Lesson 6 guideline. Как правильно тестировать Веб приложения

1. Дата менеджменТ

ДАТА МЕНЕДЖМЕНТ
ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
КИЕВ 2012

2.

Как правильно тестировать
Веб приложения
Основные понятия

3. Протокол HTTP

ПРОТОКОЛ HTTP
HTTP (сокр. от англ. HyperText Transfer Protocol — «протокол
передачи гипертекста») — протокол прикладного уровня
передачи данных (изначально — в виде гипертекстовых
документов).
Основой HTTP является технология «клиент-сервер», то есть
предполагается существование потребителей (клиентов),
которые инициируют соединение и посылают запрос, и
поставщиков (серверов), которые ожидают соединения для
получения запроса, производят необходимые действия и
возвращают обратно сообщение с результатом

4. HTTP

Основным объектом манипуляции в HTTP является ресурс, на
который указывает URI (англ. Uniform Resource Identifier) в запросе
клиента.
Обычно такими ресурсами являются хранящиеся на сервере
файлы, но ими могут быть логические объекты или что-то
абстрактное.
Особенностью протокола HTTP является возможность указать в
запросе и ответе способ представления одного и того же ресурса
по различным параметрам: формату, кодировке, языку и т. д.
Именно благодаря возможности указания способа кодирования
сообщения клиент и сервер могут обмениваться двоичными
данными, хотя данный протокол является текстовым

5. HTTP

Программа для прослушивания траффика – Fiddler
http://fiddler2.com/fiddler2/
• Корректный запрос
• Некорректный запрос
Response codes:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

6. HTTP – пример запроса

HTTP – ПРИМЕР ЗАПРОСА
Запрос клиента:
GET /wiki/страница HTTP/1.1 Host: ru.wikipedia.org User-Agent:
Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509
Firefox/3.0b5 Accept: text/html Connection: close (пустая строка)
Ответ сервера:
HTTP/1.0 200 OK Date: Wed, 11 Feb 2009 11:20:59 GMT Server:
Apache X-Powered-By: PHP/5.2.4-2ubuntu5wm1 Last-Modified: Wed,
11 Feb 2009 11:20:59 GMT Content-Language: ru Content-Type:
text/html; charset=utf-8 Content-Length: 1234 Connection: close
(далее следует запрошенная страница в HTML)

7.

3-х уровневая архитектура
7

8.

9. Основные понятия

ОСНОВНЫЕ ПОНЯТИЯ
Клиент — это интерфейсный (обычно графический) компонент,
который представляет первый уровень, собственно приложение
для конечного пользователя.
Сервер приложений располагается на втором уровне. На втором
уровне сосредоточена бо́льшая часть бизнес-логики.
Сервер базы данных обеспечивает хранение данных и выносится
на третий уровень. Обычно это стандартная реляционная или
объектно-ориентированная СУБД.

10. Основные понятия

ОСНОВНЫЕ ПОНЯТИЯ
Веб-приложение — клиент-серверное приложение, в котором
клиентом выступает браузер, а сервером — веб-сервер.
Сервер приложений (англ. application server ) — это
программная платформа (software framework), предназначенная для
эффективного исполнения процедур (программ, механических
операций, скриптов), которые поддерживают построение
приложений.
Веб-сервер — это сервер, принимающий HTTP-запросы от
клиентов, обычно веб-браузеров, и выдающий им HTTP-ответы,
обычно вместе с HTML-страницей, изображением, файлом, медиапотоком или другими данными. Веб-серверы — основа Всемирной
паутины.

11. Основные понятия

ОСНОВНЫЕ ПОНЯТИЯ
Веб-служба, веб-сервис (англ. web service) —
программная система, идентифицируемая строкой URI, чьи
общедоступные интерфейсы определены на языке XML. Описание
этой программной системы может быть найдено другими
программными системами, которые могут взаимодействовать с ней
согласно этому описанию посредством сообщений, основанных на
XML, и передаваемых с помощью интернет-протоколов.
Используются стандарты:
XML: Расширяемый язык разметки, предназначенный для
хранения и передачи структурированных данных;
SOAP: Протокол обмена сообщениями на базе XML

12.

Тестирование ВЕБ приложения
с нуля – основные виды
тестирования с описанием того,
что именно нужно тестировать

13.

Основные типы тестирования
1) Functionality Testing
2) Usability testing
3) Interface testing
4) Compatibility testing
5) Security testing

14. Functionality Testing – MAIN AREAS

FUNCTIONALITY TESTING – MAIN AREAS
1) all the links in web pages
2) database connection
3) forms used in the web pages for submitting or getting
information from user
4) cookie testing.
тестирование всех ссылок на страницах,
тестирование соединения с базой данных,
тестирование форм для отправки или получения
информации от пользователя,
тестирование Cookie

15. Functionality Testing - LINKS

