INSTITUTO POLITÉCNICO NACIONAL

UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y

CIENCIAS SOCIALES Y ADMINISTRATIVAS

UNIDAD DE APRENDIZAJE: INGENIERÍA DE PRUEBAS

PROFESOR: GARCIA RODRIGUEZ JOSE LUIS

ALUMNO: TOLENTINO SÁNCHEZ MARCO TEVI

SECUENCIA: 5NM70

2.1.1 Desarrollar: pruebas unitarias de investigación y de sistema

1
 INDICE
INTRODUCCIÓN…………………………………………………………………………………………… 3
OBJETIVO …….……………………………………………………………………………………………….3
MISION …….……………………………………………………………………………….………………….3
VISION …….………………………………………………………………………………………..………….3
ALCANCE…….……………………………………………………………………………………………..….3
DESARROLLO…………………………………………………………………………………………………4
CONCLUSIÓN ………………………………………………………………………………………….….15
REFERENCIAS………………………………..……………………………………………….……………16

2
 INTRODUCCION

Como bien sabemos existen diferentes tipos de pruebas sin embargo

abarcaremos 3 las unitarias que estas se hacen en cada parte en específico, las
de sistemas que verifican el correcto funcionamiento de las interfaces y las de
integración que etas se realizan para comprobar interacciones.

OBJETIVO

Desarrollar ampliamente las pruebas unitarias, sistemas y de integración

MISION

Conocer en que se basan las pruebas unitarias, sistemas y de integración asi

como sus ventajas, características y requisitos para llevarlas a cabo.

VISION

Poder ejecutar de una manera correcta las pruebas unitarias, sistemas y de

integración durante un desarrollo de software para asi evitarnos tanto perdidas de
tiempo como de dinero.

ALCANCE

Desarrollar de manera amplia y concisa las pruebas unitarias, de integración y de

sistema.

3
 DESARROLLO
Pruebas unitarias

Las pruebas unitarias son las que aseguran que cada célula del código
desarrollado en un componente brinde los resultados adecuados. En estas
pruebas los desarrolladores observan la interfaz y la especificación de un
componente, proporcionando la documentación del desarrollo del código se
prueba exhaustivamente, claro que de forma independiente antes de pasar a otra
unidad.

Las pruebas unitarias admiten pruebas funcionales al ejercer el código que es más
probable que se rompa. Por ello, si usas pruebas funcionales sin pruebas
unitarias, puedes experimentar algunas dificultades para diagnosticar pruebas
fallidas. Así que tenlas muy presente.

Las pruebas unitarias o unit testing son una forma de comprobar que un fragmento
de código funciona correctamente. Es un procedimiento más de los que se llevan
a cabo dentro de una metodología ágil de trabajo.

Las pruebas unitarias consisten en verificar el comportamiento de las unidades

más pequeñas de su aplicación.

Técnicamente, eso sería una clase o incluso un método de clase en los lenguajes
orientados a objetos, y un procedimiento o función en los lenguajes
procedimentales y funcionales.

4
Funcionalmente, puede ser un conjunto de clases estrechamente relacionadas.
Como un `Ciervo` y sus clases de apoyo `Cabeza`, `Cola` y `Locomoción`.

Lo que consideres una unidad de trabajo es lo que tenga sentido para ti. No hay
reglas estrictas. Siempre y cuando le ayude a entender y pensar en su aplicación.

Eso es diferente a lo que es una prueba de unidad.

consisten en aislar una parte del código y comprobar que funciona a la perfección.
Son pequeños tests que validan el comportamiento de un objeto y la lógica.

El unit testing suele realizarse durante la fase de desarrollo de aplicaciones de

software o móviles. Normalmente las llevan a cabo los desarrolladores, aunque en
la práctica, también pueden realizarlas los responsables de QA.

Hay una especie de mito respecto a las pruebas unitarias. Algunos desarrolladores
están convencidos de que son una pérdida de tiempo y las evitan buscando
ahorrar tiempo.

Con ellas se detectan antes errores que, sin las pruebas unitarias, no se podrían
detectar hasta fases más avanzadas como las pruebas de sistema, de integración
e incluso en la beta.

Realizar pruebas unitarias con regularidad supone, al final, un ahorro de tiempo y

dinero.

Ventajas de realizar pruebas unitarias

5
Las pruebas unitarias demuestran que la lógica del código está en buen estado y
que funcionará en todos los casos.

 Aumentan la legibilidad del código y ayudan a los desarrolladores a

entender el código base, lo que facilita hacer cambios más rápidamente.

 Las pruebas unitarias bien realizados sirven como documentación del

proyecto.
 Se realizan en pocos milisegundos, por lo que podrás realizar cientos de
