TestRegions简介
在标记应用程序中构建可测试性和敏捷性。
什么是TestRegions?（*）
TestRegions是一项简单的创新，通过打破应用程序编写和测试之间的传统竖井，为自动化软件测试带来了新的视角。它们为更好、更健壮的测试自动化铺平了道路，同时增强了整个开发生命周期的敏捷性。TestRegions希望是其他人可以使用和构建的第一步，以引入新一代的工具和方法，这些工具和方法将在软件测试和质量保证的艺术中带来新的进步。
简而言之，TestRegions是标记标记，可以用作“测试中的标记应用程序”的一部分，以定义应用程序并将其划分为用于自动化测试的目标测试区域的逻辑结构化和层次结构列表。标记应用程序可以是任何使用标记语言编写的应用程序，如XML、HTML、XHTML等。
testregion通常被标记应用程序的主机(或处理器)忽略，但是被实现它们的自动化系统(如Telerik Testing Framework的automation Infrastructure)所识别。
TestRegions的一些主要好处是:
通过为自动化测试提供一种通用方法来识别被测应用程序中的目标测试区域，同时在这些测试如何导航和访问这些目标区域方面添加结构和一致性，从而降低测试自动化创作过程的成本和复杂性。
testregion可以用作元素识别的参考点，它可以保护使用它们的自动化测试不受超出这些测试范围的产品更改的影响。当产品经历设计更改和功能更新时，这反过来又降低了测试的维护成本。换句话说，它们减少了产品更新引起的不必要的噪音和测试失败。
TestRegions还可以用于构建被测试应用程序的完整强类型抽象自动化层，以提供来自被测试产品的测试代码的松散耦合。这些层还可以用来封装某些要自动化的产品功能。
TestRegions还可以用来提供一个早期预警系统，在不需要运行测试和分析的情况下，将可能破坏测试自动化的产品变更通知团队。这反过来可以节省开发团队的时间，缩短开发和质量保证团队之间的反馈循环。
为了帮助演示这些好处，我们将在本教程中使用下面的简单标记页面作为示例应用程序。
Basic TestRegion's Usage
MyCompany, Inc. MyCompany 's Usage
主页。< / td > < / tr > < /表> < div > < input type = " text " id = " yourname " / > < input type = " text " id = " zipcode " / > < !——你所在邮政区里的意大利餐厅——> 名称 地址 电话。# < / td > < / tr > < tr > < td > Rest1 < / td > < td > Add1 < / td > < td > Tel1 < / td > < / tr > < tr > < td > Rest2 < / td > < td > Add2 < / td > < td > Tel2 < / td > < / tr > < tr > < td > Rest3 < / td > < td > Add3 < / td > < td > Tel3 < / td > < / tr > < /表> < / div > < /身体> < / html >
当前自动化实践
在深入研究TestRegions之前，让我们先看看当前标记应用程序的一些常用自动化方法，并了解它们的特征、挑战和缺点。
尝试在不使用TestRegions的情况下自动化标记应用程序(如上面的示例)时，常用的方法是使用其id或名称(如果定义了)直接针对页面上的每个元素。当id /名称没有定义时，自动程序通常会恢复到其他方法，比如使用标记名出现或从文档的根开始在文档中搜索目标元素。
注意:关于这些方法有几点需要注意:
考虑到测试自动化的目标元素数量，以及从整个页面上的可用id /名称的平面列表中选择id /名称的非结构化方法，使用id /名称有时会变得很麻烦。当使用大型应用程序时，这通常会导致测试代码更不容易阅读和更难维护;特别是当测试所有权转移或自动化转移到海外时。这通常会导致整个产品周期的拥有成本更高。
使用id /名称并不总是可行或容易做到。这可能是由于许多原因，其中一些是:
当使用动态web开发框架时，不提供对生成标记的所有id /名称的控制。一个经典的例子是ASP。NET Calendar控件，生成嵌套的HTML表，但用户只能控制最外层表的id。
当使用您无法控制的第三方控件或标记内容时。您基本上只能在整个页面上使用标记名称索引和XPath标识。例如，如果您的应用程序进行web抓取或使用从web服务返回的数据作为标记。
当使用无法控制的动态或自动生成的唯一id /名称时。一些复杂的应用程序被设计为执行这样的命名方案，但动态web开发框架也执行这样的命名方案。(如ASP。NET时使用命名容器)。假设您不能控制这些命名方案，对它们的任何更改(由于升级或服务包)都会极大地影响您的测试自动化，并在许多情况下使其崩溃，迫使您花费数小时/数天来修复您的测试代码。
如上所述，元素上缺乏id /名称通常会导致使用标记名或XPath标识进行元素标识。当在测试自动化中使用这种类型的识别时，它通常是产生脆弱的测试自动化的关键因素之一，这会增加测试运行分析的成本，导致无效的测试失败，并最终导致更高的维护成本。产生这些缺点的原因是，这些方法内在地依赖于整个应用程序或正在测试的页面的完整结构。当应用程序中与这些测试所针对的部分无关的部分发生变化时，使用这些方法的测试往往会频繁中断。这通常迫使开发人员在每次发生此类更改时都必须返回并更新这些测试。
为了更清楚地说明这一点，让我们举一个简单的例子:
- 在上面的示例页面中，让我们假设我们有一个自动测试，用于验证意大利餐馆表的内容。该测试使用标记名称的出现来识别列出特定邮政编码中的餐馆的第二个表。在上面的示例中，测试代码将要求'table'， occurrence='2'，这应该是正确的。现在，如果稍后页面内容更新为在意大利餐厅的桌子之前包含另一张桌子，那么我们的自动化将会中断。更具体地说，如果上面的页面更改为在包含公司名称的表的正下方包含另一个表(例如也列出公司地址)，我们的测试将中断，因为'table'出现'2'不再是意大利餐馆的表。尽管页面中的更改发生在当前测试不关心也不关心验证的应用程序部分，但测试仍然中断了。同样的场景也适用于使用XPath标识。这通常是标记应用程序中测试用例脆弱和维护测试用例的高成本的主要原因之一。
尽管如此，值得注意的是，TestRegions并没有完全消除对id /名称的需求，相反，它们增加了当前对id /名称的使用和通用自动化实践，以帮助解决上面提到的一些问题，并为测试自动化添加更多的结构和一致性。
使用TestRegions
让我们从使用上面示例中的TestRegions开始，以提供从测试自动化访问该应用程序的结构化方法。为此，我们需要在应用程序标记中注入TestRegions。Telerik测试框架自动化基础设施支持的testregion是:
< testregion id = " regionid " >…区域内容…< / testregion >
鉴于这些是自定义标记，并且目前在最新的浏览器中没有按预期处理(例如，在Firefox中，自定义标记-即使它们是用扩展dtd定义的Xhtml -总是包含在打开标记之后的结束标记中，而不管标记内容是什么)，这些标记的注释版本是受支持的:
<！——testregion id =“regionid”——>…区域内容…< !——/ testregion >
使用这些标记作为注释对于整个应用程序来说是一种非常无干扰的方法，并且完全符合XHTML和XML等标记标准。
让我们首先在上面的示例应用程序中定义两个逻辑区域，这是我们希望在自动化测试中针对的目标。下面的页面显示了上面的示例，其中定义了以下两个逻辑区域:userinput, restaurantdata。
基本TestRegion's Usage
MyCompany, Inc.主页。
< !——testregion id="restaurantdata"——> 名称 地址 电话。# < / td > < / tr > < tr > < td > Rest1 < / td > < td > Add1 < / td > < td > Tel1 < / td > < / tr > < tr > < td > Rest2 < / td > < td > Add2 < / td > < td > Tel2 < / td > < / tr > < tr > < td > Rest3 < / td > < td > Add3 < / td > < td > Tel3 < / td > < / tr > < /表> < !——/testregion——> .
定义了测试区域后，我们的测试代码可以直接访问这些区域，而不考虑它们的嵌套或定位，如下所示:
TestRegion userInput = Manager.ActiveBrowser.Regions[" userInput "];TestRegion restaurantData = Manager.ActiveBrowser.Regions[" restaurantData "];
TestRegion = Manager.ActiveBrowser.Regions(" userInput ")
上面的每个TestRegion表示应用程序的一部分，由作为应用程序一部分的TestRegio定义。这里值得注意的是，TestRegions集合访问器是不区分大小写的，以避免由于id大小写错误而导致测试失败。
使用testregion标识元素
既然我们知道了如何将测试区域定义为被测应用程序的一部分，以及如何从自动化测试代码中访问它们，我们的下一步就是能够访问这些testregion中包含的元素，以便对其执行操作或从中提取数据。
每个TestRegion对象都有两个属性，用于访问其中包含的元素:
1.每个TestRegion都有一个'Element'属性，返回该TestRegion标签的实际DOM Element对象，因为它存在于加载文档的DOM树中。您可以使用Element对象根据需要将DOM树向上或向下导航到特定的元素。但是，这种方法是非常不推荐的，因为您的测试将依赖于应用程序的特定DOM结构，并将导致测试代码很容易崩溃。
2.第二种访问元素的方法是在测试代码中使用的更健壮和推荐的方法。每个TestRegion都有一个与之关联的“Find”对象。Find对象提供了与查找页面元素主题中描述的相同的丰富api和搜索例程。不同之处在于，这个Find对象使用TestRegion元素作为开始搜索的根元素。这个差异是使测试代码对目标测试区域之外的更改具有更高弹性的关键差异。事实上，针对特定测试区域并专门使用公开的Find对象来定位元素的测试代码，将完全不会受到该区域之外应用程序中的任何更改的影响。当然，该区域内的更改将影响针对该区域的测试，这可能是一种期望的行为。
例如，要在上面的示例中找到餐馆表，你可以这样写:
TestRegion restaurantData = Manager.ActiveBrowser.Regions[" restaurantData "];//假设该表是'restaurantdata'测试区域中的第一个表，它的出现索引为'0' Element restaurantttable = restaurantdata . find。ByTagIndex("表",0);
TestRegion = Manager.ActiveBrowser.Regions(" restaurantData ") '假设该表是'restaurantdata'测试区域中的第一个表，它的出现索引为'0' Dim restaurantTable As Element = restaurantdata . find。ByTagIndex(“表”,0)
一旦您访问了Element对象，现在就可以使用它来从中提取信息或对其执行操作。例如:
//访问userinput测试区域。TestRegion userInput = Manager.ActiveBrowser.Regions[" userInput "];//使用XPath查找邮政编码[从userinput testregion的根开始的第二个输入元素zipCodeTextBox = userinput . find . byxpath ("//input[2]");//在元素上执行一个操作。Manager.ActiveBrowser.Actions。SetText (zipCodeTextBox, " 90210 ");
'访问userinput测试区域。TestRegion = Manager.ActiveBrowser.Regions(" userInput ")’用XPath找到邮编。[从userinput testregion根开始的第二个输入元素Dim zipCodeTextBox As element = userinput . find . byxpath ("/input[2]") '在元素上执行一个操作。Manager.ActiveBrowser.Actions。SetText (zipCodeTextBox,“90210”)
在上面的第一个示例中，无论在测试区域之前或之后添加了多少'table'标签，测试都不会受到应用程序的任何更改的影响。您甚至可以提取该测试区域并将其嵌入到不同应用程序的不同部分中，以该区域为目标的所有测试仍将正常工作。第二个样本也一样。
总结
上面的示例向您介绍了TestRegions作为Telerik测试框架自动化基础设施的一部分的基本用法。他们还演示了如何利用这种方法来构建健壮的测试自动化代码，这些代码显示出低维护成本，并且对不希望的测试中断具有很强的弹性。此外，它们还演示了如何使用一致的和结构化的方法来识别要实现自动化的应用程序段，同时使测试代码更容易读懂，更容易学习和理解。TestRegions可以增强开发团队的敏捷性，并很好地适应敏捷开发环境。
＊TestRegion在标记应用程序中构建可测试性的方法和识别系统目前在美国专利和贸易局处于“专利申请中”。