ES2707230T3 - Prueba del ciclo de vida - Google Patents

Prueba del ciclo de vida Download PDF

Info

Publication number
ES2707230T3
ES2707230T3 ES11164350T ES11164350T ES2707230T3 ES 2707230 T3 ES2707230 T3 ES 2707230T3 ES 11164350 T ES11164350 T ES 11164350T ES 11164350 T ES11164350 T ES 11164350T ES 2707230 T3 ES2707230 T3 ES 2707230T3
Authority
ES
Spain
Prior art keywords
prototype
test
requirements
updated
performance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES11164350T
Other languages
English (en)
Inventor
Prabhu Arumugham
Nisha Augustine
Ruby Felicia Noel
Bhanu Raju
Prabhu Subramaniam
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tata Consultancy Services Ltd
Original Assignee
Tata Consultancy Services Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tata Consultancy Services Ltd filed Critical Tata Consultancy Services Ltd
Application granted granted Critical
Publication of ES2707230T3 publication Critical patent/ES2707230T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/368—Test management for test version control, e.g. updating test cases to a new software version

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Abstract

Un sistema (102) de pruebas que comprende: un procesador (202); y una memoria (206) acoplada al procesador (202),comprendiendo la memoria (206): un módulo (108) de actualización configurado para recopilar una pluralidad de criterios de rendimiento, una pluralidad de casos de prueba y reglas de vínculo predefinidas para vincular al menos un caso de prueba, de entre la pluralidad de casos de prueba, con uno de la pluralidad de criterios de rendimiento, en una base de datos; y un módulo de actualización configurado para: recibir uno de un criterio de rendimiento modificado asociado con un prototipo actualizado y un criterio de rendimiento incremental asociado con el prototipo actualizado, en el que el criterio de rendimiento modificado es una versión modificada de un criterio de rendimiento original que falló durante la prueba de un primer prototipo y el criterio de rendimiento incremental es un nuevo criterio de rendimiento añadido al criterio de rendimiento original del primer prototipo; un módulo de extracción configurado para: extraer automáticamente el al menos un caso de prueba, a base al menos de las reglas de vínculo predefinidas, en el que el al menos un caso de prueba está vinculado a uno del criterio de rendimiento incremental asociado con el prototipo actualizado y el criterio de rendimiento modificado asociado con el prototipo actualizado; un módulo (212) de ejecución configurado para habilitar la ejecución del al menos un caso de prueba extraído por el módulo (108) de extracción en el prototipo actualizado; y un módulo (216) de versionado configurado para: almacenar el criterio de rendimiento incremental asociado con el prototipo actualizado, el criterio de rendimiento modificado asociado con el prototipo actualizado y el al menos un caso de prueba extraído por el módulo de extracción.

Description

