このコラムはブロガーの個人的なメモであり、主な目的は、断片的な時間を利用してソフトエンジニアリングの知識ポイントを暗記することです、ここに宣言します!
記事ディレクトリ
2. エンコードとは何ですか? 選択したプログラミング言語はプログラムのどの機能に大きな影響を与えますか?
3. ソフトウェア ライフ サイクルにおいて、ソフトウェア テストはどの 2 つの段階に及びますか?
4. ソフトウェア開発の総作業量に対するテストの作業量の割合はどれくらいですか?
6. コーディングルールではどのような点を考慮する必要がありますか?
12. テスト時間の順序に従って、テストのステップは何ですか?
14. テスト段階の情報フローに含まれる 2 つの部分はどれですか?また、それらはどの部分で構成されますか?
15.単体テストとは何ですか? 主にどのテスト手法が使用されますか?
17. コードレビューがコンピュータテストよりも優れている理由は何ですか?
18. 単体テストのために開発する必要がある 2 つの仮想プログラムはどれですか?
19. 高度なモジュールの凝集度は単体テストにどのような利点をもたらしますか?
21. モジュールをプログラムにアセンブルする 2 つの方法は何ですか?
22. モジュールをプログラムに組み込むための増分テスト方法の 2 つの戦略は何ですか?
23. トップダウン戦略とボトムアップ戦略の比較は何ですか? (一方の戦略の欠点は、もう一方の戦略の利点になります)
26. 検証テストの目的は何ですか? 検証と確認の違いは何ですか？
29. 確認テストの主な目的は何ですか? 通常どのような試験方法が使用されますか?
32. ホワイトボックステストテクノロジーには何が含まれますか?
34. 弱いものから強いものへの論理的なカバレッジとは何ですか?
36. 基本パステストは制御構造テストの一種ですが、具体的にはどのような手順で行うのですか？
37. ホワイトボックステストとブラックボックステストの違いは何ですか?
44. ソフトウェアの信頼性とソフトウェアの可用性の違いは何ですか?
47. さまざまなレビュー段階に応じて、どのような種類のソフトウェアレビューが分割されますか?
48. ソフトウェアレビューが非常に重要なのはなぜですか? （ソフトウェア見直しの意義）
1. 実装はどの 2 つの部分で構成されますか?
実装はコーディングとテストで構成され、これらを総称して実装と呼びます。
2. エンコードとは何ですか? 選択したプログラミング言語はプログラムのどの機能に大きな影響を与えますか?
いわゆるコーディングとは、ソフトウェアの設計結果を特定のプログラミング言語で書かれたプログラムに変換することです。
選択したプログラミング言語とコーディング スタイルの特性は、プログラムの信頼性、読みやすさ、テスト容易性、保守容易性に大きな影響を与えます。
3. ソフトウェア ライフ サイクルにおいて、ソフトウェア テストはどの 2 つの段階に及びますか?
単体テスト段階: モジュールの作成者とテスターは同一人物です
包括的なテスト段階:専任のテスターが実施します。
4. ソフトウェア開発の総作業量に対するテストの作業量の割合はどれくらいですか?
40%以上
5. コーディングの前に重要な仕事は何ですか?
適切なプログラミング言語を選択します。高級言語はアセンブリ言語よりもはるかに優れています
6. コーディングルールではどのような点を考慮する必要がありますか?
- プログラム内のドキュメント
- データの説明
- ステートメントの構造
- 入出力
- 効率
7. 効率性の 2 つの主な側面は何ですか?
時間と容量スペース
8. 効率の原則?
- 効率はパフォーマンス要件です
- 優れた設計により効率が向上します
- プログラムの効率はプログラムの単純さと一致します。効率を不必要に高めるためにプログラムの明瞭さと読みやすさを犠牲にしないでください。
9. テスト段階の基本的な目的は何ですか?
テスト段階の基本的な目的は、ソフトウェア内の潜在的なエラーをできる だけ多く見つけて排除し、最終的に高品質のソフトウェア システムをユーザーに提供することです。
ソフトウェア テストの最終目標は問題を明らかにすることではなく、問題を見つけることは問題を解決することです。
10. ソフトウェアテストの目的または定義は何ですか?
- テストとは、プログラム内のバグを見つけるためにプログラムを実行するプロセスです(定義)
- 優れたテスト計画とは、これまで発見されていないバグを発見する可能性が高い計画です。
- 成功したテストとは、これまで発見されていないバグを発見したものです
11. テストの基準は何ですか?
- すべてのテストはユーザーの要件に追跡できる必要があります
- テスト計画は、テストが開始されるずっと前に作成する必要があります
- パレートの法則をソフトウェア テストに適用します。つまり、エラーの 80% はプログラム内のモジュールの 20% によって引き起こされる可能性があります。
- 「小規模」テストから始めて、「大規模」テストに段階的に到達する必要があります。
- 徹底的なテストは不可能
- 最良のテスト結果を得るには、独立した第三者がテスト作業に従事する必要があります。
12. テスト時間の順序に従って、テストのステップは何ですか?
- 単体テスト
- 統合テスト
- システムテスト
- 受け入れテスト（確認テスト）
13. 並列運転とは何ですか?
並列運用とは、多くの場合、重要なソフトウェア製品が承認後すぐに本稼動に入るのではなく、古いシステムと一定期間の並列運用期間を経ることを意味します。
14. テスト段階の情報フローに含まれる 2 つの部分はどれですか?また、それらはどの部分で構成されますか?
- ソフトウェア構成：要求仕様書、設計仕様書、ソースプログラムリスト
- テスト構成: テストスキームと計画など。
15.単体テストとは何ですか? 主にどのテスト手法が使用されますか?
単体テストはソフトウェア設計の最小単位であるモジュールの検出に重点を置き、主に「ホワイトボックステスト技術」を使用します。
複数のモジュールのテストは、手動テストとコンピュータテストの 2 つの異なる方法を使用して並行して実行でき、作業を完了し、相互に補完し合います。
16. 単体テストの焦点は何ですか?
- モジュールインターフェース
- ローカルデータ構造
- 重要な実行経路
- エラー処理パス
- 境界条件(最も重要)
17. コードレビューがコンピュータテストよりも優れている理由は何ですか?
コードレビュー会議では多くのエラーが 見つかる可能性があり、コンピュータのテストでエラーが見つかった後は、通常、テストを続行する前にエラーを修正する必要があります。つまり、エラーは1 つずつ検出され、修正されます。
18. 単体テストのために開発する必要がある 2 つの仮想プログラムはどれですか?
ドライバーソフト（メインプログラム）
スタブソフトウェア（スタブモジュール、ダミーサブルーチン）
19. 高度なモジュールの凝集度は単体テストにどのような利点をもたらしますか?
モジュールの高度な結合により、単体テストのプロセスが簡素化されます。各モジュールが 1 つの機能のみを完了する場合、必要なテスト計画の数が大幅に減り、モジュール内のエラーの予測と発見が容易になります。
20. 統合テストとは何ですか? 主な目標は何ですか?
統合テストは、ソフトウェアをテストおよび組み立てるための体系的な手法であり、その主な目的はインターフェイスに関連する問題を見つけることです。
21. モジュールをプログラムにアセンブルする 2 つの方法は何ですか?
モジュールをプログラムに組み込む際には、非増分テスト方式と増分テスト方式があり、結合テストでは増分テスト方式が一般的に使用されます。
22. モジュールをプログラムに組み込むための増分テスト方法の 2 つの戦略は何ですか?
トップダウン戦略とボトムアップ戦略
23. トップダウン戦略とボトムアップ戦略の比較は何ですか? (一方の戦略の欠点は、もう一方の戦略の利点になります)
トップダウン テスト アプローチの主な欠点は次のとおりです。
- スタブが必要です
- これに関連してテスト上の問題が発生する可能性があります
- 低レベルの重要なモジュールのバグが発見されるのが遅い
- この方法では初期段階で人材を十分に育成できない
トップダウン テスト アプローチの主な利点は次のとおりです。
- テストドライバーは不要です
- テスト段階の早い段階でシステムの主要な機能を実装および検証する能力
- 上位モジュールのインターフェースエラーを早期に検出する機能
24. 混合戦略とは何ですか?
混合戦略 = 改良されたトップダウンテスト手法 + ハイブリッド手法
[注]: ハイブリッド方式は「サンドイッチ方式」とも呼ばれ、ソフトウェア構造の上位層ではトップダウンテスト方式が、下位層ではボトムアップテスト方式が使用されます。
25. 回帰テストとは何ですか?
回帰テストとは、すでに行われたテストのサブセットを再実行することを指します。
26. 検証テストの目的は何ですか? 検証と確認の違いは何ですか？
確認テストは受け入れテストとも呼ばれ、その目的はソフトウェアの有効性を検証することです。
検証とは、ソフトウェアが指定された要件を正しく実装していることを確認する一連のアクティビティを指します。
検証とは、ソフトウェアが実際にユーザーのニーズを満たしていることを確認するために実行される一連のアクティビティを指します。
27. ソフトウェアの有効性の定義は何ですか?
ソフトウェアの有効性とは、ソフトウェアの機能とパフォーマンスがユーザーが合理的に期待するものと一致している場合にソフトウェアが有効であることを意味します。
28. 確認検査の根拠は何ですか?
ソフトウェア要件仕様
29. 確認テストの主な目的は何ですか? 通常どのような試験方法が使用されますか?
確認テストはユーザー中心であり、通常はブラックボックス テストを使用します。この段階で見つかった問題は、通常、要件分析段階のエラーに関連しており、広範囲にわたるため解決が困難です。
30. アルファ テストとベータ テストの違いは何ですか?
アルファ テストは管理された環境で実施され、通常は開発者がユーザー テストを指示します。
ベータ テストは1 つ以上の顧客サイトでソフトウェア エンド ユーザーによって実行され、開発者はテスト サイトにはいません。
31. テストケースとは何ですか?
テストデータと期待される出力結果はテストケースと呼ばれます。最も難しい問題はテスト用の入力データを設計することです
32. ホワイトボックステストテクノロジーには何が含まれますか?
ロジックカバレッジと制御構造のテスト
33. 論理カバレッジとは何ですか?
ロジック カバレッジとは、パス テスト プロセスが徐々に完全なものになることを意味する一般用語です。
34. 弱いものから強いものへの論理的なカバレッジとは何ですか?
- ステートメント カバレッジ(ポイント カバレッジ): テスト対象プログラム内の各ステートメントが少なくとも 1 回実行されるように、十分なテスト データを選択します。
- 意思決定カバレッジ(エッジ カバレッジ): 各ステートメントを少なくとも 1 回実行する必要があるだけでなく、各意思決定の各分岐も少なくとも 1 回実行する必要があります。
- 条件カバレッジ: 各ステートメントを少なくとも 1 回実行するだけでなく、決定式の各条件でさまざまな結果が得られるようにします。
- 判定/条件のカバレッジ: 判定式の各条件はさまざまな値をとり、各判定式もさまざまな結果をとりえます。
- 条件の組み合わせのカバレッジ: 各決定式で考えられる条件の組み合わせが少なくとも 1 回発生するように、十分なテスト データを選択します。
【ノート】：
- 意思決定の適用範囲 >= ステートメントの適用範囲
- 条件カバレッジ >= ステートメント カバレッジ
- 通常、条件カバレッジは決定カバレッジよりも強力であり、特定の包含関係はありません。
- 決定/条件オーバーライド >= 決定オーバーライド
- 判定/条件オーバーライド >= 条件オーバーライド
- 最も強力な基準はパス カバレッジです
35. 制御構造テストには何が含まれますか?
基本パステスト、条件テスト、ループテスト
36. 基本パステストは制御構造テストの一種ですが、具体的にはどのような手順で行うのですか？
- プロセス設計結果に従って、対応するフロー図を描画します
- フロー グラフの循環複雑度を計算します。独立したパスは数と同じ数あり、独立したパスの結果は一意ではありません。
- 線形独立パスの基本セットを決定します(独立パスには、パスを定義する前に使用されなかったエッジが少なくとも 1 つ含まれます)
- 基本セット内の各パスを強制するテスト ケースを設計する
37. ホワイトボックステストとブラックボックステストの違いは何ですか?
- ホワイトボックステストおよび検出ソフトウェアの論理構造、ブラックボックステストおよび検出ソフトウェアの機能
- ホワイトボックステストは、テスターがプログラムの構造や処理アルゴリズムを十分に理解していることが前提ですが、ブラックボックステストは、プログラムの内部や処理を考慮せず、プログラムをブラックボックスとしてみなします。
- ホワイト ボックス テストはテストの初期段階で行われますが、ブラック ボックス テストは主にテスト プロセスの後の段階で使用されます。
- 両者の技術手法は異なり、ホワイトボックステスト手法には主にロジックカバレッジやパステストが含まれ、ブラックボックステスト手法には主に同値クラス分割や境界値解析が含まれます。
38. ブラックボックステスト手法とは何ですか?
同値クラス分割、境界値解析、エラー推測
39. 同値クラス分割法の手順は何ですか?
同値分割では、まず入力データの同値クラスを分割して、入力データの有効な同値クラスと無効な同値クラスを決定します。また、出力データの同値クラスを分析して、対応する同値クラスを導出する必要があります。出力データの等価クラスに従った入力データの等価クラス。
[注]: プログラムが最もエラーを起こしやすいのは境界条件を扱うときであり、通常、テスト計画を立てる際には同値分割と境界値解析の 2 つの手法を常に組み合わせて使用します。
40. 間違った推測方法の特徴は何ですか?
エラーの推測は直感と経験に大きく依存します
41. 入力の組み合わせを選択する効果的な方法は何ですか?
- デシジョンテーブルまたはデシジョンツリーをツールとして使用する
- コンピューターテストと人間による検査の組み合わせ
42. デバッグとは何ですか?
デバッグは、テストでエラーが見つかった後にエラーを取り除くプロセスであり、ソフトウェア開発プロセスの中で最も困難な頭脳作業です。
43. デバッグにはどのような方法がありますか?
- 強引な
- 後戻り
- 原因除去法（二分探索法、帰納法、演繹法を含む）
44. ソフトウェアの信頼性とソフトウェアの可用性の違いは何ですか?
ソフトウェアの信頼性とは、プログラムが指定された時間間隔内で仕様に従って正常に実行される確率を指します。
ソフトウェアの可用性とは、特定の時点でプログラムが仕様に従って正常に実行される確率を指します。
45. エラーの総数を見積もる方法は何ですか?
- 注入エラー
- 別のテスト
46. ソフトウェアレビューとは何ですか?
ソフトウェアレビューは、ソフトウェア要素またはプロジェクトのステータスを評価して、計画された結果と一致しているかどうかを判断し、改善を可能にする 手段です。
47. さまざまなレビュー段階に応じて、どのような種類のソフトウェアレビューが分割されますか?
- 見直しが必要
- 機能レビュー
- 品質レビュー
- コストの見直し
- メンテナンスの見直し
48. ソフトウェアレビューが非常に重要なのはなぜですか? （ソフトウェア見直しの意義）
ソフトウェアレビューは、プロジェクトチームの総合力を組織し、ソフトウェア関連の内容について合理的な分析を行い、ソフトウェアライフの初期段階で可能な限り問題を発見して解決することができるため、ソフトウェアレビューは非常に重要です
章の最後にまとめ
実装には、コーディングとテストの2 つのフェーズが含まれます。
従来のソフトウェアエンジニアリングの手法では、ソフトウェアの全体設計と詳細設計を行った後にコーディングが行われ、ソフトウェア設計の結果を特定のプログラミング言語で書かれたプログラムに変換するだけであるため、基本的にはプログラムの品質が重要となります。デザインの品質に依存します。ただし、コーディングに使用される言語、特にプログラムの作成スタイルもプログラムの品質に大きな影響を与えます。
多くの実際的な結果は、高級プログラミング言語がアセンブリ言語に比べて多くの利点を持っていることを示しています。したがって、よほどの必要がない限り、通常はアセンブリ言語を使用してプログラムを作成しないでください。どの高級プログラミング言語を選択するかについては、言語自体の特性だけでなく、使用環境などの実際的な要素も考慮する必要があります。
プログラム内の適切なドキュメント、規則的なデータ記述形式、単純明快なステートメント構造と入出力形式などは、すべてプログラムの可読性の向上に多大な効果をもたらし、また、プログラムの可読性も大幅に向上します。メンテナンス性も良好です。
現在でも、ソフトウェア テストはソフトウェアの信頼性を確保するための主な手段です。テスト段階の基本的なタスクは、ソフトウェアのバグを見つけて修正することです。
ソフトウェア テストは、ソフトウェア開発プロセスの中で最も困難で骨の折れる作業です。大規模なソフトウェア テストは、通常は少なくとも3 つの基本段階 (単体テスト、統合テスト、受け入れテスト)に分けて 段階的に実行する必要があります。
テスト計画の設計は、テスト段階における重要な技術的問題です。基本的な目標は、可能な限り完璧なテストを達成するために効率的なテスト データを最小限に選択し、ソフトウェア内でできるだけ多くの問題を見つけることです。
ソフトウェアテストはコンピュータを使用したテストだけを指すのではなく、人間によって実行されるテスト（コードレビューなど）も含まれることを認識する必要があります。2 つのテスト方法にはそれぞれ長所と短所があり、相互に補完し合うため、両方が不可欠です。
ホワイト ボックス テストとブラック ボックス テストはソフトウェア テストの 2 つの基本的な方法であり、これら 2 つの方法には独自の長所があり、相互に補完し合います。通常、ホワイト ボックス アプローチは主にテスト プロセスの初期段階で使用され、ブラック ボックス アプローチは主にテスト プロセスの後期段階で使用されます。効果的なテスト ソリューションを設計するには、ソフトウェア エンジニアはソフトウェア テストの基本原則を深く理解し、遵守する必要があります。
ホワイトボックス テスト スキームを設計する手法には主にロジック カバレッジと制御構造テストが含まれ、ブラック ボックス テスト スキームを設計する手法には主に等価性分割、境界値分析、およびエラー推測が含まれます。
テスト プロセスで見つかったソフトウェア エラーは、時間内に修正する必要があります。これがデバッグの作業です。エラーを修正するには、まずエラーの正確な位置を特定する必要がありますが、これはデバッグ プロセスの中で最も困難な作業であり、注意深く慎重な思考と推論が必要です。間違いを修正するには、元の設計を修正する必要がある場合が多く、「頭が痛ければ頭、足が痛ければ足を治療する」のではなく、総合的に考慮する必要があります。デバッグ プロセス中に新たなエラーが発生することを回避します。
テストとデバッグは、ソフトウェア テスト段階で非常に密接に関連する 2 つのプロセスであり、多くの場合、交互に実行されます。
プログラム内の隠れたエラーの数は、ソフトウェアの信頼性を直接決定します。プログラムに残っているバグの数は、テストによって推定できます。テストやデバッグの過程で発見され修正されたエラーの数に応じて、ソフトウェアの平均故障間隔を推定できますが、逆に、ソフトウェアの必要な平均故障間隔に応じて、その数は推定できます。修正すべきエラーの量を推定できるため、テスト段階を判断できます。
次の章：ソフトウェアエンジニアリング—第 8 章 メンテナンスの知識ポイント
繰り返し、地に足を着いて、決して忘れることなく、響き渡るでしょう！