1. 第一章 测试理论

1.1. 什么是软件

软件（英语：software）是一系列按照特定顺序组织的计算机数据和指令，是计算机中的非有形部分。 软件是一种抽象的，计算机中的程序代码组成的产品。

在20世纪50年代，英国计算机科学家图灵已提出了程序测试的定义，测试是验证程序正确性的一种实验形式。 直到60-70年代，软件危机出现后，人们意识到测试的意义。

软件复杂度 程序代码的复杂度，软件产品的并发性，复杂性越来越高，对程序的正确性检测也越来越高

行业竞争大 由于用户审美提升与需求越来越高，现在一个新闻类app，就有百度新闻，网易新闻，趣头条，今日头条，各家公司都想做到完美，用户喜欢自己的产品，那就得从易用性，美观性，趣味性，快速性，等等等等方面超过其他的产品，那么大公司都会配备专门的功能测试岗位，性能测试岗位，乃至于更强大的测试开发岗位。

1.2. 软件测试概念

Software Testing软件测试：

在规定的条件下对程序进行操作（人工测试、自动化测试），以发现程序错误，衡量软件质量，并对其是否能满足需求进行评估。

1.2.1. 软件测试目的

有特定的目的，有特定的方法，提交错误信息，跟踪错误信息，发现软件问题，检查系统是否满足用户需求

以下这些属于软件测试吗？

• 上冲浪，聊QQ
• 使用word、excel完成老板的任务报告
• 打英雄联盟
• 使用计算器，核算账单

哪些软件测试

你现在是腾讯的测试工程师，负责绝地求生游戏测试，检测游戏功能玩法，以及是否有问题。

发现如下问题，这属于什么呢?

1.2.2. 什么是软件测试

• 软件测试是为了检验出程序错误而执行的一系列若干操作
• 软件测试可以人力执行也可以借助工具执行
• 软件测试过程可以运行软件也可以不运行软件，指的是动态测试与静态测试

1.3. 软件测试的发展

国内处于起步和迅猛发展的阶段。 大公司非常重视测试，初创型小公司对测试关注较少。 主要还是手工测试为主，自动化测试为辅。

国外的软件测试基本成熟，软件企业非常重视软件测试部门。 测试流程化体系严谨。 一线大公司还会成立软件测试中心，服务于子公司的软件开发。

软件测试也能追本溯源（不是程序员拍脑袋想出来的），也有其存在的必然性与合理性。

1957年之前－调试为主(Debugging Oriented) 20世纪50年代，计算机刚诞生不久，只有科学家级别的人才会去编程，需求和程序本身也远远没有现在这么复杂多变，相当于开发人员一人承担需求分析，设计，开发，测试等所有工作，当然也不会有人去区分调试和测试。然而严谨的科学家们已经在开始思考 “怎么知道程序满足了需求？”这类问题了。

1979–1982－破坏为主(Destruction Oriented) 1979年，《软件测试的艺术》 (The Art of Software Testing)第一版问世，这本书是测试界的经典之作。书中给出了软件测试的经典定义： The process of executing a program with the intent of finding errors. 测试是为发现错误而执行程序的过程。

1988–至今－预防为主(Prevention Oriented) STEP(Systematic Test and Evaluation Process)是最早的一个以预防为主的生命周期模型，STEP认为测试与开发是并行的，整个测试的生命周期也是由计划，分析，设计，开发，执行和维护组成，也就是说，测试不是在编码完成后才开始介入，而是贯穿于整个软件生命周期。没有100%完美的软件，零缺陷是不可能的，所以我们要做的是：尽量早的介入，尽量早的发现这些明显的或隐藏的bug，发现得越早，修复起来的成本越低，产生的风险也越小。

1.4. 软件测试目的

通过软件测试暴露软件中隐藏的错误和问题，便于考虑是否使用该产品。

例如我们去买手机，总得反反复复的观察，这个手机流畅度，手机的外壳是否有划痕，打电话是否正常，音乐播放是否正常等等,都是在验证手机产品是否有错误。

1.4.1. 测试目的之证明

软件开发者的角度

通过软件测试证明软件中不存在错误和问题，给与自己产品质量足够的信心。

在非正常情况和条件下软件的功能性

1.4.2. 测试目的之检测

一个成功的测试，是不懈的挖掘软件的错误，不断的完善产品。

满足用户需求是产品成功的关键点。

确保交付的产品符合用户的需求。

在产品上线前尽可能的发现和修复bug。

提供产品系统的质量报告

1.4.3. 测试目的之未雨绸缪

预防下一个版本可能出现的问题

预防用户使用过程中可能遇见的问题

提前检测软件开发过程中的问题和风险

提供用于分析的测试报告

1.4.4. 软件测试历程转变

1.5. 缺少软件测试发生的事故

软件中的Bug非常令人讨厌。但同时有缺陷的软件还有可能造成重大甚至致命的事故。下面是一些非常有名的软件事故：

1. 1962年，水手号火箭的致命BUG。 经济损失：1850万美元 1962年，携带空间探测器的水手1号火箭前往金星，在起飞后不久就偏离了预定航线。任务控制在起飞293秒后摧毁了火箭。事故的起因就在于一名程序员把一条手写的公式抄写为错误的计算机代码。从而将火箭引导偏离了航向。
2. 1979年，新西兰航空公司的一架客机因计算机控制的自动飞行系统发生错乱，撞在了阿尔卑斯山，导致257名乘客遇难。
3. 几乎引发的第三次世界大战. 1983年, 苏联导弹预警系统错误地报告遭到美国发射的5枚导弹攻击. 但幸运的是,当时的负责人认为如果美国真的要攻击的话, 发射的决不只是5枚导弹. 最终没有酿成大灾难。
4. 2012年，苹果ios 6系统首次使用地图服务，由于诸多定位出现错误，引发大批量用户投诉，48小时内有1000万个用户投诉Google地图。
5. 拼多多近期出现一个重大bug，程序员误改了代码，原本100元的中国移动充值卡，一分钱就可以购买，很短的时间内就损失了大量金额财产，这已经触犯了刑事责任。

因此公司中进行软件测试，是必须的！

1.6. 软件测试世人误解

• 测试等于调试
• 软件质量由测试部门负责
• 过分依赖验收测试
• 让初级开发执行测试工作
• 实现一切自动化
• 测试无穷尽
• 测试枯燥乏味，缺少技术含量

1.7. 软件测试工程师技能要求

1.8. 软件测试主要工作

• 执行软件测试需求分析，编写测试计划书，编写测试用例
• 执行测试过程，目的发现软件缺陷，进行软件缺陷管理，提交测试缺陷报告
• 衡量软件质量，检测易用性，兼容性，性能等

1.9. 互联网职业分类

互联网行业的薪资水准相对较高，入行一年超过其他行业薪资很正常。

互联网行业究竟有哪些职位呢，又分别适合哪些传统行业转型？

1.产品经理（Product Manager）

2.UI设计

3.前端设计（css/html/js）

4.后端（python/golang/java）

5.DBA(mysql/oracle)

6.运维（linux）

8.测试（software testing）

9.算法工程师

10.大数据工程师（Hadoop）

11.Android、IOS

12.架构师

13.运营

1.10. 开发为什么不进行测试?

开发人员自己做测试的问题： 人性角度、思维惯性、测试环境复杂度等方面。

开发人员是创造性思维，面对自己的代码产品无论怎么看都是很完美，恩，真香！

测试人员是破坏性思维，职责就是各种奇葩角度去发现潜在的问题，并且专职的测试人员通常在以往测试经验中积累大量典型易出错的模式，能够更客观全面的进行测试。

专职测试人员面对例如Web的GUI测试，基本不是简单的本地浏览器测试，而如大型企业可能会选择Selenium Grid搭建GUI集群进行千百台机器大规模测试，再比如使用Appium+Selenium Grid搭建大规模移动设备测试集群，这些都必须专职人员去完成，开发精力应该是在构建新业务功能，而不是维护测试设施。

1.11. 软件的生命周期

软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期。

整个生命周期包括问题定义与规划、需求分析、系统设计、软件编程、软件测试、软件运维等阶段。

1.12. 软件编码

把软件设计转化为计算机可以理解的程序，也就是以计算机编程语言来描述软件功能，用DBMS工具创建数据库数据。

1.13. 软件测试

测试是检验软件是否符合用户需求，是否达到软件质量标准，由专门测试部门执行。

常见测试活动分为：

• 单元测试，对每一个代码函数测试
• 集成测试，对代码组成的模块进行测试
• 系统测试，针对每一个功能需求，完整的设计测试环境，指派测试人员执行

