28. Метрики дефектів.

• Open/Closed Bugs

Метрика показывает отношение количества открытых багов к закрытым (исправленным и перепроверенным)

• Reopened/ClosedBugs

Метрика показывает отношение количества переоткрытых багов к закрытым (исправленным и перепроверенным)

• Rejected/OpenedBugs

Метрика показывает отношение количества отклоненных багов к открытым

• BugsbySeverity

Количество багов по серьезности

• BugsbyPriority

Количество багов по приоритету

29. Тестуванняграфічногоінтерфейсукористувача.

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

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

• Тестирование на соответствие стандартам графических интерфейсов;

• Тестирование с различными разрешениями экрана;

• Тестирование в ограниченных условиях, например, в условиях нехватки памяти;

• Совместимость с различными Интернет-браузерами;

• Тестирование локализованных версий: точность перевода, проверка длины названий элементов интерфейса и т.д.;

• Тестирование графического интерфейса пользователя на целевых устройствах (для КПК-совместимых приложений).

30. Метрики динамікизнаходження дефектів.

Метрики якості процесів

• Вимірювання частоти дефектів під час тестування – чим більше дефектів виявлено під час тестування, тим більше їх буде при використанні

• Вимірювання динаміки виявлення дефектів на протязі часу

• Вимірювання дефектів по фазах життєвого циклу

Ефективність видалення дефектів (DRE)

31. Розробка, керована тестуванням (Test-driven development).

• Можна не писати код продукції, якщо написано перший невдалий модульний тест

• Можна більше не писати модульних тестів, ніж достатньо для провалу

• Можна більше не писати коду ніж потрібно для того щоб невдалий модульний тест було пройдено

32. Виконання тестів.

1. Начинать выполнение тестов с самых важных

a. Проверка правильности работы основных сценариев

b. Выполнение регрессионного тестирования (закрытие исправленных дефектов)

c. Прогон эффективных тестов (например, тестов частей программы, изменявшихся в последней сборке)

2. Лабораторные испытания

a. Подготовить тестовые данные и стенды

3. Помнить что до 80% ошибок будут переоткрыты после исправления

4. Не забывать обновлять сценарии тестирования. Добавлять тесты для новой функциональности, оптимизировать старые тесты.

5. Если остается время после выполнения формального тестирования, заняться исследовательским (неформальным/интуитивным) тестированием.

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

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

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

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

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

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

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

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

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

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

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

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