最近在一个接一个的做项目，每做一个项目都有不同的感受，我想按照测试计划，测试设计，测试执行三个方面梳理一下，和大家谈谈感受 。
最初做测试计划的时候会根据测试工作量来估评测试时间和资源，然后对三轮测试的时间点做一个细分。可是随着经历越来越多的项目，感受到这样计划是远远不够的，为了避免后续的测试执行工作节外生枝，我们在做测试计划时就必须多想一点，不光要多想还得想细致了。下面我谈一下项目计划中存在的风险，因为整个计划中有很多模块都是模板制定的，只有风险这一块需要经验积累才能识别更多，谈到的还是不很全面的，和大家交流交流。
1.提交应用测试的前提保证
这里说的提交应用测试的前提保证是指提交测试的时间，和提交测试的质量保证，如果说项目中开发新人较多，或者说项目属于改造重构性质的，这个能否按时按量提交测试是更需要关注的，那么面对这样的风险我们如何做好计划呢？
首先是在开发提交测试之前就需要pm整理出自测场景表单，然后我们评估是否有遗漏。那么对于这个是否遗漏又该如何把控呢？基本上是项目中每个模块中的主功能点必须进行自测。
其次需要和pm及时沟通，询问现在项目是否存在这样的风险，如果pm说按时提交测试确实有，那我们听下pm的打算并可以根据具体情况给出我们的建议，然后一定要求开发按照自测表单上的场景自测完全。
2.测试过程的保证
大部分项目在测试过程中都是按照三轮模型来执行，可是具体细节会根据项目性质的不同而不同。比如说有的项目涉及第三方，那么你在计划中就必须考虑到第三方合作伙伴那边出了问题该如何解决，找谁解决，同时需要注意解决方式，这里建议大家在和第三方合作的时候用邮件来说明问题并抄送合作方的老大，这样解决问题比较有效率。如果项目中涉及多条产品线，那么计划中就需要考虑到产品线合作间的划分问题以及依赖关系等等。
在做测试计划时就尽可能的将会发生的问题想到，并评估该风险发生的概率，事先想到缓解措施，那么你在后期的项目执行中才能有条不紊的按计划进行。
记得上次培训的时候老师也说过用户经验的积累是最有价值的，我现在感觉能很好很全面的做出计划也是很有价值的。
测试设计
从刚开始做测试起，接触的设计就是先以rose整理出流程图，必要时还需要用到子流程，从而一点点的将功能点的逻辑整理清晰，形成自己的思路，再转换成用例。可是后来渐渐做了几个项目之后，就感觉出问题来了。
1. 常常比较细节的点在流程图中体现不出来，从而设计过程中没有关注它，或者说仅仅只是想到那些细点，到写用例的时候才发现就这个细节上还有很多东西需要去确认。
2. 流程图中仅仅体现了是和否的逻辑，对于那些数据或者条件的多样性很难表现出来，到写用例的时候还是需要用表格或者在草稿纸上罗列一下。
于是再后来做测试设计就会先通过流程图来整理业务逻辑，而后再用excel来补充细节校验和场景罗列，这样做了几个项目之后又有问题了。
excel表格比较零散，针对某个功能点的校验，比如说边界值等等的融合会显得清晰很多，但是整个业务功能来说感觉还是不能串起来。模块之间的关联还是显得不够紧密，尤其是这样的一个个独立的excel使得细小的点太分散，存在很多重复劳动。
再后来做一个项目的时候尝试了一种新的方法，完全用excel做设计，不能说是最好的，但是感觉比设计比以前做的更清晰少遗漏了。这个方法是以用户的行为路径为主导，结合项目的业务逻辑来制作excel表头，其中表头还包括数据账号，预期结果，存在的疑问等等信息，这个是最难做的，需要头脑里有一个流程的概念，然后根据表头下面的业务逻辑进行条件细化，最后在各种条件下进行组合，整个excel会很庞大，但是连贯性比较好，而且非常方便的写用例，可以说接下来写用例完全没有什么难度。
这个方法我还在实践中，它当然也存在缺点，就是新人来看excel的测试设计没有看流程图的excel设计容易理解，而且这个设计方法对业务的熟练程度是有一定要求的，接下来的项目我会继续使用这样的方法，慢慢体会好与不足之处，一点点的做的更好。
