你与优秀的软件测试人员只差一个好的测试用例
发布时间:2019-05-24

       随着互联网行业的不断发展,软件测试人员已逐步成为互联网产品的守卫者。在日常工作中,一个优秀的软件测试人员除了要会实操检测bug之外,更要清楚的了解产品的需求点,做好测试用例设计。根据我以往的经验而谈,很多软件测试人员的测试用例设计方法比较陈旧,还需加强自己测试用例的设计能力。故我整理了这篇文章,与大家一起分享一下我的心德体会。
 

       浅谈测试用例的意义

       简单来说,测试用例设计是基于产品需求出发,为避免遗漏测试环点而准备的“listing”。现在很多公司都会要求测试人员设计测试用例,因为他们都意识到无论测试用例的设计是否全面,都必须有这个环节,它对产品的质量把控和效率都会起到促进的作用。

       因此,我们需要做好软件测试用例设计。那么,好的测试用例有哪些共性呢?我们怎么做好测试用例呢?下面给大家谈谈我的浅见。
 

       好的测试用例的共性

       其实,这是一个见仁见智的问题。不同的测试人员有不同的测试设计风格,这里我们求同存异即可。好的测试用例设计的共性大致如下:
 

       (1)测试设计结构组织合理。从测试用例的组织是开展测试的起点,良好的组织能够帮助我们快速定位到我们想关注的部分,这个部分的好坏关系到测试工作的持续性发展。

       (2)测试用例设计覆盖全面且不冗余。用精简的语言描述清楚一条测试用例,用较少的测试用例描述清楚需求测试点的覆盖。

       (3)测试用例设计具有可执行、可判定、可再现的特点。即在测试前提符合的前提下,按照测试步骤每一个测试用例都可以顺利执行,同时呈现相应的预期结果,而且测试用例在被多次执行的结果都应该是相同的。

       (4)逐步细化测试功能。在编写测试用例时,建议由提纲挈领到逐步细化,先写基本功能点,再逐步增加细节,切忌过早的陷入细节描述。同时测试设计粒度要适中,根据实际项目的测试效率和效果去平衡,太粗太细都不合适。
 

测试用例设计(以移动端测试设计为例)
 

       01面向问题的测试全面性组织方式
 

       移动客户端平台的测试,在传统的软件测试基础上,本身又具有自身比较突出的诸多特点。比如客户端平台多样化,系统碎片化问题突出,灵活性极高,因此仅仅将测试停留在基本功能以及传统理念上的测试组织,来确保移动客户端的测试全面性是不够的。
 

       传统的用例组织方式,如等价类划分,边界值分析,因果分析等,更多的是从面向如果精简测试用例,确保测试全面的前提下,尽量降低冗余而来的。现在我们推荐一种是面向问题发现的测试的组织方式,即由bug出现的分布对应相应的测试内容,从而达到测试全面性的一种组织方式。
 

       1) Basic – 基本功能测试

