CRM系统测试计划Word格式文档下载.docx

CRM系统测试计划Word格式文档下载.docx

《CRM系统测试计划Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《CRM系统测试计划Word格式文档下载.docx（16页珍藏版）》请在冰豆网上搜索。

4.2测试人员安排以及职责 7

4.3输出要求 7

5测试方法 7

6.测试的各项标准 8

6.1测试项通过/失败的标准 8

6.2中断测试和恢复测试的判断标准 8

7.缺陷跟踪 9

7.1缺陷类型 9

7.2缺陷管理流程图 9

7.3缺陷严重程度和优先等级 10

7.测试报告 12

8.风险及应急措施 12

1.概述

1.1目的

CRM系统“CRM系统-系统测试计划”文档有助于实现以下目标：

l确定CRM系统的测试环境、测试工具、测试范围

l列出测试用例编写的相关约定

l确定所需资源并对CRM系统测试的工具进行估计

l列出CRM系统测试项目可交付元素

文件中所规定的内容可以作为对测试过程完备性的对照检查表，将会提高测试过程的每个阶段的能见度，极大地提高测试工作的可管理性。

1.2背景介绍

客户关系管理系统是一种崭新的、国际领先的、以客户为中心的企业管理理论、商业运作模式、也是一种以信息技术为手段、有效提高企业受益、客户满意度、雇员生产力的具体软件和实现方法，是一套集理念、组织、流程、技术为一体的整体解决方案，是一种旨在改善企业与客户之间关系的新型管理机制。

企业实施CRM战略本质目标是与那些有价值的客户建立稳定的长期双赢关系，进而为企业在几楼的市场竞争中赢得优势。

1.3测试计划读者范围

测试工程师，开发经理，项目经理，实施负责人

2.测试基本内容

2.1测试环境

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

操作系统：

Win7

硬件环境

处理器：

QEMUVirtualCPUVERSION2.29GHz

内存：

4G

系统类型：

64位操作系统

软件环境：

CRM

2.2测试工具

用途

工具

生产厂商/自产

版本

备注

测试管理

ALM

HP

11.52

被测系统

N/A

报告以及测试用例

Excel/Word

Microsoft

2013

2.3测试范围

2.3.1测试对象

被测系统为CRM1.0版本，使用C++开发的。

2.3.2需要测试的特性

本次系统测试要求包含以下业务流程：

添加线索

导入与导出线索

查看线索

编辑线索

删除线索

搜索线索

2.3.3不需要测试的特性

本次系统测试不需要包含的内容：

l上述业务流程（2.3.2）之外的所有业务流程

l被删除的功能

l被外包的功能

3.测试用例设计

3.1测试用例相关约定

在设计测试用例时，你需要定义程序的操作来确保程序的各方面都被测试到。

为了确保清楚，准确的捕获到了完成一个操作所需要的所有行为，要满足下面条件：

1）测试用例的目标清楚，并能满足软件质量的各个方面，包括功能测试、性能测试、安全性测试、故障转移测试、负载测试等。

2）设计思路正确、清晰。

例如，通过序列图、状态图、工作流程图、数据流程图等来描述待测试的功能特性或非功能特性。

3）在组织和分类上，测试用例层次清楚、结构合理。

测试用例的层次与产品特性的结构/层次相一致，或者与测试的目标/子目标的分类/层次相一致，并具有合理的优先级或执行顺序。

4）测试用例覆盖所有测试点、覆盖所有已知的用户使用场景（Userscenario），也就是说每个测试点都有相应数量的测试用例来覆盖，而且将各种用户使用场景通过矩阵或因果图等方式列出来，找到相对应的测试用例。

5）测试手段的区别对待。

在设计测试用例时，就要全面考量测试的手段，哪些方面可以通过工具测试，哪些方面不得不用手工测试，对不同手段的测试用例区别对待。

6）有充分的负面测试。

作为测试用例，不仅要测试正确的输入和操作，还要测试各种各样的例外情况，如边界条件、不正确的操作、错误的数据输入等。

7）没有重复、冗余的测试用例，满足相应的行业标准等。

3.2衡量测试用例设计的质量标准

3.2.1系统性

1）对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；

2）对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系；

3.2.2连贯性

1）对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；

如果是依靠页面链接，页面链接是否正确；

2）对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯

3.2.3相关性

1）考虑各个产品之间的相关性，当某个产品某个页面的字段发生增删改时，其它产品是否有相应变化，和后台数据库之间是否匹配

2）当某个产品增加某个功能时，其它相关产品是否有相应措施

3.2.4全面性

1）应尽可能覆盖程序的各种路径

2）应尽可能覆盖系统的各个业务

3）应考虑存在跨年、跨月的数据

4）大量数据并发测试的准备

5）系统中各功能、业务的异常情况

3.2.5.正确性

1）输入用户实际数据以验证系统是否满足需求规格说明书的需求。

