Prueba De Sistema
Páginas: 52 (12789 palabras)
Publicado: 5 de noviembre de 2012
PRUEBA DEL SISTEMA
En este capitulo se consideran conceptos inherentes a:
• Prueba de las funciones
• Prueba de rendimiento
• Prueba de aceptación
• Confiabilidad, disponibilidad y facilidad de mantenimiento del software
• Prueba de instalación
• Documentación de la prueba
• Prueba de sistemas de seguridad critica
La prueba delsistema es muy diferente de las pruebas unitarias y de integración. Cuando se prueban componentes unitarios, es el desarrollador quien tiene el control completo sobre el proceso de prueba. Por lo tanto, crea sus propios datos de prueba, diseña sus propios casos de prueba y ejecuta las pruebas por si mismo. Cuando se integran los componentes, el desarrollador suele trabajar solo, pero colabora amenudo con una pequeña parte del equipo de prueba o de desarrollo. Sin embargo, cuando se prueba un sistema, se trabaja junto al equipo de desarrollo completo, coordinado lo que hace y siguiendo las directivas del líder del equipo de prueba. En este capítulo, se contempla el proceso de prueba del sistema, pasos, participantes, técnicas y herramientas.
PRINCIPIOS DE LA PRUEBA DEL SISTEMA
Elobjetivo de la integración y de la prueba unitaria es asegurar que el código implementa correctamente el diseño, es decir, que los programadores han escrito el código de manera que hace lo que los diseñadores pretenden que haga. En la prueba del sistema, el objetivo es muy diferente: asegurar que el sistema hace lo que el cliente quiere que haga. Para entender cómo alcanzar este objetivo, enprimer lugar es necesario comprender de donde provienen los defectos de los sistemas.
ORIGENES DE LOS DEFECTOS DEL SOFTWARE
Cabe recordar que un defecto del software solo causa una falta cuando estuvo acompañado por las condiciones correctas. Es decir, el defecto puede estar en el código, pero si el código nunca se ejecuta o no se ejecuta durante suficiente tiempo o en la configuraciónprecisa para causar un problema, es probable que nunca se evidencie la falla del software. Dado que las pruebas no pueden ensayar todas las posibles condiciones, el descubrimiento de defectos se mantiene como meta permanente, esperando que durante el proceso se eliminen todos los defectos que podría conducir a fallas durante el uso del sistema.
Los defectos del software pueden insertarse enun requerimiento, en el diseño, en un componente del código o en la documentación, en cualquier momento durante el desarrollo o el mantenimiento. La figura 9.1 presenta las posibles causas de defectos en cada actividad de desarrollo. Aunque se aspira a encontrar y corregir los defectos lo más pronto posible, la prueba del sistema reconoce que los defectos todavía pueden estar presentes después delas pruebas de integración.
Los defectos pueden incorporarse al sistema temprano durante el desarrollo, o tarde, como puede suceder cuando se corrige un defecto recientemente descubierto. Por ejemplo el software defectuoso puede ser el resultado de defectos en los requerimientos. Si un requerimiento ha sido ambiguo, ya sea porque el cliente no estaba del todo seguro acerca de unanecesidad, o porque se interpreto mal lo que quiso significar, el resultado es el mismo: un sistema que no trabaja de la manera que el cliente quiere que lo haga.
El mismo tipo de contratiempos de comunicación puede ocurrir durante el diseño del sistema. Se puede interpretar mal un requerimiento y por ello escribir una especificación de diseño incorrecta. O bien, se puede comprender elrequerimiento pero la especificación se formula tan pobremente que, como consecuencia, quienes leen y utilizan el diseño lo entienden mal. De manera similar, se pueden hacer suposiciones sobre características y relaciones, que no son compartidas por los otros lectores del diseño.
Eventos similares pueden derivar en defectos del diseño de programas. Las interpretaciones erróneas son comunes...
En este capitulo se consideran conceptos inherentes a:
• Prueba de las funciones
• Prueba de rendimiento
• Prueba de aceptación
• Confiabilidad, disponibilidad y facilidad de mantenimiento del software
• Prueba de instalación
• Documentación de la prueba
• Prueba de sistemas de seguridad critica
La prueba delsistema es muy diferente de las pruebas unitarias y de integración. Cuando se prueban componentes unitarios, es el desarrollador quien tiene el control completo sobre el proceso de prueba. Por lo tanto, crea sus propios datos de prueba, diseña sus propios casos de prueba y ejecuta las pruebas por si mismo. Cuando se integran los componentes, el desarrollador suele trabajar solo, pero colabora amenudo con una pequeña parte del equipo de prueba o de desarrollo. Sin embargo, cuando se prueba un sistema, se trabaja junto al equipo de desarrollo completo, coordinado lo que hace y siguiendo las directivas del líder del equipo de prueba. En este capítulo, se contempla el proceso de prueba del sistema, pasos, participantes, técnicas y herramientas.
PRINCIPIOS DE LA PRUEBA DEL SISTEMA
Elobjetivo de la integración y de la prueba unitaria es asegurar que el código implementa correctamente el diseño, es decir, que los programadores han escrito el código de manera que hace lo que los diseñadores pretenden que haga. En la prueba del sistema, el objetivo es muy diferente: asegurar que el sistema hace lo que el cliente quiere que haga. Para entender cómo alcanzar este objetivo, enprimer lugar es necesario comprender de donde provienen los defectos de los sistemas.
ORIGENES DE LOS DEFECTOS DEL SOFTWARE
Cabe recordar que un defecto del software solo causa una falta cuando estuvo acompañado por las condiciones correctas. Es decir, el defecto puede estar en el código, pero si el código nunca se ejecuta o no se ejecuta durante suficiente tiempo o en la configuraciónprecisa para causar un problema, es probable que nunca se evidencie la falla del software. Dado que las pruebas no pueden ensayar todas las posibles condiciones, el descubrimiento de defectos se mantiene como meta permanente, esperando que durante el proceso se eliminen todos los defectos que podría conducir a fallas durante el uso del sistema.
Los defectos del software pueden insertarse enun requerimiento, en el diseño, en un componente del código o en la documentación, en cualquier momento durante el desarrollo o el mantenimiento. La figura 9.1 presenta las posibles causas de defectos en cada actividad de desarrollo. Aunque se aspira a encontrar y corregir los defectos lo más pronto posible, la prueba del sistema reconoce que los defectos todavía pueden estar presentes después delas pruebas de integración.
Los defectos pueden incorporarse al sistema temprano durante el desarrollo, o tarde, como puede suceder cuando se corrige un defecto recientemente descubierto. Por ejemplo el software defectuoso puede ser el resultado de defectos en los requerimientos. Si un requerimiento ha sido ambiguo, ya sea porque el cliente no estaba del todo seguro acerca de unanecesidad, o porque se interpreto mal lo que quiso significar, el resultado es el mismo: un sistema que no trabaja de la manera que el cliente quiere que lo haga.
El mismo tipo de contratiempos de comunicación puede ocurrir durante el diseño del sistema. Se puede interpretar mal un requerimiento y por ello escribir una especificación de diseño incorrecta. O bien, se puede comprender elrequerimiento pero la especificación se formula tan pobremente que, como consecuencia, quienes leen y utilizan el diseño lo entienden mal. De manera similar, se pueden hacer suposiciones sobre características y relaciones, que no son compartidas por los otros lectores del diseño.
Eventos similares pueden derivar en defectos del diseño de programas. Las interpretaciones erróneas son comunes...
Leer documento completo
Regístrate para leer el documento completo.