Материал: Обеспечения Базовый курс (3е издание) Версия книги 2 от 17. 04. 2023

Подробная классификация тестирования
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 73/301
2.3.2.2.
Классификация по запуску кода на исполнение
Далеко не всякое тестирование предполагает взаимодействие с работаю- щим приложением. Потому в рамках данной классификации выделяют:
• Статическое тестирование (static testing
117
)
— тестирование без запуска кода на исполнение. В рамках этого подхода тестированию могут подвер- гаться: o
Документы (требования, тест-кейсы, описания архитектуры приложе- ния, схемы баз данных и т.д.). o
Графические прототипы (например, эскизы пользовательского интер- фейса). o
Код приложения (что часто выполняется самими программистами в рамках аудита кода (code review
118
)
, являющегося специфической ва- риацией взаимного просмотра
{51}
в применении к исходному коду). Код приложения также можно проверять с использованием техник тести- рования на основе структур кода
{97}
o
Параметры (настройки) среды исполнения приложения. o
Подготовленные тестовые данные.
• Динамическое тестирование (dynamic testing
119
)
— тестирование с запуском кода на исполнение. Запускаться на исполнение может как код всего прило- жения целиком (системное тестирование
{78}
), так и код нескольких взаимосвя- занных частей (интеграционное тестирование
{77}
), отдельных частей (модуль- ное или компонентное тестирование
{77}
) и даже отдельные участки кода. Ос- новная идея этого вида тестирования состоит в том, что проверяется реаль- ное поведение (части) приложения.
2.3.2.3.
Классификация по доступу к коду и архитектуре приложения
• Метод белого ящика (white box testing
120
, open box testing, clear box testing, glass box testing)
— у тестировщика есть доступ к внутренней структуре и коду приложения, а также есть достаточно знаний для понимания увиденного. Вы- деляют даже сопутствующую тестированию по методу белого ящика гло- бальную технику — тестирование на основе дизайна (design-based testing
121
).
Для более глубокого изучения сути метода белого ящика рекомендуется ознакомиться с техниками исследования потока управления
{96}
или потока данных
{96}
, использования диаграмм состояний
{97}
Некоторые авторы склонны жёстко связывать этот метод со статическим тестированием, но ничто не ме- шает тестировщику запустить код на выполнение и при этом периодически обращаться к самому коду (а модульное тестирование
{77}
и вовсе предпола- гает запуск кода на исполнение и при этом работу именно с кодом, а не с
«приложением целиком»).
117
Static testing. Testing of a software development artifact, e.g., requirements, design or code, without execution of these artifacts, e.g., reviews or static analysis. [ISTQB Glossary]
118
Jason Cohen,
«Best Kept Secrets of Peer Code Review (Modern Approach. Practical Advice.)». Официально распространяе- мую электронную версию книги можно взять здесь: https://static1.smartbear.co/smartbear/media/pdfs/best-kept-secrets-of- peer-code-review_redirected.pdf
119
Dynamic testing. Testing that involves the execution of the software of a component or system. [ISTQB Glossary]
120
White box testing. Testing based on an analysis of the internal structure of the component or system. [ISTQB Glossary]
121
Design-based Testing. An approach to testing in which test cases are designed based on the architecture and/or detailed design of a component or system (e.g. tests of interfaces between components or systems). [ISTQB Glossary]

