0% encontró este documento útil (0 votos)
49 vistas12 páginas

Tipos y Proceso de Pruebas de Software

El documento describe diferentes tipos y procesos de pruebas de software. Explica que las pruebas funcionales se enfocan en verificar los casos de uso y reglas de negocio, mientras que las pruebas no funcionales verifican requisitos como compatibilidad, seguridad y rendimiento. También describe los niveles de prueba, como las pruebas unitarias, de integración y de regresión. Finalmente, explica los modelos de prueba como el modelo en V y el modelo iterativo-incremental.

Cargado por

Rafael Romero
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
49 vistas12 páginas

Tipos y Proceso de Pruebas de Software

El documento describe diferentes tipos y procesos de pruebas de software. Explica que las pruebas funcionales se enfocan en verificar los casos de uso y reglas de negocio, mientras que las pruebas no funcionales verifican requisitos como compatibilidad, seguridad y rendimiento. También describe los niveles de prueba, como las pruebas unitarias, de integración y de regresión. Finalmente, explica los modelos de prueba como el modelo en V y el modelo iterativo-incremental.

Cargado por

Rafael Romero
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd

Pruebas Funcionales: Se enfocan en los requisitos funcionales como casos de uso y reglas de

negocio, su finalidad es verificar la apropiada aceptación de datos, Verificar el procesamiento,


recuperación y la implementación de las reglas del negocio

Se ejecutan con cada caso de uso o flujo de caso de uso usando datos validos e inválidos.

Unitarias – Humo - regresión – integración.

Pruebas no Funcionales: es la verificación de un requisito que especifica criterios que pueden


usarse para juzgar la operación de un sistema (requisitos no funcionales).

Compatibilidad – seguridad – stress- usabilidad

Pruebas Unitarias: asegura que cada unidad funcione correcta y eficientemente por separado.
Verifica que el código hace lo que tiene que hacer.

Pruebas de Integración: se enfocan en las interacciones entre los componentes y los sistemas,
verifica que los cambios no interfirieron en el funcionamiento de las interfaces, componentes o
sistemas existentes

Pruebas de regresión: volver a probar un programa previamente probado, después de algunas


modificaciones para asegurarse que no haya errores debido a los cambios realizados.

Pruebas de Humo: Permite detectar problemas que por lo regular no son detectados en las
pruebas normales, las pruebas de humo no son exhaustivas, pero van de extremo a extremo.

Error: El hecho de equivocarse

Defecto: Error visualizado en el código (sin ejecutarlo)

Falla: Cuando el sistema falla debido al defecto (en tiempo de ejecución o producción)

Caso de prueba o test case: Un conjunto de valores de entrada, precondiciones de ejecución,


resultados esperados y postcondiciones de ejecución, desarrollados para un objetivo particular de
condición de prueba, tal como para ejercer una ruta de un programa en particular para verificar
el cumplimiento de un requisito específico

Test plan: documento de recopilación de todos los casos de prueba que se deben ejecutar y el
orden que deben seguir.

Principios de prueba (7):

 efectuar una prueba donde no existen defectos no significan que estos no existen, sino
que la prueba no pudo detectarlos.
 NO existe una prueba que cubra todas las necesidades y variables del cliente
 Se realizan al inicio de vida de los productos
 Agruparlas por grupo ayudara a detectar el mismo tipo de defecto más rápido
 Deben actualizarse periódicamente para detectar nuevos tipos de errores
 Se efectúan dependiendo del funcionamiento del software
 El producto final debe de cumplir con las expectativas del usuario.

Proceso de Pruebas: Contempla 5 elementos principales que describen el ciclo de vida de un


producto:

 Planificación y Control: define objetivos y cumplir metas establecidas como: mejorar la


calidad del producto, identificar defectos, facilitar información para la toma de decisiones
evitar la aparición de defectos.
 Análisis y diseño de Pruebas: Transforma los objetivos en tareas que debemos hacer, por
