Web-программирование Лекция 12. Django. Тестирование

1. Web-программирование Лекция 12. Django. Тестирование.

асист. каф. 308 Трутнева Надежда Владимировна
тел: 8-926-880-12-76
почта: [email protected]

2.

python manage.py makemigrations polls
Собираем проект на django
manage.py makemigrations polls

3.

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

4.

Тестирование «черного ящика»
Проверка «черного ящика» – это метод тестирования программного
обеспечения, при котором функциональность исследуется без рассмотрения
кода, деталей реализации и знаний о внутреннем устройстве программного
обеспечения (ПО). Тестировщики пишут тест-кейсы, опираясь только на
требования и спецификацию программного обеспечения.
Достоинства метода:
- Позволяет быстро выявить ошибки в функциональных спецификациях.
- Тестировщику не нужна дополнительная квалификация.
- Тестирование проходит «с позиции» пользователя.
- Составлять тест-кейсы можно сразу после подготовки спецификации.
Метод имитирует поведение пользователя, у которого нет никаких знаний о
внутреннем устройстве программы. Методом «черного ящика» проводятся
следующие виды тестирования:
- функциональное;
- регрессионное;
- usability;
- smoke;
- GUI.

5.

Тестирование «белого ящика»
Проверка «белого ящика» – это метод тестирования программного
обеспечения, который предполагает, что внутренняя структура, устройство и
реализация системы известны тестировщику.
Тестирование в «белом ящике» включает в себя несколько типов
тестирования, применяемых для оценки удобства использования
приложения, блока кода или конкретного программного пакета:
- Unit-тестирование;
- интеграционное;
- системное;
- тестирование безопасности.
Достоинства метода «белого ящика»:
- Оптимизация кода путем нахождения скрытых ошибок.
- Доступность структуры кода позволяет выбрать тип входных данных,
необходимых для эффективного тестирования.
- Возможность автоматизирования тест-кейсов.
Степень сложности тестирования методом «белого ящика» зависит от
сложности вашего приложения/сервиса и от количества функций, которые
оно выполняет.

6.

Тестирование «серого ящика»
Проверка «серого ящика» – это метод тестирования программного
продукта или приложения с частичным знанием его внутреннего устройства.
Для выполнения тестирования «серого ящика» нет необходимости в доступе
тестировщика к исходному коду. Тесты пишутся на основе знания алгоритма,
архитектуры, внутренних состояний или других высокоуровневых описаний
поведения программы.
Виды тестирования «серого ящика»:
- Матричное тестирование.
- Регрессионное тестирование.
- Шаблонное тестирование (pattern).
- Тестирование с помощью ортогонального массива.

7.

Тестирование «серого ящика»
Достоинства метода:
- Тестирование серого ящика включает в себя плюсы тестирования
«черного» и «белого». Другими словами, тестировщик смотрит на объект
тестирования с позиции «черного» ящика, но при этом проводит анализ на
основе тех данных, что он знает о системе.
- Тестировщик может проектировать и использовать более сложные
сценарии тестирования.
- Тестировщик работает совместно с разработчиком, что позволяет на
начальном этапе убрать избыточные тест-кейсы. Это сокращает время
функционального и нефункционального тестирования и положительно
влияет на общее качество продукта.
- Предоставляет разработчику достаточно времени для исправления
дефектов.
Недостатки метода:
- Возможность анализа кода и тестового покрытия ограничена, так как доступ
к исходному коду отсутствует.
- Тесты могут быть избыточными в том случае, когда разработчик также
проверяет свой код Unit-тестами.
- Нельзя протестировать все возможные потоки ввода и вывода, поскольку
на это требуется слишком много времени

8.

Что выбрать?

9.

Особенности тестирования web-приложений

10.

Особенности тестирования web-приложений
1. Технологические отличия.
•Классическое приложение работает с использованием
одной или семейства родственных технологий.
•Web-приложение работает с использованием
принципиально различных технологий.
2. Структурные отличия.
•Классическое приложение “монолитное”. Состоит из
одного или небольшого количества модулей. Не
использует серверы БД, web-серверы и т.д.
•Web-приложение — “многокомпонентное”. Состоит из
большого числа модулей. Обязательно использует
серверы БД, web-серверы, серверы приложений.

11.

Особенности тестирования web-приложений
3. Отличия режимов работы.
•Классическое приложение работает в режиме
реального времени, т.е. известно о действиях
пользователя сразу же, как только оно выполнено.
•Web-приложение работает в режиме “запрос-ответ”, т.е.
известно о некотором наборе действий только после
запроса на сервер.

