スクラッチで開発

レコメンド機能

この『プログラムの改善』→『動作の保証』という一連の流れを、
「リファクタリング」「ユニットテスト」という手法を用いておこなっていくことを学びます。

プログラムの動作を変えずに重複したコードをなくしたり、
ソースコードを整理することを『リファクタリング』といいます。

Visual Studio 2013の『コードクローン分析』を利用すると、重複コードを抽出することができます。

＊デグレードとは：プログラムを手直しした際に修正部分以外の個所で不整合・不具合が発生したり、
バージョン管理の手抜かりなどによって以前の状態に戻ってしまい、修正済みだったバグが再発したりすること。

＊ユニットテスト（単体テスト）とは：プログラムを構成する比較的小さな単位（ユニット）が個々の機能を正しく
果たしているかどうかを検証するテスト。通常、関数やメソッドがユニットテストの単位。

 

このように毎日（プロジェクトによっては何日に1回、または日に数回かもしれません）定期的にビルド＆テストを
自動的に行うことを継続的インテグレーション（＝CI)といいます。

BTS（バグトラッキングシステム）

例えば、テストケースを抽出する手法の１つとして、『デシジョンテーブル』と呼ばれる手法があります。
デシジョンテーブルを利用するとテストケースの抜けもれがなく、
また、同じようなテストが重複することなくテストケースを抽出することができます。

『デシジョンテーブル』は、複数条件の組み合わせとその結果をまとめたテーブルです。
複数条件を組み合わせて、期待する結果はどうなのかを一覧表で俯瞰することができるので、
誰が見てもわかり易くなります。

結合テスト
＠Typeスポーツのサイトにお客様がログインして商品を選ぶ時におススメ情報が表示されて、実際に注文したら、そのあとカートに行って支払の処理をして、その裏ではリアルタイムで在庫管理が動いて商品残量の表示を更新して、顧客情報と連携させてお客様のお好みみたいな履歴を作って、さらに次の販促に結び付けるみたいな感じですか？

「バグ密度」というのは、「バグが製造規模あたりどの程度発生しているか」ということよ。システムを構成する場合業務に沿った単位で機能を構成するけれど、規模はバラバラだから同じ評価ができないでしょ。

「試験密度」
製造規模あたりどのくらいテストケースこなしたか」

あなたが各設計書からテスト項目を洗い出し、テストケースを作成したと想定してください。
では、そのテストケースは、ちゃんと要件にあったテストケースなのでしょうか？あるいは、要件を検証できるテストケースを抜けもれなく作成できているでしょうか？
テストケースの精度を高めるためには、こういった観点での確認が必要です。この確認を『要件トレース』と言います。

テスト密度 =　テスト件数 / ソースコード行数
バグ密度　=　バグ発生件数 / ソースコード行数