¿Qué son los datos de prueba? Técnicas de preparación de datos de prueba con ejemplo

what is test data test data preparation techniques with example

Aprenda qué son los datos de prueba y cómo preparar los datos de prueba para la prueba:

En la épica actual del crecimiento revolucionario de la información y la tecnología, los probadores suelen experimentar un consumo extenso de datos de prueba en el ciclo de vida de las pruebas de software.

Los evaluadores no solo recopilan / mantienen datos de las fuentes existentes, sino que también generan grandes volúmenes de datos de prueba para garantizar su contribución de calidad en la entrega del producto para uso en el mundo real.

Por lo tanto, nosotros, como probadores, debemos explorar, aprender y aplicar continuamente los enfoques más eficientes para la recopilación, generación, mantenimiento, automatización y gestión integral de datos para cualquier tipo de prueba funcional y no funcional.

En este tutorial, proporcionaré consejos sobre cómo preparar los datos de prueba para que no se pierda ningún caso de prueba importante debido a datos incorrectos y configuración incompleta del entorno de prueba.

Lo que vas a aprender:

• Qué son los datos de prueba y por qué son importantes
  • Desafíos del abastecimiento de datos de prueba
  • Estrategias para la preparación de datos de prueba
  • Datos de prueba corruptos
  • Datos de prueba para el caso de prueba de rendimiento
  • ¿Cómo preparar datos que garanticen la máxima cobertura de prueba?
  • Datos para pruebas de caja negra
  • Ejemplo de datos de prueba para Open EMR AUT
  • Creación de datos manuales para probar la aplicación Open EMR
• Propiedades de una buena prueba de datos
  • Propiedades de los datos de prueba
  • Técnicas de preparación de datos de prueba
  • Enfoques de generación de datos de prueba:
  • Conclusión
  • Lectura recomendada

Qué son los datos de prueba y por qué son importantes

En referencia a un estudio realizado por IBM en 2016, la búsqueda, la gestión, el mantenimiento y la generación de datos de prueba abarcan del 30% al 60% del tiempo de los probadores. Es una prueba innegable de que la preparación de datos es una fase de prueba de software que requiere mucho tiempo.

Figura 1: Tiempo promedio empleado por los probadores en TDM

No obstante, es un hecho en muchas disciplinas que la mayoría de los científicos de datos dedican del 50% al 80% del tiempo de desarrollo de su modelo a organizar los datos. Y ahora, teniendo en cuenta la legislación y la información de identificación personal (PII), la participación de los probadores en el proceso de prueba es abrumadoramente decente.

Hoy en día, la credibilidad y fiabilidad de los datos de prueba se consideran un elemento indiscutible para los propietarios de empresas. Los propietarios de productos ven las copias fantasma de los datos de prueba como el mayor desafío, lo que reduce la confiabilidad de cualquier aplicación en este momento único de demanda / requisitos de los clientes para la garantía de calidad.

Teniendo en cuenta la importancia de los datos de prueba, la gran mayoría de los propietarios de software no aceptan las aplicaciones probadas con datos falsos o menos en las medidas de seguridad.

En este punto, ¿por qué no recordamos qué son los datos de prueba? Cuando comenzamos a escribir nuestros casos de prueba para verificar y validar las características dadas y los escenarios desarrollados de la aplicación bajo prueba, necesitamos información que se utiliza como entrada para realizar las pruebas para identificar y localizar los defectos.

¿Qué es la prueba del sistema con ejemplo?

Y sabemos que esta información debe ser precisa y completa para eliminar los errores. Es lo que llamamos datos de prueba. Para que sea preciso, pueden ser nombres, países, etc., que no son confidenciales, donde los datos relacionados con la información de contacto, el número de seguro social, el historial médico y la información de la tarjeta de crédito son de naturaleza sensible.

Los datos pueden estar en cualquier forma como:

• Datos de prueba del sistema
• Datos de prueba SQL
• Datos de prueba de rendimiento
• Datos de prueba XML

Si está escribiendo casos de prueba, necesita datos de entrada para cualquier tipo de prueba. El probador puede proporcionar estos datos de entrada en el momento de ejecutar los casos de prueba o la aplicación puede elegir los datos de entrada necesarios de las ubicaciones de datos predefinidas.

