FUNDAMENTOS DE LA PRUEBA DE SOFTWARE

Universidad Nacional San Luis Gonzaga Facultad de Ingeniería de Sistemas Pruebas de Software. Alonso Morales Loayza

FUNDAMENTOS DE LA PRUEBA DE SOFTWARE

PRUEBA DE SOFTWARE

Página 1

FUNDAMENTOS DE LA PRUEBA DE SOFTWARE

Fundamento de la Prueba de Software
INTRODUCCIÓN ................................................................................................................................... 5 1. CALIDAD Y EL SOFTWARE ........................................................................................................... 6 1.1. CONCEPTOS BÁSICOS DE CALIDAD...................................................................................... 6 DESDE UNA PERSPECTIVA DE VALOR. ......................................................................... 6 DEFINICIONES FORMALES. .......................................................................................... 6 ORIGEN. ....................................................................................................................... 8 CONCEPTOS. ................................................................................................................ 9 1.1.1. 1.1.2. 1.2. 1.2.1. 1.2.2. 1.3. 2. 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 3. 3.1. 3.2. 4. 4.1. 4.2. 5. 5.1. 5.2.

CALIDAD DE SOFTWARE. ..................................................................................................... 8

ASEGURAMIENTO DE SOFTWARE Y TÉCNICAS ASOCIADAS. ............................................. 10 MODELO DE MCCALL. ....................................................................................................... 12 MODELO DE BOEHM. ........................................................................................................ 13 CMM (CAPABILITY MATURITY MODEL). ............................................................................ 14 ISO (INTERNATIONAL STANDARD ORGANIZATION). ......................................................... 15 PSP (PERSONAL SOFTWARE PROCESS) /TSP (TEAM SOFTWARE PROCESS). ..................... 15 SPICE (SOFTWARE PROCESS IMPROVEMENT AND CAPABILITY DETERMINATION). ......... 16 PEMM (PERFORMANCE ENGINEERING MATURITY MODEL)............................................. 17 TICKIT................................................................................................................................. 18 DEFINICIÓN DE VERIFICACIÓN Y VALIDACIÓN. ................................................................. 19 VALIDACIÓN Y VERIFICACIÓN EN EL CICLO DE VIDA ......................................................... 21 OBJETIVOS. ........................................................................................................................ 21 RESTRICCIONES. ................................................................................................................ 22 ESTRATEGIAS DE PRUEBAS DE SOFTWARE ....................................................................... 24 PLAN DE PRUEBAS ............................................................................................................. 24 IDENTIFICADOR DEL PLAN. ........................................................................................ 24 ALCANCE .................................................................................................................... 24 ÍTEMS A PROBAR ....................................................................................................... 24 ESTRATEGIA ............................................................................................................... 24 CATEGORIZACIÓN DE LA CONFIGURACIÓN............................................................... 25

MODELOS DE CALIDAD DE SOFTWARE .................................................................................... 12

DEFINICIÓN DE VERIFICACIÓN Y VALIDACIÓN.......................................................................... 19

OBJETIVOS Y RESTRICCIONES ................................................................................................... 21

PLANIFICACIÓN ......................................................................................................................... 23

5.2.1. 5.2.2. 5.2.3. 5.2.4. 5.2.5.

PRUEBA DE SOFTWARE

Página 2

..... 34 PRUEBA DE LA INTEGRACIÓN ............... 31 FUNCIÓN DEL SOFTWARE.................................................................................... 6.............................................................. 31 EXPECTATIVAS DEL USUARIO............2......................................... 31 PLANIFICACIÓN DE V &V ...... 7............. 6....2................................. 30 7.......3............. 35 PRUEBA DE ACEPTACIÓN DE USUARIO ..... . 34 DISEÑO DEL MÓDULO ...........................4........................2................................2............10.............................................................................................. 34 PRUEBA DE LA UNIDAD ..................... 5......................... 7.................................................................... 33 DISEÑO DE LA ARQUITECTURA........1.. 7................................................6......................7.............................................................................. 33 DISEÑO DEL SISTEMA ... 29 EL PROCESO V & V .....................................................8.............................................................................7..................................1.....................................8............................5................ 26 RESPONSABLES ..........1........................ 7............................ 6......... ........ 25 PROCEDIMIENTOS ESPECIALES .................................................................................... 26 ¿QUÉ SON LAS MÉTRICAS DE SOFTWARE? ..... 7... 28 MÉTRICAS DEL SOFTWARE ............................ 6.... 7................. 7.................................................... 5....................................... 25 CALENDARIO......................................................................7............................3.....................6......................................................... 26 METTRICAS Y MEDICIONES....................................8...3............................. 7...............2..............................7.... 5................ 7.................................7.................................... 6..3............................... VERIFICACIÓN DINÁMICA Y ESTÁTICA....... FASES DE LA VALIDACIÓN............................................................................ 26 DEFINICION.................................. .........8............... 7.........2................................... 7.......... 26 PROCESO DE MEDICION: ..............2....5.......................... 32 EL MODELO-V DE DESARROLLO ..................FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 5.................................................................... 7...................................................................3....................... 35 7.................. 27 ACTIVIDADES DE LAS METRICAS DE SOFTWARE.. 7........... ..6..............1............... 5.......................................................................... 7..................................11................................................................. 31 CONFIANZA DE LA V&V ....... 7.... 26 MANEJO DE RIESGOS..2.....2.............4.......................................................................7.. 7............................................................................... 5...................................................... 31 ENTORNO DE MARKETING........ 7........3.........4....................3....................8......... 7............................................... 6...................................8....................................................................... 30 METAS DE LA V&V ...9................. 33 ANÁLISIS DE REQUISITOS ................................................. 28 DIFERENTES ENFOQUES DE MÉTRICAS ................................................................... 34 PRUEBA DE SOFTWARE Página 3 ........................ TANGIBLES .. 34 PRUEBA DEL SISTEMA ..........7................................... 6.......1......................3..................... 6........... 25 RECURSOS..................4.....................2.. 27 CLASIFICACIÓN DE MÉTRICAS .. 32 FASE DE LA VERIFICACIÓN .........2. ........ 31 V4V EN EL PROCESO DE DESARROLLO DE SOFTWARE ..............................................

.................................................FUNDAMENTOS DE LA PRUEBA DE SOFTWARE CONCLUSIONES ................... 38 PRUEBA DE SOFTWARE Página 4 ................... 36 REFERENCIAS ................................................................................................................................................................................

