对结构、组织和设置的控制
从建立和组织你的测试资产的文件夹结构开始。你要把不同的资产，如测试、命名标准和脚本，从彼此之间隔离开来，并生成你知道你将不得不在每个文件夹中制作的文件。例如，你要为 "Scripts "文件夹中的每一种脚本生成文件--事件脚本、事件、工具和验证。请确保你也生成一个数据文件。这样，你的资产结构就可以被你的团队成员随时引用，并保证你的测试在升级的时候保持稳定。当你以这种方式结构你的资产时，你将总是能够审查项目，而没有不得不筛选大量信息的不适感。这也将为你的测试文件夹建模，以便你可以在整个项目中克隆它们。确保你有 "一个源码管理系统（SCM）"，如Git，在你进行这些最初阶段时，用于存储你的工作。如果发生错误，你将不会浪费你的时间和劳动。如果有必要，你可以跟踪这样的工具。
一系列关于测试框架的测试案例的创建和设计的建议或规定是。它们为测试应用提供了标准化的测试和报告语言，可以降低测试的维护费用。框架将测试与SDLC软件开发周期的其他方面联系起来，如需求和缺陷，使团队能够更快地识别和补救错误。然而，自动化框架并不是所有的测试框架，这是在以后设计时应该考虑到的问题。所有应用开发的工具和技术，包括对你的应用的要求，测试活动包括手动和自动测试，执行你的测试的环境等等，都包含在测试框架中。测试框架。
具体来说，自动化测试框架侧重于流程优化。他们通过重复使用和加快测试数据的开发和维护，将测试数据与逻辑隔离，从而促进快速循环。有几种自动化测试框架，挑选一个适合你的框架是至关重要的。然而，使用一个充分组织的框架，可以通过提高测试的准确性，优化测试范围，减少开支和服务，从而提高你的团队的生产力。
熟悉概念
接下来是开始熟悉应用程序--超过要求。你只能看到显示应用程序应该和不应该做什么的文件。在这个阶段，你希望你的手是肮脏的。进行探索性测试是为了给你提供一个如何建立系统内部程序的想法。通过这个练习，你将知道应用程序是如何工作的。一旦你完成了这个工作，你将不得不创建或调整如何发现你的用户界面元素。这可能意味着，根据你使用的工具，为识别对象所需的活动创建基本的名称映射属性或编写脚本。你的活动是这个层次的关键。记下你的需求以及它们如何被你的自动化测试。
定义环境和测试数据
下一步是收集测试的数据和创建你想采用的环境。为了你的成功，你必须创建可以在几个环境中执行的设置。现在是时候欢迎你的新好伙伴--事件处理程序了。事件处理程序是一个代码函数，它作为一个监听器运行，等待一个事件来激活一个或几个脚本。想象一下你的普通银行请求。经过几分钟的闲置时间，你会收到一条信息，询问是否需要进一步的时间。如果你不回复，出于安全考虑，你已经自动注销了。引起空闲通知和注销程序的脚本的函数就是你这里的事件处理程序。无论你在哪个环境下，Windows或MAC，你都希望有这个过程，你的终端用户也期望有这个过程。在没有要求为每个环境设置不同的测试的情况下，事件管理器可以执行响应事件的行动。它们是关于如何执行系统的指令，没有具体的内容，允许你改进你的测试，而不需要手动管理它们。例如，动态对象的一个识别特征，如URL或文件名可能被修改。如果你改变了程序的名称，让它以新的方式表示，或者调整它的安装方式，你可以使用你的事件管理器来解决这个问题。测试是用来检查应用程序组件是否符合预期和框架所提供的工具。现在说说你的测试信息。数据必须与你的框架内的测试分开。使用你的存储库来存储数据和概括你的属性和引用--而不是测试它们。这将允许你在脚本和你的信息之间交换你的数据对象，并节省你的时间和工作，在未来你有的所有的实用程序。
建立一个烟雾测试套件
在你构建你的实用程序和验证之前，你必须建立一个烟雾测试项目。它们将成为检查你的服务的最关键的测试集。烟雾测试或验证测试最重要的是确认一个应用程序的工作，并确定是否需要额外的测试。这意味着，当烟雾测试通过时，你的应用程序的基本元素会发挥作用，这样你就可以继续进行更深入的测试。如果不是这样，就标志着你的程序已经破坏了必须工作的基本功能。当这种情况发生时，你最好要求先纠正这种情况。在这个阶段，额外的测试只会浪费关键的时间。你的烟雾测试套件也必须随着你的程序的增长或功能的扩展而不断发展。只需要一个错误就可以使一个应用程序瘫痪，毁掉一个公司的声誉。
为UI动作创建服务
你需要为典型的用户界面（UI）操作开发标准工具，包括菜单导航和文本输入字段，同时你要熟悉程序，收集数据，并设置你的周围环境。这些是你测试的基本构建元素，然后你可能会一起建立起测试逻辑。这可能就像在关键词测试中拖放部件一样简单，取决于你选择的程序。这使你的框架能够进行你的测试流程和检查，这样每个测试都需要最小的维护。一种方法是利用JavaScript类为你的导航，特别是。这样，当你调整你的活动或预期测试结果的记录方式时，你只需要从一个地方做起--最后，你将不得不一致地维护你的记录。这将使不是自动化工程师或开发人员的团队成员能够检查和理解你的测试日志。将你的框架数据与真实的测试数据隔离开来，并确定故障是活性成分、问题还是应用中的真正缺陷，这也是至关重要的。
做验证
在这个阶段，测试将被配置--使用与你的数据结构化相同的逻辑，这意味着它们可以被划分。只要说明你正在测试你的应用程序的操作，并改变对一个文本字段的要求。如果你确认文本字段只接受数字字符而不允许文本，你需要改变你的测试。在这种情况下，你不想让每个测试都是最新的，特别是如果你继续手动操作。理想情况下，你会在一个地方改变你的文本字段的部分，这样你就可以运行50个测试，在众多条件下仍能发挥作用。你创建的任何UI控件都应该是可选的，这样如果一个字段正确地接受了输入并且测试成功了，就没有必要每次都检查这个动作。你也应该分享你的验证信息。在早期阶段，不同的数据对象可以被不同的输入工具所接受，这样他们就可以把项目连在一起。这也可以让你根据需要在一个区域进行自我更新，然后可以遍布你框架的所有部分。将再次强调将框架数据与真实测试数据分离的必要性。
日志和报告
你的日志和报告方法是你的UI自动化架构的最后部分。你所有的探索活动，数据准备，以及环境和验证建设都应该在构建过程中被记录和注意。在检查前记录信息，说明检查的内容和预期的结果。这些通知对人们来说是可读的，这样非技术用户就可以检查你的注册，并清楚地知道在哪里和为什么会出现问题。错误不应该是隐晦的，没有人应该定义它们发生的原因。这个阶段的目标是协助你规范流程--你的记录和问题是什么。自动报告也应该进行。自动报告减少了你绘制报告的时间，使你能够集中精力进行数据分析。如果你想把测试日志导出，在网络上或使用正确的工具在网络服务器上共享，你可以把电子邮件发送程序自动化。如果一个测试失败了，马上你就会想知道。为什么要等到手绘报告？应用逻辑验证测试是必须的。框架的设计是为了方便测试和构建。经过这7个阶段，你可以构建一个坚实的UI自动化框架，为持久成功奠定基础。
结论
建立一个自动化的UI测试框架可能是一个乏味的过程。它既费时又费力。你的框架应该描述你计划编写代码和脚本的所有标准语言，你采用的做法和你想利用的工具，作为你测试程序的主要指导书。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
