Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
2.3.2.13. Классификация по техникам и подходам • Позитивное тестирование (рассмотрено ранее {79} ). • Негативное тестирование (рассмотрено ранее {79} ). • Тестирование на основе опыта тестировщика, сценариев, чек-листов: o Исследовательское тестирование (рассмотрено ранее {82} ). o Свободное (интуитивное) тестирование (рассмотрено ранее {82} ). • Классификация по степени вмешательства в работу приложения: o Инвазивное тестирование (intrusive testing 217 ) — тестирование, вы- полнение которого может повлиять на функционирование приложения в силу работы инструментов тестирования (например, будут искажены показатели производительности) или в силу вмешательства (level of intrusion 218 ) в сам код приложения (например, для анализа работы при- ложения было добавлено дополнительное протоколирование, вклю- чён вывод отладочной информации и т.д.). Некоторые источники рас- сматривают 219 инвазивное тестирование как форму негативного {79} или даже стрессового {89} тестирования. o Неинвазивное тестирование (nonintrusive testing 220 ) — тестирование, выполнение которого незаметно для приложения и не влияет на про- цесс его обычной работы. • Классификация по техникам автоматизации: o Тестирование под управлением данными (data-driven testing 221 ) — способ разработки автоматизированных тест-кейсов, в котором вход- ные данные и ожидаемые результаты выносятся за пределы тест- кейса и хранятся вне его — в файле, базе данных и т.д. o Тестирование под управлением ключевыми словами (keyword- driven testing 222 ) — способ разработки автоматизированных тест-кей- сов, в котором за пределы тест-кейса выносится не только набор вход- ных данных и ожидаемых результатов, но и логика поведения тест- кейса, которая описывается ключевыми словами (командами). o Тестирование под управлением поведением (behavior-driven test- ing 223 ) — способ разработки автоматизированных тест-кейсов, в кото- ром основное внимание уделяется корректности работы бизнес-сце- нариев, а не отдельным деталям функционирования приложения. 217 Intrusive testing. Testing that collects timing and processing information during program execution that may change the behavior of the software from its behavior in a real environment. Intrusive testing usually involves additional code embedded in the software being tested or additional processes running concurrently with software being tested on the same processor. [ http://encyclope- dia2.thefreedictionary.com/intrusive+testing ] 218 Level of intrusion. The level to which a test object is modified by adjusting it for testability. [ISTQB Glossary] 219 Intrusive testing can be considered a type of interrupt testing, which is used to test how well a system reacts to intrusions and interrupts to its normal workflow. [ http://www.techopedia.com/definition/7802/intrusive-testing ] 220 Nonintrusive Testing. Testing that is transparent to the software under test, i.e., does not change its timing or processing char- acteristics. Nonintrusive testing usually involves additional hardware that collects timing or processing information and processes that information on another platform. [ http://encyclopedia2.thefreedictionary.com/nonintrusive+testing ] 221 Data-driven Testing (DDT). A scripting technique that stores test input and expected results in a table or spreadsheet, so that a single control script can execute all of the tests in the table. Data-driven testing is often used to support the application of test execution tools such as capture/playback tools. [ISTQB Glossary] 222 Keyword-driven Testing (KDT). A scripting technique that uses data files to contain not only test data and expected results, but also keywords related to the application being tested. The keywords are interpreted by special supporting scripts that are called by the control script or the test. [ISTQB Glossary] 223 Behavior-driven Testing (BDT). Behavior-driven Tests focuses on the behavior rather than the technical implementation of the software. If you want to emphasize on business point of view and requirements then BDT is the way to go. BDT are Given-when- then style tests written in natural language which are easily understandable to non-technical individuals. Hence these tests allow business analysts and management people to actively participate in test creation and review process. [Jyothi Rangaiah, http://www.womentesters.com/behaviour-driven-testing-an-introduction/ ] Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 91/298 • Классификация на основе (знания) источников ошибок: o Тестирование предугадыванием ошибок (error guessing 224 ) — тех- ника тестирования, в которой тесты разрабатываются на основе опыта тестировщика и его знаний о том, какие дефекты типичны для тех или иных компонентов или областей функциональности приложения. Мо- жет комбинироваться с техникой т.н. «ошибкоориентированного» те- стирования (failure-directed testing 225 ), в котором новые тесты строятся на основе информации о ранее обнаруженных в приложении пробле- мах. o Эвристическая оценка (heuristic evaluation 226 ) — техника тестирова- ния удобства использования {85} , направленная на поиск проблем в ин- терфейсе пользователя, представляющих собой отклонение от обще- принятых норм. o Мутационное тестирование (mutation testing 227 ) — техника тестирова- ния, в которой сравнивается поведение нескольких версий одного и того же компонента, причём часть таких версий может быть специ- ально разработана с добавлением ошибок (что позволяет оценить эф- фективность тест-кейсов — качественные тесты обнаружат эти специ- ально добавленные ошибки). Может комбинироваться со следующим в этом списке видом тестирования (тестированием добавлением оши- бок). o Тестирование добавлением ошибок (error seeding 228 ) — техника те- стирования, в которой в приложение специально добавляются зара- нее известные, специально продуманные ошибки с целью монито- ринга их обнаружения и устранения и, таким образом, формирования более точной оценки показателей процесса тестирования. Может ком- бинироваться с предыдущим в этом списке видом тестирования (мута- ционным тестированием). • Классификация на основе выбора входных данных: o Тестирование на основе классов эквивалентности (equivalence partitioning 229 ) — техника тестирования, направленная на сокращение количества разрабатываемых и выполняемых тест-кейсов при сохра- нении достаточного тестового покрытия. Суть техники состоит в выяв- лении наборов эквивалентных тест-кейсов (каждый из которых прове- ряет одно и то же поведение приложения) и выборе из таких наборов небольшого подмножества тест-кейсов, с наибольшей вероятностью обнаруживающих проблему. 224 Error Guessing. A test design technique where the experience of the tester is used to anticipate what defects might be present in the component or system under test as a result of errors made, and to design tests specifically to expose them. [ISTQB Glossary] 225 Failure-directed Testing. Software testing based on the knowledge of the types of errors made in the past that are likely for the system under test. [ https://www.techopedia.com/definition/7129/failure-directed-testing ]. 226 Heuristic Evaluation. A usability review technique that targets usability problems in the user interface or user interface design. With this technique, the reviewers examine the interface and judge its compliance with recognized usability principles (the «heu- ristics »). [ISTQB Glossary] 227 Mutation Testing, Back-to-Back Testing. Testing in which two or more variants of a component or system are executed with the same inputs, the outputs compared, and analyzed in cases of discrepancies. [ISTQB Glossary] 228 Error seeding. The process of intentionally adding known faults to those already in a computer program for the purpose of monitoring the rate of detection and removal, and estimating the number of faults remaining in the program. [ISTQB Glossary] 229 Equivalence partitioning. A black box test design technique in which test cases are designed to execute representatives from equivalence partitions. In principle test cases are designed to cover each partition at least once. [ISTQB Glossary] Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 92/298 o Тестирование на основе граничных условий (boundary value analy- sis 230 ) — инструментальная техника тестирования на основе классов эквивалентности, позволяющая выявить специфические значения ис- следуемых параметров, относящиеся к границам классов эквивалент- ности. Эта техника значительно упрощает выявление наборов эквива- лентных тест-кейсов и выбор таких тест-кейсов, которые обнаружат проблему с наибольшей вероятностью. o Доменное тестирование (domain analysis 231 , domain testing) — техника тестирования на основе классов эквивалентности и граничных усло- вий, позволяющая эффективно создавать тест-кейсы, затрагивающие несколько параметров (переменных) одновременно (в том числе с учё- том взаимозависимости этих параметров). Данная техника также опи- сывает подходы к выбору минимального множества показательных тест-кейсов из всего набора возможных тест-кейсов. o Попарное тестирование (pairwise testing 232 ) — техника тестирования, в которой тест-кейсы строятся по принципу проверки пар значений па- раметров (переменных) вместо того, чтобы пытаться проверить все возможные комбинации всех значений всех параметров. Эта техника является частным случаем N-комбинационного тестирования (n-wise testing 233 ) и позволяет существенно сократить трудозатраты на тести- рование (а иногда и вовсе сделать возможным тестирование в случае, когда количество «всех комбинаций всех значений всех параметров» измеряется миллиардами). Попарное тестирование (pairwise testing 232 ) — это НЕ парное те- стирование (pair testing 234 )! o Тестирование на основе ортогональных массивов (orthogonal array testing 235 ) — инструментальная техника попарного и N- комбинационного тестирования, основанная на использовании т.н. «ортогональных массивов» (двумерных массивов, обладающих следу- ющим свойством: если взять две любые колонки такого массива, то получившийся «подмассив» будет содержать все возможные попар- ные комбинации значений, представленных в исходном массиве). Ортогональные массивы — это НЕ ортогональные матрицы. Это совершенно разные понятия! Сравните их описания в статьях «Orthogonal array» 236 и «Orthogonal matrix» 237 230 Boundary value analysis. A black box test design technique in which test cases are designed based on boundary values (input values or output values which are on the edge of an equivalence partition or at the smallest incremental distance on either side of an edge, for example the minimum or maximum value of a range). [ISTQB Glossary] 231 Domain analysis. A black box test design technique that is used to identify efficient and effective test cases when multiple varia- bles can or should be tested together. It builds on and generalizes equivalence partitioning and boundary values analysis. [ISTQB Glossary] 232 Pairwise testing. A black box test design technique in which test cases are designed to execute all possible discrete combinations of each pair of input parameters. [ISTQB Glossary] 233 N-wise testing. A black box test design technique in which test cases are designed to execute all possible discrete combinations of any set of n input parameters. [ISTQB Glossary] 234 Pair testing. Two persons, e.g. two testers, a developer and a tester, or an end-user and a tester, working together to find defects. Typically, they share one computer and trade control of it while testing. [ISTQB Glossary] 235 Orthogonal array testing. A systematic way of testing all-pair combinations of variables using orthogonal arrays. It significantly reduces the number of all combinations of variables to test all pair combinations. See also combinatorial testing, n-wise testing, pairwise testing. [ISTQB Glossary] 236 «Orthogonal array», Wikipedia. [ http://en.wikipedia.org/wiki/Orthogonal_array ] 237 «Orthogonal matrix», Wikipedia. [ http://en.wikipedia.org/wiki/Orthogonal_matrix ] Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 93/298 Также см. комбинаторные техники тестирования {104} , которые расши- ряют и дополняют только что рассмотренный список видов тестирова- ния на основе выбора входных данных. Крайне подробное описание некоторых видов тестирования, отно- сящихся к данной классификации, можно найти в книге Ли Ко- упленда «Практическое руководство по разработке тестов» (Lee Copeland, «A Practitioner's Guide to Software Test Design»), в част- ности: • Тестирование на основе классов эквивалентности — в главе 3. • Тестирование на основе граничных условий — в главе 4. • Доменное тестирование — в главе 8. • Попарное тестирование и тестирование на основе ортогональ- ных массивов — в главе 6. Важно! Большинство этих техник входит в «джентльменский набор любого тестировщика», потому их понимание и умение применять можно считать обязательным. • Классификация на основе среды выполнения: o Тестирование в процессе разработки (development testing 238 ) — те- стирование, выполняемое непосредственно в процессе разработки приложения и/или в среде выполнения, отличной от среды реального использования приложения. Как правило, выполняется самими разра- ботчиками. o Операционное тестирование (рассмотрено ранее {85} ). • Тестирование на основе кода (code based testing). В различных источниках эту технику называют по-разному (чаще всего — тестированием на основе структур, причём некоторые авторы смешивают в один набор тестирование по потоку управления и по потоку данных, а некоторые строго разделяют эти стратегии). Подвиды этой техники также организуют в разные комбинации, но наиболее универсально их можно классифицировать так: o Тестирование по потоку управления (control flow testing 239 ) — семей- ство техник тестирования, в которых тест-кейсы разрабатываются с целью активации и проверки выполнения различных последователь- ностей событий, которые определяются посредством анализа исход- ного кода приложения. Дополнительное подробное пояснение см. дальше в этом разделе (см. тестирование на основе структур кода {94} ). o Тестирование по потоку данных (data-flow testing 240 ) — семейство техник тестирования, основанных на выборе отдельных путей из по- тока управления с целью исследования событий, связанных с измене- нием состояния переменных. Дополнительное подробное пояснение см. дальше в этом разделе (в части, где тестирование по потоку дан- ных пояснено с точки зрения стандарта ISO/IEC/IEEE 29119-4 {105} ). 238 Development testing. Formal or informal testing conducted during the implementation of a component or system, usually in the development environment by developers. [ISTQB Glossary] 239 Control Flow Testing. An approach to structure-based testing in which test cases are designed to execute specific sequences of events. Various techniques exist for control flow testing, e.g., decision testing, condition testing, and path testing, that each have their specific approach and level of control flow coverage. [ISTQB Glossary] 240 Data Flow Testing. A white box test design technique in which test cases are designed to execute definition-use pairs of variables. [ISTQB Glossary] Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 94/298 o Тестирование по диаграмме или таблице состояний (state transition testing 241 ) — техника тестирования, в которой тест-кейсы разрабатыва- ются для проверки переходов приложения из одного состояния в дру- гое. Состояния могут быть описаны диаграммой состояний (state dia- gram 242 ) или таблицей состояний (state table 243 ). Хорошее подробное пояснение по данному виду тестирова- ния можно прочесть в статье «What is State transition testing in software testing? » 244 Иногда эту технику тестирования также называют «тестированием по принципу конечного автомата» (finite state machine 245 testing). Важным преимуществом этой техники является возможность применения в ней теории конечных автоматов (которая хорошо формализована), а также возможность использования автоматизации для генерации комбина- ций входных данных. o Инспекция (аудит) кода (code review, code inspection 246 ) — семейство техник повышения качества кода за счёт того, что в процессе создания или совершенствования кода участвуют несколько человек. Степень формализации аудита кода может варьироваться от достаточно бег- лого просмотра до тщательной формальной инспекции. В отличие от техник статического анализа кода (по потоку управления и потоку дан- ных) аудит кода также улучшает такие его характеристики, как понят- ность, поддерживаемость, соответствие соглашениям об оформлении и т.д. Аудит кода выполняется в основном самими программистами. • Тестирование на основе структур кода (structure-based techniques) предпола- гает возможность исследования логики выполнения кода в зависимости от различных ситуаций и включает в себя: o Тестирование на основе выражений (statement testing 247 ) — техника тестирования (по методу белого ящика), в которой проверяется кор- ректность (и сам факт) выполнения отдельных выражений в коде. o |