Тестуваннязручностівикористання (usability).

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

Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:

· производительность, эффективность (efficiency) - сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д.? (меньше - лучше)

· правильность (accuracy) - сколько ошибок сделал пользователь во время работы с приложением? (меньше - лучше)

· активизация в памяти (recall) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени? (повторное выполнение операций после перерыва должно проходить быстрее чем у нового пользователя)

· эмоциональная реакция (emotionalresponse) – как пользователь себя чувствует после завершения задачи - растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция - лучше)

Звіти по помилках.

Баг или дефект репорт - это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.Разные системы менеджмента дефектами, предлагают нам разные поля для заполнения и разные структуры описания дефектов, но чаще всего баг-репорт содержит в себе информацию, распределенную по следующим пунктам:

Короткое описание проблемы; название тестируемого проекта; компонент приложения, где была найдена ошибка; номер версии тестируемого ПО; серьезность бага; приоритет бага; автор баг-репорта; спецификация системы на которой был найден баг; шаги воспроизведения; результат выполнения перечисленных выше шагов; результат, который ожидался

 

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

· Open/Closed Bugs

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

 

· Reopened/ClosedBugs

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

· Rejected/OpenedBugs

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

· BugsbySeverity

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

· BugsbyPriority

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

 

 

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

e. Покриття;

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

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

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

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

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

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

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

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

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

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