P. 1
Fundamentos de Pruebas de Software

Fundamentos de Pruebas de Software

|Views: 567|Likes:
Publicado porValdez Gerardo
es un trabajo de Investigacion sobre los fundamentos de desarrollo de Pruebas de Software, que contienes ciclos de desarrllo, etepas de un software, tipos de pruebas.
Consiste tambien en los modelos de caso de tipos de pruebas de Software.
es un trabajo de Investigacion sobre los fundamentos de desarrollo de Pruebas de Software, que contienes ciclos de desarrllo, etepas de un software, tipos de pruebas.
Consiste tambien en los modelos de caso de tipos de pruebas de Software.

More info:

Categories:Types, Research
Published by: Valdez Gerardo on May 11, 2013
Copyright:Traditional Copyright: All rights reserved
Precio de venta:$4.99 Comprar ahora

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
See more
See less

11/08/2014

$4.99

USD

pdf

FUNDAMENTOS DE LA PRUEBA DE SOFTWARE

Prueba de Software – Dr. Alonso Morales Loayza
Universidad Nacional San Luis Gonzaga Facultad de Ingeniería de Sistemas
Guerreros Huamaní, Luigi Marcos Ávalos, Christian Monserrate Collachagua, Renzo Quispe Chamana, Maicoll Salguero Pizarro, Jerson Ventura Ramos, William

17-4-2013

FUNDAMENTOS DE LA PRUEBA DE SOFTWARE

PRUEBA DE SOFTWARE

Página 1

FUNDAMENTOS DE LA PRUEBA DE SOFTWARE

DEDICATORIA
El presente trabajo va dedicado a nuestros padres, que con su esfuerzo, paciencia y cariño hacen posible el logro de nuestros sueños.

PRUEBA DE SOFTWARE

Página 2

............ 2.......... .......2...................... CALIDAD Y EL SOFTWARE ......7....... 19 DEFINICIÓN DE VERIFICACIÓN Y VALIDACIÓN............................. 4............... 2........3.. ..........1...................................... ...............2............... ....... 2..................................................................................................... 2...........2............................... 5... ........... . 1.................................. 24 PRUEBA DE SOFTWARE Página 3 ....................................................................... 2...................................... 25 MODELOS DE CALIDAD DE SOFTWARE .... 5.............................. 1.......................................... 25 PLAN DE PRUEBAS.............................. 10 1................ 15 ISO (INTERNATIONAL STANDARD ORGANIZATION).......................4..................... ................ 7 1.. 7 ORIGEN....................... 9 CONCEPTOS.................................. 4.............1.................................1.................6.... 22 PLANIFICACIÓN ........... ........ 3................................................ .......1.............. 3..........................................................................2...............2................... ............. 17 PEMM (PERFORMANCE ENGINEERING MATURITY MODEL)..... 19 TICKIT.............. 6 1............... 7 DEFINICIONES FORMALES..... 2.........................1............ 16 PSP (PERSONAL SOFTWARE PROCESS) /TSP (TEAM SOFTWARE PROCESS)................................. .................... 5............................................... 20 OBJETIVOS Y RESTRICCIONES .......... 9 ASEGURAMIENTO DE SOFTWARE Y TÉCNICAS ASOCIADAS....... CONCEPTOS BÁSICOS DE CALIDAD..............5.........................................................1.1........................1........................ ............2.......... 11 MODELO DE MCCALL.................... CALIDAD DE SOFTWARE............................ ......2............. 1.................................................................. 23 ESTRATEGIAS DE PRUEBAS DE SOFTWARE .... 22 OBJETIVOS..........2.............1........................... 3.......................................................... 1................................ 13 DEFINICIÓN DE VERIFICACIÓN Y VALIDACIÓN ...................FUNDAMENTOS DE LA PRUEBA DE SOFTWARE Fundamento de la Prueba de Software INTRODUCCIÓN .... 2.... 1................................................ 2.................... 16 SPICE (SOFTWARE PROCESS IMPROVEMENT AND CAPABILITY DETERMINATION)............................................................ 20 VALIDACIÓN Y VERIFICACIÓN EN EL CICLO DE VIDA ................ ....................8............... ..... 22 RESTRICCIONES...................3................................... 7 DESDE UNA PERSPECTIVA DE VALOR.................................2....................... .... 2........................ 14 CMM (CAPABILITY MATURITY MODEL)........ 13 MODELO DE BOEHM................................................................. 4...................

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

................ 37 REFERENCIAS ............... 7.............8..........2.......8............................................................................4............. DISEÑO DE LA ARQUITECTURA .........7..................8............................. 7............3........................................................................7.................... 35 DISEÑO DEL MÓDULO ............................. 35 CONCLUSIONES .....................3................. 35 PRUEBA DE LA INTEGRACIÓN .. 35 PRUEBA DE LA UNIDAD ............. 7................. 7............................ 7........................................ 7........8........................................4..................................................... 36 PRUEBA DE ACEPTACIÓN DE USUARIO ................................... 35 PRUEBA DEL SISTEMA .........................................................1...................FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 7......................................................................... 36 FASES DE LA VALIDACIÓN .. 38 PRUEBA DE SOFTWARE Página 5 .....8...........................

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

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

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

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

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

Existen requerimientos implícitos que no se mencionan. 1. 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.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. Este aseguramiento se debe diseñar para PRUEBA DE SOFTWARE Página 11 . 2006). 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. componente o proceso cumple con los requerimientos y las necesidades o expectativas del cliente o usuario”. 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.3. ASEGURAMIENTO DE SOFTWARE Y TÉCNICAS ASOCIADAS. (IEEE 610/1990) “Concordancia del software producido con los requerimientos explícitamente establecidos. “Es el grado con el que un sistema.

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. de manera que puedan eliminar defectos cuanto antes.   TÉCNICAS ASOCIADAS AL ASEGURAMIENTO DE 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. La gestión de la configuración del software.    Métricas de software para el control del proyecto. 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). 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. Almacenar cualquier inconformidad y reportarla a la gerencia media. Revisiones del software que se aplican durante cada paso del desarrollo del mismo.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE cada aplicación antes de comenzar a desarrollarlo y no durante su ejecución. PRUEBA DE SOFTWARE Página 12 . 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. Este es el papel del aseguramiento de la calidad del software”. Gestión de configuraciones de software (control de la documentación del software y de los cambios realizados). El proceso de control de cambios contribuye directamente a la calidad del software.

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

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

reusabilidad claridad document. validez McCall + + + + + Boehm + + + + + + + 2. PRUEBA DE SOFTWARE Página 15 . 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. El modelo de madurez de procesos fue generado a través de la experiencia colectiva de los proyectos más exitosos de software. Interoperab. entendib. McCall + + + + + + Boehm + + + + + + + Criterio confiabilidad usabilidad mantenim. CMM (CAPABILITY MATURITY MODEL).3. 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. El CMM tiene como objetivo evaluar los procesos en sus distintos niveles de madurez.

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

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

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

El PEMM presenta un modelo para evaluar los niveles de integración. PRUEBA DE SOFTWARE Página 19 .8. dando la dirección y guías necesarias para tal efecto.7.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 2. 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. aplicación. Al igual que SPICE se apoya en el modelo de madurez de capacidades CMM. TICKIT. Los objetivos principales de TickIt son. 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. 2. PEMM (PERFORMANCE ENGINEERING MATURITY MODEL). estimular a los desarrolladores de software a implementar sistemas de calidad. ejecución y diseño. llamado ingeniería de la ejecución del modelo de madurez. Desarrollado por el Departamento de Comercio e Industria del Reino Unido. surge por la poca adopción de las normas internacionales de calidad ISO 9000 para el área de desarrollo de software. además de desarrollar un sistema de certificación aceptable en el mercado. El modelo sirve tanto para evaluar una organización como los propios desarrollos de procesos tecnológicos específicos. El objetivo de PEMM es poder evaluar la Ejecución de la Ingeniería así como la integración del proceso.

DEFINICIÓN DE VERIFICACIÓN Y VALIDACIÓN 3. en el que tiene lugar la evaluación del producto. Este es el punto clave. será más eficiente corregirlos que si se descubriesen en etapas más avanzadas. 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. 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. 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. De esta forma. donde se decide si está o no preparado para pasar a la siguiente fase. PRUEBA DE SOFTWARE Página 20 . DEFINICIÓN DE VERIFICACIÓN Y VALIDACIÓN. 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. si hay errores y son detectados. Este tipo de comprobaciones a lo largo del ciclo de vida incluyen dos actividades: la verificación y la validación.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 3.1.

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

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

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

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

PRUEBA DE SOFTWARE Página 25 . formule preguntas como las siguientes:     ¿Cómo llevaremos a cabo nuestras pruebas? ¿Dónde las llevaremos a cabo? ¿Cuándo las llevaremos a cabo? ¿Cómo gestionaremos los problemas que encontremos? El plan de pruebas explicita el alcance. Note que puede haber un plan global que explicite el énfasis a realizar sobre los distintos tipos de pruebas (verificación. por ej. Cuando planifique. y cómo planifica realizar esas pruebas. Es una comunicación de alto nivel que revela una intención.2. IDENTIFICADOR DEL PLAN. responsables y manejo de riesgos de un proceso de pruebas. ESTRATEGIAS DE PRUEBAS DE SOFTWARE Es su modo de decirle al resto del equipo del proyecto qué es lo que usted comprobará y qué no comprobará. Con su estrategia de prueba. Un plan de pruebas incluye: 5. Es una manera de decirles a los demás qué es lo que planifica entregar. Esto significa que se desea que la información sea lo más correcta y minuciosa posible. recursos requeridos. calendario. apunte a responder las siguientes preguntas:    ¿Qué estamos verificando? ¿Qué enfoque tomaremos? ¿Qué otra información necesito para planificar con eficacia? Cuando se sepa qué es lo que intenta entregar comenzará la planificación. TP-Contr-X (plan de verificación del contrato asociado al evento de sistema X).2. enfoque.1. PLAN DE PRUEBAS El propósito de esta actividad es delinear y comunicar los detalles del esfuerzo de prueba para un periodo determinado. integración e integración).1. Preferiblemente de alguna forma mnemónica que permita relacionarlo con su alcance. TP-Req-Seguridad1 (plan de verificación del requerimiento 1 de seguridad). 5. TP-Unit-Despachador.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 5. TP Global (plan global del proceso de pruebas).

La estrategia también explicita el grado de automatización que se exigirá. Por ejemplo. ALCANCE Indica el tipo de prueba y las propiedades/elementos del software a ser probado. 60% de los caminos ciclomáticos. 5. el proceso de prueba previsto por el plan puede continuar.2.2. puede que detectemos fallas graves demasiado tarde. TANGIBLES PRUEBA DE SOFTWARE Página 26 . es difícil y riesgoso probar una configuración que aún reporta fallas. 5. 5. Al corregirse los defectos. ESTRATEGIA Describe la técnica.4.2. pero debe explicitarse a partir de qué punto. 5. por otro lado. 100% de las fronteras.2. patrón y/o herramientas a utilizarse en el diseño de los casos de prueba.2. si esperamos a que todos los módulos estén perfectos. por ej. 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". 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. ÍTEMS A PROBAR Indica la configuración a probar y las condiciones mínimas que debe cumplir para comenzar a aplicarle el plan.3..FUNDAMENTOS DE LA PRUEBA DE SOFTWARE Iniciar (plan de prueba unitario para el método iniciar de la clase Despachador). ya que puede ser necesario repetir algunas pruebas.5. Por un lado.2. Como todo artefacto del desarrollo. 5. En lo posible la estrategia debe precisar el número mínimo de casos de prueba a diseñar. CATEGORIZACIÓN DE LA CONFIGURACIÓN Explicita las condiciones bajo las cuales. por lo que debe distinguirse adicionalmente la versión y fecha del plan.6. en el caso de pruebas unitarias de un procedimiento.. tanto para la generación de casos de prueba como para su ejecución. está sujeto a control de configuración.

