测试基础 用例设计方法怎么用?

阿根 · 2022年08月03日 · 最后由 简11 回复于 2022年08月12日 · 3529 次阅读

今天遇到一个需求,就是打开开关,出现入口,点击入口出现弹窗,弹窗输入回显。我开始针对各个输入框按钮设计用例,但是设计完,我自查的时候还是有很多漏洞,突然想起有流程分析法好像比较适合这里,但我发现我居然不怎么会这个方法。突然想起,平时自己写用例好像一点也不按方法来,基本就是对输入框和按钮的无脑写用例,但这样的用例现在想起来真的太简单了,很多情况都没考虑。不知道大家有没有什么想法?或者对这些用例设计有什么心得?

共收到 9 条回复 时间 点赞

不能仅仅对着操作写用例。试着从这个需求的实现价值开始,想想为什么会有这个需求,用户在什么场景下会用,后台是如何实现的等等方向去思考。

https://testerhome.com/topics/33655 这里有具体的场景和案例,可以参考下。

我的习惯:
1、先通过了解需求内容、技术方案,确认各个部分的优先级以及可能存在的质量风险
2、设计测试策略,包括各个部分重点需要保障什么,除了常规的功能测试是不是还需要其它类型的测试引入(如常见的性能测试、兼容性测试)
3、根据测试策略写用例。先把核心流程的用例写出来(同时也是冒烟用例),然后再按各个模块的优先级扩展异常场景。扩展异常场景过程中会通过边界值、流程分析等方法去弄(实际上也不会说每个都去按着方法逐个弄,已经形成一些思维定式了)
4、通过组内的用例评审,集思广益,补充一些可能存在但编写时遗漏的用例。

对于如何更好地去设计用例,避免遗漏,我的经验是:与其想着用各种分析法,不如多做交流和总结,逐步形成自己的思维定式。建议你们团队内可以试试搞一些活动,活动上大家对同一份需求设计用例,然后各自分享思路,促进一起成长。

CKL的思考 回复

技术层面还差的有亿点远

陈恒捷 回复

确实集思广益也是不错的方式,但是现在任务项太多了,都让大家来评,时间上不允许。

阿根 回复

如果公开的活动排不了,那就日常私下多相互交流学习吧。

1、分析用户场景,可采用 5W1H 模型展开(理解需求对用户的价值,把握核心操作场景)
2、业务需求细节分析,可用 viso 画图(流程图,IPO 图都可),如业务操作流程(业务流)
3、梳理数据流,需理解软件的设计实现,例如:楼主提到打开 开关,用户是一个点击操作,此时对应软件可能是一个消息,此消息触发后面的代码,此时是否有数据的变化,如把背后的配置文件给改变了;弹窗提示有哪些信息,这些信息内容从哪里读取,如是否增加了字符串,这些字符串来自哪里,如果有多语言,其他语言的显示是否正确?弹窗存在与用户的交互吗,交互的数据,如用户输入后的数据回显,是保存在什么地方呢。
抓住业务操作流、数据流,再以各节点为分支展开分析,可得出可能对系统其他模块的影响(其输入、输出与其他功能的关系)。

想看看大家是怎么做的

简11 回复

这种细节分析确实好想法。但是我们这边测试看不到代码,所以数据层面测试不好分析,只能根据现象写用例。

阿根 回复

理解软件的设计实现,不一定要看代码,建议自已先想想,例如:假设你来实现此功能,在现在的产品平台上,你会如何设计,然后把图画出来,主动找开发人员讲讲你的思路,请教他哪里想得不对,此时,他应会告诉你他实际的设计是怎么样的。当然,如果有设计方案,拿来先看看更好。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册