测一测 | 这些软件测试题目，你都掌握了吗？

经过将近五个月、60 篇文章的学习，相信你已经对软件测试的全貌有了一个大致的理解，而对某一种类型的测试（比如，GUI 自动化测试、移动 App 的自动化测试、性能测试等），也有了更深入的理解。

现在，我从专栏中精心挑选了 10 个核心知识点，组成了 10 道测试题目（包含 5 道选择题，5 道问答题）。希望可以帮助你检测一下这段时间的学习成果，以期对这些核心知识的理解可以达到炉火纯青的程度。

如果你刚刚打开这个专栏，可以用这 10 道题目，找到自己的薄弱点，对症下药；如果你已经学习了一段时间，可以用这 10 道题目，检测一下学习成果，查漏补缺。

我的建议是：你可以拿出纸笔，写下这 10 道题的答案，然后再与文末的答案进行对照。

选择题

1. （单选）当需要对某个系统进行测试的时候，应该从哪些方面来设计测试用例？

  • A. 功能验证

  • B. 性能相关的验证

  • C. 兼容性相关的验证

  • D. 安全性相关的验证

  • E. 以上全是

2. （多选）软件测试过程中，测试数据准备的痛点有哪些？（多选）

  • A. On-the-fly 测试数据准备的时间消耗

  • B. Out-of-box 测试数据的“脏数据”

  • C. 测试数据本身组合的复杂性和多样性

  • D. 性能测试数据准备的时间消耗

  • E. 微服务化后，跨多个微服务的数据准备缺乏完整的知识体系

  • F. 微服务化后，测试数据准备的环境依赖性

3. （单选）无头浏览器的主要应用场景是？

  • A. 网络爬虫

  • B. GUI 自动化功能测试

  • C. 页面监控

  • D. 以上全是

4. （单选）以下不属于 API 测试工具的是哪个？

  • A. Postman

  • B. SoapUI

  • C. JMeter

  • D. Selenium

5. （单选）以下属于移动应用测试的工具是哪个？

  • A. Appium

  • B. UFT

  • C. TestNG

  • D. LoadRunner

问答题

  1. GUI 自动化测试脚本分层设计的最佳实践是怎么样？

  2. 多个 API 连续调用的测试用例的难点是什么？你是如何来解决的？

  3. 单元测试中，桩函数和 Mock 函数用来解决什么问题，两者又有什么区别？

  4. 性能压测过程中，当面对大量并发用户调用的时候，服务器端 CPU 的使用率是高好还是低好？为什么？

  5. 当需要在尽可能短的时间内完成大量 GUI 自动化测试用例的执行时，业界主流的解决方案是什么？

答案与解析

1. （单选）答案：E

解析：在专栏第 1 篇文章《你真的懂测试吗？从“用户登录”测试谈起》中，我和你分享了设计一个测试用例，除了要考虑显示的功能性需求外，还要涉及安全性、性能、兼容性等非功能性需求的验证。

2. （多选）答案：ABCDEF

解析：在专栏的第 15 篇文章《过不了的坎：聊聊 GUI 自动化过程中的测试数据》、第 36 篇文章《浅谈测试数据的痛点》中，我从测试时机准备的角度，和你分享了测试数据准备有哪些痛点。

而关于现在流行的微服务模式，由于每个单一功能的服务都是独立分开部署的，所以我们在准备测试数据时，还可能会遇到诸如环境依赖、跨多个微服务的数据准备缺乏完整的知识体系等问题。

3. （单选）答案：D

解析：我在专栏的第 16 篇文章《脑洞大开：GUI 测试还能这么玩（Page Code Gen + Data Gen + Headless）？》中，和你分享过：无头浏览器的主要应用场景，包括 GUI 自动化测试、页面监控以及网络爬虫这三种。

4. （单选）答案：D

解析：Selenium 属于 GUI 自动化测试工具。我还在第 12 篇文章《从 0 到 1：你的第一个 GUI 自动化测试》中，基于 Selenium 和你一起搭建了我们的第一个测试用例，你还记得吗？

5. （单选）答案：A

解析：UFT（以前的 QTP）属于一款 GUI 测试工具，LoadRunner 属于性能测试工具。而 TestNG 是一个用来简化广泛的测试需求的测试框架，适用于从单元测试到集成测试阶段的测试。

Appium 则是一款很好用的移动测试工具。如果你不记得它的使用方法了，可以再回顾下第 21 篇文章《移动测试神器：带你玩转 Appium》中的内容。

6. GUI 自动化测试脚本分层设计的最佳实践是怎样的？

考点分析：GUI 自动化测试脚本的分层设计原理。

答案与解析：

大量 GUI 自动化测试能够成功的关键，就在于脚本的分层设计。而脚本分层设计的核心思想就是模块化。

首先，我们需要对页面进行抽象，形成页面对象模型。在这样的测试用例中，你看到的都是类似于 XXXPage.YYYComponent.ZZZOperation 的语句。它们和实际的手工测试可以建立一一对应的关系，用通俗的话语来讲，就是某某页面上的某某元素，执行了某某操作。