DESCRIPCIÓN
Prueba del ciclo de vida
Campo técnico
La presente materia objeto, en general se refiere a pruebas de software y en particular, a una prueba del ciclo de vida.
Antecedentes
Las pruebas de software son una fase importante en un ciclo de vida de software. La eficiencia y rentabilidad de una organización de software, en parte, depende altamente en sus capacidades de pruebas. Con el aumento en la tendencia de desarrollar grandes aplicaciones de software modulares e integradas, la complejidad de probar este software ha aumentado. Además, los avances en tecnología proporcionan que se construyan aplicaciones de software que pueden incluir aplicaciones de cliente, aplicaciones de servidor, herramientas de desarrollo, etc. Estas aplicaciones necesitan soportarse en múltiples configuraciones de hardware y software y cumplir diversos requisitos de calidad rigurosos. Por lo tanto, con el aumento de la complejidad así como requisitos de calidad rigurosos a cumplir por estos programas de software, la necesidad de pruebas efectivas ha aumentado para habilitar la identificación de errores que necesitan arreglarse así como los cambios que se requieren en la funcionalidad de la aplicación.
El procedimiento de pruebas completo de una aplicación de software, generalmente denominado como prueba del ciclo de vida, incluye procedimientos de pruebas iterativos que cuentan con una gran cantidad de actividades de pruebas e información. Estas actividades de pruebas, información de pruebas y otros detalles relacionados necesitan gestionarse por razones tal como el mantenimiento de trazabilidad en la prueba del ciclo de vida. Para proyectos de pruebas mayores, necesitan gestionarse una mayor cantidad de información y detalles, que es una tarea incómoda y que lleva mucho tiempo.
Sumario
Este resumen se proporciona para introducir conceptos relacionados con sistema de pruebas de software. Este sumario ni se concibe para identificar características esenciales del objeto reivindicado ni se concibe para usar en la determinación o limitación del alcance del objeto reivindicado.
En el presente documento se describen sistemas y procedimientos de pruebas en una organización, en particular un sistema y un procedimiento de acuerdo con la reivindicación 1 y reivindicación 6 respectivamente como una forma ilustrativa de la invención. Sistema de pruebas o herramientas de la técnica anterior, respectivamente, se desvelan, entre otros, en los documentos US 2004/107415 A1 y PAVAN KUMAR CHITTIMALLI Y COL, "Regression test selection on system requirements", PROCEEDINGS OF THE 1ST CONFERENCE ON INDIA SOFTWARE ENGINEERING CONFERENCE, ISEC '08, Nueva York, Nueva York, Estados Unidos, (20080222), doi:10.1145/1342211.1342229, ISBN 978-1-59-593917-3.
Breve descripción de los dibujos
La descripción detallada se describe con referencia a las figuras adjuntas. En las figuras, el dígito o los dígitos más a la izquierda de un número de referencia identifica la figura en la que el número de referencia aparece primero. Los mismos números se usan a lo largo de los dibujos para hacer referencia a características y componentes similares. la Figura 1 ilustra un entorno de red ilustrativo que implementa un sistema de pruebas, de acuerdo con una forma ilustrativa de la presente materia objeto
la Figura 2 ilustra un sistema de pruebas ilustrativo, de acuerdo con una forma ilustrativa de la presente materia objeto.
la Figura 3 ilustra un procedimiento ilustrativo de pruebas en una organización, de acuerdo con una forma ilustrativa de la presente materia objeto.
Descripción detallada de los dibujos
El objeto descrito en el presente documento se refiere a un sistema de pruebas. Sistemas y procedimientos relacionados con el sistema de pruebas como se describe en el presente documento pueden implementarse en una diversidad de dispositivos, tal como un servidor, un ordenador personal de sobremesa, un ordenador de mano o un ordenador portátil, un ordenador central y en un entorno informático móvil.
Típicamente, una prueba del ciclo de vida de un código de programa, en lo sucesivo denominado como un prototipo, incluye una fase de requisitos; una fase de preparación de plan de pruebas; un fase de preparación de caso de prueba; ejecución de prueba, identificación de defectos, una fase de comunicación; y fase de lanzar a producción. Durante la fase de requisitos, se identifican una pluralidad de requisitos tal como requisitos de rendimiento y funcionales a cumplir por el prototipo. Los requisitos de un prototipo son específicos de los parámetros de rendimiento y las funcionalidades que se requieren que cumpla el prototipo. Por ejemplo, un tiempo de ejecución deseado para el prototipo puede ser un requisito y un uso de unidad de procesamiento central (CPU) deseado por el prototipo puede ser otro requisito, etc. Estos requisitos se definen a menudo por un cliente para el que se está desarrollando una aplicación y se identifican y documentan mediante por ejemplo, un analista empresarial. La documentación de los requisitos puede implicar listar el rendimiento así como los requisitos funcionales del prototipo en un documento de especificación de requisitos de software.
Estos requisitos se comunican habitualmente a un equipo de desarrollo que crea un código de programa, es decir el prototipo, para estos requisitos y simultáneamente a un equipo de pruebas que crea una pluralidad de casos de prueba de prueba de estos requisitos.
La fase de preparación de plan de prueba incluye la definición de un procedimiento de todas las pruebas a realizar en el prototipo por el equipo de pruebas. Por ejemplo, la preparación del plan de pruebas incluye las etapas y el enfoque que tienen que usarse para verificar y garantizar que el prototipo cumple los requisitos como se listan en el documento de especificación de requisitos de software.
La fase de preparación de caso de prueba incluye la preparación de los casos de prueba de acuerdo con los requisitos del prototipo. Los casos de prueba son escenarios que tienen ciertos valores de entrada para permitir la generación de ciertos valores de salida deseados cuando se ejecutan en el prototipo. Estos casos de prueba se ejecutan en el prototipo para verificar el cumplimiento de los requisitos asociados con el prototipo. Diferentes requisitos pueden tener uno o más diferentes casos de prueba asociados con el mismo.
Adicionalmente a la preparación de los casos de prueba, los casos de prueba se ejecutan. La ejecución de la prueba e identificación de defectos incluye la ejecución de los casos de prueba en el prototipo para probar el cumplimiento de un conjunto dado de requisitos, e identificación de cualquier defecto que se produce durante la ejecución de los casos de prueba en el prototipo. La ocurrencia de un defecto indica el fallo de un requisito. Posterior a la identificación de los defectos, los defectos se comunican al equipo de desarrollo en la fase de comunicación de modo que el equipo de desarrollo puede rectificar los defectos. Posteriormente, el prototipo puede modificarse por el equipo de desarrollo para eliminar el defecto. El prototipo se prueba de nuevo iterativamente, hasta que no se identifican más defectos. Una vez que se arreglan todos los defectos, el prototipo se envía para lanzamiento en la fase de lanzar a producción.
A la vista de las complejidades implicadas en las actividades de pruebas iterativas, y requisitos de calidad rigurosos a cumplir por el software durante las actividades de pruebas, diversos sistemas de gestión de prueba se emplean convencionalmente por las organizaciones. Estos sistemas de gestión de prueba se emplean para mantener la trazabilidad de las actividades de pruebas de toda la organización. Las soluciones de gestión de prueba empleadas en las organizaciones que almacenan los diversos detalles de prueba tal como requisitos, casos de prueba y defectos, en una base de datos, que puede usarse por el equipo de pruebas para ganar visibilidad en las actividades de pruebas de la organización.
Sin embargo, en los sistemas convencionales, los requisitos y los correspondientes casos de prueba se buscan manualmente por los usuarios de los sistemas de gestión de prueba. Por ejemplo, si un prototipo tiene un requisito RGUI1 que pertenece a una interfaz gráfica de usuario (GUI), y casos de prueba T63, T108 y T43 tienen que ejecutarse en el prototipo para verificar este requisito, entonces en los sistemas convencionales, se requiere que un usuario, tal como un miembro del equipo de pruebas, vaya manualmente a través de toda la base de datos para la localización de estos casos de prueba requeridos. Debido al gran número creciente de requisitos y casos de prueba asociados con cada requisito, el número de requisitos y casos de prueba almacenados en la base de datos es enorme. Por consiguiente, buscar manualmente los casos de prueba requeridos que pertenecen a un requisito a probar en los sistemas convencionales es una tarea tediosa y que lleva mucho tiempo.
Además, los sistemas convencionales no se ocupan de las modificaciones en el prototipo y cualquier modificación correspondiente en los requisitos y los casos de prueba que puede producirse. Por lo tanto, en caso de una modificación en el prototipo, se requiere que se ejecuten de nuevo todos los casos de prueba que pertenecen a todos los requisitos asociados con el prototipo. Esto resulta en una pérdida de tiempo y recursos de pruebas. Además, los sistemas convencionales no facilitan la configurabilidad de toda la actividad de prueba. En otras palabras, los sistemas convencionales no proporcionan las características de configurabilidad deseadas en las que un usuario puede definir un flujo de trabajo para las diversas etapas implicadas en la prueba del ciclo de vida, a través de una interfaz de usuario. Además, sistemas convencionales no proporcionan características que habilitan la generación de informes en un formato definido por el usuario.
Para este fin, en el presente documento se describen sistemas y procedimientos de pruebas. El sistema de pruebas como se describe en el presente documento proporciona una trazabilidad extremo a extremo y gestión de las actividades de pruebas. En una forma ilustrativa de la invención, el sistema de pruebas proporciona extracción automática de los casos de prueba requeridos para uno o más requisitos asociados con el prototipo. Adicionalmente, el sistema de pruebas también permite la extracción de casos de prueba relacionados con requisitos incrementales y requisitos modificados asociados con un prototipo actualizado. Un prototipo puede actualizarse para incluir requisitos modificados que fallaron durante una prueba anterior y/o para incluir una pluralidad de requisitos incrementales o adicionales. Cuando el prototipo se actualiza, resultando en los requisitos correspondientemente modificados y/o requisitos incrementales o adicionales, el sistema de pruebas extrae y lista únicamente los casos de prueba vinculados a los requisitos fallados o modificados, y/o los requisitos incrementales asociados con el prototipo actualizado. Por lo tanto, únicamente los casos de prueba vinculados a los requisitos modificados y/o los requisitos incrementales tienen que ejecutarse en el prototipo actualizado. Requisitos anteriores que probaron ser satisfactorios no necesitan probarse de nuevo, por lo tanto, evitando la pérdida de tiempo y recursos.
En una forma ilustrativa adicional de la invención, el sistema de pruebas habilita una prueba de regresión de prueba de los requisitos de una sola vez. La prueba de regresión también permite garantizar que requisitos originales y los casos de prueba asociados con los mismos no se afectan por las modificaciones hechas en otros requisitos y los casos de prueba en cualquiera de las actualizaciones hechas al prototipo. Para el fin de la realización de la prueba de regresión, el sistema de pruebas puede proporcionar un conjunto de pruebas de regresión que incluye una pluralidad de casos de prueba para probar todos los requisitos.
Adicionalmente, el sistema de pruebas como se describe en el presente documento proporciona funcionalidad de gestión de cambios para mantener trazabilidad en las modificaciones hechas en los requisitos y los correspondientes casos de prueba del prototipo. Para esto, el sistema de pruebas almacena todos los prototipos, los requisitos asociados con el prototipo, los casos de prueba, la vinculación entre los requisitos y los casos de prueba, los defectos así como todas las modificaciones hechas al prototipo, los requisitos y los casos de prueba.
Además, el sistema de pruebas facilita que el usuario defina los niveles de granularidad deseada en los informes generados para los prototipos, los casos de prueba asociados y los requisitos. Por ejemplo, el usuario puede seleccionar o definir el nivel de detalles a visualizar en los informes. En otro ejemplo, pueden fusionarse informes para diferentes prototipos. También, los informes que indican el requisito que se han probado y los casos de prueba utilizados para el fin pueden usarse por el usuario para determinar los requisitos y casos de prueba que pueden reutilizarse en otros proyectos y los prototipos de tipo similar. Adicionalmente, el sistema de pruebas facilita que el usuario defina los flujos de trabajo para el procedimiento de pruebas. Por ejemplo, el flujo de trabajo puede incluir un flujo de trabajo de revisión de requisitos, flujo de trabajo de revisión de casos de prueba o un flujo de trabajo de gestión de defectos para definir la secuencia y/o planificar del procedimiento de pruebas.
En la operación, cada aplicación se asocia con una pluralidad de requisitos, tal como los especificados por un cliente. Como se mencionó anteriormente, estos requisitos se listan en una especificación de requisitos durante la fase de requisitos. Por ejemplo, la aplicación 1.1 puede tener requisitos R1-R10 asociados con la misma. Un conjunto completo de todos los requisitos de la aplicación puede ser un conjunto maestro de requisitos. Estos requisitos se comunican al equipo de desarrollo y el equipo de pruebas.
El equipo de desarrollo crea el código de programa para la aplicación, en lo sucesivo denominado como el prototipo. Como se indica, se requiere que el prototipo cumpla todos los requisitos predefinidos. En una forma ilustrativa de la invención, toda la aplicación puede dividirse en una pluralidad de lanzamientos, en la que cada lanzamiento tiene uno o más prototipos a desarrollar y probar. Estos prototipos se desarrollan por el equipo de desarrollo de una manera incremental. Por ejemplo, inicialmente, el prototipo se desarrolla para requisitos R1 y R2, y se actualiza adicionalmente para incluir requisitos adicionales de una manera incremental, tal como el siguiente prototipo actualizado puede desarrollarse para incluir requisitos R3 y R4 además de los anteriormente existentes requisitos R1, R2, y así sucesivamente.
El equipo de pruebas, simultáneamente, crea una pluralidad de casos de prueba de prueba de estos requisitos. Uno o más casos de prueba se prueban para la prueba de cada uno de los requisitos predefinidos. A medida que los casos de prueba se preparan, el equipo de pruebas define una regla de vinculación para los casos de prueba y los requisitos a los que pertenecen los casos de prueba. Por lo tanto, los requisitos se vinculan a uno o más de los casos de prueba, durante la fase de preparación de caso de prueba. Posteriormente, los casos de prueba y se almacenan en la base de datos del sistema de pruebas.
En una forma ilustrativa de la invención, el equipo de pruebas recibe un prototipo de pruebas, del equipo de desarrollo. Como se ha explicado anteriormente, ya que el prototipo se desarrolla de la manera incremental, puede no estar completo inicialmente con respecto a todos los requisitos. Por lo tanto, el equipo de desarrollo especifica los requisitos para los que el prototipo actual tiene que probarse. Por ejemplo, el equipo de desarrollo puede especificar que ha desarrollado un prototipo para los dos primeros requisitos digamos R1 y R2 del conjunto maestro de los requisitos. Por lo tanto, el equipo de pruebas necesita probar el prototipo para únicamente los requisitos R1 y R2 y por lo tanto necesita únicamente los casos de prueba relevantes para requisito R1 y R2. En una forma ilustrativa de la invención, los requisitos especificados se seleccionan del conjunto maestro de requisitos creado durante la fase de requisitos.
En dicha forma ilustrativa de la invención, el equipo de pruebas proporciona los requisitos asociados con el prototipo recibido al sistema de pruebas. Como se describe anteriormente, los requisitos asociados con el prototipo han predefinido vinculación a una pluralidad de casos de prueba creados durante la fase de preparación de caso de prueba. Por lo tanto, el sistema de pruebas extrae automáticamente únicamente los casos de prueba relevantes que se requieren que se ejecuten en el prototipo para los requisitos asociados a base de la regla de vinculación predefinida. Por ejemplo, un prototipo recibido A tiene dos requisitos, R1 que indica un tiempo de ejecución deseado del prototipo y requisito R2 que indica un uso de CPU deseado del prototipo. En la fase de preparación de caso de prueba, el requisito R1 se vincula a los casos de prueba T3, T5 y T16 y de manera similar, requisito R2 se vincula a los casos de prueba T1, T10 y T20. Por lo tanto, el sistema extrae únicamente los casos de prueba vinculados a los requisitos R1 y R2 del prototipo, en este caso T3, T5 y T16 para el requisito R1 y T1, T10 y T20 para el requisito R2. La extracción automática de únicamente los casos de prueba relevantes de entre cientos de casos de prueba almacenados en la base de datos ahorra mucho tiempo y esfuerzo. Adicionalmente, la extracción automática también asegura la completitud del procedimiento de pruebas ya que cada requisito y cambios en el mismo se verifican exhaustivamente.
Posteriormente, el sistema de pruebas habilita la ejecución de los casos de prueba extraídos en una plataforma de pruebas, para verificar el cumplimiento de requisitos asociados con el prototipo. En una forma ilustrativa de la invención, el sistema de pruebas lista los casos de prueba extraídos, pertinentes a únicamente los requisitos asociados con el prototipo recibido, y proporciona los mismos al equipo de pruebas que pueden ejecutarse adicionalmente por el equipo de pruebas en una plataforma/entorno de pruebas.
Además, a medida que los casos de prueba se ejecutan en el prototipo, puede identificarse un defecto que es indicativo de un fallo de los correspondientes requisito. Por ejemplo, si el tiempo de ejecución excede el tiempo de ejecución deseado como se establece en el requisito R1, entonces esto indica que el requisito R1 ha fallado. Tales defectos se comunican al equipo de desarrollo para arreglar el defecto. Además, el equipo de pruebas recibe desde el equipo de desarrollo un prototipo actualizado en el que se abordan los defectos. En una forma ilustrativa de la invención, un prototipo actualizado puede incluir uno o más requisitos modificados que fallaron en el primer prototipo. Adicionalmente, el prototipo actualizado puede incluir uno o más requisitos adicionales o incrementales para los que el prototipo actualizado tiene que probarse por el equipo de pruebas. Por ejemplo, como se indica anteriormente, el prototipo actualizado puede incluir el requisito modificado R1 y tres requisitos adicionales digamos R3, R4 y R5. Por lo tanto, ahora el equipo de pruebas tiene que probar el prototipo actualizado para los requisitos incrementales, en este caso R3, R4 y R5, y para el requisito modificado R1. Puede indicarse que el requisito R2 que se encontró satisfactorio durante la prueba anterior puede no probarse.
En dicha forma ilustrativa de la invención, el equipo de pruebas introduce el nuevo conjunto de requisitos asociados con el prototipo actualizado (en este caso los requisitos R1, R3, R4 y R5) al sistema de pruebas. Como se describe anteriormente, los requisitos se vinculan a una pluralidad de casos de prueba como se definen por el equipo de pruebas durante la fase de preparación de caso de prueba. Por lo tanto, el sistema de pruebas extrae únicamente los casos de prueba relevantes que pertenecen a únicamente los nuevos requisitos, R1, R3, R4 y R5. Por lo tanto, el sistema de pruebas como se describe en el presente documento habilita la ejecución de nuevo de únicamente los casos de prueba vinculados a los requisitos modificados y/o los requisitos incrementales asociados con el prototipo actualizado.
Adicionalmente, el sistema de pruebas facilita el equipo de pruebas para realizar una prueba de regresión en todo el conjunto de prototipo para lanzar, para todos los requisitos. El sistema de pruebas puede proporcionar un conjunto de pruebas de regresión que incluye todos los casos de prueba requeridos para probar todos los requisitos del prototipo. La prueba de regresión habilita que el equipo de pruebas garantice que los requisitos del primer prototipo no se afectan por otras modificaciones hechas en el prototipo actualizado y los requisitos. El prototipo se envía para lanzamiento cuando satisface todos los requisitos asociados con el mismo y se arreglan todos los defectos.
En dicha forma ilustrativa de la invención, el sistema de pruebas también proporciona control de versión para los casos de prueba y los requisitos. El sistema proporciona una trazabilidad de extremo a extremo de toda las actividades de prueba a lo largo de toda la organización, incluso para equipos de pruebas distribuidos geográficamente.
El sistema de pruebas proporciona adicionalmente al usuario con una opción para seleccionar versiones de base de referencia de los casos de prueba y los requisitos y publicar adicionalmente las mismas para posterior uso por otros módulos en la prueba del ciclo de vida. En una forma ilustrativa de la invención, los usuarios pueden decidir manualmente qué versión del requisito tiene que publicarse como la base de referencia para otros módulos. Por ejemplo, en caso de que el requisito R1 tenga una versión original V1 se modifica a versiones de requisito R1 V2, y la versión de requisito R1 V2 se selecciona por el usuario como la versión final del requisito, a continuación el sistema de pruebas pone el requisito R1 V2 disponible para otros módulos en la prueba del ciclo de vida, que a su vez ahora tratan el requisito R1 V2 como una base de referencia para procesamiento adicional. Además, si después de establecer el requisito R1 V2 para ser la base de referencia para los otros módulos en la prueba del ciclo de vida se crea una versión mejorada adicional del requisito R1, digamos R1 V3, a continuación el usuario puede establecer R1 V3 como la nueva base de referencia. Por lo tanto, la versión V3 del requisito R1 se usa ahora como la base de referencia por los otros módulos en la prueba del ciclo de vida. En este caso, el sistema de pruebas como se describe en el presente documento proporciona procesamiento paralelo en la prueba del ciclo de vida, ya que los módulos pueden proceder con la versión intermedia de los requisitos (en este caso versión V2) sin esperar a la versión final.
El sistema de pruebas como se describe en el presente documento, almacena todos los requisitos, casos de prueba asociados, defectos y versiones de los requisitos y los casos de prueba en una base de datos. En una forma ilustrativa adicional de la invención, la base de datos puede buscarse usando palabras clave de búsqueda de los requisitos y casos de prueba y los defectos. La característica de búsqueda palabra clave facilita una búsqueda fácil de casos de búsqueda existentes y habilita la reutilización de los mismos.
En una forma ilustrativa adicional de la invención, el sistema de pruebas genera una pluralidad de informes de pruebas de profundización para mostrar las actividades de pruebas en toda la organización de una manera gráfica así como textual. Los informes pueden analizarse y estudiarse adicionalmente por los usuarios para conocer si las actividades de pruebas están según lo planificado, antes de lo planificado o con retardo. Adicionalmente, el sistema proporciona configuración de flujo de trabajos de pruebas procedimientos, a través de una interfaz de usuario. También, los usuarios pueden enviar por correo electrónico estos informes a otro usuario en la organización.
La manera en la que el sistema de pruebas se implementa se explicará en detalle con respecto a las Figuras 1-3. Mientras aspectos de los sistemas y procedimientos pueden implementarse en cualquier número de diferentes entornos de sistemas informáticos y/o configuraciones, los ejemplos se describen en el contexto de la siguiente arquitectura o arquitecturas de sistema ilustrativas.
La Figura 1 muestra un entorno 100 de red ilustrativo que implementa un sistema 102 de pruebas de gestión de actividades de pruebas relacionadas con pruebas de códigos de programa, en lo sucesivo denominado como el prototipo, de acuerdo con una forma ilustrativa de la invención de la presente materia objeto. Un prototipo es una versión compilada de un código fuente de programa que satisface uno o más requisitos y que puede desplegarse en cualquier dispositivo informático. Cada prototipo desarrollado necesita probarse. La prueba del prototipo puede extenderse en diversas etapas en la prueba del ciclo de vida que puede implementarse en módulos que tienen funcionalidades similares e integradas entre sí, para proporcionar flexibilidad en el procedimiento de pruebas. El sistema 102 de pruebas como se describe en el presente documento gestiona todo la prueba del ciclo de vida y proporciona una trazabilidad de extremo a extremo en todas las actividades de prueba a lo largo de toda una organización. El entorno 100 de red incluye el sistema 102 de pruebas, comunicando con diversos dispositivos 106­ 1, 106-2, a 106-n de cliente a través de una red 104. Los dispositivos 106-1, 106-2, a 106-n de cliente en lo sucesivo se denominan colectivamente como dispositivos 106 de cliente.
La red 104 puede implementarse como una red inalámbrica, red por cable o una combinación de las mismas. La red 104 puede implementarse como uno de los diferentes tipos de redes tal como intranet, red de área local (LAN), red de área extensa (WAN) y la internet. La red 104 puede o bien ser una red especializada o bien una red compartida, que representa una asociación de los diferentes tipos de redes que usan una diversidad de protocolos, por ejemplo, Protocolo de Transferencia de Hipertexto (HTTP), Protocolo de Control de Transmisión/Protocolo de Internet (TCP/IP), Protocolo de Aplicación Inalámbrica (WAP), etc., para comunicarse entre sí. Además, la red 104 puede incluir dispositivos de red, tal como conmutadores de red, concentradores, encaminadores y adaptadores de bus del anfitrión (HBA), para proporcionar un enlace entre el sistema 102 de pruebas y los dispositivos 106 de cliente. Los dispositivos de red dentro de la red 104 pueden interactuar con el sistema 102 de pruebas y los dispositivos 106 de cliente a través de enlaces de comunicación.
El sistema 102 de pruebas y los dispositivos 106 de cliente pueden implementarse como cualquiera de una diversidad de dispositivos informáticos incluyendo, por ejemplo, un servidor, un PC de sobremesa, un ordenador de mano o un ordenador portátil, una estación de trabajo, un ordenador central, un dispositivo informático móvil, un dispositivo de entretenimiento o una aplicación de internet.
Como se describe antes, cada prototipo ha predefinido requisitos asociados con el mismo. Todos los requisitos asociados con el prototipo pueden definirse como un conjunto maestro de requisitos para los que el prototipo tiene que desarrollarse y probarse. La especificación de requisitos según se documentan por el analista empresarial se comunica al equipo de desarrollo y el equipo de pruebas. El equipo de desarrollo prepara prototipos de una manera incremental dividiendo toda la aplicación en una pluralidad de lanzamientos que se constituyen de uno o más prototipos. Los prototipos también se prueban generalmente de una manera incremental de acuerdo con los lanzamientos por el equipo de desarrollo.
Por ejemplo, un primer prototipo se desarrolla para el requisito R1 a R4, el equipo de pruebas prueba el primer prototipo y, posteriormente, un prototipo actualizado se desarrolla para cumplir con los requisitos adicionales R5 a R7 y así sucesivamente, hasta que el prototipo cumple con todos los requisitos. El prototipo actualizado puede ser un incremento del primer prototipo que puede satisfacer los requisitos R5 a R7 además de los requisitos R1 a R4, satisfaciendo por lo tanto los requisitos R1 a R7. En una forma ilustrativa de la invención, el prototipo actualizado también puede ser un prototipo, que se modifica para cumplir un requisito que falló durante las pruebas del primer prototipo. De conformidad, en una forma ilustrativa de la invención, el prototipo actualizado puede ser una modificación del primer prototipo que puede haberse revisado para rectificar el primer prototipo en caso de que uno o más de los requisitos R1 a R4 fallaran mientras las pruebas del primer prototipo. Por lo tanto, como es evidente que requisitos incrementales y requisitos modificados pueden asociarse con el prototipo actualizado.
Para probar los prototipos, el equipo de pruebas crea uno o más casos de prueba de prueba de cada uno de los requisitos. Adicionalmente, el equipo de pruebas proporciona una regla de vinculación que define una vinculación entre los requisitos y los casos de prueba, durante la fase de preparación de caso de prueba. Posteriormente, los casos de prueba y la vinculación entre los requisitos y los casos de prueba se almacenan también en la base de datos o repositorio similar.
En una forma ilustrativa de la invención, cuando el equipo de pruebas recibe un prototipo para probar el mismo para un conjunto de requisitos como se especifica por el equipo de desarrollo, por ejemplo, el equipo de pruebas recibe un prototipo A desde el equipo de desarrollo, y el equipo de desarrollo especifica al equipo de pruebas que el prototipo tiene que probarse para los requisitos R1 a r3, el equipo de pruebas tiene que probar el prototipo recibido únicamente para e los requisitos R1 a R3. El equipo de pruebas proporciona el prototipo recibido junto con los requisitos especificados para el sistema 102 de pruebas en el que todos los casos de prueba que pertenecen a los requisitos R1 a R3 se extraen automáticamente desde la base de datos y hacen disponibles para las pruebas. En una forma ilustrativa de la invención, las pruebas del prototipo se hacen en un entorno de red, en el que, un usuario, digamos un miembro del equipo de pruebas puede proporcionar el prototipo junto con los requisitos especificados al sistema 102 de pruebas a través del dispositivo 106 de cliente. De manera similar, otro usuario, por ejemplo un miembro del equipo de desarrollo, puede recibir notificación de defectos en un prototipo probado desde el sistema 102 de pruebas o enviar prototipos actualizados al sistema 102 de pruebas a través del dispositivo 106 de cliente.
En una forma ilustrativa de la invención, el sistema 102 de pruebas incluye un módulo 108 de extracción de extracción de los casos de prueba relevantes para los requisitos especificados para el prototipo desde la base de datos, a base del enlace predefinido. En el ejemplo indicado anteriormente, en la recepción de un prototipo A de pruebas con los requisitos R1, R2, R3 y R4, el módulo 108 de extracción del sistema 102 de pruebas extrae únicamente los casos de prueba relevantes para los requisitos específicos. Por lo tanto, un usuario no necesita filtrar manualmente el caso de prueba relevante de entre el gran número de casos de prueba que relacionan todos los requisitos del prototipo almacenados en la base de datos.
Además, el sistema 102 de pruebas habilita la ejecución de los casos de prueba extraídos. En una forma ilustrativa de la invención, los casos de prueba extraídos se ejecutan en el prototipo por el equipo de pruebas en una plataforma/entorno de pruebas para verificar el cumplimiento de los requisitos especificados. En otra forma ilustrativa de la invención, el sistema 102 de pruebas puede configurarse para ejecutar automáticamente los casos de prueba extraídos en el prototipo.
Cualquier ocurrencia de un defecto que es indicativo de un fallo de un requisito durante la ejecución de casos de prueba se comunica al equipo de desarrollo junto con el requisito fallado asociado y el defecto. En una forma ilustrativa adicional de la invención, el sistema 102 de pruebas almacena los defectos identificados junto con los requisitos asociados y los casos de prueba en la base de datos. El equipo de desarrollo, que es responsable de desarrollar y arreglar los defectos en el prototipo, actualiza el prototipo para eliminar el defecto.
En dicha forma ilustrativa de la invención, el módulo 108 de extracción extrae y lista los casos de prueba a base de los requisitos modificados así como los incrementales asociados con el prototipo actualizado en forma de un conjunto de prueba. Para el ejemplo anterior, el equipo de pruebas proporciona los requisitos R2, R3, R4 y R5 al sistema 102 de pruebas que tienen que probarse en el prototipo actualizado. Como se describe anteriormente, estos requisitos son también del conjunto maestro y por lo tanto se vinculan a una pluralidad de casos de prueba preparados durante la fase de preparación de caso de prueba. Posteriormente, el módulo 108 de extracción extrae y lista los casos de prueba vinculados a los requisitos modificados así como adicionales asociados con el prototipo actualizado. En un ejemplo, todos los casos de prueba requeridos para verificar defectos arreglados en un prototipo actualizado pueden proporcionarse en un conjunto de pruebas de verificación de defectos. En una forma ilustrativa de la invención, el sistema de pruebas habilita la ejecución de nuevo de los casos de prueba vinculados únicamente a los requisitos modificados así como los casos de prueba vinculados al requisitos adicionales asociados con el prototipo actualizado. Los casos de prueba extraídos, como se lista mediante el módulo 108 de extracción del sistema 102 de pruebas, se ejecutan de nuevo. Por ejemplo, si para el prototipo A que tiene los requisitos R1, R2 y R3, únicamente el requisito R2 se modifica, a continuación el sistema 102 de pruebas extrae únicamente los casos de prueba vinculados al requisito modificado R2 y habilita la ejecución de nuevo de únicamente los casos de prueba modificados y/o los casos de prueba vinculados a los requisitos modificados (En este caso, casos de prueba vinculados al requisito modificado R2) en lugar de ejecutarlos todos de nuevo, como se hace convencionalmente.
Adicionalmente, una vez que todos los defectos se arreglan en el prototipo y satisface todos los requisitos como se listan en la especificación de requisitos, a continuación el sistema 102 de pruebas habilita que los usuarios realicen una prueba de regresión. La prueba de regresión proporciona una opción para seleccionar todos los requisitos modificados, casos de prueba modificados o los casos de prueba vinculados a los requisitos modificados, así como los requisitos no modificados originales y los casos de prueba relacionados a los mismos a ejecutar de nuevo. Como se mencionó anteriormente, el sistema 102 de pruebas proporciona que el conjunto de pruebas de regresión habilite la prueba de todos los requisitos. El conjunto de pruebas de regresión puede incluir cada caso de prueba requerido para probar todos los requisitos y puede ejecutarse durante las pruebas de regresión. El sistema 102 de pruebas habilita que el equipo de pruebas garantice que los requisitos originales de un prototipo no se afectan por cualquier modificación posterior hecha al prototipo.
El sistema 102 de pruebas proporciona una total trazabilidad extremo a extremo a través de los requisitos, los casos de prueba vinculados y los defectos. La prueba del ciclo de vida es un procedimiento iterativo que implica las modificaciones en los requisitos o la modificación en los casos de prueba a base del prototipo modificado o a base de los defectos identificados en todo la prueba del ciclo de vida del prototipo. Por lo tanto, el sistema 102 de pruebas almacena toda la información acerca del prototipo, los casos de prueba asociados, y los requisitos, etc., para proporcionar una trazabilidad de extremo a extremo en las actividades de pruebas de la organización. Los usuarios pueden ganar visibilidad en toda la actividad de pruebas en la organización con la ayuda de los requisitos almacenados, casos de prueba y los defectos asociados. En una forma ilustrativa de la invención, los detalles relacionados con las actividades de pruebas, tal como diversas versiones de prototipos, requisitos, defectos pueden presentarse en un formato de informe que puede enviarse por correo adicionalmente a otro usuario (digamos en el equipo de desarrollo) en la red 104.
En dicha forma ilustrativa de la invención, el sistema 102 de pruebas mantiene un registro de todas las versiones de los casos de prueba modificados y/o los requisitos modificados a base de las modificaciones en el prototipo. Además, el sistema 102 de pruebas facilita que el usuario defina una versión del requisito, o los casos de prueba, que el usuario quiere establecer como una base de referencia para los otros módulos en la prueba del ciclo de vida para procesamiento adicional. En una forma ilustrativa de la invención, los usuarios pueden seleccionar manualmente la versión de los requisitos y los casos de prueba que pueden publicarse como bases de referencia para los otros módulos en la prueba del ciclo de vida. Por ejemplo, si un requisito R1 tiene una versión original V1 que se modifica dos veces, proporcionando dos versiones más, digamos V2 y V3, a continuación el sistema 102 de pruebas facilita que el usuario seleccione manualmente una versión digamos la versión V3 de entre las tres para ser la versión final y publicar la misma como una base de referencia para otros módulos en la prueba del ciclo de vida. Además, la base de referencia del requisito R1, en este caso la versión V3, puede usarse en la siguiente etapa digamos mientras se envía el prototipo para lanzar. Sin embargo, si después de establecer la versión V3 para ser la base de referencia para los otros módulos en la prueba del ciclo de vida, se crea una nueva versión mejorada adicional del requisito, por ejemplo V4. A continuación el usuario puede ahora establecer la versión V4 como la base de referencia. Por lo tanto, la versión V4 del requisito R1 se tratará ahora como la base de referencia para procesamiento adicional por los otros módulos en la prueba del ciclo de vida. En dicha forma ilustrativa de la invención, el sistema 102 de pruebas proporciona procesamiento paralelo en la prueba del ciclo de vida, ya que los módulos en la prueba del ciclo de vida pueden proceder con una versión de base de referencia de los requisitos (en este caso la versión V3) y el usuario puede simultáneamente trabajar y mejorar la versión referenciada incluso adicionalmente. Por lo tanto, el sistema 102 de pruebas no tiene que esperar a la versión final del requisito para proceder a la siguiente etapa de la prueba del ciclo de vida. En otra forma ilustrativa de la invención, los usuarios pueden seleccionar más de una versión de los requisitos y/o casos de prueba a publicar como una base de referencia para los otros módulos en la prueba del ciclo de vida. En dicha forma ilustrativa de la invención, estas versiones de los requisitos así como los casos de prueba modificados se almacenan también en la base de datos central para que los usuarios vean el historial completo de modificaciones y las versiones de los requisitos y casos de prueba.
Además, en una realización, el sistema 102 de pruebas genera informes en forma de gráficos o presenta ilustraciones en una GUI del dispositivo 106 de cliente, tal como un tablero de control, del usuario para proporcionar una visibilidad en todas las actividades de prueba de la organización. En otra realización, el sistema 102 de pruebas proporciona que los usuarios profundicen en los informes en un nivel deseado de granularidad. Por ejemplo, el usuario puede ver dos o más proyectos de pruebas en los informes, o pueden profundizar en un proyecto específico a un nivel inferior, digamos requisitos para ese proyecto. Los usuarios también pueden ver una pluralidad de informes de prueba integrados para una pluralidad de prototipos, como se proporciona por el sistema 102 de pruebas. En una realización, los informes generados pueden ser en forma de una matriz de cobertura que ilustra cuántos y qué requisitos se vinculan a cuántos y qué casos de prueba. Esto habilita que los usuarios ganen una visión rápida de los requisitos y los casos de prueba vinculados y por lo tanto facilita la reutilización de casos de prueba.
En dicha forma ilustrativa de la invención, el sistema 102 de pruebas proporciona colaboración por correo electrónico para los usuarios, para enviar como correos electrónicos los informes deseados a otro usuario en la red 104. Por ejemplo, si un usuario A quiere enviar un informe para un proyecto particular a un usuario B, entonces, puede clicar en un botón de correo electrónico, que envía el informe al usuario deseado, el usuario B. En una forma ilustrativa de la invención, puede notificarse a un usuario mediante una notificación de correo electrónico, para proceder con una siguiente etapa según se define en un flujo de trabajo para la ejecución de los casos de prueba y los requisitos. Por lo tanto, el sistema de pruebas se configura para enviar correos electrónicos automáticamente a base de una acción predefinida en el flujo de trabajo. Por consiguiente, en cualquier flujo de trabajo, ciertas etapas pueden identificarse en las que puede generarse una notificación de correo electrónico. En una forma ilustrativa adicional de la invención, la notificación de correo electrónico puede ser automática y configurable por el usuario. Por ejemplo, en un flujo de trabajo de defectos, siempre que, se identifica un defecto, puede enviarse una notificación de correo electrónico a los usuarios objetivo, en este caso a un miembro de equipo de desarrollo para arreglar el defecto y modificar el prototipo según se requiera. Además, el sistema 102 de pruebas permite una flexibilidad para configurar los ajustes de correo electrónico para incluir detalles predefinidos tal como el asunto y cuerpo de un correo.
En una forma ilustrativa de la invención, el sistema 102 de pruebas se configura para realizar una búsqueda de palabra clave en búsqueda de toda la base de datos para resultados relevantes en los requisitos, casos de prueba y los defectos. Adicionalmente, el sistema 102 de pruebas proporciona una clasificación basada en prioridad de los resultados de búsqueda para habilitar que los usuarios refinen sus resultados de búsqueda como deseen. Por ejemplo, los casos de prueba y/o requisitos extraídos como resultados de búsqueda contra una palabra clave particular introducida por un usuario, puede clasificarse como casos de prueba y/o requisitos de alta prioridad, baja prioridad. Por lo tanto, los usuarios pueden profundizar en los resultados de búsqueda como deseen a base de las clasificaciones proporcionadas por el sistema 102 de pruebas.
En una forma ilustrativa adicional de la invención, el sistema 102 de pruebas facilita que los usuarios creen y gestionen flujos de trabajo para el uno o más requisitos, casos de prueba y los defectos, etc. Por ejemplo, los flujos de trabajo pueden indicar la secuencia de la ejecución de los requisitos y los casos de prueba, las personas responsables de la realización de una etapa de procedimiento en un ciclo de revisión para la ejecución de los requisitos, casos de prueba los defectos, etc. El sistema 102 de pruebas proporciona a los usuarios con una opción de configuración de los flujos de trabajo de los requisitos y casos de prueba como se deseen. En dicha forma ilustrativa de la invención, el sistema 102 de pruebas proporciona la configuración de los flujos de trabajo a través de una interfaz de usuario como se desee por el usuario.
En dicha forma ilustrativa de la invención, el sistema 102 de pruebas adicionalmente rastrea la planificación de los casos de prueba y los requisitos a través del informes generados del sistema. Por ejemplo, los usuarios pueden ver los informes y determinar si las actividades de pruebas están en tiempo, antes de tiempo o con retardo.
La Figura 2 ilustra ilustrativo componentes del sistema 102 de pruebas, de acuerdo con un ejemplo de la presente materia objeto. En dicha forma ilustrativa de la invención, el sistema 102 de pruebas incluye un procesador 202, interfaz 204 o interfaces de I/O y una memoria 206. El procesador 202 se acopla a la memoria 206. El procesador 202 puede implementarse como uno o más microprocesadores, microcontroladores, procesadores de señales digitales, unidades de procesamiento central, máquinas de estado, circuiterías lógicas y/o cualquier dispositivo que manipula señales a base de instrucciones operacionales. Entre otras capacidades, el procesador 202 se configura para buscar y ejecutar instrucciones legibles por ordenador almacenadas en la memoria 206.
La interfaz 204 o interfaces de I/O pueden incluir una diversidad de interfaces de software y hardware, por ejemplo, una interfaz web que permite que el sistema 102 de pruebas interactúe con los dispositivos 106 de cliente. Además, la interfaz 204 o interfaces pueden habilitar que el sistema 102 de pruebas se comunique con otros dispositivos informáticos, tal como servidores web y repositorios externos o bases de datos. La interfaz 204 o interfaces pueden facilitar múltiples comunicaciones dentro de amplia variedad de redes y tipos de protocolos, incluyendo redes por cable, por ejemplo LAN, cable, etc., y redes inalámbricas tal como WlAn , celular o satélite. La interfaz 204 o interfaces pueden incluir uno o más puertos de conexión de un número de dispositivos informáticos entre sí o a otro servidor.
La memoria 206 puede incluir cualquier medio legible por ordenador conocido en la técnica incluyendo, por ejemplo, memoria volátil (por ejemplo, RAM) y/o memoria no volátil (por ejemplo, EPROM, memoria flash, etc.). La memoria 206 incluye uno o más módulo 208 o módulos y datos 210. En una forma ilustrativa de la invención, el módulo 208 incluye adicionalmente el módulo 108 de extracción, un módulo 212 de ejecución, un módulo 214 de actualización, un módulo 216 de versionado, un módulo 218 de búsqueda y otro módulo 220 o módulos. Los datos 210 sirven, entre otras cosas, como un repositorio de almacenamiento de datos procesados, recibidos y generados por el uno o más del módulo 208 o módulos. Puede mencionarse que la base de datos que almacena los requisitos, casos de prueba asociados y defectos identificados etc., mencionados anteriormente, puede ser la memoria 206 del sistema 102 de pruebas o un repositorio de datos asociado con el mismo.
En la operación, el módulo 108 de extracción recibe una pluralidad de prototipos de pruebas desde el equipo de pruebas. En una forma ilustrativa de la invención, los prototipos recibidos pueden almacenarse en otros datos 234. Como se describe anteriormente, los prototipos tienen una pluralidad de requisitos asociados con los mismos. Los requisitos puede almacenarse en los datos 222 de requisitos.
Como se describe anteriormente, los requisitos se vinculan a una pluralidad de casos de prueba como se definen por la regla de vinculación definida durante la fase de preparación de caso de prueba. En una forma ilustrativa adicional de la invención, los casos de prueba se almacenan como datos 224 de caso de prueba junto con las reglas que vinculan los requisitos a los casos de prueba.
Posteriormente, en anteriormente mencionado módulo 108 de extracción, extrae únicamente los casos de prueba relevantes para un requisito específico del prototipo recibido, a base del vínculo recibido de los casos de prueba y los requisitos. Adicionalmente, el módulo 108 de extracción comunica los casos de prueba extraídos en forma de un conjunto de pruebas, los requisitos y el prototipo al módulo 212 de ejecución.
Además, el módulo 212 de ejecución del sistema 102 de pruebas habilita la ejecución de los casos de prueba extraídos para el prototipo, que corresponden a requisitos específicos. En una forma ilustrativa de la invención, los casos de prueba extraídos pueden ejecutarse por un equipo de pruebas en una plataforma/entorno de pruebas. En una forma ilustrativa de la invención, el módulo 212 de ejecución puede configurarse para ejecutar automáticamente los casos de prueba extraídos.
En una forma ilustrativa adicional de la invención, el módulo 212 de ejecución del sistema 102 de pruebas identifica cualquier defecto que se produce mientras se ejecutan los casos de prueba en el prototipo. Un defecto se identifica cuando el prototipo falla en cumplir con el requisito deseado. En una forma ilustrativa de la invención, el módulo 212 de ejecución indica los defectos identificados al equipo de desarrollo para modificaciones para eliminar el defecto en el prototipo. El prototipo modificado recibido desde el equipo de desarrollo se proporciona al módulo 214 de actualización del sistema 102 de pruebas. Adicionalmente, un prototipo incremental, analizado anteriormente, puede también proporcionarse al módulo 214 de actualización. En otras palabras, el prototipo actualizado que incluye el prototipo modificado y/o el prototipo incremental se proporciona al módulo 214 de actualización. En una forma ilustrativa de la invención, un requisito modificado también puede comunicarse al equipo de pruebas, que puede implicar creación o modificación los casos de prueba de acuerdo con los requisitos modificados. En dicha forma ilustrativa de la invención, las modificaciones en el prototipo, los requisitos, los casos de prueba y la vinculación se almacenan en la base de datos central como datos 228 de modificaciones.
En una forma ilustrativa adicional de la invención, el módulo 214 de actualización comunica las modificaciones recibidas en el prototipo, y los requisitos, los casos de prueba o ambos, al módulo 108 de extracción. A continuación, la extracción habilita la extracción de únicamente los casos de prueba vinculados con los requisitos modificados y/o los requisitos incrementales. En una forma ilustrativa de la invención, el módulo 212 de ejecución permite la ejecución de nuevo de casos de prueba extraídos por el módulo 108 de extracción. En una forma ilustrativa de la invención, el módulo 214 de actualización también comunica al módulo 108 de extracción, una lista en lo sucesivo denominado como un conjunto de pruebas de regresión, de todos los casos de prueba y los requisitos asociados con el prototipo para la realización de la prueba de regresión anteriormente descrita.
Además, el módulo 216 de versionado del sistema 102 de pruebas almacena las versiones de los requisitos y los casos de prueba en datos 230 de versiones. En dicha forma ilustrativa de la invención, las versiones incluir los requisitos modificados, los requisitos incrementales, casos de prueba modificados y nuevos o adicionales casos de prueba. El módulo 216 de versionado facilita que el usuario seleccione cualquier versión de los requisitos para que sea la versión final y publique la misma como una base de referencia para otros módulos en el ciclo de vida. Adicionalmente, las versiones y las bases de referencia se almacenan también en las datos 230 de versiones.
En otra forma ilustrativa de la invención, el módulo 218 de búsqueda del sistema 102 de pruebas permite que los usuarios realicen una búsqueda de palabra clave para localizar casos de prueba, requisitos, prototipos y versiones de los mismos que se relacionan con la palabra clave.
En formas ilustrativas adicionales de la invención, el otro módulo 220 del sistema 102 de pruebas puede incluir un módulo de generación de informes (no mostrado en la Figura) para generar una pluralidad de informes para la prueba del ciclo de vida a partir de los diversos datos tal como los requisitos, casos de prueba, vinculación, modificaciones del prototipo y las versiones de los requisitos, y los casos de prueba. En dicha forma ilustrativa de la invención, los usuarios pueden ver los informes generados a un nivel deseado de granularidad. Por ejemplo, los usuarios pueden seleccionar una vista integrada de informes relacionados con más de un prototipo, un único informe de un prototipo, o los usuarios pueden adicionalmente profundizar en requisitos específicos o casos de prueba del prototipo. En una forma ilustrativa de la invención, los informes generados están en forma de una matriz de cobertura que indica cuántos y qué requisitos se vinculan a cuántos y qué casos de prueba.
En una forma ilustrativa de la invención, el otro módulo 220 del sistema 102 de pruebas también puede incluir un módulo de comunicación (no mostrado en la Figura) a una interfaz el sistema 102 de pruebas para enviar a instalaciones de correo electrónico para enviar los informes a un usuario deseado en la red 104. Además, los usuarios pueden rastrear el estado a través de los informes, tal como para determinar si los proyectos están en tiempo, antes de tiempo o con retardo.
En una forma ilustrativa adicional de la invención, el otro módulo 220 del sistema 102 de pruebas puede incluir un módulo de interfaz (no mostrado en la Figura) para permitir que los usuarios definan flujos de trabajo configurables para los requisitos, casos de prueba y los defectos usando interfaz de los dispositivos 106 de cliente. Por ejemplo, los usuarios pueden configurar una planificación y una secuencia de los requisitos, casos de prueba y defectos a ejecutar. Por lo tanto el módulo de interfaz permite el rastreo de planificaciones de la prueba de los prototipos. En una forma ilustrativa adicional de la invención, los usuarios pueden definir el flujo de trabajo para un ciclo de revisión, que significa, qué persona en el equipo es responsable de qué etapa del procedimiento de ejecución del flujo de trabajo asociado con requisitos, los casos de prueba, los defectos, etc.
La Figura 3 ilustra un procedimiento ilustrativo 300 de pruebas, de acuerdo con la presente materia objeto. El procedimiento 300 ilustrativo puede describirse en el contexto general de instrucciones ejecutables por ordenador y puede ser un procedimiento que se puede implementar en ordenador. En general, instrucciones ejecutables por ordenador pueden incluir rutinas, programas, objetos, componentes, estructuras de datos, procedimientos, módulos, funciones y similares que realizan funciones particulares o implementan tipos de datos abstractos particulares. El procedimiento también puede practicarse en un entorno informático distribuido en el que se realizan funciones por dispositivos de procesamiento remotos que están vinculados a través de una red de comunicación. En un entorno informático distribuido, instrucciones ejecutables por ordenador pueden ubicarse en medio de almacenamiento informático tanto local como remoto, incluyendo dispositivos de almacenamiento de memoria.
El orden en el que se describe el procedimiento 300 no pretende que se interprete como una limitación y cualquier número de los bloques de procedimiento descritos pueden combinarse en cualquier orden para implementar el procedimiento o un procedimiento alternativo. Adicionalmente, bloques individuales pueden borrarse del procedimiento sin alejarse del ámbito del objeto descrito en el presente documento. Adicionalmente, el procedimiento puede implementarse en cualquier hardware, software, firmware adecuado o una combinación de los mismos.
De acuerdo con una forma ilustrativa de la presente materia objeto, el procedimiento 300 puede implementarse el sistema 102 de pruebas anteriormente descrito. Sin embargo, se apreciará por un experto en la materia que una forma ilustrativa de este tipo de la invención no es limitante. El procedimiento 300 puede implementarse en una diversidad de similar sistema de pruebas .
El procedimiento 300 se inicia en el bloque 302 tras la recepción de un primer prototipo o un prototipo actualizado de pruebas junto con el conjunto de requisitos para los que el prototipo tiene que probarse. En caso de que se reciba el primer prototipo, el primer prototipo tiene un conjunto de requisitos asociados para el que necesita probarse. En caso de que se reciba un prototipo actualizado, a continuación se recibe una pluralidad de requisitos incrementales y/o requisitos modificados con el prototipo actualizado. En una forma ilustrativa de la invención, el módulo 108 de extracción recibe el prototipo junto con los requisitos
En el bloque 304, se extrae uno o más casos de prueba, de entre una pluralidad de casos de prueba disponible en la base de datos, que pertenecen o bien a los requisitos asociados con un primer prototipo o bien los requisitos incrementales así como los requisitos modificados del prototipo actualizado. La extracción se realiza automáticamente por el módulo 108 de extracción a base de la regla de vinculación predefinida durante la fase de preparación de caso de prueba. La extracción automática de los casos de prueba relevantes de entre cientos de casos de prueba almacenados en el repositorio ahorra mucho tiempo y recursos y asegura que la prueba es exhaustiva y que ninguno de los requisitos se deja sin probar. En una forma ilustrativa de la invención, el módulo 212 de ejecución habilita la ejecución de los casos de prueba extraídos en el prototipo recibido o el prototipo actualizado recibido.
Además, en el bloque 306, los casos de prueba extraídos que pertenecen a los requisitos del prototipo recibido se habilitan para ejecutarse en el prototipo. En dicho ejemplo, el equipo de pruebas puede ejecutar los casos de prueba extraídos en una plataforma/entorno de pruebas. En otro ejemplo, el módulo 212 de ejecución puede configurarse para ejecutar automáticamente los casos de prueba extraídos en el prototipo recibido o el prototipo actualizado recibido. Adicionalmente, cualquier defecto que se produce mientras se ejecutan los casos de prueba en el prototipo se identifica para rectificación. El prototipo modificado/actualizado se prueba de nuevo posteriormente en varias iteraciones hasta que se satisfacen todos los requisitos del prototipo.
Aunque se han descrito ejemplos de pruebas en lenguaje específico para características estructurales y/o procedimientos, se ha de entender que la presente materia objeto no necesariamente se limita a las características específicas o procedimientos descritos. En su lugar, las características específicas y procedimientos se desvelan como ejemplos para gestión de pruebas en una organización.

