软件测试—基础篇

软件测试—基础篇

在此之前,关于软件测试的相关概念软件测试之概念篇了解一下

软件测试的生命周期

定义bug的级别

各个公司对bug的定义不太一样,
– Blocker(崩溃):主要功能丧失,基本模块缺失等。如系统崩溃,数据库缺失等问题,这种较少见,一旦出现立即中止测试。
– Cirtical(严重):功能与需求严重不符,一级功能菜单缺失但不影响其他功能测试,在不影响其他功能测试的情况下可以继续进行测试
– Major(一般):功能未完全实现但不影响使用
– Minor(次要):界面、性能缺陷,建议类问题,不影响操作功能的执行,可以优化性能的方案。

bug的生命周期

从new到closed的所有状态
不同公司,不同工具对bug生命周期的定义不太相同
以下为bug状态转换图:

这里写图片描述

七种状态:
– new:新发现的bug,决定是否交给开发人员去修改
– open:确认是bug,并认定要修改,分配给特定的开发人员修改
– fixed:开发人员修改后标记成修改状态,等测试并进行人员进行回归测试
– rejected:若认为不是bug,则拒绝修改
– delay:无关紧要的bug延迟修改
– closed:修改状态的bug在测试人员回归测试验证通过之后,关闭该bug
– reopen:经验证bug未修复,要重新打开,开发人员重新修改

如何开始第一次测试

与测试组长确认工作内容:
测试计划试内容试案例多少排几天执行/p>

测试的执行和bug管理

测试执行过程:

  • 打开待测系统
  • 执行测试用例
  • 发现bug(复现并记录复现步骤)
  • 记录bug
  • 沟通bug
  • 验证以前提交的bug
  • 完成测试
  • 撰写测试 告

如何发现更多的bug:

  • 软件测试存在二八原则,80%的故障存在20%的模块,对问题出现多的模块,加强测试深度和广度
  • 开发人员也存在二八原则,80%的bug由20%的开发人员产出,加强容易出bug的开发人员开发模块的测试深度和广度
  • 多进行逆向思维和开发性思维
  • 不局限于测试用例和需求文档
  • 早早介入项目,提前了解项目的开发流程和核心思想

处理人际关系

完成一个项目时,开发人员与测试人员难免产生冲突,具体产生冲突的原因可能有:对一个bug的判定、bug级别的确定、立即修改还是延迟修改等,这些问题都有可能使开发和测试人员之间发生争执。
遇到争执不要怕,记住批判性思维:清楚–准确、切题–深刻,有意义,有逻辑性–公正、全面。

当发生争执时,作为一个测试人员,首先要做好以下几点:

  • 先检查自己是否将bug描述清楚
  • 站在用户角度思考,这样的bug会不会对用户造成影响,有没有完全满足用户需求
  • bug的定级要有根有据,最好站在用户角度上考虑定位级别
  • 最关键的还是要提升自身技能和业务水平,在提出bug的同时,还要提出解决bug的思路
  • 避免与开发人员争吵

接下来进一步学习软件测试之用例篇

声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2018年6月17日
下一篇 2018年6月17日

相关推荐