测试基础知识

一、认识测试

1.1、测试概念

1.1.1、需求认识

软件测试就是验证软件产品特性是否满足需求

用户需求：简单理解为甲方提出的需求，或者为终端用户使用产品时必须要完成的任务。

软件需求：也称为功能需求。描述开发人员必须要实现的软件功能，是测试工作的基本依据。

1.1.2、软件的生命周期

软件开发的生命周期：需求分析—计划—设计—编码—测试—运行维护

1.2、常见的开发模型

1.2.1、瀑布模型

瀑布模型在软件⼯程中占有重要地位，是所有其他模型的基础框架。.

瀑布模型的每⼀个阶段都只执⾏ ⼀次，因此是线性顺序进⾏的软件开发模式。 瀑布模型的⼀个最⼤缺陷在于，可以运⾏的产品很迟才能被看到。这会给项⽬带来很⼤的⻛险，尤其 是集成的⻛险。因为如果在需求引⼊的⼀个缺陷要到测试阶段甚⾄更后的阶段才发现，通常会导致前 ⾯阶段的⼯作⼤⾯积返⼯，业界流⾏的说法是：“集成之⽇就是爆炸之⽇”。尽管瀑布模型存在很⼤ 的缺陷，例如，在前期阶段未发现的错误会传递并扩散到后⾯的阶段，⽽在后⾯阶段发现这些错误 时，可能已经很难回头再修正，从⽽导致项⽬的失败。但是⽬前很多软件企业还是沿⽤了瀑布模型的 线性思想，在这个基础上做出⾃⼰的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺⼊迭 代的思想。在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有⾜够的时间预留 给测试活动，否则将导致测试不充分，从⽽把缺陷直接遗留给⽤⼾。

瀑布模型的优点：

• 强调开发的阶段性
• 线性结构，每个阶段只执行一次
• 是其他模型的基础框架

瀑布模型的缺点：

• 测试后置，当前边各阶段遗留风险推迟到测试阶段会导致大面积返工影响项目进度。
• 周期太长，产品很迟才能被看到和使用，导致需求过时。

瀑布模型适用场景：需求固定的小型项目。

1.2.2、螺旋模型

⼀般在软件开发初期阶段需求不是很明确时，采⽤渐进式的开发模式。螺旋模型是渐进式开发模型的 代表之⼀。

这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新 的要求，它不允许有⼀段独⽴的测试时间和阶段，测试必须跟随开发的迭代⽽迭代。因此，回归测试的重要性就不⾔⽽喻了。

螺旋模型的优点：

• 强调严格的全过程风险管理
• 强调开发各阶段的质量
• 增加风险分析和原型

螺旋模型的缺点:

• 项目中可能存在的风险性和风险管理人员的技能水平有直接关系
• 需求人员，资金时间的增加和投入，可能会导致项目的成本过高

使用场景：规模庞大，复杂度高，风险大的项目。

1.2.3、增量模型和迭代模型

增量开发能显著降低项⽬⻛险，结合软件持续构建机制，构成了当今流⾏的软件⼯程最佳实践之⼀。

增量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发⼩组以⼀种循环的、可预测的⽅式驱动 产品 的开发。因此，在这种开发模式下，每⼀次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进⾏，测试⼈员需要与开发⼈员更加紧密地协作。

与此类似的有⼀个迭代开发，增量开发和迭代开发往往容易被⼈，但是其实两者是有区别的。增量是 逐块建造的概念，迭代是反复求精的概念。

**适用场景:**大型项目，需求不明确

1.2.4、敏捷模型

敏捷模型主要旨在帮助项⽬快速适应变更请求。因此，敏捷模型的主要⽬的是促进项⽬的快速完成。 要完成这项任务，需要敏捷。敏捷性是通过使过程适应项⽬，删除对特定项⽬可能不是必需的活动来 实现的。此外，避免任何浪费时间和精⼒的事情。

