Тестування програмного забезпечення

Размещено на http://www.allbest.ru/

[Введите текст]

ВСТУП

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

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

Зокрема, ми плануємо приділити велику увагу таким питанням, як роль тестування в Rational Unified Process і вимоги ГОСТ до процесу тестування.



РОЗДІЛ 1. ОСНОВИ ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

1.1 Поняття тестування програмного забезпечення

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

У відповідність з RUP Тестування - одна з дисциплін RUP. Вона орієнтована в першу чергу на оцінку якості за допомогою таких методів:

пошук і документування дефектів якості;

загальні рекомендації щодо якості;

перевірка виконання основних припущень і вимог на конкретних прикладах;

перевірка, що продукт функціонує так, як було запроектовано;

перевірка, що вимоги виконані відповідним чином.

У відповідність з IEEE Std 829-1983 Тестування - це процес аналізу ПО, спрямований на виявлення відмінностей між його реально існуючими і необхідними властивостями (дефект) і на оцінку властивостей ПЗ.

За ГОСТ Р ІСО МЕК 12207-99 в життєвому циклі ПЗ визначені серед інших допоміжні процеси верифікації, атестації, спільного аналізу та аудиту. Процес верифікації є процесом визначення того, що програмні продукти функціонують у повній відповідності з вимогами або умовами, реалізованими в попередніх роботах.

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

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

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

1.2 Рівні тестування програмного забезпечення

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

Модульне тестування (Unit testing)

Цей рівень тестування дозволяє перевірити функціонування окремо взятого елемента системи. Що вважати елементом - модулем системи визначається контекстом. Найбільш повно даний вид тестів описаний в стандарті IEEE 1008-87 "Standard for Software Unit Testing", задаючому інтегровану концепцію систематичного і документованого підходу до модульного тестування.

Інтеграційне тестування (Integration testing)

Даний рівень тестування є процесом перевірки взаємодії між програмними компонентами / модулями.

Класичні стратегії інтеграційного тестування - "зверху-вниз" і "знизу-вгору" - використовуються для традиційних, ієрархічно структурованих систем і їх складно застосовувати, наприклад, до тестування слабозв'язаних систем, побудованих в сервісно-орієнтованих архітектурах (SOA).

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

Інтеграційне тестування - постійно проводиться діяльність, що передбачає роботу на досить високому рівні абстракції. Найбільш успішна практика інтеграційного тестування базується на інкрементальних підході, що дозволяє уникнути проблем проведення разових тестів, пов'язаних з тестуванням результатів чергового тривалого етапу робіт, коли кількість виявлених дефектів призводить до серйозної переробки коду (традиційно, негативний досвід випуску та тестування тільки великих релізів називають "big bang").

Системне тестування (System testing)

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

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



РОЗДІЛ 2. МЕТОДИ ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

2.1 Класифікація і короткий огляд методів побудови тестів

Існує кілька методів тестування:

* Тестування програм методом "чорної скриньки" (Black box testing).

* Тестування софта методом "білого ящика" (White box).

* Тестування ПЗ методом "сірого ящика" (Grey box).

* До перевірки не функціональних аспектів програми..

Тестування програми як "білого ящика" і "чорної скриньки"

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

При тестуванні білого ящика (англ. white-box testing, також кажуть - прозорого ящика), розробник тесту має доступ до вихідного коду і може писати код, який пов'язаний з бібліотеками тестованого ПЗ. Це типово для юніт-тестування (англ. unit testing), при якому тестуються тільки окремі частини системи. Воно забезпечує те, що компоненти конструкції - працездатні і стійкі, до певної міри.

При тестуванні чорного ящика (англ. black-box testing), тестувальник має доступ до ПЗ тільки через ті ж інтерфейси, що і замовник або користувач, або через зовнішні інтерфейси, що дозволяють іншого комп'ютера або іншому процесу підключитися до системи для тестування. Наприклад, тестуючий модуль може віртуально натискати клавіші або кнопки миші в програмі, що тестується за допомогою механізму взаємодії процесів, з упевненістю в тому, чи все йде правильно, що ці події викликають той же відгук, що й реальні натискання клавіш і кнопок миші. Як правило, тестування чорного ящика ведеться з використанням специфікацій або інших документів, що описують вимоги до системи.

Якщо «альфа-» і «бета-тестування» відносяться до стадій до випуску продукту (а також, неявно, до обсягу тестуючого співтовариства і обмеженням на методи тестування), тестування "білого ящика» і «чорного ящика» має відношення до способів, якими тестувальник досягає мети.

