系统测试过程作业指导书.docx
《系统测试过程作业指导书.docx》由会员分享，可在线阅读，更多相关《系统测试过程作业指导书.docx（15页珍藏版）》请在冰豆网上搜索。
系统测试过程作业指导书
项目标准过程规范
HB-ST-01系统测试过程作业指导书
[状态]
2014/1/1
文档信息
文档名称
《项目标准过程规范-HB-ST-01系统测试过程作业指导书》
文档版本
[状态]
修订历史
修订版本号
修订日期
修订人
备注
正式核准
姓名
签名
日期
分发控制
副本
接受人
机构
1.概述
“软件测试作业指导书”用于指导软件测试过程及流程规范，使各个项目测试流程更加规范，保证软件测试质量，。
2.作业指导
2.1.作业规范
请参见《SPEC项目标准过程规范》
2.2.交付物清单
序号
交付物
交付对象
1.
《软件测试计划》
必选，评审通过后交至项目经理归档
2.
《业务流程测试用例》
必须，评审通过后交至项目经理归档
3.
《软件测试报告》
必须，填写并交至项目经理、开发经理及项目组其他成员
2.3.适用范围
2.3.1.适用对象范围
适用于质量控制部门负责人、测试主管、测试人员、项目经理、需求编写者、SQA
2.3.2.适用项目范围
1.对于新产品开发，必须使用此过程进行系统设计。
2.现有产品主版本升级，必须使用此过程进行系统设计。
3.现有产品小版本更新和bug修复，需要识别受影响的内容，并使用此过程进行系统设计。
4.现有产品的客户化定制开发，需要识别受影响的内容，并使用此过程进行系统设计。
2.3.3.职责
任务
角色
制定测试计划
编写测试用例
测试用例评审
执行测试
测试报告
工件归档
质量控制部门负责人
○
★
测试主管
★
★
★
○
★
测试分析人员、测试设计人员
★
○
★
○
测试员
○
○
★
项目经理
○
○
★
需求编写者
○
★
SQA
○
★
注：
责任者—★，配合者—○
2.3.4.名词解释
1.系统测试：
是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。
系统测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。
是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。
对象不仅仅包括需测试的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。
2.测试用例：
所谓测试用例设计就是将软件测试的行为活动，作为一个科学化的组织归纳。
软件测试是有组织性、步骤性和计划性的，而设计软件测试用例的目的，就是为了能将软件测试的行为转换为可管理的模式。
软件测试是软件质量管理中最实际的行动，同时也是耗时最多的一项。
基于时间因素的考虑，软件测试的行为必须能够加以量化，才能进一步让管理层掌握所需要的测试过程，而测试用例就是将测试行为具体量化的方法之一。
简单的说，测试用例就是设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的执行结果。
3.等价类：
等价类是指某个输入域的子集合。
在该子集中，各个输入数据对于揭露程序中的错误都是有效的。
并合理地假定：
测试某等价类的代表就等于对这一类其他值的测试。
4.边界值分析法：
边界值分析是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。
5.错误推断法：
错误推测法就是基于经验和直觉推测程序中所有可能存在的各种错误，有针对性地设计测试用例的方法。
6.因果图法：
是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件涉及的各种组合情况。
因果图法一般和判定表结合使用，通过映射同时发生相互影响的多个输入来确定判定条件。
因果图法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。
7.判定表：
是分析和表达多逻辑条件下执行不同操作的情况的工具。
在程序设计发展的初期，判定表就已经被用作编写程序的辅助工具了。
它可以把复杂的逻辑关系和多种条件组合的情况表达得较明确。
8.正交试验设计方法：
依据Galois理论，正交试验设计方法是从大量的试验数据中挑选适量的、有代表性的点，从而合理地安排测试的一种科学的试验设计方法。
9.场景法：
现在软件几乎都是用事件触发来控制的流程的，事件触发的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成了事件流。
这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。
2.3.5.参考文档
序号
交付物
1.
GB/T15532-2008计算机测试规范
2.
GB/T9386-2008计算机软件测试文档编制规范
3.
软件测评师教程（清华大学出版社2005.3）
2.4.测试流程与管理
2.4.1.需求评审
2.4.1.1.启动准则
1.项目已经立项
2.需求初稿已经完成
2.4.1.2.评审内容
测试主管，测试负责人及测试人员对《需求规格说明书》进行阅读和审查，与需求经理、项目经理沟通，根据系统功能复杂度，系统业务复杂度进行估算有效测试执行时间，为项目总计划和测试计划的制定提供参考和依据。
通过对文档分析，分解各功能模块，各功能点，为测试用例设计提供数据依据。
2.4.2.制定测试计划
2.4.2.1.输入文档
1.《需求规格说明书》
2.《开发计划》
2.4.2.2.测试计划设计
当测试部接到测试项目任务时，根据项目计划、开发计划、开发文档（需求或概要设计等），由测试主管或测试主管指定的项目测试负责人制定测试计划。
测试计划内容主要包括测试范围、测试策略，测试重点、测试时间、人员安排、任务安排，结束标准、测试风险等具体见《测试计划模板》。
测试计划在策略和方法方面说明如何计划、组织和管理测试项目。
测试计划包含足够的信息使测试人员明白项目需要做什么，是如何运作的。
测试计划不包括测试用例的细节和系统功能的详细信息。
测试计划的制定请参阅《测试计划》模板。
测试计划应附有测试功能点矩阵、测试性能点矩阵等。
2.4.2.3.测试计划评审
测试计划编写完成后，应在项目组内先进行内部评审。
内部评审通过后，在组织项目组人员评审，参与测试计划正式评审的人员包括：
项目经理、测试主管、开发组长、测试组员等。
在测试计划进行审核时应注意以下几点：
1、时间安排合理性可用性
2、测试范围是否覆盖全面
3、测试重点是否明确
4、测试人员安排是否合理
5、测试标准是否可行
6、风险评估是否全面，可控。
2.4.2.4.交付物
《软件测试计划》
2.4.3.测试用例
2.4.3.1.前置条件
1《软件需求规格说明书》已基线。
2《产品/项目测试计划》已基线。
3《产品/项目测试计划》已基线。
2.4.3.2.测试用例的设计步骤
测试人员按照测试计划中安排的测试用例任务分配表编写各自负责模块的测试用例编写。
1构造根据需求规格说明书得出的基本功能测试用例；
2边界值测试用例；
3状态转换测试用例；
4错误猜测测试用例；
5异常测试用例；
2.4.3.3.创建测试用例设计综合策略
1在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。
2必要时用等价类划分方法补充一些测试用例。
3用错误推测法再追加一些测试用例。
4对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
5如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。
2.4.3.4.PMS编写测试用例
1.登录pms,在测试——》测试—》用例管理视图中，点击创建用例
2.在创建测试用例页面填写用例具体内容
用例填写说明：
产品模块是选择该用例所属的产品线或项目名称
用例类型：
该用例适应的测试类型
适应阶段：
本用例适应的测试阶段如功能测试，性能测试等
优先级：
说明测试用例执行的优先级，优先级为1代表优先级最高
相关需求：
本测试用例对应的需求
用例标题：
填写用例标题，要简洁明确，如用户管理中添加功能测试用例
前置条件：
说明执行该用例需要的前置条件，比如需要创建某类用户，需要的测试数据
用例步骤：
描述测试用例步骤及预期结果
附件：
可以上传一些测试需要的数据，如人员信息，教师信息等
2.4.3.5.测试用例评审
测试用例编写完成后，应先进行测试部内部评审，内部评审通过后，再发起正式评审。
发起正式评审需要以邮件的方式发给项目经理，开发经理，开发人员，系统分析师，需求人员，测试人员等项目组人员，同时将测试用例文档，评审时间，参与的人员，评审方式及评审地点等写在邮件正文中。
用例进行评审时关注点：
1、用例可实用性
2、用例是否设计合理，并不具有重复性
3、测试用例是否覆盖全部需求
4、用例数据是否有代表性
5、用例业务逻辑覆盖是否完全
评审通过后，要把测试用例发给项目经理，通知项目经理将测试用例放到svn指定目录下
2.4.3.6.测试用例更新
1、当项目需求发生变更时，测试人员应该在已经基线的测试用例基础上，修改测试用例，并评审更新后的测试用例，项目组评审通过后，基线该版本测试用例。
2、测试人员执行测试任务的时候使用非测试用例中的方法发现了问题，应该及时补充该测试用例，完善测试用例，并通过测试组内部评审通过后，基线该版本。
2.4.3.7.交付物
Pms中录入的测试用例。
2.4.4.准备测试环境
根据需求文档提供的内容，测试主管或测试主管指定的项目测试负责人和开发部及项目经理沟通确定测试项目所需的软硬件环境，完成对测试项目所需软硬件资源的准备工作。
完成对软硬件资源的配置后，要进行对测试项目的软硬件环境进行评审，确认对软硬件资源配置的有效性。
测试环境必须要与需求规格中描述的生产环境要求一致或相当，如操作系统，数据库版本等，但配置与生产环境不必完全一致。
2.4.5.准备测试数据
测试主管或测试主管指定的项目测试负责人完成对测试项目基本数据的准备操作，包括用户信息、用户角色权限、单位组织等信息和测试相关的配置数据等。
2.4.6.测试执行
2.4.6.1.前置条件
1《测试用例》已基线
2环境已准备好，
3测试数据准备完成，
4开发经理已正式发出《软件送测单》
5在第一次版本测试之前，开发人员应该对系统进行公开演示，演示的内容包括软件系统基本使用，业务流程，业务逻辑等，演示通过后方可进行正式软件测试。
6开发组告知被测试工件在svn上的地址，如源码，war包，数据库初始化脚本等
2.4.6.2.执行测试
对于日常功能测试，使用《系统测试通用测试用例》执行测试即可，发现问题直接提交bug，非日常测试及业务流程测试需要按照下列步骤执行测试，
1登陆PMS,选择测试->选择项目-》点击用例管理
2.选择一个用例，点击标题，在弹出页面点击执行
1.在打开执行页面，根据测试实际情况，选择不同测试执行结果
若测试通过，在测试结果下来列表中选择通过，若测试不通过，选择失败，点击保存，在点击提交bug,进入提交bug页面，提交bug,若用例无法执行，选择阻塞，PMS提交bug步骤见2.10.2。
2.4.6.3.交付物
1.缺陷信息（在PMS录入）
2.《软件测试报告》。
2.4.7.缺陷管理
2.4.7.1.缺陷严重度划分标准
父级
子级
1
致命
2
严重
3
中等
4
一般
1.
系统崩溃/死机/冻结，
系统的主要功能部分丧失，数据不能保存，功能实现错误
删除操作不给提示;
提示信息错误（包括未给出信息、信息提示错误等），缺少必要的提示信息、错别字
2.
错误页面、乱码占据页面的主体（或关键部分）
模块无法启动或异常退出
基本功能未实现，并影响后续的业务进行
操作界面错误（包括数据窗口内列名定义、含义是否一致）
3.
影响后置流程的实现
如：
（1）申请模块发生错误，导致审核、统计等后置的业务不能有效的进行
（2）分配权限后，用户还是没有获得相应的权限
系统的次要功能完全丧失，
长时间操作无进度提示等
4.
严重的系统漏统
如：
SQL注入、XSS攻击、XPath注入、关键业务功能数据可被篡改、SSI注入、LDAP注入等，或被扫描工具定义为严重级别的漏洞
业务数据保存不完整或无法保存到数据库
操作不方便
如：
快捷键的支持不够、致使用户重复尝试（操作）、致使用户重复输入，菜单布局错误或不合理
5.
内存泄漏、用户数据丢失或破坏、严重的数值计算错误、功能设计与需求严重不符—
重要计算错误
轻微计算错误
2.4.7.2.提交BUG
1.进入测试视图的“缺陷管理”
2.点击页面右侧的"创建bug"，即可进入bug创建页面。
（或在执行测试用例的时候，从测试用例执行页面进入提交bug页面）
说明：
Ø项目和任务，以及相关需求，应该认真填写，这样可以将bug和项目，任务，需求关联起来，以便以后的统计分析。
Ø影响版本是必填的。
而这里面的列表来源，则是项目中的build。
如果这个地方没有build的话，则需要到项目中创建一个build。
Ø重现步骤应该准确，确保开发人员可以重现改bug。
缺陷标题简短，实现见文知其意的效果；
Ø缺陷导致的后果要描述清楚，配以必要的截图；
Ø缺陷严重度判断准确，参照2.10.1缺陷严重程度划分标准，不能将缺陷严重度填写过高或者过低；
Ø不能重现或者只重现几次的缺陷要在注释中加以说明；
Ø发送给项目组的缺陷描述要准确，并且缺陷类型的定义要准确；
Ø检查项目组处理完的缺陷时，要标注出缺陷检查结果，以及检查依据。
2.4.7.3.关闭BUG
当开发人员解决bug之后，就需要来验证bug，如果没有问题，则将其关闭。
在测试工作中对于不修改的bug原因是设计如此，或开发认为不是bug，必须经过与开发人员沟通，若沟通无果，则需要项目经理的确认后才能予以closed，若项目经理与测试组就以上状态的错误产生异议的，测试组必须在测试报告中将存在异议的错误体现出来。
2.4.7.4.激活BUG
如果开发人员解决bug之后，验证无法通过，则可以将bug重新激活，交由最后的解决者去重新解决。
还有一种情况就是bug关闭之后，过了一段时间，bug又重现了，也需要重新激活。
激活bug的自动指派给最后的解决者。
2.4.7.5.推迟处理的BUG
对于推迟处理的bug,必须在测试报告中予以体现，在产品正式上线前，推迟处理的bug,需要修改完成并回归通过，若开发不修改此类bug必须与项目经理确认，推迟处理的bug是否需要修改，若项目经理认为不需要修改，由项目经理在该类bug中添加备注，然后测试人员在关闭bug,若项目经理认为推迟的bug必须解决，
2.4.7.6.查询BUG
Ø我的地盘中的bug列表。
我的地盘中的bug列表，是所有当前指派给你进行处理的bug。
如果该列表为空，那么恭喜你，没有你需要处理的bug。
2.4.8.回归测试
2.4.8.1.前置条件
1.严重级别在3级以上的bug修复率在100以上，bug级别在3级的修复率在80%，其他级别的bug修复率在60以上。
2.填写《软件测试申请单》，说明本版本修改的bug信息。
2.4.8.2.执行回归测试
按照《软件测试送测单》回归bug,并测试主要流程。
2.4.8.3.交付物
《软件测试报告》
2.4.9.测试报告
测试报告是对测试结果的一个综合评估，主要统计测试中各个等级的缺陷数量，缺陷分布情况，缺陷修改情况、回归测试提交缺陷数量，性能测试指标情况。
具体见《测试报告》模板。
2.4.10.测试通过标准
1测试达到了测试计划中关于系统测试所规定的覆盖率的要求（测试用例执行覆盖率达到100%、测试需求覆盖率达到100%）；
2系统满足需求规约说明书的要求；
3在系统测试中发现的错误已经得到修改，及各级缺陷修复率达到标准。
表格1缺陷修复率达到标准
1级
2级
3级
4级
1级错误发布标准：
缺陷修复率=100%
2级错误发布标准：
缺陷修复率=100%
3级错误发布标准：
缺陷修复率=100%
4级错误发布标准：
缺陷修复率=大于等于75%
2.4.11.结束
通过测试后，软件达到测试目标即结束测试，邮件通知开发经理及项目经理，版本可以基线。
升级会员 