Задание 2.4.e:
дополните этот список идеями, которые вы почерпнули из
других книг, статей и т.д.
Пример реализации логики создания эффективных проверок
Ранее мы составили подробный чек-лист
{115}
для тестирования нашего «Кон-
вертера файлов»
{60}
. Давайте посмотрим на него критически и подумаем: что можно
сократить, чем мы в итоге пожертвуем и какой выигрыш получим.
Прежде чем мы начнём оптимизировать чек-лист, важно отметить, что реше-
ние о том, что важно и что неважно, стоит принимать на основе ранжирования тре-
бований по важности, а также согласовывать с заказчиком.
Что для пользователя САМОЕ важное? Ради чего создавалось приложение?
Чтобы конвертировать файлы. Принимая во внимание тот факт, что настройку при-
ложения будет выполнять квалифицированный технический специалист, мы можем
даже «отодвинуть на второй план» реакцию приложения на ошибки стадии запуска
и завершения.
И на первое место выходит:
•
Обработка файлов, разные форматы, кодировки и размеры:
Таблица 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–2023
Стр: 155/301
Можем ли мы как-то ускорить выполнение этих проверок (ведь их много)?
Можем. И у нас даже есть два взаимодополняющих инструмента:
•
дальнейшая классификация по важности;
•
автоматизация тестирования.
Сначала поделим таблицу на две — чуть более важное и чуть менее важное.
В «чуть более важное» попадает:
Таблица 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–2023
Достарыңызбен бөлісу: |