软件测试学习一（基础理论知识）

软件测试学习一（基础理论知识）

一、软件测试定义、目的、原则

定义：通过人工或自动的技术手段来检验软件系统是否满足规定的要求，并进行判断和评估的过程。
目的：验证软件是否满足需求，发现并减少软件缺陷，保障软件质量。
原则：

• ① 测试的本质是证明软件存在缺陷。认为无错就是好的想法是不对的，计划测试工作时不应该默许假定不会发现错误。
• ② 穷尽测试是不可能的。
• ③ 测试尽早介入，并不断进行。
• ④ 缺陷具有集群性（2/8原则) 80%的错误是由20%的模块引起的。
• ⑤ 杀虫剂悖论，测试人员一直使用相同手段重复测试会有局限，测试人员应互相检测。开发人员避免检查自己的程序。
• ⑥ 测试活动依赖于测试内容，不同项目采取不同测试方法。
• ⑦ 设计测试用例时应考虑到合法输入和不合法的输入。检查程序是否做了该做的事情，还要检查程序是否做了不该做的事情。多余的有时候会带来潜在危险或错误。
• ⑧ 应长期保留所有测试用例，保留测试用例有助于以后修改程序后的回归测试。

二、软件测试类型及流程

2.1 软件测试级别

• 功能测试：对软件的逻辑功能进行的一种测试，验证程序功能是否满足需求。
• 接口测试：对软件之间进行数据交互的接口进行的一种测试，验证程序接口是否访问正常。
• 自动化测试：使用工具或代码完成测试。
• 性能测试：模拟大量用户使用、长时间运行，对系统服务端运行状态进行监测。性能测试是一种统称，按照测试的目的不同包含了负载测试、压力测试、稳定性测试、大数据量测试等。
• 安全测试：针对系统可能存在的漏洞进行探测、发现的过程，可以从系统的整个网络结构设计、操作系统的安全、数据库的安全、系统程序代码的安全、业务逻辑的安全等众多方面进行开展。

2.2 软件开发的几个阶段

1. 项目启动阶段：了解客户需求、配置相关资源
2. 项目设计阶段：明确客户需求，确立软件开发、测试的方法
3. 项目执行阶段：开发与测试阶段
4. 项目竣工阶段：软件的上市、后期维护与技术支持

2.3 软件测试流程

编写需求分析并评审→编写测试计划并评审→设计测试用例并评审→搭建测试环境、执行测试用例、提交缺陷报告→进行评估和总结

1. 测试需求分析
对需求进行评审、理解，分析需求点，确保各部门需求理解一致。

• 目的：明确需求！！！

2. 测试计划制定
编写测试计划，测试计划包括测试的安排、时间节点、进度、人力及环境等，整体测试策略的制定，风险评估与预警，提前暴露问题等。
3. 测试设计阶段
根据需求分析设计和编写测试用例，并进行用例评审，查漏补缺。

• 评审目的：
  • 测试用例的内容是否完整，测试步骤是否描述清晰，预期输入和输出是否描述准确。
  • 测试数据的准备是否恰当、准确。
  • 功能点用例设计覆盖是否足够多，是否有遗漏或需要补充的功能点。
  • 产品需求是否理解透彻，是否还存在不明确的功能点，通过评审进行确认。

4. 测试执行阶段
开发完成编码之后，提交测试，测试人员搭建测试环境，根据测试用例执行测试，提交缺陷报告并跟踪、记录，确保bug全部解决。

• 第一轮测试：功能测试，测试全部功能，再进行回归测试。
• 第二轮测试：回归测试，进行bug的回归，对开发解决的问题进行再次验证。
• 验收测试，产品人员为主，测试人员为辅。
• 上线后的功能回归，对基本功能进行回归，验证是否有问题。

5. 测试评估，上线
进行测试评估、总结，验收通过后，部署上线，测试人员再进行线上功能验证，通过之后，发送测试报告。

软件测试工程师的工作内容

• 1.寻找软件中的bug，并且越早发现越好。
• 2.确认bug的可重复性以及bug产生的步骤。
• 3.确认bug是否被解决。
• 4.测试方法，测试计划，测试平台，测试代码，测试用例，测试文档，测试报告的确定、编写和执行。

三、软件测试分类

