软件测试控制流程图-测试直播网络延时测试软件

JAR包依赖以及维护升级，通常是一件令我们比较头疼的事情，特别是在运行时出现的冲突异常，更是灾难性的。为了从技术角度更好地进行管理，我们需要做好隔离，这一点可以利用JVM类加载机制来实现。

如果你有兴趣，可以在网上参考阿里的潘多拉（Pandora）容器设计资料，这里我们就不作详细介绍了。

功能测试

包括单元测试、接口测试、联调测试和集成测试。这里的每个测试环节起到的作用不同，联调测试和集成测试依赖的主要手段还是手工验证，所以这里我们分享下可以通过自动化手段完成的单元测试和接口测试。

这里主要用到的几个工具：

关于上述这几种工具，我在此就不展开详细介绍了，你可以自行上网查询和学习。

下面，我们分析一下功能测试中的两个重要环节：单元测试和接口测试。

上述自动化测试环节结束，软件包就可以发布到我们之前说的项目测试环境或集成测试环境进行功能联调和测试了，这时就需要部分人工的介入。

非功能测试

在功能验证的同时，还需要并行进行一些非功能性验证，包括安全审计、性能测试和容量评估 。分别介绍如下：

下面是扫描结果的简单示例（目前扫描工具已经开源，请见文末链接）：

下图是一张发布前后的效果比对示意图，正常情况下，性能曲线应该是基本重叠才对，不应该出现较大的偏差。

最后

到这里，我们稍作一个总结。

关于持续交付中的流水线模式，我们在前面两期文章以及本期的分享中，相对完整地介绍了从需求分解开始，到代码提交、软件构建，再到功能和非功能测试验证的整个过程。这个过程就是我们常说的持续集成。

之所以我没有在一开始引入这个概念，是因为软件测试控制流程图，如果我们将注意力集中到这一过程中具体的动作和问题上，会更有利于我们理解软件测试控制流程图，而不是一开始就被概念性的术语和框架束缚住。

流水线模式功能测试和非功能测试的整个过程可以总结如下：

同时，我们在上面持续集成的过程中，要基于前面介绍的各类环境和基础配置管理，比如功能验证就需要在线下环境中的开发环境、项目环境以及集成测试环境上进行验收。

而非功能验证的性能和容量评估，就需要在线上环境里的预发或Beta环境中完成。这里就已经涉及到了软件的部署发布。

下一期文章，我将分享线上发布的整个过程，并对整个持续交付体系内容做一个收尾。欢迎你留言与我讨论。

如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！

附：源代码安全审计工具