программ является метод черного ящика. При этом реализация системы недоступна тестировщикам, и тестируется только ее интерфейс посредством пользовательского воздействия. Противоположностью данному методу является тестирование методом белого ящика, когда исходный код доступен тестировщикам и используется в качестве источника информации о тестируемой системе. В этом случае на основе требований к системе помимо ее реализации создается (программируется) ее тестовая модель.
По способу реализации тесты могут быть ручными и автоматическими. Ручной тест – это последовательность действий тестировщика (или
разработчика), которую он может воспроизвести и при этом ошибка произойдет. Как правило, в средствах контроля ошибок такие последовательности действий содержатся в некоторой форме описания ошибки.
Автоматический тест – это некоторая программа, которая воздействует на систему и проверяет то или иное ее свойство (функциональное требование).
7.2. Критерии тестирования В любом случае качество тестирования может оказаться
неудовлетворительным – ошибки находятся редко или вообще не находятся ввиду того, что количество возможных состояний программы очень велико, и тестирование не в состоянии покрыть их все.
На практике в реальных проектах, определяют критерии тестирования, которые определяют тот уровень качества, который необходимо обеспечить в данном проекте. Хорошее качество стоит дорого и очевидно, что разное ПО имеет разное качество, например, система управления химическим реактором и текстовый редактор. В силу ограниченности ресурсов на тестирование также целесообразно определить те аспекты ПО, которые наиболее важны как для общей работоспособности системы, так и для удовлетворения заказчика.
При тестировании на некоторых (но не на всех возможных) входных данных применяют принцип факторизации – множество всех возможных входных значений разбивается на значимые с точки зрения тестирования классы и "прогоняются" тесты не на всех возможных входных значениях, но берут по одному набору значений из каждого класса. Например, тестируют некоторую функцию системы на ее граничные значения – очень большие значения параметров, очень маленькие и т.п. Часто факторизацию удобно делать, исходя из требований к данной функции. Также бывает полезно посмотреть на ее реализацию и протестировать ее по разным логическим веткам (порождаемым, например, условными операторами).
7.3. Виды тестирования.
Модульное тестирование – тестируется отдельный модуль, в отрыве от остальной системы. Самый распространенный случай применения –
76
тестирования модуля самим разработчиком, проверка того, что отдельные модули, классы, методы выполняют действительно то, что от них ожидается. Различные среды разработки широко поддерживают средства модульного тестирования. Созданные разработчиком модульные тесты часто включаются в пакет регрессионных тестов и таким образом, могут запускаться многократно.
Интеграционное тестирование – два и более компонентов тестируются на совместимость. Это очень важный вид тестирования, поскольку разные компоненты могут создаваться разными людьми, в разное время, на разных технологиях. Этот вид тестирования должен применяться самими программистами, чтобы, по крайней мере, удостовериться, что все компоненты программы совместимы в первом приближении. Далее тонкости интеграции могут исследовать тестировщики.
Необходимо отметить, что такого рода "ошибки на стыках" непросто обнаруживать и устранять. Во время разработки все компоненты все вместе не готовы, интеграция откладывается, а в конце обнаруживаются трудные ошибки (в том смысле, что их устранение требует существенной работы: реструктуризации, рефакторинга). Здесь выходом является ранняя интеграция системы и в дальнейшем использование практики постоянной интеграции.
Системное тестирование – это тестирование всей системы в целом, как правило, через ее пользовательский интерфейс. При этом могут использовться как ручные, так и автоматические тесты с акцентом на том, как ПО выглядит и работает в целом, удобно ли оно, удовлетворяет ли она ожиданиям заказчика. При этом могут открываться различные дефекты, такие как неудобство в использовании тех или иных функций, забытые или "скудно" понятые требования.
Регрессионное тестирование – тестирование системы в процессе ее разработки и сопровождение на не регресс. То есть проверяется, что изменения системы не ухудшили уже существующей функциональности. Для этого создаются пакеты регрессионных тестов, которые запускаются с определенной периодичностью – например, в пакетном режиме, связанные с процедурой постоянной интеграции.
Нагрузочное тестирование – тестирование системы на корректную работу с большими объемами данных. Например, проверка баз данных на корректную обработку большого (предельного) объема записей, исследование поведение серверного ПО при большом количестве клиентских соединений, эксперименты с предельным трафиком для сетевых и телекоммуникационных систем, одновременное открытие большого числа файлов, проектов и т.д.
Стрессовое тестирование – тестирование системы на устойчивость к непредвиденным ситуациям. Этот вид тестирования нужен далеко не для каждой системы, так как подразумевает высокую планку качества.
Приемочное тестирование – тестирование, выполняемое при приемке системы заказчиком. Более того, различные стандарты часто включают в себя наборы приемочных тестов.
77
Требования к содержанию отчета.
В подразделе 1 приводятся результаты ручного тестирования посредством проверки работоспособности программы по всем возможным ее ветвям. Для этого требуется инициировать срабатывание всех пунктов меню в таком порядке (номера пунктов меню приводятся со ссылкой на пример пользовательского меню из приложения В):
1, 3, 3.1 и/или 3.2 (в зависимости от типа списка; выполнить несколько раз), 3.3, 3.4, 3.5 и/или 3.6 (в зависимости от типа списка), 3.7, 6, 7.
2, 3, 3.1 и/или 3.2 (в зависимости от типа списка), 3.7, 4, 4.1, 4.2, 4.3, 5, 6, 7.
Представить обнаруженные логические ошибки (при наличии таковых). Для каждой логической ошибки:
описать ее суть;
представить тестовую последовательность манипуляций для ее обнаружения (как правило, это подмножество пунктов полной тестовой последовательности);
представить форму ее проявления в результате применения теста;
определить форму ее выражения в коде;
описать способ ее устранения.
Вподразделе 2 представить технические характеристики машин (не менее трех), которые использованы для анализа производительности программы. Привести определенную последовательность действий пользователя (наподобие последовательности проверочных действий в подразделе 1). Привести временные оценки проверок для каждой конфигурации
икратко их прокомментировать.
Вподразделе 3 представить системные сведения о созданных файлах исходных данных, распечатки файлов (шрифт Courier New, 8 пт) приложить в конце отчета. Представить технические характеристики машины, которая использована для анализа эффективности методов сортировки. Привести временные оценки нагрузочных проверок в виде сводной таблицы и графика на каждом файле для каждого метода. Прокомментировать результаты выполненного анализа.
Вподразделе 4 представить разработанный метод SortData(Method). Описать особенности работы метода, представить алгоритм его функционирования. Представить временные оценки нагрузочных проверок метода SortData(Method) в виде сводной таблицы и графика на каждом файле исходных данных
Вподразделе 5 представить результаты стрессового тестирования с описанием некорректных ситуаций, причинами и способами их устранения.
Листинг программы после тестирования (шрифт Courier New, 10 пт) приложить к отчету в конце.
78
Контрольные вопросы и упражнения
1.Перечислите и охарактеризуйте методы обеспечения качества программного обеспечения.
2.Что такое тестирование компьютерной программы?
3.Что такое ожидаемое поведение программы?
4.Какие виды тестов и тестирования программного обеспечения применимы к разработанному программному приложению?
5.Что такое производительность программного обеспечения?
6.Укажите методы и способы оценивания производительности программного обеспечения.
7.Что понимается под эффективностью программного обеспечения?
8.Что понимается под сложностью программного обеспечения?
9.Каковы могут быть формы представления результатов оценивания эффективности программного обеспечения?
10.От чего зависит эффективность программного обеспечения?
11.Определить сложность заданного фрагмента программного кода. Предложить способы оценивания производительности и эффективности программного обеспечения на базе данного кода.
79
Список рекомендуемойлитературы
ГОСТы:
1.ГОСТ Р ИСО/МЭК 12207–99. ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ. Информационная технология. ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ.
2.ГОСТ Р ИСО/МЭК 15504-1-2009. Информационные технологии. Оценка процессов. Часть 1. Концепция и словарь Текст. Введ. 14.09.2009. – М. : Стандартинформ, 2010. – 19 с.
3.ГОСТ 34.601–90. Автоматизированные системы. Стадии создания. В кн.: Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. М.: Комитет стандартизации и метрологии
СССР,1991. – с.45-52.
4.ГОСТ 34.602–89. Техническое задание на создание автоматизированной системы. В кн.: Информационная технология. Комплекс стандартов и руководящих документов на АС. М.: Комитет стандартизации и метрологии СССР,1991.
–с.15-29
5.РД 50–34.698–90. Автоматизированные системы. Требования к содержанию документов. В кн.: Информационная технология. Комплекс стандартов и руководящих документов на АС. М.: Комитет стандартизации и метрологии СССР,1991. – с.66-104.
6.ГОСТ 19.701–90 (ИСО 5807-85). Схемы алгоритмов, программ, данных и систем. Госстандарт СССР, 1990. – 20 с.
Основная литература:
7.Штерн В. Основы С++. Методы программной инженерии: Пер. с англ. : монография. – М. : Лори, 2003. – 860с.
8.Муштаев В.И., Токарев В.И, Основы инженерного творчества : учеб.
пособие. – М. : Дрофа, 2005. – 254 с.
9.Мартин Р. Чистый код. Создание, анализ и рефакторинг : монография. –
СПб.: ПИТЕР, 2012. – 464 с.
10.Мартишин С.А., Симонов В.Л., Храпченко М.В. Основы теории надёжности информационных систем : учеб. пособие. – М. : ФОРУМ: ИНФРА-
М, 2013. – 254 с. : ил.
11.Бакалов В.П. Теория функциональной сложности информационных систем : монография / отв. ред. В.К. Попков. – Новосибирск : Наука, 2005. – 283 с.
12.Орлов С.А. Технологии разработки программного обеспечения : Учебник для вузов. – СПб. : ПИТЕР, 2002. – 463 с.
13.Лавров С.С. Программирование. Математические основы, средства, теория : монография. – СПб. : БХВ-Петербург, 2001. – 317 с.
14.Кнут Д.Э. Искусство программирования: В 3 т. : Пер. с англ. Т.3:Сортировка и поиск : монография / Под ред. Ю.В. Козаченко. – 2-е изд. – М.
:Издат.дом "Вильямс", 2003. – 822 с.
15.Вернер М. Основы кодирования : учебник / пер. с нем. Д.К. Зигангирова.
80