3.1 按开发阶段划分

3.1.1 单元测试

单元测试又称模块测试，是对软件的组成单元进行的测试。【例如：登录测试】

• 目的：检验软件基本组成单位的正确性
• 测试阶段：编码后或者编码前（TDD）
• 测试对象：最小模块（软件设计的最小单元）
• 测试人员：白盒测试工程师或开发人员
• 测试依据：代码和注释+设计详细文档
• 测试方法：白盒测试
• 测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

3.1.2 集成测试

集成测试又称联合测试（联调）、组装测试、接口测试，是将程序模块采用集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。【例如：京东购物用微信支付】

• 目的：检验软件单位之间的接口是否正确
• 测试阶段：一般的单元测试之后进行
• 测试对象：模块间的接口
• 测试人员：白盒测试工程师或开发工程师
• 测试依据：单元测试模块+概要设计文档
• 测试方法：黑盒测试和白盒测试相互结合
• 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能的正确性、全局数据结构、单模块缺陷对系统的影响

3.1.3 系统测试

对软件整个系统进行测试，包括对功能、性能以及软件所运行的硬软件环境等进行测试。时间大部分在系统测试执行阶段，包括回归测试和冒烟测试。【例如：QQ能不能注册、登录、聊天发消息（功能） ，人数太多会不会卡顿（性能）】

• 测试阶段：集成测试之后
• 测试对象：整个系统（软、硬件）
• 测试人员：黑盒测试工程师
• 测试依据：需求规格说明文档
• 测试方法：黑盒测试
• 测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全等

（1）回归测试（Regression Tesing）
回归测试指的在软件进行更新迭代之后，新增加的内容和原来的功能进行测试，以确认修改没有引入新的错误或导致其他代码产生错误。
在整个软件的过程中占有很大的工作量比重，软件开发的各个阶段都会运行多次回归测试。

（2）冒烟测试（Regression Tesing）
对一个硬件或硬件组件进行更改或修复后，直接给设备加电，如果没有冒烟就认为该组件通过了测试。

• 目的：确认软件的基本功能正常，可以进行后续的测试工作
• 测试对象：每一个新编译的需要正式测试的软件版本
• 执行者：版本编译人员。

冒烟测试一般是开发人员开发完毕之后送给测试人员进行测试时，测试人员要先进行冒烟，用以保证基本功能是正确的，不会阻碍后续的测试。

3.1.4 验收测试

验收测试也叫做交付测试，是部署软件之前的最后一个测试操作。

• 目的：保证软件的准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件的购买者展示该软件的原始的需求。
• 测试阶段：系统测试之后
• 测试对象：整个的系统（包括软、硬件）
• 测试人员：最终的用户或者需求方
• 测试依据：用户需求和验收标准
• 测试方法：黑盒测试
• 测试内容：同系统测试一样（功能、界面、可靠性、易用性、性能、兼容性、安全等）

3.2 按测试实施组织划分

3.2.1 α测试（Alpha Testing）

属于验收测试，是公司内部的用户在模拟实际操作环境下进行的测试（用户在开发环境下进行的测试）。α测试是由用户测试的，测试和开发人员不得参与。
目的：评价软件产品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持）

3.2.2 β测试（Beta Testing）

属于回归测试，指的是在不同场所下，最终用户在一个或者多个场所中进行测试。

3.2.3 第三方测试

介于开发方和用户方间组织的测试。

α测试和β测试的区别

• 测试的场所不同：α测试是把用户请到开发方的场所来测试，β测试是指在一个或多个用户的场所进行的测试。【例如：游戏内测版本】
• 测试的环境不同：α测试的环境是受开发方控制的，用户的数量相对比较少，时间比较集中；而 β测试的环境是不受开发方控制的，用户数量相对比较多，时间不集中。
• 测试的周期不同：α测试先于β测试执行。通用的软件产品需要大规模的β测试，测试周期比较长。

3.3 按测试执行方式划分

3.3.1 静态测试

静态测试是指不运行被测程序本身，仅通过分析和检查源程序的语法、结构、过程、接口等来检查程序的正确性。根据需求文档，对代码的逻辑、结构、语法等进行检查、找错。【静态测试属于白盒测试】