Los datos pueden ser cualquier tipo de entrada a la aplicación, cualquier tipo de archivo que cargue la aplicación o entradas leídas de las tablas de la base de datos.

La preparación de los datos de entrada adecuados es parte de una configuración de prueba. Generalmente, los evaluadores lo llaman preparación del banco de pruebas . En el banco de pruebas, todos los requisitos de software y hardware se establecen utilizando los valores de datos predefinidos.

Si no tiene el enfoque sistemático para generar datos mientras escribir y ejecutar casos de prueba entonces hay posibilidades de perder algunos casos de prueba importantes. Los probadores pueden crear sus propios datos de acuerdo con las necesidades de prueba.

No confíe en los datos creados por otros probadores o en los datos de producción estándar. Cree siempre un conjunto de datos nuevo de acuerdo con sus requisitos.

A veces, no es posible crear un conjunto de datos completamente nuevo para todas y cada una de las compilaciones. En tales casos, puede utilizar datos de producción estándar. Pero recuerde agregar / insertar sus propios conjuntos de datos en esta base de datos existente. Una mejor manera de crear datos es utilizar los datos de muestra existentes o el banco de pruebas y agregar los datos de su nuevo caso de prueba cada vez que obtenga el mismo módulo para la prueba. De esta manera, puede crear un conjunto de datos completo durante el período.

Desafíos del abastecimiento de datos de prueba

Una de las áreas en la generación de datos de prueba que los evaluadores consideran es el requisito de suministro de datos para el subconjunto. Por ejemplo, tiene más de un millón de clientes y necesita mil de ellos para realizar pruebas. Y esta muestra de datos debe ser coherente y representar estadísticamente la distribución adecuada del grupo objetivo. En otras palabras, se supone que debemos encontrar a la persona adecuada para probar, que es uno de los métodos más útiles para probar los casos de uso.

Y esta muestra de datos debe ser coherente y representar estadísticamente la distribución adecuada del grupo objetivo. En otras palabras, se supone que debemos encontrar a la persona adecuada para probar, que es uno de los métodos más útiles para probar los casos de uso.

Además, existen algunas limitaciones ambientales en el proceso. Uno de ellos es el mapeo de políticas de PII. Como la privacidad es un obstáculo importante, los evaluadores deben clasificar los datos de PII.

Las herramientas de gestión de datos de prueba están diseñados para abordar el problema mencionado. Estas herramientas sugieren políticas basadas en los estándares / catálogo que tienen. Sin embargo, no es un ejercicio muy seguro. Todavía ofrece la oportunidad de auditar lo que uno está haciendo.

Para estar al día con el abordaje de los desafíos actuales e incluso futuros, siempre debemos hacer preguntas como ¿Cuándo / dónde debemos comenzar la conducción de TDM? ¿Qué debería automatizarse? ¿Cuánta inversión deberían asignar las empresas para realizar pruebas en áreas de desarrollo continuo de habilidades de recursos humanos y el uso de herramientas TDM más nuevas? ¿Deberíamos comenzar a probar con pruebas funcionales o no funcionales? Y preguntas mucho más probables como ellos.

Algunos de los desafíos más comunes del suministro de datos de prueba se mencionan a continuación:

• Es posible que los equipos no tengan los conocimientos y las habilidades adecuados en las herramientas de generación de datos de prueba.
• La cobertura de los datos de prueba suele ser incompleta
• Menos claridad en los requisitos de datos que cubren las especificaciones de volumen durante la fase de recopilación
• Los equipos de prueba no tienen acceso a las fuentes de datos
• Retraso en dar acceso a los datos de producción a los probadores por parte de los desarrolladores
• Es posible que los datos del entorno de producción no se puedan utilizar por completo para las pruebas basadas en los escenarios comerciales desarrollados
• Es posible que se necesiten grandes volúmenes de datos en un corto período de tiempo determinado
• Dependencias / combinaciones de datos para probar algunos de los escenarios comerciales
• Los evaluadores dedican más tiempo del necesario a comunicarse con arquitectos, administradores de bases de datos y BA para recopilar datos.
• La mayoría de los datos se crean o preparan durante la ejecución de la prueba.
• Varias aplicaciones y versiones de datos
• Ciclos de lanzamiento continuos en varias aplicaciones
• Legislación para cuidar la información de identificación personal (PII)