Microsoft y otras. implementación y la ejecución de pruebas de software no son tareas triviales. puesto que exigen la aplicación de estrategias y técnicas formales que permitan desarrollar pruebas adecuadas para medir efectivamente la calidad del producto. El diseño. A través de los años. están conscientes de esto y dedican cada vez un mayor número de recursos a las áreas de aseguramiento de la calidad para sus proyectos de software. Las empresas más grandes y experimentadas en desarrollo de software. nos hemos dado cuenta de que no es posible crear sistemas grandes y complejos sin seguir un proceso definido que organice nuestro trabajo: la ingeniería de software. además de tener la perspectiva del usuario final.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE INTRODUCCIÓN El software es un producto abstracto de la mente humana. Los ingenieros de pruebas de software cuentan con habilidades técnicas y desarrollan en mayor medida la creatividad y la atención al detalle. tales como IBM. muchas veces equiparando o incluso superando los recursos destinados al desarrollo. De igual forma. la experiencia nos ha mostrado que para entregar sistemas correctos y que satisfagan las necesidades de nuestros clientes es necesario probar nuestro software. PRUEBA DE SOFTWARE Página 5 .

1. 1. La calidad significa aportar valor al cliente. DEFINICIONES FORMALES. También. ISO 9000: Calidad: grado en el que un conjunto de características inherentes cumple con los requisitos.1.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 1. Estas mejoras son tomadas en cuenta dada la necesidad de obtener productos (software) de mejor calidad. CONCEPTOS BÁSICOS DE CALIDAD. 1.2.1. CALIDAD Y EL SOFTWARE Con el paso de los años se han ido inventando nuevas formas de mejorar los sistemas. la calidad se refiere a minimizar las pérdidas que un producto pueda causar a la sociedad humana mostrando cierto interés por parte de la empresa a mantener la satisfacción del cliente. esto es. DESDE UNA PERSPECTIVA DE VALOR.1. ofrecer unas condiciones de uso del producto o servicio superiores a las que el cliente espera recibir y a un precio accesible. 1. PRUEBA DE SOFTWARE Página 6 . ISO 8042:1994: Conjunto de propiedades y de características de un producto o servicio que le confieren capacidad para satisfacer necesidades expresadas o implícitas.

Walter A. Genichi Taguchi: Calidad es la pérdida (monetaria) que el producto o servicio ocasiona a la sociedad desde que es expedido. Philip Crosby: Calidad es cumplimiento de requisitos. Feigenbaum: Satisfacción de las expectativas del cliente. mejor o peor que las restantes de su especie.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE Luis Andres Arnauda Sequera Define la norma ISO 9000 Conjunto de normas y directrices de calidad que se deben llevar a cabo en un proceso. Shewhart: La calidad como resultado de la interacción de dos dimensiones: dimensión subjetiva (lo que el cliente quiere) y dimensión objetiva (lo que se ofrece). Joseph Juran: Calidad es adecuación al uso del cliente. PRUEBA DE SOFTWARE Página 7 . Armand V. William Edwards Deming: Calidad es satisfacción del cliente. Real Academia de la Lengua Española: Propiedad o conjunto de propiedades inherentes a una cosa que permiten apreciarla como igual.

1. y de los procesos utilizados en su desarrollo. Consecuentemente con el crecimiento en la complejidad del software. concentraron así sus esfuerzos en definir modelos centrados en la calidad de procesos de ingeniería de software e indujeron a adoptarlos como estándares que permitieran enmarcar un proceso de desarrollo de software en un determinado nivel de "madurez". e incrementar a través de ellos la calidad del mismo y disminuir los riesgos que afecten al resultado final. pone énfasis en conceptos como la gestión de calidad PRUEBA DE SOFTWARE Página 8 . y los organismos e instituciones académicas trabajaron en la definición de modelos conceptuales que cumplieran con la demanda de software de calidad. Para el aseguramiento de la Calidad del Software.2. En general. ADA Software Factory desarrolló un Modelo Integral de Calidad de Software.2. El proceso de desarrollo de software a lo largo de los años ha adquirido un grado de profesionalismo característico de la ingeniería. 1. Mientras que el segundo concepto permite certificar para así garantizar la calidad del modelo empleado como directriz del proceso de desarrollo de software. Un concepto importante a tener en cuenta es la diferencia entre la calidad y validez de un producto de software entregado al cliente. se manifestaron entornos y clientes cada vez más exigentes en materia de calidad. Esta situación demandó la necesidad de contar con procesos seguros para el desarrollo del software. usabilidad. ORIGEN. funcionalidad. CALIDAD DE SOFTWARE. versus la calidad del proceso de desarrollo de software que dio origen a dicho producto. El primero de los conceptos responde al grado de cumplimiento de la solución entregada de acuerdo a los requerimientos y expectativas que se tiene en cuanto a rendimiento. Para conseguirlo. tareas. etc. Gran parte de este profesionalismo se debe a la madurez adquirida por la Ingeniería de Software y la creciente complejidad de los sistemas de software. siendo éste un conjunto de actividades. El aseguramiento de la Calidad del Software (SQA. métodos y procedimientos que indican las pautas a conservarse y respetarse a efectos de generar un producto final de calidad. Este modelo de calidad pretende mejorar la calidad del software a través de la optimización de las propiedades de los productos resultantes. Software Quality Assurance) es una actividad de protección que se aplica durante todo el ciclo de vida del software. cumplimiento de objetivos funcionales y económicos. que se basa en estándares de tecnología informática y administración de proyectos ampliamente reconocidos.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 1.

la implementación de procesos repetibles. También se puede definir como la coordinación. porque el hardware se puede reemplazar la pieza. También se debe tener en cuenta que en el mantenimiento de hardware es muy diferente al de software.2. el sistema de seguridad y confiabilidad. la recopilación de datos estadísticos sobre los elementos integrantes de un proyecto. integrando la velocidad de respuesta de la aplicación. CONCEPTOS. La calidad del software es aquel proceso en donde se verifica que el software o aplicación cumpla con los requerimientos o necesidades del cliente.2. con los estándares de desarrollo explícitamente documentados y con las características implícitas que se esperan de todo software desarrollado profesionalmente. integridad y la aplicación de los estándares que tiene que ver con la correcta funcionabilidad y desarrollo de una aplicación. mientras el software requiere de ingeniería. Es la concordancia con los requerimientos funcionales y de rendimiento explícitamente establecidos. 1. La idea clave es "las herramientas y las plataformas cambian de forma continua.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE de productos y procesos. Pero siempre se puede medir la calidad de un producto de software y siempre se puede usar el mismo proceso si éste está bien definido y se sabe utilizar de forma adecuada". PRUEBA DE SOFTWARE Página 9 . y el trabajo a nivel de proceso. el software no se deteriora con el tiempo pues su curva de fallos es muy diferente a la de hardware.

