前言
【软件测试流程】
笔者坚信，大多公司的测试团队依然遵循以上这套软件测试流程。但是，面对繁琐的流程，作为测试执行者或管理者的您，是否也和笔者一样为每阶段重复且枯燥的工作而苦恼。我们都清楚，测试执行人员的主要职责是业务功能的验证，但受限于“软件测试流程潜规则”，其不得不把大量时间花在更新用例执行结果、描述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、脚本执行结果及缺陷同步系统
对于执行不通过的案例，跳出缺陷提示框，由测试人员进行确认，其中“预期结果”、“实际结果”、“缺陷描述”、“响应报文”、“上送报文”字段可编辑，以便测试人员对缺陷进行更详细的描述。
查看更多精彩内容，请点击下载：
版权声明：本文出自《51测试天地》第五十期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
