一体化测试管理

前言

静下心来想想，自己一直以来都是用传统的测试思维来管理和执行测试，渐渐地感到力不从心，近半年来，一直在拼命挣扎尝试突破瓶颈，却未能如愿。心大眼窄，未来要走的路还很长很长，在此对先前的工作做一个总结，下一阶段重新出发。

软件测试流程

笔者坚信，大多公司的测试团队依然遵循以上这套软件测试流程。但是，面对繁琐的流程，作为测试执行者或管理者的您，是否也和笔者一样为每阶段重复且枯燥的工作而苦恼。我们都清楚，测试执行人员的主要职责是业务功能的验证，但受限于“软件测试流程潜规则”，其不得不把大量时间花在更新用例执行结果、描述Bug、提交Bug、关注Bug流转、验证Bug等与版本质量守护无直接关联的工作上。而测试经理的主要职责是协调测试资源、监控测试进度、评估测试风险，但又不得不把时间花在提醒测试人员更新用例执行结果及置Bug状态等琐事上，另一方面，还得根据案例管理系统及缺陷系统的统计数据来整理测试报告。综上所言，测试效率低下在所难免，测试团队苦不堪言亦能理解。
该篇文章，笔者将致力于解决上述繁琐测试流程的痛点，提升团队测试效率，解放“流程潜规则”禁锢，让测试人员专注于业务验证，专注于质量守护。

"流程潜规则"：
1、用例执行后，更新结果至案例管理系统。
2、发现Bug后，详细描述Bug，然后提交Bug并关联至案例管理系统。
3、Bug修复后，验证Bug并置状态。
4、提醒测试人员更新用例及Bug状态等。
5、统计各类数据并编写系统测试报告。

针对文章开头阐述的软件测试流程，笔者把测试团队成员划分为两大角色：测试经理和测试执行者。两者共同的目标是追求高质量的版本交付，自身关注点在于：

角色关注点

测试执行者关注点：需求分析、案例编写、数据准备、案例执行、缺陷提交、缺陷验证等。
测试经理关注点：组织案例评审、测试方案拟订、测试进度监控、测试环境搭建及资源协调、缺陷分析、风险评估、测试报告提交等。

首先，站在测试执行者的角度，我们试想一下是否有方法使自己的工作达到轻松加愉快的境地？比如：

1、批量执行用例。
2、用例执行后，结果自动更新案例管理系统。
3、执行失败的用例由测试人员确认后自动提交缺陷。
4、缺陷自动关联测试用例。
5、开发修复缺陷提交版本后，自动触发缺陷验证并置缺陷状态为关闭或不通过。
6、一键完成回归测试。

  其次，站在测试经理的角度，我们希望达到的效果是：

1、拥有一个稳健的测试调度平台，每天进行质量监控
2、透明的测试进度
3、完善的风险评估机制
4、自动生成一份完美的测试报告

毫无疑问，解决以上问题，团队的测试效率必定会上升一个台阶，质量守护亦更有保障。接下来笔者将结合自身的经历和思考，谈谈传统的测试团队应如何建立和完善“一体化测试管理体系”。以最常见的接口测试为例，依赖Jmeter、Testlink、Jira、Jenkins、Git等工具，笔者将与诸位一同开启“一体化测试管理”的探索之旅。

一体化测试管理

一、半自动化体系

测试执行者专注于业务验证及脚本编写，案例执行结果更新、Bug描述、Bug提交、案例断言等工作由工具辅助完成。

半自动化测试体系

1、定义模板

测试用例模板

测试数据模板

测试用例模板的“用例名称”、“用例编号”分别与测试数据模板的testPoint,caseNo字段对应。测试数据模板的preResult字段表示预期结果，YorN字段控制该条案例是否执行（Y表示执行），tableCheck字段用于控制是否做数据库断言（Y表示执行断言），其他字段为接口入参。

2、案例导入系统

测试用例编写完成后，使用Testlink小工具导入案例管理系统。

Testlink操作小工具

案例结构

