Все способы тестирования ПС объединяются базой данных, где помещаются результаты тестирования системы. В ней содержатся все компоненты, тестовые контрольные данные, результаты тестирования и информация о документировании процесса тестирования.
База данных проекта поддерживается специальными инструментальными средствами типа CASE, которые обеспечивают ведение анализа ПрО, сборку данных об их объектах, потоках данных и тому подобное. База данных проекта хранит также начальные и эталонные данные, которые используются для сопоставления данных, накопленных в базе, с данными, которые получены в процессе тестирования системы.
При тестировании выполняются разные виды расчетов характеристик этого процесса и способы планирования и управления.
1. Расчет продолжительности выполнения функций путем сбора средних показателей скорости выполнения операторов без выполнения программы на машине. Выявляются компоненты, которые требуют большого времени выполнения в реальной среде.
2. Управление выполнением тестирования путем подбора тестов проверки, их выполнения, селекции результатов тестирования и проведения сопоставления с эталонными значениями. Результаты данного процесса отображаются на дисплее, например, в графической форме (пути прохождения по графу программы), в виде диаграмм UML, данных об отказах и ошибках или конкретных значений исходных параметров программы. Эти данные анализируются разработчиками для формулирования выводов о направлениях дальнейшей проверки правильности программы или их завершении.
Лекция 1 | Программный анализ и формальные методы верификации | Наталья Шарыгина | Лекториум
3. Планирование тестирования предназначено для распределения сроков работ по тестированию, распределения тестировщиков по отдельным видам работ и составления ими тестов проверки системы. Определяются стратегия и пути тестирования. В диалоге запрашиваются данные о реальных значениях процесса выполнения системы, структуре ветвления вершин графа и параметрах циклов. Проверенные циклы, как правило, изымаются из путей выполнения программы. При планировании путей выполнения создаются соответствующие тесты, критерии и входные значения.
Документирование результатов тестирования в соответствии с действующим стандартом ANSI/IEEE 829 включает:
· технологии разработки системы;
· планов тестирования различных объектов, необходимых ресурсов, соответствующих специалистов для проведения тестирования и технологических способов;
· тестов, контрольных примеров, критериев и ограничений, оценки результатов программного продукта, а также процесса тестирования;
· учета процесса тестирования, составление отчетов об аномальных событиях, отказах и дефектах в итоговом документе системы.
Таким образом, были рассмотрены современные методы и процессы верификации и тестирования ПС, основанные на понятии программы — «белый ящик» и «черный ящик», а также на анализе реализованных в ПС функций. Определены критерии тестирования, типы ошибок, обнаруживаемых в программах, а также отказы и ошибки на этапах ЖЦ процесса тестирования. Сформулированы цели и задачи группы тестировщиков.
Podlodka #268 – Формальные методы и верификация программ
Контрольные вопросы и задания
1. Назовите формальные методы проверки правильности программ.
2. Какие процессы проверки зафиксированы в стандарте?
3. Какие функции у процесса верификации программ?
4. Назовите основные задачи процесса валидации программ.
5. Сравните задачи процессов верификации и валидации программ.
6. В чем отличие верификации и валидации?
7. Определите процесс тестирования.
8. Назовите методы тестирования.
9. Объясните значения терминов «черный ящик», «белый ящик».
10. Назовите объекты тестирования и подходы к их тестированию.
11. Какая существует классификация типов ошибок в программах?
12. Определите основные процессы ЖЦ тестирования ПО.
13. Наведите классификацию тестов для проверки ПО.
14. Какие задачи выполняет группа текстовиков?
15. Какая организация работ в проведении тестирования?
Тема 4. Формальные спецификации, доказательство и верификация программ
Современные направления в области проверки правильности программ — формальные спецификации и методы доказательства их правильности. Для доказательства того, что спецификация программы задает правильное решение некоторой задачи, для которой она разработана, привлекается математический аппарат.
В формальных методах нет рутинного написания спецификации на ЯП, а есть анализ текста и описание поведения программы в стиле, близком математической нотации, путем рассуждений и доказательств, принятых в математике. Формальные методы в программировании появились одновременно с самим программированием, на которое повлияли работы по теории алгоритмов А.А. Маркова [6.1], А.А. Ляпунова [6.2], схемы Ю.И.Янова [6.3], формальные нотации языка описания взаимодействующих процессов К.А. Хоара [6.4] и др.
В 70-х годах прошлого столетия появились формальные спецификации, которые близки ЯП и предоставляют средства, облегчающие проводить рассуждение о свойствах формальных тестов и сближающие их с математической нотацией. Несмотря на это, исследования формальных методов носили в основном академический, теоретический характер, поскольку извлечь из них практическую пользу в программировании не удавалось в силу огромных затрат на формальную спецификацию программ и разработку дополнительных [6.5-6.10] аксиом, утверждений и условий, называемых предварительными условиями (предусловиями) и постусловиями, определяющими заключительные правила получения правильного результата.
Под спецификацией понимается формальное описание функций и данных программы, с которыми эти функции оперируют. Различают видимые данные, т.е. входные и выходные параметры, а также скрытые данные, которые не привязаны к реализации и определяют интерфейс с другими функциями.
Предусловия — это ограничения на совокупность входных параметров и постусловия — ограничения на выходные параметры.Предусловие и постусловие задаются предикатами, т.е. функциями, результатом которых будет булевская величина ( / ). Предусловие истинно тогда, когда входные параметры входят в область допустимых значений данной функции.Постусловие истинно тогда, когда совокупность значений удовлетворяет требованиям, задающим формальное определениекритерия правильности получения результата.
Доказательство проводится с помощью утверждений, которые составляются в формальном языке и служат способом проверки правильности программы в заданных точках. Набор утверждений использует предусловия и последовательность операций, приводящих к проверке результата относительно отмеченной точки программы, для которой сформулировано заключительное утверждение. Если утверждение соответствует конечному оператору программы, где требуется получить окончательный результат, то с помощью заключительного утверждения и постусловия делается окончательный вывод о частичной или полной правильности работы программы.
цикл с предусловием — это цикл (то есть повторяющаяся последовательнось) , который будет выполняться, если условие в начале цикла будет верным. Цикл с постусловием — это цикл, в котором условие будет проверяться уже просле выполнения самого цикла (то есть цикл будет выполнен хотя бы один раз) . Цикл с параметром — это цикл (обычно FOR), в котором задается шаг, на который будет увеличиваться счетчик цикла после выполения тела цикла.
Ну, например, в Pascal и Delphi они выглядят так:
с предусловием:
while (условие) do begin end;
с постусловием:
repeat begin end untill (условие) ;
с параметром:
for i:=1 to n do begin end;
вместо i можно использовать любую другую переменную (целочисленную, т. е. Integer или Char)
i — это счетчик цикла
-
Условие — это
алгебраическое выражение, значение
которого либо «ложно», либо «истинно».
Обычно в выражениях присутствуют имена
переменных программы; каждому имени
соответствует значение соответствующей
переменной. Условия также называютлогическими выражениями,булевыми
выражениями илисуждениями. Если из истинности
условия Vнепосредственно
перед выполнением оператораSследует
истинность условияРпосле выполнения
этого оператора, то говорят, чтоVестьпредусловие дляпостусловия
Рпо отношению к оператору S.
Подобная взаимозависимостьV,РиSобычно
записывается как V>SР>. ОператорSможет быть простым или составным,
содержащим любое число отдельных
операторов, то есть может быть сегментом
программы или же целой программой. Результат выполнения
оператора, сегмента программы или
программы будет корректным, если
он удовлетворяется заданному постусловию.
Оператор программы (либо сегмент
программы, либо программа)завершается,
если его выполнение доходит до конца
за конечное время и при этом отсутствуют
ошибки фазы выполнения (и ошибки фазы
компиляции) — то есть его выполнение
приводит к получению вполне определенного
результата. Если выполнение
оператора, сегмента программы или
программы приводит к получению корректного
результата, когда бы он ни завершился,
то говорят, что оператор (сегмент
программы или программа) частично
корректный. Если, кроме того, доказано,
что его выполнение действительно
заканчивается, то говорят, что оператор
(сегмент программы или программа)полностью корректный. За счет
выделения таких двух аспектов в
корректности упрощаются доказательства. Предусловия и
постусловия представляют ключевые
моменты в доказательствах корректности.
Они выражают понятие «корректности»
конкретной программы или сегмента
программы. При записи различным образом,
предусловие и постусловие вместе
образуют общую спецификацию рассматриваемой
программы. Основные части стандартного
доказательства правильности предусловия
и постусловия и, в частности, их
взаимозависимости. Иногда можно
алгебраическим путем вывести предусловие
для заданного постусловия и заданного
оператора (простого или составного).
Такой подход особенно плодотворен в
случае операторов присваивания. Часто
задача сводится к проверке (доказательству)
утверждения о корректности предусловий
и постусловий сегмента программы. В
таком случае доказываемое утверждение
о корректности разбивается на утверждения
о корректности частей рассматриваемого
сегмента программы, и они доказываются
раздельно. Ряд полезных правил,
которые будут введены в последующих
подразделах, окажут помощь при выполнении
таких шагов.
Правила вывода (доказательства)
Правило усиления предусловия и ослабления постусловия
Предметом каждого
правила вывода является взаимосвязь
предусловия и постусловия. Начнем с
правила вывода, которое в ряде случаев
поможет упростить алгебраические
преобразования выражений, возникающих
в ходе доказательства. Это правило
следует из вышеприведенного определения
предусловий и постусловий и упрощает
восприятие ряда других правил.
Правило вывода
Р1 – «Усиление предусловия
и ослабление постусловия»
V V1
and
P1 P
Если условие Vистинно перед выполнением оператораOP и если из VследуетV1, тоV1
истинно перед выполнением оператора OP.
ЕслиV1 является
предусловием дляP1 по отношению кOP, тоP1 будет
истинным после выполнения оператора OP.
Если, наконец, изP1 следуетР, то
и Рбудет истинным
после выполнения оператора OP.
Иными словами, из истинности Vперед выполнениемOPследует истинностьРпосле его
выполнения. Следовательно,Vявляется предусловием дляРпо
отношению к OP.
Продвигаясь по
программе в обратном направлении,
можноусилить условия. Усиление
условие может быть достигнуто путем
добавления произвольного элемента с
помощью операции логического умноженияandили отбрасыванием
элемента, участвующего в операции
логического сложенияor.
Двигаясь по
программе в прямом направлении,
можно ослабить условия. Условие может
быть ослаблено добавлением произвольного
элемента с помощью операции логического
сложенияorили отбрасыванием
элемента, участвующего в операции
логического умноженияand.
Разумное усиление
предусловий или ослабление постусловий
(что встречается реже) может привести
к получению более простых выражений и
сокращению (иногда значительному) объема
алгебраических преобразований в процессе
доказательства. Вместе с тем, здесь
следует соблюдать известную осторожность,
чтобы не усилить предусловие или не
ослабить постусловие столь сильно, что
нельзя будет завершить доказательство.
В приводимых ниже примерах показывается,
каким образом можно легко обойти такую
потенциально возможную проблему.
Источник: testirovanie24.ru
Лекция 2. Тестирование программного кода. Задачи и цели тестирования программного кода. Оценка качества тестируемого кода
При проверке правильности программ и систем рассматриваются процессы верификации, валидации и тестирования ПС, которые регламентированы в стандарте ISO/IEC 12207 жизненного цикла ПО. В некоторой зарубежной литературе процессы верификации и тестирования отождествляются.
Тестирование — это процесс обнаружения ошибок в ПО путем исполнения выходного кода ПС на тестовых данных.
2.1 Тестирование программ
Тестирование можно рассматривать, как процесс семантической отладки (проверки) программы, заключающийся в исполнении последовательности различных наборов контрольных тестов, для которых заранее известен результат. Т.е. тестирование предполагает выполнение программы и получение конкретных результатов выполнения тестов.
Цель тестирования — проверка работы реализованных функций в соответствии с их спецификацией. Методы функционального тестирования подразделяются на статические и динамические.
2.1.1. Статические методы тестирования
Статические методы используются при проведении инспекций и рассмотрении спецификаций компонентов без их выполнения. Техника статического анализа заключается в методическом просмотре (или обзоре) и анализе структуры программ, а также в доказательстве их правильности. Статический анализ направлен на анализ документов, разработанных на всех этапах ЖЦ, и заключается в инспекции исходного кода и сквозного контроля программы.
Инспекция ПО — это статическая проверка соответствия программы заданным спецификациям, проводится путем анализа различных представлений результатов проектирования (документации, требований, спецификаций, схем или исходного кода программ) на процессах ЖЦ..
Кроме того, разрабатывается множество новых способов автоматизации символьного выполнения программ. Например, автоматизированное средство статического контроля для языков ориентированной разработки, инструменты автоматизации доказательства корректности и автоматизированный аппарат сетей Петри.
2.1.2. Динамические методы тестирования
Динамические методы тестирования используются в процессе выполнения программ. Они базируются на графе, связывающем причины ошибок с ожидаемыми реакциями на эти ошибки. В процессе тестирования накапливается информация об ошибках, которая используется при оценке надежности и качества ПС.
Цель динамического тестирования программ по принципу «черного ящика» — выявление одним тестом максимального числа ошибок с использованием небольшого подмножества возможных входных данных.
Методы «черного ящика» обеспечивают:
· анализ граничных значений;
· применение функциональных диаграмм, которые в соединении с реверсивным анализом дают достаточно полную информацию о функционировании тестируемой программы.
«Белый ящик» базируется на структуре программы, в случае «черного ящика», о структуре программы ничего неизвестно. Для выполнения тестирования с помощью этих «ящиков» известными считаются выполняемые функции, входы (входные данные) и выходы (выходные данные), а также логика обработки, представленные в документации.
2.1.3. Функциональное тестирование
Цель функционального тестирования — обнаружение несоответствий между реальным поведением реализованных функций и ожидаемым поведением в соответствии со спецификацией и исходными требованиями.
Функциональные тесты создаются по внешним спецификациям функций, проектной информации и по тексту на ЯП, относятся к функциональным его характеристикам и применяются на этапе комплексного тестирования и испытаний для определения полноты реализации функциональных задач и их соответствия исходным требованиям.
В задачи функционального тестирования входят:
· идентификация множества функциональных требований;
· идентификация внешних функций и построение последовательностей функций в соответствии с их использованием в ПС;
· идентификация множества входных данных каждой функции и определение областей их изменения;
· построение тестовых наборов и сценариев тестирования функций;
· выявление и представление всех функциональных требований с помощью тестовых наборов и проведение тестирования ошибок в программе и при взаимодействии со средой.
Тесты, создаваемые по проектной информации, связаны со структурами данных, алгоритмами, интерфейсами между отдельными компонентами и применяются для тестирования компонентов и их интерфейсов. Основная цель — обеспечение полноты и согласованности реализованных функций и интерфейсов между ними.
2.2 Инфраструктура процесса тестирования ПС
Под инфраструктурой процесса тестирования понимается:
· выделение объектов тестирования;
· проведение классификации ошибок для рассматриваемого класса тестируемых программ;
· подготовка тестов, их выполнение и поиск разного рода ошибок и отказов в компонентах и в системе в целом;
· служба проведения и управление процессом тестирования;
· анализ результатов тестирования.
Объекты тестирования — компоненты, группы компонентов, подсистемы и система.
2.2.1 Методы поиска ошибок в программах
Международный стандарт ANSI/IEEE-729-83 разделяет все ошибки в разработке программ на следующие типы.
Ошибка (error) — состояние программы, при котором выдаются неправильные результаты, причиной которых являются изъяны (flaw) в операторах программы или в технологическом процессе ее разработки, что приводит к неправильной интерпретации исходной информации, следовательно, и к неверному решению.
Дефект (fault) в программе — следствие ошибок разработчика на любом из этапов разработки, которая может содержаться в исходных или проектных спецификациях, текстах кодов программ, эксплуатационной документация и т.п. В процессе выполнения программы может быть обнаружен дефект или сбой.
Отказ (failure) — это отклонение программы от функционирования или невозможность программы выполнять функции, определенные требованиями и ограничениями, что рассматривается как событие, способствующее переходу программы в неработоспособное состояние из-за ошибок, скрытых в ней дефектов или сбоев в среде функционирования. Отказ может быть результатом следующих причин:
· ошибочная спецификация или пропущенное требование, означающее, что спецификация точно не отражает того, что предполагал пользователь;
· спецификация может содержать требование, которое невозможно выполнить на данной аппаратуре и программном обеспечении;
· проект программы может содержать ошибки (например, база данных спроектирована без средств защиты от несанкционированного доступа пользователя, а требуется защита);
· программа может быть неправильной, т.е. она выполняет несвойственный алгоритм или он реализован не полностью.
Таким образом, отказы, как правило, являются результатами одной или более ошибок в программе, а также наличия разного рода дефектов.
2.2.2. Классификация ошибок и тестов
Каждая организация, разрабатывающая ПО общесистемного назначения, сталкивается с проблемами нахождения ошибок. Поэтому приходится классифицировать типы обнаруживаемых ошибок и определять свое отношение к устранению этих ошибок.
Таблица 2.1. Ортогональная классификация дефектов IBM
| Контекст ошибки | Классификация дефектов |
| Функция | Ошибки интерфейсов конечных пользователей ПО, вызванные аппаратурой или связаны с глобальными структурами данных |
| Интерфейс | Ошибки во взаимодействии с другими компонентами, в вызовах, макросах, управляющих блоках или в списке параметров |
| Логика | Ошибки в программной логике, неохваченной валидацией, а также в использовании значений переменных |
| Присваивание | Ошибки в структуре данных или в инициализации переменных отдельных частей программы |
| Зацикливание | Ошибки, вызванные ресурсом времени, реальным временем или разделением времени |
| Среда | Ошибки в репозитории, в управлении изменениями или в контролируемых версиях проекта |
| Алгоритм | Ошибки, связанные с обеспечением эффективности, корректности алгоритмов или структур данных системы |
| Документация | Ошибки в записях документов сопровождения или в публикациях |
Исследования фирм IBM показали, чем позже обнаруживается ошибка в программе, тем дороже обходится ее исправление, эта зависимость близка к экспоненциальной. Так военно-воздушные силы США оценили стоимость разработки одной инструкции в 75 долларов, а ее стоимость сопровождения составляет около 4000 долларов.
Создаются тесты, проверяющие:
· корректность выполнения функций и правильность функционирования системы в заданных условиях;
· надежность выполнения системы;
· защиту от сбоев аппаратуры и не выявленных ошибок и др.
2.2.3 Служба тестирования ПС
Для этих целей, как правило, создается служба проверяющих ПС — команда тестировщиков, которая не зависит от штата разработчиков ПС. Некоторые члены этой команды — опытные или даже профессионалы в этой области. К ним относятся аналитики, программисты, инженеры-тестировщики, которые посвящают в проблемы тестирования систем с начала разработки. Они имеют дело не только со спецификациями, но и с методами и средствами тестирования, организуют создание и выполнение тестов. С самого начала создания проекта тестировщики составляют планы тестирования, тестовые данные и сценарии, а также графики выполнения тестов.
2.2.4 Управление процессом тестирования
Все способы тестирования ПС объединяются базой данных, где помещаются результаты тестирования системы. В ней содержатся все компоненты, тестовые контрольные данные, результаты тестирования и информация о документировании процесса тестирования.
База данных проекта поддерживается специальными инструментальными средствами типа CASE, которые обеспечивают ведение анализа ПрО, сборку данных об их объектах, потоках данных и тому подобное. База данных проекта хранит также начальные и эталонные данные, которые используются для сопоставления данных, накопленных в базе, с данными, которые получены в процессе тестирования системы.
Контрольные вопросы и задания
1. Назовите формальные методы проверки правильности программ.
2. Какие процессы проверки зафиксированы в стандарте?
3. Какие функции у процесса верификации программ?
4. Назовите основные задачи процесса валидации программ.
5. Сравните задачи процессов верификации и валидации программ.
6. В чем отличие верификации и валидации?
7. Определите процесс тестирования.
8. Назовите методы тестирования.
9. Объясните значения терминов «черный ящик», «белый ящик».
10. Назовите объекты тестирования и подходы к их тестированию.
11. Какая существует классификация типов ошибок в программах?
12. Определите основные процессы ЖЦ тестирования ПО.
13. Наведите классификацию тестов для проверки ПО.
14. Какие задачи выполняет группа текстовиков?
15. Какая организация работ в проведении тестирования?
Источник: www.megapredmet.ru
Лекция 8: Методы проверки и тестирования программ и систем
За функциональные и исполнительные тесты несут ответственность разработчики заказчик, он больше влияет на составление тестов испытаний и инсталляции системы [7.6].
Для этих целей, как правило, создается служба проверяющих ПС — команда тестировщиков, которая не зависит от штата разработчиков ПС. Некоторые члены этой команды — опытные или даже профессионалы в этой области. К ним относятся аналитики, программисты, инженерытестировщики, которые посвящают в проблемы тестирования систем с начала разработки. Они имеют дело не только со спецификациями, но и с методами и средствами тестирования, организуют создание и выполнение тестов. С самого начала создания проекта тестировщики составляют планы тестирования, тестовые данные и сценарии, а также графики выполнения тестов.
Профессиональные тестировщики работают совместно с группой управления конфигурацией, чтобы обеспечить их документацией и другими механизмами для связи между собой тестов с требованиями проекта, конфигурацией и кодом. Они разрабатывают методы и процедуры тестирования. В эту команду включаются дополнительные специалисты, которые знакомы с требованиями системы или с подходами к их разработке. Аналитиков включают в команду, так как они понимают проблемы определения спецификаций заказчиков.
Многие специалисты сравнивают тестирование системы с созданием новой системы, в которой аналитики отражают потребности и цели заказчика, работая совместно с проектировщиками и добиваясь реализации идей и принципов работы системы.Проектировщики системы сообщают команде тестировщиков проектные цели, чтобы они знали декомпозицию системы на подсистемы и ее функции, а также принципы их работы. После проектирования тестов и тестовых покрытий, команда тестировщиков проводит анализ возможностей системы.
Так как тесты и тестовые сценарии являются прямым отражением требований и проекта в целом, перспективы управления конфигурацией системы определяются именно этой командой. Обнаруживаемые в программе ошибки и изменения в системе отражаются в документации, требованиях, проекте, а также в описаниях входных и выходных данных или в других разрабатываемых артефактах. Вносимые изменения в процессе разработки приводят к модификации тестовых сценариев или в большей части к изменению планов тестирования. Специалисты по управлению конфигурацией учитывают эти изменения и координируют составление тестов.
В команду тестировщиков входят также пользователи. Они оценивают получаемые результаты, удобство использования, а также высказывают свое мнение о принципах работы системы.
Уполномоченные заказчика планируют работы для тех пор, пока используется и сопровождается система. При этом они могут привнести некоторые изменения в проект из-за неполноты заданных требований и сформулировать системные требования для проведения верификации системы и принятия решений о ее готовности и полезности.
План тестирования.Для проведения тестирования создается план ( Test Plan ), в котором описываются стратегии, ресурсы и график тестирования отдельных компонентов и системы в целом. В плане отмечаются работы для разных членов команды, которые выполняют определенные роли в этом процессе. План включает также определение роли тестов в каждом процессе, степень покрытия программы тестами и процент тестов, которые выполняются со специальными данными.
Тестовые инженеры создают множество тестовых сценариев ( Test Cases ), каждый из которых проверяет результат взаимодействия между актором и системой на основе пред- и постусловий использования таких сценариев. Сценарии в основном относятся к тестированию по типу белого «ящика» и ориентированы на проверку структуры и операций интеграции компонентов системы.
Для проведения тестирования тестовые инженеры предлагают процедуры тестирования ( Test Procedures ), включающие валидациюобъектов и верификацию тестовых сценариев в соответствии с планом графикам. Оценка тестов (Test Evaluation) заключается в оценке результатов тестирования, степени покрытия программ сценариями и статуса полученных ошибок.
На рис. 7.5. приведен круг обязанностей инженератестировщика.
Рис. 7.5. Ответственности инженера-тестировщика
Тестировщик интегрированной системы проводит тестирование интерфейсов и дает оценку результатов выполнения соответствующих тестов с помощью создаваемых им системных тестов, выполняет анализ результатов тестирования, проведенного с отдельными элементами системы. При выполнении системных тестов, как правило, находятся дефекты, как результат глубоко скрытых погрешностей в программах, обнаруживаемых при длительной прогонке системы на тестовых данных и сценариях.
7.3.2. Управление процессом тестирования
Все способы тестирования ПС объединяются базой данных, где помещаются результаты тестирования системы. В ней содержатся все компоненты, тестовые контрольные данные, результаты тестирования и информация о документировании процесса тестирования.
База данных проекта поддерживается специальными инструментальными средствами типа CASE, которые обеспечивают ведение анализа ПрО, сборку данных об их объектах, потоках данных и тому подобное. База данных проекта хранит также начальные и эталонные данные, которые используются для сопоставления данных,накопленных в базе, с данными, которые получены в процессе тестирования системы.
При тестировании выполняются разные виды расчетов характеристик этого процесса и способы планирования и управления.
- Расчет продолжительности выполнения функций путем сбора средних показателей скорости выполнения операторов без выполнения программы на машине. Выявляются компоненты, которые требуют большого времени выполнения в реальной среде.
- Управление выполнением тестирования путем подбора тестов проверки, их выполнения, селекции результатов тестирования и проведения сопоставления с эталонными значениями. Результаты данного процесса отображаются на дисплее, например, в графической форме (пути прохождения по графу программы), в виде диаграмм UML, данных об отказах и ошибках или конкретных значений исходных параметров программы. Эти данные анализируются разработчиками для формулирования выводов о направлениях дальнейшей проверки правильности программы или их завершении.
- Планирование тестирования предназначено для распределения сроков работ по тестированию, распределения тестировщиков по отдельным видам работ и составления ими тестов проверки системы. Определяются стратегия и пути тестирования. В диалоге запрашиваются данные о реальных значениях процесса выполнения системы, структуре ветвления вершин графа и параметрах циклов. Проверенные циклы, как правило, изымаются из путей выполнения программы. При планировании путей выполнения создаются соответствующие тесты, критерии и входные значения.
Документирование результатов тестирования в соответствии с действующим стандартом ANSI/IEEE 829 включает:
Таким образом, были рассмотрены современные методы и процессы верификации и тестирования ПС, основанные на понятии программы — «белый ящик» и «черный ящик», а также на анализе реализованных в ПС функций. Определены критерии тестирования, типы ошибок, обнаруживаемых в программах, а также отказы и ошибки на этапах ЖЦ процесса тестирования. Сформулированы цели и задачи группы тестировщиков.
Контрольные вопросы и задания
- Назовите формальные методы проверки правильности программ.
- Какие процессы проверки зафиксированы в стандарте?
- Какие функции у процесса верификации программ ?
- Назовите основные задачи процесса валидации программ.
- Сравните задачи процессов верификации и валидации программ.
- В чем отличие верификации и валидации?
- Определите процесс тестирования.
- Назовите методы тестирования.
- Объясните значения терминов «черный ящик», «белый ящик».
- Назовите объекты тестирования и подходы к их тестированию.
- Какая существует классификация типов ошибок в программах?
- Определите основные процессы ЖЦ тестирования ПО.
- Наведите классификацию тестов для проверки ПО.
- Какие задачи выполняет группа текстовиков?
- Какая организация работ в проведении тестирования?
Источник: intuit.ru