• 检查项：代码的风格和规则审核；程序设计和结构审核；业务逻辑的审核、走查、审查与技术复审手册。
• 静态质量：六个方面来衡量软件的质量：功能性、可靠性、可移植性、可用性、有效性、可维护性。
• 代码静态分析和文档测试都是属于静态测试。

3.3.2 动态测试

动态测试指的是运行被测的程序。检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性的等性能，这种方法主要是由三部分进行组成的：编写测试用例、执行程序、分析程序运行结果。
大多数的软件测试就是属于动态测试的。

3.4 按是否查看代码划分

3.4.1 黑盒测试

黑盒测试又称功能测试，测试中把被测的软件当成一个黑盒子，不关心代码的内部实现过程，只关心代码运行的最终结果。【源代码不可见，功能可见】
——主要应用于系统测试阶段

• 黑盒测试方法：等价类、边界值、因果图、判定表、正交法、场景设计法、错误猜测法等。

3.4.2 白盒测试

白盒测试又称结构测试，透明盒测试、逻辑驱动测试或基于代码的测试。白盒是指可以看见里面的代码，要分析研究源代码的实现过程等。【全部代码可见，功能不可见】 接口测试也是一种白盒测试。
——主要应用于单元测试阶段

• 白盒测试方法：条件覆盖法、语句覆盖法、逻辑覆盖法、分支覆盖法、循环覆盖法、路径覆盖法等。
• 逻辑覆盖包括:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖
  • 1.语句覆盖：每条语句至少执行一次。
  • 2.判定覆盖：每个判定的每个分支至少执行一次。
  • 3.条件覆盖：每个判定的每个条件应取到各种可能的值。
  • 4.判定/条件覆盖：同时满足判定覆盖条件覆盖。
  • 5.条件组合覆盖：每个判定中各条件的每一种组合至少出现一次。
  • 6.路径覆盖：使程序中每一条可能的路径至少执行一次。

3.4.3 灰盒测试

灰盒测试是介于白盒测试与黑盒测试之间的一种测试，主要用于集成测试阶段。不仅关心输入输出结果，同时还要关心代码内部实现过程。【部分代码可见，功能不可见】
——主要应用于集成测试阶段

3.4.4 黑盒测试与白盒测试的优缺点

黑盒测试

• 优点
  • 比较简单，不需要了解软件内部代码及实现
  • 与软件的内部实现无关
  • 以用户角度出发，很容易知道用户会用到哪些功能，会遇到哪些问题
  • 基于软件开发文档，能知道软件实现了文档的哪些功能
  • 在做软件自动化测试时较为方便
• 缺点
  • 无法保证软件代码内各个主要路径都被覆盖到，容易导致测试不很完全
  • 自动化测试的复用性较低

白盒测试

• 优点
  • 针对软件代码和路径进行测试，相对易于调试，容易发现bug产生的原因
• 缺点：
  • 程序运行会有很多不同的路径，不可能测试所有的运行路径
  • 测试基于代码，只能测试开发人员做的对不对，而不能知道设计是否正确，可能会漏掉一些功能需求
  • 系统庞大时，测试开销会非常大

3.5 按是否手工执行划分

3.5.1 手工测试

手工测试是手动一个一个的输入用例，然后观察结果，属于比较原始但是必须的一种。

• 优点：自动化无法替代探索性测试、发散思维类无既定结果的测试。
• 缺点：执行的效率比较慢。量大易错。

3.5.2 自动化测试

自动化测试就是将手工测试的过程转换成代码，让机器去执行。

• 自动化测试有功能测试自动化、性能测试自动化、安全测试自动化。通常我们所说的自动化测试就是指的是功能自动化测试
• 自动化测试按照测试的对象来分：接口测试、UI测试等。接口测试的ROI（产出投入比）要比UI测试高。

3.5.3 自动化实施的步骤

• 1、完成功能测试，版本基本稳定
• 2、根据项目特性、选择合适的项目自动化工具，并搭建环境
• 3、提取手工测试的测试用例转化为自动化测试的用例
• 4、通过工具，代码实现自动化的构造输入，自动检测输出结果是否符合预期
• 5、生成自动化的构造输入，自动的检测世界古是否符合预期
• 6、生成自动测试报告
• 7、持续改进、脚本优化

