测试计划、测试设计、测试执行

草帽路飞UU

测试计划
　　最近在一个接一个的做项目，每做一个项目都有不同的感受，我想按照测试计划，测试设计，测试执行三个方面梳理一下，和大家谈谈感受 。

　　最初做测试计划的时候会根据测试工作量来估评测试时间和资源，然后对三轮测试的时间点做一个细分。可是随着经历越来越多的项目，感受到这样计划是远远不够的，为了避免后续的测试执行工作节外生枝，我们在做测试计划时就必须多想一点，不光要多想还得想细致了。下面我谈一下项目计划中存在的风险，因为整个计划中有很多模块都是模板制定的，只有风险这一块需要经验积累才能识别更多，谈到的还是不很全面的，和大家交流交流。

　　1.提交应用测试的前提保证

　　这里说的提交应用测试的前提保证是指提交测试的时间，和提交测试的质量保证，如果说项目中开发新人较多，或者说项目属于改造重构性质的，这个能否按时按量提交测试是更需要关注的，那么面对这样的风险我们如何做好计划呢？

　　首先是在开发提交测试之前就需要pm整理出自测场景表单，然后我们评估是否有遗漏。那么对于这个是否遗漏又该如何把控呢？基本上是项目中每个模块中的主功能点必须进行自测。

　　其次需要和pm及时沟通，询问现在项目是否存在这样的风险，如果pm说按时提交测试确实有，那我们听下pm的打算并可以根据具体情况给出我们的建议，然后一定要求开发按照自测表单上的场景自测完全。2.测试过程的保证

　　大部分项目在测试过程中都是按照三轮模型来执行，可是具体细节会根据项目性质的不同而不同。比如说有的项目涉及第三方，那么你在计划中就必须考虑到第三方合作伙伴那边出了问题该如何解决，找谁解决，同时需要注意解决方式，这里建议大家在和第三方合作的时候用邮件来说明问题并抄送合作方的老大，这样解决问题比较有效率。如果项目中涉及多条产品线，那么计划中就需要考虑到产品线合作间的划分问题以及依赖关系等等。

　　在做测试计划时就尽可能的将会发生的问题想到，并评估该风险发生的概率，事先想到缓解措施，那么你在后期的项目执行中才能有条不紊的按计划进行。

　　记得上次培训的时候老师也说过用户经验的积累是最有价值的，我现在感觉能很好很全面的做出计划也是很有价值的。

测试设计

　　从刚开始做测试起，接触的设计就是先以rose整理出流程图，必要时还需要用到子流程，从而一点点的将功能点的逻辑整理清晰，形成自己的思路，再转换成用例。可是后来渐渐做了几个项目之后，就感觉出问题来了。

　　1. 常常比较细节的点在流程图中体现不出来，从而设计过程中没有关注它，或者说仅仅只是想到那些细点，到写用例的时候才发现就这个细节上还有很多东西需要去确认。

　　2. 流程图中仅仅体现了是和否的逻辑，对于那些数据或者条件的多样性很难表现出来，到写用例的时候还是需要用表格或者在草稿纸上罗列一下。

　　于是再后来做测试设计就会先通过流程图来整理业务逻辑，而后再用excel来补充细节校验和场景罗列，这样做了几个项目之后又有问题了。

　　excel表格比较零散，针对某个功能点的校验，比如说边界值等等的融合会显得清晰很多，但是整个业务功能来说感觉还是不能串起来。模块之间的关联还是显得不够紧密，尤其是这样的一个个独立的excel使得细小的点太分散，存在很多重复劳动。

　　再后来做一个项目的时候尝试了一种新的方法，完全用excel做设计，不能说是最好的，但是感觉比设计比以前做的更清晰少遗漏了。这个方法是以用户的行为路径为主导，结合项目的业务逻辑来制作excel表头，其中表头还包括数据账号，预期结果，存在的疑问等等信息，这个是最难做的，需要头脑里有一个流程的概念，然后根据表头下面的业务逻辑进行条件细化，最后在各种条件下进行组合，整个excel会很庞大，但是连贯性比较好，而且非常方便的写用例，可以说接下来写用例完全没有什么难度。

　　这个方法我还在实践中，它当然也存在缺点，就是新人来看excel的测试设计没有看流程图的excel设计容易理解，而且这个设计方法对业务的熟练程度是有一定要求的，接下来的项目我会继续使用这样的方法，慢慢体会好与不足之处，一点点的做的更好。

测试执行

　　带过多次项目之后越来越觉得测试执行是最能体现团队合作和管理控制能力的。当然，前期的测试计划做的周全对测试执行帮助是很大的。但是常言计划赶不上变化，而且测试计划是从大局观来说的，执行过程中是每天的一个活动，所以常常在执行阶段还需要好好的把控。我习惯性是这样做：

　　1.前期做好约定

　　对用例执行pass和failed进行一个约定，可能很多人会觉得多此一举，和测试用例的预期结果一致就pass，和结果不一致出现bug就failed 呗，这还有什么好约定的，其实细细想一下，在执行过程中会不会遇到多个用例都是因为其中一个功能点的校验不通过而failed呢？如果这个功能点比较独立，不影响测试流程，开发在修改的过程中我们继续执行，是将这些用例都因为这个功能点不通过而置为failed呢还是将其中一个用例failed提一个 bug，将其他用例pass呢？我个人觉得两种方法都可以，可是事先需要做一个统一约定，大家都按照同一个方式去处理问题，后续负责人统计需要重新执行的用例量时也是非常清楚，方便评估的。

　　如果某个功能点不好影响测试进行的时候，测试人员是将受影响用例置为failed呢还是让它弄no run呢？其实这个也不存在谁对谁错，只是前期如果不提出来约定一下的话，恐怕每个测试人员有每个人的习惯，那么测试负责人从QC中分析执行情况以及项目进度时就不能获得比较准确的信息。

　　2.分阶段来细化每天工作量

　　前期做好约定之后，再每一个阶段开始的时候需要做一个工作量预估表，细化到每天的工作量，这使整个测试过程能更好的得到保证，比如在第一轮测试将开始的时候就根据执行的用例数和工作日做一个预估，第一轮计划是执行5天的话，那么第一天大家测试可能不会那么顺利，需要预估少一点的工作量，在后面的测试中需要抓紧时间多执行一些用例，第一轮接近尾声的时候需要预估少一点的工作，因为交接是或许遇到一些问题，这期间少一点任务能给留出一些时间冗余没想到的风险和困难。

　　另外，象这样预估好每天的工作量，可以和实际完成的工作量进行对比，可以尽早知道测试进度是正常还是延期，提早控制好风险。

　　最后，从对比的结果可以分析出整体的测试计划是否做的合理，总结经验教训，逐渐成长。

　　当然，测试过程中还是需要及时调整的，对于这块就只能意会不能言传，大家慢慢体会吧，我以后还有心得再和大家分享。