软件测试经典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

解析：除了要考虑显示的功能性需求外，还要涉及安全性、性能、兼容性等非功能性需求的验证。

2. （多选）答案：ABCDEF

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

3. （单选）答案：D

解析：无头浏览器的主要应用场景，包括 GUI 自动化测试、页面监控以及网络爬虫这三种。

4. （单选）答案：D

解析：Selenium 属于 GUI 自动化测试工具。

5. （单选）答案：A

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

Appium 则是一款很好用的移动测试工具。

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

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

答案与解析：

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

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

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

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

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

答案与解析：

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

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

• 第一种方法是，手工复制前一个 API 返回结果中的某个值，然后粘贴给后一个 API 作为输入参数。当然，这是最基本的方法，但是效率太低，而且无法实现自动化。
• 第二种方法是，使用基于代码的 API 测试框架。由于此时所有的测试逻辑都是通过代码来实现的，因此可以很容易地实现 API 之间的参数传递。
• 第三种方法是，借助于类似 HttpRunner 之类的已有 API 测试框架。此类框架可以通过关键字，很方便地将前一个 API 的返回值中的某个值传递给下一个 API 作为输入参数。

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

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

答案与解析：

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

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

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

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

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

答案与解析：

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

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

你同意哪个观点呢？

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

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

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

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

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

答案与解析：

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

• 一种是，使用第三方的云测服务，比如国外的 Sauce Labs、国内的 Testin 等；
• 另一种是，自己搭建 Selenium Grid 集群。

其实，这两种方案的本质都是将大量的测试用例以并发的方式来执行。

作者：大数据专栏
链接：https://www.jianshu.com/p/2330fac9496e
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

转载于:https://www.cnblogs.com/eriwang/p/10461131.html