Ошибки определение конкретного фрагмента при выполнении которого произошло отклонение

Можно предложить следующую методику отладки программного обеспечения, написанного на универсальных языках программирования для выполнения в операционных системах MS DOS и Win32:

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

Если ошибка не найдена или система просто «зависла», переходят ко второму этапу.

2 этап — локализация ошибки — определение конкретного фрагмента, при выполнении которого произошло отклонение от предполагаемого вычислительного процесса. Локализация может выполняться:

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

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

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

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

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

4 этап — исправление ошибки — внесение соответствующих изменений во все операторы, совместное выполнение которых привело к ошибке.

5 этап — повторное тестирование — повторение всех тестов с начала, так как при исправлении обнаруженных ошибок часто вносят в программу новые.

Следует иметь в виду, что процесс отладки можно существенно упростить, если следовать основным рекомендациям структурного подхода к программированию:

•программу наращивать «сверху-вниз», от интерфейса к обрабатывающим подпрограммам, тестируя ее по ходу добавления подпрограмм;

•выводить пользователю вводимые им данные для контроля и проверять их на допустимость сразу после ввода;

•предусматривать вывод основных данных во всех узловых точках алгоритма (ветвлениях, вызовах подпрограмм).

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

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

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

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

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

2 этап —
локализация ошибки — определение
конкретного фрагмента, при выполнении
которого произошло отклонение от
предполагаемого вычислительного
процесса. Локализация может выполняться:

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

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

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

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

4 этап —
исправление ошибки — внесение
соответствующих изменений во все
операторы, совместное выполнение
которых привело к ошибке.

5 этап —
повторное тестирование — повторение
всех тестов с начала, так как при
исправлении обнаруженных ошибок часто
вносят в программу новые.

Следует иметь в
виду, что процесс отладки можно
существенно упростить, если следовать
основным рекомендациям структурного
подхода к программированию:

• программу
наращивать «сверху-вниз», от интерфейса
к обрабатывающим подпрограммам, тестируя
ее по ходу добавления подпрограмм;

• выводить
пользователю вводимые им данные для
контроля и проверять их на допустимость
сразу после ввода;

• предусматривать
вывод основных данных во всех узловых
точках алгоритма (ветвлениях, вызовах
подпрограмм).

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

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

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

Организация
испытаний комплексов программ.
Используются для программ, создаваемых
на уровне продукции производствен­но-технического
назначения и отчуждаемых от разработчика.
Важная осо­бенность испытаний
программы состоит в наличии достаточно
полных эталонов, которым должен
соответствовать КП, тре­бований
технического задания. Цель испытаний
— определение степени соответствия
созданного комплекса программ
техниче­скому заданию, полученному
от заказчика.

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

При испытаниях
главного конструктора, которые зачастую
совмещаются с завершением комплексной
отладки, производится, по существу,
такое же тестирование, что и на совместных
испытаниях, только в меньшем объеме.
Эти проверки оформляются документально
и являются основанием для предъявления
КП за­казчику на совместные испытания.
Любые испытания ограничены допустимым
объемом проверок и длительностью работы
комиссии, поэтому не могут гарантировать
всестороннюю проверку изделия. Для
повышения достоверности определения
и улучшения харак­теристик КП после
испытаний главного конструктора
программы целесообразно на некоторое
время передавать на опытную эксплу­атацию
в типовых условиях. Это позволяет более
глубоко оце­нить эксплуатационные
характеристики созданного комплек­са
и устранить некоторые ошибки. Опытная
эксплуатация КП проводится разработчиками
с участием испытателей и некоторых
пользователей, назначаемых заказчиком.
Результаты опытной эксплуатации после
испытаний главного конструктора могут
учитываться при совместных испытаниях
для их сокращения.

В жизненном цикле
КП можно выделить следующие виды
испытаний

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

-рабочей версии
КП, адаптированной к условиям конкретного
применения,

-версии
модернизированного КП при сопровождении.

Функциональное
тестирование — наиболее об­ширное
и труднее всего систематизируемое.
Набор испытатель­ных тестов полностью
определяется функциональными задачами
и сложностью КП. Эти тесты должны
обеспечивать проверку и демонстрацию
заказчику или пользователю качества
решения функциональных задач,
сформулированных в техническом зада­нии
и конкретизированных в документации.
Поскольку исчерпывающее тестирование
для сложных КП невозможно, большое
значение имеют уточнение областей
варьирования тестовых дан­ных и
выделение областей их изменения,
наиболее важных для последующего
использования программ

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

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

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

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

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

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

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

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

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

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

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

1. Достоверность
   испытаний: методическая и статистическая
   достоверность; документирование
   результатов испытаний: исходных и
   отчетные документы при испытаниях
   программ – техническое задание,
   государственные и отраслевые стандарты,
   программа испытаний, методики испытаний,
   протоколы испытаний, акт испытаний.

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

Методическая
достоверность испытаний КП оп­ределяется
следующими факторами:

-полнотой программы
испытаний, корректностью методик
те­стирования, степенью охвата
возможных условий функциони­рования
и областей изменения исходных данных
программ;

-достоверностью
и точностью эталонных значений, с
которыми сравниваются результаты
тестирования испытываемой програм­мы
или которые служат опорными при расчете
параметров, зафиксированных в техническом
задании;

-адекватностью и
точностью моделей, используемых для
ими­тации внешней среды и их реакции
на управляющие воздей­ствия;

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

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

Документы:

1. ТЗ

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

1. Государственные
   и отраслевые стандарты

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

-объект испытаний,
его назначение и перечень основных
до­кументов, определивших его
разработку;

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

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

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

Результаты
испытаний фиксируются в протоколах,
которые обычно содержат следующие
разделы:

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

-указание методик,
в соответствии с которыми проводились
испытания, обработка и оценка результатов;

-условия проведения
тестирования и характеристика исходных
данных;

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

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

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

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

1. Виды программной
   документации: проектная и эксплуатационная
   документация. Документирование
   интерактивного ПО. Государственные
   стандарты в области документирования
   ПО. Средства автоматизации документирования.

К программным
относят документы, содержащие сведения,
необходимые для разработки, сопровождения
и эксплуатации программного
обеспечения. Документирование
программного обеспечения осуществляется
в соответствии с Единой системой
программной документации (ГОСТ 19.XXX).
Так ГОСТ 19.101-77 устанавливает виды
программных документов для программного
обеспечения различных типов. Ниже
перечислены основные программные
документы по этому стандарту и указано,
какую информацию они должны содержать.

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

Ведомость
держателей подлинников (код вида
документа — 05) должна содержать список
предприятий, на которых хранятся
подлинники программных документов.
Необходимость этого документа
определяется на этапе разработки и
утверждения технического задания
только для программного обеспечения
со сложной архитектурой.

Текст программы
(код вида документа — 12) должен содержать
текст программы с необходимыми
комментариями. Необходимость этого
документа определяется на этапе
разработки и утверждения технического
задания.

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

Ведомость
эксплуатационных документов
(код вида документа — 20) должна содержать
перечень эксплуатационных документов
на программу, к которым относятся
документы с кодами: 30, 31, 32, 33, 34, 35, 46.
Необходимость этого документа также
определяется на этапе разработки и
утверждения технического задания.

Формуляр
(код вида документа — 30) должен содержать
основные характеристики программного
обеспечения, комплектность и сведения
об эксплуатации программы.

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

Руководство
системного программиста
(код вида документа — 32) должно содержать
сведения для проверки, обеспечения
функционирования и настройки программы
на условия конкретного применения.

Руководство
программиста
(код вида документа — 33) должно содержать
сведения для эксплуатации программного
обеспечения.

Руководство
оператора
(код вида документа — 34) должно содержать
сведения для обеспечения процедуры
общения оператора с вычислительной
системой в процессе выполнения
программного обеспечения.

Описание языка
(код вида документа — 35) должно содержать
описание синтаксиса и семантики языка.

Руководство по
техническому обслуживанию
(код вида документа — 46) должно содержать
сведения для применения тестовых и
диагностических программ при обслуживании
технических средств.

Программа и
методика испытаний
(код вида документа — 51) должны содержать
требования, подлежащие проверке при
испытании программного обеспечения,
а также порядок и методы их контроля.

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

Прочие документы
(коды вида документа — 90-99) могут
составляться на любых стадиях
разработки, т. е. на стадиях эскизного,
технического и рабочего проектов.
Допускается объединять отдельные
виды эксплуатационных документов,
кроме формуляра и ведомости. Необходимость
объединения указывается в техническом
задании, а имя берут у одного из
объединяемых документов.

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

На
этапе планирования разработки ПО
создаются планы и выбираются стандарты,
которые направляют этап разработки и
интегрированный этап. Его

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

1)
определение действий на этапах разработки
и интегрированном этапе, которые будут
посвящены определению системных
требований и уровня ПО;

2)
определение ЖЦ ПО, включая взаимодействие
между этапами, механизм взаимного
влияния этапов, критерии оценки ПО при
переходе от одного этапа к другому;

3)определение
среды ЖЦ, т.е. методы и инструментальные
средства, используемые на каждом этапе;

4)
формирование дополнительных замечаний
к ПО;

5)
рассмотрение стандартов разработки
ПО, соотношение их с системными целями
безопасности, относящиеся к разрабатываемому
ПО;

6)
разработка плана создания ПО;

7)
доработка и проверка плана создания
ПО.

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

-на основе
распределения системного анализа
(алгоритмиза­ции) и разработки программ
по разным коллективам;

-по принципу
выделения коллективов, создающих всю
совокуп­ность программных модулей,
и группы специалистов, объединя­ющих
программы в единый комплекс;

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

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

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

Одним из вариантов
организационной структуры коллектива
при создании крупных КП является
иерархическая структура, базирующаяся
на группах специалистов, каждая из
которых сос­тавляет специализированную,
так называемую «хирургическую бригаду».
Такая бригада решает достаточно
автономную функци­ональную задачу
и должна разработать и отладить группу
взаи­модействующих программ с
достаточно четкой целью функциони­рования.
«Хирургическая бригада» рекомендуется
в составе 7…10 специалистов с различными
задачами и квалификацией. Во главе
бригады стоит «хирург», который
разрабатывает функциональ­ные задачи
программ, составляет алгоритм, пишет
и отлаживает программы, готовит и
проверяет документацию. Он должен
обла­дать значительным системным
опытом, высокой математической и
программистской квалификацией и
талантом разработки и от­ладки сложных
КП. «Второй пилот» является дублером
и может выполнить любую часть работы,
но менее опытен. Он принимает участие
в разработке, обсуждении и оценке
компонент, создаваемых бригадой, в
качестве оппонента или ответчика по
альтернативным решениям, а также несет
ответственность за взаимодей­ствие
с другими бригадами и с разрабатываемыми
ими груп­пами программ.

