day06(测试计划)

项目背景

项目名称：亿达商贸有限公司POS系统

用户：XXXXXXX

         《亿达商贸POS系统》可用于商品管理、商品类别、供应商的管理、客户管理、采购信息及销售信息、采购退货和销售退货、库存统计、系统维护等应用模块。

测试版本：V1.0

测试目的

为了要找出错误，通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。保证整个软件开发过程是高质量的，同时满足用户指定的需求（功能、性能、安全性、兼容性）。

测试环境

*硬件设备***

 使用7台同等配置电脑，在不同环境进行（真实机器和虚拟机器

软件环境（相关软件、操作系统等）虚拟机

Windows Server 2008 SP2

亿达商贸POS系统

硬件环境（网络、设备等）

CPU：Inter Pentium Dual 2.20GHz     内存：1GB    硬盘：40G

网络环境：100MB局域网

软件环境（相关软件、操作系统等）真实机

Microsoft Windows 7 旗舰版

亿达商贸POS系统

CPU：Inter(R) Core(TM) is-2328  2.20GHz      内存：4G      硬盘：320G

网络环境：100MB局域网

辅助工具

测试管理工具：禅道

版本控制工具：SVN

测试资源

人力资源

系统资源

硬件资源、软件资源

测试策略
功能测试

功能测试是从用户的观点出发，主要以亿达商贸POS系统软件需求说明书和操作使用手册为依据，对程序功能和程序接口进行的测试。

功能测试检查项：

\1. 表单测试：必填项，提示信息，边界值，数据类型，字符长度，特殊字符

\2. 链接测试：风格，链接正确，导航文字描述，图片链接

\3. 图形测试：图片大小，位置，相关说明，字体，大小，颜色，背景等

\4. 表格：样式

\5. 内容测试：信息归类是否正确，显示位置，检索功能

\6. 浏览器测试：功能，风格显示等

常见错误类型：

页面链接和风格、相关性检查、按钮功能、字串长度、字串类型、重复提交、回退、上传下载、必填项、快捷键、刷新、信息重复、功能错误、功能遗漏、界面错误、外部数据库错误。

测试范围

测试对象、测试的特性、不测试的特性

任务分配

时间安排	主要任务	成果
第一天	长进行模块分解，进行工作量评估；需求人员撰写需求说明书	任务分配评估表、需求说明书初稿
第二天	需求说明书评审、修订，安装调试SVN及思维导图，组长分配任务，撰写POS系统思维导图初稿并组内评审	需求说明书修订版、SVN和Xmind安装调试成功、POS系统思维导图初稿
第三天	POS系统思维导图评审、修订，组长分配任务，需求人员撰写需求细化文档，并组内评审	思维导图修订版，需求细化初稿
第四天	新需求的评审、修订，安装调试Office和Visio，组长分配任务，测试人员撰写模块拆分图	新需求修订版、office和Visio安装调试成功、模块拆分图初稿
第五天	模块拆分图初稿的评审、修订	模块拆分图修订版
第六天	测试计划制定；	测试计划、产品环境搭建完成
第七天	测试计划评审、修订；	测试用例初稿
第八天	测试用例评审、修订	用例评审结论、测试用例
第九天	执行测试用例	用例测试结果、缺陷报告
第十天	执行测试用例，项目测试总结	用例测试结果、缺陷报告、项目测试总结报告

文档管理

对各种文档进行管理，以及给不同角色的人（项目经理、开发人员、测试人员）设置不同的权限；以下文档模板：会议记录、工作日志参考附件。

2.7 用例管理

测试用例是为实施一次测试而向被测系统提供输入数据、操作或各种环境设置；它来源于测试需求。是对测试需求的一个细化，它是整个测试的基础。

测试用例的优先级别

1.小版本确认测试（BVTs）：一组你想先运行的以确定这个给出的小版本是否可以测试的测试用例。

2.高：最常执行以保证功能性是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合。

3.中：这是使给出的功能区域或功能变得更详细，检查功能的多数方面。

4.低：通常最少被执行的测试用例，们在项目的生命期间里不是常常被运行。

测试用例的元素

1.测试目标：Why—为什么而测试？功能 、可用性、安全性等。

