写这篇文章，是希望把我的一些我认为是非常有价值的经验总结出来，能够帮助刚做测试不久的新同事，或者是测试经验丰富的老同事以共享。

希望我们可爱的新同事，准备要在测试领域耕耘的伙伴，能够通过我的文章了解到测试的底层逻辑，也就是我们测试工作中可能看不到隐藏较深的点，而不只是日常所见的写用例、提bug、开发自动化、做平台。

俗话说外行看热闹，内行看门道。我认为测试人员不应该成为PRD的搬运工，高级测试工程师也不应该只是测试工具的开发者。

测试人员，最基本的测试基础理论一定要掌握，当然研发编码技术也必不可少。如果这两样缺少一样，都无法成为一个优秀的测试人员。

之前有很多测试人员都是不喜欢写代码，然后做了测试，但在未来或者现在，一个不懂代码的测试人员，很难成为一个优秀的测试人员。

但只懂代码，不了解测试理论基础的人（不懂得测试分析、用例设计、测试策略的人，或者即使了解一些 ，但实际工作中不怎么使用的人），一定也不是一个合格的测试人员。

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

优秀测试人员应该具备的核心能力

根据网络上的数据分析：编程/脚本/自动化、沟通表达、测试基础理论”被认为是优秀测试人员的三大核心能力。

对数据库、性能测试、安全测试、大数据算法等技术要求也逐渐增多。

自从10几年前的QTP开始，自动化测试就是测试人员追求的目标，直至今日，各种自动化技术、框架已经琳琅满目，市场对测试人员的要求也越来越高。

测试人员不仅要会写自动化用例，还需要具备开发维护自动化框架平台的能力，纯黑盒的测试人员要么已经完成了能力升级，要么在升级的路上，完全依赖黑盒测试完成工作的已经越来越少，如果不会编写自动化用例或不了解编程语言，估计找工作简历都很难通过。

但往往物极必反，测试人员的代码能力越来越强，测试基础能力却被忽视，测试领域的专业能力逐步被淡化，正如逆逆水行舟，不进则退，三大核心能力应该是齐头并进，不应该顾此失彼。

这些年参与了部门很多的招聘面试，我的感受就是很多测试人员虽然工作多年，但对测试用例的设计方法、策略等掌握并不好。

至少有60%的人在用例设计中不会用什么用例设计方法，也不会思考怎么进行测试分析和设计，他们大部分只是功能测试的执行者，测试设计方面思考很少，测试计划更是很少有人写，测试用例也只是PRD的拆分。

总之，测试人员一不小心就会成为PRD的搬运工。

作为一个测试老人，还是希望测试行业能够健康发展，在新技能提升的情况下，测试的专业性也能与时俱进，毕竟质量保障是测试人员的根本。

黑盒测试的底层逻辑

什么是黑盒测试？

它是把程序看作一个黑盒子，在不考虑程序内部结构的情况下，检查程序功能是否按照PRD的规定正常使用，程序是否能适当地接收输入数据，产生正确的输出。

这其实就是黑盒测试的定义，也是黑盒测试的底层逻辑。一般人不会重视定义，但往往就是定义会告诉你真理。

工作中有很多人在习惯了一种类型的系统测试，然后换一个新的业务类型，忽然就不知如何下手了。

也许是新的总要有一个适应的时间，其实万变不离其宗，只要掌握了黑盒测试的底层逻辑，就能够让你很快上手不再需要适应调整。

我们大部分做的都是黑盒测试，所以无论什么类型的系统，我们的测试方案都是“ 检查程序功能是否按照PRD的规定正常使用，程序是否能适当地接收输入数据，产生正确的输出。” 。

我们的测试依据是PRD，首先必须对PRD了如执掌，然后分析他的输入有哪些，输出有哪些，这些都覆盖到了，你基本就可以做到80分了，也就是你拿下这个项目已不成问题。

最后，我还是想再啰嗦强调一下， 就怕我讲的大家还是没有看懂，因为上面讲的大家都懂，第一天了解测试，就知道什么时候黑盒测试，什么输入输出了。

但是往往真理就藏在平凡之间，记住他的定义！！！

当你遇到项目不知如何下手测试时，把定义拿出来认真读三遍，一定会找到答案！！！

强调：实际当中纯黑盒的其实并不多，除了了解输入、输出，中间的处理逻辑也一定要清楚，这样对测试更有帮助。

另外更重要的就是：必须熟读PRD，必须对PRD里的内容分析透彻，不放过任何一段文字，一个词。其实PRD里和设计文档里也会有很多的漏洞等你挖掘。

黑盒测试底层逻辑详解

以输入输出测试为模型。这里的输入，并不是简单的界面输入框才算是输入，任何只要能够触发系统运行的都是输入。按照代码架构分层，输入也可以做到如下分类。

界面操作的输入

• 正向操作：

1、单一操作

正常的操作：输入框、按钮、单选复选框、按钮、下拉框等的规定操作。