En el lado de la caja blanca de la prueba de datos, los desarrolladores preparan los datos de producción. Ahí es donde QA debe trabajar en contacto con los desarrolladores para ampliar la cobertura de pruebas de AUT. Uno de los mayores desafíos es incorporar todos los escenarios posibles (caso de prueba del 100%) con cada caso negativo posible.

En esta sección, hablamos sobre los desafíos de los datos de prueba. Puede agregar más desafíos a medida que los haya resuelto en consecuencia. Posteriormente, exploremos diferentes enfoques para manejar el diseño y la gestión de datos de prueba.

Estrategias para la preparación de datos de prueba

Sabemos por la práctica diaria que los actores de la industria de las pruebas experimentan continuamente diferentes formas y medios para mejorar los esfuerzos de las pruebas y, lo que es más importante, su rentabilidad. En el breve curso de la evolución de la información y la tecnología, hemos visto que cuando las herramientas se incorporan a los entornos de producción / prueba, el nivel de producción aumenta sustancialmente.

Cuando hablamos de la integridad y la cobertura total de las pruebas, depende principalmente de la calidad de los datos. Como las pruebas son la columna vertebral para lograr la calidad del software, los datos de prueba son el elemento central en el proceso de prueba.

Figura 2: Estrategias para la gestión de datos de prueba (TDM)

Creación de archivos planos basados ​​en las reglas de mapeo. Siempre es práctico crear un subconjunto de los datos que necesita del entorno de producción donde los desarrolladores diseñaron y codificaron la aplicación. De hecho, este enfoque reduce los esfuerzos de preparación de datos de los probadores y maximiza el uso de los recursos existentes para evitar gastos adicionales.

Por lo general, necesitamos crear los datos o al menos identificarlos en función del tipo de requisitos que tiene cada proyecto desde el principio.

Podemos aplicar las siguientes estrategias manejando el proceso de TDM:

1. Datos del entorno de producción
2. Recuperar consultas SQL que extraen datos de las bases de datos existentes del Cliente
3. Herramientas de generación de datos automatizadas

Los probadores respaldarán sus pruebas con datos completos considerando los elementos como se muestra en la figura 3 aquí. Los resters en equipos de desarrollo ágiles generan los datos necesarios para ejecutar sus casos de prueba. Cuando hablamos de casos de prueba, nos referimos a casos para varios tipos de pruebas, como la caja blanca, la caja negra, el rendimiento y la seguridad.

En este punto, sabemos que los datos para las pruebas de rendimiento deberían poder determinar qué tan rápido responde el sistema bajo una carga de trabajo determinada para estar muy cerca de un gran volumen de datos real o en vivo con una cobertura significativa.

Para las pruebas de caja blanca, los desarrolladores preparan sus datos requeridos para cubrir tantas ramas como sea posible, todas las rutas en el código fuente del programa y la Interfaz de Programa de Aplicación (API) negativa.

Figura 3: Actividades de generación de datos de prueba

Eventualmente, podemos decir que todos los que trabajan en el ciclo de vida del desarrollo de software ( SDLC ) al igual que los BA, los desarrolladores y propietarios de productos deben participar en el proceso de preparación de los datos de prueba. Puede ser un esfuerzo conjunto. Y ahora permítanos llevarlo al tema de los datos de prueba corruptos.

Datos de prueba corruptos

Antes de la ejecución de cualquier caso de prueba en nuestros datos existentes, debemos asegurarnos de que los datos no estén dañados / desactualizados y que la aplicación bajo prueba pueda leer la fuente de datos. Por lo general, cuando más de un evaluador trabaja en diferentes módulos de un AUT en el entorno de prueba al mismo tiempo, las posibilidades de que los datos se corrompan son muy altas.

