超市收银系统测试计划

《超市收银系统测试计划》由会员分享，可在线阅读，更多相关《超市收银系统测试计划（21页珍藏版）》请在金锄头文库上搜索。

1、-超市收银系统测试计划：*润*： 12740125 班级：软件工程(1)班指导老师：路飞目录1.引言31.1编写目的31.2背景31.3定义31.4测试目标32.计划32.1测试过程32.2进度安排及里程碑32.3角色32.4 系统32.5可交付工件3测试模型3测试记录3缺陷报告32.6测试资料32.7项目风险分析33 测试设计说明33.1概述3测试方法和测试用例选取的原则3测试的控制方式3数据选择策略3测试过程描述和操作步骤33.2软件说明33.3测试内容及策略3用户界面及易用性测试3集成测试3系统测试3压力测试3功能测试3性能测试3容量测试3安全性和访问控制测试3故障转移和恢复测试3配置测

2、试3安装测试3验收测试33.4测试用例范围33.4.1 功能测试33.5评价3范围3准则34超市收银系统覆盖率测试34.1 逻辑覆盖测试34.2 语句覆盖34.3 判定覆盖34.4 条件覆盖35超市收银系统黑盒测试35.1边界值测试35.2 等价类划分35.3 因果图法31.引言1.1编写目的本测试计划主要用于控制整个超市收银系统项目测试，本文档主要实现以下目标：(1)通过此测试计划能够控制整个测试项目合理、全面、准确、协调地完成。(2)为软件测试提供依据：(3)项目管理人员根据此计划，可以对项目进行宏观调控。(4)测试人员根据此计划，能够明确自己的权利、职责，准确地定位自己在项目的任务。(5

3、)相关部门，可以根据此计划，对相关资源进行准备。1.2背景本测试计划实现超市收银系统的测试。(1)项目任务的提出者为：各个超市； (2)系统的开发者为：*润； (3)系统的使用者为：各个超市；此测试项目的进行，将在需求确认后开始执行，基准是准确、全面的需求文档。测试重点是对开发实现的功能和性能进行测试。1.3定义无1.4测试目标该测试项目将通过设计和执行接受测试、界面测试、功能测试和性能测试，对软件实现的功能，以及软件的性能、兼容性、安全性、实用性、可靠性、扩展性各个方面进行全面系统的测试。基于本系统的业务复杂性和开发周期短的特性，系统测试的重点将放在功能测试和性能测试上。通过测试提高软件的质

4、量，为用户提供最好的服务，并合理地避免软件的风险和减少软件的成本。2.计划2.1测试过程在项目开发确定好之后就开始进行测试计划的设计，伴随项目的结束而结束，整个过程是一个连贯的互相协调进行的。具体流程如图2.1所示：图2.1 系统测试过程2.2进度安排及里程碑给出进行各项测试的日期和工作内容（如熟悉环境、培训、准备输入数据、实施测试等），具体安排如下表2.1所示。表2.1 进度安排表里程碑任务工作开始日期结束日期制定测试计划*润第一周周一周二设计测试严念慈周二周五实施测试*润第二周周一周三对测试进行评估*润、严念慈周三周五2.3角色任何项目的实施首先要考虑的是人的因素，对人的识别与确认，软件测

5、试尤其不能例外。在软件测试中通常会把所有涉及人员进行分类以确立角色，并按角色进行职责划分。具体划分如下表2.2所示：表2.2 角色职责划分情况测试人员安排负责人：*润其他负责人职责联系信息职责：负责制定测试计划、编写和验收用例，完成项目实测，编写测试报告。测试组成员*职责联系信息严念慈负责功能测试用例的编写和实施*润负责性能和其他非功能测试用例的编写和实施2.4 系统测试项目所需的系统资源如表2.3所示：表2.3 系统资源信息系统资源资源名称、类型数据库服务器MySql网络或子网服务器名称数据库名称chaoshi客户端测试PCWindows特殊配置需求测试存储库Bugs 硬件环境Intel C

6、ore(TM) CPU 2.0GHz；内存4GB2.5可交付工件测试计划：一份测试用例：一份测试缺陷记录：一份测试报告：一份测试模型超市收银系统1.0测试记录采用测试用例的形式提交测试过程，详见测试用例文档。缺陷报告采用缺陷记录的形式，详见测试缺陷记录文档。2.6测试资料测试文档：测试相关模块。需求文档：项目需求文档2.7项目风险分析从质量风险维度来看，软件测试可以被定义为“对软件系统中潜在的各种风险进行评估的活动”。软件测试自身的风险性是公认的，测试的覆盖度不能做到100%。测试的这种风险定义一方面源于这层含义，另外软件测试的标准有时不清楚，所以常常强调软件测试人员应该站在客户的角度去进行测

7、试，除了发现程序中的错误，还要发现需求定义的错误、设计上的缺陷，可以针对产品的spec去报Bug。具体的风险分析如下表2.4所示：表2.4 项目风险分析风险类型风险综述在确保质量的前提下人力资源与项目周期比列失调，因此人员不到位将存在项目风险。增加人员在不同环境下运行存在风险使用统一的环境资源进行测试进度存在风险实际进度按照开发进度进行，当实际开发进度变更时将按照实际发进度及时调整测试进度客户需求发生变更常与客户进行沟通，达成一致协议人员变动风险通过培训等措施使变更后的人员了解统的业务流程，对系统深入了解，以求在最大限度内保证测试质量数据库测试中存在的风险因测试周期的限制，因此根据实际情况选择

