ソフトウェア開発プロセスの概要
1.1ソフトウェア開発段階、活動や役割
1、ソフトウェア工学相
ソフトウェアエンジニアリングの3段階：
定義、開発、テスト配信とメンテナンス
予備的なプロジェクトフィージビリティスタディの計画、要件分析：（1）の段階を定義しました。図2-1。
ソフトウェア工学の図2-1定義フェーズ
（2）開発段階：概要設計、詳細設計、実装、テスト。図2-2。
ソフトウェア工学の図2-2開発フェーズ
（3）テスト配信やメンテナンスのフェーズ：ランニング、メンテナンス、廃棄。図2-3。
図2-3テストエンジニアリング・ソフトウェア・デリバリー・保守段階
図2に示すように、ソフトウェア開発プロセスのアクティビティは
：典型的には4つの基本的なプロセスの活動含む
（1）ソフトウェア仕様：指定されたソフトウェアの機能、性能及び動作制限を。
（2）ソフトウェア開発：設計を含むと仕事をコーディング仕様を満たすためにソフトウェアを生成します。
（3）ソフトウェア検証：顧客の要件を満たすために、検証ソフトウェアは、ソフトウェアテストに対応しています。
（4）ソフトウェア（ソフトウェア・メンテナンス）の進化：顧客の変化する要件を満たすために、ソフトウェアは、ソフトウェアのライフサイクルを延長しようとするためには、当然に進化しています。
3、開発プロセスの役割
（1）プロジェクトマネージャー：ビジネスアプリケーション開発やシステム開発プロジェクトの管理を担当。
（2）ビジネスアナリスト：理解し、顧客の要件を示し、案内して収集し、ユーザーとビジネスニーズの検証、および文書を調整します。
（3）建築家：ビジネスニーズを理解し、合理的な、サウンドシステムアーキテクチャを作成するためのシステムを担当します。そして、関連する技術を選択することにしました。
（4）データデザイナー：詳細なデータベース設計を定義するための責任を負います。
（5）プログラマ：デザイン、プログラミングコード、およびインテリアデザイン仕様。
（6）テスター：テスト計画の開発を担当し、関連するテスト計画によると、製品に問題を特定。
（7）プロダクトマネージャー：製品の出荷、流通、および製品の販売を担当します。
（8）技術サポート担当：顧客からの苦情やサービスの問題を処理するための責任。
1.2ソフトウェア開発プロセスモデル
図1に示すように、線順次モデル（ウォーターフォールモデル）
（1）非常に作業負荷を増加ステージ間でドキュメントの完全固定され、大量の様々な段階に分け
（2）により開発モデルに、結果のみを見るために開発プロセス全体が終了するまで、ユーザが線形であるそれによって増加リスクの開発、
（3）早期のエラーは、開発テストの後期を見つけることができるまで、重大な結果を待つ必要があります。
図線形順序2-4モデル
2、（速い）のプロトタイプモデル
ソフトウェアの全体的な目的を定義するために一緒に始まり、開発者とユーザーから収集したプロトタイプモデルの要件、知られている要件を識別し、さらに定義されたエリアを計画し、デザインと速い、良いビルドにプロトタイプを達成するためにコーディング。プロトタイプモデルに基づき、実行、評価、ユーザーのニーズを満たすために日まで、複数回の反復を変更します。
図2-5プロトタイプモデル
3、急速な発展モデル
RADモデルを使用する場合は、システムの主要な機能コンポーネントのそれぞれが別々のRADワーキンググループによって行うことができ、最終的にすべてのコンポーネントは、完全なソフトウェアを形成するために一緒に統合されています。
RADモデルは、再利用可能なコンポーネントの開発プロセスを重視し、並列に動作する複数のチームをサポートしています。しかし、それは困難であり、モジュール、および構造は、システムの高リスク技術に適していない多くの問題を、コンポーネントを再利用する場合は、新しい技術プロジェクトの使用。
図2-6迅速な開発モデル
4、進化のソフトウェアプロセスモデル
（1）インクリメンタルモデル：線形モデルと互い違い線形シーケンスセットの進捗スケジュール/時間分析と組み合わせたプロトタイプモデル。図2-7。
（2）スパイラルモデル：線形モデルを組み合わせプロトタイプとモデル、およびリスク分析の添加です。図2-8：
ユーザ通信、計画、リスク分析、エンジニアリング、建設、出版、ユーザーの評価：スパイラルモデルは、フレームワークの活動に分割されます。
スパイラルモデルは、コンピュータソフトウェア製品のライフサイクル全体に適応しました。大規模システムの開発のためのモデルアプローチです。
ソフトウェアのテストとソフトウェア開発の間に1.3の関係
コードをテストする - ソフトウェアのテストは、ソフトウェア開発プロセスにおいて重要な役割を果たしている、ソフトウェアテストの伝統的なウォーターフォールモデルはいくつかの仕事の舞台となります。現代のソフトウェア工学のアイデアは、ソフトウェアのライフサイクルを通じて、ソフトウェアのテストと考えられており、ソフトウェアの品質を確保するための重要な手段の一つであることになります。
有些研究数据显示，在国外软件开发的工作量中，软件测试的工作量占有总工作量的40%左右；软件开发的总费用中软件测试占有30%-50%。对于一些高科技开发系统，软件测试占有的时间和费用可能更多更高。
2.软件测试的基本原则
1、测试不是为了证明系统的正确性，而是为了证明系统存在缺陷；
2、所有的测试都应该追溯到用户的需求；
3、测试应当尽早开始和不断进行；
4、穷举测试是不可能的；
5、第三方测试会更客观、更有效；
6、Pareto原则应用于软件测试；
7、软件测试是有风险的行为；但并非所有的测试都要修复；
8、测试应从小规模开始，逐步转向大规模；
9、软件测试是一项讲究条理的技术专业。
3.软件测试方法的分类
3.1静态测试与动态测试
1、静态测试
静态测试，是不需要执行被测软件，而是采用分析和查看的方式，来发现软件当中的缺陷，包括需求文档、源代码、设计文档、以及其他与软件相关文档中的二义性和错误。最好由未参加代码编写的个人或小组来完成。测试小组还能够使用一个或多个静态测试工具，以源程序代码作为输入，产生大量的在测试过程有用的数据。如图2-9所示。
图2-9 静态测试的要素
静态测试常用的方法如下：
（1）走查
走查是个非正式的过程，检查所有与源程序代码相关的文档。
（2）审查
审查比走查要求更加正规。
（3）静态代码分析工具
静态结构分析主要是以图形的方式表现程序的内部结构
2、动态测试
动态测试是指通过运行实际被测试软件，通过观察程序运行时所表现的状态、行为等来发现软件的缺陷。并对被测程序的运行情况进行分析对比，以便发现程序表现的行为与设计规格或客户需求不一致的地方。
动态测试一般包括功能确认与接口测试，覆盖率分析、性能分析、内存分析等。
动态测试是一种经常运行的测试技术。但也有它的局限性：必须要借助测试用例完成；需要搭建特定的测试环境；不能发现文档中的问题。
由于动态测试与静态测试之间存在一定的协同性，又具有相对的独立性。所以在程序执行前进行静态测试，尽可能多地发现代码中隐含的缺陷；执行动态测试检查程序实时的行为，发现程序在运行时存在的缺陷。
3.2黑盒测试与白盒测试
1、黑盒测试
黑盒测试又称功能测试或数据驱动测试；是将被测试软件看做一个黑盒子，完全不考虑程序的内部结构和处理过程，只考虑系统的输入和输出，在程序的接口进行测试，检查系统功能是否符合需求规格说明书的要求。
常用的测试方法有：等价类划分、边界值法、决策表法、因果图法、错误推测试法等。
黑盒测试的优点:黑盒测试用例与程序如何实现无关；测试用例的设计与程序开发可并行设计；没有编程经验的人也可以设计测试用例。
黑盒测试的局限性：不可能做到穷举测试；可能存在漏洞。
2、白盒测试
白盒测试又称结构测试或逻辑驱动测试；是根据被测试程序源代码的内部结构来设计测试用例的方法。
常用的测试方法有：逻辑覆盖、基本路径和数据流测试等。
白盒测试的优点：可以利用不同的覆盖准则测试程序代码的各个分支，发现程序内部的编码错误；可以直接发现内存泄露问题；可以充当黑盒测试的检查手段等。
白盒测试的局限性：因程序路径组合太多，同样不能做到穷举测试；由于设计测试用例不是根据客户需求说明进行的测试，可能存需求方面的漏洞。
3、灰盒测试
灰盒测试结合了白盒测试和黑盒测试的要素，关注输入的正确性，同时了关注内部的表现；考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同环境中评价应用软件的设计。
3.3 人工测试与自动化测试
按照测试执行时是否需要人工干预进行分类，可分为人工测试与自动测试。
1、人工测试
人工测试是人为测试和手工测试的统称。人为测试的主要方法有桌前检查、代码审查和走查。用于软件开发各阶段的审查或评审都是人为测试。手工测试主要指在测试过程中，按照测试计划一步一步执行程序，得出测试结果并进行分析的测试行为。
2、自动测试
自动化测试指的是利用测试工具对各种测试活动的管理与执行，并对测试结果自动进行分析。在测试的执行过程中，一般不需要人工干预。常用在功能测试、回归测试和性能测试等。
自动化测试的优点：提高测试效率；降低测试成本；具有一致性和可重复性；降低风险，增加软件的质量等。
自动化测试的局限性：自动化测试软件本身的问题；测试人员期望过高；有些人工测试是不能用自动化测试替代等。
3.4 其他测试分类
1、基于模型的测试与模型检测
基于模型的测试，是指对软件行为进行建模以及根据软件的形式化模型设计测试的活动。
模型检测是指，用来验证软件特定模型中的一个或多个特性的一类技术。
模型通常是有限状态的，是从一些原始材料中提取出来的，这些原始材料可能是需求文档，也可能是系统源代码本身。有穷状态模型中的每一个状态前都有一个或多个前置条件，当软件处于该状态时，这些特性必须满足。见图2-10所示说明模型检测过程。
图2-10模型检测的要素
2、冒烟测试
冒烟测试是指在测试中发现问题，也就是说找到了一个缺陷，由开发人员来修复这个缺陷，当修复完成后，是否真的解决了这个缺陷，或对其他模块是否存在影响，因此要针对这个问题进行专门的测试，这个测试过程称为冒烟测试。
在许多情况下，经过测试后，发现修复某个问题会引起其他功能模块一系列的反应，导致产生新的缺陷。冒烟测试的优点是节省测试时间，防止创建失败。缺点是覆盖率较低。
3、随机测试
随机测试是根据测试说明书执行样例测试的一种重要补充手段，是保证测试覆盖完整性的有效方式和过程。随机测试主要针对系统的一些重要功能进行复测。还对软件更新和新增的功能要进行重点测试。常与回归测试一起进行。
4.软件测试方法在软件开发过程的运用
1、在软件需求分析与建模阶段中，主要进行软件目标的定义，可行性研究和软件需求分析工作。这时测试的对象是相关文档资料，如：需求规格说明书等。从需求的完备、可实现、是否合理、是否可测试等方面进行评审，采用的静态测试方法。
2、在概要设计与详细设计阶段。概要设计描述总体系统架构中各个模块的划分及相互之间的关系；详细设计则描述各个模块具体的算法和数据结构。这些都是用文字、图表的形式进行描述的，测试时也是用静态测试的方法，对文字、图表进行评审。
3、在编码工作阶段，主要是采用高级语言对已详细设计的模块进行编程。这时的测试工作主要是对已有的程序代码进行白盒测试，可以是静态与动态相结合，采用各种覆盖方法进行测试，此时主要由程序员进行测试。
4、在测试阶段中，此时进行的集成与系统测试。集成测试采用灰盒测试方法（白盒测试与黑盒测试相结合），主要测试产品的接口以及各模块之间的关系。而系统测试一般采用黑盒测试方法，主要测试系统的功能、性能等；由测试人员来完成测试。
5、在检验交付与维护阶段，模拟或实际客户环境，对系统进行验收测试。大多采用自动化测试工具进行测试验收。包括功能测试、性能测试、回归测试、发布测试等。
5.软件测试的过程模型
5.1V_model
v-model模型是最早的软件生存期模型，在20世纪80年代由Paul Rook提出的。
v-model包含了三个等级，分别是生存期模型，分配模型，功能性工具需求模型，阐述了应当实施哪些活动，应当产生哪些结果，诸如此类。
V-model指出，单元测试所检测代码的开发是否符合详细设计的要求。集成测试所检测此前测试过的各组成部分是否能完好地结合到一起。系统测试所检测已集成在一起的产品是否符合系统规格说明书的要求。而验收测试则检测产品是否符合最终用户的需求。所以V-model模型软件测试的策略既包括低层测试又包括高层测试，底层测试是为了验证系统源代码的正确性，高层是为了测试整个系统是否满足用户的需求。
V-model的缺陷:仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段忽视了测试对需求分析,系统设计的验证，一直到后期的验收测试才被发现。
5.2W-model
W模型由Evolutif公司提出，相对于V-model，W-model更科学,W-model是V-model的发展。由于V-model的局限性，没有明确地说明早期的测试,无法体现“尽早地和不断地进行软件测试”的原则。在V-model中增加软件各开发阶段应同步进行的测试，演化为W-model。如图2-12所示。
W-model，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。以需求为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需求的验收测试。
W-model的局限性：W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动，软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可以正式开始下一个阶段。这样就无法支持迭代、自发性以及变更调整。对于当前很多文档需要事后补充，或者根本没有文档的做法下，开发人员和测试人员都面临同样的困惑。
5.3H-model
H-model。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。如图2-13所示：
H-model揭示了：
（1）软件测试不仅仅指测试的执行，还包括很多其他的活动；
（2）软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行；
（3）软件测试要尽早准备，尽早执行；
（4）软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。
5.4X-model
X-model的基本思想是由Marick提出的，他认为一个模型必须能处理开发的所有方面，包括交接，频繁重复的集成，以及需求文档的缺乏等等。 而X-model填补了V-model 的缺陷，并可为测试人员和开发人员带来明显的帮助。如图2-14所示。
5.5 pretest-model
pretest-model，它是将测试和开发紧密结合的模型，该模型提供了轻松的方式，可以使你的项目加快速度。如图2-15所示。
Pretest-model体现了以下的要点：
（1）开发和测试相结合
（2）对每一个交付内容进行测试
（3）在设计阶段进行测试计划和测试设计
（4）测试和开发结合在一起
（5）让验收测试和技术测试保持相对独立
5.6测试模型的使用
V-model强调了在整个软件项目开发中需要经历的若干个测试级别，而且每一个级别都与一个开发级别相对应，但它忽略了测试的对象不应该仅仅包括程序，或者说它没有明确地之处应该对软件的需求、设计进行测试。
W-model强调了测试计划等工作的先行核对系统需求和系统设计的测试，但W-model和V-model一样也没有专门对软件测试流程予以说明，因为事实上，随着软件质量要求越来越为大家所重视，软件测试也逐步发展成为一个独立于软件开发部的组织，就每一个软件测试的细节而言，它都有一个独立的操作流程。比如，现在的第三方测试，就包含了从测试计划和测试案例编写，到测试实施以及测试报告编写的全过程，
H-model强调测试是独立的，只要测试准备完成，就可以执行测试了。
X-model和Pretest-model又在此基础上增加了许多不确定因素的处理情况，因为在真实项目中，经常会有变更的发生，例如需要重新访问前一阶段的内容，或者跟踪并纠正以前提交的内容，修复错误，排除多余的成分，以及增加新发现的功能等。
本章先简单介绍了软件开发过程的三个阶段：定义阶段、开发阶段、检验交付与维护阶段，软件开发过程中的活动与角色，软件开发的开发模型有线性顺序模型、原型模型、快速开发模型、演化软件过程模型等，软件开发与软件测试的关系等。并介绍了软件测试的七条基本原则，软件测试方法常用有：静态测试、动态测试、白盒测试、黑盒测试、灰盒测试、人工测试、自动化测试、模型检测、冐烟测试、随机测试等。最后介绍了软件测试的五种过程模型：V-model、W-model、H-model、X-model、 pretest-model。