Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
Ожидаемая реакция Запуск без параметров. Отображение инструкции к использованию. Запуск с недостаточным количеством парамет- ров. Отображение инструкции к использованию и указание имён недостающих параметров. Запуск с неверными значениями параметров: o Недопустимый путь SOURCE_DIR. o Недопустимый путь DESTINATION_DIR. o Недопустимое имя LOG_FILE_NAME. o DESTINATION_DIR находится внутри SOURCE_DIR. o Значения DESTINATION_DIR и SOURCE_DIR совпадают. Отображение инструкции к использованию и указание имени неверного параметра, значе- ния неверного параметра и пояснения сути проблемы. Недоступные входные файлы: o Нет прав доступа. o Файл открыт и заблокирован. o Файл с атрибутом «только для чтения». Отображение сообщения в консоль и файл журнала, дальнейшее игнорирование недо- ступных файлов. Журнал работы приложения: o Автоматическое создание (при отсутствии журнала), имя журнала указано явно. o Продолжение (дополнение журнала) при по- вторных запусках, имя журнала не указано. Создание или продолжение ведения файла журнала по указанному или вычисленному пути. 4) В случае наличия времени использовать первоначальную редакцию чек-ли- ста для уровня расширенного тестирования {78} как основу для выполнения ис- следовательского тестирования {82} И почти всё. Остаётся только ещё раз подчеркнуть, что представленная ло- гика выбора проверок не претендует на то, чтобы считаться единственно верной, но она явно позволяет сэкономить огромное количество усилий, при этом практи- чески не снизив качество тестирования наиболее востребованной заказчиком функ- циональности приложения. Задание 2.4.g: подумайте, какие проверки из таблицы 2.4.h можно авто- матизировать с помощью командных файлов. Напишите такие командные файлы. Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 157/298 2.4.8. Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов Ошибки оформления и формулировок Отсутствие заглавия тест-кейса или плохо написанное заглавие. В абсо- лютном большинстве систем управления тест-кейсами поле для заглавия вынесено отдельно и является обязательным к заполнению — тогда эта проблема отпадает. Если же инструментальное средство позволяет создать тест-кейс без заглавия, возникает риск получить N тест-кейсов, для понимания сути каждого из которых нужно прочитать десятки строк вместо одного предложения. Это гарантированное убийство рабочего времени и снижение производительности команды на порядок. Если заглавие тест-кейса приходится вписывать в поле с шагами и инстру- ментальное средство допускает форматирование текста, заглавие стоит писать жирным шрифтом, чтобы его было легче отделять от основного текста. Продолжением этой ошибки является создание одинаковых заглавий, по ко- торым объективно невозможно отличить один тест-кейс от другого. Более того, воз- никает подозрение, что одинаково озаглавленные тест-кейсы и внутри одинаковы. Потому следует формулировать заглавия по-разному, при этом подчёркивая в них суть тест-кейса и его отличие от других, похожих тест-кейсов. И, наконец, в заглавии недопустимы «мусорные слова» вида «проверка», «тест» и т.д. Ведь это заглавие тест-кейса, т.е. речь по определению идёт о про- верке, и не надо этот факт подчёркивать дополнительно. Также см. более подроб- ное пояснение этой ошибки ниже в пункте «Постоянное использование слов «про- верить» (и ему подобных) в чек-листах». Отсутствие нумерации шагов и/или ожидаемых результатов (даже если таковой всего лишь один). Наличие этой ошибки превращает тест-кейс в «поток со- знания», в котором нет структурированности, модифицируемости и прочих полез- ных свойств (да, многие свойства качественных требований {41} в полной мере при- менимы и к тест-кейсам) — становится очень легко перепутать, что к чему отно- сится. Даже выполнение такого тест-кейса усложняется, а доработка и вовсе пре- вращается в каторжный труд. Ссылка на множество требований. Иногда высокоуровневый тест-кейс {117} действительно затрагивает несколько требований, но в таком случае рекоменду- ется писать ссылку на максимум 2–3 самых ключевых (наиболее соответствующих цели тест-кейса), а ещё лучше — указывать общий раздел этих требований (т.е. не ссылаться, например, на требования 5.7.1, 5.7.2, 5.7.3, 5.7.7, 5.7.9, 5.7.12, а просто сослаться на раздел 5.7, включающий в себя все перечисленные пункты). В боль- шинстве инструментальных средств управления тест-кейсами это поле представ- ляет собой выпадающий список, и там эта проблема теряет актуальность. Использование личной формы глаголов. Если вы пишете требования на русском, то пишите «нажать» вместо «нажмите», «ввести» вместо «введите», «пе- рейти» вместо «перейдите» и т.д. В технической документации вообще не рекомен- дуется «переходить на личности», а также существует мнение, что личная форма глаголов подсознательно воспринимается как «чужие бессмысленные команды» и приводит к повышенной утомляемости и раздражительности. Использование прошедшего или будущего времени в ожидаемых ре- зультатах. Это не очень серьёзная ошибка, но всё равно «введённое значение отображается в поле» читается лучше, чем «введённое значение отобразилось в поле» или «введённое значение отобразится в поле». Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 158/298 Постоянное использование слов «проверить» (и ему подобных) в чек- листах. В итоге почти каждый пункт чек-листа начинается с «проверить …», «про- верить…», «проверить…». Но ведь весь чек-лист — это и есть список проверок! Зачем писать это слово? Сравните: Плохо Хорошо Проверить запуск приложения. Проверить открытие корректного файла. Проверить модификацию файла. Проверить сохранение файла. Проверить закрытие приложения. Запуск приложения. Открытие корректного файла. Модификация файла. Сохранение файла. Закрытие приложения. Сюда же относится типичное слово «попытаться» в негативных тест-кейсах («попытаться поделить на ноль», «попытаться открыть несуществующий файл», «попытаться ввести недопустимые символы»): «деление на ноль», «открытие не- существующего файла», «ввод спецсимволов» намного короче и информативнее. А реакцию приложения, если она не очевидна, можно указать в скобках (так будет даже информативнее): «деление на ноль» (сообщение «Division by zero detected»), «открытие несуществующего файла» (приводит к автоматическому созданию файла), «ввод спецсимволов» (символы не вводятся, отображается подсказка). Описание стандартных элементов интерфейса вместо использования их устоявшихся названий. «Маленький крестик справа вверху окна приложения» — это системная кнопка «Закрыть» (system button «Close»), «быстро-быстро два- жды нажать на левую клавишу мыши» — это двойной щелчок (double click), «ма- ленькое окошечко с надписью появляется, когда наводишь мышь» — это всплыва- ющая подсказка (hint). Пунктуационные, орфографические, синтаксические и им подобные ошибки. Без комментариев. Логические ошибки Ссылка на другие тест-кейсы или шаги других тест-кейсов. За исключе- нием случаев написания строго оговорённого явно обозначенного набора последо- вательных тест-кейсов {145} это запрещено делать. В лучшем случае вам повезёт, и тест-кейс, на который вы ссылались, будет просто удалён — повезёт потому, что это будет сразу заметно. Не повезёт в случае, если тест-кейс, на который вы ссы- лаетесь, будет изменён — ссылка по-прежнему ведёт в некое существующее ме- сто, но описано там уже совершенно не то, что было в момент создания ссылки. Детализация, не соответствующая уровню функционального тестиро- вания {76} . Например, не нужно на уровне дымового тестирования {76} проверять ра- ботоспособность каждой отдельной кнопки или прописывать некий крайне слож- ный, нетривиальный и редкий сценарий — поведение кнопок и без явного указания будет проверено множеством тест-кейсов, объективно задействующих эти кнопки, а сложному сценарию место на уровне тестирования критического пути {77} или даже на уровне расширенного тестирования {78} (в которых, напротив, недостатком можно считать излишнее обобщение без должной детализации). Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 159/298 Расплывчатые двусмысленные описания действий и ожидаемых ре- зультатов. Помните, что тест-кейс с высокой вероятностью будете выполнять не вы (автор тест-кейса), а другой сотрудник, и он — не телепат. Попробуйте дога- даться по этим примерам, что имел в виду автор: • «Установить приложение на диск C». (Т.е. в «C:\»? Прямо в корень? Или как?) • «Нажать на иконку приложения». (Например, если у меня есть ico-файл с иконкой приложения, и я по нему кликну — это оно? Или нет?) • «Окно приложения запустится». (Куда?) • «Работает верно». (Ого! А верно — это, простите, как?) • «OK». (И? Что «OK»?) • «Количество найденных файлов совпадает». (С чем?) • «Приложение отказывается выполнять команду». (Что значит «отказыва- ется»? Как это выглядит? Что должно происходить?) Описание действий в качестве наименований модуля/подмодуля. Например, «запуск приложения» — это НЕ модуль или подмодуль. Модуль или под- модуль {122} — это всегда некие части приложения, а не его поведение. Сравните: «дыхательная система» — это модуль человека, но «дыхание» — нет. Описание событий или процессов в качестве шагов или ожидаемых ре- зультатов. Например, в качестве шага сказано: «Ввод спецсимволов в поле X». Это было бы сносным заглавием тест-кейса, но не годится в качестве шага, который должен быть сформулирован как «Ввести спецсимволы (перечень) в поле X». Куда страшнее, если подобное встречается в ожидаемых результатах. Например, там написано: «Отображение скорости чтения в панели X». И что? Оно должно начаться, продолжиться, завершиться, не начинаться, неким образом из- мениться (например, измениться должна размерность данных), как-то на что-то по- влиять? Тест-кейс становится полностью бессмысленным, т.к. такой ожидаемый результат невозможно сравнить с фактическим поведением приложения. «Выдумывание» особенностей поведения приложения. Да, часто в тре- бованиях отсутствуют самоочевидные (без кавычек, они на самом деле самооче- видные) вещи, но нередко встречаются и некачественные (например, неполные) требования, которые нужно улучшать, а не «телепатически компенсировать». Например, в требованиях сказано, что «приложение должно отображать диа- логовое окно сохранения с указанным по умолчанию каталогом». Если из контекста (соседних требований, иных документов) ничего не удаётся узнать об этом таин- ственном «каталоге по умолчанию», нужно задать вопрос. Нельзя просто записать в ожидаемых результатах «отображается диалоговое окно сохранения с указанным по умолчанию каталогом» (как мы проверим, что выбран именно указанный по умолчанию каталог, а не какой-то иной?). И уж тем более нельзя в ожидаемых ре- зультатах писать «отображается диалоговое окно сохранения с выбранным ката- логом “C:/SavedDocuments”» (откуда взялось это «C:/SavedDocuments», — не ясно, т.е. оно явно выдумано из головы и, скорее всего, выдумано неправильно). Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 160/298 Отсутствие описания приготовления к выполнению тест-кейса. Часто для корректного выполнения тест-кейса необходимо каким-то особым образом настроить окружение. Предположим, что мы проверяем приложение, выполняющее резервное копирование файлов. Если тест выглядит примерно так, то выполняю- щий его сотрудник будет в замешательстве, т.к. ожидаемый результат кажется про- сто бредом. Откуда взялось «200»? Что это вообще такое? Шаги выполнения Ожидаемые результаты 1. Нажать на панели «Главная» кнопку «Быст- рая дедубликация». 2. Выбрать каталог «C:/MyData». 1. Кнопка «Быстрая дедубликация» переходит в утопленное состояние и меняет цвет с се- рого на зелёный. 2. На панели «Состояние» в поле «Дубли- каты» отображается «200». И совсем иначе этот тест-кейс воспринимался бы, если бы в приготовлениях было сказано: «Создать каталог “C:/MyData” с произвольным набором подкаталогов (глубина вложенности не менее пяти). В полученном дереве каталогов разместить 1000 файлов, из которых 200 имеют одинаковые имена и размеры, но НЕ внутрен- нее содержимое». Полное дублирование (копирование) одного и того же тест-кейса на уровнях дымового тестирования, тестирования критического пути, расши- ренного тестирования. Многие идеи естественным образом развиваются от уровня к уровню {76} , но они должны именно развиваться, а не дублироваться. Срав- ните: Дымовое тестиро- вание Тестирование критиче- ского пути Расширенное тестирование Плохо Запуск приложения. Запуск приложения. Запуск приложения. Хорошо Запуск приложения. Запуск приложения из ко- мандной строки. Запуск приложения через ярлык на рабочем столе. Запуск приложения через меню «Пуск». Запуск приложения из команд- ной строки в активном режиме. Запуск приложения из команд- ной строки в фоновом режиме. Запуск приложения через ярлык на рабочем столе от имени ад- министратора. Запуск приложения через меню «Пуск» из списка часто запуска- емых приложений. Слишком длинный перечень шагов, не относящихся к сути (цели) тест- кейса. Например, мы хотим проверить корректность одностороннего режима пе- чати из нашего приложения на дуплексном принтере. Сравните: Плохо Хорошо Односторонняя печать 1. Запустить приложение. 2. В меню выбрать «Файл» -> «Открыть». 3. Выбрать любой DOCX-файл, состоящий из нескольких страниц. 4. Нажать кнопку «Открыть». 5. В меню выбрать «Файл» -> «Печать». 6. В списке «Двусторонняя печать» выбрать пункт «Нет». 7. Нажать кнопку «Печать». 8. Закрыть файл. 9. Закрыть приложение. Односторонняя печать 1. Открыть любой DOCX-файл, содержащий три и более непустых страницы. 2. В диалоговом окне «Настройка печати» в списке «Двусторонняя печать» выбрать «Нет». 3. Произвести печать документа на принтере, поддерживающем двустороннюю печать. Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 161/298 Слева мы видим огромное количество действий, не относящихся непосред- ственно к тому, что проверяет тест-кейс. Тем более что запуск и закрытие прило- жения, открытие файла, работа меню и прочее или будут покрыты другими тест- кейсами (со своими соответствующими целями), или на самом деле являются са- моочевидными (логично ведь, что нельзя открыть приложением файл, если прило- жение не запущено) и не нуждаются в описании шагов, которые только создают информационный шум и занимают время на написание и прочтение. Некорректное наименование элементов интерфейса или их свойств. Иногда из контекста понятно, что автор тест-кейса имел в виду, но иногда это ста- новится реальной проблемой. Например, мы видим тест-кейс с заглавием «Закры- тие приложения кнопками "Close" и "Close window"». Уже тут возникает недоумение по поводу того, в чём же различие этих кнопок, да и о чём вообще идёт речь. Ниже (в шагах тест-кейса) автор поясняет: «В рабочей панели внизу экрана нажать "Close window "». Ага! Ясно. Но «Close window» — это НЕ кнопка, это пункт системного кон- текстного меню приложения в панели задач. Ещё один отличный пример: «Окно приложения свернётся в окно меньшего диаметра». Хм. Окно круглое? Или должно стать круглым? А, может, тут и вовсе речь про два разных окна, и одно должно будет оказаться внутри второго? Или, всё же «размер окна уменьшается» (кстати, насколько?), а его геометрическая форма остаётся прямоугольной? И, наконец, пример, из-за которого вполне можно написать отчёт о дефекте на вполне корректно работающее приложение: «В системном меню выбрать “Фик- сация расположения”». Казалось бы, что ж тут плохого? Но потом выясняется, что имелось в виду главное меню приложения, а вовсе не системное меню. Непонимание принципов работы приложения и вызванная этим некор- ректность тест-кейсов. Классикой жанра является закрытие приложения: тот факт, что окно приложения «исчезло» (сюрприз: например, оно свернулось в об- ласть уведомления панели задач (system tray, taskbar notification area)), или прило- жение отключило интерфейс пользователя, продолжив функционировать в фоно- вом режиме, вовсе не является признаком того, что оно завершило работу. Проверка типичной «системной» функциональности. Если только ваше приложение не написано с использованием каких-то особенных библиотек и техно- логий и не реализует какое-то нетипичное поведение, нет необходимости прове- рять системные кнопки, системные меню, сворачивание-разворачивание окна и т.д. Вероятность встретить здесь ошибку стремится к нулю. Если всё же очень хочется, можно вписать эти проверки как уточнения некоторых действий на уровне тестиро- вания критического пути {77} , но создавать для них отдельные тест-кейсы не нужно. Неверное поведение приложения как ожидаемый результат. Такое не допускается по определению. Не может быть тест-кейса с шагом в стиле «поделить на ноль» с ожидаемым результатом «крах приложения с потерей пользовательских данных». Ожидаемые результаты всегда описывают правильное поведение прило- жения — даже в самых страшных стрессовых тест-кейсах. |