今天遇到一个需求，就是打开开关，出现入口，点击入口出现弹窗，弹窗输入回显。我开始针对各个输入框按钮设计用例，但是设计完，我自查的时候还是有很多漏洞，突然想起有流程分析法好像比较适合这里，但我发现我居然不怎么会这个方法。突然想起，平时自己写用例好像一点也不按方法来，基本就是对输入框和按钮的无脑写用例，但这样的用例现在想起来真的太简单了，很多情况都没考虑。不知道大家有没有什么想法？或者对这些用例设计有什么心得？
不能仅仅对着操作写用例。试着从这个需求的实现价值开始，想想为什么会有这个需求，用户在什么场景下会用，后台是如何实现的等等方向去思考。
https://testerhome.com/topics/33655 这里有具体的场景和案例，可以参考下。
我的习惯：
1、先通过了解需求内容、技术方案，确认各个部分的优先级以及可能存在的质量风险
2、设计测试策略，包括各个部分重点需要保障什么，除了常规的功能测试是不是还需要其它类型的测试引入（如常见的性能测试、兼容性测试）
3、根据测试策略写用例。先把核心流程的用例写出来（同时也是冒烟用例），然后再按各个模块的优先级扩展异常场景。扩展异常场景过程中会通过边界值、流程分析等方法去弄（实际上也不会说每个都去按着方法逐个弄，已经形成一些思维定式了）
4、通过组内的用例评审，集思广益，补充一些可能存在但编写时遗漏的用例。
对于如何更好地去设计用例，避免遗漏，我的经验是：与其想着用各种分析法，不如多做交流和总结，逐步形成自己的思维定式。建议你们团队内可以试试搞一些活动，活动上大家对同一份需求设计用例，然后各自分享思路，促进一起成长。
1、分析用户场景，可采用 5W1H 模型展开（理解需求对用户的价值，把握核心操作场景）
2、业务需求细节分析，可用 viso 画图（流程图，IPO 图都可），如业务操作流程（业务流）
3、梳理数据流，需理解软件的设计实现，例如：楼主提到打开 开关，用户是一个点击操作，此时对应软件可能是一个消息，此消息触发后面的代码，此时是否有数据的变化，如把背后的配置文件给改变了；弹窗提示有哪些信息，这些信息内容从哪里读取，如是否增加了字符串，这些字符串来自哪里，如果有多语言，其他语言的显示是否正确？弹窗存在与用户的交互吗，交互的数据，如用户输入后的数据回显，是保存在什么地方呢。
抓住业务操作流、数据流，再以各节点为分支展开分析，可得出可能对系统其他模块的影响（其输入、输出与其他功能的关系）。
想看看大家是怎么做的
阿根
回复
理解软件的设计实现，不一定要看代码，建议自已先想想，例如：假设你来实现此功能，在现在的产品平台上，你会如何设计，然后把图画出来，主动找开发人员讲讲你的思路，请教他哪里想得不对，此时，他应会告诉你他实际的设计是怎么样的。当然，如果有设计方案，拿来先看看更好。
最近看《测试架构师修炼之道 2》里面的四步法挺好的，第四章内容