Бета-тестування в цілому обмежено технікою чорного ящика (хоча постійна частина тестувальників звичайно продовжує тестування білого ящика паралельно бета-тестування). Таким чином, термін «бета-тестування» може вказувати на стан програми (ближче до випуску ніж «альфа»), або може вказувати на деяку групу тестувальників і процес, що виконується цією групою. Отже, тестувальник може продовжувати роботу з тестування білого ящика, хоча ПЗ вже «в беті» (стадія), але в цьому випадку він не є частиною «бета-тестування» (групи / процесу).

Тестування нефункціональних Параметрів програми

Існують спеціальні методи для тестування аспектів програм, які не є функціональними, тобто не відносяться до працездатності самих програм. Це тестування:

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

* Тестування "Юзабіліті" - тестування інтерфейсу користувача, його зручності, практичності і легкості для освоєння звичайним користувачем.

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

* Тестування якості інтернаціоналізації та локалізації програмного забезпечення.

Користуватися цими методами можна і потрібно, щоб програма була якісною.

Методи побудова тестів, основані на спеціфікаціях.

Еквівалентне поділ <програми> (Equivalence partitioning)

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

Аналіз граничних значень (Boundary-value analysis)

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

Таблиці прийняття рішень (Decision table)

Такі таблиці представляють логічні зв'язки між умовами (можуть розглядатися в якості "входів") і діями (можуть розглядатися як "виходи"). Набір тестів будується послідовним розглядом усіх можливих крос-зв'язків у такій таблиці.

Тести на основі кінцевого автомата (Finite-state machine-based)

Будуються як комбінація тестів для всіх станів і переходів між станами, представлених у відповідній моделі (переходів і станів додатки).

Тестування на основі формальної специфікації (Testing from formal specification)

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



Випадкове тестування (Random testing)

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

Методи побудови тестів, основані на коді.

Тести, що базуються на блок-схемі (Control-flow-based criteria)

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

Тести на основі потоків даних (Data-flow-based criteria)

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

Посилальні моделі для тестування, орієнтованого на код (Reference models for code-based testing - flowgraph, call graph)

Є не стільки технікою тестування, скільки контролем структури програми, представленої у вигляді дерева викликів (наприклад, sequence-діаграми, визначеної в нотації UML і побудованої на основі аналізу коду).



РОЗДІЛ 3. ОПИС ПРОЦЕСУ ТЕСТУВАННЯ

Концепції, стратегії, техніки та вимірювання тестування повинні бути об'єднані в єдиний процес тестування як діяльності щодо забезпечення якості. Процес тестування підтримує роботи з тестування та визначає "правила гри" для членів команди тестування - від планування тестів до оцінки їх результатів. Хоча, в більшості сучасних методів розробки, зокрема, гнучких (agile) підходів, тестування виходить на передній план і є однією з базових практик, багатостороннє тестування і, тим більше, прогнозування на основі отриманих результатів, часто підміняється окремими роботами в цій області, що не дозволяють домогтися необхідних параметрів якості (що, до речі, ясно показують вже згадувані результати досліджень Standish Group [Chaos, 2004]). Тільки в тому випадку, якщо тестування розглядати як один з важливих процесів всієї діяльності зі створення і підтримки програмного забезпечення, можна домогтися оцінки вартості відповідних робіт і, зрештою, дотримати ті обмеження, які визначені для проекту.

Практичні міркування (Practical considerations)

Програмування без персоналій (Attitudes / Egoless programming)

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

Керівництво з тестування (Test guides)

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



Управління процесом тестування (Test process management)

Роботи з тестування, що ведуться на різних рівнях (див. вище 2. "Рівні тестування"), повинні бути організовані в єдиний (однозначно інтерпретується) процес, на основі обліку 4 елементів і пов'язаних з ними факторів: людей (у тому числі, в контексті організаційної структури та культури), інструментів, регламентів і кількісних оцінок (вимірів). Стандарт життєвого циклу IEEE, ISO / IEC, ГОСТ Р 12207 не виділяє діяльність з тестування в якості самостійного процесу, однак, розглядає відповідні принципи робіт з тестування як невід'ємну частину процесів життєвого циклу і супроводу програмних систем. В іншому поширеному стандарті IEEE 1074 діяльність з тестування також об'єднана з іншими оціночними роботами як інтегральна частина повного життєвого циклу.

Документування тестів і робочого продукту (Test documentation and work products)