Claims (8)

REIVINDICACIONES
1. Un sistema (102) de pruebas que comprende:
un procesador (202); y
una memoria (206) acoplada al procesador (202),comprendiendo la memoria (206):
un módulo (108) de actualización configurado para recopilar una pluralidad de criterios de rendimiento, una pluralidad de casos de prueba y reglas de vínculo predefinidas para vincular al menos un caso de prueba, de entre la pluralidad de casos de prueba, con uno de la pluralidad de criterios de rendimiento, en una base de datos; y un módulo de actualización configurado para:
recibir uno de un criterio de rendimiento modificado asociado con un prototipo actualizado y un criterio de rendimiento incremental asociado con el prototipo actualizado, en el que el criterio de rendimiento modificado es una versión modificada de un criterio de rendimiento original que falló durante la prueba de un primer prototipo y el criterio de rendimiento incremental es un nuevo criterio de rendimiento añadido al criterio de rendimiento original del primer prototipo;
un módulo de extracción configurado para: extraer automáticamente el al menos un caso de prueba, a base al menos de las reglas de vínculo predefinidas, en el que el al menos un caso de prueba está vinculado a uno del criterio de rendimiento incremental asociado con el prototipo actualizado y el criterio de rendimiento modificado asociado con el prototipo actualizado; un módulo (212) de ejecución configurado para habilitar la ejecución del al menos un caso de prueba extraído por el módulo (108) de extracción en el prototipo actualizado; y
un módulo (216) de versionado configurado para:
almacenar el criterio de rendimiento incremental asociado con el prototipo actualizado, el criterio de rendimiento modificado asociado con el prototipo actualizado y el al menos un caso de prueba extraído por el módulo de extracción.
2. El sistema (102) de pruebas de acuerdo con la reivindicación 1, en el que el módulo (216) de versionado se configura adicionalmente para publicar una versión como una base de referencia para el sistema (102) de pruebas, en el que la base de referencia se selecciona de la al menos una versión de al menos uno del criterio de rendimiento incremental asociado con el prototipo actualizado, el criterio de rendimiento modificado asociado con el prototipo actualizado y el al menos un caso de prueba extraído por el módulo de extracción.
3. El sistema (102) de pruebas de acuerdo con la reivindicación 1, en el que el sistema (102) de pruebas comprende además un módulo de interfaz configurado para proporcionar una interfaz de usuario de definición de un flujo de trabajo asociado con una prueba de al menos uno del primer prototipo y el prototipo actualizado.
4. El sistema (102) de pruebas de acuerdo con la reivindicación 3, en el que el módulo de interfaz se configura adicionalmente para rastrear planificaciones para la prueba de al menos uno del primer prototipo y el prototipo actualizado.
5. El sistema (102) de pruebas de acuerdo con la reivindicación 1, en el que el sistema (102) de pruebas comprende además un módulo (218) de búsqueda configurado para:
buscar al menos uno del criterio de rendimiento original asociado con el primer prototipo, el criterio de rendimiento incremental asociado con el prototipo actualizado, el criterio de rendimiento modificado asociado con el prototipo actualizado, el al menos un caso de prueba extraído por el módulo de extracción, el primer prototipo y el prototipo actualizado, a base al menos en parte de una palabra clave proporcionada por un usuario; y clasificar los resultados de búsqueda obtenidos de la búsqueda a base de una prioridad.
6. Un procedimiento informático de pruebas, comprendiendo el procedimiento:
recopilar, por un procesador, una pluralidad de criterios de rendimiento, una pluralidad de casos de prueba y reglas de vínculo predefinidas para vincular al menos un caso de prueba, de entre la pluralidad de casos de prueba, con uno de la pluralidad de criterios de rendimiento, en una base de datos de un sistema de pruebas; recibir, por el procesador, uno de un criterio de rendimiento modificado asociado con un prototipo actualizado y un criterio de rendimiento incremental asociado con el prototipo actualizado, en el que el criterio de rendimiento modificado es una versión modificada de un criterio de rendimiento original que falló durante la prueba de un primer prototipo y el criterio de rendimiento incremental es un nuevo criterio de rendimiento añadido al criterio de rendimiento original del primer prototipo;
extraer, por el procesador, el al menos un caso de prueba, a base de las reglas de vínculo predefinidas, en el que el al menos un caso de prueba está vinculado a uno del criterio de rendimiento incremental asociado con el prototipo actualizado y el criterio de rendimiento modificado asociado con el prototipo actualizado; habilitar, por el procesador, la ejecución del al menos un caso de prueba extraído en el prototipo actualizado, y almacenar el criterio de rendimiento incremental asociado con el prototipo actualizado, el criterio de rendimiento modificado asociado con el prototipo actualizado y el al menos un caso de prueba extraído.
7. El procedimiento de acuerdo con la reivindicación 6, comprendiendo además vincular el al menos un criterio de rendimiento original asociado con el primer prototipo, el criterio de rendimiento incremental asociado con el prototipo actualizado, y el criterio de rendimiento modificado asociado con el prototipo actualizado con el al menos un caso de prueba.
8. El procedimiento de acuerdo con la reivindicación 6, comprendiendo además la definición de al menos uno de un flujo de trabajo y una planificación para la prueba de al menos uno del primer prototipo y el prototipo actualizado.
ES11164350T 2011-01-31 2011-04-29 Prueba del ciclo de vida Active ES2707230T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
IN261MU2011 2011-01-31