Este aseguramiento se debe diseñar para PRUEBA DE SOFTWARE Página 10 . (IEEE 610/1990) “Concordancia del software producido con los requerimientos explícitamente establecidos. ASEGURAMIENTO DE SOFTWARE Y TÉCNICAS ASOCIADAS. El aseguramiento de calidad del software es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza adecuada en que el producto (software) satisfacerá los requisitos dados de calidad. Existen requerimientos implícitos que no se mencionan. (Pressman. “Es el grado con el que un sistema. 2006). Los estándares específicos definen un conjunto de criterios de desarrollo que guían la forma de aplicación de la ingeniería de software. El Aseguramiento pretende dar confianza en que el producto tiene calidad.3.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE Existen 3 puntos importantes de la definición de calidad de software:    Los requerimientos del software son los fundamentos desde los que se mide la calidad. con los estándares de desarrollo prefijados y con los requerimientos implícitos no establecidos formalmente que desea el usuario”. componente o proceso cumple con los requerimientos y las necesidades o expectativas del cliente o usuario”. 1.

PRUEBA DE SOFTWARE Página 11 .FUNDAMENTOS DE LA PRUEBA DE SOFTWARE cada aplicación antes de comenzar a desarrollarlo y no durante su ejecución. Este es el papel del aseguramiento de la calidad del software”. de manera que puedan eliminar defectos cuanto antes. Verificación y validación del software a lo largo del ciclo de vida. Revisiones del software que se aplican durante cada paso del desarrollo del mismo. “Mientras el software que se está desarrollando reúne los requerimientos y su desempeño sea el esperado. Gestión de configuraciones de software (control de la documentación del software y de los cambios realizados).    Métricas de software para el control del proyecto. Almacenar cualquier inconformidad y reportarla a la gerencia media. La gestión de la configuración del software. El proceso de control de cambios contribuye directamente a la calidad del software. EL ASEGURAMIENTO DE LA CALIDAD DE SOFTWARE COMPRENDE UNA GRAN VARIEDAD DE TAREAS:      Participar en descripción del proyecto de software. en distintas oportunidades durante cada fase del ciclo de vida. es preciso que se supervisen las actividades de desarrollo del software y su rendimiento. Métricas de software para el control del proyecto. Asegurar que las divergencias en el trabajo de software sean documentadas de acuerdo a los estándares definidos. Verificación y validación del software a lo largo del ciclo de vida (Incluye las pruebas y los procesos de revisión e inspección).   TÉCNICAS ASOCIADAS AL ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE. Las técnicas de revisión de los productos software y las pruebas están fundamentalmente orientadas a la detección de defectos en el SW que a la evaluación de aspectos orientados a la calidad.

Las empresas de desarrollo de software de nuestro país en su mayoría son micro y pequeñas empresas.1. MODELOS DE CALIDAD DE SOFTWARE En un mercado globalizado donde las empresas deben innovar y mejorar continuamente para crecer y ser más competitivas. PRUEBA DE SOFTWARE Página 12 . Estos atributos se denominan factores de calidad y son normalmente atributos externos. Las certificaciones de calidad en la industria del software ayudan a las empresas a ser más productivas disminuyendo costos y tiempo en sus desarrollos. algunos criterios de calidad son atributos internos según McCall que el atributo interno tiene un efecto directo en el atributo externo correspondiente. El modelo de McCall fue el primero en ser presentado en 1977 y se origino motivado por Air Forcé y Dod. 2.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 2. los factores de calidad son demasiados abstractos para ser medidos directamente. McCall propone tres perspectivas para agrupar los factores de calidad:  REVISIÓN DEL PRODUCTO HABILIDAD PARA SER CAMBIADO. MODELO DE MCCALL. pero también se incluyen algunos atributos posiblemente internos. es necesario tener acceso a certificaciones de calidad internacionales que les den un respaldo y puedan mantenerse en este mercado. y para este tipo de empresas existe una certificación internacional. por lo que por cada uno de ellos se introduce atributos de bajo nivel denominados criterios de calidad. Se focaliza en el producto final identificando atributos claves desde el punto de vista del usuario.

Esfuerzo requerido para localizar y corregir fallas. Protección del programa y sus datos de accesos no autorizados. 2.  OPERACIÓN DEL PRODUCTO CARACTERÍSTICAS DE OPERACIÓN. Facilidad para realizar el testing. Interoperabilidad esfuerzo requerido para acoplar el producto con otros sistemas. cada una de las cuales contribuye al nivel general de calidad. Facilidad de realizar cambios.2. características de nivel intermedio y características primitivas. La transición del producto incluye los siguientes factores de calidad:    Portabilidad esfuerzo requerido para transferir entre distintos ambientes de operación. Reusabilidad facilidad de reusar el software en diferentes contextos. Testeabilidad. Flexibilidad. Las características de alto nivel representan requerimientos generales de uso pueden ser:    Utilidad per-se cuan (usable. Mantenibilidad cuan fácil es modificarlo. La habilidad del producto de responder ante situaciones no esperadas. entenderlos y retestearlo. Confiabilidad. Facilidad de operación del producto por parte de los usuarios. El grado en el que el producto cumple con su especificación.  TRANSICIÓN DEL PRODUCTO ADAPTABILIDAD AL NUEVO AMBIENTE.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE La revisión del producto incluye los siguientes factores de calidad:    Mantenibilidad. Integridad. La operación del producto incluye los siguientes factores de calidad:      Correctitud. PRUEBA DE SOFTWARE Página 13 . para asegurarse que el producto no tiene errores y cumple con la especificación. El segundo modelo de calidad más conocido es presentado por Barry Boehm en 1978. El uso de los recursos tales como tiempo de ejecución y memoria de ejecución. Este modelo introduce características de alto nivel. eficiente) es el producto en sí mismo. MODELO DE BOEHM. Eficiencia. confiable. Utilidad general si puede seguir usándose si se cambia el ambiente. Usabilidad.

PRUEBA DE SOFTWARE Página 14 . generando así un conjunto de prácticas importantes que deben ser implantadas por cualquier entidad que desarrolla o mantiene software.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE Criterio correctitud integridad eficiencia testeabilidad flexibilidad portabilidad modificab. validez McCall + + + + + Boehm + + + + + + + 2. reusabilidad claridad document. El modelo de madurez de procesos fue generado a través de la experiencia colectiva de los proyectos más exitosos de software. CMM (CAPABILITY MATURITY MODEL). identificar los niveles a través de los cuales una organización debe formarse para establecer una cultura de excelencia en la ingeniería de software.3. Interoperab. entendib. McCall + + + + + + Boehm + + + + + + + Criterio confiabilidad usabilidad mantenim. El CMM tiene como objetivo evaluar los procesos en sus distintos niveles de madurez.

