软件测试基础理论

1.软件测试定义：

软件测试(Software Testing)，在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

2.软件的分类：

软件 = 程序 + 数据 + 文档。

　　按照功能划分：
　　　　系统软件：如操作系统、数据库管理系统，各种驱动软件等
　　　　应用软件：如Office、金山词霸、QQ等
　　按照技术结构划分：
　　　　单机版本：如Office，画图工具等
　　　　C/S结构软件：如QQ、MSN等
　　　　B/S结构软件：如新浪、搜狐、google等
　　按照用户划分：
　　　　产品软件：Office、财务处理软件、金山毒霸等
　　　　项目软件：如为企业定制的OA系统等
　　按照开发规模划分：
　　　　类别  参与人数     开发时间
　　　　小型  10人以下  1-4个月
　　　　中型  10-100人  1年以下
　　　　大型  100人以上  1年

3.软件测试的对象：

① 源程序/目标代码
② 各开发阶段的文档（需求规格说明、概要设计说明、详细设计说明及其它相关文档）

4.软件测试的目的：

软件测试的目的是尽可能多的发现软件缺陷。检查系统是否满足需求，站在用户角度思考产品或项目功能实现的正确性。

测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征。可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，通过分析也能帮助我们设计出有针对性的检测方法，改善测试的有效性。

5.软件测试的原则

1）所有测试的都应以软件设计需求规格说明书为标准进行。
2）应当把“尽早地不断地进行软件测试“作为软件开发者的座右铭。
3）程序员应避免检查自己的程序。
4）充分注意测试中的群集现象。
5）严格执行测试计划，排除测试的随意性。
6）妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。
7）完全测试是不可能的

6.软件测试分类

单元测试：

单元测试又称模块测试，针对软件设计中的最小单位——程序模块，进行正确性检查的测试工作。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
单元定义：C中指一个函数，Java中指一个类，在图形化的软件中，单元一般指1个窗口，1个菜单。
如何进行单元测试：单元测试主要用白盒测试，先静态地检查代码是否符合规范，然后动态运行代码，检查其实际运行结果，检查程序的运行结果是否正确是一个最基本的要求，还要关注容错处理，程序的边界值处理等。

a、单元测试的内容

模块接口测试：调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；所测模块调用子模块时，它输入给子模块的参数与子模块的形式参数在个数、属性、顺序上是否匹配；是否修改了制作输入用的形式参数；输出给标准函数的参数在个数、属性、顺序上是否正确；全局量的定义在各模块中是否一致；限制是否通过形式参数来传递。
局部数据结构测试：局部数据结构是最常见的错误来源，局部数据结构测试主要包括不正确或不一致的数据类型说明；使用尚未赋值或尚未初始化的变量；错误的初始值或错误的却缺省值；变量名拼写错或书写错；不一致的数据类型。可能的话，除局部数据之外的全局数据对木块的影响也需要查清。
路径测试：选择适当的测试用例，对模块中重要的执行路径进行测试。
错误处理测试：要求能遇见出错的条件，并设置适当的出错处理，以便在一旦程序出错是，能对出错程序重做安排，保证其逻辑上的正确性。以下情况表明模块的错误处理功能半酣有错误或缺陷：出错描述难以理解；出错的描述不足以对错误进行定位，不足以确定出错的原因；显示的错误与实际的错误不符；对错误条件的处理不正确；在对粗无进行处理之前，错误条件已经引起系统的干预等。
边界测试：要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。

b、单元测试的步骤

在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。
单元测试的辅助模块：
驱动模块--相当于所测模块的主程序，它接受测试数据，把这些数据传送给所测模块，最后再输出实测结果。
桩模块—也叫做存根模块，用于代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事都不做。
驱动模块和桩模块的编写会给测试带来额外的开销。因为他们在软件交付时不作为产品的一部分一同交付。为了能够正确地测试软件，桩模块可能需要模拟实际子模块的功能，这样，桩模块的建立就不是很轻松了。

