Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Тестирование на основе ветвей (branch testing 248 ) — техника тести- рования (по методу белого ящика), в которой проверяется выполнение отдельных ветвей кода (под ветвью понимается атомарная часть кода, выполнение которой происходит или не происходит в зависимости от истинности или ложности некоторого условия). 241 State Transition Testing. A black box test design technique in which test cases are designed to execute valid and invalid state transitions. [ISTQB Glossary] 242 State Diagram. A diagram that depicts the states that a component or system can assume, and shows the events or circumstances that cause and/or result from a change from one state to another. [ISTQB Glossary] 243 State Table. A grid showing the resulting transitions for each state combined with each possible event, showing both valid and invalid transitions. [ISTQB Glossary] 244 «What is State transition testing in software testing?» [ http://istqbexamcertification.com/what-is-state-transition-testing-in-soft- ware-testing/ ] 245 Finite State Machine. A computational model consisting of a finite number of states and transitions between those states, possibly with accompanying actions. [ISTQB Glossary] 246 Inspection. A type of peer review that relies on visual examination of documents to detect defects, e.g. violations of development standards and non-conformance to higher level documentation. The most formal review technique and therefore always based on a documented procedure. [ISTQB Glossary] 247 Statement Testing. A white box test design technique in which test cases are designed to execute statements (statement is an entity in a programming language, which is typically the smallest indivisible unit of execution). [ISTQB Glossary] 248 Branch Testing. A white box test design technique in which test cases are designed to execute branches (branch is a basic block that can be selected for execution based on a program construct in which one of two or more alternative program paths is available, e.g. case, jump, go to, if-then-else.). [ISTQB Glossary] Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 95/298 o Тестирование на основе условий (condition testing 249 ) — техника те- стирования (по методу белого ящика), в которой проверяется выпол- нение отдельных условий (условием считается выражение, которое может быть вычислено до значения «истина» или «ложь»). o Тестирование на основе комбинаций условий (multiple condition testing 250 ) — техника тестирования (по методу белого ящика), в которой проверяется выполнение сложных (составных) условий. o Тестирование на основе отдельных условий, порождающих ветв- ление («решающих условий») (modified condition decision coverage testing 251 ) — техника тестирования (по методу белого ящика), в которой проверяется выполнение таких отдельных условий в составе сложных условий, которые в одиночку определяют результат вычисления всего сложного условия. o Тестирование на основе решений (decision testing 252 ) — техника те- стирования (по методу белого ящика), в которой проверяется выпол- нение сложных ветвлений (с двумя и более возможными вариантами). Несмотря на то что «два варианта» сюда также подходит, формально такую ситуацию стоит отнести к тестированию на основе условий. o Тестирование на основе путей (path testing 253 ) — техника тестирова- ния (по методу белого ящика), в которой проверяется выполнение всех или некоторых специально выбранных путей в коде приложения. Если говорить строго научно, то определения большинства видов тестирования на основе структур кода должны звучать чуть-чуть иначе, т.к. в программировании условием считается выражение без логических операторов, а решением — выражение с логиче- скими операторами. Но глоссарий ISTQB не делает на этом ак- цента, а потому приведённые выше определения можно считать корректными. Однако, если вам интересно, рекомендуется озна- комиться с заметкой «What is the difference between a Decision and a Condition? » 254 Кратко вся суть видов тестирования на основе структур кода показана в таблице 2.3.c. 249 Condition Testing. A white box test design technique in which test cases are designed to execute condition outcomes (condition is a logical expression that can be evaluated as True or False, e.g. A > B). [ISTQB Glossary] 250 Multiple Condition Testing. A white box test design technique in which test cases are designed to execute combinations of single condition outcomes (within one statement). [ISTQB Glossary] 251 Modified Condition Decision Coverage Testing. Technique to design test cases to execute branch condition outcomes that independently affect a decision outcome and discard conditions that do not affect the final outcome. [ «Guide to Advanced Soft- ware Testing, Second Edition », Anne Mette Hass]. 252 Decision Testing. A white box test design technique in which test cases are designed to execute decision outcomes (decision is program point at which the control flow has two or more alternative routes, e.g. a node with two or more links to separate branches). [ISTQB Glossary] 253 Path testing. A white box test design technique in which test cases are designed to execute paths. [ISTQB Glossary] 254 «What is the difference between a Decision and a Condition?» [ http://www-01.ibm.com/support/docview.wss?uid=swg21129252 ] Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 96/298 Таблица 2.3.c — Виды тестирования на основе структур кода Русскоязычное название Англоязычное название Суть (что проверяется) Тестирование на ос- нове выражений Statement testing Отдельные атомарные участки кода, например x = 10 Тестирование на ос- нове ветвей Branch testing Проход по ветвям выполнения кода. Тестирование на ос- нове условий Condition testing, Branch Condition Test- ing Отдельные условные конструкции, например if (a == b) Тестирование на ос- нове комбинаций условий Multiple condition test- ing, Branch Condition Combination Testing Составные условные конструкции, например if ((a == b) || (c == d)) Тестирование на ос- нове отдельных усло- вий, порождающих ветвление («решаю- щих условий») Modified Condition De- cision Coverage Test- ing Отдельные условия, в одиночку влияю- щие на итог вычисления составного условия, например в условии if ((x == y) && (n == m)) ложное значение в каждом из отдельных условий само по себе при- водит к результату false вне зависимости от результата вычисления второго усло- вия Тестирование на ос- нове решений Decision testing Сложные ветвления, например оператор switch Тестирование на ос- нове путей Path testing Все или специально выбранные пути • Тестирование на основе (моделей) поведения приложения (application behav- ior/model-based testing): o Тестирование по таблице принятия решений (decision table test- ing 255 ) — техника тестирования (по методу чёрного ящика), в которой тест-кейсы разрабатываются на основе т.н. таблицы принятия реше- ний, в которой отражены входные данные (и их комбинации) и воздей- ствия на приложение, а также соответствующие им выходные данные и реакции приложения. o Тестирование по диаграмме или таблице состояний (рассмотрено ранее {94} ). o Тестирование по спецификациям (specification-based testing, black box testing) ( рассмотрено ранее {71} ). o Тестирование по моделям поведения приложения (model-based testing 256 ) — техника тестирования, в которой исследование приложе- ния (и разработка тест-кейсов) строится на некой модели: таблице принятия решений {96} , таблице или диаграмме состояний {94} , пользова- тельских сценариев {143} , модели нагрузки {88} и т.д. o Тестирование на основе вариантов использования (use case test- ing 257 ) — техника тестирования (по методу чёрного ящика), в которой тест-кейсы разрабатываются на основе вариантов использования. Ва- рианты использования выступают в основном источником информа- ции для шагов тест-кейса, в то время как наборы входных данных 255 Decision Table Testing. A black box test design technique in which test cases are designed to execute the combinations of inputs and/or stimuli (causes) shown in a decision table (a table showing combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects), which can be used to design test cases). [ISTQB Glossary] 256 Model-based Testing. Testing based on a model of the component or system under test, e.g., reliability growth models, usage models such as operational profiles or behavioral models such as decision table or state transition diagram. [ISTQB Glossary] 257 Use case testing. A black box test design technique in which test cases are designed to execute scenarios of use cases. [ISTQB Glossary] Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 97/298 удобно разрабатывать с помощью техник выбора входных данных {91} В общем случае источником информации для разработки тест-кейсов в этой технике могут выступать не только варианты использования, но и другие пользовательские требования {37} в любом их виде. В случае если методология разработки проекта подразумевает использование пользовательских историй, этот вид тестирования может быть заме- нён тестированием на основе пользовательских историй (user story testing 258 ). o Параллельное тестирование (parallel testing 259 ) — техника тестирова- ния, в которой поведение нового (или модифицированного) приложе- ния сравнивается с поведением эталонного приложения (предположи- тельно работающего верно). Термин «параллельное тестирование» также может использоваться для обозначения способа проведения те- стирования, когда несколько тестировщиков или систем автоматиза- ции выполняют работу одновременно, т.е. параллельно. Очень редко (и не совсем верно) под параллельным тестированием понимают му- тационное тестирование {91} o Тестирование на основе случайных данных (random testing 260 ) — техника тестирования (по методу чёрного ящика), в которой входные данные, действия или даже сами тест-кейсы выбираются на основе (псевдо)случайных значений так, чтобы соответствовать операцион- ному профилю (operational profile 261 ) — подмножеству действий, соот- ветствующих некоей ситуации или сценарию работы с приложением. Не стоит путать этот вид тестирования с т.н. «обезьяньим тестирова- нием» (monkey testing 262 ). o A/B- тестирование (A/B testing, split testing 263 ) — техника тестирования, в которой исследуется влияние на результат выполнения операции из- менения одного из входных параметров. Однако куда чаще можно встретить трактовку A/B-тестирования как технику тестирования удоб- ства использования {85} , в которой пользователям случайным образом предлагаются разные варианты элементов интерфейса, после чего оценивается разница в реакции пользователей. Крайне подробное описание некоторых видов тестирования, отно- сящихся к данной классификации, можно найти в книге Ли Ко- упленда «Практическое руководство по разработке тестов» (Lee Copeland , «A Practitioner's Guide to Software Test Design»): • Тестирование по таблице принятия решений — в главе 5. • Тестирование по диаграмме или таблице состояний — в главе 7. • Тестирование на основе вариантов использования — в главе 9. 258 User story testing. A black box test design technique in which test cases are designed based on user stories to verify their correct implementation. [ISTQB Glossary] 259 Parallel testing. Testing a new or an altered data processing system with the same source data that is used in another system. The other system is considered as the standard of comparison. [ISPE Glossary] 260 Random testing. A black box test design technique where test cases are selected, possibly using a pseudo-random generation algorithm, to match an operational profile. This technique can be used for testing non-functional attributes such as reliability and performance. [ISTQB Glossary] 261 Operational profile. The representation of a distinct set of tasks performed by the component or system, possibly based on user behavior when interacting with the component or system, and their probabilities of occurrence. A task is logical rather that physical and can be executed over several machines or be executed in non-contiguous time segments. [ISTQB Glossary] 262 Monkey testing. Testing by means of a random selection from a large range of inputs and by randomly pushing buttons, ignorant of how the product is being used. [ISTQB Glossary] 263 Split testing is a design for establishing a causal relationship between changes and their influence on user-observable behavior. [«Controlled experiments on the web: survey and practical guide», Ron Kohavi] Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 98/298 2.3.2.14. Классификация по моменту выполнения (хронологии) Несмотря на многочисленные попытки создать единую хронологию тестиро- вания, предпринятые многими авторами, по-прежнему можно смело утверждать, что общепринятого решения, которое в равной степени подходило бы для любой методологии управления проектами, любого отдельного проекта и любой его ста- дии, просто не существует. Если попытаться описать хронологию тестирования одной общей фразой, то можно сказать, что происходит постепенное наращивание сложности самих тест- кейсов и сложности логики их выбора. • Общая универсальная логика последовательности тестирования состоит в том, чтобы начинать исследование каждой задачи с простых позитивных тест-кейсов, к которым постепенно добавлять негативные (но тоже доста- точно простые). Лишь после того, как наиболее типичные ситуации покрыты простыми тест-кейсами, следует переходить к более сложным (опять же, начиная с позитивных). Такой подход — не догма, но к нему стоит прислу- шаться, т.к. углубление на начальных этапах в негативные (к тому же — сложные) тест-кейсы может привести к ситуации, в которой приложение от- лично справляется с кучей неприятностей, но не работает на элементарных повседневных задачах. Ещё раз суть универсальной последовательности: 1) простое позитивное тестирование; 2) простое негативное тестирование; 3) сложное позитивное тестирование; 4) сложное негативное тестирование. • Последовательность тестирования, построенная по иерархии компонентов: o Восходящее тестирование (bottom-up testing 264 ) — инкрементальный подход к интеграционному тестированию {74} , в котором в первую оче- редь тестируются низкоуровневые компоненты, после чего процесс пе- реходит на всё более и более высокоуровневые компоненты. o Нисходящее тестирование (top-down testing 265 ) — инкрементальный подход к интеграционному тестированию {74} , в котором в первую оче- редь тестируются высокоуровневые компоненты, после чего процесс переходит на всё более и более низкоуровневые компоненты. o Гибридное тестирование (hybrid testing 266 ) — комбинация восходя- щего и нисходящего тестирования, позволяющая упростить и ускорить получение результатов оценки приложения. Поскольку термин «гибридное» является синонимом «комби- нированное», под «гибридным тестированием» может пони- маться практически любое сочетание двух и более видов, тех- ник или подходов к тестированию. Всегда уточняйте, о гибриде чего именно идёт речь. 264 Bottom-up testing. An incremental approach to integration testing where the lowest level components are tested first, and then used to facilitate the testing of higher level components. This process is repeated until the component at the top of the hierarchy is tested. [ISTQB Glossary] 265 Top-down testing. An incremental approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level compo- nents. The process is repeated until the lowest level components have been tested. [ISTQB Glossary] 266 Hybrid testing, Sandwich testing. First, the inputs for functions are integrated in the bottom-up pattern discussed above. The outputs for each function are then integrated in the top-down manner. The primary advantage of this approach is the degree of support for early release of limited functionality. [«Integration testing techniques», Kratika Parmar] Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 99/298 • Последовательность тестирования, построенная по концентрации внимания на требованиях и их составляющих: 1) Тестирование требований, которое может варьироваться от беглой оценки в стиле «всё ли нам понятно» до весьма формальных под- ходов, в любом случае первично по отношению к тестированию того, как эти требования реализованы. 2) Тестирование реализации функциональных составляющих требо- ваний логично проводить до тестирования реализации нефункцио- нальных составляющих, т.к. если что-то просто не работает, то про- верять производительность, безопасность, удобство и прочие не- функциональные составляющие бессмысленно, а чаще всего и во- все невозможно. 3) Тестирование реализации нефункциональных составляющих тре- бований часто становится логическим завершением проверки того, как реализовано то или иное требование. • Типичные общие сценарии используются в том случае, когда не существует явных предпосылок к реализации иной стратегии. Такие сценарии могут ви- доизменяться и комбинироваться (например, весь «типичный общий сцена- рий 1» можно повторять на всех шагах «типичного общего сценария 2»). o Типичный общий сценарий 1: 1) Дымовое тестирование {76} 2) Тестирование критического пути {77} 3) Расширенное тестирование {78} o Типичный общий сценарий 2: 1) Модульное тестирование {74} 2) Интеграционное тестирование {74} 3) Системное тестирование {75} o Типичный общий сценарий 3: 1) Альфа-тестирование {81} 2) Бета-тестирование {81} 3) Гамма-тестирование {81} В завершение ещё раз подчеркнём, что рассмотренные здесь классифика- ции тестирования не являются чем-то каноническим и незыблемым. Они лишь при- званы упорядочить огромный объём информации о различных видах деятельности тестировщиков и упростить запоминание соответствующих фактов. |