No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Caja Blanca, Gris y Negra

16/29
Recursos

Cuando no estamos refiriendo a una caja es la manera de observar el contenido de software.

Negra: No podemos observar c贸mo fue construida, no vemos el c贸digo, no sabemos su arquitectura, no tenemos nociones m谩s que la interfaz que estamos interactuando.

  • Partici贸n de equivalencia
  • Valores l铆mite
  • Tabla de decisiones
  • Transici贸n de estados
  • Casos de usos

Blanca: Es como una caja de cristal, puedo ver todo lo que hay adentro e incluso puedo ser parte del equipo que desarrolla el software.

  • Cobertura de declaraci贸n
  • Cobertura de decisiones

Gris: Pueden ser la integraciones, c贸mo fluye el c贸digo y puedo ver como se transmiten los datos a trav茅s de las redes.

  • Casos de negocios
  • Pruebas End-to-End
  • Pruebas de integraci贸n

Aportes 50

Preguntas 7

Ordenar por:

Los aportes, preguntas y respuestas son vitales para aprender en comunidad. Reg铆strate o inicia sesi贸n para participar.

Apuntes:

Caja Blanca, Gris y Negra

Cu谩ndo estamos refiri茅ndonos a 鈥渦na caja鈥 es la manera de observar el contenido del Software, ya sea que no tenemos noci贸n m谩s que la interfaz con la que estamos trabajando, caja negra. Cu谩ndo podemos ver todo el contenido como una caja de cristal, caja blanca. Las integraciones, los datos c贸mo fluyen de un lugar a otro, d贸nde no conozco el c贸digo ni veo interfaz pero puedo ver c贸mo fluye la informaci贸n a trav茅s de las redes, caja gris.

Caja Negra

Participaci贸n de Equivalencia. Esos grupos de datos que pueden entrar para casos exitosos o para casos no exitosos.

Valores L铆mite. Se puede tener usado un rango de valores.
Tabla de Decisiones. Va enfocada si tuvi茅ramos valores seleccionables.
Transici贸n de Estados. C贸mo el componente se comporta.
Casos de Uso. Realizar escenarios que pueda realizar el usuario.

Caja Blanca

Cobertura de declaraciones. Las declaraciones son todo aquello que tienes dentro del c贸digo y est谩s asumiendo que es lo que se pide que haga, al decir cobertura es, dependiendo el tipo de software, los requerimientos, el objetivo, se establece un porcentaje de cobertura, esto significa que, cada l铆nea de c贸digo deber铆a ser ejecutada al menos una vez, cada sentencia deber铆a de ejecutarse alguna vez.
Cobertura de c贸digo. Que se evite tener c贸digo obsoleto.

Caja Gris

Casos de Negocio. Es necesario conocer c贸mo el usuario interact煤a, qu茅 datos ingresa y qu茅 datos van a ser retornados.
Pruebas End to End. C贸mo se est谩n agregando datos y a煤n no queremos ver datos de salida.
Pruebas de integraci贸n. Ver c贸mo viajan esos datos, la respuesta y la comunicaci贸n de c贸mo fluyen los datos entre diferentes servicios.

Los ejercicios vienen en el pdf de la secci贸n archivos del v铆deo 1 de la introducci贸n, p谩gina 81.
EJERCICIOS:
Dise帽ar y ejecutar pruebas correspondiente a :
a. un sitio web
b. una aplicaci贸n m贸vil
c. una API
d. un caso de uso

Podrian darme su opinion? Gracias

Pruebas de caja
Negra: No vemos como fue construido, no vemos el c贸digo, no sabemos su arquitectura

  • Partici贸n de equivalencia: Grupos de datos para casos exitosos y fallos
  • Valores l铆mite: Que valores se pueden introducir
  • Tabla de decisiones: valores de decisi贸n l贸gicos
  • Transici贸n de estados: dependencias de otras acciones
  • Casos de uso: probar que funcione correctamente
    Blanca: podemos ver todo lo que esta dentro, evitar la ceguera de no ver los defectos a los que uno ya esta acostumbrado.
  • Cobertura de declaraci贸n: eliminar c贸digo in煤til o problem谩tico
  • Cobertura de decisiones
    Gris: las integraciones vemos como se transmiten los datos a trav茅s de las redes
  • Casos de negocio: que se procesen los datos y regresen un valor
  • Pruebas End to End: se ingresan datos pero no se obtiene una respuesta visual
  • Pruebas de integraci贸n: como viajan los datos

Este canal me ayud贸 mucho con los ejemplos, espero tambi茅n les sirva

https://www.youtube.com/channel/UCVD0XAaYNHSb_YhaT9D-P3Q

Que literatura se recomienda para estos temas?

Las pruebas s贸lo pueden demostrar la presencia de errores, no su ausencia.
-Dijkstra

EJERCICIOS:
Dise帽ar y ejecutar pruebas correspondiente a :
a. un sitio web
b. una aplicaci贸n m贸vil
c. una API
d. un caso de uso

Quizas no sea el espacio para poder decir esto pero les dejo una sugerencia que puede observarse de analizar la caja negra en la pantalla de la clase.
Cuando uno realiza la escritura de comentario en el campo para poder hacerlo y luego por X cuestion desea alterar el tamano del navegador que esta utilizando pierde lo que tenia escrito. Y uno debe volver a escribir.
Deber铆a permanecer escrito ya que muchas veces uno busca materiales para compartir y tiene que moverse en distintas partes.

Para mayor informaci贸n, recomiendo encarecidamente este art铆culo de la Wikipedia

Caja negra hace alusi贸n de que no se puede ver adentro de la caja, solo tenemos unos datos de entrada y otros de salida.
Mientras que la caja blanca, se puede ver como se est谩n haciendo las coas, es decir se puede ver el c贸digo.
Por otro lado entre estos dos tipo, esta la caja gris, en la que aun no se ve una interfaz ni c贸digo pero si vemos como los datos fluyen de un lugar a otro (las integraciones), como se trasmiten los datos a trav茅s de las redes.

CAJA NEGRA (t茅cnicas)

  1. Partici贸n de equivalencia
    Grupo de datos para casos exitosos y no exitosos (Condiciones ejemplo: Cuando en un input donde solo puedo ingresar valores solo con 5 d铆gitos, que sean mayores a 10 y menores a 100)
  2. Valores l铆mite
    Evaluar y verificar que pasa cuando se pasa de un limite condicional
  3. Tabla de decisiones
    Para check box o una lista (solo pueden ser seleccionables)
  4. Transici贸n de estados
    Como un componente se comporta en relaciona con otros (Cuando por ejemplo para enviar un mensaje de whatsapp, tienes que escribir algo para que el bot贸n cambie del s铆mbolo de audio al de enviar )
  5. Casos de uso
    Probar que el usuarios termine un proceso, como por ejemplo llenar un formulaci贸n.

CAJA BLANCA (t茅cnicas)
Porcentaje de cobertura se refiere a que cada funci贸n o linea de c贸digo debe ejecutarse al menos una vez. (Evitar c贸digo in煤til)

  1. Cobertura de declaraciones
  2. Cobertura de c贸digo

CAJA GRIS (t茅cnicas)

  1. Casos de negocio
    Conocer como el usuario interactuar
  2. Pruebas END TO END
    consiste en probar flujos de ejecuci贸n en una aplicaci贸n de comienzo a fin
  3. Pruebas de integraci贸n
    Como viajan los datos entre diferentes servicios y sus respuestas.

Caja negra
Son las pruebas en donde no sabemos como funciona el software por dentro
Caja blanca/transparente
Es cuando sabemos como funciona el software por dentro
Caja gris
Es cuando vemos partes de la interfaz del usuario y de la parte de adentro del software

Cuando pienso en pruebas lo que siempre recuerdo son las pruebas de caja negra y caja blanca. Las pruebas de caja gris siguen siendo un concepto ambiguo para mi, aun despu茅s de ver el v铆deo.

Un Sitio WEB: Envi贸 de correo electr贸nico al registrar una transacci贸n
Pruebas de Caja Negra: Funcional
Caso 1: Datos de entrada: Registrar pedido de venta. Resultado esperado (Salida): El sistema env铆a un correo electr贸nico al cliente como constancia que su pedido se ha recibido.

Caso 2: Datos de entrada: Registrar despacho de mercanc铆a al cliente. Resultado esperado (Salida): El sistema env铆a un correo electr贸nico al cliente como constancia que se ha realizado el despacho.

Caso 3: Datos de entrada: Registrar factura de cliente. Resultado esperado (Salida): El sistema env铆a un correo electr贸nico al departamento de facturaci贸n y al cliente.

