摘要:
思源CRM系统软件 测试 总结报告 文件状态: 草稿 正式发布 正在修改 文件标识: SIYUANCRM-TEST-SUMREPORT 当前版本: 3.0 作者: 李金 完成日期: 2018-05-31 1. 简介 1.1目的 编写该测试总结报告主要有以下几个目的 1.通过对测试结果的分析,得到对软件质
思源CRM系统软件测试总结报告
文件状态:
√草稿
正式发布
正在修改 |
文件标识: |
SIYUANCRM-TEST-SUMREPORT |
当前版本: |
3.0 |
作 者: |
李金 |
完成日期: |
2018-05-31 |
1. 简介
1.1目的
编写该测试总结报告主要有以下几个目的
1.通过对测试结果的分析,得到对软件质量的评价
2.分析测试的过程,产品,资源,信息,为以后制定测试计划提供参考
3.评估测试测试执行和测试计划是否符合
4.分析系统存在的缺陷,为修复和预防Bug提供建议
1.2背景
近年来,伴随着企业对客户管理的不断升级,为了方便大、中型企业对客户资料的整理及统计、对销售过程的跟踪及统计、对产品订单统计的管理,提高管理工作的准确率,节省人力、物力,特此推出思源CRM系统V3.0版。
1.3用户群
主要读者:思源CRM系统项目管理人员,思源CRM系统项目测试经理
其他读者:思源CRM系统项目相关人员。
1.4定义
基本功能点测试:等价类划分法、边界值法、错误推测法、场景法
业务流程测试:根据业务逻辑,构建测试数据,执行业务流程,查看执行结果与预期是否一致
界面易用性测试:根据界面测试规范及日常使用习惯,提出软件的非功能实现问题
回归测试:对已修复的问题,根据测试出该错误的用例,重新执行该用例,验证问题是否真正被修复,以及是否又引起了其它错误
缺陷定义:
级别 |
定义 |
一级bug |
导致系统无法实现功能目标,使用无法继续进行。主要包括:程序非正常终止、程序死机、关键需求未实现、软件功能与需求严重不符。并且重现率为50%上的,为一级BUG。 |
二级bug |
导致系统无法正常实现功能目标,但知道如何通过其它途径来避免错误发生。主要包括:程序非正常终止但可避免、非关键需求理解错误。并且重现率为50%以下,或者使用频率不高,为二级BUG。 |
三级bug |
系统功能目标基本实现,软件功能与需求基本相符,但部分功能有错误或者界面显示有错误。例如:单个字符串显示错误,图片位置与文字重叠,无法辨认等。 |
四级bug |
界面显示与需求相符,但用户使用不方便,如用户界面不很友好。 |
1.5测试对象
对8rcm客户关系管理系统进行全新测试,主要进行功能、业务、界面性、易用性、兼容性测试用例的编写
1.6测试阶段
单元测试由研发人员进行单元测试代码编写、执行。
1.6.2 集成测试
集成测试的目的是确保程序满足概要设计说明书的要求,测试内容包括模块的功能、模块间的接口以及集成后的功能,并且对以前集成的子系统进行增量式测试。
为确保集成测试与开发进度相吻合,开发完一个模块,就测一个模块。集成测试主要以功能测试为主,同时兼顾用户界面测试、易用性测试、数据和数据库完整性测试及
性能测试。
1.6.3系统测试
系统测试是通过与系统的需求规格作比较,发现软件与系统需求规格不相符合或与之矛盾的地方。它将通过集成测试的软件作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结起来,在模拟实际运行环境下对系统进行的测试。
系统测试主要进行业务流程方面的测试,同时进行回归测试。主要进行功能测试、性能测试、用户界面测试、易用性测试、压力测试、负载测试等。
(1) 保证系统中所有功能按正常流程都能正确实现。
(2) 保证多用户并发操作时模块功能实现正确。
(3) 保证系统界面符合界面规范和易用性符合用户操作习惯。
(4) 保证系统对非法数据能正确处理。
(5) 保证系统符合项目规范、浏览器兼容性、安装卸载等多个方面。
1.6.5回归测试
开发人员修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
1.6.5验收测试
对即将上线的产品由
软件测试内部人员模拟用户进行alpha测试、由软件的最终用户或潜在用户在一个或多个场所或环境下进行beta测试。
测试工具
名称 |
简介 |
测试员 |
Junit |
进行思源CRM系统单元测试 |
测试员1 |
Python+Selenium WebDriver+ Robot Framework |
验收功能自动化测试 |
测试员1 |
Jmeter |
性能、接口测试工具 |
测试员1 |
Zentao |
项目管理、Bug跟踪系统 |
测试员1 |
LoadRunner 11.0 |
企业级软件并发自动化压力测试工具 |
测试员1 |
SVN |
项目版本管理 |
测试员1 |
Jenkins |
持续集成工具 |
测试员1 |
QTP |
Web网页功能测试 |
测试员1 |
参考资料
《思源CRM系统需求规格说明书》
《思源CRM系统测试计划》
《思源CRM系统测试用例》
《思源CRM系统帮助文档》
2. 测试概要
思源CRM系统测试从 2017 年5月 1日开始到 2017 年 8 月 15 日结束,共持续 90天,测试功能点 174 个,执行 2385 个测试用例,平均每个功能点执行测试用例 13.7 个,测试共发现 427 个 bug,其中严重级别的 bug68 个,无效 bug44 个,平均每个测试功能点 2.2 个 bug。
思源CRM系统测试通过禅道进行缺陷跟踪管理,每一个测试阶段都有详细的 bug 分析表和阶段测试报告。
2.1进度回顾
任务 |
开始时间 |
结束时间 |
任务描述 |
测试计划编写 |
2017.5.01 |
2017.5.06 |
规划开发和测试的具体步骤 |
测试计划评审 |
2017.5.07 |
2017.5.07 |
对测试计划进行评审 |
测试用例设计 |
2017.5.08 |
2017.5.28 |
分析程序的具体功能模块,编写每一个模块的测试用例 |
测试用例评审 |
2017.5.29 |
2017.5.29 |
对测试用例进行评审 |
测试脚本设计 |
2017.5.30 |
2017.6.14 |
自动化测试设计测试脚本 |
测试脚本评审 |
2017.6.15 |
2017.6.15 |
对测试脚本进行评审 |
测试执行 |
2017.6.16 |
2017.7.28 |
执行测试用例 |
单元测试 |
2017.6.16 |
2017.6.30 |
执行测试脚本 |
集成测试 |
2017.7.01 |
2017.7.09 |
执行测试脚本 |
系统测试 |
2017.7.10 |
2017.7.21 |
按照测试用例测试系统 |
验收测试 |
2017.6.22 |
2017.7.28 |
按照需求进行验收测试 |
回归测试 |
2017.7.29 |
2017.8.13 |
修改Bug,重新测试,直到不再出现Bug |
测试评估 |
2017.8.14 |
2017.8.14 |
总结测试过程,编写测试报告 |
测试报告评审 |
2017.8.15 |
2017.8.15 |
对测试总结报告进行评审 |
2.2测试执行
此次测试严格按照项目计划和测试计划执行,按时完成了测试计划规定的测试对象的测试。针对测试计划规定的测试策略,在测试执行中都有体现,在测试执行过程中,依据测试计划和测试用例,对系统进行了完整的测试
2.3测试用例
思源CRM系统测试用例
3. 测试环境
3.1 软硬件环境
硬件
序号 |
环境类型 |
设备配置 |
1 |
数据库服务器 |
内存 8g
硬盘 300G
CPU 双核2.7GHZ |
2 |
Web应用服务器 |
内存 8g
硬盘 300G
CPU双核2.7GHZ |
3 |
测试及负载环境 |
内存 8g
硬盘 300G
CPU双核2.7GHZ |
软件
序号 |
环境类型 |
配置 |
1 |
服务器 |
操作系统:LINUX RedHat6.5
Web服务:IIS
数据库:SQL Server 2008 |
2 |
测试环境 |
操作系统:Windows2007 旗舰版
浏览器:Google Chrome 63.0
Firefox 59.0.1
IE8.0 |
3 |
负载运行环境 |
操作系统:Windows2007 旗舰版
浏览器:Google Chrome 63.0
Firefox 59.0.1
IE8.0 |
4. 测试结果及分析
5. 测试结论
5.1功能性
系统正确实现了系统管理、基础数据、客户管理、沟通服务、机会管理等主要模块的功能,正确实现了对公司信息、部门信息、员工信息、商品信息的添加、修改和删除的功能,正确实现了对客户信息、联系人信息、竞争对手信息的添加、修改、删除和查看的功能,正确实现了对客户行动任务的添加、修改和关闭的功能,正确实现了对机会分类的管理的功能。
5.2易用性
现有系统实现了如下易用性:
1、查询,添加,删除,修改操作相关提示信息的一致性,可理解性
2、输入限制的正确性
3、输入限制提示信息的正确性,可理解性,一致性现有系统存在如下易用性缺陷:
4、界面排版不美观
5、输入,输出字段的可理解性差
6、输入缺少解释性说明
7、中英文对应的正确性
8、中英文混排
5.3可靠性
现有系统的可靠性控制不够严密,很多控制是通过页面控制实现的,如果页面控制失效,可以向数据库插入数据,引发错误。
现有系统的容错性不高,如果系统出现错误,返回错误类型为找不到页面错误,无法回复到出错前的状态
5.4兼容性
现有系统支持window 下的IE 浏览器和傲游浏览器,支持linux 系统下的IE 浏览器和火狐浏览器。
现有系统未进行其他兼容性测试
5.5安全性
现有系统控制了以下安全性问题:
1、把某一个登录后的页面保存下来,不能单独对其进行操作不进行登录
2、直接输入某一页面的Url 能否打开页面并进行操作不应该允许。
现有系统未控制以下安全性问题:
3、用户名和密码应对大小写敏感
4、登陆错误次数限制
6. 分析摘要
6.1覆盖率
此次测试,所有测试用例都是在中文界面下执行,未在英文界面下执行,测试不包括英文界面下的测试,也不包括正对英文翻译的测试。
此次测试,部分页面需求描述无明确的定义,对输入限制无详细定义,无明确的测试依据,在测试过程中,测试是根据输入字段含义,测试人员理解,以及和项目经理,开发人员沟通获得测试依据,无法保证测试依据的正确性和完整性,因此,没有进行完整的,正确的无效数据的测试,测试覆盖率不够,无法保证测试的有效性和正确性
6.2遗留缺陷的影响
1.缺陷描述:酒店娱乐项添加页面,“距离”字段无单位,建议增加单位
缺陷影响:距离字段无单位说明,无衡量标准,用户易用性不好
推迟原因:需求定义无单位定义,统一在升级版本中解决
2.缺陷描述:酒店基础信息管理模块,默认语言设置不一致。用中文查询酒店,进入酒店
基础信息模块后,如下模块,语言显示为“请选择”
而其他模块语言显示“中文语言”
缺陷影响:相同功能模块默认语言设置不一致,一致性不好
推迟原因:默认语言设置,目前无统一标准,升级版本中统一
3.缺陷描述:tomcat 日志有乱码,日志无项目名称,查看不方便
缺陷影响:其他项目日志都有项目名称,日志无项目名称,查看不方便
推迟原因:目前的日志为了调试方便,显示了很多其它信息,在项目正式发布时会统一处理的。
4.缺陷描述:取消政策管理要么,取消时间“天/小时”缺少单位补充字段
缺陷影响:该处因为是两个不同的单位时间,需要有另外一个单位补充字段补充所所填写内容的单位
推迟原因:该缺陷单位补充字段本来存在,翻译不够准确,不能理解为补充单位的字段,需要等翻译完毕后再确认。
5.缺陷描述:数据字典种类修改,默认值设置后,在调用该数据字典种类的数据字典,默认值无显示
缺陷影响:数据字典种类的默认值设置后,不能显示设置的默认值,相当于数据字典种类默认值设置功能未实现
推迟原因:该功能暂时不好实现,需要和和系统的默认语种一起处理。
6.缺陷描述:担保政策管理页面,“Edposit Due”缺少解释行输入描述信息
缺陷影响:缺少解释性输入描述信息,用户不理解应该输入什么内容
推迟原因:需求没有描述,需要解释性说明文字由项目经理整理后,在升级版本中添加
7.缺陷描述:多媒体添加,文件上传功能未实现
缺陷影响:文件上传功能未实现
推迟原因:该功能暂时不好完成,在下个版本中完成
8.缺陷描述:参照点添加权限和修改权限单独控制出现权限异常错误
缺陷影响:用户执行添加,修改时,出现权限异常,无法完成任务
推迟原因:B9 版本发现该权限,B10 版本未通过验证,目前该模块开发人员调休,无法修改bug,
9.缺陷描述:酒店渠道绑定关系权限控制出现权限异常错误
缺陷影响:a>权限控制易用性不好,会引起用户误操作;
b>权限控制错误
推迟原因:B9 版本发现该权限,B10版本未通过验证。该模块后台无insert 权限,只有Update权限,与其他模块不同,需要重新设置权限控制方式。
10.缺陷描述:酒店Rate 绑定关系权限控制出现权限异常错误
缺陷影响:a>权限控制易用性不好,会引起用户误操作; b>权限控制错误
推迟原因:B9 版本发现该权限,B10版本未通过验证。该模块后台无insert 权限,只有Update权限,与其他模块不同,需要重新设置权限控制方式。
11.缺陷描述:新建业务管理员权限用户,进入打包促销页面出现权限异常错误
缺陷影响:除系统管理员外,其他用户无法进行打包促销操作
推迟原因:B10 版本发现该bug,目前该模块开发人员调休,无法修改bug
6.3 建议
1、在项目开始的时候应该制定编码标准,数据库标准,需求变更标准,开发和测试人员都严格按照标准进行,可以在后期减少因为开发,测试不一致而导致的问题,同时也可以降低沟通成本。
2、发布版本的时候,正确布置测试环境,减少因为测试环境,测试数据库数据的问题而出现的无效bug。
3、开发人员解决bug 的时候,填写bug 原因以及解决方式,方便bug 的跟踪。
4、开发人员在开发版本上发现bug,可以通知测试人员,因为开发人员发现的 bug很有可能在测试版本上出现,而测试人员和开发人员的思路不同,有可能测试人员没有发现该bug,而且,这样可以保证发现的bug 都能够被跟踪。
7. 度量
7.1资源消耗
测试时间 |
2017年5月1日至2017年8月15日 |
测试人力 |
1人×45天+1人×40天=85天 |
硬件资源 |
服务器:pc 1台
客户端:pc 1台 |
8. 典型缺陷引入原因分析
测试过程中发现的缺陷主要有以下几个方面:
8.1需求定义不明确
需求文档中,存在功能定义错误,输入输出字段描述错误,输入输出字段限制定义错误,输入输出限制定义缺失这几种类型的缺陷。使得开发人员根据需求进行设计时,没有考虑相关功能的关联性,以及需求错误的地方,在测试过程中,需求相关的问题表现出来。需求做改正,设计必须跟着做改动,浪费时间和影响开发人员的积极性,降低开发人员对需求的信任,可能会导致开发人员不按照需求进行设计而根据自己的经验来进行设计。
8.2功能性错误
1、功能没有实现,导致无法进行需求规定的功能的测试。主要是无法进入酒店设施管理,会议室管理页面,酒店安全项管理无法保存信息,地区,房型删除功能缺失。
2、功能实现错误,实现了需求未定义的功能,执行需求定义的功能时系统出现错误。主要是角色拥有不属于自己的权限,酒店联系人删除页面跳转错误等。
8.3页面设计和需求不一致
页面设计没有根据需求进行,输入,输出字段文字错误,用户无法理解字段含义。页面设计没有完成需求规定的输入限制验证,导致用户可以输入错误的或者无效的数据,这些数据有可能会引起功能性错误。
8.4多语言数据问题
1、系统中很多输入字段是通过调用数据字典的方式输入,但是现有系统中,很多数据字典的多语言信息没有完成,导致使用多语言的时候,显示空白字段。
2、系统中很多地方使用多语言,由于多语言编码不统一导致页面设计和数据设计使用语言编码不一致,由此引起的多语言数据无法显示的缺陷。
8.5页面设计易用性缺陷
1、页面设计不友好,系统中很多页面的输入字段无明确的输入提示,用户无法理解何种输入是正确的,但是用户输入错误后,系统提示出错,增加用户负担。
2、提示信息错误,不同模块相同结果的提示信息不一致,用户操作后,相应的提示信息不明确,引起用户误解。
3、提示信息一致性,用户在不同页面执行相同的操作,提示信息不同。
8.6开发人员疏忽引起的缺陷
因为开发人员的疏忽,导致系统需要验证的地方,调用了错误的验证,系统需要进行输入控制的地方没有进行相应的控制。