测试用例的设计思路
接到提测单后要做的事情：
- 确认提测单内包含的文件、URL地址可以访问
- 确认需求 (迭代目标、用户故事、用户愿望、问题反馈等)
- 确认回归测试范围、更新测试范围、新增测试范围
- 编写测试点思维导图，过程中有问题及时进行沟通
- 与迭代相关人员约一个时间, 开内部的测试点评审会
- 根据评审通过的测试点, 编写测试用例 (如果迭代已提测, 可以写用例和执行同步进行, 以提升测试效率)
- 执行测试用例
常规的八个用例设计方向：
- UI界面 : 界面布局、排版是否符合UI设计师或产品需求, 文字, 图标大小。比如: 点赞按钮的位置, 点赞人的名称文字显示, 点赞红星图标, 点赞个数。
- 易用性 : 操作简单, 操作是否有友好提示, 如果是输入框 (是否支持Tab、Enter等快捷键)。 比如: 点赞后有提示, 点赞流程简单, 点赞入口。
- 兼容性 : 不同手机、浏览器、操作系统版本, 软件版本, 分辨率, 显示正常且功能正常。比如: 平板, 小米, 华为, 微信客户端。
- 功能测试 : 场景+流程 (用户可能执行的操作, 业务流程) + 新增改查删除+排序。比如: 点赞别人的朋友圈 (朋友点赞我的朋友圈), 点赞成功, 取消点赞, 点赞是否看到共同好友, 删除朋友圈, 删除点赞, 点赞的排序。
- 接口测试 : 接口正常调用, 返回报文正常。比如: 点赞接口调用, 参数 (后端)。
- 弱网测试 : 断网、网络信号差, 操作的时候来电话, 4G/5G 网络切换。比如: 打电话的时候点赞, 断网点赞。
- 性能测试 : 使用该功能的响应时间是否在需求规定的时间, 多次快速操作。比如: 点赞到显示点赞的响应时间, 点赞后好友消息更新的速度, 同时点赞, 多次点赞。
- 安全测试 : 客户端和服务端都需要验证 (不能单单是在客户端验证), 涉及手机号、身份证、银行卡、密码等敏感信息是否加密。比如: 点赞是否泄露用户信息。
编写用例时点注意事项如下：
- 用例能被别人轻松地阅读、理解和执行
- 用例要紧密联系测试点
- 要在 预期结果 中与测试点完成闭环
- 存在代码时, 代码放 前置条件 里定义好, 再放 操作步骤 里引用
- 存在特殊需求或情况时, 需要在 备注 里详细说明
- 存在多团队或组织时, 需要考虑测试对象在多团队或组织下的检查
- 如果测试点为代码配置项时, 避免贴大段代码, 应该突出配置项及其关联
- 如果测试对象可以重复, 需要根据其重复规则设计测试场景
- 如果测试点关联或支持多类型、多场景时, 拆成多条用例来写
- 编写 用例标题 时
- 以
：分隔, 前面写模块、属性或路径, 后面写测试点 - 多条用例有大量重复内容时, 需要说明它们之间的差异点
- 以
- 编写 前置条件 时
- 首先保证 操作步骤 的正常执行, 不能有冲突
- 其次要明确边界, 刚好能完成 操作步骤 即可
- 编写 操作步骤 时
- 要突出测试点, 非测试点放在 前置条件 里一笔带过
- 当 步骤描述 包含多项检查时, 在 预期结果 中应给出多项结果
- 当 预期结果 里包含文本检查时, 需要考虑多语言的场景
- 当 步骤描述 只有单行文本时, 不用有序或无序列表
- 编写用例内容时
- 包含专业或难理解的词汇时, 补充简单描述或添加文档链接
- 包含
uuid、id等动态数据时, 用参数描述指代 - 包含多个测试对象时, 可以用 “A～Z”、“a～z” 或数字指代
- 包含有序列表时, 数字后应用
.而不是其他符号 - 当同一个页面有多个入口时, 固定一个入口作为路径, 避免模糊不清
- 编写前端UI组件的测试用例时
- 用例内不能依赖设计稿、开发或自己的Demo，要做到只看用例就能测试
- 如果必须要引用外部内容，可以用文件或图片以附件形式贴到用例里
- 验证测试点的组件属性或事件要明明白白地写在用例中
- 在文档不明确时，用别名代替属性或事件，待文档明确后再修改别名
- 条件允许时，贴上组件属性或事件的配置代码，让用例有较强的可执行性
- 根据测试点是否复杂，来控制用例的颗粒大小
- 复杂时，设计多条用例实现
- 简单时，在一条用例中，将组件属性或事件变成参数，并在步骤中修改参数