Please enable JavaScript.
Coggle requires JavaScript to display documents.
Metricas de testeo para software (Atributos). - Coggle Diagram
Metricas de testeo para software (Atributos).
Métricas de apoyo al progreso
The exit criteria (los criterios de salida)
El exit criteria determina cuando se debe dar una terminación al testing, dependiendo
de la cantidad de errores que se encuentre según el nivel del plan de testing.
Los Criterios de salida Tienen 3 pasos
tasa de descubrimiento de errores en los test de regresión: En caso de que la tasa de errores sea alta indicaría que los arreglos hecho por el equipo de desarrollo están rompiendo las funcionalidades previamente funcionales y creando nuevos errores.
frecuencia de arreglos fallidos: En caso de que haya una frecuencia substancial de fallos marcados como arreglados por los desarrolladores que en realidad no están solucionados.
tasa de detección de fallos: si la tasa de detección de fallas decrece dramáticamente mientras el testeo procede entonces se establece que la mayoría de fallas han sido descubiertas.
Suspension criteria for testing (Criterios de suspensión para la prueba)
Se usa para suspender todo o una parte de la actividad de testeo en los ítems de testing asociados con el plan de testing, una manera de suspender el testing es cuando hay un numero especifico de fallas detectadas durante el testing que impiden el progreso, en tal caso suspender estos testeos ayuda a ahorrar tiempo.
hay ciertas necesidades de entorno requeridas para que el testing avance
Hardware, Communications, Interfaces, Documentacion, Software, Supplies, Personal, Instalaciones
Scope of testing (Alcance de la prueba)
Basicamente Scope of testing ayuda a responder la pregunta acerca de que testear y que no testear incluye que ítems, características, procedimientos, funciones, objetos, racimos y subsistemas
Las siguientes preguntas pueden ayudar el testing scope
Que características serán testeadas y que características serán excluidas?
Cuando empezar y terminar un tipo particular de testing?
el scope of testing es conducido por la misma naturaleza del software que se esta testeando.
Monitoring of testing status (Supervisión del estado de las pruebas)
El monitoreo del estado de las pruebas se discutirá en combinación con un atributo del proceso de diseño de pruebas de software, a saber, el seguimiento del progreso de las pruebas.
Staff productivity (Productividad del personal)
La productividad del personal se discutirá en combinación con el mismo atributo que se identificó en el proceso de diseño de prueba de software.
Tracking of planned and unplanned submittals (Seguimiento de envíos planificados y no planificados)
puede identificar areas potencialmente problematicas en el proceso.
Los envíos planificados son aquellos requeridos para ser enviados de acuerdo a un cronograma, los envíos no planificados son aquellos que deben ser re enviados debido a los problemas con los envíos planificados.
En caso de que cualquiera de estos envios sean incorrectos o incompletos llevara a situaciones donde se requieranreenviar otra vez para que las actividades de testing puedan progreasar.
Soporte métrico para la calidad
Cobertura de las pruebas
Plan de calidad a tomar encuenta
Utilidad
¿Servirá el plan de pruebas para las funciones previstas?
Exactitud
¿Es exacto con respecto a cualquier afirmación de hecho?
Eficacia
¿Utiliza eficazmente los recursos disponibles?
Adaptabilidad
¿Tolerará los cambios razonables y la imprevisibilidad del proyecto?
Claridad
¿Es el plan de pruebas coherente y suficientemente inequívoco?
Usabilidad
¿Es el documento del plan de pruebas conciso, fácil de mantener y está útil?
Conformidad
¿Cumple los requisitos impuestos externamente?
Viabilidad
¿Está dentro de la capacidad de la organización que debe realizarlo?
Eficacia de las pruebas de humo.
grupo de casos de prueba que establecen la estabilidad del sistema
garantía de que el sistema tiene toda la funcionalidad y el rendimiento necesarios.
Algunas Practicas de las pruebas de "Humo"
Las pruebas de humo
se centran en la funcionalidad de alto nivel de la aplicación.
Deben ejercitar el sistema de extremo a extremo, capaz de exponer los principales problemas
Las pruebas que se incluyen en las pruebas de humo cubren las operaciones básicas que se utilizan con más frecuencia.
Por ejemplo, el inicio de sesión, la adición y eliminación de registros.
Las pruebas de humo automatizadas se ejecutan con el software cada vez que se recibe la compilación, garantizando que la funcionalidad principal funciona correctamente.
Cumplimiento de los objetivos del proceso
Estos Objetivos se dividen en niveles
nivel superior
Objetivos generales de la organización
nivel intermedio
los objetivos a nivel de unidad funcional
nivel bajo
Son objetivos de nivel proyecto o personal
Cobertura de las pruebas.
se analizará en combinación con el atributo de integridad de las pruebas, tal y como se identifica en el proceso de diseño de pruebas de software.
Soporte métrico para las tendencias de mejora
Recuento de fallos antes de la prueba.
El recuento de fallos antes de la prueba y el número previsto de fallos se analizarán en combinación con la identificación de áreas que requieren más pruebas.
Número previsto de fallos.
No hay una cantidad exacta de fallos a cometer en un programa solo se espera que un programa no cuente con una gran cantidad de fallos, ya que podria verse afectada la calidad del programador.
Clasificación de fallos
Algoritmos y procesamiento
Condiciones de desbordamiento y subdesbordamiento no comprobadas.
Conversión de un tipo de datos a otro
Ordenación incorrecta de operadores aritméticos
Comparación de tipos de datos inadecuados
Control, lógica y secuencia
Expresión incorrecta de las sentencias case.
Iteraciones incorrectas de los bucles
Rutas omitidas
Tipografía
Errores de sintaxis, es decir, ortografía incorrecta del nombre de una variable.
Inicialización
Declaraciones de inicialización incorrectas.
Flujo de datos
Fallos en las secuencias operativas de los flujos de datos.
Datos
Implementación incorrecta de las estructuras de datos.
Configuración incorrecta de banderas, índices y constantes
Los fallos cuentan con un nivel de severidad
Catastrófica
Pérdida crítica de datos, pérdida crítica de disponibilidad del sistema, pérdida crítica de
seguridad, pérdida crítica de seguridad.
Severa
Defectos con graves consecuencias para el sistema
importante
Un defecto que debe solucionarse y existe una solución.
Menor
Defectos con consecuencias insignificantes
Sin efecto
Defectos triviales
Metric support for cost (Soporte métrico para el costo)
Contiene 4 atributos
necesidades de entrenamiento del grupo de testeo y requerimiento de herramientas.
Requerimientos de los recursos.
Duracion del testeo.
Estimacion de costo del testeo.
Estimación de costo, duración de testing y requisitos de testing
Las estimaciones de costo tienen su uso a través del ciclo de desarrollo del software. soportan la planeación y asignación de recursos, factibilidad de cuando un proyecto puede estar terminado a un precio razonable y en que momento se requerirán los recursos clave.
Algunos de los factores que influencian los estimados de tiempo de testeo son:
La madurez del testing de la organización-
La complejidad de la aplicacion de software bajo testeo-
-El alcance de la prueba(Scope of testing)-
El nivel de habilidad y experiencia de los testers-
La organizacion del equipo de testing-
Métodos de prueba
método de radio de desarrollo(development radio method)
Esta estimación puede ser usada como una base para la estimación de requerimientos de recursos para el esfuerzo de testing. La estimación del numero de personal de testing requerido, basado en el numero de desarrolladores, da una manera sencilla para estimar los requisitos del personal de prueba.
Project staff ratio method(Método de proporción de personal del proyecto):
Hace uso de las metricas historicas calculando el porcentaje de personal de testing sobre los recursos
totales asignados planificados para el proyecto.
Test procedure method (Método de procedimiento de prueba)
Este método usa cuentas como el numero planificado de procedimientos de testing para estimar el numero de horas por persona de testing y el numero de testers requeridos.
Metodo de planificacion de tareas (Task planning method)
En este método los registros históricos del numero de horas de personal para desarrollar las tareas de testing son usadas para estimar el nivel de esfuerzo requerido de un software.
Las metodologías de estimación se categorizan en seis tipos:
Opinión experta-
Usando data de benchmark-
Analogía-
Puntos Proxy-
Modelos personalizados-
Modelos algorítmicos-