Управляти тестами стало легше: перспектива моделі користувацького досвіду, Різне, Програмування, статті

Зміст



Введення


У багатьох проектах з розробки програмного забезпечення (ПО) не приділяється достатньої уваги тестуванню, і тому не виконується строга відповідність тестів, необхідним для отримання хорошого програмного продукту. Часто в цьому звинувачують недосвідченого керуючого по тестах, але іноді просто не вистачає часу на те, щоб одночасно укластися в терміни реалізації проекту і використовувати всеосяжний підхід до тестування.


Однак, за допомогою перспективного планування, яке підтримується за допомогою Rational Unified Process (або RUP), Колективи, що працюють над проектами, можуть забезпечити необхідний запас часу на тестування протягом всього життєвого циклу розробки. RUP забезпечує, поряд з іншими функціями, ітеративний і заснований на прецедентах використання підхід до розробки ПЗ. Цей підхід вимагає від колективу розробників вказівки правильних вимог до управління, як до інкрементний додаванням можливостей, так і до тестування, заснованому на тестових сценаріях. Експлуатаційні прецеденти пропонують добре описані етапи взаємодії користувача з системою. Як правило, етапи експлуатаційних прецедентів можна використовувати як тестових процедур, тому існує тенденція до зіставлення проходження експлуатаційних прецедентів і тестових сценаріїв.


Що таке тестовий сценарій? RUP визначає це так:


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


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


Є два головні елементи, які в разі їх своєчасного і правильного визначення, полегшать тестування:



Після визначення цих елементів всі інші зусилля з управління тестами стають на свої місця. Ця стаття описує, як відбувається управління тестами згідно моделі користувацького досвіду (UX – User Experience).1)


Тестування і модель користувальницького досвіду


Проекти приймають модель користувальницького досвіду (UX) як частина операцій розробки ПЗ, оскільки вона дозволяє їм моделювати інтерфейси – тобто фізичний і психологічний досвід використання створюваного додатка. Отже, модель UX формує узагальнення прототипу додатку. Це комбінація моделювання та збору вимог для створення прототипу, яка найбільш цікава фахівцям з проведення тестів. Сьогодні все більше число колективів, що працюють над проектами, знають, як створювати модель UX до створення прототипу. Якщо Вам необхідно визначити тестові сценарії для функціонального тестування, можна почати з розгляду моделі UX. Оскільки вона описує те, як користувач буде працювати з інтерфейсами для досягнення своїх цілей, то звідси природним чином можна отримати функціональні тестові сценарії. Також її можна використовувати для визначення робочого навантаження для тестування продуктивності. Отже, модель UX стає для колективу з тестування тестовим мотиватором. RUP визначає тестовий мотиватор наступним чином:


Щось, що надає стимул до проведення тестів, спонукає фахівців з тестування до дій і підштовхує їх до проведення тестів. Тестові мотиватори допомагають визначити і зробити видимими ті речі, які будуть спонукати фахівців з тестування оцінювати відповідні аспекти даної версії ПЗ: узагальнено, тестові мотиватори зазвичай є певні ризики якості.


Визначення тестових сценаріїв


Давайте розглянемо, як процес моделювання UX починає виявляти тестові мотиватори.


У типовому проекті спочатку моделюється екран, який буде бачити кінцевий користувач. Це робиться з використанням стереотипів класів << екран >> і / або << форма введення >>. Екрани з’єднуються разом в ланцюжок діаграми зміни екранів, яка представляє собою використання програми будь-яким чином. Текстовим доповненням цього подання є архів експлуатаційних прецедентів. Численні експлуатаційні прецеденти описують те, як користувач взаємодіє з додатком. Всі головні шляхи, якими користувач може використовувати додатки, представляє навігаційна карта.


Ми пройдемо через приклад покупки квитка в кіно (Purchase Movie Ticket) на основі моделі UX, яка складається з навігаційної карти (рисунок 1), архіву експлуатаційних прикладів покупки квитка в кіно (рисунок 2) і низки екранів (рисунок 3).


Ось кроки, які необхідні для отримання чорнового плану управління тестами:



Розуміння навігаційної карти


Рисунок 1 показує навігаційну карту для декількох екранів, які стосуються одного архіву експлуатаційних прецедентів. Для завершення транзакції покупки квитка в кіно користувач повинен взаємодіяти з трьома екранами і двома формами введення даних. Ці дві форми введення даних (стандартно звані << форма введення >>) служать для введення вхідних значень, таких як ім’я користувача і пароль. На рис. 1 кожен екран має середній розділ, який показує, що користувач може бачити, і нижній розділ, який показує, що користувач може робити.

Малюнок 1: навігаційна карта для архіву експлуатаційних прецедентів


