软件测试基础

[如何描述一个 bug](#如何描述一个 bug)

[bug 的级别](#bug 的级别)

[bug 的生命周期](#bug 的生命周期)

[测试的执行和 bug 的管理](#测试的执行和 bug 的管理)

[如何发现更多的 bug](#如何发现更多的 bug)

本节内容：

软件的生命周期：需求分析 -> 计划 -> 设计 -> 编码 -> 测试 -> 运行维护

软件测试的生命周期：需求分析 -> 测试计划 -> 测试设计、测试开发 -> 测试执行 -> 测试评估

需求分析：需求是否完整、是否正确测试计划：确定软件由谁测试，什么时候结束测试，测试哪些模块测试设计：编写测试用例（手工测试、自动化测试用例），编写测试工具执行测试用例：执行测试用例测试评估：测试人员产生一个测试报告

测试报告：测试人员测试时间：开始时间~结束时间开发人员开发时间测试用例 bug 文档：需求文档、测试文档

发现问题的版本开发人员需要知道出现问题的版本，才能获取到对应版本的代码来重现故障，并且版本的表示有利于统计和分析每个版本的质量。
问题出现的环境环境分为硬件环境和软件环境，如果是 web 项目，需要描述浏览器版本，客户机操作系统，如果是 app 项目，需要描述机型，分辨率，操作系统版本等。详细的环境有利于故障的定位。
错误重现的步骤描述问题重现的最短步骤
预期行为的描述要让开发人员指导怎么样子=才是正确的，尤其要以用户的角度来描述符程序的行为是怎么样的。如果是一句需求提出的故障，能写明需求的来源是最好的。
错误行为的描述描述错误的现象。crash等上产log，ui问题可以截图
其他某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些由优先级的分类，严重影响测试需要开发人员优先修改，可以设计优先级为高。
不要把多个 bug 放在一起在无法确定是同一段代码造成的故障时，不要把 bug 放在一起提交。

bug 的级别一般的定义会是有：p0, p1, p2, ...

奔溃：这个bug会导致程序运行失败等... 严重：这个bug不会导致程序奔溃，但是也是需要马上处理的一般：这个bug并不是特别严重，可以先不处理次要：次要的bug就是基本不会影响使用

New：发现问题，还没有指派给谁处理 Open：将 bug 指派给开发 Fixed：开发人员将 bug 修复结束了 Reopen：将 bug 打回 Closed：关闭 Rejected：不是 bug 拒绝 Delay：延迟处理

会有一个系统用于 bug 的管理，当测试发现 bug 后提交到 bug 管理系统，然后由开发在这个系统中将 bug 处理。