Varias preguntas generales, trataré de responder en función de mi experiencia.
Think de un Test Harness como un 'facilitador' que realmente hace todo el trabajo de (1) pruebas de ejecución usando una biblioteca de prueba (2) y (3) la generación de informes . Requeriría que sus scripts de prueba estén diseñados para manejar diferentes (0) datos de prueba y (5) escenarios de prueba. Esencialmente, cuando el arnés de prueba está en su lugar y se preparan los datos de requisitos previos (también conocido como data prep), alguien debería poder hacer clic en un botón o ejecutar un comando para ejecutar todas las pruebas y generar informes.
Un arnés de prueba es muy probablemente una colección de cosas diferentes que hacen que todo lo anterior ocurra. Si escribiste pruebas unitarias mientras desarrollas tu aplicación, eso sería parte de un arnés de prueba. También tendría otras pruebas para la funcionalidad de su aplicación, como: el usuario inicia sesión en el sitio, ve el panel de favoritos, mensajes recientes y notificaciones. A continuación, agrega un 'corredor' de tipo que recorre todos sus "scripts de prueba " y los ejecuta (en lugar de tener que ejecutar pruebas de uno en uno). Si se siente como un arnés de prueba es más una colección conceptual que una sola pieza de software, entonces está entendiendo esto correctamente :-)
Ahora mi pregunta es cuál es la diferencia entre el caso de prueba y la prueba ¿guión?
Respuesta simple, pero no del todo correcto: un caso de prueba define objetivos de la prueba, descripción, condiciones previas, las etapas (descriptivos o específicos), los resultados esperados. Un script de prueba sería el script automatizado real que ejecuta para realizar esa prueba. Eso está en un contexto de Automatización. Y cambia Mucho.
Qué certificaciones como ISTQB definen como escenarios de prueba que normalmente se conoce como casos de prueba en algunas empresas y países. En otros, los casos de prueba se invierten con scripts de prueba cuando se refieren a pruebas manuales (cuando los pasos se dan en detalle pero no forman parte de un arnés de automatización). Otros dicen que los scripts de prueba son exclusivamente pruebas automatizadas. Por otro lado, también se puede argumentar que varios casos de prueba se pueden combinar en un script de prueba y viceversa.Entonces, eso plantea la pregunta: ¿cómo encaja un procedimiento de prueba ?
Una etapa test development puede tener: "Procedimientos de prueba, escenarios de prueba, casos de prueba, conjuntos de datos de prueba, scripts de prueba para usar en software de prueba."
Si supone > (es mayor que/colección de) relación, ¿cómo relacionaría eso? Pregunta retórica: que difiere según el lugar donde trabaje, quién es su cliente, etc. Lo mejor es definirlo con sus colegas/clientes y acordar la comprensión de los términos en lugar de la definición. Actualmente utilizo script de prueba = script automatizado, basado en un caso de prueba manual preexistente o en un escenario de prueba.
Además, ¿cómo utiliza el software para probar las diferentes funciones de AUT?
Escribes diferentes pruebas para probar diferentes cosas. Cada prueba realiza ciertas acciones y comprueba si la salida de AUT coincide con lo que esperaba: If displayed_value == expected_value. Un archivo de entrada podría usarse para proporcionar datos para la lista de prueba de nombres de usuario y contraseñas de prueba, por ejemplo. O ejecute la misma prueba con datos diferentes: inicie sesión como un usuario diferente con diferentes mensajes, etc.
Eche un vistazo a RobotFramework y Selenium. Una prueba de marco de robot (escrita en archivos de texto o html) combinada con la biblioteca de Selenium le permitirá escribir una prueba automática que pruebe algo específico ... como la validación de una página de inicio. Debería escribir una prueba por separado para asegurarse de que un usuario pueda ver todos sus mensajes. Otro para probar las notificaciones de compensación. Y así.
Solo piense en ello como la raíz a la que recurrirá cuando quiera probar completamente su proyecto. – Pithikos