2009-05-11 11 views
23

Hemos escrito nuestro propio arnés de prueba de integración donde podemos escribir una serie de "operaciones" o pruebas, como "Generar órdenes". Tenemos una serie de parámetros que podemos usar para configurar las pruebas (como el número de pedidos). Luego escribimos una segunda operación para confirmar que la prueba ha pasado/Falló (es decir, hay (nt) pedidos).¿Cuál es una excelente manera de realizar pruebas de integración?

La herramienta se utiliza para

  • Pruebas de Integración
  • generación de datos
  • Pruebas de extremo a extremo (mezclando y combinando una serie de pruebas)

Parece funciona bien, sin embargo requiere experiencia de desarrollo para mantener y escribir nuevas pruebas. Nuestro equipo de prueba quisiera involucrarse, quienes tienen poca experiencia en el desarrollo de C#.

Estamos a punto de comenzar un nuevo proyecto de Greenfield y estoy investigando la forma óptima de escribir y mantener pruebas de integración.

Las preguntas son las siguientes:

  • ¿Cómo se realiza la prueba de integración?
  • ¿Qué herramienta usas (FitNess ?, Custom ?, NUnit)?

Espero sugerencias o comentarios de la gente.

Gracias de antemano,

David

+0

¿Está planeando usar Pruebas de integración continua? –

+0

No es mi intención hacer la pregunta, pero creo que al menos algo de experiencia en desarrollo/C# puede ser muy beneficioso para los evaluadores. Este puede ser el momento para que adquieran un poco de habilidad en el departamento de dev't. –

+0

@McWaffletix - La herramienta personalizada que escribimos se está ejecutando cuando el código está registrado, por CC.NET, por lo que se ejecutará continuamente :). @Greg D - Estoy totalmente de acuerdo :) Sin embargo, nuestros probadores no lo hacen! El problema es persuadirlos C# es divertido. Es un cambio de mentalidad completo, continuamente obtenemos "no somos desarrolladores" ... –

Respuesta

12

Las pruebas de integración se puede realizar en un nivel de interfaz de usuario (a través de pruebas funcionales automatizadas - AFT) o nivel de interfaz de servicio/API.

Hay varias herramientas en ambos casos:

He trabajado en proyectos que utilizan con éxito Sahi o Selenium de AFT de aplicaciones web, white de popa para WPF o WinForms aplicaciones .NET, swtBot de AFT de Eclipse Rich aplicaciones de cliente y frankenstein para AFT of Java swing apps.

Fitnesse es útil para pruebas de nivel de servicio/api o para pruebas que se ejecutan justo debajo de la IU. Cuando se hace bien, tiene la ventaja de tener pruebas legibles por negocios, es decir, los que no son desarrolladores pueden leer y comprender las pruebas. Herramientas como NUnit son menos útiles para este propósito. SOAPUI es particularmente adecuado para probar servicios web SOAP.

Los factores a considerar:

  • Duración: ¿Se puede tolerar 8 horas corridas de prueba?
  • Fragilidad: AFT puede ser bastante frágil frente a una aplicación en evolución (por ejemplo, los ids y las posiciones de los widgets pueden cambiar).Se necesita habilidad y esfuerzo adecuados para no codificar las partes cambiantes.
  • Fidelity: ¿Qué tan cerca del mundo real quieres que sea? p.ej. Puede que tenga que simular interacciones con una pasarela de pago a menos que el proveedor le proporcione un entorno de prueba que pueda superar con sus pruebas.

Algunos matices se capturan here.

Descripción completa: El autor está asociado con la organización detrás de la mayoría (no todas) de las herramientas de código abierto y gratuito anteriores.

+0

Esto es lo que buscamos al final. Hemos creado una aplicación web que funciona como WCFTestClient.exe aunque permite tipos complejos para que podamos usar selenio para realizar pruebas de integración en el nivel de UI :) –

1

No es fuera de beta todavía, pero StoryTeller parece prometedor:

2

Puede probar el marco Concordion para escribir pruebas de aceptación del usuario en archivos HTML. Se necesita un enfoque de estilo BDD. También hay un .Net port

Cuestiones relacionadas