Los ingenieros / probadores de calidad de software no confían en los rastreadores y las arañas para probar sus errores. No creo que los ingenieros / probadores de seguridad de aplicaciones deban ...
En su lugar, las SQE dependen en gran medida de los marcos de prueba de desarrollo (o arneses de prueba) como Selenium RC / Bromine, Watir / WatiN / Watij, Sahi, HtmlUnit o WebDriver. Algunos optan por las herramientas comerciales de control de calidad más avanzadas, como HP QTP, IBM Rational Functional Tester, TestComplete y VisualStudio Tester Edition 2010.
Las SQE normalmente no automatizan el ejercicio de una aplicación para el flujo de ejecución porque:
- Las pruebas requieren un descubrimiento exploratorio, como lo haría un turista en una ciudad nueva en la que nunca han estado, a fin de alcanzar conclusiones y determinar resultados, especialmente cuando se trata de un cronograma (que son muchos los evaluadores)
- Los conceptos como la clasificación de equivalencia pueden ahorrar horas de trabajo a los evaluadores al no tener que repetir los mismos errores una y otra vez. Las pruebas de seguridad son un poco diferentes, ya que tenemos que probar todo, pero ciertamente no lo hacemos hoy y podríamos utilizar esta técnica, especialmente cuando se trata de una caja de tiempo.
El problema con la automatización de prueba es que las aplicaciones cambian rápidamente y el arnés de prueba generalmente debe modificarse continuamente para mantenerse al día con estos cambios. En metodologías ágiles como ICONIX, las pruebas de robustez son códigos generados a partir de modelos de dominios y diagramas de secuencia (generalmente en UML), pero ciertamente hay muchas formas de automatizar la reconstrucción de casos de prueba durante la rotación de códigos y nuevas versiones, sin embargo, esto es muy frecuente. probablemente no requiere metaprogramación.