模块的内聚程度高的话，可以简化单元测试的过程。如果一个模块要完成多种功能，且以程序包的形式出现的也不少见，这是就可以把这个模块看成几个小程序，分别进行单元测试，对关键模块还要做性能测试。对支持某些标准规程的程序，更要招收进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。

集成测试：

集成测试又叫组装测试，通常在单元测试的基础上，将所有程序模块进行有序的、递增的测试。重点测试不同模块的接口部分。

非渐增组装测试（非增式集成测试）：将单元测试后的模块按照总体的结构图一次性集成起来，然后把连接的整体进行程序测试。一般用黑盒法来编写测试集并进行测试。程序错误易出现，不容易集成成果。单元测试使用的辅助模块多，适合于规模小的开发系统。
渐增组装测试（增式集成测试）：在单元测试的基础上，采用自顶向下或自底向上逐层安装测试，直到最后安装测试完毕。也可采用自顶向下与自底向上相结合集成测试，单元测试与集成测试相结合来进行集成测试。将错误分解，容易找到错误并测试成功，适合于大规模的开发系统。

系统测试：

指将整个软件系统看为一个整体进行测试，包括对功能、性能、以及软件所运行的软硬件环境进行测试。

验收测试：

验收测试指按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。在系统测试的后期，以用户测试为主或有测试人员等质量保证人员共同参与的测试。

α测试：指的是指的是由用户，测试人员、开发人员等共同参与的内部测试。
β测试：指的是内测后的公测，即完全交给最终用户测试

软件测试一般分α、β、λ三个阶段，α是第一阶段，一般只供内部测试使用；β是第二个阶段，已经消除了软件中大部分的不完善之处，但仍有可能还存在缺陷和漏洞，一般只提供给特定的用户群来测试使用；λ是第三个阶段，此时产品已经相当成熟，只需在个别地方再做进一步的优化处理即可上市发行。

验收测试的重要性：验收签字,收钱。

静态测试：

指不实际运行被测软件，而只是静态地检查程序代码、界面和文档中可能存在的错误的过程。

动态测试：

指实际运行被测程序，输入相应的测试数据，检查实际输出结果与预期结果是否相符。（动态测试方法为结构和正确性测试；动态测试工具Robot、QTP等）

黑盒测试：

指的是把被测的软件看做一个黑盒子，我们不关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出

白盒测试：

指的是把盒子打开，去研究里面的源代码和程序结构。

白盒测试方法包括：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖，六种覆盖方法中，覆盖准则由弱到强依次是语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。其中，语句覆盖是使得程序中每个语句至少被执行一次；判定覆盖是使得程序中的每个分支至少都通过一次；条件覆盖是使得判定中的每个条件获得各种可能的结果；判定/条件覆盖是使得判定中的每个条件取到各种可能的值，并使每个判定取到各种可能的结果；条件组合覆盖是使得每个判定中条件的各种可能组合都至少出现一次。

软件公司中，往往采用黑盒测试&白盒测试相结合的方式。

静态黑盒测试：看文档，看页面等
静态白盒测试：看源代码等
动态黑盒测试：使用软件等
动态白盒测试：运行源代码等

软件调试技术：试探法（强行排错法）、回溯法、对分查找法、归纳演绎、原因排除法

灰盒测试：

是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。

功能测试：

是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求。

逻辑功能测试(functiontesting)
界面测试(UItesting)
易用性测试(usability testing)
安装测试(installationtesting)
兼容性测试(compatibilitytesting)

性能测试：

是软件测试的高端领域，通常我们所说的高级软件测试工程师一般就是指性能测试或是白盒测试工程师。

时间性能（事务响应时间等）
空间性能（系统资源消耗）

