Мнемоника Bmw Для Поиска Предельных Значений



Содержание

Мнемоника – это слово или фраза, которые помогают нам что-то запомнить.

Самая известная мнемоника – «каждый охотник хочет знать, где сидит фазан».

Кого ни спроси, все ее знают. А вот в профессиональной сфере все немного печальнее.

Спросите своих товарищей, знают ли они, что такое СПДФОТ или RCRCRC. Это далеко не факт. Но мнемоника помогает нам запускать тесты, не забывая проверять самое важное.

Чек-лист свернулся в одну фразу! Англоговорящие коллеги-тестировщики активно используют мнемотехнику.

Друг, который читает зарубежные блоги, говорит, что американцы придумывают их почти на каждый чих.

И я думаю, что это здорово.

Чужая мнемоника может не подойти для вашей системы или ваших процессов.

А свой, родной, напомнит «не лезь проверять то и это» и ограничит количество багов в продакшене.

Сегодня я хочу поделиться с вами своей мнемоникой BMW для исследования граничных значений.

Может быть:

  • отдать младшему на общее развитие в тест-дизайне;
  • использовать на собеседовании - кандидат обычно решает задачу «найти границу в числе», но найдет ли он границу в строке или скачает файл?


Мнемоника БМВ

Б - большой М - маленький В - в самый раз

Мнемоника BMW для поиска предельных значений

Это легко запомнить.

Просто вспоминаешь эту крутую машинку и сразу расшифровка готова! Но что это значит и как это поможет во время собеседований?

В самый раз



Мнемоника BMW для поиска предельных значений

По сути, вы тестируете «в самый раз» без какой-либо мнемоники.

Мы всегда начинаем с положительного тестирования, чтобы убедиться, что система действительно работает. Если поле числовое, введите общее значение.

Допустим, у нас есть розничный интернет-магазин.

Мы можем проверить 1 или 2 количества товара.

Положительный тест – это «в самый раз».

Мнемонику я показал в виде мышки.

Здесь стандартный размер.



Большой

Тогда мы говорим, что мышку нужно раздуть до невероятных размеров, чтобы она не вписывалась прямо в картинку.

И посмотреть, как с ним будет работать система.



Мнемоника BMW для поиска предельных значений

В данном случае мы просто идем «далеко вперед».

ОЧЕНЬ ДАЛЕКО! Большая мышь символизирует поиск технологической границы где-то там, за пределами произвольной.

Для ввода количества товаров это будет «9999999999999999999999999999999999999999999999999999999999.».

Не просто какое-то большое значение (9999), а ОЧЕНЬ большое.

Вспомните мышку – он настолько раздулся, что даже не вписался в картинку.

Разница существенная, большое значение поможет найти произвольную границу, а огромное значение поможет найти технологическую.

Тест на «большой» проводят часто, а на «огромный» — нет. Мнемоника напоминает нам о нем.



Маленький

Мы протыкаем мышь, и она сдувается до микроскопических размеров.



Мнемоника BMW для поиска предельных значений

Little Mouse — это поиск значений около нуля.

Наименьшее положительное значение.

Как насчет теста на «0,00000001»? Мы проверили ноль, но не забудьте покопаться поблизости.



И что?

Кажется, я говорю очевидные вещи.

Кажется, это уже знают все.

Вы просто на собеседовании даёте задачу с номером, тот самый треугольник( головоломка от Майерса ), и понимаешь, что это не так.

Мало кто будет искать технологическую границу или пытаться ввести дробное значение около нуля.

Максимум ноль и вас попросят проверить.

А если вы предлагаете тестировать НЕ число, то это еще больший ступор.

С цифрой все в порядке, ноль и лимит мы проверили по техническим характеристикам, это неплохо.

Что тестировать в линии? А в файле? Именно об этом я и хочу поговорить в этой статье.

Как можно использовать мнемотехнику в реальной жизни и при этом ловить ошибки.

