Шаблони автоматизованого інтерфейсу та кращі практики для настільних додатків

Фон

Наразі я автоматизую деякі тести для плагіна для MS Office. Ми створюємо тести кодованого інтерфейсу в VS 2010. Я вважаю, що я міг би використовувати інструмент " Зашифрований тест користувальницького інтерфейсу ", але це не дуже відповідає моєму конкретному випадку.

Завдяки цьому я створив власний клас класу та розширення інтерфейсу для кожного інтерфейсу управління / карта, де я додаю різні функції дій. Наприклад, натисніть кнопки або затвердіть деякі значення інтерфейсу користувача.

Сценарії тестових випадків є у тестових класах.

Я новачок у цій галузі, а також я новачок у роботі тестером автоматизації.

Питання

Чи люди будуть люб'язними поділитися своїм досвідом та порадами щодо передового досвіду автоматизації тестів на настільних додатках з точки зору програмування / дизайну?

Найкраща практика тестування автоматичного інтерфейсу користувача - це робити якомога менше. Користувацькі інтерфейси часто змінюються, це означає, що вам постійно доведеться оновлювати автоматизацію. Як правило, бажано структурувати код продукту таким чином, що дозволяє автоматизоване тестування без автоматичного інтерфейсу користувача.

Однак, не завжди можна позбутися автоматичної інтерфейсу користувача. Ви згадуєте офіс, тому я припускаю, що ви кодуєте для Windows та використовуєте .Net. Я досить багато займаюся своєю нинішньою роботою. Ось деякі речі, які я навчився.

1) Подивіться на бібліотеки автоматизації UIA, які були представлені в .Net 3.0. Вони забезпечують широку та досить просту у використанні бібліотеку для автоматизації. (http://msdn.microsoft.com/en-us/library/ms753107.aspx)

2) Завантажте UISpy (http://msdn.microsoft.com/en-us/library/ms727247.aspx)

3) Зробіть інтерфейси вашого продукту автоматизованими.

3a) Якщо це WPF, покладіть AutomationIDs на все.

3b) Спробуйте створити відмінні назви класів управління та вікон (назви класів UI, а не ім'я класу вихідного коду). Якщо ви не знаєте, що я маю на увазі, завантажте інтерфейс шпигуна і почніть дивитися у вікна. Зауважте, скільки вікон у різних додатках має назву класу # 32770. Це назва класу для діалогового вікна Windows. Будь-яке вікно, яке розширює діалогове вікно і не встановлює власне ім'я, за замовчуванням до цього. Це викликає всіляке горе з точки зору автоматичної інтерфейсу користувача.

4) Уникайте тверджень Thread.Sleep (). Спробуйте використовувати замість них офіціантів (див. Документи UIAutomation).

5) НІКОЛИ не змішуйте тестовий код з кодом автоматичного інтерфейсу користувача. Створіть окремі бібліотеки для виконання автоматизації інтерфейсу користувача. Викликайте ці бібліотеки зі своїх тестів. Коли інтерфейс зміниться, це значно полегшить оновлення автоматизації.

6) Завжди реєструйте слухача для події в інтерфейсі, перш ніж виконувати дію, яка призведе до події. На практиці це означає, що ви будете працювати з нитками.

6а) Приклад: не починайте чекати події, що відкрилася, після натискання на кнопку, щоб відкрити вікно. Вікно може відкритися до того, як офіціант зареєстрований і ніколи не отримає подію.

7) Ніколи не вважайте, що саме відкрилося вікно, яке ви хочете. У Windows можуть несподівано відкритися всі види вікон.

Я міг би продовжити більше, але це стає трохи довше.

Створіть функціональні тести з випадків повторного використання

Коли настає час тестування вашої програми до кінця in situ, ви виконуєте функціональне тестування. Зазвичай у вас буде набір вимог, на які ви тестуєтесь, і ви зможете побудувати різні випадки використання, які їх представляють.

Як приклад, розглянемо випадок використання "Увійти як стандартний користувач". Ваш тестовий фреймворд запускає програму, чекає екрана входу, вводить деякі облікові дані, натискає кнопку входу та перевіряє, що відповідний екран тепер показує, що вхід був успішним.

Після того, як ви зробили випадок використання "Увійти як стандартний користувач", ви захочете зробити це на тому, щоб зробити щось інше, можливо, "Редагувати мої дані про користувача". Ви не хочете повторювати весь код із випадку використання "Логін як стандартний користувач", тому ви просто зробите посилання на тестовий рамковий код, який робить цей біт.

Це означає, що у вас є якийсь функціональний тест на перезахист, який містить перелік випадків використання. Ці випадки використання містять методи тестових рамок, щоб викликати поведінку програми (натисніть кнопку X) та перевірити поведінку (екран став синім).

Загалом, ви можете створити тіло випадків повторного використання, які орієнтуються на конкретні послідовності та перевіряють конкретні відповіді, а потім об'єднати їх у різні функціональні тести, які тісно співвідносяться з бізнес-вимогами. Як тільки ви це встановите, ви зможете повністю автоматизувати весь процес збирання .

Якщо вам цікаво читати далі, я писав про цей підхід в іншому місці, але стаття орієнтована на веб-додатки на Java (за допомогою Maven та SeleniumRC), а не на настільні програми, про які ви запитували.