Тестирование продукта

Материал из AOW

Перейти к: навигация, поиск

Содержание

Тестирование сайта на его соответствие техническому заданию включает в себя:

  • Проверку работы всех обязательных функций сайта.
  • Проверку работы поиска (включая релевантность результатов).
  • Тестирование всех форм (например, обратная связь, добавление комментария в блог), в том числе анти-спам фильтры, шаблоны отправляемых писем и т.д.
  • Тестирование сайта при выключенном Javascript, Flash и других плагинах
  • Просмотр сайта на мониторах с различной разрешающей способностью.
  • Проверку времени загрузки всех страниц сайта при заданной скорости соединения с Интернет.
  • Проверку возможности просмотра сайта и правильности отображения цветов при различном количестве цветов, установленных на мониторе.
  • Проверку сайта при просмотре его на различных браузерах (IE, Firefox, Opera, Chrome т.д.) и их версиях.
  • Проверку гиперссылок, поиск и устранение сломанных гиперссылок.
  • Проверку правильности отображения шрифтов на различных браузерах (IE, Firefox, Opera, Chrome т.д.) и их версиях.
  • Проверку загрузки всех графических материалов сайта (рисунки, фотографии и т.д.).
  • Проверку замещающих надписей графических материалов.
  • Проверку работоспособности счётчиков, установленных на страницах сайта.
  • Проверку описания, содержания, свойств страниц сайта и мета-тэгов каждой страницы.
  • Проверку орфографии на страницах сайта.
  • Просмотр на соответствие содержимого страниц сайта исходному контенту, представленному заказчиком.

WEB тестирование можно классифицировать по объекту тестирования

  • Функциональное тестирование.

Функциональное тестирование проверяет, что система работает в точности, как и описано в спецификации (требованиях к системе).

  • Тестирование юзабилити.

Тестирование предназначено для оценки удобства пользования системой и соответствующих рекомендаций по её улучшению.

  • Тестирование безопасности.

Тестирование безопасности — это множество вещей, суть которых заключается в том, чтобы усложнить условия для кражи — кражи данных, денег и информации.

Функциональное тестирование

  • Необходимо проверить релевантность результатов поиска.
  • Обязательный ввод. В спецификации приложения четко определены поля требующие обязательного ввода данных. Необходимо проверить формы, которые имеют поля, определенные как обязательные для ввода, не могут быть сохранены при отсутствии данных в них.
  • Типы данных полей. В спецификации четко определены типы данных для каждого из полей (поля даты/времени, числовые поля, поля для ввода номера телефона или почтового кода и т.д.). Необходима проверка, что каждое из полей позволяет вводить или сохранять данные только определенного спецификацией типа (например, приложение не должно позволять вводить или сохранять буквы или специальные символы в числовых полях).
  • Размер поля. В спецификации четко определено максимально допустимое количество символов в каждом из полей (например, количество символов в поле с именем пользователя не должно превышать 50). Нужно проверить, что приложение не позволяет вводить или сохранять большее количество символов, нежели указано в спецификации. Не нужно забывать и о том, что данные поля, не только должны правильно функционировать, но и предупреждать пользователя об ограничениях, например, с помощью пояснительных надписей или сообщений об ошибках.
  • Числовые граничные значения. Числовые поля приложения могут иметь ограничения допустимых числовых значений. Эти ограничения могут быть указаны в спецификации приложения либо вытекать из логики работы программы (например, если тестируется функциональность связанная с начислением процентов на счет, то вполне логичным будет предположение, что начисленные проценты не могут принимать отрицательное значение). Необходимо проверить, что приложение выдает сообщение об ошибке в случае, если значения лежат за пределами допустимого диапазона (например, сообщение об ошибке должно появляться при вводе значений 9 или 51 в поле с допустимым диапазоном значений от 10 до 50, либо при вводе отрицательного значения в поле, значения которого должны быть положительными).
  • Числовые ограничения. Большинство баз данных и языков программирования определяют числовые значения как переменные с некоторым типом (например, integer или long integer), которые, в свою очередь, имеют ограничения допустимых числовых значений (например, значения integer должны находиться в диапазоне от -32768 до 32767, а long integer от -2147483648 до 2147483647). Проверка граничных значений используемых переменных, для числовых полей, граничные значения которых четко не определены спецификацией.
  • Граничные значения даты. Очень часто в приложениях существуют логические ограничения для полей содержащих дату и время. Например, если производить проверку поля содержащего дату рождения пользователя, то вполне логичным будет запрет ввода еще не наступившей даты (т.е. даты в будущем), либо ограничение на ввод даты отличающейся от сегодняшней более, чем на 150 лет.
  • Валидность даты. Поля даты всегда должны иметь проверку валидности введенных значений (например, 31-10-2009 – не валидная дата). Также, не нужно забывать и о проверке дат в високосном году (годы кратные 4м и кратные 100 и 400 одновременно - високосные).
  • Веб сессии. Множество веб приложений используют браузерные сессии для отслеживания пользователей вошедших в систему, применения специфических настроек приложения для конкретного пользователя и т.д. При этом, многие функциональные части системы не могут или не должны работать без предварительного входа в систему. Необходимо проверить, что функциональность или страницы, находящиеся за паролем, недоступны пользователю не прошедшему авторизацию.
  • Проверить работоспособность сайта с выключенным Javascript, Flash, и другими компонентами
  • Проверить вид сайта на разных разрешениях экрана (1280×1024, 1024×768, 1920×1200, 800×600...)
  • Проверка правильности отображения страниц при увеличенном зуме. Необходимо проверять как и увеличение зума всей страницы, так и увеличение масштаба текста. В последнем случае будет хорошо заметно, расползается ли верстка.
  • Проверить работу сайта в разных браузерах (Internet Explorer, Firefox, Opera, Safari, Chrome etc.), версиях (6, 7, 2.2, 3.1 etc.) и платформах (Windows, OSX, Linux).
  • Проверка гиперссылок, поиск и устранение сломанных гиперссылок. Например, утилита Xenu Link Sleuth (мощное средство для поиска ссылок, ведущих на несуществующие страницы, так же осуществляет поиск файлов-сирот и т.п. По окончанию работы есть возможность создания отчета).
  • Просмотр на соответствие содержимого страниц сайта исходному контенту, представленному заказчиком. Так же сюда входит проверка загрузки всех графических материалов сайта(рисунки, фотографии и т.д.), проверка замещающих надписей графических материалов.
  • Проверка работоспособности счетчиков.
  • Проверка содержания, орфографии на страницах сайта.
  • HTML, CSS, JS валидность.

