软件测试~基础篇

Okay，从这里起，开始测试~

1、软件测试的生命周期

需求分析–>测试计划–>测试设计、测试开发–>测试执行–>测试评估

2、测试与周期对应

• 需求阶段：

  了解需求、分解需求、得出测试需求；

• 计划阶段：

  编写测试计划或测试方案；

• 设计阶段：

  了解设计，搭建测试用例框架；

• 编码阶段：

  白盒测试人员计划执行单元测试，完善、细化测试用例以及调整方案；

• 测试阶段：

  执行测试，在过程中记录、管理缺陷，完成后编写测试报告；

• 运行维护：

  参与项目实施，必要时参与用户实用软件培训。

3、描述一个bug

问题的版本 + 问题出现的环境 + 错误重现最短步骤 + 预期行为 + 错误行为 + 其他

注意：不要把多个bug放到一起！！

4、定义bug的级别

每个公司定义bug的级别都不一致，在使用前一定先查看~

以下为示例：

① Blocker （崩溃）

• 一旦出现应立即中止当前版本测试 *

② Critical （严重）

• 该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试*

③ Major （一般）

• 该问题实际测试中存在最多*

④ Minor （次要）

• 此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理*

5、bug的生命周期

每个公司、每个工具对于bug的生命周期定义也是不同的~

下图是常见例：

上述状态：

• New：新发现的Bug，未经评审决定是否指派给开发人员进行修改。

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

• Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。

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

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

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

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

无效的bug：

• open->closed

• open->rejected->closed

Bug的跟踪及状态变更必须遵循的原则：

① 测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试，确保相同的问题不会再次出现，才能关闭缺陷。

② 对于拒绝修改和延迟修改的Bug，需要经过包含测试人员代表和开发人员代表、用户方面的代表（或代表用户角度的人）的评审。

6、如何开始第一次测试

1. 阅读所有相关文档，包括：需求文档、设计文档、用户手册。
2. 尽可能参加各种项目会议，了解项目的背景、人员组成、尽可能的了解需求和业务。
3. 熟悉项目所使用的测试管理工具、配置管理工具，获取对应的地址和登录方式。
4. 阅读已有的测试方案和测试案例。
5. 阅读旧有的bug库，了解系统功能，尤其重要和现有的测试团队保持一致的故障定级原则。
6. 了解公司的规范要求，特别是用例编写规范、用例执行规范、bug提交规范、测试工具工具使用规范等
7. 明确工作内容，比如：测试的计划是什么？测试的内容是什么？

7、测试执行

1. 打开待测试系统
2. 打开测试管理工具用例模块，执行用例
3. 发现bug，进行复现并确认bug复现步骤
4. 记录bug
5. 沟通bug
6. 验证以前提交的bug
7. 确认本次测试