在敏捷模型中，需求被分解成许多可以增量开发的⼩部分。敏捷模型采⽤迭代开发。每个增量部分都 是在迭代中开发的。每次迭代都旨在⼩⽽易于管理，并且只能在⼏周内完成。⼀次为客⼾计划、开发和部署⼀个迭代。没有制定⻓期计划。

敏捷模型的四个特点：轻⽂档，轻流程，重⽬标，重产出。

1.2.4.1、Scrum敏捷模型

Scrum是敏捷模型的一种，又称为迭代式增量开发模型。

在该模型中有三个角色和五个重要会议：

三个角色：产品经理，项目经理，开发团队。

五个重要会议：

发布计划会议：产品经理讲解用户需求，对其进行评估和排序，制定出这一期迭代需要完成的需求列表

迭代计划会议：项目团队对需求进行任务分解

每日例会：团队成员回答今天计划做什么，有什么问题

演示会议：迭代结束召开，相关人员都参加，展示本次迭代成果。

回顾会议：项目团队对本次迭代总结，发现不足，制定改进计划。

敏捷中的测试：

轻⽂档和快速迭代

• 敏捷模型中强调轻⽂档，所以测试⼈员不应使⽤传统的Excel编写测试⽤例的⽅法，更多的是 使⽤思维导图、探索性测试（强调⾃由度，设计和执⾏同时进⾏，根据测试结果不断调整测 试计划）、⾃动化测试等
• 敏捷讲求合作，在敏捷项目组中，测试⼈员应多主动跟开发⼈员了解需求、讨论设计、⼀起 研究bug出现的原因。

1.2.5、测试模型

1.2.5.1、V模型

优点：

1. 明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间 各阶段的对应关系，有效提升测试的质量和效率。
2. V模型指出：

• 单元和集成测试应检测程序的执⾏是否满⾜软件设计的要求；
• 系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；
• 验收测试确定软件的实现是否满⾜⽤⼾需要或合同的要求

1.2.5.2、W模型（双V模型）

W模型增加了软件各开发阶段中应同步进⾏的验证和确认活动。W模型由两个V字型模型组成，分别代 表测试与开发过程，图中明确表示出了测试与开发的并⾏关系。

特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进⾏的

优点：

• 有利于尽早地全⾯的发现问题。例如，需求分析完成后，测试⼈员就应该参与到对需求的验证和确 认活动中，以尽早地找出缺陷所在。
• 对需求的测试也有利于及时了解项⽬难度和测试⻛险， 及早制定应对措施，显著减少总体测试时间，加快项⽬进度。

缺点：

• 需求、设计、编码等活动被视为串⾏的； • 测试和开发活动也保持着⼀种线性的前后关系，上⼀阶段完全结束，才可正式开始下⼀个阶段⼯ 作。
• 重流程，⽆法⽀持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理 ⾯临着困惑。

1.3、软件测试的生命周期

软件测试的⽣命周期是指测试流程，这个流程是按照⼀定顺序执⾏的⼀系列特定的步骤，去保证产品 质量符合需求。在软件测试⽣命周期流程中，每个活动都按照计划的系统的执⾏。每个阶段有不同的 ⽬标和交付产物

需求分析—测试计划—测试设计和测试开发—测试执行—测试评估—上线—运行维护

需求分析	测试计划	测试设计与开发	测试执行	测试评估	上线	运行维护
用户角度：软件需求是否合理 技术⻆度：技术上 是否可⾏，是否还 有优化空间 测试⻆度：是否存在业务逻辑错误、 冗余、冲突等问题	什么时候开发测试，什么时候结束测试，耗时多久。	参考需求文档，技术文档等编写测试用例 写测试用例明确使用的测试方法，测试工具，测试形势等。	充分利 ⽤测试 ⽤例和 测试⼯ 具对项 ⽬尽可 能做到 全⽅⾯的测试 覆盖	测试是 否通 过，本 次测试 是否有 遗留的 BUG， 最终测 试⼈员需要产 出⼀个 测试报 告	项⽬测试结 束后，将项 ⽬发布到线 上环境，测 试⼈员需求 跟踪上线并 测试线上环 境下软件的运⾏是否正 确	测试⼈员需要参与项⽬的 实施⼯作。测试⼈员对项 ⽬产品的业务和操作⾮常 了解，加上测试⼈员 的 沟通表达能⼒⼀般都⽐较 强，所以测试⼈员可以参 与⽤⼾使⽤软件的培训，在试运⾏项⽬时收集问题并及时反馈给相关负 责⼈

