INTRODUCCIN A LA COMPUTACIN

TEMAS:

PRUEBAS DE SOFTWARE.
GESTIN DE LA CONFIGURACIN.
GESTIN DE SOFTWARE.

INTEGRANTES
1. ARIZOLA YANAC, CARLOS
2. ALVARADO CHAUPIS, MIGUEL ANGEL
15200196
3. RENZO LEON
TRABAJO
4. RODRIGUEZ MOROTE, DANIEL
15200249

15200197

NO

Ciudad universitaria,16 de Noviembre del 2015.

Prueba de Software
En el proceso de creacin de un Software de calidad se tienen que tomar
en cuenta ciertos aspectos a seguir para su completo y eficaz desarrollo.
Entre estos se encuentra como uno de los ms importantes, la prueba
de Software, tema que se desarrollara en el presente capitulo
Qu es la prueba de Software?
La prueba de software es un proceso que consiste en una serie de
mtodos y tcnicas empricas que se dan para poder hallar problemas
dentro de un programa en su totalidad. Encontrar estos fallos en su
mayora abarcan ms del el 50 porciento del tiempo que se demora un
desarrollador de Software en acabar su proyecto, aun as, en muchos
casos tras sus presentaciones, estos siguen conteniendo algunos errores
los cuales no habran sido detectados por el programador.

Prueba de Black Box

La prueba de Black box tambin conocida como data-driver o
imput/output driven es un mtodo que usan los programadores el cual
consiste en probar el programa sin tener en cuantas los pasos que se
dan para la realizacin de este en su interior ingresando datos que
podran hacer que el programa falle, de esta manera el software debe
ser probado para asegurarse que este no haga lo que se supone que no
debe hacer.

Prueba de White Box

La prueba de White box tambin conocida como logic-driven, es un
mtodo que consiste en intentar todos lo posibles casos que puede tener
el programa. Al mismo tiempo representara todo los contrario a la de la
Black box puesto que se analiza el funcionamiento del programa por
dentro. Este mtodo en muchos casos se considera inadecuado puesto
que como se puede ver es posible que el programador tenga que
analizar una cantidad de casos demasiado basto.

Hacer una prueba de software es un proceso muy complicado que

padecen todas las empresas en ese campo. Los errores en un software
pueden ser bastante especficos que escapan a la vista de los
probadores de software.
Cmo un error puede pasar la vigilancia de los probadores de software?

El orden de las acciones o declaraciones no son iguales a las que

se hizo en la etapa de prueba. El orden afecta significativamente
la eficiencia del software.
El usuario ingresa valores de entrada que no fueron probados.
Probar con todos los valores posibles es una tarea imposible por
eso es mejor probar con valores limites (En un caso numrico seria
probar con los limites del dominio y el 0).
El entorno del usuario no se recre en la fase de prueba.

Una forma de hacer correctamente las pruebas a un software se basa en

un moto que consta de 4 fases:
1.
2.
3.
4.

Modelar el entorno del software.

Seleccionar escenarios de prueba.
Ejecutar y evaluar los escenarios.
Medir el progreso de las prueba.

FASE 1: Modelar el Entorno del Software

En esta fase el objetivo es identificar y similar las interfaces que utilize
el sistema.Las interfaces usuales son:

Las interfaces humanas: Son aquellas que interactuan y se

comunican con las personas.
Las interfaces de software (APIs): Indican cmo utiliza el software
al sistema operativo, la base de datos o la librera, en tiempo de
ejecucin.
Las interfaces de comunicacion: Aquellas que permiten el acceso a
dispositivos fisicos.

FASE 2: Seleccionar Escenarios de Prueba

Probar con todos los escenarios posibles es una tarea imposibles.Qu

debe hacer el probador para agarrar es pequeo subconjunto de
escenarios que le pueden ayudar a identificar los errores?

1) Seleccionar un conjunto de casos de prueba que garantice que cada

sentencia se ejecute al menos una vez y 2) Seleccionar un conjunto de
casos de prueba que garantice que cada estructura de control If, Case,
While,... se evale en cada uno de sus posibles caminos de ejecucin.
FASE 3: Ejecutar y Evaluar los Escenarios.
Esta es la fase de central; despues de haber analizado las interfaces y
seleccionar los escenarios a probar.Para problemas complejos muchos
probadores automatizan el proceso mediante codigo que simulas las
entradas de un usuario.
Cuando se encuentra un error pueden ocurrir algunos casos:

Se carregla el error y el programa sigue intacto.

Se arregla el error pero una parte funcional se altera al hacer los
cambios.
No se arregla el error y el programa sigue igual.
No se arregla pero altera el programa generando nuevos errrores.

FASE 4: Medir el Progreso de las Pruebas

Es dificil saber cual es el progreso a la hora de probar el software y
corregir errores.Estas preguntas pueden ayudara los probadores a saber
su progreso:

He probado para errores de programacin comn?

He ejercitado todo el cdigo fuente?
He forzado a todos los datos internos a ser inicializados y
utilizados?
He encontrado todos los errores sembrados?

CONCLUSIONES:
El software cada vez se mas complejos lo que crea mas
dificultades para los probadores en su busqueda de errrores.

 Los probadores deben ser altamente especializados en temas

relacionados a calidad de software, teoria de grafos y a muchas
otras areas ms relacionadas a la teoria computacional.
Existen muchos estilosa la hora de probar el software.Las 4 fases
es solo un metodo y no debe considerarse como definitiva.

BIBLIOGRAFIA:
EDGAR SERNA M. & FERNANDO ARANGO I. Software testing: more
than a stage in the life cycle
GLENDFORT J. MYERS, TOM BADGETT & COREY SANDLER . The art
of software testing.