«Администратор»
позволяет избавить «хирурга» от
множества технических и административных
функций как внутри бригады, так и по
взаимодействию с администрацией всей
организации. При этом «хирургу»
принадлежит определяющее слово по
важ­нейшим вопросам организации и
проведения работ. «Редактор» критикует
документацию, созданную «хирургом»,
дорабатывает ее, снабжает ссылками и
наблюдает за ее публикацией. «Адвокат
языка» обеспечивает «хирурга»
консультациями по применению языка в
трудных или запутанных ситуациях,
способствует полу­чению более
эффективных программ. «Инструментальщик»
— опытный системный программист —
является создателем специа­лизированных
технологических и служебных программ,
каталоги­зированных процедур,
библиотек макрокоманд для расширения
функций технологического обеспечения
по заказу «хирурга». «Наладчик»
разрабатывает системные тесты в
соответствии с назначением и функциями
создаваемой группы программ. Он планирует
последовательность тестирования,
подготавливает имитаторы исходных
данных для комплексной отладки,
регистри­рует процесс проведения
отладки и ее результаты. Кроме того, в
бригаду входят 2…3 технических работника
для выполнения секретарских функций
и различных вспомогательных техни­ческих
работ.

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

Для сложных ПС, в
создании которых участвуют десятки
специалистов, необходимо провести
четкое различие между архи­тектурой
КП и реализацией проекта в целом, а
также его состав­ных частей.
«Системный архитектор» должен
специальными методами обучения
коллектива обеспечивать функциональное,
структурное и технологическое единство
проекта КП. Руководи­тели, ответственные
за функциональные группы программ,
объединяют усилия бригад и обеспечивают
их взаимодействие по функциональному
и информационному сопряжению компонент,
созданных различными бригадами. Таким
образом, иерар­хическая структура
коллектива в верхних ярусах должна
соот­ветствовать иерархической
структуре создаваемого КП, хотя следует
учитывать и обратное влияние структуры
коллектива на структуру КП.

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

1. Внедрение и
   эксплуатация ПО, процесс сопровождения:
   модификация, усовершенствование и
   коррекция ПО; планирование и организация
   сопровождения, методы конфигурационного
   управления; тиражирование и использование
   версий программ, методы сертификации
   ПО.

Во время фазы
эксплуатации и сопровождения начинается
прак­тическое использование
программного изделия.

Сопровождение
программного обеспечения связано с
внесением изменений в течение всего
времени использования программного
изделия. К причинам, определяющим
необходимость внесения из­менений
в изделии, относятся:

• наличие ошибок
в используемом программном продукте;

• изменение
требований пользователя (расширение
или модифи­кация);

• появление более
совершенных общесистемных программных
средств или технических устройств;

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

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

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

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

Задачи службы
сопровождения программного изделия

В процессе
эксплуатации программного изделия
пользователи взаимодействуют с
организацией (группой), ответственной
за со­провождение. Задачами службы
сопровождения являются:

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

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

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

4. Внесение изменений
в программы с целью их приспособления
к условиям работы конкретного
пользователя.

5. Контроль
правильности всех корректировок,
вносимых в из­делие, и проверка
качества измененных программ.

6. Доведение до
пользователя информации о внесенных
измене­ниях.

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

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

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

Можно предложить следующую методику отладки программного обеспечения, написанного на универсальных языках программирования для выполнения в операционных системах MS DOS и Win32:

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

Если ошибка не найдена или система просто «зависла», переходят ко второму этапу.

2 этап — локализация ошибки — определение конкретного фрагмента, при выполнении которого произошло отклонение от предполагаемого вычислительного процесса. Локализация может выполняться:

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

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

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

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

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

4 этап — исправление ошибки — внесение соответствующих изменений во все операторы, совместное выполнение которых привело к ошибке.

5 этап — повторное тестирование — повторение всех тестов с начала, так как при исправлении обнаруженных ошибок часто вносят в программу новые.

Следует иметь в виду, что процесс отладки можно существенно упростить, если следовать основным рекомендациям структурного подхода к программированию:

•программу наращивать «сверху-вниз», от интерфейса к обрабатывающим подпрограммам, тестируя ее по ходу добавления подпрограмм;

•выводить пользователю вводимые им данные для контроля и проверять их на допустимость сразу после ввода;

•предусматривать вывод основных данных во всех узловых точках алгоритма (ветвлениях, вызовах подпрограмм).

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

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

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

Классификация ошибок возникающих при тестировании по

Отладка программного обеспечения

Отладка программы — один их самых сложных этапов разработки программного обеспечения.

9.1. Классификация ошибок

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

В соответствии с этапом обработки, на котором проявляются ошибки, различают (рис. 9.1):

синтаксические ошибки — ошибки, фиксируемые компилятором (транслятором, интерпретатором) при выполнении синтаксического и частично семантического анализа программы;

ошибки компоновки — ошибки, обнаруженные компоновщиком (редактором связей) при объединении модулей программы;

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

Рис. 9.1. Классификация ошибок по этапу обработки программы

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

Следует иметь в виду, что чем лучше формализованы правила синтаксиса языка, тем больше ошибок из общего количества может обнаружить компилятор и, соответственно, меньше ошибок будет обнаруживаться на следующих этапах. В связи с этим говорят о языках программирования с защищенным синтаксисом и с незащищенным синтаксисом. К первым, безусловно, можно отнести Pascal, ко вторым — С со всеми его модификациями.

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

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

• появление сообщения об ошибке, зафиксированной схемами контроля выполнения машинных команд,

• появление сообщения об ошибке, обнаруженной операционной системой,

• несовпадение полученных результатов с ожидаемыми.

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

• неверное определение исходных данных,

• накопление погрешностей результатов вычислений.

Неверное определение исходных данных происходит, если возникают любые ошибки при выполнении операций ввода-вывода.

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

• ошибки некорректного использования переменных,

• ошибки межмодульного интерфейса,

• другие ошибки кодирования.

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

9.2. Методы отладки программного обеспечения

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

Метод ручного тестирования.

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

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

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

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

В процессе доказательства пытаются выяснить, все ли проявления ошибки объясняет данная гипотеза, если не все, то либо гипотеза не верна, либо ошибок несколько.

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

Метод обратного прослеживания.

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

9.3. Методы и средства получения дополнительной информации

Для получения дополнительной информации об ошибке можно выполнить добавочные тесты или использовать специальные методы и средства

• интегрированные средства отладки,

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

Данный метод не очень эффективен и в настоящее время практически не используется.

Интегрированные средства отладки.

Большинство современных сред программирования (Delphi, Builder C++, Visual Studio и т. д.) включают средства отладки, которые обеспечивают максимально эффективную отладку. Они позволяют:

• выполнять программу по шагам, причем как с заходом в подпрограммы, так и выполняя их целиком,

• предусматривать точки останова,

• выполнять программу до оператора указанного курсором и т.п..

Отладка с использованием независимых отладчиков.

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

9.4. Общая методика отладки программного обеспечения

Суммируя все сказанное выше, можно предложить следующую методику отладки программного обеспечения, написанного на универсальных языках программирования для выполнения в операционных системах MS DOS и Win32:

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

Если ошибка не найдена или система просто «зависла», переходят ко второму этапу.

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

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

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

4 этап — исправление ошибки — внесение соответствующих изменений во все операторы, совместное выполнение которых привело к ошибке.

5 этап — повторное тестирование — повторение всех тестов с начала, так как при исправлении обнаруженных ошибок часто вносят в программу новые.

Указать этапы тестирования и типы ошибок.

Приведите тесты для задачи:

Ввести элементы двумерного массива MAS(2,2) и, если выше главной диагонали хотя бы один элемент >10, просчитать количество всех элементов матрицы, в противном случае вывести сообщение «Условие не выполнено».

Тестирование — процесс выполнения программы с целью обнаружения ошибок.

Все ошибки в разработке программ делятся на следующие

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

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

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

Все ошибки, которые возникают в программах, принято подразделять на следу-ющие классы:

– логические и функциональные ошибки — являются причиной нарушения логи-ки алгоритма, внутренней несогласованности переменных и операторов, а также пра-вил программирования;

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

– ошибки ввода–вывода и манипулирования данными — являются следствием некачественной подготовки данных для выполнения программы, сбоев при занесении их в базах данных или при выборке из нее;

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

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

3. Этапы тестирования ПО.

• модульное тестирование – тестируется минимально возможный для тестиро-вания компонент, например, отдельный класс или функция;

• интегрированное тестирование – проверяется, есть ли какие-либо проблемы в интерфейсах и взаимодействии между интегрируемыми компонентами, например, не передается информация, передается некорректная информация;

• системное тестирование – тестируется интегрированная система на соответствие исходным требованиям:

o альфа-тестирование – имитация реальной работы с системой разработчи-ками либо реальная работа с системой потенциальными пользователями-заказчиками на стороне разработчика.

o бета-тестирование – в некоторых случаях выполняется распространение версии с ограничениями ( по функциональности или времени работы) для некоторой группы лиц с тем, чтобы убедиться, что продукт содержит доста-точно мало ошибок.

Дать понятие класса.

Описать классы, использующиеся для моделирования ПО.

Разработать графическое представление изображения классов для моделирования программного обеспечения:

а) управляющий класс;

В) граничный класс.

Структура и поведение одинаковых объектов описывается в общем для них классе.

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

· класс-сущность – пассивный класс, информация о котором должна храниться постоянно. Как правило, этот класс соответствует отдельной таблице БД. В этом случае его атрибуты являются полями этой таблицы, а операции — присоединенными или хранимыми процедурами (рис. 1, б).

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

11. Отладка программного обеспечения. Классификация ошибок, методы отладки программного обеспечения: ручного тестирования, индукции, дедукции, обратного прослеживания.

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

• специфики управления используемыми техническими средствами,

• среды и языка программирования,

• природы и специфики различных ошибок,

• методик отладки и соответствующих программных средств.

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

В целом сложность отладки обусловлена следующими причинами:

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

• психологически дискомфортна, так как необходимо искать собственные ошибки и, как правило, в условиях ограниченного времени;

• возможно взаимовлияние ошибок в разных частях программы, например, за счет затирания области памяти одного модуля другим из-за ошибок адресации;

• отсутствуют четко сформулированные методики отладки.

В соответствии с этапом обработки, на котором проявляются ошибки, различают (рис. 10.1): синтаксические ошибки — ошибки, фиксируемые компилятором (транслятором, интерпретатором) при выполнении синтаксического и частично семантического анализа программы; ошибки компоновки — ошибки, обнаруженные компоновщиком (редактором связей) при объединении модулей программы;

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

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

Следует иметь в виду, что чем лучше формализованы правила синтаксиса языка, тем больше ошибок из общего количества может обнаружить компилятор и, соответственно, меньше ошибок будет обнаруживаться на следующих этапах. В связи с этим говорят о языках программирования с защищенным синтаксисом и с незащищенным синтаксисом. К первым, безусловно, можно отнести Pascal, имеющий очень простой и четко определенный синтаксис, хорошо проверяемый при компиляции программы, ко вторым — Си со всеми его модификациями. Чего стоит хотя бы возможность выполнения присваивания в условном операторе в Си, например:

if (c = n) x = 0; /* в данном случае не проверятся равенство с и n, а выполняется присваивание с значения n, после чего результат операции сравнивается с нулем, если программист хотел выполнить не присваивание, а сравнение, то эта ошибка будет обнаружена только на этапе выполнения при получении результатов, отличающихся от ожидаемых */ Ошибки компоновки. Ошибки компоновки, как следует из названия, связаны с проблемами,

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

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

• появление сообщения об ошибке, зафиксированной схемами контроля выполнения машинных команд, например, переполнении разрядной сетки, ситуации «деление на ноль», нарушении адресации и т. п.;

• появление сообщения об ошибке, обнаруженной операционной системой, например, нарушении защиты памяти, попытке записи на устройства, защищенные от записи, отсутствии файла с заданным именем и т. п.;

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

