如何设计测试用例

susanml 测试交流1 83字数 1530阅读模式

测试用例是业务测试过程中测试者的生命线。
在大需求面前无从下手测试时,测试用例是测试者对全盘概念的梳理和深度探索;
在测试过程中碰到任何问题阻断测试场景或思路时,测试用例是测试者的执行指令和方向盘。
当需求文档及对应的需求技术方案产出时,测试者需要根据提供的文档对需求进行解构,解构出需求的原子内容后,再进行测试用例的设计,而测试用例即需要考虑测试验证的全面性又需要考虑测试的深度。那么,这就需要测试人员进行全方位考虑来构建测试思路和使用什么样的测试策略和方法来尽可能保证测试覆盖的全面性。

试问,当面对一个大型需求(此处是指需要花费至少 2 个迭代才能完成的需求),测试人员需要有什么样的测试用例设计思路才能达到高时效、高人效、全面的做到测试覆盖呢?文章源自玩技e族-https://www.playezu.com/182109.html

测试用例设计核心

重要程度

测试用例的设计首要考虑的是主流程场景(一定要搞清楚需求的背景及需求是为了解决什么问题而产生的),主流程包括:
1. 测试用例的设计围绕产品需求文档的描述进行设计
2. 测试用例的设计场景是否符合实际用户的使用场景
在主流程中,把握测试用例的优先级,能够尽早在测试过程中发现严重问题,尽早暴露问题文章源自玩技e族-https://www.playezu.com/182109.html

等价性

测试用例的设计需要根据开发的实现逻辑去设计,黑盒测试可能存在设计的多个测试用例间存在无效测试用例的情况,比如有些交互场景中,存在表单中有多个填入项,如果测试者设计时,将每个输入项都作为一个测试场景去设计,而不了解实现的话,那测试用例将呈指数增长,必定会存在很多无效测试用例。当然,此处的比喻比较极端,但测试者需要有这样的意识,去把开发侧实现的逻辑分支梳理清楚,防止产生垃圾测试用例的情况。文章源自玩技e族-https://www.playezu.com/182109.html

边界性

测试用例的设计涉及到功能模块间的交互,既然涉及到交互那必然存在边界。测试者需要明确该需求的上下游,该需求有几个入口和几个出口。文章源自玩技e族-https://www.playezu.com/182109.html

基于以上几点,作为设计测试用例的核心思想贯穿整个测试用例编写过程,再配合测试方法,你的脑海中将呈现一个需求完整的骨架,那么测试者对质量的把握度会大大提升。文章源自玩技e族-https://www.playezu.com/182109.html

测试点

主流程

主流程,即需求中说明的所有功能点场景,这里是测试的重点,也是冒烟测试去检查提测质量的重要手段。文章源自玩技e族-https://www.playezu.com/182109.html

分支流程

主干逻辑以外的分支逻辑场景。文章源自玩技e族-https://www.playezu.com/182109.html

异常流程

数据异常:如关键数据缺失、数据重复推送
调用链异常:如业务调用链路异常,系统的处理
常见异常有:文章源自玩技e族-https://www.playezu.com/182109.html

  1. 依赖服务不可用,是否有降级处理,是否有监控告警?
  2. 依赖数据缺失,是否 catch 异常,确保程序不 crash,并产生 error 日志?
  3. 服务重启,是否容错?
  4. 基础组件服务异常,如 redis、kakfa、mysql 等异常,是否丢数据,基础服务恢复以后,能否恢复服务?

UI 测试点

  1. 风格、样式、布局
  2. 校验:必填、选填等
  3. 显示是否有遮盖和不合理的省略情况
  4. 提示语是否友好
  5. 等等(此处可对不同项目的 UI 关注点进行补充)

向前兼容

针对对已有的需求进行改造时,需要考虑接口或者 GUI 上的向前兼容。文章源自玩技e族-https://www.playezu.com/182109.html

关联功能

需要评估该需求是否会影响到已有功能,比如:代码中对公共模块的改动。文章源自玩技e族-https://www.playezu.com/182109.html

历史数据影响

需求改造是否需要对历史存在的数据进行处理?如:已有表结构更改等。

性能影响

这里指的性能影响比较简单,如:接口响应速度(大数据量的查询、高并发访问等)、GUI 的渲染速度(大数据量时的渲染)作为基本的性能达标指标;
对于系统最大的业务处理能力、处理速度等性能表现,需要另起一个大话题来说了。

终端兼容性

若产品支持:PC、小程序、APP 端等多个终端,需要在多终端验证功能可用性。

安全性

业务数据安全:如,重要数据非明文;
业务场景安全:如,绕过登录验证、交易中的数据篡改、接口的恶意调用等

以上设计测试用例的思路和方法是个人工作经验中的沉淀和总结,属于个人浅薄之见,但应该对测试新人有一定的参考作用,同时也希望业内精英能够发现不足和缺陷,提出改进意见。

软件测试自学

 
  • 版权提示:本站仅供存储任何法律责任由作者承担▷诈骗举报◁▷新闻不符◁▷我要投稿◁
    风险通知:非原创文章均为网络投稿真实性无法判断,侵权联系2523030730
    免责声明:内容来自用户上传发布或新闻客户端自媒体,切勿!切勿!切勿!添加联系方式以免受骗。
  • 原创转载:https://www.playezu.com/182109.html
    转载说明: 点我前往阅读>>>
    • AllisonLiu
      AllisonLiu 9

      有好的意见和建议,欢迎留言交流哦~~安全性,业务安全:重要数据非明文;登录验证的绕过、交易中的数据修改、接口的恶意调用等这个分类有点乱,建议按照通用分类,测试类型 + 测试方法,重新组织下。
      若产品支持:PC、小程序、APP 端,需要在多终端验证产品可用性。
      比如这个兼容性,只是终端兼容性,“兼容性” 还包括很多细分内容。嗯嗯,收到建议~我准确描述下更改为 “终端兼容性”感谢补充,这一点我补充进去1.分类不太好理解,建议根据共性与差异,总结归类再抽象一层,例如:一、用户场景 二、功能测试 三、兼容性 四、性能 五、性能
      2.根据上面类别,再增加测试点

      采用结构化(可以提取为业务测试结构树)方法,这样对于新人,及项目间的复用更好。

    匿名

    发表评论

    匿名网友
    确定