测试开发笔试知识点和八股文-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_59073454/article/details/141086984

黑盒测试的方法有哪些？

黑盒测试是一种软件测试方法，它侧重于测试软件系统的功能而不考虑其内部实现。以下是一些常见的黑盒测试方法：
等价类划分 (Equivalence Partitioning)：将输入数据划分为若干个等价类，并从每个类中选取代表性数据进行测试，以减少测试用例的数量。

边界值分析 (Boundary Value Analysis)：测试输入数据的边界值，因为错误往往发生在这些边界上。

决策表测试 (Decision Table Testing)：使用决策表来表示输入条件和对应的操作，这对于处理复杂业务逻辑特别有用。

状态转换测试 (State Transition Testing)：根据系统的状态机模型，测试不同状态之间的转换和相应的行为。

错误推测 (Error Guessing)：基于测试人员的经验和对系统的了解，猜测可能出现的错误并设计相应的测试用例。

因果图法 (Cause-Effect Graphing)：通过构建因果图，确定输入条件（因）和输出结果（果）之间的关系，并设计测试用例。

用例测试 (Use Case Testing)：根据系统的用例，设计测试场景，确保所有功能都得到测试。

语句覆盖率 (Statement Coverage)：确保每一条语句至少被执行一次。

功能覆盖率 (Function Coverage)：确保所有功能点都被测试到。

白盒测试的方法有哪些？

白盒测试是一种软件测试方法，它关注软件系统的内部结构和实现细节。以下是一些常见的白盒测试方法：

语句覆盖 (Statement Coverage)：测试用例设计旨在确保程序中的每一条语句至少被执行一次。

分支覆盖 (Branch Coverage)：测试用例设计旨在确保程序中的每一个分支（即每个 if 语句的 true 和 false 分支）至少被执行一次。

路径覆盖 (Path Coverage)：测试用例设计旨在确保程序中的每一条可能执行的路径都被覆盖。这是最严格的白盒测试方法，但也最难实现，因为路径的数量可能非常多。

条件覆盖 (Condition Coverage)：测试用例设计旨在确保程序中的每一个条件表达式的每个可能的布尔值都至少被执行一次。

多条件覆盖 (Multiple Condition Coverage)：测试用例设计旨在确保程序中的每一个条件表达式的所有可能的组合都至少被执行一次。

数据流测试 (Data Flow Testing)：关注变量的定义和使用，确保变量在使用之前已被正确初始化，测试用例设计基于程序中变量的定义、使用和销毁。

循环测试 (Loop Testing)：测试用例设计旨在确保程序中的所有循环结构（for、while 等）在各种可能的情况下都被执行。例如，测试循环不执行、执行一次和执行多次的情况。

基路径测试 (Basis Path Testing)：基于程序的控制流图，识别出程序的所有独立路径，并设计测试用例覆盖这些路径。

逻辑覆盖 (Logic Coverage)：确保所有的逻辑表达式在各种可能的情况下都被测试。

符号执行 (Symbolic Execution)：通过符号而非实际值来执行程序，以探索所有可能的执行路径。

这些方法可以帮助识别代码中的逻辑错误、计算错误和其他潜在的问题。白盒测试通常与代码审查和静态代码分析工具结合使用，以提高测试的有效性。

什么是单元测试？

单元测试是一种软件测试方法，旨在验证软件应用程序中最小可测试单元的正确性。通常，这些单元指的是单个函数、方法、类或模块。单元测试的主要目标是确保每个单元在独立的情况下按照设计和预期运行。关键点如下：

独立性：每个单元测试应独立运行，不依赖于其他测试或系统的其他部分。这确保了测试结果的准确性和可靠性。
隔离性：单元测试通常使用**模拟对象（mocks）或桩（stubs）**来替代真实的依赖项，以便专注于被测试单元的行为。
自动化：单元测试通常是自动化的，可以在开发过程中频繁运行，以便快速发现和修复错误。常用的单元测试框架包括JUnit（Java）、NUnit（C#）、pytest（Python）、JUnit（JavaScript）等。
可重复性：单元测试应在每次运行时产生相同的结果，无论外部环境如何变化。这意味着测试应尽量避免依赖外部资源，如文件系统、网络或数据库。
高覆盖率：理想情况下，单元测试应覆盖代码的每个分支和路径，以最大程度地减少潜在的错误。
快速执行：单元测试应设计得尽可能简洁和快速，以便在持续集成过程中频繁运行。

案例

# 被测试函数
def add(a, b):
    return a + b

# 单元测试
import unittest

class TestMathFunctions(unittest.TestCase):
    def test_add(self):
        self.assertEqual(add(1, 2), 3)
        self.assertEqual(add(-1, 1), 0)
        self.assertEqual(add(-1, -1), -2)

if __name__ == '__main__':
    unittest.main()

在这个示例中，我们定义了一个简单的 add 函数，并使用 Python 的 unittest 框架为其编写了几个单元测试。这些测试验证了 add 函数在不同输入下的正确性。

单元测试的优点

早期发现错误：在开发过程中尽早发现和修复错误，降低修复成本。
改进代码质量：通过编写单元测试，可以更好地理解和设计代码，提高代码质量和可维护性。
文档作用：单元测试可以作为代码的文档，帮助开发人员理解代码的预期行为。
重构的安全网：在代码重构时，单元测试可以确保修改没有引入新的错误。

单元测试是软件开发过程中的重要组成部分，帮助确保代码的健壮性和质量。

什么是集成测试

集成测试是一种软件测试方法，旨在验证多个独立开发的单元或组件在集成在一起后能否正确工作。与单元测试不同，单元测试关注单个模块或函数的正确性，而集成测试关注这些模块或函数之间的交互和接口。

集成测试的主要目标

验证接口和交互：确保各个模块或组件之间的接口和交互能够正确地工作。
发现集成问题：识别由于模块集成引起的错误，如接口不匹配、数据格式问题和通信问题。
验证子系统行为：验证子系统或子模块在集成后的行为是否符合预期。

集成测试的方法

大爆炸法 (Big Bang Integration)：
- 所有模块在一次集成后进行测试。
- 优点：适合小型系统和简单项目。
- 缺点：难以定位错误，调试复杂。
增量集成 (Incremental Integration)：
- 分步骤集成和测试模块。
- 包括以下几种策略：
  - 自顶向下 (Top-Down Integration)：从系统的顶层模块开始，逐步集成低层模块。
  - 自底向上 (Bottom-Up Integration)：从系统的底层模块开始，逐步集成高层模块。
  - 混合集成 (Sandwich Integration)：结合自顶向下和自底向上的方法，适用于大型复杂系统。
功能集成 (Functional Integration)：
- 按功能或子系统进行集成和测试。
- 适用于功能明显分离的系统。

集成测试的类型

接口测试 (Interface Testing)：验证模块之间的接口和数据传输是否正确。
数据流测试 (Data Flow Testing)：检查数据在模块之间的流动和处理是否正确。
子系统测试 (Subsystem Testing)：验证子系统在集成后的行为和性能。
回归测试 (Regression Testing)：在每次新模块集成后，重新测试已有功能，确保没有引入新的错误。

示例

假设我们有一个简单的电商系统，包括用户管理、订单处理和支付模块。集成测试的目标是确保这些模块在集成后能正常工作。以下是一个集成测试示例：

import unittest
from user_module import User
from order_module import Order
from payment_module import Payment

class TestEcommerceIntegration(unittest.TestCase):
    def test_user_order_payment_integration(self):
        user = User(name="John Doe", balance=100)
        order = Order(user=user, total_amount=50)
        payment = Payment()

        # 用户下订单
        self.assertTrue(order.place_order())
        self.assertEqual(user.balance, 50)  # 检查余额是否正确

        # 支付订单
        self.assertTrue(payment.process_payment(order))
        self.assertEqual(order.status, "Paid")  # 检查订单状态是否更新

if __name__ == '__main__':
    unittest.main()

在这个示例中，我们测试了用户模块、订单模块和支付模块的集成，确保它们在一起工作时的行为是正确的。

集成测试的优点

早期发现集成问题：在模块集成过程中尽早发现和修复问题，减少后期修复成本。
提高系统稳定性：确保模块之间的接口和交互正确，增强系统稳定性。
验证系统功能：通过集成测试，验证系统的整体功能和性能，确保系统按预期工作。

集成测试在软件开发过程中起着重要作用，帮助确保各个模块在集成后的正确性和稳定性。

测试用例怎么编写与设计？

编写与设计测试用例是软件测试中至关重要的步骤。良好的测试用例能够系统地覆盖软件功能，帮助发现潜在的问题。以下是编写与设计测试用例的基本步骤和原则：

测试用例的基本组成部分

