1C: Prueba de escenario. Herramientas de prueba para aquellos que se arrepienten de perder el tiempo con una rutina.


El artículo considera un nuevo mecanismo de prueba automatizado, que apareció por primera vez en la plataforma en la versión 8.3. Después de estudiar el material del artículo, aprenderá:

  • ¿Qué son las pruebas automatizadas en la plataforma?
  • ¿Cómo y cuándo usarlo?
  • ¿Qué y dónde se debe configurar para ejecutarlo?
  • ¿Cómo escribir un script de prueba automatizado?

Aplicabilidad

El artículo analiza la versión 8.3.4.465 de la plataforma 1C:Enterprise. En la versión actual de la plataforma, las capacidades del mecanismo de prueba automática se expandieron significativamente, pero esto no afectó la relevancia del material del artículo. Todavía es relevante.

Pruebas automatizadas en 1C:Enterprise 8.3

La plataforma 1C:Enterprise 8.3 tiene un nuevo mecanismo diseñado para simular las acciones interactivas de los usuarios del sistema: pruebas automatizadas.

Las pruebas automatizadas no admiten trabajar con una interfaz normal, sino solo con una administrada.

Al realizar pruebas, se utilizan dos tipos de aplicaciones cliente: el administrador de pruebas y el cliente de prueba. El administrador de pruebas establece una conexión con el cliente de prueba y ejecuta el script de prueba.

Un script de prueba es un código en un lenguaje integrado que describe una secuencia de acciones interactivas que se van a realizar.

Para hacer esto, se han agregado nuevos objetos al lenguaje incorporado que describen la interfaz de la aplicación en un nivel abstracto (en términos de una ventana, formulario, controles, etc.), y también describen las acciones del usuario (navegación de configuración, entrada de datos , etc).

El administrador de pruebas puede ser un cliente grueso o ligero. Cliente de prueba: cliente pesado, cliente ligero o cliente web.

Un administrador de pruebas se puede conectar a varios clientes de prueba y un cliente de prueba solo se puede conectar a un administrador.

Para administrar el cliente, el administrador establece una conexión TCP con él. Es importante que las pruebas automatizadas no requieran cambios en la estructura de configuración.

En esencia, el cliente de prueba y el administrador son configuraciones que se ejecutan con ciertas opciones de línea de comandos, y el administrador administra los clientes al "hacer" que las ventanas y los controles se comporten como si el usuario estuviera interactuando con ellos.

Las pruebas automatizadas tienen sus limitaciones. Entonces, por ejemplo, no se admite el trabajo con la interfaz habitual, sino solo con la administrada.

Para realizar pruebas automatizadas, tanto el administrador de pruebas como el cliente de prueba deben estar ejecutándose.

El administrador se puede iniciar desde la línea de comandos con la tecla /TESTMANAGER:

“c:\Archivos de programa (x86)\1cv8\8.3.4.437\bin\1cv8c.exe” ENTERPRISE /F “X:\test” /N Administrador /TESTMANAGER

Además, el administrador de pruebas se puede iniciar desde el configurador.

Para hacer esto, a través del menú Herramientas - Opciones, abra el cuadro de diálogo "Opciones", en el que en la pestaña Iniciar 1C: Empresa - Avanzado, marque el elemento "Ejecutar como administrador de pruebas":

Otra forma de iniciar el administrador de pruebas es desde el lenguaje incorporado, utilizando el método StartSystem(), en el que debe especificar la línea de comando:

StartSystem("c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe" ENTERPRISE /F X:\test /N Administrador /TESTMANAGER")

El cliente de prueba también se puede iniciar desde la línea de comandos. Para hacer esto, use el modificador de línea de comandos /TESTCLIENT.

El parámetro TPort especifica el número de puerto a través del cual interactuarán el administrador y el cliente de prueba. Si no se especifica esta opción en la línea de comandos, se utilizará el puerto 1538.

“c:\Archivos de programa (x86)\1cv8\8.3.4.437\bin\1cv8c.exe” ENTERPRISE /F “X:\Platform8Demo” /N Administrador /TESTCLIENT -TPort 1539

El cliente de prueba se puede iniciar desde el configurador. Para hacer esto, a través del menú Herramientas - Opciones, abra el cuadro de diálogo "Opciones", en el que en la pestaña Iniciar 1C: Enterprise - Avanzado, marque el elemento "Ejecutar como cliente de prueba". En este caso, deberá especificar el número de puerto utilizado.

Tenga en cuenta que para conectarse al cliente de prueba, necesita conocer dos parámetros: la dirección IP (o nombre) de la computadora que ejecuta el cliente de prueba y el número de puerto TCP a través del cual se realizará la interacción.

Ambas bases de datos diferentes se pueden usar como administrador y cliente de prueba (la configuración de la base de datos del administrador de prueba puede no coincidir con la configuración del cliente de prueba) o la misma base de información.

Para realizar pruebas automatizadas, debe realizar los siguientes pasos:

  1. Desarrolle un script de prueba: escriba un procesamiento externo o incorporado en la configuración, que describirá secuencialmente los pasos a realizar.
  2. Inicie el administrador de pruebas.
  3. Inicie un cliente de prueba (uno o más).
  4. En el administrador de pruebas, inicie el procesamiento creado para su ejecución, asegúrese de que las acciones programadas se realicen en el cliente.

La aplicación bajo prueba se describe mediante un conjunto de objetos de lenguaje 1C:Enterprise que se utilizan para escribir el script:

  • Aplicación Probada;
  • Aplicación de cliente de ventana probada;
  • TestedCommandInterfaceWindow;
  • TestedCommandInterfaceGroup;
  • TestedButtonCommandInterface;
  • FormaProbada;
  • Campo de formulario probado;
  • GrupoFormaProbada;
  • BotónFormularioProbado;
  • TablaFormaProbada;
  • TestedDecorationForm.

Como configuración de prueba, utilizaremos la configuración de demostración de "Aplicación administrada".

Vamos a crear un procesamiento externo, agregar un nuevo formulario, en el que definiremos un controlador para el nuevo comando "Ejecutar prueba".

En la prueba, realizamos las siguientes acciones: crea un nuevo elemento del directorio "Almacenes", en el campo Nombre ingresa la línea "Prueba de almacén", luego haz clic en el botón "Guardar y cerrar".

El código para esta prueba se verá así:

&EnCliente
Procedimiento EjecutarPruebas(Equipo )
// Conéctese a la aplicación bajo prueba
Aplicación Probada= Nuevo Aplicación Probada("host local");
// Tratando de conectarse por no más de un minuto
Hora De Finalización= FechaActual() + 60 ;
Conectado = Falso;
Mientras no sea la fecha actual() >= Hora De Finalización Intento de ciclo
TestedApplication.SetConnection();
Conectado = verdadero;
abortar;
Excepción
EndTry; FinCiclo ; Si no está conectado, entonces
// Terminar la prueba
Aplicación Probada= indefinido;
Para reportar ( "¡No puede conectarse!");
Devolver ;
Terminara si ;
// Encuentra la ventana principal
MainWindowProbado
=(Tipo());
MainWindowTested.Activar();
// Ejecuta el comando para crear un elemento del directorio del producto
Ventana principal de Tested.RunCommand(“e1cib/comando/Catálogo.Almacenes.Crear”);
TestedApplication.ExpectObjectDisplay(Tipo ( “Forma Probada”), "Existencias*" );
TestedForm= Aplicación Probada.FindObject(Tipo ( “Forma Probada”),
"Existencias*" );
TestedForm.Activar();
// Establecer el nombre para el nuevo producto
elemento de formulario = TestedForm.FindObject(Tipo ( "Campo de formulario probado"),
"Nombre");
FormElement.Activar();
FormElement.EnterText(“Prueba de almacén”);
// Escribir elemento
elemento de formulario = TestedForm.FindObject(Tipo ( "Botón de formulario probado"),
“Grabar y Cerrar”);
FormElement.Prensa();
Procedimiento final

En el cuadro de diálogo de opciones de inicio, se seleccionó primero el valor "Ejecutar como administrador de pruebas", utilizando la combinación de teclas Ctrl + F5, se inició una sesión de usuario.

Luego, en el cuadro de diálogo, se seleccionó el valor "Ejecutar como cliente de prueba", utilizando la combinación de teclas Ctrl + F5, se inició la segunda sesión de usuario.

Por lo tanto, evitamos la necesidad de especificar manualmente las opciones de línea de comando requeridas.

El código anterior realiza acciones bastante simples, pero si el escenario se vuelve más complejo, la cantidad de código aumentará, ya que es necesario describir cada acción interactiva del usuario.

Aquí viene al rescate otra característica nueva de la plataforma: registrar un registro de las acciones del usuario.

Para hacer esto, debe ejecutar la aplicación en un modo especial:

Haga clic en la imagen para ampliar.

Aparecen varios botones en el encabezado del programa:

Los botones son para:

  • iniciar/detener la grabación;
  • para de grabar;
  • finalización de la grabación.

Una vez completada la grabación, se abre un documento de texto en la pantalla, que es una secuencia de acciones del usuario guardadas en un archivo XML.

Haga clic en la imagen para ampliar.

El registro grabado se puede convertir en código de programa, que luego se puede usar en un script de prueba.

Para ello se pretende el procesamiento de “User Action Log Conversion” (UILogToScript.epf), que se puede obtener del sitio web de ITS.

Haga clic en la imagen para ampliar.

Como resultado del procesamiento, obtenemos el código generado en el lenguaje incorporado. Este código debe pegarse en el módulo de formulario de procesamiento de prueba.

Tenga en cuenta que en el código generado, los números mayores que 999 o menores que -999 se generarán utilizando un espacio de no separación como separador de grupo (por ejemplo, "1234" en lugar de "1234").

Este símbolo debe eliminarse del código recibido manualmente.

La sección de código con la conexión al cliente fue generada automáticamente por procesamiento.

En nuestro ejemplo, obtenemos el siguiente código:

&EnCliente
Procedimiento EjecutarPruebas(Equipo )
Escenario de prueba_23_03_2014();
EndProcedure &AtClient
Procedimiento Escenario de prueba_23_03_2014() Aplicación de prueba= Nuevo Aplicación Probada();
Hora De Finalización= FechaActual() + 60 ;
Conectado = Falso;
DescripciónErroresConexiones= “” ;
Mientras no sea la fecha actual() >= Hora De Finalización Ciclo
Intentar
TestApplication.SetConnection();
Conectado = verdadero;
abortar;
Excepción
DescripciónErroresConexiones= DescripciónErrores();
EndTry;
FinCiclo ;
Si no está conectado, entonces
Aplicación de prueba= indefinido;
Informe (+ Símbolos. PD + DescripciónErroresConexiones);
Devolver ;
Terminara si ; ( Aplicación de prueba);
(Aplicación de prueba); EndProcedure &AtClient
Procedimiento VentanaAplicaciónCuentasCrearBotónClic(Aplicación de prueba)
VentanaAplicaciónContratistas= (Tipo (
"Prueba de la ventana de aplicación del cliente"), “Contrapartes” , , 30 );
VentanaAplicaciónCuentasFormularioCuentas= WindowApplicationAccounts.FindObject(Tipo (
“Forma Probada”), “Contratistas” );
BotónCrear = WindowApplicationAccountsFormAccounts.FindObject(Tipo (
"Botón de formulario probado"), "Crear" );
BotónCrear.Presionar(); EndProcedure &AtClient
Procedimiento VentanaAplicaciónCuentaCrearBotónGuardarYCerrarPresionar(Aplicación de prueba) VentanaAplicaciónContratistaCreación= TestApplication.FindObject(Tipo (
"Prueba de la ventana de aplicación del cliente"), "Creación de cuenta)", , 30 );
VentanaAplicaciónCreación de cuentaFormaCreación de cuenta=
WindowApplicationAccountCreate.FindObject(Tipo ( “Forma Probada”),
"Creación de cuenta)");
Nombre del campo=
(Tipo (
"Campo de formulario probado"), "Nombre");
FieldName.EnterText("Nuevo" ); PrecioTipoCampo = WindowApplicationAccountCreationFormAccountCreation.FindObject(Tipo (
"Campo de formulario probado"), “Tipo de precio” );
FieldPriceType.Activar(); FieldTypePrice.Select(); FieldViewPrice.WaitFormationDropdownList(); FieldPriceType.PerformSelectionFromSelectionList("Adquisitivo"); Botón Guardar y Cerrar=
WindowApplicationAccountCreationFormAccountCreation.FindObject(Tipo (
"Botón de formulario probado"), “Grabar y Cerrar”);
BotónGuardar y cerrar.Presione(); Procedimiento final

En el escenario resultante, se establece una conexión con el cliente de prueba, se presiona el botón para crear un nuevo elemento del directorio "Contratistas", en el campo Nombre se ingresa el texto “Nuevo”, y en el desplegable “Tipo de precio”, se selecciona el valor “Comprar”, luego se presiona el botón “Guardar y cerrar”.

Si necesita usar varios clientes de prueba en un escenario, la conexión a cada uno de ellos y las acciones realizadas deben describirse por separado.

El administrador de pruebas se usará solo y dos clientes están conectados a él en diferentes puertos.

Dado que se está procesando el script de prueba, cuyas líneas del código del programa se ejecutan secuencialmente, el desarrollador debe describir la secuencia de acciones para cada cliente.

Echemos un vistazo más de cerca a cómo se verá el código al usar dos clientes de prueba:

Procedimiento Escenario de prueba_23_03_2014_Dos clientes() //primer cliente
Aplicación de prueba1= Nuevo Aplicación Probada();
Hora De Finalización= FechaActual() + 60 ;
Conectado = Falso;
DescripciónErroresConexiones= “” ;
Mientras no sea la fecha actual() >= Hora De Finalización Ciclo
Intentar
TestApplication1.SetConnection();
Conectado = verdadero;
abortar;
Excepción
DescripciónErroresConexiones= DescripciónErrores();
EndTry;
FinCiclo ; //segundo cliente
TestApp2= Nuevo Aplicación Probada();
Hora De Finalización= FechaActual() + 60 ;
DescripciónErroresConexiones= “” ;
Mientras no sea la fecha actual() >= Hora De Finalización Ciclo
Intentar
TestApplication2.SetConnection();
Conectado = verdadero;
abortar;
Excepción
DescripciónErroresConexiones= DescripciónErrores();
EndTry;
FinCiclo ;
Si no está conectado, entonces
Aplicación de prueba1= indefinido;
TestApp2= indefinido;
Para reportar ( "¡No podía conectar!"+ Símbolos.PS + DescripciónErroresConexiones);
Devolver ;
Terminara si ; //los procedimientos son independientes para cada cliente de prueba
VentanaAplicaciónCuentasCrearBotónPresionar1(Aplicación de prueba1);
VentanaAplicaciónCuentasBotónCrearClick2(TestApp2);
VentanaAplicaciónCuentaCrearBotónGuardar y cerrarPresionar1(Aplicación de prueba1);
VentanaAplicaciónCuentaCrearBotónGuardar y cerrarPresionar2(TestApp2); Procedimiento final

Las pausas entre las acciones realizadas también deben programarse por separado. El guión de un gran número de clientes se vuelve difícil de leer.

Además, las pruebas automatizadas solo están disponibles para formularios administrados.

Sin embargo, la ventaja de las pruebas automatizadas es la simplicidad y visibilidad del desarrollo de pruebas. Dado que la prueba opera solo en acciones interactivas del usuario, el desarrollador no necesita conocer las estructuras de configuración en el nivel de atributo del objeto.

Si cambia, por ejemplo, el código de configuración, no es necesario volver a realizar la prueba, ya que el cliente de prueba seguirá realizando las mismas acciones con los mismos controles.

Los evaluadores pueden utilizar el mecanismo de prueba automatizado para registrar la secuencia de acciones que conducen a un error. Los datos registrados se pueden enviar a los desarrolladores para corregir el error detectado.

Las pruebas automatizadas también se pueden usar para identificar bloqueos redundantes e interbloqueos en una configuración.

Para hacer esto, debe implementar un script que reproduzca el problema y comenzar a encontrar y solucionar la causa.

Muchos especialistas y solo usuarios de productos basados ​​en 1C Enterprise 8 ya deberían haber oído hablar del lanzamiento de un nuevo producto de software para probar cualquier configuración (según declaraciones oficiales), y su nombre es 1C Scenario Testing 8. Lo aclararé de inmediato. esta herramienta es desarrollada directamente por la empresa 1C, y no por activistas de terceros. No pude encontrar información sobre este producto (aparte de las interminables reimpresiones del sitio web de 1C), de lo que puedo concluir que simplemente no existe. Y el producto de revisión en sí no es fácil de encontrar, al menos para aquellos que no quieren pagar 30k por una licencia o aún no la tienen, junto con el suministro de KIP8. De una forma u otra, pero después de algunas pruebas, aún logré tener esta herramienta en mis manos. Y de ahora en adelante, comenzaré con más detalle.

Instalación.

Por el momento, conozco las siguientes formas oficiales de obtener esta herramienta:

a) Está incluido en la entrega "1C: Paquete de herramientas corporativas 8".