ellas en muy poco tiempo.

 Las unit testing permiten al desarrollador refactorizar el código más

adelante y tener la garantía de que el módulo sigue funcionando
correctamente. Para ello se escriben casos de prueba para todas las
funciones y métodos, para que cada vez que un cambio provoque un error,
sea posible identificarlo y repararlo rápidamente.

 La calidad final del código mejorará ya que, al estar realizando pruebas de

manera continua, al finalizar el código será limpio y de calidad.

 Como las pruebas unitarias dividen el código en pequeños fragmentos, es

posible probar distintas partes del proyecto sin tener que esperar a que
otras estén completadas.

6
Características de una buena prueba unitaria

 Las pruebas unitarias se tienen que poder ejecutar sin necesidad de

intervención manual. Esta característica posibilita que podamos
automatizar su ejecución.

 Las pruebas unitarias tienen que poder repetirse tantas veces como uno
quiera. Por este motivo, la rapidez de las pruebas tiene un factor clave.
Si pasar las pruebas es un proceso lento no se pasarán de forma
habitual, por lo que se perderán los beneficios que éstas nos ofrecen.

 Las pruebas unitarias deben poder cubrir casi la totalidad del código de
nuestra aplicación. Una prueba unitaria será tan buena como su
cobertura de código. La cobertura de código marca la cantidad de
código de la aplicación que está sometido a una prueba. Por tanto, si la
cobertura es baja, significará que gran parte de nuestro código está sin
probar

7
  Las pruebas unitarias tienen que poder ejecutarse independientemente
del estado del entorno. Las pruebas tienen que pasar en cualquier
ordenador del equipo de desarrollo.

 Las pruebas unitarias tienen que poder ejecutarse independientemente

del estado del entorno. Las pruebas tienen que pasar en cualquier
ordenador del equipo de desarrollo.

 Las diferentes relaciones que puedan existir entre módulos deben ser
simulada para evitar dependencias entre módulos.

 Es importante conocer claramente cuál es el objetivo de la prueba.

Cualquier desarrollador debería poder conocer claramente cuál es el
objetivo de la prueba y su funcionamiento. Esto sólo se consigue si se
trata el código de pruebas como el código de la aplicación

Las 3 A’s del unit testing

 Arrange (organizar). Es el primer paso de las pruebas unitarias. En esta

parte se definen los requisitos que debe cumplir el código.
 Act (actuar). Es el paso intermedio de las pruebas, el momento de ejecutar
la prueba que dará lugar a los resultados que deberás analizar.
 Assert (afirmar). En el último paso, es el momento de comprobar si los
resultados obtenidos son los que se esperaban. Si es así, se valida y se
sigue adelante. Si no, se corrige el error hasta que desaparezca.

8
Como ponerlas en uso

El proceso de las pruebas unitarias puede realizarse de manera manual, aunque

lo más común es automatizar el procedimiento a través de herramientas.

Hay muchas opciones disponibles, que varían en función del lenguaje de

programación que se esté utilizando. Estos son algunos ejemplos de este tipo de
herramientas que te ayudarán con las pruebas.

 xUnit: se trata de una herramienta de pruebas unitarias para el

framework .NET.

 Junit: es un conjunto de bibliotecas para realizar pruebas unitarias de

aplicaciones Java.

9
 NUnit: inicialmente portado desde JUnit, NUnit 3 se ha reescrito por
completo para dotarlo de nuevas características y soporte para una amplia
gama de plataformas .NET.

 PHPUnit: entorno de pruebas unitarias en el lenguaje de programación

PHP.


Al utilizar estas herramientas, se codifican los criterios en la prueba que

verificarán si el código es o no correcto. Durante la fase de ejecución, la
herramienta puede detectar las pruebas con errores.
Si alguno de estos errores es grave, puede detener pruebas posteriores
que iban a realizarse a continuación.

10
Pruebas de Integración

Las pruebas de integración dentro del software testing chequean la integración o

interfaces entre componentes, interacciones con diferentes partes del sistema,
como un sistema operativo, sistema de archivos y hardware o interfaces entre
sistemas. Las pruebas de integración son un aspecto clave del software testing.

Es esencial que un probador de software tenga una buena comprensión de los

enfoques de prueba de integración, para lograr altos estándares de calidad y
buenos resultados.

Objetivos de las pruebas de integración

 Reducir el riesgo de seguridad de la aplicación

 Verificar que el comportamiento del software entre las distintas interfaces es
el esperado
 Asegurar la confianza en la calidad de las interfaces
 Encontrar defectos en las comunicaciones
 Prevenir la aparición de defectos en fases posteriores de pruebas

