软件测试计划.docx
《软件测试计划.docx》由会员分享，可在线阅读，更多相关《软件测试计划.docx（21页珍藏版）》请在冰豆网上搜索。
软件测试计划
沃尔沃物流解决方案
测试计划书
编号：
51win-VOLVO-02-JH-003-V1.0.2
作者：
日期：
审批：
日期：
变更记录
日期
版本
变更说明
作者
目录
1引言4
1.1目的4
1.2背景5
1.3范围5
1.4定义、缩略语5
1.5项目核实7
1.6参考资料7
2项目总览9
2.1基本信息9
2.2测试类型9
2.2.1功能测试9
2.2.2业务周期测试10
2.2.3用户界面测试10
2.2.4性能评测11
2.2.5负载测试12
2.2.6强度测试13
2.2.7容量测试14
2.2.8安全性和访问控制测试14
2.2.9配置测试15
2.3工具16
2.4角色及职责17
2.5人员培训需求18
2.6假设和约束18
2.7测试质量目标19
2.8测试项目停止标准19
3测试计划20
3.1计划测试覆盖率20
3.2里程碑和提交产品20
3.3WBS20
3.4工作量估算20
3.5进度安排（时间、人员）21
3.6项目评审21
3.7测试环境21
4测试跟踪计划22
5附录A：
项目任务23
1引言
本文档（《软件测试计划说明书》）是描述薪酬管理系统的测试计划。
此章节是整个文档的概览。
本文档的状态分为草案状态、提交状态、审核状态、确认状态、修订状态。
●草案状态：
本文档的草案，测试人员根据对用户需求的理解形成的最初文档
●提交状态：
草案状态文稿在经过测试组内部讨论通过以后向用户提交进行审核的状态。
如果测试人员在测试后表示绝大多数内容能与开发组达成共识，则文档进入审核状态。
如果测试人员表示有较多内容需要修改，则文档重新回到草案状态。
●审核状态：
如果测试人员已经与测试组在系统性能上达成基本共识，本文档的只需要进行细节的修葺就能最终确立，则文档处于审核状态。
●确认状态：
文档已经与测试人员达成共识，文档内容已经被确立
●修订状态：
测试人员需要对确认状态文档进行修改，则文档进入修订状态，修订状态文档必须交由测试人员重新审核重新进入确认状态。
该文档目前处于：
提交状态
1.1目的
本文档应当在经过用户审核后应该具有如下特性:
●本文档阐明了软件产品的最终测试（规格）
●本文档是用户及测试组对系统最终功能和性能的共识或者双方认识折衷的结果
●用户及与测试相关的人员可以在本文档最终确立后对文档内容进行修订，但是必须在初次审核通过的时候确保文档的内容在当时最大限度的描述了用户的需要
●用户可以在文档确定后，系统开发中，最终软件产品向用户提交前对文档内容进行修改，但是任何修改不允许超过《项目开发计划书》中的变更管理规定。
1.2背景
企业薪酬管理系统为完成薪酬管理的信息化平台，能够完成薪酬配置、发放、员工信息管理。
1.3范围
本文档使用对象：
测试人员
本文档开发方：
中关村软件园实训基地
1.4定义、缩略语
（此处的名词定义不一定是普遍意义的名词定义，而是在本系统中这些词汇所含有的含义）
●软件测试：
在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。
测试的目标：
以较少的用例、时间和人力找出软件中潜在的各种错误和缺陷，以确保系统的质量。
●黑盒测试：
黑盒测试又称为功能测试或数据驱动测试，把系统看成一个黑盒子，不考虑程序的内在逻辑，只根据需求规格说明书的要求来检查程序的功能是否符合它的功能说明。
●白盒测试:
又称为结构测试和逻辑驱动测试，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。
●测试用例:
由测试输入数据以及与之对应的输出结果组成。
测试用例设计的好坏直接决定了测试的效果和结果。
从测试实际的前后过程来看，软件测试上是由一系列的不同测试所组成，这些软件测试的步骤分为：
单元测试、组装测试（集成测试）、确认测试和系统测试。
软件开发的过程是自顶向下的，测试则正好相反，以上这些过程就是自底向上，逐步集成的。
●单元测试:
针对每个模块进行的测试，可从程序的内部结构出发设计测试用例，多个模块可以平行地对立地测试。
通常在编码阶段进行，必要的时候要制作驱动模块和桩模块。
集成测试：
在单元测试的基础上，将所有模块按照设计要求组装成为系统，必须精心计划，应提交集成测试计划、集成测试规格说明和集成测试分析报告。
●确认测试：
验证软件的功能和性能及其它特性是否与用户的要求一致。
●系统测试：
将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试。
●角色（Actor）：
在系统中执行一系列相关操作的人员，是抽象的职责定义，这是一个抽象后的概念，就是说它不是与现实中的某一个人对应的。
例如，在系统中会出现“读者”和“图书管理人员”这样不同的角色，区分的原因是他们的操作在系统中执行不同的职能。
在系统中角色一般是系统的使用者或者是系统所操纵的硬件设备或者是和本系统相关联的其他计算机系统
●活动（Activity）：
角色为完成某个目标而采取的一系行动，活动由角色进行，是角色的职责，活动一般有其期待形式的输入，也有角色想获取的结果，活动强调的是，活动由谁来执行，活动什么时候进行，活动的输入是什么，活动的输出是什么。
●白盒测试用例设计包括：
1.逻辑覆盖，以程序内在逻辑结构为基础的测试，包括以下5种类型：
2.语句覆盖：
每一条可执行语句至少覆盖一次；
3.判定覆盖（分支覆盖）：
设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次；
4.条件覆盖：
设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次；
5.判定-条件覆盖：
设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的所有可能取值至少执行一次，并且每个可能的判断结果也至少执行一次；
条件组合测试：
设计足够多的测试用例，运行所测程序，使程序中每个判断的所有可能的条件取值至少执行一次；
6.路径测试：
设计足够多的测试用例，运行所测程序，要覆盖程序中所有可能的路径
●基本路径测试:
在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。
包括以下5个方面：
1.程序的控制流图：
描述程序控制流的一种图示方法。
2.程序环境复杂性：
McCabe复杂性度量。
从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行依次所必须的测试用例数目的上界。
3.导出测试用例
4.准备测试用例，确保基本路径集中的每一条路径的执行
5.图形矩阵：
是在基本路径测试中起辅助作用的软件工具，利用它可以实现自动地确定一个基本路径集.
●黑盒测试用例设计包括：
等价类划分：
划分等价类--确立测试用例--设计用例
边界值分析：
通过分析，考虑如何确立边界情况错误推测法：
靠经验和直觉来推测程序中可能存在的各种错误，从而有针对性地编写用例。
可以列举出可能的错误和可能发生错误的地方，然后选择用例。
因果图：
通过画因果图，在图上标明约束和限制，转换成判定表，然后设计测试
用例。
这适合于检查程序输入条件的各种组合情况。
功能图FD：
通过形式化地表示程序的功能说明，并机械地生成功能图的测试用例。
1.5项目核实
下表列出了制定测试计划时所使用的文档，并标明了各文档的可用性：
（文档项可适当删减或增加）
《软件需求规格说明书》
《软件项目开发计划书》
《软件测试过程》
《软件配置管理计划》
文档
（版本/日期）
已创建或可用
已被接收或已经过复审
作者或来源
备注
软件需求规格说明书
■是☐否
■是☐否
软件项目开发计划书
■是☐否
☐是■否
郑贤
软件测试计划
☐是☐否
☐是☐否
软件配置管理计划
■是☐否
☐是■否
普芳
项目或业务风险评估
■是☐否
■是☐否
孔德风
1.6参考资料
●为确保软件质量，本次软件工程过程采用全球软件工程领袖Rational©提倡的RUP（RationalUnifiedProcess,理性统一过程，或称为Rational统一过程或统一过程），Rational©的相关信息请参考：
●RUP方法：
●本文档与IEEE93类型文档兼容，请参阅：
IEEEStd830-1993.
●国标（GB）文档标准请参照《软件测试说明书（SRS）》：
GB856T-88（1991）
●国标《计算机软件开发规范》GB8566
●国标《计算机软件产品开发文件编制指南》GB8567
●国标《软件工程术语》GB/T11457
2项目总览
2.1基本信息
项目名称
企业薪酬管理系统
项目编号
项目开始时间
项目结束时间
客户名称
项目经理
测试负责人
技术经理
测试工程师
2.2测试类型
本节将对系统进行相关需求分析,主要分为功能性需求和非功能性需求两大部分,你可以重点阅读功能性需求部分。
2.2.1功能测试
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。
这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。
此类测试基于黑盒技术，该技术通过图形用户界面（GUI）与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。
以下为各种应用程序列出了推荐使用的测试概要：
测试目标：
确保测试对象的功能正常，其中包括导航、数据输入、处理和检索等功能。
技术：
利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：
⎽在使用有效数据时得到预期的结果。
⎽在使用无效数据时显示相应的错误消息或警告消息。
⎽各业务规则都得到了正确的应用。
完成标准：
⎽所计划的测试已全部执行。
⎽所发现的缺陷已全部解决。
需考虑的特殊事项：
[确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）
2.2.2业务周期测试
业务周期测试应模拟在一段时间内对本糸统执行的活动。
应先确定一个时间段（例如一年），然后执行将在该时间段（一年内）发生的事务和活动。
这种测试包括所有的日、周和月周期，以及所有与日期相关的事件（如备忘录）。
测试目标
确保测试对象及背景的进程都按照所要求的业务模型和时间表正确运行。
技术：
通过执行以下活动，测试将模拟若干个业务周期：
⎽将修改或改进对测试对象进行的功能测试，以增加每项功能的执行次数，从而在指定的时间段内模拟若干个不同的用户。
⎽将使用有效的和无效的数据或时间段来执行所有与时间或数据相关的功能。
⎽将在适当的时间执行或启用所有周期性出现的功能。
⎽在测试中还将使用有效的和无效的数据，以核实以下内容：
⎽在使用有效数据时得到预期的结果。
⎽在使用无效数据时显示相应的错误消息或警告消息。
⎽各业务规则都得到了正确的应用。
完成标准：
⎽所计划的测试已全部执行。
⎽所发现的缺陷已全部解决。
需考虑的特殊事项：
⎽系统日期和事件可能需要特殊的支持活动
⎽需要通过业务模型来确定相应的测试需求和测试过程。
2.2.3用户界面测试
用户界面（UI）测试用于核实用户与软件之间的交互。
UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。
另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。
测试目标：
核实以下内容：
⎽通过测试对象进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab健、鼠标移动、和快捷键）的使用
⎽窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准。
技术：
为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。
完成标准：
成功地核实出各个窗口都与基准版本保持一致，或符合可接受标准
需考虑的特殊事项：
并不是所有定制或第三方对象的特征都可访问。
2.2.4 性能评测
性能评测是一种性能测试，它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。
性能评测的目标是核实性能需求是否都已满足。
实施和执行性能评测的目的是将测试对象的性能行为当作条件（例如工作量或硬件配置）的一种函数来进行评测和微调。
注：
以下所说的事务是指“逻辑业务事务”。
这种事务被定义为将由系统的某个Actor通过使用测试对象来执行的特定用例，例如，添加或修改给定的合同。
测试目标：
核实所指定的事务或业务功能在以下情况下的性能行为：
⎽正常的预期工作量
⎽预期的最繁重工作量
技术：
⎽使用为功能或业务周期测试制定的测试过程。
⎽通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的迭代数量。
⎽脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基准），并在多个客户机（虚拟的或实际的客户机，请参见下面的“需要考虑的特殊事项”）上重复。
完成标准：
⎽单个事务或单个用户：
在每个事务所预期或要求的时间范围内成功地完成测试脚本，没有发生任何故障。
⎽多个事务或多个用户：
在可接受的时间范围内成功地完成测试脚本，没有发生任何故障。
需考虑的特殊事项：
综合的性能测试还包括在服务器上添加后台工作量。
可采用多种方法来执行此操作，其中包括：
⎽直接将“事务强行分配到”服务器上，这通常以“结构化查询语言”（SQL）调用的形式来实现。
⎽通过创建“虚拟的”用户负载来模拟许多个（通常为数百个）客户机。
此负载可通过“远程终端仿真”（RemoteTerminalEmulation）工具来实现。
此技术还可用于在网络中加载“流量”。
⎽使用多台实际客户机（每台客户机都运行测试脚本）在系统上添加负载。
性能测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。
性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。
2.2.5负载测试
负载测试是一种性能测试。
在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。
负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。
此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
注：
以下所说的事务是指“逻辑业务事务”。
这种事务被定义为将由系统的某个最终用户通过使用应用程序来执行的特定功能，例如，添加或修改给定的合同。
测试目标：
核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。
技术：
⎽使用为功能或业务周期测试制定的测试。
⎽通过修改数据文件来增加事务数量，或通过修改测试来增加每项事务发生的次数。
完成标准：
多个事务或多个用户：
在可接受的时间范围内成功地完成测试，没有发生任何故障。
需考虑的特殊事项：
⎽负载测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。
⎽负载测试所用的数据库应该是实际大小或相同缩放比例的数据库。
2.2.6强度测试
强度测试是一种性能测试，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。
如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。
而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。
强度测试还可用于确定测试对象能够处理的最大工作量。
注：
以下提到的事务都是指逻辑业务事务。
测试目标：
核实测试对象能够在以下强度条件下正常运行，不会出现任何错误：
⎽服务器上几乎没有或根本没有可用的内存（RAM和DASD）
⎽连接或模拟了最大实际（实际允许）数量的客户机
⎽多个用户对相同的数据或账户执行相同的事务
⎽最繁重的事务量或最差的事务组合（请参见上面的“性能测试”）。
注：
强度测试的目标可表述为确定和记录那些使系统无法继续正常运行的的情况或条件。
技术：
⎽使用为性能评测或负载测试制定的测试。
⎽要对有限的资源进行测试，就应该在一台计算机上运行测试，而且应该减少或限制服务器上的RAM和DASD。
⎽对于其他强度测试，应该使用多台客户机来运行相同的测试或互补的测试，以产生最繁重的事务量或最差的事务组合。
完成标准：
所计划的测试已全部执行，并且在达到或超出指定的系统限制时没有出现任何软件故障，或者导致系统出现故障的条件并不在指定的条件范围之内。
需考虑的特殊事项：
⎽如果要增加网络工作强度，可能会需要使用网络工具来给网络加载消息或信息包。
⎽应该暂时减少用于系统的DASD，以限制数据库可用空间的增长。
⎽使多个客户机对相同的记录或数据账户同时进行的访问达到同步。
2.2.7容量测试
容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。
容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。
例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。
测试目标：
核实测试对象在以下高容量条件下能否正常运行：
⎽连接或模拟了最大（实际或实际允许）数量的客户机，所有客户机在长时间内执行相同的、且情况（性能）最坏的业务功能。
⎽已达到最大的数据库大小（实际的或按比例缩放的），而且同时执行了多个查询或报表事务。
技术：
⎽使用为性能评测或负载测试制定的测试。
⎽应该使用多台客户机来运行相同的测试或互补的测试，以便在长时间内产生最繁重的事务量或最差的事务组合（请参见上面的“强度测试”）。
⎽创建最大的数据库大小（实际的、按比例缩放的、或填充了代表性数据的数据库），并使用多台客户机在长时间内同时运行查询和报表事务。
完成标准：
⎽所计划的测试已全部执行，而且在达到或超出指定的系统限制时没有出现任何软件故障。
需考虑的特殊事项：
对于上述的高容量条件，哪个时间段是可以接受的时间？
2.2.8安全性和访问控制测试
安全性和访问控制测试侧重于安全性的两个关键方面：
⎽应用程序级别的安全性，包括对数据或业务功能的访问
⎽系统级别的安全性，包括对系统的登录或远程访问。
应用程序级别的安全性可确保：
在预期的安全性情况下，Actor只能访问特定的功能或用例，或者只能访问有限的数据。
例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。
如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。
系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。
测试目标：
⎽ 应用程序级别的安全性：
核实Actor只能访问其所属用户类型已被授权访问的那些功能或数据。
⎽ 系统级别的安全性：
核实只有具备系统和应用程序访问权限的Actor才能访问系统和应用程序。
技术：
⎽ 应用程序级别的安全性：
确定并列出各用户类型及其被授权访问的功能或数据。
⎽为各用户类型创建测试，并通过创建各用户类型所特有的事务来核实其权限。
⎽修改用户类型并为相同的用户重新运行测试。
对于每种用户类型，确保正确地提供或拒绝了这些附加的功能或数据。
⎽ 系统级别的访问：
请参见以下的“需考虑的特殊事项”
完成标准：
各种已知的Actor类型都可访问相应的功能或数据，而且所有事务都按照预期的方式运行，并在先前的应用程序功能测试中运行了所有的事务。
需考虑的特殊事项：
必须与相应的网络或系统管理员一起对系统访问权进行检查和讨论。
由于此测试可能是网络管理或系统管理的职能，可能会不需要执行此测试。
2.2.9配置测试
配置测试核实测试对象在不同的软件和硬件配置中的运行情况。
在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。
客户机工作站可能会安装不同的软件⎽例如，应用程序、驱动程序等⎽而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。
测试目标：
核实测试对象可在所需的硬件和软件配置中正常运行。
技术：
⎽使用功能测试脚本。
⎽在测试过程中或在测试开始之前，打开各种与非测试对象相关的软件（例如Microsoft应用程序：
Excel和Word），然后将其关闭。
⎽执行所选的事务，以模拟Actor与测试对象软件和非测试对象软件之间的交互。
⎽重复上述步骤，尽量减少客户机工作站上的常规可用内存。
完成标准：
对于测试对象软件和非测试对象软件的各种组合，所有事务都成功完成，没有出现任何故障。
需考虑的特殊事项：
⎽需要、可以使用并可以通过桌面访问哪种非测试对象软件？
⎽通常使用的是哪些应用程序？
⎽应用程序正在运行什么数据？
例如，在Excel中打开的大型电子表格，或是在Word中打开的100页文档。
⎽作为此测试的一部分，应将整个系统、Netware、网络服务器、数据库等都记录下来。
2.3工具
此项目将使用以下工具：
注：
可适当地删除或添加工具项。
工具
产商/自产
版本
测试管理
AstraQuickTest
MercuryInteractiveWinrunner
MercuryInteractiveWinrunnerProE19.1
缺陷跟踪
TestDirector
Compuware
CompuwareWIDGETENGINE3.8.2ibuild7.91
用于功能性测试的ASQ工具
RationalQuantify
Rational
Rationalver0.8.32002-2003MYamaguchi
用于性能测试的ASQ工具
RationalQuantifyPurify
Rational
Rationalver0.8.12002-2003isfreeware
测试覆盖监测器或评测
Edition,EcoScope,TrackRecord
TestFactory
E
升级会员 