关于测试:测试的底层逻辑

作者：京东科技 孙亮

写这篇文章，是心愿把我的一些我认为是十分有价值的经验总结进去，可能帮忙刚做测试不久的新共事，或者是测试经验丰富的老同事以共享。心愿咱们可恶的新共事，筹备要在测试畛域耕耘的搭档，可能通过我的文章理解到测试的底层逻辑，也就是咱们测试工作中可能看不到暗藏较深的点，而不只是日常所见的写用例、提 bug、开发自动化、做平台；俗话说在行看热闹，外行看门道。

我认为测试人员不应该成为 PRD 的搬运工，高级测试工程师也不应该只是测试工具得开发者；

测试人员，最根本的测试基础理论肯定要把握，当然研发编码技术也必不可少；如果这两样短少一样，都无奈成为一个优良的测试人员；之前有很多测试人员都是不喜爱写代码，而后做了测试；但在将来或者当初，一个不懂代码的测试人员，很难成为一个优良的测试人员；但只懂代码，不理解测试实践根底的人（不懂得测试剖析、用例设计、测试策略的人，或者即便理解一些，但理论工作中不怎么应用的人），肯定也不是一个合格的测试人员。

上面带大家理解一些测试的底层逻辑，测试的门道。

一、优良测试人员应该具备的外围能力

依据 Testerhome《2021 年度测试行业问卷调查报告》-【优良测试人员应具备的技术 / 能力】剖析，

1、“编程 / 脚本 / 自动化、沟通表白、测试基础理论”被认为是优良测试人员的三大外围能力，持续当先其余项；

2、数据库、性能测试、平安测试、大数据算法等技术要求，从 2020 年开始大幅增长；

三大外围能力根本是大家公认的，也是稳固不变的；但新的技术要求近几年开始都有了大量需要；从剖析数据能够看到，市场对测试人员的要求会随着新技术的呈现而一直变动；但三大外围能力是测试人员的必修课，变动不会太大，会始终占据外围地位。

自从 10 几年前的 QTP 开始，自动化测试就是测试人员谋求的指标；直至今日，各种自动化技术、框架曾经目不暇接；市场对测试人员的要求也越来越高，测试人员不仅要会写自动化用例，还须要具备开发保护自动化框架平台的能力；纯黑盒的测试人员要么曾经实现了能力降级，要么在降级的路上；齐全依赖黑盒测试实现工作的曾经越来越少，如果不会编写自动化用例或不理解编程语言，预计找工作简历都很难通过。

但往往物极必反，测试人员的代码能力越来越强，测试根底能力却被忽视，测试畛域的业余能力逐渐被淡化；正如顺水行周，逆水行舟；三大外围能力应该是齐头并进，不应该顾此失彼。

这些年参加了部门很多的招聘面试，我的感触就是很多测试人员尽管工作多年，但对测试用例的设计办法、策略等把握并不好；至多有 60% 的人在用例设计中不会用什么用例设计办法，也不会思考怎么进行测试剖析和设计，他们大部分只是功能测试的执行者，测试设计方面思考很少，测试计划更是很少有人写，测试用例也只是 PRD 的拆分；总之，测试人员一不小心就会成为 PRD 的搬运工。

作为一个测试老人，还是心愿测试行业可能衰弱倒退，在新技能晋升的状况下，测试的专业性也能与时俱进，毕竟品质保障是测试人员的基本。

二、黑盒测试的底层逻辑

什么是黑盒测试？

它是把程序看作一个黑盒子，在不思考程序内部结构的状况下，检查程序性能是否依照 PRD 的规定失常应用，程序是否能适当地接管输出数据，产生正确的输入。

这，其实就是黑盒测试的定义，也是黑盒测试的底层逻辑；个别人不会器重定义，但往往就是定义会通知你真谛。

工作中有很多人在习惯了一种类型的零碎测试，而后换一个新的业务类型，突然就不知如何下手了；兴许是新的总要有一个适应的工夫；其实万变不离其宗，只有把握了黑盒测试的底层逻辑，就可能让你很快上手不再须要适应调整；

咱们大部分做的都是黑盒测试，所以无论什么类型的零碎，咱们 的测试计划都是“ 检查程序性能是否依照 PRD 的规定失常应用，程序是否能适当地接管输出数据，产生正确的输入。”。

咱们的测试根据是PRD，首先必须对 PRD 了如执掌，而后剖析他的输出有哪些，输入有哪些；这些都笼罩到了，你根本就能够做到 80 分了，也就是你拿下这个我的项目已不成问题。

最初，我还是想再啰嗦强调一下， 就怕我讲的大家还是没有看懂，因为下面讲的大家都懂，第一天理解测试，就晓得什么时候黑盒测试，什么输入输出了；然而 往往真谛就藏在平庸之间，记住他的定义！！！

当你遇到我的项目不知如何下手测试时，把定义拿进去认真读三遍，肯定会找到答案！！！