2、BUG

2.1、bug概念

定义：⼀个计算机bug指在计算机程序中存在的⼀个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障 (fault)，这些bug使程序⽆法正确的运⾏。Bug产⽣于程序的源代码或者程序设计阶段的疏忽或者错误。

2.2、描述bug的要素

描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果

2.3、bug的级别（具体定级根据公司要求）

通过定义bug的级别，能够明确看出问题的严重程度。⼯作中开发⼈员通常需要按照bug的级别来分配 优先级来处理bug，除此之外，通过bug级别也能够体现出开发⼈员的开发质量。

2.4、bug的生命周期

● New:新发现的Bug，未经评审决定是否指派给开发⼈员进⾏修改。

● Open：确认是Bug，并且认为需要进⾏修改，指派给相应的开发⼈员。

● Fixed:开发⼈员进⾏修改后标识成修改状态，有待测试⼈员的回归测试验证。

● Rejected：如果认为不是Bug，则拒绝修改。

● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。

● Closed：修改状态的Bug经测试⼈员的回归测斌验证通过，则关闭Bug。

● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发⼈员重新修改。

⽆效的bug ：open->closed open-rejected-closed

3、用例

设计测试⽤例的万能公式：功能测试+界⾯测试+性能测试+兼容性测试+易⽤性测试+安全测试。

功能测试

功能测试是⼀个试图发现程序与其外部规格说明之间存在不⼀致的过程。外部规格说明是⼀份从 最终⽤⼾的⻆度对程序⾏为的精确描述。功能测试通常是⼀项⿊盒操作。在进⾏功能测试时，需要对 规格说明进⾏分析以提炼测试⽤例，本课程中讨论的具体设计测试⽤例的⽅法尤其适⽤于功能测试。 然⽽，不仅是⼯作中还是⾯试中，可能会存在需求不明确的功能？这种情况下该如何进⾏功能测试？ ◦ 查找其他相关⽂档，来帮助理解所要测试的产品需要完成的⽬标; ◦ 尽量多参加项⽬组内的会议，⽐如需求讨论、设计讨论、计划讨论等，能够加深对产品的理 解; ◦ 召集相关⼈员，对你整理的结果进⾏讨论，通过评审后，这份⽂档就可以作为依据来设计你 的case了; ◦ 如果是⼀款已经上线的产品，可以多使⽤产品，有不懂的问产品经理; ◦ 也可以去看历史bug，可以了解到⼀些需要关注的东西

界⾯测试

对软件界⾯上所有的内容都需要进⾏测试。 要求： ◦ 整体界⾯测试界⾯的实现与设计图要求⼀致。 ◦ 界⾯元素测试 ▪ 控件操作验证 性能测试 性能测试和功能测试的区别是：功能测试检查软件是否做了，⽽性能测试测试软件做的好不好。

兼容性测试

软件是部署在硬件系统之上，并依赖所需要的软件环境。如QQ可以在PC端打开，也可以在移动 端打开；移动端⼜分为IOS系统和Android系统，且市⾯上⼿机⼜有不同的品牌、不同的机型、不同 的版本。软件是否能够在不同的环境下正确运⾏需要测试⼈员进⾏验证。 问题：既然市⾯上有众多版本的机器，那么在执⾏兼容性测试时难道所有的机型都需要全⾯覆盖吗？ 选取标准：

