测试是一门非常大的学问，引用百度百科的原文： “软件测试（英语：Software Testing)，描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程”。
具体可以分为非应用测试和应用测试， 非应用测试是指由于外设、系统软件升级等引发的测试活动，应用测试则是指对应用软件的测试。应用测试又可以分为以下7部分，其中1、2 是由开发负责，3、4、5由测试负责，7是由业务负责。
- 单元测试：对单独模块的测试
- 集成测试：对模块、应用之间的接口进行测试
- 系统测试：和外部系统和环境组合在一起后，对系统功能和操作流程进行验证
- 性能测试：
- 安全测试：
- 回归测试： 检验已发现的缺陷有没有被修改，修改过程中有没有引入新的缺陷
- 业务验收测试： 需求提出方对软件是否符合业务设计思想进行测试
本文重点针对单元测试、集成测试进行展开。很多人将单元测试和集成测试混为一谈，都称为单元测试，但是这两者还是有区别的，下文为了简便，统称为单元测试。针对测试主要分为两派：
- 一派非常尊崇单元测试， 不仅认为测试可以极大地保证代码的质量，甚至能够促进软件的设计，提出了测试驱动开发；
- 一派则将单元测试视为累赘，很少甚至不写单元测试。
本文无意引战，评论哪种好，哪种不好，但是如果想充分利用单元测试提高代码的质量， 需要满足一定的前提。如果只是为了应付检查，为了单元测试而单元测试，不仅没有任何帮助，还会起反的效果。
- 时间充裕：
第一是要有时间，因为单元测试要想充分测试是非常消耗精力的，同时维护业务代码和测试代码，所花的时间要比单纯维护业务代码多一倍。 互联网公司又强调敏捷开发，小步快跑，很多时候光是完成需求就已经用尽了全力，哪还有时间写单元测试。更不可能因为单元测试，阻碍项目的进度，所以会优先保证项目上线，而降级单元测试。当然这里并不是说单元测试对项目质量的保证没有任何帮助 - 代码可测：
单元测试的第二个前提是代码可测，很多时候在编写代码的时候，就要充分考虑可测性。但是遗憾的是很多代码并不能够满足这个要求，有些时候代码不能方便地进行测试；又有些时候，很多遗留的代码，马上要被废弃了，对其进行单元测试也没有意义。 - 业务相对稳定：
第三个前提是业务相对稳定，如果需求三天两头变， 那么单元测试就成了累赘。 - 覆盖率与优先级：
测试的覆盖率也是一个考虑的关键点，覆盖率低了，测不出东西，覆盖率高了又需要花很多时间。 所以要重点保证一些关键接口的测试覆盖率。
网友评论