测试基础 工作总结(功能测试四星期)

yuyu · 2022年05月26日 · 最后由 KuangKKK 回复于 2022年06月07日 · 5577 次阅读

关于编写测试用例的注意事项:
1.编写的测试用例可以几乎代替需求文档和原型,测试时只需要看测试用例表
2.不能用产品的思维写测试用例,要用测试人员的思维进行编写(这方面有待加强)
3.关注上下节点的流程,这一操作结束之后,哪些用户会有联动效果
3.列表页面的字段都需要写出来,页面的每个字段都需要写出来,数据走向
非常感谢师父的教导!!!

共收到 9 条回复 时间 点赞

第四点要写数据走向这个挺不错的,你有个好师傅。

开始写总结是持续进步的开始,继续加油~

加油,继续更新啊。我也是小白

加油,向你学习

学到了,可以分享些案例吗,
目前写完每次去执行的时候就发现有些不足,但是回头重新去梳理划分时又感觉难以拆解。比如一个功能下,不同场景单独列出来,然后该功能具体的测试点又单独列出来,但是测试时需要根据这些组合一起去标注。
我这边是用 xMind 去写,写个大纲感觉还行但具体感觉写不出来

凝视 回复

分享下个人的做法,仅供参考哈~
1.设计用例前,对被测业务流程/业务场景要有一定了解,对需求文档/原型图要做深度剖析,提取被测点;
2.设计用例的工具不限,Xmind 也好,Excel 也罢或是其他用例管理工具,把控好用例颗粒度:可粗可细。比如对于一些通用功能,可以设计一版详细用例便于后期复用;
3.用例我这面分功能用例和系统用例:功能用例就是针对单独的功能点或相关的功能点,系统用例就是完整的业务流程,不同的业务场景。不同的阶段,测试关注的重点不同。
执行用例时发现不足,属于正常现象。个人理解上的偏差或出现考虑不足的情况也会出现,及时做好用例维护更新就行。

如果不是界面有复杂的业务需要明确指向的,很多测试用例可以省略。单纯把需求翻译成用例,其实个人感觉浪费时间。就像是 web 自动化和接口自动化,尤其接口自动化准备测试数据还有预期结果比较耗时,如果不是能提升很大效率,还不如自己靠手工结合工具做数据做测试。

回复内容未通过审核,暂不显示
hu 回复

你刚入行不是点? 哪儿有优越感 我只看见你有优越感 你个哈皮

写的很好 想你学习

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