Проблема наблюдаемости

Проблема наблюдаемости
Software Testing 101
Марат Ахин
Санкт-Петербургский государственный политехнический университет
2014
Марат Ахин (СПбГПУ) NP 2014 110 / 320

Quiz

Recap

Проблемы тестирования Проблемы тестирования
Проблемы тестирования
What’s up, Doc? (с)
Проблема тестовых входных данных
Проблема «останова»
Проблема тестового оракула

Содержание
1 Проблема наблюдаемости
Обеспечение распространения сбоя
Assertions
Журналирование

Проблема наблюдаемости Обеспечение распространения сбоя
Какими способами можно управлять выполнением кода?
Изменением входных данных
Изменением самого исходного кода
Необходимо обнаружить сбой и распространить его, сделав
наблюдаемым снаружи (Propagation)

Проблема наблюдаемости Обеспечение распространения сбоя

Проблема наблюдаемости Assertions
Assertions
Основной способ обеспечения наблюдаемости – assertions
1 private void checkInvariants () {
2 assert elements[tail] == null;
3 assert head == tail
4 ? elements[head] == null
5 : (elements[head] != null &&
6 elements [( tail - 1) & (elements.length - 1)] != null );
7 assert elements [( head - 1) & (elements.length - 1)] == null;
8 }

Assertions
Что такое assertion?
Формула в логике первого порядка
Проверяется на истинность во время выполнения программы
Также может проверяться на истинность статически
Допускает возможность отключения проверки истинности

Что дает использование assertions?
Проверка корректности внутреннего состояния
Внутреннее состояние обычно недоступно снаружи (полностью
или частично)
При изменении состояния хочется проверить, что оно остается
корректным

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

Явное документирование пред- и пост-условий
В общем случае программист ничего не знает о контракте
используемой функции
Использование assertions позволяет в явном виде описать
внешний контракт функции

Assertions

Какие проблемы связаны с assertions?
Ошибки в assertions
Побочные эффекты в assertions
Неправильное логическое условие срабатывания

Влияние на производительность
Проверка assertions занимает время
Чем сложнее assertion, тем больше он замедляет работу
программы

Эффект «вышибалы»
Сработавший assertion превращает любую ошибку в неудачу
Это полностью останавливает возможность дальнейшего
тестирования

Сложность проверки определенных условий
Некоторые просто формулируемые условия крайне сложно
проверить на практике
Их реализация в виде assertion является крайне затруднительной

Работают ли assertions?

1 int* ptr = malloc(sizeof(int) * 10);
2 assert(ptr);
Адекватный assertion в правильном месте

1 int* ptr = malloc(sizeof(int) * 10);
2 assert(ptr);
Замена обработки ошибок на assertion

Microsoft Oﬃce ≈ 1%
Proprietary software ≈ 3%
Open source software ≈ 5%
Eiﬀel software ≈ 7%
Сейчас assertions используются еще более широко

Работают ли assertions?1
LLVM
≈ 500,000 SLOC
≈ 7000 assertions
> 400 ошибок, относящихся к assertions
1
http://blog.regehr.org/

Работают ли assertions?1
GCC
≈ 1,000,000 SLOC
≈ 9500 assertions
> 200 ошибок, относящихся к assertions
1
http://blog.regehr.org/

Проблема наблюдаемости Журналирование

Журналирование (logging)
Запись хода выполнения программы в том или ином виде
В зависимости от необходимости журнал может быть более или
менее детализированным
По журналу выполнения при необходимости возможно
восстановить причину возникшей ошибки

Журналирование для
пользователя
Высокоуровневые
сообщения
Как можно меньше
«мусора»
Чем проще и понятнее
формат сообщений, тем
лучше
Журналирование для
программиста
Низкоуровневые
сообщения
Допустим любой шум
Никаких ограничений на
формат сообщений

Как вести журнал?
1 Result :: Ptr processBatchJob (Job :: Ptr job) {
2 // do the heavy lifting ...
3 }
Как записать ход выполнения программы?

