如何管理大量的自动化测试用例

Question

我们是一个由8名QA分析师组成的团队。我们已经为应用程序自动化了3,000多个测试用例。随着这个数字越来越大，我们已经创建了控制测试的问题，我认为我们有很多重复的测试用例。不仅重复，而且已经包含在另一个测试中的测试(测试X做测试Y已经做的加上其他事情)。

我想知道你们是如何管理测试用例的，避免重复或无用的测试用例。

我们使用的是TFS和，我们的测试使用Selenium实现自动化。

Answer 1

这个问题迟早会给每个人带来一个合适的应用程序。

为了帮助更干净地管理测试用例，您可以做一些事情：

• 使用一个自文档化系统--如果您使用C#编写Selenium代码，请使用MS注释和类似桑德堡之类的工具将生成的文档发布到公共站点。这样，团队中的每个人都可以在创建新的测试用例之前搜索所需的测试用例。
• 尝试在一个序列中将测试串在一起，而不是在另一个测试中包括额外的测试--我的意思是不是让测试A登录并执行操作X，而是测试A登录，测试B执行操作X(测试A已经成功完成的先决条件)等等。这确实在测试运行中引入了额外的依赖项，但它使您的测试代码库更加干燥。
• 为常见函数创建库例程--这包括用于登录、浏览应用程序等的库例程--本质上是应用程序中稳定的和/或已使用的库，您可以将实际测试集中在需要更密集检查的应用程序的各个方面。
• 评审和重构--您的自动化代码至少需要和产品代码一样多地被检查和重构，而定期的评审/重构将有助于定位和清除重复的测试和不必要的测试。

这些都解决不了你的问题。在保持测试的自制力和尽可能低的维护负荷之间，您总是会感到紧张。这些只是一些建议，以帮助您确定您希望在低维护(干代码)和自我包含的测试之间的平衡。

Answer 2

命名并分离出重用的部件(测试、地图关键字)。我称之为“普通”测试/地图。

1. 如果您已经有了大量的自动化测试，那么这将更加繁琐，但是提取您唯一的地图并适当地命名它们将识别正在重复测试的实际控件。
2. 遵循功能区域的测试命名约定，然后是测试的工作流程，以及映射的页面布局，可以让您快速轻松地识别哪些页面/控件是重叠的，哪些测试用例是重叠的。
3. 映射命名约定的关键字变量，这样您就可以看到哪些映射属于哪个页面，以及它们是否被大量重用，或者它们是否只存在于该页面上。无论哪种方式，对于一个在整个站点上都重复的控件有一个关键字，但是维护相同的映射值，您就可以将其附加到一个存在于单个位置的关键字变量上，并且您对该地图的维护将被几乎消除。

在你做完上面的事情之后，下面的事情应该是可能的，这将使你的生活变得更容易。

1. 重叠的测试用例步骤被取出来，形成新的“测试用例”或函数。然后，前面的测试将在测试调用中执行这些步骤，而不是前面的步骤。类似于MTM的“共享步骤”。在selenium术语中，这些常见的测试变成了常规函数，它们被调用并执行一组步骤，而不是作为测试本身存在。
2. 关键字与测试排列在一起，以便将功能工作流降到应用程序中测试内容的功能控制视图。关键字在使用它们的地方被分组，希望这对于现在的测试用例来说是唯一的。通常重用的控件很可能在第1项中的常见测试用例中。

这将减少您的维护头痛，并允许您非常容易的规模。您的报告还将与您的命名结构保持一致，这样您将能够看到问题区域更容易解决的地方。当测试失败时，您将能够将其跟踪到一个控件，该控件此时应该存在于一个单独的位置，一旦更正，您的所有测试都将再次通过。

这不是一个快速的过程，但代价是保持未来。我还有一个自动化测试的自定义报告，我可以总结功能区域，深入分析各个控制问题，并看到每个步骤的确切错误，但这取决于您需要什么，什么对您的团队有用。

Answer 3

你可能是在解决症状而不是根本原因？

1. 你有用户故事吗?它们是否在某个工具中被管理？
2. 您有每个用户故事的验收标准吗？
3. 你是否将验收标准正规化为测试用例？
4. 您是否将每个自动测试“链接”到其相应的测试用例？

如果您可以回答所有问题，那么您所需要做的就是管理您的用户案例和测试用例。测试用例不太可能落入两个不同的用户故事中，如果是这样的话，可能有一个合理的理由。

此外，处理用户故事和测试用例的工具通常准备得更充分，以处理这些信息，因此您应该能够非常容易地查询副本等。

如果你对某些问题的回答是否定的，那么我会说这是你问题的根本原因。

这一办法的其他好处：

1. 您测试一些不重要的东西的可能性会大大降低，因为您只测试产品负责人和团队决定的内容是很重要的。
2. 代码中自动化测试的文档现在只是包含到测试用例的一些链接。
3. 任何业务人员都可以轻松地检查您的测试用例，并放弃/改进它们。

*如果您不使用敏捷过程，您可以用需求或其他东西替换User Story。