Pruebas Estaticas 1 Principios2 Ciclo de Vida 4 Pruebas Dinamicas 3 Pruebas Estaticas 5 Gestión 6 Herramientas Software Testing ISTQB / ISEB Foundation.

Presentación del tema: "Pruebas Estaticas 1 Principios2 Ciclo de Vida 4 Pruebas Dinamicas 3 Pruebas Estaticas 5 Gestión 6 Herramientas Software Testing ISTQB / ISEB Foundation."— Transcripción de la presentación:

1 Pruebas Estaticas 1 Principios2 Ciclo de Vida 4 Pruebas Dinamicas 3 Pruebas Estaticas 5 Gestión 6 Herramientas Software Testing ISTQB / ISEB Foundation Exam Practice Capitulo 3

2 Contenidos El proceso de prueba y revisiones Tipos de revisión Análisis estático

3 Personas técnicas Individual:  mesa de control, de datos paso a paso, la corrección de pruebas Grupos:  Comentarios (informal y formal): por consenso  Walkthrough: para la educación  Inspección (más formal): encontrar fallas En las técnicas estáticas no se ejecuta código

4 Beneficios de las revisiones Mejora de la productividad de desarrollo Plazos de desarrollo reducido Reducido el tiempo y coste de la prueba Reducción de costos de por vida Reducción de los niveles de fallo Mejora de las relaciones de los clientes etc.

5 Las revisiones son rentables 10 veces es la reducción de fallas gracias a la prueba, las pruebas reducen su costo de 50 a 80 %  Manual de Guías, inspecciones y revisiones técnicas - Freedman y Weinberg reducir fallas en un factor de 10  Tutoriales estructurados - Yourdon

6 La reducción del 25% en las listas fallas, retirar 80-95% de fallas en cada etapa, la reducción de 28 veces en costo del mantenimiento, muchos otros  Inspección de software- Gilb & Graham

7 ¿Qué puede ser inspeccionado? Nada que no este escrito puede ser inspeccionado política, estrategia, planes de negocio, marketing o material publicitario, contratos requisitos del sistema, estudios de viabilidad, planes de pruebas de aceptación casos de prueba, prueba de diseños, planes de pruebas, resultados de la pruebas.

8 Diseños de sistemas, lógico y físico Código del software Manuales de usuario, procedimientos, material de formación

9 ¿Qué se puede revisar? todo aquello que pueda ser inspeccionado  es decir, cualquier cosa escrita planes, visiones, "panorama", orientaciones estratégicas, las ideas el progreso del proyecto  trabajo realizado para el horario, etc.. "Debemos desarrollar esto" opciones de comercialización o marketing

10 Lo que hay que revisar / Inspeccionar? Tests Requirements Design Code Functions Integration T Unit Test Accept. Test System Test

11 Los costos de las revisiones guía básica : 5%-15% del esfuerzo de desarrollo  medio día a la semana es del 10% Efuerzo requerido para la revision  planificación (por el líder / moderador)  preparación / auto-estudio verificación  Reunión  fijación / edición / seguimiento  registro y análisis de las estadísticas / métricas  proceso de mejora(deberia ser!)

12 Contenidos Procesos de Revision y prueba Tipos de Revisiones Analisis Estatico Static testing 12 45 3 6 ISTQB / ISEB Foundation Exam Practice

13 Tipos de revisión de los documentos Revision Informal indocumentados Es ampliamente considerado como útil y barato (pero nadie puede demostrarlo!) Un primer paso útil para las organizaciones caóticas. Revision Técnicas:(revisión por pares) incluye a expertos y técnicos, sin la participación de la gerencia. Normalmente descubrir errores. Puede ser bastante subjetiva.

14 La toma de decisiones en la revisión: El grupo discute un documento y toma una decisión sobre el contenido, por ejemplo, cómo se debería hacer algo, la decisión de ir o no, o comentarios técnicos

15 Tipos de revisión de los documentos Walkthrough El autor guía al grupo a través de un documento y de sus procesos de pensamiento, por lo que todos entendemos lo mismo, el consenso sobre los cambios a realizar Inspecciones: La persona formal y el grupo de control, el uso de fuentes y normas, de acuerdo con las normas genéricas y específicas y listas de verificación, se utilizan criterios de entrada y salida, el líder debe estar capacitado y certificado, en el manejo de las métricas requeridas.

16 Revision en general 1 Objectivos / metas  validación y verificación respecto a las especificaciones y normas  lograr consenso (sin inspección)  Mejora del proceso (ideal, incluido en la inspección)

17 Revision en general 2 Actividades  Planificacion  Resumen / reuniones iniciales (Inspección)  preparación / comprobación individual  reunión de revisión (no siempre)  seguimiento (para algunos tipos)  registro y análisis de métricas (Inspecciones y revisiones)

18 Revision en general 3 Roles y responsabilidades  Líder / moderador - planifica la revisión / inspección, elige a los participantes, ayuda y estimula, dirige la reunión, realiza el seguimiento, gestiona métricas.  Autor del documento inicia la revisión / Inspección

19  Revisores / Inspectores especializados - Diagnóstico-roles para Inspection  Los administradores excluidos de algunos tipos de revisión, necesita planificar el tiempo del proyecto para su revisión / inspección.  Otros: por ejemplo, Inspección / revisión Coordinador

20 Revision en general 4 Entregables  Los cambios (editables) en la revisión del producto  El Cambio de solicitudes de documentos de origen (documentos predecesores a el producto objeto de revisión / Inspeccionado)  Sugerencias para mejorar los procesos al proceso de revisión / inspección al proceso de desarrollo que elabora el producto que acaba de revisar / Inspeccionado  Las Métricas (Inspección y algunos tipos de revisiones)

21 Revision en general 5 Trampas (que no siempre funcionan!)  falta de formación en la técnica (sobre todo de Inspección, el más formal)  o la falta de calidad de la documentación – de lo que está siendo revisado / Inspeccionado

22  La falta de apoyo a la gestión – “ofrecimientos" - quiere que se hagan, pero no dar tiempo a que sucedan en los programas del proyecto  Si no se mejoran los procesos (se desilucionanaran sólo al conseguir o encontrar la misma cosa otra vez)

23 La Inspección es diferente el documento a revisar se da por adelantado Normalmente son decenas de páginas para revisar Las instrucciones son "por favor revise este" no sólo producto, fuentes fragmento o muestra formación, funciones o roles

24 La Inspección es diferente algunas personas tienen tiempo para mirar a través de él y hacer comentarios antes de la reunión (que es difícil de conseguir) la reunión suele durar horas los criterios de entrada a la reunión, puede que no valgan la pena sostenerlos 2 horas máximo, a menudo mucho más corto

25 La Inspección es diferente " No me gusta este “ mucha discusión, algunos enfoques sobre técnicas, algunas trivialidades. realmente no sé si valía la pena, pero seguimos haciendo Las violaciónes de reglas, objetivas, no subjetivas. no hay discusión, muy centrado, anti-trivia sólo lo hacen si se demuestra el valor (continua)

26 La Inspección es más y mejor Entrada critica formacion porcentaje de control óptimo priorizar las palabras estandares Mejora de procesos Salida critica las estimaciones cuantificadas de defectos restantes principales por página revisión típica Inspección temprana Inspección madura eficacia rendimiento de inversión 10 - 20% desconocido 30 - 40%6 - 8 hrs / Insp hr 80 - 95%8 - 30 hrs / Insp hr

27 El proceso de Inspección Etapa de Desarrollo de Software.. Planificación Empezar Ind Chk Cumplir Editar Cambio solicitudes Mejora Procesos Entrada Siguiente Etapa de Desarrollo de Software Salida

28 A primera vista... Aquí está un documento: repase este (o Inspecciónelo)

29 Revisiones: el tiempo y el tamaño determinan la tasa Tiempo Velocidad De chequeo Tamaño 2 horas? 100 paginas? 50 paginas por hora Velocidad De chequeo

30 ¿Revisión "Meticulosa"? La "revisión" ordinaria - encuentra algunos fallos, uno mayor, fijarlos, examinar el documento ya corregido y OK mayor menor

31 Inspección: el tiempo y la tasa de determinar el tamaño Tiempo Velocidad De chequeo Tamaño 2 horas? Optimo: 1 pagina* por hora 2 paginas (es la tasa óptima) Tamaño * 1 pagina = 300 palabras importantes

32 Inspección Rigurosidad La inspección puede encontrar fallas profundas : todos los de ese tipo se pueden corregir pero necesita una tasa de control óptimo