Документація - складова частина формалізації процесу тестування. Існує стандарт IEEE 829-98 "Standard for Software Test Documentation", що надає прекрасний опис тестових документів, їх зв'язків між собою і з процесом тестування. Серед таких документів можуть бути:

План тестування.

Специфікація процедури тестування.

Специфікація тестів.

Журнал тестів.

та ін.

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

Внутрішні і незалежні команди тестування (Internal vs. Independent test team)

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

Оцінка вартості і зусиль, а також інші виміри процесу (Cost / effort estimation and other process measures)

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

Закінчення тестування (Termination)

Дуже важливим аспектом тестування є рішення про те, в якому обсязі тестування достатньо і коли необхідно завершити процес тестування. Ретельні вимірювання, такі як досягнуту покриття коду тестами або охоплення функціональності, безумовно, дуже корисні. Однак, самі по собі вони не можуть визначити критеріїв достатності тестування. Ємство рішення про закінчення тестування також включає розгляд вартості та ризиків, пов'язаних з потенційними збоями та порушеннями надійності функціонування тестованої програмної системи. У той же час, вартість самого тестування також є одним з обмежень, на основі яких приймається рішення про продовження тих чи інших пов'язаних з проектом робіт (з зокрема, тестування) або про їх припинення. Cм. також 1.2.1 "Критерії відбору тестів / критерії адекватності тестів, правила припинення тестування".

Повторне використання та шаблони тестів (Test reuse and test patterns)

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

Тестові роботи (Test Activities)

Дана тема дає короткий огляд робіт з тестування. При цьому мається на увазі, що успішне управління тестовими роботами сильно залежить від процесів конфігураційного управління (Software Configuration Management), розглянутих пізніше як самостійна галузь знань.



Планування (Planning)

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

координацію персоналу,

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

планування обробки небажаних результатів (тобто є управлінням певними видами ризиків).

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

Генерація сценаріїв тестування (Test-case generation)

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

Розробка тестового оточення (Test environment development)

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

Виконання тестів (Execution)

Виконання тестів повинно містити основні принципи ведення наукового експерименту:

повинні фіксуватися всі роботи і результати процесу тестування,

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

тестування має проводитися у відповідності з заданими і документально оформленими,

тестування має проводитися над однозначно ідентифікованої версією і конфігурацією програмної системи.

Ряд питань виконання тестів та інших робіт з тестування висвітлений у стандарті IEEE 1008-87.

Аналіз результатів тестування (Test results evaluation)

Для визначення успішності тестів їх результати повинні оцінюватися, аналізуватися. У більшості випадків, "успішність" тестування увазі, що тестується, програмне забезпечення функціонує так, як очікувалося і в процесі роботи не призводить до непередбачуваних наслідків. Не всі такі наслідки обов'язково є збоями, вони можуть сприйматися як "перешкоди". Однак, будь-яке непередбачене поведінка може стати джерелом збоїв при зміні конфігурації або умов функціонування системи, тому вимагають уваги, як мінімум, з точки зору ідентифікації причин таких перешкод. Перед усуненням виявленого збою, необхідно визначити і зафіксувати ті зусилля, які необхідні для аналізу проблеми, налагодження та усунення. Це дозволить у подальшому забезпечити більшу глибину вимірювань, а, відповідно, в перспективі, мати можливість поліпшення самого процесу тестування. У тих випадках, коли результати тестування особливо важливі, наприклад, в силу критичності виявленого збою, може бути сформована спеціальна група аналізу (review board). Звіти про проблеми / журнал тестування (Problem reporting / Test log)

