系统测试计划书.docx
《系统测试计划书.docx》由会员分享，可在线阅读，更多相关《系统测试计划书.docx（8页珍藏版）》请在冰豆网上搜索。
系统测试计划书
系统测试计划
一、系统测试概要
系统测试是对解决方案蓝图的真实模拟，通过模拟客户真实的业务环境，对系统切换上线后的使用情况进行预测.测试内容包括软件的正确性、容错性、易用性和效率，要尽可能全面地模拟真实的生产系统，发现有可能发生的错误，并及时修改错误,对发现的业务解决方案中不妥之处也要做出调整.总之，系统测试的目的就是保证一套合理的业务解决方案能够在一套经过测试的软件上正确地、有效率地运行,使软件满足客户需求。
系统测试是系统顺利切换的关键环节，保证测试效果的关键是完善的测试方案。
二、测试范围
1、软件模块：
2、测试人员：
人员
角色及职责
李越
单元测试
彭一兵
周婷
系统测试
席钌姿
刘佳玮
集成测试
邹巧丽
曾奇阴
各种模板及测试报告书设计
李文静
3测试类型：
测试类型
优先级
测试目标
技术
完成标准
其他事项
功能测试
高、中、低
列出此类型测试所要达到的测试目标.
列出执行此类型测试是采纳的方法或依据（工具、语言等）。
如所有的计划已执行完成，或所有的缺陷已全部解决等.
确定且说明那些将对该类测试的实施和执行造成影响的事项或内部/外部的因素。
界面测试
性能测试
性能评价
负载测试
强度测试
压力测试
效率测试
报表测试
安全性测试
多用户测试
容量测试
配置测试
安装\卸载测试
加密测试
界面测试：
通过用户界面（UI）测试来核实用户与软件的交互。
UI测试的目标在于确保用户界面向用户提供了适当的访问和浏览测试对象功能的操作。
除此之外，UI测试还要确保UI功能内部的对象符合预期要求，并遵循公司发布的VIS标准。
性能评价是一种性能测试，它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。
性能评价的目标是核实性能需求是否都已满足.实施和执行性能评价的目的是将测试对象的性能行为当作条件（如工作量或硬件配置）的一种函数来进行评价和微调。
负载测试是一种性能测试。
在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。
负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行.此外,负载测试还要评估性能特征,例如，响应时间、事务处理速率和其它与时间相关的方面.
强度测试是一种性能测试，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。
如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。
而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。
强度测试还可用于确定测试对象能够处理的最大工作量。
压力测试：
参考性能评价和负载测试（在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询等）。
效率测试:
参考性能评价和负载测试（画面输入延时、最大/小报表查询时间）。
容量测试:
使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限.容量测试还将确定测试对象在给定时间内是否能够持续处理的最大负载或工作量.例如，如果测试对象正在为生成一份报表而处理一组数据库记录,那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。
配置测试核实测试对象在不同的软件和硬件配置中的运行情况。
在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。
客户机工作站可能会安装不同的软件，例如，应用程序、驱动程序等。
而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源.
安全性和访问控制测试侧重于安全性的两个关键方面：
∙应用程序级别的安全性,包括对数据或业务功能的访问；
∙系统级别的安全性,包括对系统的登录或远程访问.
应用程序级别的安全性可确保:
在预期的安全性情况下,主角只能访问特定的功能或用例，或者只能访问有限的数据。
例如，可能会允许所有人输入数据，创建新账户，但只有经理才能删除这些数据或账户。
如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户信息（包括财务数据），而“用户二”只能看见同一客户的统计数据。
系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。
三、测试方法
1、单元测试
单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等.它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。
因为单元测试需要知道内部程序设计和编码的细节知识，一般应由程序员而非测试员来完成，往往需要开发测试驱动模块和桩模块来辅助完成单元测试。
因此应用系统有一个设计很好的体系结构就显得尤为重要.
一个软件单元的正确性是相对于该单元的规约而言的。
因此，单元测试以被测试单位的规约为基准.单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。
单元测试方法单元测试的方法只有两种基本的测试方法,一个是代码复查,一个是编写测试程序。
这是两种手工的单元测试方法。
一些软件公司使用代码复查方式进行单元测试。
这种测试方法容易受到人为因素的影响。
它非常依赖于测试人员的技术水平,有时检查者发现不了错误，有时又把正确的解决方案认为是错误的。
其次，代码复查在回归测试时工作量非常巨大.当一个单元因为某种原因发生改变时，就必须对这个单元重新进行测试,这会使单元测试的工作量成倍增长。
为了克服这种现象,最好采用重构技术，通过代码重构和数据重构进行重新梳理.编写测试码是单元测试的第二种方法。
编写测试程序首先要求测试对象具有很好的内敛性及可测试性,其次开发的测试驱动程序、稳定桩要保证测试用例的完整性。
测试用例的选择是一个具有策略性的决定，它取决于软件质量、可用资源、已有的测度文档和风险分析的综合结果。
每个测试用例的结果都必须进行记录.测试驱动程序开发，先编写测试代码，再进行开发。
先编写产品函数的框架,然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码,每写一个功能点都运行测试,随时补充测试用例。
所谓先编写产品函数的框架,是指先编写函数空的实现,有返回值的随便返回一个值，编译通过后再编写测试代码，这时,函数名、参数表、返回类型都应该确定下来了,所编写的测试代码以后需修改的可能性比较小.
单元测试工具目前很多软件公司开发出了单元测试框架，使得测试程序正逐步变得半自动化,大大缩短了开发测试程序的时间。
这些测试工具是：
首先是CppUnit，这是C++单元测试工具的鼻祖，免费的开源的单元测试框架。
然后是C++Test，这是Parasoft公司的产品.C++Test是一个功能强大的自动化C/C++单元级测试工具,可以自动测试任何C/C++函数、类,自动生成测试用例、测试驱动函数或桩函数,在自动化的环境下极其容易快速的将单元级的测试覆盖率达到100％.最后是VisualUnit,简称VU，这是国产的单元测试工具，拥有一批创新的技术,自动生成测试代码，快速建立功能测试用例,程序行为一目了然，极高的测试完整性。
使用VU还能提高编码的效率，总体来说，在完成单元测试的同时，编码调试的时间还能大幅度缩短。
2、集成测试
集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确.它根据集成测试计划,一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。
集成测试的策略主要有自顶向下和自底向上两种。
集成测试是一种正规测试过程,必须精心计划，并与单元测试的完成时间协调起来.在制定测试计划时，应考虑如下因素:
1、是采用何种组装方法来进行组装测试；
2、组装测试过程中连接各个模块的顺序;
3、模块代码编制和测试进度是否与组装测试的顺序一致；
4、测试过程中是否需要专门的硬件设备；
解决了上述问题后，就可以列出各个模块的编制、测试计划表，表明各个模块单元测试完成日期、首次完成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。
最后要判定集成测试过程完成以否。
3、系统测试
系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题"。
因此，系统测试应该按照测试计划进行,其输入、输出和其他动态运行行为应该与软件规约进行对比。
软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。
测试人员在编写测试计划之前，应获得以下文档：
1）程序经理编写的产品功能说明书或产品开发计划；
2）程序经理或开发人员提供的开发进度表。
根据产品的特性及开发进度安排，测试人员制定具体的测试计划.测试计划通常包括以下内容：
1）测试目标和发布条件：
a。
给出清晰的测试目标描述;
b。
定义产品的发布条件,即在达到何种测试目标的前提下才可以发布产品的某个特定版本。
2）待测产品范围：
a。
软件主要特性/功能说明，即待测软件主要特性的列表;
b。
特性/功能测试一览，应涵盖所有特性、对话框、菜单和错误信息等待测内容,并列举每个测试范围内要重点考虑的关键功能。
3）测试方法描述:
a。
定义测试软件产品时使用的测试方法；
b。
描述每一种特定的测试方法可以覆盖哪些测试范围.
4）测试进度表：
a。
定义测试里程碑;
b。
定义当前里程碑的详细测试进度。
5）测试资源和相关的程序经理/开发工程师:
a。
定义参与测试的人员；
b。
描述每位测试人员的职责范围；
c.给出与测试有关的程序经理/开发工程师的相关信息。
6）配置范围和测试工具：
a。
给出测试时使用的所有计算机平台列表;
b。
描述测试覆盖了哪些硬件设备；
c.测试时使用的主要测试工具.
四、测试过程
1、测试环境准备
测试环境的准备主要由客户方系统管理员完成，技术顾问提供支持。
完成相应的安装记录文档，系统管理员应该在初始化的关键点备份并归档数据库。
应明确规定安装完成时间和负责人。
安装完成时间/负责人
应用服务器/数据库服务器地址
数据库备份方式/时间
数据库备份存档位置
…。
.。
2、测试用例编写
在环境准备的同时，关键用户应在顾问辅助下完成测试用例的编写。
测试用例应能覆盖业务解决方案中的所有业务流程，分为以下三种类型，测试过程应该循序渐进,由易到难，由简而繁进行。
测试用例可以安排关键用户互相审核，顾问也可以承担一部分复杂用例的审核。
1）产品功能点的测试
对产品的功能点进行逐一测试确认.
2）单元测试
比如总帐，从时间范围讲，应该从制单开始,出纳签字、审核、记帐、结转定义、月末结转、期间结帐、到年末结帐为止，使用可能发生的最长的业务流程来设计测试用例.
3）集成测试
集成测试跨越产品多个模块，如为了完成产、供、销等一系列完整业务，测试用例涉及销售模块、生产管理、采购等多个模块，测试时销售人员、采购人员、生产计划员、库管员、财务人员等需要协同工作，模块间数据正确性、流程完整性连贯性的测试应该是模拟测试的重点，客户方人员可能因为分共较细不能完成此部分测试用例设计,应用顾问应该发挥咨询实施经验来帮助客户设计用例。
业务流程
测试用例编码
测试过程描述
预期结果
实际结果
结果是否正确
作者
审核人
测试人
销售订单下达
T1
步骤1（SD-C1）
xxxx
xxxx
步骤2（PP-C1）
xxxx
xxxx
步骤3（FI-C1）
xxxx
xxxx
…。
xxxx
xxxx
步骤n（xx-xx）
xxxx
xxxx
3、系统初始化
测试用例落实之后,就可以进行系统的初始化，对关键用户来说这是一个熟悉产品的机会.
1）静态数据录入，数据来静态数据准备－《静态数据准备方案》中确定的系统参数、基本档案、业务流程配置等信息。
录入、检查之后，请备份数据库进行存档，这份完成静态数据初始化的数据库备份会很有用。
2）动态数据的准备和录入，实施过程中的动态数据准备和转换是在系统切换阶段进行的,此时可以把客户方的前几个月的真实历史数据取来进行准备和录入。
如下是期初余额的数据准备和录入
辅助项
科目名称
辅助项1
辅助项1
辅助项3
1001
5112
4、测试风险
列出可能会影响测试设计、开发或实施的所有风险或意外事件.
请将严重性最大的风险列在表的最前面.
序号
风险
可能性
潜在的影响
严重性
预防／处理措施
可能的征兆
1
2
5、测试记录和结果反馈
在测试过程中，如对具体操作有不解之处,或系统存在错误，应及时向项目组咨询和反映，如在测试结束时，错误仍未解决，则在“测试问题记录单"中记录下该错误，提交给项目组。
在测试过程中，如发现原应用方案存在不完善之处，或原方案不可行,则在方案测试记录中注明此方案不可行，并填写“应用方案调整报告"，说明调整内容和调整的原因，及时发送给项目组。
各单位和各测试人员测试完成后，在XX月XX日前将测试结果的书面文档（经测试人确认的方案测试记录）上报给向项目组。
升级会员 