软件测试及验收Word格式.docx
《软件测试及验收Word格式.docx》由会员分享，可在线阅读，更多相关《软件测试及验收Word格式.docx（15页珍藏版）》请在冰豆网上搜索。
1.2.2单元测试采用的方法、技术与内容
我们进行单元测试主要采用白盒测试技术，由编码人员使用控制流覆盖和数据流覆盖等测试方法设计测试用例，主要测试内容包括单元功能测试、单元性能测试和异常处理测试等。
1.2.3单元测试实施流程
单元测试流程分为单元测试设计，单元测试准备，单元测试实施和记录，单元测试错误跟踪。
Ø
单元测试设计也就是单元测试用例设计，由系统设计人员在详细设计的同时完成。
单元测试准备为按照测试用例的要求，准备单元测试驱动数据和驱动模块，由编码开发人员在开发过程中完成。
单元测试实施和记录由开发人员在编码完成以后进行。
单元测试问题跟踪由开发人员和系统设计人员共同完成，根据引起问题的不同原因进行不同处理。
如果测试问题为编码错误，则由编码开发人员完成纠错后重新测试。
如果测试问题为设计阶段引起的问题，则需要进行设计变更。
通过单元测试的程序，进入配置管理系统。
1.2.4单元测试用例
单元测试用例是由编码人员根据《系统详细设计说明书》对完成编码的每个用例的功能进行分析，采用功能确认、异常处理、分支覆盖、边界检验、数据检验等方法设计测试用例，并形成《单元测试用例》文档，所设计的测试用例尽可能覆盖用例的所有功能。
1.3集成测试方案
1.3.1集成测试目的
集成测试是指根据系统的概要设计及系统的详细设计的有关说明，对系统的各单元进行组装，把分离的系统单元组装为完整的可执行的计算机软件。
集成测试的目的是检查软件单元部件是否能够集成为一个整体，完成一定的功能，并找出单元测试中没有发现的错误，包括数据定义有没有重合与冲突，接口会不会产生错误，组合以后的模块功能会不会互相影响，组合的系统是不是达到预期的效果等。
项目开发采用了模块化和组件式的开发技术，通过构建业务组件，来完成业务系统的开发，因此，当单个模块或者是组件集成为系统的过程中，软件仍然可能出现问题。
如：
穿越模块接口的数据是否丢失；
一个模块功能的实现可能破坏了另一个模块的功能；
子功能组合之后不一定可以达到预期的功能；
全局数据可能被异常修改等等，因此，在模块集成的时候进行整体测试就可以尽量发现可能出现的问题。
1.3.2集成测试采用的方法、技术和内容
集成测试采用白盒测试和黑盒测试相结合的测试技术和渐增式的测试策略，用调用对和数据流等测试方法设计测试用例。
主要测试内容包括单元之间的接口测试、全局数据结构测试等。
在集成测试中，我们主要采用了关注关键模块测试的方法，也就是说，我们在测试时，关注满足某些软件需求的、程序的模块结构中位于较高的层次的、较复杂、较易发生错误的和有明确定义的性能要求模块，进行重点测试。
在集成测试的前期，我们采用非增殖式方式和混合增殖方式相结合的方法进行集成测试。
对于模块间关系复杂，数据流量大，模块的输入输出复杂的系统，采用非增殖式方式测试，而对于模块间依赖关系弱，数据传递相对少，流向简单的系统，则采用混合的增殖方式测试。
这种测试方案的步骤是首先对一个个已完成了单元测试的逐步组装成较大的模块，从底至上进行组装。
在集成测试的后期测试中，我们采用的是自顶向下的回归测试方式。
1.3.3集成测试实施流程
集成测试实施包括集成测试设计，集成测试准备，集成测试实施和测试记录、集成测试问题跟踪和结束测试等阶段。
集成测试设计由测试经理根据项目计划和开发计划编制《集成测试计划》，设计《集成测试用例》。
测试计划应当通过项目经理的审查，测试用例将通过测试部门经理的审查。
集成测试准备由测试经理（必要时技术支持部门协助）建立独立的测试环境。
测试环境包括测试硬件环境，网络，数据库，应用服务器，客户机等以及测试对象（程序）的安装和初始化工作。
集成测试和测试记录是由开发经理组织人员按照测试计划和测试用例要求进行测试，并且记录测试过程和测试结果。
回归测试：
在系统设计与开发人员解决了所有的本次集成的问题后，重新提交集成测试，直接所有的问题得到解决。
测试结束指测试问题降低到一定程度并通过测试通过准则时，开发经理编写测试报告，总结本次集成测试的情况，结束测试。
1.3.4集成测试用例
集成测试用例主要是开发人员根据《软件需求规格说明书》、《详细设计说明书》涉及的业务模块和业务功能进行分析，抽取出测试特性，采用语句覆盖、分支覆盖、条件覆盖、路径覆盖（白盒测试）和等价类划分、边界值分析、因果图、错误推测、判定表驱动分析、正交实验设计、功能图分析（黑盒测试）等用例设计方法来设计测试用例，使设计的测试用例能覆盖系统的所有功能模块，尽可能的发现问题。
1.4系统测试方案
1.4.1系统测试目的
系统测试是针对整个产品系统进行的测试，目的是为了验证软件系统是否符合《软件需求规格说明书》定义的要求找出与需求规格不相符合或与之矛盾的地方。
1.4.2独立的测试机构
为保证系统测试结果的客观性和全面性，我公司设立了独立的测试部门，由测试部门经理指派项目测试经理组织独立的测试小组开展测试工作。
测试机构独立于开发部门的优点：
保证测试结果的客观性，测试经理没有参与软件开发工作，完全按照《用户需求规格说明书》组织测试，对软件开发的结果没有主观的评价，测试的结果比较客观可靠。
保证测试过程的全面性，测试经理组织人员对系统进行测试，其行为具备不确定性，因此测试的结果也比较全面。
1.4.3独立的测试环境
测试经理依据《用户需求说明书》中对运行环境的要求建立独立的测试环境，以确保测试环境的有效性和软件的产品的完整性。
摈除开发环境对测试的影响，也就是说不能在原来的开发环境中对系统进行测试，而是要用用独立于开发外的测试环境，可以保证软件的产品和功能的完整性。
摈除开发人员对测试的影响，要求测试者以用户的角度看需求，按照用户的使用方式去测试系统，以用户的眼光评判系统，为用户把好这一关。
1.4.4设计完整、全面的测试内容覆盖
测试设计的完整性、充分性决定了整个系统过程的测试质量。
在系统测试中，为了保证系统测试质量，我们在设计阶段就对系统进行严密的测试设计，从用户层、应用层、功能层、子系统层等多层次多方面来综合考虑系统规格的实现情况。
1.用户层测试：
从操作者的角度，测试系统对用户支持的情况，用户界面的规范性、友好性、可操作性，以及数据的安全性。
主要包括：
用户支持测试：
用户手册、使用帮助、支持客户的其他产品技术手册是否正确、是否易于理解、是否人性化。
用户界面测试：
测试用户界面的风格是否满足用户要求，例如：
界面是否美观、界面是否直观、操作是否友好、是否人性化、易操作性是否较好。
可维护性测试：
可维护性是系统软、硬件实施和维护功能的方便性。
目的是降低维护功能对系统正常运行带来的影响。
例如：
对支持远程维护系统的功能或工具的测试
安全性测试：
安全性主要包括了两部分，数据的安全性和操作的安全性。
核实只有规格规定的数据才可以访问系统，其他不符合规格的数据不能够访问系统；
核实只有规格规定的操作权限才可以访问系统，其他不符合规格的操作权限不能够访问系统；
2.应用层测试：
是针对应用的测试，重点应站在系统应用的角度，模拟实际应用环境，对系统的兼容性、可靠性、性能等进行的测试。
系统性能测试：
针对整个系统的测试，包含并发性能测试、负载测试、压力测试、强度测试、破坏性测试。
并发性能测试是评估系统交易或业务在渐增式并发情况下处理瓶颈以及能够接收业务的性能过程；
强度测试是在资源情况低的情况下，找出因资源不足或资源争用而导致的错误；
破坏性测试重点关注超出系统正常负荷N倍情况下，错误出现状态和出现比率以及错误的恢复能力。
系统可靠性、稳定性测试：
一定负荷的长期使用环境下，系统可靠性、稳定性。
系统兼容性测试：
软件与各种硬件设备兼容性，与操作系统兼容性、与支撑软件的兼容性。
系统组网测试：
组网环境下，系统软件对接入设备的支持情况。
包括功能实现及群集性能。
系统安装升级测试：
安装测试的目的是确保该软件在正常和异常的不同情况下进行安装时都能按预期目标来处理。
例如，正常情况下，第一次安装或升级、完整的或自定义的安装都能进行安装。
异常情况包括磁盘空间不足、缺少目录创建权限等。
还有一个目的是核实软件在安装后可立即正常运行。
另外对安装手册、安装脚本等也需要关注。
3.功能层测试：
主要针对项目的功能实现进行测试。
业务功能的覆盖：
需求规格定义的功能系统是否都已实现。
业务功能的分解：
通过对系统进行黑盒分析，分解测试项及每个测试项关注的测试类型。
业务功能的组合：
业务功能间存在的功能冲突情况。
比如：
共享资源访问等。
4.子系统层测试：
针对软件系统的内部结构性能进行测试，关注子系统内部的性能，模块间接口的瓶颈。
单个子系统的性能：
单个子系统与各种软、硬件、接口配合情况下的整体性能。
子系统间的接口瓶颈：
子系统间通讯请求包的并发瓶颈。
子系统间的相互影响：
子系统的工作状态变化对其他子系统的影响。
1.4.5闭环的测试过程
系统测试过程是一个闭环的过程，它可以循环再进行，它主要包括以下步骤：
测试经理组织测试人员依据《需求规格说明书》编写测试用例。
系统测试由测试经理组织测试人员在搭建的测试环境中进行，测试人员根据测试计划和测试用例测试系统，如发现问题由按测试处理问题方案进行处理。
在系统设计与开发人员解决了所有的本次系统测试问题后，重新提交系统测试，直接所有的问题得到解决。
测试经理综合测试问题情况，分析、总结并填写《系统测试报告》；
项目经理确认测试问题都得到了处理。
测试经理验证测试问题的解决情况，决定软件系统是否可以发布。
1.4.6选用适当的系统测试的方法、技术
系统测试主要采用黑盒测试技术，用功能分解、等价类划分、边界值分析和因果图等测试方法设计测试用例。
1.4.7制订明确的系统测试流程
系统测试包括系统测试设计，系统测试准备，系统测试实施和测试记录，系统测试问题跟踪和结束测试等阶段。
系统测试设计由软件系统测试经理根据项目计划和开发计划编制《系统测试计划》，设计《系统测试用例》。
《测试计划》应当通过项目经理的审查。
《系统测试用例》需通过测试部门经理的审查。
系统测试准备由测试经理（必要时技术支持部门协助下）建立独立的测试环境。
测试环境包括测试硬件环境,网络,数据库,应用服务器,客户机等以及测试对象（程序）的安装和初始化工作。
系统测试实施和测试记录是由测试经理组织测试人员按照《系统测试计划》和《系统测试用例》要求进行测试,并且记录测试过程和测试结果。
系统测试问题跟踪是在测试过程中发现的问题由测试经理根据测试记录提交《测试缺陷跟踪表》,并由系统设计人员和开发人员解决每一个问题的过程。
系统测试结束指《测试缺陷跟踪表》中的问题解决后,进行回归测试。
如果问题降低到预定小的程度并通过测试通过准则时，测试经理提交《系统测试总结报告》结束测试。
我们保证在本项目中，所有向用户发布的产品都是经过了系统测试部测试通过的产品。
1.4.8系统测试用例
此部分说明参照集成测试用例。
1.5用户确认测试
1.5.1确认测试目的
用户确认测试由用户组织，确认软件系统能够满足《用户需求说明书》的要求。
1.5.2确认测试组织
确认测试由用户组织，开发方协助进行。
用户方应当设立确认测试经理，组织相应的测试人员开展测试。
1.5.3确认测试的特点
确认测试与其它测试相比，具有以下几个特点：
确认测试由用户组织、开发商给予全面的支持；
确认测试的环境是独立的环境，是对系统实际运行环境的仿真测试。
1.5.4确认测试工作流程
用户确认测试的工作流程可以参照系统测试工作流程。
我公司提交系统产品后，由实施经理根据《项目计划》制定《确认测试计划》，并与用户方讨论通过后，按计划进行确认测试。
1.5.5确认测试用例
用户确认测试用例主要是由用户根据《软件需求规格说明书》、《用户操作手册》涉及的业务模块和业务功能采用黑盒测试的用例设计方法来设计测试用例，使设计的所有测试用例能遍历测试对象的所有业务功能和模块。
1.6压力测试
压力测试主要是通过编写特定的测试脚本，使用多用户并发（毫秒级并发用户），模拟多个浏览器持续并发访问被测系统，记录系统的相关信息。
评估（基于当前系统运行环境硬件设备、软件的配置）系统的处理性能，以及为评估系统的承受能力，找出性能瓶颈，为优化软件、升级设备提供测试参考数据和依据。
1.6.1压力测试过程
整个测试过程如下图所示：
1.6.2测试策略、模型和工具
测试通过产生虚拟并发用户数和交易数（事务量）的策略和模型来生成测试负载，以此来确认系统在现有系统资源下的最大承受能力。
压力测试工具通过模拟成千上万的用户，发现并确定问题所在，进而对企业级应用系统体系架构执行监测。
由于具备支持多种环境的优势，该工具可测试整个企业的多种应用系统，包括电子商务、ERP、CRM、J2EE架构应用和常规客户/服务器应用，因而能帮助IT和网络部门优化应用性能。
通过模拟实际用户的行为，能支持广泛的通讯协议，如HTTP（s）,SMTP,WinSock等，在测试过程中能实时监测服务器（如Domino及硬件的性能）和网络性能。
常见的压力测试工具有loadrunner等。
1.6.3测试用例及监控数据
序号
用例
最大响应时间（单位：
秒）
1
系统登录
2
网上业务申请
2
3
配置项查询
3
4
统计报表
…
……
具体的测试用例在系统需求调研后再详细补充。
在测试过程中需要监控的数据包括
并发用户数响应时间；
CPU利用率；
Memory使用；
磁盘I/O；
网络流量。
1.7测试缺陷处理方案
在本项目中，所有的测试问题纳入到Scarab工具中进行统一管理。
因此，不管是单元测试中的问题、集成测试中的问题、系统测试中的问题、还是用户确认测试中的问题以及用户使用过程中的问题，都统一分问题发生的阶段与类型进行管理。
1.7.1缺陷统一管理目的
所有的系统开发与实施过程中发生的问题进行统一管理的意义在于：
统一管理，便于问题的记录、跟踪、协调、解决与发布；
便于分析系统各个阶段的质量情况、评价系统的质量以及分析参与系统建设人员的绩效情况。
1.7.2测试缺陷处理状态图
1.7.3测试缺陷处理流程
所有问题按以下流程进行处理，并且所有的问题纳入到版本管理中进行管理。
1.测试人员或者是其他问题提出人提出软件的问题（包括测试问题），在Jira的问题模版中录入问题以及问题的相关情况（如问题发生的阶段、类型、紧急程度、版本等），并将问题发送给测试经理、开发经理以及相关的人员。
2.相关人员可以随时查询问题的情况。
开发经理收到问题后，分配人分析问题：
如果认为该问题需要进行修复，则分配给相关人员进行修复。
如果开发经理分配人同时也是测试问题修复人，则可直接进入第3步；
如果认为该问题描述不清楚或是操作失误引起的，则指出该测试问题不是有效问题；
如果认为该问题已经提出过，则指出该测试问题重复。
3.问题修复人得到分配的测试问题：
如果接受该测试问题，则开始修复；
4.问题修复人在修复过程中：
如果正常修复完成测试问题，则指出修复完成；
如果由于各种原因不能够修复该测试问题，则指出不能修复。
5.测试问题验证人验证修复完的测试问题：
如果认为该问题已经正确修复了，则进行关闭；
如果认为该问题还没有正确修复，则指出验证未通过。
6.对于不能修复的测试问题，项目经理经过分析：
如果认为该问题可以进行修复，则继续分配给相关人员进行修复；
如果认为该问题暂时无法修复，则指出问题遗留。
7.对于进行过程中的测试问题，开发经理可以重新分配该问题给其他人员。
测试缺陷处理流程。
2系统验收方案
2.1硬件采购验收
2.1.1到货验收
开箱后，我公司人员与用户相关人员一起对全部设备、产品、型号、规格、数量、外型、外观、包装及资料、文件（如装箱单、保修单、随箱介质等）的验收。
对全部产品、零件、配件、用户许可证书、资料、介质等进行清点造册登记，并与原厂家随机装箱单进行核对，确保完全相符。
如有出入则详细记载，尽快联系原厂家解决。
我公司保证标书中所采购的产品设备为原厂家全新产品，在数量、质量及性能上完全满足用户的要求，为确保这一目标的实现，我公司届时将提供如下资料：
装箱单、保修服务卡、随箱介质。
使用中文说明和中文维护手册等。
2.1.2系统初验
系统初验根据以上测试方法对本项目所以设备进行单项测试，系统进行联调测试无误后，我公司将编制项目测试报告，提交测试报告给用户审核，完成系统初验。
2.1.3试运行
本系统集成后上线运行三个月为试运行期。
现场排除系统试运行过程中出现的硬件故障及软件故障，对于易出现问题的设备提供备用件。
提供热线电话，接受采购人的随时咨询。
应技术人员的要求，随时讲解系统的结构及设计，包括硬件性能、系统软件、备份结构特点。
2.1.4系统终验
正式验收主要围绕设备的配置、功能、性能及各项技术参数指标进行，完成用户整体的系统验收。
当整个系统进入试运行期，我公司将向用户提供行之有效的技术支持以确保整个业务的稳定和有效地运营，并确保整个业务能够顺利通过系统验收。
在此同时，我公司将通过具体的技术支持帮助用户操作人员熟悉和掌握这些设备和维护技术。
系统试运行期是一个非常重要的时期。
在此期间，由于用户技术人员的技术水平、设备管理、设备操作和具体设备维护之间的磨合，将会出现许多意想不到的问题和人为故障。
因此在系统试运行期，我公司将配合用户的要求提供必要的现场技术支持，同时通过定期维护以避免设备故障的发生。
在通过系统试运行的情况下，项目小组将和用户进行系统终验。
系统调试、验收程序：
按惯例，本工程验收采取过程中定期抽检、全检，最后实行总体验收的方法进行。
程序为报告申请验收，各有关单位会同验收，最后会签认同。
参见下图：
（一）、验收计划将由项目经理提交；
（二）、在我司方面，验收计划将由技术总监批准实施；
（三）、验收结果必须交由甲方（建设单位）、我方共同确认有效，方可存档。
甲方（建设单位）、我方各一份备案。
系统验收将由验收小组进行，验收时做好记录，签署验收证书，并立档、归档。
当验收不合格时，我们将无条件进行返修。
系统的安装验收主要有以下内容：
1）系统设备器材清单明细以及随设备包装的各种附件、资料等是否齐全；
2）各主要设备器材的外观评估与内在技术指标确认；
3）系统安装整体外观效果评估；
4）各系统工程各相关技术文件、现场检查验收记录等是否齐全；
5）系统的安装客观测试；
系统的工程安装验收将按用户需求进行。
2.2应用系统验收标准
项目的验收工作包括两个方面的活动：
文档评审和软件产品包的测试与试运行检验，对于不同的验收活动制定不同的验收通过标准。
衡量被评审文档或被测试软件产品质量的一个重要指标是：
评审或测试发现的缺陷数。
为进一步明确文档或软件产品的质量水平，需要对发现的缺陷按其严重程度进行分类，在本项目中，将对缺陷分为四个等级，如下表所示：
严重等级
分类的解释
严重的
缺陷对进度的影响可能是非常致命的，或者可能是一个停止器——即终止用户继续使用系统
主要的
相同类型的缺陷在很多程序或模块中出现，需要改正每一个缺陷。
例如，在任一程序中没有遵守编程标准。
或者，缺陷终止了用户按正常方式继续前进，但可以绕行
次要的
这个缺陷是独立的缺陷，或者不影响用户继续前进，但会带来不便
普通的
缺陷并不影响软件产品的性能，例如，美观问题和消息中的语法错误等
2.2.1文档评审通过标准
按照评审对象的规模（页数），根据评审投入的工作量和发现的缺陷数来确定是否通过评审：
1.评审投入的工作量（评审准备和评审会议的时间）：
是否在一个合理的范围内，如果投入的评审时间过低，则不论发现的缺陷数如何，都不能通过评审。
2.发现的陷数：
是否在一个合理的范围内，如果发现的缺陷数太多，则不能通过评审。
如果发现的缺陷数低于合理的水平，则需要分析评审过程和评审人员，以便确定是否通过评审。
2.2.2确认测试通过标准
对软件产品包的确认测试，根据测试用例质量、执行测试用例情况和发现的缺陷数来确定是否通过确认测试：
1.测试用例质量：
是否通过评审，如果测试用例没有通过评审，则不能进入确认测试过程。
2.测试用例的执行：
确认测试过程必须保证执行了所有的确认测试用例数据，测试结果得到真实记录。
3.发现的陷数：
与以前阶段成果评审、软件产品的集成测试和系统测试所发现的缺陷数相比，是否在一个合理的范围内。
一般而言，确认测试阶段发现的缺陷数应与确认测试前所有质量控制活动所发现的缺陷总数相比，应在5%至10%之间，并且不应该发现严重的缺陷。
2.2.3系统试运行通过标准
对软件产品包的试运行检验，其通过标准主要是试运行阶段所发现的软件产品的缺陷数。
与软件产品试运行以前所有质量控制活动发现的缺陷总数相比，试运行阶段发现的缺陷数是否在一个合理的范围内。
一般而言，试运行阶段发现的缺陷数应与以前
升级会员 