可测试性：先测试再测试！

可测试性：时代的需要

“你在测试中节省的时间，就是你用于测试的时间。”

如果正在测试的软件是“可测试的”，就可以将这句话付诸实践。在本文中，我将阐述可测试性如何影响软件，以及如何在软件开发生命周期（SDLC）中将其纳入。

众所周知，随着软件技术的进步以及人类对软件应用程序日益增长的依赖，质量和可靠性正成为主要关注点，这促使必须进行有力的测试，以达到令人满意的软件质量和可靠性水平。然而，随着软件系统的复杂性不断增加，而测试资源仍然有限，这让我们陷入了一个两难的境地。因此，这使我们认识到，应该设计具有最佳可测试性的系统，以提高测试的影响力。软件可测试性是软件的一个外部属性，它评估软件测试的复杂性和所需工作量。

“软件可测试性”是一个非功能性需求，它告诉我们测试软件的容易程度。它应该被添加到软件中，以便能够彻底执行测试用例和测试脚本。正式地说，“软件系统或其组件能够建立测试标准并执行测试以得出这些标准是否已满足的程度”。

在许多情况下，“低软件可测试性”会缓慢地劣化软件，因为它可能不会立即被发现；测试人员在不知情的情况下，可能会找出错误的原因，并为处理问题推荐多种解决方案，如延长工作时间、分配更多资源、昂贵的自动化工具、基于风险的测试、更好的估算和计划等，而没有正确理解问题。这往往会加剧情况，因为真正的问题将无法集中解决。

软件可测试性是软件开发的前提，因为任何SDLC都包括需求收集、分析、设计、编码、测试、实现和维护。只有当正在开发的应用程序具有显著的可测试性时，才能确保测试脚本的完整执行。一旦应用了适当的测试覆盖率，大多数缺陷将在产品上线前被发现和修复，从而减少最终用户报告的问题。

任何软件产品的可测试性主要受两个要素的影响，即可控性和可观察性。

可控性是指在极端情况下为应用程序创建测试场景的难易程度。例如，在硬盘空间非常少的情况下测试应用程序的安装。

可观察性是指能够看到软件的UI和内部流程。当实际预期输出与预期相同时，但内部过程并非如需求所述时，缺陷通常会在其他流程中被识别出来。这对于单元测试和集成测试比黑盒测试更重要。

因此，可测试性成为SDLC初始阶段就需要解决的首要问题，并必须整合到每个阶段。这可以通过以下方式实现：

软件规格阶段

应要求测试团队审查文档，并进行讨论，以获得他们的意见并澄清他们对需求的理解。文档不仅应包含在正常条件下预期的行为，还应说明应用程序在异常条件下的行为。用例对于传达需求非常有帮助。还可以维护清单，以创建可以测试的各种场景。

详细设计阶段

此阶段通过预先说明预期输出来包含可测试性。设计人员将考虑在需求规格阶段准备的清单。数据流对测试人员应该是透明的，以便知道哪个场景调用哪个程序。正确的预期输出不能完全保证内部流程给出准确的结果。在此步骤中应为测试应用程序添加添加额外代码或接口的范围。

编码阶段

此阶段要求整合前面两个阶段中采取的可测试性方法。为此，需要添加额外的设计部分或算法，并使其也经过单元测试。为了使某些程序对用户和测试人员可观察，可以创建测试驱动程序，使测试人员能够在单元级别进行测试。应用程序应针对早期阶段发现的所有场景进行单元测试，包括应用程序应该如何以及不应该如何表现。

测试阶段

项目中先前阶段中采取的所有可测试性措施都应包含在此阶段设计的测试计划和测试脚本中。除了测试功能性和非功能性需求外，还应进行详尽的测试。任何不可访问的代码或功能都应使用其他方法进行测试。在此阶段，通过使用查询、桩和驱动程序进行集成测试，以及使用特定模块或组件的测试驱动程序来处理可测试性。

因此，可测试性是最被忽视的非功能性需求，如果在软件开发中不加以解决，可能会导致其他许多问题，这些问题可能会导致其他严重的问题，而这些问题并非实际问题的真正解决方案，并将我们困在一个可能每发布一次就恶化的恶性循环中。此外，可测试的产品更容易维护，因此成本更低，从而更容易获得客户满意度。因此，“可测试性对软件的可维护性至关重要”。