Personal tools
You are here: Home Production Proyectos Testing Documentos de trabajo Procedimientos de testeo de gvSIG Información relevante ¿Qué es un plan de pruebas?
Document Actions

¿Qué es un plan de pruebas?

by Victoria Agazzi last modified 2010-06-04 16:46

Descripción de los planes de pruebas que hacemos en gvSIG

Un plan de pruebas es un conjunto de estrategias y recursos para llevar adelante una metodología de pruebas sistemática y planificada.

Mediante esta metodología se busca validar el comportamiento de la aplicación, o de parte de ella. Para validar el comportamiento de la aplicación, la persona que ejecute el plan de pruebas proporcionará unos datos de entrada y observará tanto el comportamiento de gvSIG como los datos de salida. Mediante la comparación del resultado esperado con el resultado obtenido se validan las funcionalidadeds implementadas en la aplicación.

Los casos a probar serán identificados en función de los requerimientos de usuario, la frecuencia de uso, el riesgo asociado y las especificaciones de la aplicación. Se deberán de determinar prioridades en las funcionalidades a probar de cada subsistema, ya que es imposible probarlo todo.

Estructura del plan de prueba

Cada plan de prueba tendrá una estructura jerárquica, mediante la cual se intentará cubrir al máximo posible las funcionalidades presentes en el sistema que se quiere testear. Esta estructura jerárquica constará de varios niveles en donde la relación de cada nivel con el nivel siguiente será de 1 --> n. Lo niveles de los que se puede componer un plan de pruebas son:

  • Sistema. El sistema es la aplicación en sí sobre la cual se hacen las pruebas definidas en el plan.
  • Subsistema. El subsistema asocia grupos funcionales relacionados, de forma que éste debe funcionar de forma que sea lo más independiente posible al resto del sistema.
  • Módulo. Cada módulo agrupa funcionalidades concretas las cuales integradas con las de otros módulos implementan la lógica del subsistema.
  • Casos de uso. Los casos de uso describen un uso del sistema y cómo éste interactúa con el usuario. Los casos de uso deben responder a la pregunta de qué hace cada módulo desde el punto de vista del usuario.
  • Casos de prueba. Mediante los casos de prueba se indica la sucesión de pasos a seguir por el usuario al utilizar una funcionalidad del caso de uso correspondiente. Estos pasos deberán de ser definidos de forma unívoca. Los casos de prueba se definirán para conjuntos de datos entrada-salida genéricos (no particularizados en tipos de datos, formatos, tamaño de ficheros, etc).
  • Escenarios. Cada caso de prueba se podrá probar con varios juegos de datos de entrada-salida, a cada conjunto de datos que particularizan un caso de preuba se le llama escenario. Las entradas de un escenario serán los datos necesarios para ejecutar el caso de prueba correspondiente y los datos de salida serán los resultados esperados de dicho caso de prueba.

Esquema estructura jerárquica

images/estructura_funcional.JPG

Se tiene que tener en cuenta que no en todos los casos deberán estar presentes todos los niveles, dependiendo de la complejidad del grupo de funcionalidades que se quiera probar con el plan de test a diseñar.

Ventajas del testeo en base a planes de pruebas

  • Se tienen definidas las pruebas de forma escrita

    Tener redactadas las pruebas hace que sean repetibles por cualquier usuario o tester, ya que para ejecutar las pruebas solamente tendrá que seguir de forma ordenada los pasos que se detallan en cada prueba.

  • Se identifican fácilmente las áreas de la aplicación que han sido testeadas y también las que no

    La estructura jerárquica de cada conjunto de pruebas hace que sea muy simple identificar las funcionalidades que se han testeado. Por tanto también se podrá saber de forma rápida qué funcionalidades son las que tienen más probabilidad de contener errores o malcomportamientos.

  • Monitorización del estado de la aplicación

    Los resultados de las ejecuciones de las pruebas se guardan junto con el plan de pruebas. Analizando el contenido de estos resultados puede hacer una estimación de la estabilidad del conjunto de la aplicación, y de cuáles son sus zonas de debilidad y riesgo.

  • Se identifican errores que son consecuencia de correcciones de otros errores

    Una vez se corrige un error en el código puede suceder que esta corrección perjudique otra zona de la aplicación. Al pasar las mismas pruebas build tras build compilado, se tiene más probabilidad de encontrar este tipo de errores.

View source document Get permanent link


Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: