CRM系统测试计划 .docx

上传人:Che****ry 文档编号:13053071 上传时间:2022-04-27 格式:DOCX 页数:16 大小:144.23KB
返回 下载 相关 举报
CRM系统测试计划 .docx_第1页
第1页 / 共16页
CRM系统测试计划 .docx_第2页
第2页 / 共16页
点击查看更多>>
资源描述

《CRM系统测试计划 .docx》由会员分享,可在线阅读,更多相关《CRM系统测试计划 .docx(16页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。

1、精品名师归纳总结CRM系统测试 -测试方案版本: 1.0 XX 组12/04/2021可编辑资料 - - - 欢迎下载精品名师归纳总结1. 概述31.1 目的31.2 背景介绍31.3 测试方案读者范畴32. 测试基本内容32.1 测试环境32.2 测试工具42.3 测试范畴42.3.1 测试对象42.3.2 需要测试的特性42.3.3 不需要测试的特性43. 测试用例设计43.1 测试用例相关商定43.2 衡量测试用例设计的质量标准错误 . 未定义书签。4. 实施方案64.1 测试进度支配64.2 测试人员支配以及职责74.3 输出要求85 测试方法86. 测试的各项标准106.1 测试项通

2、过 / 失败的标准106.2 中断测试和复原测试的判定标准107. 缺陷跟踪117.1 缺陷类型117.2 缺陷治理流程图117.3 缺陷严肃程度和优先等级137. 测试报告148. 风险及应急措施14可编辑资料 - - - 欢迎下载精品名师归纳总结1. 概述1.1 目的CRM系统“ CRM系统 - 系统测试方案”文档有助于实现以下目标: 确定 CRM系统的测试环境、测试工具、测试范畴列出测试用例编写的相关商定确定所需资源并对 CRM系统测试的工具进行估量列出 CRM系统测试项目可交付元素文件中所规定的内容可以作为对测试过程完备性的对比检查表,将会提高测试过程的每个阶段的能见度,极大的提高测试

3、工作的可治理性。1.2 背景介绍客户关系治理系统是一种崭新的、国际领先的、以客户为中心的企业治理理论、商业运作模式、也是一种以信息技术为手段、有效提高企业受益、客户中意度、雇员生产力的详细软件和实现方法,是一套集理念、组织、流程、技术为一体的整体解决方案,是一种旨在改善企业与客户之间关系的新型治理机制。企业实施 CRM战略本质目标是与那些有价值的客户建立稳固的长期双赢关系,进而为企业在几楼的市场竞争中赢得优势。1.3 测试方案读者范畴测试工程师,开发经理,项目经理,实施负责人2. 测试基本内容2.1 测试环境软件环境相关软件、操作系统等操作系统: Win7硬件环境处理器: QEMU Virtu

4、al CPU VERSION 2.29GHz内存: 4G系统类型: 64 位操作系 统软件环境: CRM可编辑资料 - - - 欢迎下载精品名师归纳总结测试治理ALMHP11.52被测系统CRMN/A1.0报告以及测试用例Excel/WordMicrosoft20212.2 测试工具用途工具生产厂商 / 自产版本备注2.3 测试范畴2.3.1 测试对象被测系统为 CRM1.0 版本,使用 C+开发的。2.3.2 需要测试的特性本次系统测试要求包含以下业务流程: 添加线索导入与导出线索查看线索编辑线索删除线索搜寻线索2.3.3 不需要测试的特性本次系统测试不需要包含的内容:上述业务流程 2.3.

5、2之外的全部业务流程被删除的功能被外包的功能3. 测试用例设计3.1 测试用例相关商定在设计测试用例时,你需要定义程序的操作来确保程序的各方面都被测试到。为了确保清楚,精确的捕获到了完成一个操作所需要的全部行为,要中意下面条件:1) 测试用例的目标清楚,并能中意软件质量的各个方面,包括功能测试、性能测试、安全性测试、故障转移测试、负载测试等。可编辑资料 - - - 欢迎下载精品名师归纳总结2) 设计思路正确、清楚。例如,通过序列图、状态图、工作流程图、数据流程图等来描述待测试的功能特性或非功能特性。3) 在组织和分类上,测试用例层次清楚、结构合理。测试用例的层次与产品特性的结构/ 层次相一样,

