我写这篇文章是希望把自己的一些自认为非常有价值的经验总结出来，以便能够帮助到刚刚开始测试的新同事，或者是有着丰富测试经验的老同事来分享。

希望我们可爱的新同事和准备进入测试领域的小伙伴们，能够通过我的文章，了解到测试的底层逻辑，也就是我们在测试工作中可能看不到的隐藏点，而不仅仅是我们日常生活中看到的。写用例，报bug，开发自动化，搭建平台。

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

测试人员必须掌握最基本的测试理论，当然研发编码技术也是必不可少的，缺少其中之一，就不可能成为一名优秀的测试人员。

过去很多测试人员不喜欢写代码，但后来做了测试。但是，将来或者现在，一个不懂代码的测试人员很难成为一个优秀的测试人员。

但是，只懂代码，却不懂测试理论基础的人（不懂测试分析、用例设计和测试策略，或者即使知道一些，但在实际工作中用到的却不多的人）肯定不是合格的测试人员。

接下来我们来看一下测试的一些底层逻辑和技巧。

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

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

对数据库、性能测试、安全测试、大数据算法等技术要求也在逐步提高。

从10多年前QTP推出以来，自动化测试一直是测试人员追求的目标，发展到今天，自动化技术和框架种类繁多，市场对测试人员的要求也越来越高。

测试人员不仅要会写自动化测试用例，还要具备开发和维护自动化框架平台的能力。纯黑盒测试人员要么已经完成能力升级，要么正在升级的路上。越来越多的人完全依赖黑盒测试来完成工作。如果你不会写自动化用例，或者不懂编程语言，你的简历很难被录用。

然而事情往往走向极端，然后适得其反。测试人员的编码能力越来越强，但基本的测试技能却被忽视，测试领域的专业技能也逐渐被淡化。就像逆水行舟京东下拉词，不进则退。三大核心能力应该齐头并进，不能只顾一个，而顾另一个。

我这些年参加过部门的很多招聘面试，我的感受是很多测试人员虽然工作多年，但是对于测试用例的设计方法和策略并没有很好的掌握。

至少有60%的人在用例设计中没有使用任何用例设计方法，也没有思考如何进行测试分析和设计。他们大多数只是功能测试的执行者，很少考虑测试设计，更谈不上测试规划。很少有人写测试用例，测试用例只是PRD的拆分。

总之，测试人员一不小心就很容易成为PRD搬运工。

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

黑盒测试的底层逻辑

什么是黑盒测试？

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

这其实就是黑盒测试的定义，也是黑盒测试的底层逻辑，大部分人都不会关注定义，但往往定义会告诉你真相。

很多人在工作中习惯了某种类型的系统测试，然后当转换到一种新的业务类型时，突然不知道如何下手。

也许适应新事物需要时间，其实无论事物如何变化，本质都是一样的，只要掌握了黑盒测试的底层逻辑，就能快速上手，无需适应或调整。

我们所做的大部分是黑盒测试，因此不管什么类型的系统，我们的测试计划都是“检查程序功能是否按照PRD的规定正常使用，程序是否能正确接收输入数据并产生正确的输出”。

我们的考试是围绕 PRD 进行的，首先你要对 PRD 有透彻的理解，然后分析它的输入和输出，如果这些都做到了，基本上能拿到 80 分，就算拿下了，没问题。

最后还是要再强调一下，怕大家还是没明白我说的，因为我上面说的大家都明白了，学习测试的第一天，你就知道什么时候做黑盒测试，输入输出是什么。

但往往真相就隐藏在平凡之中，记住他的定义！！！

当你遇到一个项目不知道如何下手测试的时候，拿出定义，仔细读三遍，你一定会找到答案！！！

强调：现实中纯粹的黑盒子并不多，除了了解输入输出之外，中间的处理逻辑也要清楚，这样对测试更有帮助。

更重要的是，你一定要认真看完PRD，把PRD的内容分析透彻，不要漏掉任何一个段落、任何一个字，其实PRD和设计文档里会有很多漏洞等着你去挖掘。

黑盒测试底层逻辑详解

以输入输出测试为例，这里的输入不只是简单的界面输入框，任何可以触发系统运行的东西都是输入。按照代码架构分层，输入还可以分为以下几种。

界面操作输入

1. 单一操作

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

异常操作：输入框中的值异常、超长输入、多次点击按钮、快速连续点击（很容易发现数据重复提交或者系统响应缓慢等各类问题，有可能导致系统崩溃）。

2. 操作复杂

组合操作：一般来说，一个系统的功能都是各种操作的组合；另一类是与业务场景相关，即各种业务场景组合在一起，同时进行操作。

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

3. 反向操作

回滚操作：通过浏览器或者APP进行回滚操作。

取消操作：正常的操作突然取消京东下拉词，比如用户填了很多表单内容，突然取消，需要保存还是提示？

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

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

服务层输入

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

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

MQ消息：也是京东最常见的输入形式，MQ中还可能包含文件地址等，这种输入方式比较灵活。

强调：对于接口上游的输入，不管是什么形式，都要分析上游数据的每个字段，了解各种上游输入的可能性。

对于有些字段，还必须从业务[源]那里了解该字段的含义，可能的枚举值，可能的结果等。

另外，由于历史的原因，源数据中可能包含各种人们难以想象的数据。

输入的分析非常重要，此时可以用【等价类】的方法进行分析。

数据层输入

数据变化：有许多后台处理任务监视是否有新数据插入或删除。

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

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

时间的变化：除了数据之外，时间也是计划任务的输入。

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

