作为测试人员，我们始终在寻找各种能帮助我们增强测试能力的工具。我们通常使用的工具主要是缺陷跟踪工具、对产品进行探索性测试以及文档。虽然这些工具非常重要，但如果我们通过探索开发活动来获得新的视角会怎样呢？这样做对我们如何更有效地调整测试工作会有所帮助吗？为了探索这个问题，我深入研究了Git日志，并发现了对我们的测试工作非常有益的见解。虽然Git日志主要是开发人员的领域，但它们对测试人员来说也提供了有价值的信息，从了解最常修改的文件到评估提交的频率和大小等等。
使用Pydriller和GitHub API，我构建了一个分析任何Git存储库的框架。输出结果提供了有意义的推断，揭示了开发模式的一些特征。在本博客文章中，我将分享我和我在Qxf2的同事们合作开发这些Git日志分析的经验。
此工作的代码可在此GitHub存储库中找到：https://github.com/qxf2/gitlog-insights
为什么要使用Git日志？
Git日志记录了存储库中的所有更改，为测试团队提供了深入了解开发过程的机会。为了使这些数据能够产生实际效果，测试人员需要关键的细节。我们为测试团队建立了一些视角，可以帮助他们实现这一目标。这些视角包括了解经常更改的文件、Pull Request审查时间的模式、作者贡献和合并活动等。它们提供了对开发情况的全面了解，使测试人员能够优先考虑测试工作、改进测试用例的编写、改进与开发人员的沟通，并为代码质量提供有价值的反馈。下面的章节将展示这些视角。
Git日志分析的视角
在建立这些视角时，我们尽力关注从中可以得出的推断。除了显示报告之外，我们相信提供一两句的简要摘要可以帮助测试人员工作。
为了获得分析视角下的结论，每次分析都需要提供开始日期、结束日期和要分析的GitHub存储库。本文使用 Qxf2的页面对象模型框架（https://github.com/qxf2/qxf2-page-object-model） 这个项目作为分析的示例仓库。
1. 最常修改的文件：识别经常变动的代码区域
最常修改的文件提供了对存储库中最活跃修改的区域的见解。识别这些文件对于认识频繁的代码更改非常重要，这些更改通常突显出需求中的关键功能或特性。对于测试人员来说，这些信息是一种指南，使他们能够优先考虑测试工作，并在开发过程中最关键的领域进行全面覆盖。
让我分享一下我的经验。我曾与一家初创公司合作，帮助他们启动自动化之旅。我的初始策略是进行探索性测试和缺陷跟踪。然而，了解开发活动将会很有帮助。利用最常修改的文件的信息，我可以优先考虑自动化模块的开发，因为这些模块在不断演化。专注于这些动态变化的部分不仅可以早期发现缺陷，而且还可以确保随着应用程序的演变，自动化测试的长期效果。这种亲身经历突出了最常修改的文件见解对于测试人员的实际影响和重要性。
这是以Qxf2的页面对象模型框架为例的运行结果：
这张图片显示了Git日志分析获得的最常修改的文件
从输出结果中可以看出，’Base_Page.py’既具有较高的复杂性，也经常被修改。它频繁的修改和较高的复杂性表明它在代码库中的重要性。这可以作为一个很好的起点，特别是在像我们之前讨论的构建自动化框架的情况下。
2. PR审查时间：理解开发速度
PR审查时间提供了Pull-Request的平均持续时间。对于测试人员来说，可以据此调整测试工作，因为它有助于理解开发速度。例如，了解审查所花费的平均时间可以帮助测试人员有效规划测试工作，确保与代码更改的速度保持一致。它还有助于预测新功能或修复何时可能准备好进行测试，促进开发和测试团队之间更好的协调。另一方面，延长的审查时间直接影响测试计划。测试人员可以预见到在接收新功能或修复进行测试时可能出现的延迟，从而能够相应调整测试计划。这种积极主动的方法可以避免不切实际的测试期望，并帮助更有效地管理利益相关者的时间表。
这是运行结果：
这张图片显示了对PR审查时间进行Git日志分析的结论。
例如，假设一个新的测试人员加入团队。当他们熟悉开发环境时，了解PR审查时间可以帮助他们了解团队的代码审查和部署节奏。例如，如果PR审查时间始终显示快速高效的审查，新的测试人员可以积极准备即将到来的测试周期，知道功能和修复很可能会及时准备好。
3. 贡献者偏差：识别代码贡献模式
贡献者偏差用来分析文件中贡献的分布情况，以贡献熵进行量化。较高的值表示贡献分布均匀，而较低的值则意味着集中在一个或几个作者之间。这种分析揭示了开发团队中潜在的模式，提供了关于代码贡献和作者动态的见解。
具有较高贡献者偏差的文件可能表明合作范围有限。测试人员可以在其能力范围内强调集体理解的重要性，例如在团队会议期间发起讨论或知识共享会议。此外，在人员流失的情况下，集中的贡献可能导致团队成员离开时面临挑战。测试人员可以预见到理解和文档方面的潜在差距，并促进积极的方法来记录关键代码区域，并确保在团队变动期间过渡更加顺畅。
为了计算贡献熵，我参考了这篇论文：https://ieeexplore.ieee.org/document/5069484
这张图片显示了对贡献熵向进行Git日志分析的结果。
测试人员可以将这些文件视为感兴趣的潜在点，表明特定作者在这些部分持续贡献的可能性较高。虽然输出中可能没有直接的作者详细信息，但测试人员可以探索这些文件，了解它们的复杂性、潜在风险以及是否需要协作努力进行全面测试。这种方法使测试人员能够积极应对与代码理解、知识分发和潜在协作需求相关的挑战。
4. PR的规模：评估代码更改的影响和复杂性
PR的规模提供了对一定时间内引入的更改数量的详细分析。需要注意的是，更改的行数并不直接表示复杂性，但它作为一个有价值的指标，可以帮助测试人员评估修改的规模。例如，更改行数较多的PR可能涉及广泛的修改。
了解PR的规模可以让测试人员对所需的潜在测试工作做出明智的决策。测试人员可以识别PR规模的趋势和模式，帮助他们评估对测试时间表的影响，并相应地规划测试策略。更小的PR快速更改可能表明开发周期快速，需要快速的测试反馈。另一方面，较少但规模较大的PR可能使测试人员采用更全面的测试方法。这种对齐确保了测试人员的速度与整体开发节奏相匹配。
这是运行结果：
这张图片显示了对PR规模的Git日志分析的结果。
因此，作为测试人员，这样的信息可以帮助他们相应地调整测试方法。较大的PR可能引入更广泛的修改，需要进行全面和细致的测试。并相应地帮助测试人员有效分配资源，根据代码修改的规模和复杂性确保有效的测试覆盖范围。
5. 合并活动：了解代码合并的节奏
合并活动提供了在给定时间范围内代码合并最活跃的日期信息，提供了对开发工作流程中代码集成的频率和时机的见解。虽然这不是改变游戏规则的见解，但它为测试人员提供了对开发节奏的基本了解。它帮助测试人员预见代码更改的潜在高峰，促进与开发人员的更顺畅协作，并进行更明智的资源规划。
这张图片显示了合并活动的分析结果。
例如，如果每个星期五都有增加的合并活动，测试人员可以在这些日子分配更多的测试资源，以确保及时验证新的代码更改。这是一个微妙的见解，可以帮助优化测试工作，以与团队的工作模式相一致。
高管可以利用合并活动的见解来对团队的生产力趋势有一个全面的了解。例如，观察到特定日子合并活动持续增加，可能会促使高管相应地调整发布周期或团队会议，促进更流畅的开发流程。
结论
总结一下，从Git日志分析中得出的见解为开发动态提供了宝贵的洞察，为测试人员提供了实用信息来优化他们的测试方法。虽然并非具有革命性的改变，但这些见解使测试人员具备了适应策略的意识。从基于经常修改的文件优先进行测试工作，到预见理解代码贡献方面的挑战，测试人员可以利用这些见解更高效地应对不断变化的代码库。无论是识别协作机会，减轻与知识分发相关的风险，还是了解代码更改的范围，这些见解都是测试人员的实用工具，旨在将他们的工作与开发的脉搏保持一致。虽然并非万能之策，但它们无疑有助于形成更明智、更积极主动的测试心态，帮助测试人员履行日常的职责。
