No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Pruebas de caja de cristal

26/31
Recursos

Aportes 145

Preguntas 41

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

El testing tambien es un campo interesante,
Aqui la lista de los ** 7 principios de Testing ** de acuerdo al libro de ISTQB.

1 Las pruebas muestran la presencia de defectos
Significa que las pruebas pueden demostrar que EXISTEN problemas, pero no que los problemas NO EXISTEN.
El objetivo principal de llevar a cabo una prueba es para detectar defectos. Trabajando bajo la premisa de que cada producto contiene defectos de algún tipo, una prueba que revela los errores es generalmente mejor que una que no lo hace. Todas las pruebas por lo tanto, deben ser diseñados para revelar tantos errores como sea posible

2 Las pruebas exhaustivas son imposibles
Las pruebas exhaustivas tratan de cubrir todas las combinaciones posibles de datos en el software, a fin de garantizar que ninguna situación puede surgir, una vez probado el software se ha liberado. Excepto en aplicaciones muy simples, el número de combinaciones posibles de datos es demasiado alta, es más eficaz y eficiente que los ingenieros de pruebas se centren en las funcionalidades de acuerdo a riesgos y prioridades.

3 Pruebas tempranas.
Un producto (incluyendo los documentos, tales como la especificación del producto) se puede probar tan pronto como se ha creado. ISTQB recomienda probar un producto tan pronto como sea posible, corregir los errores más rápidamente posible. Los estudios han demostrado que los errores identificados al final del proceso de desarrollo por lo general cuestan más para resolver.
Por ejemplo: un error encontrado en las especificaciones puede ser bastante sencillo de solucionar. Sin embargo, si ese error se transfiere a la codificación de software, una vez descubierto el error puede ser muy costoso y consume tiempo.

4 Agrupamiento de Defectos
Los estudios sugieren que los problemas en un elemento de software tienden a agruparse en torno a un conjunto limitado de módulos o áreas. Una vez que estas áreas han sido identificadas, los administradores eficientes de prueba son capaces de enfocar las pruebas en las zonas sensibles, mientras que siguen buscando a los errores en los módulos de software restantes. Me recuerda al 80/20.

5 La paradoja del “Pesticida”
Al igual que el sobre uso de un pesticida, un conjunto de pruebas que se utilizan repetidamente en el disminuirá en su eficacia. Usando una variedad de pruebas y técnicas expondrá una serie de defectos a través de las diferentes áreas del producto.

6 La prueba es dependiente del contexto
Las mismas pruebas no se deben aplicar en todos los ámbitos. Distintos productos de software tienen diferentes requisitos, funciones y propósitos. Una prueba diseñada para realizarse en un sitio web, por ejemplo, puede ser menos eficaz cuando se aplica a una aplicación de intranet. Una prueba diseñada para una forma de pago con tarjeta de crédito puede ser innecesariamente rigurosa si se realiza en un foro de discusión.
En general, cuanto mayor es la probabilidad y el impacto de los daños causados ​​por el software fallado, mayor es la inversión en la realización de pruebas de software.

7 La falacia de ausencia de errores
Declarar que una prueba no ha descubierto ningún error no es lo mismo que declarar que el software es “libre de errores”. Con el fin de garantizar que los procedimientos adecuados de software de prueba se lleva a cabo en todas las situaciones, los evaluadores deben asumir que todo el software contiene algunos (aunque disimulada) errores.

if __name__ == '__main__':
    unittest.main(verbosity=2)

Se le puede agregar el parámetro verbosity=2 al método unittest.main para que el resultado en la consola sea mas detallado.

Les dejo el links a mis apuntes https://github.com/karlbehrensg/introduccion-pensamiento-computacional

Pruebas de caja de cristal

Se basan en el flujo del programa, por lo que se asume que conocemos el funcionamiento del programa, por lo que podemos probar todos los caminos posibles de una función. Esto significa que vamos a probar las ramificaciones, bucles for y while, recursiónes, etc.

Este tipo de pruebas son muy buenas cuando debemos realizar:

  • Regression testing o mocks: descubrimos un bug cuando corremos el programa, por lo que vamos a buscar el bug gracias a que conocemos como esta estructurado el código.

No hay que entender el aspecto técnico al 100%.

.
Solo tienes que quedarte con que estas herramientas se utilizan para prevenir -
futuros errores.
.
Como cuando un arquitecto dibuja el plano de una casa que se va a construir y -
determina que las ventanas deben ser rectangulares.

Si el albañil instala ventanas circulares la forma más sencilla de detectar un error es volver al plano original.
.

