線形コードシーケンスとジャンプ(LCSAJ)は、広義では、テスト対象コード内の構造単位を識別するために使用されるソフトウェア分析方法です。その主な用途は、動的ソフトウェア分析で「どの程度のテストで十分か」という質問に答えることです。[1]動的ソフトウェア分析は、ソフトウェアテストデータの品質と有効性を測定するために使用され、定量化はテスト対象コードの構造単位に関して実行されます。特定のテストデータセットによって実行される構造単位を定量化するために使用される場合、動的分析は構造カバレッジ分析 とも呼ばれます。
より狭い意味では、LCSAJ はプログラム コードの明確に定義された線形領域です。この意味で使用される場合、LCSAJ はJJ パス ( jump-to-jump path) とも呼ばれます。
歴史
LCSAJ分析法は、マイケル・ヘネル教授がリバプール大学での原子物理学研究で使用した数学ライブラリの品質評価を行うために考案されました。[2] [3] ヘネル教授は後に、この研究のために作成されたソフトウェアテストベッドを商品化するためにリバプールデータリサーチアソシエイツ(LDRA)社を設立し、 LDRAテストベッド製品を生み出しました。
1976年に導入されたLCSAJ [4]は、現在ではジャンプ・トゥ・ジャンプ・パス(JJパス)とも呼ばれています。[5]また、リバプールの愚かな頭字語とジョークへの貢献とも呼ばれています。[要出典]
コード領域としてのLCSAJの定義と特徴
LCSAJは、一連のコード(線形コードシーケンス)とそれに続く制御フロージャンプから構成されるソフトウェアコードパスフラグメントであり、次の3つの項目で構成されます。[6]
- 実行可能なステートメントの線形シーケンスの開始
- 線形シーケンスの終了
- 線形シーケンスの最後に制御フローが転送されるターゲット ライン。
(最大)基本ブロックとは異なり、LCSAJ は互いに重なり合うことができます。これは、基本ブロックの途中ではジャンプ(アウト)が許されないのに対し、LCSAJ の途中ではジャンプ(アウト)が許されるためです。特に、条件ジャンプは重なり合う LCSAJ を生成します。つまり、条件が偽と評価されるところまで実行される LCSAJ と、条件が真と評価されるジャンプで終了する LCSAJ です(この記事のさらに下の例は、このような発生を示しています)。1986 年のモノグラフによると、LCSAJ は通常、基本ブロックの 4 倍の大きさでした。[7]
LCSAJの正式な定義は、次のような基本ブロックで表すことができます。[8]
コード単位の1 つ以上の連続した番号の基本ブロックp、( p +1)、...、qのシーケンス。その後に、コード [単位] 外または番号rの基本ブロックへの制御フロー ジャンプが続きます。ここで、r ≠( q +1) であり、p =1 であるか、単位内の他のブロックからブロックpへの制御フロー ジャンプが存在するかのいずれかです。(このような制御フロー ジャンプを行うことができる基本ブロックは、[LCSAJ] ジャンプのターゲットと呼ばれます。)
ジョルゲンセンの2013年の教科書によると、英国とISTQBの文献以外では、同じ概念はDDパスと呼ばれています。[9] [疑わしい–議論する]
テスト有効性比率
カバレッジ分析メトリクスは、テストがどの程度達成されたかを測定するために使用されます。最も基本的なメトリクスは、実行されたステートメントの割合、テスト有効性比率1(TER1)です。[10]
より高レベルのカバレッジメトリクスも生成できる。具体的には、次のとおりである。[11]
これらのメトリックは純粋な階層構造を満たしており、TER3 = 100% が達成されると、TER2 = 100% および TER1 = 100% も達成されたことになります。
TER1 と TER2 の両方の指標は 1970 年代初頭に使用されていましたが、3 つ目の指標は 1970 年代後半に使用されました。TER1 = 100% を達成するための要件は、1992 年に MCDC (修正条件/決定範囲) 追加要件によって補足されるまで、DO-178 航空電子工学規格に最初に選択されたレベルでした。 [12]航空宇宙、電話、銀行など、他の多くのプロジェクトでは、TER3 = 100% というより高いレベルが義務付けられています。[要出典] TER3 を使用する際の実際的な問題の 1 つは、多くの LCSAJ が、それらに含まれる矛盾する条件のために実行できないことです。
例
次の C コードを検討してください。
#include <stdlib.h>
#include <文字列.h>
#include <math.h>
# MAXCOLUMNS 26 を定義します
# MAXROW 20 を定義します
#定義 MAXCOUNT 90
#define 反復 750
int main ( void )
{
int count = 0 、合計[ MAXCOLUMNS ]、val = 0 ;
memset (合計, 0 , MAXCOLUMNS * sizeof ( int ) );
カウント= 0 ;
while ( count <反復回数)
{
val = abs ( rand ()) % MAXCOLUMNS ;
合計[値] += 1 ;
if (合計[値] > MAXCOUNT )
{
合計[ val ] = MAXCOUNT ;
}
カウント++ ;
}
戻り値( 0 );
}
この例から、LCSAJ トリプルによって識別される基本ブロックは、LCSAJ を実行するために満たされていなければならない条件を反映して、決定ポイントにまたがる可能性があることがわかります。たとえば、上記の例の LCSAJ 2 には、while条件が(count < ITERATIONS)true と評価されるステートメントが含まれています。
各コード行には、LCSAJ の「密度」が関連付けられています。たとえば、行 17 は 6 つの固有の LCSAJ 内に出現します。つまり、LCSAJ 密度は 6 です。これは、コードの保守性を評価するときに役立ちます。コード行を変更する場合、密度はその変更によって影響を受ける LCSAJ の数を示します。
使用されるテスト データによってこれらの LCSAJ のそれぞれが少なくとも 1 回実行される場合、TER3 = 100% のカバレッジ レベルが達成されます。
参考文献
- ^ MAHennell、D.Hedley、MRWoodward、「Algol 68 プログラムのテストの有効性の定量化」、Strathclyde ALGOL 68 会議 1977 の議事録、36 ~ 41 ページ、ISSN 0362-1340
- ^ MA Hennell、「数値ソフトウェアの実験的テストベッド」。{I}。{Fortran}、The Computer Journal 21(4):333--336、@nov、1978
- ^ MA Hennell と D. Hedley、「数値ソフトウェアの実験的テストベッド」。{II}。{ALGOL 68}、The Computer Journal 22(1):53--56、@feb、1979
- ^ MA Hennell、MRWoodward、D.Hedley、「プログラム分析について」、Information Processing Letters、5(5)、pp. 136 – 140、1976年
- ^ MR Woodward、MA Hennell、「2 つの制御フロー カバレッジ基準の関係について: すべての JJ パスと MCDC」、情報およびソフトウェア技術 48 (2006) pp. 433–440
- ^ MAHennell、D.Hedley、IJRiddell、「ソフトウェア ツールのクラスの評価」、第 7 回国際ソフトウェア エンジニアリング会議の議事録、1984 年 3 月、266 ~ 277 ページ。ISSN 0270-5257
- ^ Martyn A. Ould および Charles Unwin 編 (1986)。ソフトウェア開発におけるテスト。ケンブリッジ大学出版局。p. 102。ISBN 978-0-521-33786-1。
- ^ Groenda, Henning (2013).ソフトウェアコンポーネントパフォーマンス仕様の認定。KIT Scientific Publishing。pp. 198–200。ISBN 978-3-7315-0080-3。Yates, DF (2009)からの引用。「包含、包含、JJ パス、構造化パス テスト: 救済策」。ソフトウェア テスト、検証、信頼性。19 (3 ) : 199–213。doi : 10.1002/stvr.400。
- ^ Paul C. Jorgensen (2013).ソフトウェアテスト: 職人のアプローチ、第 4 版。CRC プレス。p. 136。ISBN 978-1-4665-6068-0。
- ^ JRBrown、「自動化ソフトウェアツールの実用的応用」、TRW レポート番号 TRW-SS-72-05、1972 年 WESCON で発表
- ^ MRWoodward、D.Hedley、MAHennell、「プログラムのパス分析とテストの経験」、IEEE Transactions on Software Engineering、第6巻、第3号、278~286ページ、1980年5月
- ^ 航空機搭載システムおよび機器認証におけるソフトウェアの考慮事項 - RTCA/DO-178B、RTCA Inc.、ワシントン DC、1992 年 12 月
