Лекция 7: Тестирование

Cтандартизация качеств:

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

Методы обеспечения качества ПО:

Различные способы контроля качества, используемые на практике при разработке ПО:

- Наладка качественного процесса, другими словами совершенствование процесса. Для комплексного улучшения процессов в компании (подход technologypush) компаниями-разработчиками ПО используются стандарты CMM/CMMI).

Применяются и локальные стратегии, менее дорогостоящие и более направленные на решение отдельных проблем (подход organizationpull).

- Формальные методы – использование математических формализмов для доказательства корректности, спецификации, проверки формального соответствия, автоматической генерации и т.д.:

o доказательство правильности работы программ,

o проверка на моделях определенных свойств (modelcheking),

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

o модельно-ориентированное тестирование (model-basedtesting): автоматическая генерация тестов и тестового окружения по формальным спецификациям требований к системе) и т.д.

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

- Исследование и анализ динамических свойствПО.

- Обеспечение качества кода. Сюда относится целый комплекс различных мероприятий и методов:

o Разработка стандартов оформления кода в проекте и контроль за соблюдением этих стандартов. Сюда входят правила на создание идентификаторов переменных, методов и имен классов, на оформление комментариев, правила использования стандартных для проекта библиотек и т.д.

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

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

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

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

- Тестирование. Самый распространенный способ контроля качестваПО, представленный, фактически, в каждом программном проекте.

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

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

Ожидаемое поведение программы.

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

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

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

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

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

Специально заданные, искусственные условия, – те условия, где осуществляется тестирование.

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

Тесты могут быть "ручными" и автоматизированными.

"Ручной" тест – это последовательность действий тестировщика, которую он (или разработчик) может воспроизвести и ошибка произойдет. Как правило, в средствах контроля ошибками такие последовательности действий содержатся в описании ошибки.

Автоматический тест – это некоторая программа, которая воздействует на систему и проверяет то или иное ее свойство.

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

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

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

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

- обеспечение доступа теста к системе через некоторый ее интерфейс.

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

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

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

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

1. Модульное тестирование - тестируется отдельный модуль, в отрыве от остальной системы.

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

2. Интеграционное тестирование – два и более компонентов тестируются на совместимость.

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

3. Системное тестирование – это тестирование всей системы в целом, как правило, через ее пользовательский интерфейс.

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

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

5. Нагрузочное тестирование – тестирование системы на корректную работу с большими объемами данных.

6. Стрессовое тестирование – тестирование системы на устойчивость к непредвиденным ситуациям. Этот вид тестирования нужен далеко не для каждой системы, так как подразумевает высокую планку качества.

7. Приемочное тестирование – тестирование, выполняемое при приемке системы заказчиков.

Работа с ошибками

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