销售系统测试计划文档格式.doc

1、测试计划拟制人： * 审核人： 批准人：目 录1目的12背景13范围24项目标识25测试需求26测试策略36.1测试类型36.1.1数据和数据库完整性测试36.1.2功能测试46.1.3业务周期测试46.1.4用户界面测试56.1.5性能评价56.1.6负载测试66.1.7强度测试76.1.8容量测试86.1.9安全性和访问控制测试86.1.10故障转移和恢复测试96.1.11配置测试116.1.12安装测试126.2工具137资源137.1 人力资源137.2 支持条件137.3角色147.4系统158项目里程碑159可交付工件1610测试模型16附录 A：项目任务171目的这份测试计划报告

2、书是为了为将来的开发阶段做好详细的测试计划，是下一阶段项目的测试有据可循。该测试计划包括测试对象，测试方法，测试资源，测试工具等内容。2背景1）待开发软件系统的名称：鲜花超市管理系统2） 任务的提出者：*3） 开发者：4） 用户：* 3范围本系统需要测试两大子系统，分别为：前台销售系统和后台管理系统。本计划书主要对鲜花录入、收银业务、进货管理、销售管理、库存管理、人员管理六大模块进行测试。4项目标识下表列出了制定测试计划所用的文档，并标明了文档的可用性：文档（版本/日期）已创建或可用已被接受或已经过复审作者或来源备注需求规约 是 o 否项目计划5测试需求下面列出了那些已被确定为测试对象的项目（

3、用例、功能性需求和非功能性需求）：鲜花录入：鲜花录入子系统要求能快速录入商品，因此必须支持条形码扫描、手工录入编号。收银业务：收银业务子系统能计算交易总额，打印交易清单，并根据会员卡打折。进货管理：进货管理子系统可以根据库存自动指定进货计划，进货时自动等级，以及提供查询和打印计划进货与入库记录的功能。销售管理：查询每种鲜花的销售情况并产生年、月、日报表，同时可以生成销售排行榜。库存管理：库存管理子系统提供查询库存明细记录的基本功能，并根据库存的状态报警，以及自动盘点计算。人员管理：人员管理子系统提供基本信息登记管理，员工操作权限管理，客户销售权限管理的功能。6测试策略测试工件为四个阶段：单元测

4、试、组装测试、确认测试、系统测试单元测试：采用白盒法和黑盒法相结合的方法，对于逻辑结构复杂的模块采用白盒法，对于以输入、输出为主的模块采用黑盒法测试，以提高测试的效率。组装测试：混合法（对软件结构中较上层使用的自顶向下与对软件结构中较下层使用的自底向上方法相结合）。 确认测试：由用户参与按需求规格说明书验收。系统测试：采用人工测试方法。6.1测试类型6.1.1数据和数据库完整性测试鲜花零售系统中，数据库和数据库进程应作为一个子系统来进行鲜花零售系统测试。在鲜花零售系统测试这些子系统时，不应将鲜花零售系统的用户界面用作数据的接口。对于数据库管理系统（DBMS），还需要进行深入的研究，以确定可以支

5、持以下鲜花零售系统测试的工具和技术。鲜花零售系统测试目标：确保数据库访问方法和进程正常运行，数据不会遭到损坏技术：1调用各个数据库访问方法和进程，并在其中填充有效的和无效的数据（或对数据的请求）。2检查数据库，确保数据已按预期的方式填充，并且所有的数据库事件已正常发生；或者检查所返回的数据，确保正当的理由检索到了正确的数据完成标准：所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭到损坏。需考虑的特殊事项：1鲜花零售系统测试可能需要DBMS开发环境或驱动程序在数据库中直接输入或修改数据。2进程应该以手工方式调用。3应使用小型或最小的数据库（记录的数量有限）来使所有无法接受的事件具有更大

6、的可视度。6.1.2功能测试对鲜花零售系统的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面（GUI）与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的鲜花零售系统测试概要：鲜花零售系统测试目标确保鲜花零售系统测试的功能正常，其中包括导航，数据输入，处理和检索等功能。利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：l 在使用有效数据时得到预期的结果。l 在使用无效数据时显