En el mismo entorno, los probadores modifican los datos existentes según sus necesidades / requisitos de los casos de prueba. En general, cuando los evaluadores terminan con los datos, los dejan como están. Tan pronto como el siguiente probador recoja los datos modificados y realice otra ejecución de la prueba, existe la posibilidad de que esa prueba en particular falle, que no es el error de código o defecto.

En la mayoría de los casos, así es como los datos se corrompen y / o desactualizan, lo que conduce a fallas. Para evitar y minimizar las posibilidades de discrepancia de datos, podemos aplicar las soluciones que se indican a continuación. Y, por supuesto, puede agregar más soluciones al final de este tutorial en la sección de comentarios.

1. Tener la copia de seguridad de sus datos
2. Devuelva sus datos modificados a su estado original
3. División de datos entre los probadores
4. Mantenga al administrador del almacén de datos actualizado para cualquier cambio / modificación de datos

¿Cómo mantener intactos sus datos en cualquier entorno de prueba?

La mayoría de las veces, muchos probadores son responsables de probar la misma compilación. En este caso, más de un evaluador tendrá acceso a datos comunes e intentarán manipular el conjunto de datos comunes de acuerdo con sus necesidades.

Si ha preparado datos para algunos módulos específicos, la mejor manera de mantener intacto su conjunto de datos es mantener copias de seguridad del mismo.

Datos de prueba para el caso de prueba de rendimiento

Las pruebas de rendimiento requieren un conjunto de datos muy grande. A veces, la creación de datos manualmente no detectará algunos errores sutiles que solo pueden ser detectados por datos reales creados por la aplicación bajo prueba. Si desea datos en tiempo real, que son imposibles de crear manualmente, pídale a su líder / gerente que los ponga a disposición del entorno en vivo.

Estos datos serán útiles para garantizar el buen funcionamiento de la aplicación para todas las entradas válidas.

¿Cuáles son los datos de prueba ideales?

Se puede decir que los datos son ideales si para el tamaño mínimo del conjunto de datos se identifican todos los errores de la aplicación. Trate de preparar datos que incorporen toda la funcionalidad de la aplicación, pero sin exceder las limitaciones de costo y tiempo para preparar datos y ejecutar pruebas.

¿Cómo preparar datos que garanticen la máxima cobertura de prueba?

Diseñe sus datos considerando las siguientes categorías:

1) Sin datos: Ejecute sus casos de prueba con datos en blanco o predeterminados. Vea si se generan los mensajes de error adecuados.

2) Conjunto de datos válido: Créelo para verificar si la aplicación está funcionando según los requisitos y si los datos de entrada válidos se guardan correctamente en la base de datos o archivos.

3) Conjunto de datos no válido: Prepare un conjunto de datos no válido para verificar el comportamiento de la aplicación en busca de valores negativos, entradas de cadenas alfanuméricas.

4) Formato de datos ilegal: Cree un conjunto de datos de formato de datos ilegal. El sistema no debe aceptar datos en un formato no válido o ilegal. Además, verifique que se generen los mensajes de error adecuados.

5) Conjunto de datos de condiciones de contorno: Conjunto de datos que contiene datos fuera de rango. Identifique los casos de los límites de la aplicación y prepare un conjunto de datos que cubra las condiciones de los límites inferiores y superiores.

6) El conjunto de datos para pruebas de rendimiento, carga y estrés: Este conjunto de datos debe tener un gran volumen.

De esta manera, la creación de conjuntos de datos separados para cada condición de prueba garantizará una cobertura de prueba completa.

Datos para pruebas de caja negra

Los probadores de garantía de calidad realizan pruebas de integración, pruebas del sistema y pruebas de aceptación, que se conocen como pruebas de caja negra. En este método de prueba, los probadores no tienen ningún trabajo en la estructura interna, el diseño y el código de la aplicación bajo prueba.

El objetivo principal de los evaluadores es identificar y localizar errores. Al hacerlo, aplicamos pruebas funcionales o no funcionales utilizando diferentes técnicas de prueba de caja negra.

Figura 4: Métodos de diseño de datos de caja negra

En este punto, los probadores necesitan los datos de prueba como entrada para ejecutar e implementar las técnicas de prueba de caja negra. Y los probadores deben preparar los datos que examinarán toda la funcionalidad de la aplicación sin exceder el costo y el tiempo dados.

