定制开发项目系统测试验收方案

定制开发项目系统测试验收方案
目录
第1章整体方案 (4)
1.1 项目需求理解方案 (4)
1.1.1 项目背景 (4)
1.1.2 项目概述 (4)
1.1.2.1 项目现状 (4)
第2章项目实施方案 (5)
2.1 项目实施策略 (5)
2.1.1 领导支持重视策略 (5)
2.1.2 基于成熟原型系统快速迭代的开发策略 (5)
2.1.3 全过程的知识转移策略 (6)
2.1.4 详尽的项目测试策略 (7)
2.1.5 加强沟通管理策略 (8)
2.2 系统测试方案 (8)
2.2.1 测试概述 (8)
2.2.1.1 测试的主要活动 (9)
2.2.1.2 测试类型 (9)
2.2.2 测试计划 (13)
2.2.2.1 测试目标 (13)
2.2.2.2 制定计划 (13)
2.2.3 测试组织 (14)
2.2.3.1 组织结构 (14)
2.2.3.2 岗位职责 (14)
2.2.4 测试环境准备 (15)
2.2.4.1 实验室环境 (16)
2.2.4.2 测试工具 (17)
2.2.5 测试报告 (17)
2.2.6 测试审核 (18)
2.2.7 测试过程管理 (20)
2.2.7.1 测试知识库 (20)
第3章项目验收方案 (25)
3.1 总体要求 (25)
3.2 人员安排 (26)
3.3 验收原则 (27)
3.4 验收依据和标准 (28)
3.5 验收流程 (28)
3.6 验证方案响应要求 (29)
3.6.1 软件系统验收 (29)
3.6.2 文档验收 (30)
3.7 云平台数据管理升级完善及运维验收 (30)
3.7.1 验收前提条件 (30)
3.7.2 交付物要求 (31)
3.8 机构改革软件服务验收 (32)
3.8.1 验收前提条件 (32)
3.8.2 交付物要求 (32)
第1章整体方案1.1项目需求理解方案1.1.1项目背景
1.1.2项目概述
1.1.
2.1项目现状
第2章项目实施方案
为完成本项目的顺利实施，结合项目招标要求，组织项目单位和我公司共同负责系统开发的总体管理和实施等工作。

按期完成本项目开发实施与测试上线工作，保障项目高效、高质完成，确保按期交付与验收。

2.1项目实施策略
2.1.1领导支持重视策略
本项目是云平台数据管理升级完善及运维和机构改革软件服务项目建设的关键系统软件建设，建设过程需要用户从需求、流程、时间进度安排、系统联调等方面的全程参与，这些工作的推动落实，必须有用户方领导的高度重视和参与，从高层到基层提高认识、落实责任，才能更高效的推动项目的建设和顺利上线运行。

从我公司作为实施方的角色来说也需要公司领导的支持重视，从人员、制度、后勤保障、技术、管理等方面为本项目提供便利的条件，整合公司的各方面力量，为项目实施提供强有力的保障，同时协调与用户方在项目实施过程中的事务，使项目实施按计划顺利进行。

有了领导和我公司领导的支持重视，就为本项目的成功实施打下坚实的基础，必将推动项目按时、保质的完成。

2.1.2基于成熟原型系统快速迭代的开发策略
云平台数据管理升级完善及运维和机构改革软件服务项目建设项目需求范围大、涉及面广、并与多个业务系统关联衔接，同时开发工期要求紧迫，开发过程与质量要求高，因此，必须在符合用户需求的原型系统基础上快速迭代，才能高质量按期完成目标系统的开发。

本项目拟采用“增量原型法”软件开发过程模型，该模型是国际目前比较先进的开发方法。

它比较传统的瀑布法和原型法等进行了优化和改进，是一种快速生命周期循环的开发方法，符合RUP的模式，通过分阶段的开发模型以适应用户不断增加和完善功能。

上面是“增量原型法”示意图，它通过循环的过程提交各个版本，每个版本的发布都将增加必要的功能，当最后一个版本发布之后整个生命周期结束。

每一个新版本的发布过程都是一个完整的包括设计、计划、开发和稳定的过程，也就是说，用户可以定期看到新的成果。

这种方法的优势就在于，用户不断察看发布版本的功能，监测是否满足需要，如果有偏差可以在下一个版本中调整。

对于用户对需求以及一些意外事件引起的变更可以及时得到响应。

我公司在充分理解用户业务需求和原型系统设计要求的基础上，认真准备并完成了云平台数据管理升级完善及运维和机构改革软件服务项目的部分开发。

