重庆市建筑网站建设新闻热点最新事件

工作当中,总会有人为自己的测试用例写得不够好去找各种理由,时间不够是我印象当中涉及到最多的,也是最反感。想写好测试用例，前提是测试分析和需求拆解做的足够好，通过xmind或者UML图把需求和开发设计提供的产品信息提炼出来。

我个人的提炼标准一般是：

·所有业务链路是否是闭环；

· 所有业务场景以用户层面来观察是否合情合理；

· 技术设计是否存在性能/可靠/安全等风险；

· 梳理测试要点，明确每个业务在测试环节里面需要观察的功能预期；

· 开始明确测试方案，确认列出来的测试要点要怎么样才能实施测试。这里多问自己一句：只做功能测试能满足质量覆盖的要求吗？不能就扩展考虑是否做白盒测试/接口测试/性能测试/稳定性测试/安全测试/体验测试/…；

· 然后才进入测试用例编写的阶段，通过对测试点的特征评估考虑用哪种测试用例设计方法覆盖；

· 最后输出用例。

在这里,我想说说我对用例的个人看法：

1.用例不仅仅只是为了满足功能测试，它应该是通过一组输入输出的方式用来衡量产品功能是否符合预期。

2.测试用例不可能永远只被设计者执行，所以请严格按照规范来设计和编写用例，让其他后继的执行人能高效准确的执行。

3.用例设计是极其严肃的任务，但是业内很少QA会真正的做到根据被测试对象的特征来挑选测试用例设计方法并严格按照这些方法来输出用例。

所以,不要说什么时间不够来不及，假设有一天你去了一个时间充足对质量要求极高的测试岗位，你能保证最细的测试颗粒度是多少？做测试要知道自己的上限在哪里，因为绝大多数的质量问题不是因为时间太少，而是测试眼界不够高，想得不够多，做的不够好。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

 

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取