7、示相应的错误消息或警告消息。l 各业务规则都得到了正确的应用。确定或说明那些将对功能鲜花零售系统测试的实施和执行造成影响的事项或因素（内部的或外部的）6.1.3业务周期测试业务周期测试应模拟在一段时间内对鲜花零售系统执行的活动。应先确定一段时间（例如一年），然后执行将在该时段内发生的事务和活动。这种测试包括所有的每日、每周和每月的周期，以及所有与日期相关的事件（如备忘录）。测试目标确保测试对象及背景的进程都按照所要求的业务模型和时间表正确运行。1通过执行以下活动，测试将模拟若干个业务周期：l 将修改或改进对测试对象进行的功能测试，以增加每项功能的执行次数，从而在指定的时间段内模拟若干个不同的用

8、户。l 将使用有效的和无效的数据或时间段来执行所有与时间或数据相关的功能。l 将在适当的时间执行或启用所有周期性出现的功能。2在测试中还将使用有效的和无效的数据，以核实以下内容：1所计划的测试已全部执行。2所发现的缺陷已全部解决。1系统日期和事件可能需要特殊的支持活动。2需要通过业务模型来确定相应的测试需求和测试过程。6.1.4用户界面测试通过用户界面 （UI） 测试来核实用户与软件的交互。UI 测试的目标在于确保用户界面向用户提供了适当的访问和浏览测试对象功能的操作。除此之外，UI 测试还要确保 UI 功能内部的对象符合预期要求，并遵循公司或行业的标准。测试目标：核实以下内容：l 通过测试对

9、象进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab 健、鼠标移动、和快捷键）的使用l 窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准。为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。成功地核实出各个窗口都与基准版本保持一致，或符合可接受标准。并不是所有定制或第三方对象的特征都可访问。6.1.5性能评价性能评价是一种性能测试，它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评价的目标是核实性能需求是否都已满足。实施和执行性能评价的目的是将测试对象的

10、性能行为当作条件（例如工作量或硬件配置）的一种函数来进行评价和微调。核实所指定的事务或业务功能在以下情况下的性能行为：l 正常的预期工作量l 预期的最繁重工作量1使用为功能或业务周期测试制定的测试过程。2通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的迭代数量。3脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基准），并在多个客户机（虚拟的或实际的客户机，请参见下面的“需要考虑的特殊事项”）上重复。1单个事务或单个用户：在每个事务所预期或要求的时间范围内成功地完成测试脚本，没有发生任何故障。2多个事务或多个用户：在可接受的时间范围内成功地完成测试脚本，没有发生任何故障。综

11、合的性能测试还包括在服务器上添加后台工作量。可采用多种方法来执行此操作，其中包括：l 直接将“事务强行分配到”服务器上，这通常以“结构化查询语言”（SQL） 调用的形式来实现。l 使用多台实际客户机（每台客户机都运行测试脚本）在系统上添加负载。l 性能测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。l 性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。6.1.6负载测试负载测试是一种性能测试。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作

12、量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。1使用为功能或业务周期测试制定的测试。2通过修改数据文件来增加事务数量，或通过修改测试来增加每项事务发生的次数。多个事务或多个用户：在可接受的时间范围内成功地完成测试，没有发生任何故障。1负载测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。2负载测试所用的数据库应该是实际大小或相同缩放比例的数据库。6.1.7强度测试强度测试是一种性能测试，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的

13、错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。核实测试对象能够在以下强度条件下正常运行，不会出现任何错误：l 服务器上几乎没有或根本没有可用的内存（RAM 和 DASD）l 连接或模拟了最大实际（实际允许）数量的客户机l 多个用户对相同的数据或账户执行相同的事务l 最繁重的事务量或最差的事务组合（请参见上面的“性能测试”）。1使用为性能评测或负载测试制定的测试。2要对有限的资源进行测试，就应该在一台计算机上运行测试，而且应该减少或限制服务器上的 RAM 和 DASD。3对于其他强度测试，应该使用多台客户机来运行相同的测试或互补的测试，以产生最繁重的事务量或最差的事务组合。所计划的测试已全部执行，并且在达到或超出指定的系统限制时没有出现任何软件故障，或者导致系统出现故障的条件