2.测试对象：What—测试什么？被测试的项目，如对象、函数、类、菜单、按钮、表格、接口、整个系统等；

3.测试环境：Where—在哪里测？测试用例运行时所处的环境，包括系统的配置和设定等要求，也包括操作系统、浏览器、通讯协议 等单机或网络环境。

4.测试前提：When—什么时候可以测？测试用例运行时所处的前提或条件限制。

5.输入数据：Which—那些数据？在操作时，系统所接受的各种可变化的数据，如数字、字符、文件等。

6.操作步骤：How——如何测？执行软件和程序的先后次序步骤等。如打开对话框、点击按钮等

测试用例模板参考附录

2.8缺陷管理

缺陷报告用于记录缺陷，对缺陷进行分类，为解决不同的缺陷分配合理的资源，并通过缺陷报告对处理缺陷的过程进行跟踪，从而使软件缺陷得以修复。

*缺陷报告包括的元素：*缺陷标题、复现缺陷的操作步骤、缺陷的实际结果、缺陷的预期结果、缺陷的优先级别、缺陷的严重程度、缺陷的基本信息、缺陷的类型、测试的软件和硬件环境、测试的软件版本、注释文字和截的缺陷图像。

缺陷严重程度

（1）致命性错误：数据丢失、数据传递错误，造成操作系统或其他支撑系统崩溃、应用系统崩溃，非正常关闭和非正常死机。

（2）严重性错误：规定的主要功能没有实现或不完整；设计不合理造成性能低下。

（3）一般性错误：不影响业务运行的功能问题。

修改优先级：

P1：立刻修复；

P2：如果时间允许就修复；

P3：可以在将来的某个版本修复；

P4：推迟修复；

P5：不进行修复。

缺陷报告模板参考附录

时间的安排

测试计划时间安排上遵守：趋势收敛的原则，越到后面，周期越短，问题应该越少。那么测试执行的原则就是：尽可能的把问题都暴露在前面，这样才能保证测试时间上呈收敛趋势。

做测试计划时，测试轮次的安排，一般根据不同的项目来定，小项目2+1或者1+1，大项目3+1或者2+1。

举例说明：假如现有一项目，测试总时间为10天，需要分3轮进行测试。

那么测试时间的安排我们采取4、3、2的原则。

第一轮（4天）：全面覆盖所有用例；

第二轮（3天）：基本上是基本功能全覆盖（故要刷筛选好一级用例），回归问题单，缺陷比较多的模块功能全覆盖；

第三轮（2天）：基本上是回归问题单+基本功能全覆盖（执行一级用例）。

还有1天留着备用，若第3轮测试有未关闭的bug，需要再加一轮，用于回归问题。

以上就是常见测试计划安排模式：3+1模式。

风险控制：4条

系统风险

需求或设计的变更未及时通知。

需求不明确可能导致开发的产品与目标不一致。

3.2影响计划的潜在因素

在测试计划执行过程中，可能存在以下因素影响计划的按时完成：

时间紧迫，任务繁重；

测试人员对的熟悉进度慢；

测试人员对被测试产品不够熟悉，对测试工具的使用熟悉程序不够；

被测试产品存在重大错误，以致于测试无法继续；

测试资源未及时到位（设备和人员）；

硬件、软件或网络环境出现故障等；

测试人员获取的需求与开发人员产生分歧；

测试人员与开发人员的协调与沟通。

3.3应急措施

如果上述潜在的可能事件发生，则通过适当加班来保证计划的按时完成。如果是由于被测试产品存在重大错误而严重影响测试进度，则考虑按照测试暂停标准来暂停该测试。

3.4测试的局限性

系统硬件配置存在不可预测的问题；

测试范围不能覆盖所有的可能情况；

测试时间的限制；

测试数据可能不全面；

测试工具自身的缺陷；

测试人员的失误。

1根据风险发生的概率和带来的影响确定风险的优先级，然后采取措施避免那些可以避免的风险

2，风险转移

3 有些风险不可避免就设法降低风险

4 为了避免转移或降低风险事先要做好风险管理计划

5 对风险的处理要制定一些应急的有效的处理方案

6 在做计划时估算资源预算时间等要留有余地不要用到100%

7 制定文档标准同意建立一种机制保证文档及时产生。