b) Se puede descargar desde el sitio web de soporte al usuario de 1C.

c) Una versión anterior estaba presente en el disco ITS, creo que para octubre.

La aplicación en sí pesa alrededor de 2 MB, pero es demasiado pronto para alegrarse: para instalarla, debe especificar la ruta a la carpeta con las plantillas. Según tengo entendido, este directorio está en las configuraciones básicas, o en la de prueba, que se adjunta al programa. Debe instalarse en primer lugar (~ 90Mb), luego instalaremos la utilidad de manera segura y eliminaremos la configuración más innecesaria.

Tras estas sencillas manipulaciones, obtendremos un catálogo con la herramienta que nos interesa. El programa en sí consta de dos procesamientos externos *.epf, además se adjunta una breve descripción y una prueba de demostración para la configuración ejemplar que hemos eliminado.

Permítanme aclarar con qué tenía que trabajar. Obtuve la versión 1.2.2.1, obviamente no la principal. Como configuración de prueba, utilicé una configuración basada en 1C Enterprise 8.1.

Interrogación.

Entonces, como ya mencioné, 1C Scenario Testing consta de dos procesos externos: Recording Tests y Running Tests.

La mayor parte de la información se puede encontrar en la ayuda integrada. Sin embargo, no tendría muchas esperanzas en él, está escrito según el principio de "masticar lo obvio y nada más". Pero, sin embargo, puedes leer para el desarrollo general.

