2014-01-08 4 views

ответ

1

Так я это делаю. Отнюдь не лучший или единственный способ.

У меня есть класс статические утилиты для основных функций и запуска/закрытия appundertest

public static class Utilities 
{ 
    private static ApplicationUnderTest App; 
    public static Launch() 
    { 
     try 
     { 
       App = ApplicationUnderTest.Launch(pathToExe); 
     } 
     catch (Microsoft.VisualStudio.TestTools.UITest.Extension.FailedToLaunchApplicationException e) {} 
    } 
    public static Close() 
    { 
     App.Close(); 
     App = null; 
    } 
} 

Все мои * .uimaps разделяются базы на «страницы» или «экранов» приложения. Иногда это кодируется. UI зажимается, и ваши * .uimaps могут сломаться. Также стоит упомянуть, что все uimaps содержат отдельные действия на странице, такие как заполнение имени пользователя для входа в систему или нажатия кнопки.

У меня тогда есть класс NavMap, который содержит все навигационные системы более высокого уровня, которые я бы сделал в своих приложениях. Было бы лучше, чтобы придумать какую-то сложную структуру, но я предпочитаю просто список методы списка в статическом классе

//you will need to include the uimap in a using statement 
public static class NavMap 
{ 
public static void Login() 
{ 
    this.credsUIMap.EnterUsername(); 
    this.credsUIMap.ENterPassword(); 
    this.credsUIMap.ClickLoginButton(); 
} 

public static void LogOut() 
{ 
    this.credsUIMap.ClickLogOutButton(); 
} 
} 

Наконец у меня есть тестовый файл codedUI, где тесты сформированной

[TestClass] 
public class Tests 
{ 
    [TestMethod] 
    public void TestMethod1() 
    { 
     NavMap.Login(); 
    } 
    [TestMethod] 
    public void TestMethod2() 
    { 
     NavMap.LogOut 
    } 

    [ClassInitialize()] 
    public static void ClassInitialize(TestContext testcontext) 
    {   
     Utilities.Launch(); 
    } 

    [ClassCleanup()] 
    public static void ClassCleanup() 
    {   
     Utilities.Close(); 
    } 
} 

I Также делайте отдельные тестовые файлы для различных типов тестов (положительные, отрицательные, стрессовые, ...). Затем я их объединяю в упорядоченный тест

+0

спасибо, Zaq. – stasde

0

Я использую несколько проектов. Один общий, содержащий общие методы и общие UIMaps для других проектов (с соответствующими зависимостями от общего проекта).

А потом у меня есть проект для каждого рабочего стола или веб-приложения, которое я хочу автоматизировать. В проектах: UIMap для каждого окна. Затем каждый тестовый экземпляр uimaps, который должен быть использован, должен использоваться. Контрольная группа каждого теста.


Я могу добавить следующий пример:

*** Я не могу разместить изображения еще Пример моей текущей структуры исследуемого раствора: http://i.stack.imgur.com/ekniz.png

Путь вызвать записанное действие с методом теста будет:

#using Application.UIMaps.Common_Application_UIClasses; 
#using Application.UIMaps.Window_1_UIClases; 

... 

Common_Application_UI app_common = new Common_Application_UI(); 
Window_1_UI win1 = new Window_1_UI(); 

app_common.goToMenuThatOpenWindow1(); 

win1.setSomething("hello world!"); 
win1.exit(); 
app_common.exit(); 

Возможно, это не лучший способ работы, но в настоящее время я так и делаю.

Извините за мой английский. Надеюсь, это вдохновит вас.

+0

Большое спасибо, xavilage. Звучит интересно. – stasde

+0

дайте мне знать, если вы хотите получить более подробную информацию. – xavilage

+0

_Спасибо за вашу помощь, @ xavilage._ 1. У вас есть базовый класс для UIMaps? 2. Вы проводите тесты и UIMaps в отдельных проектах? – stasde

0

Я бы рекомендовал использовать что-то вроде Code First или CodedUI Page Modeling (что я написал), чтобы создать абстракции над вашим пользовательским интерфейсом с высокой степенью проверки.

Даже без этих фреймворков вы можете легко писать абстракции по своим тестам, чтобы ваше тестовое решение выглядело очень похоже на ваш основной код решения.

Я написал blog post о том, как это будет выглядеть.

Как правило, я бы создал папку для каждого основного рабочего процесса в приложении и один для общего доступа. Это будет очень похоже на структуру MVC вашего приложения. Каждый элемент управления в вашем приложении станет моделью страницы в вашем проекте тестирования.

Web Project 
| 
| 
Views 
    | 
    --- Accounts 
    | | 
    | --- Create 
    | --- Manage 
    | 
    | 
    --- Products 
     | 
     --- Search 


Test Project 
    | 
    | 
    --- Page Models 
      | 
      --- Accounts 
       | 
       --- ICreateAccountPageModel (interface) 
       --- CreateAccountPageModel (coded ui implementation) 
       --- IManageAccountPageModel 
       --- ManageAccountPageModel 
      --- Products 
       | 
       --- ISearch 
       --- Search 

    | 
    --- Tests 
      | 
      --- Accounts 
       | 
       --- CreateAccountTests 
       --- ManageAccountTests 
      --- Products 
       | 
       --- SearchProductTests 

Модели страниц представляют собой тестируемую страницу (или контроль над тестированием при более современном веб-разработке). Они могут быть написаны с использованием подхода Test Driven без того, что пользовательский интерфейс еще не разработан.

Создание учетной записи будет содержать имя пользователя, пароль и подтверждение ввода пароля.

Создание учетной записи страницы модель будет иметь методы для установки входов, проверки состояния страницы, нажав кнопку регистра и т.д.

Тесты будут проверять снова интерфейс вашей страницы модели. Реализация будет написана с использованием кодированного пользовательского интерфейса.

Если вы используете шаблон MVVM на своем веб-сайте, ваши модели страниц окажутся очень похожими на ваши модели просмотра.

Смежные вопросы