介绍
在我参与的许多项目中,人们并没有为自己定制 TestRail,而是使用标准设置。 因此,在本文中我将尝试描述一个可以帮助您提高工作效率的单独设置的示例。 以一个移动应用程序开发项目为例。
一个小小的免责声明。 本文不包含对 TestRail 基本功能的描述(有很多关于此的指南)和销售表达式,生动地描述了为什么您需要选择这个特定的供应商来创建带有测试的存储库。
论证计划(将实施什么)
-
一般要求
-
绝对任何人都应该能够通过此案。
-
案例应尽可能长时间地保持相关性
-
案例应尽可能全面地涵盖移动应用程序的功能,以免与前两点相矛盾
-
-
分为测试用例和测试场景
-
快速生成各种类型的TestRun
-
烟雾
-
回归
-
冲击试验等
-
-
案例支持优化
-
放弃“死”硬编码屏幕截图,转而使用“可移动数据”
-
岗位要求
要编辑字段,您需要管理员访问权限
选择项目类型
有三种项目类型可供选择:
我们将选择默认类型。 所有案例都将同时在其中提供。 我们将使用智能过滤并一次性动态管理所有案例。
添加字段以查看测试用例列表
让我们添加一个字段来显示优先级测试用例:
您还可以添加其他字段。
设置测试用例字段和标签
打开设置菜单:
我们将需要以下字段:
“摘要”字段(测试用例标题)
这个领域已经存在,我们只是系统化它的使用。 我们将用例分为TestCase和TestScenario。 为了提高大量案例的可读性,最好事先就撰写摘要的规则达成一致。
测试场景:
示例:TestScenario - 使用移动应用程序的基本场景
测试用例:
示例:主屏幕 - 授权部分 - 输入登录名
总的来说,我们在案例的总结中看到了经典的理解:“什么、哪里、何时”。 我们还以最适合自动化的形式在视觉上分离高级测试脚本和低级测试用例。
“StartScreen”标签(TestScenario 开始的屏幕;此外,许多测试用例可以接触相邻的屏幕)
对于可能需要的内容:我们将从文本中删除引导用户进入当前测试用例屏幕的典型步骤的文本。 (创建特定测试情况的典型步骤)所有测试用例的所有典型步骤将写入一个文件中。 我会单独写更详细的内容。
创建一个新字段:
填写新字段的组成部分:
在本例中,我们从值列表中创建一个选择字段。 输入该字段的值:
请注意,id值不以XNUMX开头且不连续。 为什么要这样做? 关键是,如果我们有记录了输入的 id 的测试用例,
之后我们需要在两个现有屏幕之间创建第三个屏幕,
那么我们将不得不重写 id,并且由于现有文本案例的标签已经附加到它,因此它们将被简单地删除。 这将是非常不愉快的。
标签“Screen”(影响测试用例的屏幕名称)
您可能需要什么:冲击测试的锚点之一。 例如,开发人员制作了一项很酷的新功能。 我们需要对其进行测试,但为此我们需要了解此功能到底会影响什么。 默认情况下,我们可以从以下范例开始:应用程序的不同屏幕(活动)具有不同的类,因此构成应用程序的不同组件。 当然,在这种情况下需要采取单独的方法。
示例:home_screen、MapScreen、PayScreen 等。
“MovableData”字段(链接到具有可更改测试数据的代理数据库)
接下来,我们将尝试解决测试用例中保持数据相关性的问题:
-
链接到当前布局(这比截取死截图要好得多)
-
进入测试情况屏幕的典型步骤
-
SQL查询
-
外部数据和其他数据的链接
我们不会在每个测试用例中写入测试数据,而是创建一个外部文件,并在所有测试用例上链接到该文件。 更新此数据时,我们不必遍历所有测试用例并更改它们,但可以仅在一处更改此数据。 如果有人毫无准备地打开一个测试用例,他会在测试用例的正文中看到一个文件的链接,并提示他需要访问该文件以获取测试数据。
我们将把所有这些数据打包到一个外部文件中,项目中的每个人都可以使用该文件。 例如,您可以使用 Google Sheet 或 Excel 并在文件中设置搜索。 为什么选择这些特定的供应商? 事实上,我们从以下范式开始:团队中的任何人都应该能够打开并通过测试用例,而无需先安装任何工具。
为 Google表格 您可以使用 SQL 查询。 例子:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")
为 Excel 您可以设置方便的即时搜索宏。 (过滤)示例
实际上,这个想法并不新鲜,在第一个测试人员的书“Testing dot com”中有所描述。 (作者 Savin Roman)我们只是将 Roman Savin 提出的方法集成到 TestRail 中。 为此,请创建一个包含指向所创建文件的链接的字段:
填写链接的默认值,以便每个新的测试用例已经有一个链接:
如果外部文件的位置发生变化(我们提供任何不可抗力的情况),那么您可以方便地在所有测试用例中一次更改一个或多个字段:
字段“描述”(测试用例的描述或想法,标准说明)
您可能需要什么:在此文本字段中,我们将放置测试用例和标准说明的简短描述。
示例: 此测试用例中的所有测试数据(当前布局、工具的使用和其他数据)均由链接 {...} 指示,并位于 MovableData 文件中。 链接到顶部相应字段中的 MovableData。
标签“组件”(移动应用程序组件)
可能需要什么:用于冲击测试。 如果一个移动应用程序可以分为多个组件(彼此影响尽可能小),那么一个组件中的更改就足以在同一组件内进行检查(存在一些风险),并且执行的理由就会更少一切事物的普遍回归。 如果有信息表明一个组件可能影响另一个组件,则编制影响测试矩阵。
示例组件:GooglePay、订单、用户、地图、授权等。
标签“TAG”(用于过滤的其他标签)
使用标签标记测试用例以进行任意过滤。
对于以下方面非常有用:
-
快速编译各种典型任务的 TestRun:冒烟、回归等。
-
测试会自动化还是已经自动化?
-
任何其他标签
示例:Smoke、Automated、WhiteLabel、ForDelete 等。
设置测试用例中字段的显示顺序
我们创建了很多新字段,是时候以方便的顺序排列它们了:
创建测试运行
现在,我们将使用当前案例创建一个新的测试运行,只需单击三下即可进行冒烟测试:
其他提示
-
如果 TestRail 有多个项目,那么不要忘记仅为您的项目创建新字段,否则相邻团队的同事会对新的不寻常字段的出现感到非常惊讶。 可能会出现局部昏厥。
2. 具有大量字段的案例从相似的组类型中复制比创建新的更容易:
3、账号可以共享。 例如:一名管理员,多名用户。
结论
上述示例已在多个项目中实施并显示出其有效性。 我希望它们能帮助您提高对这个工具的理解,并帮助您创建有效且方便的“测试存储”。 如果您在评论中描述您使用 TestRail 的经验和有用的提示,我将非常感激。
参考文献:
非常感谢您的关注!
来源: habr.com