Las ventanas circulares cumplen la misma función que unas rectangulares pero-
están fuera del contexto que se le prometió al futuro dueño de la casa.
.

Con Unittest


podemos establecer algo similar a un plano como la base de desarrollo de forma que nuestro código no se salga de contexto.

La diferencia entre las pruebas de Caja Negra y Caja de Cristal es que en las pruebas de caja negra se escriben primero los test para ayudarnos a implementar nuevo código. En las pruebas de caja de cristal se asume que se tiene código escrito y las pruebas se escriben para verificar todas las ramificaciones del programa y probar todos los diferentes caminos posibles.

La mejor manera de entender algo es con ejemplos del mundo real para poder relacionar el concepto tecnológico con algo que conocemos.

caja negra testing sería el cual una persona haría antes de comprar un coche, encender las luces, encender el motor entre otras pruebas (Sin necesidad de saber cómo funciona el coche por dentro)

realizar pruebas de tipo caja de cristal sería la técnica que usa un mecánico cuando llevas tu coche al mecánico y tiene que buscar una avería.

Fuente: https://www.testermoderno.com/caja-blanca-vs-caja-negra/

Por si alguien se pregunta esto, assertEqual() lo que hace es comprar el resultado de tu función con el resultado que tu esperabas, assertEqual(<resultado de función>, <resultado que esperabas>) y si estos dos son iguales, el test es correcto.

No se si alguien mas lo noto pero si las funciones declaradas dentro de la clase de unittest no empiezan con test, no se contemplado al momento de hacer las pruebas, por ejemplo si corres el siguiente codigo que en ambas funciones deberia marcar error no te marcara ninguno:

import unittest


def mayor_edad(edad):
    if edad >= 18:
        return True
    else:
        return False


class PruebaDeCristalTest(unittest.TestCase):
    
    def es_mayor(self):
        edad = 15
        result = mayor_edad(edad)

        self.assertEqual(result, True)

    def es_menor(self):
        edad = 100
        result = mayor_edad(edad)

        self.assertEqual(result, False)


if __name__ == '__main__':
    unittest.main()

Ahora aqui el mismo codigo solo que las funciones empiezan con test:

import unittest


def mayor_edad(edad):
    if edad >= 18:
        return True
    else:
        return False


class PruebaDeCristalTest(unittest.TestCase):
    
    def test_es_mayor(self):
        edad = 15
        result = mayor_edad(edad)

        self.assertEqual(result, True)

    def test_es_menor(self):
        edad = 100
        result = mayor_edad(edad)

        self.assertEqual(result, False)


if __name__ == '__main__':
    unittest.main()

Espero le sirva este aporte a alguien y sepan que es importante añadir al nombre de la función la palabra test al inicio 😃

Si alguien desea tener sus apuntes en jupyter notebook o en google colab y correr estas pruebas deben agregar
argv=[‘first-arg-is-ignored’], exit=False al unittest.main() así:

unittest.main(argv=['first-arg-is-ignored'], exit=False)

Hola.
La diferencia es que las pruebas de caja negra se realiza teniendo en cuenta los datos de entrada y de salida, sin aun tener una idea de como se va a realizar la lógica del programa, mientras que las pruebas de caja de cristal o caja blanca, como también se le suele llamar, se centra en el procedimiento que tiene el programa, por lo que la implementación de esta prueba esta fuertemente ligada al código que realices.
Saludos.

Cual sería entonces la diferencia con la pruebas de caja negra? Veo que la implementación es igual.

buenas compañeros pueden revisar otros usos e inclusive algunos ejemplos de como se utilizan estas pruebas, y obviamente que más puedes hacer leyendo la documentación de la librería unittest acá:
https://docs.python.org/3/library/unittest.html
nota está en ingles, pero es la documentación oficial.

Normalmente los test se corren en archivos aparte? O debería ser parte del código. Osea, si pasa el test, recién se ejecuta la función.

Acá un articulo que me ayudó a entender:

"Entrando ya de lleno en el tema del testing en la programación pura, que es lo que realmente nos interesa, ¿Cuál sería una definición más concreta del testing en este ámbito? El testing en programación se refiere a la comprobación de que todo el código que se ha escrito funciona.

Por ejemplo, si estamos diseñando una app para pedir taxis, tendremos que comprobar que cuando el usuario abre la app, le aparece un mapa con su posición actual y un botón para pedir un taxi; que al apretar el botón de “pedir un taxi” lo lleva a una pantalla para elegir la hora; que después va a la pantalla de confirmar y que, cuando acaba el viaje, le sale el botón de pagar.

