Testing av et program er uunnværlig hvis du planlegger å levere et robust og pålitelig produkt til kundene dine. Denne artikkelen vil ta en nærmere titt på beta-testing iOS-applikasjoner med TestFlight, en gratis webtjeneste som gjør det enkelt å distribuere Ad Hoc-bygg og overvåke betatestbruk.
Testingsprogramvare er ikke begrenset til beta-testing. Det finnes flere teknikker for å teste programvare, for eksempel enhetstesting, integreringstesting, stresstesting, etc. Hver av disse metodene har sin fordel og plass i utviklingssyklusen. Betatesting er en prosess der en pre-release eller beta-versjon distribueres til et begrenset publikum som ikke er en del av utviklingslaget.
I de tidlige dagene av iOS-utviklingen var det ikke trivielt å distribuere testbygg, samle tilbakemelding og samle krasjrapporter. Men i de senere år har en håndfull tjenester oppstått som gjør beta-testing ikke bare enklere, men trivielt. I denne artikkelen vil jeg diskutere en slik tjeneste: TestFlight. TestFlight tillater utviklere å distribuere testbygginger over luften. Fiddling med .ipa filer og provisjonsprofiler er en ting fra fortiden hvis du bestemmer deg for å slutte med TestFlight.
Enkel ad hoc-distribusjon er ikke den eneste fordelen med TestFlight. TestFlight tilbyr også en SDK som gir deg en rekke flotte funksjoner med overraskende lite overhead. Når SDK er installert og konfigurert, sendes krasjrapporter til TestFlight og automatisk symbolisert. En annen flott funksjon i TestFlight SDK er kontrollpunkter. Du kan angi kontrollpunkter på bestemte steder i søknaden din for å se om en bestemt funksjon faktisk brukes. Kontrollpunktene knytter seg pent inn i øktene. Når en bruker åpner programmet, startes en økt automatisk. TestFlight-dashbordet viser hvor lenge en økt varer og hvilke kontrollpunkter som testeren passerte under en økt. Listen over funksjoner stopper ikke der. Noen andre nyttige funksjoner inkluderer: tilbakemelding i appen, oppdateringer i appen og ekstern logging.
For å følge trinnene i denne opplæringen trenger du en TestFlight-konto. Gå over til TestFlight-nettstedet og registrer deg for en gratis konto. Etter at du har logget deg på TestFlight-kontoen din for første gang, blir du bedt om å lage et lag. Hva er lag? Et lag er bare en kategorisering for gruppering av bygg og testere. Sjansen er at du jobber på flere applikasjoner for forskjellige kunder eller prosjekter. Et team lar deg enkelt gruppere bygg og testere for hver applikasjon eller klient. Med andre ord er det en praktisk måte å holde byggene og testerne av ulike prosjekter skilt og organisert.
Det neste trinnet er å laste opp en testbygg til TestFlight. Men før vi gjør det, må vi opprette et program som er riktig konfigurert og konfigurert for TestFlight. Dette inkluderer integrering av TestFlight SDK for å utnytte funksjonene jeg beskrev tidligere.
Selvfølgelig skinner TestFlight virkelig hvis du har en gruppe engasjerte testere (helst folk som ikke er med i utviklingslaget). Å legge til testere til TestFlight er like enkelt som å sende en invitasjon. Med TestFlight er det ikke lenger tungvint å få en enhetens UDID som du vil se litt senere. Jeg forklarer hvordan du kan invitere beta testere litt senere i denne opplæringen.
Programmet som vi skal bygge vil være enkelt. Det primære målet med denne opplæringen er å vise deg hvordan du får fart med TestFlight og ikke så mye å bygge et funksjonsrikt program. Funksjonene i applikasjonen er enkle, (1) implementere TestFlight-kontrollpunkter, (2) spør brukeren om tilbakemelding mens du bruker programmet, og (3) krasjer applikasjonen og la TestFlight samle krasjrapporten.
Opprett et nytt prosjekt i Xcode ved å velge Enkeltvisningsprogram mal fra listen over maler (figur 3). Navn søknaden din Ta av, skriv inn en bedriftsidentifikator, sett iPhone for enhetens familie, og sjekk Bruk automatisk referansetelling. Sørg for å fjerne merket for de resterende avmerkingsboksene for dette prosjektet. Fortell Xcode hvor du vil lagre prosjektet ditt og klikk på Skape knapp (figur 4).
Start med å laste ned den nyeste stabile utgivelsen av TestFlight SDK (1.1 på skrivingstidspunktet). Ekstra arkivet og legg til libTestFlight.a og TestFlight.h, ligger i TestFlightx.x mappe til prosjektet ditt. Pass på at du kopierer begge filene til prosjektet ved å merke av i boksen merket Kopier elementer til målgruppens mappe (om nødvendig) og ikke glem å legge til begge filene i Take-Off-målet (figur 5). For å holde alt organisert, plasser libTestFlight.a og TestFlight.h i en egen gruppe som heter TestFlight.
Noen få trinn er nødvendige for å fullføre integrasjonen med TestFlight. Velg prosjektet ditt i Prosjektnavigator og klikk på Take-Off-målet i listen over mål. Velg Bygg faser kategorien øverst og åpne Link binær med biblioteker skuff. Hvis alt gikk bra, libTestFlight.a bør være til stede i listen over biblioteker. Dra libTestFlight.a inn i listen over koblede biblioteker hvis den ikke er til stede i listen (figur 6).
TestFlight benytter seg også av libz bibliotek for å gjøre noe av sitt arbeid, så vi må koble prosjektet mot dette biblioteket også. Klikk på pluss-knappen nederst på listen over biblioteker, søk etter libz.dylib, og legg det til i listen over koblede biblioteker.
Det neste trinnet er valgfritt, men anbefales hvis du planlegger å bruke TestFlight i hele programmet. I stedet for å importere TestFlight.h I hver fil som bruker TestFlight SDK, er det mer praktisk å legge det til prosjektets Prefix.pch fil. Ta en titt på det komplette Prefix.pch filen nedenfor for avklaring.
// // Prefiksheader for alle kildefiler av "Take-off" -målet i "Take-off" -prosjektet // #import#ifndef __IPHONE_4_0 #warning "Dette prosjektet bruker funksjoner som bare er tilgjengelige i iOS SDK 4.0 og nyere." #endif #ifdef __OBJC__ #import #importere #import "TestFlight.h" #endif
TestFlight installerer en uncaught unntakshåndterer for å rapportere krasjer og samle krasjrapporter. Hvis du vil benytte denne funksjonen, anbefales det å endre innstillingene for prosjektet litt. Velg prosjektet ditt fra Prosjektnavigator og velg Ta av mål fra listen over mål. Velg Bygg innstillinger og bla til Utplassering innstillinger (figur 8). Tre distribusjonsinnstillinger må settes til NEI.
Innstillinger i fet skrift indikerer at standardverdien er overstyrt. Du kan tilbakestille eventuelle endringer du har gjort ved å velge en fet innstilling og trykke på plass på tastaturet. Kontroller at den effektive verdien av bygginnstillingen er satt til kombinert (figur 9).
TestFlight gjør ikke noe i søknaden din ennå. For å gjøre bruk av funksjonene må vi initialisere TestFlight når programmet lanseres. Det ideelle stedet for å sette opp TestFlight er i programdelegatet applikasjons: didFinishLaunchingWithOptions:
metode. Det er overraskende enkelt å sette opp TestFlight. Alt vi trenger å gjøre er å ringe ta av:
på TestFlight-klassen og pass teamtoken til laget vi satt opp tidligere i denne opplæringen.
For å finne teamtoken din, gå over til TestFlights Dashboard, velg det riktige laget fra rullegardinmenyen øverst til høyre, og velg Rediger Info fra samme meny. Kopier teamtoken og send det som parameter i ta av:
metode.
- (BOOL) søknad: (UIApplication *) søknad didFinishLaunchingWithOptions: (NSDictionary *) launchOptions // Initialiser View Controller self.viewController = [[MTViewController alloker] initWithNibName: @ "MTViewController" bundle: null); // Initialiser Window self.window = [[UIWindow alloc] initWithFrame: grenser for [[UIScreen mainScreen]]; [self.window setRootViewController: self.viewController]; [self.window makeKeyAndVisible]; // Initialiser TestFlight [TestFlight takeOff: @ "TEAM_TOKEN_GOES_HERE"]; returnere JA;
TestFlight er nå satt opp, men vi må fortsatt laste opp en bygg til TestFlight. Følgende trinn er ikke annerledes enn trinnene du normalt vil ta for å forberede en test eller ad hoc-bygge for et program. Jeg har oppført de nødvendige trinnene nedenfor.
Dette kan virke som mye arbeid, men de fleste av disse trinnene må bare gjøres en gang for en ny applikasjon. I tillegg kan mye av dette automatiseres. I tillegg til TestFlight SDK har TestFlight også en opplastings-API som lar utviklere automatisk laste opp bygg til TestFlight. Jeg vil ikke dekke opplastings-API-en i denne opplæringen, da dette er et mer avansert emne.
Siden du leser denne opplæringen, vil jeg anta at du allerede er kjent med beta-testing og trinnene som er involvert for å forberede en testbygg for ad hoc-distribusjon. I denne artikkelen vil jeg begrense meg til trinnene som involverer TestFlight.
Når distribusjon bygger med TestFlight, er det viktig å riktig versjonen av byggene dine. Ved å gjøre det, blir det lettere å holde styr på ulike testbygginger.
Før du laster opp programmet, må du sørge for å angi versionsnummeret til programmet ditt til 0.1.0 for å indikere at dette er en pre-release-versjon. Ta en titt på dette spørsmålet om Stack Overflow for mer informasjon om versjonsnummer.
For å laste opp en konstruksjon manuelt til TestFlight, klikk på den andre knappen fra høyre øverst på TestFlight Dashboard.
Å legge til en ny bygning er like enkelt som å dra .ipa-filen til riktig felt, legger til en kort beskrivelse, også kjent som utgivelsesnotater, og klikker på Laste opp knapp. Utgivelsesnotater er mye mer nyttige enn de fleste tror. Utgivelsesnotater skal inneholde opplysninger om endringene som er gjort i testbygget, men de bør også inneholde kjente feil (om nødvendig) og mulige løsningsmuligheter.
Etter å ha lastet opp en bygning av søknaden din, blir du tatt til tillatelser se på din nye testbygg. Tillatelsene til en bygge bestemmer hvem som har tilgang til den nye testbyggingen, det vil si hvem som kan installere testbyggingen på enheten / enhetene sine. Hvis du for eksempel bare vil teste en kritisk konstruksjon internt og forhindre at eksterne testere får tilgang til byggingen, kan du begrense tillatelsene til den bygningen til bare å omfatte medlemmer av utviklingslaget ditt.
For å gjøre distribusjonen av testbyggene enklere, har TestFlight en funksjon som er riktig navngitt distribusjonslister. En distribusjonsliste er en liste eller en gruppe personer i et TestFlight-team. I stedet for å manuelt velge medlemmer av et TestFlight-team hver gang du laster opp en ny bygning, forteller du TestFlight hvilke distribusjonslister som har tilgang til den nye bygningen.
En av de beste funksjonene i TestFlight er evnen til å samle inn og automatisk symbolisere krasjrapporter. Det er enkelt å implementere kontrollpunkter og spørre om tilbakemelding fra brukerne. La oss endre prosjektet for å se hvordan alt dette fungerer.
Åpne ditt Xcode-prosjekt og gå over til visningskontrollens implementeringsfil (MTViewController.m). I viewDidLoad
metode, opprett tre knapper som vist nedenfor. Koden skal ikke være vanskelig å forstå.
- (void) viewDidLoad [super viewDidLoad]; // Opprett Crash Button UIButton * crashButton = [[UIButton allokere] initWithFrame: CGRectMake (20.0, 20.0, 280.0, 44.0)]; [crashButton setTitle: @ "Crash" forState: UIControlStateNormal]; [crashButton setBackgroundColor: [UIColor blueColor]]; [crashButton addTarget: selvhandling: @selector (crash :) forControlEvents: UIControlEventTouchUpInside]; [self.view addSubview: crashButton]; // Opprett kontrollpunktsknapp UIButton * checkpointButton = [[UIButton-allokering] initWithFrame: CGRectMake (20,0, 72,0, 280,0, 44,0)]; [checkpointButton setTitle: @ "Checkpoint" forState: UIControlStateNormal]; [checkpointButton setBackgroundColor: [UIColor blueColor]]; [checkpointButton addTarget: self action: @selector (checkpoint :) forControlEvents: UIControlEventTouchUpInside]; [self.view addSubview: checkpointButton]; // Opprett Tilbakeknappsknapp UIButton * FeedbackButton = [[UIButton-allokering] initWithFrame: CGRectMake (20.0, 124.0, 280.0, 44.0)]; [tilbakemeldingButton setTitle: @ "Tilbakemelding" forState: UIControlStateNormal]; [tilbakemeldingstast setBackgroundColor: [UIColor blueColor]]; [tilbakemeldingButton addTarget: selvhandling: @selector (tilbakemelding :) forControlEvents: UIControlEventTouchUpInside]; [self.view addSubview: feedbackButton];
Ideen er enkel. Søknaden bør krasje når brukeren tapper den første knappen. Krasj et søknad er enkelt. Ikke sant? Ta en titt på implementeringen av brak:
metode for å se hvordan den implementeres. Vi lager en matrise med ett element og deretter be om det andre objektet i matrisen. Dette kaster en NSRangeException
siden det bare er ett element i gruppen.
- (ugyldig) krasj: (id) avsender NSArray * array = @ [@ "one"]; NSLog (@ "% @", [array objectAtIndex: 1]);
Gjennomføringen av kontrollpunkt:
Metoden er overraskende enkel takket være TestFlight SDK. Som nevnt tidligere, er kontrollpunktene et middel for å spore om visse funksjoner i søknaden din brukes av dine testere. Med andre ord, forklarer du når en bruker har gjort noe som er av interesse for deg. Som jeg sa, forteller kontrollpunktene (blant annet) hvilke funksjoner som brukes, og enda viktigere, hvilke funksjoner som ikke er. Noen funksjoner er vanskelige å finne selv om dette kanskje ikke er åpenbart for utvikleren.
- (ugyldig) kontrollpunkt: (id) avsender [TestFlight passCheckpoint: @ "Brukeren klikket på kontrollpunktknappen."];
Det finnes ulike måter å samle tilbakemelding fra testene dine på. Den enkleste måten å samle tilbakemelding på er imidlertid å bruke TestFlights tilbakemeldingsintegrasjon. Ta en titt på implementeringen av tilbakemelding:
metode for å se hvordan dette fungerer. Når brukeren tapper tilbakekoblingsknappen, vises en modal visning og lar brukeren legge inn tilbakemelding (figur 13).
- (ugyldig) tilbakemelding: (id) avsender [TestFlight openFeedbackView];
Når du har lagt til disse endringene i søknaden din, oppdaterer du versionsnummeret til applikasjonen til 0.2.0 og arkiverer prosjektet. Det er god praksis å alltid rense prosjektet ditt før du utarbeider et bygg for distribusjon, for App Store, samt for ad hoc-distribusjon. Last opp den nye .ipa-filen til TestFlight, angi de riktige tillatelsene, og oppdater installasjonen på enheten din med den nye bygningen ved å gå til TestFlight-dashbordet på enheten din. Hvis du fulgte trinnene, bør du se de tre knappene og trykke på hver knapp vil utløse funksjonaliteten i programmet.
TestFlight sender informasjon til TestFlight-serverne når det er mulig, det vil si hvis en nettverkstilkobling er tilgjengelig og operativsystemet ikke dreper programmet før det er ferdig med å sende dataene til TestFlight-serverne. Dette betyr at TestFlight er et flott verktøy for å samle levende data fra testene dine. Du kan prøve dette selv ved å trykke på de tre knappene i søknaden din og ta en titt på TestFlight-instrumentbrettet noen minutter senere.
TestFlight viser hvilke testere som installerte oppdateringen og hvilken enhet. Det viser deg antall økter, hvilke kontrollpunkter de passerte, og hvor mange sammenbrudd som skjedde. Som jeg nevnte tidligere, blir krasjrapporterne automatisk symbolisert, noe som er en av funksjonene jeg elsker mest.
Det er også mulig å utforske individuelle økter ved å klikke på øktfanen til venstre (figur 14), velge en bruker fra listen og klikke på en av øktene. Dette gir deg en detaljert oversikt over den respektive brukerens økt (figur 15).
Betatesting er bare nyttig hvis du kan stole på en gruppe engasjerte testere som virkelig ønsker å sette søknaden din gjennom sine skritt. Legge til testere til TestFlight kan gjøres på to måter. (1) Åpne TestFlight dashbordet til teamet som du vil legge til en ny tester. Klikk på knappen med det lille plustegnet i øverste høyre hjørne og fyll ut skjemaet. Det anbefales at brukeren klikker på aksepteringslinken på testenheten. Selv om dette ikke er strengt nødvendig, gjør det prosessen mye enklere, fordi enheten som brukeren bruker, vil bli automatisk lagt til sin konto som en testenhet.
(2) Et annet alternativ for å legge til testere, er å bruke en rekrutteringsadresse. Dette er et skjema som gjør at noen kan registrere seg som tester. Dette gjør det enklere hvis du har en ganske stor gruppe testere du vil legge til i TestFlight.
For noen måneder siden ble TestFlight kjøpt av Burstly, og dette har resultert i etableringen av TestFlight Live. TestFlight Live er et annet tillegg til TestFlight-plattformen, og det gir utviklere mulighetene til ikke bare å bruke TestFlight for utvikling og testing, men også når applikasjonen er live i App Store. Du kan lese mer om det på TestFlights blogg.
Selv om ideen bak TestFlight er enkel, over-the-air distribusjon av beta-versjoner, har TestFlight mye mer å tilby. Etter å ha brukt TestFlight i noen uker, vil du legge merke til at teamet bak TestFlight har gjort en god jobb når det gjelder hvilke funksjoner som skal inkluderes og hvordan alle de forskjellige stykkene passer sammen.
Det er mange flere funksjoner som jeg ikke diskuterte i denne artikkelen, så jeg oppfordrer deg til å besøke TestFlights nettsted og bla gjennom den utestående dokumentasjonen. TestFlight vokser fortsatt raskt, og jeg er nysgjerrig på å se hvordan den fortsetter å utvikle seg og forbedre.