Визначення значущих транзакцій


Навігаційна карта показує всі перехресні зв’язки між екранами. Розробник тестів може використовувати ці зв’язки для моделювання потоку транзакцій. Для даного прикладу створення тестових сценаріїв, які зіставлені навігаційним потокам, наведено в таблиці 1.


Таблиць






































































Серійний номер  Тестовий
сценарій
 
Опис  Чергування
екранів:
<< Екран >>
 
Набори
даних:
<< Форма
введення >>
Або тестові
дані
 
Сценарій
тестування
 
Залежність  Очікуване
значення
 
1  Основний потік  Купівля
квитків у кіно
MainFrm (основна форма) Форма реєстрації Реєстрація Немає
      Сторінка фільмів Форма вибору фільму Вибір фільму MainFrm (основна форма)
      Результати виборафільма   Сторінка результатів Сторінка фільмів Корекція вартості квитків
2  Подчин-енний потік  Попередньо вельних перегляд фільму MainFrm (основна форма) Регістру-Ціон форма Реєстрація Немає
      Сторінка фільмів Тестові дані: Назва фільму Вибрати фільм MainFrm (основна форма)  
      Показати рецензію на фільм   Відобразити
рецензію
Сторінка фільмів Витягти
правильну
рецензіюна
фільм
Загальна кількість тестових сценаріевОжідаемое час запису на один тестовий сценарійУсіліе  x
y
x*y*2

Спочатку фахівцям з тестування необхідно побачити всі значущі транзакції, які необхідно перевірити. Зазвичай кожна значуща транзакція відповідає одному тестовому сценарієм. Під терміном “значуща” розуміється значення, з точки зору користувача, для виконання певної задачі за допомогою програми. Згідно з цим визначенням, значущою є тільки завершена і коректна транзакція, оскільки неповні та неточні транзакції не виконують повністю бажання користувача. З навігаційної карти видно два можливих шляхи для досягнення двох кінцевих точок: Показати рецензію на фільм і Результати вибору фільмів. У таблиці вони відповідають основним та підлеглому потокам.


Про незавершених операціях ми поговоримо в розділі “Деталізація тестових сценаріїв”. Незавершені транзакції в архіві експлуатаційних прецедентів відповідають альтернативному потоку.


Оцінка зусиль з тестування


Таблиця 1 також пояснює зусилля, необхідні для виконання тестових сценаріїв. Зусилля прив’язуються до технології, яка необхідна для досягнення кінцевого результату. Якщо для автоматизації зусилля використовується засіб для запису і відтворення, то разом узяте мінімальний час на реалізацію тестових сценаріїв становить подвійну час процесу запису. Це буде важливим фактором при прийнятті рішення про необхідні ресурси та плануванні тестів. Наприклад, якщо користувачеві необхідно y хвилин для досягнення сторінки результатів вибору фільму і завершення транзакції покупки, то для отримання сумарного часу (z), необхідного на запис і відтворення однієї такої транзакції, можна помножити y на 2. Сумарні необхідні зусилля будуть рівні z, помноженому на кількість тестових сценаріїв. Це кінцеве число можна використовувати для ітераційного планування.


Визначення тестових даних


Стовпець 5 в таблиці 1 показує набори даних, необхідні для виконання тестових сценаріїв. Тестові дані для першого тестового сценарію (Основний потік 1) можна легко вивести, глянувши на реєстраційну форму і форму вибору фільму. Для знаходження тестових даних для другого тестового сценарію (Підлеглий потік 1) необхідно перевірити дії, які ведуть до відображення наступного екрану, який перераховує фільми, які можна вибрати.


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


Планування модульності


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


Із застосуванням модульності супровід сценаріїв тестування стає зручніше. Шляхом розбивки транзакцій на послідовності екранів (як в стовпці 4 таблиці 1) можна досягти модульності в тому випадку, якщо, наприклад, один екран відповідає одним сценарієм тестування.


Таким чином, при зміні основного екрану реєстрації (MainFrm), зі стовпця сценарію тестування (стовпець 6 таблиці 1) можна побачити, що зачіпаються два тестових сценарію. Все, що необхідно зробити, – Це змінити лише один сценарій: сценарій реєстрації.


Модульність вимагає створення залежностей між транзакціями, а отже, необхідний стовпець “Залежність” в таблиці 1. Залежність може також мати більш широкий контекст: наприклад, вона може показувати стан програми, від якого залежить поточна транзакція, або показувати завершення виконання іншої транзакції. Для виконання першого тестового сценарію необхідно виконати три сценарії у такій послідовності: сценарій реєстрації, сценарій вибору фільму і сценарій сторінки результатів.


Визначення правильності транзакцій