Para empezar, describiré con mis propias palabras la funcionalidad principal de esta herramienta y luego intentaré profundizar en la implementación de funciones individuales.

Usando 1C Scenario Testing, puede crear fácilmente documentos, directorios, registros automáticamente de acuerdo con un guión preescrito, compararlos con objetos de referencia, etc., tanto en modo visual como oculto a los ojos del evaluador. En la primera captura de pantalla se puede ver un ejemplo de un escenario típico.

Cada elemento del script se denomina paso. En general, todo es obvio y simple a primera vista y, por desgracia, hasta cierto punto engañoso. Sin embargo, hablaremos de las trampas en la siguiente sección, pero por ahora centrémonos en las características básicas.

Arroz. 1 Manejo de pruebas de escritura.

La ideología de esta herramienta se basa en comparar los objetos de la base de referencia con los objetos de la base bajo prueba. Esto se ve claramente en la ventana principal para procesar los Registros de Prueba, en el lado izquierdo hay datos de la base de datos de referencia, en el lado derecho hay pruebas basadas en datos del lado izquierdo. La base de datos de referencia es la base de datos en la que se creó la prueba.

Además de la función principal de la herramienta descrita anteriormente, hay una serie de otras, más primitivas, pero a veces no menos útiles. Por ejemplo, la herramienta solo se puede usar para autocompletar formularios, hacer clic en botones, completar secciones tabulares, etc. Estos pasos simulan el trabajo del usuario en modo interactivo. Y dado que el probador desempeña el papel del usuario, resulta una especie de prueba ad hoc en modo automático.

