
Ответы на вопросы зачета / Ответы на вопросы зачета по ТПО
.pdfДля каждого требования пишется один или более тестов, которые в совокупности должны проверить выполнение данного требования в продукте.
Тестирование сценариев:
•Определяется модель использования. Актором может быть пользователь, другой продукт, аппаратная часть и др.
•Разрабатываются сценарии использования продукта.
•Разрабатывается набор тестов, покрывающих заданные сценарии.
Ручная разработка тестов.
Производительность труда, характерная для ручной разработки тестов,
не намного выше скорости создания кода продукта, а объемы тестового кода на практике зачастую превышают объем кода продукта в 5 и более раз.
Генерация тестов.
Использование специальных тестовых языков (скриптов, например,
MSC) и генераторов тестов.
Использование подхода генерации позволяет значительно увеличить производительность тестирования.
31.Документация и сопровождение тестов
Тестовые процедуры — это формальный документ, содержащий описание необходимых шагов для выполнения тестового набора.
В случае описания ручных тестов тестовые процедуры должны содержать полное описание всех шагов и проверок, позволяющих протестировать продукт и вынести вердикт PASS/FAIL.
Описание тестов должно выполнять следующие задачи:
•Анализировать степень покрытия продукта тестами;
•Найти тесты использования всех функций ПО;
•Определить все функции и их сочетания, которые тест использует;
•Вывить структуру и взаимосвязи тестовых файлов;
•Выявить принцип построения системы автоматизации тестирования.
21
Документирование дефекта.
Каждый дефект, обнаруженный в процессе тестирования, должен быть задокументирован и отслежен. При обнаружении нового дефекта его заносят
вбазу дефектов. При занесении следует указывать:
•Наименование подсистемы.
•Версия продукта (номер build).
•Описание дефекта и шагов, необходимых для воспроизведения.
•Номер теста.
•Уровень критичности дефекта.
Тестовый отчет обновляется после каждого цикла тестирования:
•Перечень функций, запланированный для тестирования на данном цикле, и реальные данные по нему;
•Количество выполненных тестов (запланированное и реально исполненное);
•Время, затраченное на тестирование каждой функции, и общее время тестирования;
•Количество найденных дефектов;
•Отклонения от запланированной последовательности действий;
•Выводы о необходимых корректировках в системе тестов.
32.Оценка качества тестов
Набор тестовых метрик помогает определить эффективность
тестирования и текущее состояние продукта:
•Покрытие функциональных требований;
•Покрытие кода продукта (для модульного уровня тестирования);
•Покрытие множества сценариев;
•Количество или плотность найденных дефектов;
22
•Соотношение количества найденных дефектов с количеством тестов на данную функцию продукта;
•Количество найденных дефектов, соотнесенное по времени, или
скорость поиска дефектов.
Обзоры тестов и стратегии.
Тестовый код и стратегия тестирования, зафиксированные в виде документов, улучшаются, если подвергаются коллективному обсуждению.
Цели обзора тестовой стратегии:
•Установить достаточность проверок;
•Проанализировать оптимальность покрытия;
•Проанализировать оптимальность подхода к разработке кода,
автоматизации тестирования.
Цели обзора тестового кода:
•Установить соответствие тестового набора тестовой стратегии.
•Проверить правильность кодирования тестов.
•Оценить достигнутую степень качества кода.
•Возможно проанализировать оптимальность тестового кода.
33.Нагрузочное тестирование
Нагрузочное тестирование (Load Testing) — автоматизированное тестирование, имитирующее работу определенного количества пользователей на каком-либо общем для них ресурсе.
Нагрузочный тест имитирует одновременную работу нескольких сотен или тысяч пользователей, проверяя, будет ли устойчивой работа ПО под большой нагрузкой.
Основные цели:
•Оценка производительности и работоспособности ПО на этапе разработки, на этапе передачи в эксплуатацию, на этапе выпуска новых релизов;
•Оптимизация производительности ПО
23
• Подбор соответствующей аппаратной конфигурации.
Основные показатели нагрузочного тестирования:
•Уникальность запросов;
•Время отклика системы;
•Зависимость времени отклика системы от степени распределенности этой системы;
•Разброс времени отклика системы.
34.Основные этапы нагрузочного тестирования
Основные этапы проведения нагрузочного тестирования:
•Анализ требований и сбор информации о тестируемой системе;
•Конфигурация тестового стенда для нагрузочного тестирования;
•Разработка модели нагрузки;
•Выбор методов и инструментов для формирования нагрузки и сбора статистики;
•Создание и отладка тестовых скриптов;
•Проведение нагрузочного тестирования;
•Анализ результатов;
•Формирование отчета.
35.Основные виды нагрузочных тестов
Виды нагрузочных тестов:
•Тестирование производительности (определение масштабируемости приложения под нагрузкой);
•Стрессовое тестирование (насколько система работоспособна в условиях стресса);
•Объемное тестирование (получение оценки производительности при увеличении объемов данных в базе данных);
•Тестирование стабильности или надежности (с целью проверки отсутствия утечек памяти, выявления количества перезапусков под нагрузкой и другие аспекты, влияющие на стабильность);
24
•Тестирование моделирования транзакций (GUI-роботы;
моделирование работы приложения без участия пользователя);
•Тестирование методом анализа данных на стороне клиента
(отслеживание и анализ взаимодействия приложения и ОС);
•Тестирование методом анализа сетевого трафика (извлечение данных о времени реакции приложения, его доступности и др.);
•Тестирование масштабируемости (способность увеличивать производительность с ростом нагрузки и/или т.п.).
36.Основные инструменты формирования нагрузки и сбора статистики при выполнении нагрузочного тестирования
•С использованием общего ПО для сбора статистики, например, Cacti,
Nagios, Zabbix, mrtg, Mozilla Firefox (Firebug), Google Chrome
(Диспетчер задач, Инструменты разработчика) и др.
•С использованием общесистемного ПО ОС GNU Linux (top, vmstat, iotop, iostat, sysstat, sar, sockstat, sysstat и др.)
•С использованием ПО, специально разработанного для формирования нагрузки (ab, httperf, Jmeter, Grinder для java-серверов, dnsperf, iperf, netperf и др.).
37.Регрессионное тестирование
Регрессионное тестирование — вид тестирования, который производится при внесении изменений на этапе системного тестирования или сопровождения продукта. Позволяет убедиться, что изменения не вызвали нежелательных побочных эффектов.
Если модифицированный код оказал влияние на функциональность программы (на этапе сопровождения), то говорят о регрессионном эффекте.
Пример.
Программист, получив отчет об ошибке, анализирует исходный код,
находит ошибку, исправляет ее и тестирует результат.
25

