3.艾斯医药商务系统测试计划

《3.艾斯医药商务系统测试计划》由会员分享，可在线阅读，更多相关《3.艾斯医药商务系统测试计划（12页珍藏版）》请在金锄头文库上搜索。

1、 AscentSys 医药商务系统测试计划变更记录日期版本变更说明作者2010-08-09 V1.0 新建签字确认职务姓名签字日期1.引言1.1 编写目的本测试计划主要用于控制整个AscentSys 医药商务系统项目测试，本文档主要实现以下目标：（1）通过此测试计划能够控制整个测试项目合理、全面、准确、协调地完成。（2）为软件测试提供依据：（3）项目管理人员根据此计划，可以对项目进行宏观调控。（4）测试人员根据此计划，能够明确自己的权利、职责，准确地定位自己在项目的任务。（5）相关部门，可以根据此计划，对相关资源进行准备。1.2 背景（1）本测试计划从属于亚思晟科技有限公司，为 XXX医药公司

2、实现AscentSys 医药商务系统的测试。（2）项目任务的提出者为：亚思晟公司项目管理部；系统的开发者为：亚思晟公司；系统的使用者为：XXX医药公司；（3）此测试项目的进行， 将在需求确认后开始执行，基准是准确、 全面的需求文档。测试重点是对开发实现的功能和性能进行测试。1.3 定义无1.4 参考资料AscentSys 医药商务需求规格说明书 1.0版本AscentSys 医药商务测试计划编写规范1.5 控制信息本项目测试经理：* ；电话号码： (010)58855925 1.6 测试目标该测试项目将通过设计和执行接受测试、界面测试、 功能测试和性能测试，对软件实现的功能，以及软件的性能、兼

3、容性、安全性、实用性、可靠性、扩展性各个方面进行全面系统的测试。 基于本系统的业务复杂性和开发周期短的特性，系统测试的重点将放在功能测试和性能测试上。 通过测试提高软件的质量，为用户提供最好的服务，并合理地避免软件的风险和减少软件的成本。2.计划2.1 测试过程2.2 进度安排及里程碑测试报告评审测试计划测试方案（规范）测试报告测试执行项目新版本提交测试报告测试方案评审测试方案设计制定测试计划成立项目组给出进行各项测试的日期和工作内容（如熟悉环境、培训、准备输入数据、实施测试等） 。里程碑任务工作开始日期结束日期制定测试计划安* 2010-08-09 2010-08-10 设计测试安* 201

4、0-08-10 2010-08-13 实施测试安* 2010-08-16 2010-08-25 对测试进行评估郭* 2010-08-26 2010-08-27 2.3 角色测试人员安排负责人：郭 * 其他负责人职责联系信息职责：负责制定测试计划；负责编写和验收用例； 完成项目实测； 负责与外部合作部门交互；负责协调内部人员的工作；负责编写测试报告。测试组成员姓名职责联系信息安 * 负责功能测试用例的编写和实施孙 * 负责性能和其他非功能测试用例的编写和实施2.4 系统下表列出了测试项目所需的系统资源。系统资源资源名称 / 类型数据库服务器MySQL 5.0 网络或子网服务器名称数据库名称ace

5、sysDS 客户端测试 PC IE 8 包括特殊的配置需求Tomcat 5.0 测试存储库Bugs 网络或子网服务器名称测试开发 PC Window XP 硬件环境Intel Core(TM) CPU 2.0GHz；内存 1GB 2.5 可交付工件测试计划：一份测试用例：一份测试缺陷记录：一份测试报告：一份2.5.1 测试模型Ascent 医药商务系统1.0 2.5.2 测试记录采用测试用例的形式提交测试过程，详见测试用例文档。2.5.3 缺陷报告采用缺陷记录的形式，详见测试缺陷记录文档。2.6 测试资料测试文档：测试相关模块。需求文档：项目需求文档2.7 项目风险分析风险类型风险综述现有人力