接下来，为了使 GUI 自动化测试脚本更加符合业务场景的描述，同时进一步提高脚本的封装性和可重用性，就需要引入业务流程脚本的概念。这里，业务流程和实际的业务流程也是一一对应的关系。这样，测试用例就可以通过调用业务流程脚本来实现，测试用例本身的可读性以及可维护性也会更好。同样地，业务流程脚本，也是基于页面对象模型实现的。

关于页面对象模型的细节，你可以再回顾下第 13 篇文章《效率为王：脚本与数据的解耦 + Page Object 模型》中的相关内容。

而关于业务流程抽象的细节，你可以再回顾下第 14 篇文章《更接近业务的抽象：让自动化测试脚本更好地描述业务》中的相关内容。

7. 多个 API 连续调用的测试用例设计难点是什么？你是如何解决的？

考点分析：多个 API 连续调用时，前后两个 API 之间的参数传递。

答案与解析：

单个 API 测试并不难，难的是多个 API 的连续调用，并且后一个 API 的参数值使用的是前一个 API 调用的返回结果，这就要求多个 API 调用之间可以方便地进行参数传递。一个最典型的场景就是，前一个 API 调用会返回一个有效的 token，后一个 API 调用需要带着这个 token 才能调用成功。

为了解决这个问题，一般来讲有三种处理方法：

  • 第一种方法是，手工复制前一个 API 返回结果中的某个值，然后粘贴给后一个 API 作为输入参数。当然，这是最基本的方法，但是效率太低，而且无法实现自动化。

  • 第二种方法是，使用基于代码的 API 测试框架。由于此时所有的测试逻辑都是通过代码来实现的，因此可以很容易地实现 API 之间的参数传递。

  • 第三种方法是，借助于类似 HttpRunner 之类的已有 API 测试框架。此类框架可以通过关键字，很方便地将前一个 API 的返回值中的某个值传递给下一个 API 作为输入参数。

关于复杂场景下的 API 测试，建议你再回顾下第 22 篇文章《从 0 到 1：API 测试怎么做？常用 API 测试工具简介》中的相关内容，以及《测试专栏特别放送 | 答疑解惑第四期》中的第一个问题。毕竟，复杂场景的 API 测试，才是我们业务场景中最常遇到的，也是软件测试工程师面试过程中经常会被问题到的问题。

8. 单元测试中，桩函数和 Mock 函数主要用来解决什么问题？这两者又有什么区别呢？

考点分析：理解桩函数和 Mock 函数的本质区别。

答案与解析：

当被测函数中调用了第三方的函数时，我们一般会采用桩函数或者 Mock 函数来模拟这些第三方函数，以此来实现被测函数的高代码覆盖率。可以说，桩函数和 Mock 函数的使用大大方便了单元测试的开展，同时也解决了单元测试的代码耦合性问题。

但是，这两者到底有什么区别呢？

通俗来讲，如果你的测试验证是在被测函数中进行的，那么此时你使用的就是桩函数；而如果你的测试验证是在被模拟的函数中进行的，那么这个被模拟的函数就是 Mock 函数。

更详细的分析，你可以再回看下第 3 篇文章《什么是单元测试？如何做好单元测试？》中的相关内容。

9. 性能压测过程中，当面对大量并发用户调用的时候，服务器端 CPU 的使用率是高好还是低好？为什么？

考点分析：理解性能测试指标解读的复杂性，必须要全盘考虑多个指标间的相互关联和制约。

答案与解析：

这个问题的答案，一定会有坚持不同意见的两派人。

  • 一部分人认为，CPU 使用率当然是越低越好。这说明后端代码实现得很高效，只占用很少的计算资源就能实现较高的并发。并发情况下，越低的 CPU 占用率，说明系统可以继续承载越多的并发负载。

  • 而另一部分人则认为，CPU 的使用率是越高越好。这说明系统的计算资源被充分利用了起来。

你同意哪个观点呢？其实，这个问题本身就是个伪命题，单单通过题干中的信息是不足以给出孰好孰坏的结论的。这里的关键是，随着并发用户数的上升，事务的响应时间是如何变化的。

如果随着并发用户数的增加，事务的响应时间也呈线性增长，但 CPU 的使用率一直上不去，这就是典型的 CPU 资源没有被充分利用的现象。此时，你就需要去进一步诊断为什么 CPU 资源不能在并发场景下被充分利用。

而如果随着并发用户数的增加，事务的响应时间能基本保持稳定，同时 CPU 的使用率会随着并发用户数的增加呈线性增加，这反倒是我们希望看到的结果，也就是说更多的并发用户会需要使用更多的 CPU 资源。

10. 当需要在尽可能短的时间内，执行完大量 GUI 自动化测试用例时，业界主流的解决方案是什么？

考点分析：测试执行架构的设计

答案与解析：

这个问题其实不难回答，业界一般会采用两种方案：

  • 一种是，使用第三方的云测服务，比如国外的 Sauce Labs、国内的 Testin 等；

  • 另一种是，自己搭建 Selenium Grid 集群。

其实，这两种方案的本质都是将大量的测试用例以并发的方式来执行。更多的技术细节，你可以参考第 39 篇文章《从小作坊到工厂：什么是 Selenium Grid？如何搭建 Selenium Grid？》中的相关内容。

Previous测试专栏特别放送 | 浅谈全链路压测

Last updated

Was this helpful?