CRM客户关系管理系统测试计划.docx

1、CRM客户关系管理系统测试计划CRM(客户关系管理系统)测试计划文档修订记录版本号变化状态简要说明日期变更人批准日期批准人V1.0C 变化状态：C=创立，A=增加，M=修改，D=删除1. 概述1.1 目的CRM系统“CRM系统-系统测试计划”文档有助于实现以下目标：确定CRM系统的测试环境、测试工具、测试范围列出测试用例编写的相关约定确定所需资源并对CRM系统测试的工具进行估计列出CRM系统测试项目可交付元素文件中所规定的内容可以作为对测试过程完备性的对照检查表，将会提高测试过程的每个阶段的能见度，极大地提高测试工作的可管理性。1.2 背景介绍客户关系管理系统是一种崭新的、国际领先的、以客户为

2、中心的企业管理理论、商业运作模式、也是一种以信息技术为手段、有效提高企业受益、客户满意度、雇员生产力的具体软件和实现方法，是一套集理念、组织、流程、技术为一体的整体解决方案，是一种旨在改善企业与客户之间关系的新型管理机制。企业实施CRM战略本质目标是与那些有价值的客户建立稳定的长期双赢关系，进而为企业在几楼的市场竞争中赢得优势。1.3 测试计划读者范围 测试工程师，开发经理，项目经理，实施负责人2. 测试基本内容2.1测试环境软件环境（相关软件、操作系统等）操作系统：Win7硬件环境CPU处理器： i3-3220 3.3 GHz内存：4G系统类型：64位操作系统软件环境：CRM2.2测试工具用

3、途工具生产厂商/自产版本备注测试管理ALMHP11.5被测系统CRMN/A1.0报告以及测试用例WordMicrosoft20072.3测试范围2.3.1 测试对象被测系统为CRM1.0版本，使用C+开发的。2.3.2需要测试的特性本次系统测试要求包含以下业务流程：添加线索导入与导出线索查看线索编辑线索删除线索搜索线索2.3.3不需要测试的特性本次系统测试不需要包含的内容：上述业务流程(2.3.2)之外的所有业务流程被删除的功能被外包的功能3. 测试用例设计3.1 测试用例相关约定在设计测试用例时，你需要定义程序的操作来确保程序的各方面都被测试到。为了确保清楚，准确的捕获到了完成一个操作所需要

4、的所有行为，要满足下面条件：1)测试用例的目标清楚，并能满足软件质量的各个方面，包括功能测试、性能测试、安全性测试、故障转移测试、负载测试等。2)设计思路正确、清晰。例如，通过序列图、状态图、工作流程图、数据流程图等来描述待测试的功能特性或非功能特性。3)在组织和分类上，测试用例层次清楚、结构合理。测试用例的层次与产品特性的结构/层次相一致，或者与测试的目标/子目标的分类/层次相一致，并具有合理的优先级或执行顺序。4)测试用例覆盖所有测试点、覆盖所有已知的用户使用场景(User scenario)，也就是说每个测试点都有相应数量的测试用例来覆盖，而且将各种用户使用场景通过矩阵或因果图等方式列出

5、来，找到相对应的测试用例。5)测试手段的区别对待。在设计测试用例时，就要全面考量测试的手段，哪些方面可以通过工具测试，哪些方面不得不用手工测试，对不同手段的测试用例区别对待。6)有充分的负面测试。作为测试用例，不仅要测试正确的输入和操作，还要测试各种各样的例外情况，如边界条件、不正确的操作、错误的数据输入等。7)没有重复、冗余的测试用例，满足相应的行业标准等。3.2衡量测试用例设计的质量标准3.2.1系统性1)对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；2)对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系；3.2.2连贯性

6、1)对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接是否正确；2)对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯3.2.3相关性1)考虑各个产品之间的相关性，当某个产品某个页面的字段发生增删改时，其它产品是否有相应变化，和后台数据库之间是否匹配2)当某个产品增加某个功能时，其它相关产品是否有相应措施3.2.4全面性1)应尽可能覆盖程序的各种路径2)应尽可能覆盖系统的各个业务3)应考虑存在跨年、跨月的数据4)大量数据并发测试的准备5)系统中各功能、业务的异常情况3.2.5.正

7、确性1)输入用户实际数据以验证系统是否满足需求规格说明书的需求。2)测试用例中的测试点应保证至少覆盖需求规格说明书中的各项功能。3.2.6符合正常业务惯例1)测试数据应符合用户实际工作业务流程2)兼顾各种业务变化的可能3)要符合当前业务行业法律，法规。3.2.7容错性（健壮性）1)程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。2)在设计测试用例时，你需要定义程序的操作来确保程序的各方面都被测试到。为了确保清楚，准确的捕获到了完成一个操作所需要的所有行为，要满足下面条件：每一步都用主动语态书写，使用主动

