艾斯医药商务系统测试计划 - 图文

中测试用例的状态记载：

（1） failed:如果某一步测试用例失败，但不影响以后测试用例处理 （2） block:如果某一步测试用例失败，并影响以后测试用例处理 （3） good:测试成功

? 实际测试与外部交互使用缺陷记录清单进行交流。

测试人员必须详细、准确填写缺陷记录内容，开发修改人员要详细、准确地填写修改情况，通过缺陷记录清单的状态进行测试和修改交互。

（1）open:当开始一个问题报告单时，为open

开发返回后，错误仍存在为 re-open （2）fixed / return

开发人员对错误进行了修改，为fixed

开发人员对错误没有进行修改,返回测试部为return （3）close/ cancel

测试人员确认错误已经修改,为close

测试人员确认错误的无效或可以接受（标记）为cancel

? 测试版本的控制

由项目开发组随版本发布时提交版本提交单，测试组完成测试后提交版本测试报告，版本更新时由开发组填写更新记录。 ? 测试用例的命名原则：

[测试点]-编号 例如：XDL-01

? 缺陷记录清单命名原则

缺陷记录清单+_测试人员名称+_日期 例如：缺陷记录清单_刘飞_20020101

3.1.3数据选择策略

数据的选择全面覆盖所有数据、并要求避免冗余数据的使用（采用边界值、特殊值、以及普通值）。

3.1.4测试过程描述和操作步骤

1. 测试过程描述 （1）书写测试计划

（2）参考测试计划、需求、概要设计以及部分详细设计文档进行用例设计 （3）参考测试计划和测试用例进行实际测试操作 （4）测试总结和报告 2. 操作步骤

? 测试基本流程（简易的IVT） ? 测试功能块（重点为容错测试） ? 统计信息的测试（IVT） 3.2软件说明

Ascent医药商务系统主要涵盖管理员、普通用户、游客三中角色登录，实现功能主要有：用户管理、商品管理、邮件管理、购物功能、订单管理。

3.3测试内容及策略

本测试将通过用户界面测试、集成测试，系统测试、验收测试、性能测试、负载测试、强度测试、容量测试、安全性和访问控制测试、故障转移和恢复测试、配置测试、安装测试方面对系统进行测试。

用户界面测试用于核实用户与软件之间的交互，测试用户界面的正确性和易用性。 3.3.1用户界面及易用性测试

目的：确保用户界面通过测试对象的功能来为用户提供相应的访问或浏览功能；另外，UI测试还可以确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。

内容：对系统的功能页面进行各种可操作性测试。 重点：容错检测，易用性。 3.3.2集成测试

目的：检测系统是否达到需求，对业务流程及数据流的处理是否符合标准，检测系统对业务流处理是否存在逻辑不严谨及错误，检测需求是否存在不合理的标准和要求。

内容：利用有效的和无效的数据来执行各个用例，用例流或功能，以核实在使用有效数据时得到的预期结果，在使用无效数据时显示相应的错误消息或警告消息，个业务规则都得到了正确的应用。

重点：测试的单元模块之间的接口和调用是否正确，集成后是否实现了某个功能。

3.3.3系统测试

目的：将软件整合为一体，看各个功能是否全部实现。

内容：将整个软件系统看做一个整体进行测试，测试功能是否能满足需求，是否全部实现，后期主要包括看系统运行的性能是否满足需求，以及系统在不同的软硬件环境中的兼容性等。

重点：系统在配置好的环境中是否可以正常运行。

3.3.4压力测试

目的：了解(被测应用程序)一般能够承受的压力，同时能够承受的用户访问量(容量)，最多支持有多少用户同时访问某个功能。 内容：

（1）因为事先我们不知道将有多少用户访问是临界点，所以在测试过程中需要多次改变用户数来确定，

（2）计划的设置，每x时间后加载10用户(根据总用户数设置)，完全加载后持续运行不超过5分钟(根据需要设置)。

（3）当运行中的用户数100%达到集合点时释放。

重点：找到系统的临界值点

3.3.5功能测试

目的：功能测试就是对系统的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。

内容：

（1）页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。 （2）相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影

响是否都正确。

（3）检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。 （4）字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.

（5）字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错. （6）标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.

（7）中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错. （8）检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致 （9）信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.

（10）检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理. （11）检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.

（12）检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.

（13）重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。

（14）检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错. （15）search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确. （16）输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.

（17）上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。

（18）必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*

（19）快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。

（20）回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错。 重点：确保各项功能和用需求一致 3.3.6性能测试

目的：核实性能是否满足用户需求，将测试对象的性能行为当做条件的一种函数来进行评测和微调。

内容：负载测试、强度测试。 a． 单个事务单个用户时候，在每个事务所语气时间范围内成功完成测试脚本，没有发

生任何故障；多个事务多个用户时，可完成脚本没有发生故障的情况临界值。

b． 使测试系统承担不同的工作量，得出系统持续正常运行的能力。 c． 找出因资源不足或资源争用导致的错误。 重点：确保性能指标满足用户需求。 3.3.7容量测试

目的：所计划的测试全部执行，而且达到或超出指定的系统限制时没有出现任何软件故障。

内容：在客户机长时间内执行相同的、最坏的业务时候系统维持的时间。 重点：核实系统能否在连续或模拟了最多数量的客户机下正常运行。

3.3.8安全性和访问控制测试

目的：保证只有访问权限的用户才能访问系统，核实用户以不同身份登录有不同的访问权限。

内容：数据或业务功能访问的安全性，包括系统登录或远程访问。 重点：确保治具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。。

3.3.9故障转移和恢复测试

目的：检测系统可否在意外数据损失、数据完整性破坏、各种硬件、软件、网络故障中恢复数据。

内容：

? 客户机断电、服务器断电看事务可否发生回滚。 ? 网络服务器中断。

重点：看数据库的恢复情况，以及系统在经历意外时间时候是否会发生崩溃现象。

3.3.10配置测试

目的：核实是否可以在所需的硬件和软件配置中正常运行。

内容：核实该系统在不同系统、不同软件和硬件配置中的运行情况。。 重点：软硬件配置不同时候对系统的影响。 3.3.11安装测试

目的：此1.0版本重点在于检查系统首次安装可否正常运行。

内容：启动或执行安装，使用预先确定的功能测试脚本子集来运行事务。

重点：异常情况处理：如磁盘空间不足、缺少目录创建权限等；核实软件安装后可否正常运行。

3.3.12验收测试

目的：对整个系统，包括软硬件，试运行，看一下是否全部功能能够实现。

内容：由软件测试工程师、用户等根据需求规格说明书对整个系统进行试运行，看是否能满足全部功能。

重点：在可移植环境中、并发访问环境中系统是否可以正常运行。

3.4测试用例范围 3.4.1 功能测试

测试的重点将主要放在功能测试上，按照三种角色：管理员、普通用户、游客登录，每