Коротко. "Почему нужны тесты"

Сделали тут нагрузочные тесты, я писал об этом - Коротко. Сделали нагрузочные тесты.

Каков итог?

Мало того, что я добился "стабильности работы" на "ограниченном числе клиентов". Т.е. проблемы и отказы - протоколируются, но данные - не разрушатся. Максимум что случается - это "перезапуск транзакции".

Повторю - "на ограниченном количестве клиентов".

В реальных условиях - пока не тестировал. Но есть определённый оптимизм.

Но кроме решения проблемы с отказами и обработкой ошибок я нашёл и "разрулил" уже несколько "бутылочных горлышек" - Про "рефакторинг" - там где клиенты "бились за общий ресурс".

"Разрулил". Более-менее успешно. Опять же - "на ограниченном количестве клиентов".

Далее - автоматическое нагрузочное тестирование с числом клиентов "сравнимым с реальным". Стенды - готовим. Думаю - запустим и посмотрим.

Ну и ещё один вывод был сделан - "схема данных не самая удачная". Будем думать над схемой.

Она родилась лет 10-15-ть назад и видимо "уже не вписывается в современные реалии". Так бывает.

Будем думать и над схемой тоже.

Один только вопрос я "сам себе задаю" - "а что мешало сделать подобные нагрузочные тесты уже несколько лет назад". При том, что автоматические GUI-тесты и Unit-тесты - давно уже внедрены и работают. И показывают хотя бы "регресс".

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

А может быть - "не хватало инфраструктуры", которую мы наконец "набрали".

Не поленюсь опять привести код теста, ибо он - "хорош", почти по-русски:

USES
 QuickTestsUtils.script
;
 
Тест TK565491886
 
 ARRAY VAR "Список документов"
 [ Конституция ГК НК ТК ТНВЭД ОКОФ ОКОНХ ] >>> "Список документов"         
 
 BOOLEAN VAR Вечность
 ДА >>> Вечность 
 ПОКА Вечность (
          INTEGER VAR "Случайный документ"
          ( "Список документов" array:Count Random "Список документов" [i] ) >>> "Случайный документ" 
     Параметры: ( "Документ из базы {("Случайный документ")}" )
     Выполнить ( 
  "Набить текст {('Вносим изменения в текст и сохраняем документ!!!')}"
  "Нажать Enter" 
  // - чтобы отделить параграфы документа, 
  //   иначе параграфы могут быть "слишком длинными" для восприятия
  "Сохранить документ"
  "Обработать сообщения" // - чтобы приложение перерисовывалось
  Если "Нажали кнопку 'Прервать тест'" то Выходим 
  // - это ВАЖНО, потому, что наш тест - "бесконечный" 
  //   и его надо как-то прерывать (не только по Ctrl-F2)
   )
        )
;
 
TK565491886

Чего "греха таить" - я лично - "горжусь тем, что приложил руку к тому, чтобы это работало".

Причём работало "именно в таком виде".

По-русски - это конечно ерунда. Можно и по-китайски. Такая возможность - есть. Главное, что код теста - "самодокументируемый".

Но однако - "мы вышли на новый уровень тестирования". Это факт.

Есть один момент, который пока ещё "не автоматизирован". Это "автоматический деплоймент тестов" на распределённых клиентов. Но я думаю, что мы скоро и это - тоже сделаем.

Первый шаг - это деплоймент собственно тестовых скриптов с централизированного сервера. Но это - "вообще копейки". Надеюсь. Грубо говоря - "как мы ходим к серверу за дистрибутивами приложений и данными", так "мы можем ходить к серверу за тестами".

Хотя конечно же - "дьявол кроется в деталях".

Поживём увидим.

Но вопрос - "что же мы не сделали подобные тесты ещё несколько лет назад" - я сам для себя - пока не решил.

Ну а сухой остаток - "тесты это более чем полезно". Всякие разные.

1. Unit.
2. GUI.
3. Нагрузочные.

Подробнее я писал когда-то тут - Ещё раз об "уровнях тестирования".
Ну и тут - GUI-тестирование "по-русски". Заметка об уровнях тестирования.

Ну собственно вот - "поделился позитивом". Я лично - очередной раз убедился в важности тестов. После кратковременной депрессии.

P.S. Анализ "вскрывшихся проблем" - я отдельно ещё напишу.

Там есть вопросы про дырявую абстракцию в частности.

Во-первых потому, что в ReadFile и WriteFile - "дырявая абстракция" при "отказах сети".
А во-вторых - наши собственные классы - тоже "дырявая абстракция". Как выяснилось.

P.P.S. И ещё "из части догадок". Так как "натурный эксперимент поставлен пока не был".

Но косвенные признаки говорят о чём:

Если на одном клиенте сделать так:

LockFile(hFile, 10 {anOffset - смещение региона для залочки}, 20{aLength - длина региона});

А на другом так:

SetPosition(hFile, 0 {- позиция файла});
Result := ReadFile(hFile, @aData {- куда читаем}, 10 {- сколько читаем}, @l_ReadBytes {- сколько считали});
Assert(10 = l_ReadBytes); // - проходит
Assert(Result); // - не проходит

-- то есть вероятность, что "второй клиент" получит ошибку LOCKVIOLATION.

Записи о таких ситуациях я наблюдал в логе.

Хотя регионы - вроде не пересекаются.

Потому что залоченный регион это - [10, 20].

А читаемый регион это - [0, 9].

[A, B] - это интервал в "смысле математики", во включением концов.

Т.е. - "есть впечатление", что "иногда" при чтении/записи если конец читаемого/записываемого интервала "упирается" в залоченный интервал, то функции ReadFile/WriteFile - могут возвращать ошибку.

P.P.P.S. Кстати можно посмотреть на "код тестов".

P.P.P.P.S. Ну и напомню - это.