Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Pruebas Software

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 4

Pruebas de Software Reyes Carreño Ricardo; Moreno Evaristo Uriel 3IM9

PRUEBAS UNITARIAS.

En programación, una prueba unitaria es una forma de probar el


correcto funcionamiento de un módulo de código. Esto sirve para
asegurar que cada uno de los módulos funcione correctamente por
separado. Luego, con las Pruebas de Integración, se podrá asegurar el
correcto funcionamiento del sistema o subsistema en cuestión.
La idea es escribir casos de prueba para cada función no trivial o
método en el módulo de forma que cada caso sea independiente del
resto.

Contenido
• 1 Características
• 2 Ventajas
• 3 Limitaciones
• 4 Herramientas

Características
Para que una prueba unitaria sea buena se deben cumplir los
siguientes requisitos:
• Automatizable: no debería requerirse una intervención manual.
Esto es especialmente útil para integración continúa.
• Completas: deben cubrir la mayor cantidad de código.
• Repetibles o Reutilizables: no se deben crear pruebas que sólo
puedan ser ejecutadas una sola vez. También es útil para
integración continua.
• Independientes: la ejecución de una prueba no debe afectar a la
ejecución de otra.
• Profesionales: las pruebas deben ser consideradas igual que el
código, con la misma profesionalidad, documentación, etc.
Aunque estos requisitos no tienen que ser cumplidos al pie de la letra,
se recomienda seguirlos o de lo contrario las pruebas pierden parte
de su función.
Ventajas
El objetivo de las pruebas unitarias es aislar cada parte del programa
y mostrar que las partes individuales son correctas. Proporcionan un
contrato escrito que el trozo de código debe satisfacer. Estas pruebas
aisladas proporcionan cinco ventajas básicas:
1. Fomentan el cambio: Las pruebas unitarias facilitan que el
programador cambie el código para mejorar su estructura (lo
que se ha dado en llamar refactorización), puesto que permiten
hacer pruebas sobre los cambios y así asegurarse de que los
nuevos cambios no han introducido errores.
Pruebas de Software Reyes Carreño Ricardo; Moreno Evaristo Uriel 3IM9

2. Simplifica la integración: Puesto que permiten llegar a la fase de


integración con un grado alto de seguridad de que el código
está funcionando correctamente. De esta manera se facilitan
las pruebas de integración.
3. Documenta el código: Las propias pruebas son documentación
del código puesto que ahí se puede ver cómo utilizarlo.
4. Separación de la interfaz y la implementación: Dado que la
única interacción entre los casos de prueba y las unidades bajo
prueba son las interfaces de estas últimas, se puede cambiar
cualquiera de los dos sin afectar al otro, a veces usando objetos
mock (mock object) para simular el comportamiento de objetos
complejos.
5. Los errores están más acotados y son más fáciles de localizar:
dado que tenemos pruebas unitarias que pueden
desenmascararlos.
Limitaciones
Es importante darse cuenta de que las pruebas unitarias no
descubrirán todos los errores del código. Por definición, sólo prueban
las unidades por sí solas. Por lo tanto, no descubrirán errores de
integración, problemas de rendimiento y otros problemas que afectan
a todo el sistema en su conjunto. Además, puede no ser trivial
anticipar todos los casos especiales de entradas que puede recibir en
realidad la unidad de programa bajo estudio. Las pruebas unitarias
sólo son efectivas si se usan en conjunto con otras pruebas de
software.
PRUEBAS DE INTEGRACION
Son aquellas que se realizan en el ámbito del desarrollo de software
una vez que se han aprobado las pruebas unitarias. Únicamente se
refieren a la prueba o pruebas de todos los elementos unitarios que
componen un proceso, hecha en conjunto, de una sola vez.
Consiste en realizar pruebas para verificar que un gran conjunto de
partes de software funcionan juntos.
Las pruebas de integración (algunas veces llamadas integración y
testeo I&t) es la fase del testeo de software en la cual módulos
individuales de software son combinados y testeados como un grupo.
Son las pruebas posteriores a las pruebas unitarias y preceden el
testeo de sistema.
PRUEBAS DE SISTEMA
Dependiendo del tamaño de la Empresa que usara el Sistema y el
riesgo asociado a su uso, puede hacerse la elección de comenzar la
operación del Sistema solo en un área de la Empresa (como una
Prueba piloto), que puede llevarse a cabo en un Departamento o con
una o dos personas. Cuando se implanta un nuevo sistema lo
aconsejable es que el viejo y el nuevo funcionen de manera
simultanea o paralela con la finalidad de comparar los resultados que
Pruebas de Software Reyes Carreño Ricardo; Moreno Evaristo Uriel 3IM9