Caso 4: Datos de entrada: Registrar cobro. Resultado esperado (Salida): El sistema env铆a un correo electr贸nico al departamento de cuentas por cobrar y al agente comercial (vendedor) que lleva la cuenta del cliente.

Negra
No podemos observar c贸mo fue construida, no vemos el c贸digo, no sabemos su arquitectura, no tenemos nociones m谩s que la interfaz que estamos interactuando.
Partici贸n de equivalencia
Valores l铆mite
Tabla de decisiones
Transici贸n de estados
Casos de usos
Blanca
Es como una caja de cristal, puedo ver todo lo que hay adentro e incluso puedo ser parte del equipo que desarrolla el software.
Cobertura de declaraci贸n
Cobertura de decisiones
Gris
Pueden ser la integraciones, c贸mo fluye el c贸digo y puedo ver como se transmiten los datos a trav茅s de las redes.
Casos de negocios
Pruebas End-to-End
Pruebas de integraci贸n

Al principio pens茅 que ser铆a muy f谩cil dise帽arlos, despu茅s me di cuenta que la gran mayor铆a de los casos de pruebas, deben de partir de un requisito, por ejemplo la autenticaci贸n previa de usuario.
El nivel de detalle es algo importante a considerar, los pasos pueden ser enormes con mucho detalle, o muy cortos con poco detalle.
Tambi茅n me parece que ser铆a mejor (para los caso de uso funcionales), agregar una columa que especifique los caso de uso relacionados, y otra para los requisitos del caso.

pregunta: No veo los ejercicios en esta clase.驴donde los encuentro ?

Que mala onda que tengamos que ir hasta la primera clase a buscar los ejercicios que menciona la maestra鈥

Recomiendo la lectura de este post si quieren comprender un poco mejor, con ventajas y desventajas:

https://www.solvd.com/blog/black-white-grey-box-testing

Caja Negra: (Front-End)

  • partici贸n de equivalencia
  • Valores Limite
  • tabla de decisiones
  • transacci贸n de estados
  • Casos de Uso

Caja Blanca: (Back-End)

  • Cobertura de declaraciones

  • Cobertura de c贸digo

    1. sentencias
    2. decisiones
    3. condiciones

Caja Gris:

  • Casos de Negocio
  • Pruebas End to End
  • pruebas de Integraci贸n

Encontre otra prueba de Caja Negra.
Pruebas de historias de usuario:
Prueba muy utilizada en metodolog铆as 脕giles como puede ser el Scrum. Los requerimientos de usuario son preparados como historias de usuario.
Estas historias de usuario describen una funcionalidad que puede ser desarrollada o probada en una misma secuencia.
En estas descripciones en las historias de usuarios suelen aparecer funcionalidades a implementar, requerimientos no funcionales y los criterios de aceptaci贸n.
Los criterios de aceptaci贸n abarcan la cobertura m铆nima requerida para la historia de usuario.
Los casos de pruebas se basan en estos criterios de aceptaci贸n.

Que opinan?
Comparto el Link https://howtotesting.com/testing-funcional/pruebas-de-caja-negra/

Caja Negra:

  • Partici贸n de Equivalencia
  • Valores l铆mite
  • Tabla de decisiones.
  • Transici贸n de Estados
  • Casos de uso.

Caja Blanca:

  • Cobertura de Declaraciones
  • Cobertura de C贸digo.

Caja Gris:

  • Casos de Negocio
  • Pruebas End to End
  • Pruebas de integracion

Por favor, suban los ejercicios. Hace 13 d铆as que se public贸 esta inquietud y no la han respondido. Estos ejercicios sirven para practicar y profundizar en el tema. O es que los ejercicios aparecen en v铆deos posteriores?

Done puedo ver los ejercicios?

Comparto los ejercicios:

Pruebas de caja negra

1. particion de equivalencia: grupos de datos que ingresan exitosos y no exitosos
2. valores limite: definir datos , hasta cuantos digitos
3. tabla de decisiones: true o false
4. transicion de estados: como se comporta el componente, si necesita de otro para estar activo
5. casos de uso: el usuario puede llenar el formualrio pasa al siguiente si esta completo

Pruebas de caja Gris

Pruebas de caja Blanca

Pruebas de caja Negra

En la Academia de Ingles de Platzi se encuentra un curso genial. Ingles para Developers en el que hablan m谩s acerca de esto.

Cuando no estamos refiriendo a una caja es la manera de observar el contenido de software.

Negra:No podemos observar c贸mo fue construida, no vemos el c贸digo, no sabemos su arquitectura, no tenemos nociones m谩s que la interfaz que estamos interactuando.

Partici贸n de equivalencia
Valores l铆mite
Tabla de decisiones
Transici贸n de estados
Casos de usos
Blanca: Es como una caja de cristal, puedo ver todo lo que hay adentro e incluso puedo ser parte del equipo que desarrolla el software.

Cobertura de declaraci贸n
Cobertura de decisiones
Gris: Pueden ser la integraciones, c贸mo fluye el c贸digo y puedo ver como se transmiten los datos a trav茅s de las redes.

Casos de negocios
Pruebas End-to-End
Pruebas de integraci贸n

Muy interesante

Caja negra > Transiciones de Estados en Formularios

Un caso muy com煤n son los campos obligatorios. Por ejemplo: si un usuario no ingresa un contacto, no debe de poder completar el formulario hasta llenarlo. Por lo cu谩l el estado del bot贸n 鈥淓nviar formulario鈥 deber铆a verse en modo inactivo hasta que el campo mencionado se complete.

Caja Blanca, Gris y Negra
Se llaman pruebas de caja porque es la manera de observar el contenido del software.

Los modelos de caja negra es cuando por ejemplo en un computador no vemos como fue construido, se puede referenciar dentro del desarrollo como la parte del Backend, el codigo, no sabemos de arquitectura, si no la unica noci贸n que tenemos es la interfaz con la que interactua el usuario

Pruebas de caja negra
Partici贸n de equivalencia: Que tipo de informacion dentro de los tipos de datos deberia contener por ejemplo un formulario, enteros, flotantes

Valores l铆mite: Establecer limites por ejemplo un maximo de digitos en una fraccion en pesos. Que pasa si coloco una fraccion de 90.001 o 90.000.001 o 90.000.00001

Tabla de decisiones: Aplica para casos donde existen check box o listas y son valores fijos, no le corresponde la opcion de establecer un criterio a los usuarios

Transici贸n de estados: Como el componente se comporta

Casos de usos: Por ejemplo donde un usario puede llenar un formulario y enviarlo o los campos son obligatorios y no puede pasar al siguiente campo hasta no completar los que son obligatorios

Los modelos de caja blanca es llamada en ocasiones caja de cristal, se puede referenciar dentro del desarrollo como la parte del Frontend, donde se puede ver todo lo que hay adentro e incluso es posible ser parte del equipo que esta desarrollando software

Pruebas de caja blanca
Cobertura de declaraci贸n: Es todo aquello que esta dentro del codigo y se pide hacer, es decir que cada linea de codigo realizada se ejecute por lo menos una vez, debe tener una cobertura medible por porcentaje

Cobertura de codigo: Es eliminar todo tipo de codigo que sea innecesario en el producto o proyecto teniendo en cuenta:

Sentencias

Desiciones

Condiciones

Los modelos de caja gris es donde se realizan integraciones, viene siendo un punto intermedio entre la caja blanca y la caja negra y podemos ver los datos como fluyen o se transmiten de un lugar a otro

Pruebas de caja gris
Casos de negocios: Como el usuario esta interactuando en el Frontend o la interfaz y como esta respondiendo el producto es decir todo lo que va al Backend, se transforma y de que forma regresa la informacion al Frontend de nuevo. Es decir datos de entrada y salida

Pruebas End-to-End: Se refiere por ejemplo a la creacion de un usuario para una aplicacion pero no necesariamente se tiene que ver como quedo en la salida y posiblemente no se vea el resultado pero se visualiza en otro entorno

Pruebas de integraci贸n: Es ver como se estan transmitiendo los datos del Frontend al Backend

Tipos de pruebas de CAJA NEGRA

  • Partici贸n de equivalencia: Se divide entre los datos validos y los que no son.
  • Valores limite: Determina un valor limite para un cierto tipo de dato
  • Tabla de decisiones: Esta aplica al momento en el que tenemos elementos que puedan ser true/false o si/no
  • Transici贸n de estados: Aplica en cosas como los videos de platzi (est谩n en pausa, en play, silenciados, etc)
  • En los casos de uso es como una prueba para saber si se puede realizar ciertas acciones

