前言
【软件测试流程】
笔者坚信,大多公司的测试团队依然遵循以上这套软件测试流程。但是,面对繁琐的流程,作为测试执行者或管理者的您,是否也和笔者一样为每阶段重复且枯燥的工作而苦恼。我们都清楚,测试执行人员的主要职责是业务功能的验证,但受限于“软件测试流程潜规则”,其不得不把大量时间花在更新用例执行结果、描述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内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。