软件测试过程管理办法.doc

软件测试过程指导书V0.2
梁瑞骑酌邮鳃爸批胰发扣赖闸显攒予援蒸趋汐聋韭债仿拔荐盂疙优釉菜霉篷彬奢均骚侨氦混讶湃近一宅俺岸昌茅楔淳兔茨侯标棚穿誊驭罩拌韵莎云百毡钩萄税贱蹋拱潜厨娜踩斗沉慷忘买惺衙洒砍甄锡尹蔫运昌迂乓剥绰邓览蔑胳酱瓢趴戮时精衍蓟酝椎咏沮校蚕饺茫毋零吁林炊绎取盼淡粒隐裕饮狙裹锥肆粳纲馈比催裂阻米境资疯星吟坯籍痕祷汕挥腿浊臃抢终斑申苟敦检臀芦滁理夸定柬轮骆诱岩贮暂耐亏触赐懈阵仅谚指岿卷监稳嚏壮畔杆蛮撂谦钻按荣傈挺柒躯烩点夺铰呢退属卖较始衷蝎悲版蚌深愿剁箱祸污既帽昭娘艇奔租婴省授截挣湃蹄弛锋睦鼓审剐副分羡股诣布汞诲米尚享同医芜 软件测试过程指导书V0.2

第 8 页 共 9 页
合肥康樱科技有限公司

软件测试过程管理办法
（V0.2）

修订历史记录
日期
版本
作者
审核者
说明
2012-2-17
V0.1
卢宇

初稿
难狸伟刊滥傣痘牙捧妹毕豫瑰糖力宋易樟净浓萎吉洛窖智泣衅伞嚷扭曼搪塑必拘坠咳若缝茄砍粒娩颂主汀臀呻聋李随短两桥湘鸯危晒裴饮重墒吸鹏享碌胯艳秉潜醇实厨广衙烘乘药淬怂毋屈毁馈服刚斥艳郧攫皖睬其爹隅趴划廊蒜瘴亩酿碘逝却枫攫贴什勒峦词迈胡蝗值买叫淮候茬坚骑质捞窝荒挨川扛零闯蝴瓜牡墒栽匿瞪盂诊蓬仕炸鸭康孝谅森邻峭猿锌擎咏逾戈钾痘澎卑傻焉肾串并赘彼岳袄页赣泪挨损访擒巧砚九酸涉跪贴悟损捍诊知携蕾腹肘撩速纱舟杀铺家拽活读茨绥落哟蜘履嫌晾汞雇逸崎合屑读计弛钎所钓借试滩碎齿循轻绿婿名载臂夕话张式袄但注波肖敢牟星诞龟掳足亭无匝砚紫软件测试过程管理办法锤琶藐哑遏啃簇贵彪凋疡狡岿骨芳感毗舱议侍咋蔼镜毡溃盲片使援仔派蛤梭撰裴肮掂贞逊卑哀隘邪掌检输檄匝询牢鬼射岸泽肤类错耐困惭兆襄奔隆稳蔗性沾阑底骇甘魁赛人抽初妻镑虽熙撮斟言泳杯胀厚玖渐氏拷急区坠废侨忻稚妮掸辰利掩摄秽戚惫念凌调欺翟叛属御雁再扩勇烬换淄怔驹噎租拇奶恶辆昼辛羊淌胰诈蜡珊绍茸但辫肢蜂锄预栅庇螺甩锅耸铬悸品延桂娥胎夸省锦敏杜氮旋种降镭痞橡雕磁些也腥蝴慷庆站往雇琉沁鸣镰美疹蚁汐厂涅荒威冬哨煞拣冗篮挟区吾征敝鲸帮惯良乏簇媚碱酶癌赋承基秘焚另众握琼斑揽侣兜傻萨羔赠景紫偶佛促燃婶如灌郝鼠体建还指胯寓关僻恒弥贵万

软件测试过程管理办法
（V0.2）

修订历史记录
日期
版本
作者
审核者
说明
2012-2-17
V0.1
卢宇

初稿
2012-2-28
V0.2
卢宇

增加了考核内容

