Поехали:
Слайд 118
Работая с паззлами, студенты часто говорят, что они могут решить, корректен ли размер, измеряя его.
Все не так просто. Единица измерения размера символа - точка. В дюйме 72 точки. Но символы, высота которых 10 точек намного короче своих двойников в других шрифтах.
Так что вместо того, чтоб попытаться точно измерить, что может быть очень сложно, мы полагаемся на простую эвристику, которая состоит в сравнении больших символов с меньшими и в сравнении с другой программой, которой мы больше доверяем.
Слайд 119
Вернемся к оригинальной идее о том, что тестирование это сравнение результата теста с ожидаемым.
Тут есть четыре проблемы:
Первая: наши ожидания могут быть ошибочными.Если программа работает не так, как описано в спецификации, то часто это бывает из за того, что ошибка в спецификации или она устарела. Если программа работает не так как эталонная, то может случиться, что в эталонной программе баг.
Вторая: даже если программа и оракул совпали, то тут все равно может быть баг. вспомните программу которая складывает 2 и 3 пять часов. Эталонная программа не даст всех возможных случаев. Нет полных спецификаций. Всегда есть аспект программы - в большинстве случаев достаточно важный - для которых тестировщик не знает, как определить, правильно или нет ведет себя программа.
Третья. У Open Office и WordPad был в сущности один и тот же баг со шрифтами, но я сказал, что это серьезный баг для Open Office и тривиальный для WordPad. Когда Джеймс учит этому, он говорит, что он, вероятно, не репортил бы формально этот баг, а просто рассказал о нем программистам. В моей практике все немного по другому. я хочу чтоб все особенности были записаны, поэтому я репорчу о каждом несоответствии между результатами и ожиданиями. Но если я считаю, что это неважно, то я так и говорю. Я не трачу много времени на это и я не давлю на людей, чтоб они это исправляли. Чтоб определить серьезность бага, мы должны полагаться на человеческие суждения. в этом оракулы редко помогают.
И наконец, есть проблема доверия. Когда вы говорите, что программа работает некорректно, почему вам кто-то должен верить. Может быть, никто не стал бы оспаривать вас, если бы вашим оракулом была спецификация или заслуживающая доверия эталонная программа. Но что, если программа плохо себя ведет способом, который не покрывается оракулом? Игнорировать? Репортить и надеяться, что вам не придется ее защищать? Мы репортим, но мы должны быть уверены, что читатель будет ясно понимать, почему мы считаем, что это проблема.
Слайд 118
Работая с паззлами, студенты часто говорят, что они могут решить, корректен ли размер, измеряя его.
Все не так просто. Единица измерения размера символа - точка. В дюйме 72 точки. Но символы, высота которых 10 точек намного короче своих двойников в других шрифтах.
Так что вместо того, чтоб попытаться точно измерить, что может быть очень сложно, мы полагаемся на простую эвристику, которая состоит в сравнении больших символов с меньшими и в сравнении с другой программой, которой мы больше доверяем.
Слайд 119
Вернемся к оригинальной идее о том, что тестирование это сравнение результата теста с ожидаемым.
Тут есть четыре проблемы:
Первая: наши ожидания могут быть ошибочными.Если программа работает не так, как описано в спецификации, то часто это бывает из за того, что ошибка в спецификации или она устарела. Если программа работает не так как эталонная, то может случиться, что в эталонной программе баг.
Вторая: даже если программа и оракул совпали, то тут все равно может быть баг. вспомните программу которая складывает 2 и 3 пять часов. Эталонная программа не даст всех возможных случаев. Нет полных спецификаций. Всегда есть аспект программы - в большинстве случаев достаточно важный - для которых тестировщик не знает, как определить, правильно или нет ведет себя программа.
Третья. У Open Office и WordPad был в сущности один и тот же баг со шрифтами, но я сказал, что это серьезный баг для Open Office и тривиальный для WordPad. Когда Джеймс учит этому, он говорит, что он, вероятно, не репортил бы формально этот баг, а просто рассказал о нем программистам. В моей практике все немного по другому. я хочу чтоб все особенности были записаны, поэтому я репорчу о каждом несоответствии между результатами и ожиданиями. Но если я считаю, что это неважно, то я так и говорю. Я не трачу много времени на это и я не давлю на людей, чтоб они это исправляли. Чтоб определить серьезность бага, мы должны полагаться на человеческие суждения. в этом оракулы редко помогают.
И наконец, есть проблема доверия. Когда вы говорите, что программа работает некорректно, почему вам кто-то должен верить. Может быть, никто не стал бы оспаривать вас, если бы вашим оракулом была спецификация или заслуживающая доверия эталонная программа. Но что, если программа плохо себя ведет способом, который не покрывается оракулом? Игнорировать? Репортить и надеяться, что вам не придется ее защищать? Мы репортим, но мы должны быть уверены, что читатель будет ясно понимать, почему мы считаем, что это проблема.
Комментариев нет:
Отправить комментарий