初级测试跟着干，中级测试带着干，高级测试养着干。
老板问我说：测试管理怎么办？
我说：这个基本上很难。

问题

如今互联网几乎全走微服务架构，对于测试工程师来说可不是个好消息，不但变化频繁，接口数量还暴增，测试场景更是可以令人发指的“随心所欲”。

  • 理想状态下，测试计划先定好，人人心中有目标，用例全部文档化，不管你生手熟手，信手拈来，执行不走样，测试质量有保障，无论自动、手动，测试记录皆可查，报表总结看进展，工作快活赛神仙。
  • 现实工作中，领会高层精神：动作要快，姿势要帅，测试用例加量不加价，范围可以蔓延，工期不能耽误。版本不停发发发，测试只够点点点，更要命的是，每个人的测试用例/脚本要么存在自己的小本本上，要么存在自己的脑子里，你中无我，我中无你，进度靠估，质量靠吼。

结果

  • 做管理的团队：正规军，专业度高，协作强，质量可视，不但自己进步，还能带动整个研发部门的技能提升，帮产品团队建立发布前的信心；
  • 不做管理的团队：游击战，心中没谱，无协作，做一天和尚撞一天钟，团队无沉淀，质量没保障。

痛点

大家都说会管理，但问其如何管理，都只谈理论：定计划、分资源、跑用例、做报告。

落实起来无章法可循，无工具可使。基层干得没劲，中层管得没体现，高层看得云里雾里。

解决方案

测试管理四大护法：

  • 测试用例
  • 测试计划
  • 测试执行
  • 测试报告

尝试了 JIRA 的几款测试管理插件之后，力荐 TM4J (如今已经改名为 Zephyr Scale)

出品方 SmartBear 很强，Swagger, Zephyr 也都是旗下产品。

图片

不过近期，应该是出于战略调整， TM4J 已经正式并入 Zephyr ，更名为 Zephyr Scale

图片

其特点很鲜明：

  • 有 API 支持
  • 可对接 Jenkins
  • 学习成本低
  • 独立的管理页面
  • 整体界面简洁
  • 可以双向关联 Jira 平台中的需求、任务、缺陷
  • Atlassian 生态支持

操作上都不难，我们看看如何应用它来落实测试管理四大护法。

测试用例（Tests）

层级结构上，根据 HLTD 来创建目录以及子目录，以方便所有人理解和阅读，最后的测试点则实例化为一个测试用例，它拥有全局唯一的 Key。

图片

创建测试用例时，除了定义用例名称、目的、前提条件，设置状态、优先级、所属组件，还可以添加一些便于管理的标签。

图片

测试步骤可以采用 Step-by-Step 类型，按照 STEP - TEST DATA - EXPECTED RESULT 的格式添加。

图片

亮点在于，每个用例可以关联 Jira issue 和 Confluence page，打造生态闭环。

图片

测试计划（Plans）

计划管理推荐按照发布版本来制定顶层目录，然后针对测试类型创建二级目录，如回归、新功能、端到端、接口、性能等等。可简单可详细，适合任意风格的团队。

图片

同样的，测试计划可关联需求或者 Confluence 页面，并且与之后的测试执行（Cycles）双向关联，使得每一个计划都有据可依，每一个计划都切实落地。

图片

测试执行（Cycles）

在 TM4J 中，测试执行靠 Cycles（测试周期）来管理，上关联测试计划，下关联测试用例。

与测试计划一样，多层目录结构可以使进度的追踪适应各种类型团队的需要。

图片

分配测试用例到测试周期，测试用例便具备了项目属性。

图片

通过查找来关联已经做好的测试计划。

图片

大多数的人作为测试执行者，进入该周期浏览到分配到自己名下的测试用例，标记通过、失败、阻塞，并且可以快速创建、查找 Jira issue 进行关联。完美打造需求/开发/测试闭环。

图片

测试报告（Reports）

TM4J 的 Reports 提供了丰富的模板，方便一些经验不足的测试质量管理者，把成果展现出来。

图片

图片

总结

图片

测试工作不能作为一个独立的业务，应该更多的与其他角色协作，测试管理工作是迈向质量管理的第一步，它不是形式主义，是质量管理的基石。