测试用例编号：唯一标识测试用例的编号，方便管理和追踪。
测试用例标题：简要描述测试用例的内容和目的。
前置条件：执行测试前需要满足的条件或系统状态。
测试步骤：详细列出执行测试的步骤，确保测试人员能够准确复现测试过程。
预期结果：执行测试步骤后系统应显示的正确结果。
实际结果：执行测试步骤后系统的实际表现，测试时填写。
测试状态：测试结果是否通过，标记为通过或失败。
备注：其他需要说明的内容，如特殊情况、依赖关系等。

编写与设计测试用例的步骤

理解需求：深入理解软件需求和功能规格，明确系统的预期行为和性能标准。
识别测试点：根据需求文档和功能说明，确定需要测试的功能点和场景。
设计测试数据：根据测试点设计相应的输入数据，确保测试覆盖各种边界情况和异常情况。
编写测试步骤：详细编写每个测试步骤，确保操作简单明了，易于复现。
定义预期结果：明确每个测试步骤的预期结果，确保结果具体、可验证。
评审和优化：与团队成员评审测试用例，确保完整性和准确性，优化测试用例设计。

设计测试用例的方法

等价类划分 (Equivalence Partitioning)：将输入数据划分为若干等价类，每个类中的数据应产生相同的结果，从每个类中选取代表性数据进行测试。
边界值分析 (Boundary Value Analysis)：重点测试输入数据的边界值，因为错误往往发生在边界处。
因果图法 (Cause-Effect Graphing)：分析输入条件（因）与输出结果（果）之间的关系，设计测试用例覆盖各种组合。
决策表测试 (Decision Table Testing)：使用决策表表示输入条件和对应操作，设计测试用例覆盖所有可能的条件组合。
状态转换测试 (State Transition Testing)：根据系统的状态机模型，测试不同状态之间的转换和相应行为。
错误推测 (Error Guessing)：基于经验和直觉，猜测可能出现的错误并设计相应测试用例。

示例

假设我们有一个简单的登录功能，要求如下：

用户名和密码均为必填项。
用户名和密码正确时，登录成功。
用户名或密码错误时，登录失败。

以下是为该登录功能设计的一些测试用例：

测试用例编号	测试用例标题	前置条件	测试步骤	预期结果	备注
TC001	用户名和密码均正确的登录测试	无	1. 输入正确的用户名 2. 输入正确的密码 3. 点击登录按钮	显示登录成功消息	无
TC002	用户名为空的登录测试	无	1. 输入空的用户名 2. 输入正确的密码 3. 点击登录按钮	提示用户名不能为空	无
TC003	密码为空的登录测试	无	1. 输入正确的用户名 2. 输入空的密码 3. 点击登录按钮	提示密码不能为空	无
TC004	用户名错误的登录测试	无	1. 输入错误的用户名 2. 输入正确的密码 3. 点击登录按钮	提示用户名或密码错误	无
TC005	密码错误的登录测试	无	1. 输入正确的用户名 2. 输入错误的密码 3. 点击登录按钮	提示用户名或密码错误	无

通过这些测试用例，我们可以系统地验证登录功能的正确性，确保在各种情况下系统表现符合预期。

测试用例编写的最佳实践

保持简洁明了：测试步骤和预期结果应尽量简洁，便于理解和执行。
覆盖全面：确保测试用例覆盖所有功能点、边界情况和异常情况。
可重复性：测试用例应保证每次执行时的结果一致。
独立性：每个测试用例应独立，不依赖于其他测试用例的执行顺序或结果。
持续维护：随着需求变化和软件更新，及时更新测试用例，保持其有效性和准确性。

通过遵循这些原则和步骤，可以编写出高质量的测试用例，帮助确保软件系统的可靠性和稳定性。

什么是灰盒测试？

灰盒测试是一种软件测试方法，结合了白盒测试和黑盒测试的特点。它既关注软件系统的内部结构和实现细节，又关注系统的功能和外部行为。灰盒测试主要用于在不完全了解内部实现的情况下，通过部分了解系统的内部工作原理来设计和执行测试。

灰盒测试的特点

部分了解内部结构：测试人员对系统的内部工作原理有一定了解，但不是完全掌握。这种部分了解可以帮助测试人员设计更有效的测试用例。
关注功能和性能：灰盒测试不仅测试系统的功能是否正确，还测试系统在不同负载和条件下的性能。
适用场景广泛：灰盒测试适用于需要了解部分内部实现的功能测试、集成测试和系统测试等。