Podemos diseñar los datos para nuestros casos de prueba considerando categorías de conjuntos de datos como sin datos, datos válidos, datos no válidos, formato de datos ilegal, datos de condición de límite, partición de equivalencia, tabla de datos de decisión, datos de transición de estado y datos de casos de uso. Antes de entrar en las categorías del conjunto de datos, los probadores inician la recopilación de datos y el análisis de los recursos existentes de la aplicación bajo prueba (AUT).

De acuerdo con los puntos mencionados anteriormente sobre mantener su almacén de datos siempre actualizado, debe documentar los requisitos de datos a nivel de caso de prueba y marcarlos como utilizables o no reutilizables cuando escriba sus casos de prueba. Le ayuda a que los datos necesarios para las pruebas estén bien aclarados y documentados desde el principio, a los que podría consultar para su uso posterior.

Ejemplo de datos de prueba para Open EMR AUT

Para nuestro tutorial actual, tenemos Open EMR como la Aplicación bajo prueba (AUT).

=> Por favor busque el enlace para la aplicación Open EMR aquí para su referencia / práctica.

La siguiente tabla ilustra prácticamente una muestra de la recopilación de requisitos de datos que puede ser parte de la documentación del caso de prueba y se actualiza cuando escribe los casos de prueba para sus escenarios de prueba.

( NOTA : Hacer clic en cualquier imagen para una vista ampliada)

Creación de datos manuales para probar la aplicación Open EMR

Avancemos hacia la creación de datos manuales para probar la aplicación Open EMR para las categorías de conjuntos de datos dadas.

1) Sin datos: El probador valida la URL de la aplicación Open EMR y las funciones 'Buscar o agregar paciente' sin proporcionar datos.

2) Datos válidos: El probador valida la URL de la aplicación Open EMR y la función 'Buscar o agregar paciente' dando datos válidos.

3) Datos no válidos: El probador valida la URL de la aplicación Open EMR y la función 'Buscar o agregar paciente' dando datos no válidos.

4) Formato de datos ilegal: El probador valida la URL de la aplicación Open EMR y la función 'Buscar o agregar paciente' dando datos no válidos.

Datos de prueba para 1-4 categorías de conjuntos de datos:

5) Conjunto de datos de condiciones de contorno: Sirve para determinar los valores de entrada para los límites que están dentro o fuera de los valores dados como datos.

6) Conjunto de datos de partición de equivalencia: Es la técnica de prueba que divide los datos de entrada en valores de entrada válidos e inválidos.

Datos de prueba para 5^thy 6^thcategorías de conjuntos de datos, que es para el nombre de usuario y la contraseña de Open EMR:

7) Conjunto de datos de la tabla de decisiones: Es la técnica para calificar sus datos con una combinación de entradas para producir varios resultados. Este método de prueba de caja negra le ayuda a reducir sus esfuerzos de prueba para verificar todas y cada una de las combinaciones de datos de prueba. Además, esta técnica puede garantizarle la cobertura completa de la prueba.

Consulte a continuación el conjunto de datos de la tabla de decisiones para el nombre de usuario y la contraseña de la aplicación Open EMR.

El cálculo de las combinaciones realizado en la tabla anterior se describe para su información detallada a continuación. Puede que lo necesite cuando haga más de cuatro combinaciones.

• Número de combinación = Número de condiciones 1 valores * Número de condiciones 2 valores
• Número de combinaciones = 2 ^ Número de condiciones verdaderas / falsas
• Ejemplo: número de combinaciones - 2 ^ 2 = 4

8) Conjunto de datos de prueba de transición de estado: Es la técnica de prueba que le ayuda a validar la transición de estado de la Aplicación bajo prueba (AUT) proporcionando al sistema las condiciones de entrada.

Por ejemplo, iniciamos sesión en la aplicación Open EMR proporcionando el nombre de usuario y la contraseña correctos en el primer intento. El sistema nos da acceso, pero si ingresamos los datos de inicio de sesión incorrectos, el sistema niega el acceso. Las pruebas de transición de estado validan cuántos intentos de inicio de sesión puede realizar antes de que se cierre Open EMR.

