Descripción general de las pruebas de conversión en las pruebas de software

Pruebas de conversión:
cada proceso de desarrollo de software sigue el ciclo de vida de desarrollo de software (SDLC) para desarrollar y entregar un producto de software de buena calidad. En la fase de prueba del desarrollo de software, se realizan diferentes tipos de pruebas de software para verificar diferentes parámetros de verificación o casos de prueba. Donde en cada software, los datos son una parte importante, ya que con la ayuda de los datos, una aplicación de software realiza sus operaciones. La prueba de conversión se realiza para verificar la conversión de un formato de datos a otro formato de datos que una aplicación puede utilizar de forma continua durante el proceso de prueba. Cualquier tipo de datos se puede convertir de un formulario a otro, pero las páginas web deben estar en formato HTML para que el navegador pueda representar fácilmente la página.

Algunos ejemplos de prueba comunes:

• Color del botón:
  por ejemplo, probamos si un botón azul convierte a una tasa más alta que un botón rojo.
• Imagen de fondo:
  por ejemplo, prueba si la imagen de fondo se convierte a una tasa más alta que una imagen simple normal.
• Oferta:
  por ejemplo, prueba si el envío gratuito de productos de $50 o menos convierte un descuento superior al 10%.
• Ventana emergente :
  por ejemplo, prueba si una ventana emergente se convierte a una tasa más alta en lugar de un control flotante para los visitantes móviles.

Pruebas A/B v/s Pruebas secuenciales:

1. A/B Test es simplemente crear dos versiones de algo. Automáticamente tiene en cuenta todos los factores porque la única diferencia entre un conjunto de visitantes de otro es que lo que ven en su sitio, mientras que el tiempo, el año y el clima es el mismo, es decir, restringe las actividades externas que pueden influir en el resultado.
2. Por otro lado, en las pruebas secuenciales estamos haciendo una cosa por un período de tiempo y si hacemos algunos cambios los dejaríamos por el mismo período de tiempo, entonces podemos comparar fácilmente los resultados. Pero en este caso está correctamente analizado porque muchos factores podrían haber alterado los resultados que pueden estar fuera de control.

Niveles de pruebas de conversión de datos:
Hay principalmente dos niveles de pruebas que se realizan, es decir, técnicas y comerciales, «pruebas cálidas y difusas». Las pruebas técnicas verificarán la conversión con respecto a las especificaciones, mientras que las pruebas comerciales brindarán a los representantes comerciales la confianza cuando su antiguo sistema esté en reposo, los valiosos datos se copiarán sin problemas en el nuevo sistema.

1. Pruebas técnicas:

Deberíamos iniciar esta prueba estableciendo la trazabilidad de la prueba. Al menos una vez, la prueba debe escribirse contra cada declaración como antes para garantizar que la prueba cubra todos los datos que se convertirán. Deberíamos iniciar esta prueba estableciendo la trazabilidad de la prueba. Al menos una vez, la prueba debe escribirse contra cada declaración como antes para garantizar que la prueba cubra todos los datos que se convertirán.

Podemos escribir consultas de muchas maneras para probar si un registro en particular se convirtió correctamente. 

Hay principalmente dos consultas más comunes:

• (i) Recuento de filas
• (ii) Identificar objetos con datos faltantes

(i) Recuento de filas:
se utilizan para comparar no. de registros en la tabla de origen y destino. Si la conversión es una conversión directa, las consultas anteriores pueden verificar fácilmente que no. de filas Si se van a convertir registros con un parámetro particular, entonces podemos seguir la ejecución de las siguientes consultas.

Run against Source Table,
Choose count(*) from [Source table]
where [field1] = [a condition]
          [field2] = [another condition]
Run against Target Table,
Choose count(*) from [Target table]

 Esta prueba le dará no. del subconjunto de la tabla de origen que se va a convertir y el número total. de filas en la tabla de destino. La prueba pasa si los números coinciden.

(ii) Identificar objetos con datos faltantes:
su objetivo es identificar los objetos principales cuyos objetos secundarios que deberían haberse convertido están ausentes. Prueba que cada padre tiene su objeto secundario correspondiente. Escribimos la consulta SQL en los siguientes pasos.

una. Escriba una consulta que obtenga la clave externa que vuelve a la tabla principal desde la tabla de objetos secundarios. p.ej

where  [field1] = [value1] AND
 [field2] = [value2] AND
 [field3] = [value3]

Aquí esto proporcionará todos los objetos secundarios correctamente conectados.

b. Escriba una consulta para la tabla principal que obtenga todos los parent_id que deberían ser objetos secundarios en ChildObjectTable, por ejemplo

choose id from parentTable
where [fieldX] = [a value]

      C. Ahora combinamos las dos consultas que ayudarán a generar una nueva consulta para mostrar parent_id que no existían en la primera consulta. p.ej

select id from parentTable
where [fieldX] = [some value] and
id  is not in (
select parent_id from childObjectTable
where [field1] = [value1] AND
           [field2] = [value2] AND
           [field3] = [value3]
)

Entonces, la lista generará una lista de parent_id completos a los que les falta un objeto secundario generado correctamente de childObjectTable.

2. Pruebas comerciales:

• La prueba comercial, una vez identificada, se puede realizar utilizando el servicio SQL o ejecutando pruebas de GUI. En esta prueba, el personal comercial sabrá lo que busca en el sistema anterior y, al seguir las acciones en la prueba, podemos demostrar que los datos que les interesan se convierten con precisión.
• Entonces, aquí escribirían una prueba como la de una prueba funcional que incluye navegación a través del sistema, etc., que mostrará los datos en el sistema.