Начнем с общих примеров, которые встречаются в каждом проекте.

И что можно дать на собеседовании в виде небольшой задачи.

А дальше я расскажу вам примеры из своей работы.

Да, они специфические.

Да, они о конкретных технологиях.

Ну и что? Но они показывают, как мнемотехнику можно применять в более сложных местах.

Смысл всё тот же: почти везде есть границы.

Просто найдите число и поэкспериментируйте с ним.

И не забывайте про мнемотехнику BMW, ведь именно на B и M мы часто можем обнаружить ошибки.



Общие примеры

Примеры, которые существуют в любом проекте: числовое поле, строка, дата.

Мы рассмотрим их в таком порядке:

  • В самый раз
  • Большой
  • Маленький


Число

  • 10
  • 0,00000001
  • 999999999999999999999999.
Допустим, поле с количеством книг, платьев или коробок сока.

В качестве положительного теста выбираем какое-то адекватное количество: 3, 5, 10. Для небольшого значения выберите значение, максимально близкое к нулю.

Помните, что мышка должна быть очень маленькой.

Это не просто единица, а N-й знак после запятой.

Что делать, если округляется до нуля и где-то в формулах есть сбой? В этом случае на цифре «1» все будет работать хорошо.

Ну а максимум достигается вводом 10 миллионов девяток.

Сгенерируйте такую строку с помощью таких инструментов, как Perlclip, и продолжайте тестировать МНОГО! Смотрите также: Классы эквивалентности для строки, представляющей число - еще больше идей для тестов числовых линий Как сгенерировать большую строку, инструменты - помощники в создании большой ценности

дата

  • 26.05.2017
  • 01.01.1900
  • 21.12.3003
Положительная дата — это либо «сегодня», если мы загружаем отчет за определенную дату.

Или дату вашего рождения, если речь идет о дне рождения, или какую-то другую дату, соответствующую вашему бизнес-процессу.

В качестве маленькой даты возьмем волшебную дату «01.01.1900», на которую приложения часто разваливаются.

С этой даты начинается отсчет времени в Excel. Это также проникает в приложения.

Вы устанавливаете это магическое число, и отчет разваливается, даже если существует надежная защита от нулей.

Так что я очень рекомендую это проверить.

Если речь идет об очень маленькой мышке, то можно также отметить «00.00.0000».

Это позволит проверить ноль, что также важно.

Но от такой дуры разработчики защищаются чаще, чем от 01.01.1900. «Далеко вперед» тоже может быть разным.

Можно уйти в негатив и проверить дату или месяц, которых на самом деле не существует: 40.05.2018. Или найдите технологическую границу по дате 99.99.9999. Либо можно взять чуть более реалистичное значение, которое просто появится не скоро: 2400 или 3000. Смотрите также: Классы эквивалентности для строки, представляющей дату - еще больше идей для тестирования свиданий

Мнемоника BMW для поиска предельных значений



Линия

  • Вася
  • (одно место)
  • (здесь было много текста)
Допустим, при регистрации есть поле с именем.

Положительный тест - общее имя: Ольга, Вася, Петр.

При поиске мышонка берем пустую строку или лайфхак: один-два пробела.

В этом случае строка остается пустой (нет символов), но в то же время она как бы заполнена.

На что обращают внимание при поиске большой мыши? Когда мы тестируем большую строку, нам нужно протестировать БОЛЬШУЮ строку! Помните, что мышь должна быть БОЛЬШОЙ.

Потому что я обычно объясняю студентам, как это все работает, как искать технологическую границу и т. д. А потом мне сдают ДД и пишут «Проверил 1000 символов — технологического предела нет».

Сейчас 21 век, что такое 1000 символов? Берем любой инструмент, позволяющий сгенерировать 10 миллионов, и вставляем 10 миллионов.

Это будет поиск технологической границы.

А баги уже есть, и система может сломаться.