Останній стовпець в таблиці 1 визначає очікувані результати тестових сценаріїв. Цей стовпець є необхідним. Не всі кроки перевіряються, оскільки це було б перебільшення тестування. Оскільки метою є можливість для користувача виконання транзакції, то перевірка обмежується кінцевим результатом тієї транзакції, яка перевіряється. Для тестового сценарію “Основний потік” перевіряється вартість квитка (чи білетів) на фільм, отримана із системи. Це мета тестування. У проміжній перевірці необхідності немає.


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


Коротко кажучи, навігаційна карта дозволяє управляючому по тестам наступне: (1) розробляти високорівнева чернетку тестових сценаріїв для всього програми, (2) визначати кількість створюваних тестових даних. Цей чернетку можна деталізувати в ступені, достатньої для вказівки перевіряються транзакцій і очікуваних вихідних значень.


Каталог тестових ідей


Тут варто згадати “тестові ідеї” і каталог тестових ідей (артефакт RUP). Не покриті до теперішнього часу тестом транзакції є тестовими ідеями. Тестові сценарії, які вони представляють, як і раніше потребують уточнення і деталізації. RUP визначає тестову ідею таким чином:


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


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


У більшості організацій досвід тестування є зборами значно розрізняються досвіду членів колективу, що працює над проектом. А методологія уніфікації отриманого досвіду зазвичай відсутня. В якості вирішення цієї проблеми каталог тестових ідей надає механізм для збору та повторного використання досвіду тестування різних колективів і окремих працівників. Щоб бути по-справжньому корисним, каталог тестових ідей повинен надавати чітку відповідність між тестовими ідеями та їх реалізацією (тобто всіма відомими тестовими сценаріями).


Прикладом каталогу тестових ідей служить таблиця 2. Відповідна інформація щодо проектів збирається в рядках “Створити (записи про квитки в кіно)” і “Вибрати (рецензії на фільм)”. Також можуть існувати подібні тестові ідеї з іншого проекту, як в рядку “Створити (інші)”.


Таблиця 2: каталог тестових ідей




































Серійний номер  Функції  Опис проекту  Розгляд тестів  Подробиці вимог до проекту  Сценарій тестування проекту  Набори тестових даних проекту 
1  Створити (записи про квитки в кіно)  Привілейований профіль реєстрації, можливість створювати запис про квиток, одночасна можливість вибору місця. Використання різних профілів, використання різних комбінаціймест, виборав ремінь і т.д. Див вимоги до проекту xx Розділ xx Реєстрація Вибрати екран Див. таблицю, яка містить набори тестових даних
2  Вибрати (рецензії на фільм)  Відображення статичної сторінки Вибрати різні комбінації відповідно до обсягу повернутих даних і т.д. Див вимоги до проекту xx Розділ xx    
3  Створити (інші)           

Деталізація тестових сценаріїв з використанням архіву експлуатаційних прецедентів


Після чорнової створення високорівневих тестових ідей працює над проектом колектив може починати деталізувати тестові сценарії.


Для визначення реальних етапів тестових сценаріїв ми пошлемося на архів експлуатаційних прецедентів, який є етапами експлуатаційних прецедентів з додатковою інформацією про досвід користувача. Архів експлуатаційних прецедентів показаний на малюнку 2.

Рисунок 2: архів експлуатаційних прецедентів


Щоб архів експлуатаційних прецедентів був корисний для деталізації тестових сценаріїв, необхідні деякі додаткові відомості:


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


Чергування екранів


У моделі UX існують і інші елементи. Наприклад, чергування екранів, показане на малюнку 3, є циклограми, а сполучення між екранами є діями, які може виконати користувач. На кожен архів експлуатаційних прецедентів існує зазвичай одна послідовність екранів. Слід зауважити, що окремі дії входять у тимчасову послідовність і можуть залежати від раніше вироблених дій. Так що транзакції повинні враховувати такі послідовності. Ця циклограма дозволяє конструктору тестів додатково уточнювати тестові сценарії. Однак, більша частина наведеної вище інформації доступна в текстовому форматі з архіву експлуатаційних прецедентів, так що стосовно чергування екранів ми не будемо надавати додаткову інформацію та опис дій.

Рисунок 3: чергування екранів при купівлі квитків у кіно


Висновок


Управління тестами включає в себе різні дії: створення колективу працівників, розробку головного плану тестування, який деталізує використовувані для тестування методи і мету тестування з точки зору організації, розробку тестового плану, що відноситься до колективу, який працює над проектом, і багато іншого.


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


Примітки



  1. Доброю довідкової книгою по моделі UX є “Створення Web-додатків за допомогою UML”, 2-я редакція, автор Джим Конелла (Jim Conallen) (видавництво Addison-Wesley, 1999 р.).

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*