用于测试具有多个分支的大型项目的过程和工具

时间:2009-09-22 21:17:18

标签: branch qa

我们利用大量的分支(相当传统的主线模型)进行开发,并且它被证明是非常有效的组织事物和保持开发人员在大型团队中的效率。我们有QA测试开发分支,然后再将它们推回主线,这确保了主线始终稳定。

现在有一些与测试有关的有趣问题。最常见的是:假设测试人员在测试期间遇到错误,已经标记为已修复。是因为修复失败了(在这种情况下他们应该重新打开错误),还是因为修复程序没有到达正在测试的分支?

作为强制用户,我们正在寻求通过perforce工作来解决这些问题。它虽然是一个非常“原始”的工具 - 它或多或少地为此提供了底层功能,但不是一个简单的界面,特别是对于测试人员来说。所以我想知道是否有更多用户友好的方法,或完全不同的方法(我不认为“避免分支”在这种情况下是我们的实际答案!)

在多个分支机构执行有效质量检查的最佳做法是什么?是否有任何好的工具可以为这些问题提供自动化和支持?

2 个答案:

答案 0 :(得分:1)

有时在开发分支上进行一次测试,并在合并到发布分支后再次进行测试。但这是一个过程选择,而不是一个要求。

如果您只从“主线”分支发布,则可以考虑更改QA流程,以便仅在将更改合并到发布分支后进行测试。并依赖开发人员在合并前/后测试他们的更改。这更典型。

根据你现在所拥有的,听起来每个开发人员可能有一个分支(只是一个猜测)。并且您针对每个开发分支提交错误。我会认真考虑改变这个过程。它不可维护,并且在合并后跟踪错误将非常具有挑战性。

正如TrueWill建议的那样,建立持续集成将是一个好主意。补充频繁(每日)构建。然后让QA测试构建。

答案 1 :(得分:0)

如果qa在主分支中找到bug,并且它在dev分支中修复,那么:

  • 让qa检查它是否已在dev分支中修复
  • 让qa评论主分支中的bug,但保持打开
  • 修复后发布到主分支,以免再次测试它的主分支
  • 如果修复将其修复为主分支中的主要关闭错误。

至于其他情况,尝试这样的锻炼场景(这里你有一段bug生命周期)。准备何时测试和测试什么的场景,通信qa-dev应该如何。写下一切。那将是你的测试过程。让QA遵循它(并在适当的时候开发)。可能你不会马上完成所有情况,所以要随着时间的推移改进你的过程。

大型多分支项目。也许考虑聘请测试经理/测试负责人/或任何你想称之为角色的人。谁将管理qa工作。准备测试策略。准备测试计划。与开发团队协调qa工作。确保正确沟通。此外,这个人可以管理不同分支机构之间的QA工作。 在具有并行分支的大型复杂项目中,qa需要良好的管理(与其他人一样)。

至于工具可能很少,但我只使用HP Quality Center和HP Quick Test Pro。 QTP是测试自动化软件(记录和回放,数据驱动,脚本化 - VB)。 QC是测试的存储库(手动和自动),缺陷,也可以保存需求,测试结果。它可以跟踪需求测试覆盖率和测试缺陷链接(实际测试运行缺陷,但您可以从测试运行跳转到测试)。
此外,您可以在其中定义Cycles和Releases,例如,它可以是Cycle per branch和Release per code release(每个Release与给定的Cycle相关,因此可以清楚地发布了哪个分支代码)。或者你可以用不同的方式映射它 问题是,该软件需要花钱。我的意思是真钱。这是一种承诺。