modelos de ciclos de vida. PSP (PERSONAL SOFTWARE PROCESS) /TSP (TEAM SOFTWARE PROCESS).5. Identifica todos los aspectos que deberían ser tratados y es independiente de la tecnología. 2.4. PRUEBA DE SOFTWARE Página 15 . procesos de desarrollo y estructuras organizacionales. desarrollo. especifica los requisitos para un sistema de gestión de la calidad cuando una organización necesita demostrar su capacidad de proporcionar de forma coherente productos que satisfagan los requisitos del cliente y aspira a aumentar su satisfacción a través de la aplicación eficaz del sistema. ISO (INTERNATIONAL STANDARD ORGANIZATION).FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 2. operación y mantenimiento de software y sus servicios relacionados. La norma ISO/IEC 9003 proporciona una guía necesaria en las organizaciones para la aplicación de la ISO 9001 a la adquisición de suministro. incluyendo los procesos para la mejora continua del sistema y el aseguramiento de la conformidad con los requisitos y de acuerdo a las reglamentaciones existentes. La norma ISO 9001.

apoya en que los proveedores de software tengan que someterse a una sola evaluación para aspirar a nuevos negocios y busca que las organizaciones de software dispongan de una herramienta universalmente reconocida para dar soporte a su programa de mejoramiento continuo. SPICE (SOFTWARE PROCESS IMPROVEMENT AND CAPABILITY DETERMINATION).FUNDAMENTOS DE LA PRUEBA DE SOFTWARE El PSP es una tecnología que tiene como justificación la premisa de que la calidad de software depende del trabajo de cada uno de los ingenieros de software y de aquí que el proceso diseñado debe ayudar a controlar. El objetivo de PSP es lograr una mejor planeación del trabajo. La instrumentación de esta tecnología consiste en lo que se denomina “evolución del PSP”. SPICE fomenta productos de calidad. promueve la optimización de procesos y facilita la evaluación del producto a través de los procesos de desarrollo.6. SPICE tiene diversos alcances. El TSP se concentra en los aspectos del desarrollo de software realizado por equipos de trabajo. manejar y mejorar el trabajo de los ingenieros. 2. El SPICE es un modelo de madurez de procesos internacional. definiendo aspectos como la asignación y control de tareas para los diversos miembros del equipo. PRUEBA DE SOFTWARE Página 16 . medir la calidad de productos y mejorar las técnicas para su desarrollo. se aplica tanto a nivel directivo como a nivel de usuarios para asegurar que el proceso se encuentra alineado con las necesidades del negocio. conocer con precisión el desempeño.

Al igual que SPICE se apoya en el modelo de madurez de capacidades CMM. PRUEBA DE SOFTWARE Página 17 . El objetivo de PEMM es poder evaluar la Ejecución de la Ingeniería así como la integración del proceso. aplicación. PEMM (PERFORMANCE ENGINEERING MATURITY MODEL). llamado ingeniería de la ejecución del modelo de madurez. ejecución y diseño.7.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 2. El modelo sirve tanto para evaluar una organización como los propios desarrollos de procesos tecnológicos específicos. Sirve también para definir el criterio al escoger un proveedor de software para los productos críticos o semi-críticos de la compañía. El PEMM presenta un modelo para evaluar los niveles de integración.

TickIt es primordialmente una guía que presenta las estrategias para lograr la certificación en la producción de software a través de la interpretación de los estándares ISO.8. Desarrollado por el Departamento de Comercio e Industria del Reino Unido. TICKIT. PRUEBA DE SOFTWARE Página 18 . Los objetivos principales de TickIt son. surge por la poca adopción de las normas internacionales de calidad ISO 9000 para el área de desarrollo de software.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 2. además de desarrollar un sistema de certificación aceptable en el mercado. dando la dirección y guías necesarias para tal efecto. estimular a los desarrolladores de software a implementar sistemas de calidad.

La validación y la verificación son procesos de evaluación de productos que son útiles para determinar si se satisfacen las necesidades del negocio y si se están construyendo acorde a las especificaciones. Existen distintos modelos de ciclo de vida que se han desarrollado para conseguir diferentes objetivos. El proceso de desarrollo adoptado por un proyecto dependerá de los objetivos y metas que tenga el proyecto. PRUEBA DE SOFTWARE Página 19 . Este tipo de comprobaciones a lo largo del ciclo de vida incluyen dos actividades: la verificación y la validación. DEFINICIÓN DE VERIFICACIÓN Y VALIDACIÓN. donde se decide si está o no preparado para pasar a la siguiente fase. Al final de cada fase del ciclo de vida debería comprobarse que el trabajo realizado hasta ese momento cumple con todos los objetivos previstos.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 3. pero en cualquiera de ellos será necesario un proceso que asegure la calidad a través de todo el ciclo de vida de desarrollo del producto. Este es el punto clave. será más eficiente corregirlos que si se descubriesen en etapas más avanzadas. en el que tiene lugar la evaluación del producto.1. DEFINICIÓN DE VERIFICACIÓN Y VALIDACIÓN 3. si hay errores y son detectados. De esta forma.

FUNDAMENTOS DE LA PRUEBA DE SOFTWARE La verificación y la validación no son lo mismo. por lo que las compañías deben invertir más esfuerzo en llevar a cabo las actividades de verificación y validación. El nivel de confianza requerido depende de:  El propósito o función del sistema. La validación. Por ejemplo. El nivel de confianza necesario depende de lo crítico que sea el software para una organización. el nivel de confianza del software que se utiliza para controlar un sistema de seguridad crítico es mucho más alto que el requerido para un prototipo de un sistema software que ha sido desarrollado para demostrar nuevas ideas. debido a que quiere ser el primero en el mercado.   PRUEBA DE SOFTWARE Página 20 . Sin embargo. el precio que sus clientes están dispuestos a pagar por el sistema y los plazos requeridos para entregar dicho sistema.Validación: “¿Se está construyendo el producto correcto?” El papel de la verificación implica comprobar que el software está de acuerdo con su especificación. aunque a menudo se confunden. Actualmente es menos aceptable entregar sistemas no fiables. Debería comprobarse que satisface sus requisitos funcionales y no funcionales. El objetivo último del proceso de verificación y validación es comprobar que el sistema está hecho para un propósito. tiene como objetivo asegurar que el sistema satisface las expectativas del cliente. Una reflexión lamentable sobre la industria del software es que a muchos usuarios no les sorprende cuando su software falla durante su uso. Las expectativas del usuario. Todos estos factores pueden considerarse cuando se decide cuánto esfuerzo debería invertirse en el proceso de validación y verificación. la tolerancia de los usuarios a los fallos de los sistemas está decreciendo en los últimos años. ya que las especificaciones del sistema no siempre reflejan los deseos o necesidades reales de los usuarios y los propietarios del sistema. pueden estar dispuestos a tolerar más defectos en él. Entorno de mercado actual. Cuando una compañía tiene pocos competidores. Cuando los clientes no están dispuestos a pagar precios altos por el software. sin embargo. puede decidir entregar un programa antes de que haya sido completamente probado y depurado. Cuando un sistema se comercializa. Están dispuestos a aceptar estos fallos del sistema cuando los beneficios de su uso son mayores que sus desventajas.Verificación: “¿Se está construyendo el producto de la manera correcta?” . Esto significa que el sistema debe ser lo suficientemente bueno para su uso previsto. Va más allá de la comprobación de que el sistema satisface su especificación para demostrar que el software hace lo que el cliente espera que haga. Boehm expresó la diferencia entre ellas de la siguiente manera: . los vendedores del sistema deben tener en cuenta los programas competidores.