原型系统涵盖了集成管理标准管理、版本管控、自动化测试、配置参数管理等内容，为项目的实施奠定了坚实基础。

结合原型系统的界面展现与功能设计，也便于将用户需求具体化、明确化，有助于用户与开发团队的沟通和确认。

2.1.3全过程的知识转移策略
对本项目这样的大型信息化项目，因为是用户核心系统软件，涉及的相关各方人员众多，包括税局人员、软件开发商、本项目承建商、工具提供商等多种角色，所以必须重视知识转移工作，加强用户培训，对操作人员、维护人
员、管理人员等人员予以详细培训，使其熟练掌握软件的操作、维护、管理方面的知识。

知识转移的过程不局限于某一特定时间段，应该从项目建设的全过程进行知识转移，在需求分析、设计、编码、测试、上线等阶段都要对用户进行培训，使本项目相关用户能够及时、熟练的了解和掌握业务变化、设计思想、设计方法、开发方法、数据资源等方面的知识，使用户更多的参与到项目建设中，通过全程的知识转移使用户熟练的掌握本系统的操作、维护以及设计、开发思路和方法，为项目上线使用和今后的维护打下良好的基础。

同时，注重对用户全过程的知识转移，也能使用户在项目开发的前期即提出意见和好的建议，更好的促进我公司实施工作的改进与提高。

2.1.4详尽的项目测试策略
由于本项目中涉及到的优化完善及运维和机构改革软件服务都是总局云平台数据管理项目的平台，平台的质量保证是重中之重，所以必须加强测试工作。

在这方面采取如下措施：
1、需求转测试：需求人员在完成需求工作后，可以部分转换到测试组，这样可以很好的进行知识转移，保证测试用例的完整性。

2、测试方案提前编写：测试方案应提前到设计阶段进行编写，当需求初步定型或评审通过后，就开始测试方案的编写工作。

测试人员、技术设计人员背靠背工作，这就给测试方案的编写争取了更多的时间，保证测试用例的质量和全面性。

3、测试的自动化：测试工作的展开完全靠手工进行是不现实的，必须借助有关的测试工具，提高测试的效率和BUG的管理，达到很好的测试结果。

4、全面的测试：除了单元测试和集成测试外，还要进行功能、性能、安全、健壮、界面、安装、文档方面的测试。

5、联调测试：在平台功能稳定的基础上，与第三方业务系统与应用系统的功能联调测试，是验证本项目建设需求的必要内容。

2.1.5加强沟通管理策略
由于本项目涉及的单位部门多，为保证项目的顺利进行必须建立好项目的沟通管理制度。

在项目启动时，应从决策层、管理层、执行层和监督层四个层面建立业主和项目实施单位的沟通渠道。

同时，启动时就应明确项目的沟通方式，如周报、周会、高层会谈制度等，保证项目情况得到有效的沟通，推进项目进展。

2.2系统测试方案
根据本项目招标要求，提出适用本系统的测试方案，我公司在以前项目中积累了宝贵的经验，对一些测试技术和测试方法都进行了应用实践，并取得了显著成果。

2.2.1测试概述
本节概述为实施本项目而建议的测试方案。

该方案是基于我公司的诸多大型信息系统建设积累的经验，遵循我公司软件能力成熟度模型CMM3级质量过程体系，并结合本项目实际状况和实施计划制定，用于保证整个项目的软件质量和项目的总体目标。

本项目中包含的测试内容有如下：
●集成测试；
●系统测试；
●系统性能
●安全测试；
●系统模拟测试；
●用户验收测试。

对于软件的测试，根据项目采用的不同的生命周期不同而有所不同。

在项目的进行整个过程中，测试相当于整个软件项目来具体管理和实施。

测试的活动也是跟开发活动并行进行的。

2.2.1.1测试的主要活动
●制定《测试策略》；
●制定《测试计划》；
●编写测试用例；
●设计测试数据题库；
●参与测试计划和用例的评审；
●安装、部署、配置、搭建测试环境；
●准备测试数据；
●测试执行、报告测试BUG、填写测试用例执行结果；
●完成测试报告
2.2.1.2测试类型
对于云平台数据管理升级完善及运维和机构改革软件服务项目的基础软件环境，我们从以下几个类型来测试软件的系统的可靠性、系统的可维护性以及
软件的并发处理能力等。

2.2.1.2.1功能测试
2.2.1.2.1.1测试内容
功能测试是对项目内系统功能的测试。