6、资源严重不足。在确保质量的前提下，人力资 源与项目周期比例失调，因此人员不到位，将存在项目 风险。增加人员测试中使用IE6，因此在IE7 等其他环境下运行存在风 险。与客户确定为争取时间保证质量仅使用 IE6 进行测试进度存在风险实际进度将按照开发进度进行，预期度按照开发进度进行，但是实际开发度变更时，将按照实际开发进度及时正测试进度。测试环境各服务器的配置低于实际产品使用时的服务器 配置与客户商议达成一致人员变动风险通过培训等措施使变更后的人员了解统的业务流程，对系统深入了解，以求在最大限度内保证测试质量数据库测试中存在风险。因测试周期的限制， 因此根据实际情况选择的测试策略存在的风险情况反

7、应给客户，与 客户商议达成一致。版本部署风险版本在部署的时候， 可能会由于数据库的导 入错误等原因导致系统出错。因此在实际给 客户部署时同样存在此种风险。数据迁移部分增加了一个测试策略以验证迁移数据的完 整性，该策略是以自建的小数据来模拟大数据。因此对 于实际超大数据量的数据迁移存在一定风险。但是该方法能够验证数据迁移的迁移方法 的正确性，且能够非常直观的查看结果。3.测试设计说明（大纲）3.1 概述3.1.1 测试方法和测试用例选取的原则系统 ：根据系统需求说明书对系统进行单元测试、集成测试、 系统测试、 验收测试、性能测试，并结合可能的用户测试。全面 ：要求测试用例能够覆盖每一个测试点的要

8、点。合理 ：从可行性角度考虑，测试不可能全面覆盖，所以设置好等价类划分，测试的用例的选择避免重复测试、选择最好的测试方法将测试点合理覆盖。3.1.2 测试的控制方式测试用例的实现必须遵守测试计划的安排，实际测试必须以测试用例为基准。实际测试中测试用例的状态记载：（1）failed:如果某一步测试用例失败，但不影响以后测试用例处理（2）block: 如果某一步测试用例失败，并影响以后测试用例处理（3）good: 测试成功实际测试与外部交互使用缺陷记录清单进行交流。测试人员必须详细、准确填写缺陷记录内容，开发修改人员要详细、准确地填写修改情况，通过缺陷记录清单的状态进行测试和修改交互。（1）ope

9、n: 当开始一个问题报告单时，为open 开发返回后，错误仍存在为 re-open （2）fixed / return 开发人员对错误进行了修改，为fixed 开发人员对错误没有进行修改,返回测试部为return （3）close/ cancel 测试人员确认错误已经修改, 为 close 测试人员确认错误的无效或可以接受（标记）为cancel 测试版本的控制由项目开发组随版本发布时提交版本提交单，测试组完成测试后提交版本测试报告，版本更新时由开发组填写更新记录。测试用例的命名原则： 测试点 - 编号例如： XDL-01 缺陷记录清单命名原则缺陷记录清单+_测试人员名称 +_日期例如：缺陷记录

10、清单_刘飞 _20020101 3.1.3 数据选择策略数据的选择全面覆盖所有数据、并要求避免冗余数据的使用（采用边界值、特殊值、以及普通值）。3.1.4 测试过程描述和操作步骤1.测试过程描述（1）书写测试计划（2）参考测试计划、需求、概要设计以及部分详细设计文档进行用例设计（3）参考测试计划和测试用例进行实际测试操作（4）测试总结和报告2.操作步骤测试基本流程（简易的IVT）测试功能块（重点为容错测试）统计信息的测试（IVT）3.2 软件说明Ascent 医药商务系统主要涵盖管理员、普通用户、游客三中角色登录，实现功能主要有：用户管理、商品管理、邮件管理、购物功能、订单管理，详见需求规格说