Подробная классификация тестирования
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 74/301
• Метод чёрного ящика (black box testing
122
, closed box testing, specification- based testing)
— у тестировщика либо нет доступа к внутренней структуре и коду приложения, либо недостаточно знаний для их понимания, либо он со- знательно не обращается к ним в процессе тестирования. При этом абсолют- ное большинство перечисленных на рисунках 2.3.b и 2.3.c видов тестирова- ния работают по методу чёрного ящика, идею которого в альтернативном определении можно сформулировать так: тестировщик оказывает на прило- жение воздействия (и проверяет реакцию) тем же способом, каким при ре- альной эксплуатации приложения на него воздействовали бы пользователи или другие приложения. В рамках тестирования по методу чёрного ящика ос- новной информацией для создания тест-кейсов выступает документация
(особенно — требования (requirements-based testing
123
)) и общий здравый смысл (для случаев, когда поведение приложения в некоторой ситуации не регламентировано явно; иногда это называют «тестированием на основе не- явных требований», но канонического определения у этого подхода нет).
• Метод серого ящика (gray box testing
124
)
— комбинация методов белого ящика и чёрного ящика, состоящая в том, что к части кода и архитектуры у тестировщика доступ есть, а к части — нет. На рисунках 2.3.b и 2.3.c этот метод обозначен особым пунктиром и серым цветом потому, что его явное упоминание — крайне редкий случай: обычно говорят о методах белого или чёрного ящика в применении к тем или иным частям приложения, при этом понимая, что «приложение целиком» тестируется по методу серого ящика.
Важно! Некоторые авторы
125
определяют метод серого ящика как противопоставление методам белого и чёрного ящика, особо под- чёркивая, что при работе по методу серого ящика внутренняя струк- тура тестируемого объекта известна частично и выясняется по мере исследования. Этот подход, бесспорно, имеет право на существо- вание, но в своём предельном случае он вырождается до состояния
«часть системы мы знаем, часть — не знаем», т.е. до всё той же комбинации белого и чёрного ящиков.
Если сравнить основные преимущества и недостатки перечисленных мето- дов, получается следующая картина (см. таблицу 2.3.a).
Методы белого и чёрного ящика не являются конкурирующими или взаимо- исключающими — напротив, они гармонично дополняют друг друга, компенсируя таким образом имеющиеся недостатки.
122
Black box testing. Testing, either functional or non-functional, without reference to the internal structure of the component or system. [ISTQB Glossary]
123
Requirements-based Testing. An approach to testing in which test cases are designed based on test objectives and test condi- tions derived from requirements, e.g. tests that exercise specific functions or probe non-functional attributes such as reliability or usability. [ISTQB Glossary]
124
Gray box testing is a software testing method, which is a combination of Black Box Testing method and White Box Testing method. … In Gray Box Testing, the internal structure is partially known. This involves having access to internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level. [
«Gray Box Testing Funda- mentals
», http://softwaretestingfundamentals.com/gray-box-testing
].
125
«Gray box testing (gray box) definition», Margaret Rouse [
http://searchsoftwarequality.techtarget.com/definition/gray-box
]

Подробная классификация тестирования
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 75/301
Таблица 2.3.a — Преимущества и недостатки методов белого, чёрного и серого ящиков
Преимущества
Недостатки
Метод белого
ящика
• Показывает скрытые проблемы и упрощает их диагностику.
• Допускает достаточно простую ав- томатизацию тест-кейсов и их вы- полнение на самых ранних ста- диях развития проекта.
• Обладает развитой системой мет- рик, сбор и анализ которых легко автоматизируется.
• Стимулирует разработчиков к написанию качественного кода.
• Многие техники этого метода яв- ляются проверенными, хорошо себя зарекомендовавшими реше- ниями, базирующимися на строгом техническом подходе.
• Не может выполняться тестиров- щиками, не обладающими доста- точными знаниями в области про- граммирования.
• Тестирование сфокусировано на реализованной функционально- сти, что повышает вероятность пропуска нереализованных требо- ваний.
• Поведение приложения исследу- ется в отрыве от реальной среды выполнения и не учитывает её влияние.
• Поведение приложения исследу- ется в отрыве от реальных поль- зовательских сценариев
{146}
Метод чёрного
ящика
• Тестировщик не обязан обладать
(глубокими) знаниями в области программирования.
• Поведение приложения исследу- ется в контексте реальной среды выполнения и учитывает её влия- ние.
• Поведение приложения исследу- ется в контексте реальных пользо- вательских сценариев
{146}
• Тест-кейсы можно создавать уже на стадии появления стабильных требований.
• Процесс создания тест-кейсов поз- воляет выявить дефекты в требо- ваниях.
• Допускает создание тест-кейсов, которые можно многократно ис- пользовать на разных проектах.
• Возможно повторение части тест- кейсов, уже выполненных разра- ботчиками.
• Высока вероятность того, что часть возможных вариантов пове- дения приложения останется не- протестированной.
• Для разработки высокоэффектив- ных тест-кейсов необходима каче- ственная документация.
• Диагностика обнаруженных де- фектов более сложна в сравнении с техниками метода белого ящика.
• В связи с широким выбором тех- ник и подходов затрудняется пла- нирование и оценка трудозатрат.
• В случае автоматизации могут по- требоваться сложные дорогостоя- щие инструментальные средства.
Метод серого
ящика
Сочетает преимущества и недостатки методов белого и чёрного ящика.
2.3.2.4.
Классификация по степени автоматизации
• Ручное тестирование (manual testing
126
)
— тестирование, в котором тест- кейсы выполняются человеком вручную без использования средств автома- тизации. Несмотря на то что это звучит очень просто, от тестировщика в те или иные моменты времени требуются такие качества, как терпеливость, наблюдательность, креативность, умение ставить нестандартные экспери- менты, а также умение видеть и понимать, что происходит «внутри системы», т.е. как внешние воздействия на приложение трансформируются в его внут- ренние процессы.
126
Manual testing is performed by the tester who carries out all the actions on the tested application manually, step by step and indicates whether a particular step was accomplished successfully or whether it failed. Manual testing is always a part of any testing effort. It is especially useful in the initial phase of software development, when the software and its user interface are not stable enough, and beginning the automation does not make sense. (SmartBear TestComplete user manual, https://sup- port.smartbear.com/testcomplete/docs/testing-with/deprecated/manual/index.html
)

