XXXXXX系统测试方案广东兰贝斯信息科技有限公司2014-6文件修订记录：日期版本号修订说明修订人2014-5-300.9新建测试组2014-6-41.0根据测试组内部讨论意见修改雷蕾目 录1引言41.1文档目的41.2项目背景41.3参资料42测试方案52.1测试方案流程图52.2测试需求分析52.3测试策划52.4编写测试用例52.5系统测试62.5.1搭建测试环境62.5.2测试数据准备62.5.3执行系统测试72.5.4提交测试报告72.6缺陷管理72.7验收测试73测试风险84测试产生的文件95评价准则95.1范围95.2数据整理95.3测试通过标准101 引言1.1 文档目的编写该测试方案的目的用于指导系统的测试，主要从测试流程、测试需求分析、测试环境、测试工具 、测试策略、测试具体执行方法、测试任务等事先计划和设计。1.2 项目背景此处填写项目背景。1.3 参资料XXXXXXXX_需求规格说明书XXXXXXXX_项目总体计划测试组工作流程和规定V1.02 测试方案2.1 测试方案流程图2.2 测试需求分析本项目的测试需求参考XXXXXXXX等相关文档，可从svn的需求文档目录下获得。2.3 测试策划请参看XXXXXXXX测试计划.doc，双击下面的图标可打开。2.4 编写测试用例根据测试项目性质的不同，采用的测试用例的模板也不同，例如对应多逻辑条件或人机交互多而输入条件少的应用程序则采用决策分析法设计测试用例。测试用例需要包括以下要素：测试用例名称、设计者、测试用例编号、测试模块、摘要、前置条件、操作步骤、输入数据、预期结果、确认形式、实际结果、是否采用此测试用例，备注。所有项均是必填项。测试用例编号规则：1.测试用例编号形式：项目名称简称的拼音首字母缩写_+子系统名称简称的拼音首字母缩写_+流水号2.流水号统一使用两位阿拉伯字数表示，从001开始。3.例如项目名称是广东会计，子系统是从业人员管理那么测试用例的编号为：GDKJ_CYGL_001测试用例编写完成后需要进行内部评审。2.5 系统测试系统测试目的是确保各单元模块组合在一起后能够满足设计要求，确保增量组装的构件正确。并确保使系统能够达到XXXXXXXX_需求规格说明书规定的功能要求、性能要求等。它所测试的内容包括系统后的功能、以及功能与功能间的接口，对以前的系统进行回归测试。2.5.1 搭建测试环境系统测试环境需要独立的、稳定的和良好的测试环境。可在应用服务器测试机（IP：XXX.XX.XX.XXX），数据库服务器测试机（IP:XXX.XX.XX.XXX）上部署测试环境。2.5.2 测试数据准备序号测试数据准备方法用途12342.5.3 执行系统测试l 测试组成员依据测试方案和测试用例，执行系统测试。l 测试发现的问题记录到JIRA中。2.5.4 提交测试报告系统测试报告在系统测试阶段结束后或达到系统测试结束标准由测试经理组织编写测试报告，系统测试报告中需要包括以下要素：l 测试范围l 测试环境（硬件、软件、测试数据）l 测试执行情况（测试方案和选用的测试用例执行结果）l 测试结果统计（测试用例执行通过率、测试用例的覆盖率和缺陷统计）l 缺陷统计和分析l 测试结果评价（建议测试结论，遗留缺陷建议）2.6 缺陷管理测试的目的是为了尽早发现软件系统中的缺陷，并对缺陷进行跟踪管理，确保每个被发现的缺陷都能够及时得到处理是测试工作重点。说明缺陷管理方式，参照缺陷管理规程V1.0。2.7 验收测试在系统测试完成后，进行验收测试，其目的是咨询顾问与用户一起确认软件在真实环境下的功能是否达到预定的要求。3 测试风险测试风险是不可避免的、总是存在的，所以对测试风险的管理非常重要，必须尽力降低测试中所存在的风险，最大程度地保证质量和满足客户的需求。在测试工作中，主要的风险有：一、质量需求或产品的特性理解不准确，造成测试范围分析的误差，结果某些地方始终测试不到或验证的标准不对；二、测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏；三、需求的临时/突然变化，导致设计的修改和代码的重写，测试时间不够；四、质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智；五、测试用例设计不到位，忽视了一些边界条件、深层次的逻辑、用户场景等；六、测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差；七、有些缺陷出现频率不是百分之百，不容易被发现；如果代码质量差，软件缺陷很多，被漏检的缺陷可能性就大；八、回归测试一般不运行全部测试用例，是有选择性的执行，必然带来风险。前面三种风险是可以避免的，而四至七的四种风险是不能避免的，可以降到最低。最后一种回归测试风险是可以避免，但出于时间或成本的考虑，一般也是存在的。针对上述软件测试的风险，有一些有效的测试风险控制方法，如：测试环境不对可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查；有些测试风险可能带来的后果非常严重，能否将它转化为其他一些不会引起严重后果的低风险。如产品发布前夕，在某个不是很重要的新功能上发现一个严重的缺陷，如果修正这个缺陷，很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大，对策是去掉(Diasble)那个新功能，转移这种风险；有些风险不可避免，就设法降低风险，如“程序中未发现的缺陷”这种风险总是存在，我们就要通过提高测试用例的覆盖率(如达到99.9%)来降低这种风险；为了避免、转移或降低风险，事先要做好风险管理计划和控制风险的策略，并对风险的处理还要制定一些应急的、有效的处理方案，如：在做资源、时间、成本等估算时，要留有余地，不要用到100%；在项目开始前，把一些环节或边界上的可能会有变化、难以控制的因素列入风险管理计划中；对每个关键性技术人员培养后备人员，作好人员流动的准备，采取一些措施确保人员一旦离开公司， 项目不会受到严重影响，仍能可以继续下去；制定文档标准，并建立一种机制，保证文档及时产生;对所有工作多进行互相审查，及时发现问题，包括对不同的测试人员在不同的测试模块上相互调换；对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险。要想真正回避风险，就必须彻底改变测试项目的管理方式；针对测试的各种风险，建立一种“防患于未然”或“以预防为主”的管理意识。与传统的软件测试相比，全过程测试管理方式不仅可以有效降低产品的质量风险，而且还可以提前对软件产品缺陷进行规避、缩短对缺陷的反馈周期和整个项目的测试周期。4 测试产生的文件测试中产生的文档主要包括：测试方案测试计划测试用例测试报告5 评价准则5.1 范围描述范围。5.2 数据整理功能测试数据整理到XXXXXX测试用例中，性能测试数据可根据系统运行的实际情况进行适当的调整。5.3 测试通过标准描述测试通过标准，可参考以下几点：1）主要功能点的用例全部执行测试。2）测试覆盖率达到标准。3）缺陷率达到标准。4）其他指标达到质量标准。