CRM客户关系标准管理系统测试专题计划.docx

CRM(用户关系管理系统)

测试计划

文档修订统计
版本号
改变状态
简明说明
日期
变更人
同意日期
同意人
V1.0
C

改变状态：C=创建，A=增加，M=修改，D=删除

1. 概述 4
1.1 目标 4
1.2 背景介绍 4
1.3 测试计划读者范围 4
2. 测试基础内容 4
2.1测试环境 4
2.2测试工具 5
2.3测试范围 5
2.3.1 测试对象 5
2.3.2需要测试特征 5
2.3.3不需要测试特征 6
3. 测试用例设计 6
3.1 测试用例相关约定 6
3.2 衡量测试用例设计质量标准 7
3.2.1系统性 7
3.2.2连贯性 7
3.2.3相关性 7
3.2.4全方面性 7
3.2.5.正确性 8
3.2.6符合正常业务通例 8
3.2.7容错性（健壮性） 8
4.实施计划 8
4.1 测试进度安排 8
4.2 测试人员安排和职责 9
4.3 输出要求 10
5 测试方法 10
5.1黑盒测试方法 10
5.1.1等价类划分法 10
5.1.2边界值分析法 10
5.1.3因果图法 11
5.1.4功效图法 11
5.1.5错误推测法 11
5.1.6正交试验设计方法 11
5.1.7接口间测试 12
5.1.8数据库测试 12
5.1.9可了解（操作）性 12
5.1.10可移植性 12
5.2软件测试部分准则 12
6. 测试各项标准 13
6.1 测试项经过/失败标准 13
6.2 中止测试和恢复测试判定标准 13
7. 缺点跟踪 14
7.1 缺点类型 14
7.2 缺点管理步骤图 14
7.3 缺点严重程度和优先等级 16
7. 测试汇报 18
8. 风险及应急方法 18
1. 概述
1.1 目标
CRM系统“CRM系统-系统测试计划”文档有利于实现以下目标：
l 确定CRM系统测试环境、测试工具、测试范围
l 列出测试用例编写相关约定
l 确定所需资源并对CRM系统测试工具进行估量
l 列出CRM系统测试项目可交付元素
文件中所要求内容能够作为对测试过程完备性对照检验表，将会提升测试过程每个阶段能见度，极大地提升测试工作可管理性。
1.2 背景介绍
用户关系管理系统是一个崭新、国际领先、以用户为中心企业管理理论、商业运作模式、也是一个以信息技术为手段、有效提升企业受益、用户满意度、雇员生产力具体软件和实现方法，是一套集理念、组织、步骤、技术为一体整体处理方案，是一个意在改善企业和用户之间关系新型管理机制。企业实施CRM战略本质目标是和那些有价值用户建立稳定长久双赢关系，进而为企业在几楼市场竞争中赢得优势。
1.3 测试计划读者范围
测试工程师，开发经理，项目经理，实施责任人
2. 测试基础内容
2.1测试环境

软件环境（相关软件、操作系统等）
操作系统：Win7
硬件环境
CPU处理器： i3-3220 @3.3 GHz
内存：4G
系统类型：64位操作系统
软件环境：CRM

2.2测试工具
用途
工具
生产厂商/自产
版本
备注
测试管理
ALM
HP
11.5

被测系统
CRM
N/A
1.0

汇报和测试用例
Word
Microsoft

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) 测试用例覆盖全部测试点、覆盖全部已知用户使用场景(User scenario)，也就是说每个测试点全部有对应数量测试用例来覆盖，而且将多种用户使用场景经过矩阵或因果图等方法列出来，找到相对应测试用例。
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 测试进度安排
此次测试时间安排以下：
里程碑
实施者
开始
时间
完成
时间
天数（天）
需求分析

CRM系统业务分析

编写需求并导入ALM

测试用例设计

设计测试用例

用例评审

导入ALM（也能够直接在ALM录入）

测试实施

ALM中创建测试集

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

第一轮测试实施并提交缺点和测试汇报

第二轮测试实施并提交缺点和测试汇报

项目总结汇报

系统测试总结

