Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Статическое тестирование (static testing 116 ) — тестирование без запуска кода на исполнение. В рамках этого подхода тестированию могут подвер- гаться: o Документы (требования, тест-кейсы, описания архитектуры приложе- ния, схемы баз данных и т.д.). o Графические прототипы (например, эскизы пользовательского интер- фейса). o Код приложения (что часто выполняется самими программистами в рамках аудита кода (code review 117 ) , являющегося специфической ва- риацией взаимного просмотра {48} в применении к исходному коду). Код приложения также можно проверять с использованием техник тести- рования на основе структур кода {94} o Параметры (настройки) среды исполнения приложения. o Подготовленные тестовые данные. • Динамическое тестирование (dynamic testing 118 ) — тестирование с запуском кода на исполнение. Запускаться на исполнение может как код всего прило- жения целиком (системное тестирование {75} ), так и код нескольких взаимосвя- занных частей (интеграционное тестирование {74} ), отдельных частей (модуль- ное или компонентное тестирование {74} ) и даже отдельные участки кода. Ос- новная идея этого вида тестирования состоит в том, что проверяется реаль- ное поведение (части) приложения. 2.3.2.3. Классификация по доступу к коду и архитектуре приложения • Метод белого ящика (white box testing 119 , open box testing, clear box testing, glass box testing) — у тестировщика есть доступ к внутренней структуре и коду приложения, а также есть достаточно знаний для понимания увиденного. Вы- деляют даже сопутствующую тестированию по методу белого ящика гло- бальную технику — тестирование на основе дизайна (design-based testing 120 ). Для более глубокого изучения сути метода белого ящика рекомендуется ознакомиться с техниками исследования потока управления {93} или потока данных {93} , использования диаграмм состояний {94} Некоторые авторы склонны жёстко связывать этот метод со статическим тестированием, но ничто не ме- шает тестировщику запустить код на выполнение и при этом периодически обращаться к самому коду (а модульное тестирование {74} и вовсе предпола- гает запуск кода на исполнение и при этом работу именно с кодом, а не с «приложением целиком»). 116 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] 117 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 118 Dynamic testing. Testing that involves the execution of the software of a component or system. [ISTQB Glossary] 119 White box testing. Testing based on an analysis of the internal structure of the component or system. [ISTQB Glossary] 120 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–2022 Стр: 71/298 • Метод чёрного ящика (black box testing 121 , closed box testing, specification- based testing) — у тестировщика либо нет доступа к внутренней структуре и коду приложения, либо недостаточно знаний для их понимания, либо он со- знательно не обращается к ним в процессе тестирования. При этом абсолют- ное большинство перечисленных на рисунках 2.3.b и 2.3.c видов тестирова- ния работают по методу чёрного ящика, идею которого в альтернативном определении можно сформулировать так: тестировщик оказывает на прило- жение воздействия (и проверяет реакцию) тем же способом, каким при ре- альной эксплуатации приложения на него воздействовали бы пользователи или другие приложения. В рамках тестирования по методу чёрного ящика ос- новной информацией для создания тест-кейсов выступает документация (особенно — требования (requirements-based testing 122 )) и общий здравый смысл (для случаев, когда поведение приложения в некоторой ситуации не регламентировано явно; иногда это называют «тестированием на основе не- явных требований», но канонического определения у этого подхода нет). • Метод серого ящика (gray box testing 123 ) — комбинация методов белого ящика и чёрного ящика, состоящая в том, что к части кода и архитектуры у тестировщика доступ есть, а к части — нет. На рисунках 2.3.b и 2.3.c этот метод обозначен особым пунктиром и серым цветом потому, что его явное упоминание — крайне редкий случай: обычно говорят о методах белого или чёрного ящика в применении к тем или иным частям приложения, при этом понимая, что «приложение целиком» тестируется по методу серого ящика. Важно! Некоторые авторы 124 определяют метод серого ящика как противопоставление методам белого и чёрного ящика, особо под- чёркивая, что при работе по методу серого ящика внутренняя струк- тура тестируемого объекта известна частично и выясняется по мере исследования. Этот подход, бесспорно, имеет право на существо- вание, но в своём предельном случае он вырождается до состояния «часть системы мы знаем, часть — не знаем», т.е. до всё той же комбинации белого и чёрного ящиков. Если сравнить основные преимущества и недостатки перечисленных мето- дов, получается следующая картина (см. таблицу 2.3.a). Методы белого и чёрного ящика не являются конкурирующими или взаимо- исключающими — напротив, они гармонично дополняют друг друга, компенсируя таким образом имеющиеся недостатки. 121 Black box testing. Testing, either functional or non-functional, without reference to the internal structure of the component or system. [ISTQB Glossary] 122 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] 123 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 ]. 124 «Gray box testing (gray box) definition», Margaret Rouse [ http://searchsoftwarequality.techtarget.com/definition/gray-box ] Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 72/298 Таблица 2.3.a — Преимущества и недостатки методов белого, чёрного и серого ящиков Преимущества Недостатки Метод белого ящика • Показывает скрытые проблемы и упрощает их диагностику. • Допускает достаточно простую ав- томатизацию тест-кейсов и их вы- полнение на самых ранних ста- диях развития проекта. • Обладает развитой системой мет- рик, сбор и анализ которых легко автоматизируется. • Стимулирует разработчиков к написанию качественного кода. • Многие техники этого метода яв- ляются проверенными, хорошо себя зарекомендовавшими реше- ниями, базирующимися на строгом техническом подходе. • Не может выполняться тестиров- щиками, не обладающими доста- точными знаниями в области про- граммирования. • Тестирование сфокусировано на реализованной функционально- сти, что повышает вероятность пропуска нереализованных требо- ваний. • Поведение приложения исследу- ется в отрыве от реальной среды выполнения и не учитывает её влияние. • Поведение приложения исследу- ется в отрыве от реальных поль- зовательских сценариев {143} Метод чёрного ящика • Тестировщик не обязан обладать (глубокими) знаниями в области программирования. • Поведение приложения исследу- ется в контексте реальной среды выполнения и учитывает её влия- ние. • Поведение приложения исследу- ется в контексте реальных пользо- вательских сценариев {143} • Тест-кейсы можно создавать уже на стадии появления стабильных требований. • Процесс создания тест-кейсов поз- воляет выявить дефекты в требо- ваниях. • Допускает создание тест-кейсов, которые можно многократно ис- пользовать на разных проектах. • Возможно повторение части тест- кейсов, уже выполненных разра- ботчиками. • Высока вероятность того, что часть возможных вариантов пове- дения приложения останется не- протестированной. • Для разработки высокоэффектив- ных тест-кейсов необходима каче- ственная документация. • Диагностика обнаруженных де- фектов более сложна в сравнении с техниками метода белого ящика. • В связи с широким выбором тех- ник и подходов затрудняется пла- нирование и оценка трудозатрат. • В случае автоматизации могут по- требоваться сложные дорогостоя- щие инструментальные средства. Метод серого ящика Сочетает преимущества и недостатки методов белого и чёрного ящика. 2.3.2.4. Классификация по степени автоматизации • Ручное тестирование (manual testing 125 ) — тестирование, в котором тест- кейсы выполняются человеком вручную без использования средств автома- тизации. Несмотря на то что это звучит очень просто, от тестировщика в те или иные моменты времени требуются такие качества, как терпеливость, наблюдательность, креативность, умение ставить нестандартные экспери- менты, а также умение видеть и понимать, что происходит «внутри системы», т.е. как внешние воздействия на приложение трансформируются в его внут- ренние процессы. 125 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–2022 Стр: 73/298 • Автоматизированное тестирование (automated testing, test automation 126 ) — набор техник, подходов и инструментальных средств, позволяющий исклю- чить человека из выполнения некоторых задач в процессе тестирования. Тест-кейсы частично или полностью выполняет специальное инструменталь- ное средство, однако разработка тест-кейсов, подготовка данных, оценка ре- зультатов выполнения, написания отчётов об обнаруженных дефектах — всё это и многое другое по-прежнему делает человек. Некоторые авторы 112 говорят отдельно о «полуавтоматизирован- ном» тестировании как варианте ручного с частичным использова- нием средств автоматизации и отдельно об «автоматизированном» тестировании (относя туда области тестирования, в которых компь- ютер выполняет ощутимо большой процент задач). Но т.к. без уча- стия человека всё равно не обходится ни один из этих видов тести- рования, не станем усложнять набор терминов и ограничимся одним понятием «автоматизированное тестирование». У автоматизированного тестирования есть много как сильных, так и слабых сторон (см. таблицу 2.3.b). Таблица 2.3.b — Преимущества и недостатки автоматизированного тестирования Преимущества Недостатки • Скорость выполнения тест-кейсов может в разы и на порядки превосходить возможно- сти человека. • Отсутствие влияния человеческого фактора в процессе выполнения тест-кейсов (устало- сти, невнимательности и т.д.). • Минимизация затрат при многократном вы- полнении тест-кейсов (участие человека здесь требуется лишь эпизодически). • Способность средств автоматизации выпол- нить тест-кейсы, в принципе непосильные для человека в силу своей сложности, скоро- сти или иных факторов. • Способность средств автоматизации соби- рать, сохранять, анализировать, агрегиро- вать и представлять в удобной для восприя- тия человеком форме колоссальные объёмы данных. • Способность средств автоматизации выпол- нять низкоуровневые действия с приложе- нием, операционной системой, каналами пе- редачи данных и т.д. • Необходим высококвалифицированный пер- сонал в силу того факта, что автоматизация — это «проект внутри проекта» (со своими требованиями, планами, кодом и т.д.) • Высокие затраты на сложные средства авто- матизации, разработку и сопровождение кода тест-кейсов. • Автоматизация требует более тщательного планирования и управления рисками, т.к. в противном случае проекту может быть нане- сён серьёзный ущерб. • Средств автоматизации крайне много, что усложняет проблему выбора того или иного средства и может повлечь за собой финансо- вые затраты (и риски), необходимость обуче- ния персонала (или поиска специалистов). • В случае ощутимого изменения требований, смены технологического домена, перера- ботки интерфейсов (как пользовательских, так и программных) многие тест-кейсы стано- вятся безнадёжно устаревшими и требуют создания заново. Если же выразить все преимущества и недостатки автоматизации тестиро- вания одной фразой, то получается, что автоматизация позволяет ощутимо увели- чить тестовое покрытие (test coverage 127 ), но при этом столь же ощутимо увеличи- вает риски. 126 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 formalized testing process. (Ravin der Veer Hooda, “An Automation of Software Testing: A Foundation for the Future”) 127 Coverage, Test coverage. The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test suite. [ISTQB Glossary] Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 74/298 Задание 2.3.a: сформируйте аналогичную таблицу с преимуществами и недостатками ручного тестирования. Подсказка: здесь недостаточно про- сто поменять заголовки колонок с преимуществами и недостатками авто- матизации. 2.3.2.5. Классификация по уровню детализации приложения (по уровню тестирования) Внимание! Возможна путаница, вызванная тем, что единого общеприня- того набора классификаций не существует, и две из них имеют очень схо- жие названия: • «По уровню детализации приложения» = «по уровню тестирования». • «По (убыванию) степени важности тестируемых функций» = «по уровню функционального тестирования». • Модульное (компонентное) тестирование (unit testing, module testing, com- ponent testing 128 ) направлено на проверку отдельных небольших частей при- ложения, которые (как правило) можно исследовать изолированно от других подобных частей. При выполнении данного тестирования могут проверяться отдельные функции или методы классов, сами классы, взаимодействие клас- сов, небольшие библиотеки, отдельные части приложения. Часто данный вид тестирования реализуется с использованием специальных технологий и инструментальных средств автоматизации тестирования {73} , значительно упрощающих и ускоряющих разработку соответствующих тест-кейсов. Из-за особенностей перевода на русский язык теряются нюансы степени детализации: «юнит-тестирование», как правило, направ- лено на тестирование атомарных участков кода, «модульное» — на тестирование классов и небольших библиотек, «компонентное» — на тестирование библиотек и структурных частей приложения. Но эта классификация не стандартизирована, и у различных авторов можно встретить совершенно разные взаимоисключающие трак- товки. • Интеграционное тестирование (integration testing 129 , component integration testing 130 , pairwise integration testing 131 , system integration testing 132 , incremental testing 133 , interface testing 134 , thread testing 135 ) направлено на проверку взаимо- действия между несколькими частями приложения (каждая из которых, в свою очередь, проверена отдельно на стадии модульного тестирования). К сожалению, даже если мы работаем с очень качественными отдельными 128 Module testing, Unit testing, Component testing. The testing of individual software components. [ISTQB Glossary] 129 Integration testing. Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems. [ISTQB Glossary] 130 Component integration testing. Testing performed to expose defects in the interfaces and interaction between integrated com- ponents. [ISTQB Glossary] 131 Pairwise integration testing. A form of integration testing that targets pairs of components that work together, as shown in a call graph. [ISTQB Glossary] 132 System integration testing. Testing the integration of systems and packages; testing interfaces to external organizations (e.g. Electronic Data Interchange, Internet). [ISTQB Glossary] 133 Incremental testing. Testing where components or systems are integrated and tested one or some at a time, until all the compo- nents or systems are integrated and tested. [ISTQB Glossary] 134 Interface testing. An integration test type that is concerned with testing the interfaces between components or systems. [ISTQB Glossary] 135 |