UNIVERSIDAD NACIONAL DE LOJA

FACULTAD DE LA ENERGÍA, LAS INDUSTRIAS Y LOS RECURSOS NATURALES

NO RENOVABLES

CARRERA DE INGENIERÍA EN SISTEMAS

INGENIERÍA DEL SOFTWARE II

Nombre: Alexandra Patricia López Romero. Docente: Ing. José Guamán.

Ciclo: Noveno “A”. Fecha: 08 de junio de 2020.

Tema:

CONSULTA

TIPOS DE SOFTWARE

De acuerdo a muchos estudios los tipos de software son “Medios para definir claramente
el objetivo de un cierto nivel para un programa o proyecto”, es decir las pruebas de
software son cruciales para el desarrollo de aplicaciones. Si un producto no se prueba
correctamente, probablemente no funcionará tan bien como se esperaba y los usuarios le
informarán muy pronto si tienen problemas, además estas pruebas evalúan las aplicaciones
para detectar cualquier diferencia entre una entrada dada y su salida esperada.
A continuación, se describe algunos tipos de pruebas de software muy importante que se
debe conocer:

PRUEBAS DE SOFTWARE FUNCIONALES

Esta prueba se define a partir de funciones o características y su interoperabilidad con
sistemas específicos, pudiendo ejecutarse en
todos los niveles de pruebas, además se
encuentran las pruebas de Caja Negra (black-
box testing) puesto que valoramos el
comportamiento externo del sistema y las
pruebas de seguridad o las pruebas de
interoperabilidad entre sistemas o componentes
son casos especializados de las pruebas
funcionales. [1] Fig 1. Prueba de software Caja Negra
PRUEBAS DE SOFTWARE NO FUNCIONALES
Estas pruebas pueden ejecutarse en todos los niveles de pruebas la característica principal
de esta prueba es que se pueden medir de diversas maneras, normalmente se considera el
comportamiento externo del sistema, en la mayoría de los casos se utilizan técnicas de
Prueba Negra o se incluyen pruebas de: Rendimiento, Carga, Estrés, Usabilidad,
Mantenibilidad, Fiabilidad o Portabilidad [2].
PRUEBAS DE SOFTWARE
ESTRUCTURALES
Igual que las demás pruebas se
ejecutan en todos los niveles de
pruebas y encajan muy bien si se utiliza
las técnicas de especificación de la
estructura o arquitectura del software.
Fig 2. Prueba de software Caja Blanca

Además, este utiliza las herramientas de apoyo para calcular la cobertura del código en
el caso de Pruebas de Componentes o en Pruebas de Integración de Componentes aquí
se destaca las pruebas de Caja Blanca (white-box testing) [1].

PRUEBAS DE SOFTWARE DE REGRESIÓN Y LAS RE-PRUEBAS

Esta prueba consiste en volver a probar un componente, tras haber sido modificado, para
descubrir cualquier defecto introducido, o no cubierto previamente, como secuencia de
los cambios. Los defectos pueden encontrarse
tanto en el software que se ha cambiado como en
algún otro componente.
Se ejecutan cuando se cambia el software o su
entorno, el criterio para decidir la extensión de
estas pruebas de regresión esta basado en el
riesgo de no encontrar defectos en el software que
anteriormente estaba funcionando correctamente
[5].
Fig 3. Prueba de software de Regresión

Los conjuntos de pruebas de regresión suelen ser bastante estables por lo que son muy
buenos candidatos para actividades de automatización de pruebas software.
PRUEBAS UNITARIAS (Unit test)
Estas pruebas también como pruebas de código las cuales permiten validar que el código
escrito cumpla con los casos programados.
Este tipo de pruebas consiste en probar de forma individual las funciones y/o métodos,
debido a lo específico que son, generalmente son las pruebas automatizadas de menor
coste, y pueden ejecutarse rápidamente por un servidor de integración continua [6].

Cuando se habla de Test Driven Development, se hace referencia a las pruebas unitarias,
es decir, se usan este tipo como especificaciones de lo que el código debe hacer.

PRUEBAS DE INTEGRACIÓN (Integration test)

Las pruebas de integración permiten validar la comunicación de la aplicación con
componentes y servicios externos y a la vez ver como se comportan estos con data válida
e inválida.
Las pruebas de integración son típicamente el paso siguiente a las pruebas unitarias y son
generalmente más costosas de ejecutar ya que requieren más partes de nuestra aplicación
se configure y se encuentra en funcionamiento [2].

PRUEBAS CON EL USUARIO

Estas pruebas las realiza el usuario final que va utilizar el aplicativo y consiste en validar
que el aplicativo realmente funcione, así como se lo pensó.
Usualmente en estas pruebas el usuario no está conforme con el aplicativo por lo que
siempre se pedirá que realice algunos ajustes a su forma dependiendo de las
funcionalidades del producto owner o analista de negocio [8].
PRUEBAS DE PUNTA A PUNTA (End-to-end)
Estas pruebas replican el comportamiento de los usuarios con el software, en un entorno de
aplicación completo además que verifican que los flujos que sigue un usuario trabajan
como se espera, y se pueden ser tan simples o muy complejas.
Las pruebas end-to-end son muy útiles, pero son costosas de realizar y pueden ser difíciles
de mantener cuando son automatizadas por eso es recomendable realizar o tener pocas
pruebas para que resulten pruebas a bajo nivel para detectar rápidamente aquellos
cambios que impactan negativamente sobre nuestra aplicación [6].
PRUEBAS DE HUMO (Smoke testing)
La prueba de humo es un método de prueba de integración que es comúnmente utilizada
cuando se ha desarrollado un software “empaquetado”. Es diseñado como un mecanismo
para proyectos críticos por tiempos, permitiendo que el equipo de software valore su
proyecto sobre una base sólida, aquellas pruebas verifican la funcionalidad básica de
una aplicación.

PRUEBAS DE ACEPTACIÓN (Acceptance testing)

Son pruebas formales, ejecutadas para verificar si un sistema satisface sus requerimientos de
negocio. Estas pruebas requieren que el software se encuentre en funcionamiento, y se
centran en replicar el comportamiento de los usuarios, a fin de rechazar cambios si no se
cumplen los objetivos [7].
Para que este tipo de pruebas se lleve a cabo correctamente resulta importante que los
responsables del proyecto definan criterios de aceptación justo antes de empezar a
trabajar en el mismo.

PRUEBAS DE RENDIMIENTO (Perfomance testing)

Estas pruebas verifican cómo responde el sistema cuando éste se encuentra bajo una alta
carga por naturaleza son bastantes costosas de implementar y ejecutar, pero pueden
ayudarnos a comprender si nuevos cambios van a degradar nuestro sistema.
Las pruebas de rendimiento no fallan del mismo modo que fallan las demás pruebas, su
objetivo principal es recolectar métricas y definir objetivos por alcanzar además es muy
bueno utilizar es tipo de pruebas ya que en lanzamientos nuevos se refactoriza código [8].

PRUEBAS EXPLORATORIAS (Exploraty testing)

Este tipo de prueba no debe exceder más de 2 horas, y es necesario tener bien definido
el alcance, para ayudar a los evaluadores a centrarse en un área específica del software.
Este tipo de pruebas resulta costoso por naturaleza, pero permite descubrir errores en la UI
y verificar flujos complejos que siguen los usuarios.
Resulta útil principalmente cuando se agrega una nueva característica importante a nuestra
aplicación, para ayudar comprender cómo se comporta en casos extremos [3].

PRUEBAS DE ESTRÉS
Este tipo de pruebas “consiste en saturar la aplicación para saber dos cosas, la primera
para saber cuánto es lo máximo que puede soportar una aplicación a nivel de usuarios y
que recursos consumiría en este momento y la segunda es para saber que cuellos de botella
hay en nuestra aplicación de un banco debe ser estresada mediante una prueba de estrés
para saber el límite y reconocer hasta cuantos usuarios puede soportar y si es necesario
poner más recursos para la aplicación” [4].
CONCLUSIONES

- Las pruebas son muy importantes para asegurar que lo que hemos realizado funcione
de acuerdo a lo estipulado por la empresa.

- Las pruebas de software también son una parte de código por lo importantes utilizarlas
durante los “code review” ya que son un paso importante para el pase de producción.

- Las pruebas del software se utilizan para verificar que el sistema esté funcionando
adecuadamente y no se presente acciones inesperadas.

- En la actualidad las empresas buscan desarrolladores de software que apliquen y

desarrollen pruebas automatizadas para el buen funcionamiento del software.

- Las pruebas unitarias son muy importantes para un desarrollador ya que puede observar
si el software esta realmente cumpliendo con lo definido y si perteneces a un grupo
puedes aplicar de pruebas funcionales, integración, de humo, etc.

BIBLIOGRAFÍA

[1]"Tipos de pruebas de software", Es.slideshare.net, 2020. [Online]. Available:

https://es.slideshare.net/xpjair/tipos-de-pruebas-de-software-16980977.

[2]"Introducción de pruebas de software", Es.slideshare.net, 2020. [Online]. Available:

https://es.slideshare.net/mstabare/introduccin-de-pruebas-de-software.

[3]J. A., "Prueba de Software o QA: Importancia y qué tipos existen - Johana Chuquino -
Transformación Digital - Business Agility - Agile Coach - Speaker, 2020. [Online].
Available: http://johanachuquino.com/qa-7-tipos-de-pruebas-para-software/.

[4]"Tipos de prueba: sobre sus subtipos, herramientas y especificaciones.", EasyQA,

2020. [Online]. Available: https://geteasyqa.com/es/qa/software-testing-types/.

[5]"Software QA - ¿Cuáles son los tipos de pruebas software?", Panel Sistemas, 2020.
[Online]. Available: https://www.panel.es/blog/software-qa-cuales-son-los-tipos-de-
pruebas-software/.
 [6]J. Ramos, "Los diferentes tipos de Pruebas de software", Programacionymas.com,
2020. [Online]. Available: https://programacionymas.com/blog/tipos-de-testing-en-
desarrollo-de-software.

[7]T. SOFTWARE, "TIPOS DE PRUEBAS DE SOFTWARE", Ing-sw.blogspot.com, 2020.

[Online]. Available: http://ing-sw.blogspot.com/2005/04/tipos-de-pruebas-de-
software.html.

[8]"Tipos de pruebas de software", Es.slideshare.net, 2020. [Online]. Available:

https://es.slideshare.net/GuillermoLemus/tipos-de-pruebas-de-software.