Yo Hice Mis Purebas en Python Con Una libreria llamada unittest su
modulo interno de unittet llamado TestCase o tambien caso de prueba
consiste en ir verificando cada modulo si pasa la prueba el mismo te indica que las pruebas salieron Ok y sino te muestra las fallas se ejecuta directamente en el modulo principal yo recomiendo hacerlo en un archivo Aparte importarlo y dejarlo hay y hacer las pruebas con el respectivo codigo que te pasan para corregir 鈥
Te invido a Probarla y ver como te va aki un breve ejemplo correro y me dices como te fue

import unittest

def suma(num_1,num_2):
return num_1 + num_2

class CajaNegraTest(unittest.TestCase):

def test_suma_dos_positivos(self):
    num_1 = 10
    num_2 =  5

    resultado = suma(num_1,num_2)

    self.assertEqual(resultado, 15)

def test_suma_dos_negativos(self):
    num_1 = -10
    num_2 = -7

    resultado = suma(num_1,num_2)

    self.assertEqual(resultado, -17)

if name == 鈥main鈥:
unittest.main()

entonces por ejemplo, en la caja gris ir铆an las pruebas al servicio web?

no hay los ejercicios 馃槮

D贸nde est谩n los ejercicios de Caja Negra, Gris, Blanca?

Cuando no estamos refiriendo a una caja es la manera de observar el contenido de software.

Negra: No podemos observar c贸mo fue construida, no vemos el c贸digo, no sabemos su arquitectura, no tenemos nociones m谩s que la interfaz que estamos interactuando.

Partici贸n de equivalencia
Valores l铆mite
Tabla de decisiones
Transici贸n de estados
Casos de usos

Blanca: Es como una caja de cristal, puedo ver todo lo que hay adentro e incluso puedo ser parte del equipo que desarrolla el software.

Cobertura de declaraci贸n
Cobertura de decisiones

Gris: Pueden ser la integraciones, c贸mo fluye el c贸digo y puedo ver como se transmiten los datos a trav茅s de las redes.

Casos de negocios
Pruebas End-to-End
Pruebas de integraci贸n

Cu谩l es la diferencia entre la t茅cnica de casos de usos vs casos de negocio?

Caja Negra: Interfaz.

  • Participaci贸n de Equivalencias
  • Valores l铆mites
  • Tabla de decisiones
  • Transici贸n de estados
  • Casos de usos.
    Caja Blanca: Ingres贸 a la fuente, su interior.
  • Cobertura de declaraciones
  • Cobertura de decisiones.
    Caja Gris:Comunicaci贸n del c贸digo
  • Casos de negocios
  • Pruebas End to end
  • Pruebas de integraci贸n.

Entendido

La caja se refiere al contenido del software.

  • Negra -> No conocemos su c贸digo ni arquitectura ni c贸mo fue construido. Solamente la noci贸n de la interfaz.
  • Blanca -> Puedo ver todo lo que hay dentro, incluso puedo ser parte del equipo que desarroll贸 el software.
  • Gris -> No conozco el c贸digo, pero veo c贸mo se transmiten los datos.

T茅cnicas de pruebas:

  • Caja negra
    • Partici贸n de equivalencia
    • Valores l铆mite
    • Tabla de decisiones
    • Transici贸n de estados
    • Casos de uso
  • Caja gris
    • Casos de negocio
    • Pruebas End to End
    • Pruebas de integraci贸n
  • Caja blanca
    • Cobertura de declaraci贸n
    • Cobertura de decisiones

Las prubeas 鈥淓nd to End鈥 consisten en: Yo como usuario hago cosas y la informaci贸n se ver谩 reflejada no en m铆, sino en otra parte de front end.

Las pruebas de integraci贸n son las respuestas y la comunicaci贸n de c贸mo fluyen los datos entre diferentes servicios.

隆Tambi茅n hay que tomar en cuenta los datos vac铆os! Se deber铆a mostrar un mensaje diciendo 鈥淣o puedes dejar X campo vac铆o鈥.

En un textboxt creo que tambi茅n entra la tabla de la verdad, el el momento de validar el tipo de datos, por ejemplo con expresiones regulares, si cumple o no el patr贸n!

Caja blanca
En los tipos de pruebas que se aplican a la caja blanca son las de cobertura, 贸sea que se checan que est茅n funcionando correctamente una cierta cantidad de modelos del c贸digo o de las declaraciones en este caso

Para complementar estas lecciones. les aconsejo que tomen el curso de English for Developers, ah铆 tambi茅n explican esto de las cajas.