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

ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

1.	Роль и место тестирования в жизненном цикле разработки ПО.
2.	Тестирование методами «черного, белого, серого ящиков».
3.	Понятие «качество программного продукта». Экономические и психологические аспекты тестирования.
4.	Основные составляющие «быстрого тестирования».
5.	Каскадная, V-образная и спиралевидная модели разработки ПО.
6.	Процесс разработки требований. Свойства и категории требований.
7.	Хронологический порядок тестирования.
8.	Модульное тестирование и его методы.
9.	Структурное тестирование.
10.	Интеграционное тестирование.
11.	Особенности объектно-ориентированного тестирования.
12.	Тестирование классов.
13.	Автоматизация модульного тестирования.
14.	Тестовые случаи и их свойства. Процесс разработки тестовых случаев.
15.	Сходства и различия тестовых случаев для приемочного, критического и углубленного тестов.
16.	Эквивалентирование и анализ граничных значений.
17.	Тестовый план. Тестовая стратегия.
18.	Статическое тестирование, его виды.
19.	Процесс динамического тестирования.
20.	Ошибка. Свойства ошибки.
21.	Правила составления отчетов об ошибках.
22.	Жизненный цикл ошибки. Системы документирования ошибок.
23.	Специфика и ограничения тестирования Web-приложений.
24.	Приемочный тест. Критерии непрохождения приемочного теста.
25.	Критическое тестирование. Углубленное тестирование.
26.	Использование контрольных перечней в углубленном тестировании.
27.	Теория модели СММ.
28.	Автоматизированное тестирование, его этапы, преимущества и недостатки.
29.	Метод функциональной декомпозиции.
30.	Методы Data-driven, Keyword-driven.

Роль и место тестирования в жизненном цикле разработки ПО.

Тестирование – это процесс анализа и эксплуатации ПО с целью выявления дефекта (поиска ошибок). Слово «процесс» исп-ется для того чтобы подчеркнуть, что тестирование – это плановая и упорядоченная деятельность.

Ошибка – несоответствие ожидаемых результатов полученным.

Правила:

1) В прог-ме всегда есть ошибки

2) Нельзя найти все ошибки 3)Нельзя тестировать свои программы.

Хорошо продуманный систематический подход быстрее приводит к обнаружению ошибок, чем плохо спланированное тест-ние, проводимое в спешке.

Тестовая деят-ность, связанная с анализом ПП, наз. статическим тестированием (static testing). СТ предусматривает стратегию тест-ния, сквозную проверку прогр-ных кодов. Осуществляется без запуска проги. Тестовая деят-ность, предусматривающая эксплуатацию ПО, наз. динамическим тестированием (dynamic testing). Проводится посредством запуска проги. СТ и ДТ дополняют друг друга и реализуют свой собственный подход нахождения ошибок.

Тест-ние образовалось в 80-ых гг. Процесс тест-ния был разделен с процессом разработки и тестирование проводилось только на готовом продукте. В 90-ые гг началась кач-венная борьба за кач-во. Microsoft разработала методику zero-defect mindset, осн. идея к-рой заключается в том, что кач-во продукта проверяется в процессе разработки постоянно.

Выделяют следующие этапы:

Разработка требований

Проектирование

Кодирование

Тестирование

Сопровождение

Роль тестирования в ЖЦРПО

Команда	Проектирование	Проектирование	Кодирование	Тестирование	Сопровождение
Тестировщик	Анализ требований	Проектирование тестовой деятельности	Составление тестового сценария	Реализация теста	Тестирование документации

 

2. Тестирование методами “черного, белого и серого ящика”

 

При тестировании чёрного ящика (англ. black-box testing), тестировщик имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Например, тестирующий модуль может виртуально нажимать клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия процессов, с уверенностью в том, все ли идет правильно, что эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок мыши. Как правило, тестирование чёрного ящика ведётся с использованием спецификаций или иных документов, описывающих требования к системе. Как правило, в данном виде тестирования критерий покрытия складывается из покрытия структуры входных данных, покрытия требований и покрытия модели (в тестировании на основе моделей).