Pero ojo, también probamos si la app responde bien ante los errores. Por ejemplo, que, si no hay taxis, le aparezca el mensaje de error correspondiente; que si no tiene internet le aparezca un mensaje indicándolo; que cuando el pago falla, le aparezca una interfaz para volverlo a intentar."

https://diegolaballos.com/podcast/40-que-es-y-para-que-sirve-el-testing-en-programacion/#:~:text=El testing en programación se,que se ha escrito funciona.

En Test Development se escriben los Test antes de escribir el código. EN las Pruebas de Caja de Cristal ya existe el código, ya está escrito y se corren los test sobre dicho código, en todos y cada uno de sus módulos y para todas y cada una de las posibilidades del módulo.

import unittest

def es_mayor_de_edad(edad):
    if edad>=18:
        return False
    else:
        return False

class PruebaDeCristalTest(unittest.TestCase):

    def test_es_mayor_de_edad(self):
        edad=20
        resultado=es_mayor_de_edad(edad)
        self.assertEqual(resultado, True)
    def test_es_menor_de_edad(self):
        edad =15
        resultado=es_mayor_de_edad(edad)
        self.assertSetEqual(resultado,False)    

if __name__ == "__main__":
    unittest.main()```

Notas 😃
Pruebas de caja de cristal

  • Se basan en el flujo del programa.
  • Prueba todos los caminos posibles de una función. Ramificaciones, bucles for y while, recursión.
  • Sirve para regression testing o mocks. Esto es, cuando ya se liberó el programa pero descubrimos un bug que queremos arreglar.
    • if: Debemos probar todas las condiciones.
    • for y recursión: Una donde no entre, otro donde entre una vez y otra donde entre varias.
    • while: Donde la condición de entrada sea falsa y otra donde probemos los break statements.
  • También debemos probar todas las excepciones.
import unittest   

def es_mayor_de_edad(edad):
    if edad >= 18:
        return True
    else:
        return False

class PruebaDeCristalTest(unittest.TestCase):
    
    def test_es_mayor_de_edad(self):
        edad = 20
        resultado = es_mayor_de_edad(edad)
        
        self.assertEqual(resultado, True)
        
    def test_es_menor_de_edad(self):
        edad = 16
        resultado = es_mayor_de_edad(edad)
        
        self.assertEqual(resultado, False)

if __name__ == '__main__':
    unittest.main()

Concepto


‎ ‏‏‎
La prueba de caja de cristal es un método de testing de software que examina la funcionalidad de una aplicación asumiendo que sabe acerca de la estructura interna de nuestro programa. Las pruebas que realiza se basa en probar todos los caminos posibles de una función, es decir: ramificaciones, bucles como for o while, y también la recursión.
‎ ‏‏‎‏‏‎

Diferencias entre caja negra y caja de cristal


‎ ‏‏‎

  1. En Caja Negra, las pruebas se efectúan sin el conocimiento de la estructura interna del programa o la aplicación, mientras que en Caja de Cristal las pruebas se realizan con el conocimiento de la estructura interna del pgm.
    ‎ ‏‏‎
  2. En Caja Negra, las pruebas no requieren conocimientos de programación, sin embargo, en Caja de Cristal tienen el objetivo principal de probar el programa de manera interna, y esto obviamente requiere conocimientos en estos temas.
    ‎ ‏‏‎
  3. En Caja Negra, las pruebas se centran en la perspectiva del usuario final o externo, mientras que las pruebas de Caja de Cristal se centran en la estructura del código, las condicionales, las rutas y las ramas.
    ‎ ‏‏‎
  4. En Caja Negra, las pruebas son un proceso que no requiere mucho tiempo, mientras que en las pruebas de Caja de Cristal son un proceso más tardío.
    ‎ ‏‏‎

Criterios al elegir entre las dos


‎ ‏‏‎
Los test de caja negra:
Son implementadas cuando no conoces la estructura interna del código, este tipo de cajas son realizadas por ingenieros que no están involucrados en el desarrollo de la aplicación y los cuales se limitan a probar la funcionalidad desde una perspectiva del usuario.
‎ ‏‏‎
Los test de caja de cristal:
Son implementadas cuando conoces la estructura del código y son realizadas para probar la funcionalidad todos los componentes. Normalmente esta es la elección que toman los desarrolladores o programadores de la aplicación.

Las pruebas de Caja de Cristal

Se basan en el flujo del programa

prueba todos los caminos posibles de una funcion. (ramificaciones, bucles for y while, recursion.

Regression testing o mocks.

![](urlhttps://s3-us-west-2.amazonaws.com/secure.notion-static.com/9e84a4d2-2c43-4784-878e-f44268d864c6/Untitled.png](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/9e84a4d2-2c43-4784-878e-f44268d864c6/Untitled.png)

aqui la prueba de cristal salio correcta porque el parametro de la funcion es correcto ya que 20 es mayor de edad

Pero si tuvieramos una falla o pusieramos un error a la hora de hacer el test nos saldria negativo el resultado.

Tiene sentido porque una es Black Box y otra White Box o GlassBox.

Si tengo 100 funciones, entonces tendía que escribir 1oo pruebas unitarias?....El código se duplica

Las pruebas de caja de cristal (también son conocidas como pruebas de caja blanca o pruebas estructurales) se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente.

[1:31] Si tenemos un while loop, lo que queremos probar son dos cosas, una prueba donde la condición de entrada sea falsa y una prueba en donde veamos los break statements y cómo se comportan.

Sin duda el testing es tan importante como la programacion misma; despues de todo los humanos cometemos muchos errores de manera seguida. Antes las ‘computadoras’ humanas que hacian todos los calculos a mano cometian errores al resolverlos, me pregunto si en algun momento veremos a los programadores como vemos ahora a las computdoras.

Muy bien explicado!!

estructura codigo----unittest-----caja de cristal

estructura codigo----unittest-----caja de cristal

Hay más métodos además del assertEqual(), por ejemplo:

self.assertTrue()
self.assertFalse()
self.assertRaises()

Asumo que son bastante auto descriptivos pero por si a caso el primero y el segundo sirven para corroborar una condición que ha de cumplirse y el último para corroborar que se ‘levante’ una excepción específica.

Además me gustaría agregar que se puede hacer que la impresión de los resultados en la consola sean más verbales si corremos el flag -v corriendo el unittest desde consola:

python3 -m test_module.py -v

Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o pruebas estructurales) se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente, lo cual, esto significa que tenemos que realizar un “estudio”, o más bien, un análisis de nuestro código, para esto, existen tres pautas fundamentales para poder realizar con éxito una prueba de caja blanca.

Pruebas de cubrimiento: Se trata básicamente de ejecutar al menos una vez cada sentencia. Pero para cumplir con las pruebas de cubrimiento se necesitan varios casos de prueba:

Determinar posibles «caminos» independientes.
Cada condición debe cumplirse en un caso y en otro no.
Y puede ser imposible cubrir el 100%
Código que nunca se ejecuta: condiciones imposibles

Estaba tratando de ejecutar el código, pero no me entrega ninguna salida en pantalla.

import unittest


def es_mayor_de_edad(edad):
    if edad >= 18:
        return True
    else:
        return False


class PruebaDeCristalTest(unittest.TestCase):

    def test_es_mayor_de_edad(self):
        edad = 20

        resultado = es_mayor_de_edad(edad)

        self.assertEqual(resultado, True)
    
    def test_es_menor_de_edad(self):
        edad = 15

        resultado = es_mayor_de_edad(edad)

        self.assertEqual(resultado, False)

if __name__ == '__nain__':
    unittest.main()

Así lo estaba haciendo, ¿alguien ve algo malo? Lo comparé con el código que está en la sección de Archivos y a mi parecer está igual.

Excelente!

Pruebas de caja de cristal: Son pruebas que se basan en el flujo del programa al contrario de las pruebas de caja negra que solamente ingresamos inputs y validamos los outputs. En este caso las pruebas de caja de cristal asumen que nosotros conocemos el proceso de implementacion y que podemos probar todas las diferencias o todos los caminos que existen dentro de la funcion. Ejemplo si tenemos un if se tienen que probar todas sus condiciones.


* Se basan en el flujo del programa
* Prueba todos los caminos posibles de una funcion. Ramificaciones, bucles for y while, recursion.
* Regression testing o mocks.

Ejemplo de prueba de caja de cristal:

import unittest
def es_mayor_de_edad(edad):
    if edad >= 18:
        return True
    else:
        return False
class PruebaDeCristalTest(unittest.TestCase):
    def test_es_mayor(self):
        edad = 20
        resultado = es_mayor_de_edad(edad)
        self.assertEqual(resultado, True)
    def test_es_menor(self):
        edad = 17
        resultado = es_mayor_de_edad(edad)
        self.assertEqual(resultado, False)
if __name__ == '__main__':
    unittest.main()```