3.6 按测试对象划分

3.6.1 业务测试

测试人员把系统的所有模块组合起来，模拟用户实际运行过程，对满足用户需求的程序的所有功能进行测试。

3.6.2 界面测试

界面测试（简称UI测试），对页面布局，颜色搭配，整体色调，风格的测试。
测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。

3.6.3 容错性测试

主要包含两个方面：应对小错误的测试和应对灾难性错误的测试。

• 应对小错误的测试：出入异常数据或进行异常操作。比如输入内容的类型不对，格式不符，范围有误，网络卡顿状态下等等。
• 应对灾难性问题的测试：让软件直接崩溃，或者服务器直接停止运行。检查里边的数据是否还在，是否能在最短时间内恢复好。

3.6.4 文档测试

文档测试关注的点：文档的术语、格式、正确性、完整性、一致性、易用性等。

• 开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书等。
• 用户文件：用户手册、操作手册（用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本）
• 管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
  在实际的测试中，最常见的就是用户文件的测试，例如：用户操作说明书等。

3.6.5 兼容性测试

兼容性测试主要指软件之间能否很好的运作，软、硬件之间能否发挥好，会不会影响导致系统的崩溃。
在每次迭代、更新、修改bug之后都要进行。最常见的就是浏览器的兼容性测试，因为不同的浏览器在解析css和js时会导致页面的显示不同。

• 平台测试【例如：各种不同品牌型号、不同操作系统（如：android、iOS）的手机是否兼容】
• 浏览器测试【例如：不同浏览器兼容性测试（火狐、谷歌、360等）】
• 软件本身是否向前或向后兼容【例如：本版本和上一版本是否兼容】
• 测试软件是否与其他相关软件兼容【例如：同时下载两款软件是否都能正常使用】
• 数据兼容性测试【数据之间有一定的隔离性，两个软件里面的数据不会串、相互隔离、兼容】

3.6.6 易用性测试（用户体验测试）

易用性是交互的适应性、功能性和有效性的集中体现，看放不方便用户使用。

3.6.7 性能测试

检查系统是否满足需求规格说明书中规定的性能。通常表现在以下方面：

• 稳定性【例如：一万人的时候和十万人的时候，甚至一百万的时候系统会不会卡顿】
• 响应时间【例如：等待相应的时间是否过慢】
• 吞吐量（TPS）
• 执行间隔

3.6.8 安全测试

测试软件应对恶意攻击的操作。
【如：WEB的安全测试、需要熟悉各种网络协议、防火墙、CDN、熟悉各种操作系统的漏洞、熟悉路由器等。】

3.6.8 安装测试

测试程序的安装、卸载。

3.7 按测试地域划分

3.7.1 本地化测试

本地化测试的对象是软件的本地化版本。之前所有讲的都是基于本地化进行测试的。

3.7.2 国际化测试

软件的国际化和软件的本地化是开发面向全球不同地区用户使用的软件系统的两个过程。
本地化和国际化的软件测试的一些测试要点。

• 1、本地化后的软件在外观上与原来版本存在着一些差异，外观是否整齐、不定样。
• 2、是否对界面元素进行了本地化处理，包括对话框、菜单、工具栏、状态栏、提示信息（包括声音的提示、日志等）。
• 3、在不同分辨率界面下是否显示的是正常的。
• 4、是否存在不同的字体的大小，字体设置的是否恰当。
• 5、日期、数字格式、货币等是否能够适应不同的国家的文化习俗。例如年、月、日，而英文是月日年。
• 6、排序的方式是否考虑到了不同语言的特点。
• 7、在不同个的国家采用的是不同的度量单位，软件是否能够自适应和转换。
• 8、软件是否能够在不同类型的硬件上正常运行。正文翻译是否正确，恰当是否有语法的错误。
• 9、软件是否能够适应不同的操作系统的平台。
• 10、联机帮助和文档是否已经进行翻译，翻译后链接是否正常。正文翻译是否正确，恰当是否有语法的错误。

四、软件模型

4.1 开发模型

4.1.1 瀑布模型（Waterfall Model）