2）测试用例中的测试点应保证至少覆盖需求规格说明书中的各项功能。

3.2.6符合正常业务惯例

1）测试数据应符合用户实际工作业务流程

2）兼顾各种业务变化的可能

3）要符合当前业务行业法律，法规。

3.2.7容错性（健壮性）

1）程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。

2）在设计测试用例时，你需要定义程序的操作来确保程序的各方面都被测试到。

每一步都用主动语态书写，使用主动语态的好处是使得测试执行人员

4.实施计划

4.1测试进度安排

本次测试的时间安排如下：

里程碑

执行者

开始时间

完成时间

天数（天）

需求分析

杨斌

12/19

12/20

2

CRM系统业务分析

张慧媛

12/21

12/22

编写需求并导入ALM

孟盼盼

12/23

1

测试用例设计

李贝贝

12/24

12/26

3

设计测试用例

张爱美

用例评审

小组

导入ALM（也可以直接在ALM录入）

测试执行

王鹏

12/27

12/29

ALM中创建测试集

将测试计划中案例添加到测试集

第一轮测试执行并提交缺陷以及测试报告

12/30

第二轮测试执行并提交缺陷以及测试报告

任福运

12/31

项目总结报告

孙彦林

系统测试的总结

4.2测试人员安排以及职责

人员

角色

职责、任务

PM

编写项目计划，审核测试计划，审批测试案例，项目进度追踪管理，评估并防控风险及问题的发生

PA

编写测试计划，评审案例，协助将案例导入ALM，管理测试过程，生成QC测试报告

系统测试Owner

需求分析，设计测试用例，导入测试用例，执行测试，记录测试执行日志，缺陷追踪

梦盼盼

ALMOwner

ALMAdmin，管理ALM项目，用户，完成所有和ALM相关的工作；

配合PM和系统测试Owner完成所有在ALM的工作。

CRM业务人员

熟练的掌握CRM，安装，CRM系统详细的需求（PM）

SCM

负责CRM环境，项目文档的管理

4.3输出要求

《测试计划》

《测试用例》

《测试数据》

《测试缺陷报告》

《测试总结报告》

5测试方法

本次测试是CRM的系统测试，确保：

5.1黑盒测试方法

5.1.1等价类划分法

将所有可能的输入数据（有效的和无效的）划分成若干个等价类。

5.1.2边界值分析法

指对输入的边界条件进行分析，设计出针对边界值的测试用例。

5.1.3因果图法

就是利用图解法分析软件输入（原因）和输出条件（结果）之间的关系，以设计测试用例的方法。

因果图法适合于检查程序输入条件的多种情况的组合，并最终生成判定表，来获得对应的测试用例。

5.1.4功能图法

功能图是描述程序状态变化、转移的过程，因为软件运行或操作的过程可以看作是其状态不断发生变化的过程。

测试用例的设计就是如何覆盖所有软件表现出来的状态，即在满足输入/输出的一组条件下，软件运行是一系列有次序的、受控制的状态变化过程。

5.1.5错误推测法

推测法主要依赖经验、直觉来作出简单的判断甚至是猜测，给出可能存在缺陷的条件、场景等，在找到缺陷后，设计出相应的测试用例。

5.1.6正交实验设计方法

主要步骤是：

1）对软件需求规格说明中的功能要求进行划分（层层分解与展开），分解成具体的、相对独立的基本功能。

2）根据基本功能的质量需求，找出影响其功能实现的操作对象和外部因素，每个因素的取值可以看作水平，多个取值就存在多个水平。

3）确定待测试软件中所有因素及其权值，这是测试用例设计的关键，确保全面、准确。

权值是依据各因素的影响范围、发生的频率和质量的需求来确定的。

4）加权筛选，生成因素分析表。

5）利用正交表构造测试数据集，正交表的每一行，就是一条测试用例。

考虑交互作用不可忽略的处理因素和不可混杂的原则，有交互作用的组合优先安排。

6）利用正交实验设计方法设计测试用例，可控制生成的测试用例数量，覆盖率高且测试效率高。

5.1.7接口间测试

测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。

5.1.8数据库测试

依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。

5.1.9可理解（操作）性

理解和使用该系统的难易程度（界面友好性）。

5.1.10可移植性

在不同操作系统及硬件配置情况下的运行性。

5.2软件测试的一些准则

软件测试从不同的角度出发会派生出两种不同的测试原则，从用户的角度出发，就是希望通过软件测试能充分暴露软件中存在的问题和缺陷，从而考虑是否可以接受该产品，从开发者的角度出发，就是希望测试能表明软件产品不存在错误，已经正确地实现了用户的需求，确立人们对软件质量的信心。

为了达到上述的原则，那么需要注意以下几点：

1．应当把“尽早和不断的测试”作为开发者的座右铭

2．程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完。

3．设计测试用例时