8、的测试策略存在的风险情况反应给客户，与客户商议达成一致版本部署风险版本在部署的时候，可能会由于数据库的导入错误等原因导致系统出错。因此在实际给客户部署时同样存在此种风险。3 测试设计说明3.1概述测试方法和测试用例选取的原则系统：根据系统需求说明书对系统进行单元测试、集成测试、系统测试、验收测试、性能测试，并结合可能的用户测试。全面：要求测试用例能够覆盖每一个测试点的要点。合理：从可行性角度考虑，测试不可能全面覆盖，所以设置好等价类划分，测试的用例的选择避免重复测试、选择最好的测试方法将测试点合理覆盖。测试的控制方式测试用例的实现必须遵守测试计划的安排，实际测试必须以测试用例为基准。实际测试中

9、测试用例的状态记载： (1)failed:如果*一步测试用例失败，不影响以后测试用例处理 (2)block:如果*一步测试用例失败，并影响以后测试用例处理 (3)good:测试成功实际测试与外部交互使用缺陷记录清单进行交流。测试人员必须详细、准确填写缺陷记录内容，开发修改人员要详细、准确地填写修改情况，通过缺陷记录清单的状态进行测试和修改交互。(1)open:当开始一个问题报告单时，为open开发返回后，错误仍存在为 re-open(2)fi*ed / return开发人员对错误进行了修改，为fi*ed开发人员对错误没有进行修改,返回测试部为return(3)close/ cancel测试人员

10、确认错误已经修改,为close测试人员确认错误的无效或可以接受（标记）为cancel测试版本的控制由项目开发组随版本发布时提交版本提交单，测试组完成测试后提交版本测试报告，版本更新时由开发组填写更新记录。测试用例的命名原则： 测试点-编号例如：CHS-01缺陷记录清单命名原则缺陷记录清单+_测试人员名称+_日期例如：缺陷记录清单_*润_20150625数据选择策略数据的选择全面覆盖所有数据、并要求避免冗余数据的使用（采用边界值、特殊值、以及普通值）。测试过程描述和操作步骤1.测试过程描述(1)书写测试计划(2)参考测试计划、需求、概要设计以及部分详细设计文档进行用例设计(3)参考测试计划和测试

11、用例进行实际测试操作(4)测试总结和报告2.操作步骤(1)测试基本流程（简易的IVT）(2)测试功能块（重点为容错测试）(3)统计信息的测试（IVT）3.2软件说明超市收银系统主要涵盖管理员、库存管理员、售货员三种角色登录，实现功能主要有：用户管理、商品管理、库存管理、商品销售，详见需求规格说明书。3.3测试内容及策略本测试将通过用户界面测试、集成测试，系统测试、验收测试、性能测试、负载测试、强度测试、容量测试、安全性和访问控制测试、故障转移和恢复测试、配置测试、安装测试方面对系统进行测试。用户界面测试用于核实用户与软件之间的交互，测试用户界面的正确性和易用性。用户界面及易用性测试目的：确保用

12、户界面通过测试对象的功能来为用户提供相应的访问或浏览功能；另外，UI测试还可以确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。内容：对系统的功能页面进行各种可操作性测试。重点：容错检测，易用性。集成测试目的：检测系统是否达到需求，对业务流程及数据流的处理是否符合标准，检测系统对业务流处理是否存在逻辑不严谨及错误，检测需求是否存在不合理的标准和要求。内容：利用有效的和无效的数据来执行各个用例，用例流或功能，以核实在使用有效数据时得到的预期结果，在使用无效数据时显示相应的错误消息或警告消息，个业务规则都得到了正确的应用。重点：测试的单元模块之间的接口和调用是否正确，集成后是否实现了*个

13、功能。系统测试目的：将软件整合为一体，看各个功能是否全部实现。内容：将整个软件系统看做一个整体进行测试，测试功能是否能满足需求，是否全部实现，后期主要包括看系统运行的性能是否满足需求，以及系统在不同的软硬件环境中的兼容性等。重点：系统在配置好的环境中是否可以正常运行。压力测试目的：了解(被测应用程序)一般能够承受的压力，同时能够承受的用户访问量(容量)，最多支持有多少用户同时访问*个功能。内容：（1）因为事先我们不知道将有多少用户访问是临界点，所以在测试过程中需要多次改变用户数来确定，（2）计划的设置，每*时间后加载10用户(根据总用户数设置)，完全加载后持续运行不超过5分钟(根据需要设置)。

14、（3）当运行中的用户数100%达到集合点时释放。重点：找到系统的临界值点功能测试目的：功能测试就是对系统的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。内容：（1）页面检查：每一个是否都有对应的页面，并且页面之间切换正确。（2）相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。（3）检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。（4）字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错. （5）字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错. （6）标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确. （7）中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错. （8）检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致（9）信息重复: 在一些需要命名,且名字应该唯