测试过程中尽可能的发现潜在问题。

功能性测试重在全面覆盖业务场景。

功能测试主要验证：本项目需求中所有功能的完整性、业务功能的正确性、接口功能的可靠性、各个功能之间影响是否正确等。

2.2.1.2.1.2测试完成标准
1、成功地执行了测试计划中规定的所有测试内容并形成完整的测试报告；
2、修正了所发现的错误；
3、测试结果通过了专家小组的评审。

2.2.1.2.2性能测试
2.2.1.2.2.1测试内容
性能测试是通过软件测试工具模拟业务功能进行高并发运行的测试。

该测试用来检验系统性能瓶颈，测算系统性能峰值，如果系统峰值不能满足当前业务量峰值，那么需要进行系统性能调优。

2.2.1.2.2.2测试完成标准
1、模拟业务功能按设置的参数正常运行。

2、运行过程中发现的性能瓶颈均得到解决，并再次得到测试验证。

3、所有软件业务功能缺陷均已解决，修改正了所有的错误；
4、测试结果通过了专家小组的评审。

2.2.1.2.3安全测试
2.2.1.2.
3.1测试内容
1、应用系统安全隐患测试
身份验证
验证系统在登录时是否有身份验证及身份验证的有效性。

即操作员登录系统时，系统应对用户的身份进行校验，验证登录的用户是否存在以及提供的口令是否正确。

只有当用户输入正确的登录ID和密码才可以进入系统进行相应的操作，如果没有输入正确的登录ID和密码，则不能通过身份验证，不能登录系统。

从而实现对系统的安全访问控制。

权限管理
在应用系统中对每个业务功能模块都划分了对应的权限，由系统管理员通过权限管理对系统内不同的操作员划分不同的权限，使每个操作员只能看到与自己相关的功能菜单，避免操作员的误操作及其他问题出现，达到对系统访问权限的有效控制。

因此这项测试主要是验证系统是否针对每个业务功能模块都划分了对应的权限，并且系统提供的业务功能权限是否与所属税务机关级别相对应。

即区县、地市、省级、总局税务机关拥有各自的功能权限列表，每级机关的操作员只能分配本级机关级别所具有的相关权限，不能分配其他级别的权限。

操作员以相应的登录ID登录系统时不能访问未被分配权限的功能模块，并且在系统中应只有系统管理员才有创建用户和分配权限的功能，普通用户不具备这些权限。

数据安全
在系统中对于登录用户的级别与操作数据范围之间是有严格的控制的。

即当用户登录系统进行业务操作时，系统应根据用户的职能权限对其访问的数据进行控制，只允许其访问涉及自己职能权限范围内的数据，不能查询其职能权限管辖范围以外的数据，从而保证系统内数据的访问安全性。

另外，还要针对特殊业务的特殊数据要求进行输入输出边界值的验证，通过测试边界数据检验系统对数据校验的严密性和一致性。

即不符合需求的业务数据
不能进入系统，保证符合相关数据类型规范的数据才能进入系统，为系统后续的操作做好准备，避免垃圾数据的产生，也避免由错误数据引起的其他问题。

系统导出的数据也要满足需求，并可以正常导出。

URL测试
系统通过URL地址来显示用户访问系统的某个页面。

通过在地址栏输入系统的登录URL地址，可以看到登录系统的界面，但是如果直接在地址栏输入其他操作页面的URL地址而没有通过登录URL地址进行登录，系统应对展示的页面进行控制，使用户不能正常进行业务操作，以保障系统不被恶意登录和使用，保证系统安全。

在测试中主要选取系统中关键的业务操作页面进行测试。

登录超时
在用户登录系统后，系统会进行登录超时监控，当用户一段时间内不操作系统，达到系统预定的超时范围，则系统会提示用户登录超时。

从而防止当用户离开工作用机一段时间后，其他人可以通过页面停留的窗口直接进行操作，而不需要身份验证，避免不明身份的用户对系统进行相关操作，以保护每个用户的操作安全。

在测试中主要验证系统是否有判断登录超时的机制以及判断登录超时的时间是否合理。

即操作员进行系统登录后，一段时间内不对系统进行操作，系统是否判断为超时并要求用户重新登录。

2、系统与数据库之间安全访问
数据库用户权限管理
系统在设计规划阶段对相关数据库业务用户的权限及其所属对象的权限根据实际业务需要严格控制，应用程序部署运行时只能通过对应的Weblogic的连接池进行连接和操作。

