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

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

1) Стратегия черного ящика.

2) Стратегия белого ящика.

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

1) Эквивалентное разбиение

2) Анализ граничных значений

3) Функциональные диаграммы

4) гипотеза ошибок

1) Метод эквивалентных разбиений состоит в разбиении входных данных (входной области) на конечное число классов эквивалентности, при которых каждый тест некоторого класса эквивалентен в смысле обнаружения ошибок любому другому тесту этого класса. Разработка методов эквивалентного разбиения осуществляется в 2 этапа

1) Выделение эквивалентных классов

2) Построение теста на этом классе.

Классы эквивалентности: выделяются на основе анализа входной области и спецификации программы. При этом различают 2 класса эквивалентности правильный и неправильный.

1) О законах непрерывности данных

2) Непрерывной

При построении эквивалентных областей используется следующая последовательность действий

1) Каждому классу эквивалентности назначен уникальный номер.

2) Из множества правильных тестов выбирается тот, который накрывает наибольшее число классов эквивалентности

3) Для каждого неправильного класса эквивалентности вырабатывается отдельных индивидуальный тест

2) Метод граничных значений

Метод, дополненный до проверки на границе области.

Главным недостатком методов эквивалентного разбиения и граничных значений является то, что они не могут рассмотреть комбинации входных условий.

3) Метод функциональных диаграмм

Метод был разработан фирмой IВМ и представляет собой оценку причинно-следственных связей, где входными данными являются причины, а выходными- следствия. Метод функциональных диаграмм представляет собой формальный язык, на котором транслируются спецификации, написанные на естественном языке.. Построение тестов осуществляется в несколько этапов для уменьшения громоздкости и трудоемкости, спецификация разрабатывается на рабочем участке в каждом рабочем участке, определяется причины, которые характеризуют отдельное входное условие или определяют некоторые остаточные действия программы. Каждой причине и следствию присваивается отдельный номер. Причинно- следственные отношения отображаются в виде булевого отношения или графа с двумя узлами и дугой, где под дугой понимаются логические условия «и», «или», «не». Полученный граф и получит название функциональной диаграммы, Ограниченные и синтаксически невозможные комбинации причин и следствия оформляются отдельно, как приложение к функциональной диаграмме и рассматриваются самостоятельно.

Лекция 15

Методы функциональных диаграмм

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

В процессе прослеживания решений, состояния решений преобразуется в некоторую таблицу, где столбцами служат тесты с ограниченными входами, т.е столбцы формируются в тесты, которые при оптимизации можно применять оптимальный объем или на неограниченный объем.

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

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

Недостатки данного подхода.

1) По определению исчерпывающего тестирования невозможно провести.

2) Нет гарантии того, что программа соответствует своим спецификациям, т.е программа жестко следует спецификации.

3) В программе могут быть пропущены некоторые операторы и условия.

4) Исчерпывающее тестирование не может выявить ряд ошибок условного характера, т.е по абсолютной величине а-в<ε

|A| - |B| ≤ ε: A>0: B>0: |A-B|≤ ε

Особенности тестирования черного и белого ящика

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

Стратегия белого ящика

Метод один поиск всех маршрутов, а критериев несколько.

Следующие критерии:

1) Критерии покрытия операторов

2) Критерии покрытия решений

3) Критерии покрытия условий

4) Критерии решений –условий

5) Критерии комбинаторного покрытия, т.е критерии белого ящика определяет покрытия логики программы.

1) Критерии операторов- когда по операторам пройтись хоть раз

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

3) Критерии условий. Являются более сильными критериями, при котором выполняется требование «пройтись хотя бы однократно по результатам каждого условия». Иначе говоря, поскольку при данном критерии не всегда удается пройтись по всем операторам, то и указанное требование дополняется требованием, что в каждой точке программы хотя бы один раз было передано управление покрытия условий.

4) Это такой критерий, как и (3), только в тестах должны еще участвовать анализ решений.

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

Известны 3 метода предупреждения и выявления ошибок.

1) Выбор оптимальной технологии разработки программного изделия, поддерживаемой мощными инструментальными средствами, четко регламентированными действиями, процессом разработки Программного изделия, что, в конечном счете, позволяет избежать множества ошибок.

2) Метод проведения поэтапной разработки программного изделия, а точнее проверку состояния программного изделия в конце каждого этапа разработки его жизненного цикла позволяет обнаружить и локализовать ошибки до следующего этапа разработки.

