Запросы как приложения информационной системы тест
Рассмотрим на конкретном примере методику проектирования много табличной базы данных.
| ФАКУЛЬТЕТЫ |
| Название факультета |
| Экзамен 1 |
| Экзамен 2 |
| Экзамен 3 |
| СПЕЦИАЛЬНОСТИ |
| Название специальности |
| Название факультета |
| План приема |
Имеем модель данных, состоящую из трех взаимосвязанных таблиц:
| АБИТУРИЕНТЫ |
| Регистрационный номер |
| Фамилия |
| Имя |
| Отчество |
| Дата рождения |
| Город |
| Законченное учебное заведение |
| Название специальности |
| Производственный стаж |
| Медаль |
| Оценка за экзамен 1 |
| Оценка за экзамен 2 |
| Оценка за экзамен 3 |
| Зачисление |
Эти таблицы можно рассматривать как модель данных в реляционной СУБД. Но работать с БД в таком виде неудобно, т.к. к реляционной БД предъявляется требование: минимизация избыточности данных.
Недостаток этих таблиц - многократное повторение длинных значений полей в разных записях.
Внесем изменения в таблицы:
| ФАКУЛЬТЕТЫ |
| Код факультета |
| Название факультета |
| Экзамен 1 |
| Экзамен 2 |
| Экзамен 3 |
| ФАКУЛЬТЕТЫ |
| Название факультета |
| Экзамен 1 |
| Экзамен 2 |
| Экзамен 3 |
| СПЕЦИАЛЬНОСТИ |
| Название специальности |
| Название факультета |
| План приема |
| СПЕЦИАЛЬНОСТИ |
| Название специальности |
| Название факультета |
| План приема |
Т аблицу АБИТУРИЕНТЫ разделим на четыре таблицы:
| АНКЕТЫ |
| Регистрационный номер |
| Фамилия |
| Имя |
| Отчество |
| Дата рождения |
| Город |
| Учебное заведение |
| АБИТУРИЕНТЫ |
| Регистрационный номер |
| Код специальности |
| Медаль |
| Производственный стаж |
| ОЦЕНКИ |
| Регистрационный номер |
| Оценка за экзамен 1 |
| Оценка за экзамен 2 |
| Оценка за экзамен 3 |
| ИТОГИ |
| Регистрационный номер |
| Зачисление |
Для указания связей между таблицами построим схему базы данных .
В схеме указывается наличие связей между таблицами и типы связей.
Здесь использованы два типа связей:
При связи «один-к-одному» с одной записью в таблице связана одна запись в другой таблице. При наличии связи «один-ко-многим» одна запись в некоторой таблице связана с множеством записей в другой таблице.
Тема: Запросы как приложения информационной системы. Понятие запроса. Создание запросов на выборку данных.
Действия, выполняемые над информацией, хранящейся в базе данных, называются манипулированием данными. К ним относятся выборка данных по некоторым условиям, сортировка данных, обновление, удаление устаревших и добавление новых данных. Выполнение этих действий производится с помощью запросов.
Запрос — это команда к СУБД на выполнение определенного вида манипулирования данными.
Существует универсальный язык, на котором формулируются запросы во многих СУБД. Он называется SQL (Structured Query Language) — структурированный язык запросов. Здесь мы оказываемся перед выбором, с которым часто приходится сталкиваться в информатике: обучаться составлению запросов на языке SQL или воспользоваться каким-то более высокоуровневым вспомогательным средством. В большинстве современных СУБД такие средства имеются. Например, в Microsoft Access это конструктор запросов.
В учебных целях мы будем использовать строчное описание команд запросов на придуманном (гипотетическом) языке. Он близок к SQL, однако имеет не такой строгий синтаксис и, кроме того, использует русские служебные слова.
Команда запроса на выборку данных из БД на гипотетическом языке запросов имеет следующий формат:
Не все составляющие этой команды являются обязательными. Могут отсутствовать условие выбора и порядок сортировки. Кроме того, ключей сортировки может быть несколько. Тогда они записываются в порядке приоритетов: первый, второй и т. д.
Опишем серию запросов на гипотетическом языке, которую позже в практикуме реализуем средствами СУБД. В курсе информатики основной школы вы учились составлять запросы к однотабличной БД. Теперь рассмотрим примеры запросов, для выполнения которых потребуется извлекать данные из нескольких таблиц.
Запрос 1. Требуется получить список всех специальностей университета с указанием факультета и плана приема на специальность. Список отсортировать в алфавитном порядке по двум ключам: названию факультета (первый ключ) и названию специальности (второй ключ).
В этом запросе не будет использовано условие выбора, поскольку в итоговый список войдет информация из всех записей таблиц ФАКУЛЬТЕТЫ и СПЕЦИАЛЬНОСТИ. В разделе сортировки должно быть указано два ключа по порядку. Напомним, что в таком случае сортировка сначала происходит по первому ключу, и в случае совпадения у нескольких записей его значения они упорядочиваются по второму ключу.
Если в запросе используются поля из разных таблиц, то для их обозначения применяются составные имена, включающие разделенные точкой имя таблицы и имя поля в этой таблице.
Команда для данного запроса будет следующей:
Результат выполнения запроса — таблица 1.15.
Таблица 1.15
План приема: запрос на выборку
Запрос 2. Получить список всех абитуриентов, поступающих на юридический факультет, имеющих производственный стаж. Указать фамилию, город, специальность и стаж. Упорядочить по фамилиям.
В этом запросе должны использоваться четыре таблицы одновременно: АНКЕТЫ, СПЕЦИАЛЬНОСТИ, АБИТУРИЕНТЫ, ФАКУЛЬТЕТЫ. Условие выбора в этом запросе будет представлять собой логическое выражение, содержащее операцию логического умножения «И» — конъюнкцию. Подробнее способы записи логических выражений мы обсудим в следующем параграфе.
На гипотетическом языке запросов команда будет выглядеть так:
В результате будет получена таблица 1.16.
Запросы как приложения информационной системы. Понятие запроса. Создание запросов на выборку данных.
Практическая работа 2 «Реализация простых запросов с помощью конструктора»
Практическая работа 3 «Работа с формой»
Образовательные:
• конкретизировать понятие объектов БД, используя личный опыт учащихся;
• сформировать представление о разнообразии объектов БД;
• сформировать умение работать с формами и запросами на практике;
• сформировать представление о связи объектов БД;
• сформировать умение самостоятельно работать с алгоритмическими предписаниями компьютерного практикума.
Воспитательные:
воспитывать стремление к получению знаний, интерес к предмету, способность осуществлять выбор и нести за него ответственность, стремление к созидательной деятельности и продолжению образования;
Развивающие:
развивать учебно-познавательную деятельность обучающихся, логическое мышление, навыки работы на компьютере.
Задачи урока через планируемые результаты:
формировать систему знаний о БД как универсальном хранилище информации и мощной системе обработки информации, навыки и умения безопасного и целесообразного поведения при работе с компьютерными программами, умения соблюдать нормы информационной этики и права; отработать умения и навыки при создании запросов в режиме конструктора и формы в режиме мастера.
Метапредметные:
владеть достоверной информацией исторических событий, происходивших на территории Донбасса во время ВОВ, устанавливать причинно-следственные связи, делать логические рассуждения, выводы;
развивать чувства личной ответственности за качество и достоверность отображаемой информации, способность связывать данные с собственным жизненным опытом.
Формирование УУД:
Регулятивные:
целеполагание – формулировать и удерживать учебную задачу; планирование – выбирать действия в соответствии с поставленной задачей и условиями ее реализации.
Познавательные:
общеучебные – использовать общие приемы решения поставленных задач;
Коммуникативные:
инициативное сотрудничество – постановка вопросов, обращаться за помощью
Оборудование:
Карточка «критерии оценивания», карточки объектов, карточки с алгоритмом действий, собранный материал для реализации проекта, тест, учебник.
Методы обучения:
Наглядный, словесный, практический, индивидуальное консультирование, мозговой штурм, самоконтроль.
Технология проведения
Деятельность
Деятельность
обучающихся
Планируемые результаты
Метапредметные
1.Оргнизационный
Цель: подготовка класса к работе
Проверка присутствия обучающихся
Подготовка к уроку
Интерес к предмету, теме
Регулятивные УУД:
умение планировать свою деятельность
2.Актуализация знаний
Цель: создание ситуации успеха на уроке для каждого обучающегося через повторение ранее изученного материала
На прошлых уроке мы с вами начали изучать и сегодня продолжаем изучение темы «База данных как модель предметной области», а также освоили приемы создания реляционной БД с помощью конструктора. Прежде чем приступить к продолжению изучения возможностей БД , давайте с вами закрепим наши знания.
1. Что такое база данных?
2. Какие типы БД существуют?
3. Что вы знаете о реляционной БД?
У вас на партах лежат тесты, предлагаю пройти их и проверить уровень своих знаний самостоятельно, сверив ответы с доской.
Работа с тестом (самопроверка)
Заполняют оценочный лист
Закрепление основных понятий , изученных ранее.
Познавательные УУД:
анализировать и обобщать;
сравнивать;устанавливать аналогии работы в разных приложнениях
Регулятивные УУД:
умение планировать свою деятельность, оценивать степень успешности достижения цели
Коммуникативные УУД:
излагать своё мнение;
участвовать в диалоге
3 .Мотивация
На прошлом уроке мы разделились на группы и определились с темой ваших БД. В рамках года 75-летия Великой Победы вы выбрали для своих проектов поисковую деятельность на тему Герои Донбасса. В ваших папках с практическими работами у вас создана заготовка БД, которую вы будете продолжать, и на основании которых вы будете работать. Ответьте на вопрос: что мы можем с ней сделать? (Выбирать и систематизировать информацию по полям).
Показывают папки с информацией собранной для БД
Заполняют оценочный лист
Поисковая работа с информацией. Отработка информационных процессов
Познавательные УУД:
анализировать и обобщать;
умение работать с информацией
4. Постановка цели урока
Приступим к продолжению изучения возможностей БД.
Тему урока запишите в тетрадь.
Сегодня на уроке мы с вами рассмотрим основные способы работы с объектами БД и способы их создания, выполним две практические работы по заданному алгоритму.
Записывают в тетрадь тему урока и определения основных понятий данной темы, выполнение лабораторно-практической работы
Изучение новых возможностей при формировании баз данных
Регулятивные УУД:
умение планировать свою деятельность, оценивать степень успешности достижения цели
5. Изучение нового материала
Цель: знакомство с новыми понятиями объектов БД запросами и формами и с новыми возможностями приложения Microsoft Access 2007 .
Система управления базами данных (СУБД) — это программное обеспечение компьютера для работы с базами данных.
Запросы упрощают просмотр, добавление, удаление или изменение данных в базе данных Access. Среди других целей использования запросов можно отметить:
· быстрый поиск определенных данных путем фильтрации с применением определенных критериев (условий);
· вычисление или сведение данных;
· автоматизированное управление данными, например регулярный просмотр актуальных данных.
Форма отображает одну запись в удобном для пользователя виде. В процессе создания формы можно указать какие поля БД включить в форму, как расположить поля в окне формы, а также как можно сделать форму визуально привлекательной.
Для создания запроса ознакомимся с алгоритмом создания запросов и форм, он лежит у вас на рабочем столе.
Основные способы создания этих объектов : режим конструктора и режим мастера
-Слушают объяснения и записывают новые понятия в тетрадь.
-Для закрепления полученных знаний выполняют лабораторно-практическую работу.
-Выявляют непонятные вопросы при выполнении работы.
-Ознакамливаются с алгоритмом создания запросов и форм для реализации его на практике
Знакомятся с новыми понятиями при формировании базы данных и с новыми возможностями приложения через теоретический материал и лабораторно-практический.
Познавательные УУД:
устанавливать аналогии по созданию таблиц баз данных в других приложениях, поиск наиболее эффективного способа решения задачи;
Регулятивные УУД:
работать по плану урока
Коммуникативные УУД:
умение полно и точно выражать свои мысли в соответствие с задачами и условиями коммуникации, владение монологической и диалогической формами речи при формировании вопросов по выполнению работы
6 Практическая работа за ПК
Цель: научится создавать запросы в режиме конструктора и формы в режиме мастера
Перед практическими работами повторим правила безопасной жизнедеятельности в компьютерном классе.
Занимайте свои рабочие места за компьютерами.
При создании запроса и формы по выбранным вами полям используйте алгоритм. Который лежит на рабочем месте.
ФИЗМИНУТКА
Повторяют правила БЖ.
Выполняют практическую работу.
Знакомятся с новыми понятиями при создании запросов и форм
В практической деятельности, отрабатывают практические навыки посредством выполнения практической работы.
Познавательные УУД:
устанавливать аналогии по созданию таблиц баз данных в других приложениях, поиск наиболее эффективного способа решения задачи;
Регулятивные УУД:
работать по плану урока
Коммуникативные УУД:
умение полно и точно выражать свои мысли в соответствие с задачами и условиями коммуникации, владение монологической и диалогической формами речи при формировании вопросов по выполнению работы
7.Подведение итогов урока
Цель: определение предварительного уровня достижения цели урока
1.С какими возможностями баз данных мы познакомились на уроке?
Был ли полезным новый материал урока?
2.Достигли ли цели урока?
3. Оценивание
Отвечают на вопросы на основе записей в тетради и выполнения лабораторно-практической работы.
Заполняют оценочный лист.
Лабораторно-практическая работа выполнена .Запросы и формы созданы.
Коммуникативные УУД:
излагать своё мнение
Регулятивные УУД:
определять цель, обнаруживать и формулировать проблему урока, оценивать степень успешности достижения цели
Цель: закрепление знаний по теме, возможность выбора заданий для обучающихся с разным уровнем мотивации
Домашнее задание : продолжение сбора информации для проекта
Найти ответы на поставленные вопросы в тексте учебника, использовать приложение Microsoft Access 2007 .
Закрепление знаний, умений и навыков, полученных на уроке
Познавательные УУД:
находить информацию в тексте, обобщать;
представлять информацию в развёрнутом виде
Если Вы считаете, что материал нарушает авторские права либо по каким-то другим причинам должен быть удален с сайта, Вы можете оставить жалобу на материал.
Цель занятий: сформировать представление о запросе БД, формировать умение создавать запросы разных типов в среде БД.
- образовательная: знакомство с правилами формирования команд запросов, с синтаксисом команд на языке гипотетической СУБД, освоение приемов создания и реализации запросов
- развивающая: формирование приемов логического мышления
- воспитательная: воспитание аккуратности, точности
| № п/п | Тема | Слайд | Работа | Домашнее задание |
| Запросы как приложения информационной системы | 1-6 | 3.11 | Придумать запросы "на выбору" к индивидуальной базе данных. Представить эти запросы на гипотетическом языке. Ответить на вопрос: в чем состоит разница между инструментами "расширенный фильтр" и "запрос". | |
| Перекрестный запрос. Логические условия выбора данных | 7-8 | 3.13 | Придумать "перекрестные" запросы к индивидуальной базе данных. Представить эти запросы на гипотетическом языке. | |
| Запрос на действие. Параметрический запрос | 9-10 | 3.14 | Придумать запросы "на действие" и "параметрические" запросы к индивидуальной базе данных. Представить эти запросы на гипотетическом языке. |
Основная задача любой информационной системы - поиск информации в БД. Поиск происходит по запросу пользователя. С помощью запросов данные упорядочивают, фильтруют, отбирают, изменяют, объединяют, то есть обрабатывают. На одном из занятий мы с вами знакомились с инструментами сортировка и фильтр. Давайте вспомним алгоритм сортировки.
- Выбрать поле, которое требуется использовать для сортировки записей.
- Нажать кнопку Сортировка по возрастанию или Сортировка по убыванию
Какие существуют способы отбора записей в таблице с помощью фильтров?
Ответ: фильтр по выделенному, обычный фильтр, поле "Фильтр дня" и расширенный фильтр.
Вспомним алгоритм применения расширенного фильтра
- Открыть таблицу в режиме таблицы
- Выбрать команду Фильтр в меню Записи, а затем команду Расширенный фильтр.
- Добавить в бланк поля, для которых будут заданы искомые значения или другие условия, используемые в фильтре для отбора записей.
- Чтобы указать порядок сортировки, выбрать ячейку Сортировка нужного поля, щелкните стрелку и выберите порядок сортировки.
- В ячейке Условие отбора полей, включенных в бланк, указать искомое значение или ввести выражение.
- Чтобы применить фильтр, нажать кнопку Применить фильтр на панели инструментов.
Запросы очень похожи на фильтры и предназначены для поиска в базе данных информации, отвечающей определенным критериям. Найденные записи, называемые результатами запроса, можно просматривать, редактировать и анализировать различными способами. Кроме того, результаты запроса могут использоваться в качестве основы для создания других объектов MS Access.
- Запрос на выборку: извлекает данные из одной или нескольких таблиц и представляет их в табличном виде
- Запрос на действие: вносит множественные изменения за одну операцию.
- Параметрический запрос: запрашивает ввод параметров (например, начальную и конечную дату)
- Перекрестный запрос: выполняет расчеты и группирует данные для анализа информации
Существует универсальный язык, на котором формулируются запросы во многих СУБД - SQL (Structured Query Language - структурированный язык запросов). В учебных целях мы будем использовать строчное описание команд запросов на придуманном (гипотетическом) языке. Он близок к SQL, однако имеет не такой строгий синтаксис.
Далее каждый тип запроса рассматривается отдельно и более подробно (Приложение 1).
Запросы рассматриваются на основе примеров. Сначала показываем условие запроса далее запись на гипотетическом языке. Разбираем пример более подробно. Далее показываем создание запроса на примере базы данных "Приемная комиссия" (Приложение 2) перейдя по ссылке в презентации (Приложение 1). После просмотра примера учащиеся самостоятельно записывают алгоритм создания запроса в тетрадях. В следующем шаге учитель показывает условие запроса, и учащиеся самостоятельно записывают запрос на гипотетическом языке. На выполнение задания дается 3 мин. После выполнения учащиеся проверяют правильность запроса. Один из учеников выполняет запрос в СУБД "MS Access" (можно использовать интерактивную доску).
Для закрепления знаний учащиеся выполняют работу № 3.11. "Реализация простых запросов с помощью конструктора", работу № 3.13 "Реализация сложных запросов к базе данных "Приемная комиссия"", работу № 3.14 "Реализация запросов на удаление. Использование вычисляемых полей" из учебника [2].
Привет, Хабр! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов (как вариант, эта информация может быть для общего понимания полезна ИТ-рекрутерам, которые проводят первичное собеседование и попутно задают некоторые около-технические вопросы).
ОСНОВНЫЕ ТЕРМИНЫ
Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:
планированием работ (Test Management)
проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.
анализом результатов (Test Analysis)
Основные цели тестирования
техническая: предоставление актуальной информации о состоянии продукта на данный момент.
коммерческая: повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей.
Верификация (verification)
Валидация (validation)
Соответствие продукта требованиям (спецификации)
Соответствие продукта потребностям пользователей
Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.
Следует уметь различать, что:
Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).
Жизненный цикл бага
Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.
Blocker - ошибка, приводящая приложение в нерабочее состояние, из-за которой дальнейшая работа с системой или ее ключевыми функциями становится невозможна, т.е. тестирование значительной части функциональности становится недоступно
Крит (Critical) - неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие непрямые пути (workaround).
Значительный (Major) - часть основной бизнес логики работает некорректно, есть возможность для работы с тестируемой функцией, используя обходные пути (workaround); либо дефект с высоким visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
Тривиальная (Trivial) - ошибка, не касающаяся бизнес-логики приложения, не оказывающая никакого влияния на общее качество продукта, например, опечатки в тексте, несоответствие шрифта и оттенка и т.д.
Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.
НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА
Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. ПРИМЕР: есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.
Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.
Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).
Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).
Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.
Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить общее количество тест-кейсов. Используется для тестирования, например, фильтров, сортировок. Этот интересный метод заслуживает отдельного внимания и более подробно рассматривается в статье по ссылке (в конце которой упоминаются инструменты для автоматизации применения PT ).
Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
Таблица принятия решений (decision table) — инструмент для упорядочения бизнес-требований, которые должны быть реализованы в продукте. Применяется для систем со сложной логикой. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.
ВИДЫ ТЕСТИРОВАНИЯ
Классификация по целям
Функциональное тестирование (functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.
Тестирование пользовательского интерфейса (GUI Testing) — проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).
Тестирование удобства использования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Состоит из: UX — что испытывает пользователь во время использования цифрового продукта, и UI — инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».
Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Инсталляционное тестирование (installation testing) направленно на проверку успешной установки и настройки, а также обновления или удаления приложения.
Конфигурационное тестирование (Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)
Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться, т.е. обеспечивать сохранность и целостность данных, после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).
Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Тестирование стабильности или надежности (Stability / Reliability Testing) — это проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.
Стрессовое тестирование (Stress Testing) позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса (например, повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера) и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса.
Объемное тестирование (Volume Testing) — тестирование, которое проводится для получения оценки производительности при увеличении объемов данных в базе данных приложения.
Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
Классификация по позитивности сценария
Позитивное — тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.
Классификация по знанию системы
Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.
Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
Тестирование чёрного ящика (Black Box) — метод тестирования ПО, также известный как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, которая не предполагает доступа (полного или частичного) к системе, т.е. основывается на работе исключительно с внешним интерфейсом тестируемой системы.
Классификация по исполнителям тестирования
Альфа-тестирование — является ранней версией программного продукта, тестирование которой проводится внутри организации-разработчика; может быть вероятно частичное привлечение конечных пользователей.
Бета-тестирование — практически готовое ПО, выпускаемое для ограниченного количества пользователей, разрабатывается в первую очередь для тестирования конечными пользователями и получения отзывов клиентов о продукте для внесения соответствующих изменений.
Классификация по уровню тестирования
Модульное (компонентное) тестирование (Unit Testing) проводится самими разработчиками, т.к. предполагает полный доступ к коду, для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде, проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).
Интеграционное тестирование (Integration Testing) направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.
Сверху вниз (Top Down Integration) Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами.
Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.
Системное тестирование (System Testing) — это проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д., и оцениваются характеристики качества системы — ее устойчивость, надежность, безопасность и производительность.
Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.
Классификация по исполнению кода
Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки. Например, путем анализа кода (code review). Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к этому виду относится тестирование требований, спецификаций и прочей документации.
Динамическое тестирование проводится на работающей системе, т.е. с осуществлением запуска программного кода приложения.
Классификация по хронологии выполнения
Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.
Регрессионное тестирование (regression testing) — это тестирование после внесения изменений в код приложения (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям, т.е. проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвали новых багов.
Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
ДОКУМЕНТАЦИЯ
Требования — это спецификация (описание) того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Основные атрибуты требований:
Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
Недвусмысленность — требование должно содержать однозначные формулировки.
Проверяемость (тестопригодность) — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования).
Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:
Что нужно тестировать?
Как будет проводиться тестирование?
Когда будет проводиться тестирование?
Критерии начала тестирования.
Критерии окончания тестирования.
Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.
Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.
Читайте также: