测试部流程规范实践方法812.docx
《测试部流程规范实践方法812.docx》由会员分享，可在线阅读，更多相关《测试部流程规范实践方法812.docx（9页珍藏版）》请在冰点文库上搜索。
测试部流程规范实践方法812
软件研发中心测试部
工作流程规范&实践方法
版本:
V_0.1
发布日期：
2016/8/12
编写：
付佳盈
审核：
批准：
办法修订记录
A-增加M-修订D-删除
版本号
修订日期
变更类型
（A*M*D）
修改描述
修改人
V_0.1
2016/8/12
A
付佳盈
一、目的
本文档用来明确项目各阶段内的测试任务，规范测试流程、明确测试准则以及实践方法，不涉及具体测试技术和方法。
二、适用范围
本文档适用部门为测试部、产品部、设计部、开发一部、开发二部、开发三部，以及项目管理部；适用人员为测试人员、项目经理、产品人员、开发人员、设计人员以及维护人员。
三、人员角色与职责
表1-1角色与职责
角色
职责
产品经理
项目立项，提供产品原型、产品需求文档，配合相关人员明确需求问题
项目经理
制定项目整体研发计划；提供《提测单》；保证版本达到接收测试标准
测试经理
指导测试工作，监控测试过程和测试结果；测试任务分配；协调资源；项目沟通协调；编制部门管理制度、测试流程及实践方法等相关规范文档；团队建设；部门日常管理
测试人员
参加所在项目组的一系列评审/讨论；迭代版本测试工作排期；需求分析、测试用例设计；测试执行；缺陷管理与跟踪；项目组内日常协调沟通；出具测试报告
配置管理员
实施配置管理；建立、标识及更新基线，并维护基线的完整性
四、测试流程及实践方法
4.1测试准备
4.1.1需求评审
a）产品部在《需求说明书》编制过程中邀请测试人员参与需求分析/讨论（可选），测试人员提供需求意见或建议；
b）产品部在《需求说明书》定稿后，邀请测试人员进行评审，以达到测试部设计用例要求，测试人员改进意见或建议。
如有需求不明确，或细节之处待商榷，从测试角度而言，此次评审为未通过，产品人员需及时修改《需求说明书》，并进行二次评审，直至整体《需求说明书》评审通过。
4.1.2UI评审
a）UI部门完成设计后，邀请测试人员进行UI评审，测试人员提供修改意见或建议。
如设计稿中存在需求遗漏、改动，或其他设计缺陷，则从测试角度而言，该设计稿为评审未通过，设计人员需及时修改设计稿，并进行修改内容评审，直至整体设计稿评审通过。
4.1.3测试计划制定
a）项目进入研发阶段后，项目经理提供整体项目计划，测试人员依据开发计划输出《测试计划》（进度计划可包含在项目计划中），提供项目组评审。
4.1.4测试用例设计、评审
a）《需求说明书》评审通过后，相关测试人员开始进行需求分析、需求点提取（根据实际情况，可选）、用例设计/编辑；
b）用例编辑完成后，测试人员发起部门内部评审，内部评审通过后，发起正式评审，以邮件形式通知项目组成员、所在部门人员、以及其他相关人员。
4.2测试执行
4.2.1安装部署测试
a）被测程序提测前，项目经理以企业邮件的形式向相关测试人员发送《提测单》，其中包括开发人员的自测报告、安卓/IOS系统安装包、服务端war包、数据脚本，以及部署文档。
如部署或安装失败，则将《提测单》退回项目组。
4.2.2版本接收（冒烟测试）
a）部署及安装测试通过后，测试人员开始执行版本接收测试（冒烟测试），不通过则退回项目组；
b）对于退回项目组的版本，需要重新走提测流程；并由测试人员做好统计，作为相关考核的依据。
4.2.3功能测试
a）冒烟测试通过后继续执行功能测试；
b）测试人员执行3轮功能测试，1轮整体回归测试，至多4轮即达到新版本测试要求，超过4轮计入绩效考核；
c）测试人员将测试出的bug及时提交到禅道，指派给相关开发人员，并进行bug跟踪管理；对已解决的bug，进行回归测试，经回归仍未解决的bug，进行激活并重新指派，直至bug闭环。
（请参考附件2“bug处理流程图”）
d）测试过程中，如有需求变更，产品人员需及时更新《需求说明书》，并以邮件形式发送给测试人员及其他相关人员；
e）在项目迭代版本上线之前，测试人员输出《测试报告》，报告内容包括测试过程简述、测试结果摘要、缺陷统计分析、质量整体评估、上线意见/建议等。
测试报告以邮件形式发送相关人员。
f）项目周期较长时，在测试进程当中，测试人员需出具《测试简报》（请参考附件3），以方便项目组成员及其他相关人员了解项目测试情况。
具体出具时间可根据项目运行情况，自行决策。
如遇项目紧急上线，则测试人员只出具《测试简报》即可。
各产品组测试人员可根据项目实际测试情况，对模板内容进行相应增改。
表1-2测试通过标准对照表
类别
阶段
轮次
接收标准
通过标准
功能测试
冒烟测试
1
开发自测通过
冒烟测试用例通过率100%
整体功能测试
<=4
冒烟测试用例通过率100%
1）用例通过率>=99%
2）缺陷清除率>=95%
3）没有1级的bug
4）2级bug需经过产品经理与项目经理确认，如确认结果为不影响上线，则可迭代到下个版本去跟踪解决。
性能测试
整版
<=4
功能测试用例通过率90%
满足客户要求的性能指标
4.2.4性能测试
a）在功能测试期间，测试用例通过率达到90%，方可启动性能测试，版本必须与功能测试版本保持一致。
五、测试资源分配
目前测试部门共计4人，测试经理1人，测试组长1人，测试工程师2人。
资源分配情况如下表：
表1-3测试部资源分配表
项目名称
测试负责人
致医云诊室pad-安卓系统
潘明月
致医云诊室Pad-IOS系统
潘明月
致医云诊室-boss用户激励系统
潘明月
致医云诊室-运营系统
潘明月
致医云诊室PC端
张雪
致医健康App-安卓系统
付佳盈（代）
致医健康App-IOS系统
付佳盈（代）
致医健康-医生运营后台
付佳盈（代）
致医健康-医生回复问诊后台
付佳盈（代）
致医健康-报告解读后台
付佳盈（代）
致医商城App-安卓系统
李娜
致医商城App-IOS系统
李娜
致医商城-商业后台
李娜
致医商城-运营后台
李娜
新项目立项后，由测试经理根据其他项目当前测试情况及项目进度，进行新的测试任务分配；如某一项目紧急上线，现有测试力量不足时，该项目测试人员可向测试经理申请协助资源，测试经理根据测试实际情况，决策是否调取资源进行资源临时调配。
被临时调配的测试人员，角色为辅助测试人员；原产品线测试负责人角色不变。
测试人员接受调配的任务，以及季度内所负责测试的项目数量，均计入季度绩效考核。
六、周例会及周报
测试部实行周例会，及周报制度。
周例会时间为每周五下午15:
00，以及下周一（具体时间根据信息研发中心周例会时间而定）。
周五例会的目的主要有：
各产品线测试人员汇报本周测试情况、所负责的项目进展情况，沟通测试过程中遇到的问题；测试经理进行整体测试进度把控，开展团队沟通，以及日常管理要求的制定，保证测试流程的正常运行等。
测试部人员每周需提交工作周报，详细汇总本周所完成的工作，并根据所负责项目的运行情况及项目计划，制定下周的测试工作计划。
周报于每周五下午17:
00之前以电子版形式提交到测试经理处。
（周报模板请参考附件1）
七、绩效考核
（正在制定）
附件1
周报模板
测试部工作周报
报告人：
日期：
2016-7-22
序号
本周工作总结
完成情况
存在问题
解决办法
预计完成时间
下周工作计划
已完成
未完成
1
已完成
2
未完成
3
4
5
6
7
8
附件2
Bug处理流程图
附件3
测试简报模板
《XXXX》V_0.1测试简报
测试项目：
XXXX
测试时间段：
XXXX
测试人员：
XXXX
测试内容概要：
1.
2.
3.
4.
5.
测试总结：
（部分重点测试现象总结）
1.此版本共提交bug52个，关闭bug32个，延期处理bug15个，激活状态3个，设计如
此1个，外部原因1个；
2.开具处方时进行临时保存操作，临时保存后将处方中的药品在药房管理中删除，将临时
保存的处方进行去结算操作成功；（已修复）
3.看病开方-处方笺界面，选择新增加的药品，药品数量处的默认值为0；（已修复）
4.新建立的诊所账号，在登录云诊室后，发现-火爆活动界面显示错误提示（目前直接在数据库修改字段即可解决此问题）；（已修复）
测试结论：
1.
2.
升级会员 