当然，单元和集成测试通常作为开发过程的一部分执行。我正在寻找在现有系统配置中使用此方法的方法，在本例中为Asterisk soft PBX。
在 Asterisk 的情况下，配置文件和其他任何东西一样是一种编程语言，包含循环、跳转、条件等，并且可以变得相当复杂。配置更改通常会遇到与复杂软件产品更改相同的问题——如果没有适当的测试，很难预见所有影响。更糟糕的是，系统的本质是与外部实体进行通信，即打电话。
我有一些关于使用调用文件（在扩展之间创建特定调用）测试系统的想法，同时观察管理器界面生成的事件。然后测试可以观察预期的结果，即拨打 *99# 应该会导致语音邮件应用程序被调用。
缺陷很明显——它不测试实际结果，只测试系统认为的结果，并且可能需要对被测系统进行一些修改。编写足够健壮的这些测试以仅在预期输出上触发也非常困难，尤其是在系统正在使用中（即正在进行其他调用）时。
我想要的 Asterisk 测试系统是不可能的吗？如果没有，您对如何以合理的方式解决此问题有任何想法吗？我愿意为此投入大量的开发时间，并在友好的许可下发布结果，但我不确定处理它的最佳方法。
好吧，这取决于您要测试的内容。有很多方法可以处理这种事情。我的偏好是使用与拨号方案代码捆绑在一起的 Asterisk 呼叫文件。EG：创建一个呼叫文件来拨打一些公共号码，一旦被应答，跳回指定的拨号方案上下文并执行我所有的测试逻辑（播放声音文件，监听按键等）
我写了一个 Asterisk 调用文件库，它使这种测试非常容易。它也有很多文档/示例，请在此处查看：http: //pycall.org/。这可能会帮助你。
祝你好运！
这显然是一个老问题，所以很有可能当原始答案在这里发布时，Asterisk 不支持单元/集成测试到今天的程度（尽管单元测试框架 API 于 12 月 22 日/ 09，因此至少确实存在）。
单元测试框架（来自此处的开发列表的 David 的电子邮件）允许您直接在 Asterisk 中执行单元测试。测试在框架中注册，可以通过 CLI 执行/查看。因为这都是 Asterisk 的一部分，所以测试被编译成可执行文件。您必须使用 --enable-dev-mode 选项配置 Asterisk，并使用 menuselect 工具标记要编译的测试（某些应用程序，如 app_voicemail，会自动注册测试 - 但它们是少数）。
编写单元测试相当简单——虽然它（显然）不像商业单元测试框架那样功能齐全，但它可以完成工作并且可以根据需要进行增强。
这很可能不是大多数 Asterisk 用户想要使用的 - 尽管强烈鼓励 Asterisk 开发人员检查它。用户和开发人员都可能对Asterisk 测试套件提供的集成测试感兴趣。从本质上讲，测试套件是一个执行其他脚本的 python 脚本——无论是 lua、python 等。测试套件带有一组 python 和 lua 库，可帮助编排和执行多个 Asterisk 实例。测试编写者可以使用第三方应用程序，例如 SIPp 或 Asterisk 接口（AMI、AGI）或其组合来测试托管的 Asterisk 实例。
测试套件中现在有近 200 个测试，并且会定期添加更多测试。您显然可以编写自己的测试来执行您的 Asterisk 配置并让它们由测试套件管理 - 如果它们足够通用，您也可以提交它们以包含在测试套件中。
请注意，设置测试套件可能有点棘手 - Leif 在这里写了一篇关于设置测试套件的好博文。
您可以创建一组特定场景并使用 Asterisk 的 MixMonitor 命令来记录这些调用。这将使您能够为这些测试建立一组对您的系统来说是规范的录音，并使用自动声音文件比较工具（也许来自比较声音文件如果不完全相同？）来检查结果。只是一个想法。
与集成测试相反，单元测试意味着您的代码应该是结构化的，因此逻辑本身与外部依赖项隔离。您说过“配置文件与其他任何东西一样是一种编程语言”，但这就是事实 --- 真正的语言不仅具有控制流，而且具有抽象功能，它允许您以可以进行单元测试的方式编写逻辑。这就是为什么我尽可能将逻辑放在星号之外。
对于集成测试，使用脚本linphonec来驱动您的应用程序，并使用 grep 星号控制台查看它在做什么。您可以使用 docker，并为每个测试启动临时星号实例。