大学での講義やネットから得た知識を忘れないようにまとめよう
知識の定着をするためにアウトプットをしたいので、投稿をしていきたいと思います。
では、やっていきましょう
ソフトウェア設計？
試験とは
開発しているシステムに「誤り」のないことを確かめる
↳使用に沿っていないこと
-機能
-性能
-使用自体が誤っている可能性
現実には「誤り」のないことを表すことはできない
⇓現実
開発しているシステムに「誤り」が含まれていることを認め
「含まれている誤りを最大限見つけだし、それらを取り除く」努力をすること
ここから感じるのは、プログラムを組むのはどうしても人間しか現状いなくそこからのミスが
試験で発見されて修正がされてもそこから試験自体が誤りがあるのではないかという考えが
浮かびまたそこからも...という感じでスパイラルに止まらない状態になるのでもう見つけられる
最大限の誤りを見つけてそれを取り除くことを努力しようそして見つからないような誤りというのは人海戦術でみつからないということはほぼその誤りは発生しないものということで目をつむることにしたほうがいいということなのではないかと考える
試験とデバグ
デバグとは ： 試験で指摘されたその原因の誤りを探して取り除くこと
言明および仕様 試験 目的
1 証明 → 現論上適正さ
2 妥当性 → 与えられた環境での適正さ
3 検証 → 試験環境での論理上適正さ
4 保証 → 適正さ及び効率の保証
5 性能試験 → 社算機時間や資源利用などの特徴
この1~5までの事柄を行い 誤りが出たら 虫取りを行い 修正をして また1~5までを
繰り返していきます
試験作業手順
単体試験
-作成された単体(Unit)の適正さを確かめる
プログラムの部品 ← 部品そのものの適正さを確かめる
プログラムの部品
プログラムの部品
情報システム ※補足
数万行のシステム全体からエラーを探すことは困難だが
部品単体であれば数十行～数百行
なので問題個所の発見、修正が容易となる
プログラムの部品
コンパイル単位として実現されることが多い、複数の関数や手続きを含むことがあり
これを内部モジュールと呼ぶ 単体は他の単体とのやり取りをすることが通常
単体試験の流れと特徴
試験 → 試験項目確定 → データ作成 → 動作環境整備 → 実施・確認(繰り返す)
↓
障害記録 ← 修正・虫取り
↓
修正・回帰
・単体試験は基本的に個人活動
・個人が試験・修正・管理という複数の役割をこなす必要がある
・↑は詳細な情報の伝達や情報収集の作業量を削減できるので利点である
・一方で、試験の質低下などの作業になってしまう