Hay un patrón de pasos típicos creados automáticamente dependiendo del objeto bajo prueba. Aquí hay un ejemplo típico: en el lado izquierdo, seleccione un documento específico (libro de referencia, etc.) y arrástrelo hacia el lado derecho, después de lo cual se crea automáticamente una plantilla de pasos típicos para nosotros. Después de eso, puede editarlos como desee.

Cada paso se puede ejecutar directamente en este procesamiento presionando F12. Esta funcionalidad pone en duda la necesidad de un segundo procesamiento de RunTests, creo que sería lógico combinarlos en el futuro.

Arroz. 2 Ejecución de prueba de manejo.

La prueba finalizada se escribe en un documento xml, que abrimos en la base de datos bajo prueba a través del procesamiento de la ejecución de la prueba y observamos cómo todo está bien con nosotros.

La funcionalidad del segundo procesamiento no es diferente, dado que la ejecución se puede realizar con el primer procesamiento. De las características útiles, se puede señalar el mantenimiento del protocolo de ejecución y el marcado de los pasos tomados.

De cara al futuro, para no volver a este procesamiento, diré que me golpeó en el acto. Con toda la variedad de opciones necesarias y no muy, no había lugar para un modo de ejecución de prueba ignorando errores. Lo que hace que sea extremadamente desagradable realizar pruebas negativas y pruebas en general. A la menor incoherencia, nuestro procesamiento "automático" cae en un estado de estupor.

Ahora considere los pros y los contras de usar este sistema en el campo.

Características de uso.

Según declaraciones oficiales, 1C Scenario Testing debería ser una herramienta universal en términos de compatibilidad con varias configuraciones. Creo que mi configuración es un excelente banco de pruebas para esta afirmación.

Diré de inmediato que el proceso de trabajar con esta herramienta no puede llamarse simple y tranquilo. En casi cada paso (en todos los sentidos) tienes que experimentar con cosas aparentemente obvias.

Esto es algo con lo que tuve que lidiar:

  1. Por alguna razón, con toda la variedad de opciones para los pasos de prueba, no hay ningún paso para eliminar el objeto procesado. Al principio, tuve que usar el paso "Procesar" y escribir código manualmente para eliminar objetos. Al final, decidí prescindir de él por ahora y trabajar con los datos existentes.
  2. Uno de los más útiles, en mi opinión, es el paso "Comparación de movimiento con el estándar". Esto es lo que faltaba. Ahora es posible realizar un seguimiento de todos los cambios en las transacciones que no fueron planificadas.
    Este paso necesita un ajuste muy fino. Por ejemplo, necesitamos rastrear el movimiento de un documento a través de cuatro registros, y cada uno de ellos tiene su propio conjunto de campos y análisis. Hay valores que cambiarán cuando cambie el objeto, y esto no será un error. Por ejemplo, un campo como TimeStamp, que registra la hora del documento, o el número de documento, si se asigna automáticamente. Todos estos momentos provocarán un error al ejecutar la prueba. Es bueno que los desarrolladores hayan proporcionado esto y hayan hecho posible deshabilitar la verificación de un campo no constante. Sólo tenemos que encontrar esos campos.
    Sin embargo, incluso aquí no estuvo exento de trampas. Por ejemplo, por alguna razón, en mi formulario de configuración de pasos, si se muestra más de un registro, entonces no se muestran los movimientos en ellos, tengo que desactivar los adicionales y configurar cada registro individualmente.
    Y lo que no me gustó nada. Como logré entender, solo los movimientos que están en el estándar son verificados por registros. Por ejemplo, si hay un cableado en el estándar y tres en la base de datos probada, NO habrá errores al comparar. Porque en todo el registro se busca una transacción con los parámetros de la referencia, si todo está bien, entonces no se rastrea la presencia en el registro del resto relacionado con el mismo objeto.
  3. Los pasos de finalización automática basados ​​en secuencias de comandos no siempre funcionan correctamente. A menudo se producen errores en los campos de referencia y las fechas. Es más probable que esto no sea un error de la herramienta, sino una característica de los campos, pero, sin embargo, tendrá que modificar su configuración.
  4. Los posibles pasos están asociados con objetos de configuración específicos. Lo que está disponible para directorios puede no estar disponible para registros, etc. Sería más exacto decir que la vinculación no es a los objetos, sino a sus características, por ejemplo, si el registro no tiene un formulario, entonces no habrá ningún paso para completarlo.
    Pero también hay errores, por ejemplo, el paso "Presione el botón" a menudo no está disponible para mí, o más bien, se puede hacer la elección en sí, pero no sucederá nada.
  5. Quedan solo muchas preguntas sobre la automatización de pruebas en algunos casos particularmente confusos. Esto es especialmente cierto para los documentos que trabajan con residuos, donde casi todos los momentos juegan un papel importante, algunos de los cuales son muy problemáticos de superar en la implementación actual de la herramienta. Hay una serie de restricciones en la configuración para crear documentos en la misma fecha, con el mismo número, etc. hasta ahora me he decidido por usar objetos existentes sin crear otros nuevos.