瀑布模型是所有其他模型的基础框架。瀑布模型每个阶段都只执行一次，是线性顺序进行的软件开发模式，适用于需求比较稳定的项目。
优点：计划周密，阶段性强，每个阶段较独立，看重前期的需求分析和后期的测试阶段。
缺点：测试在编码之后才进入，导致前期的问题后期才发现，失去及早纠正的机会。

4.1.2 螺旋模型（Spiral Model）

一般在软件开发初期阶段，需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一，适合规模庞大、复杂度高、风险大的项目。

• 优点： 强调各开发阶段的质量，分析项目是否有价值继续，严格的全过程风险管理。
• 缺点： 对风险管理的技能水平要求较高，人力物力、时间、成本较高。

4.1.3 增量和迭代模型

**增量：逐块增加，一部分一部分来。**先完成模块A，再模块B。
**迭代：反复求精的过程，先整体再细化。**先完成所有模块的基础功能（轮廓），再进行模块的升级和细化。

• 优点：抗风险能力增加。

4.1.4 敏捷模型

敏捷开发以用户需求为核心，采用迭代、循序渐进的方法进行软件开发。轻文档、轻流程、重目标，重产出。

• 优点：高适应性，以人为本。注重市场快速反应能力，即就是具体应对能力，客户前期满意度高。
• 缺点：注重与人员的沟通，但忽略文档的重要性，若项目人员流动太大，维护难度大；项目周期长，很难保证开发的人员不更换，没有文档就会造成在交接的过程中出现很大的困难。

4.2 测试模型

4.2.1 V模型

V模型是瀑布模型的变种，左右每个阶段之间一一对应，左边是右边测试阶段的依据。
V模型流程是从上至下，从左到右。测试和开发是串行的。
单元和集成测试检测程序的执行是否满足软件设计的要求；系统测试检测系统功能、性能的质量 特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。

• 优点：每一个阶段都清晰明了，便于控制开发的每一个过程。既包含单元测试又包含系统测试。
• 缺点：编码后才进行测试，未在需求阶段就进入测试，前期的错误后期才发现，失去修改的机会，模型灵活性低。

4.2.2 W模型

W模型由两个V字型模型组成，分别代表测试与开发过程，克服了V模型的缺点，测试与开发是并行的关系，开发的同时进行验证和确认，即：测试与开发是同步进行的。

• 优点：测试介入较早，有利于尽早地全面的发现问题。测试伴随整个开发周期，测试与开发并行。测试的对象不仅仅是程序，还有需求和设计。【例如，在需求分析结束后就可以进行需求分析测试。】
• 缺点：需求、设计、编码等都是串行的，测试和开发活动保持着一种线性的前后关系，上一阶段结束，才可开始下阶段工作。不支持敏捷开发模式，对于需求和设计的测试技术要求高，实现起来困难。【有些项目开发过程中根本没有文档产生，故W模型无法使用。】

4.2.3 H模型

相对于V模型和W模型，H模型将测试活动完全独立出来，使测试流程形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

• 优点：软件测试完全独立，贯穿产品整个生命周期，并与其他流程并发进行，不同的测试活动可以按次序先后进行，也可反复进行，只要测试准备完成，就可以执行测试。
• 缺点：
  • 管理性要求高：由于模型很灵活，必须定义清晰的规则和管理制度，否则测试过程将难以管理和控制。
  • 技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小。
  • 测试就绪点分析困难：很多时候并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大的困难。

五、测试用例

5.1 测试用例的定义、好处及作用、特性

• 定义：测试用例是为了实施测试而向被测试的系统提供的一组案例集合，包含：测试环境、前置条件、测试步骤、测试数据、预期结果等要素。
  • 将要进行的测试工作，具体化，并且记录到一个文件中，一般是一个excel
  • 在测试用例中，明确的指定了每一步做什么操作，期望得到什么结果
• 好处及作用：
  • 在实施测试前设计好测试用例，可以避免盲目测试并提高测试效率，测试重点突出，目标明确，防止漏测。
  • 检验软件是否满足客户需求，展现测试用例的设计思路。
  • 在软件版本更新后只需修正部分测试用例，便可开展测试工作，降低工作强度，缩短周期。
