6 необходимых критериев спецификации тестирование

При проведении тестирования необходимо определить критерии окончания процесса тестирования. ведь недостаток тестирования может вести к выпуску продукта с существенными недостатками.

При проведении тестирования необходимо определить критерии окончания процесса тестирования. Ведь недостаток тестирования может вести к выпуску продукта с существенными недостатками. А «лишнее» тестирование может стоить достаточно дорого, задерживать выпуск продукта и отвлекать тестировщиков от других работ.

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

Еще одним важным понятием в теории тестирования является понятие критериев покрытия тестирования. Не следует путать метрики тестирования и критерии покрытия тестирования. Последние позволяют определить степень покрытия разрабатываемого продукта тестами. Поэтому часто критерии покрытия используются для определения метрик тестирования.

Приведем примеры самых распространенных критериев покрытия при тестировании функциональных требований в соответствии с методологией RUP.

При тестировании функциональных требований могут быть выделены, по крайней мере, два типа покрытия: покрытие, основанное на спецификации, и покрытие, основанное на коде.

Покрытие, основанное на спецификации или на требованиях (Specification-Based Coverage or Requirements-based Test Coverage).

Этот критерий оценивает степень покрытия, принимая во внимание требования Заказчика или системные спецификации. Основой может быть, например, таблица требований, use case модель и диаграмма состояний-переходов. Набор тестов должен покрывать все или конкретно определенные функциональные требования. На практике это чаще всего реализуется следующим образом: Заказчик (или системный аналитик) составляет набор требований, которые могут быть переведены в тестовые сценарии. После чего эти сценарии могут быть проверены на правильность и полноту.

Таким образом, данный критерий показывает в процентном отношении количество покрытых тестами требований. Чаще всего данный критерий используется при тестировании методом «черного ящика».

Покрытие, основанное на коде (Code-Based Coverage) имеет отношение к потоку управления и потоку данных программы. Чаще всего данный критерий используется при тестировании методом «белого ящика». Основные критерии покрытия тестирования кода следующие:

  • Покрытие строк (Line Coverage) – мера измерения покрытия кода, указывающая процентное отношение строк программы, затронутых тестами, к общему числу строк. Это очень неточная метрика, потому что даже стопроцентное покрытие по ней пропускает много ошибок.
  • Покрытие ветвей (Branch Coverage). Это мера измерения покрытия кода указывает в процентном отношении, сколько ветвей потока управления было протестировано во время теста. Она надежнее предыдущей метрики, но снова стопроцентное покрытие не гарантирует отсутствие ошибок.
  • Покрытие путей (Path Coverage). Эта единица измерения характеризует процент всевозможных путей (и/или комбинаций ветвей), которые покрываются тестами. Однако, даже не смотря на 100-процентное покрытие (достичь которого практически нереально в коммерческих системах) все еще могут присутствовать скрытые ошибки.

Метрики и критерии тестирования определяются в стратегии тестирования наряду с остальными составляющими процесса.

Тестирование. Фундаментальная теория

Материал взят на dou.ua.

Все замечания, корректировки и дополнения очень приветствуются.

Тестирование программного обеспечения — проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. В более широком смысле, тестирование — это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Качество программного обеспечения (Software Quality) — это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. [ISO 8402:1994 Quality management and quality assurance]

Верификация (verification) — это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа[IEEE]. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1].
Также можно встретить иную интерпритацию:
Процесс оценки соответствия продукта явным требованиям (спецификациям) и есть верификация (verification), в то же время оценка соответствия продукта ожиданиям и требованиям пользователей — есть валидация (validation). Также часто можно встретить следующее определение этих понятий:
Validation — ’is this the right specification?’.
Verification — ’is the system correct to specification?’.

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

Этапы тестирования:
1. Анализ
2. Разработка стратегии тестирования
и планирование процедур контроля качества
3. Работа с требованиями
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Стабилизация
8. Эксплуатация

Тест план (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Отвечает на вопросы:
Что надо тестировать?
Что будете тестировать?
Как будете тестировать?
Когда будете тестировать?
Критерии начала тестирования.
Критерии окончания тестирования.

Основные пункты тест плана
В стандарте IEEE 829 перечислены пункты, из которых должен (пусть — может) состоять тест-план:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Environmental needs;
l) Responsibilities;
m) StafÞng and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.

Тест дизайн — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.
Роли, ответственные за тест дизайн:
• Тест аналитик — определяет «ЧТО тестировать?»
• Тест дизайнер — определяет «КАК тестировать?»

Техники тест дизайна

• Эквивалентное Разделение (Equivalence Partitioning — EP). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала — 0.

• Анализ Граничных Значений (Boundary Value Analysis — BVA). Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

