L'unité et les tests d'intégration sont généralement effectués dans le cadre d'un processus de développement, bien sûr. Je cherche des moyens d'utiliser cette méthodologie dans Configuration d'un système existant, dans ce cas, le Asterisk Soft PBX .
Dans le cas de l'astérisque, le fichier de configuration est autant une langue de programmation que autre chose, avec des boucles, des sauts, des conditionnels, etc., et peut être assez complexe. Les modifications apportées à la configuration souffrent souvent des mêmes problèmes que les modifications apportées à un logiciel complexe - il peut être difficile de prévoir tous les effets sans tests en place. Il est aggravé par le fait que la nature du système est de communiquer avec des entités externes, c'est-à-dire des appels téléphoniques.
J'ai quelques idées sur le test du système à l'aide de fichiers d'appel (pour créer des appels spécifiques entre les extensions) tout en regardant l'interface Manager pour des événements générés. Un test pourrait alors surveiller un résultat attendu, c'est-à-dire la numérotation * 99 # devrait entraîner l'application de la messagerie vocale.
Les défauts sont évidents - il ne teste pas le résultat réel, seul ce que le système pense est le résultat et nécessite probablement une modification du système sous test. Il est également très difficile d'écrire ces tests suffisamment de manière robuste pour déclencher uniquement sur la sortie attendue, en particulier si le système est utilisé (c'est-à-dire d'autres appels en cours).
est ce que je veux, un système de test pour l'astérisque, impossible? Sinon, avez-vous des idées sur les moyens d'y aller de manière raisonnable? Je suis disposé à mettre en place une bonne quantité de temps de développement dans cette question et je suis libéré le résultat sous une licence amicale, mais je ne suis pas sûr de la meilleure façon de l'aborder.
4 Réponses :
Eh bien, cela dépend de ce que vous testez. Il y a beaucoup de façons de gérer ce genre de chose. Ma préférence est d'utiliser des fichiers d'appels astérisques groupés avec le code de dialplan. Exemple: Créez un fichier Callfile pour composer un certain nombre de numéros publics, une fois que vous avez répondu, accédez au contexte de dialplan spécifié et effectuez toute ma logique de test (Play SoundFiles, écouter pour les touches, etc.)
J'ai écrit une bibliothèque de fichiers d'appel d'astérisque qui rend ce type de test extrêmement facile. Il a aussi beaucoup de documentation / d'exemples également, vérifiez ici: http://pycall.org/ . Cela peut vous aider.
bonne chance!
Ce n'est pas une mauvaise bibliothèque. La plupart des tests que j'envisage sont de l'utilisateur "l'utilisateur appelle ce nombre court, vérifie qu'un appel est placé sur cet autre numéro sur la ligne de réseau" ou "utilisateur appelle ce numéro, vérifiez que l'appel est répondu, un fichier son joué et une entrée de base de données créée ". Les effets secondaires sont (relativement) faciles à vérifier, l'expérience utilisateur pas tellement. : /
Dans ce cas, vous voudrez utiliser l'AMI (interface Asterisk Manager), car vous pouvez obtenir des événements d'état en direct pour savoir si l'appel a été effectué avec succès, etc. Découvrez les documents ici: VoIP-Info.org/wiki/view/Asterisk+Manager+Api
Vous pouvez créer un ensemble de scénarios spécifiques et utiliser la commande Asterisk de MixMonitor pour enregistrer ces appels. Cela vous permettrait d'établir un ensemble d'enregistrements sonores normatifs pour votre système pour ces tests et d'utiliser un outil de comparaison de fichiers audio automatisé (peut-être quelque chose de comparer-sound-fichiers-if-non-complètement-identiques ?) Examiner les résultats. Juste une idée.
Cela ne fonctionnera pas. Il y a beaucoup de variables lors de la gestion du son des appels. Les numéros statiques, timings et autres rendront cela presque impossible.
Je n'ai pas beaucoup d'expérience avec des empreintes digitales audio et je ne sais pas quelle granularité la comparaison fonctionnerait avec. Cependant, si vous appelez à partir d'une boîte d'astérisque à une boîte d'astérisque sur un réseau local, ce que j'imagine que vous utiliseriez pour les tests unitaires, je devinerais que beaucoup de variables que vous suggérez seraient plus proches des constantes. Cela étant dit, moi aussi, je ne sais pas à quel point ce type de test de l'unité serait efficace, en donnant des suggestions. : -).
Ceci est évidemment une ancienne question. Il y a donc de bonnes chances que lorsque les réponses originales ont été postées ici, cet astérisque n'a pas soutenu les tests de l'unité / de l'intégration dans la mesure où il le fait aujourd'hui (bien que l'API de test de test unitaire ait été enregistrée sur 12 / 22/09, de sorte que, du moins, existait).
Le cadre de test de l'unité (e-mail de David de la liste de devis Ici ) vous permet d'exécuter des tests d'unité directement dans l'astérisque. Les tests sont enregistrés dans le cadre et peuvent être exécutés / consultés via la CLI. Comme cela fait partie de l'astérisque, les tests sont compilés dans l'exécutable. Vous devez configurer Asterisk avec l'option --enable-Dev-Mode et marquer les tests de compilation à l'aide de l'outil MenusElect (certaines applications, telles que app_voicemail, enregistrez automatiquement des tests - mais ils sont la minorité).
Les tests d'unités d'écriture sont assez simples - et bien que cela (évidemment) n'est pas aussi pleinement présenté comme un cadre de test d'unités commerciales, il obtient le travail effectué et peut être amélioré au besoin.
Ce n'est probablement pas ce que la majorité des utilisateurs d'astérisque vont vouloir utiliser - bien que les développeurs d'astérisque soient très encouragés à le vérifier. Les utilisateurs et les développeurs sont probablement intéressés par des tests d'intégration, que le Asterisk Test Suite fournit. À son noyau, la suite de tests est un script python qui exécute d'autres scripts - être Lua, Python, etc. La suite de tests est livrée avec un ensemble de bibliothèques Python et Lua qui aident à orchestrer et à exécuter plusieurs instances d'astérisque. Les écrivains de test peuvent utiliser des applications tierces telles que SIPP ou des interfaces astérisques (AMI, AGI) ou une combinaison de ceux-ci pour tester l'instance d'astérisque hébergée.
Il existe maintenant près de 200 tests dans la suite de tests, avec plus d'additionner de manière assez régulière. Vous pouvez évidemment écrire vos propres tests qui exercent votre configuration astérisque et les avoir géré par la suite de tests - s'ils sont suffisamment génériques, vous pouvez également les soumettre à l'inclusion dans la suite de tests.
Notez que la suite de tests peut être un peu difficile à configurer - Leif a écrit un bon blog sur la configuration de la suite de tests ici .
Corrigez-moi si je me trompe, mais la suite de tests est destinée aux développeurs astérisques de tester l'astérisque lui-même, tandis que la question était de tester un système construit sur l'astérisque
Il peut être utilisé à diverses fins. La suite de test d'astérisque orchesille une instance d'astérisque, en utilisant la configuration de la machine + quelques remplissages. Cela inclut la conduite d'astérisque avec des appels mock, vérifiant des événements, etc. Un certain nombre de personnes l'utilisent pour vérifier leur configuration entre mises à niveau; Basé sur la question de OP, cela semblait être une possibilité.
Test unitaire par opposition aux tests d'intégration signifie que votre code est censé être architecturé afin que la logique elle-même soit isolée des dépendances externes. Vous avez dit "Le fichier de configuration est autant une langue de programmation comme autre chose" mais c'est la chose ------ Les langues réelles ne contiennent que les capacités d'abstraction, ce qui vous permet d'écrire la logique d'une manière qui peut être testée une unité. C'est pourquoi je garde la logique en dehors de l'astérisque autant que possible.
Pour les tests d'intégration, script linphonec pour piloter votre application et Grep la console d'astérisque pour voir ce qu'elle fait.
Vous pouvez utiliser Docker et enflammer des instances d'astérisque temporaires pour chaque test.