4.2 测试人员安排和职责
人员
角色
职责、任务
备注

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

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

系统测试Owner
需求分析，设计测试用例，导入测试用例，实施测试，统计测试实施日志，缺点追踪

ALM Owner
ALM Admin，管理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．设计测试用例时应该考虑到正当输入和不正当输入和多种边界条件，特殊情况要制造极端状态和意外状态，比如网络异常中止、电源断电等情况。
4．一定要注意测试中错误集中发生现象，这和程序员编程水平和习惯有很大关系。
5．对测试错误结果一定要有一个确定过程，通常有A测试出来错误，一定要有一个B来确定，严重错误能够召开评审会进行讨论和分析。
6．制订严格测试计划，并把测试时间安排尽可能宽松，不要期望在极短时间内完成一个高水平测试。
7．回归测试关联性一定要引发充足注意，修改一个错误而引发更多错误出现现象并不少见。
8．妥善保留一切测试过程文档，意义是不言而喻，测试重现性往往要靠测试文档。
6. 测试各项标准
6.1 测试项经过/失败标准
通常有“基于测试用例”和“基于缺点密度”两种评选准则，在这里我们采取前者。
准则以下：
l 功效性测试用例经过率达成95％；
l 非功效性测试用例经过率达成90％；
l 沒有高于优先级 3以上缺点。
l 备选经过措施：
依据实际情况由软件开发部门经理、项目经理和测试责任人等共同讨论确定本阶段是否结束。
6.2 中止测试和恢复测试判定标准

l 缺点数量大于100时中止测试直至缺点修复到10时恢复
l 现代码不全时停止测试直至代码全方面恢复测试
l 当缺点严重程度为4个数超出总体缺点1/2时停止测试
l 当缺点优先级为1个数超出总体缺点1/3时停止测试
7. 缺点跟踪
7.1 缺点类型
此次测试过程中缺点管理将在ALM中进行，缺点大致包含以下状态：

缺点类型
具体含义
冗余代码多
代码冗余，即是编程时无须要代码段。
兼容性差
软件从某一环境转移到另一环境后不能正常运行
可操作性差
软件难以了解,不轻易使用,运行缓慢。
界面不友好
最终用户会认为界面不好。
和需求不一致
软件没有实现产品规格说明所要求功效模块;
软件实现了产品规格说明没有提到功效模块。
可扩展性差
软件在原有功效上不轻易实现新增其它新功效。
7.2 缺点管理步骤图
缺点状态如上所表示，通常缺点管理步骤以下图所表示：

7.3 缺点严重程度和优先等级

缺点严重程度：
严重等级
严重程度描述
1-Low
使用不方便问题
对软件改善提议：
1) 轻易给用户误解和歧义提醒；
2) 界面需要改善；
3) 对有疑虑文档，提出修改提议
2-Medium
界面非关键信息错误
•微小错误，不会影响系统功效
•风格不统一，包含相近步骤界面布局相异，相同问题点提醒信息相异，但对用户使用方法和使用习惯不造成影响（需求中明确风格要求除外）如帮助、提醒信息不完整，有错误，但不影响用户使用。
不正确，但有使系统使用起来不太方便错误：
1) 系统提醒语不明确，不简明
2) 滚动条无效
3) 可编辑区和不可编辑区不显著
4) 光标跳转设置不好，鼠标（光标）定位错误
5) 上下翻页，首尾页定位错误
6) 界面不一致，或界面不正确
7) 日期或时间初始值错误（起止日期、时间没有限定）
8) 按钮或标签上有拼写错误单词、不正确大小写
该问题是一个不正确或轻易误解行为，但不会引发下面（3、4、5等级）列出问题
3-High
功效缺失或错误，界面关键信息错误
•该问题增加了安装、测试或用户操作复杂度或成本
•该问题轻微降低了系统性能，但系统仍然能工作
•非关键功效实现不完整或不正确，但对系统影响很小，系统仍然能工作
•业务步骤对应功效未实现，不过有替换方法处理，不影响实际使用
•布署文档描述不明确，增加布署难度
不正确，但不会影响系统稳定性：
1) 过程调用或其它脚本错误
2) 系统刷新错误
3) 产生错误结果，如计算结果错误等
4) 功效实现有问题。如在系统实现界面上，部分可接收输入控件点击后无作用，对数据库操作不能正确实现
5) 编码时数据类型、长度定义错误
6) 对用户使用有操作次序上限制
7) 即使正确性不受影响，但系统性能和响应时间受到影响
4-Very High
造成系统瓦解、数据丢失、严重系统资源泄露，关键功效缺失或错误
•该问题会严重降低系统性能
•业务步骤不正确
•需求实现不完整，设计实现上缺点，且无替换方法，如：设计了3条路上山，不过实际只有一条能够上
•该问题不符合需求规格书
•配置项设计错误，无法正常配置，或配置后，测试中出现和配置相关错误
•布署文档错误，造成布署失败
•和其它网元接口，调用或提供错误
•申报信息提交错误，可继续测试（如联网申报、分类错误、乱码、违禁信息），但影响应用后续审核上线；
5-Urgent
必需立即处理，依据情况能够要求项目组立即公布新版本，阻碍步骤、系统瓦解造成开发或测试无法进行或程序无法正常运行缺点。
•提交物缺失，造成测试、布署和维护无法正常进行
•需求未实现
•正常操作，造成系统（进程）瓦解
•系统不能开启或开启后无法正常工作
•系统（进程）常常自动瓦解（最少一天一次）