ej. así como la colocación específica del software a probar (p. Subplanes. las acciones mitigantes y de contingencia. ej. especificación de pruebas.9. tiempo en la máquina de producción. 6. PROCEDIMIENTOS ESPECIALES Identifica el grafo de las tareas necesarias para preparar y ejecutar las pruebas. 5.1. 5. casos de prueba. así como cualquier habilidad especial que se requiere. RECURSOS Especifica las propiedades necesarias y deseables del ambiente de prueba.7.2. 6. incluyendo las características del hardware. ej.2. RESPONSABLES Especifica quién es el responsable de cada una de las tareas previstas en el plan. También se indican cualquier requerimiento especial del proceso: actualización de licencias. La sección incluye un estimado de los recursos humanos necesarios para el proceso. el sistema de operación). espacio de oficina.10. DEFINICION. resumen gerencial del proceso y bitácora de pruebas. CALENDARIO Esta sección describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de las tareas a realizar.11. METTRICAS Y MEDICIONES. PRUEBA DE SOFTWARE Página 27 . qué módulos se colocan en qué máquinas de una red local) y la configuración del software de apoyo.8.2.2.2. el software de sistemas (p. cualquier otro software necesario para llevar a cabo las pruebas. 5. 5. 5.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE Explicita los documentos a entregarse al culminar el proceso previsto por el plan p. seguridad. MANEJO DE RIESGOS Explicita los riesgos del plan.

[Fenton´91]. cantidad. “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”. dimensiones.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE La palabra métrica. [LenO. y por otro lado. Michael [‘99] Las métricas son la maduración de una disciplina. capacidad y tamaño de algunos atributos de un proceso o producto”.Ejiogo´91]. Aunque se han propuesto docenas de métricas o medidas. [Pressman´98]. El IEEE “Standard Glosaryof Software Engering Terms” define como MÉTRICA a “una medida cuantitativa del grado en que un sistema. “MEDIDA “proporciona una indicación cuantitativa de extensión. existe la necesidad de medir y controlar la complejidad del software. Muchos investigadores han intentado desarrollar una sola métrica que proporcione una medida completa de la complejidad del software. así el administrador junto con el empleo de estas técnicas mejorará el proceso y sus productos”. Las métricas de software proveen la información necesaria para la toma de decisiones técnicas. cada una de éstas tiene un punto de vista diferente.2. que. es muy común asociarla con las palabras medición y medida. PRUEBA DE SOFTWARE Página 28 . ¿QUÉ SON LAS MÉTRICAS 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. 6. componente o proceso posee un atributo dado”. según Pressman [’98] van a ayudar a la Evaluación de los modelos de análisis y de diseño. es difícil de obtener un solo valor de estas métricas de calidad. aunque estas tres son distintas.

descritas por LemO. ACTIVIDADES DE LAS METRICAS DE SOFTWARE. Las métricas de software incluyen otras actividades.4. Realización de modelos y mediciones de la calidad.5. Medición de la productividad. REALIMENTACIÓN: Recomendaciones obtenidas de la interpretación de métricas técnicas trasmitidas al equipo de software. 6. COLECCIÓN: El mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas. Evaluación y modelos de desempeño. A continuación se muestra una breve clasificación de métricas de software. Ejiogu [‘91]: PRUEBA DE SOFTWARE Página 29 .3. es por eso que propone un proceso de medición. ANÁLISIS: El cálculo de las métricas y la aplicación de herramientas matemáticas. Acumulación de datos. Evaluación del método y herramientas. Valoración de las capacidades y de la madurez. 6. PROCESO DE MEDICION: Ayudar en el diseño de pruebas más efectivas. tales como:         Estimación de costo y el esfuerzo. 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. 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. 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 6. Administración por métricas.

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. etc. mantenimiento. Mide la estructura del sistema. f. codificación. las métricas orientadas a la función se centran en la funcionalidad o utilidad del programa. d. pruebas.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE  MÉTRICAS DE COMPLEJIDAD: Son todas las métricas de software que definen de una u otra forma la medición de la complejidad. etc. Tales como exactitud. el cómo está hecho. pruebas y mantenimiento. costo (estimación). tamaño. eficiencia y competencia. MÉTRICAS DE PRODUCTIVIDAD. acoplamiento del módulo. tiempo. Tales como volumen. Generalmente tienen que ver con la eficiencia de ejecución. almacenamiento. Estas son los puntos críticos en el diseño. anidaciones. Es para saber en qué tiempo voy a terminar el software y cuantas personas voy a necesitar. configuración. rapidez. MÉTRICAS DE DESEMPEÑO: Corresponden a las métricas que miden la conducta de módulos y sistemas de un software. En lugar de calcularlas las LDC. complejidad. y flujo. c. e. Es decir cómo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente. MÉTRICAS ORIENTADAS A LA PERSONA. estructuración o modularidad. cohesión del módulo. MÉTRICAS DEL SOFTWARE Son las que están relacionadas con el desarrollo del software como funcionalidad. complejidad de algoritmos computacionales. MÉTRICAS ORIENTADAS A LA FUNCIÓN. PRUEBA DE SOFTWARE Página 30 . eficiencia.6. agregación. MÉTRICAS DE CALIDAD: Son todas las métricas de software que definen de una u otra forma la calidad del software. reusabilidad. Es decir que tan productivo va a ser el software que voy a diseñar.    6. b. bajo la supervisión del sistema operativo o hardware. a. Se centran en el rendimiento del proceso de la ingeniería del software. MÉTRICAS TÉCNICAS: Se centran en las características de software. 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 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. Son medidas indirectas del software y del proceso por el cual se desarrolla. MÉTRICAS ORIENTADAS AL TAMAÑO.

Algunas demandan mediciones que son demasiado complejas.  PRUEBA DE SOFTWARE Página 31 . No obstante que la mayoría de las métricas de software compensan las características anteriores. No deberían depender de los caprichos de la sintaxis o semántica del lenguaje de programación. otras son tan esotéricas que pocos profesionales tienen la esperanza de entenderlas. por lo tanto la 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. DIFERENTES ENFOQUES DE MÉTRICAS Se han propuesto cientos de métricas para el 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. 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. y otras violan las nociones básicas intuitivas de lo que realmente es el software de alta calidad. modelo de diseño o en la propia estructura del programa.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 6. algunas de las métricas usualmente empleadas no cumplen una o dos características. pero no todas proporcionan suficiente soporte práctico para su desarrollo. INDEPENDIENTE DEL LENGUAJE DE PROGRAMACIÓN: las métricas deberían apoyarse en el modelo de análisis. Es por eso que se han definido una serie de atributos que deben acompañar a las métricas efectivas de software. 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.7.

7. 7. 7.   El descubrimiento de defectos en el sistema. La evaluación de si el sistema es útil y utilizable en una situación operacional o no. Sino que debe ser lo suficientemente bueno para su uso previsto y el tipo de uso determinará el grado de confianza que se necesita. EL PROCESO V & V Es el proceso de todo un ciclo vital: La V & V debe aplicarse en cada etapa del software. V4V EN EL PROCESO DE DESARROLLO DE SOFTWARE 7.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 7. CONFIANZA DE LA V&V Depende del propósito del sistema.1. FUNCIÓN DEL SOFTWARE.3.2.3. Tiene dos objetivos principales.1. El nivel de confianza depende de lo crítico que es el sistema para una organización. Esto NO significa que esté completamente libre de defectos. PRUEBA DE SOFTWARE Página 32 . 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. las expectativas del usuario y el entorno de marketing.

 7. EXPECTATIVAS DEL USUARIO. Se ocupa del análisis de representaciones estáticas del sistema para describir problemas (verificación estática).3.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 7.2.   El plan debería identificar el balance entre la verificación estática y las pruebas.3.4. PRUEBA DE SOFTWARE Página 33 . La planificación debería comenzar pronto en el proceso de desarrollo. VERIFICACIÓN DINÁMICA Y ESTÁTICA PRINCIPAL TÉCNICA V&V  INSPECCIONES DE SOFTWARE. Los usuarios pueden tener bajas expectativas para ciertas clases de software. PRUEBAS DEL SOFTWARE. Se ocupa de la ejercitación y la observación del comportamiento del producto (verificación dinámica). 7.5.3. PLANIFICACIÓN DE V &V Se requiere una cuidadosa planificación para sacar el máximo de los procesos de inspección y pruebas. Pueden ser complementadas por documentos basados en herramientas y análisis del código. El sistema se ejecuta con datos de pruebas y se observa su comportamiento operativo. ENTORNO DE MARKETING. Introducir un producto en el mercado pronto puede ser más importante que encontrar defectos en el programa 7. La planificación trata de definir estándares para el proceso de prueba en lugar de describir pruebas de productos.

no se determina cómo el software será diseñado o construido. se entrevistan con los usuarios y un documento llamado el documento de las exigencias del consumidor se genera.7. el interfaz. El documento de las exigencias del consumidor describirá típicamente el sistema funcional. los pasos de proceso están doblados hacia arriba después de codificación fase. En vez de la mudanza abajo de una manera linear. El V-Modelo demuestra las relaciones entre cada fase del ciclo vital del desarrollo y su fase asociada de prueba. Sin embargo. Esta fase se refiere sobre establecer lo que tiene que realizarse el sistema ideal. el funcionamiento. 7.7.6.7. físico. ANÁLISIS DE REQUISITOS En esta fase.2.1. DISEÑO DEL SISTEMA PRUEBA DE SOFTWARE Página 34 . EL MODELO-V DE DESARROLLO V-MODELO Es a proceso del desarrollo del software cuál se puede presumir para ser la extensión del modelo de la cascada. Generalmente. FASE DE LA VERIFICACIÓN 7. los requisitos de la seguridad según lo esperado por el usuario. formar la forma de V típica. los requisitos del sistema propuesto son recogidos analizando las necesidades de los usuarios. los datos.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE 7. 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. 7. Calculan hacia fuera las posibilidades y las técnicas por las cuales las exigencias del consumidor pueden ser puestas en ejecución.4. dependencias. El documento de la especificación del software que sirve mientras que un modelo para la fase del desarrollo se genera.2. Implica el análisis del código escrito con la intención de eliminar errores.8. estructuras del menú. La prueba está generalmente caja blanca. tecnología detallan el etc. DISEÑO DE LA ARQUITECTURA Esta fase se puede también llamar como diseño de alto nivel. DISEÑO DEL MÓDULO Esta fase se puede también llamar como diseño bajo.8. con todos los elementos. Las especificaciones del documento o del programa del diseño del nivel bajo contendrán una lógica funcional detallada del módulo. Este documento contiene la organización general del sistema. incluyendo su tipo y tamaño todos los detalles del interfaz. la prueba de la unidad implica la primera etapa de prueba dinámica proceso. FASES DE LA VALIDACIÓN 7. los diagramas de la arquitectura. su interfaz relaciones. 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. 7. Se hace usando el diseño de la prueba de unidad elaborada durante la fase de diseño del módulo.1.FUNDAMENTOS DE LA PRUEBA DE SOFTWARE Los técnicos analizan y entienden el negocio del sistema propuesto estudiando el documento de las exigencias del consumidor. 7. tablas de la base de datos.8. PRUEBA DE SOFTWARE Página 35 . adentro pseudocódigo. base de datos tablas. 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. PRUEBA DE LA UNIDAD En el V-modelo del desarrollo del software.7. estructuras de datos etc. También verifica que los códigos sean eficientes y tengan estándares de la codificación. breve funcionalidad de cada módulo.7.3. El diseño de prueba de la integración se realiza en esta fase.

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

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

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

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)//-->