El proceso de pruebas de software tiene 2 objetivos distintos: a. OBJETIVOS. Es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software. El modelo en cascada es un modelo tradicional. y controlar los costes de los procesos de validación y verificación. Existen distintos modelos que representan el ciclo de vida del producto. VALIDACIÓN Y VERIFICACIÓN EN EL CICLO DE VIDA La validación y la verificación son procesos costosos y para algunos sistemas. pero existen otros modelos que se ajustan mejor a los proyectos actuales y que se explican a continuación. Es necesario que haya una planificación cuidadosa para obtener el máximo provecho de las inspecciones y pruebas. de forma que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. más de la mitad del presupuesto para el desarrollo del sistema puede invertirse en ambos procesos. con la ayuda de los modelos de ciclo de vida. Dicha planificación debería comenzar en etapas tempranas del proceso de desarrollo. tales como los sistemas de tiempo real con complejas restricciones no funcionales. lo que supone un coste muy elevado en la corrección de defectos. PRUEBA DE SOFTWARE Página 21 . como se verá. OBJETIVOS Y RESTRICCIONES 4.1. 4. El modelo en cascada es uno de los más sencillos en cuanto a su diseño.2. En este modelo. Para demostrar al desarrollador y al cliente que el software satisface sus requerimientos. las pruebas se realizan al final del ciclo de vida del proyecto por lo que los defectos son detectados cerca de la fecha de implementación del producto o sistema.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 3.

una prueba con éxito es aquella que muestra un defecto que hace que el sistema funciona incorrectamente. La prueba de defectos está relacionada con la eliminación de todos los tipos de comportamientos del sistema no deseables. significa que debería haber pruebas para todas las características del sistema que se incorporaran en la entrega del producto. Este objetivo conduce a las pruebas de validación. tales como:    Caídas del sistema. PRUEBA DE SOFTWARE Página 22 . Pueden tener una fase de pruebas de aceptación explicita en la que el cliente comprueba formalmente que el sistema entregado cumple su especificación. Este objetivo conduce a la prueba de defectos. en las que se espera que el sistema funcione correctamente usando un conjunto determinado de casos de prueba que reflejan el uso esperado de aquel. Para las pruebas de defectos. Los casos de prueba pueden ser deliberadamente oscuros y no necesitan reflejar cómo se utiliza normalmente el sistema. en los que los casos de prueba se diseñan para exponer los defectos. 4. Para productos de software genéricos. Para descubrir defectos en el software en que el comportamiento de este es incorrecto. esto significa que debería haber al menos una prueba para cada requerimiento de los documentos de requerimientos del sistema y del usuario. Interacciones no permitidas con otros sistemas.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE   Para el software a medida. Para las pruebas de validación. una prueba con éxito es aquella en la que el sistema funciona correctamente. no deseable o no cumple su especificación. Cálculos incorrectos y corrupción de datos.2. b. RESTRICCIONES.

tal como una política en la que todas las sentencias de los programas deberían ejecutarse al menos una vez. 3. PRUEBA DE SOFTWARE Página 23 .FUNDAMENTOS DE LA PRUEBA DE SOFTWARE Idealmente algunas compañías deberían tener políticas para elegir este subconjunto de pruebas en lugar de dejar esto al equipo de desarrollo. Es un proceso. De forma alternativa. las prácticas. Esto es más que los objetivos y requerimientos del proyecto: significa comprender cómo y por qué funcionan la empresa y el equipo. las filosofías. Estas políticas podrían basarse en políticas generales de pruebas. los procesos. Deberían probarse todas las funciones del sistema a las que se accede a través de menús. 2. Cuando se piensa en su proceso de planificación de pruebas. PLANIFICACIÓN La planificación de pruebas significa tomar su estrategia de prueba y ponerla en acción. todas las funciones deben probarse con datos correctos e incorrectos. Por ejemplo: 1. un sprint o un pequeño proyecto. Deben probarse todas las combinaciones de funciones (por ejemplo. el mismo no deberá iniciarse con un documento. las políticas y las personalidades de aquellos con quienes se trabaja. Lo primero que se debe hacer es comprender el contexto de su empresa o proyecto en particular. las políticas de pruebas pueden basarse en la experiencia de uso del sistema y puede centrarse en probar las características del sistema operacional. 5. formateado de textos) a las que se accede a través del mismo menú. a menudo durante un periodo específico como por ejemplo una iteración. En los puntos del programa en los que el usuario introduce datos. Comprender el contexto es otra manera de decir comprender los valores.

FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 5. ESTRATEGIAS DE PRUEBAS DE SOFTWARE El propósito de esta actividad es delinear y comunicar los detalles del esfuerzo de prueba para un periodo determinado. Un plan de pruebas incluye: 5. PLAN DE PRUEBAS El propósito del plan de pruebas es explicitar el alcance. Iniciar (plan de prueba unitario para el método iniciar de la clase Despachador). Note que puede haber un plan global que explicite el énfasis a realizar sobre los distintos tipos de pruebas (verificación. ÍTEMS A PROBAR Indica la configuración a probar y las condiciones mínimas que debe cumplir para comenzar a aplicarle el plan. TP Global (plan global del proceso de pruebas).2. recursos requeridos. 5. por lo que debe distinguirse adicionalmente la versión y fecha del plan. Preferiblemente de alguna forma mnemónica que permita relacionarlo con su alcance.1. esta sección podría indicar: "Se aplicará la estrategia caja-negra de fronteras de la precondición" o "Ejercicio de los caminos ciclomáticos válidos".2. IDENTIFICADOR DEL PLAN.3. Por un lado.4. calendario. ALCANCE Indica el tipo de prueba y las propiedades/elementos del software a ser probado. es difícil y riesgoso probar una configuración que aún reporta fallas.2. en el caso de pruebas unitarias de un procedimiento. TP-Contr-X (plan de verificación del contrato asociado al evento de sistema X).1.2. TP-Req-Seguridad1 (plan de verificación del requerimiento 1 de seguridad). 5. Como todo artefacto del desarrollo. Esto significa que se desea que la información sea lo más correcta y minuciosa posible.2. si esperamos a que todos los módulos estén perfectos. Por ejemplo. patrón y/o herramientas a utilizarse en el diseño de los casos de prueba. responsables y manejo de riesgos de un proceso de pruebas. integración e integración). puede que detectemos fallas graves demasiado tarde. por ej.2. 5. ESTRATEGIA Describe la técnica. enfoque. está sujeto a control de configuración. En lo posible la PRUEBA DE SOFTWARE Página 24 . 5. TP-Unit-Despachador. por otro lado.

así como cualquier habilidad especial que se requiere. 100% de las fronteras. Al corregirse los defectos. TANGIBLES Explicita los documentos a entregarse al culminar el proceso previsto por el plan p. PRUEBA DE SOFTWARE Página 25 . 5.2. PROCEDIMIENTOS ESPECIALES Identifica el grafo de las tareas necesarias para preparar y ejecutar las pruebas. así como la colocación específica del software a probar (p. También se indican cualquier requerimiento especial del proceso: actualización de licencias. especificación de pruebas. por ej. cualquier otro software necesario para llevar a cabo las pruebas. qué módulos se colocan en qué máquinas de una red local) y la configuración del software de apoyo. casos de prueba. ej. 60% de los caminos ciclomáticos.2.7. ya que puede ser necesario repetir algunas pruebas. La estrategia también explicita el grado de automatización que se exigirá. Subplanes.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE estrategia debe precisar el número mínimo de casos de prueba a diseñar.8. el proceso de prueba previsto por el plan puede continuar. RECURSOS Especifica las propiedades necesarias y deseables del ambiente de prueba. tanto para la generación de casos de prueba como para su ejecución. el software de sistemas (p. el plan debe ser:    Suspendido Repetido Culminado En algunas circunstancias el proceso de prueba debe suspenderse en vista de los defectos o fallas que se han detectado. CATEGORIZACIÓN DE LA CONFIGURACIÓN Explicita las condiciones bajo las cuales. tiempo en la máquina de producción.5.2. seguridad.6. espacio de oficina. resumen gerencial del proceso y bitácora de pruebas. el sistema de operación).. incluyendo las características del hardware. ej. 5. pero debe explicitarse a partir de qué punto. 5. ej..2. 5. La sección incluye un estimado de los recursos humanos necesarios para el proceso.

10. [Fenton´91].2.2. 5. cantidad. 6. DEFINICION. Aunque se han propuesto docenas de métricas o medidas. RESPONSABLES Especifica quién es el responsable de cada una de las tareas previstas en el plan.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 5.1. y por otro lado. ¿QUÉ SON LAS MÉTRICAS DE SOFTWARE? PRUEBA DE SOFTWARE Página 26 . capacidad y tamaño de algunos atributos de un proceso o producto”. MANEJO DE RIESGOS Explicita los riesgos del plan. [LenO. CALENDARIO Esta sección describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de las tareas a realizar. 6. METTRICAS Y MEDICIONES. [Pressman´98].11. La palabra métrica. Muchos investigadores han intentado desarrollar una sola métrica que proporcione una medida completa de la complejidad del software. “MEDIDA “proporciona una indicación cuantitativa de extensión.2. 6. las acciones mitigantes y de contingencia. 5. componente o proceso posee un atributo dado”.Ejiogo´91]. aunque estas tres son distintas.9. cada una de éstas tiene un punto de vista diferente. existe la necesidad de medir y controlar la complejidad del software. dimensiones. es difícil de obtener un solo valor de estas métricas de calidad.2. “LA MEDICIÓN” es el proceso por el cual los números o símbolos son asignados a atributos o entidades en el mundo real tal como son descritos de acuerdo a reglas claramente definidas”. es muy común asociarla con las palabras medición y medida. El IEEE “Standard Glosaryof Software Engering Terms” define como MÉTRICA a “una medida cuantitativa del grado en que un sistema.

4. es por eso que propone un proceso de medición. que. ANÁLISIS: El cálculo de las métricas y la aplicación de herramientas matemáticas. INTERPRETACIÓN: La evaluación de los resultados de las métricas en un esfuerzo por conseguir una visión interna de la calidad de la representación.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE Es la aplicación continua de mediciones basadas en técnicas para el proceso de desarrollo del software y sus productos para suministrar información relevante a tiempo. el cual se puede caracterizar por cinco actividades:      FORMULACIÓN: La obtención de medidas y métricas del software apropiadas para la representación de software en cuestión. Michael [‘99] Las métricas son la maduración de una disciplina. REALIMENTACIÓN: Recomendaciones obtenidas de la interpretación de métricas técnicas trasmitidas al equipo de software. Las métricas de software proveen la información necesaria para la toma de decisiones técnicas. 6. 6. PROCESO DE MEDICION: Ayudar en el diseño de pruebas más efectivas. COLECCIÓN: El mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas. PRUEBA DE SOFTWARE Página 27 . ACTIVIDADES DE LAS METRICAS DE SOFTWARE. según Pressman [’98] van a ayudar a la Evaluación de los modelos de análisis y de diseño.3. así el administrador junto con el empleo de estas técnicas mejorará el proceso y sus productos”.