ejemplo: revisar la base de pruebas, requisitos e informes de análisis de riesgo también se
diseñan y ordenan los casos de prueba se diseña la configuración del entorno de pruebas
 Ejecución: Se especifican los procedimientos, se verifica que el entorno de pruebas haya
sido correctamente configurado, implementar los casos de prueba finalmente se registran
los resultados de ejecución
 Evaluación de Criterios de Salida: Compara la ejecución de las pruebas con los objetivos
que definimos previamente. Elaborar un resumen de las pruebas para los clientes y equipo
de trabajo.
 Actividades de Cierre: se recopilan los resultados de las pruebas terminadas, comprobar
los documentos que han sido entregados, cuantos usuarios aceptaron las pruebas

El proceso de pruebas es mas grande que el de la ejecución analiza y verifica todo el sistema.

Modelos de Pruebas: Un modelo contiene las diferentes formas en que se puede aplicar los
diferentes tipos de prueba, para escoger el mejor modelo debemos verificar los objetivos de
trabajo y elegir el que mejor nos convenga

Desarrollo secuencial (modelo V): se basa en 4 modelos de prueba que son

 Pruebas de componente
 Pruebas de integración
 Pruebas de sistema
 Pruebas de aceptación

Desarrollo Iterativo- Incremental: forma un grupo de tareas y forma una parte del sistema y sirve
para la probarlo.

Iteraciones: numero de veces que realizas una prueba modificando las condiciones.

Existen mas modelos de prueba qui pueden combinarse y van a depender del tipo de arquitectura
del sistema.

Niveles de Prueba: es el orden en el que deben ejecutarse las pruebas


Pruebas de caja blanca (pruebas de estructura): Están basadas en el funcionamiento del código
del software se verifican puntos tales fallas en la seguridad interna, trayectorias mal estructuradas,
el flujo a través del código su finalidad es mejorar el diseño del sistema su seguridad y usabilidad
del sistema.
Pruebas de caja negra: verifica la funcionalidad del software sin examinar el código, (pruebas de
humo).

Tipos de Herramientas:

Herramientas de Gestión: se pueden emplear durante todo el ciclo de vida del software

 Gestión de pruebas (interfaces para ejecutar pruebas, localizar defectos y elaboración de


reportes)
 Gestión de Requisitos (Almacena los requisitos y atributos para proporcionar indicadores)
 Gestión de incidencias (guardan y administran información sobre las fallas y peticiones)
 Gestión de Configuraciones (Contiene y administra las versiones de soporte del software,
útiles para más de un entorno)

Herramientas de Ejecución: Permiten encontrar las fallas de software en una etapa temprana del
desarrollo de pruebas

 Revisión (almacenan y comunican los informes de las fallas)


 Análisis Estáticos (ayudan a localizar defectos sin la necesidad de realizar pruebas
dinámicas y analizan la estructura y dependencia).
 Modelado (validar modelos de software además localizan y enumeran los defectos).

Análisis de Riesgo: Elemento fundamental para el desarrollo de un proyecto

Identificación de los riesgos

Riesgos del proyecto: cualquier evento incierto que puede impactar al proyecto, tiene 3 categorías
principales:

Riesgos organizacionales: son los que están relacionados con los recursos humanos involucrados
del proyecto

Riesgos Técnicos: Son los que causan mas perdidas por las malas ejecución de las pruebas.

Riesgos de Negocios: factores externos al proyecto, como clientes o socios.

Riesgos del producto: se refiere a la posibilidad de que el software o sistema no cumpla con las
expectativas del cliente (problemas de funcionalidad).

Análisis de impacto: Probabilidad de que un riesgo ocurra

Alta o nivel 3 (alta Probabilidad de que ocurra un problema 75%)

Media o nivel 2 (Media posibilidad de que ocurra un problema 50%)


