2008-09-17 6 views
7

Estoy presentando pruebas de integración automatizada para una aplicación madura que hasta ahora solo se ha probado manualmente.Integración automatizada probando una aplicación C++ con una base de datos

La aplicación está basada en Windows y se comunica con una base de datos MySQL.

¿Cuál es la mejor forma (incluidos los detalles de las herramientas recomendadas) de mantener las pruebas independientes unas de otras en términos de las transacciones de la base de datos que se producirán?

(Modificaciones a la fuente de la aplicación para este propósito en particular no son una opción.)

Respuesta

3

¿Cómo está verificando los resultados?

Si necesita consultar el DB (y suena como probablemente lo haga) para obtener resultados entonces estoy de acuerdo con Kris K, excepto que me esforzaría por reconstruir el DB después de cada caso de prueba, no solo en cada suite.

Esto ayuda a evitar la peligrosa interacting tests

cuanto a las herramientas, recomendaría CppUnit.No está realmente haciendo pruebas unitarias, pero no debería importar ya que el marco xUnit debería darle el marco de configuración y desmontaje que necesitará para configurar automáticamente su test fixture

Obviamente esto puede resultar en una ejecución lenta pruebas, dependiendo del tamaño de su base de datos, población, etc. Es posible que pueda adjuntar/separar bases de datos en lugar de descartar/reconstruir.

Si está interesado en seguir investigando, consulte XUnit Test Patterns. Es un buen libro y un buen sitio web para este tipo de cosas.

Y gracias a la automatización :)

Nick

1

se puede volcar/restaurar la base de datos para cada conjunto de pruebas, etc. Dado que está automatizando esto, puede haber algo en el funcionalidad de configuración/desmontaje.

0

El mejor entorno para tales pruebas, creo, es VMWare o un equivalente. Configure su base de datos, registro de transacciones, etc., y luego registre todo el lote, la base de datos y la configuración. Luego, para volver a probar, vuelva a cargar la imagen y la base de datos y comience las pruebas. Esto aún requiere el mantenimiento de las pruebas a medida que el sistema cambia, pero al menos las pruebas son repetibles, que es uno de sus mayores desafíos en las pruebas de integración.

Para la automatización de pruebas, mucha gente usa Perl, pero descubrimos que los programas Perl crecen como Topsy y se vuelven complicados. El uso de Python como lenguaje de scripting (ejecutamos pruebas de C++) vale la pena si estás intentando construir una serie de pruebas estructuradas.

0

Como @Kris K. dice que el dumping y la restauración de la base de datos entre cada prueba probablemente sea el camino a seguir.

Como usted está buscando realizar pruebas externas a la Aplicación, me gustaría construir el marco de prueba en un lenguaje en el que pueda aprovechar mejores herramientas de prueba.

Si construyó el marco de prueba en Java podría aprovechar JUnit y potencialmente incluso algo así como FitNesse.

No piense que solo porque la aplicación bajo prueba es C++ eso significa que está estancado al usar C++ para sus pruebas automatizadas.

1

Solía ​​restaurar la base de datos en la función SetUp de la clase de prueba de la unidad relacionada con la base de datos. De esta manera, se aseguró que cada prueba se ejecuta en las mismas condiciones.

Puede considerar preparar contenido de base de datos especial para las pruebas, es decir, con menos datos que la versión de producción actual (para mantener los tiempos de restauración razonables).

0

Inténtelo AnyDbTest, creo que es la herramienta que está encontrando. (www.anydbtest.com).

Características: caso de prueba

  • 1.Writing con XML, no Java/C++/C# código/VB. No necesita esas costosas herramientas de programación.

  • 2.Supports bases de datos de todos los populares, tales como Oracle/SQL Server/My SQL

  • 3.So muchos tipos de afirmación compatibles, como StrictEqual, SetEqual, IsSupersetOf, superposiciones y RecordCountEqual etc. Plus , la mayoría de las aserciones pueden prefijar la lógica, no el operador.

  • 4.Permite utilizar una hoja de cálculo Excel/Xml como fuente de los datos para las pruebas. Como sabe, la hoja de cálculo de Excel es para crear/editar y mantener fácilmente los datos de prueba.

  • 5. Soporta el modelo de prueba de sandbox, si se realiza una prueba en el entorno limitado, todas las operaciones de la base de datos en cada base de datos se revertirán, lo que significa que cualquier cambio se deshará.

  • 6. Permite realizar la bomba de datos de una base de datos/Excel en la base de datos de destino durante la fase de inicialización y finalización de la prueba. Esta es una manera fácil de preparar los datos de prueba para la prueba.

  • 7. Pruebas únicas de bases de datos de tipos cruzados, lo que significa que el conjunto de resultados de referencia y destino puede provenir de dos bases de datos, incluso una es SQL Server, otra es Oracle.

  • 8.Configuración del estilo de conjunto para recordset. AnyDbTest le dirá cuál es la intersección, o excedente o ausencia entre los dos conjuntos de registros.

  • 9. Comparación de estilo secuencial para recordset o valores escalares. Significa que los dos conjuntos de resultados se compararán en su secuencia original.

  • 10.Allow para exportar el conjunto de resultados de la declaración SQL en el archivo Xml/Excel.

Cuestiones relacionadas