Niveles de Pruebas
Testing de Componentes
También denominadas pruebas de Desarrollador (developer’s test), se
prueba cada componente tras su realización/construcción. Dadas las
convenciones de cada lenguaje de programación para la asignacion de
nombres a sus respectivos componentes, se podrá hacer referencia a una
componente como:
- Prueba de modulo: En C
- Prueba de Clase: En java o C++
- Pruebas de unidad: En pascal
Alcance:
- Solo se prueban componentes individuales
- Cada componente es probado de forma independiente
- Los casos de prueba tienen 3 fuentes
Las pruebas de componentes buscan defectos y verifican el
funcionamiento del software (por ejemplo, módulos, programas, objetos,
clases, etc) que son testeables por separado. Se puede realizar de forma
aislada del resto del sistema, en función del contexto del ciclo de
vida de desarrollo y el sistema.
El Testing de componentes puede incluir el testing de elementos
funcionales y no funcionales, tales como recursos del sistema (por
ejemplo, mal uso de memoria), así como las pruebas estructurales. Los
casos de prueba son derivados de los trabajos como una especificación de
los componentes, el diseño del software o el modelo de datos.
Típicamente, el testing de componentes se produce con acceso al
código bajo pruebas y con el apoyo del entorno de desarrollo, tales como
un framework de pruebas unitarias o herramientas de depuración, y, en
la práctica, por lo general involucra al programador que escribió el
código. Los errores se suelen reparar tan pronto como se encuentran, sin
constancia oficial de los incidentes.
Un enfoque para el testing de componentes es la de preparar y
automatizar casos de prueba antes de codificar. Esto se conoce como
enfoque “desarrollo basado en pruebas” (TDD). Este enfoque es muy
repetitivo y se basa en los ciclos de desarrollo de casos de prueba, a
continuación, construcción e integración de pequeños trozos de código y
ejecución de las pruebas de componentes hasta que pasen.
Testing de Integración
Verifica las interfaces entre componentes, las interacciones entre
las diferentes partes de un sistema, tales como el sistema operativo,
sistema de archivos, hardware, o interfaces con otros sistemas.
Puede haber más de un nivel de pruebas de integración y puede
llevarse a cabo sobre objetos de prueba de tamaño variable. Por
ejemplo: Pruebas de integración de componentes verifican las
interacciones entre las los componentes del software y se realiza
después de las pruebas de componentes.
Cuanto mayor sea el alcance de la integración, más difícil se hace
para aislar las fallas de un elemento o sistema específico, que puede
conducir a un aumento del riesgo.
Las estrategias sistemáticas de integración pueden estar basadas en
la arquitectura del sistema (por ejemplo, de arriba abajo y de abajo
hacia arriba), tareas funcionales, las secuencias de procesamiento de
transacciones, o algún otro aspecto del sistema o componente. Con el fin
de reducir el riesgo de encontrar errores demasiado tarde, la
integración normalmente es incremental.
Alcance:
- Se prueban grupos de componentes
- Se puede implementar a nivel subsistemas si se tiene un grupo de los mismos
- Comprueban la interacción entre componentes respecto de la especificación de interfaces.
Testing de Sistema
La calidad del software es observada desde el punto de vista del
usuario. El entorno de prueba debe corresponder al entorno de producción
tanto como sea posible para reducir al mínimo el riesgo de incidentes
debidos al ambiente específicamente y que no se encontraron en las
pruebas. Pueden incluir pruebas basadas en los riesgos y/o
especificaciones sobre los requerimientos, procesos de negocio, casos de
uso, u otras descripciones de alto nivel del comportamiento del
sistema, las interacciones con el sistema operativo y los recursos del
sistema.
Deben investigar tanto requerimientos funcionales y no funcionales
del sistema. Estos requerimientos pueden existir como texto y/o modelos.
Alcance:
- Adecuacion (Suitability): ¿Las funcoines implementadas son adecuadas para su uso esperado?
- Exactitud (Accuracy): ¿Las funciones presentan los resultados correctos (acordados)?
- Interoperabilidad (Interoperability): ¿Las interacciones con el entorno del sistema presentan algun problema?
- Cumplimiento de Funcionalidad (Compliance): ¿El sistema cumple con normas y reglamentos aplicables?
- Seguridad (Security): ¿Están protegidos los datos/programas contra acceso no deseado o perdida?
Testing de Aceptación
Son a menudo responsabilidad de los clientes y/o usuarios de un
sistema; otras partes interesadas pueden participar también. La meta en
las pruebas de aceptación es el de establecer confianza en el sistema,
las partes del sistema o las características específicas y no
funcionales del sistema. Encontrar defectos no es el foco principal en
las pruebas de aceptación. Las pruebas de aceptación pueden evaluar la
disposición del sistema para el uso, aunque no es necesariamente el
nivel final de las pruebas. Por ejemplo, una prueba de integración de
sistemas a gran escala puede venir en pos de la prueba de aceptación
para un sistema.
La prueba de aceptación se puede presentar como algo más que una
prueba de nivel único, por ejemplo: Se pueden realizar pruebas de
aceptación sobre un producto de software cuando se instala o se
integra. Las pruebas de aceptación de la usabilidad de un componente
puede hacerse durante las pruebas de componentes. Las pruebas de
aceptación de una nueva mejora funcional puede hacerse antes de la
prueba del sistema.
Alcance:
- Se verificará que el software satisface los requisitos del cliente
Tipos de pruebas según Objetivos
Testing Funcional:
Las pruebas se basan en funciones y características (descripta en
los documentos o entendidas por los testers) y su interoperabilidad con
sistemas específicos, y puede llevarse a cabo en todos los niveles del
Testing (por ejemplo, las pruebas de unidad pueden estar basadas en la
especificación de componentes). Se pueden llevar a cabo en todos los
niveles de pruebas.
Objetivo: la función del objeto de prueba.
Testing no Funcional
Es la prueba de “cómo” funciona el sistema. Incluyen, pero no se
limitan a, las pruebas de rendimiento, pruebas de carga, pruebas de
estrés, pruebas de usabilidad, pruebas de mantenimiento, pruebas de
fiabilidad y pruebas de portabilidad.
Las pruebas no funcionales se pueden realizar en todos los niveles
del Testing. El termino pruebas no funcionales describe las pruebas
necesarias para medir las características de los sistemas y software que
se puede cuantificar en una escala variable, tales como tiempos de
respuesta para las pruebas de rendimiento.
Objetivo: Describir las pruebas necesarias para medir las características de los sistemas que se puede cuantificar en una escala variable
Testing Estructural
Puede realizarse en todos los niveles del testing. Las técnicas
estructuradas son las mejores, usadas después de las técnicas basadas en
especificaciones, con el fin de ayudar a medir el rigor de las pruebas
mediante la evaluación de la cobertura de un tipo de estructura.
La cobertura es la medida en que una estructura ha sido llevada a
cabo por una serie de pruebas, expresado como porcentaje de los puntos
que son cubiertos. Si la cobertura es del 100%, luego más pruebas pueden
ser diseñadas para probar a los elementos que se han perdido y, por
tanto, incrementar la cobertura.
Objetivo: La finalidad de las pruebas es medir el
grado en el cual la estructura del objeto de prueba ha sido cubierto
por los casos de prueba.
http://josepablosarco.wordpress.com/2012/05/25/istqb-cap-2-testing-a-traves-del-ciclo-de-vida-del-software-ii/
No hay comentarios.:
Publicar un comentario