软件测试学习（一） 测试理论

一、软件测试

• 定义：通过手工或者自动化的方式运行被测试的软件检查是否正常（评判标准：预期结果与实际结果是否一致）
• 测试目的：确保软件具有高质量（尽可能的全面的发现问题，证明软件存在问题，从而让开发解决问题）
• 测试的外在体现：找出软件bug验证软件质量

二、软件质量

名词解释：

• 需求：用户的想法，为了实现某个目的或解决某个问题而产生的想法
• 需求规格说明书：将用户的想法转化为技术上可以实现的文档

（一）软件质量模型

应用场景：提供对于软件产品从测试角度思考的一种思路

软件质量定义：产品的实际实现结果和需求描述是否一致，相一致程度高说明软件质量高

软件质量的评判：

• 功能：软件产品是否具备某种能力
• 性能：软件产品对于时间和空间的占用程度高低
• 兼容性：软件兼容其他软硬件的能力
• 易用性：在一定的用户群的基础上，软件是否好用、容易理解
• 可靠性：软件是否具备持续无故障运行的能力
• 安全性：软件运行过程中对于数据的传输和存储是否安全
• 可移植性：软件产品从一个环境一直到另一个环境中正常运行的能力
• 可维护性：软件出现故障后，自我修复/恢复的能力

（二）软件的生命周期

定义：软件从无到有到消亡的过程，也叫软件开发过程模型、软件生命周期模型

1、瀑布模型

用至软件生成到小王的过程，该模型目前实际工作中已不常用，但是该模型是其他模型的开发基础

瀑布模型的优点

• 每个阶段比较清楚，并且有对应的文档产生
• 当前一个阶段完成后开始后面的阶段（一次性的）

瀑布模型的缺点

• 发现问题的时机比较晚，失去提前纠错的机会
• 测试介入比较晚

适用场景

• 适用于需求不易发生变化的大项目

敏捷开发模型：能够适用需求的变化，并且能够给出快速的响应

2、V模型

作用：主要描述测试、开发之间的对应关系

 V模型优点

• 每个阶段比较清楚，测试过程由底层（代码）测试到高层（应用）测试过程

V模型缺点

• 不适用于需求的变更，发现问题的实际比较晚

3、W模型

作用：将测试过程更加细化说明，对应测试、开发之间的关系更加清楚

 W模型优点

• 测试介入时间早，能够及时发现问题，降低修复成本
• 测试伴随整个软件生产周期，除了测试软件之外，还需要验证文档

W模型缺点

• 该模型应用起来复杂度高（具备计算机技能、业务能力、管理能力、测试素质）

三、测试用例设计方法

（一）等价类划分法

• 等价类定义：根据需求将被测对象的所有可能的输入划分为若干集合，集合中每一个元素（除上点、离点），对于发现错误的效果是等价的。即在批量的测试数据中，选取具有共同特征的数据子集作为测试的输入
• 等价类的分类
  • 有效等价类：满足需求的测试数据
  • 无效等价类：不满足需求的测试数据

等价类划分法设计用例步骤

案例：请测试两个两位数整数之间的和（即-99到99之间数据求和）是否存在漏洞

• 明确需求
  • 测试目的
    • 验证两位数整数是否正常求和
  • 测试条件
    • 长度 / 类型（来源于键盘输入）/ 规则
• 划分等价类
  • 有效等价类：满足需求的所有条件
  • 无效等价类：不满足（只要不满足其中一个条件即可）需求的所有输入数据

等价类适用场景

• 针对于有批量数据输入的测试场景，无法穷举测试时适用
• 常见代表：输入框（下拉框、选择框、下拉列表等）

编写用例注意事项：

• 单模块测试中，用例标题具有唯一性
• 必要步骤尽可能清楚
• 预期结果尽量描述测试结论行的语句及现象（如果有具体现象最好描述）
• 用例编号和测试项目简称对应设置

（二）边界值分析法

边界范围的确定

根据需求，将数据类型和边界确定，直接可以获取对应的边界范围值

• 上点：刚好等于边界的值（取值不考虑开闭区间）
• 离点：刚好小于/大于边界上的值（取值类型看需求）
• 内点：边界范围内的任何取值（取中间的值）

