Над чем мы проводим тесты (модуль, группа модулей, система)

Методы тестирования

Мы работаем с кодом системы?

— НЕТ = метод «черного» ящика (black-box)

— Частично = метод «серого» ящика (grey-box)

— ДА = метод «белого» ящика (white-box)

Уровни тестирования

Над чем мы проводим тесты (модуль, группа модулей, система)

— Компонентное/модульное (component/unit testing)

— Интеграционное (integration testing)

— Системное (system testing)

А также вторая классификация:

— Приемочное (smoke test, acceptance testing)

— Тест критического пути (critical path test)

— Расширенный тест (extended test

 

Виды тестирования по преследуемым целям разбиваются на группы:

— Функциональные виды Тестируем функции и взаимодействия с другими системами

Пишем тесты на всех уровнях тестирования (компонентное / интеграционное / системное; приемочное/ тестирование критического пути/расширенное тестирование)

Изучаем, как внешне ведет себя система

Функциональное тестирование (functional testing)

Тестирование новой функциональности (new feature testing)

Тестирование безопасности (security testing)

— Нефункциональные виды Тестируем то, «как» система работает

Виды:

1. Тестирование производительности (performance testing): Тестирование производительности (performance testing) - тестирование, которое проводится с целью определения, как быстро работает система или её часть под определённой нагрузкой.

А) нагрузочное (performance & load testing) Нагрузочное тестирование (performance & load testing) – это автоматизированное тестирование, которое имитирует одновременную работу множества пользователей над тестируемым приложением. \

B) стрессовое ( stress testing)Стрессовое тестирование (stress testing)позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса.

C) тестирование стабильности / надежности (stability / reliability testing) Тестирование стабильности / надежности (stability / reliability testing)- проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.

D) тестирование объемами (volume testing) Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит: измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций. может производиться определение количества пользователей, одновременно работающих с приложением

2. Установочное тестирование (installation testing); Тестирование установкинаправленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения.

3. Тестирование удобства пользования (usability testing); Тестирование удобства пользования (usability testing)- это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.

4. Тестирование на отказ и восстановление (failover & recovery testing); Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).

5. Конфигурационное тестирование(configuration testing)Конфигурационное тестирование (Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)

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

7. Локализационное тестирование (localisation testing) –проверяет, насколько корректно продукт адаптирован к работе на том или ином языке: всё ли переведено и переведено правильно, не нарушилась ли логика построения интерфейса и обработки данных и т.д. Для локализационного тестирования рекомендуется обязательно приглашать в команду носителя того языка, перевод на который тестируется.

8. Тестирование документации (document testing) Тестирование

9. Тестирование совместимости (compatibility testing)Тестирование совместимости (compatibility testing) - вид нефункционального тестирования, основной целью которого является проверка корректной работы продукта в определенном окружении. Окружение может включать в себя следующие элементы:

Аппаратная платформа;

Сетевые устройства;

Периферия (принтеры, CD/DVD-приводы, веб-камеры и пр.);

Операционная система (Unix, Windows, MacOS, ...)

Базы данных (Oracle, MS SQL, MySQL, ...)

Системное программное обеспечение (веб-сервер, антивирус, ...)

Браузеры (Internet Explorer, Firefox, Opera, Chrome, Safari)

— Виды, связанные с изменениями Дымовое тестирование (smoke testing)

Регрессионное тестирование (regression testing)

Тестирование сборки (build verification testing)

Проверка согласованности/исправности (sanity testing)

Жизненный цикл ПО

— Формирование и анализ требований Тестирование требований на вменяемость/ осуществимость

— Тестирование функциональной спецификации

— Создание предварительных тестовых сценариев на основе требований

— Проектирование Тестирование документов, описывающих архитектуру (product architecture) и дизайн (product design)

— Тестирование плана проекта

— Реализация Тестирования кода и модульное тестирование

— Тестирование результатов итерации разработки

— Регрессионное тестирование

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

— Внедрение Тестирование совместимости продукта с существующей инфраструктурой заказчика (типы серверов, окружение и т. д.)

— Сбор и обработка обратной связи о приложении от пользователей

— Эксплуатация и сопровождение Обработка отчетов об ошибках от пользователей во время эксплуатации