8、语态的好处是使得测试执行人员4.实施计划4.1 测试进度安排本次测试的时间安排如下：里程碑执行者开始时间完成时间天数（天）需求分析CRM系统业务分析编写需求并导入ALM测试用例设计设计测试用例用例评审导入ALM（也可以直接在ALM录入）测试执行ALM中创建测试集将测试计划中案例添加到测试集第一轮测试执行并提交缺陷以及测试报告第二轮测试执行并提交缺陷以及测试报告项目总结报告系统测试的总结4.2 测试人员安排以及职责人员角色职责、任务备注PM编写项目计划，审核测试计划，审批测试案例，项目进度追踪管理，评估并防控风险及问题的发生PA编写测试计划，评审案例，协助将案例导入ALM，管理测试过程，生成QC

9、测试报告系统测试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边界值分析法指对输入的边界条件进

10、行分析，设计出针对边界值的测试用例。5.1.3因果图法就是利用图解法分析软件输入(原因)和输出条件(结果)之间的关系，以设计测试用例的方法。因果图法适合于检查程序输入条件的多种情况的组合，并最终生成判定表，来获得对应的测试用例。5.1.4功能图法功能图是描述程序状态变化、转移的过程，因为软件运行或操作的过程可以看作是其状态不断发生变化的过程。测试用例的设计就是如何覆盖所有软件表现出来的状态，即在满足输入/输出的一组条件下，软件运行是一系列有次序的、受控制的状态变化过程。5.1.5错误推测法推测法主要依赖经验、直觉来作出简单的判断甚至是猜测，给出可能存在缺陷的条件、场景等，在找到缺陷后，设计出相

11、应的测试用例。5.1.6正交实验设计方法主要步骤是：1)对软件需求规格说明中的功能要求进行划分(层层分解与展开)，分解成具体的、相对独立的基本功能。2)根据基本功能的质量需求，找出影响其功能实现的操作对象和外部因素，每个因素的取值可以看作水平，多个取值就存在多个水平。3)确定待测试软件中所有因素及其权值，这是测试用例设计的关键，确保全面、准确。权值是依据各因素的影响范围、发生的频率和质量的需求来确定的。4)加权筛选，生成因素分析表。5)利用正交表构造测试数据集，正交表的每一行，就是一条测试用例。考虑交互作用不可忽略的处理因素和不可混杂的原则，有交互作用的组合优先安排。6)利用正交实验设计方法设

12、计测试用例，可控制生成的测试用例数量，覆盖率高且测试效率高。5.1.7接口间测试测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。5.1.8数据库测试依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。5.1.9可理解（操作）性理解和使用该系统的难易程度（界面友好性）。5.1.10可移植性在不同操作系统及硬件配置情况下的运行性。5.2软件测试的一些准则软件测试从不同的角度出发会派生出两种不同的测试原则，从用户的角度出发，就是希望通过软件测试能充分暴露软件中存在的问题和缺陷，从而考虑是否可以接受该产品，从开发者的角度出发，就是希望测试能表明软件产品不存

13、在错误，已经正确地实现了用户的需求，确立人们对软件质量的信心。为了达到上述的原则，那么需要注意以下几点：1应当把“尽早和不断的测试”作为开发者的座右铭2程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完。3设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。4一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。5对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。6制定严格的测试计划，并把测试时间

14、安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。7回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。8妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。6. 测试的各项标准6.1 测试项通过/失败的标准 一般有“基于测试用例”和“基于缺陷密度”两种评比准则，在这里我们采用前者。准则如下：功能性测试用例通过率达到95；非功能性测试用例通过率达到90；沒有高于优先级 3以上的缺陷。备选通过办法：根据实际情况由软件开发部门的经理、项目经理和测试负责人等共同讨论确定本阶段是否结束。6.2 中断测试和恢复测试的判断标准缺陷数量大于1

15、00时中断测试直至缺陷修复到10时恢复当代码不全时停止测试直至代码全面恢复测试当缺陷严重程度为4的个数超过总体缺陷的1/2时停止测试当缺陷优先级为1的个数超过总体缺陷1/3时停止测试7. 缺陷跟踪7.1 缺陷类型 本次测试过程中缺陷的管理将在ALM中进行，缺陷大致包含如下状态：缺陷类型具体含义冗余代码多代码冗余，即是编程时不必要的代码段。兼容性差软件从某一环境转移到另一环境后不能正常运行可操作性差软件难以理解,不容易使用,运行缓慢。界面不友好最终用户会认为界面不好。与需求不一致软件没有实现产品规格说明所要求的功能模块;软件实现了产品规格说明没有提到的功能模块。可扩展性差软件在原有的功能上不容易

16、实现新增其他新的功能。7.2 缺陷管理流程图缺陷的状态如上所示，通常缺陷的管理流程如下图所示：7.3 缺陷严重程度和优先等级缺陷严重程度：严重级别严重程度描述1-Low使用不方便的问题对软件的改进建议：1)容易给用户误解和歧义的提示；2)界面需要改进的；3)对有疑虑的文档，提出修改建议2-Medium界面非关键信息错误微小的错误，不会影响系统的功能风格不统一，包括相近流程的界面布局相异，相同的问题点提示信息相异，但对用户的使用方法和使用习惯不造成影响（需求中明确的风格要求除外）如帮助、提示信息不完整，有错误，但不影响用户使用。不正确的，但有使系统使用起来不太方便的错误：1)系统的提示语不明确，

