如何以最小化维护工作的方式来构造硒测试？

#1 楼

正如其他人所说，请使用Pageobject和其他最佳实践。很少有链接：



PageObject解释了-独立于语言的Martin Fowler

硒最佳实践-简短的摘要，用于Java

摘要：


使用PageObjects模式
精通


返回此内容，变量，泛型，
重新使用模型并使用jodatime



要健壮和便携


首选选择器顺序：id>名称> css> xpath避免Thread.sleep首选Wait或FluentWait
使用相对URL
不要依赖特定的Driver实现
创建数据集


了解新工具


保持最新（版本和使用模式）
故障排除


jre 1.6
IE（缩放，受保护模式设置）
Firefox / firebug起始页


如何处理UI组件，如...文件上传，日期选择器，ajax表等...
检测硒是否存在时不是工作的好工具
不要害怕乱砍硒
/>


搜索“ pageobject”和“最佳实践”将为您提供更多有关系统和语言的链接。

PageObject为它们封装了许多页面交互和定位符，因此测试可以调用pageobject方法在页面上执行某些操作，而无需了解HTML，定位符等。

#2 楼

除了其他人提出的令人敬畏的建议之外，我还要描述一个经常被忽视的领域。与单元测试不同，在端到端测试中，您对系统中的数据和测试环境的控制较少。以下是一些建议，可以在此类数据或测试环境更改时使您的测试更易于维护：不要以为您的测试数据将永远存在于数据库中。我见过依赖生产数据库数据的测试，例如具有特定名称或特权的用户。如果对这些数据的引用进行了硬编码，并且这些引用之后的数据将被更新，甚至更糟的是将其删除，则测试将无用。而是让您的测试创建特定的测试数据或以声明的方式检索它们，例如通过SQL查询。
命名您的测试数据。如果您不确定要作为测试的一部分来检索或创建特定的测试数据，请给他们至少一些有意义的名称，这些名称将解释您为什么选择此示例而不是其他示例。想象一下，您必须维护一组包含过时航班的测试数据：不再有从洛杉矶到雷克雅未克的航班。因此，您需要另一个类似航班的样本。类似的测试数据在这里意味着什么？即测试此特定航班的目的是什么？它是关于检查洲际航班或往返航班的系统行为吗？更好的方法是使用名称来包装此测试数据，例如anyIntercontinentalRoundtripFlight()。
与测试环境脱钩。不要将您的测试与特定的测试环境耦合在一起。我见过使用URL，路径，数据库连接URL和其他特定于环境的元素进行硬编码的测试。当您的产品必须在新配置上进行测试时，更新测试将是一场噩梦。因此，将测试环境配置与测试用例分开。将环境配置放在单独的类或文件中。

#3 楼

像处理其他代码一样处理测试，使用编码准则，开发模式，最佳实践和文档方法等...从代码角度来看，使其尽可能易于维护。迄今为止，我将在您的过程中添加以下步骤：


让开发人员在签入/提交代码之前运行测试（使他们负责不破坏自动化测试）
在每个检入/提交操作中使用连续集成服务器运行测试（这样您就知道谁/什么破坏了测试）
如果测试失败，请确定其是否有缺陷或是否需要更新
在继续进行其他任何开发之前，请确保有人正在修复测试。

关键是要给开发人员尽可能快的反馈，并防止在流沙上进行构建。

#4 楼

可读性：
我的一位代码指导员在我职业生涯的早期就教给我：“如果您的逻辑/算法不够简单，无法由第三人理解和修改，重构并重复。
六个月后下线，那第三个人可能就是你自己。“

我在设计自动化测试时遵循的一些规则： br />
简化代码：简化代码，使其自然地从一层流到另一层，并由第三方读取。
非技术人员可以像这样阅读和理解您的代码吗？一本书？（至少在顶层上）


干燥您的代码：干燥您的代码，因此，如果有任何更改，则只需在一个地方进行更新。始终不断重构代码以使其更加DRYer。 >
将重点放在简单的测试上，而不是冗长的复杂测试：将一个断言作为测试的最后一步。 br />仅由于其他任何测试失败而失败。


每个测试仅应测试一件事：每个测试都应该仅出于一个原因而失败。 ，则没有正确设计。


没有多余的步骤：多个测试中不应包含相同的步骤/验证点。


分离定位器和测试数据：将定位器和测试数据与主要的自动化代码隔离开，以便可以独立更新而无需触及代码。

#5 楼

基本上，您希望将测试的内容与实际的页面交互隔离开，以便可以一次更新页面交互代码并使所有测试正常工作，对吧？对于。如果您有一个知道如何与您的网站进行交互的对象，并且所有测试都与该对象进行交互而不是直接触摸页面，则在网站更改后，您只需更新PageObject即可，所有测试都将是最新的。

#6 楼

我相信您必须已经知道这一点-通常认为自动化将来可能会改变的功能部件/功能/模块是个坏主意。但是我知道有时候产品的后果不是由任何人来控制，而是由客户来控制。在产品发生变化时最大程度地减少工作量-


模块化您的代码。创建一个基类，其中包含处理最常用/最常用动作的方法。单击按钮，上下文单击，声明，等待等。这将鼓励Test类中代码的重用。
从外部文件获取测试数据。您也可以将元素标识符存储在文件中。这将帮助您（在一定程度上）更改测试用例，而不必重新编译您的一个或多个类。
符合编码标准。如果您有一个庞大的团队，并且有多个QA参与自动化过程，那么每个人都必须以正确的格式编写代码非常重要。这将使团队的每个成员都能够阅读，理解和更改（如果需要）代码的任何部分，从而节省时间和精力
使用适当的框架。使用诸如TestNG之类的框架，您可以执行/定义除测试步骤之外的许多操作，例如。哪些案例/类要运行/不运行，哪些案例要首先执行，如果一个或多个案例失败，哪些案例要依赖于其他案例/跳过等等，等等。马上。希望能有所帮助，但是根据我的经验，如果您频繁地进行自动化更改，您最终会花费大量不必要的精力来尝试应对更改。太多的更改通常会导致在代码中引入新的问题。

#7 楼

正如Yash所建议的那样，但简写为：

使用Testng注释可以很好地表明依赖关系。

花了一些时间才学会使用它（yaml +组+包） ，但对于批注，您可以轻松构建测试的依赖关系和结构。

外部属性文件对用户数据也很有帮助。样板代码，简化了理解和编写工作的麻烦，并且还提供了学习脚本语言的机会。如果可能，请使用DSL。