FUNDAMENTOS DEL SOFTWARE

ANLISIS
CERTIFICACIN ISTQB

Dorothy Graham

Erik van Veenendaal

Isabel Evans

Rex Negro

CONTENIDO

Expresiones de gratitud

ix Prefacio viii

1.5

Fundamentos de la prueba 1

1.1

Por qu es necesario probar?1

1.2

Cul es la prueba?[11

1.3

Principios de prueba 18

1.4

Proceso de prueba fundamental 20

La psicologa de las pruebas de revisin 26 Captulo 31

Examen de muestra cuestiona 32 Ejercicio: Prueba de la

psicologa solucin Ejercicio 33 34

Prueba de todo el ciclo de vida del software

2.1

Los modelos de desarrollo de software 35

2.2

Los niveles de prueba 41

2.3 Tipos de pruebas: los objetivos de la prueba

35

46

2.4 Mantenimiento opinin de pruebas 50 Captulo 54

Preguntas del examen de la muestra

55

Tcnicas estticas 57

3.1

Los comentarios y la prueba de proceso 57

proceso de revisin.
3.3 El anlisis esttico mediante herramientas de revisin 69
Captulo 74
Examen de muestra cuestiona 75

Tcnicas de diseo de pruebas 77

4.1

La identificacin de las condiciones de prueba y el diseo de casos de prueba 77

4.2

Categoras de tcnicas de diseo de pruebas 84

4.3

Las tcnicas basadas en la especificacin o negro-box 87

4.4

Tcnicas basadas en la estructura o de caja blanca 105

4.5

Tcnicas basadas en la experiencia 112

4.6

La eleccin de una tcnica de ensayo 114

captulo opinin

117

Preguntas del examen de la muestra

118

Ejercicios: tcnicas de diseo de pruebas

121

soluciones de los ejercicios

Gestin de Pruebas

Organizacin de Pruebas

5.2 Prueba de planes, estimaciones y estrategias

132

5.3

Prueba de control del progreso y el control 142

Gestin de la configuracin
5.5

Riesgo y pruebas 149

8.1.3 Administracin de Incidentes

Repaso del
captulo 161
preguntas del
examen de la
muestra

162

Nmero de marcadores
genticos para los que se
Ejercicio: informe realizaron pruebas...entre 7
de incidente
y 10 millones
solucion
de
ejercicios

166

6 Herramienta de
apoyo para las
pruebas

169

6,1 Tipos de herramienta de prueba 169

6,2 El uso efectivo de herramientas: beneficios y riesgos potenciales 184
6.3 La introduccin de una herramienta en una organizacin 190

captulo
opinin

193

preguntas del
examen de la
muestra

195

Fundacin ISTQB examen 197

Preparacin para el examen 197 Tomando el examen 199

201 examen de prueba

GLOSARIO
Las respuestas a las preguntas del examen 227 muestrean
Referencias 166
Author: %s
empresas

ndice:

Captulo 1 Fundamentos de la
prueba

Erealizar
n este captulo, se le dar a conocer los fundamentos de la prueba: por qu es necesario
exmenes; sus limitaciones, los objetivos y el propsito; los principios detrs de la
prueba; el proceso que sigue probadores; y algunos de los factores psicolgicos que los

evaluadores deben tener en cuenta en su trabajo.Mediante la lectura de este captulo obtendr una
comprensin de los fundamentos de la prueba y ser capaz de describir

esos fundamentos.

1.1 Por qu est probando NECESARIO?

1 Describir, con ejemplos, la forma en que un defecto en el software puede

causar dao a una persona, al medio ambiente oa una empresa.(k)

2 Distinguir entre la causa de un defecto y sus efectos.(k)

3 Dar las razones por las pruebas es necesario, dando ejemplos.(k)

4 Describir por qu la prueba es parte de la garanta de calidad y dar ejemplos

de cmo las pruebas contribuye a una mayor calidad.(k)

5 Recordemos los trminos "error", "defecto", "culpa", "fracaso" y "error"

ding los trminos y corres 'bug'.{0}k = 0.015 L{/0}{1}1{/1}

6 Explicar los principios fundamentales en las pruebas.(k)

10.1 INSTRODUCCION 107

En esta seccin, vamos a poner en marcha el libro con una discusin sobre qu es importante la
prueba. Vamos a describir e ilustrar cmo los defectos o errores de software pueden causar
problemas para las personas, el medio ambiente o una empresa. Dibujaremos importantes
distinciones entre dis-defectos, sus causas y sus efectos. Vamos a explicar por qu es necesario
encontrar pruebas de estos defectos, cmo las pruebas promueve la calidad, y cmo encaja en las
pruebas de control de calidad. En esta seccin, tambin vamos a introducir algunos principios
bsicos de la comprobacin.

A medida que avanzamos a travs de esta seccin, para ver los trminos del programa de
estudios de errores, defectos, errores, fracaso, culpa, error, la calidad, el riesgo, el software,
los ensayos y pruebas exhaustivas.

Usted encontrar estos trminos definidos en el glosario.

Usted puede preguntar "cul es la prueba?y vamos a ver ms de cerca la defi-nicin de las pruebas en
la Seccin 1.2. Por el momento, vamos a adoptar un uso-vida cotidiana sencilla: "cuando estamos
probando algo estamos comprobando si es OK '. Vamos a tener que redefinir que cuando definimos las
pruebas de software ms adelante. Vamos a empezar por considerar por qu es necesario realizar
exmenes. La prueba es necesaria porque todos los errores de toma. Algunos de esos errores no son
importantes, pero algunos de ellos son caros o peligrosos. Tenemos que comprobar todo y cualquier cosa
que producimos porque las cosas siempre pueden ir mal - los seres humanos cometen errores todo el
tiempo - es lo que hacemos mejor!

Debido a que debemos asumir nuestro trabajo contiene errores, todos tenemos que revisar nuestro
propio trabajo. Sin embargo, algunos errores provienen de malas suposiciones y puntos ciegos, por lo que
podran hacer los mismos errores cuando comprobamos nuestro propio trabajo como hicimos cuando lo
hicimos. As que es posible que no note los defectos en lo que hemos hecho. Lo ideal sera conseguir a

alguien ms para comprobar nuestro trabajo - otra persona tiene ms probabilidades de detectar los
defectos.

En este libro, vamos a explorar las implicaciones de estos dos prrafos simples y otra vez. Qu importa si
hay errores en lo que hacemos? Qu importa si no nos encontramos con algunos de esos defectos? Sabemos
que en la vida ordinaria, algunos de nuestros errores no importan, y algunos son muy importantes. Es lo mismo
con los sistemas de software. Necesitamos saber si es probable que cause problemas de un error en particular.
Para ayudarnos a pensar en esto, debemos tener en cuenta el contexto en el que se utilizan diferentes sistemas
de software.

contexto 1.1.2 Los sistemas de software

Prueba Principio - La prueba es dependiente del contexto

La prueba se realiza de forma diferente en diferentes contextos. Por ejemplo, el software de seguridad crtico se prueba
de forma diferente a partir de un sitio de comercio electrnico.

En estos das, casi todo el mundo es consciente de los sistemas de software.Los encontramos en nuestros
hogares, en el trabajo, mientras que las compras, y debido a los sistemas de comunicacin de masas. Cada vez
ms, son parte de nuestras vidas. Utilizamos el software de aplicaciones empresariales del da a da, tales como
la banca y en productos de consumo tales como automviles y lavadoras. Sin embargo, la mayora de la gente
ha tenido una experiencia con el software que no funcion como se esperaba: un error en una factura, un
retraso cuando la espera de una tarjeta de crdito para procesar y un sitio web que no se carga correctamente
son ejemplos comunes de los problemas que pueden ocurrir debido de problemas de software. No todos los
sistemas de software de llevar el mismo nivel de riesgo y no todos los problemas tienen el mismo impacto
cuando se producen.Un riesgo es algo que no ha Hap-PNED todava y puede que nunca llegue a suceder; es
un problema potencial. Estamos preocupados por estos problemas potenciales, ya que, si uno de ellos fue as,
nos sentimos un impacto negativo. Cuando hablamos de riesgos, debemos tener en cuenta qu tan probable es
que el problema se produce, y el impacto en caso de que suceda. Por ejemplo, cada vez que se cruza la
carretera, hay un cierto riesgo de que vamos a ser heridos por un coche. El likeli cap depende de factores tales
como el volumen de trfico en la carretera, si hay un lugar de paso seguro, lo bien que podemos ver, y qu tan
rpido podemos cruzar. El impacto depende de qu tan rpido se va el coche, si estamos usando equipo de
proteccin, nuestra edad y nuestra salud. El riesgo de una persona en particular se puede resolver y por lo tanto
la mejor estrategia de ruta de cruce.

Algunos de los problemas que nos encontramos al utilizar el software son bastante trivial, pero otros pueden
ser costosos y perjudiciales - con la prdida de dinero, tiempo o reputacin de la empresa - e incluso puede
provocar lesiones o la muerte.Por ejemplo, supongamos que una interfaz de usuario tiene defectos tipogrficos.
Importa esto? Puede ser trivial, pero podra tener un efecto significativo, segn el sitio web y el defecto:

Si mi sitio web personal rbol genealgico ha apellido de soltera de mi abuela materna mal escrito, mi
madre se molesta y tengo que aguantar algunas burlas familia, pero se puede arreglar con facilidad y slo la
familia verlo (probablemente).

Si el sitio web de la compaa tiene algunas faltas de ortografa en el texto, potenciales clien- cus se
pueden poner fuera de la empresa, ya que parece poco profesional.
Si un programa de software calcula mal cantidades aplicacin de plaguicidas, el efecto podra ser muy
significativa: supongamos que se coloca errneamente un punto decimal de modo que la tasa de aplicacin
es 10 veces demasiado grande.El agricultor o jardinero utiliza ms plaguicidas de los necesarios, lo que
eleva sus costos, tiene impactos ambientales sobre la fauna y agua y tiene impacto en la salud y la
seguridad para el agricultor, jardinero, la familia y la fuerza de trabajo, ganado y animales domsticos.
Tambin puede haber consiguiente prdida de confianza en los negocios y para la empresa y posi ble costos
legales y multas por causa de los problemas ambientales y de salud.

1.1.3 Las causas de los defectos de software

Por qu es que los sistemas de software a veces no funcionan correctamente? Sabemos que la gente
comete errores - que son falibles.

Si alguien comete un error o un error en el uso del software, esto puede conducir directamente a un
problema - el software se utiliza de forma incorrecta y por lo tanto no se comporta como esperbamos.Sin
embargo, las personas tambin disear y construir el software y pueden cometer errores durante el diseo
y la construccin. Estos errores significan que hay fallas en el software en s. Estos son los llamados
defectos o, a veces errores o fallos.Recuerde que el software no es slo el cdigo; comprobar la
definicin de soft-ware de nuevo para recordar.

Cuando el cdigo de software se ha construido, se ejecuta y luego cualquier defecto puede hacer que el
sistema falle para hacer lo que debe hacer (o hacer algo que no debera), causando un fracaso. No todos
los defectos dan lugar a fallos; algunas permanecen latentes en el cdigo y puede que nunca les aviso.

S importan nuestros errores?

Vamos a pensar en las consecuencias de los errores. Estamos de acuerdo en que cualquier ser humano,
programadores y probadores incluidos, puede cometer un error. Estos errores pueden producir defectos
en el cdigo de software o sistema, o en un documento. Si se ejecuta un defecto en el cdigo, el sistema
puede experimentar un fracaso. Por lo que los errores que cometemos cuestin en parte porque tienen
consecuencias para los productos para los que somos responsables.

Nuestros errores son tambin importantes porque los sistemas y proyectos de software son complicadas.
Muchos de los productos intermedios y finales se construyen durante un proyecto, y la gente es casi seguro
que cometer errores y errores en todas las actividades de la construccin. Algunos de stos se encuentran y se
retira por los autores de la obra, pero es difcil para las personas a encontrar sus propios errores, mientras que
la construccin de un producto. Los defectos en software, sistemas o documentos pueden resultar en fallos,
pero no todos

defectos causan fallos.Podramos argumentar que si un error no conduce a un defecto o un defecto no

conduce a un fallo, entonces no es de importancia - que ni siquiera saben que hemos hecho un error.

Nuestra falibilidad se agrava cuando nos falta experiencia, no tenemos la informacin correcta,
malinterpretar, o si no tenemos cuidado, cansado o bajo la presin del tiempo. Todos estos factores
afectan nuestra capacidad para tomar decisiones sensatas - nuestro cerebro, o bien no tienen la
informacin o no pueden procesar con la suficiente rapidez.

Adems, somos ms propensos a cometer errores cuando se trata de perplex-Ing problemas tcnicos o
de negocio, procesos de negocio complejos, cdigo o infra-estructura, las tecnologas cambiantes, o
muchas interacciones del sistema. Esto se debe a que nuestro cerebro slo puede tratar con una cantidad
razonable de complejidad o el cambio - cuando se le pregunt que lidiar con ms nuestros cerebros no
pueden procesar la informacin que tenemos correctamente.

No es slo los defectos que dan lugar al fracaso. Las fallas tambin pueden ser causados por
condiciones ambientales, as: por ejemplo, una rfaga de radiacin, un fuerte campo mag-ntico, campos
electrnicos, o la contaminacin podran causar fallos en el hardware o firmware. Esos defectos pueden
prevenir o modificar la ejecucin de un programa. Las fallas tambin pueden surgir debido a un error
humano en la interaccin con el software, tal vez se introduce un valor de entrada incorrecta o una salida

siendo mal interpretada. Por ltimo, las fallas tambin pueden ser causados por alguien deliberadamente
tratando de provocar un fallo en un sistema - dao malicioso.

Cuando pensamos en lo que podra salir mal, tenemos que considerar los defectos y fallas que surgen
de:

errores en la especificacin, diseo e implementacin del software y del sistema;

errores en el uso del sistema;

Condiciones ambientales

dao intencional;

posibles consecuencias de los errores anteriores, dao intencional, defectos y fracasos.

Cuando surgen defectos?

En la figura 1.1 podemos ver cmo pueden surgir defectos en cuatro requisitos de un producto.

Podemos ver que el requisito 1 se implementa correctamente - comprendimos las necesidades del cliente,
diseado correctamente para cumplir con este requisito, construido cor-rectamente a conocer el diseo, y as
entregar ese requisito con las correctas attrib-nutos: funcionalmente, que hace lo que se supone que debe hacer
y tambin tiene los atributos no funcionales adecuadas, por lo que es lo suficientemente rpido, fcil de
entender y as sucesivamente.

Con los dems requisitos, se han cometido errores en diferentes etapas. Requisito 2 es bien hasta que se codifica
el software, cuando hacemos algunos errores e introducir defectos. Probablemente, estos se puedan distinguir
fcilmente y corregirse durante la prueba, ya que podemos ver el producto no cumple con las caractersticas de
diseo.

Los defectos introducidos en el requisito 3 son ms difciles de tratar; hemos construido exactamente lo que
nos dijeron que por desgracia, pero el diseador hecho algunos errores de toma de modo que haya defectos en
el diseo. A menos que comprobamos en contra de la definicin requerir-mentos, no vamos a detectar esos
defectos durante la prueba. Cuando hacemos notar que van a ser difcil de solucionar porque sern necesarios
cambios en el diseo.

Se introdujeron los defectos en el requisito 4 durante la definicin de los requisitos; el producto ha sido
diseado y construido para satisfacer los requisitos de esta definicin defectuosa. Si se prueba que el producto
cumpla con los requisitos y el diseo, que va a pasar sus pruebas, pero puede ser rechazado por el usuario o
cliente. Defectos reportados por el cliente en la prueba de aceptacin o uso directo puede ser muy costoso.
Desafortunadamente, los requisitos y defectos de diseo no son raros; evaluaciones de miles de proyectos han
demostrado que los defectos introducidos durante requisitos y el diseo constituyen cerca de la mitad del
nmero total de defectos [Jones].

Cul es el costo de los defectos?

Adems de considerar el impacto de los fallos derivados de defectos que no hemos encontrado, tenemos que
considerar el impacto de cuando nos encontramos con esos defectos. El costo de encontrar y corregir defectos
se eleva considerablemente en todo el ciclo de vida; pensar en el viejo proverbio Ingls "una puntada a tiempo
ahorra nueve '. Esto significa que si usted reparar un desgarro en el manguito de ahora, si bien es pequea, es
fcil de reparar, pero si lo deja, va a empeorar y necesitan ms puntos de sutura para repararlo.

Si relacionamos los escenarios mencionados anteriormente a la figura 1.2, vemos que, si se comete un error
y se detecta el consiguiente defecto en los requisitos en la fase de especificacin, entonces es relativamente
barato para encontrar y corregir. La obser-cin del aumento de los costes de eliminacin de defectos en el
software se remonta a [Boehm]. Encontrar evidencia de la economa de otras actividades de control de
calidad de pruebas y en gilb [], [Negro 2001] o [Negro 2004]. La especificacin puede ser cor-rected y reemitida. Del mismo modo, si se comete un error y el consiguiente defecto detectado en el diseo en la fase de
diseo a continuacin, el diseo se puede corregir y re-emite con un costo relativamente bajo. Lo mismo se
aplica para la construccin. Si

Sin embargo un defecto se introduce en la especificacin de requisitos y no se detecta hasta que las
pruebas de aceptacin o incluso una vez que el sistema ha sido imple-mentado entonces ser mucho ms
caros de solucionar. Esto es porque ser necesaria la reanudacin en la especificacin y diseo antes de
los cambios se pueden hacer en con-construccin; debido a un defecto en los requisitos bien puede
propagar en varios lugares en el diseo y el cdigo; y porque todo el trabajo realizado pruebas a ese punto
tendr que ser repetida con el fin de alcanzar el nivel de confianza en el software que se requiere.

Es muy frecuente el caso de que los defectos detectados en una etapa muy tarda, dependiendo de la
gravedad de la misma, no son corregidos debido a que el costo de hacerlo es demasiado caro. Adems, si el
software se entrega y cumple las especificaciones acordadas, que a veces todava no ser aceptada si la
especificacin estaba mal. El equipo del proyecto puede haber entregado exactamente lo que se les pidi que
entregar, pero no es lo que queran los usuarios. Esto puede llevar a los usuarios ser infeliz con el sistema que
finalmente se entrega. En algunos casos, cuando el defecto es demasiado grave, el sistema puede tener que ser
desinstalados completamente.

1.1.4 Papel de las pruebas de software de desarrollo, mantenimiento y operaciones

Hemos visto que los errores humanos pueden causar un defecto o falla al ser introducidos en cualquier etapa
dentro del ciclo de vida de desarrollo de software y, dependiendo de las consecuencias del error, los resultados
pueden ser triviales o catastrfica. Pruebas rigurosas es necesario durante el desarrollo y mantenimiento para

identificar defectos, con el fin de reducir los fallos en el entorno operativo y aumentar la calidad del sistema
operativo. Esto incluye la bsqueda de lugares en la interfaz de usuario que un usuario podra cometer un error
en la entrada de datos o en la interpretacin de la salida, y en busca de posibles puntos dbiles de ataque
intencional y maliciosa. Encargado de realizar la ayuda a avanzar hacia una mejor calidad de producto y
servicio, pero eso es slo uno de los mtodos de verificacin y validacin aplicados a los productos. Los
procesos tambin se comprueban, por ejemplo mediante una auditora. Una variedad de mtodos se puede
utilizar para comprobar el trabajo, algunos de los cuales son realizados por el autor de la obra y unos por otros
para obtener una visin independiente.

Tambin es posible que sea necesario para llevar a cabo las pruebas de software para satisfacer los
requisitos contractuales o legales, o las normas especficas de la industria.Estas normas pueden
especificar qu tipo de tcnicas que debemos utilizar, o el porcentaje de cdigo de software que debe ser
ejercido. Puede ser una sorpresa saber que no siempre probar todo el cdigo; eso sera demasiado caro en
comparacin con el riesgo que estamos tratando de hacer frente a. Sin embargo - como es de esperar - el
ms alto es el riesgo asociado a la indus-intente utilizar el software, lo ms probable es que va a existir un
estndar para la prueba. Las industrias de avinica, motor, mdicos y farmacuticos tienen normas
relativas a las pruebas de software. Por ejemplo, el estndar DO-178B de la Administracin Federal de
Aviacin de los Estados Unidos [RTCA / DO-178B] tiene requisitos para la cobertura de la prueba.

1.1.5 Pruebas y calidad

Las pruebas nos ayuda a medir la calidad de software en trminos de la cantidad de defectos encontrados, las
pruebas se ejecutan, y el sistema cubierto por las pruebas.Podemos hacer esto tanto para los atributos
funcionales del software (por ejemplo, la impresin de un informe correctamente) y de los requisitos no
funcionales de software y caractersticas (por ejemplo, la impresin de un informe con la suficiente rapidez).
caractersticas no funcionales se describen en el Captulo 2. Las pruebas pueden dar confianza en la calidad de
la suave-mercancas si encuentra pocos o ningn defectos, siempre estamos contentos de que la prueba es
riguroso SUF-temente. Por supuesto, una prueba pobre puede descubrir algunos defectos y nos dejan con una
falsa sensacin de seguridad. Una prueba bien diseado descubrir defectos si estn presentes y por lo tanto, si
pasa una prueba de este tipo, que ser, justamente, ms confianza en el software y poder afirmar que el nivel
general de riesgo de la utilizacin del sistema se ha reducido. Cuando las pruebas no encontrar defectos, la
calidad del sistema de software se incrementa cuando se fijan esos defectos, siempre que las correcciones se
llevan a cabo correctamente.

Qu es la calidad?

Proyectos tienen como objetivo ofrecer software de especificacin. Para el proyecto de ofrecer lo que
necesita el cliente requiere una especificacin correcta. Adems, el sistema entregado debe cumplir con la
especificacin. Esto se conoce como validacin ( "es esta la especificacin correcta? ') y verificacin ( 'es
el sistema adecuado a las especificaciones-ficacin?'). Por supuesto, adems de querer que el sistema de
software adecuado construida cor-rectamente, el cliente quiere que el proyecto sea dentro del presupuesto
y la escala de tiempo - que debe llegar cuando lo necesitan y no cuestan demasiado.

La definicin del glosario ISTQB abarca no slo los requisitos especificados, sino tambin a las necesidades y
expectativas de los usuarios y de los clientes. Es importante que el equipo del proyecto, los clientes y otros
interesados en el proyecto establecen y acuerdan expecta-ciones. Tenemos que entender lo que los clientes entienden
por calidad y cules son sus expectativas. Lo que nosotros como desarrolladores de software y probadores podemos
ver como la calidad - que el software cumple con su especificacin definida, es tcnicamente excelente y tiene
algunos errores en ella - no puede proporcionar una solucin de calidad para nuestros CUS-clien-. Por otra parte, si
nuestros clientes a encontrar que han gastado ms dinero de lo que queran o que el software no ayuda a llevar a
cabo sus tareas, no van a ser impresionados por la excelencia tcnica de la solucin. Si el cliente quiere un coche
barato para una "gestin sobre 'y tiene un pequeo presupuesto, entonces un costoso

coche deportivo o un tanque militar no son soluciones de calidad, por muy bien
que son construidos.

Para ayudar a comparar diferentes expectativas de las personas, la Tabla 1.1

resume y explica los puntos de vista y expectativas usando "la produccin y la
compra de los tomates 'como una analoga de calidad de' la produccin y compra
de software '. Vas a ver como se mira a travs de la mesa que el enfoque de la
prueba sera muy diferente dependiendo de qu punto de vista estamos a favor de
[Trienekens], [Evans].

Adems de comprender lo que la calidad se siente y se parece a los clientes,

usuarios y otras partes interesadas, que ayuda a tener algunos atributos de calidad
para medir la calidad en contra, sobre todo para ayudar a la primera, basada en el
producto, punto de vista de la tabla. Estos atributos o caractersticas pueden servir
como un marco o listas de comprobacin para las reas a tener en cuenta la
cobertura. Una de esas conjunto de atributos de calidad puede

TABLA 1.1

Puntos de vista de las expectativas y la calidad

Punto de vista

Software

Tomates

La calidad se mide observando los atributos del producto.

Vamos a medir los atributos del software, por ejemplo, su fiabilidad en trminos de tiempo medio entre fallos (MBTF), y
suelte cuando llegan a un nivel especificado por ejemplo MTBF de 12 horas.

Los tomates son el tamao y la forma correcta para el embalaje para el supermercado. Los tomates tienen un buen sabor y
color,

La calidad es la aptitud para el uso. La calidad puede tener aspectos subjetivos y no slo los aspectos cuantitativos.

Vamos a pedir a los usuarios si pueden llevar a cabo sus tareas; si estn satisfechos de que puedan se dar a
conocer el software.

Los tomates son adecuados para nuestra receta,

La calidad se basa en buenos procesos de fabricacin, y la reunin de los requisitos definidos. Se mide mediante
pruebas, inspeccin y anlisis de fallos y los errores.

Vamos a utilizar un proceso de desarrollo de software reconocido. Slo se dar a conocer el software si hay menos de
cinco defectos de alta prioridad en circulacin una vez que las pruebas son planificados

completar el acusado.

Los tomates son cultivados orgnicamente. Los tomates no tienen manchas y sin dao de la plaga,

Expectativa de relacin calidad-precio.

Hemos encajadas en tiempo para la prueba

asequibilidad, y una compensacin basada en el valor

entre el tiempo, esfuerzo y aspectos econmicos.

dos semanas para mantenerse en el proyecto

presupuesto.

Podemos darnos el lujo de comprar este software y

esperamos un retorno de la inversin.

Los tomates tienen una buena vida til. Los tomates son de valor econmico o de buena calidad-precio,

sentimientos trascendentes - esto es acerca de los sentimientos de un individuo o grupo de individuos hacia un
producto o un proveedor.

Nos gusta este software! Es divertido y es la ltima cosa! Entonces, qu si tiene algunos problemas? Queremos
utilizar de todos modos ...

Nos gusta trabajar con este equipo de software. Por lo tanto, hubo algunos problemas - que ellos lo solucionaron
muy rpido - confiamos en ellos.

Obtenemos nuestros tomates de una pequea granja local y nos llevamos

tan bien con los productores,

se encuentran en la norma ISO 9126.Esta jerarqua de caractersticas y sub-caractersticas de calidad se

discute en el Captulo 2.

Qu es el anlisis de causa raz?

Cuando detectamos fallos, podramos tratar de rastrear de nuevo a su causa fundamental, la verdadera razn de
que ocurrieron. Hay varias formas de llevar a cabo el anlisis de causa raz, a menudo con un grupo de lluvia
de ideas y discutirlas, por lo que pueden ver diferentes tcnicas en diferentes organizaciones. Si est entre
sados en el uso de anlisis de causa raz en su trabajo, encontrar tcnicas simples que se describen en [Evans],
[TQMI] y [Robson]. Por ejemplo, supongamos que una organi-zacin tiene un problema con la impresin, de
manera repetida. Algunos de TI popular de mantenimiento se renen para examinar el problema y empiezan
por la lluvia de ideas todas las posibles causas de los fracasos. A continuacin, se agrupan en categoras que
han elegido, y ver si hay causas subyacentes o profundas comunes. Algunas de las causas obvias que descubren
podra ser:

Impresora se queda sin suministros (tinta o papel).

Software del controlador de impresora falla.

Sala de la impresora est demasiado caliente para la impresora y se apodera de arriba.

Estas son las causas inmediatas. Si nos fijamos en uno de ellos - 'impresora se queda sin suministros
(tinta o papel)' - puede ocurrir debido a:

Nadie es responsable de comprobar los niveles de papel y de tinta en la impresora; posible causa
fundamental: ningn proceso para comprobar los niveles de tinta / papel de la impresora antes de su
uso.

Algunos empleados no saben cmo cambiar los cartuchos de tinta; posible causa fundamental: el
personal no capacitado o dado instrucciones en el cuidado de las impresoras.
No hay suministro de cartuchos de repuesto o papel; posible causa fundamental: ningn proceso
de control de existencias y pedidos.

Si su prueba se limita al software, lo podra hacer en estos y decir, 'No se trata de problemas de software,
por lo que no nos conciernen!' As que, como probadores de software que podramos limitarnos a informar del

fallo de controlador de impresora. Sin embargo, nuestra competencia como probadores puede estar ms all del
software; podramos tener un mandato para mirar a todo un sistema que incluye hardware y firmware. Adems,
incluso si nuestra competencia es el software, es posible que desee considerar la forma de software puede
ayudar a las personas a prevenir o resolver problemas; podemos mirar ms all de este punto de vista. El
software podra proporcionar una interfaz de usuario que ayuda al usuario anticipar cuando el papel o la tinta
se est agotando. Se podra proporcionar instrucciones paso a paso para ayudar a los usuarios cambiar los
cartuchos o reponer papel. Se podra proporcionar una advertencia de alta temperatura, de modo que el medio
ambiente puede ser controlado. Como probadores, que no quieren slo de pensar e informar sobre los defectos,
pero, con el resto del equipo del proyecto, pensar en cualquier posibles causas de fallos.

Utilizamos las pruebas para ayudarnos a encontrar fallos y los errores (potenciales) durante el desarrollo de
software, mantenimiento y operaciones. Hacemos esto para ayudar a reducir el riesgo de fallos que se
producen en un entorno operativo - en otras palabras, una vez que el sistema est siendo utilizado - y contribuir
a la calidad del sistema de software. Sin embargo, al mismo tiempo tenemos que pensar e informar sobre una
amplia variedad de defectos y fallos, no todos se arreglen. Programadores y otros pueden corregir defectos

antes de divulgar el sistema para su uso operativo, pero puede ser ms sensible a evitar el fracaso.La fijacin
de un defecto tiene alguna posibilidad de introducir otro defecto o de ser hecho incorrecta o incompleta. Esto
es especialmente cierto si estamos arreglando un defecto bajo presin. Por esta razn, los proyectos tendrn
una vista a veces que van a diferir la fijacin de un fallo. Esto no quiere decir que el probador que ha
encontrado los problemas ha perdido el tiempo. Es til saber que hay un problema y que puede ayudar al
sistema a los usuarios trabajar alrededor y evitarlo.

Cuanto ms rigurosa nuestras pruebas, las ms defectos que encontraremos. Pero se ver en los
captulos 3 y 4, cuando nos fijamos en las tcnicas de prueba, que rigurosas pruebas no significa
necesariamente ms pruebas; lo que queremos hacer es la prueba que encuentra defectos - un pequeo
nmero de pruebas selectivas, bien situados puede ser ms riguroso que un gran nmero de pruebas mal
enfocadas.

Vimos anteriormente que una de las estrategias para hacer frente a los errores, fallos y los errores es tratar
de evitar que ellos, y nos fijamos en la identificacin de las causas de los defectos y fallas. Cuando
empezamos un nuevo proyecto, vale la pena aprender de los problemas encontrados en proyectos anteriores o
en el software de produccin. La comprensin de las causas fundamentales de la cts DEFE es un aspecto
importante de las actividades de aseguramiento de la calidad, y las pruebas contribuye al ayudarnos a
identificar defectos tan pronto como sea posible antes de que el software est en uso.Como probadores,
tambin estamos interesados en el estudio de los defectos encontrados en otros proyectos, por lo que podemos
mejorar nuestros procesos. Las mejoras de proceso deben evitar los defectos recurrentes y, como
consecuencia, mejorar la calidad de los sistemas futuros. Las organizaciones deben considerar la prueba como
parte de una estrategia de aseguramiento de la calidad ms grande, que incluye otras actividades (por ejemplo,
las normas de desarrollo, la formacin y el anlisis de la causa raz).

1.1.6 Cunto prueba es suficiente?

Principio de pruebas - Las pruebas exhaustivas no es posible

Prueba de todo (todas las combinaciones de insumos y las condiciones previas) no es factible a excepcin de los casos triviales. En
lugar de pruebas exhaustivas, utilizamos los riesgos y prioridades para enfocar los esfuerzos de prueba.

Hemos visto que las pruebas nos ayuda a encontrar defectos y mejorar la calidad del software. La
cantidad de pruebas debemos hacer? Tenemos una opcin: Prueba de todo, nada prueba o anlisis,
algunos de los programas. Ahora, su respuesta inmediata para que as puede ser decir, "Todo debe ser
probado '. No queremos utilizar el software que no ha sido completamente probado, verdad? Esto
implica que hay que ejercitar todos los aspectos de un sistema de software durante la prueba. Lo que
tenemos que considerar es si debemos, o incluso puede, prueba completamente.

Veamos la cantidad de pruebas tendramos que hacer para ser capaz de probar exhaus-vamente.
Cuntas pruebas se necesita para hacer para probar completamente un campo numrico de un dgito? La
pregunta inmediata es: "Qu quiere decir con la prueba por completo? Hay 10 posibles valores
numricos vlidos, pero as como los valores vlidos que necesitamos para asegurar que todos los valores
vlidos son rechazados. Hay 26 caracteres alfabticos en maysculas, minsculas y caracteres 26, al
menos 6 especiales y de puntuacin, as como un valor en blanco. As no habra al menos 68 pruebas para
este ejemplo de un campo de un dgito.

Este problema solo empeora a medida que nos fijamos en los ejemplos ms realistas. En prcti-Tice, los
sistemas tienen ms de un campo de entrada con los campos que son de diferentes tamaos. Estas pruebas
seran junto a otros como la ejecucin de las pruebas de diferencia

Seccin 2

Cul es la prueba?

ambientes ENT. Si tomamos un ejemplo en una pantalla cuenta con 15 campos

de entrada, cada uno con 5 valores posibles, a continuacin, para poner a
prueba todas las combi-ciones de valor de entrada vlidos que se necesita 30
517 578 125 (5) 15 pruebas!Es poco probable que las escalas de tiempo del
proyecto permitiran para este nmero de pruebas.

[11

Prueba de nuestro campo de un dgito con valores de 2, 3 y 4 hace que

nuestras pruebas ms thor-ough, pero no nos da ms informacin que si
acabbamos de prueba con el valor 3.

Las presiones sobre un proyecto incluyen el tiempo y el presupuesto, as

como la presin para ofrecer una solucin tcnica que satisfaga las necesidades
de los clientes. Clientes y gestores de proyectos tendr que pasar una cantidad
de pruebas que proporciona un retorno de la inversin para ellos. Este retorno
de la inversin incluye a prevenir las fallas-cin despus de la liberacin que
son costosos. Probando por completo - incluso si eso es lo que los clientes y
gestores de proyectos piden - simplemente no es lo que pueden permitirse.

En cambio, necesitamos un enfoque de prueba que proporciona la cantidad

correcta de las pruebas para este proyecto, estos clientes (y otras partes
interesadas) y este software. Hacemos esto mediante la alineacin de las
pruebas que hacemos con los riesgos para los clientes, las partes interesadas, el
proyecto y el software. La evaluacin y gestin del riesgo es una de las
actividades ms importantes en cualquier proyecto, y es una actividad clave y
la razn para la prueba. Decidir la cantidad de pruebas es suficiente debe tener
en cuenta el nivel de riesgo, incluidos los riesgos tcnicos y comerciales
relacionados con las restricciones de productos y de proyectos tales como el
tiempo y el presupuesto.

Llevamos a cabo una evaluacin de riesgos para decidir la cantidad de

pruebas que hacer. A continuacin, podemos variar el esfuerzo de pruebas
basado en el nivel de riesgo en diferentes reas. Adems, las pruebas deben
proporcionar informacin suficiente a las partes interesadas para tomar
decisiones informadas acerca de la versin del software o el sistema que
estamos probando, para la siguiente etapa de desarrollo o entrega a los clientes.
El esfuerzo puesto en las actividades de garanta de calidad y de pruebas debe
ser tai lored a los riesgos y los costos asociados con el proyecto. Debido a los
lmites en el presupuesto, el tiempo, y en las pruebas que necesitamos para
decidir cmo vamos a centrar nuestra prueba, basado en los riesgos. Pronto nos
ocuparemos de la evaluacin de riesgos en el captulo 5.

1.2 Qu es la prueba?

objetivos de aprendizaje del programa de estudios para 1.2 Cul es la prueba?

1 Recordar los objetivos comunes de la prueba.{0}k = 0.015 L{/0}{1}1{/1}

2 Describir el propsito de las pruebas en el desarrollo de

software, mantenimiento
y las operaciones como un medio para encontrar
defectos, proporcionan confianza y infor

macin y prevenir los defectos. (k)

En esta seccin, vamos a revisar los objetivos comunes de la prueba. Vamos a

explicar cmo las pruebas nos ayuda a encontrar defectos, dar confianza y la
informacin, y evitar posibles daos. Tambin introduciremos otros principios
fundamentales de la prueba.

A medida que lea esta seccin, se encontrar con el cdigo trminos, la depuracin, desarrollo de
software, requisitos, revisin, base de pruebas, casos de prueba, ensayo y objetivo de la prueba.

1.2.1 La prueba de conduccin - una analoga para las pruebas de software

Hemos pasado algn tiempo describiendo por qu tenemos que probar, pero tenemos no dis-cussed lo que es
prueba. Qu entendemos por la palabra de pruebas? Utilizamos el test de palabras y las pruebas en la vida
cotidiana y dijimos anteriormente la prueba podra ser descrito como "la comprobacin del software est bien '.
Eso no es una definicin suficientemente detallada para ayudarnos a entender las pruebas de software. Vamos a
usar una analoga para ayudarnos: los exmenes de conduccin. En un examen de manejo, el examinador
evala crticamente la conduccin del candidato, tomando nota de cada error, grande o pequea, hecha por el
conductor bajo prueba. El examinador toma el conductor a travs de una ruta que pone a prueba muchas de las
actividades de conduccin posibles, tales como cruces de carreteras de diferentes tipos, de control y maniobra
del vehculo, capacidad para detener de forma segura en caso de emergencia, y la conciencia de la carretera,
otros usuarios de la carretera y los peligros. Algunas de las actividades deben ser probados.Por ejemplo, en el
Reino Unido, una prueba de parada de emergencia se realiza siempre, con el examinador simulando el
momento de la emergencia por golpear el tablero de instrumentos momento en el que el conductor debe
detener el coche rpida, segura y sin prdida de control. Al final de la prueba, el examinador hace un juicio

sobre el comportamiento del conductor. Ha pasado al conductor la prueba o no? El examinador basa la
sentencia sobre el nmero y la gravedad de los fallos detectados, y tambin si el conductor ha sido capaz de
satisfacer las necesidades de conduccin. Un fallo grave sola es suficiente para dejar toda la prueba, pero un
pequeo nmero de fallos menores an podra implicar que se super la prueba. Muchas fallas menores
reduciran la confianza del examinador en la calidad -de la conduccin hasta el punto en que el conductor no
puede pasar. El formato de la prueba de conduccin y la conduccin del examinador son dignas de
consideracin:

La prueba est previsto y preparado para.Antes de la prueba, el examinador ha planeado una

serie de rutas que cubren las actividades motrices clave para permitir una evaluacin exhaustiva de la
actuacin del conductor. Los conductores menores de prueba no saben qu ruta se les pedir a tomar
con antelacin, aunque conocen los requisitos de la prueba.

La prueba ha conocido metas - evaluar si el conductor es suficientemente seguro para ser

permitido para conducir por s mismos sin un instructor, sin poner en peligro ellos mismos u otros
ing.Hay pase claro / fallan criterios, basados en el nmero y la gravedad de las faltas, pero la
confianza del examinador en la conduccin tambin se tiene en cuenta.

Por lo tanto, la prueba se lleva a cabo para demostrar que satisface los controladores requieren los mentos
para la conduccin y para demostrar que estn en condiciones de conducir.El examinador busca fallas en la
conduccin. El tiempo para la prueba es limitado, por lo que no es una prueba completa de las capacidades del
conductor, pero es representativa, y permite al mdico tomar una decisin basada en el riesgo sobre el
controlador. Todos los controladores se prueban de forma equivalente y el examinador es neutral y objetivo. El
examinador registrar observaciones objetivas que permiten una evaluacin del riesgo que hacerse acerca de la
conduccin. En base a esto, un conductor que pasa se le dar una forma que le permita solicitar una licencia de
conducir. Un conductor que no va a obtener un informe con una lista de fallos y reas a mejorar antes de
volver a tomar la prueba.

As como la observacin de que el conductor efectivamente el volante, el examinador le har

preguntas o el controlador tomar un examen escrito para comprobar su bajo prestigio de las normas
de circulacin, seales de trfico, y qu hacer en diferentes situaciones de trfico.

1.2.2 Definicin de pruebas de software

Con esa analoga en mente, veamos la definicin de software ISTQB

Pruebas
Vamos a romper la definicin en partes; la definicin tiene algunas frases clave a tener en cuenta. La
definicin empieza con una descripcin de las pruebas como un proceso y, a continuacin se enumeran
algunos objetivos del proceso de prueba. En primer lugar, vamos a ver como un proceso de pruebas:

Proceso - La prueba es un proceso ms que una sola actividad - hay una serie de las actividades en
cuestin.

Todas las actividades del ciclo de vida - Captulo 2 se analizan las pruebas como un proceso que
se lleva colocar a lo largo del ciclo de vida del software de desarrollo.Vimos anteriormente que
cuanto ms tarde en el ciclo de la vida nos encontramos con errores, el ms caro que son de
arreglar. Si podemos encontrar y corregir los defectos de los requisitos en la fase de requisitos,
que deben tener sentido comercial. Vamos a construir el software adecuado, correctamente y en
un menor costo total. Por lo tanto, el proceso de pensamiento de las pruebas de ING de diseo al
principio del ciclo de vida puede ayudar a prevenir los defectos que se introduzcan en el cdigo.
A veces nos referimos a esto como "la verificacin de la prueba base a travs del diseo de la prueba
'.La base de pruebas incluye documentos tales como los requisitos y especificaciones de diseo.Vas a
ver cmo hacer esto en Captulo 4.

Tanto esttico como dinmico - Veremos en el captulo 3 que, adems de pruebas en las el cdigo
de software que se ejecuta para demostrar los resultados de la ejecucin de pruebas (a menudo
llamadas pruebas dinmicas) tambin podemos probar y encontrar defectos sin cdigo cuting exe.Esto
se llama prueba esttica. Esta prueba incluye la revisin de documentos (incluyendo el cdigo fuente)
y el anlisis esttico.Esta es una manera til y rentable de las pruebas.

Planificacin - Las actividades se llevan a cabo antes y despus de la ejecucin de la

prueba.Necesitamos que administrar la prueba; por ejemplo, tenemos la intencin de lo que queremos
hacer; controlamos las actividades de prueba; nos informe sobre el progreso y probar el estado del
software bajo prueba; y finalizamos o cerca de ensayos cuando se completa una fase.Captulo 5 se
refiere a estas actividades de gestin de prueba.

Preparacin - Tenemos que elegir lo que vamos a hacer la prueba, seleccionando con la prueba
condiciones y casos de prueba el diseo. Captulo 4 cubre las actividades de diseo de prueba.

Evaluacin - As como la ejecucin de las pruebas, debemos comprobar los resultados y evaluar el
software bajo prueba y los criterios de finalizacin, que nos ayudan a decidir si hemos terminado las
pruebas y si el producto de software ha superado las pruebas.

 Los productos de software y productos de trabajo relacionados - Nosotros no lo hacen solo cdigo de
prueba.probamos los requisitos y especificaciones de diseo, y nos ponen a prueba los documentos
relacionados, tales como el funcionamiento, el usuario y material de formacin.pruebas estticas y
dinmicas son igualmente necesarios para cubrir la gama de productos que necesitamos para poner a
prueba.

La segunda parte de la definicin cubre el algunos de los objetivos para las pruebas - las razones por las
que hacemos es:

Determinar que los productos de software () satisfacer los requisitos especificados - Algunas de
las pruebas que hacemos se centra en el control de los productos con las especificaciones para el
producto; por ejemplo, se revisa el diseo para ver si se ajusta a requerir mentos, y entonces
podramos ejecutar el cdigo para comprobar que cumple con el diseo.Si el producto cumple con su
especificacin, podemos proporcionar esa informacin para ayudar a los actores juzgan la calidad del
producto y decidir si est listo para su uso.

Demostrar que los productos de software () son aptos para el propsito - Esto es un poco diferente
con el punto anterior; despus de todos los requisitos especificados podra ser incorrecta o
incompleta.'Es adecuado al fin' analiza si el software hace lo suficiente para ayudar a los usuarios
llevar a cabo sus tareas; nos fijamos en si el soft ware hace lo que el usuario podra esperar
razonablemente. Por ejemplo, podemos fijarnos en los que poda comprar o utilizar el software y
comprobar que se hace lo que se espera; esto nos podra llevar a aadir un comentario de la
comercializacin compaero rial a nuestras pruebas estticas, para comprobar que las expectativas de
que el software se han establecido correctamente. Una manera de juzgar la calidad de un producto es
por su estado de forma es para su propsito.

Detectar defectos - Nos lo ms a menudo pensamos en las pruebas de software como un medio de
deteccin de fallos o defectos que, en uso operativo causarn fallas.Encontrar los defectos nos ayuda a
comprender los riesgos asociados con poner el software en uso operativo, y la fijacin de los defectos
mejora la calidad de los productos ductos. Sin embargo, la identificacin de defectos tiene otra
ventaja. Con el anlisis de causa raz, sino que tambin ayudan a mejorar los procesos de desarrollo y
cometer menos errores en el trabajo futuro.

Esta es una definicin adecuada de las pruebas para cualquier nivel de la prueba, la prueba de componente a travs de las pruebas de aceptacin, siempre que recordemos que tomar los distintos objetivos de
estos diferentes niveles de pruebas en cuenta. (En el captulo 2 explicaremos los diferentes niveles de la
prueba, sus objetivos, y cmo encajan en el ciclo de vida de desarrollo de software.)

claramente podemos ver ahora por qu la percepcin comn de pruebas (que slo consiste en las
pruebas de funcionamiento, es decir, ejecutar el software) no est completa. Esta es una de las actividades
de prueba, pero no todo el proceso de prueba.

prueba y prueba de conduccin 1.2.3 Software compar

Podemos ver que la prueba de software es muy parecido a una prueba de conduccin de muchas maneras,
aunque por supuesto no es una analoga perfecta! El examinador se convierte en el probador de software.
El conductor que se examina se convierte en el sistema o software bajo prueba, y ver a medida que
avanzamos a travs de este libro que tiene el mismo enfoque en trminos generales.

La planificacin y preparacin - Tanto el examinador y el probador necesitan un plan de la accin

y la necesidad de prepararse para la prueba, que no es exhaustiva, pero es repre sentante y permite
tomar decisiones basadas en el riesgo sobre el resultado.

Esttico y dinmico - Tanto dinmico (conducir el coche o la ejecucin de la suave Ware) y

esttico (preguntas al conductor o una revisin de las pruebas de software) son tiles.

Evaluacin - El examinador y el probador debe hacer un objetivo evaluacin,

registrar el resultado de la prueba y reportar observaciones objetivas sobre la prueba.

Determinar que cumplen los requisitos especificados - El examinador y probador

tanto verificacin segn las necesidades para llevar a cabo determinadas tareas con xito.

Demostrar que son aptos para el propsito - El examinador y la probador no son

la evaluacin de la perfeccin, sino para cumplir suficiente de los atributos requeridos

para pasar la prueba.

Detectar defectos - El examinador y el probador de tanto buscar y registro fallos.

Vamos a pensar un poco ms acerca de la planificacin. Debido a que el tiempo es limitado,

con el fin de realizar un recorrido representativo que proporcionara una suficientemente buena
prueba, ambos probadores de software y los examinadores deciden de antemano la ruta que
tomarn. No es posible llevar a cabo la prueba de conduccin y tomar decisiones acerca de
dnde pedir al conductor que vaya al lado en el calor del momento. Si el examinador hizo eso,
podran quedarse sin tiempo y tienen que volver al centro de prueba sin tener observadas todas
las maniobras necesarias. El conductor todava va a querer un pase / informe de fallo. De la
misma manera, si nos embarcamos en la prueba de un sistema de software sin un plan de accin,
estamos muy probable que se ejecute fuera de tiempo antes de que sepamos si hemos hecho las
pruebas suficientes. Vamos a ver que los buenos probadores siempre tienen un plan de accin. En
algunos casos, se utiliza un esquema de peso ligero que proporciona los objetivos y la direccin
general de la prueba, lo que permite a los probadores para variar la prueba durante la ejecucin.
En otros casos, se utiliza guiones detallados que muestran los pasos de la ruta de prueba y
documentar exactamente lo que el probador debe esperar que suceda ya que cada paso. Sea cual
sea el enfoque del probador de toma, habr un plan de accin. Del mismo modo, al igual que el
examinador hace un registro y reporte, un buen probador objetivamente documentar los defectos
encontrados y los resultados de la prueba.

Por lo tanto, existen actividades de prueba antes y despus de la ejecucin de la prueba, y nos
explican esas actividades en este libro. Como probador o el director de pruebas, usted estar
involucrado en la planificacin y control de la prueba, la eleccin de las condiciones de prueba,
el diseo de casos de prueba basados en esas condiciones de prueba, la ejecucin de ellos y
comprobar los resultados, evaluar si la prueba se ha hecho suficiente mediante el examen de
finalizacin (o salida) criterios, al informar sobre el proceso de prueba y el sistema bajo prueba,
y la presentacin de finalizacin de la prueba (o resumen) informa.

1.2.4 Cuando podemos cumplir con nuestros objetivos de la prueba?

Principio de pruebas - Las primeras pruebas

Las actividades de prueba debe comenzar tan pronto como sea posible en el ciclo de vida del software o sistema de desarrollo
y debe ser centrado en objetivos definidos.

Podemos utilizar tanto las pruebas dinmicas y pruebas estticas como medio para alcanzar los
objetivos de prueba similares. Ambos proporcionan informacin para mejorar tanto el sistema
a ensayar, y el desarrollo y los procesos de prueba. Ya hemos mencionado que las pruebas
pueden tener diferentes metas y objetivos, que a menudo incluyen:

encontrar defectos;

ganando la confianza y proporcionar informacin sobre el nivel

de calidad;

la prevencin de defectos.

Muchos tipos de revisin y pruebas actividades se llevan a cabo en diferentes etapas del ciclo de vida,
como veremos en el captulo 2. Estos tienen diferentes objetivos. Los primeros estudios de - tales como
actividades de diseo y revisin de la prueba temprana - encuentra defectos al principio, cuando son
baratos para encontrar y corregir. Una vez que el cdigo est escrito, los programadores y probadores a
menudo corren un conjunto de pruebas para que puedan identificar y corregir defectos en el software. En
este 'pruebas de desarrollo "(que incluye los componentes, inte-gracin y las pruebas del sistema), el
objetivo principal puede ser la de causar tantos a prueba de Ures como sea posible para que se identifican
defectos en el software y pueden ser fijos. Despus de que las pruebas, los usuarios del software pueden
llevar a cabo las pruebas de aceptacin para confirmar que el sistema funciona como se espera y para
ganar la confianza de que ha cumplido con los requisitos.

La fijacin de los defectos no siempre puede ser el objetivo de la prueba o el resultado deseado. A
veces simplemente queremos recabar informacin y medir el software. Esto puede tomar la forma de
medidas de atributos tales como el tiempo medio entre fallos para evaluar la confiabilidad, o una
evaluacin de la densidad de defectos en el software para evaluar y comprender el riesgo de soltarlo.

Cuando el mantenimiento del software mediante la mejora o corregir errores, estamos cambiando el
software que ya est siendo utilizado. En ese caso, un objetivo de la prueba puede ser para asegurarse de
que no hemos cometido errores y defectos introducidos cuando cambiamos el software. Esto se conoce
como pruebas de regresin - pruebas para asegurar que nada ha cambiado que no debera haber
cambiado.

Podemos continuar para probar el sistema una vez que est en uso operacional. En este caso, el
objetivo principal puede ser para evaluar las caractersticas del sistema tales como la fiabilidad o
disponibilidad.

Principio de pruebas - agrupacin de defectos

Un pequeo nmero de mdulos contiene la mayor parte de los defectos detectados durante las pruebas de prelanzamiento o mostrar las fallas ms operativas.

1.2.5 Centrndose en defectos puede ayudar a planificar nuestras pruebas

Un anlisis de defectos y fracasos con el fin de mejorar los procesos nos permite mejorar nuestras
pruebas y nuestros procesos de requisitos, diseo y desarrollo. Un fenmeno que han observado muchos
probadores es que los defectos tienden a agruparse. Esto puede suceder porque un rea del cdigo es
particularmente complejo y delicado, o porque el cambio de software y otros productos tiende a provocar
reaccin en cadena defectos. Probadores suelen usar esta informacin al hacer su evaluacin de los
riesgos para la planificacin de las pruebas, y se centrarn en conocidos "puntos calientes".

Un objetivo principal de opiniones y otras pruebas estticas es llevar a cabo las pruebas tan pronto como
sea posible, encontrar y corregir los defectos de forma ms barata y la prevencin de los defectos que
aparezcan en las etapas posteriores de este proyecto. Estas actividades ayudan a averiguar sobre los defectos
anteriormente e identificar posibles grupos. Adems, un resultado importante de todas las pruebas es
informacin que ayuda a evaluar el riesgo cin; estas opiniones contribuirn a la planificacin de las pruebas
ejecutadas ms tarde en el ciclo de vida del software de desarrollo. Tambin podemos llevar a cabo anlisis de
causa raz para prevenir los defectos y fallas que ocurren de nuevo y tal vez para identificar la causa de los
clusters y agrupaciones potenciales futuras.

1.2.6 Los grupos de defectos cambian con el tiempo

Principio de pruebas - paradoja de Pesticidas

Si las mismas pruebas se repiten una y otra vez, con el tiempo el mismo conjunto de casos de prueba ya no encuentra ninguna
nuevos errores. Para superar esta "paradoja del pesticida ', los casos de prueba deben ser examinados y revisados con
regularidad, y tienen que ser por escrito para ejercer diferentes partes del software o el sistema para encontrar ms defectos
potencialmente pruebas nuevas y diferentes.

Con el tiempo, a medida que mejoramos todo nuestro ciclo de vida de desarrollo de software y la prueba
esttica temprana, bien podemos encontrar que los niveles de los ensayos dinmicos que encuentran un
menor nmero de defectos. Una iniciativa tpica de mejora de ensayo inicialmente se encuentra ms
defectos como las pruebas de mejora y, a continuacin, como la prevencin de defectos entra en accin,
vemos la cada de los nmeros de defectos, como se muestra en la Figura 1.3. La primera parte de la
mejora nos permite reducir los fallos en el funcionamiento; ms tarde, los mejoren-mentos nos hacen ms
eficientes y eficaces en la produccin de software con un menor nmero de defectos en el mismo.

Como los "puntos calientes" para los insectos se limpiaron tenemos que mover nuestro enfoque otra
cosa, donde, a la siguiente serie de riesgos. Con el tiempo, nuestro enfoque puede cambiar de encontrar
errores de codificacin, al mirar a los requisitos y documentos de diseo de los defectos, y a la bsqueda
de mejoras en los procesos de manera que se previene defectos en el producto. Con referencia a la Figura
1.3, por la publicacin de 9 y 10, se esperara que el coste total y el esfuerzo asociado con reseas y
ensayos es mucho menor que en las versiones 4 o 7.

1.2.7 Depuracin elimina defectos

Cuando una prueba encuentra un defecto que debe ser fijo, un programador tiene que hacer algn trabajo para
localizar el defecto en el cdigo y hacer la correccin. En este proceso, llamado debug-ging, un programador
examinar el cdigo de la causa inmediata de la problema, repare el cdigo y comprobar que el cdigo se ejecuta
ahora como se esperaba.El arreglo est a menudo entonces prueba por separado (por ejemplo, mediante un probador
independiente) para confirmar la correccin. Tenga en cuenta que las pruebas y la depuracin son actividades
diferentes. Desarrolladores pueden probar sus propias correcciones, en cuyo caso el ciclo muy ajustado de la
identificacin de fallos,

depuracin y repeticin del examen es a menudo referido libremente como la depuracin.Sin embargo, a
menudo siguiendo el ciclo de depuracin del cdigo fijo se prueba de forma independiente tanto para
volver a probar la correccin de s mismo y de aplicar las pruebas de regresin para el software sin
cambios circundante.

1.2.8 Es el defecto del software libre?

Principio de pruebas - Las pruebas muestran presencia de defectos

Las pruebas pueden demostrar que los defectos estn presentes, pero no puede demostrar que no hay defectos. Testing reduce
la probabilidad de defectos sin descubrir que quedan en el software, pero, incluso si no se encuentran defectos, no es una
prueba de la correccin.

Este principio se deriva de la teora del proceso de experi-cin cientfica y ha sido adoptada por los
probadores; ver la idea en muchos libros de ensayo. Si bien no se espera para leer la teora cientfica [Popper]
la analoga utilizada en la ciencia es til; sin embargo muchos cisnes blancos que vemos, no podemos decir
que todos los cisnes son blancos. Sin embargo, tan pronto como vemos un cisne negro que podemos decir
"No todos los cisnes son blancos. De la misma manera, sin embargo, muchas pruebas de que ejecutamos sin
encontrar un error, que no han mostrado 'No hay errores'. Tan pronto como nos encontramos con un error,
hemos demostrado 'Este cdigo no est libre de errores'.

1.2.9 Si no encontramos defectos Eso significa que los usuarios acepten el

software?

Principio de pruebas - Ausencia de errores falacia

Encontrar y corregir defectos no ayuda si el sistema integrado se puede utilizar y no cumple con las necesidades y expectativas
de los usuarios.

Hay otro principio importante debemos tener en cuenta; los clientes de suave-ware - las personas y
organizaciones que compran y lo utilizan para ayudar en sus tareas del da a da - no estn interesados en
los defectos o nmero de defectos, excepto cuando se ven afectadas directamente por la inestabilidad del
software. Las personas que utilizan suave-mercancas estn ms interesados en el software de apoyo en la
realizacin de tareas con eficiencia y eficacia. El software debe satisfacer sus necesidades. Es por esta
razn que los requisitos y defectos de diseo que hemos discutido son tan importantes, y por qu las
revisiones e inspecciones (vase el Captulo 3) son una parte tan-funda mental de toda la actividad de
prueba.

1.3 PRINCIPIOS DE PRUEBA

1 Explicar los principios fundamentales en las pruebas. (k)

En las secciones 1.1 y 1.2, hemos introducido una serie de principios de ensayo y breves
explicaciones.Estos se enumeran en la Tabla 1.2, para que lo lea a recordar acerca de ellos. Estos
principios se han sugerido en los ltimos 40 aos y ofrecen directrices generales comunes para todas las
pruebas.

{0}Tabla 2.
{/0} {1} {/1}

PRINCIPIO

principios de prueba

muestra de prueba

Las pruebas pueden demostrar que los

defectos estn presentes,

presencia de defectos, pero no puede demostrar que no hay

defectos. Testing reduce la probabilidad

de

defectos sin descubrir que quedan en el

software, pero, incluso si no se detectan

deficiencias,

no es una prueba de la correccin.

PRINCIPIO

Las pruebas
exhaustivas

es imposible

Prueba de todo (todas las combinaciones

de

insumos y las condiciones previas) no es

viable

a excepcin de los casos triviales. En

lugar de

exhaustivas pruebas, utilizamos los

riesgos y

prioridades para centrar los esfuerzos de

prueba.

PRINCIPIO

Las primeras
pruebas

Las actividades de prueba debe

comenzar tan pronto como

posible en el software o sistema

el desarrollo del ciclo de vida y debe ser

centrado en objetivos definidos.

PRINCIPIO

agrupacin defecto

Un pequeo nmero de mdulos

contienen la mayor parte

de los defectos descubiertos durante la

pre

liberar las pruebas o mostrar la mayor

parte

fallas operacionales.

PRINCIPIO

Paradoja del
pesticida

Si las mismas pruebas se repiten una y

otra vez, con el tiempo el mismo

conjunto de prueba

casos ya no encuentra ninguna nuevos

errores. A

superar esta "paradoja del pesticida ', la

prueba

casos necesitan ser revisados con

regularidad y

revisadas y nuevas y diferentes pruebas

necesitan

para ser escrito para ejercer diferentes

partes del

el software o sistema para encontrar

potencialmente

ms defectos.

PRINCIPIO

La prueba es el
contexto

dependiente

La prueba se realiza de forma diferente en

diferentes

Contextos Por ejemplo, la seguridad

crticos

software se prueba de manera diferente

a partir de una

sitio de comercio electrnico.

PRINCIPIO

La ausencia de
errores,

falacia

Encontrar y corregir defectos no ayuda si

el sistema integrado se puede utilizar y

no lo hace

satisfacer las necesidades y

expectativas de los usuarios.

1.4 FUNDAMENTAL proceso de prueba

1 Recordemos las actividades fundamentales de la prueba desde la planificacin

para probar las actividades de cierre y las tareas principales de cada actividad de
prueba. {0}k = 0.015 L{/0}{1}1{/1}

10.1 INSTRODUCCION 107

En esta seccin, vamos a describir el proceso de la prueba fundamental y activi-dades. Estos comienzan
con la planificacin de controles y continan hasta el cierre a prueba. Para cada parte del proceso de
prueba, vamos a discutir las principales tareas de cada actividad de prueba.

En esta seccin, tambin se encontrar con las pruebas de confirmacin trminos del glosario,

criterios de salida, incidente, pruebas de regresin, base de pruebas, condiciones de ensayo,

cobertura de las pruebas, datos de prueba, ejecucin de pruebas, registro de la prueba, del
plan de prueba, la estrategia de ensayo, el informe resumen de la prueba y testware.

Como hemos visto, aunque la ejecucin de pruebas es importante, tambin es necesario un plan de
accin y un informe sobre el resultado de las pruebas. Proyectos y planes de prueba debe incluir el tiempo
que se gasta en la planificacin de las pruebas, el diseo de casos de prueba, la preparacin para la
ejecucin y la evaluacin del estado. La idea de un proceso de prueba fundamental para todos los niveles
de la prueba se ha desarrollado a lo largo de los aos. Sea cual sea el nivel de pruebas, vemos el mismo
tipo de actividades principales ocurriendo, aunque puede haber una cantidad diferente de formalidad en
los diferentes niveles, por ejemplo, pruebas de componentes pueden ser llevadas a cabo de manera menos
formal de las pruebas del sistema en la mayora de las organizaciones con un menor proceso de prueba
documentada. La decisin sobre el nivel de formalidad de los procesos depender del contexto del
sistema y el software y el nivel de riesgo asociado con el software. As podemos dividir las actividades en
el proceso de prueba fundamental en los siguientes pasos bsicos:

planificacin y control;

anlisis y diseo;

implementacin y ejecucin;

la evaluacin de los criterios de salida y presentacin de informes;

las actividades de cierre de prueba.

Estas actividades son lgicamente ordenado, pero en un proyecto en particular, pueden superponerse,
simultneamente e incluso repetirse. Este proceso es sbre todo utilizado para la prueba dinmica, pero las
principales partidas del proceso se puede aplicar a los exmenes tambin. Por ejemplo, tenemos que
planificar y prepararse para una revisin, llevar a cabo las revisiones, y evaluar los resultados de los
exmenes. Para algunas crticas, como las inspecciones, tendremos salida crite-ria y pasaremos por las
actividades de cierre. Sin embargo, el detalle y la denominacin de las actividades sern diferentes para
pruebas estticas. Discutiremos pruebas estticas en el Captulo 3.

1.4.2 planificacin y control de prueba

Durante la planificacin de pruebas, nos aseguramos de que entendemos las metas y objetivos de los clientes,
interesados y el proyecto, y los riesgos que la prueba est destinada a hacer frente.Esto nos dar lo que se
llama a veces la misin de la prueba o la asignacin de prueba. Sobre la base de este entendimiento, fijamos
las metas y objetivos para los propios ensayos, y derivamos una aproximacin y un plan para las pruebas,
incluyendo la especificacin de las actividades de prueba. Para ayudarnos a que pueden tener una organizacin
o programa de prueba de las polticas y una estrategia de prueba. poltica de prueba da normas para las
pruebas, por ejemplo, "que siempre revisar los documentos de diseo '; estrategia de prueba es el enfoque
general de alto nivel, por ejemplo, "las pruebas del sistema se lleva a cabo mediante una notificacin al
administrador de la calidad del programa equipo independiente. Ser basado en el riesgo y procede de un
anlisis de riesgo del producto (calidad) '(vase el captulo 5). Si la poltica y la estrategia estn ya definidos
que conducen nuestra planificacin, pero si no hay que preguntar por ellas, que se indicarn y definidos. la
planificacin de prueba tiene las siguientes tareas principales, dados aproxi madamente-fin, que nos ayudan a
construir un plan de pruebas:

Determinar el alcance y los riesgos e identificar los objetivos de la prueba: debera considerar con qu
software, componentes, sistemas u otros productos que estn en el alcance de las pruebas; el negocio,
producto, proyecto y los riesgos tcnicos que deben abordarse; y si estamos probando principalmente para
descubrir defectos, para demostrar que el software cumple con los requisitos, para demostrar que el sistema
es adecuado para el propsito o para medir las cualidades y atributos de software.

Establecer el mtodo de prueba (tcnicas, elementos de prueba, la cobertura, la identificacin y la

interfaz con los equipos que participan en la prueba, testware): consideramos cmo vamos a llevar a cabo
las pruebas, las tcnicas a utilizar, lo que necesita pruebas y cunto tiempo (es decir, en qu medida de la

cobertura).Vamos a ver quin necesita para involucrarse y cuando (esto podra incluir los desarrolladores,
los usuarios, los equipos de TI tura infraes); vamos a decidir lo que vamos a producir la mayor parte de las
pruebas (por ejemplo testware tales como los procedimientos y datos del ensayo). Esto estar relacionado
con los requisitos de la estrategia de prueba.

Aplicar la poltica de prueba y / o la estrategia de prueba: hemos mencionado que puede haber una
poltica de organizacin o programa y la estrategia para la prueba.Si este es el caso, durante nuestra
planificacin debemos asegurarnos de que lo que vamos a hacer adhiere a la poltica y la estrategia o
que debe haber acordado con las partes interesadas, y documentado, una buena razn para apartarse de
ella.

Determinar los recursos de prueba requeridas (por ejemplo, personas, entorno de prueba, PCs):
desde la planificacin ya lo hemos hecho, ahora podemos entrar en detalles; decidimos en nuestro
equipo de maquillaje y tambin creamos todo el hardware y software de apoyo que requerimos para el
entorno de prueba.

El anlisis calendario de pruebas y tareas de diseo, implementacin de prueba, ejecucin y

evaluacin: vamos a necesitar un horario de todas las tareas y actividades, de manera que podamos realizar
un seguimiento de ellos y asegurarnos de que podemos completar la prueba en el tiempo.

Determinar los criterios de salida: tenemos que establecer criterios tales como los criterios de cobertura (por
ejemplo, el porcentaje de declaraciones en el software que debe ser ejecutado durante la prueba) que le ayudarn a
realizar un seguimiento de si estamos completando las activi dades de prueba correctamente.Ellos nos mostrarn qu
tareas y controles hay que completar para un nivel particular de las pruebas antes de poder decir que la prueba ha
terminado.

La gestin de cualquier actividad no se detiene con la planificacin de la misma.Tenemos que controlar

y medir el progreso contra el plan. Por lo tanto, el control de la prueba es una actividad
continua.Necesitamos comparar el progreso real del progreso del planeado, e informar al director del
proyecto y del cliente sobre el estado actual de las pruebas, incluyendo cualquier cambio o desviacin del
plan. Vamos a tener que tomar medidas cuando sea necesario para cumplir con los objetivos del proyecto.
Tales acciones pueden traducirse en cambios en nuestro plan original, que sucede a menudo. Cuando
diferentes grupos realizan diferentes actividades de revisin y prueba dentro del proyecto, las necesidades
de planificacin y control que sucedan dentro de cada uno de esos grupos, pero tambin a travs de los
grupos de coordinacin entre ellos, lo que permite traspasos suaves entre cada etapa de la prueba.
Planificacin de las pruebas tiene en cuenta la retroalimentacin de las actividades de vigilancia y control
que se llevan a cabo durante todo el proyecto.control de prueba tiene las siguientes tareas principales:


Medir y analizar los resultados de los exmenes y pruebas: Necesitamos saber cuntos
comentarios y pruebas que hemos realizado.Tenemos que realizar un seguimiento de cuntas pruebas
han pasado y cuntos fallado, junto con el nmero, el tipo y la importancia de los defectos indicados.

Monitorear y documentar el progreso, la cobertura de prueba y criterios de salida: Es importante que se

informa al equipo del proyecto lo mucho que se realicen pruebas, cules son los resultados, y qu
conclusiones y evaluacin de riesgos que han hecho.Debemos hacer que el resultado de la prueba visible y
til para todo el equipo.

Proporcionar informacin sobre las pruebas: Debemos esperar a que presenten informes
peridicos y excepcionales al jefe de proyecto, direccin de obra, los clientes y otras partes
interesadas clave para ayudarles a tomar decisiones informadas sobre el estado del proyecto.Tambin
debemos utilizar la informacin que tenemos para analizar la prueba en s.

Iniciar acciones correctivas: Por ejemplo, apretar los criterios de salida para los defectos fijos,
pedir ms esfuerzo para ser puesto en la depuracin o priorizar defectos para la fijacin de los
bloqueadores de prueba.

Tomar decisiones: Sobre la base de las medidas y la informacin recogida durante las pruebas y
cualquier cambio en los riesgos de negocio y de proyecto o nuestra aumentado bajo el pie de riesgos
tcnicos y de productos, vamos a hacer decisiones o capacitar a otros para tomar decisiones: para
continuar con las pruebas, para detener la prueba , para liberar el software o para retenerlo para el
trabajo posterior, por ejemplo.

Anlisis y Diseo de la Prueba

anlisis y diseo de la prueba es la actividad en la que los objetivos generales de prueba son transformarse en condiciones de prueba tangibles y diseos de prueba. Durante el anlisis y diseo de la
prueba, tomamos objetivos de las pruebas generales identificados durante la planificacin y construir
diseos de prueba y los procedimientos de prueba (scripts). Vas a ver cmo hacer esto en el captulo 4.
anlisis y diseo de la prueba tiene las siguientes tareas principales, aproximadamente en el siguiente
orden:

 Revisar la base de pruebas (tales como el anlisis de riesgo del producto, requisitos, tecture archi,
especificaciones de diseo, e interfaces), el examen de las especificaciones para el software que estamos
probando.Usamos la base de pruebas para ayudarnos a construir nuestras pruebas. Podemos empezar a
disear ciertos tipos de pruebas (llamadas pruebas de recuadro negro)

antes de que exista el cdigo, ya que podemos utilizar los documentos bsicos de prueba para entender
lo que el sistema debe hacer una vez construido.A medida que estudiamos la base de pruebas, que a
menudo identificar las lagunas y ambigedades en las especificaciones, ya que estamos tratando de
identificar con precisin lo que sucede en cada punto en el sistema, y esto tambin defectos prerespiraderos que aparece en el cdigo.

Identificar las condiciones de prueba basados en el anlisis de los elementos de prueba, sus
especificaciones, y lo que sabemos acerca de su comportamiento y estructura.Esto nos da una lista de
alto nivel de lo que estamos interesados en la prueba. Si volvemos a nuestro ejemplo de la conduccin,
el examinador podra tener una lista de condiciones de prueba que incluye 'ior behav en los cruces ","
uso de indicadores "," capacidad de maniobra del coche y as sucesivamente. En las pruebas, usamos
las tcnicas de prueba para ayudarnos a definir las condi ciones de prueba. De esto podemos empezar
a identificar el tipo de datos de prueba genrica que pueda necesitar.

Disear las pruebas (ver cmo hacer esto en el captulo 4), el uso de tcnicas para ayudar a
seleccionar las pruebas representativas que se refieren a aspectos particulares del soft ware que llevan
riesgos o que son de particular inters, en base a las condiciones de prueba y va en ms detalles.Por
ejemplo, el examinador podra mirar a una lista de condiciones de prueba y decidir que las uniones
tienen que incluir uniones en T, cruce de caminos y as sucesivamente. En las pruebas, vamos a definir
el caso de prueba y procedimientos de prueba.

Evaluar la capacidad de prueba de los requisitos y del sistema.Los requisitos pueden ser escritos en
una forma que permita un probador para disear pruebas; por ejemplo, si el rendimiento por el
software es importante, que deber precisarse de una manera comprobable. Si los requisitos slo dicen
'el software tiene que responder lo suficientemente rpido "que no es comprobable, ya que" lo
suficientemente rpido "puede significar diferentes cosas para diferentes personas. Uno de los
requisitos ms comprobable sera 'el soft ware debe responder de 5 segundos con 20 personas se
conectaron'. El TestABil dad del sistema depende de aspectos tales como si es posible configurar el
sistema en un entorno que coincida con el entorno operativo y si todas las formas en que el sistema
puede ser configurado o utilizado puede ser comprendido y probado. Por ejemplo, si se prueba un sitio
web, puede que no sea posible iden tificar y volver a crear todas las configuraciones de hardware,
sistema operativo, navegador, conexin, cortafuegos y otros factores que el sitio web pueda encontrar.

Disear el entorno de configuracin de prueba e identificar cualquier infraestructura y las herramientas

necesarias.Esto incluye herramientas de prueba (vase el Captulo 6) y herramientas de apoyo, tales como
hojas de clculo, procesadores de texto, herramientas de planificacin de proyectos y herramientas que no
son de TI y equipos - todo lo que necesita para llevar a cabo nuestro trabajo.

1.4.4 Prueba de la aplicacin y ejecucin

Durante la implementacin y ejecucin de pruebas, tomamos las condiciones de prueba y los hacemos en casos de
prueba y testware y configurar el entorno de prueba.Esto significa que, despus de haber elaborado un diseo de
alto nivel para nuestras pruebas, que ahora empezamos a construirlas.Transformamos nuestras condiciones de
prueba en los casos de prueba y procedimientos, otra testware tales como secuencias de comandos para la
automatizacin.Tambin tenemos que configurar una ENVI-am- donde vamos a ejecutar las pruebas y construir
nuestros datos de prueba. La creacin de Environ-mentos y datos a menudo implica mucho tiempo y esfuerzo, por
lo que debe planear

y vigilar cuidadosamente este trabajo.Prueba de la aplicacin y ejecucin tienen las siguientes tareas
principales, aproximadamente en el siguiente orden:

Implementacin

- Desarrollar y dar prioridad a los casos de prueba, utilizando las tcnicas que usted ver en el
captulo 4, y crear datos de prueba para dichas pruebas.Tambin vamos a escribir las instrucciones
para la realizacin de las pruebas (procedimientos de prueba). Para que el examinador esto podra
significar cambiar 'las JunC' la condicin de prueba de "tomar la ruta hacia abajo Mayfield Road
hasta el cruce con el camino de verano y pedir al conductor a girar a la izquierda en la carretera de
verano y luego a la derecha en verde, camino, esperando que el conductor comprueba espejos,
seales y maniobras correctamente, sin dejar de ser conscientes de otros usuarios de la carretera '. Es
posible que tengamos para automatizar algunas pruebas utilizando arneses de prueba y scripts de
prueba automatizados. Ya hablaremos de automatizacin ms en el captulo 6.

- Crear conjuntos de pruebas de los casos de prueba para la ejecucin de la prueba eficiente.
Un conjunto de pruebas es una coleccin lgica de casos de prueba que, naturalmente, trabajan
juntos. conjuntos de pruebas a menudo comparten datos y un conjunto de alto nivel comn de
objetivos. Tambin vamos a establecer un calendario de ejecucin de la prueba.

- Implementar y verificar el medio ambiente.Nos aseguramos de que el medio ENVI prueba se ha

configurado correctamente, posiblemente, incluso la realizacin de pruebas especficas en l.

Ejecucin

Ejecutar los bancos de pruebas y casos de prueba individuales, siguiendo nuestros pro
cedimientos de prueba.Podramos hacerlo manualmente o mediante el uso de herramientas de
ejecucin de pruebas, ing acuerdo a la secuencia planificada.

- Ingrese el resultado de la ejecucin de pruebas y registrar las identidades y las versiones del
software bajo prueba, herramientas de prueba y testware.Hay que saber exactamente qu pruebas se
utiliz contra qu versin del software; debemos reportar defectos contra versiones especficas; y el
registro de la prueba mantenemos proporciona una pista de auditora.
- Comparar los resultados reales (lo que pas cuando nos encontramos con las pruebas) con los
resultados esperados (lo que anticipamos que ocurrira).

- Cuando existan diferencias entre los resultados reales y esperados, discrepancias informe como
incidentes. Analizamos ellos acceder a ms informacin sobre el defecto, la presentacin de
informacin adicional sobre el problema, identificar las causas de los defectos, y diferenciar entre
los problemas en el software y otros productos sometidos a prueba y cualquier defecto en los datos
de prueba, en los documentos de prueba, o errores en la forma en que exe recortado la prueba. Nos
gustara registrar este ltimo con el fin de mejorar la prueba en s.

Actividades de prueba de repeticin, como resultado de las medidas adoptadas para cada
discrepancia.Necesitamos pruebas que previamente haba fracasado con el fin de confirmar una
solucin (pruebas de confirmacin o re-prueba) volver a ejecutar.Ejecutamos pruebas
corregidas y suites si haba defectos en nuestras pruebas.Probamos el software corregido de nuevo
para asegurarse de que el defecto fue hecho correctamente fijada (prueba de confirmacin) y que los
programadores no introdujo defectos en reas no modificadas del software y que la fijacin de un
defecto no descubri otros defectos (regresin pruebas).

1.4.5 La evaluacin de los criterios de salida y presentacin de informes

La evaluacin de los criterios de salida es la actividad en la ejecucin de la prueba se evala con respecto a los
objetivos definidos. Esto debe hacerse para cada nivel de la prueba, como para cada uno que necesitamos saber
si hemos hecho las pruebas suficientes. Sobre la base de nuestro riesgo de evaluar-ment, tendremos criterios
establecidos contra el cual mediremos "suficiente". Estos Crite-ria varan para cada proyecto y se conocen
como criterios de salida. Ellos nos dicen si podemos declarar una actividad de prueba o nivel completo.
Podemos tener una mezcla de criterios COV-media o de terminacin (que nos dice acerca de los casos de
prueba que deben ser incluidos, por ejemplo, "el examen de manejo debe incluir una parada de emergencia" o
"la prueba de software debe incluir una medicin de la respuesta '), criterios de aceptacin (que nos dicen
cmo sabemos si el software se aprueba o no global, por ejemplo, "slo pasan al conductor si han completado

la parada de emergencia correctamente" o "slo pasan el software para su liberacin si se ajusta a la lista de
requisitos de prioridad 1 ') y criterios de salida de proceso (que nos dicen si hemos completado todas las tareas
que tenemos que hacer, por ejemplo, "el examinador / probador no ha terminado hasta que se han escrito y
presentada al final del informe de la prueba '). Criterios de salida se deben establecer y evaluar para cada nivel
de prueba. La evaluacin de los criterios de salida tiene las siguientes tareas principales:

Compruebe los registros de ensayo frente a los criterios de salida especificados en la planificacin
de controles: Buscamos para ver lo que evidencia que tenemos para los que las pruebas se han
ejecutado y verificado, y se han planteado qu defectos, fija, a prueba de confirmacin, o se
encuentran fuera de pie.

Evaluar si se necesitan ms pruebas o si se deben cambiar los criterios de salida se especifica: Es

posible que tenga que hacer ms pruebas si no hemos realizado todas las pruebas que hemos diseado,
o si nos damos cuenta de que no hemos llegado a la cobertura de lo que esperbamos, o si el han
aumentado los riesgos para el proyecto.Es posible que tenga que cambiar los criterios de salida para
bajarlos, si los riesgos de negocio y de proyecto se elevan en impor tancia y el producto o riesgos
tcnicos caen en importancia. Tenga en cuenta que esto no es fcil de hacer y debe ser acordado con
las partes interesadas. La prueba de manejar herramientas Ment y herramientas de cobertura de prueba
que vamos a discutir en el captulo 6 nos ayudan con esta evaluacin.

Escribir un informe resumen de la prueba para las partes interesadas: No es suficiente que los
probadores de conocer el resultado de la prueba. Todas las partes interesadas deben saber lo que se
realicen pruebas y el resultado de la prueba, con el fin de tomar decisiones informadas sobre el
software.

1.4.6

Las actividades de cierre de prueba

Durante las actividades de cierre de prueba, recogemos los datos de las actividades de prueba completados para
consolidar la experiencia, incluyendo cheques y testware presentacin, y los hechos y analizar los nmeros. Es
posible que tengamos que hacer esto cuando se entrega el software. Tambin podramos cerrar las pruebas por
otras razones, como cuando nos hemos reunido la infor-macin necesaria de la prueba, cuando el proyecto se
cancela, cuando se alcanza un hito en particular, o cuando se realiza una liberacin o actualizacin de
mantenimiento. las actividades de cierre de prueba incluyen las siguientes tareas principales:

Permite comprobar qu previsto entregables que efectivamente entregada y asegurar que todos los
informes de incidentes se han resuelto a travs de la reparacin de defectos o aplazamiento.Para los
diferidos, es decir, aquellos que permanecen abiertos, podemos solicitar

un cambio en una versin futura.Documentamos la aceptacin o el rechazo del sistema de software.

Finalizar y testware archivo, tales como scripts, el entorno de prueba, y cualquier otra
infraestructura de prueba, para su posterior reutilizacin.Es importante volver a utilizar todo lo que
podamos de testware; vamos a inevitable llevar a cabo las pruebas de mantenimiento, y se ahorra
tiempo y esfuerzo si nuestra testware se puede sacar de una biblioteca de pruebas existentes. Tambin
nos permite comparar los resultados de las pruebas entre las versiones de software.

Mano sobre testware a la organizacin de mantenimiento que apoyar el software y realizar

cualquier correccin de errores o cambios de mantenimiento, para su uso en pruebas de confirmacin
y con pruebas de regresin.Este grupo puede ser un grupo independiente para las personas que
construyen y ponen a prueba el software; los probadores de mantenimiento son uno de los clientes de
los probadores de desarrollo; van a utilizar la biblioteca de pruebas.

Evaluar cmo la prueba fue y analizar las lecciones aprendidas de las emisiones y los proyectos
futuros.Esto podra incluir mejoras en los procesos para el ciclo de vida de desarrollo de soft ware en su
conjunto y tambin la mejora de los procesos de prueba. Si usted refleja en la figura 1.3 una vez ms,
podemos utilizar los resultados de la prueba para establecer objetivos para mejorar crticas y pruebas con el
objetivo de reducir el nmero de defectos en el uso en vivo. Podemos fijarnos en el nmero de incidentes
que eran problemas de prueba, con el objetivo de mejorar la forma de disear, ejecutar y comprobar
nuestras pruebas o la gestin de los entornos de prueba y datos. Esto nos ayuda a tomar nuestras pruebas
ms madura y rentable para la organizacin. Esto est documentado en un informe resumen de la prueba o
podra ser parte de un informe general de evaluacin del proyecto.

1.5 LA PSICOLOGA DE PRUEBAS

Recordemos que el xito de la prueba se ve influenciada por factores psicolgicos: (KL)

objetivos claros;

un balance de la auto-prueba y las pruebas independientes;

el reconocimiento de la comunicacin corts y comentarios sobre defectos.

Contrasta la mentalidad de un probador y el de un desarrollador.(k)

En esta seccin, vamos a discutir los diversos factores psicolgicos que influyen en la prueba y su xito.
Estos incluyen objetivos claros para las pruebas, las funciones y el buen equilibrio de la auto-prueba y las
pruebas independientes, clara, corts com-municacin y retroalimentacin sobre los defectos. Tambin
vamos a contrastar la mentalidad de un probador y de un desarrollador.

Encontrar un solo trmino del programa de estudios en esta seccin, las pruebas independientes, y
el trmino del glosario, la independencia.

1.5.1 Las pruebas independientes - que es un probador?

La mentalidad que desea utilizar durante la prueba y revisin es diferente de la que usamos durante el anlisis o en
desarrollo. Con esto queremos decir que, si estamos acumulacin de ING algo que estamos trabajando
positivamente para resolver problemas en el diseo y para realizar un producto que cumpla con alguna necesidad.
Sin embargo, cuando nos prueba o revisa un producto, estamos buscando defectos en el producto y por lo tanto
somos crticos de la misma.

Supongamos que se va a cocinar una comida para entrar en una competicin para los cocineros. Se
selecciona el men, recoja los ingredientes, cocinar la comida, poner la mesa, y servir la comida. Si
quieres ganar, lo hace cada tarea, as como puedas. Supongamos que en vez usted es uno de los jueces
que evalan las comidas de competencia. Se examina crticamente todo, incluyendo el men, los
ingredientes, los mtodos utilizados, manteniendo a las asignaciones de tiempo y presupuesto, la eleccin
de los ingredientes, la ele-gance del ajuste de la tabla y de la porcin, y el aspecto y el sabor de la comida.
Para diferenciar entre los chefs de competencia, se le alabas todo buen aspecto de sus actuaciones sino
que tambin tenga en cuenta todos los fallos y errores Todos chef hizo. Lo mismo sucede con las pruebas
de software: la construccin del software requiere una mentalidad diferente de las pruebas del software.

No queremos decir que un aparato no puede ser un programador, o que un programa-mer no puede ser un
probador, aunque a menudo son funciones separadas. De hecho, los programas-dores son probadores - que ponen a
prueba los componentes que se construyen, y la integracin de los componentes en el sistema.El buen chef ser tan
crtico como los jueces de la competicin de su propia obra, con el fin de prevenir y corregir los errores y defectos
antes de que nadie se fija en ellos. As, con el derecho de pensar, de programas-dores pueden probar su propio
cdigo; de hecho, los programadores ponen a prueba su propio cdigo y encuentran muchos problemas, resolverlos
antes de que nadie ms ve el cdigo. El anlisis de negocios y personal de marketing deben revisar sus propios
requisitos. arquitectos de sistemas deben revisar sus propios diseos. Sin embargo, todos sabemos que es difcil
encontrar nuestros propios errores. Por lo tanto, los analistas de negocios, personal de marketing, arquitectos y
programadores a menudo dependen de otros para ayudar a probar su trabajo. Esta otra persona puede ser un analista
compaero, diseador o desarrollador. Una persona que va a utilizar el soft-ware puede ayudar a probar la misma.
Los analistas de negocio que trabajaron en los requisitos y el diseo pueden realizar algunas pruebas. especialistas
en ensayos - probadores profesionales - a menudo estn involucrados. De hecho, los exmenes pueden implicar una
sucesin de personas que llevan a cabo cada uno un nivel diferente de la prueba. Esto permite que una prueba
independiente del sistema.

Pronto nos ocuparemos de los puntos del ciclo de vida de desarrollo de software donde las pruebas se lleva
a cabo en el Captulo 2. Usted ver que hay que varias etapas de revisin y las pruebas se llevan a cabo durante
todo el ciclo de vida y estos pueden ser revisiones independientes y pruebas. Temprano en el ciclo de vida, los
comentarios de los requisitos y documentos de diseo por alguien que no sea el autor ayuda a encontrar
defectos antes de que comience la codificacin y ayuda a construir el software adecuado. Despus de la
codificacin, el software puede ser probada de forma independiente. Este grado de independencia evita el
sesgo autor y es a menudo ms eficaz en la bsqueda de defectos y fallas.

Varios niveles de independencia pueden ser identificados, mencionadas anteriormente, desde el nivel
ms bajo de la independencia de la ms alta:

pruebas por parte de la persona que escribi el artculo bajo prueba;

las pruebas realizadas por otra persona segn el mismo equipo, como otro programador;

las pruebas realizadas por una persona de un grupo organizativo diferente, como por ejemplo un
equipo de pruebas ent inde;

pruebas diseadas por una persona de una organizacin diferente o compaa, como las pruebas
externalizado o certificacin por un organismo externo.

Debemos tener en cuenta, sin embargo, que la independencia no es necesariamente el factor ms importante
para una buena prueba. Los desarrolladores que saben cmo poner a prueba y que son, como buenos
cocineros, autocrticas, tienen la ventaja de la familiaridad y el orgullo sin trabajo que viene con verdadero
profesionalismo. Tales promotores pueden encontrar de manera eficiente muchos defectos en su propio
cdigo. Algunos methodolo-gas de desarrollo de software a los desarrolladores insisten en el diseo de
pruebas antes de empezar a programar y ejecutar estas pruebas de forma continua a medida que cambian el
cdigo. Este enfoque promueve las primeras pruebas y la deteccin temprana de defectos, lo que es rentable.
Recuerde, las pruebas indepen-ent puede llevarse a cabo en cualquier nivel de la prueba y la eleccin del nivel
inde-cia depende del riesgo en el contexto particular.

1.5.2 Por qu a veces no seguir adelante con el resto del equipo?

As como la independencia, la separacin de la funcin probador de la funcin promotora tambin se

hace para ayudar a los esfuerzos de enfoque y para proporcionar los beneficios de los recursos de prueba
capacitados y profesionales. En muchas organizaciones, las primeras etapas de las pruebas se llevan a
cabo por los desarrolladores e integradores y las etapas posteriores de forma independiente, ya sea por un
grupo de prueba especialista o por los clientes. Sin embargo, esta separacin puede conducir a problemas,
as como ventajas. La ventaja de la independencia y el enfoque se puede perder si las inter-relacionesnaves del equipo se deterioran, como veremos.

Cada organizacin y cada proyecto tendr sus propias metas y objetivos. Las diferentes partes interesadas,
tales como los clientes, el equipo de desarrollo y los gerentes de la organizacin, tendrn diferentes puntos de
vista acerca de la calidad y tienen sus propios objetivos. Debido a que las personas y los proyectos son
impulsados por objetivos, la parte interesada con las vistas ms fuertes o la mayor influencia sobre un grupo
definir, consciente o inconscientemente, lo que esos objetivos son. La gente tiende a alinear sus planes con
estos objetivos. Por ejemplo, dependiendo del objetivo, un probador podra centrarse ya sea en la bsqueda de
defectos o en confirmar que funciona el software. Pero si uno de los interesados es menos influyente durante el
proyecto, pero ms influyente en el parto, puede haber un choque de opiniones acerca de si la prueba ha
cumplido sus objetivos. Un gerente puede desear la confirmacin de que el software funciona y que es
"suficientemente buena" si esto es visto como una manera de entregar lo ms rpido posible. Otro gerente
puede querer la prueba para encontrar tantos defectos como sea posible antes de que se libere el software, que
tendr ms tiempo para hacer y requieren tiempo para la fijacin, repeticin de pruebas y pruebas de regresin.
Si no hay objetivos claramente establecidos y los criterios de salida para las pruebas de la cual todas las partes
interesadas han acordado, argumentos podran surgir, durante la prueba o despus de la liberacin, acerca de si
la prueba "suficiente" se ha hecho.

Muchos de nosotros nos resulta un reto para realmente disfrutar de la crtica de nuestro trabajo. Por lo general,
creemos que hemos hecho todo lo posible para producir trabajo (documentos, cdigo, pruebas, lo que sea) que es
correcta y completa. As que cuando alguien identifica un defecto, un error que hemos hecho, podramos tomar
como algo personal y obtener molesto con la otra persona, sobre todo si estamos bajo la presin del tiempo. Este es
el caso de directivos, el personal, los probadores y desarrolladores. Todos cometemos errores y algunas veces nos
molesta, molesta o deprimida cuando alguien les seala. As que,

cuando como probadores se corre una prueba que (desde nuestro punto de vista) es una buena prueba que
encuentra defectos y fallos en el software, tenemos que tener cuidado en cmo reaccionamos.Estamos muy
contentos, por supuesto, ya que hemos encontrado un insecto bueno! Pero la manera en que el analista
requerir-mentos, diseador, desarrollador, director del proyecto y el cliente reaccionar? Las personas que
construyen productos pueden reaccionar a la defensiva y perciben este defecto informaron como una crtica
personal contra el producto y contra el autor. El director del proyecto puede ser molesto con todo el mundo
para sostener el proyecto. El cliente puede perder la confianza en el producto porque puede ver los defectos.
Dado que las pruebas puede ser visto como una actividad destructiva, hay que tener cuidado para informar
sobre los defectos y fallos del modo ms objetivo y cortsmente como sea posible. Si hay otras personas para
ver nuestro trabajo como constructiva en la gestin de riesgos de los productos, tenemos que tener cuidado
cuando estamos revisando y cuando estamos probando:

Comunicar los resultados sobre el producto de una manera neutral, hecho-centrado sin criticar a la
persona que lo cre.Por ejemplo, escribir informes de incidentes objetivas y fcticas y resultados de la
revisin.

No regodearse - usted no es perfecto, ya sea!

No culpe - los errores son, probablemente, por el grupo en lugar de un individuo.

S crtica constructiva y discutir el defecto y cmo se va a registrarlo.

Explicamos que al saber de esto ahora podemos trabajar alrededor de l o fijarlo por lo que el
sistema entregado es mejor para el cliente.
-

Di lo que te gust y lo que funcion, as como lo que no funcion.

Mostrar lo que el riesgo es sinceramente - no todo es de alta prioridad.

No se limite a ver el lado pesimista - alabar, as como la crtica.

Mostrar lo que los riesgos se han descubierto y los beneficios de la revisin o prueba.

Comience con la colaboracin en lugar de batallas.Recordar a todos el objetivo comn de los

sistemas de mejor calidad.

Sea educado y servicial, colaborar con sus colegas.

Tratan de entender cmo la otra persona se siente y por qu reaccionan como lo hacen.

Confirmar que la otra persona ha entendido lo que ha dicho, y viceversa.

De explicarle lo que ayuda u opinin del autor - lo que est en l para l o ella.

Ofrecer el trabajo para ser revisado, tambin.

Es nuestro trabajo como revisores y probadores para proporcionar a todos con informacin clara, objetiva y
para ello vamos bug-caza, defecto de la minera y la falta de decisiones. Las personas que van a hacer buenos
los colaboradores y los probadores tienen el deseo y la capacidad de encontrar problemas, y esto es cierto si la
prueba es su trabajo principal o parte de su papel como desarrollador. Estas personas acumulan la experiencia
de los que los errores son susceptibles de ser cometidos, y se caracterizan por su curiosidad, profesional pessimism, ojo crtico y atencin al detalle. Sin embargo, a menos que tambin tenemos buenas habilidades
interpersonales y de comunicacin, la cortesa, la comprensin de los dems y una buena actitud hacia nuestros
compaeros, colegas, clientes, directivos y el resto del equipo, vamos a fracasar como probadores porque nadie
nos escuchar .

El lder del probador y la prueba necesitan buenas habilidades interpersonales para comunicar informacin
objetiva acerca de los defectos, el progreso y los riesgos de una manera constructiva [Perry].Para el autor del
programa o documento, informacin de defectos puede ayudar a mejorar sus habilidades, pero slo si sta se
realiza de una manera que les ayuda. Un libro que le puede resultar interesante en este contexto es Seis
sombreros para pensar [de Bono].No se trata de la prueba sino que describe una manera de comunicar
informacin diferente: hechos; nuestras emociones; pensamientos pesimistas y optimistas; e ideas cre-ativa. Al
revisar o probar, tenemos que comunicar hechos obje-tivamente, pero los otros tipos de informacin son tiles
tambin: "Esto sucedi; esto es lo que senta por ella; esto es lo que era bueno; esto es lo que podra salir mal;
aqu es una forma de poder resolver el problema ". Como parte del suministro de la evaluacin del riesgo,
podemos ayudar a los gerentes y los clientes a tomar decisiones basadas en el riesgo basado en el impacto del
coste y el tiempo de un defecto. Si probamos y encontramos un defecto que costara $ a 15 000 para fijar y
prueba de repeticin de la prueba / de regresin, es que vale la fijacin? Si se causara un impacto en el
negocio de 50 $ 000 en el entorno directo del cliente puede desear lo arreglen. Si se tiene un potencial impacto
en el negocio de 10 $ 000 pero cualquier correccin es difcil de hacer y que pueden tener efectos negativos en
otros lugares, puede ser mejor no fijar. Por pro-Viding el equipo con la informacin sobre el defecto en
trminos que encuentran til, podemos ayudarles a tomar la decisin correcta acerca de la fijacin o no fijar el
prob-blemas. Generalmente se dice que los defectos encontrados y se fijaron durante la prueba se ahorrar
tiempo y dinero en el futuro y reducir los riesgos, por lo que necesitamos para demostrar que es el caso para
que la prueba sea valorado.

Para ayudarle a pensar acerca de la psicologa de las pruebas, no es un ejercicio al final del captulo,
despus de las preguntas del examen la prctica.

Repaso Captulo

Vamos a repasar lo que ha aprendido en este captulo.

De la Seccin 1.1, ahora debera ser capaz de explicar por qu es necesario realizar ensayos y apoyar esa
explicacin con ejemplos y pruebas. Usted debe ser capaz de dar ejemplos de las consecuencias negativas de un
defecto o error de software para las personas, las empresas y el medio ambiente. Usted debe ser capaz de contrastar
un defecto con sus sntomas. Usted debe ser capaz de discutir las formas en que las pruebas encaja en y es
compatible con una mayor calidad. Usted debe conocer los trminos del glosario

error, defecto, error, el fracaso, culpa, error, la calidad, el riesgo, el software, los ensayos y
pruebas exhaustivas.

De la Seccin 1.2, usted debe ahora sabe lo que es la prueba. Usted debe ser capaz de recordar los objetivos
comunes de la prueba. Usted debe ser capaz de describir cmo las pruebas puede encontrar defectos, dar
confianza y la informacin y evitar posibles daos. Usted debe ser capaz de explicar los principios bsicos de
la comprobacin, que se resumen en la Seccin 1.3. Usted debe saber el cdigo trminos del glosario, debug-

ging, desarrollo de software, requisitos, revisin, base de pruebas, casos de prueba, ensayo
y objetivo de la prueba.

De la Seccin 1.4, usted debe reconocer ahora el proceso de prueba fundamental, adems de ser consciente de
algunas otras formas relacionadas para modelar el proceso de prueba. Usted debe ser capaz de recordar las
principales actividades de pruebas relacionadas con la planificacin de las pruebas y el control, el anlisis y el
diseo, implementacin y ejecucin, la evaluacin de la salida cri-terios y presentacin de informes, y el cierre de
prueba. Usted debe conocer los trminos del glosario con-

pruebas de confirmacin, los criterios de salida, incidentes, pruebas de regresin, base de

pruebas, condiciones de ensayo, cobertura de las pruebas, datos de prueba, ejecucin de

pruebas, registro de la prueba, del plan de prueba, la estrategia de ensayo, el informe

resumen de la prueba y testware.

Por ltimo, desde la Seccin 1.5, ahora debera ser capaz de explicar la psicologa de la prueba y cmo las
personas influyen en el xito la prueba. Usted debe recordar la importancia de objetivos claros, la combinacin
adecuada de autodiagnstico y las pruebas independientes y corts, respetuosa comunicacin entre los
probadores y otros miembros del equipo del proyecto, especialmente sobre los defectos. Usted debe ser capaz
de explicar y contrastar la mentalidad de los probadores y programadores y por qu estas diferencias pueden
provocar conflictos. Usted debe saber la independencia trmino del glosario.

PREGUNTAS examen de la muestra

Pregunta 1 Una empresa ha adquirido recientemente una aplicacin off-the-shelf para automatizar su proceso
de pago de facturas. Ahora planean para ejecutar una prueba de aceptacin en contra del paquete antes de
ponerlo en produccin. Cul de las siguientes es la razn ms probable para la prueba?

a.

Para fomentar la confianza en la aplicacin.

b.

Para detectar errores en la aplicacin.

c.

Para reunir pruebas para una demanda.

d.

Para capacitar a los usuarios.

Pregunta 2 Segn el Glosario ISTQB, la palabra 'bug' es sinnimo de cul de las siguientes palabras?

a.

Incidente

b.

El defecto

c.

Equivocacin?

d.

Rrror

Pregunta 3 Segn el Glosario ISTQB, el riesgo se refiere a cul de las siguientes?

a.

La retroalimentacin negativa al probador.

b.

Las consecuencias negativas que se producirn.

c.

Las consecuencias negativas que podran ocurrir.

d.

consecuencias negativas para el objeto de prueba.

Pregunta 4 Asegurar que el diseo de prueba se inicia durante la fase de definicin de requerimientos es
impor-tante para permitir a cul de las siguientes prueba obje-tantes?

a.

La prevencin de defectos en el sistema.

b.

Encontrar defectos a travs de pruebas dinmicas.

c.

Obtener la confianza en el sistema.

d.

Terminar el proyecto a tiempo.

Pregunta 5 Un equipo de prueba encuentra constantemente entre el 90% y el 95% de los defectos presentes en
el sistema bajo prueba. Mientras que el director de pruebas entiende que este es un buen porcentaje de
defectos de deteccin para su equipo de pruebas y la industria, la alta direccin y ejecutivos quedar frustrados
en el grupo de prueba, diciendo que el equipo de pruebas se pierde demasiados errores. Dado que los usuarios
son generalmente

contento con el sistema y que los fallos que se han producido han sido generalmente bajo impacto, cul de
los siguientes principios Las pruebas son ms propensos a ayudar al director de pruebas explicar a estos
gerentes y ejecutivos por qu algunos defectos son susceptibles de ser pasado por alto?

a.

Las pruebas exhaustivas no es posible

b.

agrupacin defecto

c.

Paradoja del pesticida

d.

La ausencia de errores-falacia

Pregunta 6 Segn el Glosario ISTQB, es necesario realizar pruebas de regresin con qu propsito?

a.

Para verificar el xito de las acciones correctivas.

b. Para evitar una tarea de ser conside incorrectamente completado Ered.

c.

Para asegurarse de que los defectos no se han introducido mediante una modificacin.

d. Para motivar mejor prueba de la unidad por los meros programas.

Pregunta 7 Cul de los siguientes es ms importante promover y mantener buenas relaciones con barcos
entre los probadores y desarrolladores?

a. La comprensin de qu valor gerentes acerca de las pruebas.

b.

Al explicar los resultados de pruebas de forma neutra.

c.

La identificacin de potenciales clientes soluciones temporales para los insectos.

d. La promocin de software de mejor calidad siempre que sea posible.

Pregunta 8 Cul de las siguientes afirmaciones es la mejor evaluacin de cmo se aplican los principios
de prueba en todo el ciclo de vida de la prueba?

a. principios de prueba slo afectan a la preparacin para la prueba.

b. principios de prueba slo afectan a activi dades de ejecucin de pruebas.

c. principios de prueba afectan a las actividades de prueba de principios tales como la revisin.
d. principios de prueba afectan las actividades a lo largo del ciclo de vida de prueba.

EJERCICIO: PRUEBA DE PSICOLOGA

Leer el correo electrnico a continuacin, y ver lo que encuentre pistas para ayudarle a identificar
problemas en el escenario descrito. Categorizar las pistas / problemas como:

posibles problemas de la gente, la psicologa y la actitud;

otros problemas, por ejemplo, problemas posibles de gestin de pruebas y de roles, posibles
problemas del producto.

Hola!
Bueno, casi me caus pnico hoy porque pens que haba encontrado un
sensacional Mega en el sistema de comercio que estamos probando. El director de
pruebas y otros se involucraron examinar las bases de datos por primera vez en el
servidor y luego en la puerta de entrada que alimenta a los clientes, comprobando
los registros de actualizacin de procesos que funcionaron durante la noche, as
como la comprobacin de los datos pasados al cliente. Finalmente encontr el
problema. Tena mis-clic en un archivo .bat cuando se ejecuta un cliente y se haban
quedado hasta el entorno de cliente errneo. Para entonces, el director de pruebas
estaba listo para decir unas pocas palabras en mi odo, especialmente en lo que a la
gente de desarrollo haban comenzado a involucrarse y tienen cero tolerancia por los
errores cometidos por los probadores. El nico que salvaba era que he encontrado el
error y no uno de los desarrolladores.

Era, objetivamente, un error interesante. Al iniciar sesin en los entornos de

prueba del servidor, los paneles muestran siempre el medio ambiente al que
est conectado. En nuestro caso tenemos dos entornos de prueba llamados
Systest14 y Systest15 y mis pruebas se establecieron en Systest15. Para
ejecutar los clientes, tenemos que ejecutar archivos .bat, ya sea para un cliente
de 14 o 15. Yo haba comenzado dos clientes, es decir, dos participantes en el
intercambio, por lo que poda hacer algo de comercio entre ellos.

Parece que empec el primer cliente en Aceptar en el medio ambiente 15, pero
cuando empec el segundo, accidentalmente movido el ratn una fraccin por lo que
corri el archivo .bat 14 que est junto a l en la lista de archivos del Explorador. Para
empeorar las cosas, las pantallas de los clientes no muestran el entorno al que est
conectado.

Al principio me sent un poco estpido haber causado mucha actividad agitada y

desperdiciado. En la reflexin pens que si yo, como persona razonablemente

competente, puede cometer un error como ste entonces algo est mal. En el lado
del servidor cuando inicia sesin en un entorno de prueba, tengo que introducir el
nombre del entorno y se ha demostrado en todos los paneles. En el lado del cliente,
me ejecutar un entorno de prueba de cliente mediante la seleccin de un archivo
.bat de una lista de muchos y tienen que asegurarse de que haga clic en el archivo
correcto. No hay ni una exhibicin ni la capacidad de determinar el entorno de
cliente en el que estoy trabajando.

As que voy a registrar esto como una alta prioridad, o incluso SHOWSTOPPER,
el error - el cliente no se presenta el medio ambiente. En trminos reales, esto
significa que un usuario real podra estar conectado al sistema de produccin y
creo que est conectado a un sistema de prueba y el tornillo hasta el comercio. S
que esto ocurri una vez en el sistema de negociacin de acciones, cuando un
operador introduce una carga de transacciones de prueba en el sistema de
produccin por error y le provoca un infarto.

Como una adicin a esta historia, un par de das ms tarde uno de los probadores
encontr lo que pareca ser otro sensacional Mega. l y el director de pruebas pas tres
horas merodeando por todo el sistema antes de descubrir el "error". Un nuevo filtro se
haba aadido al software de cliente para filtrar las transacciones que se muestran en los
paneles por mercado geogrfico. Desconocido para ellos, que se estableci en un valor
predeterminado del mercado alemn, mientras que pensaban que estaban en el
mercado del Reino Unido. En consecuencia, a primera vista, pareca que haba
problemas fundamentales con la red de autobuses de transacciones y los sistemas de
mensajes de radiodifusin. Aparte de la cuestin que deberan haber sido informados de
este cambio, se plante un problema similar al que haba experimentado -el sistema
cliente no muestra el mercado en el que est operando.

Bueno - Me voy para otro da feliz en la oficina! Le deseo todo lo mejor,

SOLUCIN DE EJERCICIO

La gente, los problemas de la psicologa y la actitud incluyen, por ejemplo:

Las malas relaciones entre el equipo de prueba y el director de pruebas, y los probadores y
desarrolladores, por ejemplo 'Para entonces, el director de pruebas estaba listo para decir unas pocas
palabras en mi odo, especialmente en lo que a la gente de desarrollo haban comenzado a

involucrarse y tienen cero tolerancia por los errores cometidos por los probadores. El nico que
salvaba era que he encontrado el error y no uno de los desarrolladores ".

El uso del lenguaje emotivo - comprensible en las circunstancias pero no es adecuado para los
problemas de informacin, por ejemplo 'Bueno, casi me caus pnico hoy porque pens que haba
encontrado un sensacional Mega en el sistema de comercio que estamos probando, 'y' Como una
adicin a esta historia, un par de das ms tarde uno de los probadores encontraron lo que pareca ser
otro mega-sensacional '.

Desconfianza inicial superar mediante un reexamen del problema - si una persona puede cometer este error
entonces otros."Al principio me sent un poco estpido haber causado mucha actividad agitada y desperdiciado.
En la reflexin pens que si yo, como persona razonablemente competente, puede cometer un error como ste
entonces algo est mal '.

Comprensible uso de sarcasmo ...'Bueno - Me voy para otro da feliz en la oficina! "

Otros problemas incluyen la gestin de pruebas y problemas de conducta, por ejemplo:

Gestin de la configuracin y el control de la liberacin - Un nuevo filtro se haban aadido al

software de cliente para filtrar las transacciones que se muestran en los paneles por mercado
geogrfico .

Gestin de la configuracin, las relaciones, las comunicaciones - Aparte de la cuestin que

deberan haber sido informados de este cambio .... '

El director de pruebas comprenda muy bien su papel?"l y el director de pruebas pas tres
horas merodeando por todo el sistema antes de descubrir el" error "," y "El director de pruebas y otros
se involucr el examen de las bases de datos. '

Hay algunos problemas de productos, aunque no hay problemas de funcionalidad o tcnicos. No todos los
problemas que nos encontramos como probadores estn funcionalidad o problemas tcnicos. Hay algunos
problemas que no son funcionales
- En concreto, la usabilidad - que indican que un usuario real podra ser molestados o peor por este
problema:

"Tena mis-clic en un archivo .bat ... '

"En trminos reales, esto significa que un usuario real podra estar conectado al sistema de
produccin y creo que est conectado a un sistema de prueba y el tornillo hasta el comercio.S que
esto sucedi una vez ... cuando un operador introduce una carga de transacciones de prueba en el
sistema de produccin por error y le provoca un infarto '.

"Se plante un problema similar al que haba experimentado - el sistema cliente no muestra el
mercado en el que est operando.

"No hay ni una exhibicin ni la capacidad de determinar el entorno de cliente en el que estoy trabajando."Y
'Para empeorar las cosas, las pantallas de los clientes no muestran el entorno al que est conectado.

"Desconocido para ellos, que se estableci en un valor predeterminado del mercado alemn,
mientras que pensaban que estaban en el mercado del Reino Unido."

Tenga en cuenta que vamos a volver a este ejercicio al final del captulo 5, donde nos ocupamos de
escribir un buen informe de incidente.

Captulo 4

Prueba de todo el ciclo de vida del

software

sante no es una actividad independiente, solos.Tiene su lugar dentro de un ciclo de vida de desarrollo de
software modelo y por lo tanto el ciclo de vida aplicado determinar en gran medida cmo se organiza la
prueba.

Hay muchas formas diferentes de pruebas. Debido a varias disciplinas, a menudo con diferentes intereses,
estn involucrados en el ciclo de vida de desarrollo, es importante entender claramente y definir los
distintos niveles y tipos de prueba. Este captulo trata de los modelos de desarrollo de software ms
comnmente aplicadas, los niveles de prueba y tipos de prueba. El mantenimiento puede ser visto como
una instancia especfica de un proceso de desarrollo. El mantenimiento de manera influye en el proceso
de la prueba, los niveles y tipos de pruebas y cmo se puede organizar que se describe en la ltima
seccin de este captulo.

2.1 MODELOS DE DESARROLLO DE SOFTWARE

1 Comprender la relacin entre el desarrollo, actividades de prueba y

productos de trabajo en el ciclo de vida de desarrollo y dar ejemplos en
base a las caractersticas del producto y del proyecto y el contexto.(k)
2 Reconocer el hecho de que los modelos de desarrollo de software deben
adaptarse al contexto de las caractersticas del proyecto y del producto.
{0}k = 0.015 L{/0}{1}1{/1}
3
Recordemos razones para diferentes niveles de prueba y las
caractersticas de una buena prueba en cualquier modelo de ciclo de vida.
{0}k = 0.015 L{/0}{1}1{/1}

El proceso de desarrollo adoptado por un proyecto depender de los objetivos y metas del proyecto. Hay
numerosos ciclos de vida de desarrollo que se han desarrollado con el fin de lograr diferentes objetivos
requeridos. Estos ciclos de vida van desde metodologas ligero y rpido, donde el tiempo de
comercializacin es de la esencia, a travs de metodologas totalmente controlados y documentados en
los que la calidad y la fiabilidad son factores clave. Cada uno de estos mtodos tiene su lugar en el
desarrollo de software moderno y el proceso de desarrollo ms adecuado se debe aplicar a cada proyecto.
Los modelos especifican las diversas etapas del proceso y el orden en el que se llevan a cabo.

El modelo de ciclo de vida que se adopte para un proyecto tendr un gran impacto en la prueba que
se lleva a cabo. Las pruebas no existe en forma aislada; actividades de prueba

estn muy relacionadas con las actividades de desarrollo de software.Se definir el qu, dnde, y cundo
de nuestra prueba planificada, las pruebas de la influencia de regresin, y en gran medida determinar qu
tcnicas de ensayo para su uso. La prueba est organizada manera debe ajustarse al ciclo de vida de
desarrollo o no ser capaz de entregar su beneficio. Si el tiempo de comercializacin es el factor clave, a
continuacin, la prueba debe ser rpido y eficiente. Si un ciclo de vida del software de desarrollo
completamente documentado, con una pista de auditora de las pruebas, es necesario, la prueba debe estar
plenamente documentado.

En cada ciclo de vida de desarrollo, una parte de esos anlisis se centr en las pruebas de verificacin y
una parte se centra en las pruebas de validacin.La verificacin se refiere a la evaluacin de un producto de
trabajo, componente o sistema para determinar si cumple con los requisitos establecidos. De hecho, la
verificacin se centra en la pregunta "Es la entrega construido de acuerdo a la especificacin? '. La validacin
se refiere a la evaluacin de un producto de trabajo, componente o sistema para determinar si cumple con las
necesidades y requerimientos de los usuarios. La validacin se centra en la pregunta "Es el ajuste se puede
entregar para el propsito, por ejemplo, tampoco proporciona una solucin al problema? '.

2.1.1 V-modelo

Antes de discutir el modelo en V, vamos a ver el modelo que haba antes de l.El modelo de cascada fue uno de los
primeros modelos, que se establecer. Tiene una lnea de tiempo natural, donde las tareas se ejecutan de manera
secuencial. Comenzamos en la parte superior de la cascada con un estudio de viabilidad y el flujo a travs de las
diversas tareas del proyecto acabado con aplicacin en el entorno real. fluye a travs del diseo en el desarrollo, que
a su vez desemboca en construccin, y finalmente en en la prueba. Las pruebas tiende a ocurrir hacia el final del
ciclo de vida del proyecto por lo que los defectos se detectan cerca de la fecha de implantacin en vivo. Con este
modelo ha sido difcil conseguir la regeneracin pasado hacia atrs hasta la cascada y hay dificultades si tenemos
que realizar numerosas iteraciones para una fase particular.

El V-modelo fue desarrollado para abordar algunos de los problemas experimentados con el enfoque
tradicional cascada.Los defectos se estn encontrando demasiado tarde en el ciclo de vida, como la prueba
no estaba implicado hasta el final del proyecto. Las pruebas tambin aade tiempo de espera debido a su
implicacin tarde. El modelo V-pro-porciona orientacin que la prueba debe comenzar lo antes posible en
el ciclo de vida, que, como hemos visto en el captulo 1, es uno de los princi-pios fundamentales de la
prueba estructurada. Tambin muestra que la prueba no es slo una actividad basada en la ejecucin. Hay
una variedad de actividades que deban llevarse a cabo antes de que el final de la fase de codificacin.
Estas actividades deben llevarse a cabo en paralelo con las actividades de desarrollo, y los probadores
tienen que trabajar con devel-opers y analistas de negocios para que puedan realizar estas actividades y
tareas y producir un conjunto de entregables de prueba.Los productos de trabajo producidos por los
desarrolladores y analistas de negocios durante el desarrollo son la base de las pruebas en uno o ms
niveles. Al comenzar el diseo del ensayo temprano, los defectos se encuentran a menudo en los
documentos bsicos de prueba. Una buena prctica es probadores han participado incluso antes, durante
la revisin de los documentos bsicos (borrador) de prueba. El V-modelo es un modelo que ilustra cmo
las actividades de prueba (verificacin y validacin) pueden integrarse en cada fase del ciclo de vida.
Dentro del modelo de V, las pruebas de validacin se lleva a cabo especialmente durante las primeras
etapas, por ejemplo, la revisin de los requisitos de los usuarios, y al final del ciclo de vida, por ejemplo,
durante las pruebas de aceptacin del usuario.

Aunque existen variantes del modelo en V, un tipo comn de V-modelo utiliza cuatro niveles de
prueba. Los cuatro niveles de prueba utilizados, cada uno con sus propios objetivos, son:


comprobacin de los componentes: busca defectos en y verifica el funcionamiento de los
componentes de software (por ejemplo, mdulos, programas, objetos, clases, etc.) que son
comprobables por separado;

pruebas de integracin: las interfaces entre los componentes de las pruebas, las interacciones con
dif rentes partes de un sistema tal como un sistema operativo, sistema de archivos y mercancas duras
o interfaces entre los sistemas;

las pruebas del sistema: en cuestin con el comportamiento de todo el sistema / producto, definida por
el alcance de un proyecto de desarrollo o producto.El foco principal de las pruebas del sistema es la
verificacin respecto a los requisitos especificados;

pruebas de aceptacin: las pruebas de validacin en relacin con las necesidades del usuario,
requiere mentos y procesos de negocio llevadas a cabo para determinar si acepta o no el sistema.

Los diferentes niveles de la prueba se explican y analizan en detalle en la seccin 2.2. En la prctica, un
modelo en V puede tener ms o menos diferentes niveles de desarrollo,

rrollo y pruebas, dependiendo del proyecto y el producto de software. Por ejemplo, puede haber pruebas
de integracin de componentes despus de la prueba y el sistema de pruebas de integracin de
componentes despus de las pruebas del sistema. Los niveles de prueba pueden ser combinados o
reorganizarse en funcin de la naturaleza del proyecto o la arquitectura del sistema. Para la integracin de
un estante fuera de la facilidad en el mercado (COTS) producto de software en un sistema, un
comprador puede realizar slo pruebas de inte-gracin a nivel del sistema (por ejemplo, la integracin de
la infraestructura y otros sistemas) y en una etapa de pruebas de aceptacin posterior.

Tenga en cuenta que los tipos de productos de trabajo mencionadas en la figura 2.2 en el lado izquierdo
de la V-modelo son slo una ilustracin. En la prctica vienen bajo muchos nombres dife-rentes.
Referencias para los productos de trabajo genricos incluyen el Capability Maturity Model Integration
(CMMI) o los "procesos del ciclo de vida del software 'de la norma ISO / IEC 12207. El CMMI es un
marco para la mejora de procesos, tanto para la ingeniera de sistemas e ingeniera de software. Se
proporciona orientacin sobre dnde enfocar y cmo, con el fin de aumentar el nivel de madurez de los
procesos [Chrissis et ah, 2004].ISO / IEC 12207 es un estndar de proceso del ciclo de vida del software
integrado que se est convirtiendo rpidamente ms popular.

2.1.2 ciclos de vida iterativos

No todos los ciclos de vida son secuenciales. Tambin hay ciclos de vida iterativos o incrementales,
donde, en lugar de una gran lnea de tiempo de desarrollo de principio a fin, pasar por una serie de fases
del ciclo de vida ms pequeos autnomos para el mismo proyecto. Al igual que con el modelo en V, hay
muchas variantes de los ciclos de vida iterativos.

Una caracterstica comn de los enfoques iterativos es que la entrega se divide en incrementos o construye
con cada incremento de aadir nuevas funcionalidades.El incremento inicial contendr la infraestructura
necesaria para soportar la funcionalidad inicial de construccin. El incremento producido por una iteracin
puede ser probado en varios niveles, como parte de su desarrollo. Los incrementos subsiguientes necesitarn
pruebas para la nueva funcionalidad, pruebas de regresin de la funcionalidad existente, y las pruebas de integracin de los nuevos y existentes partes. Las pruebas de regresin es cada vez ms importante en todas las
iteraciones despus de la primera. Esto significa que ser necesario realizar ms pruebas en cada fase posterior
entrega que debe tenerse en cuenta en los planes del proyecto. Este ciclo de vida puede dar presencia en el
mercado temprano con func-cionalidad crtico, puede ser ms fcil de manejar debido a la carga de trabajo se
divide en trozos ms pequeos, y puede reducir la inversin inicial aunque puede costar ms en el largo plazo.
Adems presencia en el mercado a principios significar pruebas de validacin se lleva a cabo en cada
incremento, dando as respuesta temprana en el valor del negocio y la aptitud para el uso del producto.

Ejemplos de modelos de desarrollo iterativos o incrementales son prototipos, desarrollo rpido de

aplicaciones (RAD), Rational Unified Process (RUP) y el desarrollo gil.Con el propsito de desarrollar
modelos iterativos-ment mejor comprensin y el papel cambiante de probar una breve explicacin de
ambos RAD y el desarrollo gil se proporciona.

Desarrollo rpido de aplicaciones

Desarrollo rpido de aplicaciones (RAD) es formalmente un desarrollo paralelo de las funciones y la

posterior integracin.

Componentes / funciones se desarrollan en paralelo como si fueran mini-proj-eja, los desarrollos son
encajadas en tiempo, entregados, y luego se ensamblan en un prototipo de trabajo. Esto puede dar muy
rpidamente al cliente algo que ver y utilizar y ofrecer informacin relacionada con la entrega y sus requisitos.
El rpido cambio y el desarrollo del producto es posible usar este methodol-loga. Sin embargo necesitar la
especificacin del producto a desarrollar para el producto en algn momento, y tendr que ser sometido a
controles ms formales antes de entrar en la produccin del proyecto. Esta metodologa permite temprana

validacin de los riesgos de la tecnologa y una respuesta rpida a las cambiantes necesidades de los
clientes.

Metodologa de Desarrollo de Sistema Dinmico [DSDM] es un proceso que permite a RAD refinada
controles para ponerse en marcha con el fin de detener el proceso se salga de control. Recuerde que
todava tiene que tener los elementos esenciales de la buena prctica de desarrollo en su lugar a fin de que
estas metodologas para trabajar. Tenemos que mantener una estricta gestin de la configuracin de los
rpidos cambios que estamos haciendo en una serie de ciclos de desarrollo paralelo. Desde la perspectiva
de las pruebas que necesitamos para planificar esto con mucho cuidado y actualizar los planes
peridicamente ya que las cosas van a cambiar muy rpidamente (vase el Captulo 5 para ms
informacin sobre los planes de prueba).

El proceso de desarrollo RAD estimula la regeneracin de cliente activo. El cliente obtiene una
visibilidad temprana del producto, puede proporcionar informacin sobre el diseo y puede decidir,
basndose en la funcionalidad existente, si proceder con el desarrollo, lo que la funcionalidad para incluir
en el prximo ciclo de entrega o incluso para detener el proyecto si es no entregar el valor esperado. Una
solucin centrada en el negocio temprano en el mercado da un pronto retorno de la inversin (ROI) y
puede proporcionar valiosa informacin de marketing para el negocio. Validacin con el proceso de
desarrollo RAD es, pues, una actividad importante y temprana.

Desarrollo gil

Extreme Programming (XP) es actualmente uno de los modelos ms conocidos del ciclo de vida de
desarrollo gil. (Vase [gil] para las ideas detrs de este enfoque.) La metodologa pretende ser amigable
ms humano que los mtodos tradicionales de desarrollar-ment. Algunas caractersticas de XP son:

Promueve la generacin de historias de negocios para definir la funcionalidad.

Exige un cliente in situ de retroalimentacin continua y para definir y llevar a cabo las pruebas de
aceptacin funcional.

Promueve la programacin en parejas y la propiedad de cdigo compartido entre los

desarrolladores.
Afirma que los scripts de prueba de componentes debern ser escritos antes de que el cdigo est
escrito y que esas pruebas deben ser automatizados.

Se afirma que la integracin y las pruebas del cdigo debern ocurrir varias veces al da.

Afirma que ha puesto en prctica la solucin ms sencilla para satisfacer los problemas de hoy.

Con XP hay numerosas iteraciones de cada prueba que requiere. XP-ers desarrollar escriben todos los casos
de prueba que se les ocurra y automatizarlos. Cada vez que se realiza un cambio en el cdigo es probado
componente y luego integrado con el cdigo existente, que a su vez es totalmente integracin a prueba
utilizando el conjunto completo de casos de prueba. Esto le da a la integracin continua, por lo que
entendemos que los cambios se incorporan de forma continua en la compilacin de software. Al mismo
tiempo, todos los casos de prueba deben ejecutar al 100% lo que significa que todos los casos de prueba que
han sido identificados y automatizadas se ejecutan y pasan. XP no se trata de hacer actividades extremas
durante el proceso de desarrollo, se trata de hacer actividades vajue-adicin conocidos de una manera extrema.

2.1.3 Ensayos dentro de un modelo de ciclo de vida

En resumen, lo que se est utilizando modelo de ciclo de vida, hay varias carac-ticas de buena prueba:

para cada actividad de desarrollo hay una actividad pruebas correspondientes;

cada nivel de prueba tiene objetivos especficos de prueba a ese nivel;


el anlisis y diseo de pruebas para un nivel dado de ensayo deberan comenzar durante el
desarrollo de la actividad correspondiente;

probadores deben participar en la revisin de documentos tan pronto como borradores son
capaces vano en el ciclo de desarrollo.

2. 2 NIVELES DE PRUEBA

1 Comparacin de los diferentes niveles de comprobacin: principales objetivos, objetos

tpicos de las pruebas, los objetivos tpicos de las pruebas (por ejemplo, funcional o
estructural) y productos de trabajo relacionados, las personas que dan, los tipos de defectos y
fallos sean identificados. (k)

El V-modelo para la prueba se introdujo en la Seccin 2.1. Esta seccin analiza con ms detalle en los distintos
niveles de la prueba. Las caractersticas clave para cada nivel de prueba se discuten y se definen para ser capaz
de separar ms claramente los diferentes niveles de prueba. Una comprensin profunda y la definicin de los
distintos niveles de la prueba identificarn las reas que faltan y evitar el solapamiento y la repeticin. A veces
podemos desear introducir solapamiento deliberado para hacer frente a riesgos especficos. Saber si queremos
solapamientos y acabar con las lagunas har que los niveles de prueba complementaria ms lo que conduce a la
prueba ms eficaz y eficiente.

2.2.1 Pruebas de componentes

Pruebas de componentes, tambin conocido como unidad, mdulo y programa de pruebas, las
bsquedas por defectos en, y verifica el funcionamiento del software (por ejemplo, mdulos, programas,
objetos, clases, etc.) que son por separado comprobable.

Pruebas de componentes puede realizarse de forma aislada del resto del sistema dependen-cin en el
contexto del ciclo de vida de desarrollo y el sistema. Lo ms a menudo los trozos y los conductores se
utilizan para reemplazar el software que falta y simular la interfaz entre los componentes de software de
una manera simple.Un taln se llama desde el componente de software a probar; un controlador llama a
un componente a ensayar (vase la figura 2.5).

Pruebas de componentes puede incluir pruebas de funcionalidad y caractersticas no funcionales

especficos tales como recursos en el comportamiento (por ejemplo, prdidas de memoria), porrendimiento o la comprobacin de la solidez, as como pruebas estructurales (por ejemplo, la cobertura
de decisin).Los casos de prueba se derivan de los productos de trabajo, tales como el diseo de software
o el modelo de datos.

Por lo general, las pruebas de componentes se produce con acceso al cdigo que est siendo probado y
con el apoyo del entorno de desarrollo, tales como un marco de trabajo o la depuracin herramienta de
prueba de la unidad, y en la prctica por lo general implica el programador que escribi el cdigo. A
veces, dependiendo del nivel aplicable de riesgos, los ensayos compo-nente se lleva a cabo por un
programador diferente introduciendo de este modo inde-pendencia. Los defectos se fijan normalmente tan
pronto como se encuentran, sin registro oficial de los incidentes que se encuentran.

Un enfoque en las pruebas de componentes, que se utiliza en la programacin extrema (XP), es preparar y
automatizar casos de prueba antes de la codificacin. Esto se llama un enfoque de prueba de primera o de
desarrollo basado en pruebas. Este enfoque es muy iterativo y se basa en los ciclos de desarrollo de casos de
prueba, a continuacin, la construccin y la integracin de pequeas piezas de cdigo, y la ejecucin de las
pruebas de componentes hasta que pasan.

2.2.2 Las pruebas de integracin

Interfaces de pruebas de pruebas de integracin entre los componentes, interacciones de DIF-rentes

partes de un sistema tal como un sistema operativo, sistema de ficheros y duro-ware o las interfaces entre
los sistemas.Tenga en cuenta que las pruebas de integracin debe diferenciarse de otras actividades de
integracin. Las pruebas de integracin se lleva a cabo a menudo por el integrador, pero preferiblemente
mediante un probador de integracin especfico o equipo de pruebas.

Puede haber ms de un nivel de pruebas de integracin y se puede llevar a cabo en los objetos de
prueba de tamao variable. Por ejemplo:

las pruebas de integracin de componentes a prueba las interacciones entre los componentes de
software y com se realiza despus de las pruebas de componentes;

las pruebas de integracin de sistemas a prueba las interacciones entre diferentes sistemas y puede
hacerse despus de las pruebas del sistema.En este caso, la Organiza cin en desarrollo puede controlar
slo un lado de la interfaz, por lo que los cambios pueden ser lizing destabi. Los procesos de negocio
implementados como flujos de trabajo pueden implicar una serie de sistemas que puede incluso funcionar
en diferentes plataformas.

Cuanto mayor sea el alcance de la integracin, ms difcil se hace para aislar fallos a una interfaz especfica, que
puede conducir a un mayor riesgo. Esto conduce a diferentes formas de emprender las pruebas de integracin. Un
extremo es que todos los compo-nentes o sistemas estn integrados al mismo tiempo, despus de lo cual todo se

prueba como un todo. Esto se llama 'big-bang' pruebas de integracin. pruebas de big-bang tiene la ventaja de que
todo est terminado antes del comienzo de las pruebas de integracin. No hay necesidad para simular (an sin
terminar) partes. La principal desventaja es que en

general, es mucho tiempo y es difcil de encontrar la causa de los fallos con esta integracin tarda.Por lo
tanto la integracin del big-bang puede parecer una buena idea al plan de-cin del proyecto, siendo
optimista y esperando encontrar ningn problema. Si se piensa en las pruebas de integracin va a
encontrar defectos, es una buena prctica considerar si el tiempo se salve por romper el el proceso de
pruebas de integracin. Otro extremo es que todos los programas estn integrados uno a uno, y una
prueba se lleva a cabo despus de cada paso (pruebas incremental). Entre estos dos extremos, hay una
gama de variantes. El enfoque incremental tiene la ventaja de que los defectos se encuentran al principio
de un conjunto ms pequeo cuando es relativamente fcil de detectar la causa. Una desventaja es que
puede llevar mucho tiempo ya que los trozos y los conductores tienen que ser desarrollado y utilizado en
la prueba. Dentro incremental de inte-gracin probando una gama de posibilidades existen, en parte, en
funcin de la arquitectura del sistema:

De arriba hacia abajo: la prueba se lleva a cabo de arriba a abajo, siguiendo el flujo de control o
estructura arquitectnica (por ejemplo, a partir de la interfaz grfica de usuario o en el men
principal).Componentes o sistemas son sustituidos por los talones.

De abajo hacia arriba: la prueba se lleva a cabo desde la parte inferior del control de flujo hacia
arriba.Componentes o sistemas son sustituidos por los conductores.

Funcional incrementales: la integracin y las pruebas se lleva a cabo sobre la base de las funciones o
funcionalidades, como se documenta en la especificacin funcional.

La secuencia de integracin preferido y el nmero de pasos de integracin requeridos dependen de la

ubicacin en la arquitectura de las interfaces de alto riesgo. La mejor opcin es comenzar la integracin con
los interfaces que se espera que causen ms problemas. Hacer esto impide que los defectos importantes al final
de la fase de prueba de inte-gracin. Con el fin de reducir el riesgo de ser descubierto tarde defecto, integracin debe normalmente ser incrementales en lugar de 'big-bang'. Lo ideal sera que los probadores deben
entender la planificacin de la arquitectura y la influencia de integracin. Si se planifican las pruebas de integracin antes de construir componentes o sistemas, que pueden ser desarrollados en el orden requerido para las
pruebas ms eficiente.

En cada etapa de la integracin, los probadores se concentran nicamente en la propia integracin. Por
ejemplo, si se estn integrando el componente A con el componente B que estn interesados en probar la
comunicacin entre los componentes, no la funcionalidad de cualquiera de ellos. Ambos enfoques
funcionales y estructurales se pueden usar. Ensayo de caractersticas no funcionales especficos (por

ejemplo de rendimiento) tambin puede estar incluida en las pruebas de integracin. Las pruebas de
integracin se puede llevar a cabo por los desarrolladores, pero puede ser realizado por un equipo
independiente de probadores de integracin especializadas, o por un grupo especializado de
desarrolladores / integradores incluyendo especialistas no func-cional.

Prueba del sistema

Las pruebas del sistema est relacionada con el comportamiento de todo el sistema / producto como definido por el
alcance de un proyecto de desarrollo o producto.Puede incluir pruebas basadas en los riesgos y / o especificacin de
requisitos, procesos de negocio, casos de uso, u otras descripciones de alto nivel de comportamiento del sistema, las
interacciones con el sistema oper-CIONES, y los recursos del sistema. Las pruebas del sistema es ms a menudo la
prueba final en nombre del desarrollo para verificar que el sistema para ser entregado cumple con la especificacinficacin y su propsito puede ser de encontrar ya que muchos defectos como sea posible. Ms amenudo

que se lleva a cabo por los probadores especializadas que formen un dedicado, ya veces inde-pendiente,
equipo de pruebas dentro del desarrollo, que depende del gerente de desarrollo o director del proyecto.En
algunas organizaciones las pruebas del sistema se lleva a cabo por un equipo tercero o por los analistas de
negocios. Una vez ms el nivel requerido de inde-cia est en funcin del nivel de riesgo aplicable y esto
tendr una alta influencia en las pruebas del sistema se organiza manera.

Las pruebas del sistema debe investigar tanto funcionales como no funcionales requisitos del
sistema.Pruebas no funcionales tpicos incluyen el rendimiento y fiabilidad.Probadores tambin pueden
necesitar para hacer frente a los requisitos incompletos o sin papeles. Las pruebas del sistema de
requisitos funcionales se inicia mediante el uso de las tcnicas de caja (negro) ms adecuadas basadas en
las especificaciones para el aspecto del sistema a ser probado. Por ejemplo, una tabla de decisin puede
ser creado para com-binaciones de los efectos descritos en las reglas de negocio. (caja blanca) tcnicas
basadas en la estructura tambin se pueden utilizar para evaluar la minuciosidad de los elementos de
prueba tales como la estructura de dilogo o men de navegacin pgina web (vase el captulo 4 para
ms informacin sobre los diferentes tipos de tcnica).

Las pruebas del sistema requiere un entorno de prueba controlada con respecto a, entre otras cosas, el
control de las versiones de software, testware y los datos de prueba (vase el Captulo 5 para ms
informacin sobre la gestin de configuracin).Una prueba del sistema es ejecutado por la organizacin
de desarrollo en un (debidamente controlada) environ-ment. El entorno de prueba debe corresponder a la
final de destino o entorno de produccin tanto como sea posible a fin de minimizar el riesgo de fallos
especficos del entorno no ser encontrados por las pruebas.

Pruebas de aceptacin

Cuando la organizacin de desarrollo ha realizado su prueba del sistema y tiene cor-rected todos o la
mayora de los defectos, el sistema ser entregado al usuario o cliente para las pruebas de aceptacin. La
prueba de aceptacin debe responder a preguntas como: "Qu, en su caso, son los riesgos (de negocios)
en circulacin ''? Puede ser liberado del sistema, y 'Ha cumplido con sus obligaciones de desarrollo?'.
Las pruebas de aceptacin es ms a menudo la responsabilidad del usuario o cliente, aunque otros
stakehold-res pueden estar implicados tambin. La ejecucin de la prueba de aceptacin requiere un
entorno de prueba que es para la mayora de los aspectos, representativa de la produccin environ-ment
( "como si la produccin ').

El objetivo de las pruebas de aceptacin es establecer la confianza en el sistema, parte del sistema o
caractersticas no funcionales especficos, por ejemplo la facilidad de uso, del sistema. Las pruebas de
aceptacin ms a menudo se centra en un tipo de validacin de las pruebas, por lo que estamos tratando
de determinar si el sistema es adecuado para el propsito. Encontrar defectos no deben ser el foco
principal de las pruebas de aceptacin. Aunque se evala la disposicin del sistema para el despliegue y
uso, no es necesariamente el nivel final de la prueba. Por ejemplo, una prueba de integracin de sistemas
a gran escala puede venir despus de la aceptacin de un sistema.

Las pruebas de aceptacin puede ocurrir en ms de un solo nivel, por ejemplo:

Un Comercial Off El producto de software (COTS) se puede ensayar la aceptacin cuando se

instala o integrado.
Las pruebas de aceptacin de la usabilidad de un componente puede hacerse durante las pruebas
com ponente.

Las pruebas de aceptacin de una nueva mejora funcional puede venir antes de las pruebas del
sistema.

Dentro de la prueba de aceptacin para un sistema de negocio de apoyo, dos tipos de pruebas se pueden
distinguir; como resultado de su carcter especial, son generalmente preparados y ejecutados por
separado. La prueba de aceptacin del usuario se centra principalmente en la funcionalidad validando as
la aptitud para el uso del sistema por parte del usuario de negocios, mientras que la prueba de aceptacin
operativa (tambin llamada la produccin de prueba de aceptacin) valida si el sistema cumple los
requisitos de la explotacin.La prueba de aceptacin del usuario se lleva a cabo por los usuarios y los
administradores de la aplicacin. En cuanto a la planificacin, la prueba de aceptacin del usuario por lo
general vincula estrechamente a la prueba del sistema y, en muchos casos, ser-zado rgano superponen en
el tiempo. Si el sistema a ser probado se compone de un nmero de subsistemas ms o menos
independientes, la prueba de aceptacin para un subsistema que cumple con los criterios de salida de la
prueba del sistema puede comenzar mientras que otro subsistema puede estar todava en la fase de prueba
del sistema. En la mayora-ciones de Organiza, la administracin del sistema llevar a cabo la prueba de

aceptacin operativa poco antes de que el sistema est en libertad. La prueba de aceptacin operacional
puede incluir la prueba de copia de seguridad / restauracin, recuperacin de desastres, las tareas de
mantenimiento y verificacin peridica de las vulnerabilidades de seguridad.
Otros tipos de pruebas de aceptacin que existen son contrato de las pruebas de aceptacin y
cumplimiento de las pruebas de aceptacin. las pruebas de aceptacin del contrato se realiza en contra
de los criterios de aceptacin de un contrato para la produccin desarrollado por encargo soft-ware. La
aceptacin deben estar formalmente definidos cuando se acord el contrato. Cumplimiento de las pruebas
de aceptacin o aceptacin regulacin de las pruebas se realizan en contra de las normas que se deben
cumplir, como los reglamentos gubernamentales, legales o de seguridad.

Si el sistema ha sido desarrollado para el mercado de masas, por ejemplo, software off-the-shelf (COTS),
luego las pruebas para usuarios individuales o clientes no es prctico ni posible en algunos casos.
Retroalimentacin es necesaria de los usuarios potenciales o existentes en su mercado antes de que el producto
de software es puesto out en venta en el comercio. Muy a menudo este tipo de sistema se somete a dos etapas
de la prueba de aceptar-ANCE. El primero se llama alfa de prueba. Esta prueba se lleva a cabo en el lugar de
la de desa-oper. Una seccin transversal de los usuarios potenciales y los miembros de la organizacin de los
desarrolladores estn invitados a utilizar el sistema. Los desarrolladores observan los usuarios y los problemas
de nota. Las pruebas alfa tambin puede llevarse a cabo por un equipo de pruebas independiente. Las pruebas
beta, o las pruebas de campo, el sistema enva a una muestra representativa de los usuarios que instalen y
utilicen en los trminos de las condiciones de trabajo del mundo real.Los usuarios envan los registros de
incidentes con el sistema de la organizacin de desarrollo donde se han reparado los defectos.

Tenga en cuenta que las organizaciones pueden utilizar otros trminos, como las pruebas de aceptacin
en fbrica y la aceptacin sitio de prueba para sistemas que se ponen a prueba antes y despus de ser
trasladado a las instalaciones del cliente.

2.3 Tipos de pruebas: LOS OBJETIVOS DE LA

VERIFICACIN

1 Comparacin de cuatro tipos de pruebas de software (funcionales y no funcionales,

estructurales
y cambiar relacionados con) por ejemplo. (k)

2 Reconocer que las pruebas funcionales y estructurales se producen en cualquier

nivel de la prueba.

{0}k = 0.015 L{/0}{1}1{/1}

3 Identificacin y descripcin de los tipos de pruebas no funcionales basados en no

funcional

. (k)

4 Identificacin y descripcin de los tipos de prueba basados en el anlisis de un

software

estructura o arquitectura del sistema. (k)

5
Describir el propsito de las pruebas de confirmacin y pruebas de
regresin.

(k)

Los tipos de prueba se introducen como un medio para definir con claridad el objetivo de un cierto nivel
de prueba para un programa o proyecto. Tenemos que pensar acerca de los tipos difieren-tes de la prueba
debido probar la funcionalidad del componente o sistema puede no ser suficiente en cada nivel para
cumplir con los objetivos generales de la prueba. Enfoque de la prueba en un objetivo de la prueba
especfica y, por lo tanto, la seleccin del tipo apropiado de prueba ayuda a la toma de decisiones y que se
comunican con los objetivos de las pruebas ms sencillas.

Un tipo de prueba se centr en un objetivo de la prueba en particular, lo que podra ser el ensayo de
una funcin a realizar por el componente o sistema; una caracterstica de calidad no funcionales, tales
como la fiabilidad o usabilidad; la estructura o arquitectura del componente o sistema; o relacionados con
los cambios, es decir, con-reafirmante que los defectos han sido corregidos (prueba de confirmacin, o la
repeticin de pruebas) y en busca de cambios no deseados (pruebas de regresin).Dependiendo de sus
obje-tivas, las pruebas se organizarn de manera diferente. Por ejemplo, la prueba de componentes
dirigida a un rendimiento sera muy diferente a las pruebas de componentes destinada a lograr la
cobertura de decisin.

2.3.1 Pruebas de la funcin (pruebas funcionales)

La funcin de un sistema (o componente) es 'lo que hace'. Esto se describe tpicamente en una especificacin
de requisitos, una especificacin funcional, o en los casos de uso. Puede haber algunas funciones que se
"supone" que siempre que no estn documentados que son tambin parte de la necesidad de un sistema, aunque
es difcil de probar en contra de los requisitos de indocumentados e implcitos. Las pruebas funcionales se
basan en estas funciones, que se describen en los documentos o entendidos por los probadores y se pueden
realizar en todos los niveles de prueba (por ejemplo, prueba de componentes puede estar basada en una
especificacin de componente).

Las pruebas funcionales considera el comportamiento especificado y es a menudo tambin se refiri

como las pruebas de recuadro negro. Esto no es del todo cierto, ya que las pruebas de recuadro negro
tambin incluye pruebas no funcionales (vase la Seccin 2.3.2).

Funcin (o funciones) de prueba puede, en base a la norma ISO 9126, se har foco-cin sobre la
idoneidad, la interoperabilidad, la seguridad, la precisin y el cumplimiento.Las pruebas de seguridad, por
ejemplo, investiga las funciones (por ejemplo, un firewall) en relacin con detec-cin de amenazas, como
virus, gente maliciosa del exterior.

funcionalidad de prueba puede hacerse desde dos perspectivas: los requisitos basados en o basados en
procesos de empresa.

pruebas basadas en requerimientos utiliza una especificacin de la Require-mentos funcionales para el

sistema como base para el diseo de pruebas. Una buena manera de empezar es utilizar la tabla de
contenido de la especificacin de requisitos como un inventario inicial de prueba o una lista de elementos
para probar (o no poner a prueba). Tambin hay que dar prioridad a las necesidades basadas en criterios
de riesgo (si esto no se ha hecho ya en el specifica-cin) y usar esto para dar prioridad a las pruebas. Esto
asegurar que las pruebas ms impor-tantes y ms crticos estn incluidas en el esfuerzo de prueba.

Las pruebas basadas en procesos de empresa utiliza el conocimiento de los procesos de negocio. Los
procesos de negocio se describen los escenarios involucrados en el uso del negocio del da a da del sistema.
Por ejemplo, un sistema de personal y nmina puede tener un proceso de nego-dad a lo largo de las lneas de:
alguien se une a la compaa, l o ella se le paga sobre una base regular, y l o ella finalmente deja la
compaa. Los casos de uso originados por el desarrollo orientado a objetos, sino que son hoy en da muy
popular en muchos ciclos de vida de desarrollar-ment. Tambin toman los procesos de negocio como punto de
partida, aunque se parte de las tareas a realizar por los usuarios. Los casos de uso son una base muy til para
casos de prueba desde una perspectiva de negocio.

Las tcnicas utilizadas para las pruebas funcionales son a menudo basada en la especificacin, pero las tcnicas
a base de experimentados tambin pueden utilizarse (vase el captulo 4 para ms informacin sobre tcnicas de
prueba).Condiciones de prueba y casos de prueba se derivan de la funcionalidad del componente o sistema. Como
parte del diseo de prueba, un modelo puede ser desarrollado, como un modelo de proceso, el modelo de transicin
de estado o una especificacin en lenguaje claro.

2.3.2 Pruebas de software de las caractersticas del producto (ensayos

no funcional)

Un segundo objetivo de la prueba es la prueba de las caractersticas de calidad, o atributos no funcionales

del sistema (o componente o la integracin del grupo). Aqu estamos interesados en qu tan bien o algo
rpido que se hace. Estamos probando algo que necesitamos medir en una escala de medicin, por
ejemplo, el tiempo para responder.

Ensayos no funcional, como las pruebas funcionales, se lleva a cabo en todos los niveles de prueba. No
funcional de prueba incluye, pero no est limitado a, pruebas de rendimiento, de carga las pruebas, las
pruebas de estrs, pruebas de usabilidad, pruebas de mantenimiento, pruebas de fiabilidad y la portabilidad
de prueba.Es la prueba de "lo bien" que funciona el sistema.

Muchos han tratado de captar la calidad del software en un conjunto de caractersticas y sub-caractersticas
relacionadas. En estos modelos algunas caracters-ticas elementales siguen reapareciendo, aunque su lugar en
la jerarqua puede ser diferente. La Organizacin Internacional de Normalizacin (ISO) ha definido un
conjunto de caractersticas de calidad [ISO / IEC 9126, 2001]. Este conjunto refleja un importante paso hacia
el consenso en la industria de TI y por lo tanto se refiere a la nocin general de la calidad del software. La
norma ISO 9126 define seis caractersticas de calidad y la subdivisin de cada caracterstica de calidad en un
nmero de

sub-caractersticas.Esta norma es cada vez ms y ms reconocimiento en la industria, lo que permite el

desarrollo, prueba y sus grupos de inters de utilizar una terminologa comn para las caractersticas de
calidad y por lo tanto para las pruebas no funcionales.

Las caractersticas y sus sub-caractersticas son, respectivamente:

funcionalidad, que consta de cinco sub-caractersticas: idoneidad, precisin, seguridad,

interoperabilidad y cumplimiento; Esta caracterstica se refiere a las pruebas cional func como se
describe en la Seccin 2.3.1;

fiabilidad, que se define adicionalmente en la madurez sub-caractersticas (robustez), tolerancia a

fallos, capacidad de recuperacin y el cumplimiento;

facilidad de uso, que se divide en la comprensibilidad sub-caractersticas, facilidad de aprendizaje,

operabilidad, el atractivo y el cumplimiento;

eficiencia, que se divide en comportamiento en el tiempo (rendimiento), uti recursos lizacin y el

cumplimiento;

mantenibilidad, que consta de cinco sub-caractersticas: analizabilidad, mutabilidad, la

estabilidad, la capacidad de prueba y el cumplimiento;

portabilidad, que tambin consta de cinco sub-caractersticas: capacidad de adaptacin, capacidad

de instalacin, la convivencia, la intercambiabilidad y cumplimiento.

2.3.3 Ensayos de estructura de software / Arquitectura (pruebas estructurales)

La tercera objetivo de las pruebas es la estructura del sistema o componente. Si estamos hablando de la
estructura de un sistema, podemos llamarla la arquitectura del sistema. Pruebas estructurales se refiere a
menudo como "caja blanca" o "caja de vidrio ', porque estamos interesados en lo que est sucediendo'
dentro de la caja '.

pruebas estructurales se utiliza ms a menudo como una forma de medir la rigurosidad de las pruebas a
travs de la cobertura de un conjunto de elementos estructurales o elementos de cobertura. Puede ocurrir a
cualquier nivel de la prueba, si bien es cierto que decir que tiende a ser aplicado sobre todo en los
componentes y la integracin y por lo general es menos probable en los niveles ms altos de la prueba, a
excepcin de las pruebas de los procesos empresariales. En el nivel de integracin de componentes que
puede estar basada en la arquitectura del sistema, tal como un JERAR-CHi llamando. Una base de
pruebas pruebas del sistema, integracin de sistemas o aceptacin podra ser un modelo de negocio o
estructura del men.

A nivel de componentes, y en menor medida en las pruebas de integracin de componentes, hay una
buena herramienta de apoyo para medir la cobertura de cdigo. Herramientas de medicin de la
cobertura de evaluar el porcentaje de elementos ejecutables (por ejemplo, estado-mentos o resultados de
decisin) que han sido ejercitados (es decir, cubiertos) por una serie de pruebas.Si la cobertura no es
100%, entonces pruebas adicionales pueden necesitar ser escrita y correr para cubrir aquellas partes que
an no han sido ejercidos.Por supuesto, esto depende de los criterios de salida. (Tcnicas de cobertura se
describen en el Captulo 4.)

Las tcnicas utilizadas para pruebas estructurales son las tcnicas basadas en la estructura, tambin se
hace referencia como tcnicas de caja blanca. modelos de flujo de control se utilizan a menudo para
apoyar las pruebas estructurales.

2.3.4 Ensayos relacionados con los cambios (de confirmacin y pruebas de

regresin)
El objetivo final de la prueba es la prueba de los cambios. Esta categora es un poco dif-ferente a los
otros, porque si usted ha hecho un cambio en el software, se le han cambiado la forma en que funciona, la
forma en que se lleva a cabo (o ambas) y su estruc-tura. Sin embargo estamos buscando aqu en los tipos
especficos de pruebas relativas a los cambios, a pesar de que pueden incluir todos los otros tipos de
pruebas.

las pruebas de confirmacin (repeticin de pruebas)

Cuando una prueba falla y se determina que la causa del fracaso es un defecto de software, se inform el
defecto, y podemos esperar una nueva versin del software que ha tenido el defecto fijo. En este caso
tendremos que ejecutar la prueba de nuevo para confirmar que el defecto de hecho se ha solucionado.
Esto se conoce como la confirmacin prueba (tambin conocido como re-ensayo).

Al hacer las pruebas de confirmacin, es importante asegurarse de que la prueba se ejecuta exactamente de
la misma manera como lo fue la primera vez, usando las mismas entradas, los datos y el medio ambiente. Si la
prueba pasa ahora quiere decir esto que el software est en orden? Pues bien, ahora sabemos que al menos una
parte del software es correcta - donde estaba el defecto. Pero esto no es todo, La correccin puede tener introreducirse o descubierto un defecto en el software diferente en otro lugar. La manera de detectar a estos efectos
secundarios inesperados 'de correcciones es hacer pruebas de regresin.

Pruebas de regresin.

Al igual que las pruebas de confirmacin, pruebas de regresin implica casos de prueba de ejecucin que han
sido ejecutadas antes. La diferencia es que, para las pruebas de regresin, los casos de prueba, probablemente,
pasaron la ltima vez que fueron ejecutados (comparar esto con los casos de prueba ejecutados en las pruebas
de confirmacin - fallaron la ltima vez).

El trmino 'pruebas de regresin "es un trmino equivocado.Sera mejor si se llama prueba

"anti-regresin" porque estamos llevando a cabo pruebas con la intencin de verificar que el
sistema no ha retrocedido (es decir, que ahora no tiene ms defectos en el mismo como resultado de
algn cambio) . Ms especficamente, el propsito de las pruebas de regresin es verificar que las
modificaciones en el software o el medio ambiente no han causado efectos secundarios adversos no
deseados y que el sistema sigue cumpliendo sus requisitos.

Es comn que las organizaciones tienen por lo general lo que se llama un paquete de pruebas banco de pruebas
de regresin o la regresin. Se trata de un conjunto de casos de prueba que se utiliza especficamente para pruebas
de regresin. Estn diseados para ejercer colectivamente la mayora de las funciones (CER-tainly las ms
importantes) en un sistema pero no probar cualquiera en detalle. Es conveniente contar con un conjunto de pruebas
de regresin en todos los niveles de las pruebas (pruebas de componentes, pruebas de integracin, pruebas del
sistema, etc.). Todos los casos de prueba en un conjunto de pruebas de regresin seran ejecutados cada vez que una
nueva versin del software se produce y esto les hace candidatos ideales para la automatizacin. Si el conjunto de
pruebas de regresin es muy grande, puede ser ms apropiado para seleccionar un subconjunto para su ejecucin.

pruebas de regresin se ejecutan cada vez que los cambios de software, ya sea como resultado de las
correcciones o funcionalidad nueva o modificada. Tambin es una buena idea para ejecutarlas cuando se
utiliza algn aspecto de los cambios del entorno, por ejemplo, cuando se introduce una nueva versin de
un sistema de gestin de base de datos o una nueva versin de un compilador de cdigo fuente.

El mantenimiento de un conjunto de pruebas de regresin debe llevarse a cabo por lo que evoluciona con el
tiempo de acuerdo con el software.A medida que se aade una nueva funcionalidad a un sistema de nuevas
pruebas de regresin que debera aadirse o funcionalidad tan antigua se cambia o desaparece tambin lo debe
de regresin pruebas de ser cambiado o eliminado. A medida que se aaden nuevas pruebas de un conjunto de
pruebas de regresin puede llegar a ser muy grande. Si todas las pruebas tienen que ser ejecutado
manualmente puede que no sea posible ejecutar todas ellas cada vez que se utiliza la suite de regresin. En este
caso un subconjunto de los casos de prueba tiene que ser elegido. Esta seleccin debe hacerse a la luz de los
ltimos cambios que se han hecho al software. A veces, un conjunto de pruebas de regresin de pruebas
automatizadas puede llegar a ser tan grande que no siempre es posible ejecutar todas. Puede ser pos-bles y
deseables para eliminar algunos casos de prueba a partir de un conjunto de pruebas de regresin grande, por
ejemplo, si son repetitivos (pruebas que ejercen las mismas condi-ciones) o se pueden combinar (si siempre se
ejecutan en conjunto). Otro enfoque es el de eliminar los casos de prueba que no han encontrado un defecto
durante mucho tiempo (aunque este enfoque se debe utilizar con cuidado!).

2. PRUEBA 4 MANTENIMIENTO

1 Comparacin de las pruebas de mantenimiento (chequeo de un sistema operativo)

para las pruebas

una nueva aplicacin con respecto a los tipos de prueba, disparadores de pruebas y

cantidad de pruebas. (k)

2 Identificar las razones de las pruebas de mantenimiento (modificaciones, la

migracin y

Jubilacin (k)

3 Describir el papel de las pruebas de regresin y anlisis de impacto en el manteni

maricn. (k)

Una vez desplegado, el sistema es a menudo en servicio durante aos o incluso dcadas. Durante este
tiempo el sistema y su entorno de trabajo suelen corregirse, modificarse o ampliarse. Las pruebas que se
ejecuta durante esta fase del ciclo de vida se llama 'pruebas de mantenimiento'.

Tenga en cuenta que las pruebas de mantenimiento es diferente de las pruebas de mantenimiento,
que define lo fcil que es para mantener el sistema.

El proceso de desarrollo y prueba aplicables a los nuevos desarrollos no cambia fundamentalmente para
fines de mantenimiento. Los mismos pasos del proceso de prueba y sern de aplicacin, en funcin del tamao
y el riesgo de los cambios realizados, varios niveles de pruebas se llevan a cabo: una prueba de componentes,
una prueba de integracin, una prueba del sistema y una prueba de aceptacin. Un proceso de prueba de
mantenimiento por lo general comienza con la recepcin de una solicitud de un cambio o un plan de
lanzamiento. El director de pruebas va a utilizar esto como una base para producir un plan de pruebas. Tras la
recepcin de las especificaciones nuevas o modificadas, casos de prueba correspondientes se especifican o
adaptados. Tras la recepcin del objeto de prueba, los nuevos y modificados ensayos y las pruebas de regresin
se ejecutan. Al trmino de la prueba, se conserva una vez ms la testware.

La comparacin de las pruebas de mantenimiento para probar una nueva aplicacin es simplemente una
cuestin de una aproximacin desde un ngulo diferente, lo que da lugar a una serie de

cambios de nfasis.Hay varias zonas donde se producen la mayora de las diferencias, por ejemplo en
cuanto a la realizacin de pruebas selectivas. con frecuencia se requiere una operacin de "puesta a
nivel, cuando se mantienen los sistemas. Las especificaciones son a menudo "faltan", y simplemente no
existe un conjunto de testware relativa a las especificaciones. Bien puede ser posible llevar a cabo esta
oper-acin de puesta al da junto con la prueba de una nueva versin de mantenimiento, lo que puede
reducir el costo. Si no es posible compilar las especificaciones de la cual los casos de prueba pueden ser
escritas, incluyendo los resultados esperados, una base de prueba alternativo, por ejemplo, un orculo de
pruebas, se debe buscar como solucin de compromiso.Una bsqueda debe ser realizado para la
documentacin que est ms prxima a las especificaciones y que pueden ser gestionados por los
desarrolladores, as como probadores.En tales casos, es advis-capaz de llamar la atencin del cliente a la
calidad de la prueba inferior que puede lograrse. Ser conscientes de los posibles problemas de
"produccin diaria '. En el peor de los casos no se sabe lo que se est probando, muchos casos de prueba
son Execut-ing el mismo escenario y si se encuentra un incidente que a menudo es difcil de rastrear de
nuevo al defecto real, ya que no hay trazabilidad para probar diseos y / o requisitos existe . Tenga en
cuenta que la reproducibilidad de las pruebas tambin es importante para las pruebas de mantenimiento.

Un aspecto que, en muchos casos, difiere un poco de la situacin del desarrollo es la organizacin del
ensayo. Nueva sus actividades de ensayo apropiados desarrollo y por lo general se llevan a cabo como parte de
un proyecto, mientras que las pruebas de mantenimiento se ejecutan normalmente como una actividad en la
organizacin peridica. Como resultado, a menudo hay cierta falta de recursos y la flexibilidad, y el proceso de
prueba puede experimentar una mayor competencia de otras actividades.

2.4.1 Anlisis del impacto y pruebas de regresin

Por lo general, las pruebas de mantenimiento constar de dos partes:

las pruebas de los cambios

pruebas de regresin para mostrar que el resto del sistema no se ha visto afectada por los trabajos
de mantenimiento.

Adems de probar lo que se ha cambiado, las pruebas de mantenimiento incluye extensas pruebas de
regresin para las partes del sistema que no se han cambiado. Una de las principales actividades e
importante dentro de las pruebas de mantenimiento es el anlisis del impacto. Durante el anlisis del
impacto, junto con las partes interesadas, una deci-sion se hace sobre qu partes del sistema pueden verse
afectados involuntariamente y por lo tanto necesitan pruebas de regresin cuidado.El anlisis de riesgos
ayudar a decidir dnde enfocar las pruebas de regresin - es poco probable que el equipo tendr tiempo
para repetir todas las pruebas existentes.

Si se mantienen las especificaciones de prueba desde el desarrollo inicial del sistema, uno puede ser
capaz de volver a utilizarlos para las pruebas de regresin y para adaptarlos a los cambios en el sistema.
Esto puede ser tan simple como cambiar los resultados esperados para las pruebas existentes. A veces
pueden necesitar ser construida pruebas adicionales. Extensin o mejora del sistema puede significar
nuevas reas han sido espec-cado y las pruebas se elaborarn al igual que para el desarrollo. Tambin es
posi-ble que las actualizaciones son necesarias para un conjunto de pruebas automatizadas, que a menudo
se utiliza para soportar las pruebas de regresin.

2.4.2 Los disparadores para las pruebas de mantenimiento

Como pruebas de mantenimiento indicado se realiza en un sistema operativo existente. Es provocada por
modificaciones, la migracin, o la jubilacin del sistema. Las modificaciones incluyen cambios de mejora
planificadas (por ejemplo, basado-Release), cambios cor-rectiva y de emergencia, y los cambios en el medio
ambiente, tales como actualizaciones del sistema operativo o de bases de datos previstos, ni parches para las
vulnerabilidades DISCOV-Ered del sistema operativo recin expuestas o.Pruebas de mantenimiento para la
migracin (por ejemplo, de una plataforma a otra) debe incluir la puesta a punto del nuevo entorno, as como
el software modificado.pruebas de mantenimiento para el retiro de un sistema puede incluir el ensayo de
migracin de datos o archivo, si se requieren perodos de retencin de datos a largo.

Puesto que las modificaciones son ms a menudo la parte principal de mantenimiento pruebas FOI
mayora de las organizaciones, esto se discutir en ms detalle. Desde el punto de vista de las pruebas,
hay dos tipos de modificaciones. Hay modificaciones en las que se pueden planear las pruebas, y hay
modificaciones correctivas ad-hoc, que no se pueden planear en absoluto. Ad-hoc mantenimiento
correctivo se lleva a cabo cuando la bsqueda de soluciones a los defectos no se puede retrasar. proce
dimientos de ensayo-especiales se requieren en ese momento.

modificaciones previstas

Los siguientes tipos de modificacin prevista se pueden identificar:

modificaciones perfectivo (adaptacin del software a los deseos del usuario, por ejemplo
mediante el suministro de nuevas funciones o la mejora del rendimiento);
modificaciones adaptativas (software a los cambios ambientales, tales como el nuevo hardware,
software nuevo o sistemas de adaptacin de la nueva legislacin);

modificaciones previstas con correccin (correccin de defectos diferible).

El mtodo de prueba estndar estructurado es casi totalmente aplicable a las modificaciones previstas.
En promedio, modificacin prevista representa ms del 90% de todos los trabajos de mantenimiento de
los sistemas. [Pol y van Veenendaal]

Ad-hoc modificaciones correctivas

Ad-hoc modificaciones correctivas tienen que ver con los defectos que requieren una solucin inme-inme-, por
ejemplo, un ciclo de produccin que vuelca a altas horas de la noche, una red que va hacia abajo con unos

pocos cientos de usuarios en lnea, un correo con direcciones incorrectas. Existen diferentes normas y
procedimientos diferentes para la solucin de problemas de este tipo. Ser imposible tomar los pasos
necesarios para un enfoque estructurado para la prueba. Si, sin embargo, una serie de actividades se llevan a
cabo antes de un posible mal funcionamiento, puede ser posible conseguir una situacin en la que las pruebas
fiables coche. ser ejecutado a pesar de las estaciones de pnico '' todo el ao. En cierta medida, este tipo de
pruebas de mantenimiento es a menudo como los primeros auxilios - remendar - y en una etapa posterior del
proceso de prueba estndar Luego se sigue para establecer una solucin robusta, probarlo y estableci-blecer el
nivel apropiado de documentacin.

Un anlisis de riesgos de los sistemas operativos se debe realizar con el fin de establecer qu funciones o
programas constituyen el mayor riesgo para los servicios de pera-cional en caso de desastre. A continuacin,
se establece - en el caso de las funciones de riesgo - los cuales (de prueba) las acciones se deben realizar si se
produce una mala funcin en particular. Existen varios tipos de mal funcionamiento pueden ser identificados y
hay

diversas formas de responder a ellos para cada funcin en riesgo.Una posible reac-cin puede ser que una
funcin relevante en riesgo siempre debe ser probado, o que, en ciertas circunstancias, la prueba podra
ser realizada, en retrospectiva (el da siguiente, por ejemplo). Si se decide que una funcin particular en
riesgo siempre se debe probar siempre que sea pertinente, una serie de pruebas normalizadas, lo cual
podra ser exe-recortado casi inmediatamente, debe estar preparado para este fin. Las pruebas estndar,
obviamente, seran preparados y mantenidos de acuerdo con el enfoque de la prueba estruc-rado.

Incluso en el caso de modificaciones ad-hoc, por lo que es posible lograr una mejora en la calidad
mediante la adopcin de un enfoque de la prueba especfica. Es importante hacer un anlisis de riesgos
completo del sistema y especificar un conjunto de pruebas estndar en consecuencia.

Repaso Captulo

Vamos a repasar lo que ha aprendido en este captulo.

De la Seccin 2.1, que ahora debe entender la relacin entre el desarrollo y las pruebas dentro
de un ciclo de vida de desarrollo, incluyendo las actividades de prueba y productos de prueba (de
trabajo). Usted debe saber que el modelo de desarrollo a utilizar debe encajar, o si debe ser
adaptado para ajustarse a las caractersticas del proyecto y del producto. Usted debe ser capaz de
recordar las razones de los diferentes niveles de las pruebas y las caractersticas de una buena
prueba en cualquier modelo de ciclo de vida. Usted debe conocer los trminos del glosario
(comerciales) off-the-shelf software (COTS), modelo de desarrollo incremental, a nivel de
prueba, validacin, verificacin y V-modelo.

De la Seccin 2.2, usted debe saber los niveles tpicos de la prueba. Usted debe ser capaz de
comparar los diferentes niveles de pruebas con respecto a sus principales objetivos, objetos
tpicos de las pruebas, los objetivos tpicos de las pruebas (por ejemplo, funcional o estructural)
y productos de trabajo relacionados. Tambin debe saber lo que las personas llevan a cabo las
actividades de control en los diferentes niveles de la prueba, los tipos de defectos encontrados y
fracasos a ser identificados. Usted debe saber el glosario de trminos alfa las pruebas, las
pruebas beta, pruebas de componentes, conductor, requisitos funcionales, integracin,
pruebas de integracin, pruebas no funcionales, pruebas de funcionamiento, regulacin de
las pruebas de aceptacin (pruebas de cumplimiento), las pruebas de robustez, trozo, las
pruebas del sistema, desarrollo basado en pruebas, entorno de prueba y Pruebas de
aceptacin del usuario.

De la Seccin 2.3, usted debe saber los cuatro tipos principales de prueba (funcionales, no
funcionales, estructurales y cambio- relacionada) y debe ser capaz de proporcionar algunos
ejemplos concretos para cada uno de estos. Usted debe entender que las pruebas funcionales y
estructurales se producen en cualquier nivel de la prueba y ser capaz de explicar cmo se aplican
en los distintos niveles de la prueba. Usted debe ser capaz de identificar y describir los tipos de
ensayo no -Funcional basado en los requisitos no funcionales y las caractersticas de calidad del
producto. Por ultimo, debe ser capaz de explicar el propsito de las pruebas de confirmacin
(repeticin de pruebas) y pruebas de regresin en el contexto de las pruebas relacionadas con el
cambio. Usted debe saber los trminos del glosario de pruebas de recuadro negro, la
cobertura de cdigo, las pruebas de confirmacin (re-prueba), pruebas funcionales,
pruebas de interoperabilidad, pruebas de carga, pruebas de mantenimiento, pruebas de
rendimiento, portabilidad de pruebas, pruebas de regresin, pruebas de fiabilidad, pruebas
de seguridad, las pruebas basadas en las especificaciones, las pruebas de estrs, pruebas
estructurales, prueba privado, las pruebas de usabilidad y pruebas de caja blanca

De la Seccin 2.4, usted debe ser capaz de comparar las pruebas de mantenimiento a prueba
de nuevas aplicaciones. Usted debe ser capaz de identificar los factores desencadenantes y las
razones de las pruebas de mantenimiento, tales como modificaciones, la migracin y la
jubilacin. Por ultimo, debe ser capaz de describir el papel de las pruebas de regresin y anlisis
de impacto dentro de las pruebas de mantenimiento. Usted debe saber las pruebas de anlisis de
trminos de impacto y mantenimiento glosario.

PREGUNTAS examen de la muestra

Pregunta 1 Cules son las buenas prcticas para las pruebas dentro del ciclo de vida de desarrollo?
a.

anlisis de la prueba y su diseo.

b. Diferentes niveles de prueba se definen con objetivos especficos.

c. Probadores comenzarn a involucrarse lo ms pronto

la codificacin se realiza.

d.

A y B anteriores.

Pregunta 2 Qu opcin describe mejor obje-tantes de los niveles de prueba con un modelo de ciclo de vida?

a. Los objetivos deben ser genrico para cualquier nivel de prueba.

b.

Los objetivos son los mismos para cada nivel de prueba.

c. Los objetivos de un nivel de prueba no tienen que ser definidos de antemano.

d. Cada nivel tiene objetivos especficos a ese nivel.

Pregunta 3 Cul de los siguientes es un tipo de prueba?

a.

pruebas de componentes

b.

pruebas funcionales

c.

Prueba del sistema

d.

Pruebas de aceptacin

Pregunta 4 Cul de las siguientes es una caracterstica de calidad no funcional?

a.

Viabilidad

b.

Usabilidad

c.

Mantenimiento

d.

Estadsticas de

Pregunta 5 Cul de estos es una prueba funcional?

a. La medicin de tiempo de respuesta en una reserva on line

S.

b. Comprobacin del efecto de grandes volmenes de trfico en

un sistema de centro de llamadas.

c.

Comprobacin de la reservas on-line de infor macin pantalla y el contenido de bases de datos en

contra de la infor
macin sobre la carta a los clientes.

d.

Comprobar qu fcil es el sistema de usar.

Pregunta 6 Cul de los siguientes es una declaracin verdadera con respecto al proceso de fijacin de
los cambios de emergencia?

a. No hay tiempo para probar el cambio antes de que entre en vigor, por lo que slo los mejores
desarrolladores deben hacer
este trabajo y no deben implicar a los probadores como se

ralentizar el proceso.

b. Slo tiene que ejecutar la segunda prueba del defecto realidad fija.
c. Siempre ejecutar una prueba de regresin completa de todo el sistema en el caso de otras partes
del sistema han sido afectados de manera adversa.

d. Vuelva a probar la zona cambiada y luego utilizar la evaluacin para decidir sobre un
subconjunto razonable de
toda la prueba de regresin se ejecute en caso de que otras partes del sistema han sido afectados de
manera adversa.

Pregunta 7 Una prueba de regresin:

a.

Es slo se ejecutan una vez.

b.

Siempre ser automatizado.

c.

Revisar las reas no modificadas del software para ver si han sido afectados.
d. Revisar las reas modificados del software para ver

si han sido afectados.

Pregunta 8 Ensayos no funcional incluye:

a. La prueba para ver donde el sistema hace la no func correctamente.

b. Prueba de los atributos de calidad del sistema

incluyendo la fiabilidad y facilidad de uso.

c.

Obtener la aprobacin del usuario para el sistema.

d. Prueba de una caracterstica del sistema utilizando slo el software

requerido para esa funcin.

Pregunta de prueba de 9 Beta es:

a.

Realizado por los clientes en su propio sitio.

b. Realizado por los clientes en el sitio del software de desa oper.

c.

Realizado por un equipo de pruebas independiente.

d. til para probar el software desarrollado para una especfica

cliente o usuario.

CAPTULO TRES

tcnicas estticas

Tcnicas de pruebas
Tatic constituyen una forma eficaz de mejorar la calidad y la productividad de
software desarrollo.En este captulo se describen las tcnicas de verificacin esttica, incluyendo opiniones y
proporciona una visin general de la forma en que se llevan a cabo. El objetivo fundamental de una prueba
esttica es mejorar la calidad de los productos de trabajo de software, ayudando a los ingenieros para reconocer
y corregir sus propios defectos temprano en el proceso de desarrollo de software. Si bien las tcnicas de
pruebas estticas no va a resolver todos los problemas, que son enormemente eficaz. tcnicas estticas pueden
mejorar tanto la calidad como la productividad por factores impresionantes. pruebas estticas no es magia y no
debe ser considerado como un reemplazo para la prueba dinmica, pero todas las organizaciones de software
debera considerar el uso de las opiniones en todos los aspectos principales de su trabajo incluyendo los
requisitos, diseo, implementacin, pruebas y mantenimiento. herramientas de anlisis esttico implementan

controles automticos, por ejemplo en cdigo.

3.1 COMENTARIOS Y EL PROCESO DE PRUEBA

1
Reconocer los productos de trabajo de software que pueden ser
examinadas por diferentes tcnicas estticas.{0}k = 0.015 L{/0}{1}1{/1}
2 Describir la importancia y el valor de considerar tcnicas estticas para
la evaluacin de los productos de trabajo de software.(k)

3 Explicar la diferencia entre las tcnicas estticas y dinmicas.(k)

En el captulo 1, se presentaron varios trminos de prueba.Tambin prueba en s se defini. La ltima

definicin se repite aqu como medio para explicar los dos tipos principales de la prueba.

La definicin de las pruebas se describen los objetivos que se relacionan con la evaluacin, que revela
los defectos y calidad. Como se indica en la definicin dos enfoques se pueden utilizar para lograr estos
objetivos, las pruebas estticas y dinmicas de prueba.

Con los mtodos de prueba dinmicos, software se ejecuta utilizando un conjunto de valores de entrada
y luego se examin su produccin y se compara con lo que se espera. Durante la prueba esttica,
productos de trabajo de software se examina de forma manual o con un conjunto de herramientas, pero no
ejecutados. Como consecuencia, la prueba dinmica slo se puede aplicar al cdigo de software.
ejecucin dinmica se aplica como una tcnica para detectar

defectos y para determinar los atributos de calidad del cdigo.Esta opcin de prueba no es aplicable para
la mayora de los productos de trabajo de software. Entre los ques-ciones que surgen son: Cmo
podemos evaluar o analizar un documento de requisitos, un documento de diseo, un plan de pruebas, o
un manual de usuario? Cmo podemos efectivamente pre-examinar el cdigo fuente antes de la
ejecucin? Una tcnica poderosa que se puede utilizar es la prueba esttica, por ejemplo, una revisin.
En principio, todos los productos de trabajo de software se pueden probar usando tcnicas de revisin.

Las pruebas dinmicas y pruebas estticas son mtodos complementarios, ya que tienden a encontrar
diferentes tipos de defectos de forma eficaz y eficiente. Tipos de defectos que son ms fciles de
encontrar durante las pruebas estticas son: desviaciones de las normas, requisitos faltantes, defectos de
diseo, cdigo e interfaz inconsistente especificaciones no tienen mantenimiento. Tenga en cuenta que en
contraste con las pruebas dinmicas, pruebas estticas encuentra defectos en lugar de fracasos.

Adems de los defectos que encuentran, los objetivos de las recomendaciones son a menudo tambin
informativo, comunicacional y educativo, en el que los participantes aprenden sobre el contenido de los
productos de trabajo de software para ayudarles a entender el papel de su propio trabajo y para planificar
futuras etapas de desarrollo. Los comentarios a menudo representan los hitos del proyecto, y apoyar el
establecimiento de una lnea de base para un producto de software. El tipo y la cantidad de defectos
encontrados durante las revisiones tambin puede ayudar a los probadores centran su prueba y seleccionar
las clases efectivas de pruebas. En algunos casos, los clientes / usuarios asisten a la reunin de revisin y
proporcionan retroalimentacin al equipo de desarrollo, por lo que las recomendaciones son tambin un
medio de comunicacin con el cliente / usuario.

Los estudios han demostrado que, como resultado de los exmenes, un aumento significativo en proproductividad y la calidad del producto se puede lograr [Gilb y Graham, 1993], [van Veenendaal, 1999].
La reduccin del nmero de defectos tempranos en el ciclo de vida del producto tambin significa que
menos tiempo tiene que ser gastado en pruebas y mantenimiento. En resumen, el uso de pruebas estticas,
por ejemplo, comentarios, sobre los productos de trabajo de software tiene varias ventajas:

Dado que las pruebas estticas puede comenzar temprano en el ciclo de la vida, la
retroalimentacin temprana de problemas de calidad se puede establecer, por ejemplo, una validacin
temprana de necesidades de los usuarios y no slo al final del ciclo de vida durante las pruebas de
aceptacin.

Mediante la deteccin de defectos en una etapa temprana, trabajo de repaso costes son ms a
menudo relativamente bajo y por lo tanto se puede lograr una mejora relativamente barato de la
calidad de los pro- ductos de software.

Desde la reanudacin esfuerzo se reduce sustancialmente, las cifras de productividad de desarrollo

es probable que aumenten.

La evaluacin por un equipo tiene la ventaja adicional de que se produce un intercambio de

informacin entre los participantes.

Pruebas estticas contribuyen a una mayor concienciacin de los problemas de calidad.

En conclusin, las pruebas estticas es un mtodo muy adecuado para la mejora de la calidad de los
productos de trabajo de software. Esto se aplica principalmente a los propios productos evaluados, pero

tambin es importante que la mejora de la calidad no se logra una vez, pero tiene un carcter ms
estructural. La retroalimentacin del proceso de pruebas estticas para el proceso de desarrollo permite la
mejora de los procesos, lo que permite evitar los errores similares se estn realizando en el futuro.

proceso de revisin.

1 Recordemos las fases, funciones y responsabilidades de una revisin tpica formal.

{0}k = 0.015 L{/0}{1}1{/1}

2 Explicar las diferencias entre los diferentes tipos de revisin: informal

revisin, revisin tcnica, paso a paso y la inspeccin. (k)

3 Explicar los factores para el desempeo exitoso de comentarios.(k)

Opiniones varan desde muy informal al formal (es decir, bien estructurado y regulado).A pesar de que la
inspeccin es quizs la revisin tcnico-nique ms documentado y formal, desde luego, no es el nico. La
formalidad de un proceso de revisin est relacionada con factores como la madurez del proceso de desarrollo,
los requisitos legales o reglamentarias, o la necesidad de una pista de auditora. En la prctica, la revisin
informal es quizs el tipo ms comn de revisin. revisiones informales se aplican en varias ocasiones durante
las primeras etapas del ciclo de vida de un documento. Un equipo de dos personas puede llevar a cabo una
revisin informal, como el autor puede pedir a un col-liga para revisar un documento o cdigo. En etapas
posteriores, estas revisiones involucran a ms personas y una reunin. Esto normalmente implica colegas del
autor, que tratan de encontrar defectos en el documento sometido a examen y discutir estos defectos en una
reunin de revisin. El objetivo es ayudar a los autores y al mejorar la calidad del documento. revisiones
informales vienen en varios tamaos y formas, pero todas tienen una caracterstica en comn - que no estn
documentadas.

3.2.1 Fases de una revisin formal

En contraste con revisiones informales, las revisiones formales siguen un proceso formal. Un proceso
tpico de revisin formal consta de seis pasos principales:

4. Planificar

1.5 Arranque

Preparacin

Reunin de Revisin,

Reproceso

Seguir

Planificacion

El proceso de revisin para una revisin en particular comienza con una "solicitud de revisin" por el autor para el
moderador (o lder de inspeccin).Un moderador a menudo se asigna a cuidar de la programacin (fechas, hora,
lugar y la invitacin) de la revisin. A nivel de proyecto, la planificacin del proyecto tiene que dar tiempo a las
actividades de revisin y retrabajo, proporcionando as a los ingenieros tiempo para participar a fondo en las
revisiones. Para ms formales, por ejemplo, inspecciones, el moderador siempre realiza una inspeccin de entrada y
define en esta etapa los criterios de salida formales. El control de entrada es

llevado a cabo para asegurar que el tiempo de los revisores no se desperdicia en un documento que no est
listo para su revisin.Un documento que contiene demasiados errores obvios no es claramente listo para entrar

en un proceso de revisin formal y que incluso podra ser muy perjudicial para el proceso de revisin. Sera
posiblemente de-motivar a los dos revisores y el autor. Adems, la revisin no es ms probable eficaz porque
los numerosos defectos obvios y menores sern ocultar los defectos importantes.

Aunque ms y otros criterios de entrada se pueden aplicar, lo siguiente puede ser considerado como
el mnimo establecido para la realizacin del control de entrada:

Un corto de verificacin de una muestra del producto por el moderador (o experto) no revela un
gran nmero de defectos importantes.Por ejemplo, despus de 30 minutos de cheques, de no ms de 3
defectos mayores que se encuentran en una sola pgina o menos de 10 de los principales defectos en
total en un conjunto de 5 pginas.

El documento para ser revisado est disponible con los nmeros de lnea.

El documento ha sido eliminado ejecutando ningn controles automticos que se aplican.

Las referencias necesarias para la inspeccin son estables y disponibles.

El autor del documento se prepara para unirse al equipo de revisin y se siente seguro con la
calidad del documento.

Si el documento pasa la comprobacin de la entrada, el moderador y autor deciden qu parte del

documento de revisin. Debido a que la mente humana puede com-prehend un conjunto limitado de
pginas a la vez, el nmero no debe ser demasiado alto. El nmero mximo de pginas depende, entre
otras cosas, del tipo objetivo, el tipo de examen y documento y debe derivarse de las experiencias cas-tico
dentro de la organizacin. Para una revisin, el tamao mximo es por lo general entre 10 y 20 pginas.
En inspeccin formal, solamente una o dos pginas puede ser visto en profundidad con el fin de encontrar
los defectos ms graves que no son obvias.

Despus de que el tamao del documento se ha establecido y las pginas que deben ser controlados
han sido seleccionados, el moderador determina, en cooperacin con el autor, la com-posicin del equipo
de revisin. El equipo consta normalmente de cuatro a seis partici-pantalones, incluyendo el moderador y
el autor. Para mejorar la eficacia de la revisin, diferentes roles se asignan a cada uno de los participantes.
Estas funciones ayudan a los revisores se centran en determinados tipos de defectos durante la

comprobacin.Esto reduce la posibilidad de diferentes revisores encontrar los mismos defectos. El

moderador asigna los roles a los colaboradores.

La Figura 3.1 muestra los diferentes roles dentro de una revisin. Los roles representan puntos de vista
del documento que se examina.

Dentro de opiniones los siguientes enfoques pueden ser identificados:

centrarse en los documentos de nivel superior, por ejemplo, el diseo no cumple con los
requisitos;

centrarse en las normas, por ejemplo, consistencia interna, la claridad, las convenciones de
nombres, plantillas;

centrarse en los documentos relacionados a un mismo nivel, por ejemplo, las interfaces entre las
funciones de soft ware;

se centran en el uso, por ejemplo, para la capacidad de prueba o de mantenimiento.

El autor puede aumentar las funciones y las preguntas que tienen que ser tratados especficos adicionales. El
moderador tiene la opcin de cumplir tambin un papel, junto con la tarea de ser un lder de opinin. Comprobacin
del documento mejora la capacidad del moderador para dirigir la reunin, ya que asegura una mejor comprensin.
Adems, mejora la eficiencia revisin porque el moderador sustituye a un ingeniero que otros en cuanto que revisar
el documento y asistir a la reunin. Se recomienda que el moderador tomar el papel de comprobar el cumplimiento
de las normas, ya que esto tiende a ser un papel muy objetivo, que conduce a una menor discusin de los defectos
encontrados.

Lanzamiento

Un paso opcional en un procedimiento de revisin es una reunin de lanzamiento. El objetivo de esta reunin
es conseguir que todos en la misma longitud de onda en relacin con el documento objeto de examen y de
comprometerse con el tiempo que se gasta en la comprobacin. Tambin el resultado de la inspeccin de
entrada y salida criterios definidos se discuten en el caso de una revisin ms formal. En general un saque de
salida es muy recomendable ya que hay un fuerte efecto positivo de una reunin de lanzamiento de la
motivacin de los colaboradores y por lo tanto la eficacia del proceso de revisin. En las instalaciones del
cliente, tenemos resultados meas-rado hasta un 70% ms defectos principales que se encuentran por pgina
como resultado de per-formando un saque inicial, [van Veenendaal y van der Zwan, 2000]

Durante la reunin de lanzamiento los revisores reciben una breve introduccin sobre los objetivos de
la revisin y los documentos. Las relaciones entre el doc-mento objeto de examen y los dems
documentos (fuentes) se explican, espe-cialmente si el nmero de documentos relacionados es alta.

Las asignaciones de funciones, porcentaje de control, las pginas que deben controlarse, tambin se
discuten posibles cambios en los procesos y otras preguntas durante esta reunin. Por supuesto, la distribucin
del documento objeto de examen, los documentos de origen y otra documentacin relacionada, tambin se
puede hacer durante el inicio del encuentro.

Preparacin

Los participantes trabajan individualmente en el documento que se examina el uso de los documentos
relacionados, procedimientos, reglas y listas de comprobacin. Los participantes individuales identificar
defectos, preguntas y comentarios, de acuerdo con su

comprensin del documento y el papel.Todos los temas estn grabados, preferiblemente mediante un
formulario de registro. Los errores ortogrficos se registran en el documento objeto de examen, pero que no se
mencionan en la reunin. El documento anotado ser entregado al autor al final de la sesin de registro. El uso
de listas de control durante esta fase puede hacer una revisin ms eficaz y eficiente, por ejemplo, una lista de
control especfico basado en perspectivas como usuario, mantenedor, probador u operaciones, o una lista de
control para problemas tpicos de codificacin.

Un factor crtico de xito para una preparacin exhaustiva es el nmero de pginas controladas por
hora. Esto se conoce como ndice de comprobacin. El porcentaje de control ptimo es el resultado de
una combinacin de factores, incluyendo el tipo de documento, su com-complejidad, el nmero de
documentos relacionados y la experiencia del revisor. Por lo general, el porcentaje de control est en el
intervalo de cinco a diez pginas por hora, pero puede ser mucho menos para inspeccin formal, por
ejemplo, una pgina por hora. Durante la preparacin, los participantes no deben exceder este criterio.
Mediante la recopilacin de datos y medir el proceso de revisin, los criterios especficos de la empresa
para el control de velocidad y el tamao del documento (ver fase de planificacin) se puede ajustar,
preferentemente especfico para un tipo de documento.

Reunin de Revisin,

La reunin consiste tpicamente en los siguientes elementos (en parte, en funcin del tipo de examen):
fase de registro, la fase de discusin y decisin de fase.

Durante la fase de registro de las cuestiones, por ejemplo, defectos, que han sido identificadas durante la
preparacin se mencionan pgina por pgina, revisor en el comentario y se registran ya sea por el autor o por un
escriba. Una persona separada para hacer el registro (un escriba) es especialmente til para este tipo de revisin
formales tales como una inspeccin-cin. Para asegurar el progreso y la eficiencia, no se permite ninguna discusin
real durante la fase de registro. Si un problema necesita discusin, el elemento se registra y luego se maneja en la
fase de discusin. Una discusin detallada sobre si es o no es un problema es un defecto no es muy significativo, ya
que es mucho ms eficiente que simplemente registre y proceder a la siguiente. Por otra parte, a pesar de la opinin
del equipo, un defecto dis-terco y se desecha bien puede llegar a ser una de verdad durante la reanudacin.

Cada defecto y su gravedad se van a registrar. El participante que identifica el defecto propone la
gravedad. los grados de severidad pueden ser:

Crticos: los defectos sern causar daos aguas abajo; el alcance y el impacto de la defecto est
ms all del documento bajo inspeccin.
Los principales defectos, podran causar un efecto aguas abajo (por ejemplo, un fallo en un diseo
puede como resultado un error en la aplicacin).
Menor de edad, los defectos no son susceptibles de causar daos aguas abajo (por ejemplo, no
Compli midad con las normas y plantillas). ,

Con el fin de mantener el valor aadido de las opiniones, errores de ortografa no son parte de la
clasificacin de defectos. defectos de ortografa se observan, por los participantes, en el documento que se
examina y se les da el autor al final de la reunin o podran tratarse en un ejercicio de correccin de
pruebas por separado.

Durante la fase de registro de la atencin se centra en capturar la mayor cantidad de defectos como sea
posible dentro de un plazo determinado. Para asegurar esto, el moderador intenta mantener una buena
velocidad de registro (nmero de defectos registrados por minuto). En una reunin de revisin formal
bien dirigida y plined disci, la frecuencia de registro debe estar entre uno y dos defectos registrados por
minuto.

Para una revisin ms formal, los aspectos clasificados como temas de discusin sern tratados durante
esta fase reunin.comentarios informales a menudo no tienen una fase de registro Sep-arate y comenzar
inmediatamente con la discusin. Los participantes pueden tomar parte en la discusin poniendo de
relieve sus comentarios y rea-envenenamien-. Como presidente de la reunin de la discusin, el
moderador se encarga de asuntos de la gente. Por ejemplo, el moderador evita discusiones de conseguir
demasiado personal, reformula observaciones si es necesario y pide un descanso para enfriar las
discusiones y / o participantes '' con calefaccin.

Revisores que no necesitan estar en la discusin pueden dejar, o mantenerse como un ejercicio de
aprendizaje. El moderador tambin se pasea esta parte de la reunin y se asegura de que todos los puntos
discutidos o bien tienen un resultado al final de la reunin, o se definen como un punto de accin si una
discusin no puede ser resuelto durante la reunin. El resultado de las discusiones se documenta para
referencia futura.

Al final de la reunin, una decisin sobre el documento objeto de examen tiene que ser hecha por los
participantes, a veces sobre la base de criterios de salida formales. El criterio de salida ms importante
es el nmero promedio de defectos crticos y / o principales que se encuentran por pgina (por ejemplo,
no ms de tres importantes defectos crticos / por pgina). Si el nmero de defectos encontrados por
pgina supera un cierto nivel, el documento debe ser revisado de nuevo, despus de que haya sido
modificada. Si el documento cumple con los criterios de salida, el documento ser revisado durante el
seguimiento por parte de la madre ator o uno o ms participantes. Posteriormente, el documento puede
salir del proceso de revisin.

Si un proyecto se encuentra bajo presin, el moderador veces se ver obligado a saltar nuevas
revisiones y salir con un documento defecto propensa. Configuracin, y acordar, criterios de nivel de
salida cuantificados ayuda al moderador para tomar decisiones firmes en todo momento.

Adems del nmero de defectos por pgina, otros criterios de salida se utilizan para medir los rigurosidad
del proceso de revisin, tales como asegurar que todas las pginas han sido revisados a la velocidad adecuada.
El nmero promedio de defectos por pgina slo es un indicador de la calidad vlida si se cumplen estos
criterios de proceso.

Reproceso

Sobre la base de los defectos detectados, el autor mejorar el documento que se examina paso a paso. No
todos los defectos que se encuentra conduce a volver a trabajar. Es responsabilidad del autor para juzgar
si un defecto tiene que ser fijo. Si no se hace nada acerca de un tema por alguna razn, se debe informar
al menos a indicar que el autor ha examinado la cuestin.

Los cambios que se realizan en el documento deben ser fciles de identificar durante el seguimiento.
Por lo tanto, el autor tiene que indicar dnde se realizan cambios (por ejemplo, utilizando el control de
cambios '' en el software de procesamiento de textos).

Seguimiento

El moderador es responsable de asegurar que las acciones satisfactorias han tenido en cuenta todos los
defectos (registrada), sugerencias de mejora de procesos y solicitudes de cambio. Aunque el moderador
controles para asegurarse de que el autor ha adoptado medidas sobre todos los defectos conocidos, no es
necesario que el moderador para verificar todas las correcciones en detalle. Si se decide que todos los
participantes revisarn el documento actualizado, el moderador se encarga de la distribucin y recoge

3.075.000

las votaciones. Para ms tipos de revisin formal de los controles moderador compli-ANCE a los
criterios de salida.

Con el fin de controlar y optimizar el proceso de revisin, una serie de mtricas mentos son recogidos
por el moderador en cada paso del proceso. Ejemplos de tales medidas incluyen el nmero de defectos
encontrados, nmero de defectos detectados por pgina, el tiempo dedicado a la comprobacin por
pgina, el esfuerzo total de examen, etc. Es la responsa-bilidad del moderador para asegurarse de que la
informacin es correcta y se almacena para su posterior anlisis .

Roles y Responsabilidades

Los participantes en cualquier tipo de revisin formal debe tener conocimientos adecuados del proceso de
revisin. La mejor y ms eficiente, situacin crtica se produce cuando los participantes a obtener algn
tipo de ventaja para su propio trabajo durante la revisin-cin. En el caso de una inspeccin o revisin
tcnica, los participantes deben haber sido debidamente formado para ambos tipos de revisin han
demostrado ser mucho menos xito-ful sin participantes formados. De hecho, esto se percibe como un
factor crtico de xito.

Los mejores comentarios formales provienen de equipos bien organizados, guiados por los
moderadores capacitados (o lderes de opinin). Dentro de un equipo de revisin, cuatro tipos de
participantes se pueden distinguir: moderador, autor, escriba y revisor. Adems hombre-gestin tiene que
desempear un papel en el proceso de revisin.

el moderador

El moderador (o lder de opinin) conduce el proceso de revisin. l o ella disuadir-minas, en

cooperacin con el autor, el tipo de revisin, el enfoque y la composicin del equipo de revisin. El
moderador realiza la comprobacin de la entrada y el seguimiento de la repeticin del trabajo, con el fin
de controlar la calidad de la entrada y la salida del proceso de revisin. El moderador tambin los
horarios de la reunin, difunde los documentos antes de la reunin, entrenadores otros miembros del
equipo, marca el ritmo del encuentro, conduce posibles discusiones y almacena los datos que se recogen.

{0}{/0} {1}El Autor 2012.{/1}

Como el autor del documento que se examina, objetivo bsico del autor debe ser aprender tanto como
sea posible en lo que respecta a la mejora de la calidad del documento, sino tambin para mejorar su
capacidad de escribir documentos futuros. La tarea del autor es iluminar zonas poco claras y comprender
los defectos encontrados.

el escriba

Durante la reunin de la tala, el escriba (o grabadora) tiene que registrar cada defecto mencionados y
cualquier sugerencia para la mejora de procesos.En la prctica es a menudo el autor que juega este papel,
asegurndose de que el registro se puede leer y entender-poder. Si los autores registran sus propios defectos, o
al menos tomar sus propias notas en sus propias palabras, se les ayuda a comprender mejor el registro durante
el retrabajo. Sin embargo, tener a alguien que no sea el autor tomar el papel del escriba (por ejemplo, el
moderador) puede tener ventajas significativas, ya que el autor se libera a pensar en el documento en lugar de
estar atado con una gran cantidad de escritura.

los revisores

La tarea de los revisores (tambin llamadas damas o inspectores) es comprobar cualquier material en busca de
defectos, sobre todo antes de la reunin. El nivel de rigor requerido depende del tipo de revisin. El nivel de

conocimiento del dominio o pericia tecnologa-nica necesaria por los revisores tambin depende del tipo de revisin.
Los revisores deben ser elegidos para representar diferentes perspectivas y roles en el proceso de revisin. Adems
del documento objeto de examen, los materiales de revisin-res reciben incluye documentos de origen, normas,
listas de control, etc. En general, cuanto menor fuente y documentos de referencia proporcionado, se necesita ms
experiencia en el campo con respecto al contenido del documento que se examina.

- El gerente.

El gerente est implicado en los comentarios ya que l o ella decide sobre la ejecucin de los exmenes,
asigna tiempo en los programas del proyecto y determina si se han cumplido los objetivos del proceso de
revisin. El gerente tambin se har cargo de ningn tipo de formacin examen solicitado por los
participantes. Por supuesto, un administrador tambin puede estar implicado en la propia revisin en
funcin de sus antecedentes, que juega el papel de un revisor si esto sera de gran ayuda.

3.2.3 Tipos de opinin

Un solo documento puede ser objeto de ms de una revisin. Si se utiliza ms de un tipo de revisin, el
orden puede variar. Por ejemplo, una revisin informal puede llevarse a cabo antes de una revisin
tcnica, o la inspeccin puede llevarse a cabo en una especificacin de requisitos antes de que un tutorial
con los clientes. Es evidente que ninguno de los siguientes tipos de revisin es el "ganador", pero los tipos
dif rentes sirven para diferentes propsitos en diferentes etapas del ciclo de vida de un documento.

Los principales tipos de examen, sus principales caractersticas y objetivos comunes se describen a
continuacin.

Tutorial

Un tutorial se caracteriza por el autor del documento que se examina guiando a los participantes a travs
de la sus procesos de pensamiento documento y, para lograr un entendimiento comn y el intercambio de
ideas.Esto es especialmente til si la gente de fuera de la disciplina de software estn presentes, que no
estn acostumbrados a, o no se puede entender fcilmente documentos de desarrollo de software. El
contenido del documento se explica paso a paso por el autor, para llegar a un consenso sobre los cambios
o para reunir informacin.

Dentro de un paso a paso el autor hace la mayor parte de la preparacin. Los partici-pantalones, que son
seleccionados a partir de diferentes departamentos y fondos, no estn obligados a hacer un estudio detallado de
los documentos con antelacin. Debido a la forma en que la reunin se estructura, un gran nmero de personas
pueden participar y este pblico ms amplio puede traer un gran nmero de diversos puntos de vista en
relacin con el contenido del documento que est siendo revisado, adems de servir un propsito educativo. Si
el pblico representa una amplia muestra de las habilidades y disci-plinas, puede dar la seguridad de que no
hay defectos importantes se 'perdieron' en el recorrido. Un tutorial es especialmente til para los documentos
de nivel superior, tales como especificaciones de requisitos y documentos arquitectnicos.

Los objetivos especficos de un recorrido dependen de su papel en la creacin del documento.En

general los siguientes objetivos pueden ser aplicables:

para presentar el documento a las partes interesadas, tanto dentro como fuera de la disciplina
mercancas suaves, con el fin de recopilar informacin sobre el tema en la documentacin;

para explicar (transferencia de conocimientos) y evaluar el contenido del docu mento;

para establecer un entendimiento comn del documento;

para examinar y discutir la validez de las soluciones propuestas y la viabilidad de las alternativas,
establecer un consenso.

Las caractersticas clave de los recorridos son:

El encuentro est dirigido por los autores; menudo un escriba separada est presente.

Escenarios y carreras seco pueden ser usados para validar el contenido.

Separar la preparacin previa al encuentro de los colaboradores es opcional.

Revisin tcnica

Una revisin tcnica es una reunin de la discusin que se centra en el logro de con-senso sobre el
contenido tcnico de un documento.En comparacin con INSPEC-nes, revisiones tcnicas son menos
formales y hay poco o ningn nfasis en la identificacin de defectos sobre la base de los documentos
referenciados, destinados lectura lide- y reglas. Durante las revisiones tcnicas se han observado defectos
por los expertos, que se centran en el contenido del documento. Los expertos que se necesitan para una
revisin tcnica son, por ejemplo, arquitectos, jefes de diseo y usuarios clave. En la prctica, las
revisiones tcnicas varan de bastante informal a formal.

Los objetivos de una revisin tcnica son los siguientes:

evaluar el valor de los conceptos tcnicos y alternativas en el entorno del producto y del proyecto;

establecer una coherencia en el uso y la representacin de los conceptos tcnicos;

garantizar, en una primera fase, que los conceptos tcnicos se utilizan correctamente;

informar a los participantes sobre el contenido tcnico del documento.Las

caractersticas clave de una revisin tcnica son:

Es un proceso de deteccin de defectos documentado que consiste en pares y expertos tcnicos.

A menudo se lleva a cabo como una revisin por pares y sin gestin de par ticipacin.

Lo ideal es que est dirigido por un moderador capacitado, pero posiblemente tambin por un
experto tcnico.

Una preparacin separada se lleva a cabo durante el cual el producto se examina y se encuentran
los defectos.

 Ms caractersticas formales tales como el uso de listas de verificacin y una lista de registro o
asunto de registro son opcionales.

Inspeccin

La inspeccin es el tipo ms formal de revisin.El documento bajo inspeccin es redactada y revisada a

fondo por los revisores antes de la reunin, compar-cin del producto de trabajo con sus fuentes y otros
documentos de referencia, y el uso de reglas y listas de control.En la reunin de la inspeccin de los
defectos encontrados son registrados y cualquier discusin se pospone hasta la fase de discusin. Esto
hace que la inspeccin del cumplimiento de una reunin muy eficiente.

La razn para llevar a cabo las inspecciones puede explicarse mediante el uso de Weinberg concepto de
ingeniera sin ego [Weinberg, 1971]. Weinberg se refiere a la tendencia humana a acciones auto-justificar. Ya
que tienden a no ver la evidencia que est en conflicto con nuestras creencias fuertes, nuestra capacidad de
encontrar errores en nuestro propio trabajo resulta afectada. Debido a esta tendencia, muchas organizaciones de
ingeniera han establecido grupos de pruebas independientes que se especializan en la bsqueda de defectos.
Principios similares se han llevado a la introduccin de las inspecciones y revisiones en general.

Dependiendo de la organizacin y los objetivos de un proyecto, las inspecciones pueden ser

equilibrados para servir a una serie de objetivos. Por ejemplo, si el tiempo de salida al mercado es
extremadamente importante, el nfasis en las inspecciones ser la eficiencia. En un mercado crtico para
la seguridad, la atencin se centrar en la efectividad.

Los objetivos generalmente aceptados de la inspeccin son los siguientes:

ayudar al autor a mejorar la calidad del documento objeto de la inspeccin;

eliminar los defectos de manera eficiente, lo ms pronto posible;

mejorar la calidad del producto, mediante la produccin de documentos con un mayor nivel de
calidad;

 crear un entendimiento comn mediante el intercambio de informacin entre los participantes de

inspeccin;

capacitar a los nuevos empleados en el proceso de desarrollo de la organizacin;

aprender de los defectos encontrados y mejorar los procesos con el fin de evitar que se repiten
rencia de defectos similares;
degustar unas pocas pginas o secciones de un documento ms grande con el fin de medir la
calidad tpica del documento, lo que lleva a un mejor trabajo de las personas en el futuro, y para
mejoras de proceso.

Las caractersticas clave de una inspeccin son:

Por lo general, est dirigida por un moderador capacitado (desde luego no por el autor).

Utiliza las funciones definidas durante el proceso.

Se trata de pares para examinar el producto.

Reglas y listas de control se utilizan durante la fase de preparacin.

Una preparacin separada se lleva a cabo durante el cual el producto se examina y se encuentran
los defectos.

Los defectos encontrados se documentan en una lista de registro o registro de tema.

Un oficial de seguimiento se lleva a cabo por el moderador aplicando criterios de salida.


Opcionalmente, una etapa de anlisis causal se introdujo para hacer frente a problemas de
proceso de mejorar Ment y aprender de los defectos encontrados.

Las mtricas son recogidos y analizados para optimizar el proceso.

3.2.4 Factores de xito para las revisiones

La implementacin de comentarios (formal) no es fcil ya que no hay una manera de xito y hay numerosas
formas de fracasar. La siguiente lista contiene una serie de factores crticos de xito que mejoran las
posibilidades de xito en la aplicacin de opiniones. Su objetivo es responder a la pregunta: "Cmo se inicia
opiniones (formales)? '.

Encontrar un "campen"

Se necesita un campen, que conducir el proceso en un proyecto o nivel Organiza-cin.Necesitan

experiencia, entusiasmo y una mentalidad prctica con el fin de guiar a los moderadores y participantes.
La autoridad de este campen debe quedar claro para toda la organizacin. apoyo a la gestin tambin es
esencial para el xito. Ellos deben, entre otras cosas, incorporar un tiempo adecuado para las actividades
de revisin de los programas del proyecto.

Recoger las cosas que realmente cuentan

Seleccione los documentos de revisin que son ms importantes en un proyecto. La revisin de

documentos altamente crticos, aguas arriba como requisitos y arqui-tura con toda seguridad, mostrar los
beneficios del proceso de revisin para el proyecto. Estas horas de revisin invertidos tendrn un retorno
claro y alto de la inversin. Adems asegrese de que cada opinin tiene un claro objetivo y el tipo de
examen correcta es seleccionado que coincide con el objetivo definido. No tratar de revisar todo mediante
inspeccin; adaptarse a la opinin sobre el riesgo asociado con el docu-ment. Algunos documentos slo
pueden justificar una revisin informal y otros pagarn mediante inspeccin. Por supuesto, tambin es de
suma importancia que las personas adecuadas estn involucrados.

Explcitamente planificar y realizar un seguimiento de las actividades de revisin

Para asegurar que los exmenes se convierten en parte de las actividades del da a da, las horas que se
gasten los que debern ser visibles dentro de cada plan de proyecto. Los ingenieros implicados se les
solicita que programar el tiempo de preparacin y, muy impor-tante, hacer de nuevo. El seguimiento de
estas horas ser mejorar la planificacin de la prxima revisin. Como se dijo anteriormente, la gestin
juega un papel importante en la planificacin de las actividades de revisin.

Capacitar a los participantes

Es importante que se imparta formacin en tcnicas de revisin, especialmente las tcnicas ms formales,
como la inspeccin. De lo contrario es probable que se vea obstaculizado por aquellos que no entienden
el proceso y el razonamiento detrs de l el proceso. entrenamiento especial se debe proporcionar a los
moderadores para prepararlos para su papel fundamental en el proceso de revisin.

Resolver los problemas de la gente

Los comentarios son sobre la evaluacin del documento de alguien. Algunos comentarios tienden a ser
demasiado personal cuando no estn bien gestionados por el moderador. Personas cuestiones y aspectos
psicolgicos deben ser tratados por el moderador y deben ser parte de la formacin crtica, con lo que la
opinin de una experiencia positiva para el autor. Durante la revisin, los defectos deben ser bienvenidos
y se expresan de manera objetiva.

Siga las reglas, pero que sea sencillo

Siga todas las reglas formales hasta que sepa por qu y cmo modificarlos, pero hacer que el proceso slo
tan formal como la cultura del proyecto o nivel de madurez permite. No se convierta en demasiado
terica o demasiado detallada. Las listas de verificacin y los roles son reco-mienda para aumentar la
eficacia de la identificacin de defectos.

Mejorar continuamente procesos y herramientas

La mejora continua de los procesos y herramientas de apoyo (por ejemplo, listas de control), basado en
las ideas de los participantes, asegura la motivacin de los ingenieros involucrados. La motivacin es la
clave para un proceso de cambio con xito. Tambin debe haber un nfasis, adems de la bsqueda de
desertar, en el aprendizaje y mejora de procesos.

los resultados del informe

Informe cuantifica los resultados y beneficios para todos los involucrados tan pronto como sea posible, y
discutir las consecuencias de los defectos si no se haban encontrado tan temprano. Los costos deben ser
rastreados por supuesto, pero los beneficios, sobre todo cuando los problemas no se producen en el
futuro, deben hacerse visibles mediante la cuantificacin de los beneficios, as como los costos.

Solo hazlo!.

El proceso es simple pero no fcil. Cada paso del proceso es claro, pero se necesita expe-riencia para
ejecutarlos correctamente. Por lo tanto, tratar de conseguir que la gente con experiencia para observar y
ayudar en lo posible. Pero lo ms importante, empezar a hacer comentarios y empezar a aprender de cada
revisin.

3.3 Anlisis esttico por herramientas

1 Describir el objetivo del anlisis esttico y dinmico para compararlo

Pruebas (k)

2 Recordemos defectos tpicos identificados por el anlisis esttico y los

comparan con

crticas y pruebas dinmicas. {0}k = 0.015 L{/0}{1}1{/1}

3 Enumerar los beneficios tpicos de los analistas estticas.{0}k = 0.015 L{/0}{1}1{/1}

4 Enumerar los defectos de cdigo y diseo tpicos que se pueden identificar por la
esttica

Las herramientas de anlisis. {0}k = 0.015 L{/0}{1}1{/1}

Hay mucho por hacer el examen de los productos de trabajo de software sin ejecutar el sistema. Por ejemplo,
vimos en el apartado anterior que podemos revisar cuidadosamente los requisitos, diseos, cdigos, planes de
prueba y ms, para encontrar defectos y corregirlos antes de entregar un producto a un cliente. En esta seccin,
nos centramos en un tipo diferente de pruebas estticas, donde examinamos cuidadosamente los requisitos, los
diseos y el cdigo, por lo general con la asistencia automatizada para desentraar

defectos adicionales antes del cdigo real de ejecucin.Por lo tanto, lo que se llama esttica El anlisis
es ms que otra forma de prueba.

El anlisis esttico es un examen de los requisitos, el diseo y el cdigo que se diferencia de la prueba
dinmica ms tradicional en un nmero de maneras importantes:

El anlisis esttico se realiza sobre los requisitos, el diseo o cdigo sin ejecutar realmente el
artefacto software que est siendo examinada.

El anlisis esttico se realiza idealmente antes de que los tipos de revisin formal DIS discute en
la Seccin 3.2.

El anlisis esttico no est relacionado con las propiedades dinmicas de los requisitos, el diseo y
el cdigo, como la cobertura de la prueba.

 El objetivo del anlisis esttico es encontrar defectos, sean o no pueden causar fallos.Como con las
crticas, el anlisis esttico encuentra defectos en lugar de fracasos.

Para el anlisis esttico hay muchas herramientas, y la mayora de ellos se centran en cdigo de software. herramientas de anlisis esttico suelen ser utilizados por los desarrolladores antes, ya veces
durante, componentes y pruebas de integracin y por diseadores durante el modelado de software. Las
herramientas pueden mostrar no slo los atributos estructurales (mtricas de cdigo), como la
profundidad del nmero de anidacin o ciclomtica y comprobar los estndares de codificacin, sino
tambin representaciones grficas de flujo de control, las relaciones de datos y el nmero de caminos
distintos desde una lnea de cdigo a otro . Incluso el compilador puede ser considerada como una
herramienta de anlisis esttico, ya que construye una tabla de smbolos, seala un uso incorrecto y
comprueba si no compli-ANCE para que codifican las convenciones del lenguaje (sintaxis).

Una de las razones para utilizar el anlisis esttico (estndares de codificacin y similares) est
relacionada con las caractersticas de los lenguajes de programacin en s. Uno puede pensar que los
idiomas son seguros de usar, ya que al menos el comit stan-nor- sabe dnde estn los problemas. Pero
esto sera un error. Agregando a los agujeros dejados por el proceso de normalizacin, los programadores
con-continuar reportar caractersticas de la lengua, que aunque bien definido, conduce a modos de fallo
reconocibles. A finales de la dcada de 1990, aproximadamente 700 de estos problemas adicionales
haban sido identificados en el estndar C. Ahora est claro que existen tales modos de fallo. Se puede
demostrar que con frecuencia escapan al escrutinio de la prueba dinmica convencional, terminando en
productos comer- ciales-. Estos problemas se pueden encontrar mediante el uso de herramientas de
anlisis esttico para detectarlas. De hecho, muchos de los modos de fallo 700 reportados en C se pueden
detectar de esta manera! En un programa tpico de C, hay un promedio de aproxi-madamente ocho tales
faltas por cada 1.000 lneas de cdigo fuente; que estn incrustados en el cdigo publicado, a la espera de
hacer que el cdigo para fallar [Hatton, 1997]. Las pruebas dinmicas simplemente no detect ellos. C no
es el culpable aqu; este ejercicio puede llevarse a cabo para otros idiomas con ampliamente los mismos
resultados. Todos los lenguajes de programacin tienen problemas y los programadores no pueden asumir
que estn protegidos contra ellos. Y nada en el proceso Interna-cional actual de las lenguas de
normalizacin ser evitar que esto suceda en el futuro.

Las diversas caractersticas de las herramientas de anlisis esttico se discuten a continuacin, con un
enfoque especial hacia las herramientas de anlisis de cdigo esttico, ya que estos son los ms comunes
en la prctica del da a da. Tenga en cuenta que las herramientas de anlisis esttico analizan cdigo de
software, as como la salida generada como HTML y XML.

{2}Normas de codificacin{/2}

Comprobacin de la adherencia a los estndares de codificacin es sin duda la ms conocida de todas las
caractersticas. La primera accin a realizar es definir o adoptar una codificacin de stan-dard. Por lo general,

un estndar de codificacin consiste en un conjunto de reglas de programacin (por ejemplo 'Compruebe

siempre los lmites de un array cuando se copia a la matriz '), las convenciones de nomenclatura (por
ejemplo'Las clases deben comenzar con ESPECIFICA-ciones de capital C) y de la disposicin (por ejemplo
'Guin 4 espacios '). Se recomienda que se adopten las normas existentes. La principal ventaja de esto es que
se ahorra una gran cantidad de esfuerzo. Una razn adicional para la adopcin de este enfoque es que si se
toma un conocido de codificacin stan-dard es probable que haya herramientas disponibles que soportan este
estndar de cheques. Incluso se puede poner al revs: la compra de un analizador de cdigo esttico y declarar
(una seleccin de) las reglas en l como su norma de codificacin. Sin esas herramientas, es probable que falle
la aplicacin de un estndar de codificacin en una organizacin. Hay tres causas principales para esto: el
nmero de reglas en un estndar de codificacin suele ser tan grande que nadie puede recordar a todos ellos;
algunas reglas sensibles al contexto que exigen una revisin de varios archivos son muy difciles de comprobar
por los seres humanos; y si la gente pasa tiempo revisando los estndares de codificacin en los exmenes, que
se distraiga de otros defectos que de otro modo podran, por lo que el proceso de revisin sea menos eficaz.

3.3.2 mtricas de cdigo

Como se ha indicado, al realizar el anlisis de cdigo esttico, por lo general la informacin se calcula
sobre los atributos estructurales del cdigo, como comentario fre-cuencia, la profundidad de, el nmero y
el nmero de lneas de cdigo ciclomtica anidacin. Esta informacin se puede calcular no slo como se
crean el diseo y el cdigo, sino tambin como se realizan cambios en un sistema, para ver si el diseo o
el cdigo es cada vez ms grande, ms complejo y ms difcil de entender y mantener. Las mediciones
tambin nos ayudan a decidir entre varias alternativas de diseo, especialmente cuando el rediseo de las
porciones de cdigo existente.

Hay muchos tipos diferentes de medidas estructurales, cada uno de los cuales nos dice algo sobre el
esfuerzo necesario para escribir el cdigo en primer lugar, para entender el cdigo de la hora de hacer un
cambio, o para probar el cdigo utilizando herramientas o tcnicas particu-lar.

Los programadores con experiencia saben que el 20% del cdigo har que el 80% de los problemas, y
el anlisis de la complejidad ayuda para encontrar que lo ms importante 20%, que se refieren de nuevo
al principio de la agrupacin defecto como se explica en el Captulo 1. Mtricas de complejidad
identificar zonas de alto riesgo complejas.

La mtrica de complejidad ciclomtica se basa en el nmero de decisiones en un programa.Es

importante probadores, ya que proporciona una indicacin de la cantidad de pruebas (incluyendo
revisin) necesario para evitar prcticamente defectos. En otras palabras, las reas identificadas como de
cdigo ms complejo son can-can- para revisiones y pruebas dinmicas adicionales. Si bien hay muchas
maneras de calcular la complejidad ciclomtica, la forma ms fcil es para sumar el nmero de
declaraciones de decisiones binarias (por ejemplo, si, mientras que, por, etc.) y se aade 1 a la misma.
Una definicin ms formal con respecto a las reglas de clculo se proporciona en el glosario.

A continuacin se muestra un programa simple como un

ejemplo:
Si una
Entonces, si B> C
Entonces A = B
ELSE A = C
[endif]
[endif]
Una de impresin
El flujo de control generada por el programa podra verse como la Figura 3.2.

El flujo de control muestra siete nodos (formas) y ocho bordes (lneas), por lo tanto con la
frmula oficial es la complejidad ciclomtica 8-7 + 2 = 3. En este caso no hay grfico llamado o
subrutina. Alternativamente, se puede calcular la complejidad ciclomtica utilizando la regla de
los puntos de decisin. Puesto que hay dos puntos de decisin, la complejidad ciclomtica es 2 +
1 = 3.

3.3.3 estructura de Cdigo

Hay muchos tipos diferentes de medidas estructurales, cada uno de los cuales nos dice algo sobre
el esfuerzo necesario para escribir el cdigo en primer lugar, para entender el cdigo de la hora
de hacer un cambio, o para probar el cdigo utilizando herramientas o tcnicas particulares. A
menudo se supone que un mdulo grande requiere ms tiempo para especificar, diseo, cdigo y
prueba de que una ms pequea. Pero, de hecho, la estructura del cdigo juega un papel
importante. Hay varios aspectos de la estructura del cdigo a tener en cuenta:

estructura de flujo de control;

estructura de flujo de datos;

estructura de datos.

La estructura de flujo de control se dirige a la secuencia en la que se ejecutan las

instrucciones. Este aspecto de la estructura refleja las iteraciones y bucles en el diseo de un
programa. Si se mide slo el tamao de un programa, no se proporciona informacin sobre la
frecuencia con la que se ejecuta una instruccin que se ejecuta. anlisis de flujo de control
tambin puede ser usado para identificar cdigo inalcanzable (muertos). De hecho muchas de las
mtricas de cdigo se refieren a la estructura de flujo de control, por ejemplo, nmero de niveles
anidados o complejidad ciclomtica.

Estructura de flujo de datos sigue la estela de un elemento de datos, ya que se accede y mod-cado por
el cdigo.Muchas veces, las transacciones aplicadas a los datos son ms complejas que las instrucciones
que los desarrollen. Por lo tanto, el uso de medidas de flujo de datos se muestra como la Ley de datos a
medida que se transforman por el programa. Los defectos pueden ser encontrados como referencia a una
variable con un valor indefinido y variables que no se utilizan nunca.

estructura de datos se refiere a la organizacin de los datos en s, independiente del programa. Cuando
los datos se organiza como una lista, cola, pila, u otra estructura bien definida, los algoritmos para la
creacin, modificacin o supresin de ellas son ms propensos a ser bien definido, tambin. Por lo tanto,
la estructura de datos proporciona una gran cantidad de informa-cin acerca de la dificultad de escribir
programas para manejar los datos y en el diseo de casos de prueba para demostrar la correccin del
programa. Es decir, a veces un programa es complejo, ya que tiene una estructura de datos compleja, en
lugar de a causa de control complejo o flujo de datos.

Lo importante para el probador es ser consciente de que las medidas de anlisis esttico antes
mencionados se pueden utilizar como seales de alerta temprana de lo bueno que es probable que sea
cuando se acaba el cdigo.

En resumen, el valor del anlisis esttico es especialmente para:

la deteccin temprana de defectos antes de probar la ejecucin;

alerta temprana sobre aspectos sospechosos del cdigo, diseo o los requisitos;

identificacin de defectos que no se encuentran fcilmente en las pruebas dinmicas;

mantenimiento mejorado de cdigo y diseo ya que los ingenieros trabajar de acuerdo a las
normas y reglas documentados;

la prevencin de defectos, a condicin de que los ingenieros estn dispuestos a aprender de sus
errores y mejora continua se practica.

Repaso Captulo

Vamos a repasar lo que ha aprendido en este captulo.

De la Seccin 3.1, usted debe ser capaz de explicar la importancia y ADVAN-tages de pruebas estticas. Usted
debe saber la diferencia entre las pruebas estticas y las pruebas dinmicas, y tambin entender el concepto de
comentarios. Usted debe ser capaz de reconocer los productos de trabajo de software que pueden ser examinadas
por los ensayos estticos. Usted debe conocer los trminos del glosario pruebas estticas, pruebas dinmicas y

Evaluacin
De la Seccin 3.2, usted debe entender la diferencia entre revisiones formales e informales. Usted debe ser capaz
de recordar las principales etapas de una revisin tpica formal. Las principales funciones dentro de crticas y sus
responsabilidades deben ser claros para usted. Usted debe conocer las diferencias entre los distintos tipos de revisin
formal: revisin tcnica, paso a paso y la inspeccin. Por ultimo, debe ser capaz de explicar los factores para el
desempeo exitoso de comentarios. Usted debera de

conocer los criterios de ingreso trminos del glosario, los criterios de salida, formal revisin,
revisin informal, inspeccin, moderador, revisor, escriba, revisin tcnica y paso a paso.

De la Seccin 3.3, usted debe entender el objetivo del anlisis esttico y poder compararlo con pruebas
estticas y dinmicas. Usted debe ser capaz de describir las principales caractersticas de anlisis esttico y
recordar defectos tpicos que se pueden encontrar mediante el anlisis esttico. Por ltimo, usted debe ser
capaz de recordar los beneficios del uso de anlisis esttico. Usted debe saber que el compilador trminos del
glosario, ciclo-

complejidad matic, control de flujo, el flujo de datos y el anlisis esttico.

PREGUNTAS examen de la muestra

Pregunta 1 Cul de los siguientes artefactos pueden ser examinadas mediante el uso de
tcnicas de revisin?

a.

cdigo de software

b.

Especificacin de requisitos

c.

El empleo de pruebas

d.

Todas los anteriores

Pregunta 2 Qu afirmacin acerca de la funcin de una herramienta de anlisis esttico es

cierto?

a. Proporciona informacin de calidad sobre el cdigo sin ejecutarlo.

b. Los cheques espera que los resultados contra los resultados reales.

c.

Puede detectar prdidas de memoria.

d. Proporciona informacin acerca del cdigo tiene y no se ha ejercido.

Pregunta 3 Qu no es un tipo de revisin?

a.

Tutorial

b.

Inspeccin

c.

revisin informal

d.

Gerencia de Aprobaciones

Pregunta 4 Cul declaracin sobre comentarios es de verdad?

a. Las inspecciones son dirigidas por un moderador capacitado,

mientras que las revisiones tcnicas no son necesariamente.

b. Revisiones tcnicas son dirigidos por un lder entrenado, las inspecciones no son.

c. En un recorrido, el autor no asiste.

d. Los participantes de un recorrido siempre necesitan ser entrenados completamente.

Pregunta 5 Cul es la principal diferencia entre un tutorial y una inspeccin?

a. Una inspeccin es dirigido por los autores, mientras que un paseo

a travs es dirigido por un moderador capacitado.

b. Una inspeccin tiene un lder entrenado, mientras que un paseo a travs no tiene un
lder.

c. Los autores no estn presentes durante las inspecciones, mientras

que son durante los recorridos.

d. Un tutorial est dirigido por el autor, mientras que un

inspeccin est dirigida por un moderador capacitado.

Pregunta 6 Cul de las siguientes caractersticas y tipos de procesos de revisin van de la

mano?
1.

Dirigido por el autor

2.

indocumentado

3.

Sin la participacin de la gestin

4.

Dirigido por un moderador o lder entrenado

5. Usos de entrada y criterios de salida s. Referencia de Inspeccin

t Revisin tcnica

u.

revisin informal

v.

Tutorial

a.

s = 4, t = 3, u = 2 y 5, v = 1

b.

s = 4 y 5, t = 3, u = 2, v = 1

c.

s = 1 y 5, t = 3, u = 2, v = 4

d.

s = 5, t = 4, u = 3, v = 1 y 2

Pregunta 7 Qu afirmacin sobre el anlisis esttico es cierto?

a. Con el anlisis esttico, los defectos se pueden encontrar que estn
difcil de encontrar con las pruebas dinmicas.

b. Compilando no es una forma de anlisis esttico.

c. Si se realiza correctamente, el anlisis esttico hace

redundante pruebas funcionales.

d.

El anlisis esttico encuentra todas las faltas.

Pregunta 8 Cul de las siguientes afirmaciones acerca de diseo de la prueba temprana son
verdaderas y cules son falsas?

1.
2.

Los defectos encontrados durante el diseo de la prueba temprana son ms caros

de solucionar.
diseo de la prueba temprana puede encontrar defectos.
3. diseo de la prueba temprana puede causar cambios en los requisitos.

4.

diseo de la prueba temprana requiere ms esfuerzo.

a.

1 y 3 son ciertas. 2 y 4 son falsas.

b.

2 es verdadera. 1, 3 y 4 son falsas.

c.

2 y 3 son ciertas. 1 y 4 son falsas.

d.

2, 3 y 4 son verdaderas. 1 es falsa.

Pregunta 9 de anlisis de cdigo esttico tpicamente identifica todos menos uno de los
siguientes problemas. Cul es?

a.

Cdigo inalcanzable

b.

las variables no declaradas

c.

Los fallos en los requisitos

d.

No hay suficientes comentarios

Captulo Cuatro

tcnicas de diseo de pruebas

ap tulo 3 cubierto pruebas estticas, mirando a los documentos y el cdigo y que no utiliza el cdigo somos
interesado en.Este captulo se centra en las pruebas dinmicas, donde el software que estn interesados en que se
ejecute

mediante la ejecucin de pruebas en el cdigo de ejecucin.

4.1 IDENTIFICACIN condiciones de las pruebas DISEO

CASOS

1 Diferenciar entre una especificacin de diseo de la prueba, una

especificacin de casos de prueba y un procedimiento de ensayo.{0}k =
0.015 L{/0}{1}1{/1}

2 Comparar los trminos de condiciones de prueba, casos de prueba y procedimiento

de prueba.(k)

3 Escribir casos de prueba: (K3)

una que muestra una clara trazabilidad de los requisitos; b que

contiene un resultado esperado.

4
Traducir casos de prueba en un procedimiento de ensayo bien
estructurado en un nivel de detalle relevante para el conocimiento de los
probadores.(k)

5 Escribir un programa de ejecucin de prueba para un determinado

conjunto de casos de prueba, teniendo en cuenta el establecimiento de
prioridades, y las dependencias tcnicas y lgicas.(k)

10.1 INSTRODUCCION 107

Antes de que realmente puede ejecutar una prueba, tenemos que saber lo que estamos tratando de probar,
los insumos, los resultados que deben ser producidos por esas entradas, y cmo conseguimos realmente
listo para y ejecutar las pruebas.

En esta seccin estamos ante tres cosas: las condiciones de prueba, casos de prueba y procedimientos
de prueba (o scripts) - que se describen en las siguientes secciones. Cada uno se especifica en su propio
documento, de acuerdo con la documentacin de prueba estndar [IEEE829].

Condiciones de la prueba se documentan en un diseo de la Norma de Ensayo. Vamos a ver cmo

elegir las condiciones de prueba y dar prioridad a ellos.

Los casos de prueba se documentan en un caso de la Norma de Ensayo.Vamos a ver cmo escribir un
buen caso de prueba, mostrando clara trazabilidad a la base de pruebas (por ejemplo, la especificacin de
requisitos), as como para poner a prueba las condiciones.

Los procedimientos de prueba estn documentados (como se puede esperar) en un procedimiento de la

Norma de Ensayo (tambin conocida como una secuencia de comandos de prueba o un script de prueba
manual). Vamos a ver cmo traducir los casos de prueba en los procedimientos de prueba relevantes para
el conocimiento del probador que van a realizar los ensayos, y vamos a ver cmo producir un calendario
de ejecucin de pruebas, usando el establecimiento de prioridades y dependencias tcnicas y lgicas.
En esta seccin, busque las definiciones de los trminos del glosario: caso de prueba, la prueba

especificacin caso, las condiciones de ensayo, datos de prueba, procedimiento de ensayo,

escritura de la prueba y la trazabilidad.

4.1.2 La formalidad de la documentacin de prueba

La prueba puede realizarse con diversos grados de formalidad. prueba muy formal tendra una extensa
documentacin que est bien controlada, y esperara que el detalle de las pruebas documentadas para incluir la
entrada exacta y especfica y el resultado esperado de la prueba. Muy informal prueba puede no tener la documentacin en absoluto, o slo las notas tomadas por los probadores individuales, pero todava era de esperar los
probadores que tienen en sus mentes y toma nota de una cierta idea de lo que pretendan poner a prueba y lo que se
espera el resultado de ser. La mayora de las personas son probablemente algunos-en donde en el medio! El nivel
adecuado de formalidad para usted depende de su contexto: una aplicacin comercial crtico para la seguridad tiene

muy diferentes necesidades que una aplicacin de una sola vez para ser utilizado por slo unas pocas personas por
un corto tiempo.

El nivel de formalidad tambin se ve influida por su organizacin - su cultura, la gente que trabaja all,
su grado de madurez del proceso de desarrollo es, la madurez de los procesos de prueba es, etc. La
rigurosidad de la documentacin de prueba tambin puede depender de sus limitaciones de tiempo; bajo
presin de tiempo excesiva, manteniendo una buena documentacin puede verse comprometida.

En este captulo vamos a describir un estilo de documentacin bastante formal. Si esto no es apropiado
para usted, es posible adoptar un enfoque menos formal, pero usted ser consciente de cmo aumentar la
formalidad si es necesario.

anlisis 4.1.3 Prueba: la identificacin de las condiciones de prueba

anlisis de la prueba es el proceso de mirar algo que puede ser utilizada para obtener informacin de la
prueba. Esta base de las pruebas se denomina la "base de pruebas '. Podra ser un requisito del sistema,
una especificacin tcnica, el propio cdigo (para pruebas estructurales), o un proceso de negocio. A
veces las pruebas se pueden basar en el conocimiento de un usuario experimentado del sistema, que no
puede ser documentado. La base de pruebas incluye cualesquiera que sean las pruebas se basan en. Esto
tambin se discuti en el Captulo 1. Desde una perspectiva de pruebas, nos fijamos en la base de pruebas
con el fin de ver lo que podra ser probada - stas son las condiciones de prueba. Una condicin de
prueba es simplemente algo que hemos podido probar. Si estamos buscando para medir la cobertura de
cdigo decisiones (ramas), entonces la base de pruebas sera el propio cdigo, y la lista de condiciones de
prueba seran los resultados de la decisin (verdaderos y falsos).Si tenemos una especificacin de
requisitos, la tabla de contenido puede ser nuestra lista inicial de las condiciones de ensayo.

Una buena manera de entender mejor los requisitos es tratar de definir pruebas para cumplir con esos
requisitos, como ha sealado [Hetzel, 1988].
Por ejemplo, si estamos probando una gestin de clientes y sistema de comercializacin de una
empresa de telefona mvil, podramos tener condiciones de prueba que estn relacionados con una
campaa de marketing, tales como la edad del cliente (pre-adolescente, adulto joven, madura), gnero,
cdigo postal o el cdigo postal, y la preferencia de compra (pay-as-you-go o contrato). Una campaa de
publicidad en particular podra ser dirigido a los clientes adolescentes varones en el medio oeste de los
EE.UU. en pay-as-you-go, por ejemplo.

expertos en pruebas utilizan diferentes nombres para representar la idea bsica de "una lista de cosas
que podamos probar '. Por ejemplo, Marick se refiere a '' los requisitos de prueba como cosas que deben
ser probados. Aunque no se pretende dar a entender que todo debe ser probado, se interpreta fcilmente
de esta manera. [Marick, 1994] En con-traste, Hutcheson habla de la "prueba de inventario 'como una

lista de cosas que podran ser probado [Hutcheson, 2003]; Craig habla sobre como amplias categoras
'objetivos' de prueba para probar cosas y los inventarios de prueba '' como la lista actual de las cosas que
necesitan ser probados [Craig, 2002]. Estos autores se refieren a todo lo que el glosario ISTQB llama a
una condicin de prueba.

En la identificacin de las condiciones de prueba, queremos 'lanzar la red de ancho' para identificar a
todos los que podamos, y luego vamos a empezar a ser selectivo sobre cules llevar adelante para
desarrollar con ms detalle y combinar en los casos de prueba. Podramos llamarlos 'posibilidades' de
prueba.

En el captulo 1 se explic que las pruebas de todo lo que se conoce como pruebas exhaustivas
(definido como el ejercicio de todas las combinaciones de insumos y las condiciones previas) y hemos
demostrado que este es un objetivo prctico. Por lo tanto, ya que no podemos probar todo, tenemos que
seleccionar un subconjunto de todas las pruebas posibles. En la prctica, el subconjunto seleccionamos
puede ser un subconjunto muy pequeo y, sin embargo, tiene que tener un alto proba-bilidad de encontrar
la mayor parte de los defectos en un sistema. Necesitamos algunos procesos de pensamiento inteligente
para guiar nuestra seleccin; tcnicas de prueba (es decir, diseo de pruebas tech-tcnicas) son tales
procesos de pensamiento.

Una tcnica de prueba ayuda a seleccionar un buen conjunto de pruebas a partir del nmero total de
todas las pruebas posibles para un sistema dado. Diferentes tcnicas ofrecen diferentes maneras de mirar
el software bajo prueba, supuestos posiblemente difciles hechas al respecto. Cada tcnica proporciona un
conjunto de reglas o directrices para el probador a seguir en la identificacin de las condiciones de prueba
y casos de prueba. Las tcnicas se describen en detalle ms adelante en este captulo.

Las condiciones de prueba que se elijan dependern de la estrategia de prueba o mtodo de prueba
detallado. Por ejemplo, podran estar basados en el riesgo, modelos del sistema, los fallos que puedan, los
requisitos de cumplimiento, el asesoramiento de expertos o heurstica. La palabra 'heurstica' viene de la
misma raz griega como Eureka, que significa 'encuentro'.Una heurstica es una manera de dirigir su
atencin, una regla de sentido comn til para resolver un problema.

Condiciones de ensayo deben ser capaces de vincularse de nuevo a sus fuentes en una base de ensayos
- esto se llama trazabilidad.

La trazabilidad puede ser horizontal a travs de toda la documentacin de prueba para un nivel de
prueba determinado (por ejemplo, pruebas de sistema, de condiciones de prueba a travs de casos de
prueba para probar los scripts) o vertical a travs de las capas de la documentacin de desarrollo (por
ejemplo, de los requisitos a los componentes).

Por qu es importante la trazabilidad? Considera estos ejemplos:

Los requisitos para una funcin o caracterstica dada han cambiado.Algunos de los campos ahora tienen
diferentes rangos que se pueden introducir. Los exmenes que estuviera mirando a esos lmites? Ahora necesitan
ser cambiadas. Cuntas pruebas sern realmente afectados por este cambio en los requisitos? Estas preguntas
pueden ser respondidas fcilmente si los requisitos se pueden rastrear fcilmente a las pruebas.

Un conjunto de pruebas que ha corrido bien en el pasado ha empezado a tener pro- blemas graves.
Qu funcionalidad hacen estas pruebas en realidad ejercen? Trazabilidad entre las pruebas y el
requisito de que se estn probando permite a las funciones o elementos afectados a identificarse ms
fcilmente.

Antes de la entrega de un nuevo lanzamiento, queremos saber si es o no hemos probado todos los requisitos
especificados en la especificacin de requisitos.Tenemos la lista de las pruebas que han pasado - se puso a
prueba todos los requisitos?

Despus de haber identificado una lista de condiciones de prueba, es importante dar prioridad a ellos, de
manera que se identifican las condiciones de las pruebas ms importantes (antes de que una gran cantidad de
tiempo que se gasta en el diseo de casos de prueba basados en ellos). Es una buena idea para tratar de pensar
en el doble de las condiciones de prueba como sea necesario - a continuacin, se puede tirar a la basura los
menos importantes, y usted tendr una mejor conjunto de condiciones de prueba!

Tenga en cuenta que pasar algn tiempo adicional ahora, mientras que la identificacin de las
condiciones de prueba, no se necesita mucho tiempo, ya que slo enumerando las cosas que podamos
probar. Esta es una buena inversin de nuestro tiempo - que no queremos pasar el tiempo la aplicacin de
pruebas de pobres!

Condiciones de ensayo se pueden identificar los datos de prueba, as como para las entradas de
prueba y los resultados de las pruebas, por ejemplo, diferentes tipos de registro, la distribucin de
diferentes tipos de registro dentro de un archivo o base de datos, diferentes tamaos de los registros o
campos de un registro.Los datos de prueba deben ser diseados para representar los tipos de datos ms
importantes, es decir, las condiciones de los datos ms importantes.

Condiciones de la prueba se documentan en el documento IEEE 829 se llama un diseo de la Norma

de Ensayo, se muestra a continuacin. (Este documento podra haber sido llamado un Estado de la Norma
de Ensayo, ya que los contenidos se hace referencia en la norma son en realidad las condiciones de
prueba.)

IEEE 829 STANDARD:

PRUEBA DE DISEO ESPECIFICACIONES MODELO

Caractersticas prueba de especificacin de diseo de identificador a

ensayar Enfoque refinamientos prueba de Identificacin de estructuras
pasa / no pasa criterios

4.1.4 Prueba de diseo: la especificacin de casos de prueba

Condiciones de ensayo pueden ser bastante vaga, que cubre toda una amplia gama de posibilidades como vimos en
nuestro ejemplo empresa de telefona mvil (por ejemplo, un adolescente en el medio oeste), o una condicin de
prueba puede ser ms especficos (por ejemplo, un cliente masculino en particular en pago -como se avanza con
menos de $ 10 de crdito). Sin embargo, cuando llegamos a hacer un caso de prueba, estamos obligados a ser muy
especfico; de hecho, ahora tenemos exacta y

insumos especficos detallados, no descripciones generales (por ejemplo, Jim Green, de 17 aos, que vive en
Grand Rapids, Michigan, con el crdito de $ 8,64, resultado esperado: aadir a la campaa de marketing
Q4).Tenga en cuenta que uno de los casos de prueba cubre una serie de condiciones (adolescente, varn,
medio oeste zona, pay-as-you-go, y el crdito de menos de $ 10).

Para una condicin de prueba de "un cliente existente ', la entrada de caso de prueba debe ser' Jim
Green ', donde Jim Green ya existe en la base de datos del cliente, o parte de esta prueba podra ser la
creacin de un registro de base de datos para Jim Green.

Un caso de prueba debe tener valores de entrada, por supuesto, pero slo tener algunos valores de entrada al
sistema, no es una prueba! Si usted no sabe lo que el sistema est SUP-plantea que ver con las entradas, no se puede
decir si la prueba es aprobada o no.

En caso de que estos casos de prueba detallados ser escritos? Pueden ser formalmente doc-no
documentadas, como describiremos a continuacin. Sin embargo, es posible probar sin doc-umenting a nivel
de casos de prueba. Si le das a un probador de aceptacin del usuario experimentado, con un fuerte
conocimiento de los negocios una lista de condiciones de prueba de alto nivel, que probablemente podra hacer
un buen trabajo de la prueba. Pero si usted le dio la misma lista a un nuevo motor de arranque que no conoca
el sistema en absoluto, que probablemente se perdern, por lo que se beneficiaran de tener casos de prueba
ms detallados.

Los casos de prueba se pueden documentar como se describe en el estndar IEEE 829 Estndar para la
Documentacin de la comprobacin. Tenga en cuenta que el contenido descrito en la norma no todos tienen
que ser documentos fsicos separados. Pero la lista de la norma de lo que debe mantenerse un registro de es un
buen punto de partida, incluso si las condiciones de prueba y casos de prueba para una funcionalidad o
caracterstica determinada se mantienen todas en un solo documento fsico.

Uno de los aspectos ms importantes de un instrumento es que se evala que el sistema hace lo que se
supone que debe hacer. Copeland dice 'En su esencia, la prueba es el proceso de comparar "lo que es" con "lo
que debera ser"'. [Copeland, 2003] Si nos limitamos a poner en un cierto entradas y pensamos 'que fue muy
divertido, supongo que el sistema es probablemente correcto, ya que no se haba estrellado ", entonces estamos
realmente que las pruebas? Nosotros no lo creemos. Habr observado que el sistema hace lo que hace el
sistema - esto no es una prueba. Boris Beizer refiere a esto como "la prueba para nios '[Beizer, 1990]. Es
posible que no sabemos cul es la respuesta correcta es con detalle cada vez, y todava podemos obtener algn
beneficio de este enfoque a veces, pero no es realmente la prueba.

Con el fin de saber lo que debe hacer el sistema, tenemos que tener una fuente de informa-cin sobre el
comportamiento correcto del sistema - esto se llama un "orculo" o un orculo de pruebas.Esto no tiene nada que ver con
las bases de datos o empresas que los fabrican. Viene del griego antiguo orculo de Delfos, que supuestamente poda
predecir el futuro con exactitud infalible. En realidad, sus respuestas eran tan vagas que la gente los interpretados de la
manera que queran - tal vez un poco como las especificaciones de requisitos!

Una vez que un determinado valor de entrada ha sido elegido, el probador tiene que determinar cul es
el resultado esperado de entrar en esa entrada sera y documentarla como parte del caso de prueba.

Los resultados esperados incluyen informacin que aparece en una pantalla en respuesta a una entrada,
pero tambin incluyen cambios en los datos y / o estados, y cualquier otro cuencias-cuencias de la prueba
(por ejemplo, una carta para ser impreso durante la noche).

Qu pasa si no tomamos una decisin en los resultados esperados antes de correr una prueba? Todava
podemos ver lo que produce el sistema y probablemente notar si algo era absolutamente incorrecta. Sin
embargo, probablemente no notar pequeas diferencias en los clculos o resultados que parecan mirar bien (es
decir, son plausibles). As llegamos a la conclusin de que la prueba haba pasado, cuando en realidad el
software no ha dado el resultado correcto. Las pequeas diferencias en un clculo pueden sumar a algo muy
importante ms adelante, por ejemplo, si los resultados se multiplican por un factor grande.

Lo ideal sera que los resultados esperados se pueden predecir antes de que se ejecute la prueba entonces su evaluacin de si o no el software hizo lo correcto ser ms objetiva.

Para algunas aplicaciones puede que no sea posible predecir o saber exactamente lo que se espera
como debe ser; que slo podemos hacer un control de razonabilidad '. En este caso tenemos un "orculo
parcial" - sabemos cuando algo est muy mal, pero probablemente tendr que aceptar algo que pareca
razonable. Un ejemplo es cuando un sistema ha sido escrita para calcular algo donde puede que no sea
posible producir manualmente los resultados esperados en un plazo de tiempo razonable, porque los
clculos son tan complejos.

Adems de los resultados esperados, el caso de la prueba tambin se especifica el entorno-cin y otras
cosas que deben estar en su lugar antes de la prueba se puede ejecutar (las condiciones previas) y las
cosas que han de aplicarse tras la prueba completa (las condiciones posteriores) .

IEEE 829 STANDARD: j

CASO DE PRUEBA
ESPECIFICACIONES MODELO
1

Identificador de la prueba especificacin de caso

Elementos de prueba

Las especificaciones de salida

necesidades ambientales

Las especificaciones de entrada

Requisitos de procedimiento especiales

 Dependencias en el nter de los casos

El caso de prueba tambin se debe decir por qu existe - es decir, el objetivo de la prueba es parte de, o
las condiciones de prueba que se est ejercitando (trazabilidad). Los casos de prueba ahora se pueden
priorizar de manera que los casos de prueba ms importantes se ejecutan primero, y los casos de prueba
de baja prioridad se ejecutan despus, o incluso no se ejecutan en absoluto. Esto puede reflejar las
prioridades ya establecidas para las condiciones de ensayo o de la prioridad puede ser determinado por
otros factores relacionados con los casos de prueba especficos, como un valor de entrada SPE-especque ha demostrado ser problemtico en el pasado, el riesgo asociado a la prueba o, la secuencia ms
sensible de la ejecucin de las pruebas. Captulo 5 da ms detalles de la prueba basado en el riesgo.

Los casos de prueba deben ser detalladas por lo que podemos comprobar con exactitud los resultados y
saber que tenemos exactamente la respuesta adecuada del sistema. Si las pruebas han de ser
automatizado, la herramienta de prueba tiene que saber exactamente lo que para comparar la salida del
sistema a.

4.1.5 Prueba de aplicacin: la especificacin de los procedimientos de prueba o

secuencias de comandos

El siguiente paso consiste en agrupar los casos de prueba en una forma sensata de su ejecucin y para
especificar los pasos secuenciales que hay que hacer para ejecutar la prueba. Por ejemplo, un conjunto de
pruebas simples que cubre la anchura del sistema puede formar un conjunto de regresin, o la totalidad de
las pruebas que exploran el funcionamiento de una funcionalidad dada o caracterstica en profundidad
pueden ser agrupados para ser ejecutado juntos.

Puede ser necesario ejecutar en una secuencia particular algunos casos de prueba. Por ejemplo, una prueba
puede crear un nuevo registro de cliente, modificar dicho registro recin creado y

luego eliminarlo.Estas pruebas se deben ejecutar en el orden correcto, o no van a probar lo que estn
destinados a probar.

El documento que describe los pasos a seguir en la ejecucin de un conjunto de pruebas (y especifica
el orden ejecutable de las pruebas) se llama una prueba de procedi-miento en el estndar IEEE 829, y se
suele denominar tambin como un script de prueba.Podra ser llamado una secuencia de comandos de
prueba manual para las pruebas que estn destinados a ser ejecutar manualmente en lugar de utilizar una
herramienta de ejecucin de la prueba.escritura de la prueba tambin se utiliza para describir las
instrucciones para una herramienta de ejecucin de la prueba. Una secuencia de comandos de
automatizacin est escrito en un lenguaje de programacin que la herramienta pueda interpretar. (Este es
un procedimiento de ensayo automatizado.) Vase el captulo 6 para obtener ms informacin sobre ste
y otros tipos de herramientas de prueba.

Los procedimientos de prueba, o scripts de prueba, se forman entonces en un programa de ejecucin de

prueba que especifica qu procedimientos se van a ejecutar en primer lugar - una especie de super-guin.
El plan de ensayo dira cuando una secuencia de comandos dada se debe ejecutar y por quin. El horario
puede variar en funcin de los nuevos riesgos percibidos que afectan a la prioridad de una secuencia de
comandos que se ocupa de que el riesgo, por ejemplo. Las dependencias lgicas y tcnicas entre las
secuencias de comandos tambin se tendran en cuenta a la hora de programar las secuencias de
comandos. Por ejemplo, una secuencia de comandos de regresin siempre puede ser el primero en ser
ejecutado cuando una nueva versin del software llega, como una prueba de humo o de comprobacin de
validez.

Volviendo a nuestro ejemplo de marketing cam-paa de la empresa de telefona mvil, podemos tener
algunas pruebas para configurar los clientes de diferentes tipos en la base de datos. Puede ser sensato para
ejecutar la totalidad de la configuracin de un grupo de pruebas primero. As que nuestro primer
procedimiento de prueba implicara la creacin de un nmero de clientes, INCLUYENDO-ing Jim Green,
en la base de datos.

Procedimiento de la prueba DB15: Configuracin de los clientes para la campaa de marketing Y.

Paso 1: Abrir base de datos con el privilegio de escritura Paso 2: Configurar clientes Bob Flounders
varn, de 62 aos, Hudsonville, contrato Paso 3: Configurar el cliente
Jim Green

masculino, 17, Grand Rapids, pay-as-you-go, $ 8,64 Paso 4: ...

entonces podemos tener otro procedimiento de ensayo que ver con la comercializacin cam-paa:

Procedimiento de la prueba MC03: Ofertas especiales para adolescentes bajo crdito

Paso 1: Obtener datos de la base de datos de Jim Green Paso 2: Enviar un mensaje de
texto que ofrece el doble de crdito Paso 3: Jim Green solicita crdito de $ 20, $ 40 le
atribuye

Escribir el procedimiento de prueba es otra oportunidad para dar prioridad a las pruebas, para asegurar
que la mejor prueba se realiza en el tiempo disponible. Una buena regla de oro es "encontrar la primera
cosas de miedo '. Sin embargo, la definicin de lo que es 'miedo' depende de la empresa, sistema o
proyecto. Por ejemplo, es peor para elevar el lmite de crdito Bob Fundadores cuando l no es un buen
riesgo de crdito (que no puede pagar por el crdito que pidi) o negarse a aumentar su lmite de crdito
cuando el riesgo de buen crdito (l puede ir a otro lugar para su servicio de telfono y perder la
oportunidad de una gran cantidad de ingresos de l).

IEEE 829 STANDARD:

Especificacin de procedimiento de pruebas

Plantilla

Identificador de especificacin de procedimiento de pruebas

Propsito

Requisitos especiales

pasos del procedimiento

4. 2 CATEGORAS DE DISEO DE PRUEBA

Tcnicas

1 Recordemos que tanto razones (recuadro negro) basada en la especificacin y

estructura-

basado (caja blanca) se acerca a prueba diseo de la caja son tiles, y la lista de la

tcnicas comunes para cada uno. {0}k = 0.015 L{/0}{1}1{/1}

2 Explicar las caractersticas y diferencias entre basada en la especificacin

las pruebas, las pruebas basadas en la estructura y el ensayo basado en la experiencia.

(k)

En esta seccin vamos a ver los diferentes tipos de tcnicas de diseo de pruebas, cmo se utilizan y
cmo se diferencian. Los tres tipos o categoras se distin-guido por su fuente primaria: una
especificacin, la estructura del sistema o componente, o la experiencia de una persona. Todas las
categoras son tiles y los tres son complementarias.
En esta seccin, busque las definiciones de los trminos del glosario: prueba de recuadro negro

tcnicas de diseo, tcnicas de diseo de pruebas basado en la experiencia, las tcnicas de

diseo de pruebas basado en las especificaciones tcnicas de diseo, las pruebas basadas en
la estructura y tcnicas de diseo de pruebas de caja blanca.

10.1 INSTRODUCCION 107

Hay muchos tipos diferentes de tcnicas de pruebas de software, cada uno con sus propias fortalezas y
debilidades. Cada tcnica individual es bueno para encontrar tipos partic ular-de defectos y relativamente
pobres en la bsqueda de otros tipos. Por ejemplo, una tcnica que explora los lmites superior e inferior de un
solo rango de entrada es ms probable encontrar defectos de contorno que los defectos asociados con la combinaciones de entradas. Del mismo modo, las pruebas realizadas en las diferentes etapas del ciclo de vida del
software de desarrollo encontrarn diferentes tipos de defectos; la prueba de componentes es ms probable
encontrar defectos lgicos de codificacin que no sean defectos de diseo del sistema.

Cada tcnica de pruebas se encuentra en una de un nmero de diferentes categoras. En trminos generales hay
dos categoras principales, estticas y dinmicas. Estticas tech-tcnicas se discuten en el Captulo 3. tcnicas
dinmicas se subdividen en tres categoras ms: basada en la especificacin (negro-caja, tambin conocido como
conductual

tcnicas), basado en la estructura (caja blanca o tcnicas estructurales) y expe-cia basada en. las tcnicas
basadas en la especificacin incluyen tanto tcnicas funcionales y no funcionales (es decir, caractersticas
de calidad). Las tcnicas tratadas en el programa de estudios se resumen en la Figura 4.1.

4.2.2 tcnicas de pruebas estticas

Como vimos en el captulo 3, las tcnicas de pruebas estticas no ejecutan el cdigo que est siendo
examinado y se utiliza generalmente antes de las pruebas se ejecutan en el software. Podran ser llamados
tcnicas no ejecucin. La mayora de las tcnicas de pruebas estticas se pueden utilizar para "prueba"
cualquier forma de documento que incluye cdigo fuente, diseo docu-mentos y modelos,
especificaciones funcionales y especificaciones de requisitos. Sin embargo, el "anlisis esttico" es un
tipo de prueba esttica que concen-trados en pruebas de lenguajes formales y por lo tanto a menudo se
realiza para probar estticamente cdigo fuente herramienta compatible.

4.2.3 (recuadro negro) tcnicas de prueba basados en la especificacin

La primera de las tcnicas de pruebas dinmicas vamos a ver son las tcnicas de prueba basados en la
especificacin. Estos tambin son conocidos como "recuadro negro" o de entrada / salida impulsado por tcnicas
de prueba, porque consideran que el software como un recuadro negro con entradas y salidas, pero no tienen ningn
conocimiento de cmo funciona el sistema o

componente se estructura dentro de la caja.En esencia, el probador est concentrando en lo que hace el
software, no cmo lo hace.

Ntese que la definicin menciona las pruebas -funcional tanto funcionales como no. Las pruebas
funcionales se ocupa de lo que hace el sistema, sus caractersticas o funciones. Ensayos no funcional se ocupa
de examinar qu tan bien el sistema hace algo, en lugar de lo que hace. aspectos no funcionales (tambin
conocidas como caractersticas de calidad o atributos de calidad) incluyen el rendimiento, facilidad de uso,
portabilidad, facilidad de mantenimiento, etc. Las tcnicas para probar estos aspectos no func-cional son
menos procesal y menos formal que los de otras cate-goras como el pruebas reales son ms dependientes del
tipo de sistema, lo que hace y los recursos disponibles para las pruebas.

Ensayos no funcional es parte del programa de estudios y tambin se trata en el captulo 2. Hay tcnicas
para derivar las pruebas no funcionales [gilb, 1988], [] normas de ensayo, pero no estn cubiertos en el nivel
de infraestructura.

Categorizacin de las pruebas en blanco y negro-caja se menciona en varios libros de ensayo,

incluyendo [Beizer, 1990] y [Copeland, 2003].

4.2.4 (caja blanca) tcnicas de prueba basados en estructuras

tcnicas de pruebas basadas en la estructura (que tambin son dinmicos y no estticos) utilizan la
estructura interna del software para derivar casos de prueba. Se com-comnmente llamados tcnicas de
"caja de vidrio '' caja blanca 'o (lo que implica que usted puede ver en el sistema), ya que requieren
el conocimiento de cmo se implementa el software, es decir, cmo funciona.Por ejemplo, una
tcnica estructural puede estar preocupado con el ejercicio de bucles en el software. Diferentes
casos de prueba pueden derivarse de ejercer el bucle una vez, dos veces, y muchas veces. Esto
puede realizarse independientemente de la func-lidad del software.

4.2.5 tcnicas de pruebas basadas en la experiencia

En las tcnicas basadas en la experiencia, el conocimiento, las habilidades y los antecedentes de las
personas son un factor primordial a las condiciones de prueba y casos de prueba.La experiencia de las dos
personas tcnicas y de negocios es importante, ya que aportan diferentes perspectivas al anlisis de la
prueba y el proceso de diseo. Debido a la experiencia previa con sistemas similares, que pueden tener
una visin de lo que podra ir mal, lo que es muy til para realizar pruebas.

4.2.6 En caso de aplicar las diferentes categoras de tcnicas

Las tcnicas basadas en las especificaciones son apropiados en todos los niveles de las pruebas (pruebas
compo-nente a travs de las pruebas de aceptacin) cuando existan especificaciones. Al realizar las
pruebas de aceptacin del sistema o, la especificacin de requisitos o especificaciones funcionales pueden
formar la base de las pruebas. Al realizar com-ponente o las pruebas de integracin, un documento de
diseo o especificacin de bajo nivel es la base de las pruebas.

Las tcnicas basadas en estructura tambin se pueden utilizar en todos los niveles de la prueba. Los
desarrolladores utilizan tcnicas basadas en la estructura de las pruebas y compo-nente de las pruebas de
integracin de componentes, especialmente cuando existe un buen apoyo para la herramienta de cobertura de
cdigo. Las tcnicas basadas en estructura tambin se utilizan en el sistema y la aceptacin

pruebas, pero las estructuras son diferentes.Por ejemplo, la cobertura de las opciones de men o
transacciones de negocios ms importantes podra ser el elemento estructural en el sistema o pruebas de
aceptacin.

tcnicas basadas en la experiencia se utilizan para complementar las tcnicas basadas en la

especificacin y basados en la estructura, y tambin se utilizan cuando no hay specifica-cin, o si la
especificacin es inadecuada o fuera de fecha. Este puede ser el nico tipo de tcnica utilizada para
sistemas de bajo riesgo, pero este enfoque puede ser particu-larmente til bajo extrema presin de tiempo
- de hecho, este es uno de los factores que conducen a pruebas exploratorias.

4.3 ESPECIFICACIONES BASADA EN NEGRO O-BOX

Tcnicas

1 Escribir casos de prueba a partir de modelos dados de software utilizando la

siguiente prueba

tcnicas de diseo. (k)

una particin de equivalencia; b anlisis de valores

lmite; c tablas de decisin;

d pruebas de transicin de estado.

2 Comprender el propsito principal de cada una de las cuatro tcnicas, qu nivel

y el tipo de prueba podra utilizar la tcnica, y cmo puede ser la cobertura

medirse. (k)

3 Comprender el concepto de pruebas de casos de uso y sus beneficios.

(k)

En esta seccin vamos a examinar en detalle cuatro tcnicas basadas en la especificacin o negro-box.
Estas cuatro tcnicas son K3 en el Syllabus - esto significa que usted necesita para ser capaz de utilizar
estas tcnicas para el diseo de casos de prueba. Tambin vamos a cubrir brevemente (no a nivel K3) la
tcnica basada en la especificacin de las pruebas de caso de uso. En la Seccin 4.4, vamos a ver las
tcnicas basadas en la estructura K3.
En esta seccin, busque las definiciones de los trminos del glosario: valores en la frontera

anlisis, pruebas de la tabla de decisiones, la particin de equivalencia, las pruebas de

transicin de estado y pruebas de casos de uso.

Las cuatro tcnicas basadas en la especificacin vamos a cubrir en detalle son:

Particin de Equivalencia

anlisis de valores lmite;

Tablas de decisin

Prueba de Estado de Transicin

Tenga en cuenta que vamos a discutir los dos juntos por primera vez, ya que estn estrechamente
relacionados.

4.3.1 Equivalencia separacin y anlisis de valores lmite

Particin de Equivalencia

Particin de equivalencia (EP) es una buena tcnica de recuadro negro basado en la especificacin
de todos los aspectos.Se puede aplicar en cualquier nivel de la prueba y es a menudo una buena
tecnologa-nique debe usar primero. Es un enfoque de sentido comn de la prueba, tanto es as que
la mayora de los probadores de la practican de manera informal a pesar de que no se den cuenta.
Sin embargo, si bien es mejor utilizar la tcnica de manera informal que no en todos, es mucho
mejor usar la tcnica de una manera formal para alcanzar todos los beneficios que puede ofrecer.
Esta tcnica se puede encontrar en la mayora de libros de prueba, incluyendo [Myers, 1979] y
[Copeland, 2003].

La idea detrs de la tcnica consiste en dividir (es decir, a la Particin) un conjunto de prueba condiciones en grupos o conjuntos que se puede considerar de la misma (es decir, el sistema debe manejarlos
de forma equivalente), por lo tanto "particin de equivalencia '. Particiones de equivalencia tambin se
conocen como clases de equivalencia - los dos trminos significan exactamente lo mismo.

La tcnica de equivalencia-particionamiento requiere entonces que necesitamos probar una sola condicin
de cada particin. Esto se debe a que estamos suponiendo que todas las condiciones de una particin sern
tratados de la misma manera por el software. Si una condicin en una particin funciona, asumimos todas las
condiciones en que la com- par va a funcionar, y por lo tanto no tiene mucho sentido en la prueba de
cualquiera de estos otros. Por el contrario, si una de las condiciones en una particin que no funciona, entonces

suponemos que ninguna de las condiciones en que la particin va a funcionar as que de nuevo no tiene mucho
sentido en la prueba ms en esa particin. Por supuesto, estos estn simplificando supuestos que pueden no ser
siempre correcta, pero si les escribimos, por lo menos le da a la gente la oportunidad de desafiar las
suposiciones que hemos hecho y espero ayudar a identificar mejor las particiones. Si tiene tiempo, es posible
que desee probar ms de un valor a partir de una particin, especialmente si desea confirmar una seleccin de
entradas de usuario tpicos.

Por ejemplo, una cuenta de ahorros en un banco gana una tasa de inters diferente en funcin del saldo
de la cuenta. Con el fin de probar el software que cula-cal de los intereses debidos, podemos identificar
los rangos de valores de equilibrio que ganan las diferentes tasas de inters. Por ejemplo, si un equilibrio
en el rango de $ 0 a $ 100 tiene una tasa de inters del 3%, un saldo de ms de $ 100 y hasta $ 1000 tiene
una tasa de inter-est 5%, y el saldo de $ 1000 y ms de tener una tasa de inters del 7%, identificaramos
ini-cialmente tres particiones de equivalencia vlidas y una particin vlida como se muestra a
continuacin.

invlida de la Vlido (por inters del

particin 3%)

32. 0.00

$100.00

Vlido (el 5%)

32.

Vlido (el 7%)

32. $1.000.00

Tenga en cuenta que hemos identificado cuatro particiones aqu, a pesar de que la especifica--cin slo menciona
tres. Esto ilustra una tarea muy importante del probador - no slo lo probamos lo que est en nuestra especificacin,
pero tambin pensamos en cosas que no han sido especificados. En este caso se ha pensado en la situacin en la que
el equilibrio es menor que cero. (todava) no hemos identificado una particin no vlida a la derecha, pero esto
tambin sera una buena cosa a tener en cuenta. Con el fin de identificar dnde termina la particin 7%, tendramos
que saber qu es el saldo mximo para esta cuenta (que puede no ser fcil de encontrar). En nuestro ejemplo hemos
dejado esta abierta por el momento. Tenga en cuenta que la entrada no numrico es tambin una particin no vlido
(por ejemplo, la letra "a"), pero slo se discuten las particiones numricos por ahora.

Hemos hecho una suposicin aqu sobre lo que es la diferencia ms pequea entre dos valores.Hemos
asumido dos cifras decimales, es decir, $ 100.00, pero que podra haber asumido cero decimales (es decir, $
100) o ms de dos decimales (por ejemplo, $ 100,0000) En cualquier caso, es una buena idea para indicar sus
supuestos - a continuacin, otras personas pueden ver ellos y le permiten saber si son correctas o no.

En el diseo de los casos de prueba de este software que se asegurara de que las tres particiones de
equivalencia vlidos son cada vez cubiertas, y tambin queremos probar la particin no vlido al menos
una vez. As, por ejemplo, podemos elegir calcular los intereses sobre saldos Pu- $ 10.00 $ 50.00 $
260.00 y $ 1,348.00. Si no hubiramos identificado especficamente estas particiones, es posible que al
menos uno de ellos se podran haber perdido a costa de poner a prueba otra varias veces. Tenga en cuenta
que tambin podramos aplicar la particin de equivalencia a las salidas tambin. En este caso tenemos
tres tipos de inters: 3%, 5% y 7%, ms el mensaje de error no vlido para la particin (o particiones). En
este ejemplo, la salida par-ticiones se alinean exactamente con las particiones de entrada.

Cmo le podra probar esto sin pensar en las particiones? Un probador ingenua (vamos a llamar a l
Robbie) podra haber pensado que un buen conjunto de pruebas sera probar cada $ 50. Eso dara a las
siguientes pruebas: $ 50.00 $ 100.00 $ 150.00, $ 200.00 $ 250.00 ... dicen hasta $ 800.00 (continuacin Robbie
habra cansado de ella y pens que suficientes pruebas se han llevado a cabo). Pero mira lo que Robbie ha
probado: slo dos de cada cuatro particiones! As que si el sistema no cor-rectamente manejar un saldo
negativo o un saldo de $ 1000 o ms, no se habra encontrado estos defectos - por lo que el enfoque ingenuo es
menos eficaz que la particin equiva-lencia. Al mismo tiempo, Robbie tiene cuatro veces ms pruebas (16
ensayos por nuestros cuatro pruebas utilizando particiones de equivalencia), por lo que tambin es mucho
menos efi-ciente! Es por esto que decimos que el uso de tcnicas tales como esto hace que las pruebas a la vez
ms eficaz y ms eficiente.

Tenga en cuenta que cuando decimos que una particin es "no vlido", esto no significa que un valor
que no se puede entrar por un usuario o un valor que el usuario no est SUP-pos para introducirlo-senta
repre. Slo significa que no es una de las entradas esperadas para este campo en particular. El software
debe manejar correctamente los valores de la particin no vlida, al responder con un mensaje de error
como "El balance debe ser de al menos $ 0.00 '.

Tenga en cuenta tambin que la particin no vlida puede no ser vlido slo en el contexto de acreditar el pago de
intereses. Una cuenta que est sobregirada requerir algn tipo de accin diferente.

anlisis de valores lmite

Anlisis de valores lmite (BVA) se basa en las pruebas en los lmites entre particiones.Si alguna vez has
hecho 'verificacin de rango', que estaba probablemente utilizando la tcnica de anlisis de valores lmite,
incluso si usted no era consciente de ello. Tenga en cuenta que tenemos dos lmites vlidos (en las
particiones vlidas) y los lmites vlidos (en las particiones no vlidas).

A modo de ejemplo, considere una impresora que tiene una opcin de entrada del nmero de

Para aplicar anlisis de valores lmite, tomaremos los valores mximo y mnimo (frontera) y de la
particin vlida (1 y 99 en este caso), junto con copias a hacer, de 1 a 99.

el primero o el ltimo valor, respectivamente, en cada una de las particiones no

vlidas adyacentes a la particin vlida (0 y 100 en este caso).En este ejemplo
tendramos tres pruebas de equivalencia de particin (uno de cada una de las
tres particiones) y cuatro pruebas de contorno.

Considere el sistema bancario se describe en la seccin sobre la

equivalencia parti-namiento.

Debido a que los valores lmite se definen como aquellos valores en el borde
de una particin, se han identificado los siguientes valores lmite: - $ 0.01 (un
valor lmite vlido, ya que est en el borde de una particin no vlido), $ 0,00,
$ 100.00 $ 100.01, $ 999.99 y $ 1000.00 todos los valores lmite vlidos.

As que mediante la aplicacin de anlisis de valores lmite tendremos seis

pruebas para los valores lmite. Compara lo que nuestro modelo de prueba ingenua
Robbie haba hecho; hizo realidad golpe a uno de los valores lmite ($ 100) a
pesar de que era ms por accidente que el diseo. As, adems de las pruebas de
slo la mitad de las particiones, Robbie slo ha probado una sexta parte de las
fronteras (por lo que ser menos eficaz en la bsqueda defectos de contorno). Si
tenemos en cuenta todas nuestras pruebas, tanto para la particin de equivalencia y
anlisis de valores lmite, las tcnicas nos dan un total de nueve pruebas, en

comparacin con los 16 que Robbie tena, por lo que todava son
considerablemente ms eficiente, adems de ser ms de tres veces ms eficaz
(prueba de cuatro particiones y seis sujetos, de modo aries 10 condiciones en total
en comparacin con los tres).

Tenga en cuenta que en el ejemplo de los intereses bancarios, tenemos las

particiones vlidas junto a otras particiones vlidas. Si nos vamos a considerar un
lmite vlido para el tipo de inters del 3%, que tenemos - $ 0,01, pero qu pasa
con el valor justo por encima de $ 100.00? El valor de $ 100.01 no es un lmite
vlido; en realidad es una frontera vlida porque cae en una particin vlida.As
que la particin para 5%, por ejemplo, no tiene valores de lmites no vlidos
asociados con las particiones prximos a l.

Una buena manera de representar las particiones y los lmites vlidos y no

vlidos se encuentra en una tabla como la Tabla 4.1:

Tabla 1.

particiones de equivalencia y lmites

Condiciones de
Pruebas

El equilibrio
en

aU

particiones
vlidas

particiones no
vlidas

0.00 $100.00 <21

Unt

32. > $ Max

32.

Maxma no entero (si

lmites vlidos

0.00

32.

$100.00

Maxma

32.

el equilibrio es un
insumo

Campo

lmites no vlidos

32.

$1.000.00

Maxma

Las tasas de
inters

3%

Cualquier otro valor

5%

No entero

7%

Sin intereses
calculados

No aplicable.

No aplicable.

Al mostrar los valores de la tabla, podemos ver que hay un mximo ha sido especificado para la tasa de
inters del 7%.Ahora nos gustara saber cul es el valor mximo es de un saldo de cuenta, por lo que
podemos probar ese lmite. Esto se llama una "frontera abierta", porque uno de los lados de la particin se
deja abierta, es decir, no se define. Pero eso no quiere decir que podemos ignorarlo - an debemos tratar
de probarlo, pero cmo?

fronteras abiertas son ms difciles de probar, pero hay maneras de acercarse a ellos. En realidad, la
mejor solucin al problema consiste en averiguar cul es el lmite-aria debe especificarse como! Un
mtodo consiste en volver a la especificacin para ver si un mximo ha indicado en otro lugar para una
cantidad de equilibrio. Si es as, entonces sabemos lo que nuestro valor lmite es. Otro enfoque podra ser
la de investigar otras reas conexas del sistema. Por ejemplo, el campo que contiene el saldo de la cuenta
cifra puede ser slo seis figuras ms dos cifras decimales. Esto dara un saldo de la cuenta mxima de $
999 999.99, as que podra usar eso como nuestro mximo valor lmite. Si realmente no podemos
encontrar cualquier-cosa sobre lo que debe ser este lmite, entonces es probable que utilizar un enfoque
intuitivo basado en la experiencia o para sondear diversos valores grandes que tratan de hacer que falle.

Tambin podramos tratar de averiguar sobre el lmite inferior abierto - cul es el saldo negativo ms
bajo? A pesar de que se han omitido esto desde nuestro ejemplo, para ajustarlo a cabo en la tabla muestra
que se han omitido, as nos ayuda a ser ms profunda si queramos ser.

En representacin de las particiones y los lmites de una tabla como esto tambin hace que sea ms
fcil para ver si est o no han probado cada uno (si ese es su objetivo).

La extensin de la particin de equivalencia y anlisis de valores lmite Hasta el momento, mediante

el uso de condiciones de PE y BVA que hemos identificado que podra ser probadas, es decir, las particiones y
los valores lmite.Las tcnicas se utilizan para identificar las pruebas con-diciones, que podra estar en una (por
ejemplo, "cuenta de bajo inters") bastante alto nivel o en un nivel detallado (por ejemplo, "valor de $

100.00"). Hemos estado buscando en la aplicacin de estas tcnicas a los rangos de nmeros. Sin embargo,
tambin podemos aplicar las tcnicas a otras cosas.

Por ejemplo, si se reserva un vuelo, usted tiene una opcin de entrenador, entradas Economa / Economa
Premium, Business o Primera Clase. Cada una de ellas es una particin de equivalencia en su propio derecho y
debe ser probado, pero no tiene sentido hablar de lmites para este tipo de particin, que es una coleccin de
cosas vlidos. La particin no vlida sera un intento de escribir en cualquier otro tipo de clase de vuelo (por
ejemplo 'Personal Si este campo se implementa mediante una lista desplegable, entonces no debera ser posible
escribir cualquier otra cosa, pero todava es una buena prueba para probar al menos una vez en algn campo
desplegable. Cuando est ana-lizarla, la base de prueba (por ejemplo, una especificacin de requisitos), la
particin de equivalencia puede ayudar a identificar dnde una lista desplegable sera apropiado.

Cuando se trata de identificar un defecto, puede probar con varios valores en una particin. Si esto se
traduce en un comportamiento diferente en el que esperaba que fuera el mismo, entonces puede haber dos
(o ms) particiones en el que inicialmente se pens que slo haba una.

Podemos aplicar la particin de equivalencia y anlisis de valores lmite para todos los niveles de la prueba. Los
ejemplos que aqu se encontraban en un nivel bastante detallada probablemente ms adecuado en las pruebas de
componentes o en la prueba detallada de una sola pantalla.

A nivel del sistema, por ejemplo, podemos tener tres configuraciones bsicas que nuestros usuarios pueden
elegir la hora de establecer sus sistemas, con una serie de opciones para cada configuracin.Las
configuraciones bsicas podran ser administrador del sistema, gestor y el enlace al cliente. Estos representan
tres particiones equiva-lencia que podran ser probados. Podramos tener serios problemas si nos olvidamos de
poner a prueba la configuracin para el administrador del sistema, por ejemplo.

Tambin podemos aplicar la particin de equivalencia y anlisis de valores lmite ms de una vez para el mismo
elemento de la especificacin. Por ejemplo, si un sistema de tele-telfono interno para una empresa con 200
telfonos tiene un nmero de extensin de 3 dgitos desde 100 hasta 699, podemos identificar los siguientes
particiones y lmites:

dgitos (caracteres 0 a 9) con la particin no vlida que no contienen dgitos

nmero de dgitos, 3 (valores lmite por lo que no vlidas de 2 dgitos y 4 dgitos)

rango de nmeros de extensin 100 a 699 (valores de lmite de modo no vlidos de 099 y 700)

extensiones que estn en uso y las que no lo son (dos particiones vlidas, no hay lmites)

los nmeros de extensin menor a mayor y que estn en uso tambin se podran utilizar como
valores de lmite

Un caso de prueba podra probar ms de una de estas particiones / lmites. Por ejemplo, la extensin
409 que se encuentra en uso podra probar cuatro particiones vlidas: dgitos, el nmero de dgitos, el
rango vlido, y la particin 'en uso'. Tambin evala los valores lmite para los dgitos, 0 y 9.

Cuntos casos de prueba qu tenemos que probar todas estas particiones y lmites, tanto vlidos y no
vlidos? Necesitaramos un no-dgitos, un nmero de 2 dgitos y 4 dgitos, los valores de 99, 100, 699 y
700, una extensin que no est en uso, y, posiblemente, las extensiones de menor a mayor y en uso. Se
trata de diez u once casos de prueba - el nmero exacto depender de lo que se podra combinar en un
caso de prueba.

Compare esto con el ejemplo nmero de un dgito en la Seccin 1.1.6. Aqu encontramos que tenamos
68 pruebas slo para probar un campo de un dgito, si tuviramos que probarlo a fondo. En el
particionado equivalencia y anlisis de valores lmite nos ayuda a identificar las pruebas que tienen ms
probabilidades de encontrar defectos, y utilizar un menor nmero de casos de prueba para encontrarlos.
Esto es porque el contenido de una particin son representativos de todos los valores posibles. En lugar
de prueba de los diez dgitos individuales, probamos uno en el medio (por ejemplo, 4) y los dos bordes (0
y 9). En lugar de probar todos los personajes posi-ble no sea un dgito, se puede representar a todos ellos.
As que tenemos cuatro pruebas (en lugar de 68) para un campo de un dgito.

Como hemos mencionado anteriormente, tambin podemos aplicar estas tcnicas a la salida de par-ticiones.
Considere la siguiente extensin a nuestro ejemplo del tipo de inters bancario. Supongamos que un cliente
con ms de una cuenta puede tener un inters adicional del 1% sobre esta cuenta si tienen al menos 1000 $ en
ella. Ahora tenemos dos valores de salida pos-ble (7% de inters y un 8% de inters) para el mismo saldo de la
cuenta, por lo que hemos identificado otra condicin de prueba (tasa de inters del 8%). (Es posible que
tambin hemos identificado esa misma condicin de salida examinado los clientes con ms de una cuenta, la
cual es una particin del tipo de cliente.)

particin de equivalencia se puede aplicar a diferentes tipos de entrada tambin. Nuestros ejemplos se han
concentrado en las entradas que se escriben en un usuario (humano) cuando se utiliza el sistema. Sin embargo,
los sistemas reciben datos de entrada de otra

fuentes, as, como de otros sistemas a travs de alguna de las interfaces - esto es tambin un buen lugar
para buscar las particiones (y los lmites).Por ejemplo, el valor de un parmetro de la interfaz puede caer
en particiones de equivalencia vlidos y no vlidos. Este tipo de defecto es a menudo difcil de encontrar
en las pruebas una vez que las interfaces se han unido, de modo es particularmente til para aplicar en las
pruebas de integracin (ya sea la integracin de componentes o la integracin del sistema).

anlisis de valores lmite se puede aplicar a la totalidad de una serie de carac-tros (por ejemplo, un
nombre o direccin). El nmero de caracteres de la cadena es un par-la com-, por ejemplo, entre 1 y 30
caracteres es la particin vlida con los lmites vlidos de 1 y 30. Los lmites no vlidos seran caracteres
(0 nulo, simplemente pulse la tecla de retorno) y 31 caracteres. Ambas deberan producir un mensaje de
error.

Particiones tambin pueden identificarse cuando la creacin de datos de prueba. Si hay diferir-rentes tipos de
registro, ser la prueba ms representativa si se incluye un registro de datos de cada tipo. El tamao de un registro
es tambin una particin con los lmites, por lo que podra incluir registros mximos y mnimos de tamao en la
base de datos de prueba.

Si usted tiene algn conocimiento acerca de cmo el interior de los datos es fsicamente rgano-izada,
puede ser capaz de identificar algunos lmites ocultos. Por ejemplo, si se utiliza un bloque de almacenamiento
de desbordamiento cuando se introducen ms de 255 caracteres en un campo, las pruebas de contorno
incluiran 255 y 256 caracteres en este campo. Esto se puede raya en pruebas de caja blanca, ya que tenemos
algn conocimiento de cmo est estructurado de los datos, pero no importa cmo clasificamos las cosas,
siempre y cuando nuestra prueba es eficaz en la bsqueda de defectos. No se colg en una fina distincin-cin
- acaba de hacer lo que la prueba tiene sentido, sobre la base de lo que sabe. Un viejo proverbio chino dice:
"No importa si el gato es blanco o negro; lo nico que importa es que el gato cace ratones ".

Con el anlisis de valores en la frontera, pensamos en la frontera como una lnea divisoria entre dos
cosas. Por lo tanto tenemos un valor a cada lado de la frontera (pero el lmite en s no es un valor).

Invlido

Vlido

0 "1

Invlido

99 "TOO

En cuanto a los valores de nuestro ejemplo de la impresora, es 0 en una particin vlida, 1 y 99 estn
en la particin vlida y 100 est en la otra particin vlida. As que el lmite se encuentra entre los valores
de 0 y 1, y entre los valores de 99 y 100. Hay una escuela de pensamiento que considera un valor real

como un valor lmite. Por tradicin, estos son los valores de la particin vlida (es decir, los valores
especificados). Este enfoque requiere entonces tres valores por cada dos lmites, por lo que tendra 0,1 y
2 para el lmite izquierdo, y 98, 99 y 100 para el lmite derecho en este ejemplo. Los valores lmite se
dice que son "en y cada lado de la frontera 'y el valor que es' on 'se toma generalmente el lmite para estar
en la particin vlida.

Tenga en cuenta que Beizer habla acerca de las pruebas de dominio, una generalizacin de la
reparticin equiva-lencia, con lmites de tres valores. Se hace una distincin entre fronteras abiertas y
cerradas, donde un contorno cerrado es aquel en que se incluye el punto en el dominio. Por lo que la
convencin es vlida para la parti-cin de tener fronteras cerradas. Es posible que se alegrarn de saber
que usted no tiene que saber esto para el examen! British Standard 7925-2 estndar para el software de
pruebas de componentes tambin define un enfoque de tres valores de anlisis de valores lmite.

Entonces, cul es el mejor enfoque?Si se utiliza el mtodo de dos valor junto con la particin de
equivalencia, que son igualmente eficaces y ligeramente ms eficiente que el enfoque de tres valores. (No
vamos a entrar en detalles aqu, pero esto se puede demostrar.) En este libro vamos a utilizar el enfoque
de dos valores. En el examen, es posible que tenga una pregunta basada en cualquiera de los dos-valor o
el enfoque de tres valores, pero debe quedar claro cul es la opcin correcta es en ambos casos.

El diseo de casos de prueba

Una vez identificadas las condiciones que desea probar, en este caso mediante el uso de particiones de equivalencia
y anlisis de valores lmite, el siguiente paso es el diseo de los casos de prueba. Los ms condiciones de prueba que
pueden ser cubiertos en un solo caso de prueba, se necesitarn menos los casos de prueba con el fin de cubrir todas
las condiciones. Este suele ser el mejor enfoque a adoptar para las pruebas positivas y para las pruebas que usted es
rea-blemente confianza va a pasar. Sin embargo, si no pasa la prueba, entonces tenemos que averiguar por qu ha
fallado - el cual las condiciones de ensayo fue manejado de forma incorrecta? Tenemos que conseguir un buen
equilibrio entre cubrir demasiados y demasiado pocas condiciones de prueba en nuestras pruebas.

Veamos cmo un caso de prueba puede cubrir una o ms condiciones de ensayo. Usando el ejemplo de
balance de los bancos, nuestra primera prueba podra ser de un nuevo cliente con un saldo de $ 500. Esto
cubrira un equilibrio en la particin desde $ 100.01 a $ 999.99 y una particin de salida de una tasa de
inters del 5%. Tambin estaramos cubierta-ing otras particiones que an no hemos explicado. por
ejemplo, un cliente vlido, un nuevo cliente, un cliente con una sola cuenta, etc. Todas las particiones
cubiertos en esta prueba son las particiones vlidas.

Cuando llegamos a probar particiones no vlidas, la opcin ms segura es probablemente para tratar de
cubrir slo una condicin de prueba vlida por caso de prueba. Esto es porque los programas pueden detener el
procesamiento de entrada tan pronto como se encuentran con el primer problema. As que si usted tiene un
nombre no vlido al cliente, direccin no vlida, y el equilibrio no vlida, puede recibir un mensaje de error

que dice "entrada no vlida" y usted don "t saber si la prueba ha detectado slo una entrada vlida o todos
ellos. (Esta es tambin la razn por mensajes de error especficos son mucho mejores que los generales!)

Sin embargo, si se sabe que se requiere el software bajo prueba para procesar todas las entradas
independientemente de su validez, entonces es razonable continuar como antes los casos de prueba y de
diseo que cubren la mayor cantidad de condiciones no vlidos en una sola vez como sea posible. Por
ejemplo, si cada campo no vlido en un formulario tiene un texto de color rojo por encima o por debajo
del campo diciendo que este campo no es vlido y por qu, entonces usted sabe que cada campo se ha
comprobado, por lo que han probado todo el procesamiento de error en una prueba caso. En cualquier
caso, no debera haber casos de prueba separados acerca de las con-diciones vlidas y no vlidas.

Para cubrir los casos de prueba de contorno, puede ser posible combinar todos los lmites mnimos
vlidos para un grupo de campos en un caso de prueba y tambin los valores mximos de contorno. Los
lmites no vlidos podran ser probados juntos si la validacin se realiza en todos los campos; de lo
contrario, deben ser probados por separado, como con las particiones no vlidos.

Por qu tanto la particin de equivalencia y anlisis de valores lmite?

Tcnicamente, porque cada lmite es de alguna particin, si slo has obligado-aria anlisis de valor tambin se
habran puesto a prueba todas las particiones de equivalencia. Sin embargo, este enfoque puede causar problemas si
ese valor no - era slo el valor lmite que fall o dej toda la particin? Tambin mediante el ensayo solamente

lmites que probablemente no dar a los usuarios tanta confianza como estamos utilizando valores
extremos en lugar de los valores normales.Los lmites pueden ser ms difciles (y por lo tanto ms
costoso) para establecer as.

Por ejemplo, en el ejemplo de copias de impresora descrito anteriormente se identificaron los

siguientes valores lmite:

Supongamos que prueba slo los lmites vlidos los valores 1 y 99 y nada en el medio. Si pasan ambas
pruebas, esto parece indicar que todos los valores intermedios tambin deben trabajar. Sin embargo,
supongamos que una pgina se imprime correctamente, pero 99 pginas no lo hacen. Ahora no sabemos
si cualquier conjunto de ms de una pgina funciona, as que lo primero que hara sera poner a prueba
por ejemplo, 10 pginas, es decir, un valor de la particin de equivalencia.

Le recomendamos que pruebe las particiones por separado de las fronteras - esto significa elegir
valores de particin no son valores lmite.

Sin embargo, si se utiliza el mtodo del valor lmite de tres valores, entonces usted tendra valores
lmite vlidos de 1, 2, 98 y 99, por lo que tiene un valor equiv-alence separada, adems de los dos valores
lmites adicionales no dara mucho adicional beneficio. Pero notar que el valor uno equivalencia, por
ejemplo 10, reemplaza ambos de los dos valores lmite adicionales (2 y 98). Esta es la razn por la
equivalencia particin-cin con el anlisis de valores lmite de dos valores es ms eficiente que el anlisis
de valores lmite de tres valores.

Qu particiones y los lmites que decida ejercer (no es necesario para poner a prueba a todos ellos), y
para que usted decida poner a prueba en primer lugar, depende de sus objetivos de la prueba. Si su
objetivo es el enfoque ms a fondo, a continuacin, siga el pro-cedimiento de prueba particiones vlidas
en primer lugar, a continuacin, las particiones no vlidas, entonces los lmites vlidos y no vlidos
finalmente lmites. Sin embargo, si usted est bajo la presin del tiempo y no se puede probar todo (y
quin no lo es?), A continuacin de la prueba obje-tantes le ayudarn a decidir qu vamos a probar. Si
usted est despus de la confianza del usuario de las operaciones tpicas con un nmero mnimo de
pruebas, puede hacer vlidos slo par-ticiones. Si desea encontrar el mayor nmero posible de defectos
tan pronto como sea pos-bles, que pueden comenzar con los valores lmite, vlidas y no vlidas. Si desea
la confianza de que el sistema se encargar de malas entradas correctamente, es posible hacer las
particiones y los lmites sobre todo no vlidos. Su experiencia previa de los tipos de defectos encontrados
puede ayudar a encontrar defectos similares; por ejemplo, si normalmente hay una serie de defectos de
contorno, entonces usted podra empezar por probar lmites.

particionamiento equivalencia y anlisis de valores lmite se describen en la mayora de los libros de

pruebas, incluido [Myers, 1979] y [Copeland, 2003]. Ejemplos de tipos de clases de equivalencia a tener en
cuenta se dan en [Kaner et al., 1993] Equivalencia separacin y anlisis de valores lmite se describen en
BS7925-2, incluyendo el diseo de pruebas y medicin de la cobertura.

prueba de la mesa 4.3.2 Decisin

Por qu utilizar las tablas de decisin ?.

Las tcnicas de particin de equivalencia y anlisis de valores lmite se aplican a menudo a situaciones o insumos
especficos. Sin embargo, si diferentes combinaciones

de insumos como resultado diferentes acciones emprendidas, esto puede ser ms difcil de demostrar con
el particionado equivalencia y anlisis de valores lmite, que tienden a estar ms centrado en la interfaz de
usuario.Los otros dos tech-tcnicas basadas en las especificaciones, tablas de decisin y las pruebas de
transicin de estado se centran ms en la lgica de negocio o de reglas de negocio.
Una tabla de decisin es una buena manera de hacer frente a las combinaciones de las cosas (por
ejemplo, entradas).Esta tcnica a veces tambin se conoce como una tabla 'causa-efecto'. La razn de esto
es que no es una tcnica de diagramas lgica asociada llamada 'causa-efecto grfica' que a veces se utiliza
para ayudar a derivar la tabla de decisin (Myers describe esto como una red lgica combinatoria [Myers,
1979]). Sin embargo, la mayora de las personas les resulta ms til slo para usar la tabla se describe en
[Copeland, 2003].

Si comenzar a utilizar las tablas de decisin para explorar lo que se deben probar las reglas de negocio,
es posible que los analistas y desarrolladores a encontrar tablas muy tiles y quieren empezar a usarlos
tambin. Anime a esto, ya que har ms fcil su trabajo en el futuro. Las tablas de decisin proporcionan
una forma sistemtica de enunciar reglas de negocio complejas, que es til para los desarrolladores, as
como para los probadores. Las tablas de decisin se pueden utilizar en el diseo de pruebas o no se
utilizan en las especificaciones, ya que ayudan a los probadores de explorar los efectos de combinaciones
de entradas dif rentes y otros estados de software que deben aplicar correctamente las reglas de negocio.
Ayudar a los desarrolladores hacer un mejor trabajo tambin puede conducir a mejores relaciones naves
con ellos.

combinaciones de prueba puede ser un reto, ya que el nmero de combinaciones a menudo puede ser
enorme. Probar todas las combinaciones puede ser poco prctico, si no impo-sible. Tenemos que estar
satisfecho con las pruebas de slo un pequeo subconjunto de combinaciones, pero tomar la decisin de
qu combinaciones para probar y para dejar de lado no es trivial. Si usted no tiene una forma sistemtica
de la seleccin de combinaciones, un subconjunto arbitrario ser utilizado y esto puede dar lugar a un
esfuerzo de la prueba ineficaz.

Las tablas de decisin ayudar a la seleccin sistemtica de casos de prueba eficaces y pueden tener el
efecto secundario beneficioso de encontrar problemas y ambigedades en la especificacin-ficacin. Es
una tcnica que funciona bien en conjunto con la equivalencia par-titioning. La combinacin de
condiciones explorado puede ser combinaciones de particiones de equivalencia.

Adems de las tablas de decisin, hay otras tcnicas que tienen que ver con las combinaciones de
pruebas de cosas: las pruebas por parejas y matrices ortogonales. Estos se describen en [Copeland, 2003].
Otra fuente de tcnicas es [Pol et al., 2001].Las tablas de decisin y de causa-efecto grfica se describen
en [BS7925-2], incluyendo el diseo de pruebas y medicin de la cobertura.

Utilizando las tablas de decisin para el diseo de la prueba

La primera tarea es identificar una funcin o subsistema adecuado que tiene un comportamiento que reacciona
de acuerdo con una combinacin de entradas o eventos. La conducta de inters no debe ser demasiado extensa
(es decir, no debe contener demasiadas entradas) OTH-De otra el nmero de combinaciones ser hecho muy
pesado y difcil de manejar. Es mejor tratar con un gran nmero de condiciones mediante la divisin en
subconjuntos y hacer frente a los subconjuntos de uno en uno.

Una vez que haya identificado los aspectos que deben ser combinados, a continuacin, se los pone en una tabla
con todas las combinaciones de verdadero y falso para cada uno de los aspectos. Tomemos un ejemplo de una
solicitud de prstamo, donde se puede introducir el importe

de la cuota mensual o el nmero de aos que desea tomar para devolver el dinero (el trmino del
prstamo).Si introduce tanto, el sistema har un compro-puesta entre los dos si entran en conflicto. Las
dos condiciones son la cantidad del prstamo y el trmino, por lo que los ponen en una tabla (ver Tabla
4.2).

TABLA 4.2

condiciones

Tabla de decisin vaca

Regla 1

regla 2

regla 3

regla 4

importe de la devolucin se ha introducido

Plazo del prstamo se ha introducido

A continuacin vamos a identificar todas las combinaciones de verdadero y falso (ver Tabla 4.3). Con dos
condiciones, cada uno de los cuales puede ser verdadera o falsa, tendremos cuatro combinaciones (dos a la
potencia del nmero de cosas para ser combinados). Tenga en cuenta que si tenemos tres cosas para combinar,
tendremos ocho combinaciones, con cuatro cosas, hay 16, etc. Es por esto que es bueno para hacer frente a
pequeos grupos de com-binaciones a la vez. Con el fin de realizar un seguimiento de cules son las
combinaciones que tenemos, vamos a alternar verdadero y falso en la fila inferior, poner dos Trues y luego dos

Falses en la fila encima de la fila inferior, etc., por lo que la fila superior tendr todos los verdaderos y luego
todos Falses (y este principio se aplica a todos sus tablas).

TABLA 4.3

Tabla de decisiones con combinaciones de entradas

Condiciones

importe de reembolso
tiene

Regla 44.

Regla 44.

F13.
Personal de
recursos
humanos
saben, y
llevar a la
organizaci
n, las
mejores
prcticas en
la gestin
de la
carrera.

Regla 44.

Regla 44.

F13.
Personal de
recursos
humanos
saben, y
llevar a la
organizacin,
las mejores
prcticas en
la gestin de
la carrera.

F13.
Personal de
recursos
humanos
saben, y
llevar a la
organizaci
n, las
mejores
prcticas en
la gestin
de la
carrera.

F13.
Personal de
recursos
humanos
saben, y
llevar a la
organizaci
n, las
mejores
prcticas en
la gestin
de la
carrera.

adolescente entr

Plazo del prstamo ha

sido

ingresados

El siguiente paso (al menos para este ejemplo) es identificar el resultado correcto para cada
combinacin (vase la Tabla 4.4). En este ejemplo, podemos entrar en uno o ambos de los dos campos.
Cada combinacin se refiere a veces como una regla.

TABLA 4.4

Tabla de decisiones con combinaciones y resultados

Condiciones

importe de reembolso
tiene

Regla 44.

Regla 44.

Regla 44.

Regla 44.

F13.
Personal de
recursos
humanos
saben, y
llevar a la
organizaci
n, las
mejores
prcticas en
la gestin
de la
carrera.

F13.
Personal de
recursos
humanos
saben, y
llevar a la
organizaci
n, las
mejores
prcticas en
la gestin
de la
carrera.

F13.
Personal de
recursos
humanos
saben, y
llevar a la
organizaci
n, las
mejores
prcticas en
la gestin
de la
carrera.

ha introducido

F13.
Personal de
recursos
humanos
saben, y
llevar a la
organizacin,
las mejores
prcticas en
la gestin de
la carrera.

monto del prstamo

Proceso

SI

SI

proceso plazo

SI

Plazo del prstamo ha

sido

ingresados

Acciones / Resultados

SI

En este punto, podemos darnos cuenta de que no habamos pensado en lo que sucede si el cliente no
entra nada en ninguno de los dos campos.La tabla ha puesto de relieve una combinacin que no fue
mencionado en el pliego de condiciones de este ejemplo. Podramos suponer que esta combinacin
debera dar como resultado un mensaje de error, por lo que tenemos que aadir otra accin (vase el
cuadro 4.5). Esta alta ilumina la fuerza de esta tcnica para descubrir omisiones y ambigedades en las
especificaciones. No es inusual para algunas combinaciones para ser omitidos de las especificaciones;
Por lo tanto, esto tambin es una tcnica valiosa para utilizar cuando revisin-cin de la base de pruebas.

{0}Tabla 2.{/0} {1} {/1} 5

Condiciones

importe de reembolso tiene

Tabla de decisiones con resultados adicionales

Regla 44.

Regla 44.

F13. Personal
de recursos
humanos
saben, y llevar
a la
organizacin,
las mejores
prcticas en la
gestin de la
carrera.

Regla 44.

Regla 44.

F13.
Personal de
recursos
humanos
saben, y
llevar a la
organizaci
n, las
mejores
prcticas en
la gestin
de la
carrera.

F13.
Personal de
recursos
humanos
saben, y
llevar a la
organizaci
n, las
mejores
prcticas en
la gestin
de la
carrera.

F13.
Personal de
recursos
humanos
saben, y
llevar a la
organizacin
, las mejores
prcticas en
la gestin de
la carrera.

ha introducido

Plazo del prstamo ha sido

ingresados

Acciones / Resultados

monto del prstamo Proceso

SI

proceso plazo

SI

SI

SI

Mensaje de error

SI

Supongamos que cambiamos nuestro ejemplo ligeramente, de manera que el cliente no se le permite entrar tanto
de pago y plazo. Ahora nuestra mesa va a cambiar, ya que debera haber tambin un mensaje de error si se
introducen, por lo que se ver como la tabla 4.6.

{0}Tabla 2.{/0} {1} {/1} 6

Condiciones

importe de reembolso tiene

Tabla de decisiones con las modificaciones de los resultados

Regla 44.

Regla 44.

F13. Personal
de recursos
humanos
saben, y llevar
a la
organizacin,
las mejores

Regla 44.

F13.
Personal de
recursos
humanos
saben, y
llevar a la
organizaci
n, las
mejores
prcticas en
la gestin
de la
carrera.

Regla 44.

F13.
Personal de
recursos
humanos
saben, y
llevar a la
organizaci
n, las
mejores
prcticas en
la gestin
de la
carrera.

ha introducido

Plazo del prstamo ha sido

F13.
Personal de
recursos
humanos
saben, y
llevar a la
organizacin

, las mejores
prcticas en
la gestin de
la carrera.

prcticas en la
gestin de la
carrera.

ingresados

Acciones / Resultados

monto del prstamo Proceso

SI

proceso plazo

Mensaje de error

SI

SI

SI

Usted puede notar ahora que slo hay un "S" en cada columna, es decir, nuestras acciones son mutuamente
excluyentes - una sola accin se produce para cada combinacin de condiciones. Podramos representar esto de
una manera diferente haciendo una lista de las acciones en la celda de una fila, como se muestra en la Tabla
4.7. Tenga en cuenta que si hay ms de una accin se produce por cualquiera de las combinaciones, entonces
sera mejor para mostrarles como filas separadas en lugar de combinarlos en una fila.

Tabla 2.

Condiciones

Tabla de decisiones con los resultados en una fila

Regla 44.

Regla 44.

Regla 44.

Regla 44.

importe de reembolso tiene

F13.
Personal de
recursos
humanos
saben, y
llevar a la
organizaci
n, las
mejores
prcticas en
la gestin
de la
carrera.

F13.
Personal de
recursos
humanos
saben, y
llevar a la
organizaci
n, las
mejores
prcticas en
la gestin
de la
carrera.

F13.
Personal de
recursos
humanos
saben, y
llevar a la
organizaci
n, las
mejores
prcticas en
la gestin
de la
carrera.

ha introducido

Plazo del prstamo ha sido

F13. Personal
de recursos
humanos
saben, y llevar
a la
organizacin,
las mejores
prcticas en la
gestin de la
carrera.

ingresados

Acciones / Resultados

Resultado

Rrror

mensaje

El proceso de
prstamo

suma

Proceso

Rrror

term

mensaje

El paso final de esta tcnica es escribir casos de prueba para ejercer cada uno de los cuatro reglas en
nuestra mesa.
En este ejemplo empezamos mediante la identificacin de las condiciones de entrada y luego identificar los resultados. Sin embargo, en la prctica podra funcionar al revs - podemos ver que hay una
serie de resultados diferentes, y tienen que trabajar de nuevo a comprender qu combinacin de
condiciones de entrada en realidad conducir esos resultados. La tcnica funciona igual de bien lo hace de

esta manera, y bien puede ser un enfoque iterativo a medida que descubre ms sobre las reglas que
impulsan el sistema.

tarjeta de crdito ejemplo prctico

Veamos otro ejemplo. Si usted es un nuevo cliente de abrir una cuenta de tarjeta de crdito, recibir un
descuento del 15% en todas sus compras hoy. Si usted es un cliente existente y se tiene una tarjeta de
fidelizacin, se obtiene un descuento del 10%. Si usted tiene un cupn, puede obtener 20% de descuento
en la actualidad (pero no puede ser utilizado con el descuento 'nuevo cliente'). Se aaden cantidades de
descuento, si procede. Esto se muestra en la Tabla 4.8.

{0}Tabla 2.{/0} {1} {/1} 8

Tabla de decisiones, por ejemplo, tarjeta de crdito

En la Tabla 4.8, las condiciones y las acciones se enumeran en la columna de la izquierda. Todas las
dems columnas de la tabla de decisin representan cada uno un estado separado, uno para cada
combinacin de condiciones. Podemos optar por probar cada regla / combinacin y si hay slo unos
pocos lo cual suele ser el caso. Sin embargo, si el nmero de reglas / combinaciones es grande, es ms
probable a la muestra mediante la seleccin de un subconjunto rico para la prueba.

Tenga en cuenta que hemos puesto X para el descuento para dos de las columnas (Reglas 1 y 2) - esto
significa que esta combinacin no debe ocurrir.No se puede ser a la vez un nuevo cliente y ya sostener
una tarjeta de fidelidad! Debe haber un mensaje de error que indica esto, pero incluso si no sabemos cul
debera ser ese mensaje, todava har una buena prueba.

Hemos hecho una suposicin en la Regla 3. Desde el cupn tiene un descuento mayor que el descuento
de cliente nuevo, suponemos que el cliente elegir el 20% en lugar del 15%. No podemos aadirlos, ya
que el cupn no se puede utilizar con el descuento 'nuevo cliente'. La accin del 20% es una suposicin de
nuestra parte, y que debe comprobar que esta suposicin (y cualquier otro suposiciones que hacemos) es
correcta, pidiendo a la persona que escribi la especificacin o los usuarios.

Por regla 5, sin embargo, podemos aadir los descuentos, ya que deben aplicarse tanto en el cupn y el
descuento tarjeta de fidelidad (al menos esa es nuestra hiptesis).

Reglas 4, 6 y 7 tienen un solo tipo de descuento y el Artculo 8 no tiene descuento. por lo que 0%.

Si estamos aplicando esta tcnica a fondo, tendramos una prueba para cada columna o regla de nuestra
tabla de decisiones. La ventaja de hacer esto es que podemos probar una combinacin de cosas que de
otro modo quizs no nos hemos probado y que pudimos encontrar un defecto.

Sin embargo, si tenemos una gran cantidad de combinaciones, puede que no sea posible o razonable
para probar todas las combinaciones. Si estamos con limitaciones de tiempo, es posible que no tenemos
tiempo para probar todas las combinaciones. No asuma que todas las combinaciones deben ser probados;
es mejor para priorizar y probar las combinaciones ms importantes. Tener la tabla completa nos permite
ver qu combinaciones que decidimos probar y que no para poner a prueba esta vez.

Tambin puede haber muchas acciones diferentes como resultado de las combinaciones de
condiciones. En el ejemplo anterior que acabamos de tener una: el descuento que se aplicar. La tabla de
decisin muestra las acciones que se aplican a cada combinacin de condiciones.

En el ejemplo anterior todas las condiciones son binarias, es decir, tienen slo dos valores posibles:
Verdadero o Falso (o, si lo prefiere S o No). A menudo es el caso que las condiciones son ms complejas, que
tienen potencialmente muchos valores posibles. Cuando este es el caso es probable que sea muy grande el
nmero de combinaciones, por lo que las combinaciones slo puede ser muestreada en lugar de ejercer todos
ellos.

Prueba de Estado de Transicin

Pruebas de transicin de estados se utiliza cuando algn aspecto del sistema puede ser se describe en lo
que se llama una "mquina de estados finitos '.Esto simplemente significa que el sistema puede estar en
un nmero (finito) de diferentes estados y las transiciones de un estado a otro estn determinados por las
reglas de la "mquina". Este es el modelo en que se basa el sistema y las pruebas. Cualquier sistema en el
que se obtiene una salida diferente para la misma entrada, dependiendo de lo que ha ocurrido antes, es un
sistema de estados finitos. Un sistema de estados finitos se muestra a menudo como un diagrama de
estado (vase la Figura 4.2).

Por ejemplo, si solicita a retirar $ 100 de un cajero automtico, se le puede dar dinero en efectivo. Ms
adelante puede hacer exactamente la misma peticin, pero se neg el dinero (ya que su saldo es insuficiente).
Esta tarde rechazo es porque el estado de su cuenta bancaria ha pasado de tener fondos suficientes para cubrir

la retirada de tener fondos insuficientes.La operacin que caus su cuenta para cambiar su estado era
probablemente la retirada anterior. Un diagrama de estados puede representar un modelo desde el punto
de vista del sistema, la cuenta o el cliente.

Otro ejemplo es un procesador de textos. Si un documento est abierto, usted es capaz de cerrarla. Si no hay
ningn documento abierto, luego 'Cerrar' no est disponible. Despus de elegir "Cerrar" una vez, no se puede
elegir de nuevo para el mismo documento a menos que se abre el documento. As, un documento tiene dos
estados: abierta y cerrada.

Un modelo de transicin de estado tiene cuatro partes bsicas:

los estados que el software puede ocupar (abierto / cerrado o financiado / fondos insuficientes);

las transiciones de un estado a otro (no se permiten todas las transiciones);

los eventos que causan una transicin (el cierre de un archivo o la retirada de dinero);

las acciones que se derivan de una transicin (un mensaje de error o est dando su dinero en
efectivo).

Tenga en cuenta que en cualquier estado dado, un evento puede causar una sola accin, pero que el
mismo evento - de un estado diferente - puede causar una accin diferente y un estado final di-ferentes.
Vamos a ver por primera vez en los casos de prueba que ejecutan las transiciones de estado vlidos.

La figura 4.2 muestra un ejemplo de introducir un nmero de identificacin personal (PIN) a una
cuenta bancaria. Los estados se muestran como crculos, las transiciones como lneas con flechas y los
eventos como el texto cercano a las transiciones. (No hemos mostrado las acciones explcitamente en este
diagrama, pero sera un mensaje al cliente diciendo cosas tales como "Por favor, introduzca su PIN '.)

El diagrama de estados muestra siete estados pero slo cuatro eventos posibles (tarjeta insertada, introduzca
el PIN, PIN y el PIN OK no OK). No hemos especificado todas las posibles transiciones aqu - tambin habra
un tiempo de espera de "esperar a que el PIN 'y desde los tres intentos que se remontan al estado inicial una
vez transcurrido el tiempo y, probablemente extraer la tarjeta. Tambin habra una transi-cin del estado
"comer la tarjeta 'de nuevo al estado de inicio. No hemos especificado todos los eventos posibles, ya sea - que
habra una opcin "cancelar" de "esperar a que el PIN '

y desde los tres intentos, lo que tambin se remontan al estado de inicio y extraer la tarjeta.El estado de
cuenta de acceso 'sera el comienzo de otro diagrama de estado que muestra las transacciones vlidas que
pueden ser asumidas en la cuenta.

Sin embargo, este diagrama de estado, a pesar de que es incompleta, todava nos da infor-macin en la
que el diseo de algunas pruebas tiles y para explicar la tcnica de transicin de estado.

Al derivar casos de prueba, podemos empezar con un escenario tpico. Un primer caso de prueba
sensata en este caso sera la situacin normal, donde se introduce el PIN correcto la primera vez. Para ser
ms profundo, es posible que queremos estar seguros de que cubrimos todos los estados (es decir, al
menos una prueba pasa por cada estado) o es posible que queramos cubrir cada transicin. Una segunda
prueba (para visitar todos los estados) sera la de introducir un PIN incorrecto cada vez, por lo que el
sistema se come la tarjeta. Todava no hemos probado cada transicin todava. Con el fin de hacer eso,
nos gustara una prueba en la que el PIN es incorrecta la primera vez, pero est bien la segunda vez, y otra
prueba donde el PIN era correcta en el tercer intento. Estas pruebas son probablemente menos importante
que los dos primeros.

Tenga en cuenta que una transicin no tiene que cambiar a un estado diferente (aunque todas las
transiciones que se muestran arriba que ir a un estado diferente). Por lo que podra ser una transicin de la
'cuenta de acceso ", que simplemente se remonta a' cuenta de acceso" para una accin como "equilibrio
solicitud '.

Las condiciones de ensayo se pueden derivar de la grfica del estado de varias maneras. Cada estado puede
sealarse como una condicin de prueba, al igual que cada transicin. En el Syllabus, tenemos que ser capaces
de identificar la cobertura de una serie de pruebas en cuanto a las transiciones.

Yendo ms all del nivel esperado en el Syllabus, tambin podemos considerar pares y triples tran-sicin y
as sucesivamente. La cobertura de todas las transiciones individuales tambin se conoce como cobertura 0interruptor, la cobertura de pares de transicin es la cobertura l-interruptor, la cobertura de la transicin se
triplica la cobertura de 2 controles, etc. derivando los casos de prueba a partir del modelo de transicin de
estados es un enfoque de recuadro negro . La medicin de la cantidad que han probado (cubierta) se est
acercando a un punto de vista de caja blanca. Sin embargo, las pruebas de transicin de estado se considera
como una tcnica de recuadro negro.

Una de las ventajas de la tcnica de transicin de estados es que el modelo puede ser tan detallada o tan
abstracto como usted necesita que sea. Cuando una parte del sistema es ms importante (es decir, requiere
ms pruebas) una mayor profundidad de detalle puede ser modelado. Cuando el sistema es menos

importante (requiere menos pruebas), el modelo se puede utilizar un solo estado para significar lo que
sera una serie de diferentes estados.

Las pruebas para las transiciones no vlidas

Derivacin de pruebas slo a partir de un diagrama de estados (tambin conocido como un diagrama de
estado) es muy bueno para ver las transiciones vlidas, pero no puede ver con facilidad las pruebas
negativas, donde tratamos de generar transiciones no vlidas. Con el fin de ver el nmero total de
combinaciones de estados y transiciones, vlidas y no vlidas, una tabla de estados es til.

La tabla de estado se enumeran todos los estados en un lado de la mesa y todos los eventos que causan las
transiciones a lo largo de la parte superior (o viceversa). Cada celda representa entonces un par estado evento.
El contenido de cada celda indica que el estado del sistema se mover a, cuando el evento correspondiente se
produce mientras que en el estado asociado. Esto incluir los posibles eventos errneos - acontecimientos que
no se espera que ocurra en ciertos estados. Estas son las condiciones de ensayo negativas.

La Tabla 4.9 enumera los estados de la primera columna y las posibles entradas en la fila superior. As,
por ejemplo, si el sistema est en el estado 1, la insercin de una tarjeta de la llevar al estado 2. Si
estamos en el estado 2, y se introduce un PIN vlido, vamos al Estado 6 para acceder a la cuenta. En el
estado 2 si introduce un nmero incorrecto, vamos al Estado 3. Hemos puesto un guin en las clulas que
deberan ser imposible, es decir, representan transiciones no vlidas desde ese estado.

Hemos puesto un signo de interrogacin de dos clulas, en donde entramos ya sea un PIN vlido o no
vlido cuando estamos accediendo a la cuenta. Tal vez el sistema se llevar a nuestro nmero PIN como
la cantidad de dinero en efectivo a retirar? Podra ser una buena prueba! La mayora de las otras clulas
no vlidos sera fsicamente imposible en este ejemplo. pruebas no vlidas (negativos) intentarn generar
transiciones no vlidas, las transiciones que no debera ser posible (pero a menudo tomar buenas pruebas
cuando resulta que son posibles).

Una descripcin ms extensa de las mquinas de estado se encuentra en [Marick, 1994]. pruebas de
transicin de estados tambin se describe en [Craig, 2002], [Copeland, 2003], [Beizer, 1990] y
[Broekman, 2003]. pruebas de transicin de estado se describe en BS7925-2, incluyendo pruebas de
diseo y medidas de cobertura.

4.3.4 Uso pruebas de caso

Las pruebas de casos de uso es una tcnica que nos ayuda a identificar casos de prueba que ejercen el
sistema entero en una transaccin por transaccin de principio a fin.Son descritos por Ivar Jacobson en su
libro Object-Oriented Software Engineering: A Caso de uso enfoque impulsado [Jacobson, 1992].

Un caso de uso es una descripcin de un uso particular del sistema por un actor (un usuario del
sistema). Cada caso de uso describe las interacciones el actor tiene con el sistema a fin de lograr una tarea
especfica (o, al menos, producir algo de valor para el usuario). Los actores son por lo general las
personas, pero tambin pueden ser otros sistemas. Los casos de uso son una secuencia de pasos que
describen las interacciones entre el actor y el sistema.

Los casos de uso se definen en trminos del actor, no el sistema, describiendo lo que el actor hace y lo que
el actor ve ms que lo que las entradas del sistema de espera y lo que el system'outputs. A menudo utilizan el
lenguaje y los trminos de la empresa en lugar de trminos tcnicos, especialmente cuando el actor es un
negocio

Usuario.Ellos sirven como base para el desarrollo de casos de prueba sobre todo en los niveles
de prueba y aceptacin del sistema.

Los casos de uso pueden descubrir defectos de integracin, es decir, los defectos causados por la
interaccin entre los diferentes componentes incorrectos. Utilizado de esta manera, el actor puede ser algo
que las interfaces del sistema a como un enlace de comunicacin o sub-sistema.

Los casos de uso describen el proceso fluye a travs de un sistema basado en su uso ms probable. Esto
hace que los casos de prueba derivados de los casos de uso particularmente buenos para encontrar defectos en
el uso real del sistema (es decir, los defectos que los usuarios tienen ms probabilidades de venir a travs de la
primera vez que el uso del sistema). Cada caso de uso general tiene una corriente principal (o lo ms probable)
y escenarios alternativos ramas veces adicionales (que abarcan, por ejemplo, casos especiales condi-ciones o
excepcionales). Cada caso de uso debe especificar ninguna condicin previa que se deben cumplir para el caso
de uso para trabajar. Los casos de uso tambin deben especificar condiciones posteriores que son resultados
observables y una descripcin del estado final del sistema despus de que el caso de uso se ha ejecutado con
xito.

El ejemplo de PIN que se utiliz para la prueba de transicin de estado tambin podra definirse en
trminos de casos de uso, como se muestra en la Figura 4.3. Mostramos un xito SCE-nario y las
extensiones (que representan las formas en que el escenario podra dejar de ser un xito).

Para las pruebas de casos de uso, tendramos una prueba de la hiptesis de xito y uno Tesi para cada
extensin. En este ejemplo, podemos dar la extensin 4b una prioridad ms alta que 4a desde el punto de
vista de la seguridad.

Requisitos del sistema tambin se pueden especificar como un conjunto de casos de uso. Este enfoque
puede hacer que sea ms fcil para involucrar a los usuarios en el proceso de recopilacin de requisitos y
definicin.

14 ESTRUCTURA BASADA EN BLANCO O-BOX

Tcnicas

1 Describir el concepto y la importancia de la cobertura de cdigo.(k)

2 Explicar los conceptos de la declaracin y la cobertura de decisin y bajo

destacan que estos conceptos se pueden utilizar tambin en otros niveles de prueba
que com

prueba componente (por ejemplo, en los procesos de negocio a nivel de sistema). (k)

3 Escribir casos de prueba a partir de flujos de control dados utilizando el siguiente

diseo de la prueba

tcnicas: (K3) una cobertura de sentencias;

la cobertura de decisin b.

4 Declaracin y la cobertura de la decisin de evaluar para la integridad.(k)

En esta seccin vamos a analizar en detalle el concepto de cobertura y cmo puede ser utilizado
para medir algunos aspectos de la rigurosidad de las pruebas. Con el fin de ver cmo la cobertura
realmente funciona, vamos a utilizar algunos ejemplos a nivel de cdigo (aunque la cobertura se
aplica tambin a otros niveles, como los procedimientos de negocio). En particular, vamos a
mostrar cmo medir la cobertura de las declaraciones y decisiones, y cmo escribir casos de
prueba para ampliar la cobertura si no es 100%. Los mismos principios se aplican a la cobertura
de los elementos de cobertura a nivel de sistema, por ejemplo, elementos de men.

En esta seccin, busque las definiciones de los trminos del glosario: cobertura de cdigo, la
cobertura de decisin, la cobertura de sentencias, pruebas estructurales, la estructura
-basado ensayos y pruebas de caja blanco-

4.4.1 El uso de tcnicas basadas en la estructura para medir pruebas de cobertura y

de diseo

tcnicas basadas en la estructura sirven para dos propsitos: la prueba de medicin de la

cobertura y de diseo de casos de prueba estructural. A menudo se utilizan primero para evaluar
la cantidad de pruebas realizadas por pruebas derivadas de tcnicas basadas en la especificacin,
es decir, para evaluar la cobertura. A continuacin, se utilizan para disear pruebas adicionales
con el objetivo de aumentar la cobertura de la prueba.

Tcnicas de diseo de pruebas basadas en la estructura son una buena manera de generar
casos de prueba adicionales que son diferentes de las pruebas existentes.Ellos pueden ayudar a
asegurar ms la amplitud de la prueba, en el sentido de que los casos de prueba que permitan
alcanzar una cobertura del 100% en ninguna medida se ejercen todas las partes del software
desde el punto de vista de los elementos que se estn cubiertos.

Qu es la cobertura de la prueba?

medidas de cobertura de las pruebas de alguna manera especfica la cantidad de pruebas

realizadas por un conjunto de pruebas (derivado de alguna otra manera, por ejemplo, utilizando
tcnicas basadas en la especificacin). Siempre que sea posible

contar las cosas y puede decir si o no cada una de esas cosas ha sido probado por alguna prueba,
entonces podemos medir la cobertura.La medida es la cobertura bsica

-------------------------------------------------- Numberofcoverageitemsexercised

COBERTU
RA

incgnit

Nmero total de elementos de cobertura

donde el 'elemento de cobertura' es todo lo que hemos podido contar y ver si una prueba ha ejercido o
utilizado este concepto.

Hay peligro en el uso de una medida de cobertura. Una cobertura del 100% no significa probados al 100%!
tcnicas de cobertura miden slo una dimensin de un concepto de mltiples dimen-sional. Dos casos de prueba
diferentes pueden alcanzar exactamente la misma cobertura pero los datos de entrada de uno puede encontrar un
error que los datos de entrada de la otra no.

Uno de los inconvenientes de la medicin de cobertura de cdigo es que mide la cobertura de lo que se
ha escrito, es decir, el propio cdigo; no se puede decir nada sobre el software que no se ha escrito.Si una
funcin especfica no ha sido imple-mentado, tcnicas de prueba basados en la especificacin se revelan
esto. Si una funcin se omiti de la especificacin, a continuacin, las tcnicas basadas en la experiencia
pueden encontrar. Pero las tcnicas basadas en la estructura slo puede mirar a una estructura que ya est
ah.

Tipos de cobertura

cobertura de la prueba se puede medir en base a un nmero de diferentes ele-mentos estructurales en un

sistema o componente. La cobertura se puede medir a nivel pruebas de componentes, el nivel de pruebas de
integracin o en niveles por el sistema o pruebas de aceptacin. Por ejemplo, en el sistema o nivel de
aceptacin, los elementos de cobertura pueden ser requerir-mentos, opciones de mens, pantallas, o las
transacciones comerciales tpicas. Otras medidas de cobertura incluyen cosas tales como elementos de base de
datos estructurales (registros, campos y subcampos) y archivos. Es digno de la comprobacin de las nuevas
herramientas, como el mercado de herramientas de prueba se desarrolla con bastante rapidez.

En el nivel de integracin, podramos medir la cobertura de las interfaces o interacciones especficas que
han sido probados. La cobertura de llamadas del mdulo, objeto o pro-cedimiento llamadas tambin se puede
medir (y es apoyado por herramientas hasta cierto punto).

Podemos medir la cobertura para cada una de las tcnicas basadas en la especificacin, as:

EP: porcentaje de particiones de equivalencia ejercido (podramos medir la cobertura particin

vlidos y no vlidos por separado si esto tiene sentido);
BVA: porcentaje de lmites ejercidas (tambin podramos separar los lmites vlidos y no vlidos
si hubiramos deseado);

Las tablas de decisin: porcentaje de reglas de negocio o columnas de tabla de decisiones

probado;

Pruebas de transicin de estado: hay una serie de posibles medidas de cobertura:

Porcentaje de estados visitados

- Porcentaje de transiciones (vlidos) ejercidas (esto se conoce como cobertura 0-interruptor de

Chow)

- Porcentaje de pares de transiciones vlidas ejercidas ( 'pares' de transicin o de cobertura 1interruptor de Chow) - y la serie ms larga de transiciones, como triples, cudruples tran sicin,
etc.

Porcentaje de transiciones no vlidas ejercidas (de la tabla de estado)

Las medidas de cobertura de las tcnicas basadas en la especificacin se aplicaran

independientemente del nivel en la prueba tcnica se ha utilizado (por ejemplo, nivel de sistema o
componente).

Cuando la cobertura es discutido por los analistas de negocios, probadores del sistema o usuarios, es
muy probable que se refiere al porcentaje de requisitos que han sido probados por una serie de pruebas.
Esto se puede medir por una herramienta tal como una herramienta de gestin-ment requisitos o una
herramienta de gestin de ensayo.

Sin embargo, cuando la cobertura es discutido por los programadores, lo ms probable se refiere a la
cobertura de cdigo, donde los elementos estructurales se pueden identificar usando una herramienta, ya
que no es bueno soporte de la herramienta para la medicin de la cobertura de cdigo. Vamos a cubrir
declaracin y cobertura de decisin en breve.

Las declaraciones y los resultados de decisin son dos estructuras que se pueden medir en el cdigo y existe
una buena herramienta de apoyo para estas medidas de cobertura. Cdigo COV-tura se hace normalmente en
las pruebas de componentes y el componente de integracin - si se hace en absoluto. Si alguien afirma haber
logrado la cobertura de cdigo, es importante establecer exactamente qu elementos del cdigo han sido
cubiertas, como la cobertura de sentencias (a menudo lo que se entiende) es significativamente ms dbil que
la cobertura de decisin o algunas de las otras medidas de cobertura de cdigo.

Cmo medir la cobertura

A efectos prcticos, la medicin de la cobertura es algo que requiere soporte de la herramienta. Sin
embargo, el conocimiento de los pasos que toma tpicamente para medir COV-tura es til en la
comprensin de los mritos relativos de cada tcnica. Nuestro ejemplo se supone una herramienta de
medida de cobertura intrusiva que altera el cdigo de insercin de instrumentacin:

1 Decidir sobre el elemento estructural a utilizar, es decir, los elementos de cobertura para ser
contados.
2 Contar los elementos estructurales o elementos.

3 Instrumento cdigo.

4 Ejecutar las pruebas para las cuales se requiere la medicin de cobertura.

5 Uso de la salida de la instrumentacin, determinar el porcentaje de elemen tos o artculos

ejercidas.

Instrumentar el cdigo (paso 3) implica la insercin de cdigo junto a cada elemento estruc-tural con el
fin de registrar el momento en que el elemento estructural ha sido ejer-CISED. La determinacin de la
medida de cobertura real (paso 5) es entonces una cuestin de anlisis de la informacin grabada.

de medida de cobertura de cdigo se hace mejor uso de herramientas (como se describe en el captulo
6) y hay un gran nmero de tales herramientas en el mercado. Estas herramientas pueden ayudar a
aumentar la calidad y la productividad de las pruebas. Aumentan la calidad, garantizando que los aspectos
ms estructurales son probados, por lo que los defectos en los caminos estructurales se pueden encontrar.
Ellos aumentan la productividad y la eficiencia, poniendo de relieve las pruebas que sean redundantes, es
decir, probando la misma estructura que las otras pruebas (aunque esto no es necesariamente una mala
cosa, ya que podemos encontrar un defecto probar la misma estructura con datos diferentes).

En comn con todas las tcnicas de pruebas basadas en la estructura, cobertura de cdigo tech-nicas son los
ms utilizados en las zonas de cdigo de software que se requiere realizar pruebas ms. cdigo crtico con la

seguridad; cdigo que es vital para el correcto funcionamiento de un sistema, y piezas complejas de cdigo
son todos ejemplos de dnde basado estructura

tcnicas son particularmente digno de la aplicacin.Por ejemplo, DO178-B [RTCA] requiere cobertura
estructural para ciertos tipos de sistema para ser utilizado por la mili-tario. tcnicas de cobertura
estructurales se deben utilizar siempre, adems de Spec-ficacin basada en tcnicas de pruebas basadas
en la experiencia, ms que como una alternativa a ellos y.

el diseo de casos de prueba basados en la estructura de

Si usted est apuntando para un nivel dado de cobertura (digamos 95%), pero que no ha alcanzado su
objetivo (por ejemplo, slo tiene el 87% hasta el momento), entonces los casos de prueba adicionales
pueden ser diseados con el objetivo de ejercer alguna o la totalidad de la elementos estruc-turales an no
llegaron. Este es el diseo del ensayo basado en la estructura. Estas nuevas pruebas se ejecutan a
continuacin, a travs del cdigo instrumentado y se calcula una nueva medida de la cobertura. Esto se
repite hasta que se alcanza la medida cobertura requerida (o hasta que decida que su objetivo era
demasiado ambi-cioso!). Lo ideal sera que todas las pruebas deben ser correr de nuevo en el cdigo antiinstrumentado.

Vamos a ver algunos ejemplos de la cobertura y la prueba de diseo basado en la estructura de la

declaracin y la toma de pruebas a continuacin.

4.4.2 Declaracin de la cobertura y de pruebas de requisitos

---------------------------------------------

Numberofstatementsexercised

la cobertura de
sentencias =

incgnit

Nmero total de declaraciones

Declaracin cobertura se calcula por:

Los estudios y la experiencia en la industria han indicado que lo que se considera razonablemente
exhaustiva prueba de recuadro negro en realidad puede lograr una cobertura declaracin slo el 60% al
75%. Tpica prueba ad hoc es probable que sea alrededor del 30% - esto deja el 70% de las declaraciones
no probadas.

Diferentes herramientas de cobertura pueden trabajar de manera ligeramente diferente, por lo que
pueden dar otros valores de cobertura para el mismo conjunto de pruebas en el mismo cdigo, aunque con
una cobertura del 100% que deben ser los mismos.

Vamos a ilustrar los principios de la cobertura de cdigo. Con el fin de simplificar los ejemplos, vamos
a utilizar un pseudo-cdigo bsico - esto no es ningn lenguaje especfico programa-ming, pero debe ser
legible y comprensible para usted, incluso si usted no ha hecho ningn tipo de programacin usted
mismo.

Por ejemplo, considere el ejemplo de cdigo 4.1.

LEER UN

readb

IFA> BTHENC = 0

[endif]

Code sample

Para alcanzar 100% de cobertura de declaracin de este segmento de cdigo se requiere slo un caso de
prueba, uno que asegura que la variable A contiene un valor que es mayor

que el valor de la variable B, por ejemplo, A = 12 y B = 10.Tenga en cuenta que el diseo de pruebas
estructurales que aqu estamos haciendo en primer lugar, ya que estamos eligiendo nuestros valores de
entrada con el fin de garantizar la cobertura de sentencias.

Veamos un ejemplo en el que medimos la cobertura en primer lugar. Con el fin de sim-ficar el ejemplo,
vamos a considerar cada lnea como un comunicado. (Las diferentes herramientas y mtodos pueden contar
cosas diferentes como estados de cuenta, pero el principio bsico es el mismo, sin embargo se cuentan.) Una
declaracin puede ser en una sola lnea, o puede extenderse a varias lneas. Una lnea puede contener ms de
una sentencia, slo una declaracin, o slo una parte de un comunicado. Algunos estados pueden contener
otros estados dentro de ellos. En el ejemplo de cdigo 4.2, tenemos dos declaraciones de lectura, una
instruccin de asignacin, y luego una instruccin IF en tres lneas, pero la instruccin IF contiene otra
declaracin (impresin) como parte de ella.

LEER UN

LEER B

C = A+ B 2 *

Si C> 50 ENTONCES

Letra grande C

#END IF

Code sample

Aunque no es del todo correcta, hemos numerado cada lnea y consideraremos cada lnea como un comunicado.
(Algunas herramientas pueden declaraciones grupo que siempre se ejecutarn juntos en un bloque bsico que se considera
como una sola instruccin.) Sin embargo, nos limitaremos a usar lneas numeradas para ilustrar los principios de la
cobertura de los estados (lneas). Vamos a analizar la cobertura de un conjunto de pruebas en nuestro programa de seis
declaracin:

PRUEBAS DE 1 Prueba 1_1: Un

= 2, B = 3 Prueba 1_2: A =
0, B = 25 Prueba 1_3: A = 47, B = 1

Cul prrafo hemos cubierto?

En el Ensayo 1_1, el valor de C ser de 8, por lo que cubrir las declaraciones de las lneas 1 a 4 y
la lnea 6.

En el Ensayo 1_2, el valor de C ser 50, de modo que cubrir exactamente los mismos mentos
estatales como prueba 1_1.

En el Ensayo 1_3, el valor de C ser de 49 aos, as que de nuevo vamos a cubrir los mismos
mentos estatales.

Puesto que hemos cubierto cinco de los seis estados, tenemos la cobertura de sentencias 83% (con tres
pruebas). Lo que prueba qu necesitamos con el fin de cubrir Estado-ment 5, la afirmacin de que no hemos
ejercido todava? Y ste?

Prueba 1_4: A = 20, B = 25

Esta vez el valor de C es 70, por lo que se imprimir 'Large C y que habr ejercido los seis de los
estados, por lo que ahora la cobertura de sentencias = 100%. Ntese que medimos la cobertura en primer
lugar, y luego diseamos una prueba para cubrir la afirmacin de que todava no habamos cubierto.

Tenga en cuenta que la prueba 1_4 por s solo es ms efectividad (hacia nuestra meta de la cobertura de
sentencias 100% achiev-ing) que las tres primeras pruebas juntos.Slo tomando Prueba 1_4 por s solo
tambin es ms eficiente que el conjunto de cuatro pruebas, ya que se ha utilizado una sola prueba en
lugar de cuatro. Al ser ms eficaz y ms eficiente es la marca de una buena tcnica de ensayo.

4.4.3 Decisin de cobertura y pruebas de decisin

Una decisin es una instruccin IF, una declaracin de control de bucle (por ejemplo, do-while o repeatuntil), o una instruccin CASE, donde hay salidas o resultados de dos o ms posi-ble de la declaracin.
Con una instruccin IF, ya sea la salida puede ser verdadero o falso, dependiendo del valor de la
condicin lgica que viene despus de SI. Con una sentencia de control de bucle, el resultado es o bien
para llevar a cabo el cdigo dentro del bucle o no - de nuevo una salida Verdadero o Falso. Decisin
cobertura se calcula mediante:

-------------------------------------------------- -----Numberofdecisionoutcomesexercised

la cobertura de
decisin =

incgnit

Nmero total de resultados de la decisin

Lo que se siente como pruebas funcionales razonablemente exhaustiva puede lograr una cobertura
decisin slo del 40% al 60%. prueba tpica ad hoc puede cubrir slo el 20% de las decisiones, dejando el
80% de los posibles resultados no probados. Incluso si su prueba parece bastante a fondo desde una
perspectiva funcional o basado en la especificacin, es posible que slo cubra dos tercios o tres cuartos
de las decisiones. la cobertura de decisin es ms fuerte que la cobertura de sentencias. Es la cobertura de
sentencias 'sub-reanudar la' - esto significa que la cobertura de decisin 100% siempre garantiza la
cobertura de sentencias 100%. Cualquier medida de la cobertura ms fuerte puede requerir ms casos de
prueba para lograr una cobertura del 100%. Por ejemplo, considere el ejemplo de cdigo 4.1 nuevo.

Vimos anteriormente se requera ese caso, slo una prueba para lograr una cobertura unificacin estado
100%. Sin embargo, la cobertura de decisin requiere que cada decisin de haber tenido un resultado
verdadero y falso. Por lo tanto, para lograr la cobertura de decisin 100%, un segundo caso de prueba es
necesario que A es menor o igual a B. Esto se asegurar de que la declaracin de decisiones 'SI A> B' tiene un
resultado falso. As que una prueba es suficiente para la cobertura de declaracin de 100%, pero se necesitan
dos pruebas para la cobertura de decisin 100%. Tenga en cuenta que la cobertura de decisin 100% garantiza
la cobertura unificacin estado 100%, pero no al revs!

LEER UN

LEER B

C = A- B 2 *

IFC <0THEN

PRINT "C negativo"

#END IF

Code sample

Vamos a suponer que ya tenemos la siguiente prueba, lo que nos da una cobertura del 100%
comunicado por ejemplo de cdigo 4.3.

PRUEBAS DE 2

Prueba 2_1: A = 20, B = 15

Qu resultados de la decisin que hemos ejercido con nuestra prueba? El valor de C es de -10, por lo que
la condicin de 'C <0' es cierto, por lo que se imprimir 'C negativo' y hemos ejercido el resultado de esa
declaracin verdadera decisin. Pero no hemos EXER-CISED el resultado de la decisin de False. Qu otra
prueba de qu tenemos que ejercer el resultado falso y para lograr una cobertura del 100% de decisin?

Antes de responder a esta pregunta, vamos a echar un vistazo a otra forma de representar el cdigo. A
veces, la estructura de toma es ms fcil ver en un diagrama de flujo de control (vase la Figura 4.4).

La lnea punteada muestra donde Prueba 2_1 ha ido y claramente demuestra que hasta ahora no hemos
tenido un examen que toma la salida falsa de la instruccin IF.

Vamos a modificar nuestra prueba existente establecido mediante la adicin de otra prueba:

PRUEBAS DE 2
Prueba 2_1: A = 20, B = 15
Prueba 2_2: A = 10, B = 2

Esto se refiere ahora tanto de los resultados de la decisin, la verdad (con prueba 2_1) y falsas (con
prueba 2_2). Si tuviramos que dibujar el camino tomado por la prueba 2_2, sera una lnea recta desde la
declaracin de lectura abajo de la salida falsa ya travs de la ENDIF. Tenga en cuenta que podra haber
elegido otros nmeros para lograr cualquiera de los resultados Verdadero o Falso.

4.4.4 Otras tcnicas basadas en la estructura

Hay otras tcnicas basadas en la estructura que se pueden utilizar para lograr la prueba a diferentes
grados de rigurosidad. Algunas tcnicas son ms fuertes (requieren ms pruebas para lograr una cobertura
del 100% y, por tanto, tienen una mayor probabilidad de detectar defectos) y otros son ms dbiles.

Por ejemplo, la cobertura de la rama est estrechamente relacionado con la cobertura de decisiones y con
una cobertura del 100% que dan exactamente los mismos resultados. Decisin cobertura mide la cobertura de
las ramas condicionales; cobertura de sucursales mide la cobertura de ambas ramas condicionales e
incondicionales. El Plan de estudios utiliza decisin

cobertura, ya que es la fuente de las ramas.Algunas herramientas de medicin de cobertura pueden hablar
acerca de la cobertura de la rama cuando en realidad quieren decir la cobertura de decisin.

Otras medidas de cdigo de cobertura de flujo de control incluyen secuencia lineal de cdigo y la cobertura
de salto (LCSAJ), la cobertura de estado, estado cobertura mltiple (tambin conocido como la cobertura de
combinacin condicin) y la cobertura de la determinacin de la condicin (tambin conocida como la
cobertura de decisin condicin mltiple o con-dicin modificado la cobertura de decisin, MCDC). Esta
tcnica requiere la cobertura de todas las condiciones que pueden afectar o determinar el resultado de la
decisin.

Otro popular, pero a menudo mal entendido, medida en cdigo es la cobertura de cobertura de caminos.
A veces cualquier tcnica basada en la estructura se denomina "prueba de ruta '[Patton, 2001]. Sin
embargo, estrictamente hablando, para cualquier cdigo que contiene un bucle, la cobertura de ruta es
imposible ya que un camino que viaja alrededor del bucle tres veces es diferente de la ruta que viaja
alrededor del mismo bucle cuatro veces. Esto es cierto incluso si el resto de los caminos son idnticos. As
que si es posible viajar por el bucle un nmero ilimitado de veces, entonces hay un nmero ilimitado de
rutas a travs de ese trozo de cdigo. Por esta razn, es ms correcto hablar de "una cobertura
independiente segmento de trazado", aunque la cobertura "camino ms corto plazo se utiliza con
frecuencia.

medidas basadas en la estructura y tcnicas de diseo de pruebas relacionadas se describen en

[BS7925-2]. Las tcnicas basadas en estructura tambin se discuten en [Copeland. 2003] y [Myers, 1979].
Una buena descripcin de la teora de grafos detrs de las pruebas estruc-tural se puede encontrar en
[Jorgensen, 1995] y [Hetzel, 1988] tambin muestra un enfoque estructural. [Pol et al, 2001] describe un
enfoque basado en la estructura llamada una prueba de algoritmo.

4.5 TCNICAS basado en la experiencia

1
Recordemos razones para escribir casos de prueba basados en la intuicin, la
experiencia y el conocimiento de los defectos comunes.{0}k = 0.015 L{/0}{1}1{/1}

2 Comparacin de las tcnicas basadas en la experiencia con tcnicas de prueba basados

en la especificacin.(k)

En esta seccin vamos a ver dos tcnicas basadas en la experiencia, por qu y cuando son tiles, y cmo
encajan con las tcnicas basadas en la especificacin.

Si bien es cierto que la prueba debe ser rigurosa, completa y sistemtica, esto no es todo lo que hay de
la prueba. Hay un papel definitivo para Tech-tcnicas no sistemticas, es decir, sobre la base de pruebas
de una persona conocimiento, la experiencia, la imaginacin y la intuicin. La razn es que algunos
defectos son difciles de encontrar utilizando enfoques ms tico del sistema, por lo que una buena 'bug
cazador' puede ser muy creativo en la bsqueda de esos defectos difcil de alcanzar.

En esta seccin, busque las definiciones de los trminos del glosario: adivinar error y exploratoria
pruebas.

4.5.1 adivinar error

Error adivinar es una tcnica que siempre se debe utilizar como un complemento de otras tcnicas ms
formales.El xito de adivinar error es muy dependiente tanto de la habilidad del probador, como buenos
probadores saben donde es ms probable que se esconden los defectos. Algunas personas parecen ser
naturalmente bueno en las pruebas y otros son buenos probadores porque tienen mucha experiencia, ya sea
como un probador o trabajar con un sistema en particular y por lo tanto son capaces de establecer claramente
sus debilidades. Esta es la razn por un enfoque de error de adivinar, que se utiliza despus de las tcnicas ms
formales se han aplicado en cierta medida, puede ser muy eficaz. En el uso de tcnicas ms tech-formales, el
probador es probable que obtener una mejor comprensin del sistema, lo que hace y cmo funciona. Con esta

mejor comprensin, l o ella es probable que sea mejor en formas de adivinanzas en el que el sistema no
funcione correctamente.

No hay reglas para adivinar error. El probador se le anima a pensar en situaciones en las que el
software puede no ser capaz de hacer frente. Las condiciones tpicas para tratar de incluir la divisin por
cero, de entrada en blanco (o no), archivos vacos y el tipo equivocado de datos (por ejemplo caracteres
alfabticos donde se requiere numrico). Si alguien dice de un sistema o el entorno en el cual se va a
operar "Eso nunca podra suceder ', que podra ser una buena idea para probar esa condicin, ya que tales
suposiciones acerca de lo que ser y no va a ocurrir en el entorno real son a menudo la causa de los fallos.
Un enfoque estructurado a la tcnica de error de adivinar es enumerar los defectos o fallos pos-ble y
disear pruebas que tratan de producirlos. Estas listas de defectos y fracasos se pueden construir en base a
la propia experiencia del probador o la de otras personas, defectos e insuficiencia de datos disponibles, y
de conocimiento comn acerca de por qu falla el software.

4.5.2 El testing exploratorio

Pruebas exploratorias es un enfoque prctico en el que estn involucrados en los probadores mnimo de
planificacin y ejecucin de prueba mxima.La planificacin implica el cre-acin de una carta de prueba, una
breve declaracin del alcance de una breve prueba de esfuerzo (1 a 2 hora) encajadas en tiempo, los objetivos
y posibles enfoques para ser utilizados.

Las actividades de diseo y ejecucin de pruebas de ensayo se realizan en paralelo typi-camente sin
documentar formalmente las condiciones de prueba, casos de prueba o scripts de prueba. Esto no quiere
decir que no se utilizarn otras ms tcnicas, pruebas formales. Por ejemplo, el probador puede decidir
utilizar anlisis de valores lmite, pero va a pensar a travs y poner a prueba los valores lmite ms
importantes sin tener que escribir necesariamente hacia abajo. Algunas notas sern escritos durante la
sesin de pruebas exploratorias, de manera que un informe se puede producir despus.

se lleva a cabo el registro de datos que se lleva a cabo la ejecucin de pruebas, la documentacin de los aspectos
clave de lo que se evala, y cualquier defecto encontrado ningn pensamiento acerca de la posible realizar ms
pruebas. Un aspecto clave de la prueba exploratoria es el aprendizaje: el aprendizaje por el probador sobre el
software, su uso, sus puntos fuertes y sus puntos dbiles. Como su nombre lo indica, pruebas exploratorias se trata
de explorar, encontrar informacin sobre el software, lo que hace, lo que no hace, qu funciona y qu no funciona.
El probador est constantemente haciendo decisiones sobre lo que debe probar siguiente y dnde pasar el tiempo
(limitado).

Este es un enfoque que es ms til cuando no hay o hay pobres ESPECIFICACIONES-ciones y cuando el
tiempo es muy limitado. Tambin puede servir para complementar otras pruebas, ms formal, ayudando a
establecer una mayor confianza en el software. En

de esta manera, las pruebas de exploracin se puede utilizar como un control sobre el proceso de prueba
formal, ayudando a garantizar que los defectos ms graves han sido encontrados.

pruebas exploratorias se describe en [Kaner, 2002] y [Copeland, 2003] Otras formas de pruebas en
forma exploratoria ( "ataques") se describen b \ [Whittaker, 2002].

4. 6 ELECCIN DE UNA TCNICA DE PRUEBA

1 Enumerar los factores que influyen en la seleccin de la tcnica de diseo de prueba

apropiado para un determinado tipo de problema, como por ejemplo el tipo de
sistema, el riesgo, los requisitos del cliente, modelos para el modelado de casos de uso,
modelos de requisitos o conocimiento probador. (k)

En esta ltima seccin vamos a ver los factores que intervienen en la decisin sobre qu tcnicas que
pueden utilizarse.

Qu tcnica es la mejor? Esta es la pregunta equivocada! Cada tcnica es buena para ciertas cosas, y
no tan bueno para otras cosas. Por ejemplo, uno de los beneficios de las tcnicas basadas en la estructura
es que se pueden encontrar cosas en el cdigo que se supone no estar all, como en caballos de Troya u
otro cdigo malicioso. Sin embargo, si hay partes de la especificacin que faltan en el cdigo, tcnicas
slo a base de especificaciones se encuentra que - las tcnicas basadas en la estructura slo se puede
probar lo que hay. Si hay cosas que faltan en la memoria descriptiva y a partir del cdigo, a continuacin,
tcnicas slo a base de la experiencia encontrara. Cada tcnica individual est dirigido a tipos
particulares de defecto tambin. Por ejemplo, las pruebas de transicin de estado es poco probable
encontrar defectos de contorno.

La eleccin de qu tcnicas de prueba para utilizar depende de varios factores, incluyendo el tipo de
sistema, las normas reglamentarias, cliente o requisitos contractuales, nivel de riesgo, tipo de riesgo, objetivo

de la prueba, la documentacin disponible, el conocimiento de los probadores, el tiempo y presupuesto, ciclo

de vida de desarrollo, modelos de casos de uso y la experiencia previa de los tipos de defectos encontrados.

Algunas tcnicas son ms aplicables a determinadas situaciones y niveles de prueba: los dems son
aplicables a todos los niveles de la prueba.

En este captulo se ha cubierto las tcnicas de pruebas de software ms populares y de uso comn. Hay
muchos otros que quedan fuera del mbito del Plan de Estudios que este libro se basa en. Con tantas
tcnicas de prueba para elegir cmo son los probadores para decidir cules usar?

Tal vez lo ms importante a entender es que la mejor tcnica de prueba es ninguna tcnica nica prueba.
Debido a que cada tcnica de prueba es bueno para encontrar una clase especfica de defecto, mediante una
sola tcnica ayudar a asegurar que muchos (tal vez la mayora, pero no todos) se encuentran defectos de esa
clase particular. Por desgracia, tambin puede ayudar a asegurar que muchos defectos de otras clases se
pierden! Usando una variedad de tcnicas, por tanto, ayudar a asegurar que una variedad de defectos se
encuentran, lo que resulta en las pruebas ms eficaz.

Entonces, cmo podemos elegir las tcnicas de ensayo ms adecuados para usar?La decisin se basa en
una serie de factores, tanto internos como externos.

Los factores internos que influyen en la decisin sobre qu tcnica a utilizar son:

Los modelos utilizados - Dado que las tcnicas de pruebas se basan en modelos, los modelos
disponible (es decir, desarrollar y utilizar durante la especificacin, diseo e implementacin del
sistema), en cierta medida, que regir las tcnicas de prueba se pueden utilizar.Por ejemplo, si la
especificacin contiene un diagrama de transicin de estado, la prueba de transicin de estado sera
una buena tcnica a utilizar.

Conocimiento probador experimento - Cunto probadores conocen el sistema y sobre Tcnicas

de ensayo influirn claramente su eleccin de tcnicas de pruebas de alta tecnologa.Este
conocimiento en s mismo ser influenciado por su experiencia de la prueba y del sistema bajo prueba.

Defectos que puedan - El conocimiento de los defectos que sern muy tiles en choos ing tcnicas
de prueba (ya que cada tcnica es bueno para encontrar un tipo particular de defecto).Este

conocimiento puede ser adquirida a travs de la experiencia de probar una versin anterior del sistema
y los niveles anteriores de las pruebas de la versin actual.

Objetivo de la prueba - Si el objetivo de la prueba es simplemente para ganar la confianza de que

la suave Ware hacer frente a las tareas operativas tpicas a continuacin, utilizar los casos sera un
enfoque ble sen.Si el objetivo es que las pruebas tcnicas muy rigurosas luego ms riguroso y
detallado (incluyendo tcnicas basadas en la estructura) debe ser elegido.

Documentacin - Sea o no la documentacin (por ejemplo, un requisitos especificacin) existe y si

es o no es hasta la fecha afectar a la eleccin de las tcnicas de prueba.El contenido y el estilo de la
documentacin tambin influirn en la eleccin de las tcnicas (por ejemplo, si las tablas de decisin o
grafos de estado se han utilizado a continuacin las tcnicas de prueba asociados deben ser utilizados).

Modelo de ciclo de vida - Un modelo de ciclo de vida secuencial se presta a la utilizacin de ms

tcnicas formales, mientras que un modelo de ciclo de vida iterativo pueden ser ms adecuados para el
uso de un enfoque de pruebas exploratorias.

Los factores externos que influyen en la decisin sobre qu tcnica a utilizar son:

Riesgo - La mayor es el riesgo (por ejemplo, los sistemas crticos de seguridad), mayor es la
necesidad para las pruebas formales ms a fondo y ms.El riesgo comercial puede ser influ mentado
por problemas de calidad (prueba de manera ms completa sera apropiado) o por cuestiones de
tiempo hasta el comercial (ensayo de manera exploratoria sera una eleccin ms appropri ATE).

I requisitos contractuales de los clientes - A veces los contratos especifican la par particutcnicas de prueba a utilizar (ms comnmente declaracin o cobertura de sucursales).

Tipo de sistema - El tipo de sistema (por ejemplo, incrustado, grfico, financiero, etc.) influir en la eleccin
de las tcnicas.Por ejemplo, una aplicacin financiera que implica muchos clculos se beneficiara de anlisis de
valores lmite.

Los requisitos reglamentarios - Algunas industrias tienen normas reglamentarias o directrices que
rigen las tcnicas de prueba utilizados.Por ejemplo, la industria aeronutica requiere el uso de particin
de equivalencia, el valor lmite de Analy sis y la prueba de transicin de estados para sistemas de alta

integridad, junto con pliego, la decisin o la cobertura de decisin condicin modificada en funcin del
nivel de integridad del software requerido.

Tiempo y presupuesto - En ltima instancia la cantidad de tiempo no est disponible siempre ser
afectar la eleccin de las tcnicas de prueba.Cuando se dispone de ms tiempo podemos darnos el lujo
de seleccionar ms tcnicas y cuando el tiempo es muy limitado estaremos limitados a los que sabemos
que tienen una buena oportunidad de ayudarnos a encontrar slo los defectos ms importantes.

Repaso Captulo

Vamos a repasar lo que ha aprendido en este captulo.

De la Seccin 4.1, ahora debera ser capaz de diferenciar entre una condicin de prueba, un
caso de prueba y un procedimiento de prueba y saber que estn documentados en una
especificacin de diseo de la prueba, una especificacin de casos de prueba y un procedimiento
de ensayo, respectivamente. Usted debe ser capaz de escribir casos de prueba que incluyen los
resultados esperados y que muestran una clara trazabilidad a la base de pruebas (por ejemplo,
requisitos). Usted debe ser capaz de traducir los casos de prueba en un procedimiento de ensayo
en el nivel de detalle adecuado para los probadores y usted debera ser capaz de escribir un
programa de ejecucin de prueba para un determinado conjunto de casos de prueba que tenga en
cuenta las prioridades, as como tcnica y lgica dependencias. Usted debe saber los casos de
prueba trminos del glosario, especificacin de caso de prueba, condiciones de ensayo, datos
de prueba, procedimiento de ensayo, test script y trazabilidad.

De la Seccin 4.2 (o categoras de tcnicas de diseo de pruebas), usted debe ser capaz de dar
razones por las cuales ambos (caja blanca) enfoques basados en la especificacin (recuadro
negro) y basadas en la estructura son tiles, y la lista de las tcnicas comunes para cada uno de
estos enfoques. Usted debe ser capaz de explicar las caractersticas y diferencias entre las
tcnicas, basadas en la experiencia basada en la estructura y basada en la especificacin. Usted
debe saber la prueba de recuadro negro trminos del glosario tcnicas de diseo, tcnicas de
diseo de pruebas basadas en la experiencia, las tcnicas de diseo de pruebas basado en
las especificaciones tcnicas de diseo, las pruebas basadas estructura- y tcnicas de diseo
de pruebas de caja blanca.

De la Seccin 4.3, usted debe ser capaz de escribir casos de prueba a partir de modelos dados
de software utilizando la particin de equivalencia, anlisis de valores lmite, tablas de decisin
y diagramas de transicin de estados. Debe comprender el propsito principal de cada una de
estas cuatro tcnicas, qu nivel y tipo de pruebas podran utilizar cada cobertura tech-nique y
cmo puede medirse para cada uno de ellos. Tambin debe comprender el concepto y los
beneficios de las pruebas de casos de uso. Usted debe saber el valor lmite de los trminos del
glosario anlisis, pruebas de la tabla de decisiones, la particin de equivalencia, las pruebas
de transicin de estado y pruebas de casos de uso.

De la Seccin 4.4, usted debe ser capaz de describir el concepto y la importancia de la

cobertura de cdigo. Usted debe ser capaz de explicar los conceptos de la cobertura de
sentencias y decisiones y entender que estos conceptos tambin se pueden utilizar en los niveles
de ensayo distintos de las pruebas de componentes (como los procedimientos comerciales a
nivel de prueba del sistema). Usted debe ser capaz de escribir casos de prueba a partir de flujos
de control determinado, utilizando pruebas de requisitos y pruebas de decisin, y usted debera
ser capaz de evaluar la cobertura de sentencias y decisiones para la integridad. Debe conocer la
cobertura de cdigo glosario trminos, la cobertura de decisin, la cobertura de sentencias,
pruebas estructurales, las pruebas basadas en la estructura y las pruebas de caja blanca.

De la Seccin 4.5, usted debe ser capaz de recordar las razones de los casos de prueba de
escritura basados en la intuicin, la experiencia y el conocimiento de los defectos comunes y
usted debera ser capaz de comparar las tcnicas basadas en la experiencia con las tcnicas
basadas en la especificacin. Usted debe saber el error trminos del glosario de adivinar y
pruebas exploratorias.

De la Seccin 4.6, usted debe ser capaz de enumerar los factores que influyen en la seleccin
de la tcnica de diseo de prueba apropiado para un determinado tipo de problema, como por
ejemplo el tipo de sistema, el riesgo, los requisitos del cliente, modelos para el modelado de
casos de uso, modelos de requisitos o probar el conocimiento.

PREGUNTAS examen de la muestra

Pregunta 1 En qu documento descrito en la norma IEEE 829 le encontrar las instrucciones para las
medidas que deben tomarse para una prueba que incluye la configuracin, el registro, el medio ambiente
y la medicin?

a.

{0}{/0} {1} {/1} {2}Plan de prueba{/2}

b.

especificacin de diseo de la prueba

c.

Especificacin de caso de pruebas

d.

Especificacin de procedimiento de pruebas

Pregunta 2 Con un probador de gran experiencia con un buen conocimiento de los negocios, que se
acercan a la definicin de los procedimientos de ensayo sea eficaz y ms eficiente para un proyecto bajo
la presin del tiempo severo?

a. Un esquema de alto nivel de las condiciones de prueba y los pasos generales a seguir.

b.

Cada paso en el ensayo explicado en detalle.

c.

Un esquema de alto nivel de las condiciones de prueba con los pasos a seguir discutido en
detalle con otro probador experimentado.

d.

La documentacin detallada de todos los casos de prueba y un registro cuidadoso de cada paso que se da
en la prueba.

Pregunta 3 Ponga los casos de prueba que implementan las siguientes condiciones de prueba en el mejor orden para
el programa de ejecucin de la prueba, para una prueba que est comprobando las modificaciones de los clientes en
una base de datos.

1 Imprimir registro de cliente modificado.

2 Cambiar la direccin del cliente: nmero de casa y nombre de la calle.

3 Capturar e imprimir el mensaje de error en pantalla.

4 Cambiar la direccin del cliente: cdigo postal.

5 Confirmar cliente existente est en la base de datos mediante la apertura de ese registro.

6 Cierre el registro del cliente y cerrar la base de datos.

7 Trate de aadir un nuevo cliente sin detalles en absoluto. a.32.

segundo. 4,2,5,1,6,7,3 c. 5,4,2,1,7,3,6 d. 32.

Pregunta 4 Por qu estn basados en la especificacin y tanto la estructura basada en tcnicas de prueba
til?

a.

Ellos encuentran diferentes tipos de defectos.

b.

El uso de tcnicas ms es siempre mejor.

c.

Ambos encuentran los mismos tipos de defectos.

d.

Debido a las especificaciones tienden a ser no estructurada.

Pregunta 5 Qu es una caracterstica clave de las tcnicas de pruebas basadas en la estructura?

a. Se utilizan principalmente para evaluar la estructura de una especificacin.

b. Se utilizan tanto para medir la cobertura y disear pruebas para aumentar la cobertura.
c. Se basan en los conocimientos y la experiencia del probador.

d. Utilizan un modelo formal o informal del software o componente.

Pregunta 6 Cul de las siguientes sera un ejemplo de las pruebas de la toma de la tabla para una aplicacin
financiera aplicada a nivel del sistema de la prueba?

a. Una tabla que contiene reglas para combinaciones de entradas a dos campos en una pantalla.
b. Una tabla que contiene las reglas para las interfaces entre los componentes.

c. Una tabla que contiene las reglas para las solicitudes de hipotecas.
d.

Una tabla que contiene las reglas para el ajedrez.

Pregunta 7 Cul de las siguientes podra ser una medida de cobertura para las pruebas de transicin de
estado?

V Se han llegado a todos los estados.

W El tiempo de respuesta para cada transaccin es adecuada.

x Cada transicin se ha ejercido.

Y Todos los lmites se han ejercido.

Z Secuencias especficas de las transiciones se han ejercido.

a.

X, YandZ

b.

V, X, Y y Z

c.

W, Xandy

d.

V, X y Z

Pregunta 8 Las tarifas postales para cartas 'ligeros' son 25p hasta L0G, 35p hasta 50 g ms un l0p extra
por cada 25 g adicional hasta l00g.

Qu entradas de prueba (en gramos) se pueden seleccionar mediante la particin de equivalencia?

a.

32.

b.

4-15

c.

d.

20-40

Pregunta 9 Cul de los siguientes podra ser utilizado para evaluar la cobertura alcanzada por (recuadro
negro) tcnicas de prueba basados en la especificacin?

V Resultados de las decisiones ejercidas

W particiones ejercidas

x Los lmites ejercidas

Y Las transiciones de estado ejercidas

Z declaraciones ejercidas

a.

V, W, YorZ

b.

W, XorY

c.

V, XorZ

d.

W, X, Y o Z

Pregunta 10 Cul de las siguientes tcnicas de diseo de pruebas basado en la estructura sera ms
probable que se aplicar a?

1 Los lmites entre las bandas de los tipos de inters de la hipoteca.

2 Una transicin no vlido entre dos diferentes mora ^ estados.

3 El proceso de negocio de flujo de aprobacin de la hipoteca.

4 El flujo de control del programa para el clculo de los pagos.

a.

%@, %@ y %@

b.

%@, %@ y %@

c.

%@, %@ y %@

d.

%@, %@ y %@

Pregunta 11 Uso de pruebas caso es til para cul de las siguientes?

Diseo de pruebas de aceptacin P con los usuarios o clientes.

Q Asegurarse de que los procesos de negocio principales son probados.

R encontrar defectos en la interaccin entre los componentes.

S Identificacin de los valores mximo y mnimo para cada campo de entrada. La identificacin de la T

porcentaje de declaraciones ejercidos por una series de pruebas.

a.

P, Q y R

b.

Q, Sandt

c.

P, Q y S

d.

R, S y T

Pregunta 12 Cul de las siguientes afirmaciones sobre la relacin entre la cobertura de sentencias y la
cobertura de decisin es la correcta?

a. la cobertura de decisin 100% se consigue si la cobertura declaracin es mayor que 90%.

b. la cobertura de declaracin 100% se consigue si la cobertura de decisin es mayor que 90%.

c. la cobertura de la decisin 100% siempre significa una cobertura del 100% comunicado.

d. la cobertura de sentencias 100% siempre significa una cobertura decisin 100%.

Pregunta 13 Si usted est volando con un boleto en clase econmica, existe la posibilidad de que puede
ser actualizado a la clase de negocios, sobre todo si se tiene una tarjeta de oro en el programa de viajero
frecuente de la aerolnea. Si usted no posee una tarjeta de oro, hay una posibilidad de que usted
conseguir 'golpeado' fuera de la lnea area si esto est lleno y que el proceso de registro de retraso. Esto
se muestra en la Figura 4.5. Tenga en cuenta que cada caja (es decir, declaracin) ha sido numerada.

Tres pruebas han llevado a cabo:

Prueba 1: titular de la tarjeta de oro que se ve actualizado a la clase de negocios

Prueba 2: titular de la tarjeta no de oro que se queda en la economa de prueba 3: Una persona que recibe un golpe
desde el vuelo Cul es la cobertura de sentencias de estas tres pruebas?

a.

60%

b.

70%

c.

80%

d.

90%

Pregunta 14 Por qu estn adivinando error y pruebas exploratorias bueno hacer?

a. Pueden encontrar defectos perdidas mediante tcnicas basadas en la estructura basada en la

especificacin y.

b. No requieren ningn tipo de formacin para ser tan eficaz como las tcnicas formales.
c. Se pueden utilizar ms eficazmente cuando hay buenas especificaciones.
d. Se asegurarn de que todo el cdigo o el sistema se pone a prueba.

Pregunta 15 Cmo funcionan las tcnicas basadas en la experiencia diferir de las tcnicas basadas en la
especificacin?

a. Dependen de la comprensin del probador de la forma en que el sistema est estructurado en

vez de en un registro documentado de lo que debe hacer el sistema.

b. Ellos dependen de tener probadores de ms edad en lugar de los probadores ms jvenes.

c. Dependen de un registro documentado de lo que debe hacer el sistema ms que en la opinin
personal de un individuo.

d. Dependen de vista personal de un individuo en vez de en un registro documentado de lo que

debe hacer el sistema.

Pregunta 16 Al elegir qu tcnica utilizar en una situacin dada, que factores deben tenerse en cuenta?

T experiencia previa de tipos de defectos que se encuentran en tal o sistemas similares

V el conocimiento existente de los probadores

W normas reglamentarias que se aplican

X el tipo de herramienta de ejecucin de la prueba que se utilizar Y la documentacin disponible

Z experiencia previa en el desarrollo del lenguaje

a.

V, W, YandZ

b.

U, V, W e Y

c.

T, Xandy

d.

V, W e Y

Pregunta 17 Teniendo en cuenta el diagrama de estados de la figura 4.6, que caso de prueba es la serie
mnima de transiciones vlidas para cubrir todos los estados?

a.

SS - S1 - S2 - S4 - S1 - S3 - ES

b.

SS - S1 - S2 - S3 - S4 - ES

c.

SS - S1 - S2 - S4 - S1 - S3 - S4 - S1 - S3 - ES

d.

SS - S1 - S4 - S2 - S1 - S3 - ES

Ejercicios: TCNICAS DE DISEO DE PRUEBA

Ejercicios basados en las tcnicas reguladas en este captulo se dan en esta seccin. soluciones trabajadas
se dan en la siguiente seccin.

el ejercicio de equivalencia Particin / Lmite Anlisis de Valor

Escenario: Si se toma el tren antes de las 9:30 de la maana o por la tarde despus de las 4:00 pm hasta las 19:30
( 'hora punta'), que debe pagar la tarifa completa.Un billete protector est disponible para los trenes entre las 9:30
am y las 4:00 pm, y despus de las 7:30.

Cules son las particiones y los valores lmite para poner a prueba los horarios de los trenes para los
tipos de entradas? Los cuales son vlidos par-ticiones y que son particiones no vlidos? Cules son los
valores lmite? (Una tabla puede ser til al rgano-ize sus particiones y los lmites). Derivar casos de
prueba para las particiones y los lmites.

Hay alguna pregunta que tenga sobre este 'requisito'? Est claro algo?

ejercicio tabla de decisin

Escenario: Si mantiene un '' mayores de 60 aos tarjeta de ferrocarril, se obtiene un descuento del 34%
en cualquier compra de entradas.Si usted es viajar con un nio (menor de 16), se puede obtener un
descuento del 50% en cualquier billete si usted tiene una tarjeta de ferrocarril de la familia, si no se
obtiene un descuento del 10%.Que slo puede contener un tipo de tarjeta de ferrocarril.

Producir una tabla de decisin que muestra todas las combinaciones de tipos de tarifas y descuentos
resultantes y derivar casos de prueba a partir de la tabla de decisiones.

el ejercicio de transicin de estados

Escenario: Una cesta de compras sitio web comienza como vaca.Como se seleccionan las compras, que se
aaden a la cesta de la compra.Los elementos tambin se pueden eliminar de la cesta de la compra. Cuando el
cliente decide hacer la salida, se muestra un resumen de los artculos de la canasta y el costo total, para el
cliente para decir si esto es correcto o no. Si el contenido y los precios estn bien, luego de salir de la pantalla
de resumen y de ir al sistema de pago. De lo contrario, vaya de nuevo a compras (para que pueda eliminar
elementos si lo desea).

a. Producir un diagrama de estado que muestra los diferentes estados y transiciones. Definir una
prueba, en cuanto a la secuencia de estados, de todas las transiciones.

b.

Producir una tabla de estados. D un ejemplo de ensayo para una transicin vlida.

Declaracin y pruebas decisin ejercicio

Escenario: Una mquina expendedora dispensa cualquiera de bebidas calientes o fras.Si elige una
bebida caliente (por ejemplo, t o caf), se le preguntar si desea la leche (y aade la leche si es
necesario), y luego se le pregunta si desea azcar (y agrega el azcar si es necesario), y luego de su
bebida se dispensa.

a. Dibuje un diagrama de flujo de control para este ejemplo. (Pista: consideran a la seleccin del
tipo de bebida como una declaracin.)

b. Dadas las pruebas siguientes, cul es la cobertura de sentencias logra? Lo que se logra la
cobertura de decisin?

Prueba 1: Bebida fra

Prueba 2: Bebida caliente con leche y azcar

c. Qu pruebas adicionales seran necesarios para lograr una cobertura del 100% comunicado?
Qu pruebas adicionales seran necesarios para lograr una cobertura del 100% de decisin?

soluciones de los ejercicios

ejercicio EP / BVA

Lo primero que debe hacer es establecer exactamente cules son los lmites entre la tarifa completa y
tarifa ahorro. Vamos a poner estos en una tabla para organizar nuestros pensamientos:

Hemos asumido que los valores lmite son: las 9:29 am, 9:30 am, a las 4:00 de la tarde, 16:01, 7:30 y 19:31.
Al establecer exactamente lo que pensamos que se entiende por la especificacin, podemos destacar algunas
ambigedades o, al menos, plantear algunas preguntas - este es uno de los beneficios del uso de la tcnica! Por
ejemplo:

"Cundo comienza la hora punta de la maana? A la medianoche? A las 11:30 pm del da anterior?
En el momento del primer tren del da? Si es as, cundo es el primer tren? Las 10 horas

Esta es una omisin ms importante de la especificacin. Podramos hacer una suposicin acerca de
cuando se inicia, pero sera mejor averiguar lo que es correcto.

Si un tren se debe dejar exactamente a las 4:00 pm es un boleto protector sigue siendo vlido?

Qu pasa si un tren se debe dejar antes de las 4:00 pm, pero se retrasa hasta despus de 16:00?Es
un boleto protector sigue siendo vlido? (Es decir, si la hora de salida real es diferente a la hora de
salida programada)

Nuestra tabla anterior nos ha ayudado a ver dnde estn las particiones. Todas las particiones de la tabla
anterior son las particiones vlidas. Puede ser que una particin no vlida sera un tiempo que ningn tren
estaba en marcha, por ejemplo, antes de las 5:00 am, pero nuestra especificacin no mencion que! Sin
embargo, sera bueno mostrar esta posibilidad tambin. Podramos ser un poco ms formal haciendo una lista
de todas las particiones y los lmites vlidos y no vlidos en una tabla, como lo hemos descrito en la Seccin
4.3.1, pero en este caso que en realidad no aadir mucho, ya que todas las particiones son vlidos.

Estos son los casos de prueba podemos extraer de este ejemplo:

Tenga en cuenta que los casos de prueba 1, 4, 7 y 10 se basan en valores de particin de equivalencia;
los casos 2, 3, 5, 6, 8 y 9 de ensayo se basa en los valores lmite. Tambin puede haber otra informacin
sobre los casos de prueba, tales como precondi-ciones, que no hemos mostrado aqu.

Ejercicio tabla de decisin

Los tipos de tarifas mencionadas incluyen una tarjeta de ferrocarril de los 60 ms ', una tarjeta de ferrocarril
de la familia, y si usted est viajando con un nio o no. Con tres condiciones o causas, tenemos ocho
columnas en nuestra mesa de decisin siguiente.

Cuando llegamos a llenar los efectos, podemos encontrar esto un poco ms difcil. Para las dos
primeras reglas, por ejemplo, cul debe ser la salida? Es una X debido a la celebracin de ms de una
tarjeta de carril no debe ser pos-ble? La especificacin no dice qu pasa si alguien nos depara ms de una
tarjeta, es decir, que no ha especificado la salida, as que tal vez debera poner un signo de interrogacin
en esta columna. Por supuesto, si alguien tiene dos cartas del ferrocarril, que probablemente no admitir
esto, y tal vez iban a reclamar el descuento del 50% con su tarjeta de ferrocarril de la familia si estn
viajando con un nio, as que quizs deberan poner el 50% de la Regla 1 y 34% para la Regla 2 en esta
columna. Nuestra notacin muestra que no sabemos cul ser el resultado esperado debera ser para estas
reglas!

Esto pone de relieve el hecho de que nuestro lenguaje natural (Ingls) especificacin no es muy clara
en cuanto a lo que los efectos deberan ser en realidad. Una de las ventajas de esta tcnica es que obliga a
una mayor claridad. Si las respuestas se detallan en una tabla de decisin, entonces est claro cul es el
efecto debe ser. Cuando diferentes personas vienen con diferentes respuestas para las salidas, entonces
usted tiene una especificacin de claro!

La palabra 'en otro caso' en la especificacin es ambigua. Significa "lo contrario" significa que usted
siempre obtenga al menos un descuento del 10% o significa que si viaja con un nio y una tarjeta de
mayores de 60 aos, pero no una tarjeta de la familia se obtiene el 10% y el 34%? Dependiendo de lo
supuesto de que realice por el significado de "lo contrario", obtendr una ltima fila diferente en su tabla
de decisiones.

Tenga en cuenta que el efecto o la salida es la misma (34%) tanto para los artculos 3 y 4. Esto significa
que nuestra tercera causa (sea o no un nio tambin est viajando) en realidad no tiene ninguna influencia
en el resultado. Por tanto, estas columnas podran combinarse con 'no me importa' como entrada para la
tercera causa. Este racionalizacin de la tabla significa que vamos a tener un menor nmero de
columnas y, por tanto, un menor nmero de casos de prueba. La reduccin en los casos de prueba se basa
en la suposicin de que estamos haciendo sobre el factor que no tiene efecto sobre el resultado, por lo que
un enfoque ms a fondo sera incluir cada columna de la tabla.

Aqu hay una tabla racionalizado, donde hemos mostrado nuestras suposiciones acerca de los dos
primeros resultados y tambin hemos combinado los artculos 6 y 8, ya que tener una tarjeta de ferrocarril
de la familia no tiene ningn efecto si no est travel-ING con un nio.

Estos son los casos de prueba que nosotros sacamos de esta tabla.(Si no racionalizar la tabla, a
continuacin, tendr ocho casos de prueba en lugar de seis.) Tenga en cuenta que no necesariamente
probar cada columna, pero la tabla le permite tomar una decisin sobre qu combinaciones para poner a
prueba y cules no para poner a prueba esta vez.

Tenga en cuenta que es posible que hayamos planteado algunas cuestiones adicionales cuando
diseamos los casos de prueba. Por ejemplo, el descuento para una tarjeta de ferrocarril slo se aplican a
los viajeros o para alguien que viaja con ellos? Aqu hemos supuesto que se aplica a todos los viajeros de
ferrocarril de la tarjeta de la familia, pero al pasajero individual solamente para mayores de 60 aos
tarjeta de ferrocarril.

el ejercicio de transicin de estados

El diagrama de estados se muestra en la Figura 4.7. El estado inicial (SI) es cuando la cesta de la compra
est vaca. Cuando se aade un elemento a la cesta, se pasa al estado (S2), donde hay posibles compras.
Cualquier elemento adicional aadido a la canasta no cambian el estado (slo el nmero total de lo que se
compra). Los productos que se pueden quitar, que no cambia el estado a menos que el total de elementos
ordenados va de 1 a 0. En este caso, volvemos a la cesta vaca (SI). Cuando queremos hacer la salida, nos
vamos al estado de sumario (S3) para su aprobacin. Si la lista y los precios son aprobados, vamos al
pago (S4); si no, volvemos al estado de compras (posiblemente para eliminar algunos elementos para
reducir el precio total que tenemos que pagar). Hay cuatro estados y siete transiciones.

Tenga en cuenta que SI es nuestro Estado de inicio para este ejemplo y S4 es el estado final - esto
significa que no estamos con-trate con cualquier evento que sucede una vez que lleguemos al estado S4.

Aqu est una prueba para cubrir todas las transiciones.Tenga en cuenta que el estado final de una
etapa o evento es el estado de inicio para el prximo evento, por lo que estos pasos deben realizarse en
esta secuencia.

Aunque nuestro ejemplo no est interesado en lo que sucede a partir de Estado 4, no habra otros
eventos y acciones, una vez que entramos en el proceso de pago que podra ser mostrado por otro
diagrama de estado (por ejemplo, control vlido-dad de la tarjeta de crdito, practicar la retencin de
correo electrnico un recibo, etc.).

La tabla de estado correspondiente es:

Todas las cajas que contienen las transiciones - son vlidos en este ejemplo. pruebas negativas
ejemplo podra incluir:

intente agregar un elemento a partir del resumen y el estado costar (S3)

tratar de eliminar un elemento de la cesta vaca de compras (SI)

tratar de entrar en 'Aceptar', mientras que en el estado de compras (S2).

Declaracin y pruebas decisin ejercicio

El diagrama de flujo de control se muestra en la Figura 4.8. Tenga en cuenta que dibujo de un diagrama
de control aqu ilustra que la prueba estructural tambin se puede aplicar a la estructura de los procesos
generales, no slo a los algoritmos de ordenador. Los diagramas de flujo son generalmente fciles de
entender que el texto cuando se est tratando de describir los resultados de las decisiones tomadas en los
acontecimientos posteriores.

En la Figura 4.9, podemos ver la ruta que las pruebas 1 y 2 han tomado a travs de nuestro grafo de
control de flujo. Prueba 1 ha ido hacia abajo de la parte izquierda para seleccionar una bebida fra. Prueba
2 se ha ido a la derecha en cada oportunidad, aadiendo la leche y el azcar a una bebida caliente.

Cada declaracin (representado por una caja en el diagrama) ha sido cubierto por nuestros dos pruebas,
por lo que tenemos la cobertura de sentencias 100%.

No hemos tomado el no haya salida ya sea de la leche? ' o "azcar? ' decisiones, por lo que hay dos
resultados de la decisin que nosotros no hemos probado todava. Hicimos prueba tanto de los resultados
de la 'caliente o fro? decisin, por lo que han cubierto cuatro de los seis resultados de la decisin. la
cobertura de decisin es 4/6 o 67% con las dos pruebas.

No se requieren pruebas adicionales para lograr la cobertura de sentencias, como ya tenemos una
cobertura del 100% de los estados.

Se necesita un ensayo adicional para lograr una cobertura del 100%

de decisin: Prueba 3: Bebida caliente, sin leche, sin azcar

Este examen abarcar tanto resultado de la decisin del "no" de la leche y el azcar decisiones, por lo
que ahora tendr cobertura de decisin 100%.

Capitulo cinco.

Gestin de Pruebas

T
resante es una actividad compleja.La prueba es a menudo un sub-proyecto distinto dentro del software ms
grande desarrollo, mantenimiento, o proyecto de integracin.Las pruebas usualmente representa una sustancial
proporcin del presupuesto total del proyecto. Por lo tanto, debemos entender cmo debemos
gestionar las pruebas que hacemos.

En este captulo trata sobre los temas esenciales para la gestin de pruebas en seis secciones. La primera se
refiere a la forma de organizar los probadores y las pruebas. El segundo se refiere a la estimacin, la
planificacin y la estrategia del esfuerzo de la prueba. Los terceros direcciones de prueba monitoreo del
progreso, informes de pruebas y control de prueba. El cuarto explica gestin de la configuracin y su relacin
con la prueba. El quinto cubre el tema central de riesgo y cmo las pruebas afecta y es afectada por riesgos de
los productos y de proyectos. La sexta y ltima seccin se analiza la gestin de incidentes, ambos defectos de
los productos y otros eventos que requieren una mayor investigacin.

Organizacin de Pruebas

1 Reconocer la importancia de las pruebas independientes.{0}k = 0.015 L{/0}{1}1{/1}

2
Enumerar las ventajas y los inconvenientes de las pruebas
independientes dentro de un rgano zacin.(k)
3 Reconocer los diferentes miembros del equipo a tener en cuenta para la
creacin de un equipo de prueba.{0}k = 0.015 L{/0}{1}1{/1}

4 Recordemos las tareas de los lderes y los probadores de prueba tpicos.{0}k = 0.015
L{/0}{1}1{/1}

En esta seccin, vamos a hablar de la organizacin de un esfuerzo de la prueba dentro de un proyecto. Vamos a
ver el valor de las pruebas independientes, y discutir los beneficios y riesgos potenciales asociados con las
pruebas independientes. Vamos a examinar los diversos tipos de diferentes miembros del equipo de prueba de
lo que se quiere en un equipo de prueba. y adems...

familiarizarnos con las tareas tpicas realizadas por los lderes de la prueba y los probadores.

A medida que avanzamos a travs de esta seccin, mantener los ojos abiertos para el glosario de
trminos probador, el lder de la prueba y director de pruebas.

5.1.1 Las pruebas independientes e integrada

En el captulo 1 hablamos de pruebas independiente desde la perspectiva de indi-vidual psicologa

probador. En este captulo, vamos a ver las implicaciones organizativas y de gestin de la independencia.

Los enfoques para la organizacin de un equipo de pruebas varan, as como los lugares de la
estructura de los rganos-izacin, donde el equipo de pruebas se adapta. Dado que la prueba es una
evaluacin de la calidad, y puesto que la evaluacin no siempre es positiva, muchas organizaciones se
esfuerzan por crear un clima organizacional donde los evaluadores pueden ofrecer una inde-pendiente, la
evaluacin objetiva de la calidad.

Cuando se piensa en la forma independiente del equipo de pruebas es, reconocer que inde-pendencia
no es un bien / o estado, sino un proceso continuo. En un extremo del continuo se encuentra la falta de
independencia, donde el programador realiza pruebas dentro del equipo de programacin.

En camino hacia la independencia, a encontrar un probador integrado o un grupo de probadores que

trabajan junto a los programadores, pero an dentro e informar al gerente de desarrollo. Es posible encontrar
un equipo de probadores que son indepen-ent y fuera del equipo de desarrollo, pero la presentacin de
informes de gestin de proyectos.

Cerca del otro extremo de la escala estara completa independencia. Es posible que vea un equipo de
prueba separado los informes en la organizacin en un punto igual al equipo de desarrollo o proyecto.
Usted puede encontrar especialistas en el mbito empresarial (por ejemplo, los usuarios del sistema),
especialistas en la tecnologa (por ejemplo, los expertos de base de datos), y especialistas en las pruebas
(tales como los auditores de seguridad, los probadores de certificacin, o expertos de automatizacin de
pruebas) en una separada equipo de pruebas, como parte de un equipo de prueba independiente ms
grande, o como parte de un contrato, el equipo de prueba externalizado. Vamos a examinar los beneficios
y riesgos potenciales de la independencia, empezando por los beneficios.

Organizacin independiente a menudo puede ver ms, otros, y los diferentes defectos que un probador
de trabajo dentro de un equipo de programacin - o un probador que ejerce la profesin de programador.
Mientras que los analistas de negocios, personal de marketing, diseadores y pro-programadores traer sus
propias suposiciones a la especificacin y IMPLEMENTA-cin del elemento bajo prueba, organizacin
independiente trae un conjunto diferente de supuestos a prueba y a los comentarios, que a menudo ayuda
a exponer oculta defectos y problemas relacionados con la manera de pensar del grupo, como hemos
comentado en el captulo 3. Organizacin independiente trae una actitud escptica de pesimismo
profesional, una sensacin de que, si hay alguna duda sobre el comportamiento observado, se debe
preguntar: Esto es un defecto?

A nivel de equipo, un equipo de pruebas independiente que informa a un gerente general o ejecu-tivo puede
disfrutar de (una vez que se lo han ganado) ms credibilidad en la organizacin de un lder de ensayo o tester,
que forma parte del equipo de programacin.Un probador inde-ent que reporta a la alta direccin
puede reportar sus resultados con honestidad y sin preocuparse por las represalias que pudieran
derivarse de sealar los problemas de los compaeros de trabajo "o, peor an, el trabajo del gerente. Un
equipo de pruebas independiente a menudo tiene un presupuesto separado, lo que ayuda a garantizar el
nivel adecuado de dinero se gasta en la formacin probador, herramientas de prueba, equipos de
prueba, y as sucesivamente. Adems, en algunas organizaciones, los probadores en un equipo de prueba
independiente puede resultar ms fcil de tener una carrera que conduce en ms puestos de alto rango
en las pruebas.

equipos de pruebas independientes no estn exentas de riesgos. Es posible que los probadores y el equipo
de pruebas a aislarse. Esto puede tomar la forma de aislamiento interpersonal de los programadores, los
diseadores y el equipo del proyecto en s, o puede tomar

la forma de aislamiento de la visin ms amplia de la calidad y los negocios obje-tivas (por ejemplo, el
enfoque obsesivo sobre los defectos, a menudo acompaado de una negativa a aceptar el establecimiento de
prioridades del negocio de defectos).Esto conduce a problemas de comunicacin, sentimientos de alienacin y
la antipata, una falta de identificacin y apoyo a los objetivos del proyecto, festivales culpa espontneas y
pualadas por la espalda poltico.

Incluso los equipos de pruebas bien integrados pueden sufrir problemas. Otros proyectos partes
interesadas puedan llegar a ver al equipo de pruebas independiente - con o sin razn - como un cuello de
botella y una fuente de demora. Algunos programadores abdican su responsa-bilidad de calidad, diciendo,
'Bueno, tenemos este equipo de pruebas ahora, as que por qu necesito unidad de prueba de mi cdigo?

Debido al deseo de los beneficios de un equipo de pruebas independientes, a veces las empresas
establecen ellos, slo para separarlos de nuevo ms tarde. Por qu sucede esto? Una causa comn es el
hecho de que el director de pruebas para gestionar eficazmente los riesgos de la independencia
enumerados anteriormente. Algunos equipos de prueba sucumben a la tentacin de adoptar una actitud de
"no se puede", viene con razones por las cuales el proyecto debe plegarse a sus necesidades en lugar de
ser flexible cada lado para permitir que el xito del proyecto. Probadores llevan a actuar como agentes de
proceso o como auditores sin un mandato de gestin y el apoyo adecuados. Resentimientos y la presin
aumenta, hasta que por fin la organizacin decide que el equipo de pruebas independiente causa ms
problemas de los que resuelve. Es espe-cialmente importante para que los evaluadores y gestores de
prueba para entender la misin que sirven y las razones por las que la organizacin quiere un equipo de
pruebas independiente. A menudo, todo el equipo de prueba debe darse cuenta de que, si son parte del
equipo de proyecto o independiente, que existen para proporcionar un servicio al equipo del proyecto.

No hay un solo enfoque correcto para la organizacin de pruebas. Para cada proyecto, debe tener en cuenta
si va a utilizar un equipo de pruebas independiente, basado en el proyecto, el dominio de aplicacin, y los
niveles de riesgo, entre otros factores. A medida que el tamao, la complejidad y criticidad de los aumentos del
proyecto, es importante contar con inde-pendencia en los niveles posteriores de las pruebas (como prueba de
integracin, prueba del sistema y aceptar-ANCE prueba), aunque algunos anlisis con frecuencia es el mejor
hecho por otras personas tales como directores de proyectos, gerentes de calidad, desarrolladores, expertos en
negocios y de dominio o de infraestructura o expertos de operaciones de TI.

5.1.2 Trabajando como un lder de la prueba

Hemos visto que la ubicacin de un equipo de pruebas dentro de una organizacin del proyecto puede
variar ampliamente. Del mismo modo hay una amplia variacin en los papeles que las personas dentro
del juego del equipo de prueba. Algunas de estas funciones se producen con frecuencia, algunos con poca
frecuencia. Dos papeles que se encuentran dentro de muchos equipos de prueba son las del lder de la
prueba y el probador, aunque las mismas personas pueden desempear ambos papeles en varios puntos

durante el proyecto. Vamos a echar un vistazo a los trabajos realizados en estos papeles, empezando por
el lder de la prueba.

Los lderes de prueba tienden a estar involucrados en la planificacin, el seguimiento y control de las
actividades de prueba y las tareas se discuten en la Seccin 1.5 en el proceso de prueba fundamental. Al inicio
del proyecto, los lderes de la prueba, en colaboracin con las otras partes interesadas, disear los objetivos de
la prueba, las polticas de organizacin de la prueba (si no est ya en su lugar), las estrategias de prueba y
planes de pruebas. Se estiman las pruebas a realizar y negociar con la direccin para adquirir los recursos
necesarios. Reconocen cuando la automatizacin de pruebas es adecuada y, si lo es, que planean el

esfuerzo, seleccionar las herramientas, y garantizar la formacin del equipo.Pueden consultar con otros
grupos - por ejemplo, programadores - para ayudarles con sus pruebas. Conducen, conducir y supervisar
el anlisis, diseo, implementacin y ejecucin de los casos de prueba, procedimientos de ensayo y de
pruebas. Se aseguran de gestin de la configuracin apropiada de la testware producido y la trazabilidad
de las pruebas a la base de pruebas.

A medida que se acerca la ejecucin de pruebas, se aseguran de que el entorno de prueba se pone en su
lugar antes de la ejecucin de pruebas y administrado durante la ejecucin de la prueba. Se programan las
pruebas para la ejecucin y luego monitorear, medir, controlar e informar sobre el progreso de la prueba,
el estado de la calidad del producto y los resultados de las pruebas, la adaptacin del plan de pruebas y
compensando como sea necesario para adaptarse a la evolucin de con-diciones. Durante la ejecucin de
prueba y medida que el proyecto vaya remitiendo, las que escriben resmenes de estado de la prueba.

A veces los lderes prueba de desgaste diferentes ttulos, como director de pruebas o coordinador de la
prueba. Por otra parte, el papel supervisor de la prueba puede terminar asignado a un director de proyecto,
un gerente de desarrollo o un gerente de control de calidad. (En cuanto a las dos primeras personas en esta
lista, campanas sobre la independencia de advertencia deben estar sonando en tu cabeza ahora, adems de
los pensamientos acerca de cmo podemos asegurar que tales probadores no obtienen el conocimiento y
la perspectiva necesaria para administrar las pruebas.) El que est jugando el papel, esperar que se
planean, supervisan y controlan el trabajo de ensayo.

5.1.3 Trabajando como un probador

Al igual que con los lderes de la prueba, los proyectos deben incluir los probadores, en primer lugar, a
pesar de que es a menudo el caso de que el proyecto no necesita un complemento completo de los
probadores hasta que el perodo de ejecucin de la prueba. En las fases de planificacin y preparacin de
las pruebas, los probadores deben revisar y contribuir a prueba los planes, as como el anlisis, la
revisin-cin y los requisitos de la evaluacin y las especificaciones de diseo. Ellos pueden estar
involucrados en o incluso ser el pueblo primarias que identifican las condiciones de prueba y probar los
diseos cre-Ating, casos de prueba, especificaciones del procedimiento de prueba y los datos de prueba, y

pueden ayudar a automatizar o automatizar las pruebas. A menudo se establecieron las prueba ENVI-amo ayudar a la administracin del sistema y el personal de gestin de red en hacerlo.

A medida que comienza la ejecucin de pruebas, el nmero de probadores a menudo aumenta,

comenzando con el trabajo necesario para aplicar las pruebas en el entorno de prueba. (Pueden
desempear un papel tan en todos los niveles de la prueba, incluso los que no estn bajo el control directo
del grupo de prueba; por ejemplo, se podra aplicar pruebas unitarias que fueron diseados por el
programa-tarios.) Probadores ejecutan y registran las pruebas, evaluar los resultados y problemas de
documentos encontrados. Siguen de cerca la prueba y el entorno de prueba, a menudo utilizando
herramientas para esta tarea, y con frecuencia se renen los parmetros de rendimiento. A lo largo del
ciclo de vida de las pruebas, que revisan el trabajo del otro, incluyendo ESPECIFICA-ciones de pruebas,
informes de defectos y resultados de las pruebas.

5.1.4 Definicin de la necesidad de habilidades del personal de pruebas

Haciendo pruebas adecuadamente requiere algo ms que la definicin de las posiciones de la derecha y el
nmero de personas para estos cargos. Los buenos equipos de ensayo tienen la combinacin adecuada de

habilidades basadas en las tareas y actividades que se debe llevar a cabo, y personas ajenas al equipo de
pruebas que estn a cargo de las tareas de prueba necesitan los conocimientos adecuados, tambin.Las
personas que participan en las pruebas necesitan cualificaciones profesionales y sociales bsicas como la
alfabetizacin, la capacidad de preparar y entregar informes escritos y verbales, la capacidad de
comunicarse de manera efectiva, y as sucesivamente. Yendo ms all de eso, cuando pensamos en las
habilidades que necesitan probadores, tres reas principales vienen a la mente:

Aplicacin o negocio de dominio: Un probador debe entender el comportamiento previsto, el

problema del sistema va a resolver, el proceso se automatizar y as sucesivamente, con el fin de
detectar el comportamiento inadecuado durante las pruebas y reconocer los '' deben trabajar las
funciones y caractersticas.

Tecnologa: Un probador debe ser consciente de los problemas, limitaciones y capacidades de la

tecnologa de aplicacin elegido, con el fin de localizar de manera eficaz y efi cientemente problemas
y reconocer la 'probabilidad de fallar' funciones y caractersticas.

Pruebas: Un probador debe conocer los temas de prueba analizados en este libro - y temas sobre la
prueba a menudo ms avanzados - con el fin de llevar a cabo con eficacia y eficiencia las tareas de
prueba asignados.

Las habilidades especficas en cada rea y el nivel de habilidad requerido varan segn el proyecto,
organizacin, aplicacin, y los riesgos involucrados.
El conjunto de tareas y actividades de prueba son muchos y variados, y tambin lo son las habilidades
requeridas, lo que a menudo produce una especializacin de habilidades y separacin de funciones. Por
ejemplo, debido al conocimiento especial requerido en las reas de las pruebas, la tecnologa y el dominio
de la empresa, respectivamente, los expertos de la herramienta de prueba pueden manejar la
automatizacin de las pruebas de regresin, los programadores pueden realizar compo-nente y pruebas de
integracin y de los usuarios y los operadores pueden estar involucrados en la aceptacin pruebas.

Hemos defendido durante mucho tiempo la prueba generalizada, la participacin de las personas en
todo el equipo del proyecto en la realizacin de tareas de prueba. Cerremos esta seccin, sin embargo, en
una nota de advertencia. Las compaas de software y del sistema (por ejemplo, los productores de
software empaquetado y productos de consumo) typi-camente sobrestimar el conocimiento tecnologa
necesaria para ser un probador efectiva. Las empresas que utilizan la tecnologa de la informacin (por
ejemplo, bancos y compaas de Insur-ANCE) por lo general sobreestiman el conocimiento del dominio
de negocio necesario.

Todos los tipos de proyectos tienden a subestimar el conocimiento pruebas requeridas. Hemos visto un
proyecto fracasan en parte debido a que las personas sin conocimientos apropiados de prueba a prueba los
componentes crticos, que condujo al descubrimiento desastrosa de los problemas fundamentales de
arquitectura ms tarde. La mayora de los proyectos pueden beneficiarse de la participacin de los
probadores profesionales, como las pruebas de aficionados a solas por lo general no ser suficiente.

5.2 prueba los planes, estimaciones y

Estrategias

1 Reconocer los diferentes niveles y objetivos de la planificacin de pruebas.{0}k = 0.015

L{/0}{1}1{/1}

2 Resumir el propsito y el contenido del plan de pruebas, diseo de pruebas

especfi
cationes y procedimiento de prueba de acuerdo con los documentos [IEEE 829]. (k)

3 Recordemos factores tpicos que influyen en el esfuerzo relacionados con las

pruebas.{0}k = 0.015 L{/0}{1}1{/1}
4 Diferenciar entre dos enfoques de estimacin conceptualmente diferentes:

el enfoque basado en la mtrica y el enfoque basado en el experto. (k)

5 Diferenciar entre el tema de planificacin de pruebas para un proyecto, para

indi

indivi- niveles de prueba (por ejemplo, prueba del sistema) u objetivos especficos de
prueba (por ejemplo, la facilidad de uso

prueba), y para la ejecucin de la prueba. (k)

6 Lista de preparacin para el examen y la ejecucin de las tareas que

requieren planificacin.{0}k = 0.015 L{/0}{1}1{/1}
7 Reconocer y justificar los criterios de salida adecuadas para los niveles especficos
de prueba y

grupos de casos de prueba (por ejemplo, para las pruebas de integracin, pruebas de
aceptacin o

{0}{/0}{1}Pruebas de usabilidad{/1} (k)

En esta seccin, vamos a hablar de un tro de temas complicados de prueba: planes, estimaciones
y estrategias. Los planes, estimaciones y estrategias dependen de una serie de factores,
incluyendo el nivel, metas y objetivos de la prueba que estamos de salir a hacer. Escribir un plan,
preparar una estimacin y seleccin de estrategias de prueba tienden a ocurrir simultneamente e
idealmente durante el perodo de planificacin para el proyecto en general, aunque hay que listo
para revisarlas como avanza el proyecto y obtener ms informacin.

Veamos de cerca cmo preparar un plan de pruebas, el examen de las cuestiones relacionadas
con la planificacin de un proyecto, para un nivel de prueba o fase, para un tipo especfico de
prueba y de ejecucin de la prueba. Vamos a examinar los factores tpicos que influyen en el
esfuerzo relacionados con las pruebas, y vemos dos enfoques diferentes de estimacin: mtricas
basadas y basadas en los expertos. Discutiremos la seleccin de estrategias de prueba y las
formas de establecer criterios de salida adecuadas para la prueba. Adems, vamos a ver
diferentes tareas relacionadas con la preparacin y ejecucin de pruebas que requieren
planificacin.

Al leer, mantener los ojos abiertos para la entrada del glosario de trminos criterios, los
criterios de salida, prueba exploratoria, enfoque de la prueba, la prueba de nivel, planes de
prueba, el procedimiento de prueba y estrategia de prueba.

5.2.1 El propsito y el contenido de los planes de prueba

Mientras que las personas tienden a tener diferentes definiciones de lo que sucede en un plan de
pruebas, para nosotros un plan de pruebas es el plan del proyecto para el trabajo de pruebas para
acabar.No es una especificacin de diseo de la prueba, una coleccin de prueba

casos o un conjunto de procedimientos de prueba; de hecho, la mayor parte de nuestros planes

de prueba Do No abordar ese nivel de detalle.
Por qu escribimos planes de prueba? Tenemos tres razones principales.

En primer lugar, escribir un plan de pruebas gua nuestro pensamiento. Encontramos que si
podemos explicar algo con palabras, lo entendemos. Si no es as, hay una buena probabilidad de
que no.

Escribir un plan de pruebas nos obliga a hacer frente a los retos que nos esperan y se centran nuestro
pensamiento sobre temas importantes. En el captulo 2 del libro brillante y esencial Fred Brooks en la

gestin de la ingeniera de software, El mes laboral mtico, explica la importancia de la estimacin

cuidadosa y la planificacin para la prueba de la siguiente manera:

La falta de suficiente tiempo para la prueba del sistema, en particular, es particularmente

desastrosa. Dado que el retraso se produce al final de la programacin, nadie es consciente
de lo previsto problemas hasta casi el retraso fecha de entrega [y] en este punto tiene
inusualmente severa ...
repercusiones financieras. El proyecto est dotado de personal, y el coste por da es el
mximo [como son los costos de oportunidad asociados]. Por eso es muy importante que
haya tiempo suficiente prueba del sistema en el programa original.

[Brooks, 1995]

Encontramos que el uso de una plantilla al escribir los planes de prueba nos ayuda a recordar los retos
importantes. Puede utilizar la plantilla del plan de prueba IEEE 829 se muestra en este captulo, el uso de otra
persona plantilla o crear su propia plantilla con el tiempo.

El proceso de planificacin de prueba y el plan en s sirven como vehculos para la comuni-cando con otros
miembros del equipo del proyecto, probadores, compaeros, directivos y otras partes interesadas. Esta
comunicacin permite que el plan de pruebas para influir en el equipo del proyecto y el equipo del proyecto
para influir en el plan de pruebas, especialmente en las reas de las polticas y las motivaciones de pruebas de
toda la organizacin; Prueba de alcance, obje-tivas y reas crticas para poner a prueba; proyecto y del
producto riesgos, recursos considera-ciones y restricciones; y la capacidad de prueba del elemento bajo prueba.

Esto se puede hacer a travs de la comunicacin de circulacin de una o dos borradores del plan de
prueba y por medio de las reuniones de revisin. un proyecto de tales incluir muchas notas como las
siguientes:

[Por determinar: Jennifer: Por favor dgame cul es el plan para la liberacin de los elementos de prueba en el
laboratorio de pruebas para cada ciclo de ejecucin de la prueba del sistema?] [David - por favor hgamelo
saber qu versin de la herramienta de prueba se utilizar para las pruebas de regresin de los incrementos
anteriores.]

Como documentar las respuestas a estas preguntas, el plan de pruebas se convierte en un registro de las
discusiones previas y acuerdos entre los probadores y el resto del equipo del proyecto.

El plan de pruebas tambin nos ayuda a gestionar el cambio. Durante las primeras fases del proyecto, mientras
nos reunimos ms informacin, revisamos nuestros planes. A medida que evoluciona y situaciones proyecto
cambian, nos adaptamos nuestros planes. planes de pruebas escritas nos dan un punto de referencia contra el cual
medir dichas revisiones o cambios. Por otra parte, la actualizacin del plan en los principales hitos de la prueba
ayuda a mantener alineada con las necesidades del proyecto. Mientras corremos las pruebas, hacemos los ajustes
finales en nuestros planes basados en los resultados. Es posible que no tenga el tiempo - o la energa - para
actualizar sus planes de prueba cada vez que se produce una variacin, ya que algunos proyectos pueden ser muy
dinmico. En el captulo 6 [Negro, 2001], se describe un mtodo sencillo para documentar las variaciones del plan
de prueba que se puede implementar utilizando una base de datos u hoja de clculo. Puede incluir estos registros de
cambio en una actualizacin peridica plan de pruebas, como parte de un informe de estado de la prueba, o como
parte como un resumen de la prueba al final de su proyecto.

Hemos encontrado que es mejor escribir varios planes de prueba en algunas situaciones. Por ejemplo,
cuando logramos los dos niveles de integracin y pruebas del sistema, esos dos perodos de ejecucin de
pruebas ocurrir en diferentes momentos y tienen diferentes

1.5 OBJETIVOSPara algunos proyectos de sistemas, un plan de pruebas de hardware y software de un

plan de pruebas abordar diferentes tcnicas y herramientas, as como los diferentes pblicos. Sin
embargo, ya que puede haber superposicin entre estos planes de prueba, un plan de pruebas maestro que
se ocupa de los elementos comunes puede reducir la cantidad de documentacin redundante.

IEEE 829 STANDARD plan de pruebas PLANTILLA

Identificador de plan de pruebas

Introduccin

Elementos de prueba

entregables de prueba

tareas de prueba

necesidades ambientales

Caractersticas para ser probados

Caractersticas no a ensayar

Enfoque

Responsabilidades

Las necesidades de personal y de formacin

Programar

Tema pase / no pasa criterios

Criterios de suspensin y reanudacin

Riesgos y contingencias

aprobaciones

32.

Qu hacer con su cerebro, mientras que la planificacin de las pruebas

Escribir un buen plan de pruebas es ms fcil que escribir una novela, pero ambas tareas requieren un
enfoque organizado y el pensamiento cuidadoso. De hecho, ya que un buen plan de pruebas se mantiene
corto y concentrado, a diferencia de algunas novelas, algunos podran argumentar que es ms difcil
escribir un buen plan de pruebas. Veamos algunas de las tareas de planificacin que necesita para llevar a
cabo.

A un alto nivel, es necesario considerar el propsito servido por el trabajo de ensayo. En trminos de
las necesidades globales de la organizacin, este propsito se conoce Vari-ormente como la misin del
equipo de prueba o la poltica de pruebas de la organizacin. En cuanto al proyecto especfico, la
comprensin del propsito de la prueba significa conocer las respuestas a preguntas como las siguientes:

Lo que es en su alcance y lo que est fuera del alcance de este esfuerzo de prueba?

Cules son los objetivos de la prueba?

 Cules son los riesgos importantes proyectos y productos?(Ms informacin sobre los riesgos en
la seccin 5.5).
Las restricciones afectan lo que prueba (por ejemplo, limitaciones presupuestarias, plazos duros,
etc.)?

Lo que es ms importante para este producto y el proyecto?

Qu aspectos del producto son ms (o menos) comprobable?

Cul debera ser el calendario general de ejecucin de pruebas y cmo deberamos decidir el
orden en el que ejecutar pruebas especficas?(Producto y planificacin de riesgos, discutidos ms
adelante en este captulo, influir en las respuestas a estas preguntas.)

A continuacin, debe seleccionar las estrategias que sean adecuadas a la finalidad de la prueba (ms en
el tema de la seleccin de estrategias en unas pocas pginas).

Adems, es necesario decidir cmo dividir el trabajo de ensayo en varios niveles, como se discuti en el
captulo 2 (por ejemplo, componentes, integracin, sistema y aceptacin).Si ya se ha tomado esa decisin, es
necesario decidir cmo encajar mejor su trabajo de pruebas en el nivel en el que es responsable de la labor
pruebas realizadas en esos otros niveles de la prueba. Durante el anlisis y diseo de pruebas, tendr que
reducir las brechas y la superposicin entre los niveles y, durante la prueba de ejecu-cin, tendr que coordinar
entre los niveles. Estos detalles se ocupan de la coordinacin entre el nivel se abordan a menudo en el plan de
pruebas maestro.

Adems de la integracin y coordinacin entre los niveles de prueba, tambin se debe planear para integrar
y coordinar todo el trabajo de pruebas para hacerse con el resto del proyecto. Por ejemplo, qu elementos
deben ser adquiridos para la prueba? Hay como un cajero automtico en curso los problemas de suministro,
como con las cuentas de imitacin (es decir, billetes de banco simulado) para una aplicacin financiera?
Cundo el programa-dores obra completa en el sistema bajo prueba? Qu apoyo operaciones se requiere
para el entorno de prueba? Qu tipo de informacin debe ser entregado al equipo de mantenimiento al final
de la prueba?

Descendiendo en los detalles, lo que hace que un plan de un plan - en lugar de un estado-cin de
principios, una larga lista de buenas ideas o una coleccin de sugerencias - es que el autor especifica en
ella quin har qu, cuando y (al menos de una manera general) cmo. Se necesitan recursos para llevar a
cabo el trabajo. Estos son a menudo decisiones difciles que requieren una cuidadosa consideracin y la
construccin de un consenso entre el equipo, incluso con el director del proyecto.

Todo el proceso de prueba - desde la planificacin hasta el cierre - produce informacin, algunos de los
cuales tendr que documentar. Con qu precisin debe escribir los probadores de prueba diseos, casos y
procedimientos? Cunto deberan de salir a la sentencia del probador durante la ejecucin de la prueba, y
cules son los problemas de reproducibilidad asociados con esta decisin? Qu tipos de plantillas se pueden
utilizar los probadores de los diversos documentos que van a producir? Cmo esos docu-mentos se relacionan
entre s? Si tiene intencin de utilizar herramientas para tareas como el diseo y ejecucin de pruebas, como se
explica en el captulo 6, que necesita para comprender como estos instrumentos de documentacin de captura
mientras se trabaja en el plan.

Algunos saber qu informacin deber reunirse en forma de datos en bruto y luego destilar. Qu mtricas
de qu se va a utilizar para supervisar, controlar y administrar las pruebas? Cul de esas mtricas - y tal vez
otras mtricas - va a utilizar para informar de sus resultados? Vamos a ver ms de cerca las posibles respuestas
a esas ques-ciones en la Seccin 5.3, pero un buen plan de ensayo respuestas al principio del proyecto.

Por ltimo, se mueve hacia atrs hasta un nivel ms alto, pensar en lo que es verdad sobre el proyecto
cuando el proyecto estaba listo para comenzar a ejecutar las pruebas. Qu sera verdad sobre el proyecto
cuando el proyecto estaba listo para declarar la prueba exe-cution hecho? En qu momento se puede
empezar con seguridad un determinado nivel o fase de prueba, banco de pruebas o destino de la prueba?
Cundo se puede acabarla? Los factores a tener en cuenta en este tipo de decisiones son a menudo
llamados "criterios de entrada y criterios de salida. ' Para tales criterios, factores tpicos son:

Adquisicin y suministro: la disponibilidad de personal, herramientas, sistemas y otros materiales

necesarios.
Elementos de prueba: Estado de que los elementos que se probarn debe estar en para iniciar y
terminar la prueba.

Defectos: el nmero conocido de estar presente, la tasa de llegada, la pre nmero predicho a
permanecer, y el nmero resuelto.

Pruebas: el nmero de ejecucin, pasada, con error, bloqueados, saltan, y as sucesivamente.

 Cobertura: las partes de la base de pruebas, el cdigo de software o ambos que han sido probados
y cules no.

Calidad: el estado de las caractersticas de calidad importantes para el sistema.

Dinero: el costo de encontrar el siguiente defecto en el nivel actual de las pruebas com comparacin con el
costo de encontrar en el siguiente nivel de la prueba (o de produccin).

Riesgo: los resultados no deseados que podran resultar de envo demasiado pronto (tales como
defectos latentes o zonas no probadas) - o demasiado tarde (como la prdida de cuota de mercado).

Al escribir los criterios de salida, tratamos de recordar que un proyecto exitoso es un equilibrio
de consideraciones de calidad, presupuesto, agenda y caractersticas.Esto es an ms importante
cuando se aplica el criterio de salida al final del proyecto.

5.2.3 Estimacin de las pruebas de lo que implica y lo que costar

El trabajo de pruebas que se hace a menudo puede ser visto como un subproyecto dentro del proyecto
general. Por lo tanto, podemos adaptar las tcnicas fundamentales de la estimacin para la prueba.
Podramos comenzar con una estructura de trabajo de desintegracin que identifica las fases, actividades
y tareas.

Comenzando en el nivel ms alto, podemos descomponer un proyecto en fases de pruebas utilizando el

proceso de prueba fundamental identificado en el Plan de estudios ISTQB: planificacin y control; anlisis y
diseo; implementacin y ejecucin; la evaluacin de los criterios de salida y presentacin de informes; y el
cierre de prueba. Dentro de cada fase se identifican las actividades y dentro de cada actividad identificamos
tareas y quizs subtareas. Para identificar las actividades y tareas, trabajamos tanto hacia delante y hacia atrs.
Cuando decimos que trabajamos hacia adelante, queremos decir que comenzamos con las actividades de
planificacin y luego avanzar en el paso a paso de tiempo, preguntando: "Ahora, qu viene despus? '

Trabajando hacia atrs significa que tenemos en cuenta los riesgos que se identificaron durante el
anlisis de riesgos (que discutiremos en la Seccin 5.5). Para aquellos riesgos que tiene la intencin de
abordar a travs de pruebas, se pregunta, 'Entonces, qu actividades y tareas se requieren en cada etapa
para llevar a cabo esta prueba?' Veamos un ejemplo de cmo se puede trabajar hacia atrs.

Supongamos que usted ha identificado actuacin como un rea importante de riesgo para su producto.
Por lo tanto, las pruebas de rendimiento es una actividad en la fase de ejecucin de la prueba. Ahora
podr valorar las tareas involucradas con la ejecucin de una prueba de rendimiento, el tiempo que esas
tareas se llevarn y el nmero de veces que se necesita para ejecutar las pruebas de rendimiento.

Ahora, esas pruebas no se acaba de aparecer de la nada: alguien tena que desarrollarlas. Por lo tanto, el
desarrollo de pruebas de rendimiento implica actividades de anlisis de la prueba, diseo e implementacin.
Ahora podr valorar las tareas implicadas en el desarrollo de un ensayo por-desempeo, tales como escribir
scripts de prueba y la creacin de datos de prueba.

Por lo general, las pruebas de rendimiento se deben ejecutar en un entorno de prueba especial que est
diseado para parecerse al entorno de produccin o en el campo, al menos en aquellas formas que podran
afectar el tiempo de respuesta y la utilizacin de recursos y realizar-ANCE pruebas necesitan herramientas
especiales para generar carga y comprobar la respuesta. Por lo tanto, llevar a cabo la adquisicin-ANCE
entorno de prueba y configuracin es una actividad en la fase de ejecucin de prueba. Ahora podr valorar las
tareas involucradas en la adquisicin y con-calculando un entorno de este tipo de prueba, tales como la
simulacin de rendimiento en los juegos

diseo de entorno de produccin para buscar posibles cuellos de botella, para obtener el derecho de hardware,
software y herramientas y la configuracin de hardware, software y herramientas.

No todo el mundo sabe cmo usar las herramientas de pruebas de rendimiento o el diseo de pruebas porrendimiento. Por lo tanto, el rendimiento de formacin el ensayo o la dotacin de personal es una actividad en
la fase de planificacin de las pruebas. Dependiendo del enfoque que desea tomar, ahora estimar el tiempo
necesario para identificar y contratar a un profesional de la prueba de rendimiento o para entrenar a una o ms
personas en su organizacin para hacer el trabajo.

Por ltimo, en muchos casos, un plan detallado de las pruebas se ha escrito para las pruebas de
rendimiento, debido a sus diferencias con respecto a otros tipos de pruebas. Por lo tanto, la planificacin
de la prueba de rendimiento es una actividad en la fase de planificacin de las pruebas. Ahora calcular el
tiempo necesario para redactar, revisar y finalizar un plan de pruebas de rendimiento.

Cuando va a crear su estructura de trabajo de desintegracin, recuerde que usted tendr que usar tanto
para la estimacin (al principio) y el seguimiento y control (como el proyecto sigue). Para asegurar la
precisin de la estimacin y el control preciso, asegrese de que subdividir el trabajo finamente
suficiente. Esto significa que las tareas deben ser de corta duracin, dicen uno a tres das. Si ellos son
mucho ms largos - por ejemplo dos semanas - entonces se corre el riesgo de que los largos y complejos
sub-tareas se 'esconden' dentro de la tarea ms grande, slo para descubrir ms tarde. Esto puede llevar a
sorpresas desagradables durante el proyecto.

5.2.4 Las tcnicas de estimacin

Hay dos tcnicas para la estimacin cubiertos por la Fundacin ISTQB Syllabus. Uno consiste en consultar a
la gente que va a hacer el trabajo y otras personas con experiencia en las tareas a realizar. El otro consiste en
analizar las mtricas de proyectos pasados y de los datos de la industria. Veamos cada uno de ellos.

Pidiendo a los contribuyentes y los expertos implica trabajar con los miembros del personal expementado para desarrollar una estructura de trabajo de desintegracin para el proyecto. Una vez hecho
esto, se trabaja en conjunto para comprender, para cada tarea, los requisitos de esfuerzo, duracin,
dependencias y recursos. La idea es aprovechar la sabidura colectiva del equipo para crear su estimacin
de prueba. El uso de una herramienta como Microsoft Project o una pizarra blanca y notas adhesivas,
usted y el equipo entonces puede predecir las pruebas finales actualizados y los principales hitos. Esta
tcnica se llama a menudo 'abajo hacia arriba' estimacin porque se inicia en el nivel ms bajo de la
ruptura hier-archical en la estructura de trabajo de desintegracin - la tarea - y dejar que la duracin,
esfuerzo, dependencias y recursos para cada tarea se suman en todos las tareas.

Anlisis de mtricas pueden ser tan simples o sofisticados como usted lo hace. El enfoque sim-plest es preguntar,
"Cuntas probadores es lo que normalmente tenemos por desarrollador en un proyecto? Un enfoque algo ms
fiable consiste en clasificar el proyecto en trminos de tamao (pequeo, mediano o grande) y la complejidad
(simple, mod-eRate o complejo) y luego ver, en promedio, los proyectos de cunto tiempo de una talla o
combinacin de complejidad han tomado en el pasado. Otro mtodo sencillo y fiable que hemos utilizado es para
mirar el esfuerzo promedio por caso de prueba en proyectos anteriores similares y de utilizar el nmero estimado de
casos de prueba para estimar el esfuerzo total. enfoques sofisticados implican la construccin de modelos
matemticos en una hoja de clculo que mira los promedios histricos o de la industria para ciertos parmetros clave
- nmero de pruebas realizadas por el probador por da, nmero de defectos encontrados por el probador por da,
etc. - y despus de conectar esos parmetros para predecir

duracin y esfuerzo para tareas o actividades clave en su proyecto.La relacin de probador a desarrollador es
un ejemplo de una tcnica de estimacin de arriba hacia abajo, en la que la totalidad de la estimacin se deriva
a nivel de proyecto, mientras que la tcnica paramtrica es de abajo hacia arriba, por lo menos cuando se
utiliza para estimar las tareas individuales o ocupaciones.

Preferimos empezar haciendo uso de la sabidura del equipo para crear la estructura de trabajo de
desintegracin y una estimacin detallada de abajo hacia arriba. A continuacin, aplicamos modelos y
reglas generales para comprobar y ajustar la estimacin de abajo arriba y de arriba hacia abajo usando la
historia pasada. Este enfoque tiende a crear una estimacin que es a la vez ms precisa y ms defendible
que cualquiera de las tcnicas por s mismo.

Incluso la mejor estimacin se debe negociar con la direccin. Las sesiones de negociacin exhiben
variedad increble, dependiendo de las personas involucradas. Sin embargo, hay algunas posiciones de
negociacin clsicos. No es inusual para el lder de pruebas o de tratar de vender el equipo de gestin en el
valor agregado de la prueba o para alertar a la gestin de los problemas potenciales que se derivaran de la
prueba no es suficiente. No es inusual para una gestin que debe buscar formas inteligentes para acelerar la
programacin o para conseguir una cobertura equivalente en menos tiempo o con menos recursos. En medio de
estas posiciones, usted y sus colegas pueden llegar a un compromiso, si las partes estn dispuestas. Nuestra
experiencia ha sido que las negociaciones exitosas sobre estimaciones son aquellos en los que la atencin se
centra menos en ganar y perder y ms acerca de averiguar la mejor manera de equilibrar las presiones de la
competencia en los mbitos de calidad, programacin, presupuesto y caractersticas.

5.2.5 Factores que afectan esfuerzo de la prueba

La prueba es una tarea compleja en muchos proyectos y una variedad de factores que pueden influir en ella. Al
crear planes de prueba y la estimacin del esfuerzo de prueba y el calendario, usted debe tener en cuenta estos
factores o sus planes y estimaciones le engaar al comienzo del proyecto y traicionarte en el medio o al final.

Las estrategias de prueba o enfoques que usted escoge tendrn una influencia importante en el esfuerzo
de prueba. Este factor es tan influyente que vamos a volver a ella en la Seccin 5.2.6. En esta seccin,
vamos a ver los factores relacionados con el producto, el proceso y los resultados de las pruebas.

factores de productos comienzan con la presencia de la documentacin del proyecto suficiente para que
los probadores puede averiguar lo que el sistema es, cmo se supone que funciona y qu comportamiento
correcto se parece. En otras palabras, adecuada y de alta calidad de la informacin sobre la base de
pruebas nos ayudar a hacer un mejor trabajo, ms eficiente de la definicin de las pruebas.

La importancia de las caractersticas de calidad no funcionales tales como la facilidad de uso,

fiabilidad, seguridad, rendimiento, y as sucesivamente tambin influye en el esfuerzo de prueba. Estos
objetivos de la prueba puede ser costoso y consume mucho tiempo.

La complejidad es otro factor importante producto. Los ejemplos de complejidad-opera- Considrant

incluyen:

La dificultad de comprender y manejar el problema que el sistema est siendo construido para resolver
correctamente (por ejemplo, avinica y software de exploracin de petrleo);

 El uso de tecnologas innovadoras, en especial los de largo en la hiprbole y corto en un historial

probado;

La necesidad de configuraciones de prueba intrincados y tal vez mltiples, sobre todo cuando stos
dependen de la llegada oportuna de software escasos, hardware y otros suministros;

La prevalencia de las normas de seguridad muy estrictas, estrictamente reglamentadas procesos u

otras normativas;
La distribucin geogrfica del equipo, sobre todo si el equipo cruza zonas horarias (como muchos
de los esfuerzos de externalizacin hacen).

Mientras que la buena documentacin del proyecto es un factor positivo, tambin es cierto que tener
que presentar la documentacin detallada, como los casos de prueba especificados meticulosamente, da
lugar a retrasos. Durante la ejecucin de pruebas, tener que mantener dicha documentacin detallada
requiere mucho esfuerzo, al igual que el trabajo con los datos de prueba frgiles que deben ser
mantenidas o restauradas con frecuencia durante la prueba.

Finalmente, el aumento del tamao del producto conduce a aumentos en el tamao del proyecto y el
equipo de proyecto. Aumenta en el proyecto y su equipo aumenta la dificultad de predecir y gestionar
ellos. Esto lleva a la tasa de des-proporcional del colapso de grandes proyectos.

factores de proceso incluyen la disponibilidad de herramientas de prueba, especialmente aquellas que

reducen el esfuerzo asociado con la ejecucin de la prueba, que se encuentra en la ruta crtica para la
liberacin. En el lado de desarrollo, las herramientas de depuracin y un entorno de depuracin dedicado
(a diferencia de la depuracin en el entorno de prueba) tambin reducir el tiempo requerido para
completar las pruebas.

El ciclo de la vida misma es un factor influyente proceso, como el V-modelo tiende a ser ms frgil en la cara de
cambio de ltima hora mientras que los modelos incrementales tienden a tener costos de las pruebas de regresin alta. la
madurez del proceso, incluyendo la madurez del proceso de prueba, es otro de los factores, especialmente la implicacin
de que maduran procesos implican el manejo cuidadoso de cambio en el medio y al final del proyecto, lo que reduce el
coste de ejecucin de la prueba.

La presin del tiempo es otro factor a considerar. La presin no debe ser una excusa para tomar riesgos
innecesarios. Sin embargo, es una razn para tomar decisiones cuidadosas, con-considerarse y planificar
y volver a planificar de manera inteligente durante todo el proceso, que es otra caracterstica de los
procesos maduros.

Las personas ejecutan el proceso, y la gente factores son tan importantes o ms importantes que
cualquier otra. De hecho, incluso cuando muchas cosas preocupantes son ciertas acerca de un proyecto,
un excelente equipo puede a menudo hacen que sucedan cosas buenas en el proyecto y en las pruebas.
Personas importantes factores incluyen las habilidades de los indi-UALs y el equipo en su conjunto, y la
alineacin de las habilidades con las necesidades del proyecto. Desde un equipo de proyecto es un equipo,
relaciones slidas, la ejecucin fiable de acordados los compromisos y responsabilidades y una
determinacin de trabajar juntos hacia un objetivo comn son importantes. Esto es especialmente
importante para las pruebas, donde gran parte de lo que probamos, el uso y genera ni proviene de, o se
basa en destina a personas fuera del grupo de prueba. Debido a la impor-tancia de relaciones de confianza
y las largas curvas de aprendizaje involucrados en soft-ware y la ingeniera de sistemas, la estabilidad del
equipo de proyecto es un factor importante de personas, tambin.

Resultados de la prueba en s son importantes en la cantidad total de esfuerzo de la prueba durante la

ejecucin de la prueba. La entrega de software de buena calidad en el inicio de la ejecucin de pruebas y
reparaciones de defectos, slidos rpidas durante la ejecucin de pruebas evita retrasos en el proceso de
ejecucin de la prueba. Un defecto, una vez identificados, no debera tener que pasar por varios ciclos de
correccin / retest / re-abierta, al menos no si la estimacin inicial se va a celebrar a.

Usted probablemente ha notado que a partir de esta lista se incluyeron una serie de factores que estn fuera
del alcance y control del supervisor de la prueba o el administrador. De hecho, los eventos que

ocurrir antes o despus de la prueba puede traer estos factores sobre.Por esta razn, es importante que los
probadores, especialmente los lderes o gerentes de prueba, estar en sintona con el contexto general en el
que operan. Algunos de estos factores contextuales impliquen un riesgo de proyectos especficos para las
pruebas, que deben ser abordados en el plan de pruebas. Los riesgos del proyecto se analizan con ms
detalle en la Seccin 5.5.

5.2.6 Prueba de enfoques o estrategias

La eleccin de los enfoques o estrategias de ensayo es un poderoso factor en el xito de la prueba de

esfuerzo y la exactitud de los planes de pruebas y estimaciones.Este factor est bajo el control de los
probadores y lderes de prueba. Por supuesto, tener opciones tambin significa que se pueden cometer
errores, por lo que vamos a hablar de cmo elegir las estrategias de prueba correctas en un minuto. En
primer lugar, sin embargo, vamos encuesta los principales tipos de prueba Strate-gas que se encuentran
comnmente. 1

 Analtica: Por ejemplo, la estrategia basada en el riesgo implica la realizacin de un anlisis de

riesgos utilizando documentos de proyectos y aportaciones de las mismas, a continuacin, la
planificacin, el apareamiento esti, el diseo, y dar prioridad a las pruebas basadas en el riesgo.
(Hablaremos ms sobre el anlisis de riesgo ms adelante en este captulo). Otra estrategia de ensayo
analtico es la estrategia basada en las necesidades, en un anlisis de los requisitos de especificaciones
ficacin constituye la base para la planificacin, el diseo y la estimacin de las pruebas. estrategias
de pruebas analticas tienen en comn el uso de algunos formal o infor tcnica analtica mal, por lo
general durante las etapas de diseo y requisitos del proyecto.

Basado en modelos: Por ejemplo, se puede construir modelos matemticos para la carga y la respuesta de los
servidores de comercio electrnico, y la prueba sobre la base de ese modelo.Si el comportamiento del sistema
bajo prueba se ajusta a la predicha por el modelo, el sistema se considera estar funcionando. estrategias de
prueba basados en modelos tienen en comn la creacin o seleccin de un cierto modelo formal o informal para
los comportamientos crticos del sistema, por lo general durante los requisitos y las etapas de diseo del
proyecto.

Metdica: Por ejemplo, es posible que tenga una lista de comprobacin que ha reunido en los ltimos aos
que sugieren las principales reas de las pruebas para correr o podra seguir un estndar de la industria para la
calidad del software, tales como ISO 9126, para su esbozo de las principales pruebas reas.A continuacin,
disear metdicamente, implementar y ejecutar las pruebas siguiendo este esquema. estrategias de pruebas
metdicas tienen en comn la adhesin a un enfoque planificado previamente, sistematizado que se ha
desarrollado en la empresa, montado a partir de varios conceptos desarrollados internamente y se reunieron
desde el exterior, o adaptado significativamente de las ideas del exterior y puede tener una temprana o tarda
punto de participacin para la prueba.

Procesamiento o compatible con el estndar: Por ejemplo, se podran adoptar la norma IEEE 829 para su
prueba, el uso de libros tales como [Craig, 2002] o [Drabick, 2004] para llenar los vacos
metodolgicos.Alternativamente, es posible adoptar una de las metodologas giles como la programacin
extrema. Dard estrategias conformes a procesos o stan tienen en comn la dependencia en un enfoque
desarrollado externamente a la prueba, a menudo con poco - en su caso - la personalizacin y pueden tener un
punto de participacin para la prueba temprana o tarda.

El catlogo de estrategias de ensayo que se ha incluido en el Plan de Estudios de la Fundacin ISTQB surgi de una discusin
por correo electrnico entre Rex Negro, Ross Collard, Kathy Iberle y Cem Kaner.Les damos las gracias por sus comentarios a la
reflexin.

Dinmica: Por ejemplo, puede crear un conjunto ligero de las lneas de gua de prueba que se centran
en la adaptacin rpida o debilidades conocidas en el software.Estrategias dinmicas, tales como pruebas
exploratorias, tienen en concentrat comn ing en la bsqueda de la mayor cantidad posible de defectos
durante la ejecucin de la prueba y se adaptan ing a las realidades del sistema bajo prueba, ya que es

cuando se entrega, y por lo general hacen hincapi en las ltimas etapas de la prueba.Vase, por ejemplo,
el enfoque basado en el ataque de [Whittaker, 2002] y [Whittaker, 2003] y el enfoque de exploracin de
[Kaner et al., 2002].

Consultivo o dirigida: Por ejemplo, es posible que pedir a los usuarios o desarrollar res del sistema
para que le informan sobre lo que prueba ni siquiera dependen de ellos para hacer la prueba.las
estrategias de consulta o dirigidos tienen en comn la dependencia de un grupo de no-testers para
guiar o llevar a cabo el esfuerzo de prueba y por lo general hacen hincapi en las ltimas etapas de la
prueba, simplemente debido a la falta de reconocimiento del valor de las primeras pruebas.

Regresin de aversin: Por ejemplo, usted puede tratar de automatizar todas las pruebas de
funcionalidad del sistema de modo que, cada vez que algo cambia, puede volver a ejecutar todas las
pruebas para asegurar que nada se ha roto.en tcnicas de regresin con aversin tienen en comn un
conjunto de procedimientos automatizados - por lo general - que les permiten detectar defectos de
regresin. Una estrategia de regresin de aversin puede implicar la automatizacin de pruebas
funcionales antes de su liberacin de la funcin, en cuyo caso se requiere una prueba temprana, pero a
veces la prueba se centr casi exclusivamente en la fun ciones de prueba que ya han sido puestos en
libertad, que es en cierto sentido un formulario de la participacin de la prueba posterior a la
liberacin.

Algunas de estas estrategias son ms preventivo, otros ms reactivo. Por ejemplo, la estrategia de pruebas
analticas implican el anlisis inicial de la base de pruebas, y tienden a identificar los problemas en la base de
pruebas antes de la ejecucin de la prueba. Esto permite que el temprano - y barato - la eliminacin de los defectos.
Esa es una fortaleza de los enfoques preventivos.

las estrategias de los ensayos dinmicos que se centran en el perodo de ejecucin de la prueba. Tales
estrategias permiten la localizacin de defectos y clusters de defectos que podran haber sido difcil
anticipar hasta que tenga el sistema real en frente de usted. Esa es una fuerza de enfoques reactivos.

En lugar de ver la seleccin de estrategias, en particular las estrategias preventivas o REAC-tivo, ya

sea como una / o situacin, vamos a dejar entrar en el secreto peor guardado de la prueba (y muchas otras
disciplinas): No hay nadie mejor camino. Sugerimos que usted adopta cualquier prueba enfoques tienen
ms sentido en su situacin particu-lar, y no dude en pedir prestado y mezclar.

Cmo sabes qu estrategias para recoger o mezcla de las mejores posibilidades de xito? Hay muchos
factores a considerar, pero nos permiten destacar algunos de los ms importantes:

 Riesgos: La prueba es sobre la gestin de riesgos, por lo que debe tener en cuenta los riesgos y el
nivel de riesgo.Para una aplicacin bien establecida que est evolucionando lentamente, la regresin
es un riesgo importante, por lo que las estrategias de regresin con aversin tienen sentido. Para una
nueva aplicacin, un anlisis de riesgos puede revelar diferentes riesgos si tienes que elegir una
estrategia de anlisis basado en el riesgo.

Habilidades: Las estrategias no slo deben ser elegidos, sino que tambin deben ser ejecutados.Por
lo tanto, usted tiene que considerar qu habilidades poseen sus probadores y la falta. Una estrategia
compatibles con el estndar es una opcin inteligente cuando se carece de tiempo y habilidades en su
equipo para crear su propio enfoque.

Objetivos: Las pruebas deben satisfacer las necesidades de los interesados para tener xito.Si el
objetivo es encontrar el mayor nmero de defectos como sea posible con una cantidad mnima de por
adelantado el tiempo y esfuerzo invertido - por ejemplo, en un tpico laboratorio de pruebas
independiente - a continuacin, una estrategia dinmica tiene sentido.

Regulaciones: A veces hay que satisfacer no slo las partes interesadas, sino tambin reg ulators.En
este caso, puede ser necesario disear una estrategia de ensayo metdico que satisface estos reguladores
que se han cumplido todos los requisitos.

Producto: Algunos productos tales como sistemas de armas y software contrato de desarrollo
tienden a tener requisitos bien especificados.Esto conduce a la sinergia con una estrategia de anlisis
basados en los requisitos.

Negocio: consideraciones comerciales y continuidad del negocio son a menudo impor tante.Si
usted puede utilizar un sistema heredado como un modelo para un nuevo sistema, se puede utilizar una
estrategia basada en el modelo.

Ya hemos mencionado que un buen equipo a veces puede triunfar sobre una situa-cin donde los
materiales, procesos y factores que retrasan se iban en contra de su xito. Sin embargo, la ejecucin del
talento de una estrategia prudente es equivalente a ir muy rpido por una carretera en la direccin
equivocada. Por lo tanto, debe tomar decisiones inteligentes en trminos de estrategias de ensayo. Por otra
parte, se debe elegir estrategias de ensayo con un ojo hacia los factores mencionados anteriormente, la
programacin, el presupuesto y las limitaciones funcionales que ofrece el proyecto y las realidades de la
organizacin y su poltica.

5.3 PRUEBA DE SEGUIMIENTO Y PROGRESO

Control de Lote

1 Recordemos mtricas comunes que se utilizan para la preparacin de la prueba de

seguimiento y ejecu
. {0}k = 0.015 L{/0}{1}1{/1}

2 Comprender e interpretar las mtricas de prueba para la presentacin de

informes de prueba y control de prueba
(Por ejemplo, los defectos encontrados y se fijaron y pruebas pasaron y no). (k)

3 Resumir el propsito y el contenido de la prueba de informe resumido docu

Ment de acuerdo con [IEEE 829]. (k)

En esta seccin, vamos a revisar las tcnicas y las mtricas que se utilizan comnmente para la
preparacin de la prueba de supervisin y ejecucin. Nos centraremos especialmente en el uso e
interpretacin de tales parmetros de prueba para la presentacin de informes, controlando y analizando
el esfuerzo de la prueba, incluyendo las basadas en defectos y los basados en los datos de prueba.
Tambin vamos a ver opciones para informar sobre el estado de prueba utilizando dichas mtricas y otra
informacin.

A medida que lea, recuerde que debe velar por la densidad de los trminos del glosario defecto, falla

tasa, control de prueba, cobertura de la prueba, monitorizacin de las pruebas y el informe

de prueba.

5.3.1 Seguimiento de la evolucin de las actividades de prueba

Despus de haber desarrollado nuestros planes, que se define nuestras estrategias y enfoques de prueba y
estim que el trabajo a realizar, ahora tenemos que seguir nuestro trabajo de pruebas que llevamos a
cabo. Monitoreo de prueba puede servir a varios propsitos durante el proyecto, incluyendo las
siguientes:

Darle al equipo de prueba y el director de pruebas de retroalimentacin sobre cmo el trabajo de ensayo se
va, lo que permite oportunidades para orientar y mejorar las pruebas y el proyecto.

Proporcionar al equipo de proyecto con la visibilidad de los resultados de las pruebas.

Medir el estado de los elementos de prueba, la cobertura de prueba y de ensayo frente a los
criterios de salida para determinar si el trabajo de examen se realiza.

Recopilar datos para su uso en la estimacin de los esfuerzos de las pruebas futuras.

Especialmente para proyectos pequeos, el lder de prueba o una persona delegada pueden reunir progreso
de la prueba control de la informacin de forma manual utilizando documentos, hojas de clculo y bases de
datos simples. Cuando se trabaja con equipos grandes, proyectos distribuidos y los esfuerzos de prueba a largo
plazo, nos encontramos con que la eficacia y la coherencia de los datos colec-cin es ayudado por el uso de
herramientas automatizadas (vase el Captulo 6).

Una manera de reunir informacin progreso de la prueba es el uso de la plantilla de registro de la

prueba IEEE 829. Si bien gran parte de la informacin relacionada con los eventos de registro puede

haber un uso totalmente capturados en un documento, preferimos para capturar la informacin de la

prueba por prueba en hojas de clculo (vase la Figura 5.1).

IEEE 829 STANDARD: LOG plantilla de prueba

Identificador de registro de pruebas

Descripcin (piezas que se prueben,

entradas de actividad y de eventos

(ejecucin

Descripcin resultados,
procedimiento,

ambiente en el que la prueba es

{0}{/0} {1}
{/1} {2}la
informacin ambiental,{/2}

llevadas a cabo.

eventos anmalos, informe de

incidente

los identificadores.

En la Figura 5.1, las columnas A y B muestran la ID de prueba y el caso de ensayo o prueba de nombre de
suite. El estado del caso de prueba se muestra en la columna C ( 'Warn' indica una prueba que dio lugar a una
falla menor). Columna D muestra la configuracin de prueba, donde los cdigos de A, B y C corresponden a
probar entornos que se describen en detalle en el plan de prueba. Las columnas E y F muestran el nmero de
defectos (o error) ID (de la base de datos de seguimiento de defectos) y el nmero de prioridad de riesgo del
defecto (que van desde 1, la peor, a 25, el menos arriesgado). Columna G muestra las iniciales del probador
que corri la prueba. Columnas H a travs de los datos de captura de mayor para cada prueba relacionada con
las fechas, el esfuerzo y la duracin (en horas). Tenemos mtrica para el esfuerzo y las fechas previstas y reales
completado lo que nos permitira resumir el progreso contra el calendario y el presupuesto previsto. Esta hoja
de clculo tambin se puede resumir en trminos del porcentaje de pruebas que se hagan funcionar y el
porcentaje de pruebas que han pasado y han fallado.

Figura 5.1 podra mostrar una instantnea del progreso de la prueba durante el perodo de ejecucin de
la prueba, o tal vez incluso a prueba de cierre si se considera aceptable para omitir algunas de las pruebas.
Durante el anlisis, diseo e implementacin de las pruebas, una hoja de clculo as mostrara el estado de
las pruebas en funcin de su estado de desarrollo.

Adems del estado de casos de prueba, tambin es comn para monitorear el progreso de ensayo
durante el perodo de ejecucin de la prueba observando el nmero de defectos encontrados y fijos.
Figura 5.2 muestra un grfico que traza el nmero total de defectos abiertos y cerrados en el transcurso de
la ejecucin de la prueba hasta el momento.

Tambin muestra el perodo de prueba de la fecha de finalizacin prevista y el nmero previsto de los
defectos que se encontraron. Lo ideal es que el proyecto se acerca la fecha de finalizacin prevista, el
nmero total de defectos abiertos se instalar en el nmero previsto y el nmero total de defectos
corregidos se reunirn con el nmero total de abrirse. Estos dos resultados nos dicen que hemos
encontrado bastantes defectos se sientan cmodos que hemos terminado la prueba, que no tenemos
ninguna razn para pensar que muchos ms defectos estn al acecho en el producto, y que todos los
defectos conocidos se han resuelto.

Grficas tales como la Figura 5.2 tambin se pueden utilizar para mostrar las tasas de fallo o defecto
densidad.Cuando la fiabilidad es una preocupacin fundamental, podramos estar ms preocupado por la
frecuencia con la que se observan fallos que con el nmero de defectos estn causando los fracasos.En las
organizaciones que estn buscando para producir ultra-fiable

software, que puede representar el nmero de defectos sin resolver normalizado por el tamao del
producto, ya sea en miles de lneas de cdigo fuente (KSLOC), los puntos de func-cin (FP) o alguna otra
mtrica de tamao del cdigo. Una vez que el nmero de defectos-Unre resuelto cae por debajo de un
umbral predefinido - por ejemplo, tres por cada milln de lneas de cdigo - a continuacin, el producto
pueden considerarse que cumplen los criterios de salida densidad de defectos.

Medir el progreso prueba basada en los defectos encontrados y fijo es comn y til - si se usan con
cuidado. Evitar el uso de mtricas de defectos solo, ya que es posible lograr un defecto plana encontrar
tarifas y solucionar todos los defectos conocidos por detener cualquier prueba adicional, al impedir
deliberadamente la notificacin de defectos y por permitir-ing programadores a rechazar, cancelar o cerca
informes de defectos sin ninguna revisin inde-pendiente.

Que las tcnicas dicho, controlando el progreso de ensayo varan considerablemente dependiendo de
las preferencias de los probadores y las partes interesadas, las necesidades y objetivos del proyecto, los
requisitos reglamentarios, las limitaciones de tiempo y de dinero y otros factores. Adems de los tipos de
informacin que aparecen en la norma IEEE 829 Prueba de plantilla de registro, las figuras 5.1 y Figura
5.2, otros indicadores comunes para el seguimiento progreso de la prueba son:

El grado de terminacin de la preparacin entorno de prueba;

La extensin de la cobertura de las pruebas logrado, medido frente a los requisitos, riesgos,
cdigo, configuraciones u otras reas de inters;

El estado de la prueba (incluyendo el anlisis, diseo e implementacin) en comparacin con

diversos hitos de prueba;

La economa de la prueba, tales como los costes y beneficios de la ejecucin de la prueba continua en
trminos de encontrar el siguiente defecto o ejecutar la siguiente prueba.

Como tcnica de monitorizacin complementaria, es posible evaluar el nivel subjetivo de la confianza de los
probadores tienen en los artculos de la prueba.Sin embargo, evitar tomar decisiones importantes basadas en
evaluaciones subjetivas por s solos, como impres-siones de las personas tienen una forma de ser inexacta y
coloreado por el sesgo.

5.3.2 Informes de estado de la prueba

monitoreo de progreso de la prueba se trata de la recopilacin de los datos de prueba detallado; informar sobre
el estado de prueba es de comunicar de manera eficaz los resultados del proyecto a otras partes interesadas. Al
igual que con el control del progreso de prueba, en la prctica existe una gran variabilidad observada en cmo
la gente se informe provisional de situacin, con las variaciones impulsadas por las pref-cias de los probadores
y las partes interesadas, las necesidades y objetivos del proyecto, los requisitos de reg-ulatory, el tiempo y
limitaciones de dinero y las limitaciones de las herramientas disponibles para la presentacin de informes de
situacin. A menudo, las variaciones o resmenes de las mtricas utilizadas para el monitoreo progreso de la
prueba, como la Figura 5.1 y Figura 5.2, se utilizan para los informes de estado de prueba, tambin.
Independientemente de lo especfico mtricas, grficos e informes utilizados, informes de estado de prueba es
de ayudar a los participantes del proyecto insuficientemente soportar los resultados de un perodo de prueba,
especialmente en lo que se refiere a los objetivos fundamentales del proyecto y si (o cuando) los criterios de
salida se mostraron satisfechos.

Adems de notificar a los interesados del proyecto sobre los resultados de pruebas, informes de estado
de prueba es a menudo sobre esclarecedor e influir en ellos. Esto implica ana-lizarla, la informacin y las
mtricas disponibles para apoyar las conclusiones, recomen-daciones y decisiones acerca de cmo
orientar el proyecto hacia adelante o tomar otras acciones. Por ejemplo, podramos estimar el nmero de
defectos que quedan por descubrir, presentar los costos y beneficios de retrasar la fecha de lanzamiento
para permitir ms pruebas, evaluar los riesgos de los productos y de los proyectos restantes y ofrecer una
opinin sobre la confianza de las partes interesadas deben tener en la calidad del sistema bajo prueba.

Usted debe pensar en los informes de estado de prueba durante los perodos de planificacin y preparacin
de la prueba, ya que a menudo tendr que recoger las mtricas especficas durante y al final de un perodo de
prueba para generar los informes de estado de prueba de una manera eficaz y eficiente. Los datos especficos
que usted desee para recoger depender de sus informes especficos, pero las consideraciones comunes
incluyen los siguientes:

Cmo va a evaluar la adecuacin de los objetivos de la prueba para un nivel de prueba dado y si
se lograron los objetivos?
Cmo va a evaluar la adecuacin de la prueba enfoques adoptados y si apoyar el logro de los
objetivos de prueba del proyecto?

Cmo va a evaluar la eficacia de la prueba con respecto a estos objetivos y enfoques?

Por ejemplo, si usted est haciendo la prueba basada en el riesgo, un objetivo principal de la prueba consiste
en someter los riesgos importantes de productos en la medida adecuada de la prueba. La Tabla 5.1 muestra un
ejemplo de un grfico que permitira a informar de su prueba de encubrimiento edad y defectos no resueltos
frente a las principales reas de riesgo producto que identific en el el anlisis de riesgos.Si usted est haciendo
las pruebas basadas en requisitos, se puede medir la cobertura en trminos de requisitos o reas funcionales en
lugar de riesgos.

En algunos proyectos, el equipo de pruebas debe crear un informe de resumen de la prueba. Dicho
informe, creado ya sea en un hito clave o al final de un nivel de prueba, se describen los resultados de un
determinado grado o fase de las pruebas. La prueba estndar IEEE 829

Resumen plantilla de informe proporciona una gua til para lo que entra en dicho informe. Adems de
incluir el tipo de grficos y tablas que se muestran anteriormente, es posible discutir los eventos
importantes (especialmente problemticas) que se produjeron durante las pruebas, los objetivos de la
prueba y si lo fueron, la estrategia de prueba sigui y lo bien que funcion, y el eficacia global del
esfuerzo de la prueba.

IEEE 829 STANDARD:

PRUEBA DE INFORME RESUMEN

PLANTILLA

Prueba identificador informe

resumido

Evaluacin

Resumen

Resumen de las actividades

varianzas

Aprobaciones

Evaluacin detallada

Resumen de Resultados

5.3.3 Prueba de control

Proyectos no siempre se desarrollan segn lo previsto. De hecho, toda obra humana ms complicado que
un da de campo familiar es probable que vare de plan. Los riesgos se convierten en ocurrencias.
necesidades de los interesados evolucionan. El mundo que nos rodea cambia. Cuando los planes y la
realidad divergen, debemos actuar para llevar el proyecto de nuevo bajo control.

En algunos casos, los resultados de prueba en s son detrs de la divergencia; Por ejemplo, supongamos
que la calidad de los artculos de la prueba resulta inaceptablemente malo y retrasos Progreso de la prueba.
En otros casos, las pruebas se ve afectada por eventos fuera; por ejemplo, las pruebas pueden ser retrasada
cuando los elementos de prueba llegan tarde o el entorno de prueba no est disponible. Control de prueba
se trata de orientar y acciones correctivas para tratar de lograr el mejor resultado posible para el proyecto.

Las acciones correctivas o rectores especficos dependen, por supuesto, de lo que estamos tratando
de controlar. Considere los siguientes ejemplos hipotticos:

Una parte del software bajo prueba ser entregado tarde, despus de la fecha de inicio de la prueba
prevista. Las condiciones del mercado dictan que no podemos cambiar la liberacin

Fecha - 2016Prueba de control podra implicar modificar las prioridades de las pruebas para
que podamos empezar a probar en contra de lo que est disponible ahora.

Por razones de coste, pruebas de rendimiento se ejecuta normalmente en las noches de

entre semana fuera del horario en el entorno de produccin.Debido a la alta demanda
imprevista de sus productos, la compaa ha adoptado temporalmente un turno de noche que
mantiene el entorno de produccin en uso 18 horas al da, cinco das a la semana. Prueba de
control podra implicar la reprogramacin de las pruebas de rendimiento para el fin de semana.

Aunque estos ejemplos muestran las acciones de control de la prueba que afectan a las
pruebas, el equipo del proyecto tambin podra tener que tomar otras acciones que afectan a
terceros en el proyecto. Por ejemplo, supongamos que la fecha de finalizacin de la prueba est
en riesgo debido a un elevado nmero de reparaciones de defectos que fallan las pruebas de
confirmacin en el entorno de prueba. En este caso, el control de la prueba podra implicar que

requieren los programadores hacer las correcciones para volver a probar a fondo las correcciones
antes de registrarse en el repositorio de cdigo para su inclusin en una compilacin de prueba.

Gestin de la configuracin

1 Resumir cmo la gestin de configuracin admite la prueba. (k)

En esta breve seccin, vamos a ver cmo la gestin de configuracin se refiere a las pruebas y
apoya. Usted se encontrar con el control de gestin de la configuracin y la versin trminos
del glosario.

Gestin de la configuracin es un tema que a menudo confunde a la nueva practicantes,

pero, si alguna vez tiene la mala suerte de trabajar como probador en un proyecto donde se
maneja mal esta actividad crtica, que jams olvidar lo importante que es.En pocas palabras,
gestin de la configuracin es, en parte, sobre la determinacin claramente lo que los artculos
son que componen el software o sistema. Estos artculos incluyen el cdigo fuente, scripts de
prueba, el software de terceros, hardware, los datos y el desarrollo y documentacin de prueba.
gestin de la configuracin es tambin trata de asegurar que estos elementos se utilizan
cuidadosamente, a fondo y con atencin en todo el ciclo de vida del producto y del proyecto.

Gestin de la configuracin tiene una serie de implicaciones importantes para las pruebas. Por
un lado, permite a los probadores para gestionar sus testware y resultados de pruebas usando los
mismos mecanismos de gestin de configuracin, como si fueran tan valioso como el cdigo
fuente y la documentacin para el sistema en s - que por supuesto que son.

Por otro lado, la gestin de configuracin es compatible con el proceso de construccin, que
es esencial para la entrega de un comunicado de prueba en el entorno de prueba. El simple envo
de archivos Zip por correo electrnico no ser suficiente, porque hay demasiadas oportunidades
para este tipo de archivos que se contaminan con contenidos no deseados o para albergar

izquierda con respecto a versiones anteriores de los artculos. Sobre todo en las ltimas fases de
la prueba, es fundamental tener una forma slida y fiable de entrega de elementos de prueba que
funcionan y son la versin correcta.

Por ltimo, pero no menos importante, la administracin de configuracin nos permite mapear
lo que est poniendo a prueba a los archivos subyacentes y los componentes que lo integran.Esto
es absolutamente crtico. Por ejemplo, cuando nos informan de defectos, tenemos que informar
sobre ellos en contra de algo, lo que es controlada versin. Si no est claro lo que encontramos
en el defecto, los programadores tendrn un tiempo muy difcil de encontrar el defecto con el fin
de solucionarlo. Para el tipo de informes de ensayos discutidos anteriormente de tener sentido,
debemos ser capaces de rastrear los resultados de la prueba de nuevo a qu es exactamente lo
que hemos probado.

Idealmente, cuando se los somete una, las versiones de prueba bajo control de versiones
organizada de un repositorio de cdigo fuente gestionados cambio, se acompaa de un elemento
de prueba informe de trans-Mittal o notas de release. [IEEE 829] proporciona una gua til para
lo que entra en dicho informe. Notas de la versin no son siempre tan formal y no contienen toda
la informacin siempre se muestra.

Mientras que nuestra descripcin fue breve, gestin de la configuracin es un tema que es tan
compleja como la gestin de medio ambiente. Por lo tanto, la planificacin avanzada es
fundamental para hacer este trabajo. Durante la fase de planificacin del proyecto - y tal vez
como parte de su propio plan de pruebas - asegurarse de que los procedimientos y herramientas
de gestin de configuracin se seleccionan. A medida que avanza el proyecto, el proceso y los
mecanismos de configuracin deben llevarse a cabo, y las interfaces clave para el resto del
proceso de desarrollo deben ser documentados. Llegado el momento de ejecucin de la prueba,
esto permitir que usted y el resto del equipo del proyecto para evitar sorpresas desagradables,
como las pruebas del software equivocado, recibiendo puedan instalar construcciones y
comunicar defectos irreproducibles contra una versin de cdigo que no existen ms que en el
entorno de prueba.

IEEE 829 STANDARD: TEST

ARTCULO DE INFORME
DE TRANSMISIN DE LA PLANTILLA

identificador de informe de transmisin

elementos de transmisin

Ubicacin

Estatus

Aprobaciones

17/1/200 5 RIESGO Y ENSAYO

1 Describir un riesgo como un posible problema que pondra en peligro el lograr

cin de los objetivos del proyecto una o ms de las partes interesadas. (k)

2 Recuerde que los riesgos son determinados por la probabilidad (de ocurrir) y
impacto (dao resultante si sucede). {0}k = 0.015 L{/0}{1}1{/1}

3 Distinguir entre los riesgos del proyecto y del producto.(k)

4 Reconocer productos y proyectos riesgos tpicos.{0}k = 0.015 L{/0}{1}1{/1}

5 Describir, mediante ejemplos, cmo el anlisis y gestin de riesgos puede

ser utilizado para la planificacin de pruebas. (k)

Esta seccin trata sobre un tema que creemos que es fundamental para las pruebas: el riesgo.Veamos de cerca a
los riesgos, los posibles problemas que pudieran poner en peligro los objetivos de los interesados en el
proyecto. Vamos a discutir la forma de determinar el nivel de riesgo utilizando como lihood-e impacto.
Veremos que existen riesgos relacionados con el producto y los riesgos relacionados con el proyecto, y
miramos a los riesgos tpicos en ambas categoras. Por ltimo - y ms importante - vamos a ver diferentes
formas en que el anlisis de riesgos y el riesgo de administrar-ment pueden ayudar a trazar un curso para la
prueba slida
A medida que lea esta seccin, asegrese de asistir con atencin los trminos del glosario

riesgo del producto, el riesgo del proyecto, el riesgo y la prueba basada en el riesgo.

5.5.1 Riesgos y niveles de riesgo

El riesgo es una palabra que todos usamos sin apretar, pero qu es el riesgo?En pocas palabras, es el
posibilidad de un resultado negativo o indeseable.En el futuro, un riesgo tiene cierta probabilidad entre
0% y 100%; es una posibilidad, no una certeza. En el pasado, sin embargo, ya sea el riesgo se ha
materializado y convertirse en un resultado o problema o no lo ha hecho; la probabilidad de un riesgo
en el pasado es o bien 0% o 100%.

La probabilidad de un riesgo de convertirse en un resultado es un factor a considerar cuando se piensa

en el nivel de riesgo asociado con sus posibles conse- cuencias-negativos. La ms probable que el
resultado es, peor es el riesgo. Sin embargo, likeli-campana no es la nica consideracin.

Por ejemplo, la mayora de la gente tiende a coger un resfriado en el curso de sus vidas, por lo general
ms de una vez. El individuo tpico sana no sufre consecuencias graves. Por lo tanto, el nivel general de
riesgo asociado con los resfriados es baja para esta persona. Pero el riesgo de un resfriado para una
persona mayor con la respiracin difi-cultades sera alto. El impacto potenciales consecuencias o es una
consideracin importante que afecta el nivel de riesgo, tambin.

Recordemos que en el captulo 1 hemos discutido cmo el contexto del sistema, y espe-cialmente el
riesgo asociado con fallas, pruebas de influencias. A continuacin, vamos a entrar en ms detalles sobre el
concepto de riesgos, cmo influyen en las pruebas, y las formas especficas para el manejo de riesgos.

Podemos clasificar los riesgos en los riesgos del proyecto (factores relacionados con la forma en que el
trabajo se lleva a cabo, es decir, el proyecto de prueba) y riesgos de los productos (factores en relacin
con lo que se produce por el trabajo, es decir, lo que estamos probando). Vamos a ver riesgos de los
productos en primer lugar.

5.5.2 riesgos del producto

Se puede pensar en un riesgo del producto, la posibilidad de que el sistema o software podran no
satisfacer alguna razonable al cliente, usuario o grupos de inters Expecta-cin.(Algunos autores se
refieren a los "riesgos de los productos 'como' riesgos 'de calidad como son los riesgos para la calidad
del producto.) software insatisfactoria podra omitir algunos fun-cin clave que los clientes especifican,
los usuarios necesarios o las partes interesadas se les prometi. software insatisfactoria podra ser poco
fiable y con frecuencia dejar de comportarse normalmente. software insatisfactoria puede fallar en
formas que causan dao financiero o de otro tipo a un usuario o la empresa que trabaja para el usuario.
software insatisfactoria podra tener problemas relacionados con una caracterstica particular de la
calidad, que podra no ser la funcionalidad, sino ms bien la seguridad, fiabilidad, facilidad de uso,
principal-sosteni- o el rendimiento.

Las pruebas basadas en riesgo es la idea de que podemos organizar nuestros esfuerzos de pruebas en una
manera que reduce el nivel residual de riesgo del producto cuando los barcos del sistema.Las pruebas basadas
en el riesgo usa riesgo para priorizar y hacer hincapi en los ensayos adecuados durante la ejecucin de la
prueba, pero es algo ms que eso. Las pruebas basadas en el riesgo comienza al principio del proyecto,
identificando los riesgos para la calidad del sistema y el uso que el conocimiento de los riesgos para orientar la
planificacin de pruebas, especificacin, preparacin y ejecucin. Las pruebas basadas en el riesgo involucra
tanto a la mitigacin - pruebas para proporcionar oportunidades para reducir la probabilidad de defectos,
especialmente los defectos de alto impacto - y la contingencia - pruebas para identificar soluciones alternativas
para que los defectos que quedan ms all de nosotros menos doloroso. Las pruebas basadas en riesgo tambin
implica la medicin de lo bien que estamos haciendo en la bsqueda y eliminacin de defectos en reas
crticas, como se muestra en la Tabla 5.1. Las pruebas basadas en el riesgo tambin puede implicar el uso de
anlisis de riesgos para identificar oportunidades proactivas para eliminar o prevenir los defectos a travs de
actividades no son para pruebas y para ayudarnos a seleccionar las actividades de prueba a realizar.

organizaciones de pruebas maduros utilizan pruebas para reducir el riesgo asociado con deliv-Ering el software a
un nivel aceptable [Beizer, 1990], [Hetzel, 1988]. En el medio de la dcada de 1990, una serie de probadores,
incluyendo los Estados Unidos, comenz a explorar diversas tcnicas para el ensayo basado en el riesgo. Al hacerlo,
hemos adaptado los conceptos de gestin de riesgo bien aceptados para las pruebas de software. Aplicar y evaluar
las tcnicas de unificacin y de gestin de riesgos de refinacin se discuten en [Negro, 2001] y [Negro, 2004]. Por
dos puntos de vista alternativos, vase el captulo 11 de la [Pol et al., 2002] y en el Captulo 2 de [Craig, 2002].El
origen del concepto de pruebas basado en el riesgo se puede encontrar en el captulo 1 de [Beizer, 1990] y en el
Captulo 2 de [Hetzel, 1988].

Las pruebas basadas en el riesgo comienza con el anlisis de riesgos del producto. Una de las tcnicas para
el anlisis de riesgos es una lectura atenta de la especificacin de requisitos, ESPECIFICA-ciones de diseo,
documentacin del usuario y otros artculos. Otra tcnica es una lluvia de ideas con muchos de los interesados
en el proyecto. Otra es una secuencia de uno-a-uno o sesiones de grupos pequeos con los expertos en
negocios y tecnologa en la empresa. Algunas personas utilizan todas estas tcnicas cuando pueden. Para
nosotros, un enfoque basado en el equipo que involucra a los actores clave y expertos es preferible un enfoque
puramente basado en el documento, como el enfoque de equipo se basan en el conocimiento, la sabidura y la
visin de todo el equipo para determinar qu prueba y cunto.

Mientras que usted podra realizar el anlisis de riesgos con la pregunta "Qu debemos preocuparnos? ' por
lo general se requiere una mayor estructura de evitar las cosas que faltan. Una manera de proporcionar esa
estructura es la bsqueda de riesgos especficos en riesgo particular de producto CAT-ras. Se podra
considerar los riesgos en las reas de funcionalidad, la localizacin, la facilidad de uso, fiabilidad, rendimiento
y compatibilidad. Como alternativa, puede utilizar las caractersticas de calidad y sub-caractersticas de la
norma ISO 9126 (intro-ducido en el captulo 1), ya que cada sub-caracterstica que importa est sujeta a
riesgos que el sistema podra tener problemas en esa rea. Es posible que tenga una lista de control de los
riesgos tpicos o pasados que deben ser considerados. Tambin puede ser que desee revisar las pruebas que
fallaron y los errores que haya encontrado en una versin anterior o un producto similar. Estas listas y
reflexiones sirven para refrescar la memoria, lo que oblig a pensar en los riesgos de tipos particulares, as
como ayudar a estructurar el doc-documenta- de los riesgos de los productos.

Cuando hablamos de riesgos especficos, nos referimos a un tipo particular de defecto o falla que pudiera
ocurrir. Por ejemplo, si estuviera probando la utilidad de la calculadora que se incluye con Microsoft
Windows, es posible identificar 'incorrecta Calcula-cin' como un riesgo especfico dentro de la categora de
funcionalidad. Sin embargo, esto es demasiado

AmplioConsidere adems incorrecta. Se trata de una especie de alto impacto de los defectos, como todos
los que usan la calculadora lo ver. Es poco probable, ya que la adicin no es un algoritmo complejo.
Esto contrasta con un clculo incorrecto de seno. Este es un tipo de bajo impacto de defecto, ya que pocas
personas utilizan la funcin seno en la calculadora de Windows. Es ms probable que tenga un defecto,
sin embargo, ya func-ciones sinusoidales son difciles de calcular.
Despus de identificar los elementos de riesgo, usted y, en su caso, las partes interesadas, debe revisar
la lista para asignar la probabilidad de problemas y el impacto de los problemas asociados con cada uno.
Hay muchas maneras de ir sobre esta asignacin de probabilidad e impacto. Usted puede hacer esto con
todas las partes interesadas a la vez. Puede hacer que los hombres de negocios que determinan el impacto
y los tcnicos determinar la probabilidad, y luego fusionar las determinaciones. De cualquier manera, la
razn de la identificacin de riesgos primero y despus la evaluacin de su nivel, es que los riesgos son en
relacin con la otra.

Las escalas utilizadas para la probabilidad y el impacto tasa varan. Algunas personas les califica de
alta, media y baja. Algunos utilizan una escala de 1-10. El problema con una escala de 1-10 es que a

menudo es difcil diferenciar una 2 de un 3 o un 7 desde un 8, a menos que las diferencias entre cada
calificacin estn claramente definidos. Una escala de cinco puntos (muy alto, alto, medio, bajo y muy
bajo) tiende a funcionar bien.

Dados dos clasificaciones de niveles de riesgo, probabilidad e impacto, tenemos un problema, sin
embargo: Necesitamos una nica calificacin de riesgo, agregado para guiar nuestro esfuerzo de pruebas.
Al igual que con las escalas de calificacin, las prcticas varan. Un mtodo consiste en convertir cada
clasificacin de riesgo en un nmero y luego agregar o multiplicar los nmeros de cal-cular un nmero de
prioridad de riesgo.Por ejemplo, suponga un riesgo particular tiene una alta probabilidad de un impacto y
medio. El nmero de prioridad de riesgo sera entonces 6 (2 veces 3).

Armado con un nmero de prioridad de riesgo, ahora podemos decidir sobre las diversas opciones de
mitigacin de riesgos disponibles para nosotros. Utilizamos entrenamiento formal para los
programadores o analistas, se basan en el entrenamiento cruzado y crticas o asumen que saben lo
suficiente? Hacemos llevamos a cabo extensas pruebas, las pruebas superficial o ninguna prueba en
absoluto? Hay que garantizar la unidad de pruebas y la cobertura de las pruebas del sistema de este
riesgo? Estas opciones y ms estn disponibles para nosotros.

A medida que transcurre este proceso, asegrese de capturar la informacin clave en un documento. No somos
aficionados a la documentacin excesiva, pero esta cantidad de infor-macin simplemente no puede ser controlada
en su cabeza. Recomendamos una tabla de peso ligero como el que se muestra en la Tabla 5.2; por lo general
capturar esto en una hoja de clculo.

Vamos a terminar esta seccin con dos consejos rpidos sobre el anlisis de riesgo del producto. En primer lugar,
recuerde tener en cuenta tanto la probabilidad e impacto. Si bien puede hacer que se sienta como un hroe de
encontrar un montn de defectos, las pruebas tambin se trata de la construccin de la confianza en clave

FuncionesNecesitamos poner a prueba las cosas que probablemente no se rompen, pero sera
catastrfico si lo hicieron.

En segundo lugar, los anlisis de riesgo, especialmente los primeros, son educados conjeturas.
Asegrese de que usted sigue y vuelve a visitar el anlisis de riesgos en los hitos clave del proyecto. Por
ejemplo, si usted est siguiendo un modelo en V, es posible realizar el anlisis inicial durante la fase de
requisitos, a continuacin, examinar y revisar que al final de las fases de diseo e implementacin, as
como antes de iniciar prueba de unidad, prueba de integracin y prueba del sistema. Tambin le
recomendamos revisar el anlisis de riesgos durante la prueba. Usted puede encontrar que han descubierto
nuevos riesgos o encontrado que algunos riesgos no eran tan arriesgado como se pensaba y el aumento de
su con-confianza en el anlisis de riesgos.

5.5.3 Riesgos del proyecto

Acabamos de discutir el uso de pruebas para gestionar los riesgos para la calidad del producto. Sin
embargo, la prueba es una actividad como el resto del proyecto y por lo tanto est sujeta a riesgos que
ponen en peligro el proyecto. Para hacer frente a los riesgos de los proyectos que se aplican a las
pruebas, podemos utilizar los mismos conceptos que aplicamos a identificar, priorizar y gestionar los
riesgos de productos.

Recordando que un riesgo es la posibilidad de un resultado negativo, lo que los riesgos de proyectos
afectan a las pruebas? Existen riesgos directos tales como la demora en la entrega de los elementos de
prueba al equipo de pruebas o problemas de disponibilidad con el entorno de prueba. Tambin existen
riesgos indirectos, tales como retrasos excesivos en la reparacin de los defectos encontrados en las
pruebas o problemas con la obtencin de apoyo administracin del sistema profesional para el entorno de
prueba.

Por supuesto, estos no son ms que cuatro ejemplos de los riesgos del proyecto; muchos otros se
pueden aplicar a su esfuerzo de pruebas. Para descubrir estos riesgos, hgase y otros participantes en el
proyecto y las partes interesadas, "Qu podra ir mal en el proyecto de retrasar o invalidar el plan de
pruebas, la estrategia de prueba y la estimacin de prueba? Cules son los resultados inaceptables de
prueba o en pruebas? Cules son las probabilidades e impactos de cada uno de estos riesgos? Se puede
ver que este proceso es muy similar al proceso de anlisis de riesgos de los productos. Listas de control y
ejemplos pueden ayudar a identificar los riesgos del proyecto de prueba [Black, 2004].

Para cualquier riesgo, producto o proyecto, tiene cuatro opciones tpicas:

Mitigar: Tomar medidas con antelacin para reducir la probabilidad (y posiblemente el impacto)
del riesgo.
Contingencia: Tener un plan en marcha para reducir el impacto que ocurra el riesgo convertido en
un resultado.

 Transferencia: Convencer a algn otro miembro del equipo de proyecto o grupos de inters para
reducir la probabilidad o aceptar el impacto del riesgo.

Ignorar: No hacer nada acerca del riesgo, que suele ser una opcin inteligente slo cuando hay
poco que se pueda hacer o cuando la probabilidad y el impacto son bajos.

Hay otra opcin tpica de gestin de riesgos, la compra de un seguro, que no se ejercen habitualmente
por proyecto o producto riesgos en los proyectos de software, a pesar de que no es desconocida.

Aqu hay algunos riesgos tpicos, junto con algunas opciones para la gestin de los mismos.

Logstica o problemas de calidad del producto que bloquean pruebas: Estos pueden ser miti
cerrada mediante una planificacin cuidadosa, buena clasificacin y gestin de defectos, y diseo de
la prueba robusta.

Elementos de prueba que no se instalar en el entorno de prueba: Estos pueden ser mitigados a
travs del humo (o aceptacin) pruebas antes de iniciar las fases de prueba o como parte de una
acumulacin de la noche o de integracin continua.Tener un proceso de desinstalacin definido es un
buen plan de contingencia.

Una variacin excesiva al producto que invalida los resultados de pruebas o requiere cambios a los
casos de prueba, los resultados esperados y los entornos: Estos pueden ser mit igated travs de buenos
procesos de control de cambios, el diseo de pruebas robusta y documentacin de prueba de peso
ligero.Cuando se producen incidentes graves, la transferencia del riesgo por la progresividad de
gestin a menudo est en orden.

Entornos de pruebas insuficientes o poco realistas que dan resultados engaosos: Una opcin es transferir
los riesgos de gestin, explicando los lmites en los resultados de las pruebas obtenidos en entornos
limitados.Mitigacin - a veces com el alivio completa - se puede lograr mediante la subcontratacin de pruebas
tales como pruebas de rendimiento que son particularmente sensibles a los entornos de prueba apropiados.

Aqu hay algunos riesgos adicionales a tener en cuenta y tal vez para gestionar:

Las cuestiones de organizacin, como la escasez de personas, habilidades o entrenamiento,

problemas de comunicacin y responder a probar los resultados, malos taciones expec de lo que puede
lograr la prueba y la complejidad del equipo o de la organizacin del proyecto.

Problemas de los proveedores, como problemas con las plataformas subyacentes o hardware, la no
consideracin de las pruebas cuestiones en el contrato o la falta de respuesta adecuada a los problemas
que puedan surgir.

Los problemas tcnicos relacionados con los requisitos ambiguos, contradictorios o sin
prioridades, un nmero excesivamente grande de los requisitos que se indican otras restricciones del
proyecto, de alta complejidad del sistema y problemas de calidad con el diseo, el cdigo o las
pruebas.

Puede haber otros riesgos que se aplican a su proyecto y no todos los proyectos estn sujetos a los
mismos riesgos. Vase el Captulo 2 de [Negro, 2001], los captulos 6 y 7 de la [Negro, 2004] y en el
Captulo 3 de [Craig, 2002] para una discusin sobre la gestin de riesgos del proyecto durante la prueba
y en el plan de pruebas.

Por ltimo, no se olvide de que los elementos de prueba tambin puede tener riesgos asociados con ellos.
Por ejemplo, existe el riesgo de que el plan de pruebas omitir pruebas para un rea funcional o que los casos
de prueba no ejercen las reas crticas del sistema.

5.5.4 Atar todo junto para la gestin de riesgos

Podemos hacer frente a los riesgos relacionados con la prueba-en el proyecto y el producto mediante la aplicacin de
algunas tcnicas de gestin de riesgos sencillos, estructurados. El primer paso es evaluar o analizar los riesgos al
comienzo del proyecto. Al igual que un forro gran ocano, proyectos, proyectos espe-cialmente grande, manejo de la
direccin mucho antes del iceberg est a la vista. Mediante el uso de una plantilla de plan de pruebas como la
plantilla IEEE 829 se ha mostrado anteriormente, se puede recordar que debe considerar y gestionar los riesgos
durante la fase de planificacin.

Vale la pena repetir aqu que los anlisis de riesgo tempranos son conjeturas.Algunas de esas
conjeturas habr equivocado. Asegrese de que va a volver a evaluar y ajustar sus riesgos a intervalos
regulares en el proyecto y hacer correcciones adecuadas a la prueba o el propio proyecto.

las personas tienen un problema comn cuando las organizaciones adoptan primera prueba basado en
el riesgo es una tendencia a ser excesivamente alarmado por algunos de los riesgos una vez que se
articulan claramente. No se debe confundir con la probabilidad de impacto o viceversa. Debe administrar
los riesgos de manera apropiada, basada en probabilidad y el impacto. Triage los riesgos mediante la
comprensin de qu parte de su esfuerzo general puede ser dedicado a tratar con ellos.

Es muy importante mantener un sentido de perspectiva, un enfoque en el objetivo del ejercicio. Al

igual que con la vida, el objetivo de la prueba basado en el riesgo no debe ser - prcticamente no puede
ser - un proyecto libre de riesgo. Lo que podemos lograr con la prueba basado en el riesgo es el
matrimonio de las pruebas con las mejores prcticas en la gestin de riesgos para lograr un resultado del
proyecto que equilibra los riesgos con la calidad, caractersticas, presupuesto y el calendario.

17/1/200 8.1.3 Administracin de Incidentes

1 Reconocer el contenido del informe [IEEE 829] incidente.{0}k = 0.015 L{/0}

{1}1{/1}
2 Escribir un informe de incidente que cubre la observacin de un fallo durante
Pruebas (k)

Vamos a relajarse este captulo sobre gestin de pruebas con un tema importante: cmo podemos
documentar y gestionar las incidencias que se produzcan durante la prueba de ejecu-cin. Vamos a ver lo
que los temas que debemos cubrir al informar de los incidentes y defectos. Al final de esta seccin, usted
estar listo para escribir un informe de incidente a fondo.

Mantenga sus ojos abiertos para el nico trmino del programa de estudios en esta seccin, incidente

loguean

5.6.1 Cules son los informes de incidentes para y cmo se escriben los buenos?

Cuando se ejecuta una prueba, es posible observar que los resultados reales que varan de los esperados. Esto no es
algo malo - uno de los principales objetivos de las pruebas es encontrar prob-blemas. Diferentes organizaciones
tienen diferentes nombres para describir este tipo de situaciones. Comnmente, se llaman incidentes, errores,
defectos, problemas o cuestiones.

Para ser precisos, a veces hacer una distincin entre incidentes, por un lado y los defectos o errores en el
otro. Un incidente es cualquier situacin en la que el sistema muestra un comportamiento cuestionable, pero a
menudo nos referimos a un incidente como un defecto slo cuando la causa es algn problema en el tema que
estamos probando.

Otras causas de los incidentes incluyen una mala configuracin o el fracaso de la prueba ENVI-am-, los
datos de prueba corruptos, malos pruebas, los resultados esperados no vlidos y probador

Errores ...(Sin embargo, en algunos casos, la poltica es clasificar como un defecto cualquier-dent INCI que
surge a partir de un diseo de la prueba, el entorno de prueba o cualquier otra cosa que est bajo la
administracin de configuracin formal.) Hablamos de incidentes que indican la posibilidad de que un
comportamiento cuestionable no es necesariamente un defecto verdadero. Nos registrar estos incidentes para
que tengamos un registro de lo que hemos observado y puede repetir el incidente y realizar un seguimiento de
lo que se hace para corregirlo.

Si bien es ms comn encontrar el registro de incidentes o defecto procesos y herramientas en el uso

de informes durante las fases de pruebas formales, independientes, tambin se puede iniciar la sesin,
informe, seguimiento y gestionar incidencias encontradas durante el desarrollo y revisin.De hecho, esta
es una buena idea, ya que le da informacin til en la medida en que los principios - y ms barato - las
actividades de deteccin de defectos y eliminacin estn sucediendo.

Por supuesto, tambin necesitamos alguna forma de presentacin de informes, el seguimiento y la gestin de
INCI abolladuras que se producen en el campo o despus de la implementacin del sistema. Mientras que muchos
de estos incidentes se producen fallos humanos o algn otro comportamiento no relacionada con un defecto, un
porcentaje de defectos escapan del control de calidad y pruebas de activ-dades. El porcentaje de deteccin de

defectos, que compara los defectos del campo con defectos de prueba, es una medida importante de la eficacia del
proceso de prueba.

He aqu un ejemplo de una frmula DDP que se aplicara para el clculo de DDP para el ltimo nivel
de la prueba antes de su liberacin en el campo:

Defectos (testers)
DDP = ------------------------------------------------ ---------Defectos (testers) + defectos (de campo)

Es ms comn encontrar defectos notificados en contra del cdigo o del propio sistema. Sin embargo,
tambin hemos visto casos en que se describen los defectos en contra de los requisitos y especificaciones de
diseo, el usuario y las guas del operador y las pruebas. A menudo, ayuda a la eficacia y eficiencia de la
presentacin de informes, seguimiento y defectos manag-cin cuando la herramienta de seguimiento de
defectos proporciona una capacidad de variar alguna de la informacin capturada en funcin de lo que se
inform de que el defecto en contra.

En algunos proyectos, se encuentran un gran nmero de defectos. Incluso en proyectos ms pequeos

donde se encuentran 100 o menos defectos, se puede perder fcilmente un seguimiento de ellos a menos
que tenga un proceso para la presentacin de informes, clasificacin, asignacin y gestin de los defectos
del descubrimiento a la resolucin final.

Un informe de incidente contiene una descripcin de la mala conducta que fue observada y la
clasificacin de que la mala conducta. Al igual que con cualquier comuni-cacin por escrito, que ayuda a
tener objetivos claros en mente al escribir. Un objetivo comn para este tipo de informes es proporcionar
a los programadores, administradores y otros con informacin detallada sobre el comportamiento
observado y el defecto. Otra es la de apoyar el anlisis de las tendencias en los datos agregados de
defectos, ya sea para entender ms acerca de un conjunto particular de problemas o pruebas o para
comprender e informar el nivel global de la calidad del sistema. Por ltimo, informes de defectos, cuando
se analiz sobre un proyecto e incluso a travs de proyectos, dan informacin que puede dar lugar a
procesos de desarrollo y prueba de mejoras.

Al escribir un incidente, que ayuda a tener los lectores en mente, tambin. Los pro-programadores necesitan
la informacin de la memoria para encontrar y corregir los defectos. Antes de que suceda, sin embargo, los
gerentes deben revisar y dar prioridad a los defectos de forma que los desarrolladores de pruebas y los escasos
recursos se gastan de fijacin y la confirmacin de las pruebas de los defectos ms importantes. Debido a que
algunos defectos pueden ser diferidos - tal vez para ser fijado ms tarde o quizs, en ltima instancia, a no ser
fijo en todos - debemos incluir

soluciones temporales y otros datos tiles para el servicio de asistencia o equipos de apoyo tcnico.Por
ltimo, los probadores a menudo necesitan saber lo que sus colegas estn encontrando para que puedan
ver un comportamiento similar en otro lugar y evitar tratar de ejecutar las pruebas que sern bloqueados.

Un buen informe de incidente es un documento tcnico. Adems de ser claro para sus objetivos y la
audiencia, cualquier buen informe surge de un enfoque cuidadoso para investigar y escribir el informe.
Tenemos algunas reglas bsicas que pueden ayudarle a escribir un mejor informe de incidente.

En primer lugar, utilizar un enfoque cuidadoso, atento a la ejecucin de las pruebas. Nunca se sabe
cundo vas a encontrar un problema. Si usted est golpeando la llave de a bordo mientras charlando con
los compaeros de oficina o soando con una pelcula que acaba de ver, es posible que no se d cuenta
comportamientos extraos. Incluso si usted ve el incidente, cunto es lo que realmente sabe sobre l?
Qu se puede escribir en su informe de incidente?

sntomas intermitentes o espordicos son un hecho de la vida para algunos defectos y siempre
desalentador tener un informe de incidente se recuper como 'irrepro-ducible'. Por lo tanto, es una buena
idea para tratar de reproducir los sntomas cuando los vea y se han encontrado tres veces para ser una
buena regla del pulgar. Si un defecto tiene sntomas inter-mitente, todava tendramos que informar, pero
nos gustara estar seguro de incluir la mayor cantidad de informacin posible, sobre todo la cantidad de
veces que intentamos reproducir y el nmero de veces que de hecho ocurri.

Tambin debe tratar de aislar el defecto mediante cambios cuidadosamente elegidos a los pasos
utilizados para reproducirlo. Al aislar el defecto, usted ayuda a guiar el pro-gramtica a la parte
problemtica del sistema. Tambin aumentar su propio conocimiento de cmo funciona el sistema - y la
forma en que se produce un error.

Algunos casos de prueba se centran en las condiciones de contorno, que pueden hacer que parezca que un
defecto no es probable que suceda con frecuencia en la prctica. Hemos encontrado que es una buena idea
para buscar condiciones ms generalizadas que causan la falla que se produzca, en lugar de simplemente
confiar en el caso de prueba. Esto ayuda a prevenir el informe del incidente rplica Infa-mous, 'Ningn usuario
real est cada vez va a hacer eso. " Tambin reduce el nmero de informes duplicados que quedan archivados.

Como a menudo hay una gran cantidad de pruebas pasando con el sistema durante un perodo de
prueba, hay un montn de otros resultados de las pruebas disponibles. Comparacin de un problema
observado en contra de otros resultados de la prueba y los defectos conocidos encontrado es una buena
manera de encontrar y documentar la informacin adicional que el programador es probable encontrar
muy til. Por ejemplo, es posible comprobar si hay sntomas similares observados con otros defectos, el
mismo sntoma observado con defectos corregidos en versiones anteriores o resultados similares (o
diferentes) observada en los ensayos que cubren partes similares del sistema.

Muchos lectores de informes de incidentes, especialmente los administradores, tendrn que soportar
bajo la prioridad y la gravedad del defecto.Por lo tanto, el impacto del problema en los usuarios,
clientes y otras partes interesadas es importante. La mayora de los sistemas de seguimiento de defectos
tienen un campo de ttulo o resumen y ese campo deben mencionar el impacto, tambin.

Eleccin de las palabras, sin duda importa en los informes de incidentes. Debe ser clara e inequvoca.
Tambin debe ser neutral, hecho-centrado y impar-cial, teniendo en cuenta los problemas interpersonales
relacionados con las pruebas expuestas en el captulo 1 y al principio de este captulo. Por ltimo,
mantener el concisa informe ayuda a mantener la atencin de la gente y evita el problema de la prdida
de ellos en los detalles.

Como ltima regla de oro para los informes de incidentes, se recomienda que utilice un proceso de
revisin de todos los informes presentados.Funciona si tiene los informes de revisin probador de plomo
y tambin hemos permitido que los probadores - al menos los experimentados - para revisar los informes
de otros catadores. Los comentarios son probadas tcnicas de garanta de calidad y los informes de
incidentes son importantes prestaciones del proyecto.

5.6.2 Lo que va en un informe de incidente?

Un informe de incidente describe una situacin, comportamiento o acontecimiento que ocurri durante la
prueba que requiere una mayor investigacin. En muchos casos, un informe de incidente consiste en una
o dos pantallas - completos de la informacin recogida por una herramienta de seguimiento de defectos y
se almacena en una base de datos.

Como se mencion anteriormente, a menudo se documenta la informacin narrativa como el resumen, los
pasos para reproducir, las etapas de aislamiento probados y el impacto del problema. Estos campos deben
mencionar las entradas dadas y salidas observadas, la discrepancia o la varianza de las expectativas, las
diferentes formas en que podra - y no pudo - hacer que el problema reaparezca y el impacto. Clasificacin
informa-cin que un aparato proporcionara incluye la fecha y hora de la falla, en qu fase del proyecto se
encuentra en el fracaso, el caso de prueba que produjo el incidente, las referencias a las especificaciones u
otros documentos que proporcionan informa-cin sobre la correcta comportamiento, el nombre del probador (y
tal vez el revisor), el entorno de prueba y cualquier informacin adicional acerca de la configuracin del
software, sistema o medio ambiente. A veces probadores clasifican el alcance, la gravedad y la prioridad del
defecto, aunque a veces los gerentes o un comit de triaje error manejan ese papel.

A medida que el incidente se logr la resolucin, los administradores pueden asignar un nivel de
prioridad a la informacin. El comit de triaje tablero de control de cambios o fallo podra documentar los
riesgos, costos, oportunidades y beneficios asociados a la fijacin o que no se fija el defecto. El

programador, al fijar el defecto, puede capturar la causa raz, la fase de introduccin y la fase de
extraccin.

Despus de que el defecto haya sido resuelto, gestores, programadores o otros pueden querer capturar
conclusiones y recomendaciones. A lo largo del ciclo de vida de la notificacin de incidentes, desde el
descubrimiento de la resolucin, el sistema de seguimiento de defectos debe permitir que cada persona
que trabaja en el informe de incidente para entrar informacin de estado y la historia.

IEEE 829 STANDARD:

PRUEBA DE PLANTILLA DE INFORME DE INCIDENTE

Prueba incidente informe identificador Resumen

Descripcin incidente (insumos, resultados esperados, los
resultados reales, anomalas, fecha y hora, paso del procedimiento,
el medio ambiente, intenta repetir, probadores y observadores)

##Impacto

5.6.3 Qu ocurre con los informes de incidentes despus de que les presenta?

Como mencionamos anteriormente, los informes de incidentes se gestionan a travs de un ciclo de vida,
desde el descubrimiento de la resolucin. El ciclo de vida de notificacin de incidentes a menudo se
muestra como un diagrama de transicin de estado (vase la Figura 5.3). Mientras que el sistema de
seguimiento de defectos puede utilizar un ciclo de vida diferente, vamos a tomar ste como un ejemplo
para ilustrar cmo un ciclo de vida de notificacin de incidentes podra funcionar.

En el ciclo de vida de notificacin de incidentes se muestra en la Figura 5.3, todos los informes de incidentes
se mueven a travs de una serie de estados claramente identificados despus de haber sido informado. Algunas
de estas transiciones de estado se producen cuando un miembro del equipo del proyecto se completa una tarea
asignada en relacin con el cierre de un informe de incidente. Algunos de estos TRANSI-ciones estatales se
producen cuando el equipo del proyecto decide no reparar un defecto durante este proyecto, que lleva al

aplazamiento del informe del incidente. Algunos de estos tran-siciones de estado se producen cuando un
informe de incidente est mal escrito o describe el comportamiento que es realmente correcto, lo que lleva al
rechazo de ese informe.

Vamos a centrarnos en el camino tomado por los informes de incidentes que finalmente son corregidos.
Despus de que se inform de un incidente, un probador de compaeros o director de pruebas revisa el
informe. Si tiene xito en el examen, el informe del incidente se convierte en abierto, por lo que ahora el
equipo del proyecto debe decidir si o no para reparar el defecto. Si el defecto es para ser reparado, se le
asigna a un programador para repararlo.

Una vez que el programador cree que las reparaciones se han completado, el informe del incidente vuelve al
probador para las pruebas de confirmacin. Si la prueba de confirmacin falla, el informe de incidente se
vuelve a abrir y volver a asignar. Una vez que el probador confirma una buena reparacin, el informe de
incidente est cerrado. No queda ms trabajo por hacer.

En cualquier estado que no sea rechazada, difiere o se cierra, es necesario seguir trabajando sobre el
incidente antes de la finalizacin de este proyecto. En tal estado, el informe del incidente tiene un
propietario identificado claramente. El propietario es responsable de la transicin del incidente en un
estado posterior permitido. Las flechas en el diagrama muestran estas transiciones permitidas.

En un estado rechazado, diferido o cerrado, no se asignar el informe del incidente a un propietario.Sin

embargo, ciertos acontecimientos del mundo real pueden causar un informe de incidente para cambiar el
estado, incluso si no hay trabajo activo est ocurriendo en el informe del incidente. Los ejemplos incluyen
la recurrencia de un fallo asociado con un informe de incidente cerrado y el descubrimiento de un fallo de
ms grave asociado con un informe de incidente diferido.

Lo ideal sera que slo el propietario puede pasar el informe del incidente desde el estado actual al
estado siguiente y lo ideal es el propietario slo puede pasar el informe del incidente a un estado prximo
permitido. La mayora de los sistemas de seguimiento de defectos apoyan y hacen cumplir las normas de
ciclo de ciclo de vida y de la vida. Los buenos sistemas de seguimiento de defectos le permiten
personalizar el conjunto de estados, los propietarios, y las transiciones permitidas para que coincida con
los flujos de trabajo reales. Y, mientras que un buen sistema de seguimiento de defectos es muy til, el
flujo de trabajo defecto real debe ser supervisado y apoyado por proyecto y direccin de la empresa.

Repaso Captulo

Vamos a repasar lo que ha aprendido en este captulo.

De la Seccin 5.1, ahora debera ser capaz de explicar las ideas bsicas de la organizacin de
pruebas. Usted debe saber qu pruebas independientes es importante, sino tambin ser capaz de
analizar las ventajas y los problemas asociados con los equipos de pruebas independientes
potenciales. Debe reconocer los tipos de personas y habilidades necesarias en un equipo de
prueba y recordar las tareas que un aparato y un lder de la prueba llevarn a cabo. Usted debe
saber el probador trminos del glosario, supervisor de la prueba y la prueba gerente.

De la Seccin 5.2, ahora debera comprender los fundamentos de la planificacin de las

pruebas y la estimacin. Usted debe saber las razones de los planes de prueba por escrito y ser
capaz de explicar cmo los planes de prueba se refieren a los proyectos, los niveles de prueba o
fases, objetivos de prueba y ejecucin de la prueba. Usted debe saber qu partes del proceso de
prueba requieren una atencin especial en la planificacin de las pruebas. Usted debe ser capaz
de explicar la justificacin detrs de varios criterios de entrada y de salida que podran estar
relacionados con los proyectos, niveles o fases de prueba y los objetivos de la prueba. Usted debe
ser capaz de distinguir el propsito y el contenido de los planes de prueba en sus especificaciones
de diseo, casos de prueba y procedimientos de prueba, y conocer el esquema IEEE 829 para un
plan de pruebas. Usted debe conocer los factores que afectan el esfuerzo de las pruebas,
incluyendo especialmente las estrategias de prueba (enfoques) y cmo afectan a la prueba. Usted
debe ser capaz de explicar cmo se utilizan mtricas, la experiencia y la negociacin para la
estimacin. Usted debe conocer los criterios de entrada del glosario de trminos, salida
criterios, pruebas exploratorias, enfoque de la prueba, la prueba de nivel, planes de
prueba, el procedimiento de prueba y estrategia de prueba.

De la Seccin 5.3, usted debe ser capaz de explicar los fundamentos de la prueba de
seguimiento y control progreso. Usted debe conocer los sistemas de medicin comunes que son
capturados, guardados y usados para el monitoreo, as como formas de presentar estas mtricas.
Usted debe ser capaz de analizar, interpretar y explicar las mtricas de prueba que pueden ser
tiles para informar sobre el estado de prueba y para la toma de decisiones sobre cmo controlar
el progreso de prueba. Usted debe ser capaz de explicar un informe provisional de situacin
tpica y conocer el informe de resumen de la prueba IEEE 829 y el registro de la prueba. Usted
debe conocer los trminos del glosario densidad de defectos, las tasas de fracaso, de control
de prueba, prueba la cobertura, la supervisin de prueba y el informe de prueba.

De la Seccin 5.4, que ahora debe entender los conceptos bsicos de gestin de la
configuracin que se relacionan con las pruebas. Usted debe ser capaz de resumir lo bueno de
gestin de configuracin nos ayuda a hacer nuestro trabajo de pruebas mejor. Usted debe saber el
control de gestin de la configuracin y la versin trminos del glosario.

De la Seccin 5.5, ahora debera ser capaz de explicar cmo el riesgo y las pruebas se
relacionan. Usted debe saber que el riesgo de un potencial efecto negativo o indeseable y que la
mayor parte de los riesgos que nos interesan se relacionan con el logro de los objetivos del
proyecto. Usted debe saber sobre probabilidad y el impacto que los factores que determinan la
importancia de un riesgo. Usted debe ser capaz de comparar y contrastar los riesgos para el
producto (y su calidad) y los riesgos para el propio proyecto y conocer los riesgos tpicos para el
producto y el proyecto. Usted debe ser capaz de describir cmo utilizar el anlisis de riesgos y
gestin de riesgos para la prueba y planificacin de las pruebas. Usted debe saber el riesgo
trminos del glosario de productos, el riesgo del proyecto, el riesgo y las pruebas basadas en
riesgos.

De la Seccin 5.6, usted debe entender ahora el registro de incidentes y ser capaz de utilizar la
gestin de incidencias en sus proyectos. Usted debe conocer el contenido de un informe de
incidente de acuerdo con el estndar IEEE 829. Usted debe ser capaz de escribir un informe de
alta calidad basado en los resultados de pruebas y gestionar dicho informe a travs de su ciclo de
vida. Usted debe saber el registro de incidentes trmino del glosario.

PREGUNTAS examen de la muestra

Pregunta 1 Por qu es importante la prueba independiente?

a. Las pruebas independientes es generalmente ms barato que las pruebas de su propio

trabajo.
b. Las pruebas independientes es ms eficaz en la bsqueda de defectos.

c. probadores independientes deben determinar los procesos y las metodologas utilizadas.

d. probadores independientes son desapasionado acerca de si el proyecto tiene xito o fracasa.

Pregunta 2 Cul de las siguientes es una de las tareas tpicas de un lder de la prueba?

a. Desarrollar los requisitos del sistema, especificaciones de diseo y modelos de uso.

b.

Manejar todas las funciones de automatizacin de pruebas.

c. Mantener pruebas y cobertura de las pruebas ocultas a los programadores.

d.

Reunir y presentar las mtricas de progreso de la prueba.

Pregunta 3 Segn el Glosario ISTQB, qu queremos decir cuando llamamos a alguien un director de
pruebas?

a.

Un director de pruebas gestiona una coleccin de lderes de la prueba.

b.

Un director de pruebas es el lder de un equipo de prueba o equipos.

c.

Un director de pruebas se le paga ms de un lder de la prueba.

d.

Un gerente prueba de informes a un lder de la prueba.

Pregunta 4 Cul es la principal diferencia entre el plan de pruebas, la especificacin de diseo de la prueba y el
procedimiento de ensayo?

a. El plan de ensayo describe uno o ms niveles de las pruebas, las especificaciones de diseo
prueba identifica los casos de prueba de nivel alto y un procedimiento de ensayo describe las
acciones para la ejecucin de una prueba.

b. El plan de pruebas es para los administradores, la especificacin de diseo de la prueba es

para los programadores y del procedimiento de ensayo es para probadores que estn
automatizando las pruebas.

c.

El plan de pruebas es la menos profunda, del procedimiento de ensayo es la ms completa y la

especificacin de diseo de la prueba est a medio camino entre los dos.

d. El plan de pruebas se termin en el primer tercio del proyecto, la especificacin de diseo de la

prueba se termina en el tercio medio del proyecto y del procedimiento de ensayo se termin en el
ltimo tercio del proyecto.

Pregunta 5 Cul de los siguientes factores es una influencia en la prueba de esfuerzo involucrado en
la mayora de los proyectos?

a. La separacin geogrfica de probador y programadores.

b. La salida del director de pruebas durante el proyecto.

c. La calidad de la informacin utilizada para desarrollar las pruebas.
d. enfermedad inesperada a largo plazo por un miembro del equipo del proyecto.

Pregunta 6 La Fundacin ISTQB Plan establece un proceso de prueba fundamental en la planificacin de pruebas se
produce al principio del proyecto, mientras que la ejecucin de pruebas se produce al final. Cul de los siguientes
elementos del plan de pruebas, mientras que se especifique durante la planificacin de las pruebas, se evala
durante la ejecucin de la prueba?

a.

Tareas de las Pruebas

b.

Necesidades del ambiente

c.

Criterio de salida

d.

entrenamiento del equipo de prueba

Pregunta 7 Tenga en cuenta los siguientes criterios de salida que podran encontrarse en un plan de
pruebas:
I No se conocen los defectos de los clientes crtico.

II Todas las interfaces entre los componentes probados. III 100% de cobertura de cdigo de todas las
unidades.

IVAll especifica los requisitos satisfechos.

V funcionalidad del sistema coincide con el sistema legado para todas las reglas de negocio.

Cul de las siguientes afirmaciones es verdadera acerca de si estos criterios de salida pertenecen en un
plan de pruebas de aceptacin?

a.

Todas las declaraciones pertenecen en un plan de pruebas de aceptacin.

b. Slo comunicado que pertenece en un plan de pruebas de aceptacin.

c. Slo los nmeros I, II y V pertenecen en un plan de pruebas de aceptacin.

d. Slo los nmeros I, IV, V y pertenecen en un plan de pruebas de aceptacin.

Pregunta 8 Segn el Glosario ISTQB, lo que es un nivel de prueba?

a. Un grupo de actividades de prueba que se organizan en conjunto.

b. Una o ms de las pruebas documentos de especificaciones de diseo.

c.

Un tipo de prueba.

d.

Una certificacin ISTQB.

Pregunta 9 Cul de las siguientes mediciones que sera ms til para monitorizar durante la ejecucin de la
prueba?

a.

Porcentaje de casos de prueba escrita.

b. Nmero de entornos de prueba restantes a configurar.

c.

Nmero de defectos encontrados y fijos.

d. Porcentaje de requisitos para los que una prueba ha sido escrito.

Pregunta 10 Durante la ejecucin de pruebas, el gerente de ensayo describe la siguiente situacin al equipo
del proyecto: '90% de los casos de prueba se han ejecutado. 20% de los casos de prueba han identificado los
defectos. Se han encontrado 127 defectos. 112 defectos han sido corregidos y han superado las pruebas de
confirmacin. De los 15 restantes defectos, gestin de proyectos ha decidido que no necesitan ser fijados
antes de su liberacin. " Cul de las siguientes es la interpretacin ms razonable de este informe provisional
de situacin?

a.

Los restantes 15 defectos deben ser probados de confirmacin antes de su liberacin.

b. El 10% restante de los casos de prueba se debe ejecutar antes de su liberacin.

c.

Ahora el sistema est listo para el lanzamiento sin esfuerzo de pruebas o desarrollo adicional.

d.

Los programadores deben centrar su atencin en la fijacin de los defectos conocidos que quedan antes de su
liberacin.

Pregunta 11 En un informe resumen de ensayo, prueba de lder del proyecto hace la siguiente declaracin: "El
subsistema de procesamiento de pagos no puede aceptar pagos de los titulares de tarjetas American Express,
que se considera una caracterstica indispensable de trabajo para esta versin. ' Esta declaracin es probable
que se encuentre en cul de las siguientes secciones?

a.

Evaluacin

b.

Resumen de las actividades

c.

varianzas

d.

Descripcin incidente

Pregunta 12 Durante un perodo temprano de la ejecucin de la prueba, un defecto se encuentra, resuelto

y confirm lo resuelto por la re-pruebas, pero se ve de nuevo ms tarde durante la ejecucin de la prueba
posterior. Cul de los siguientes es un aspecto relacionados con las pruebas de gestin de la
configuracin que es ms probable que se han roto?

a.

trazabilidad

b.

(pruebas de confirmacin)

c.

CONFIGURACIN, CONTROL

d.

gestin de documentacin de prueba

Pregunta 13 Est trabajando como probador en un proyecto para desarrollar un sistema de punto deventa para tiendas de comestibles y otros puntos de venta similares. Cul de los siguientes es un riesgo
producto para un proyecto as?

a.

La llegada de un producto competidor ms confiable en el mercado.

b. Entrega de una versin de prueba incompleta al primer ciclo de prueba del sistema.

c. Un excesivamente alto nmero de soluciones a anomalas fallar durante repeticin de pruebas.

d.

Si no se acepta tarjetas de crdito permitidas.

Pregunta 14 Una reunin de anlisis de riesgo del producto se lleva a cabo durante el perodo de
planificacin del proyecto. Cul de las siguientes determina el nivel de riesgo?

a.

Dificultad de la solucin de problemas relacionados con el cdigo

b.

El dao que podra causar al usuario

c.

El precio por el que se vende el software

d.

El personal tcnico de la reunin

La pregunta 15 que est escribiendo un plan de pruebas usando la plantilla IEEE 829 y actualmente estn
completando los riesgos y contingencias seccin. Cul de los siguientes es ms probable que se enumeran como un
riesgo del proyecto?

a.

enfermedad inesperada de un miembro clave del equipo

b.

el tiempo de proceso de transacciones excesivamente lento

c.

corrupcin de los datos en virtud de congestin de la red

d.

El fracaso para tratar un caso clave de uso

Pregunta 16 Usted y los interesados en el proyecto de elaborar una lista de los riesgos de producto y
los riesgos del proyecto durante la fase de planificacin de un proyecto. Qu ms debe hacer con esas
listas de los riesgos durante la planificacin de las pruebas?

a.

Determinar el alcance de las pruebas requeridas por los riesgos producto y las medidas de mitigacin y
contingencia necesarios para los riesgos del proyecto.

b. Obtener los recursos necesarios para cubrir completamente cada riesgo del producto con pruebas
y transferir la responsabilidad de los riesgos del proyecto al director del proyecto.

c. Ejecutar pruebas suficientes para los riesgos de los productos, en base a la probabilidad y el
impacto de cada riesgo del producto y ejecutar acciones de mitigacin para todos los riesgos
del proyecto.

d. No se requiere ninguna accin adicional de gestin de riesgos en la etapa de planificacin de

las pruebas.

Pregunta 17 Segn el Glosario ISTQB, un riesgo del producto se relaciona con cul de las siguientes?

a.

El control del proyecto de prueba

b.

El objeto de prueba

c.

Un elemento de una sola prueba

d.

Un posible resultado negativo

Pregunta 18 En un informe de incidente, el probador hace la siguiente declaracin, En este punto, espero
recibir un mensaje de error que explica el rechazo de esta entrada invlida y me pide que introduzca una
entrada vlida. En cambio, el sistema acepta la entrada, muestra un reloj de arena entre uno y cinco segundos
y, finalmente, termina de forma anormal,

dando el mensaje, "inesperado tipo de datos: 15. Haz click para continuar." 'Esta declaracin es probable
que se encuentre en cul de las siguientes secciones de un informe de incidente 829 estndar IEEE?

a.

Resmen

b.

##Impacto

c.

Criterios de Elementos Aprobados/Fallidos

d.

Descripcin incidente

Pregunta 19 Segn el Glosario ISTQB, qu es lo que llamamos un documento que describe cualquier
evento que ocurri durante la prueba que requiere una mayor investigacin?

a.

Un informe de error

b.

Un informe de defectos

c.

Un informe de incidente

d.

Un informe resumen de la prueba

Pregunta 20 Un anlisis de riesgo del producto se lleva a cabo durante la fase de planificacin del proceso de
prueba. Durante la fase de ejecucin del proceso de prueba, el director de pruebas dirige los probadores para
clasificar cada informe de defectos por el riesgo de un producto conocido que se refiere a (o al "otro"). Una vez a la
semana, el director de pruebas se ejecuta un informe que muestra el porcentaje de defectos relacionados con cada
producto riesgo conocidos y desconocidos a los riesgos. Cul es una posible utilizacin de dicho informe?

a.

Para identificar nuevos riesgos para la calidad del sistema.

b.

Para localizar las agrupaciones de defectos en los subsistemas de productos.

c.

Para comprobar la cobertura de riesgos por medio de pruebas.

d.

Para medir pruebas exploratorias.

EJERCICIO: INFORME DE INCIDENTES

Remitirse a la direccin de correo utilizado como un ejercicio en el Captulo 1. Utilice la plantilla para
transformar incidente que el correo electrnico en un defecto informe bien escrito. Asegrese de tomar en
cuenta y resolver algunos de los problemas con el correo electrnico. Sintase libre de utilizar su
imaginacin para crear los detalles adicionales que pueda necesitar para un buen informe de defectos.

SOLUCIN DE EJERCICIO

Este es un posible defecto informe derivado de la direccin de correo. Tenga en cuenta que se ha evitado
la repeticin y el lenguaje emotivo. Nos hemos asegurado de incluir suficientes pruebas y los pasos para
reproducir el problema.

nmero de reporte de
fallos

Project number =
210698

fase de prueba

informes
relacionados

TP

ANB10

Prueba del sistema

AB

TP

Descripcin breve Los entornos de cliente no estn claramente identificados en pantalla para el usuario y el
mtodo de iniciar sesin en un entorno de cliente permite a los entornos de prueba y produccin deben
confundirse.Esto significa que si mis-clic en un archivo .bat cuando se ejecuta el cliente, puede abrir el cliente
equivocado y no se dan cuenta.

Evaluacin de impacto

Prioridad baja a mediana

(No detener procedimiento de

prueba)

Muy alta severidad

(Podra afectar los negocios

de los usuarios)

Descripcin detallada Los entornos de cliente no estn claramente identificados en pantalla para el usuario y el
mtodo de iniciar sesin en un entorno de cliente permite a los entornos de prueba y produccin deben
confundirse.Esto significa que si mis-clic en un archivo .bat cuando se ejecuta el cliente, puede abrir el cliente
equivocado y no se dan cuenta.

Este es un problema que resuelve si hara pruebas realizadas dentro de las reas de desarrollo y prueba
sistema ms eficiente y tambin es importante para la comunidad de usuarios.
Este problema surgir para los usuarios de dos maneras:

Llevan a cabo UAT en sus propias mquinas y por lo tanto los datos de prueba, as como los
clientes en vivo estn disponibles en sus listas y puede mis-seleccione el cliente, ya sea en la
realizacin de las pruebas (y sin querer probar en el sistema en vivo) o pueden misin seleccionar el
sistema de prueba cuando el comercio (piensan que han negociado cuando no tienen o plantean
cuestiones de mesa de ayuda si creen que sea un problema del sistema).

Llevan a cabo el trabajo en diferentes pases / mercados y necesitan saber que estn operando
en.Las medidas tomadas por el probador:

Tenemos dos entornos de prueba llamados Systest14 y Systesti 5 y mis pruebas se establecieron en
systest 15.

Para ejecutar los clientes, tenemos que ejecutar un archivo .bat, ya sea para un cliente de 14 o 15.

Yo haba comenzado dos clientes, es decir, dos participantes en el intercambio, por lo que poda
hacer algo de comercio entre ellos.

Parece que empec el primer cliente en el entorno de 15, pero cuando empec el segundo error,
he movido el ratn una fraccin por lo que corri el archivo .bat 14 que est junto a l en la lista de
archivos del Explorador.
Las pantallas de los clientes no muestran el entorno al que est conectado y por lo que trataron de proceder con las
pruebas que haba planeado y no pudieron obtener los resultados que esperaba. Despus de algunas investigaciones me
di cuenta de que haba cometido un error en la prueba de puesta a punto seleccionando el cliente equivocado. Qu hizo
que mi error y podra prevenirse? Mientras que en el lado del servidor de conexin a la comunicacin a un entorno de
prueba, el nombre del entorno debe escribirse y se muestra en todos los paneles, el inicio de sesin para el lado del
cliente se realiza mediante la seleccin de un archivo .bat de una lista de muchos nombre similar archivos. No hay ni una
exhibicin ni la capacidad de determinar el entorno de cliente en el que se est trabajando.

Un problema relacionado (TP1034 / 2) se ha aumentado con respecto al pas por defecto / mercado, que no se
muestra en la pantalla y puede ser mis-seleccionados. Proporcionar una pantalla de inicio de sesin para el
cliente y que muestra el cliente seleccionado en la pantalla impedira estos dos errores de usuario.

Aunque esto no es un problema funcionalidad y es causada por un error de usuario, que es un error fcil de
hacer y podra tener un gran impacto. En trminos de la vida real que significa que un usuario real podra estar
conectado al sistema de produccin y creo que l o ella est conectado a un sistema de prueba y por lo tanto
hacer que las operaciones irregulares o ilegales. Esto ha sucedido una vez en el sistema de comercio de acciones
de produccin, cuando un operador introduce una carga de transacciones de prueba en el sistema de produccin
por error y caus considerables problemas (ver informe de incidente en vivo A1204 / 23b). Necesitamos, por tanto,
para evitar que esto ocurra en este sistema.

Impacto en las pruebas

Pasaron 15 horas-hombre para investigar y comprender la causa raz.

La evidencia adjunta

Las capturas de pantalla de los entornos de servidor y cliente 14 y 15

Las capturas de pantalla de entornos reales equivalentes

Las capturas de pantalla del problema de eleccin pas

Estadsticas de tiempo de recuperacin para este problema, el problema valor predeterminado de

pas / mercado y el problema del sistema de capital a que se refiere.

Captulo Seis.

Herramienta de apoyo para las

pruebas

sted puede desear que tenas una herramienta mgica que automatizar todos la prueba para usted.Si es
as, usted se sentir decepcionado. Sin embargo, hay una serie de herramientas muy tiles que puedan aportar
ventajas significativas. En este captulo veremos que hay un apoyo para la herramienta de muchos aspectos
diferentes de pruebas de software. Veremos que el xito con herramientas no est garantizada, incluso si una
herramienta apropiada se adquiere - tambin hay riesgos en el uso de herramientas. Hay algunas
consideraciones especiales que se mencionan en el programa de estudios para ciertos tipos de herramientas:
herramientas de ejecucin de pruebas, herramientas de pruebas de rendimiento, herramientas de anlisis
esttico y

Herramientas de gestin de pruebas

6.1 Tipos de herramienta de prueba

1 Clasificar los diferentes tipos de herramientas de prueba de acuerdo con la

activi proceso de prueba

Lazos (k)

2 Reconocer las herramientas que pueden ayudar a los desarrolladores en sus

pruebas.{0}k = 0.015 L{/0}{1}1{/1}

En esta seccin, vamos a describir los diferentes tipos de herramientas en trminos de su funcionalidad
general, en lugar de entrar en muchos detalles. La razn de esto es que, en general, los tipos de
herramienta ser bastante estable durante un perodo ms largo, a pesar de que no habr nuevos
proveedores en el mercado, herramientas nuevas y mejoradas, e incluso nuevos tipos de herramienta en
los prximos aos.

No mencionaremos las herramientas comerciales en este captulo. Si lo hemos hecho, este libro saldra
muy rpidamente! proveedores de herramientas son adquiridos por otros proveedores, cambiar sus
nombres, y cambiar los nombres de las herramientas con bastante frecuencia, por lo que no van a
mencionar los nombres de herramientas o vendedores.

6.1.1 Prueba de clasificacin de herramientas

Las herramientas se agrupan por las actividades de ensayo o reas que son compatibles con un conjunto
de herramientas, por ejemplo, herramientas que apoyan las actividades de gestin, herramientas de apoyo
a pruebas estticas, etc.

No hay necesariamente un uno-a-uno entre un tipo de herramienta se describe aqu y una herramienta
ofrecido por un proveedor herramienta comercial o un abierto

herramienta de cdigo.Algunas herramientas realizan una funcin muy especfica y limitada (a veces llamada
"solucin de punto '), pero muchas de las herramientas comerciales proporcionan soporte para una serie de
funciones diferentes conjuntos de herramientas (o familias de herramientas). Por ejemplo, una herramienta de

'gestin de pruebas' puede proporcionar apoyo para la gestin de las pruebas (monitoreo del progreso), gestin
de la configuracin de testware, gestin de incidencias y gestin de requisitos y trazabilidad; otra herramienta
puede proporcionar tanto la medicin de cobertura y apoyo diseo de la prueba.

Hay algunas cosas que la gente puede hacer mucho mejor o ms fcil que un com-ordenador puede
hacer. Por ejemplo, cuando ves a un amigo en un lugar inesperado, por ejemplo en un aeropuerto, se
puede reconocer de inmediato su rostro. Este es un ejemplo de reconocimiento de patrones que las
personas son muy buenos, pero no es fcil de escribir suave-ware que puede reconocer una cara.

Hay otras cosas que las computadoras pueden hacer mucho mejor o ms rpido de lo que la gente
puede hacer. Por ejemplo, se puede aadir hasta 20 nmeros de tres dgitos rpidamente? Esto no es fcil
para la mayora de la gente a hacer, por lo que es probable que hacer algunos errores, incluso si los
nmeros estn escritos. Una computadora hace esto con precisin y muy rpidamente. Como otro
ejemplo, si las personas se les pide hacer exactamente la misma tarea una y otra vez, pronto se aburren y
luego comienzan a cometer errores.

El punto es que es una buena idea utilizar las computadoras para hacer cosas que comput-res son realmente
buenos y que las personas no son muy buenos. As soporte de la herramienta es muy til para las tareas
repetitivas - el equipo no se aburre y ser capaz de repetir exactamente lo que se hizo antes. Debido a que la
herramienta sea rpido, esto puede hacer que esas actividades mucho ms eficiente y ms fiable. Las
herramientas tambin pueden hacer cosas que pueden saturar una persona, tales como la comparacin de los
contenidos de un fichero de datos de gran tamao o la simulacin de cmo se comportara el sistema.

Una herramienta que mide algn aspecto de software puede tener efectos secundarios inesperados en el
software. Por ejemplo, una herramienta que mide los tiempos para las pruebas no funcionales
(rendimiento) necesita interactuar muy de cerca con ese software con el fin de medirlo. Una herramienta
de rendimiento establecer un tiempo de inicio y un tiempo de parada para una transaccin dada con el fin
de medir el tiempo de respuesta, por ejemplo. Pero el acto de tomar esa medida, es decir, almacenar el
tiempo en esos dos puntos, en realidad podra hacer toda la operacin tardar un poco ms de lo que hara
si la herramienta no estaba midiendo el tiempo de respuesta. Por supuesto, el tiempo extra es muy
pequeo, pero todava est all. Este efecto se llama el "efecto de sondeo '.

Otro ejemplo del efecto de la sonda se produce con las herramientas de cobertura. Con el fin de medir la
cobertura, la herramienta debe primero identificar todos los elementos estructurales que puedan ser ejercidos
para ver si una prueba ejerce o no. Esto se conoce como "instrumento-Menting el cdigo '. Las pruebas se
ejecutan a continuacin, a travs del cdigo instrumentado para que la herramienta puede decir (a travs de la
instrumentacin) si es o no una rama determinada (por ejemplo) se ha ejercido. Pero el cdigo instrumentado
no es el mismo que el cdigo real - tambin incluye el cdigo de instrumentacin. En teora, el cdigo es el
mismo, pero en la prctica, no lo es. Debido a que diferentes herramientas de cobertura funcionan de manera
ligeramente diferente, es posible obtener una medida de la cobertura ligeramente diferente en el mismo
programa, debido al efecto de la sonda. Por ejemplo diferentes herramientas pueden cuentan sucursales en
diferentes formas, por lo que el porcentaje de cobertura sera com-comparacin con un nmero total de

diferentes ramas. El tiempo de respuesta del cdigo instru-mentado tambin puede ser significativamente peor
que el cdigo sin instrumentacin. (Tambin hay herramientas de cobertura no intrusivos que observan la

bloques de memoria que contienen el cdigo objeto para obtener una medida aproximada sin
instrumentacin, por ejemplo, para el software embebido.)
Un ejemplo adicional del efecto de sondeo es una herramienta de depuracin cuando se utiliza para
tratar de encontrar un defecto particular. Si se ejecuta el cdigo con el depurador, a continuacin, el error
desaparece; slo reaparece cuando el depurador se apaga (haciendo as mucho ms difcil de encontrar).
Estos son a veces conocidos como "Heizenbugs '(despus de principio de incertidumbre de Heizenberg).

En las descripciones de las herramientas a continuacin, indicaremos las herramientas que son ms
susceptibles de ser utilizados por los desarrolladores durante la prueba de componentes y pruebas de
integracin de componentes. Por ejemplo herramientas de medicin de la cobertura se utilizan con mayor
frecuencia en las pruebas de componentes, pero las herramientas de pruebas de rendimiento se utilizan con
ms frecuencia en las pruebas del sistema, las pruebas de integracin de sistemas y pruebas de aceptacin.

Tenga en cuenta que para el examen Foundation Certificate, slo es necesario reconocer los diferentes
tipos de herramientas y lo que hacen; que no es necesario un especifican en la data de ellos (o sabe cmo
usarlos).

6.1.2 Herramienta de apoyo para la gestin de las pruebas y exmenes

Qu significa "gestin de pruebas '? Podra ser 'la gestin de pruebas' o podra ser 'la gestin del proceso de
prueba'. Las herramientas en esta amplia categora proporcionan soporte para uno o ambos de estos. La gestin
de la prueba se aplica sobre la totalidad del ciclo de vida de desarrollo de software, por lo que una herramienta
de gestin de prueba podra estar entre los primeros en ser utilizado en un proyecto. Una herramienta de
gestin de pruebas tambin puede gestionar las pruebas, que se iniciara al principio del proyecto y continuara
para ser utilizado en todo el proyecto y tambin despus de que el sistema haba sido puesto en libertad. En la
prctica, las herramientas de gestin de pruebas suelen ser utilizados por los probadores especial-ist o gerentes
de las pruebas a nivel de prueba del sistema o aceptacin.

Herramientas de gestin de pruebas

Las caractersticas proporcionadas por las herramientas de gestin de prueba incluyen los que se
enumeran a continuacin.Algunas herramientas proporcionarn todas estas caractersticas; otros

pueden proporcionar una o ms de las caractersticas, sin embargo este tipo de herramientas
todava seran clasificados como herramientas de gestin de prueba.

Rasgos o caractersticas de las herramientas de gestin de pruebas incluyen soporte para:

la gestin de las pruebas (por ejemplo, hacer el seguimiento de los datos asociados a un
determinado conjunto de pruebas, sabiendo que pone a prueba necesita para funcionar en un entorno
comn, nmero de pruebas previstas, por escrito, correr, pasado o no);

la programacin de pruebas para ser ejecutado (manualmente o mediante una herramienta de

ejecucin de la prueba);

la gestin de las actividades de prueba (tiempo de permanencia en el diseo de pruebas, ejecucin

de la prueba, si estamos en la fecha prevista o en el presupuesto);

interfaces con otras herramientas, tales como:

herramientas de ejecucin de pruebas (prueba de herramientas en ejecucin);

Herramientas de gestin de incidentes

herramientas de gestin de requisitos;

herramientas de gestin de configuracin;

trazabilidad de las pruebas, resultados de pruebas y defectos en los requisitos o de otras fuentes;

resultados de las pruebas de registro (tenga en cuenta que la herramienta de gestin de pruebas no
se ejecuta pruebas,

pero podra resumir los resultados de herramientas de ejecucin de pruebas de que la prueba ManageMent interfaces de las herramientas con);

la preparacin de informes de progreso basados en mtricas (anlisis cuantitativo), tales como:

las pruebas se ejecutan y se pasan las pruebas;

incidentes plantearon, defectos fijos y excepcional.

Esta informacin se puede utilizar para controlar el proceso de prueba y decidir las acciones a tomar
(control de prueba), como se describe en el captulo 5. La herramienta tambin da informacin sobre el
componente o sistema que est siendo probado (el objeto de prueba). herramientas de gestin de pruebas
ayudan a reunir, organizar y comunicar informacin acerca de las pruebas en un proyecto.

herramientas de gestin de requisitos

Son herramientas de gestin de requisitos herramientas realmente poniendo a prueba?Algunas personas

pueden decir que no lo son, sino que proporcionan algunas de las caractersticas que son muy tiles para
las pruebas. Dado que las pruebas se basan en los requisitos, mejor ser la calidad de las requerir-mentos,
ms fcil ser para escribir pruebas de ellos. Tambin es importante ser capaz de rastrear las pruebas a los
requisitos y exigencias de pruebas, como vimos en el captulo 2.

Algunas herramientas de gestin de requisitos son capaces de encontrar defectos en las requerirmentos, por ejemplo mediante la comprobacin de palabras ambiguas o prohibidas, tales como "fuerza",
"y / o", "segn sea necesario" o "(por decidir) '.

Funciones o caractersticas de las herramientas de gestin de requisitos incluyen soporte para:

el almacenamiento de estados de requisitos;

el almacenamiento de informacin sobre los atributos de requisitos;

verificacin de la coherencia de los requisitos;

identificar indefinido, desaparecidos o 'que se define ms adelante' requisitos;

fijacin de las prioridades con fines de prueba;

trazabilidad de los requisitos a los ensayos y pruebas a los requisitos, funciones o elementos;

trazabilidad a travs de niveles de requisitos;

interfaz para probar las herramientas de gestin;

la cobertura de las necesidades por un conjunto de pruebas (a veces).

Herramientas de gestin de incidentes

Este tipo de herramienta tambin se conoce como una herramienta de seguimiento de defectos, una
herramienta de gestin de defectos, una herramienta de error de seguimiento o una herramienta de gestin
de errores. Sin embargo, 'incidente hombre-gestin de herramientas "es probablemente un mejor
nombre para l, porque no todas las cosas rastreado en realidad son defectos o errores; incidentes tambin
pueden ser percibidos problemas, anomalas (que no son necesariamente defectos) o las solicitudes de
mejora.Tambin lo que normalmente se registra es la informacin sobre el error (no el defecto) que se
gener durante la prueba - informacin sobre el defecto que caus que el no vendra a la luz cuando
alguien (por ejemplo, un desarrollador) comienza a investigar el fracaso.

Los informes de incidentes pasan por una serie de etapas de identificacin inicial y la grabacin de los
detalles, a travs de anlisis, clasificacin, asignacin para

la fijacin, fijo, re-probado y cerrada, tal como se describe en el captulo 5.Incidente gestionar-ment
herramientas hacen que sea mucho ms fcil hacer un seguimiento de los incidentes en el tiempo.

Funciones o caractersticas de las herramientas de gestin de incidentes incluyen soporte para:

almacenar informacin sobre los atributos de los incidentes de gravedad (por ejemplo);

el almacenamiento de archivos adjuntos (por ejemplo, una captura de pantalla);

priorizacin de incidentes;

la asignacin de acciones a las personas (FIX, prueba de confirmacin, etc.);

estado (por ejemplo abierta, rechazado, duplicar, diferido, listo para la prueba de confirmacin,
cerrado);

notificacin de estadsticas / mtricas sobre incidentes (por ejemplo, tiempo medio abierta, el
nmero de incidentes con cada estado, el nmero total recaudado, abierto o cerrado).

funcionalidad de la herramienta de gestin de incidencias se puede incluir en las herramientas de

gestin de pruebas comerciales.

herramientas de gestin de configuracin

Un ejemplo: Un grupo de prueba comenz a probar el software, esperando encontrar la costumbre

bastante alto nmero de problemas. Pero para su sorpresa, el software pareca ser mucho mejor de lo
habitual en esta ocasin - se encontraron muy pocos defectos. Antes de que CEL ebrated-la gran calidad
de esta versin, que acaba de hacer una comprobacin adicional para ver si tenan la versin correcta y
descubrieron que en realidad estaban probando la versin de dos meses anteriores (que haban sido

depuradas) con las pruebas de que version anterior. Era bueno saber que esto todava estaba bien, pero no
estaban en realidad probando lo que pensaban que estaban probando o lo que deberan haber estado
probando.

Herramientas de gestin de configuracin no son estrictamente probando herramientas o bien, pero

buena gestin de la configuracin es crucial para el ensayo controlado, como se describe en el Captulo
5.Tenemos que saber exactamente qu es lo que estamos SUP-puesto a prueba, como la versin exacta de
todas las cosas que pertenecen a un sistema. Es posible llevar a cabo actividades de gestin de
configuracin sin el uso de herramientas, pero las herramientas de hacer la vida mucho ms fcil,
especialmente en entornos complejos.

Testware necesita estar bajo gestin de la configuracin y la misma herramienta puede ser capaz de ser
utilizado para testware as como para elementos de software. Testware tambin tiene diferentes versiones
y se cambia con el tiempo. Es importante para ejecutar la versin correcta de los ensayos, as, como
nuestro ejemplo anterior muestra.

Funciones o caractersticas de las herramientas de gestin de configuracin incluyen soporte para:

almacenar informacin acerca de las versiones y la obra del software y testware;

trazabilidad entre el software y testware y diferentes versiones o variantes;

hacer el seguimiento de las versiones con las que pertenecen las configuraciones (por ejemplo
ciera que operan los sistemas, las bibliotecas, los navegadores);

la construccin y la gestin de la liberacin;

baselining (por ejemplo, todos los elementos de configuracin que componen una versin especfica);

control de acceso (registro de salida).

6.1.3 Herramienta de apoyo para pruebas estticas

Las herramientas descritas en esta seccin apoyan las actividades de ensayo descritos en el Captulo 3.

herramientas de apoyo a proceso de revisin

El valor de los diferentes tipos de revisin se discuti en el Captulo 3. Para una revisin muy informal,
donde una persona se ve en el documento de otra y se dan algunos comentarios al respecto, una
herramienta como esto podra ponerse en el camino. Sin embargo, cuando el proceso de revisin es ms
formal, cuando muchas personas estn involucradas, o cuando las personas involucradas estn en
diferentes ubicaciones geogrficas, a continuacin, se convierte en soporte de la herramienta mucho ms
beneficioso.

Es posible hacer un seguimiento de toda la informacin para un proceso de revisin mediante hojas de
clculo y documentos de texto, sino una herramienta de revisin que se ha diseado con el propsito es
ms probable que hacer un mejor trabajo.Por ejemplo, una cosa que debe vigilarse para cada revisin es
que los crticos no han pasado sobre el documento demasiado rpido, es decir, que el ndice de
comprobacin (nmero de pginas controladas por hora) era similar a la recomendada para ese ciclo de
revisin. Una herramienta de apoyo a proceso de revisin podra calcular automticamente la velocidad y
la comprobacin de flag excepciones. Las herramientas de apoyo a proceso de revisin normalmente se
pueden adaptar para el proceso de revisin en particular o tipo de revisin se est realizando.

Rasgos o caractersticas de las herramientas de apoyo proceso de revisin incluyen soporte para:

una referencia comn para el proceso de revisin o procesos para utilizar en diferentes situaciones;

almacenar y clasificar los comentarios de revisin;

comunicar comentarios a las personas pertinentes;

la coordinacin de las revisiones en lnea;

hacer el seguimiento de los comentarios, incluyendo los defectos encontrados y proporcionar

estadsti cal informacin sobre ellos;

proporcionando la trazabilidad entre los comentarios, documentos documentos revisados y afines;

un repositorio de reglas, procedimientos y listas de control para ser utilizado en los exmenes, as
como los criterios de entrada y salida;

control del estado de revisin (pasado, fue aprobada con correcciones, requiere re-examen);

recoger mediciones e informar sobre los factores clave.

herramientas de anlisis esttico (D)

El '(D)' despus de esto (y otros tipos de herramienta) indica que estas herramientas son ms susceptibles de
ser utilizados por los desarrolladores. El anlisis esttico de herramientas se discuti en el Captulo 3.En esta
seccin damos un resumen de lo que hacen las herramientas.

Herramientas de anlisis esttico son utilizados normalmente por los desarrolladores como parte del
proceso de prueba y desarrollar-ment componente.El aspecto clave es que el cdigo (ni ningn otro artefacto)
no se ejecuta o se ejecutan. Por supuesto, la propia herramienta se ejecuta, pero el cdigo fuente que nos
interesa es la de datos de entrada a la herramienta.

Herramientas de anlisis esttico son una extensin de la tecnologa de compilacin - de hecho,

algunos compiladores ofrecen funciones de anlisis esttico.Vale la pena comprobar lo que est
disponible a partir de los compiladores existentes o entornos de desarrollo antes de mirar purpersiguiendo una herramienta de anlisis esttico ms sofisticado.

El anlisis esttico tambin se puede llevar a cabo en otras cosas que el cdigo de software, por
ejemplo, el anlisis esttico de requisitos o el anlisis esttico de los sitios web (por ejemplo, para evaluar
el uso adecuado de etiquetas de accesibilidad o el seguimiento de los estndares HTML).

herramientas de anlisis esttico de cdigo puede ayudar a los desarrolladores a entender la estruc-tura
del cdigo, y tambin puede ser utilizado para hacer cumplir las normas de codificacin. Vase la seccin
6.2.3 para las consideraciones especiales en la introduccin de herramientas de anlisis esttico en una
organizacin.

Funciones o caractersticas de las herramientas de anlisis esttico incluyen soporte para:

calcular mtricas tales como la complejidad ciclomtica o niveles de anidacin (que pueden ayudar a
identificar dnde ms pruebas puede ser necesaria debido al aumento del riesgo);

hacer cumplir las normas de codificacin;

analizar las estructuras y dependencias;

ayuda en la comprensin de cdigo;

identificar anomalas o defectos en el cdigo (como se describe en el captulo 3).

Las herramientas de modelado (D)

Las herramientas de modelado ayudan a validar modelos del sistema o software.Por ejemplo una
herramienta puede comprobar la consistencia de los objetos de datos en una base de datos y se puede
encontrar inconsis-tencias y defectos.Estos pueden ser difciles de recoger en las pruebas - es posible que
haya probado con un elemento de datos y no se dan cuenta de que en otra parte de la base de datos exista
informacin relacionada con ese tema. Las herramientas de modelado tambin pueden revisar los
modelos de estado o modelos de objetos.

Las herramientas de modelado suelen ser utilizados por los desarrolladores y pueden ayudar en el
diseo del software.

Una gran ventaja de las dos herramientas de modelado y herramientas de anlisis esttico es que
pueden ser utilizados antes de las pruebas dinmicas se pueden ejecutar. Esto permite que cualquier
defecto que estas herramientas pueden encontrar para ser identificados lo ms pronto posible, cuando es
ms fcil y ms barato para solucionarlos. Tambin hay un menor nmero de defectos que dejan a propagate en etapas posteriores, por lo que el desarrollo puede acelerarse y hay menos trabajo. (Por supuesto,
esto es difcil de demostrar, ya que estos defectos no estn all ahora!)

Tenga en cuenta que "herramientas basadas en modelos de ensayo son en realidad herramientas que
generan las entradas de prueba o casos de prueba a partir de la informacin almacenada sobre un modelo
en particular (por ejemplo, un diagrama de estado), por lo que se clasifican como herramientas de diseo
del ensayo (vase la Seccin 6.1.4).

Rasgos o caractersticas de las herramientas de modelado incluyen soporte para:

la identificacin de inconsistencias y defectos dentro del modelo;

ayudando a identificar y priorizar las reas del modelo para las pruebas;

la prediccin de la respuesta del sistema y el comportamiento bajo diversas situaciones, tales

como el nivel de carga;

ayudar a comprender las funciones del sistema e identificar las condiciones de prueba utilizando
un lenguaje de modelado como UML.

6.1.4 Herramienta de apoyo para la especificacin de las pruebas

Las herramientas descritas en esta seccin apoyan las actividades de ensayo descritos en el captulo 4.

Herramientas de diseo de prueba

Herramientas de diseo de prueba ayudan a construir casos de prueba, o al menos las entradas de
prueba (que es parte de un caso de prueba).Si un orculo automatizado est disponible, a continuacin, la
herramienta tambin puede con-struct el resultado esperado, por lo que en realidad puede generar casos
de prueba (en lugar de slo las entradas de prueba).

Por ejemplo, si los requisitos se mantienen en una herramienta de gestin de requisitos o de gestin de
pruebas, o en un Computer Aided Software Engineering herramienta (CASE) utilizado por los desarrolladores,
entonces es posible identificar los campos de entrada, incluyendo el rango de valores vlidos. Esta informacin
de la distancia se puede usar para identificar los valores lmite-arios y particiones de equivalencia. Si se
almacena el rango vlido, la herramienta puede distinguir entre los valores que deben ser aceptadas y las que
debe gen-eRate un mensaje de error. Si se almacenan los mensajes de error, entonces el resultado esperado se
puede comprobar en detalle. Si se conoce el resultado esperado de la entrada de un valor vlido, entonces
resultado que espera tambin se puede incluir en el caso de prueba construido por la herramienta de diseo de
prueba.

Otro tipo de herramienta de diseo de la prueba es una que ayuda a seleccionar combinaciones de
posibles factores para ser utilizados en la prueba, para asegurar que todos los pares de combinaciones de
sistema operativo y el navegador se prueban, por ejemplo. Algunas de estas herramientas pueden utilizar
matrices ortogonales. Ver [Copeland, 2003] para una descripcin de estas tcnicas combi-nacin.

Tenga en cuenta que la herramienta de diseo de la prueba puede tener slo un orculo parcial - es
decir, se puede saber qu entrada los valores han de ser aceptados y rechazados, pero puede no conocer el
mensaje de error exacto o el clculo resultante para el resultado esperado de la prueba. As, la herramienta
de diseo de la prueba puede ayudarnos a empezar a trabajar con el diseo de pruebas e identificar todos
los campos, pero no va a hacer todo el trabajo de diseo de prueba para nosotros - no habr ms de
verificacin que puede ser necesario hacer.

Otro tipo de herramienta de diseo de la prueba a veces se llama un "raspador de pantalla ', una
plantilla estructurada o un marco de ensayo. La herramienta se parece a una ventana de la interfaz grfica
de usuario e identifica todos los botones, listas y campos de entrada, y se puede configurar una prueba
para cada cosa que encuentre. Esto significa que cada botn se hace clic, por ejemplo, y se seleccionar a
cada cuadro de lista. Este es un buen punto de partida para una serie completa de pruebas y que puede
rpida y fcilmente identificar los botones que no funcionan. Sin embargo, a menos que la herramienta
tiene acceso a un orculo, que puede no saber lo que realmente debera ocurrir como resultado de los
botones de seleccin.

Sin embargo, otro tipo de herramienta de diseo de la prueba puede ser combinado con una
herramienta de cobertura. Si una herramienta de cobertura ha identificado que se ramifica han sido
cubiertas por un conjunto de pruebas existentes, por ejemplo, tambin puede identificar la ruta que debe
ser tomada con el fin de cubrir las ramas no probados. Al identificar cul de los resultados anteriores
deci-Sion tiene que ser verdadera o falsa, la herramienta se puede calcular un valor de entrada que va a
provocar la ejecucin de tomar un camino particular con el fin de aumentar la cobertura. Aqu la prueba
est siendo diseado desde el propio cdigo. En este caso es menos probable la presencia de un orculo,
por lo que slo puede ser las entradas de prueba que se construyen mediante la herramienta de diseo de
la prueba.

Rasgos o caractersticas de las herramientas de diseo de prueba incluyen soporte para:

la generacin de valores de entrada de prueba desde:

REQUISITOS:

modelos de diseo (estado, datos u objeto);

2.3

Cdigo.

interfaces grficas de usuario;

Condiciones de prueba

la generacin de los resultados esperados, si un orculo est disponible para la herramienta.

La ventaja de este tipo de herramientas es que puede identificar fcilmente y rpidamente las pruebas
(o entradas de prueba) que va a ejercer todos los elementos, por ejemplo, campos de entrada, botones,
ramas. Esto ayuda a la prueba para ser ms a fondo (si es un objetivo de la prueba!)

Entonces podemos tener el problema de tener demasiadas pruebas y la necesidad de encontrar una
forma de identificar las pruebas ms importantes para correr. La tala de un nmero unmanage-capaces de
pruebas se puede hacer mediante el anlisis de riesgos (vase el captulo 5). Usando una tcnica combinacin tales como matrices ortogonales tambin puede ayudar.

Herramientas de preparacin de datos de prueba

La creacin de datos de prueba puede ser un esfuerzo significativo, especialmente si se necesita una
extensa gama o el volumen de los datos para las pruebas. Herramientas de prueba de preparacin de
datos ayudan en esta rea.Pueden ser utilizados por los desarrolladores, pero tambin pueden ser
utilizados durante sistema o pruebas de aceptacin. Son particularmente tiles para rendimiento per-y
pruebas de fiabilidad, donde se necesita una gran cantidad de datos realistas.

Herramientas de prueba de preparacin de datos permiten que los datos se seleccionan a partir de una
base de datos existente o creado, generado, manipulados y editados para su uso en pruebas. Las
herramientas ms sofisticadas pueden hacer frente a una serie de archivos y formatos de base de datos.

Rasgos o caractersticas de las herramientas de preparacin de datos de prueba incluyen el apoyo a:

extraer registros de datos seleccionados a partir de archivos o bases de datos;

'masaje' registros de datos para que sean annimos o no capaz de identificarse con la gente real
(para la proteccin de datos);

permitir a los registros para ser ordenados o dispuestos en un orden diferente;

generar nuevos registros con los datos pertinentes pseudo-aleatorios o datos creados de acuerdo
con algunas directrices, por ejemplo, un perfil operacional;
construir un gran nmero de registros similares a partir de una plantilla, para dar un gran conjunto
de registros para las pruebas de volumen, por ejemplo.

6.1.5
Herramienta de apoyo para la ejecucin de la prueba y la explotacin
forestal

Herramientas de ejecucin de pruebas

Cuando la gente piensa en una "herramienta de prueba ', por lo general es una herramienta de ejecucin de
pruebas que tienen en mente, una herramienta que puede ejecutar las pruebas.Este tipo de herramienta tambin se
conoce como una "herramienta de prueba de marcha. La mayora de las herramientas de este tipo ofrecen una
manera de iniciarse mediante la captura o la grabacin de las pruebas manuales; de ah que tambin se conocen
como herramientas 'de captura / reproduccin "," / repeticin de captura' 'herramientas o herramientas de
grabacin / reproduccin.La analoga es con la grabacin de un programa de televisin, y reproduccin del
mismo. Sin embargo, las pruebas no son algo

que se reproducen slo para otras personas a ver las pruebas de interactuar con el sistema, que puede
reaccionar de forma ligeramente diferente cuando se repiten las pruebas.Por lo tanto Cap-rado las pruebas
no son adecuados si se desea alcanzar el xito a largo plazo con una herramienta de ejecucin de la
prueba, tal como se describe en la Seccin 6.2.3.

herramientas de ejecucin de pruebas utilizan un lenguaje de script para manejar la herramienta. El

lenguaje de programacin es en realidad un lenguaje de programacin. Por lo que cualquier probador que
desee utilizar una herramienta de ejecucin de la prueba directamente tendr que utilizar conocimientos
de programacin para crear y modificar los scripts. La ventaja de secuencias de comandos programable es
que las pruebas se pueden repetir las acciones (en bucles) para diferentes valores de los datos (es decir, las
entradas de prueba), que pueden tomar diferentes rutas, dependiendo del resultado de una prueba (por
ejemplo, si no pasa la prueba, vaya a un conjunto diferente de pruebas) y pueden ser llamados desde otros
scripts que dan algn tipo de estructura para el conjunto de las pruebas.

Cuando las personas se encuentran con una herramienta de ejecucin de la prueba, tienden a utilizarlo
para la "captura / reproduccin ', que suena muy bien cuando se escucha por primera vez al respecto. La
teora es que mientras se ejecutan las pruebas manuales, slo tiene que encender la "captura", como una
grabadora de vdeo para un programa de televisin. Sin embargo, la teora se viene abajo cuando se
intenta reproducir las pruebas capturados - este enfoque no escala para un gran nmero de pruebas. La
razn principal de esto es que una secuencia de comandos capturado es muy difcil de mantener porque:

Est estrechamente relacionado con el flujo y la interfaz presentada por la interfaz grfica de
usuario.

Se puede depender de las circunstancias, el estado y el contexto del sistema en el momento en que se
registr el guin.Por ejemplo, una secuencia de comandos capturar un nuevo nmero de orden asignado
por el sistema cuando se graba una prueba. Cuando la prueba se reproduce, el sistema asignar un nmero
de orden diferente y rechazar las solicitudes SUBSECUENTE que contienen el nmero de pedido
previamente capturada.

La informacin de contacto de prueba es "hard-coded ', es decir, que se incorpora en la secuencia

de comandos UAL individ para cada prueba.

Cualquiera de estas cosas pueden ser superados mediante la modificacin de las secuencias de comandos,
pero entonces ya no son slo grabar y reproducir! Si se necesita ms tiempo para actualizar una prueba
capturado de lo que se necesitara para ejecutar la misma prueba de nuevo manualmente, los guiones tienden a
ser abandonado y se convierte en la herramienta 'estantera-ware'.

Hay mejores maneras de utilizar las herramientas de ejecucin de pruebas para hacer que funcionen
bien y realmente ofrecer los beneficios de correr sin supervisin de pruebas automatizadas. Hay por lo
menos cinco niveles de secuencias de comandos y tambin diferentes tcnicas de comparacin.
secuencias de comandos basada en datos es un avance con respecto a las secuencias de comandos
capturados, pero los guiones de palabras clave impulsada dan significativamente ms beneficios. [Fewster
y Graham, 1999], [Buwalda et al., 2001].[Mosley y Posey, 2002] describir "control sincronizado de
pruebas basadas en datos '. (Vase tambin el actculo 5.1.1.2).

Hay muchas maneras diferentes de utilizar una herramienta de ejecucin de la prueba y las herramientas
mismas continan para obtener nuevas caractersticas tiles. Por ejemplo, una herramienta exe-cution prueba
puede ayudar a identificar los campos de entrada que formarn las entradas de prueba y puede construir una
tabla que es el primer paso hacia el scripting basado en datos.

A pesar de que se conocen comnmente como herramientas de prueba, en realidad son la mejor opcin para
las pruebas de regresin (para que pudieran ser referidos como "pruebas de herramientas de regresin" en
lugar de "herramientas de prueba '). Una herramienta de ejecucin de las pruebas ms a menudo lleva a cabo
pruebas que ya se han ejecutado antes. Una de las ventajas ms importantes de la utilizacin de este tipo de
herramientas es que cada vez que se cambia un sistema existente (por ejemplo, para una solucin defecto o una
mejora), todas las pruebas que se ejecutaron anteriormente podran

potencialmente ser ejecutado de nuevo, para asegurarse de que los cambios no han alterado el sistema
existente mediante la introduccin o revelar un defecto.
Funciones o caractersticas de las herramientas de ejecucin de pruebas incluyen soporte para:

la captura de entradas de prueba (grabacin) mientras que las pruebas se ejecutan de forma manual;

almacenar un resultado esperado en forma de una pantalla o un objeto de comparar con, la

prxima vez que se ejecute la prueba;

la ejecucin de pruebas de secuencias de comandos y archivos de datos almacenados,

opcionalmente, los que se accede por el script (si es impulsado por los datos o se utiliza secuencias de
comandos basado en palabras clave);


la comparacin dinmica (mientras se ejecuta la prueba) de las pantallas, elementos, enlaces,
controles, objetos y valores;

capacidad para iniciar la comparacin posterior a la ejecucin;

resultados del registro de las pruebas realizadas (pasa / no pasa, las diferencias entre los resultados
esperados y reales);

enmascaramiento o filtrado de subconjuntos de los resultados reales y esperados, por ejemplo

excluyendo la fecha actual pantalla visualizada y el tiempo que no es de inters para una prueba en
particular;

la medicin de los tiempos de pruebas;

la sincronizacin de las entradas con la aplicacin que se est probando, por ejemplo, esperar
hasta que la apli cacin est listo para aceptar la siguiente entrada, o insertar un retardo fijo para
representar la velocidad de la interaccin humana;

el envo de los resultados de resumen de una herramienta de gestin de pruebas.

Mazo de prueba / Grupo de instrumentos de prueba de marco (D)

Estos dos tipos de herramientas se agrupan porque son variantes del tipo de apoyo que necesitan los
desarrolladores al probar componentes o de unidades de software individuales. Un instrumento de
prueba proporciona talones y los conductores, que son pequeos programas que interactan con el
software bajo prueba (por ejemplo, para probar middle-ware y software embebido).Vase el Captulo 2
para obtener ms detalles de cmo estos se utilizan en las pruebas de integracin. Algunas herramientas
de marco de prueba de unidad proporcionan soporte para el software orientado a objetos, otros por
otros paradigmas de desarrollo.frameworks de pruebas unitarias se pueden utilizar en el desarrollo gil
para automatizar las pruebas en Paral-lel con el desarrollo. Ambos tipos de herramientas permiten a los
desarrolladores para probar, identificar y localizar cualquier defecto. El marco o los talones y los
controladores proporcionan ninguna informacin que necesita el software que est siendo probado (por
ejemplo, una entrada que habra venido de un usuario) y tambin recibir cualquier informacin enviada

por el software (por ejemplo, un valor que se muestra en una pantalla). Los trozos tambin puede ser
denominado como "objetos de imitacin '.

arneses de prueba o controladores se pueden desarrollar en el local para los sistemas particulares. Asesoramiento
sobre el diseo de los pilotos de pruebas se puede encontrar en [Hoffman y Strooper, 1995].

Hay un gran nmero de herramientas 'xUnit' de programacin diferente lan-guas, por ejemplo JUnit
para Java, NUnit para aplicaciones .Net, etc. Hay dos herramientas comerciales y tambin de cdigo
abierto (es decir, libres) herramientas. Unidad de herramientas marco de pruebas son muy similares a
probar herramientas de ejecucin, ya que incluyen instalaciones como la capacidad de almacenar los
casos de prueba y monitorear si las pruebas de aprobacin o no, por ejemplo. La principal diferencia es
que no hay instalaciones de captura / reproduccin y que tienden a ser utilizado en un nivel inferior, es
decir, para el componente o pruebas de integracin de componentes, en lugar de para el sistema o pruebas
de aceptacin.

Rasgos o caractersticas de los arneses de prueba y herramientas de marco de pruebas unitarias

incluyen soporte para:

el suministro de insumos para el software que est siendo probado;

recibir las salidas generadas por el software que est siendo probado;

la ejecucin de una serie de pruebas en el marco o usar el instrumento de prueba;

el registro de la pasa / no pasa resultados de cada prueba (herramientas de marco);

pruebas de almacenamiento de herramientas (marco);

soporte para depuracin (herramientas de marco);

medicin de la cobertura en el nivel de cdigo (herramientas de marco).

comparadores de prueba

Es realmente una prueba si pones algunos elementos de entrada en algn tipo de software, pero nunca
mira para ver si el software produce el resultado correcto? La esencia de la prueba es comprobar si el
software produce el resultado correcto, y para hacer eso, hay que comparar lo que el software produce a
lo que debera producir. Una prueba comparador ayuda a automatizar aspectos de esa comparacin.

Hay dos formas en las que los resultados reales de la prueba se pueden comparar con los resultados
esperados para la prueba. comparacin dinmica es donde la comparacin se realiza de forma dinmica, es
decir, mientras que la prueba se est ejecutando. La otra forma es la comparacin posterior a la ejecu-cin,
donde se realiza la comparacin despus de la prueba ha finalizado la ejecucin y el software que se est
probando ya no est en funcionamiento.

herramientas de ejecucin de pruebas incluyen la capacidad de realizar la comparacin dinmica mientras que la
herramienta se ejecuta una prueba. Este tipo de comparacin es buena para comparar el texto de un mensaje de error
que aparece en una pantalla con el texto correcto para ese mensaje de error. comparacin dinmico es til cuando un
resultado real no coincide con el resultado esperado en el medio de una prueba - la herramienta puede ser
programado para tomar algunas medidas de recuperacin en este momento o ir a un conjunto diferente de las
pruebas.

la comparacin posterior a la ejecucin por lo general se realiza mejor mediante una herramienta
independiente (es decir, no la herramienta de ejecucin de la prueba). Este es el tipo de herramienta que
queremos decir con una herramienta de prueba de comparacin comparativamente-tor o la prueba y es
tpicamente una herramienta 'stand-alone'. Los sistemas operativos suelen tener herramientas de
comparacin de archivos disponibles que pueden ser utilizados para la comparacin posterior a la
ejecucin y, a menudo una herramienta de comparacin se desarrollarn en el local para la comparacin
de un determinado tipo de archivo o prueba de resultado.

comparacin post-ejecucin es mejor para la comparacin de un gran volumen de datos, por ejemplo,
comparando el contenido de un archivo completo con los contenidos previstos de dicho archivo o en la
comparacin de un gran conjunto de registros de una base de datos con el contenido esperado de esos
registros. Por ejemplo, comparando el resultado de un lote de ejecucin (por ejemplo, procesamiento de
transacciones en lnea durante la noche del da) es probablemente imposible de hacer sin ayuda de
herramientas.

Si una comparacin es dinmica o posterior a la ejecucin, el comparador de prueba tiene que saber lo
que el resultado es correcto. Esto puede ser almacenado como parte del propio caso de prueba o puede ser
calculada utilizando un orculo de prueba. En el captulo 4 informa-cin sobre los orculos de prueba.

Rasgos o caractersticas de los comparadores de prueba incluyen soporte para:

comparacin dinmica de eventos transitorios que se producen durante la ejecucin de pruebas;

comparacin posterior a la ejecucin de los datos almacenados, por ejemplo en archivos o bases de
datos;

enmascaramiento o filtrado de subconjuntos de los resultados reales y esperados.

Herramientas de medicin de la cobertura (D)

Como bien has probado? Herramientas de cobertura pueden ayudar a responder a esta pregunta.

Una herramienta de cobertura identifica en primer lugar los elementos o elementos de cobertura que se
pueden contar, y en que la herramienta puede identificar cuando una prueba ha ejercido ese elemento en
edad de cubierta. A nivel de las pruebas de componentes, los elementos de cobertura podran ser lneas de
cdigo o cdigos de estados o resultados de las decisiones (por ejemplo, la salida Verdadero o Falso de
una instruccin IF). En el nivel de integracin de componentes, el elemento de cobertura puede ser una
llamada a una funcin o mdulo. A pesar de que la cobertura se puede medir en el sistema o acepteANCE niveles de prueba, por ejemplo, cuando el elemento de cobertura puede ser un estado-ment
requisito, no hay muchos (si lo hay) herramientas comerciales a este nivel; hay ms apoyo a nivel de la
herramienta de pruebas de componentes o en alguna medida a nivel inte-gracin componente.

El proceso de identificacin de los elementos de cobertura a nivel de la prueba componente se llama

'instrumentar el cdigo', tal como se describe en el captulo 4. Una serie de pruebas se ejecuta entonces a
travs del cdigo instrumentado, ya sea de forma automtica utilizando una herramienta exe-cution
prueba o manualmente. La herramienta de cobertura a continuacin, cuenta el nmero de elementos de
cobertura que han sido ejecutadas por el banco de pruebas, y refleja el porcentaje de elementos de
cobertura que se han ejercido, y tambin puede identificar los elementos que todava no se han ejercido
(es decir, an no probado). Las pruebas adicionales pueden ser ejecutadas para aumentar la cobertura (la
herramienta de informes de cobertura acumulada de todas las pruebas se ejecutan hasta el momento).

Las herramientas ms sofisticadas de cobertura pueden proporcionar apoyo para ayudar a iden-tificar
las entradas de prueba que va a ejercer las rutas que incluyen como an no ejercidas elementos de
cobertura (o enlace a una herramienta de diseo de prueba para identificar los elementos no ejercitadas).
Por ejemplo, si se han ejercido no todos los resultados de la decisin, la herramienta de cobertura puede
identificar el resultado particular de decisiones (por ejemplo, una salida falsa de una instruccin IF) que
ninguna prueba ha tenido hasta ahora, y puede entonces tambin ser capaces de calcular la entrada de
prueba requerida para forzar la ejecucin tomar ese resultado de la decisin.

Rasgos o caractersticas de las herramientas de medicin de cobertura incluyen soporte para:

Identificacin de los elementos de cobertura (instrumentar el cdigo);

calcular el porcentaje de elementos de cobertura que fueron ejercidos por una serie de pruebas; '

los elementos de informacin de cobertura que no se han ejercido hasta el momento;

la identificacin de entradas de prueba para ejercer artculos que an no cubiertas (funcionalidad

de la herramienta de diseo de la prueba);

generando talones y los conductores (si es parte de un marco de prueba de unidad).

Tenga en cuenta que las herramientas de cobertura slo miden la cobertura de los objetos que se
puedan identificar. El hecho de que las pruebas han alcanzado el 100% comunicado cubierta de edad, esto
no significa que su software ha sido probado 100%!

herramientas de seguridad

Hay una serie de herramientas que se protejan los sistemas de los ataques externos, por ejemplo
servidores de seguridad, que son importantes para cualquier sistema.

Herramientas de pruebas de seguridad se pueden utilizar para probar la seguridad al tratar de entrar en
una sistema, si es o no est protegido por una herramienta de seguridad. Los ataques pueden centrarse

en la red, el software de soporte, el cdigo de la aplicacin o la base de datos subyacente.

Funciones o caractersticas de las herramientas de pruebas de seguridad incluyen soporte para:

la identificacin de los virus;

deteccin de intrusiones, tales como ataques de denegacin de servicio;

la simulacin de diversos tipos de ataques externos;

el sondeo de puertos abiertos u otros puntos externamente visibles de ataque;

identificar las debilidades en los archivos de contraseas y contraseas;

controles de seguridad durante el funcionamiento, por ejemplo, para comprobar la integridad de

los archivos y deteccin de intrusos, por ejemplo, comprobar los resultados de los ataques de prueba.

6.1.6

Herramienta de apoyo para el funcionamiento y la supervisin

Las herramientas descritas en esta prueba el apoyo seccin que se puede llevar a cabo en un sistema
cuando est en funcionamiento, es decir, mientras se est ejecutando. Esto puede ser durante las pruebas o
podra ser despus de un sistema se libera en el modo Live.

Las herramientas de anlisis dinmico (D)

Las herramientas de anlisis dinmicos son "dinmico", ya que requieren que el cdigo sea
corriendo.Son "anlisis" en lugar de herramientas 'de prueba' porque analizan lo que est pasando "entre
bastidores", mientras que se ejecuta el software (si se ejecuta con los casos de prueba o estn siendo
utilizados en la operacin).

Una analoga con un coche puede ser til en este caso. Si usted va a mirar un coche para comprar, es posible que se
sienta en ella para ver si es cmodo y ver lo que suenan las puertas hacen - esto sera el anlisis esttico porque el coche no
est siendo impulsada. Si se toma una prueba de manejo, entonces sera comprobar que el coche lleva a cabo como se
esperaba (por ejemplo, gira a la derecha cuando se gira el volante hacia la derecha) - esto sera una prueba. Mientras que el
coche est en marcha, si se va a comprobar el nivel de aceite o el lquido de frenos, esto sera dinmica Analy-sis - que
slo se puede hacer mientras el motor est en marcha, pero no es un caso de prueba.

Cuando el tiempo de respuesta de su PC se ralentiza y ms lento con el tiempo, pero ha mejorado

mucho despus de volver a arrancar da, esto puede ser debido a una "prdida de memoria", donde los
programas no liberan correctamente bloques de memoria de vuelta al sistema operativo . Finalmente, el
sistema funcionar sin memoria por completo y se detendr. Re-arranque restaura toda la memoria que se
haba perdido, por lo que el rendimiento del sistema se ha restaurado a su estado normal.

Rasgos o caractersticas de las herramientas de anlisis dinmicos incluyen soporte para:

la deteccin de fugas de memoria;

la identificacin de la aritmtica de punteros errores como punteros nulos;

la identificacin de dependencias de tiempo.

Estas herramientas normalmente seran utilizados por los desarrolladores en la prueba de componentes
y pruebas de integracin de componentes, por ejemplo, al probar el middleware, al probar la seguridad o
en la bsqueda de defectos de robustez.

Otra forma de anlisis dinmico para sitios web es comprobar si cada enlace que realmente hace
enlazar a otra cosa (este tipo de herramienta puede ser llamada una "tela de araa '). La herramienta no
sabe si se ha vinculado a la pgina correcta, pero al menos se puede encontrar enlaces muertos, que
pueden ser tiles.

-Pruebas de rendimiento, carga de prueba y herramientas de stress-testing-herramientas de

pruebas de rendimiento se refieren a las pruebas a nivel de sistema para ver si es o no el sistema har frente a
un gran volumen de uso.A 'Load' prueba comprueba que el sistema puede hacer frente a su nmero esperado
de transacciones.Un "volumen" prueba comprueba que el sistema puede hacer frente a una gran cantidad de
datos, por ejemplo, muchos campos de un registro, muchos registros en un archivo, etc. Una prueba de
"estrs" es uno que va ms all del uso normal esperado del sistema (para ver lo que pasara ms all de sus
expectativas de diseo), con respecto a la carga o volumen.

En las pruebas de rendimiento, muchas entradas de prueba pueden ser enviados en el software o
sistema en el que los resultados individuales no puedan ser controlados con detalle. El objetivo del
ensayo es medir caractersticas, tales como tiempos de respuesta, el rendimiento o el tiempo medio entre
fallos (para las pruebas de fiabilidad).

Con el fin de evaluar el rendimiento, la herramienta tiene que generar algn tipo de actividad en el
sistema, y esto se puede hacer de diferentes maneras. En un nivel muy sencilla la misma transaccin
podra repetirse muchas veces, pero esto no es realis-tic. Hay muchos niveles de realismo que se podran
establecer, en funcin de la herramienta, como los diferentes perfiles de usuario, diferentes tipos de
actividades, retrasos de temporizacin y otros parmetros. Adecuadamente la replicacin de los entornos
de usuario final y perfiles de usuario suele ser clave para obtener resultados realistas.

El anlisis de la salida de una herramienta de pruebas de rendimiento no siempre es sencillo y requiere

tiempo y experiencia. Si el rendimiento no es hasta el nivel que se espera, a continuacin, algunos
anlisis debe ser realizado para ver dnde est el problema y saber qu se puede hacer para mejorar el
rendimiento.

Rasgos o caractersticas de las herramientas de pruebas de rendimiento incluyen soporte para:

la generacin de una carga en el sistema a ensayar;

la medicin de la temporizacin de las operaciones especficas como la carga en el sistema vara;

la medicin de tiempos medios de respuesta;

la produccin de grficos o tablas de respuestas en el tiempo.

Las herramientas de monitoreo

Las herramientas de monitoreo se utilizan para el seguimiento continuo del estado del sistema en uso, con el
fin de tener la advertencia ms temprana de problemas y para mejorar el servicio.Existen herramientas de
monitoreo para servidores, redes, bases de datos, seguridad, realice-ANCE, sitio web y el uso de Internet y
aplicaciones.

Rasgos o caractersticas de las herramientas de supervisin incluyen soporte para:

la identificacin de problemas y el envo de un mensaje de alerta al administrador (por ejemplo,

administrador de la red);

el registro en tiempo real e informacin histrica;

encontrar los valores ptimos;

controlar el nmero de usuarios en una red;

trfico de la red de control (ya sea en tiempo real o que cubre una longitud de tiempo de
funcionamiento con el anlisis realizado despus).

6.1.7 Herramienta de apoyo para las reas especficas de la aplicacin (KL)

En este captulo, hemos descrito las herramientas segn sus clasificaciones funcionales generales. Tambin hay
otras especializaciones de herramientas dentro de estos clas-clasifi-. Por ejemplo, hay herramientas de pruebas

de rendimiento basadas en la Web, as como las herramientas de pruebas de rendimiento para los sistemas de
back-office. Existen herramientas de anlisis esttico para plataformas de desarrollo y lenguajes de
programacin especficos, ya que cada lenguaje de programacin y cada plataforma tiene caractersticas
distintas. Hay herramientas de anlisis dinmicos que se centran en temas de seguridad, as como herramientas
de anlisis dinmicos para sistemas embebidos.

juegos de herramientas comerciales podrn agruparse para reas de aplicacin especficas, tales como
sistemas basados en Web o incrustados.

6.1.8 Herramienta de apoyo utilizando otras herramientas

Las herramientas descritas en este captulo no son las nicas herramientas que un aparato puede hacer
uso. Normalmente, no puede pensar en un procesador de textos o una hoja de clculo como una
herramienta de prueba, pero a menudo se utilizan para almacenar los diseos de prueba, scripts de prueba
o datos de prueba. Probadores pueden tambin utilizar SQL para configurar y consultar bases de datos que
contiene los datos de prueba. Las herramientas utilizadas por los desarrolladores durante la depuracin,
para ayudar a localizar defectos y comprobar sus correcciones, tambin estn probando herramientas.

Los desarrolladores utilizan herramientas de depuracin al identificar y corregir defectos.Las

herramientas de depuracin les permiten ejecutar pruebas individuales y localizados para garantizar que
se han identificado correctamente la causa de un defecto y para confirmar que su cambio en el cdigo de
hecho corregir el defecto.

Es una buena idea para buscar en cualquier tipo de herramienta a su disposicin formas que podra ser
utilizado para ayudar a apoyar cualquiera de las actividades de prueba. Por ejemplo, los probadores
pueden utilizar scripts de Perl para ayudar a comparar los resultados de las pruebas.

6.2 uso efectivo de herramientas: POTENCIAL

Beneficios y riesgos

1 Un resumen de los beneficios y riesgos de la automatizacin de pruebas y

herramientas potenciales

apoyo para la prueba. (k)

2
Reconocer que las herramientas de ejecucin de pruebas puede tener
diferente tecnologa de secuencias de comandos
tcnicas, incluyendo impulsado por los datos y basado en palabras clave. {0}k = 0.015
L{/0}{1}1{/1}

La razn de la adquisicin de herramientas para apoyar la prueba es para obtener beneficios, mediante el
uso de un programa de software para realizar ciertas tareas que se realizan mejor por un ordenador que
por una persona.

Indicaciones para la introduccin de herramientas en una organizacin se puede encontrar en la web

Arti-culos, revistas y libros, tales como [Dustin et al., 1999], [Siteur, 2005] y [Fewster y Graham, 1999].

6.2.1 Los beneficios potenciales de la utilizacin de herramientas

Hay muchos beneficios que se pueden obtener mediante el uso de herramientas para apoyar la prueba,
sea cual sea el tipo especfico de herramienta. Adems, incluye:

la reduccin del trabajo repetitivo;

una mayor coherencia y capacidad de repeticin;

evaluacin objetiva;

la facilidad de acceso a la informacin sobre las pruebas o ensayos.

El trabajo repetitivo es tedioso que hacer manualmente. La gente se aburre y cometer errores al hacer
la misma tarea una y otra vez. Ejemplos de este tipo de trabajos repetitivos incluyen la ejecucin de
pruebas de regresin, entrando en la misma datos de prueba una y otra vez (ambos de los cuales se puede
hacer mediante una herramienta de ejecucin de la prueba), los comparen con los estndares de
codificacin (que puede ser realizado por un an-sis esttica herramienta) o la creacin de una base de
datos de ensayo especfico (que puede ser realizado por una herramienta de preparacin de datos de
prueba).

La gente tiende a hacer la misma tarea de una manera ligeramente diferente, incluso cuando piensan
que estn repitiendo algo exactamente. Una herramienta va a reproducir exactamente lo que lo haca
antes, por lo que cada vez que se ejecuta el resultado es consistente. Ejemplos en los que este aspecto es
beneficioso incluyen la comprobacin para confirmar la exactitud de una solucin a un defecto (que
puede ser realizado por una herramienta herramienta de depuracin o la ejecucin de la prueba),
introduzca-ing entradas de prueba (que puede ser realizado por una herramienta de ejecucin de la
prueba) y la generacin de pruebas de requisitos (que se pueden hacer con una herramienta de diseo de
la prueba o, posiblemente, una herramienta de gestin de requisitos).

Si una persona calcula un valor a partir de los informes de software o incidentes, pueden omitir
inadvertidamente algo, o sus propios prejuicios subjetivos pueden dar lugar a interpretar que los datos de
forma incorrecta. Utilizando una herramienta significa que el sesgo subjetiva se retira y la evaluacin es
ms repetible y calculado de forma coherente. Los ejemplos incluyen la evaluacin de la complejidad
ciclomtica o anidar niveles de un componente (que puede ser realizado por una herramienta de anlisis
esttico), la cobertura (herramienta de medida de cobertura), el comportamiento del sistema (herramientas
de monitoreo) y las estadsticas de incidentes (herramienta de gestin de pruebas).

Tener gran cantidad de datos no significa que la informacin se comunica. La informacin presentada
visualmente es mucho ms fcil para la mente humana para tomar en e interpretar. Por ejemplo, una tabla
o grfica es una mejor manera de mostrar informa-cin que una larga lista de nmeros - esta es la razn
por tablas y grficos en las planillas de clculo son tan tiles. herramientas especiales dan estas funciones
directamente para la informacin que procesan. Los ejemplos incluyen estadsticas y grficos sobre el
progreso de prueba (ejecucin de la prueba o de la herramienta de gestin de pruebas), las tasas de

incidencia (gestin de incidente o de instrumentos de medida de gestin) y rendimiento (herramienta de

pruebas de rendimiento).

Adems de estos beneficios generales, cada tipo de herramienta tiene beneficios especficos
relacionados con el aspecto de las pruebas que soporta la herramienta particular. Estos beneficios son
normalmente prominentemente en la informacin disponible para las ventas del tipo de herramienta. Vale
la pena investigar una serie de diferentes herramientas para obtener una visin general de los beneficios.

6.2.2 Los riesgos de usar herramientas

Aunque hay importantes beneficios que se pueden lograr usando herramientas para apoyar las actividades
de prueba, hay muchas organizaciones que no han logrado los beneficios que esperaban.

La simple compra de una herramienta no es garanta de lograr beneficios, al igual que la compra de la
membresa en un gimnasio no es garanta de que va a ser ms en forma. Cada tipo de herramienta
requiere una inversin de tiempo y esfuerzo con el fin de lograr los beneficios potenciales.

Hay muchos riesgos que estn presentes cuando el apoyo de herramientas para la prueba es introproducida y utilizada, sea cual sea el tipo especfico de herramienta. Los riesgos incluyen:

expectativas poco realistas de la herramienta;

subestimar el tiempo, coste y esfuerzo para la introduccin inicial de una herramienta;

subestimar el tiempo y el esfuerzo necesarios para lograr importantes beneficios y en contra

conti- de la herramienta;

subestimar el esfuerzo necesario para mantener los activos de prueba generados por la
herramienta;

la excesiva dependencia de la herramienta.

Las expectativas poco realistas pueden ser uno de los mayores riesgos para el xito con las
herramientas. Las herramientas son solamente software y todos sabemos que hay muchos problemas con
cualquier tipo de software! Es importante tener claros los objetivos para lo que la herramienta puede
hacer y que esos objetivos son realistas.

La introduccin de algo nuevo en una organizacin rara vez es sencillo. Despus de haber comprado
un instrumento, tendr que pasar de la apertura de la caja para tener un nmero de personas que son
capaces de utilizar la herramienta de una manera que traer beneficios. Habr problemas tcnicos que
superar, pero tambin habr resistencia por parte de otras personas - ambos necesitan ser abordados con el
fin de tener xito en presen-cin de una herramienta.

Piense en la ltima vez que hiciste algo nuevo por primera vez (aprender a conducir, andar en bicicleta,
esquiar). Sus primeros intentos fueron poco probable que sea muy bueno, pero con ms experiencia que
llegaron a ser mucho mejor. El uso de una herramienta de prueba por primera vez no va a ser su mejor uso
de la herramienta, ya sea. Se necesita tiempo para desarrollar formas de utilizacin de la herramienta con
el fin de lograr lo que es posible. Afortunadamente, hay algunos atajos (por ejemplo, la lectura de libros y
artculos sobre las experiencias de otras personas y aprender de ellos). Vase tambin la seccin 6.3 para
obtener ms detalles sobre la introduccin de una herramienta en una organizacin.

una planificacin insuficiente para el mantenimiento de los activos que la herramienta se pro-duce un
fuerte contribuyente a las herramientas que terminan como 'mercancas de tiempo de conservacin', junto
con los riesgos mencionados anteriormente. Aunque particularmente relevante para las herramientas de
prueba exe-cution, la planificacin de mantenimiento es tambin un factor con otro tipo de herramienta.

Las herramientas no son definitivamente la magia! Ellos pueden hacer muy bien lo que han sido diseados
para hacer (por lo menos una herramienta de buena calidad puede), pero no pueden hacerlo todo. Una
herramienta sin duda puede ayudar, pero no sustituir a la inteligencia necesaria para conocer la mejor manera
de usarlo, y cmo evaluar los usos actuales y futuras de la herramienta. Por ejemplo, una herramienta de
ejecucin de la prueba no reemplaza la necesidad de un buen diseo de prueba y no se debe utilizar para cada
prueba - algunas pruebas son an mejores

ejecutado manualmente.Un examen que toma un tiempo muy largo para automatizar y no se ejecuta muy
a menudo es mejor hacerlo de forma manual.
Esta lista de riesgos no es exhaustiva. Otros dos factores importantes son:

la habilidad necesaria para crear buenas pruebas;

la habilidad necesaria para utilizar las herramientas bien, dependiendo del tipo de herramienta.

Las habilidades de un probador no son las mismas que las habilidades del usuario de la herramienta. El
probador se concentra en lo que debe ser probado, lo que los casos de prueba deben ser y cmo priorizar las
pruebas. El usuario de la herramienta se concentra en la mejor manera de obtener la herramienta para hacer su
trabajo con eficacia y cmo dar el aumento de los beneficios del uso de la herramienta.

6.2.3 Consideraciones especiales para algunos tipos de herramientas

Herramientas de ejecucin de pruebas

A '/ herramienta de reproduccin de captura "es un trmino engaoso, aunque es de uso comn. Captura /
reproduccin es un modo de utilizar una herramienta de ejecucin de la prueba y, probablemente, la peor
manera de usarlo!

Con el fin de saber lo que pone a prueba a ejecutar y cmo ejecutar ellos, la herramienta de ejecu-cin de
prueba, debe tener alguna forma de saber qu hacer - esto es la secuencia de comandos para la herramienta.
Pero puesto que la herramienta es nico software, el guin debe ser exacta y sin ambigedades al ordenador
(que no tiene sentido comn). Esto significa que la secuencia de comandos se convierte en un programa,
escrito en un lenguaje de programacin. El lenguaje de script-cin puede ser especfico de una herramienta
en particular, o puede ser una ms general idioma.Los lenguajes de script no se utilizan solo por las
herramientas de ejecucin de pruebas, pero los guiones utilizados por la herramienta se almacenan
electrnicamente para ser ejecutado cuando las pruebas se ejecutan bajo el control de la herramienta.

Existen herramientas que pueden generar secuencias de comandos mediante la identificacin de lo que
est en la pantalla en lugar de mediante la captura de una prueba manual, pero todava generan secuencias
de comandos que se utilizarn en la ejecucin; ellos no estn libres de la escritura.

Hay diferentes niveles de secuencias de comandos. Cinco se describen en [Fewster y Graham, 1999]:

guiones lineales (que podran ser creadas manualmente o se capturan mediante el registro de una
prueba manual);

guiones estructurados (utilizando seleccin y estructuras de programacin iteracin);

guiones compartidos (donde una secuencia de comandos puede ser llamado por otros sistemas de
escritura por lo que puede ser re-utilizados - comparten secuencias de comandos tambin requieren
una biblioteca de scripts formal en virtud del hombre gestin de configuracin);

guiones basados en datos (cuando los datos de prueba est en un archivo o una hoja de clculo
para ser ledos por una secuencia de comandos de control);

secuencias de comandos basado en palabras clave (donde se almacena toda la informacin

acerca de la prueba en un archivo u hoja de clculo, con un nmero de secuencias de comandos de
control que implementan las pruebas descritas en el archivo).

La captura de una prueba manual parece ser una buena idea para empezar, sobre todo si se est
ejecutando actualmente pruebas manualmente de todos modos. Pero una prueba capturado (un guin
lineal) no es una buena solucin, por una serie de razones, incluyendo:

La secuencia de comandos no sabe cul es el resultado esperado es hasta que se programa en - que
slo almacena entradas que se han registrado, no se ponen a prueba los casos.

Un pequeo cambio en el software puede invalidar docenas o cientos de guiones.

El script grabado slo puede hacer frente a exactamente las mismas condiciones que cuando fue
registrado.Los acontecimientos inesperados (por ejemplo, un archivo que ya existe) no sern
interpretados correctamente por la herramienta.

Sin embargo, hay algunos momentos en los que la captura de entradas de prueba (es decir, registrocin de una prueba manual) es til. Por ejemplo, si usted est haciendo pruebas exploratorias o si est
ejecutando pruebas sin guin con los usuarios de negocios con experiencia, que puede ser muy til
simplemente para registrar todo lo que se hace, como una pista de auditora. Esto sirve como una forma
de documentacin de lo que se puso a prueba (aunque el anlisis puede no ser fcil). Esta pista de
auditora tambin puede ser muy til si se produce un error que no puede ser reproducido fcilmente - la
grabacin de la falla especfica se puede jugar a la promotora para ver exactamente qu secuencia caus
el problema.

entradas de prueba capturados pueden ser tiles en el corto plazo, donde el contexto sigue siendo
vlida. Slo que no espere para jugar de nuevo como pruebas de regresin (cuando el contexto de la
prueba puede ser diferente). pruebas capturados pueden ser aceptables para algunas pruebas docena,
donde el esfuerzo para actualizarlos cuando no es muy grande, los cambios en el software. No hay que
esperar un enfoque lineal de scripts para escalar a cientos o miles de pruebas.

As pruebas de captura tiene un lugar, pero no es un lugar grande en trminos de automatizacin de

ejecucin de la prueba.

guiones basados en datos permiten a los datos, es decir, las entradas de prueba y espera fuera viene,
para ser almacenados por separado de la secuencia de comandos. Esto tiene la ventaja de que un probador
que no sabe cmo utilizar un lenguaje de script puede rellenar un archivo o una hoja de clculo con los
datos de una prueba especfica. Esto es particularmente til cuando hay un gran nmero de valores de
datos que necesitan ser probados utilizando la misma secuencia de comandos de control.

secuencias de comandos basado en palabras clave incluyen no slo datos, sino tambin las palabras
clave en el archivo de datos u hoja de clculo. Esto permite un probador (que no es un programador de
secuencia de comandos) para elaborar una gran variedad de pruebas (no slo los datos de prueba de
entrada para esencialmente la misma prueba, al igual que en los scripts basados en datos). El probador
necesita saber qu palabras clave estn disponibles actualmente para usar (por alguien despus de haber
escrito un guin para l) y los datos que la palabra clave se esperaba, pero el probador puede entonces
escribir pruebas, no slo los datos de prueba. El probador tambin puede solicitar palabras clave
adicionales que se aaden al conjunto de guiones programados disponibles segn sea necesario. Las
palabras clave pueden hacer frente a las dos entradas de prueba y los resultados esperados.

Por supuesto, alguien todava tiene que ser capaz de utilizar la herramienta directa y ser capaz de
programar en un lenguaje de secuencias de comandos de la herramienta con el fin de escribir y depurar
los guiones que utilizarn las tablas de datos o tablas de palabras clave. Un pequeo nmero de
especialistas en automatizacin puede admitir un mayor nmero de probadores, que entonces no necesitan
aprender a ser programadores de secuencias de comandos (a menos que quieran).

Los archivos de datos (data-driven o basado en palabras clave) incluyen los resultados esperados para
las pruebas. Los resultados reales de cada ensayo tambin necesitan ser almacenados, al menos hasta que
se comparan con los resultados esperados y se registran las diferencias.

Ms informacin sobre impulsado por los datos y secuencias de comandos basado en palabras clave se
puede encontrar en [Fewster y Graham, 1999].

Herramientas de pruebas de rendimiento

Las pruebas de rendimiento se est convirtiendo en una disciplina especializada de su propia. Con las pruebas
funcionales, los tipos de defectos que nosotros estamos buscando la funcionalidad son - El sistema o
componente producir el resultado correcto para entradas dadas? En las pruebas de rendimiento, no nos interesa
normalmente tanto con la correccin funcional, pero con caractersticas de calidad no funcionales. Cuando se
utiliza una herramienta per-rendimiento de pruebas que estamos buscando en el proceso de las transacciones, el
grado de precisin de un clculo dado, los recursos del ordenador que se utiliza para un nivel dado de
transacciones, el tiempo necesario para determinadas operaciones o el nmero de usuarios que pueden usar el
sistema a la vez.

Con el fin de obtener lo mejor de una herramienta de pruebas de rendimiento, es importante entender
lo que la herramienta puede y no puede hacer por usted. Aunque esto es cierto para otros tipos de
herramienta as, hay problemas particulares con las herramientas de pruebas de rendimiento, incluyendo:

el diseo de la carga a ser generado por la herramienta (por ejemplo, entrada aleatoria o de
acuerdo con los perfiles de usuario);

aspectos de temporizacin (por ejemplo, la insercin de retardos para hacer la entrada del usuario simulado ms
realista);

la duracin de la prueba y qu hacer si una prueba se detiene prematuramente;

la reduccin a la ubicacin de un cuello de botella;

exactamente qu aspectos de medir (por ejemplo, nivel de interaccin del usuario o de servidor);

la forma de presentar la informacin recopilada.

herramientas de anlisis esttico

herramientas de anlisis esttico son muy tiles para los desarrolladores, ya que pueden identificar
problemas potenciales en el cdigo antes de que se ejecute el cdigo y que tambin puede ayudar a
comprobar que el cdigo se escribe en los estndares de codificacin.

Cuando se introduce primero una herramienta de anlisis esttico, no puede haber algunos problemas. Por
ejemplo, si la herramienta comprueba el estndar de codificacin actual frente a cdigo escrito hace varios
aos, puede haber una serie de cosas que se encuentran en el cdigo antiguo que no cumplan con la nueva
norma de codificacin de ahora en su lugar. Si el cdigo de edad, ha estado trabajando bien durante aos,
probablemente no es una buena idea para cambiarlo slo para satisfacer el nuevo estndar de codificacin (a
menos que los cambios son necesarios por alguna otra razn). Existe el riesgo de que los cambios para cumplir
con la nueva norma puede tener efectos secundarios involuntarios que pueden no ser arrastrados por las
pruebas de regresin.

herramientas de anlisis estadstico pueden generar un gran nmero de mensajes, por ejemplo,
mediante la bsqueda de la misma cosa cada pocas lneas. Esto puede ser bastante molesto, especialmente si las cosas que se encuentran no se consideran importantes ahora, por ejemplo WARN-Ings en
lugar de defectos potenciales.

El objetivo de la herramienta de anlisis esttico es producir cdigo que ser ms fcil de mantener en
el futuro, por lo que sera una buena idea para implementar mayores stan-nor- sobre nuevo cdigo que
todava est siendo probado, antes de que se libera en el uso, sino para permitir que el cdigo ms antiguo
pueda comprobarse de forma menos estricta. Todava hay un riesgo de que los cambios para ajustarse a la
nueva norma introducir un inesperado efecto secundario, pero hay una probabilidad mucho mayor de
que se encontrar en las pruebas y no hay tiempo para arreglarlo antes de que el sistema se libera.

Un filtro en la salida de. la herramienta de anlisis esttico podra eliminar algunos de los mensajes
menos importantes y hacer los mensajes ms importantes ms posibilidades de ser detectada y se fijaron.

Herramientas de gestin de pruebas

herramientas de gestin de pruebas pueden proporcionar una gran cantidad de informacin til, pero la
informa-cin como la producida por la herramienta no puede estar en la forma que sea ms eficaz dentro
de su propio contexto. Algunos trabajo adicional puede ser necesaria para producir interfaces con otras
herramientas o una hoja de clculo con el fin de asegurar que la informa-cin se comunica de la manera
ms eficaz.

Un informe realizado por una herramienta de gestin de pruebas (ya sea directa o indirectamente a
travs de otra herramienta u hoja de clculo) puede ser un informe muy til en este momento, pero puede

no ser til en tres o seis meses. Es importante controlar la informacin producida para asegurar que es el
ms relevante ahora.

Es importante disponer de un procedimiento de ensayo definido antes de introducir las herramientas de

gestin de ensayo. Si el proceso de prueba est funcionando bien manualmente, a continuacin, una
herramienta de gestin de pruebas puede ayudar a apoyar el proceso y hacerlo ms eficiente. Si usted
adopta una herramienta de gestin de pruebas cuando sus propios procesos de prueba son inmaduros, una
opcin es seguir las normas y procesos que son asumidos por la forma en que la herramienta funciona.
Esto puede ser til; pero no es necesario seguir los procesos especficos del proveedor. El mejor enfoque
consiste en definir sus propios procesos, teniendo en cuenta la herramienta que va a utilizar, y luego
adaptar la herramienta para proporcionar el mayor beneficio para su organizacin.

6.3 La introduccin de una herramienta en AN

- Organizacin

1 Expondrn los principales principios de la introduccin de una herramienta

en una organizacin.

{0}k = 0.015 L{/0}{1}1{/1}

2 Indicar los objetivos de una prueba de concepto o fase de pilotaje para evalua
herramienta
. {0}k = 0.015 L{/0}{1}1{/1}

3
Reconocen que otros factores, adems de simplemente la adquisicin de una
herramienta se requieren

para una buena sujecin de la herramienta. {0}k = 0.015 L{/0}{1}1{/1}

6.3.1 Principios fundamentales

El lugar para empezar a la hora de introducir una herramienta en una organizacin no es con la herramienta es con la organizacin. Para que una herramienta para proporcionar un beneficio, debe coincidir con una
necesidad dentro de la organizacin, y resolver esa necesidad en una forma que es a la vez eficaz y eficiente.
La herramienta debe ayudar a construir sobre las fortalezas de la organizacin y hacer frente a sus debilidades.
La organizacin tiene que estar preparado para los cambios que vendrn con la nueva herramienta. Si las
prcticas de las pruebas actuales no son buenas y la organizacin no est maduro, entonces es generalmente
ms rentable para mejorar las prcticas de prueba en lugar de tratar de encontrar herramientas de apoyo a las
malas prcticas. La automatizacin de caos apenas da el caos ms rpido!

Por supuesto, a veces podemos mejorar nuestros propios procesos en paralelo con la introduccin de
una herramienta de apoyo a esas prcticas y podemos recoger algunas buenas ideas para la mejora de las
formas en que las herramientas de trabajo.Sin embargo, tenga en cuenta que la herramienta no debe tomar
la iniciativa, sino que debe proporcionar el apoyo a lo que su organizacin define.

Los siguientes factores son importantes en la seleccin de una herramienta:

evaluacin de la madurez de la organizacin (por ejemplo, preparacin para el cambio);

identificacin de las reas de la organizacin, donde el apoyo de herramientas ayudar a mejorar

los procesos de prueba;

evaluacin de las herramientas contra requisitos claros y criterios objetivos;

 prueba de concepto para ver si el producto funciona como se desee y cumpla con los requisitos y
objetivos definidos por ella;
Evaluacin del proveedor (formacin, apoyo y otros aspectos comerciales) o red de cdigo abierto
de apoyo;
la identificacin y planificacin de implementacin interna (incluyendo orientacin y tutora para
los nuevos en el uso de la herramienta).

Proyecto Piloto

Una de las maneras de hacer una prueba de concepto-es tener un proyecto piloto como el primero que se
hace con una nueva herramienta. Esto utilizar la herramienta en serio, pero a pequea escala, con el
tiempo suficiente para explorar diferentes formas de utilizar la herramienta. Los objetivos deben ser
establecidos para el piloto con el fin de evaluar si es o no el concepto se ha demostrado, es decir, que la
herramienta puede lograr lo que se necesita en el contexto orga-nizacional actual.

Un proyecto piloto de la herramienta debe esperar encontrarse con problemas - que deben ser resueltos
de manera que puedan ser utilizados por todo el mundo en el futuro. El proyecto piloto debe experimentar
con diferentes formas de utilizar la herramienta. Por ejemplo, diferentes ajustes de una herramienta de
anlisis esttico, diferentes informes de una herramienta de gestin de pruebas, las tcnicas de scripting y
la comparacin de una herramienta de ejecucin de la prueba o diferentes perfiles de carga para una
herramienta de pruebas de rendimiento ent-difieren.

Los objetivos de un proyecto piloto para una nueva herramienta son:

para obtener ms informacin acerca de la herramienta (ms detalle, ms profundidad);

para ver cmo la herramienta encajara con los procesos o documentacin existentes, cmo los que
tendra que cambiar para trabajar bien con la herramienta y cmo utilizar la herramienta para
optimizar los procesos existentes;

para decidir sobre los procedimientos estndar para el uso de la herramienta que funcione para
todos los usuarios potenciales (por ejemplo, las convenciones de nomenclatura, creacin de

bibliotecas, modularidad definir, donde se almacenarn los diferentes elementos, y la forma en que la
propia herramienta se mantendrn);

para evaluar el proyecto piloto respecto a sus objetivos (tienen los beneficios han alcanzado a un
costo razonable?).

6.3.3 Factores de xito

El xito no est garantizado o automtica en la aplicacin de una herramienta de prueba, pero muchas
organizaciones han tenido xito. stos son algunos de los factores que han contribuido al xito:

incremental de puesta en marcha (despus de que el piloto) con el resto de la organizacin;

la adaptacin y mejora de los procesos, testware y artefactos herramienta para conseguir el mejor
ajuste y el equilibrio entre ellos y el uso de la herramienta;

proporcionar la formacin adecuada, orientacin y tutora de nuevos usuarios;

definicin y comunicacin de directrices para el uso de la herramienta, sobre la base de lo

aprendido en el piloto;

la implementacin de un mecanismo de mejora continua como herramienta de uso se extiende a

travs de ms de la organizacin;

control de la utilizacin de la herramienta y los beneficios logrados y adaptar el uso de la

herramienta para tener en cuenta de lo aprendido.

Ms informacin y consejos sobre la seleccin y aplicacin de herramientas se pueden encontrar en

[Fewster y Graham, 1999] y [Dustin et al., 1999].

Repaso Captulo

Vamos a repasar lo que ha aprendido en este captulo.

De la Seccin 6.1, ahora debera ser capaz de clasificar los diferentes tipos de herramientas de prueba de
acuerdo a las actividades del proceso de pruebas que apoyan. Tambin debe reconocer las herramientas que
pueden ayudar a los desarrolladores en sus pruebas (mostradas por "(D)" ms adelante). Adems de la lista de
abajo, hay que reconocer que existen herramientas que apoyan las reas de aplicacin especficas y que las
herramientas de uso general tambin se pueden utilizar para apoyar la prueba. Las herramientas que ahora
debe reconocer son:

Las herramientas que soportan la gestin de las pruebas y exmenes:

-

herramienta de gestin de pruebas;

herramienta de gestin de requisitos;

herramienta de gestin de incidencias;

herramienta de gestin de la configuracin.

Herramientas que soportan pruebas estticas:

-

opinin herramienta de soporte de procesos;

herramienta de anlisis esttico (D);

herramienta de modelado (D).

Herramientas que soportan la especificacin de prueba:

-

herramienta de diseo de la prueba;

prueba de la herramienta de preparacin de datos.

Herramientas que apoyan la ejecucin de pruebas y registro:

-

herramienta de ejecucin de la prueba;

instrumento de prueba y una herramienta de marco de prueba de unidad (D);

comparador de ensayo;

herramienta de medicin de cobertura (D);

herramienta de seguridad.

Las herramientas que apoyan el desempeo y monitoreo:

-

herramienta de anlisis dinmico;

rendimiento en las pruebas, la carga de prueba y herramienta de pruebas de tensin;

herramienta de monitorizacin.

Adems de las herramientas mencionadas, usted debe conocer los trminos del glosario

herramienta de depuracin, conductor, el efecto de la sonda y el trozo.

De la Seccin 6.2, usted debe ser capaz de resumir los posibles beneficios y riesgos potenciales de soporte de
herramientas para probar en general. Usted debe reconocer que algunas herramientas tienen consideraciones
especiales, incluidas las herramientas de ejecucin de pruebas, herramientas per-rendimiento de pruebas,
herramientas de anlisis esttico y herramientas de gestin de prueba. Usted debe conocer los trminos del glosario
de pruebas, ensayos y lenguaje de scripting basado en palabras clave basadas en datos, y las considerar
asociado con herramientas de ejecucin de prueba.

De la Seccin 6.3, usted debe ser capaz de indicar los principales principios de la presen-cin de una
herramienta en una organizacin (por ejemplo, la evaluacin de madurez de la organizacin, requisitos claros y
criterios objetivos, la prueba de concepto, evaluacin de proveedores, orientacin y tutora). Usted debe ser
capaz de indicar los objetivos de una fase de prueba de concepto o de pilotaje para la evaluacin de
herramientas (por ejemplo, aprender acerca de la herramienta, evaluar en forma con las prcticas actuales,
decidir sobre las normas, evaluar los beneficios). Debe RECO-Niza que simplemente la adquisicin de una
herramienta no es el nico factor en el logro de una buena herramienta

apoyo; hay muchos otros factores que son importantes para el xito (por ejemplo, incre-mental de puesta
en marcha, los procesos de adaptacin, capacitacin y entrenamiento, que definen las pautas de uso,

lecciones de aprendizaje y seguimiento de las prestaciones).No hay DEF-defini- especficas para esta
seccin.

PREGUNTAS examen de la muestra

Pregunta 1 Qu herramientas ayudan a soportar pruebas estticas?

a.

herramientas de anlisis esttico y herramientas de ejecucin de pruebas.

b. proceso de revisin de los instrumentos de apoyo, herramientas de anlisis esttico y herramientas de

medicin de la cobertura.

c.

Dinmica herramientas de anlisis y herramientas de modelado.

d. proceso de revisin de los instrumentos de apoyo, herramientas de anlisis esttico y

herramientas de modelado.

Pregunta 2 actividades de prueba que se apoyan en instrumento de prueba o herramientas marco de

pruebas unitarias?

a.

Gestin de pruebas y control.

b.

especificacin de las pruebas y el diseo.

c.

Ejecucin de la prueba y la explotacin forestal.

d.

Rendimiento y la supervisin.

Pregunta 3 Cules son los posibles beneficios del uso de herramientas en general para apoyar las
pruebas?

a.

Mayor calidad de cdigo, la reduccin en el nmero de probadores necesarios, mejores objetivos para
las pruebas.

b. Una mayor capacidad de repeticin de las pruebas, la reduccin en el trabajo repetitivo, la

evaluacin objetiva.

c. Una mayor capacidad de respuesta de los usuarios, la reduccin de los ensayos realizados, los
objetivos no es necesario.

d. Mayor calidad del cdigo, reduccin de papeleo, menos objeciones a las pruebas.

Pregunta 4 Qu es un riesgo potencial en el uso de herramientas para apoyar la prueba?

a. Las expectativas poco realistas, contar con la herramienta que se puede hacer demasiado.

b. la confianza suficiente sobre la herramienta, es decir, dejar de hacer pruebas manuales cuando
una herramienta de ejecucin de la prueba ha sido comprado.

c.

La herramienta puede detectar defectos que no estn all.

d. La herramienta se repetir exactamente lo mismo que lo hizo la vez anterior.

Pregunta 5 Cul de las tcnicas de scripting siguientes son herramientas avanzadas para ejecucin de
pruebas?

a.

Impulsado por los datos y basado en palabras clave

b.

Basada en datos y la captura impulsada

c.

Captura de guiado y de ojo de cerradura impulsada

d.

Reproduccin impulsado y guiado por palabra clave

Pregunta 6 Cul de los siguientes no se llevara a cabo como parte de la seleccin de una herramienta para
una organizacin?

a. Evaluar la madurez de la organizacin, fortalezas y debilidades.

b. Estirar la herramienta a tantos usuarios como sea posible dentro de la organizacin.

c.

Evaluar las caractersticas de la herramienta respecto a los requisitos claros y criterios

objetivos.

d. Identificar los requisitos internos para la orientacin y tutora en el uso de la herramienta.

Pregunta 7 Cul de los siguientes es un objetivo para una prueba de concepto o fase piloto para la evaluacin de
herramientas?

a.

Decidir qu herramienta para adquirir.

b. Decidir sobre los principales objetivos y requisitos para este tipo de herramienta.
c.

Evaluar el vendedor herramienta incluida la formacin, el apoyo y los aspectos comerciales.

d. Decidir sobre los procedimientos estndar para el uso, el manejo, el almacenamiento y el

mantenimiento de la herramienta y los activos de prueba.

Simulacin

En el examen real, usted tendr 60 minutos para trabajar a travs de 40 preguntas de

aproximadamente la misma mezcla de dificultad y la distribucin del programa de estudios,
como se muestra en el siguiente examen de prueba. Despus de haber tomado este examen de
prueba, verifique sus respuestas con la clave de respuestas.

Pregunta 1 Qu es una caracterstica clave de las tcnicas de prueba basados en la

especificacin?

a. Las pruebas se derivan de informacin acerca de cmo se construye el software.

b. Las pruebas se derivan de modelos (formal o informal) que especifican el problema que
hay que resolver por

el software o sus componentes.

c. Las pruebas se derivar en base a las habilidades y

experiencia del probador.

d. Las pruebas se derivan de la extensin de la cobertura

de los elementos estructurales del sistema o componentes.

Pregunta 2 Un conjunto de pruebas exhaustiva incluira:

a. Todas las combinaciones de valores de entrada y precondiciones.

b. Todas las combinaciones de valores de entrada y valores de salida.

c. Todos los pares de valor de entrada y precondiciones.

d.

Todos los estados y las transiciones de estado.

Pregunta 3 Qu afirmacin acerca de las pruebas es cierto?

a.

La prueba se inicia tan pronto como sea posible en la vida

Ciclo de curado

b. La prueba se inici despus de que el cdigo est escrito de manera que

tenemos un sistema con el que trabajar.

c. La prueba se realiza econmicamente ms al final de

el ciclo de vida.

d. Testing slo se puede hacer por una prueba independiente

Instituto.

Pregunta 4 Para un procedimiento de prueba que se est comprobando las modificaciones de

los clientes en una base de datos, que dos pasos seran la prioridad ms baja si no tenemos
tiempo para ejecutar todos los pasos?

1 Abrir base de datos y confirman cliente existente

2 Cambiar el estado civil de los clientes de soltero a casado

3 Cambiar nombre de la calle de cliente a partir de Parques Camino a Park Road

4 Lmite de crdito del cliente el cambio de 500 a 750

5 Sustituir el primer nombre del cliente con exactamente el

mismo nombre de pila

6 Cierre el registro del cliente y cerrar el

a.

Las pruebas 1 y 4

b.

Las pruebas 2 y 3

c.

Las pruebas 5 y 6

d.

Las pruebas 3 y 5

Pregunta 5 Tenga en cuenta la siguiente lista de cualquiera de los riesgos del producto o
proyecto:

yo Un clculo incorrecto de las tasas podra

shortchange la organizacin.

II Un vendedor puede fallar para entregar un componente del sistema en el

tiempo.

IIIA defecto podra permitir a los hackers privilegios administrativos.

IVA brecha de habilidades podra ocurrir en una nueva tecnologa utilizada en el sistema.

VA proceso de priorizacin de defectos podra sobrecargar el equipo de desarrollo.

{0}Cul de las siguientes afirmaciones es cierta?{/0} {1} {/1}

a. I es principalmente un riesgo del producto y II, III, IV y V

son sobre todo los riesgos del proyecto.

b. II y V son los principales riesgos de los productos y I, III y

V son los principales riesgos del proyecto.

c. I y III son principalmente riesgos de los productos, mientras II, IV

y V son los principales riesgos del proyecto.

d. Enfermo y V son los principales riesgos de los productos, mientras que I, II

y IV son los principales riesgos del proyecto.

Pregunta 6 Considere las siguientes afirmaciones acerca de las pruebas de regresin:

yo

Pueden ser automatizados til si estn bien diseados.

II Ellos son los mismos que los ensayos de confirmacin (re-tests).

III Son una forma de reducir el riesgo de un cambio que tiene un efecto adverso en otras partes del sistema.

IVThey solamente son efectivos si automatizado.

Qu par de afirmaciones es verdadera?

a.

I y II

b.

I y III

c.

II y III

d.

II y IV

Pregunta 7 Cul de las siguientes podra ser utilizado para evaluar la cobertura alcanzada por (caja
blanca) tcnicas de prueba basados en la estructura?

V Resultados de las decisiones ejercidas

W particiones ejercidas

x Los lmites ejercidas

Y Condiciones o mltiples condiciones ejercido

Z declaraciones ejercidas

a.

V, Wory

b.

WXorY

c.

V, YorZ

d.

W, XorZ

Pregunta 8 de la opinin de la parte siguiente de un informe de incidente.

1

Pongo cualquier artculo en la cesta de la compra.

Pongo cualquier elemento (diferente) en el carrito de compras.

Me quito el primer elemento de la cesta de la compra, pero dejo el segundo artculo en el carrito.

Hacer clic en el botn <Pedido>.

5 Espero que el sistema muestre la primera pantalla de pago.En su lugar, nos muestra un mensaje de
error emergente, 'No hay artculos en la cesta. Haga clic en <Ok> para continuar con la compra.'.

Hago clic en <Ok>.

7 Espero que el sistema para volver a la ventana principal para que yo contine aadiendo y
eliminando los artculos en el carro.En lugar de ello, el navegador termina.

8 El fracaso se describe en los pasos 5 y 7 se produjo en cada uno de tres intentos de realizar los
pasos 1,2,3,4 y 6.

Supongamos que hay otra informacin narrativa se incluye en el informe. Cul de los siguientes aspectos
importantes de un buen informe de incidente no se encuentra en este informe de incidente?

a.

Los pasos para reproducir el fallo.

b.

El resumen.

c.

La comprobacin de la intermitencia.

d.

El uso de un tono de objetivo.

Pregunta 9 Cul de los siguientes son los beneficios y que son riesgos del uso de herramientas de apoyo a la
prueba?

La excesiva dependencia de la herramienta

Mayor consistencia y repetibilidad

Evaluacin objetiva

Expectativas poco realistas

5
Subestimar el esfuerzo necesario para mantener los activos de prueba generados por la
herramienta

La facilidad de acceso a la informacin sobre los ensayos o pruebas

El trabajo repetitivo se reduce

a.

benefits and Riesgos: 1,2 y 5

b.

Beneficios: 1,2,3 y 7, Riesgos: 4,5 y 6

c.

benefits and Riesgos: 1,4 y 5

d.

benefits and Riesgos: 1,4 y 7

Pregunta 10 Cul de las siguientes pruebas objetivas anima?

a.

Pruebas Unitarias

b.

Prueba del sistema

c.

Las pruebas independientes

d.

Pruebas destructivas

Pregunta 11 De las siguientes afirmaciones sobre la revisin de especificaciones, que afirmacin es cierta?

a. Los comentarios no son generalmente rentables como las reuniones son mucho tiempo y
requieren una preparacin y seguimiento.

b.

No hay necesidad de preparar o dar seguimiento a comentarios.

c.

Los comentarios deben ser controladas por el autor.

d. Los comentarios son una prueba esttica temprana rentable en el sistema.

Pregunta 12 Considere la siguiente lista de actividades del proceso de prueba:

Anlisis I y II diseo de las actividades de cierre de prueba
IIIEvaluating criterios de salida y presentacin de informes

IVPlanning y control

V Aplicacin y ejecucin

Cul de los siguientes lugares estos en su secuencia lgica?

a.

I, II, III, IV y V

b.

IV, I, V, III y II.

c.

IV, I, V, II y III.

d.

I, IV, V HI y II.

Pregunta 13 Objetivos de la prueba varan entre los proyectos y por lo tanto deben ser
estipuladas en el plan de pruebas. Cul de las siguientes objetivos de la prueba podra entrar en
conflicto con la mentalidad adecuada probador?

a. Demostrar que el sistema funciona antes de enviarlo.

b.

Encontrar el mayor nmero posible de defectos.

c.

Reducir el nivel general de riesgo del producto.

d. Prevenir los defectos a travs de la participacin temprana.

Pregunta 14 actividades de prueba que se apoyan en herramientas de preparacin de los datos

de prueba?

a.

gestin y control de prueba

b.

especificacin de las pruebas y el diseo

c.

Ejecucin de la prueba y la explotacin forestal

d.

Rendimiento y monitorizacin

Pregunta 15 Si usted est volando con un boleto en clase econmica, existe la posibilidad de
que puede ser actualizado a la clase de negocios, sobre todo si se tiene una tarjeta de oro en el
programa de viajero frecuente de la aerolnea. Si usted no posee una tarjeta de oro, hay una
posibilidad de que usted conseguir 'golpeado' fuera de la lnea area si esto est lleno y que el
proceso de registro de retraso. Esto se muestra en la Figura 7.1. Tenga en cuenta que cada caja
(es decir, declaracin) ha sido numerada.

Tres ensayos ya han llevado a cabo:

Prueba 1: titular de la tarjeta de oro que se ve actualizado a

Clase Business

Prueba 2: titular de la tarjeta no de oro que se queda en la economa

Prueba 3: Una persona que recibe un golpe desde el vuelo

Qu pruebas adicionales seran necesarios para lograr una cobertura del 100% de decisin?

a. Un titular de la tarjeta de oro que se queda en la economa y una

titular de la tarjeta no de oro que se ve actualizado a

Clase Business

b. Un titular de la tarjeta de oro y un soporte de la tarjeta ni oro

que se actualizan tanto a la clase ejecutiva.

c. Un titular de la tarjeta de oro y un soporte de la tarjeta ni oro

que tanto se quedan en clase econmica.

d. Un titular de la tarjeta de oro que se actualiza a negocio

clase y un titular de tarjeta no el oro que se aloja en

clase de economia.

Pregunta 16 Considere los siguientes tipos de herramientas:

herramientas de gestin de la prueba: V

W X herramientas de anlisis de herramientas de modelado esttico

Las herramientas de anlisis dinmico Y.

herramientas de pruebas de rendimiento Z

Cul de los siguientes de estas herramientas es ms probable que sea utilizado por los
desarrolladores?

a.

W, Xandy

b.

VYandZ

c.

V, WandZ

d.

X, YandZ

pregunta 17

Qu es una condicin de la prueba?

a. Una entrada, resultado esperado, condicin previa y postcondition

b. Los pasos a seguir para obtener el sistema a un punto dado

c.

Algo que puede ser probado

d. Un estado especfico del software, por ejemplo, antes de una prueba

se puede ejecutar

Pregunta 18 Cul de las siguientes es la diferencia ms importante entre el enfoque basado en la

mtrica y el enfoque basado en la estimacin de expertos para probar?

a. El enfoque basado en la mtrica es ms preciso

que el enfoque basado en el experto.

b. El enfoque basado en mtricas utiliza clculos

a partir de datos histricos, mientras que el experto de base

enfoque se basa en la sabidura del equipo.

c. El enfoque basado en la mtrica puede ser utilizado para verificar

una estimacin creado usando el experto de base

enfoque, pero no viceversa.

d. El enfoque basado en el experto tarda ms que el

basada en mtricas de enfoque.

Pregunta 19 Si la temperatura cae por debajo de 18 grados, la calefaccin se conecta. Cuando

la temperatura alcanza 21 grados, la calefaccin se desconecta. Cul es el conjunto mnimo de
valores de entrada de prueba para cubrir todas las particiones de equivalencia vlidos?

a.

15,19 y 25 grados

b.

17,18,20 y 21 grados

c.

18,20 y 22 grados

d.

16 y 26 grados

Pregunta 20 Cul de las siguientes afirmaciones sobre las pruebas funcionales es cierto?

a. Ensayos estructurales es ms importante que

pruebas funcionales, ya que aborda el cdigo.

b. Las pruebas funcionales es til durante toda la vida

ciclo y puede ser aplicada por los analistas de negocios,

probadores, desarrolladores y usuarios.

c. Las pruebas funcionales es ms poderoso que las pruebas estticas

ya que en realidad ejecuta el sistema y ver qu pasa.

d.

La inspeccin es una forma de pruebas funcionales.

Pregunta 21 Cul es el propsito de las pruebas de confirmacin?

a Para confirmar la confianza de los usuarios que el sistema de

responda a sus necesidades de negocio.

b. Para confirmar que un defecto se ha fijado correctamente.

c. Para confirmar que no hay cambios inesperados han sido

introducido o no cubierto, como resultado de cambios

hizo

d. Para confirmar que la lgica detallada de un componente de

se ajusta a su especificacin.

La pregunta 22 que se requieren factores de xito para un buen soporte de la herramienta

dentro de una organizacin?

a. La adquisicin de la mejor herramienta y la garanta de que todos

probadores utilizan.

b. procesos de adaptacin para encajar con el uso de la herramienta

y monitorear el uso de herramientas y beneficios.

c. El establecimiento de objetivos ambiciosos para los beneficios de la herramienta y

plazos agresivos para lograrlos.

d.

de

La adopcin de prcticas de otras organizaciones de xito y asegurar que formas iniciales

el uso de la herramienta se mantienen.

Pregunta 23 Cul de las siguientes opciones describe mejor las pruebas de integracin?

a. Pruebas realizadas para exponer las fallas en el

interfaces y en la interaccin entre

componentes integrados.

b. Las pruebas para verificar que un componente est preparado para

e integracin.

c. Pruebas para verificar que el entorno de prueba puede ser

integrado con el producto.

d. La integracin de conjuntos de pruebas de software automatizadas con

El fino marco de estas pantallas

Pregunta 24 Segn el Glosario ISTQB, depuracin:

a.

Es parte del proceso de prueba fundamental.

b. Incluye la reparacin de la causa de un fallo.

c. Consiste en aadir intencionadamente defectos conocidos.
d.

Sigue los pasos de un procedimiento de prueba.

Pregunta 25 Cul de los siguientes podra ser una causa de un defecto en el software financiero
en el que se calcula una tasa de inters incorrecto?

a. La insuficiencia de fondos disponibles para pagar la tasa de inters calculada.

b. La insuficiencia de los clculos de inters compuesto

se incluyeron.

c. Una formacin insuficiente fue dado a los desarrolladores

sobre normas de clculo de inters compuesto.

d. calculadoras inexactos se utilizaron para calcular la

RESULTADOS PREVISTOS

Pregunta 26 Supongamos tarifas postales para cartas 'ligeros' son:

$ 0,25 hasta 10 gramos; $ 0,35 hasta 50 gramos; $ 0,45 hasta 75 gramos;
$ 0,55 hasta 100 gramos.

Qu entradas de prueba (en gramos) se pueden seleccionar mediante anlisis de valores

lmite?
a {0}9:19{/0} {0}-22).{/0}

b.

32.

c.

10.

d.

32.

Pregunta 27 Considere la siguiente tabla de decisiones.

Teniendo en cuenta esta tabla de decisin, cul es el resultado esperado para los siguientes casos
de prueba?

TCI: A -old de 26 aos en el negocio, pero con violacines o accidentes en su historial de

manejo

TC2: Un turista de edad 62-ao- con un historial de manejo limpio

a. TCI: No suministre coche; coche de alimentacin con: TC2

de pagar prima.

b. TCI: vehculo de suministro de pago de prima; TC2:

coche de alimentacin sin necesidad de pagar prima.

c. TCI: No suministre coche; Suministro coche sin: TC2

de pagar prima.

d. TCI: vehculo de suministro de pago de prima; TC2:

No suministrar coche.

pregunta 28

Cul es la prueba exploratoria?

a. El proceso de anticipar o adivinar donde

se pueden producir defectos.

b. Un enfoque sistemtico para la identificacin especfica

clases equivalentes de entrada.

c. La prueba llevada a cabo por un ingeniero colegiado.

d. diseo de la prueba concurrente, ejecucin de la prueba, la prueba

la tala y el aprendizaje.

Pregunta 29 Qu significa si un conjunto de pruebas ha alcanzado una cobertura del 90%

afirmacin?

a. 9 de cada 10 resultados de la decisin han sido

ejercido por este conjunto de pruebas.

b. 9 de cada 10 declaraciones han sido ejercidas por esta

conjunto de pruebas.

c. 9 de cada 10 pruebas han llevado a cabo en este conjunto de

software

d. 9 de cada 10 requisitos enunciados acerca de la

software son correctos.

Pregunta 30 Un plan de prueba est escrito especficamente para describir un nivel de

pruebas, donde el objetivo principal es el establecimiento

confianza en el sistema.Cul de los siguientes es un nombre probable de este documento?

a.

plan de pruebas maestro

b.

plan de pruebas del sistema

c.

plan de pruebas de aceptacin

d.

- Plan del Proyecto

Pregunta 31 Requisito 24.3. A 'franqueo Asistente' calcular la cantidad de franqueo insuficiente

para cartas y paquetes pequeos de hasta 1 kilogramo de peso. Las entradas son: el tipo de
elemento (carta, libro u otro paquete) y el peso en gramos. Cul de las siguientes ajustarse a los
contenidos requeridos de un caso de prueba?

a. Prueba de los tres tipos de artculo al poste y tres pesos diferentes [Req 24.3]

b. Prueba 1: carta, 10 gramos, franqueo 0,25. Prueba 2: libro, de 500 gramos, el franqueo
1,00. Prueba 3: paquete, 999 gramos, franqueo 2,53 [Req 24.3]

c. Prueba 1: carta, 10 gramos a Blgica. Prueba 2: Libro de 500 gramos a EE.UU.. Prueba 3:
paquete, 999 gramos a Sudfrica [Req 24.3]

d. Prueba 1: carta de 10 gramos, Blgica, franqueo 0,25. Prueba 2: paquete de 999 gramos a
Sudfrica, franqueo 2,53

Pregunta 32 Cul es la mejor descripcin del anlisis esttico?

a.

El anlisis de los programas de proceso por lotes

b.

La revisin de los planes de prueba

c. El anlisis de cdigo de programa u otros artefactos de software

d.

El uso de las pruebas de recuadro negro

Pregunta ejecucin de la prueba 33 del sistema en un proyecto est previsto durante ocho semanas.
Despus de una semana de pruebas, un probador sugiere que el objetivo de la prueba se indica en el
plan de pruebas de "encontrar tantos defectos como sea posible durante la prueba del sistema" podra
estar ms estrechamente cumplido mediante la reorientacin del esfuerzo de la prueba segn la cual
principio de la prueba?

a.

Imposibilidad de pruebas exhaustivas.

b.

Importancia de las primeras pruebas.

c.

La ausencia de errores falacia.

d.

agrupacin defecto.

Pregunta 34 Tenga en cuenta las siguientes actividades que podran estar relacionados con la gestin de
configuracin:

yo

Identificar y documentar las caractersticas de un elemento de prueba

II Controlar los cambios en las caractersticas de un elemento de prueba

III Comprobar un elemento de prueba para detectar defectos introducidos por un cambio

IVRecord e informe del estado de cambios para probar artculos

V Confirmar que cambia a un elemento de prueba fijado un defecto Cul de las siguientes afirmaciones es
verdadera?

a.

Slo I es una tarea de gestin de configuracin.

b.

Todas son tareas de gestin de configuracin.

c.

I, II y III son las tareas de gestin de configuracin.

d.

I, II y IV son las tareas de gestin de configuracin.

Pregunta 35 Considere el siguiente diagrama de transicin de estado.

Teniendo en cuenta este diagrama, que cubre caso de prueba por debajo de cada transicin vlida?
a.

SS - S1 - S2 - S4 - S1 - S3 - ES

b.

SS - S1 - S2 - S3 - S4 - S3 - S4 - ES

c.

SS - S1 - S2 - S4 - S1 - S3 - S4 - S1 - S3 - ES

d.

SS - S1 - S4 - S2 - S1 - S3 - ES

Pregunta 36 Un plan de prueba incluy las siguientes clusulas entre los criterios de salida:

La prueba del sistema continuar hasta que todos los riesgos significativos de productos han sido
cubiertos en la medida especificada en el documento de anlisis de riesgo del producto.

La prueba del sistema deber continuar hasta que no hay defectos deber-fix se mantienen en contra de
cualquier producto significativa los riesgos modific especfica en el documento de anlisis de riesgo del
producto.

Durante la ejecucin de pruebas, el equipo de prueba detecta defectos 430 necesidad de reparacin de averas antes
de su liberacin y todos los defectos debe-fix se resuelven. Despus de la liberacin, los clientes encuentran 212
nuevos defectos, ninguno de los cuales fueron detectados durante las pruebas. Esto significa que slo el 67% de los
defectos importantes se encontraron antes de la liberacin, un porcentaje que est muy por debajo de la media de su
sector. Se le pedir que encontrar la causa de la gran cantidad de fallas en el campo. Tenga en cuenta la siguiente
lista de explicaciones:

yo

No todas las pruebas previstas para los riesgos significativos de productos fueron ejecutados.

II La organizacin tiene expectativas poco realistas de que el porcentaje de defectos que las pruebas se
pueden encontrar.

III Una cuestin de control de versin ha dado como resultado la liberacin de una versin del
software que se utiliz durante las primeras pruebas.

IVThe anlisis de riesgos producto no ha identificado todos los riesgos importantes desde el
punto de vista del cliente.

V El anlisis de riesgo del producto no se ha actualizado durante el proyecto de nueva

informacin estuviera disponible.

Cul de las siguientes afirmaciones Indicar las explicaciones son posibles causas de raz?

a. II, III y IV son posibles explicaciones, sino yo y

V no son posibles.

b.

Los cinco son posibles explicaciones.

c.

I, IV y V son posibles explicaciones, pero

II y
III no son posibles.

d. Ill, IV y V son posibles explicaciones, sino yo y

II no son posibles.

Pregunta 37 Cul es el ms importante factor para el desempeo exitoso de comentarios?

a. Un escriba por separado durante la reunin de la tala

b.

participantes capacitados y lderes de opinin

c. La disponibilidad de herramientas para apoyar la revisin

proceso

d.

Un plan de prueba revisado

Pregunta 38 Considere el siguiente declaraciones acerca de las pruebas de mantenimiento:

yo

Requiere tanto repeticin de la prueba y la prueba de regresin y

puede requerir nuevas pruebas adicionales.

II Se est haciendo pruebas para demostrar que tan fcil ser mantener

si

III Es difcil alcance y, por tanto, necesita cuidado

riesgos y anlisis de impacto.

IVIT no tiene por qu hacerse con correccin de errores de emergencia. Cul de las
afirmaciones son ciertas?

a.

I y III

b.

I y IV

c.

II y III

d.

II y IV

Pregunta 39 Qu dos tcnicas de ensayo basadas en las especificaciones estn ms

estrechamente relacionados entre s?

a. Las tablas de decisin y las pruebas de transicin de estados

b. particin de equivalencia y de transicin de estados

Pruebas

c. Las tablas de decisin y anlisis de valores lmite

d.

Particionamiento equivalencia y anlisis de valores lmite

Pregunta 40 Cul de los siguientes es Una ventaja de las pruebas independientes?

a. probadores independientes no tienen que perder tiempo
la comunicacin con el equipo del proyecto.

b. Los programadores pueden dejar de preocuparse por la calidad

de su trabajo y se centran en la produccin de ms cdigo.

c. Los otros en un proyecto pueden presionar a los probadores independientes para acelerar
las pruebas en el
al final del programa.

d.

probadores independientes veces cuestionan la

supuestos detrs de requisitos, diseos y

Implementations

RESPUESTAS A MUESTREAN preguntas del examen

Esta seccin contiene las respuestas y los objetivos de aprendizaje de las preguntas de la muestra en cada
captulo y para el papel maqueta completa en el Captulo 7.
Si tiene cualquiera de las preguntas incorrectas o si no estaban seguros de la respuesta, entonces el objetivo de
aprendizaje que le indica qu parte del programa de estudios para volver a con el fin de ayudarle a entender por qu
la respuesta correcta es la correcta. Los objetivos aprender-ing se enumeran al principio de cada seccin. Por

ejemplo, si usted consigui la pregunta 4 del Captulo 1 equivocada, y luego ir a la Seccin 1.2 y leer el primer
objetivo de aprender-ing. A continuacin, vuelva a leer la parte del captulo que se ocupa de ese tema.