Professional Documents
Culture Documents
Tiempo Medio
entre Fallos
producto
cumple
los
Debe especificarse el
fiabilidad y cundo ese nivel es Confiabilidad:
alcanzado.
indica la fraccin
de todas las operaciones que
intent completar con xito.
Validacin
Incluye pruebas
de usabilidad,
feedback del
usuario.
Especificaciones
de SW
Sistema
Verificacin
Incluye testing
(anlisis
dinmico),
revisiones e
inspecciones
(anlisis esttico)
Actividades de la Prueba de
Software
Inspecciones (ejercicio prxima clase)
Revisiones (ejercicio prxima clase)
Pruebas ejecutables:
De
De
De
De
De
De
Actividades de la Prueba de
Software
Por ejemplo:
las pruebas de caja blanca requieren del
conocimiento
de
la
estructura
del
programas el cdigo a probar.
Las pruebas de caja negra no requieren el
conocimiento de la estructura del programa,
tan solo de los parmetros de entrada y
las salidas esperadas.
Actividades de la Prueba de
Software
Por ejemplo las pruebas de paquete se
utilizan en sistema estructurados de
dicha manera; donde el paquete
corresponde a una coleccin de mdulos
relativos al manejo de un grupo de datos
o enfocados a la implementacin de una
funcionalidad.
Las pruebas de paquetes sirven para
asegurar que los mdulos en dicho paquete
trabajan correctamente en su conjunto.
Conocimientos previos
Conocimientos previos
Conoce o recuerda alguna tcnica
de prueba???
Particin equivalente (PA)
Anlisis de valor lmite (AVL)
Pares-Sabios (PS)
Pruebas de Unidad
Definicin Unidad
Corresponde a un mtodo/funcin/procedimiento.
Coleccin
de
mtodos/funciones/procedimientos
relacionados.
Pruebas de Unidad
Definicin Prueba de Unidad (cont.)
Una prueba ejecutada por el desarrollador en un
ambiente de laboratorio, que debe demostrar que
el programa cumple con los requerimientos
establecidos en la especificacin de diseo
[Koomen and Pol 00]
Prueban los componentes de software individuales o
colecciones de componentes. Los testers definen el
domino de entrada para las unidades en cuestin
e ignoran el resto del sistema. [Whittaker 00]
Pruebas de Unidad
Qu?
Cundo?
Tcnicas
En cada construccin/
da/semana
Cmo?
Basada en estructura Toma segundos u
horas correrla
No formalmente
Quin?
Por qu?
Aseguramiento de las
Desarrollador (grupo)
funcionalidades
No un tester o QA
Definicin
Probar componente
singular o grupos de
no?
componentes.
Fortaleza
Identificacin del
componente (unidad).
Debilidades
Pruebas GUI
Identificacin de unidades.
Mantenimiento de los
scripts de prueba.
Estructuras de datos.
Cmo?
Quin?
Caractersticas
Pueden abarcar desde un componente a un grupo de
grupo de componentes o un programa completo
Suelen realizarse por personal de desarrollo
Inspeccin de cdigo (walkthrough) tipicamente por el equipo
Compilacin y remocin de los errores de sintxis remanentes
Pruebas de Caja Negra
Basadas en la Especificacin
No puedo ver dentro del componente
Pruebas de Caja blanca
Basadas en programa
Puedo ver dentro del componente
Ejemplo clsico
John
John works hard. He codes everyday. The project
deadline is tomorrow. He types in about two hundred
new lines per hour, and thinks that after 6 hours and
roughly a thousand new lines added the program would
work flawlessly.
Betty
Betty works hard. She codes everyday. The project
deadline is tomorrow. She types in about one hundred
new lines per hour, and keeps testing each method she
adds. She does not proceed to write new codes unless all
previously written pieces work correctly.
Pruebas de Unidad
Caractersticas
mbito: unidad individual
A menudo corresponde a la nocin de unidad de
compilacin para un lenguaje de programa.
Fases
Planificacin
Planificar los acercamientos generales, recursos y
calendario.
Determinar caractersticas a probar
Refinar el plan general
Medicin
Ejecutar los procedimientos de prueba
Verificar la finalizacin
Evaluar el esfuerzo de prueba y unidad
Planificacin (cont.)
Salidas:
Informacin de la planificacin de las pruebas de unidad.
Peticiones generales de recursos para las pruebas de
unidad.
Planificacin (cont.)
Tareas
Estudio de requerimientos funcionales
Identificacin de requerimientos adicionales y
procedimientos
Identificacin de los estados de la unidad
Salidas
Listado de elementos a incluir en la prueba
Peticiones de clarificacin de requerimientos de unidad.
Planificacin (cont.)
Refinar Tareas
Acercamientos al refinamiento
Especificacin de requerimientos especiales de recursos
Especificacin detallada de la calendarizacin
Refinar salidas
Informacin especifica de la planificacin de la prueba de
unidad
Peticin de recursos especiales para la prueba de unidad
Tareas
Salidas
Verificar la finalizacin
Chequeo de entradas
Chequeo de tareas
Chequeo de salidas
Chequeo de tareas
Chequeo de la finalizacin normal del proceso de testing
Chequeo de la terminacin anormal del proceso de testing
Set de pruebas suplementarias
Chequeo de salidas
Chequeo de la informacin en el reporte de resumen de pruebas
Especificaciones de pruebas revisadas o adicionales
Datos de prueba adicionales
Evaluacin de tareas
Evaluacin de Salidas
Reporte de resumen de prueba
Coleccin y almacenamiento completo de los productos del testing
Pruebas de Integracin
Definicin Prueba de Unidad
Corresponde a un proceso de desarrollo de software
en el cual las unidades de programas son combinadas
y probadas como grupo en mltiples formas.
Caractersticas
Expone problemas relativos a las interfaces entre los
componentes de programa.
Las pruebas de integracin resultan crticas para
asegurar
la correctitud funcional del sistema
integrado.
Su objetivo es descubrir errores en la interface de los
elementos que estn siendo integrados.
Driver invoca al
mdulo bajo prueba.
Entrega los datos de
entrada para la
prueba.
Arns de Pruebas
Drive
r
T
D
Stub
Stub es un procedimiento,
modulo o unidad tonto que
ocupa el lugar de la seccin
no finalizada del sistema
http://amit-badola.blogspot.com/2007/10/drivers-and-stubs.html
Pruebas de Integracin
Categoras de I&T
Incremental
Expande
el
grupo
progresivamente.
de
mdulos
integrados
No Incremental
Pruebas de Integracin
Estrategias
Instantnea v/s incremental
Top down?
Botton up?
Los mdulos crticos o de alto riesgo primero?
Por generalidad?
Pruebas de Integracin
Integracin TOP-DOWN
Las rutinas de control son probadas primero,
en lo posible con las estructuras de control en
el nivel medio, presentes slo como stubs
(bloques de cdigo para prueba).
Stubs son subprogramas incompletos, utilizados slo
para permitir que las rutinas de control de alto nivel
sean probadas.
El nivel superior, usualmente el que controla los componentes,
es testeado por si mismo. Luego, todos los componentes
llamados por el/los componente(s) probado(s) son combinados
Prueb
Prueb
para probarse como una
unidad mayor. Este acercamiento se
Prueb
a
a
replica hasta que ha sido incorporado
el ltimo componente.
a
A, B,
B, C,
A
C, D,
D
E, F
Pruebas de Integracin
Integracin TOP-DOWN
Puede ser ejecutado en
En Profundidad
En Amplitud
Pruebas de Integracin
Integracin TOP-DOWN
Ventajas
Desventajas
Pruebas de Integracin
Integracin TOP-DOWN
Pruebas de Integracin
Integracin TOP-DOWN
TestA
LayerI
TestA,B,C,D
LayerI+II
LayerI
LayerII
LayerIII
Test
A,B,C,D,
E,F,G
AllLayers
Pruebas de Integracin
Integracin BOTTON-UP
Pruebas de Integracin
Integracin BOTTON-UP
Pruebas de Integracin
Integracin BOTTON-UP
TestE
E
TestB,E,F
LayerI
TestF
TestC
TestD,G
TestG
Test
A,B,C,D,
E,F,G
LayerII
LayerIII
Pruebas de Integracin
Integracin BOTTON-UP
Ventajas
Desventajas
Pruebas de Integracin
Integracin por SANDWICH
Combina las estrategias Top-Down y
Botton-Up.
El sistema se ve como si lo estructurara
3 capas:
Una capa cetral (objetivo).
Una capa sobre la capa objetivo.
Una capa bajo la capa objetivo.
Pruebas de Integracin
Integracin por SANDWICH
Se aplica a los proyectos de software grandes,
desarrollados por un cierto nmero de sub-equipos, o
en los proyectos pequeos donde los diferentes
mdulos son construidos individualmente.
Los sub equipos o los equipos individuales deben
conducir las pruebas botton-up de los mdulos que
construyeron antes de liberarlos al equipo de
integracin, el cual los ensamblar mediante pruebas
top-down.
Las capas Superior e Inferior pueden testearse en
forma paralela.
No se debe probar concienzudamente los subsistemas
en forma individual antes de la integracin.
Pruebas de Integracin
Integracin por SANDWICH
E
TestB,E,F
TestF
TestG
TestD,G
TestA,B,C,D
Top
Layer
Tests
LayerI
C
TestE
Bottom
Layer
Tests
TestA
Test
A,B,C,D,
E,F,G
LayerII
LayerIII
Pruebas de Integracin
Integracin
modificado
por
SANDWICH
Prueba en paralelo
Pruebas de IntegracinDouble
Double
A
TestB
TestE
Triple
Triple
TestI
TestI
Triple
Triple
TestI
TestI
TestB,E,F
TestI
TestI
Double
Double
TestII
TestII
TestD,G
LayerII
LayerIII
Test
A,B,C,D,
E,F,G
TestG
TestA,C
TestA
TestC
Double
Double
TestII
TestII
TestF
TestD
LayerI
Double
Double
TestI
TestI
Integracin por
SANDWICH modificado
Pruebas de Integracin
Integracin Big Bang
Definida por Myers en 1979; establece que,
cuando todos los componentes son probados
en forma aislada, es una gran tentacin
mezclarlos como si fueran el sistema final para
ver si funciona a la primera.
Prueba
A, B,
C, D
Prueba
A
Prueba
B
Prueba
C
Prueba
D
Pruebas de Integracin
Integracin Big Bang
Muchos programadores utilizan el acercamiento
big-bang para sistemas pequeos, pero no es
practico para los sistemas grandes.
De hecho, se han encontrado una serie de
desventajas por las cuales no es recomendado
para todos los sistemas
Requiere tanto de stubs como de drivers para probar
los componentes independientemente.
Es difcil encontrar la causa de todas las fallas porque
todos los componentes estn fundidos en uno.
Los bugs de interface no pueden ser distinguidos
fcilmente de otro tipo de faltas.
Pruebas de Integracin
Integracin Big Bang
VENTAJAS:
Ninguna
DESVENTAJAS:
Dificultad para debugging.
Mucho cdigo desechable.
Mdulos
crticos
y
perifricos
no
distinguibles.
Los usuarios no ven el producto hasta
etapas finales del ciclo de desarrollo.
Pruebas de Integracin
Comparacin entre las estrategias
Pruebas de Integracin
Pasos genricos
1.1.Basados
Basadosen
enestrategias
estrategiasde
de
integracin,
integracin,seleccione
seleccioneun
un
componente
componentepara
paraser
serprobado.
probado.
Aplique
Apliquepruebas
pruebasde
deunidad
unidadalal
. componente.
componente.
2.2.Coloque
Coloquelos
loscomponentes
componentes
seleccionados
seleccionadosjuntos;
juntos;realice
realice
cualquier
cualquierarreglo
arreglonecesario
necesariopara
para
hacer
hacerlalaprueba
pruebade
deintegracin
integracin
operacional
operacional(drivers,
(drivers,stubs).
stubs).
3.3.Realice
Realicepruebas
pruebasfuncionales:
funcionales:
Defina
Definalos
loscasos
casosde
deprueba
prueba
asociado
asociadoaalalafuncionalidad
funcionalidaddel
del
componente
componenteseleccionado.
seleccionado.
4.4.Realice
Realicepruebas
pruebasestructurales:
estructurales:
Defina
Definalos
loscasos
casosde
deprueba
pruebaque
que
ejerciten
ejercitenelelcomponente
componente
seleccionado.
seleccionado.
5.5.Ejecute
Ejecutelas
laspruebas
pruebasde
dedesempeo.
desempeo.
6.6.Lleve
Lleveregistro
registrode
delos
loscasos
casosde
de
prueba
pruebayylas
lasactividades
actividadesde
de
prueba.
prueba.
7.7.Repita
Repitalos
lospasos
pasos11aa77hasta
hastaque
queelel
sistema
sistemacompleto
completohaya
hayasido
sido
probado.
probado.
El
Elobjetivo
objetivoprimario
primariode
delalaprueba
pruebade
de
integracin
integracines
esidentificar
identificarlos
loserrores
errores
en
enlalaconfiguracin
configuracindel
delcomponente
componente
actualmente
actualmenteprobado.
probado.
Pruebas de Integracin
Qu estrategia escoger?
Factores
Factoresaaconsiderar
considerar
Cantidad
Cantidadde
depruebas
pruebasde
derutina
rutina
(stubs
(stubs&drivers)
&drivers)
Ubicacin
Ubicacinde
delas
laspartes
partes
crticas
crticasen
enelelsistema
sistema
Disponibilidad
Disponibilidadde
dehardware
hardware
Disponibilidad
Disponibilidadde
de
componentes
componentes
Asuntos
Asuntosconcernientes
concernientesaa
calendarizacin
calendarizacin
Acercamiento
AcercamientoBottom-Up
Bottom-Up
Buena
Buenapara
parametodologas
metodologas
orientadas
orientadasaaobjetos,
objetos,
Deteccin
Deteccinde
deerrores
erroresde
de
diseo
diseopospuestos
pospuestoshasta
hastaelel
final
finalde
delas
laspruebas,
pruebas,
Componentes
Componentesde
denivel
nivel
superior
superiorusualmente
usualmenteson
son
importantes
importantesyyno
nopuede
puede
restarceles
restarcelesimportancia
importanciahasta
hasta
elelfinal
de
las
pruebas.
final de las pruebas.
Acercamiento
AcercamientoTop-down
Top-down
Los
Loscasos
casosde
deprueba
pruebapueden
pueden
definirse
en
trminos
de
definirse en trminos delala
funcin
funcinexaminada,
examinada,
Requiere
Requieremantener
mantenerlala
correctitud
correctitudde
delas
laspruebas
pruebasque
que
utilizan
utilizanstubs,
stubs,
Escribir
Escribirlos
losstubs
stubspuede
puedeser
ser
complicado.
complicado.
Pruebas de Integracin
Botton-up extensin
de las pruebas de unidad
Botton-up extensin
de las pruebas de unidad
Pruebas de Sistemas
La entrada a la prueba de sistema, es el
sistema conformado por la integracin de la
totalidad de sus componentes.
Las pruebas de sistemas
Son una actividad de verificacin,
Estn focalizadas en las propiedades a nivel
de sistema,
Son realizadas por el equipo de desarrollo,
Validan la utilidad y satisfaccin con el producto, y
Se consideran la culminacin de las pruebas de
integracin.
Pruebas de Sistemas
Las
pruebas
constitudas por
diferentes, cuyo
profundamente el
de
sistemas
estn
una serie de pruebas
propsito es ejercitar
sistema.
Prueba Funcional
Prueba de Estructura
Prueba de Desempeo
Prueba de Aceptancin
Prueba de Instalacin
Etc., (ver PSS0510)
Pruebas de Sistemas
Impacto de los requerimientos en las pruebas de
sistema
Mientras ms explcitos los requerimientos, mas fcil
resultan de probar.
La calidad
de
los
componentes
(en OO
implementados por medio de UML seran los casos de
uso), determina la facilidad para probar la funcionalidad.
La calidad de descompocicin de subsistemas
determina la facilidad para hacer pruebas de estructura.
La calidad de los requerimientos no funcionales y
los no funcionales de restricciones determinan la
facilidad de ejecutar pruebas de desempeo.
Plan Pruebas de
Sistemas
Planificacin
Se construye el Plan de Pruebas de Sistema
definido en la etapa de Requerimientos de
Sistema (o Software) y se documenta en el SVVP.
El SVVP debe cubrir
Diseo
Plan Pruebas de
Sistemas
Plan Pruebas de
Sistemas
Reporte de Pruebas
3.0
12
12
Si
7.0
12
12
Si
8.0
12
12
Si
Mozilla Firefox
3.5
12
12
Si
Google Chrome
3.0
12
12
Si
Pruebas de Sistemas
Algunos tipos de pruebas de sistemas
PRUEBA FUNCIONAL
Pruebas de Sistemas
Algunos tipos de pruebas de sistemas
PRUEBA FUNCIONAL
Ejemplo a nivel de unidad
Asegurar que cada lnea de cdigo es ejecutada
apropiadamente:
Cobertura funcional: cada funcin o mtodo es
ejecutada al menos en un caso de prueba.
Cobertura de declaraciones: cada lnea de
cdigo es cubierta al menos en un caso de
prueba.
Cobertura de caminos: cada posible camino a
travs del cdigo es cubierto por al menos un
caso de prueba.
Pruebas de Sistemas
Algunos
sistemas
tipos
de
pruebas
de
PRUEBA FUNCIONAL
Ejemplo a nivel de integracin
Asegurar que el sistema es integrado con
otros sistemas de manera tal que no los
afecte:
Este tipo de pruebas busca lograr la
interoperabilidad y cooperacin entre
aplicaciones.
Aqu se definen objetivos de prueba
que ejerciten comunicacin.
Pruebas de Sistemas
Algunos
sistemas
tipos
de
pruebas
de
PRUEBA FUNCIONAL
Ejemplo a nivel de Sistemas
Asegurar que todas las funciones son
combinadas
adecuadamente
para
entregar el resultado de negocios
deseado:
Considerar todos los subsistemas que
deben ser probados primero o si todas
las capas de un subsistemas deben ser
probadas antes de ser combinadas.
Pruebas de Sistemas
Algunos tipos de pruebas de sistemas
PRUEBA DE ESTRUCTURA
Esencialmente igual que una prueba de caja blanca
Objetivo: Cubrir el camino del diseo del sistema
Ejercitar todas los parmetros de entrada y
salida para cada componente.
Ejercitar todos los componentes y todas las
llamadas (cada componente es llamado al
menos una vez y todo componente es llamado
por todas las posibles llamadas).
Utilice pruebas condicionales y de iteracin
como pruebas de unidad.
Pruebas de Sistemas
Algunos tipos de pruebas de sistemas
PRUEBAS DE DESEMPEO
Pruebas de Sistemas
Prueba de Tiempo
Evaluar los tiempos de respuesta y de
rendimiento para una funcin
Prueba de medioambiente
Probar la tolerancia al calentamiento,
humedad, moviemiento, portabilidad
Prueba de Calidad
Probar confiabilidad, habilidad de
mantencin y disponibilidad del sistema
Prueba de Recuperacin
Probar la respuesta del sistema ante la
precencia de errores por prdida de datos
Pruebas de Factor Humano
Pruebas de interface con el usuario
PRUEBAS DE DESEMPEO
Definicin Pruebas de
Aceptacin
The
International Software Testing Qualifications
Board
(ISTQB) Standard glossary of terms, version
1.3 (dd. May, 31, 2007), la definicin
sindicada es la siguiente:
"Formal testing with respect to user needs,
requirements,
and
business
processes
conducted to determine whether or not a system
satisfies the acceptance criteria and to enable
the user, customers or other authorized entity to
determine whether or not to accept the system."
Pruebas de aceptacin
Propsito: guiar la decisin de si el producto
en su estado actual debe o no
serseliberado.
Cmo
determina esta
Objetivo: demostrar que el decisin?
sistema se
encuentra listo para su utilizacin operacional:
Pruebas de aceptacin
Pruebas ALFA
Se lleban acabo en el lugar de desarrollo con un
stakeholder por parte del cliente y con el desarrollador
como observador, registrando los errores encontrados y
los problemas de uso.
Se ejecutan en entornos controlados. Este tipo de pruebas
Pruebas BETA
Pruebas de aceptacin
Desde la perspectiva de la ESA
Segn el estandar ESA PSS050, las pruebas de
aceptacin se refieren al proceso de probar el
sistema contra los requerimientos de usuario.
La entrada a las pruebas de aceptacin
corresponde al software exitosamente probado a
nivel de sistema.
Plan de Pruebas de Aceptacin:
Es construdo y documentado en el SVVP.
Se define durante la fase UR y debe describir el
mbito, acercamiento, recursos y calendario de las
pruebas de aceptacin que se pretende realizar.
Pruebas de aceptacin
Diseo de Pruebas de Aceptacin:
el diseo de pruebas de aceptacin debe especificar el
detalle de las pruebas de acercamiento para los
requerimientos de usuario, o combinaciones de los
requerimientos de usuario; e identificar los casos de
prueba y procedimientos de prueba asociados.
Aqui no se requiere del conocimiento de cmo trabaja el
software internamente no utilizar pruebas de caja blanca.
La especificacin de requerimientos de usuario (URD) debe
ser dividida en requermientos de capacidad y de restriccin
para el acercamiento de pruebas.
Pruebas de Capacidad
Pruebas de Restriccin
Pruebas de aceptacin
Especificacin de las pruebas de aceptacin:
Pruebas de aceptacin
Desventajas
Los usuarios no saben como probar o no son
entrenados para probar el producto de software.
Bajo las restricciones de tiempo, se le entregan al
usuario suit de pruebas que ejecutan los caminos
seguros, y no se ejecutan pruebas exhaustivas o bajo
condiciones interesantes que permitan evidenciar
errores en la funcionalidad.
Pruebas de aceptacin
Cul es el error en la propuesta de
acercamiento para pruebas de aceptacin
siguiente?
Voy a darles una breve introduccin de cmo el sistema
funciona. Luego les proporcionare un manual de usuario
y algunos datos de ejemplo (como listados de productos
que han sido previamente ingresados al sistema) y
quisiera que utilicen la aplicacin para completar las
tareas para las cuales la aplicacipon debe ser utilizada.
Miestras
trabajen,
por favor
proporcione informacin
Lo que
debe buscarse
tiene relacin
con:
su experiencia
con de
la acuerdo
aplicacin
enseel
sobre
Los usuarios
del sistema estn
con que
ha formulario
dado
adjunto.
satisfaccin. a las necesidades que ellos plantearon para el sistema?"
Pruebas de aceptacin
No olvidar qu se espera del ingeniero de
pruebas que disea las pruebas de aceptacin,
eso implica que conteste a la interrogante:
Cmo diseo pruebas de aceptacin que satisfagan las
necesidades de la gerencia de proyecto para determinar
si el usuario final estar de acuerdo con que los
requerimientos han sido logrados, a la vez que cumplo
con mi obligacin de capturar la informacin que
requiero para proporcionar una satisfaccin global al
usuario con
LA RESPUESTA
ES: respecto al producto a travs de una
comprensiva
para el
mismo???
evaluacin
Suits de pruebas
altamente
estructuradas,
con scripts
de aceptacin paso a paso por parte del usuario, que
contengan criterios de aprobacin/rechaso especficos y
derivados desde los requerimientos del sistema, de
manera tal que proporcionen el tiempo y mecanismo de
feedback requeridos.
Pruebas de aceptacin
Resumen
Las pruebas de aceptacin verifican la adecuacin a
las necesidades del usuario.
Las pruebas de aceptacin son llebadas a cabo por
grupos de pruebas que involucran usuarios.
Las pruebas de aceptacin verifican la correctitud y
completitud del producto de software.
Las pruebas de aceptacin son una actividad de
validacin que busca lograr, primeramente, la
aceptabilidad del producto; incluye juicios sobre su
utilidad actual y su usabilidad, ms que la
conformidad con los requerimientos de especificacin.
Pruebas de Regresin
Definicin
Es el proceso de probar los cambios para un
programa de computadoras asegurndose de que
el programa antiguo seguir funcionando con los
nuevos cambios.
Pruebas de Regresin
Definicin
Corresponde a la ejecucin de un conjunto de
casos de prueba a un programa con el fin de
garantizar que su revisin (y consecuente
mantencin correctiva, adaptativa o evolutiva)
no produce defectos no deseados, que no
implica un retroceso, es decir, se vuelva menos
eficaz que lo que haba sido en el pasado.
Asegura que los cambios hechos durante la
mantencin no destruyan las funcionalidades
existentes.
Pruebas de Regresin
Por qu las pruebas de regresin son un
problema?
Los sistemas grandes pueden tomar MUCHO tiempo
en ser re-testeados.
Puede ser difcil y altamente demandante, en
trminos de tiempo, crear las pruebas.
Puede ser difcil y altamente demandante evaluar
las pruebas
Seleccin de Pruebas de
Regresin
La reduccin de costos: seleccionar un sub grupo
Definicin
Necesario porque
Seleccin de Pruebas de
Regresin
Ejemplo
Seleccin de Pruebas de
Regresin
Ejemplo 2
Pruebas de Regresin
Cmo escribir una pruebas de regresin en el
Plan de Pruebas?
Cul es el objetivo de la prueba?
Pruebas de Regresin
Cmo escribir una pruebas de regresin en el Plan de Pruebas?
Glossary
Test planning: The activity of establishing or updating
a test plan.
Test plan: A document describing the scope,
approach, resources, and schedule of intended test
activities. It identifies, amongst others, test items,
the features to be tested, the testing tasks, who will
do each task, the degree of tester independence, the
test environment, the test design techniques and
entry and exit criteria to be used and the rationale
for their choice, and any risks requiring contingency
planning. It is a record of the test planning process.
Glossary
Test case: A set of input values, execution preconditions,
expected
results,
and
execution
post-conditions
developed for a particular objective or test condition,
such as to exercise a particular program path or to verify
compliance with a specific requirement.
Test condition: An item or event of a component or
system that could be verified by one or more test cases
(e.g., a function, transaction, feature, quality attribute, or
structural element).
Test execution: The process of running a test on the
component or system under test, producing actual
result(s).
Glossary
Test procedure: A document specifying a
sequence of actions for the execution of a test.
Also known as test script or manual test script.
Test control: A test management task that deals
with developing and applying a set of
corrective actions to get a test project on track
when monitoring shows a deviation from what
was planned.
Test implementation: The process of developing
and prioritizing test procedures, creating test
data, and, optionally, preparing test harnesses
and writing automated test scripts.
Glossary
Test script: Commonly used to refer
to a test procedure specification,
especially an automated one.
Test log: A chronological record of
relevant details about the execution
of tests.
Test
logging:
The
process
of
recording information about tests
executed into a test log.
Glossary
Exit criteria: The set of generic and specific conditions, agreed upon
with the stakeholders, for permitting a process to be officially
completed. The purpose of exit criteria is to prevent a task from
being considered completed when there are still outstanding parts
of the task that have not been finished. Exit criteria are used to
report against and to plan when to stop testing.
Test closure: During the test closure phase of a test process, data is
collected from completed activities to consolidate experience,
testware, facts, and numbers. The test closure phase consists of
finalizing and archiving the testware and evaluating the test
process, including preparation of a test evaluation report.
Test summary report: A document summarizing testing activities
and results. It also contains an evaluation of the corresponding test
items against exit criteria.