强调： 理论当中纯黑盒的其实并不多，除了理解输出、输入，两头的解决逻辑也肯定要分明，这样对测试更有帮忙；另外更重要的就是：必须熟读 PRD，必须对 PRD 里的内容分析透彻，不放过任何一段文字，一个词。其实 PRD 里和设计文档里也会有很多的破绽等你开掘。

三、黑盒测试底层逻辑详解：【输入输出测试模型】

【输出】： 这里的输出，并不是简略的界面输入框才算是输出；任何只有可能触发零碎运行的都是输出。依照代码架构分层，输出也能够做到如下分类：

1、界面操作的输出：

正向操作：

1）繁多操作：

•失常的操作：输入框、按钮、单选复选框、按钮、下拉框等的规定操作异样的操作：输入框的异样值、超长输出等、按钮的屡次点击、疾速间断点击（很容易就会发现数据反复提交，或者零碎反馈迟缓等各种问题，说不定零碎就此而奔溃）

2）简单操作：

•组合操作：个别零碎的性能都是各种操作的组合；另外一种跟业务场景相干，也就是各种业务场景同时组合进行操作。

•并行操作：多人对同一性能点的并发操作；或者多人对同一个数据进行的操作，比方两个人同时对一条单价进行批改、删除等操作。

逆向操作：

3）逆向操作：

•回退操作：通过浏览器或 APP 进行的回退操作勾销操作：失常操作忽然勾销，例如用户填写很多表格内容，忽然操作了勾销，是否须要保留或提醒呢？删除操作：通过零碎提供的性能对数据进行删除

上面的输出是最容易被疏忽的：

2、服务层的输出：

•接口服务：对外提供的接口，对于零碎来说也是很常见的一种输出，这种输出也是最容易出问题的；

•文件上传：有些零碎性能是通过获取 ftp 服务器上的 excel、xml 等文件来触发零碎运行的，所以这时候的输出就变成了文件。

•MQ 音讯：也是京东最常见的一种输出模式，MQ 里也可能会蕴含文件地址等，这种输出就更加灵便了。

强调：

•对于接口上游的输出，无论何种模式，都要剖析上游数据的每一个字段，理解上游各种输出的可能。

•有些字段还必须从业务【源头】理解这个字段的含意，可能的枚举值，可能的后果等；

•另外因为历史起因，源头的数据就可能存在各种想像不到的数据；

•对于输出的剖析十分重要，这时候你就能够应用【等价类】办法进行剖析。

3、数据层的输出：

•数据的变动：有很多后盾解决的工作就是监控是否有新数据的插入或删除等数据字段的变动：后盾解决工作监控数据状态的变动，或组合字段的变动等缓存数据的变动：除了数据库的变动，有的是缓存数据的变动工夫的变动：定时工作除了数据是输出，工夫也是他的输出。

【输入】：输入分为可见输入和不可见输入

看的见的输入： 就是咱们常见的零碎操作反馈，用户能间接看到的变动；比方弹框、提醒、跳转、数据的新增、批改、删除后的变动，图片、视频等操作后的变动等等。

看不见的输入： 看不见的输入是最容易疏忽也是最容易出问题的；【看不见的输入】包含：数据库的变动、缓存的变动、系统文件的变动、发送给上游接口的数据等

【看的见的输入】尽管可能帮咱们验证根本 90% 以上的性能，通过界面展现的数据也能验证咱们新增或批改的数据，是否新增胜利了或正确的被批改了；然而咱们看到的只是一部分；还有很多字段是没有被展现的，有的可能只是给上游或其余零碎应用的，也有可能是留给将来应用的；这些不可见的局部，常常就会引起零碎的异样，也是暗藏在零碎中最大的坑；

所以测试，除了站在用户的角度去测试零碎，还要站在设计者的角度去测试，更应该站在整个产品的角度去思考。

四、测试剖析与设计的底层逻辑

说到测试剖析与设计，我认为这个是测试人员最外围的能力；下面讲到的黑盒测试、输入输出模型，只是针对功能测试的办法，尽管个别的零碎测试中功能测试占到 80%-90% 左右，但并不是全副。而且也只是测试中的一个阶段一个类型，要想做好测试，测试剖析和设计是必不可少的。

大家能够思考一个问题：拿到一个我的项目，你如何来测试？如何保障品质？

面试中很多人给我的答案是：剖析需要，编写用例，而后执行测试，发报告；这个只是测试的流程，只是通知了咱们测试的先后顺序，但并不能领导一个测试人员如何去测试，如何去做测试剖析，更无奈保障系统的品质。

拿到一个我的项目，你如何来测试？

能够借用 5W2H 办法来剖析，其实作为测试架构师，不须要 5W 也不须要 3W，2W+1H 就够了！

因为这 2W+1H 是最重要的，也是最容易被教训代替而后就疏忽的；日常的测试工作因为产品的状态及零碎的架构根本固定，所以测试计划思路也根本固定，这样就导致拿到相似的我的项目就不再有思考，根本很快就依照教训开始干了；一旦遇到不同类型的零碎，或者遇到新的业务就不知如何下手，这时候2W1H 分析法就能够帮忙咱们解决这个问题。