负载：模拟业务操作对服务器造成压力的过程
性能测试：模拟用户负载来测试系统在负载情况下，系统的响应时间、吞吐量等指标是否满足性能要求
负载测试：在一定软硬件环境下，通过不断加大负载(阶梯式)来确定在满足性能指标情况下能够承受的最大用户数。找出系统的拐点，往往用于容量规划测试
稳定性测试：在一定软硬件环境下，长时间(7*24小时)运行常规负载(波浪式)，确定系统在满足性能指标的前提下(加大1.5到2倍)是否运行稳定
压力/强度测试：在一定软硬件环境下，通过高负载的手段来使服务器资源(硬件资源)处于极限状态，测试系统在极限状态下长时间运行是否稳定
配置测试：测试不同配置反映出来的不同性能，合理地调配资源，提高系统运行效率
性能基准测试：基于固定的硬件环境和部署架构对系统进行测试，然后与上一版发布时的系统指标进行对比，发现是否有恶化趋势
狭义并发：所有用户在同一时刻做同一件事情或操作。多适用于性能测试、负载测试、压力测试、稳定性测试场景
广义并发：多个用户对系统发出了请求或者进行了操作，但这些请求或操作可以是不同的。多适用于混合场景、稳定性测试场景

并发用户数、响应时间、系统吞吐量之间的关系：当系统并发用户数较少时，系统的吞吐量也低，系统处于空闲状态，我们往往把这个阶段称为“空闲空间”。当系统整体负载并不是很大时，随着系统并发用户的增长，系统的吞吐量也会线性增长，我们往往把这个阶段称为“线性增长区间”。随着系统并发用户数的进一步增长，系统的处理能力逐渐趋于饱和，因此每个用户的响应时间会逐渐变长，相应的系统的整体吞吐量并不会随着并发用户数的增长而继续线性增长，我们往往把这个时间点称为系统的“拐点”。随着系统并发用户数的增长，系统处理能力达到过饱和状态，此时如果继续增加并发用户数，最终所有用户的响应时间会变得无限长，相应的系统的整体吞吐量会降为零，系统处于被压垮的状态，我们往往把这个阶段称为“过饱和区间”。

回归测试：

指对软件的新版本测试时，重复执行上一个版本测试时的用例。可使用自动化测试进行回归测试

冒烟测试：

是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测试性。

随机测试：

是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。

安全渗透测试：

常用方法：针对性测试(“开灯”测试)、外部测试、内部测试、盲测、双盲测试(隐秘测试)
执行步骤：1）规划和侦察、2）安全扫描、3）获取访问权限、4）维持访问权限、5）入侵分析
常用工具：Nmap、Aircrack-ng、sqlmap、Wifiphisher、AppScan

移动端专项测试：

安装、卸载、特殊操作、交互、通知、交叉事件、兼容性、流量、耗电量、弱网、边界

7.测试计划

一份好的测试计划要包括测试范围、测试策略、测试资源、测试进度和测试风险预估，并且每一方面都要给出应对可能出现问题的解决办法。

传统软件产品的测试策略：金字塔模型
互联网产品的测试策略：菱形模型

8.测试用例

好的测试用例的定义：一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而与能否发现缺陷无关。
好的测试用例的特征：整体完备性、等价类划分的准确性、等价类集合的完备性
常用测试用例设计方法：等价类划分(有效、无效)、边界值分析、错误推测、因果图、判定表驱动分析、正交实验设计、功能图分析、场景设计、形式化、扩展有限状态机等，最常用的是前3种
好的测试用例设计：1）全面地、无遗漏地识别出测试需求是至关重要的，2）综合运用设计方法来全面地设计测试用例

需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，代码覆盖率统计工具，如Java的JaCoCo、JavaScript的Istanbul

9.测试缺陷

缺陷内容：标题、概述、影响、环境配置、前置条件、重现步骤、期望结果和实际结果、优先级和严重程度、变通方案、根原因分析、附件

严重级：
1）严重：系统崩溃、数据跌势、数据毁坏。
2）较严重：操作性错误、错误结果、遗漏功能。
3）一般：小问题、错别字、UI布局、罕见故障。
4）建议：不影响使用的瑕疵或更好的实现。
优先级：
1）最高优先级：立即修复，停止进一步测试。
2）次高优先级：在产品发布之前必须修复。
3）中等优先级：如果时间允许应该修复。
4）最低等优先级：可能会修复，但是也能发布。
生命周期：
创建、修复中、已解决/延期处理/拒绝处理、重新打开/关闭

