НОУ ІНТУІТ, Лекція, VSTS тестування

Виділимо такі можливості VSTS із тестування:

інтегрована система відстеження помилок;
засоби розробки модульних тестів;
засоби організації тестових пакетів;
автоматичне тестування Web-додатків (зокрема і навантажувальний).

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

Система відстеження помилок

Загальне. Система відстеження помилок в VSTS реалізована з урахуванням системи управління елементами робіт. Адже помилки (bugs) – особливий тип елементів робіт. Порівняно з іншими системами відстеження помилок, інтегрована система на основі системи управління елементами роботи має низку таких серйозних переваг.

Можливість завдання зв'язку змін програмного коду з помилками, які вони призначені виправити, дозволяє легше підтримувати та розвивати систему, уникаючи значної регресії.
Інтеграція із системою автоматичного складання дозволяє легко відстежувати те, в яку складання увійшло виправлення тієї чи іншої помилки, не вимагаючи від розробників додаткових дій.
Можливість легко будувати зведені звіти дозволяє легко відстежувати поточнеякість продукту.
Можливість інтеграції з офісними продуктами і, зокрема, з продуктом Microsoft Project, дозволять простіше планувати та керувати процесом виправлення помилок, водночас система автоматичних оповіщень дозволяє зробити цей процес більш оперативним.

На рис. 15.1 представлено опис життєвого циклу елемента роботи "помилка" ( Bug ) із шаблону процесу VSTS під назвою MSF for Agile 4.2. У цього типу елемента роботи визначено три стани:

Active – помилка потребує виправлення,
Resolve – помилка виправлена,
Close – помилка перевірена та виправлення прийнято.

На стрілках-переходах вказані причини, через які помилка перейшла у цей стан. Опишемо деякі, найчастіше зустрічаються переходи.

У стан Active помилка потрапляє, по-перше, після свого створення – тобто тестувальник знайшов нову помилку та створив відповідний елемент роботи (це початкова дія на зображенні не показана). Далі, в цей стан помилка може потрапити зі стан Resolved, після того, як тестувальник перевірив виправлення програміста і виявив, що тести все одно "падають" (причина Test failed). Якщо виправлення помилки було проведено некоректно (поведінка системи відповідає бажаному), то помилка перетворюється на стан Active через Wrong Fix . Якщо спосіб закриття помилки є неприйнятним (наприклад, тестер не згоден, що дана помилка є дублікатом інший), то використовується причина Resolution Denied. Нарешті, помилка може перейти в стан Active, якщо вона знову почала з'являтися - причини Reactivation і Regression. При цьому для тестувальника важливо не створювати нової помилки, а зрозуміти, що це стара, закрита, знову виявилася. Ця інформація допоможерозробникам швидше розібратися з виправленнями – переглянути зміни вихідних текстів, які закривали цю помилку і виправити їх. При цьому може дуже ефективно працювати зв'язок, який забезпечує VSTS для елементів робіт та змінами у засобі контролю версій – що детально обговорювалося в лекції про підтримку TFS конфігураційного управління.

У стан Resolve помилка переходить, по-перше, після того, як розробник виправив її. У цей стан розробник може перевести помилку ще й через те, що це не помилка, а властивість (тестувальник неправильно зрозумів вимоги до системи або проектну специфікацію) – причина As Designed. А також тому, що помилка повторює іншу, знайдену раніше помилку (Duplicate), помилка не відтворюється у розробника (Unable to reproduce) і т.д.

У стан Close помилка переходить, по-перше, коли тестувальник прийняв її виправлення (причина Fixed). По-друге, коли він погодився з думкою розробника, що вона повторна (Duplicated), не відтворюється (Unable to reproduce) та ін. З цих самих причин сам розробник може перевести помилку в стан Close прямо зі стану Active. Щоправда, це може бути не будь-який розробник, а, наприклад, технічний керівник проекту чи архітектор. Решта розробників може мати права переводити помилки самостійно у стан Close, а мають діяти через тестувальників.