FUNDAMENTOS DE LA PRUEBA DE SOFTWARE Las métricas de software incluyen otras actividades. estructuración o modularidad. reusabilidad.    6. 6. Ejiogu [‘91]:  MÉTRICAS DE COMPLEJIDAD: Son todas las métricas de software que definen de una u otra forma la medición de la complejidad. Administración por métricas. complejidad de algoritmos computacionales. agregación. Medición de la productividad. y flujo. MÉTRICAS DE DESEMPEÑO: Corresponden a las métricas que miden la conducta de módulos y sistemas de un software. configuración. etc. Estas son los puntos críticos en el diseño. etc. Generalmente tienen que ver con la eficiencia de ejecución. Acumulación de datos. A continuación se muestra una breve clasificación de métricas de software. Realización de modelos y mediciones de la calidad. MÉTRICAS DEL SOFTWARE PRUEBA DE SOFTWARE Página 28 . acoplamiento del módulo. Valoración de las capacidades y de la madurez.6. cohesión del módulo. CLASIFICACIÓN DE MÉTRICAS La clasificación de una métrica de software refleja o describe la conducta del software. anidaciones. mantenimiento. pruebas y mantenimiento. pruebas. tamaño. rapidez. eficiencia y competencia. Evaluación y modelos de desempeño. almacenamiento.5. descritas por LemO. tiempo. bajo la supervisión del sistema operativo o hardware. tales como:         Estimación de costo y el esfuerzo. Tales como exactitud. costo (estimación). Evaluación del método y herramientas. Tales como volumen. MÉTRICAS DE CALIDAD: Son todas las métricas de software que definen de una u otra forma la calidad del software. MÉTRICAS DE COMPETENCIA: Son todas las métricas que intentan valorar o medir las actividades de productividad de los programadores o practicantes con respecto a su certeza. codificación.

Es decir cómo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente. Proporcionan medidas e información sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos. Es por eso que se han definido una serie de atributos que deben acompañar a las métricas efectivas de software. y otras violan las nociones básicas intuitivas de lo que realmente es el software de alta calidad. e. Mide la estructura del sistema. DIFERENTES ENFOQUES DE MÉTRICAS Se han propuesto cientos de métricas para el software. MÉTRICAS ORIENTADAS AL TAMAÑO. eficiencia. Es decir que tan productivo va a ser el software que voy a diseñar. MÉTRICAS ORIENTADAS A LA PERSONA. b. Son medidas indirectas del software y del proceso por el cual se desarrolla. 6. otras son tan esotéricas que pocos profesionales tienen la esperanza de entenderlas. MÉTRICAS DE PRODUCTIVIDAD. complejidad. Algunas demandan mediciones que son demasiado complejas. por lo tanto la PRUEBA DE SOFTWARE Página 29 .7.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE Son las que están relacionadas con el desarrollo del software como funcionalidad. Es para saber en qué tiempo voy a terminar el software y cuantas personas voy a necesitar. c. a. MÉTRICAS DE CALIDAD: proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. pero no todas proporcionan suficiente soporte práctico para su desarrollo. Se centran en el rendimiento del proceso de la ingeniería del software. En lugar de calcularlas las LDC. MÉTRICAS TÉCNICAS: Se centran en las características de software. MÉTRICAS ORIENTADAS A LA FUNCIÓN. las métricas orientadas a la función se centran en la funcionalidad o utilidad del programa. el cómo está hecho. f. d.

algunas de las métricas usualmente empleadas no cumplen una o dos características. V4V EN EL PROCESO DE DESARROLLO DE SOFTWARE 7. CONSISTENTE EN EL EMPLEO DE UNIDADES Y TAMAÑOS: el cálculo matemático de la métrica debería utilizar medidas que no lleven a extrañas combinaciones de unidades. No obstante que la mayoría de las métricas de software compensan las características anteriores. modelo de diseño o en la propia estructura del programa. UN MECANISMO EFICAZ PARA LA REALIMENTACIÓN DE CALIDAD: la métrica debería suministrar al desarrollador de software información que le lleve a un producto final de superior calidad. La evaluación de si el sistema es útil y utilizable en una situación operacional o no.1. EMPÍRICA E INTUITIVAMENTE PERSUASIVA: la métrica debería satisfacer las nociones intuitivas del ingeniero de software sobre el atributo del producto en cuestión. EL PROCESO V & V Es el proceso de todo un ciclo vital: La V & V debe aplicarse en cada etapa del software.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE métrica obtenida y las medidas que conducen a ello deben cumplir con las siguientes características fundamentales:     SIMPLE Y FÁCIL DE CALCULAR: debería ser relativamente fácil de aprender a obtener la métrica y su cálculo no obligara a un esfuerzo o a una cantidad de tiempo inusuales. PRUEBA DE SOFTWARE Página 30 .   El descubrimiento de defectos en el sistema.  7. Tiene dos objetivos principales. No deberían depender de los caprichos de la sintaxis o semántica del lenguaje de programación. INDEPENDIENTE DEL LENGUAJE DE PROGRAMACIÓN: las métricas deberían apoyarse en el modelo de análisis.

las expectativas del usuario y el entorno de marketing. EXPECTATIVAS DEL USUARIO. Introducir un producto en el mercado pronto puede ser más importante que encontrar defectos en el programa 7. 7. FUNCIÓN DEL SOFTWARE. VERIFICACIÓN DINÁMICA Y ESTÁTICA PRUEBA DE SOFTWARE Página 31 . CONFIANZA DE LA V&V Depende del propósito del sistema. METAS DE LA V&V La verificación y la validación deberían establecer la confianza de que el software es adecuado al propósito.2. 7.3.3. 7. 7.4.3.3.3.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 7. Los usuarios pueden tener bajas expectativas para ciertas clases de software.1. Esto NO significa que esté completamente libre de defectos. Sino que debe ser lo suficientemente bueno para su uso previsto y el tipo de uso determinará el grado de confianza que se necesita.2. El nivel de confianza depende de lo crítico que es el sistema para una organización. ENTORNO DE MARKETING.

  El plan debería identificar el balance entre la verificación estática y las pruebas. La planificación debería comenzar pronto en el proceso de desarrollo. Pueden ser complementadas por documentos basados en herramientas y análisis del código. La planificación trata de definir estándares para el proceso de prueba en lugar de describir pruebas de productos. El sistema se ejecuta con datos de pruebas y se observa su comportamiento operativo.5. PRUEBAS DEL SOFTWARE. Se ocupa de la ejercitación y la observación del comportamiento del producto (verificación dinámica).6.  7. 7.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE PRINCIPAL TÉCNICA V&V  INSPECCIONES DE SOFTWARE. EL MODELO-V DE DESARROLLO PRUEBA DE SOFTWARE Página 32 . PLANIFICACIÓN DE V &V Se requiere una cuidadosa planificación para sacar el máximo de los procesos de inspección y pruebas. Se ocupa del análisis de representaciones estáticas del sistema para describir problemas (verificación estática).

el funcionamiento. no se determina cómo el software será diseñado o construido. los requisitos del sistema propuesto son recogidos analizando las necesidades de los usuarios. FASE DE LA VERIFICACIÓN 7.7. Calculan hacia fuera las posibilidades y las técnicas por las cuales las exigencias del consumidor pueden ser puestas en ejecución. 7. 7. PRUEBA DE SOFTWARE Página 33 . estructuras del menú. Esta fase se refiere sobre establecer lo que tiene que realizarse el sistema ideal.7. En vez de la mudanza abajo de una manera linear. se entrevistan con los usuarios y un documento llamado el documento de las exigencias del consumidor se genera. los requisitos de la seguridad según lo esperado por el usuario. ANÁLISIS DE REQUISITOS En esta fase. El documento de la especificación del software que sirve mientras que un modelo para la fase del desarrollo se genera. El documento de las exigencias del consumidor describirá típicamente el sistema funcional. El V-Modelo demuestra las relaciones entre cada fase del ciclo vital del desarrollo y su fase asociada de prueba.7. Sin embargo. los datos. Este documento contiene la organización general del sistema. físico.2. Generalmente.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE V-MODELO Es a proceso del desarrollo del software cuál se puede presumir para ser la extensión del modelo de la cascada. DISEÑO DEL SISTEMA Los técnicos analizan y entienden el negocio del sistema propuesto estudiando el documento de las exigencias del consumidor. estructuras de datos etc. los pasos de proceso están doblados hacia arriba después de codificación fase. formar la forma de V típica. el interfaz.1.

8. Se hace usando el diseño de la prueba de unidad elaborada durante la fase de diseño del módulo. También verifica que los códigos sean eficientes y tengan estándares de la codificación.8. base de datos tablas.2. El sistema diseñado está quebrado para arriba adentro a unidades más pequeñas o se explica los módulos y cada uno de ellas de modo que el programador pueda comenzar a cifrar directamente.7.8.3. la prueba de la unidad implica la primera etapa de prueba dinámica proceso. 7. los diagramas de la arquitectura. El diseño de prueba de la integración se realiza en esta fase.4. su interfaz relaciones. PRUEBA DE LA UNIDAD En el V-modelo del desarrollo del software. 7. Implica el análisis del código escrito con la intención de eliminar errores. breve funcionalidad de cada módulo. FASES DE LA VALIDACIÓN 7. 7. con todos los elementos. Se hace usando el diseño de la prueba de la integración elaborada durante la fase de diseño de la arquitectura. tecnología detallan el etc. PRUEBA DE SOFTWARE Página 34 . DISEÑO DEL MÓDULO Esta fase se puede también llamar como diseño bajo. incluyendo su tipo y tamaño todos los detalles del interfaz. Las especificaciones del documento o del programa del diseño del nivel bajo contendrán una lógica funcional detallada del módulo. PRUEBA DE LA INTEGRACIÓN En la integración la prueba de los módulos separados será probada junta para exponer averías en interfaces y en la interacción entre los componentes integrados.7.1. DISEÑO DE LA ARQUITECTURA Esta fase se puede también llamar como diseño de alto nivel.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 7. La línea de fondo en seleccionar la arquitectura es que debe realizar todo que consista en típicamente la lista de módulos. adentro pseudocódigo. La prueba está generalmente caja blanca. tablas de la base de datos. La prueba está generalmente caja negra pues el código no se comprueba directamente para saber si hay errores. dependencias.

PRUEBA DEL SISTEMA La prueba del sistema comparará las especificaciones de sistema contra el sistema real.8.3. PRUEBA DE ACEPTACIÓN: Para determinarse si un sistema satisface sus criterios de la aceptación o no.8. PRUEBA DE SOFTWARE Página 35 . Responsabilidades del usuario. PRUEBA DE ACEPTACIÓN DE USUARIO a. La prueba del sistema está a veces automatizado usar las herramientas de prueba. PROCEDIMIENTOS PARA CONDUCIR LA PRUEBA DE ACEPTACIÓN: Defina los criterios de la aceptación:         Requisitos de la funcionalidad y funcionamiento. Descripción de la aceptación. La prueba hecha en esta etapa se llama prueba del sistema. Una vez que se integren todos los módulos varios errores pueden presentarse. El diseño de la prueba del sistema se deriva de los documentos del diseño del sistema y se utiliza en esta fase. b. 7.4. Para probar el software en el “del mundo real” por las audiencias previstas. Requisitos de calidad totales del software.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 7. PROPÓSITO DE LA PRUEBA DE ACEPTACIÓN:  Para verificar el sistema o los cambios según las necesidades originales. Ejecute el plan de prueba de aceptación. Requisitos de calidad del interfaz. Desarrolle un plan de la aceptación: Descripción del proyecto. Para permitir al cliente determinarse si aceptar el sistema o no.

Los testers tienen que considerar el software y las funciones que realiza. El testeo de software es fundamental durante todo el ciclo de producción de las aplicaciones de software. Si el código es difícil de probar. Las pruebas de Software ejecuta el software con el objetivo de establecer si se ajusta a las especificaciones y si se adapta correctamente al ambiente de operación. y el ambiente en el que el software (eventualmente) operará. El desarrollo del testing se ha visto favorecido en ambientes académicos. Por lo tanto. entonces debería considerarse la re-escritura del código.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE CONCLUSIONES    Una aplicación probada reduce el riesgo de errores críticos en producción. sus entradas y como se pueden combinar.    PRUEBA DE SOFTWARE Página 36 . el software testing no solo busca errores. Se requiere traspasar este trabajo académico a ideas más prácticas para su aplicación en el desarrollo de software.

FUNDAMENTOS DE LA PRUEBA DE SOFTWARE PRUEBA DE SOFTWARE Página 37 .

buenastareas.html http://elchrboy.net/loreknelamorena/mtricas-de-proceso-y-proyecto-de-software http://empleo.trovit.pdf http://www.mx/u_dl_a/tales/documentos/lis/gonzalez_d_h/capitulo2.com/2010/03/estrategias-de-pruebas-de-software.willydev.html http://desasof2004.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE REFERENCIAS http://www.html http://catarina.com/ensayos/Verificacion-Y-Validacion-De-Sofware/312349.blogspot.slideshare.buenastareas.com/2009/06/plan-de-pruebas-de-software.html http://www.com/ma/enwiki/es/V-Model_%28software_development%29 PRUEBA DE SOFTWARE Página 38 .php?save_page=%2Fensayos%2FVerificacion-Y-ValidacionDe-Sofware%2F312349.org/blog/que-es-la-calidad-de-software.html http://www.php http://desasof2004.udlap.blogspot.worldlingo.rodolfoquispe.net/descargas/willydev_planeasoftware.es/ofertas-empleo/verificacion-calidad-desarrollo-software http://www.com/2009/06/plan-de-pruebas-de-software.pdf8 http://www.com/login.blogspot.

Sign up to vote on this title
UsefulNot useful