面向于被测应用的基本功能实现,在测试用例的组织上,主要可以通过功能分层,逐级细化;画出草图,然后文字化得方式书写。主要采用功能图分析方法,因果图分析方法。

       基本功能测试可以称之为一般性的功能实现测试,这部分可以不完全去考虑实现的好坏(如读取文件的速度),不考虑特殊的输入输出,不考虑特殊的中断,不考虑特殊的环境。我们组织用例时,考虑将基本功能测试点和其他特殊测试内容分离的原因在于,按照经验,我们倾向于认为,基本功能在一般状况下,在实现并在一轮完整的测试之后通常即可保证该部分是完备的,之后的问题一般的都是出现在基本功能实现基础上的特殊状况中。
 

       因此,如此组织用例,有利于我们后期,适当的裁剪测试用例,将更多的测试精力放在容易发生问题的部分,而基本功能基本上可以通过特殊状况的检验而覆盖到。
 

       2) Boundary – 边界分析测试

       在基本功能的基础上,开始考虑各种输入输出的影响。一般的,基本功能容易在边界附近出问题。主要采用等价类划分方法,边界值分析方法。用例组织上,可以梳理已经产出的基本功能草图,确定哪些部分存在边界问题。并构造测试用例,执行测试工作。

       如:

       · 边界类型数值大小 ,输入的数值的范围

       · 字串长短,Null-max-max+1

       · 内容有无

       · 支持与否,(保留字符,特殊字符,计划外字符。
 

       3) Memory – 存储测试

       主要测试涉及存储空间读写的部分。最大的问题还是内存泄漏(memory leak)。

       在测试用例组织上,主要考虑哪些部分容易发生memory的问题。特别是移动客户端容易出现的问题。比如:

       •    旋转屏幕—响应G sensor,画面需要重新载入,重新载入前的页面可能会发生内存无法释放的问题。移动客户端相对特有的。

       •    连续加载页面

       •    开多个窗口—比较典型的,如浏览器

       •    应用多次的互相调用—应用之间的相互调用,调用传递之间,可能存在问题,另外要特别注意“重入”;所谓重入,是指一个应用A叫起了应用B,但是应用B又可以再次叫起应用A,如message编辑时插入图片可以叫起camera,拍摄之后,camera可以不直接返回message编辑器窗口,而是通过点击分享-message,重入message编辑器,由此产生循环的栈叠加,也容易发生内存问题。

       •    多线程下载
 

       4) Performance – 性能测试

       响应速度,资源占用,流量消耗,CPU占用的测试需要比对benchmark,并依据和benchmark的比对来判断被测试应用的表现能力,另外一个参考是我们在立项阶段的对某些核心内容的预期,或者用户主观感受。立项初期就选择合适的竞品,选择核心的用例。所谓核心用例主要是依据用户的一个使用习惯,调研反馈总结出那些核心数据是用户在意的。

       比如:一款导航产品,位置平均误差会有一个用户体验可以接受的范围,对路径的优化结果会有一个主观感受等等。在测试执行时,切忌完全依赖于主观感受,对修复的预期缺乏清晰的目标。比如,我们认为一款产品的首页打开速度很慢,那多快才是我们所预期的,这个需要我们明确。
 

       5) Stress – 压力测试

      可以简单理解为在基本功能上的提升负载,速度,吞吐量等性能指标。一般的,移动客户端通过monkey之类的测试工具加以覆盖,以及录制回放工具之类的测试来实现压力检验。

       6) Capability – 兼容性测试

       兼容性测试是指测试软件在特定的硬件产台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能很好地运行的测试。简单的说,兼容性测试是指测试某新开发的软件在某一特定环境下与各种软件的协调性,软件之间能否很好的运作。

       移动客户端常见的兼容性测试测项

       •    网络兼容性测试(不同运营商3G,4G, WIFI,弱网)

       •    操作系统兼容性测试 (Android>=2.3, IOS >=7.0)

       •    ROM类型兼容性(主流厂商如苹果,华为,小米,魅族,OPPO等)

       •    分辨率兼容性测试 (各种不同的分辨率)

       •    数据兼容性(不同版本间的数据兼容)

       •    其他可能会涉及移动客户端兼容性测试测项

       •    蓝牙设备兼容性测试 (如果是一款使用蓝牙的应用)

       •    存储卡兼容性测试(比如文件管理器)

       •    第三方软件兼容冲突(比如输入法冲突)
 

       7) Interrupt – 中断功能测试

       当前的被测应用被另外的应用打断当前的功能执行状态。

       在用例组织上,主要在考虑执行某项操作时的系统打断,比如:

       •    来电

       •    短信

       •    闹钟提醒,日历提醒,蓝牙提醒

       •    插拔数据线,插拔耳机

       •    待机,锁屏

       •    低电量提醒
 

       8) Interaction – 交互功能测试

       应用以及应用之间的调用,以及不存在应用层面的调用,但是存在更低一层的资源抢夺以及公用。比如:

       •    页面占用

       •    内存占用

       •    音频资源占用

       •    摄像资源占用
 

       02实践经验
 

       综上述,我们通过全面测试的指导思想提出了多种测试设计方法,但是每种测试方法其实都有一个最佳测试时间,如在版本测试阶段,我们应当要先做基本功能测试,边界分析测试和中断,交互功能测试,快速发现bug提单给开发去快速修复,保证主体功能可以尽快得到保证,而不是一开始就先纠结与性能,压力和兼容测试。
 

       一方面这类测试往往所消耗的时间会很长,降低了发现bug的速度;另一方面,先做这部分测试后,再去发现主体功能的bug,那么在开发人员动了大量代码之后,还是要再执行一遍性能,压力和兼容测试的相关用例,不仅劳命伤财,效果还事倍功半。

       所以在实际项目测试中,当前我们的项目将测试内容分为功能测试,兼容性测试,性能测试,稳定性测试四项,分别在不同的测试阶段进行(具体排期在测试计划时确定):
 

       (1)功能测试 —— 版本测试阶段

       (2)兼容性测试 —— 回归测试阶段前期

       (3)性能测试 —— 回归测试阶段,版本功能稳定后执行

       (4)稳定性测试 —— 贯穿整个测试阶段,每晚执行monkey
 

       因此,我们的功能用例更多的会使用『基本功能测试』,『边界分析测试』『中断功能测试』『交互功能测试』这几类测试用例设计方法。具体大家在做项目测试时,也建议通过实际情况做调整。只有通过大量的坚持实践和不断的总结积累,才能打破固有思维,提升自己的测试用例设计能力。因此我也提炼了一些移动客户端的常见功能的测试用例设计点,下面,就逐一与大家分享一下。
 

       03APP页面类型功能测试点总结
 

       1)UE体验

       (1)布局与交互图保持一致;

       (2)真机效果与UE图没有视觉上的严重偏差,如字号,字体大小,加粗,字体颜色,行高,行间距,按钮摆放位置,间隔,尺寸等;

       (3)资源图正确使用,没有不必要的拉伸,压缩或其他效果;

       (4)各种提示,文字通顺不产生歧义,展示符合用户使用习惯;

       (5)动画效果不卡顿,正常展现。
 

       2)页面操作

       (1)是否有防重复点击,即连续快速点击不会出现多个页面或弹窗

       (2)单指滑动,单指单击,单指双击,单指长按,单指缩放,多指点击

       (3)摇一摇,横竖屏切换,前后台切换

       (4)长时间使用,长时间放在后台
 

       3)不同场景下的页面操作

       (1)不同网络,弱网下的页面跳转,点击响应的展现效果;

       (2)修改本地参数后的页面操作展现效果,如修改日期,时间,时区,语言,键盘等;

       (3)修改系统权限后的页面操作展现效果,如打开关闭定位,摄像,照片,通讯录等的授权等;

       (4)页面操作过程中有系统打断,如来电,短信,闹钟提醒,日历提醒,蓝牙提醒,插拔数据线,插拔耳机,待机,锁屏,低电量提醒等;

       (5)页面操作过程中进行前后台切换,如当页面数据交换时,有弹窗,提示框的时机进行切换容易发现问题;

       (6)针对非主线程调用的接口,前端要对异常及无网络情况做异步处理,不提示异常且不影响主线程操作。
 

       4)页面数据获取和展现

       (1)页面是否有缓存,缓存机制是怎样的,缓存的内容有哪些;

       (2)在提交页面数据失败后是否有重试机制,重试的接口参数是否保持不变;

       (3)在页面操作过程中,异步接口返回的内容,是否对用户透明(客户端兼容忽略请求返回msg)。
 

文章来源:网络 版权归原作者所有
上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8103),我们将立即处理。

相关阅读
/