虽然可见的输出能帮我们验证90%以上的功能，但界面展示的数据也能验证我们添加或修改的数据是否添加成功或修改正确。这只是一部分，还有很多字段没有展示出来，有的可能只是下游或其他系统用到，也有可能是留着以后用，这些不可见的部分往往会导致系统异常，也是隐藏在系统中最大的陷阱。

所以，我们除了要站在用户的角度去测试系统之外，还要站在设计师的角度去测试，要站在整个产品的角度去思考。

测试分析与设计的底层逻辑

说到测试分析与设计，我觉得这是一个测试人员最核心的能力。

上面提到的黑盒测试和输入输出模型只是功能测试的方法，虽然功能测试在一般的系统测试中占比大约80%-90%，但并不是全部。

而且测试只是测试的一个阶段和一种类型，要做好测试，测试分析与设计必不可少。

你可以思考一下这个问题：当你接到一个项目的时候，你如何测试它？你如何保证质量？

面试的时候很多人给我的答案都是：分析需求，写用例，然后执行测试，出报告。

这只是一个测试流程，它只告诉我们测试的顺序下拉神器登录★64xl.com下拉技术霸屏，搜索次数多就会生成推荐词吗，但是它不能指导测试人员如何去测试，如何做测试分析，也不能保证系统的质量。

当你接到一个项目时，你如何测试它？

可以用5W2H的方法进行分析，其实作为测试架构师，不需要5W或者3W，2W+1H就够了！

因为这2W+1H是最重要的，也是最容易被经验所取代而后被忽略的。

在日常的测试工作中，由于产品形态、系统架构基本固定，测试方案思路也基本固定，这就导致接到类似项目时不用再多想，基本都是凭经验快速上手。

一旦遇到不同类型的系统或者新的业务，我们就不知道从何下手了，这时候2W1H分析法就可以帮助我们解决这个问题。

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

1.为什么要做这个项目？项目的背景是什么？知道为什么，才能知道用户想要什么。

2.这个项目我们需要测试什么？我们的测试范围是什么？只有范围明确了，测试才不会漏掉。

3.我们如何测试这个项目？我们应该采用什么样的测试策略和方法？ ——这里告诉我们测试要有策略和方法。

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

4. 该项目预计什么时候完工？

5. 世卫组织可以利用哪些资源？

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

6. 是否需要集中收尾？研发和测试团队需要坐在一起吗？

测试人员也可以想想自己需要在什么环境下测试？测试环境？预发布环境？线上环境？环境？环境？iOS环境？什么浏览器？什么版本等等……

7. 这个项目要花多少钱？需要多少人天？需要多少服务器资源？

测试分析与设计的底层逻辑是如何回答好问题？

2W1H三个问题：

不过现在讲的是方法论，具体的操作步骤还没讲清楚，大家可以自己去了解一下，就是HTSM启发式测试策略模型，这个模型正好对应2W+1H。

测试人员内部培训

作为测试人员，“沟通、表达等软技能”被认为是优秀测试人员的三大核心能力之一。根据上述统计，有超过90%的人认同这一点。以下是我之前的一些总结：

主动沟通

电商领域的特点就是速度和变化，一些需求或者项目往往需要快速上线，由于时间仓促，PRD中的一些逻辑可能会有漏洞或者根本没考虑到。面对这样的情况，我们该如何测试？该怎么办？

这时候就需要沟通了，随时跟产品沟通需求，随时跟开发沟通设计，随时跟其他系统沟通联调，没有沟通，项目中的坑就很容易被忽略。

沟通也必须积极主动，找其他领域的产品、研发、测试，把自己当成老板，项目的质量基本上就能保证。

把自己当老板的员工，肯定是老板最能信任的员工。

有自己的标准

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

测试一定要有自己的分析，不能轻易的去跟着研发的思路走，因为他们告诉你的东西他们已经思考过、处理过，可能跟原来的需求会有偏差，这也正是测试的价值所在。

即使他们说的99%都是对的，也只能作为我们分析的素材，要我们自己根据自己的需要去分析。

对一切持怀疑态度

需求是测试的依据，但是有时候依据是错误的，所以我们也应该对PRD持怀疑态度。

测试就是怀疑一切，怀疑每一个流程，怀疑每一个细节。当我看到需求的时候，基本第一次就认定它是正确的。等我对整体有了一定的了解之后，就开始怀疑流程是否完备，是否有漏洞。模块功能是否能满足用户的要求，是否会因为操作不正常而出现问题，用户是否会用，这个功能是否真的为客户解决了问题等等。

我们可以通过质量标准、测试策略和测试经验来质疑和考虑这些问题。

简而言之，测试每个功能之前请三思。

从公司和用户的角度思考

公司越大，部门越多，系统就越复杂，相互依赖性就越强，出现问题的可能性就越大。

因为界限多了，沟通的成本也就高了，需要沟通的点也多了，只要有些细节没沟通好，或者没考虑到，或者双方都认为对方有责任，那么陷阱就会产生。

当然，这些缺陷大部分会在联调测试阶段被发现，但它们对测试进度的影响巨大，常常造成返工、延误等风险。

为了在测试阶段发现这些缺陷，需要一名主测试员。但是，我认为主测试员不应该是一个人。所有测试人员都应该是“主测试员”。

作为测试人员，作为软件质量的最终把关人，我们不能只关注自己负责的部分，也不能局限于自己的部门或团队，只要是整个系统的问题，我们都有责任提出来，找人解决。

测试不能只注重细节，更要注重大局，要站在企业和用户的角度去思考和测试。

以上主要总结了我的一些经验和测试中的一些疑问，如有不足或者不完整的地方希望大家补充。

结尾

关联：

本文经授权转载，转载文章所含文字来自作者，如内容或版权有问题，请联系我们删除