软件测试基础理论

官方释义：

a.用来促进鉴定软 件的正确性、完整性、安全性和质量的过程；

b.是一种实际输出与预期输出间的审核或者比较过程；

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

经典定义：

a.软件测试是为了发现错误而执行程序的过程。

b.软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例(即输入数据及其预期的输出结果)，并利用这些测试用例去运行程序，以发现程序错误的过程。

按开发阶段来分：单元测试、集成测试、系统测试、验收测试。

按测试的实施单位来分：开发方测试、用户测试、第三方测试。

按测试技术来分：白盒测试、黑盒测试、灰盒测试。

黑盒测试：把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。

黑盒测试方法包括：等价类划分、边界值分析、因果图分析、错误推测法、功能图分析等。

白盒测试：是对软件的过程性细节做细致的检查。是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。

白盒测试方法包括：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖等。

单元测试：是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约(详细设计)而言的。因此，单元测试以被测试单位的规约为基准。

单元测试方法包括：控制流测试、数据流测试、排错测试、分域测试等。

集成测试：是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。

系统测试：是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等。

验收测试：由客户或最终用户执行，旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

UAT测试：

UAT，(User Acceptance Test),也就是用户验收测试，或用户可接受测试，系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。 它让系统用户决定是否接收系统。 它是一项确定产品是否能够满足合同或用户所规定需求的测试。

功能测试：对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。

性能测试：是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

用户视角的软件性能：

系统管理员视角的软件性能：

软件性能指标：

负载测试：

压力测试：

恢复测试：恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。如果系统恢复是自动的（即恢复由系统自身完成），则应该检验以下内容：重新初始化、检验点设置机构、数据恢复以及重新启动是否正确。

可用性测试：

可用性测试是面向用户的系统测试。让一群有代表性的用户尝试对产品进行典型操作，- - 同时观察员和开发人员在一旁观察，聆听，做记录。

兼容性测试：

安全性测试：

Alpha测试：由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现在错误和使用中遇到的问题。总之，Alpha测试是在受控的环境中进行的。

Beta测试：由软件的最终用户们在一个或多个客房场所进行。与Alpha测试不同，开发者通常不在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户Beta测试过程中遇到的一切问题（真实在或想像的），并且定期把这些问题报告给开发者。接收到在Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。

冒烟测试：可以根据其名称理解为该种测试耗时短；其实是对软件基本的功能进行测试，测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本的功能正常，保证软件系统能跑得起来，可以进行后续的正式测试工作。

回归测试：是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误，回归测试的困难在于不好确定哪些内容应当被重新测试。

随机测试：主要是根据测试者的经验对软件进行功能和性能抽查。它是根据测试说明书执行样例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。

动态测试：是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。所谓软件的动态测试，就是通过运行软件来检验软件的动态行为和运行结果的正确性。目前，动态测试也是公司的测试工作的主要方式。

静态测试：是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。

UI测试：指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等；用户界面(UI)测试用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化，易操作性测试。UI测试比较主观，与测试人员的喜好有关。

自动化测试：利用软件测试工具自动实现全部或部分测试，它是软件测试的一个重要组成部分，能完成许多手工测试无法实现或难以实现的测试；正确、合理的实施自动测试，能够快速、全面的对软件进行测试，从而提高软件质量，节省经费，缩短软件发布周期。

桩测试：

桩的英文是stub；是指一个软件模块的框架或特殊目标实现，主要用于开发和测试一个组件，该组件调用或依赖这个模块。

桩模块：集成测试前要为被测模块编制一些模拟其下级模块功能的“替身”模块，以代替被测模块的接口，接受或传递被测模块的数据，这些专供测试用的“假”模块称为被测模块的桩模块。

测试桩一般是 自顶向下集成时需要使用

驱动测试：

所谓驱动测试（自底向上集成时使用），就是你负责测试模块/方法是中间的，没有main（）入口，怎么编译，怎么启动呢？就需要写一个带main()的方法来调用你的模块/方法

桩模块的使命除了使得程序能够编译通过之外，还需要模拟返回被代替的模块的各种可能返回值(什么时候返回什么值需要根据测试用例的情况来决定)。

驱动模块的使命就是根据测试用例的设计去调用被测试模块，并且判断被测试模块的返回值是否与测试用例的预期结果相符