— Верификация исправления ошибок

— Обработка запросов новой функциональности

— Тестирование новой функциональности

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

Гибкая методология разработки(англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Итеративный подход (англ. iteration, «повторение») в разработке программного обеспечения— это выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы.

Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл:

Планирование — Реализация — Проверка — Оценка (англ. plan-do-check-act)

ü Снижение воздействия серьёзных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение

ü Организация эффективной обратной связи проектной команды с потребителем (а также заказчиками) и создание продукта, реально отвечающего его потребностям

ü Акцент усилий на наиболее важные и критичные направления проекта

ü Непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом

ü Раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта

ü Более равномерная загрузка участников проекта

ü Эффективное использование накопленного опыта

ü Реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении

ü Затраты распределяются по всему проекту, а не группируются в его конце

манифест

— Люди и взаимодействие важнее процессов и инструментов

— Работающий продукт важнее исчерпывающей документации

— Сотрудничество с заказчиком важнее согласования условий контракта

— Готовность к изменениям важнее следования первоначальному плану

Scrum (от англ. scrum «схватка») — методология управления проектами, активно применяющаяся при разработке информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки.

— Спринт (Sprint)— итерация в скраме, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель.

— Резерв спринта (Sprint backlog)— содержит функциональность, выбранную владельцем проекта из резерва проекта.

Все функции разбиты по задачам, каждая из которых оценивается скрам-командой.

Каждый день команда оценивает объем работы, который нужно проделать для завершения спринта.

— История спринта (Sprint Story)— Требуемая функциональность, которую добавляют в резерв, часто называют историей. Зачастую история имеет следующую структуру: «Будучи пользователем <тип пользователя> я хочу сделать <действие>, чтобы получить <результат>».

Такая структура удобна тем, что понятна как разработчикам так и заказчикам.

История, которая исходит от пользователя, называется «Пожелание пользователя» (User Story)

«Свиньи» полностью включены в проект и в скрам-процесс.

— Скрам-мастер (ScrumMaster)— проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрам, разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса. Руководитель проекта скорее относится к владельцу проекта и не должен фигурировать в качестве скрам-мастера.

— Владелец продукта (Product Owner)— представляет интересы конечных пользователей и других заинтересованных в продукте сторон.

— Скрам-команда (Scrum Team)— кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.

Пользователи (Users)

Клиенты, Продавцы (Stakeholders) — лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).

Управляющие (Managers) — люди, которые управляют персоналом.

Эксперты-консультанты (Consulting Experts)

Планирование

Ежедневное совещание (Daily Scrum meeting):

— Начинается точно вовремя

— Все могут наблюдать, но только «свиньи» говорят

— Длится не более 15 минут

— Проводится в одном и том же месте в течение спринта.

В течение совещания каждый член команды отвечает на 3 вопроса:

— Что сделано с момента предыдущего ежедневного совещания?

— Что будет сделано с момента текущего совещания до следующего?

— Какие проблемы мешают достижению целей спринта? (Над решением этих проблем работает скрам мастер. Обычно это решение проходит за рамками ежедневного совещания и в составе лиц, непосредственно затронутых данным препятствием.)

— Обзор итогов спринта (Sprint review meeting) Проводится после завершения спринта:

— Команда демонстрирует инкремент функциональности продукта всем заинтересованным лицам.

— Привлекается максимальное количество зрителей.

— Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).

— Нельзя демонстрировать незавершенную функциональность.

— Ограничена четырьмя часами в зависимости от продолжительности итерации и инкремента продукта.

Требования (requirements) – это подробное изложение функционального наполнения системы.

Проектную документацию (project documentation):

Ø Требования к программному продукту (product requirements).

Ø Функциональные спецификации к программному продукту (functional specifications).

Ø Архитектуру (architecture) и дизайн (design).

Ø План проекта (project plan) и тестовый план (test plan).

Ø Тестовые случаи и сценарии (test cases, test scenarios).

Сопроводительную документацию (и документацию для пользователей):

Ø Интерактивную помощь (on-line help).

Ø Руководства по установке (Installation guide) и использованию программного продукта (user manual).