• несовпадение полученных результатов с ожидаемыми.

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

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

• неверное определение исходных данных,

• накопление погрешностей результатов вычислений (рис. 10.2).

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

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

К последней группе относят:

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

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

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

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

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

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

опосредованного проявления ошибок;

возможности взаимовлияния ошибок;

возможности получения внешне одинаковых проявлений разных ошибок;

отсутствия повторяемости проявлений некоторых ошибок от запуска к запуску – так называемые стохастические ошибки;

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

написания отдельных частей программы разными программистами.

Методы отладки программного обеспечения

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

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

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

Данный метод часто используют как составную часть других методов отладки.

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

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

В процессе доказательства пытаются выяснить, все ли проявления ошибки объясняет данная гипотеза, если не все, то либо гипотеза не верна, либо ошибок несколько.

Метод дедукции. По методу дедукции вначале формируют множество причин, которые могли бы вызвать данное проявление ошибки. Затем анализируя причины, исключают те, которые противоречат имеющимся данным. Если все причины исключены, то следует выполнить дополнительное тестирование исследуемого фрагмента. В противном случае наиболее вероятную гипотезу пытаются доказать. Если гипотеза объясняет полученные признаки ошибки, то ошибка найдена, иначе — проверяют следующую причину (рис. 10.4).

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

Форум тестировщиков

Стандартная классификация ошибок внутри ко.

Олешка 02 окт 2003

Case 08 окт 2003

Олешка 08 окт 2003

Олешка 08 окт 2003

Case 08 окт 2003

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

По поводу предопределённого заранее типа ошибок, говорить не могу — ибо не знаю такого метода 🙂

Olga 08 окт 2003

Case 08 окт 2003

Олешка 08 окт 2003

У нас тоже есть группы, относящиеся к модулям приложения, или к стадиям тестирования. Речь о другом — есть список типичных ошибок.
Есть ли какое-то рациональное зерно в использовании дополнительно и такого списка?

Наверное, имеет смысл взглянуть на список групп ошибок Канера:

• Ошибки пользовательского интерфейса
• Обработка ошибок
• Ошибки, связанные с граничными условиями
• Ошибки вычислений
• Начальное и последующее состояния
• Ошибки управления потоком
• Ошибки обработки или интерпретация данных
• Ситуации гонок
• Повышенные нагрузки
• Аппаратное обеспечение
• Контроль версий и идентификаторов
• Ошибки тестирования

SNord 08 окт 2003

Олешка 08 окт 2003

Olga 08 окт 2003

Guriy 08 окт 2003

У нас такая группа есть. Другое дело, что она не является обязательной для заполнения.

NOT NULL в базе поставить на поле 😉

Guriy 08 окт 2003

Не использую, потому как не злан что такая спецификация есть.
Можно ссылки в студию или документ в почту (выложу в раздел Портфель).

У него есть поля на форме Change Request
«Component» и «Category»

В компонент — что именно падает «Main Menu — System — File — Open File Dialog»
В категорию — категорию(:)) ошибки «Design»

И потом манагер проекта захотел посмотреть по каким-то параметрам количество багов — выборку по базе 🙂 а-ля

У нас вообще тулзня заполняет эти поля

Case 10 окт 2003

Категорию канешно используем, я имею в виду что у нас сиа не стандартизовано, а так канечно отмечаем — не в дизайне, не в спецификации, повторяющаяся и пр.
С таким разнообразием как вы привели не работаем.
Различные типы ошибок (гонки, затыки, доступ) находятся на определённых этапах тестирования, поэтому не вижу особой надобности особо их разрабсывать.

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

Guriy 10 окт 2003

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

Тестировщикам зато нет 🙁

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

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

Тут именно указывается компонент. А на каком уровне сломалось, это уже девелопер пусть смотрит — у нас задачи другие. Нам под отладчиком тестировать некузяво .

sua 10 окт 2003

Мы в свое время долго бились над классификацие багов у нас в компании и в конце концов пришли к определенному решению. Оно доморощенное, т.к. на тот момент мы были не знакомы с первоисточниками, но и на данный момент нас вполне удовлетворяет
У нас баги делаться по Projects (или Module в другой интерпретации), по Components (область функциональной области)

А еще одна проблема для нас была расстановки проиритетов. Мы также придумали собственную систему:
1- Crash — функция вызывает падеж программы или порчу данных
2 — Blocking point — функция отрабатывает, но результат ноль
3 — Incorrect — функция работает, что-то делает, но неправильно, т.е. результат не совпадает с ожидаемым
4 — Cosmetic — GUI (очепятки, размещение эл-ов ит.д.) и мелкие недочеты функционирования
5 — Requests — предложения по улучшению
6 — specifications — ошибки спецификации
Интересно a как это реализовано у коллег?

Case 10 окт 2003

Сидит вот у меня девочка, ее от слова «сиквэл» в дрожь бросает.

Это её персональная проблема и к вопросу организации процесса отношения не имеет.

Как ей объяснить что вот эта ошибка произошла на бизнес-уровне, а вот эта, хоть и похожая, на уровне клиента. А вот эта вот, ну просто идентичная с предыдущей, — вообще не наша и желающие могут написать претензии в Майкрософт.

Это ей обьяснять и не надо 🙂 На это есть вы. У меня когда сотрудники не сообразят куда закинуть (бизнесс уровень, дата) — просто кидают на меня. Когда я не знаю, кто именно сейчас ведёт этот кусок функционала из девелоперов — просто кидаю на ведущего разработчика.

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

Опять не правда ваша — проект большой, но опять таки к предмету темы дела не имеет.
Да какая мне разница сколько в нём файлов исходников? 🙂

У системы есть N модулей. Каждому модулю в разделе риквестов по две папки для начала:
— ЮзерИнтерфейс — сюда и дизайн и юзабилити, и неспецификацию по тем же полям ввода, табордерам, шорткатам и пр
— БизнесЛогика (вылеты, спецификация, логика, предложения и тыды)

А на каком уровне сломалось, это уже девелопер пусть смотрит

Бедные девелоперы — как же вы им риквесты, то биш запросы на изменение то ставите? 🙂

— у нас задачи другие.

Девушек успокаивать, которые в дрожи бьются? 😉

Guriy, без обид, просто призываю более предметно и обоснованно.

Mike 10 окт 2003

Там где я работал тестером, была следующая классификация (по памяти, мож что и путаю):

Note :
Enhancement
Feature request
Bug:
Crash
Exception occured (не приводящие к слёту программы)
Data error
I/O error
Incorrect result
Interface error (ошибки пользовательского интерфейса)
Spelling error

Кроме этого поля (Category), у каждого дефекта было поле Importance

Case 10 окт 2003

А еще одна проблема для нас была расстановки проиритетов. Мы также придумали собственную систему:
1- Crash — функция вызывает падеж программы или порчу данных
2 — Blocking point — функция отрабатывает, но результат ноль
3 — Incorrect — функция работает, что-то делает, но неправильно, т.е. результат не совпадает с ожидаемым
4 — Cosmetic — GUI (очепятки, размещение эл-ов ит.д.) и мелкие недочеты функционирования
5 — Requests — предложения по улучшению
6 — specifications — ошибки спецификации

Очень продумано.
Во многом зависит от системы которую вы тестируете, но чувствую, что проработано. А потом вы это используете как предлагалось выше? То есть строите разные выборки, чтобы погсомтреть что-то? И если не секрент что именно? Или при планировании применяете? Приоритеты ж ведь.

Интересно a как это реализовано у коллег?

У нас сейчас тип бага это просто указание разработчику что именно вылетело — если угодно просто более формальное описание проблемы. Потом я для себя реальной пользы не вижу. Считать сколько было замечаний по дизайну, а сколько по функционалу мне не очень интересно. Мы стараемся всё таки работать на результат (на продукт), а не на цифры отчётов.

SALar 15 окт 2003

Несколько обьемно, но пока удобно.
————
Полное описание ошибки.

Описание
1) ID
2) Заголовок
3) Описание и воспроизведение (можно разбить на две части)
4) Аттач

Управленческие признаки:
1) Приоритет исправления. 4 градации
2) Важность. 4 градации + предложение
3) Номер версии. Крупная версионность, такая как «Альфа», «Вета», .
4) Владелец.
5) Состояние ошибки. Из Rational Rose.

Аналитические признаки:
1) Часть программы. Обычно 5-15.
2) Тип ошибки. Можно брать из Канера.

Достаточно стандартная ситуация:
Необходимо стабилизировать альфа версию для отправки клиенту. Часть ошибок переносится на бету, недочеты по производительности и авторизации не исправлять.
Запрос программиста к базе:
Часть программы: журнал операций (удобней править один пакет подряд)
Состояние: «назначена» или «в работе»
Тип: «функционал», «дизайн» (остальное не важно СЕЙЧАС)
Версия: «Альфа».
Вывести в порядке важности.
Другой запрос:
Срочно исправить ошибки с высоким приритетом (данные ошибки блокируют работу остальных участников команды)

1. Critical (критическая) — с этой ошибкой приложение не может выполнять своих базовых функций
2. Major (важная) — выпадает важная функциональность
3. Average (средняя) — система ведет себя нестабильно и непредсказуемо
4. Minor () — функция реализована неудобно
5. Enhancement () — нужно добавить в спецификацию

Другой вариант оценки:
1. End User не может выполнять свою работу без внесение изменений в код
2. End User не может выполнять свою работу без консультации с фирмой разработчиком и / или выполнения нетривиальных действий (ручная инициализация базы, …).
3. End User может выполнять свою работу, но это неудобно
4. Мелкие недочеты, такие как, некорректные сообщения системы, отсутствие обозначения полей, обязательных к заполнению, ошибки в падежах, …

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

1. Исправить немедленно.
Данная ошибка блокирует дальнейшую работу остальных участников проекта либо это требование заказчика.
2. По окончании текущей работы
3. Решать в рабочем порядке.
Порядок продолжения разработки и / или внесения изменений планируется разработчиком, исходя из общего плана.
4. Устранить при возможности.
Данная ошибка может быть исправлена при наличии ресурсов или малой ресурсоемкости.

Изначально тестер назначает приоритеты исходя из соответствия важности и критичности для проведения тестов. В дальнейшем менеджер проекта может изменять приоритеты.

Замечу что важность ошибки и приоритет исполнения далеко не одно и тоже. Может быть минорная бага с высшим приоритетом и наоборот.

Классификация ошибок возникающих при тестировании по

Рассмотрим классификацию ошибок по месту их возникновения, которая рассмотрена в книге С. Канера «Тестирование программного обеспечения». Фундаментальные концепции менеджмента бизнес-приложений. . Главным критерием программы должно быть ее качество, которое трактуется как отсутствие в ней недостатков, а также сбоев и явных ошибок. Недостатки программы зависят от субъективной оценкой ее качества потенциальным пользователем. При этом авторы скептически относятся к спецификации и утверждают, что даже при ее наличии, выявленные на конечном этапе недостатки говорят о ее низком качестве. При таком подходе преодоление недостатков программы, особенно на заключительном этапе проектирования, может приводить к снижению надежности. Очевидно, что для разработки ответственного и безопасного программного обеспечения (ПО) такой подход не годится, однако проблемы наличия ошибок в спецификациях, субъективного оценивания пользователем качества программы существуют и не могут быть проигнорированы. Должна быть разработана система некоторых ограничений, которая бы учитывала эти факторы при разработке и сертификации такого рода ПО. Для обычных программ все проблемы, связанные с субъективным оцениванием их качества и наличием ошибок, скорее всего неизбежны.

