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

CRM(用户关系管理系统)测试计划文档修订统计版本号改变状态简明说明日期变更人同意日期同意人V1.0C 改变状态：C=创建，A=增加，M=修改，D=删除1. 概述41.1 目标41.2 背景介绍41.3 测试计划读者范围42. 测试基础内容42.1测试环境42.2测试工具52.3测试范围52.3.1 测试对象52.3.2需要测试特征52.3.3不需要测试特征63. 测试用例设计63.1 测试用例相关约定63.2衡量测试用例设计质量标准73.2.1系统性73.2.2连贯性73.2.3相关性73.2.4全方面性73.2.5.正确性83.2.6符合正常业务通例83.2.7容错性（健壮性）84.实施计划84.1 测试进度安排84.2 测试人员安排和职责94.3 输出要求105 测试方法105.1黑盒测试方法105.1.1等价类划分法105.1.2边界值分析法105.1.3因果图法115.1.4功效图法115.1.5错误推测法115.1.6正交试验设计方法115.1.7接口间测试125.1.8数据库测试125.1.9可了解（操作）性125.1.10可移植性125.2软件测试部分准则126. 测试各项标准136.1 测试项经过/失败标准136.2 中止测试和恢复测试判定标准137. 缺点跟踪147.1 缺点类型147.2 缺点管理步骤图147.3 缺点严重程度和优先等级167. 测试汇报188. 风险及应急方法181. 概述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位操作系统软件环境：CRM2.2测试工具用途工具生产厂商/自产版本备注测试管理ALMHP11.5被测系统CRMN/A1.0汇报和测试用例WordMicrosoft2.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 OwnerALM 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) 在测试环境配置，争取尽可能和真实环境一致；激励测试人员发挥主观能动性，提出可能出现缺点，完善测试过程。