软件测试基础(2)

r囧r小猫 2024-04-06 15:54 83阅读 0赞

## 如何开始第一次测试 ##

作为一个菜鸟在进入测试团队开始第一次测试的时候, 我们需要做很多准备:

> 1.阅读所有项目有关的文档, 包括:需求文档, 设计文档, 用户手册.
> 
> 2.尽可能参加各种项目会议, 了解项目的背景, 人员组成, 尽可能的了解需求和业务. 特别针对业务专业性较强的项目, 例如银行业务, 需要了解各种业务知识,如高低柜, 一二三类账户等, 存款, 贷款等.
> 
> 3.熟悉项目所使用的测试管理工具, 配置管理工具, 获取对应的地址和登陆方式.
> 
> 4.阅读已有的测试方案和测试案例.
> 
> 5.阅读旧有的BUG库, 了解系统功能. 更重要的是和现有的测试团队保持一致的故障定级规则.
> 
> 6.了解公司的规范要求, 特别是用例编写规范, 用例执行规范, bug提交规范, 测试工具使用规范等.

在进行了以上的准备工作之后, 第一次测试的工作到来了, 我们需要与测试组长确定具体工作内容:

> 1.测试的计划是什么?
> 
> 2.测试的内容是什么? test case有多少? 安排了几天进行? 有没有自由测试的时间?
> 
> 3.我们要测试的内容开发人员是谁? 需求人员是谁?
> 
> 4.分配给我的测试内容是否需要特殊的测试资源? 资源是否满足需要?

在我们确认了上述内容之后, 就可以开始测试的执行了.

## 测试的执行和bug管理 ##

现在我们开始进行测试了:

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

执行测试时处理要做到测试用例和需求的覆盖外, 还要有临时发挥的能力. 根据自己的经验, 对测试的感悟以及随机测试可以发现更多根据测试用例无法发现的缺陷.

不能拘泥于测试用例或者已经有的测试方法, 在测试执行过程中要不断总结测试方法和测试故障的模型. 真正优秀的测试人员在执行测试时是想着做, 做着想, 这样的测试效果才好, 尤其是在测试过程中, 对程序的处理相当了解的情况下, 测试的思路会更加清晰和全面.

### 如何发现更多的bug? ###

> 1.软件测试同样存在二八原则, 80%的故障集中于20%的模块, 如果某部分问题较多, 加强测试的广度和深度!
> 
> 2.开发人员也存在二八原则, 80%的故障集中于20%的开发人员, 如果某些开发人员的bug比较多, 加强对他模块测试的广度和深度!
> 
> 3.多进行逆向思维和发散性的思维.
> 
> 4.不要局限于用例和需求文档.
> 
> 5.尽早介入项目, 不要等开发的进行的差不多了再介入项目.

> 发散一下: 以注册需求来进行一次测试?
> 
> 功能: 需求所描述的功能.
> 
> 功能其他: 需求未考虑到的: 邮件内容是否正确? 连续注册?
> 
> 边界:最大值,最小值等
> 
> 界面:美观, 整齐
> 
> 校验: email格式校验, 错误校验, 已注册校验, 输出校验, 为空等.
> 
> 兼容性:IE, 360, CHROME
> 
> 安全性: 验证码能否起效? http请求能否直接发送
> 
> 性能:多用户并发.
> 
> 其它?

## 产生争执怎么办?(人际关系) ##

**能让开发人员解决最多Bug的测试人员是最优秀的测试人员.**

测试工作中, 最常遇到和开发人员的PK, 作为测试经理还需要与项目经理, 产品经理PK进度,质量.

作为一个测试人员, 一般会遇到以下几种情况:

> 这不是bug
> 
> 这个bug的级别太高了
> 
> bug影响不大, 暂不修改

**遇到争执, 先不要怕, 记住批判性思维: 清楚--准确, 切题--深刻, 有意义, 有逻辑性--公正,全面.**

> **1.先检查自身, 是否bug描述不清楚**
> 
> 如果能正确地, 高质量地录入一个Bug, 那么基本上已经成功地与开发人员沟通了一大半的关于Bug的信息. 但总有"书难达意"的时候, 这时候就需要测试人员主动和开发人员进行沟通了. 如果测试人员发现写完一个缺陷后, 好像还有很多关于Bug的信息没有表达, 或很难用书面表达, 就应该在提交bug之后, 马上找相关程序员解释录入的bug, 确保程序员了解bug的意思.
> 
> **2.站在用户的角度思考问题**, 应该让开发人员了解到bug对用户可能造成的困扰, 这样才能使开发人员更加积极地, 高质量地修改bug. 在争执时, 可以问一句:如果你是用户,你可以接受吗?
> 
> **3.bug定级要有理有据**
> 
> bug定级时, 不仅要参考bug级别, 还要考虑到bug是否会影响到流程, 往往用户的bug级别和我们的是有区别的, 需站在用户的角度考虑定位级别.
> 
> **4.提高自身的技术和业务水平. 不光要提出问题, 最好也要提出解决方案.**
> 
> 在工作中, 你会发现同一个bug, 资深测试工程师和初级测试工程师提出, 两者的结果完全不同, 两者最大的区别是资深测试工程师往往会提出解决方案. 而长此以往, 权威性就会建立起来. 使得开发人员对你的判断信服性更高.
> 
> eg:某网站经常隔几天访问时出现500错误, 但是之后就不会复现.
> 
> 测试人员提出问题: 网站偶发性出现500错误.
> 
> 开发人员回答; 不常见, 不影响使用, 暂不修改.
> 
> 资深测试人员提出问题: 网站偶发性出现500错误, 查看日志, 是由于mysql数据库8小时超时问题造成. 需要修改连接池配置定期校验连接.
> 
> 开发人员处理:修改xml, 增加校验配置项.
> 
> 5.**开发人员不接受时, 不要争吵**.
> 
> 可能你已经进行了多轮沟通, 但开发人员仍不接收. 此时可以发起bug评审.
> 
> bug评审要注意的问题 : 1.决定如何处理bug 2.分析缺陷产生原因, 找出预防对策.
> 
> (1)决定如何处理bug. 这一方面评审需要项目组各个方面的代表参加, 通常是测试代表, 开发代表, 产品代表.
> 
> 测试代表主要从bug的具体表现, 严重程度等方面提供信息, 并提出自己对bug的处理意见.(需要注意不应一味要求对bug的修改, 因为修改可能带来回归的风险, 同时带来回归测试的工作量, 如果时间紧迫, 没有时间进行, 不修改可能更明智).
> 
> 开发代表主要从修改缺陷的难度和风险出发, 考虑修改付出的代价, 影响的范围, 可能引发的风险等, 如果决定要修改, 还需要讨论修改的初步方案.
> 
> 产品代表主要从产品的整体计划, 用户的要求等方面对缺陷修改的必要性, 缺陷修改的时间和版本提出意见.
> 
> (2)分析缺陷产生原因, 找出预防对策. 缺陷评审还应该包括原因分析, 找出bug出现的原因,彻底根除重复出现的bug. 找出错误产生根源, 并指定预防措施, 确保同类型的bug不再出现.