1 Result :: Ptr ThreadedProcessor :: processBatchJob (Job:: Ptr job) {
2 log () << "Start of: " << job << endl;
3 // do the heavy lifting ...
4 log () << "End of: " << job << endl;
5 }
Ручная вставка журналирующих вызовов

1 aspect ProcessTracer {
2 advice call("% %Processor :: process %(%)") : before () {
3 log () << "Start of: " << * JoinedPoint ::arg <0 >() << endl;
4 }
5 advice call("% %Processor :: process %(%)") : after () {
6 log () << "End of: " << *JoinedPoint ::arg <0 >() << endl;
7 }
8 };
Журналирующие аспекты / интерсепторы

Logging as a Service

Основная проблема журналирования
INFO [http -thread -pool -8080(5)] Received token: e6749451
TRACE [http -thread -pool -8080(5)] Calling: AuthStorageBean . getAuthData
TRACE [http -thread -pool -8080(5)] Called: AuthStorageBean .getAuthData -> 2.0708E-5
INFO [http -thread -pool -8080(5)] Authentication data found: AuthData { authToken:e6749451
userId :1 firstName: lastName:Admin patrName: role:ru.korus.tmis.core.entity.model.
Role[id=1] spec: }
TRACE [http -thread -pool -8080(5)] Calling: AuthStorageBean . getAuthDateTime
TRACE [http -thread -pool -8080(5)] Called: AuthStorageBean . getAuthDateTime -> 1.9825E-5
INFO [http -thread -pool -8080(5)] Token is valid
TRACE [http -thread -pool -8080(5)] attempting to get session; create = false; session is
null = true; session has id = false
TRACE [http -thread -pool -8080(5)] Authentication attempt received for token [ru.korus.tmis
.core.auth. TmisShiroToken@37bd2b6 ]
DEBUG [http -thread -pool -8080(5)] Performing credentials equality check for
tokenCredentials of type [java.lang.String and accountCredentials of type [java.lang
.String]
DEBUG [http -thread -pool -8080(5)] Both credentials arguments can be easily converted to
byte arrays. Performing array equals comparison
DEBUG [http -thread -pool -8080(5)] Authentication successful for token [ru.korus.tmis.core.
auth. TmisShiroToken@37bd2b6 ]. Returned account [(admin ,ru.korus.tmis.core.entity.
model.Role[id =1])]
DEBUG [http -thread -pool -8080(5)] No SecurityManager available in subject context map.
Falling back to SecurityUtils . getSecurityManager () lookup.
Too much data!

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

Ограничение размера журнала
Необходимо ограничивать размер записываемых данных

Уровни журналирования
Сообщения пишутся в журнал с определенным уровнем
В дальнейшем возможно фильтровать сообщения по уровням
Error / Warning / Info / Debug / Trace

Домены журналирования
Домены ортогональны уровням журналирования
В зависимости от типа сообщения пишутся в разные домены
Database / Network / UI / Conﬁguration / ...

Стохастическое журналирование
В случае, если какие-то события встречаются очень часто,
достаточно записывать лишь их часть
1 if (_ok == true) {
2 _logger.log( Level.WARNING , "Server seen down: " + _addr , e );
3 } else if (Math.random () < 0.1) {
4 _logger.log( Level.WARNING , "Server seen down: " + _addr );
5 }

Сессионное журналирование
Часто работа ПО разбита на набор слабо связанных сессий
Каждая сессия может журналироваться независимо от других
1 try {
2 // logging ...
3 } catch (Exception ex) {
4 ctx.logging. dumpCurrentSession ();
5 throw;
6 } finally {
7 ctx.logging.reset ();
8 }

W.I.L.T. What I Learned Today?
W.I.L.T.

Проблема наблюдаемости

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Проблема наблюдаемости

Ähnlich wie Проблема наблюдаемости (20)

Проблема наблюдаемости