wiki:metodologia2017/ReportePruebasUnitarias

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

Reporte de Pruebas Unitarias



  1. Reporte de Pruebas Unitarias de las Clases del Componente <nombre del componente>



[El diseño del reporte de pruebas que se indica en esta sección se realiza solo en caso de un desarrollo orientado a objeto]

1.1. Casos de Prueba de la Clase <nombre de la clase>

A continuación se presentan los casos de prueba de los métodos correspondiente a la clase <nombre de la clase>

Casos de Prueba del Método <nombre del método>

[Se coloca la tabla de los casos de prueba del método en particular. Estos casos de prueba deben reflejar resultados satisfactorios, es decir, sin errores]

Resumen de Incidentes



[En la tabla que se muestra a continuación se deben reportar todos los errores encontrados en los casos de prueba del método en particular, así como la frecuencia y el origen de los errores]

Errores encontrados Frecuencia Origen de errores
- se coloca la frecuencai de origen del error -
- se coloca la frecuencai de origen del error -


Reporte de Correcciones y Modificaciones



[Se colocan las correcciones y modificaciones hechas al código del método en particular]

[Los pasos indicados en la sub-sección 1.1 deben repetirse para todas las clases que integren el componentes en particular]

[Los pasos indicados en la sección 1 deben repetirse para todos los componentes que conformen la aplicación]

  1. Reporte de Pruebas Unitarias de las Funciones del Componente <nombre del componente>



[El diseño del reporte de pruebas que se indica en esta sección se realiza solo en caso de un desarrollo no orientado a objeto]

2.1. Casos de Prueba de las Funciones del Componente <nombre del componente>

A continuación se presentan los casos de prueba de las funciones correspondiente al componente <nombre del componente>

Casos de Prueba de la Función <nombre de la función>

[Se coloca la tabla de los casos de prueba de la función en particular. Estos casos de prueba deben reflejar resultados satisfactorios, es decir, sin errores]

Resumen de Incidentes



[En la tabla que se muestra a continuación se deben reportar todos los errores encontrados en los casos de prueba de la función en particular, así como la frecuencia y el origen de los errores]

Errores encontrados Frecuencia Origen de errores
- se coloca la frecuencai de origen del error -
- se coloca la frecuencai de origen del error -


Reporte de Correcciones y Modificaciones



[Se colocan las correcciones y modificaciones hechas al código de la función en particular]

[Los pasos indicados en la sub-sección 2.1 deben repetirse para todas las funciones que integran el componentes en particular]

[Los pasos indicados en la sección 2 deben repetirse para todos los componentes que conformen la aplicación]









Last modified 7 years ago Last modified on Jan 19, 2017, 11:56:01 AM