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