好吧,我需要在这个思考过程中得到提升——我的大脑很痛。我想得到你对一些方法的反馈。
我会提前发布我的问题,以防我在下面的描述中失去你的注意力:
您以前编写过类似产品的脚本吗?你是怎么处理的?
这些方法中的任何一种是否因任何原因而突出/可怕?如果是这样,是什么?
- 是否有另一种您会发现更合适的方法?
我正在测试一个工作流程,为了论证,我们将其称为购物车,其中包含各种 text_fields、radio_buttons 和 select_lists。 一家公司为大约 60 个客户提供此购物车,并非所有客户都使用相同的确切表格,但一般流程是相同的。客户端之间的总体思路是相同的(相同的目标功能),并且存在具有相同工作流的客户端子集,但许多是独特的。在这种情况下,唯一可能意味着某些字段不是必需的,而它们可能适用于其他客户端。或者,某个客户存在某些问题/文本字段,其他客户根本无法使用。
此时脚本的目标只是通过 Web 界面生成订单,而不是将流程的每个单独步骤验证为“测试”。你必须在这里相信我一点。仍然有很多常见的细节能够以可接受的准确度运行负面/边缘案例。
到目前为止,我看到的方法是:
使用页面对象模式,为每个客户端站点创建一个“页面”文件,并根据正在测试的客户端使用不同的页面类。这是乏味的,主要是脆弱的并且需要大量维护工作。但是,它会起作用,只要可以访问每个人的特定页面文件,我就可以为每个人使用相同的功能/场景。
创建一个方法来从 DOM 中抓取所有输入元素,检测它们是否是我们需要注入特定所需输入的保留字段,或者只需填写信息以完成订单。这不会搭载数据库,因此整体性能应该更好。
连接到数据库,收集用于构建页面的特定客户所需的所有信息,并为订单动态构建字段,并相应地回答它们。这在理论上听起来很棒,如果需要维护的话,几乎不需要。数据库抓取很容易,构建字段的难度我还不知道......
现在我正在使用: watir-webdriver cucumber Cheezy's page-object gem sequel