PDF软件沙箱筛选：SCM 遇上 QA
源代码控制——不再仅仅用于跟踪更改。
WILLIAM W. WHITE，PERFORCE SOFTWARE
得益于现代 SCM（软件配置管理）系统，当开发人员在代码行上工作时，他们会留下一系列线索，可以揭示代码的哪些部分已被修改、何时、如何以及由谁修改。从 QA（质量保证）和测试工程师的角度来看，这一切仅仅是“数据”，还是存在可以提高测试覆盖率和产品整体质量的有用信息？
照常测试
测试和 QA 工程师在评估软件产品时，可以使用各种工具。他们可以使用功能规范和用户手册来制定测试计划；设计规范和与开发人员的访谈可以提供开发功能测试所需的信息；脚本工具可用于自动化执行某些测试；代码覆盖率工具可以用来识别测试程序中的漏洞。然而，在编写测试计划并开发和执行基本测试套件之后，仍有许多工作要做。
测试计划和自动化测试套件在一定程度上保证了软件产品旨在提供的功能是存在且按预期运行的。随着产品的增长和发展，这些工具也可以相应地发展，以包含针对新增或修改功能的附加用例。在产品的整个生命周期中，它们对于防止回归（将缺陷引入先前版本中运行正常的功能）也至关重要。
然而，回归错误相对较少，而且一旦产品发布，测试计划和自动化测试套件仅偶尔会发现错误。更重要的是，这些工具无助于测试人员了解错误可能发生的位置，也无助于 QA 工程师对即将发布的产品质量做出实际评估。幸运的是，还有其他工具可以提供帮助。
缺陷跟踪器
几十年来，软件开发人员一直使用缺陷跟踪工具来管理有关已知错误和产品改进请求的信息。几乎所有此类工具都包含用于识别每个问题的性质和严重程度的字段，以及诸如何时记录和何时修复的信息。这些最基本的信息足以让测试人员和 QA 工程师在评估产品质量时获得强大的杠杆作用。
关于测试，此信息最基本用途是验证报告已修复的错误是否真的已修复。这通常通过生成一个项目列表来完成，这些项目的“已修复”或“已关闭”日期在指定的范围内——例如，在前一个版本发布之后，但在待发布版本的代码冻结之前。然后，测试人员可以浏览该列表，按照每个问题描述中的重现步骤进行操作。对于每个项目，如果问题不再出现，则测试人员将其勾选并继续下一个；如果问题仍然存在，则重新打开该项目并采取纠正措施。
除了错误修复之外，产品更新通常会引入新功能——有时会引入新的错误。为了防止这种可能性，产品在发布前会经历一个密集的测试期，以“消除”开发阶段引入的任何问题。在此期间出现大量错误并不罕见。
尽管 QA 人员会注意发现的错误总数，但一个可能更有意义的观察结果是这些错误的报告速率。在图 1 所示的典型情况下，在预发布测试期的最初几天内“弹出”了相对大量的错误，并且随着该时期临近其计划结束，该数量逐渐减少。显示不同模式的趋势——例如，错误率保持在高位，或从低位开始——可能表明产品或测试过程存在问题，并可能需要延迟发布，以便进行更多测试和修复错误。
产品发布后，缺陷跟踪系统中的信息可以以多种方式用于评估正在进行的维护工作的质量。例如，有理由期望客户遇到的严重软件问题能够得到及时纠正。一种简单的了解这种情况是否正在发生的方法是将每周报告的新错误数量与同期修复的错误数量进行绘制，如图 2 所示。理想情况下，趋势将显示修复率非常紧密地跟随新报告的错误率，特别是对于高优先级问题。另请注意，此图中显示的总体趋势应反映预发布测试期间绘制的趋势：随着产品的成熟，您应该期望从现场报告的新错误会减少。
可以从缺陷跟踪系统中信息的分析中获得任意数量的其他指标。（有关其他示例，请参阅 Stephen Kan 的《软件质量工程中的度量和模型》，Addison-Wesley Professional，1995 年。）然而，总的来说，这些工具受到其应用于软件的“黑盒”视角的限制。虽然计算报告的问题数量可能很容易，并且该工具可能允许您在报告中包含有关错误发生的特定模块的信息，但大多数缺陷跟踪工具无法识别源代码中发生故障的确切位置。这意味着测试人员在尝试确定错误是否影响了其他功能时，需要依赖直觉和对产品内部结构的了解。由于错误的影响有时可能很广泛，并且可能在远离最初观察到它们的位置浮出水面，因此从典型的缺陷跟踪应用程序获得的信息可能不足以用作测试指南。
第一代 SCM 工具：离散的按文件更改跟踪
与缺陷跟踪系统的情况一样，自 20 世纪 70 年代以来，开发人员一直使用工具来管理对源代码所做的更改。这些工具的重点在于它们对开发和维护代码的程序员的有用性，但测试和 QA 专业人员也从中受益。
如果测试人员可以访问产品的完整存档文件，并且他们愿意并且能够深入研究并开发提取和汇总相关数据所需的脚本，则可以从简单的按文件跟踪系统（如 RCS（版本控制系统）或 CVS（并发版本系统））中挖掘与 QA 相关的信息。这项工作还需要对源代码有一定程度的熟悉，这可能超出许多经理或测试人员的舒适区。更重要的是，所需的源代码存档访问权限程度可能会给许多软件公司的管理人员的舒适度带来压力。
例如，QA 工程师可以从 RCS 中收集到的信息类型是对代码行波动性的非常粗略的衡量。这可以通过计算上次客户交付和最近一次构建之间发生的文件更改次数来获得。如果上次客户交付是在 2004 年 8 月 1 日，而最近的候选发布版本构建是在 9 月 22 日完成的，则如下所示的 shell 命令将告诉您有多少更改影响了当前目录中的文件
% rlog -d”2004-08-01<2004-09-22” *,v | grep ^revision | wc
405 810 5556
在此示例中，您可以看到在 8 月 1 日至 9 月 22 日期间，在当前目录中提交了 405 个更改。这并没有告诉您更改的范围有多大，但至少确实为您提供了一个可供工作的硬性事实。
除了更改的复杂性之外，405 是一个大数字还是一个小数字？在源代码树的每个目录中运行相同的命令将为您提供部分答案——任何更改数量较多的目录都将引起关注。其余答案在于每个目录中有多少文件受源代码控制，以及每个目录中的文件数与更改提交数之间的关系。修改多次的文件预计不如修改次数少的文件可靠。
例如，如果整个源代码树中更改提交与文件的平均比率结果为 3:1，但您的某个目录的比率为 20:1，那么与该目录关联的产品模块将是查找新引入错误的好地方。同样，如果一个目录有 200 个记录的更改，而其他目录的平均更改数为 10 个，那么即使该目录包含大量文件，并且更改与文件的比率相对较低，该目录也值得仔细检查。
手动执行 RCS 命令并进行数学运算并不困难，但对于具有大型复杂源代码树的典型软件产品来说，这将是乏味且耗时的。幸运的是，编写脚本来处理大部分工作很简单，并且可以编写更复杂的脚本来处理所有信息并将结果汇总在类似于图 3 所示的表格中。在测试中，应强调与图 3 中的目录 sub1 关联的产品模块，因为那里的更改提交数量很多。还应强调与 sub3 关联的模块，因为每个文件的更改次数很多。
下一代 SCM 工具：变更集和变更通知
现代 SCM 系统包含其他功能，这些功能对参与测试和 QA 的人员可能很有用。其中之一是能够将一组文件更改分组并作为单个实体提交。这些组通常称为变更集或变更列表。另一个有用的功能是能够在指定源代码树的某些部分发生更改时请求通知。
变更列表对开发人员和移植工程师具有明显的价值，例如，他们可能希望在新平台上实施错误修复或撤消结果证明具有不良副作用的更改，因为它允许他们立即查看受更改影响的完整文件集。它们还具有显着优势，即提供了一个单一、显而易见的位置，可以在其中记录更改的完整描述——无需为每个涉及的文件复制此信息，也无需建立每个开发人员都必须遵循的正式程序，以确保下游人员能够找到所有相关信息。
事实证明，输入到变更列表中的描述对于集中测试工作非常有用，尤其是在产品发布前的几周内——当然，前提是提交更改的开发人员在描述更改时相当彻底。
例如，自产品上一个版本发布以来所做的所有更改的描述的简单列表，可以相当于即将发布的版本的系统生成的测试计划，如图 4 所示。它将是不完善的，其组织将是纯粹按时间顺序排列的，并且它可能包含大量在测试上下文中不是特别有用的信息。尽管如此，有耐心的测试人员可以筛选这些数据，并清楚地了解已更改的内容以及需要特别注意的内容。结合一组回归测试来捕获最近更改的任何不利副作用，这是一个强大的工具。
同样，自动变更通知可以立即提醒相关方可能影响他们自己工作的代码更改。它可以让主管实时监控对代码所做的更新，并且可以在产品中出现新功能或错误修复并准备好进行测试时立即告知测试人员和 QA 工程师。
一些现代 SCM 系统要么包含缺陷跟踪器，要么允许您集成第三方产品（如 Bugzilla），或两者兼而有之。集成的缺陷跟踪系统可以自动将错误修复与更改描述相关联。这允许您立即将错误报告（通常从客户的角度编写）与开发人员对底层问题的描述以及为纠正问题而采取的步骤进行比较。包含变更通知并将错误报告与变更列表关联的系统可让您立即知道您感兴趣的问题的状态何时更新。它还允许您放大更改的详细信息，甚至可以检查对受其影响的每个文件所做的确切编码修改。这种功能组合可以让测试人员及时了解产品中发生的错误修复、新功能实现以及任何其他更改。
未来展望？
SCM 系统已经发展了几十年，它们收集和存储与更改相关数据的能力令人印象深刻。然而，直到最近，大多数系统都依赖命令行界面将该信息传达给用户。在很大程度上，这对于开发人员来说已经足够了，他们往往对有关特定文件或更改的非常详细的信息感兴趣，但这意味着诸如 QA 之类的组织，需要通过分析和汇总信息来突出显示趋势，因此被迫开发调用命令行界面的脚本，收集其发出的原始数据，并对其进行迭代。一旦以这种方式消化数据，最终结果就可以格式化为表格或图表，以传达数据背后的含义。电子表格或 Crystal Reports 等第三方工具通常用于此目的。
好消息是，SCM 解决方案提供商越来越多地为其产品提供 GUI 界面。有些是基于 Web 的，有些使用标准的 Windows 协议，还有一些使用第三方库（如 Trolltech 的 Qt）或跨平台编程工具（如 Java 语言及其图形扩展）来生成可在各种平台上运行的应用程序，同时保留适合其支持的每个操作系统的外观和感觉。无论其实现方式如何，这些界面都通过消除开发人员学习一套神秘的新命令的要求来提高软件开发人员的生产力。相反，开发人员只需点击即可浏览其源代码、检出和编辑文件、提交更改、比较文件和文件夹修订以及执行与完成工作相关的所有标准操作。这些界面对开发人员很有用，但它们对 QA 和测试人员来说更有希望。
SCM 和缺陷跟踪系统存储大量关于软件产品的状态和更改历史的数据。例如，计算缺陷到达和修复模式所需的所有信息都可以在许多 SCM 数据存储中找到，并且这些信息一旦提取和汇总，就可以作为衡量软件维护团队有效性的有用指标。
现在，提取和汇总这些数据涉及运行一组脚本，这些脚本调用 SCM 系统的命令行界面来计算在指定时间段内报告的错误数量，然后计算在同一时间段内提交的错误修复数量。当收集一系列时间间隔的总数并在表格或图表中汇总时，软件团队对报告问题的响应能力就会清晰地显现出来。请注意，这些信息可以按离散时间间隔绘制，如图 2 所示，或者更常见的是，按在较长时间段内报告和修复的错误累积数量绘制，如图 5 所示。您可以根据错误的严重程度进一步细化信息，因为您希望看到对更严重的错误立即做出响应，而不太严重的错误可能会推迟到后续产品版本发布。
这足够好吗？SCM 和缺陷跟踪系统提供了收集、存储和提取进行此类测量所需信息的方法，一旦编写了脚本，运行它们就非常简单了。甚至可以安排它们每晚或每周自动运行，也许结果会发布在内部网页上。
然而，SCM 系统中 GUI 的出现，增加了脚本、计划和手动流程可以被搁置一边，转而支持实时、可配置的按需报告的可能性。高层管理人员可能仍然需要定期的、定期安排的摘要，但一线 QA 工程师和一线经理通常想知道，“我们现在做得怎么样？”由于生成这些报告所需的所有数据都直接可供 SCM 系统使用，因此图形界面可以随时以任何所需的形式提供此信息，这将非常容易。
强大的武器——变得更加强大
借助现代 SCM 和缺陷跟踪系统，QA 和测试工程师拥有强大的武器来增强测试计划、脚本和代码覆盖率工具，他们传统上依靠这些工具来确保软件产品的质量。他们现在可以在他们监控的错误的状态更新或更改提交到他们关心的源代码树的一部分时立即收到自动通知。
一旦提取和汇总，这些信息可以告诉 QA 工程师或产品经理很多关于软件产品的状态、稳定性和质量的信息，并且对于回答最终问题非常宝贵：它准备好发布了吗？然而，从 SCM 系统中提取和汇总信息仍然是劳动密集型的。例如，考虑尝试确定缺陷到达和修复模式，或测量代码行、产品或源代码树的特定子集中的缺陷密度或相对波动性。此过程将要求 QA 工程师开发、部署和维护与 SCM 系统和/或缺陷跟踪工具结合使用的自定义脚本。
向 SCM 和缺陷跟踪系统添加 GUI 可能会改变这一切。首次，从仅跟踪缺陷的系统转向提供实时缺陷和质量分析的系统可能变得可行。想象一下，如果您可以单击 GUI 上的一个按钮，看到一个帕累托图，突出显示源代码树中报告缺陷数量最多的区域，或者如果您可以立即查看一个图表，显示产品、产品内的子系统或源代码树的任意子集的缺陷报告和修复趋势，那么您在测试待发布版本时可以发挥多大的作用。或者想象一下，如果您可以从上下文菜单中选择一个选项，并立即看到代码某部分的缺陷密度度量。
SCM 系统中面向 QA 的功能的未来仍在定义中，但大部分数据已经存在，并且通过图形界面利用这些数据的可能性令人兴奋。
WILLIAM W. WHITE 拥有超过 20 年的应用设计师和开发人员、软件工程师、QA 工程师和作家的经验。他目前在 Perforce Software 管理 QA 部门。
最初发表于 Queue 第 3 卷，第 1 期—
在 数字图书馆 中评论本文
更多相关文章
Sanjay Sha - 企业应用程序的可靠性
企业可靠性是一门学科，它确保应用程序将以一致、可预测且经济高效的方式交付所需的业务功能，而不会损害可用性、性能和可维护性等核心方面。本文介绍了一套企业可以应用的核心原则和工程方法，以帮助他们驾驭企业可靠性的复杂环境，并交付高度可靠且经济高效的应用程序。
Robert Guo - MongoDB 的 JavaScript Fuzzer
随着 MongoDB 随着时间的推移变得更加功能丰富和复杂，开发更复杂的方法来查找错误的需求也随之增长。三年前，MongDB 将自研的 JavaScript fuzzer 添加到其工具包中，它现在是我们最高产的错误查找工具，在两个发布周期中负责检测到近 200 个错误。这些错误跨越了从分片到存储引擎的各种 MongoDB 组件，症状范围从死锁到数据不一致。fuzzer 作为 CI（持续集成）系统的一部分运行，它经常捕获新提交代码中的错误。
Robert V. Binder, Bruno Legeard, Anne Kramer - 基于模型的测试：它处于什么位置？
您可能听说过 MBT（基于模型的测试），但与许多未使用过 MBT 的软件工程专业人员一样，您可能对其他人使用这种测试设计方法的经验感到好奇。从 2014 年 6 月中旬到 2014 年 8 月初，我们进行了一项调查，以了解 MBT 用户如何看待其效率和有效性。2014 年 MBT 用户调查是对 2012 年类似调查的后续调查，向所有评估或使用过任何 MBT 方法的人开放。它的 32 个问题包括 2013 年高级自动化测试用户会议上分发的调查中的一些问题。一些问题侧重于 MBT 的效率和有效性，提供了管理者最感兴趣的数字。
Terry Coatta, Michael Donat, Jafar Husain - EA 的自动化 QA 测试：事件驱动
对于数百万游戏发烧友来说，在 Electronic Arts 担任 QA（质量保证）测试员的职位一定像梦寐以求的工作。但从公司的角度来看，与 QA 相关的开销可能看起来非常可怕，尤其是在大型多人游戏时代。
© 保留所有权利。