Прежде всего определимся с некоторыми понятиями, связанными с отладкой программного обеспечения.
Программная ошибка — это расхождение между программой и ее спецификацией, причем тогда и только тогда, когда спецификация существует и она правильна. Также можно определить, что программная ошибка — это ситуация, когда программа не делает того, что пользователь от нее вполне обоснованно ожидает.
Отладкой называют процесс локализации и исправления ошибок, обнаруженных при тестировании программного обеспечения.
Локализация — это определение оператора/операторов программы, выполнение которого вызвало нарушение вычислительного процесса.
Для исправления ошибки необходимо определить ее причину, т.е. определить оператор или фрагмент, содержащие ошибку. Причины ошибок могут быть и очевидными, и очень глубоко скрытыми.
Психосоматика — 2. Стресс: как сбросить опасные эмоции и избавиться от обиды.
Рис. 5.1. Группы программных ошибок
Ошибки компиляции — это синтаксические ошибки, фиксируемые компилятором (транслятором, интерпретатором). Ошибки компиляции являются самыми простыми, так как синтаксис языка, как правило, строго формализован, и ошибки сопровождаются подробным комментарием с указанием местоположения ошибки. Чем лучше формализованы правила синтаксиса языка, тем больше ошибок из общего количества может обнаружить компилятор и, соответственно, меньше ошибок возникнет на следующих этапах.
Ошибки компоновки — ошибки, обнаруженные компоновщиком (редактором связей) при объединении модулей программы. Ошибки компоновки связаны с проблемами, обнаруженными при разрешении внешних ссылок. Например, предусмотрено обращение к подпрограмме другого модуля, а при объединении модулей данная подпрограмма не найдена или не стыкуются списки параметров.
Ошибки выполнения — ошибки, обнаруженные операционной системой, аппаратными средствами или пользователем при выполнении программы. Ошибки выполнения являются самыми непредсказуемыми. Некоторые из них обнаруживаются и документируются операционной системой. Они могут иметь разную природу и поэтому по-разному проявляться:
- • появление сообщения об ошибке, например, деление на ноль, нарушение адресации, переполнение разрядов и т.п.;
- • появление сообщения об ошибке, обнаруженной операционной системой, например при попытке записи на защищенные устройства памяти, при ссылке на отсутствующий файл и т.п.;
- • «зависание» компьютера (иногда для продолжения работы необходима его перезагрузка);
- • несовпадение полученных результатов с ожидаемыми.
Причины ошибок выполнения очень разнообразны, а потому их
сложно локализовать. Все возможные причины ошибок выполнения можно разделить на следующие группы:
- • ошибки определения данных;
- • логические ошибки;
- • ошибки накопления погрешностей.
Ошибки определения данных (неверное определение исходных данных) возникают при выполнении операций ввода-вывода: ошибки передачи, ошибки преобразования, ошибки перезаписи, ошибки данных. Использование специальных технических средств и программирование с защитой от ошибок позволяют обнаружить и предотвратить только часть этих ошибок.
Катя Гордон: скандал-это профессия. Дело Чайки, алименты Тарасова, Собчак, Эрнст и понятийная Россия
Логические ошибки имеют разную природу и могут следовать из ошибок, допущенных при проектировании, например при выборе методов, разработке алгоритмов или определении структуры данных (классов), а могут быть непосредственно внесены при кодировании модуля. К ошибкам кодирования относятся:
- • ошибки некорректного использования переменных, например неудачный выбор типов данных, использование переменных до их инициализации, использование индексов, выходящих за границы определения массивов, нарушения соответствия типов данных и т.п.;
- • ошибки вычислений, например некорректная работа с переменными, некорректное преобразование типов данных в процессе вычислений и т.п.;
• ошибки взаимодействия модулей, т.е. межмодульного интерфейса, например нарушение типов и последовательности при передаче параметров, несоблюдение единства единиц измерения формальных и фактических параметров, нарушение области действия локальных и глобальных переменных.
Возможны и другие ошибки кодирования, например неправильная реализация логики программы при кодировании, игнорирование особенностей или ограничений конкретного языка программирования.
Ошибки накопления погрешностей возникают в результате накопления погрешностей результатов числовых вычислений, например при некорректном отбрасывании дробных цифр чисел, при некорректном использовании приближенных методов вычислений и т.п.
Процесс отладки требует от разработчика глубоких знаний специфики среды и языка программирования, используемых технических средств, операционной системы. На сложность отладки оказывают влияние следующие факторы:
- • опосредованное проявление ошибок;
- • возможность взаимного влияния ошибок;
- • возможность получения внешне одинаковых проявлений разных ошибок;
- • стохастические ошибки, которые могут не проявиться от запуска к запуску;
- • может аннулироваться или измениться внешнее проявление ошибок при внесении некоторых изменений в программу, например, при включении в программу диагностических фрагментов. Отладка программы всегда предполагает обдумывание и логическое осмысление всей имеющейся информации об ошибке. Большинство ошибок можно обнаружить, тщательно анализируя текст программы и результаты тестирования.
- • метод ручного тестирования;
- • метод индукции;
- • метод дедукции;
- • метод обратного прослеживания.
Метод ручного тестирования — самый простой и естественный способ отладки программы. При обнаружении ошибки необходимо выполнить тестируемую программу вручную, используя тестовый набор, при работе с которыми была обнаружена ошибка. Метод эффективен, но не применим для больших программных систем и программ со сложными вычислениями. Этот метод часто используют как составную часть других методов отладки.
Метод индукции предусматривает подробный анализ проявления ошибки. Это могут быть неверные результаты вычислений или сообщение об ошибке. Если компьютер просто «зависает», то место проявления ошибки в программном обеспечении определяют исходя из последних полученных результатов и действий пользователя.
Полученную таким образом информацию можно изучить, просматривая соответствующий фрагмент программы. В результате выдвигаются гипотезы об ошибках, которые затем проверяются. Если гипотеза верна, то детализируют информацию об ошибке, иначе — выдвигают другую гипотезу. Если в результате изучения данных никаких гипотез не появляется, то необходима дополнительная информация об ошибке.
Метод дедукции работает по следующему алгоритму. Сначала формируют множество причин, которые могли бы вызвать данное проявление ошибки. Затем, анализируя причины, исключают те, которые противоречат имеющимся данным. Если все причины исключены, то необходима дополнительная информация об ошибке и следует выполнить дополнительное тестирование исследуемого фрагмента.
В противном случае наиболее вероятную гипотезу пытаются доказать. Если гипотеза объясняет полученные признаки ошибки, то ошибка найдена, иначе — проверяют следующую причину.
Метод обратного прослеживания используется для небольших программ и заключается в следующем. Определяется точка вывода неправильного результата. Затем строится гипотеза о значениях основных переменных, которые могли бы привести к получению этого результата. Исходя из этой гипотезы, делают предположения о значениях переменных в предыдущей точке. Процесс продолжают, пока не обнаружат причину ошибки.
Рассмотрим категории программных ошибок, которые встречаются наиболее часто.
Функциональные недостатки. Данные недостатки присущи программе, если она не делает того, что должна, выполняет одну из своих функций плохо или не полностью. Функции программы должны быть подробно описаны в ее спецификации, и именно на основе утвержденной спецификации тестировщик строит свою работу.
Недостатки пользовательского интерфейса. Лучше всего оценить удобство и правильность работы пользовательского интерфейса может только пользователь в процессе работы с ним. Проверить это возможно с помощью прототипа программного обеспечения, на котором проводятся обкатка и согласование всех требований к пользовательскому интерфейсу с дальнейшей фиксацией их в спецификации требований. После утверждения спецификации требований любые отклонения от нее или невыполнение последних являются ошибкой. Это в полной мере касается и пользовательского интерфейса.
Недостаточная производительность. При разработке некоторого программного продукта очень важной его характеристикой может оказаться скорость работы, иногда этот критерий задается в требованиях заказчика к программному обеспечению. Недопустимо, если программа не удовлетворяет заданным в спецификации требований характеристикам. Это уже ошибка, которая должна быть обязательно устранена.
Некорректная обработка ошибок. Правильно определив ошибку, программа должна выдать о ней сообщение. Отсутствие такого сообщения является ошибкой в работе программы.
Некорректная обработка граничных условий. Существует много различных граничных ситуаций. Любой аспект работы программы, к которому применимы понятия «больше» или «меньше», «раньше» или «позже», «первый» или «последний», «короче» или «длиннее», обязательно должен быть проверен на границах диапазона. Внутри диапазонов программа может работать правильно, а на их границах могут происходить неожиданные ситуации, которые, в свою очередь, приводят к ошибкам в работе программного обеспечения.
Ошибки вычислений. К ошибкам вычислений относятся ошибки, вызванные неправильным выбором алгоритма вычислений, неправильными формулами либо формулами, неприменимыми к обрабатываемым данным. Самыми распространенными среди ошибок вычислений являются ошибки округления.
Ошибки управления потоком. По логике работы программы вслед за первым действием должно быть выполнено второе. Если вместо этого выполняется третье или четвертое действие, значит, в управлении потоком допущена ошибка.
Ситуация гонок. Предположим, в системе ожидаются два события: А и Б. Если первым наступит событие А, то выполнение программы продолжится, а если событие Б, то в работе программы произойдет сбой. Разработчики предполагают, что первым всегда должно быть событие А, и не ожидают, что Б может выиграть гонки и наступить раньше. Такова классическая ситуация гонок.
Тестировать ситуации гонок довольно сложно. Наиболее типичны они для систем, где параллельно выполняются взаимодействующие процессы и потоки, а также для многопользовательских систем реального времени. Ошибки в таких системах трудно воспроизвести, и на их выявление обычно требуется очень много времени.
Перегрузки. Сбои в работе программы могут происходить из-за нехватки памяти или отсутствия других необходимых системных ресурсов. У каждой программы свои пределы, программа может не справляться с повышенными нагрузками, например со слишком большими объемами данных. Вопрос в том, соответствуют ли реальные возможности программы, ее требования к ресурсам спецификации программы, и как она себя поведет при перегрузках.
Некорректная работа с аппаратурой компьютера. Программы могут отправлять аппаратным устройствам неверные данные, игнорировать их сообщения об ошибках, пытаться использовать устройства, которые заняты или вообще отсутствуют. Даже если нужное устройство просто неисправно, программа должна понять это, а не «зависать» при попытке к нему обратиться.
Методы и способы идентификации сбоев и ошибок
.
Международный стандарт ANSI/IEEE-729-83
разделяет все ошибки в разработке программ на
следующие типы.
• Ошибка (error) — состояние программы, при
котором выдаются неправильные результаты,
причиной которых являются изъяны (flaw) в
операторах программы или в технологическом
процессе ее разработки, что приводит к
неправильной
интерпретации
исходной
информации, следовательно, и к неверному
решению.
.
• Дефект (fault) в программе — следствие ошибок
разработчика на любом из этапов разработки,
которая может содержаться в исходных или
проектных
спецификациях,
текстах
кодов
программ, эксплуатационной документация и т.п. В
процессе выполнения программы может быть
обнаружен дефект или сбой.
• Отказ (failure) — это отклонение программы от
функционирования или невозможность программы
выполнять функции, определенные требованиями и
ограничениями, что рассматривается как событие,
способствующее
переходу
программы
в
неработоспособное состояние из-за ошибок,
скрытых в ней дефектов или сбоев в среде
функционирования.
.
Отказ может быть результатом следующих причин:
• ошибочная спецификация или пропущенное требование,
означающее, что спецификация точно не отражает того,
что предполагал пользователь;
• спецификация может содержать требование, которое
невозможно выполнить на данной аппаратуре и
программном обеспечении;
• проект программы может содержать ошибки (например,
база данных спроектирована без средств защиты от
несанкционированного доступа пользователя, а требуется
защита);
• программа может быть неправильной, т.е. она выполняет
несвойственный алгоритм или он реализован не
полностью.
Таким образом, отказы, как правило, являются результатами
одной или более ошибок в программе, а также наличия
разного рода дефектов.
Ошибки на этапах процесса тестирования.
Приведенные типы ошибок распределяются по этапам ЖЦ
и им соответствуют такие источники их возникновения:
• непреднамеренное отклонение разработчиков от
рабочих стандартов или планов реализации;
• спецификации функциональных и интерфейсных
требований выполнены без соблюдения стандартов
разработки, что приводит к нарушению
функционирования программ;
• организации процесса разработки — несовершенная или
недостаточное управление руководителем проекта
ресурсами (человеческими, техническими,
программными и т.д.) и вопросами тестирования и
интеграции элементов проекта.
Рассмотрим процесс тестирования, исходя из рекомендаций стандарта ISO/IEC 12207, и приведем типы ошибок, которые обнаруживаются
на каждом процессе ЖЦ.
Процесс разработки требований. При определении исходной
концепции системы и исходных требований к системе возникают
ошибки аналитиков при спецификации верхнего уровня системы и
построении концептуальной модели предметной области.
Характерными ошибками этого процесса являются:
• неадекватность
спецификации
требований
конечным
пользователям;
некорректность
спецификации
взаимодействия ПО со средой функционирования или с
пользователями;
• несоответствие требований заказчика к отдельным и общим
свойствам ПО;
• некорректность описания функциональных характеристик;
• необеспеченность инструментальными средствами всех
аспектов реализации требований заказчика и др.
Процесс проектирования
• Ошибки при проектировании компонентов
могут возникать при описании алгоритмов,
логики управления, структур данных,
интерфейсов, логики моделирования
потоков данных, форматов ввода-вывода и
др. В основе этих ошибок лежат дефекты
спецификаций аналитиков и недоработки
проектировщиков.
.
К ним относятся ошибки, связанные:
• с определением интерфейса пользователя со средой;
• с описанием функций (неадекватность целей и задач
компонентов, которые обнаруживаются при проверке
комплекса компонентов);
• с определением процесса обработки информации и
взаимодействия
между
процессами
(результат
некорректного определения взаимосвязей компонентов
и процессов);
• с некорректным заданием данных и их структур при
описании отдельных компонентов и ПС в целом;
• с некорректным описанием алгоритмов модулей;
• с определением условий возникновения возможных
ошибок в программе;
• с нарушением принятых для проекта стандартов и
технологий.
Этап кодирования
• На данном этапе возникают ошибки, которые являются
результатом
дефектов
проектирования,
ошибок
программистов и менеджеров в процессе разработки и
отладки системы. Причиной ошибок являются:
• бесконтрольность значений входных параметров, индексов
массивов, параметров циклов, выходных результатов,
деления на 0 и др.;
• неправильная обработка нерегулярных ситуаций при анализе
кодов возврата от вызываемых подпрограмм, функций и др.;
• нарушение стандартов кодирования (плохие комментарии,
нерациональное выделение модулей и компонент и др.);
• использование одного имени для обозначения разных
объектов или разных имен одного объекта, плохая
мнемоника имен;- несогласованное внесение изменений в
программу разными разработчиками и др.
Процесс тестирования.
• На этом процессе ошибки допускаются
программистами и тестировщиками при
выполнении
технологии
сборки
и
тестирования, выбора тестовых наборов и
сценариев тестирования и др. Отказы в
программном обеспечении, вызванные такого
рода
ошибками,
должны
выявляться,
устраняться и не отражаться на статистике
ошибок
компонент
и
программного
обеспечения в целом.
Процесс сопровождения.
На процессе сопровождения обнаруживаются
ошибки,
причиной
которых
являются
недоработки и дефекты эксплуатационной
документации,
недостаточные
показатели
модифицируемости и удобочитаемости, а также
некомпетентность лиц, ответственных за
сопровождение и/или усовершенствование ПО.
В зависимости от сущности вносимых изменений
на этом этапе могут возникать практически
любые
ошибки,
аналогичные
ранее
перечисленным ошибкам на предыдущих
этапах.
Тестирования программ и систем
Тестирования программ и систем — это способ семантической проверки программы, который заключается в обработке программой последовательности разнообразных контрольных наборов тестов с известными результатами. Тесты подбираются так, чтобы они охватили самые разнообразные типы возможных ситуаций.
Основные виды работ по тестированию:
o верификация результатов разработки программного продукта на каждом этапе жизненного цикла;
o составление плана тестирования и подготовки тестов для проверки отдельных элементов разработанной программы и программы в целом;
o управление выполнением тестов и анализ результатов тестирования;
o повторное тестирование.
Тестирование — оценка качества методом экспериментальной проверки — путем выполнения тестов. Цель тестирования — выявить наличие ошибок и несогласованностей. Другими словами, это нахождение ошибок (локализация — задача диагностики), достижения отсутствии ошибок (отладка).
Конечной целью тестирования промышленных ИТ-проектов является получение сертификата на разработанный программный продукт.
Тестирование составляет от ЗО до 50 % трудоемкости работ по созданию кода.
Исторически первым разновидностью тестирования было отладка — проверка программного объекта на наличие в нем ошибок для их устранения. При этом могут вноситься новые ошибки.
Методы тестирования и верификации целиком зависят от методов проектирования и стадий, из которых начинается проверка правильности функционирования результатов проектирования.
Статические методы используются во время проведения инспекций и анализа спецификаций компонентов без их выполнения, а динамические применяются в процессе выполнения программ.
Тесты, основанные на внешних спецификациях программного обеспечения, применяемые на этапе комплексного тестирования для определения полноты решения функциональных задач и их соответствия исходным требованиям.
Функциональному тестированию предшествует анализ функций, в задачи которого входят:
o идентификация множества функциональных требований;
o идентификация внешних функций в реализации программного обеспечения и построение последовательностей функций соответственно использование их в ПО;
o идентификация множества входных данных каждой функции и определение направлений их изменения;
o построение тестовых наборов и сценариев тестирования функций;
o выявление и представление всех функциональных требований с помощью тестовых наборов и проведения тестирования ошибок в программе и взаимодействия со средой.
Основная цель тестирования — обеспечение полноты и согласованности реализованных в программных компонентах функций и интерфейсов между ними.
Методы доказательства правильности программ появились еще в 80-е годы. Техника символьного выполнения включает моделирование выполнения кода, используя символы вместо переменных данных.
Проверка — проверка соответствия реализации системы спецификациям результатов проектирования и описания компоненты,
Проверка — проверка соответствия созданного ПО потребностям и требованиям заказчика. Это дорогостоящий процесс, что обеспечивает высокое качество программного кода. Валидация позволяет подтвердить, что программное обеспечение является корректной реализацией исходных условий в системе и производится после завершения каждого этапа разработки этого обеспечения.
Ошибки и причины их появления на этапах жизненного цикла
Ошибка — это состояние программы, при котором генерируются неверные результаты. Причиной ошибок являются недостатки в операторах программы или в технологическом процессе ее разработки, что приводит к неправильному преобразования входной информации в выходную. Дефект в программе возникает вследствие ошибок разработчика. Он может содержаться во входных или проектных спецификациях, текстах кодов программ, в эксплуатационной документации. Отказ — это невозможность выполнять функции, определенные требованиями и ограничениями. Она возникает вследствие следующих причин:
o ошибочной спецификации или пропущенной требования (спецификация точно не отражает предположение пользователя);
o наличие требования, которую невозможно выполнить на этой аппаратуре и ПО;
o ошибки в проекте программы (к примеру, базу данных спроектировано без защиты от несанкционированного доступа пользователя, а защита нужна);
o ошибки в алгоритме.
Ошибки в ПО можно классифицировать в соответствии с их распределением по этапам жизненного цикла и источников их возникновения:
1) непреднамеренное отклонение от разработчиков рабочих стандартов или планов реализации;
2) спецификации функциональных и интерфейсных требований без соблюдения стандартов разработки;
3) несовершенная организация процесса разработки.
Ошибки могут возникать во время разработки программного обеспечения на различных этапах жизненного цикла. Рассмотрим подробнее эти этапы.
1. Этап анализа требований. В определении входного концепции системы и описания входных требований заказчика возникают ошибки аналитиков, когда они формулируют спецификации верхнего уровня и строят концептуальную модель ПрО.
o неадекватность описания спецификациям требований конечных пользователей;
o некорректность спецификации взаимодействия программного обеспечения со средой функционирования или с пользователями;
o несоответствие требований заказчика отдельным и общим свойствам программного обеспечения;
o некорректность описания функциональных характеристик;
o необеспеченность инструментальными средствами поддержки всех аспектов реализации требований заказчика и т.д.
2. Этап проектирования компонент. Ошибки во время проектирования компонент могут возникать при описании алгоритмов, логики управления, структур данных, интерфейсов, логики моделирование потоков данных, форматов ввода-вывода и т.д. В основе этих ошибок лежат дефекты спецификаций аналитиков и ошибок проектировщиков.
Ошибки могут возникать при:
o определение интерфейса пользователя со средой;
o описания функций (неадекватности формулировок в проекте цели и задач отдельных компонентов, выявляемых при проверке проекта);
o определение процесса обработки информации или связей между процессами (следствие некорректного определения взаимосвязей компонентов и процессов);
o определение данных и их структур для отдельных компонент и программного обеспечения, что в целом некорректно заданы;
o описания алгоритмов модулей и их логики, что некорректно определены в представленном проекте модуля;
o определение условий возникновения возможных ошибок в программе;
o нарушение принятых для проекта стандартов и технологий.
3. Этап кодирования и отладки. На этом этапе возникают ошибки, что является результатом дефектов проектирования, ошибок программистов и менеджеров процесса разработки и отладки.
o бесконтрольность допустимости значений входных и выходных параметров, деление на 0 и т.п.;
o неправильная обработка нетипичных ситуаций во время анализа кодов возврата от подпрограмм;
o использование одного имени для обозначения нескольких объектов или нескольких имен для обозначения одного объекта;
o несогласованное внесение изменений в программу несколькими разработчиками.
4. Этап тестирования. На этом этапе ошибки допускают тестировщики, а также программисты, осуществляя сбор, тестирование и выбор некорректных тестовых наборов и сценариев тестирования и т.п.
5. Этап сопровождения. При сопровождении программного обеспечения причиной ошибок являются дефекты эксплуатационной документации, слабые показатели модифицируемости и понятности программного обеспечения, а также некомпетентность лиц, ответственных за сопровождение и/а потому усовершенствования программного обеспечения. В зависимости от сущности внесенных изменений на этом этапе могут возникать практически любые ошибки, аналогичные ранее перечисленным.
Ошибки, возникающие в программах, бывают: логические и функциональные, вычислений, ввода-вывода и манипулирования данными, интерфейсов и т.д.
Тест — это совокупность входных данных и/или действий пользователя с указанием ожидаемых результатов или соответствующих реакций программы, которая предназначена для проверки работоспособности программы и выявления в ней ошибочных ситуаций.
Тестовую проверку можно провести также путем добавления к программе, проверяется, дополнительных операторов, которые будут сигнализировать о ходе ее выполнения и получения результатов.
Тестовые данные, предназначены для проверки работы системы, создаются по-разному: генератором тестовых данных, проектной группой на основе документов или файлов, пользователем из спецификации требований и т.д. Очень часто разрабатываются специальные формы входных документов, в которых отражается процесс выполнения программы с помощью тестовых данных.
Виды тестирования программ с целью проверки:
o полноты функций;
o согласованности интерфейсов;
o структуры программы;
o исчисления и корректности выполнения функций;
o правильности функционирования в заданных условиях;
o надежности выполнения программ;
o эффективности защиты от сбоев аппаратуры и необнаруженных ошибок;
o удобства применения и сопровождения.
Команда тестировщиков
Для проведения тестирования создается специальная команда тестировщиков. За функциональные тесты отвечает разработчик, а заказчик больше влияет на составление испытательных и установочных тестов.
Как правило, команда тестировщиков не зависит от штата разработчиков ИС. Некоторые члены этой команды являются опытными тестировщиками или даже профессионалами. Это аналитики, программисты, инженеры-тестировщики, которые посвящают все свое время проблемам тестирования систем. Они имеют дело не только со спецификациями, но и с методами и средствами тестирования, организуют создание и выполнение тестов на машине. Тестировщиков включают в процесс разработок с начала создания проекта для составления тестовых наборов и сценариев, а также графиков выполнения тестов.
Тесты и тестовые сценарии является прямым отражением требований и проекта в целом. Ошибки, которые еще случаются в программе, и изменения в системе отражаются в документации, требованиях, проекте, а также в описаниях входных и выходных данных. Изменения, внесенные в процессе разработок, приводящих к модификации тестовых сценариев или изменения планов тестирования. Специалисты по управлению конфигурацией учитывают эти изменения и координируют составления тестов.
В состав команды тестировщиков входят также пользователи. Они оценивают полученные результаты и удобство использования, а также высказывают свое мнение относительно принципа работы системы на начальных этапах проекта.
Представители заказчика планируют работы для тех, кто будет использовать и сопровождать систему. При этом они могут привнести некоторые изменения в проект, вызванные неполнотой заданных ранее требований, и сформулировать системные требования для проведения верификации системы и принятия решения о ее готовности и полезность.
Сопровождение ИС — это работы по внесению изменений в ИС после того, как был передан пользователю для эксплуатации. В отличие от оборудования, которое со временем требует ремонта, НО не «стареет», поэтому процесс сопровождения нацелен на поддержку прежде всего эволюционирования системы, то есть на изменение ее функций и свойств.
Типичные причины, которые могут обусловить необходимость изменений:
o выявление дефектов функционирования ИС при эксплуатации, не найденных на этапе тестирования (изменения, за которые несет ответственность разработчик);
o выяснения заказчиком во время эксплуатации ИС, требования к системе были выражены недостаточно или неполно, и поэтому она не соответствует отдельным требованиям заказчика (изменения, за которые несет ответственность постановщик задачи);
o изменение условий деятельности заказчика, которые не соответствуют ранее поставленным требованиям (к примеру, изменились налоговое законодательство или местная регуляция правил бизнеса, способы коммуникации заказчика с бизнес-партнерами или произошло перераспределение их роли в бизнесе и т.п.).
Как свидетельствуют эксперты, процесс внесения изменений достаточно дорогой — оценки его стоимости достигают 60-80 % от общей стоимости разработки.
o корректирующую — внесение корректив для устранения ошибок, которые были найдены после передачи системы в эксплуатацию;
o адаптивное — адаптация продукта к изменившимся обстоятельствам использования после передачи системы в эксплуатацию;
o предупредительное — деятельность по обеспечению адаптивного сопровождения на старте разработок.
Блок 3. Категории программных ошибок
Тестирование программного обеспечения- проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом.
Тестировщик — специалист, занимающийся тестированием, он моделирует различные ситуации, которые могут возникнуть в процессе использования программы (чтобы разработчики смогли исправить обнаруженные ошибки).
Цель тестирования — это нахождение ошибок в программе до того, как их найдут пользователи.
Цель тестировщика — найти как можно больше ошибок, и чем серьезнее найденные проблемы, тем лучше. В конечном счете большинство ошибок исправляют, и качество программы улучшается.
Блок 2. Как определить качество ПО (стандарты ISO, критерии качества, метрики)
Понятие «качество ПО» имеет множество трактовок. И тестировщик, и программист дадут свое толкование этого термина.
Если вкратце, то качество программы определяется следующим:
• возможностями, благодаря которым она понравится пользователю;
• недостатками, которые вынуждают пользователя приобрести другую программу.
Вне зависимости от определения, качество, как и его отсутствие, зависит от деятельности всех участников процесса разработки ПО и отлаженности и настройки самого процесса.
Характеристики качества ПО
Наиболее распространенная модель описания качества ПО представлена в серии стандартов ISO 9126 Многоуровневая Модель Качества программного обеспечения.
Она описывает внутреннее и внешнее качество программного обеспечения по следующим шести критериям:
1. Функциональность (Functionality) — что ПО должно делать;
2. Надежность (Reliability) — насколько оно должно быть надежно;
3. Удобство использования (Usability) — насколько им должно быть удобно пользоваться;
4. Эффективность (Efficiency) — насколько оно должно быть эффективно;
5. Удобство сопровождения (Maintainability) — насколько удобно должно быть его сопровождение;
6. Портативность (Portability) — насколько оно должно быть переносимо и заменяемо.
Наряду с атрибутами качества, стандарт ISO 9126 определяет наборы метрик для оценки (получения численного значения) каждого атрибута:
1. Полнота реализации функций;
2. Корректность реализации функций;
3. Отношение числа обнаруженных дефектов к прогнозируемому;
4. Отношение числа проведенных тестов к общему их числу;
5. Отношение числа доступных проектных документов к указанному в их списке;
6. Наглядность и полнота документации.
Как контролировать качество системы?
Как точно узнать, что программа делает именно то, что нужно, и ничего другого? Как определить, что она достаточно надежна, переносима, удобна в использовании? Ответы на этот вопрос можно получить с помощью процессов верификацииивалидации.
Блок 3. Категории программных ошибок
Не существует ни абсолютного определения ошибок, ни точного критерия наличия их в программе. Можно лишь сказать, насколько программа не справляется со своей задачей — это исключительно субъективная характеристика.
Программная ошибка (в простонародье, баг – «bug») — изъян в разработке программы, который вызывает несоответствие ожидаемых результатов выполнения программы и фактически полученных результатов.
Коварные баги имеют свою категорийность, охватывающую все возможные варианты:
Ошибки пользовательского интерфейса
2. Взаимодействие программы с пользователем
3. Организация программы
4. Пропущенные команды
6. Выходные данные
Процедуры обработки ошибок — это очень важная часть программы. В них тоже часто встречаются ошибки. Кроме того, правильно определив ошибку, программа не всегда выдает о ней достаточно информативное сообщение.
Ошибки, связанные с обработкой граничных условий
Простейшими граничными условиями являются числовые. Но существует и много других граничных ситуаций. Любой аспект работы программы, к которому применимы понятия больше или меньше, раньше или позже, первый или последний, короче или длиннее, обязательно должен быть проверен на границах диапазона. Внутри диапазонов программа обычно работает прекрасно, а вот на их границах порой случаются самые неожиданные отклонения.
Даже самые простые арифметические операции всегда чреваты ошибками. Одними из самых распространенных среди математических ошибок являются ошибки округления. После нескольких промежуточных вычислений может оказаться, что 2 + 2 = -1, даже если на промежуточных этапах не было логических ошибок.
Начальное и последующие состояния
Бывает, что при выполнении какой-либо функции программы сбой происходит только однажды — при самом первом обращении к этой функции. Такую ошибку невозможно повторить (точнее, для ее повторения нужно установить новую копию программы). Но не стоит думать, что ошибка, проявляющаяся только при первом запуске программы, безвредна: ведь это будет первое, с чем столкнется каждый новый пользователь.
Ошибки управления потоком
Если по логике программы вслед за первым действием должно быть выполнено второе, а она выполняет третье, значит, в управлении потоком допущена ошибка. Такие ошибки трудно пропустить:
в худшем случае в работе программы произойдет сбой, а при менее серьезной ошибке она просто «забредет не туда».
Ошибки передачи или интерпретации данных
Один модуль может передавать данные другому или даже другой про грамме. Некоторые данные могут передаваться между модулями множество раз, и на каком-то этапе они могут быть разрушены или неверно интерпретированы. Изменения, внесенные одной из частей программы, могут потеряться или достичь не всех частей системы, где они важны.
Описывается так: предположим, в системе ожидаются два события, А и Б. Первым может произойти любое из них. Но если первым произойдет событие А, выполнение программы продолжится, а если первым наступит событие Б, то в работе программы произойдет сбой. Программист полагал, что первым всегда должно быть событие А, и не ожидал, что Б может выиграть гонки.
Программа может не справляться с повышенными нагрузками. Например, она может не выдерживать интенсивной и длительной эксплуатации или не справляться со слишком большими объемами данных.
Программы могут посылать устройствам неверные данные, игнорировать их сообщения об ошибках, пытаться использовать устройства, которые заняты или вообще отсутствуют. Даже если нужное устройство просто сломано, программа должна понять это, а не сбоить при попытке к нему обратиться.
Бывает, что старые ошибки вдруг всплывают снова из-за того, что программа скомпонована с устаревшей версией одной из подпрограмм. Поэтому версии всех составляющих проекта обязательно должны централизованно контролироваться.
Документация считается частью программного продукта. И если она плохо написана, пользователь может подумать, что и сама программа требует значительных доработок.
Если программист допускает по полторы ошибки на каждую строку программного кода, то сколько их допускает тестировщик на каждый тест? Обнаружение ошибок, допущенных тестировщиками, — дело обычное. Конечно, если таких ошибок будет слишком много, вы быстро потеряете доверие остальных членов команды. Но нужно иметь в виду, что иногда ошибки тестировщика отражают проблемы пользовательского интерфейса: если программа заставляет пользователя делать ошибки, значит, с ней что- то не так. Конечно, многие ошибки тестирования вызваны просто неверными тестовыми данными.
И в заключение – в качестве бонуса на лекции вас ожидает тест для оценки себя как тестировщика 🙂
Цель функционального тестирования — обнаружение несоответствий между реальным поведением реализованных функций и ожидаемым поведением в соответствии со спецификацией и исходными требованиями. Функциональные тесты должны охватывать все реализованные функции с учетом наиболее вероятных типов ошибок. Тестовые сценарии, объединяющие отдельные тесты, ориентированы на проверку качества решения функциональных задач.
Функциональные тесты создаются по внешним спецификациям функций, проектной информации и по тексту на ЯП, относятся к функциональным его характеристикам и применяются на этапе комплексного тестирования и испытаний для определения полноты реализации функциональных задач и их соответствия исходным требованиям.
В задачи функционального тестирования входят:
· идентификация множества функциональных требований;
· идентификация внешних функций и построение последовательностей функций в соответствии с их использованием в ПС;- идентификация множества входных данных каждой функции и определение областей их изменения;
· построение тестовых наборов и сценариев тестирования функций;
· выявление и представление всех функциональных требований с помощью тестовых наборов и проведение тестирования ошибок в программе и при взаимодействии со средой.
Тесты, создаваемые по проектной информации, связаны со структурами данных, алгоритмами, интерфейсами между отдельными компонентами и применяются для тестирования компонентов и их интерфейсов. Основная цель — обеспечение полноты и согласованности реализованных функций и интерфейсов между ними.
Комбинированный метод «черного ящика» и «прозрачного ящика» основан на разбиении входной области функции на подобласти обнаружения ошибок. Подобласть содержит однородные элементы, которые все обрабатываются корректно либо некорректно. Для тестирования подобласти производится выполнение программы на одном из элементов этой области.
Предпосылки функционального тестирования:
· корректное оформление требований и ограничений к качеству ПО;
· корректное описание модели функционирования ПО в среде эксплуатации у заказчика;
· адекватность модели ПО заданному классу.
Под инфраструктурой процесса тестирования понимается:
· выделение объектов тестирования;
· проведение классификации ошибок для рассматриваемого класса тестируемых программ;
· подготовка тестов, их выполнение и поиск разного рода ошибок и отказов в компонентах и в системе в целом;
· служба проведения и управление процессом тестирования;
· анализ результатов тестирования.
Объекты тестирования — компоненты, группы компонентов, подсистемы и система. Для каждого из них формируется стратегия проведения тестирования. Если объект тестирования относится к «белому ящику» или «черному ящику», состав компонентов которого неизвестный, то тестирование проводится посредством ввода внего входных тестовых данных для получения выходных данных. Стратегическая цель тестирования состоит в том, чтобы убедиться, что каждый рассматриваемый входной набор данных соответствует ожидаемым выходным выходных данным. При таком подходе к тестированию не требуется знания внутренней структуры и логики объекта тестирования.
Проектировщик тестов должен заглянуть внутрь «черного ящика» и исследовать детали процессов обработки данных, вопросы обеспечения защиты и восстановления данных, а также интерфейсы с другими программами и системами. Это способствует подготовке тестовых данных для проведения тестирования.
Для некоторых типов объектов группа тестирования не может сгенерировать представительное множество тестовых наборов, которые демонстрировали бы функциональную правильность работы компоненты при всех возможных наборах тестов.
Поэтому предпочтительным является метод «белого ящика», при котором можно использовать структуру объекта для организации тестирования по различным ветвям. Например, можно выполнить тестовые наборы, которые проходят через все операторы или все контрольные точки компонента для того, чтобы убедиться в правильности их работы.
Международный стандарт ANSI/IEEE-729-83 разделяет все ошибки в разработке программ на следующие типы.
Ошибка (error) — состояние программы, при котором выдаются неправильные результаты, причиной которых являются изъяны (flaw) в операторах программы или в технологическом процессе ее разработки, что приводит к неправильной интерпретации исходной информации, следовательно, и к неверному решению.
Дефект (fault) в программе — следствие ошибок разработчика на любом из этапов разработки, которая может содержаться в исходных или проектных спецификациях, текстах кодов программ, эксплуатационной документация и т.п. В процессе выполнения программы может быть обнаружен дефект или сбой.
Отказ (failure) — это отклонение программы от функционирования или невозможность программы выполнять функции, определенные требованиями и ограничениями, что рассматривается как событие, способствующее переходу программы в неработоспособное состояние из-за ошибок, скрытых в ней дефектов или сбоев в среде функционирования. Отказ может быть результатом следующих причин:
· ошибочная спецификация или пропущенное требование, означающее, что спецификация точно не отражает того, что предполагал пользователь;
· спецификация может содержать требование, которое невозможно выполнить на данной аппаратуре и программном обеспечении;
· проект программы может содержать ошибки (например, база данных спроектирована без средств защиты от несанкционированного доступа пользователя, а требуется защита);
· программа может быть неправильной, т.е. она выполняет несвойственный алгоритм или он реализован не полностью.
Таким образом, отказы, как правило, являются результатами одной или более ошибок в программе, а также наличия разного рода дефектов.
Ошибки на этапах процесса тестирования. Приведенные типы ошибок распределяются по этапам ЖЦ и им соответствуют такие источники их возникновения:
· непреднамеренное отклонение разработчиков от рабочих стандартов или планов реализации;
· спецификации функциональных и интерфейсных требований выполнены без соблюдения стандартов разработки, что приводит к нарушению функционирования программ;
· организации процесса разработки — несовершенная или недостаточное управление руководителем проекта ресурсами (человеческими, техническими, программными и т.д.) и вопросами тестирования и интеграции элементов проекта.
Рассмотрим процесс тестирования, исходя из рекомендаций стандарта ISO/IEC 12207, и приведем типы ошибок, которые обнаруживаются на каждом процессе ЖЦ.
Процесс разработки требований. При определении исходной концепции системы и исходных требований к системе возникают ошибки аналитиков при спецификации верхнего уровня системы и построении концептуальной модели предметной области.
Характерными ошибками этого процесса являются:
· неадекватность спецификации требований конечным пользователям;- некорректность спецификации взаимодействия ПО со средой функционирования или с пользователями;
· несоответствие требований заказчика к отдельным и общим свойствам ПО;
· некорректность описания функциональных характеристик;
· необеспеченность инструментальными средствами всех аспектов реализации требований заказчика и др.
Процесс проектирования. Ошибки при проектировании компонентов могут возникать при описании алгоритмов, логики управления, структур данных, интерфейсов, логики моделирования потоков данных, форматов ввода-вывода и др. В основе этих ошибок лежат дефекты спецификаций аналитиков и недоработки проектировщиков. К ним относятся ошибки, связанные:
· с определением интерфейса пользователя со средой;
· с описанием функций (неадекватность целей и задач компонентов, которые обнаруживаются при проверке комплекса компонентов);
· с определением процесса обработки информации и взаимодействия между процессами (результат некорректного определения взаимосвязей компонентов и процессов);
· с некорректным заданием данных и их структур при описании отдельных компонентов и ПС в целом;
· с некорректным описанием алгоритмов модулей;
· с определением условий возникновения возможных ошибок в программе;
· с нарушением принятых для проекта стандартов и технологий.
Этап кодирования. На данном этапе возникают ошибки, которые являются результатом дефектов проектирования, ошибок программистов и менеджеров в процессе разработки и отладки системы. Причиной ошибок являются:
· бесконтрольность значений входных параметров, индексов массивов, параметров циклов, выходных результатов, деления на 0 и др.;
· неправильная обработка нерегулярных ситуаций при анализе кодов возврата от вызываемых подпрограмм, функций и др.;
· использование одного имени для обозначения разных объектов или разных имен одного объекта, плохая мнемоника имен;- несогласованное внесение изменений в программу разными разработчиками и др.
Процесс тестирования. На этом процессе ошибки допускаются программистами и тестировщиками при выполнении технологии сборки и тестирования, выбора тестовых наборов и сценариев тестирования и др. Отказы в программном обеспечении, вызванные такого рода ошибками, должны выявляться, устраняться и не отражаться на статистике ошибок компонент и программного обеспечения в целом.
Процесс сопровождения. На процессе сопровождения обнаруживаются ошибки, причиной которых являются недоработки и дефекты эксплуатационной документации, недостаточные показатели модифицируемости и удобочитаемости, а также некомпетентность лиц, ответственных за сопровождение и/или усовершенствование ПО. В зависимости от сущности вносимых изменений на этом этапе могут возникать практически любые ошибки, аналогичные ранее перечисленным ошибкам на предыдущих этапах.
Все ошибки, которые возникают в программах, принято подразделять на следующие классы:
· логические и функциональные ошибки;
· ошибки вычислений и времени выполнения;
· ошибки ввода-вывода и манипулирования данными;
· ошибки интерфейсов;
· ошибки объема данных и др.
Логические ошибки являются причиной нарушения логики алгоритма, внутренней несогласованности переменных и операторов, а также правил программирования. Функциональные ошибки — следствие неправильно определенных функций, нарушения порядка их применения или отсутствия полноты их реализации и т.д.
Ошибки вычислений возникают по причине неточности исходных данных и реализованных формул, погрешностей методов, неправильного применения операций вычислений или операндов. Ошибки времени выполнения связаны с не обеспечением требуемой скорости обработки запросов или времени восстановления программы.
Ошибки ввода-вывода и манипулирования данными являются следствием некачественной подготовки данных для выполнения программы, сбоев при занесении их в базы данных или при выборке из нее.
Ошибки интерфейса относятся к ошибкам взаимосвязи отдельных элементов друг с другом, что проявляется при передаче данных между ними, а также при взаимодействии со средой функционирования.
Ошибки объема относятся к данным и являются следствием того, что реализованные методы доступа и размеры баз данных не удовлетворяют реальным объемам информации системы или интенсивности их обработки.
Приведенные основные классы ошибок свойственны разным типам компонентов ПО и проявляются они в программах по разному. Так, при работе с БД возникают ошибки представления и манипулирования данными, логические ошибки в задании прикладных процедур обработки данных и др. В программах вычислительного характера преобладают ошибки вычислений, а в программах управления и обработки — логические и функциональные ошибки. В ПО, которое состоит из множества разноплановых программ, реализующих разные функции, могут содержаться ошибки разных типов. Ошибки интерфейсов и нарушение объема характерны для любого типа систем.
Анализ типов ошибок в программах является необходимым условием создания планов тестирования и методов тестирования для обеспечения правильности ПО.
На современном этапе развития средств поддержки разработки ПО (CASE-технологии, объектно-ориентированные методы и средства проектирования моделей и программ) проводится такое проектирование, при котором ПО защищается от наиболее типичных ошибок и тем самым предотвращается появление программных дефектов.
Связь ошибки с отказом. Наличие ошибки в программе, как правило, приводит к отказу ПО при его функционировании. Для анализа причинно-следственных связей «ошибка отказ» выполняются следующие действия:
· идентификация изъянов в технологиях проектирования и программирования;
· взаимосвязь изъянов процесса проектирования и допускаемых человеком ошибок;
· классификация отказов, изъянов и возможных ошибок, а также дефектов на каждом этапе разработки;- сопоставление ошибок человека, допускаемых на определенном процессе разработки, и дефектов в объекте, как следствий ошибок спецификации проекта, моделей программ;
· проверка и защита от ошибок на всех этапах ЖЦ, а также обнаружение дефектов на каждом этапе разработки;
· сопоставление дефектов и отказов в ПО для разработки системы взаимосвязей и методики локализации, сбора и анализа информации об отказах и дефектах;
· разработка подходов к процессам документирования и испытания ПО.
Конечная цель причинно-следственных связей «ошибка отказ» заключается в определении методов и средств тестирования и обнаружения ошибок определенных классов, а также критериев завершения тестирования на множестве наборов данных; в определении путей совершенствования организации процесса разработки, тестирования и сопровождения ПО.
Приведем следующую классификацию типов отказов:
· аппаратный, при котором общесистемное ПО не работоспособно;
· информационный, вызванный ошибками во входных данных и передаче данных по каналам связи, а также при сбое устройств ввода (следствие аппаратных отказов);
· эргономический, вызванный ошибками оператора при его взаимодействии с машиной (этот отказ — вторичный отказ, может привести к информационному или функциональному отказам);
· программный, при наличии ошибок в компонентах и др.
Некоторые ошибки могут быть следствием недоработок при определении требований, проекта, генерации выходного кода или документации. С другой стороны, они порождаются в процессе разработки программы или при разработке интерфейсов отдельных элементов программы (нарушение порядка параметров, меньше или больше параметров и т.п.).
Источники ошибок. Ошибки могут быть порождены в процессе разработки проекта, компонентов, кода и документации. Как правило, они обнаруживаются при выполнении или сопровождении программного обеспечения в самых неожиданных и разных ее точках.
Некоторые ошибки в программе могут быть следствием недоработок при определении требований, проекта, генерации кода или документации. С другой стороны, ошибки порождаются в процессе разработки программы или интерфейсов ее элементов (например, при нарушении порядка задания параметров связи — меньше или больше, чем требуется и т.п.).
Причиной появления ошибок — непонимание требований заказчика; неточная спецификация требований в документах проекта и др. Это приводит к тому, что реализуются некоторые функции системы, которые будут работать не так, как предлагает
заказчик. В связи с этим проводится совместное обсуждение заказчиком и разработчиком некоторых деталей требований для их уточнения.
Команда разработчиков системы может также изменить синтаксис и семантику описания системы. Однако некоторые ошибки могут быть не обнаружены (например, неправильно заданы индексы или значения переменных этих операторов).