В краткой классификации выделяются следующие ошибки.

— Ошибки пользовательского интерфейса.

— Ошибки управления потоком.

— Ошибки передачи или интерпретации данных.

— Ошибка выявлена и забыта.

1. Ошибки пользовательского интерфейса.

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

2. Ошибки вычислений.

Выделяют следующие причины возникновения таких ошибок:

— неверная логика (может быть следствием, как ошибок проектирования, так и кодирования);

— неправильно выполняются арифметические операции (как правило — это ошибки кодирования);

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

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

3. Ошибки управления потоком.

В этот раздел относится все то, что связано с последовательностью и обстоятельствами выполнения операторов программы.

— очевидно неверное поведение программы;

— переход по GOTO;

— логика, основанная на определении вызывающей подпрограммы;

— использование таблиц переходов;

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

4. Ошибки обработки или интерпретации данных.

— проблемы при передаче данных между подпрограммами (сюда включены несколько видов ошибок: параметры указаны не в том порядке или пропущены, несоответствие типов данных, псевдонимы и различная интерпретация содержимого одной и той же области памяти, неправильная интерпретация данных, неадекватная информация об ошибке, перед аварийным выходом из подпрограммы не восстановлено правильное состояние данных, устаревшие копии данных, связанные переменные не синхронизированы, локальная установка глобальных данных (имеется в виду путаница локальных и глобальных переменных), глобальное использование локальных переменных, неверная маска битового поля, неверное значение из таблицы);

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

— проблемы с обменом сообщений (сюда включены несколько видов ошибок: отправка сообщения не тому процессу или не в тот порт, ошибка распознавания полученного сообщения, недостающие или несинхронизированные сообщения, сообщение передано только N процессам из N+1, порча данных, хранящихся на внешнем устройстве, потеря изменений, не сохранены введенные данные, объем данных слишком велик для процесса-получателя, неудачная попытка отмены записи данных).

5. Повышенные нагрузки.

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

В этом разделе хотелось бы обратить внимание на следующее:

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

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

6. Контроль версий и идентификаторов.

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

7. Ошибки тестирования.

Являются ошибками сотрудников группы тестирования, а не программы. Выделяются подпункты:

— пропущенные ошибки в программе;

— не замечена проблема (отмечаются следующие причины этого: тестировщик не знает, каким должен быть правильный результат, ошибка затерялась в большом объеме выходных данных, тестировщик не ожидал такого результата теста, тестировщик устал и невнимателен, ему скучно, механизм выполнения теста настолько сложен, что тестировщик уделяет ему больше внимания, чем результатам);

— пропуск ошибок на экране;

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

8. Ошибка выявлена и забыта.

Описываются ошибки использования результатов тестирования. По-моему, раздел следует объединить с предыдущим. Выделяются подпункты: не составлен итоговый отчет; серьезная проблема не документирована повторно; не проверено исправление; перед выпуском продукта не проанализирован список нерешенных проблем.

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

Основные пути борьбы с ошибками

Учитывая рассмотренные особенности действий человека при переводе можно указать следующие пути борьбы с ошибками:

· сужение пространства перебора (упрощение создаваемых систем),

· обеспечение требуемого уровня подготовки разработчика (это функции менеджеров коллектива разработчиков),

· обеспечение однозначности интерпретации представления информации,

· контроль правильности перевода (включая и контроль однозначности интерпретации).

Содержание:

ВВЕДЕНИЕ

Повышение интереса к тестированию программного обеспечения пришлось на 90-е годы XX века в США. Стремительный рост систем автоматизированной разработки программного обеспечения и компьютерных сетей привел к увеличению производства программного обеспечения и к разработке подходов к обеспечению качества и надёжности разрабатываемых приложений. Рост конкуренции между создателями программного обеспечения потребовал определенного внимания к качеству производимых приложений, так как у пользователей появился выбор: разработчики предоставляли свои программы по достаточно приемлемым ценам, что позволяло обращаться к тому, кто разработает необходимый продукт не только дёшево и быстро, но и качественно[3].

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

Анализ актуальности обусловили выбор темы исследования: «Отладка и тестирование программ: основные подходы и ограничения».

Объектом исследования является процесс тестирования программного обеспечения.

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

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

Для достижения поставленной цели необходимо решить следующие задачи:

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

1. ОСНОВНЫЕ АСПЕКТЫ ТЕСТИРОВАНИЯ И ОТЛАДКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

1.1 Понятия тестирования и отладки программного обеспечения

Тестированием программного обеспечения (software testing) является процесс эксплуатации или анализа программного обеспечения для выявления дефектов[1].

Разберём более подробно данное определение. Понятие «процесс» используется выделения того, что тестирование является плановой, упорядоченной деятельностью. На это необходимо обратить внимание, так как хорошо организованная, систематическая проверка упрощает обнаружение программных ошибок, в сравнении с плохо спланированным тестированием.

Из определения следует, что тестирование подразумевает «эксплуатацию» или «анализ» программного обеспечения. Тестирование, при котором выполняется анализ результатов разработки программного продукта, называют статическим тестированием (static testing), в которое включается проверка кода программы, сквозной контроль и проверка «за столом» (desk checks) , т.е. проверка программного продукта без запуска на компьютере. В отличие от статического тестирования, тестовая деятельность, в которой предусмотрена эксплуатация программы, называется динамическим тестированием (dynamic testing). Эти два типа тестирования дополняют друг друга, реализуя в отдельности собственный подход к определению ошибок в программе.

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

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

Отладка – это процесс поиска того оператора программы, который вызвал ошибку вычислительного процесса и исправления найденной ошибки, обнаруженной в процессе тестирования программного обеспечения. Чтобы исправить ошибку необходимо выявить ее причину [2]. Различают следующие типы ошибок:

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

1.2 Цели и задачи тестирования программного обеспечения

Целями тестирования программного обеспечения являются[8]:

• повышение вероятности правильной работы приложения в различных обстоятельствах;
• повышение вероятности соответствия приложения всем необходимым требованиям.
• проведение полного тестирования приложения в короткие сроки.

Задачами тестирования являются:

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

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

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

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

Существуют несколько подходов при формулировании стратегии тестирования[4]:

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

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

3. Определение условий входа и выхода на каждом этапе тестирования, определение всех точек контроля качества.

4. Определение стратегии автоматизации при использовании автоматизации определенного вида тестовых испытаний.

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

Можно выделить несколько рекомендаций по разработке стратегии тестирования, использование которых могут обеспечить оптимальное тестовое покрытие[7]:

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

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

• этап, на котором формулируются требования;
• этап системного проектирования;
• этап, на котором тестируются проекты программы, программные коды, производится модульное тестирование и комплексные испытания;
• системное тестирование;
• приемочное тестирование;
• регрессионное тестирование.

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

Для определения критериев тестирования и точек контроля качества перед началом системного тестирования используют следующие пять типов[6]:

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

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

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

1.4 Комплексное тестирование программного обеспечения

Комплексное тестирование состоит в проверке корректного согласования каждого модуля приложения с остальными его модулями. При этом могут использоваться технологии обработки снизу вверх и сверху вниз, при которых каждый модуль, в виде листа в дереве системы, интегрируется с модулями более высокого или более низкого уровня, пока не будет сформировано дерево программного продукта. Такая технология тестирования необходима для проверки как параметров, передающихся между двумя модулями, так и для проверки глобальных параметров[10].

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

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

1.5 Восходящее и нисходящее тестирование

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

Недостаток восходящего тестирования состоит в необходимости создания специального скрипта-оболочки, который бы вызывал тестируемый модуль, и «заглушки» для других модулей – имитации вызываемой функции, которая возвращает только данные, ничего больше не выполняя.

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

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

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

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

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

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

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

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

Мнения разработчиков об эффективности этих двух инкрементальных подходов тестирования разнятся[4, 9, 11]. Практически выбор стратегии тестирования производится следующим образом: все модули по возможности тестируется сразу после их создания, поэтому тестирование одних частей программы может происходить в восходящей последовательности, а других – в нисходящей.

2. РАЗЛИЧНЫЕ ПОДХОДЫ К ТЕСТИРОВАНИЮ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

2.1 Метод сандвича

Метод сандвича является компромиссным методом между восходящими и нисходящими технологиями тестирования. Здесь делается попытка воспользоваться достоинствами обоих методов, избежав их недостатков. В данном методе нисходящее и восходящее тестирование начинают одновременно, проверяя код как сверху, так и снизу и заканчивая проверку где-то в середине иерархии модулей. Место окончания проверки зависит от программы, которая тестируется и заранее определяется при разборе ее структуры. Например, если программа может быть представлена как совокупность, включающую в себя прикладные модули, затем модули обработки запросов, уровни примитивных функций, то программист может применить нисходящий метод при тестировании прикладных модулей (создавая заглушки, замещающие модули обработки запросов), а остальные модули проверять восходящим методом. Метод сандвича применяется при проверке больших программ, например, операционных систем или пакетов прикладных программ[4].

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

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

2.2 Метод «белого ящика»

Метод «белый ящик» состоит в том, что при создании тестовых случаев программисты используют все данные о внутренней структуре программы и её или коде. Технологии, которые применяются при тестировании методом «белого ящика» представляют собой технологии статического тестирования[8].

Этот метод не выявляет синтаксические ошибки, ткоторые обнаруживаются компилятором. Метод «белого ящика» направлен на поиск дефектов, выявить которые сложно, на обнаружение логических ошибок и проверку степени покрытия тестами.

В тестовых испытаниях методом «белого ящика» применяют управляющую логику процедур. Они выполняют следующие функции:

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

Метод «белого ящика» является разновидностью стратегии модульного тестирования, при которой тестирование производится на функциональном или модульном уровне и тестирование направлено на исследование внутренней структуры модуля. Такой тип тестирования также носит название модульного тестирования или тестирования «прозрачного ящика» (clear box) или прозрачным (translucent) тестированием, так как специалисты, кторые проводят тестирование, знают весь программный код и видят работу программы изнутри. Подход к тестированию, основанный на открытости кода, ещё называют структурным подходом.

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

2.3 Методы тестирования на основе стратегии «белого ящика»

2.3.1 Ввод неверных значений

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

2.3.2 Модульное тестирование

Разработка отдельных модулей программы сопровождается модульным тестированием, в результате которого проверяется, работоспособность кода, верность его работы и корректность реализации интерфейса. Модульное тестирование проверяет новый код на соответствие архитектуры; изучаются пути в коде, определяется, что ниспадающие меню, экраны и сообщения отформатированы должным образом; выполняется проверка диапазона и типов вводимых данных, а также генерацию исключений и возврата ошибок (error returns). Тестирование отдельных модулей программы выполняется для проверки корректности алгоритмов и логики соответствия предъявляемым требованиям функциональности. В результате модульного тестирования определяются ошибки, которые относятся к времени работы, логике программы, выходу из диапазона, перегрузке и утечке памяти.

2.3.3 Тестирование обработки ошибок

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

2.3.4 Утечка памяти

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

2.3.5 Комплексное тестирование

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