17、不简明2)滚动条无效3)可编辑区和不可编辑区不明显4)光标跳转设置不好，鼠标（光标）定位错误5)上下翻页，首尾页定位错误6)界面不一致，或界面不正确7)日期或时间初始值错误（起止日期、时间没有限定）8)按钮或标签上有拼写错误的单词、不正确的大小写该问题是一个不准确或容易误解的行为，但不会引起下面（3、4、5级别）列出的问题3-High功能缺失或错误，界面关键信息错误该问题增加了安装、测试或用户操作的复杂度或成本该问题轻微降低了系统的性能，但系统仍然能工作非核心功能实现不完整或不正确，但对系统影响很小，系统仍然能工作业务流程对应的功能未实现，但是有替代方法解决，不影响实际的使用部署文档描述不明确

18、，增加部署难度不正确的，但不会影响系统稳定性的：1)过程调用或其它脚本错误2)系统刷新错误3)产生错误结果，如计算结果错误等4)功能的实现有问题。如在系统实现的界面上，一些可接受输入的控件点击后无作用，对数据库的操作不能正确实现5)编码时数据类型、长度定义错误的6)对用户的使用有操作顺序上的限制7)虽然正确性不受影响，但系统性能和响应时间受到影响4-Very High导致系统崩溃、数据丢失、严重系统资源泄露，关键功能缺失或错误该问题会严重降低系统的性能业务流程不正确需求实现不完整，设计实现上的缺陷，且无替代方法，如：设计了3条路上山，但是实际只有一条可以上该问题不符合需求规格书配置项设计错误，

19、无法正常配置，或配置后，测试中出现与配置相关的错误部署文档错误，导致部署失败与其它网元的接口，调用或提供错误申报信息提交错误，可继续测试（如联网申报、分类错误、乱码、违禁信息），但影响应用后续审核上线；5-Urgent必须马上解决的，根据情况可以要求项目组立刻发布新版本，阻碍流程、系统崩溃导致开发或测试无法进行或程序无法正常运行的缺陷。提交物缺失，导致测试、部署和维护无法正常进行需求未实现正常的操作，导致系统（进程）崩溃系统不能启动或启动后无法正常工作系统（进程）经常自动崩溃（至少一天一次）缺陷的优先级：优先级优先级描述1-Low可能会修复，但是也能不修复2-Medium如果时间允许应该修复3

20、-High在产品发布前必须修复4-Very High尽快修复5-Urgent立即修复，停止进一步测试7. 测试报告8. 风险及应急措施风险：1)人员流动风险：在项目进行过程人员的流动导致的风险；2)人员过失风险：因测试人员在工作中不认真，如测试用例执行不彻底，结果填写错误等；3)环境风险：在项目进行过程中，由于测试环境的问题导致的错误及项目延期等问题；4)需求变更风险：由于需求的变更导致的测试在需求上发生的错误或遗漏；5)需求分析错误：因需求分析人员在需求分析中出现的理解错误，导致的一系列连带错误；6)需求文档缺失：测试人员没有详细设计说明书，导致测试在需求分析中出现错误；7)用例设计风险：测

21、试人员在用例设计中出现不到位而导致的风险；8)自动化测试风险：因界面不稳定而导致的自动化测试风险；9)硬件资源风险：因为对测试硬件资源预估不足，导致的测试进行中出现的资源紧张；10)版本控制：因测试过程中版本控制不足而导致的程序出现的混乱，出现不应出现的问题；11)时间风险：因测试时间预估不足而导致的不能按时将项目交付；12)回归风险：因回归测试不彻底而发生的风险；13)环境改变风险：因测试环境和真实环境不一致，导致的测试不彻底；14)隐藏缺陷：因程序在测试运行中没有出现，而在特殊情况下出现的缺陷导致的风险；解决方案：1)加强人员储备，在项目组中人员互为替补，及时做好人员的补充；2)加强人员的

22、监督，优化人员的监督机制；3)对测试环境定期检查，尽量避免出现的问题，同时，为项目中预留适当时间来缓冲因出现的问题而导致的延期；4)在项目初期与客户明确需求，避免需求的后期变更，同时，在项目计划期留出缓冲时间；5)做好小组评审，争取在问题的初期改正，如用例设计，需求分析等；6)加强测试中的信息交流，及时与客户代表沟通，明确需求；7)与开发人员及时沟通，争取界面的尽快稳定，必要的话，取消部分自动化测试项目；8)对硬件资源的及时监控，合理分析，争取在问题出现前解决；9)明确版本控制，避免版本混乱；10)初期合理安排计划，进行过程中出现问题，尽量在不改变计划的前提下通过其他措施赶工，如果确定不能按期完成，与项目经理沟通；11)回归测试尽量详细；12)在测试环境的配置，争取尽量与真实环境一致；鼓励测试人员发挥主观能动性，提出可能出现的缺陷，完善测试过程。