五分之四的 QA 申请人希望学习如何使用自动化测试。 并不是所有公司都能在工作时间内满足手工测试人员的这种愿望。 Wrike 为员工举办了一所自动化学校，并实现了许多人的这一愿望。 我正是作为一名 QA 学生参加了这所学校。
我学会了如何使用 Selenium，现在几乎无需外部帮助即可独立支持一定数量的自动测试。 并且，根据我们共同的经验和我个人的结论，我将尝试推导出最理想的自动化学校的公式。
赖克组织学校的经验
当自动化学校的需求变得清晰时，它的组织就落到了自动化技术主管 Stas Davydov 的肩上。 除了他还有谁能解释他们为什么提出这个倡议、他们是否取得了成果以及他们是否后悔所花费的时间？ 让我们请他发言：
— 2016 年，我们编写了一个新的自动测试框架，并使编写测试变得容易：出现了正常步骤，结构变得更容易理解。 我们提出了一个想法：我们需要让每个想要编写新测试的人都参与进来，并且为了使其更容易理解，我们创建了一系列讲座。 我们共同制定了一个主题计划，每位未来的讲师都为自己准备了一个主题并准备了一份报告。
——学生们遇到了什么困难？
——当然主要是建筑。 关于我们的测试结构存在很多问题。 在反馈中，关于这个主题的文章很多，我们不得不举办额外的讲座来更详细地解释。
——学校有回报吗？
- 当然是。 多亏了她，很多人都参与了测试的编写，平均而言，在医院里，每个人都开始更好地了解自动测试是什么，它们是如何编写的以及如何启动的。 自动化工程师的负担也减轻了：我们现在收到的分析测试帮助请求减少了很多倍，因为测试人员和开发人员已经开始在几乎所有情况下自己处理这个问题。 嗯，该部门有几个内部优势：我们在演示和讲座方面获得了经验，因此一些自动化工程师已经成功地在会议上进行了演示，并且还收到了一套针对新手入职的强大视频和演示文稿。
我谨代表我个人补充一点，我们各部门之间的沟通已经简化到了极其简单的程度。 例如，现在我几乎不需要考虑哪些情况以及在什么级别的原子性上进行自动化。 因此，所有感兴趣的各方都在全力关注不断增长的测试覆盖率。 没有人向别人要求不可能的事情。
总的来说，这对团队工作的影响绝对是积极的。 也许阅读这篇文章的同事也在考虑做类似的事情？ 那么建议很简单：如果自动化测试是您的优先事项，那么这是值得的。 接下来，我们将讨论一个更复杂的问题：如何尽可能正确地组织这一切，使各方成本最小，产出最大。
组织技巧
学校很有用，但正如斯塔斯承认的那样，存在一些困难，因此有必要安排额外的讲座。 作为一名最近的学生，我在比较我自己（无知的情况下）和现在的我自己时，制定了以下步骤，以创建我认为的教测试人员理解自动化测试的理想方法。
步骤0.创建字典
当然，这一步不仅是 QA 所需要的。 但是，我想明确表示：自动化代码库必须以可读的形式保存。 编程语言——尤其重要 语言，然后您就可以开始潜水了。
这是带有元素名称的任务视图的屏幕截图。 让我们想象一下，您正在将任务视图作为黑匣子进行测试，并且从未见过 Selenium。 这段代码有什么作用？
（剧透 - 该任务被代表管理员通过休息删除，然后我们看到流中有此记录。）
仅此一步就使 QAA 和 QA 语言更加紧密地结合在一起。 自动化团队更容易解释运行结果；手动测试人员在创建案例上花费的精力更少：它们可以变得不那么详细。 不过，大家还是互相理解的。 我们甚至在实际训练开始之前就收到了奖金。
步骤 1. 重复短语
让我们继续与语言进行比较。 当我们小时候学习说话时，我们并不是从词源学和语义学开始的。 我们重复“妈妈”、“买玩具”，但不会立即探究这些词的原始印欧语根源。 所以这里是这样的：如果不尝试编写一些有用的东西，就没有必要深入研究自动测试的技术特征。
这听起来有点违反直觉，但它确实有效。
在第一课中，值得介绍如何直接编写自动测试的基础。 我们帮助设置开发环境（在我的例子中是 Intellij IDEA），解释使用现有步骤在现有类中编写另一个方法所需的最低语言规则。 我们和他们一起编写一两个测试，并给他们布置家庭作业，我将其格式化如下：从主分支分支出来的一个分支，但已从中删除了几个测试。 仅保留了他们的描述。 我们要求测试人员恢复这些测试（当然不是通过 show diff）。
结果，倾听并采取一切行动的人将能够：
- 学习使用开发环境界面：创建分支、热键、提交和推送；
- 掌握语言和类结构的基础知识：除了步骤之外，在哪里插入注入、在哪里导入、为什么需要注释、在那里找到什么样的符号；
- 了解action、wait和check之间的区别，在哪里使用什么；
- 请注意自动测试和手动检查之间的区别：在自动测试中，您可以拉取一个或另一个处理程序，而不是通过界面执行操作。 例如，直接向后端发送评论，而不是打开任务视图、选择输入、键入文本并单击“发送”按钮；
- 制定下一步将要回答的问题。
最后一点非常重要。 这些答案很容易提前给出，但一个重要的教学原则是，没有形成问题的答案不会被记住，并且在最终需要时不会被使用。
如果此时 QA 团队的自动化工程师给他分配一项任务，让他在战斗中编写几个测试，并允许他向他的分支提交子提交，那就太理想了。
不该给予的东西：
- 对开发环境的功能和编程语言本身有更深入的了解，只有在独立处理分支时才需要这些知识。 它不会被记住，你必须解释两三次，但我们很重视自动化工程师的时间，对吧？ 示例：解决冲突、向 git 添加文件、从头开始创建类、处理依赖项；
- 与 xpath 相关的一切。 严重地。 你需要单独、一次、非常集中地谈论它。
步骤 2. 仔细查看语法
让我们记住步骤 #0 中的任务视图屏幕截图。 我们有一个名为 checkCommentWithTextExists 的步骤。 我们的测试人员已经了解此步骤的作用，我们可以查看该步骤的内部并对其进行一些分解。
里面有以下内容：
onCommentBlock(userName).comment(expectedText).should(displayed());onCommentBlock 在哪里
onCommonStreamPanel().commentBlock(userName);现在我们学会说的不是“买玩具”，而是“从 Detsky Mir 商店购买玩具，位于从顶部数第三个架子的蓝色柜子里”。 有必要解释一下，我们从较大的元素开始按顺序指向一个元素（流 -> 带有某个人的注释的块 -> 该块中指定文本所在的部分）。
不，现在还不是讨论 xpath 的时候。 只需简单提一下，所有这些指令都是由它们描述的，并且继承是通过它们进行的。 但我们需要谈论所有这些匹配者和服务员；他们与此步骤具体相关，并且对于了解正在发生的事情是必要的。 但不要超载：你的学生稍后可以自己研究更复杂的断言。 最有可能的是，should、waitUntil、displayed();、exist();、not(); 就足够了。
作业很明显：一个分支，其中删除了一定数量的测试所需的几个步骤的内容。 让测试人员恢复它们并使运行再次变得绿色。
另外，如果测试团队的工作中不仅有新功能，还修复了一些bug，你可以要求他立即针对这些bug编写测试并发布。 最有可能的是，所有元素都已被描述；仅可能缺少几个步骤。 这将是一次完美的锻炼。
步骤 3. 完全沉浸
对于将继续履行其直接职责的测试人员来说，尽可能完整。 最后，我们需要谈谈xpath。
首先我们要明确一点，所有这些onCommentBlock和comment都是由他们来描述的。
合计：
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"故事的顺序非常重要。 首先，我们采用任何现有的 xpath 并显示元素选项卡如何包含一个且仅一个元素。 接下来，我们将讨论结构：何时需要使用 WebElement，以及何时需要为新元素创建单独的文件。 这将使您更好地理解继承。
必须明确指出，单个元素是整个任务视图，它包含一个子元素 - 整个流，其中包含一个子元素 - 单独的注释等。 子元素位于页面上和自动测试框架结构中的父元素内部。
至此，观众应该已经牢牢明白它们是如何继承的，以及onCommentBlock的点号后面可以输入什么内容了。 至此，我们解释了所有的运算符：/、//、.、[]等。 我们将有关使用的知识添加到负载中 @class 以及其他必要的东西。
学生应该明白如何这样翻译xpath。 巩固——没错，就是作业。 我们删除元素的描述，让它们恢复测试的工作。
为什么选择这条特定的路径？
我们不应该让一个人拥有复杂的知识，但我们必须立即解释一切，这是一个困难的困境。 这条路径将允许我们首先让听众提出问题并且不理解某些内容，然后在下一刻回答它们。 如果你谈论整个架构，那么当分析步骤或xpath主题时，其中最重要的部分已经由于难以理解而被遗忘。
然而，你们中的一些人可能能够分享如何进一步优化流程的经验。 我很乐意在评论中阅读类似的建议！
来源： habr.com