• 软测测试按照测试的方法分类,可以分为白盒测试, 黑盒测试和灰盒测试, 那么他们分别是什么意思?主要的测试内容和意义是什么?

一. 白盒测试.

• 白盒测试的定义: 白盒测试又称为结构测试或者逻辑测试, 它一般用来分析程序内部的结构, 针对程序的逻辑结构来设计测试用例.

• 白盒测试主要有两种:

  1. 静态测试: 常见于桌面检查, 代码审查, 代码扫描工具等.
  2. 动态测试: 语句覆盖, 判定覆盖, 条件覆盖, 判定条件覆盖, 条件组合覆盖, 路径覆盖.

1.1 语句覆盖

• 语句覆盖定义: 每个语句都至少执行一次.(即代码中的语句都必须被执行到)

• 现给出如下代码:
  if A and B
then action1
if C or D
then action2

• 对于第一条语句: A和B都必须为true 才能够执行action1 确保每一条语句都执行.

• 对于第二条语句: 有三种情况可以执行保证每条语句都执行, C true D true ||
  C true D false || C false D true (即必须保证C or D为真 ) 此时才可以执行action2

• 此时的语句覆盖可以是 :

  • 语句覆盖测试用例: A true B true C true D false
  • 此时,就可以保证每个语句都执行. 此处只是列举其中的一种情况, 亦可以是其他的覆盖

• 语句覆盖的优点:

  • 关注判定：判定覆盖主要关注程序中的判定语句，如if-else语句、switch语句等。
  • 真假分支：对于每个判定语句，都需要设计测试用例来覆盖其取“真”和取“假”的情况。
  • 全面覆盖：确保程序中的每一个判定都至少经历一次取“真”和一次取“假”的分支。

• 语句覆盖的缺点:

  • 测试质量低：语句覆盖只关注语句的执行，而不考虑逻辑路径、条件分支、循环等复杂结构。因此，即使实现了语句覆盖，也可能遗漏很多重要的测试场景，导致测试质量不高。
  • 误导性：语句覆盖可能会给人一种“程序已经测试得很充分”的错觉，而实际上程序可能还存在很多未被发现的错误和缺陷。这是因为语句覆盖没有考虑到程序中的逻辑关系和依赖关系。
  • 缺乏深度：对于包含多个分支、循环和复杂逻辑的程序，语句覆盖的局限性尤为明显。它无法确保程序在所有可能的输入和条件下都能正确运行。
  • 重复代码问题：如果程序中存在大量重复的代码（如函数或方法中的重复语句），语句覆盖可能会导致测试用例的冗余和不必要的重复。这是因为每个重复的语句都需要被单独测试，而实际上它们可能具有相同的逻辑和功能。
  • 忽略异常和错误处理：语句覆盖通常不会特别关注程序的异常和错误处理逻辑。这意味着即使程序中的异常和错误处理语句被覆盖了，也可能无法确保这些逻辑在实际运行时能够正确工作。

1.2 判定覆盖

• 判定覆盖定义:也称为分支覆盖（Branch Coverage），是软件测试中的一种覆盖技术，它要求设计足够的测试用例，以确保程序中的每一个判定（或分支点）至少获得一次“真”和一次“假”的结果，即程序流程图中的每一个真假分支至少被执行一次。(无论出现集中判定结果, 在测试用例中必须体现出这两种判定结果)
• 现给出如下代码:
  if A and B
then action1
if C or D
then action2
• 对于语句一:
  • if判定语句为真: A true B true
  • if判定语句为假: A true B false || A false B true || A false B false
• 对于语句二:
  • if判定语句为真: C true D true || C true D false || C false D true
  • if判定语句为假: C false D false
• 此时的判定覆盖可以是:
  • 判定覆盖的测试用例1: A true B true C true D false
  • 判定覆盖的测试用例2: A true B false C false D false
  • 此时,就可以保证每个语句都执行. 此处只是列举其中的一种情况, 亦可以是其他的覆盖
• 判定覆盖的优点
  • 相比于语句覆盖，判定覆盖能够更全面地测试程序中的逻辑路径，因为它考虑了判定语句的不同结果。
  • 有助于发现由于判定条件错误或遗漏而导致的逻辑错误。
