☆测试

    一个好的测试人员会在着手测试之前，先准确了解自己要测试的是什么。

 

测试问题一般分为以下四类：

（1）测试现实生活中的事物（比如一支笔）；

（2）测试一套软件；

（3）编写代码测试一个函数；

（4）调试解决已知问题。针对每一类题型，我们都会给出相应的解法。

请记住，处理这四类问题时，切勿假设使用者会好好地正常操作。请做好应对用户误用乱用软件的准备。

1.      面试官想考擦什么

表面上看，测试问题主要考察你能否想到周全完备的测试用例。这在某种程度上也是对的，求职者确实需要想出一系列合理的测试用例。

但除此之外，面试官还想考察以下几个方面。

• 全局观：你是否真的了解软件是怎么回事？你能否正确区分测试用例的优先顺序？比如说，假设你被问到该如何测试像亚马逊这样的电子商务系统。若能确保产品图片显示位置正确，当然也不错，但最重要的还是确保支付流程万无一失，货品能顺利地进入发货流程，并且顾客绝对不能被重复扣款。

• 懂整合：你是否了解软件的工作原理？该如何将它们整合成更大的软件生态系统？假设要测试谷歌电子表格，你自然会想到测试文档的打开储存及编辑功能。但是，实际上，谷歌电子表格也是大型软件生态系统的重要组成部分之一。所以，你还需将它与Gmail、各种插件和其它模块整合在一起进行测试。

• 会组织：你能否有条理地处理问题？还是处理问题时毫无条理？被要求提出照相机的测试用例时，有些求职者只会一股脑儿倒出一些杂乱无章的想法。而优秀的求职者却能将测试功能分为几类，比如拍照、照片管理、设置，等等。在创建测试用例是，这种结构化处理方法还有助于你将公司操作落实。

• 可操作：你制定的测试计划是否合理，行之有效？比如，如有用户报告，软件会在打开某种图片时崩溃，而你却只是要求他们他们重新安装软件，这显然太不实际了。你的测试计划必须切实可行，便于公司操作落实。

倘若能在面试中充分展现这些方面，那么，你无疑就是任何测试团队所梦寐以求的重要

一员。

2.      测试现实生活中的事物

问及该如何测试一支笔时，有些求职者会感到莫名惊诧。毕竟，你要测试的不是软件吗？

没错，但这些关于“现实生活”的问题其实很常见。我们先来看看下面这个例子吧！

比如有这么一个问题：如何测试一枚回形针？

l 步骤1：使用者是哪些人？做什么用？

你需要跟面试官讨论一下，谁会使用这个产品，做什么用。回答可能出乎你的意料，比

如，回答可能是“老师，把纸张夹在一起”或“艺术家，为了弯成动物造型”。又或者，两者皆要考虑。这个问题的答案，将影响你怎么处理后续问题。

l 步骤2：有哪些用例？

列出回形针的一系列用例，这对解决问题很有帮助。在这个例子中，用例可能是，将纸

张固定在一起，且不得破坏纸张。

若是其它问题，可能会有多个用例。比如，某产品要能够发送和接收内容，或擦写和删

除功能，等等。

l 步骤3：有哪些使用限制？

使用限制可能是，回形针一次可以夹最多30张纸，且不会造成永久性损害（比如弯掉），

另外，可以夹30到50张纸时，只不过会发生轻微变形。

同时，使用限制也要考虑环境因素。比如，回形针可否非常温暖的环境下（33~43摄氏

度）使用？在极寒环境下呢？

l 步骤4：压力与失效情况下的状态如何？

没有产品是万无一失的，所以，在测试中，还必须分析失效情况。跟面试官探讨时，最

好问一下在什么情况下产品失效是可接受的（甚至是必要的），以及什么样才算是失效的。

        举个例子，要你测试一台洗衣机，你可能会认为洗衣机至少要能洗30件T恤衫或裤子。一次放进30到45件衣服，可能会导致轻微失效，因为衣物洗得不够干净。若超过45件衣物，出现极端失效或许可以接受。不过，这里所谓的极端失效，应该是指洗衣机根本不该进水，绝对不应该让水溢出来或引发火灾。

l 步骤5：如何执行测试？

有些情况下，讨论执行测试的细节可能很重要。比如，若要确保一把椅子能正常使用5

