目录
1 概述
2 缩略词
3 已知问题和注意点
4 兼容性测试定义
5 兼容性测试目的
6 兼容性测试的作用
7 APP兼容性测试
7.1 手机系统
7.2 手机品牌
7.3 分辨率
7.4 运营商
7.5 网络
7.6 其他软件兼容性
7.7 测试点
8 Web兼容性测试
8.1 操作系统
8.2 浏览器
8.3 分辨率
8.4 测试点
9 缺陷管理
9.1 缺陷等级定义
9.2 缺陷书写规范
10 测试工具
11 测试策略
12 测试流程
12.1 测试流程说明
12.2 需求宣贯
12.3 测试计划
12.4 测试框架
12.5 执行测试
12.6 缺陷跟踪
12.7 版本发布条件
12.8 Bugreview
12.9 上线测试
12.10 测试总结
为使测试团队有明确的兼容性测试规范,按照合理章程开展工作,编写本文档,旨在规范兼容性测试过程的完整性,提高公司产品的兼容性方面的质量。
目的:
梳理兼容性测试点,为测试人员在进行兼容性测试时提供基本测试点;
无
1)兼容性测试范围较广,考虑到人力、资源等方面,WEB兼容性测试时硬件兼容暂未展开;
2)APP兼容性测试,真机数目有待扩充,非主流品牌、系统等可采用云测方式进行;
3)深层次兼容性测试需逐步完善;
兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能够很友好的运行的测试。
AAP : 随着互联网的快速发展,电子产品种类越来越多,尤其是移动设备。移动设备的品牌、系统、分辨率等均呈现出多样化,且均有各自的亮点与不同。这就导致了APP的有些功能在不同的移动设备上可能出现不同甚至功能不可用。而广大的用户使用的设备也是多种多样,为了给用户更好的用户体验,做APP的兼容性测试,是非常有必要的。
Web : 我们的Web项目面向的也是大众用户群体,而用户所使用的电脑、浏览器、屏幕分辨率等也是多种多样,可能某个功能在A设备或者浏览器上显示正常、操作正常,但是在B设备或浏览器上显示就可能就乱糟糟的,严重的可能导致功能异常,不同的分辨率也可能导致UI布局被破坏影响系统的易用性等,这样一来用户群体对项目系统的好感就大大的打了折扣,因此WEB项目的兼容性测试也是非常有必要的。
兼容性测试能够进一步提高产品的质量;
兼容性测试能使软件与尽可能多的其他软件“和平共处”,尽可能达到平台无关性;
兼容性测试能尽可能的保证软件存在的价值,它是衡量一个软件质量的重要指标;
兼容性测试能使软件产品的市场更广阔。
APP兼容性测试需要从以下几方面考虑:手机系统、手机品牌、分辨率、运营商、网络、其他软件兼容性。
7.1手机系统
1)手机的系统主要有:IOS、安卓、华为:EMUI 、小米:miui;
2)安卓系统主要版本有:9.0、8.0、7.0、6.0、5.0、4.4/4.3/4.2/4.1/4.0、3.2/3.1/3.0、2.3/2.2/2.1/2.0、1.6/1.5/1/1/1/0;
3)IOS系统主要版本有:12.1.2、11.0、10、9.0、8.0、7.0;
7.2手机品牌
1)销量前十的品牌:iphone、华为、华为荣耀、OPPO、VIVO、小米、魅族、三星、360、smartisan坚果(数据来源:中国品牌网:https://www.chinapp.com/paihang/shouji/);
7.3分辨率
1)主流手机分辨率有:29601440、25601440、2436 * 1125、23401080、22801080、22461080、22441080、22441080、22201080、1920 x 1080 、1334 x 750、960*540;
7.4运营商
1)主要运营商:移动、联通、电信。
7.5网络
1)网络:2G、3G、4G、WIFI。
7.6其他软件兼容性
1)主流软件:QQ、微信、支付宝、美团、淘宝等。
7.7测试点
在不同的系统、品牌、分辨率、运营商、网络的手机上,必须关注以下测试点:
1)是否可以正常登录系统、退出系统;
2)是否会出现闪退;
3)UI布局是否出现异位、乱码、变形、遮挡、留白等;
4)图片显示是否清晰、是否有拉伸;
5)动画特效显示是否正确;
6)存在输入框时,点击输入框是否可正常调出虚拟键盘,是否会遮挡输入框、按钮等;
7)收起虚拟键盘,界面显示及录入的数据显示是否正确;
8)主流程是否可以正常走通;
9)是否可以切换至后台运行,再切换回前台运行;
10)是否可以其他常用APP同时运行(例如QQ、微信等);
11)是否可以调用其他APP,例如手机自带的相册、相机;
12)是否支持手机自带返回及返回主页按钮;
13)上下滑动屏幕是否会闪退;
在不同的系统、品牌、分辨率、运营商、网络的手机上,注意以下测试点:
1)多个输入框来回切换光标定位是否正确;
2)提交或保存按钮多次点击是否出现多次提交、存储重复数据;
3)弱网络下数据存储与前台界面是否一致;
4)弱网络下无法加载数据或加载数据失败是否有合理提示;
5)弱网络下未加载界面或数据未加载完成是否可操作,或点击刷新是否出现闪退等问题;
6)突然断网或突然有电话等阻断程序进行,是否会出现数据上传失败或闪退等情况;
7)数据未加载完成滑动屏幕进行界面刷新,是否出现闪退;
8)权限测试,例如需调用的软件需要权限才能调用或需要解锁才能打开程序等;
9)长按屏幕或某些内容是否支持复制、粘贴(手机自带功能)或粘贴其他程序内复制的数据;
10)多次快速点击某一按钮或空白界面是否出现闪退;
11)多次切换TAB页,界面及界面数据展示是否正确或出现闪退;
12)在PAD上也需要进行兼容性测试,以上关注点也需要进行关注。
13)同时在两部手机上登录同一账户,是否会弹出提示或强制下线一部手机的登录信息;
14)授权申请时关闭某一权限,再次调用改权限时是否会出现闪退(例如关闭调用相机权限,再次调用是否闪退);
15)卸载APP后重新安装,是否可成功安装;
16)登录系统后锁屏,解锁后界面展示是否正确;
17)通过推送消息是否可以正常进入APP;
18)免打扰模式或关闭消息通知权限时,用户是否会接收到推送消息;
19)存在不可操作的置灰按钮时,点击置灰按钮,看是否可操作;
Web兼容性测试主要从以下几个方面考虑:操作系统、浏览器、分辨率。
8.1操作系统
主要操作系统有:
1)Windows(WindowsXP、Windows7、Windows10);
2)MAC;
3)LINUX。
目前产品需支持系统为:
1)Windows7及以上版本;
8.2浏览器
主要浏览器内核及对应浏览器有:
1)IE内核:IE8、IE9、IE10、IE11、360安全浏览器(兼容模式)、搜狗浏览器(兼容模式)、QQ浏览器;
2)Firefox内核:火狐浏览器;
3)Chrome内核:Chrome、360安全浏览器(极速模式)、搜狗浏览器(高速模式)。
目前产品需支持的浏览器及版本有:
1)IE9、IE10、IE11;
2)360安全浏览器
3)谷歌浏览器
4)火狐浏览器
8.3分辨率
常见分辨率有:
1)1024×768
2)1280×1024
3)1366X768
4)1680X1050
5)1920X1080
目前产品需支持的分辨率有:
1)1366X768
2)1680X1050
3)1920X1080
8.4测试点
在不同的操作系统、浏览器、分辨率电脑上,必须关注以下测试点:
1)是否可以正常登录系统、退出系统;
2)UI布局是否出现异位、乱码、变形、遮挡、留白等;
3)图片显示是否清晰、是否有拉伸;
4)动画特效显示是否正确;
5)导航链接是否均正确;
6)主流程是否能走通;
在不同的操作系统、浏览器、分辨率电脑上,注意以下测试点:
1)多次快速点击某一按钮或空白界面是否出现报错;
2)多次切换TAB页,界面及界面数据展示是否正确;
3)存在输入框时,是否可正常录入、提交、保存数据;
4)多个输入框来回切换光标定位是否正确;
5)连续点击提交/保存按钮是否会出现多次提交、存储重复数据;
6)弱网络下数据存储与前台界面结果是否一致;
7)弱网络下无法加载数据或加载数据失败是否有合理提示;
8)弱网络下未加载界面或数据未加载完成是否可操作,或点击刷新是否出现报错等问题;
9)是否支持常用快捷键,例如:Ctrl+C、Ctrl+V、Enter、Delete等;
10)登录系统后,直接复制导航栏地址,重新打开一个浏览器粘贴后进入系统,看是否显示为登录状态;
11)存在不可操作的置灰按钮时,点击置灰按钮,看是否可操作;
9.1缺陷等级定义
本规范定义以下四类测试错误类型:
A 类——致命缺陷Blocker:
阻碍开发和测试工作,致命性的缺陷。由于兼容性问题,导致系统无法登录、经常闪退或主流程应用模块无法启动、异常退出,无法测试,造成系统不稳定。
B 类——严重功能缺陷Critical 、Major:
由于兼容性问题,导致界面布局严重变形导致软件使用中存在较明显的障碍,或者局部功能错误,但可以采取其他变通的操作实现。
C 类——普通功能缺陷Normal 、Minor:
由于编兼容性问题,导致界面布局变形、图片无法显示等致使某个小功能无法使用,或者对特殊的操作与要求不能支持,存在某些细微的缺陷,但不影响程序正常应用。
D 类——轻微功能缺陷或建议trivial:
由于兼容性问题导致的界面布局轻微变形、图片显示模糊等页面细节问题或者优化建议等
9.2缺陷书写规范
1)针对不同的原因导致的问题要包含对应的原因,例如手机的品牌、操作系统或者是浏览器名称、版本等以及常规BUG中的:操作步骤、预期结果、实际结果,并清晰表述;
2)缺陷标题中应简洁明确,能够概括缺陷的总体现象;
3)兼容性问题需在两个以上环境中确认BUG再进行提交;
4)测试环境,发现版本,严重等级需在禅道系统中交代清楚,按照缺陷等级定义进行评级;
5)非必现BUG需进行10次以上测试,标注问题出现概率;
1)BrowserShots:是一款免费的跨浏览器测试工具,捕捉网站在不同浏览器中的截图。(http://browsershots.org,在线测试平台,优点:可测试不同的分辨率及系统以及不同浏览器的不同版本,缺点:无IE内核浏览器,易用性不高,仅适合单页面的UI测试,效率低,不推荐使用)
2)(推荐使用)百度MTC:线上移动应用云测平台,可在此平台进行移动APP兼容性测试、性能测试等,包括深度兼容性测试、虚拟机租赁功能(付费)。
3)testin云测:线上移动应用云测平台,可直接进行移动APP的兼容性测试、性能测试扥,包括深度兼容性测试、虚拟机租赁功能(付费)。
为了提高兼容性测试覆盖率,APP兼容性测试 计划采用真机测试+云测深度兼容测试(安装、启动、退出等主要操作)+云测租赁方式 ,进行兼容性测试,以真机测试为主,云测为辅。
WEB兼容性测试目前主要采用手工进行测试,工具应用方面有待完善。
12.1测试流程说明
因开发过程中可能存在需求变更,产品迭代以用户的需求进化为核心,因此总体测试流程按照敏捷模式。
12.2需求宣贯
需求宣贯一般由产品经理主导,研发和测试参与,测试团队需通过需求宣贯理解产品设计思路、逻辑、主要流程,产品变更内容,梳理出测试重点,测试方案。
12.3测试计划
设计图定稿后,测试组根据已经确定的设计图、产品规格说明书和开发计划,构建测试计划,计划中版本构建时间点需要明确,风险要及时反馈到项目组,测试计划需要相关各方进行评审。
测试计划应包含以下内容:
1)测试目标——对本次测试的要求和要达到的目标;
2)测试范围——需要测试小组测试的范围,例如需要兼容的:手机品牌、系统、手机分辨率、浏览器、计算机分辨率等;
3)工作分工——明确测试组内部及外部配合方的相关责任和工作关系;
4)测试策略——整体测试的总体测试策略、环境、方法和工具等;
5)完成标准——达到何种条件可以认为测试完成;
6)主要任务——每项任务的时间计划、前置条件及资源;
7)主要里程碑——关键任务及完成时间点
在项目研发过程中,要适时的对测试计划进行跟踪,以评估此计划的完整性、可行性,在项目结束时还要最后评估一下测试计划的质量。
12.4测试框架
在测试准备阶段中,测试人员需要根据产品规格说明书及设计图制定测试框架,准备好需要用到的环境及工具。因前端测试时间较紧,项目变动较大,用例可维护性不高,投入产出比较低,建议暂不设计用例,但需要有具体的测试框架作为指引。
12.5执行测试
此阶段是测试的主要部分,需要测试人员按照框架、测试计划和设计图开展测试。
1)根据测试计划、设计图,执行相应的测试用例,并做好测试记录;
2)进行缺陷登记,并跟踪解决情况,及时复测,关闭缺陷;
3)跟踪测试执行情况,了解影响测试执行的因素,及时跟进有关的协调、报告测试状态,根据项目的情况,选择有关的报告形式,晨会或邮件形式,将测试进展情况及时通报给有关各方。
12.6缺陷跟踪
目前测试按以下流程执行缺陷跟踪流程,主要工具为禅道,已实现缺陷全生命周期管理。
1)测试人员在测试过程中,记录被测产品缺陷,跟踪缺陷的分析、解决过程;
2)研发人员及时分析处理缺陷,并按要求记录缺陷的分析处理信息,更新缺陷状态,填制缺陷原因;
3)需要其它人员参与分析处理的时候,需及时将缺陷分配给下一环节人员;测试人员对待验证的缺陷需及时进行复测,测试通过后关闭缺陷;
12.7版本发布条件
APP兼容性测试完成标准:
1)覆盖全部已有真机且不存在未解决的1、2级缺陷,遗留缺陷数量产品经理可以接受;
2)百度MTC深度兼容测试中,通过率不低于95%(注意查看未通过的机型等信息);
3)测试完成本次迭代内容的主要功能、流程及所有界面测试,和80%以上回归测试;
APP兼容性测试目标:
1)不存在未解决的缺陷;
2)百度MTC深度兼容测试中,通过率不低于99.9%;
3)友盟上的“总崩溃率”低于0.1% ;
WEB兼容性测试完成标准:
1)覆盖主流浏览器(内核)、版本、分辨率,不存在未解决的1、2级缺陷,遗留缺陷数量产品经理可以接受;
2)测试完成本次迭代内容的主要功能、流程及所有界面测试,和80%以上回归测试;
WEB兼容性测试目标:
1)不存在未解决的缺陷。
2)兼容不同的操作系统,例如:MAC。
12.8 Bugreview
上线前反馈缺陷处理情况及状态,对于严重或致命BUG或不兼容的版本、机型等,由产品经理、测试经理及研发总监进行评审,达成共识后,进行处理,一般处理方案有【本期解决】、【延期解决】、【暂不考虑】。
12.9 上线测试
经过测试环境版本迭代,趋于稳定后,开展上线测试,上线后输出测试报告。
12.10测试总结
兼容性测试完成后,测试团队需编写相应的兼容性测试报告,对产品的兼容性加以评估,其目的在于总结测试过程和分析测试结果,最终确认版本是否可用,把发现的Bug 汇总成文档,和测试报告一起发送给各管理层人员,让其了解各版本的产品兼容性情况。兼容性测试报告应包含以下内容:
1)测试过程中对版本内容、时间、环境的描述;
2)APP产品覆盖的品牌、系统、分辨率等以及云测得到的测试结果;
3)WEB产品覆盖的浏览器、版本、分辨率等;
4)BUG的数量、已修复/未修复数量、严重等级、原有Bug 数、新增Bug数及分布情况;
5)测试结论及建议,测试团队作为产品出口,可从用户角度对于产品改进提出合理建议;