软件测试基本概念知识

1、如何清楚的描述一个Bug:

1⃣️版本号（代码版本号）2⃣️测试环境（Win/Mac；浏览器；手机型号等）3⃣️测试步骤（测试数据）4⃣️实际测试结果5⃣️预期结果6⃣️附件（错误日志、截图）

2、需求：测试人员展开测试的工作依据（下图是具体流程以用户登录注册功能为例）

3、软件生命周期：

需求分析->计划->设计->编码->测试->运行维护

• 需求阶段 –测试人员了解需求、对需求进行分解，得出测试需求
• 计划阶段 根据需求编写测试计划/测试方案
• 设计阶段 –测试人员适当的了解设计，对于设计测试用例是很有帮助的，测试人员搭建测试用例框架，根据 需求和设计编写一部分测试用例
• 编码阶段 –测试人员一般是不需要编码的，但已经编码的模块，专业的白盒测试人员可以计划执行单元测 试，完善、细化测试用例以及调整测试计划和方案。
• 测试阶段 –测试阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试，在执行的过程中 记录、管理缺陷，测试完成后编写测试报告。
• 运行维护 –测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员 的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集 问题并及时反馈给相关负责人。

4. 测试用例设计方法

1. 等价类：

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

2. 边界值：
   注：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
3. 错误猜测法：
   注：顾名思义，这个东西比较依靠个人经验
4. 场景设计法：
   注：模拟正常场景，设计测试
5. 因果图：
   注：因果图设计步骤：

(1)分析所有可能的输入和可能的输出。
(2)找出输入与输出之间的对应关系。 
(3)画出因果图。 
(4)把因果图转换成判定表。 
(5)把判定表对应到每一个测试用例。
1
2
3
4
5

6.正交法：
注：根据正交性，从大量实验数据中，选最优的数据组合，根据最优的数据组合的结果衡量整个测试的输出结果

5. 为什么要设计测试用例

（1）测试用例是测试执行的依据
（2）测试用例有复用性
（3）测试用例可以衡量需求覆盖率
（4）自动化测试用例编写依据
（5）借鉴意义

6. 基于需求（测试用例设计依据：需求）如何设计测试用例

1. 分析需求，验证需求合理性与正确性，查看是否逻辑自洽无二义；
2. 细化需求提取测试项，根据测试项设计用例；

`功能性考虑`
1.从界面功能开始分析设计，确保无遗漏
2.根据业务、使用场景，把功能串联起来测试（ 场景法）
3.对一个功能不同的输入进行测试
4.功能之间的一致性与交互性
5.数据异常等异常操作的考虑
6.验证软件中的算法（白盒测试）
1
2
3
4
5
6
7

`非功能性考虑`
易用性、可靠性、容错性、兼容性、安全性、可移植性、性能
1
2

因果图稍微复杂所以我们举一个例子

假设业务单据的处理规则为：“淘宝618活动，订单已提交，订单合计金额大于300元或有红包，则进优惠”。

1. 分析可能的输入输出
   解：输入：订单已提交、金额大于300、有红包；输出：优惠、不优惠
2. 找出输入与输出之间的对应的逻辑关系。
   解：
   (1)订单已提交，订单金额大于300元，有/无红包：优惠；
   (2)订单已提交，订单金额小于等于300元，无红包：不优惠；
   (3)订单已提交，订单金额小于等于300元，有红包：优惠；
   (4)订单未提交：不优惠。
3. 画因果图：
   
4. 根据因果图画判定表：
   
5. 根据判定表写测试用例

• 订单已提交 ， 金额>300 ， 有红包 ：有优惠
• 订单已提交 ， 金额>300 ， 无红包 ：有优惠
• 订单已提交 ， 金额<300 ， 有红包 ：有优惠
• 订单已提交 ， 金额<300 ， 无红包 ：无优惠
• 订单未提交 ， 金额>300 ， 有红包 ：无优惠
• 订单未提交 ， 金额>300 ， 无红包 ：无优惠
• 订单未提交 ， 金额<300 ， 有红包 ：无优惠
• 订单未提交 ， 金额<300 ， 无红包 ：无优惠

7. 测试分类如下图所示：
   

---

8.下面举一个关于测试用例的例子（按测试对象划分）：

9.按是否查看代码划分

黑盒测试：（不关心代码内部实现，不关心代码逻辑结构，只关心输入输出是否符合预期）
测试方法
等价类、边界值、因果图、错误猜测法、场景法、正交法

白盒测试：（针对代码、分析测试代码的逻辑、结构，实现的功能，观察是否符合用户需求）
测试方法
语句覆盖、路径覆盖、判定覆盖、条件覆盖、判定组合覆盖、条件组合覆盖、判定条件组合覆盖
【Java：Junit单元测试框架】

灰盒测试
介于黑盒测试与白盒测试之间

10. 按照开发阶段
    (测试金字塔，越往下，测试效率越高，定位问题越容易)
    

1. 单元测试：

• 测试阶段：编码后或者编码前（TDD）
• 测试对象：最小模块
• 测试人员：白盒测试工程师或开发工程师
• 测试依据：代码和注释+详细设计文档
• 测试方法：白盒测试
• 测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
  TDD:（测试驱动开发）
  测试人员先写测试代码进行空跑、开发人员根据异常写代码、直到测试用例通过

2. 集成测试：（按照一定策略把单元模块组合起来形成一个大的功能模块，对这个功能模块进行测试）

• 测试阶段：一般单元测试之后进行
• 测试对象：模块间的接口
• 测试人员：白盒测试工程师或开发工程师
• 测试依据：单元测试的模块+概要设计文档（V模型）
  v模型如下图所示：
• 测试方法：黑盒测试与白盒测试相结合(灰盒测试)
• 测试内容：单元模块之间接口的正确性，模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单原模块 缺陷对系统的影响

3. 系统测试：

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

（回归测试与冒烟测试都属于系统测试）
回归测试：当系统引入新的代码，查看新代码是否影响旧的功能（迭代、修改bug）
冒烟测试：（自动化测试）正式测试之前，对软件系统基本流程和核心功能进行测试，同意后才可以进行正式测试//准入原则
1
2
3

4. 验收测试

• 测试阶段：系统测试通过之后
• 测试对象：整个系统（包括软硬件）
• 测试人员：主要是最终用户或者需求方
• 测试依据：用户需求、验收标准
• 测试方法：黑盒测试
• 测试内容：同系统测试(功能…各类文档等)

11. 按照实施组织区划分

1. α测试(Alpha Testing)
   用户或除了开发人员及测试人员以外的公司内部人员到开发现场测试
2. β测试(Beta Testing)
   实际用户使用环境下测试，不限时间地点（游戏内测）
3. 第三方测试
   第三方软件测评机构进行测试

12. 是否运行代码划分：

1. 静态测试：
   不运行代码、分析代码风格、是否符合公司标准规范、分析代码结构、逻辑、算法、方法的实现是否满足用户需求
2. 动态测试：
   运行一下

13. 按是否手工划分：

1. 手工测试
   手工执行测试用例，查看测试结果
   缺点：量大容易出错、效率低
   优点：认为可控、有利于探索性测试
2. 自动化测试
   机器按照设定好的条件执行测试，包括正常和异常方面
   自动化测试脚本：UI自动化；接口自动化；性能自动化

14. 按照地域划分

软件国际化：开发软件时使用一种工程技术，使得软件在适用不同国家语言、风格使用习惯的时候不用去改变软件的源码就可以做到

• 国际化测试 ； 本地化测试