Тестирование юзабилити

Эти десять правил юзабилити выведены Якобом Нильсеном (Jakob Nielsen) - одним из основателей и руководителей компании "Nielsen Norman Group", занимающейся предоставлением консультаций в области юзабилити. Эти правила он сформулировал еще в 1990 году, но, несмотря на это, они все-равно не потеряли своей актуальности. В оригинале их название звучит как "Ten Usability Heuristics".

  • Информированность о состоянии системы. Пользователь всегда должен быть в курсе того, что происходит в системе. При этом обратная связь между пользователем и системой должна быть как можно более логичной и оперативной.
  • Схожесть системы с реальным миром. Система должна общаться с пользователем на понятном ему языке. Использование слов, фраз и понятий знакомых пользователю в реальном мире, намного предпочтительнее, чем использование специализированных терминов. Это позволяет представлять информацию в более естественном и логичном виде.
  • Свобода действий. Пользователи часто ошибаются, поэтому система всегда должна предоставлять очевидный «путь к отступлению», благодаря которому, пользователю понадобится сделать минимум телодвижений, чтобы исправить свою ошибку. Необходимо дать пользователям возможность отмены действий, а также возврата к ранее отмененным действиям.
  • Единообразие и стандарты. Не нужно вводить пользователя в заблуждение, описывая одни и те же вещи разными словами и терминами. Желательно придерживаться единообразия и следования стандартам.
  • Предотвращение ошибок. Даже самые лучшие сообщения об ошибках не смогут сделать систему настолько дружелюбной, насколько это сделает продуманная архитектура, позволяющая эти ошибки предотвращать. Нужно свести к минимуму количество условий, в которых могут быть допущены ошибки, а также требовать от пользователя дополнительного подтверждения своих действий, в случае если он допустил ошибку.
  • На виду, а не в памяти. Не нужно утомлять пользователя, заставляя его запоминать большое количество объектов, действий и опций. Пользователь не должен держать в голове информацию, перемещаясь из одной части системы в другую. Инструкции по использованию системы всегда должны быть на виду или, по крайней мере, должны быть легкодоступны из любой части системы.
  • Гибкость и эффективность. Не стоит нагружать опытных пользователей излишней информацией, лучше предоставить им возможность совершать часто повторяющиеся действия как можно быстрее и проще. При этом постараться скрыть эти возможности от глаз неопытного пользователя.
  • Эстетичный и минималистичный дизайн. Диалоги не должны содержать нерелевантной или мало востребованной информации. Каждое лишнее слово делает восприятие релевантной информации все более сложным.
  • Понимание проблем и их решение. Сообщения об ошибках должны быть выражены на понятном пользователю языке. Они должны как можно более точно описывать проблему и предоставлять возможные варианты ее решения.
  • Справочные материалы и документация. Даже если система может использоваться без документации, в процессе работы с ней все же может потребоваться справочная информация. Подобные документы должны составляться таким образом, чтобы в них легко было найти необходимое. К тому же, справочные материалы должны быть лаконичными и содержать только конкретные руководства к действиям.