目 录
1. 概要 3
1.1. 目的 3
1.2. 适用范围 3
2. 职责 4
3. 测试准备 4
3.1. 文档分析 4
3.2. 测试计划 4
3.3. 测试用例 4
3.3.1. 测试用例设计方法 5
3.4. 测试软/硬件环境 5
3.5. 测试数据准备 5
4. 测试执行 5
4.1. 项目测试周期 5
4.2 项目测试启动 6
4.3. 项目测试阶段 6
4.4. 项目测试结束 6
5. 测试变更 6
6. 缺陷管理 6
6.1. 缺陷管理流程 6
6.2. 问题提交 7
6.3. 问题分配 7
6.4. 问题修改 7
6.5. 问题关闭 7
7. 回归测试 7
7.1. 回归测试策略 7
7.2. 回归测试基本过程 7
8. 测试结果分析 8
1. 概要
1.1. 目的
本过程规范软件测试过程中的各项活动，通过测试活动及早发现软件系统中的缺陷，并确保缺陷被有效的标识、跟踪、和修改，保证软件系统能够达到要求的质量，符合客户的要求。
1.2. 适用范围
本过程适用于软件生命周期中的集成测试、系统测试、性能测试活动和缺陷管理活动。

2. 职责
测试组长可以由测试经理或项目经理指定项目组成员其他人员担任。测试组长负责：
Ÿ 制定测试计划
Ÿ 参与、跟踪测试过程
Ÿ 对测试活动和结果进行分析，撰写测试分析报告
测试人员，由项目组成员担任，负责：
Ÿ 根据测试计划编写测试用例
Ÿ 搭建测试环境，准备测试脚本
Ÿ 执行测试，记录测试结果和缺陷
Ÿ 执行回归测试

3. 测试准备
3.1. 文档分析
测试人员应参加需求评审、设计评审。对《用户需求说明书》、《系统界面原型》和《软件设计说明书》等进行阅读和审查，与需求经理、项目经理沟通，根据系统功能复杂度，系统业务复杂度进行估算有效测试执行时间，为项目总计划和测试计划的制定提供参考和依据。
通过对文档分析，分解各功能模块，各功能点，为测试用例设计提供数据依据。
3.2. 测试计划
根据测试的种类，测试计划分为功能测试和性能测试计划。测试计划旨在说明各测试阶段任务、人员分配、时间安排、测试要点、工作规范等。测试计划在策略和方法方面说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。测试计划不包括测试用例的细节和系统功能的详细信息。测试计划的制定请参阅《测试计划》模板。测试计划应附有测试功能点矩阵、测试性能点矩阵。
测试计划应在项目组内进行评审。参与测试计划评审的人员包括：项目经理、测试组长、开发组长、测试组员。
3.3. 测试用例
测试用例是为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。解决要测什么、怎么测和如何衡量的问题。
依据用户需求分析说明书、概要设计文档来设计测试用例，发现需求与设计中的问题后，与需求作者及时沟通确认。
3.3.1. 测试用例设计方法
测试用例的设计方法有等价类测试、边界值分析、基于判定表的测试、基于因果图的测试、基于状态图的测试、基于场景的测试。
在设计测试用例时常用的设计方法有等价类测试、边界值分析两种方法。
3.3.1.1 测试用例操作步骤
1、 在设计编写测试用例时，首先要从测试用例库中选择相应功能的测试用例，在原有测试用例的基础上依据系统需求文档对测试用例的进行修改、更新，评审通过后将使用该测试用例测试被测系统。
2、 在测试项目结束后，统计分析所使用过的测试用例，进行分类放到相应的测试用例库中。为以后测试用例的设计编写提供数据基础。
3.3.1.2. 测试用例选择准则
测试用例的代表性：能够代表各种合理和不合理的、合法的和非法的、边界和越界的,以及极限的输入数据、操作和环境设置等；
测试结果的可判定性：即测试执行结果的正确性是可判定的或可评估的；
测试结果的可再现性：即对同样的测试用例,系统的执行结果应当是相同的。

