Pruebas de Software Diseño de Casos de Prueba PDF

INGENIERÍA INFORMÁTICA TESTING TEMA: Diseño de Casos de Prueba Ing. David Sánchez Rivero  Todo sistema o aplicación debe ser probado mediante su ejecución controlada antes de ser entregado al cliente. Las pruebas constituyen un método más para poder verificar y validar el...

INGENIERÍA INFORMÁTICA TESTING TEMA: Diseño de Casos de Prueba Ing. David Sánchez Rivero  Todo sistema o aplicación debe ser probado mediante su ejecución controlada antes de ser entregado al cliente. Las pruebas constituyen un método más para poder verificar y validar el software. Las pruebas presentan una interesante anomalía para los ingenieros de software, quienes por naturaleza son personas constructivas. Las pruebas requieren que el desarrollador deseche nociones preconcebidas sobre lo “correcto” del software recién desarrollado y luego trabajen duro para diseñar casos de prueba a fin de “romper” el software. FUNDAMENTOS DE LAS PRUEBAS DEL SOFTWARE La meta de probar es encontrar errores, y una buena prueba es aquella que tiene una alta probabilidad de encontrar uno. Por tanto, un sistema basado en computadora o un producto debe diseñarse e implementarse teniendo en mente la “comprobabilidad”. Al mismo tiempo, las pruebas en sí mismas deben mostrar un conjunto de características que logren la meta de encontrar la mayor cantidad de errores con el mínimo esfuerzo. “La comprobabilidad del software significa simplemente saber con cuánta facilidad puede probarse [un programa de cómputo].” Las siguientes características conducen a software comprobable. Operatividad. “Mientras mejor funcione, más eficientemente puede probarse.” Si un sistema se diseña e implementa teniendo como objetivo la calidad, relativamente pocos errores bloquearán la ejecución de las pruebas, lo que permitirá avanzar en ellas sin interrupciones. Observabilidad. “Lo que ve es lo que prueba.” Las entradas proporcionadas como parte de las pruebas producen distintas salidas. Calidad del Software & Testing 2  Controlabilidad. “Mientras mejor pueda controlar el software, más podrá automatizar y optimizar las pruebas.” Todas las salidas posibles pueden generarse a través de alguna combinación de entradas, y los formatos de E/S son consistentes y estructurados. Descomponibilidad. “Al controlar el ámbito de las pruebas, es posible aislar más rápidamente los problemas y realizar pruebas nuevas y más inteligentes.” El sistema de software se construye a partir de módulos independientes que pueden probarse de manera independiente. Simplicidad. “Mientras haya menos que probar, más rápidamente se le puede probar.” El programa debe mostrar simplicidad funcional (por ejemplo, el conjunto característico es el mínimo necesario para satisfacer los requerimientos); simplicidad estructural (la arquitectura es modular para limitar la propagación de fallos) y simplicidad de código (se adopta un estándar de codificación para facilitar la inspección y el mantenimiento). Estabilidad. “Mientras menos cambios, menos perturbaciones para probar.” Los cambios al software son raros, se controlan cuando ocurren y no invalidan las pruebas existentes. El software se recupera bien de los fallos. Comprensibilidad. “Mientras más información se tenga, se probará con más inteligencia.” El diseño arquitectónico y las dependencias entre componentes internos, externos y compartidos son bien comprendidos. La documentación técnica es accesible al instante, está bien organizada, es específica, detallada y precisa. Los cambios al diseño son comunicados a los examinadores. Pueden usarse estos atributos para desarrollar una configuración de software (es decir, programas, datos y documentos) que sean fáciles de probar. Calidad del Software & Testing 3  Una buena prueba tiene una alta probabilidad de encontrar un error. Para lograr esta meta, el examinador debe comprender el software e intentar desarrollar una imagen mental de cómo puede fallar. De manera ideal, se prueban las clases de fallas. Por ejemplo, una clase de fallas potenciales en una interfaz gráfica de usuario es la falla para reconocer la posición adecuada del ratón. Se diseña entonces un conjunto de pruebas para revisar el ratón con la intención de demostrar un error en el reconocimiento de la posición del ratón. Una buena prueba no es redundante. El tiempo y los recursos de la prueba son limitados. No se trata de realizar una prueba que tenga el mismo propósito que otra. Cada una debe tener un propósito diferente (incluso si es sutilmente diferente). Una buena prueba debe ser “la mejor de la camada”. En un grupo de pruebas que tengan una intención similar, las limitaciones de tiempo y recursos pueden mitigar la ejecución de sólo un subconjunto de dichas pruebas. En tales casos, debe usarse la prueba que tenga la mayor probabilidad de descubrir toda una clase de errores. Una buena prueba no debe ser demasiado simple o demasiado compleja. Aunque en ocasiones es posible combinar una serie de pruebas en un caso de prueba, los efectos colaterales posibles asociados con este enfoque pueden enmascarar errores. En general, cada prueba debe ejecutarse por separado. Calidad del Software & Testing 4  La prueba exhaustiva del software es impracticable, no se pueden probar todas las posibilidades de su funcionamiento incluso en programas pequeños y sencillos. EL objetivo de las pruebas es la detección de defectos en el software. Se trata de una actividad a posteriori, de detección, y no de prevención, de problemas en el software. Las pruebas permiten la rectificación en el software. El descubrimiento de un defecto significa un éxito para la mejora de la calidad. La filosofía más adecuada consiste en planificarlas y diseñarlas de forma sistemática para poder detectar el máximo número y variedad de defectos con el mínimo consumo de esfuerzo y tiempo. Pruebas exhaustivas Considere un programa de 100 líneas en el lenguaje C. Después de alguna declaración básica de datos, el programa contiene dos bucles anidados que se ejecutan de 1 a 20 veces cada uno, dependiendo de las condiciones especificadas en la entrada. Dentro del bucle interior, se requieren cuatro constructores if-then- else. ¡Existen aproximadamente 1014 rutas posibles que pueden ejecutarse en este programa! Para poner este número en perspectiva, suponga que se desarrolló un procesador de prueba mágico (“mágico” porque no existe tal procesador) para realizar pruebas exhaustivas. El procesador puede desarrollar un caso de prueba, ejecutarlo y evaluar los resultados en un milisegundo. Si trabajara 24 horas al día los 365 días del año, el procesador trabajaría durante 3170 años para probar el programa. Esto, sin duda alguna, causaría estragos en la mayoría de los calendarios de desarrollo. Por tanto, es razonable afirmar que la prueba exhaustiva es imposible para sistemas de software grandes. Calidad del Software & Testing 5  Las técnicas de diseño de casos de prueba tienen como objetivo conseguir una confianza aceptable en que se detectarán los defectos existentes, sin necesidad de consumir una cantidad excesiva de recursos. Hay que buscar un equilibrio entre la disponibilidad de recursos y la confianza que aportan los casos de prueba para descubrir los defectos existentes. Ya que no se pueden probar todas las posibilidades de funcionamiento del software, el diseño de pruebas consiste en elegir algunas de ellas que se consideren representativas del resto. La dificultad es saber elegir los casos que se deban ejecutar. Una elección puramente aleatoria no proporciona demasiada confianza en que se puedan detectar todos los defectos existentes. Existen varios enfoques para el diseño de casos de prueba: Enfoque estructural o de caja blanca: se centra en la estructura interna del programa para elegir los casos de prueba. La prueba ideal consistiría en probar todos los posibles caminos de ejecución que puedan trazarse. Enfoque funcional o de caja negra: se estudia la especificación de las funciones, la entrada y la salida, para derivar los casos. La prueba ideal es probar todas las posibles entradas y salidas del programa. Enfoque aleatorio: se utilizan modelos (estadísticos) que representen las posibles entradas al programa para crear, a partir de ellos, los casos de prueba. Calidad del Software & Testing 6  El diseño de casos tiene que basarse en la elección de caminos importantes que ofrezcan una seguridad aceptable en descubrir defectos, se utilizan los criterios de cobertura lógica. Una clasificación de éstos, en función de menor a mayor seguridad, es: Cobertura de sentencias: Se trata de generar los casos de prueba necesarios para que cada sentencia o instrucción del programa se ejecute al menos una vez. Cobertura de decisiones: Cada decisión tiene, por lo menos, un resultado verdadero y, al menos una vez, uno falso. Una ejecución de pruebas que cumple la cobertura de decisiones cumple la anterior. Cobertura de condiciones: Cada condición de cada decisión adopte el valor verdadero, al menos una vez, y el falso, al menos una vez. No podemos asegurar que si se cumple esta cobertura se cumpla necesariamente la anterior. Criterio de decisión/condición: Consiste en exigir el criterio de cobertura de condiciones obligando a que se cumpla el criterio de decisiones. Criterio de condición múltiple: En el caso de que se considere que la evaluación de las condiciones de cada decisión no se realiza de forma simultánea, se descompone cada decisión multicondicional en decisiones unicondicionales y se debe conseguir que todas las posibles combinaciones de resultados de cada condición, en cada decisión, se ejecute al menos una vez. Cada uno de los posibles caminos del programa se debe ejecutar al menos una vez. El camino de pruebas atraviesa como máximo una vez el interior de cada bucle que se encuentre. Los bucles deberían probarse al menos tres veces, una sin entrar en su interior, otra ejecutándolo una vez y otra más ejecutándolo dos veces. Los bucles constituyen el elemento de los programas que genera un mayor número de problemas para la cobertura de caminos. Calidad del Software & Testing 7  La prueba funcional o de caja negra se centra en el estudio de la especificación del software, del análisis de las funciones que debe realizar, de las entradas y de las salidas. La prueba exhaustiva de caja negra es impracticable. Debemos buscar criterios que permitan elegir un subconjunto de casos cuya ejecución aporte una cierta confianza en detectar los posibles defectos del software. Un caso de prueba está bien elegido sí: Reduce el número de otros casos necesarios para que la prueba sea razonable. Esto implica que el caso ejecute el máximo número de posibilidades de entrada diferentes para así reducir el total de casos. Cubre un conjunto extenso de otros casos posibles, indica algo acerca de la ausencia o la presencia de defectos en el conjunto específico de entradas que prueba, así como de otros conjuntos similares. Particiones o clases de equivalencia Las cualidades que definen un buen caso de prueba son: Cada caso debe cubrir el máximo número de entradas. Debe tratarse el dominio de valores de entrada dividido en un número finito de clases de equivalencia. El método de diseño de casos consiste en: Identificación de clases de equivalencia: Identificación de las condiciones de las entradas del programa. Identificar las clases de equivalencia (datos válidos y datos no válidos). Creación de los casos de prueba correspondientes: Asignación de un número único a cada clase de equivalencia. Hasta que todas las clases de equivalencia hayan sido cubiertas por casos de prueba, se tratará de escribir un caso que cubra tantas clases válidas no incorporadas como sea posible. Hasta que todas las clases de equivalencia no válidas hayan sido cubiertas por casos de prueba, escribir un caso para una única clase no valida, sin cubrir. Calidad del Software & Testing 8  Análisis de Valores Límite (AVL) Son casos de prueba que exploran las condiciones límite de un programa. Las situaciones límite son las que se hallan arriba, abajo y en los márgenes de las clases de equivalencia. Se diferencian de las particiones de equivalencia en que: Se requiere la selección de uno o más elementos de manera que los márgenes se sometan a prueba. Consideran también el espacio de salida. Conjetura de errores Se enumera una lisa de equivocaciones que pueden cometer los desarrolladores y de las situaciones propensas a ciertos errores. Después se generan casos de prueba en base a dicha lista. Casos que se pueden presentar: El valor cero es una situación propensa a errores. Si se han de introducir un número variable de valores, probar el caso de no introducir ninguno. Suponer que el programador pudiera haber interpretado algo mal en la especificación. Calidad del Software & Testing 9  Simulamos la entrada habitual del programa creando datos de entrada en la secuencia y con la frecuencia con la que podrían aparecer en la práctica, de forma continua sin parar. Indicando la distribución estadística que siguen las entradas, hacemos que la frecuencia de las entradas sea la apropiada para orientar las pruebas hacia lo que es probable que suceda en la práctica. Calidad del Software & Testing 10  La documentación es necesaria para una buena organización de las pruebas, así como para asegurar su reutilización, que es fundamental para optimizar la eficacia como la eficiencia de las pruebas. Plan de pruebas Su objetivo es señalar el enfoque, los recursos y el esquema de las actividades de prueba, así como los elementos a probar, características, personal responsable y los riesgos asociados. Especificación del diseño de pruebas Su objetivo es especificar los refinamientos necesarios sobre el enfoque general reflejado en el plan e identificar las características que se deben probar con este diseño de pruebas. Especificación de casos de pruebas El objetivo es definir uno de los casos de prueba identificado por una especificación del diseño de las pruebas. Especificación del procedimiento de prueba El objetivo es especificar los pasos para la ejecución de un conjunto de casos de prueba o los pasos utilizados para analizar un elemento software con el propósito de evaluar un conjunto de características del mismo. Calidad del Software & Testing 11  El proceso de pruebas consta de las siguientes fases: 1. Ejecutar las pruebas: Ejecutar las pruebas. Comprobar si ha habido algún fallo en la ejecución. En caso de fallo, pasar a depuración o corrección del código. Ejecutar las nuevas pruebas corregidas. Si no hay fallos, pasar a la comprobación de la terminación de las pruebas. 2. Comprobar si se ha concluido el proceso de prueba: Tras la ejecución, comprobar si se cumplen los criterios de completitud de pruebas descritos en el plan de pruebas. En caso de terminar las pruebas, pasar a la evaluación de los productos probados sobre la base de los resultados obtenidos. En caso de no terminar las pruebas, comprobar la presencia de condiciones anormales en la prueba. Si se dan condiciones anormales, se pasa de nuevo a la evaluación, en caso contrario, se pasa a generar y ejecutar pruebas adicionales. 3. En caso de que hayan terminado, evaluar los resultados. En caso contrario, generar pruebas adicionales. Documentación de la ejecución de pruebas Se pueden distinguir dos grupos principales de documentos: 1. Documentación de entrada, constituida por las especificaciones de los casos de prueba que se van a usar y las especificaciones de los procedimientos de pruebas. 2. Documentación de salida o informes sobre la ejecución. Cada ejecución de pruebas generará dos tipos de documentos: Histórico de pruebas o registro cronológico de la ejecución. Informe de los incidentes ocurridos durante la ejecución. Calidad del Software & Testing 12  Histórico de pruebas El objetivo es la documentación de todos los hechos relevantes ocurridos durante la ejecución de las pruebas. Informe de incidente Su objetivo es documentar cada incidente ocurrido en la prueba y que requiera una posterior investigación. Informe resumen de las pruebas El objetivo es resumir los resultados de las actividades de prueba y aporta una evaluación del software basada en dichos resultados. Depuración Es el proceso de localizar, analizar y corregir los defectos que se sospecha que contiene el software. Suele ser consecuencia de una prueba con éxito. Las consecuencias de la depuración pueden ser: Encontrar la causa del error, analizarla y corregirla. No encontrar la causa y, por tanto, tener que generar nuevos casos de prueba. Las dos principales etapas en la depuración son: Localización del defecto, que conlleva la mayor parte del esfuerzo. Corrección del defecto, efectuando las modificaciones necesarias en el software. Análisis de errores o análisis causal El objetivo es proporcionar información sobre la naturaleza de los defectos, con el fin de informar al personal sobre los errores que comete para que se puedan prevenir en el futuro. Calidad del Software & Testing 13  Dada la definición de prueba, el paso siguiente es determinar si es posible probar un programa para encontrar todos sus errores. En general, no es práctico y más aún es imposible encontrar todos los errores en un programa. Es decir hay imposibilidad de una prueba “completa”. El diseño de pruebas para el software o para otros productos de ingeniería puede requerir tanto esfuerzo como el propio diseño inicial del producto. Sin embargo los ingenieros de software tratan las pruebas como algo sin importancia, desarrollando casos de prueba que “parezcan adecuados” pero que tienen poca garantía de ser completos. “Existe una sola regla para el diseño de casos de prueba: cubrir todas las posibilidades, sin hacer demasiados casos de prueba” [Tsuneo Yamaura]. Para realizar la verificación de un producto, el especialista diseña un conjunto de datos con los que realiza la prueba funcional. La prueba funcional determina si la función que especifica un producto coincide con las funciones implementadas en ese producto. Cualquier producto de ingeniería puede probarse de una de estas dos formas: (1) conociendo la función específica para la que fue diseñado el producto, se pueden llevar a cabo pruebas que demuestren que cada función es completamente operativa y, al mismo tiempo, buscando errores en cada función; (2) conociendo el funcionamiento del producto, se pueden desarrollar pruebas que aseguren que “todas las piezas encajen”, o sea, que la operación interna se ajusta a las especificaciones y que todos los componentes internos se han comprobado de forma adecuada. El primer enfoque de prueba se denomina prueba de caja negra y el segundo, prueba de caja blanca. Calidad del Software & Testing 14  Cuando se considera el software de computadora, la prueba de caja negra se refiere a las pruebas que se llevan a cabo sobre la interfaz del software. O sea, los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce un resultado correcto, así como que la integridad de la información externa se mantiene. Una prueba de caja negra examina algunos aspectos del modelo fundamental del sistema sin tener mucho en cuenta la estructura lógica interna del software. La prueba de caja blanca del software se basa en el minucioso examen de los detalles procedimentales. Se comprueban los caminos lógicos del software proponiendo casos de prueba que ejerciten conjuntos específicos de condiciones y/o bucles. Lo que se tiene que hacer es definir todos los caminos lógicos, desarrollar casos de prueba que los ejerciten y evaluar los resultados, es decir, generar casos de prueba que ejerciten exhaustivamente la lógica del programa. Sin embargo la prueba exhaustiva presenta ciertos problemas logísticos. Incluso para pequeños programas, el número de caminos lógicos posibles puede ser enorme. Sin embargo la prueba de caja blanca no se debe desechar como impracticable. Se pueden elegir y ejercitar una serie de caminos lógicos importantes. Se pueden comprobar las estructuras de datos más importantes para verificar su validez. Se pueden combinar los atributos de la prueba de caja blanca así como los de caja negra, para llegar a un método que valide la interfaz del software y asegure selectivamente que el funcionamiento interno del software es correcto. Calidad del Software & Testing 15  CAJA BLANCA También llamadas lógicas, pretenden examinar la estructura interna del programa; es por eso que se llaman blanca o de cristal porque permiten ver el interior del programa. Es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para obtener los casos de prueba. Mediante los métodos de casos de prueba de caja blanca, el ingeniero de software puede obtener casos de prueba que: (1) garanticen que se ejercita por lo menos una vez todos los caminos independientes de cada módulo; (2) ejerciten todas las decisiones lógicas en sus vertientes verdadera y falsa; (3) ejecuten todos los bucles en sus límites y con sus límites operacionales; y (4) ejerciten las estructuras internas de datos para asegurar su validez. CAJA NEGRA Intentan examinar el comportamiento del programa basándose en las especificaciones de las funciones que debe realizar; por lo que se llaman pruebas del comportamiento y se centran en los requisitos funcionales del software. O sea, la prueba de caja negra permite, al ingeniero de software, obtener conjuntos de condiciones de entrada que ejerciten completamente todos los requisitos funcionales del programa. Aquí no importa ver cómo es el interior del programa, ya que se lo considera una caja negra que no permite la visión de la estructura interna. La prueba de caja negra intenta encontrar errores de las siguientes categorías: (1) funciones incorrectas o ausentes; (2) errores de interfaz; (3) errores de estructura de datos o en accesos a bases de datos externas; (4) errores de rendimiento y (5) errores de inicialización y de terminación. Calidad del Software & Testing 16  Llamada también cobertura lógica o pruebas basadas en la estructura. Se ocupa del grado en que los casos de prueba ejercitan o cubren la lógica (código fuente) del programa. Consiste en recorrer todas las posibles secuencias de sentencias. La prueba perfecta de caja blanca es aquella en que se recorre cada uno de los posibles caminos lógicos en un programa, pero desde el momento en que esto es casi imposible de realizar en un programa con lazos, la prueba completa de secuencias no se considera aquí como una meta posible de lograr. La prueba exhaustiva es impracticable hasta en programas pequeños, es decir, completa al 100 %. Por ejemplo, un programa Fortran con 50 líneas y 25 sentencias IF en serie contiene 33,5 millones de sentencias potenciales (2 posibles salidas: Verdadero y Falso, en 25 sentencias es igual a 225 potenciales secuencias). Esta no es una razón para desechar este tipo de técnicas ya que pueden probarse ciertos caminos o secuencias lógicas importantes, seleccionadas según un criterio de cobertura lógica, que ofrezcan una seguridad aceptable en el descubrimiento de errores. Criterios: 1) Cobertura de sentencias. 2) Cobertura de decisión o de ramificación. 3) Cobertura de condición. 4) Cobertura de decisión/condición. Calidad del Software & Testing 17  La complejidad ciclomática es una medición de software que proporciona una evaluación cuantitativa de la complejidad lógica de un programa. Cuando se usa en el contexto del método de prueba de la ruta básica, el valor calculado por la complejidad ciclomática define el número de rutas independientes del conjunto básico de un programa y le brinda una cota superior para el número de pruebas que debe realizar a fin de asegurar que todos los enunciados se ejecutaron al menos una vez. La complejidad ciclomática tiene fundamentos en la teoría de gráficos y proporciona una medición de software extremadamente útil. La complejidad se calcula en una de tres formas: 1. El número de regiones del gráfico de flujo corresponde a la complejidad ciclomática. 2. La complejidad ciclomática V(G) para un gráfico de flujo G se define como V(G) = E - N + 2 donde E es el número de aristas del gráfico de flujo y N el número de nodos del gráfico de flujo. 3. La complejidad ciclomática V(G) para un gráfico de flujo G también se define como V(G) = P + 1 donde P es el número de nodos predicado contenidos en el gráfico de flujo G. a) Diagrama de Flujo b) Gráfico de Flujo Calidad del Software & Testing 18  En el gráfico de flujo de la figura anterior, la complejidad ciclomática puede calcularse usando cada uno de los algoritmos recién indicados: 1. El gráfico de flujo tiene cuatro regiones. 2. V(G) = 11 aristas - 9 nodos + 2 = 4. 3. V(G) = 3 nodos predicado + 1 = 4. Por tanto, la complejidad ciclomática del gráfico de flujo en la figura anterior es 4. Más importante, el valor para V(G) proporciona una cota superior para el número de rutas independientes que forman el conjunto básico y, por implicación, una cota superior sobre el número de pruebas que deben diseñarse y ejecutarse para garantizar cobertura de todos los enunciados del programa. Calidad del Software & Testing 19  Llamada también prueba producida por los datos o prueba producida por entrada/salida. Aquí se considera el programa como una caja negra, es decir se desentiende del comportamiento y estructura interna del programa. Su interés se dirige a encontrar circunstancias en las cuáles el programa no se comporta de acuerdo a sus especificaciones. Los datos de prueba se preparan de acuerdo a las especificaciones. Para detectar errores de este tipo habría que usar no solamente los datos de entrada válidos sino también todos los datos de entrada posibles. Esto demuestra que la prueba exhaustiva de entrada es imposible e impracticable. Ejemplo: Sumar 2 enteros A y B, de dos dígitos cada uno y cualquier signo implica 40.000 casos. Es decir que hay que considerar (199 x 199) porqué hay que considerar todas las combinaciones de A y B ya que el programa es una caja negra. Debe buscarse el subconjunto de casos con mayor probabilidad de encontrar errores (es decir una prueba razonablemente rigurosa). Las propiedades de un caso bien elegido (para formar el mencionado subconjunto) son: Reduce el número de otros casos, eso implica que el caso invoque el máximo número de condiciones de entrada diferentes para minimizar el número total de casos. Cubre un conjunto extenso de otros casos posibles, dice algo acerca de la ausencia o presencia de errores con respecto al conjunto específico de valores de entrada y también de otros. Las técnicas de caja negra de mayor aplicación son: Particiones de equivalencia. Análisis de Valores Límites (AVL). Conjetura de errores. Calidad del Software & Testing 20  Se basa en las dos propiedades consideradas para definir un caso de prueba bien elegido. Esto es: a) Cada caso debe invocar el mayor número posible de condiciones de entrada diferentes a fin de minimizar el número total de casos necesarios. b) Debe tratarse de partir el dominio de entrada en un número finito de “clases de equivalencia”, en las que las pruebas de un valor representativo de cada clase sea equivalente a la prueba de cualquier valor. Es decir que si un caso de prueba perteneciente a una clase de equivalencia detecta un error, se espera que cualquier otro caso de prueba perteneciente a la misma clase detecte el mismo error. Estas consideraciones forman una metodología de caja negra que se conoce como “partición de equivalencia”. Etapas: El proyecto de caso de prueba por medio de partición de equivalencia se realiza en dos pasos: Identificación de la clase de equivalencia. Definición de los casos de prueba. Identificación de las clases de equivalencia Las clases de equivalencia se identifican tomando cada condición de entrada (usualmente sacada de la especificación) y dividiéndola en dos o más grupos. Para ello se emplea la siguiente tabla: Calidad del Software & Testing 21  Se identifican dos tipos de clases: Clases de equivalencia válidas (que representan entradas válidas al programa). Clases de equivalencias inválidas (que representan todos los otros estados posibles de la condición, valores erróneos de entrada). Se puede recurrir a la tabla anterior o bien a una enumeración en formato de un perfil como: Introducir un número entre 1 y 99 a.1) Casos Válidos a.1.1) Un Nº entre 1 y 99 b.1) Casos Inválidos b.1.1) El cero (0) b.1.2) Un Nº > 99 b.1.3) Nº Negativos b.1.4) Letras y otros símbolos no numéricos Pautas para la definición de clases Si la condición de entrada especifica: 1) Para un “rango” de valores se debe especificar una clase válida y dos clases inválidas. Por ejemplo: Válida 1