10分钟看尽全程软件测试

发表于:2018-1-29 14:07

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:山丘的测试之道    来源:博客园

分享:
  针对接口的处理逻辑进行设计:
  针对输出结果设计:
  其他方面考虑:
  · 接口超时处理
  · 废弃接口处理
  二、测试用例评审
  测试用例的评审无疑是为了给测试用例进行查漏补缺。
  评审方式:
  · 测试内部评审
  · 项目组评审:项目相关人参与评审(开发、测试、产品)
  注意:
  · 项目组评审时,一般是会议的形式,由于测试用例的数量关系,会议上评审会占用很长的时间,造成时间资源的浪费。
  · 建议大家在评审前先将测试用例邮件发送给评审会议相关人,让他们提前能对测试用例进行了解,熟悉。会议中进行反馈,记录后,会后再修改。
  三、测试执行
  前面的工作做的充足的话,在测试执行的时候就会非常简单了。只需要根据测试用例一条一条去执行程序即可。发现缺陷就提交缺陷,测试通过就继续回归。
  各位看官现在应该是心里一万个XXX呼啸而过~~哪有说的那么简单。
  其实测试执行的过程真的很简单,只是在执行的过程中各部门的协作,沟通以及各项文档的输出很复杂。下面我们来聊聊在测试执行过程要注意的几方面问题。
  1、测试与开发的沟通
  “XXX 我这有个问题,你过来看下”
  “什么问题?你演示下我看看”
  “这不是问题,这个地方只能这样做”或者 “这不是问题,我刚刚跟需求确认过的”
  “这样做不合逻辑啊!”
  “那你说怎么处理?”
  “我觉得应该....处理”
  “你先跟需求确认下吧”
  这应该是测试工程师的日常吧。测试与开发沟通无疑是关于某个功能或者产品的,主要围绕几个以下几个点:
  · 程序某个地方存在问题
  · 产品需求信息在测试和开发中不统一
  · 程序某功能应该是怎么处理
  · 缺陷修复后的验证
  既然知道问题的核心,我们就要想办法规避这些问题。假设一开始提问题的时候就把问题的特征,位置,以及操作步骤,截图都一目了然的提交给开发,是不是很大程度上可以节省测试演示的时间?
  另一个最容易出现的问题就是信息不统一,这个需要整个项目组有意识的培养健全的工作流程,通过工作流程来规避这种信息不对称的情况。这种情况将大大增加测试与开发的沟通成本。
  2、测试与需求的沟通
  测试人员与需求的沟通难点主要还是体现在需求不明确或者需求变更上。
  很多时候需求人员的需求文档都是不全面的,测试人员在写测试用例时需要一次又一次的与需求进行确认,一来二去,需求估计有种想把桌子里40米长的大刀放桌上来。
  另一方面在项目过程中,不可避免的会出现需求变更,只要出现变更就意味着之前的测试准备工作就作废。
  所以在与需求的沟通是非常频繁又火星四溅的,那怎么更好的与需求进行沟通呢?
  · 切记不能停留在口头沟通,确认
  · 所有的需求确认或者需求变更都需要文档化,实在不行也需要发邮件
  · 每一次确认、变更都需要通过项目相关人
  · 建立完善的需求变更体系,流程上控制需求变更
  3、测试结果的反馈
  相信大家应该遇到过偶现的缺陷,开发重现时就没有了,忙活了半天,被开发嫌弃了一顿
  测试结果的反馈容易出现问题的地方就是结果描述不清楚,增加项目的时间和沟通成本。解决这个问题最好的办法就是将测试结果尽可能的描述清楚。
  测试结果反馈分为两种:
  · 在沟通工具中向开发反馈缺陷
  · 在缺陷管理工具中提交缺陷
  到底怎样提交/描述清楚一个缺陷?在下文中,我会详细介绍。
  四、缺陷管理
  在开发阶段,测试人员最重要的产出就是缺陷。缺陷不仅仅是数量多,就越有价值。更应该关注缺陷的质量、缺陷的管理以及缺陷分析。
  怎么样提出质量高的缺陷?怎么样对缺陷进行管理和分析?见下图
  
缺陷处理流程图
  缺陷管理是软件测试活动中极其重要的一环,很多时候测试用例并没有发现多少缺陷,反而自己在运行程序的过程中发现了很多缺陷,那这些缺陷就是对测试用例的补充,对之后的测试就可以提供思路。
  小结:
  在开发阶段,测试人员最主要的工作就是发现缺陷,但是在这个过程中会伴随着很多其他的问题,需要我们在工作流程中去规避。最重要的就是把测试放在整个项目中,是各个部门的团队协作。
  很多团队的问题并没有出在测试用例设计,测试执行,缺陷提交中,更多的出现在各部门之间的沟通、协作中。
  发布阶段
  进入发布阶段就意味着产品已经通过了测试,可以发布到线上,交付给用户使用。那如何确认测试已经通过?在发布过程中,我们测试人员又需要完成哪些工作?
  测试通过准则规范
  上线前,需要确认测试已经通过,现在程序越来越复杂,如果没有量化的规范,就很难确定测试到什么时候可以上线。所以我们需要设定测试通过的准则,只有达到准则才能上线
  · 测试需求功能覆盖率100%
  · 测试用例通过率95%以上
  · 遗留缺陷没有严重程度3级以及以上的缺陷
  测试报告
  完成测试后,提交测试报告,给出此次测试过程中的数据,例如:测试用例的数量,发现缺陷的总数,各个严重程度的缺陷数量,总共修复的缺陷数量以及缺陷修复率等等
  系统回滚方案
  每一次发布都不能说百分之百的没有问题,如果真的出现问题,我们该如何处理?
  · 如果线上出现的问题不是很严重,尽量当时处理掉再上线
  · 如果线上出现的问题很严重,就必须要系统回滚,保证线上用户的正常使用
  · 系统回滚方案须跟开发/项目经理确认
  线上功能检查
  · 程序原有功能的回归测试
  · 新上线的功能全面测试
  小结:
  每一次发布后,测试人员都应该持续反馈,改进、总结每个版本中遇到的问题,不管是缺陷还是流程问题,从一次次的问题中总结一些经验,提高整个软件生命周期的质量
  日常维护阶段
  产品上线后,用户能稳定的长期使用,就意味着发布的功能进入到日常维护阶段。而这里并不是终点,这个阶段将一直存在。
  在这个阶段,测试人员的主要工作就比较简单
  · 持续测试,没有产品是没有缺陷的
  · 即使收集用户反馈的问题,并尽快组织人员修复
  · 长时间稳定性测试(自动化测试)
  总结
  全程软件测试,关注的是在整个软件生命周期中,各个阶段的测试活动。
  通过对各个阶段的过程质量把控,从而提高产品的测试质量。产品的质量并不是测试能决定的,而是整个项目构建过程中,通过一次次的优化过程,不断的总结成长,是整个项目团队决定的。
  不同的工种都在这个过程中起到举足轻重的作用,而全程软件测试强调不断提高每个阶段的质量,最终提高项目团队的综合能力,从而提高产品质量

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
22/2<12
100家互联网大公司java笔试题汇总,填问卷领取~

精彩评论

  • aaa616798887
    2019-8-01 18:19:16

    写的真心好 学习了 !!

  • 春雨
    2018-3-12 15:37:18

    文章写不错

  • daleiwenting
    2018-2-27 10:46:11

    写的很好,梳理的也很清晰,一目了然,棒!

  • liujh1211
    2018-2-23 14:22:33

    文章梳理的很棒,受益非浅

  • xinyu2012
    2018-2-07 09:21:27

    文章很不错,受益非浅~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号