内容纲要:

软件测试的生命周期

如何描述一个bug

如何定义bug的级别

bug的生命周期

如何开始第一次测试

测试的执行和bug管理

产生争执怎么办

1. 软件测试的生命周期

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

• 需求分析:需求是否正确,是否可行
• 测试计划:项目什么时候开始测试,结束测试,由谁测试
• 测试开发:设计测试用例,开发测试工具
• 测试执行:执行测试用例,发现bug,提交bug,验收bug
• 测试评估:测试人员需要产出一个测试报告

测试报告:

项目名称,项目代码地址,开发人员,测试人员,项目计划,测试用例,bug......

文档:

以邮件方式周知到项目相关人,整个产品,开发,测试团队

问:

测试执行阶段要用到的测试方法确定了吗?

答:

确定了,在测试计划已经选择了测试方法

 

2. 如何描述一个bug

 一个合格的bug描述应该包括以下几个部分：

• 发现问题的版本
• 问题出现的环境
• 错误重现的步骤
• 预期行为的描述
• 错误行为的描述
• 其他
• 不要把多个bug放到一起

举个例子:

版本:V1.0

环境:浏览器

错误重新的步骤:输入账号123,密码123(均正确)

预期行为:登录成功,跳转到首页

错误行为:跳转到列表页面

优先级:严重

3. 如何定义bug的级别(依公司而定)

①Blocker（崩溃）：

阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。

如：代码错误、死循环、数据库发生死锁等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

②Critical（严重）：

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用等。

如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

③Major（一般）：

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。

如：格式错误、边界条件错误等(该问题实际测试中存在最多）

④Minor（次要）：

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

如：错别字、界面格式不规范（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

 

4. BUG的生命周期

 

注: 

• Delay的BUG不是不修复,只是当前版本不修复,但是未来一定要修复.
• 如果出现了Delay和Rejected这种BUG,QA一定要将这些BUG告知给相关人,以及项目相关人的Leader.
• 发送测试报告时一定要指出Delay和Rejected这种BUG. 

5. 如何开始第一次测试

5.1 测试的准备工作

• 阅读所有项目有关的文档，包括：需求文档、设计文档、用户手册
• 尽可能参加各种项目会议，了解项目的背景、人员组成、尽可能的了解需求和业务。特别针对业务专业性较强的项目，例如银行业务，需要了解各种业务知识，如高低柜等。
• 熟悉项目所使用的测试管理工具、配置管理工具，获取对应的地址和登录方式
• 阅读已有的测试方案和测试案例
• 阅读旧有的bug库，了解系统功能。尤其重要的是和现有的测试团队保持一致的故障定级原则
• 了解公司的规范要求，特别是用例编写规范、用例执行规范、bug提交规范、测试工具工具使用规 范等

5.2 具体的工作内容

• 测试的计划是什么？
• 测试的内容是什么？test case有多少？安排了几天执行？有没有自由测试的时间？
• 我要测试的内容开发人员是谁？需求人员是谁？
• 分配给我的测试内容是否需要特殊的测试资源？资源是否满足需要？

之后就可以开始执行测试了......

6. 测试的执行和BUG管理

6.1 进行测试

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

6.2 如何发现更多的BUG 

• 软件测试同样存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度和深度！(某些复杂逻辑的模块容易出现BUG)
• 开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的bug较多，加强他开发模块的测试广度和深度！(某些开发人员开发质量低)
• 多进行逆向思维和发散性的思维
• 不要局限于用例和需求文档(是依据,不完全依赖)
• 尽早介入项目

7. [重点]产生争执怎么办(处理人际关系)

问:当你发现了一个BUG,但是开发却认为这不是一个BUG,怎么办?   

①先检查自身，是否bug描述不清楚

②站在用户角度考虑问题,问：如果你是用户，你可以接受么？

③BUG定级要有理有据

④提高自身的技术和业务水平. 不光要提出问题, 最好也能提出解决方案

案例：

某网站经常隔几天访问时会出现500错误，但是之后就不会复现。

测试人员会提出问题：网站偶发性出现500错误。

开发人员回答：不常见，不影响使用，暂不修改

资深测试人员提出问题：网站偶发性500错误，查看日志，是由于mysql数据库8小时超时问题造成。需要修改 连接池配置定期校验连接

开发人员处理：修改xml，增加校验配置项

⑤开发人员不接受时，不要争吵

⑥三方讨论会