Só imaxino poder escribir scripts que interactúan automaticamente coa súa aplicación iOS e poder verificar os resultados. Con UI Automation pode. UI Automation é unha ferramenta proporcionada por Apple para realizar un maior nivel de proba na súa aplicación iOS máis aló do que se pode conseguir con xctest.
1. caixa branca versus en probas de caixa negra
Pode ter oído a comparación de probas de caixa branca contra as probas de caixa negra con respecto a como podería ser probado unha peza de software. Se non está familiarizado con estes conceptos, deixe-me explicar como funcionan.
Probas en caixa branca
Imaxina que hai unha peza de software dentro dunha caixa. Con probas de caixa branca, podes ver dentro da caixa e ver todas as pezas de como funciona o software e, a continuación, facer decisións informadas sobre como probar o software. Tamén pode ter ganchos de nivel máis profundo no software de probas que escribe.
A proba da unidade é unha proba de caixa branca. Ao escribir probas de unidade, o testador ten acceso detallado ao código en proba. O verificador pode realmente escribir probas que aproveitan o software baixo proba no método ou unidade, nivel.
No desenvolvemento do software iOS, usamos o cadro Xctest para realizar este tipo de probas. Bótalle un ollo a outro tutorial que escribín sobre como comezar co xctest.
Proba de caixa negra
En probas de caixa negra, a caixa é opaca. O probador non pode ver dentro da caixa. O probador non pode acceder e non sabe sobre a implementación do código base para escribir probas. No seu canto, o probador está obrigado a usar a aplicación como usuario final interactuaría coa aplicación e agardando a súa resposta, verificando os resultados.
Hai polo menos dúas formas de executar este tipo de proba.
- un testador que realiza repetidamente e manual unha serie de pasos predefinidos e verifica visualmente os resultados.
- Use ferramentas especializadas para probar a aplicación con API que se comportan de forma similar a como un ser humano interactúa.
No desenvolvemento de aplicacións de iOS, Apple ofrece unha ferramenta chamada UI Automation para realizar probas en caixa negra.
2. Cal é a UI Automatización?
UI Automation é unha ferramenta que Apple ofrece e mantén para o maior nivel automático de aplicacións iOS. As probas están escritas en JavaScript, que se adhiren a unha API definida por Apple.
As probas de escritura pódense simplificar cando dependen das etiquetas de accesibilidade para os elementos da interface de usuario na súa aplicación. Non te preocupes, se non tes estes definidos, hai alternativas dispoñibles.
A UI API API carece do formato típico de Xunit para escribir probas. A diferenza coas probas de unidade é que o probador debe gravar manualmente éxito e fallos. As probas de automatización da UI son executadas desde o instrumento de automatización dentro da ferramenta de instrumentos que ven coas ferramentas de desenvolvedor de Apple. As probas poden ser executadas no simulador de iOS ou nun dispositivo físico.
3. Escriba probas de automatización de UI
Paso 1: abra o proxecto de exemplo
Actualizoi o proxecto de exemplo utilizado no tutorial anterior en probas de iOS con algúns elementos adicionais da interface de usuario que proporcionan algúns ganchos útiles para engadir probas de automatización II. Descarga o proxecto GitHub. Abre o proxecto e executa a aplicación para asegurarse de que todo funcione como se esperaba. Debería ver unha interface de usuario similar á que se mostra a continuación.
Antes de escribir calquera Proba, non dubide en probar a aplicación de mostra para familiarizarse coa súa funcionalidade. Como usuario, pode introducir texto no campo de texto e premer o botón para ver unha etiqueta na pantalla que amosa a cadea invertida introducida.
Paso 2: Crea unha automatización de UI
Agora que está familiarizado coa aplicación de mostra, é hora de engadir unha proba de automatización da UI. UI Automation é unha ferramenta que se pode atopar nos instrumentos. Para executar a aplicación de mostra de instrumento, seleccione Produto > perfil no menú Xcode. Seleccione Automatización da lista de ferramentas.
A xanela principal do instrumento abrirase cun único instrumento listo para executar, o Instrumento de automatización (o instrumento de automatización executa casos de proba de automatización UI). Tamén verás unha área na metade inferior da xanela que parece un editor de texto. Este é o editor de guións. Aquí é onde escribirás as túas probas de automatización II. Para esta primeira proba, siga as instrucións a continuación, engadindo cada liña ao script no editor de script.
Comezar almacenando unha referencia ao campo de texto nunha variable.
var inputField = target.frontMostApp().mainWindow().textFields();
Establecer o valor do campo de texto.
inputField.setValue("hi”);
Verificar que o valor estaba correctamente definido e, se Foi, pasar a proba. Falla a proba se non era así.
if (inputField.value() != "hi") UIALogger.logFail("The Input Field was NOT able to be set with the string!");else UIALogger.logPass("The Input Field was able to be set with the string!");
Aínda que esta proba é bastante trivial, ten valor. Acaba de escribir unha proba que demostra a presenza dun campo de texto cando a aplicación é lanzada e proba se se pode establecer unha cadea aleatoria como o valor do campo de texto. Se non me cres, elimine o campo de texto do storyboard e executa a proba. Verás que falla.
Esta proba demostra tres sistemas importantes de probas de automatización de escritura da interface de usuario. En primeiro lugar, mostra como acceder a un elemento sinxelo de interface de usuario, o campo de texto. En concreto, accedemos a un dicionario de todos os campos de texto na vista base da aplicación a través de target.frontMostApp().mainWindow().textFields() e despois buscamos o campo de texto que nos interesa ao buscar o que ten a clave Input Field. Esta clave é realmente a etiqueta de accesibilidade do campo de texto. Neste caso, defínese no guión gráfico. Tamén podemos configurar a etiqueta de accesibilidade no código usando a propiedade en NSObject.
Acceso ao director da xanela Da aplicación, a aplicación máis frontal eo obxectivo son comúns ao traballar coa automatización da interface de usuario. Vou amosar-lle como facer isto máis fácil e menos detallado máis tarde neste tutorial.
En segundo lugar, isto mostra que pode interactuar cos elementos da interface de usuario na pantalla. Neste caso, establecemos o valor do campo de texto, imitando ao usuario que interactúa coa aplicación ao introducir texto no campo de texto.
e terceiro, o exemplo tamén mostra unha técnica para verificar o que ocorre en A solicitude. Se o valor está establecido con éxito, a proba pasa. Se o valor non está definido, a proba falla.
Paso 3: Gardar probas
Ao escribir probas no editor de scripts é conveniente, rápidamente se fai complicado e difícil manter. Se deixa instrumentos, o cambio non gardado é descartado. Necesitamos manter as probas que escribimos. Simplemente copie e pegue a proba nun novo documento no seu editor de texto favorito e garda-lo. Podes atopar as probas creadas neste tutorial no proxecto de exemplo en Jumblify / jumblifytss / automatizaciónTes.js.
Para executar a proba, seleccione a pestana Media no panel dereito, ao lado do editor de scripts, e seleccione Engadir > Importar.
Pediráselle que seleccione o script para importar. Navega ata o script gardado e impréntelo. Aínda pode cambiar o script no editor de guións. Calquera cambio gardarase automaticamente no ficheiro externo que creou.
Paso 4: Tocar un
Button Actualizamos a nosa proba para probar a interacción co botón. A nosa proba xa engade texto ao campo de texto, polo que só necesitamos engadir código para tocar o botón. Considere primeiro como atopar o botón na vista para que poida tocar. Hai polo menos tres xeitos de lograr isto e cada enfoque ten a súa compensación.
foco 1
Podemos programar programando unha coordenada (x, y) na pantalla .. Facemos isto coa seguinte liña de código:
Por suposto, non teño idea se esas son as coordenadas do botón do botón Pantalla e non vou preocuparse por iso, porque este enfoque non é a ferramenta correcta para este traballo. Só o menciono para que saiba que existe. Use o en target para tocar un botón é propenso a erros, porque ese botón non se atopa sempre nesa coordenada específica.
Focus 2
Tamén é posible atopar o botón que busca na matriz do botón na xanela principal, de forma similar á que accedemos ao campo de texto na primeira proba.En lugar de acceder ao botón directamente usando unha chave, podemos recuperar unha matriz de botón na xanela principal e codificar un índice de matriz para obter unha referencia ao botón.
target.frontMostApp().mainWindow().buttons().tap();
Este enfoque é un pouco mellor. Non estamos codificando unha coordenada, pero estamos codificando un índice de matriz para atopar o botón. Se engadimos outro botón na páxina, pode accidentalmente romper esta proba.
foco 3
Isto lévame á terceira forma de atopar o botón da páxina, Usar etiquetas de accesibilidade Usando unha etiqueta de accesibilidade, podemos acceder directamente ao botón, simplemente me gustou atopar un obxecto nun dicionario cunha tecla.
target.frontMostApp().mainWindow().buttons().tap();
Con todo, con todo, Se engades a liña anterior ao script e executa-lo, recibirás un erro.
Este debe por que non definimos a etiqueta de accesibilidade para o botón. Para facelo, vai a Xcode e abra o storyboard do proxecto. Busque o botón na vista e abra o inspector de identidade á dereita (Ver > Utilities > inspector de identidade). Asegúrese de que a accesibilidade está habilitada e configure a etiqueta para o botón de Jumblify Button.
para executar a proba de novo, ten que executar a aplicación de Xcode, seleccionando produtos > executar e, a continuación, delinear a aplicación de novo, seleccionando produtos > perfil. Isto executa as probas e cada proba debe ocorrer agora.
Paso 5: Comprobe a cadea jumbled (cadea desordenada)
Como mencionei anteriormente, a nosa aplicación leva unha cadea como entrada e, cando O usuario toca o botón, mostra a cadea invertida. Necesitamos engadir unha proba máis para verificar que a cadea de entrada foi invertida correctamente. Para verificar que o UILabel está cheo coa cadea correcta, necesitamos descubrir como facer referencia a UILabel e verificar a cadea que mostra. Este é un problema común ao escribir as probas de automatización, é dicir, para descubrir como se refiren a un elemento da aplicación para facer unha afirmación respecto diso.
Hai un método en case todos os obxectos da API Automatización da interface de usuario logElementTree. Este método rexistra os elementos anidados dun determinado elemento. Isto é moi útil para comprender a xerarquía de elementos da aplicación e axudar a determinar a forma de orientar un elemento específico.
Vexamos como isto funciona gravando a árbore do elemento da xanela principal. Bótalle un ollo á seguinte liña de código.
target.frontMostApp().mainWindow().logElementTree();
Engadir esta liña ao script de proba Resultados no seguinte resultado:
Como se pode ver, hai un sub-elemento? UIAStaticText do UIAWindow e tamén pode ver que ten un nome de ih, que tamén é a cadea invertida que necesitamos verificar. Agora, para completar a nosa proba, só necesitamos engadir código para acceder a este elemento e verificar que está presente.
Por que só necesitamos verificar se o elemento
está presente? Como o nome do elemento é a cadea invertida da cadea de entrada, verificando a súa presenza confirma que a secuencia foi investida correctamente. Se o elemento non existe cando a referencia está feita por nome, a cadea invertida significa que a cadea non foi invertida correctamente.
var stringResult = target.frontMostApp().mainWindow().staticTexts();if (! stringResult.isValid()) UIALogger.logFail("The output text was NOT set with the correctly reversed string!");else UIALogger.logPass("The output text was set with the correctly reversed string!");
4. Raspando o Superficie
Hai moitas outras formas en que un usuario final pode interactuar cun dispositivo iOS mentres usa a súa aplicación. Isto significa que hai moitas outras formas que pode usar a UI UI UI para simular estas interaccións. En vez de intentar capturar unha lista completa destas interaccións, vou á documentación de referencia de automatización da UI.
Para cada tipo de obxecto co que pode interactuar, pode ver a lista de métodos dispoñibles niso Obxecto. Algúns métodos deben recuperar os atributos sobre o obxecto, mentres que outros deben simular a interacción táctil, como flickInsideWithOptions en UIAWindow.
Gravar unha sesión
a medida que intente probar aplicacións cada vez máis complicadas coa automatización da IU, verá que ás veces é bastante tedioso para usar repetidamente logElementTree Para atopar o elemento que está a procurar.Isto tamén se fai tedioso e complexo para aplicacións cunha xerarquía de vistas complexas ou navegación. Nestes casos, pode usar outra función de instrumento para rexistrar un conxunto de interaccións de usuario. O que é aínda máis grande é que os instrumentos xera o código de automatización de JavaScript da interface de usuario que se necesita para reproducir as interaccións rexistradas. Así é como pode probalo por si mesmo.
Nos instrumentos e co instrumento de automatización seleccionado, busque o botón de gravación na parte inferior da xanela.
Se fai clic no botón de gravación, os instrumentos iniciarán unha sesión de gravación como se mostra na seguinte captura de pantalla.
Os instrumentos lanzarán a súa solicitude no simulador de iOS e poden interactuar con el. Os instrumentos xerarán un guión en función das súas interaccións en tempo real. Proba. Xire o simulador de iOS, toque locais aleatorios, faga un xesto deslizante, etc. É unha forma moi útil de axudar a explorar as posibilidades de automatización II.
Evite o código monolítico
como pode prever, se seguimos engadindo máis probas á proba Arquivo que creamos co mesmo método, será difícil de manter. Que podemos facer para evitar que isto ocorra? Nas miñas probas, fago dúas cousas para solucionar este problema:
- Unha proba para unha función: isto implica que as probas que escribimos deberían centrarse nunha funcionalidade específica. Incluso lle dará un nome apropiado, como
testEmptyInputField. - Grupo as probas relacionadas nun ficheiro: tamén agrupando probas relacionadas co mesmo ficheiro. Isto mantén o código dun ficheiro manexable. Isto tamén facilita a proba das partes da funcionalidade por separado executando as probas nun ficheiro específico. Ademais, pode crear un script mestre no que chamas as funcións ou probas que agrupa a outros ficheiros de proba.
No seguinte fragmento de código, importamos un ficheiro JavaScript e isto que o Funcións nese ficheiro de JavaScript están dispoñibles para nós.
#import "OtherTests.js”
Conclusión
Neste tutorial, aprendeu o valor de Probas de nivel superior e como a UI Automation pode axudar a encher ese baleiro. É outra ferramenta na súa caixa de ferramentas para axudar a garantir que envíe aplicacións fiables e robustas.