从需求分析到用例设计过程的分享

lsekfe

团队小伙伴跟我提，希望可以进行测试用例设计的培训，我才意识到这个比我想象的迫切，所以就想着把这事提上日程。
　　团队中有个习惯，就是我会组织大家每个月立flag，其实就是每个月给自己一个目标。
　　一、准备
　　—）讲什么
　　有了flag就有了监督，我开始考虑培训内容，翻书、找以往的培训材料等，最终，确认了我的培训方案。
　　我把这次培训定义为分享，以最近在做的一个功能测试为例介绍。
　　一些书上看得到，可以自学的测试方法，不在我的讲解范围内。一方面，这些完全可以自学和实践，另一方面，我也没有深入研究过，即使培训效果也不好。
　　那讲些什么呢，就根据一个功能，分享我进行测试需求分析到用例设计的思路。
　　二）怎么讲
　　不管是分享还是培训，我的风格就是互动，我不喜欢干巴巴的一直讲，我习惯通过互动提问的方式，让大家思考、提问。
　　那就延续互动的方式吧。
　　为了让互动效果更好，我提前3天把需求发到小组群里，并告诉大家提前熟悉和准备，中间有互动，而且可能波及所有人。
　　二、会议分享
　　正式进入分享环节。
　　一）理解需求
　　首先，我让大家用自己的话描述需求是什么。
　　为什么这么做，因为需求写的有点绕，而且，只有用自己的话描述后，才算知道这个需求是什么。
　　果然很绕，前面大家都在提问，也没有很清晰的描述出来。
　　这个不重要，毕竟开始理解需求，总会有各种问题，就是在问答过程中，不断升级自己的理解。
　　在大家基本理解之后，我给出了自己的理解，有的小伙伴还有疑问，这里需要控场，把问题记录下来不再展开，后续确认。
　　其次，统一对需求的认识。
　　在第一环每个人都表达了对需求的理解，我也给出了自己的认识，下面就是需要保证大家的理解一致，有疑问也没有关系，先按照统一的思路开启下面的环节，中间引申的问题也可以提出来。
　　是的，再次强调需求是什么。
　　二）进行需求分析
　　1、寻找关键词
　　让大家从需求中提取关键词；以便抓住重点；
　　2、寻找影响因素
　　基于需求和以往的经验，大家共同寻找影响功能中间过程和结果的影响因素，也就是影响功能的那些变量。
　　这个环节结束大家共梳理出6个变量，是的，还不全。
　　没关系，这个环节不要求全部识别，先进行下面的环节，在不断梳理过程中，大家还会补充。
　　3、寻找检查项
　　是的，检查项很重要，它会告诉你，这个功能怎样的呈现是对，怎样的显示是错。
　　这里依然是让大家共同寻找，大家有想法就说出来，我进行记录。
　　整体上，大家从外部输出和内部流程，关注到已识别的点。
　　在这个过程中，大家不断补充影响因素，最后是12条，增加了一倍。
　　4、输出用例场景
　　在开始讲解前，也让大家，基于前面的分析，分享自己设计场景的思路。
　　最终，确定的用例场景设计的思路是：
　　* 确定每个影响因素有哪些值，这里大家可以作用相关的测试方法，选取合适的值；
　　* 根据每个影响因素设计测试用例，尽量每个用例关注一个影响因素；
　　* 多个因素相互影响的场景，综合考虑。
　　别以为到了这一步，就很简单了，即使有了前面的基础，把场景设计出来也不容易。
　　因为时间关系，我用2个影响因素举例；如果遍历那就是16种场景；结合等价类的思想，那就是4种场景；结合经验和错误猜测，那就是6种场景。
　　如果你说用例场景设计是个排列组合的概念，其实也没错。
　　但怎么合适的把场景设计出来，用相对少的场景验证你所考虑的功能，这里需要业务、需要测试技术、需要逻辑、还需要经验。
　　三、收集反馈
　　分享结束后，在小组群里发消息，希望大家可以给出反馈，便于后续改进。
　　四、写在最后
　　分享前，针对这个功能，我已经把需求分析到场景设计的过程全部走了一遍了。
　　但是分享的过程，我并没有在每个环节直接给解决，而且引导大家一起思考，最终的结果确实是存在我之前没有考虑到的点。
　　也想通过这种引导的方式，让大家切身感受需求到用例的过程，掌握整个思路。
　　以上，就是这次分享的一些过程，不过重要的还是分享后的效果，所以收集反馈和根据反馈做调整很重要，后面再整理这方面的内容。