• 判定覆盖的缺点
  • 判定覆盖仍然可能遗漏某些路径，特别是当多个条件组合时，可能无法覆盖所有可能的条件组合。
  • 对于复杂的程序，设计足够的测试用例以实现判定覆盖可能会比较困难且耗时。

1.3 条件覆盖

• 条件覆盖定义: 设计足够的测试用例，使得程序中每个判定表达式中的每个条件的每种可能值都至少执行一次。(每个条件的可能值都必须被执行过)

• 现给出如下代码:
  if A and B
then action1
if C or D
then action2

• 对于语句一: 它的条件有A和B,他们的情况分别为true或者false.

• 对于语句二: 它的条件有C和D,他们的情况分别为true或者false.

• 此时的判定覆盖可以是:

  • 判定覆盖的测试用例1: A true B true C true D true
  • 判定覆盖的测试用例2: A false B false C false D false
  • 此时,就可以保证每个语句都执行. 此处只是列举其中的一种情况, 亦可以是其他的覆盖

• 条件覆盖的优点:

  • 高效检测条件错误：能够确保每个条件表达式中的每个条件都至少取到其所有可能的结果，有助于发现条件逻辑错误。
  • 提高代码覆盖率：相比于其他覆盖策略，条件覆盖通常能提供更高的代码覆盖率，特别是针对条件表达式丰富的代码段。
  • 促进代码质量：通过细致的条件测试，有助于提升代码质量，减少因条件逻辑不当而导致的软件缺陷。

• 条件覆盖的缺点:

  • 可能产生冗余测试：有时为了满足条件覆盖的要求，可能会设计一些在实际应用中不太可能出现的测试用例，这些测试用例可能增加测试成本而对软件质量的提升贡献不大。
  • 忽略条件组合：条件覆盖主要关注单个条件的取值，而不考虑条件之间的组合关系，可能无法发现由条件组合错误引起的软件问题。
  • 测试成本较高：为了实现条件覆盖，需要设计更多的测试用例，增加了测试工作的复杂性和成本。
  • 依赖代码实现：条件覆盖测试用例的设计高度依赖于代码的具体实现，代码的任何变动都可能需要重新设计测试用例。

1.4 判定条件覆盖.

• 判定条件覆盖定义: 顾名思义就是既要包含条件覆盖(每个条件所出现的每种情况都必须包含在测试用例之中), 又要包含判定覆盖(每一个判定的两种情况都必须体现在测试用例之中).
• 现给出如下代码:
  if A and B
then action1
if C or D
then action2
• 此处只需要将上面的判定覆盖的用例和 条件覆盖的用例结合, 就可以得出判定条件覆盖的测试用例:
  • 用例1: A true B true C true D true
  • 用例2: A false B false C false D false
• 判定条件覆盖的优点:
  • 全面测试：判定条件覆盖不仅考虑了判断语句的真假分支，还深入到了判断条件内部，确保了每个条件的不同取值都被测试到，从而提供了更为全面的测试覆盖。
  • 提高测试质量：通过测试每个条件的不同取值和判断的不同结果，判定条件覆盖有助于发现更多的逻辑错误和边界情况，提高测试质量。
  • 促进代码质量：在开发过程中实施判定条件覆盖，可以促使开发人员编写更清晰、更易于测试的代码，从而提高代码质量。
• 判定条件覆盖的缺点:
  • 测试用例设计复杂：为了实现判定条件覆盖，需要设计更为复杂的测试用例，以覆盖每个条件的不同取值和判断的不同结果，这增加了测试工作的难度和成本。
  • 测试成本较高：由于需要设计更多的测试用例，并且这些测试用例的执行可能涉及更复杂的测试场景和输入数据，因此判定条件覆盖的测试成本相对较高。
  • 可能忽略条件组合：尽管判定条件覆盖考虑了条件的不同取值，但它仍然可能忽略条件之间的组合情况。在某些情况下，可能需要额外的测试用例来覆盖这些条件组合。
  • 依赖代码实现：判定条件覆盖的测试用例设计高度依赖于代码的具体实现，代码的任何变动都可能导致测试用例需要重新设计或修改。

