appium怎么测试ios
iOS设备仍占据着移动市场的重要份额，占全球销售额的22％。 随着许多忠实的客户回来购买新的Apple产品，对iOS应用程序的需求也很大。 在本文中，我们将着眼于确保通过Appium，Cucumber和Serenity工具努力争取最佳实践的iOS应用程序的质量。 (iOS devices still claim a significant part of the mobile market, taking up to 22 percent of the sales globally. As many devoted clients come back for new Apple products, there is also a great demand for iOS applications. In this article, we are going to look at ensuring the quality of iOS apps striving for the usage of best practices using Appium, Cucumber, and Serenity tools.)
结构体 (Structure)
The Page Object Model is one of the best approaches to testing that QA engineers can apply to a test automation project. It is such a way of structuring the code in an automation project that improves code quality and readability, test maintenance, and on top of that, it is a great way of avoiding chaos. The basic idea behind it comes to keeping all references to mobile elements and methods performing operations on them in one class file for each page or screen of the app (or web page for non-native web applications).
页面对象模型是质量检查工程师可以应用于测试自动化项目的最佳测试方法之一。 这种在自动化项目中构造代码的方法可以提高代码质量和可读性，测试维护，并且最重要的是，它可以避免混乱。 其背后的基本思想是将对移动元素和对它们执行操作的方法的所有引用保存在一个类文件中，用于应用程序的每个页面或屏幕(或非本地Web应用程序的网页)。
What are the benefits of this approach, you may ask? Firstly, it makes automation really straightforward. Basically, it means finding elements in our iOS app via inspector and then performing operations on them. Another main advantage is the coherent structure of the project that allows anyone to navigate through it quickly.
您可能会问这种方法有什么好处？ 首先，它使自动化变得非常简单。 基本上，这意味着要通过检查器在我们的iOS应用中找到元素，然后对它们执行操作。 另一个主要优点是项目的连贯结构，它使任何人都可以快速浏览它。
Let’s take an example of an app that contains recipes. It shows the default cookbook with basic recipes on startup, which will be our first page. From there, a user can navigate to any available recipe, thus marking a second page. On top of that, the app also allows to browse other cookbooks or purchase premium ones, making it the third page and consequently — a page object file.
让我们以包含食谱的应用为例。 它显示了默认的食谱以及启动时的基本配方，这将是我们的第一页。 从那里，用户可以导航到任何可用的配方，从而标记第二页。 最重要的是，该应用程序还允许浏览其他食谱或购买高级食谱，从而使其成为第三页，从而成为页面对象文件。
Similarly, we should create corresponding step definition files. This is not an obligatory practice, but keeping all step definitions in one place causes unnecessary chaos.
同样，我们应该创建相应的步骤定义文件。 这不是强制性的做法，但是将所有步骤定义都放在一个位置会造成不必要的混乱。
While creating your pages and step definition class files it is advised to choose names that are related to the page (app screen) which contents you are going to work on. Naming these files after a feature or scenario can seem right at first glance, but as the project expands, you will notice more and more clutter in its structure. Adopting the page naming convention ensures that anyone involved in the project can get familiar with it straight away and start collaboration on it in no time. Such practice also contributes to reusability of code — either step definitions or methods/functions.
在创建页面和步骤定义类文件时，建议选择与要处理的页面(应用程序屏幕)相关的名称。 乍一看，在功能或场景下命名这些文件似乎是正确的，但是随着项目的扩展，您会发现其结构越来越混乱。 采用页面命名约定可确保项目中涉及的任何人都可以立即熟悉它并立即开始对其进行协作。 这种做法也有助于代码的可重用性-步骤定义或方法/功能。
Contrary to the mentioned step and step definition files, the Cucumber feature files should be named after a feature they verify. Clever, isn’t it? And again, structuring them into directories named in relation to a particular field of the application under test will make the structure more meaningful.
与上述步骤和步骤定义文件相反，Cucumber功能文件应以其验证的功能命名。 聪明，不是吗？ 再者，将它们构造为与被测应用程序的特定字段相关的命名目录将使该结构更有意义。
Serenity’s basic concept is to be a ‘living documentation’. Therefore, giving test scenarios and feature files appropriate names helps the team and stakeholders understand reports and the entire project better.
Serenity的基本概念是成为“生活文件”。 因此，给测试方案和功能文件适当的名称有助于团队和利益相关者更好地理解报告和整个项目。
Another ingredient expanding the benefits of the Page Object Model in the test automation project is PageFactory. It is a tool that helps you reduce the coding work and easily put MobileElements locators in code, using @FindBy notation. From there, finding elements for Appium to interact with them in tests is much simpler.
在测试自动化项目中扩展Page Object Model的好处的另一个因素是PageFactory。 它是一种工具，可帮助您减少编码工作，并使用@FindBy表示法轻松地将MobileElements定位符放入代码中。 从那里开始，找到Appium在测试中与它们交互的元素要简单得多。
断言 (Assertion)
Running tests via Appium can be very resource-consuming. To make things easier for your MacOS machine running tests on your iOS device, make sure you are not constantly asserting the visibility of all objects on a page. This practice significantly increases the test execution time, which usually is not the most desirable thing.
通过Appium运行测试可能会非常消耗资源。 为了使MacOS机器在iOS设备上运行测试变得更容易，请确保您没有不断断言页面上所有对象的可见性。 这种做法大大增加了测试执行时间，这通常不是最理想的选择。
What is more, when you do have to check if an element is visible, enabled, clickable, or anything in between — try to avoid locating mobile elements using Xpath. The Appium inspector tip has a valid point! You should do what you can to convince the development team to make an extra effort and assign unique IDs and names to the elements in the app. This will not only make automation testing easier and quicker, consequently making your work as a tester more effective, ultimately resulting in increasing the overall quality of the product. And that is why we are here. Not to mention that the maintenance of the tests (e.g. switching to different locators when necessary) will become much more enjoyable.
而且，当您必须检查某个元素是否可见，启用，可单击或介于两者之间时，请尽量避免使用Xpath定位移动元素。 Appium检查员提示有一个有效的观点！ 您应该尽力说服开发团队付出更多努力，并为应用程序中的元素分配唯一的ID和名称。 这不仅将使自动化测试更加轻松快捷，从而使您作为测试人员的工作更加有效，最终提高了产品的整体质量。 这就是为什么我们在这里。 更不用说测试的维护(例如在必要时切换到不同的定位器)将变得更加令人愉快。
了解步骤 (Understanding the steps)
Another aspect of setting up this kind of project comes down to taking advantage of Cucumber and using Gherkin language.
设置此类项目的另一个方面是利用Cucumber并使用Gherkin语言。
Gherkin implements a straightforward approach with Given, When, Then notation with the help of the additional And and But which seems fairly easy to use. You could write pretty much anything you want in the test steps of your feature files. Ultimately, the called methods are going to perform actions.
Gherkin在附加的And and But的帮助下，使用Given，When，Then符号实现了一种简单的方法，该方法似乎相当容易使用。 您可以在功能文件的测试步骤中编写几乎所需的任何内容。 最终，被调用的方法将执行操作。
But the reason for using the Behavior Driven Development approach and Cucumber itself is enabling the non-tech people involved in the project to understand what is going on in the tests field. Not only that, writing test scenarios in Given/When/Then manner can also act in your advantage. Such high-level test descriptions delivered by the client or business analyst will get you coding in no time, provided that they are written properly. Here are some helpful tips:
但是，使用行为驱动开发方法和Cucumber的原因是使参与该项目的非技术人员能够了解测试领域中正在发生的事情。 不仅如此，以“ 给定/何时/然后”的方式编写测试方案也可以发挥自己的优势。 客户或业务分析师提供的这种高级测试描述，只要编写正确，就可以立即为您提供编码。 以下是一些有用的提示：
Test scenarios written in Gherkin should focus on the behavior of the app (hence Behavior Driven Development).Here’s an example of how NOT to write test scenarios in Gherkin, further exploring the theme of cookbook application:
用Gherkin编写的测试场景应重点关注应用程序的行为(因此称为行为驱动开发)。以下是如何不使用Gherkin编写测试场景的示例，进一步探讨了Cookbook应用程序的主题：
Above example illustrates two bad practices we should avoid: It focuses on the implementation instead of behavior and it uses hard-coded values rather than writing test steps in such a way to enable reusability by changing values within a step.
上面的示例说明了我们应避免的两种不良做法：它着重于实现而不是行为，并且它使用硬编码的值而不是编写测试步骤，而是通过在步骤中更改值来实现可重用性。
Therefore, a proper scenario concerning purchasing a cookbook in our example app should look like:
因此，有关在示例应用程序中购买食谱的正确方案应如下所示：
Another example:
另一个例子：
Adopting this approach means less work creating and coding the test steps whenever the implementation of a particular feature changes.
采用这种方法意味着每当特定功能的实现发生变化时，创建和编码测试步骤的工作就更少了。
Apart from the main notation of Given/When/Then, Cucumber supports usage of conjunction steps. Using And and But step notations will make the test steps more general and reusable, which results in writing less code and maintaining order within the project. Here is a basic example:
除了Given / When / Then的主要表示法之外，Cucumber还支持使用连词步骤。 使用“ 与”和“ 但”步骤符号将使测试步骤更加通用和可重用，从而减少编写代码并维护项目中的顺序。 这是一个基本示例：
Doing so, if you code the above ‘Given’ step to locate our recipe element by searching its name, you can reuse it many times just changing the string value in the step (provided that you code the step definition properly later on). On top of that, The ‘And’ step can be a part of any test scenario that involves such action.
这样做，如果您对上面的“给出”步骤进行了编码以通过搜索其名称来定位我们的配方元素，则只需更改该步骤中的字符串值即可使用它多次(前提是稍后您正确地对步骤定义进行了编码)。 最重要的是， “与”步骤可以是任何涉及此类操作的测试方案的一部分。
全部放在一起 (Putting it all together)
After setting up a project utilizing the practices described above, the most visible parts of using Serenity are the generated test reports. After adopting the @RunWith(CucumberWithSerenity.class) tag in your TestRunner class file, running the test suite will result in Serenity generating an aggregated test results report, which can be useful in evaluating the quality of the app under test and presenting the status of the product to the stakeholders or the development team.
在使用上述实践设置项目之后，使用Serenity最明显的部分是生成的测试报告。 在您的TestRunner类文件中采用@RunWith(CucumberWithSerenity.class)标记后，运行测试套件将导致Serenity生成汇总的测试结果报告，这可用于评估被测应用程序的质量并显示测试状态。将产品提供给利益相关者或开发团队。
摘要 (Summary)
As you can see, the concept of best practices in automation testing can be summarized in three words: reusability, readability, and performance. Reusability means fewer coding, consequently diminishing the time needed to finish the job. Readability improves understanding, which is crucial to ensure that the product does what it needs to do. Finally, performance saves execution time and improves stability. All three contributing not only to the quality of the test automation project but have a significant role in enhancing the overall quality of the delivered app.
如您所见，自动化测试中最佳实践的概念可以概括为三个词：可重用性，可读性和性能。 可重用性意味着更少的编码，因此减少了完成工作所需的时间。 可读性提高了理解力，这对于确保产品完成其需要做的事情至关重要。 最后，性能可以节省执行时间并提高稳定性。 这三者不仅有助于测试自动化项目的质量，而且在提高交付的应用程序的整体质量方面也起着重要作用。
资料来源： (Sources:)
https://www.guru99.com/page-object-model-pom-page-factory-in-selenium-ultimate-guide.html
https://www.guru99.com/page-object-model-pom-page-factory-in-selenium-ultimate-guide.html
originally published at http://grapeup.com on September 27th, 2019
最初于 2019 年 9月27日发布在 http://grapeup.com
appium怎么测试ios
344
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
