单元/集成测试 Asterisk 配置
当然，单元和集成测试通常作为开发过程的一部分进行。我正在寻找在现有系统的配置中使用此方法的方法，在本例中为 Asterisk 软 PBX。
就 Asterisk 而言，配置文件与其他任何东西一样都是一种编程语言，包含循环、跳转、条件等，并且可能变得相当复杂。配置的更改通常会遇到与复杂软件产品的更改相同的问题 - 如果没有适当的测试，很难预见所有影响。更糟糕的是，系统的本质是与外部实体通信，即打电话。
我有一些关于使用调用文件测试系统（以在扩展之间创建特定调用）同时观察管理器界面生成的事件的一些想法。然后，测试可以观察预期的结果，即拨打 *99# 应该会导致语音邮件应用程序被呼叫。
缺陷是显而易见的 - 它不测试实际结果，只测试系统认为的结果，并且可能需要对被测系统进行一些修改。编写这些测试足够稳健以仅在预期输出上触发也非常困难，特别是当系统正在使用时（即有其他调用正在进行中）。
我想要的 Asterisk 测试系统不可能吗？如果没有，您对如何以合理的方式解决这个问题有什么想法吗？我愿意投入大量的开发时间并在友好的许可证下发布结果，但我不确定实现它的最佳方法。
Unit and integration testing is usually performed as part of a development process, of course. I'm looking for ways to use this methodology in configuration of an existing system, in this case the Asterisk soft PBX.
In the case of Asterisk, the configuration file is as much a programming language as anything else, complete with loops, jumps, conditionals, etc., and can get quite complex. Changes to the configuration often suffers from the same problems as changes to a complex software product - it can be hard to foresee all the effects without tests in place. It's made worse by the fact that the nature of the system is to communicate with external entities, i.e. make phone calls.
I have a few ideas about testing the system using call files (to create specific calls between extensions) while watching the manager interface for generated events. A test could then watch for an expected result, i.e. dialling *99# should result in the Voicemail application getting called.
The flaws are obvious - it doesn't test the actual result, only what the system thinks is the result, and it probably requires some modification of the system under test. It's also really hard to write these tests robustly enough to only trigger on the expected output, especially if the system is in use (i.e. there are other calls in progress).
Is what I want, a testing system for Asterisk, impossible? If not, do you have any ideas about ways to go about this in a reasonable manner? I'm willing to put a fair amount of development time into this and release the result under a friendly license, but I'm unsure about the best way to approach it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以创建一组特定场景并使用 Asterisk 的 MixMonitor 命令来记录这些呼叫。这将使您能够建立一组对您的系统进行这些测试规范的录音，并使用自动声音文件比较工具（可能来自比较声音文件如果不完全相同？）来检查结果。只是一个想法。
You could create a set of specific scenarios and use Asterisk's MixMonitor command to record these calls. This would enable you to establish a set of sound recordings that were normative for your system for these tests, and use an automated sound file comparison tool (Perhaps something from comparing-sound-files-if-not-completely-identical?) to examine the results. Just an idea.
与集成测试相反，单元测试意味着您的代码应该进行架构设计，以便逻辑本身与外部依赖项隔离。您说“配置文件与其他任何东西一样都是一种编程语言”，但事实就是如此——真正的语言不仅具有控制流，还具有抽象功能，它允许您以可以进行单元测试的方式编写逻辑。这就是为什么我尽可能将逻辑保留在星号之外。
对于集成测试，编写
linphonec脚本来驱动您的应用程序，并 grep asterisk 控制台来查看它正在做什么。您可以使用 docker，并为每个测试启动临时星号实例。
Unit testing as opposed to integration testing means your code is supposed to be architectured so the logic itself is insulated from external dependencies. You said "the configuration file is as much a programming language as anything else" but that's the thing --- real languages has not just control flow but abstraction capabilities, which allow you to write the logic in a way that can be unit tested. That's why I keep logic outside of asterisk as much as possible.
For integration testing, script
linphonecto drive your application, and grep the asterisk console to see what it's doing.You can use docker, and fire up temporary asterisk instances for each test.
这显然是一个老问题，所以很有可能当原始答案发布在这里时，Asterisk 不支持单元/集成测试到今天的程度（尽管单元测试框架 API 于 12/22/ 09，所以至少确实存在）。
单元测试框架（来自开发列表的 David 的电子邮件此处< /a>) 允许您直接在 Asterisk 中执行单元测试。测试已在框架中注册，并且可以通过 CLI 执行/查看。由于这都是 Asterisk 的一部分，因此测试被编译到可执行文件中。您必须使用 --enable-dev-mode 选项配置 Asterisk，并使用 menuselect 工具标记要编译的测试（某些应用程序，如 app_voicemail，自动注册测试 - 但它们是少数）。
编写单元测试相当简单 - 虽然它（显然）不像商业单元测试框架那样功能齐全，但它可以完成工作并且可以根据需要进行增强。
这很可能不是大多数 Asterisk 用户想要使用的——尽管强烈鼓励 Asterisk 开发人员检查它。用户和开发人员可能都对集成测试感兴趣，Asterisk 测试套件提供。测试套件的核心是一个执行其他脚本（lua、python 等）的 python 脚本。测试套件附带了一组 python 和 lua 库，可帮助编排和执行多个 Asterisk 实例。测试编写者可以使用第三方应用程序（例如 SIPp 或 Asterisk 接口（AMI、AGI）或其组合）来测试托管的 Asterisk 实例。
测试套件中现在有近 200 个测试，并且会定期添加更多测试。显然，您可以编写自己的测试来执行 Asterisk 配置并由测试套件管理它们 - 如果它们足够通用，您也可以提交它们以将其包含在测试套件中。
请注意，测试套件的设置可能有点棘手 - Leif 写了一篇关于设置测试套件的好博客文章 此处。
This is obviously an old question, so there's a good chance that when the original answers were posted here that Asterisk did not support unit / integration testing to the extent that it does today (although the Unit Test Framework API went in on 12/22/09, so that, at least, did exist).
The unit testing framework (David's e-mail from the dev list here) lets you execute unit tests directly within Asterisk. Tests are registered with the framework and can be executed / viewed through the CLI. Since this is all part of Asterisk, the tests are compiled into the executable. You do have to configure Asterisk with the --enable-dev-mode option, and mark the tests for compilation using the menuselect tool (some applications, like app_voicemail, automatically register tests - but they're the minority).
Writing unit tests is fairly straight-forward - and while it (obviously) isn't as fully featured as a commercial unit test framework, it gets the job done and can be enhanced as needed.
That most likely isn't what the majority of Asterisk users are going to want to use - although Asterisk developers are highly encouraged to check it out. Both users and developers are probably interested in integration tests, which the Asterisk Test Suite provides. At its core, the Test Suite is a python script that executes other scripts - be they lua, python, etc. The Test Suite comes with a set of python and lua libraries that help to orchestrate and execute multiple Asterisk instances. Test writers can use third party applications such as SIPp or Asterisk interfaces (AMI, AGI) or a combination thereof to test the hosted Asterisk instance(s).
There are close to 200 tests now in the Test Suite, with more being added on a fairly regular basis. You could obviously write your own tests that exercise your Asterisk configuration and have them managed by the Test Suite - if they're generic enough, you could submit them for inclusion in the Test Suite as well.
Note that the Test Suite can be a bit tricky to set up - Leif wrote a good blog post on setting up the Test Suite here.
嗯，这取决于您要测试的内容。有很多方法可以处理这类事情。我的偏好是使用与拨号方案代码捆绑在一起的 Asterisk 呼叫文件。 EG：创建一个呼叫文件来拨打某个公共号码，一旦被应答，跳回到指定的拨号方案上下文并执行我所有的测试逻辑（播放声音文件，监听按键等）
我编写了一个 Asterisk 呼叫文件库，它使得这种测试非常简单。它也有很多文档/示例，请在此处查看：http://pycall.org/。这可能对你有帮助。
祝你好运！
Well, it depends on what you are testing. There are a lot of ways to handle this sort of thing. My preference is to use Asterisk Call Files bundled with dialplan code. EG: Create a callfile to dial some public number, once it is answered, hop back to the specified dialplan context and perform all of my testing logic (play soundfiles, listen for keypresses, etc.)
I wrote an Asterisk call file library which makes this sort of testing EXTREMELY easy. It has a lot of documentation / examples too, check it out here: http://pycall.org/. That may help you.
Good luck!