Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

ソフトウェア・テスト入門2

52 vues

Publié le

ソフトウェア基礎講座資料

Publié dans : Formation
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

ソフトウェア・テスト入門2

  1. 1. 第2回「プログラムの検査,ウォーク スルー,検討」 2011年6月17日(金) 服部 健太 ソフトウェア・テスト入門
  2. 2. 人間によるテスト  コンピュータによらないテスト過程  人々に読まれるためのプログラム  プログラムをコーディングするときと,コンピュー タによるテストをはじめるときとのあいだに応用す る手法  エラーは早期に発見する方が良い  修正にかかるコストが低くなる  正しく修正する確率も高くなる  コンピュータによるテストがはじまると,プログラマに対する 心理的圧迫が増える 2011/6/172 ソフトウェア・テスト入門2
  3. 3. コードの検査とウォークスルー 2011/6/17ソフトウェア・テスト入門23  プログラム作成者を含む数人のグループで行う  チームの人々がプログラムを読む,または見る.  目的はエラーを発見すること  解決法を見つけることではない.  これらの手法の利点  プログラム作成者以外の目でチェックされることで,エラー が発見されやすい(cf.テストの原則)  vs.机上チェック  エラーを見つけたとき,エラーの正しい性格が把握できるこ とが多い  エラーをまとめて発見できる  ある種のエラー発見に対してはコンピュータによるテスト より効果的であり,別種のエラーに対しては,その逆もい える.  両方を組み合わせるのが最も効果的.
  4. 4. コードの検査 2011/6/17ソフトウェア・テスト入門24  グループによるコード読合せのための一連の手続 きとエラー検出技法  検査チームの構成  議長:有能なプログラマだが,そのプログラムの作 成者ではない  資料の準備と配布,検査会のスケジュール,発見されたエ ラーの記録,その後の修正の確認  品質管理技術者に似た役割  その他のプログラマ:  そのプログラムの設計者(作成者と異なる場合)  テストの専門家
  5. 5. コード検査の手順 2011/6/17ソフトウェア・テスト入門25  事前準備:  議長は,事前にプログラム・リストと設計仕様を参加者 に配布しておく.  参加者は,事前にその資料を十分しらべておく  検査会での活動:  プログラマは,プログラムの論理を1命令ずつ読み上げ る.その間に疑問点があげられ,エラーがあるかどうか を考えながらすすめていく  経験によれば,発見されるエラーの多くは,読み上げている最 中に,そのプログラマ自身によって見つけられることが多い  典型的なエラーのチェックリストを見ながらプログラム を分析する  検査後,発見されたエラーリストが残る  後で,エラーチェックリストにフィードバックする
  6. 6. 検査会の注意点 2011/6/17ソフトウェア・テスト入門26  外部から中断されることがないように,時間と場所 を考える  検査に要する最適な時間は90分~120分くらい  長すぎると集中力が低下し,生産性が下がる  プログラマは「無我」の態度でのぞむ  検査を自分の人格への攻撃と捉えないこと  ⇒検査の結果はプログラマの給与査定に反映してはなら ない!  副次的な効果:  エラーによるあやまりから学べる  プログラミングスタイル,アルゴリズムの選択,プログ ラミング技術についてフィードバックを受けられる
  7. 7. 検査のためのエラー・チェック リスト 2011/6/17ソフトウェア・テスト入門27
  8. 8. データ参照エラー 2011/6/17ソフトウェア・テスト入門28  値がセットされていない変数を使っていないか?  いまどきは,コンパイラが警告してくれる  添字の値が範囲内にあるか?  整数でない添字を使っていないか?  静的型付言語ではコンパイラがチェックしてくれる  懸垂参照は?  例:  int* global_data;  void set_global(int n) { global_data = &n; }  GCのある言語では,気にしなくてよい.ただし,Null ポインタチェックは必要.  別名を使うときに正しい属性を持つか?  C言語における共用体(union)の取り扱い
  9. 9. データ参照エラー(2) 2011/6/17ソフトウェア・テスト入門29  レコードと構造の属性が一致しているか?  静的型付け言語ではコンパイラがチェックしてくれる  ビット列の番地を計算しているか?ビット列の引数 をわたしているか?  アラインメントなどの制約を満たしてるか  基底となる記憶域属性は正しいか?  静的型付け言語ではコンパイラがチェックしてくれる  構造の定義はそれぞれの手続き関数に対して,同一 の形になっているか?  静的型付け言語ではコンパイラがチェックしてくれる  文字列の限界を超えてないないか?  添字オペレーションで1つずれエラーがないか?
  10. 10. データ定義エラー 2011/6/17ソフトウェア・テスト入門210  すべての変数が宣言されているか?  静的型付け言語ではコンパイラがチェックしてくれる (誤って外側のスコープの変数を参照してる場合は チェックされない)  デフォルトの属性を知っているか?  C言語はデフォルトはint型になる  配列と文字列に適切な初期値をセットしているか?  長さ,型,記憶域の種類が正しく与えられている か?  初期値セットが記憶域の型と一致しているか?  コンパイラがチェックしてくれる  よく似た同じような名前の変数をもっているのでは ないか?
  11. 11. 計算エラー 2011/6/17ソフトウェア・テスト入門211  数字項目でない変数の計算は?  静的型付け言語ではコンパイラがチェックしてくれる  混じったモードの計算は?  int,float,doubleやsingedとunsignedの混ざった四則演算  中間結果がオーバフローあるいはアンダフローでは?  0で割っているのでは?  2進数表現の不正確さは?  意味をなす範囲を超えた変数値は?  例:変数probabilityは0.0~1.0の範囲内にあるか  演算子の優先順位を理解しているだろうか?  整数の割り算結果は正確か?  x/2 * 2 = x ???
  12. 12. 比較エラー 2011/6/17ソフトウェア・テスト入門212  矛盾する変数同士の比較は?  混じったモードの比較は?  正しい関係の比較は?  ==かequalsか,>か>=か,etc.  ブール代数表現が正しいか?  and, or, notを含む論理式が正しいか?  比較とブール代数表現が混じっているか?  x < y < zではなく,(x < y) and (y < z)  x > a or bではなく,(x > a) or (x > b)  演算子の優先順位を理解しているだろうか?  ブール代数式のコンパイラによる解釈方法を理解している だろうか?  例:if x != 0 and y/x > z then …  言語によっては0除算が発生
  13. 13. 制御流れのエラー 2011/6/17ソフトウェア・テスト入門213  分岐は適切か?  case節でbreakを忘れている場合  default節の忘れ  ネストしたif then elseの対応  ループは停止するだろうか?  プログラムは停止するだろうか?  入口条件のためどこかのループがとばされている か?  例:while (notfound) { … }  ループでの可能な中断が正しくおこなわれるか?  例:do { … } while (notfound);  1つずれの反復回数エラーは?  すべての場合を網羅していない判定はないか?
  14. 14. インタフェース・エラー 2011/6/17ソフトウェア・テスト入門214  入力パラメータの数が引数の数と等しいか?  静的型付け言語ではコンパイラがチェック  パラメータと引数の属性が一致しているか?  静的型付け言語ではコンパイラがチェック  パラメータと引数の単位系が一致しているか?  引数の順序は正しいか?  入力だけの引数が変更されてないか?  大域変数定義がモジュール間で一致しているか?  インタフェース呼び出しの順序関係は正しいか?
  15. 15. 入力/出力エラー 2011/6/17ソフトウェア・テスト入門215  ファイル属性は正しいか?  OPEN命令は正しいか?  printf/scanfなどのフォーマット指定が引数と一致 しているか?  バッファの大きさはレコードの大きさに合ってい るか?  使用前にファイルはOPENされているか?  ファイルの終わりの条件が正しく処理されている か?  I/Oエラーは正しく扱われているか?  出力情報に何かつづりのエラーはあるか?
  16. 16. その他のチェック 2011/6/17ソフトウェア・テスト入門216  使われてない変数や関数は無いか?  いまどきは,コンパイラがチェックしてくれる  警告メッセージがあるか?  入力の正当性がチェックされているか?  欠けている機能はないか?
  17. 17. ウォークスルー 2011/6/17ソフトウェア・テスト入門217  グループによるコード読み合わせのための一連の手 続きとエラー発見手法  コード検査と共通している部分もあるが,少し異なる  チームの構成  議長:資料の準備と配布,会合のスケジュールなど  書記:見つかったエラーを記録する人  テスト担当:いくつかの代表的なテスト・ケース(一連 の入力データと予想される出力データ)を用意する  参加者は「コンピュータを演じる」  会合のあいだ,テストケースは頭の中で実行される
  18. 18. その他の手法 2011/6/17ソフトウェア・テスト入門218  机上チェック  個人によるコード検査,あるいはウォークスルー  コードレビュー  インスペクションよりも気軽な会合  ピアレビュー  仲間うちでのレビュー  ピアレビューを済ましたコードのみコミットできる というルールを課すプラクティスもある
  19. 19. 次回予定  日にち  2011年6月24日(金)  時間  10:30~12:00  場所  LB/2FA  内容  テスト・ケースの設計 2011/6/1719 ソフトウェア・テスト入門2

×