3) Программно-целевой метод тестирования программного изделия, состоит в четкой ориентации тестов на конкретные цели тестирования каждого шага разработки, например,цели: тестирование особых ситуаций, тестирование операционной памяти, тестирование загрузки.

Выбор способа сборки программного изделия из отдельных его модулей наиболее важный

этап тестирования целого программного изделия. Именно здесь определяется форма направления тестов модуля, типы средств использующихся при тестировании, порядок тестирования модулей локализации и направления ошибок.

Для решения поставленной проблемы выбора, для решения процессов- разработано 2 подхода

1) Монолитное тестирование

2) Пошаговое тестирование(может быть как восходящим, так и нисходящим).

Монолитное тестирование предусматривает проверку всей программы целиком(комплекс программ)

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

Анализ двух указанных подходов(преимущества и недостатки)

1) Монолитное тестирование более трудоемкий процесс сравнительно с пошаговым.

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

3) При пошаговом тестировании менее трудоемка отладка и поиск ошибок, т.е локализация ошибок и внешних изменений не влечет за собой переделку всего модуля.

4) Качество тестирования при пошаговом подходе выше, чем при монолитном тестировании, поскольку при пошаговом тестировании модулей, все оттестируемые модули могут выступать в виде заглушек и не участвовать в трудоемкой разработке тестов.

5) Затраты машинного времени в большинстве случаев при монолитном тестировании как правило меньше, чем при пошаговом, т.к при монолитном тестировании выполняется отдельный модуль, который просто передает управление, тогда как в конце тестирование производится в полном объеме.

6) Монолитное тестирование создает хорошие предпосылки для распространения процессов тестирования.

В связи со слабой формализованностью описания требований к программному изделию и составлению пользовательской документации, наконец, отсутствие методологии написания тестов для проверки системы выделены 15 категорий тестов, обеспечивающих тестирование системы разработки программного обеспечения.

1) Тестирование удобств пользователя, т.е тестирование каждого пункта пользовательской документации.

2) Тестирование на предельных объектах

Цель: показать, что программа не может управлять максимальным объемом данных специфицированными в исходных требованиях, т.е в техническом задании прописан максимальный объем памяти 12 мб..

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

4) Тестирование удобства эксплуатации, когда человеческому фактору уделяется большое внимание. Эти тесты ориентированы в основном на выявление психологической совместимости проблем возникающих при работе программного обеспечения

5) Тестирование защиты, которое представляет собой систему проверок информации от несанкционированного доступа в систему. Цель состоит в том, чтобы построить такой тест, который позволял бы вскрыть недостатки системы и на них войти в систему.

6) Тестирование производительности или эффективности программного обеспечения.

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

7) Тестирование требований к памяти, т.е необходимость проверить предельные объемы оперативной и внешней памяти,в любой момент времени работы программного изделия.

8) Тестирование конфигураций оборудования, как правило, тестируемые системы является достаточно большими, и обладают достаточной адаптируемостью к любой конфигурации. Поскольку конфигураций достаточно большое число, то и тестирование должно учитывать и эти проблемы конфигураций.

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

9) Тестирование удобств установки программного обеспечения- оно проверяет установку достаточно сложного программного продукта, на конкретные условия эксплуатации.

10) Тестирование надежности в настоящее время носит принципиальный характер и является важнейшим показателем разработки программного обеспечения.

11) Тестирование восстановления

Существует ряд программных систем:

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

12) Тестирование удобств обслуживания, как правило, состоит из комплекса инструментальных средств, облегчающих сопровождения программного обеспечения. Это возможность получения данных, все те средства, позволяющие изучить более детально тестирование программного обеспечения.

13) Тестирование документации

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

14) Тестирование процедур: если программное обеспечение является некоторой частью подсистемы обработки данных большой системы, в которой имеются процедуры выполняемые человеком, то эти процедуры должны быть протестированы

Анализ: трудоемкость тестирования составляет от 20 до 60% от всего объема работ, причем львиная доля его составляет -выбор необходимой исходной информации для получения эталонных значений. Эта задача резко экспоненциально растет, когда речь идет о комплексном тестировании огромного объема маршрутов, когда необходимо протестировать предельные нагрузки на программное обеспечение. Нередкий случай,когда ручная разработка тестов практически невозможна и специально создается и ……..позволяющая генерирование тестов.

Методы отладки:

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

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

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

Лекция 16