При тестировании белого ящика (англ. white-box testing, также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определенной степени. При тестировании белого ящика используются метрики покрытия кода.

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

Тестирование серого ящика – по этому принципу работают автоматизированные программы.

Психологические аспекты тестирования

 

 

Поощрение изменений

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

Упрощение интеграции

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

Документирование кода

Юнит-тесты можно рассматривать как «живой документ» для тестируемого класса. Клиенты, которые не знают, как использовать данный класс, могут использовать юнит-тест в качестве примера.

Структурное тестирование.

Изучение структуры программы. Как правило, тестирование структуры модуля происходит с помощью графического отображения модуля. Например, диаграммы Чейпина, диаграммы Насси-Шнайдермана, ориентированные графы Мак-Кейна.

В основу принято понятие, что узел – оператор, ребро – связь между узлами (операторами).

 

IF_THEN CASE

IF_THEN_ELSE DO_WHILE REPEAT_UNTIL

По построенным графам для отдельного модуля можно посчитать цикломатическое число, которое определяет сложность написанной программы.

Цикломатическое число графа (метрический показатель сложности программы): G=R(ребра) – V(вершины) + 2

Формула справедлива для замкнутого графа (существуют начальный и конечный узлы). Цикломатическое число отражает сложность графа. G>=15 недопустимо (необходимо дробить модуль).

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

Проход – путь по графу от первого до последнего узла.

Выбор проходов для тестирования (если общее количество проходов больше цикломатического числа) осуществляется по следующим стратегиям:

1) длительность исполнения прохода и число операторов в проходе

2) количество условных переходов (рассматриваются проходы, которые участвуют в формировании условий)

Характерна для логических программ.

 

Нисходящее тестирование.

Заключается в том, что тестирование начинается с головного модуля (A). Тогда возникает проблема передачи данных в головной модуль. Решение проблемы:

- написать несколько вариантов заглушек модуля B для различных тестов;

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

Можно использовать одну из следующих стратегий подключения:

1. Подключить наиболее важные модули сточки зрения тестирования;

2. Подключить модули, осуществляющие операцию вв/выв для того, чтобы обеспечить тестовыми данными внутренние модули.

Недостатки – написание заглушек.

Наприм.: модули I и J уже подключены и на следующем шаге тестирования заглушка модуля Н меняется на реальный модуль Н. Как тогда передать тестовые данные в модуль Н? Т.к. между модулями J и имеются промежуточные модули и может оказаться невозможным передать тестовые данные, соответствующие разработанным тестам. К тому же достаточно сложно интерпретировать результаты тестирования модуля Н, т.к. между Н и I также существуют промежуточные модули.

 

Восходящее тестирование.

Восходящее тестирование начинается с не вызывающих другие модули (терминальных) модулей.

Стратегия подключения новых модулей также должна основываться на степени критичности данного модуля в программе.

Недостаток заключается в том, что рабочая программа не существует до тех пор, пока не будет подключен последний главный модуль (А).

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

 

Тестирование классов направлено на проверку соответствия реализации данного класса его спецификации.

Прежде, чем тестировать класс, необходимо определить: тестировать его в автономном окружении или как компонент некой системы. Для этого необходимо выяснить:

4) Роль класса в системе, в частности, степень связанного с ним риска

5) Сложность класса, которая измеряется количеством состояний, операций и связей с другими классами

6) Объем трудозатрат на разработку тестового драйвера для тестирования этого класса

Важно!

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

 

Смотри 14.

Как правило, весь функционал не тестируется сразу, а разбивается на этапы:

1) приемочный тест (smoke test) – проверка основного функционала программного продукта. Цель – определить пригодна ли данная версия для дальнейшего тестирования.

2) Критический тест (critical passtest) – проверка всей функциональности программы при стандартных (правильных) вариантах работы

3) Углубленный тест – это проверка работы программы при нестандартных вариантах работы.

 

Критическое тестирование - основной вид тестирования, при котором проверяется типичная работа программы (при правильной последовательности действий и т.д.). Этот вид проводится всегда над каждой версией пп по заранее подготовленным тестовым сценариям.

Каждый отработанный случай помечается, как пройден/не пройден. Если «не пройден», то тестер оформляет отчет на найденную ошибку.

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

 

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

Углубленное тестирование проводиться на основе заранее разработанных тестовых сценариев, а также с использованием контрольных перечней – check list’ов. Как правило, контрольные перечни создаются для стандартных компонентов (поле даты, текстовые поля и тд).

В некоторой степени контроль переменных является упрощенным тестовым сценарием.

