质量监控的范围和概念

　　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层面，而其它维度交给专职的测试开发工程师进行测试。无论哪一种执行方式都应该进行全方位的质量保障，如果有缺失，就会有隐患。尤其是用户量较大的知名企业，多少黑客和工作室再盯着，甚至国外的间谍都在打你们的主意，一不留神损失的不光是企业，甚至是国家。

　　后续

　　对于各个维度可以展开讨论心得。而一个标准化的测试用例编写平台是必要的，因为我们不可能记住每一个测试设计方法，需要一个标准化模板去做，起码在编写用例的过程当中给予相关的提示提醒。有机会的话，我会把更多的细节记录下来分享给朋友们，同时希望朋友们多多提供业内好的东西，大家共同学习。

作者：惯看秋月春风_6398   

来源：http://www.51testing.com/html/65/n-4476465.html