0
点赞
收藏
分享

微信扫一扫

快速编写测试用例技巧(以大数据平台为例)

在觉 2021-09-19 阅读 66
日记本

本话题暂不探讨是否有必要编写详细的测试用例(另开话题讨论),而是在确定要交付详细的测试用例这个前提下,分享如何更高效地完成的测试用例编写。

对齐测试用例需求

首先、对齐要完成的测试用例文档目标要求,模板、范围、粒度等!

快速了解产品

最快的速度熟悉产品业务背景与技术架构,从而勾勒出测试用例整体框架。任何一款产品,最终都能映射到【横向扩展】+【纵向分层】的组合模式下来完成用例覆盖。
横向业务扩展
是指产品辅平来看,总共有哪些业务场景,提供了哪些能力,即产品最上层的功能全景。
纵向架构分层
是指从产品的技术架构层面来分析,当前产品可以宏观上分为几层,以便于在用例验证是从不同层次上进行验证和用例覆盖.

E-MapReduce的横向核心业务功能全景线路图(以Hadoop集群为例),其核心流程有:Hadoop集群创建->集群管理->服务组件管理->ECS主机管理->...->Hadoop集群释放;功能全景如图1所示:

E-MapReduce的纵向核心架构分层简化为以下四层,如图2:

  • 最顶层:E-MapReduce的门户控制台界面【UI】
  • 次顶层:E-MapReduce的门户后端API【OpenApi】
  • 次底层:E-MapReduce的服务端【大数据服务组件】
  • 最底层:E-MapReduce的基础设施【云服务器】

快速制定方案

用例覆盖范围

1、 从产品业务功能全景出发,结合纵向架构层次,用例无死角全面覆盖产品(论范围)。
(1)水平方向拓宽【宽度】,围绕它的主生命周期由大模块至小模块、主功能至次要功能逐步扩展支叶,借用鱼骨图梳理(如下图3)或Xmind脑图来梳理。先梳理内部,然后梳理外部对接的服务或产品场景(如:消息中心、费用中心、告警中心、文档中心、数据开发、OSS、DataWorks等等)。



(2)横向扩展发散完成后,开始纵向挖掘【深度】,比如,E-MapReduce核心架构分为四层,每一层都需要拆开了看:

  • 最顶层:UI层端对端用例走查(如前面所述),从顶层UI操作测试除了验UI结果、还要确保底层集群服务器上的实际结果与界面显示一致
  • 次顶层:第二层是门户后端Api,直接调用OpenApi的相关测试用例覆盖
  • 次底层:直接操作使用或强干预Hadoop集群服务组件、检验整个E-MapReduce的质量;由于大数据平台上的服务组件非常多(有二三十个),除了单个服务使用外,更要多个服务常用搭配组合验证。
  • 最底层:直接操作使用或强干预ECS服务器层,检验整个E-MapReduce的质量


到目前为此,E-MapReduce整个Hadoop集群的测试用例全部范围梳理完毕。

编写用例估算

1、80条用例/每个工作日
全新的用例设计编写速度约在90条/工作日,不使用代码生成用例、也没有现成复用的用例,全部需要从无到有设计与手动编写完成。
2、一个模块平均约百条功能用例、非功能性用例是功能用例的三分之一
3、笼统估计,普通复杂度的一个子模块一天完成

用例设计方法

从测试类型出发,有功能与非功能测试用例覆盖。本次不需要交付非功能用例,因此不展开;功能性用例设计方法:

  • 等价类划分法(正等价类、负等价类)
  • 边界值分析法(边界内、边界外)
  • 判定表分析法(Google或找我)
  • 因果图(Google或找我)
  • 错误推测法(Google或找我)

用例编写原则

  • 拆分原则:
    全文制定统一的边界。比如:以模块为边界、当不同模块之间有关联互动时、预置条件作为分界线,预置条件里的内容放在上游模块验证。
  • 优先级原则:
    【创建】【查看】【使用(启停等)】【修改】【删除】为序
    【主场景】优先、【次要场景】其次
    【正例】优先、【反例】其次
  • 基础原则
    用例无重复、无遗漏,
    单一性原则、即一个用例仅覆盖一个场景
    清淅的步骤、明确的预期结果不存在二义性
    反复执行结果相同


快速编写小妙招


制定统一标准
以阿里云E-MapReduce产品为例,很多需求功能统一要求,为此设计一套标准化用例:

  • 比如: 创建新增的页面,表单输入项,需求约束统一要求(是否必填、长度限制、字符要求),设计一套标准化用例,供其他页面复用。
  • 比如:每个模块的权限测试用例,设计统一标准用例;
  • 比如:所有的OpenApi测试,都是200、400、401、403、405、500
  • 比如:大数据平台服务30多个,每个服务是不同的,但操作是类似:添加、启动、停止、修改配置、部署,为此设计统一标准用例
    (哈哈、有一种代码重构的既视感,定义一个标准的方法、供大家反复调用)

提取公共组件
以阿里云E-MapReduce产品为例,其中包含了10个以上的列表页面,对于每个列表都有分页组件、筛选、搜索、排序,这些公共组件的用例抽为【公共组件用例】,设计一套标准化用例,相关页面复用即可。
注意:统一标准用例中,可变的项用{ABC}来替换,比如:在集群查看列表中筛选集群状态时,把统一标准用例中的{ABC}替换成{集群状态}即可。

批量编写与自动生成
在用例编写过程中,发现很多情况除了{某名称或字段}不同,其它都是一样的,此时可以批量编写(如:借助Sublime或直接传变量用代码生成),这样也可以大大提高编写效率。


在编写OpenApi相关测试用例时,QA直接定义出一套OpenApi标准用例,以QA设计出的标准用例为模板,Dev协助编写代码,通过读取OpenApi的Json文件,快速生成71个Api的测试用例,共达800条详细测试用例,非常高效。
活用全文替换
编写用例时,QA人员一定要用统一语言文字或格式,一来是给阅读的人方便、二来是方便查找替换,即通过全文查找替换能 快速维护用例。

前边提到过设计了多套统一标准用例,新的页面复用时,直接替换变量内容,生成当前用例。又或者需求变更的刚好是统一标准用例的内容,活用全文查找替换、一分钟搞定用例维护。

总之,编写用例所有的秒招,离不开可复用、无非就是找到共性、提炼统用。然后,再通过一些手段或工具或代码协助快速完成。

划清领域边界、高复用、低耦合,是不是似曾相熟,没错,编写用例也一样。

举报

相关推荐

0 条评论