Ø 1. На верхнем уровне представлены так называемые бизнес-требования (business requirements).
Пример бизнес-требования: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия.
2. Следующий уровень — уровень требований пользователей (user requirements). Пример требования пользователя:система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение.

Ø Требования пользователей часто бывают плохо структурированными, дублирующимися, противоречивыми. Поэтому для создания системы важен третий уровень, в котором осуществляется формализация требований.
3. Третий уровень — функциональный (functional requirements).
Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удалён и перемещён с участка на участок.

Источники требований

— Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения)

— Нормативное обеспечение организации (регламенты, положения, уставы, приказы)

— Текущая организация деятельности объекта автоматизации

— Модели деятельности (диаграммы бизнес-процессов)

— Представления и ожидания потребителей и пользователей системы

— Журналы использования существующих программно-аппаратных систем

— Конкурирующие программные продукты

— Соображения, высказанные представителем заказчика (сотрудники аналитической группы исполнителя, внешних экспертов и т.д.)

— Артефакты, описывающие предметную область

— «Лучшие практики» («best practices»)

Пути выявления требований

— интервью (заказчик)

— анкетирование (заказчик, пользователи)

— наблюдение (за целевыми пользователями)

— самостоятельное описание

— семинары (заказчик, пользователи)

— прототипирование

Требования помогают

— Важность тестирования требований состоит в том, что хорошие требования позволяют:

— Достичь общего понимания между заказчиком и разработчиком

— Определить рамки проекта

— Более точно определить финансовые и временные характеристики проекта.

— Обезопасить заказчика от риска получить продукт, в котором он не сможет работать

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

— Каждое требование должно быть:

— Завершённым (complete). Все важные аспекты должны быть включены. Ничто не должно быть оставлено «для будущего определения» (TBD – to be defined).

— Непротиворечивым (consistent). Требование не должно содержать противоречий как внутри себя, так и с другими требованиями.

— Корректным (correct). Требование должно чётко указывать на то, что должно выполнять приложение. Недопустимо при написании требования предполагать, что что-то окажется очевидным. Каждый человек понимает это «очевидное» по-своему, и в итоге система получится не такой, как задумывалось.

— Недвусмысленным (unambiguous). Требование не должно допускать разночтений.

— Проверяемым (verifiable). Требование должно быть сформулировано так, чтобы существовали способы однозначной проверки – выполнено требование или нет.

— Наборы требований должны быть:

— Модифицируемыми (modifiable). Структура и стиль набора требований должны быть такими, чтобы набор требований можно было легко модифицировать. Должна отсутствовать избыточность. Должно быть построено корректное содержание всего документа.

— Прослеживаемыми (traceable). У каждого требования должен быть уникальный идентификатор, по которому на это требование можно сослаться.

— Проранжированными по важности, стабильности и срочности (ranked for importance, stability and priority). Для каждого требования должен быть указан уровень его важности (насколько оно важно для заказчика), стабильности (насколько высока вероятность, что это требование ещё будет изменено в процессе обсуждения деталей проекта) и срочности (как быстро требование должно быть реализовано).

Проблемы с требованиями

— Проблема незавершенности (неполноты)

— Проблема «To Be Defined»

— Проблема противоречивости

— Проблема некорректности

— Проблема двусмысленности

— Проблема непроверяемости

— Проблема немодифицируемости

— Проблема непрослеживаемости

— Проблема непроранжированности

— Одна из наиболее распространённых техник работы с требованиями – взаимный перепросмотр.

— Суть взаимного перепросмотра требований проста: после того, как один человек создал требование, другой человек это требование проверяет.

— Обычно, выделяют три уровня перепросмотра:

— Неформальный перепросмотр. Двое коллег просто обмениваются листиками (файликами) и правят найденные ошибки, которые потом обсуждаются за чашкой чая или в любое другое относительно свободное время.

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

— Формальная инспекция. Проводится редко и в случае очень больших проектов и крайней необходимости. Описывается специальными стандартами, требует соблюдения широкого спектра правил и протоколирования результатов.

— Существует три простые техники работы с требованиями: задавать вопросы, писать тест кейсы и рисовать рисунки.

— Самый простой и не требующий большого опыта способ – задавать как можно больше вопросов. Получая разнообразные ответы от разных участников проекта (как наших коллег так и представителей заказчика), мы расширяем, углубляем и уточняем своё представление о том, что и как должно работать.

