关于开发者测试

关于开发者测试

在软件行业中，一个程序从开始开发到交付使用，中间涉及了包括单元测试、集成测试、接口测试、性能测试等许多测试环节。其中由开发者完成的代码级测试部分称为开发者测试。

什么是开发者测试

• 单元测试
  开发者测试最重要的组成部分是单元测试。单元测试是在直接对代码的最基本逻辑进行的测试，一般而言，最基础的代码逻辑很难形成文档，只有开发者本人是最了解自己的代码逻辑，也只有开发者本人最适合写单元测试代码。之前比较流行的一些概念，比如测试驱动开发、结对编程等，与一般的开发者测试也是一样的思路，区别只在于是先写业务代码还是先写测试代码，是一个程序员写所有代码还是两个程序员互相写测试代码。

• DevOps和测试前移
  DevOps是比较流行的一种开发理念，这个单词是development和operation的组合，表示从开发到测试再到运维，一个项目团队要担起自己的项目生命周期内所有的事情。DevOps的概念流程中，没有单独的testing角色，但是测试还是要做，于是软件开发中有了测试前移的概念，既所有的测试都由开发人员来完成，这也给开发者测试添加了更加丰富的概念，除单元测试之外，代码级的各种黑白盒测试都可算入此类。

• 覆盖率
  说到测试就不能不提覆盖率的概念。覆盖率表示测试活动中，执行到的业务代码占总业务代码量的比例，是代码测试充分程度的度量指标，与测试的另一个指标——测试用例通过率——一起衡量测试活动的达成情况。

要不要做开发者测试

针对不同的代码类别、不同的代码性能要求、不同的测试难度等，合适的开发者测试力度会有一定的区别。软件业界的主流观点是肯定开发者测试的意义的。当你访问一个开源的项目时，总能在他的文件列表中找到单元测试的代码。对开源项目开发者而言，充足的测试也是对自己代码性能的一种证明，让其他的开发人员更容易认可自己的项目。
本人根据自己的经验，大概总结了一些代码级测试的好处：

• 及时发现代码问题
  要写出合适的测试代码，必须要非常熟悉代码的逻辑，因此写测试用例的过程本身也是开发者对自己的代码进行二次审视的过程，这个过程可以有效的发现开发时没有留心的问题。
• 高效的代码看护
  一般的项目都有一定的生命周期，在生命周期内会不断地升级和更新，每次升级和更新都不可避免的需要添加新的代码和逻辑。程序员是流动的，在一个项目的生命期内，很难保证一个代码模块始终跟同一个程序员绑定（程序员可能换项目组、离职或者猝死）。如果没有充足的测试用例，接手代码的程序员修改代码就会显得战战兢兢，每个轻微的修改都可能对已有的业务造成不可预期的影响，由修改引入的异常若不能及时发现，还会埋下长久的祸根。如果有充足的测试用例，集成构建系统就能很快的帮我们发现修改是否引入了问题，对代码的升级修改就也就能更加从容和高效。
• 提高代码可读性
  别人的代码总是很难理解，哪怕自己的代码，时间久了也会觉得莫名其妙。如果有充足的测试用例，对于一段生涩的代码，我们不理解时，读一下测试用例，就可以通过之前的程序员构造的测试输入和输出去揣度代码的逻辑用意，因此测试用例本身对代码的可读性是个很好的补充。

开发者的困惑

开发者测试虽然非常美丽，但程序员们对她却并不一定都有真爱。在国内某大型软件企业刚制定单元测试要求时，开发者表现出了强烈的抵触情绪。究其原因，包括以下几点：

• 紧逼的进度
  “版本经理说一周交付，一周能写完业务代码就不错了，还要写测试用例？”
• 无力的导向
  “不写测试用例的时候，两个月可以完成一个项目，写测试用例时，三个月才可以完成一个项目，主管打绩效的时候只会记录我的产出下降了，看不到我的质量提高了！”
• 虚弱的工具
  “覆盖率工具各种配置，自动生产的测试用例完全mock不到点子上，把所有的工具搭起来，我手动写main函数测都测完了！”
• 渺茫的效果
  “我的代码逻辑我都审视过了，没有问题，什么？以后其他人要看，要改？跟我有什么关系，凭什么花我的时间去帮别人提高效率！”

正确的测试导向

质量的导向是从上到下的，开发者测试能力的构建，需要管理者和开发人员共同努力。针对项目的管理者或者质量的监管者，有以下几点仅供参考的建议：

• 给开发团队自主权，有开发团队自主决定开发者测试的力度，只测核心功能或者测试所有代码，或者无需测试；
• 给开发者时间。不要急功近利，短期内时间成本的增加，要从长远看效果；
• 选好工具。项目团队根据自己的实际情况选择合适的工具，做好使用推广和培训，使一般程序员能够快速上手，不至于花太多的时间研究怎么使用工具；
• 做好引导。好的程序员，都能意识到代码测试的意义，进而主动的投入到测试活动中去。项目团队要引导每个成员都成为好的程序员。