测试架构师 只须要思考三个问题（2W+1H） 就够了：

1、Why？ 为什么做这个我的项目？我的项目的背景是什么？——只有晓得为什么，才晓得用户想要什么。

2、What？ 这个我的项目咱们须要测什么？咱们的测试范畴有哪些？——只有范畴明确，测试才不会脱漏。

3、How? 这个我的项目咱们怎么测？咱们应该应用哪些测试策略、测试方法？——这里通知咱们测试该当有策略有办法

测试负责人（也可能是测试架构师）还需确定的两个问题：

4、When? 我的项目冀望的实现工夫？

5、Who? 能够调用的资源有哪些？

项目经理 须要思考的另外两个问题：（测试负责人也须要思考的 2 个问题）

6、Where？是否须要集中关闭，是否须要研发测试坐到一起？

测试人员还能够思考须要在什么环境下测试？测试环境？预发环境？线上环境？windows 环境？Linux 环境？ios 环境？Android？什么浏览器？什么版本等等

7、How Much？这个我的项目老本是多少？须要多少人日？须要多少服务器资源？

测试剖析和设计的底层逻辑就是如何答复好 2W1H 这三个问题；Why 和 What 能够领导咱们进行测试剖析，理解我的项目的【背景】，确认测试的【范畴】；How 能够领导咱们去进行测试设计，依据我的项目背景及测试范畴确定测试的【策略】。

不过目前讲的还是方法论，具体的操作步骤还没有讲；因为这一部分内容比拟多，能够通过一篇文章具体来讲；大家也能够本人去理解学习一下，就是 HTSM 启发式测试策略模型，这个模型正好与 2W+1H 是绝对应的。

五、测试人员的内功修炼

作为测试人员，“沟通表白等软技能”被认为是优良测试人员的三大外围能力一，依据下面的统计数据，90% 以上的人都是认可的。上面把我之前的一些总结分享一下：

1、被动沟通

在电商畛域，特点就是疾速和变动；有些需要或我的项目，常常要求疾速上线，因为工夫短，PRD 里有些逻辑就可能会存在破绽或者基本没有思考到，面对这样的状况，咱们测试该怎么办呢？这时就须要沟通，与产品随时沟通需要，与开发随时沟通设计，与其余零碎随时沟通联调，没有沟通，我的项目里的坑很容易就会被脱漏 。沟通还必须得是主动出击，找产品、找研发、找其余条线的测试，把本人当成老板，这个我的项目的品质根本就有保障了； 把本人当成老板的员工，肯定是最让老板释怀的员工。

2、要有本人的规范

零碎测试最根本的根据就是需要规格说明书；作为测试人员，咱们是最初一道保障；测试必须有本人的剖析，不能轻易就跟着研发的思路走，因为他通知你的曾经是通过他们思考加工过的，与原始需要可能曾经存在了偏差；这也正是测试的价值所在。即便他们说的 99% 都是对的，然而也只能作为咱们剖析的一个资料；咱们必须本人通过需要去剖析。

3、对所有都要有狐疑的态度

需要是测试的根据，然而根据也有错的时候；所以对 PRD 也要有狐疑的态度。测试就是要狐疑所有； 每一个流程每一个细节；我看需要的时候第一遍根本默认他是对的，等对整体有了肯定的了解，我就开始狐疑，流程是否残缺? 是否存在破绽? 模块性能是否能满足用户的要求? 非正常操作是否会呈现问题? 用户是否会用？这个性能是否真的为客户解决了问题？等等，这些问题能够通过咱们的一些质量标准、测试策略以及测试教训去狐疑，去思考。总之，测试每一个性能都要“三思”。

4、站在公司和用户的角度思考

公司越大，部门越多，零碎就会越简单；相互依赖越多，出问题的几率也会越大；因为边界多了，沟通老本也就高了；须要沟通的点多了，只有有些细节没有沟通到位，或者都没有思考到，或者都认为是对方负责，那坑就呈现了；当然这样的坑大部分会在联调测试阶段发现，但对于测试进度影响十分大，常常会造成反工、延期等危险；

要想这些坑可能在测试阶段发现，这时候就须要有一个主测试了；但我感觉主测试不应该是一个人，所有测试人员都应该是“主测试”；作为测试人员，软件品质的最初把关者，不能只看到本人负责的这一块，不能局限于本人的部门、团队，只有对整个零碎有疑难，咱们都有责任提出来，去找人解决。测试不能只看部分，要看全局；要站在公司的地位和用户的角度去思考，去测试。

下面次要是总结了我得一些教训，测试中的一些道，有不足之处或不够全面的也心愿大家多多补充；后续还会持续分享我认为很重要的 HTSM 模型，以及我认为十分重要的等价类划分，场景测试、基因测试、摸索式测试的一些好的办法等。总之，我想把我的一些有价值的教训都分享进去以共享。