Baja o nivel 1 (Baja probabilidad de que ocurra un problema menos del 25 %)

Impacto:

Alto o nivel 3 (el problema impacta a todo el proyecto, el proyecto no puede continuar sino se
resuelve).

Medio o nivel 2 (El problema impacta a partes importantes del proyecto y debe atenderse lo antes
posible)

Bajo o nivel 1 (El proyecto afecta a partes no vitales del proyecto es necesario que se resuelva sin
embargo se pueden tomar otras alternativas en lo que se soluciona)

Prioridad:

Nivel 6 a 9 Alta: se deben atender inmediatamente y se deben monitorear todos los días hasta
que se resuelvan.

Nivel 3 a 5 Media: requiere que sean tratados y monitoreados en juntas internas.

Nivel 1 a 2 Baja: es necesario monitorear el problema ocasionalmente.

Toma de contramedidas:

Riesgo

Monitoreo

Control de riesgo.

Estimación de Pruebas: Nos permite tener una idea estimada de cuanto tiempo y dinero nos
tomara realizar las pruebas

¿Cómo hacer una estimación?

 Dividir el proyecto en tareas y subtareas de tal manera que cada una de ellas sea lo más
explícita.
 Asignar cada una de las tareas a algún miembro el equipo tomar en cuenta las habilidades
experiencia y conocimiento del equipo
 Estimación de esfuerzo por tarea.

Estimación de los tres puntos

Punto “A” los mejores probadores y todos los recursos disponibles

Punto “M” (El más probable) Probadores adecuados y recursos suficientes


Punto “B” Equipo sin la mejor experiencia y escasos recursos.

Una vez se tiene la estimación se envía a los administradores del proyecto para la aprobación de
esta. Es buena practica dejar un tiempo de “reserva” por cualquier cambio un tiempo estimado de
una semana es lo recomendable.

Plan de pruebas:

Elaborar un plan de pruebas ahorra esfuerzo y tiempo durante el proceso de análisis.

Análisis: estudiar la documentación del software

Estrategia de pruebas:

 Determinación del alcance de pruebas.

Elementos que se les va a realizar la prueba se les conoce como bajo cobertura se tienen que
conocer los requerimientos del cliente, las especificaciones del producto, presupuesto asignado,
habilidades y numero de equipo de trabajo,

Elementos que no están bajo prueba pero que están definidos fuera de cobertura.

 Identificación de tipo de Prueba

Dependiendo de las metas del proyecto determinaremos que prueba hacer (Humo, Integración,
Unitarias etc.)

 Análisis de Riesgo

Evento futuro incierto que tiene cierta posibilidad que ocurra genere perdidas. (falla)

 Estrategia de Prueba

Define quien ejecutará la prueba y cuando lo hará (se consideran las habilidades de cada tester y
requerimientos del cliente)

El tester debe tener una buena cooperación y atención al detalle

 Capital humano

El Objetivo de toda prueba es encontrar la mayor cantidad de errores y que el software este libre
de fallas cuando sea adquirido por el usuario final

Para definir los objetivos de prueba se necesita determinar todas las aplicaciones del software que
necesitan probarse (mediante una lista) planificar las pruebas dependiendo de la importancia de
las funciones del software.
Criterios de Prueba: es un estándar que se establece durante el proceso de pruebas con el que se
ahorra tiempo

Criterio de suspensión: determina el punto critico del ciclo de prueba (si se suspende se
reanudará hasta que el criterio sea solucionado).

Criterio de salida: determina la finalización exitosa de una fase de pruebas se considera el


objetivo esperado que es necesario para pasar a la siguiente fase (se consideran porcentajes como
Tasa de ejecución tiene que ser igual al 100% casos ejecutados entre casos de pruebas totales,
Tasa de éxito es el porcentaje de casos de prueba exitosos entre casos de pruebas ejecutados
debemos conseguir un alto porcentaje esto dependerá del alcance del proyecto).

 Planeación de recursos.