• Причина / Следствие (Cause/Effect — CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как «Имя», «Адрес», «Номер Телефона» а затем, нажать кнопку «Добавить» — эта «Причина». После нажатия кнопки «Добавить», система добавляет клиента в базу данных и показывает его номер на экране — это «Следствие».

• Предугадывание ошибки (Error Guessing — EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тест аналитик, будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? », и так далее. Это и есть предугадывание ошибки.

• Исчерпывающее тестирование (Exhaustive Testing — ET) — это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.

Traceability matrix — Матрица соответствия требований — это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.
Матрица соответсвия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.

Тестовый случай (Test Case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Пример:
Action Expected Result Test Result
(passed/failed/blocked)
Open page «login» Login page is opened Passed

Каждый тест кейс должен иметь 3 части:
PreConditions Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям
PostConditions Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state)
Виды Тестовых Случаев:
Тест кейсы разделяются по ожидаемому результату на позитивные и негативные:
• Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
• Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.

Чек-лист (check list) — это документ, описывающий что должно быть протестировано. При этом чек-лист может быть абсолютно разного уровня детализации. На сколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта.
Как правило, чек-лист содержит только действия (шаги), без ожидаемого результата. Чек-лист менее формализован чем тестовый сценарий. Его уместно использовать тогда, когда тестовые сценарии будут избыточны. Также чек-лист ассоциируются с гибкими подходами в тестировании.

Дефект (он же баг) — это несоответствие фактического результата выполнения программы ожидаемому результату. Дефекты обнаруживаются на этапе тестирования программного обеспечения (ПО), когда тестировщик проводит сравнение полученных результатов работы программы (компонента или дизайна) с ожидаемым результатом, описанным в спецификации требований.

Error — ошибка пользователя, то есть он пытается использовать программу иным способом.
Пример — вводит буквы в поля, где требуется вводить цифры (возраст, количество товара и т.п.).
В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message), с красным крестиком которые.
Bug (defect) — ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так как планировалось и программа выходит из-под контроля. Например, когда никак не контроллируется ввод пользователя, в результате неверные данные вызывают краши или иные «радости» в работе программы. Либо внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (A defect caused the failure) и существуют такие, которые не приводят. UI-дефекты например. Но аппаратный сбой, никак не связанный с software, тоже является failure.

Баг Репорт (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Шапка
Короткое описание (Summary) Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.
Проект (Project) Название тестируемого проекта
Компонент приложения (Component) Название части или функции тестируемого продукта
Номер версии (Version) Версия на которой была найдена ошибка
Серьезность (Severity) Наиболее распространена пятиуровневая система градации серьезности дефекта:
• S1 Блокирующий (Blocker)
• S2 Критический (Critical)
• S3 Значительный (Major)
• S4 Незначительный (Minor)
• S5 Тривиальный (Trivial)
Приоритет (Priority) Приоритет дефекта:
• P1 Высокий (High)
• P2 Средний (Medium)
• P3 Низкий (Low)
Статус (Status) Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle)

Автор (Author) Создатель баг репорта
Назначен на (Assigned To) Имя сотрудника, назначенного на решение проблемы
Окружение
ОС / Сервис Пак и т.д. / Браузера + версия / … Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования — имя и версия браузера и т.д.

Описание
Шаги воспроизведения (Steps to Reproduce) Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.
Фактический Результат (Result) Результат, полученный после прохождения шагов к воспроизведению
Ожидаемый результат (Expected Result) Ожидаемый правильный результат
Дополнения
Прикрепленный файл (Attachment) Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы

Severity vs Priority
Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения.
Приоритет (Priority) — это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.
Severity выставляется тестировщиком
Priority — менеджером, тимлидом или заказчиком

Градация Серьезности дефекта (Severity)

S1 Блокирующая (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.

S2 Критическая (Critical)
Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.

S3 Значительная (Major)
Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.

S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.

S5 Тривиальная (Trivial)
Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная посредствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Градация Приоритета дефекта (Priority)
P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Уровни Тестирования

1. Модульное тестирование (Unit Testing)
Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).

2. Интеграционное тестирование (Integration Testing)
Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

3. Системное тестирование (System Testing)
Основной задачей системного тестирования является проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство использования и т.д.

4. Операционное тестирование (Release Testing).
Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации, как это было определено в бизнес моделе системы. Следует учесть, что и бизнес модель может содержать ошибки. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях; недостаточная производительность системы в среде эксплуатации и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема. Поэтому так важно проведение не только верификации, но и валидации, с самых ранних этапов разработки ПО.

5. Приемочное тестирование (Acceptance Testing)
Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:
• определения удовлетворяет ли система приемочным критериям;
• вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.

Виды / типы тестирования

Функциональные виды тестирования

• Функциональное тестирование (Functional testing)
• Тестирование безопасности (Security and Access Control Testing)
• Тестирование взаимодействия (Interoperability Testing)

Прокрутить вверх

©2015- 2022 stydopedia.ru Все материалы защищены законодательством РФ.

При
создании программ, опирающемся на
тестирование (test-driven) и получившем
известность благодаря методам «скорой»
(agile) разработки, тесты ставят на первое
место, но иногда считают, что они могут
заменить спецификации. Не могут. Тесты,
даже если их миллион, — это лишь примеры;
в них отсутствует абстракция, которую
может дать только спецификация.

Принцип
2. Тесты или спецификации.
 Тесты
не заменяют спецификации.

Опасность
заблуждения, что тесты могут выступать
в роли спецификаций, была продемонстрирована
целым рядом программных катастроф,
которые произошли только потому, что
никто не подумал об исключительном
случае. Несмотря на то, что в спецификациях
тоже могут быть упущены из виду какие-то
случаи, по крайней мере, в них предпринимается
попытка некого обобщения. В частности,
спецификации могут использоваться для
генерации тестов, даже автоматически
(как в случае тестирования, опирающегося
на модели); но обратное без вмешательства
человека невозможно.

Регрессивное тестирование

Особенностью
тестирования, если судить по практике
создания программного обеспечения,
является печальная склонность к появлению
уже исправленных ошибок. Старые головы
у гидры, как бы глубоко они ни были
отсечены, вырастают снова. Это явление
известно как регрессия и заставляет
использовать регрессивное тестирование,
то есть проверку того, что исправленное
ранее по-прежнему работает. Как следствие,
вы всегда должны помнить об ошибке,
которую уже когда-то обнаружили.

Принцип
3. Регрессивное тестирование.
 Любое
неудачное выполнение должно порождать
тестовый случай, который навсегда
становится частью тестового пакета
данного проекта.

Этот
принцип касается всех ошибок, возникших
во время разработки и тестирования.
Отсюда вытекает необходимость в
инструментарии, позволяющем превращать
неудачное исполнение в воспроизводимый
тестовый случай, и недавно такой
инструментарий появился: Contract-Driven
Development, ReCrash, JCrasher.

Предсказания

Выполнение
теста полезно только в том случае, если
вы можете однозначно определить, прошел
ли он. Критерий называется предсказанием
теста. Если у вас есть несколько десятков
или даже сотен тестов, то вы в состоянии
проверить их результаты по отдельности,
однако с увеличением их количества это
становится все менее вероятным. Данная
задача требует автоматизации.

Принцип
4. Использование предсказаний.
 Определение
успеха или неудачи тестов должно
происходить автоматически.

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

Принцип
4 (вариант). Контракты как
предсказания.
 Предсказания
должны быть частью текста программы
как контракты. Успех или неудача теста
должны определяться автоматически,
причем в рамках этого процесса необходимо
вести мониторинг выполнения контракта
во время работы программы.

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

Тестовые
случаи, проверяемые вручную и автоматически

Многие
тестовые случаи проверяются вручную.
Тестеры продумывают интересные сценарии
выполнения и готовят соответствующие
тесты. К этой категории можно добавить
тесты, полученные в соответствии с
принципом 3 как результат некорректного
выполнения, их первоначально не
предполагалось использовать при
тестировании. Сейчас все чаще можно
дополнить эти две категории автоматическими
тестовыми случаями, полученными из
спецификаций с помощью генератора
автоматических тестов. Процесс,
ограниченный тестами, выполняемыми
вручную, не в полной мере использует
возможности современных компьютеров.

Все
подходы лишь дополняют друг друга.

Принцип
5. Тестовые случаи, проверяемые вручную
и автоматически.
Эффективный
процесс тестирования должен включать
в себя тестовые случаи, проверяемые как
вручную, так и автоматически.

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

Стратегии
тестирования

Теперь
мы переходим от практики тестирования
к исследованиям новых технологий
тестирования, которые, однако, уязвимы
в смысле рисков мыслительного процесса.
Вы придумали идею, которая, как вам
кажется, обещает усовершенствования и
подтверждается вашей интуицией.
Тестирование — это сложный процесс, и
после объективного анализа далеко не
все разумные идеи оказываются полезными.
Типичный тому пример — случайное
тестирование. Интуитивно кажется, что
любая стратегия, использующая знания
о программе, должна быть лучше случайного
ввода. Однако объективные показатели,
такие как число найденных ошибок,
свидетельствуют о том, что случайное
тестирование часто превосходит казавшиеся
разумными идеи. В обзоре Ричарда Хемлета,
посвященном случайному тестированию
(Encyclopedia of Software Engineering, J.J. Marciniak, ed., Wiley,
1994), приводится захватывающее
противопоставление человеческого
знания и научного анализа.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #

    19.02.2016258.56 Кб97.doc

  • #
  • #
  • #
  • #

    19.02.2016319.49 Кб88.doc

  • #
  • #
  • #

4.2.4. Критерии оценки и выбора

Критерии формируют базис для процессов оценки и выбора и могут принимать различные формы, включая:

  • числовые меры в широком диапазоне значений, например, объем требуемой памяти;
  • числовые меры в ограниченном диапазоне значений, например, простота освоения, выраженная в баллах от 1 до 5;
  • двоичные меры (истина/ложь, да/нет), например, способность генерации документации в формате Postscript;
  • меры, которые могут принимать одно или более из конечных множеств значений, например, платформы, для которых поддерживается CASE-средство.

Типичный процесс оценки и/или выбора может использовать набор критериев различных типов.

Структура набора критериев приведена на рисунке 4.3. Каждый критерий должен быть выбран и адаптирован экспертом с учетом особенностей конкретного процесса. В большинстве случаев только некоторые из множества описанных ниже критериев оказываются приемлемыми для использования, при этом также добавляются дополнительные критерии. Выбор и уточнение набора используемых критериев является критическим шагом в процессе оценки и/или выбора.

Функциональные характеристики

Критерии первого класса предназначены для определения функциональных характеристик CASE-средства. Они в свою очередь подразделяются на ряд групп и подгрупп.

  1. Среда функционирования:
    1. Проектная среда:

      • поддержка процессов жизненного цикла
      • . Определяет набор процессов ЖЦ, которые поддерживает CASE-средство. Примерами таких процессов являются анализ требований, проектирование, реализация, тестирование и оценка, сопровождение, обеспечение качества, управление конфигурацией и управление проектом, причем они зависят от принятой пользователем модели ЖЦ.

      • область применения.
      • Примерами являются системы обработки транзакций, системы реального времени, информационные системы и т.д.

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

    2. ПО/технические средства:

      • требуемые технические средства
      • . Оборудование, необходимое для функционирования CASE-средства, включая тип процессора, объем оперативной и дисковой памяти.

      • поддерживаемые технические средства
      • . Элементы оборудования, которые могут использоваться CASE-средством, например, устройства ввода/вывода.

      • требуемое ПО
      • . ПО, необходимое для функционирования CASE-средства, включая операционные системы и графические оболочки.

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

      Рис. 4.3. Структура набора критериев

    3. Технологическая среда:

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

      • совместимость с другими средствами
      • . Способность к взаимодействию с другими средствами, включая непосредственный обмен данными (примерами таких средств являются текстовые процессоры, базы данных и другие CASE-средства). Возможность преобразования репозитория или его части в стандартный формат для обработки другими средствами.

      • поддерживаемая методология
      • . Набор методов и методик, поддерживаемых CASE-средством. Примерами являются структурный или объектно-ориентированный анализ и проектирование.

      • поддерживаемые языки
      • . Все языки, используемые CASE-средством. Примерами таких языков являются языки программирования (Кобол, Ада, С), языки баз данных и языки запросов (DDL, SQL), графические языки (Postscript, HPGL), языки спецификации проектных требований и интерфейсы операционных систем (языки управления заданиями).

  2. Функции, ориентированные на фазы жизненного цикла:
    1. Моделирование:

      Данные критерии определяют способность выполнения функций, необходимых для спецификации требований к ПО и преобразованию их в проект:

      • построение диаграмм
      • . Возможность создания и редактирования диаграмм различных типов, представляющих интерес для пользователя. Наиболее распространенные типы диаграмм описаны в разделе 2.

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

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

      • язык спецификации требований и проектных спецификаций
      • . Возможность импорта, экспорта и редактирования спецификаций с использованием формального языка.

      • моделирование данных
      • . Возможность ввода и редактирования информации, описывающей элементы данных системы и их отношения.

      • моделирование процессов
      • . Возможность ввода и редактирования информации, описывающей процессы системы и их отношения.

      • проектирование архитектуры ПО
      • . Проектирование логической структуры ПО — структуры модулей, интерфейсов и др.

      • имитационное моделирование
      • . Возможность динамического моделирования различных аспектов функционирования системы на основе спецификаций требований и/или проектных спецификаций, включая внешний интерфейс и производительность (например, время отклика, коэффициент использования ресурсов и пропускную способность).

      • прототипирование.
      • Возможность проектирования и генерации предварительного варианта всей системы или ее отдельных компонент на основе спецификаций требований и/или проектных спецификаций. Прототипирование в основном касается внешнего пользовательского интерфейса и осуществляется при непосредственном участии пользователей.

      • генерация экранных форм
      • . Возможность генерации экранных форм на основе спецификаций требований и/или проектных спецификаций.

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

      • синтаксический и семантический контроль проектных спецификаций.
      • Контроль синтаксиса диаграмм и типов их элементов, контроль декомпозиции функций, проверка спецификаций на полноту и непротиворечивость.

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

      • автоматизированное проектирование отчетов.
    2. Реализация:

      Реализация затрагивает функции, связанные с созданием исполняемых элементов системы (программных кодов) или модификацией существующей системы. Многие из перечисленных ниже критериев зависят от конкретных языков и включают следующие:

      • синтаксически управляемое редактирование
      • . Возможность ввода и редактирования исходных кодов на одном или нескольких языках с одновременным синтаксическим контролем.

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

      • компиляция кода.
      • конвертирование исходного кода
      • . Возможность преобразования кода из одного языка в другой.

      • анализ надежности
      • . Возможность количественно оценивать параметры надежности ПО, такие, как количество ошибок и др.

      • реверсный инжиниринг
      • . Возможность анализа существующих исходных кодов и формирования на их основе проектных спецификаций.

      • реструктуризация исходного кода
      • . Возможность модификации формата и/или структуры существующего исходного кода.

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

      • отладка
      • . Типичные функции отладки — трассировка программ, выделение узких мест и наиболее часто используемых фрагментов кода и т.д.

    3. Тестирование:

      Критерии тестирования включают следующие:

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

      • фиксация и повторение действий оператора
      • . Возможность фиксировать данные, вводимые оператором с помощью клавиатуры, мыши и т.д., редактировать их и воспроизводить в тестовых примерах.

      • автоматический запуск тестовых примеров.
      • регрессионное тестирование
      • . Возможность повторения и модификации ранее выполненных тестов для определения различий в системе и/или среде.

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

      • анализ тестового покрытия
      • . Оснащенность средствами контроля исходного кода и анализ тестового покрытия. Проверяются, в частности, обращения к операторам, процедурам и переменным.

      • анализ производительности
      • . Возможность анализа производительности программ. Анализируемые параметры производительности могут включать использование центрального процессора, памяти, обращения к определенным элементам данных и/или сегментам кода, временные характеристики и т.д.

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

  3. Общие функции:

    Приведенные ниже критерии определяют функции CASE-средств, охватывающие всю совокупность фаз ЖЦ. Поддержка всех этих функций осуществляется посредством репозитория.

    1. Документирование:

      • редактирование текстов и графики
      • . Возможность вводить и редактировать данные в текстовом и графическом формате.

      • редактирование с помощью форм
      • . Возможность поддерживать формы, определенные пользователями, вводить и редактировать данные в соответствии с формами.

      • возможности издательских систем.
      • поддержка функций и форматов гипертекста.
      • соответствие стандартам документирования.
      • автоматическое извлечение данных из репозитория и генерация документации по спецификациям пользователя.
    2. Управление конфигурацией:

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

      • отслеживание модификаций
      • . Фиксация и ведение журнала всех модификаций, внесенных в систему в процессе разработки или сопровождения.

      • управление версиями
      • . Ведение и контроль данных о версиях системы и всех ее коллективно используемых компонентах.

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

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

      • архивирование
      • . Возможность автоматического архивирования элементов данных для последующего использования.

    3. Управление проектом:

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

      • оценка
      • . Возможность оценивать затраты, график и другие проектные параметры, вводимые пользователями.

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

      • управление качеством
      • . Ввод соответствующих данных, их анализ и генерация отчетов.

      • корректирующие действия
      • . Поддержка управления корректирующими действиями, включая обработку сообщений о проблемных ситуациях.

Назад | Содержание | Вперед

Тестирование программного обеспечения (ПО) выявляет недоработки, изъяны и ошибки в коде, которые необходимо устранить. Его также можно определить как процесс оценки функциональных возможностей и корректности ПО с помощью анализа. Основные методы интеграции и тестирования программных продуктов обеспечивают качество приложений и заключаются в проверке спецификации, дизайна и кода, оценке надежности, валидации и верификации.

Методы

Главная цель тестирования ПО — подтверждение качества программного комплекса путем систематической отладки приложений в тщательно контролируемых условиях, определение их полноты и корректности, а также обнаружение скрытых ошибок.

Методы можно разделить на статические и динамические.

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

Динамические техники следующие:

  1. Тестирование методом белого ящика.
    Это подробное исследование внутренней логики и структуры программы. При этом необходимо знание исходного кода.
  2. Тестирование методом черного ящика.
    Данная техника не требует каких-либо знаний о внутренней работе приложения. Рассматриваются только основные аспекты системы, не связанные или мало связанные с ее внутренней логической структурой.
  3. Метод серого ящика.
    Сочетает в себе предыдущие два подхода. Отладка с ограниченным знанием о внутреннем функционировании приложения сочетается со знанием основных аспектов системы.

Прозрачное тестирование

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

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

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

Недостатки:

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

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

Основные разновидности:

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

2) отладка ветвления имеет целью исследование каждой опции (истинной или ложной) каждого оператора управления, который также включает в себя объединенное решение;