Но 1000 символов? Нет. Смотрите также: Как сгенерировать большую строку, инструменты - помощники в создании большой ценности Но ок, здесь тоже все ясно.

Что произойдет, если мы проверим файл?

Файл

Где я могу найти номер в файле? Во-первых, у файла есть его размер:
  • 5 МБ
  • 1 КБ
  • 10 ГБ
При тестировании большого файла обычно пробуют что-то вроде 30МБ, и на этом успокаиваются.

А потом загружаешь 1Гб — и все, сервер зависает. Конечно, если вы новичок и тестируете на опыт реальный сайт, не стоит загружать его без ведома владельца.

Но когда будете тестировать ее в работе, обязательно проверьте большую мышку.

Во-вторых, у файла есть имя → и это длина строки, о которой мы только что говорили.

Но в файле тоже есть контент! Имеется ряд столбцов (столбцов) и строк.

Рядовые тесты:

  • 5 строк
  • 1 строка
  • 10000000000 строк
И здесь все начинает становиться интереснее.

Потому что даже в одном и том же Excel разные версии имеют разные ограничения на количество поддерживаемых строк:

  • Excel ниже 97 – 16 384
  • Эксель 97-2003 – 65 536
  • Excel 2007 – 1 048 576
Но все равно цифры довольно большие, это не интересно.

Но старый Excel не открывал более 256 столбцов, и это серьезное ограничение:

  • Эксель 2003 – 256
  • Excel 2007 – 16 385
Его бесплатный брат LibreOffice не может открыть более 1024 столбцов.



Мнемоника BMW для поиска предельных значений

Жизненная история Некоторые автотесты пишем в формате CSV. Входные данные — таблица, выходные данные — таблица.

Откройте и отредактируйте в LibreOffice, чтобы увидеть, какой столбец какой.

Все отлично, все работает. Пока количество столбцов не превысит 1024. Здесь начинается #lifepain. LibreOffice больше не будет открывать тест; в формате CSV неудобно, потому что сложно понять, где находится 555 столбец.

Открываешь тест в Excel, редактируешь, сохраняешь, запускаешь тест. Вылетает в 10 новых местах: Идентификационный номер налогоплательщика испорчен.

Он длинный, например 7710152113. Xel с радостью конвертирует его в формат 1.2E+5. Другие длинные числа также теряются.

Если значение было в кавычках, оно заключено в дополнительные кавычки, чего тест не ожидает. И вы исправляете эти мелочи в формате CSV, мысленно проклиная Excel. Так что ограничение есть, стоит его помнить! Хоть это и не отражается на работе самой системы, но может просто усложнить жизнь тестировщику.



Таблица в Oracle (база данных)

И раз уж мы говорим о 1024 столбцах, вспомним Oracle (популярную базу данных).

Существует то же ограничение: в одной таблице может быть не более 1024 столбцов.

Об этом лучше помнить заранее! У нас была таблица примерно с 1000 столбцов, но половина была зарезервирована на будущее: «когда-нибудь пригодится, этого нам хватит надолго».

Этого хватило, но ненадолго.

Расширить таблицу некуда — уперлись в ограничение.

Так что либо разбивайте таблицу на две, либо упаковывайте содержимое в BLOB: это что-то вроде zip-архива с данными, он занимает один столбец, а внутри него сколько угодно.

Но в любом случае это миграция данных.

А миграция данных — это всегда боль в жизни.

На большой базе это занимает много времени, приносит новые проблемы, которые могут возникнуть только через полгода.

Бррр! Если можно обойтись без миграции, то лучше так и сделайте.

Если у вас есть таблица с МНОГО данных, подумайте о будущем.

Всегда ли вы уместитесь в 1024 столбца? Придется ли мне мигрировать позже? Ведь чем дольше живет система, тем сложнее будет перенос.

А «хватит на 5 лет» означает, что вам придется мигрировать на пять лет. Как это проверить? Да по коду оцените свои таблицы с данными, присмотритесь, что где.

