Esta inquietud se puede abordar de diversas formas, por lo tanto te enseñamos la que en nuestra opinión es la respuesta más completa.
Solución:
Varias preguntas generales allí, intentaré responder en base a mi experiencia.
Pensar en un Arnés de prueba como un ‘facilitador’ que realmente hace todo el trabajo de (1)ejecutando pruebas usando un (2)biblioteca de prueba y (3)generar informes. Requeriría que sus scripts de prueba estén diseñados para manejar diferentes (4)datos de prueba y (5)escenarios de prueba. Esencialmente, cuando el arnés de prueba está en su lugar y los datos de requisitos previos están preparados (también conocido como preparación de datos) alguien debería poder hacer clic en un botón o ejecutar un comando para ejecutar todas sus pruebas y generar informes.
Lo más probable es que un arnés de prueba sea una colección de cosas diferentes que hacen que suceda todo lo anterior. Si escribió pruebas unitarias mientras desarrollaba su 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. Luego agrega una especie de “corredor” que pasa por todos sus “guiones de pruebay los ejecuta (en lugar de tener que ejecutar las pruebas una a la vez). Si parece que un arnés de prueba es más una colección conceptual que una sola pieza de software, entonces lo estás entendiendo correctamente 🙂
Ahora mi pregunta es ¿cuál es la diferencia entre el caso de prueba y el script de prueba?
Respuesta simple pero no del todo correcta: A Caso de prueba define los objetivos de la prueba, la descripción, las condiciones previas, los pasos (descriptivos o específicos), los resultados esperados. A Guión de prueba entonces sería el script automatizado real que ejecuta para hacer esa prueba. Eso es en un contexto de automatización. Y cambia. Mucho.
Lo que certificaciones como ISTQB definen como escenarios de prueba generalmente se le 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 significan exclusivamente pruebas automatizadas. Por otro lado, también se puede argumentar que se pueden combinar varios casos de prueba en un script de prueba y viceversa. Entonces eso plantea la pregunta, ¿cómo funciona un procedimiento de prueba encajar?
Una etapa de desarrollo de prueba 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 asumes un > (es más grande que/colección de) relación, ¿cómo los relacionarías? Pregunta retórica: que difiere según el lugar donde trabaja, quién es su cliente, etc. Lo mejor es definirlo con sus colegas/clientes y estar de acuerdo en la comprensión de los términos en lugar de la definición. Actualmente voy con script de prueba = script automatizado, basado en un caso de prueba manual preexistente o un escenario de prueba.
Además, ¿cómo usa el software para probar las diferentes funciones del AUT?
Escribes diferentes pruebas para probar diferentes cosas. Cada prueba realiza ciertas acciones y verifica si la salida de AUT coincide con lo que esperaba: If displayed_value == expected_value. Un fichero 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 mensajes diferentes, etc.
Eche un vistazo a RobotFramework y Selenium. Una prueba de marco de trabajo de robot (escrita en archivos de texto o html) combinada con la biblioteca Selenium le permitiría escribir una prueba automatizada que pruebe algo específico… como una validación de página de inicio. Escribiría una prueba separada para asegurarse de que un usuario pueda ver todos sus mensajes. Otro para probar la eliminación de notificaciones. Y así.
arnés de prueba: Un entorno de prueba compuesto por stubs y controladores necesarios para ejecutar una prueba.
Se utilizarán arneses y cabos de prueba para replicar los elementos faltantes (componentes aún no incluidos en las pruebas o sistemas externos). A menudo, cuando se realizan pruebas de integración a pequeña escala de varios módulos o componentes, es necesario idear o improvisar métodos y herramientas para llevar los datos de prueba a los componentes bajo prueba. Esto a menudo se denomina arnés de prueba. Debido a la necesidad de comprender los aspectos técnicos necesarios para construir un arnés de prueba, esta prueba casi siempre la realiza el equipo de desarrollo.
Un arnés de prueba puede facilitar la prueba de componentes o parte de un sistema al simular el entorno en el que se ejecutará ese objeto de prueba. Esto se puede hacer porque otros componentes de ese entorno aún no están disponibles y se reemplazan por stubs y/o controladores, o simplemente para proporcionar un entorno predecible y controlable en el que cualquier falla pueda localizarse en el objeto bajo prueba. Suelen ser programas personalizados generados por desarrolladores para ayudar en el proceso de prueba. Si se utilizan en una organización madura, es muy posible que estos arneses se consideren como ‘Activos de prueba’ y estén sujetos a Control de versiones y Gestión de configuración.