Автоматизоване тестування при розробці ПЗ
Віктор Ематін, Борис Позина
Анотація
Стаття
розглядає один з найважливіших етапів при розробці складних програмних
систем - етап тестування. Сучасні засоби розробки дозволяють швидко
побудувати "каркас" програми, але наскільки це якісно? У статті
описуються основні завдання тестування, види тестів і критерії тестування.
Наводяться рекомендації з побудови процесу тестування.
Тестування - один з найважливіших етапів перевірки
якості розробленого ПЗ.
Так
склалося, що відповідь на питання про якість ПЗ в більшості випадків дає тільки
його експлуатація - як то кажуть, "життя покаже". Разом з тим замовник
вправі вимагати від розробника гарантій. Велика кількість невдалих спроб отримати
замовлене ПО високої якості викликає у замовників законні питання: а
чи можливо в принципі створювати якісне програмне забезпечення? як цього домогтися? що
замовник повинен вимагати від підрядника, щоб отримати якісне програмне забезпечення? як
повинен працювати сам замовник?
Для
оцінки якості ПЗ завжди застосовується цілий комплекс заходів, серед яких
тестування ПЗ на предмет виявлення помилок - один з найважливіших етапів.
1.
З чого ж починається тестування? Для його проведення необхідні об'єкт
тестування - у даному випадку ПО - і еталон, за яким цей об'єкт
порівнюється. ПО-це складний об'єкт, який змінюється за складом і перевіряється
властивостями на різних стадіях розробки. Важливо розуміти, що якщо розробник і
замовник не сформулювали вимоги до ПЗ ще до початку його розробки, то,
по-перше, замовник навряд чи отримає саме те, що хотів, і, по-друге, ПЗ,
яке він все-таки отримає не можна буде перевірити, оскільки об'єкт є, а
еталона немає.
Інакше
кажучи, тестування ПЗ проводиться на відповідність наперед визначеним
вимогам (по функціональності, продуктивності, безпеки та ін.)
Оскільки об'єкт тестування складний, необхідний системний підхід до
тестування, його організації та проведення.
Отже,
перший висновок: треба чітко визначати вимоги до ПЗ на самому початку розробки,
але не "вимоги взагалі" типу "ПЗ повинно працювати", а
вимоги, які можна перевірити. При цьому вимоги до ПЗ підрозділяються на
функціональні (які функції і з якою якістю повинно реалізовувати ПО) і
нефункціональні (обмеження на час вирішення завдання, швидкість доступу до
даними, вимоги до займаним ресурсів і т. п.). У замовника і розробника
повинна бути можливість порівняти поточне функціонування системи з її
еталонним (очікуваним) поведінкою. При цьому рекомендується використовувати
ітеративний підхід, тому що раннє тестування критичних областей значно
знижує ризик невдачі і вартість виправлень для всього проекту розробки ПЗ.
2.
Недосвідчений замовник завжди налаштований на те, щоб дати завдання, а потім
побачити кінцевий результат. Це самий вірний спосіб одержати неякісне
ПЗ. Але низька якість невигідно обом сторонам. Замовнику тому що
замовлене їм ПО не можна використовувати до того моменту, коли воно вже потрібно, і він
втрачає час і гроші, оскільки ПЗ повинно працювати на його бізнес, а воно не
працює (тобто не приносить грошей), та ще й відбирає додаткові ресурси на
доопрацювання. Розробнику тому, що він втрачає авторитет, допрацьовує ПО за
свій рахунок (втрачає гроші) і не може швидко переключитися на іншого замовника
(втрачає замовлення). Набагато ефективніше поетапно здійснювати контроль над ходом
відпрацювання ПЗ. Саме такий підхід приносить найбільший ефект і при розумній позиції
замовника буде напевно позитивно сприйнятий розробником. Для успішного
проведення тестування надзвичайно важливо ретельно спланувати ці роботи.
Рекомендується використовувати шаблони документів, у тому числі плану тестування,
розроблений відповідно до вимог міжнародного стандарту IEEE
829-1983 Standard for Software Test Documentation.
Ми
не будемо в цій статті описувати весь технологічний процес створення ПЗ.
Зауважимо лише, що обговорення технічного завдання, технічного проекту,
архітектури системи із замовником - це теж частина процесу виявлення помилок
та уточнення еталону. Одне з головних правил для розробника - треба дуже
щільно працювати з замовником, тоді обидві сторони будуть краще розуміти, що
відбувається при створенні ПЗ в кожен конкретний момент і як швидше знаходити
спільні рішення.
3.
І все-таки, що означає "поетапне тестування"? Зауважимо відразу, що
багато замовників не думають про те, що тестування коштує грошей і взагалі витрат
ресурсів і що за якість треба платити. Однак, усвідомивши це, замовник завжди
повинен розуміти, за що саме він платить і як побачити результати.
Прийнято
розділяти тестування за рівнями завдань і об'єктів на різних стадіях і етапах
розробки ПЗ (див. таблицю):
тестування
частин ПЗ (модулів, компонентів) з метою перевірки правильності реалізації
алгоритмів - виконується розробниками;
функціональне
тестування підсистем, ПЗ в цілому з метою з'ясувати рівень виконання
функціональних вимог до ПЗ - рекомендується проводити окремою групою
тестувальників, не підпорядкованої керівнику розробки;
Навантажувальне
тестування (в тому числі стресовий) для виявлення характеристик
функціонування ПО при зміні навантаження (інтенсивності звернень до нього,
наповнення бази даних і т. п.) - для виконання цієї роботи потрібні
висококваліфіковані тестувальники і дорогі засоби автоматизації
експериментів.
Етапи
тестування
Вид тестування
Стадія, етап
Об'єкт
Критерій
Структурний,
надійності
Розробка
Компоненти
Покриття розгалужень,
функції
Складальне
Розробка
Підсистеми
Функціональність,
ступінь перевірки компонентів
Функціональне
Розробка
Система в цілому
Відповідність
функціональним вимогам ТЗ
регресійні
Розробка,
супроводження
Система в цілому
Перевірка якості
внесення змін
Навантажувальне
Розробка,
супроводження
Система в цілому
Оцінка
статистичних характеристик системи, відповідність ТЗ, ТТХ, підбір
конфігурації обладнання
Стресове
Розробка,
супроводження
Система в цілому
Коректність роботи
системи при граничних навантаженнях
Коли
зрозуміло, що і навіщо потрібно тестувати, і є план дій, саме час
задуматися про те, як це зробити ефективніше, швидше і якісніше.
Сучасне ПЗ - це складний об'єкт, і вручну з ним справлятися важко і
дорого. До того ж при "ручному" тестуванні результати кожного
виконання тестів пропадають, і їх важко повторити. Для того щоб збільшити
обсяг перевірок і підвищити якість тестування, забезпечити можливість повторного
використання тестів при внесенні змін в ПЗ застосовують засоби
автоматизації тестування. До їх числа відносяться засоби автоматизації
функціонального і навантажувального тестування клієнт-серверних і Web-додатків:
Rational TestStudio, Mercury LoadRunner, Segue SilkPerformer, а також менш
популярні продукти фірм Compuware, CA, Empirix, RadView Software та ін
Тестування
треба займатися не тільки постійно, але і систематично. Якщо не забувати, що
це процес виявлення помилок, то варто вимагати від розробника, щоб він
періодично силами спеціально створених груп проводив так звані
"review", або "структурні перегляди" проектних матеріалів
і аудит вихідних кодів програм. Замовник має право домовитися з розробником про
пред'явленні подібних матеріалів або про не дуже глибокому контролі ходу такого
процесу. Він зацікавлений в тому, щоб в організації розробника були
поставлені процеси. У цьому випадку замовник може бути впевнений, що якість
розробляється ПО контролюється і забезпечується в процесі розробки. Саме
на це спрямовані відома модель технологічної зрілості СММ (Capability
Maturity Model, www.sei.cmu.edu/cmmi/orgdocs/conops.html) і стандарт ISO 15504.
Бажано,
щоб на етапах складання, комплексного налагодження і дослідної експлуатації розробник
фіксував інтенсивність виявлення помилок, - тоді за характером зміни
цієї інтенсивності можна буде судити про зміну якості ПЗ і, наприклад, про
доцільності його передачі в дослідну або постійну експлуатацію. Нарешті,
необхідне проведення комплексу випробувань ПЗ на відповідність вимогам ТЗ або
інших нормативних документів, на можливість ефективно працювати з ПЗ на
основі використання програмної документації, приймально-здавальних та інших видів
випробувань, що забезпечують замовнику впевненість в працездатності створеного
для нього ПЗ.
Ну
а що ж між випробуваннями, коли ПО ще тільки створюється? І на цьому етапі
дуже важливо, щоб діяльність з тестування велася планомірно. Хоча
тестування - процес досить творчий, його можна і потрібно планувати.
Це означає, що на кожному етапі робіт повинні бути вибрані критерій якості і
критерій завершення тестування. Перший потрібен для того, щоб тестувальник або
група тестувальників розуміли, що і на відповідність чому вони перевіряють. Те
є, які об'єкт і еталон і які властивості об'єкта перевіряються. Другий
критерій допомагає прийняти рішення у випадку, коли вичерпуються ресурси,
відведені на тестування, він відповідає на питання, за яких умов
тестування може бути завершено.
План
при тестуванні дійсно потрібен. Адже для перевірки складного об'єкта можна
і треба застосовувати різні стратегії, що дозволяють добиватися максимального
результату при існуючих обмеженнях на ресурси тестування. Наприклад,
якщо перевірити найбільш ймовірні шляхи в програмі, можна бути впевненим, що
вже на них-то ПО буде працювати правильно. Крім того, план тестування дозволяє
заздалегідь визначити, що потрібно підготувати для проведення тестування. Скажімо,
багато розробників ПЗ починають готуватися до навантажувальні експериментів тільки
тоді, коли настав час їх проведення. Адже заздалегідь відомо, що для
таких експериментів знадобиться випробувальний стенд (комплекс обладнання з
встановленим системним і прикладним ПЗ), і відомо який, буде потрібно
наповнена вихідними даними база даних, її зміст буде змінюватися, і цю
базу іноді доведеться відновлювати. Нарешті, буде потрібна інформація, яку
часто називають нормативної або довідкової і яка повинна зберігатися у складі
ПО або в базах даних.
План
тестування визначається міжнародним стандартом IEEE 829-1983. У ньому повинні
бути передбачені як мінімум три розділи містять, наступні описи:
що
буде тестуватися (тестові вимоги, тестові варіанти);
якими
методами і наскільки докладно буде тестуватися система;
план-графік
робіт і необхідні ресурси (персонал, техніка).
Додатково
описуються критерії вдалого/невдалого завершення тестів, критерії закінчення
тестування, ризики, непередбачені ситуації, наводяться посилання на
відповідні розділи в основних документах проекту - план управління
вимогами, план конфігураційного управління і т.п.
Як
підготуватися до тестування, що саме потрібно для його проведення? Як ми вже
з'ясували, необхідні перевіряються вимоги, потім кожне з них пов'язується з
одним або кількома тестовими вимогами. Далі логічний набір тестових
вимог групується в тестові сценарії, перевірка яких дозволить дати
однозначну відповідь на питання, чи коректно здійснюється введення, чи правильно
працює та чи інша бізнес-функція в системі. Цей результат зрозумілий не тільки
фахівцям, але і кінцевому користувачеві. Основні об'єкти автоматизації
тестування - системи, що реалізують роботу клієнтської частини. Ключовою особливістю
тестування клієнт-серверних систем є можливість перевірки коректності
функціонування та задовільного швидкодії системи через роботу
клієнтської частини. Таким чином, ретельно і всебічно перевіривши ці
можливості, ми отримуємо гарантію працездатності системи для кінцевого
користувача. Ще один важливий аспект організації робіт - зберігання створених
тестів. Ми рекомендуємо ставитися до тестів так само, як і до вихідного коду, т.
тобто потрібно використовувати версійність сховища для можливості відновлення
тестів попередніх версій системи (MS SourceSafe, Rational ClearCase ,...). Це
стане в нагоді на етапі супроводу ПЗ і дасть можливість повторного
використання готових тестів на декількох версіях системи. Аналогічно потрібно
ставитися і до тестових даними, створюючи архіви, копії та версії вмісту БД.
Як
проводити тестування? Тестування - це завжди експеримент. Для його
проведення потрібна база. Як у будь-якому експерименті, при тестуванні потрібно десь
збирати накопичену інформацію, обробляти результати. Є найбільше
поділ видів тестування: статичне і динамічне. При статичному
тестуванні ПЗ не виконується, а відбувається аналіз коду, структур даних.
Динамічне тестування, навпаки, вимагає виконання тестового ПЗ. Для
цього потрібні не тільки засоби автоматизації тестування, але і допоміжні
кошти. Відомо дуже багато засоби побудови і автоматичної генерації
тестів, засобів моніторингу ресурсів під час виконання тестів, засобів вимірювання
та візуалізації результатів тестування, засобів статистичної обробки
результатів і т. п.
Обмежений
обсяг статті не дає нам можливості докладно описати повний комплекс
заходів для забезпечення впевненості замовника у тому, що ПЗ добре протестовано.
Крім того, завжди є особливості тестування, специфічні для
конкретного ПЗ. Не у всіх розробників є необхідні засоби автоматизації
тестування. Багато замовників використовують для проведення тестування
незалежні організації, доручаючи їм аутсорсинг тестування ПЗ. Вони роблять це
заради більшої впевненості в якості створюваного для них ПЗ, перш за все в
наступних відповідальних областях:
білінгові
системи;
системи
масового обслуговування клієнтів;
CRM-рішення;
введення
в дію нових ERP-систем для оцінки якості їх роботи в умовах мережі і
інфраструктури замовника в цілому;
тестування
ПО при його супроводі і розвитку, постачання нових версій і релізів;
вибір
серверів, на яких працює ПЗ, і т. п.
Список літератури
1.
Агапов А. С., Зенин С. В., Михайлівський Н. Е., Мкртумян А. А. Оцінка і
атестація зрілості процесів створення і супроводу програмних засобів і
інформаційних систем (ISO/IEC TR 15504-CMM), Пер. з англ. Москва, "Книга
і бізнес ", 2001.
2.
Мартін Фаулер. Нові методології програмування.
www.maxkir.com/sd/newmethRUS.html.
3.
Rational Unified Process, Rational Software Corp., 1987-2002.
Для
підготовки даної роботи були використані матеріали з сайту http://www.citforum.ru/