2.3.6 Тестирование цепочек

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

2.3.7 Исследование покрытия

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

2.3.8 Покрытие решений

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

2.3.9 Покрытие условий

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

2.4 Метод «черного ящика»

Тестирование на основе стратегии черного ящика возможно лишь при наличии установленных открытых интерфейсов, таких как интерфейс пользователя или программный интерфейс приложения (API). Если тестирование на основе стратегии белого ящика исследует внутреннюю работу программы, то методы тестирования черного ящика сравнивают поведение приложения с соответствующими требованиями. Кроме того, эти методы обычно направлены на выявление трех основных видов ошибок: функциональности, поддерживаемой программным продуктом; производимых вычислений; допустимого диапазона или области действия значений данных, которые могут быть обработаны программным продуктом. На этом уровне тестировщики не исследуют внутреннюю работу компонентов программного продукта, тем не менее, они проверяются неявно. Группа тестирования изучает входные и выходные данные программного продукта. В этом ракурсе тестирование с помощью методов черного ящика рассматривается как синоним тестирования на уровне системы, хотя методы черного ящика могут также применяться во время модульного или компонентного тестирования.

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

Тестирование при помощи методов черного ящика направлено на получение множеств входных данных, которые наиболее полно проверяют все функциональные требования системы. Это не альтернатива тестированию по методу белого ящика. Этот тип тестирования нацелен на поиск ошибок, относящихся к целому ряду категорий, среди них[9]:

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

2.5 Методы тестирования на основе стратегии «черного ящика»

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

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

При тестировании ошибок, связанных с выходом за пределы области допустимых значений, применяют три основных типа эквивалентных классов: значения внутри границы диапазона, за границей диапазона и на границе. Оправдывает себя практика создания тестовых процедур, которые проверяют граничные случаи плюс/минус один во избежание пропуска ошибок «на единицу больше» или «на единицу меньше». Кроме разработки тестовых процедур, использующих сильно структурированные классы эквивалентности, группа тестирования должна провести исследовательское тестирование. Тестовые процедуры, при выполнении которых выдаются ожидаемые результаты, называются правильными тестами. Тестовые процедуры, проведение которых должно привести к ошибке, носят название неправильных тестов[7].

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

Анализ граничных значений можно применить как на структурном, так и на функциональном уровне тестирования. Границы определяют данные трех типов: правильные, неправильные и лежащие на границе. Тестирование границ использует значения, лежащие внутри или на границе (например, крайние точки), и максимальные/минимальные значения (например, длины полей). При таком исследовании всегда должны учитываться значения на единицу больше и меньше граничного. При тестировании за пределами границы используется репрезентативный образец данных, выходящих за границу, т.е. неверные значения.

2.5.3 Диаграммы причинно-следственных связей

Составление диаграмм причинно-следственных связей — это метод, дающий четкое представление о логических условиях и соответствующих действиях. Метод предполагает четыре этапа. Первый этап заключается в составлении перечня причин (условий ввода) и следствий (действий) для модуля и в присвоении идентификатора каждому модулю. На втором этапе разрабатывается диаграмма причинно-следственных связей. На третьем этапе диаграмма преобразуется в таблицу решений. Четвертый этап включает в себя установление причин и следствий в процессе чтения спецификации функций. Каждой причине и следствию присваивается собственный идентификатор. Причины перечисляются в столбике с левой стороны листа бумаги, а следствия — с правой. Затем причины и следствия соединяются линиями так, чтобы были отражены имеющиеся между ними соответствия. На диаграмме проставляются булевы выражения, которые объединяют две или более причин, связанных со следствием. Далее правила таблицы решений преобразуются в тестовые процедуры.

2.5.4 Системное тестирование

Термин «системное тестирование» часто употребляется как синоним «тестирования с помощью методов черного ящика», поскольку во время системного тестирования группа тестирования рассматривает в основном «внешнее поведение» приложения. Системное тестирование включает в себя несколько подтипов тестирования, в том числе функциональное, регрессионное, безопасности, перегрузок, производительности, удобства использования, случайное, целостности данных, преобразования данных, сохранения резервных копий и способности к восстановлению, готовности к работе, приемо-сдаточные испытания и альфа/бета тестирование.

2.5.5 Функциональное тестирование

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

2.5.6 Регрессионное тестирование.

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

2.5.7 Тестирование безопасности

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

2.5.8 Тестирование перегрузок

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

2.5.9 Тестирование производительности

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

2.5.10 Тестирование удобства использования

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

3. ОТЛАДКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

3.1 Методы отладки программного обеспечения

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

— ручного тестирования;

— индукции;

— дедукции;

— обратного прослеживания.

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

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

Данный метод часто используют как составную часть других методов отладки.

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

Рисунок 1 — Схема процесса отладки методом индукции

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

В процессе доказательства пытаются выяснить, все ли проявления ошибки объясняет данная гипотеза, если не все, то либо гипотеза не верна, либо ошибок несколько.

Метод дедукции. По методу дедукции вначале формируют множество причин, которые могли бы вызвать данное проявление ошибки. Затем анализируя причины, исключают те, которые противоречат имеющимся данным. Если все причины исключены, то следует выполнить дополнительное тестирование исследуемого фрагмента. В противном случае наиболее вероятную гипотезу пытаются доказать. Если гипотеза объясняет полученные признаки ошибки, то ошибка найдена, иначе — проверяют следующую причину (рис. 2).

Рисунок 2 — Схема процесса отладки методом дедукции

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

3.2 Общая методика отладки программного обеспечения

Суммируя все сказанное выше, можно предложить следующую методику отладки программного обеспечения, написанного на универсальных языках программирования[9]:

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

Если ошибка не найдена или система просто «зависла», переходят ко второму этапу.

2 этап — локализация ошибки — определение конкретного фрагмента, при выполнении которого произошло отклонение от предполагаемого вычислительного процесса. Локализация может выполняться:

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

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

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

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

4этап — исправление ошибки — внесение соответствующих изменений во все операторы, совместное выполнение которых привело к ошибке.

5 этап — повторное тестирование — повторение всех тестов с начала, так как при исправлении обнаруженных ошибок часто вносят в программу новые.

Следует иметь в виду, что процесс отладки можно существенно упростить, если следовать основным рекомендациям структурного подхода к программированию[7]:

• программу наращивать «сверху-вниз», от интерфейса к обрабатывающим подпрограммам, тестируя ее по ходу добавления подпрограмм;
• выводить пользователю вводимые им данные для контроля и проверять их на допустимость сразу после ввода;
• предусматривать вывод основных данных во всех узловых точках алгоритма (ветвлениях, вызовах подпрограмм).

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем [текст] / Б. Бейзер; — Питер, 2004, 320 с. ISBN 5-94723-698-2.
2. Брауде Э.Д. Технология разработки программного обеспечения [текст] / Э.Д. Брауде; — Питер, 2004, 656 с. ISBN 5-94723-663-X.
3. Винниченко И.В. Автоматизация процессов тестирования [текст] / И. В. Винниченко; — Питер, 2005, 208 с. ISBN 5-469-00798-7.
4. Канер С. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений [текст] / С. Канер; — ДиаСофт, 2001, 544 с, ISBN 966-7393-87-9.
5. Калбертсон Р. Быстрое тестирование [текст] / Р. Калбертсон, К. Браун, Г. Кобб; — Вильямс, 2002, 384 с. ISBN 5-8459-0336-X.
6. Коликова Т.В. Основы тестирования программного обеспечения. Учебное пособие [текст] / Т.В. Коликова, В.П. Котляров; — Интуит, 2006, — 285 с. ISBN 5-85582-186-2.
7. Касперски К. Техника отладки программ без исходных текстов [текст] / К. Касперски; — БХВ-Петербург, 2005, 832 с. ISBN 5-94157-229-8.
8. Макгрегор Д. Тестирование объектно-ориентированного программного обеспечения. Практическое пособие [текст] / Д. Макгрегор, Д. Сайкс; — ТИД «ДС», 2004, 432 с. ISBN 966-7992-12-8.
9. Плаксин М. Тестирование и отладка программ — для профессионалов будущих и настоящих [текст] / М. Пласкин; — Бином. Лаборатория знаний, 2007, — 168 с. ISBN 978-5-94774-458-3.
10. Роберт М. Быстрая разработка программ: принципы, примеры, практика [текст] / М. Роберт, Д. Ньюкирк; — Вильямс, 2004, 752 с. ISBN 5-8459-0558-3.
11. Фолк Д. Тестирование программного обеспечения [текст] / Д. Фолк, Е. К. Нгуен, С. Канер; — Диасофт, 2003 , 400 с. ISBN 966-7393-87-9.
12. Элфрид Д. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация [текст] / Элфрид Д., Джефф Р., Джон П.;- Лори, 2003, ISBN 5-85582-186-2.

Скачать материал

Скачать материал

Описание презентации по отдельным слайдам:

• 

  1 слайд

  ОТЛАДКА ПРОГРАММЫ
  Предмет: Технология разработки
  программного обеспечения

  Преподаватель: Кумскова И.А.

• 

  2 слайд

  ОПРЕДЕЛЕНИЯ
  …Возмездье
  Рукой бесстрастной чашу с нашим ядом
  Подносит нам же..,
  (Шекспир. Макбет)

  Программа, свободная от ошибок, есть абстрактное теоретическое понятие .
  ОТЛАДКА ПРОГРАММЫ (program debugging) — этап разработки программы, состоящий в локализации, выявлении и устранении программных ошибок, факт существования которых уже установлен.
  Отладка имеет место тогда, когда очевидно, что программа либо не компилируется, либо работает неправильно.
  Отладка программы предполагает обязательное наличие той или иной ошибки, в противном случае речь идет о тестировании.

• 

  3 слайд

  СЛОЖНОСТЬ ОТЛАДКИ
  ПРИЧИНЫ:
  требует от программиста глубоких знаний специфики управления используемыми техническими средствами, операционной системы, среды и языка программирования, реализуемых процессов, природы и специфики различных ошибок, методик отладки и соответствующих программных средств;
  психологически дискомфортна, так как необходимо искать собственные ошибки и, как правило, в условиях ограниченного времени;
  возможно взаимовлияние ошибок в разных частях программы, например, за счет затирания области памяти одного модуля другим из-за ошибок адресации;
  отсутствуют четко сформулированные методики отладки.

• 

  4 слайд

  ОШИБКИ
  Из истории ошибок: первая программная ошибка была обнаружена на заре развития ЭВМ,
  когда в Массачусетском технологическом
  институте окончилась неудачей попытка
  запуска машины Whirlwind I.

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

• 

  5 слайд

  ОШИБКИ ВЫПОЛНЕНИЯ
  Способы проявления:
  появление сообщения об ошибке, зафиксированной схемами контроля выполнения машинных команд, например, переполнении разрядной сетки, ситуации «деление на ноль», нарушении адресации и т.п.;
  появление сообщения об ошибке, обнаруженной операционной системой, например, нарушении защиты памяти, попытке записи на устройства, защищенные от записи, отсутствии файла с заданным именем и т.п.;
  «зависание» компьютера, как простое, когда удается завершить программу без перезагрузки операционной системы, так и «тяжелое», когда для продолжения работы необходима перезагрузка;
  несовпадение полученных результатов с ожидаемыми.

• 

  6 слайд

  ОШИБКИ ВЫПОЛНЕНИЯ

