测试理论

1. 80%的bug存在于20%的代码中，所以不用等价测试所有功能，在主要功能处狠狠测试

2. 软件测试原则：

   • 测试尽早介入原则：在早期发现问题，修复成本较低
   • 测试无法穷尽原则
   • 独立性原则：测试人员应该独立于开发团队，测试会从用户的角度考虑，严格审视软件功能，而开发人员可能更关注软件有没有按照自己的设计意图实现。
   • 杀虫剂悖论：如果一直使用同一套测试用例，那系统会对测试用例免疫，所以要及时更新和补充测试用例。

3. 负载测试与压力测试的区别：

   负载测试用来评估系统的性能指标，而压力测试是去制造问题，然后去分析引起问题的原因

4. 测试左移

   • 在整个周期中，越早发现缺陷，修复成本越低。
   • 将测试是软件质量的负责人，改为测试人员、开发人员和产品经理等角色共同参与质量保障。
   • 预防优于检测：通过提前验证需求分析和设计，设计测试用例，并依据测试用例，减少缺陷产生的可能性。

   测试左移不是完全取代传统测试，而是互补，需要结合使用。

5. 测试驱动开发（Test-Driven Development）

   关键点在于：通过 测试-->编码-->重构的方式实现

   编写单元测试-->编码使其可以通过单元测试-->重构优化代码

   单元测试是最常用的测试类型，但也可根据项目需求选择测试类型，核心是遵循以上原则。

   从单元测试驱动开发的角度看，更趋向于开发模式的改变。

   适用于对质量要求很高的系统，或核心模块。

   TDD如果不使用技术手段，其实是没什么意思的。（比如通过测试用例先行，让开发根据测试用例开发，提前思考可能会引发的问题，而不通过单元测试或其他测试方式验证代码功能，实际上效果并不明显，因为【提前思考可能会引发的问题】这个行为究竟能产生多大的效益）