ui自动化测试测试报告_ui测试的screenidentifier模式

ui自动化测试测试报告

A good principle to follow in automated tests, particularly UI tests, is identifying a problem and failing the test as early as possible while also providing an error message which makes it easy to identify the root cause.

在自动化测试(尤其是UI测试)中要遵循的一个良好原则是：识别问题并尽早使测试失败，同时还提供一条错误消息，使您可以轻松识别根本原因。

Let’s assume we have the following test case:

假设我们有以下测试案例：

1. Open www.google.com
   打开www.google.com
2. Search for “Test all the things”
   搜索“测试所有东西”
3. Click on the first search result
   点击第一个搜索结果
4. …
   …

Let’s imagine this test failing at step 3 (Click on the first search result) with an error message like: Cannot find element “searchResult”. Without debugging the test execution, can we quickly tell what the root cause is?

假设此测试在步骤3(单击第一个搜索结果)失败，并显示以下错误消息： Cannot find element “searchResult” 。 在不调试测试执行的情况下，我们能否Swift说出根本原因是什么？

Not really. It could be a problem on the search results page, for example the search results not being rendered (or being empty). However, the problem could also be that the search results page never loaded in the first place and we are still on the homepage. In other words, our step 3 is looking for a UI element on the wrong screen.

并不是的。 这可能是搜索结果页面上的问题，例如搜索结果未呈现(或为空)。 但是，问题还可能是搜索结果页面从来没有加载过，而我们仍然位于主页上。 换句话说，我们的步骤3在错误的屏幕上寻找UI元素。

In the second scenario, it would save us significant analysis time (especially in more complex tests) if the test already failed at the second step (Search for “Test all the things”) because that is where the actual problem lies.

在第二种情况下，如果第二步测试已经失败(搜索“测试所有事物”)，这将为我们节省大量分析时间(尤其是在更复杂的测试中)，因为这是实际问题所在。

屏幕标识符模式可用于救援 (Screen Identifier pattern to the rescue)

A pattern we can use to improve this is what I call page objects with screen identifiers. Whenever a test is expected to transition the application under test to a new screen, we verify that the screen/page loads correctly before continuing with the test. Therefore, we define one (or multiple) UI elements that should be present on each screen. Ideally, these should be unique to the screen and load fast. If they are missing, we conclude that we are not on the expected screen and fail the test — right then and there.

我们可以用来改善这种情况的模式是我所说的带有屏幕标识符的页面对象。 每当需要进行测试以将被测应用程序转换到新屏幕时，我们都会在继续测试之前验证屏幕/页面是否正确加载。 因此，我们定义一个(或多个)UI元素，这些元素应出现在每个屏幕上。 理想情况下，它们应该是屏幕唯一的并且可以快速加载。 如果缺少它们，我们得出的结论是我们不在预期的屏幕上，并且在当时和那里都未通过测试。

This is how it looks like (code using Selenium/Selenide and Java, simplified from JustTestLah!):

这是它的样子(使用Selenium / Selenide和Java的代码，从JustTestLah简化！ )：

// Test code
public class GoogleSteps extends BaseSteps {
  private GooglePage google;
  private ResultsPage results;  @When("I search for {string}")
  public void search(String searchTerm) {
    google.verify().search(searchTerm).verify();
  }
}// Page object class for the homepage
@ScreenIdentifier("SEARCH_FIELD")
public class GooglePage extends BasePage<GooglePage> {  private ResultsPage results;  public ResultsPage search(String searchTerm) {
    $("SEARCH_FIELD").sendKeys(searchTerm);
    $("SEARCH_FIELD").pressEnter();
    return results;
  }
}// Page object UI locators for the homepage
SEARCH_FIELD:
  web:
    type: css
    value: input[name=q]
    
LOGO:
  web:
    type: id
    value: hplogo// Page object for the search results page
@ScreenIdentifier({"SEARCH_RESULT", "RESULT_STATS"})
public class ResultsPage extends BasePage<ResultsPage> {
}// Page object UI locators for the search results page
SEARCH_RESULT:
  web:
    type: css
    value: .g
    
RESULT_STATS:
  web:
    type: id
    value: result-stats

The main part to focus on are the @ScreenIdentifier annotations and the calls to verify(). This method is implemented in a BasePage class and it is where the screen identifiers are read (using reflection) and verified:

要关注的主要部分是@ScreenIdentifier批注和对verify()的调用。 此方法在BasePage类中实现，并且可以在其中读取屏幕标识符(使用反射)并进行验证：

public T verify(int timeout) {
  Class<?> clazz = this.getClass();
  while (clazz != Base.class) {
    for (ScreenIdentifier identifiers : clazz.getAnnotationsByType(ScreenIdentifier.class)) {
      for (String identifier : identifiers.value()) {
        try {
          $(identifier).waitUntil(appear, timeout).isDisplayed();
        } catch (ElementNotFound exception) {
          throw new ScreenVerificationException(identifier, this.getClass().getSimpleName(), timeout);
        }
      }
      clazz = clazz.getSuperclass();
    }
    return (T) this;
  }

Assuming a problem in loading the search results, this test would now fail in the second step (Search for “Test all the things”) throwing an exception that pinpoints exactly which screen didn’t load correctly (and which element we used to identify this):

假设加载搜索结果时出现问题，该测试现在将在第二步(搜索“测试所有事物”)中失败，并抛出一个异常，该异常精确地指出了哪个屏幕未正确加载(以及我们用来识别该屏幕的元素) )：

qa.justtestlah.exception.ScreenVerificationException: Expected element RESULT_STATS (id:result-stats) is not displayed on ResultsPage after 2000 milliseconds

qa.justtestlah.exception.ScreenVerificationException: Expected element RESULT_STATS (id:result-stats) is not displayed on ResultsPage after 2000 milliseconds

翻译自: https://medium.com/swlh/the-screenidentifier-pattern-for-ui-tests-542a772b5eba

ui自动化测试测试报告