En las pruebas de caja gris tenemos cierto conocimiento sobre la estructura interna de la aplicación, pero, como en las pruebas de caja negra, nos apoyamos principalmente en la especificación.
Por ejemplo, podríamos tener acceso al esquema de la base de datos y detectar bugs ya en la etapa de revisión de documentación. Veremos bases de datos más adelante aquí.
El acceso al esquema de la base de datos permite al tester comprobar de antemano si los requisitos coinciden con la estructura real de la tabla.
A continuación hay ejemplos de bugs que pueden encontrarse simplemente comparando los requisitos con el esquema.
| Requisitos | Base de datos |
|---|---|
| El campo puede contener cualquier carácter |
El campo tiene tipo numérico
INTEGER
|
| El campo debe almacenar texto de hasta 200 caracteres |
El campo está limitado a 100 caracteres
VARCHAR(100)
|
| Requisitos | Base de datos |
|---|---|
| El campo puede estar vacío |
El campo tiene una restricción
NOT NULL
|
| Requisitos | Base de datos |
|---|---|
| Los valores del campo no son únicos |
El campo tiene una restricción
UNIQUE
|
Revisa los requisitos de la API y el esquema de base de datos. Realiza pruebas de caja gris. Cuando el servidor recibe una solicitud, actualiza la name columna de la tabla cat.
Requisitos para el API:
| Clave | Tipo | Obligatorio | Restricciones |
|---|---|---|---|
| name | string | + | de 1 a 30 caracteres |
Esquema de la tabla Cat:
| Campo | Tipo | Descripción |
|---|---|---|
| id | integer |
Identificador del registro |
| name | varchar(16) |
Nombre |
| age | integer |
Edad |
Restricciones de campos:
varchar(16) -
string de hasta 16 caracteres
integer -
number
Hicimos algo similar en la tarea de API. Esta vez, nuestro objetivo es encontrar un bug usando tanto los requisitos como el conocimiento adicional del esquema de base de datos.
Уровень повышен!