将常见缺陷整理为检查表(checklist)，用于优化、补充测试用例

10.测试报告

内容：测试报告主要包括测试项目背景介绍、测试计划、测试结果及发现以及测试分析等相关内容，这些都属于测试报告中最基础的内容，也是最重要的内容。

1.测试项目背景介绍，主要对测试报告编写目的、系统名称、环境、专业术语等相关内容进行介绍，同时还要对测试报告里面引用的参考资料全部列出。
2.测试计划，主要对测试具体计划进行列出，利用表格将测试内容进行调出，逐一说明系统的具体功能以及指标，同时还要介绍测试进度。
3.测试结果及发现，通过测试可以获得动态输出结果，然后与动态输出相关要求展开对比，对其中存在的一些问题及时发现并解决。
4.测试分析，这也是测试报告最重要的一项内容，主要对测试环节软件存在的问题进行记录，然后分析可能产生的影响，并提出合理的解决对策。

11.功能测试工程师核心竞争力

测试策略设计能力
测试用例设计能力
快速学习能力
探索性测试思维
缺陷分析能力
自动化测试技术
良好的沟通能力

12.测试开发工程师核心竞争力

测试开发岗位的核心是“测试”，“开发”的目的是更好地服务于测试，设计、开发帮助测试人员提高效率并解决实际问题的工具

测试系统需求分析能力
更宽广的知识面

13、软件测试过程模型

（1）V模型
优点：是瀑布模型的变种，反映了测试活动与分析和设计的关系，从左到右，描述了基本的开发过程和测试行为，非常明确的标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对于关系。
缺点：仅仅把测试过程作为在需求设计、概要设计、详细设计及编码之后的一个阶段，不能体现“尽早地和不断地进行软件测试”的原则。容易使人认为测试时软件开发的最后一个阶段，主要是针对程序进行测试寻找错误，而是需求分析阶段隐藏的问题一直到后期的验收测试才被发现。

 （2）W模型
在V模型中增加软件各开发阶段应同步进行的测试，被演化为W模型，因为开发是“V”，测试也是与此并行的“V”。基于“尽早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活动应遵循IEEE std 1012-1998《软件验证和确认（V&V）》的原则。
局限性：跟V模型一样把软件开发是为需求、设计、编码等一系列串行的活动。同样的，软件开发与测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一个阶段，这样就无法支持迭代、自发性以及变更调整。对于当前很多文档需要时候补充，或者根本就没有文档的做法下（这已成为一种开发的文化），开发人员和测试人员都面临同样的困惑。

（3）H模型
将测试活动完全独立出来，形成一个独立的流程，将测试准备活动和测试执行活动清晰地表现出来。 

这个示意图仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”。图中的其他流程可以是任意开发流程（设计流程、编码流程等，也可以是测试流程自身），只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以（或者说需要）进行了。
H模型揭示了：
1）软件测试不仅仅指测试的执行，还包括很多其他的活动。
2）软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。
3）软件测试要尽早准备，尽早执行。
4）软件测试是根据被测物的不同分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。

（4）X模型
X模型的目标是弥补V模型的一些缺陷。X模型左边描述的是针对单独程序片段进行的相互分离的编码和测试，此后进行频繁的交接，通过集成最终合成可执行的程序。这一点在图的右上方得以体现，而且这些可执行程序还需要进行测试，已通过测试的成品可以进行封板并提交给用户，也可以作为更大规模和范围内集成的一部分。此外，X模型还定位了探索性测试，即不进行事先计划的特殊类型的测试，诸如“我这么测一下，结果会怎么样”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
 

（5）前置测试模型

前置测试模型体现了以下的要点：
1）开发和测试相结合
2）对每一个交付内容进行测试，不仅仅是源程序代码，还包括可行性报告、业务需求说明、系统设计文档等。
3）在设计阶段进行测试计划和测试设计
4）测试和开发结合在一起，在开发阶段以编码—测试—编码—测试的方式实现，也就是说程序片段一旦编写完成，就会立即进行测试。
5）让验收测试和技术测试保持相互独立。