Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
Логика создания эффективных проверок Теперь, когда мы рассмотрели принципы построения чек-листов {112} и оформ- ления тест-кейсов {121} , свойства качественных тест-кейсов {133} , а также принципы объ- единения тест-кейсов в наборы {147} , настало время перейти к самой сложной, «фи- лософской» части, в которой мы будем рассуждать уже не о том, что и как писать, а о том, как думать. Ранее уже было сказано: если у тест-кейса не указаны входные данные, условия выполнения и ожидаемые результаты, и/или не ясна цель тест-кейса — это плохой тест-кейс. И здесь во главе угла стоит цель. Если мы чётко понимаем, что и зачем мы делаем, мы или быстро находим всю остальную недостающую ин- формацию, или столь же быстро формулируем правильные вопросы и адресуем их правильным людям. Вся суть работы тестировщика в конечном итоге направлена на повышение качества (процессов, продуктов и т.д.). Но что такое качество? Да, существует сухое официальное определение 305 , но даже там сказано про «user/customer needs and expectations » (потребности и ожидания пользователя/заказчика). И здесь проявляется главная мысль: качество — это некая ценность для конечного пользователя (заказчика). Человек в любом случае платит за исполь- зование продукта — деньгами, своим временем, какими-то усилиями (даже если вы не получаете эту «оплату», человек вполне обоснованно считает, что что-то уже на вас потратил, и он прав). Но получает ли он то, на что рассчитывал (предположим, что его ожидания — здравы и реалистичны)? Если мы подходим к тестированию формально, мы рискуем получить про- дукт, который по документам (метрикам и т.д.) выглядит идеально, но в реальности никому не нужен. Поскольку практически любой современный программный продукт представ- ляет собой непростую систему, среди широкого множества её свойств и функций объективно есть самые важные, менее важные и совсем незначительные по важ- ности для пользователей. Если усилия тестировщиков будут сконцентрированы на первой и второй ка- тегории (самом важном и чуть менее важном), наши шансы создать приложение, удовлетворяющее заказчика, резко увеличиваются. Есть простая логика: • Тесты ищут ошибки. • Но все ошибки найти невозможно. • Значит, наша задача — найти максимум ВАЖНЫХ ошибок за имеющееся время. Под важными ошибками здесь мы понимаем такие, которые приводят к нару- шению важных для пользователя функций или свойств продукта. Функции и свой- ства разделены не случайно — безопасность, производительность, удобство и т.д. не относятся к функциям, но играют ничуть не менее важную роль в формировании удовлетворённости заказчика и конечных пользователей. Ситуация усугубляется следующими фактами: • в силу множества экономических и технических причин мы не можем выпол- нить «все тесты, что придут нам в голову» (да ещё и многократно) — прихо- дится тщательно выбирать, что и как мы будем тестировать, принимая во внимание только что упомянутую мысль: качество — это некая ценность для конечного пользователя (заказчика); 305 Quality. The degree to which a component, system or process meets specified requirements and/or user/customer needs and expectations. [ISTQB Glossary] Логика создания эффективных проверок Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 150/298 • никогда в реальной жизни (как бы мы ни старались) мы не получим «совер- шенного и идеального набора требований» — там всегда будет некоторое количество недоработок, и это тоже надо принимать во внимание. Однако существует достаточно простой алгоритм, позволяющий нам созда- вать эффективные проверки даже в таких условиях. Приступая к продумыванию чек-листа, тест-кейса или набора тест-кейсов, задайте себе следующие вопросы и получите чёткие ответы: • Что перед вами? Если вы не понимаете, что вам предстоит тестировать, вы не уйдёте дальше бездумных формальных проверок. • Кому и зачем оно нужно (и насколько это важно)? Ответ на этот вопрос поз- волит вам быстро придумать несколько характерных сценариев использова- ния {143} того, что вы собираетесь тестировать. • Как оно обычно используется? Это уже детализация сценариев и источник идей для позитивного тестирования {79} (их удобно оформить в виде чек-ли- ста). • Как оно может сломаться, т.е. начать работать неверно? Это также детали- зация сценариев использования, но уже в контексте негативного тестирова- ния {79} (их тоже удобно оформить в виде чек-листа). К этому алгоритму можно добавить ещё небольшой перечень универсальных рекомендаций, которые позволят вам проводить тестирование лучше: • Начинайте как можно раньше — уже с момента появления первых требова- ний можно заниматься их тестированием и улучшением, можно писать чек- листы и тест-кейсы, можно уточнять план тестирования, готовить тестовое окружение и т.д. • Если вам предстоит тестировать что-то большое и сложное, разбивайте его на модули и подмодули, функциональность подвергайте функциональной декомпозиции 306 — т.е. добейтесь такого уровня детализации, при котором вы можете без труда удержать в голове всю информацию об объекте тести- рования. • Обязательно пишите чек-листы. Если вам кажется, что вы сможете запом- нить все идеи и потом легко их воспроизвести, вы ошибаетесь. Исключений не бывает. • По мере создания чек-листов, тест-кейсов и т.д. прямо в текст вписывайте возникающие вопросы. Когда вопросов накопится достаточно, соберите их отдельно, уточните формулировки и обратитесь к тому, кто может дать от- веты. • Если используемое вами инструментальное средство позволяет использо- вать косметическое оформление текста — используйте (так текст будет лучше читаться), но старайтесь следовать общепринятым традициям и не раскрашивать каждое второе слово в свой цвет, шрифт, размер и т.д. • Используйте технику беглого просмотра {48} для получения отзыва от коллег и улучшения созданного вами документа. • Планируйте время на улучшение тест-кейсов (исправление ошибок, дора- ботку по факту изменения требований и т.д.). • Начинайте проработку (и выполнение) тест-кейсов с простых позитивных проверок наиболее важной функциональности. Затем постепенно повы- шайте сложность проверок, помня не только о позитивных {79} , но и о негатив- ных {79} проверках. 306 «Functional decomposition», Wikipedia [ http://en.wikipedia.org/wiki/Functional_decomposition ] Логика создания эффективных проверок Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 151/298 • Помните, что в основе тестирования лежит цель. Если вы не можете быстро и просто сформулировать цель созданного вами тест-кейса, вы создали пло- хой тест-кейс. • Избегайте избыточных, дублирующих друг друга тест-кейсов. Минимизиро- вать их количество вам помогут техники классов эквивалентности {91} , гранич- ных условий {92} , доменного тестирования {92} • Если показательность {137} тест-кейса можно увеличить, при этом не сильно изменив его сложность и не отклонившись от исходной цели, сделайте это. • Помните, что очень многие тест-кейсы требуют отдельной подготовки, кото- рую нужно описать в соответствующем поле тест-кейса. • Несколько позитивных тест-кейсов {79} можно безбоязненно объединять, но объединение негативных тест-кейсов {79} почти всегда запрещено. • Подумайте, как можно оптимизировать созданный вами тест-кейс (набор тест-кейсов и т.д.) так, чтобы снизить трудозатраты на его выполнение. • Перед тем как отправлять финальную версию созданного вами документа, ещё раз перечитайте написанное (в доброй половине случаев найдёте опе- чатку или иную недоработку). Задание 2.4.e: дополните этот список идеями, которые вы почерпнули из других книг, статей и т.д. Пример реализации логики создания эффективных проверок Ранее мы составили подробный чек-лист {112} для тестирования нашего «Кон- вертера файлов» {57} . Давайте посмотрим на него критически и подумаем: что можно сократить, чем мы в итоге пожертвуем и какой выигрыш получим. Прежде чем мы начнём оптимизировать чек-лист, важно отметить, что реше- ние о том, что важно и что неважно, стоит принимать на основе ранжирования тре- бований по важности, а также согласовывать с заказчиком. Что для пользователя САМОЕ важное? Ради чего создавалось приложение? Чтобы конвертировать файлы. Принимая во внимание тот факт, что настройку при- ложения будет выполнять квалифицированный технический специалист, мы можем даже «отодвинуть на второй план» реакцию приложения на ошибки стадии запуска и завершения. И на первое место выходит: • Обработка файлов, разные форматы, кодировки и размеры: Таблица 2.4.d — Форматы, кодировки и размеры файлов Форматы входных файлов TXT HTML MD Кодировки входных фай- лов WIN1251 100 КБ 50 МБ 10 МБ CP866 10 МБ 100 КБ 50 МБ KOI8R 50 МБ 10 МБ 100 КБ Любая 0 байт Любая 50 МБ + 1 Б 50 МБ + 1 Б 50 МБ + 1 Б - Любой недопустимый формат Любая Повреждения в допустимом формате Логика создания эффективных проверок Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 152/298 Можем ли мы как-то ускорить выполнение этих проверок (ведь их много)? Можем. И у нас даже есть два взаимодополняющих инструмента: • дальнейшая классификация по важности; • автоматизация тестирования. Сначала поделим таблицу на две — чуть более важное и чуть менее важное. В «чуть более важное» попадает: Таблица 2.4.e — Форматы, кодировки и размеры файлов Форматы входных файлов TXT HTML MD Кодировки входных фай- лов WIN1251 100 КБ 50 МБ 10 МБ CP866 10 МБ 100 КБ 50 МБ KOI8R 50 МБ 10 МБ 100 КБ Подготовим 18 файлов — 9 исходных + 9 сконвертированных (в любом тек- стовом редакторе с функцией конвертации кодировок), чтобы в дальнейшем сравнивать работу нашего приложения с эталоном. Для «чуть менее важного» осталось: • Файл размером 0 байт (объективно для него не важна такая характеристика, как «кодировка»). Подготовим один файл размером 0 байт. • Файл размером 50 МБ + 1 Б (для него тоже не важна кодировка). Подготовим один файл размером 52’428’801 байт. • Любой недопустимый формат: o По расширению (файл с расширением, отличным от .txt, .html, .md). Берём любой произвольный файл, например картинку (размер от 1 до 50 МБ, расширение .jpg). o По внутреннему содержанию (например, .jpg переименовали в .txt). Ко- пии файла из предыдущего пункта даём расширение .txt. • Повреждения в допустимом формате. Вычёркиваем. Вообще. Даже крайне сложные дорогие редакторы далеко не всегда способны восстановить по- вреждённые файлы своих форматов, наше же приложение — это просто миниатюрная утилита конвертации кодировок, и не стоит ждать от неё возможностей профессионального инструментального средства восста- новления данных. Что мы получили в итоге? Нам нужно подготовить следующие 22 файла (по- скольку у файлов всё равно есть имена, усилим этот набор тестовых данных, пред- ставив в именах файлов символы латиницы, кириллицы и спецсимволы). Логика создания эффективных проверок Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 153/298 Таблица 2.4.f — Итоговый набор файлов для тестирования приложения № Имя Кодировка Размер 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 - 1 МБ И только что мы упомянули автоматизацию как способ ускорения выполне- ния тест-кейсов. В данном случае мы можем обойтись самыми тривиальными ко- мандными файлами. В приложении «Командные файлы для Windows и Linux, авто- матизирующие выполнение дымового тестирования» {281} приведены скрипты, пол- ностью автоматизирующие выполнение всего уровня дымового тестирования {76} над представленным выше набором из 22 файлов. Задание 2.4.f: доработайте представленные в приложении {281} командные файлы так, чтобы их выполнение заодно проверяло работу тестируемого приложения с пробелами, кириллическими символами и спецсимволами в путях к входному каталогу, выходному каталогу и файлу журнала. Опти- мизируйте получившиеся командные файлы так, чтобы избежать много- кратного дублирования кода. Если снова вернуться к чек-листу, то оказывается, что мы уже подготовили проверки для всего уровня дымового тестирования {76} и части уровня тестирования критического пути {77} Продолжим оптимизацию. Большинство проверок не представляет особой сложности, и мы разберёмся с ними по ходу дела, но есть в чек-листе пункт, вызы- вающий особую тревогу: производительность. Тестирование и оптимизация производительности {88} — это отдельный вид тестирования со своими достаточно непростыми правилами и подходами, к тому же разделяющийся на несколько подвидов. Нужно ли оно нам в нашем приложе- нии? Заказчик в АК-1.1 определил минимальную производительность приложения как способность обрабатывать входные данные со скоростью не менее 5 МБ/сек. Грубые эксперименты на указанном в АК-1.1 оборудовании показывают, что даже куда более сложные операции (например, архивирование видеофайла с макси- мальной степенью сжатия) выполняются быстрее (пусть и ненамного). Вывод? Вы- чёркиваем. Вероятность встретить здесь проблему ничтожно мала, а соответству- Логика создания эффективных проверок Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 154/298 ющее тестирование требует ощутимых затрат сил и времени, а также наличия со- ответствующих специалистов. Вернёмся к чек-листу: • Конфигурирование и запуск: o С верными параметрами: ▪ Значения SOURCE_DIR, DESTINATION_DIR, LOG_FILE_NAME указаны и содержат пробелы и кириллические символы (повто- рить для форматов путей в Windows и *nix файловых системах, обратить внимание на имена логических дисков и разделители имён каталогов (“/” и “\”)). (Уже учтено при автоматизации про- верки работы приложения с 22 файлами.) ▪ Значение LOG_FILE_NAME не указано. (Объединить с про- веркой ведения самого файла журнала.) o Без параметров. o С недостаточным количеством параметров. o С неверными параметрами: ▪ Недопустимый путь SOURCE_DIR. ▪ Недопустимый путь DESTINATION_DIR. ▪ Недопустимое имя LOG_FILE_NAME. ▪ DESTINATION_DIR находится внутри SOURCE_DIR. ▪ Значения DESTINATION_DIR и SOURCE_DIR совпадают. • Обработка файлов: o Разные форматы, кодировки и размеры. (Уже сделано.) o Недоступные входные файлы: ▪ Нет прав доступа. ▪ Файл открыт и заблокирован. ▪ Файл с атрибутом «только для чтения». • Остановка: o Закрытием окна консоли. (Вычёркиваем. Не настолько важная про- верка, а если и будут проблемы — технология PHP не позволит их решить.) • Журнал работы приложения: o Автоматическое создание (при отсутствии журнала), имя журнала ука- зано явно. o Продолжение (дополнение журнала) при повторных запусках, имя жур- нала не указано. • Производительность: o Элементарный тест с грубой оценкой. (Ранее решили, что наше при- ложение явно уложится в весьма демократичные требования за- казчика.) Перепишем компактно то, что у нас осталось от уровня тестирования крити- ческого пути {77} . Внимание! Это — НЕ тест-кейс! Это всего лишь ещё одна форма записи чек-листа, более удобная на данном этапе. Логика создания эффективных проверок Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 155/298 Таблица 2.4.g — Чек-лист для уровня критического пути Суть проверки Ожидаемая реакция Запуск без параметров. Отображение инструкции к использованию. Запуск с недостаточным количеством парамет- ров. Отображение инструкции к использованию и указание имён недостающих параметров. Запуск с неверными значениями параметров: 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 Продолжение (дополнение журнала) при повторных запусках, имя журнала не ука- зано. Создание или продолжение ведения файла журнала по указанному или вычисленному пути. Наконец, у нас остался уровень расширенного тестирования {78} И сейчас мы сделаем то, чего по всем классическим книгам учат не делать, — мы откажемся от всего этого набора проверок целиком. • Конфигурирование и запуск: o Значения SOURCE_DIR, DESTINATION_DIR, LOG_FILE_NAME: ▪ В разных стилях (Windows-пути + *nix-пути) — одно в одном стиле, другое — в другом. ▪ С использованием UNC-имён. ▪ LOG_FILE_NAME внутри SOURCE_DIR. ▪ LOG_FILE_NAME внутри DESTINATION_DIR. o Размер LOG_FILE_NAME на момент запуска: ▪ 2 –4 ГБ. ▪ 4+ ГБ. o Запуск двух и более копий приложения с: ▪ Одинаковыми параметрами SOURCE_DIR, DESTINATION_DIR, LOG_FILE_NAME. ▪ Одинаковыми SOURCE_DIR и LOG_FILE_NAME, но разными DESTINATION_DIR. ▪ Одинаковыми DESTINATION_DIR и LOG_FILE_NAME, но раз- ными SOURCE_DIR. • Обработка файлов: o Файл верного формата, в котором текст представлен в двух и более поддерживаемых кодировках одновременно. o Размер входного файла: ▪ 2 –4 ГБ. ▪ 4+ ГБ. Да, мы сейчас действительно повысили риск пропустить какой-то дефект. Но — дефект, вероятность возникновения которого мала в силу малой вероятности возникновения описанных в этих проверках ситуаций. При этом по самым скромным Логика создания эффективных проверок Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 156/298 прикидкам мы на треть сократили общее количество проверок, которые нам нужно будет выполнять, а значит — высвободили силы и время для более тщательной проработки типичных каждодневных сценариев использования {143} приложения. Весь оптимизированный чек-лист (он же — и черновик для плана выполнения проверок) теперь выглядит так: 1) Подготовить файлы (см. таблицу 2.4.f). 2) Для «дымового теста» использовать командные файлы (см. приложение «Ко- мандные файлы для Windows и Linux, автоматизирующие выполнение дымо- вого тестирования» {281} ). 3) Для основных проверок использовать файлы из пункта 1 и следующие идеи ( таблица 2.4.h). Таблица 2.4.h — Основные проверки для приложения «Конвертер файлов» |