边界值分析法设计用例步骤

• 明确需求
  • 测试目的
  • 测试条件
    • 长度
    • 类型
    • 规则
• 划分等价类
  • 有效等价类
  • 无效等价类
• 确认边界范围值：确定边界范围值之后，结合等价类进行合并补充
  • 上点
  • 离点（可以优化）
  • 内点（可以和有效等价类的取值合并）
• 提取数据编写用例
  • 按照用例模板编写内容即可

离点优化

目的：减少用例数量，由7条数据变5条数据

注意事项：非必须，可以不用优化

离点优化：离点的选取和上点取值相反的取值点即可

结论：7个优化为5个点

上点：必选（不考虑区间开闭）

内点：必选（建议选择中间范围）

离点：开内闭外（考虑开闭区间，开区间选择内部离点，闭区间选择外部离点）

边界值适用场景

在等价类划分法的适用场景上完善和补充

• 针对有边界范围的批量数据的输入类测试（重点关注边界）
• 典型代表：输入框（有边界范围区间）

（三）判定表法

判定表引入

• 判定表：是一种以表格形式表达多条件逻辑判断的工具

判定表构成

条件	是否欠费	是	是	否	否
	是否关机	是	否	是	否
操作	是否允许主被叫	否	否	否	是

• 条件桩：列出问题中的所有条件。列出条件的次序无关紧要。         蓝色区域的信息
• 动作桩：列出问题中可能采取的操作。可能存在多个，操作的排列顺序没有约束 。              紫红色区域的信息
• 条件项：列出条件对应的取值。所有可能情况下的真假值，所有条件对应取值的全组合。          绿色区域的信息
• 动作项：列出条件项的各种取值情况下应该采取的动作结果。（通过条件项得到的结果）          黄色区域的信息

根据表计算测试用例

如果条件的取值只有两个，那么每种条件的组合数量为2的n次方

规则：每种条件项和动作项对应的一列就是一条规则，也叫一条测试用例

判定表设计用例步骤

• 明确需求
  • 测试目的
  • 测试条件：根据需求进行罗列
• 画出判定表
  • 列出条件桩和动作桩（根据需求来分析提取）
  • 在条件桩前面加判定词，根据条件数量进行组合得到所有取值（条件项）
  • 根据每种条件的组合得到动作项
  • 优化合并相同的条件
• 按照规则编写用例
  • 按照测试用例模板编写即可

判定表的适用场景

• 针对需求中有多个条件，并且条件和条件之间有组合关系，条件和结果之间有制约（因果）关系的场景
• 常见词汇：如果.....那么......；若....则.......
• 局限性：条件个数不易过多（不超过4个）

注意：超过4个条件的不常见，如果超过4个以上条件的，可以是使用因果图（网络查询）

（四）场景法

也叫流程图法，通过流程图法的描述用户的使用场景过程，验证整个产品的业务（用户使用过程）是否正常

• 用户：用户使用更加关注整个系统的应用
• 测试：测试不仅仅要关注单功能测试，还需要关注系统之间组合测试

适用场景

• 一般在测试的后期，对于整个系统的模块进行全部的组合测试
• 测试的依据：业务流程图

案例：ATM取款

场景介绍：

 银行取款流程图

 （五）错误推测法

错误推测法介绍

• 要求：有实际项目测试经验的人使用
• 定义：通过直觉（经验）或者智慧推测系统可能出现问题的地方进行再次测试

错误推测法适用场景

• 时间不足：通过以往类似项目的经验，提取当前项目中核心模块（出现问题较多）进行验证测试
• 时间宽裕：在基础测试的基础上，将原有模块（存在问题较多）进行再次细化测试

四、软件缺陷

1、缺陷的定义

判断依据的材料（1）用户需求说明书  （2）测试用例

定义：软件在使用（运行）过程中存在的任何问题（如：错误、异常、失效等），都叫软件的缺陷（即bug）

2、缺陷的判定标准

（1）软件未实现需求（规格）说明书中明确要求的功能（即没有做）

比如：手机是否支持5G功能

（2）软件出现了需求（规格）说明书中知名不应该出现的错误（即做错了）