11、明书。3.3 测试内容及策略本测试将通过用户界面测试、集成测试，系统测试、验收测试、性能测试、负载测试、强度测试、容量测试、安全性和访问控制测试、故障转移和恢复测试、配置测试、安装测试方面对系统进行测试。用户界面测试用于核实用户与软件之间的交互，测试用户界面的正确性和易用性。3.3.1 用户界面及易用性测试目的： 确保用户界面通过测试对象的功能来为用户提供相应的访问或浏览功能；另外，UI 测试还可以确保UI 中的对象按照预期的方式运行，并符合公司或行业的标准。内容：对系统的功能页面进行各种可操作性测试。重点：容错检测，易用性。3.3.2 集成测试目的：检测系统是否达到需求，对业务流程及数据流的

12、处理是否符合标准，检测系统对业务流处理是否存在逻辑不严谨及错误，检测需求是否存在不合理的标准和要求。内容： 利用有效的和无效的数据来执行各个用例，用例流或功能， 以核实在使用有效数据时得到的预期结果，在使用无效数据时显示相应的错误消息或警告消息，个业务规则都得到了正确的应用。重点： 测试的单元模块之间的接口和调用是否正确，集成后是否实现了某个功能。3.3.3 系统测试目的： 将软件整合为一体，看各个功能是否全部实现。内容： 将整个软件系统看做一个整体进行测试，测试功能是否能满足需求，是否全部实现，后期主要包括看系统运行的性能是否满足需求，以及系统在不同的软硬件环境中的兼容性等。重点： 系统在配

13、置好的环境中是否可以正常运行。3.3.4 压力测试目的： 了解 ( 被测应用程序 ) 一般能够承受的压力，同时能够承受的用户访问量( 容量 ) ，最多支持有多少用户同时访问某个功能。内容：（1）因为事先我们不知道将有多少用户访问是临界点，所以在测试过程中需要多次改变用户数来确定，（2）计划的设置， 每 x 时间后加载10 用户 ( 根据总用户数设置) ，完全加载后持续运行不超过 5 分钟 (根据需要设置) 。（3）当运行中的用户数100% 达到集合点时释放。重点： 找到系统的临界值点3.3.5 功能测试目的： 功能测试就是对系统的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户

14、要求的功能。内容：（1）页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。（2） 相关性检查：删除/ 增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。（3）检查按钮的功能是否正确：如update, cancel, delete, save 等功能是否正确。（4） 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度 ,会不会出错 . （5）字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容( 如在应该输入整型的地方输入其他字符类型), 看系统是否检查字符类型, 会否报错 . （6） 标点符号检查: 输入内容包括各种标

15、点符号, 特别是空格 , 各种引号 , 回车键 . 看系统处理是否正确. （7）中文字符处理: 在可以输入中文的系统输入中文, 看会否出现乱码或出错. （8） 检查带出信息的完整性: 在查看信息和update 信息时 ,查看所填写的信息是不是全部带出 ., 带出信息和添加的是否一致（9） 信息重复 : 在一些需要命名, 且名字应该唯一的信息输入重复的名字或ID, 看系统有没有处理 , 会否报错 , 重名包括是否区分大小写, 以及在输入内容的前后输入空格, 系统是否作出正确处理. （10）检查删除功能: 在一些可以一次删除多个信息的地方, 不选择任何信息,按”delete ”, 看系统如何处理,

16、 会否出错 ; 然后选择一个和多个信息, 进行删除 , 看是否正确处理 . （11） 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致, 例如添加要求必填的项 , 修改也应该必填; 添加规定为整型的项, 修改也必须为整型. （12）检查修改重名: 修改时把不能重名的项改为已存在的内容, 看会否处理 ,报错 . 同时, 也要注意 , 会不会报和自己重名的错. （13）重复提交表单：一条已经成功提交的纪录，back 后再提交，看看系统是否做了处理。（14）检查多次使用back 键的情况 : 在有 back 的地方 ,back, 回到原来页面 , 再 back,重复多次 ,看会否出错 . （15）search 检查 : 在有 search 功能的地方输入系统存在和不存在的内容, 看 search结果是否正确 . 如果可以输入多个search 条件 , 可以同时添加合理和不合理的条件, 看系统处理是否正确. （16）输入信息位置: 注意在光标停留的地方输入信息时, 光标和所输入的信息会否跳到别的地方 . （17