Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Категоричные заявления без обоснования. Как продолжение ошибки «критика текста или даже его автора» можно отметить и просто категоричные заяв- ления наподобие «это невозможно», «мы не будем этого делать», «это не нужно». Даже если вы понимаете, что требование бессмысленно или невыполнимо, эту мысль стоит сформулировать в корректной форме и дополнить вопросами, позво- ляющими автору документа самому принять окончательное решение. Например, «это не нужно» можно переформулировать так: «Мы сомневаемся в том, что дан- ная функция будет востребована пользователями. Какова важность этого требова- ния? Уверены ли вы в его необходимости?» Указание проблемы с требованиями без пояснения её сути. Помните, что автор исходного документа может не быть специалистом по тестированию или биз- нес-анализу. Потому просто пометка в стиле «неполнота», «двусмысленность» и т.д. могут ничего ему не сказать. Поясняйте свою мысль. Сюда же можно отнести небольшую, но досадную недоработку, относящуюся к противоречивости: если вы обнаружили некие противоречия, сделайте соответ- ствующие пометки во всех противоречащих друг другу местах, а не только в одном из них. Например, вы обнаружили, что требование 20 противоречит требованию 30. Тогда в требовании 20 отметьте, что оно противоречит требованию 30, и наоборот. И поясните суть противоречия. Плохое оформление вопросов и комментариев. Старайтесь сделать ваши вопросы и комментарии максимально простыми для восприятия. Помните не только о краткости формулировок, но и об оформлении текста (см., например, как на рисунке 2.2.j вопросы структурированы в виде списка — такая структура воспри- нимается намного лучше, чем сплошной текст). Перечитайте свой текст, исправьте опечатки, грамматические и пунктуационные ошибки и т.д. Описание проблемы не в том месте, к которому она относится. Класси- ческим примером может быть неточность в сноске, приложении или рисунке, кото- рая почему-то описана не там, где она находится, а в тексте, ссылающемся на со- ответствующий элемент. Исключением может считаться противоречивость, при ко- торой описать проблему нужно в обоих местах. Ошибочное восприятие требования как «требования к пользователю». Ранее (см. «Корректность» в «Свойства качественных требований») мы говорили, что требования в стиле «пользователь должен быть в состоянии отправить сооб- щение» являются некорректными. И это так. Но бывают ситуации, когда проблема намного менее опасна и состоит только в формулировке. Например, фразы в стиле «пользователь может нажать на любую из кнопок», «пользователю должно быть видно главное меню» на самом деле означают «все отображаемые кнопки должны Типичные ошибки при анализе и тестировании требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 63/298 быть доступны для нажатия» и «главное меню должно отображаться». Да, эту недо- работку тоже стоит исправить, но не следует отмечать её как критическую про- блему. Скрытое редактирование требований. Эту ошибку можно смело отнести к разряду крайне опасных. Её суть состоит в том, что тестировщик произвольно вно- сит правки в требования, никак не отмечая этот факт. Соответственно, автор доку- мента, скорее всего, не заметит такой правки, а потом будет очень удивлён, когда в продукте что-то будет реализовано совсем не так, как когда-то было описано в требованиях. Потому простая рекомендация: если вы что-то правите, обязательно отмечайте это (средствами вашего инструмента или просто явно в тексте). И ещё лучше отмечать правку как предложение по изменению, а не как свершившийся факт, т.к. автор исходного документа может иметь совершенно иной взгляд на си- туацию. Анализ, не соответствующий уровню требований. При тестировании тре- бований следует постоянно помнить, к какому уровню они относятся, т.к. в против- ном случае появляются следующие типичные ошибки: • Добавление в бизнес-требования мелких технических подробностей. • Дублирование на уровне пользовательских требований части бизнес-требо- ваний (если вы хотите увеличить прослеживаемость набора требований, имеет смысл просто использовать ссылки). • Недостаточная детализация требований уровня продукта (общие фразы, до- пустимые, например, на уровне бизнес-требований, здесь уже должны быть предельно детализированы, структурированы и дополнены подробной тех- нической информацией). Виды и направления тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 64/298 2.3. Виды и направления тестирования 2.3.1. Упрощённая классификация тестирования Тестирование можно классифицировать по очень большому количеству при- знаков, и практически в каждой серьёзной книге о тестировании автор показывает свой (безусловно имеющий право на существование) взгляд на этот вопрос. Соответствующий материал достаточно объёмен и сложен, а глубокое пони- мание каждого пункта в классификации требует определённого опыта, потому мы разделим данную тему на две: сейчас мы рассмотрим самый простой, минималь- ный набор информации, необходимый начинающему тестировщику, а в следующей главе приведём подробную классификацию. Используйте нижеприведённый список как очень краткую «шпаргалку для за- поминания». Итак, тестирование можно классифицировать: Рисунок 2.3.a — Упрощённая классификация тестирования • По запуску кода на исполнение: o Статическое тестирование — без запуска. o Динамическое тестирование — с запуском. • По доступу к коду и архитектуре приложения: o Метод белого ящика — доступ к коду есть. o Метод чёрного ящика — доступа к коду нет. o Метод серого ящика — к части кода доступ есть, к части — нет. • По степени автоматизации: o Ручное тестирование — тест-кейсы выполняет человек. o Автоматизированное тестирование — тест-кейсы частично или полно- стью выполняет специальное инструментальное средство. • По уровню детализации приложения (по уровню тестирования): o Модульное (компонентное) тестирование — проверяются отдельные небольшие части приложения. o Интеграционное тестирование — проверяется взаимодействие между несколькими частями приложения. o Системное тестирование — приложение проверяется как единое це- лое. • По (убыванию) степени важности тестируемых функций (по уровню функци- онального тестирования): o Дымовое тестирование (обязательно изучите этимологию термина — хотя бы в Википедии 109 ) — проверка самой важной, самой ключевой функциональности, неработоспособность которой делает бессмыс- ленной саму идею использования приложения. 109 «Smoke test», Wikipedia [ http://en.wikipedia.org/wiki/Smoke_testing_(electrical) ] Статическое Динамическое По запуску кода на исполнение Метод белого ящика По доступу к коду и архитектуре приложения Метод чёрного ящика Метод серого ящика Модульное Интеграционное По уровню детализации приложения Системное Ручное Автоматизированное По степени автоматизации По (убыванию) степени важности тестируемых функций «Дымовое» ( «смоук») Критического пути Расширенное Упрощённая классификация тестирования Позитивное Негативное По принципам работы с приложением Упрощённая классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 65/298 o Тестирование критического пути — проверка функциональности, ис- пользуемой типичными пользователями в типичной повседневной де- ятельности. o Расширенное тестирование — проверка всей (остальной) функцио- нальности, заявленной в требованиях. • По принципам работы с приложением: o Позитивное тестирование — все действия с приложением выполня- ются строго по инструкции без никаких недопустимых действий, некор- ректных данных и т.д. Можно образно сказать, что приложение иссле- дуется в «тепличных условиях». o Негативное тестирование — в работе с приложением выполняются (некорректные) операции и используются данные, потенциально при- водящие к ошибкам (классика жанра — деление на ноль). Внимание! Очень частая ошибка! Негативные тесты НЕ пред- полагают возникновения в приложении ошибки. Напротив — они предполагают, что верно работающее приложение даже в критической ситуации поведёт себя правильным образом (в примере с делением на ноль, например, отобразит сообще- ние «Делить на ноль запрещено»). Часто возникает вопрос о том, чем различаются «тип тестирования», «вид тестирования», «способ тестирования», «подход к тестированию» и т.д. и т.п. Если вас интересует строгий формальный ответ, посмотрите в направлении таких вещей как «таксономия 110 » и «таксон 111 », т.к. сам вопрос выходит за рамки тестирования как такового и относится уже к области науки. Но исторически так сложилось, что как минимум «тип тестирования» (testing type) и «вид тестирования» (testing kind) давно стали синонимами. 110 «Таксономия», Wikipedia [ https://ru.wikipedia.org/wiki/ Таксономия ] 111 «Таксон», Wikipedia [ https://ru.wikipedia.org/wiki/ Таксон ] Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 66/298 2.3.2. Подробная классификация тестирования 2.3.2.1. Схема классификации тестирования Теперь мы рассмотрим классификацию тестирования максимально по- дробно. Настоятельно рекомендуется прочесть не только текст этой главы, но и все дополнительные источники, на которые будут приведены ссылки. На рисунках 2.3.b и 2.3.c приведена схема, на которой все способы класси- фикации показаны одновременно. Многие авторы, создававшие подобные класси- фикации 112 , использовали интеллект-карты, однако такая техника не позволяет в полной мере отразить тот факт, что способы классификации пересекаются (т.е. не- которые виды тестирования можно отнести к разным способам классификации). На рисунках 2.3.b и 2.3.c самые яркие случаи таких пересечений отмечены цветом (см. полноразмерный электронный вид рисунка 115 ) и границей блоков в виде набора то- чек. Если вы видите на схеме подобный блок — ищите одноимённый где-то в дру- гом виде классификации. Настоятельно рекомендуется в дополнение к материалу этой главы про- честь: • прекрасную статью «Классификация видов тестирования» 112 ; • также классическую книгу Ли Коупленда «Практическое руководство по разработке тестов» (Lee Copeland, «A Practitioner's Guide to Software Test Design »); • очень интересную заметку «Types of Software Testing: List of 100 Differ- ent Testing Types » 113 Зачем вообще нужна классификация тестирования? Она позволяет упорядо- чить знания и значительно ускоряет процессы планирования тестирования и раз- работки тест-кейсов, а также позволяет оптимизировать трудозатраты за счёт того, что тестировщику не приходится изобретать очередной велосипед. При этом ничто не мешает создавать собственные классификации — как во- обще придуманные с нуля, так и представляющие собой комбинации и модифика- ции представленных ниже классификаций. Если вас интересует некая «эталонная классификация», то… её не суще- ствует. Можно сказать, что в материалах 114 ISTQB приведён наиболее обобщённый и общепринятый взгляд на этот вопрос, но и там нет единой схемы, которая объединяла бы все варианты классификации. Так что, если вас просят рассказать о классификации тестирования, стоит уточнить, согласно какому автору или источнику спрашивающий ожидает услышать ваш ответ. Сейчас вы приступите к изучению одного из самых сложных разделов этой книги. Если вы уже имеете достаточный опыт в тестировании, можете отталки- ваться от схемы, чтобы систематизировать и расширить свои знания. Если вы только начинаете заниматься тестированием, рекомендуется сначала прочитать текст, следующий за схемой. 112 «Классификация видов тестирования» [ http://habrahabr.ru/company/npo-comp/blog/223833/ ] 113 «Types of Software Testing: List of 100 Different Testing Types» [ http://www.guru99.com/types-of-software-testing.html ] 114 International Software Testing Qualifications Board, Downloads. [ http://www.istqb.org/downloads.html ] Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 67/298 По поводу схем, которые вы сейчас увидите на рисунках 2.3.b и 2.3.c, ча- сто поступают вопросы, почему функциональное и нефункциональное те- стирование не связано с соответствующими подвидами. Тому есть две причины: 1) Несмотря на то что те или иные виды тестирования принято причислять к функциональному или нефункциональному тестированию, в них всё равно присутствуют обе составляющие (как функциональная, так и не- функциональная), пусть и в разных пропорциях. Более того: часто прове- рить нефункциональную составляющую невозможно, пока не будет реа- лизована соответствующая функциональная составляющая. 2) Схема превратилась бы в непроглядную паутину линий. Потому было решено оставить рисунки 2.3.b и 2.3.c в том виде, в каком они представлены на следующих двух страницах. Полноразмерный вари- ант этих рисунков можно скачать здесь 115 Итак, тестирование можно классифицировать… 115 Полноразмерный вариант рисунков 2.3.b [ http://svyatoslav.biz/wp-pics/software_testing_classification_ru.png ] и 2.3.c [ http://svyatoslav.biz/wp-pics/software_testing_classification_en.png ] Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 68/298 Рисунок 2.3.b — Подробная классификация тестирования (русскоязычный вариант) Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 69/298 Рисунок 2.3.c — Подробная классификация тестирования (англоязычный вариант) Static testing Dynamic testing By code execution White box method By access to application code and architecture Black box method Gray box method Unit testing Integration testing By specification level (by testing level) System testing Web app testing Mobile app testing By application nature Desktop app testing By architecture tier Presentation tier testing Business-logic tier testing Data tier testing By formalization level Test case based Exploratory Ad hoc Manual Automated (+ automatic) By automation level Alpha testing Beta testing By end users participation By functions under test importance (decreasingly) (by functional testing level) Smoke testing Critical path testing Extended testing By aims and goals Regression testing Re-testing Acceptance testing Positive testing Negative testing Functional testing Nonfunctional testing Installation testing Performance testing Load testing (Capacity testing) Scalability testing Volume testing Stress testing Reliability testing Accessibility testing Interface testing Security testing Internationalization testing Localization testing Compatibility testing Data quality testing and Database integrity testing By techniques and approaches By chronology Based on tester’s experience, scenarios, checklists Exploratory Ad hoc By input data selection techniques Equivalence partitioning Boundary value analysis Domain testing Pairwise testing By code Control flow testing Data flow testing State transition testing By error source (knowledge) Error guessing Mutation testing By operational environment Operational testing Decision table testing By application behavior (models) Specification-based testing Model-based testing State transition testing Positive (simple) Negative (simple) Positive testing Negative testing Positive (complex) Negative (complex) Smoke testing Critical path testing Extended testing Typical scenario 1 Typical scenario 2 Unit testing Integration testing System testing Typical scenario 3 Software testing classification General chronology General typical scenarios Orthogonal array testing Comparison testing Error seeding Heuristic evaluation Use case testing Hybrid testing Qualification testing Exhaustive testing Resource utilization testing By intrusion to application work process Intrusive testing Nonintrusive testing Code review By code structures Statement testing Decision testing Condition testing Multiple condition testing Parallel testing Configuration testing Cross-browser testing Gamma testing Alpha testing Beta testing Gamma testing Acceptance testing Operational testing Branch testing Modified condition decision testing Path testing Usability testing Recoverability testing Failover testing Random testing Development testing A / B testing Concurrency testing By component hierarchy Bottom-up testing Top-down testing Hybrid testing By automation techniques Data-driven testing Keyword-driven testing By attention to requirements and requirements’ components Requirements testing Functional components testing Nonfunctional components testing By ways of dealing with application Behavior-driven testing Operational testing Подробная классификация тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 70/298 2.3.2.2. Классификация по запуску кода на исполнение Далеко не всякое тестирование предполагает взаимодействие с работаю- щим приложением. Потому в рамках данной классификации выделяют: • |