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