测试方法分类：

等价类划分方法

等价类划分：指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定；测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据，取得较好的测试结果。

等价类划分可有两种不同的情况：有效等价类和无效等价类。

边界值分析方法

边界值：是对等价类划分方法的补充，测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

错误推测方法

错误推测：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。例如：在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

因果图方法

前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件,但未考虑输入条件之间的联系，相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情,即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（逻辑模型）。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。

判定表驱动分析方法

判定表：是分析和表达多逻辑条件下执行不同操作的情况的工具。

正交表设计分析方法

有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。

功能图分析方法

功能图：由状态迁移图和布尔函数组成，状态迁移图用状态和迁移来描述。一个状态指出数据输入的位置（或时间），而迁移则指明状态的改变。同时要依靠判定表或因果图表示的逻辑功能。

场景模拟分析方法

指根据用户场景来模拟用户的操作步骤,这个比较类似因果图,但是可能执行的深度和可行性更好。

软件测试的基本流程（文字描述）

1测试需求分析阶段：阅读需求，理解需求，主要就是对业务的学习，分析需求点，参与需求评审会议

2制定测试计划阶段：主要任务就是编写测试计划，参考软件需求规格说明书，项目总体计划，内容包括测试范围（来自需求文档），进度安排，人力物力的分配，整体测试策略的制定。风险评估与规避措施有一个制定。

3测试设计阶段：主要是编写测试用例，会参考需求文档（原型图），概要设计，详细设计等文档，用例编写完成之后会进行评审。

4测试执行阶段：搭建环境，执行冒烟测试（预测试）-然后进入正式测试，bug管理直到测试结束

5测试评估阶段：出测试报告，确认是否可以上线

从心理学的角度出发思考，下面两个方面显著地提高了测试的功效和可靠性

首先，人们普遍认识到错误发现得越早，改正错误的成本越低，正确改正错误

的可能性也越大。

其次，程序员在开始基于计算机的测试时似乎要经历一个心理上的转变。从内部产生的压力似乎会急剧增长，并产生一个趋势，要“尽可能快地修正这个缺陷”。由于这些压力的存在．程序员在改正某个由基于计算机测试发现的错误时所犯的失误，要比改正早期发现的问题时所犯的失误更多一些。

检查与走查(Inspections And Walkthroughs)

代码检查与走查是两种主要的人工测试方法

代码检查与走查都要求人们组成一个小组来阅读或直观检查特定的程序。无论采用哪种方法，参加者都需要完成一些准备工作。准备工作的高潮是在参加者会议上进行的所谓“头脑风暴会”。“头脑风暴会”的目标是找出错误来，但不必找出改 正错误的方法。换句话说，是测试，而不是调试

代码检查是以组为单位阅读代码，它是一系列规程和错误检查技术的集合。对代码检查的大多数讨论都集中在规程、所要填写的表格等。

这个代码检查过程通常将注意力集中在发现错误上，而不是纠正错误。

是指从软件的产生直到报废的整个周期，包括可行性分析与项目计划，需求分析，概要设计和详细设计，编码，调试，维护七个阶段。

是指从测试项目计划建立到BUG提交的整个测试过程，包括软件项目测试计划，测试需求分析，测试用例设计，测试用例执行，BUG提交五个阶段。

也可以是（测试计划 → 测试设计 → 测试开发 → 测试执行 → 测试评估）。

软件测试生命周期并行与软件生命周期，存在于软件生命周期的各个阶段。

编写测试计划

设计测试用例

执行测试，发现缺陷提交测试报告

验证缺陷是否得到修改

编写测试总结报告

软件测试的原则 ：

十项原则

1 测试用例中一个必需部分是对预期输出或结果进行定义

2 程序员应避免测试自己编写的程序

3 编写软件的组织不应当测试自已编写的软件

4 应当彻底检查每个测试的执行结果

5 测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况

6 检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程是 否“做了其不应该做的”

7 应避免测试用例用后即弃，除非软件本身就是个一次性的软件

8 计划测试工作时不应默许假定不会发现错误

9 程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比

10 软件测试是一项极富创造性，极具智力的挑战性的工作

三个重要的测试原则：

