（1）软件基本概念

软件（software）是指一系列按照某种特定规则组织在一起，实现用户需求的计算机数据和指令的集合体。从狭义理解即运行在计算机、手机、手持设备等电子设备上的应用程序，都称为软件。从广义理解，软件不仅仅包含实现用户需求的源代码（计算机数据、指令），还包含与之相匹配的数据文档、支撑源代码运行的配置数据。三者构成一个完整的软件实体。

（2）软件生命周期

计划-需求分析-计划-编码-测试-运维

计划工作内容：

•确定软件开发总目标；

•给出软件的功能、性能、可靠性以及接口等方面的设想；

•研究完成该项目的可行性，探讨问题解决方案；

•对可供开发使用的资源、成本、可取得的效益和开发进度作出估计；

•制定完成开发任务的实施计划。

需求分析：

有需求分析人员和客户共同商讨制定软件需求说明书srs（SoftwareRequirement  Specification2%22%7D;）

设计：

•设计是软件工程的技术核心，这个阶段需要完成设计说明书

•概要设计（HLD），在设计阶段把各项需求转换成相应的体系结构，每一部分是功能明确的模块；

  详细设计（LLD），对每个模块要完成的工作进行具体的描述

编码:

•把软件设计转换成计算机可以接受的程序，即写成以某个程序设计语言表示的源程序清单，使用RDBMS工具建立数据库。

测试：

•测试是检验软件是否符合客户需求，达到质量要求，一般由独立的小组执行，测试工作分为：

•单元测试

•集成测试

•系统测试

运维：

这个阶段将软件交付用户投入正式使用，以后便进入维护阶段，可能有多种原因需要对它进行修改，如软件错误、系统软件升级、增强软件功能、提高性能等。

（3）软件开发模式

软件研发模型（software development model）是软件生产过程中分析、设计、研发活动所遵循的框架模式。

瀑布模型

严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。

主要的问题

Ø严格分级导致的自由度降低

Ø开发成果输出过晚，风险高

Ø后期需求的变化难以调整，代价高昂

瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的

原型模型

用户很难将需求表达得既具体又明确，用户与需求开发人员的知识背景不同。当需求表述错误时，在瀑布模型下往往到后期才能发现。原型模型在很大程度上解决了这个问题。原型模型是在瀑布模型基础上演进的一种较为先进的研发模型。利用该模型，产品设计者实现用户与软件系统的交互，当原型研发生产完成后，由用户根据自身的实际需求对原型进行评价，从而进一步细化待开发软件的需求

迭代模型

•迭代模型(iterative   model)是由IBM公司提出的一种软件开发方法，该方法包括一系列的增量的步骤或迭代，每个迭代都包括很多的开发活动(需求、分析、设计、实现等)

•实现软件的每项功能反复求精的过程，是从模糊到清晰的开发过程。每次迭代是从功能的深度和细化程度来划分的。

 迭代模型最适合使用与前期需求不稳定，需求多变的项目

增量模型

增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交。

敏捷开发

•敏捷软件开发又称敏捷开发， 是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。

•在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

-人和交互   重于过程和工具。

-可以工作的软件    重于求全而完备的文档。

-客户协作     重于合同谈判。

-随时应对变化     重于循规蹈矩。

•因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少。

原则： 主张简单 拥抱变化 递增的变化 快速反馈

（4）测试定义，目的，原则：

定义：使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别

目的：

1.发现被测对象与用户需求之间的差异，即缺陷

2.通过测试发现并解决问题，让客户对软解质量有信心

3.通过测试了解软件质量，为决策提供数据

4.通过测试积累经验，预防缺陷出现，降低产品失败风险

原则：

1.测试证明软件存在缺陷

2.不能执行无穷尽的测试

3.测试应尽早介入

4.缺陷存在群集现象（二八原理）

5.杀虫剂悖论

6.不同的测试活动依赖于不同的测试背景

7.不存在缺陷谬论

（5）测试阶段

单元测试（unit testing）

集成测试（integration testing）

系统测试（system testing）

验收测试（acceptance testing）

UT

单元测试是针对软件基本组成单元函数内部的语句、条件分支来进行正确性检验的测试工作

单元测试的目的是检测软件模块对《详细设计说明书》LLD的符合程度

IT（集成测试）

集成测试是在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统，验证组装后功能以及模块间接口是否正确的测试工作 

 集成测试的目的是检测软件模块对《概要设计说明书》HLD的符合程度

ST

•系统测试是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的测试工作

•系统测试的目的在于通过与《需求规格说明书》作比较，发现软件与系统需求定义不符合或与之矛盾的地方

单元测试（ut） 集成测试（it） 系统测试（st）之间的区别

•测试方法不同

–  单元测试属于白盒测试范畴

–  集成测试属于灰盒测试范畴