Amigos comparto un enlace donde amplían la explicación 😃

Interesante, nunca he implementado pruebas en mi código, creo que es hora de hacerlo, porque siempre me ando quebrando la cabeza cuando ya está hecho…

Es muy necesario el uso de los mocks cuando se esta desarrollando con microservicios debido a la gran cantidad de clases que se crean

python me sorprende cada vez mas

buenardo

Hola!,aunque si bien el código está bien, me sale failure,alguno sabe por que?

# -*- coding:utf-8 -*-
#2°método debug,asume que nosotros sabemos la implementacion,a diferencia de la caja negra,por lo que no tenemos que escribir el test driven development

import unittest

age = int(input('Cuántos años tenes?: '))
disease = input('Tenés alguna enfermedad que perjudique de algún modo a tu sistema autoinmune?(y/n): ')

message_more_or_equal_than_50='Usted se encuentra dentro del sector de riesgo,además de lavarse las manos,evite salir de su hogar,y en caso de necesitar compras o urgencias,comuniquese con el número proporcionado por el gobierno'
message_less='Usted no se encuentra en el sector de riesgo,pero de igual manera, evite exponerse ante multitudes y lavese las manos frecuentemente'

def avisos_segun_edad(age,disease):
    """Funct lance avisos de precaución segun edad(covid19)
    if age>=number
    return message_n
    """
    
    if age >= 50 or disease == 'y':
       return print(message_more_or_equal_than_50)
    else:
        return print(message_less)