缺点优先级：
优先级
优先级描述
1-Low
可能会修复，不过也能不修复
2-Medium
假如时间许可应该修复
3-High
在产品公布前必需修复
4-Very High
立即修复
5-Urgent
立即修复，停止深入测试

7. 测试汇报
8. 风险及应急方法
风险：
1) 人员流动风险：在项目进行过程人员流动造成风险；
2) 人员过失风险：因测试人员在工作中不认真，如测试用例实施不根本，结果填写错误等；
3) 环境风险：在项目进行过程中，因为测试环境问题造成错误及项目延期等问题；
4) 需求变更风险：因为需求变更造成测试在需求上发生错误或遗漏；
5) 需求分析错误：因需求分析人员在需求分析中出现了解错误，造成一系列连带错误；
6) 需求文档缺失：测试人员没有具体设计说明书，造成测试在需求分析中出现错误；
7) 用例设计风险：测试人员在用例设计中出现不到位而造成风险；
8) 自动化测试风险：因界面不稳定而造成自动化测试风险；
9) 硬件资源风险：因为对测试硬件资源预估不足，造成测试进行中出现资源担心；
10) 版本控制：因测试过程中版本控制不足而造成程序出现混乱，出现不应出现问题；
11) 时间风险：因测试时间预估不足而造成不能按时将项目交付；
12) 回归风险：因回归测试不根本而发生风险；
13) 环境改变风险：因测试环境和真实环境不一致，造成测试不根本；
14) 隐藏缺点：因程序在测试运行中没有出现，而在特殊情况下出现缺点造成风险；

处理方案：
1) 加强人员贮备，在项目组中人员互为替补，立即做好人员补充；
2) 加强人员监督，优化人员监督机制；
3) 对测试环境定时检验，尽可能避免出现问题，同时，为项目中预留合适时间来缓冲因出现问题而造成延期；
4) 在项目早期和用户明确需求，避免需求后期变更，同时，在项目计划期留出缓冲时间；
5) 做好小组评审，争取在问题早期更正，如用例设计，需求分析等；
6) 加强测试中信息交流，立即和用户代表沟通，明确需求；
7) 和开发人员立即沟通，争取界面立即稳定，必需话，取消部分自动化测试项目；
8) 对硬件资源立即监控，合理分析，争取在问题出现前处理；
9) 明确版本控制，避免版本混乱；
10) 早期合理安排计划，进行过程中出现问题，尽可能在不改变计划前提下经过其它方法赶工，假如确定不能按期完成，和项目经理沟通；
11) 回归测试尽可能具体；
12) 在测试环境配置，争取尽可能和真实环境一致；
激励测试人员发挥主观能动性，提出可能出现缺点，完善测试过程。