resumen ingenieria de software 3

3
PRUEBAS DE SOFTWARE Construcción de software.- Creación detallada de software operativo mediante Codificación, Verificación, Pruebas Unitarias y de Integración y Depuración. Artefacto de software.- Engloba ficheros de código, casos o archivos de prueba, contenidos. Lenguajes de construcción: Especifican una solución a un problema ejecutable por la computadora - Configuración.- Ejemplo: Software nuevo para Linux o Windows. - Toolkits.- Ejemplo: Scripts o API (código reutilizable) - Programación.- Tipos: Lingüística, Formal, Visual. Principios de construcción de software: - Minimizar complejidad (Código sencillo y de calidad) - Anticipar cambios (Actualizar software) - Pensar en verificación posterior. (Aplicar pruebas y pensar en los fallos) - Aplicar estándares o Directos: Usar lenguaje conocido y estándar como c++, java, etc. Reglas de codificación. Notación en diagramas como UML. o De proyecto: Externos .- ISO, ANSI, OMG, IEEE Internos.- Propios de cada organización. Perspectiva de proceso Planificación.- Orden de construcción y asignación de tareas. Manejo de Excepciones.- Modificaciones y detalles. Codificación.- Código simple, variables significativas, manejo de excepciones, validaciones. Pruebas.- Unitarias y de Integración. Aseguramiento de Calidad Escribir pruebas primero Ejecución línea a línea Usar aserciones. Depuración Revisión Reutilización.- Uso de bibliotecas. Integración.- Rutinas, clases y otros componentes que están incluidos en forma separada. Verificación y validación.- Su propósito es asegurar que un producto de software resuelve el problema inicialmente planteado. Las pruebas de software son de esta familia. Sus objetivos: - Detectar y corregir defectos. - Disminuir riesgos sobre el enfoque del proyecto. - Mejorar calidad y fiabilidad del software. - Valorar cambios y consecuencias. Verificación: Estamos construyendo correctamente el producto? [Revisiones] Validación: El software construido es el correcto? [Pruebas] Revisión.- Técnica estática basada en la construcción de software (Arquitectura, Base de diseño, Analisis de Requerimientos). Prueba.- Técnica dinámica basada principalmente en la codificación y en la ejecución del programa. Revisiones de software Informales.- Inspección mínima y superficial, se detectan menos errores. Semi-formales.- Procedimientos mínimos (walkthroughs) Formales.- Inspección completa y detallada. Tipos de Pruebas: Un módulo: Unitarias -> Verifican el funcionamiento aislado de piezas de software. Varios módulos: De integración -> Interacción entre componentes. Pueden ser: Incremental ascendente.- Comienza por pruebas unitarias, siguiendo

Upload: anarocha

Post on 13-Sep-2015

4 views

Category:

Documents


2 download

DESCRIPTION

Resumen ingenieria de software 3

TRANSCRIPT

PRUEBAS DE SOFTWAREConstruccin de software.- Creacin detallada de software operativo mediante Codificacin, Verificacin, Pruebas Unitarias y de Integracin y Depuracin.

Artefacto de software.- Engloba ficheros de cdigo, casos o archivos de prueba, contenidos.

Lenguajes de construccin: Especifican una solucin a un problema ejecutable por la computadora Configuracin.- Ejemplo: Software nuevo para Linux o Windows. Toolkits.- Ejemplo: Scripts o API (cdigo reutilizable) Programacin.- Tipos: Lingstica, Formal, Visual.

Principios de construccin de software: Minimizar complejidad (Cdigo sencillo y de calidad) Anticipar cambios (Actualizar software) Pensar en verificacin posterior. (Aplicar pruebas y pensar en los fallos) Aplicar estndares Directos: Usar lenguaje conocido y estndar como c++, java, etc. Reglas de codificacin. Notacin en diagramas como UML. De proyecto: Externos .- ISO, ANSI, OMG, IEEE Internos.- Propios de cada organizacin.

Perspectiva de proceso Planificacin.- Orden de construccin y asignacin de tareas. Manejo de Excepciones.- Modificaciones y detalles. Codificacin.- Cdigo simple, variables significativas, manejo de excepciones, validaciones. Pruebas.- Unitarias y de Integracin. Aseguramiento de CalidadEscribir pruebas primeroEjecucin lnea a lneaUsar aserciones.DepuracinRevisin Reutilizacin.- Uso de bibliotecas. Integracin.- Rutinas, clases y otros componentes que estn incluidos en forma separada.