У багатьох випадках, в процесі тестової діяльності ведеться журнал тестування, що фіксує інформацію про відповідні роботах: коли проводиться тест, який тест, ким проводиться, для якої конфігурації програмної системи (в термінах параметрів і в термінах ідентифікованої версії контексту конфігураційного управління) і т.п. Несподівані або некоректні результати тестів можуть записуватися в спеціальній підсистемі ведення звітності по збоїв (problem-reporting system, забезпечуючи формування бази даних, використовуваної для налагодження, усунення проблем і подальшого тестування. Крім того, аномалії (перешкоди), які не можна ідентифікувати як збої, також можуть фіксуватися в журналі і / або системі ведення звітності по збоїв. У кожному разі, документування таких аномалій знижує ризики процесу тестування і допомагає вирішувати питання підвищення надійності самої тестованої системи. Звіти по тестах можуть бути входом для процесу управління змінами та генерації запитів на зміни ( change request) у рамках процесів конфігураційного управління (див. далі відповідну область знань "Software Configuration Management").

Відстеження дефектів (Defect tracking)

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



РОЗДІЛ 4. МЕТРИКИ ТЕСТУВАННЯ

При проведенні тестування необхідно визначити критерії закінчення процесу тестування. Адже недолік тестування може вести до випуску продукту з істотними недоліками. А «зайве» тестування може коштувати досить дорого, затримувати випуск продукту і відволікати тестувальників від інших робіт.

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

Ще одним важливим поняттям у теорії тестування є поняття критеріїв покриття тестування. Не слід плутати метрики тестування і критерії покриття тестування. Останні дозволяють визначити ступінь покриття розроблюваного продукту тестами. Тому часто критерії покриття використовуються для визначення метрик тестування.

Наведемо приклади найпоширеніших критеріїв покриття при тестуванні функціональних вимог відповідно до методології RUP.

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

Покриття, засноване на специфікації або на вимогах (Specification-Based Coverage or Requirements-based Test Coverage).

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

Покриття, засноване на коді (Code-Based Coverage) має відношення до потоку управління та потоку даних програми. Найчастіше даний критерій використовується при тестуванні методом «білого ящика». Основні критерії покриття тестування коду наступні:

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

Покриття гілок (Branch Coverage). Це міра виміру покриття коду вказує у відсотковому відношенні, скільки гілок потоку управління було протестовано під час тесту. Вона надійніше попередньої метрики, але знову сто відсоткове покриття не гарантує відсутність помилок.

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

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



РОЗДІЛ 5. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

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

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

Таблиця 5.1 - Класи еквівалентності

Вхідні умови	Правильні класи еквівалентності	Неправильні класи еквівалентності
N	2<= n<=50	n<2 n>50 Символ
M	2<= m<=50	m<2 m>50 Символ
Елемент матриці	дійсне число	Символ

Таблиця 5.2 - Тести з правильних класів еквівалентності

№ Тесту	№ Класу еквівалентності	Вхідні умови	Результат
	1	3	Правильні
1	5	3	дані
	9	7



Таблиця 5.3 - Тести з неправильних класів еквівалентності

№ Тесту	№ Класу еквівалентності	Вхідні умови	Результат
	2	1	M and N must be >= 2
1	3	51	M and N must be < 50
	4	a	M and N must be >= 2
	6	0	M and N must be >= 2
	7	55	M and N must be < 50
	8	b	M and N must be >= 2
	10	t	Float or Integer ONLY!

Розробка програми

Найти максимум среди всех элементов тех строк заданной матрицы, которые упорядочены (либо по возростанию, либо по убыванию).

Для реалізації програми згідно специфікацій, було вибрано середу програмування Microsoft Visual Studio 2009 та мову програмування C++.

Програма складеться з модулів та головної програми. Код програми представлений нижче.

#include <iostream>

#include <conio.h>

using namespace std;

//Проверяет отсортирована ли строка row

bool isSorted(long n, long * row);

//Возвращает макс элемент строки

long GetMax(long n, long * row);

int main()

{

long i,j,m,n,val, maxv;

long ** arr;//Пусть будет массив с длинными целыми

bool bSorted = false;//Флаг сигнализирующий есть ли

//в массиве хоть 1-на сортированная строка

do

{

//Вводим строки и столбцы матрицы

std::cout<<"Rows in matrix : ";std::cin>>m;

std::cout<<"Cols in matrix : ";std::cin>>n;

arr = new long*[m];//Память под указатели на строки матрицы

for(i = 0; i < m; i++)

{

arr[i] = new long[n];//Память под элементы строки

for(j = 0; j < n; j++)

{

std::cout<<"arr["<<i + 1<<"]["<<j + 1<<"] = ";

std::cin>>arr[i][j];//Вводим эл-ты массива

}

}

//Теперь отыскиваем отсортированную строку

//конечно если такие строки есть

//я решил сэкономить на коде и попутно ищу

//первый максимальный элемент сортированных строк

//как только строка isSorted в maxv уже

//будет первый макс элемент отсортированных строк

//при этом поиск последующих строк уже буду вести

//с i-ой строки - вобщем удобно

while(0 < (i--) )

{

if((bSorted = isSorted(n, arr[i])))

{

maxv = GetMax(n, arr[i]);

break;

}

}

if(!bSorted)

//Если сортированных строк в массиве нет bSorted = false

//выводим соответсвующее уведомление

std::cout<<"Input array not contain sorted rows!\r\n";

else

{

//Завершаем пробор массива

while(0 < (i--))

{

if(isSorted(n, arr[i]))//Работаем только с сортированными строками

if(maxv < (val = GetMax(n, arr[i])))

maxv = val;

}

std::cout<<"Max value in sorted rows : "<<maxv<<"\r\n";

}

std::cout<<"Press Y for new input\r\n";

}//Если нажали Y можем повторить алгоритм для новй матрицы

while(toupper(getch()) == 'Y');

return 0;

}

bool isSorted(long n, long * row)

{

bool bRet = true;//полагаем вначале ччто строка отсортирована

long i;

//Ну а теперь сравниваем элементы строки row

//Проверяем сортированность по возрастанию

for(i = 0; i < n - 1 && bRet; i++)

{

if(row[i] > row[i + 1])

bRet = false;

}

//если строка не отсортирована по возрастанию

//проверим отсортирована ли она по убsванию

if(!bRet)

{

bRet = true;

for(i = n - 1; 0 <= i && bRet; i--)

{

if(row[i] < row[n - i - 1])

bRet = false;

}

}

return bRet;

}

long GetMax(long n, long * row)

{

long ret = row[0];

for(long i = 1; i < n; i++)

{

if(ret < row[i])

ret = row[i];

}

return ret;

}

Результати тестування методом «Білого ящика» представлені у таблиці 5.4



Таблиця 5.4 - Результати іспитів методом «Білого ящика»

№ тесту	№ класу еквивалентності	Входні умови	Результат
1	1	3	Результат представлен на рисунке 5.2
	5	3
	9	7
2	2	0	M and N must be >= 2
3	3	220	M and N must be < 100
4	4	a	M and N must be >= 2
5	6	b	M and N must be >= 2
6	7	115	M and N must be < 100
7	8	-3	M and N must be >= 2
8	10	pi	Float or Integer ONLY!
У випробуванні № 1 виконалися всі умови модуля.
У випробуванні № 2 не виповнилося жодна умова.
У випробуванні № 3 умова 1 виповнилося, не виконуючи умови 2,3,4,5
У випробуванні № 4 не виповнилося жодна умова.
У випробуванні № 5 не виконалось жодна умова.
У випробуванні № 6 умова 1 виповнилося, не виконуючи умови 2,3,4,5
У випробуванні № 7 не виповнилося жодна умова.
У випробуванні № 8 умови 1,2 виконалися, що не виконалися умови 3,4,5

Результат тестування методом «Чорного ящику» представлені в таблиці 5.5.

тестування програмування документування команда

Таблиця 5.5 - Результат тестування методом «Чорного ящику»

Номер тесту	Вхідні дані	Очікуваний результат	Результат тестування
1	Спроба ввести невірну матрицю	Програма повинна надавати помітку про помилку	Тест пройдений



ВИСНОВКИ

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

Була розроблена специфікація та тести до програми. За допомогою тестування можливо перевірити програму на помилки.



СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ І ЛІТЕРАТУРИ

1. Майерс Р. Мистецтво тестування програм / Г. Майерс; Пер. з англ. під ред. Позина. - М.: Фінанси і статистика, 1982. - 176 с.

2. Степанченко І.В. Методи тестування програмного забезпечення: Учеб. посібник / Степанченко І.В. - ВолгГТУ, Волгоград, 2006. - 76 с.

3. Калбертсон Р. Швидке тестування. / Р. Калбертсон, К. Браун, Г. Кобб. - М.: Видавничий дім «Вільямс», 2003. - 374 с.

4. Синіцин С.В. Верифікація програмного забезпечення. / С.В. Синицин, Н.Ю. Налютін. - М.: 2006. - 158 с.

5. Савін Р. Тестування дот ком або допомогу по жорсткому поводженню з багами в інтернет-стартапи / Р. Савін. - М.: Видавництво «Справа», 2007. - 316 с.

6. Канер С. Тестування програмного забезпечення. Фундаментальні концепції менеджменту бізнес-додатків / С. Канер, Дж. Фолк, Є. Кек Нгуен; Пер. з англ. - К.: Видавництво «ДіаСофт», 2001. - 544 с.

7. Тамро Л. Введення в тестування програмного забезпечення / Л. Тамро; Пер. з англ. М.: Видавничий дім «Вільямс», 2003. 368 с.

Размещено на Allbest.ru

...