Ingenieria Del Software II


INVESTIGACION DE
INGENIERIA DEL SOFTWARE II TEMAS DE LA UNIDAD
3
[Escriba aquí una descripción breve del documento. Normalmente, una

descripción breve es un resumen corto del contenido del documento. Escriba
aquí una descripción breve del documento. Normalmente, una descripción
breve es un resumen corto del contenido del documento.]
INGENIERIA DEL SOFTWARE II 2011
 TIPOS DE PRUEBA DE SOFTWARE

 Introducción.
 La prueba de software es un conjunto de herramientas,
 Técnicas y métodos que hacen a la excelencia del desempeño
 De un programa, así como también la mejor publicidad que
 Una empresa dedicada a la producción de software pueda
 Tener. Las técnicas 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 técnicas 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
 Sería 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, técnicas y métodos
 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.
 ¿Qué es el control de calidad del software?
 El control de calidad del software incluye desde el monitoreo de desarrollo
de
 Procesos haciendo respetar los estándares y procedimientos concordados
 Asegurándose un buen seguimiento de programa y la detección y
corrección de
 Errores. El control de calidad del software está orientado a la prevención.
 ¿Que es prueba de software?
EQUIPO INVESTIGACION TERCERA UNIDAD “PRUEBAS DE SFTWARE” 5° “D” T.I.C

5
 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 detección.
 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 (detección) logrando una tarea exitosa.
 Fallos más recientes causados por software con bugs en sistemas de
computación:
 En enero del 2000 se registró 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 pública de los Estados Unidos
5
 Donde alrededor de 100.000 estudiantes solicitaron la inscripción y el
sistema
 No contemplaba el manejo de tal cantidad de inscriptos causando errores
ellas 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 módulo 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 inglés, 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 inglés 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 el 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 por 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
5
 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 médico personal. Una noche
 Mientras cenaban el Señor le pregunta al médico cuál de sus otros
familiares era tan poderoso como el,
 Entonces el medico comento; Yo atiendo a personas con grandes males,
casi moribundos llegan a mí 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 está visible o no ha sucedido
todavía.
 ¿Cuáles 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 software
 Modernos como por ejemplo en sistemas cliente servidor, aplicaciones
 Distribuidas, comunicación de datos, manejo de enormes bases de datos

5
 Relacionales y un gran manejo de técnicas orientadas a objetos. A veces
estos
 Conocimientos también pueden causar más errores de los que corrigen.
 Errores de programación. 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 re planificación
 Causan efectos en otros proyectos que trabajan en conjunto o a partir de
 Resultados del sistema modificado.
 Estos procesos cooperativos generan más 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.
5
 −No puedo estimar cuanto tiempo me llevara este trabajo.
 −No sé cómo 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 está 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 más 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 cuestión.
 ¿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¨
 Independen verification and validación.
5
 ¿Qué tipos de prueba de programa deben ser considerados?
 Caja negra. No está basada en el conocimiento del código o diseño interno,
 determina la funcionalidad del sistema.
 Caja blanca. Está basada en la lógica interna de la aplicación y el código.
Hace
 una cobertura de declaraciones del código, ramas, caminos y condiciones.
 Unidad de testeo o prueba. Es la escala más 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 aplicación 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 hardware, bases de datos y redes.
 Prueba de sanidad. Determina si la nueva versión de un software está 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
5
 no está 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. Está 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 performance basada en la
 funcionalidad del sistema bajo cargas pesadas, un gran número de
 repeticiones, manejo de grandes datos y demasiadas preguntas a bases de
 datos grandes.
 Prueba de performance. 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 recuperación. 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
5
 sofisticadas técnicas y herramientas.
 Prueba de compatibilidad. Evalúa el desempeño del software en diferentes
 hardware, 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 aplicación está 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 está 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.
 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.
 Estudio de técnicas de prueba básicas.
5
 Hoy en día, la mayor parte de las técnicas de prueba se basan en las
técnicas
 aparecidas en los años 70, dándole fundamental importancia los avances
 tecnológicos, los avances en lenguajes de programación 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 carecería de garantías y credibilidad en
sus
 resultados.
 Prueba de caja negra
 Esta prueba implica una variada selección de los datos de prueba así como
 una buena interpretación de los resultados para determinar el nivel de
optimización de
 la funcionalidad del sistema.
 Se ha determinado con diferentes estudios estadísticos, 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
creación.
 Según 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

5
 real a la prueba, errores de tipeo, trabajar en aplicaciones equivocadas
