INSTITUTO TECNOLGICO SUPERIOR DE FELIPE CARRILLO PUERTO

Investigacin U4
Subtema 4.1 Definiciones
Alumna: Jurez Lpez Dalia Mara Prof.: Ing. Eduardo Castillo Moo

Ingeniera en Sistemas Computacionales

Introduccin

En estos puntos de esta investigacin conoceremos los conceptos bsicos para llevar a cabo una prueba de algn software que estemos llevando a cabo, las pruebas del software es una parte importante ya que este nos ayuda a ver si el software funciona de manera correcta y si hace lo que debe hacer o si no lo hace lo que debe hacer. Se conocer los tipos de pruebas que existen, los cuales son las pruebas estructurales, las funcionales y las aleatorias, cada una tiene un fin diferente para que el software tenga un rendimiento ptimo. Y como ltimo tema estar la documentacin del diseo de pruebas este tendr un registro de las pruebas que se le harn al software antes de ser entregado pero para poder llevar a cabo el registro se deben llevar ciertos pasos que ms adelante se detallarn.

4.1 Definiciones
4.1.1.- Prueba, Caso de prueba, Defecto, Falla, Error, Verificacin y Validacin
Verificacin: El proceso de evaluacin de un sistema (o de uno de sus componentes para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase. Validacin: El proceso de evaluacin de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario. Prueba: Una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluacin de algn aspecto. Caso de prueba: Un conjunto de entradas, condiciones de ejecucin y resultados esperados desarrollados para un objetivo particular. Defecto: Un defecto en el software como, por ejemplo, un proceso, una definicin de datos o un paso de procesamiento incorrectos en un programa. Fallo: La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.

4.1.2.- Relacin entre Defectos-Falla-Error.

La prueba exhaustiva del software es impracticable (no se pueden probar todas las posibilidades de su funcionamiento ni siquiera en programas sencillos). El objetivo de las pruebas es la deteccin de defectos en el software (descubrir un error es el xito de una prueba). Cada caso de prueba debe definir el resultado de salida esperado que se comparar con el realmente obtenido. Al generar casos de prueba, se deben incluir tanto datos de entrada vlidos y esperados como no vlidos e inesperados.

La experiencia parece indicar que donde hay un defecto hay otros, es decir, la probabilidad de descubrir nuevos defectos en una parte del software es proporcional al nmero de defectos ya descubierto. Las pruebas son una tarea tanto o ms creativa que el desarrollo de software. Siempre se han considerado las pruebas como una tarea destructiva y rutinaria.

4.1.3 Pruebas Estructurales, Funcionales y Aleatorias

Pruebas Estructurales
El diseo de casos de prueba tiene que estar basado en la eleccin de caminos importantes que ofrezcan una seguridad aceptable de que se descubren defectos (un programa de 50 lneas con 25 sentencias if en serie da lugar a 33,5 millones de secuencias posibles), para lo que se usan los criterios de cobertura lgica.

Diagrama de flujo de las estructuras basicas de un programa

Pruebas Funcionales
Se centran en las funciones, entradas y salidas. Seria imprctico probar el software para todas las posibilidades. De nuevo hay que tener criterios para elegir buenos casos de prueba. Un caso de prueba funcional es bien elegido si se cumple que: Reduce el nmero de otros casos necesarios para que la prueba sea razonable. Esto implica que el caso ejecute el mximo nmero de posibilidades de entrada diferentes para as reducir el total de casos. Cubre un conjunto extenso de otros casos posibles, es decir, no indica algo acerca de la ausencia o la presencia de defectos en el conjunto especfico de entradas que prueba, as como de otros conjuntos similares.

Pruebas Aleatorias
En las pruebas aleatorias simulamos la entrada habitual del programa creando datos de entrada en la secuencia y con la frecuencia con las que podran aparecer en la prctica (de manera repetitiva). Para ello habitualmente se utilizan generadores automticos de casos de prueba.

4.1.4.- Documentacin del Diseo de las pruebas

Para poder tener la certeza de que una aplicacin de software ha sido revisada en todos los aspectos indispensables y que posee una funcionalidad de acuerdo a los requerimientos del cliente, es necesario llevar un registro de las pruebas a realizar, donde se pueda tener un control del progreso de esta etapa. La documentacin del diseo de pruebas se compone de los siguientes pasos: Generar un plan de pruebas. Disear pruebas especficas. Especificar los casos de prueba (tomar configuracin del sw a probar). Especificar los procedimientos de las pruebas (configurar las pruebas).

Conclusin

Como pudimos observar las pruebas nos ayudan de mucho con el software, es una parte importante, como vimos en cada definicin de cada concepto los defectos, las fallas y los errores van de la mano ya que si el defecto viene desde el programador, hace que el software falla y hace que los errores aparezcan en el sistema, pero para que esto no suceda en la mayora de los casos estas las pruebas estructurales, funcionales y aleatorias. Las pruebas estructurales ofrecen una seguridad aceptable donde se descubren defectos para los programadores que se usan los criterios de cobertura lgica. Las funcionales se centran ms que nada en las entradas y las salidas, es elegido si reduce el nmero de otros casos necesarios para que la prueba sea razonable y las aleatorias estas simulan las entradas creando datos en la secuencia y con la frecuencia con las que podran aparecer en la prctica. La documentacin del diseo lleva un registro donde se describe si una aplicacin de software ha sido revisada en todos los aspectos indispensables y que posee una funcionalidad de acuerdo a los requerimientos del cliente.