软件测试一

一、软件测试的生命周期

软件测试的生命周期：需求分析→测试计划→测试设计、测试开发→测试执行→测试评估
软件开发的生命周期
★ 需求阶段
测试人员了解需求，对需求进行分解，得出测试需求
★ 计划阶段
根据需求编写测试计划和测试方案
★ 设计阶段
搭建测试用例框架，编写一部分测试用例。
★ 编码阶段
测试人员执行单元测试、完善细化测试用例以及调整测试计划和方案。
★ 测试阶段
执行测试、记录管理缺陷，编写测试报告。
★ 运行维护
参与用户的软件培训，将试项目时收集的问题加以整理。

二、如何描述一个bug

▲ 发现问题的版本
开发人员要知道出现问题的版本，才能够获取对应版本的代码来重现故障。
▲ 出现问题的环境
环境可以分为软件环境和硬件环境，详细的环境描述有利于定位故障。
▲ 错误重现的步骤
描述问题出现的最短步骤
▲ 预期行为的描述
根据需求提出的故障，能写明需求的来源是最好的。
▲ 错误行为的描述
描述错误的现象，crash等可以上传log，UI问题可以有截图。
▲ 其他
一些公司故障会有一定的分类，有些有优先级的分类，需要开发人员进行优先修改，可以设置优先级为高。
▲ 不要把多个bug放在一块。

三、如何定义bug的级别

bug 的定义级别是不一致的，在定义级别之前需要查看公司规划。
1、Blocker（崩溃）
2、Critical（严重）
3、Major（一般）
4、Minor（次要）

四、bug的生命周期

每个公司，每一个工具对于bug生命周期的定义都是不一致的，
测试人员应该跟踪一个bug的生命周期，从New到closed的所有状态。
bug状态的转换图

New:新发现的bug，未经评审决定是否指派给开发人员进行修改。
Open：确认时bug，并且认为需要进行修改，指派给相应的开发人员。
Fixed：开发人员进行修改后标识成修改状态，指派给相应的开发人员
Rejected：如果认为不是bug，则拒绝修改
Delay：如果认为暂时不需要修改或者暂时不能修改，则延后进行修改
Closed：修改状态的bug经测试人员的回归测试验证通过，则关闭bug
Reopen：如果验证bug仍然还是存在，则需要重新打开bug，开发人员重新进行修改。

无效的bug：open->closed,open->rejected->closed
bug的跟踪以及状态变更应该遵循一些原则

• 测试人员对于自己每一个缺陷的修改必须重新取一个包含变更后的代码的新版本进行回归测试，确保相同的问题不再出现，才能关闭缺陷。
• 对于延迟和拒绝修改的bug，需要经过包含测试人员代表和开发人员代表吗，用户方面的代表的评审。

五、如何开始第一次的bug

1、阅读所有的项目有关的文档
2、尽可能的参加各种项目会议
3、熟悉项目所使用的测试管理工具
4、阅读已有的测试方案和测试案例
5、阅读旧的bug库，
6、了解公司的规范要求

六、测试的执行和bug的管理

1、打开待测试的系统
2、打开测试管理工具用例模块，开始执行用例（测试执行之前先要进行冒烟测试、系统测试、回归测试）
3、发现bug！进行复现并确认bug的复现步骤
4、记录bug
5、沟通bug
6、验证以前提交的bug
7、确认本次测试完毕
8、编写测试报告

七、如何发现bug

1、软件测试同样存在二八原则，如果某个部分的bug较多，加强测试的广度和深度。
2、开发人员也存在着二八原则，如果开发人员的bug平时比较多的话，就要对其加强测试的广度和深度。
3、多进行逆向思维和发散性思维
4、不要局限于用例和需求文档
5、尽早介入项目，不要等到开发差不多了，再介入项目。