Обратите внимание на большую мышку: те таблицы, в которых уже много столбцов.

Будут ли с ними проблемы в будущем?

Отчет в системе

Зачем мы загружаем файлы в систему или скачиваем данные из Oracle? Скорее всего для того, чтобы построить какой-то отчет. Эту мнемонику можно применить и здесь.

Данные могут быть как на входе (много, мало, в самый раз), так и на выходе! И это тоже важно, поскольку это разные классы эквивалентности.

В результате проверяем количество:

  • столбцы отчета;
  • линии;
  • входные данные;
  • выходные данные (в самом отчете).

Структура (столбцы и строки) Можем ли мы повлиять на количество строк или столбцов? Иногда да, мы можем.

На второй работе я тестировал дизайнер отчетов: слева у вас кубики с названиями параметров, которые можно закидывать в сам отчет по горизонтали или по вертикали.

То есть вы сами решаете, сколько будет строк и сколько столбцов.

Используем мнемотехнику.

После типичного отчета (положительный тест, «в самый раз» мышка) пробуем немного сделать:

  • 1 столбец, 0 строк;
  • 0 столбцов, 1 строка;
  • 1 столбец, 1 строка.

Потом много:
  • максимум столбцов, 1 ряд (все кубики раскидываются по столбцам);
  • максимум строк, 1 столбец;
  • если кубики и можно дублировать, то и там и там по максимуму, но это сомнительно;
  • максимальные уровни вложенности (это когда внутри одного столбца агрегатора есть два других).

Далее мы проверяем данные на входе и выходе.

Мы можем повлиять на них в любом отчете, даже если конструктора нет и количество строк и столбцов всегда одинаковое.

Входные данные Давайте разберемся, как формируется отчет. Допустим, каждый день заполняются какие-то данные, скажем, количество проданных платьев, сарафанов, футболок.

А в отчете мы видим группировку данных по категориям, цветам, размерам.

Сколько продано за день/месяц/час.

Строим отчет и влияем на входные данные:

  • Обычное количество (5 платьев в день, хотя на крупных сайтах это количество может быть 2000 и более, здесь нужно уточнить, что будет более позитивно для вашей системы).

  • Пусто, ничего не продано / продано 1 вещь за месяц.

  • Объём нереально большой, максимум каждого товара, любого цвета, любого размера.

    Ставим максимум «в наличии» и продаем все: в течение месяца или даже одного дня.

    Что по этому поводу скажет репортаж?

Выходные данные Теоретически выходные данные коррелируют с входными данными.

Ввод мал → вывод будет небольшим.

Много входных данных, много выходных.

Но это не всегда работает таким образом.

Иногда входные данные можно исключить или, наоборот, умножить.

И тогда мы сможем как-то с этим поиграть.

Например, вот система Дадата .

Вы загружаете файл с одним столбцом ФИО, а на выходе получаете сразу несколько:

  1. Исходное полное имя, которое было в файле;
  2. Разобранное полное имя (если удалось разобраться);
  3. Род. случай;
  4. Дат. случай;
  5. Создание дела;
  6. Фамилия;
  7. Имя;
  8. Фамилия;
  9. Статус парсинга — уверенное распознавание механизмом или проверенное человеком;


Мнемоника BMW для поиска предельных значений

Из одной ячейки у нас получилось 9. И это только исходя из полного имени, а еще система умеет парсить адреса.

Там из одной ячейки получается почти 50: кроме гранулированных компонентов, есть еще всякие коды КЛАДР, ФИАС, ОКАТО.

А теперь интересно.

Получается, что на входе у нас может быть мало данных, но много на выходе.

А если рассматривать максимум по столбцам, то у нас есть два варианта:

  • 500 выходных столбцов (это около 10 входных адресов);
  • 500 динамиков на входе (и целая куча на выходе).

