lsekfe 发表于 2021-3-25 11:24:27

测试用例的设计方法多维进阶版

质量监控的范围和概念
  1.用户体验是否舒服:
  以用户的角度对产品进行使用,以找到不合理,体验差的功能点。
  2.产品设计是否符合:
  以产品的角度对产品设计的完整性进行检验。
  3.性能状况是否稳定:
  以系统运维的角度找到产品性能的瓶颈。
  4.逻辑设计是否存在漏洞:
  以开发人员的角度检测产品的逻辑合理性。
  5.系统安全,数据安全是否有保障:
  以不法分子,黑客的角度对产品进行攻击,以检测产品的安全性。
  测试用例设计方法:
  软测行内共识的设计方法不再赘述,转帖一篇文章小白们可以自己去看:
  测试用例的几种常见设计方法:
  已有的常规方法我们可以照搬照用,但是从质量管理的整体性来说,它仅仅是功能逻辑维度,主要参照物是产品设计文档,所以我要补充的是另外的几个维度。
  所以包含上述方法在内做个补充:
  产品逻辑维度:
  等价类,边界值,错误推测,判定表法,正交实验。
  文字逻辑维度:
  主语,谓语,宾语,定语,状语,补语为逻辑描述的基本要素。
  其中,主语,宾语通常是用户和客户端的关系,谓语可以理解为动作,定语状语为限制条件,补语为补充条件。
  首先是正常语句,其次逐级否定,最后是逐级反义。(有关这个方法本人已经用程序实现,可以自动化生成)
  UI维度
  通常由UI设计师进行检查,但是也有可能需要测试人员进行检查。人工检测包括字体,字号,色值,布局。
  写过UI自动化的都知道,UI自动化的主要原理是页面元素的的识别和命令赋予。
  所以大致我们把它分为以下几个设计方法:
  1、文本框:字符类型,空,等价类,边界值,特殊字符,编程语言关键字,sql关键字。
  字符类型的限制走的是if和else,空值走的是null的判断,等价类边界值走的也是if逻辑,特殊字符主要是考验数据库的兼容性,编程语言和sql关键字考验的是程序安全,避免报错信息出现代码片段,sql语句。
  2、复选框:数据来源,长度,数据量。
  其中需要注意上下左右是否超出页面范围,数据量考验的是响应时间和页面内存。
  3、列表:数据来源,数据量,翻页。
  这里说一下翻页,翻页主要验证的是sql是否有问题,数据是否重复,limit衔接处是否有重复。
  4、按钮:单击,双击,长按,长按移开,多点触发。
  重点说一下不符合产品设计操作的手势,比如单击按钮双击是否造成重复命令,页面重叠,请求重复(数据安全)。多点触发后是否出现重复页面和矛盾请求。这里面的形成的异常测试,最严重的后果就是产生垃圾数据。
  5、页面跳转:中断,返回。
  主要监测的是缓存是否正确,或者无效页面是否创建垃圾数据。
  6、多媒体:图片,语音,视频。正常查看,放大,音量,暂停,快进等常规性验证。
  设备维度
  1、设备按键:比如安卓手机:back键,menu键,home键。截图,录屏,旋转屏,耳机,音量,锁屏,左右滑动。电脑键盘:回车,方向page,home,end,backspace,insert,delete,printscr等是否符合用户习惯,尤其产品文档不太可能涉及这些细节时,这里应该遵循用户习惯。
  2、附件上传或下载:文件格式,下载方式。
  3、系统安全拦截:应该使用主流的杀毒软件,系统管家等对app或者网页进行检测,一方面如果确实有带着病毒或者广告的三方库或者框架,也能及时找出,避免发布上线后因为类似原因造成损失。
  4、内存管理:程序本身的运行需要占用一定的内存空间,如果涉及到本地存储,分为两个方向。第一个方向是,验证程序本身申请的内存大小的边界。第二是验证或计算设备本身的内存多久可以占满。通过程序本身或者系统管家类软件能否清理。
  5、网络:包括有线,wifi,2g,3g,4g,5g...网络下的超时表现,网络切换表现。
  6、三方服务:比如音频播放器,视频播放器,特定格式的编辑器,查看器,浏览器,多媒体输入/输出设备的兼容系。三方服务是否能够有效支撑,是否存在漏洞。如云服务,地图,聊天,输入法,各类前后端框架是否对我方程序有不合理限制。
  7、系统:系统版本,内核版本,苹果,安卓,windows,安卓定制化系统(如小米,华为,三星,OPPO,可参考市场占有率酌情选择),浏览器类型及版本(IE,谷歌,360,火狐等),兼容性测试的抽样选型,以产品要求为主,或者以用户量为主。
  接口维度
  包括调用是否正确,是否有次数限制,参数类型限制,响应时间,并发,稳定性。
  存储维度
  包含数据库,缓存服务,队列服务,搜索引擎。存储是否有字段缺失,获取是否准确。高可用,并发,稳定性。
  性能维度
  性能维度其实在上面已经涉及到了。但是这里也单独说一下。他包含客户端和服务端两个方面。客户端主要是内存上的抗压力。服务端主要是并发请求的抗压力。同时两端都需要进行稳定性测试。
  安全维度
  攻击,窃取等方式手段有多种多样。用户资料主要存储于数据库和缓存服务器,或者是搜索引擎内。测试人员会尝试输入程序的“关键字”,那么程序在exception处理上,应该避免将数据库相关的语句,微服务的名称暴露出来。抓包拦截也是主要攻击手段之一,我们的用户拿着手机东北西走,很有可能进入被监控的无线网络内,如果接口内包含用户的账号密码,电话地址等,是很有可能被拦截窃取的。所以返代理机制需要考虑增加,被监控时应予以提醒。恶意压力请求是最为常见的,我们应该在关键的地方做拦截,比如IP拦截,同一用户单位时间请求量的拦截,请求间隔时间限制。对于数据的格式的严谨性需要增强,有必要的话应该加入加密字段,避免因为用户涉及黄色,暴力,低俗,政治敏感信息牵连我方。
  另外反编译技术可以获取到源代码,所以必要的版本判断需要增强,应该在检测被篡改的客户端发来的请求,要求其更新,否则不予处理。还有一种内存监控修改的方式,来跳转到不该进入的页面或状态。
  自动化维度
  ui自动化的设计,通常以页面为类,按钮为方法,并且命名一个页面为基础页面。校验结果也是页面元素。对象化调用的设计,混合api自动化快速制作需要的数据。
  api自动化的设计,通常以后端服务为类,接口为方法。校验结果包含固定响应,特殊响应,以及混合存储查询来验证写入的正确性。
  性能测试的设计,以ui或api为基础,它的关注点是性能状态。
  监控的设计,以ui或api为基础,把较为重要的部分进行心跳式调用,一旦发现crash或者500的情况要及时的通过邮件等方式发布警报。这个心跳间隔可以是任何时长。
  代码维度
  代码逻辑不仅是遵循业务逻辑那么简单,最重要的是处理异常。例如,字符类型的转化是否完整。多个if应该每个都要跑到。exception/catch是否能补货特定异常,是否能出现其它异常。如果我们的测试执行,没有走遍每一个ifelse,每一个trycatch,那么对于程序的完整性测试就没有做到。如果函数写得很粗糙,那么就会有很多的情况它无法处理,在代码维度上,通常是很难进行测试的。为什么呢,因为专职的开发工程师,是专精一门开发语言的,而测试通常掌握的都是脚本语言,有很多比较重的开发语言是不会的,即便是会了一门两门,那么可能换了工作环境了,你会的东西就用不到了,有的仁兄就说了,我能给开发检查代码,我还干什么测试呢。所以很多时候我们需要借助框架,借助工具去实现,去告诉我们代码覆盖率,哪些地方我们没有测试到,由检测程序来告诉我们。同时作为一名优秀的测试人员,应该培养读代码的能力,重要的沟通能力,起码做到,写虽然写不出来,但是你让我看,我能看明白代码的意义,语言都是想通的,只是各有各的规范而已。
  总结
  当然,我们都知道。测试工程师也是有相应的级别划分的。测试用例的设计本质,是为了给质量保障提供有依据的参照物。而通常设计测试用例的工作,由中级及以下工程师负责。而有一些维度尽管想到了也不知道如何进行。所以通常我们会把测试用例精确到UI维度。其它维度分别规划在自动化测试设,性能测试设计,以及安全测试设计,在后三个测试设计内,其实也不能称之为通常意义的测试用例了。目前测试团队通常有两种模式,一种是以敏捷开发衍生的全站式的测试工程师,一个功能模块下的任务归一个人负责到底,这个时候就适合做一个多维度的测试用例,从头到尾做好保障。另外一种团队模式是功能测试和测试开发分离的模式,功能测试仅负责到UI层面,而其它维度交给专职的测试开发工程师进行测试。无论哪一种执行方式都应该进行全方位的质量保障,如果有缺失,就会有隐患。尤其是用户量较大的知名企业,多少黑客和工作室再盯着,甚至国外的间谍都在打你们的主意,一不留神损失的不光是企业,甚至是国家。
  后续
  对于各个维度可以展开讨论心得。而一个标准化的测试用例编写平台是必要的,因为我们不可能记住每一个测试设计方法,需要一个标准化模板去做,起码在编写用例的过程当中给予相关的提示提醒。有机会的话,我会把更多的细节记录下来分享给朋友们,同时希望朋友们多多提供业内好的东西,大家共同学习。
页: [1]
查看完整版本: 测试用例的设计方法多维进阶版