stringtranslate.com

Pruebas basadas en palabras clave

Las pruebas basadas en palabras clave , también conocidas como pruebas basadas en palabras de acción (que no deben confundirse con las pruebas basadas en acciones ), son una metodología de pruebas de software adecuada tanto para pruebas manuales como automatizadas . Este método separa la documentación de los casos de prueba  (incluidos tanto los datos como la funcionalidad a utilizar) de la prescripción de la forma en que se ejecutan los casos de prueba. Como resultado, separa el proceso de creación de pruebas en dos etapas distintas: una etapa de diseño y desarrollo, y una etapa de ejecución. La subetapa de diseño cubre el análisis y la evaluación de requisitos y el análisis, la definición y la población de datos.

Descripción general

Esta metodología utiliza palabras clave (o palabras de acción) para simbolizar una funcionalidad a probar, como por ejemplo Enter Client . La palabra clave Enter Client se define como el conjunto de acciones que se deben ejecutar para ingresar un nuevo cliente en la base de datos. Su documentación de palabras clave contendría:

La sintaxis de pruebas basadas en palabras clave enumera los casos de prueba (palabras de datos y de acción) mediante un formato de tabla (consulte el ejemplo a continuación). La primera columna (columna A) contiene la palabra clave, Enter Client, que es la funcionalidad que se está probando. Luego, las columnas restantes, BE, contienen los datos necesarios para ejecutar la palabra clave: nombre, dirección, código postal y ciudad.

Para ingresar otro cliente, el evaluador crearía otra fila en la tabla con Enter Client como palabra clave y los datos del nuevo cliente en las columnas siguientes. No es necesario volver a enumerar todas las acciones incluidas.

En él podrás diseñar tus casos de prueba mediante:

Dada la naturaleza iterativa del desarrollo de software, el diseño de la prueba suele ser más abstracto (menos específico) que una implementación manual de una prueba, pero puede evolucionar fácilmente a uno.

Ventajas

Las pruebas basadas en palabras clave reducen la sensibilidad al mantenimiento causado por cambios en el Sistema/Software Bajo Prueba (SUT). Si cambian los diseños de pantalla o se migra el sistema a otro SO, prácticamente no es necesario realizar cambios en los casos de prueba: los cambios se realizarán en la documentación de palabras clave, un documento por cada palabra clave, sin importar cuántas veces se use la palabra clave en los casos de prueba, e implica un proceso profundo de diseño de pruebas.

Además, debido a la descripción muy detallada de la forma de ejecutar la palabra clave (en la documentación de palabras clave), la prueba puede ser realizada por casi cualquier persona. Por lo tanto, las pruebas basadas en palabras clave se pueden utilizar tanto para pruebas manuales como para pruebas automatizadas . [1]

Además, este enfoque es un marco abierto y extensible que unifica todas las herramientas, activos y datos relacionados con el esfuerzo de prueba y producidos por él. Bajo este marco único, todos los participantes en el esfuerzo de prueba pueden definir y refinar los objetivos de calidad por los que están trabajando. Es donde el equipo define el plan que implementará para alcanzar esos objetivos. Y, lo más importante, proporciona a todo el equipo un lugar al que acudir para determinar el estado del sistema en cualquier momento.

Las pruebas son el mecanismo de retroalimentación en el proceso de desarrollo de software. Te indican dónde se deben hacer correcciones para mantener el rumbo en cualquier iteración dada de un esfuerzo de desarrollo. También te informan sobre la calidad actual del sistema que se está desarrollando. La actividad de implementación de pruebas implica el diseño y desarrollo de scripts de prueba reutilizables que implementan el caso de prueba. Después de la implementación, se puede asociar con el caso de prueba.