年，你恐怕不会把它放在家里，等上5年来看结果。相反，你需要定义何谓“正常”使用情况（每年会在椅子上坐多少次？扶手呢？）。然后，除了做一些手动测试，你可能还会想到找台机器，自动执行某些功能测试。

3.      测试一套软件

测试软件与测试现实生活中的事物非常相似。主要差异在于，软件测试往往更强调执行

测试的细节。

        请注意，软件测试主要有如下两个方面。

• • 手动测试与自动化测试：理想情况下，我们当然希望能够自动化所有的测试工作，不过这不太现实。有效东西还是手动测试来的更好，因为某些功能对计算机而言过于定性，计算机很难有效地检查（比如，内容带有淫秽色情成分）。此外，计算机只能机械地识别明确告知的情况，而人类就不一样了，通过观察可能发现亟待验证的新问题。因此，在测试过程中，无论是人工还是计算机，两者都不可或缺。

  • 黑盒测试与白盒测试：两者的区别反映了我们对软件内部机制的掌控程度。在黑盒测试中，我们只关心软件的表象，并且仅测试其功能。而在白盒测试中，我们会了解程序的内部机制，还可以分别对每一个函数单独进行测试。我们也可以自动执行部分黑盒测试，只不过难度要大得多。

        下面介绍一种测试方法，并从头到尾细述一遍。

l 步骤1：要做黑盒测试还是白盒测试？

尽管通常我们会拖到测试后期才考虑这个问题，但我喜欢早点做出选择。不妨根面试官

确认一下，要做黑盒测试还是白盒测试——或是两者都要。

l 步骤2：使用者是哪些人？做什么用？

一般来说，软件都会有一个或多个目标用户，设计各个功能时，就会考虑用户需求。比

如，若要你测试一款家长用来监控网页浏览器的软件，那么，你的目标用户既包括家长（实施监控过滤哪些网站），又包括孩子（有些网站被过滤了）。用户也可能包括“访客”（也就是既不实施也不受监控的使用者）。

l 步骤3：有哪些用例？

在监控过滤软件中，家长的用例包括安装软件、更新过滤网站清单、移除过滤网站，以

及供他们自己的不受限制的网站。对孩子而言，用例包括访问合法内容积“非法”内容。

切记，不可凭空想象来决定各种用例，应该与面试官交流讨论后确定。

l 步骤4：有哪些使用限制？

大致定义好用例后，我们还需要找出确切的意思。“网络被过滤屏蔽”具体指什么？只

过虑屏蔽“非法”网页还是屏蔽整个网站？是否要求该软件具备“学习”能力，从容识别不良内容，异或只是根据白名单或黑名单进行过滤？若要求具备学习能力并自动识别不良内容，允许多大的误报漏报率？

l 步骤5：压力条件和失效条件为何？

软件的失效是不可避免的，那么，软件失效应该是什么样的？显然，就算软件失效了，也不能导致计算机宕机。在本例中，失效可能是软件未能屏蔽本该屏蔽的网站，或是屏蔽本来允许访问的网站。对于后一种情况，你或许应该与面试官讨论一下，是不是让家长输入密码，允许访问该网站。

l 步骤6：有哪些测试用例？如何执行测试？

这才是手动测试和自动测试以及黑盒测试和白盒测试真正显示出差异的地方。

在步骤3和步骤4中，我们初步拟定了软件的用例，这里会进一步加以定义，并讨论该

如何执行测试。具体需要测试哪些情况？其中哪些步骤可以自动化？哪些又需要人工介入？

请记住，在有些测试中，虽然自动化可以助你一臂之力，但它也有着重大缺陷。一般来

说，在测试过程中，手动测试还是少不了的。、

对着上面的清单一步步解决问题时，请不要想到什么就草率吐露。这会显得很没有条理，

而且你肯定会遗漏重要环节。相反，你应该组织好自己的思路，先将测试工作分割为几个主要模块，然后逐一展开分析。这样，不仅可以给出一份更完整的测试用例清单，而且也显得你做事有层次、有条理。

4.      测试一个函数

基本上，测试函数是测试中最简单的一种，与面试官的交流相对也会比较简短、清晰，

因为，测试一个函数通常不外乎就是验证输入与输出。

话说回来，千万不要忽视与面试官交流的重要性。对于任意可能，特别是如何处理特定