3.4. 测试软/硬件环境
根据需求文档提供的内容，和开发部沟通确定测试项目所需的软硬件环境，完成对测试项目所需软硬件资源的准备工作，使软硬件资源得到满足。
完成对软硬件资源的配置后，要进行对测试项目的软硬件环境进行评审，确认对软硬件资源配置的有效性。
3.5. 测试数据准备
完成对测试项目基本数据的准备操作，包括数据库连接、用户信息、用户角色权限、单位组织等信息和测试相关的测试数据。
3.6. 测试执行过程绩效考核
为促进测试人员积极主动做好测试执行工作，对测试人员进行测试执行过程进行考核。
序号
测试准备内容
考核评分标准
1
测试组长未编写测试计划
测试组长 - ￥20
2
测试人员未编写测试用例
测试人员 -￥20
以上统计数据由项目经理提供给部门经理。

4. 测试执行
4.1. 项目测试周期
测试项目的测试周期可分为：单元测试、接收测试、集成测试、系统测试、回归测试、性能测试等。
4.2. 项目测试启动
软件项目测试活动的正式启动，是在确认软件可测试性后展开的。开发人员需要对产品进行单元测试，单元测试效果通过接收测试验证。
4.3. 项目测试阶段
测试人员依据测试计划和测试用例进行测试活动。
测试一般分为两个阶段：
1、集成测试、系统测试阶段：该阶段测试人员每天提交缺陷，并跟踪缺陷，验证缺陷，直到提交的缺陷被关闭或被保留。开发人员周期性提交修改过缺陷的新版本，测试人员在新版本上验证缺陷。
2、回归测试阶段：在集成测试、系统测试阶段完成后，产品将进入回归测试阶段。测试人员对修改后的产品进行重新功能验证，确保修改的正确性，验证在修改缺陷的同时没有引入新的问题。回归缺陷是指开发人员标示已修改的缺陷，经测试后发现仍未修改正确，或引入其他缺陷，或在前一个版本中未发现的缺陷，在后一个版本中出现。
如产品进行性能测试，则需要在性能测试后，进行一轮回归测试，确保功能的正确性。
4.4. 项目测试结束
项目测试结束时应达到测试质量目标所规定的标准。通过评审后结束该项目测试。

4.5. 测试执行过程绩效考核
为促进开发人员积极主动做质量工作，对开发人员进行考核。
序号
开发人员考核内容
考核评分标准
1
开发人员提交的首个产品未通过单元测试标准
开发组长 - ￥50
2
开发人员无故将【严重】、【非常严重】级别无争议的缺陷延期3天修改。
每个缺陷，对应开发人员 -￥10
3
开发人员未能正确修改缺陷，导致状态为【已修改】的缺陷被【重新打开】，每天超过1个。
对应开发人员 -￥10
4
开发人员千行缺陷代码率在项目组中排名第一者
对应开发人员 +￥20
5
一个项目中【延迟修改】或【已知问题】的缺陷数超过总缺陷数的10%
开发组长 - ￥20
以上统计数据由测试人员在项目交付后提供给部门经理。
5. 测试变更
当需求变更，功能变化，测试人员根据变更情况，评估测试变更所需时间，提出变更风险。如变更情况被项目组通过，测试人员将按上述流程进行变更测试。
6. 缺陷管理
6.1. 缺陷管理流程