Publications (1)

Publication Number Publication Date
ES2707230T3 true ES2707230T3 (es) 2019-04-03

Family

ID=44117660

Family Applications (1)

Application Number Title Priority Date Filing Date
ES11164350T Active ES2707230T3 (es) 2011-01-31 2011-04-29 Prueba del ciclo de vida

Country Status (3)

Country Link
US (1) US8745589B2 (es)
EP (1) EP2482192B1 (es)
ES (1) ES2707230T3 (es)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8924935B1 (en) * 2012-09-14 2014-12-30 Emc Corporation Predictive model of automated fix handling
CN103186468B (zh) * 2013-04-10 2016-03-30 华为技术有限公司 一种验证软件升级准确性的方法和装置
US9111037B1 (en) * 2013-08-21 2015-08-18 Ca, Inc. Method and apparatus to enable mainframe computer testing for software testing management platform
US9471470B2 (en) * 2014-06-25 2016-10-18 Hcl Technologies Ltd Automatically recommending test suite from historical data based on randomized evolutionary techniques
US9880924B2 (en) 2015-02-24 2018-01-30 Red Hat, Inc. Source code unit testing using an indexing tool
US20160328312A1 (en) * 2015-05-04 2016-11-10 Halogen Software Inc. Enhanced stability of automation execution via use of state machine pattern and expected conditions when executing an action on an application element
US10733520B2 (en) 2015-05-13 2020-08-04 Microsoft Technology Licensing, Llc Making a prediction regarding development of a software product
US9804954B2 (en) * 2016-01-07 2017-10-31 International Business Machines Corporation Automatic cognitive adaptation of development assets according to requirement changes
US9898392B2 (en) 2016-02-29 2018-02-20 Red Hat, Inc. Automated test planning using test case relevancy
US9823953B2 (en) 2016-04-04 2017-11-21 Bank Of America Corporation Interprogram communication messaging for program synchronization
US9684588B1 (en) 2016-04-04 2017-06-20 Bank Of America Corporation Interprogram communication messaging for application development event handling
US11093374B2 (en) 2016-08-09 2021-08-17 SeaLights Technologies LTD System and method for continuous testing and delivery of software
US10503630B2 (en) * 2016-08-31 2019-12-10 Vmware, Inc. Method and system for test-execution optimization in an automated application-release-management system during source-code check-in
US10466993B2 (en) * 2017-05-05 2019-11-05 Micro Focus Llc Application deployment on multiple platforms
US10394697B2 (en) * 2017-05-15 2019-08-27 International Business Machines Corporation Focus area integration test heuristics
US11494288B2 (en) 2017-08-17 2022-11-08 Micro Focus Llc Test relevancy prediction for code changes
US10459694B2 (en) * 2017-10-16 2019-10-29 Bank Of America Corporation Intelligent checking engine
US10310967B1 (en) * 2017-11-17 2019-06-04 International Business Machines Corporation Regression testing of new software version and deployment
US10585779B2 (en) 2018-07-30 2020-03-10 General Electric Company Systems and methods of requirements chaining and applications thereof
US11086759B2 (en) 2018-09-27 2021-08-10 SeaLights Technologies LTD System and method for probe injection for code coverage
US11573885B1 (en) 2019-09-26 2023-02-07 SeaLights Technologies LTD System and method for test selection according to test impact analytics
WO2021144904A1 (ja) * 2020-01-16 2021-07-22 日本電信電話株式会社 プログラム生成装置、プログラム生成方法及びプログラム

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5432940A (en) * 1992-11-02 1995-07-11 Borland International, Inc. System and methods for improved computer-based training
US7080371B1 (en) * 1998-03-03 2006-07-18 Siebel Systems, Inc. Method, system, apparatus and program product for distribution and instantiation of software upgrades
US6636886B1 (en) * 1998-05-15 2003-10-21 E.Piphany, Inc. Publish-subscribe architecture using information objects in a computer network
US6934934B1 (en) * 1999-08-30 2005-08-23 Empirix Inc. Method and system for software object testing
US20060074727A1 (en) * 2000-09-07 2006-04-06 Briere Daniel D Method and apparatus for collection and dissemination of information over a computer network
US7055137B2 (en) * 2001-11-29 2006-05-30 I2 Technologies Us, Inc. Distributed automated software graphical user interface (GUI) testing
US7167870B2 (en) * 2002-05-08 2007-01-23 Sun Microsystems, Inc. Software development test case maintenance
US7272823B2 (en) * 2002-08-22 2007-09-18 Sun Microsystems, Inc. Method and apparatus for software metrics immediate feedback mechanism
US7334219B2 (en) * 2002-09-30 2008-02-19 Ensco, Inc. Method and system for object level software testing
US7784044B2 (en) * 2002-12-02 2010-08-24 Microsoft Corporation Patching of in-use functions on a running computer system
US7313564B2 (en) * 2002-12-03 2007-12-25 Symbioware, Inc. Web-interactive software testing management method and computer system including an integrated test case authoring tool
EP1680741B1 (en) * 2003-11-04 2012-09-05 Kimberly-Clark Worldwide, Inc. Testing tool for complex component based software systems
US7665068B2 (en) * 2003-12-12 2010-02-16 Oracle International Corporation Methods and systems for testing software applications
US7392509B2 (en) * 2004-04-13 2008-06-24 University Of Maryland Method for domain specific test design automation
US7954090B1 (en) * 2004-12-21 2011-05-31 Zenprise, Inc. Systems and methods for detecting behavioral features of software application deployments for automated deployment management
US7840944B2 (en) * 2005-06-30 2010-11-23 Sap Ag Analytical regression testing on a software build
US7950004B2 (en) * 2005-10-21 2011-05-24 Siemens Corporation Devices systems and methods for testing software
US8001532B1 (en) * 2006-03-10 2011-08-16 Parasoft Corporation System and method for generating source code-based test cases
CN100547562C (zh) * 2006-10-18 2009-10-07 国际商业机器公司 自动生成可再现运行时问题的单元测试用例的方法和系统
US20080201705A1 (en) * 2007-02-15 2008-08-21 Sun Microsystems, Inc. Apparatus and method for generating a software dependency map
US7506312B1 (en) * 2008-01-31 2009-03-17 International Business Machines Corporation Method and system for automatically determining risk areas to retest

