什么是软件可测试性？
不是每个应用程序都可以测试吗？很可能是，但基于系统设计和架构，进行测试和发现bug实际上可能更容易或更困难。
有很多方法可以定义可测试性。在最基本的层面上，可测试性考虑了软件测试的难易程度。查看可测试性的另一种方法是测试暴露应用程序中错误的可能性。
有时，不管你运行了多少测试，应用程序的覆盖范围有多大，bug似乎仍然会悄悄地传到客户那里。
这样，可测试性是开发、产品和测试团队之间有效沟通的产物。在创建功能时考虑的测试能力越多，其他团队成员在此阶段要求测试人员的输入越多，测试就会越有效。
影响可测性的因素有很多，并且没有好的方法来给出精确的度量，但是对被测系统的了解越多，测试就越直接，结果对整个团队就越有价值。
为什么可测试性很重要？
提出一个软件可测试性的例子，并提倡它如何影响最终产品，意味着在产品进行测试之前的关键阶段，如规划、设计和代码评审，将更多地考虑这个想法。
可测试性是在设计和开发阶段确定的，但对于其他需求（如可用性和功能性），它常常被忽略，因为应用程序通常是为用户而不是为QA团队构建的。
然而，创建一个高度可测试的应用程序最终也会让用户受益。可测试性影响可交付性。当测试人员更容易定位问题时，就可以更快地对其进行调试，并且应用程序能够更快地到达用户手中，并且没有隐藏的故障。此外，可测试性也将有助于产品和开发团队。通过具有更高的可测试性，这些团队将受益于更快的反馈，这将允许更频繁的修复和迭代。
在软件开发的生命周期中，我们经常谈到更快地考虑质量。而不是等到测试，拥有一个完整的团队方法来实现可测试性意味着在规划、设计和开发过程中对应用程序给予周到的考虑。这包括强调多个方面，如文档、日志和需求。测试人员对产品或特性、其用途和预期行为的了解越多，他们的测试和测试结果就越有价值。
可测试性与自动化能力
有时在考虑可测试性时，我们可能会将其与自动化能力或“自动化”混淆。相反，自动化能力会询问多次运行测试是否有好处。虽然这两者肯定是相关的，并且可能会相互影响，但有些东西可能是高度可测试的，但不是测试自动化的好候选对象，反之亦然。
当我们谈论软件测试和可测试性时，我们关心的是人类在测试期间能够从应用程序中获得哪些新信息。在将测试包含在自动化套件中之前，确定测试的优先级以及自动化测试的价值是很重要的。仅仅因为在自动化测试之后收到了“通过”或“失败”，并不意味着这些信息对团队是有价值的。此外，有些测试可能很难或不可能自动化。
在花时间在自动化套件中创建和维护测试之前，了解自动化是否适合某个测试是很重要的。然而，退一步并首先确定应用程序的可测试性也很重要。虽然可测试性通常会告知测试是否自动化，但团队可能会犯跳过可测试性而直接转到自动化或自动化的错误。
为可测试性腾出时间
测试的核心是验证某些东西是否有效。然而，许多事情会干扰测试的有效性——需求、条件、环境、工具、知识、数据、文档。
虽然可测试性对每个团队来说可能意味着不同的东西，但重要的是确定哪些措施将帮助组织改进反馈和功能发布。
此外，虽然“可测试性”一词可能暗示这是QA 团队的工作，但实际情况是，可测试性是整个团队的质量方法，需要在发布之前、期间和之后进行考虑。
当我们讨论左移并在软件开发生命周期中更快地将质量作为优先事项时，可测试性应该成为对话的一部分。通过将应用程序设计为固有的可测试性，发布功能强大的高质量应用程序的障碍就会减少。
演示工具：www.eolinker.com