Методологія та практика тестування ПО, Комерція, Різне, статті

Навряд чи є сенс говорити про важливість тестування в загальному процесі розробки ПЗ, адже давно відомо, що реалізація кожного етапу життєвого циклу додатків є необхідною умовою для появи якісного програмного продукту. Але, сказавши слова про рівність всіх видів робіт, потрібно визнати: протягом всієї історії розробки ПЗ – а вона налічує понад 50 років – тестування виступало в ролі падчерки, якої дістається найбільш трудомістка, рутинна і непрестижна робота*. Далеко за прикладами ходити не потрібно: авторські права розробників закріплені законодавством, їх імена можна при бажанні легко впізнати. А що нам відомо про тих, хто тестує програми, і це при те, що саме на їх частку припадає в середньому близько третини витрат по створенню ПО?


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


Потрібно відзначити парадоксальну ситуацію: при великій кількості методичної літератури і курсів з проектування та кодування ПО спостерігається практично повна відсутність матеріалів з тестування та налагодження! Як сказав відомий американський автор книг з розробки ПЗ Джон Роббінс: “Навіть якщо у вас є спеціальна освіта, б’юся об заклад, що ви ніколи не стикалися зі спеціальним курсом, присвяченим налагодженні “(див. PC Week / RE, № 9/2004, с. 61).







Види тестування з методології Rational Unified Process  


Однак ситуація дещо змінюється, одним із свідчень чого є проведені в кінці лютого в Москві компанією “Аплана” за підтримки московського представництва IBM практичні семінари “Ефективна організація процесів тестування в ході розробки і супроводу корпоративних систем “. Тема виявилася настільки актуальною, що Центр технологій IBM не зміг вмістити всіх бажаючих в один день, тому семінар довелося проводити двічі. Спочатку захід було орієнтовано на ІТ-підрозділу корпорацій, що ведуть власні внутрішньофірмові розробки, проте великий інтерес до нього проявили і спеціалізовані фірми – творці замовного і тиражируемого ПО. У загальній складності в семінарах взяли участь понад 80 керівників та фахівців корпоративних і відомчих центрів розробки і впровадження, а також ІТ-компаній.


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


Особливості організації тестування


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


Є ще один важливий момент. Тестування, в свою чергу, є лише складовою частиною налагодження – процесу доведення ПО після його написання до експлуатаційного стану. Процес цей включає дві основні процедури: виявлення помилок (тестування) та пошук і усунення їх причин. Однак, навіть враховуючи всі можливі взаємозв’язку цих робіт (наприклад, пошук причин помилок вимагає проведення спеціального додаткового тестування), потрібно підкреслити, що тестування є досить автономним, незалежним етапом життєвого циклу ПЗ. При цьому підкреслимо, що підвищення якості розробки (яке обернено пропорційно кількості помилок в додатку) безпосередньо знижує витрати на усунення помилок, але на обсяг тестування впливає зовсім не так сильно: його потрібно проводити в будь-якому випадку і бажано “по повній програмі”.


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


Говорячи про особливості процедур тестування в ІТ-підрозділах, напевно, треба виділити три основних, вельми суперечливих аспекти.



  1. Обсяг тестування дуже великий. Справа в тому, що саме в разі внутрішньофірмових розробок дуже часто вносяться зміни (багато слухачів семінару говорили про безперервному потоці коригувань за запитами підрозділів-замовників). А адже, як відомо, класичне правило розробки ПО говорить: зміна одного рядка коду вимагає повторного проведення повного циклу тестування.
  2. Як це не цинічно звучить, але розробники дуже часто не зацікавлені в зниженні кількості помилок в ПЗ, переданому в експлуатацію. Керівництво компаній оцінює роботу ІТ-відділу в першу чергу за його вмінню укластися в бюджет (час і гроші), а проблеми експлуатації програм його хвилюють значно менше. Тому виходить, що збільшення обсягів тестування підвищує витрати ІТ-підрозділу без виділення відповідних ресурсів з боку начальства**.
  3. Проведення якісного тестування вимагає наявності фахівців та інструментів відповідного профілю. А з п. 2 випливає, що ІТ-підрозділам тримати власні групи тестувальників просто невигідно.


