做完XXX2.0项目，想起了一个比较初级的问题，测试计划与测试方案的区别，大致印象测试计划重要包括测试范围、测试时间、测试资源分配、风险评估等，测试方案主要是测试策略、测试方法等等。就不多谈两者的区别了。

　　测试计划，我们会在项目前期产出，不多说。测试方案中很重要的就是测试策略。运用到实际项目中，测试策略体现在哪里？个人认为，三轮测试就是一种比较通用的测试策略。基本上全部项目都可以套用这种测试策略，但是将3轮测试的测试策略直接运用到项目中作为测试策略，太广了，需要细化。讲一下现在想到的测试策略中的几点吧。

　　1. 用例的执行策略。

　　测试用例的执行测试，主要受2个因素影响，1.项目的性质，2.项目资源（时间资源、人员资源）。项目的性质不同，资源投入不同，策略也会有所区别。具体来讲，就是根据项目的性质，时间周期的长短，投入人力资源的多少，以及人员情况（新人、老人、熟悉业务的、不熟悉业务的等）等因素，制定冒烟测试、第一轮、第二轮、第三轮、合并主干测试、预发布测试、正式上线验收测试，由谁执行哪些测试用例。在3轮测试中，每一轮都需要执行测试用例。但是很多项目由于项目时间紧，无法保证3轮测试每一轮都可以完整执行全部的测试用例。需要提前规划好每轮测试的用例执行策略。

　　比如某项目，主要是页面改动，功能改动不大，而时间又很紧，可以指定这样的用例执行策略：冒烟测试：执行P1级测试用例，保证主流程跑通。第一轮：执行全部测试用例，以免有我们不知道的功能改动点或者影响点。第二轮，执行P1+P2+P3的测试用例，以及第一轮中field的测试用例。该项目为界面改版的项目，对于边界值啊、必填项啊这类细节点影响是不多的，且在第一轮中也已执行一遍，在第二轮中仅跑一遍流程，如果时间过紧，甚至可以只执行P1+P2，一定保证足够的时间可以进行随机发散测试。第三轮测试，主要是回归测试，如果时间充足，最好执行全部测试用例。但如果时间无法保证，可以执行 P1+P2+P3，以及前2轮中field用例，用例所在模块的用例。合并主干回归测试，P1+P2的测试用例。我们每一轮都会把流程规则的用例走到，确保不会有严重问题。预发布测试，由于数据为线上真实数据，会对线上有影响，需要规划出是否需要制定出一套独立的适合线上测试的用例。线上验收测试，基本和预发布测试同理，测试的范围可能会更小一些。

　　2. 交叉测试策略。

　　通常情况，项目会投入至少2名测试人员，测试人员会重点负责一部分功能。为了减小视觉盲点，会进行交叉测试。那么在什么阶段进行交叉测试？如何进行交叉测试？也是测试策略的一部分。比如，我们可以选择，在第二轮开始交叉测试。如何进行交叉测试呢？测试人员会在制定测试计划时变进行了任务分工，之后，测试人员会最关注自己相关功能的业务，对其他人负责的功能，了解的会少一些，在交叉测试时，如何使不了解这个业务的同学，能够很快熟悉业务呢？其实这个问题并不难，刚好可以用上面用例执行测试策略的例子说明。在第二轮测试时，我们还是需要执行流程性测试用例的，在第一轮测试用例执行后，用例均已被梳理一次，哪些用例需要改动，已经清晰。负责这部分测试用例的同学在执行用例时，及时确认是bug还是用例问题，及时修改用例，以及测试用例的补充。这样，第二轮测试时，便可以由其他不熟悉业务的同学来执行用例，熟悉流程和业务规则。

　　3. 兼容性测试策略。

　　兼容性测试，一般都会有自己的测试规范，哪些操作系统、浏览器、分辨率等是支持的，不同操作系统、浏览器需要支持什么程度。我们需要在制定测试策略时，规定好，对哪些浏览器执行哪些测试用例，以及，什么阶段执行兼容性测试，谁负责哪个浏览器的兼容性测试。例：在第二轮测试阶段，由A执行IE6的 P1+P2+P3+页面展现+js相关的测试用例。

　　此外，为了保证项目高效进行，可以在制定测试策略时考虑，兼容性测试是否可和交叉测试并行进行。这样，一方面便于效率的提高，减少后期冗余测试，一方面又可以保证测试完全，使后期的测试是有计划有条理的进行。

　　4. bug复验收策略。

　　上线前，我们需要对bug进行复测。可以将bug复测的工作写入到测试策略中，指点新人。例如：10月29号（第三轮执行完测试用例后）bug提交人对closed bug进行复测，项目测试负责人发送当前later bug致项目组。

　　5. 回归测试策略。

　　回归测试：第三轮测试及主干回归测试。两者均为回归测试，但是侧重点不同。第三轮测试的回归测试，主要针对程序代码是否还有bug；主干回归测试，验证合并主干后，是否对该应用或相关应用产生了影响。我们这里主要说的是合并主干的测试策略，需要考虑项目的回归任务分配，该应用的回归任务分配，可能影响到的其他应用回归任务分配，以及打分支阶段，该应用其他日常的回归任务分配。