Верификация и аттестация Метод "чистая комната"
1. Формальная спецификация. Для системы формальная спецификация. Для записи спецификации используется
модель состояний, в которой отображены отклики системы на стимулы.
2.Пошаговая разработка. Разработка разбивается на несколько этапов, которые выполняются и проверяются методом ''чистая комната" независимо друг от друга. Этапы определяются совместно с заказчиком на ранних стадиях процесса создания.
3.Структурное программирование. Используется только ограниченное количество управляющих конструкций и абстракций данных. Процесс разработки программы — это процедура поэтапной детализации спецификации.
4.Статическая верификация. Разрабатываемое ПО проверяется статическим методом строгого инспектирования ПО. Для модулей или отдельных элементов тестирование кода не проводится.
5.Статистическое тестирование системы. На каждом шаге разработки проводится тестирование статистическими методами, позволяющими
оценить© 2005, В.В.Хашковский,надежностьД.П.Калачевпрограммной. системы. 21
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
(Software engineering)
Учебный курс
очного обучения по специальностям 230105 «Программное обеспечение вычислительной техники и автоматизированных систем»
010503 «Математическое обеспечение и администрирование информационных систем» кафедры
Л Е К Ц И Я
5.2
Испытания
программных
систем.
МОП ЭВМ
8 семестр
Тестирование
программного
обеспечения.
В.В.Хашковский, к.т.н., доц. каф. МОП ЭВМ ТРТУ
Д.П.Калачев, доц., к.т.н., доц. каф. МОП ЭВМ
ТРТУ
Тестирование программного обеспечения Цели изучения и рассматриваемые вопросы
Цель — познакомиться с методами тестирования программного обеспечения, которые используются для обнаружения ошибок и дефектов в программах:
знать, какие методы тестирования используются для выявления программных ошибок;
познакомиться с основными принципами тестирования интерфейсов;
знать особенности покомпонентного тестирования и тестирования процесса сборки объектно- ориентированных систем;
познакомиться с CASE-средствами, применяемыми для тестирования.
© 2005, В.В.Хашковский, Д.П.Калачев. |
23 |
Верификация и аттестация ПО Определения
Тестирование ПО. Запуск исполняемого кода с тестовыми данными и исследование выходных данных и рабочих характеристик программного продукта для проверки правильности работы системы.
Тестирование ПС это процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом.
Отладка ПС - это деятельность, направленная на обнаружение и исправление ошибок в ПС с использованием процессов выполнения его программ.
Отладка = Тестирование + Поиск ошибок + Редактирование. Таким
образом, отладку можно представить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки в программах и документации ПС и редактирования программ и документации с целью устранения обнаруженной ошибки.
© 2005, В.В.Хашковский, Д.П.Калачев. |
24 |
Тестирование программного обеспечения Тестирование дефектов
Целью тестирования дефектов является выявление в программной системе скрытых дефектов до того, как она будет сдана заказчику.
Тестирование дефектов противоположно аттестации, в ходе которой проверяется соответствие системы своей спецификации. Во время аттестации система должна корректно работать со всеми заданными тестовыми данными. При тестировании дефектов запускается такой тест, который вызывает некорректную работу программы
и, следовательно, выявляет дефект. Обратите внимание на эту важную особенность: тестирование дефектов демонстрирует наличие, а не отсутствие дефектов в программе.
© 2005, В.В.Хашковский, Д.П.Калачев. |
25 |
Тестирование программного обеспечения Тестирование дефектов
Тестовые сценарии — это спецификации входных тестовых данных и ожидаемых выходных данных плюс описание процедуры тестирования.
Тестовые данные иногда генерируются автоматически. Автоматическая генерация тестовых сценариев невозможна, поскольку результаты проведения теста не всегда можно предсказать заранее.
© 2005, В.В.Хашковский, Д.П.Калачев. |
26 |
Тестирование программного обеспечения
|
Методы тестирование ( |
) |
|
|
|
Black-, Gray-, White-box Testing |
|
Input determined by... |
|
Result |
|
|
Actual output |
||
|
|
|
|
|
|
Black box |
|
|
… requirements |
compared |
|
|
|
with |
|
|
|
|
|
|
|
|
required output |
|
|
|
|
|
… requirements & |
Gray box |
As for black- |
|
|
||
|
|
and white box |
|
|
key design elements |
|
|
|
|
testing |
|
|
|
|
|
|
|
|
|
|
|
White box |
|
|
…design |
|
Confirmation |
|
|
of expected |
|
|
elements |
|
|
|
|
behavior |
|
|
|
|
|
© 2005, В.В.Хашковский, Д.П.Калачев. |
|
27 |
|
|
|||
Тестирование программного обеспечения
Метод «черного» ящика |
Black box |
|
|
Функциональное тестирование, или тестирование методом черного ящика базируется на том, что все тесты
основываются на спецификации системы или ее компонентов.
Система представляется как "черный ящик", поведение которого можно определить только посредством изучения ее входных и соответствующих выходных данных.
Другое название этого метода — функциональное тестирование — связано с тем, что испытатель проверяет не реализацию ПО, а только его выполняемые функции.
© 2005, В.В.Хашковский, Д.П.Калачев. |
28 |
Тестирование программного обеспечения
Метод «белого» ящика |
|
|
White box |
|
|
|
|
|
|
|
|
Метод структурного тестирования предполагает создание тестов на основе структуры системы и ее реализации.
Такой подход иногда называют тестированием методом "'белого ящика", "стеклянного ящика" или "прозрачного ящика", чтобы отличать его от тестирования методом черного ящика.
Как правило, структурное тестирование применяется к относительно небольшим программным элементам, например к подпрограммам или методам, ассоциированным с объектами. Например, из анализа кода можно определить, сколько контрольных тестов 29
© 2005, В.В.Хашковский, Д.П.Калачев.
нужно выполнить для того, чтобы в процессе тестирования все операторы выполнились по
крайней мере один раз.
Тестирование программного обеспечения Тестирование интерфейсов
Ошибки в интерфейсах являются наиболее распространенными типами ошибок в сложных системах и делятся на три класса.
Неправильное использование интерфейсов. Компонент вызывает другой
компонент и совершает ошибку при использовании его интерфейса. Данный тип ошибки особенно распространен в параметрических интерфейсах; например, параметры могут иметь неправильный тип, следовать в неправильном порядке или же иметь неверное количество параметров.
Неправильное понимание интерфейсов. Вызывающий компонент, в который заложена неправильная интерпретация спецификации интерфейса вызываемого
компонента, предполагает определенное поведение этого компонента. Если поведение вызываемого компонента не совпадает с ожидаемым, поведение вызывающего компонента становится непредсказуемым. Например, если программа бинарного поиска вызывается для поиска заданного элемента в неупорядоченном массиве, то в работе программы произойдет сбой.
Ошибки синхронизации. Такие ошибки встречаются в системах реального времени, где используются интерфейсы разделяемой памяти или передачи сообщений. Подсистема — производитель данных и подсистема — потребитель
данных могут работать с разной скоростью. Если при проектировании интерфейса не учитывать этот фактор, потребитель может, например, получить доступ к устаревшим данным, потому что производитель к тому моменту еще не успел обновить совместно используемые данные.
© 2005, В.В.Хашковский, Д.П.Калачев. |
30 |