— Второй способ – создавать тест-кейсы (о которых мы поговорим позже). Когда вы видите требование, спросите себя: «Как я буду его тестировать? Какие тесты очевидно покажут, что это требование реализовано в ПС правильно?» Если с придумыванием таких тестов вы испытываете сложность – это тревожный звоночек: скорее всего, в требовании есть проблемы.

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

Тест план (Test Plan) - это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения

Тестовый план – документ проектной документации, который описывает:

— процесс тестирования конкретного продукта в конкретном проекте;

— что, когда, кем и как будет тестироваться;

— компоненты тестирования;

— команду тестировщиков;

— стратегию и методы тестирования;

— критерии качества и риски тестирования;

— график работ.

— Риск – сочетание вероятности наступления события и последствий, вызванных этим событием.

Секции тестового плана включают в себя:

— Перечень работ

— Критерии качества и оценка качества процесса

— Оценка рисков

— Документация и письма

— Тестовая стратегия Критерии приёмки билдов

— Методы тестирования

— Типы тестирования

— Уровни тестирования

— Отслеживание ошибок

— Использование метрик

— Ресурсы

— Метрики Метрика – это числовая характеристика, позволяющая оценить тот или иной аспект программного продукта или процесса в целом. Правило метрики:Билд считается неприемлимым, если в нем есть хотя бы один Critical или High баг, либо 5% функционала не простестировано или имеет Medium или Low баги

— Расписание

— Ключевые точки

— Тест план должен быть:

— Полным

— Корректным

— Недвусмысленным

Класс эквивалентности(equivalence class) – набор тестов, полное выполнение которого является избыточным и не приводит к обнаружению новых дефектов

Проверить вставку фацла

— «Корректный» файл

— Очень большой файл

— Несуществующий файл

— «Файл по сети» (Доступный. Недоступный будет эквивалентен несуществующему)

— Уже открытый файл (Нашим приложением и другим приложением)

— Файл неверного формата (По расширению и/или реальному содержимому)

— Пустой файл

— Повреждённый файл

Тест кейс («Набор тестовых входных данных, условий выполнения и ожидаемых результатов, разработанных с конкретной целью, такой как проверка некоторого пути выполнения программы или проверка соответствия некоторому требованию.»)

— Тест-кейсы могут быть:

— Специфичными или общими.

— Простыми или сложными.

— Независимыми или связанными друг с другом.

Позитивными или негативными

— Что содержит тест кейс Идентификатор теста (id)

— Связанное с тестом требование (related requirement)

— Краткое заглавие теста (title)

— Модуль и подмодуль приложения, к которым относится тест (module, submodule)

— Приоритет теста (priority: smoke, critical, extended; A, B, C, D)

— Исходные данные, необходимые для теста (initial data) (обычно включается в шаги выполнения)

— Шаги для выполнения теста (steps)

— Ожидаемые результаты (expected results)

— Поле для пометки, прошёл тест или нет (passed or failed)

— Последний полученный актуальный результат (actual result), связанный с тестом баг (если есть) (related bug)

