测试没有管理，产品质量心情说了算？

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

问题

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

• 理想状态下，测试计划先定好，人人心中有目标，用例全部文档化，不管你生手熟手，信手拈来，执行不走样，测试质量有保障，无论自动、手动，测试记录皆可查，报表总结看进展，工作快活赛神仙。

• 现实情况中，领会高层精神：动作要快，姿势要帅，测试用例加量不加价，范围可以蔓延，工期不能耽误。版本不停发发发，测试只够点点点，更要命的是，每个人的测试用例/脚本要么存在自己的小本本上，要么存在自己的脑子里，你中无我，我中无你，进度靠估，质量靠吼。

结果

• 做管理的团队：正规军，专业度高，协作强，质量可视，不但自己进步，还能带动整个研发部门的技能提升，帮产品团队建立发布前的信心；

• 不做管理的团队：游击战，心中没谱，无协作，做一天和尚撞一天钟，团队无沉淀，质量没保障。

痛点

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

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

解决方案

测试管理四大护法：

• 测试用例
• 测试计划
• 测试进度
• 测试报告

尝试了 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 提供了丰富的模板，方便一些经验不足的测试质量管理者，把成果展现出来。

总结

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