编写自动化测试套件时的最佳实践-所有测试都在一个文件中？

#1 楼

通常，随着代码库的增长，您应该将代码分为几个小块。例如，使用应用程序代码，您可以将所有类和方法放在一个文件中-长12,500行。但是，这变得不切实际且难以编辑。最好将代码分解成单独的类，然后将每个类放在单独的文件中。

相同的原理适用于测试。您可以将所有测试代码放在一个地方，但最好将其分解。这也将提供组织它的机会。例如，如果要测试7个类，则可以在一个单独的文件中为每个类创建测试，该文件相应命名。现在，这提供了测试代码的结构和组织，以使更改和维护更加容易。

#2 楼

绝对不能在单个文件中。

它不会缩放。将测试放在单个增长的文件中会损害可读性，在浏览时变得不便，并阻止您看到更大的图片。请记住，《代码》比《书面》的阅读频率要高得多。

我们也正在使用Protractor，并且拥有庞大的测试代码库，我认为，我们在此过程中已经吸取了很多教训。以下是适用于我们的原则：


使用“页面对象”模式抽象出页面的元素和块，从而构建供测试使用的便捷API
< br将页面对象放到po目录下，将规范放到specs下，使用每个屏幕或每个功能的内部目录来组织。这是我们当前的目录结构：

/config
/helpers  (a collection of helper methods and internal testing utilities)
/po
    /dashboard.po
        index.js
        filters.po.js
    profile.po.js
/specs
    /dashboard
        /validation
        defaultView.spec.js
    /exportToExcel
        ...   

请注意，我们如何在带有index.js和“子”页面对象的目录中将某些页面对象定义为“节点包”。我们还使用requirePO和requireHelper函数来简化在测试中导入页面对象和帮助程序的操作，在这里建议。

遵循量角器的样式指南
一个测试文件应涵盖一个特定的功能块-它应该只需使用一个句子就可以轻松设置describe描述，而无需使用“和”（“和”通常表示您正在尝试测试两个或更多不同的事物）
针对每个测试一个断言-这并不总是可以实现并且并不总是很有意义，但是在大多数情况下，如果您将describe块彼此嵌套在一起，这可以避免在一次测试中测试太多的东西
-这是过度复杂化这一特定特征的有力信号测试。查看是否最好创建单独的测试文件。 “扁平比嵌套更好。” （摘自“ Python的禅宗”）
我们还成功使用了jasmine-data-provider，它可以“乘以”并参数化测试
通过静态代码分析（我们一直在使用ESLint，eslint-plugin-jasmine和eslint-plugin-protractor插件）实施样式指南和其他规则。
用suites将测试分组为逻辑组

#3 楼

一般而言，它取决于应用程序。
对于一个非常简单的应用程序，在该应用程序中，您只需要自动化一种类型的测试，将它们分成多个文件就没有什么价值。
对于具有多个功能的复杂应用程序段中，您可以自动执行几种不同类型的测试，将这些东西分离成一个合理的文件结构显然是个好主意。
对于既不是非常简单也不是很复杂的应用程序，则不需要将其分成多个文件但是这样做有助于提高自动化测试的可理解性和可维护性。
这还取决于您使用什么工具来自动化测试。当您使用Python之类的语言编写自动化测试时，创建一个或多个库来保存将在多个测试用例和/或测试类型中使用的函数是很有意义的。诸如Cucumber，Fitnesse或Robotframework之类的测试框架通常还具有一组“最佳实践”，这些最佳实践源于框架的设计方式。
根据经验，没有“一种尺寸可以适合所有情况”的解决方案。将文件分成多个文件实际上总是一个好主意。由于应高度依赖于您的方法，因此应该由您和您的团队来决定应该进行哪种精确的分离。

#4 楼

我组织自动化测试解决方案的方式是...每个应用程序1个项目，应用程序每个主要区域1个文件夹，每个屏幕1个TestClass文件。

取决于应用程序的粒度和您可能需要为此编写大量测试，因此可能需要嵌套级别的文件夹，才能正确反映产品的粒度。即如果应用程序的一个选项卡包含10个选项卡，并且每个选项卡都包含10个页面导航，则您的项目可能应该具有2级文件夹，而不是一个包含100个测试文件的文件夹。

如果您将要有2个或更多的人为一个区域（即一个页面）编写100多个自动化测试，您可能想寻找一种方法将该区域划分为每个逻辑单元多个测试文件。这样一来，每个SDET /自动化实习生都可以在单独的文件中工作，并且可以避免他们每天解决合并冲突。

#5 楼

按功能划分测试

无疑将有助于将测试划分为“套件”，以测试适合人类使用流程的特征或功能（例如“登录”可能会测试登录页面的显示，身份验证，OAuth2等，但实际上只是所有这些都可以登录）。然后您可以制作自己的测试运行器脚本。一旦有了更多的测试和更复杂的案例，您将需要一组称为“夹具”的特殊测试数据，例如不包含用于测试表单验证的“ @”的电子邮件地址，以及测试用户的登录详细信息。测试运行器可以帮助添加此数据，然后将其删除。

高级测试

好像您在进行自动化功能测试。我建议检查可在任何Web应用程序上使用的其他测试工具，例如Cucumber（任何人都可以读写的测试语言）和Selenium（可自动执行诸如Chrome，Firefox等真正的浏览器的操作）-Behat会同时使用这两种工具。 >

#6 楼

这是我如何构建最新的python项目的示例：





不幸的是，python没有具有像ruby Rspec这样的内置方法分组。因此，我只是将单元测试分组为哪种特定方法进行单元测试：



希望这会有所帮助

#7 楼

拆分为源文件有很多好处，但是通常可以将其推迟到真正需要时再进行。它增加了额外的复杂性，可能暂时无法真正增加价值。

拆分成多个文件的充分理由：




多个工程师：正在工作在同一个项目上有多个测试自动化工程师。这限制了合并冲突。

长类：长于200-400行的类似乎是拆分的不错选择。

很多测试：涵盖不同应用领域的测试似乎是不错的选择split。

并行运行测试：并行运行散布在类/文件周围的测试更容易。

拥有单个文件的充分理由：



测试数量有限：在我的一个开源项目中，我只有14个端到端测试，似乎可以放在一个文件中。

中央：对于较小的项目，简单的中央位置很方便

好的做法：

我喜欢从一开始就使其尽可能简单。我采用KISS，YAGNI和DRY原则。因此，我总是在一个文件中开始测试。下一步是将测试步骤移至简单的pageObject中，因为测试开始重复相同的代码。然后，我可能会开始将测试拆分为多个文件。

坏习惯：

我当然不做的是将复杂的文件结构从以前的项目复制到新的文件中项目。听起来很简单，但可能会增加其他团队成员的开销和学习难度。从简单开始，可以帮助团队中的每个人享受编写测试的乐趣。