Resumen detallado de todos los recursos disponibles para la realización del proyecto (humanos,
económicos, equipo)

 Planeación del ambiente de pruebas.

Trata de recrear el escenario real al que se enfrentara la aplicación dentro del software o
hardware.

 Calendarización

Técnica utilizada para monitorear el avance del proyecto (cantidad de gente disponible para las
pruebas, días laborales y fecha de entrega y riegos del proyecto).

 Entregables

Todos los documentos, herramientas o componentes que se aplican en el proceso de pruebas, por
ejemplo, documentación del plan de prueba y de los casos de prueba, simuladores reporte de
defectos y resultados

Resultado

Creación de casos de prueba

En el ambiente de procesos de prueba se necesita ser especifico ya que los escenarios son
confusos y cubren un amplio rango de posibilidades.

Casos de prueba es el conjunto de acciones que sirve para verificar una característica o función
específica de un software.

Constan de valores de entrada (datos de prueba)

Datos de prueba son los datos que existen (por ejemplo, en una base de datos) antes de que una
prueba sea ejecutada y que afectan o son afectados por el componente o sistema en pruebas.

Precondiciones y postcondiciones son elementos opcionales en casos de prueba.

Al realizar casos de prueba debemos tener en cuenta:


Utilizar el Lenguaje más simple. Para que cualquier persona pueda utilizarlo

si distintas pruebas usan el mismo caso de prueba usarlo como condición,

seguir las especificaciones documentadas (no asumir características o funcionalidad).

Diseño de Pruebas: Técnicas para diseñar los casos de prueba.

Tabla de decisión: usada cuando el software admite mas de un dato de entrada y genera una
respuesta a cada combinación

Diagrama de transición de estados: prueba las diferentes transacciones presentes en un sistema y


esta compuesta por los siguientes elementos 4 elementos:

 Estados que el software puede ocupar


 Transición de un estado a otro
 Eventos
 Acciones

Valores Limite: Técnicas que facilita el proceso de prueba para cubrir las más importante.

Equivalencia de particiones: Técnica de caja negra que se puede aplicar en cualquier nivel
de prueba, consiste en dividir los casos que pueden considerarse lo mismo; valores limites son los
que se prueban entre los límites de las particiones.

Pruebas de calidad: Son las pruebas que garantizan la calidad de software

 Pruebas de exactitud y de adecuación: las de exactitud comprueban que el software


cumple con los requerimientos específicos por otro lado las de adecuación verifican y
evalúan la capacidad de un conjunto de funciones para la realización de tareas especificas
 Pruebas de Interoperabilidad: se examina que una aplicación funcione correctamente en
todos los entornos es decir la forma en que estos se relacionan entre sí.
 Pruebas de usabilidad: grado de adecuación del software (proporcionar funciones que
satisfacen las necesidades declaradas e implícitas) la flexibilidad en el control y el logro de
objetivos se realizan en la fase de diseño del software y cuyo objetivo es analizar los
siguientes factores:
o Eficacia: capacidad del software para cumplir con los objetivos específicos incluye
facilidad y exactitud.
o Eficiencia: el sistema permite la navegación de los usuarios entre pantallas y que
haya uniformidad en la aplicación.
o Precisión: No deben existir datos incorrectos u obsoletos, ni enlaces rotos
o Satisfacción: El usuario esta conforme con el uso del software
o Accesibilidad: se ejecutan para asegurar que el sistema puede ser usado por
personas con discapacidades o necesidades particulares (reconocimientos de voz,
lectura de pantalla, etc.)
Pruebas técnicas: tipos de prueba que tienen como meta verificar la función del producto para
asegurar su calidad. Su meta es encontrar todas las vulnerabilidades del sistema. Que
comúnmente son errores de diseño o configuración o bugs de software, se encargan de validad la
capacidad que tiene el software para impedir los ataques de seguridad más comunes (accesos no
autorizados, copias no autorizadas de información, ruptura de cogido de encriptación).

