Тестування сервісів Windows NT / 2000 / XP

    Одна з  важливих переваг перед конкурентами - можливість тестування спеціальних програм, таких як  сервіси.

    Особливість роботи полягає в  тому, що  сервіс не можна запускати з  середовища розробки. Інструменти тестування розуміють це, і  пропонують своє рішення, по  якому необхідно наситити код  відкомпільованого сервісу  (з  налагоджування) налагоджування  (Не  запустивши при  цьому). Отримані в  результаті файл зареєструвати в  якості сервісу. Зробити це  можна як з GUI так і з командного рядка. Ми розглянемо послідовність кроків для  командного рядка, демонструючи її можливості (В прикладі, використовується посилання на  Purify, але  замість нього підставити ім'я  будь-якого засобу тестування):

1. Правильно налаштувати системні шляхи таким чином, щоб з них було видно всі директорії Purify (особливо кеш: \ Program Files \ Rational \ Purify), інакше процес не піде на виконання;

2. Відкомпільований сервіс потрібно запустити Purify з командного рядка таким чином: purify / Run = no /Out=service_pure.exe service.exe. Як видно з параметрів, Purify інструментує файл service.exe, поміщаючи його копію разом з OCI в service_pure.exe. Все відбувається без запуску;

3. У ключі реєстру \ HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services необхідно поставити посилання на кешований файл (service_pure.exe);

4. У вкладці сервісів активувати пункт Allow Service To Interact With Desktop, вибрати режим запуску " manual".

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

    В момент старту сервісу інструмент тестування запуститься автоматично.

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

Основні властивості засобів Purify, Quantify і   PureCoverage

· Інтегруються з засобами функціонального тестування Robot, TestManager і Visual Test;

· Інтегруються з ClearQuest, для документування та відстеження, виникають у процесі тестування помилок;

· Видають точну і детальну інформацію про продуктивності додатка;

 

· Використовують технологію OCI - Object Code Insertion, що дозволяє детально відстежувати і виловлювати помилки не тільки в розробленому модулі, але і в зовнішніх бібліотеках;

· Представляють комплексний додатковий огляд даних по продуктивності, області охоплення коду і по стабільності;

· Мають гнучке налаштування в відповідності з потребами розробників і тестувальників;

· Дозволяють багаторазово тестувати додаток (по ходу розробки), відстежувати зміни для кожної перекомпіляції, формуючи тим самим дані для подальшого аналізу;

· Інтегруються зі засобами розробки (Visual Studio 6.0, Visual Studio. NET, Vis-UAL Age ​ ​ For Java);

· Тестують компоненти ActiveX, COM / DCOM і ODBC;  

· Мають інтерфейс API, що дозволяє дописувати розробникам власні для найбільш ретельного і ефективного тестування.

Частина 3. Планування функціонального і   навантажувального тестування

Планування функціонального і   навантажувального тестування

    Якщо ви виробляєте складні програмні продукти, вкладаєте значні кошти і  ресурси в їх  розробку і  хочете бути впевнені в їх стабільній і  надійній роботі до  того, як  почнете впровадження, вам  необхідно переконатися, що  програмне забезпечення працює так, як воно проектувалося і як ви цього очікуєте. Використовуючи IBM  Rational вам  потрібно всього лише кілька комп'ютерів для  того, щоб в  лабораторних умовах емулювати складне оточення реального світу клієнт / серверних і  Інтернет взаємодій і  призвести всебічне тестування вашої розподіленої системи.

    На основі IBM  Rational ви  можете створити тестову лабораторію з  центром активності, який буде емулювати сотні і  тисячі користувачів, що посилають і  отримують інформацію, відтворюючи тим  самим складну взаємодію між вашим клієнтським додатком і  базами даних, іншими додатками і Web серверами. В такої лабораторії командним пунктом стає комп'ютер, який при  інсталяції PerformanceStudio був  визначений як Майстер. З цього комп'ютера ви  організуєте тестування, спостерігаєте за  процесом і  аналізуєте результати виконання тестів симулювати користувачами графічного інтерфейсу  (GUI) і  віртуальними користувачами  (VU).

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

    При організації роботи вашої тестовій лабораторії ви  можете завантажити сам  Майстер-комп'ютер роботою по  відтворення скриптів, а  можете перерозподілити завдання виконання скриптів між декількома комп'ютерами  - Агентами, які вивільнять ресурси Майстра. Використовуючи комп'ютер Майстер в  поєднанні з його Агентами для  відтворення скриптів можна створити значно більш потужну і  реалістичну навантаження при  тестуванні характеристик продуктивності серверів. Агенти можуть відтворювати різні комбінації VU і GUI  скриптів, забезпечуючи тим  самим додаткову гнучкість і  масштабування при  організації тестів в  складних гетерогенних мережевих структурах. Якщо Майстер-комп'ютер працює тільки на  MS  Windows NT, то  Агенти можуть бути встановлені на  різні платформи MS  Windows і  UNIX.

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

· Яку продуктивність матиме ваша розподілена система в реальному оточенні?

· Скільки часу потрібно серверам бази даних для завершення транзакцій?

· Наскільки швидко сервер обслуговує запити в умовах сильного навантаження?

· Чи є в системі вузькі місця і де вони?

· Чи є в додатку несправності, і яким чином їх можна подолати?

Для того, щоб знайти відповіді на ці і подібні питання, PerformanceStudio забезпечує користувача набором тестів для  всього життєвого циклу розробки системи.

Типи тестів

    Тести продуктивності  (Performance  Tests) дозволяють визначити, чи працює багатокористувацька система в  відповідності з  необхідних стандартів при  зміненні навантажень. В результаті виконання тестів вимірюються часи відгуку системи на  якійсь із  запитів, і на основі зібраної статистичної інформації робляться висновки про  характеристиках системи. Тести продуктивності виконуються за  допомогою програми LoadTest. При цьому тестуванні типово використовується навантаження сервера великою кількістю віртуальних користувачів. Наприклад, ви  можете встановити таймер для  одного VU, щоб визначити, скільки часу займе виконання запиту, коли тисячі інших VU  посилають запити на той же самий сервер в то же самий час. Термін 'тести продуктивності' включає навантажувальні, стресові, конкуруючі і  конфігураційні тести. Сукупність цих тестів дозволяє прискорити цикл тестування продуктивності і  досягти значущих і  точних результатів.

    Тестування навантаження  (Load  Tests) виконується тоді, коли потрібно визначити час відгуку серверів  або клієнтських додатків при  навантаженню, що змінюється. Тестування навантаження також використовується тоді, коли потрібно обчислити, яку максимальну кількість транзакцій може виконати сервер за  певний часовий відрізок. Якщо клієнт / серверна система використовує розподілену архітектуру  або засоби балансування навантаження - тестування навантаження може бути використано для  того, щоб перевірити правильність обраних методів для  балансування  або конструювання системи.

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

    Стресове тестування  (Stress  Test)  - це  перевірка роботи системи в  екстремальних умовах, тобто, коли випробовувана система штучно ставиться в  умови, які можуть призвести до  збою в  роботі як  клієнтської  або серверної частини додатків, так і всієї системи в  цілому.

Способів організації стресового тестування може бути безліч, наприклад:

· тривала робота клієнт / серверних додатків.

· виконання великої кількості транзакцій

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

· заповнення клієнтських форм свідомо неправильними або недостатніми даними і виконання транзакцій з цими даними.

· створення умов для роботи тестованої системи з недостатньою кількістю пам'яті або поділюваних системних ресурсів.

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

    Конкуруюче тестування  (Contention  Test) виконується як  комбінація GUI і VU на одному або декількох комп'ютерах, для  того щоб емулювати дійсне багатокористувацьке оточення. Наприклад, можна створити тест, коли кілька GUI  користувачів і  безліч віртуальних користувачів в  один і  той же час будуть звертатися до тієї ж самійої бази даних для  виявлення проблем в  управлінні багатозадачністю  або блокування. Без  автоматизованого засобу тестування такі тести, що вимагають точної синхронізації дій великої кількості користувачів, виконати практично неможливо.

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

    Конфігураційне тестування  (Configuration  Testing). Кожен комп'ютер користувача може мати різну суміш апаратних і  програмних особливостей, які створюють ризик того, що  створюване програмне забезпечення буде працювати на  одному з  них, а на одним не  буде. Знизити ймовірність виникнення таких ситуацій можна застосуванням конфігураційних тестів, коли один раз  створені скрипти для  GUI і VU  користувачів будуть виконуватися на  комп'ютерах з  різними OS  або конфігураціями програмних і  апаратних засобів. Наприклад, якщо ви використовуєте кілька типів мережевих карт, ви  можете виконати серію тестів для  кожної з  них з тим, щоб визначити, яка володіє кращими характеристиками.

    Розподілене функціональне тестування  (Distributed  Functional Testing).

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

Типи записи тестів

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

    Засоби тестування IBM  Rational підтримують три  режими інтерактивного запису скриптів:

    API  - Записує API  виклики з  клієнтських додатків і  клієнтських бібліотек до  серверів. API  режим запису являється рекомендованим підходом для  всіх клієнтів, що працюють на  платформі Windows NT. В цьому режимі і  PerformanceStudio і  клієнтську програму обидва  встановлюються на  клієнтський комп'ютер.

    Network - записує трафік по  TCP / IP протоколу на  рівні мережного інтерфейсу. Цей тип  запису рекомендований тоді, коли покупець не  підтримує API  режим запису.

Proxy - в  цьому режимі записується той  же самий трафік, що і в режимі запису Network, але для передачі пакетів між клієнтом і  сервером використовується машрутізація через proxy комп'ютер. Цей спеціалізований тип  запису застосовується в  високошвидкісних мережах і  мережах з  комутаторами.

Введення в   Test Manager

Види тестів

    RUP  регламентує і  описує безліч різних видів тестів, фокусуючих увагу на  різних проектних проблемах.

    TestManager, будучи засобом планування тестування, відповідає за їх коректне виконання. Не буде зайвим нагадати, що  створенням скриптів  (бібліотеки  скриптів) займається Rational Robot, фізично здійснює запис і  відтворення скриптів. Отриманий набір скриптів перетвориться в  план тестування, а  потім в  сценарій тестування безпосередньо в  TestManager

Розглянемо основні види тестів з  RUP:

· функціональне тестування;

· тестування цілісності баз даних;

· тестування бізнес циклів;

· тестування користувальницького інтерфейсу;

· профілювання продуктивності;

· тестування навантаження;

· стресове тестування;

· об'ємне тестування;

· тестування управління доступом. Тестування безпеки;

· тестування відновлення після збоїв;

· конфігураційне тестування;

· інсталяційне тестування.

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

    Розглянемо докладно основні види тестів, додаткові умови тестування, вимоги до  тестів і  критерії завершення.

Функціональне тестування

    Функціональне тестування об'єкта-тестування планується і  проводиться на  основі вимог до  тестування, заданих на  етапі визначення вимог. В якості вимог виступають діаграми use-case, бізнес-функції і  бізнес-правила. Мета функціональних тестів полягає в  тому, щоб перевірити відповідність розроблених графічних компонентів встановленим вимогам.

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

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

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

· тест на продуктивність;

· тест на наявність помилок з пам'яттю;

· тест на покриття коду.

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

Мета тестування:

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

Методика:

    Необхідно виконати  (програти) кожен з  use-case, використовуючи як  вірні значення, так і свідомо помилкові, для  підтвердження правильного функціонування, по  таким критеріям:

· продукт адекватно реагує на всі введені дані (виводяться очікувані результати в відповідь на правильно вводяться дані);

· продукт адекватно реагує на неправильно введені дані (з'являються відповідні повідомлення про помилки);

· кожне бізнес-правило реалізовано належним (встановленим) чином.

Критерії Завершення:

    Всі заплановані дії по  тестуванню виконані.

    Всі знайдені дефекти були відповідним чином оброблені  (документовані і поміщені в  базу дефектів).

Тестування цілісності даних і   баз   даних

Мета Тестування:
    Переконатися в  надійності методів доступу до  баз даних, в їх правильному виконанні, без  порушення цілісності даних.

Методика:
    Необхідно послідовно випробувати максимально можливе число способів звернення до  бази. Використовується підхід, при  якому тест складається таким чином, щоб  «навантажити» базу послідовністю, як  вірних значень, так і свідомо помилкових.

    Оцінити правильність внесення даних і  переконатися в  коректній обробці базою вхідних значень.

Критерії Завершення:

    Всі способи доступу функціонують, в  відповідності з  вимогами.

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

Тестування бізнес циклів

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

Мета тестування:
    Перевірити вірність функціонування об'єкта тестування та  пов'язаних з ним процесів на  відповідність вимогам бізнес моделей і  розкладів.

Методика:
    Тестування буде моделювати кілька бізнес циклів, з  виконанням наступного:

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

2. всі функції, які працюють з датою або часом, коректно виконуються в будь-яких тимчасових інтервалах;

3. всі функції, виконувані в періодичних розкладах виконуються або викликаються в відповідних тимчасових інтервалах;

4. тестування включає використання правильних і неправильних дат для перевірки реакції програми

Критерії завершення:
    Всі заплановані тести виконані. Всі виявлені дефекти оброблені і задокументовані.

Тестування для користувача інтерфейсу

Мета Тестування:
    Перевірити вірність навігації по  об'єкту тестування (В тому  числі міжвіконні переходи, переходи між полями, правильність обробки клавіш  «enter» та «tab», робота з  мишею, функціонування клавіш-акселераторів і  повна відповідність індустріальним стандартам);

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

Методика:
    Створюється  або доопрацьовуються тести для  кожного з  вікон, на  предмет відповідності навігації і  станів кожного з  об'єктів;

Критерії завершення:
    Кожне вікно протестовано і  задовільняє, базову лінію поведінки, вимогам стандартів і  НЕ  суперечить проектним вимогам;

    Всі виявлені дефекти оброблені і  задокументовані.

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: