同時テスト

並行性テストおよび同時実行テストに関する研究^{[ 1 ]}および文献^{[ 2 ]}は、通常、同時実行コンピューティングを使用するソフトウェアおよびシステムのテストに焦点を当てています。その目的は、ほとんどのソフトウェアテストと同様に、同時実行コンピューティングを使用するソフトウェアシステムの動作とパフォーマンスを理解することであり、特に、通常の動作中のシステムまたはアプリケーションの安定性を評価することです。

プログラムの並行性に関する研究は1950年代に始まり^{[ 3 ]} 、プログラムの並行性テストに関する研究は1960年代に登場した^{[ 4 ]} 。並行性テストで明らかになる問題の例としては、共有メモリへの誤ったアクセスや、メッセージまたはスレッドの実行順序の予期しないものなどが挙げられる^{[ 5 ] : 2 [ 1 ]。}リソース競合の解決、スケジューリング、デッドロックの回避、優先順位の逆転、および競合状態も重要視されている^{[ 6 ] : 745}

並行性テストのアプローチは、限定的な単体テストレベルからシステムテストレベルまで多岐にわたる。^{[ 7 ]}

プログラム／ソフトウェアの並行性テストの研究および応用におけるアプローチとしては、以下のようなものがある。

• テストを1回実行します。^{[ 8 ] : 63}

これは非決定論的システムにおける並行性のテストには効果的ではないと考えられ、システム上で逐次的な非並行プログラムをテストすることと同等であった。

• 同じテストシーケンスを複数回実行する。^{[ 8 ]： 63}

非決定的なソフトウェア実行において、何らかの問題が発生する可能性が高いと考えられる。

これは後に非決定論的テストと呼ばれるようになった。^{[ 9 ]}

• 決定論的テスト。^{[ 8 ]： 63}

これは、システムを特定の状態に設定することで、コードが既知の順序で実行されるようにするための手法です。

• 到達可能性テスト^{[ 9 ] [ 10 ]}

指定された入力に対して同期シーケンスの組み合わせをテストする試み（共有変数へのアクセスが破損していないこと、つまり競合状態変数を効果的にテストする）。このシーケンスは通常、非決定的なテスト実行のために導出される。

• 構造的アプローチ／静的解析

コード構造の分析と静的解析ツール。

一例としてヒューリスティックアプローチ^{[ 11 ]が挙げられる。}

これにより、jlintなどのコードチェッカーの開発につながりました。^{[ 12 ]}並行バグに対する静的解析とコードチェッカーの研究と比較^{[ 13 ]}

静的コード解析ツール一覧も参照してください。

• マルチユーザーアプローチ

これは、複数のユーザーアクセス、つまり異なるユーザーまたはタスクを同時に処理することによって、プログラムの並行性をテストするアプローチです。^{[ 2 ] [ 6 ] : 745}

ソフトウェアとシステムの並行性のテストは、通常、システムを定義された制限を超えて負荷をかけることに関連するストレス テストと混同してはいけません。並行プログラムのテストでは、システムが定義された制限内で動作しているときに問題が発生する可能性があります。上記のアプローチのほとんどは、システムの過負荷に依存していません。一部の文献^{[ 6 ] : 745}では、並行性のテストはストレス テストの前提条件であると述べています。

2008年の研究^{[ 11 ]}では、いくつかのオープンソースソフトウェアのバグデータベースを分析しました。これは、並行処理バグに関する最初の実世界研究と考えられていました。105個のバグが並行処理バグとして分類され、分析されました。そのうち31個はデッドロックバグ、74個は非デッドロックバグでした。この研究では、今後のフォローアップや調査の対象となるいくつかの知見が得られました。

• 並行処理に関するバグの約3分の1は、プログラムのクラッシュやフリーズを引き起こします。
• デッドロック以外の並行処理バグのほとんどは、アトミック性違反または順序違反である。

つまり、アトミック性（共有データの保護された使用）やシーケンスに焦点を当てることで、デッドロック以外のほとんどのバグを発見できる可能性がある。

• 並行処理に関するバグのほとんどは、1つまたは2つのスレッドに関係しています。

つまり、同時ユーザー数や使用頻度が高いことがこれらのバグの発生原因ではないということです。このようなバグを検出するには、ペアワイズテストが有効である可能性が示唆されています。

• デッドロックバグの20%以上（31件中7件）がシングルスレッドで発生した。
• デッドロックの並行処理バグのほとんど（30/31）は、1つか2つのリソースのみに関係していました。

これは、リソース使用量の観点からのペアワイズテストを適用することで、デッドロックを検出できる可能性を示唆している。

• ソフトウェアテスト
• スケーラビリティテスト
• 負荷テスト
• ソフトウェアパフォーマンステスト
• シナリオ分析
• シミュレーション
• ストレステスト（ハードウェア）
• システムテスト

• 同時テストとは何か？ （ Wayback Machineアーカイブ、2016年8月19日）