• 特性：
  • 有效性：测试用例能够被使用，且被不同人员使用测试结果是一致的
  • 可复用性：良好的测试用例具有重复使用的功能，如：回归测试
  • 易组织性：好的测试用例会分门别类地提供给测试人员参考和使用
  • 可评估性：从测试管理的角度，测试用例的通过率和软件缺陷的数目是软件产品质量好坏的测试标准
  • 可管理性：从测试管理的角度，测试用例的通过率和软件缺陷的数目是软件产品质量好坏的测试标准

5.2 测试用例的模板

测试用例组成元素(具体元素视公司规定)
【以QQ的登录模块为例】

• 用例编号：唯一性标识一条用例。格式：项目+模块+编号（项目和模块用英文）【eg:QQ_login_001】
• 用例标题：写清楚用例的测试目的。格式：预期结果+测试步骤(测试点)【eg:登录成功(正确的账号+正确的密码)】
• 项目/模块：用例测试的项目/模块【eg:登录】
• 优先级：标识用例的重要程度。格式：P0-P4。（只有冒烟测试用例可以标记为P0）【eg:P0】
  • P0：冒烟测试用例，保证保证系统基本功能，核心业务，重要特性，实际使用频率比较高的用例。
  • P1：次要功能，小功能(成功)。
  • P2：UI、边界、错误的设置(错误)。
  • P3：错误信息、较复杂的场景、不常用的场景。
• 前置条件 ：在执行测试用例之前需要做好的准备工作。有就写，没有可以不写 【eg: 1. app 应用正常 2. 网络正常】
• 测试步骤 ：在测试过程中具体的操作步骤。格式：分步骤写1、2、3、4，写明具体的操作【eg: 1. 输入qq号 2. 输入密码 3. 点击登录】
• 测试数据 ：操作过程中，如果涉及到输入，则会有数据。 有就写，没有可以不写。【eg: 1. qq号：1441559210 2. 密码：cecn1234】
• 预期结果：按照需求，执行对应的步骤后，希望看到的结果。【eg:登录成功，跳转到个人主页】
• 其他要素：用例的设计者，用例设计日期，对应的开发人员，测试结果（pass，fail，block），测试类型（功能，性能，压力等）

测试用例需要被开发、审阅、使用、维护和保存。

5.3 测试用例的设计原则及方法

设计原则

• 明确性：尽量避免测试用例存在含糊的因素，在测试过程中，测试用例的测试结果是唯一的。
• 代表性：尽量将具有相似功能的测试用例抽象合并，功能相似的用例要合并。
• 简洁性：测试用例简洁，可读性良好，测试过程目的明确，测试结果唯一。测试用例要陈述语句，一句话直指问题的核心，不要用浮夸的修饰手法。

设计方法

5.3.1 等价类划分法

通俗来讲，将具有某种共同特征的数据集合进行划分。
等价类划分原则

• 如果某个输入条件规定了取值范围或值的个数。则可确定一个合理的等价类（输入值在此范围内）和两个不合理的等价类（输入值或个数小于这个范围的最小值或大于这个范围的最大值）
• 如果规定了输入数据的一组值，而且程序对不同输入值做不同的处理，则每个允许输入值是一个合理的等价类，此外还有一个不合理的等价类（任何一个不允许输入的值）。
• 如果输入是布尔表达式，可以分为一个有效的等价类和一个无效的等价类。
• 如果已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分为更小的等价类。
• 等价类划分还应特别注意默认值、空值、Null、0等的情形。

【案例：找6-10位长度自然数】

• 有效等价类：比较好找，123456 1234567
• 无效等价类：相对复杂，可以从以下几点来思考
  • 数据内容不符合 数据是否为空
  • 数据长度不符合：过长、过短
  • 数据是否重复
    

5.3.2 边界值分析法

针对输入和输出的边界进行测试用例的设计。

边界值选择的原则

• 如果输入条件规定了值的范围，可选择正好等于边界值的数据作为合理的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。【eg：输入值的取值范围是[0,99],可取-1,0，99,100等值作为测试数据。】
• 如果输入的条件指定了输入数据的个数，则按最大个数、最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。【如，一个输入文件可包括1~255个记录。则分别设计有1个记录，255个记录，以及0个记录、266个记录的输入文件来作为测试用例。】
• 如果程序的规格说明给出的输入域或输出域是有序集合（如有序列表、顺序文件等），则应选取集合的第一个元素和最后一个元素作为测试数据。【如，输出的表最多有99行，每50行为一页，则输出0行、1行、50行、51行、99行。】

【案例】
需求：通过边界值法验证标题长度的合法性
要求：标题大于0，小于等于30个字符

5.3.3 因果图法

当输入很多，并且不同的输入组合对应这不同的输出，这个时候用因果图法来分析不同输入组合和输出之间的对应关系。（相当于逻辑图）
逻辑关系：恒等 与 或 非

• 因果图法设计步骤：
  • 1、分析出所有的输入和输出；
  • 2、找出输出和输出之间的关系；
  • 3、画因果图；
  • 4、画判定图；
  • 5、把判定表转换成测试用例；

【案例：淘宝618活动，订单满300，或者有红包，测提交订单后享受优惠。】

• 1、输入和输出
  • 输入：金额<300，金额>300, 金额==300，有红包，无红包，提交订单
  • 输出：享受优惠，不享受优惠
• 2、输入和输出之间的关系
  • 订单已提交，金额大于等于300 ，无红包，享受优惠；
  • 订单已提交，金额大于等于300 ，有红包，享受优惠；
  • 订单已提交，金额小于300，有红包，享受优惠；
  • 订单已提交，金额小于300，无红包，无优惠；
  • 订单没有提交，无优惠；
• 3、画因果图
  
• 4、根据因果图画判定表
  

5.3.4 判定表法

5.3.5 正交表法

研究多因素多水平的一种方法，根据正交性选出最优的水平组合进行实验，用实验的结果来分析这个测试用例的结果。（选择最优的组合）

• 因素：输入的变量；
• 水平：因素的取值；
• 因素数：变量的个数；
• 水平数：变量取值的最大个数；
  
• 正交表设计测试用例的步骤：
  • 1、找出所有的输入变量（因素），确定因素数；
  • 2、确定变量的取值，确定水平数；
  • 3、确定正交表的行和列；
  • 4、根据正交表的性质去填写正交表
  • 5、把正交表的每一行对应写成一个测试用例；
  • 6、补充你认为重要的但没有体现在正交表中的测试用例；
    【例子：姓名，邮箱，密码，确认密码，验证码（输入和不输入）——不用正交表要列出2^5=32情况】
• 因素：5
• 水平数：2（输入和不输入）
• 行：（水平数-1）*因素数+1=6 ；列：因素数：5
  填写正交表
  

5.3.6 错误推断法

根据测试人员的直觉，知识，经验，判断软件的哪一块有问题，专门针对性的设计测试用例，适合作为一种补充设计测试用例的方法。

• 1、验证码大小写不区分
• ​2、空格搜索，把输入的搜索信息前后空格忽略

5.3.7 场景法

典型的应用是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。
【ATM机取款场景】
功能点：插卡——输入密码——输入钱数——取款（主要功能，核心流程）

• 插卡：插反，插错卡（饭卡，会员卡，不是本行卡），注销，消磁，冻结，有不良记录的卡
• 输入密码：密码错误，密码输入正确，密码三次错误，第一次密码错第二次密码对，前两次密码错第三次密码对
• 输入钱数：钱数<=银行卡余额，输入钱数>=银行卡余额，输入的不是整百，ATM机余额不足，超过每日取款限额，超过每次取款最大上限，超过每次取款最大次数。
• 取款：确认取款钱数后，ATM机吐出对应钱数；ATM机吐钞规则，操作超时，长时间不吐钱。
• 其他：ATM机断网，断电，出现故障；超时，所有的操作如果超时，那么会出现吞卡（安全机制）。
  • 1、插卡插反：第二次重新插入正确插入，仍可以正常取钱；卡冻结/注销，无法正常取钱
  • 2、输入三次密码错误，账户冻结，无法取款；前两次密码错第三次密码对，仍可以正常取钱
    

5.3.8 总结

• 等价类：测试的内容有输入功能，而且输入的内容之间没有关系
• 边界值：输入的内容有边界，有类型、大小、长度的要求
• 判定表/因果图：有多种输入的内容，而且有多种输出结果
• 正交法：测试的数据和条件特别多
• 场景法：整合测试多个功能，需要使用场景法
• 错误推断法：时间、资源不充足；仅仅需要做初测