因此应用系统只能访问该数据库用户下合法权限内的业务数据和对象，不能访问其他数据库用户下的非授权对象中的数据，同时其他数据库业务用户也不能访问核心征管系统中未经授权的对象和数据。

业务用户口令管理
系统基于凯撒加密算法进行封装，实现了用户口令的加密存储和校验，口令以密文的形式存储在数据库中，非法用户无法获得真实的口令明文。

数据访问权限管理
系统根据业务元数据的所属税务机关和登录用户的职能权限机关的相互校验实现数据查询权限控制。

基于此原则，某职能权限机关的操作员只能查询涉及其所属机关的业务数据，而不能查询其职能权限机关外的业务数据.
2.2.1.2.
3.2测试完成标准
1、成功地执行了测试计划中规定的所有测试内容并形成完整的测试报告；
2、修正了所发现的错误；
3、测试结果通过了专家小组的评审。

2.2.2测试计划
2.2.2.1测试目标
云平台数据管理升级完善及运维和机构改革软件服务项目的主要测试目标如下：
1、满足用户的业务、功能需求
2、满足用户的性能需求
3、满足数据安全要求
4、满足数据接口要求
2.2.2.2制定计划
测试组根据软件需求文档组织编写系统测试计划和测试用例，根据软件系统架构设计文档和软件设计文档编制集成测试计划和测试用例，测试组提交测试计划和测试用例给项目经理。

项目经理对系统测试计划和测试用例进行审核并组织评审，项目经理依据评审意见进行批准。

评审通过后的测试计划和测试用例提交配置管理组纳入配置管理。

测试组应根据测试计划和测试用例安排相应的测试人员执行。

2.2.3测试组织
2.2.
3.1组织结构
针对本项目实施特点，我公司成立专门的测试组织来完成测试工作，测试的组织结构是属于项目组，但是独立于开发组，测试组长的直接汇报渠道是项目经理。

测试组内部又分为测试分析组、测试设计组和测试执行组。

软件开发组在测试阶段主要完成对软件错误的修改，系统性能的调优等工作，另外还要辅助测试组完成一些测试脚本的编写等工作。

质量保障组在测试阶段，对软件的测试及版本进行管理。

2.2.
3.2岗位职责
人是测试工作中最有价值也是最重要的资源，没有一个合格的、积极的测试队伍，测试就不可能实现。

在整个测试过程中，涉及不同的测试技术和不同性质的测试工作，所以测试人员应该进行详细的分工，一般可分为：测试组长、需求分析师、测试工程师等。

项目评审组，该组由内部、外部专家、第三方专业测试机构及需求方人员组成，整个测试活动要在评审人员出席的情况下进行，其岗位和职责分别定义如下：
2.2.4测试环境准备
一般来说，配置主测试环境可遵循下列原则：
1.符合软件运行的最低要求。

测试环境首先要保证能支撑软件正常运行。

2.选用比较普及的操作系统和软件平台。

3.无毒的环境。

利用有效的正版杀毒软件检测软件环境，保证测试环境中没有病毒。

辅测试环境常常用来满足不同的测试需求或特殊测试项目：
兼容性测试：在满足软件运行要求的范围内，可选择一些典型的操作系统和常用应用软件对其安装卸载和主要功能进行验证。

模拟真实环境测试：有些软件，在测试时常常需要考察在真实环境中的表现。

4.营造相对简单、独立的测试环境。

除了操作系统，测试机上只安装软件运行和测试必需的软件，以免不相关的软件影响测试实施。

毫无疑问，稳定和可控的测试环境，可以使测试人员花费较少的时间就完成测试用例的执行，也无需为测试用例、测试过程的维护花费额外的时间，并且可以保证每一个被提交的缺陷都可以在任何时候被准确的重现。

简单的说，经过良好规划和管理的测试环境，可以尽可能的减少环境的变动对测试工作的不利影响，并可以对测试工作的效率和质量的提高产生积极的作用。

本项目的测试工作从总体上划分为投标方实验室环境的测试、招标方测试环境的测试。

2.2.4.1实验室环境
为了确定测试环境的组成，我们需要明确以下问题：
1. 所需要的计算机的数量，以及对每台计算机的硬件配置要求，包括CPU 的速度、内存和硬盘的容量、网卡所支持的速度、打印机的型号等；
2. 部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；
3. 用来保存各种测试工作中生成的文档和数据的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；
4. 用来执行测试工作的计算机所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；
5. 是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份；
6. 测试中所需要使用的网络环境。