Тестировщик должен проверить и утвердить исправление ошибки,
попробовать воспроизвести ошибку другим способом, протестировать
последствия исправлений.
38.Цели и задачи регрессионного тестирования
Цели регрессионного тестирования:
•Гарантировать тот же уровень покрытия, что и при полном повторном тестировании программы.
•Удостовериться, что программа функционирует в соответствии со своей спецификацией.
Рисунок 38.1 Задачи регрессионного тестирования:
•Уменьшение стоимости выполнения тестов;
•Сокращение времени выполнения тестов.
Практический вариант решения задачи выборочного регрессионного тестирования состоит в получении множества, которое включает все тесты,
активирующие измененный код, и не включающее никакие другие тесты.
39.Виды регрессионного тестирования
3типа сопровождения ПО:
•Корректирующее (исправление ошибки, не требующей изменения спецификации требований).
•Адаптивное (в ответ на требования изменения данных или среды исполнения).
•Прогрессивное (с целью повышения эффективности работы системы или сопровождения).
26
2типа регрессионного тестирования:
•Прогрессивное регрессионное тестирование предполагает модификацию технического задания.
•Корректирующее регрессионное тестирование предполагает модификацию кода без изменения спецификации.
Подходы к отбору регрессионных тестов:
•Активный подход (уменьшение объема тестирования).
•Консервативный подход (отбор всех тестов).
40.Управляемое регрессионное тестирование
Для обеспечения управляемости регрессионного тестирования
необходимо выполнение следующих условий:
•Должны использоваться реальные модули системы;
•Информация об изменениях должна быть корректна;
•В программе нет ошибок, кроме тех, которые могли возникнуть из-за её изменения;
•Тесты предыдущих версий продукта доступны;
•Необходимо хранить информацию о результатах выполнения тестов предыдущих этапов тестирования.
41.Обоснование корректности метода отбора тестов
•Если код не менялся и входные данные тоже (для заданного теста), то нет необходимости прогонять этот тест повторно.
•Если отрывок кода не менялся и поведение которого не зависело от измененного кода, то нет необходимости прогонять этот тест повторно.
•Необходимо ориентироваться на выбор только тех тестов, которые покрывают измененный код.
42.Классификация тестов при отборе
1.Множество тестов, пригодных для повторного использования.
2.Множество тестов, требующих повторного запуска.
27

3.Множество устаревших тестов.
4.Новые тесты, которые еще не запускались и могут быть использованы для тестирования.
Рисунок 42.1
43.Возможности повторного использования тестов
Уровни повторного использования теста:
•Уровень 1. Тест не допускает повторного использования и требуется создание нового набора тестов.
•Уровень 2. Повторное использование возможно только для входных данных теста.
•Уровень 3. Возможно повторное использование как входных, так и выходных данных теста.
•Уровень 4. Наивысший уровень повторного использования теста.
Критерии оценки методики выборочного повторного тестирования:
•Критерий 1. Безопасность (выбор тестов, которые потенциально могут обнаруживать ошибки).
•Критерий 2. Точность (выбор только тестов с изменившимся поведением). В лучшем случае можно рассчитывать лишь на некоторое увеличение точности.
•Критерий 3. Эффективность (применение автоматизации и хранение информации о ходе исполнения тестов в минимально возможном объеме).
•Критерий 4. Универсальность (применимость ко всем языкам и языковым конструкциям).
28
В общем случае целесообразно находить некоторый компромисс между безопасностью, точностью, эффективностью и универсальностью.
44.Классификация выборочных методов
Для проверки корректности различных подходов к регрессионному тестированию используется модель оценки методов регрессионного тестирования по критериям:
•Полнота — мера отбора тестов, на которых результат выполнения измененной программы отличен от результата выполнения исходной программы, вследствие чего могут быть обнаружены ошибки в модифицированной программе. Метод, полный на 100%, называется безопасным.
•Точность — мера способности метода избегать выбора тестов,
неспособных обнаруживать ошибки в модифицированной программе.
Точность множества тестов — отношение числа тестов данного множества, на которых результаты выполнения новой и старой программ различаются, к общему числу тестов множества.
•Эффективность — оценка вычислительной стоимости реализации требований тестирования по времени и памяти, а также возможности автоматизации.
•Универсальность — мера способности метода к применению в достаточно широком диапазоне ситуаций.
29