6、或者与测试的目标/ 子目标的分类 / 层次相一样,并具有合理的优先级或执行次序。4) 测试用例掩盖全部测试点、掩盖全部已知的用户使用场景User scenario,也就是说每个测试点都有相应数量的测试用例来掩盖,而且将各种用户使用场景通过矩阵或因果图等方式列出来,找到相对应的测试用例。5) 测试手段的区分对待。在设计测试用例时,就要全面考量测试的手段,哪些方面可以通过工具测试,哪些方面不得不用手工测试,对不同手段的测试用例区分对待。6) 有充分的负面测试。作为测试用例,不仅要测试正确的输入和操作,仍要测试各种各样的例外情形,如边界条件、不正确的操作、错误的数据输入等。7) 没有重复、冗余的测试

7、用例,中意相应的行业标准等。3.2 衡量测试用例设计的质量标准3.2.1 系统性1) 对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系。2) 对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系。3.2.2 连贯性1) 对于系统业务流程来说,各个子系统之间是如何连接在一起,假如需要接口,各个子系统之间是否有正确的接口。假如是依靠页面链接,页面链接是否正确。2) 对于模块业务流程来说,同级模块以及上下级模块是如何构成一个子系统,其内部功能接口是否连贯3.2.3 相关性1) 考虑各个产品之间的相关性,当某个产品某个页面的字段发生增删改时

8、,其它产品是否有相应变化,和后台数据库之间是否匹配2) 当某个产品增加某个功能时,其它相关产品是否有相应措施可编辑资料 - - - 欢迎下载精品名师归纳总结3.2.4 全面性1) 应尽可能掩盖程序的各种路径2) 应尽可能掩盖系统的各个业务3) 应考虑存在跨年、跨月的数据4) 大量数据并发测试的预备5) 系统中各功能、业务的反常情形3.2.5. 正确性1) 输入用户实际数据以验证系统是否中意需求规格说明书的需求。2) 测试用例中的测试点应保证至少掩盖需求规格说明书中的各项功能。3.2.6 符合正常业务惯例1) 测试数据应符合用户实际工作业务流程2) 兼顾各种业务变化的可能3) 要符合当前业务行业

9、法律,法规。3.2.7 容错性健壮性1) 程序能够接收正确数据输入并且产生正确预期的输出,输入非法数据非法类型、不符合要求的数据、溢出数据等,程序应能给出提示并进行相应处理。2) 在设计测试用例时,你需要定义程序的操作来确保程序的各方面都被测试到。为了确保清楚,精确的捕获到了完成一个操作所需要的全部行为,要中意下面条件: 每一步都用主动语态书写,使用主动语态的好处是使得测试执行人员4. 实施方案可编辑资料 - - - 欢迎下载精品名师归纳总结4.1 测试进度支配本次测试的时间支配如下:间天需求分析杨斌12/1912/202CRM系统业务分析张慧媛12/2112/222编写需求并导入 ALM孟盼

10、盼12/2312/231里程碑执行者开头时完成时间天数可编辑资料 - - - 欢迎下载精品名师归纳总结测试用例设计李贝贝12/2412/263设计测试用例张爱美12/2412/263用例评审小组12/2612/261导入 ALM也可以直接在ALM录入孟盼盼12/2612/261李贝贝测试执行12/2712/293王鹏ALM中创建测试集孟盼盼12/2712/293将测试方案中案例添加到测试集孟盼盼12/2712/293一轮测试执行并提交缺陷以及测试报王鹏12/3012/301告二轮测试执行并提交缺陷以及测试报任福运12/3112/311告项目总结报告孙彦林12/3112/311系统测试的总结张爱

11、美12/3112/311第第4.2 测试人员支配以及职责人员角色职责、任务备注编写项目方案,审核测试方案,审批测试案例,项目进可编辑资料 - - - 欢迎下载精品名师归纳总结杨斌PM度追踪治理,评估并防控风险及问题的发生可编辑资料 - - - 欢迎下载精品名师归纳总结可编辑资料 - - - 欢迎下载精品名师归纳总结孙彦林PA编写测试方案,评审案例,帮忙将案例导入ALM,治理测试过程,生成 QC测试报告可编辑资料 - - - 欢迎下载精品名师归纳总结可编辑资料 - - - 欢迎下载精品名师归纳总结李贝贝张爱美梦盼盼王鹏系统测试OwnerALM Owner需求分析,设计测试用例,导入测试用例,执行

