software testing terms complete glossary
Para evitar las ambigüedades en los diferentes términos de prueba de software, adjunto un glosario de pruebas de software aquí.
Todos los términos de prueba de software se incluyen en este glosario. Si cree que conoce la definición de cualquier término mejor que el mencionado aquí, puede usar este Formulario de contacto para enviarme las definiciones. Al revisarlos, los incluiré en este glosario.
Para conocer las definiciones básicas de pruebas de software y aseguramiento de la calidad, este es el mejor glosario compilado por Erik van Veenendaal . También para cada definición hay una referencia de IEEE o ISO mencionada entre paréntesis.
A
criterios de aceptación: Los criterios de salida que debe satisfacer un componente o sistema para seraceptado por un usuario, cliente u otra entidad autorizada. (IEEE 610)
test de aceptación: Pruebas formales con respecto a las necesidades del usuario, los requisitos y los procesos comerciales realizados para determinar si un sistema satisface o no los criterios de aceptación y para permitir al usuario, los clientes u otra entidad autorizada determinar si aceptar o no el sistema. (Después de IEEE 610)
pruebas de accesibilidad: Pruebas para determinar la facilidad con la que los usuarios con discapacidades pueden usar un componente o sistema. (Gerrard)
precisión: La capacidad del producto de software para proporcionar los resultados o efectos correctos o acordados con el grado de precisión necesario. (ISO 9126) Consulte también pruebas de funcionalidad.
resultado actual: El comportamiento producido / observado cuando se prueba un componente o sistema.
pruebas ad hoc: Pruebas realizadas de manera informal; no se lleva a cabo una preparación formal de la prueba, no se utiliza ninguna técnica de diseño de prueba reconocida, no hay expectativas de resultados y la aleatoriedad guía la actividad de ejecución de la prueba.
adaptabilidad: La capacidad del producto software para adaptarse a diferentes entornos especificados sin aplicar acciones o medios distintos a los previstos para este fin para el software considerado. (ISO 9126) Consulte también pruebas de portabilidad.
pruebas ágiles: Práctica de prueba para un proyecto utilizando metodologías ágiles, como programación extrema (XP), tratando el desarrollo como el cliente de las pruebas y enfatizando el paradigma de diseño de prueba primero.
prueba alfa: Pruebas operativas simuladas o reales por usuarios / clientes potenciales o un equipo de prueba independiente en el sitio de los desarrolladores, pero fuera de la organización de desarrollo. Las pruebas alfa se emplean a menudo como una forma de prueba de aceptación interna.
analizabilidad: La capacidad del producto de software para diagnosticar deficiencias o causas de fallas en el software, o para identificar las piezas que se modificarán. (ISO 9126) Ver también pruebas de mantenibilidad.
anomalía: Cualquier condición que se desvíe de las expectativas basadas en especificaciones de requisitos, documentos de diseño, documentos de usuario, estándares, etc. o de la percepción o experiencia de alguien. Se pueden encontrar anomalías durante, entre otros, la revisión, prueba, análisis, compilación o uso de productos de software o documentación aplicable. (IEEE 1044) Véase también defecto, desviación, error, falla, falla, incidente, problema.
atractivo: La capacidad del producto de software para ser atractivo para el usuario. (ISO 9126)
auditoría: Una evaluación independiente de los productos o procesos de software para determinar el cumplimiento de estándares, directrices, especificaciones y / o procedimientos basados en criterios objetivos, incluidos documentos que especifican:
(1) la forma o el contenido de los productos a producir
(2) el proceso por el cual se producirán los productos
(3) cómo se medirá el cumplimiento de las normas o directrices. (IEEE 1028)
pista de auditoría: Una ruta por la cual la entrada original a un proceso (por ejemplo, datos) se puede rastrear a través del proceso, tomando la salida del proceso como punto de partida. Esto facilita el análisis de defectos y permite realizar una auditoría de proceso. (Después de TMap)
software de prueba automatizado: Testware utilizado en pruebas automatizadas, como scripts de herramientas.
disponibilidad: El grado en el que un componente o sistema es operativo y accesible cuando se requiere para su uso. A menudo se expresa como porcentaje. (IEEE 610)
B
pruebas consecutivas: Pruebas en las que se ejecutan dos o más variantes de un componente o sistema con las mismas entradas, se comparan las salidas y se analizan en caso de discrepancias. (IEEE 610)
base: Una especificación o producto de software que se ha revisado o acordado formalmente, que a partir de entonces sirve como base para un mayor desarrollo y que solo se puede cambiar mediante un proceso formal de control de cambios. (Después de IEEE 610)
bloque básico: Una secuencia de una o más sentencias ejecutables consecutivas que no contienen ramas.
conjunto de prueba de base: Un conjunto de casos de prueba derivados de la estructura o especificación interna para garantizar que se alcance el 100% de un criterio de cobertura especificado.
comportamiento: La respuesta de un componente o sistema a un conjunto de valores de entrada y condiciones previas.
prueba de referencia: (1) Un estándar con el que se pueden realizar mediciones o comparaciones. (2) Una prueba que se usa para comparar componentes o sistemas entre sí o con un estándar como en (1). (Después de IEEE 610)
software a medida: Software desarrollado específicamente para un conjunto de usuarios o clientes. Lo opuesto es el software estándar.
mejores prácticas: Un método superior o una práctica innovadora que contribuye a mejorar el desempeño de una organización en un contexto dado, generalmente reconocido como 'mejor' por otras organizaciones pares.
prueba beta: Pruebas operativas realizadas por usuarios / clientes potenciales y / o existentes en un sitio externo que no esté involucrado de otra manera con los desarrolladores, para determinar si un componente o sistema satisface las necesidades del usuario / cliente y se ajusta a los procesos comerciales. Las pruebas beta a menudo se emplean como una forma de prueba de aceptación externa para obtener comentarios del mercado.
prueba de big-bang: Un tipo de prueba de integración en la que los elementos de software, los elementos de hardware o ambos se combinan de una vez en un componente o un sistema general, en lugar de en etapas. (Después de IEEE 610) Consulte también pruebas de integración.
prueba de caja negra: Pruebas, ya sean funcionales o no funcionales, sin referencia a la estructura interna del componente o sistema.
técnicas de diseño de prueba de caja negra: Procedimiento documentado para derivar y 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 interna.
caso de prueba bloqueado: Un caso de prueba que no se puede ejecutar porque no se cumplen las condiciones previas para su ejecución.
prueba de abajo hacia arriba: Un enfoque incremental para las pruebas de integración en el que los componentes de nivel más bajo se prueban primero y luego se utilizan para facilitar la prueba de componentes de nivel superior. Este proceso se repite hasta que se prueba el componente en la parte superior de la jerarquía. Consulte también pruebas de integración.
valor límite: Un valor de entrada o valor de salida que se encuentra en el borde de una partición de equivalencia o en la distancia incremental más pequeña a cada lado de un borde, por ejemplo, el valor mínimo o máximo de un rango.
análisis de valor límite: Una técnica de diseño de prueba de caja negra en la que los casos de prueba se diseñan en función de los valores límite.
cobertura del valor límite: El porcentaje de valores límite que ha sido ejercido por un conjunto de pruebas.
rama: Un bloque básico que puede seleccionarse para su ejecución basándose en una construcción de programa en la que están disponibles una de dos o más rutas de programa alternativas, p. caso, saltar, ir a, si entonces- de lo contrario.
el algoritmo de dijkstra usando la cola de prioridad java
cobertura de sucursales: El porcentaje de sucursales que ha ejercido una suite de pruebas. La cobertura del 100% de la sucursal implica tanto una cobertura de decisión del 100% como una cobertura de declaración del 100%.
prueba de rama: Una técnica de diseño de prueba de caja blanca en la que los casos de prueba están diseñados para ejecutar ramas.
pruebas basadas en procesos comerciales: Un enfoque de las pruebas en el que los casos de prueba se diseñan en función de las descripciones y / o el conocimiento de los procesos comerciales.
C
Modelo de madurez de capacidad (CMM): Un marco por etapas de cinco niveles que describe los elementos clave de un proceso de software eficaz. El modelo de madurez de la capacidad cubre las prácticas de planificación, ingeniería y gestión del desarrollo y mantenimiento de software. (CMM)
Integración del modelo de madurez de capacidad (CMMI): Un marco que describe los elementos clave de un proceso efectivo de desarrollo y mantenimiento de productos. La integración del modelo de madurez de capacidad cubre prácticas para la planificación, ingeniería y gestión del desarrollo y mantenimiento de productos. CMMI es el sucesor designado del CMM. (CMMI)
herramienta de captura / reproducción: Un tipo de herramienta de ejecución de prueba donde las entradas se registran durante la prueba manual para generar scripts de prueba automatizados que se pueden ejecutar más tarde (es decir, reproducir). Estas herramientas se utilizan a menudo para respaldar las pruebas de regresión automatizadas.
CASO: Acrónimo de Ingeniería de Software Asistida por Computadora.
EMITIR: Acrónimo de pruebas de software asistidas por computadora. Consulte también automatización de pruebas.
gráfico de causa-efecto: Una representación gráfica de entradas y / o estímulos (causas) con sus salidas asociadas (efectos), que se puede utilizar para diseñar casos de prueba.
gráficos de causa-efecto: Una técnica de diseño de prueba de caja negra en la que los casos de prueba se diseñan a partir de gráficos de causa-efecto. (BS 7925/2)
Certificación: El proceso de confirmar que un componente, sistema o persona cumple con sus requisitos especificados, p. Ej. pasando un examen.
posibilidad de cambiar: La capacidad del producto de software para permitir la implementación de modificaciones específicas. (ISO 9126) Véase también mantenibilidad.
método de árbol de clasificación: Una técnica de diseño de prueba de caja negra en la que los casos de prueba, descritos por medio de un árbol de clasificación, están diseñados para ejecutar combinaciones de representantes de dominios de entrada y / o salida. (Grochtmann)
cobertura de código: Un método de análisis que determina qué partes del software han sido ejecutadas (cubiertas) por el conjunto de pruebas y qué partes no se han ejecutado, p. cobertura de declaración, cobertura de decisión o cobertura de condición.
coexistencia: La capacidad del producto de software para coexistir con otro software independiente en un entorno común que comparte recursos comunes. (ISO 9126) Consulte las pruebas de portabilidad.
complejidad: El grado en el que un componente o sistema tiene un diseño y / o estructura interna que es difícil de entender, mantener y verificar. Ver también complejidad ciclomática.
cumplimiento: La capacidad del producto de software para adherirse a estándares, convenciones o regulaciones en leyes y prescripciones similares. (ISO 9126)
pruebas de conformidad : El proceso de prueba para determinar la conformidad de un componente o sistema.
componente: Un elemento de software mínimo que se puede probar de forma aislada.
prueba de integración de componentes: Pruebas realizadas para exponer defectos en las interfaces y la interacción entre componentes integrados.
especificación del componente: Una descripción de la función de un componente en términos de sus valores de salida para valores de entrada especificados en condiciones específicas y comportamiento no funcional requerido (por ejemplo, utilización de recursos).
prueba de componentes: La prueba de componentes de software individuales. (Después de IEEE 610)
condición compuesta: Dos o más condiciones únicas unidas por medio de un operador lógico (Y, O o XOR), p. Ej. 'A> B Y C> 1000'.
prueba de concurrencia: Pruebas para determinar cómo la ocurrencia de dos o más actividades dentro del mismo intervalo de tiempo, lograda ya sea intercalando las actividades o mediante la ejecución simultánea, es manejada por el componente o sistema. (Después de IEEE 610)
condición: Una expresión lógica que puede evaluarse como verdadera o falsa, p. Ej. A> B. Consulte también condición de prueba.
cobertura de condición: El porcentaje de resultados de condición que se han ejercido en un conjunto de pruebas. La cobertura de condición del 100% requiere que cada condición en cada declaración de decisión se pruebe como Verdadera y Falsa.
cobertura de determinación de condición: El porcentaje de todos los resultados de una sola condición que afectan de forma independiente un resultado de decisión que ha sido ejercido por un conjunto de casos de prueba. La cobertura de determinación de condición del 100% implica una cobertura de condición de decisión del 100%.
prueba de determinación de condición: Una técnica de diseño de prueba de caja blanca en la que los casos de prueba están diseñados para ejecutar resultados de condición única que afectan de forma independiente el resultado de una decisión.
prueba de condición: Una técnica de diseño de prueba de caja blanca en la que los casos de prueba están diseñados para ejecutar resultados de condiciones.
resultado de la condición: La evaluación de una condición a Verdadero o Falso.
configuración: La composición de un componente o sistema definido por el número, la naturaleza y las interconexiones de sus partes constituyentes.
auditoría de configuración: La función para verificar el contenido de las bibliotecas de elementos de configuración, p. Ej. para el cumplimiento de las normas. (IEEE 610)
control de configuración: Un elemento de gestión de la configuración, que consiste en la evaluación, coordinación, aprobación o desaprobación e implementación de cambios en los elementos de configuración después del establecimiento formal de su identificación de configuración. (IEEE
610)
identificación de configuración: Elemento de la gestión de la configuración, que consiste en seleccionar los elementos de configuración de un sistema y registrar sus características funcionales y físicas en la documentación técnica. (IEEE 610)
elemento de configuración: Una agregación de hardware, software o ambos, que se designa para la gestión de la configuración y se trata como una sola entidad en el proceso de gestión de la configuración. (IEEE 610)
gestión de la configuración: Una disciplina que aplica la dirección y vigilancia técnica y administrativa para: identificar y documentar las características funcionales y físicas de un elemento de configuración, controlar los cambios en esas características, registrar e informar el estado de implementación y procesamiento de cambios y verificar el cumplimiento de los requisitos especificados. (IEEE 610)
consistencia: El grado de uniformidad, estandarización y ausencia de contradicciones entre los documentos o partes de un componente o sistema. (IEEE 610)
flujo de control: Una representación abstracta de todas las posibles secuencias de eventos (rutas) en la ejecución a través de un componente o sistema.
prueba de conversión: Prueba de software utilizado para convertir datos de sistemas existentes para su uso en sistemas de reemplazo.
CUNAS: Acrónimo de software comercial listo para usar.
cobertura: El grado, expresado como porcentaje, en el que un conjunto de pruebas ha ejercido un elemento de cobertura específico.
análisis de cobertura: Medición de la cobertura alcanzada para un elemento de cobertura especificado durante la ejecución de la prueba en referencia a criterios predeterminados para determinar si se requieren pruebas adicionales y, de ser así, qué casos de prueba se necesitan.
artículo de cobertura: Una entidad o propiedad utilizada como base para la cobertura de la prueba, p. Ej. particiones de equivalencia o declaraciones de código.
herramienta de cobertura: Una herramienta que proporciona medidas objetivas de qué elementos estructurales, p. Ej. declaraciones, las ramas han sido ejercidas por la suite de pruebas.
Complejidad ciclomática: El número de rutas independientes a través de un programa. La complejidad ciclomática se define como: L - N + 2P, donde -L = el número de bordes / enlaces en un gráfico -N = el número de nodos en un gráfico - P = el número de partes desconectadas del gráfico (por ejemplo, un gráfico de llamada y una subrutina). (Después de McCabe)
D
definición de datos: Una declaración ejecutable en la que se asigna un valor a una variable.
pruebas basadas en datos: Una técnica de secuencia de comandos que almacena la entrada de la prueba y los resultados esperados en una tabla u hoja de cálculo, de modo que una sola secuencia de comandos de control pueda ejecutar todas las pruebas en la tabla. Las pruebas basadas en datos se utilizan a menudo para respaldar la aplicación de herramientas de ejecución de pruebas, como las herramientas de captura / reproducción. (Fewster y Graham) Consulte también pruebas basadas en palabras clave.
flujo de datos: Una representación abstracta de la secuencia y posibles cambios del estado de los objetos de datos, donde el estado de un objeto es cualquiera de:creación, uso o destrucción. (Beizer)
análisis de flujo de datos: Una forma de análisis estático basado en la definición y uso de variables.
cobertura del flujo de datos: El porcentaje de pares de definición-uso que ha sido ejercido por un conjunto de casos de prueba.
prueba de flujo de datos: Una técnica de diseño de prueba de caja blanca en la que los casos de prueba están diseñados para ejecutar la definición y usar pares de variables.
depuración: El proceso de encontrar, analizar y eliminar las causas de fallas en el software.
herramienta de depuración: Una herramienta que utilizan los programadores para reproducir fallos, investigar el estado de los programas y encontrar el defecto correspondiente. Los depuradores permiten a los programadores ejecutar programas paso a paso, detener un programa en cualquier instrucción del programa y establecer y examinar las variables del programa.
decisión: Un punto del programa en el que el flujo de control tiene dos o más rutas alternativas. Un nodo con dos o más enlaces para separar ramas.
cobertura de condición de decisión: El porcentaje de todos los resultados de condiciones y resultados de decisiones que se han ejercido en un conjunto de pruebas. La cobertura del 100% de condiciones de decisión implica tanto una cobertura de 100% de condiciones como una cobertura de decisiones del 100%.
prueba de condición de decisión: Una técnica de diseño de prueba de caja blanca en la que los casos de prueba están diseñados para ejecutar resultados de condiciones y resultados de decisiones.
cobertura de decisiones: El porcentaje de resultados de decisiones que han sido ejercitados por un conjunto de pruebas. La cobertura de decisiones del 100% implica una cobertura de sucursales del 100% y una cobertura del estado de cuenta del 100%.
tabla de decisiones: Una tabla que muestra combinaciones de entradas y / o estímulos (causas) con sus salidas y / o acciones (efectos) asociados, que se pueden utilizar para diseñar casos de prueba.
prueba de la tabla de decisiones: Técnicas de diseño de pruebas de caja negra en las que los casos de prueba están diseñados para ejecutar las combinaciones de entradas y / o estímulos (causas) que se muestran en una tabla de decisión. (Veenendaal)
prueba de decisión: Una técnica de diseño de prueba de caja blanca en la que los casos de prueba están diseñados para ejecutar resultados de decisiones.
resultado de la decisión: El resultado de una decisión (que por tanto determina las ramas a tomar).
defecto: Un defecto en un componente o sistema que puede hacer que el componente o sistema no realice su función requerida, p. Ej. una declaración o definición de datos incorrecta. Si se encuentra un defecto durante la ejecución, puede provocar una falla del componente o del sistema.
densidad de defectos: El número de defectos identificados en un componente o sistema dividido por el tamaño del componente o sistema (expresado en términos de medición estándar, por ejemplo, líneas de código, número de clases o puntos de función).
Porcentaje de detección de defectos (DDP): el número de defectos encontrados por una fase de prueba, dividido por el número encontrado por esa fase de prueba y cualquier otro medio posterior.
informe de defectos: Un documento que informa sobre cualquier falla en un componente o sistema que puede causar que el componente o sistema no cumpla con su función requerida. (Después de IEEE 829)
gestión de defectos: El proceso de reconocer, investigar, tomar medidas y eliminar los defectos. Implica registrar los defectos, clasificarlos e identificar el impacto. (Después de IEEE 1044)
enmascaramiento de defectos: Suceso en el que un defecto impide la detección de otro. (Después de IEEE 610)
par definición-uso: La asociación de la definición de una variable con el uso de esa variable. Los usos variables incluyen computacional (por ejemplo, multiplicación) o para dirigir la ejecución de una ruta (uso de 'predicado').
entregable: Cualquier producto (de trabajo) que deba entregarse a otra persona que no sea el autor del producto (de trabajo).
pruebas basadas en el diseño: Un enfoque para las pruebas en el que los casos de prueba se diseñan en función de la arquitectura y / o el diseño detallado de un componente o sistema (por ejemplo, pruebas de interfaces entre componentes o sistemas).
comprobación de escritorio: Prueba de software o especificación mediante simulación manual de su ejecución.
pruebas de desarrollo: Pruebas formales o informales realizadas durante la implementación de un componente o sistema, generalmente en el entorno de desarrollo por parte de los desarrolladores. (Después de IEEE 610)
pruebas de documentación: Probar la calidad de la documentación, p. Ej. guía de usuario o guía de instalación.
dominio: El conjunto del que se pueden seleccionar valores de entrada y / o salida válidos.
conductor: Un componente de software o herramienta de prueba que reemplaza un componente que se encarga del control y / o la llamada de un componente o sistema. (Después de TMap)
análisis dinámico: El proceso de evaluación del comportamiento, p. Ej. rendimiento de la memoria, uso de la CPU, de un sistema o componente durante la ejecución. (Después de IEEE 610)
comparación dinámica: Comparación de los resultados reales y esperados, realizada mientras se ejecuta el software, por ejemplo, mediante una herramienta de ejecución de pruebas.
prueba dinámica: Pruebas que implican la ejecución del software de un componente o sistema.
ES
eficiencia: La capacidad del producto de software para proporcionar un rendimiento adecuado, en relación con la cantidad de recursos utilizados en las condiciones establecidas. (ISO 9126)
prueba de eficiencia: El proceso de prueba para determinar la eficiencia de un producto de software.
prueba de comparación elemental: Técnicas de diseño de pruebas de caja negra en las que los casos de prueba están diseñados para ejecutar combinaciones de entradas utilizando el concepto de cobertura de determinación de condición. (TMap)
emulador: Dispositivo, programa de computadora o sistema que acepta las mismas entradas y produce las mismas salidas que un sistema dado. (IEEE 610) Véase también simulador.
criterio para entrar: el conjunto de condiciones genéricas y específicas para permitir que un proceso avance con una tarea definida, p. fase de prueba. El propósito de los criterios de entrada es evitar que se inicie una tarea que implicaría más esfuerzo (desperdiciado) en comparación con el esfuerzo necesario para eliminar los criterios de entrada fallidos. (Gilb y Graham)
punto de entrada: La primera declaración ejecutable dentro de un componente.
partición de equivalencia: Porción de un dominio de entrada o salida para el que se supone que el comportamiento de un componente o sistema es el mismo, según la especificación.
cobertura de partición de equivalencia: El porcentaje de particiones de equivalencia que ha ejercido una suite de pruebas.
partición de equivalencia: Una técnica de diseño de prueba de caja negra en la que los casos de prueba están diseñados para ejecutar representantes de particiones de equivalencia. En principio, los casos de prueba están diseñados para cubrir cada partición al menos una vez.
error: Una acción humana que produce un resultado incorrecto. (Después de IEEE 610)
adivinar error: Una técnica de diseño de prueba en la que se utiliza la experiencia del probador para anticipar qué defectos pueden estar presentes en el componente o sistema bajo prueba como resultado de errores cometidos, y para diseñar pruebas específicamente para exponerlos.
error de siembra: El proceso de agregar intencionalmente defectos conocidos a los que ya están en el componente o sistema con el fin de monitorear la tasa de detección y eliminación, y estimar el número de defectos restantes. (IEEE 610)
tolerancia a errores: La capacidad de un sistema o componente para continuar el funcionamiento normal a pesar de la presencia de entradas erróneas. (Después de IEEE 610).
manejo de excepciones: Comportamiento de un componente o sistema en respuesta a una entrada errónea, ya sea de un usuario humano o de otro componente o sistema, oa una falla interna.
declaración ejecutable: Una declaración que, cuando se compila, se traduce en código objeto, y que se ejecutará de forma procedimental cuando el programa se esté ejecutando y puede realizar una acción sobre los datos.
ejercido: Se dice que un elemento de programa es ejercido por un caso de prueba cuando el valor de entrada provoca la ejecución de ese elemento, como una declaración, decisión u otro elemento estructural.
pruebas exhaustivas: Un enfoque de prueba en el que el conjunto de pruebas comprende todas las combinaciones de valores de entrada y condiciones previas.
criterio de salida: Conjunto de condiciones genéricas y específicas, consensuadas con los grupos de interés, para permitir la culminación oficial de un proceso. El propósito de los criterios de salida es evitar que una tarea se considere completada cuando todavía hay partes pendientes de la tarea que no se han terminado. Los criterios de salida se utilizan en las pruebas para informar y planificar cuándo detener las pruebas. (Después de Gilb y Graham)
punto de salida: La última instrucción ejecutable dentro de un componente.
Resultado Esperado: El comportamiento predicho por la especificación, u otra fuente, del componente o sistema en condiciones específicas.
prueba exploratoria: Pruebas donde el probador controla activamente el diseño de las pruebas a medida que se realizan y utiliza la información obtenida durante las pruebas para diseñar pruebas nuevas y mejores. (Llevar una vida de soltero)
F
fallar: Se considera que una prueba falla si su resultado real no coincide con el resultado esperado.
falla: Desviación real del componente o sistema de su entrega, servicio o resultado esperado. (Después de Fenton)
modo de fallo: La manifestación física o funcional de una falla. Por ejemplo, un sistema en modo de falla puede caracterizarse por un funcionamiento lento, salidas incorrectas o la terminación completa de la ejecución.
Análisis de modo y efecto de falla (FMEA): Un enfoque sistemático para la identificación y análisis de riesgos para identificar posibles modos de falla e intentar prevenir su ocurrencia.
tasa de fracaso: La relación entre el número de fallos de una categoría determinada y una unidad de medida determinada, p. Ej. fallas por unidad de tiempo, fallas por número de transacciones, fallas por número de ejecuciones de computadora. (IEEE 610)
Tolerancia a fallos: La capacidad del producto de software para mantener un nivel específico de rendimiento en casos de fallas (defectos) del software o de infracción de su interfaz especificada. (ISO 9126) Véase también fiabilidad.
análisis del árbol de fallos: Un método utilizado para analizar las causas de fallas (defectos).
camino factible: Una ruta para la que existe un conjunto de valores de entrada y condiciones previas que hace que se ejecute.
característica: Un atributo de un componente o sistema especificado o implícito en la documentación de requisitos (por ejemplo, confiabilidad, usabilidad o restricciones de diseño). (Después de IEEE 1008)
máquina de estados finitos: Un modelo computacional que consta de un número finito de estados y transiciones entre esos estados, posiblemente con acciones acompañantes. (IEEE 610)
revisión formal: Una revisión caracterizada por procedimientos y requisitos documentados, p. Ej. inspección.
base de prueba congelada: Un documento de base de prueba que solo puede modificarse mediante un proceso formal de control de cambios. Ver también línea de base.
Análisis de puntos de función (FPA): Método que tiene como objetivo medir el tamaño de la funcionalidad de un sistema de información. La medición es independiente de la tecnología. Esta medición puede usarse como base para la medición de la productividad, la estimación de los recursos necesarios y el control del proyecto.
integración funcional: Un enfoque de integración que combina los componentes o sistemas con el fin de lograr que una funcionalidad básica funcione de manera temprana. Consulte también pruebas de integración.
requerimiento funcional: Un requisito que especifica una función que debe realizar un componente o sistema. (IEEE 610)
técnica de diseño de prueba funcional: Procedimiento documentado para derivar y seleccionar casos de prueba basados en un análisis de la especificación de la funcionalidad de un componente o sistema sin referencia a su estructura interna. Véase también técnica de diseño de prueba de caja negra.
prueba funcional: Pruebas basadas en un análisis de la especificación de la funcionalidad de un componente o sistema. Consulte también pruebas de caja negra.
funcionalidad: La capacidad del producto de software para proporcionar funciones que satisfagan las necesidades declaradas e implícitas cuando el software se utiliza en condiciones específicas. (ISO 9126)
prueba de funcionalidad: El proceso de prueba para determinar la funcionalidad de un producto de software.
GRAMO
prueba de caja de vidrio: Ver prueba de caja blanca.
H
evaluación heurística: Una técnica de prueba de usabilidad estática para determinar el cumplimiento de una interfaz de usuario con principios de usabilidad reconocidos (los llamados “heurísticos”).
caso de prueba de alto nivel: Un caso de prueba sin valores concretos (nivel de implementación) para los datos de entrada y los resultados esperados.
trazabilidad horizontal: El seguimiento de los requisitos para un nivel de prueba a través de las capas de documentación de prueba (por ejemplo, plan de prueba, especificación de diseño de prueba, especificación de caso de prueba y especificación de procedimiento de prueba).
I
análisis de impacto: La evaluación del cambio en las capas de documentación de desarrollo, documentación de prueba y componentes, con el fin de implementar un cambio dado a los requisitos especificados.
modelo de desarrollo incremental: Un ciclo de vida de desarrollo en el que un proyecto se divide en una serie de incrementos, cada uno de los cuales ofrece una parte de la funcionalidad de los requisitos generales del proyecto. Los requisitos se priorizan y se entregan en orden de prioridad en el incremento apropiado. En algunas (pero no en todas) las versiones de este modelo de ciclo de vida, cada subproyecto sigue un 'mini modelo en V' con sus propias fases de diseño, codificación y prueba.
prueba incremental: Pruebas donde los componentes o sistemas se integran y prueban uno o algunos a la vez, hasta que todos los componentes o sistemas están integrados y probados.
incidente: Cualquier evento que ocurra durante las pruebas que requiera investigación. (Después de IEEE 1008)
administracion de incidentes: El proceso de reconocimiento, investigación, actuación y resolución de incidentes. Implica registrar las incidencias, clasificarlas e identificar el impacto. (Después de IEEE 1044)
herramienta de gestión de incidentes: Una herramienta que facilita el registro y seguimiento del estado de los incidentes encontrados durante las pruebas. A menudo tienen instalaciones orientadas al flujo de trabajo para rastrear y controlar la asignación, corrección y nueva prueba de incidentes y proporcionar instalaciones de informes.
reporte de incidente: Un documento que informa sobre cualquier evento que ocurra durante la prueba que requiera investigación. (Después de IEEE 829)
independencia: Separación de responsabilidades, lo que favorece la realización de pruebas objetivas. (Después de DO-178b)
camino inviable: Una ruta que no puede ser ejercida por ningún conjunto de posibles valores de entrada.
revisión informal: Una revisión que no se basa en un procedimiento formal (documentado).
aporte: Una variable (ya sea almacenada dentro o fuera de un componente) que es leída por un componente.
dominio de entrada: El conjunto del que se pueden seleccionar valores de entrada válidos. Véase también dominio.
valor de entrada: Una instancia de una entrada. Ver también entrada.
inspección: Un tipo de revisión que se basa en el examen visual de documentos para detectar defectos, p. Ej. violaciones de los estándares de desarrollo y no conformidad con la documentación de nivel superior. La técnica de revisión más formal y, por tanto, siempre basada en un procedimiento documentado. (Después de IEEE 610, IEEE 1028)
instalabilidad: La capacidad del producto de software para instalarse en un entorno específico (ISO 9126). Consulte también portabilidad.
prueba de instalabilidad: El proceso de probar la instalabilidad de un producto de software. Consulte también pruebas de portabilidad.
guía de instalación: Se proporcionan instrucciones en cualquier soporte adecuado, que guía al instalador a través del proceso de instalación. Puede ser una guía manual, un procedimiento paso a paso, un asistente de instalación o cualquier otra descripción de proceso similar.
asistente de instalación: Software suministrado en cualquier medio adecuado, que guía al instalador a través del proceso de instalación. Normalmente ejecuta el proceso de instalación, proporciona comentarios sobre los resultados de la instalación y solicita opciones.
instrumentación: La inserción de código adicional en el programa para recopilar información sobre el comportamiento del programa durante la ejecución.
instrumentos: Una herramienta de software que se utiliza para realizar instrumentación.
prueba de admisión: Una instancia especial de una prueba de humo para decidir si el componente o sistema está listo para pruebas detalladas y adicionales. Normalmente, una prueba de admisión se realiza al comienzo de la fase de ejecución de la prueba.
integración: El proceso de combinar componentes o sistemas en conjuntos más grandes.
pruebas de integración: Pruebas realizadas para exponer defectos en las interfaces y en las interacciones entre componentes o sistemas integrados. Consulte también pruebas de integración de componentes, pruebas de integración de sistemas.
prueba de interfaz: Un tipo de prueba de integración que se ocupa de probar las interfaces entre componentes o sistemas.
interoperabilidad: La capacidad del producto de software para interactuar con uno o más componentes o sistemas específicos. (Después de ISO 9126) Consulte también la funcionalidad.
pruebas de interoperabilidad: El proceso de prueba para determinar la interoperabilidad de un producto de software. Consulte también pruebas de funcionalidad.
prueba no válida: Prueba usando valores de entrada que deberían ser rechazados por el componente o sistema. Consulte también tolerancia a errores.
prueba de aislamiento: Pruebas de componentes individuales aislados de los componentes circundantes, simulando los componentes circundantes mediante stubs y controladores, si es necesario.
A
pruebas basadas en palabras clave: Una técnica de secuencia de comandos que utiliza archivos de datos para contener no solo datos de prueba y resultados esperados, sino también palabras clave relacionadas con la aplicación que se está probando. Las palabras clave se interpretan mediante scripts de apoyo especiales que son llamados por el script de control para la prueba. Consulte también pruebas basadas en datos.
L
LCSAJ: Una secuencia de código lineal y salto, que consta de los siguientes tres elementos (identificados convencionalmente por números de línea en una lista de código fuente): el comienzo de la secuencia lineal de declaraciones ejecutables, el final de la secuencia lineal y la línea de destino a la que se controla el flujo se transfiere al final de la secuencia lineal.
Cobertura LCSAJ: El porcentaje de LCSAJ de un componente que ha sido ejercido por un conjunto de pruebas. La cobertura del 100% de LCSAJ implica una cobertura de decisión del 100%.
Pruebas LCSAJ: Una técnica de diseño de prueba de caja blanca en la que los casos de prueba están diseñados para ejecutar LCSAJ.
capacidad de aprendizaje: La capacidad del producto de software para permitir que el usuario aprenda su aplicación. (ISO 9126) Véase también usabilidad.
prueba de carga: Un tipo de prueba que se ocupa de medir el comportamiento de un componente o sistema con carga creciente, p. número de usuarios paralelos y / o número de transacciones para determinar qué carga puede manejar el componente o sistema.
caso de prueba de bajo nivel: Un caso de prueba con valores concretos (nivel de implementación) para los datos de entrada y los resultados esperados.
METRO
mantenimiento: Modificación de un producto de software después de la entrega para corregir defectos, mejorar el rendimiento u otros atributos, o para adaptar el producto a un entorno modificado. (IEEE 1219)
pruebas de mantenimiento: Probar los cambios en un sistema operativo o el impacto de un entorno cambiado en un sistema operativo.
mantenibilidad: La facilidad con la que un producto de software puede modificarse para corregir defectos, modificarse para cumplir con nuevos requisitos, modificarse para facilitar el mantenimiento futuro o adaptarse a un entorno modificado. (ISO 9126)
pruebas de mantenibilidad: El proceso de prueba para determinar la capacidad de mantenimiento de un producto de software.
revisión de gestión: Una evaluación sistemática del proceso de adquisición, suministro, desarrollo, operación o mantenimiento de software, realizada por o en nombre de la gerencia que monitorea el progreso, determina el estado de los planes y programas, confirma los requisitos y la asignación de su sistema, o evalúa la efectividad de los enfoques de gestión. para lograr la aptitud para el propósito. (Después de IEEE 610, IEEE 1028)
madurez: (1) La capacidad de una organización con respecto a la eficacia y eficiencia de sus procesos y prácticas laborales. Consulte también Modelo de madurez de capacidad, Modelo de madurez de prueba. (2) La capacidad del producto de software para evitar fallas como resultado de defectos en el software. (ISO 9126) Véase también fiabilidad.
la medida: El número o categoría asignada a un atributo de una entidad al realizar una medición (ISO 14598).
medición: El proceso de asignar un número o categoría a una entidad para describir un atributo de esa entidad. (ISO 14598)
escala de medición: Una escala que restringe el tipo de análisis de datos que se puede realizar en ella. (ISO 14598)
pérdida de memoria: Un defecto en la lógica de asignación de almacenamiento dinámico de un programa que hace que no pueda recuperar memoria después de haber terminado de usarla, lo que eventualmente hace que el programa falle debido a la falta de memoria.
métrico: Una escala de medición y el método utilizado para la medición. (ISO 14598)
hito: Un momento en un proyecto en el que los entregables (intermedios) definidos ylos resultados deberían estar listos.
moderador: El líder y la persona principal responsable de una inspección u otro proceso de revisión.
monitor: Una herramienta de software o dispositivo de hardware que se ejecuta simultáneamente con el componente o sistema bajo prueba y supervisa, registra y / o analiza el comportamiento del componente o sistema. (Después de IEEE 610)
cobertura de múltiples condiciones: El porcentaje de combinaciones de todas las condiciones individualesresultados dentro de una declaración que han sido ejercitados por un conjunto de pruebas. 100% múltiplela cobertura de condición implica una cobertura de determinación de condición del 100%.
pruebas de condiciones múltiples: Una técnica de diseño de prueba de caja blanca en la que los casos de prueba están diseñados para ejecutar combinaciones de resultados de una sola condición (dentro de una declaración).
análisis de mutaciones: Un método para determinar la minuciosidad de la suite de pruebas midiendo hasta qué punto una suite de pruebas puede discriminar el programa de las variantes leves (mutantes) del programa.
norte
Cobertura N-switch: El porcentaje de secuencias de transiciones N + 1 que han sido ejercidas por una serie de pruebas. (Perro chino)
Prueba de N-switch: Una forma de prueba de transición de estado en la que los casos de prueba están diseñados para ejecutar todas las secuencias válidas de transiciones N + 1. (Chow) Ver también prueba de transición estatal.
prueba negativa: Pruebas destinadas a demostrar que un componente o sistema no funciona. Las pruebas negativas están relacionadas con la actitud de los evaluadores más que con un enfoque de prueba específico o una técnica de diseño de prueba. (Después de Beizer).
disconformidad: Incumplimiento de un requisito especificado. (ISO 9000)
requisito no funcional: Un requisito que no se relaciona con la funcionalidad, sino con atributos como confiabilidad, eficiencia, usabilidad, mantenibilidad y portabilidad.
pruebas no funcionales: Probar los atributos de un componente o sistema que no se relacionan con la funcionalidad, p. Ej. confiabilidad, eficiencia, usabilidad, mantenibilidad y portabilidad.
Técnicas de diseño de pruebas no funcionales: Métodos utilizados para diseñar o seleccionar pruebas para pruebas no funcionales.
O
software estándar: Un producto de software que se desarrolla para el mercado general, es decir, para un gran número de clientes, y que se entrega a muchos clientes en un formato idéntico.
operabilidad: La capacidad del producto de software para permitir al usuario operarlo y controlarlo. (ISO 9126) Véase también usabilidad.
entorno operativo: Productos de hardware y software instalados en los sitios de los usuarios o clientes donde se utilizará el componente o sistema bajo prueba. El software puede incluir sistemas operativos, sistemas de gestión de bases de datos y otras aplicaciones.
prueba de perfil operativo: Pruebas estadísticas utilizando un modelo de operaciones del sistema (tareas de corta duración) y su probabilidad de uso típico. (Musa)
pruebas operativas: Pruebas realizadas para evaluar un componente o sistema en su entorno operativo. (IEEE 610)
producción: Una variable (ya sea almacenada dentro o fuera de un componente) que está escrita por un componente.
dominio de salida: El conjunto del que se pueden seleccionar valores de salida válidos. Consulte también dominio.
valor de salida: Una instancia de una salida. Ver también salida.
PAGS
programación en pareja: Un enfoque de desarrollo de software mediante el cual las líneas de código (producción y / o prueba) de un componente son escritas por dos programadores sentados en una sola computadora. Esto significa implícitamente que se realizan revisiones continuas de código en tiempo real.
prueba de pares: Dos probadores trabajan juntos para encontrar defectos. Por lo general, comparten una computadora y comercian con el control durante la prueba.
Pasar: Se considera que una prueba pasa si su resultado real coincide con el resultado esperado.
criterios de pasa / no pasa: Reglas de decisión utilizadas para determinar si un elemento de prueba (función) o característica ha pasado o no una prueba. (IEEE 829)
camino: Una secuencia de eventos, p. Ej. sentencias ejecutables, de un componente o sistema desde un punto de entrada a un punto de salida.
cobertura de ruta: El porcentaje de rutas que ha realizado un conjunto de pruebas. La cobertura de ruta del 100% implica una cobertura de LCSAJ del 100%.
sensibilización de caminos: Elegir un conjunto de valores de entrada para forzar la ejecución de una ruta determinada.
prueba de ruta: Una técnica de diseño de prueba de caja blanca en la que los casos de prueba están diseñados para ejecutar rutas.
rendimiento: El grado en el que un sistema o componente cumple sus funciones designadas dentro de las limitaciones dadas con respecto al tiempo de procesamiento y la tasa de rendimiento. (Después de IEEE 610) Consulte eficiencia.
indicador de rendimiento: Una métrica de alto nivel de eficacia y / o eficiencia utilizada para guiar y controlar el desarrollo progresivo, p. Ej. Porcentaje de detección de defectos (DDP) para realizar pruebas. (CMMI)
pruebas de rendimiento: El proceso de prueba para determinar el rendimiento de un producto de software. Ver pruebas de eficiencia.
herramienta de prueba de rendimiento: Una herramienta para respaldar las pruebas de desempeño y que generalmente tiene dos facilidades principales: generación de carga y medición de transacciones de prueba. La generación de carga puede simular múltiples usuarios o grandes volúmenes de datos de entrada. Durante la ejecución, se toman medidas de tiempo de respuesta de transacciones seleccionadas y se registran. Las herramientas de prueba de rendimiento normalmente proporcionan informes basados en registros de prueba y gráficos de carga contra los tiempos de respuesta.
plan de prueba de fase: Un plan de prueba que normalmente aborda un nivel de prueba.
portabilidad: La facilidad con la que el producto de software se puede transferir de un entorno de hardware o software a otro. (ISO 9126)
pruebas de portabilidad: El proceso de prueba para determinar la portabilidad de un producto de software.
poscondición: Condiciones ambientales y estatales que deben cumplirse tras la ejecución de una prueba o procedimiento de prueba.
comparación posterior a la ejecución: Comparación de los resultados reales y esperados, realizada después de que el software haya terminado de ejecutarse.
condición previa: Condiciones ambientales y estatales que deben cumplirse antes de que el componente o sistema pueda ejecutarse con una prueba o procedimiento de prueba en particular.
Prioridad: El nivel de importancia (comercial) asignado a un artículo, p. Ej. defecto.
prueba de ciclo de proceso: Una técnica de diseño de prueba de caja negra en la que los casos de prueba están diseñados para ejecutar procedimientos y procesos comerciales. (TMap)
proceso: Conjunto de actividades interrelacionadas que transforman insumos en productos. (ISO 12207)
proyecto: Un proyecto es un conjunto único de actividades coordinadas y controladas con fechas de inicio y finalización emprendidas y un objetivo que se ajusta a requisitos específicos, incluidas las limitaciones de tiempo, costo y recursos. (ISO 9000)
plan de prueba del proyecto: Un plan de prueba que normalmente aborda múltiples niveles de prueba.
pseudoaleatorio: Una serie que parece ser aleatoria pero que de hecho se genera de acuerdo con alguna secuencia preestablecida.
Q
calidad: El grado en el que un componente, sistema o proceso cumple los requisitos especificados y / o las necesidades y expectativas del usuario / cliente. (Después de IEEE 610)
seguro de calidad: Parte de la gestión de la calidad centrada en brindar confianza en que se cumplirán los requisitos de calidad. (ISO 9000)
atributo de calidad: Un rasgo o característica que afecta la calidad de un artículo. (IEEE 610)
gestión de la calidad: Actividades coordinadas para dirigir y controlar una organización en materia de calidad. La dirección y el control con respecto a la calidad generalmente incluye el establecimiento de la política de calidad y los objetivos de la calidad, la planificación de la calidad, el control de la calidad, el aseguramiento y la mejora de la calidad. (ISO 9000)
R
prueba aleatoria: Una técnica de diseño de prueba de caja negra donde se seleccionan casos de prueba, posiblemente utilizando un algoritmo de generación pseudoaleatorio, para que coincida con un perfil operativo. Esta técnica se puede utilizar para probar atributos no funcionales como la confiabilidad y el rendimiento.
recuperabilidad: La capacidad del producto de software para restablecer un nivel específico de rendimiento y recuperar los datos directamente afectados en caso de falla. (ISO 9126) Véase también fiabilidad.
pruebas de recuperabilidad: El proceso de prueba para determinar la recuperabilidad de un producto de software. Consulte también pruebas de confiabilidad.
pruebas de regresión: Prueba de un programa previamente probado después de la modificación para garantizar que no se hayan introducido o descubierto defectos en áreas no modificadas del software, como resultado de los cambios realizados. Se realiza cuando se cambia el software o su entorno.
nota de lanzamiento: Un documento que identifica los elementos de prueba, su configuración, estado actual y otra información de entrega entregada por el desarrollo a las pruebas, y posiblemente a otras partes interesadas, al comienzo de una fase de ejecución de la prueba. (Después de IEEE 829)
fiabilidad: La capacidad del producto de software para realizar sus funciones requeridas en las condiciones establecidas durante un período de tiempo específico o para un número específico de operaciones. (ISO 9126)
prueba de confiabilidad: El proceso de prueba para determinar la confiabilidad de un producto de software.
reemplazabilidad: La capacidad del producto de software para ser utilizado en lugar de otro producto de software especificado para el mismo propósito en el mismo entorno. (ISO 9126) Véase también portabilidad.
requisito: Una condición o capacidad que necesita un usuario para resolver un problema o lograr un objetivo que un sistema o componente del sistema debe cumplir o poseer para satisfacer un contrato, estándar, especificación u otro documento formalmente impuesto. (Después de IEEE 610)
pruebas basadas en requisitos: Un enfoque de prueba en el que los casos de prueba se diseñan en función de los objetivos de prueba y las condiciones de prueba derivadas de los requisitos, p. pruebas que ejercen funciones específicas o sondean atributos no funcionales como la confiabilidad o la usabilidad.
herramienta de gestión de requisitos: Una herramienta que soporta el registro de requisitos, atributos de requisitos (por ejemplo, prioridad, conocimiento responsable) y anotación, y facilita la trazabilidad a través de capas de requisitos y gestión de cambios de requisitos. Algunas herramientas de gestión de requisitos también proporcionan facilidades para el análisis estático, como la verificación de coherencia y las infracciones de las reglas de requisitos predefinidas.
fase de requisitos: El período de tiempo en el ciclo de vida del software durante el cual se definen y documentan los requisitos para un producto de software. (IEEE 610)
utilización de recursos: La capacidad del producto de software para utilizar cantidades y tipos de recursos adecuados, por ejemplo, las cantidades de memoria principal y secundaria utilizadas por el programa y los tamaños de los archivos temporales o de desbordamiento necesarios, cuando el software realiza su función en las condiciones establecidas. (Después de ISO 9126) Véase también eficiencia.
pruebas de utilización de recursos: El proceso de prueba para determinar la utilización de recursos de un producto de software.
resultado: La consecuencia / resultado de la ejecución de una prueba. Incluye salidas a pantallas, cambios en datos, informes y mensajes de comunicación enviados. Ver también resultado real, resultado esperado.
criterios de reanudación: Las actividades de prueba que deben repetirse cuando se reinicia la prueba después de una suspensión. (Después de IEEE 829)
volver a probar: Pruebas que ejecutan casos de prueba que fallaron la última vez que se ejecutaron, con el fin de verificar el éxito de las acciones correctivas.
revisión: Una evaluación del estado de un producto o proyecto para determinar las discrepancias de los resultados planificados y recomendar mejoras. Los ejemplos incluyen revisión por la dirección, revisión informal, revisión técnica, inspección y recorrido. (Después de IEEE 1028)
crítico: La persona involucrada en la revisión que identificará y describirá las anomalías en el producto o proyecto bajo revisión. Se pueden elegir revisores para representar diferentes puntos de vista y roles en el proceso de revisión.
riesgo: Un factor que podría resultar en futuras consecuencias negativas; generalmente expresado como impacto y probabilidad.
análisis de riesgo: El proceso de evaluar los riesgos identificados para estimar su impacto y probabilidad de ocurrencia (probabilidad).
pruebas basadas en riesgos: Pruebas orientadas a explorar y brindar información sobre los riesgos del producto. (Después de Gerrard)
control de riesgo: El proceso a través del cual se toman decisiones y se implementan las medidas de protección para reducir los riesgos o mantenerlos dentro de niveles específicos.
identificación de riesgo: El proceso de identificación de riesgos utilizando técnicas como lluvia de ideas, listas de verificación e historial de fallas.
gestión de riesgos: Aplicación sistemática de procedimientos y prácticas a las tareas de identificación, análisis, priorización y control de riesgos.
robustez: El grado en que un componente o sistema puede funcionar correctamente en presencia de entradas no válidas o condiciones ambientales estresantes. (IEEE 610) Consulte también tolerancia a errores, tolerancia a fallos.
causa principal: Un factor subyacente que causó una no conformidad y que posiblemente debería eliminarse permanentemente mediante la mejora del proceso.
S
la seguridad: La capacidad del producto de software para lograr niveles aceptables de riesgo de daño para las personas, la empresa, el software, la propiedad o el medio ambiente en un contexto de uso específico. (ISO 9126)
pruebas de seguridad: El proceso de prueba para determinar la seguridad de un producto de software.
escalabilidad: La capacidad del producto de software para actualizarse para adaptarse a mayores cargas. (Después de Gerrard)
pruebas de escalabilidad: Pruebas para determinar la escalabilidad del producto de software.
escriba: La persona que tiene que registrar cada defecto mencionado y cualquier sugerencia de mejora durante una reunión de revisión, en un formulario de registro. El escribiente debe asegurarse de que el formulario de registro sea legible y comprensible.
Lenguaje de escritura: Un lenguaje de programación en el que se escriben scripts de prueba ejecutables, utilizado por una herramienta de ejecución de prueba (por ejemplo, una herramienta de captura / reproducción).
seguridad: Atributos de los productos de software que influyen en su capacidad para evitar el acceso no autorizado, ya sea accidental o deliberado, a programas y datos. (ISO 9126)
pruebas de seguridad: Pruebas para determinar la seguridad del producto de software.
gravedad: El grado de impacto que tiene un defecto en el desarrollo o el funcionamiento de un componente o sistema. (Después de IEEE 610)
simulación: La representación de características de comportamiento seleccionadas de un sistema físico o abstracto por otro sistema. (ISO 2382/1)
simulador: Un dispositivo, programa de computadora o sistema utilizado durante la prueba, que se comporta u opera como un sistema dado cuando se le proporciona un conjunto de entradas controladas. (Después de IEEE 610, DO178b) Véase también emulador.
prueba de humo: Un subconjunto de todos los casos de prueba definidos / planificados que cubren la funcionalidad principal de un componente o sistema, para determinar que las funciones más cruciales de un programa funcionan, pero sin preocuparse por detalles más finos. Una prueba diaria de fabricación y humo se encuentra entre las mejores prácticas de la industria. Ver también prueba de admisión.
calidad del software: La totalidad de las funciones y características de un producto de software que influyen en su capacidad para satisfacer necesidades declaradas o implícitas. (Después de ISO 9126)
especificación: Un documento que especifica, idealmente de manera completa, precisa y verificable, los requisitos, diseño, comportamiento u otras características de un componente o sistema y, a menudo, los procedimientos para determinar si estas disposiciones se han cumplido. (Después de IEEE 610)
técnica de diseño de prueba basada en especificaciones: Consulte la técnica de diseño de prueba de caja negra.
entrada especificada: Una entrada para la que la especificación predice un resultado.
estabilidad: La capacidad del producto de software para evitar efectos inesperados de modificaciones en el software. (ISO 9126) Véase también mantenibilidad.
diagrama de estado: Un diagrama que describe los estados que puede asumir un componente o sistema y muestra los eventos o circunstancias que causan y / o resultan de un cambio de un estado a otro. (IEEE 610)
tabla de estado: Una cuadrícula que muestra las transiciones resultantes para cada estado combinado con cada posible evento, mostrando tanto las transiciones válidas como las inválidas.
transición de estado: Una transición entre dos estados de un componente o sistema.
prueba de transición estatal: Una técnica de diseño de prueba de caja negra en la que los casos de prueba están diseñados para ejecutar transiciones de estado válidas e inválidas. Consulte también las pruebas de N-switch.
declaración: Una entidad en un lenguaje de programación, que suele ser la unidad de ejecución indivisible más pequeña.
cobertura de la declaración: El porcentaje de declaraciones ejecutables que han sido ejercidas por un conjunto de pruebas.
prueba de declaración: Una técnica de diseño de prueba de caja blanca en la que los casos de prueba están diseñados para ejecutar declaraciones.
análisis estático: Análisis de artefactos de software, p. Ej. requisitos o código, realizados sin la ejecución de estos artefactos de software.
analizador estático: Una herramienta que realiza análisis estáticos.
análisis de código estático: Análisis del código fuente del programa realizado sin la ejecución de ese software.
analizador de código estático: Una herramienta que realiza análisis de código estático. La herramienta verifica el código fuente, en busca de ciertas propiedades, como la conformidad con los estándares de codificación, métricas de calidad o anomalías en el flujo de datos.
prueba estática: Prueba de un componente o sistema a nivel de especificación o implementación sin la ejecución de ese software, p. Ej. revisiones o análisis de código estático.
pruebas estadísticas: Técnica de diseño de pruebas en la que se utiliza un modelo de distribución estadística de la entrada para construir casos de prueba representativos. Consulte también pruebas de perfil operativo.
contabilidad de estado: Un elemento de la gestión de la configuración, que consiste en el registro y el informe de la información necesaria para gestionar una configuración de forma eficaz. Esta información incluye una lista de la identificación de configuración aprobada, el estado de los cambios propuestos a la configuración y el estado de implementación de los cambios aprobados. (IEEE 610)
Pruebas de estrés: Pruebas realizadas para evaluar un sistema o componente en o más allá de los límites de sus requisitos especificados. (IEEE 610)
cobertura estructural: Medidas de cobertura basadas en la estructura interna del componente.
técnica de diseño de prueba estructural: Consulte la técnica de diseño de prueba de caja blanca.
talón: Una implementación esquelética o de propósito especial de un componente de software, que se utiliza para desarrollar o probar un componente que lo llama o depende de él. Reemplaza un componente llamado. (Después de IEEE 610)
subruta: Una secuencia de declaraciones ejecutables dentro de un componente.
criterios de suspensión: Los criterios utilizados para detener (temporalmente) todas o una parte de las actividades de prueba en los elementos de prueba. (Después de IEEE 829)
idoneidad: La capacidad del producto de software para proporcionar un conjunto apropiado de funciones para tareas específicas y objetivos de usuario. (ISO 9126) Consulte también la funcionalidad.
Inventario de medición de usabilidad de software (SUMI): Una técnica de prueba de usabilidad basada en cuestionarios para evaluar la usabilidad, p. Ej. satisfacción del usuario, de un componente o sistema. (Veenendaal)
prueba de sintaxis: Una técnica de diseño de prueba de caja negra en la que los casos de prueba se diseñan basándose en la definición del dominio de entrada y / o dominio de salida.
sistema: Una colección de componentes organizados para realizar una función específica o un conjunto de funciones. (IEEE 610)
pruebas de integración del sistema: Prueba de la integración de sistemas y paquetes; probar interfaces con organizaciones externas (por ejemplo, intercambio electrónico de datos, Internet).
prueba del sistema: El proceso de probar un sistema integrado para verificar que cumple con los requisitos especificados. (Hetzel)
T
revisión técnica: Una actividad de discusión en grupo de pares que se enfoca en lograr un consenso sobre el enfoque técnico a tomar. Una revisión técnica también se conoce como revisión por pares. (Gilb y Graham, IEEE 1028)
enfoque de prueba: La implementación de la estrategia de prueba para un proyecto específico. Por lo general, incluye las decisiones que se toman a continuación en función del objetivo del proyecto (de prueba) y la evaluación de riesgos realizada, los puntos de partida con respecto al proceso de prueba, las técnicas de diseño de prueba que se aplicarán, los criterios de salida y los tipos de prueba que se realizarán.
automatización de pruebas: El uso de software para realizar o respaldar actividades de prueba, p. Ej. gestión de pruebas, diseño de pruebas, ejecución de pruebas y verificación de resultados.
base de prueba: Todos los documentos de los que se pueden inferir los requisitos de un componente o sistema. La documentación en la que se basan los casos de prueba. Si un documento solo puede modificarse mediante un procedimiento de enmienda formal, la base de prueba se denomina base de prueba congelada. (Después de TMap)
caso de prueba: Un conjunto de valores de entrada, precondiciones de ejecución, resultados esperados y poscondiciones de ejecución, desarrollado para un objetivo particular o condición de prueba, como para ejercitar una ruta de programa en particular o para verificar el cumplimiento de un requisito específico. (Después de IEEE 610)
especificación del caso de prueba: Un documento que especifica un conjunto de casos de prueba (objetivo, entradas, acciones de prueba, resultados esperados y condiciones previas de ejecución) para un elemento de prueba. (Después de IEEE 829)
carta de prueba: Una declaración de objetivos de prueba y posiblemente ideas de prueba. Las cartas de prueba se utilizan, entre otras cosas, en pruebas exploratorias. Consulte también pruebas exploratorias.
comparador de prueba: Una herramienta de prueba para realizar una comparación de pruebas automatizada.
comparación de prueba: El proceso de identificar diferencias entre los resultados reales producidos por el componente o sistema bajo prueba y los resultados esperados para una prueba. La comparación de pruebas se puede realizar durante la ejecución de la prueba (comparación dinámica) o después de la ejecución de la prueba.
condición de prueba: Un elemento o evento de un componente o sistema que podría ser verificado por uno o más casos de prueba, p. Ej. una función, transacción, atributo de calidad o elemento estructural.
datos de prueba: Datos que existen (por ejemplo, en una base de datos) antes de que se ejecute una prueba y que afectan o son afectados por el componente o sistema bajo prueba.
herramienta de preparación de datos de prueba: Un tipo de herramienta de prueba que permite seleccionar datos de bases de datos existentes o crear, generar, manipular y editar para su uso en pruebas.
especificación de diseño de prueba: Un documento que especifica las condiciones de prueba (elementos de cobertura) para un elemento de prueba, el enfoque de prueba detallado e identifica los casos de prueba de alto nivel asociados. (Después de IEEE 829)
herramienta de diseño de prueba: Una herramienta que respalda la actividad de diseño de prueba mediante la generación de entradas de prueba a partir de una especificación que puede guardarse en un repositorio de herramientas CASE, p. herramienta de gestión de requisitos, o de condiciones de prueba especificadas contenidas en la propia herramienta.
técnica de diseño de prueba: Un método utilizado para derivar o seleccionar casos de prueba.
entorno de prueba: Un entorno que contiene hardware, instrumentación, simuladores, herramientas de software y otros elementos de soporte necesarios para realizar una prueba. (Después de IEEE 610)
informe de evaluación de la prueba: Un documento elaborado al final del proceso de prueba que resume todas las actividades de prueba y los resultados. También contiene una evaluación del proceso de prueba y lecciones aprendidas.
ejecución de pruebas: El proceso de ejecutar una prueba por el componente o sistema bajo prueba, produciendo resultados reales.
automatización de ejecución de pruebas: El uso de software, p. Ej. herramientas de captura / reproducción, para controlar la ejecución de las pruebas, la comparación de los resultados reales con los resultados esperados, la configuración de las condiciones previas de las pruebas y otras funciones de control y generación de informes de las pruebas.
fase de ejecución de la prueba: El período de tiempo en un ciclo de vida de desarrollo de software durante el cual se ejecutan los componentes de un producto de software, y el producto de software se evalúa para determinar si se han satisfecho o no los requisitos. (IEEE 610)
programa de ejecución de la prueba: Un esquema para la ejecución de procedimientos de prueba. Los procedimientos de prueba se incluyen en el programa de ejecución de la prueba en su contexto y en el orden en el que se ejecutarán.
técnica de ejecución de prueba: El método utilizado para realizar la ejecución de la prueba real,ya sea de forma manual o automática.
herramienta de ejecución de pruebas: Un tipo de herramienta de prueba que puede ejecutar otro software usando un script de prueba automatizado, p. Ej. captura / reproducción. (Fewster y Graham)
arnés de prueba: Un entorno de prueba compuesto por stubs y controladores necesarios para realizar una prueba.
infraestructura de prueba: Los artefactos organizativos necesarios para realizar pruebas, que consisten en entornos de prueba, herramientas de prueba, entorno de oficina y procedimientos.
Elemento de prueba: El elemento individual a probar. Por lo general, hay un objeto de prueba y muchos elementos de prueba. Véase también objeto de prueba.
nivel de prueba: Un grupo de actividades de prueba que se organizan y administran juntas. Un nivel de prueba está vinculado a las responsabilidades de un proyecto. Ejemplos de niveles de prueba son la prueba de componentes, la prueba de integración, la prueba del sistema y la prueba de aceptación. (Después de TMap)
registro de prueba: Un registro cronológico de detalles relevantes sobre la ejecución de pruebas. (IEEE 829)
registro de prueba: El proceso de registrar información sobre las pruebas ejecutadas en un registro de pruebas.
administrador de pruebas: La persona responsable de probar y evaluar un objeto de prueba. El individuo, que dirige, controla, administra, planifica y regula la evaluación de un objeto de prueba.
gestión de pruebas: La planificación, estimación, seguimiento y control de las actividades de prueba, normalmente llevada a cabo por un administrador de pruebas.
Modelo de madurez de prueba (TMM): Un marco por etapas de cinco niveles para la mejora del proceso de prueba, relacionado con el Modelo de madurez de capacidad (CMM) que describe los elementos clave de un proceso de prueba eficaz.
Mejora del proceso de prueba (TPI): Un marco continuo para la mejora del proceso de prueba que describe los elementos clave de un proceso de prueba eficaz, especialmente dirigido a las pruebas de sistema y las pruebas de aceptación.
objeto de prueba: El componente o sistema que se va a probar. Véase también elemento de prueba.
objetivo de la prueba: Razón o propósito para diseñar y ejecutar una prueba.
prueba de oráculo: Una fuente para determinar los resultados esperados para compararlos con el resultado real del software bajo prueba. Un oráculo puede ser el sistema existente (para un punto de referencia), un manual de usuario o el conocimiento especializado de una persona, pero no debería ser el código. (Después de Adrion)
indicador de rendimiento de la prueba: Una métrica, en general de alto nivel, que indica en qué medida se cumple un determinado valor o criterio objetivo. A menudo relacionado con los objetivos de mejora del proceso de prueba, p. Porcentaje de detección de defectos (DDP).
fase de prueba: Un conjunto distinto de actividades de prueba recopiladas en una fase manejable de un proyecto, p. Ej. las actividades de ejecución de un nivel de prueba. (Después de Gerrard)
Plan de prueba: Un documento que describe el alcance, el enfoque, los recursos y el cronograma de las actividades de prueba previstas. Identifica, entre otros elementos de prueba, las características que se probarán, las tareas de prueba, quién realizará cada tarea, el grado de independencia del evaluador, el entorno de prueba, las técnicas de diseño de prueba y las técnicas de medición de prueba que se utilizarán, y la justificación de su elección. y cualquier riesgo que requiera planificación de contingencia. Es un registro del proceso de planificación de pruebas (después de IEEE 829)
planificación de pruebas: La actividad de establecer o actualizar un plan de prueba.
política de prueba: Un documento de alto nivel que describe los principios, el enfoque y los principales objetivos de la organización con respecto a las pruebas.
análisis de punto de prueba (TPA): Un método de estimación de prueba basado en fórmulas basado en el análisis de puntos de función. (TMap)
procedimiento de prueba: Consulte la especificación del procedimiento de prueba.
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 script de prueba o script de prueba manual. (Después de IEEE 829)
proceso de prueba: El proceso de prueba fundamental comprende la planificación, especificación, ejecución, registro y verificación de su finalización. (BS 7925/2)
prueba de repetibilidad: Un atributo de una prueba que indica si se producen los mismos resultados cada vez que se ejecuta la prueba.
prueba de funcionamiento: Ejecución de una prueba en una versión específica del objeto de prueba.
secuencia de comandos de prueba: Se usa comúnmente para referirse a la especificación de un procedimiento de prueba, especialmente uno automatizado.
especificación de prueba: Un documento que consta de una especificación de diseño de prueba, una especificación de caso de prueba y / o una especificación de procedimiento de prueba.
estrategia de prueba: Un documento de alto nivel que define los niveles de prueba que se realizarán y las pruebas dentro de esos niveles para un programa (uno o más proyectos).
Banco de pruebas: Un conjunto de varios casos de prueba para un componente o sistema bajo prueba, donde la condición posterior de una prueba se usa a menudo como condición previa para la siguiente.
informe de resumen de la prueba: Un documento que resume las actividades y los resultados de las pruebas. También contiene una evaluación de los elementos de prueba correspondientes frente a los criterios de salida..(Después de IEEE 829)
objetivo de prueba: Un conjunto de criterios de salida.
herramienta de prueba: Un producto de software que admite una o más actividades de prueba, como planificación y control, especificación, creación de archivos y datos iniciales, ejecución de pruebas y análisis de pruebas. (TMap) Consulte también CAST.
tipo de prueba: Un grupo de actividades de prueba destinadas a probar un componente o sistema con respecto a uno o más atributos de calidad interrelacionados. Un tipo de prueba se centra en un objetivo de prueba específico, es decir, prueba de confiabilidad, prueba de usabilidad, prueba de regresión, etc., y puede tener lugar en uno o más niveles de prueba o fases de prueba. (Después de TMap)
probabilidad: La capacidad del producto de software para permitir que se pruebe el software modificado. (ISO 9126) Véase también mantenibilidad.
revisión de probabilidad: Una verificación detallada de la base de la prueba para determinar si la base de la prueba tiene un nivel de calidad adecuado para actuar como un documento de entrada para el proceso de prueba. (Después de TMap)
requisitos comprobables: El grado en que se establece un requisito en términos que permiten el establecimiento de diseños de prueba (y posteriormente casos de prueba) y la ejecución de pruebas para determinar si se han cumplido los requisitos. (Después de IEEE 610)
ensayador: Un profesional técnicamente capacitado que participa en la prueba de un componente o sistema.
pruebas: El proceso que consiste en todas las actividades del ciclo de vida, tanto estáticas como dinámicas, relacionadas con la planificación, preparación y evaluación de productos de software y productos de trabajo relacionados para determinar que satisfacen los requisitos especificados, demostrar que son aptos para su propósito y detectar defectos.
testware: Los artefactos producidos durante el proceso de prueba necesarios para planificar, diseñar y ejecutar pruebas, como documentación, scripts, entradas, resultados esperados, procedimientos de configuración y limpieza, archivos, bases de datos, entorno y cualquier software o utilidades adicionales que se utilicen en pruebas. (Después de Fewster y Graham)
prueba de hilo: Una versión de las pruebas de integración de componentes donde la integración progresiva de los componentes sigue a la implementación de subconjuntos de los requisitos, en contraposición a la integración de componentes por niveles de una jerarquía.
trazabilidad: La capacidad de identificar elementos relacionados en la documentación y el software, comorequisitos con pruebas asociadas. Ver también trazabilidad horizontal, trazabilidad vertical.
prueba de arriba hacia abajo: Un enfoque incremental para las pruebas de integración en el que el componente en la parte superior de la jerarquía de componentes se prueba primero, y los componentes de nivel inferior se simulan mediante stubs. Los componentes probados se utilizan luego para probar componentes de nivel inferior. El proceso se repite hasta que se hayan probado los componentes de nivel más bajo.
U
comprensibilidad: La capacidad del producto de software para permitir que el usuario comprenda si el software es adecuado y cómo se puede utilizar para tareas y condiciones de uso particulares. (ISO 9126) Véase también usabilidad.
código inalcanzable: Código que no se puede alcanzar y por lo tanto es imposible de ejecutar.
usabilidad: La capacidad del software para ser comprendido, aprendido, utilizado y atractivo para el usuario cuando se utiliza en condiciones específicas. (ISO 9126)
pruebas de usabilidad: Pruebas para determinar en qué medida se entiende el producto de software, es fácil de aprender, fácil de operar y atractivo para los usuarios en condiciones específicas. (Después de ISO 9126)
prueba de casos de uso: Una técnica de diseño de prueba de caja negra en la que los casos de prueba están diseñados para ejecutar escenarios de usuario.
prueba de usuario: Una prueba en la que participan usuarios de la vida real para evaluar la usabilidad de un componente o sistema.
V
Modelo en V: Un marco para describir las actividades del ciclo de vida del desarrollo de software desde la especificación de requisitos hasta el mantenimiento. El modelo V ilustra cómo las actividades de prueba se pueden integrar en cada fase del ciclo de vida del desarrollo de software.
validación: Confirmación mediante examen y provisión de evidencia objetiva de que se han cumplido los requisitos para un uso o aplicación específicos previstos. (ISO 9000)
variable: Un elemento de almacenamiento en una computadora al que se puede acceder mediante un programa de software al referirse a él por un nombre.
verificación: Confirmación mediante examen y provisión de evidencia objetiva de que se han cumplido los requisitos especificados. (ISO 9000)
trazabilidad vertical: El seguimiento de los requisitos a través de las capas de documentación de desarrollo hasta los componentes.
prueba de volumen: Pruebas donde el sistema está sujeto a grandes volúmenes de datos. Consulte también pruebas de utilización de recursos.
EN
recorrido: Una presentación paso a paso por parte del autor de un documento con el fin de recopilar información y establecer una comprensión común de su contenido. (Freedman y Weinberg, IEEE 1028)
técnica de diseño de prueba de caja blanca: Procedimiento documentado para derivar y seleccionar casos de prueba basados en un análisis de la estructura interna de un componente o sistema.
prueba de caja blanca: Pruebas basadas en un análisis de la estructura interna del componente o sistema.
Delphi de banda ancha: Una técnica de estimación de pruebas basada en expertos que tiene como objetivo realizar una estimación precisa utilizando la sabiduría colectiva de los miembros del equipo.
Contáctame si desea agregar más definiciones en este glosario.
Referencia: http://www.istqb.org/downloads/glossary-1.0.pdf
Lectura recomendada
- Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
- Trabajo de asistente de control de calidad de pruebas de software
- Curso de pruebas de software: ¿A qué instituto de pruebas de software debo unirme?
- Elegir las pruebas de software como carrera
- Trabajo autónomo de redactor de contenido técnico de pruebas de software
- Guía de subcontratación de control de calidad: empresas de subcontratación de pruebas de software
- Algunas preguntas interesantes de la entrevista sobre pruebas de software
- Comentarios y revisiones del curso de pruebas de software