比如：用户注册失败应当有错误提示，但实际没有提示

（3）软件实现的功能超出需求（规格）说明书指明的范围（即做多了）

比如：实现计算的软件出现聊天互动的功能

（4）软件未实现需求（规格）说明书中虽未明确指明但应该实现的要求（即没做完）

比如：软件的产品对于手机号码默认不能超过11位，但是软件未设置相关限制（需求中未详细说明）

（5）软件理解性差、使用复杂、运行缓慢、用户体验不好（即虽完成，但效果不好）

比如：软件使用卡顿严重，响应速度慢、界面不美观

缺陷的级别判定：

• 若违反上述（1）（2）（3）条件，则划分为高严重级别的bug
• 若违反上述（4）（5）条件，则划分为中低级别的bug

3、缺陷产生原因阶段

注意：为什么需要分析缺陷的原因？

• 帮助测试人员及领导定位产品出现质量问题的具体阶段，方便于后续软件产品质量的优化
• 能够帮助测试人员积累经验

（1）需求阶段：需求描述不易理解，有歧义、错误等

（2）设计阶段：设计文档存在错误或者缺陷

（3）编码阶段：代码出现错误（语法、单词、标点符号等）

（4）运行系统：软硬件系统本身故障导致软件缺陷

（5）故障解决阶段：对于系统不熟悉修复问题时引入新bug

 4、缺陷报告的核心内容

（1）缺陷的标题（描述缺陷的核心问题）

• 错误问题的结论+【现象】

比如：后台会员管理输入正确的手机号添加会员失败，提示：手机号码有误

（2）缺陷的预置条件（缺陷产生的前提）

• 与测试用例的预置条件一致

（3）缺陷的复现步骤（复现缺陷的过程）

• 与测试用例的测试步骤保持基本一致（含测试数据）

（4）缺陷的预期结果（希望得到的结果）

• 与测试用例的预期结果保持一致

比如：输入正确的手机号添加会员可以成功

（5）缺陷的实际结果（实际得到的结果）

• 实际的错误问题描述（结论+错误现象）

比如：输入正确的手机号添加会员提示手机号码有误

（6）缺陷的必要附件（图片、日志等信息）

5、缺陷报告的其他要素

（1）缺陷的编号：能够唯一的表示一个缺陷

（2）缺陷的状态：买哦书缺陷生命周期的过程

• 新建（new)：表示缺陷的产生
• 打开（open）：表示开发确认通过
• 拒绝（rejected）：表示开发确认不通过
• 进行中（inprogress）：表示开发正在修复缺陷
• 已修复（fixed）：表示开发已经修复完成
• 延迟修复（delay/postpone）：表示开发延迟修复
• 测试通过（reopen/open)：表示测试通过，已关闭
• 测试不通过（reopen/open）：表示测试不通过，重新打开

（3）缺陷的所属模块：类似于用例的所属项目，描述缺陷产生的模块范围

（4）缺陷的优先级：告诉开发当前缺陷修改的先后次序（P1）priority

• urgent priority：最高优先级
• veryhigh priority：次高优先级
• high priority：高优先级
• medium priority：中优先级
• low priority：低优先级

（5）缺陷的严重级：告诉产品当前缺陷对于整个产品的破坏程度（和优先级一一对应）（S1）serious

• critical：致命的破坏
• major：高的破坏性
• medium：中等破坏
• minor：低等破坏
• tiny：微小的破坏

（6）缺陷的类型：描述缺陷主要产生问题的原因

• 功能问题
• UI问题
• 兼容性问题
• 易用性问题
• 架构问题
• 安全问题

五、缺陷管理

1、缺陷的跟踪流程

作用：描述开发和测试在公司中对于缺陷的跟踪管理过程

2、编写缺陷报告规范

• 可复现：确保当前发现的bug能够复现
• 唯一性：确保一个缺陷报告中上报一个问题
• 规范性：遵循公司规定的报bug的要求

注意事项

• 确保上报的bug是准确的
• 描述尽可能简洁易懂具体
• 不能使用感情色彩的词语
• 不能使用模棱两可的词汇
• 不能使用人称代词