12.

Особенности тестирования web-приложений
4. Отличия формирования интерфейса.
•Классическое приложение использует для формирования
интерфейса пользователя относительно устоявшиеся и
стандартизированные технологии.
•Web-приложение использует для формирования пользовательского
интерфейса стремительно развивающиеся технологии, множество
которых конкурирует между собой.
5. Отличия работы с сетью.
•Классическое приложение практически не использует сетевые каналы
передачи данных.
•Web-приложение активно использует сетевые каналы передачи
данных.
6. Отличия запуска и остановки.
•Классическое приложение запускается и останавливается редко.
•Web-приложение запускается и останавливается по факту
поступления каждого запроса, т.е. очень часто.

13.

Особенности тестирования web-приложений
7. Разница в количестве пользователей.
•Классическое приложение: количество пользователей,
одновременно использующих приложение, подвержено
контролю, ограничено и легко прогнозируемо.
•Web-приложение: количество пользователей,
одновременно использующих приложение,
сложнопрогнозируемо и может скачкообразно меняться в
широких диапазонах.
8. Особенности сбоев и отказов.
•Классическое приложение: выход из строя тех или иных
компонентов сразу становится очевидным.
•Web-приложение: выход из строя некоторых компонентов
оказывает непредсказуемое влияние на
работоспособность приложения в целом.

14.

Особенности тестирования web-приложений
9. Отличия в инсталляции.
•Классическое приложение — процесс инсталляции
стандартизирован и максимально ориентирован на
широкую аудиторию пользователей. Не требует
специфических знаний. Добавление компонентов
приложения выполняется стандартным способом с
использованием одного и того же инсталлятора.
•Web-приложение — процесс инсталляции часто
недоступен конечному пользователю. Инсталляция
требует специфических знаний. Процесс изменения
компонент приложения не предусматривается или
требует квалификации пользователей. инсталлятор
отсутствует.

15.

Особенности тестирования web-приложений
10. Отличия в деинсталляции.
•Классическое приложение: процесс деинсталляции
стандартизирован и выполняется автоматически или
полуавтоматически.
•Web-приложение: процесс деинсталляции требует специфических
знаний для вмешательства администратора и часто сопряжен с
изменением кода среды функционирования приложения, БД,
настройки системного ОС.
11. Особенности среды функционирования.
•Классическое приложение: среда функционирования
стандартизирована и не сильно влияет на функционирование
приложения.
•Web-приложение: среда функционирования очень разнообразна и
может оказать серьезное влияние на работоспособность и
серверной, и клиентской части.

16.

Уровни тестирования
Тестирование компонентов (unit-тестирование) — тестируется минимально
возможный для тестирования компонент, например, отдельный класс или функция.
Часто тестирование компонентов осуществляется разработчиками программного
обеспечения.
Интеграционное тестирование — тестируются интерфейсы между компонентами,
подсистемами или системами. При наличии резерва времени на данной стадии
тестирование ведётся итерационно, с постепенным подключением последующих
подсистем.
Системное тестирование — тестируется интегрированная система на её соответствие
требованиям.
Альфа-тестирование — имитация реальной работы с системой штатными
разработчиками, либо реальная работа с системой потенциальными
пользователями/заказчиком. Чаще всего альфа-тестирование проводится на
ранней стадии разработки продукта, но в некоторых случаях может применяться
для законченного продукта в качестве внутреннего приёмочного тестирования.
Бета-тестирование — в некоторых случаях выполняется распространение
предварительной версии для некоторой большей группы лиц с тем, чтобы
убедиться, что продукт содержит достаточно мало ошибок. Иногда бетатестирование выполняется для того, чтобы получить обратную связь о продукте
от его будущих пользователей.
Часто для свободного и открытого программного обеспечения стадия альфатестирования характеризует функциональное наполнение кода, а бета-тестирования —
стадию исправления ошибок. При этом как правило на каждом этапе разработки
промежуточные результаты работы доступны конечным пользователям.

17.

Модульное тестирование (unit-тесты) в
Django

18.

Модульное тестирование (unit-тесты) в
Django

19.

Selenium WebDriver
Selenium — это инструмент для автоматизации действий веб-браузера. В
большинстве случаев используется для тестирования Web-приложений, но
этим не ограничивается. В частности, реализация Selenium WebDriver для
браузера phantomjs часто используется как веб-граббер.

20.

Спасибо за внимание !
ВОПРОСЫ???