Файл: Обеспечения Базовый курс (3е издание) Версия книги 2 от 17. 04. 2023.pdf

Скачать файл
Заказать решение

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 07.11.2023

Просмотров: 857

Скачиваний: 31

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

Раздел 2: основные знания и умения 2.1. Процессы тестирования и разработки ПО 2.1.1. Модели разработки ПО Чтобы лучше разобраться в том, как тестирование соотносится с программи- рованием и иными видами проектной деятельности, для начала рассмотрим самые основы — модели разработки (lifecycle model16) ПО (как часть жизненного цикла (software lifecycle17) ПО). При этом сразу подчеркнём, что разработка ПО является лишь частью жизненного цикла ПО, и здесь мы говорим именно о разработке. Материал данной главы относится скорее к дисциплине «управление проек- тами», потому здесь рассмотрен крайне сжато: пожалуйста, не воспринимайте его как исчерпывающее руководство — здесь едва ли рассмотрена и сотая доля про- цента соответствующей предметной области. Модель разработки ПО (Software Development Model, SDM) — структура, систематизирующая различные виды проектной деятельности, их взаимо- действие и последовательность в процессе разработки ПО. Выбор той или иной модели зависит от масштаба и сложности проекта, предметной области, доступных ресурсов и множества других факторов. Выбор модели разработки ПО серьёзно влияет на процесс тестирования, определяя выбор стратегии, расписание, необходимые ресурсы и т.д. Моделей разработки ПО много, но в общем случае классическими можно считать водопадную, v-образную, итерационную инкрементальную, спиральную и гибкую. Перечень моделей разработки ПО (с кратким описанием), рекомендуе- мых к изучению тестировщиками, можно найти в статье «What are the Software Development Models?»18Знать и понимать модели разработки ПО нужно затем, чтобы уже с первых дней работы осознавать, что происходит вокруг, что, зачем и почему вы делаете. Многие начинающие тестировщики отмечают, что ощущение бессмысленности происходящего посещает их, даже если текущие задания интересны. Чем полнее вы будете представлять картину происходящего на проекте, тем яснее вам будет виден ваш собственный вклад в общее дело и смысл того, чем вы занимаетесь. Ещё одна важная вещь, которую следует понимать, состоит в том, что ника- кая модель не является догмой или универсальным решением. Нет идеальной мо- дели. Есть та, которая хуже или лучше подходит для конкретного проекта, конкрет- ной команды, конкретных условий. Частая ошибка! Единственное, от чего стоит предостеречь уже сейчас, так это от фривольной трактовки модели и перекраивания её «на свой вкус» без кристально чёткого понимания, что и зачем вы делаете. О том, что бывает при нарушении логики модели, прекрасно сказал в своём слайдка- сте «Scrum Tailoring»19Максим Дорофеев. 16 Lifecycle model. A partitioning of the life of a product or project into phases. [ISTQB Glossary] 17 Software lifecycle. The period of time that begins when a software product is conceived and ends when the software is no longer available for use. The software lifecycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and sometimes, retirement phase. Note these phases may overlap or be performed iteratively. [ISTQB Glossary] 18«What are the Software Development Models?» [http://istqbexamcertification.com/what-are-the-software-development-models/] 19«Scrum Tailoring», Максим Дорофеев [http://cartmendum.livejournal.com/10862.html] Модели разработки ПО Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023Стр: 19/301 Водопадная модель (waterfall model20) сейчас представляет скорее истори- ческий интерес, т.к. в современных проектах практически неприменима. Она пред- полагает однократное выполнение каждой из фаз проекта, которые, в свою оче- редь, строго следуют друг за другом (рисунок 2.1.a). Очень упрощённо можно ска- зать, что в рамках этой модели в любой момент времени команде «видна» лишь предыдущая и следующая фаза. В реальной же разработке ПО приходится «видеть весь проект целиком» и возвращаться к предыдущим фазам, чтобы исправить недоработки или что-то уточнить. Рисунок 2.1.a — Водопадная модель разработки ПО К недостаткам водопадной модели принято относить тот факт, что участие пользователей ПО в ней либо не предусмотрено вообще, либо предусмотрено лишь косвенно на стадии однократного сбора требований. С точки зрения же тести- рования эта модель плоха тем, что тестирование в явном виде появляется здесь лишь с середины развития проекта, достигая своего максимума в самом конце. 20 In a waterfall model, each phase must be completed fully before the next phase can begin. This type of model is basically used for the project which is small and there are no uncertain requirements. At the end of each phase, a review takes place to deter- mine if the project is on the right path and whether or not to continue or discard the project. [http://istqbexamcertifica- tion.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/] Общее планированиеТестирование в явном виде появляется лишь с середины развития проекта, достигая своего максимума в самом конце.Пользовательские требованияСистемные требованияТехническая архитектураДетализированный дизайнРазработка и отладкаИнтеграция и модульные тестыИнсталляционное тестированиеСистемное тестированиеПриёмочное тестированиеИтоговая отчётность Модели разработки ПО Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023Стр: 20/301 Тем не менее водопадная модель часто интуитивно применяется при выпол- нении относительно простых задач, а её недостатки послужили прекрасным отправ- ным пунктом для создания новых моделей. Также эта модель в несколько усовер- шенствованном виде используется на крупных проектах, в которых требования очень стабильны и могут быть хорошо сформулированы в начале проекта (аэро- космическая область, медицинское ПО и т.д.). Относительно краткое и притом хорошее описание водопадной модели можно найти в статье «What is Waterfall model advantages, disadvantages and when to use it?»21Великолепное описание истории развития и заката водопадной модели было создано Максимом Дорофеевым в виде слайдкаста «The Rise And Fall Of Waterfall», который можно посмотреть22в его ЖЖ.V-образная модель (V-model23) является логическим развитием водопад- ной. Можно заметить (рисунок 2.1.b), что в общем случае как водопадная, так и v- образная модели жизненного цикла ПО могут содержать один и тот же набор ста- дий, но принципиальное отличие заключается в том, как эта информация исполь- зуется в процессе реализации проекта. Очень упрощённо можно сказать, что при использовании v-образной модели на каждой стадии «на спуске» нужно думать о том, что и как будет происходить на соответствующей стадии «на подъёме». Тестирование здесь появляется уже на са- мых ранних стадиях развития проекта, что позволяет минимизировать риски, а также обнаружить и устранить множество потенциальных проблем до того, как они станут проблемами реальными. Рисунок 2.1.b — V-образная модель разработки ПО 21«What is Waterfall model advantages, disadvantages and when to use it?» [http://istqbexamcertification.com/what-is-waterfall- model-advantages-disadvantages-and-when-to-use-it/] 22ЖЖ Максима Дорофеева. [http://cartmendum.livejournal.com/44064.html] 23 V-model. A framework to describe the software development lifecycle activities from requirements specification to maintenance. The V-model illustrates how testing activities can be integrated into each phase of the software development lifecycle. [ISTQB Glossary] Общее планированиеПользовательские требованияСистемные требованияТехническая архитектураДетализированный дизайнРазработка и отладкаИнтеграция и модульные тестыИнсталляционное тестированиеСистемное тестированиеПриёмочное тестированиеИтоговая отчётностьТестирование появляется с самого начала проекта. Модели разработки ПО Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023Стр: 21/301 Краткое описание v-образной модели можно найти в статье «What is V- model advantages, disadvantages and when to use it?»24Пояснение по ис- пользованию v-образной модели в тестировании можно найти в статье «Using V Models for Testing»25Итерационная инкрементальная модель (iterative model26, incremental model27) является фундаментальной основой современного подхода к разработке ПО. Как следует из названия модели, ей свойственна определённая двойствен- ность (а ISTQB-глоссарий даже не приводит единого определения, разбивая его на отдельные части): • с точки зрения жизненного цикла модель является итерационной, т.к. под- разумевает многократное повторение одних и тех же стадий; • с точки зрения развития продукта (приращения его полезных функций) мо- дель является инкрементальной. Ключевой особенностью данной модели является разбиение проекта на от- носительно небольшие промежутки (итерации), каждый из которых в общем случае может включать в себя все классические стадии, присущие водопадной и v- образной моделям (рисунок 2.1.c). Итогом итерации является приращение (инкре- мент) функциональности продукта, выраженное в промежуточном билде (build28). Рисунок 2.1.c — Итерационная инкрементальная модель разработки ПО 24«What is V-model advantages, disadvantages and when to use it?» [http://istqbexamcertification.com/what-is-v-model-advantages- disadvantages-and-when-to-use-it/] 25«Using V Models for Testing», Donald Firesmith [https://insights.sei.cmu.edu/sei_blog/2013/11/using-v-models-for-testing.html] 26 Iterative development model. A development lifecycle where a project is broken into a usually large number of iterations. An iteration is a complete development loop resulting in a release (internal or external) of an executable product, a subset of the final product under development, which grows from iteration to iteration to become the final product. [ISTQB Glossary] 27 Incremental development model. A development lifecycle where a project is broken into a series of increments, each of which delivers a portion of the functionality in the overall project requirements. The requirements are prioritized and delivered in priority order in the appropriate increment. In some (but not all) versions of this lifecycle model, each subproject follows a 'mini V-model' with its own design, coding and testing phases. [ISTQB Glossary] 28 Build. A development activity whereby a complete system is compiled and linked, so that a consistent system is available including all latest changes. [На основе определения термина «daily build» из ISTQB Glossary] Общее планированиеПланирование + требованияАрхитектура и дизайнРазработка и отладкаИнтеграция и модульные тестыУстановка билдаТестированиеОценка результатовИтоговая отчётностьОтчётность Модели разработки ПО Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023Стр: 22/301 Длина итераций может меняться в зависимости от множества факторов, од- нако сам принцип многократного повторения позволяет гарантировать, что и тести- рование, и демонстрация продукта конечному заказчику (с получением обратной связи) будет активно применяться с самого начала и на протяжении всего времени разработки проекта. Во многих случаях допускается распараллеливание отдельных стадий внутри итерации и активная доработка с целью устранения недостатков, обнару- женных на любой из (предыдущих) стадий. Итерационная инкрементальная модель очень хорошо зарекомендовала себя на объёмных и сложных проектах, выполняемых большими командами на про- тяжении длительных сроков. Однако к основным недостаткам этой модели часто относят высокие накладные расходы, вызванные высокой «бюрократизированно- стью» и общей громоздкостью модели. Относительно краткие и очень хорошие описания итерационной инкре- ментальной модели можно найти в статьях «What is Iterative model ad- vantages, disadvantages and when to use it?»29и «What is Incremental model advantages, disadvantages and when to use it?»30Спиральная модель (spiral model31) представляет собой частный случай итерационной инкрементальной модели, в котором особое внимание уделяется управлению рисками, в особенности влияющими на организацию процесса разра- ботки проекта и контрольные точки. Схематично суть спиральной модели представлена на рисунке 2.1.d. Обра- тите внимание на то, что здесь явно выделены четыре ключевые фазы: • проработка целей, альтернатив и ограничений; • анализ рисков и прототипирование; • разработка (промежуточной версии) продукта; • планирование следующего цикла. С точки зрения тестирования и управления качеством повышенное внимание рискам является ощутимым преимуществом при использовании спиральной мо- дели для разработки концептуальных проектов, в которых требования естествен- ным образом являются сложными и нестабильными (могут многократно меняться по ходу выполнения проекта). Автор модели Barry Boehm в своих публикациях32,33подробно раскрывает эти вопросы и приводит множество рассуждений и рекомендаций о том, как применять спиральную модель с максимальным эффектом. Относительно краткие и очень хорошие описания спиральной модели можно найти в статьях «What is Spiral model - advantages, disadvantages and when to use it?»34и «Spiral Model»35 29«What is Iterative model advantages, disadvantages and when to use it?» [http://istqbexamcertification.com/what-is-iterative- model-advantages-disadvantages-and-when-to-use-it/] 30«What is Incremental model advantages, disadvantages and when to use it?» [http://istqbexamcertification.com/what-is-incremen- tal-model-advantages-disadvantages-and-when-to-use-it/] 31 Spiral model. A software lifecycle model which supposes incremental development, using the waterfall model for each step, with the aim of managing risk. In the spiral model, developers define and implement features in order of decreasing priority. [https://www.geeksforgeeks.org/software-engineering-spiral-model/] 32«A Spiral Model of Software Development and Enhancement», Barry Boehm [http://www-scf.usc.edu/csci201/lectures/Lec- ture11/boehm1988.pdf] 33«Spiral Development: Experience, Principles, and Refinements», Barry Boehm. [http://www.sei.cmu.edu/reports/00sr008.pdf] 34«What is Spiral model- advantages, disadvantages and when to use it?» [http://istqbexamcertification.com/what-is-spiral-model- advantages-disadvantages-and-when-to-use-it/] 35«Spiral Model» [https://searchsoftwarequality.techtarget.com/definition/spiral-model] Модели разработки ПО Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023Стр: 23/301 Рисунок 2.1.d — Спиральная модель разработки ПО Гибкая модель (agile model36) представляет собой совокупность различных подходов к разработке ПО и базируется на т.н. «agile-манифесте»37: • Люди и взаимодействие важнее процессов и инструментов. • Работающий продукт важнее исчерпывающей документации. • Сотрудничество с заказчиком важнее согласования условий контракта. • Готовность к изменениям важнее следования первоначальному плану. Данная тема является настолько большой, что ссылок на статьи недоста- точно, а потому стоит почитать эти книги: • «Agile Testing» (Lisa Crispin, Janet Gregory). • «Essential Scrum» (Kenneth S. Rubin). 36 Agile software development. A group of software development methodologies based on EITP iterative incremental development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. [ISTQB Glos- sary] 37«Agile-манифест» [http://agilemanifesto.org/iso/ru/manifesto.html] Проработка целей, альтернатив и ограниченийПроектныхПродуктныхЖизненного цикла проектаПроцесса разработки проектаЭксплуа- тации продуктаАнализ рисков и прототипированиеРазработка (промежуточной версии) продуктаПланирование следующего циклаПроекта и продуктаЖизненного циклаРазработки, интеграции и тестированияВнедрения и сопровожденияОбщей концепцииУточнённых требованийАрхитектурыДизайнаДетализацияКодированиеИнтеграцияТестированиеДетализацияКодированиеИнтеграцияТестированиеОценка промежуточных результатовНа ра ст ани е об щей цен но ст и пр од ук та Модели разработки ПО Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023Стр: 24/301 Как несложно догадаться, положенные в основу гибкой модели подходы яв- ляются логическим развитием и продолжением всего того, что было за десятилетия создано и опробовано в водопадной, v-образной, итерационной инкрементальной, спиральной и иных моделях. Причём здесь впервые был достигнут ощутимый ре- зультат в снижении бюрократической составляющей и максимальной адаптации процесса разработки ПО к мгновенным изменениям рынка и требований заказчика. Рисунок 2.1.e — Суть гибкой модели разработки ПО Очень упрощённо (почти на грани допустимого) можно сказать, что гибкая модель представляет собой облегчённую с точки зрения документации смесь ите- рационной инкрементальной и спиральной моделей (рисунки 2.1.c и 2.1.d); при этом следует помнить об «agile-манифесте» и всех вытекающих из него преимуществах и недостатках. ЦенностиСТРАТЕГИЯВЫПУСКИТЕРАЦИЯЕЖЕДНЕВНОНЕПРЕРЫВНОTDDБилдРефакторингИнтеграцияСотрудничествоБилд«Стендап» собраниеТестированиеПланированиеОценкаРетроспектива«Бэклог»План выпускаОценкаВидениеЦелиСоглашенияБюджетАдаптивностьПрозрачностьПростотаЕдинствоНаглядностьОсталось сделатьПроизводительностьСделаноТесты Модели разработки ПО Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023Стр: 25/301 Рисунок 2.1.f — Итерационный подход в рамках гибкой модели и scrum Главным недостатком гибкой модели считается сложность её применения к крупным проектам, а также частое ошибочное внедрение её подходов, вызванное недопониманием фундаментальных принципов модели. Тем не менее можно утверждать, что всё больше и больше проектов начи- нают использовать гибкую модель разработки. Очень подробное и элегантное изложение принципов применения гибкой модели разработки ПО можно найти в статье «The Agile System Develop- ment Life Cycle»381   2   3   4   5   6   7   8   9   ...   38

№ Имя Кодировка Размер 1 «Мелкий» файл в WIN1251.txt WIN1251 100 КБ 2 «Средний» файл в CP866.txt CP866 10 МБ 3 «Крупный» файл в KOI8R.txt KOI8R 50 МБ 4 «Крупный» файл в win-1251.html WIN1251 50 МБ 5 «Мелкий» файл в cp-866.html CP866 100 КБ 6 «Средний» файл в koi8-r.html KOI8R 10 МБ 7 «Средний» файл в WIN_1251.md WIN1251 10 МБ 8 «Крупный» файл в CP_866.md CP866 50 МБ 9 «Мелкий» файл в KOI8_R.md KOI8R 100 КБ 10 «Мелкий» эталон WIN1251.txt UTF8 100 КБ 11 «Средний» эталон CP866.txt UTF8 10 МБ 12 «Крупный» эталон KOI8R.txt UTF8 50 МБ 13 «Крупный» эталон в win-1251.html UTF8 50 МБ 14 «Мелкий» эталон в cp-866.html UTF8 100 КБ 15 «Средний» эталон в koi8-r.html UTF8 10 МБ 16 «Средний» эталон в WIN_1251.md UTF8 10 МБ 17 «Крупный» эталон в CP_866.md UTF8 50 МБ 18 «Мелкий» эталон в KOI8_R.md UTF8 100 КБ 19 Пустой файл.md - 0 Б 20 Слишком большой файл.txt - 52’428’801 Б 21 Картинка.jpg - 1 МБ 22 Картинка в виде TXT.txt -

Описание действий в качестве наименований модуля/подмодуля. Например, «запуск приложения» — это НЕ модуль или подмодуль. Модуль или под- модуль{125}— это всегда некие части приложения, а не его поведение. Сравните: «дыхательная система» — это модуль человека, но «дыхание» — нет. Описание событий или процессов в качестве шагов или ожидаемых ре-зультатов. Например, в качестве шага сказано: «Ввод спецсимволов в поле X». Это было бы сносным заглавием тест-кейса, но не годится в качестве шага, который должен быть сформулирован как «Ввести спецсимволы (перечень) в поле X». Куда страшнее, если подобное встречается в ожидаемых результатах. Например, там написано: «Отображение скорости чтения в панели X». И что? Оно должно начаться, продолжиться, завершиться, не начинаться, неким образом из- мениться (например, измениться должна размерность данных), как-то на что-то по- влиять? Тест-кейс становится полностью бессмысленным, т.к. такой ожидаемый результат невозможно сравнить с фактическим поведением приложения. «Выдумывание» особенностей поведения приложения. Да, часто в тре- бованиях отсутствуют самоочевидные (без кавычек, они на самом деле самооче- видные) вещи, но нередко встречаются и некачественные (например, неполные) требования, которые нужно улучшать, а не «телепатически компенсировать». Например, в требованиях сказано, что «приложение должно отображать диа- логовое окно сохранения с указанным по умолчанию каталогом». Если из контекста (соседних требований, иных документов) ничего не удаётся узнать об этом таин- ственном «каталоге по умолчанию», нужно задать вопрос. Нельзя просто записать в ожидаемых результатах «отображается диалоговое окно сохранения с указанным по умолчанию каталогом» (как мы проверим, что выбран именно указанный по умолчанию каталог, а не какой-то иной?). И уж тем более нельзя в ожидаемых ре- зультатах писать «отображается диалоговое окно сохранения с выбранным ката- логом “C:/SavedDocuments”» (откуда взялось это «C:/SavedDocuments», — не ясно, т.е. оно явно выдумано из головы и, скорее всего, выдумано неправильно). Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023Стр: 163/301 Отсутствие описания приготовления к выполнению тест-кейса. Часто для корректного выполнения тест-кейса необходимо каким-то особым образом настроить окружение. Предположим, что мы проверяем приложение, выполняющее резервное копирование файлов. Если тест выглядит примерно так, то выполняю- щий его сотрудник будет в замешательстве, т.к. ожидаемый результат кажется про- сто бредом. Откуда взялось «200»? Что это вообще такое? Шаги выполнения Ожидаемые результаты 1. Нажать на панели «Главная» кнопку «Быст- рая дедубликация». 2. Выбрать каталог «C:/MyData». 1. Кнопка «Быстрая дедубликация» переходит в утопленное состояние и меняет цвет с се- рого на зелёный. 2. На панели «Состояние» в поле «Дубли- каты» отображается «200». И совсем иначе этот тест-кейс воспринимался бы, если бы в приготовлениях было сказано: «Создать каталог “C:/MyData” с произвольным набором подкаталогов (глубина вложенности не менее пяти). В полученном дереве каталогов разместить 1000 файлов, из которых 200 имеют одинаковые имена и размеры, но НЕ внутрен- нее содержимое». Полное дублирование (копирование) одного и того же тест-кейса на уровнях дымового тестирования, тестирования критического пути, расши-ренного тестирования. Многие идеи естественным образом развиваются от уровня к уровню{79}, но они должны именно развиваться, а не дублироваться. Срав- ните: Дымовое тестиро-вание Тестирование критиче-ского пути Расширенное тестирование Плохо Запуск приложения. Запуск приложения. Запуск приложения. Хорошо Запуск приложения. Запуск приложения из ко- мандной строки. Запуск приложения через ярлык на рабочем столе. Запуск приложения через меню «Пуск». Запуск приложения из команд- ной строки в активном режиме. Запуск приложения из команд- ной строки в фоновом режиме. Запуск приложения через ярлык на рабочем столе от имени ад- министратора. Запуск приложения через меню «Пуск» из списка часто запуска- емых приложений. Слишком длинный перечень шагов, не относящихся к сути (цели) тест-кейса. Например, мы хотим проверить корректность одностороннего режима пе- чати из нашего приложения на дуплексном принтере. Сравните: Плохо Хорошо Односторонняя печать 1. Запустить приложение. 2. В меню выбрать «Файл» -> «Открыть». 3. Выбрать любой DOCX-файл, состоящий из нескольких страниц. 4. Нажать кнопку «Открыть». 5. В меню выбрать «Файл» -> «Печать». 6. В списке «Двусторонняя печать» выбрать пункт «Нет». 7. Нажать кнопку «Печать». 8. Закрыть файл. 9. Закрыть приложение. Односторонняя печать 1. Открыть любой DOCX-файл, содержащий три и более непустых страницы. 2. В диалоговом окне «Настройка печати» в списке «Двусторонняя печать» выбрать «Нет». 3. Произвести печать документа на принтере, поддерживающем двустороннюю печать. Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023Стр: 164/301 Слева мы видим огромное количество действий, не относящихся непосред- ственно к тому, что проверяет тест-кейс. Тем более что запуск и закрытие прило- жения, открытие файла, работа меню и прочее или будут покрыты другими тест- кейсами (со своими соответствующими целями), или на самом деле являются са- моочевидными (логично ведь, что нельзя открыть приложением файл, если прило- жение не запущено) и не нуждаются в описании шагов, которые только создают информационный шум и занимают время на написание и прочтение. Некорректное наименование элементов интерфейса или их свойств. Иногда из контекста понятно, что автор тест-кейса имел в виду, но иногда это ста- новится реальной проблемой. Например, мы видим тест-кейс с заглавием «Закры- тие приложения кнопками "Close" и "Close window"». Уже тут возникает недоумение по поводу того, в чём же различие этих кнопок, да и о чём вообще идёт речь. Ниже (в шагах тест-кейса) автор поясняет: «В рабочей панели внизу экрана нажать "Close window"». Ага! Ясно. Но «Close window» — это НЕ кнопка, это пункт системного кон- текстного меню приложения в панели задач. Ещё один отличный пример: «Окно приложения свернётся в окно меньшего диаметра». Хм. Окно круглое? Или должно стать круглым? А, может, тут и вовсе речь про два разных окна, и одно должно будет оказаться внутри второго? Или, всё же «размер окна уменьшается» (кстати, насколько?), а его геометрическая форма остаётся прямоугольной? И, наконец, пример, из-за которого вполне можно написать отчёт о дефекте на вполне корректно работающее приложение: «В системном меню выбрать “Фик- сация расположения”». Казалось бы, что ж тут плохого? Но потом выясняется, что имелось в виду главное меню приложения, а вовсе не системное меню. Непонимание принципов работы приложения и вызванная этим некор-ректность тест-кейсов. Классикой жанра является закрытие приложения: тот факт, что окно приложения «исчезло» (сюрприз: например, оно свернулось в об- ласть уведомления панели задач (system tray, taskbar notification area)), или прило- жение отключило интерфейс пользователя, продолжив функционировать в фоно- вом режиме, вовсе не является признаком того, что оно завершило работу. Проверка типичной «системной» функциональности. Если только ваше приложение не написано с использованием каких-то особенных библиотек и техно- логий и не реализует какое-то нетипичное поведение, нет необходимости прове- рять системные кнопки, системные меню, сворачивание-разворачивание окна и т.д. Вероятность встретить здесь ошибку стремится к нулю. Если всё же очень хочется, можно вписать эти проверки как уточнения некоторых действий на уровне тестиро- вания критического пути{80}, но создавать для них отдельные тест-кейсы не нужно. Неверное поведение приложения как ожидаемый результат. Такое не допускается по определению. Не может быть тест-кейса с шагом в стиле «поделить на ноль» с ожидаемым результатом «крах приложения с потерей пользовательских данных». Ожидаемые результаты всегда описывают правильное поведение прило- жения — даже в самых страшных стрессовых тест-кейсах. Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023Стр: 165/301 Общая некорректность тест-кейсов. Может быть вызвана множеством при- чин и выражаться множеством образов, но вот классический пример: Шаги выполнения Ожидаемые результаты … 4. Закрыть приложение нажатием Alt+F4. 5. Выбрать в меню «Текущее состояние». … 4. Приложение завершает работу. 5. Отображается окно с заголовком «Текущее состояние» и содержимым, соответствую- щим рисунку 999.99. Здесь или не указано, что вызов окна «Текущее состояние» происходит где- то в другом приложении, или остаётся загадкой, как вызвать это окно у завершив- шего работу приложения. Запустить заново? Возможно, но в тест-кейсе этого не сказано. Неверное разбиение наборов данных на классы эквивалентности. Дей- ствительно, иногда классы эквивалентности{94}могут быть очень неочевидными. Но ошибки встречаются и в довольно простых случаях. Допустим, в требованиях ска- зано, что размер некоего файла может быть от 10 до 100 КБ (включительно). Раз- биение по размеру 0–9 КБ, 10–100 КБ, 101+ КБ ошибочно, т.к. килобайт не явля- ется неделимой единицей. Такое ошибочное разбиение не учитывает, например, размеры в 9.5 КБ, 100.1 КБ, 100.7 КБ и т.д. Потому здесь стоит применять неравен- ства: 0 КБ ≤ размер < 10 КБ, 10 КБ ≤ размер ≤ 100 КБ, 100 КБ < размер. Также можно писать с использованием синтаксиса скобок: [0, 10) КБ, [10, 100] КБ, (100, ∞) КБ, но вариант с неравенствами более привычен большинству людей. Тест-кейсы, не относящиеся к тестируемому приложению. Например, нам нужно протестировать фотогалерею на сайте. Соответственно, следующие тест-кейсы никак не относятся к фотогалерее (они тестируют браузер, операцион- ную систему пользователя, файловый менеджер и т.д. — но НЕ наше приложение, ни его серверную, ни даже клиентскую часть): • Файл с сетевого диска. • Файл со съёмного носителя. • Файл, заблокированный другим приложением. • Файл, открытый другим приложением. • Файл, к которому у пользователя нет прав доступа. • Вручную указать путь к файлу. • Файл из глубоко расположенной поддиректории. Формальные и/или субъективные проверки. Чаще всего данную ошибку можно встретить в пунктах чек-листа. Возможно, у автора в голове и был чёткий и подробный план, но из следующих примеров совершенно невозможно понять, что будет сделано с приложением, и какой результат мы должны ожидать: • «Сконвертировать». • «Проверить метод getMessage()». • «Некорректная работа в корректных условиях». • «Скорость». • «Объём данных». • «Должно работать быстро». В отдельных исключительных ситуациях можно возразить, что из контекста и дальнейшей детализации становится понятно, что имелось в виду. Но чаще всего никакого контекста и никакой дальнейшей детализации нет, т.е. приведённые при- меры оформлены как отдельные полноправные пункты чек-листа. Так — нельзя. Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023Стр: 166/301 Как можно и нужно – см. в примере чек-листа{116}и всём соответствующем раз- деле{115}Теперь для лучшего закрепления рекомендуется заново прочитать про оформление атрибутов тест-кейсов{124}, свойства качественных тест-кейсов{136}и ло- гику построения{152}качественных тест-кейсов и качественных наборов тест-кейсов. Отчёты о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023Стр: 167/301 2.5. Отчёты о дефектах 2.5.1. Ошибки, дефекты, сбои, отказы и т.д. Упрощённый взгляд на понятие дефекта Далее в этой главе мы глубоко погрузимся в терминологию (она действи- тельно важна!), а потому начнём с очень простого: дефектом упрощённо можно счи- тать любое расхождение ожидаемого (свойства, результата, поведения и т.д., ко- торое мы ожидали увидеть) и фактического (свойства, результата, поведения и т.д., которое мы на самом деле увидели). При обнаружении дефекта создаётся отчёт о дефекте. Дефект — расхождение ожидаемого и фактического результата. Ожидаемый результат — поведение системы, описанное в требованиях. Фактический результат — поведение системы, наблюдаемое в процессе тестирования. ВАЖНО! Эти три определения приведены в предельно упрощённой (и даже искажённой) форме с целью первичного ознакомления. Полноцен- ные формулировки см. далее в этой же главе. Поскольку столь простая трактовка не покрывает все возможные формы про- явления проблем с программными продуктами, мы сразу же переходим к более по- дробному рассмотрению соответствующей терминологии. Расширенный взгляд на терминологию, описывающую проблемы Разберёмся с широким спектром синонимов, которыми обозначают про- блемы с программными продуктами и иными артефактами и процессами, сопут- ствующими их разработке. В силлабусе ISTQB написано308, что человек совершает ошибки, которые при- водят к возникновению дефектов в коде, которые, в свою очередь, приводят к сбоям и отказам приложения (однако сбои и отказы могут возникать и из-за внешних усло- вий, таких как электромагнитное воздействие на оборудование и т.д.). Таким образом, упрощённо можно изобразить следующую схему: Рисунок 2.5.a — Ошибки, дефекты, сбои и отказы 308 A human being can make an error (mistake), which produces a defect (fault, bug) in the program code, or in a document. If a defect in code is executed, the system may fail to do what it should do (or do something it shouldn't), causing a failure. Defects in software, systems or documents may result in failures, but not all defects do so. Defects occur because human beings are fallible and because there is time pressure, complex code, complexity of infrastructure, changing technologies, and/or many system interactions. Failures can be caused by environmental conditions as well. For example, radiation, magnetism, electronic fields, and pollution can cause faults in firmware or influence the execution of software by changing the hardware conditions. [ISTQB Syllabus] ОшибкаДефектСбой или отказ Ошибки, дефекты, сбои, отказы и т.д. Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023Стр: 168/301 Если же посмотреть на англоязычную терминологию, представленную в глоссарии ISTQB и иных источниках, можно построить чуть более сложную схему: Рисунок 2.5.b — Взаимосвязь проблем в разработке программных продуктов Рассмотрим все соответствующие термины. Ошибка (error309, mistake) — действие человека, приводящее к некоррект- ным результатам. Этот термин очень часто используют как наиболее универсальный, описыва- ющий любые проблемы («ошибка человека», «ошибка в коде», «ошибка в докумен- тации», «ошибка выполнения операции», «ошибка передачи данных», «ошибочный результат» и т.п.) Более того, куда чаще вы сможете услышать «отчёт об ошибке», чем «отчёт о дефекте». И это нормально, так сложилось исторически, к тому же термин «ошибка» на самом деле очень широкий. Дефект (defect310, bug, problem, fault) — недостаток в компоненте или си- стеме, способный привести к ситуации сбоя или отказа. Этот термин также понимают достаточно широко, говоря о дефектах в доку- ментации, настройках, входных данных и т.д. Почему глава называется именно «от- чёты о дефектах»? Потому что этот термин как раз стоит посередине — бессмыс- ленно писать отчёты о человеческих ошибках, равно как и почти бесполезно просто описывать проявления сбоев и отказов — нужно докопаться до их причины, и пер- вым шагом в этом направлении является именно описание дефекта. Сбой (interruption311) или отказ (failure312) — отклонение поведения си- стемы от ожидаемого. В ГОСТ 27.002-89 даны хорошие и краткие определения сбоя и отказа: Сбой — самоустраняющийся отказ или однократный отказ, устраняемый незначительным вмешательством оператора. Отказ — событие, заключающееся в нарушении работоспособного состо- яния объекта. Эти термины скорее относятся к теории надёжности и нечасто встречаются в повседневной работе тестировщика, но именно сбои и отказы являются тем, что тестировщик замечает в процессе тестирования (и отталкиваясь от чего, проводит исследование с целью выявить дефект и его причины). 309 Error, Mistake. A human action that produces an incorrect result. [ISTQB Glossary] 310 Defect, Bug, Problem, Fault. A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system. [ISTQB Glossary] 311 Interruption. A suspension of a process, such as the execution of a computer program, caused by an event external to that process and performed in such a way that the process can be resumed. [http://www.electropedia.org/iev/iev.nsf/display?open- form&ievref=714-22-10] 312 Failure. Deviation of the component or system from its expected delivery, service or result. [ISTQB Glossary] Error (Mistake)Defect(Problem, Bug, Fault)Failure, InterruptionAnomaly, Incident (Deviation) Ошибки, дефекты, сбои, отказы и т.д. Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023Стр: 169/301 1   ...   20   21   22   23   24   25   26   27   ...   38


Командные файлы для Windows и Linux
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 289/301
if [ -f "OUT/Картинка.jpg" ]
then
echo "ERROR! Picture file was processed!" >> smoke_test.log
else
echo "OK! Picture file was NOT processed!" >> smoke_test.log
fi
if [ -f "OUT/Картинка в виде TXT.txt" ]
then
echo "OK! Picture file with TXT extension was processed!" >> smoke_test.log
else
echo "ERROR! Picture file with TXT extension was NOT processed!" >> smoke_test.log
fi
if [ -f "OUT/Пустой файл.md" ]
then
echo "OK! Empty file was processed!" >> smoke_test.log
else
echo "ERROR! Empty file was NOT processed!" >> smoke_test.log
fi
# ===========================================================================
# ===========================================================================
# Проверка удаления из входного каталога файлов, которые должны быть обработаны,
# и неудаления файлов, которые не должны быть обработаны:
echo "" >> smoke_test.log
echo "Moving test:" >> smoke_test.log
if [ ! -f "IN/«Мелкий» файл в WIN1251.txt" ]
then
echo "OK! '«Мелкий» файл в WIN1251.txt' file was moved!" >> smoke_test.log
else
echo "ERROR! '«Мелкий» файл в WIN1251.txt' file was NOT moved!" >> smoke_test.log
fi
if [ ! -f "IN/«Средний» файл в CP866.txt" ]
then
echo "OK! '«Средний» файл в CP866.txt' file was moved!" >> smoke_test.log
else
echo "ERROR! '«Средний» файл в CP866.txt' file was NOT moved!" >> smoke_test.log
fi
if [ ! -f "IN/«Крупный» файл в KOI8R.txt" ]
then
echo "OK! '«Крупный» файл в KOI8R.txt' file was moved!" >> smoke_test.log
else
echo "ERROR! '«Крупный» файл в KOI8R.txt' file was NOT moved!" >> smoke_test.log
fi
if [ ! -f "IN/«Крупный» файл в win-1251.html" ]
then
echo "OK! '«Крупный» файл в win-1251.html' file was moved!" >> smoke_test.log
else
echo "ERROR! '«Крупный» файл в win-1251.html' file was NOT moved!" >> smoke_test.log
fi
if [ ! -f "IN/«Мелкий» файл в cp-866.html" ]
then
echo "OK! '«Мелкий» файл в cp-866.html' file was moved!" >> smoke_test.log
else
echo "ERROR! '«Мелкий» файл в cp-866.html' file was NOT moved!" >> smoke_test.log
fi
if [ ! -f "IN/«Средний» файл в koi8-r.html" ]
then
echo "OK! '«Средний» файл в koi8-r.html' file was moved!" >> smoke_test.log
else
echo "ERROR! '«Средний» файл в koi8-r.html' file was NOT moved!" >> smoke_test.log
fi
if [ ! -f "IN/«Средний» файл в WIN_1251.md" ]
then
echo "OK! '«Средний» файл в WIN_1251.md' file was moved!" >> smoke_test.log
else
echo "ERROR! '«Средний» файл в WIN_1251.md' file was NOT moved!" >> smoke_test.log
fi

Командные файлы для Windows и Linux
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 290/301
if [ ! -f "IN/«Крупный» файл в CP_866.md" ]
then
echo "OK! '«Крупный» файл в CP_866.md' file was moved!" >> smoke_test.log
else
echo "ERROR! '«Крупный» файл в CP_866.md' file was NOT moved!" >> smoke_test.log
fi
if [ ! -f "IN/«Мелкий» файл в KOI8_R.md" ]
then
echo "OK! '«Мелкий» файл в KOI8_R.md' file was moved!" >> smoke_test.log
else
echo "ERROR! '«Мелкий» файл в KOI8_R.md' file was NOT moved!" >> smoke_test.log
fi
if [ ! -f "IN/Слишком большой файл.txt" ]
then
echo "ERROR! 'Too big' file was moved!" >> smoke_test.log
else
echo "OK! 'Too big' file was NOT moved!" >> smoke_test.log
fi
if [ ! -f "IN/Картинка.jpg" ]
then
echo "ERROR! Picture file was moved!" >> smoke_test.log
else
echo "OK! Picture file was NOT moved!" >> smoke_test.log
fi
if [ ! -f "IN/Картинка в виде TXT.txt" ]
then
echo "OK! Picture file with TXT extension was moved!" >> smoke_test.log
else
echo "ERROR! Picture file with TXT extension was NOT moved!" >> smoke_test.log
fi
if [ ! -f "IN/Пустой файл.md" ]
then
echo "OK! Empty file was moved!" >> smoke_test.log
else
echo "ERROR! Empty file was NOT moved!" >> smoke_test.log
fi
# ===========================================================================
clear
# ===========================================================================
# Проверка конвертации файлов путём сравнения результатов
# работы приложения с эталонными файлами:
echo "" >> smoke_test.log
echo "Comparing test:" >> smoke_test.log
if cmp -s "Test_ETALON/«Мелкий» эталон WIN1251.txt" "OUT/«Мелкий» файл в WIN1251.txt"
then
echo "OK! File '«Мелкий» файл в WIN1251.txt' was processed correctly!" >> smoke_test.log
else
echo "ERROR! File '«Мелкий» файл в WIN1251.txt' was NOT processed correctly!" >> smoke_test.log
fi
if cmp -s "Test_ETALON/«Средний» эталон CP866.txt" "OUT/«Средний» файл CP866.txt"
then
echo "OK! File '«Средний» файл CP866.txt' was processed correctly!" >> smoke_test.log
else
echo "ERROR! File '«Средний» файл CP866.txt' was NOT processed correctly!" >> smoke_test.log
fi
if cmp -s "Test_ETALON/«Крупный» эталон KOI8R.txt" "OUT/«Крупный» файл KOI8R.txt"
then
echo "OK! File '«Крупный» файл KOI8R.txt' was processed correctly!" >> smoke_test.log
else
echo "ERROR! File '«Крупный» файл KOI8R.txt' was NOT processed correctly!" >> smoke_test.log
fi

Командные файлы для Windows и Linux
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 291/301
if cmp -s "Test_ETALON/«Крупный» файл в win-1251.html" "OUT/«Крупный» файл в win-1251.html"
then
echo "OK! File '«Крупный» файл в win-1251.html' was processed correctly!" >> smoke_test.log
else
echo "ERROR! File '«Крупный» файл в win-1251.html' was NOT processed correctly!" >> smoke_test.log
fi
if cmp -s "Test_ETALON/«Мелкий» эталон в cp-866.html" "OUT/«Мелкий» файл в cp-866.html"
then
echo "OK! File '«Мелкий» файл в cp-866.html' was processed correctly!" >> smoke_test.log
else
echo "ERROR! File '«Мелкий» файл в cp-866.html' was NOT processed correctly!" >> smoke_test.log
fi
if cmp -s "Test_ETALON/«Средний» эталон в koi8-r.html" "OUT/«Средний» файл в koi8-r.html"
then
echo "OK! File '«Средний» файл в koi8-r.html' was processed correctly!" >> smoke_test.log
else
echo "ERROR! File '«Средний» файл в koi8-r.html' was NOT processed correctly!" >> smoke_test.log
fi
if cmp -s "Test_ETALON/«Средний» эталон в WIN_1251.md" "OUT/«Средний» файл в WIN_1251.md"
then
echo "OK! File '«Средний» файл в WIN_1251.md' was processed correctly!" >> smoke_test.log
else
echo "ERROR! File '«Средний» файл в WIN_1251.md' was NOT processed correctly!" >> smoke_test.log
fi
if cmp -s "Test_ETALON/«Крупный» эталон в CP_866.md" "OUT/«Крупный» файл в CP_866.md"
then
echo "OK! File '«Крупный» файл в CP_866.md' was processed correctly!" >> smoke_test.log
else
echo "ERROR! File '«Крупный» файл в CP_866.md' was NOT processed correctly!" >> smoke_test.log
fi
if cmp -s "Test_ETALON/«Мелкий» эталон в KOI8_R.md" "OUT/«Мелкий» файл в KOI8_R.md"
then
echo "OK! File '«Мелкий» файл в KOI8_R.md' was processed correctly!" >> smoke_test.log
else
echo "ERROR! File '«Мелкий» файл в KOI8_R.md' was NOT processed correctly!" >> smoke_test.log
fi
if cmp -s "Test_ETALON/Пустой файл.md" "OUT/Пустой файл.md"
then
echo "OK! File 'Пустой файл.md' was processed correctly!" >> smoke_test.log
else
echo "ERROR! File 'Пустой файл.md' was NOT processed correctly!" >> smoke_test.log
fi
echo "WARNING! File 'Картинка в виде TXT.txt' has NO etalon decision, and it's OK for this file to
be corrupted." >> smoke_test.log
# ===========================================================================
Пример результатов выполнения (на одном из первых билдов, со-
держащих множество дефектов)
Processing test:
OK! '«Мелкий» файл в WIN1251.txt' file was processed!
OK! '«Средний» файл в CP866.txt' file was processed!
OK! '«Крупный» файл в KOI8R.txt' file was processed!
OK! '«Крупный» файл в win-1251.html' file was processed!
OK! '«Мелкий» файл в cp-866.html' file was processed!
OK! '«Средний» файл в koi8-r.html' file was processed!
OK! '«Средний» файл в WIN_1251.md' file was processed!
OK! '«Крупный» файл в CP_866.md' file was processed!
OK! '«Мелкий» файл в KOI8_R.md' file was processed!
OK! 'Too big' file was NOT processed!
OK! Picture file was NOT processed!
OK! Picture file with TXT extension was processed!
Moving test:
ERROR! '«Мелкий» файл в WIN1251.txt' file was NOT moved!
ERROR! '«Средний» файл в CP866.txt' file was NOT moved!
ERROR! '«Крупный» файл в KOI8R.txt' file was NOT moved!
ERROR! '«Крупный» файл в win-1251.html' file was NOT moved!
ERROR! '«Мелкий» файл в cp-866.html' file was NOT moved!
ERROR! '«Средний» файл в koi8-r.html' file was NOT moved!
ERROR! '«Средний» файл в WIN_1251.md' file was NOT moved!

Командные файлы для Windows и Linux
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 292/301
ERROR! '«Крупный» файл в CP_866.md' file was NOT moved!
ERROR! '«Мелкий» файл в KOI8_R.md' file was NOT moved!
OK! 'Too big' file was NOT moved!
OK! Picture file was NOT moved!
ERROR! Picture file with TXT extension was NOT moved!
Comparing test:
ERROR! File '«Мелкий» файл в WIN1251.txt' was NOT processed correctly!
ERROR! File '«Средний» файл в CP866.txt' was NOT processed correctly!
ERROR! File '«Крупный» файл в KOI8R.txt' was NOT processed correctly!
ERROR! File '«Крупный» файл в win-1251.html' was NOT processed correctly!
ERROR! File '«Мелкий» файл в cp-866.html' was NOT processed correctly!
ERROR! File '«Средний» файл в koi8-r.html' was NOT processed correctly!
ERROR! File '«Средний» файл в WIN_1251.md' was NOT processed correctly!
ERROR! File '«Крупный» файл в CP_866.md' was NOT processed correctly!
ERROR! File '«Мелкий» файл в KOI8_R.md' was NOT processed correctly!
OK! File 'Пустой файл.md' was processed correctly!
WARNING! File 'Картинка в виде TXT.txt' has NO etalon decision, and it's OK for this file to be
corrupted.

Пример данных для попарного тестирования
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 293/301
4.4.
Пример данных для попарного тестирования
№
Расположение /
длина / значение
/ комбинация
символов / заре-
зервированное
или свободное
Существо-
вание
Наличие прав доступа
Семейство
ОС
Коди-
ровки
1.
X:\
Да
К каталогу и его содержи- мому
Windows 64 bit
UTF8 2. smb://host/dir
Нет
Linux 32 bit
UTF16 3.
../dir
Да
Ни к каталогу, ни к его со- держимому
Linux 64 bit
OEM
4.
[257 байт только для Windows]
Да
Только к каталогу
Windows 64 bit
OEM
5. smb://host/dir/
Да
К каталогу и его содержи- мому
Linux 64 bit
UTF8 6. nul
Да
Ни к каталогу, ни к его со- держимому
Windows 64 bit
OEM
7.
\\
Нет
Linux 64 bit
UTF16 8.
/dir
Да
Ни к каталогу, ни к его со- держимому
Linux 32 bit
OEM
9.
./dir/
Нет
Linux 32 bit
OEM
10.
./dir
Нет
К каталогу и его содержи- мому
Linux 64 bit
UTF8 11. smb://host/dir
Да
Только к каталогу
Linux 64 bit
UTF8 12.
\\host\dir\
Да
К каталогу и его содержи- мому
Linux 32 bit
UTF8 13. host:/dir
Нет
Windows 32 bit
UTF8 14.
.\dir\
Нет
Windows 64 bit
UTF8 15.
[0 символов]
Нет
Windows 32 bit
UTF16 16.
[4097 байт только для Linux]
Нет
Linux 32 bit
UTF16 17.
..\dir\
Нет
Windows 32 bit
UTF16 18.
"/пробелы и рус- ский/"
Да
К каталогу и его содержи- мому
Windows 32 bit
OEM
19. smb://host/dir/
Да
Только к каталогу
Linux 32 bit
OEM
20. nul
Да
Windows 32 bit
UTF8 21.
"/пробелы и рус- ский"
Нет
Linux 32 bit
OEM
22. host:/dir/
Да
Только к каталогу
Windows 64 bit
UTF8 23.
../dir
Нет
Windows 64 bit
UTF16 24.
./dir/
Нет
Linux 64 bit
UTF16 25.
[257 байт только для Windows]
Нет
Windows 32 bit
UTF16 26.
"/пробелы и рус- ский/"
Нет
Linux 64 bit
UTF8 27.
Нет
Windows 32 bit
UTF8 28. host:/dir/
Нет
Linux 64 bit
OEM
29.
X:\dir\
Да
К каталогу и его содержи- мому
Windows 64 bit
UTF8

Пример данных для попарного тестирования
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 294/301 30.
\\
Да
Ни к каталогу, ни к его со- держимому
Windows 64 bit
UTF8 31.
//
Нет
Только к каталогу
Windows 64 bit
UTF8 32.
..\dir\
Нет
Ни к каталогу, ни к его со- держимому
Windows 64 bit
OEM
33.
X:\dir
Нет
Только к каталогу
Windows 64 bit
OEM
34.
"X:\
пробелы и рус- ский\"
Да
Только к каталогу
Windows 64 bit
UTF16 35.
\\host\dir\
Нет
Только к каталогу
Windows 32 bit
UTF16 36.
[256 байт только для Windows]
Да
К каталогу и его содержи- мому
Windows 32 bit
UTF8 37.
[4096 байт только для Linux]
Нет
Только к каталогу
Linux 64 bit
UTF16 38.
/dir/
Да
К каталогу и его содержи- мому
Linux 64 bit
UTF8 39.
[256 байт только для Windows]
Да
К каталогу и его содержи- мому
Windows 64 bit
OEM
40.
.\dir
Нет
К каталогу и его содержи- мому
Windows 32 bit
UTF16 41.
//
Да
Ни к каталогу, ни к его со- держимому
Windows 32 bit
OEM
42. prn
Да
Ни к каталогу, ни к его со- держимому
Windows 64 bit
UTF16 43.
..\dir
Нет
Ни к каталогу, ни к его со- держимому
Windows 64 bit
UTF16 44.
\\host\dir\
Нет
Только к каталогу
Windows 64 bit
UTF16 45.
../dir/
Да
Ни к каталогу, ни к его со- держимому
Linux 64 bit
UTF8 46.
Да
Только к каталогу
Linux 32 bit
OEM
47.
..\dir
Да
Только к каталогу
Windows 32 bit
UTF8 48.
/dir
Да
Только к каталогу
Linux 64 bit
UTF8 49.
"
Нет
Только к каталогу
Windows 32 bit
UTF8 50.
../dir/
Нет
К каталогу и его содержи- мому
Linux 32 bit
UTF16 51.
.\dir
Да
Только к каталогу
Windows 64 bit
OEM
52. host:/dir/
Нет
Ни к каталогу, ни к его со- держимому
Linux 32 bit
UTF16 53.
"/пробелы и рус- ский"
Нет
К каталогу и его содержи- мому
Linux 64 bit
UTF16 54. com1-com9
Да
Ни к каталогу, ни к его со- держимому
Windows 64 bit
UTF16 55. lpt1-lpt9
Да
Только к каталогу
Windows 32 bit
UTF8 56.
[0 символов]
Нет
Только к каталогу
Linux 64 bit
UTF16 57.
\\host\dir
Да
Ни к каталогу, ни к его со- держимому
Windows 32 bit
UTF16 58.
"X:\
пробелы и рус- ский"
Да
Только к каталогу
Windows 64 bit
UTF16 59.
\\host\dir
Нет
Только к каталогу
Linux 64 bit
UTF8 60. lpt1-lpt9
Да
Только к каталогу
Windows 64 bit
UTF8 61.
"X:\
пробелы и рус- ский"
Нет
К каталогу и его содержи- мому
Windows 32 bit
OEM

Пример данных для попарного тестирования
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 295/301 62. host:/dir
Да
К каталогу и его содержи- мому
Linux 32 bit
OEM
63.
X:\
Да
Только к каталогу
Windows 32 bit
OEM
64.
\\
Нет
Только к каталогу
Windows 32 bit
OEM
65.
[4096 байт только для Linux]
Да
К каталогу и его содержи- мому
Linux 32 bit
UTF8 66.
\\host\dir
Нет
К каталогу и его содержи- мому
Windows 64 bit
OEM
67.
"
Нет
Ни к каталогу, ни к его со- держимому
Linux 32 bit
OEM
68. con
Нет
К каталогу и его содержи- мому
Windows 32 bit
UTF16 69.
../dir
Нет
Только к каталогу
Linux 32 bit
UTF16 70.
X:\dir
Да
К каталогу и его содержи- мому
Windows 32 bit
OEM
71.
./dir
Да
К каталогу и его содержи- мому
Linux 32 bit
UTF16 72.
//
Да
К каталогу и его содержи- мому
Linux 32 bit
UTF16 73. host:/dir
Нет
Ни к каталогу, ни к его со- держимому
Linux 64 bit
UTF8 74.
/
Нет
К каталогу и его содержи- мому
Linux 64 bit
UTF8 75.
"X:\
пробелы и рус- ский\"
Да
Ни к каталогу, ни к его со- держимому
Windows 32 bit
OEM
76.
.\dir\
Да
Ни к каталогу, ни к его со- держимому
Windows 32 bit
OEM
77.
//
Нет
Только к каталогу
Linux 64 bit
OEM
78.
X:\dir\
Да
Только к каталогу
Windows 32 bit
UTF8 79.
"
Да
Ни к каталогу, ни к его со- держимому
Linux 64 bit
UTF16 80.
/
Да
К каталогу и его содержи- мому
Linux 32 bit
UTF16 81.
Да
К каталогу и его содержи- мому
Windows 64 bit
UTF16 82. com1-com9
Да
Ни к каталогу, ни к его со- держимому
Windows 32 bit
OEM
83.
Да
Ни к каталогу, ни к его со- держимому
Linux 64 bit
OEM
84.
/dir/
Да
К каталогу и его содержи- мому
Linux 32 bit
UTF16 85.
[4097 байт только для Linux]
Нет
К каталогу и его содержи- мому
Linux 64 bit
UTF16

Список основных определений
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 296/301
4.5.
Список основных определений
Для удобства поиска термины приведены в алфавитном порядке со ссыл- ками на то место в книге, где находится их подробное рассмотрение. Здесь пред- ставлены только самые важные, самые ключевые определения из двух с лишним сотен, что рассмотрены в книге.
Термин (по-
русски)
Термин (по-
английски)
Определение
Автоматизиро- ванное тести- рование
{76}
Automated test- ing
Набор техник, подходов и инструментальных средств, позволяющий исключить человека из выполнения некоторых задач в процессе тестирования.
Альфа-тести- рование
{84}
Alpha testing
Тестирование, которое выполняется внутри организации-разработчика с возможным ча- стичным привлечением конечных пользова- телей. Может являться формой внутреннего приёмочного тестирования.
Анализ перво- причин
{253}
Root cause analysis
Процесс исследования и классификации пер- вопричин возникновения событий, негативно влияющих на безопасность, здоровье, окру- жающую среду, качество, надёжность и про- изводственный процесс.
Бета-тестиро- вание
{84}
Beta testing
Тестирование, которое выполняется вне ор- ганизации-разработчика с активным привле- чением конечных пользователей/заказчиков.
Граничное условие
{237}
Border condi- tion, boundary condition
Значение, находящееся на границе классов эквивалентности.
Дефект
{169}
Defect, anomaly
Отклонение фактического результата от ожи- даний наблюдателя, сформированных на ос- нове требований, спецификаций, иной доку- ментации или опыта и здравого смысла.
Динамическое тестирова- ние
{73}
Dynamic testing
Тестирование с запуском кода на исполне- ние.
Дымовое те- стирование
{79}
Smoke test
Тестирование, которое направлено на про- верку самой главной, самой важной, самой ключевой функциональности, неработоспо- собность которой делает бессмысленной саму идею использования приложения (или иного объекта, подвергаемого дымовому те- стированию).

Список основных определений
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 297/301
Инспекция
(аудит) кода
{97}
Code review, code inspection
Семейство техник повышения качества кода за счёт того, что в процессе создания или со- вершенствования кода участвуют несколько человек. В отличие от техник статического анализа кода (по потоку управления и потоку данных), аудит кода также улучшает такие его характеристики как понятность, поддер- живаемость, соответствие соглашениям об оформлении и т.д. Аудит кода выполняется в основном самими программистами.
Интеграцион- ное тестирова- ние
{77}
Integration test- ing
Тестирование, которое направлено на про- верку взаимодействия между несколькими частями приложения (каждая из которых, в свою очередь, проверена отдельно на стадии модульного тестирования).
Класс эквива- лентности
{237}
Equivalence class
Набор данных, обрабатываемых одинаковым образом и приводящих к одинаковому ре- зультату.
Метод белого ящика
{73}
White box test- ing
Метод тестирования, в рамках которого у те- стировщика есть доступ к внутренней струк- туре и коду приложения, а также есть доста- точно знаний для понимания увиденного.
Метод серого ящика
{74}
Gray box testing
Комбинация методов белого ящика и чёрного ящика, состоящая в том, что к части кода и архитектуры у тестировщика доступ есть, а к части — нет. (См. пояснения по альтернатив- ному определению здесь:
{74}
.)
Метод чёрного ящика
{74}
Black box test- ing
Метод тестирования, в рамках которого у те- стировщика либо нет доступа к внутренней структуре и коду приложения, либо недоста- точно знаний для их понимания, либо он со- знательно не обращается к этим данным в процессе тестирования.
Метрика
{213}
Metric
Числовая характеристика показателя каче- ства. Может включать описание способов оценки и анализа результата.
Модель разра- ботки ПО
{18}
Software Devel- opment Model
Структура, систематизирующая различные виды проектной деятельности, их взаимодей- ствие и последовательность в процессе раз- работки ПО. Выбор той или иной модели за- висит от масштаба и сложности проекта, предметной области, доступных ресурсов и множества других факторов.
Модульное
(компонентное) тестирова- ние
{77}
Unit testing, component test- ing
Тестирование, направленное на проверку от- дельных небольших частей приложения, ко- торые (как правило) можно исследовать изо- лированно от других подобных частей.
Набор тест- кейсов
{146}
Test case suite, test suite, test set
Совокупность тест-кейсов, выбранных с неко- торой общей целью или по некоторому об- щему признаку.

Смотрите также файлы