• 软件测试是为发现错误而执行程序的过程。

• 一个好的测试用例具有较高的发现某个尚未发现的错误的可能性。

• 一个成功的测试用例能够发现某个尚未发现的错误。

良好的沟通和表达能力

具有怀疑与破坏的精神

扎实的软件测试基础知识

缜密的业务逻辑分析能力

处在用户的角度进行换位思考

足够的耐心、细心、信心、责任心

积极乐观向上的心态和团队协作能力

要有严谨、敢于承担责任、稳重的做事风格

善于自我总结、自我督促和不断学习的能力

1、Apache JMeter是一个Apache项目，可用作负载测试工具，用于分析和测量各种服务的性能，重点关注Web应用程序。

做压力测试的步骤如下:

1. 写脚本 或者录制脚本

2. 使用用户自定义参数

3. 场景设计

4. 使用控制器，来控制 模拟多少用户。

5. 使用监听器， 查看测试结果

链接：

测试是一种思想，一种思路，只要思路清晰了，什么东西都可以测试。

功能测试(Function test)

兼容测试(UI Test)

界面测试(UI Test)

性能测试(performance test)

安全性测试(Security test)

可用性测试(Usability Test)

测试的重点是在于设计而不是开发，如果重点是开发的话，那为什么别人部直接叫做开发的人来进行测试呢，如果真的叫开发来做而测试的话，那也违背了软件测试的原则，开发自己编写的程序不应该由自己来测试。真正很厉害的测试人员，他是可以设计出最少的测试用例，然后发现软件中最多的错误，真正有经验的测试人员，他对于自己测试的东西是很熟悉、很了解的，甚至一眼就能看出哪里有问题。

瀑布模型

特点：1.里程碑或基线驱动。2.过程逆转性很差或者说不可逆转。逆转可能会延误工期，增加成本，造成损失

优点：1.开发阶段清晰，便于评审、审计、跟踪、管理和控制。

缺点：1.不可逆或很难可逆。2.问题会积累，错误会传递发散扩大，导致成本和质量失控。

适用范围：1.在开发时间内需求不变化或很少变化。2.分析设计人员对此领域非常熟悉。3.低风险项目。4.用户使用环境稳定（如系统软件，工具软件）

快速原型模型

特点：1.容易适应需求的变化

优点：1.克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。

缺点：1.所使用的开发工具和技术不一定符合主流的发展；快速建立起来的系统架构加上连续的修改可能会导致产品质量低下。

适用范围：1.需求不明确或复杂系统。2.用户无法自主提出应用需求。

增量模型

特点：1.软件由一系列增量构件组成

优点：1.人员分配灵活，刚开始不用投入大量人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量。当配备人员不能在设定的时间内完成产品时，它提供了一种先推进核心产品的途径，这样即可先发部分功能给客户，对客户起到镇静剂作用。2.增量能够有计划的管理技术风险。

缺点：1.由于各个构件是逐渐并入已有的软件体系结构中，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。2.在开发过程中，需求变化是不可避免的，增量的灵活性可以使其适应这种变化的能力大大优于瀑布和快速原型模型，但也容易退化为边改边做模型，从而使软件过程的控制失去整体性。3.如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。

适用范围：1.系统容易拆分。2.开发人力比较少。3.特别适用于商业软件（如QQ，网游）

螺旋模型

特点：1.是一种周期性的方法进行系统开发。2.有许多“中间版本”。3.每个周期都包括需求定义、风险分析、工程实现和评审4个阶段

优点：1.设计上灵活，可在项目各个阶段进行变更。2.以小的分段来构建大型系统，使成本计算变得简单容易。3.客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性。

缺点：1.建设周期长，而软件技术更新比较快，所以经常出现软件开发结束后，和当前的技术水平有了很大的差距，无法满足当前用户需求。

适用范围：1.系统庞大，风险高。2.需求不太明确。

喷泉模型

特点：1.该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。

优点：1.提高软件项目开发效率，节省开发时间，适用于面向对象的软件开发过程。

缺点：1.由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。2.要求严格管理文档，使得审核难度加大，尤其是面对可能随时加入的各种信息、需求与资料的情况。

适用范围：1.面向对象的软件开发过程

参考书籍：《软件测试的艺术》《软件工程》第2版