–  系统测试属于黑盒测试范畴

• 测试对象不同

– 单元测试主要测试单元内部的数据结构、逻辑控制、异常处理等

– 集成测试主要测试模块之间的接口和接口数据传递关系，以及模块

  组合后的整体功能

–  系统测试主要测试整个系统相对于需求的符合度

• 判断标准不同

–  单元测试判断标准是详细设计说明书

–  集成测试的判断标准是概要设计说明书

–  系统测试的判断标准是软件需求规格说明书

验收测试

是以用户为主的测试，主要测试方法有3种

α测试:开发环境下进行，软件在自然状态下使用，有开发人员在旁，测试可控制。目的主要是评价软件产品的FLURPS（即功能、局域化、可用性、可靠性、性能和技术支持）

β测试：多个用户在多个实际情况下使用，开发人员不在旁，测试不可控制。

UAT测试：即用户接受度测试。一般用于商业用户验收系统的可用性。

•一般用于商业用户验证系统的可用性，通常情况由终端用户或利益相关方对被测试对象进行选择性功能验证。

• 也有可能根据法律法规、行业现行标准进行验收测试。

（6）测试方法

按是否关系产品内部结构划分: 黑盒测试，灰盒测试，白盒测试；

按是否运行程序划分：静态测试 动态测试；

按测试执行方式：手工测试  自动化测试；

软件测试两种极端情况：

1.已知产品的需求规格，但不知道其内部实现，可以进行测试证明每个需求是否实现。

2.已知产品的内部实现过程，可以通过测试证明每种内部操作是否符合设计规格的要求，所有内部成分是否已经过检查

白盒测试：

分析软件内部构造， 根据内部构造设计用例，对内部控制流程进行测试，不顾软件整体功能实现情况

是基于内部结构的逻辑驱动测试

又可称为玻璃盒测试、透明盒测试、开放盒测试、结构化测试、逻辑驱动测试

白盒测试一般在测试前期进行，通过测试让内部结构达到一定逻辑覆盖率指标，使内部控制问题尽可能达到最小，使软件代码达到更大质量保证，而且而且测试前期发现问题解决成本低

黑盒测试:

考虑整体功能实现情况，不顾内部构造

基于规则的测试

对更大的代码单元（子系统甚至系统级）测试效率比白盒高，对测试人员的代码语音能力要求比白盒低，从用户的角度测试，容易被理解接受，有助于暴露任何规格不一致或有歧义的问题。

灰盒测试：

•根据利用的被测对象信息的不同，会采用不同的方法进行测试。 

•利用被测对象的整体特性信息，采用黑盒测试方法 

 •利用被测对象的内部具体实现信息，采用白盒测试方法 

•如果既利用被测对象的整体特性信息，又利用被测对象的内部具体实现信息，采用的就是灰盒测试方法。两种信息占的比例不同，相应的灰度就不同。完全是整体特性信息，就是黑盒测试，完全是内部具体实现信息，就是白盒测试 

 •典型的灰盒测试比如集成测试和系统测试时借助log信息

静态测试：

不运行被测试的软件系统，而是采用其他手段和技术对被测试软件进行检测的一种测试技术。例如：代码走读、文档评审、程序分析等都是静态测试的范畴。常用技术有静态分析技术。

静态分析技术：

•定义：静态分析是一种不通过执行程序而分析程序执行的技术

•功能：检查软件的表示和描述是否一致，没有冲突或者没有歧义，它瞄准的是纠正软件系统在描述、表示和规格上的错误，因此是任何进一步测试执行的前提。

主要有三种不同的程序测试可能性：

•考虑程序是否满足编码规则，语法上是否具有一致性和完整性；

•考虑文档描述是否规范、准确、便于查阅；

•考虑程序和文档之间的一致性。

动态测试：

按照预先设计的数据和步骤去运行被测软件系统，从而对被测软件系统进行检测的一种测试技术。常用技术有动态分析技术

人工测试：

测试活动（如评审、测试设计、测试执行等）由人来完成，狭义上是指测试执行由人工完成，这是最基本的测试形式

自动化测试：

一般是指通过计算机模拟人的测试行为，替代人的测试活动，狭义上是指测试执行由计算机来完成

自动化测试意义:

•对程序新版本运行前一版本执行的测试，提高回归测试效率

•可以运行更多更频繁的测试，比如冒烟测试

•可以执行手工测试困难或不可能做的测试，比如大量的重复操作或者集成测试

•更好地利用资源，比如测试仪器或者被测对象

自动化测试限制：

•不能取代手工测试，自动化测试只能提高测试效率，不能提高测试有效性，即不可能发现更多缺陷

•手工测试比自动测试发现的缺陷更多

•对测试设计依赖性极大，测试设计的不好会遗漏问题