La siguiente tabla indica cómo responden los intentos correctos o incorrectos de inicio de sesión

cómo usar maven en eclipse

9) Fecha de prueba del caso de uso: Es el método de prueba que identifica nuestros casos de prueba y captura la prueba de un extremo a otro de una característica en particular.

Ejemplo, inicio de sesión de EMR abierto:

Leer también => Técnicas de gestión de datos

Propiedades de una buena prueba de datos

Como evaluador, debe probar el módulo 'Resultados del examen' del sitio web de una universidad. Tenga en cuenta que toda la aplicación se ha integrado y está en estado 'Lista para probar'. El 'Módulo de examen' está vinculado con los módulos 'Registro', 'Cursos' y 'Finanzas'.

Suponga que tiene información adecuada sobre la aplicación y creó una lista completa de escenarios de prueba. Ahora tienes que diseñar, documentar y ejecutar estos casos de prueba. En la sección 'Acciones / Pasos' o 'Entradas de prueba' de los casos de prueba, deberá mencionar los datos aceptables como entrada para la prueba.

Los datos mencionados en los casos de prueba deben seleccionarse correctamente. La precisión de la columna 'Resultados reales' del documento de caso de prueba depende principalmente de los datos de la prueba. Por lo tanto, el paso para preparar los datos de prueba de entrada es muy importante. Por lo tanto, aquí está mi resumen sobre 'Pruebas de base de datos - Estrategias de preparación de datos de prueba'.

Propiedades de los datos de prueba

Los datos de prueba deben seleccionarse con precisión y deben poseer las siguientes cuatro cualidades:

1) Realista:

Por realista, significa que los datos deben ser precisos en el contexto de escenarios de la vida real. Por ejemplo, para probar el campo 'Edad', todos los valores deben ser positivos y 18 o más. Es bastante obvio que los candidatos a la admisión en la universidad suelen tener 18 años (esto podría definirse de manera diferente en términos de requisitos comerciales).

Si la prueba se realiza utilizando datos de prueba realistas, la aplicación será más sólida, ya que la mayoría de los posibles errores se pueden capturar con datos realistas. Otra ventaja de los datos realistas es su reutilización, lo que nos ahorra tiempo y esfuerzo para crear nuevos datos una y otra vez.

Cuando hablamos de datos realistas, me gustaría presentarles el concepto del conjunto de datos dorado. Un conjunto de datos dorado es aquel que cubre casi todos los escenarios posibles que ocurren en el proyecto real. Al utilizar el GDS, podemos proporcionar la máxima cobertura de prueba. Utilizo el GDS para hacer pruebas de regresión en mi organización y esto me ayuda a probar todos los escenarios posibles que pueden ocurrir si el código va en la caja de producción.

Hay muchas herramientas generadoras de datos de prueba disponibles en el mercado que analizan las características de la columna y las definiciones de usuario en la base de datos y, en base a ellas, generan datos de prueba realistas para usted. Pocos de los buenos ejemplos de las herramientas que generan datos para las pruebas de bases de datos son Generador de datos DTM , Generador de datos SQL y Mockaroo .

2. Prácticamente válido:

Esto es similar a realista pero no lo mismo. Esta propiedad está más relacionada con la lógica empresarial de AUT, p. Ej. El valor 60 es realista en el campo de la edad, pero prácticamente no es válido para un candidato de graduación o incluso programas de maestría. En este caso, un rango válido sería de 18 a 25 años (esto podría definirse en los requisitos).

3. Versátil para cubrir escenarios:

cómo agregar valores a una matriz de Java

Puede haber varias condiciones posteriores en un solo escenario, así que elija los datos astutamente para cubrir los aspectos máximos de un solo escenario con el conjunto mínimo de datos, p. Al crear datos de prueba para el módulo de resultados, no solo considere el caso de los estudiantes regulares que están completando su programa sin problemas. Preste atención a los estudiantes que están repitiendo el mismo curso y pertenecen a semestres diferentes o incluso a programas diferentes. El conjunto de datos puede verse así:

Puede haber varias otras subcondiciones interesantes y complicadas. P.ej. la limitación de años para completar un programa de grado, superando un curso prerrequisito para inscribirse en un curso, máximo no. de los cursos que un estudiante puede inscribirse en un solo semestre, etc. etc. Asegúrese de cubrir todos estos escenarios sabiamente con el conjunto finito de datos.

4. Datos excepcionales (si corresponde / requerido):

Puede haber ciertos escenarios excepcionales que ocurren con menos frecuencia pero que exigen una gran atención cuando ocurrieron, p. problemas relacionados con los estudiantes discapacitados.

Otra buena explicación y ejemplo del conjunto de datos excepcional se ve en la siguiente imagen:

Quitar:

Los datos de una prueba se conocen como buenos datos de prueba si son realistas, válidos y versátiles. Es una ventaja adicional si los datos también brindan cobertura para escenarios excepcionales.

Técnicas de preparación de datos de prueba

Hemos discutido brevemente las propiedades importantes de los datos de prueba y también hemos elaborado cómo la selección de datos de prueba es importante mientras se realizan las pruebas de la base de datos. Ahora analicemos el ‘ técnicas para preparar datos de prueba ’ .

Solo hay dos formas de preparar datos de prueba:

Método 1) Insertar datos nuevos

Obtenga una base de datos limpia e inserte todos los datos como se especifica en sus casos de prueba. Una vez que haya ingresado todos los datos requeridos y deseados, comience a ejecutar sus casos de prueba y complete las columnas 'Pasa / No pasa' comparando el 'Resultado real' con el 'Resultado esperado'. Suena simple, ¿verdad? Pero espera, no es tan simple.

Algunas preocupaciones esenciales y críticas son las siguientes:

• Es posible que una instancia vacía de la base de datos no esté disponible
• Los datos de prueba insertados pueden ser insuficientes para probar algunos casos como el rendimiento y las pruebas de carga.
• Insertar los datos de prueba requeridos en la base de datos en blanco no es un trabajo fácil debido a las dependencias de la tabla de la base de datos. Debido a esta restricción inevitable, la inserción de datos puede convertirse en una tarea difícil para el evaluador.
• La inserción de datos de prueba limitados (solo de acuerdo con las necesidades del caso de prueba) puede ocultar algunos problemas que solo se pueden encontrar con el gran conjunto de datos.
• Para la inserción de datos, es posible que se requieran consultas y / o procedimientos complejos, y para esto sería necesaria la suficiente asistencia o ayuda del desarrollador (es) de la base de datos.

Los cinco problemas mencionados anteriormente son los inconvenientes más críticos y más obvios de esta técnica para la preparación de datos de prueba. Pero también hay algunas ventajas:

• La ejecución de TC se vuelve más eficiente ya que la base de datos solo tiene los datos necesarios.
• El aislamiento de errores no requiere tiempo, ya que solo los datos especificados en los casos de prueba están presentes en la base de datos.
• Se requiere menos tiempo para las pruebas y la comparación de resultados.
• Proceso de prueba sin desorden

Método # 2) Elija un subconjunto de datos de muestra de los datos reales de la base de datos

Esta es una técnica factible y más práctica para la preparación de datos de prueba. Sin embargo, requiere habilidades técnicas sólidas y un conocimiento detallado de DB Schema y SQL. En este método, debe copiar y usar datos de producción reemplazando algunos valores de campo por valores ficticios. Este es el mejor subconjunto de datos para sus pruebas, ya que representa los datos de producción. Pero esto puede no ser factible todo el tiempo debido a problemas de privacidad y seguridad de los datos.

Quitar:

En la sección anterior, hemos discutido anteriormente las técnicas de preparación de datos de prueba. En resumen, hay dos técnicas: crear datos nuevos o seleccionar un subconjunto de datos ya existentes. Ambos deben realizarse de manera que los datos seleccionados brinden cobertura para varios escenarios de prueba, principalmente prueba válida e inválida, prueba de rendimiento y prueba nula.

En la última sección, también haremos un recorrido rápido por los enfoques de generación de datos. Estos enfoques son útiles cuando necesitamos generar nuevos datos.

