Шпаргалка по "Программированию и компьютерам"

 

49. Контроль программного модуля.

Применяются в настоящее время следующие методы контроля программного модуля:

1. Статическая  проверка текста модуля.

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

2. Сквозное  прослеживание.

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

3. Доказательство  свойств программного модуля.

 

50. Тестирование и отладка программного модуля: основные понятия.

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

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

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

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

2. Поиска  места ошибки в программном  средстве или его документации.

3. Редактирование  кода или описания программного  средства с целью устранения  найденной ошибки.

В самом процессе отладки программного средства выделяют 2 основных вида тестирования:

1. Тестирование  по отношению к спецификациям.

2. Тестирование  по отношению к текстам программ.

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

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

30% тестирование  по спецификациям и 70% - по тексту  программ.

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

 

51. Принципы и виды отладки программного модуля.

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

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

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

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

 

52. Основные «заповеди» отладки программного модуля.

«Заповеди» теории отладки:

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

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

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

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

5. Каждый  модуль подключайте к программе  только один раз. Никогда не  изменяйте код программы чтобы  облегчить ее тестирование.

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

 

53. Автономная отладка программного средства.

Выделяются 2 основные стратегии:

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

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

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

Особенность данного тестирования – при проведении тестирования любого модуля необходимо налаживать имитацию сопряженных модулей.

При нисходящем тестировании перекос идет в другую сторону.

Недостатки нисходящего тестирования:

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

Достоинства:

1) малый  объем тестировочного программирования

2) нет  необходимости учитывать сопряжения  других модулей

Также нисходящее тестирование в литературе носит название тестирования окружающей среды.

 

54. Комплексная отладка программного средства.

Комплексное тестирование проводится после автономного тестирования каждого модуля программного средства.

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

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

Тестирование внешних функций. Целью тестирования является поиск расхождений между функциональной спецификацией и совокупностью программ ПС.

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

Тестирование документации по применению ПС. Целью тестирования является поиск несогласованности документации по применению и совокупностью программ ПС, а также неудобств применения ПС.

Тестирование определения требований к ПС. Целью тестирования является выяснение, в какой мере ПС не соответствует предъявленному определению требований к нему.

 

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

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

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

Тем не менее, в спецификации качества ПС могут быть дополнительные характеристики этих критериев:

1.Обеспечение завершенности  ПС.

2.Обеспечение точности ПС.

3.Обеспечение автономности ПС.

4.Обеспечение устойчивости ПС.

5.Обеспечение  защищенности ПС.

 

56. Обеспечение завершенности программного средства.

Завершенность ПС является общим примитивом качества ПС для выражения и функциональности и надежности ПС, причем для функциональности она является единственным примитивом.

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

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