creyendo
 trabajar en la aplicación deseada, etc., pero sucede que los programadores
han
 pasado tanto tiempo en la creación del sistema y al ser la prueba de caja
negra una
 de las más tempranas sus hechos factibles de la vida real están entre el
¨begin¨ y el
 ¨end¨ de cada aplicación.
 La prueba de caja negra ha hecho que cada organización 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 función matemática, estudiando si las
respuestas o
 salidas son ¨condominio¨ 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 recuperación
del sistema
 luego de fallas o caídas sean estas producidas por manejo incorrecto de
datos,
 equipo, o producidas externamente como cortes de energía.
 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

5
 han cubierto todos los casos o gran parte de ellos, no olvidemos que los
testers
 pertenecen a la organización por lo que la prueba de caja negra no termina
una
 vez que salió del laboratorio.
 La prueba con intervención 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 tolerabilidad de los datos que el maneja. El usuario dará la
 puntada final en la cuestión 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.
 Conocer el desarrollo interno del programa, determinante en el análisis de
coherencia y consistencia del
 código.
 Considerar las reglas predefinidas por cada algoritmo.
 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 está 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
5
 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 selección de datos de prueba es una de las más 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.
 ¿Qué 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
5
 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 más 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 métodos 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.
 ¿Cómo se define un plan de prueba ?
− Titulo
− Identificación, números de versión, creador, fecha de creación.
5
− Tabla de contenidos.
− Reportes de reuniones.
− Reportes de requerimientos.
− Reportes de documentación.
− Análisis de riesgos.
− Prioridades y focos de prueba.
− Límites. (tiempo, riesgos, etc.)
− Reporte de datos de prueba.
− Reporte de resultados.
− Reporte de aplicaciones conjuntas al programa.
− Informe de herramientas automatizadas.
− Determinación de la sanidad del programa.
− Personal implicado.
− Reportes relevantes. (Licencias, clasificaciones, métodos, etc.)
− Apéndices, glosario, cronología.
 CASOS DE PRUEBA
 En la ingeniería del software, los casos de PICO o Test Case son un

conjunto de condiciones o variables bajo las cuáles el analista determinará
si el requisito de una aplicación es parcial o completamente satisfactorio.
 Se pueden realizar muchos casos de prueba para determinar que un

requisito es completamente satisfactorio. Con el propósito de comprobar
que todos los requisitos de una aplicación son revisados, debe haber al
menos un caso de prueba para cada requisito a menos que un requisito
tenga requisitos secundarios. En ese caso, cada requisito secundario
deberá tener por lo menos un caso de prueba. Algunas metodologías como
RUP recomiendan el crear por lo menos dos casos de prueba para cada

5
requisito. Uno de ellos debe realizar la prueba positiva de los requisitos y el
otro debe realizar la prueba negativa.
 Si la aplicación es creada sin requisitos formales, entonces los casos de

prueba se escriben basados en la operación normal de programas de una
clase similar.
 Lo que caracteriza un escrito formal de caso de prueba es que hay una

entrada conocida y una salida esperada, los cuales son formulados antes
de que se ejecute la prueba. La entrada conocida debe probar una
precondición y la salida esperada debe probar una pos condición.
 Bajo circunstancias especiales, podría haber la necesidad de ejecutar la

prueba, producir resultados, y luego un equipo de expertos evaluaría si los
resultados se pueden considerar como "correctos". Esto sucede a menudo
en la determinación del número del rendimiento de productos nuevos. La
primera prueba se toma como línea base para los subsecuentes ciclos de
pruebas/lanzamiento del producto.
 Los casos de prueba escritos, incluyen una descripción de la funcionalidad

que se probará, la cual es tomada ya sea de los requisitos o de los casos
de uso, y la preparación requerida para asegurarse de que la prueba pueda
ser dirigida.
 Los casos de prueba escritos se recogen generalmente en una suite de

pruebas.
 Las variaciones de los casos de prueba son comúnmente utilizadas en

pruebas de aceptación. La prueba de aceptación es realizada por un grupo
de usuarios finales o los clientes del sistema, para asegurarse que el
sistema desarrollado cumple sus requisitos. La prueba de aceptación de
usuario se distingue generalmente por la incorporación de un trayecto feliz
o casos de prueba positivos.
5
 Estructura de los casos de prueba
 Formalmente, los casos de prueba escritos consisten principalmente en tres

partes con subdivisiones:
 Introducción/visión general contiene información general acerca de los