Pruebas de fiabilidad: su objetivo es determinar una medida estadística que comparare la


estabilidad real con la esperada.

Pruebas de robustez: evalúa la tolerancia del software ante fallos que ocurren de manera externa
y se comunica mediante el sistema operativo.

Pruebas de recuperabilidad: valora la capacidad el sistema de restablecerse de una falla ya sea de


hardware o software y maneja los siguientes aspectos:

 Failover: simular o controlar fallos controlados. Comprueban los sistemas failover


y comprobar que no hubo afectación en el servicio o perdida de datos.
 Back-up y restablecimiento: son los que establecen medidas para minimizar las
consecuencias tras una falla.

Pruebas de mantenibilidad: facilidad con la que un software puede ser analizado, modificado o
probado de las cuales podemos mencionar:

 Pruebas dinámicas de mantenimiento: Se enfocan en los requerimientos


para verificar que se alcancen los niveles de servicio requeridos.
 Pruebas de mantenimiento correctivo: Miden el tiempo en que una falla
en el sistema es corregida.
 Pruebas de mantenimiento adaptativo: valoran 3 condiciones
o El esfuerzo requerido para modificar el sistema
o probar los cambios
o La respuesta del sistema a esas variaciones

Es necesario probar el software para verificar como funciona como fue diseñado

Pruebas de eficiencia: el software responde sobre circunstancias específicas entre estas pruebas

 Pruebas de carga: Miden la capacidad del sistema cuando soporta niveles


crecientes de carga los cuales simulan condiciones normales de operación con
estas pruebas logramos clasificar las siguientes características:
o Máxima capacidad de operación del sistema.
o Determina si la infraestructura actual es suficiente para soportar la
aplicación
o Sustentabilidad de la aplicación correspondiente a los picos de uso
 Pruebas de Estrés: el objetivo de esta prueba es determinar su estabilidad,
confiabilidad y determinar los limites en los que falla
 Pruebas de escalabilidad: Miden la capacidad de un sistema para satisfacer las
necesidades futuras como por ejemplo más información almacenada o un
incremento en las operaciones realizadas
 Pruebas de Utilización de recursos: Evalúan la forma en que los sistemas utilizan
los recursos disponibles entre los que se encuentran, ancho de banda, espacio de
memoria y capacidad del disco.
 Pruebas de portabilidad: Su finalidad es medir que tan fácil puede ser transferido
un sistema
o Pruebas de instabilidad: son para verificar que el software pude ser
instalado siguiendo un manual o un asistente de instalación
o Pruebas de compatibilidad: su función verifica si el software es capaz de
funcionar correctamente en diferentes sistemas operativos, entornos de
red o hardware.

Prueba exploratoria: está basada en la experiencia del tester y su objetivo esta basado en
la investigación y aprendizaje, sus características son:

 Creación simultanea de los casos de pruebas y su ejecución.


 Se enfoca en la investigación del sistema o su aplicación
 Mejora el diseño de pruebas
 El tester tiene el control de las pruebas sin seguir ningún guion
determinado.

Los elementos de las pruebas exploratorias constan de 5 elementos que


son:
 Clasificación de defectos: cataloga los errores mas comunes del pasado y
analiza la causa que origino esos defectos.
 Carta de prueba es un documento que debe contener que y como debería
probarse
 Cuadro de tiempo: dos testers deben trabajar 90 minutos sin interrupción
con el fin de ver la reacción del sistema y preparar la respuesta correcta
 Revisión de resultados: se evalúan los defectos encontrados en las áreas
cubiertas por las pruebas
 Cierre: se juntan los resultados de las pruebas para verificar si se necesita
alguna prueba adicional.

Proceso de mejoramiento de Pruebas: La calidad de un sistema está relacionada con la calidad del
proceso utilizado para desarrollar un producto.