异常的操作：输入框的异常值、超长输入等、按钮的多次点击、快速连续点击（很容易就会发现数据重复提交，或者系统反应缓慢等各种问题，说不定系统就此而奔溃）。

2、复杂操作

组合操作：一般系统的功能都是各种操作的组合；另外一种跟业务场景相关，也就是各种业务场景同时组合进行操作。

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

• 逆向操作：

3、逆向操作

回退操作：通过浏览器或APP进行的回退操作。

取消操作：正常操作突然取消，例如用户填写很多表格内容，突然操作了取消，是否需要保存或提示呢？

删除操作：通过系统提供的功能对数据进行删除。

下面的输入是最容易被忽略的。

服务层的输入

接口服务：对外提供的接口，对于系统来说也是很常见的一种输入，这种输入也是最容易出问题的。

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

MQ消息：也是京东最常见的一种输入形式，MQ里也可能会包含文件地址等，这种输入就更加灵活了。

强调：对于接口上游的输入，无论何种形式，都要分析上游数据的每一个字段，了解上游各种输入的可能。

有些字段还必须从业务【源头】了解这个字段的含义、可能的枚举值、可能的结果等。

另外由于历史原因，源头的数据就可能存在各种想像不到的数据。

对于输入的分析非常重要，这时候你就可以使用【等价类】方法进行分析。

数据层的输入

数据的变化：有很多后台处理的任务就是监控是否有新数据的插入或删除等。

数据字段的变化：后台处理任务监控数据状态的变化，或组合字段的变化等。

缓存数据的变化：除了数据库的变化，有的是缓存数据的变化。

时间的变化：定时任务除了数据是输入，时间也是他的输入。

输出分为可见输出和不可见输出：

• 看得见的输出：就是我们常见的系统操作反馈，用户能直接看到的变化。比如弹框、提示、跳转、数据的新增、修改、删除后的变化，图片、视频等操作后的变化等等。

• 看不见的输出：看不见的输出是最容易忽略也是最容易出问题的。包括：数据库的变化、缓存的变化、系统文件的变化、发送给下游接口的数据等。

看得见的输出虽然能够帮我们验证基本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%以上的人都是认可的。下面把我之前的一些总结分享一下：

主动沟通

在电商领域，特点就是快速和变化；有些需求或项目，经常要求快速上线，由于时间短，PRD里有些逻辑就可能会存在漏洞或者根本没有考虑到，面对这样的情况，我们测试该怎么办呢？

这时就需要沟通，与产品随时沟通需求，与开发随时沟通设计，与其他系统随时沟通联调，没有沟通，项目里的坑很容易就会被遗漏。

沟通还必需得是主动出击，找产品、找研发、找其他条线的测试，把自己当成老板，这个项目的质量基本就有保障了。

把自己当成老板的员工，一定是最让老板放心的员工。

要有自己的标准

系统测试最基本的依据就是需求规格说明书，作为测试人员，我们是最后一道保障。

测试必须有自己的分析，不能轻易就跟着研发的思路走，因为他告诉你的已经是经过他们思考加工过的，与原始需求可能已经存在了偏差，这也正是测试的价值所在。

即使他们说的99%都是对的，但是也只能作为我们分析的一个材料，我们必须自己通过需求去分析。

对一切都要有怀疑的态度

需求是测试的依据，但是依据也有错的时候，所以对PRD也要有怀疑的态度。

测试就是要怀疑一切，每一个流程每一个细节，我看需求的时候第一遍基本默认他是对的，等对整体有了一定的理解，我就开始怀疑：流程是否完整，是否存在漏洞，模块功能是否能满足用户的要求，非正常操作是否会出现问题，用户是否会用，这个功能是否真的为客户解决了问题等等。

这些问题可以通过我们的一些质量标准、测试策略以及测试经验去怀疑、去思考。

总之，测试每一个功能都要“三思”。

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

公司越大，部门越多，系统就会越复杂，相互依赖越多，出问题的几率也会越大。

因为边界多了，沟通成本也就高了，需要沟通的点多了，只要有些细节没有沟通到位，或者都没有考虑到，或者都认为是对方负责，那坑就出现了。

当然这样的坑大部分会在联调测试阶段发现，但对于测试进度影响非常大，经常会造成反工、延期等风险。

要想这些坑能够在测试阶段发现，这时候就需要有一个主测试了，但我觉得主测试不应该是一个人，所有测试人员都应该是“主测试”。

作为测试人员，软件质量的最后把关者，不能只看到自己负责的这一块，不能局限于自己的部门、团队，只要对整个系统有疑问，我们都有责任提出来，去找人解决。

测试不能只看局部，要看全局，要站在公司的位置和用户的角度去思考，去测试。

上面主要是总结了我得一些经验，测试中的一些道，有不足之处或不够全面的也希望大家多多补充。

End

 

链接：https://juejin.cn/post/7211315741903585336 本文转载文章所包含的文字来源于作者。如因内容或版权等问题，请联系进行删除