MSDN Magazine > Inicio > Todos los números > 2008 > Launch >  Test Run: Automatización de pruebas person...
Test Run
Automatización de pruebas personalizadas con Team System
Dr. James McCaffrey

Descarga de código disponible en: TestRun2008_Launch.exe (205 KB)
Browse the Code Online
No existe una mejor manera de realizar pruebas de software. Además de las pruebas manuales, según el entorno de desarrollo específico del usuario, puede que esté usando marcos de automatización de pruebas comerciales, código abierto y marcos de automatización de pruebas internos y scripts de automatización personalizada de pruebas. Todos estos métodos tienen ventajas y desventajas.
Los scripts de automatización de pruebas tienen las ventajas de poder escribirse rápidamente y ofrecer una flexibilidad máxima. Sin embargo, una desventaja del uso de la automatización personalizada de pruebas es la capacidad de administración. El esfuerzo para realizar pruebas se puede aumentar significativamente debido al volumen de scripts de prueba, a los datos de casos de prueba y a los resultados de la prueba. Por suerte, Visual Studio ® 2005 Team System proporciona la capacidad de administrar la automatización personalizada de pruebas. Permítame mostrarle lo que significa usar un par de capturas de pantalla. En primer lugar, considere el script de automatización de pruebas en ejecución que se muestra en la figura 1.
Figura 1 Script típico de automatización de pruebas (Hacer clic en la imagen para ampliarla)
La automatización de pruebas es un script de JavaScript muy corto que realiza pruebas de módulo en un método denominado TriMax y que vuelve simplemente el más grande de tres números enteros. El método TriMax reside en un archivo clásico COM DLL. Aunque sea sencillo y eficaz, la automatización de pruebas mediante este tipo de método presenta varias desventajas. ¿Dónde se almacenan los resultados de la prueba? ¿Contra qué compilación del archivo DLL se ejecuta esta prueba? ¿Cómo se pueden compartir los resultados de la prueba con otros miembros del equipo de desarrollo? ¿Están estos resultados relacionados con algún error abierto? Visual Studio Team System está diseñado para administrar dichos problemas, tal como muestra la figura 2.
Figura 2 Administración de la automatización personalizada con Team System (Hacer clic en la imagen para ampliarla)
Visual Studio 2005 Team System incluye Team Foundation Server (TFS) más una de las ediciones cliente de Visual Studio. Puede considerar TFS como un almacén inteligente de datos back-end que almacena y administra todos los datos asociados con un proyecto de desarrollo de software, incluido el código fuente, los errores, los resultados de las pruebas, los documentos de especificaciones y mucho más.
La funcionalidad de automatización personalizada de pruebas que describo en esta columna se ofrece a los evaluadores en Visual Studio Team Edition. Puede descargar la versión de evaluación de 180 días de Visual Studio 2005 Team Suite, que incluye la funcionalidad de todas las ediciones, además de Team Foundation Server en la dirección microsoft.com/downloads.
Presentaré tres ejemplos en esta columna. La primera muestra cómo usar VSTE para que los evaluadores puedan tomar una parte muy sencilla de la automatización personalizada de pruebas e incluirla en una prueba que Team System podrá administrar. El segundo ejemplo amplía el primero y muestra cómo modificar la automatización personalizada de pruebas de modo que pueda crear los resultados del caso de prueba con información más detallada que simplemente una aprobación o un error como resultado. Mi tercer ejemplo muestra cómo usar Team Foundation Server para almacenar y administrar los datos del resultado de la ejecución de la prueba.
Antes de entrar en detalles, describiré brevemente el módulo en el que se realizará la prueba para que pueda comprender la sencilla automatización personalizada de pruebas y poder crear el módulo si así los desea. (Si sabe crear objetos COM mediante ATL, puede pasar a la sección siguiente).
Mi módulo es un método Win32® C++ denominado TriMax. Mediante Visual Studio, he creado un proyecto nuevo mediante una plantilla ATL de C++ y le asigné el nombre MyCOMLib. Acepté todos los valores de configuración predeterminados del asistente de ATL, los cuales indican a Visual Studio que debe crear un archivo DLL. En el Explorador de soluciones del proyecto, hice clic con el botón secundario del mouse en el nombre de proyecto y seleccioné Agregar | Clase del menú contextual. A continuación, de la categoría ATL, seleccioné la plantilla de objeto sencillo ATL. Luego, en el Asistente para plantillas de objeto sencillo ATL, escribí "MyMethods" en el campo Nombre corto de C++, que rellenó automáticamente los siete campos de nombre restantes (el archivo .h como MyMethods.h, Clase como CMyMethods, el archivo .cpp como MyMethods.cpp, Coclass como MyMethods, Tipo como MyMethodsClass, Interfaz como IMyMethods y ProgID como MyCOMLib.MyMethods).
Después que terminar el asistente, pasé a la ventana de Vista de clases, hice clic con el botón secundario del mouse en la interfaz IMyMethods y seleccioné Agregar | Agregar el método del menú contextual. En el Asistente para agregar método, le asigné al método el nombre TriMax. Luego agregué tres parámetros de entrada, denominados X, Y y Z, todos del tipo LONG y también agregué un parámetro LONG* retval para contener el valor de devolución del método. Después de que hacer clic en el botón Finalizar del Asistente para agregar métodos, regresé a la vista del Explorador de soluciones en Visual Studio e hice doble clic en MyMethods.cpp de la carpeta de archivos de código fuente. El código sencillo para el método bajo prueba es el siguiente:
STDMETHODIMP CMyMethods::TriMax(LONG x, LONG y, LONG z, LONG* pRes)
{
  if (x > y && x > z)
    *pRes = x;
  else if (y > z)
    *pRes = y;
  else
    *pRes = z;

  return S_OK;
} 
Presioné Ctrl + Mayús + B para realizar una compilación local de mi objeto COM. Y, por último, usé Explorador de Windows para comprobar que el archivo MyCOMLib.Dll resultante se creó correctamente en el subdirectorio MyCOMLib\Debug. Como puede observar, el método de TriMax es demasiado sencillo como para ser realista; simplemente busco algo contra el que realizar la automatización de pruebas. Quiero hacer hincapié en que, aunque los ejemplos que siguen usan código de automatización de pruebas de JavaScript para realizar pruebas de un objeto Win32 COM, los principios de usar Visual Studio Team System para administrar la automatización personalizada de pruebas se aplican a cualquier tipo de automatización personalizada de pruebas (incluidos C#, Visual Basic® .NET, Windows PowerShell®, etc.) cuyo objetivo es cualquier tipo de sistema bajo prueba (incluidas las bibliotecas .NET administradas, aplicaciones basadas en formularios de Windows®, aplicaciones web de ASP.NET, servicios web de ASP.NET, etc.).

Ajuste de un script sencillo de automatización de pruebas
Ahora miremos el script sencillo de automatización de pruebas de la figura 3. Luego mostraré cómo integrar el script en VSTE para evaluadores y describiré las ventajas de hacer esto. Mi script empieza por mostrar un par de mensajes mediante el método Echo de Windows Script Host. A continuación, creo una instancia del objeto COM que contiene el método bajo prueba:
// testSimple.js

WScript.Echo("\nBegin test run\n");
WScript.Echo("Testing TriMax() in MyCOMLib.dll\n");
var o = new ActiveXObject("MyCOMLib.MyMethods");

var cases = new Array( "001:3*7*5:7",
                       "002:0*0*0:1",
                       "003:2*4*6:6" );
var allPassed = true;

for (var i = 0; i < cases.length; ++i)
{
  var tokens = cases[i].split(":");
  var id = tokens[0];
  var inputs = tokens[1];
  var expected = tokens[2];

  var temp = inputs.split("*");
  var arg1 = temp[0];
  var arg2 = temp[1];
  var arg3 = temp[2];
  
  WScript.Echo("==============");
  WScript.Echo("Case ID = " + id);
  WScript.Echo("Inputs = " + arg1 + " " + arg2 + " " + arg3);
  var actual = o.TriMax(arg1,arg2,arg3);
  WScript.Echo("Expected = " + expected);
  WScript.Echo("Actual = " + actual);
  if (actual == expected) {
    WScript.Echo("Pass");
  }
  else {
    WScript.Echo("**FAIL**");
    allPassed = false;
  }
}

WScript.Echo("==============");
if (allPassed == true) {
  WScript.Echo("\nAll test cases passed");
  WScript.Quit(0);
}
else {
  WScript.Echo("\nOne or more cases failed");
  WScript.Quit(1);
}

var o = new ActiveXObject("MyCOMLib.MyMethods");
Dado que estoy realizando pruebas de un objeto COM clásico, puedo hacer referencia al objeto mediante su ProgID. Asimismo, dado que compilé el objeto COM en el equipo host de prueba, la información del objeto se almacenó en el Registro del sistema. Tenga en cuenta que si hubiera copiado el archivo MyCOMLib.dll a mi equipo host de prueba desde un equipo diferente, habría debido registrar la DLL mediante una llamada a regsvr32.exe con el método Run del objeto WScript.Shell. Mi script de ejemplo almacena sus datos de caso de prueba internamente:
var cases = new Array( "001:3*7*5:7",
                       "002:0*0*0:1",
                       "003:2*4*6:6" );
var allPassed = true;
Como regla general, es preferible almacenar los datos de caso de prueba externamente al código de automatización de pruebas. El almacenamiento externo permite compartir y modificar casos de prueba con mayor facilidad que los datos que se almacenan de manera interna. Sin embargo, los datos internos son más sencillos y a veces representan una elección buena de diseño.
En este ejemplo sencillo, tengo tres casos de prueba. La primera prueba del método TriMax(x,y,z) tiene una identificación de 001, entradas de 3, 5 y 7 y un resultado esperado de 7. El segundo caso de prueba tiene un error intencional para fines de demostración. Observe que inicializo una variable denominada allPassed en true. Esta variable realice el seguimiento de si se aprueban o no todos los casos de prueba individuales. Mi automatización de pruebas itera a través de cada caso de prueba, analizando el identificador del caso de prueba, las entradas y el valor esperado. Con esos valores en mano, mi script invoca el método bajo prueba y compara el resultado real con el resultado esperado para determinar un resultado de aprobación/error para el caso de prueba individual:
var actual = o.TriMax(arg1,arg2,arg3);
if (actual == expected) {
  WScript.Echo("Pass");
}
else {
  WScript.Echo("**FAIL**");
  allPassed = false;
}
Si se encuentra un caso de prueba con error, establezco el valor de la variable allPassed en false. Por último, el ejemplo de script de prueba termina con el uso del método WScript.Quit para establecer el código de salida del proceso en 0 ó 1:
if (allPassed == true) {
  WScript.Echo("\nAll test cases passed");
  WScript.Quit(0);
}
else {
  WScript.Echo("\nOne or more cases failed");
  WScript.Quit(1);
}
Si tiene la intención de administrar la automatización personalizada de pruebas mediante VSTE para evaluadores, la automatización debe establecer un código de salida de 0 para indicar que el resultado general de la prueba es una aprobación, o bien un código de salida de 1 para indicar un error. Esto significa que si piensa integrar la automatización de pruebas existente con VSTS, es probable que tenga que modificar la automatización, ya que la automatización de pruebas raramente establece el valor del código de salida. El método exacto para establecer el código de salida varía ligeramente de un lenguaje a otro. Por ejemplo, en un programa compatible con el lenguaje .NET, puede usar la propiedad System.Environment.ExitCode y en un script de Windows PowerShell puede usar una instrucción de salida.
Llegado a este punto, puede ejecutar el script de automatización de pruebas de forma local, tal como se muestra en la figura 1. No obstante, también puede ejecutar la automatización personalizada de dentro de VSTE para evaluadores. Seleccione Archivo | Nuevo | Proyecto. El cuadro de diálogo Nuevo proyecto tiene un tipo Proyectos de prueba con un subtipo Documentos de prueba. Seleccione Documentos de prueba y aparecerá una plantilla de proyecto de prueba. A continuación, asigne un nombre al proyecto de prueba, como por ejemplo MyTestProject, y especifique una ubicación para el directorio raíz del proyecto.
Un proyecto de prueba puede incluir una o más pruebas. Cada prueba puede incluir uno o más casos de prueba individuales. De forma predeterminada, obtendrá un proyecto de prueba que contiene un documento de texto de ayuda general denominado AuthoringTests.txt y los esqueletos para dos pruebas: una prueba manual y una prueba unitaria. Puede eliminar estos tres archivos en la ventana Explorador de soluciones.
Ahora haga clic con el botón secundario del mouse en el nombre del proyecto de prueba y seleccione Agregar | Nueva prueba del menú contextual. En el cuadro de diálogo Agregar nueva prueba, seleccione la plantilla de prueba genérica, asígnele el nombre Simple.GenericTest y haga clic en Aceptar. VSTE para evaluadores dispone de plantillas integradas para pruebas de carga, pruebas unitarias y pruebas web. El tipo Prueba genérica es esencialmente un contenedor para la automatización personalizada de pruebas y cuenta con todos los elementos necesarios para habilitar la automatización personalizada de modo que pueda funcionar con VSTE para evaluadores. La captura de pantalla de la figura 4 muestra el proceso de establecer el contenedor de la automatización personalizada de pruebas como una prueba genérica.
Figura 4 Creación de una prueba genérica sencilla (Hacer clic en la imagen para ampliarla)
El primer campo especifica un programa de prueba existente para ejecutar. Este valor debe ser la ruta de acceso a un archivo .exe. (Si bien usé una ruta de acceso absoluta en este ejemplo, puede especificar adicionalmente la ruta de acceso del script como variable de entorno, una ruta de acceso relativa o una ruta de acceso de implementación.) En el caso de la automatización de pruebas basada en scripts, se trata del programa cscript.exe que suele almacenarse en el directorio C:\Windows\System32\. Si la automatización de pruebas es un archivo .exe, tal como un programa C#, especificaría la ruta de acceso completa a la automatización. El segundo campo especifica los argumentos de línea de comandos que se deberán transferir al archivo .exe especificado en el primer campo. En este ejemplo, el valor sería la ruta de acceso completa al script, como por ejemplo C:\VSTTIntegration\Scripts\testSimple.js. Éstos son los dos único campos que necesita especificar para ejecutar las pruebas sencillas basadas en scripts con almacenamiento interno del caso de prueba.
Hay varias maneras de ejecutar las pruebas desde VSTE para evaluadores. Una manera sencilla es mostrar todas las pruebas del proyecto al hacer clic en Prueba | Windows | Vista de pruebas. A continuación, seleccione la prueba que desea ejecutar, haga clic con el botón secundario del mouse en el nombre de la prueba y haga clic en Ejecutar selección. La captura de pantalla de la figura 5 muestra un ejemplo.
Figura 5 Ejecución de una prueba genérica (Hacer clic en la imagen para ampliarla)
La ventana Resultados de pruebas muestra el resultado general de aprobación/error. Si hace doble clic en el resultado, obtendrá los resultados detallados, incluyendo la duración de ejecución de la prueba, la hora de inicio y de finalización y una copia de los resultados de la consola. Un resultado de prueba se almacena de manera predeterminada en el equipo host como un archivo XML con una extensión de archivo .trx (XML del resultado de la prueba) en un subdirectorio TestResults. De forma predeterminada, estos nombres de archivo .trx llevan un sello con el nombre de usuario, el nombre de equipo y la fecha y hora para facilitar su organización. La estructura real de los archivos .trx es algo compleja pero fácil de interpretar. Por ejemplo, una parte pequeña del archivo .trx que genera este ejemplo de prueba genérica es:
   <errorInfo>
     <message type="System.String">
       The test failed with exit code 1.
     </message> 
     <stackTrace type="System.String" /> 
   </errorInfo>
El ejemplo que acabo de describir crea un contenedor de la automatización personalizada de pruebas que tiene datos de caso de prueba incrustados en el código de automatización. Si la automatización lee datos de caso de prueba de una fuente externa, puede que sea necesario modificar uno de los campos de prueba genérica. Supongamos que la automatización de pruebas tiene el aspecto siguiente:
   var fsi = new ActiveXObject(
     "Scripting.FileSystemObject");
   var fi = fsi.OpenTextFile(".\\testCases.txt");  

   while (!fi.AtEndOfStream)
   {
     line = fi.ReadLine();
     // parse test case data
     // call method under test
     // determine pass/fail
   }
Aquí el script usa una ruta de archivo relativa para leer los datos de caso de prueba de un archivo que se encuentra en el mismo directorio que el del script. Cuando se ejecute una prueba genérica ejecuta, copiará los archivos ejecutables en un directorio de trabajo, lo que significa que los datos de caso de prueba no se encontrarán. Una solución para este problema consiste en especificar una ruta de acceso codificada en el campo Directorio de trabajo al crear una prueba genérica. Un método algo más flexible consiste en establecer los valores de una o más variables de entorno tales como %TestDir%, %TestLocation% y %TestOutputDirectory% y, a continuación, usar dichas variables de entorno para controlar la ejecución de la prueba. Sin embargo, la opción más flexible consiste en declarar el script como un elemento de implementación en Visual Studio. De este modo, los datos de caso de prueba se copiarán en el directorio de salida de modo que se podrá hacer referencia a ellos a través de una ruta de acceso local y relativa.

Resultados de prueba ampliados
Ha visto cómo usar VSTE para evaluadores para administrar la automatización personalizada y sencilla de pruebas. También puede crear automatización de pruebas que guarda información adicional y resultados de prueba más detallados. La idea básica es codificar la automatización de pruebas para que guarde resultados intermediarios y detallados de la prueba como un sencillo archivo XML que se ajusta a un esquema SummaryResult.xsd especial. VSTE para evaluadores usa automáticamente el archivo de resultados XML sencillos emitido para crear el archivo de resultados .trx más complejo que Visual Studio Team System administrará. Este proceso de dos pasos es mucho más fácil que intentar escribir la automatización de pruebas que produce directamente un archivo .trx de resultados de la prueba. Es más fácil entender este proceso si lo miramos de atrás hacia delante. La lista de la figura 6 muestra un archivo XML de resultados de la prueba que se ajusta a SummaryResult.xsd y, por lo tanto, se puede convertir automáticamente a un archivo de resultados .trx.
<SummaryResult>
  <TestName>MyCOMLib Test Run</TestName> 
  <TestResult>Failed</TestResult>
  <DetailedResultsFile>
    C:\AdditionalResults\Details.txt
  </DetailedResultsFile> 
  <InnerTests>
    <InnerTest>
      <TestName>001</TestName> 
      <TestResult>Passed</TestResult> 
    </InnerTest>
    <InnerTest>
      <TestName>002</TestName> 
      <TestResult>Failed</TestResult> 
    </InnerTest>
  </InnerTests>
</SummaryResult> 

El archivo de figura 6 ha requerido los valores TestName y TestResult globales y un valor opcional DetailedResultsFile global. Entre los otros valores opcionales que se definen en el esquema SummaryResult xsd se incluye InnerTest para almacenar el nombre y los resultados de los casos de prueba que componen la prueba genérica global y los valores ErrorMessage.
El archivo de esquema SummaryResult.xsd se instala con VSTE para evaluadores y suele almacenarse en el directorio C:\Archivos de Programa\Microsoft Visual Studio 8\Xml\Schemas\. El esquema define los tipos de resultados de prueba más allá de simplemente aprobación o error. Los tipos de resultados definidos adicionales son Aborted, Error, Inconclusive, NotRunnable, NotExecuted, Discontinued, Warning, InProgress, Pending, PassedButRunAborted y Completed.
Exactamente cómo escribe la automatización personalizada de pruebas para emitir un archivo de resultados de caso de prueba XML ampliado e intermedio depende del lenguaje de programación que usa y la estructura de la lógica de automatización. Si desea usar la etiqueta InnerTest, el esquema SummaryResult xsd dicta que debe especificar el resultado general de la prueba antes de especificar el resultado de cada caso de prueba. Esto significa que no puede generar el archivo de resultados XML intermedio de manera estrictamente secuencial al procesar los datos de caso de prueba.
Hay muchos métodos que puede usar. La lista de la figura 7 muestra una manera de modificar el script de automatización de pruebas que se presenta en la figura 3 para emitir un archivo de resultados ampliados. La idea general es generar el archivo de resultados XML como una única cadena larga al capturar los resultados de cada caso de prueba a medida que se procesen y, a continuación, generar la cadena final después de conocer el resultado global de la prueba.
// testExtended.js

function main()
{
  WScript.Echo("\nBegin test run\n");
  var o = new ActiveXObject("MyCOMLib.MyMethods");

  var cases = new Array( "001:3*7*5:7",
                         "002:0*0*0:1",
                         "003:2*4*6:6" );
  var allPassed = true;
  var innerTestText = new Array(cases.length);

  for (var i = 0; i < cases.length; ++i)
  {
    var tokens = cases[i].split(":");
    var id = tokens[0];
    var inputs = tokens[1];
    var expected = tokens[2]; 

    var temp = inputs.split("*");
    var arg1 = temp[0];
    var arg2 = temp[1];
    var arg3 = temp[2];

    WScript.Echo("==============");
    WScript.Echo("Case ID = " + id);
    WScript.Echo("Inputs = " + arg1 + " " + arg2 + " " + arg3);
    var actual = o.TriMax(arg1,arg2,arg3);
    WScript.Echo("Expected = " + expected);
    WScript.Echo("Actual = " + actual);

    innerTestText[i] = "<TestName>" + id + "</TestName>";
    innerTestText[i] += "<TestResult>";  // inner test result

    if (actual == expected) {
      WScript.Echo("Pass");
      innerTestText[i] += "Passed";
    } 
    else {
      WScript.Echo("FAIL");
      innerTestText[i] += "Failed";
      allPassed = false;
    }

    innerTestText[i] += "</TestResult>";
  } // main loop

  WScript.Echo("==============");
  var extendedResults = "<SummaryResult>";
  extendedResults += "<TestName>MyCOMLib Test Run</TestName>";
  extendedResults += "<TestResult>";  // overall meta-result
  if (allPassed == true) {
    extendedResults += "Passed</TestResult>";
  }
  else {
    extendedResults += "Failed</TestResult>";
  }

  extendedResults += "<InnerTests>"; 

  for (var j = 0; j < innerTestText.length; ++j) {
    extendedResults += "<InnerTest>";
    extendedResults += innerTestText[j];
    extendedResults += "</InnerTest>";
  }

  extendedResults += "</InnerTests>";
  extendedResults += "</SummaryResult>";

  var fso = new ActiveXObject("Scripting.FileSystemObject");
  var f = fso.CreateTextFile("C:\\VSTTIntegration\\Scripts\\results.xml");
  f.WriteLine(extendedResults);
  f.Close();
} // main()

main()

Creo una matriz de cadenas, una cadena para cada caso de prueba, para que contenga los valores InnerTest:
var innerTestText = new Array(cases.length);
Dentro del bucle procesamiento principal, escribo el valor TestName y el inicio del valor TestResult:
innerTestText[i] = "<TestName>" + id + "</TestName>";
innerTestText[i] += "<TestResult>"; // inner test result
Después de procesar un caso de prueba individual, puedo proporcionar un valor de resultado de la prueba y agregar la etiqueta final TestResult:
if (actual == expected) {
  WScript.Echo("Pass");
  innerTestText[i] += "Passed";
} 
else {
  WScript.Echo("FAIL");
  innerTestText[i] += "Failed";
  allPassed = false;
}
innerTestText[i] += "</TestResult>";
Una vez que se haya finalizado el bucle de procesamiento y se hayan generado todos los datos InnerTest, puedo crear la primera parte del archivo de resultados ampliados:
var extendedResults = "<SummaryResult>";
extendedResults += "<TestName>MyCOMLib Test Run</TestName>";
extendedResults += "<TestResult>";  // overall meta-result
if (allPassed == true) {
  extendedResults += "Passed</TestResult>";
}
else {
  extendedResults += "Failed</TestResult>";
}
Termino por agregar los datos InnerTest que guardé anteriormente y escribir toda la cadena como un archivo XML:
extendedResults += "<InnerTests>"; 
for (var j = 0; j < innerTestText.length; ++j) {
  extendedResults += "<InnerTest>";
  extendedResults += innerTestText[j];
  extendedResults += "</InnerTest>";
}

extendedResults += "</InnerTests>";
extendedResults += "</SummaryResult>";

var fso = new ActiveXObject("Scripting.FileSystemObject");
var f = fso.CreateTextFile("C:\\VSTTIntegration\\Scripts\\results.xml");
f.WriteLine(extendedResults);
Hay muchos otros métodos que puede usar para emitir resultados XML. En mi columna "Cinco maneras de emitir resultados de prueba como XML" en el número de junio de 2006 de MSDN® Magazine (msdn.microsoft.com/msdnmag/issues/06/06/TestRun) se describen algunas de estas técnicas.
Llegado a este punto, tengo un script de automatización personalizada de pruebas que escribe resultados de prueba detallados en un archivo results.xml que se ajusta al esquema SummaryResult.xsd. Para usar esta automatización en VSTE para evaluadores, creo una nueva prueba genérica alrededor de la automatización mediante la técnica que describí anteriormente, pero con un cambio. Después de seleccionar Agregar | Nueva prueba y asignar un nombre a la prueba (digamos Extended.GenricTest) en el panel de definición, activo la casilla Resumir archivo de resultados y especifico la ubicación del archivo de resultados en el cuadro de texto asociado (digamos, C:\VSTTIntegration\Scripts\Results\results.xml). Ahora, cuando ejecuto la prueba genérica, VSTE para evaluadores ejecutará la automatización, buscará el archivo intermedio results.xml y usará automáticamente los datos encontrados para crear archivo de resultados .trx final con el sello de nombre, fecha y hora. ¡Qué bien!

Publicación de resultados de la prueba en Team Foundation Server
Crear un contenedor para la automatización personalizada de pruebas como una prueba genérica mediante VSTE para evaluadores ofrece una excelente manera de administrar las pruebas y los resultados correspondientes. Si usa Team Foundation Server en el entorno de desarrollo, puede publicar los resultados de prueba en el almacén de datos de TFS con el fin de lograr una mejor administración de los resultados de prueba.
El almacén de datos back-end de TFS es muy complejo, por lo que no es aconsejable intentar guardar los resultados de la prueba .trx directamente en las tablas subyacentes de SQL. Sin embargo, puede guardar los datos de resultado de prueba en TFS mediante VSTE para evaluadores. El proceso es muy sencillo. Después de ejecutar una prueba genérica, conéctese al proyecto TFS. Para ello, seleccione Herramientas | Conectar con servidor Team Foundation Server del menú principal. En el menú de la ventana Resultados de pruebas, haga clic en el icono Publicar. Aparecerá un cuadro de diálogo de publicación de resultados de la prueba similar al que se muestra en la figura 8.
Figura 8 Publicación de resultados de la prueba en Team Foundation Server (Hacer clic en la imagen para ampliarla)
Puede seleccionar uno o más resultados de prueba cargados y, a continuación, elegir la compilación adecuada del sistema bajo prueba de un control desplegable. Tenga en cuenta que el archivo de resultados de prueba debe encontrarse en el directorio de salida de pruebas para que pueda estar disponible para su publicación en el almacén de datos. Tras hacer clic en Aceptar, los resultados de prueba se publicarán en el almacén de datos de TFS. Este método permite a cualquier miembro del equipo de desarrollo ver fácilmente los resultados de prueba.
Una manera de ver los resultados en VSTE para evaluadores es conectarse al proyecto TFS y ampliar la carpeta de compilaciones de la ventana de Team Explorer. Si hace doble clic en el tipo de compilación apropiado, verá una lista de todas las compilaciones específicas de ese tipo. Si hace doble clic en una entrada de compilación en particular, verá los datos asociados con esa compilación, incluidos los resultados de prueba publicados. Aún mejor, puesto que los datos del informe de errores de TFS se pueden asociar a resultados de prueba publicados, podrá ver informes integrados, tal como Ejecución de prueba fallada sin errores activos, o bien podrá crear informes personalizados que usen estos datos.
Observe que para publicar los resultados de prueba en Team Foundation Server, deberá asociarlos a una compilación en particular del sistema bajo prueba. Esto significa que debe tener establecido un sistema de compilaciones de TFS. Pero ¿qué sucede si realiza pruebas de retroceso en un componente heredado que ya no se compila de manera activa, o incluso un componente para el que ya no existe código fuente? Una solución sencilla es crear un proyecto falso, realizar una única compilación de ese proyecto y, a continuación, usar ese número de compilación como marcador que funcionará como objetivo de los resultados de prueba. Para obtener más información al respecto, consulte la columna de Team System escrita por Brian Randell, "Control de versiones de Team Foundation Server", en el número de enero de 2007 de MSDN Magazine (msdn.microsoft.com/msdnmag/issues/07/01/TeamSystem).

Conclusión
Visual Studio 2005 Team Edition para evaluadores tiene la capacidad de crear una amplia gama de tipos de prueba integrados, tales como pruebas unitarias y pruebas de carga. Estos tipos de prueba muy conocidos están estrechamente integrados en el proceso de desarrollo y suelen asociarse con el desarrollo impulsado por pruebas. Sin embargo, hay muchas situaciones posibles de desarrollo en las que existe una automatización de pruebas heredada o se desea crear una automatización personalizada de pruebas. Por ejemplo, es posible que subcontrate el esfuerzo de pruebas y que, por motivos de seguridad, no desea que el equipo de prueba tenga acceso directo al código fuente del sistema. VSTE para evaluadores permite ajustar cualquier clase de automatización personalizada de pruebas en un tipo de prueba genérica. Además de ofrecer una estructura de administración centralizada para la automatización personalizada de pruebas, obtiene automáticamente datos de resultados adicionales, como por ejemplo, la hora de inicio y finalización y la duración de cada ejecución de prueba, así como un registro de los resultados de la consola.
Los resultados de la prueba genérico se almacenan como archivos .trx en el equipo host local, y en pueden funcionar fácilmente con otros sistemas de prueba si fuera necesario, ya que se almacenan en un formato XML estándar. Aunque pueda configurar la automatización personalizada de pruebas para registrar un resultado sencillo de aprobación o error, VSTE para evaluadores también permite registrar resultados ampliados, incluyendo los tipos de resultado tales como Inconclusive y Aborted. Para ello, modifica la automatización personalizada de pruebas para producir un archivo de resultados XML intermedio que se ajusta al esquema SummaryResult.xsd. VSTE para evaluadores usa automáticamente el archivo XML intermedio para producir un archivo .trx detallado.
En las situaciones de desarrollo en las que se usa Team Foundation Server para administrar el código fuente, documentos de especificaciones, datos de error y procesos de compilación, puede publicar los resultados de prueba en el almacén de datos de TFS. La publicación de los resultados de prueba en TFS permite la visualización de éstos por todos los otros miembros del equipo de desarrollo y determina fácilmente las relaciones entre errores, compilaciones y resultados de prueba.
Visual Studio 2008 acaba de lanzarse y, según lo que he visto hasta ahora, contará con toda la capacidad existente para administrar la automatización personalizada de pruebas, más una funcionalidad de administración de pruebas adicional que ayudará a crear mejores sistemas de software.
Quiero agradecer a Howard Dierking por haber sugerido el tema de esta columna y al experto de Team System, Brian Randell, por haberla revisado.

Envíe sus preguntas y comentarios para James a testrun@microsoft.com.


Dr. James McCaffrey trabaja en Volt Information Sciences, Inc., donde se encarga de los programas de aprendizaje técnicos dirigidos a los ingenieros de software en el campus de Microsoft en Redmond. Ha colaborado en el desarrollo de varios productos de Microsoft como, por ejemplo, Internet Explorer y MSN Search. James es autor de .NET Test Automation Recipes (Apress, 2006) y puede ponerse en contacto con él en jmccaffrey@volt.com o v-jammc@microsoft.com.

Page view tracker