TECNICAS DE PRUEBA
INTRODUCCIÓN.
La prueba de software es un
conjunto de herramientas, tecnicas y métodos que hacen a la excelencia del
desempeño de un programa, asi como tambien la mejor publicidad que una empresa
dedicada a la producción de software pueda tener. Las tecnicas para encontrar
problemas en un programa son extensamente variadas y van desde el uso del
ingenio por parte del personal de prueba hasta herramientas automatizadas que
ayudan a aliviar el peso y el costo de tiempo de esta actividad. Pero de nada
serviría conocer todas las tecnicas de prueba de software, si un programa
carece de documentación, el código es confuso, o no se han seguido pasos para
la planificación y desarrollo del software, ya que seria como buscar una aguja
en un pajar.Es por eso que en este trabajo monográfico nos hemos volcado a
definir no solo las herramientas, tecnicas y metodos de prueba sino que también
a todo el trabajo previo de control de calidad en el desarrollo de software, ya
que sabemos que mucho mejor que encontrar y solucionar un problema es prevenir
que no ocurra.
¿
QUE ES EL CONTROL DE CALIDAD DEL SOFTWARE ?
El control de calidad del
software incluye desde el monitoreo de desarrollo de
procesos haciendo respetar los
estandares y procedimientos concordados
asegurandose un buen seguimiento
de programa y la deteccion y correccion de
errores. El control de calidad
del software esta orientado a la prevención.
¿
QUE ES PRUEBA DE SOFTWARE ?
La prueba de software involucra
las operaciones del sistema bajo condiciones
controladas y evaluando los
resultados.
Las condiciones controladas
pueden ser normales o anormales. La prueba
puede intencionalmente esforzar
al programa y producir errores en las
respuestas para determinar si los
sucesos ocurren cuando no tendrían que
ocurrir o cuando los hechos no
suceden cuando deberían suceder.
La prueba de software esta
detectada a la deteccion.
La mayoría de las grandes
organizaciones asumen la responsabilidad del
control de calidad y prueba de
software a tal medida que en la producción se
incluyen desarrolladores de
sistemas (analistas , programadores) y un grupo
dedicado a la prueba de software
para que estos grupos antes mencionados
trabajen en conjunto cumpliendo
el control de calidad (prevención) y la prueba
de software (deteccion) logrando
una tarea exitosa.
Fallos
mas recientes causados por software con bugs en sistemas de computación :
• En enero del 2000 se registro la mayor cantidad de
fallas de sistemas, en
organizaciones europeas, de todos
los tiempos al sufrir las consecuencias
del efecto Y2K (Y2K bug).
Como por ejemplo el sistema de
trenes se vio afectado al no reconocer la
fecha 01-01-00 y los trenes no
salieron o salieron a destiempo, de la misma
manera se produjeron problemas de
comunicación en correos electrónicos en
aquellos sistemas que utilizaban
agenda de pedidos o informes que se
enviaban
automáticamente en cada fecha.
• Otro problema fue causado en una escuela publica de
los Estados Unidos
donde alrededor de 100.000
estudiantes solicitaron la inscripción y el sistema
no contemplaba el manejo de tal
cantidad de inscriptos causando errores en
las tarjetas de reportes de los
alumnos inclusive inscriptos en otros años y en
el sistema de registros de materias.
Esta escuela decidió reinstalar
el sistema viejo de hace 25 años hasta que los
bugs del sistema hayan sido
corregidos.
• En octubre de 1999 un modulo de la nave espacial para
el estudio de Marte
valuado en 125 Millones de
dólares fue perdido en el espacio debido a un
simple error de conversión de
datos. Fue ciertamente determinado que el
software de la nave utilizaba
datos en el sistema métrico ingles , el error fue
causado cuando se ejecutaban
procesos concurrentes donde uno de ellos
establecía comunicación para el
descenso en el sistema métrico ingles y el otro
proceso calculaba los parámetros
de órbita con otro tipo de unidades, entonces
estos dos procesos utilizaron el
mismo procedimiento para la conversión de
datos, aunque no se ha determinado
que modulo del sistema causaron el bug.
• Un bug en le programa de soporte de una red comercial
de alta velocidad
afecto 70.000 negocios de
clientes por el periodo de 8 idas en agosto de 1999,
entre los afectados fue la
empresa Electronic Trading System Futures
Exchange , la cual tuvo que
suspender sus tareas. Esto fue causado per el
repentino paro del programa de
soporte en este sistema Non Stop.
¿
Porque es tan difícil para el desarrollo de sistemas incluir seriamente un
control de calidad y una buena prueba de errores ?
Resolver los problemas cuando se
presentan es un proceso fácilmente
determinado, pero prevenir
problemas es una tarea muy minuciosa y muy difícil de
determinar.
En la antigua china existía una
familia de curadores , uno de los integrantes de esta familia siendo ya muy
reconocido fue contratado por uno de los grandes Señores del territorio como su
medico personal. Una noche mientras cenaban el Señor le pregunta al medico cual
de sus otros familiares era tan poderoso como el, entonces el medico comento;
Yo atiendo a personas con grandes males, casi moribundos llegan a mi con cierta
fe, y algunas veces logro curarlos, y mi nombre es reconocido en casi todo el
territorio. Mi hermano mayor cura las enfermedades cuando recién comienzan a
hacer raíz en el cuerpo y su nombre es reconocido en los vecindarios, mi
hermano menor cura enfermedades antes de que aparezcan y solo es conocido por
la familia y su nombre no ha salido de la casa.
Es decir, arreglar o corregir un
problema o bug después que sale a la luz es
una tarea relativamente sencilla,
ya que se conoce el foco del problema, el
inconveniente esta en corregir un
error que no esta visible o no ha sucedido todavía.
¿Cuales
son las razones para que un programa contenga bugs?
• Poca o falta de comunicación entre diferentes
aplicaciones.(Requerimientos
de las aplicaciones.)
• Complejidad del software. Causa dificultad en la
reutilización de código y
generalmente requiere personas
con experiencia en desarrollo de sofware
modernos como por ejemplo en
sistemas cliente servidor, aplicaciones
distribuidas, comunicación de
datos, manejo de enormes bases de datos
relacionales y un gran manejo de
tecnicas orientadas a objetos. A veces estos
conocimientos también pueden
causar mas errores de los que corrigen.
• Errores de programacion. Los programadores son uno de
los principales
factores en la causa de errores o
bugs.
• Requerimiento de cambio en el sistema. El rediseño y
la replanificación
causan efectos en otros proyectos
que trabajan en conjunto o a partir de
resultados del sistema
modificado.
Estos procesos cooperativos
generan mas complejidad en las diferentes
pruebas y en el control y
generalmente el entusiasmo de los desarrolladores
del sistema se ve afectado al
tener que realizar actividades diferentes o no
correspondientes a su labor.
Como por ejemplo el de los
ingenieros al tener que hacer un análisis funcional
a partir de su planificación,
todo esto influye y atenta con la integridad del
programa y genera riesgos de una
gran cantidad de errores.
• Presiones de tiempos. Una buena planificación y un
buen análisis con sus
respectivos controles de calidad
y prueba se ven afectados por un lapso corto
de tiempo para que esto sea
completo. La falta de tiempo generalmente
conlleva a no considerar u omitir
ciertas fases de prueba y control.
• El ego (aspecto psicológico del personal).A veces la
situación y el contexto
lleva a que la gente diga:
- No hay problema
- Es muy fácil.
- Puedo terminar esto en pocas
horas.
-No habrá inconvenientes en
adaptar ese viejo código.
en vez de decir:
-Eso es muy complejo.
-Nos llevara a cometer varios errores.
-No puedo estimar cuanto tiempo
me llevara este trabajo.
-No se como readaptar ese código.
Son muchas las ocasiones en las
que un ¨ No hay problema ¨ genera un bug.
• Pobre documentación del código. Es difícil poder
modificar código cuya
documentación es escasa o esta
mal escrita.
En muchas organizaciones los
directivos no incentivan a los programadores a
realizar una buena documentación
e incluso a no darle importancia a la
entendibilidad del código, como
también el hecho de incentivar demasiada
seguridad en la documentación y
escritura del código. Lo que fue difícil de
escribir podría llegar a ser
difícil de leer y aun mas complicado de modificarlo.
• Herramientas de desarrollo de software. Herramientas
visuales , librerías de
clases, compiladores,
herramientas de escritura, etc., a menudo introducen
código extra con pobre
documentación lo cual genera un bug en el programa
en cuestion.
¿
Cómo un nuevo software con control de calidad puede ser introducido en una
organizacion existente ?
Depende del tamaño de la
organizacion y de los riesgos involucrados.
Para grandes organizaciones con
altos niveles de riesgos en términos de
capital y vida evolutiva de la
empresa un serio manejo de control de calidad es
absolutamente necesario por lo
que un nuevo software debe garantizar una muy
buena seguridad y cumplir con lo
formalizado.
En organizaciones donde los
riesgos son menores la implementación con
control de calidad puede ir
disminuyendo su intensidad con el tiempo sin que la
organizacion con el tiempo. Esta
falta de procesos con control de calidad podría ser
equilibrada con mayor
productividad eliminando niveles de burocracia.
Para pequeños proyectos el
control de calidad de procesos puede ser
enfocado a partes especificas del
sistema dependiendo del tipo de organizacion o de
clientes, aunque es importante
asegurar una adecuada comunicación entre
desarrolladores y personal
ocupado de la prueba de programa asegurando también
una retroalimentación del sistema
optimizando la relación cliente empresa.
En todo los casos, lo mas valioso
es el esfuerzo en la prueba de software y un
control de calidad del sistema
garantizando buena especificación y cumpliendo con
las expectativas pero
generalmente el desempeño y los requerimientos de la empresa
principalmente el factor tiempo
hacen que las pruebas de software y controles sean
limitadas.
¿
Que es verificación y validación ?
La verificación típicamente
incluye por parte de los desarrolladores la revisión
de los planes, del código, de los
requerimientos, de la documentación y las
especificaciones y posteriormente
una reunión con los usuarios para evaluar dichos
documentos. Esto puede ser hecho
con listas de chequeos, listas de problemas,
walkthrough.
La validación típicamente incluye
las pruebas del software y comienza después
que la verificación este
completa.
Este proceso de verificación y
validación da lugar al termino ¨IV&V¨
Independent verification and validation.
¿Que es walkthrough ?
Es una reunión informal entre
analistas y usuarios para la evaluación de propuestas informacionales,
generalmente es requerida una pequeña preparación de documentos.
¿Que es la inspección
?
La inspección es una reunión
formal luego del walkthrough, generalmente
incluye personal de diferentes
sectores esencialmente analistas, programadores, y
personal de prueba (testers)
donde acuerdan con los usuarios los metodos de
seguridad prueba a llevar a cabo.
A menudo en estas reuniones se incluye un
moderador el cual representa a la
empresa y que da a conocer al usuario una lista de
operaciones de metodos de prueba
y controles de calidad en las cuales el usuario
debe optar definiendo el mismo el
nivel de calidad.
¿Que
tipos de prueba de programa deben ser considerados ?
• Caja negra.
No esta basada en el conocimiento del código o diseño interno,
determina la funcionalidad del
sistema.
•Caja blanca. Esta basada en la lógica interna de la aplicacion y
el código. Hace
una cobertura de declaraciones
del código, ramas, caminos y condiciones.
•Unidad de testeo
o prueba. Es la escala mas pequeña de la
prueba, esta
basada en la funcionalidad de los
módulos del programa, como funciones,
procedimientos, módulos de clase,
etc. En ciertos sistemas también se
verifican o se prueban los
drivers y el diseño de la arquitectura.
•Integración
incremental. Cuando nuevas
funciones son ingresadas al sistema
se hace la prueba basándose en la
funcionalidad, la dependencia con otros
módulos y la integración con el
programa completo.
•Prueba de
integración. Se basa en las
pruebas de conexiones y
comunicaciones entre diferentes
módulos. Es esencial en sistemas de
cliente_servidor o red.
•Prueba
funcional. La caja negra hace la prueba
funcional de los
requerimientos de la aplicacion y
generalmente es realizada por el programador,
en cambio, la prueba funcional es
realizada por los testers.
•Prueba de
sistema. Es una prueba de caja negra
incluyendo todos los
componentes del sistema desde el
hardware a la documentación.
•Prueba de fin a
fin. Es similar a la prueba de sistema pero esta
involucra la
interacción con otros hardwares,
bases de datos y redes.
•Prueba de
sanidad. Determina si la nueva versión
de un software esta bien
realizada y si necesita un nuevo
esfuerzo en la prueba de software. Por
ejemplo la nueva versión de un
programa cumple con casi todos los requisitos
pero destruye la base de datos al
leerla, por lo tanto se dice que este software
no esta en una condición sana.
•Prueba de
regresión. Es una nueva revisión en las
pruebas del programa
luego de que este haya sufrido
algún cambio o por apuros de tiempo o la
modificación fue en el ambiente
en que se desenvuelve. Actualmente
aparecieron herramientas
automatizadas que hacen que este tipo de pruebas
no lleve demasiado tiempo.
•Prueba de
aceptación. Es la prueba final basada en
las especificaciones del
usuario o basada en el uso del
programa por el usuario final luego de un
periodo de tiempo.
•Prueba de carga. Esta basada en las aplicaciones bajo cargas pesadas ,
generalmente usadas en sitios web
y en servidores con gran cantidad de datos
donde se determina en cuales
puntos existen degradaciones del sistema.
•Prueba de estrés. Es una prueba de carga y perfomance basada en la
funcionalidad del sistema bajo
cargas pesadas , un gran numero de
repeticiones, manejo de grandes
datos y demasiadas preguntas a bases de
datos grandes.
•Prueba de
perfomance. Es una de las pruebas finales y
sirve para definir los
requerimientos y la calidad del
software, en base a las pruebas de carga y
estrés. Incluye entrevistas con
el usuario y programador.
•Prueba de
instalación y desinstalación.
Determina la eficiencia de los
procesos que instalan y
desinstalan las aplicaciones del programa.
•Prueba de
recuperacion. Es la prueba que
evalúa que tan bien se recupera el
sistema luego de bloqueos ,
fallas del hardware u otros problemas
catastróficos.
•Prueba de
seguridad. Evalúa que tan bien el sistema
se protege contra
accesos , internos o externos, no
autorizados, esta prueba requiere
sofisticadas tecnicas y
herramientas.
•Prueba de
compatibilidad. Evalúa el desempeño
del software en diferentes
hardwares , sistemas operativos ,
redes, etc.
•Prueba de
exploración. Es una prueba
informal del software que no esta
basada en ningún plan o caja de
prueba y a menudo los testers aprenden del
programa al explorar todas las
aplicaciones posibles.
•Prueba de
anuncio. Es similar a la prueba de
exploración pero los testers
deben tener suficiente noción
sobre el funcionamiento del programa antes de
comenzar esta prueba. Incluye
reunión con analistas y programadores.
•Prueba de
usuario. Determina si el usuario se
desenvuelve satisfactoriamente
con el programa.
•Prueba de
comparación. En esta prueba se
comparan los pro y los contra del
programa con los programas
creados con la competencia.
•Prueba alfa. Es la prueba cuando la aplicacion esta cerca de la
entrega al
usuario. Se hacen pequeños
cambios generalmente en el diseño de
interfaces. Esta prueba es hecha
por usuarios.
•Prueba beta. Es la búsqueda de bugs en el programa completo.
Generalmente es hecha por
usuarios.
•Prueba de
mutación. Esta prueba esta basada en la
introducción deliberada
de diferentes códigos externos al
programa (bugs) para reexaminar si estos
bugs pueden ser detectados.
Requiere gran disponibilidad de recursos de
computación.
¿Cuales son los cinco
problemas mas comunes en el desarrollo de
procesos. ?
•Pobre definición de requerimientos. Es normal que se
comience a trabajar en
base a requerimientos que estan
en bruto, si no hay una buena prueba de
requerimientos con el usuario se
crearan problemas.
•Planificación irreal. Planifica sobre supuestos para
acortar el tiempo de
desarrollo, los problemas serán
inevitables.
•Pruebas inadecuadas. Es imprescindible asegurarse que
el programa funciona
antes de la entrega al usuario.
•Falta de comunicación. Si desarrolladores de
programas, clientes o usuarios y
directivos del proyecto tienen
una mala o escasa comunicación los problemas
estarán garantizados.
•Carencia de rasgos. Definir nuevos rasgos una vez que
el programa se haya
terminado es muy común y genera
problemas. Se deben definir las
características del programa.
¿Cuales son las cinco
soluciones para los problemas de desarrollo?
•Requerimientos sólidos. Deben ser claros, completos,
detallados, probables, posibles, cohesivos y coherentes. Son imprescindibles
los prototipos para que se cumplan estas condiciones.
•Planificación real. Se debe ser sincero y dedicar el
tiempo adecuado a la planificación. Esto agilizara el diseño, la prueba y dara
tiempo a posibles cambios.
•Pruebas adecuadas. Las pruebas deben ser tempranas y
adecuadas durante el desarrollo pudiendo establecer puntos de prueba
(checkpoints) en caso de cambios, y pruebas finales una vez concluido el
programa.
•Comunicación continua. Con la tecnología existente hoy
en dia, un buen profesional debe poder utilizar todas las herramientas
posibles, desde teléfonos celulares, e-mail, hasta reuniones formales e
informales en los diferentes ámbitos que conciernan al desarrollo del software.
•Seguimiento de rasgos. Es deseable realizar una buena
preparación de las características a seguir por el programa. Interfaces,
salidas, equipos etc. Una buena prototipación de las entradas y salidas es lo
ideal para defenderse de posibles cambios y potenciales problemas.
¿Cómo
realizar un buen código?
Un Buen código es aquel que
funciona sin bugs, además debe ser legible y mantenible, se debe ajustar a los
estandares de la organizacion para que todos los desarrolladores del sistema
manejen y entiendan las mismas herramientas y mecanismos en la codificación.
A continuación definiremos reglas
que la mayoría de las organizaciones consideran importantes para evitar
problemas en la mayoría de los lenguajes de programacion mas usados como el C,
C++.
•Minimizar el uso de variables globales.
•Nombres descriptivos de funciones, variables, módulos,
objetos y metodos.
•Minimizar el tamaño de funciones, metodos y
procedimientos. Acercamiento al caso ideal de no exceder las 50 líneas.
•Descripciones deben ser cortas y claras para no
confundir la lectura del código.
•Organizacion de los metodos, una buena disposición del
código hará que futuros cambios sean posibles.
•Uso generoso de espacios en blanco.
•Es importante que cada línea de código no supere los
70 caracteres.
•Una sentencia por línea.
•Es fundamental que el grupo de desarrolladores respete
el mismo estilo de
codificación.
•Toda aplicacion debe ser documentada no importa lo
pequeña sea dicha
aplicacion.
¿Cómo pueden las
nuevas herramientas automatizadas de prueba simplificar el proceso de deteccion
de errores ?
Una de las herramientas
automatizadas que a logrado ser muy popular en el
entorno del diseño de software,
por su simplicidad y, además, por el ultimo gran
disgusto en cuestion a problemas
de software, el efecto Y2K, es la herramienta
RECORD-PLAYBACK, al ejecutar
dicha aplicacion antes de hacer correr el programa
a probar, se activa la opción
récord, el tester navega por las diferentes aplicaciones
del software, menús, cuadros de
dialogo, plantillas, tablas, botones, y los resultados
son grabados en forma de texto
para un reporte, y en el lenguaje de la herramienta en
un archivo de grabado, cuando
nuevas aplicaciones son agregadas al software o son
modificadas las aplicaciones
actuales, la opción playback de la herramienta navega
automáticamente por el programa y
luego emite un reporte de resultados y
operaciones aun no testeadas.
Otras herramientas automatizadas
existentes en el mercado son:
•Analizador de código. Es una especie de depurador
externo que
examina además de las sentencias,
los caminos e hilos del programa.
•Analizador de cobertura. Solamente prueba las ramas y
caminos de
todas las funciones que trabajan,
internamente o externamente, con el
programa.
•Analizador de memoria. Evalúa si las aplicaciones no
exceden los limites
de memoria en los peores casos, o
situaciones criticas.
•Perfomance de carga. En sistemas cliente servidor,
esfuerza al
programa para que trabaje con
cargas pesadas y en situaciones
extremas.
•Analizador de sitios WEB. Examina los enlaces y las
aplicaciones en
los diferentes nodos y en el
servidor.
•Reporte de bugs. Trabaja en conjunto con analizadores
de código y de
cobertura, haciendo un reporte de
las partes de códigos no examinadas
o confusas.
•Reporte de configuración. Hace un reporte de los
requerimientos del
programa en cuestion a hardware y
los parámetros mínimos que se
deben cumplir para que el
software pueda trabajar al máximo.
•Reporte de desempeño. Hace un reporte del nivel de
desempeño,
aplicacion por aplicacion, del
programa en el hardware instalado.
Estudio
de tecnicas de prueba basicas.
Hoy en dia, la mayor parte de las
tecnicas de prueba se basan en las tecnicas
aparecidas en los años 70,
dandole fundamental importancia los avances
tecnologicos, los avances en
lenguajes de programacion y la gran variedad de tipos
de software, las pruebas de caja
negra y caja blanca han tomado un lugar muy
importante en el desarrollo de
sistemas de cualquier tipo, tanto que sin dichas
pruebas un sistema desarrollado
careceria de garantias y credibilidad en sus
resultados.
Prueba
de caja negra
Esta prueba implica una variada
seleccion de los datos de prueba asi como
una buena interpretacion de los
resultados para determinar el nivel de optimizacion de
la funcionalidad del sistema.
Se ha determinado con diferentes
estudios estadisticos, que el software no
debe ser probado por el creador o
grupo de creadores del sistema ya que el extenso
conocimiento de la estructura
interna del programa limita la variedad de datos
probados o el encaminamiento de
las pruebas es hacia ciertos rasgos del programa
olvidando otras partes del
software poco valoradas por su simpleza en la creacion.
Segun C. Kaner en su libro
¨Testing Computer Software¨ de 1993, el aspecto
humano es esencial en la prueba
de caja negra aplicando factibles sucesos de la vida
real a la prueba, errores de
tipeo, trabajar en aplicaciones equivocadas creyendo
trabajar en la aplicacion
deseada, etc., pero sucede que los programadores han
pasado tanto tiempo en la
creacion del sistema y al ser la prueba de caja negra una
de las mas tempranas sus hechos
factibles de la vida real estan entre el ¨begin¨ y el
¨end¨ de cada aplicacion.
La prueba de caja negra ha hecho
que cada organizacion dedicada al
desarrollo de software contemple
dentro de ella un departamento especial dedicado a
las pruebas.
El principal objetivo es
determinar la funcionalidad del software y parte de tratar
al programa como si fuera una
funcion matematica, estudiando si las respuestas o
salidas son ¨codominio¨ de los
datos entrantes ¨dominio¨. La prueba de caja negra
tiene otras metas, determinar la
eficiencia del programa desde el desempeño en el
equipo, el tiempo de retardo de
las salidas hasta el nivel de recuperacion del sistema
luego de fallas o caidas sean
estas producidas por manejo incorrecto de datos,
equipo, o producidas externamente
como cortes de energia.
La prueba de caja negra debe
cubrir el espectro entero de sucesos factibles,
de esto se debe ocupar el
departamento de prueba, pero nunca se sabe si se
han cubierto todos los casos o
gran parte de ellos, no olvidemos que los testers
pertenecen a la organizacion por
lo que la prueba de caja negra no termina una
vez que salio del laboratorio.
La prueba con intervencion del
usuario es un pequeño periodo de tiempo en el
cual el usuario bajo el
asesoramiento de testers, se desenvuelve en el software
y examina la operabilidad de los
datos que el maneja. El usuario dara la
puntada final en la cuestion de
datos de prueba. Esta parte de la prueba no
podría hacerse sin que el usuario
haya tenido previo contacto con los
prototipos del sistema, y para
los testers una efectiva interacción con
herramientas CASE.
Prueba
de caja blanca
Para esta prueba se consideran
tres importantes puntos.
I) Conocer el desarrollo interno del programa,
determinante en el análisis de coherencia y consistencia del código.
II) Considerar las reglas predefinidas por cada algoritmo.
III) Comparar el desarrollo del programa en su código con
la documentación pertinente.
La primera parte de esta prueba
es el análisis estático.
• Análisis estático Manual
• Inspección : Determina si el código esta completo y
correcto,
como también las
especificaciones.
• Walkthrough : Interrelación informal entre testers,
creadores y
usuarios del sistema.
• Análisis estático Automático
• Verificación estática : Compara los valores generados
por el
programa con los rangos de
valores predefinidos haciendo una
descripción del funcionamiento de
los procedimientos en términos
booleanos determinando los puntos
de falla.
• Ejecución simbólica : Hace un seguimiento de la
comunicación
entre funciones, módulos,
aplicaciones, luego de que todas las
partes hayan sido verificadas por
separado.
La segunda parte de esta es el
análisis dinámico. Para esto se cuenta con
diferentes tipo de herramientas.
• Análisis de cobertura : Examina las extensiones del
código, haciendo
una caja blanca por modulo.
• Trafico : Sigue todos los caminos de comunicación
entre módulos
guardando los valores de las
variables en cada uno de ellos.
• Simulador : Simula partes del sistema para el cual el
hardware no esta
habilitado.
• Sintonía : Testea los recursos utilizados durante la
ejecución del
programa.
• Prueba de certeza : Examina las construcciones
lógicas del programa.
Generación
de datos de prueba.
La seleccion de datos de prueba
es una de las mas importantes disciplinas
dentro de la caja blanca.
Usualmente se generaban en forma aleatoria y hacían un
acercamiento a una sofisticada
prueba estructural determinando el desempeño de los
módulos con dichos valores.
A partir del gran colapso causado
por el efecto Y2K han aparecido en el
mercado herramientas
automatizadas que generan datos de prueba y que, además
examinan paso a paso la ejecución
del programa.
¿ Que cosas hacen a
un buen ingeniero en pruebas y control de
calidad ?
El ingeniero debe tener una
actitud de probar para romper, o sea, la habilidad
de conseguir el punto de vista
del cliente y un buen análisis de detalle para encontrar
errores que no se ven a simple
vista. Aunque no parezca importante, la actitud de
trabajo en equipo, la diplomacia
con usuarios , desarrolladores y ejecutivos dará a
este la noción de los focos de
prueba mas importantes cuando el tiempo de prueba es
extremadamente limitado y los
riesgos de un mal control son altos.
Un buen ingeniero dedicado a esta
disciplina debe ser paciente y tener la
habilidad de saber encontrar los
problemas y las omisiones.
Pasos
para el desarrollo de pruebas :
- Obtener los requerimientos en
forma clara.
- Obtener planificación de
diseño.
- Determinar funcionalidad.
- Identificar aplicaciones de
alto riesgo o con prioridad de prueba.
- Determinar metodos de prueba.
- Determinar contexto de la
prueba.
- Obtener datos de prueba.
- Estimar tiempo de prueba.
- Clasificar errores del
programa.
- Documentar errores del
programa.
- Redactar los casos de prueba
que encontraron fallas.
- Aprobar una revisión en la
prueba.
- Evaluar resultados en reportes.
- Buscar bugs.
- Volver a probar si es
necesario.
- Actualizar el plan de prueba.
No hay comentarios:
Publicar un comentario