• 优先选择使⽤当前产品top级别的机型进⾏测试实际在企业中，后台是可以获取到使⽤产品的机型，并以报表的形式统计在后台，供产品⼈员或 其他⼈员制定策略参考。
• 选择主流的浏览器/机型进⾏测试

易⽤性测试

易⽤性测试的标准是检查产品是否具备简单易上⼿的属性。假如测试⼈员从来没有安装或使⽤过 该产品，作为⼀个新⽤⼾，对当前产品是否能够快速适⽤产品的使⽤流程。

安全测试

安全测试和性能测试⼀样都是⽐较⼤的领域。常⻅的安全问题如： 隐私数据明⽂显⽰。 参数未强校验导致SQL注⼊。 越权：普通⽤⼾也可以执⾏管理员权限的操作。

3.1、设计测试用例的方法

3.1.1、等价类

依据需求将输⼊（特殊情况下会考虑输出）划分为若⼲个等价类，从等价类中选出⼀个测试⽤例，如果这个测试⽤例测试通过，则认为所代表的等价类测试通过，这样就可以⽤较少的测试⽤例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

等价类分类：

• 有效等价类：对于程序的规格说明书是合理的、有意义的输⼊数据构成的集合，利⽤有效等价类验 证程序是否实现了规格说明中所规定的功能和性能
• ⽆效等价类：根据需求说明书，不满⾜需求的集合。

3.1.2、边界值

边界值分析法就是对输⼊或输出的边界值进⾏测试的⼀种⿊盒测试⽅法。通常边界值分析法是作为对 等 价类划分法的补充，这种情况下，其测试⽤例来⾃等价类的边界。

边界值包含：边界值和次边界值

3.1.3、正交法

正交试验设计(Orthogonal experimentaldesign)是研究多因素多⽔平的⼀种设计⽅法，它是根据正交 性，由试验因素的全部⽔平组合中挑选出部分有代表性的点进⾏试验，通过对这部分试验结果的分析 了 解全⾯试验的情况，找出最优的⽔平组合。正交试验设计是⼀种基于正交表的、⾼效率、快速、经济的试验。

3.1.4、判定表法

根据判定表法设计测试⽤例的步骤：

1. 确认需求中输⼊条件和输出条件
2. 找出输⼊条件和输出条件之间的关系
3. 画判定表
4. 根据判定表编写测试⽤例

3.1.5、场景法

现在的软件⼏乎都是⽤事件触发来控制流程的，事件触发时的情景便形成了场景，⽽同⼀事件不同的 触发顺序和处理结果就形成事件流。

通过运⽤场景来对系统的功能点或业务流程的描述，从⽽提⾼测试效果的⼀种⽅法。⽤例场景来测试 需求是指模拟特定场景边界发⽣的事情，通过事件来触发某个动作的发⽣，观察事件的最终结果，从 ⽽⽤来发现需求中存在的问题。我们通常以正常的⽤例场景分析开始，然后再着⼿其他的场景分析。 场景法⼀般包含基本流和备⽤流，从⼀个流程开始，通过描述经过的路径来确定的过程，经过遍历所 有的基本流和备⽤流来完成整个场景。场景主要包括4种主要的类型：正常的⽤例场景，备选的⽤例场 景，异常的⽤例场景，假定推测的场景

4、测试分类

4.1、按测试目标分类

4.1.1、界面测试

界⾯测试（简称UI测试)，指按照界⾯的需求（⼀般是UI设计稿）和界⾯的设计规则，对我们软件界 ⾯所展⽰的全部内容进⾏测试和检查，⼀般包括如下内容：

