回答編集履歴
1
整形
test
CHANGED
|
@@ -2,21 +2,19 @@
|
|
|
2
2
|
|
|
3
3
|
|
|
4
4
|
|
|
5
|
-
ポイントとしては、内部仕様の把握は必要になる時(その部分の改修等)までは
|
|
5
|
+
ポイントとしては、内部仕様の把握は必要になる時(その部分の改修等)までは保留しておいて、各単位の外部仕様の把握に専念する事です。
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
6
|
|
|
11
7
|
|
|
12
8
|
|
|
13
9
|
1. 壊しても良い検証環境の構築
|
|
14
10
|
|
|
11
|
+
---
|
|
12
|
+
|
|
15
13
|
とりあえず可能な限り同じ環境を構築する。
|
|
16
14
|
|
|
17
15
|
データも本番から取得したものを使う。
|
|
18
16
|
|
|
19
|
-
環境のバックアップを取っていつでも戻せる様にする。(ソースコードレベルでは無く、OSのイメージ化や仮想化)
|
|
17
|
+
環境のバックアップを取っていつでも戻せる様にする。(ソースコードレベルでは無く、OSのイメージ化や仮想化で確実に元に戻せる状態を確保する)
|
|
20
18
|
|
|
21
19
|
|
|
22
20
|
|
|
@@ -30,9 +28,17 @@
|
|
|
30
28
|
|
|
31
29
|
2. インデントや体裁が汚いものはIDEを駆使して奇麗にする
|
|
32
30
|
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
機械的に直せるところは直してしまいましょう。
|
|
33
34
|
|
|
34
35
|
|
|
36
|
+
|
|
37
|
+
|
|
38
|
+
|
|
35
|
-
3. 内部仕様を読み解くのでは無く、確認出来る単位(ユーザー定義関数や、一連の処理)で外部仕様を確認していく
|
|
39
|
+
3. 内部仕様を読み解くのでは無く、確認出来る単位(ユーザー定義関数や、一連の処理)で外部仕様を確認していく
|
|
40
|
+
|
|
41
|
+
---
|
|
36
42
|
|
|
37
43
|
|
|
38
44
|
|
|
@@ -48,6 +54,14 @@
|
|
|
48
54
|
|
|
49
55
|
結果の検証
|
|
50
56
|
|
|
51
|
-
と言うのを繰り返して、どういった役割と外部仕様を持った部品なのかを把握してい
|
|
57
|
+
と言うのを繰り返して、どういった役割と外部仕様を持った部品なのかを把握していきます。
|
|
52
58
|
|
|
59
|
+
|
|
60
|
+
|
|
53
|
-
結果が仮説と違った場合は、`仮説と結果の差異を確かめる事に目的を絞って`ブレークポイントを仕掛ける等して内部仕様から外部仕様を導き出す
|
|
61
|
+
- 結果が仮説と違った場合は、`仮説と結果の差異を確かめる事に目的を絞って`ブレークポイントを仕掛ける等して内部仕様から外部仕様を導き出す
|
|
62
|
+
|
|
63
|
+
- 大きな単位（一連の処理）の正常形を最初に確認して（業務要件と直結しているはずなので、実際に使っている人に教えてもらうのが早いことが多いです）、一段ずつ単位を細かくしていく
|
|
64
|
+
|
|
65
|
+
- 一つ下の単位の部品の外部仕様が把握できて来たら、一段上の単位に戻って異常系についても確認していく（行ったり来たりして挙動を把握する）
|
|
66
|
+
|
|
67
|
+
- 最初のうちは異常系まで一気に全部把握するのは無理なので、正常系に絞ってそのシステムの全体の流れを把握することに注力し、全体像や作りが把握できて来たら異常系や境界値について仕様を仮定してテストケースを作る
|