FUNCTIONALITY TESTING - LINKS
Check all the links – проверка ссылок:
• Проверка всех ссылок
- создание чеклиста
- проход
• Проверка переходов внутри страницы.
• Проверка отправки писем администратору
• Проверка ссылок, которые никуда не ведут и битых ссылок
Сделать на примере www.thomasnet.com

16. Functionality Testing - FORMS

FUNCTIONALITY TESTING - FORMS
1) Проверка валидации полей
2) Проверка начальных значений
3) Проверка некорректного ввода
4) CRUD tests
Пример: http://rutracker.org , http://expekt.com

17. Functionality Testing - COOKIES

FUNCTIONALITY TESTING - COOKIES
Ку́ки (слово не склоняется; от англ. cookie — печенье) — небольшой
фрагмент данных, созданный веб-сервером или веб-страницей и
хранимый на компьютере пользователя в виде файла, который вебклиент (обычно веб-браузер) каждый раз пересылает веб-серверу в
HTTP-запросе при попытке открыть страницу соответствующего сайта.
Применяется для сохранения данных на стороне пользователя, на
практике обычно используется для:
аутентификации пользователя;
хранения персональных предпочтений и настроек пользователя;
отслеживания состояния сессии доступа пользователя;
ведения статистики о пользователях.

18. Functionality Testing - COOKIES

FUNCTIONALITY TESTING - COOKIES
Пример проверки
1)
Открыть сайт mail.ru
2) Создать пользователя
3) Зайти под этим пользователем
4) Закрыть сайт и войти на сайт ещё раз – сайт помнит пользователя
5) Удалить куки и обновить страницу – сайт не помнит пользователя

19. Functionality Testing - DB

FUNCTIONALITY TESTING - DB
Любое действие, связанное с CRUD тестами, требует
проверки путём написания соответствующего запроса в
базу данных
Задача
1) Придумать структуру таблицы пользователей
2) написать на каждый из CRUD тестов соответствующий
запрос в базу

20. Usability Testing

USABILITY TESTING
• Удобна ли навигация
• Правильное ли наполнение
20

21. Compatibility Testing

COMPATIBILITY TESTING
Compatibility of your web site is very important testing aspect. See
which compatibility test to be executed:
Browser compatibility – проверка в браузерах
Operating system compatibility – проверка на совместимость
операционных систем
Mobile browsing – проверка в мобильных приложениях
21

22. Security Testing

SECURITY TESTING
Test by pasting internal url directly into browser address bar without login. Internal
pages should not open.
Пример – google.com – выйти из своей почты и попробовать ссылку
https://mail.google.com/mail/?shva=1#inbox
If you are logged in using username and password and browsing internal pages
then try changing url options directly. I.e. If you are checking some publisher site
statistics with publisher site ID= 123. Try directly changing the url site ID parameter
to different site ID which is not related to logged in user. Access should denied for
this user to view others stats.
http://job.ukr.net/?event=Login&Id=44994&hashKey=5a229b39af159877aff4bdf4fa
d91ad5&r=http%3A%2F%2Fjob.ukr.net%2Fpersonal%2Fvacancy%2Fnachinajuwijtestirovwik-testirovwik-junior-regular-senior-test-engineer-1186542%2F
Try some invalid inputs in input fields like login username, password, input
text boxes. Check the system reaction on all invalid inputs.
22

23. Security Testing

SECURITY TESTING
Web directories or files should not be accessible directly unless given
download option – отсутствие возможности зайти и посмотреть файлы
сайта без соответствующих прав
Test the CAPTCHA for automates scripts logins – проверка, работает ли
Каптча
If used proper message should get displayed when user switch from nonsecure http:// pages to secure https:// pages and vice versa – проверка,
что для передачи данных кредитной карты используется правильный
протокол – и что эта передача не осуществляется, если протокол не
секьюрный – изменение руцями
All transactions, error messages, security breach attempts should get
logged in log files somewhere on web server – проверка лог файлов на
предмет того, что транзакции все записываются
23

24. Что проЙТИ

ЧТО ПРОЙТИ
• http://www.w3schools.com/html/default.asp
• http://www.w3schools.com/xml/default.asp
• http://www.w3schools.com/web/default.asp

25. Автоматизированное тестирование

АВТОМАТИЗИРОВАННОЕ ТЕСТИРОВАНИЕ
ОСНОВНЫЕ ПОНЯТИЯ

26. Практические соображения

ПРАКТИЧЕСКИЕ СООБРАЖЕНИЯ
• Автоматизированное тестирование ПО – это вид тестов, а
не фаза тестирования
• Автоматизация тестирования не начинается
после какого-то другого этапа тестирования
• Потенциально практически любой тест может быть
автоматизирован
• Не все тесты должны быть автоматизированы
26

27. КАКОЕ ТЕСТИРОВАНИЕ АВТОМАТИЗИРУЮТ