Известны три источника ошибок в написании программы (с точки зрения анализа их распределения) – это алгоритмические ошибки или неверный выбор алгоритма решения задачи. Эти ошибки могут иметь наиболее серьезный характер впоследствии до полной переработки программы. К ним относятся: не учет или неполный учет данных, неправильное понимание структуры рассмотрения алгоритма, как неполного подмножества данных, данные, выходящие за пределы задач, не знание или неполное знание средств вычислительной техники, незнание команд ЭВМ, языковых средств, возможностей среды разработки.

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

Основная задача программиста состоит в том, чтобы его программа работала без ошибок.

Классификация ошибок по их внутреннему содержанию.

Основные классы ошибок.

1) Отсутствие инициализации переменных.

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

Этот вид ошибок связан, как правило, с оформлением переменных на локальном уровне.

2) Ошибки индикации – это наиболее распространенные ошибки, когда обращение происходит за пределами памяти.

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

4) Ошибки, связанные с формулировкой условий.

5) Арифметические ошибки – это большой класс ошибок, связанный с аварийными ситуациями: деление на ноль, выхождение за пределы объема.

6) Ошибки косвенного доступа.

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

7) Висячие ошибки.

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

8) Ошибки синхронизации

Одна из наиболее трудно уловимых ошибок, как правило, связанная с параллельными процессами.

9) Исторические ошибки – ошибки, связанные с данными, которые мы изменяем.

Способы проявления ошибок или симптомы проявления ошибок.

Неверная выдача:

1) Когда программа, завершается, а результат не верен.

2) Когда программа завершается, но

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

4) Программа завершается, и ее выдача соответствует ожидаемым результатам, прог, читаемых прог обработки данных сложной структуры. Здено хранимые данные испорченны.

Основной вывод.

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

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

Методы, используемые при поиске ошибок.

(делят на 2 категории)

1) Аналитический подход, когда методы поиска ошибок построены на анализе входных или выходных данных, т.е. по форме объекта.

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

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

В аналитическом способе нагрузка ложиться на аналитические способности программиста.

В экспериментальном - на программу, когда она проверяет ошибки.

Золотые правила отладки.

1) Обнаружив симптомы ошибки, даже если они имеют мерцающий характер, никогда не списывайте на ошибку ЭВМ.

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

3) Обнаружив в ходе анализа ошибку, неверную часть программы, убедитесь в том, что именно она является источником ошибок через конкретные расчеты (ручные).

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

Оценка качества разработки ПО.

Основные показатели качества ПО.

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

Какие программы считать хорошими?

Многообразие пользовательских интерфейсов приводит к тому, что для ПО невозможно создать формальную систему требований к его качеству. В промышленности высокое качество достигается за счет контрольных средств, т.е. контроль проводится простым сравнением. ПО невозможно таким образом сравнить.

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

Используя данную методологию, которая применяется при оценке качества ПО: на каждом этапе жизненного цикла программное изделии сталкивается с проблемой слабой формализованности программного продукта его индивидуальности, слабая формализованность ПО, что в результате привело к отсутствию единой системы качества оценки ПО и как следствие отсутствие этой системы привело к низкому качеству большинства программных изделий.

Основные черты хорошего ПО.

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

Основные требования к документации: ясность и полнота описания, удовлетворяющаяся с помощью всякого рода руководств, в том числе ГОСТ-ов.

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

3) Надежность, которая является одной из основополагающих характеристик программного изделия.

Особое значение программное изделие приобретает тогда, когда оно функционирует в реальном масштабе времени.

С этой характеристикой связаны практически все циклы разработки.

4) Эффективность можно рассматривать как интегральную характеристику ПО

5) Специфицируемость –это интегральная характеристика качества ПО, которая включает в себя ряд компонент:

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

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

Проверяемость всех файлов показателями, требованиями, представленными в спецификации.

в) Осуществление требований на регламентированных технических средствах. (ЭВМ).

г) Понятность назначения ПО каждому специалисту, использующему это ПО.

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

е) Мобильность или переносимость характеризуется степенью необходимых изменений или дополнений, а в отдельных случаях и изменений данного ПО на новые технические средства (ЭВМ).

ж) Совместимость – это возможность использования ПО совместно с другим программным изделием, как составную часть общего программного изделия.

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

и) Стоимость, которая является интегральной характеристикой качества программного изделия. Чем выше качество, тем дороже ПО.

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

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

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

Следует выделить два основных показателя качества:

Сложность из-за практической значимости;

Сложность из-за своей каррелированности разного рода характеристик качества.

Дата добавления: 2015-07-02