Esta lista puede seguir y seguir, pero deje que los probadores de este producto lo hagan. Lo principal que entendí y estoy tratando de transmitir es que "no habrá regalos". Para implementar la automatización de pruebas con este producto como protagonista, tendrá que sudar más de un día. Por supuesto, mi análisis es puramente subjetivo, y la falta de experiencia en el uso del producto y las funciones de configuración también pueden afectar, pero, como dicen, tenemos lo que tenemos y no hay escapatoria.

Opciones de aplicación.

Por mi parte, por el momento he elegido el siguiente concepto para introducir la herramienta en cuestión en el proceso de prueba.

Basado en la experiencia operativa actual, estoy convencido de que la base de referencia y la base de prueba deben ser idénticas en términos de datos. Naturalmente, si estamos hablando de scripts que usan objetos existentes sin cambiarlos y no crean otros nuevos. En primer lugar, esto nos dará los mismos saldos en ambas bases, y esto es muy importante para probar pérdidas de balón. En segundo lugar, brindará cierta confiabilidad y cierta protección contra errores innecesarios, porque. Todavía no entendía del todo la conexión entre los datos de referencia y las bases de datos, varios enlaces, etc., me atormentan vagas sospechas de que puede haber algún tipo de enlaces que en un buen momento se convertirán en una maraña de enlaces muertos que no puedes desentrañar.

Entonces, tenemos una base de referencia, según la cual nos hicimos escenarios para todas las ocasiones. Hay correcciones en un documento de configuración de desarrollo que deben probarse. Como regla general, manualmente. Después de eso, la configuración con los cambios se carga en la base de prueba y los scripts se ejecutan para todos o solo los objetos adyacentes para averiguar si el cambio en el documento tuvo un impacto en otros objetos. Después de eso, la configuración se considera viable y se instala en la base de datos de trabajo. Después de eso, la secuencia de comandos para probar el documento modificado se cambia a un nuevo estándar de la base de datos de trabajo.

En otras palabras, estamos haciendo pruebas de regresión con estos escenarios. Y este es uno de los tipos de prueba más importantes y difíciles de implementar manualmente en 1C Enterprise. Después de todo, muy a menudo no solo cambia el documento, sino, digamos, la función de publicar un documento, que está asociado con todos los documentos del sistema, aquí es donde nuestros scripts desempeñarán el papel de una red en la que todos los documentos que fallará caerá.

Otro buen uso sería verificar la base de trabajo en busca de errores aleatorios. Para hacer esto, se toma una copia de seguridad, se carga en alguna base de datos de prueba y se ejecuta un ciclo completo de pruebas. Sería bueno realizar este procedimiento en modo automático, pero 1C Scenario Testing no prevé el lanzamiento de pruebas en un horario, al menos no todavía.

Esto, por supuesto, no termina con el alcance de esta herramienta, hay muchas opciones posibles, he dado solo las primeras que me vinieron a la mente.

Conclusión.

Esta herramienta sin duda tiene futuro. Me parece que la mayor parte de su potencial aún está por revelarse en versiones posteriores y, sin duda, el producto encontrará a su usuario, que, en mi opinión, que aparentemente no coincide con la opinión del fabricante, probablemente no. un usuario común sin conocimientos específicos en el campo TI, pero una persona del departamento de desarrollo. Porque usar esta herramienta de manera efectiva no es una tarea fácil, especialmente en configuraciones complejas.

¡Hola amigos!

Traigo a su atención una pequeña configuración para pruebas de escenarios de soluciones basadas en 1C:Enterprise 8.3, formularios administrados.

La configuración se llama Tester. El probador es un entorno para desarrollar y ejecutar pruebas con guiones. El probador no es un producto BDD puro y no pretende describir el comportamiento de un sistema antes de que se desarrollara.

Los principales objetivos del Tester:

  1. Organice el trabajo en equipo con pruebas en un solo entorno con soporte para control de versiones, captura para edición y otras funciones familiares para trabajar con código
  2. Proporcionar al usuario una manera fácil de crear, mantener y extender pruebas de escenarios reales, en un tiempo razonable, con un umbral mínimo para ingresar al proceso y una infraestructura confiable