•自动化测试对软件开发具有很大的依赖性，开发上出现变更可能导致前面的自动化测试完全失效

•工具本身并不具备想象力，工具不具有智能

(7)测试模型

与开发模型一样，软件测试根据不同的被测对象、测试背景、被测对象质量要求、项目进度要求等，可以采用不同的测试模型实施测试活动，来指导软件测试活动安排。

业界常见模型：

V模型     从上至下  从左至右        缺点：项目早期的缺陷，在后期才能发现

W模型（双V模型）   测试活动与研发并行， 文档测试

X模型 单独的程序片段进行独立的编码和测试活动    探测性测试

H模型 开发与测试独立     分测试准备，测试执行

敏捷模型 客户角度进行测试 预防缺陷重于发现缺陷

V模型：

•V模型是所有软件测试模型中最为大家熟知的一种模型。它是从瀑布研发模型演变而来的测试模型，如图所示。

V模型流程是从上至下，从左到右

①测试工程师在研发人员编程过程中，对其生成的代码函数做单元测试

②单元测试通过后进行集成测试

③集成测试通过后做系统测试、验收测试

V模型缺点：项目早期的缺陷，在后期才能

W模型：

W模型是在V模型的基础上演变而来的，一般又称为双V模型。在V模型中，研发活动没有完成、无任何输出物时，测试工程师无法开展测试工作，相对而言，测试活动严重滞后。为了解决V模型的缺点，W模型提出了测试活动与研发活动并行的概念，并且在生产流程演进过程中，增加了验证与确认活动

W模型从用户需求开始，研发团队根据用户需求进行需求分析、概要设计、详细设计、编码开发等活动，测试团队则根据用户需求进行验收测试、系统测试、集成测试及单元测试设计。测试工作与研发活动分离，实现了并行操作。测试活动伴随着整个研发过程，而不仅在研发有成果输出后才参与。

W模型强调了测试活动不仅仅包括研发活动所产生的软件源代码，还考虑各种文档，如需求文档、概要设计文档、详细设计文档、代码等。

W模型要求测试活动从用户需求阶段就介入，有利于尽早地发现问题，在模型实施过程中，时刻进行确认（validation）、验证（verification）活动

X模型：

•X模型产生的背景亦与V模型有关，V模型的缺点是测试活动滞后于研发活动，无法尽早地开展测试活动。而X模型与W模型一样，提出的初衷都是解决V模型的缺点。

•X模型的基本思想是由Marick提出的， Robin F.Goldsmith进行了完善。X模型如图所示。

X模型左边表明针对单独的程序片段n进行独立的编码和测试活动，以此为基本过程，不断迭代，通过集成活动最终成为可执行程序，然后再对这些可执行程序进行测试。通过集成测试的成品可以进行封装并提交给系统测试环节或直接给用户。多条并行的曲线表示变更可以在各个部分发生。

探索性测试:探索性测试与常规的测试方法不同，无须事先制定测试计划或设计，有经验的测试工程师可根据自己的思维活动及对被测对象的理解，在测试计划之外发现更多的软件错误。但探索性测试通常情况下仅作为其他测试方法的补充，因其消耗测试资源较多，且受制于测试工程师的经验，所以不能成为独立的测试方法。

    H模型：

H模型将测试活动与其他研发流程独立，测试活动分为测试准备与测试执行两个部分，便于测试设计与测试执行活动定义，如图所示。测试准备活动包括测试需求分析、测试计划、测试设计、测试编码、测试验证等，测试执行包括测试运行、测试报告、测试结果分析、确认回归测试等

    H模型与W模型一样，揭示了软件测试活动应该是一个独立的软件生产流程，贯穿整个软件生命周期，测试活动应该尽早准备、尽早执行，当测试准备工作完成后，一旦到达测试就绪点，就可开展测试执行活动，不会受制于研发活动。

敏捷测试：

强调从客户角度进行测试；

重点关注迭代测试新功能，不再强调测试阶段

尽早测试，不间断测试，具备条件即测试

强调持续反馈

预防缺陷重于发现缺陷

 传统测试：测试是质量的最后保护者                  敏捷测试：开发和测试人员是紧密合作，大家都有责任对软件负责；

                      严格的变更管理                                                     变更是可接受的，拥抱变

                      预先的计划和细节的准备                                     计划随着进展时常调整

                       重量级文档                                                            只需要绝对必要的文档

                各阶段测试严格的入口和出口标准                           各迭代之间已经没有明显的入口和出口标准

               更多在回归测试时进行重量级的自动化测试            所有阶段都需要自动测试，每个人都需要做，是项目集成                                                                                                        的一部分；

              严格依赖流程执行                                                        流程不再需要严格执行

              测试团队和开发团队是相对独立的                            团队合作是无缝隙合作