wiki:metodologia2017/PlanPruebasIntegracion

Tabla de Contenido

  1. Proyecto Terepaima (Visor PDF)
    1. Actividades del 2017
    2. Actividades del 2016
      1. Documentación general asociada al proyecto
      2. Primera solución
      3. Segunda solución
    3. Documentación sobre el Desarrollo de Terepaima
      1. Documentación sobre Evince y EvinceSignatures
      2. Documentación sobre poppler
      3. Documentación sobre paquetes debian
      4. Documentación sobre qpdfview
      5. Empaquetado terepaima
    4. Descargar Terepaima
  2. Metodología de Desarrollo de Software Libre (MDSL) Versión 2.0
    1. Conceptualización
      1. Plantillas
      2. Flujograma
    2. Administracion
      1. Plantillas
      2. Flujograma
    3. Construcción
      1. Plantillas
      2. Flujograma
    4. Uso de macros para trazabilidad
  3. Alcance del Proyecto
  4. Propuesta de Solución
  5. Propuesta de Desarrollo del Proyecto
    1. 1. Necesidades y/o problemas
    2. 2. Solución propuesta
    3. 3. Alcance del software propuesto
    4. 4. Descripción general de la arquitectura del software
    5. 5. Metodología de desarrollo
    6. 6. Plataforma de operación
    7. 7. Plataforma de desarrollo
    8. 8. Licencias de código y documentación
  6. Posibles Actores de la Comunidad de Desarrollo de la Aplicación
    1. 1. Lista de Posibles Aliados de la Red de Desarrollo de la Aplicación
    2. 2. Lista de Posibles Colaboradores en el Desarrollo de la Aplicación
  7. Estudio de Factibilidad de Desarrollo del Proyecto
    1. 1. Aspectos a Considerar para el Estudio de Factibilidad del Proyecto
    2. 2. Factibilidad del Desarrollo del Proyecto
  8. Descripción de la Aplicación
  9. Estándares de Desarrollo del Proyecto
  10. Priorización de Funcionalidades
    1. Funcionalidad:
    2. Valor cuantitativo de prioridad:
    3. Dependencia entre Funcionalidades:
  11. Estudio de los Riesgos
    1. Valor cuantitativo de prioridad
  12. Plan del Proyecto
    1. 1. Priorización de funcionalidades del software según las necesidades …
  13. Definición del dominio de la aplicación
  14. Definición del dominio de la aplicación
  15. Diagramas de Actividades
  16. Diagramas de Actividades de los Métodos de las Clases de la Aplicación
  17. Definición de Requerimientos
    1. 1. Requerimientos Funcionales
    2. 2. Requerimientos No-funcionales
  18. Especificación de Requerimientos (Funcionalidades)
    1. 1. Casos de Uso Firmar Archivos PDF usando servicio Murachi
    2. Flujograma de actividades
  19. Diagramas de Secuencia
    1. 1. Diagramas de Secuencia para los Casos de Uso de la Aplicación
      1. 1.1 Diagrama de Secuencia del Caso de Uso <Nombre del Caso de Uso>
      2. 1.2 Diagrama de Secuencia del Caso de Uso <Nombre del Caso de Uso>
  20. Diagramas de Estado de las Clases de la Aplicación
    1. 1. Diagrama de Estado de la Clase <nombre de la clase>
    2. 2. Diagrama de Estado de la Clase <nombre de la clase>
  21. Diseño del Prototipo No-funcional de la Interfaz U/S
  22. Pruebas
  23. Manuales del Sistema

Plan de Pruebas de Integración



Las pruebas de integración representan la manera como se integran las unidades o componentes de la aplicación de software que ya han sido probados.

1. Ambiente de Prueba



Recursos Físicos



[Se colocan las características del equipo (hardware) a utilizar para la realización de la prueba, por ejemplo, tipo de computador y su velocidad, tipo de memoria, características de disco duro, etc.]

Recursos Lógicos



[Se indican las herramientas a instalar para la realización de las pruebas, por ejemplo, herramientas automatizadas para la aplicar de pruebas]

2. Eventos



Los posibles eventos que pueden activar métodos o funciones de los componentes a integrar se indican a continuación:



[Se indica en cada ítem el evento que genera la activación de métodos o funciones de los componentes a integrar]

[Se indica en cada ítem el evento que genera la activación de un o varios métodos o funciones de los componentes a integrar]
.
.
.


Nota:



Los eventos que generan la activación de los métodos o funciones de los componentes de la aplicación pueden obtenerse a través de los casos de uso.
Un evento puede ser: la invocación de una función (caso de uso) o, un cambio de estado en un objeto que activa un pase de mensajes.

3. Casos de Pruebas de Integración



[El formato del caso de prueba que se elabora como parte del plan de prueba de integración contendrá solo la información referida a los siguientes campos de la Tabla 1: objetivo de la prueba, evento asociado, # del caso de prueba, servicio solicitado, condiciones y servicio realizado esperado. Los demás campos de esta tabla serán llenados una vez realizada la prueba]

# del caso de pruebaObjetivo de la pruebaEventoComponentes participantesCondicionesSecuencia (hilo) de ejecución de los métodos de los componentesRespuesta esperada a la solicitudRespuesta obten[Notas:ida a la solicitudObservaciones
[Se colocan las condiciones, en caso de existir, que permiten que ante un mismo evento se activen diferentes métodos o funciones. Cada condición generará casos de prueba distintos][Se coloca la secuencia de métodos o funciones activados de cada componente dado el evento en particular. En caso de que los métodos tengan algún tipo de polimorfismo es conveniente colocar los parámetros de los métodos. Utilizar la secuencia de métodos o funciones indicada en el método de Jorgensen y Erickson]




Notas:



[Un mismo evento puede generar varios casos de prueba dependiendo de ciertas condiciones.
Cada secuencia de mensajes (hilo) se integra individualmente]





Last modified 7 years ago Last modified on Jan 19, 2017, 11:55:37 AM