Академический Документы
Профессиональный Документы
Культура Документы
Когда у нас есть список треб. К системе мы составляем утверждение, какие задачи
должна система реализовывать.
Цели тестирования
Задачи:
Цикл тестирования ПО
1. Функциональное
2. Нефункциональное
1. По состоянию
2. По знанию системы
3. По степени автоматизации:
· Ручное тестирование
Уровни тестирования
Функциональные дефекты:
Дефекты документации
Дефекты производительности
1. Человеческий фактор
· Ошибки спецификации
· Ошибки проектирования
Отчет об ошибке
Отчет об ошибке:
1. Заголовок (Title) – информативное и сжатое описание проблемы (Где – место
системы? Что – что пошло не так? Когда – в какой момент?)
3. Фактический результат (Actual result) – то как система ведет себя на самом деле
· Высокий (high)
· Средний (medium)
· Низкий (low)
· Тестовое окружение
Серьёзность: critical
Приоритет: high
Описание
Шаги по воспроизведению:
3. Зайти в корзину
2. Выйти из системы
Может быть допущена ошибка при программировании, а может потому что идет
загрузка.
Если на этапе разработки был обнаружен баг в требования, нужно повторять снова
этап анализа и разработки.
Если обнаружили баг на этапе внедрения, то нужно проходить больше шагов: анализ –
разработка – тестирование – внедрение. Потратится в два раза больше времени, чем
могли бы в идеальном случае. Тестирование должно проводится уже на этапе анализа
и быть внедрено в каждый этап разработки.
Эмоциональный интеллект:
Виды:
§ цели
§ требования к системе
§ возможные риски
§ список артефактов
§ необходимые ресурсы
§ ответственные за тестирование
· Тестовый случай
2. Тестовое окружение
4. Дата тестирования
2. Автор (author)
4. Приоритет дефекта
5. Серьезность дефекта
9. Предусловия
11. Постусловия
§ Финальный отчет
§ Состав команды
Основы тест-дизайна
§ Тестирование документации
§ Какие есть роли пользователя (разные наборы функций для разных категорий
пользователя)?
§ Зарегистрированный пользователь
o Обмениваться сообщениями
o Добавлять друзей
o Создавать записи
o Оставлять комменты
o …
§ Админ группы
§ Незарег пользователь
Составляем тест-кейсы:
Нужно знать какие параметры есть на входе и какие данные получаем на выходе, как
входные параметры влияют на результат.
Как входные параметры влияют на результат: видим то что постит друг, что постит
сообщество, не видим тех, кто в черном списке.
Части диаграммы:
· Состояние (state)
· ПЕРЕХОД (transition)
Таблица переходов
Т С Р Нов
е о еа ое
к б кц сос
у ы ия тоя
щ т ние
е и
е е
с
о
с
т
о
я
н
и
е
В з В под
ы а ал тве
б п ид ржд
о о ац ени
р л ия е
б н ф
и и ор
л т м
е ь ы
т
о
в
В о Уд Отм
ы т ал ена
б м ен зак
о е ие аза
р н ин
б и ф
и т ор
л ь м
е ац
т ии
о о
в за
ка
зе
из
ба
з
ы
… … … …
о о С бил
п п ов ет
л л ер
а а ш
т т ит
а и ь
т де
ь не
ж
н
ы
й
пе
ре
во
д
Это полезно если приложение сложное, у него много частей и есть много
сценариев взаимодействия.
Количество классов:
· 1-10
· 11-99
· Больше 99
· Дробное число
(не полный перечень, все зависит от того что нужно для проверки)
· Дата и время: границы минуты, часа, дня, недели, месяца, года, столетия;
несуществующие значения;
29 февраля;
часовые пояса;
соотношение с «сейчас»;
Описание тест-кейсов
· Обязательно:
o Заголовок (title)
o Шаги (steps)
o Ожидаемый результат (expected result) – чтобы было понятно был баг
или нет для других людей
Steps:
· Чтобы не забыть
Пример тест-дизайна:
Архитектура веб-приложения.
Сайт, на котором есть какой-то интерактив. Эл. Почта, соц сеть, онлайн банк и др.
· клиент – браузер
Особенности
· Много клиентов
· Много серверов
Связь
(Для chrome) Для начала вызываем инструменты разработчика (developer tools): f12
или ctrl+shift+I или cmd+opt+i
На вкладке нетворк в нижней части выделите нужный вам запрос, в правой части на
вкладке хедерс нажать на кнопку вью ресорс
Структура HTTP-сообщения
Get (метод)
Заголовки (Headers)
Cache-control: max-age=0
Content-type: “application/json”
…………………..dfsgg……………………
Методы HTTP-запросов
Адрес сайта
Картинка
Код статуса: целое трёхзначное число, часть стартовой строки ответа сервера
HTTP/1/1 200 OK
· 200 – ok
Клиент:
Структура страницы:
Первоначально dom может меняться динамически. Для этого используется java script –
это скриптовый язык программирования. Он обеспечивает интерактивность на стороне
клиента: анимация, валидация, взаимное расположение и др.
Ошибки при работе java script можно видеть в консоли браузера, которая находится в
инструментах разработчика.
1. Отправка запроса
Практика:
Данные:
Кэш
Типы:
При таком разрешении человеческий глаз перестает замечать, что картинка состоит из
пикселей.
Тестирование обновлений:
Android
IOS
● уникальное имя
● опр. категория
● ссылка для обратной связи с разработчиком
● Human interface Guidelines
● отказ в сертификации по некоторым причинам
● утечка памяти
● обработка ситуаций нехватки памяти для функционирования ОС
● недостаток места для установки или работы приложения
● отсутствие в некоторых устройствах поддерживаемых приложением функций
● установка и перенос на сд карту
● потребление электроэнергии
● временные файлы
Проблемы тестирования
Инструменты тестирования:
● perfecto mobile
● device everywhere
● …
Автоматизация тестирования:
Проектный треугольник
Плюсы:
● стабильность требований
● фиксированный порядок этапов проекта
● простота планирования затрат и сроков завершения работ
● полная и согласованная документация на каждом этапе
● прозрачность процессов (фиксированность результатов и их сроков, мы знаем
что мы делаем и что будем делать дальше)
Минусы:
● отсутствие обратной связи между этапами (мы не можем просто вернуться к
анализу и поправить маленький кусочек)
● высокая стоимость ошибки
● нельзя изменить требования (их хочется менять, чтобы они лучше подходили к
реальности)
● у клиента и пользователей нет возможности ознакомиться с предварительной
версией ПО
Agile
Для того, чтобы было возможно создать продукт, используются итертивные разработки.
Основные идеи:
Принципы agile-манифеста.
Итерация/Спринт (Sprint)
● промежуток времени от 1 недели до 1 месяца (длина итерации), на практике 2-3
недели
● в конце итерации есть готовый инкремент (вариант) продукта
● длина итерации не меняется (если две недели, то всегда две недели)
● задачи заканчиваются в той итерации, в которой начались (отличительная черта
скрама)
● не более одного дня задержки между итерациями
● для каждой задачи команда знает, каким образом и от кого получить доп.
информацию
Kanban
Принципы:
● визуализировать работы (доска не сильно отличается)
● завершать каждую задачу как можно быстрее к пользователю (сначала
завершаем то, что уже в работе) задачи максимально быстро продвигаются в
колонку готово
- непрерывная поставка (continuous delivery) - новая разработка
оказывается у пользователя автоматически, не нужно ждать конца
спринта
Спиральная модель.
● итеративная разработка (на один виток спирали может приходиться как одна
итерация, так и несколько)
● недостающую работу можно будет выполнить на следующей итерации
● главная задача - как можно быстрее показать первую работающую версию
продукта (быть продукту или не быть)
Основные риски:
● дефицит специалистов (риск менеджера)
● нереалистические сроки и бюджеты (качество влияет на сроки и на бюджет)
● реализация несоответствующей функциональности (риск разработать не то)
● разработка неправильного интерфейса
● “золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание
деталей при плохо сделанной основной функциональности
● непрекращающийся поток изменений
● нехватка информации о внешних компонентах, определяющих окружение
системы или вовлеченных в интеграцию
● недостатки в работах, выполняемых внешними (по отношению к проекту)
ресурсами
● недостаточная производительность получаемой системы
● разрыв между квалификацией специалистов и требованиями проекта