软件测试阶段包括单元测试、集成测试、系统测试和验收测试。
在单元测试阶段中一旦发现缺陷，很容易修改；而在系统测试或者验收测试阶段发现缺陷，就需要测试人员通过缺陷管理工具报告给开发人员，为了让开发人员能够快速、准确地定位缺陷，测试人员需要在缺陷报告中准确书写发现问题的版本、产生错误的步骤和缺陷的内容（有时候需要附上截图或日志信息）。
开发人员通过缺陷报告找到问题所在的代码行进行修复，重新编译后再给测试人员进行复测。如果测试通过，则关闭缺陷修复流程，否则描述问题，重新让开发人员修改。
这个过程是非常耗时、耗力的，可见单元测试在软件研发中是非常有效的。
但是单元测试也不是万能的，针对业务逻辑的缺陷，在单元测试阶段是很难被发现的，只有在系统测试或验收测试阶段才可以进行验证。
在我刚毕业的年代，单元测试往往是运行程序中的主函数（比如C语言中的main()函数），通过打印语句或者监控变量的值用半手工的方式进行验证，但是这种方式用完就被丢弃了，不能很好地被保留下来。
随着XUnit框架及代码扫描工具的出现，单元测试变得越来越容易，单元测试代码也可以被重复使用。随着敏捷和DevOps的出现，迭代变得越来越频繁，单元测试代码、代码扫描工具的复用也变得越来越频繁，特别是随着TDD（Test Driver Developed，测试驱动开发）的提出，单元测试越来越被人们所重视。
针对一段产品代码，需要匹配的单元测试代码可能是代码本身的数倍或者数十倍，这也是很多人知道单元测试的重要性，但是因为时间紧迫，把单元测试阶段忽略的原因。
我的建议是，可以把产品分为以下五类。
1. To C的互联网产品。
2. To B的互联网产品。
3. 传统的非嵌入式软件产品，如ERP、财务、CRM、管理等软件产品。
4. 传统的嵌入式软件产品。
5. 安全级别的软件产品，如部分金融、医疗、航空、航天软件产品。
针对第1、2类和部分第3类产品可以减少单元测试的数量，采用纺锤形测试模型或者蜂巢形测试模型，增加接口测试的数量。
针对第3、4类产品采用金字塔测试模型，测试覆盖率尽可能满足分支覆盖、条件/分支覆盖和路径覆盖，而对于嵌入式产品还需要考虑控制流覆盖。
针对第5类产品采用金字塔测试模型，测试覆盖率尽可能满足分支覆盖、条件/分支覆盖、路径覆盖，而对于关键模块必须考虑MC/DC。
最后：下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】
整套资料获取
