Лекция "Этапы разработки программного обеспечения. способы отладки и тестирования по"

  • Лекции
  • docx
  • 14.03.2017
Публикация на сайте для учителей

Публикация педагогических разработок

Бесплатное участие. Свидетельство автора сразу.
Мгновенные 10 документов в портфолио.

На первом этапе первичным документом является постановка задачи, объединяющая: • общую характеристику задачи (назначение, экономическая эффективность, структура объектов); • описание входных данных (структура и способ поступления); • описание выходных данных; • существующие к данному моменту алгоритмы получения выходных данных на основе входных; • источники разработки (откуда появилась вся информация). Результатом первого этапа является техническое задание, в котором, как правило, содержатся название системы, цели создания, характеристика области применения, требования к системе в целом (интерфейс, особые требования к отдельным модулям, безопасность, и т.д.), информационная база (структура базы данных, с которой будет взаимодействовать программная система), программное обеспечение (обоснование выбора языка программирования), техническое обеспечение, описание данных для тестирования.
Иконка файла материала билет 5 тема 2.docx
билет 5 тема 2 этапы разработки программного обеспечения. способы отладки и тестирования по Программное обеспечение (пакет программ) – большая группа взаимосвязанных и взаимодействующих  программ, предназначенных для решения любой задачи из конкретной области (например, для  моделирования технологических процессов, для выполнения графических работ).  Программы какого­либо пакета рассчитаны на совместное использование в различных комбинациях друг  с другом. Этапы разработки ПО можно представить в следующем виде:     На первом этапе первичным документом является постановка задачи, объединяющая: • общую характеристику задачи (назначение, экономическая эффективность, структура объектов); • описание входных данных (структура и способ поступления); • описание выходных данных; • существующие к данному моменту алгоритмы получения выходных данных на основе входных; • источники разработки (откуда появилась вся информация). Результатом первого этапа является техническое задание, в котором, как правило, содержатся название  системы, цели создания, характеристика области применения, требования к системе в целом (интерфейс, особые требования к отдельным модулям, безопасность, и т.д.), информационная база (структура базы  данных, с которой будет взаимодействовать программная система), программное обеспечение  (обоснование выбора языка программирования), техническое обеспечение, описание данных для  тестирования. На основании технического задания формируются спецификации – описание количества и режимов  работы модулей, их взаимодействия.На этапе проектирования разрабатываются алгоритмы, задаваемые спецификациями, и формируется  общая структура будущей программы путем детальной проработки последовательности ее действий. Для разработки алгоритмов сложных программ используется метод пошаговой детализации, при котором процесс преобразования исходных данных в результат вначале представляется в виде  последовательности небольшого числа простых этапов (задач). На следующем шаге задачи разбиваются  на последовательность подзадач следующего уровня и т.д. Детализация заканчивается, когда каждый  отдельный этап может быть записан на выбранном языке программирования, или представляет собой  известную задачу, для которой уже имеется готовая программа. Формальное описание алгоритмов  осуществляется, например, с использованием языка схем или псевдокода. Кодирование представляет собой реализацию разработанных алгоритмов, составление по ним текстов  программы с использованием конкретного языка программирования. Включает процесс трансляции –  перевода программы в последовательность машинных команд (машинный код). При автономном тестировании каждый модуль проверяется отдельно. При этом программная среда  модуля имитируется с помощью программы управления тестированием, содержащей фиктивные  программы вместо реальных подпрограмм, к которым имеется обращение из данного модуля. При комплексном тестировании производится совместная проверка групп программных компонентов. В процессе тестирования происходит оптимизация системы (разгрузка участков повторяемости – циклов, замена сложных операций на более простые, экономия памяти и т.д.). Большая часть расходов, затрачиваемых в течение жизненного цикла системы, приходится на  эксплуатацию и сопровождение. Причины выпуска новых версий (модификаций) ПО: • необходимость исправления ошибок, выявленных в процессе эксплуатации; • необходимость совершенствования, например, улучшения интерфейса или расширения состава,  выполняемых функций; • изменение среды (появление новых технических средств и/или программных продуктов).               Тестирование программного средства (ПС) ­ это процесс выполнения программ на некотором наборе  данных, для которого заранее известен результат применения или известны правила поведения этих  программ. Указанный набор данных называется тестовым или просто тестом. Тестирование программ  является одной из составных частей более общего понятия ­ «отладка программ». Под отладкой по­ нимается процесс, позволяющий получить программу, функционирующую с требующимися  характеристиками в заданной области изменения входных данных.  Процесс отладки включает:    действия, направленные на выявление ошибок (тестирование);   диагностику и локализацию ошибок (определение характера ошибок и их местонахождение);   внесение исправлений в программу с целью устранения ошибок. Из трех перечисленных видов работ самым трудоемким и дорогим является тестирование, затраты на  которое приближаются к 45  Невозможно гарантировать отсутствие ошибок в программе. В лучшем случае можно попытаться  показать наличие ошибок. Если программа правильно ведет себя для большого набора тестов, нет  оснований утверждать, что в ней нет ошибок. Если считать, что набор тестов способен с большой  вероятностью обнаружить возможные ошибки, то можно говорить о некотором уровне уверенности  (надежности) в правильности работы программы, устанавливаемом этими тестами. Сформулируем  следующее высказывание: если ваша цель ­ показать отсутствие ошибок, вы их найдете не слишком  много. Если же ваша цель ­ показать наличие ошибок, вы найдете значительную их часть.  Надежность невозможно внести в программу в результате тестирования, она определяется  правильностью этапов проектирования. Наилучшее решение проблемы надежности ­ с самого начала не  допускать ошибок в программе. Однако вероятность того, что удастся безупречно спроектировать  большую программу, мала. Роль тестирования состоит в том, чтобы определить местонахождение  немногочисленных ошибок, оставшихся в хорошо спроектированной программе тестирования достичь надежности плохо спроектированной программы безнадежны.  Тестирование оказывается довольно необычным процессом (поэтому и считается трудным), так как этот  процесс разрушительный. Ведь цель проверяющего (тестовика) ­ заставить программу сбиться.   % общих затрат на разработку ПС.    . Попытки с помощью                    ным (неэффективным).  тивным он является для самого автора     (формализация процесса  ного тестового прогона данных, необходимо знать ожидаемый результат. Таким  Программы, как объекты тестирования, имеют ряд особенностей, которые отличают процесс их  тестирования от общепринятого, применяемого при разработке аппаратуры и других технических  изделий. Особенностями тестирования ПС являются:    ствовать тестируемая программа;  отсутствие эталона (программы), которому должна соответ   высокая сложность программ и принципиальная невозможность исчерпывающего тестирования;   практическая невозможность создания единой методики тестирования тестирования) в силу большого разнообразия программных изделий (ПИ) по их сложности,  функциональному назначению, области использования и т.д.  Тестирование ­ это процесс многократного выполнения программы с целью выявления ошибок.  Целью тестирования является обнаружение максимального числа ошибок. Поэтому тестовый  прогон, в результате которого не выявлено ошибок, считается неудач Существуют несколько эмпирических правил проведения тестирования программ, обобщающих опыт  тестировщиков.  1. Процесс тестирования более эффективен, если проводится не автором программы. По своей сути  тестирование ­ это процесс деструктивный (разрушительный). Именно этим и объясняется, поче му  многие считают его трудным. Особенно трудным и малоэффек программы, так как после выполнения конструктивной части при проектировании и написания  программы, ему трудно перестроиться на деструктивный образ мышления и, создав программу, тут же  приступить к пристрастному выявлению в ней ошибок. Поэтому для проведения тестирования создаются  специальные группы тестирования. Это не означает, что программист не может тестировать свою  программу. Речь идет о повышении эффективности тестирования.  2. Необходимой частью тестового набора данных должно быть описание предполагаемых значений  результатов тестовых прогонов. Тестирование как процесс многократного выполнения программы  проводится на многочисленных входных наборах данных. Чтобы определить правильность полученных    в результате очеред образом, тестовый набор данных должен включать в себя два компонента: описание входных данных,  описание точного и кор сложно, а в некоторых случаях и невозможно реализовать на практике. Сложность его заключается в том, что при тестировании программы (модуля) необходимо для каждого входного набора данных рассчитать  вручную ожидаемый результат или найти допустимый интервал изменения выходных данных. Процесс  этот трудоемкий даже для небольших программ, так как он требует ручных расчетов, следуя логике  алгоритма программы. Из рассмотренного принципа, который трудно реализуем, но которого следует  придерживаться логически, вытекает следующий.  3. Необходимо изучить результаты каждого теста. Из практики следует, что значительная часть  обнаруженных ошибок могла быть выявлена в результате первых тестовых прогонов, но они были  пропущены вследствие недостаточно тщательного анализа их результатов.  4. Тесты для неправильных и непредусмотренных входных данных должны разрабатываться также  тщательно, как для правильных и предусмотренных. Согласно этому принципу при обработке данных,  выходящих за область допустимых значений, в тестируемой программе должна быть предусмотрена  диагностика в виде сообщений. Если сообще алгоритму отсутствует, и программа завершается аварийно или ведет себя непредсказуемо, то такая  программа не может считаться работоспособной и требует существенной доработки. Тестовые наборы  данных из области недопустимых входных значений обладают большей обнаруживающей способностью,  чем тесты, соответствующие корректным входным данным.  5. Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает  ли она того, чего не должна делать. Это утверждение логически вытекает из предыдущего. Необходимо  любую программу проверить на нежелательные побочные эффекты.  6. Следует тщательнее проверять те участки программ, где обнаруживается больше ошибок.  Утверждается, что вероятность наличия необнаруженных ошибок в какой­либо части программы  пропорциональна числу ошибок, уже обнаруженных в этой части. Возможно, что те части программы, где при тестировании обнаружено большее число ошибок, либо были слабо проработаны с точки зрения  системного анализа, либо разрабатывались программистами более низкой квалификации.  ректного результата, соответствующего набору входных данных. Этот принцип  ние о причине невозможности обработки по предложенному                                      Методы отладки программного обеспеченияДля локализации и установки точной природы ошибки в программе используют статические и  динамические методы отладки программ.  К статическим методамотносятся методы отладки, при которых не требуется выполнение  отлаживаемой программы на ЭВМ. Они обычно требуют больших усилий от программиста и  незначительных затрат машинного времени. Они универсальны и пригодны для отладки программ,  написанных на любом языке программирования и используемых на любой ЭВМ. Статические методы  включают:  ­ ручную прокрутку программы; ­ прокрутку    программы    программными   анализаторами   ( например,  компилятором);  автоматизированный анализ программы в этом случае проводится без выполнения ее на ЭВМ и поэтому  попадает в категорию «статических»; ­   коллективную проверку программ; ­   проверку программы программистом­технологом с целью выявления и исправления в ней  технологических ошибок. Экспериментально установлено, что в программах ручными методами удается обнаруживать от 30 до 70  % программных и алгоритмических ошибок из общего числа ошибок, выявленных при отладке. При этом  одновременно осуществляется доработка программ с целью улучшения их структуры, логики обработки  данных и для снижения сложности последующего автоматизированного тестирования на ЭВМ.  Динамические методысвязаны со значительным расходом машинного времени и, возможно, не  меньшими затратами труда программиста. В этом случае отладка программ происходит совместно с их  выполнением на ЭВМ. Динамические методы отладки программ, как правило, привязаны к конкретной  ЭВМ и к конкретному транслятору (компилятору).  К динамическим методам относятся:  ­   тестирование;  ­   поиск ошибок с использованием системных средств;  ­    отладка программы в интерактивном режиме. Важнейшее правило отладки: не делать следующего выхода на ЭВМ, пока не будет разобрана каждая  найденная ошибка. Из этого правила существует единственное исключение: если найдены 5—6 ошибок,  которые не дают эффекта, то можно сделать новый выход на машину (устранив эти ошибки), чтобы  получить эффект в чистом виде (если он есть),поскольку наложение нескольких ошибок иногда может  дать самый неожиданный результат.  Если программист исчерпал все возможности поиска ошибки, но не нашел ее, то как крайнее средство,  можно сделать выход на машину, ничего не изменив в программе, но добавив печати, выдающие значения  идентификаторов, участвующих в формировании неверного значения. И снова произвести анализ  полученных результатов. Квалификация программиста в области отладки определяется тем, сколько  информации об ошибках он сможет получить из одной выдачи ЭВМ. едостаточно выполнить проектирование и кодирование программного продукта, также необходимо  обеспечить его соответствие требованиям и спецификациям. Многократно проводимые исследования  показали, что чем раньше обнаруживаются те или иные несоответствия или ошибки, тем больше  вероятность их исправления и ниже его стоимость [4]. Современные технологии разработки ПО преду­ сматривают раннее обнаружение ошибок за счет выполнения контроля результатов всех этапов и стадий  разработки. На начальных этапах контроль осуществляют вручную или с использованием CASE­средств,  на последних ­ он принимает форму тестирования. Тестирование ­ это процесс выполнения программы, целью которого является выявление ошибок.  Никакое тестирование не может доказать отсутствие ошибок в сложном ПО, поскольку выполнение  полного тестирования становится невозможным и имеется вероятность, что остались невыявленные  ошибки. Соблюдение основных правил тестирования и научно обоснованный подбор тестов может  уменьшить их количество. Процесс разработки согласно современной модели жизненного цикла ПО  предполагает три стадии тестирования: автономное тестирование компонентов ПО; комплексное  тестирование разрабатываемого ПО; системное или оценочное тестирование на соответствие основным  критериям качества. Для повышения качества тестирования рекомендуется соблюдать следующие  основные принципы: предполагаемые результаты должны быть известны до тестирования; следует избегать тестирования программы автором; необходимо досконально изучать результаты каждого теста;необходимо проверять действия программы на неверных данных; необходимо проверять программу на неожиданные побочные эффекты на неверных данных. Вероятность наличия необнаруженных ошибок в части программы пропорциональна количеству ошибок  уже найденных в этой части. Удачным считают тест, который обнаруживает хотя бы одну ошибку.  Формирование набора тестов имеет большое значение, поскольку тестирование является одним из  наиболее трудоемких этапов создания ПО. Доля стоимости тестирования в общей стоимости разработки  возрастает при увеличении сложности ПО и повышении требований к их качеству. Существуют два принципиально различных подхода к формированию тестовых наборов: структурный и  функциональный. Структурный подход базируется на том, что известна структура тестируемого ПО, в  том числе его алгоритмы («стеклянный ящик»). Тесты строятся для проверки правильности реализации  заданной логики в коде программы. Функциональный подход основывается на том, что структура ПО  не известна («черный ящик»). В этом случае тесты строят, опираясь на функциональные спецификации.  Этот подход называют также подходом, управляемым данными, так как при его использовании тесты  строят на базе различных способов декомпозиции множества данных. Наборы тестов, полученные в  соответствии с методами этих подходов, объединяют, обеспечивая всестороннее тестирование ПО. Ручной контроль используют на ранних этапах разработки. Все проектные решения анализируются с  точки зрения их правильности и целесообразности как можно раньше, пока их можно легко  пересмотреть. Различают статический и динамический подходы к ручному контролю. При статическом  подходе анализируют структуру, управляющие и информационные связи программы, ее входные и  выходные данные. При динамическом ­ выполняют ручное тестирование (вручную моделируют процесс выполнения программы на заданных исходных данных). Исходными данными для таких проверок  являются: техническое задание, спецификации, структурная и функциональная схемы программного  продукта, схемы отдельных компонентов, а для более поздних этапов ­ алгоритмы и тексты программ, а  также тестовые наборы. Доказано, что ручной контроль способствует существенному увеличению  производительности и повышению надежности программ и с его помощью можно находить от 30 до 70 %  ошибок логического проектирования и кодирования. Основными методами ручного контроля являются:  инспекции исходного текста, сквозные просмотры, проверка за столом, оценки программ. В основе структурного тестирования лежит концепция максимально полного тестирования всех  маршрутов, предусмотренных алгоритмом (последовательности операторов программы, выполняемых  при конкретном варианте исходных данных). Недостатки: построенные тестовые наборы не  обнаруживают пропущенных маршрутов и ошибок, зависящих от заложенных данных; не дают гарантии,  что программа правильна. Другим способом проверки программ является функциональное тестирование: программа  рассматривается как «черный ящик», целью тестирования является выяснение обстоятельств, когда  поведение программы не соответствует спецификации. Для обнаружения всех ошибок необходимо  выполнить исчерпывающее тестирование (при всех возможных наборах данных), что для большинства  случаев невозможно. Поэтому обычно выполняют «разумное» или «приемлемое» тестирование,  ограничивающееся прогонами программы на небольшом подмножестве всех возможных входных данных.  При функциональном тестировании различают следующие методы формирования тестовых наборов:  эквивалентное разбиение; анализ граничных значений; анализ причинно­следственных связей;  предположение об ошибке. При комплексном тестировании используют тесты, построенные по методам эквивалентных классов,  граничных условий и предположении об ошибках, поскольку структурное тестирование для него не при­ менимо. Одним из самых сложных является вопрос о завершении тестирования, так как невозможно  гарантировать, что в программе не осталось ошибок. Часто тестирование завершают потому, что  закончилось время, отведенное на его выполнение. Его сворачивают, обходясь минимальным  тестированием [15], которое предполагает: тестирование граничных значений, тщательную проверку  руководства, тестирование минимальных конфигураций технических средств, возможности  редактирования команд и повторения их в любой последовательности, устойчивости к ошибкам  пользователя. После завершения комплексного тестирования приступают к оценочному тестированию, целью  которого является поиск несоответствий техническому заданию. Оценочное тестирование включаеттестирование: удобства использования, на предельных объемах, на предельных нагрузках, удобства  эксплуатации, защиты, производительности, требований к памяти, конфигурации оборудования,  совместимости, удобства установки, удобства обслуживания, надежности, восстановления,  документации, процедуры. Отладка ­ это процесс локализации (определения оператора программы, выполнение которого вызвало  нарушение вычислительного процесса) и исправления ошибок, обнаруженных при тестировании ПО. Для  исправления ошибки необходимо определить ее причину. Отладка требует от программиста глубоких  знаний специфики управления используемыми техническими средствами, операционной системы, среды  и языка программирования, реализуемых процессов, природы и специфики ошибок, методик отладки и  соответствующих программных средств; психологически дискомфортна (нужно искать собственные  ошибки в условиях ограниченного времени); оставляет возможность взаимовлияния ошибок в разных  частях программы. Четко сформулированные методики отладки отсутствуют. Различают: синтаксические ошибки – сопровождаются комментарием с указанием их местоположения,  фиксируются компилятором (транслятором) при выполнении синтаксического и частично се­ мантического анализа; ошибки компоновки ­ обнаруживаются компоновщиком (редактором связей) при объединении модулей  программы; ошибки выполнения ­ обнаруживаются аппаратными средствами, операционной системой или  пользователем при выполнении программы, проявляются разными способами и в свою очередь делятся  на группы: ошибки определения исходных данных (ошибки передачи, ошибки преобразования, ошибки перезаписи и  ошибки данных); логические ошибки проектирования (неприменимый метод, неверный алгоритм, неверная структура  данных, другие) и кодирования (ошибки некорректного использования переменных, вычислений,  межмодульного интерфейса, реализации алгоритма, другие); ошибки накопления погрешностей результатов вычислений (игнорирование ограничений разрядной сетки и способов уменьшения погрешности). Отладка программы в любом случае предполагает обдумывание и логическое осмысление всей  имеющейся информации об ошибке. Большинство ошибок можно обнаружить по косвенным признакам  посредством тщательного анализа текстов программ и результатов тестирования без получения  дополнительной информации с помощью следующих методов: ручного тестирования (при обнаружении ошибки нужно выполнить тестируемую программу вручную,  используя тестовый набор, при работе с которым была обнаружена ошибка); индукции (основан на тщательном анализе симптомов ошибки, которые могут проявляться как неверные  результаты вычислений или как сообщение об ошибке); дедукции (вначале формируют множество причин, которые могли бы вызвать данное проявление ошибки, а затем анализируя причины, исключают те, которые противоречат имеющимся данным); обратного прослеживания (для точки вывода неверного результата строится гипотеза о значениях  основных переменных, которые могли бы привести к получению данного результата, а затем, исходя из  этой гипотезы, делают предположения о значениях переменных в предыдущей точке). Для получения дополнительной информации об ошибке выполняют добавочные тесты и используют  специальные методы и средства: отладочный вывод; интегрированные средства отладки;  независимые отладчики. Общая методика отладки программных продуктов, написанных для выполнения в операционных  системах MS DOS и Win32: 1 этап ­ изучение проявления ошибки; 2 этап – определение локализации ошибки; 3 этап ­ определение причины ошибки; 4 этап — исправление ошибки; 5 этап ­ повторное тестирование. Процесс отладки можно существенно упростить, если следовать основным рекомендациям структурного  подхода к программированию: программу наращивать «сверху­вниз», от интерфейса к обрабатывающим подпрограммам, тестируя ее по ходу добавления подпрограмм;выводить пользователю вводимые им данные для контроля и проверять их на допустимость сразу после  ввода; предусматривать вывод основных данных во всех узловых точках алгоритма (ветвлениях, вызовах  подпрограмм). Дополнительную информацию по теме можно получить в [1, 2, 4, 7, 9, 14, 15].