灰盒测试的方法

代码审查和分析：通过代码审查和分析，理解系统的关键逻辑和实现细节，从而设计有针对性的测试用例。
日志文件分析：通过分析系统的日志文件，了解系统的内部状态和行为，帮助定位和诊断问题。
数据库测试：检查数据库的状态和数据完整性，验证系统对数据库的操作是否正确。
配置文件测试：检查系统的配置文件，验证配置参数的正确性和系统对配置变化的响应。
结合自动化测试工具：使用自动化测试工具和框架，如Selenium、JUnit等，通过脚本化测试实现灰盒测试。

灰盒测试的优点

更全面的测试覆盖：结合了黑盒测试和白盒测试的优点，能够更全面地覆盖系统的功能和内部逻辑。
早期发现潜在问题：通过了解部分内部实现，可以在早期发现和修复潜在问题，减少后期修复成本。
提高测试效率：利用内部实现的部分知识，可以更有针对性地设计测试用例，提高测试效率和效果。

灰盒测试的缺点

依赖知识水平：灰盒测试依赖测试人员对系统内部实现的了解程度，不同测试人员的知识水平可能影响测试效果。
不适用于所有项目：对于完全未知的系统或外包项目，获取内部实现的知识可能困难，不适合进行灰盒测试。

示例

假设我们有一个简单的Web应用，用户可以通过登录页面进行登录。灰盒测试可以结合登录功能的黑盒测试和部分白盒测试。

黑盒测试用例

输入正确的用户名和密码，验证能否成功登录。
输入错误的用户名或密码，验证登录失败的提示消息。
输入空的用户名或密码，验证登录失败的提示消息。

白盒测试用例

验证登录函数对数据库的查询是否正确。
检查登录函数是否正确处理异常情况，如数据库连接失败。

灰盒测试用例

分析登录日志文件，验证日志中记录的登录尝试是否正确。
检查用户输入的数据是否在登录函数中正确传递和处理。
验证用户登录后的会话管理是否正确，确保会话ID的生成和管理符合预期。

总结

灰盒测试是一种综合性测试方法，通过结合黑盒测试和白盒测试的优点，可以更全面、深入地测试系统的功能和性能。在实际应用中，灰盒测试能够帮助测试人员更有效地发现问题，提高软件系统的质量和可靠性。

圈复杂度怎么计算？
圈复杂度（Cyclomatic Complexity）是衡量代码复杂度的一个重要指标，它表示程序的独立路径数量，即判断逻辑结构的复杂程度。圈复杂度越高，表示代码的逻辑分支越多，维护难度也会增加。

计算圈复杂度的方法

圈复杂度通常通过代码的控制流图（Control Flow Graph, CFG）来计算。控制流图中的节点代表程序中的基本块（单个入口和出口的代码序列），而边代表控制流的转移。

以下是圈复杂度的计算方法：

控制流图法：
- 将程序绘制成控制流图。
- 圈复杂度 V(G)计算公式： V(G) = E - N + 2P
  其中：
  E是图中的边数。
  N是图中的节点数。
  P是图中独立部分的数量（通常为1，如果是单个程序）。
代码结构法：
圈复杂度也可以通过代码结构来计算。对于一个函数或方法，圈复杂度的初始值为1，然后根据以下规则进行累加：
- 每个 if、else if、while、for、case、catch、goto 语句增加 1。
- 每个 and (&&) 或 or (||) 逻辑运算符通常也会增加 1，因为它们引入了额外的逻辑分支。

例子

假设有以下的简单伪代码：

def example(x, y):
    if x > 10:
        if y > 5:
            return y
        else:
            return x
    else:
        return x + y

初始化圈复杂度为1。
第一个 if 语句增加1。
第二个嵌套的 if 语句增加1。
else 语句不增加圈复杂度，因为它与之前的 if 共享一个分支。
所以，这段代码的圈复杂度为 1（初始） + 1（第一个 if） + 1（第二个 if） = 3。

圈复杂度的意义

1-10：代码的结构比较简单，可读性和可维护性都较高。
10-20：代码复杂度中等，可能需要重构。
20-40：代码复杂度较高，维护困难，强烈建议重构。
40+：代码非常复杂，几乎不可维护，需要重写。

圈复杂度是评估代码复杂性的一个重要指标，有助于开发者识别和优化复杂的代码块，从而提升代码的可读性和可维护性。

例题来自牛客网
在这里插入例题来自牛客网图片描述