1.5 条件组合覆盖

• 条件组合覆盖定义:（Condition Combination Coverage）是白盒测试中的一种高级测试策略，它要求设计足够的测试用例，使得每个判定语句中所有条件的各种可能组合都至少被执行一次。这种测试方法不仅关注单个条件的取值，还关注条件之间的组合关系，从而提供更全面的测试覆盖。
• 条件组合覆盖的优点:
  • 提供更全面的测试覆盖，有助于发现更多潜在的逻辑错误和边界情况。
  • 提高测试质量，增强软件的可靠性和稳定性。
• 条件组合覆盖的缺点:
  • 测试用例设计复杂，需要投入更多的时间和资源。
  • 在条件较多或组合复杂的情况下，测试用例数量可能非常庞大，导致测试成本增加。

1.6 路径覆盖

• 路径覆盖的定义: 其核心思想是设计足够多的测试用例，以确保程序中的每条可能路径都至少被执行一次。如果程序图中有环，则要求每个环也至少经过一次。路径覆盖是白盒测试法中的一种重要技术，因为它覆盖了程序中所有可能的执行路径，因此其覆盖程度非常高。

• 路径覆盖的优点:

  • 高代码覆盖率：路径覆盖致力于确保程序中的每条可能路径都被执行至少一次。这有助于发现那些只在特定路径上才会出现的问题，从而提高代码的整体覆盖率。
  • 发现潜在错误：通过测试所有可能的执行路径，路径覆盖能够揭示那些在常规测试（如语句覆盖或判定覆盖）中可能遗漏的逻辑错误或异常处理不当的问题。
  • 增强软件可靠性：通过确保所有路径都被测试，路径覆盖有助于增强软件的可靠性和稳定性，因为它减少了软件中隐藏的错误和漏洞。
  • 提高测试质量：路径覆盖要求测试人员深入理解程序的结构和逻辑，从而设计出能够覆盖所有路径的测试用例。这种深入的测试设计有助于提高测试的质量和有效性。

• 路径覆盖的缺点:

  • 测试成本高：对于复杂的程序，可能的执行路径数量可能非常庞大，甚至是指数级的。这意味着为了实现路径覆盖，需要设计并执行大量的测试用例，从而导致测试成本显著增加。
  • 实现难度大：在实际应用中，完全实现路径覆盖可能非常困难。程序中的循环、条件分支和函数调用等因素都可能增加路径的复杂性和数量。此外，由于程序的动态性和不确定性，某些路径可能在实际运行中很难被触发。
  • 冗余测试：在某些情况下，路径覆盖可能会产生冗余的测试。例如，某些路径可能在实际应用中很少被触发，或者它们的执行结果对程序的整体功能没有显著影响。为这些路径设计测试用例可能会浪费测试资源。
  • 对测试人员要求高：路径覆盖要求测试人员具有深入的程序分析能力和良好的测试用例设计能力。测试人员需要能够准确识别所有可能的执行路径，并设计出能够覆盖这些路径的测试用例。这对测试人员的技能和经验提出了较高的要求。

二.黑盒测试.

• 黑盒测试的定义: 又称功能测试或数据驱动测试，是基于需求规格和用户文档来测试软件系统的功能是否按照预期工作。在测试中，将程序看作一个不能打开的黑盒子，测试人员不需要了解程序内部的代码或结构，只需通过程序的接口进行测试，验证其功能是否满足需求规格说明书的要求。

2.1 黑盒测试常用方法

• 黑盒测试的方法:
  • 等价类划分法：将程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。
  • 边界值分析法：对输入或输出的边界值进行测试，通常与等价类划分法结合使用，以提高测试的覆盖率和有效性。
  • 错误推测法：基于测试人员的经验和直觉，推测程序中可能存在的错误，并设计相应的测试用例来验证这些错误是否存在。
  • 场景设计法：通过模拟特定场景边界发生的事件，触发某个动作的发生，并观察事件的最终结果，从而发现需求中存在的问题。
  • 因果图法：一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系，从而设计测试用例。
  • 判定表法：通过条件桩、动作桩、条件项、动作项构建整体过程，将复杂的问题按照各种可能的情况全部列举出来，从而设计完整的测试用例集合。
  • 正交试验设计法：研究多因素多水平的一种设计方法，通过少数的试验替代全面试验，提高测试效率。

