Модель процесу тестування

Причини для модульного тестування в автономній манері:

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

¨ Під час тестування бажано перевіряти чи приносить виконання певного модуля бажані результати. В ідеалі виконання всіх можливих (або максимально можлива кількість) випадків повинне бути розглянуто підчас тестування. Це вимагає обережно обирати вхідні дані для кожного виконання.

¨ Виконати кожну стрічку коду. За відсутності такого спостереження, сюрпризи можуть дуже дорого коштувати.

¨ Виконати кожен предикат

в модулі, для того щоб

оцінити його істинність чи хибність.

¨ Важливим є виконання модулем своїх функцій та забезпечення відсутності в них відомих помилок.

Попередньо проведене модульне тестування не дає гарантій що програма буде працювати вірно в цілому. Але це не означає що його не потрібно проводити. Немає сенсу інтегрувати помилкові модулі через такі причини:

¨ Багато з наступних тестів будуть марною тратою ресурсів

Пошук корінних причин невдач у інтегрованої системи є більш ресурсномістким

34. Управління тестуванням.

Главные принципы

Целью менеджмента качества(SQM) является управление качеством программного обеспечения и процесса его развития.

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

Привитие каждому члену команды разработчиков мысли о том, что стремление к выпуску качественного ПО - обязанность каждого.

Весь процесс управления качеством можно разбить на 3 уровня:

1. Обеспечение качества программного продукта

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

Наличие базы лучших практик достижения качества

Наличие программных средства для применения вышеуказанных практик

2. План достижения качества

Для каждого разрабатываемого проекта должен быть написан план по достижению качества, который необходим, чтобы регулировать применение тех средств, которые описаны выше

3. Контроль качества ПО

Обучение персонала созданию четко формализованных инженерных документов с использованием стандартных шаблонов

Обучение персонала тому, как проводить стандартные процессы управления качеством

Проверка и оценка того, как усвоен процесс использования методов, процедур и программных средств с первого уровня

Інструменти тестування.

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

Класифікація

¨ Інструменти керування тестуванням

¤ Менеджери конфігурацій та проекту

¨ Інструменти, підтримуючі аналіз вимог та проекту

¤ Аналізатори планів, вимог та проектів

¤ Розробники прототипів/емулятори системи

¤ Інструменти тестування вимог

¤ Планувальники тестів

¨ Інструменти підтримки тестування на етапі реалізації та супроводу

¤ Статичні аналізатори вихідного коду

¤ Інструменти підготовки тестів

¤ Інструменти виконання тестів

¤ Оцінювачі тестів

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

¨ Менеджери проекту - підтримують функції планування та відстеження на етапах розробки та супроводу системи (оцінювання термінів, ресурсів, побудова мережевих графіків і ін.)

¨ Аналізатори планів, вимог і проектів - оцінюють специфікації на повноту, несуперечність і відповідність встановленим стандартам для специфікацій.

¨ Будівники прототипів/емулятори системи - об'єднують дії з тестування з діями з аналізу та проектування і дозволяють швидко промоделювати вимоги та проектні рішення Інструменти трасування вимог - дозволяють встановити зв'язки вимог до проекту, кодом і тестами.

¨ Планувальники тестів - підтримують процес планування тестування на всіх його рівнях.

Інструменти підготовки тестів

¨ Екстрактори даних - будують тести, витягуючи інформацію з існуючих баз даних або тестових наборів.

¨ Генератори тестів за специфікацією вимог - будують тести за вимогами, написаним на формальному мові специфікації.

¨ Генератори тестових даних (за різними методами) - генерують вхідні дані для тестування відповідно до методу, реалізованим в інструменті.

¨ Планувальники тестів - підтримують розробку та ведення планів тестування.

Інструменти виконання тестів

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

¨ Інструменти захоплення / програвання - автоматично записують дії тестувальника при виконанні програми у вигляді автоматичної тестової процедури і потім відтворюють ці дії.

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

¨ Емулятори - можуть застосовуватися замість відсутніх компонентів системи.

¨ Аналізатори мережі - призначені для аналізу трафіку мережі.

¨ Аналізатори продуктивності - відстежують тимчасові характеристики системи або її компонентів.