ambos ofrecen en su operación, además dar tiempo al personal para


su entrenamiento y adaptación al nuevo Sistema.
Durante el Proceso de Implantación y Prueba se deben implementar
todas las estrategias posibles para garantizar que en el uso inicial del
Sistema este se encuentre libre de problemas lo cual se puede
descubrir durante este proceso y levar a cabo las correcciones de
lugar para su buen funcionamiento.
Desdichadamente la evaluación de Sistemas no siempre recibe la
atención que merece, sin embargo cuando se lleva a cabo de manera
adecuada proporciona muchas informaciones que pueden ayudar a
mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones
futuras.

PRUEBAS DE IMPLANTACIÓN
Es el proceso instalar equipos o Software nuevo, como resultado de
un análisis y diseño previo como resultado de la sustitución o
mejoramiento de la forma de llevar a cavo un proceso automatizado.
Al Implantar un Sistema de Información lo primero que debemos
hacer es asegurarnos que el Sistema sea operacional o sea que
funcione de acuerdo a los requerimientos del análisis y permitir que
los usuarios puedan operarlo.

Existen varios enfoques de Implementación:

• Es darle responsabilidad a los grupos


• Uso de diferentes estrategias para el entrenamiento de los
usuarios
• El Analista de Sistemas necesita ponderar la situación y
proponer un plan de conversión que sea adecuado para la
organización.
• El Analista necesita formular medidas de desempeño con las
cuales evaluar a los Usuarios.
• Debe Convertir físicamente el sistema de información antiguo,
al nuevo modificado.
En la preparación de la Implantación, aunque el Sistema este bien
diseñado y desarrollado correctamente su éxito dependerá de su
implantación y ejecución por lo que es importante capacitar al usuario
con respecto a su uso y mantenimiento.

PRUEBAS DE ACEPTACION
El objetivo de las pruebas de aceptación es validar que un sistema
cumple con el funcionamiento esperado y permitir al usuario de dicho
Pruebas de Software Reyes Carreño Ricardo; Moreno Evaristo Uriel 3IM9

sistema que determine su aceptación, desde el punto de vista de su


funcionalidad y rendimiento.
Las pruebas de aceptación son definidas por el usuario del sistema y
preparadas por el equipo de desarrollo, aunque la ejecución y
aprobación final corresponden al usuario.
La validación del sistema se consigue mediante la realización de
pruebas de caja negra que demuestran la conformidad con los
requisitos y que se recogen en el plan de pruebas, el cual define las
verificaciones a realizar y los casos de prueba asociados. Dicho plan
está diseñado para asegurar que se satisfacen todos los requisitos
funcionales especificados por el usuario teniendo en cuenta también
los requisitos no funcionales relacionados con el rendimiento,
seguridad de acceso al sistema, a los datos y procesos, así como a los
distintos recursos del sistema.

PRUEBAS DE REGRESIÓN
Se denominan Pruebas de regresión a cualquier tipo de pruebas de
software que intentan descubrir las causas de nuevos errores (bugs),
carencias de funcionalidad, o divergencias funcionales con respecto al
comportamiento esperado del software, inducidos por cambios
recientemente realizados en partes de la aplicación que
anteriormente al citado cambio no eran propensas a este tipo de
error. Esto implica que el error tratado se reproduce como
consecuencia inesperada del citado cambio en el programa.
Este tipo de cambio puede ser debido a prácticas no adecuadas de
control de versiones, falta de consideración acerca del ámbito o
contexto de producción final y extensibilidad del error que fue
corregido (fragilidad de la corrección), o simplemente una
consecuencia del rediseño de la aplicación.
Por lo tanto, en la mayoría de las situaciones del desarrollo de
software se considera una buena práctica que cuando se localiza y
corrige un bug, se grabe una prueba que exponga el bug y se vuelvan
a probar regularmente después de los cambios subsiguientes que
experimente el programa.
Existen herramientas de software que permiten detectar este tipo de
errores de manera parcial o totalmente automatizada, la práctica
habitual en programación extrema es que este tipo de pruebas se
ejecuten en cada uno de los pasos del ciclo de vida del desarrollo del
software.

También podría gustarte