测试用例书写规范
其他
2020-01-30 17:47:02
阅读次数: 0
- 用例的拆分与划分
较大的功能建议拆分成不同的用例文件，方便查阅和加载
同一应用下，按照产品拆分如：工作流，多租赁
同一产品下，按照功能模块拆分，比如登陆，表单，列表，搜索表单
功能下，不可拆分用例，可以分层书写用例，可按照不同的功能点做分层 比如打印功能，可分功能点为打印默认详情页和指定详情页
功能点下，还可以再按照场景书写，比如打印功能，可分功能点为打印默认详情页和指定详情页，详情页按照场景分又分成只有主对象的详情页和有主对象有相关对象的详情页等诸多场景
- 用例的粒度
一个功能一个正常流程，编写一个测试用例；
一个功能中多个异常流程，应分开编写多个测试用例；
同一功能不同入口，可合并编写一个测试用例；举例 多个地方，相同的用例，
同一功能不同数据准备，应分开编写多个测试用例；
除了功能，UI样式，交互，兼容性测试等，也是同样的要求
项目中的术语，自己起名的术语 ，大家承认的术语，要有解释下，起名的重要
- 用例内容编写最基本的要求
具有清晰名称、前提条件、操作步骤、期望结果的
可被他人理解的
可被他人执行的
减少不必要的分层
根据需求，转化成可执行的用例，不可照抄照搬需求原文
有特殊验证数据的，需要书写数据内容
不确定的用例，可标记，在测试中确定补充（如使用的是开源组建，看原组件的支持程度；提示信息等）
不要写疑问句，要写肯定句或者否定句
不要写特别长难以理解，逻辑复杂时可拆分层级
如果过程中需求有变更，测试用例必须及时更新评审
- 建议
按照测试的逻辑写测试用例即怎么测就怎么写，如果是一连串的操作，但是按照模块划分或者其他情况，要把两部分用例拆开测试，可以在写用例时做好标记在梳理思路和测试时，两个模块合并测试，而不是生生断开
需要测试可见的页面，也要注重内在的逻辑，而不是围绕页面测试
发布了14 篇原创文章 ·
获赞 0 ·
访问量 2486
转载自blog.csdn.net/weixin_44232308/article/details/89607847