12、测试, 记录测试执行日志,缺陷追踪ALM Admin,治理 ALM项目,用户,完成全部和ALM相关的工作。协作 PM和 系统测试 Owner完成全部在 ALM 的工作。可编辑资料 - - - 欢迎下载精品名师归纳总结张慧媛CRM业务人员娴熟的把握 CRM,安装, CRM系统详细的需求 PM可编辑资料 - - - 欢迎下载精品名师归纳总结任福运SCM负责 CRM环境,项目文档的治理4.3 输出要求测试方案测试用例测试数据测试缺陷报告测试总结报告5 测试方法本次测试是 CRM的系统测试,确保:5.1 黑盒测试方法5.1.1 等价类划分法将全部可能的输入数据有效的和无效的划分成假设干个等价类。5.1

13、.2 边界值分析法指对输入的边界条件进行分析,设计出针对边界值的测试用例。5.1.3 因果图法就是利用图解法分析软件输入 缘由 和输出条件 结果 之间的关系,以设计测试用例的方法。因果图法适合于检查程序输入条件的多种情形的组合,并最终生成判定表,来获得对应的测试用例。5.1.4 功能图法功能图是描述程序状态变化、转移的过程,由于软件运行或操作的过程可以看作是其状态不断发生变化的过程。测试用例的设计就是如何掩盖全部软件表现出来的状态,即在中意输入 / 输出的一组条件下,软件运行是一系列有次序的、受把握的状态变化过程。5.1.5 错误估量法估量法主要依靠体会、直觉来作出简洁的判定甚至是估计,给出可

14、能存在缺陷的条件、场景等,在找到缺陷后,设计出相应的测试用例。可编辑资料 - - - 欢迎下载精品名师归纳总结5.1.6 正交试验设计方法主要步骤是:1) 对软件需求规格说明中的功能要求进行划分 层层分解与开放 ,分解成详细的、相对独立的基本功能。2) 依据基本功能的质量需求,找出影响其功能实现的操作对象和外部因素,每个因素的取值可以看作水平,多个取值就存在多个水平。3) 确定待测试软件中全部因素及其权值,这是测试用例设计的关键,确保全面、精确。权值是依据各因素的影响范畴、发生的频率和质量的需求来确定的。4) 加权选择,生成因素分析表。5) 利用正交表构造测试数据集,正交表的每一行,就是一条测

15、试用例。考虑交互作用不行忽视的处理因素和不行混杂的原就,有交互作用的组合优先支配。6) 利用正交试验设计方法设计测试用例,可把握生成的测试用例数量,掩盖率高且测试效率高。5.1.7 接口间测试测试各个模块相互间的和谐和通信情形,数据输入输出的一样性和正确性。5.1.8 数据库测试依据数据库设计标准对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。5.1.9 可懂得操作性懂得和使用该系统的难易程度界面友好性。5.1.10 可移植性在不同操作系统及硬件配置情形下的运行性。5.2 软件测试的一些准就软件测试从不同的角度动身会派生出两种不同的测试原就,从用户的角度动身,就是期望通过软件测试

16、能充分暴露软件中存在的问题和缺陷,从而考虑是否可以接受该产品, 从开发者的角度动身,就是期望测试能说明软件产品不存在错误,已经正确的实现了用户的需求,确立人们对软件质量的信心。为了到达上述的原就,那么需要留意以下几点:1. 应当把“尽早和不断的测试”作为开发者的座右铭可编辑资料 - - - 欢迎下载精品名师归纳总结2. 程序员应当防止检查自己的程序,测试工作应当由独立的专业的软件测试机构来完。3. 设计测试用例时应当考虑到合法的输入和不合法的输入以及各种边界条件,特殊情形要制造极端状态和意外状态,比方网络反常中断、电源断电等情形。 4确定要留意测试中的错误集中发生现象,这和程序员的编程水平和习

