-
-
手机阅读
在两年以前，我写了一系列关于单元测试的文章，希望在公司内部的产品开发过程中，引进完整的单元测试，当单元测试工作推动起来后，我便停止了这方面的写作。前几天，与公司不同部门的同事谈起单元测试，很有一些感触，因此，又动了写单元测试文章的想法。
话题的起因是这样的，这位同事以及其他几位同位，正在全力开发一个全新的产品，团队人数不多，项目周期也不长，想在内部引入单元测试，因为觉得我部门单元测试的工作推动得不错，这位同事向我搬救兵，希望我部门给他支援一两个单元测试人员。问他打算如何推动单元测试工作，他的想法是，他和另一个核心开发人员全力编写系统，我支援的测试人员全力给他们做单元测试。
我当时问了他几个问题：
1、你们两个核心人员准备参与单元测试吗？
回答：不准备参与。
2、如果两个测试人员的测试速度跟不上两个核心人员的开发速度，怎么办？
回答：只测主流程和基础模块，不测分支流程和上层模块（也是非界面）。
3、测试人员如何理解拟测试的程序及模块？
回答：核心开发人员给测试人员讲解模块的功能，由测试人员自我阅读理解。
我当时这样回答那位同事：如果是这样，我建议你还是不要引入单元测试。
这样回答，不是给那位同事拨冷水，也不是不愿意支援两个单元测试人员，这两年，我们团队在单元测试的过程中，尝到了太多酸甜苦辣。回想这两年以来的产品开发工作，在我的强力推动下，单元测试工作推动得不错，取得了一些成绩，也发现了很多以前没有发现的问题。在这里将一些感受写出来，算是两年单元测试的总结吧。
总结1：如果项目团队的主要领导对单元测试的理论和技术不熟悉，一定不要引入单元测试。
总结2：当项目的开发周期紧，开发人员的投入不多，一定不要引入单元测试。
总结3：在项目的开发过程中，要只少有一位核心开发人员投入到单元测试，或者，每位核心开发人员至少要投入1/3的时间到自己所编程的单元测试中。
总结4：单元测试是一项长期的系统性的工程，启动容易，长期坚持难，对单元测试如何能够长期适应项目的变动，是单元测试中最难处理的事情。
总结5：当项目需求经常变化，或内核模块未达到一定的功能稳定期，不要贸然投入单元测试，否则，大量的单元测试工作会全部白做。
总结6：如果单元测试对被测试代码不能够达到一定程度的测试覆盖度，不如不做单元测试。
总结7：当代码的文档不全时，对单元测试人员的水平要求非常高，如果单元测试人员的水平不够，会编出很多无意义的单元测试用例。
总结8：同水平的单元测试人员与开发人员的数量如果不能达到1:1，不要引入单元测试，要使单元测试发挥效果，单元测试人员与开发人员的数量最好达到或超过2:1。
总结9：不要试图对第三方库、或历史遗留模块做单元测试；
总结10：不要迷信单元测试所得出的系统稳定性指标，再严格单元测试也不能完全保证系统质量，需要与模块测试、接口测试、集成测试等一并保证系统质量。
写了以上这些内容，并不是反对在项目中引入单元测试，只是希望那些对单元测试不太了解的团队，在是否要引入单元测试时，一定要慎重，否则，会发现投入了很多，产出却少得可怜。
事实上，我们团队已经在项目中尝到了单元测试的甜头，我们也希望在单元测试方面做得更好，我相信，经历过这两年的酸甜苦辣，我们有信心在单元测试这条路上走得更远