Difference between revisions of "GXtest Generator - Complejidad de las pruebas"
(Created page with "{{Idiomas |GXtest Generator - Complejidad de las pruebas |GXtest Generator - Test depth |GXtest Generator - テスト深度}} (Estamos trabajando en la traducción de esta p...") |
(→Options) |
||
| Line 9: | Line 9: | ||
The Test depth option specifies the data complexity that the generated Test Cases will have. The number of rows that the generated datapools will have depends on this configuration. | The Test depth option specifies the data complexity that the generated Test Cases will have. The number of rows that the generated datapools will have depends on this configuration. | ||
| − | == | + | == Opciones == |
| − | + | Tienen 4 niveles de configuración: | |
| − | * | + | * Mínimo |
| − | * | + | * Básico |
| − | * | + | * Básico con reglas |
| − | * | + | * Todos los valores discretos |
| + | * Válido e inválido | ||
| + | === Mínimo === | ||
| + | Genera solamente un valor por cada campo editable de la entidad analizada (transacción). Los datos son generados en forma aleatoria (siguiendo algunas, o pueden ser tomados desde un un diccionario de datos, o una base de datos de la aplicación. | ||
| − | === | + | === Básico === |
| − | + | Genera un conjunto de valores por cada campo editable, basado en los valores borde de cada uno de los campos. | |
| + | Por ejemplo, para un campo Numeric(4), podría generar los siguientes valores: 183, 0, 1, 9999 | ||
| + | La generación de valores se basa en la técnica de [http://en.wikipedia.org/wiki/Boundary-value_analysis boundary value analysis] | ||
| − | === | + | === Básico con reglas === |
| − | + | Igual que el básico, pero además incluye valores borde basados en las reglas GeneXus del objeto analizado. Por ejemplo, si existe una regla error sobre un campo "Edad", tal que la aplicación desplegará un error si se ingresa una edad mayor o igual a 120, entonces GXtest Generator elegirá el 119 como un valor interesante para probar. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The rules that are currently analized/supported are: | The rules that are currently analized/supported are: | ||
* error() - when the error depends on a numeric attribute comparison | * error() - when the error depends on a numeric attribute comparison | ||
| + | * error() - when the error fires if an attribute value is empty | ||
| + | * error() - when the error fires if the lenght of a string is greater or lower than a numeric value | ||
| + | |||
| + | === Todos los valores discretos === | ||
| + | Esta configuración se aplica en particular a campos en los que se puede elegir un valor de un conjunto discreto de opciones. El ejemplo más claro de esto son los Combo, los cuales tienen una cantidad acotada de valores que pueden utilizarse. La configuración "All discrete values" agregará a la prueba todos los valores disponibles en ese Combo (en lugar de seleccionar sólo algunos). | ||
| + | |||
| + | === Válido e inválido === | ||
| + | Además de las pruebas del flujo normal de la aplicación, se generará un caso de prueba adicional con el fin de probar que los ingresos inválidos de datos sean correctamente manejados por la aplicación. Por ejemplo, si tenemos una regla error sobre el campo Edad: | ||
| + | |||
| + | error("La edad debe ser menor a 120") if Edad>=120; | ||
| + | |||
| + | El caso de prueba generado ingresará el valor 120 (o uno mayor) en el formulario, y validará que efectivamente aparece el mensaje de error en la pantalla. | ||
| + | |||
| + | GXtest Generator podrá generar un ingreso de datos (FillInput) y una validación (VerifyControlValidation). Para el ejemplo de la edad, el caso de prueba tendrá lo siguiente: | ||
| + | |||
| + | FillInput(Edad, 120) | ||
| + | |||
| + | VerifyControlValidation(Edad, "La edad debe ser menor a 120", Error) | ||
| + | |||
| + | FillInput(Edad, 20) | ||
| + | |||
| + | Los primeros dos comandos, servirán para validar el mensaje de error sobre el campo. El último FillInput, se utiliza para dejar un valor válido en el campo, para el caso que querramos seguir validando otros mensajes de error mas adelante en el form, de modo que este error no nos tranque el resto de las validaciones. | ||
| + | |||
| + | |||
| + | Para las reglas que tengan una lógica más compleja para decidir si un error se debe mostrar (por ejemplo que invoquen a un Procedure), GXtest Generator generará igualmente los tres comandos, pero agregará valores fijos a los FillInputs. Esto se debe a que no podrá conocer cuál valor dispararía el error (porque por ejemplo depende de datos de la ejecución y la lógica del Procedure invocado), pero que seguramente el tester conoce y podrá completar en el datapool asociado luego de la generación. | ||
| + | |||
| + | Los datos que GXtest Generator no pudo calcular, podrán ser identificados fácilmente en el datapool, ya que tendrán los valores "Fill with an invalid value here" y "Fill with a valid value here", para indicar al tester que debe ingresar esos datos y así completar el caso de prueba. | ||
| + | |||
| + | |||
| + | === Consideraciones === | ||
| + | |||
| + | Para las configuraciones en las que se generan más de una fila de datos (todas menos Mínimo), se utiliza una estrategia similar a [http://en.wikipedia.org/wiki/All-pairs_testing pairwise testing] para optimizar la cantidad de ejecuciones que se realizará con los datos. Si combináramos cada valor de cada columna con las demás y realizáramos todas las combinaciones posibles, tendríamos un datapool con el producto cartesiano de todos los valores de todas las columnas, y el caso de prueba acabaría demorando mucho en completar su ejecución (ya que tendría demasiados valores para probar). | ||
| − | + | Está comprobado que utilizar pairwise testing es una técnica suficientemente buena para asegurarnos cierta combinación de valores que resulten interesantes en las pruebas. | |
| − | + | ||
Revision as of 14:55, 14 April 2015
 |
 |
 |
(Estamos trabajando en la traducción de esta página)
The Test depth option specifies the data complexity that the generated Test Cases will have. The number of rows that the generated datapools will have depends on this configuration.
Contents |
Opciones
Tienen 4 niveles de configuración:
- Mínimo
- Básico
- Básico con reglas
- Todos los valores discretos
- Válido e inválido
Mínimo
Genera solamente un valor por cada campo editable de la entidad analizada (transacción). Los datos son generados en forma aleatoria (siguiendo algunas, o pueden ser tomados desde un un diccionario de datos, o una base de datos de la aplicación.
Básico
Genera un conjunto de valores por cada campo editable, basado en los valores borde de cada uno de los campos. Por ejemplo, para un campo Numeric(4), podría generar los siguientes valores: 183, 0, 1, 9999 La generación de valores se basa en la técnica de boundary value analysis
Básico con reglas
Igual que el básico, pero además incluye valores borde basados en las reglas GeneXus del objeto analizado. Por ejemplo, si existe una regla error sobre un campo "Edad", tal que la aplicación desplegará un error si se ingresa una edad mayor o igual a 120, entonces GXtest Generator elegirá el 119 como un valor interesante para probar.
The rules that are currently analized/supported are:
- error() - when the error depends on a numeric attribute comparison
- error() - when the error fires if an attribute value is empty
- error() - when the error fires if the lenght of a string is greater or lower than a numeric value
Todos los valores discretos
Esta configuración se aplica en particular a campos en los que se puede elegir un valor de un conjunto discreto de opciones. El ejemplo más claro de esto son los Combo, los cuales tienen una cantidad acotada de valores que pueden utilizarse. La configuración "All discrete values" agregará a la prueba todos los valores disponibles en ese Combo (en lugar de seleccionar sólo algunos).
Válido e inválido
Además de las pruebas del flujo normal de la aplicación, se generará un caso de prueba adicional con el fin de probar que los ingresos inválidos de datos sean correctamente manejados por la aplicación. Por ejemplo, si tenemos una regla error sobre el campo Edad:
error("La edad debe ser menor a 120") if Edad>=120;
El caso de prueba generado ingresará el valor 120 (o uno mayor) en el formulario, y validará que efectivamente aparece el mensaje de error en la pantalla.
GXtest Generator podrá generar un ingreso de datos (FillInput) y una validación (VerifyControlValidation). Para el ejemplo de la edad, el caso de prueba tendrá lo siguiente:
FillInput(Edad, 120)
VerifyControlValidation(Edad, "La edad debe ser menor a 120", Error)
FillInput(Edad, 20)
Los primeros dos comandos, servirán para validar el mensaje de error sobre el campo. El último FillInput, se utiliza para dejar un valor válido en el campo, para el caso que querramos seguir validando otros mensajes de error mas adelante en el form, de modo que este error no nos tranque el resto de las validaciones.
Para las reglas que tengan una lógica más compleja para decidir si un error se debe mostrar (por ejemplo que invoquen a un Procedure), GXtest Generator generará igualmente los tres comandos, pero agregará valores fijos a los FillInputs. Esto se debe a que no podrá conocer cuál valor dispararía el error (porque por ejemplo depende de datos de la ejecución y la lógica del Procedure invocado), pero que seguramente el tester conoce y podrá completar en el datapool asociado luego de la generación.
Los datos que GXtest Generator no pudo calcular, podrán ser identificados fácilmente en el datapool, ya que tendrán los valores "Fill with an invalid value here" y "Fill with a valid value here", para indicar al tester que debe ingresar esos datos y así completar el caso de prueba.
Consideraciones
Para las configuraciones en las que se generan más de una fila de datos (todas menos Mínimo), se utiliza una estrategia similar a pairwise testing para optimizar la cantidad de ejecuciones que se realizará con los datos. Si combináramos cada valor de cada columna con las demás y realizáramos todas las combinaciones posibles, tendríamos un datapool con el producto cartesiano de todos los valores de todas las columnas, y el caso de prueba acabaría demorando mucho en completar su ejecución (ya que tendría demasiados valores para probar).
Está comprobado que utilizar pairwise testing es una técnica suficientemente buena para asegurarnos cierta combinación de valores que resulten interesantes en las pruebas.
