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

#1 楼

这个问题迟早会给使用大小合适的应用程序的每个人带来打击。

您可以采取一些措施来更干净地管理测试用例：



使用自记录系统-如果您愿意，用C＃重新编码Selenium，使用MS XML注释和诸如Sandcastle之类的东西将在生成时生成的文档发布到一个公共站点。这样，团队中的每个人都可以在创建新测试用例之前搜索满足其需求的测试用例。

尝试按顺序将测试串在一起，而不是在其他测试中包含额外内容-我的意思是而不是测试A登录并执行操作X，而是已经测试A登录，测试B执行操作X（前提是必须成功完成测试A），依此类推。这确实会在测试运行中引入额外的依赖关系，但会使测试代码库更加干燥。

为常见功能创建库例程-其中包括用于登录，在应用程序中导航的库例程，等等。 -基本上所有在应用程序中稳定和/或使用过的东西都变成了库，您将实际测试集中在需要更深入检查的应用程序方面。

查看和重构-您的自动化代码需要至少与生产代码一样要进行审查和重构，并且定期进行审查/重构将有助于查找和清除重复项和不必要的测试。

这些都不能解决您的问题。在保持测试自成体系和保持尽可能低的维护成本之间，您总是会遇到压力。这些只是一些建议，可帮助您确定希望在较低维护成本（DRY代码）和独立测试之间取得平衡的地方。

#2 楼

命名并分离出重复使用的零件（测试，地图关键字）。我将其称为“常见”测试/地图。


如果您已经有很多自动化的测试，那么这会比较乏味，但是拔出您的唯一地图并适当命名它们将识别出进行重复测试的实际控件。
遵循功能区域的测试命名约定，然后是测试的工作流程以及地图的页面布局，可以使您快速轻松地识别哪些页面/控件也重叠地图命名约定的关键字变量，这样您就可以查看哪些地图属于哪些页面，以及它们是否被大量重用，或者它们是否真正存在于该页面上。不管是哪种方式，都可以为整个站点重复使用一个控件的单个关键字，但是保持相同的映射值，这将允许您附加到存在于单个位置的关键字变量，从而实际上消除了对该映射的维护。 br />
完成上述操作后，应有可能使生活变得更加轻松。


删除了重叠的测试用例步骤，并形成了新的“测试”案例”或功能。然后，先前的测试将在测试调用中执行这些步骤，而不是先前的步骤。与MTM“共享步骤”类似的想法。用硒的术语来说，这些通用测试成为常规函数，它们被调用并执行一组步骤，而不是作为自身的测试而存在。
关键字与测试对齐，以使功能工作流程简化为功能控制视图应用程序中正在测试的内容。关键字在使用它们的位置分组，希望现在对于测试用例是唯一的。经常重用的控件很可能会出现在第1项的常见测试用例中。

这将减轻您的维护麻烦，并使您轻松扩展。您的报告也将与您的命名结构保持一致，因此您将能够查看问题区域的位置。如果测试失败，您将可以将其跟踪到一个控件，该控件应该在单个位置存在，并且一旦更正，您的所有测试将再次通过。

这不是一个快速的过程，但是要在维护方面进行权衡。我也有一个针对自动化测试的自定义报告，我可以总结功能领域并深入研究各个控制问题，并查看每个步骤的确切错误，但这取决于您需要什么以及对团队有用。

#3 楼

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


您是否拥有User Stories *，并且已通过某种工具进行管理？
您是否有接受标准每个用户故事？
您是否将接受条件正式化为测试用例？
您是否将每个自动测试“链接”到其相应的测试用例？

如果可以回答“是”所有问题，然后您需要做的就是管理用户案例和测试用例。测试用例不太可能会落入两个不同的用户案例中，如果这样做，可能有正当的理由。

此外，用于处理用户案例和测试用例的工具通常要准备得更充分。处理这些信息，因此您应该能够非常轻松地查询重复项等。

如果您对某些问题的回答为“否”，那么我想这就是问题的根本原因。

这种方法的其他好处：


大大降低了您测试不重要的内容的机会，因为您只测试了产品负责人和团队
代码中的自动化测试文档现在仅包含一些指向测试用例的链接。
任何业务人员都可以轻松地查看您的测试用例并弃用/改进它们。

*如果不使用敏捷流程，则可以用需求或其他方式替换用户素材。

#4 楼

经常被忽略的一件事是利用覆盖率工具，而不是确保每行代码都经过测试-如果将工具配置为为每个测试/测试序列生成一个单独的命名输出文件，则可以

另一个关键点是-与所有内容一样-文档是关键-文档越好，维护就越容易。

#5 楼

将测试分为各种测试，即


与应用程序代码一起编写的单元测试
测试依赖项的集成测试
同时测试两者的性能测试响应和数量
手动测试

，并考虑您的业务和行业需要什么。一家资金很少的新兴公司将进行与Facebook完全不同的测试。

还要考虑一下测试金字塔：

        ui
     Integrated
 Performance & Load
Individual Unit Level

您应该拥有少数高级ui案例，但成百上千个低级单元案例（模拟和存根实际服务）。在级别之间的测试重复方面，我实际上希望所有高级集成测试在某种程度上都可以复制低级单元测试所涵盖的内容。例如，在网站上注册并进行购买的用户可能是一个端到端ui测试，但是它将使用具有单元测试的许多代码来实现这一目的。

时间跑步也是一个因素。您应该拥有可以在5分钟内运行的单元测试套件。不幸的是，许多公司的测试套件可以运行2或4甚至24小时。这意味着他们现在承担着技术债务，如果不解决，这些债务会使他们瘫痪。解决这个问题将意味着重大的文化变革，而且这将是非常困难的。他们失去了对流程的控制，现在遇到了严重的问题。

#6 楼

创建和维护RTM。在类似的情况下，我在自动化团队中提出并实现了需求可追溯性矩阵，在该团队中，需求和测试用例被映射以找出多余的测试用例和未涵盖的需求通过任何现有的测试用例。

经过这个练习，发现了一个令人惊讶的事实，即在测试用例之间有30-40％的测试步骤是多余的，而许多要求仅被部分覆盖。

#7 楼

其他人也有很好的观点，但是在管理大量测试方面，我还有另外一件事。确保您有办法从测试结果中倒退一步（或几步）以形成组。通常，通过软件的功能来形成组是可行的，并且您可能需要为不适合ti组的端对端测试等添加组。无论如何，通过这种方式，您可以一次处理一个小组，而不是整个小组。另外，如果您对测试原因和测试内容进行了描述，则会发现保持测试完整性更加容易。如果您以此创建树形结构，则可以管理成千上万的测试。

我不确定Microsoft Test Manager的工作方式，但是我想它具有支持此功能的功能。有点工作。我正在使用Meliora Testlab，它可以与Jenkins-Selenium集成一起使用。这种方法可以很好地与手动测试配合使用。