Also Published As

Publication number Publication date
EP2482192B1 (en) 2018-10-24
US20120198421A1 (en) 2012-08-02
EP2482192A1 (en) 2012-08-01
US8745589B2 (en) 2014-06-03

Similar Documents

Publication Publication Date Title
ES2707230T3 (es) Prueba del ciclo de vida
US20200183896A1 (en) Upgrade of heterogeneous multi-instance database clusters
US10157054B2 (en) Managing change-set delivery
Ragunath et al. Evolving a new model (SDLC Model-2010) for software development life cycle (SDLC)
Gupta et al. Challenges in adopting continuous delivery and DevOps in a globally distributed product team: A case study of a healthcare organization
Lwakatare et al. DevOps for AI–Challenges in Development of AI-enabled Applications
CN105095059B (zh) 一种自动化测试的方法和装置
KR20130135271A (ko) 코드 복제 통지 및 아키텍처 변경 가시화
CN105138386A (zh) 基于Jenkins与vManager的逻辑设计验证持续集成平台
Rather et al. A comparative study of software development life cycle models
Nugroho et al. Comparative analysis of software development methods between Parallel, V-Shaped and Iterative
CN104636130B (zh) 用于生成事件树的方法和系统
US11531539B2 (en) Automated compliance and testing framework for software development
US20140165188A1 (en) Using data analytics and crowdsourcing to determine roles for a computer system
CN110990048A (zh) 一种监控Unity项目资源缺失的方法及系统
CN106557878A (zh) 开发项目管理方法及装置
EP1881447A1 (en) Software release management
Osman et al. UML Usage in Open Source Software Development: A Field Study.
US10248402B2 (en) Automated code deployment system
Reza et al. Toward model-based requirement engineering tool support
Kovarik Jr et al. Model-based systems engineering: Lessons learned from the joint tactical radio system
WO2021131435A1 (ja) プログラム開発支援システム及びプログラム開発支援方法
EP3206173A1 (en) Systems and methods for generating blueprints for enterprises
Dahiya Enterprise systems development: Impact of various software development methodologies
JPWO2018174223A1 (ja) 運用管理サーバ、開発運用支援システム、それらの方法及びプログラム