P. 1
Fundamentos de La Prueba de Software

Fundamentos de La Prueba de Software

|Views: 18|Likes:

More info:

Published by: Jerson Salguero Pizarro on Oct 08, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

06/01/2015

pdf

text

original

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

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

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

Los ingenieros de pruebas de software cuentan con habilidades técnicas y desarrollan en mayor medida la creatividad y la atención al detalle. El diseño. implementación y la ejecución de pruebas de software no son tareas triviales. Microsoft y otras. A través de los años. puesto que exigen la aplicación de estrategias y técnicas formales que permitan desarrollar pruebas adecuadas para medir efectivamente la calidad del producto. la experiencia nos ha mostrado que para entregar sistemas correctos y que satisfagan las necesidades de nuestros clientes es necesario probar nuestro software. De igual forma. además de tener la perspectiva del usuario final. Las empresas más grandes y experimentadas en desarrollo de software. 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.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE INTRODUCCIÓN El software es un producto abstracto de la mente humana. muchas veces equiparando o incluso superando los recursos destinados al desarrollo. tales como IBM. PRUEBA DE SOFTWARE Página 5 . 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.

1. La calidad significa aportar valor al cliente. 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.1. esto es.1.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 1. ISO 9000: Calidad: grado en el que un conjunto de características inherentes cumple con los requisitos. También. 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. 1. PRUEBA DE SOFTWARE Página 6 .1.1. Estas mejoras son tomadas en cuenta dada la necesidad de obtener productos (software) de mejor calidad. DEFINICIONES FORMALES. DESDE UNA PERSPECTIVA DE VALOR.2. ofrecer unas condiciones de uso del producto o servicio superiores a las que el cliente espera recibir y a un precio accesible. 1. CONCEPTOS BÁSICOS DE CALIDAD.

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. Philip Crosby: Calidad es cumplimiento de requisitos. Armand V. Joseph Juran: Calidad es adecuación al uso del cliente. Genichi Taguchi: Calidad es la pérdida (monetaria) que el producto o servicio ocasiona a la sociedad desde que es expedido. PRUEBA DE SOFTWARE Página 7 . mejor o peor que las restantes de su especie. Walter A. Feigenbaum: Satisfacción de las expectativas del cliente. William Edwards Deming: Calidad es satisfacción del cliente. 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). Real Academia de la Lengua Española: Propiedad o conjunto de propiedades inherentes a una cosa que permiten apreciarla como igual.

se manifestaron entornos y clientes cada vez más exigentes en materia de calidad. y los organismos e instituciones académicas trabajaron en la definición de modelos conceptuales que cumplieran con la demanda de software de calidad. siendo éste un conjunto de actividades. 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. 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. tareas. ORIGEN. Este modelo de calidad pretende mejorar la calidad del software a través de la optimización de las propiedades de los productos resultantes. 1.2. que se basa en estándares de tecnología informática y administración de proyectos ampliamente reconocidos. etc. cumplimiento de objetivos funcionales y económicos.1. pone énfasis en conceptos como la gestión de calidad PRUEBA DE SOFTWARE Página 8 . Esta situación demandó la necesidad de contar con procesos seguros para el desarrollo del software. versus la calidad del proceso de desarrollo de software que dio origen a dicho producto. Para el aseguramiento de la Calidad del Software. usabilidad. Un concepto importante a tener en cuenta es la diferencia entre la calidad y validez de un producto de software entregado al cliente. Para conseguirlo. funcionalidad. El aseguramiento de la Calidad del Software (SQA. 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". Mientras que el segundo concepto permite certificar para así garantizar la calidad del modelo empleado como directriz del proceso de desarrollo de software. e incrementar a través de ellos la calidad del mismo y disminuir los riesgos que afecten al resultado final. En general.2. 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. métodos y procedimientos que indican las pautas a conservarse y respetarse a efectos de generar un producto final de calidad.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 1. ADA Software Factory desarrolló un Modelo Integral de Calidad de Software. CALIDAD DE SOFTWARE. Software Quality Assurance) es una actividad de protección que se aplica durante todo el ciclo de vida del software. y de los procesos utilizados en su desarrollo. Consecuentemente con el crecimiento en la complejidad del software.

Es la concordancia con los requerimientos funcionales y de rendimiento explícitamente establecidos.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE de productos y procesos. porque el hardware se puede reemplazar la pieza. La idea clave es "las herramientas y las plataformas cambian de forma continua. el software no se deteriora con el tiempo pues su curva de fallos es muy diferente a la de hardware. el sistema de seguridad y confiabilidad. la implementación de procesos repetibles. También se puede definir como la coordinación. con los estándares de desarrollo explícitamente documentados y con las características implícitas que se esperan de todo software desarrollado profesionalmente. la recopilación de datos estadísticos sobre los elementos integrantes de un proyecto. También se debe tener en cuenta que en el mantenimiento de hardware es muy diferente al de software.2. CONCEPTOS.2. PRUEBA DE SOFTWARE Página 9 . 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. integrando la velocidad de respuesta de la aplicación. mientras el software requiere de ingeniería. y el trabajo a nivel de proceso. integridad y la aplicación de los estándares que tiene que ver con la correcta funcionabilidad y desarrollo de una aplicación. 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". 1.

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. Existen requerimientos implícitos que no se mencionan.3. “Es el grado con el que un sistema. componente o proceso cumple con los requerimientos y las necesidades o expectativas del cliente o usuario”. (IEEE 610/1990) “Concordancia del software producido con los requerimientos explícitamente establecidos. 1. ASEGURAMIENTO DE SOFTWARE Y TÉCNICAS ASOCIADAS. con los estándares de desarrollo prefijados y con los requerimientos implícitos no establecidos formalmente que desea el usuario”. El Aseguramiento pretende dar confianza en que el producto tiene calidad.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. (Pressman. 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. Este aseguramiento se debe diseñar para PRUEBA DE SOFTWARE Página 10 . 2006).

es preciso que se supervisen las actividades de desarrollo del software y su rendimiento. Revisiones del software que se aplican durante cada paso del desarrollo del mismo. 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. Verificación y validación del software a lo largo del ciclo de vida. “Mientras el software que se está desarrollando reúne los requerimientos y su desempeño sea el esperado. 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).FUNDAMENTOS DE LA PRUEBA DE SOFTWARE cada aplicación antes de comenzar a desarrollarlo y no durante su ejecución. 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. PRUEBA DE SOFTWARE Página 11 . 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. Métricas de software para el control del proyecto.   TÉCNICAS ASOCIADAS AL ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE. Asegurar que las divergencias en el trabajo de software sean documentadas de acuerdo a los estándares definidos. La gestión de la configuración del software. de manera que puedan eliminar defectos cuanto antes. Este es el papel del aseguramiento de la calidad del software”. El proceso de control de cambios contribuye directamente a la calidad del software.

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

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