Casos de Prueba.
− Identificador es un identificador único para futuras referencias, por
ejemplo, mientras se describe un defecto encontrado.
− Caso de prueba dueño/creador es el nombre del analista o
diseñador de pruebas, quien ha desarrollado pruebas o es
responsable de su desarrollo.
− Versión la actual definición del caso de prueba.
− Nombre el caso de prueba debe ser un título entendible por
personas, para la fácil comprensión del propósito del caso de prueba
y su campo de aplicación.
− Identificador de requerimientos el cual está incluido por el caso de
prueba. También aquí puede ser identificador de casos de uso o
especificación funcional.
− Propósito contiene una breve descripción del propósito de la
prueba, y la funcionalidad que chequea.
− Dependencias
 Actividades de los casos de prueba
− Ambiente de prueba/configuración contiene información acerca de
la configuración del hardware o software en el cuál se ejecutará el
caso de prueba.
− Inicialización describe acciones, que deben ser ejecutadas antes de
que los casos de prueba se hayan inicializado. Por ejemplo,
debemos abrir algún archivo.
− Finalización describe acciones, que deben ser ejecutadas después
de realizado el caso de prueba. Por ejemplo si el caso de prueba

5
estropea la base de datos, el analista debe restaurarla antes de que
otro caso de prueba sea ejecutado.
− Acciones pasos a realizar para completar la prueba.
− Descripción de los datos de entrada
 Resultados
− Resultados esperados contiene una descripción de lo que el
analista debería ver tras haber completado todos los pasos de la
prueba
− Resultados reales contienen una breve descripción de lo que el
analista encuentra después de que los pasos de prueba se hayan
completado. Esto se sustituye a menudo con un Correcto/Fallido. Si
un caso de prueba falla, frecuentemente la referencia al defecto
implicado se debe enumerar en esta columna.
HERRAMIENTAS PARA PRUEBAS DE SOFTWARE
 kSETT
Tabla 7.12: kSETT.

Clase de Gestión de pruebas. Gestión y seguimiento de
herramienta casos de pruebas.
Organización Software SETT Corporation.
http://www.softsett.com/

5
Descripción kSETT soluciona el problema de mantener un
gran volumen de pruebas, seguimiento y
reporte de resultados de pruebas manuales y
automáticas para todos los miembros del
equipo y gerencia.
kSETT proporciona una solución Web

detallada para problemas cotidianos de crear,
manejar, seguir y ejecutar casos de prueba.
Usando un estándar HTML para la interfaz y
los informes en línea el kSETT proporcionan
una intefaz amigable al usuario.
Plataforma Solución Hosted
 rth
Tabla 7.13: rth.

Clase de Gestión de pruebas. Gestión de
herramienta pruebas/requerimientos - seguimiento
de defectos
(Freeware)
Organizació RTH project.
n https://sourceforge.net/projects/rth/
Descripción Requerimientos: almacena registros o
archivos de requerimientos bajo control
de versiones (upload documentos o
inserción de registros). Links al
requerimiento, a subrequerimientos o
link a requerimientos a probar. Cerrar o
abrir requerimientos. Notificaciones
por e-mail cuando un requerimiento
cambia. Vista en tabla o vista en árbol
5
de requerimientos.
Pruebas: almacenamiento de casos de

prueba o documentación de soporte
bajo control de versiones. Capacidad
de atar pruebas a los requisitos y de
definir cobertura. Asignar las pruebas a
usuarios y al progreso de seguimiento,
de la creación o de la automatización
de las pruebas.
Resultado de las pruebas: atar todos los

resultados de la prueba a Release,
Build, y Test Set. Almacenar los planes
de prueba bajo control de la versión.
Defectos: atar defectos a otros

defectos. Asignar un defecto a un
Desarrollador o a un Probador.
Adicionar notas a un defecto. Mostrar
el historial de bugs. Notificaciones por
e-mail de cambios en los defectos.
rth es diseñado para ser simple y correr

en cualquier sistema. La disposición y
la configuración son simples y
funciona en los servidores de Linux y
de Windows.
Plataforma Windows y Linux.
 QaTraq
Tabla 7.14: QaTraq.

Clase de Gestión de pruebas. Herramienta de
herramienta gestión de casos de prueba.
(Freeware)
Organizació testmanagement.com
n http://www.testmanagement.com/
Descripción QaTraq es un sistema de gestión de
casos de prueba, con capacidad de
realizar reportes y seguimiento de los
resultados de las pruebas. QaTraq está
disponible como Open Source

5
Software.
Plataforma Windows, Linux y Solaris.
 TestDirector
