系统测试与验收专项方案.docx
《系统测试与验收专项方案.docx》由会员分享，可在线阅读，更多相关《系统测试与验收专项方案.docx（8页珍藏版）》请在冰豆网上搜索。
系统测试与验收专项方案
系统测试和验收方案
1.1. 测试方案
1.1.1. 单元测试
1.1.1.1. 单元测试说明
在计算机编程中，单元测试（又称为模块测试）是针对程序模块（软件设计最小单位）来进行正确性检验测试工作。
程序单元是应用最小可测试部件。
在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包含基类（超类）、抽象类、或派生类（子类）中方法。
单元测试目标是隔离程序部件并证实这些单个部件是正确。
一个单元测试提供了代码片断需要满足严密书面规约。
所以，单元测试带来了部分益处。
单元测试在软件开发过程早期就能发觉问题。
1.1.1.2. 单元测试方法和内容
单元测试关键采取白盒测试技术，用控制流覆盖和数据流覆盖等测试方法设计测试用例；关键测试内容包含单元功效测试、单元性能测试和异常处理测试等。
1.1.1.3. 单元测试步骤
图15-1 单元测试步骤图
从配置库获取源码文件，设计测试用例，实施测试用例，并利用相关测试工具对单元代码进行测试，将测试结论填写到单元测试汇报和软件Bug清单中。
把软件Bug清单和测试用例实施结果提交测试责任人，并进入纳入质量管理。
对源码文件进行测试，视程序存在缺点情况，可能要反复进行，直至问题处理。
单元测试实施者，通常情况下可由程序编码者进行，特殊情况可由独立于编码者测试人员进行。
1.1.1.4. 单元测试用例
编程组组长组织、指导开发人员依据《系统设计说明书》，编写所负责代码设计模块《单元测试用例》，设计单元测试脚本。
1.1.2. 代码评审
代码评审也称代码复查，是指经过阅读代码来检验源代码和编码标准符合性和代码质量活动。
评审内容：
1）编码规范问题：
命名不规范、magic number、 System.out等；
2）代码结构问题：
反复代码、巨大方法和类、分层不妥、紧耦合等；
3）工具、框架使用不妥：
Spring、Hibernate、AJAX等；
4）实现问题：
错误验证、异常处理、事务划分、线程、性能、安全、实现过于
复杂、代码可读性不佳、扩展性不好等； 5） 测试问题：
测试覆盖度不够、可测试性不好等。
评审优点：
1） 提升代码质量：
在项目标早期发觉缺点，将损失降至最低
2） 评审过程也是重新梳理思途经程，双方全部加深了对系统了解
3） 促进团体沟通、促进知识共享、共同提升
1.1.3. 集成测试
1.1.3.1. 集成测试目标
集成测试，也叫组装测试或联合测试。
集成测试是在单元测试基础上，依据《系统概要设计》及《系统集成和开发具体设计》，对系统各单元进行组装。
把分离系统单元组装为完整可实施计算机软件。
集成测试目标是检验软件单元部件是否能够集成为一个整体，完成一定功效，并找出单元测试中没有发觉错误，包含数据定义有没有重合和冲突，接口会不会产生错误，组合以后模块功效会不会相互影响，组合系统是不是达成预期效果等。
1.1.3.2. 集成测试采取方法和内容
集成测试采取白盒测试和黑盒测试相结合测试技术和渐增式测试策略，用数据流等测试方法设计测试用例。
关键测试内容包含单元之间接口测试、全局数据结构测试等。
1.1.3.3. 集成测试步骤
集成测试包含集成测试设计、集成测试准备、集成测试实施和测试统计、集成测试问题跟踪和结束测试等阶段。
集成测试设计由测试组组长依据项目计划和开发计划编制《集成测试计划》，设计《测试用例》。
测试计划和测试用例应该经过项目经理审查。
集成测试准备需要系统测试组组长建立独立测试环境。
测试环境包含测试硬件环境、网络、数据库、应用服务器等和测试对象（程序）安装和初始化工作。
集成测试实施和测试统计是由系统测试组组长组织人员根据测试计划和测试用例要求进行测试，而且统计测试过程和测试结果。
集成测试问题跟踪是在测试过程中发觉问题由系统测试组组长依据测试
统计提交测试问题汇报，并由系统设计人员和开发人员处理每一个问题过程。
测试结束指测试问题汇报中问题处理后，进行回归测试。
当测试问题降低到一定程度并经过测试经过准则时，系统测试组组长提交测试总结汇报结束测试。
1.1.4. 功效测试
功效测试包含两大部分，一是包含基础业务功效、业务测试、接口测试和可用性测试等方面功效测试，二是包含：
安全性测试、故障恢复测试、数据库测试、配置测试、安装测试产品化测试。
验收测试关键从系统实用性、稳定性、可维护性、灵活性、可操作性、和安全性方面进行测试。
（1）测试目标
组织并实施测试，以降低软件产品中存在缺点，确保产品质量和可用性，测试工作目标就是降低BUG率，从各个方面提升软件产品质量和可用性。
（2）测试步骤
在确定具体测试范围及内容后，进行测试分类，并依据分类结果确定需要设计测试用例。
在整个测试过程中，我们将用缺点管理工具BugBase对测试纲领、测试用例、测试问题等进行管理，并可对问题进行统计。
（3）测试完成标准
l 实现功效完全符合功效列表。
l 全部功效页面均可达。
l TD上问题得到妥善处理，不含有A,B,C类问题。
l 定义测试项目完成。
l 产品化测试约束达成。
（5）缺点管理追踪工具
在上节描述中提到TD，能够应用于测试全过程，也能够用于管理各类评审缺点等。
TD还提供部分模板，比如测试计划、测试总结、测试纲领、测试问题卡，所以能够经过BugBase实现从测试计划到总结各测试活动管理。
我们以需求说明书、软件需求规格说明为输入编写测试纲领，对应测试纲领中内容和测试需求编写测试用例，测试人员能够依据测试纲领和用例实施测试，发觉问题后，统计在TD中，测试责任人经过查看缺点问题列表将问题分配给对应开发人员，开发人员经过查看问题列表修改问题，TD还提供了多种统计功效，比如依据问题发觉日期、问题等级、问题分布、问题引入阶段等进行统计，这些统计结果可用来进行分析和总结
1.1.5. 性能测试
性能测试总体步骤和业务系统测试步骤基础相同。
验收测试关键从系统实用性、稳定性、可维护性、灵活性、可操作性、和安全性方面进行测试。
性能测试内容源于用户对平台系统性能要求。
1.1.5.1. 测试目标
性能测试目标是在整个系统或一个系统特定组件上定义、建立和实施性能测试。
验证系统是否满足标书性能要求，如不能满足，要进行对应优化。
1.1.5.2. 测试步骤
首先对性能测试进行策划，确定性能测试类别和测试方法。
然后开发性能测试用例，确定测试环境并准备就绪后实施性能测试，确定测试中系统或组件性能，并使用其结果决定性能是否能够被业务所接收。
假如在测试中度量性能特征证实是不能被接收，我们能够经过对业务改善、数据库、应用服务器等进行调优，以提升性能质量，在进行系统调优前，我们一样要进行调优设计和分析。
性能测试和应用和技术架构紧密相关而且二者相互影响。
1.1.5.3. 性能测试指标
a） 响应时间
响应速度在用户心理所能承受范围内。
不管是用户端还是管理端，当用户登陆，进行任何操作时候，系统应该立即进行反应，系统应能检测出多种非正常情况，并立即提醒用户。
b） 可扩展性
在设计上必需含有适应改变能力，当系统新增业务功效或现有业务改变时，应确保业务在整体框架不变基础上，业务改变造成影响局部化。
c） 易用性
全部业务功效界面风格和操作步骤一致，业务表单做到所见即所得，录入能够完全经过键盘完成。
d） 可靠性
系统应确保7*二十四小时内不宕机，确保在正常情况下和极端情况下业务逻辑正确性。
e） 可用性
必需避免因为单点故障或系统升级而影响整个系统正常运行。
f） 可维护性
系统能够简单方便修改和升级，包含可度性、可修改性、可测试性等。
g） 可管理性和服务支持能力
每个层次、每个构件全部提供标准管理接口。
实现统一、一致日志功效。
每个构件全部提供给用架构总体设计要求必需标准外部接口。
1.1.6. 用户测试
1.1.6.1. 测试步骤
用户测试步骤以下：
1） 明确测试内容，其中包含功效、性能、可用性、安全性、兼容性、和其它系统集成
2） 确定测试范围：
确定业务情况类型是是很关键。
每一个业务情况类型全部对应一个实际商业业务。
业务情况类型能够被表示成多个情况（比如，简单情况、或需要进行复杂处理例外情况）。
3） 测试小组组员确定：
由管理人员、业务人员、技术人员等组成，我方提供验收测试过程中技术支持。
4） 明确问题分类标准
5） 系统功效经过功效测试进行验证。
在功效测试过程中发觉问题依据其严重程度进行分类。
下表列出了功效测试问题分类。
1.1.6.2. 用户测试设计
设计测试用例：
确定每个功效测试用例，明确系统输入信息和期望输出结果。
针对需求规格说明书每一条测试内容，确定测试用例。
每个测试用例包含测试条件（包含生成测试条件需要测试数据类型）和期望结果。
每个测试用例全部应该是唯一确定（比如，赋一个数值）。
设计测试纲领：
依据测试范围生成测试纲领。
对每一个业务情况类型，生成尽可能多测试用例来完善测试纲领。
为了确保测试纲领包含全部测试用例，将测试用例条件映射为测试纲领是很必需。
测试纲领中测试用例次序安排是很关键，它应考虑多个方面原因，关键考虑原因是根据系统产生数据，在测试纲领中安排测试用例次序，使得一个测试结果作为另一个测试前提。
测试环境准备：
为了预防出现问题，如数据损坏或对系统资源争用，需要建立一个独立测试环境。
在进行测试之前，依据测试计划中确定时机建立一个独立测试环境。
1.1.6.3. 用户测试结果
1） 测试结束后，测试小组依据测试数据，制订并向验收工作领导小组提交《用户测试汇报》。
2） 测试汇报结果说明软件满足下列要求：
3） 在认可外部设计文档中表述功效要求 4） 在认可系统描述文档中表述非功效要求 5） 另外，测试汇报中还包含对系统提出改善意见。
1.2. 验收方案
1.2.1. 验收步骤
在验收阶段，平台系统将根据用户和我企业全部认可《系统需求分析》，组织验收小组，进行功效和性能验收测试。
从系统实用性、稳定性、可维护性、灵活性、可操作性、和安全性及系统文档、代码、规范及注释说明等方面组织全方面验收。
验收测试安排分为系统初验和系统终验。
1.2.2. 系统初验
经过系统内部试运行，我企业对内部试运行期间发觉问题更正后，提出系统初验书面申请。
验收标准将根据“需求说明书”和双方认可相关系统设计文档所提要求进行。
用户在收到我企业验收申请后，立即组织系统初验。
初验前我企业提供全部工程文档和安装测试汇报，并提供初验测试文档，在用户认可后进行初验测试，初验经过后，系统进入正式试运行期。
我企业应处理试运行期间所反应出问题，若系统达不到协议要求要求，试运行期将继续顺延，直到系统完善，但试运行期最长不得超出30天。
1.2.3. 系统试运行
初验合格后，经用户同意，系统进入试运行阶段，试运行周期不超出三个月。
在试运行期间，我企业按用户要求提供培训和技术支持，确保用户能够正确了解和使用系统；我企业对试运行中出现任何问题及用户提出修改意见将立即做出响应，并提交处理方案，在用户确定后实施。
试运行期间如出现重大故障，则试运行期从故障排除之日起重新计算。
1.2.4. 系统终验
试运行期结束后，如系统无功效缺点，能够正常运行，在含有终验条件下进行系统终验，由我企业提出终验书面申请，用户在收到我企业验收申请后，立即组织系统终验。
成立项目全方面验收小组，由用户、我企业和外部教授等组成，对项目进行全方面验收。
系统终验前，我企业提交终验测试标准和终验测试计划，内容包含：
测试对象及应达成测试指标、测试方法和测试条件、测试资料和数据，并以图表说明每一测试对象或过程功效输入输出测试进度。
系统终验标准：
1） 系统实用性：
项目验收最关键指标，检验系统是否符合目前业务需要，尤其是业务流整体性和数据流一致性，并前瞻性提供未来业务接口。
2） 系统稳定性：
硬件环境稳定性、软件运行异常处理和正常运行情况。
3） 系统可维护性：
含网络系统管理和维护、服务器系统平台管理和维护、操作系统管理和维护、应用系统软件管理和维护、数据库管理和维护和数据库备份、应用系统备份，灾难事件处理和处理实施方案等。
4） 系统文档：
验收文档是否齐全、规范、正确、具体，关键文档包含：
需求分析汇报，框架设计汇报，数据库物理及逻辑设计汇报，具体设计汇报，编码规范及技术选型汇报，测试汇报，系统布署和公布汇报，集成方案，软件用户使用手册，系统维护方案和操作文档等。
5） 代码规范及注释说明：
程序代码编写是否规范；注释说明或代码文档是否具体全方面；接口定义是否符合局信息系统计划一致性要求。
6） 系统灵活性：
系统是否方便用户进行维护；系统是否在优异性基础上含有未来升级和可扩充性；是否利于系统平台迁移和布署等。
7） 系统可操作性：
界面是否友好性；是否实现傻瓜化操作和智能化数据检索功效。
8） 系统安全性：
是否有完善安全机制确保系统安全性，如软件方面安全防范（加密方法、相关认证、数据库安全防范），硬件方面（防火墙、物理隔离和逻辑隔离）安全设置。
9） 其它验收标准：
其它和本系统相关验收标准。
系统终验步骤安排
1） 我企业根据项目验收计划完成验收准备工作 2） 用户代表运行验收测试用例集，统计运行结果
3） 假如发觉没有经过验收测试用例，则我企业立即处理问题 4） 用户主持项目验收会
5） 我企业向用户汇报项目实施结果 6） 用户代表向用户汇报试运行结果
7） 用户评议项目实施和试运行结果，起草和审定项目验收汇报。
1.2.5. 系统终验相关文档
我企业在软件开发和系统集成中将严格根据国家软件工程相关要求提供文档来提供，验收技术文档最少包含以下内容：
1）系统需求分析
2）系统概要设计
3） 系统具体设计
4） 数据库具体设计
5） 应用系统集成实施方案
6） 系统测试纲领
7） 系统测试汇报
8） 系统验收汇报
9） 系统用户使用手册
10） 系统安装维护管理手册
1.2.6. 终验汇报
验收小组将在终验结束后提交一份由教授署名验收汇报。
验收汇报附平台系统和整体系统测试结果汇报，同时给出以下明确结论之一：
1）经过验收；
2）基础经过验收，要求在五个工作日内完善后再次进行验收；
3）未经过验收，要求在十五个工作日内更正后再次进行验收； 如再次验收后仍然不能全部经过，用户有权终止协议，并要求我企业负担违约责任。
验收结束时,我企业将平台系统相关产品说明书、系统安装手册、技术文档、资料及安装、测试、验收汇报等文档聚集成册交付用户。
升级会员 