Verificacin y validacin.- Su propsito es asegurar que un producto de software resuelve el problema inicialmente planteado. Las pruebas de software son de esta familia. Sus objetivos: - Detectar y corregir defectos. - Disminuir riesgos sobre el enfoque del proyecto. - Mejorar calidad y fiabilidad del software. - Valorar cambios y consecuencias.Verificacin: Estamos construyendo correctamente el producto? [Revisiones]Validacin: El software construido es el correcto? [Pruebas]

Revisin.- Tcnica esttica basada en la construccin de software (Arquitectura, Base de diseo, Analisis de Requerimientos).Prueba.-Tcnica dinmica basada principalmente en la codificacin y en la ejecucin del programa.

Revisiones de softwareInformales.- Inspeccin mnima y superficial, se detectan menos errores.Semi-formales.- Procedimientos mnimos (walkthroughs)Formales.- Inspeccin completa y detallada.

Tipos de Pruebas:Un mdulo: Unitarias -> Verifican el funcionamiento aislado de piezas de software.Varios mdulos: De integracin -> Interaccin entre componentes. Pueden ser:Incremental ascendente.- Comienza por pruebas unitarias, siguiendo las ramas de dependencia en profundidad.Incremental descendente.- Comienza por un conjunto de mdulos en fases.Sistema completo: De sistema. Aqu se detectan requisitos no funcionales y fallos funcionales.Funcionamiento ante hardware: De aceptacin. Orden: UNITARIAS -> INTEGRACION -> SISTEMA -> ACEPTACION

Pruebas de caja negra.- [Funcionales] Basadas en la entrada/salida que genera el cdigo

Pruebas de caja blanca.- [Estructurales] Basadas en cmo fue codificado el software

Pruebas Ad hoc.- Se generan por la habilidad intuitiva en programas del ingeniero de pruebas.

Pruebas Exploratorias.- Se generan sobre la marcha, es decir, se aprenden.

Criterios de cobertura 1-wise.- Cuando cada valor de la prueba es utilizado al menos una vez como parmetro en un caso. 2-wise.- Cuando un par de valores es utilizado en un caso de prueba como parmetro

DOCUMENTACION EN LINEADocumentacin en Lnea.- Instrucciones escritas electrnicamente que permiten obtener las prestaciones de las aplicaciones de software. Objetivos:Minimizar costos de soporte.Fomentar autoaprendizaje de usuariosMinimiza errores de interaccin de usuarios con aplicaciones.

Documentacin en HTML.- Su aparicin oficial fue el 7 de febrero de 1996 en Seattle.Acceso universal, distribucin de documento.

WorldWideWeb.- Primer navegador web, 1991.

CONVENIOS PARA PONER LLAVES EN UN PROGRAMA

Allmanwhile (x == y){ something(); somethingelse();}Llaves alineadas a la sentencia contenedora.K&R if (some_error) { do_correct(); } else continue_as_usual();Las llaves se colocan alineadas a la sentencia contenedora, sin embargo, en estructuras de control la sentencia se alinea a la llave de cierre.

Bannerfunction1 () { do stuff do more stuff }La ultima llave es alineada a las sentencias contenidas. Y la primer llave incluida en la sentencia contenedora.White Smithfunction some() { if(algo) { something(); } }Llaves alineadas a las sentencias contenidas.

BSD KNFwhile (x == y) { something(); somethingelse();}La primer llave incluida en la sentencia contenedora y la de cierre alineada a la sentencia contenedora.PicoFunction indent(){ Instruccion;}La primer llave incluida en la lnea de la sentencia contenedora. La llave de cierre en la misma lnea que la ultima instruccin;

GNUconcat (char *s1, char *s2){ while (x == y) { something (); somethingelse (); } finalthing ();}Las llaves contenedoras alineadas a la sentencia contenedora.Las llaves encontradas adentro de las contenedoras debern tener espacio de tal manera que queden a la mitad entre la sentencia contenedora y las sentencias contenidasHorstmannwhile (x == y){ something(); somethingelse();}Llaves alineadas a la sentencia contenedora.La primer instruccin contenida deber ir en la misma lnea que la primer llave.

REFACTORIZACION

Refactorizacin.- Es una tcnica de la ingeniera del software para efectuar cambios en la estructura interna de un cdigo sin cambiar su comportamiento externo.

Refactorizacin Pull-Up: Mover un mtodo o variables de una subclase a una superclase.

Refactorizacin Push-down: Mover un mtodo o variables de superclase a una subclase.

ARQUITECTURA DE PROYECTOS DE SOFTWARE

Arquitectura n-Tier : es la distribucin fsica de las capas. Lugar en donde est el cdigo y se ejecutanlos procesos.

Arquitectura n-Layers : es la distribucin lgica de las capas. Es la forma en que est estructurado el cdigo.