FUNDAMENTOS DE LA PRUEBA DE SOFTWARE Criterio correctitud integridad eficiencia testeabilidad flexibilidad portabilidad modificab. El modelo de madurez de procesos fue generado a través de la experiencia colectiva de los proyectos más exitosos de software. El CMM tiene como objetivo evaluar los procesos en sus distintos niveles de madurez. validez McCall + + + + + Boehm + + + + + + + 2. McCall + + + + + + Boehm + + + + + + + Criterio confiabilidad usabilidad mantenim. reusabilidad claridad document. 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. PRUEBA DE SOFTWARE Página 14 . entendib.3. generando así un conjunto de prácticas importantes que deben ser implantadas por cualquier entidad que desarrolla o mantiene software. Interoperab.

La norma ISO 9001.4. 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. modelos de ciclos de vida. ISO (INTERNATIONAL STANDARD ORGANIZATION). 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. PRUEBA DE SOFTWARE Página 15 . PSP (PERSONAL SOFTWARE PROCESS) /TSP (TEAM SOFTWARE PROCESS).FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 2. Identifica todos los aspectos que deberían ser tratados y es independiente de la tecnología. operación y mantenimiento de software y sus servicios relacionados. 2. desarrollo. procesos de desarrollo y estructuras organizacionales. 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.5.

SPICE fomenta productos de calidad.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. La instrumentación de esta tecnología consiste en lo que se denomina “evolución del PSP”. manejar y mejorar el trabajo de los ingenieros. SPICE tiene diversos alcances. SPICE (SOFTWARE PROCESS IMPROVEMENT AND CAPABILITY DETERMINATION). definiendo aspectos como la asignación y control de tareas para los diversos miembros del equipo. medir la calidad de productos y mejorar las técnicas para su desarrollo. El TSP se concentra en los aspectos del desarrollo de software realizado por equipos de trabajo.6. 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. El SPICE es un modelo de madurez de procesos internacional. 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. PRUEBA DE SOFTWARE Página 16 . 2. promueve la optimización de procesos y facilita la evaluación del producto a través de los procesos de desarrollo. El objetivo de PSP es lograr una mejor planeación del trabajo.

PRUEBA DE SOFTWARE Página 17 . llamado ingeniería de la ejecución del modelo de madurez. El objetivo de PEMM es poder evaluar la Ejecución de la Ingeniería así como la integración del proceso. ejecución y diseño. 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.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 2. Al igual que SPICE se apoya en el modelo de madurez de capacidades CMM. PEMM (PERFORMANCE ENGINEERING MATURITY MODEL). El PEMM presenta un modelo para evaluar los niveles de integración. aplicación.7.

surge por la poca adopción de las normas internacionales de calidad ISO 9000 para el área de desarrollo de software. TICKIT. estimular a los desarrolladores de software a implementar sistemas de calidad. Los objetivos principales de TickIt son. 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. dando la dirección y guías necesarias para tal efecto. además de desarrollar un sistema de certificación aceptable en el mercado. PRUEBA DE SOFTWARE Página 18 .FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 2. Desarrollado por el Departamento de Comercio e Industria del Reino Unido.8.

