测试策略就是你所作的计划，其目的是实现你的测试目标，前提条件是必须根据项目的实际情况来采取不同的测试策略。

1. 测试这个项目或者本次迭代或者某个功能模块是一个什么样的测试目标/li>
2. 如何去组织本次的测试，来实现这个目标br> 2.1 对发现一个bug有一个什么样的重视程度br> 2.2 什么样的bug重要性比较高br> 3.3 你对你的工作文档编写细致到什么程度/li>

普通商业软件项目前期

目标

• 普通商业软件项目前期，功能随时会改，因此不用纠结各种细节，主要目标验证需求是否有重大逻辑错误，比如走不下去，自相矛盾的业务逻辑
• 评估下风险，每个模块测试下，看看那个模块问题高发，那个模块进度不理想
• 测完给出模块的当前质量状况，bug数量及严重度、当前进度 告等
• 前期不要抠细节，没有意义可能还会影响后期进度。

组织

1）正常流程 2）可选流程 3）异常流程

前期尽量进行探索性测试，也就是不写case尝试找找bug。

发现bug的重视程度

1. 一开始发现的bug严重程度较低，但是开发一直没有修，到后期需要调整严重程度。
2. 更重要的是对发现的bug做出分析，指出团队在人员安排，项目进度等方面的风险。比如一开始进度缓慢，bug量极大风险

什么样的bug严重程度高

毋庸置疑，走不通，自相矛盾的业务逻辑，项目前期比较容易发现这种需求定义上的错误。

文档细致程度

如果需求一直在改，则测试用例等不用太细，但是测试 告尽量细化。

普通商业软件项目后期

目标

1. 功能稳定后，抠一些细节，充实bug列表
2. 主要目标：回归测试验证新功能改动有没有影响原有已开发完成的功能
3. 给出完整的测试 告或者质量状况评估，以供领导决定是否可发布作参考。

组织

后期尽量多做回归测试，来验证新改动有没有影响之前做好的功能，

发现bug的重视程度

看情况把bug分为影响发布的bug和不影响发布的bug
作为测试人员，不要擅自决定哪些bug不影响发布，需要给出一个bug列表，和项目负责人讨论。让领导决定。如果没人能拍板一个bug影不影响发布，我们就默认这个bug会影响发布。

文档细致程度

测试 告需要细致，并且频繁 告

测试主要原则：事实求是，具体问题具体分析

以上学习内容来自挺哥