软件测试基础理论学习-软件测试概论（流程，bug，测试用例）

测试的流程

也可以理解为测试工程师在软件开发中需要介入的部分，个人总结如下：

1. 需求分析。这个部分主要就是针对需求提出一些不合理的地方，也可以让测试人员对整个软件模型和需求进行整体的掌握和把控，如果出现了不合理的地方，需要讨论解决之后才进入下一步，需要对岗位和软件产品负责。

2. 测试计划。根据需求文档做对功能进行划分，通过合理的划分人力、物力进行测试安排。

3. 测试方案。主要确定测试的方法、测试的环境、测试的对象，是性能测试呢？还是功能测试？

4. 测试用例。这个步骤通常可以在开发进行的时候同步进行编写（理想状态）。

5. 用例评审。在这一步里面，通常需要产品、UI、前后端等多个部门的人参与进来，有必要的话也需要邀请甲方一起，完善测试用例。

6. 接口测试。这个步骤一般是在前后端完成之后，我们在测试结果的时候，开发进行前后端联调。

7. 功能测试。在前后端联调完之后，进行功能测试。

8. bug管理。使用bug管理工具进行bug的管理。

9. 回归测试。需要验证bug是否已经正确解决了，需要注意的是，解决bug的过程中是否产生了新的bug。

10. 线上验证。在产品上线后，我们可以使用自动化脚本进行一个监控，一般是只查不改，主要为了实现自动化监控预警。

综上所述，测试工程师应该参与到软件开发的各个流程中，才能最大限度的对软件的质量进行把控，但是在实际的生产开发工作中，测试工程师大多是中途加入项目中，这就需要测试人员有较强的学习理解能力，能尽快的掌握需要测试的核心功能。

bug的定义

Bug，从软件工程的角度来看，是一种程序错误或缺陷，它是软件在实现预期功能、满足需求或规范时出现的偏差。

这个定义不仅仅局限于代码层面的逻辑错误，还涵盖了设计缺陷、文档不准确、用户界面不符合期望、性能瓶颈以及任何与软件产品相关的可改进点。

往深了讲，Bug的本质是人类意图（即需求）与计算机执行之间的鸿沟。在更高维度上，bug反映了开发过程中的知识转换失真，这种失真可能源于开发者对需求理解的差异、编程语言表达能力的局限、系统环境的复杂性或者团队协作中沟通的有效性不足等多元因素。

bug的生命周期

1. 发现bug

2. 确认bug

3. 提交bug

4. 指派bug

5. 开发确认bug（如果开发确认这是重复bug、不是缺陷、无法复现的bug，经我们确认后同意开发观点，则关闭bug）

6. 开发解决bug

7. 验证bug并回归测试

8. 是否通过验证（如果通过则关闭bug，如果没通过则重新激活这个bug）

9. 关闭bug

bug的组成

1. bug的表现形式，就是用户或者测试人员发现这个bug的异常行为的具体表现，例如：程序崩溃、数据计算错误、网页错误、页面显示不正确等。

2. bug的标题、编号、创建时间等，能够帮助开发人员或者测试人员更好的找到bug单。

3. bug触发的概率、是否可以复现以及复现的步骤是怎么样的

4. bug的实际结果、预期结果，可以使用截图或者一些关键信息来指明这个地方和预期不符

5. bug的影响范围、严重性级别（致命、严重、一般等）

6. bug的产生环境，例如操作系统的版本，浏览器类型，数据库类型和配置等，也可以理解为重现步骤中的一个环节

7. 发现bug的时候产生的一些日志信息，也是所需要的，例如：相关代码段，时间信息，报错代码等

测试用例的组成部分

下文是一份比较详尽的测试用例的清单：

1. 用例编号

2. 用例标题

3. 所属模块

4. 优先级

5. 测试数据（输入数据）

6. 前置条件（测试环境）

7. 测试步骤

8. 预期输出

9. 实际输出

10. 提出人员

11. 提出时间

12. 执行人员

13. 执行时间

测试用例的设计原则

1. 要遵从“8/2法则”，需要保证用较少的测试用例去覆盖较多的范围，不能通过数量多来进行覆盖，会导致有很多冗余、无用的测试用例

2. 需要尽可能覆盖到所有可能的功能路径和业务场景，包括正常，异常，边界等，可以参考上一篇文章中的测试方法论

3. 需要有比较明确的测试点，测试的什么功能

4. 测试用例需要有可重复性，在共性的系统中，需要让测试用例能够做到复用

5. 测试用例需要做到模块化和分层设计，也就是说每个模块的测试用例应该独立于其他的模块，也需要考虑不同层次的测试，例如单元测试，集成测试，性能测试等

6. 测试用例的相关文档应该比较详尽，做到有迹可查和便于其他成员理解和复用