class PruebaDeCristalTest(unittest.TestCase):
    
    def test_avisos_segun_edad_mayor_o_igual(self):
        age = 50

        resultado = avisos_segun_edad(age,disease)

        self.assertEqual(resultado, message_more_or_equal_than_50)

    def test_avisos_segun_edad_menor(self):
        age = 21

        resultado = avisos_segun_edad(age,disease)

        self.assertEqual(resultado, message_less)


if __name__ == "__main__":
    unittest.main()

[7:25] Los test son una forma de proteger nuestro código de nuestro yo futuro.

Gracias a las pruebas de caja negra y de cristal, se puede tener una mejor escalabilidad de los programas desarrollados.

Estimado ¿Como hago para que mi consola me muestre los errores e ese formato mas ordenado que usa el profesor? uso VSC y el error me lo muestra en la tarminal pero sale feo ajajajaj cuesta leer y encontrar el error señalado, gracias

Es mejor prevenir que lamentar, así se demore un poco más…

import unittest

def es_mayor_de_edad(edad):
    if edad >= 21:
        print('Es mayor de edad')
        return True
    else:
        print('Es menor de edad')
        return False


class PruebaDeCristalTest(unittest.TestCase):
    def test_es_mayor_de_edad(self):
        edad = 23

        resultado = es_mayor_de_edad(edad)

        self.assertEqual(resultado,True)

    def test_es_menor_de_edad(self):
        
        edad = 15

        resultado = es_mayor_de_edad(edad)

        self.assertEqual(resultado,False)


if __name__ == '__main__':
    unittest.main()
Si te gusta criticar el trabajo de los demas y eres bien picky, tengo el trabajo perfecto para ti! QA!!!
<https://platzi.com/discusiones/1764-python-cs/300968-cual-es-la-diferencia-entre-un-caja-negra-y-una-caja-de-cristal/>
```js import unittest def es_mayor_de_edad(edad): if edad >= 18: return True else: return False class PruebaDeCristalTest(unittest.TestCase): def test_es_mayor_de_edad(self): edad = 20 resultado = es_mayor_de_edad(edad) self.assertEqual(resultado, True) def test_es_menor_de_edad(self): edad= 15 resultado = es_mayor_de_edad(edad) self.assertEqual(resultado, False) if __name__ == "__main__": unittest.main() ```import unittest def es\_mayor\_de\_edad(edad):    if edad >= 18:        return True    else:        return False    class PruebaDeCristalTest(unittest.TestCase):        def test\_es\_mayor\_de\_edad(self):        edad = 20         resultado = es\_mayor\_de\_edad(edad)         self.assertEqual(resultado, True)     def test\_es\_menor\_de\_edad(self):        edad= 15         resultado = es\_mayor\_de\_edad(edad)         self.assertEqual(resultado, False) if \_\_name\_\_ == "\_\_main\_\_":    unittest.main()

26. Pruebas de caja de cristal

  • Se basan en el flujo del programa.
  • Prueba todos los caminos posibles de una función. Ramificaciones, bucles for y while, recursión.
  • Regression testing o mocks.
import unittest

def es_mayor_de_edad(edad):
    if edad >= 18:
        return True
    else:
        return False
    

