Scribd Logo
Cargar

¡Te damos la bienvenida a Scribd!

  • 08 - Glosario

    Cargado por

    Gaby María Palomino Gutiérrez
    3 vistas20 páginas
    glosario

    Derechos de autor

    © © All Rights Reserved

    Formatos disponibles

    PDF o lea en línea desde Scribd

    ¿Le pareció útil este documento?

    ¿Este contenido es inapropiado?

    Denunciar este documento
    glosario

    Copyright:

    © All Rights Reserved
    Descargue como PDF o lea en línea desde Scribd
    Marcar por contenido inapropiado
    3 vistas20 páginas

    08 - Glosario

    Cargado por

    Gaby María Palomino Gutiérrez
    glosario

    Copyright:

    © All Rights Reserved
    Descargue como PDF o lea en línea desde Scribd
    Marcar por contenido inapropiado
    de 20
    RBES SuUsiINeSSs twe teste INNOVATIONS Glosario Depuracién: Ei proceso de encontrar, analizar y retirar las causas de las fallas en el software. Requisito: Una condicién 0 capacidad necesitada por el usuario para resolver un problema calcanzar un objetivo que debe ser cumplido o poseido por un sistema 0 componente de sistema para satisfacer un contrato, esténdar, especificacién u otro documento impuesto formalmente. Revisién: Una evaluacién de un producto 0 estado de un proyecto para determinar discrepancias desde los resultados planificados hasta las mejoras recomendadas. Por ejemplo la revision de gestién, revision informal, revision técnica, inspeccién, y revision guiada. Caso de prueba: Un conjunto de valores de entrada, precondiciones de ejecu: resultados esperados y pos condiciones de ejecucién, desarrollado para un objetivo particular o condicién de prueba, tal como ejercitar un camino de programa particular o para verificar la conformidad de un requisito especttico. Pruebas: El proceso que consiste en todas Jas actividades del ciclo de vida, tanto estaticas como dindmicas, que tiene que ver con planificacién, preparacion y evaluacion de productos de software y productos relacionados al trabajo para determinar que satisfagan los requisitos especificados, para demostrar que son aptos para el propésito y para detectar defectos. Objetivo de prueba: Una razén o propésito para el disefio y la ejecucion de una prueba “Bug”: Véase defecto. Defecto: Un desperfecto en un componente o sistema que puede causar que el componente o sistema falle al realizar su funcién requerida, p.ej. una sentencia o definicién de datos incorrecta. Un defecto, si es encontrado durante la ejecucién, puede causar una falla de la componente o sistema Error: Una accién humana que produce un resultado incorrecto Falla: Desviacion del componente o sistema de su entrega, servicio o resultado Copysght © RBCS, 2008-2011, Version 40 esperado. 7 Falta: Véase defecto Equivocacién: Véase error Calidad: El grado al cual un componente, sistema o proceso cumple los requisitos especificados y/o las necesidades y expectativas del usuario/cliente Riesgo: Un factor que podria resultar en futuras consecuencias negativas; usualmente expresado como impacto y probabilidad. Pruebas exhaustivas: Un método de pruebas en el cual el juego de pruebas comprende todas las combinaciones de valores de entrada y pre condiciones. e Pruebas de confirmacién: Véase repeticién de pruebas. Repeticién de pruebas: Pruebas que ejecutan los casos de pruebas que fallaron la altima vez que se ejecutaron, con el fin de verificar el éxito de las acciones correctivas. Criterios de salida: El conjunto de condiciones genéricas y especificas, acordadas con los interesados del negocio, para permitir que un proceso sea completado oficialmente, El propésito de los criterios de salida es prevenir que una tarea sea considerada completa cuando todavia hay partes pendientes de la tarea que no ha sido terminado, Los criterios de salida se utilizan para informar en contra de la parada de las pruebas y para planificar la parada de las pruebas. Incidencia: Cualquier evento que ocurre y que necesita investigacién. e Pruebas de regresién: Pruebas de un programa previamente probado a raiz de una modificacién para garantizar que defectos no han sido introducidos o descubiertos en Areas no modificadas del software, como resultado de los cambios realizados. Se realizan cuando el software o su entorno son modificados. Base de pruebas: Todos los documentos de los cuales los requisitos de un componente o sistema pueden ser deducidos. La documentacion sobre la cual los casos de pruebas se basan. Si un documento puede ser enmendado sélo por medio de un procedimiento de enmienda formal, entonces la base pruebas se llama base de pruebas congelada Condicione de pruebas: Un ftem o evento de una componente o sistema que pudiera ser verificado por uno 0 mas casos de pruebas, p.j., una funcién, CCoppeight © RECS, 20062011, Veron «0 transacci6n, caracteristica, atributo de calidad, o elemento estructural. Cobertura de prueba: Véase cobertura. Cobertura: El grado, expresado como porcentaje, hasta el cual un ftem de cobertura especificado ha sido ejercido por un juego de pruebas. Tenga en cuenta que este término no ha sido referenciado especificamente en esta seccion, pero se incluye aqui, ya que es un sinénimo de cobertura de pruebas. Datos de pruebas: Datos que existen (por ejemplo, en una base de datos) antes que una prueba sea ejecutada, y que afecta 0 es afectado por el componente o sistema sometido a pruebas. Ejeciicién de pruebas: El proceso de ejecucién de una prueba en el componente 0 sistema sometido a pruebas, produciendo resultado(s) real(es). Registro de pruebas: Un re; ejecucion de las pruebas. tro cronolégico de detalles relevantes sobre la Plan de pruebas: Un documento que describe el alcance, método, los recursos y el calendario de las actividades de pruebas previstas. Identifica entre otros items de pruebas, las caracteristicas a ser probadas, las tareas de pruebas, quien hard cada tarea, el grado de independencia del probador, el entorno de pruebas, las técnicas de diseno de pruebas y los criterios de entrada y salida que serén utilizados, y las razones para su eleccién, y algunos riesgos que requieren planes de contingencia Es un registro del proceso de planificacién de pruebas. Procedimiento de prueba: Ver especificacién de procedimit ato de prueba Especificacién de procedimiento de prueba: Un documento que especifica una secuencia de acciones para la ejecucién de una prueba. También conocido como guién de prueba o guién de prueba manual. Tenga en cuenta que este término no ha sido referenciado especificamente en esta seccién, pero se incluye aqui, ya que es un sinénimo de procedimiento de pruebas. Politica de pruebas: Un documento de alto nivel que describe los principios, métodos y objetivos principales de la organizacién respecto a las pruebas. Estrategia de pruebas: Una descripcién de alto nivel de los niveles de pruebas a realizarse y las pruebas en esos niveles para una organizacién o programa (uno 0 més proyectos), Juego de pruebas: Un conjunto de varios casos de pruebas para un componente 0 CCopysight © RBCS, 008-2011, Version £0 sistema sometido a pruebas, donde la pos condicién de de una prueba es utilizada a menudo como una precondicion para la siguiente. Informe de resumen de pruebas: Un documento que resume las actividades de pruebas y los resultados. También contiene una evaluacién de los {tems de pruebas correspondientes contra los criterios de salida. Testware: Artefactos producidos durante el proceso de pruebas necesarios para planificar, disefiar y ejecutar pruebas, tales como la documentacién, los guiones, las entradas, los resultados esperados, los procedimientos de instalacién y de ajuste, los archivos, las bases de datos, el entorno, y cualquier software adicional o utilitarios utilizados en las pruebas. Prediccién de error: Una técnica de disefio de pruebas, donde la experiencia del probador se utiliza para anticipar que defectos podrfan estar presentes en el componente o sistema sometido a pruebas como consecuencia de los errores cometidos, y disefiar pruebas especificamente para exponerlas. Independencia: Este término no esta definido en ei glosario, pero si un término relacionado, la independencia de pruebas. Independencia de pruebas: Separacién de responsabilidades, lo que fomenta el logro de pruebas objetivas. Comercial de distribucion masiva (COTS): Véase software de distribucién masiva. Software de distribucién masiva: un producto de software que es desarrollado para el mercado general, es decir para un gran mimero de clientes, y que es entregado a e muchos clientes en formato idéntico. Tenga en cuenta que este término no es llamado especificamente en esta seccién, pero se lo incluye aqui, ya que es un sinénimo de comercial de distribucion masiva. Modelo de desarrollo iterativo-incremental: Este término no esta definido directamente en el glosario, pero si dos términos relacionados. Modelo de desarrollo iterativo: Un ciclo de vida de desarrollo donde un proyecto es dividido usualmente en un gran nimero de iteraciones. Una iteracién es un ci completo de desarrollo que resulta en una versi6n (interna 0 externa) de un producto ejecutable, un subconjunto del producto final en fase de desarrollo, que crece de iteracién en iteracién para convertirse en el producto final. lo Modelo de desarrollo incremental: Un ciclo de vida de desarrollo donde un ight © RBCS, 2008-2011, Version 4.0 proyecto es dividido en una serie de incrementos, cada uno de los cuales produce una porcién de la funcionalidad del total de los requisitos del proyecto. Los requisitos son priorizados y entregados en orden de prioridad en el incremento adecuado. En algunas (pero no en todas) versiones de este modelo de ciclo de vida, cada sub proyecto sigue un "mini modelo V" con su propio disefo, codificacin y fases de pruebas. Validacién: Confirmacién mediante un examen y a través de la provision de evidencia objetiva de que los requisitos han sido realizados para un uso 0 aplicaci6n intencionada especifica Verificacion: Confirmacién mediante un examen y a través de la provision de evidencia objetiva de que los requisitos especificados han sido realizados. Modelo V: Un framework para describir las actividades del ciclo de vida de desdirollo de software desde la especificacion de requisitos hasta el mantenimiento. E] modelo V ilustra como las actividades de prueba pueden ser integradas en cada ase del ciclo de vida de desarrollo de software. Pruebas alfa: Pruebas operacionales simuladas o reales por usuarios /clientes potenciales 0 por un equipo de pruebas independiente en el sitio de los desarrolladores, pero fuera de la organizacion de desarrollo. Las pruebas alfa son a menudo empleadas para software comercial de distribucién masiva como una forma de pruebas de aceptacién internas. Pruebas beta: Pruebas operacionales por usuarios/clientes potenciales y/o existentes en un sitio externo sin involucrar de alguna forma a los desarrolladores, para determinar si un componente o sistema satisface las necesidades del usuario/ cliente y se ajusta a los procesos de negocio. Las pruebas beta se emplean a menudo como una forma de pruebas de aceptacion externa para software comercial de distribucién masiva con el objeto de obtener retroalimentacién del mercado. Pruebas de componente (también conocidas como pruebas de unidad, médulo 0 programa): Las pruebas de componentes de software individuales, Driver: Un componente de software o herramienta de pruebas que reemplaza un componente que se encarga del control y/o la Hamada de un componente o sistema. Pruebas de campo: Véase pruebas beta. Requisito funcional: Un requisito que especifica una funcién que un componente o sistema debe realizar. CCopysigh © RBCS, 2008-2011, Version 4.0 Integraci6n: El proceso de combinacién de componentes o sistemas en ensamblados més grandes. Pruebas de integracién: Pruebas realizadas para exponer defectos en las interfaces y en las interacciones entre los componentes o sistemas integrados. Véase también pruebas de integracién de componentes, pruebas de integracién de sistemas. Requisito no funcional: Un requisito que no est relacionado con la funcionalidad, pero si con atributos tales como fiabilidad, eficiencia, usabilidad, mantenibilidad y portabilidad. Pruebas de'robustez: Pruebas para determinar la robustez de un producto de software Robustez: El grado en el cual una componente o un sistema puede funcionar correctamente ena presencia de entradas invélidas 0 condiciones del entorno estresantes. Véase también tolerancia de errores, tolerancia de faltas. Tenga en cuenta que este término no se uso especificamente para esta seccién, pero se incluye aqui, ya que es esencial para comprender el término pruebas de robustez Stub: Una implementacién esquelética o de propésito especial de un componente de software, utilizado para desarrollar o probar un componente que Hama 0 que es de otra manera dependiente de ella. Sustituye a un componente llamado. Pruebas de sistema: El proceso de probar un sistema integrado para verificar que cumple los requisitos especificados. Nivel de pruebas: Un grupo de actividades de pruebas que estan organizadas y gestionadas conjuntamente. Un nivel de pruebas esta enlazado a las e responsabilidades en un proyecto. Ejemplos de niveles de prueba son las pruebas de componente, pruebas de integracion, prueba de sistema y pruebas de aceptacién. Desarrollo dirigido por pruebas: Una forma de desarrollo de software donde los casos de pruebas son desarrollados y a menudo automatizados, antes de que el software sea desarrollado para ejecutar aquellos casos de pruebas. Entorno de pruebas: Un entorno de pruebas que contiene el hardware, la instrumentacién, los simuladores, las herramientas de software y otros elementos de soporte necesarios para realizar una prueba. Pruebas de aceptacion del usuario: Véase pruebas de aceptacién. Copycighe © RBCS, 008-001, Pruebas de aceptacién: Pruebas formales con respecto a las necesidades de usuarios, los requisitos y procesos de negocio conducidos para determinar si un sistema satisface o no los criterios de aceptaci6n y para permitir al usuario, los clientes u otra entidad autorizada determinar si acepta 0 no el sistema. Tenga en cuenta que este término no se cito especificamente para esta secci6n, pero se incluye aqui ya que es un sinénimo para las pruebas de aceptacion de usuario. Pruebas de caja negra: Pruebas, ya sea funcionales o no funcionales, sin referencia a Ja estructura interna del componente o sistema. Cobertura de c6digo: Un método de andlisis que determina cuales partes del software han sido ejecutadas (cubiertas) por el juego de pruebas y cuales partes no han sido ejecutadas, p.ej., cobertura de sentencias, cobertura de decisiones 0 cobertura de condiciones. Pruebas funcionales: Pruebas basadas en un anélisis de la especificacion de la funcionalidad de un componente o sistema. Véase también pruebas de caja negra. Pruebas de interoperabilidad: El proceso de pruebas para determinar la interoperabilidad de un producto de software, Véase también pruebas de fancionalidad. Interoperabilidad: La capacidad del producto de software para interactuar con uno o més sistemas o componentes especificados. Tenga en cuenta que este término no ha sido enunciado especificamente en esta secci6n, pero se lo incluye aqui, ya que es esencial para la compresién del término pruebas de interoperabilidad. Pruebas de carga: Un tipo de pruebas de rendimiento conducidas para evaluar el comportamiento de un componente o sistema con una carga cada vez mayor, p.ej mimero de usuarios en concurrentes y/o mimero de transacciones, para determinar que carga puede ser manejada por el componente o sistema. Véase también pruebas de rendimiento, pruebas de estrés, Pruebas de mantenibilidad: El proceso de pruebas para determinar la mantenibilidad de un producto de software. Mantenibilidad: La facilidad con la cual un producto de software puede ser modificado para corregir defectos, modificado para satisiacer nuevos requisitos, modificado para hacer el mantenimiento futuro més facil, o adaptado a un entorno modificado. Tenga en cuenta que este término no ha sido enunciado especificamente en esta seccién, pero se lo incluye aqui, ya que es esencial para la comprension del término pruebas de mantenibilidad 10 RBCS, 208-2011, Version 4.0 Las pruebas de rendimiento: El proceso de pruebas para determinar el rendimiento de un producto de software. Véase también las pruebas de eficiencia. Rendimiento: El grado en el cual un sistema o componente cumple sus funciones designadas dentro de las restricciones dadas en relacién con el tiempo de procesamiento y la tasa de transferencia, Véase también la eficiencia. Tenga en cuenta que este término no se enuncié especificamente en esta seccién, pero se lo incluye aqui, ya que es esencial para comprender el término pruebas de rendimiento. Pruebas de Portabilidad: El proceso de pruebas para determinar la portabilidad de un producto de software. Portabilidad: La facilidad con la cual el producto de software puede ser transferido e de un entorno de hardware o software a otro. Tenga en cuenta que este término no ha sido enunciado especificamente en esta seccién, pero se lo incluye aqui, ya que es esencial para comprender el término pruebas de portabilidad. Pruebas de fiabilidad: El proceso de pruebas par producto de software ‘a determinar la fiabilidad de un Fiabilidad: La capacidad del producto de software para realizar sus funciones necesarias en las condiciones establecidas por un periodo de tiempo especificado, 0 para un mimero de operaciones especificadas. Tenga en cuenta que este término no ha sido enunciado especificamente en esta seccién, pero se lo incluye aqui, ya que es. esencial para comprender el término pruebas de fiabilidad. Pruebas de seguridad: Pruebas para determinar la seguridad del producto de software, Véase también pruebas de funcionalidad. e Seguridad: Atributos de los productos de software que influyen en su capacidad para prevenir el acceso no autorizado, ya sea accidental o intencionado, a los. programas y datos. Véase también la funcionalidad. Tenga en cuenta que este término no ha sido enunciado especificamente en esta seccién, pero se lo incluye aqui, ya que es esencial para comprender el término pruebas seguridad. Pruebas basadas en la especificacién: Véase pruebas de caja negra Pruebas de estrés: Un tipo de pruebas de rendimiento conducido para evaluar un sistema o componente en 0 fuera de los limites de sus cargas de trabajo anticipadas © especificadas, 0 con menor disponibilidad de recursos tales como el acceso a memoria o los servidores. Véase también las pruebas de rendimiento, pruebas de carga. - Copysght © RBCS, 2008-2011, Version £0 Pruebas estructurales: Véase pruebas de caja blanca, Pruebas de usabilidad: Las pruebas para determinar la medida en que el producto de software es comprendido, es facil de aprender, facil de operar y atractivo para Jos usuarios bajo determinadas condiciones. Pruebas de caja blanca: Las pruebas basadas en un andlisis de la estructura interna del componente o sistema. nélisis del impacto: La evaluacién del cambio a las capas de la documentacion de desarrollo, dacumentacién de las pruebas y componentes, con el fin de implementar un cambio dado en los requisitos especificados. Pruebéé de mantenimiento: Pruebas de los cambios en un sistema en produccién 0 el impatto de un entorno modificado en un sistema en produccién Pruebas dinamicas: Pruebas que involucran la ejecucién del software de un componente o sistema. Pruebas estéticas: Pruebas de un componente o sistema en un nivel de especificacién o implementacion sin la ejecucién de ese software, p.ej. andllisis estatico. terios de entrada: El conjunto de condiciones genéricas y especificas para permitir aun proceso seguir adelante con una tarea definida, p.e). la fase de pruebas. El propésito de los criterios de entrada es evitar que una tarea comience lo cual implicarfa més esfuerzo (desperdiciado) en comparacién con el esfuezzo necesario para eliminar los criterios de entrada fallidos. Revisién formal: Una revision caracterizada por procedimientos y requisitos documentados, p.ej,, la inspecci6n. Revisi6n informal: Una revision que no se basa un procedimiento formal (documentado). Inspeccién: Un tipo de revision entre colegas (“peer review”) que se basa en la n visual de documentos para detectar defectos, p.ej., violaciones a los est&ndares de desarrollo y la no conformidad a la dacumentacién de nivel superior. La técnica de revision més formal y ademas basada siempre en un procedimiento documentado. Véase también la revisién entre colegas (“peer review"). revi: Métrica: una escala de medicién y el método utilizado para la medicion. igh © RBCS, 2008-2011, Version 4.0 10 Moderador o lider de la inspeccién: El lider y la principal persona responsable par una inspeccién u otro proceso de revision. Tenga en cuenta que el término "Ifder de inspeccién" no esta definido en el Glosario ISTQB, pero su utilizacién en El Programa de Estudios del ISTOB Nivel Bésico implica que es un sinénimo. Revision entre colegas (“peer review”) o Revision entre pares (“no es igual a pruebas por pares”): Una revision de un producto del trabajo de software por colegas del productor del producto con el propésito de identificar defectos y mejoras, Ejemplos son la inspeccién, revision técnica y revision guiada (“Walkthrough”) Pruebas por pares (“pair testing”, no es igual a Revision entre pares): Dos personas, por ejemplo dos probadores, un desarrollador y un probador o un usuario final y e un probador, trabajando juntas para detectar defectos. Normalmente comparten un tinico ordenador e intercambian el control del mismo durante las pruebas, Revisor: La persona involucrada en Ja revisién que identifica y describe anomalias en el producto o proyecto bajo revision. Los revisores pueden ser elegidos para representar los diferentes puntos de vista y roles en el proceso de revisién. Escribano: La.persona quien registra cada defecto mencionado y alguna sugerencia para la mejora del proceso.durante una reunién de revision, en un formulario. de registro. El escribano deberfa que garantizar que el formulario de registro es legil le y comprens: Revisin técnica: Una actividad de discusién de grupo entre pares (colegas) que se enfoca en lograr un consenso sobre el método técnico que deba tomarse, Véase también la revisién entre pares (colegas). e Revision guiada (Walkthrough): Una presentacién paso a paso por el autor de un documento con el fin de reunir informaci6n y establecer un entendimiento comin de su contenido. Véase también revision entre pares Compilador: Este término no esta definido en el glosario ISTQB. La politica del ISTQB es que los términos no definidos en el glosario no pueden ser incluidos en el examen. Complejidad: El grado en que un componente o sistema tiene un disefio y/o una estructura interna que es dificil de entender, mantener y verificar. Véase también la complejidad ciclomatica Flujo de control: Una secuencia de eventos (caminos) en la ejecucién a través de un \Copysght © RECS, 2008-201, Version 40 Ml componente o sistema. Flujo de datos: Una representacién abstracta de la secuencia y cambios posibles del estado de los objetos de datos, donde el estado de un objeto es cualquiera de los siguientes: creacién, uso, o destruccion. Andlisis estético: Andlisis de los artefactos del software, p.cj., requisites 0 eédigo, Hevados a cabo sin la ejecucién de estos artefactos del software. El andlisis estatico es usualmente Ilevado a cabo por una herramienta. Especificacién de casos de prueba: Un documento que especifica un conjunto de casos de prueba (objetivo, entradas, acciones de pruebas, resultados esperados, y las precondiciones de ejecucion) para un ftem de prueba, Disefio de pruebas: (1) Véase la especificacion de disefio de pruebas, de transformacién de los objetivos generales de pr tangibles y casos de prueba. ) El proceso ebas en condiciones de pruebas Especificacién del disefio de pruebas: Un documento que especifica las condiciones de prueba (items de cobertura) para un item de prueba, el método de pruebas detallado y la identificacion de los casos de prueba asociados de alto nivel. Tenga en cuenta que este término no se enuncié especificamente para esta secci6n, pero Io incluye aqui, ya que es un sinénimo de disesio de pruebas. Calendario de ejecucién de pruebas: Un esquema para la ejecucién de los procedimientos de prueba. Los procedimientos de prueba estén incluidos en el calendario de ejecucién de pruebas en su contexto y en el orden en el cual tienen que ser ejecutados. Especificacién del procedimiento de prueba: Un documento que especifica una secuencia de acciones para la ejecucién de una prueba. También conocido como guidn de prueba o guién de prueba manual, Guién de prueba: Comuinmente utilizado para referirse a una especificacion del procedimiento de prueba, especialmente uno automatizado Trazabilidad: La habilidad de identificar items relacionados en la documentacién y el software, tales como los requisitos con las pruebas asociadas. Véase taml trazabilidad horizontal, trazabilidad vertical. nla Técnica de disefio de pruebas de caja negra: Procedimiento para derivar y/o seleccionar casos de prueba basados en un anélisis de la especificacién, ya sea funcional o no funcional, de un componente o sistema sin referencia a su estructura Copyaight © RECS, 2008-2011, Version 4.0 interna, Técnica de diserio de pruebas basada en la experiencia: Este término no est definido en el Glosario ISTQB. La politica del ISTQB es que los términos no definidos en el glosario no pueden entrar en el examen. ‘Técnica de disefio de pruebas basada en la especificacién: Véase técnica de disefio de pruebas de caja negra Técnica de disefio de pruebas basada en la estructura: Este término no est definido enel glosario ISTOB, pero un término estrechamente relacionado, la técnica basada en la estructura, es definida como un sinénimo para la técnica de disefio de pruebas de caja blanca Técnica de disefio de pruebas de caja blanca: Procedimiento para derivar y/o seleccionar casos de prueba basados en un andlisis de la estructura interna de un componente o sistema, Aniélisis de valor limite: Una técnica de disefio de pruebas de caja negr: Jos casos de prueba son-di valor limite. Ja cual efiados basados en los valores limite. Véase también’ Valor limite deuna Un valor de entrada 0 valor de salida el cual se encuentra en el borde ticién de equivalencia o en la distancia incremental més pequefia en cada lado de un borde, por ejemplo, el valor minimo 0 maximo de un rango. Teng en cuenta que este término no se enuncié especificamente para esta seccién, pero se lo incluye aqui, ya que es esencial para comprender el término anélisis de valor limite. Pruebas de tabla de decision: Una técnica de disefio de pruebas de caja negra en ia cual los casos de prueba son disefiados para ejecutar las combinaciones de entradas y/o estimulos (causas) representadas en una tabla de decision, Véase también tabla de decision. Tabla de decision: Una tabla que muestra las combinaciones de entradas y/o estimulos (causas) con sus productos y/o acciones (efectos) asociados, los cuales pueden ser utilizados para diseftar casos de prueba. Tenga en cuenta que este término no se enuncié especificamente para esta seccién, pero se lo incluye aqui, ya que es esencial para comprender el término prueba de tablas de decisién. Particionamiento de equivalencia: Una técnica de disefio pruebas de caja negra enla CCopyeghe © RBCS, 2008-2011, 13 cual los casos de prueba son disefiados para ejecutar los representantes de las particiones de equivalencia. En principio, los casos de prueba son disefiados para cubrir cada particién por lo menos una vez. Particién de equivalencia: Una porcién de un dominio de entrada o salida para el cual se supone que el comportamiento de tn componente o sistema sea el mismo, asandose en la especificacion. Tenga en cuenta que este término no se enuncié especificamente para esta secciOn, pero se Jo incluye aqui, ya que es esencial para comprender el término particionamiento de equivalencia. Pruebas de transicién de estados: Una técnica de disefio de pruebas de caja enla cual los casos de prueba son disefiados para ejecutar transiciones de estado validas e invélidas. Véase también pruebas de conmutador de multiplicidad. Transicion'de estados: Una transicién entre dos estados de un componente 0 sistema Tenga en cuenta que este término no se enuncié especificamente para es seccién, pero se Io inchuye aqui, ya que es esencial para comprender pruebas de transicién de estado. 1 término Pruebas de casos de uso: Una técnica de disefio de pruebas de caja negra en la cual los casos de prueba son disefiados para ejecutar los escenarios de los casos de uso. Caso de uso: Una secuencia de transacciones en un diélogo entre un a componente o siste: tor y una na con un resultado tangible, donde un actor puede a usuario o cualquier cosa que pueda intercambiar informacion con el sistema.Tenga en cuenta que este término no se enuncié especificamente para esta seccién, pero se Jo incluye aqui, ya que es esencial para comprender el término pruebas de casos de uso. Cobertura de cédigo: Un método de anélisis que determina cudles partes del software han sido ejecutadas (cubiertas) por el juego de pruebas y cudles partes no han sido ejecutadas, p.c, cobertura de sentencia, cobertura de decision 0 cobertura de condicion Cobertura de decisién: El porcentaje de resultados de decision que hayan sido ercidos por un juego de pruebas. 100% de cobertura de decisién implica ambos 100% de cobertura de rama y 100% cobertura de sentencia. Cobertura de sentencia: El porcentaje de sentencias ejecutables que hayan sido ejercidas por un juego de pruebas. Pruebas basadas en la estructura: Vean pruebas de caja blanca 1 Version £0 14 Pruebas de caja blanca: Pruebas basadas en el andlisis de la estructura interna de una componente o sistema, Tome en cuenta de que el término no esta especificamente designado para esta seccién pero esté incluido aqui ya que es un sinénimo para pruebas basadas en la estructura. Pruebas exploratorias: Una técnica disefio de pruebas informal donde el probador controla activamente el disefio de las pruebas como aquellas pruebas son Ilevadas a cabo y utilizan informacién ganada mientras se prueba para disefiar pruebas nuevas y mejores. Ataque de'defectos: Véase ataque. Ataque: Intento dirigido y enfocado para evaluar la calidad, especialmente la e fiabilidad, de un objeto de prueba intentando de forzar que ocurran fallas especificas. Véase también pruebas negativas. Note que este termino no ha sido enunciado especificamente en esta secci6n pero es incluido aqui ya que es un sinonimo para ataque de defectos Pruebas negativas: Pruebas con el objetivo de mostrar que una componente o sistema no funciona. Las pruebas negativas estén relacionadas con la actitud de los probadores mAs que un método de pruebas especifico o una técnica de disefio de pruebas, p.¢j. las pruebas con valores de entrada invélidos o excepciones. Note que este término no es especificamente enunciado para esta seccién pero es incluido aqui ya que esté relacionado con el término ataque de defectos, Probador: Un profesional habil quién esté involucrado en las pruebas de una componente o sistema, Lider de pruebas: Véase jefe de pruebas. e Jefe de Pruebas: La persona responsable para la gestion del proyecto de las. actividades y recursos de pruebas, y evaluacin de un objeto de prueba. El dividuo quién dirige, controla, administra, planifica y regula la evaluaci6n de un objeto de prueba. ‘Método de prueba: La implementacién de la estrategia de pruebas para un proyecto espectfico. Tipicamente incluye las decisiones tomadas que siguen basadas en las metas del proyecto (de pruebas) y la evaluacién de los riesgos llevadas a cabo, puntos del principio con relacién al proceso de pruebas, las técnicas de disefio de pruebas a ser aplicadas, los criterios de salida y los tipos de pruebas a ser realizadas. © RBCS, 2008-2013, Version 40 15 Estrategia de pruebas: Una descripcién de alto nivel de los niveles de prueba a ser realizados y de las pruebas en aquellos niveles para una organizacién o programa (uno 0 més proyectos). Note que este término no es especificamente utilizado en esta seccién pero esta aqui incluido ya que es esencial para comprender el témino método de prueba. a Densidad de Defectos: El nimero de defectos identificados en una componente 0 sistema dividido por el tamafio de la componente o sistema (expresados en términos de medidas estndar, p.ej. Lineas de cédigo, ntimero de clases o puntos de funcién) asa de fallos: La proporcién del mimero de fallas del categoria dada para un unidad de medida dada, p.¢j. fallos por unidad de tiempo, fallos por el numero de transaccionés, fallos por el ntimero de ejecuciones en la computadora. Control de pruebas: Una tarea de gestion de pruebas que trata con el desarrollo y la aplicacién de un conjunto de acciones correctivas para encaminar un proyecto de pruebas cuando el monitoreo muestra una desviacién de lo que fue planificado. Vea también a la gestion de las pruebas. Monitoreo de las pruebas: Una tarea de la gestién de pruebas que trata con las actividades relacionadas a la comprobaci6n periddica del estado del proyecto de pruebas. Se preparan informes que comparan los estados reales con los planificados. Vea también la gestion de pruebas. Gestion de pruebas: La planificacién, la estimacién, el monitoreo y el control de las actividades de pruebas, tipicamente realizadas por un jefe de pruebas. Note que este término no esté siendo convocado especificamente para esta seccién pero es incluido aqui ya que es esencial para comprender los términos control de pruebas y monitoreo de pruebas. Informe de pruebas: Consulte el informe de resumen de pruebas. Informe de resumen de pruebas: Un documento que resume las actividades y resultados de las pruebas. Este contiene también una evaluacién de los items de pruebas correspondientes con los criterios de salida. La gestion de configuraciones: Una disciplina que aplica direcci6n y vigilancia técnica y administrativa para: identificar y documentar las caracteristicas funcionales y fisicas de un {tem de configuracién, controlar los cambios de aquellas caracteristicas, grabar e informar el estado del proceso de cambios y de la implementacién, y verificar la conformidad con los requisitos especificos. 16 El control de versiones: Consulte el control de versiones. El control de configuraciones: Un elemento de la gestién de configuraciones, que consiste de la evaluacién, la coordinacién, la aprobacién o la desaprobacién, e implementacién de cambios a los items de configuracién después de un establecimiento formal de su identificacién de configuracién. Note que este término no es especificamente llamado para esta seccién pero es incluido aqui ya que esta seccién es un sinénimo para el control de versiones. Riesgo de producto: Un riesgo relacionado directamente al objeto de pruebas. Vea también riesgo. Note que en este curso he utilizado el termino riesgo de calidad como un sinénimo para un producto. Riesgo de proyecto: Un riesgo relacionado con la gestion y control del proyecto (de e pruebas), p.¢j falta de personal, plazos estrictos, requisitos que cambian, etc. Vea también riesgo. Riesgo: Un factor que puede resultar en futuras consecuencias negativas; usualmente expresado como impacto y probabilidad. Pruebas basadas los riesgos: Un método para las pruebas para reducir el nivel de Jos riesgos del producto e informar a los interesados del negocio sobre su estado, comenzando en las etapas iniciales de un proyecto. Esto involucra la identificacin. de los riesgos del producto’y la utilizacién de los niveles de riesgos para guiar el proceso de pruebas. Registro de incidencias: Guardado de los detalles de cualquier incidencia que ocurri6, p.ej. durante las pruebas. Gestion de incidencias: El proceso de zeconocer, investigar, tomando accién y disponiendo de las incidencias. Esto involucra las incidencias registradas, clasific&ndolos e identificando el impacto. Herramienta de revision: Una herramienta que proporciona apoyo al proceso de revision. Caracteristicas tipicas incluyen la planificacién de la revision y el soporte del seguimiento, soporte de comunicaciones, revisiones colaborativas y un repositorio para reunir e informar sobre las métricas. Herramientas de seguridad: Una herramienta que apoya la seguridad operacional. Herramienta de pruebas de seguridad: Una herramienta que brinda soporte para probar las caracteristicas y vulnerabilidades de seguridad. Note que este término Copysght © RECS, 2008-2011, Version 40 7 no es enunciado especificamente en esta seccién, pero esté incluido aquf para ayudarle a comprender el término herramienta de seguridad, Herramienta de andlisis estatico: Vea analizador estatico. ‘Analizador estatico: Una herramienta que lleva a cabo el andlisis estatico. Note que este término no es enunciado especificamente para esta seccién pero esta incluido aqui desde que es un sinénimo para herramienta de anélisis estitico. Herramienta de pruebas de estrés: Una herramienta que apoya las pruebas de estrés. Pruebas de estrés. Un tipo de pruebas de rendimiento conducido para evaluar un sistema o componente en o més allé de los limites de sus cargas de trabajo anticipadas’o especificadas, o con una reducida disponibilidad de recursos tales como el accéso a la memoria 0 a los servidores. Vea también las pruebas de rendimiento, pruebas de carga. Note que este término no es especificamente enunciado para esta seccién, pero esté incluido aqui para ayudarle a comprender el término herramienta de pruebas de estrés Comparador de pruebas: Una herramienta de pruebas para realizar comparaciones de pruebas automatizadas de los resultados reales con resultados esperados. Herramienta de preparacién de datos de prueba: Un tipo de herramienta de pruebas que hacen posible la seleccion de datos de bases de datos existentes o ser creadas, generadas, manipuladas y editadas para su utilizacién en las pruebas. Herramienta de disefio de pruebas: Una herramienta que apoya la actividad del disefio de pruebas generando entradas de pruebas de una especificacién que puede ser mantenida en un repositorio de una herramienta CASE, p.¢) la herramienta de gestion de requisitos, de las condiciones de pruebas especificadas contenidas en misma herramienta, 0 del codigo. Arnés de pruebas: Un entorno de pruebas compuesto de stubs y drivers necesarios para ejecutar una prueba. Herramienta de ejecucién de pruebas: Un tipo de herramienta de pruebas que es capaz de ejecutar otro software utilizando un guién de pruebas automatizadas, p.

    También podría gustarte