ЗАПАДЛО БЕТА-ТЕСТЕРА

Спецвыпуск Xakep, номер #010, стр. 010-014-2

БОЕВЫЕ БАГИ

И немного о том, как придумывать подходящие для флуда баги. Основной критерий - они должны быть трудоемкими. Понимаешь, если ты все время будешь слать лажу, типа "Там буква не прорисовывается", "Эта кнопка западает", "Тут минус теряется", кодер будет тратить минимум времени на проверку таких багов. Может даже так получится, что ты будешь тратить больше времени на их придумывание, чем он на проверку, а это в стратегическом плане невыгодно :). Подвиснешь ты, а не он :) (такая ситуевина тебе тоже знакома из практики сетевого флуда). Поэтому надо придумывать трудоемкие баги. Смело можешь отрепортить, что открывал и закрывал (прокатит любое действие) прогу около семисот раз :), и только после этого в ней произошел такой-то баг (вис там какой-нибудь, или глюк расчета, короче, что угодно). Усек? Программер, скорее всего, полезет, посмотрит код, ничего явно подозрительного там не найдет (так как такого бага вообще не существует) и вынужденно начнет открывать и закрывать свою прогу. Семьсот раз! Но это еще цветочки. Существует класс ошибок, называемых ошибками работы с памятью, и эти ошибки являются самыми противными и трудно отлавливаемыми (когда софтина пишется на языке высокого уровня). Если умудришься убедить кодера, что его софт отжирает память или как-то еще с ней плохо поступает, ему придется лезть в дебри низких уровней, и он там потратит намного больше времени, чем на открывание-закрывание пусть даже семьсот раз.

СКРИНШОТНЫЕ ФАЛЬШИВКИ

Основным доказательством существования найденного бага во все времена являлись скриншоты (если баг визуальный). Многие кодеры не рассматривают репорты своих тестеров о визуальных багах, пока те не приложат скриншот. А как подделывать скриншоты ты знаешь? Конечно знаешь: делаешь скрин, открываешь его в каком-нибудь фотожопе и изменяешь как хочешь. Таким макаром можно сымитировать абсолютно любой баг. Это тебе на заметку :).

НЕСКОЛЬКО СОВЕТОВ ПО ОБУСТРОЙСТВУ ХАОСА