73

4 Классификация видов тестирования

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

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

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

Тестирование ПО можно классифицировать по следующим признакам

(рис. 4.1):

1)по знанию системы;

2)по позитивности;

3)по целям (объекту);

4)по исполнителям (субъекту);

5)по времени проведения (тестирование изменений);

6)по степени автоматизации;

7)по состоянию (по исполнению кода).

75

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

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

Согласно ISTQB, тест-дизайн, основанный на технике чер-

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

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

Целью этой техники является поиск ошибок в следующих категориях:

неправильно реализованные или недостающие функции;

ошибки интерфейса;

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

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

Преимущества:

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

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

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

можно начинать писать тест-кейсы, как только готова спецификация.

Недостатки:

тестируется только очень ограниченное количество путей выполнения программы;

без четкой спецификации (а это скорее реальность на многих проектах) достаточно трудно составить эффективные тест-кейсы;

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

76

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

Тестирование белого ящика (white box testing, open box testing,

clear box testing, glass box testing) – у тестировщика есть доступ к внутренней структуре и коду приложения, а также есть достаточно знаний для понимания увиденного.

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

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

Техники, основанные на структуре, или белого ящика:

тестирование операторов;

тестирование альтернатив.

Преимущества:

показывает скрытые проблемы и упрощает их диагностику;

допускает достаточно простую автоматизацию тест-кейсов и их выполнение на самых ранних стадиях развития проекта;

мотивирует разработчиков к написанию качественного (чистого) кода.

Недостатки:

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

поведение ПО исследуется в отрыве от реальной среды выполнения и не учитывает ее влияние.

Написать автотесты – это еще полдела, необходимо проверить, а весь ли код покрыт тестами. Автоматические тесты должны покрывать 100% функционала, нужно стремиться к тому, чтобы каждая строчка кода была исполнена в результате исполнения хотя бы одного теста. Данная характеристика называется code coverage и буквально означает степень покрытия кода тестами.

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

Покрытие кода (code coverage) – метод анализа, определяю-

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

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·