1.14. 软件运维

此阶段软件已经交付上线提供用户使用，进入维护阶段，保证软件系统正常运转，如网站的7*24小时运行，因为软件系统可能出现如下问题：

• 由于用户增长造成的性能压力
• 服务器出现问题造成系统不可用
• 软件系统出现bug
• 系统升级出现未知bug

用户在使用过程中出现问题，反馈给技术支持人员，然后再递交给测试组，由研发组修复。

1.15. 软件项目组人员

项目组一般由项目经理领导且负责定制项目计划，工作分配，资源配置等。

项目组人员一般有：

• 分析
• 设计
• 研发
• 测试
• 运维

金字塔模式

矩阵化管理

1.16. 软件开发模型

由于项目、需求的模式不同，软件在生命周期过程中选择的软件开发模型也有所不同。

早期开发中，软件是边做边改，项目，需求没法管控，软件愈发复杂，开发越难。

开发模型开始演进，瀑布、原型、螺旋、敏捷等模式出现。

1.17. 瀑布型生命周期

瀑布模型如同工地里的建造盖房流程，使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求

的输出，下一阶段的工作就不展开。(银行体系用的最多，一个需求做一年，变化很少。以及印度开发者是瀑布模型的重度使用者)

优点：

明确划分了软件生命周期的各个环节。

强调早期软件计划，需求分析重要性。

清晰的工作流程，便于分工协作。

适合需求稳定的产品开发。

缺点：

线性的开发流程，存在巨大的风险。

依赖于早期的需求调查，不适应需求的变化，单一流程不可逆。

风险在后期可能才会暴露，且无法纠正。

如法保证用户的产品需求不变，开发过程无法更改。

(比如盖房子，照着图纸打好的地基可以承载7层楼，现在用户突然要加三层，那么地基就得重打，已经盖好的楼就

得爆破，这是不可能的操作。)

一、问题的定义及规划

确定软件开发目的以及可行性，指定开发计划。

二、需求分析

在确定软件开发可行性正确下，对软件所需的功能进行详细分析，明确客户需求，输出原型图。

三、软件设计

概要设计：架构的实现，表述各模块功能、模块接口和数据传递等事务。

详细设计：对表述的各模块深入分析，要求达到代码级别，将程序具体的实现描述出来，以及数据库设计。

四、软件编码

按照详细的模块功能表，编程人员编写出计算机可运行代码。

1.18. 快速原型模型

客户与开发公司紧密联系，开发周期较长，开发受到需求经常变更的影响。

增加客户与系统的交互

根据用户的主要需求，建立一个软件原型，然后让用户进行评价，然后根据用户的评价和提出的更多的需求来开发出相应的软件产品。通过逐步调整原型使其满足客户的要求。(例如室内设计，客户想要客厅装修成xx样，待你画好了效果图、客户一看，不行，我想要这样、我想要那样..)

细化软件需求

快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。

优点：

快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。

提供学习手段，通过开发原型和演示原型对开发者和使用者对整个系统了解有积极作用。

真正理解客户的需求。

缺点：

快速建立的系统结构可能产品质量低下。

1.19. 螺旋模型

螺旋模型结合了 瀑布模型与快速原型

将开发过程分为螺旋周期，每个螺旋周期和瀑布模型相符，沿着螺旋线旋转，坐标轴的四个象限表示四个活动。

1988年由巴里·勃姆提出的软件开发模型升级版，兼顾了瀑布模型的优点。

“螺旋模型”的核心就在于不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵，定义最重要的能实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到您满意的最终产品。

（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；

（3）实施工程：实施软件开发和验证；

（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。

螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风

险评估。

螺旋模型的优点：

引入了其他模型不具备的风险分析，使得软件遇见风险时可以停止，减少损失。

要求每个迭代阶段都需要构建原型，进行软件测试以减小项目开发风险。

整个过程有较高灵活性，开发过程的任意阶段自由应对变化。

缺点：

需要测试人员有丰富的风险评估经验和专业知识才能及时标识风险，减少软件缺陷损失，过多的评审迭代，造成开

发成本压力。

1.20. 敏捷开发之Scrum方法

20世纪90年代开始引起关注的，新型软件开发方法。

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

Scrum就是敏捷开发的具体方式。

Scrum的英文意思是橄榄球运动的一个专业术语，表示 “争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。

而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。

Scrum团队中三个关键角色：Scrum Master，Scrum Product Owner和Scrum开发团队

敏捷开发思想：

1.技术团队与业务专家之间的紧密协作和面对面沟通

2.频繁交付新的软件版本，自动化测试为核心

3.紧凑的团队组织

4.更好适应需求变化的代码编写方式与团队管理。

核心分为产品负责人，敏捷主管，技术团队

产品负责人采集用户需求，放入产品列表，通过计划会议讨论要实现哪些功能

敏捷开发不强调一次性就确定软件需求，完成开发，而是通过短期内的多次迭代，完成产品开发。

可能对于路飞学城来说，先完成用户登录注册的功能，确保是可工作的状态，就可以上线，后续功能继续迭代更

新。

软件是在逐步的改进增减的过程，最终达到用户满意度。

敏捷开发就是迭代+增量。

敏捷开发对于自动化测试的要求较高，开发人员注重开发，测试人员注重测试过程。

传统瀑布模型要求写好诸多的文档，敏捷开发不需要太多文档，测试人员就需要更好的掌握自动化技能。

1.21. 软件测试流程

软件测试思维导图

1.22. 软件测试模型

随着软件测试的发展，测试人员在大量实践中总结出一些测试模型，对测试活动进行抽象，如V模型、W模型等。

V模型和瀑布开发模型有着一些共同的特性，V模型中的过程从左到右，描述了基本的开发过程和测试行为。

V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。

局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现。

V模型

模型部分解释

单元测试

也叫做模块测试，进行正确性检查的工作。

单元测试要从程序内部结构设计测试用例，每个模块可以独立进行测试。

单元是什么？

比如Python中的类

图形化软件的一个窗口，一个功能菜单

集成测试

也叫组装测试，也就是将所有单元测试，进行有序的组合测试

系统测试

将整个软件系统看做一个整体进行测试，对功能，性能，硬件，软件所有环节进行测试。

单元测试目的测试功能是否满足要求。

系统测试目的测试系统是否满足性能的要求，以及不同的机器系统平台中运行,如一台机器我登陆多个qq，是否可

以运行，在windows，linux平台运行qq是否正常等方面。

验收测试

α测试

Alpha测试模拟实际操作环境下验收测试，如删档内侧，软件只是初步完成的产品，bug可能较多，不会进行上线

提供用户访问。

β测试

Beta测试系统已经通过内部测试，大部分错误已经修复，即将正式发布，在多个真实环境下发布，如不删档公

测。

对比α版本已经有了较大改进，但仍可能存在一些bug，需要大规模测试，例如DNF公司更新一个地图，提供公测

免费下载，由专业游戏玩家进行游戏结果反馈，开发者啊、再进行修复。

γ版本

y版本指的是正式版本，与上线版本几乎无区别。

1.22.1. 软件测试的W模型

开发和测试的协调工作图，绿色开发，橙色测试。

《软件验证和确认》原则中提出在软件需求设计阶段，也得有测试活动。

W模型就是开发流程一个V，测试一个V，组合而来的W

W模型优点

测试伴随整个软件开发生命周期，更早接入测试，可以更好的发现需求设计中的缺陷，修复成本也更低。

W模型缺点

依赖于软件开发和测试的前后线性关系，还是无法解决需求变更调整的问题

对于项目中不产出文档的事例，测试工作无法执行。(小型公司直接产出原型图，并不写需求说明书)

对于复杂业务，新人经验不足以测试需求，测试设计。

1.23. 测试覆盖率

覆盖率是用来度量测试完整性的一个手段，同时也是测试技术有效性的度量。

例如路飞学城我有一百个测试点，我目前完成了九十个，那么我功能点覆盖率就是90%

覆盖率=(至少执行一次的项目点)/ 项目点总数

特点

• 通过覆盖率数据，检验测试工作是否充足
• 分析出测试的弱点，对比测试人员的测试结果
• 指导我们设计能够增加覆盖率的测试用例，有效提高测试质量

测试覆盖率与黑盒

• 需求覆盖 在测试中，有哪些功能被测试了，被测试的频率
  • 需求覆盖=(验证的需求数)/(总需求数)