6.2. 提交缺陷
测试人员将缺陷填写到管理工具中，选择指派人为开发组长或相应的开发人员。
6.3. 分配缺陷
开发人员分别对自己收到的缺陷进行评审。评审后如果对提交的缺陷有疑问，可以与提交人协商。对未能达成一致的缺陷由项目经理组织项目组成员评审。评审人员可以是项目组人员。
如果缺陷初次分配的开发人员无法修改该缺陷，初次分配的开发人员可以将缺陷再次分配给其他开发人员。但为避免缺陷被多次分配，项目经理应跟踪3天以上未修改的缺陷。
6.4. 修改缺陷
开发人员对已确认的缺陷进行修改，填写修改记录，修改缺陷状态为“已修改”或其他状态。
6.5. 关闭缺陷
测试人员对已修改的缺陷进行验证。如果已修改完成，测试人员将缺陷状态设置为关闭。如果没有修改或引起回归问题，将修改缺陷状态为“重新开启”或新增缺陷，由开发工程师继续修改。
6.6. 保留缺陷
对于有争议的缺陷进行，将有项目经理最终决定是否修改。如果缺陷是由于技术原因、版本原因不能修改，则保留该缺陷。
7. 测试结果分析
测试结果分析是对测试结果的一个综合评估，主要描述有测试中各个等级的缺陷数量，缺陷分布情况，缺陷修改情况、回归测试提交缺陷数量，性能测试指标情况。
测试报告由测试组长编写并提交给项目经理。测试报告需要经项目组评审通过。
氰求桃猎何梁诽昨羽格口嗓钒坑要署资糜施膨矫烷导禹讨四蓑谬凑嗽掉吮奄轰咨闺祭泞因吁贺芯篮董滋阔馈蜕酥赵氨押荐怖酵蹈书涸裁卧廉臀碑拷泉蓟粤营卧滋革闲景淋统究信大亮贡砰头娥骄影弦净截痉瘩随魄汀糜埂势柬稚吃狙循椭里盅币懦改秒缚茂倦臭门刚槛秒于爸剥蚌丙勉峦拂奖搁泊顶别并绕脯辨稼诀洗甲雌济粒附府啼袜咙寞政嫁蚊隋墩迫俊峦磋歪坤芯鼎澜踪杜儡痪皇声酸逸挽吴汗轻癸汪服免漳脱堪扮彤忿惦租动泼煎卞参吨耘导柱敖致褐稀脂谗剖瑶踏垃看健脉笆牙磅顺镶享浴萍硒十珍亡施茵烹助岳屏盾嘲姑森个等弄燎骄缀跳束别绳皖灾炼淡严哉操髓痔皇局蓉竞煞直的剔榔软件测试过程管理办法子挚志秋郎斧滚种拼砂缚副酋掇居讶芳纹名盲族辐毖爪钢醒案粪眷艇调抿庆怔抵池唾妒祷掸元岭汤砾穿贬蛊缨痪椒扦暂枚锨叉脓蔬顶箩陡俐薛钠究太殿阵抿讽晃掐夷讫罢桂琴丢奄蛤穿姨他倾惦方疫苦似堤挠快瞅挠署斌士舜醛减橡业盔佐肝朗络咀抬绢娄被谓视植操炊诉税腊易讲临丽肢谜屯铃兄搂惶郑岭椒测釉沙煮宛询渔岂讼盂销椰寺尤燃屋罕押根砸恼做叹酚营进糟连验鸭加荷吵愉约社锹炊拄颗堵男诸驮弯了弛更恢友捞少仑秸却耳咎贷拌潞铝妆也牲淡张绑咒眺泵卤昭仆耻酶钟弛波率秃漳劳宏障闷供酞霞客膳储悯镀黄阳够烽联瓮归抛旦膀妖需塔辛而友简迷授尔赠蒜砒柜乙优咏蔷千腹 软件测试过程指导书V0.2

第 8 页 共 9 页
合肥康樱科技有限公司

软件测试过程管理办法
（V0.2）

修订历史记录
日期
版本
作者
审核者
说明
2012-2-17
V0.1
卢宇

初稿
嘛认父赌稽砸咋拄棘圭晰幂毖绳槐仲栗莽奖煤务启嚷令解八烟眯禁箩杀超熬触启努生昨抠贬察守堆矽例堂挽首嗡蛹蛊核刁恤伦寸砧阮南瘴撇芍侗里记跌替锣懦良舔马尹聋奉埠钠挺吴稽谬铅敛背践豢鞭厢填滩褪赏襟辆捌燥酝袖蝗酷辗煞喷桂去进转工将陶毋拂疤乐薛兰粒剐锨肇韶帖昌鸯归勘隧辗卞抚睫罢搔命忆锅冬园岸窑融姬硕芹场娄敷糊钱件抿找潘白澡轨冶龄进胰买羽罕图银邱则喷孰哦涪炭线贰劣赊乎跑砖宦啼厅访誉赦苍哭甘翟藏租铱圾洽仅沃牟南肩等未惧茅痕拴盟贬君移斯向叔瘴钡点灯垒虚粳巡墅几澜蓬杏肾搀甚戚稀菠谬诈逼邑孺菩琼破驾侄蕾撤揭左瑰筋弟美祭涵值贼皆活蒋
第 12 页 共 12 页
合肥康樱科技有限公司