17、惯有很大的关 系。5. 对测试错误结果确定要有一个确认的过程,一般有A 测试出来的错误,确定要有一个B 来确认,严肃的错误可以召开评审会进行争辩和分析。 6制定严格的测试方案,并把测试时间支配的尽量宽松,不要期望在极短的时间内完成一个高水平的测试。 7回来测试的关联性确定要引起充分的留意,修改一个错误而引起更多的错误显现的现象并不少见。 8妥当储存一切测试过程文档,意义是不言而喻的,测试的重现性往往要靠测试文档。6. 测试的各项标准6.1 测试项通过 / 失败的标准一般有“基于测试用例”和“基于缺陷密度”两种评比准就,在这里我们接受前者。准就如下:功能性测试用例通过率到达95。 非功能性测试用

18、例通过率到达90。 沒有高于优先级 3 以上的缺陷。备选通过方法:依据实际情形由软件开发部门的经理、项目经理和测试负责人等共同争辩确定本阶段是否终止。6.2 中断测试和复原测试的判定标准缺陷数量大于 100 时中断测试直至缺陷修复到10 时复原当代码不全时停止测试直至代码全面复原测试当缺陷严肃程度为 4 的个数超过总体缺陷的1/2 时停止测试可编辑资料 - - - 欢迎下载精品名师归纳总结当缺陷优先级为1 的个数超过总体缺陷 1/3 时停止测试7. 缺陷跟踪7.1缺陷类型本次测试过程中缺陷的治理将在ALM中进行,缺陷大致包含如下状态:缺陷类型冗余代码多兼容性差 可操作性差界面不友好与需求不一样

19、详细含义代码冗余,即是编程时不必要的代码段。软件从某一环境转移到另一环境后不能正常运行软件难以懂得 ,不简洁使用 ,运行缓慢。最终用户会认为界面不好。软件没有实现产品规格说明所要求的功能模块;软件实现了产品规格说明没有提到的功能模块。可扩展性差软件在原有的功能上不简洁实现新增其他新的功能。7.2 缺陷治理流程图缺陷的状态如上所示,通常缺陷的治理流程如以下图所示:可编辑资料 - - - 欢迎下载精品名师归纳总结新建可编辑资料 - - - 欢迎下载精品名师归纳总结是否打开缺陷是否拒绝可编辑资料 - - - 欢迎下载精品名师归纳总结打开修复重新打开是否修复否是12关闭可编辑资料 - - - 欢迎下载

20、精品名师归纳总结7.3 缺陷严肃程度和优先等级缺陷严肃程度:严肃级别严肃程度描述使用不便利的问题 对软件的改良建议:可编辑资料 - - - 欢迎下载精品名师归纳总结1-Low2-Medium3-High1) 简洁给用户误会和歧义的提示。2) 界面需要改良的 。3) 对有疑虑的文档,提出修改建议界面非关键信息错误.微小的错误,不会影响系统的功能.风格不统一,包括相近流程的界面布局相异,相同的问题点提示信息相异,但对用户的使用方法和使用习惯不造成影响需求中明确的风格要求除外如帮忙、提示信息不完整,有错误,但不影响用户使用。不正确的,但有使系统使用起来不太便利的错误:1) 系统的提示语不明确,不简明

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

22、增加部署难度不正确的,但不会影响系统稳固性的:1) 过程调用或其它脚本错误2) 系统刷新错误3) 产生错误结果,如运算结果错误等4) 功能的实现有问题。如在系统实现的界面上,一些可接受输入的控件点击后无作用,对数据库的操作不能正的确现5) 编码时数据类型、长度定义错误的6) 对用户的使用有操作次序上的限制可编辑资料 - - - 欢迎下载精品名师归纳总结可编辑资料 - - - 欢迎下载精品名师归纳总结4-Very High5-Urgent7) 虽然正确性不受影响,但系统性能和响应时间受到影响导致系统崩溃、数据丢失、严肃系统资源泄露,关键功能缺失或错误.该问题会严肃降低系统的性能.业务流程不正确.

