Hispanopedia WikiLa automatización de pruebas consiste en el uso de software (independiente del software que se está probando) para controlar la ejecución de las pruebas y comparar el resultado real con el previsto. [ 1 ] La automatización de pruebas permite probar el sistema bajo prueba (SUT) sin interacción manual, lo que puede conducir a una ejecución de pruebas más rápida y a una mayor frecuencia de pruebas. La automatización de pruebas es un aspecto clave de las pruebas continuas y, a menudo, de la integración continua y la entrega continua (CI/CD). [ 2 ]
En comparación con las pruebas manuales
La automatización ofrece muchas ventajas sobre las pruebas manuales.
Pruebas de API
En las pruebas de API , estas controlan el sistema bajo prueba (SUT) a través de su interfaz de programación de aplicaciones (API). En comparación con las pruebas manuales, las pruebas automatizadas de API suelen ejecutar un número considerable de casos en un tiempo relativamente corto.
Pruebas de interfaz gráfica de usuario
Para las pruebas de interfaz gráfica de usuario (GUI) , estas controlan el sistema bajo prueba (SUT) mediante su interfaz gráfica , generando eventos como pulsaciones de teclas y clics del ratón. Las pruebas automatizadas de GUI pueden ser difíciles de desarrollar, pero se ejecutan mucho más rápido que si las realizara una persona. Las especializaciones incluyen:
- Pruebas de grabación y reproducción : algunas herramientas de prueba de interfaz gráfica de usuario (GUI) ofrecen una función que permite grabar interactivamente las acciones del usuario y reproducirlas posteriormente como prueba, comparando los resultados reales con los esperados. Una ventaja de este enfoque es que requiere poca o ninguna programación. Sin embargo, algunos afirman que estas pruebas presentan problemas de fiabilidad, mantenimiento y precisión. Por ejemplo, cambiar la etiqueta de un botón o moverlo a otra parte de la vista puede requerir que las pruebas se vuelvan a grabar, y estas pruebas suelen ser ineficientes y registran incorrectamente actividades irrelevantes.
- Para probar un sitio web, la interfaz gráfica de usuario (GUI) es el navegador y la interacción se realiza mediante eventos DOM y HTML . Normalmente se utiliza un navegador sin interfaz gráfica o soluciones basadas en Selenium WebDriver para este propósito. [ 3 ]
Pruebas de regresión
Cuando se implementan las pruebas automatizadas, las pruebas de regresión pueden ser una operación relativamente rápida y sencilla. En lugar de requerir una inversión considerable de tiempo y esfuerzo humano, ejecutar una prueba de regresión podría ser tan solo presionar un botón, e incluso el inicio de la ejecución puede automatizarse.
Técnicas automatizadas
Las siguientes son técnicas de prueba destacadas que se clasifican como automatización de pruebas.
Pruebas continuas
Continuous testing is the process of executing automated tests as part of the software delivery pipeline to assess the business risk of releasing the SUT.[4][5] The scope of testing extends from validating bottom-up requirements or user stories to assessing the system requirements associated with overarching business goals.[6]
Model-based testing
For model-based testing, the SUT is modeled and test cases can be generated from it to support no code test development. Some tools support the encoding of test cases as plain English that can be used on multiple operating systems, browsers, and smart devices.[7]
Test-driven development
Test-driven development (TDD) inherently includes the generation of automation test code. Unit test code is written while the SUT code is written. When the code is complete, the tests are complete as well.[8]
Other
Other test automation techniques include:
Considerations
A review of 52 practitioner and 26 academic sources found that five main factors to consider in test automation decision are: system under test (SUT), scope of testing, test toolset, human and organizational topics, cross-cutting factors. The factors most frequently identified were: need for regression testing, economic factors, and maturity of SUT.[9][10]
While the reusability of automated tests is valued by software development companies, this property can also be viewed as a disadvantage as it leads to a plateau effect, where repeatedly executing the same tests stops detecting errors.
Testing tools can help automate tasks such as product installation, test data creation, GUI interaction, problem detection (consider parsing or polling agents equipped with test oracles), defect logging, etc., without necessarily automating tests in an end-to-end fashion.
Considerations when developing automated tests include:
- Platform and operating system independence
- Data-driven testing
- Reporting (database, Crystal Reports)
- Ease of debugging
- Logging
- Version control
- Extension and customization (e.g., APIs for integrating with other tools)
- Integration with developer tools (e.g., using Ant or Maven for Java development)
- Unattended test runs for integration with build processes and batch runs
- Notificaciones por correo electrónico (es decir, mensajes de rebote )
- Ejecución de pruebas distribuidas
Roles
Para respaldar las pruebas automatizadas con código, el ingeniero de pruebas o el responsable de control de calidad del software debe tener conocimientos de programación. Algunas técnicas de prueba, como las basadas en tablas y las que no requieren código, pueden reducir o eliminar la necesidad de conocimientos de programación.
Estructura
Un marco de automatización de pruebas proporciona un entorno de programación que integra la lógica de prueba, los datos de prueba y otros recursos. Este marco sienta las bases de la automatización de pruebas y simplifica el proceso. El uso de un marco puede reducir el costo del desarrollo y mantenimiento de las pruebas . Si se modifica algún caso de prueba , solo es necesario actualizar el archivo del caso de prueba; el script principal y el script de inicio permanecerán sin cambios.
Un marco de trabajo se encarga de definir el formato en el que se expresan las expectativas, proporciona un mecanismo para conectarse o controlar el SUT, ejecuta las pruebas e informa los resultados. [ 11 ]
Existen diversos tipos de marcos de trabajo:
- Lineal : código procedimental, posiblemente generado por herramientas como las que utilizan grabación y reproducción.
- Estructurado : utiliza estructuras de control, normalmente condiciones/declaraciones 'if-else', 'switch', 'for', 'while'.
- Basado en datos : los datos se almacenan fuera de las pruebas en una base de datos, hoja de cálculo u otro mecanismo.
- Basado en palabras clave
- Híbrido : se utilizan varios tipos
- Marco de automatización ágil
- Pruebas unitarias : algunos frameworks están diseñados principalmente para pruebas unitarias, como xUnit , JUnit y NUnit.
Interfaz de automatización de pruebas
Una interfaz de automatización de pruebas es una plataforma que proporciona un espacio de trabajo para incorporar múltiples herramientas y marcos de prueba para pruebas de sistema/integración . Una interfaz de automatización de pruebas puede simplificar el proceso de mapeo de pruebas a criterios de negocio sin necesidad de codificación. Una interfaz de automatización de pruebas puede mejorar la eficiencia y la flexibilidad del mantenimiento de las pruebas. [ 12 ]
Una interfaz de automatización de pruebas consta de los siguientes aspectos:
- Motor de interfaz
- Consta de un analizador sintáctico y un ejecutor de pruebas. El analizador sintáctico se encarga de analizar los archivos objeto provenientes del repositorio de objetos y convertirlos al lenguaje de scripting específico de la prueba. El ejecutor de pruebas ejecuta los scripts de prueba utilizando un entorno de prueba . [ 12 ]
- Repositorio de objetos
- Recopilación de datos de objetos de la interfaz de usuario/aplicación registrados por la herramienta de prueba mientras se explora el SUT. [ 12 ]
Véase también
- Comparación de herramientas de prueba de interfaz gráfica de usuario (GUI)
- Lista de herramientas de prueba web
- Fuzzing : técnica de prueba de software automatizada
Referencias
- ↑ Kolawa, Adam; Huizinga, Dorota (2007). Prevención automatizada de defectos: Mejores prácticas en la gestión de software . Wiley-IEEE Computer Society Press. pág. 74. ISBN 978-0-470-04212-0.
- ↑ O'Connor, Rory V.; Akkaya, Mariye Umay; Kemaneci, Kerem; Yilmaz, Murat; Poth, Alexander; Messnarz, Richard (15 de octubre de 2015). Mejora de procesos de sistemas, software y servicios: 22.ª Conferencia Europea, EuroSPI 2015, Ankara, Turquía, 30 de septiembre - 2 de octubre de 2015. Actas . Springer. ISBN 978-3-319-24647-5.
- ↑ Pruebas sin interfaz gráfica con PhantomJS; http://phantomjs.org/headless-testing.html
- ↑ Parte del proceso: Por qué las pruebas continuas son esenciales , por Adam Auerbach, TechWell Insights, agosto de 2015
- ↑ La relación entre el riesgo y las pruebas continuas: una entrevista con Wayne Ariola , por Cameron Philipp-Edmonds, Stickyminds, diciembre de 2015
- ↑ DevOps: ¿Está usted enviando los errores a los clientes más rápido ?, por Wayne Ariola y Cynthia Dunlop, PNSQC, octubre de 2015
- ↑ Actas de la 5.ª Conferencia Internacional sobre Pruebas y Validación de Software (ICST). Centro de Competencia de Software Hagenberg. «Diseño de pruebas: lecciones aprendidas e implicaciones prácticas» . doi : 10.1109/IEEESTD.2008.4578383 . ISBN 978-0-7381-5746-7.
- ↑ Vodde, Bas; Koskela, Lasse (2007). "Aprendiendo desarrollo guiado por pruebas contando líneas". IEEE Software . 24 (3): 74– 79. doi : 10.1109/ms.2007.80 . S2CID 30671391 .
- ↑ Garousi, Vahid; Mäntylä, Mika V. (2016-08-01). "¿Cuándo y qué automatizar en las pruebas de software? Una revisión bibliográfica multivocal". Information and Software Technology . 76 : 92–117 . doi : 10.1016/j.infsof.2016.04.015 .
- ↑ Brian Marick. "¿Cuándo se debe automatizar una prueba?" . StickyMinds.com . Consultado el 20 de agosto de 2009 .
- ↑ "Selenium Meet-Up 20/04/2010 Elisabeth Hendrickson sobre Robot Framework 1 de 2" . YouTube . 28 de abril de 2010. Consultado el 26 de septiembre de 2010 .
- 1 2 3 "Conquest: Interfaz para el diseño de automatización de pruebas" (PDF) . Archivado del original (PDF) el 26 de abril de 2012. Recuperado el 11 de diciembre de 2011 .
General references
- Elfriede Dustin; et al. (1999). Automated Software Testing. Addison Wesley. ISBN 978-0-201-43287-9.
- Elfriede Dustin; et al. (2009). Implementing Automated Software Testing. Addison Wesley. ISBN 978-0-321-58051-1.
- Mark Fewster & Dorothy Graham (1999). Software Test Automation. ACM Press/Addison-Wesley. ISBN 978-0-201-33140-0.
- Roman Savenkov: How to Become a Software Tester. Roman Savenkov Consulting, 2008, ISBN 978-0-615-23372-7
- Hong Zhu; et al. (2008). AST '08: Proceedings of the 3rd International Workshop on Automation of Software Test. ACM Press. doi:10.1145/1370042. ISBN 978-1-60558-030-2.
- Mosley, Daniel J.; Posey, Bruce (2002). Just Enough Software Test Automation. Prentice Hall Professional. ISBN 978-0130084682.
- Hayes, Linda G., "Automated Testing Handbook", Software Testing Institute, 2nd Edition, March 2004
- Kaner, Cem, "Architectures of Test AutomationArchived 2021-01-26 at the Wayback Machine", August 2000
- Software testing
- Automation software