Як створюється опис помилки. Створення нової помилки може відбуватися або за допомогою пункту меню Team Explorer " Team / Add Bug ...", або за допомогою додавання пов'язаних елементів роботи для завдань, при реалізації яких помилки були виявлені. Крім того, провал автоматичного складання або прогону тестів може бути тригером для автоматичногостворення помилки. Вікно для опису помилки показано на рис. 15.2.

Зв'язок змін вихідних текстів і помилок. У лекції про конфігураційне управління ми докладно розглянули зв'язок зміни вихідних кодів з елементами роботи. Тепер подивимося те що, як помилка пов'язані з цими змінами (тобто ми дивимося той самий завдання, але з іншого боку – з боку елементів роботи, і вибираємо один специфічний тип елемента роботи – помилку). Всі зміни в коді, пов'язані з виправленням певної помилки, легко можна відстежити, використовуючи закладку "Links" у діалозі опису помилки. Так, на рис. 15.3 показано, що помилка пов'язана з пакетом змін, внесеним до системи контролю версій.

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

У TFS, як показано на рис. 15.5, підтримані такі типи автоматичних оповіщень.

При зміні елемента роботи (повідомлення відправляється за зміни будь-якого реквізиту). Цей вид оповіщень дозволяє оперативно дізнаватися про появу нових елементів роботи та про зміну існуючих. Наприклад, розробник може оперативно отримувати повідомлення про переведені на нього помилки.
Внесення змін до системи контролю версій. Як правило, цей тип оповіщення використовується архітекторами або технічними лідерами команди для контролю якості коду, що вноситься за допомогою регулярної перевірки внесених змін.
При автоматичній або ручній зміні атрибуту "якість" в описі результатівавтоматичного складання 1 "Якість" є атрибутом складання, що встановлюється вручну тестером після проведення тестування. На підставі значення цього атрибуту може бути прийняте рішення про готовність чи ні певної збірки до випуску чи переведення на подальші етапи тестування. . Цей тип оповіщень дозволяє керівникам проекту дізнаватися про зміну стану проекту.
При завершенні процесу автоматичного складання , незалежно від результатів. Цей тип оповіщень є корисним для всіх учасників проекту.

Модульні тести

Модульні тести як підвищення якості програмного забезпечення з'явилися досить давно, проте вони довго залишалися не підтриманими продуктами Microsoft. Вперше підтримка модульних тестів з'явилася у Visual Sutdio 2005 і доступна у виданнях Professional і вище (у тому числі і у всіх виданнях групи Team).

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

Історично одним з перших популярних інструментів, орієнтованих на організацію модульного тестування, був jUnit для Java-додатків, клонований потім під багато інших платформ. Для платформи. NET піонером тут був nUnit, який досі займає лідируючу позицію у цій ніші. Однак, лідерство nUnit серйозно похитнулося з появою підтримки модульнихтестів у Visual Studio. У порівнянні з класичними системами Visual Studio має ряд таких переваг.

Підтримана повна інтеграція в інтерфейс користувача, включаючи запуск і аналіз результатів (для інших систем інтеграція доступна за окремі гроші і не така велика).
Реалізовані можливості для легкої інтеграції у засоби автоматичного збирання (тільки для TFS Team Build).
Запропоновано додаткові засоби для опису процедури розгортання тесту (хворе місце більшості інших систем) та конфігурації інших аспектів виконання.
Є засоби автоматичної генерації сигнатур тестів та засобів доступу до приватних частин класів, що тестуються.
Підтримано керування тестовими даними, а також тестами, які використовують дані на рівні платформи.

У версії Visual Studio 2008 підтримка модульного тестування була перенесена з видань сімейства Team у видання Professional, що було цілком логічним кроком, оскільки модульне тестування є загальною практикою, яка застосовується як в особистій, так і командній розробці. Оскільки модульне тестування більше не є чимось специфічним для Visual Studio Team System, а його реалізація відповідає більшості стандартних пакетів у цій галузі, ми не будемо зупинятися на цій можливості докладніше.