часть 2
Итак, вы хотите стать тестировщиком веб-приложений? Это хорошо. Однако, прежде чем приступить к тестированию, сначала определите, ЧТО следует тестировать. Затем найдите ответ на вопрос «Как вы будете проверять эти вещи?». Сегодня я поделюсь с вами несколькими полезными советами, которые помогут вам стать лучшим тестировщиком веб-приложений.
Прежде чем двигаться дальше, обязательно прочтите раздел Как запустить тестовое веб-приложение? Часть 1.»
стандарты W3C
Это простой шаг. Просто зайдите на страницу W3C и подтвердите документ (веб-страницу?) онлайн. Затем читайте отчет, находите ошибки (эти красные) и… сообщайте об ошибках. Теперь небольшой урок истории:
‹урок истории›: когда создавался консорциум W3C, они давали вебмастерам только рекомендации. Так началась война с разработчиками браузеров. Война была основана на убеждении, что разработчики должны начать использовать рекомендации W3C в своих браузерах. Спустя более десяти лет W3C победил, и с этого времени они изменили название «рекомендации» на «стандарты», чтобы никто не мог снова начать войну. ‹/урок истории›
Мораль этой истории такова: стандарты W3C действуют, поэтому большинство веб-мастеров, веб-разработчиков и т. д. должны следить за ними. Так и вы. Это полезно, потому что вы (теоретически) знаете, «как что-то должно работать». Конечно, как всегда, есть исключения из правил, но вопрос в том, хорошо ли эти исключения продуманы? Более того, учитесь на ошибках, желательно на чужих ошибках.
Консоль
Консоль - полезный инструмент. Если у вас нет консоли, установите ее в браузере как можно быстрее. В браузерах Chrome и Internet Explorer консоль установлена по умолчанию. В других браузерах вам придется установить его вручную. Я рекомендую [см. раздел W3C] «Консоль Firebug», которую вы можете настроить даже для браузера Chrome. Для чего нужна консоль? Ну… для многих вещей; это будет ваш основной инструмент для тестирования веб-сайта. В консоли вы можете найти ошибки JS, CSS, HTML и серверов, вы можете редактировать код (HTML, CSS, JS) и быстро увидеть результаты ваших изменений, вы можете добавлять/удалять/редактировать файлы cookie, просматривать DOM, Интернет и многое другое. более.
Окружающая среда
Среда — это место, где ваш проект начнет новую жизнь. Очевидно, что ваш проект не будет жить в одной (ПРАВИЛЬНОЙ) среде. Будет много пользователей с множеством вариантов окружения. Невозможно протестировать их все, но вы можете протестировать некоторые из них, наиболее важные. Во-первых, если вы тестируете веб-страницы и веб-приложения, проверьте их поведение в разных браузерах (FireFox, Chrome, Internet Explorer, Safari, Opera и других?) и… разных версиях этих браузеров. Во-вторых, сделайте то же самое еще раз, но смените ОС (Windows, Linux, iOS…), в-третьих, проверьте отзывчивость страницы (автоматический механизм, обеспечивающий оптимальное качество просмотра).
404 — ошибки
Эта тема легкая. Сначала проверьте, создана ли в тестируемом веб-приложении пользовательская страница ошибки 404. Затем просмотрите весь проект и проверьте, нет ли скрытых ошибок 404. Если вы найдете какие-либо, проверьте, правильно ли они оформлены.
Проверки безопасности
Эта тема широка для разнообразия и основана на трех основных концепциях: XSS, внедрение скриптов и автоматические сканеры. Давайте начнем описывать их, как всегда, с последнего. Автоматические сканеры (такие как: Acunetix, Netsparker, Wapiti) одновременно полезны и бесполезны. Не ошибитесь и не доверяйте этим сканерам безоговорочно. Однако они могут дать вам некоторые дополнительные идеи о том, как проверить безопасность вручную. Да, вы правильно прочитали: вручную. В этой области вам нужно сделать большую часть работы самостоятельно.
Внедрение скриптов и общее тестирование безопасности веб-сайтов требуют знаний, но прежде всего интуиции тестировщика. Сначала определите основные точки атаки. Если это, например. форма, подумайте, что вы можете отправить на сервер. Затем подумайте обо всех вещах, которые вы не должны делать как пользователь. Вы должны мыслить творчески, интуитивно и — что тут скажешь — деструктивно. Имейте в виду, что потенциальный хакер не будет восхищаться великолепием вашего кода, который вы создали в команде. При первой же возможности он найдет в ней дырку и расширит ее, чтобы проскользнуть внутрь… совсем как хомячок.
Последняя концепция, межсайтовый скриптинг (XSS), представляет собой хардкорную версию безопасности. Это требует овладения искусством написания сценариев и отправки их, например, по URL-адресу. Здесь не хватит места, чтобы изложить все нюансы этой черной магии. Я рекомендую исследовать этот вопрос дальше, Интернет может помочь.
Сообщить об ошибке
Когда вы, наконец, добрались до этой точки, это означает, что вы думаете, что выполнили свой тест (или, в большинстве случаев, они должны были быть завершены до истечения срока). Во всяком случае, вы сделали некоторые тесты и есть результаты. «Что теперь?» — спросите вы. Хорошо, потому что в этой работе приходится спрашивать (в большинстве случаев вы спрашиваете себя — странно, не так ли?). Теперь вам нужно сообщить об ошибках, которые вы нашли. Вы еще помните пункт номер 4? Да? Нет? Если нет, то быстро идите туда и делайте домашнее задание, не теряя времени.
Чистая процедура
Это самое грустное из всех действий. Как тестер… о, простите! Как тестер — вы должны убрать беспорядок, который вы создали. Удалите все тестовые страницы, ресурсы и все внесенные вами изменения. Будьте ниндзя — оставьте проект в том состоянии, в котором вы его создали. Оставайтесь неуловимым. Никто не увидит, никто не услышит о ваших действиях. Так и должно быть.
Но всегда есть какое-то «но». Иногда вы не можете удалить и очистить все следы, которые вы оставили. Всегда следы, оставшиеся после тестирования, могут быть использованы для воспроизведения ошибок и проверки исправлений. Это зависит от руководства проекта. Если я вызвал у вас сомнения, вернитесь к разделу «Отчеты» в этой статье.
Автоматизация
Это всего лишь предложение, но… в последнее время это очень модно среди тестировщиков. Почему вам нужно тестировать вручную, если машина может сделать это за вас? Хорошо, вам нужны специальные знания по этому вопросу, но это стоит усилий. Это может сэкономить вам время в будущем.
Заключение
Вы можете поместить все эти советы в один красивый контрольный список. Это может помочь вам с вашими тестами. Контрольный список может быть полезным инструментом, если только вы не забываете соблюдать каждый его пункт. Сложность составления чек-листа состоит в том, чтобы расставить пункты в правильном порядке. Конечно, на практике мы часто склонны упускать из виду некоторые моменты, однако важно делать это осознанно. Не стесняйтесь использовать этот инструмент. Это может улучшить работу начинающих тестировщиков и научить их хорошим практикам.
Контрольный список, однако, не оракул. Не доверяйте этому полностью. Не застревайте между графиком и рутиной. Помните, что вы должны использовать свое творческое мышление, знания, опыт и интуицию. Чек-листом должен пользоваться тестер, поэтому не позволяйте ему взять на себя всю вашу работу.