Загальні питання тестування

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


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


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


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


Тестування – процес поетапний. Напевно, має сенс розділити перевірку працездатності програм в ході безпосереднього написання коду (самим програмістом) і після завершення основного етапу кодування (Швидше за все, спеціальними тестувальниками). Тут можна згадати про золоте правило програмування: написання кожних 20-30 рядків коду (тим більше закінчених процедур, функцій) повинно супроводжуватися перевіркою їх працездатності, хоча б у якомусь основному режимі. У той же час потрібно підкреслити і важлива відмінність у проведенні тестування в ході кодування і по його завершенні: в першому випадку продовжувати написання програми (а також запуск інших тестових прикладів) бажано тільки після усунення помилки, у другому здійснюється пакетне виконання серії текстів з простою фіксацією їх результатів.


Тестування – процес також ітераційний. Після виявлення та виправлення кожної помилки обов’язково слід повторення тестів, щоб переконатися в працездатності програми. Більш того, для ідентифікації причини виявленої проблеми може знадобитися проведення спеціального додаткового тестування. При цьому потрібно завжди пам’ятати про фундаментальне висновку, зробленому професором Едсжером Дейкстрой в 1972 р: “Тестування програм може служити доказом наявності помилок, але ніколи не доведе їх відсутність!”.


Різні види тестування можна класифікувати і за такими основними характеристиками (хоча будь-яка категоризація є досить умовною).


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


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


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


Напевно, має сенс виділити тестування поточної конфігурації системи і тестування з урахуванням її можливого розвитку. Аналіз можливих проблем в майбутньому найчастіше пов’язується сьогодні з завданнями масштабування, наприклад підвищення навантаження на систему в результаті збільшення числа користувачів. Хоча звичайно ж тут потрібно мати на увазі більш широкий круг питань, зокрема перспективи зміни платформи. Хотілося б при цьому підкреслити, що оцінка масштабування може (і повинна!) проводитися не тільки за допомогою тестування реального додатки, а й методами системного моделювання на рівні загальної структури ПЗ (про такий підхід в останні роки щось стали забувати!).



Рішення проблеми – центри тестування

Як вже було сказано, провідну роль в питаннях тестування грають методологія і організаційна складова. Що ж до інструментарію, то його роль в цьому процесі вторинна і вибір того чи іншого продукту для автоматизації задач тестування визначається вже в залежності від цілей та специфіки проекту, існуючих переваг замовника, бюджету. На ринку зараз представлений цілий спектр засобів автоматизованого тестування, в якому лідирують IBM Rational, Mercury, Segue, Compuware.


В рамках семінару фахівцями компанії “Аплана” розглядалися можливості автоматизованого тестування на прикладі засобів тестування IBM Rational, які в даний час набули значного поширення серед російських розробників (див. врізку “Методологія та інструментарій IBM Rational”). Обговорювалися також різні сценарії їх застосування при створенні ПО корпоративного рівня. Серед конкретних програмних продуктів особливу увагу було приділено найбільш популярної сьогодні системі IBM Rational Robot.


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


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


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



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

*Не забуваючи про значимість питань тестування, потрібно пам’ятати про те, що один із класиків сучасних методів розробки ПЗ, голландський професор Едсжер Дейкстра ще в кінці 60-х років минулого століття обгрунтував необхідність застосування методів структурного програмування, виходячи саме з завдання зниження трудовитрат на тестування.

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

***Говорячи про тестування, треба також обов’язково згадати про важливість верифікації ПЗ (систематичної процедури перевірки правильності). Тонке відмінність між цими поняттями полягає в тому, що тестування базується на можливості порівняння отриманих результатів з еталонними. Проте є досить великий клас задач, коли еталонних даних просто немає. Класичний приклад такого варіанту – побудова складних математичних моделей з рішенням десятків тисяч диференціальних рівнянь, хоча аналогічні ситуації виникають і тоді, коли маєш справу з бізнес-додатками. В цьому випадку потрібно включення в ПО додаткових функцій та проведення спеціальних досліджень, щоб у користувача з’явилася впевненість (нехай навіть не 100 -%), що програма дійсно працює правильно.







