Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Thread testing. An approach to component integration testing where the progressive integration of components follows the im- plementation of subsets of the requirements, as opposed to the integration of components by levels of a hierarchy. [ISTQB Glossary] Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 75/298 компонентами, «на стыке» их взаимодействия часто возникают проблемы. Именно эти проблемы и выявляет интеграционное тестирование. (См. также техники восходящего, нисходящего и гибридного тестирования в хронологи- ческой классификации по иерархии компонентов {98} .) • Системное тестирование (system testing 136 ) направлено на проверку всего приложения как единого целого, собранного из частей, проверенных на двух предыдущих стадиях. Здесь не только выявляются дефекты «на стыках» компонентов, но и появляется возможность полноценно взаимодействовать с приложением с точки зрения конечного пользователя, применяя множество других видов тестирования, перечисленных в данной главе. С классификацией по уровню детализации приложения связан интересный печальный факт: если предыдущая стадия обнаружила проблемы, то на следую- щей стадии эти проблемы точно нанесут удар по качеству; если же предыдущая стадия не обнаружила проблем, это ещё никоим образом не защищает нас от про- блем на следующей стадии. Для лучшего запоминания степень детализации в модульном, интеграцион- ном и системном тестировании показана схематично на рисунке 2.3.d. Рисунок 2.3.d — Схематичное представление классификации тестирования по уровню детализации приложения Если обратиться к словарю ISTQB и прочитать определение уровня тестиро- вания (test level 137 ), то можно увидеть, что аналогичное разбиение на модульное, интеграционное и системное тестирование, к которым добавлено ещё и приёмоч- ное тестирование {84} , используется в контексте разделения областей ответственно- сти на проекте. Но такая классификация больше относится к вопросам управления проектом, чем к тестированию в чистом виде, а потому выходит за рамки рассмат- риваемых нами вопросов. Самый полный вариант классификации тестирования по уровню тестиро- вания можно посмотреть в статье «What are Software Testing Levels? 138 ». Для улучшения запоминания отразим эту идею на рисунке 2.3.e, но отме- тим, что это скорее общий теоретический взгляд. 136 System testing. The process of testing an integrated system to verify that it meets specified requirements. [ISTQB Glossary] 137 Test level. A group of test activities that are organized and managed together. A test level is linked to the responsibilities in a project. Examples of test levels are component test, integration test, system test and acceptance test. [ISTQB Glossary] 138 «What are Software Testing Levels?» [ http://istqbexamcertification.com/what-are-software-testing-levels/ ] Модульное тестирование Интеграционное тестирование Системное тестирование Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 76/298 Рисунок 2.3.e — Самый полный вариант классификации тестирования по уровню тестирования 2.3.2.6. Классификация по (убыванию) степени важности тестируемых функций (по уровню функционального тестирования) В некоторых источниках эту разновидность классификации также называют «по глубине тестирования». Внимание! Возможна путаница, вызванная тем, что единого общеприня- того набора классификаций не существует, и две из них имеют очень схо- жие названия: • «По уровню детализации приложения» = «по уровню тестирования». • «По (убыванию) степени важности тестируемых функций» = «по уровню функционального тестирования». • Дымовое тестирование (smoke test 139 , intake test 140 , build verification test 141 ) направлено на проверку самой главной, самой важной, самой ключевой функциональности, неработоспособность которой делает бессмысленной 139 Smoke test, Confidence test, Sanity test. A subset of all defined/planned test cases that cover the main functionality of a component or system, to ascertaining that the most crucial functions of a program work, but not bothering with finer details. [ISTQB Glossary] 140 Intake test. A special instance of a smoke test to decide if the component or system is ready for detailed and further testing. An intake test is typically carried out at the start of the test execution phase. [ISTQB Glossary] 141 Build verification test. A set of automated tests which validates the integrity of each new build and verifies its key/core function- ality, stability and testability. It is an industry practice when a high frequency of build releases occurs (e.g., agile projects) and it is run on every new build before the build is released for further testing. [ISTQB Glossary] Модульное тестирование Интеграционное тестирование Компонентное тестирование Компонентное интеграционное тестирование Системное интеграционное тестирование Системное тестирование Приёмочное тестирование Альфа-тестирование Бета-тестирование У ро ве нь т ест ир о ва ни я Гамма-тестирование Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 77/298 саму идею использования приложения (или иного объекта, подвергаемого дымовому тестированию). Внимание! Очень распространённая проблема! Из-за особенности перевода на русский язык под термином «приёмочное тестирова- ние» часто может пониматься как «smoke test» {76} , так и «acceptance test » {84} , которые изначально не имеют между собою ничего общего. Возможно, в том числе поэтому многие тестировщики почти не ис- пользуют русский перевод «дымовое тестирование», а так и гово- рят — «смоук-тест». Дымовое тестирование проводится после выхода нового билда, чтобы опре- делить общий уровень качества приложения и принять решение о (не)целе- сообразности выполнения тестирования критического пути и расширенного тестирования. Поскольку тест-кейсов на уровне дымового тестирования от- носительно немного, а сами они достаточно просты, но при этом очень часто повторяются, они являются хорошими кандидатами на автоматизацию. В связи с высокой важностью тест-кейсов на данном уровне пороговое значе- ние метрики их прохождения часто выставляется равным 100 % или близким к 100 %. Очень часто можно услышать вопрос о том, чем «smoke test» отличается от «sanity test». В глоссарии ISTQB сказано просто: «sanity test: See smoke test». Но некоторые авторы утверждают 142 , что разница 143 есть и может быть выра- жена следующей схемой (рисунок 2.3.f): Рисунок 2.3.f — Трактовка разницы между smoke test и sanity test • Тестирование критического пути (critical path 144 test) направлено на иссле- дование функциональности, используемой типичными пользователями в ти- пичной повседневной деятельности. Как видно из определения в сноске к ан- глоязычной версии термина, сама идея позаимствована из управления про- ектами и трансформирована в контексте тестирования в следующую: суще- ствует большинство пользователей, которые чаще всего используют некое 142 «Smoke Vs Sanity Testing — Introduction and Differences» [ http://www.guru99.com/smoke-sanity-testing.html ] 143 «Smoke testing and sanity testing — Quick and simple differences» [ http://www.softwaretestinghelp.com/smoke-testing-and-san- ity-testing-difference/ ] 144 Critical path. Longest sequence of activities in a project plan which must be completed on time for the project to complete on due date. An activity on the critical path cannot be started until its predecessor activity is complete; if it is delayed for a day, the entire project will be delayed for a day unless the activity following the delayed activity is completed a day earlier. [ https://ever- hour.com/blog/how-to-calculate-critical-path/ ] Билд 1 Smoke Test Билд 2 Билд 3 Билд 30 Билд 31 Билд 32 Тест пройден? Sanity Test Дальнейшее тестирование Начальные, относительно нестабильные билды Близкие к релизу, относительно стабильные билды Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 78/298 подмножество функций приложения (см. рисунок 2.3.g). Именно эти функции и нужно проверить, как только мы убедились, что приложение «в принципе работает» (дымовой тест прошёл успешно). Если по каким-то причинам при- ложение не выполняет эти функции или выполняет их некорректно, очень многие пользователи не смогут достичь множества своих целей. Пороговое значение метрики успешного прохождения «теста критического пути» уже не- много ниже, чем в дымовом тестировании, но всё равно достаточно высоко (как правило, порядка 70–80–90 % — в зависимости от сути проекта). Рисунок 2.3.g — Суть тестирования критического пути • Расширенное тестирование (extended test 145 ) направлено на исследование всей заявленной в требованиях функциональности — даже той, которая низко проранжирована по степени важности. При этом здесь также учитыва- ется, какая функциональность является более важной, а какая — менее важ- ной. Но при наличии достаточного количества времени и иных ресурсов тест- кейсы этого уровня могут затронуть даже самые низкоприоритетные требо- вания. Ещё одним направлением исследования в рамках данного тестирования яв- ляются нетипичные, маловероятные, экзотические случаи и сценарии ис- пользования функций и свойств приложения, затронутых на предыдущих уровнях. Пороговое значение метрики успешного прохождения расширен- ного тестирования существенно ниже, чем в тестировании критического пути ( иногда можно увидеть даже значения в диапазоне 30–50 %, т.к. подавляю- щее большинство найденных здесь дефектов не представляет угрозы для успешного использования приложения большинством пользователей). К сожалению, часто можно встретить мнение, что дымовое тести- рование, тестирование критического пути и расширенное тестиро- вание напрямую связаны с позитивным {79} тестированием и негатив- ным {79} тестированием, и негативное появляется только на уровне тестирования критического пути. Это не так. Как позитивные, так и негативные тесты могут (а иногда и обязаны) встречаться на всех перечисленных уровнях. Например, деление на ноль в калькуля- торе явно должно относиться к дымовому тестированию, хотя это яркий пример негативного тест-кейса. 145 Extended test. The idea is to develop a comprehensive application system test suite by modeling essential capabilities as ex- tended use cases. [By «Extended Use Case Test Design Pattern», Rob Kuijt] Пользователи Функции приложения Время использования Тестирование критического пути Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 79/298 Для лучшего запоминания отразим эту классификацию графически: Рисунок 2.3.h — Классификация тестирования по (убыванию) степени важности тестируемых функций (по уровню функционального тестирования) 2.3.2.7. Классификация по принципам работы с приложением • Позитивное тестирование (positive testing 146 ) направлено на исследование приложения в ситуации, когда все действия выполняются строго по инструк- ции без каких бы то ни было ошибок, отклонений, ввода неверных данных и т.д. Если позитивные тест-кейсы завершаются ошибками, это тревожный признак — приложение работает неверно даже в идеальных условиях (и можно предположить, что в неидеальных условиях оно работает ещё хуже). Для ускорения тестирования несколько позитивных тест-кейсов можно объ- единять (например, перед отправкой заполнить все поля формы верными значениями) — иногда это может усложнить диагностику ошибки, но суще- ственная экономия времени компенсирует этот риск. • Негативное тестирование (negative testing 147 , invalid testing 148 ) — направлено на исследование работы приложения в ситуациях, когда с ним выполняются (некорректные) операции и/или используются данные, потенциально приво- дящие к ошибкам (классика жанра — деление на ноль). Поскольку в реаль- ной жизни таких ситуаций значительно больше (пользователи допускают ошибки, злоумышленники осознанно «ломают» приложение, в среде работы приложения возникают проблемы и т.д.), негативных тест-кейсов оказыва- ется значительно больше, чем позитивных (иногда — в разы или даже на порядки). В отличие от позитивных негативные тест-кейсы не стоит объеди- нять, т.к. подобное решение может привести к неверной трактовке поведения приложения и пропуску (необнаружению) дефектов. 146 Positive testing is testing process where the system validated against the valid input data. In this testing tester always check for only valid set of values and check if application behaves as expected with its expected inputs. The main intention of this testing is to check whether software application not showing error when not supposed to & showing error when supposed to. Such testing is to be carried out keeping positive point of view & only execute the positive scenario. Positive Testing always tries to prove that a given product and project always meets the requirements and specifications. [ http://www.softwaretest- ingclass.com/positive-and-negative-testing-in-software-testing/ ] 147 Negative testing. Tests aimed at showing that a component or system does not work. Negative testing is related to the testers’ attitude rather than a specific test approach or test design technique, e.g. testing with invalid input values or exceptions. [ISTQB Glossary] 148 Invalid testing. Testing using input values that should be rejected by the component or system. [ISTQB Glossary] Дымовое тестирование Расширенное тестирование Тестирование критического пути У р о в ен ь ф ун кц и о н ал ь н о го те с ти р о в ан и я С те пе нь ва ж но ст и т ес ти ру ем ы х фу нк ц ий Высокая важность Средняя важность Низкая важность Гл уб ин а д ет ал из ац и и ис сл е до ва ни я пр и ло ж ен и я 1 2 3 П ос ле до ва те ль но ст ь вы по л не ни я Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 80/298 2.3.2.8. Классификация по природе приложения Данный вид классификации является искусственным, поскольку «внутри» речь будет идти об одних и тех же видах тестирования, отличающихся в данном контексте лишь концентрацией на соответствующих функциях и особенностях при- ложения, использованием специфических инструментов и отдельных техник. • Тестирование веб-приложений (web-applications testing) сопряжено с ин- тенсивной деятельностью в области тестирования совместимости {86} ( в осо- бенности — кросс-браузерного тестирования {87} ), тестирования производи- тельности {88} , автоматизации тестирования с использованием широкого спек- тра инструментальных средств. • Тестирование мобильных приложений (mobile applications testing) также требует повышенного внимания к тестированию совместимости {86} , оптимиза- ции производительности {88} (в том числе клиентской части с точки зрения сни- жения энергопотребления), автоматизации тестирования с применением эмуляторов мобильных устройств. • Тестирование настольных приложений (desktop applications testing) явля- ется самым классическим среди всех перечисленных в данной классифика- ции, и его особенности зависят от предметной области приложения, нюансов архитектуры, ключевых показателей качества и т.д. Эту классификацию можно продолжать очень долго. Например, можно от- дельно рассматривать тестирование консольных приложений (console appli- cations testing ) и приложений с графическим интерфейсом (GUI-applications testing ), серверных приложений (server applications testing) и клиентских при- ложений (client applications testing) и т.д. 2.3.2.9. Классификация по фокусировке на уровне архитектуры приложе- ния Данный вид классификации, как и предыдущий, также является искусствен- ным и отражает лишь концентрацию внимания на отдельной части приложения. • Тестирование уровня представления (presentation tier testing) сконцентри- ровано на той части приложения, которая отвечает за взаимодействие с «внешним миром» (как пользователями, так и другими приложениями). Здесь исследуются вопросы удобства использования, скорости отклика интер- фейса, совместимости с браузерами, корректности работы интерфейсов. • Тестирование уровня бизнес-логики (business logic tier testing) отвечает за проверку основного набора функций приложения и строится на базе ключе- вых требований к приложению, бизнес-правил и общей проверки функцио- нальности. • Тестирование уровня данных (data tier testing) сконцентрировано на той части приложения, которая отвечает за хранение и некоторую обработку дан- ных (чаще всего — в базе данных или ином хранилище). Здесь особый инте- рес представляет тестирование данных, проверка соблюдения бизнес-пра- вил, тестирование производительности. Если вы не знакомы с понятием многоуровневой архитектуры приложе- ний, ознакомьтесь с ним хотя бы по материалу 149 из Википедии. 149 «Multitier architecture», Wikipedia [ http://en.wikipedia.org/wiki/Multitier_architecture ] |