|
|
# 测试专栏特别放送 | 答疑解惑第七期
|
|
|
|
|
|
你好，我是茹炳晟。
|
|
|
|
|
|
今天的“答疑解惑”系列文章，我们一起来解决测试新技术、测试人员的互联网架构核心知识这最后两个系列相关的问题。
|
|
|
|
|
|
这期的答疑文章，我不会针对每篇文章后面的思考题展开，而是会选择了四个大家比较关注的问题，和你分享我的观点。如果你的看法不同，或者你还有哪些其他问题的话，欢迎你在这篇文章下面给我留言，我会持续不断地解答你的问题。
|
|
|
|
|
|
当然了，我还是会先用一句话简单概括下每篇文章的内容，并给出对应的链接，方便你复习。
|
|
|
|
|
|
## 测试新技术系列文章回顾
|
|
|
|
|
|
**在专栏的第43篇文章[《发挥人的潜能：探索式测试》](https://time.geekbang.org/column/article/41203)中**，我和你阐述了这样一个基本思想：探索式测试是一种软件测试风格，而不是一种具体的软件测试技术。
|
|
|
|
|
|
作为一种思维方法，探索式测试强调依据当前语境与上下文选择最适合的测试技术，并强调独立测试工程师的个人自由和责任，其目的是为了持续优化其工作的价值。
|
|
|
|
|
|
看到有用户在留言中说到想在实际项目中开展探索式测试，这里我想再给个建议：
|
|
|
|
|
|
高效开展探索式测试的前提是，对被测系统的设计以及行业应用有非常清晰的认识，同时在此基础上以发散的方式对系统可能存在的缺陷进行探索。所以，这就要求测试人员不仅要具有很深的业务领域知识，还需要很强的逻辑推理和分析能力。而这样的人才，属于比较稀缺的。
|
|
|
|
|
|
另外，探索式测试不要到了项目后期再集中展开，而是应该在各个模块级别就尽可能多地去探索，尽量在测试早期就能发现问题。
|
|
|
|
|
|
需要注意的是，一定不要在执行层面，将探索式测试变成了随机测试，你设计的所有后续测试步骤都必须是在你之前的步骤上推演出来的。而且，在执行探索性测试的过程中，你需要明确每个操作的目的是什么，是想证实自己的推论还是要推翻自己的假设。对此，你一定要做到心中有数，否则很容易就会变成无明确目的随机测试。
|
|
|
|
|
|
而从管理层的角度来看，千万不要以探索式测试发现的缺陷数量来考核团队的绩效。因为这样不仅不能提升测试效率，反而会把大量的时间浪费在一些非核心功能的测试上。
|
|
|
|
|
|
**在专栏的第44篇文章[《测试先行：测试驱动开发（TDD）》](https://time.geekbang.org/column/article/41238)中**，我和你分享了TDD的核心思想是：在开发人员实现功能代码前，先设计好测试用例，编写测试代码，然后再针对新增的测试代码来编写产品的功能代码，最终目的是让新增的测试代码能够通过。
|
|
|
|
|
|
正如“叶夏立”在留言中所说，TDD如何落地才是最核心的问题。所以，我会将这个问题，作为今天这篇文章要回答的第一个问题，和你分享些我的经验。
|
|
|
|
|
|
**在专栏的第45篇文章[《打蛇打七寸：精准测试》](https://time.geekbang.org/column/article/41368)中**，我通过分析传统软件测试的短板，和你分享了精准测试的概念、必要性、核心思想，以及具体的测试方法。
|
|
|
|
|
|
因为这种测试理念，国内外成功落地的案例非常少，而这个理论也是由星云测试公司提出的，所以我借鉴了《星云精准测试白皮书》中的内容，并从我的视角为你解读了其中的部分内容。如果其中有哪些不清楚的问题，我们可以一起探讨，共同进步。
|
|
|
|
|
|
**在专栏的第46篇文章[《安全第一：渗透测试》](https://time.geekbang.org/column/article/41608)中**，我分享了渗透测试是由专业的安全专家来模拟黑客对系统发起攻击，找到并修复系统的安全漏洞，从而让真正的黑客无机可乘。在这其中，我和你详细分享了渗透测试的知识点，包括常用的测试方法、步骤、工具。
|
|
|
|
|
|
这篇文章更新后，有的用户反馈希望看到实例的演示，这样可以更生动、易于理解，所以这里我决定在今天的第二个问题中，和你分享一个实际的渗透测试实例，满足你的需求。
|
|
|
|
|
|
**在专栏的第47篇文章[《用机器设计测试用例：基于模型的测试》](https://time.geekbang.org/column/article/41781)中**，我分享了基于模型的测试（MBT）是一种基于被测系统的模型，由工具自动生成测试用例的软件测试技术。这也就决定了，相对于传统软件测试技术来说有优优劣。
|
|
|
|
|
|
所以，我们需要综合考虑项目本身的特点和人员的技术水平，以此决定是否有必要开展MBT。关于如何判断你的项目是否适合开展MBT，我决定作为今天的第三个问题，和你展开分享。
|
|
|
|
|
|
## 测试人员的互联网架构核心知识系列文章回顾
|
|
|
|
|
|
**在48篇文章[《优秀的测试工程师为什么要懂大型网站的架构设计？》](https://time.geekbang.org/column/article/42373)中**，我主要和你分享了测试人员学习网站架构知识的why、what、how的问题，并提出了“由广度到深度”和“自上而下”的架构学习思路，希望可以增强你学习网站架构的信心。
|
|
|
|
|
|
**在第49篇文章[《深入浅出网站高性能架构设计》](https://time.geekbang.org/column/article/42569)中**，我从测试人员的视角，和你分享了网站的高性能架构设计包括哪些部分，以及在设计测试用例时，需要着重考虑哪些点。而设计到具体的测试方法、工具问题，你可以再回顾一下第28~34篇文章（也就是性能测试系列文章）中的相关内容。
|
|
|
|
|
|
**在第50篇文章[《深入浅出网站高可用架构设计》](https://time.geekbang.org/column/article/42509)中**，我将影响网站高可用的因素归为了三类（即：服务器硬件故障、新应用的发布、应用程序本身的问题），并相应地给出了解决这三类问题的方案。希望这些内容可以帮到你。
|
|
|
|
|
|
**在第51篇文章[《深入浅出网站伸缩性架构设计》](https://time.geekbang.org/column/article/42894)中**，我和你分享了一个网站的可伸缩性架构设计主要包含的两个层面。其中，一个是指根据功能进行物理分离来实现伸缩，另一个是指物理分离后的单一功能通过增加或者减少硬件来实现伸缩。
|
|
|
|
|
|
**在第52篇文章[《深入浅出网站可扩展性架构设计》](https://time.geekbang.org/column/article/44185)中**，我和你分享了本专栏的最后一个主题，即网站的可扩展性架构设计。从已有的实现方案来看，实现网站可扩展性架构的主要技术手段包括事件驱动架构和微服务架构。
|
|
|
|
|
|
而在微服务的实现方案中，需要测试人员关注的点，你可以参考第24篇文章[《紧跟时代步伐：微服务模式下API测试要怎么做？》](https://time.geekbang.org/column/article/13581)中的相关内容。所以，在这篇文章中，我和你重点分享的是事件驱动架构实现的大致原理，以及测试人员需要额外关注的点。
|
|
|
|
|
|
因为这个系列的文章，更新日期比较近，所以很多用户还没来得及看。所以，我就没有在这篇答疑文章中，设置与这个系列有关的问题。如果你阅读完这个系列的文章，有任何困惑，都可以给我留言，我将和你一起讨论、解决。
|
|
|
|
|
|
## 问题一：什么样的项目适合TDD？TDD如何才能落地？
|
|
|
|
|
|
的确，TDD这个概念从提出来到现在已经有很长时间了，但实际落地的项目并不多，甚至可以说少之又少。造成TDD落地困难的原因有很多，比如很多大型项目本身就不适合做TDD，TDD初期阶段的工作划分以及粒度控制都是难点。但我认为最重要的原因是，TDD需要大幅改变研发团队的流程规范。这种改变在公司层面，尤其是中大型公司是很难实际执行的。
|
|
|
|
|
|
虽然明知落地TDD困难重重，但是你又特别想在自己的项目中尝试TDD，以解决现在的测试方法不能解决的问题。那么，落地TDD有哪些可值得借鉴的经验呢？这也正是很多用户关心的，比如昵称为“叶夏立”的用户在文章下面的留言。
|
|
|
|
|
|
|
|
|
这里，我根据自己的时间，为你总结了如下几点：
|
|
|
|
|
|
* 只在一些小型项目，比如前期的POC项目中，尝试开展TDD；
|
|
|
* 一定要借助Cucumber之类的TDD或者BDD工具，来协助TDD的开展；
|
|
|
* 必须把控好每个测试用例的粒度，不能太大，也不能太小，需要与开发函数以及功能的粒度相匹配；
|
|
|
* 项目管理的流程必须去适应TDD的实践，原本管理的是需求，现在管理的可能是测试用例了，因为用例本身就是对需求的解读；
|
|
|
* 测试人员必须要有开发背景，否则TDD只能是空谈；
|
|
|
* 必须要得到管理层的大力支持，最好是能自顶向下的推广。
|
|
|
|
|
|
## 问题二：渗透测试在落地的时候，需要注意哪些问题？
|
|
|
|
|
|
首先说一下，我设立这个问题的初衷，是想通过一个实际的例子，来帮助你理解渗透测试的本质。
|
|
|
|
|
|
所以，我以最常见的SQL注入攻击为例，和你简单分享下渗透测试落地时需要主要的问题。假设，我现在要测试用户登录功能，用户登录时会在界面上分别输入用户名（userName）和密码（passWord），然后程序代码会将输入的userName和passWord填充到下面SQL语句中。
|
|
|
|
|
|
```
|
|
|
SELECT * FROM users WHERE (name = '" + userName + "') and (pw = '"+ passWord +"');"
|
|
|
|
|
|
```
|
|
|
|
|
|
假设，我们输入的用户名是“Robin”，密码是“12345678”。那么，此时的SQL语句如下所示：
|
|
|
|
|
|
```
|
|
|
SELECT * FROM users WHERE (name = 'Robin') and (pw = '12345678');"
|
|
|
|
|
|
```
|
|
|
|
|
|
然后，系统就会使用这个SQL语句去数据库中查询是否存在该用户，以及该用户的密码是否正确。
|
|
|
|
|
|
此时，如果你是黑客希望通过渗透来非法获取系统信息，你就会尝试设计以下的用户名和密码：
|
|
|
|
|
|
```
|
|
|
username 输入 "1' OR '1'='1";
|
|
|
password 输入 "1' OR '1'='1";
|
|
|
|
|
|
```
|
|
|
|
|
|
这种情况下，用于数据库查询的SQL语句就会变成如下所示的样子，就是将userName和password的部分用 "1’ OR ‘1’='1"都代替：
|
|
|
|
|
|
```
|
|
|
SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');"
|
|
|
|
|
|
```
|
|
|
|
|
|
如果你熟悉SQL语句的语法，你就会发现黑客查询数据库使用的SQL语句，其实和下面这个SQL语句是等价的：
|
|
|
|
|
|
```
|
|
|
SELECT * FROM users;
|
|
|
|
|
|
```
|
|
|
|
|
|
也就是说，原本用于查询单条用户信息的SQL语句已经被黑客改造成了获取全部用户信息的SQL语句。这，就是最典型的SQL注入攻击手段了。
|
|
|
|
|
|
而我们所讲的渗透测试，就是会去人为模拟这种攻击，以判断系统是否能够成功应对此类攻击。
|
|
|
|
|
|
## 问题三：如何判断你的项目是否适合采用MBT，以及你认为会遇到哪些问题可能会阻碍MBT的开展呢？
|
|
|
|
|
|
一般来讲，只要系统的设计可以用状态转移图来描述的话，基本都可以采用MBT。另外，基于GUI的系统，因为本身就可以画出页面之间相互跳转的关系图，所以也适合采用MBT。
|
|
|
|
|
|
很可惜，eBay内部的项目除了一些实验性的尝试，并没有大规模开展MBT。但据我所知，业界最近有一家初创企业AutoTest正在全力推进MBT的落地和应用，而且还发表了很多[相关文章](https://mp.weixin.qq.com/s/6RwTJlf7uEquCadMp1jnbw)，如果你对此感兴趣可以去关注一下。
|
|
|
|
|
|
在我看来，阻碍MBT落地的最关键问题，有两个：
|
|
|
|
|
|
* 一个是，探索路径的有效性问题。早期的实施方案，完全基于图论来覆盖可能路径，造成了大量的非法或者不合理的路径。但是，近几年来由于人工智能的介入，大大提升了路径探索的有效性。
|
|
|
* 另一个是，如果只是用MBT完成单纯测试的话，收益比会比较低。只有将MBT和自动化测试结合在一起，才能发挥MBT的优势。在这方面，eBay一直在尝试，试图将Selenium和MBT集成到一起，目前已经有了初步成果，实现了用模型导出实际可以执行的自动化测试用例的POC。
|
|
|
|
|
|
## 问题四：测试工程师如何应对面试？
|
|
|
|
|
|
首先，我并不鼓励为了应对面试，而去做特别的准备，你还是应该在平常的工作中多积累。**面试的过程，本来就是尽可能地反映你真实的技术水平以及业务熟练程度的交流，关注的重点应该是如何将你自己掌握的技术和知识更好地展现出来，而不是把你不懂的知识包装成你已经“懂”的知识**。为此，我有如下几点小建议供你参考：
|
|
|
|
|
|
* 当被问及相关测试工具的时候，除非问到了该工具使用上的细节，否则尽可能避免谈及工具使用的细节，而是应该更多地阐述工具本身的原理、和同类工具相比的优劣势，以及这个工具可以以什么样的方式帮你解决问题。这时，你的视野一定要高，不能局限于细节。当然，这也就要求你能够充分理解这个工具的原理和使用方法。
|
|
|
* 当被问及特定算法实现的时候，刚开始的时候，一定不要试图去寻求最优解法，而是要考虑最基本的实现，然后在此基础上迭代优化。因为，优秀的面试官希望看到的不是最优解，而是你解决问题的过程，以及在这个迭代过程中的逻辑推理。
|
|
|
* 当被问及你所不熟悉的测试技术时，如实回答就好，不要试图去掩饰。很多时候面试官看重的并不是你知不知道，而是当你不知道的时候你会怎么做。
|
|
|
|
|
|
最后，感谢你能认真阅读第43~52这10篇文章的内容，并写下了你的想法和问题。期待你能继续关注我的专栏，继续留下你对文章内容的思考，我也在一直关注着你的留言、你的学习情况。
|
|
|
|
|
|
咱们的答疑环节暂告一段落了，但这并不意味着结束。如果你在学习过程中遇到了什么问题，还可以继续给我留言，我会持续不断地回答你的问题。
|
|
|
|