Con el probador, puede contar con la resolución de las siguientes tareas:

  1. Alto grado de cobertura de funcionalidad. El evaluador está bien enfocado en el proceso de desarrollo de la prueba, lo que tiene un efecto positivo en la cantidad y calidad de las pruebas creadas.
  2. Las pruebas están escritas en el lenguaje de programación 1C, que no solo es una herramienta familiar, sino que también le permite usar todo el conjunto de funciones de la plataforma en las pruebas y, lo que es más importante, le permite controlar el proceso de prueba mediante programación, sin depender de la versión integrada. modelo en la herramienta de prueba
  3. Puede crear bibliotecas a partir de pruebas, por ejemplo, puede crear pruebas que abran una ventana de búsqueda en una lista dinámica de acuerdo con los parámetros pasados, o generar un informe determinado. Si necesita tener un saldo en stock para su prueba, puede implementar una prueba de biblioteca en la que pase la composición del saldo requerido, y este saldo será acreditado
  4. Una simple verificación de la lógica de negocios, sin comparación con datos de otras bases de datos, sin solicitudes directas a la aplicación bajo prueba, sin diseños con datos serializados "en otro lugar". Toda la información se puede guardar en la prueba misma, en el diseño, si es necesario, modificado.
  5. Además del hecho de que todas las pruebas se almacenan en la base de datos, y cualquier usuario de Tester puede usar una prueba escrita por otro programador, Tester tiene la capacidad de descargar/cargar pruebas de forma incremental en el sistema de archivos. Esto puede ser útil para una mayor sincronización de las pruebas con sistemas de control de versiones como Git.

La base de demostración ha desarrollado una pequeña infraestructura de pruebas interconectadas que se pueden utilizar para desarrollar sus propias pruebas. Además, la base de datos contiene un ejemplo de cómo crear un documento de pedido a proveedor para ERP2 (demostración).

Para la configuración de ERP2 (demo) se creó un repositorio https://github.com/grumagargler/ERP2
Allí descargué pruebas demo. Espero que esta empresa no pase desapercibida para los entusiastas y las pruebas se repongan.

Encontrará la información más completa sobre Tester en la ayuda, estará en el escritorio cuando se inicie el sistema. Hay una sección de inicio rápido en la ayuda, le recomiendo que se familiarice con ella.

El probador es gratis. Desarrollado y mantenido para nuestras propias necesidades, sin antecedentes comerciales.

¡Gracias por su interés en el sistema y buena suerte con sus pruebas, amigos!

Actualización 1.3.2.7

Se agregó el procedimiento LogError (RecordError), que se usa para agregar mensajes mediante programación al registro de errores desde el código de la secuencia de comandos sin detener la ejecución de la secuencia de comandos.

Todas las funciones para trabajar con campos ahora pueden navegar a través de la parte tabular, por ejemplo, de esta manera puede verificar el monto de la acumulación en la quinta línea: Verificar ("#Accruals / Result [ 5 ]", 1000);

La función Check intenta comprobar valores numéricos sin tener en cuenta el separador de tríada y la parte fraccionaria

Se agregó Run Log donde se registran los eventos de ejecución de scripts

Se agregó la transición de la secuencia de comandos al registro de ejecución y al registro de errores.

Ayudante agregado al árbol de selección de campo

Se agregó ayuda en línea para los métodos de prueba incorporados al asistente

Se agregaron versiones de la aplicación. Las versiones se pueden configurar tanto para la aplicación en su conjunto como por separado para cada usuario.

Informes agregados: Protocolo, Resumen (los informes solo funcionarán para escenarios recién lanzados de esta versión). Es posible configurar un horario para el envío de informes por correo (al generar informes, se tienen en cuenta los RLS de los usuarios)

Los informes se implementan como derechos separados, para agregarlos a usuarios que no son administradores, debe realizar la configuración adecuada en sus perfiles

Scripts de descarga optimizados a archivos. Los archivos cargados se generan en formato bsl

Orden de transición:

Después de actualizar la configuración, antes de ejecutar los scripts, se recomienda prescribir sus versiones para sus soluciones. Esto se hace en el directorio de la aplicación.

¡Atención! La configuración se basa en la versión 8.3.10, pero también se admite el trabajo de versiones anteriores. Para hacer esto, en la versión 8.3.10, debe establecer el modo de compatibilidad de configuración requerido, guardar la configuración en un archivo y usarla como una actualización.

Tarjeta de solución 1C: prueba de escenario 8

Es un conjunto de herramientas para comprobar el rendimiento de cualquier configuración del sistema 1C:Enterprise 8. El producto le permite preparar las pruebas necesarias y realizarlas de forma manual o automática. Para desarrollar pruebas utilizando "1C: Scenario Testing 8", basta con tener una idea sobre el funcionamiento de la configuración probada a nivel de usuario, no se requieren conocimientos de programación.

Comprar 1C: prueba de escenario 8

4601546061393 42 000

Licencia 1C: Prueba de escenario 8

El producto "1C: Prueba de escenario 8" está diseñado para usarse con 1C: licencias de cliente Enterprise 8 que aumentan el número de trabajos.El paquete del producto incluye un kit de distribución, un libro "1C: Prueba de escenario 8. Guía del usuario" y un acuerdo de licencia.

Para usar el producto, debe tener cualquier entrega básica (versión PROF) del sistema 1C:Enterprise 8. El producto no está diseñado para usarse con las versiones básicas de 1C:Enterprise 8. 1C:Scenario Testing 8 es legal para usar en lugares de trabajo de la red local de la organización, provistos de una licencia de cliente 1C: Empresas 8. 1C: Prueba de escenario 8 incluida en la entrega 1C:Paquete de herramientas corporativas 8

Soporte y actualización 1C: prueba de escenario 8

El soporte y mantenimiento del servicio de los usuarios registrados se realiza en el marco de Información y soporte tecnológico (1C: ITS) - 1C: ITS Techno o 1C: ITS Prof. El período de suscripción gratuita al comprar el programa es de 3 meses. Después de la expiración del período de suscripción gratuita, para recibir servicios de soporte de productos, debe suscribirse a cualquier distribución básica del sistema 1C:Enterprise 8

Los usuarios registrados pueden descargar actualizaciones desde el sitio users.v8.1c.ru y desde el disco ITS.

Funcionalidad 1C: Prueba de escenario 8

Una prueba es un conjunto de acciones que un usuario debe realizar en un programa. Estas pueden ser acciones, por ejemplo, en crear nuevos elementos de directorios, documentos, completar datos en un formulario, presionar botones. Cuando dicha prueba se realiza automáticamente, se simula la entrada del usuario. Es importante que la plataforma 1C:Enterprise 8 procese la ejecución de comandos de prueba para la creación interactiva de objetos y el llenado de formularios de la misma manera que si el usuario ingresara estos datos desde el teclado.

Existe un principio de prueba similar en otros programas, pero, a diferencia de ellos, 1C: Scenario Testing 8 implementa capacidades de desarrollo de pruebas que reflejan las especificaciones de las configuraciones de prueba de 1C: Enterprise 8. Estas capacidades incluyen:

  • crear plantillas para completar formularios de diferentes objetos de configuración (se pueden personalizar y usar para diferentes pruebas de la misma configuración);
  • análisis de la conexión entre objetos de la base de referencia de configuración y pasos de prueba;
  • análisis de la corrección de la prueba grabada antes de su ejecución;
  • la capacidad de omitir manualmente el error detectado al realizar una prueba automatizada y continuar la prueba en modo automático;
  • comparación automática de movimientos de documentos con los datos de la base de referencia;
  • comparación uno por uno de los objetos creados por la prueba con los datos de la base de datos de referencia;
  • la capacidad de realizar pasos de depuración al grabar una prueba;
  • análisis de cobertura de prueba de objetos de configuración.

Para realizar la prueba, no se requiere una preparación especial de la configuración probada.

En la misma prueba, puede crear pasos para probar diferentes transacciones comerciales. La lógica de prueba se describe mediante las reglas para reflejar transacciones comerciales en el programa de acuerdo con la documentación del usuario. Por lo tanto, la herramienta se puede utilizar para pruebas funcionales o con guiones de configuraciones.

La necesidad de tales pruebas surge cuando es necesario asegurarse de que al finalizar la funcionalidad de configuración o corregir errores, se conserva la operatividad de la funcionalidad de configuración que permanece sin cambios. Esto tiene más demanda en aquellas organizaciones donde el desarrollo de nuevas versiones de configuraciones, su prueba y lanzamiento son iterativos. En este caso, el costo de escribir pruebas y su posterior ejecución automatizada será menor que con las pruebas de regresión manual de cada nueva versión de la configuración.

Por regla general, las pruebas se escriben para los escenarios de trabajo real más utilizados con una solución aplicada y se ejecutan en cada nueva versión de una configuración o plataforma modificada. Las pruebas pueden hacerse más o menos complejas, dependiendo de la criticidad de los errores en una funcionalidad particular de la solución aplicada y dependiendo de la cantidad de tiempo que la organización esté dispuesta a dedicar a las pruebas.

El kit de herramientas 1C:Scenario Testing 8 consta de dos procesamientos externos (un procesamiento está diseñado para escribir una prueba, el segundo para su ejecución), así como un conjunto de pruebas (archivos en formato xml) para configuraciones típicas de 1C:Enterprise 8.

Puedo usar:

  • socios - desarrolladores de soluciones de circulación,
  • socios o usuarios que tienen la tarea de probar la configuración antes de actualizar la base de producción.


@ 2023 lasiea.ru - Guía de ropa. sitio de información