La implementación es diferente en cada proyecto de prueba. En un proyecto, puede decidir crear tanto scripts de prueba automatizados como scripts de prueba manuales. [2] El diseño de pruebas, en cambio, es un proceso iterativo. Puede comenzar a diseñar pruebas antes de cualquier implementación del sistema basando el diseño de prueba en especificaciones de casos de uso, requisitos, prototipos, etc. A medida que el sistema se especifica con mayor claridad y tiene compilaciones del sistema con las que trabajar, puede elaborar los detalles del diseño. La actividad de diseñar pruebas responde a la pregunta: "¿Cómo voy a realizar las pruebas?" Un diseño de prueba completo informa a los lectores sobre qué acciones deben tomarse con el sistema y qué comportamientos y características deben esperar observar si el sistema funciona correctamente.

Un diseño de prueba es diferente del trabajo de diseño que debe realizarse para determinar cómo construir la implementación de la prueba.

Metodología

La metodología de pruebas basada en palabras clave divide la ejecución del proceso de prueba en varias etapas:

  1. Base del modelo/prototipado: análisis y evaluación de requisitos.
  2. Definición del modelo de pruebas: a partir del resultado de la evaluación de requisitos, elaborar un modelo software propio.
  3. Definición de datos de prueba: en base al modelo propio definido, palabra clave de inicio y definición de datos principales/complementarios.
  4. Preparación para la prueba: base de la prueba de admisión, etc.
  5. Diseño de pruebas: análisis de la base de prueba, diseño de casos/procedimientos de prueba, diseño de datos de prueba.
  6. Ejecución manual de pruebas: ejecución manual de los casos de prueba utilizando la documentación de palabras clave como guía de ejecución.
  7. Automatización de la ejecución de pruebas: creación de scripts automatizados que realizan acciones de acuerdo a la documentación de palabras clave.
  8. Ejecución de pruebas automatizada.

Definición

Una palabra clave o palabra de acción es una combinación definida de acciones en un objeto de prueba que describe cómo deben ejecutarse las líneas de prueba. Una palabra de acción contiene argumentos y la define un analista de pruebas.

La prueba es un paso clave en cualquier proceso de desarrollo y consiste en aplicar una serie de pruebas o comprobaciones a un objeto (prueba de sistema/SW — SUT). Recordando siempre que la prueba sólo puede mostrar la presencia de errores, no su ausencia. En la prueba de sistema RT, no es suficiente comprobar si el SUT produce los resultados correctos. También debe verificarse que el tiempo empleado en producir ese resultado sea el esperado. Además, el momento en que se obtienen estos resultados también puede depender del momento en que se obtienen las entradas. A su vez, el momento en que se obtienen las entradas futuras se determina a partir de los resultados. [2]

Automatización de la ejecución de pruebas

La etapa de implementación difiere según la herramienta o el marco de trabajo. A menudo, los ingenieros de automatización implementan un marco de trabajo que proporciona palabras clave como “verificar” e “ingresar”. [1] Los evaluadores o diseñadores de pruebas (que no necesitan saber programar) escriben casos de prueba basados ​​en las palabras clave definidas en la etapa de planificación que han sido implementadas por los ingenieros. La prueba se ejecuta utilizando un controlador que lee las palabras clave y ejecuta el código correspondiente.

Otras metodologías utilizan una etapa de implementación integral. En lugar de separar las tareas de diseño de pruebas e ingeniería de pruebas, el diseño de pruebas es la automatización de pruebas. Las palabras clave, como "editar" o "verificar", se crean utilizando herramientas en las que ya se ha escrito el código necesario. Esto elimina la necesidad de ingenieros adicionales en el proceso de prueba, porque la implementación de las palabras clave ya es parte de la herramienta. Algunos ejemplos son GUIdancer y QTP .

Ventajas

Contras

Véase también

Referencias

  1. ^ ab Faught, Danny R. (noviembre de 2004). "Pruebas basadas en palabras clave". Sticky Minds . Ingeniería de calidad de software . Consultado el 12 de septiembre de 2012 .
  2. ^ ab Mandurrino, José L. (julio de 2014). "Gestión y aplicación de la validación en el sistema RT (tiempo real)". UTIU. {{cite web}}: Falta o está vacío |url=( ayuda )

Enlaces externos