Caso de prueba
Especificación de una prueba de software, su objetivo y su procedimiento

En ingeniería de software , un caso de prueba es una especificación de las entradas, las condiciones de ejecución, el procedimiento de prueba y los resultados esperados que definen una sola prueba que se ejecutará para lograr un objetivo de prueba de software particular , como para ejercitar una ruta de programa particular o para verificar el cumplimiento de un requisito específico. [1] Los casos de prueba son la base de las pruebas que son metódicas en lugar de aleatorias. Se puede crear una batería de casos de prueba para producir la cobertura deseada del software que se está probando. Los casos de prueba definidos formalmente permiten que las mismas pruebas se ejecuten repetidamente contra versiones sucesivas del software, lo que permite una prueba de regresión efectiva y consistente . [2]

Casos de prueba formales

Para comprobar por completo que se cumplen todos los requisitos de una aplicación, debe haber al menos dos casos de prueba para cada requisito: una prueba positiva y una prueba negativa. [3] Si un requisito tiene subrequisitos, cada subrequisito debe tener al menos dos casos de prueba. El seguimiento del vínculo entre el requisito y la prueba se realiza con frecuencia mediante una matriz de trazabilidad . Los casos de prueba escritos deben incluir una descripción de la funcionalidad que se va a probar y la preparación necesaria para garantizar que se pueda realizar la prueba.

Un caso de prueba escrito formal se caracteriza por una entrada conocida y una salida esperada, que se elabora antes de ejecutar la prueba. [4] La entrada conocida debe probar una condición previa y la salida esperada debe probar una condición posterior .

Casos de prueba informales

Para aplicaciones o sistemas sin requisitos formales, los casos de prueba se pueden escribir basándose en el funcionamiento normal aceptado de programas de una clase similar. En algunas escuelas de pruebas, los casos de prueba no se escriben en absoluto, pero las actividades y los resultados se informan después de que se han ejecutado las pruebas.

En las pruebas de escenarios , se utilizan historias hipotéticas para ayudar al evaluador a pensar en un problema o sistema complejo. Estos escenarios normalmente no se escriben con ningún detalle. Pueden ser tan simples como un diagrama para un entorno de prueba o podrían ser una descripción escrita en prosa. La prueba de escenario ideal es una historia que sea motivadora, creíble, compleja y fácil de evaluar. Por lo general, se diferencian de los casos de prueba en que los casos de prueba son pasos únicos, mientras que los escenarios cubren una serie de pasos clave. [5] [6]

Formato típico de caso de prueba escrito

Un caso de prueba generalmente contiene un solo paso o una secuencia de pasos para probar el comportamiento/funcionalidad y las características correctas de una aplicación. Generalmente se proporciona un resultado esperado.

Información adicional que puede incluirse: [7]

  • ID de caso de prueba : un identificador único para el caso de prueba.
  • Descripción/resumen : El objetivo del caso de prueba.
  • Pasos de prueba : los pasos exactos a realizar.
  • Resultado esperado : El resultado esperado y cómo determinar si se ha logrado.
  • Resultado real
  • Prerrequisitos : Condiciones que deben existir o preparación requerida antes de la ejecución de la prueba.
  • Categoría de prueba
  • Autor - nombre del probador.
  • Automatización : si este caso de prueba está automatizado o no y, de ser así, cómo.
  • Aprobado/reprobado
  • Observaciones

Los casos de prueba más grandes también pueden contener estados o pasos previos y descripciones. [7]

Un caso de prueba escrito también debe contener un lugar para el resultado real.

Estos pasos se pueden almacenar en un documento de procesador de textos, una hoja de cálculo, una base de datos u otro repositorio común.

En un sistema de base de datos, también podrá ver los resultados de pruebas anteriores, quién los generó y la configuración del sistema utilizada para generarlos. Estos resultados anteriores normalmente se almacenan en una tabla separada.

Los conjuntos de pruebas a menudo también contienen [8]

  • Resumen de la prueba
  • Configuración

Además de una descripción de la funcionalidad que se va a probar y la preparación necesaria para garantizar que la prueba pueda realizarse, la parte que requiere más tiempo en el caso de prueba es crear las pruebas y modificarlas cuando el sistema cambia.

En circunstancias especiales, podría ser necesario realizar la prueba, obtener resultados y luego un equipo de expertos evaluaría si los resultados pueden considerarse aprobados. Esto sucede a menudo cuando se determina el número de rendimiento de los productos nuevos. La primera prueba se toma como base para los ciclos de prueba y lanzamiento de productos posteriores.

Las pruebas de aceptación , que utilizan una variación de un caso de prueba escrito, son realizadas comúnmente por un grupo de usuarios finales o clientes del sistema para garantizar que el sistema desarrollado cumpla con los requisitos especificados o el contrato. [9] [10] Las pruebas de aceptación del usuario se diferencian por la inclusión de casos de prueba positivos o de ruta feliz y la exclusión casi completa de casos de prueba negativos. [11]

Véase también

Referencias

  1. ^ Ingeniería de sistemas y software -- Vocabulario . Iso/Iec/IEEE 24765:2010(E). 2010-12-01. pp. 1–418. doi :10.1109/IEEESTD.2010.5733835. ISBN 978-0-7381-6205-8.
  2. ^ Kaner, Cem (mayo de 2003). "¿Qué es un buen caso de prueba?" (PDF) . STAR East : 2.
  3. ^ "Redacción de reglas de prueba para verificar los requisitos de las partes interesadas". StickyMinds .
  4. ^ Beizer, Boris (22 de mayo de 1995). Pruebas de caja negra . Nueva York: Wiley. p. 3. ISBN 9780471120940.
  5. ^ "Introducción a las pruebas de escenarios" (PDF) . Cem Kaner . Consultado el 7 de mayo de 2009 .
  6. ^ Crispin, Lisa; Gregory, Janet (2009). Pruebas ágiles: una guía práctica para evaluadores y equipos ágiles . Addison-Wesley . Págs. 192-195. ISBN. 978-81-317-3068-3.
  7. ^ ab Liu, Juan (2014). "Equilibrio del proceso de toma de decisiones en el mercado financiero". Conferencia internacional sobre ciencia computacional e inteligencia computacional de 2014. págs. 113–121. doi :10.1109/CSCI.2014.104. ISBN 9781605951676. S2CID  15204091 . Consultado el 22 de octubre de 2019 .
  8. ^ Kaner, Cem; Falk, Jack; Nguyen, Hung Q. (1993). Prueba de software informático (2.ª ed.). Boston: Thomson Computer Press. pág. 123-124. ISBN 1-85032-847-1.
  9. ^ Hambling, Brian; van Goethem, Pauline (2013). Pruebas de aceptación del usuario: una guía paso a paso . BCS Learning & Development Limited. ISBN 9781780171678.
  10. ^ Black, Rex (agosto de 2009). Gestión del proceso de pruebas: herramientas y técnicas prácticas para gestionar pruebas de hardware y software . Hoboken, Nueva Jersey: Wiley. ISBN 978-0-470-40415-7.
  11. ^ Cimperman, Rob (2006). UAT Defined: A Guide to Practical User Acceptance Testing (Definición de UAT: una guía para pruebas prácticas de aceptación del usuario ). Pearson Education. pp. Capítulo 2. ISBN. 9780132702621.
  • Ingeniería de casos de prueba de software Por Ajay Bhagwat
Obtenido de "https://es.wikipedia.org/w/index.php?title=Caso_de_prueba&oldid=1239950600"