class PruebaDeCristalTest(unittest.TestCase):
    
    def test_es_mayor_de_edad(self):
        edad = 20
        
        resultado = es_mayor_de_edad(edad)
        
        self.assertEqual(resultado, True)

    def test_es_menor_de_edad(self):
        edad = 15

        resultado = es_mayor_de_edad(edad)

        self.assertEqual(resultado, False)

if __name__ == '__main__':
    unittest.main()

White testing


.
Las “pruebas de caja de cristal” (también conocidas como pruebas de caja blanca) son pruebas que se centran en la estructura interna del código de un programa y verifican que funciona correctamente. Estas pruebas se realizan a nivel de código y se diseñan para probar todos los caminos posibles que puede tomar el código.
.
Regression testing, por otro lado, es un tipo de prueba que se realiza para asegurarse de que los cambios realizados en el código no afecten el funcionamiento de las funcionalidades existentes. En otras palabras, se trata de volver a ejecutar las pruebas que se realizaron previamente para asegurarse de que todo sigue funcionando correctamente después de los cambios.
.
En Python, se pueden utilizar herramientas de pruebas de caja de cristal como pytest o unittest para escribir y ejecutar pruebas automatizadas en el código. Para hacer regression testing, se pueden utilizar estas mismas herramientas y volver a ejecutar las pruebas existentes después de hacer cambios en el código.

Caja de cristal - asume que nosotros sabemos la implementación y podemos probar todos los posibles caminos dentro de nuestra función. O sea, probar ramificaciones, bucles for y while, recursión.

Regression testing: Determinar un bug ya que el programa salio a operación. Necesitamos saber como esta estructurado el código. Loops:alguna condicion falsa. Probar excepciones.

Mocks.

Pruebas de caja de cristal

  • Se basan en el flujo del programa.
  • Prueba todos los caminos posibles de una
    función. Ramificaciones, bucles for y while,
    recursión.
  • Regression testing o mocks.

En resumen

La pruebas de caja de cristal pueden definirse como una técnica de monitorización o prueba de software en la se analiza el diseño, código y estructura interna, con el objetivo de mejorar propiedades como la seguridad y el uso eficiente del sistema.

Estas pruebas se caracterizan principalmente porque son los propios sistemas y aplicaciones quienes exponen sus métricas para que el usuario pueda leerlas, analizarlas y tomar decisiones y acciones en función de la obtención de un resultado u otro.

En las pruebas de monitorización de caja de cristal, los propios probadores aparecen en el mismo código, por lo que este recurso también suele conocerse como prueba de caja transparente o prueba de caja blanca, entre otros.

Características de las pruebas de caja de cristal

El sistema de monitorización basado en las pruebas de caja de cristal cuenta con una serie de propiedades y elementos que lo caracterizan y permiten su funcionamiento en las máquinas o equipos de software con los que trabaja. Se realiza sobre un módulo en específico, esto es, sobre un subsistema en concreto.

Estas pruebas de caja de cristal se basan en los detalles referentes al código fuente, es decir, que se enfoca en su análisis y puede llevarse a cabo a nivel de integración o unidad del sistema para el desarrollo de software.

Uno de los objetivos fundamentales de los sistemas de monitorización basados en las pruebas de caja de cristal es el de comprobar el flujo de trabajo de las aplicaciones y software para garantizar que todo esté funcionando de manera adecuada y eficiente o si, por el contrario, existe algún tipo de inconveniente que interrumpa o retrase los procesos.

Elementos principales

Dentro de los elementos principales que permiten la realización de las pruebas de caja de cristal en un software determinado, se encuentran:

Métricas

Las métricas en las pruebas de caja de cristal pueden ser de todo tipo, dependiendo del sistema monitorizado. Este estándar de medición se utiliza con el objetivo de medir de forma cuantitativa el estado del sistema con respecto a diferentes componentes o atributos, como puede ser la seguridad, eficiencia y demás.

Application Performance Metrics (APM)

El Application Performance Metrics (APM) es uno de los componentes característicos del sistema de pruebas de caja de cristal. Consiste en un sistema que se encarga de la recolección de métricas claves de la infraestructura y aplicación que se analiza, lo que permite que el usuario pueda identificar y solucionar los problemas de tipo funcional antes de que estos lleguen a tener un impacto negativo sobre los resultados a nivel comercial. Algunos ejemplos del APM son la tasa de error, el rendimiento o los tiempos de respuesta, entre otros.

