“凡是不能量化的工作都是不可考量的”

　　目前很多公司已经意识到了单元测试的重要性，但国内坚持写单元测试的团队并不多，其中一个难点在于没有考量，没有很好地执行单元测试覆盖率检测。

　　想想，如果没有单元测试覆盖率检测，单纯的只写单元测试，时间长了也许开发人员会产生惰性，比如：今天任务太紧了，就不写单元测试了，以后再补，反正写不写也没有人知道。引入单元测试覆盖率检测之后，开发人员会更主动地写单元测试，就算补写单元测试也更有成就感。单元测试覆盖率检测有现成的第三方工具，比如 code climate 、 Coveralls 等等，针对不同的语言也有还有一些定制化的检测工具， 比如前端常用的 Eslint , Python 常用的PEP8 等等。整个项目的单元测试覆盖情况百分比，看上去一目了然。

　　相比其他层级的测试，单元测试发现并解决问题付出的成本相对来说 低，而投入产出比 高。单元测试的责任主体一般来说是开发人员，写单元测试也是开发人员对自己的代码进行检查的过程。

　　1.2 Service 集成测试

　　“多数应用和产品都需要与外部资源交互，有时候多数 Bug 并不来源于程序本身，而是由从外部输入的数据所引起的。”

　　这时候，就更需要集成测试。

　　集成测试是在单元测试的基础上，将所有模块按照设计要求(如根据结构图)组装成为子系统或系统，进行集成测试。这个集成测试阶段主要解决的是检查各个软件组成单元代码是否符合开发规范、接口是否存在问题、整体功能有无错误、界面是否符合设计规范、性能是否满足用户需求等等。

　　集成测试与单元测试 大的区别在于，它需要尽可能地测试整个功能及相关环境。如果不经过单元测试，那么集成测试的效果将会受到很大影响，大幅增加单元代码纠错的代价。

　　这一层的被测对象是抽离了展现层的代码(前端以及部分后端展现层逻辑)，主要是由测试人员进行，是测试人员大展身手的地方。

　　1.3 UI 系统测试

　　“一份永远都运行成功的自动化测试用例是没有价值的。一切都在变化中。”

　　在做好上面两层的测试覆盖之后，的是 UI 层的自动化测试。目前，UI 层的自动化覆盖正在逐渐转变为页面展示逻辑及界面前端与服务展现层交互的集成验证。UI层自动化做的方式很多，根据不同的系统，不同的架构可能会用到不同的框架或者工具，比较主流的有QTP，Robot Framework、watir、selenium 等。

　　怎么选择合适的工具?每个测试工具都有它的优缺点，每个被测试的项目也有自己本身的特点。比如，项目是用什么语言编写的，C, C++, Java, PHP , Python or C#? 项目是什么类型，Desktop , Web or Mobile Application? 很难说一种工具就可以搞定所有或者大部分的项目，也很难说一个项目就能单纯的靠一种工具来搞定。

　　UI 层是直接面向用户的，需要测试人员放入更多的时间和精力。如今的互联网公司大多需求变化大而快，迭代频繁，所以很多团队做 UI 自动化测试投入较大精力，却迟迟见不到效果，自动化测试人员每天奔命于维护脚本，追赶进度。有 2 点 UI层自动化覆盖的原则非常有必要提下：

　　能在底层做自动化覆盖，就尽量不在UI层做自动化覆盖;

　　只做核心功能的自动化覆盖，脚本可维护性尽可能提高。

　　综上所述，分层自动化测试侧重不同，效果不尽然完美的，而发现 bug 的方法是将自动化测试包含到构建过程中。谨慎周全的自动化测试可以进一步保 证持续部署的稳定与安全，提高持续部署的成功率。

　　请联系网站，了解详细的课程信息~

　　优质、便捷、省心