грязная посуда

ГЛЕБ ДЕЙКАЛО

Спецвыпуск: Хакер, номер #073, стр. 073-020-4

[попытки поломать web-систему.]

Есть легенда о тестировщице. Девушка устраивалась тестировщицей в некую компанию, и ее попросили продемонстрировать способности к тестированию. Девушка подошла к настольной лампе, выключила ее из розетки, поставила выключатель в положение между «включено» и «выключено» и воткнула вилку обратно в розетку. Лампа перегорела, и девушку взяли на работу. У хорошего тестировщика должен быть дар ломать все, к чему он ни притронется. Потому что если у web-системы есть слабое место, легкий удар в которое «уронит» ее, то этот удар обязательно произойдет.

На данном этапе тестирования нужно делать с web-системой все: в CMS задавать предельные значения для сущностей (например, в текст новости вставить три тома «Войны и Мира»), в динамический контент вставлять длинные строки без пробелов (браузер переносит текст, используя в качества места разрыва пробел, следовательно, длинная строка без пробела будет растягивать сайт), вставлять в динамический контент различные «нехорошие» данные (например, JavaScript или спецсимволы &, ‘, ` и “ – они могут вызвать ошибку при работе с базой данных) и т.д. Это первое, что приходит в голову. Список этот можно продолжать очень долго, и именно в этом заключается талант тестировщика.

[тестовый контент.]

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

1 Тестовый контент должен быть корректен с морально-этической точки зрения - он не должен содержать слов и выражений на грани цензуры, и тем более нецензурных (чем нередко грешат разработчики и тестировщики). В идеале, тестовый контент должен лишь показывать, что он собой представляет. Например, для новости стоит задавать параметры следующего вида. Заголовок – «я заголовок новости», Анонс – «а я - ее анонс», Текст – «а я текст новости, я должен быть мало-мальски длинным, потому что так оно обычно и бывает...» и все в таком духе. Естественно, с некоторыми вариациями, чтобы отличать одну новость от другой.

2 Тестовый контент должен явно отличаться от реального контента. Приведенный пример с новостью в этом плане не очень хорош. Он не бросается в глаза. Вопрос о том, как выделить тестовый контент, решается «по ситуации». Например, если у новости есть еще и поле Картинка, то достаточно всем тестовым новостям задать яркую картинку (явно выделяющуюся из дизайна) с надписью «test». Или можно просто начинать все поля префиксом «AHTUNG! TEST!» или подобным.

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

[систематизация багов, bug-tracking.]

И вот, наконец, все баги найдены. Теперь нужно их систематизировать. Для этого существуют так называемые «баг-трекеры» – программы, ведущие историю багов. Чаще всего баг-трекеры представляют собой web-системы, устроенные по принципу форумов или блогов. Разберемся в систематизации багов на примере баг-трекера Mantis.