Методологические основы


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



Download 2,39 Mb.
bet200/293
Sana26.06.2022
Hajmi2,39 Mb.
#705514
TuriУчебник
1   ...   196   197   198   199   200   201   202   203   ...   293
Bog'liq
Липаев В В Программная инженерия Методологические основы 2006

зон реальной вероятности ошибки, допускаемой квалифицированным программистом первично в каждой дуге графа программы. Эксперимен­тально установлено, что для слабо структурированных программ число ошибок, выявляемых в процессе тестирования программных модулей, со­ставляет около одного процента числа строк текста этих модулей. Для программ обработки информации и управления число условных перехо­дов составляет около 10% числа строк в программе, т.е. ветвление в про­грамме происходит в среднем после исполнения 10 строк текста линейных участков. Следовдтельно, порядка 10% линейных участков (или дуг в гра­фе) программных модулей могут содержать первоначально ошибки перед тестированием, что соответствует вероятности 0,1.

  • Использование правил структурного программирования, специфика­ций требований на модули и группы программ, а также современной тех­нологии программирования позволяет снизить первичную вероятность ошибок приблизительно на порядок, т.е. до уровня qtJ ~ 0,01. Поэтому оценивание стратегий тестирования и достигаемой при этом корректности целесообразно проводить в диапазоне qtJ = 0,1—0,01, соответствующем практически наихудшим и наилучшим значениям вероятностей ошибок в дуге до тестирования.

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

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

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

    1. Тестирование обработки потоков данных
      программными компонентами


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

    • Наборы действий по преобразованию исходных данных в выходные могут быть формализованы диаграммами потоков данных (DFD — Data Flow Diagrams). Для этого применяется система графических элементов, содержащих квадратики с описаниями сущностей и номерами, а также соединяющие их стрелки процессов:

    • внешние сущности — объекты, являющиеся источниками или по­требителями информации, идентифицируемые их содержанием и номерами;

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

    • накопители объектов или данных, где временно они размещаются на хранение;

    • потоки данных — информация, передаваемая от источника к по­требителю.

    • Для построения DFD-диаграмм формализованы синтаксис и семанти­ка графических элементов: отражающих движение объектов — процеду­ры программ; описаний внешних сущностей — источников и потребите­лей данных; их хранения. Рекомендуется вначале определять набор дей­ствий, описывающих, что должны выполнять процедуры программы. Затем строить модель окружения — внешние сущности, порождающие процес­сы и специфическое поведение при обработке данных. Наборы простей­ших DFD-диаграмм — операторов программы, объединяются в иерархи­ческие структуры, отражающие потоки данных в программных модулях или функциональных компонентах из ряда модулей.

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

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

    • полностью изменяющей область определения и значения результа­тов обработки;

    • изменяющей результаты в пределах некоторой ограниченной, пра­вильной области определения.
  • 1   ...   196   197   198   199   200   201   202   203   ...   293




    Ma'lumotlar bazasi mualliflik huquqi bilan himoyalangan ©hozir.org 2024
    ma'muriyatiga murojaat qiling

    kiriting | ro'yxatdan o'tish
        Bosh sahifa
    юртда тантана
    Боғда битган
    Бугун юртда
    Эшитганлар жилманглар
    Эшитмадим деманглар
    битган бодомлар
    Yangiariq tumani
    qitish marakazi
    Raqamli texnologiyalar
    ilishida muhokamadan
    tasdiqqa tavsiya
    tavsiya etilgan
    iqtisodiyot kafedrasi
    steiermarkischen landesregierung
    asarlaringizni yuboring
    o'zingizning asarlaringizni
    Iltimos faqat
    faqat o'zingizning
    steierm rkischen
    landesregierung fachabteilung
    rkischen landesregierung
    hamshira loyihasi
    loyihasi mavsum
    faolyatining oqibatlari
    asosiy adabiyotlar
    fakulteti ahborot
    ahborot havfsizligi
    havfsizligi kafedrasi
    fanidan bo’yicha
    fakulteti iqtisodiyot
    boshqaruv fakulteti
    chiqarishda boshqaruv
    ishlab chiqarishda
    iqtisodiyot fakultet
    multiservis tarmoqlari
    fanidan asosiy
    Uzbek fanidan
    mavzulari potok
    asosidagi multiservis
    'aliyyil a'ziym
    billahil 'aliyyil
    illaa billahil
    quvvata illaa
    falah' deganida
    Kompyuter savodxonligi
    bo’yicha mustaqil
    'alal falah'
    Hayya 'alal
    'alas soloh
    Hayya 'alas
    mavsum boyicha


    yuklab olish