3) тестирование основного пути, которое позволяет тестировщику установить меру логической сложности процедурного проекта для выделения базового набора путей выполнения;

4) проверка потока данных — стратегия исследования потока управления путем аннотации графа информацией об объявлении и использовании переменных программы;

5) тестирование циклов — полностью сосредоточено на правильном выполнении циклических процедур.

Поведенческая отладка

Тестирование методом черного ящика рассматривает ПО как «черный ящик» — сведения о внутренней работе программы не учитываются, а проверяются только основные аспекты системы. При этом тестировщику необходимо знать системную архитектуру без доступа к исходному коду.

Преимущества такого подхода:

  • эффективность для большого сегмента кода;
  • простота восприятия тестировщиком;
  • перспектива пользователя четко отделена от перспективы разработчика (программист и тестировщик независимы друг от друга);
  • более быстрое создание теста.

Тестирование программ методами черного ящика имеет следующие недостатки:

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

Другие названия данной техники — поведенческое, непрозрачное, функциональное тестирование и отладка методом закрытого ящика.

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

2) краевой анализ фокусируется на проверке границ или экстремальных граничных значений — минимумах, максимумах, ошибочных и типичных значениях;

3) фаззинг — используется для поиска погрешностей реализации с помощью ввода искаженных или полуискаженных данных в автоматическом или полуавтоматическом режиме;

4) графы причинно-следственных связей — методика, основанная на создании графов и установлении связи между действием и его причинами: тождественность, отрицание, логическое ИЛИ и логическое И — четыре основных символа, выражающие взаимозависимость между причиной и следствием;

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

6) тестирование всех пар — техника, набор тестовых значений которой включает все возможные дискретные комбинации каждой пары входных параметров;

Тестирование методом черного ящика: примеры

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

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

Тестировщик, таким образом, взаимодействует с ПО путем ввода, воздействуя на переключатели, кнопки или другие интерфейсы. Выбор входных данных, порядок их введения или очередность действий могут привести к гигантскому суммарному числу комбинаций, как это видно на следующем примере.

Какое количество тестов необходимо произвести, чтобы проверить все возможные значения для 4 окон флажка и одного двухпозиционного поля, задающего время в секундах? На первый взгляд расчет прост: 4 поля с двумя возможными состояниями — 24 = 16, которые необходимо умножить на число возможных позиций от 00 до 99, то есть 1600 возможных тестов.

Тем не менее этот расчет ошибочен: мы можем определить, что двухпозиционное поле может также содержать пробел, т. е. оно состоит из двух буквенно-цифровых позиций и может включать символы алфавита, специальные символы, пробелы и т. д. Таким образом, если система представляет собой 16-битный компьютер, то получится 216 = 65 536 вариантов для каждой позиции, результирующих в 4 294 967 296 тестовых случаев, которые необходимо умножить на 16 комбинаций для флажков, что в общей сложности дает 68 719 476 736. Если их выполнить со скоростью 1 тест в секунду, то общая продолжительность тестирования составит 2 177,5 лет. Для 32 или 64-битных систем, длительность еще больше.

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

Эквивалентное разбиение

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

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

Другим следствием такого разбиения является сокращение комбинаторного взрыва между различными переменными и связанное с ними сокращение тестовых случаев.

Например, в (1/x) 1/2 используется три последовательности данных, три эквивалентных разбиения:

1. Все положительные числа будут обрабатываться таким же образом и должны давать правильные результаты.

2. Все отрицательные числа будут обрабатываться так же, с таким же результатом. Это неверно, так как корень из отрицательного числа является мнимым.

3. Ноль будет обрабатываться отдельно и даст ошибку «деление на ноль». Это раздел с одним значением.

Таким образом, мы видим три различных раздела, один из которых сводится к единственному значению. Есть один «правильный» раздел, дающий достоверные результаты, и два «неправильных», с некорректными результатами.

Краевой анализ

Обработка данных на границах эквивалентного разбиения может выполняться иначе, чем ожидается. Исследование граничных значений — хорошо известный способ анализа поведения ПО в таких областях. Эта техника позволяет выявить такие ошибки:

  • неправильное использование операторов отношения (, =, ≠, ≥, ≤);
  • единичные ошибки;
  • проблемы в циклах и итерациях,
  • неправильные типы или размер переменных, используемых для хранения информации;
  • искусственные ограничения, связанные с данными и типами переменных.

Полупрозрачное тестирование

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

При использовании этой техники тестировщик для разработки тестовых значений должен обладать знаниями о внутренних структурах данных и алгоритмах. Примерами методики тестирования серого ящика являются:

  • архитектурная модель;
  • унифицированный язык моделирования (UML);
  • модель состояний (конечный автомат).

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

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

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

Недостатки:

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

Другое название техники серого ящика — полупрозрачная отладка.

1) ортогональный массив — использование подмножества всех возможных комбинаций;

2) матричная отладка с использованием данных о состоянии программы;

3) проводимая при внесении новых изменений в ПО;

4) шаблонный тест, который анализирует дизайн и архитектуру добротного приложения.

тестирования ПО

Использование всех динамических методов приводит к комбинаторному взрыву количества тестов, которые должны быть разработаны, воплощены и проведены. Каждую технику следует использовать прагматично, принимая во внимание ее ограничения.

Единственно верного метода не существует, есть только те, которые лучше подходят для конкретного контекста. Структурные техники позволяют найти бесполезный или вредоносный код, но они сложны и неприменимы к крупным программам. Методы на основе спецификации — единственные, которые способны выявить недостающий код, но они не могут идентифицировать посторонний. Одни техники больше подходят для конкретного уровня тестирования, типа ошибок или контекста, чем другие.

Ниже приведены основные отличия трех динамических техник тестирования — дана таблица сравнения между тремя формами отладки ПО.

Аспект

Метод черного ящика

Метод серого ящика

Метод белого ящика

Наличие сведений о составе программы

Анализируются только базовые аспекты

Частичное знание о внутреннем устройстве программы

Полный доступ к исходному коду

Степень дробления программы

Кто производит отладку?

Конечные пользователи, тестировщики и разработчики

Конечные пользователи, отладчики и девелоперы

Разработчики и тестировщики

Тестирование базируется на внешних внештатных ситуациях.

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

Внутреннее устройство полностью известно

Степень охвата

Наименее исчерпывающая и требует минимума времени