情况，你都应该深究到底。

        假设要你编写代码测试对整数数组排序的函数sort(int [] array),可参考下面的解决步骤。

l 步骤1：定义测试用例？

一般来说，你应该考虑以下几种测试用例。

正常情况：输入正常数组时，该函数是否能生成正确的输出？务必记得考虑其中的潜在问题。比如，排序通常涉及某种分割处理，应该要合理的想一想，数组元素个数为奇数时，由于无法均分数组，算法可能无法处理。所以，测试用例必须涵盖元素个数为偶数与奇数的两种数组。

极端情况：传入空数组会出现什么问题？或传入一个很小的数组（只有一个元素）？此外，传入非常大数组又会如何呢？

空指针和“非法”输入：值得花时间好好考虑一番，若函数接收到非法输入，该怎么处理。比较，你在测试生成第n项菲波那切数的函数，那么，在测试用例中，自然要考虑n为负数的情况。

奇怪的输入：第四种有可能出现的情况：奇怪的输入。传入一个有序数组会怎么样？或者，传入一个反向排序的数组呢？

        只有充分了解函数功能，才能想到这些测试用例。如果你对各种限制条件不是很清楚，最好先向面试官问个清楚。

l 步骤2：定义预期结果？

通常，预期结果非常明显：正确的输出。然而，在某些情况下，你可能还需要验证其它

情况。比如，如果sort函数返回的是一个已排序的新数组，那么，你可能还有验证一下原先的数组是否保持原样。

l 步骤3：编写测试代码？

有了测试用例，并定义好预期结果后，编写代码实现这些测试用例，也就水到渠成了。

代码大致如下：

   

   

5.      调试与故障排除

测试问题的最后一种是，说明你会如何调试或排除已知故障。碰到这种问题，很多求职

者都会支支吾吾，处理不当，给出诸如“重装软件”等不切实际的答案。其实，就像其它问题一样，还是有章可循的，也可以有条不紊地处理。

        下面通过一个例子辅助说明，假设你是谷歌Chrome浏览器团队的一员，收到一份bug报告：Chrome启动时会崩溃。你会怎么处理。

        重新安装浏览器或许就能解决该用户的问题，但是，若其他用户碰到同样问题，怎么办？你的目标是搞清楚究竟出了什么问题，以便开发人员修复缺陷。

l 步骤1：理清状况？

首先，你应该多体问题，尽量了解当时的情况：

• 用户碰到这个问题有多久了？

• 该浏览器的版本号？在什么操作系统下运行？

• 该问题经常发生吗？或者，出问题的频率有多高？什么时候会发生？

• 有无提交错误报告？

l 步骤2：分解问题？

了解了问题发生时的具体状况，接下来，着手将问题分解为可测模块。在这个例子中，

可以设想出以下操作步骤。

1. 转到Windows的“开始”菜单。

2. 点击Chrome图标。

3. 浏览器启动。

4. 浏览器载入参数设置。

5. 浏览器发送HTTP请求载入首页。

6. 浏览器收到HTTP回应。

7. 浏览器解析网页。

8. 浏览器显示网页内容。

        在上述过程中的某一点，有地方出错致使浏览器崩溃。优秀的测试人员会逐一排查每个步骤，诊断定位问题所在。

l 步骤3：创建特定的、可控的测试？

以上各个测试模块都应该有实际的指令动作——也就是你要求用户执行的、或是你自己

可以做的操作步骤（从而在你自己的机器上予以）。在真实世界中，你面对是一般客户，不可能给他们做不到或不愿做的操作指令。

 

附：随机崩溃常见原因

1. 随机变量：该应用程序可能用到某个随机变量或可变分量，程序每次执行时取值不定。具体的例子包括用户输入、程序生成的随机数，或当前时间等。

2. 未初始化变量：该应用程序可能包含一个未初始化变量，在某些语言中，该变量可能含有任意值。这个变量取不同值可能导致代码每次执行路径有所不同。

3. 内存泄漏：该程序可能存在内存溢出。每次运行时引发问题的可疑进程随机不定，这与当时运行的进程数量有关。另外还包括堆溢出或栈内数据被破坏。

4. 外部依赖：该程序可能依赖别的应用程序、机器或资源。要是存在多处依赖，程序就有可能在任意位置崩溃。

                                    ——摘自《程序员面试金典(第5版)》