Последовательность линейного кода и прыжок - Linear code sequence and jump

Последовательность линейного кода и прыжок (LCSAJ) в широком смысле - это метод анализа программного обеспечения, используемый для выявления структурных единиц в тестируемом коде. Его основное использование - с динамическим анализом программного обеспечения, чтобы помочь ответить на вопрос «Сколько тестов достаточно?».[1] Динамический анализ программного обеспечения используется для измерения качества и эффективности данных тестирования программного обеспечения, где количественная оценка выполняется с точки зрения структурных единиц тестируемого кода. При использовании для количественной оценки структурных единиц, выполняемых заданным набором тестовых данных, динамический анализ также называется анализ структурного покрытия.

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

История

Метод анализа LCSAJ был разработан профессором Майкл Хеннелл для выполнения оценки качества математических библиотек, в которых он ядерная физика исследования в Ливерпульский университет зависело.[2][3] Позже профессор Хеннелл основал Liverpool Data Research Associates (LDRA) для коммерциализации испытательного стенда программного обеспечения, созданного для этой работы, в результате чего Стенд LDRA товар.

Представленный в 1976 году, LCSAJ[4] теперь также называется траекторией перехода к скачку (JJ-path).[5] Его также называют вкладом Ливерпуля в глупые сокращения и анекдоты.[нужна цитата ]

Определение и характеристика LCSAJ как кодовой области

LCSAJ - это фрагмент программного кода, состоящий из последовательности кода (линейной кодовой последовательности), за которой следует переход потока управления, и состоит из следующих трех элементов:[6]

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

В отличие от (максимального) базовые блоки LCSAJ могут перекрываться друг с другом, потому что переход (выход) может происходить в середине LCSAJ, в то время как он не разрешен в середине базового блока. В частности, условные переходы генерируют перекрывающиеся LCSAJ: один, который проходит до того места, где условие оценивается как ложное, а другой, который заканчивается при переходе, когда условие оценивается как истинное (пример, приведенный ниже в этой статье, иллюстрирует такой случай). Таким образом, каждый базовый блок является LCSAJ, но LCSAJ может состоять более чем из одного базового блока. Согласно монографии 1986 года, LCSAJ обычно были в четыре раза больше, чем базовые блоки.[7]

Формальное определение LCSAJ может быть дано в терминах основных блоков следующим образом:[8]

последовательность из одного или нескольких последовательно пронумерованных базовых блоков, п, (п+1), ..., q, кодового блока, за которым следует переход потока управления либо из кода [unit], либо к базовому блоку с номером р, куда р≠(q+1), и либо п= 1 или существует переход потока управления в блок п из другого блока в блоке. (Базовый блок, к которому может быть выполнен такой переход потока управления, называется целью перехода [LCSAJ].)

Согласно учебнику Йоргенсена 2013 г., за пределами Великобритании и ISTQB литературе то же понятие называется DD-путь.[9][сомнительный – обсуждать]

Коэффициент эффективности теста

Метрики анализа покрытия используются для оценки результатов тестирования. Самая основная метрика - это доля выполненных заявлений, коэффициент эффективности теста 1 (TER1):[10]

Также могут быть созданы показатели покрытия более высокого уровня, в частности:[11]

Эти показатели удовлетворяют чистой иерархии, согласно которой при достижении TER3 = 100% следует, что TER2 = 100% и TER1 = 100% также были достигнуты.

Метрики TER1 и TER2 использовались в начале 1970-х годов, а третья датируется концом 1970-х годов. Требование для достижения TER1 = 100% было уровнем, изначально выбранным для стандарта авионики DO-178, пока он не был дополнен MCDC (модифицированное покрытие условий / решений ) дополнительное требование в 1992 г.[12] Более высокие уровни TER3 = 100% требуются для многих других проектов, включая аэрокосмическую, телефонную и банковскую.[нужна цитата ] Одна практическая проблема использования TER3 заключается в том, что многие LCSAJ никогда не могут быть выполнены из-за конфликтующих условий, которые они содержат.

Пример