Методологія та інструментарій IBM Rational  
Загальна методологія розробки ПЗ Rational Unified Process виділяє досить великий набір видів тестування (див. малюнок). Їх можна з певною часткою умовності розділити таким чином:
Функціональне тестування (Function testing)

  • тестування цілісності даних (Data integrity testing);
  • тестування на різних платформах (Configuration testing);
  • тестування відмовостійкості (Failover & recovery testing);
  • тестування доступу (Security testing);
  • інсталяційне тестування (Installation testing);
  • тестування користувальницького інтерфейсу (User interface testing)
Навантажувальне тестування (Load testing)

  • профілювання продуктивності (Performance profiling);
  • тестування циклу роботи (Business cycle testing);
  • тестування при великій користувальницької навантаженні (Stress testing);
  • тестування на великих обсягах даних (Volume testing).
Для вирішення цих завдань передбачено такі основні інструменти:

  • IBM Rational TestManager – управління тестуванням;
  • IBM Rational PurifyPlus (Purify, PureCoverage, Quantify) – аналіз роботи системи в режимі RunTime;
  • IBM Rational Robot – функціональне і навантажувальне тестування;
  • IBM Rational TestFactory – автоматизація створення тестів;
  • IBM Rational XDE Tester – функціональне тестування Java і web-додатків.
Із зіставлення двох цих списків видно, що кожен продукт покриває кілька типів тестування. Ось коротка характеристика цих інструментів.
IBM Rational TestManager необхідний на всіх етапах тестування, надає в розпорядження команди спільні кошти планування, проектування, виконання та аналізу тестів з використанням єдиної панелі управління. Даний продукт має власне сховище даних, що забезпечує більш якісне управління версіями. Будь-який інструмент тестування ПО, що володіє власним API, не складно інтегрувати в єдину систему, при цьому може підтримуватися більшість виконуючих платформ тестування.
IBM Rational PurifyPlus включає три інструменти, призначених для аналізу в режимі реального часу додатків і компонентів, розроблених за допомогою Visual C / C + +, C #, VB, VB. NET, Java, Java. NET. Purify забезпечує автоматичне виявлення помилок, пов’язаних з пам’яттю, при цьому виділяються джерело і розташування помилки. Якщо доступний вихідний код, то його можна виправити безпосередньо з Purify. Запатентована технологія Object Code Insertion дозволяє виявляти помилки доступу до пам’яті не тільки в вихідному коді, але і в двійкових програмних компонентах (DLL, об’єкти COM / DCOM, ODBC). PureCoverage – засіб автоматичного визначення непротестованих коду. Quantify виконує оцінку продуктивності, визначаючи вузькі місця додатків і компонентів, як з вихідним кодом, так і без нього. Вбудовані засоби аналізу даних допомагають проводити порівняння результатів тестових прогонів для різних варіантів коду.
IBM Rational Robot – Засіб створення, зміни та виконання автоматизованих тестів Інтернет-додатків, ERP-систем і клієнт-серверних рішень. З його допомогою забезпечується об’єктно-рівнева підтримка при створенні додатків на різних засобах розробки. Сценарії функціональних тестів генеруються в середовищі SQABasic, синтаксично сумісної з VB; вбудований редактор дозволяє розширити сценарії тестів необхідними процедурами і логічними умовами. Передбачена можливість створення спеціалізованих тестів для різних типів програмних об’єктів. Для формування скриптів використовується власний Сі-подібний мову.
IBM Rational TestFactory – Інструмент автоматичної генерації скриптів тестування за допомогою всебічного аналізу запущеного додатка для виявлення дефектів надійності. Оскільки в програмах є величезна кількість колій виконання, проблема полягає в тому, щоб створити тести, які перевіряють повний функціонал програми за мінімальне число кроків.
IBM Rational XDE Tester – Спеціалізований інструмент для тестування Java-додатків (J2EE, J2SE, SWT, AWT / JFC) і Web-додатків (HTML, DHTML, XML, JavaScript, аплети Java). Текстові сценарії пишуться на Java, технологія ScriptAssure забезпечує перевірку достовірності динамічних даних. Середа тестування реалізована в оболонці Eclipse, при цьому є можливість вбудовування інструменту в WebSphere Studio і Rational XDE Developer.

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


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

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

Ваш отзыв

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

*

*