Este documento describe diferentes tipos de pruebas de software, incluyendo pruebas de rendimiento, pruebas funcionales realizadas por el cliente, pruebas de regresión y pruebas de caja negra. Explica que las pruebas de rendimiento evalúan el sistema bajo condiciones de trabajo particulares para validar atributos como escalabilidad y uso de recursos.

1. Carreño Cristy
Cona Yessica
Chavez Jean
Garcia Gabriel
Toro Edgardo

2. Este es el tipo más sencillo de
pruebas de rendimiento. Una prueba de
carga se realiza generalmente para
observar el comportamiento de una
aplicaciones bajo una cantidad de
peticiones esperada. Esta carga puede
ser el número esperado de usuarios
concurrentes utilizando la aplicación y
que realizan un número específico de
transacciones durante el tiempo que
dura la carga. Esta prueba puede
mostrar los tiempos de respuesta de
todas las transacciones importantes de
la aplicación. Si la base de datos el
servidor de aplicaciones, etc. También
se monitorizan, entonces esta prueba
puede mostrar el cuello de botella en la
aplicación.

3. Se realizan las funciones especificadas, Pruebas relacionadas con el
rendimiento del sistema:
•Rendimiento (tiempos de respuesta adecuados)
•Volumen (funcionamiento con grandes volúmenes de datos)
• Sobrecarga (funcionamiento en la Disponibilidad de datos (cuando se
produce una recuperación ante fallos)
• Facilidad de uso (usabilidad) de desarranque, actualización de
Operación e instalación (operaciones software)
•Entorno (interacciones con otros sistemas) y
•comunicaciones Seguridad (control de acceso e intrusiones)

4. Tipo de pruebas de software que se realiza
sobre las funciones internas de un módulo.
Entre las técnicas usadas se encuentran; la cobertura de
caminos (pruebas que hagan que se recorran todos los
posibles caminos de ejecución), pruebas sobre las
expresiones lógico-aritméticas, pruebas de camino de
datos (definición-uso de variables), comprobación
de bucles (se verifican los bucles para 0,1 y n
iteraciones, y luego para las iteraciones
máximas, máximas menos uno y más uno).

5. Es aquel elemento que es estudiado desde
el punto de vista de las entradas que
recibe y las salidas o respuestas que
produce
En otras palabras, de una caja negra nos interesará su forma de interactuar con
el medio que le rodea, entendiendo qué es lo que hace, pero sin dar importancia
a cómo lo hace.

6. Estas pruebas las realiza el cliente.
Son básicamente pruebas
funcionales, sobre el sistema
completo, y buscan una cobertura de
la especificación de requisitos y
del manual del usuario.
La experiencia muestra que aún
después del más
cuidadoso proceso de pruebas por
parte del desarrollador, quedan una
serie de errores que sólo aparecen
cuando el cliente comienza a usarlo.

7. Es 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
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.

8. Son las pruebas que se realizan, desde una perspectiva, para determinar lo
rápido que realiza una tarea un sistema en condiciones particulares de trabajo.
También puede servir para validar y verificar otros atributos de la calidad del
sistema, tales como la escalabilidad, fiabilidad y uso de los recursos. Las
pruebas de rendimiento son un subconjunto de la ingeniería de pruebas, una
práctica informática que se esfuerza por mejorar el rendimiento, englobándose
en el diseño y la arquitectura de un sistema, antes incluso del esfuerzo inicial
de la codificación.

9. Las pruebas de prestaciones, enmarcadas dentro de lo que se viene a
llamar Calidad Operacional o Calidad de Servicio son, hoy en día, cada
vez más necesarias: los tiempos de respuesta por encima de lo
aceptable, la excesiva variabilidad de los mismos en función de la carga
del sistema y los problemas de fiabilidad o disponibilidad deben de
considerarse errores tan graves como los de funcionalidad.

10. •Se reúne a desarrolladores y
críticos
• Los críticos se leen el código
línea a línea y piden
explicaciones a
los desarrolladores
•Eficaz para errores de
naturaleza local
•Pésima para localizar fallos en
interacciones entre partes
alejadas

11. Esta prueba esta basada en la introducción deliberada de diferentes
códigos externos al programa (bugs) para reexaminar si estos bugs
pueden ser detectados. Requiere gran disponibilidad de recursos de
computación. En otras palabras es Introducir errores a propósito para
verificar la bondad de las pruebas

12. Esto viene al caso de que comúnmente uno define los escenarios de
Performance o de pruebas de Carga de la manera: “La aplicación debe
soportar un máximo de 250 usuarios concurrentes” poniendo implícitamente
la cantidad de usuarios concurrentes como parámetro de entrada para las
pruebas.

13. Esto se consigue mediante el uso
de un dispositivo especial de
prueba (test Fixture), cuyas
terminales de contacto (pogo-
pins) coinciden con los puntos de
conexión de la tarjeta de circuito
impreso que están en el lado de
las pistas.