¨ Аналізатори помилок періоду виконання - відстежують роботу програми на наявність помилок, пов'язаних із захопленням-звільненням пам'яті, нульовими покажчиками і т.п.

¨ Інструменти управління виконанням тестів - автоматизують різні функції налаштування та виконання тестів, очищення системи після виконання тестів.

Оцінючі тестів

¨ Компаратори - порівнюють результати тестування і виявляють відхилення. Інструменти захоплення / програвання зазвичай мають у своєму складі такі компоненти.

¨ Конвертори та аналізатори даних - конвертують дані в зручний для інтерпретації формат і виконують різні види статистичного аналізу цих даних.

¨ Трасувальник дефектів / змін - зберігають інформацію про дефекти і генерують звіти. Зазвичай входять до складу систем управління конфігурацією і інструментів управління тестуванням.

Метрики покриття.

Оцінювання продукту здійснюється за допомогою метрик:

a. Підрахунку дефектів;

b. Тенденції дефектів;

c. Надійності;

d. Процесу тестування;

e. Покриття;

f. Структурного покриття;

g. Функціонального покриття;

h. Динаміки виявлення дефектів.

Статистичне тестування.

В статичній фазі код досліджується по

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

Код перевіряється, застосовуючи методи широко відомі як:

¨ Перевірка – покроковий груповий перегляд робочого продукту, де з кожним кроком перевіряються наперед визначені критерії

¨ Покрокове керівництво – це перегляд де автор очолює команду під час пробного або вдаваного виконання продукту з наперед визначеними сценаріями.

Кроки процесу перегляду коду

38. Класифікація інструментів тестування.

¨ Інструменти керування тестуванням

¤ Менеджери конфігурацій та проекту

¨ Інструменти, підтримуючі аналіз вимог та проекту

¤ Аналізатори планів, вимог та проектів

¤ Розробники прототипів/емулятори системи

¤ Інструменти тестування вимог

¤ Планувальники тестів

¨ Інструменти підтримки тестування на етапі реалізації та супроводу

¤ Статичні аналізатори вихідного коду

¤ Інструменти підготовки тестів

¤ Інструменти виконання тестів

¤ Оцінювачі тестів

¨ Планувальники тестів - підтримують процес планування тестування на всіх його рівнях.

Інструменти підготовки тестів

¨ Екстрактори даних - будують тести, витягуючи інформацію з існуючих баз даних або тестових наборів.

¨ Планувальники тестів - підтримують розробку та ведення планів тестування.

Інструменти виконання тестів

¨ Емулятори - можуть застосовуватися замість відсутніх компонентів системи.

¨ Аналізатори мережі - призначені для аналізу трафіку мережі.

¨ Аналізатори продуктивності - відстежують тимчасові характеристики системи або її компонентів.

Оцінючі тестів

39. Спеціалізоване тестування.

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

40. Критерії завершення тестування.

Об'єктивні критерії завершення тестування ґрунтуються на кількісних вимірах. Існуючі підходи до формування кількісних критеріїв можна розділити на чотири категорії:

· критерії, базовані на метриках покриття;

· критерії, базовані на серйозності дефектів;

· критерії, базовані на оцінках інтенсивності відмов та надійності;

· критерії оптимізації вартості, часу тестування та надійності.

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

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

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

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

q Планування тестування:

Ø Цільове налаштування на основі перспектив та очікувань клієнтів по якості

Ø Загальна стратегія на онові характеристик продукту/оточення

q Підготовка тестування:

Ø Підготовка тестових випадків та наборів– зазвичай на основі формальних моделей

Підготовка процедури випробувань

42. Створення тестів (test-cаse).

Лек 8 сл21(мб подойдет…)

Тестовый случай (Test Case) - это совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Под тест кейсом понимается структура вида:

Action > Expected Result > Test Result

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

Каждый тест кейс должен иметь 3 части:

PreConditions — Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.

Test Case Description — Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям

PostConditions — Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста - initial state)

Примечание: Post Conditions не является обязательной частью. Это скорее всего - правило хорошего тона: "намусорил - убери за собой". Это особенно актуально при автоматизированном тестировании, когда за один прогон можно наполнить базу данных сотней или даже тысячей некорректных документов.

⇐ Назад