Prueba de unidad/integración Configuración de asterisco

Question

Las pruebas de unidad y de integración se suelen realizar como parte de un proceso de desarrollo, por supuesto. Estoy buscando maneras de utilizar esta metodología en configuración de un sistema existente, en este caso el Asterisk soft PBX.

En el caso de Asterisk, el archivo de configuración es tanto un lenguaje de programación como cualquier otra cosa, completo con bucles, saltos, condicionales, etc., y puede volverse bastante complejo. Los cambios en la configuración a menudo adolecen de los mismos problemas que los cambios en un producto de software complejo; puede ser difícil prever todos los efectos sin pruebas en su lugar. Se empeora por el hecho de que la naturaleza del sistema es comunicarse con entidades externas, es decir, hacer llamadas telefónicas.

Tengo algunas ideas para probar el sistema usando los archivos de llamadas (para crear llamadas específicas entre extensiones) mientras miro la interfaz del administrador para los eventos generados. Una prueba podría entonces buscar un resultado esperado, es decir, marcar * 99 # debería dar como resultado que se llamara a la aplicación Voicemail.

Los defectos son obvios: no prueba el resultado real, solo lo que el sistema piensa es el resultado, y probablemente requiera alguna modificación del sistema bajo prueba. También es muy difícil escribir estas pruebas con la robustez suficiente como para activar solo la salida esperada, especialmente si el sistema está en uso (es decir, hay otras llamadas en curso).

¿Es lo que quiero, un sistema de prueba para Asterisk, imposible? Si no es así, ¿tiene alguna idea sobre cómo hacer esto de manera razonable? Estoy dispuesto a dedicarle una buena cantidad de tiempo de desarrollo y publicar el resultado bajo una licencia amiga, pero no estoy seguro de la mejor manera de abordarlo.

Answer 1

Obviamente, esta es una vieja pregunta, por lo que hay muchas posibilidades de que cuando Asterisk no admitió las pruebas de unidad/integración en la medida en que lo hace hoy (aunque la API de Unit Test Framework entró en 22/12/09, por lo que, al menos, existió).

El marco de prueba de la unidad (el correo electrónico de David de la lista de desarrolladores here) le permite ejecutar pruebas unitarias directamente dentro de Asterisk. Las pruebas se registran en el marco y se pueden ejecutar/ver a través de la CLI. Como todo esto es parte de Asterisk, las pruebas se compilan en el archivo ejecutable. Tienes que configurar Asterisk con la opción --enable-dev-mode, y marcar las pruebas para la compilación usando la herramienta menuselect (algunas aplicaciones, como app_voicemail, registran pruebas automáticamente, pero son la minoría).

Las pruebas de unidad de escritura son bastante sencillas, y aunque (obviamente) no está tan completo como un marco de pruebas de unidad comercial, hace el trabajo y puede mejorarse según sea necesario.

Lo más probable es que no sea lo que la mayoría de los usuarios de Asterisk querrán usar, aunque los desarrolladores de Asterisk están muy animados a que lo comprueben. Tanto los usuarios como los desarrolladores probablemente estén interesados ​​en las pruebas de integración, que ofrece el Asterisk Test Suite. En esencia, el Test Suite es un script de Python que ejecuta otros scripts, ya sean lua, python, etc. El Test Suite viene con un conjunto de bibliotecas de python y lua que ayudan a organizar y ejecutar múltiples instancias de Asterisk. Los escritores de prueba pueden usar aplicaciones de terceros como SIPp o Asterisk (AMI, AGI) o una combinación de las mismas para probar las instancias alojadas de Asterisk.

Actualmente, hay cerca de 200 pruebas en el conjunto de pruebas, y se agregan más de forma regular. Obviamente, podría escribir sus propias pruebas que ejerzan su configuración de Asterisk y que el conjunto de pruebas las administre. Si son lo suficientemente genéricas, también puede enviarlas para su inclusión en el paquete de pruebas.

Tenga en cuenta que el Test Suite puede ser un poco complicado de configurar: Leif escribió una buena publicación en el blog sobre la configuración del Test Suite here.

Answer 2

Bueno, depende de lo que está probando. Hay muchas maneras de manejar este tipo de cosas. Mi preferencia es usar los archivos de llamadas de Asterisk incluidos con el código de marcado. EG: Crear un archivo de llamadas para marcar un número público, una vez que se responde, volver al contexto de plan de marcado especificado y realizar toda mi lógica de prueba (reproducir archivos de sonido, escuchar presionar teclas, etc.)

Escribí una llamada de Asterisk biblioteca de archivos que hace que este tipo de pruebas sea extremadamente fácil. También tiene mucha documentación/ejemplos, compruébalo aquí: http://pycall.org/. Eso puede ayudarte.

¡Buena suerte!

Answer 3

Puede crear un conjunto de escenarios específicos y usar el comando MixMonitor de Asterisk para grabar estas llamadas. Esto le permitiría establecer un conjunto de grabaciones de sonido que fueran normativas para su sistema para estas pruebas, y usar una herramienta de comparación automática de archivos de sonido (¿Quizás algo de comparing-sound-files-if-not-completely-identical?) Para examinar los resultados. Solo una idea.

Answer 4

Pruebas unitarias en lugar de pruebas de integración significa que se supone que su código debe ser arquitectónico, por lo que la lógica está aislada de las dependencias externas. Usted dijo "el archivo de configuración es tanto un lenguaje de programación como cualquier otra cosa", pero esa es la cuestión: los lenguajes reales no solo tienen flujo de control sino también capacidades de abstracción, que le permiten escribir la lógica de una manera que puede ser probada por unidades. Es por eso que mantengo la lógica fuera del asterisco tanto como sea posible.

Para realizar pruebas de integración, ejecute la secuencia de comandos linphonec y guíe la consola del asterisco para ver qué está haciendo. Puede usar la ventana acoplable y activar instancias de asterisco temporales para cada prueba.