TestRegions简介
在标记应用程序中构建可测试性和敏捷性。
什么是testregion ?（*）
TestRegions是一种简单的创新，通过打破应用程序编写和测试之间的传统竖井，为自动化软件测试带来了新的视角。它们为更好、更健壮的测试自动化铺平了道路，同时增强了整个开发生命周期的敏捷性。TestRegions是有希望的第一步，其他人可以使用并以此为基础来引领新一代的工具和方法，这些工具和方法在软件测试和质量保证艺术方面取得了新的进展。
简而言之，TestRegions是标记标记，可以作为“被测试的标记应用程序”的一部分来定义和分割应用程序，并将其划分为自动化测试的目标测试区域的逻辑结构化和分层列表。标记应用程序可以是使用诸如XML、HTML、XHTML等标记语言编写的任何应用程序。
testregion通常会被标记应用程序的主机(或处理器)忽略，但是会被实现它们的自动化系统识别，比如Telerik Testing Framework的自动化基础设施。
TestRegions的一些主要优点是:
通过提供自动化测试的通用方法来识别在测试中的应用程序中的目标测试区域，同时在这些测试导航和访问这些目标区域的方式中添加结构和一致性，从而降低测试自动化编写过程的成本和复杂性。
TestRegions可以用作元素识别的参考点，它具有屏蔽使用它们的自动化测试，使其免受超出这些测试范围的产品变更的影响。当产品经历设计变更和功能更新时，这反过来又降低了测试的维护成本。换句话说，它们减少了不必要的噪音和由产品更新引起的测试失败。
TestRegions还可以用于构建被测试应用程序的完整的强类型抽象自动化层，以提供来自被测试产品的测试代码的松散耦合。这些层还可以用来封装要自动化的某些产品功能。
还可以利用TestRegions提供一个早期预警系统，通知团队产品变更，这些变更可能会破坏他们的测试自动化，而不需要运行测试和进行分析。这反过来又可以节省开发团队的时间，缩短开发和质量保证团队之间的反馈循环。
为了帮助演示这些好处，我们将使用以下简单的标记页面作为本教程的示例应用程序。
TestRegion基本用法
MyCompany, Inc.主页。< / 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 /名称时，自动程序通常会恢复到其他方法，比如在文档中使用标记名称搜索目标元素，或者从文档的根目录使用XPath搜索目标元素。
注意:关于这些方法，有几点需要注意:
考虑到测试自动化所针对的元素数量，以及从整个页面上可用的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 id = " regionid " >…区域内容…< / testregion >
考虑到这些是自定义标记，并且目前在最新的浏览器中没有按照预期的方式处理(例如，在Firefox中，自定义标记-即使它们是用扩展dtd定义的Xhtml -总是包含在打开标记之后的结束标记中，而不管标记内容如何)，因此支持这些标记的注释版本:
< !——testregion id =“regionid”——>…区域内容…< !——/ testregion >
对整个应用程序来说，使用这些标记作为注释是一种非常不具侵入性的方法，并且完全符合XHTML和XML等标记标准。
让我们首先在上面的示例应用程序中定义两个逻辑区域，我们希望在自动化测试中以它们为目标。下面的页面显示了上面的示例，其中定义了以下两个逻辑区域:userinput、restaurantdata。
TestRegion基本用法
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 "];
Dim userInput = Manager.ActiveBrowser.Regions(" userInput ") Dim restaurantData为TestRegion = Manager.ActiveBrowser.Regions(" restaurantData ")
上面的每个TestRegion都代表应用程序的一部分，由作为应用程序一部分的TestRegion定义。这里值得注意的是，TestRegions集合访问器是不区分大小写的，以避免由于id大小写错误而导致测试失败。
使用TestRegions识别元素
现在我们知道了如何将测试区域定义为测试应用程序的一部分，以及如何从自动化测试代码中访问它们，我们的下一步是能够访问这些TestRegions中包含的元素，以便在其上执行操作或从中提取数据。
每个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'。ByTagIndex("表",0);
Dim restaurantData As TestRegion = Manager.ActiveBrowser.Regions(" restaurantData ") '假定该表是'restaurantdata'测试区域中的第一个表，它的出现索引为'0'。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测试区域。将userInput设置为TestRegion = Manager.ActiveBrowser.Regions(" userInput ")使用XPath找到邮政编码。[从userinput的根开始的第二个输入元素testregion Dim zipCodeTextBox As element = userinput . find . byxpath ("/input[2]") '对元素执行一个操作。Manager.ActiveBrowser.Actions。SetText (zipCodeTextBox,“90210”)
在上面的第一个示例中，无论在测试区域之前或之后添加了多少“表”标记，对应用程序的任何更改都不会影响测试。您甚至可以提取该测试区域并将其嵌入到不同应用程序的不同部分中，并且针对该区域的所有测试仍将按预期工作。第二个样本也是一样。
总结
上面的示例向您介绍了TestRegions作为Telerik测试框架自动化基础设施的一部分的基本用法。他们还演示了如何利用这种方法来构建健壮的测试自动化代码，这些代码显示出低维护成本，并且对不希望的测试中断具有高度的弹性。此外，它们演示了如何使用一致的和结构化的方法来识别应用程序段，以实现自动化，同时使测试代码更清晰，更快地学习和理解。TestRegions可以增强开发团队的敏捷性，并且非常适合敏捷开发环境。
＊TestRegion在标记应用程序中构建可测试性的方法和识别系统目前正在美国专利和贸易办公室“申请专利”。