Тестовая стратегия.

Указ. какие конфиг. тестов будут тест-ся в 1-ю очередь, объемы тест-х работ, типы методик тестир-я, критерии входа и выхода испытаний.

Для успешного тестирования необходимо определить:

1. Определение объема тестовых работ заключается в определении той части проги, к-рая будет тест-ваться. Надо установить баланс м/у избыточным и недостаточным тест-нием.

2. Подход к тестированию, т. е. для каждого этапа определить необходимые шаги и документы.

3. Определить критерии входа и выхода. критерии входа – описать, что надо делать перед началом тест-я и какими располагать док-ми; критерии выхода – необходимые для завершения испытаний.

Ошибка. Свойства ошибки.

Ошибка (дефект, Bug) – расхождение м-ду прогой и ее спецификацией.

или если прога не делает того, что пользователь от нее вполне обоснованно ожидает.

Если прога не делает того, что польз-ль от нее ожидает – программная ошибка.

Свойства ошибок:

1. Важность:

1) критическая ошибка – происходит крах прилож-я, крах сервера, ОС, невозможность продолж-я раб. с прил-ем без его перезапуска.

2) серьезная – не работ-ая или неправильно раб-щая осн. функциональность прилож-я: невозм-ть сохр. данные, выбора опер-й продукта, потеря информ.

3) средняя – не раб. или неправильно раб. неосн. функц-ть, но есть др. сп-б для ее реализ-ии: не раб Save As(раб. Save).

4) Низкая – все дефекты, не влияющие на функциональность (грам. ошибки, некорректная табуляция и т.д.)

2. Воспроизводимость – как часто проявляется ошибка:

- всегда

- иногда при каком-то условии

3. Симптом – категория ошибки:

- Неверное действие;

- Отказ системы;

- Потеря данных;

- Искажение данных;

- Косметическая ошибка;

- Ошибка документации;

- Различие со спецификацией.

4. Приоритет ошибки по отношения с другими ошибками:

- Очень высокий; - Высокий; - Средний; - Низкий.

Теория модели CMM

 

Методологии разработки ПО используются заказчиком для определения уровня исполнителя. Наиболее популярная методика-это CMM, т.е. методика зрелости процессов. Разработана в США. Основные понятия этой методики:

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

- продуктивность – описывает совокупность ожидаемых результатов, которые могут быть достигнуты при следовании производственному процессу. Продуктивность позволяет прогнозировать вероятные результаты будущего процесса.

- производительность – реальные результаты.

- уровень зрелости – степень, до которой тот или иной процесс определен, управляем, измеряем, контролируем и эффективен. Модель CMM подразумевает 5 уровней зрелости: 1) начальный – производственный процесс характеризуется как создаваемый каждый раз для каждого нового проекта. Определены лишь некоторые процессы;

2) повторяемый – установлены основные процессы управления проектом: отслеживание затрат, график работ, функциональность разрабатываемых проектов.

3) определенный – производственный процесс документирован и стандартизирован;

4) управляемый – собираются подробные количественные показатели производственного процесса и качества создаваемого продукта. Как ПП, так и продукты оцениваются и контролируются с количественной точки зрения.

5) оптимизирующий – постоянное совершенствование. Определяются причины возникновения дефектов. Продуктивность характеризуется как постоянно улучшающаяся, производительность постоянно повышается.

 

 

Пример

Проверка функциональности Login в некотором приложении. Для реализации этой проверки можно написать одну функцию Login с 3 параметрами: имя пользователя, пароль, признак ожидаемого результата.

Однако, с точки зрения повышения модульности, а также для сведения к минимуму усилий для поддержки изменения автоматизированных тестов сделаем функцию VerifyLogin, из которой в свою очередь будет вызываться функция Login. Она в свою очередь не производит проверок, а лишь вызывает функции SetUserName, SetPassword, ClickButton. При этом функции SetUserName и SetPassword будут вызывать функцию SetTextBox, которая уже утилита.

 

Data-driven

Этот метод является продолжением предыдущего (декомпозиции). И в нем параметры функций (данные для тестов) выносятся за пределы кода скрипта. Для примера (в декомпозиции) эти данные могли бы храниться в базе данных (например Excel).

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

 

Keyword-driven

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

Ключевое слово	Действие	Ожидаемый результат	Полученный результат

 

 

ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