Este es el punto clave. 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. PRUEBA DE SOFTWARE Página 19 . DEFINICIÓN DE VERIFICACIÓN Y VALIDACIÓN 3. será más eficiente corregirlos que si se descubriesen en etapas más avanzadas. DEFINICIÓN DE VERIFICACIÓN Y VALIDACIÓN. 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. De esta forma. Existen distintos modelos de ciclo de vida que se han desarrollado para conseguir diferentes objetivos.1.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 3. si hay errores y son detectados. 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. El proceso de desarrollo adoptado por un proyecto dependerá de los objetivos y metas que tenga el proyecto. Este tipo de comprobaciones a lo largo del ciclo de vida incluyen dos actividades: la verificación y la validación. en el que tiene lugar la evaluación del producto.

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

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

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

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

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

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

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

6. PROCESO DE MEDICION: Ayudar en el diseño de pruebas más efectivas. ACTIVIDADES DE LAS METRICAS DE SOFTWARE. REALIMENTACIÓN: Recomendaciones obtenidas de la interpretación de métricas técnicas trasmitidas al equipo de software. 6. que. así el administrador junto con el empleo de estas técnicas mejorará el proceso y sus productos”. 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. PRUEBA DE SOFTWARE Página 27 . Michael [‘99] Las métricas son la maduración de una disciplina. es por eso que propone un proceso de medición. Las métricas de software proveen la información necesaria para la toma de decisiones técnicas. ANÁLISIS: El cálculo de las métricas y la aplicación de herramientas matemáticas.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.4.3. según Pressman [’98] van a ayudar a la Evaluación de los modelos de análisis y de diseño. COLECCIÓN: El mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas. 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.

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

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

  El descubrimiento de defectos en el sistema. modelo de diseño o en la propia estructura del programa.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. La evaluación de si el sistema es útil y utilizable en una situación operacional o no. INDEPENDIENTE DEL LENGUAJE DE PROGRAMACIÓN: las métricas deberían apoyarse en el modelo de análisis.  7. Tiene dos objetivos principales. EL PROCESO V & V Es el proceso de todo un ciclo vital: La V & V debe aplicarse en cada etapa del software. 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. PRUEBA DE SOFTWARE Página 30 . No deberían depender de los caprichos de la sintaxis o semántica del lenguaje de programación.1. No obstante que la mayoría de las métricas de software compensan las características anteriores. 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. V4V EN EL PROCESO DE DESARROLLO DE SOFTWARE 7. 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. algunas de las métricas usualmente empleadas no cumplen una o dos características.

Introducir un producto en el mercado pronto puede ser más importante que encontrar defectos en el programa 7.3.2. 7. 7. El nivel de confianza depende de lo crítico que es el sistema para una organización.4. las expectativas del usuario y el entorno de marketing. 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. 7.3. Sino que debe ser lo suficientemente bueno para su uso previsto y el tipo de uso determinará el grado de confianza que se necesita. FUNCIÓN DEL SOFTWARE. Esto NO significa que esté completamente libre de defectos. ENTORNO DE MARKETING.2. Los usuarios pueden tener bajas expectativas para ciertas clases de software. VERIFICACIÓN DINÁMICA Y ESTÁTICA PRUEBA DE SOFTWARE Página 31 . 7.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 7.3. EXPECTATIVAS DEL USUARIO.1.3.3.

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

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

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. los diagramas de la arquitectura. Las especificaciones del documento o del programa del diseño del nivel bajo contendrán una lógica funcional detallada del módulo. La prueba está generalmente caja blanca. Implica el análisis del código escrito con la intención de eliminar errores. incluyendo su tipo y tamaño todos los detalles del interfaz. DISEÑO DEL MÓDULO Esta fase se puede también llamar como diseño bajo. 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.2. FASES DE LA VALIDACIÓN 7.8. la prueba de la unidad implica la primera etapa de prueba dinámica proceso. 7. El diseño de prueba de la integración se realiza en esta fase.7. tablas de la base de datos.8. También verifica que los códigos sean eficientes y tengan estándares de la codificación. PRUEBA DE SOFTWARE Página 34 . breve funcionalidad de cada módulo. Se hace usando el diseño de la prueba de la integración elaborada durante la fase de diseño de la arquitectura.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.8.1. 7. PRUEBA DE LA UNIDAD En el V-modelo del desarrollo del software. Se hace usando el diseño de la prueba de unidad elaborada durante la fase de diseño del módulo. base de datos tablas. dependencias.4. con todos los elementos. su interfaz relaciones.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 7. adentro pseudocódigo.3. 7. La prueba está generalmente caja negra pues el código no se comprueba directamente para saber si hay errores. tecnología detallan el etc. DISEÑO DE LA ARQUITECTURA Esta fase se puede también llamar como diseño de alto nivel.

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

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

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

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

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->