Тестирование безопасности

xss уязвимости

  • Закрыть поисковикам доступ к служебным/секретным/закрытым разделам сайта, используя robots.txt
  • Проверить, нет ли у посетителей доступа к служебным/секретным/закрытым страницам.
  • Использовать длинные комплексные пароли и нестандартные логины, периодически выполнять их смену;
  • У большинства SQL баз данных возникают проблемы при наличии одинарных кавычек в запросе (например, Jones’s car). Необходимо при данном тесте использовать одинарные кавычки при проверке каждого поля ввода работающего с базой данных.
  • Желательно настроить расписание резервного копирования, и проверьте результат восстановления из резервной копии.
  • Нужно защитить все критически важные страницы (например, раздел администрирования сайта)
  • Необходимо протестировать web продукта на возможность взлома (например, таким софтом, как XSpider)
  • Выключить вывод текстовых сообщений об ошибках
  • Настроить уведомления по электронной почте и (или) SMS (например, для ошибок или сбоев сервера) для системы внутреннего и внешнего мониторинга
  • Настроить ведение лог файлов на веб-сервере и сервере БД

Полезные советы при тестировании

  • Тестирование полей ввода.

Тестирование полей ввода.

  • Логирование в автотестах.

Качественный логгер очень важный момент в автоматическом тестировании, так как понятные и удобные логии упростят процесс тестирование и сэкономят ваше время. Основные требования к логам:

  1. Логи должны быть ориентированы на различные группы пользователей (машины, тестировщики, разработчики или менеджеры)
  2. Использование HTML
  3. Сохранять стандартный лог (чаще всего подробный, ибо пригодится)
  4. Возможность различных форматов для интеграции
  5. Полнота лога
  6. Возможность сохранять скриншоты (ошибок и проблемных мест, что гораздо упростит работу тестера и програмиста)
  7. Лог должен содержать разнообразные фильтры
  8. Использовать цветовое кодирование (наглядность)
  9. Не забывать про unicode
  • Явные и неявные требования

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


Инструменты

  • Selenium IDE

Selenium - это java-программа, которая умеет запускать браузер и делать в нем различные действия типа клика на кнопку, поиска элемента, ожидания загрузки страницы. Плюсы: Не требует больших навыков тестирования Удобный помощник при создании простых тестов, таких как создание товаров, быстрое заполнение полей, смена статусов продуктов

http://seleniumhq.org/projects/ide/

  • TestComplete.

Полнофункциональная система для автоматизации тестирования приложений. С помощью TestComplete можно выполнять функциональное, узловое, регрессионное, распределенное тестирование, а также тестирование работоспособности HTTP на проектном уровне. С помощью TestComplete можно выполнять систематическое, автоматизированное и структурное тестирование для .NET, Java, Visual C++, Visual Basic, Delphi, C++Builder, web страниц и других приложений. Инструмент позволяет записывать сложные, объектно-ориентированное тестовые действия, которые в дальнейшем могут повторно использоваться практически без изменений. TestComplete ведет подробный журнал всех действий, выполняемых в ходе автоматизированного тестирования и позволяет пользователям добавлять необходимый контент в журнал. Вы сможете осуществлять сортировку, фильтрацию, группировку и другие операции для анализа результатов автоматизированного тестирования. http://smartbear.com/products/qa-tools/automated-testing/

  • Apache JMeter

Apache JMeter - инструмент для проведения нагрузочного тестирования Подробно с инструкцией по проведению нагрузочного тестирования можно ознакомится на Хабре. http://habrahabr.ru/blogs/testing/84190/


Ссылки

Источник — «http://doc.artofweb.ru/doc/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%B0»

Разработка веб-сайтов, автоматизация.
По всем вопросам обращайтесь по телефонам:

+7 495 640 29 90
+7 495 729 07 98
http://artofweb.ru