一、前言
作为移动互联网产品最后一公里的守护者,我们必须要清楚的知道自己该做什么、怎么做。但从版本迭代速度、需求量级、测试人员不断变动等方面综合来看,我们很多人都没有做好充分的准备。测试方法落后、测试用例覆盖不全、测试效率低下,使得测试将要成为阻碍产品质量进一步提升的另一瓶颈。
![7c6a07d576dae32b47fc412532eb91ab.png](https://i-blog.csdnimg.cn/blog_migrate/a7e3244c9440860b4a5ef1e5753c23f2.jpeg)
因此,沉淀一下自己的工作心得,希望能帮助更多的人完善测试设计,提升自我测试能力。
二、提高测试用例质量
测试用例的存在,能对复杂需求的功能质量提升,以及自身测试效率的提升,起到非常基本的促进作用。因为测试用例本身就是通过对需求点的梳理,找出潜在的测试点,避免测试点的遗漏。
那么问题来了:为什么要强调提升测试用例质量呢?
测试用例设计能力的好坏,直接关系到各角色peer,尤其是开发人员对测试人员的印象的好坏。就如同测试人员去评价一位优秀的开发人员:代码规范、Bug少;思维严谨、效率高;沟通顺畅、责任心强…
同样的,开发人员去评价一名优秀的测试人员,也无非这几个方面:case覆盖全、漏测少;思维严谨、效率高;沟通顺畅、责任心强。
从这就可以看出,就像开发人员写不出好代码一样,测试人员测试用例设计的不好,其实是一件挺丢面儿的事。
此外,好的测试用例,对测试质量和测试效率,有着很大的影响。因为好的测试用例的设计,是需要在层层剖析功能需求,以及对开发设计逻辑深入理解的情况下构造出来的。因而,需求点挖的越深,测试点覆盖的就会越全面,漏测的几率也就越低。
同时,在梳理测试点的过程中,我们能够很清楚的找出各个测试点之间的各种关系:互斥、前后关联、相互影响等,通过对这种测试点之间相互关系的认识,又能够帮助测试人员有效地设计测试用例的执行顺序,省去了在执行阶段费心构造设计的时间,自然而然地提高了测试人员的测试效率。
三、好的测试用例的特点
不同的测试人员,可能存在这不同的测试用例设计风格。但也不外乎以下几种共性:
合理的组织结构:用良好的测试用例结构框架,聚焦到不同的关注模块,清晰且可延展。
精简的用例条例:用较少的测试用例,描述清楚测试点的覆盖,全面而不冗余。
稳定的测试方法:在一定的执行条件、顺序下,有明确的执行结果。
在进行测试用例设计的时候,建议像写论文一样,由提纲契领到逐步细化。在基本功能点的基础上逐步增加细节,不要过早陷入细节描述。同时,测试用例的粒度,要根据测试效率和效果来综合评估。
![db3cb2d097a57aab5abed4d5f557bbdb.png](https://i-blog.csdnimg.cn/blog_migrate/5f578e4de3bda39d999fc97d4d591dfb.jpeg)
四、移动端测试设计方法
考虑到移动端平台及系统的多样化、功能需求的复杂化,使用传统的用例组织方式(例如等价类划分、边界值分析、因果分析等)而将测试仅仅停留在基本功能上,目前看来已经远远不够,测试人员还需要从面向问题发现的角度来组织测试用例。即由Bug可能的分布点来考虑测试内容。
因此,在实际的项目中,移动端测试大致分为以下几点:
(1)基础测试:基本功能、数据交互(边界值、异常数据等)基本功能测试,可以通过功能分析、因果分析方法,将功能分层,逐级细化,先画出框架、草图,再文字细化。这一部分在一轮完整的测试后,通常即可保证该功能基本是完备的,之后的问题一般是出现在基本功能之上的特殊状况中。
因此,这一环节中,可以暂不考虑功能实现的好坏、特殊场景及特殊操作的影响,也就将基本功能测试点和其他特殊测试内容进行了分离。这样组织,也有利于裁剪测试用例,将更多的精力放在容易发生问题的部分,而这一部分的基本功能则可以通过特殊状况的检验而覆盖到。
(2)数据交互测试:主要是在基本功能的基础上,考虑各种输入输出。一般基本功能容易在边界附近出现问题。这里可以根据梳理初的基本功能草图,确定哪些部分可能存在相应的问题,然后加以构造。例如,输入的数值范围、字符长短、内容缺失、字符/数字类型是否支持等。
(3)性能测试:响应速度、资源占用(CPU、电量等)、流量消耗、稳定性
测试人员在进行产品测试过程中,对于响应速度、资源占用、流量消耗、CPU占用的测试,会有明确的用户主管感受。而判断产品性能是否符合预期,不能只凭主管感受,需要对合适的竞品进行分析,从竞品的核心用例得出一个benchmark。因此,立项初期,测试人员对预期的目标应该有一个清晰的认识。
(4)异常测试:中断测试(来电、短信、闹钟、日历、锁屏、弹窗等)、应用交互(资源抢夺、应用切换等)、手势测试(快速连续点击、多触屏点点击、滑动手势等)、硬件异常(存储空间不足等)
在设备平台强大的功能背景下,应用于应用之间,会存在执行状态被打断的情况,例如:来电、短信、闹钟、日历、锁屏、弹窗等;而在应用层更低一层的资源层面,也会存在这资源抢夺及公用的情况,例如:音频资源、摄像资源、内存占用等。
(5)兼容测试:网络兼容、操作系统兼容、分辨率兼容、版本兼容、硬件设备兼容(蓝牙、存储卡等)、第三方应用兼容(输入法等)
兼容测试是指新开发的软件在某一特定环境(例如:特定硬件平台、特定操作系统)下,与各应用软件之间的能够很好的运行。
![937edae8e3bd174fe257f7697ddbeb48.png](https://i-blog.csdnimg.cn/blog_migrate/4c3dd370e80f2c97e7ad2af97b605e22.jpeg)
五、测试用例设计结合实践
上文中提到了多个测试点,但每个测试其实都有一个最佳的测试时间。例如在版本开发测试阶段,测试人员应将重点集中在基础测试上,快速发现问题并推动修复,保证主体功能得到快速实现,而非在初始就纠结性能、压力、兼容性,避免研发人员在改动大量代码之后,还需要再重新执行一遍性能、压力、兼容相关测试,降低测试效率。所以,在设定测试计划时,就要明确不同测试阶段需要进行的工作。一般可按照以下阶段进行:
基础测试、异常测试——版本开发测试阶段;
兼容测试——回归测试阶段;
性能测试——回归测试阶段,待功能稳定后进行;
稳定性测试——建议在整个测试阶段,每晚进行;
以移动APP NA页面为例,提炼出一些移动端常见功能的测试用例设计点:
1.UE/UI体验
(1)布局与交互图保持是否一致
(2)真机效果与UE图没有视觉上的严重偏差,如字号,字体大小,加粗,字体颜色,行高,行间距,按钮摆放位置,间隔,尺寸等。
(3)资源图正确使用,没有不必要的拉伸,压缩或其他效果。
(4)各种提示,文字通顺不产生歧义,展示符合用户使用习惯。
(5)动画效果不卡顿,正常展现。
2.数据交互
(1)页面是否有缓存,缓存机制是怎样的,缓存的内容有哪些
(2)在提交页面数据失败后是否有重试机制,重试的接口参数是否保持不变
(3)在页面操作过程中,异步接口返回的内容,是否对用户透明(客户端兼容忽略请求返回msg)
(4)在页面操作过程中,对于接口返回的异常数据,客户端需兼容,保证程序不crash。
3.手势/操作
(1)是否有防重复点击,即连续快速点击不会出现多个页面或弹窗
(2)单指滑动,单指单击,单指双击,单指长按,单指缩放,多指点击
(3)摇一摇,横竖屏切换,前后台切换
(4)长时间使用,长时间放在后台
4.场景干扰
(1)不同网络,弱网下的页面跳转,点击响应的展现效果
(2)修改本地参数后的页面操作展现效果,如修改日期,时间,时区,语言,键盘等
(3)修改系统权限后的页面操作展现效果,如打开关闭定位,摄像,照片,通讯录等的授权等
(4)页面操作过程中有系统打断,如来电,短信,闹钟提醒,日历提醒,蓝牙提醒,插拔数据线,插拔耳机,待机,锁屏,低电量提醒等
(5)页面操作过程中进行前后台切换,如当页面数据交换时,有弹窗,提示框的时机进行切换容易发现问题。
(6)针对非主线程调用的接口,前端要对异常及无网络情况做异步处理,不提示异常且不影响主线程操作。