目录
一、软件测试
1、测试的目的
软件测试是软件质量保证的主要手段之一，也是在将软件交付给客户之前所必须完成的步骤。
目前，软件的正确性证明尚未得到根本的解决，软件测试仍是发现软件错误和缺陷的主要手段。软件测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件产品（主要是指程序）中的错误和缺陷。
1983年，BillHetzel在"CompleteGuideofSoftwareTesting"一书中指出："测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度量".
GrenfordJ.Myers在"TheArtofSoftwareTesting"一书中指出：
- 软件测试是为了发现错误而执行程序的过程。
- 测试是为了证明程序有错，而不是证明程序无错误。
- 一个好的测试用例是在于它能发现至今未发现的错误。
- 一个成功的测试是发现了至今未发现的错误的测试。
这种观点可以提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。但是仅凭字面意思理解这一观点可能会产生误导，认为发现错误是软件测试的唯一目的，查找不出错误的测试就是没有价值的，事实并非如此。
首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性的检测方法，改善测试的有效性。
其次，没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。
因此，软件测试可以验证软件是否满足软件需求规格说明和软件设计所规定的功能、性能及其软件质量特性的要求，为软件质量的评价提供依据。我们要注意的是软件测试只是软件质量保证的手段之一，不能单凭测试来保证软件质量。
2、测试的类型
软件测试方法一般分为两大类，分别为动态测试和静态测试。
（1）动态测试
动态测试指通过运行程序发现错误，分为黑盒测试法、白盒测试法和灰盒测试法。
不管是哪一种测试，都不能做到穷尽测试，只能选取少量最有代表性的输入数据，以期用较少的代价暴露出较多的程序错误。这些被选取出来的数据就是测试用例（一个完整的测
试用例应该包括输入数据和期望的输出结果）。
黑盒法
_______________
把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程，只在软件的接口处进行测试，依据需求规格说明书，检查程序是否满足功能要求。
常用的黑盒测试用例的设计方法有等价类划分、边值分析、错误猜测、因果图和功能图等。
等价类划分：将所有可能的输入数据，划分为等价的部分，然后从每个部分中选取少数有代表性的数据作为测试用例。等价类可以分为有效等价类（即合理、有意义的数据集合）、无效等价类（即不合理、无意义的数据集合）两种。而在选取测试用例时，应遵从"设计一个新的测试用例时，应尽可能多地覆盖尚未覆盖的有效等价类；但每次应仅覆盖一个尚未覆盖的无效等价类"的原则。
边界值分析：它是对等价类划分法的一个补充，即选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
错误推测法：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
因果图：等价类划分、边界值分析都只考虑了输入条件，未考虑输入条件间的联系，而因果图则用来描述多种条件组合的测试用例，其最终生成的结果是判定表。
它首先基于规格说明书分析原因（等价类）和结果（输出条件）；然后找出原因与结果之间的关系，画出因果图；在因果图上加上约束或限制条件；将其转换为判定表；根据判
定表得出测试用例。
功能图：它是由状态迁移图和逻辑功能模型构建的，状态迁移图用于表示输入数据序列以及相应的输出数据；逻辑功能模型用于表示在状态中输入条件与输出条件之间的对应关系。测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成的。
白盒法
_______________
把测试对象看作一个打开的盒子，测试人员须了解程序的内部结构和处理过程，以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致。
由于白盒测试是结构测试，所以被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例。
常用的白盒测试用例设计方法有基本路径测试、循环覆盖测试、逻辑覆盖测试。
逻辑覆盖：以程序内部逻辑为基础的测试技术，如常用的语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、点覆盖、边覆盖、路径覆盖。
- 语句覆盖是指选择足够多的测试用例，使得运行这些测试用例时，被测程序的每个语句至少执行一次。很显然，语句覆盖是一种很弱的覆盖标准。
- 判定覆盖又称分支覆盖，它的含义是不仅每个语句至少执行一次，而且每个判定的每种可能的结果（分支）都至少执行一次。判定覆盖比语句覆盖强，但对程序逻辑的覆盖程度仍然不高。
- 条件覆盖的含义是不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果。条件覆盖不一定包含判定覆盖，判定覆盖也不一定包含条件覆盖。
- 同时满足判定覆盖和条件覆盖的逻辑覆盖称为判定/条件覆盖。它的含义是选取足够的测试用例，使得判定表达式中每个条件的所有可能结果至少出现一次，而且每个判定本身的所有可能结果也至少出现一次。
- 条件组合覆盖的含义是选取足够的测试用例，使得每个判定表达式中条件结果的所有可能组合至少出现一次。显然，满足条件组合覆盖的测试用例，也一定满足判定/条件覆盖。因此，条件组合覆盖是上述五种覆盖标准中最强的一种。然而，条件组合覆盖还不能保证程序中所有可能的路径都至少经过一次。
- 路径覆盖的含义是选取足够的测试用例，使得程序的每条可能执行到的路径都至少经过一次（如果程序中有环路，则要求每条环路径至少经过一次）。路径覆盖实际上考虑了程序中各种判定结果的所有可能组合，因此是一种较强的覆盖标准。但路径覆盖并未考虑判定中的条件结果的组合，并不能代替条件覆盖和条件组合覆盖。
- 循环覆盖：单循环及嵌套循环。
- 基本路径法：在程序控制流程图的基础上，通过分析控制构造的环路复杂性导出基本路径集合。然后设计测试用例，保证这些路径至少通过一次。
灰盒法
_______________
灰盒测试是一种介于白盒测试与黑盒测试之间的测试，它关注输出对于输入的正确性。同时也关注内部表现，但这种关注不像白盒测试那样详细且完整，而只是通过一些表征性的现象、事件及标志来判断程序内部的运行状态。
灰盒测试结合了白盒测试和黑盒测试的要素，考虑了用户端、特定的系统知识和操作环境，在系统组件的协同性环境中评价应用软件的设计。
（2）静态测试
静态测试指被测试程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。
静态分析中进行人工测试的主要方法有桌前检查（DeskChecking）、代码审查和代码走查。经验表明：使用这种方法能够有效地发现30%~70%的逻辑设计和编码错误。
1）桌前检查由程序员自己检查自己编写的程序。
程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析、检验，并补充相关的文档，目的是发现程序中的错误。这种桌前检查，由于程序员熟悉自己的程序和自身的程序设计风格，可以节省很多的检查时间，但应避免主观片面性。
2）代码审查
代码审查是由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。
代码审查分两步：
- 第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据。小组成员在充分阅读这些材料之后，进入审查的第二步。
- 第二步，召开程序审查会。
在会上，首先由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。
在会前，应当给会审小组每个成员准备一份常见错误的清单，把以往所有可能发生的常见错误罗列出来，供与会者对照检查，以提高会审的实效。这个常见错误清单也叫做检查表，它把程序中可能发生的各种错误进行分类，对每一类列举出尽可能多的典型错误，然后把它们制成表格，供在会审时使用。这种检查表类似于单元测试中给出的检查表。
3）代码走查
代码走查与代码审查基本相同，其过程也分为两步。
- 第一步，把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。
- 第二步，开会的程序与代码审查不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者"充当"计算机。
即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。
值得说明的是使用静态测试的方法也可以实现白盒测试。例如：使用人工检查代码的方法来检查代码的逻辑问题，也属于白盒测试范畴。
3、测试的阶段
为了保证系统的质量和可靠性，应力求在分析、设计等各个开发阶段结束前，对软件进行严格的技术评审。而软件测试是为了发现错误而执行程序的过程。
根据测试的目的、阶段的不同，可以把测试分为单元测试、集成测试、确认测试、系统测试等种类。
（1）单元测试
单元测试又称为模块测试，是针对软件设计的最小单位（程序模块）进行正确性检验的测试工作。
其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。
单元测试需要从程序的内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试。
单元测试根据详细设计说明书，包括模块接口测试、局部数据结构测试、路径测试、错误处理测试和边界测试，单元测试通常由开发人员自己负责。
而由于通常程序模块不是单独存在的，因此常常要借助驱动模块（相当于用于测试模拟的主程序）和桩模块（子模块）完成。单元测试的计划通常是在软件详细设计阶段完成的。
（2）集成测试
集成测试也称为组装测试、联合测试（对于子系统而言，则称为部件测试）。它主要是将已通过单元测试的模块集成在一起，主要测试模块之间的协作性。集成测试计划通常在软件概要设计阶段完成。
从组装策略而言，可以分为一次性组装和增量式组装，增量式组装又包括自顶向下、自底向上、混合式三种，其中混合式组装又称为三明治测试。
- 自顶向下集成测试是一种构造程序结构的增量实现方法。 模块集成的顺序是首先集成主控模块（主程序），然后按照控制层次结构向下进行集成。隶属于（和间接隶属于）主控模块的模块按照深度优先或者广度优先的方式集成到整个结构中去。
- 自底向上集成测试是从原子模块（比如在程序结构的最低层的模块）开始来进行构造和测试的，跟自顶向下集成测试相反。
- 三明治式测试是一种组合的折中测试策略，从"两头"往"中间"测试，其在程序结构的高层使用自顶向下策略，而在下面的较低层中使用自底向上策略，类似于"两片面包间夹馅的三明治"而得名。
软件集成的过程是一个持续的过程，会形成多个临时版本。在不断的集成过程中，功能集成的稳定性是真正的挑战。在每个版本提交时，都需要进行冒烟测试，即对程序主要功能进行验证。冒烟测试也称为版本验证测试或提交测试。
（3）确认测试
确认测试也称为有效性测试，主要验证软件的功能、性能及其他特性是否与用户要求（需求）一致。确认测试计划通常在需求分析阶段完成。根据用户的参与程度，通常包括4种类型：
1）内部确认测试：主要由软件开发组织内部按软件需求说明书进行测试。
2）a测试（Alpha测试）：由用户在开发环境下进行测试。
3）b测试（Beta测试）：由用户在实际使用环境下进行测试。
4）验收测试：针对软件需求说明书，在交付前由用户为主进行的测试。
（4）系统测试
如果项目不只包含软件，还有硬件和网络等，则要将软件与外部支持的硬件、外设、支持软件、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统的一系列集成与确认测试。
一般地，系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等。系统测试计划通常是在系统分析阶段（需求分析阶段）完成的。
不管是哪个阶段的测试，一旦测试出问题，就要进行修改。修改之后，为了检查这种修改是否会引起其他错误，还要对这个问题进行测试，这种测试称为回归测试或退化测试。
（5）性能测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
负载测试和压力测试都属于性能测试，两者可以结合进行，统称为负载压力测试。
- 通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。
- 压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
性能测试的目的
————————————————————————
性能测试的目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。
具体来说，包括以下几个方面：
- 评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。
- 识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。
- 系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。
- 检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。
- 验证稳定性和可靠性：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。
性能测试的类型
————————————————————————
性能测试类型包括负载测试，强度测试，容量测试等。
- 负载测试：负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。
- 强度测试： 强度测试是一种性能测试，表明在系统资源特别低的情况下软件系统运行情况。
- 容量测试：确定系统可处理同时在线的最大用户数。
负载压力测试
————————————————————————
系统的负载压力测试（负载测试）是指系统在某种指定软件、硬件及网络环境下承受的流量，例如：并发用户数、持续运行时间、数据量等，其中并发用户数是负载压力的重要体现。
系统在应用环境下主要承受并发访问用户数、无故障稳定运行时间、大数据量操作等负载压力。
负载压力测试的目的如下：
- 在真实环境下检测系统性能，评估系统性能是否可以满足系统的性能设计要求。
- 预见系统负载压力承受力，对系统的预期性能进行评估。
- 进行系统瓶颈分析、优化系统。
在网络应用系统中，负载压力测试应重点关注客户端、网络、服务器（包括应用服务器和数据库服务器）的性能。应获取的关键测试指标如下：
- 客户端：并发用户数、响应时间、交易通过率以及吞吐量等。
- 网络：带宽利用率、网络负载、延迟以及网络传输和应用错误等。
- 服务器：操作系统的CPU占用率、内存使用、硬盘I/O等；数据库服务器的会话执行情况、SQL执行情况、资源争用以及死锁等；应用服务器的并发连接数、请求响应时间等。
（6）第三方测试
第三方测试指独立于软件开发方和用户方的测试，组织的测试也称为"独立测试"。
软件质量工程强调开展独立验证和确认（IV&V）活动，是由在技术、管理和财务上与开发组织具有规定程序独立的组织执行验证和确认过程。
软件第三方测试是相对独立的组织进行的软件测试，一般情况下是在模拟用户真实应用环境下，进行的软件确认测试。
第三方测试机构是一个中介的服务机构，它通过自己专业化的测试手段为客户提供有价值的服务。但是这些服务不同于公司内部的测试，因为第三方测试机构的测试除了发现软件问题之外，还有科学公正地评价软件的职能，这就要求该机构要保持公正、廉洁、客观、科学且独立的态度。
第三方测试机构存在的价值主要是由软件公司、软件用户，以及国家的公正诉求所决定的。
- 对于软件开发商来说，经过第三方测试机构的测试，不仅可以通过专业化的测试手段发现软件错误，帮助开发商提升软件的品质，而且可以对软件有一个客观且科学的评价，有助于开发商认清自己产品的定位。
- 对于行业主管部门以及软件使用者来说，第三方测试机构可帮助选择合适且优秀的软件产品。而对于一些信息工程项目来说，在验收之前，经过第三方机构的严格测试，可以最大程度地避免信息行业的"豆腐渣"工程。
此外，经过国家认可的第三方测试机构，还为国家软件产品的质量监督抽查提供独立公正的测试支持。
在选择第三方测试机构时，主要查看其资质、信息系统工程测评经验、测试环境、测试工具及测试工程师队伍的素质等。
（7）面向对象测试基础
面向对象测试是与采用面向对象开发相对应的测试技术，它通常包括4个测试层次，从低到高排列分别是算法层、类层、模板层和系统层。
- 算法层：测试类中定义的每个方法，基本上相当于传统软件测试中的单元测试。
- 类层：测试封装在同一个类中的所有方法与属性之间的相互作用。在面向对象软件中类是基本模块，因此可以认为这是面向对象测试中所特有的模块（单元）测试。
- 模板层：也称为主题层，测试一组协同工作的类或对象之间的相互作用。大体上相当于传统软件测试中的子系统测试，但是也有面向对象软件的特点（例如：对象之间通过发送消息相互作用）。
- 系统层：把各个子系统组装成完整的面向对象软件系统，在组装过程中同时进行测试。
设计测试方案的传统技术，例如：逻辑覆盖、等价划分、边界值分析和错误推测等方法，仍然可以作为测试类中每个方法的主要技术。
面向对象测试的主要目标，也是用尽可能低的测试成本和尽可能少的测试方案，发现尽可能多的错误。但是，面向对象程序中特有的封装、继承和多态等机制，也给面向对象测试带来一些新特点，增加了测试和调试的难度。
二、软件维护
在软件维护阶段，主要考查软件维护的分类、软件的可维护性等。
软件经过测试，交付给用户后，在使用和运行过程中可能在软件运行/维护阶段对软件产品进行的修改就是维护。
软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充和压缩的容易程度。目前广泛用来衡量程序可维护性的因素包括可理解性、可测试性、可修改性。
1、维护的类型
软件维护占整个软件生命周期的60%-80%，维护的类型主要有3种：
（1）改正性维护
为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。
（2）适应性维护
在使用过程中，外部环境（新的硬、软件配置）、数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化。为使软件适应这种变化，而去修改软
件的过程就叫做适应性维护。
（3）完善性维护
在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件
的可维护性。这种情况下进行的维护活动叫做完善性维护。
在实际维护工作中，改正性维护大约占20%的工作量，适应性维护大约占25%的工作量，完善性维护大约占50%的工作量。
（4）预防性维护
除了这3类维护之外，还有一类维护活动，叫做预防性维护。
这是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。
通常，预防性维护定义为："把今天的方法学用于昨天的系统以满足明天的需要"。也就是说，采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。
在软件开发过程中，错误纠正成本在逐步放大。也就是说，错误发现得越早，纠正错误所花费的成本就会越低，反之则越高。例如：如果在软件设计阶段有个错误未被发现，而待编码阶段时才发现，这时，纠正这个设计错误比纠正源代码错误需要更大的成本。