• 

• 

  8 слайд

  СЛОЖНОСТЬ ОТЛАДКИ
  Сложность отладки увеличивается также вследствие влияния следующих факторов:
  опосредованного проявления ошибок;
  возможности взаимовлияния ошибок;
  возможности получения внешне
  одинаковых проявлений разных ошибок;
  отсутствия повторяемости проявлений некоторых ошибок от запуска к запуску — так называемые стохастические ошибки;
  возможности устранения внешних проявлений ошибок в исследуемой ситуации при внесении некоторых изменений в программу, например, при включении в программу диагностических фрагментов может аннулироваться или измениться внешнее проявление ошибок;
  написания отдельных частей программы разными программистами.

• 

  9 слайд

  ОШИБКИ ОБЩЕГО ХАРАКТЕРА

  Логические ошибки
  Ошибки в циклах
  Ошибки при работе с данными
  Ошибки в описании переменных
  Ошибки при работе с массивами
  Ошибки арифметических операций
  Ошибки в подпрограммах
  Ошибки ввода-вывода
  Ошибки логических операций

• 

  10 слайд

  МЕТОДИКА ОТЛАДКИ ПО
  1 этап — изучение проявления ошибки: если выдано какое-либо сообщение или выданы неправильные или неполные результаты, то необходимо их изучить и попытаться понять, какая ошибка могла так проявиться версии о характере ошибки, которые необходимо проверить.
  2 этап — локализация ошибки: определение конкретного фрагмента, при выполнении которого произошло отклонение от предполагаемого вычислительного процесса.
  3 этап — определение причины ошибки: изучение результатов второго этапа и формирование версий возможных причин ошибки.
  4 этап — исправление ошибки: внесение соответствующих изменений во все операторы, совместное выполнение которых привело к ошибке.
  5 этап — повторное тестирование: повторение всех тестов с начала, так как при исправлении обнаруженных ошибок часто вносят в программу новые.

• 

  11 слайд

  СРЕДСТВА ОТЛАДКИ
  Типы отладочных средств, применяемых при программировании:
         1. Распечатывание содержимого памяти.
         2. Отслеживание хода выполнения алгоритма.
         3. Отслеживание обращений к переменным.
         4. Отслеживание обращений к подпрограммам.
         5. Проверка индексов.
         6. Воспроизведение значений переменных.

• 

  12 слайд

  МЕТОДЫ ОТЛАДКИ
  Запуск программы из под отладчика с пошаговой отладкой, просмотром состояний (переменных, стека, памяти, регистров и т.п.) в требуемых точках исполнения программы.
  Логирования кода – вывод в файл (или консоль и т.п.) входных, выходных аргументов функций, промежуточных состояний (переменных, стека, памяти, передаваемых или получаемых каким-либо образом данных и т.п.) в процессе исполнения программы. При сложностях с воспроизведением сценария дефекта, логирование становится основной методикой отладки.

• 

  13 слайд

  МЕТОДЫ ОТЛАДКИ
  Анализ кода без исполнения программы – поиск причин возникновения дефекта с помощью анализа исходного кода программы, проблемного контента, конфигурации, состояния базы данных и т.п.
  Анализ поведения системы или её части – изолирование проблемы, путём упрощения сценария (используя ручное или автоматическое тестирование). Аксиома звучит так: чем проще сценарий, тем проще отладить проблему. Если найти более простой сценарий, то отладка может упроститься.
  Unit тестирование – выполнение автоматических unit test-ов в основном изолировано (т.е. в более простых сценариях) для функций (модулей, компонентов и т.п.), и таким образом автоматическое выявление проблемных участков кода. Unit тестирование в каком-то смысле одна из разновидностей отладки путём «анализа поведения системы».

• 

  14 слайд

  МЕТОДЫ ОТЛАДКИ
  Прототипирование – проверка функций (модулей, библиотек, и т.п.) в изоляции с помощью небольших примеров кода (прототипов). Прототип легче отлаживать, чем целевую систему. Если проблема воспроизводиться с помощью прототипа, отладка упрощается.
  Отладка с помощью memory-dump-ов – разновидность логирования кода, только здесь логируется не просто некая структура памяти, а целиком вся память процесса и состояния регистров, когда возникает exception. По такому дампу памяти можно «раскрутить» состояние программы (стеков, очередей, переменных и т.п.), в котором она находилась во время паники. Достаточно много существует инструментальных средств для выполнения этой операции.

• 

  15 слайд

  МЕТОДЫ ОТЛАДКИ
  Отладка с помощью перехватов – в основном используется в случаях утечки ресурсов, разновидность логирования кода. Основная идея: перехват и логирование вызова функций выделения и освобождения ресурса, а также анализ состояния ресурсов (например, памяти) в требуемый момент времени или в нужной точке исполнения программы.
  Профилирование кода (если необходима оптимизация производительности) – разновидность логирования кода, хотя часто выполняется с использованием специализированных инструментальных средств (профилировщиков). Этот метод отладки позволяет получить профиль исполнения программы – сколько и какая функция, строчка кода, модуль, и т.п. отнимают процессорного времени, и таким образом найти узкие места.

• 

  16 слайд

  МЕТОДЫ ОТЛАДКИ
  Выполнения программы (или её части) в другой среде (операционной системе, эмуляторе, симуляторе) – основная идея в том, что если нет инструментальных средств на целевой платформе, то можно спортировать код на другую платформу, где они есть. Также можно изначально писать кросс-платформенный код системы или какой-то её части, и таким образом, при необходимости практически без портирования отлаживать код на другой платформе.
  Отладка методом RPC (remote procedure call)  – применимо в основном для встроенного программирования. Суть метода в возможности вызвать любую функцию (модуль и т.п.) передавая аргументы и получая результаты исполнения удалённо с одного хоста на другом вместо того, чтобы тратить время на компиляцию или обновление софта на удалённом хосте.

• 

  17 слайд

  МЕТОДЫ ОТЛАДКИ
  Отладка путём анализа документации, дизайна, требований или ограничений модулей (программных или аппаратных) – применимо в основном для сложных и крупных проектов. Основная идея понять по имеющейся документации допустимо ли поведение, происходящее в дефекте.
  Отладка трансляцией кода – сложный алгоритм пишется или прототипируется на одном языке программирования) с наличием всех доступных инструментальных средств), а потом исходный код отлаженного алгоритма транслируется в ручную или автоматически в другой язык программирования (целевой системы), для которого отсутствуют необходимые инструментальный средства.
  Возможны и другие варианты, например,   дисассемблерование с целью более низкоуровневого понимания, что происходит при выполнении программы. Т.е. анализируется некий промежуточный вариант кода, который в некоторых ситуациях легче отладить или понять.

• 

  18 слайд

  МЕТОДЫ ОТЛАДКИ
  Отладка разработкой интерпретатора — метод отладки, корый используется, когда модуль требует частых изменений, а время построения приложения очень большое.
  Для ускорения процесса и гибкости пишется небольшой интерпретатор кода с наличием управляющих конструкций. При наличии такого интерпретатора разработчик сравнительно не сложно создаёт скрипты, которые  можно быстрее исправить и отладить.

• 

  19 слайд

  ПРЕДОТВРАЩЕНИЕ ОШИБОК
  Не применяйте непроверенных способов программирования.
  Старайтесь не использовать принцип умолчания.
  Никогда не допускайте зависимости работы программы от достоверности данных.
  Добивайтесь полноты логических решений.
  Стремитесь минимизировать число обращений к оператору ЭВМ.

• 

  20 слайд

  СОВЕТЫ ПРОГРАММИСТУ
  Применяйте отладочный компилятор.
  Первым делом проверяйте программу за столом.
  Выполняйте эхо-проверку вводимых данных.
  Вводите средства отладки как можно раньше.
  Контролируйте правдоподобность вводимых
  данных.
  Используйте доступные для вас
  средства отладки.
  Делайте программу правильной с
  самого начала.

Найдите материал к любому уроку, указав свой предмет (категорию), класс, учебник и тему:

6 096 098 материалов в базе

• Выберите категорию:
• Выберите учебник и тему

• Выберите класс:
• Тип материала:

  • Все материалы

  • Статьи

  • Научные работы

  • Видеоуроки

  • Презентации

  • Конспекты

  • Тесты

  • Рабочие программы

  • Другие методич. материалы

Найти материалы

Вам будут интересны эти курсы:

• Курс повышения квалификации «Методика написания учебной и научно-исследовательской работы в школе (доклад, реферат, эссе, статья) в процессе реализации метапредметных задач ФГОС ОО»

• Курс повышения квалификации «Организация научно-исследовательской работы студентов в соответствии с требованиями ФГОС»

• Курс профессиональной переподготовки «Экскурсоведение: основы организации экскурсионной деятельности»

• Курс повышения квалификации «Экономика предприятия: оценка эффективности деятельности»

• Курс профессиональной переподготовки «Клиническая психология: теория и методика преподавания в образовательной организации»

• Курс повышения квалификации «Управление финансами: как уйти от банкротства»

• Курс повышения квалификации «Организация практики студентов в соответствии с требованиями ФГОС юридических направлений подготовки»

• Курс профессиональной переподготовки «Организация деятельности по подбору и оценке персонала (рекрутинг)»

• Курс повышения квалификации «Организация практики студентов в соответствии с требованиями ФГОС медицинских направлений подготовки»

• Курс повышения квалификации «Экономика: инструменты контроллинга»

• Курс повышения квалификации «Разработка бизнес-плана и анализ инвестиционных проектов»

• Курс повышения квалификации «Актуальные вопросы банковской деятельности»

• Курс профессиональной переподготовки «Деятельность по хранению музейных предметов и музейных коллекций в музеях всех видов»

• Курс профессиональной переподготовки «Политология: взаимодействие с органами государственной власти и управления, негосударственными и международными организациями»

Классификация ошибок

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

В целом сложность отладки обусловлена следующими причинами:

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

Следует иметь в виду, что чем лучше формализованы правила синтаксиса языка, тем больше ошибок из общего количества может обнаружить компилятор и, соответственно, меньше ошибок будет обнаруживаться на следующих этапах. В связи с этим говорят о языках программирования с защищенным синтаксисом и с незащищенным синтаксисом. К первым, безусловно, можно отнести Pascal, имеющий очень простой и четко определенный синтаксис, хорошо проверяемый при компиляции программы, ко вторым — Си со всеми его модификациями. Чего стоит хотя бы возможность выполнения присваивания в условном операторе в Си, например:

if (c = n) x = 0; /* в данном случае не проверятся равенство с и n, а выполняется присваивание с значения n, после чего результат операции сравнивается с нулем, если программист хотел выполнить не присваивание, а сравнение, то эта ошибка будет обнаружена только на этапе выполнения при получении результатов, отличающихся от ожидаемых.

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

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

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

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

Неправильное исходное положение => включение в движение синергистов

Выполнение первой фазы

тестирования с максимальной силой => быстрое утомление мышцы

Врач работает в уступающем режиме

(концентрическое сокращение) => тонус не изменяется

Врач работает в подавляющем режиме

(эксцентрическое сокращение) => тонус снижается

Пациент задерживает дыхание,

касается участков тела => проводится терапевтическая локализация

Врач касается суставов пациента => проводится терапевтическая локализация

ФАКТОРЫ, РЕАЛИЗУЮЩИЕ ТОНУС МЫШЦ.

Периферический уровень

• ноцицепторы, проприоцепторы, барорецепторы, виброрецепторы (фасция периост, связки, сухожильный аппарат Гольджи).

Сегментарный уровень

• функциональный блок

• компрессия корешка

• дуральная торзия

• венозный застой

• лимфостаз

• меридианный дисбаланс

Таламическнй уровень.

• висцеральный орган

• нейрологический зуб

Центральный уровень

• эмоциональный дисбаланс

• эндокринные нарушения

• обменные процессы

АССОЦИИРОВАННАЯ МЫШЦА

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

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

Клиника — определяется вторичным укорочением и гиперактивностью антогониста.

Терапевтическая локализация —

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

при локализации на саногенный очаг дисфункции не реагирует (отрицательная реакция).

Провокация — обычно не используется.

ИНДИКАТОРНАЯ МЫШЦА.

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

Терапевтическая локализация —

при расположении руки, магнита, камертона над патогенным очагом формирует функциональную слабость.

Провокация —

А. Механическая — смещение диагностируемого позвонка, органа.

• во всех направлениях вызывает слабость мышцы (органическое поражение, МТ противопоказана).

• во всех направлениях не вызывает слабость мышцы (ошибка ТЛ).

Патобиомеханические изменения

Цель методов мануальной терапии

расслабленная мышца     Растянутая мышца Укороченная мышца Функциональный блок   мышечного генеза (комбинация латерофлексии и ротации в од­ном направлении в сочетании с флексией и экстензией) суставного генеза (комбинация латерофлексии и ротации в раз­ном направлении в сочетании с флексией и экстензией) связочного генеза экстензия в сочетании с латерофлексией разной направленности дурального генеза (ротация в разном направлении без наличия других угловых движений внутрикостного генеза (экстензия или флексия без со­путствующих угловых движений) Локальная гипермобильность регионарный постуральный дисбаланс мышц неоптимальная стати­ка   Атипичный моторный паттерн   Неоптимальная динамика

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

• в одном направлении вызывает слабость мышцы (МТ показана в данном направлении с учетом rebound — mechanism).

В. Дыхательная — проводится в сочетании с механическим смещением, вызывающим слабость мышцы.

• на обе фазы дыхания сохраняется слабость (торзия твердой мозговой оболочки).

• на одну фазу дыхания исчезает мышечная слабость (используется при МТ).

• на обе фазы дыхания исчезает мышечная слабость (ошибка диагностики).

Характеристика болевого синдрома расслабленной мышцы

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

Диагностика формирования мышечного дисбаланса с позиции первичности мышечного укорочения или расслабления

характе­ристика патогенез   визуаль­ные критерии     формирование атипичного моторного паттерна     коррекция

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

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

6. МЕТОДЫ ДИАГНОСТИКИ В ПРИКЛАДНОЙ КИНЕЗИОЛОГИИ

Терапевтическая локализация

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

Провокация

Увеличение активности имеющегося очага поражения посредством раздражения:

1. Механическое раздражение —

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

2. Химическое раздражение — локализация на кожу, слизистые оболочки химических веществ (токсинов, пищевых добавок).

3. Эмоциональное раздражение —

проговаривание вслух или мысленно слов, дат, воспроизведение событий.

ВАРИАНТЫ ФУНКЦИОНАЛЬНЫХ БЛОКОВ

Сублюксация

Фиксация

(Функциональный блок мышечный) • образован вследствие мышечного дисбаланса • возникает в тех позвонках, которые имеют ассоциативные связи с мышцами • визуальная оценка — асимметрия одного из позвонков • Терапевтическая локализация — на остистый отросток одного позвонка • Провокация — пассивное смещение остистого отростка в разные стороны, дыхание • Лечение — мобилизация пассивным смещением в сочетании с актом дыхания

(Функциональный блок суставный) • образован вследствие дискового или внутрисуставного дисбаланса. • возникает в тех позвонках, которые с мышцами имеют приобретенные связи • визуальная оценка — асимметрии позвонков нет • Терапевтическая локализация — на остистые отростки двух соседних позвонков • Провокация пассивное смещение остистых отростков друг против друга или активное движение региона конечности или туловища • Лечение — манипуляция в направлении линейного смещения

НЕЙРОВАСКУЛЯРНЫЕ ТОЧКИ

НЕЙРОЛИМФАТИЧЕСКИЕ ТОЧКИ

7. СХЕМА АССОЦИИРОВАНЫХ СВЯЗЕЙ МЫШЦ

8. СТРУКТУРНАЯ СОСТАВЛЯЮЩАЯ ЗДОРОВЬЯ. КОМПРЕССИОННЫЙ СИНДРОМ ПОЗВОНОЧНИКА

ДИАГНОСТИКА КОРЕШКОВОЙ КОМПРЕССИИ.

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

Объективный статус:

• снижение чувствительности и сухожильных рефлексов соответствующих для компремированного корешка.

• в нейтральном положении возможна слабость соответствующих мышц стопы (кисти)

• провокация движения соответствующим отделам позвоночника в направлении флексии, экстензии, латерофлексии, ротации

• данная провокация изменения силы тестируемых мышц бедра и стопы (плеча, кисти)

ОСОБЕННОСТИ ФОРМИРОВАНИЯ МЫШЕЧНОЙ СЛАБОСТИ ПРИ КОМПРЕССИИ КОРЕШКОВ.

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

2. Терапевтическая локализация малоэффективна. Вместо нее используется компрессия (положение сидя, давление на голову).

3. Последовательность возникновения неврологического поражения:

• снижение тонуса мышц

• гиперстезия — гипостезия

• болевые ощущения

4. Сила мышц изменяется при положении «сидя — лежа». При движении в одну из сторон — флексия, латерофлексия, экстензия, ротация.

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

СООТВЕТСТВИЕ НАПРАВЛЕНИЯ ПРОВОКАЦИИ ПАТОБИОМЕХАНИЧЕСКОМУ ИЛИ ПАТОМОРФОЛОГИЧЕСКОМУ ИЗМЕНЕНИЮ СТРУКТУР ПОЗВОНОЧНИКА.

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

АЛГОРИТМ ДИАГНОСТИКИ КОМПРЕССИИ КОРЕШКОВ

1. Исследование в положении сидя.

2. Проведение провокации — флексия, экстензия, латерофлексия, ротация.

3. Исследование в положении лежа.

4. Повторное проведение провокации в направлении вызывающем слабость мышц при тестировании сидя.

5. Определение направления движения туловища увеличивающего и/или уменьшающего силу иннервируемых мышц.

КОМПРЕССИЯ ШЕЙНЫХ КОРЕШКОВ

Уровень поражения	Наименование мышцы
С5	надостная (Сд) дельтовидная (Сд)
С6	плечелучевая мышца плеча, двуглавая мышца, лучевой разгибатель кисти, локтевой разгибатель кисти
С7	треглавая мышца плеча, лучевой флексор кисти
С8	локтевой флексор кисти
Th1	червеобразные мышцы

BICEPS BRACHII & BRACHIALIS

Иннервация BICEPS – мышечно-кожный нерв, С5, 6

BRACHIALIS — мышечно-кожный нерв, лучевой нерв, С5, 6

Питание – бетаин, НСl, доуденальный экстракт, хлорофил.

Меридиан — желудок Орган – желудок

CORABRACHIALIS

Иннервация — мышечно-кожный нерв, С6, 7

Питание – lung glundilar, Vit. C. Меридиан — легкие Орган – легкие

BRACHIRADIALIS

Иннервация — лучевой нерв, С5, 6

Иннервация — лучевой нерв, С5, 6, 7, 8

Тестирование – давление на дорсальную поверхность кисти, вдоль второй пястной кости

в направлении сгибания и незначительно к локтевой стороне

Иннервация — лучевой нерв, С6, 7, 8

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

TRICEPS BRACHII

Иннервация — лучевой нерв, С6, 7, 8, T1

Питание – возможно splin glundilars

Меридиан – поджелудочная железа

Орган – селезенка

Иннервация: Медиальный ненв С6, 7, 8

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

Тестирование: Давление на возвышение большого пальца в направлении разгибания и локтевой кости

ТЕСТИРУЕМЫЕ МЫШЦЫ

ПРИ ДИАГНОСТИКЕ КОМПРЕССИИ СПИННЫХ КОРЕШКОВ

Порядковый номер корешка	Наименование мышцы
L1(2)	косые мышцы, живота поперечная мышца живота, квадратная мышца поясницы, пояснично-подвздошная, портняжная мышца
L2(3)	четырехглавая мышца, приводящие мышцы бедра, пояснично – подвздошная, портняжная мышца
L4	передняя большеберцовая четырехглавая бедра приводящая бедра
L5	разгибатель большого пальца, задняя большеберцовая, экстензоры бедра, большая ягодичная, средняя ягодичная, грушевидная
S1	длинная малоберцовая, короткая малоберцовая, третичная малоберцовая, экстензоры бедра, большая (средняя) ягодичная мышца, грушевидная
S2	длинный флексор большого пальца, флексоры пальцев (II-Y)

ABDOMINALS

Питание – витамин Е, концентрат двенадцатиперстной кишки или нуклепротеиновый экстракт

Меридиан – тонкий кишечник

Орган — тонкий кишечник

QUADRATUS LUMBORUM

Иннервация – поясничное сплетение Т12, L1, 2, 3

Питание – витамины Е, С и А. Меридиан – толстый кишечник. Орган – аппендикс

QUDRICIPS – Rectus Femoris

Иннервация – бедренный нерв, L1, 2, 3

Питание – витамины Д.

Меридиан – тонкий кишечник. Орган – тонкий кишечник

ADDUCTORS

Иннервация – бедренный и запирательный нервы

Питание – экстракт эндокринных желез, витамин Е, омега 3, цинк

Меридиан – перикард. Орган – репродуктивные органы

TIBIALIS ATERIOR

Питание –витамин A

Меридиан – мочевой пузырь

Орган – мочевой пузырь

TIBIALIS POSTERIOR

Иннервация – большеберцовый нерв, L4, 5, S1

Питание –витамин A Меридиан – желчный пузырь.

Орган – желчный пузырь

EXTENSOR HALLUCIS LONGUS/BREVIS

Иннервация

длинный разгибатель 1-го пальца — малоберцовый нерв, L4, 5, S1

короткий разгибатель 1-го пальца — малоберцовый нерв, L5, S1

PERONEUS LONGUS/BREVIS

Питание – кальций, комплекс витамина В, избегать чавелевых кислот (ревент, шпинат)

Меридиан – мочевой пузырь.

Орган – мочевой пузырь

PERONEUS TETRIS

FLEXOR HALLICIS LONGUS

Иннервация: Longus — Большеберцовый нерв, L5, S1,2.

Brevis — Большеберцовый нерв, L5 S1.

Тестирование: Давление оказывается на последнее сочленение большого пальца в попытке произвести разгибание в суставе.

Питание: Сырокостный концентрат. Меридиан: Circulation sex.

Орган: Ни один из имеющихся, однако отмечены корреляции с синдромом тарзального туннеля.

FLEXOR DIGITORUM BREVIS

АЛГОРИТМ ЛЕЧЕНИЯ КОМПРЕССИИ КОРЕШКОВ

1. Расположение тела пациента в направлении движения, провоцирующем слабость иннервирующих мышц.

2. Определение максимальной болезненности одного из остистых отростков исследуемого позвоночного двигательного сегмента.

3. Устранение категорий таза;

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

4. Повышение внутричерепного давления;

• тестирование сильной индикаторной мышцы (экстензоры бедра)

• ягулярная компрессия — слабость экстензоров бедра указывает на сторону для воздействия на сакротуберальную связку

5. Растяжение сакротуберальной связки в направлении уменьшающем боль в области ключично — вертебральной связки в сочетании с ягулярной компрессией и выполнением 4-5 глубоких дыхательных движений.

6. Коррегирование остальных дисфункций таза в следующей последовательности:

• устранение — дисфункции крестца, позвоночника;

• сублюксации L5-C1, L4-C2, L3-С3

7. Устранение дисфункций соответствующего ПДС:

• исходное расположение пациента в направлении ротации и латерофлексии уменьшающих слабость мышцы;

• проведение линейного толчка кранио-вентро-латерально или каудо-дорзо-латерально (с учетом rebaund — mechanizm)

8. Повторное тестирование силы иннервирующих мышц и их реакции на провокацию.

АЛГОРИТМ ДИАГНОСТИКИ ФУНКЦИОНАЛЬНОЙ ПАТОЛОГИИ ПРИ НЕОПТИМАЛЬНОЙ ДИНАМИКЕ.

(Среди провоцирующих факторов преобладает ходьба, движения).

А. Визуально определяется:

• основное направление движения, провоцирующее боль.

• локализация мышцы-агоннста выполняемого моторного паттерна, включающейся в движение с опозданием (диагностика ее функциональной слабости)

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

В. Пальпаторно определяется:

• место расположения положительной терапевтической локализации.

С. Методом провокации определяется:

• необходимость воздействия (физического, химического, эмоционального).

9. ХИМИЧЕСКАЯ СОСТАВЛЯЮЩАЯ ЗДОРОВЬЯ

Критерии нормореакции

Отсутствие фугкционально расслабленных мышц. Отсутствие гипертоничности мышц — ТЛ на точке К 27.

не ослабляет индикаторную мышцу Отсутствие аллергических реакций.

Критерии химических функциональных нарушений в организме

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

Мышца	Вещества
дельтовидная	витамин С, РНК
мышца, напрягающая широ­кую фасцию бедра	железо, ацидофилин, бифидобактерии, лактобактерии
экстензоры бедра	витамин Е. кальций, бетаин
ключичная порция большой, грудной мышцы	витамин В, B12
широчайшая мышца спины	витамин А
трапециевидная	витамин А, С, кальций
подлопаточная	витамин В., С, Е, калий, магний
четырехглавая	витамины группы В, витамин D
малоберцовые	витамины группы В, кальций
подвздошно-поясничная	витамины А, Е
грушевидная	витамины А, Е
ягодичные	витамин Е
малая круглая	йод, марганец, железо, витамин А, селен, водоросли
портняжная	витамин С, В5, жень­шень, цинк, иногда — NaCI
подколенная	витамин А
грудинная порция большой грудной мышцы	витамин А, желчь
большая круглая	К, Na, цинк, водоросли
надостная	РНК

АЛГОРИТМ ДИАГНОСТИКИ НАРУШЕНИЙ ХИМИЧЕСКИХ ПРОЦЕССОВ

1. Определение мышцы-индикатора.

2. Проведение химической провокации:

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

3. Поиск патогенетически значимого органа.

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

5. Диагностика причины (механической, химической, энергетической), вызвавшей нарушение органа и ее коррекция.

Зона для тестирования химических веществ

АЛГОРИТМ ТЕСТИРОВАНИЯ НА НЕДОСТАТОК ВЕЩЕСВ

1. Определение функционально слабой или гипертоничной мышцы

2. Химическая провокация

-химическое вещество располагается на животе или производится диагностика по зонам Ридлера

-устраняется функциональная слабость мышцы — вещество в недостатке

-определение дозы и кратности применения данного вещества

3. Определение органа, нарушающего усвоение вещества

— терапевтическая локализация на внутренние органы появление функциональной слабости — подтверждение патогенетической значимости органа

4. Поиск причины функционального нарушения органа

-структурные нарушения (дисфункция, диспозия, нарушения крово-лимфообращения)

-химические — потребность в ферментах, витаминах, минералах

— энергетические (меридианный, эмоциональный дисбаланс)

АЛГОРИТМ ТЕСТИРОВАНИЯ НА ИЗБЫТОК ВЕЩЕСТВ (ТОКСИЧНОСТЬ)

1. Определение индикаторной мышцы

2. Химическая провокация

— химическое вещество (витамины, минералы) располагается на живете под южным полюсом магнита

— диагностика зон Риддлера

— ослабление мышцы-индикатора — вещество в избытке

3. Определение патогенетического детоксифицирующего органа с одновременно проводимой терапевтической локализацией на выделительных органах. Усиление мышцы-индикатора — подтверждение патогенетической значимости органа.

4. Поиск причины функционального нарушения органа.

— структурные нарушения (дисфункция, диспозиция, нарушение крово-лимфообращения)

— химические нарушения (потребность в добавках — витамины, минералы, интоксикации, инфекции)

— энергетические нарушения (меридианный дисбаланс, чакры, эмоции)

ДИАГНОСТИКА ТОКСИЧЕСКИХ ВЕЩЕСТВ И ИНФЕКЦИИ.

1. Диагностика дисфункции органов детоксикации (печень, почки, толстый кишечник, легкие)

— функциональная слабость ассоциированной мышцы

— слабость мышцы-индикатора при терапевтической локализации на органе

2. Коррекция причины дисфункции органа

3. Химическая провокация

— расположение химических провокаторов на коже под южным полюсом магнита (кофеин, парацетомол, фенол, ацетальдегид, перекись водорода, глютамин)

— ослабление индикаторной мышцы — признак нарушения определённого этапа детоксикации

4. Коррекция

— биомеханические нарушения

— химические нарушения

— энергетические нарушения

ВЛИЯНИЕ ХИМИЧЕСКИХ НАРУШЕНИЙ НА ДРУГИЕ СОСТАВЛЯЮЩИЕ ЗДОРОВЬЯ.

1. Влияние на энергетические процессы.

— память о перенесенном химическом повреждении (печень, толстый кишечник, почки, легкие)

— канально-меридианный дисбаланс (опосредованно через дисфункцию висцерального органа, дисфункцию мышц на пути следования меридиана)

— чакральные нарушения (опосредованно через органы, расположенные в области чакр)

2. Влияние на биомеханику

— слабость мышц, вследствие дефицита витаминов, минералов

— нарушение образования соединительной ткани (хрящи, надкостница, связки, кости, мышцы, фасции)

— дефицит аминокислот, витаминов, минералов, интоксикации

— висцеральные органы (интоксикация, дефицит)

— на нервную регуляцию (интоксикация, дефицит)

Варианты нарушений биохимических процессов.

I. Недостаток веществ (витаминов, минералов, аминокислот, полиненасыщенных жирных кислот).

1. Недостаток поступления.

2. Нарушение процессов всасывания.

3. Нарушение процессов усвоения.

4. Нарушения транспортировки в системе лимфы или крови.

5. Нарушение поступления к месту назначения.

6. Патологическое усиление выведения.

II. Избыток веществ (Vitt A, Zn, Си, К, Мд, Са, дисбаланс полиненасыщенных жирных кислот).

1. Избыточное поступление.

2. Нарушение процессов выведения или эллеминации.

III. Наличие токсических веществ.

1. Химикаты (нитраты, пестициды, гербециды, консерванты продуктов).

2. Токсические металлы (Нg-зубная амальгама, рыба в зоне промстоков; Al-тара для напитков, аэрозоли, фармпрепараты; Cd-яркие красители).

3. Радиоактивные вещества, жёсткое излучение.

4. Аллергии.

IV. Инфицированность (острая и хроническая).

1. Грибковая.

2. Вирусная.

3. Паразитарная.

4. Бактериальная.

V. Память о перенесенной травме (общая и местная).

1. Структурная.

2. Химическая.

3. Биологическая.

4. Эмоциональная.

5. Клеточная.

НАРУШЕНИЯ ОБМЕНА ОСНОВНЫХ НУТРИЕНТОВ

ОСНОВНЫЕ ПРИЧИНЫ НАРУШЕНИЯ ОБМЕНА АМИНОКСИЛОТ, УГЛЕВОДОВ.

1. Нарушение работы энтероцитов

1.1. Химические нарушения

— воспаление тонкого кишечника (инфекция, бактерии)

1.2. Биомеханические нарушения

— спазм висцеральной мускулатуры, спаечный процесс;

— нарушение кровоснабжения

— нарушение лимфооттока

(ассоциированные мышцы — прямая мышца бедра и мышцы живота)

1.3. Энергетические нарушения

— меридиан тонкого кишечника

— нарушение желудочной чакры

2. Нарушение работы поджелудочной железы (цинк, витамины гр. В)

2.1. Химические нарушения

— токсические нарушения

— инфекционные нарушения (вирусы)

2.2. Биомеханические нарушения

— нарушение крово-лимфообращения

— дисфункция, диспозиция органа

(ассоциированные мышцы: широчайшая мышца спины, трехглавая мышца плеча; функциональный блок — Thvi-vii)

2.3. Энергетические нарушения

— меридиан селезенки — поджелудочная железа

— нарушение желудочной чакры

ОСНОВНЫЕ ПРИЧИНЫ НАРУШЕНИЯ МЕТАБОЛИЗМА ЖИРОВ

1. Нарушение работы энтероцитов

2. Нарушение работы поджелудочной железы

3. Нарушение работы печени, желчевыводящих путей

— химические: дефицит витамина С, таурин, фосфотидилхолин, полиненасыщенные жиры

— токсические

— инфекционные

— биомеханические (дисфункция, диспозиция желчного пузыря, сфинктера Одди, спазм диафрагмы

4. Ассоциированные мышцы: большая грудная мышца, ромбовидная мышца; функциональный блок Thiv

5. Энергетические дисфункции: нарушение меридиана печени; нарушение желудочной и сердечной чакры; эмоции (гнев)

Использование точек начала и конца меридианов диагностике химических нарушений

Lg19 тирозин, Be, фолиевая кислота, Fe, Сu, тирозиназа, В3

V1 триптофан, фолиевая кислота, Fe, Be, В3

VB1 холин, пантотеновая кислота

GI20 глицин, В2, В6, фолиевая кислота, Mn, Zn, глютаминовая кислота, пантотеновая кислота

TR23 нарушение углеводного обмена, B6, B5, C, Zn, Сu, Сг, Fe, тирозиназа, фолиевая кислота

Е1 гистамин, кинин, аргинин, пролин, глицин,серин, фенилаланин, Вб, Zn

Связь определённых мышц с нутриентами

1. Tuaмин (B1)     2. Рибофлавин (В2) 3. Ниацин (Вз)   4. Пиридоксин 5. Фолиевая кислота (Р) 6. Витамин А 7. Витамин С 8. Zn 9. К 10. Сr 11. Fe

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

ДИАГНОСТИКА ДЕФИЦИТА АМИНОКИСЛОТ

Использован материал Семинара Шелдона С. Дила, проведенного в Санкт-Петербурге в 1998 году.

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

Соответствие недостатка аминокислот дисфункции акупунктурной системы.