转正实录｜到你来写测试用例啦～

自学的时候，我觉得编写测试用例挺简单的，
根据需求文档，逐句逐点去拆分，正向流程、逆向流程、有什么逻辑限制、什么状态允许执行……
看起来都不难是吧？
但到了实际工作，发现是我低估了写用例这件事的难度。

第一，需求过于粗略，无从下手

对于这种需求，先动手写起来吧，联想到多少，就写多少。
最怕的是，自己在内耗，时间白白浪费，结果一个用例没写出来。

我的做法是，每个需求，建一份文档，主要记录3类事情：

1. 需求基础资料，包括需求文档、原型图、相关测试指引、关联数据库表、注意事项……
2. 需求疑问点
3. bug记录

通常是边写用例，边记录自己的疑问点，
一般需求会有原型图，问题描述时，最好能附图，有利于产品定位你的疑问。
尽量不要打断自己编写用例的思路，保持连贯性。
分阶段把整理好的疑问点，发给产品给你答复：

• 可以积累到一定数量发，例如积累到10个疑问点，先发一波给产品
• 可以按时间划分，例如2天时间写测试用例，那么第一天结束前，先发一波，而不是拖到最后一天来发
• 认为某个疑问点不解决，无法写下去，那就马上把这个问题发给产品给你答复

第二，担心写得不全面

写用例，很难做到面面俱到。
所以，才需要进行用例评审，产品、开发有时能给你些新的视角，从而完善测试用例。
作为转行测试的新人，不要轻易否定自己，先大胆做起来。
更好地去适应测试工程师这个新角色，并且把这个角色做好。
针对这点，我的建议是：
首先，如果产品经理的需求有输出流程图，那你就根据需求描述来捋顺整体流程。
如果没有，你自己得输出一份简略的流程图，根据每个流程节点发散思考来写用例。
其次，向你的导师、同事，了解这个需求有什么核心关注点，是否跟其他需求有关联。
最后，写完用例后，邀请导师和同事来帮你过一下，看看有没有遗漏。

今天分享到这里，有疑问的可以告诉我~
加油~