Modelos que utilizan marcos de referencia para juzgar la capacidad de un proceso

 TMM (Test Maturity Model): Modelo de madurez


o Inicial: representa un estado donde no hay un proceso de pruebas formalmente
documentado y estructurado
o Definición: Se establecen objetivos, políticas y técnicas de pruebas
o Integración: es cuando el proceso de pruebas se integra en el ciclo de vida del
producto y se documenta con normas, procedimientos y métodos formales
o Gestión y medición: es cuando el proceso de pruebas puede ser medido,
gestionado y adaptado a proyectos específicos de forma eficaz
o Optimización: representa el estado en el que la información obtenida puede ser
utilizada para evitar defectos en el proceso de prueba
 TPI (Test Process Improvement): el proceso de pruebas se revisa a través de varios
puntos.
o Ciclo de vida
o Organización
o Infraestructura
o Herramientas
Dentro de estos cuatro existen elementos que llamamos Áreas Claves y cubren todo el
proceso de prueba las cuales se clasifican en diferentes niveles para asegurarse que cada
área es asignada en el nivel adecuado se deben establecer una serie de requerimientos
llamados puntos de control.

 CTP (Critical Testing Process): La premisa de este modelo es que hay determinados
procesos de prueba críticos.

Para emplear este modelo se evalúan los procesos de prueba existentes que varían en
función del contexto especifico, determina cuales procesos son más fuertes y débiles.

Puntos críticos: El proceso de prueba, establecimiento del contexto, análisis de riesgo para
la calidad, prueba de estimación y planeación, prueba del equipo y sistema de desarrollo,
administración de la versión de prueba, prueba de ejecución, reporte de bugs, cambio de
administración

5 pasos por seguir una vez identificados las áreas de mejora:

o Dar prioridad a la solución de problema


o Planear el proceso de mejora
o Implementar el cambio y medir la mejora en el tiempo
o Consolidar el cambio para convertirlo en modo en el que se hacen las cosas
o Volver a comenzar
 STEP (Systematic Test and Evaluation Process)

No se necesitan que las pruebas se hagan en un orden especifico, consideran las pruebas
como una actividad dentro de la vida de un software especifico que comienzan dentro de
la definición de requerimientos

Entre sus características están: Las pruebas se realizan al principio del ciclo de vida, se emplean
como requisito y modelo de uso, el diseño de soporte de prueba conduce al diseño del producto,
los probadores y diseñadores trabajan conjuntamente.

Las métricas utilizadas: Estados de pruebas en el tiempo, requisitos de prueba y cobertura de


tiempo, tendencia y densidad de los defectos, porcentaje de defectos encontrados y efectividad al
eliminarlos, costes de las pruebas en términos de tiempo, utilización del proceso de pruebas
definido, satisfacción del cliente.
Administración de defectos: proceso colección de defectos.

Descubrimiento: comunicación entre el tester y los comunicadores de los defectos que se


han encontrado; verifican que realmente existan errores para poder pasar a la siguiente
etapa

Categorización: clasificación de los defectos encontrados: Critica – Alta – Media – Baja

Resolución de Defectos:

 Asignación: Desarrolladores se encargan de reparar los


defectos
 Programación de la reparación: los desarrolladores crean un
programa para reparar los defectos reportados
 Reparación de defectos: Los tester verifican que las fechas se
cumplan en la reparación de defectos
 Reporte de Solución: Entrega de documento de parte de los
desarrolladores con la información de los defectos reparados.
 Verificación: el equipo de tester verifica los cambios funcionen
y no haya provocado nuevos defectos

Clausura: conclusión de un defecto

Reporte: Los miembros que pertenecen a las pruebas tienen que estar enterados de los defectos.

Ciclo de vida de un defecto: Nuevo, asignación, apertura, solucionado, espera de prueba. Prueba,
verificado, cerrado.

También podría gustarte