33 Sorpresas en la Inspección Importancia fundamental del Reglamento  democráticamente acordado aplicar  definir temas / fallas Porcentajes de control lentos Criterios de entrada y salida estrictas Tasas de registro rápido Cantidad de responsabilidad al autor

34 Contenidos El proceso de prueba y revisiones Tipos de revisión Análisis estático

35 ¿Qué puede hacer el análisis estático? Recuerde: Las técnicas estáticas no ejecutan el código? Una forma de pruebas automatizadas  comprobar si hay violaciónes de los estandares  comprobar si hay cosas que pueden ser un fallo

36 Descendiente de tecnología de compilación  un compilador analiza estáticamente código y "sabe" mucho de él, por ejemplo, uso de variables, encuentra fallas de sintaxis.  herramientas de análisis estático extienden este conocimiento  puede encontrar el código inalcanzable, las variables no declaradas, los parámetros de tipo erróneas de los procedimientos, las funciones no exigidos y los procedimientos, las violaciones en la declaración de vectores y matrices, etc.

37 Análisis de flujo de datos Este es el estudio de las variables del programa  * variables definidas donde se guarda un valor en ella  variable que se utiliza donde se accede al valor almacenado  variable no está definida antes de que se define o cuando se sale del ámbito * definido no debe confundirse con declarada x = y + z IF a > b THEN read(S) x esta definida, y and z estan en uso a and b estan en uso, S esta definida

38 Fallos de análisis de flujo de datos n := 0 read (x) n := 1 while x > y do begin read (y) write( n*y) x := x - n end Anomalia en el flujo de datos: n es re-definida sin ser utilizada Falla de flujo de datos: y es Usada antes de que se haya Definido (primera vez alrededor del bucle)

39 Análisis de flujo de control Destaca :  nodos que no son accesibles desde el nodo de inicio  bucles infinitos  entradas múltiples a los bucles  si el código está bien estructurado, es decir, reducible  si el código se ajusta a un gramática de diagrama de flujo  Los saltos a etiquetas indefinidos  Las etiquetas no saltaron  La complejidad ciclomática y otras métricas

40 Ejemplo de código inalcanzable Las definiciones de macros (diferente para plataformas, Diferentes el Código corre sobre plataformas distintas) Buffsize: 1000 Mailboxmax: 1000 IF Buffsize < Mailboxmax THEN Error-Exit ENDIF

41 El análisis estatico encuentra en la cluasula THEN inalcanzable, así que marcará un fallo

42 La Complejidad Ciclomática La complejidad ciclomática es una medida de la complejidad de un gráfico de flujo  (y por lo tanto el código que representa la gráfica de flujo) el más complejo es el gráfico de flujo, es mayor la medida se puede calcular más fácilmente como:  complejidad= número de decisiones + 1

43 Qué gráfica de flujo es más compleja? 1 2 3 5 Cuál es la complejidad ciclomática?

44 Gráfico de flujo de control de ejemplo Result = 0 Right = 0 DO WHILE more Questions IF Answer = Correct THEN Right = Right + 1 ENDIF END DO Result = (Right / Questions) IF Result > 60% THEN Print "pass" ELSE Print "fail” ENDIF do ifr=r+1 end init if res pass fail end Pseudo Código:

45 Otras Metricas Estaticas Lineas de Código (LOC) operandos y operadores (Métricas de Halstead) abanico-in & abanico-out niveles que se anidan Llamado a Funciones Metricas orientadas a objeto: profundidad de árbol de herencia, número de métodos, acoplando y cohesión

46 Limitaciones y ventajas Limitaciones:  no puede distinguir código "a prueba de fallos" de los fallos de programación o anomalías (a menudo crea una sobrecarga de mensajes de error falsos)  no ejecute el código, por lo que no están relacionadas con las condiciones de operación Ventajas:  puede encontrar fallas difíciles de "ver“  da la evaluación de calidad objetiva de código

47 Sumario: Puntos Claves Las opiniones ayudan a encontrar fallas en el desarrollo y documentación de las pruebas, y deben aplicarse principios o lineamientos Tipos de review: informal, walkthrough, técnica / evaluación por pares, Inspección El análisis estático puede encontrar fallas y dar información sobre el código sin ejecutarlo