В зависимости от объектов тестирования выделяют
следующие виды тестирования:
• Функциональное
• Регрессионное
• Нагрузочное
27

28.

ВИДЫ АВТОМАТИЧЕСКОГО ТЕСТИРОВАНИЯ
Функциональное тестирование позволяет:
• Выполнить прогон тестов под максимально возможным
количеством поддерживаемых аппаратно-программных
конфигураций
• Использовать для прогона тестов нерабочее время
тестировщиков
• Выделить тестирование устоявшейся и новой
функциональности
28

29. Виды Автоматического тестирования

ВИДЫ АВТОМАТИЧЕСКОГО ТЕСТИРОВАНИЯ
Нагрузочное тестирование позволяет:
• Определить время реакции приложения
• Определить, какое количество пользователей может
поддерживать система
• Определить оптимальную конфигурацию системы
29

30. Виды Автоматического тестирования

ВИДЫ АВТОМАТИЧЕСКОГО ТЕСТИРОВАНИЯ
Регрессионное тестирование позволяет:
• Проверить постоянно растущий функционал системы
• Проверить самые важные бизнес транзакции
• Проверить ранее возникшие критические баги
30

31. ЧТО НУЖНО АВТОМАТИЗИРОВАТЬ

Труднодоступные места в системе (бэкенд процессы, логирование файлов,
запись в БД)
Часто используемая функциональность, риски от ошибок в которой достаточно
высоки. Автоматизировав проверку критической функциональности, можно
гарантировать быстрое нахождение ошибок, а значит и быстрое их решение.
Рутинные операции, такие как переборы данных (формы с большим
количеством вводимых полей. Автоматизировать заполнение полей
различными данными и их проверку после сохранения)
Валидационные сообщения (Автоматизировать заполнение полей не
корректными данными и проверку на появление той или иной валидации)
Длинные end-to-end сценарии
Проверка данных, требующих точных математических расчетов
Проверка правильности поиска данных

32. ЧТО НЕ НУЖНО АВТОМАТИЗИРОВАТЬ

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

33. Как пишется тестовый фреймворк

КАК ПИШЕТСЯ ТЕСТОВЫЙ ФРЕЙМВОРК
Выделяются сценарии
Анализируются на предмет пригодности

34. ВХОДНЫЕ И ВЫХОДНЫЕ ДАННЫЕ

Пример файла с тестовыми данными.xls

35. КОДИРОВАНИЕ

36. Наиболее часто используемые функции- в ФРЕЙМВОРК

НАИБОЛЕЕ ЧАСТО ИСПОЛЬЗУЕМЫЕ ФУНКЦИИ- В ФРЕЙМВОРК

37. СОЗДАНИЕ УПРАВЛЯЮЩЕГО ФАЙЛА

Sl #
Module / Project Name
1 Channel
2 Items
3 Item_ID
4 Search
5 Search_SC_new
6 Search_SC_old
7 Search_SCE_new
8 Search_SCE_old
9 Search_SF_new
10 Search_SF_old
11 Search_SNF
12 Search_WS_new
13 Search_WS_old
14 Entities
15 RelatedItems
16 RelatedLinks
17 FieldList
18 FieldGroups
19 DefaultFieldGroups
20 EntityResolution
21 LinkSources
22 LinkSourceGroups
23 DefaultLinkSourceGroups
24 Embargo
25 Outcode
26 RSS-OLR
27 RSS-Wirefeed
28 RSS-ChannelList
29 RSS-Items
30 Packages
31 Olr
32 Ping
33 PingBRV
34 RSS-Search
35 User_Permissions
scheduleFlag
Remarks
No
No
No
No
Yes
No
No
Don't use. Not ready
Yes
Don't use. Not ready
No
Don't use. Not ready
Yes
Don't use. Not ready
No
Don't use. Not ready
No
Don't use. Not ready
Yes
Don't use. Not ready
No
No
Yes
No
No
Yes
No
No
Yes
No
No
No
No
No
No
No
No
No
No
No
No
No

38. СОЗДАНИЕ УДОБНОГО ОТЧЁТА

39. ИНСТРУМЕНТЫ ДЛЯ ТЕСТИРОВАНИЯ

Компания
Hewlett-Packard (Mercury
Interactive)
IBM Rational
Borland (Segue)
AutomatedQA Corp
Microsoft
OpenQA
Инструмент
QuickTest Professional, WinRunner
Rational Robot, Rational Functional
Tester
SilkTest
TestComplete
Microsoft VS 2005
Selenium

40. Домашнее задание

ДОМАШНЕЕ ЗАДАНИЕ
Создание тест кейсов
по основным видам тестирования
веб приложения для сайта
www.expekt.com
Написать по одному тест кейсу на каждую ситуацию из
нижеперечисленных видов тестирования
1) Functionality Testing
2) Usability testing
3) Interface testing
4) Compatibility testing
5) Security testing