• 验证界⾯内容显⽰的完整性，⼀致性，准确性，友好性。⽐如界⾯内容对屏幕大小的⾃适应，换行，内容是否全部清晰展示；
• 验证整个界⾯布局和排版是否合理，不同板块字体的设计，图⽚的展⽰是否符合需求；
• 对界⾯不同控件的测试，⽐如，对话框，⽂本框，滚动条，选项按钮等是否可以正常使⽤，有效 和
• ⽆效的状态是否设计合理；
• 界⾯的布局和⾊调符合当下时事的发展。

4.1.2、功能测试

功能测试就是对产品的各功能进⾏验证，根据功能测试⽤例，逐项测试，检查产品是否达到⽤⼾要 求的功能。

根据产品特性、操作描述和用户⽅案，测试⼀个产品的特性和可操作⾏为以确定它们满⾜设计需求。 本地化软件的功能测试，⽤于验证应⽤程序或⽹站对⽬标用户能正确⼯作。使⽤适当的平台、浏览器 和测试脚本，以保证⽬标用户的体验将⾜够好，就像应⽤程序是专⻔为该市场开发的⼀样。功能测试 是为了确保程序以期望的⽅式运⾏⽽按功能要求对软件进⾏的测试，通过对⼀个系统的所有的特性和 功能都进⾏测试确保符合需求和规范。

4.1.3、可靠性测试

可靠性（Availability）即可⽤性，是指系统正常运⾏的能⼒或者程度，⼀般⽤正常向⽤⼾提供软件 服务 的时间占总时间的百分⽐表⽰。

*可靠性 = 正常运⾏时间/（正常运⾏时间+⾮正常运⾏时间）100%

4.1.4、安全性测试

安全性是指信息安全，是指计算机系统或⽹络保护⽤⼾数据隐私，完整，保护数据正常传输和抵御黑客，病毒攻击的能⼒。

系统常⻅的安全漏洞和威胁如下

• 输⼊域，如输⼊恶性或者带有病毒的脚本或⻓字符串；
• 代码中的安全性问题，如SQL/XML注⼊
• 不安全的数据存储或者传递
• 数据⽂件，邮件⽂件，系统配置⽂件等⾥⾯有危害系统的信息或者数据；
• 有问题的访问控制，权限分配等
• 假冒ID：⾝份欺骗
• 篡改，对数据的恶意修改，破坏数据的完整性

安全性测试的⽅法有代码评审，渗透测试，安全运维等，常⽤的静态安全测试⼯具有，Coverity， IBM Appscan Source，HPFortify，常⽤的动态安全测试有OWASP的ZAP，HP WebInspect等。其 中静态安全测试是常⽤的安全性测试的⽅法

4.1.5、易用性测试

易⽤性包含七个要素：符合标准和规 范，直观性，⼀致性，灵活性，舒适性，正确性和实⽤性。

4.2、按照这执行方式分类

4.2.1、静态测试

所谓静态测试（static testing）就是不实际运⾏被测软件，⽽只是静态地检查程序代码、界⾯或⽂档 中可能存在的错误的过程。

不以测试数据的执⾏⽽是对测试对象的分析过程，仅通过分析或检查源程序的设计、内部结构、逻辑、代码⻛格和规格等来检查程序的正确性。

4.2.2、动态测试

动态测试（dynamic testing），指的是实际运⾏被测程序，输⼊相应的测试数据，检查实际输出结 果和预期果是否相符的过程，所以判断⼀个测试属于动态测试还是静态的，唯⼀的标准就是看是否运行程序。

动态测试⽅法主要包含六种测试⽅法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆 盖、路径覆盖。

4.3、按照测试方法

4.3.1、白盒测试

⽩盒测试⼜称为结构测试或逻辑测试，它⼀般⽤来分析程序的内部结构，针对程序的逻辑结构来设 计测 试⽤例进⾏测试。

⽩盒测试的测试⽬的是，通过检查软件内部的逻辑结构，对软件中的逻辑路径进⾏覆盖测试；在程序 不 同地⽅设⽴检查点，检查程序的状态，以确定实际运⾏状态与预期状态是否⼀致

4.3.2、黑盒测试