personalizando mi código de testing, me di cuenta que es obligatorio el uso de “test_” antes de cualquier nombre de función, es decir como prefijo hay que usarlo. ejemplo:

def test_esMayorDeEdad(self) sino lo haces, no funciona.

Algo que no sabía y que me hizo pasar un mal rato porque el código no me funcionaba es que todos los métodos (las funciones dentro de la clase test) deben tener un nombre que inicie con la palabra “test”. Esto me pasó porque suelo renombrar el código para que quede en inglés y en una de esas cree métodos que no empezaban con “test” y por lo tanto no corrían

Al igual que la clase anterior dejo un vídeo para complementar:
https://www.youtube.com/watch?v=N-a5DEa_f0U

la vi dos veces, no entendi mucho 😣

la clase estuvo super me costo un poco pero aprendi

import unittest


def es_mayor_de_edad(edad):
    if edad >= 18:
        return True
    else:
        return False


class PruebaDeCristalTest(unittest.TestCase):

    def test_es_mayor_de_edad(self):
        edad = 20

        resultado = es_mayor_de_edad(edad)

        self.assertEqual(resultado, True)

    def test_es_menor_de_edad(self):
        edad = 15

        resultado = es_mayor_de_edad(edad)

        self.assertEqual(resultado, False)


if __name__ == '__main__':
    unittest.main()
F.
======================================================================
FAIL: test_es_mayor_de_edad (__main__.PruebaDeCristalTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/macbook/Downloads/python/caja_cristal.py", line 18, in test_es_mayor_de_edad
    self.assertEqual(resultado, True)
AssertionError: False != True

----------------------------------------------------------------------
Ran 2 tests in 0.001s

FAILED (failures=1)
macbook@MacBook-Pro-de-MACBOOK python % python3 caja_cristal.py
..
----------------------------------------------------------------------
Ran 2 tests in 0.000s

OK

Pruebas de cajas de cristal:

Se basan en el flujo del programa

Prueba todos los caminos posibles de una funcion, ramificaciones, bucles, for y while, recursion.

Regression testing o moks.

Buena clase!

Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o pruebas estructurales) se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente, lo cual, esto significa que tenemos que realizar un “estudio”, o más bien, un análisis de nuestro código, para esto, existen tres pautas fundamentales para poder realizar con éxito una prueba de caja blanca.

Excelente, nunca lo habia visto

import unittest #Módulo de Python para hacer pruebas

def es_mayor_de_edad(edad): # Ya el código está escrito
    if edad >= 18:
        return True
    else: 
        return False

class PruebaDeCristalTest(unittest.TestCase):
    def test_es_mayor_de_edad(self):
        edad = 20

        resultado = es_mayor_de_edad(edad)
        self.assertEqual(resultado, True) #Prueba de la rama mayor de edad

    def test_es_menor_de_edad(self):
        edad = 15

        resultado = es_mayor_de_edad(edad)
        self.assertEqual(resultado, False) #Prueba de la rama menor de edad

if __name__ == '__main__':
    unittest.main()

Yo utilizaría los test para hacer implementaciones nuevas sobre el código o cuando te mandan a parchar 😁

Como ejecuto la función testeada después de su testing???

<code>

import unittest
 
def es_mayor_de_edad(edad):
    if edad >= 18:
        return True
    else:
        return False


class PruebasDeCritalTest(unittest.TestCase):
    
    def test_mayor_de_edad(self):
        edad = 20
        
        resultado = es_mayor_de_edad(edad)
        
        self.assertEqual(resultado, True)

    def test_menor_de_edad(self):
        edad = 15

        resulado = es_mayor_de_edad(edad)

        self.assertEqual(resulado, False)

if __name__== "__main__":
    unittest.main()
en qué curso puedo aprender más sobre Debug?🤔

Buen dia companeros, tengo una pregunta. A que hace referencia la palabra reservada “self”?

Al intentar ejecutar el scrip me salta este error:

Estoy usando la terminal Bash en vsCode
¿Cómo puedo solucionarlo?

Muy bueno!!

Excelente herramienta!

Pruebas de caja de Cristal:

  • Se basan en el flujo del programa
  • Probamos todos los posibles caminos: ramificaciones, bucles y recursion
  • Se usan para hacer regression testing o mocks

Regresion Testing o mocks
Probamos los bugs que se presenten en su uso una vez ya ha salido el programa a luz.

chicos++ a mi cuando lo pongo me salta un archivo de pyton y se borra osea wtf ++

super buena explicación y que buena herramienta

Un tema muy útil cuando se desarrollan proyectos complejos y en equipo:

Revisar este contenido en el futuro.

Revisar este contenido en el futuro.

#Pruebas cajas de cristal
import unittest

def es_mayor_de_edad(edad):
    if edad >18:
        return True #Si le coloco False, me salta error
    else:
        return False

class PruebaDeCristalTest(unittest.TestCase):
    def test_es_mayor_de_edad(self):
        edad = 20
        resultado = es_mayor_de_edad(edad)
        self.assertEqual(resultado,True)

    def test_es_menor_de_edad(self):
        edad = 15
        resultado = es_mayor_de_edad(edad)
        self.assertEqual(resultado, False)



if __name__=='__main__':
    unittest.main()
import unittest

def es_mayor_de_edad(edad):
    if edad >= 18:
        return True

    else: 
        return False

class PruebaDeCristalTest(unittest.TestCase):
    
    def test_es_mayor_de_edad(self):
        edad = 20 

        resultado = es_mayor_de_edad(edad)

        self.assertEqual(resultado, True)

    def test_es_menor_de_edad(self):
        edad = 15

        resultado = es_mayor_de_edad(edad)

        self.assertEqual(resultado, False)
if __name__ == "__main__":
    unittest.main()```

Estoy impaciente por hacer mi primer programa.

excelente explicación, se entiende claramente la diferencia

import unittest

def es_mayor_de_edad(edad):
    if edad >= 18:
        return False
    else:
        return False

class PruebaDeCristalTest(unittest.TestCase):
    
    def test_es_mayor_de_edad(self):
        edad = 20

        resultado = es_mayor_de_edad(edad)
        self.assertEqual(resultado,True)
    
    def test_es_menor_de_edad(self):
        edad = 15

        resultado = es_mayor_de_edad(edad)
        
        self.assertEqual(resultado,False)

if __name__ == '__main__':
    unittest.main()

Para verificar que todas las lineas pasen por el test pueden usar coverage instalandolo con pip

  • pip3 install coverage

y ejecutarlo:

luego de eso ejecutan


donde te indica la covertura de los tests y las lineas que no estan cubiertas

mi codigo es el siguiente:

Las pruebas de caja de cristal: Prueba TODOS los posibles caminos o flujos de un programa, algoritmo o función.

Hola, buen día, hay manera de acceder a las diapositivas de la clase?

import unittest

def es_mayor_de_edad(edad):
    if edad >= 18:
        return True
    else:
        return False


class PruebaDeCristalTest(unittest.TestCase):
    
    def test_es_mayor_de_edad(self):
        edad = 20

        resultado = es_mayor_de_edad(edad)

        self.assertEqual(resultado, True)

    def test_es_menor_de_edad(self):
        edad = 17

        resultado = es_mayor_de_edad(edad)

        self.assertEqual(resultado, False)

Hola a todos, el ejecutar el programa me aparece en siguiente error:

import unittest

def es_mayor_de_edad (edad):
      if edad >=18:
        return True
      else:
        return False 

         
class PruebaDeCristalTest(unittest.TestCase):
      def test_es_mayor_de_edad(self):
        edad = 20

        resultado = es_mayor_de_edad (edad)

        self.assertEqual(resultado, True)


      def test_es_menor_de_edad (self):
        edad = 15

        resultado = es_mayor_de_edad (edad)

        self.assertEqual(resultado, False)



if __name__ == '__main__':
      unittest.main()
<h1>E</h1>

ERROR: /root/ (unittest.loader._FailedTest)

AttributeError: module ‘main’ has no attribute ‘/root/’


Ran 1 test in 0.002s

FAILED (errors=1)
An exception has occurred, use %tb to see the full traceback.

SystemExit: True

Al parecer corre el primer test de manera correcta pero el segundo no, creo que el código esta bien pero sigue arrojando este error, cualquier ayuda es bienvenida.

Se comprendió!!

Genial, todo claro.

Me encanto esta clase 😄

Esto es como tener guarda espaldas

no entendí la diferencia entre las pruebas, porque entiendo el objetivo de ambas pruebas, pero si comparo los codigos son parecidas las implementaciones, entiendo que de cristal es un analisis del bloque de código con ramificaciones,etc, no hay otro ejemplo que pueda entender mejor o alguna lectura?

No entendia la diferencia de caja de cristal(o caja blanca)y caja negra. La blanca analiza el interior de una funcion, mientras que la negra no toma en cuenta el funcionamiento de la funcion, si no su resultado .

Excelente tema!

Solo conocía el uso de excepciones para evitar errores, ahora con estos nuevos conceptos me siento más preparado.