注:
如有想了解更多关于黑盒测试方法具体内容的可以去我前的一篇博客进行深入的了解: https://blog.csdn.net/m0_74105656/article/details/142360590?fromshare=blogdetail&sharetype=blogdetail&sharerId=142360590&sharerefer=PC&sharesource=m0_74105656&sharefrom=from_link

2.2 黑盒测试的优缺点

• 黑盒测试的优点:
  • 独立性：黑盒测试不需要了解软件系统的内部代码或结构，测试人员可以独立进行测试，不受开发人员的影响。
  • 用户角度：黑盒测试更加贴近用户的使用场景，能够模拟用户的行为，更容易发现用户体验方面的问题。
  • 全面性：通过黑盒测试可以测试软件系统的各个功能模块，并确保各个功能之间的交互正常，从而提高软件系统的整体质量。
  • 容错性：黑盒测试能够帮助发现软件系统中隐藏的潜在问题和异常情况，从而提前修复问题，保证软件的稳定性和可靠性。
  • 易于理解：黑盒测试案例通常基于需求规格和用户文档，易于理解和执行，既能帮助测试人员更好地理解软件功能，也方便其他项目成员了解测试情况。
• 黑盒测试的缺点:
  • 覆盖率较低：黑盒测试不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%左右，有些bug可能检测不出来。
  • 自动化测试的复用性较低：由于黑盒测试主要关注于软件的功能，而不是代码细节，因此自动化测试脚本的复用性可能较低。
  • 依赖需求规格说明书：黑盒测试直接依赖于需求规格说明书，如果需求规格说明书不全面或存在错误，得到的测试结果也可能不完善。

三. 灰盒测试

• 灰盒测试的定义: 它在对应用程序内部结构有部分了解的情况下对软件产品或应用程序进行测试。灰盒测试不仅关注输出、输入的正确性，同时也关注程序内部的情况，但不像白盒测试那样详细、完整地了解内部逻辑，而是基于部分内部知识和外部表现来设计测试用例。

3.1 灰盒测试常用的方法

• 确定程序的所有输入和输出：这是测试的基础，需要明确程序接收哪些输入，以及期望的输出结果。
• 确定程序所有状态：了解程序在不同操作下的状态变化，有助于设计更全面的测试用例。
• 确定程序主路径：识别程序的主要执行路径，确保这些路径被充分测试。
• 确定程序的功能：明确程序需要实现的具体功能，并设计测试用例来验证这些功能。
• 产生实验子功能的输入：针对程序的子功能，设计特定的输入数据。
• 制定验证子功能的输出：预期子功能在给定输入下的输出结果，以便验证其正确性。
• 执行测试用例：运行测试用例，观察程序的实际输出与预期输出是否一致。
• 检验测试用例的结果正确性：分析测试结果，确认程序是否按预期工作。
• 回归测试：在程序修改后重新执行测试用例，确保修改没有引入新的错误。

3.2 灰盒测试的优点与挑战

• 灰盒测试的优点:
  • 增强测试覆盖率：灰盒测试能够结合内部知识和外部表现，增加测试的全面性。
  • 便于bug定位：通过部分了解内部逻辑，灰盒测试可以更快地定位问题根源。
  • 提高测试效率：相比白盒测试，灰盒测试不需要深入了解所有代码细节，降低了测试复杂度。
• 灰盒测试的挑战:
  • 测试成本：灰盒测试可能需要更多的时间和资源，特别是对于复杂的系统。
  • 测试人员要求：灰盒测试要求测试人员具备一定的编程和系统设计知识，增加了学习成本。
  • 系统依赖性：灰盒测试依赖于对系统内部结构的部分了解，如果系统结构复杂或频繁变化，测试难度会增加。