• 用例覆盖 体现每轮测试验证通过的用例数在总比例中的比重
  • 用例覆盖=(验证通过的用例数)/(总用例总数)

1.24. 软件测试常见术语

• c/s：Client客户端、Server服务端，指的是互联网中一台服务器安装服务端软件，每个用户都需要安装客户端软件，例如QQ、微信、游戏。
• b/s：Browser浏览器，Server服务器，不需要安装客户端，只需要有浏览器即可，例如淘宝网、京东网，便于维护与升级。
• bug：指的是软件中不符合用户需求的问题，软件存在的缺陷。
• Testing Environment：软件运行的平台、包括硬件、软件、网络配置。
• Test Case：测试执行之前的详细测试方案，包括测试环境、测试步骤、测试数据、预期结果。
  • 测试用例=数据输入+测试结果输出+测试环境配置
• Smoke Testing：在软件大规模测试之前，验证基本功能，决定是否有可测性，例如路飞学城的基本登录。

1.25. 测试人员情商素养

• 踏实细心
• 积极主动
• 好奇心、具有怀疑态度
• 良好的沟通交流能力
• 自我提高，持续学习
• 责任心
• ...

1.26. 测试人员的原则

所有测试动作必须追溯到用户需求

80%的产品缺陷都是在产品开发过程中的需求定义出现偏差引发的，如果需求得到准确的验证，可以消除80%的返工问题，节省投入成本40%。

尽早启动测试工作

Pareto法则应用于软件测试

Pareto(帕累托)法则是由意大利经济学家帕累托提出，又称为28效率法则【二八定律、帕累托定律、最省力法则、不平衡原则、犹太法则。】

人们采用二八定律，用于计量投入和产出之间可能存在的影响关系。

• 管理学：通常一个企业80%的利润来自于20%的项目。
• 心理学：
  • 20%的人集中了人类80%的智慧，出生就是鹤立鸡群。
  • 20%的人买时间，80%的人卖时间
  • 20%的人做事业，80%的人做事情
  • 20%的人正面思考，80%的人负面思考

在项目管理认证中（PMP）Pareto法则成效是：

• 抓住主要矛盾
• 科学分配时间和经历
• 把80%的资源花费在关键效益的20%的方面，这20%又能带动80%的发展，相辅相成，生生不息。

测试中的Pareto法则是指在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的缺陷，系统测试又能找出其余缺陷的80%，最后4%的缺陷可能在用户大范围、长时间试用下才会暴露。

不可能穷尽测试

很少会有对软件进行所有可能的测试，对大多数软件项目来说，应该使用适当的风险分析。这很看重测试经验，常识与感觉。

杀虫剂怪事

软件测试越多，对测试的免疫力也越强，例如开发和测试长时间相处，开发就知道测试人员的套路，也会尽量去避免。

为了克服杀虫剂怪事，测试人员必须不断编写更新的测试方案，对程序的不同部分进行测试，以找出更多软件测试。

前进两步、后退一步

测试中一个基本问题是，缺陷修复后总会以20%-50%的几率引入新的缺陷。每次修复后，必须重新运行先前所有的测试用例，确保系统不会以隐蔽的方式被破坏。

三心二意

• 细心(不要放过任何一个细节)
• 信心(对自己的测试结果有信心，防止开发人员说：我的程序不可能出错，你重新再去测！)
• 耐心
• 团队协作意识
• 软件缺陷预防意识

1.27. 软件工程标准

国内通用的软件工程标准主要有ISO9000以及CMM。

ISO9000系列标准是国际标准化组织质量管理和质量保证技术委员（ISO/TC176）会制定的国际标准，其核心标准是质量保证标准(ISO9001/2/3)和质量管理标准(ISO9004)。

CMM(Capability Maturity Model)即软件能力成熟度模型，是向软件组织提供如何增加对其开发和维护软件过程的控制能力，也就是评估软件能力与成熟度的标准。

ISO9000系列标准的基本思想，主要分为两条：

• 控制的思想，对产品形成的全过程-从采购原材料、加工制造到产品销售、售后服务进行控制。
• 预防的思想，对产品形成的全过程进行控制以及建立并有效运行自我完善机制达到预防不合格，从根本上减少或消除不合格产品。

根据ISO9000画出的软件管控图：

CMM是专为软件开发组织设计的，侧重于软件开发和改进，在产品的设计和开发的细节做了较多要求。