Потенциально наиболее исчерпывающая. Требует много времени

Данные и внутренние границы

Отладка исключительно методом проб и ошибок

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

Лучшее тестирование доменов данных и внутренних границ

Пригодность для тестирования алгоритма

Автоматизация

Автоматические методы тестирования программных продуктов намного упрощают процесс проверки независимо от технической среды или контекста ПО. Их используют в двух случаях:

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

2) для выполнения или отслеживания задач, которые не могут быть легко осуществимы людьми, таких как проверка производительности или анализ времени отклика, которые могут измеряться в сотых долях секунды.

Тестовые инструменты могут быть классифицированы по-разному. Следующее деление основано на поддерживаемых ими задачах:

  • управление тестированием, которое включает поддержку управления проектом, версиями, конфигурациями, риск-анализ, отслеживание тестов, ошибок, дефектов и инструменты создания отчетов;
  • управление требованиями, которое включает хранение требований и спецификаций, их проверку на полноту и многозначность, их приоритет и отслеживаемость каждого теста;
  • критический просмотр и статический анализ, включая мониторинг потока и задач, запись и хранение комментариев, обнаружение дефектов и плановых коррекций, управление ссылками на проверочные списки и правила, отслеживание связи исходных документов и кода, статический анализ с обнаружением дефектов, обеспечением соответствия стандартам написания кода, разбором структур и их зависимостей, вычислением метрических параметров кода и архитектуры. Кроме того, используются компиляторы, анализаторы связей и генераторы кросс-ссылок;
  • моделирование, которое включает инструменты моделирования бизнес-поведения и проверки созданных моделей;
  • разработка тестов обеспечивает генерацию ожидаемых данных исходя из условий и интерфейса пользователя, моделей и кода, управление ими для создания или изменения файлов и БД, сообщений, проверки данных исходя из правил управления, анализа статистики условий и рисков;
  • критический просмотр путем ввода данных через графический интерфейс пользователя, API, командные строки с использованием компараторов, помогающих определить успешные и неудавшиеся тесты;
  • поддержка сред отладки, которая позволяет заменить отсутствующее оборудование или ПО, в т. ч. симуляторы оборудования на основе подмножества детерминированного выхода, эмуляторы терминалов, мобильных телефонов или сетевого оборудования, среды для проверки языков, ОС и аппаратного обеспечения путем замены недостающих компонентов драйверами, фиктивными модулями и др., а также инструменты для перехвата и модификации запросов ОС, симуляции ограничений ЦПУ, ОЗУ, ПЗУ или сети;
  • сравнение данных файлов, БД, проверка ожидаемых результатов во время и по окончании тестирования, в т. ч. динамическое и пакетное сравнение, автоматические «оракулы»;
  • измерение покрытия для локализации утечек памяти и некорректного управления ею, оценки поведения системы в условиях симулированной нагрузки, генерации нагрузки приложений, БД, сети или серверов по реалистичным сценариям ее роста, для измерения, анализа, проверки и отчета о системных ресурсах;
  • обеспечение безопасности;
  • тестирование производительности, нагрузки и динамический анализ;
  • другие инструменты, в т. ч. для проверки правописания и синтаксиса, сетевой безопасности, наличия всех страниц веб-сайта и др.

Перспектива