Enfoques de generación de datos de prueba:

• Generación manual de datos de prueba: En este enfoque, los probadores ingresan manualmente los datos de prueba según los requisitos del caso de prueba. Es un proceso que toma tiempo y también es propenso a errores.
• Generación de datos de prueba automatizada: Esto se hace con la ayuda de herramientas de generación de datos. La principal ventaja de este enfoque es su velocidad y precisión. Sin embargo, tiene un costo más alto que la generación manual de datos de prueba.
• Inyección de datos de back-end : Esto se realiza mediante consultas SQL. Este enfoque también puede actualizar los datos existentes en la base de datos. Es rápido y eficiente, pero debe implementarse con mucho cuidado para que la base de datos existente no se corrompa.
• Uso de herramientas de terceros : Hay herramientas disponibles en el mercado que primero comprenden sus escenarios de prueba y luego generan o inyectan datos en consecuencia para proporcionar una amplia cobertura de prueba. Estas herramientas son precisas, ya que se personalizan según las necesidades comerciales. Pero son bastante costosos.

Quitar:

Hay 4 enfoques para probar la generación de datos:

1. manual,
2. automatización,
3. inyección de datos de back-end,
4. y herramientas de terceros.

Cada acercamiento tiene sus propios pros y contras. Debe seleccionar el enfoque que satisfaga sus necesidades comerciales y de prueba.

Conclusión

La creación de datos de prueba de software completos de conformidad con los estándares de la industria, la legislación y los documentos de referencia del proyecto emprendido se encuentra entre las responsabilidades principales de los probadores. Cuanto más eficientemente gestionemos los datos de prueba, más podremos implementar productos razonablemente libres de errores para los usuarios del mundo real.

La gestión de datos de prueba (TDM) es el proceso que se basa en el análisis de desafíos y la introducción y aplicación de las mejores herramientas y métodos para abordar bien los problemas identificados sin comprometer la confiabilidad y la cobertura total del resultado final (producto).

Siempre debemos plantearnos preguntas para buscar métodos innovadores y más rentables para analizar y seleccionar los métodos de prueba, incluido el uso de herramientas para generar los datos. Está ampliamente probado que los datos bien diseñados nos permiten identificar los defectos de la aplicación bajo prueba en cada fase de un SDLC multifase.

Necesitamos ser creativos y participar con todos los miembros dentro y fuera de nuestro ágil equipo. Comparta sus comentarios, experiencias, preguntas y comentarios para que podamos mantener nuestras discusiones técnicas en curso para maximizar nuestro impacto positivo en AUT mediante la gestión de datos.

La preparación de datos de prueba adecuados es una parte fundamental de la 'configuración del entorno de prueba del proyecto'. No podemos simplemente perdernos el caso de prueba que dice que los datos completos no estaban disponibles para la prueba. El probador debe crear sus propios datos de prueba adicionales a los datos de producción estándar existentes. Su conjunto de datos debe ser ideal en términos de costo y tiempo.

Sea creativo, use sus propias habilidades y juicios para crear diferentes conjuntos de datos en lugar de depender de los datos de producción estándar.

Parte II - La segunda parte de este tutorial está en el “ Generación de datos de prueba con la herramienta en línea GEDIS Studio ”.

¿Ha enfrentado el problema de los datos de prueba incompletos para la prueba? ¿Cómo lo lograste? Comparta sus consejos, experiencia, comentarios y preguntas para enriquecer aún más este tema de discusión.

Lectura recomendada

• Tutorial de pruebas de almacenamiento de datos de pruebas ETL (una guía completa)
• ¿Qué es la prueba de mutación? Tutorial con ejemplos
• Cómo realizar pruebas basadas en datos con la herramienta TestComplete
• Pruebas basadas en datos o parametrizadas con Spock Framework
• Los 4 pasos para las pruebas de inteligencia empresarial (BI): cómo probar datos empresariales
• Tutorial de prueba de volumen: ejemplos y herramientas de prueba de volumen
• Una forma excelente de realizar pruebas de datos con tecnologías XML (informe técnico)
• Las 10 mejores herramientas de validación y pruebas de datos estructurados para SEO