Defectos encontrados habitualmente en las pruebas de integración

 Cálculos incorrectos
 Comportamiento incorrecto en aspectos funcionales y no funcionales
 Flujo incorrecto de la información entre los componentes

11
  Defectos únicamente reproducibles en entornos de producción
 Funcionamientos incorrectos respecto a la documentación del producto.

Niveles de pruebas de integración

Se diferencian dos niveles distintos de pruebas de integración.

Pruebas de integración de componentes

Principalmente enfocado en la interacción e interfaces entre los componentes

integrados.

Este tipo de pruebas debe realizarse de forma posterior a las pruebas unitarias.

En desarrollos ágiles, la integración de los distintos componentes, son

habitualmente parte de un proceso de integración continua.

Pruebas de integración de sistemas

En este caso, se centran en la interacción e interfaces entre distintos sistemas,

paquetes o microservicios

Aquí también entrarían las pruebas de interacciones con elementos externos a la

organización como, por ejemplo, servicios web (mail, almacenamiento cloud, redes
sociales, etc…) Esto supone un reto mayor al no tener todo el control de estos
elementos externos.

Las pruebas de integración de sistemas se pueden realizar tanto después de las

pruebas de sistema, como de forma paralela a ellas.

Estrategias de pruebas de integración

Big Bang

12
En las pruebas de integración de Big Bang, todos los componentes o módulos se
integran simultáneamente, después de lo cual todo se prueba como un todo.

Ventaja:

Las pruebas de Big Bang tienen la ventaja de que todo está terminado antes de
que comiencen las pruebas de integración.

Desventaja

La principal desventaja es que, en general, lleva mucho tiempo y es difícil rastrear

la causa de las fallas debido a esta integración tardía.

Ad Hoc

Con esta estrategia realizaremos las pruebas inmediatamente después de que el

componente ya se haya integrado.

Top Down

Las pruebas se llevan a cabo de arriba a abajo, siguiendo el flujo de control o la

estructura arquitectónica (por ejemplo, comenzando desde la GUI o el menú
principal). Los componentes o sistemas se sustituyen por stubs.

Ventajas

El producto probado es muy consistente porque la prueba de integración se realiza

básicamente en un entorno casi similar al de la realidad.

Los códigos auxiliares se pueden escribir en menos tiempo porque en

comparación con los controladores, los códigos auxiliares son más sencillos de
crear.

Desventajas

La funcionalidad básica se prueba al final del ciclo.

13
Down Top

Las pruebas se llevan a cabo desde la parte inferior del flujo de control hacia
arriba. Los componentes o sistemas se sustituyen por controladores.

Ventaja

En este enfoque, el desarrollo y las pruebas se pueden realizar juntos para que el
producto o la aplicación sea eficiente y de acuerdo con las especificaciones del
cliente.

Desventajas

Podemos detectar los defectos de la interfaz clave al final del ciclo.

Es necesario crear los controladores de prueba para los módulos en todos los
niveles excepto el control superior.

Hybrid

En algunos casos, puede ser una ventaja no seguir una estrategia de las
anteriores, sino una combinación de ellas.

Por ejemplo, la integración híbrida, es aquella que combina las estrategias Top
Down y Down Top.

Pruebas de sistema

Las pruebas del sistema tienen como objetivo ejercitar profundamente el sistema
comprobando la integración del sistema de información globalmente, verificando el
funcionamiento correcto de las interfaces entre los distintos subsistemas que lo
componen y con el resto de los sistemas de información con los que se comunica.

14
Son pruebas de integración del sistema de información completo, y permiten
probar el sistema en su conjunto y con otros sistemas con los que se relaciona
para verificar que las especificaciones funcionales y técnicas se cumplen. Dan una
visión muy similar a su comportamiento en el entorno de producción.

CONSLUSIÓN

Estas pruebas en especifico son demasiado importantes como pudimos observar

actualmente ya se pueden realizar de manera automatizada con diferentes
herramientas que nos ayudaran a aganar tiempo y sobre todo a tener menor
errores sin embargo estas herramientas también se pueden equivocar es por eso
que se recomienda la buena practica de estas ya tanto las pruebas unitarias,
integración y sistemas de complementan unas a otras.

15
 REFERENCIAS

Myers, G. J., Badgett, T., Thomas, T. M., & Sandler, C. (2004). The Art of Software
Testing (2 Rev Upd ed.). John Wiley & Sons Inc.

Foundations of Software Testing ISTQB Certification, 4th edition (4a edición).

(2019b). Cengage Learning EMEA.

Laboon, B. (2016). A Friendly Introduction to Software Testing (1. ed.).

Createspace Independent Publishing Platform.

16