Последовательность и скачок линейного кода ( LCSAJ ) в широком смысле - это метод анализа программного обеспечения, используемый для идентификации структурных единиц в тестируемом коде. Его основное использование - с динамическим анализом программного обеспечения, чтобы помочь ответить на вопрос «Сколько тестов достаточно?». [1] Динамический анализ программного обеспечения используется для измерения качества и эффективности данных тестирования программного обеспечения, где количественная оценка выполняется с точки зрения структурных единиц тестируемого кода. При использовании для количественной оценки структурных единиц, задействованных в заданном наборе данных испытаний, динамический анализ также называется анализом структурного покрытия .
В более узком смысле LCSAJ - это четко определенная линейная область программного кода. В этом смысле LCSAJ также называется JJ-path , что означает путь от перехода к переходу .
История [ править ]
Метод анализа LCSAJ был разработан профессором Майклом Хеннеллом для оценки качества математических библиотек, от которых зависели его исследования в области ядерной физики в Ливерпульском университете . [2] [3] Позже профессор Хеннелл основал компанию Liverpool Data Research Associates (LDRA) с целью коммерциализации испытательного стенда программного обеспечения, созданного для этой работы, в результате чего был создан продукт LDRA Testbed .
Представленный в 1976 году, LCSAJ [4] теперь также называется путем перехода от одного к другому (JJ-путь). [5] Его также называют вкладом Ливерпуля в глупые сокращения и анекдоты. [ необходима цитата ]
Определение и характеристики LCSAJ как кодовой области [ править ]
LCSAJ - это фрагмент программного кода, состоящий из последовательности кода (линейной кодовой последовательности), за которой следует переход потока управления, и состоит из следующих трех элементов: [6]
- начало линейной последовательности исполняемых операторов
- конец линейной последовательности
- целевая линия, на которую передается поток управления в конце линейной последовательности.
В отличие от (максимальных) базовых блоков , LCSAJ могут перекрываться друг с другом, потому что прыжок (выход) может происходить в середине LCSAJ, в то время как он не разрешен в середине базового блока. В частности, условные переходы генерируют перекрывающиеся LCSAJ: один, который проходит до того места, где условие оценивается как ложное, а другой, который заканчивается переходом, когда условие оценивается как истинное (пример, приведенный ниже в этой статье, иллюстрирует такой случай). Таким образом, каждый базовый блок является LCSAJ, но LCSAJ может состоять более чем из одного базового блока. Согласно монографии 1986 года, LCSAJ обычно были в четыре раза больше, чем базовые блоки. [7]
Формальное определение LCSAJ может быть дано в терминах основных блоков следующим образом: [8]
последовательность из одного или нескольких последовательно пронумерованных базовых блоков, p , ( p +1), ..., q , кодовой единицы, за которой следует переход потока управления либо из кода [unit], либо к базовому нумерованному блоку r , где r ≠ ( q +1), и либо p = 1, либо существует переход потока управления к блоку p из некоторого другого блока в блоке. (Базовый блок, к которому может быть выполнен такой переход потока управления, называется целью перехода [LCSAJ].)
Согласно учебнику Йоргенсена 2013 года, за пределами Великобритании и литературы ISTQB , то же понятие называется DD-path . [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:
#include <stdlib.h>#include <string.h>#include <math.h>#define MAXCOLUMNS 26#define MAXROW 20#define MAXCOUNT 90#define ИТЕРАЦИИ 750int main ( пусто ){ int count = 0 , итоги [ MAXCOLUMNS ], val = 0 ; MemSet ( итоговые , 0 , MAXCOLUMNS * SizeOf ( INT )); count = 0 ; while ( count < ИТЕРАЦИИ ) { val = abs ( rand ()) % MAXCOLUMNS ; итоги [ val ] + = 1 ; если ( итоги [ Val ] > MAXCOUNT ) { итоги [ val ] = MAXCOUNT ; } count ++ ; } возврат ( 0 );}Из этого кода следует полный список троек LCSAJ для этого кода.
| Номер LCSAJ | Стартовая линия | Финишная черта | Перейти к строке |
|---|---|---|---|
| 1 | 10 | 17 | 28 год |
| 2 | 10 | 21 год | 25 |
| 3 | 10 | 26 год | 17 |
| 4 | 17 | 17 | 28 год |
| 5 | 17 | 21 год | 25 |
| 6 | 17 | 26 год | 17 |
| 7 | 25 | 26 год | 17 |
| 8 | 28 год | 28 год | −1 |
Из этого примера можно увидеть, что базовый блок, идентифицированный тройкой LCSAJ, может охватывать точку принятия решения, отражающую условия, которые должны быть выполнены для выполнения LCSAJ. Например, LCSAJ 2 для приведенного выше примера включает whileоператор, в котором условие (count < ITERATIONS)оценивается как истинное.
Каждая строка кода имеет связанную с ней "плотность" LCSAJ; строка 17, например, появляется в 6 уникальных LCSAJ, т. е. имеет плотность LCSAJ, равную 6. Это полезно при оценке ремонтопригодности кода; Если строка кода должна быть изменена, то плотность указывает, сколько LCSAJ будет затронуто этим изменением.
Уровень покрытия TER3 = 100% будет достигнут, если используемые тестовые данные вызывают выполнение каждого из этих LCSAJ хотя бы один раз.
Ссылки [ править ]
- ^ MAHennell, D.Hedley и MRWoodward, "Количественная оценка эффективности тестов программ на Алголе 68", Труды конференции Strathclyde ALGOL 68 1977, стр. 36 - 41, ISSN 0362-1340
- ^ MA Hennell, Экспериментальный стенд для численного программного обеспечения. {Я}. {Fortran} , The Computer Journal 21 (4): 333–336, @nov, 1978.
- ^ MA Хеннелл и Д. Хедли, экспериментальный стенд для численного программного обеспечения. {II}. {АЛГОЛ 68} , Компьютерный журнал 22 (1): 53–56, @feb, 1979
- ^ MA Hennell, MRWoodward и D.Hedley, "On program analysis", Information Processing Letters, 5 (5), стр. 136 - 140, 1976 г.
- ^ MR Woodward, MA Hennell, «О взаимосвязи между двумя критериями покрытия потока управления: всеми JJ-путями и MCDC», Информационные и программные технологии 48 (2006), стр. 433–440
- ^ MAHennell, D.Hedley и IJRiddell, "Assessing a Class of Software Tools", Proceedings of the 7th International Conference on Software Engineering March 1984, pp. 266-2777. ISSN 0270-5257
- ^ Мартин А. Оулд и Чарльз Анвин, изд. (1986). Тестирование в разработке программного обеспечения . Издательство Кембриджского университета. п. 102. ISBN 978-0-521-33786-1.
- ^ Groenda, Henning (2013). Сертификация характеристик производительности программных компонентов . КИТ Научное издательство. С. 198–200. ISBN 978-3-7315-0080-3.цитата из Yates, DF (2009). «Включение, включение, JJ-пути и структурированное тестирование путей: исправление». Тестирование, проверка и надежность программного обеспечения . 19 (3): 199–213. DOI : 10.1002 / stvr.400 .
- ^ Пол С. Йоргенсен (2013). Тестирование программного обеспечения: подход мастера, четвертое издание . CRC Press. п. 136. ISBN. 978-1-4665-6068-0.
- ^ JRBrown, «Практическое применение автоматизированных программных средств», отчет TRW № TRW-SS-72-05, представленный на WESCON, 1972 г.
- ^ MRWoodward, D.Hedley и MAHennell, «Опыт анализа путей и тестирования программ», IEEE Transactions on Software Engineering, Vol. 6, No. 3, pp. 278 - 286, май 1980 г.
- ^ Вопросы программного обеспечения при сертификации бортовых систем и оборудования - RTCA / DO-178B, RTCA Inc., Вашингтон, округ Колумбия, декабрь 1992 г.