С изменением тенденций в индустрии ПО процесс его отладки также подвержен изменениям. Существующие новые методы тестирования программных продуктов, такие как сервис-ориентированнае архитектура (SOA), беспроводные технологии, мобильные услуги и т. д., открыли новые способы проверки ПО. Некоторые из изменений, которые ожидаются в этой отрасли в течение следующих нескольких лет, перечислены ниже:

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

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

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

    Чтобы такого не происходило, мы обычно заранее, до релиза, стараемся оценивать качество тестирования: насколько хорошо и тщательно мы проверяем продукт? Каким областям не хватает внимания, где основные риски, какой прогресс? И чтобы ответить на все эти вопросы, мы оцениваем тестовое покрытие.

    Зачем оценивать?

    Любые метрики оценки – трата времени. В это время можно тестировать, заводить баги, готовить автотесты. Какую такую магическую пользу мы получаем благодаря метрикам тестового покрытия, чтобы пожертвовать временем на тестирование?

    1. Поиск своих слабых зон.
      Естественно, это нам нужно? не чтобы просто погоревать, а чтобы знать, где требуются улучшения. Какие функциональные области не покрыты тестами? Что мы не проверили? Где наибольшие риски пропуска ошибок?
    2. Редко по результатам оценки покрытия мы получаем 100%. Что улучшать? Куда идти? Какой сейчас процент? Как мы его повысим какой-либо задачей? Как быстро мы дойдём до 100? Все эти вопросы приносят прозрачности и понятности нашему процессу
      , а ответы на них даёт оценка покрытия.
    3. Фокус внимания.
      Допустим, в нашем продукте около 50 различных функциональных зон. Выходит новая версия, и мы начинаем тестировать 1-ю из них, и находим там опечатки, и съехавшие на пару пикселей кнопки, и прочую мелочь… И вот время на тестирование завершено, и эта функциональность проверена детально… А остальные 50? Оценка покрытия позволяет нам приоритезировать задачи исходя из текущих реалий и сроков.

    Как оценивать?

    Прежде, чем внедрять любую метрику, важно определиться, как вы её будете использовать. Начните с ответа именно на этот вопрос – скорее всего, вы сразу поймёте, как её лучше всего считать. А я только поделюсь в этой статье некоторыми примерами и своим опытом, как это можно сделать. Не для того, чтобы слепо копировать решения – а для того, чтобы ваша фантазия опиралась на этот опыт, продумывая идеально подходящее именно вам решение.

    Оцениваем покрытие требований тестами

    Допустим, у вас в команде есть аналитики, и они не зря тратят своё рабочее время. По результатам их работы созданы требования в RMS (Requirements Management System) – HP QC, MS TFS, IBM Doors, Jira (с доп. плагинами) и т.д. В эту систему они вносят требования, соответствующие требованиям к требованиям (простите за тавтологию). Эти требования атомарны, трассируемы, конкретны… В общем, идеальные условия для тестирования. Что мы можем сделать в таком случае? При использовании скриптового подхода – связывать требования и тесты. Ведём в той же системе тесты, делаем связку требование-тест, и в любой момент можем посмотреть отчёт, по каким требованиям тесты есть, по каким – нет, когда эти тесты были пройдены, и с каким результатом.
    Получаем карту покрытия, все непокрытые требования покрываем, все счастливы и довольны, ошибок не пропускаем…

    Ладно, давайте вернёмся с небес на землю. Скорее всего, детальных требований у вас нет, они не атомарны, часть требований вообще утеряны, а времени документировать каждый тест, ну или хотя бы каждый второй, тоже нет. Можно отчаяться и поплакать, а можно признать, что тестирование – процесс компенсаторный, и чем хуже у нас с аналитикой и разработкой на проекте, тем больше стараться должны мы сами, и компенсировать проблемы других участников процесса. Разберём проблемы по отдельности.

    Проблема: требования не атомарны.

    Аналитики тоже иногда грешат винегретом в голове, и обычно это чревато проблемами со всем проектом. Например, вы разрабатываете текстовый редактор, и у вас могут быть в системе (в числе прочих) заведены два требования: «должно поддерживаться html-форматирование» и «при открытии файла неподдерживаемого формата, должно появляться всплывающее окно с вопросом». Сколько тестов требуется для базовой проверки 1-го требования? А для 2-го? Разница в ответах, скорее всего, примерно в сто раз!!! Мы не можем сказать, что при наличии хотя бы 1-го теста по 1-му требованию, этого достаточно – а вот про 2-е, скорее всего, вполне.

    Таким образом, наличие теста на требование нам вообще ничего не гарантирует! Что значит в таком случае наша статистика покрытия? Примерно ничего! Придётся решать!

    1. Автоматический расчёт покрытия требований тестами в таком случае можно убрать – он смысловой нагрузки всё равно не несёт.
    2. По каждому требованию, начиная с наиболее приоритетных, готовим тесты. При подготовке анализируем, какие тесты потребуются этому требованию, сколько будет достаточно? Проводим полноценный тест-анализ, а не отмахиваемся «один тест есть, ну и ладно».
    3. В зависимости от используемой системы, делаем экспорт/выгрузку тестов по требованию и… проводим тестирование этих тестов! Достаточно ли их? В идеале, конечно, такое тестирование нужно проводить с аналитиком и разработчиком этой функциональности. Распечатайте тесты, заприте коллег в переговорке, и не отпускайте, пока они не скажут «да, этих тестов достаточно» (такое бывает только при письменном согласовании, когда эти слова говорятся для отписки, даже без анализа тестов. При устном обсуждении ваши коллеги выльют ушат критики, пропущенных тестов, неправильно понятых требований и т.д. – это не всегда приятно, но для тестирования очень полезно!)
    4. После доработки тестов по требованию и согласования их полноты, в системе этому требованию можно проставить статус «покрыто тестами». Эта информация будет значить значительно больше, чем «тут есть хотя бы 1 тест».

    Конечно, такой процесс согласования требует немало ресурсов и времени, особенно поначалу, до наработки практики. Поэтому проводите по нему только высокоприоритетные требования, и новые доработки. Со временем и остальные требования подтянете, и все будут счастливы! Но… а если требований нет вообще?

    Проблема: требований нет вообще.

    Они на проекте отсутствуют, обсуждаются устно, каждый делает, что хочет/может и как он понимает. Тестируем так же. Как результат, получаем огромное количество проблем не только в тестировании и разработке, но и изначально некорректной реализации фич – хотели совсем другого! Здесь я могу посоветовать вариант «определите и задокументируйте требования сами», и даже пару раз в своей практике использовала эту стратегию, но в 99% случаев таких ресурсов в команде тестирования нет – так что пойдём значительно менее ресурсоёмким путём:

    1. Создаём фичелист (feature list). Сами! В виде google-таблички, в формате PBI в TFS – выбирайте любой, лишь бы не текстовый формат. Нам ещё статусы собирать надо будет! В этот список вносим все функциональные области продукта, и постарайтесь выбрать один общий уровень декомпозиции (вы можете выписать объекты ПО, или пользовательские сценарии, или модули, или веб-страницы, или методы API, или экранные формы…) – только не всё это сразу! ОДИН формат декомпозиции, который вам проще и нагляднее всего позволит не пропустить важное.
    2. Согласовываем ПОЛНОТУ этого списка с аналитиками, разработчиками, бизнесом, внутри своей команды… Постарайтесь сделать всё, чтобы не потерять важные части продукта! Насколько глубоко проводить анализ – решать вам. В моей практике всего несколько раз были продукты, на которые мы создали более 100 страниц в таблице, и это были продукты-гиганты. Чаще всего, 30-50 строк – достижимый результат для последующей тщательной обработки. В небольшой команде без выделенных тест-аналитиков большее число элементов фичелиста будет слишком сложным в поддержке.
    3. После этого, идём по приоритетам, и обрабатываем каждую строку фичелиста как в описанном выше разделе с требованиями. Пишем тесты, обсуждаем, согласовываем достаточность. Помечаем статусы, по какой фиче тестов хватает. Получаем и статус, и прогресс, и расширение тестов за счёт общения с командой. Все счастливы!

    Но… Что делать, если требования ведутся, но не в трассируемом формате?

    Проблема: требования не трассируемы.

    На проекте есть огромное количество документации, аналитики печатают со скоростью 400 знаков в минуту, у вас есть спецификации, ТЗ, инструкции, справки (чаще всего это происходит по просьбе заказчика), и всё это выступает в роли требований, и на проекте уже все давно запутались, где какую информацию искать?
    Повторяем предыдущий раздел, помогая всей команде навести порядок!

    1. Создаём фичелист (см. выше), но без детального описания требований.
    2. По каждой фиче собираем воедино ссылки на ТЗ, спецификации, инструкции, и прочие документы.
    3. Идём по приоритетам, готовим тесты, согласовываем их полноту. Всё то же самое, только благодаря объединению всех документов в одну табличку повышаем простоту доступа к ним, прозрачные статусы и согласованность тестов. В итоге, у нас всё супер, и все счастливы!

    Но… Ненадолго… Кажется, за прошлую неделю аналитики по обращениям заказчиков обновили 4 разные спецификации!!!

    Проблема: требования всё время меняются.

    Конечно, хорошо бы тестировать некую фиксированную систему, но наши продукты обычно живые. Что-то попросил заказчик, что-то изменилось во внешнем к нашему продукту законодательстве, а где-то аналитики нашли ошибку анализа позапрошлого года… Требования живут своей жизнью! Что же делать?

    1. Допустим, у вас уже собраны ссылки на ТЗ и спецификации в виде фичелиста-таблицы, PBI, требований, заметок в Wiki и т.д. Допустим, у вас уже есть тесты на эти требования. И вот, требование меняется! Это может означать изменение в RMS, или задачу в TMS (Task Management System), или письмо в почте. В любом случае, это ведёт к одному и тому же следствию: ваши тесты неактуальны! Или могут быть неактуальны. А значит, требуют обновления (покрытие тестами старой версии продукта как-то не очень считается, да?)
    2. В фичелисте, в RMS, в TMS (Test Management System – testrails, sitechco, etc) тесты должны быть обязательно и незамедлительно помечены как неактуальные! В HP QC или MS TFS это можно делать автоматически при обновлении требований, а в google-табличке или wiki придётся проставлять ручками. Но вы должны видеть сразу: тесты неактуальны! А значит, нас ждёт полный повторный путь: обновить, провести заново тест-анализ, переписать тесты, согласовать изменения, и только после этого пометить фичу/требование снова как «покрыто тестами».

    В этом случае мы получаем все бенефиты оценки тестового покрытия, да ещё и в динамике! Все счастливы!!! Но…
    Но вы так много внимания уделяли работе с требованиями, что теперь вам не хватает времени либо на тестирование, либо на документирование тестов. На мой взгляд (и тут есть место религиозному спору!) требования важнее тестов, и уж лучше так! Хотя бы они в порядке, и вся команда в курсе, и разработчики делают именно то, что нужно. НО НА ДОКУМЕНТИРОВАНИЕ ТЕСТОВ ВРЕМЕНИ НЕ ОСТАЁТСЯ!

    Проблема: не хватает времени документировать тесты.

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

    1. Вам всё равно нужны требования, как полноценные требования или как фиче-лист, поэтому какой-то из вышеописанных разделов, в зависимости от работы аналитиков на проекте, будет всё равно необходим. Получили требования / фичелист?
    2. Описываем и устно согласовываем вкратце стратегию тестирования, без документирования конкретных тестов! Эта стратегия может быть указана в столбце таблицы, на странице вики или в требовании в RMS, и она должна быть опять же согласована. В рамках этой стратегии проверки будут проводиться по-разному, но вы будете знать: когда это последний раз тестировалось и по какой стратегии? А это уже, согласитесь, тоже неплохо! И все будут счастливы.

    Но… Какое ещё «но»? Какое???

    Говорите, все обойдём, и да пребудут с нами качественные продукты!

    Аннотация:
    Основные понятия тестирования. Фазы и этапы тестирования. Типы тестов. Разработка, управляемая тестами (Test Driven Development)

    Введение

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

    С технической точки
    зрения тестирование заключается в выполнении приложения на некотором множестве исходных данных и сверке получаемых результатов с заранее известными (эталонными) с целью установить соответствие различных свойств и характеристик приложения заказанным свойствам. Как одна из основных фаз процесса разработки программного продукта ( Дизайн
    приложения — Разработка кода — Тестирование), тестирование характеризуется достаточно большим вкладом в суммарную трудоемкость разработки продукта. Широко известна оценка распределения трудоемкости между фазами создания программного продукта: 40%-20%-40%.

    С точки зрения математики
    тестирование можно рассматривать как интерпретацию некоторой формулы и проверки ее истинности на некоторых множествах. Действительно, программу можно представить в виде формулы f = f1* f2* f3*… * fn
    , где f1
    , f 2
    , … fn
    — операторы
    языка программирования, а их суперпозиция
    — программа
    .

    Обосновать истинность такой формулы можно при помощи формального подхода — то есть выводить из исходных формул-аксиом с помощью формальных процедур (правил вывода) искомые формулы и утверждения (теоремы). Преимущество формального подхода заключается в том, что с его помощью удается избегать обращений к бесконечной области значений и на каждом шаге доказательства оперировать только конечным множеством символов. Однако зачастую построение формальной системы и формализация самой программы являются очень сложными процессами. Альтернативным подходом обоснования истинности может служить интерпретация
    .

    Интерпретационный подход применяется, когда осуществляется подстановка
    констант в формулы, а затем интерпретация
    формул как осмысленных утверждений в элементах множеств конкретных значений. Истинность интерпретируемых формул проверяется на конечных множествах возможных значений. Сложность подхода состоит в том, что часто число комбинаций значений очень велико и сами комбинации состоят из большого числа значений — а значит, обработка всех комбинаций потребует значительных ресурсов. Существуют различные методы, позволяющие уменьшить количество комбинаций, которые необходимо рассмотреть. Основная проблема тестирования
    — определение
    достаточности множества
    тестов для истинности вывода о правильности реализации программы, а также нахождения множества
    тестов, обладающих этим свойством.

    Статическое тестирование
    выявляет формальными методами анализа без выполнения тестируемой программы неверные конструкции или неверные отношения объектов программы (ошибки формального задания) с помощью специальных инструментов контроля кода — CodeChecker.

    Динамическое тестирование
    (собственно тестирование) осуществляет выявление ошибок только на выполняющейся программе с помощью специальных инструментов автоматизации тестирования
    — Testbed
    или Testbench.

    Основы тестирования

    Классы критериев тестирования

    Структурные критерии
    используют информацию о структуре программы (критерии так называемого «белого ящика»), что предполагает знание исходного текста программы или спецификации программы в виде потокового графа управления. Структурные критерии
    базируются на основных элементах графа управления — операторах, ветвях и путях.

    • Условие критерия тестирования команд (критерий С0) — набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза.
    • Условие критерия тестирования ветвей (критерий С1) — набор тестов в совокупности должен обеспечить прохождение каждой ветви не менее одного раза.
    • Условие критерия тестирования путей (критерий С2) — набор тестов в совокупности должен обеспечить прохождение каждого пути не менее 1 раз.

    Функциональные критерии
    формулируются в описании требований к программному изделию (критерии так называемого «черного ящика») Они обеспечивают, прежде всего, контроль степени выполнения требований заказчика в программном продукте. Поскольку требования формулируются к продукту в целом, они отражают взаимодействие тестируемого приложения с окружением. Проблема функционального тестирования — это прежде всего трудоемкость; дело в том, что документы, фиксирующие требования к программному изделию, как правило, достаточно объемны, тем не менее соответствующая проверка должна быть всеобъемлющей.

    Выделяют следующие частные виды функциональных критериев
    :

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

    проверки наличия заданных свойств у тестируемого приложения, средствами проверки некоторой статистической гипотезы. Применяется при тестировании сложных программных комплексов — когда набор детерминированных тестов (X, Y) имеет громадную мощность.

    Мутационные критерии
    ориентированы на проверку свойств программного изделия на основе подхода Монте-Карло.

    Метод мутационного тестирования состоит в том, что в разрабатываемую программу P вносят мутации (мелкие ошибки), т.е. искусственно создают программы- мутанты
    P1, P2… . Затем программа P и ее мутанты
    тестируются на одном и том же наборе тестов (X, Y).

    Если на наборе (X, Y) подтверждается правильность программы P и, кроме того, выявляются все внесенные в программы- мутанты
    ошибки, то набор тестов (X, Y) соответствует мутационному критерию, а тестируемая программа объявляется правильной. Если некоторые мутанты
    не выявили всех мутаций, то надо расширять набор тестов (X, Y) и продолжать тестирование.

    Фазы тестирования

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

    Модульное тестирование
    — это тестирование программы на уровне отдельно взятых модулей, функций или классов. Цель модульного тестирования состоит в выявлении локализованных в модуле ошибок в реализации алгоритмов, а также в определении степени готовности системы к переходу на следующий уровень разработки и тестирования. Модульное тестирование проводится по принципу «белого ящика», то есть основывается на знании внутренней структуры программы, и часто включает те или иные методы анализа покрытия кода.

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

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

    Системное тестирование производится над проектом в целом с помощью метода «черного ящика». Структура программы не имеет никакого значения, для проверки доступны только входы и выходы, видимые пользователю. Тестированию подлежат коды и пользовательская документация.

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

    Этапы тестирования

    Каждая фаза тестирования
    включает в себя следующие этапы:

    1. Определение целей
      (требований к тестированию), включающее следующую конкретизацию: какие части системы будут тестироваться, какие аспекты их работы будут выбраны для проверки, каково желаемое качество и т. п.
    2. Планирование
      : создание графика (расписания) разработки тестов для каждой тестируемой подсистемы; оценка необходимых человеческих, программных и аппаратных ресурсов; разработка расписания тестовых циклов
      . Важно отметить, что расписание тестирования обязательно должно быть согласовано с расписанием разработки создаваемой системы.
    3. Разработка тестов
      (тестового кода для тестируемой системы).
    4. Выполнение тестов
      : реализация тестовых циклов
      .
    5. Анализ результатов
      .

    Тестовый цикл
    — это цикл исполнения тестов, включающий фазы 4 и 5 тестового процесса. Тестовый цикл
    заключается в прогоне разработанных тестов на некотором однозначно определяемом срезе системы (состоянии кода разрабатываемой системы). Обычно такой срез системы называют build
    .

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

    Тесты разрабатывают на основе спецификаций как вручную, так и с помощью автоматизирующих средств. Помимо собственно кода, в понятие «тест» включается его общее описание и подробное описание шагов, выполняемых в данном тесте.

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

    Вся информация об обнаруженных в процессе тестирования дефектах (тип, условия обнаружения
    , причина, условия исправления, время, затраченное на исправление) заносятся в базу дефектов.

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

    Типы тестов

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

    Типы тестирования по виду подсистемы или продукта таковы:

    1. Тестирование основной функциональности, когда тестированию подвергается собственно система, являющаяся основным выпускаемым продуктом.
    2. Тестирование инсталляции включает тестирование сценариев первичной инсталляции системы, сценариев повторной инсталляции (поверх уже существующей копии), тестирование деинсталляции, тестирование инсталляции в условиях наличия ошибок в инсталлируемом пакете, в окружении или в сценарии и т. п.
    3. Тестирование пользовательской документации включает проверку полноты и понятности описания правил и особенностей использования продукта, наличие описания всех сценариев и функциональности, синтаксис и грамматику языка, работоспособность примеров и т. п.

    Типы тестирования по способу выбора входных значений:

    1. Функциональное тестирование, при котором проверяется:
      • покрытие функциональных требований;
      • покрытие сценариев использования.
    2. Стрессовое тестирование, при котором проверяются экстремальные режимы использования продукта.
    3. Тестирование граничных значений.
    4. Тестирование производительности.
    5. Тестирование на соответствие стандартам.
    6. Тестирование совместимости с другими программно-аппаратными комплексами.
    7. Тестирование работы с окружением.
    8. Тестирование работы на конкретной платформе.

    Test Driven Development

    Рассмотрим подход к тестированию, несколько отличающийся от приведенного выше. Разработка через тестирование ( Test Driven Development
    — TDD) — процесс разработки программного обеспечения, который предусматривает написание и автоматизацию модульных тестов еще до момента написания соответствующих классов или модулей. Это гарантирует, что все обязанности любого элемента программного обеспечения определяются еще до того, как они будут закодированы.

    TDD задает следующий порядок этапов программирования:

    • Красный — напишите небольшой тест, который не работает, а возможно, даже не компилируется.
    • Зеленый — заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал.
    • Рефакторинг — удалите из написанного вами кода любое дублирование.
    • Освоив TDD, разработчики обнаруживают, что они пишут значительно больше тестов, чем раньше, и двигаются вперед маленькими шагами, которые раньше могли показаться бессмысленными.

    После того, как программист заставил тест работать и может быть уверен, что эта часть функциональности покрыта, он заставляет работать второй тест, затем третий, четвертый и т. д. Чем сложнее проблема, стоящая перед программистом, тем меньшую область функциональности должен покрывать каждый тест. В итоге получается 100% покрытие кода модульными тестами, чего, как правило, невозможно добиться при классическом подходе к тестированию.

    Определенно существуют задачи, которые невозможно (по крайней мере на текущий момент) решить только при помощи тестов. В частности, TDD не позволяет механически продемонстрировать адекватность
    разработанного кода в области безопасности данных и взаимодействия между процессами. Безусловно, безопасность
    основана на коде, в котором не должно быть дефектов, однако она основана также на участии человека в процедурах защиты данных. Тонкие проблемы, возникающие в области взаимодействия между процессами, невозможно с уверенностью воспроизвести, просто запустив некоторый код.

    Итоги

    Чем активней разрабатываются новые информационные системы
    , усложняются архитектуры, развиваются новые технологии, тем важнее становится процесс тестирования. Появляется все больше сетевых приложений и приложений для мобильных устройств. Тестировать такие системы значительно сложнее, чем однопользовательские программы для домашних ПК. Для таких типов систем требуются эффективные алгоритмы автоматизации тестов. Кроме того, актуальна задача тестирования безопасности информационных систем во всех ее проявлениях. Индустрия видеоигр также нуждается в новых подходах к тестированию.

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

    Кроме того, продолжаются исследования в области тестов, ориентированных на конкретную модель разработки (водопадную, спиральную) или на конкретную парадигму программирования. Например, для тестирования компонентно-ориентированных систем предлагается тестирование при помощи агентов. Для тестирования активных Java-апплетов предлагают использовать нейросети. Для тестирования агентов, существующих в web
    (роботы, пауки), предлагают использовать системы, основанные на знаниях.

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

    Ваша цель как системного администратора
    состоит во внедрении эффективных стратегий для
    максимизации своих компьютерных ресурсов.



    Д. Гантер, С. Барнет, Л. Гантер.
    Интеграция Windows NT и Unix

    Специалистам в области IT приходится не только знакомиться с многочисленными тестированиями, публикуемыми в компьютерной прессе, но и самим разрабатывать процедуры испытаний, необходимые и при выборе поставщика, и при создании собственного решения. Поэтому попытаемся ответить на вопросы, возникающие в многотрудном процессе тестирования, особенно когда это касается таких сложных систем, как серверы
    .

    Что и зачем тестируется

    Часто в компьютерной периодике встречаются разного рода обзоры программ, аппаратных средств и решений. Особый интерес, как правило, представляют сравнительные обзоры функционально однородных продуктов, где приводятся результаты тестирования. Считается, что эти развернутые таблицы помогают пользователю, администратору и IT-профессионалу как минимум быть в курсе происходящего в данной области и даже определиться с выбором продукта.

    Итак, какие факторы учитываются в таких случаях, что является объектом исследований и какого рода испытания наиболее популярны?

    Критерии тестирования обычно таковы:

    • функциональные возможности продукта;
    • простота освоения;
    • легкость установки;
    • качество документации и поддержки;
    • производительность;
    • для аппаратуры иногда учитывается конструктивное исполнение.

    Встречаются и весьма двусмысленные критерии. Не так давно в одном из обзоров Web-серверов при выставлении общей оценки в качестве положительного фактора рассматривалась «высокая степень интеграции с операционной системой». Но если сбой приложения вызывает сбой операционной системы (вероятность чего пропорциональна степени интегрированности) — то такое ли уж это преимущество?

    Равна ли сотня кроликов одному тигру?

    Отдельно хотелось бы остановиться на соотношении цена/производительность, типичном при оценке аппаратных средств. На первый взгляд, это действительно единственный объективный критерий, связывающий технические характеристики исследуемой системы с кошельком потребителя. Однако и здесь не все так просто, как кажется. Дело в том, что вышеупомянутый подход срабатывает лишь на момент покупки и не учитывает ни цену владения, ни сохранность инвестиций в оборудование или ПО, ни возможность дальнейшей модернизации.

    Типичный пример — сравнение старших моделей систем на процессорах Intel с младшими в линии RISC-платформ. Да, действительно, в заданном ценовом диапазоне машины с Intel-архитектурой сопоставимы или, в некоторых случаях, даже превосходят RISC-системы. Однако то, что является потолком для одних платформ, — лишь начальный уровень для других и т. д.

    Выводы: относитесь критически к критериям, по которым оценивается продукт, — у вас и у тестеров могут оказаться разные вкусы. Попробуйте сказать приверженцам Unix, что ради удобства графического интерфейса конфигурирования системы стоит смириться с необходимостью перезагрузки после изменения IP-параметров. Что же касается компактности исполнения системного блока, то это хорошо до тех пор, пока вам не понадобится вставить в slim-корпус дополнительный винчестер.

    Одним словом — переосмысливайте результаты тестов в соответствии со своими нуждами.

    Специфика тестирования серверов

    Если компьютер не включается — он неисправен.
    Если не выключается — он сервер.
    Народная примета

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

    Кроме того, следует учитывать, что специализированные, т. е. обеспечивающие только один сервис, серверы пока являются скорее исключением, чем правилом. Обычно один такой компьютер совмещает ряд функций — например, сервер приложений может служить также и файл-сервером, сервером печати, контроллером службы резервного копирования и т. д. Для коммуникационных серверов типична работа с несколькими протоколами прикладного уровня, каждый из которых обслуживается собственным «демоном».

    И наконец, характерной особенностью функционирования серверов является наличие пиковых нагрузок. Причины их появления могут быть самыми разными — от начала рабочего дня в большой организации (особенно если все пользователи приходят на работу вовремя) до восстановления «упавшего» соединения у поставщика услуг Internet, когда на коммуникационные серверы обрушиваются накопившаяся почта и группы новостей.

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

    К сожалению, большинство обзоров, публикуемых в компьютерной периодике, посвящено либо сопоставлению производительности разных аппаратных решений на наборе тестовых задач, выполняемых последовательно, либо сравнительному тестированию того или иного сервиса (например, испытание Web-серверов разных производителей). Один из наихудших вариантов такого подхода — когда сравнительный обзор возможностей аналогичных решений называют тестированием только потому, что автор публикации провел инсталляцию и немного «погонял» продукт.

    Условия проведения тестирования

    Для начала немного теории. Гленфорд Майерс в своей работе «Надежность программного обеспечения» приводит несколько «аксиом тестирования». Попробуем, следуя им, рассмотреть, что и как надо тестировать.

    Время от времени в компьютерной прессе появляются сообщения почти спортивного характера: продукт фирмы N показал рекордное быстродействие в тесте M. Насколько информативны тесты, проведенные фирмами-производителями?

    Невозможно тестировать свою собственную программу

    Зачастую тесты пишутся сотрудниками фирмы под конкретный продукт. Притчей во языцех стали тесты производительности процессоров, написанные так, чтобы реализовать преимущества конкретного процессора. Например, размер тестирующей программы подбирается с учетом ее размещения в кэш-памяти и т. д. Часто достаточно тенденциозным является и графическое представление таких результатов.

    Знание особенностей архитектуры приложений и использования ими ресурсов ОС позволяет разработчикам ПО настроить систему таким образом, чтобы получить максимальные результаты для их программы. Совершенно не важно, будет ли другое ПО или сервисы чувствовать себя комфортно при таких установках операционной системы и не произойдет ли «захват ресурсов» испытуемым приложением.

    С таким явлением автор столкнулся, пытаясь настроить Netscape Enterprise Web Server под Solaris (SPARC). Производительность сервера по http-протоколу удалось поднять почти в 6 (!) раз (по данным тестирования с MS InetLoad), однако на комплексном тесте увеличение оказалось трехкратным, в то время как быстродействие POP3-сервера возросло вдвое, News-сервера — осталось неизменным, а SMTP показал в два раза худшие результаты, чем до внесения изменений.

    Кроме того, производители, зная характеристики того или иного тестового набора, могут оптимизировать параметры системы именно под него. Пример тому — Web-страничка Netscape, где приведены рекомендации, как настроить Netscape Enterprise Server для проведения тестирования с помощью SPECweb96
    .

    Тестирование проводится для обнаружения ошибок

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

    • все сервисы должны быть запущены;
    • все сервисы должны тестироваться одновременно (комплексный тест);
    • к каждому из сервисов направляется поток запросов, имитирующий типичную активность пользователей;
    • эта активность должна в процессе теста периодически возрастать до тех пор, пока по меньшей мере один сервис не перестанет справляться с обработкой запросов.

    Здесь уместны два примечания:

    1. Модель поведения пользователя.

    По отношению к пользователям администратор должен быть пессимистом. Соответственно должно строиться и тестирование «на выживание».

    Предусмотрите максимальное количество действий, совершить которые вам в нормальном состоянии просто не пришло бы в голову. Прикиньте (или проверьте), нормально ли будет функционировать система в данной ситуации. И что не менее важно, получит ли пользователь от нее вразумительное сообщение о том, что так делать больше не стоит и почему.

    2. Сервис перестал справляться с обработкой запросов: возможные варианты.

    По степени серьезности такие отказы можно разделить на 4 группы:

    • снижение производительности — сервис не успевает провести обработку, но отвечает корректно (возвращает соответствующий код ошибки — «Too many connections» и т. п.);
    • аварийное завершение работы сервиса, не влекущее за собой негативных последствий для системы: соответствующая программа завершила работу, выгружена из памяти, системные ресурсы освобождены;
    • аварийное завершение работы сервиса, отрицательно влияющее на производительность системы. Программа либо «висит» в списке процессов, не высвобождая ресурсы, либо в процессе завершения захватывает дополнительные ресурсы;
    • крах системы — в лучшем случае с последующей перезагрузкой, в худшем — с зависанием.

    Готовьте тесты как для правильных, так и для неправильных входных данных

    Эта аксиома детализирует предыдущую с точки зрения входных информационных потоков.

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

    Совет, взятый из той же книги Г. Майерса: «старайтесь, чтобы система не рассердила пользователя, ибо это может привести к некоторым неожиданным ситуациям на входе — правило # 5 минимизации ошибок пользователя в диалоговых системах. Быть пессимистом — не значит быть мизантропом!».

    А как насчет news-сервера — установлен ли там максимальный размер статьи?

    Может ли кто-то, вознамерившись загрузить половину вашего FTP-сайта, открыть три десятка параллельных ftp-сессий, и если да, то как это повлияет на ваш канал и работу других желающих посетить FTP?

    В качестве примера, подтверждающего корректность такого подхода, можно упомянуть инцидент с ракетным крейсером Yorktown, где ошибка ввода оператора повлекла за собой отказ системы управления двигателями
    . Или еще один, приведенный самим Майерсом: «Операторы Нью-Йоркской системы диспетчеризации полицейских машин SPRINT в свободное время развлекались тем, что пытались вывести ее из строя, вводя заведомо неправильные сообщения». Это происходило в начале 70-х. Может, с тех пор нравы и смягчились, но это маловероятно.

    Избегайте невоспроизводимых тестов

    В случае тестирования серверов и серверного ПО эта аксиома особенно актуальна. Во-первых, для их тестирования необходимо наличие аппаратно разделенных генераторов нагрузки (Client-Side Load Generators, CSLG) — обычно это группы рабочих станций, выполняющих клиентскую часть теста и обеспечивающих поток запросов на сервер. Во-вторых, на результаты может повлиять состояние сети, соединяющей сервер и CSLG. Кроме того, во многих случаях производительность зависит от предыстории обращений к серверу. Большинство серверных приложений использует кэширование. Скорость обращения к кэш-памяти значительно выше скорости обращения к дисковой подсистеме. Кэш приложения может наполняться вследствие предварительных или отладочных прогонов тест-программ — и соответственно могут меняться результаты. Более того, при комплексном тестировании возможно перекрестное влияние приложений — так, количество обработанных за единицу времени сложных запросов к POP3- или IMAP-серверам зависит от размера почтового спула, который может быть увеличен предыдущим проведением SMTP-теста. И наконец, на производительность влияют настройки операционной системы.

    Во всех приличных обзорах есть раздел «Как проводились испытания». В одних публикациях он более подробен, в других менее — стандарта на описание и протоколирование тестирования, кажется, до сих пор не существует. Прекрасным образцом тому может служить тест SPECweb96
    . В этом документе учтена специфика тестирования именно серверного приложения. В отличие от традиционных описаний там есть требования к протоколированию дополнительных настроек операционной системы и исследуемого приложения — то, что обычно лишь вскользь упоминается даже в лучших образцах описаний тестирования.

    Возможно, вы сами придете к осознанию необходимости провести собственное испытание. Такая потребность может возникнуть в следующих случаях:

    • вы планируете расширить вашу сеть, что приведет к повышению нагрузки на размещенные в ней серверы;
    • вы намереваетесь обновить (или сменить) программное обеспечение;
    • вы решили сменить ваш сервер (или серверы) на более производительные;
    • наконец, может быть, вы просто решили выяснить «пределы роста» вашей системы.

    Вашим первым шагом, вероятно, станет изучение опубликованных обзоров. Поэтому для того, чтобы воспользоваться полученными кем-то другим данными, относитесь к ним критически и попытайтесь понять в том числе мотивацию людей, выполнявших это тестирование. А далее все зависит от вас — осознание цели, выбор или написание адекватного набора тестов и корректное проведение самого тестирования. Надеюсь, что изложенные в настоящей статье соображения помогут вам в этом.

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

    Цель

    Целью тестирования является оценка качества продукта. Под этим подразумевается не только оценка окончательного продукта, но и оценка архитектуры с ранних этапов процесса и вплоть до окончательной передачи продукта раказчикам. включает следующее.

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

    Проверку правильности интеграции компонентов

    Проверку точности реализации всех требований

    Выявление дефектов и принятие мер, необходимых для их устранения до
    развертывания программного обеспечения

    Качество

    Стандартное употребление термина качество
    включает в себя многое: как правило, этим словом обозначают отсутствие дефектов и (что гораздо важнее!) соответствие поставленной цели; с понятием качества мы связываем то, что нам нужно от продукта. В продукте (или его компоненте) могут отсутствовать дефекты, но если он не делает то, что необходимо нам, то он так же бесполезен, как и несовершенный продукт. Основной целью тестирования является оценка качества конечного продукта, а также оценка качества компонентов, составляющих его, и архитектуры, определяющей форму этих компонентов. Это нужно для того, чтобы убедиться, что продукт со-

    Глава 12. Г67

    ответствует определенным требованиям или превышает их (оценка производится согласно мерам и критериям приемлемости).

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

    Кто отвечает за качество продукта

    За производство качественного продукта отвечают все члены проектной команды. Если качество не было изначально заложено в продукт, то его уже нельзя будет «добавить позднее» посредством выполнения некоторых активных действий, гарантирующих качество.

    Задача тестирования — не гарантировать
    качество, а оценить
    его, одновременно обеспечивая обратную связь, позволяющую разрешить вопросы качества за разумную цену и в приемлемое время. Задача испытателя, выполняющего тестирование, — это оценивать качество и организовывать обратную связь, а задача проектной команды — создавать артефакты, удовлетворяющие требованиям и заданным параметрам качества.

    Тестирование в итеративном жизненном цикле

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

    Классификация тестов

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

    Тестируемый параметр качества —
    какой параметр качества проходит испытания

    Этап тестирования-
    момент жизненного цикла, в котором выполняется
    тестирование

    Тип теста
    — конкретная задача отдельного теста, как правило, связанная с одним
    параметром качества

    Параметры качества

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

    Надежность

    Программное обеспечение «сопротивляется» появлению ошибок в процессе выполнения: отсутствуют аварийные отказы, зависания, утечка памяти и т. п.

    Функциональные возможности

    Программное обеспечение реализует требуемые прецеденты или имеет ожидаемое поведение.

    Я Производительность

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

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

    Этапы тестирования

    Тестирование не следует считать обособленным видом деятельности, выполняемым целиком и сразу. Тестирование производится на разных этапах разработки программного обеспечения и направлено на проверку различных объектов (целевых объектов тестирования). Этапы тестирования прогрессируют — от тестирования небольших элементов системы, таких как компоненты (блочное тестирование), до тес- . тирования завершенных систем (системное тестирование). Перечислим существующие этапы тестирования и их задачи.

    Блочное тестирование

    Тестируются минимальные элементы системы. Время тестирования, как правило, совпадает со временем реализации элементов.

    Интегральное тестирование

    Тестируются интегральные блоки (или компоненты, или подсистемы).

    Системное тестирование

    Тестируются завершенные приложения и системы (состоящие из одного или нескольких приложений).

    Приемочное тестирование

    Конечными пользователями (или представителями конечных пользователей) тестируется завершенное приложение (или система). Цель тестирования: определить готовность к развертыванию продукта.

    Следует помнить, что в разное время жизненного цикла этапы тестирования проходят с различными акцентами. Ранний концептуальный прототип, используемый в фазе исследования для оценки жизнеспособности видения продукта, будет подвергаться различным приемочным испытаниям. Архитектурный прототип, разрабатываемый в фазе уточнения плана, будет подвержен интегральным и системным испытаниям, направленным на проверку архитектурной целостности и производительности ключевых архитектурных элементов, несмотря на то что в это время большая часть кода системы имеет форму программ-суррогатов. Этапы тестирования — это не предопределенные «фазы», последовательно выполняемые ближе к концу
    проекта; наоборот, при итеративном жизненном цикле тестирование начинается рано и выполняется часто.

    Типы тестов

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

    Аттестационный тест

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

    Конфигурационный тест

    Проверяет приемлемость функционирования целевого объекта тестирования при различных конфигурациях (программных или аппаратных).

    Функциональные испытания

    Проверяется функционирование целевого объекта тестирования в общем, т.е. должная реализация требуемых прецедентов.

    Установочные испытания

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

    Тестирование целостности

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

    Испытание под нагрузкой

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

    Эксплуатационные испытания

    Проверяется приемлемость производительности целевого объекта тестирования в различных конфигурациях при постоянных операционных характеристиках.

    Испытания в жестком режиме

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

    Регрессивное тестирование

    Регрессивное тестирование — это методика испытаний, при которой тесты, производимые ранее, повторно выполняются на новой версии целевого объекта. Цель такого типа тестирования — обеспечить, чтобы качество целевого объекта не ухудшалось (не регрессировало) при добавлении к этому объекту новых функций. Регрессивное тестирование необходимо для

    Максимально раннего выявления дефектов;

    Проверки того, что изменения кода не приводят к новым дефектам или не
    восстанавливают старые.

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

    Модель тестирования

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

    Рассмотрим подробнее составляющие модели тестирования.

    Контрольные задачи

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

    Методики испытания

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

    Сценарии испытаний

    Инструкции, автоматизирующие реализацию части или всей методики испытания (или методик испытания).

    Классы и компоненты испытаний

    Классы и компоненты, реализующие проекты тестов, в том числе драйверы и программы-суррогаты.

    Взаимодействия тестов

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

    Примечания

    Текстовая информация, описывающая ограничения, или дополнительная информация, используемая в модели тестирования. Примечания могут присоединяться к любому элементу модели тестирования.

    Основные элементы модели тестирования и их взаимоотношения показаны на рис. 12.1.

    Рис. 12.1. Контрольные задачи, методики испытаний и сценарии испытаний для банкомата

    Исполнители и артефакты

    В технологическом процессе тестирования задействованы два основных исполнителя.

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

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

    Если для поддержки тестирования необходим специфический код (например, должны разрабатываться драйверы или программы-суррогаты), то в процессе должны участвовать еще разработчик и конструктор, исполняющие роли, подобные определенным в главах 10 и 11.

    Исполнители и артефакты технологического процесса тестирования представлены на рис. 12.2. Давайте рассмотрим ключевые артефакты этого процесса.

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

    Модель тестирования
    описывалась ранее.

    Результаты тестирования
    и данные, собранные в процессе выполнения тестов.

    Модель рабочей нагрузки
    для эксплуатационных испытаний; она определяет
    переменные и их значения, используемые в различных эксплуатационных
    испытаниях для моделирования или имитации характеристик внешних
    исполнителей, функций, выполняемых конечными пользователями, объема
    этих функций и нагрузки, создаваемой этими функциями.

    Дефекты,
    полученные в результате «проваленных тестов» являются одним из
    типов запросов на внесение изменений (см. главу 13).

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

    Пакеты и классы тестов

    Подсистемы и компоненты тестов

    Заключительная оценка тестов используется как часть оценки итерации проекта и периодической оценки состояния (см. главу 7, «Технологический процесс управления проектом»).

    Технологический процесс

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

    Подготовка к тестированию

    Целью этого элемента технологического процесса является определение и описание тестирования, которое будет выполняться. Для этого создается план тестирования, содержащий требования к тесту и стратегиям тестирования. Может разрабатываться единый план тестирования, в котором описаны все типы выполняемых тестов, или для каждого типа теста может создаваться отдельный план. Подготовка к тестированию выполняется таким образом, чтобы работы по тестированию были измеримыми и управляемыми.

    Разработка теста

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

    Реализация теста

    Цель этого элемента технологического процесса состоит в реализации методик испытания, определенных в разделе Подготовка к тестированию.
    Создание методик испытания производится, как правило, в среде средств автоматизации тестов или в среде программирования. Результирующим артефактом является электронная версия методики испытания, называемая сценарием испытания.

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

    Выполнение тестов на этапе интегрального тестирования

    Цель этого элемента технологического процесса — обеспечение корректного объединения системных компонентов, а также проверка наличия у этого объединения правильного поведения. За компиляцию и объединение системы в увеличивающиеся функциональные блоки отвечает системный интегратор. Для каждого такого блока тестируются добавленные функции, выполняются регрессивные тесты и извлекаются результаты тестирования.

    В ходе одной итерации интегральное тестирование выполняется несколько раз, пока не будет успешно интегрирована вся система (определяется целью итерации).

    Выполнение тестов на этапе системного тестирования

    Целью данного элемента технологического процесса является обеспечение должного функционирования всей системы. Системный интегратор компилирует и объединяет системы в увеличивающиеся функциональные блоки. Каждый добавляемый элемент

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

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

    Оценка тестирования

    Цель данного элемента технологического процесса — выработка и оценка количественных мер тестирования, позволяющих определить качество целевого объекта теста и процесса тестирования. Это выполняется посредством рецензирования и оценки результатов тестирования, определения и регистрации запросов на внесение изменений, а также вычисления основных мер теста.

    Инструментальная поддержка

    Поскольку тестирование — это итеративная работа, выполняемая в течение всего цикла разработки, инструментальная поддержка необходима для того, чтобы тестирование начать рано и выполнять часто; ручное тестирование недостаточно эффективно и не позволяет тщательно оценить разрабатываемое программное обеспечение. Последнее утверждение особенно справедливо для эксплуатационных испытаний и испытаний под нагрузкой, в которых должна моделироваться рабочая нагрузка и должен накапливаться значительный объем данных.

    Корпорация Rational Software предлагает следующие инструментальные средства, поддерживающие автоматизацию тестов и процесс тестирования в целом.

    TestStudio — это набор инструментальных средств, поддерживающих выполне
    ние тестов и оценку результатов тестирования. Средства TestStudio позволяй
    испытателю создавать сценарии тестирования, имеющие графический интер
    фейс пользователя. Эти сценарии акцентируют внимание на таких параметра
    качества, как надежность, функционирование и производительность. В набор
    TestStudio входят следующие инструменты.

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

    LogViewer фиксирует результаты тестирования и представляет отчет для оценки выполнения теста.

    TestManager поддерживает планирование, проектирование и оценку тестов, позволяет определить тестовое покрытие и генерирует отчеты о состоянии тестов.

    TestFactory поддерживает тестирование надежности путем автоматического создания и выполнения сценариев тестирования. Кроме того, этот инструмент в программной форме сообщает о тестовом покрытии.

    PerformanceStudio выполняет сценарии тестирования виртуального пользова
    теля, используя для этого эксплуатационные испытания и некоторые функци
    ональные испытания.

    DevelopmentStudio поддерживает технологический процесс тестирования и
    включает следующие инструментальные средства.

    Rational Purify для локализации труднообнаруживаемых ошибок времени выполнения.

    Rational PureCoverage* для определения участков кода, не прошедших тестирование, и выполнения анализа покрытия кода.

    Rational Quantify* для выявления фрагментов кода, ограничивающих производительность.

    Кроме того, для большинства из названных средств Rational Unified Process предлагает инструментальные наставники.

    Резюме

    Тестирование позволяет оценить качество производимого продукта.

    Тестирование — это итеративный процесс, выполняемый во всех фазах жизнен
    ного цикла; он позволяет рано организовать обратную
    связь по вопросам качест
    ва, используемую для улучшения продукта в процессе его разработки и построе
    ния. Тестирование должно выполняться не только в конце жизненного цикла
    (для принятия или отклонения конечного продукта); оно должно быть неотъем
    лемой частью механизма постоянной обратной связи.

    За качество отвечают все. Качество не может вноситься тестирующей органи
    зацией. Тестирование направлено только на оценку качества и организацию
    своевременной обратной связи, позволяющей повысить качество системы.

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