Подробная классификация тестирования
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 76/301
• Автоматизированное тестирование (automated testing, test automation
127
)
— набор техник, подходов и инструментальных средств, позволяющий исклю- чить человека из выполнения некоторых задач в процессе тестирования.
Тест-кейсы частично или полностью выполняет специальное инструменталь- ное средство, однако разработка тест-кейсов, подготовка данных, оценка ре- зультатов выполнения, написания отчётов об обнаруженных дефектах — всё это и многое другое по-прежнему делает человек.
Некоторые авторы
113
говорят отдельно о «полуавтоматизирован- ном» тестировании как варианте ручного с частичным использова- нием средств автоматизации и отдельно об «автоматизированном» тестировании (относя туда области тестирования, в которых компь- ютер выполняет ощутимо большой процент задач). Но т.к. без уча- стия человека всё равно не обходится ни один из этих видов тести- рования, не станем усложнять набор терминов и ограничимся одним понятием «автоматизированное тестирование».
У автоматизированного тестирования есть много как сильных, так и слабых сторон (см. таблицу 2.3.b).
Таблица 2.3.b — Преимущества и недостатки автоматизированного тестирования
Преимущества
Недостатки
• Скорость выполнения тест-кейсов может в разы и на порядки превосходить возможно- сти человека.
• Отсутствие влияния человеческого фактора в процессе выполнения тест-кейсов (устало- сти, невнимательности и т.д.).
• Минимизация затрат при многократном вы- полнении тест-кейсов (участие человека здесь требуется лишь эпизодически).
• Способность средств автоматизации выпол- нить тест-кейсы, в принципе непосильные для человека в силу своей сложности, скоро- сти или иных факторов.
• Способность средств автоматизации соби- рать, сохранять, анализировать, агрегиро- вать и представлять в удобной для восприя- тия человеком форме колоссальные объёмы данных.
• Способность средств автоматизации выпол- нять низкоуровневые действия с приложе- нием, операционной системой, каналами пе- редачи данных и т.д.
• Необходим высококвалифицированный пер- сонал в силу того факта, что автоматизация
— это «проект внутри проекта» (со своими требованиями, планами, кодом и т.д.)
• Высокие затраты на сложные средства авто- матизации, разработку и сопровождение кода тест-кейсов.
• Автоматизация требует более тщательного планирования и управления рисками, т.к. в противном случае проекту может быть нане- сён серьёзный ущерб.
• Средств автоматизации крайне много, что усложняет проблему выбора того или иного средства и может повлечь за собой финансо- вые затраты (и риски), необходимость обуче- ния персонала (или поиска специалистов).
• В случае ощутимого изменения требований, смены технологического домена, перера- ботки интерфейсов (как пользовательских, так и программных) многие тест-кейсы стано- вятся безнадёжно устаревшими и требуют создания заново.
Если же выразить все преимущества и недостатки автоматизации тестиро- вания одной фразой, то получается, что автоматизация позволяет ощутимо увели- чить тестовое покрытие (test coverage
128
), но при этом столь же ощутимо увеличи- вает риски.
127
Test automation is the use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions. Commonly, test automation involves automating a manual process already in place that uses a f ormalized testing process. (Ravinder Veer Hooda, “An Automation of
Software Testing: A Foundation for the Future”)
128