Software Test Automation - Masters Thesis

Question

Estoy tratando de escribir una tesis sobre Software Test Automation. Planeo comparar los dos enfoques de grabación y programación de scripts de prueba, y discutir sobre varios marcos de automatización, por ejemplo Abbot, Selenium, Yemmy, FEST, etc ... También en mi tesis habrá una breve descripción sobre las técnicas de prueba de software y tal vez una comparación de pruebas automatizadas con pruebas de software.

EDIT: Tengo la intención de los aspectos de probar una aplicación sobre él es interfaz gráfica de usuario. Entonces mis Pruebas estarían principalmente en el lado Blackbox del mundo de las pruebas. No he planeado escribir sobre Pruebas unitarias.

En el momento en que leí bastante sobre los diferentes marcos de automatización, pero pueden no tener el tiempo para revisar todos ellos. Así que planeo leer sobre ellos y hacer que Thesis esté más basada en la literatura.

• ¿Piensa que este Tema puede ser un éxito?
• ¿Tiene alguna otra idea sobre este tema?
• ¿Puede recomendar literatura?
• ¿Cuál es su opinión sobre este tema?

Answer 1

Una encuesta de la literatura debe ser un buen enfoque para una tesis de maestría. Parece que solo quieres hablar sobre las herramientas orientadas a los clientes que guían a la interfaz gráfica de usuario de la caja negra, que es un nicho razonablemente pequeño.

Usted/podría/quiere tener una página o dos en todo el mundo de herramientas de prueba - pruebas de unidades, seguridad, carga, etc., como alguien mencionado anteriormente. Pero creo que enfocaste tu nicho bastante bien.

Creo que con una tesis de 6 créditos deberías tener suficiente tiempo para explorar y probar algunas de las herramientas comerciales y de código abierto más grandes, así como para examinar la literatura. Le animo a que estudie las dos herramientas comerciales (prueba rápida pro, prueba completa) y también la automatización basada en palabras clave: selenio RC, por ejemplo. Alguien más mencionó las pruebas "detrás de la GUI", por ejemplo, FIT/Fitnesse, podría valer la pena discutir y evaluar.

cubro de recuadro negro, la automatización de pruebas funcionales en mi columna mensual en el número de diciembre de 2008 de la prueba de software y la revista rendimiento:

http://www.stpmag.com/issues/stp-2008-12.pdf (página 7)

Esa es la única página de cero-el- introducción superficialLa introducción de cinco frases es que las herramientas de grabación/reproducción de pantalla lo comparan todo, por lo que si su GUI cambia, de alguna manera (incluso si solo cambia la resolución de la pantalla), puede aparecer como un error falso. Las herramientas basadas en palabras clave solo verifican lo que les pides que verifiquen: fallan si un botón se desactiva repentinamente sin una buena razón o si el ícono no es transparente.

Solo un humano es bueno para verificar esa afirmación oculta al final de cada caso de prueba "... y no sucedió nada extraño".

Por lo tanto, la ejecución y evaluación de pruebas basadas en computadora puede tener algún valor, pero debe ser parte de un desayuno equilibrado.

Otras cosas a tener en:

• James Bach de "pruebas de software de automatización de aceite de serpiente"
• Kaner, Bach y el libro "Lecciones aprendidas en Testing de Software"
• mi blog sobre los marcos de prueba de Pettichord - http://xndev.blogspot.com/2007/09/whats-test-framework.html (que es el número 4 resultado en Google de "lo que es un marco de pruebas", por lo que me siento cómodo recomendando)
• la analogía campo de minas (http://www.testingperspective.com/tpwiki/doku.php?id=minefield)
• Los papeles de Doug Hoffman en la automatización de pruebas: http://www.softwarequalitymethods.com/H-Papers.html
• El clásico "shelfware" problema de la automatización de pruebas
• El antiintelectualismo empujado por algunos defensores de la comunidad de automatización de pruebas de caja negra
• Negro Caja Pruebas de Software de Kaner por supuesto
• la obra de James Bach en el desarrollo cognitivo/prueba/
• Contexto Driven Software Testing
• trabajo de Jon Kohl en "el hombre y la máquina", o el enfoque cyborg (en lugar de la computadora -alona ejecución y evaluación de prueba)

Espero que ayude.

Answer 2

No sé de literatura, pero creo que las publicaciones de ACM en la biblioteca de su escuela probablemente produzcan resultados. Particularmente el SIG* newsletters. (Tal vez SIGSOFT?)

Suena como una buena tesis de la Maestra a mí. Por supuesto, su asesor de tesis es la última palabra sobre eso. Deberías ir a hablar con ellos.

Answer 3

Como una revisión basada en la literatura, esto hace un excelente tema; hay mucho material por ahí. Obviamente no voy a comenzar a entrar en todos los detalles de eso, ya que ese es su trabajo como autor. :-)

Sin embargo, aunque no estoy familiarizado con los requisitos originales de investigación para una tesis de maestría, esto ciertamente no sería suficiente para una tesis doctoral. Buscaría un trabajo original que podría agregar a esto. Una idea sería una taxonomía de métodos y sistemas de prueba. También puede examinar el papel de las pruebas en comparación con la verificación formal.

Answer 4

de prueba de software de automatización es un gran tema, y ​​es posible que desee afinar la puntería en lugar de intentar cubrir una mezcla de los marcos, reproducción/grabación, resumen de las técnicas, frente automatizado no.

Libros enteros se han escrito sobre la automatización de pruebas de software:

• Como tema general
• Centrándose en las pruebas de funcionamiento/función (FIT)
• Centrándose en la unidad de pruebas
• Centrándose en las pruebas unitarias utilizando un lenguaje y un marco particulares

Los marcos están destinados a diferentes tipos de pruebas :

• Prueba de la unidad
  • Test-Driven Development
  • Comportamiento-Driven Development
• Característica/Pruebas funcionales
• pruebas de interfaz gráfica de usuario (Windows, GUI de Java, X Window, etc. .)
• Prueba web
• Pruebas de rendimiento
• Pruebas de seguridad

me consideraría centrándose en los marcos (o técnicas, o lo que sea) en una de estas áreas en lugar de intentar cubrir todas. O elige un par de estas áreas y contrastarlas.

El problema de la reproducción/grabación frente a las pruebas escritas a mano me parece antiguo. En la década de 1980, a los vendedores les gustaba impulsar la reproducción/grabación para la automatización de la GUI de Windows. Fue un gran demos y grandes esperanzas. Pero también hizo pruebas frágiles y anaqueles. Reproducir/grabar es bueno para empezar con una herramienta, pero para ser mantenible, generalmente necesita guiones escritos en un nivel superior. Eso marcó el comienzo de una nueva era de hoja de cálculo y enfoques basados ​​en palabras clave, y finalmente FIT/FitNesse.

Answer 5

Acaba de publicarse este año un excelente libro sobre automatización de pruebas: "Implementación de pruebas automáticas", Elfriede Dustin, Thom Garrett & Bernie Gauf, Addison Wesley.

Answer 6

Me gustaría leer la tesis si está disponible en línea. Vale la pena considerar el acceso programático a la GUI, tanto en la web como en la aplicación. Luego hay herramientas de grabación y reproducción como Selenium o WatiR. Y, por supuesto, los pros y los contras de la automatización: limitaciones de las herramientas (la mayoría no puede ver los applets de java o flash en páginas web, por ejemplo) y lo más importante que algunas personas olvidan al automatizar. ¡NO todo debe ser automatizado!

Pero si es posible que comentes esto para notificarnos cuando esté listo, me gustaría sinceramente leerlo.