Этот принцип работает и в обратном направлении.

Что, если на входе — целая куча данных, а на выходе — ничего? Если вместо ФИО стоит какая-то ерунда типа «or34e8n8pe»? Потом оказывается, что все дополнительные столбцы пусты, только статус парсинга «вы прислали мне мусор».

Таким образом мы получаем минимальный вывод (мышонок), что тоже стоит проверить.

А что, если столбцы можно исключить! Вы также можете проверить класс эквивалентности «нулевой»; когда вывод равен нулю, исходный файл не пуст. Проверить минимум можно тогда, когда вы оставили 1 столбец из ста.

Здесь главное помнить, что помимо входных данных у нас есть выходные данные.

А иногда в них можно проверить границы, которые не будут зависеть от входных данных.

И тогда это необходимо сделать.



Мобильные приложения



Связь

Возможны разные варианты связи:
  • Нормальный;
  • Абсолютно дрянной (маленькая мышка);
  • Супер-быстрый (большой).

Причем плохая связь может быть отчасти: если вы находитесь в зоне с нормальным Wi-Fi и плохой сотовой сетью.

Интернет работает хорошо, но СМС плохо.



Объем памяти

Также важно, сколько памяти у приложения:
  • Нормальная сумма;
  • Очень мало;
  • Очень много.

А если в данном случае можно совместить первый и третий тесты, то мышонок получается очень интересный.

И есть разные варианты: — запускаем приложение на телефоне, у которого УЖЕ мало памяти; — запускаем, когда память нормальная, сворачиваем, разворачиваем что-то большое, пытаемся вернуться к первому приложению.

Вот если приложение не умеет правильно резервировать память, то во втором случае оно просто упадет, память уже выжата.



Диагональ устройства

  • Стандартный (изучаем рынок, смотрим, что больше нравится нашим пользователям).

  • Минимум (телефон).

  • Максимум (большой планшет).



Разрешение экрана

  • Стандартный;
  • Самая маленькая вещь;
  • Самый большой;
Не путайте разрешение и диагональ, это разные вещи.

У вас может быть старое устройство с большим дисплеем, а у меня новый модный смартфон с разрешением в 5 раз лучше.

И страшно представить, что будет через 20 лет.

GPX-пути

Пути GPX представляют собой XML-файлы с последовательными координатами.

Их можно загрузить в мобильные эмуляторы, чтобы телефон думал, что он движется в пространстве с некоторой скоростью.

Полезно, если приложение считывает координаты GPS для каких-то своих целей.

Именно так он определяет, ходите ли вы, бежите или едете.

Или не надо бегать, просто скормите координаты в приложение, задайте коэффициент их прохождения и протестируйте сидя в офисе.

Какие шансы стоит проверить? Все по мнемонике:

  • 1 – нормальный коэффициент, заменяет простую ходьбу;
  • 0,01 – как будто бреешь;
  • 200 – ты даже не бежишь, ты летишь!
Зачем все это проверять? С какими ошибками можно столкнуться? Например, в самолете может произойти сбой приложения — я его запустил, а оно сразу вылетело.

Потому что он считывает координаты и пытается определить вашу скорость.

Но кто знал, что скорость будет выше 130? На медленных скоростях приложение может аварийно завершить работу.

Он настроит себе миллион промежуточных точек и не сможет удержать их в памяти.

И всё, до свидания.

Смотрите также: Что такое пути GPX и зачем они нужны тестировщикам? — подробнее о путях gpx и пример такого файла

Краткое изложение общих примеров

Я хочу здесь показать, что, казалось бы, «большое, маленькое» — это числовое поле и всё! Но на самом деле мнемотехнику можно использовать везде, будь то файлы, игрушки, отчеты.

И она очень помогает нам находить ошибки.

Вот несколько примеров из моей практики: Мышка (нижняя граница) — Дата 01.01.1900 Когда я работал фрилансером, эта дата испортила все мои отчеты.