用例结构分为4层，第一层为项目名，第二层为接口名称，第三层为用例集描述，第四层为具体用例。Tesltink系统的用例名称以caseNo_CaseName命名，方便关联测试脚本的用例，从而实现脚本执行结果同步Tesltink。

3、脚本执行结果及缺陷同步系统

对于执行不通过的案例，跳出缺陷提示框，由测试人员进行确认，其中“预期结果”、“实际结果”、“缺陷描述”、“响应报文”、“上送报文”字段可编辑，以便测试人员对缺陷进行更详细的描述。

测试人员确认缺陷-编辑缺陷描述

测试人员也可为缺陷添加附件，附件目录如下图所示。

缺陷附件目录

测试人员确认缺陷-添加bug附件

添加附件，并勾选缺陷后，既可自动提交缺陷至缺陷管理系统，同时同步案例执行结果至案例管理系统。

确认并提交缺陷

执行结果同步Tesltink

缺陷描述模板定制如下，方便开发分析及重现bug。

【测试要点】
XXX
【预期结果】
XXX
【实际结果】
XXX
【缺陷描述】
XXX
【响应报文】
XXX
【上送报文】
XXX

Jira缺陷描述

Jira缺陷附件

用例执行结果描述模板如下，方便测试人员对用例进行分析和二轮评审。

【自动化预期结果】
XXX
【自动化实际结果】
XXX
【自动化断言结果】
XXX
【响应报文】
XXX
【上送报文】
XXX

Testlink执行结果

提交缺陷及同步用例执行结果至(Jira,Testlink)系统的同时，亦自动把bug关联了对应的测试用例，以便后续进行缺陷分析。

Testlink缺陷统计

4、案例执行结果导出

  使用小工具导出用例执行结果，用例执行结果模板如下图所示。

用例执行结果

5、生成测试报告

依赖用例执行结果，使用小工具自动生成测试报告。测试报告部分内容如下所示。

测试报告截图

二、自动化体系

1、缺陷自动验证

传统测试团队一般是根据Bug状态来驱动缺陷验证，比如开发集成版本后，将Bug状态置为“已集成”，测试人员收到通知后，对Bug进行验证，验证不通过则退回开发处理，置状态为“处理中”，验证通过则置状态为“关闭”。

Jira缺陷工作流

换一种思路，咱们可以持续监控缺陷管理系统Bug状态，如果为“已集成”，则触发Bug关联的测试脚本进行验证，然后根据脚本执行结果自动更新Bug状态。当然，如果公司实施的是DevOps模式，则可根据开发代码更新来驱动Bug验证。

自动验证缺陷

2、一键回归测试，质量监控

还记得“半自动化体系”提到的测试脚本么？那不仅仅应用于手工测试，依赖Jenkins+Ant+Jmeter+Git+Testlink，咱们可以建立一套完整的持续集成体系，持续进行质量监控或回归测试。测试人员编写Jmx脚本并push到Git服务器，即可触发自动构建，并生成测试报告。当然也可以设置定时构建，每天进行质量监控。

持续集成体系g

三、性能测试平台

接口性能测试也是不少公司重点关注的，相比于Loadrunner，笔者更喜欢使用更轻便的Jmeter，依赖Jenkins+Ant+Git+Jmeter+telegraf+influxdb+Grafana，我们也很方便地搭建一套性能测试框架。当然，由于Jmeter是纯java应用，其对cpu和内存等损耗比较大，使用起来就仁者见仁了。

性能测试框架

框架理念：测试人员专注于测试脚本编写，专注于性能结果分析。
实现方式：测试人员编写测试脚本后，push到Git服务器，触发自动构建，随后登录Grafana查看性能测试结果。

性能展现

结语

文章针对接口测试所阐述的“一体化测试管理体系”不一定适合每个团队，但是，“专注质量守护，专注效率提升”的理念却是每个团队努力追求的，希望笔者的经历和思考对各位同行有所启发。最后写下一句话，与诸位共勉：只有不断思考探索，才能发现工作中的不足并致力改进，从而提升效率。