Рассмотрим следующий код C:

 1 #включают    <stdlib.h> 2 #включают    <string.h> 3 #включают    <math.h> 4  5 #define MAXCOLUMNS 26 6 #define MAXROW 20 7 #define MAXCOUNT 90 8 #define ИТЕРАЦИИ 750 9 10 int главный (пустота)11 {12     int считать = 0, итоги[MAXCOLUMNS], вал = 0;13 14     мемсет (итоги, 0, MAXCOLUMNS * размер(int));15 16     считать = 0;17     пока ( считать < ИТЕРАЦИИ )18     {19         вал = пресс(ранд()) % MAXCOLUMNS;20         итоги[вал] += 1;21         если ( итоги[вал] > MAXCOUNT )22         {23             итоги[вал] = MAXCOUNT;24         }25         считать++;26     }27     28     возвращаться (0);29 30 }

Ниже приведен полный список троек LCSAJ для этого кода.

Номер LCSAJСтартовая линияФинишная чертаПерейти к строке
1101728
2102125
3102617
4171728
5172125
6172617
7252617
82828−1

Из этого примера можно увидеть, что базовый блок, идентифицированный тройкой LCSAJ, может охватывать точку принятия решения, отражающую условия, которые должны быть выполнены для выполнения LCSAJ. Например, LCSAJ 2 для приведенного выше примера включает пока заявление, где условие (количество <ИТЕРАЦИИ) оценивается как истина.

Каждая строка кода имеет связанную с ней "плотность" LCSAJ; строка 17, например, появляется в 6 уникальных LCSAJ, т. е. имеет плотность LCSAJ, равную 6. Это полезно при оценке ремонтопригодности кода; Если строка кода должна быть изменена, то плотность указывает, сколько LCSAJ будет затронуто этим изменением.

Уровень покрытия TER3 = 100% будет достигнут, если используемые тестовые данные вызывают выполнение каждого из этих LCSAJ хотя бы один раз.

Рекомендации

  1. ^ М. А. Хеннелл, Д. Хедли и М. Р. Вудвард, "Количественная оценка эффективности тестов программ на Алголе 68", Труды конференции Strathclyde ALGOL 68 1977, стр. 36 - 41, ISSN 0362-1340
  2. ^ М. А. Хеннелл, Экспериментальный стенд для численного программного обеспечения. {Я}. {Fortran}, Компьютерный журнал 21 (4): 333-336, @nov, 1978.
  3. ^ М. А. Хеннелл и Д. Хедли, Экспериментальный стенд для численного программного обеспечения. {II}. {АЛГОЛ 68}, Компьютерный журнал 22 (1): 53--56, @feb, 1979
  4. ^ М. А. Хеннелл, М. Р. Вудвард и Д. Хедли, "Об анализе программ", Информационные письма, 5 (5), стр. 136 - 140, 1976
  5. ^ М. Р. Вудворд, М. А. Хеннелл, «О взаимосвязи между двумя критериями покрытия потока управления: всеми JJ-путями и MCDC», Информационные и программные технологии 48 (2006), стр. 433–440
  6. ^ M.A.Hennell, D.Hedley и I.J.Riddell, "Assessing a Class of Software Tools", Proceedings of the 7th International Conference on Software Engineering March 1984, pp. 266 - 277. ISSN 0270-5257
  7. ^ Мартин А. Ульд и Чарльз Анвин, изд. (1986). Тестирование в разработке программного обеспечения. Издательство Кембриджского университета. п. 102. ISBN  978-0-521-33786-1.
  8. ^ Groenda, Хеннинг (2013). Сертификация характеристик производительности программных компонентов. КИТ Научное издательство. С. 198–200. ISBN  978-3-7315-0080-3. цитата из Йейтс, Д. Ф. (2009). «Включение, включение, JJ-пути и структурированное тестирование путей: исправление». Тестирование, проверка и надежность программного обеспечения. 19 (3): 199–213. Дои:10.1002 / stvr.400.
  9. ^ Пол К. Йоргенсен (2013). Тестирование программного обеспечения: подход мастера, четвертое издание. CRC Press. п. 136. ISBN  978-1-4665-6068-0.
  10. ^ Дж. Р. Браун, «Практическое применение автоматизированных программных средств», отчет TRW № TRW-SS-72-05, представленный на WESCON, 1972 г.
  11. ^ М. Р. Вудвард, Д. Хедли и М. А. Хеннелл, «Опыт анализа путей и тестирования программ», IEEE Transactions on Software Engineering, Vol. 6, No. 3, pp. 278 - 286, май 1980 г.
  12. ^ Рекомендации по программному обеспечению при сертификации бортовых систем и оборудования - RTCA / DO-178B, RTCA Inc., Вашингтон, округ Колумбия, декабрь 1992 г.