Потому что даже если разработчик установил защиту от дураков, он установил защиту от 0000. Но защиту от 1900 он не установил.

— Одинокий символ конца строки Этот тест мне предложил более опытный коллега, когда мы обсуждали примеры использования мнемотехники.

Если система проверяет файл на пустоту, необходимо проверить, не является ли он полностью пустым.

Я рекомендую этот тест: добавьте в файл символ конца строки.

Даже не пробел, а специальный символ.

И посмотреть, как отреагирует система.

Но она не всегда хорошо реагирует =) Большая Мышь (верхняя граница) Если говорить о большой мышке, то там багов вообще бесконечное количество: - Война и мир; — Много данных; — 2 ГБ.

Вы можете загрузить войну и мир в текстовое поле, загрузить в систему огромный файл, вводить или выводить большое количество данных.

Это все типичные ошибки, с которыми я сталкивался в своей практике.

И не только я, верхний предел часто проверяют именно потому, что знают, что там могут быть баги.

Скорее всего, они забудут о мышонке.

Другой пример большой мыши — нагрузочное тестирование.

О! Такие примеры у меня есть, поэтому переходим к хардкору.

Если вы знаете контекст, если вы знаете, как ваше приложение работает внутри, на каком языке программирования оно написано, какую базу данных оно использует, вы также можете применить эту мнемонику.

И я хочу показать это на конкретных примерах.



Мои примеры из практики



Большая мышь



Linux, Lucene, Mmap

В операционной системе Linux есть настройка максимального количества открытых файловых дескрипторов:
  • redhat-6 — /etc/security/limits.conf
  • redhat-7 - /etc/systemd/system/[имя службы].

    service.d/limits.conf (по одному на каждую услугу)

Дескриптор файла открывается для любого действия над файлами:
  • создать соединение с базой данных;
  • прочитать файл;
  • записать в файл.

  • .

Если ваша система активно работает с файлами и выполняет множество операций, настройки необходимо увеличить.

В противном случае малейшая нагрузка раздавит вас.

Наша система использует поисковый индекс Lucene. Это когда мы берем некоторые данные из базы данных и загружаем их на диск, чтобы мы могли быстрее их искать.

А если строить индекс по технологии mmap, то при построении индекса он открывает множество файлов для записи.



Мнемоника BMW для поиска предельных значений

В тестовой базе клиентов обычно 100, ну 1000. Не так уж и много.

Перестроение проходит без проблем, даже если вы не настраиваете дескрипторы.

А в реальной системе будет 10+ миллионов клиентов.

И если там не настроить количество файловых дескрипторов, то когда вы начнете строить индексы, все просто рухнет. Об этом нужно знать и сразу писать инструкцию: настройте операционную систему на сервере, иначе будут такие-то последствия.

И с вашей стороны важно проводить не только функциональные тесты, но и нагрузочные тесты, используя реальный объем данных.



Редхат 6 ≠ Редхат 7

Тестируя большую мышку (нагрузочную), не забывайте, что в разных конфигурациях приложение будет работать по-разному.

Если взять инструкцию из предыдущего пункта, то ее нужно не только написать, но и проверить.

И проверить это в среде заказчика.

Потому что разные операционные системы работают по-разному.

И у нас была ситуация, когда вроде бы все настроилось, но система зависла и сказала «Мне не хватает дескрипторов открытых файлов».

Мы говорим: — Проверьте параметр.

— Настроено, всё по вашей инструкции! Как же так? Оказывается, у нас есть инструкция для Redhat 6, а у них Redhat 7, где настройки совсем в другом месте! В итоге сделали по нерабочей инструкции и как будто и не делали вообще.

Так что если вы работаете с разными версиями дистрибутивов Linux, вам необходимо проверить их все.

И не просто развернуть сервисы на машине, но и провести хотя бы один раз нагрузочное тестирование: убедиться, что все работает. В конце концов, лучше поймать ошибку в тестовой среде, чем потом иметь дело с продакшеном.