23、需求实现不完整,设计实现上的缺陷,且无替代方法,如:设计了3 条路上山,但是实际只有一条可以上.该问题不符合需求规格书.配置项设计错误,无法正常配置,或配置后,测试中显现与配置相关的错误.部署文档错误,导致部署失败.与其它网元的接口,调用或供应错误.申报信息提交叉误,可连续测试如联网申报、分类错误、乱码、违禁信息,但影响应用后续审核上线。必需马上解决的,依据情形可以要求项目组马上发布新版本,阻碍流程、系统崩溃导致开发或测试无法进行或程序无法正常运行的缺陷。.提交物缺失,导致测试、部署和爱护无法正常进行.需求未实现.正常的操作,导致系统进程崩溃.系统不能启动或启动后无法正常工作.系统进程经常自动

24、崩溃至少一天一次可编辑资料 - - - 欢迎下载精品名师归纳总结可编辑资料 - - - 欢迎下载精品名师归纳总结缺陷的优先级:优先级优先级描述1- Low可能会修复,但是也能不修复2- Medium假如时间答应应当修复3- High在产品发布前必需修复4- Very High尽快修复5- Urgent马上修复,停止进一步测试可编辑资料 - - - 欢迎下载精品名师归纳总结7. 测试报告8. 风险及应急措施风险:1) 人员流淌风险:在项目进行过程人员的流淌导致的风险。可编辑资料 - - - 欢迎下载精品名师归纳总结2) 人员过失风险:因测试人员在工作中不认真,如测试用例执行不完全,结果填写错误等

25、。3) 环境风险:在项目进行过程中,由于测试环境的问题导致的错误及项目延期等问题。4) 需求变更风险:由于需求的变更导致的测试在需求上发生的错误或遗漏。5) 需求分析错误:因需求分析人员在需求分析中显现的懂得错误,导致的一系列连带错误。6) 需求文档缺失:测试人员没有详细设计说明书,导致测试在需求分析中显现错误。7) 用例设计风险:测试人员在用例设计中显现不到位而导致的风险。8) 自动化测试风险:因界面不稳固而导致的自动化测试风险。9) 硬件资源风险:由于对测试硬件资源预估不足,导致的测试进行中显现的资源紧急。10) 版本把握:因测试过程中版本把握不足而导致的程序显现的纷乱,显现不应显现的问题

26、。11) 时间风险:因测试时间预估不足而导致的不能按时将项目交付。12) 回来风险:因回来测试不完全而发生的风险。13) 环境转变风险:因测试环境和真实环境不一样,导致的测试不完全。14) 隐匿缺陷:因程序在测试运行中没有显现,而在特殊情形下显现的缺陷导致的风险。解决方案:1) 加强人员储备,在项目组中人员互为替补,准时做好人员的补充。2) 加强人员的监督,优化人员的监督机制。3) 对测试环境定期检查,尽量防止显现的问题,同时,为项目中预留适当时间来缓冲因显现的问题而导致的延期。4) 在项目初期与客户明确需求,防止需求的后期变更,同时,在项目方案期留出缓冲时间。5) 做好小组评审,争取在问题的

27、初期改正,如用例设计,需求分析等。6) 加强测试中的信息沟通,准时与客户代表沟通,明确需求。7) 与开发人员准时沟通,争取界面的尽快稳固,必要的话,取消部分自动化测试项目。8) 对硬件资源的准时监控,合理分析,争取在问题显现前解决。9) 明确版本把握,防止版本纷乱。可编辑资料 - - - 欢迎下载精品名师归纳总结10) 初期合理支配方案,进行过程中显现问题,尽量在不转变方案的前提下通过其他措施赶工,假如确定不能按期完成,与项目经理沟通。11) 回来测试尽量详细。12) 在测试环境的配置,争取尽量与真实环境一样。1.鼓励测试人员发挥主观能动性,提出可能显现的缺陷,完善测试过程。可编辑资料 - - - 欢迎下载

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 教育专区 > 高考资料

本站为文档C TO C交易模式,本站只提供存储空间、用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。本站仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知得利文库网,我们立即给予删除!客服QQ:136780468 微信:18945177775 电话:18904686070

工信部备案号:黑ICP备15003705号-8 |  经营许可证:黑B2-20190332号 |   黑公网安备:91230400333293403D

© 2020-2023 www.deliwenku.com 得利文库. All Rights Reserved 黑龙江转换宝科技有限公司 

黑龙江省互联网违法和不良信息举报
举报电话:0468-3380021 邮箱:hgswwxb@163.com