⿊盒测试就是在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使⽤、是否能适当的接收输⼊数据⽽输出正确的结果，满⾜规范需求。

所以，⿊盒测试⼜称之为数据驱动测试，只注重软件的功能

⿊盒测试的优点 不需要了解程序内部的代码以及实现，不关注软件内部的实现。 从⽤⼾⻆度出发设计测试⽤例，很容易的知道⽤⼾会⽤到哪些功能，会遇到哪些问题，锻炼测试⼈ 员的产品思维

⿊盒测试⽤到的测试⽅法有，等价类，边界值，因果图，场景法，错误猜测法等

4.4、按照测试阶段分类

4.4.1、单元测试

• 测试阶段：编码后或者编码前（TDD）
• 测试对象：最⼩模块
• 测试⼈员：⽩盒测试⼯程师或开发⼯程师
• 测试依据：代码和注释+详细设计⽂档
• 测试⽅法：⽩盒测试
• 测试内容：模块接⼝测试、局部数据结构测试、路径测试、错误处理测试、边界测试

4.4.2、集成测试

集成测试也称联合测试（联调）、组装测试，将程序模块采⽤适当的集成策略组装起来，对系统的接口及集成后的功能进⾏正确性检测的测试⼯作。集成主要⽬的是检查软件单位之间的接⼝是否正确。

• 测试阶段：⼀般单元测试之后进⾏
• 测试对象：模块间的接⼝
• 测试⼈员：⽩盒测试⼯程师或开发⼯程师 • 测试依据：单元测试的模块+概要设计⽂档
• 测试⽅法：⿊盒测试与⽩盒测试相结合
• 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模 块缺陷对系统的影响

4.4.3、系统测试

对通过集成测试的系统进⾏整体测试，验证系统功能性和⾮功能性需求的实现。

• 测试阶段：集成测试通过之后
• 测试对象：整个系统（软、硬件）
• 测试⼈员：⿊盒测试⼯程师
• 测试依据：需求规格说明⽂档
• 测试⽅法：⿊盒测试
• 测试内容：功能、界⾯、可靠性、易⽤性、性能、兼容性、安全性等

4.4.4、回归测试

回归测试是指修改了旧代码后，重新进⾏测试以确认修改没有引⼊新的错误或导致其他代码产⽣错误。

在整个软件测试过程中占有很⼤的⼯作量⽐重，软件开发的各个阶段都会进⾏多次回归测试。随着系 统的庞⼤，回归测试的成本越来越⼤，通过选择正确的回归测试策略来改进回归测试的效率和有效性 是很有意义的。

回归测试主要由人工测试和⾃动化测试进⾏。

4.4.5、验收测试

• 测试⼈员：主要是最终⽤⼾或者需求⽅。
• 测试依据：⽤⼾需求、验收标准
• 测试⽅法：⿊盒测试
  试对象：整个系统（软、硬件）
• 测试⼈员：⿊盒测试⼯程师
• 测试依据：需求规格说明⽂档
• 测试⽅法：⿊盒测试
• 测试内容：功能、界⾯、可靠性、易⽤性、性能、兼容性、安全性等

4.4.4、回归测试

回归测试是指修改了旧代码后，重新进⾏测试以确认修改没有引⼊新的错误或导致其他代码产⽣错误。

在整个软件测试过程中占有很⼤的⼯作量⽐重，软件开发的各个阶段都会进⾏多次回归测试。随着系 统的庞⼤，回归测试的成本越来越⼤，通过选择正确的回归测试策略来改进回归测试的效率和有效性 是很有意义的。

回归测试主要由人工测试和⾃动化测试进⾏。

4.4.5、验收测试

• 测试⼈员：主要是最终⽤⼾或者需求⽅。
• 测试依据：⽤⼾需求、验收标准
• 测试⽅法：⿊盒测试
• 测试内容：同系统测试(功能…各类⽂档等) 单元测试