Java и сбор мусора

Мы используем язык Java, в котором есть встроенный сборщик мусора.

Иногда кажется, что если приложение использует много памяти и находится на грани OOM (Out of Memory) для какой-то сложной операции, то такая проблема может легко решить, просто увеличив объем доступной памяти! Зачем тестировать? Не совсем.

Если дать слишком много Xmx, приложение зависнет на сборщике мусора.



Мнемоника BMW для поиска предельных значений

Причем это проявляется для пользователя очень неожиданно.

Ночью прикладывали большую нагрузку, скачивали много данных – особенно в нерабочее время, чтобы никого не беспокоить.

Утром приходит пользователь, он один работает с системой, нагрузки почти нет, и у него все зависает. И он даже не понимает, почему.

А на самом деле нагрузка прошла, нагрузка ушла, и сборщик мусора вышел все почистить, из-за этого и фризы.

И хотя нагрузки сейчас нет и работает один пользователь, ему грустно.

Поэтому просто выделить приложению много памяти «и не надо его тестировать» так не получится.

Лучше проверьте.



дикая муха

Сервер Java-приложений WildFly не позволит вам загружать большие файлы, если они не настроены соответствующим образом.



Мнемоника BMW для поиска предельных значений

Мы используем сервер приложений Jboss, также известный как Wildfly. И оказывается, что большие файлы в него по умолчанию загрузить нельзя.

При этом мы помним, что мышь должна быть БОЛЬШОЙ.

Если тестируем 5мб или 50, все работает, все нормально.

Но если вы попытаетесь загрузить 2ГБ, система выдаст ошибку 404, и по логам вы ничего не сможете понять: логи приложений пусты.

Поскольку это приложение не может скачать файл, Wildfly сам его обрезает. Если вы не проводите тестирование на своей стороне, клиент может столкнуться с этим.

И это будет очень неприятно, он придет с вопросом «Почему не загружаетсяЭ», а без разработчика вы ничего не сможете сказать.

Поэтому лучше не забывать проверять границы, в том числе заталкивая в систему большие файлы.

Как минимум, вы будете знать результат таких действий.

И здесь мы либо исправляем это увеличением параметра max-post-size, либо предоставляем информацию об ограничении и пишем ее в технической спецификации.



Ведение журнала

Еще один пример тестирования «большой» мыши.

Да, почему-то я помню больше таких примеров.

Он чаще ловит ошибки! Допустим, мы проверяем регистрацию ошибок.

Что ошибка записывается в stacktrace в журнале.

Вот мы и проверили, у нас молодец: да, всё круто, всё записано! И я все понял из стека по тексту ошибки.

Если Заказчик не справится, я сразу пойму, почему.



Мнемоника BMW для поиска предельных значений

Что произойдет, если у нас будет не одна ошибка, а несколько? Тоже все хорошо, все логируется, все отлично! Но помним, что мышка должна быть БОЛЬШОЙ:

Мнемоника BMW для поиска предельных значений

Что произойдет, если у нас будет МНОГО ошибок? У нас была именно такая ситуация.

Исходная система загружает данные в буферную таблицу базы данных.

Наша система берет оттуда эти данные и потом как-то с ними работает. Исходная система вышла из строя и загрузила неправильный прирост, в котором все данные были неверными.

Наша система приняла инкремент, и было 13600 ошибок.

А когда Java попыталась сгенерировать трассировку стека с 13 тысячами ошибок, она израсходовала всю выделенную для нее память, а затем сказала: «О, Java-куча».

Как ты это починил? В задачу загрузки добавлен параметр maxStoredErrors (по умолчанию 100) - m. Теги: #тестирование #граничные значения #занимаюсь пиаром #Тестирование IT-систем #Тестирование веб-сервисов #Тестирование мобильных приложений #Тестирование игр

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.