例如，如果测试结果同接入Internet的线路的稳定性有关，那么应该考虑为测试环境租用单独的线路；如果测试结果与局域网内的网络速度有关，那么应该保证计算机的网卡、网线以及用到的集线器、交换机都不会成为瓶颈；
7. 执行测试工作所需要使用的文档编写工具、测试管理系统、性能测试工具、缺陷跟踪管理系统等软件的名称、版本、License数量，以及所要用到的相关补丁的版本。

对于性能测试工具，则还应当特别关注所选择的工具是否支持被测应用所使用的协议；
8. 为了执行测试用例，所需要初始化的各项数据，例如登陆被测应用所需的用户名和访问权限，或其他基础资料、业务资料；
9．对于性能测试，还应当特别考虑执行测试场景前应当满足的历史数据量。

当然，还有另外一个非常关键的问题：在测试过程中受到影响的数据如何恢复?
明确了上面的问题后，明确哪些条件是可以满足的，哪些是需要其他部门协助调配、采购或者支援的。

在搭建测试环境之前，把上面的问题做成一张列表，并为每一项指定一个责任人，完成一项就填写一项，最终形成的文档则作为测试环境的配置说明文档使用。

2.2.4.2测试工具
2.2.5测试报告
根据测试方案中内容，严格执行系统测试总体实施计划，分别完成系统功能测试、性能测试、安全测试等，并且完成测试标准，形成对应测试报告，具体包括如下：
1、《云平台数据管理升级完善及运维和机构改革软件服务项目—系统功能测试报告》；
2、《云平台数据管理升级完善及运维和机构改革软件服务项目—系统性能测试报告》
3、《云平台数据管理升级完善及运维和机构改革软件服务项目—系统安全测试报告》
2.2.6测试审核
我公司对软件质量的保障措施采取控制与监控相结合的方式。

针对软件测试工作，测试结果的审核和结果认定由项目经理、质量经理和测试经理功能把握，具体控制过程如下：
第一、在测试期间，测试组完成《测试日报》，说明测试进展，及时向项目组反映测试情况；
第二、质量经理评审测试结果，并就测试的完全性与有效性向项目经理提出建议，并启动评审流程；
第三、当系统测试出口条件满足时，测试组长提交《测试分析报告》；
第四、经项目经理和质量经理共同审核通过后，确认测试工作完结。

第五、测试记录在TestDirector的缺陷管理部分完成，缺陷界面参见下图，测试报告中的数据可以完全可以根据TestDirector中的数据生成。

测试等级区分如下
⏹A类——严重错误，包括：
（1）由于程序所引起的死机,非法退出
（2）死循环
（3）导致数据库发生死锁
（4）数据通讯错误
（5）严重的数值计算错误
⏹B类——较严重错误，包括：
（1）功能不符
（2）数据流错误
（3）程序接口错误
（4）轻微的数值计算错误
⏹C类——一般性错误，包括：
（1）界面错误(详细文档)
（2）打印内容、格式错误
（3）简单的输入限制未放在前台进行控制
（4）删除操作未给出提示
⏹D类——较小错误，包括：
（1）辅助说明描述不清楚
（2）显示格式不规范
（3）长时间操作未给用户进度提示
（4）提示窗口文字未采用行业术语
（5）可输入区域和只读区域没有明显的区分标志（6）系统处理未优化
⏹E类——测试建议
测试分析报告：
2.2.7测试过程管理
2.2.7.1测试知识库
知识是对信息的推理、验证，从中得出系统化的规律、概念或经验，它是言行的基础。

知识是有价值的信息，能指导人们开展价值创造的实践活动。

经验、真理、判断和直觉构成了知识的重要组成部分。

2.2.7.1.1测试知识库需求分析
通常测试知识库建立的需求有如下几点：
一、帮助新进项目组的成员快速了解项目概况，降低新人培训的成本
实现：新进项目组的成员，最想了解的东西可能会是他要做什么(测试人员职责分配文档)，他做的是什么(SRS、HLD、LLD、TC、操作手册等)，如何做(测试环境搭建手册，测试环境地址，测试管理工具操作手册)；
二、共享组织内所有成员的知识，避免业务知识过于集中，降低人员流动或者请假带来项目延迟的风险，降低沟通成本
实现：可以建立WiKi服务器，对整个项目或者全司的知识财富进行存档，也可以使用多用户版博客建立学习型知识存档交流，可对这种分享型知识库的建。