Техники, ориентированные на код (Code-based techniques)
3.3.1 Тесты, базирующиеся на блок-схеме (Control-flow-based criteria)
Набор тестов строится исходя из покрытия всех условий и решений блок-схемы. В какой-то степени напоминает тесты на основе конечного автомата. Отличие – в источнике набора тестов.
Максимальная отдача от тестов на основе блок-схемы получается когда тесты покрывают различные пути блок-схемы – по-сути, сценарии потоков работ (поведения) тестируемой системы. Адекватность таких тестов оценивается как процент покрытия всех возможных путей блок-схемы.
3.3.2 Тесты на основе потоков данных (Data-flow-based criteria)
В данных тестах отслеживается полный жизненный цикл величин (переменных) – с момента рождения (определения), на всем протяжении использования, вплоть до уничтожения (неопределенности). В реальной практике используются нестрогое тестирование такого вида, ориентированное, например, только на проверку задания начальных значений всех переменных или всех вхождений переменных в код, с точки зрения их использования.
3.3.3 Ссылочные модели для тестирования, ориентированного на код (Reference models for code-based testing – flowgraph, call graph)
Является не столько техникой тестирования, сколько контролем структуры программы, представленной в виде дерева вызовов (например, sequence-диаграммы, определенной в нотации UML и построенной на основе анализа кода).
21. Система відслідковування проблем
¨ Цілі системи відслідковування проблем:
¤ Відслідковування стану тестування та усунення дефектів;
¤ Організація взаємодії між співробітниками та рішення спірних питань відносно класифікації і пріоритетів усунення дефектів;
¤ Визначення причин дефектів та виявлення “ вузьких місць ” у процесах розробки тестування.
22. Класифікація дефектів за серйозністю:
¨ Критичний;
¨ Серйозний;
¨ Значний;
¨ Незначний;
¨ Не дефект.
Класифікація дефектів за пріоритетом усунення:
¨ У першу чергу;
¨ Звернути увагу;
¨ У порядку черги;
¨ Відкласти;
¨ Відхилити.
Класифікація дефектів за стадіями розробки та джерелам:
¨ Класифікація дефектів за стадіями розробки співвідносить їх зі стадіями розробки, на яких вони були внесені.
¨ Класифікація дефектів за джерелами співвідносить дефекти з робочими продуктами стадій розробки, використання яких призвело до появи дефектів у коді ПО.
Класифікація дефектів за типом дефекту:
¨ Логічні;
¨ Обчислень;
¨ Інтерфейсу;
¨ Обробки даних;
¨ Вводу даних;
¨ Обробки помилок та ін.
23. Исследовательское тестирование – систематический способ проверить продукт без предопределенного набора тестов. Существует множество эвристик, которые могут быть применены к проведению исследовательского тестирования. Эти эвристики включают в себя использование ролей, характеристики, переменный анализ, область поиска и тестирование различных состояний. Для того, чтобы выполнить исследовательское тестирование таким образом, необходимо выбрать роль и работать через функциональные возможности системы, пытаясь достичь определённых целей. Лимит сессий исследовательского тестирования – не более двух часов.
24. Тестуванняконфігурації.
Конфигурационное тестирование (ConfigurationTesting) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров тд
В зависимости от типа проекта конфигурационное тестирование может иметь разные цели:
· Проект по профилированию работы системы
Цель Тестирования: определить оптимальную конфигурацию оборудования, обеспечивающую требуемые характеристики производительности и времени реакции тестируемой системы.
· Проект по миграции системы с одной платформы на другую
Цель Тестирования: Проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм.
Перед началом проведения конфигурационного тестирования рекомендуется:
· создавать матрицу покрытия (матрица покрытия - это таблица, в которую заносят все возможные конфигурации),
· проводить приоритезацию конфигураций (на практике, скорее всего, все желаемые конфигурации проверить не получится),
· шаг за шагом, в соответствии с расставленными приоритетами, проверяют каждую конфигурацию.
· Уже на начальном этапе становится очевидно, что чем больше требований к работе приложения при различных конфигурациях рабочих станций, тем больше тестов нам необходимо будет провести. В связи с этим, рекомендуем, по возможности, автоматизировать этот процесс, так как именно при конфигурационном тестировании автоматизация реально помогает сэкономить время и ресурсы. Конечно же автоматизированное тестирование не является панацеей, но в данном случае оно окажется очень эффективным помощником.
Модульнетестування.
Модульное тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.). Обычно модульное тестирование проводится вызывая код, который необходимо проверить и при поддержке сред разработки, таких как фреймворки (frameworks - каркасы) для модульного тестирования или инструменты для отладки. Все найденные дефекты, как правило исправляются в коде без формального их описания в системе менеджмента багов (BugTrackingSystem).
Один из наиболее эффективных подходов к модульному тестированию - это подготовка автоматизированных тестов до начала основного кодирования (разработки) программного обеспечения. Это называется разработка от тестирования (test-drivendevelopment) или подход тестирования вначале (testfirstapproach). При этом подходе создаются и интегрируются небольшие куски кода, напротив которых запускаются тесты, написанные до начала кодирования. Разработка ведется до тех пор пока все тесты не будут успешными.
26. Тестуваннязручностівикористання (usability).
Тестирование удобства пользования - это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:
· производительность, эффективность (efficiency) - сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д.? (меньше - лучше)
· правильность(accuracy) - сколько ошибок сделал пользователь во время работы с приложением? (меньше - лучше)
· активизация в памяти (recall) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени? (повторное выполнение операций после перерыва должно проходить быстрее чем у нового пользователя)
· эмоциональная реакция (emotionalresponse) – как пользователь себя чувствует после завершения задачи - растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция - лучше)
27. Звіти по помилках.
Баг или дефект репорт - это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.Разные системы менеджмента дефектами, предлагают нам разные поля для заполнения и разные структуры описания дефектов, но чаще всего баг-репорт содержит в себе информацию, распределенную по следующим пунктам:
Короткое описание проблемы; название тестируемого проекта; компонент приложения, где была найдена ошибка; номер версии тестируемого ПО; серьезность бага; приоритет бага; автор баг-репорта; спецификация системы на которой был найден баг; шаги воспроизведения; результат выполнения перечисленных выше шагов; результат, который ожидался
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. Если остается время после выполнения формального тестирования, заняться исследовательским (неформальным/интуитивным) тестированием.