《超市收银系统测试计划》由会员分享，可在线阅读，更多相关《超市收银系统测试计划（41页珍藏版）》请在金锄头文库上搜索。
1、 超市收银系统测试计划 姓名： 张润 学号： 12740125 班级： 软件工程(1)班 指导老师： 路飞 目 录1.引言41.1编写目的41.2背景41.3定义41.4测试目的42.计划52.1测试过程52.2进度安排及里程碑52.3角色62.4 系统72.5可交付工件72.5.1测试模型72.5.2测试记录72.5.3缺陷报告72.6测试资料72.7项目风险分析83 测试设计说明93.1概述93.1.1测试方法和测试用例选取的原则93.1.2测试的控制方式93.1.3数据选择策略103.1.4测试过程描述和操作环节103.2软件说明103.3测试内容及策略103.3.1用户界面及易用性测试
2、103.3.2集成测试113.3.3系统测试113.3.4压力测试113.3.5功能测试113.3.6性能测试133.3.7容量测试133.3.8安全性和访问控制测试133.3.9故障转移和恢复测试143.3.10配置测试143.3.11安装测试143.3.12验收测试143.4测试用例范围143.4.1 功能测试143.5评价173.5.1范围173.5.2准则174超市收银系统覆盖率测试184.1 逻辑覆盖测试184.2 语句覆盖214.3 鉴定覆盖214.4 条件覆盖215超市收银系统黑盒测试225.1边界值测试225.2 等价类划分225.3 因果图法231.引言1.1编写目的本测试计
3、划重要用于控制整个超市收银系统项目测试，本文档重要实现以下目的：(1)通过此测试计划可以控制整个测试项目合理、全面、准确、协调地完毕。(2)为软件测试提供依据：(3)项目管理人员根据此计划，可以对项目进行宏观调控。(4)测试人员根据此计划，可以明确自己的权利、职责，准确地定位自己在项目的任务。(5)相关部门，可以根据此计划，对相关资源进行准备。1.2背景本测试计划实现超市收银系统的测试。(1)项目任务的提出者为：各个超市； (2)系统的开发者为：张润； (3)系统的使用者为：各个超市；此测试项目的进行，将在需求确认后开始执行，基准是准确、全面的需求文档。测试重点是对开发实现的功能和性能进行测试
4、。1.3定义无1.4测试目的该测试项目将通过设计和执行接受测试、界面测试、功能测试和性能测试，对软件实现的功能，以及软件的性能、兼容性、安全性、实用性、可靠性、扩展性各个方面进行全面系统的测试。基于本系统的业务复杂性和开发周期短的特性，系统测试的重点将放在功能测试和性能测试上。通过测试提高软件的质量，为用户提供最佳的服务，并合理地避免软件的风险和减少软件的成本。2.计划2.1测试过程在项目开发拟定好之后就开始进行测试计划的设计，随着项目的结束而结束，整个过程是一个连贯的互相协调进行的。具体流程如图2.1所示：图2.1 系统测试过程2.2进度安排及里程碑给出进行各项测试的日期和工作内容（如熟悉环
5、境、培训、准备输入数据、实行测试等），具体安排如下表2.1所示。表2.1 进度安排表里程碑任务工作开始日期结束日期制定测试计划张润第一周周一周二设计测试严念慈周二周五实行测试张润第二周周一周三对测试进行评估张润、严念慈周三周五2.3角色任何项目的实行一方面要考虑的是人的因素，对人的辨认与确认，软件测试特别不能例外。在软件测试中通常会把所有涉及人员进行分类以确立角色，并按角色进行职责划分。具体划分如下表2.2所示：表2.2 角色职责划分情况测试人员安排负责人：张润其他负责人职责联系信息职责：负责制定测试计划、编写和验收用例，完毕项目实测，编写测试报告。测 试 组 成 员姓 名职 责联系信息严念慈
6、负责功能测试用例的编写和实行张润负责性能和其他非功能测试用例的编写和实行2.4 系统测试项目所需的系统资源如表2.3所示：表2.3 系统资源信息系统资源资源名称、类型数据库服务器MySql网络或子网服务器名称数据库名称chaoshi客户端测试PCWindows特殊配置需求测试存储库Bugs 硬件环境Intel Core(TM) CPU 2.0GHz；内存4GB2.5可交付工件测试计划：一份测试用例：一份测试缺陷记录：一份测试报告：一份2.5.1测试模型超市收银系统1.02.5.2测试记录采用测试用例的形式提交测试过程，详见测试用例文档。2.5.3缺陷报告采用缺陷记录的形式，详见测试缺陷记录文档
7、。2.6测试资料测试文档：测试相关模块。需求文档：项目需求文档2.7项目风险分析从质量风险维度来看，软件测试可以被定义为“对软件系统中潜在的各种风险进行评估的活动”。软件测试自身的风险性是公认的，测试的覆盖度不能做到100%。测试的这种风险定义一方面源于这层含义，此外软件测试的标准有时不清楚，所以经常强调软件测试人员应当站在客户的角度去进行测试，除了发现程序中的错误，还要发现需求定义的错误、设计上的缺陷，可以针对产品的spec去报Bug。具体的风险分析如下表2.4所示：表2.4 项目风险分析风险类型风险综述在保证质量的前提下人力资源与项目周期比列失调，因此人员不到位将存在项目风险。增长人员在不
8、同环境下运营存在风险使用统一的环境资源进行测试进度存在风险实际进度按照开发进度进行，当实际开发进度变更时将按照实际发进度及时调整测试进度客户需求发生变更常与客户进行沟通，达成一致协议人员变动风险通过培训等措施使变更后的人员了解统的业务流程，对系统进一步了解，以求在最大限度内保证测试质量数据库测试中存在的风险因测试周期的限制，因此根据实际情况选择的测试策略存在的风险情况反映给客户，与客户商议达成一致版本部署风险版本在部署的时候，也许会由于数据库的导入错误等因素导致系统犯错。因此在实际给客户部署时同样存在此种风险。3 测试设计说明3.1概述3.1.1测试方法和测试用例选取的原则系统：根据系统需求说
9、明书对系统进行单元测试、集成测试、系统测试、验收测试、性能测试，并结合也许的用户测试。全面：规定测试用例可以覆盖每一个测试点的要点。合理：从可行性角度考虑，测试不也许全面覆盖，所以设立好等价类划分，测试的用例的选择避免反复测试、选择最佳的测试方法将测试点合理覆盖。3.1.2测试的控制方式测试用例的实现必须遵守测试计划的安排，实际测试必须以测试用例为基准。实际测试中测试用例的状态记载： (1)failed:假如某一步测试用例失败，不影响以后测试用例解决 (2)block:假如某一步测试用例失败，并影响以后测试用例解决 (3)good:测试成功实际测试与外部交互使用缺陷记录清单进行交流。测试人员必
10、须具体、准确填写缺陷记录内容，开发修改人员要具体、准确地填写修改情况，通过缺陷记录清单的状态进行测试和修改交互。(1)open:当开始一个问题报告单时，为open 开发返回后，错误仍存在为 re-open(2)fixed / return 开发人员对错误进行了修改，为fixed 开发人员对错误没有进行修改,返回测试部为return(3)close/ cancel 测试人员确认错误已经修改,为close 测试人员确认错误的无效或可以接受（标记）为cancel测试版本的控制由项目开发组随版本发布时提交版本提交单，测试组完毕测试后提交版本测试报告，版本更新时由开发组填写更新记录。测试用例的命名原则：
11、 测试点-编号 例如：CHS-01 缺陷记录清单命名原则 缺陷记录清单+_测试人员名称+_日期 例如：缺陷记录清单_张润_202306253.1.3数据选择策略数据的选择全面覆盖所有数据、并规定避免冗余数据的使用（采用边界值、特殊值、以及普通值）。3.1.4测试过程描述和操作环节1.测试过程描述(1)书写测试计划(2)参考测试计划、需求、概要设计以及部分具体设计文档进行用例设计(3)参考测试计划和测试用例进行实际测试操作(4)测试总结和报告2.操作环节(1)测试基本流程（简易的IVT）(2)测试功能块（重点为容错测试）(3)记录信息的测试（IVT）3.2软件说明超市收银系统重要涵盖管理员、库存
12、管理员、售货员三种角色登录，实现功能重要有：用户管理、商品管理、库存管理、商品销售，详见需求规格说明书。3.3测试内容及策略本测试将通过用户界面测试、集成测试，系统测试、验收测试、性能测试、负载测试、强度测试、容量测试、安全性和访问控制测试、故障转移和恢复测试、配置测试、安装测试方面对系统进行测试。用户界面测试用于核算用户与软件之间的交互，测试用户界面的对的性和易用性。3.3.1用户界面及易用性测试目的： 保证用户界面通过测试对象的功能来为用户提供相应的访问或浏览功能；此外，UI测试还可以保证UI中的对象按照预期的方式运营，并符合公司或行业的标准。内容： 对系统的功能页面进行各种可操作性测试。
13、重点： 容错检测，易用性。3.3.2集成测试目的： 检测系统是否达成需求，对业务流程及数据流的解决是否符合标准，检测系统对业务流解决是否存在逻辑不严谨及错误，检测需求是否存在不合理的标准和规定。内容：运用有效的和无效的数据来执行各个用例，用例流或功能，以核算在使用有效数据时得到的预期结果，在使用无效数据时显示相应的错误消息或警告消息，个业务规则都得到了对的的应用。重点：测试的单元模块之间的接口和调用是否对的，集成后是否实现了某个功能。3.3.3系统测试目的：将软件整合为一体，看各个功能是否所有实现。内容：将整个软件系统看做一个整体进行测试，测试功能是否能满足需求，是否所有实现，后期重要涉及看系
14、统运营的性能是否满足需求，以及系统在不同的软硬件环境中的兼容性等。重点：系统在配置好的环境中是否可以正常运营。3.3.4压力测试目的：了解(被测应用程序)一般可以承受的压力，同时可以承受的用户访问量(容量)，最多支持有多少用户同时访问某个功能。内容：（1）由于事先我们不知道将有多少用户访问是临界点，所以在测试过程中需要多次改变用户数来拟定，（2）计划的设立，每x时间后加载10用户(根据总用户数设立)，完全加载后连续运营不超过5分钟(根据需要设立)。（3）当运营中的用户数100%达成集合点时释放。重点：找到系统的临界值点3.3.5功能测试目的：功能测试就是对系统的各功能进行验证，根据功能测试用例，逐项测试，检查产品是