Указать автора теста (author), время последнего выполнения теста (last time run) (часто эта информация указывается в заголовке файла

Критерии хорошего тест кейса

— Обладает высокой вероятностью обнаружения ошибки.

— Не выполняет ненужных действий.

— Не является избыточным по отношению к другим тестам.

— Исследует соответствующую («ту, которую надо») область приложения.

— Позволяет легко диагностировать ошибку.

— Делает обнаруженную ошибку очевидной.

— Независим (каждый тест-кейс – это индивидуальный сценарий с точкой входа и точкой выхода).

Тестовый сценарий– набор тестов (тест-кейсов), собранных в последовательность для достижения некоторой цели.

Баг - это отклонение фактического результата (actual result) от ожидаемого результата (expected result). Дефект – это несоответствие требованиям или функциональным спецификациям

Жизненный цикл дефекта

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

— Назначен (assigned). Далее ведущий разработчик рассматривает дефект и назначает его исправление кому-то из команды разработчиков.

— Исправлен (fixed). Разработчик, которому было назначено исправление дефекта, исправляет его и сообщает о том, что задание выполнено.

— Проверен (verified). Тестировщик, который обнаружил ошибку проверяет на новом билде (в котором исправление данной ошибки заявлено), исправлен ли дефект на самом деле. И только в том случае, если ошибка не проявится на новом билде, тестировщик меняет статус бага на Verified.

— Открыт заново (reopened). Если баг проявляется на новом билде, тестировщик снова открывает этот дефект. Баг приобретает статус Reopened.

— Отклонён (reject). Баг может быть отклонён. Во-первых, потому, что для заказчика какие-то ошибки перестают быть актуальными. Во-вторых, это может случится по вине тестировщика из-за плохого знания продукта, требований (дефекта на самом деле нет).

— Отложен (deferred). Если исправление конкретного бага сейчас не очень важно или заказчик пока думает, или мы ждём какую-то информацию, от которой зависит исправление бага, тогда баг приобретает статус Deferred.

— Дублирован (duplicate).Если уже существует открытый баг, который направлен на выявление той же самой ошибки.

— Баг/Дефект Репорт (Bug Report) - это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

Отчёт об ошибке («баг-репорт», «bug report») – один из основных результатов работы тестировщиков. И, к слову, именно этот результат работы видят коллеги (другие тестировщики и люди, не входящие в команду тестировщиков Это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

Основные атрибуты:

— Идентификатор (id)

— Краткое описание (summary) Что? Где? При каких условиях?

— Подробное описание (description)

— Шаги воспроизведения (steps to reproduce, STR)

— Важность (severity) Критическая (critical). Это самые страшные ошибки, выражающиеся в крахе приложения или операционной системы, серьёзных повреждениях базы данных, падению веб-сервера или сервера приложений.

Высокая (major). Серьёзные ошибки, такие как: потеря данных пользователя, падение значительной части функциональности приложения, падение браузера или иного клиента и т.п.

Средняя (medium). Ошибки, затрагивающие небольшой набор функций приложения. Как правило, такие ошибки можно «обойти», т.е. выполнить требуемое действие иным способом, не приводящим к возникновению ошибки.

Низкая (minor).Ошибки, не мешающие непосредственно работе с приложением. Как правило, сюда относятся всевозможные косметические дефекты, опечатки и т.п.

— Срочность (priority) Наивысшая (ASAP, as soon as possible). Присваивается ошибкам, наличие которых делает невозможным дальнейшую работу над проектом или передачу заказчику текущей версии проекта.
Высокая (high). Присваивается ошибкам, которые нужно исправить в самое ближайшее время.
Обычная (normal). Присваивается ошибкам, которые следует исправлять в порядке общей очереди.
Низкая (low). Присваивается ошибкам, которыми отделу разработки следует заниматься в последнюю очередь (когда и если на них останется время).

Дополнительные (необязательные) атрибуты:

— Возможность «обойти баг» (workaround)

— Дополнительная информация (additional information)

— Воспроизводимость (reproducible)

— Приложения (attachments)

Баг-трэкинговые системы

JIRA

Redmine

Bugzilla

QC

Отчёт о результатах тестирования (test result report, TRR) – часть тестовой документации, включающая в себя описание процесса тестирования, суммарную информацию о протестированных за подотчётный период билдах, информацию о деятельности тестировщиков, а также некоторые статистические данные.

Структура

1. Команда тестировщиков
2. Описание процесса тестирования (testing process description)
3. Краткое описание (summary)
4. Расписание (testing timetable)
5. Рекомендации (recomendations)
6. Статистика по ошибкам (bugs statistics)
7. Список новых ошибок (new bugs found)
8. Статистика по всем ошибкам (all bugs statistics)

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

Любое веб-приложение представляет собой набор статических и динамических веб-страниц.

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

В противоположность этому, сервер вносит изменения в динамическую веб-страницу перед отправкой ее браузеру. По причине того, что страница меняется, она называется динамической

Статический веб-сайт содержит набор соответствующих HTML-страниц и файлов, размещенных на компьютере, на котором установлен веб-сервер

Веб-сервер — это программное обеспечение, которое предоставляет веб-страницы в ответ на запросы веб-браузеров. Обычно запрос страницы создается при щелчке ссылки на веб-странице, выборе закладки в браузере либо вводе URL-адреса в адресной строке браузера

Когда веб-сервер получает запрос на выдачу статической веб-страницы, он отправляет страницу непосредственно браузеру. Однако, когда запрашивается динамическая страница, действия веб-сервера не столь однозначны. Сервер передает страницу специальной программе, которая и формирует окончательную страницу. Такая программа называется сервером приложений

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

Структура Запрос в большинстве случаев выглядит так:

<метод> <запрашиваемый_ресурс> HTTP/1.1<\n>

<заголовочное_поле>: <значение><\n>

<заголовочное_поле>: <значение><\n>

...

<заголовочное_поле>: <значение><\n>

<\n>

Метод - характеризует текущий запрос. Их несколько,

например head, post, put, delete, get

Ответ сервера выглядит следующим образом:

HTTP/1.1 <код ответа> <сообщение><\n>

<заголовочное_поле>: <значение><\n>

<заголовочное_поле>: <значение><\n>

...

<заголовочное_поле>: <значение><\n>

<\n>

<тело документа>

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

Коды ответов

— 200 ОК

— 201 Успешная команда post

— 202 Запрос принят

— 203 Запрос get либо head выполнен

— 204 Запрос выполнен, но нет содержимого

— 300 Ресурс обнаружен в нескольких местах

— 301 Ресурс удален навсегда

— 302 Ресурс временно удален

— 304 Ресурс изменен

— 400 Плохой запрос от клиента

— 401 Неавторизованный запрос

— 402 Необходима оплата за запрос ("зарезервированно для дальнейшего использования”, на данный момент не используется)

— 403 Доступ к ресурсу запрещен

— 404 Ресурс не найден

— 405 Метод неприменим для данного ресурса

— 406 Недопустимый тип ресурса

— 410 Ресурс недоступен

— 500 Внутренняя ошибка сервера

— 501 Метод не выполнен

— 502 Перегрузка сервера или неисправный шлюз

— 503 Сервер недоступен или таймаут шлюза

Get запрос. Основным недостатком является ограничение длины URL - 255 байтов/255 символов Отдельным недостатком можно выделить явную передачу данных через строку браузера из соображений безопасности (можно визуально запомнить передаваемый логин/пароль или другую важную информацию HTTP-запрос типа GET состоит только из HTTP-заголовков, тело у него отсутствует

Если необходимо передать на веб-сервер большой объем данных, например, текст сообщения или файл, используют POST-запрос. В этом типе запроса параметры помещаются в тело HTTP-запроса, а размер передаваемых данных в байтах указывается в заголовке Content-Length: Таким образом, в URL передаваемые параметры не видны. Простым способом сформировать POST-запрос не получится, они в основном генерируются с помощью HTML-форм

Программная инструкция, предназначенная для получения данных из базы данных, называется запросом к базе данных

Запрос состоит из критериев поиска, выраженных с помощью языка баз данных, называемого SQL (язык структурированных запросов).

Автоматизированное тестирование – это набор практик, подходов, методов и инструментальных средств, позволяющих исключить участие человека в реализации некоторых задач по тестированию ПО. Программы Selenium

— Appium

— Sikuli

— TestComplete

Smoke test для крупных систем, где приходится выполнять большое количество примитивных трудоёмких задач

ü Регрессионное тестирование. Прекрасный кандидат на автоматизацию в силу того, что его тесты (одни и те же тесты!) выполняются большое количество раз

ü Конфигурационное тестирование в контексте проверки работоспособности приложения при тех или иных настройках

ü Распределённое тестирование, при котором приходится эмулировать работу большого количества серверных и клиентских компонентов

ü Часто повторяющиеся тесты, простые для автоматизации

ü Длинные утомительные для человека тесты

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

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

— Существуют следующие способы проведения тестирования:

— наблюдение;

— карточная сортировка;

— проведение опросов и исследований;

— прототипирование;

— контекстуальные исследования;

— эвристическое исследование;

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

— работа с выделенными группами (фокусные группы).

Информация – сведения о лицах, предметах, фактах, событиях, явлениях и процессах независимо от формы их представления

Безопасность программного продукта — способность продукта достигать приемлемого