Tabla 7.15: TestDirector.

Clase de Gestión de pruebas. Herramienta de
herramienta gestión de pruebas automatizada.
Organizació Mercury Interactive.
n http://www.mercuryinteractive.com/
Descripción Gestiona y automatiza el proceso
entero de QA.
Plataforma MS Windows.
 QADirector®#circledR;
Tabla: QADirector®#circledR;.
Clase de Herramienta de gestión de pruebas.
herramienta
Organizació Compuware Corporation
n www.compuware.com/qacenter
Descripción QADirector®#circledR; es una
herramienta de gestión de procesos de
pruebas base-Windows que es parte de
QACenterTM de Compuware de la
familia de productos de pruebas para
aplicaciones. Provee a los encargados
de la aplicación y del sistema, a los
desarrolladores y de los grupos de
trabajo de QA un solo punto del control
para manejar todas las fases de
pruebas. QADirector integra la gestión
de pruebas con las pruebas
automatizadas para proporcionar un
framework que maneja el proceso de
5
pruebas entero, planeación y diseño,
ejecución y análisis. QADirector
también permite hacer el mejor uso de
los artefactos existentes en las pruebas
(planes de prueba, casos, scripts), de
las metodologías y de las herramientas
de prueba de aplicaciones.
Plataforma Windows.
 T-Plan Professional
Tabla 7.17: T-Plan Professional.

Clase de Herramienta de gestión de pruebas.
herramienta
Organizació T-Plan.
n www.t-plan.co.uk
Descripción T-Plan permite que se maneje cada
aspecto del proceso de pruebas,
proporcionando un acercamiento
consistente y estructurado.
Proporcionando orden, estructura y
visibilidad a través del ciclo de vida de
desarrollo, desde la planeación a
ejecución.
Plataforma Windows.

5

5

Ingenieria Del Software II

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ingenieria Del Software II

Uploaded by

Copyright:

Available Formats



[Escriba aquí una descripción breve del documento. Normalmente, una

 TIPOS DE PRUEBA DE SOFTWARE

EQUIPO INVESTIGACION TERCERA UNIDAD “PRUEBAS DE SFTWARE” 5° “D” T.I.C

EQUIPO INVESTIGACION TERCERA UNIDAD “PRUEBAS DE SFTWARE” 5° “D” T.I.C

EQUIPO INVESTIGACION TERCERA UNIDAD “PRUEBAS DE SFTWARE” 5° “D” T.I.C

EQUIPO INVESTIGACION TERCERA UNIDAD “PRUEBAS DE SFTWARE” 5° “D” T.I.C

 En la ingeniería del software, los casos de PICO o Test Case son un

 Se pueden realizar muchos casos de prueba para determinar que un

EQUIPO INVESTIGACION TERCERA UNIDAD “PRUEBAS DE SFTWARE” 5° “D” T.I.C

 Si la aplicación es creada sin requisitos formales, entonces los casos de

 Lo que caracteriza un escrito formal de caso de prueba es que hay una

 Bajo circunstancias especiales, podría haber la necesidad de ejecutar la

 Los casos de prueba escritos, incluyen una descripción de la funcionalidad

 Los casos de prueba escritos se recogen generalmente en una suite de

 Las variaciones de los casos de prueba son comúnmente utilizadas en

 Formalmente, los casos de prueba escritos consisten principalmente en tres

EQUIPO INVESTIGACION TERCERA UNIDAD “PRUEBAS DE SFTWARE” 5° “D” T.I.C

HERRAMIENTAS PARA PRUEBAS DE SOFTWARE

Tabla 7.12: kSETT.

EQUIPO INVESTIGACION TERCERA UNIDAD “PRUEBAS DE SFTWARE” 5° “D” T.I.C

kSETT proporciona una solución Web

Plataforma Solución Hosted

Tabla 7.13: rth.

Pruebas: almacenamiento de casos de

Resultado de las pruebas: atar todos los

Defectos: atar defectos a otros

rth es diseñado para ser simple y correr

Tabla 7.14: QaTraq.

EQUIPO INVESTIGACION TERCERA UNIDAD “PRUEBAS DE SFTWARE” 5° “D” T.I.C

Tabla 7.15: TestDirector.

Tabla 7.17: T-Plan Professional.

EQUIPO INVESTIGACION TERCERA UNIDAD “PRUEBAS DE SFTWARE” 5° “D” T.I.C

EQUIPO INVESTIGACION TERCERA UNIDAD “PRUEBAS DE SFTWARE” 5° “D” T.I.C

You might also like