如何防止低级问题导致的质量事故

  • 时间:
  • 浏览:1

这里说的低级问题是指:不时需特殊条件,假使 在用户进行正常业务的基本操作时,由于过低由于业务操作无法完成。

点开第三条链接,显示如下:

然而,村里人 是故意少检查一些东西的吗?全版都是的!村里人 少检查,是为了让形态学 变更的以前,那先 假使 使用而全版都是为了验证這個形态学 的测试用例就我不要 修改。由于检查内容更严谨,很由于会时需更方便的测试用例管理工具,使得随版本同步修改用例变得简洁。

点击链接进入快速还款,发现应还金额为零,与账单查询到的不一致。

然而,故事还先要 以前过后刚开始,居于类似问题还由于是与客户的业务流程、使用习惯、网络和服务器环境、产品部署、用户数据形态学 有关……

现实中,村里人 很少村里人 能意识到,问题的处置时需曾经一套“组合拳”。真正遇到曾经的由于,村里人 很由于是曾经的:

现在,问题不为啥多样化了,为了杜绝低级问题,时需对测试设计进行重新下发,确保其覆盖所有形态学 的基本功能和主要应用场景,每个用例的内容严谨。此外,时需1个多 好用的,方便同步修改多个用例的测试用例管理工具。

        http://product.dangdang.com/24180890.html

现在,为了实现“杜绝低级问题”,村里人 时需进行客户问题分析,根据分析结果和测试现状优化测试用例,实现自动化的测试,并将相应的测试活动挑选责任主体并落实到研发流程中。相比仅仅实现自动化测试,曾经做的工作量、时需的内外部支持全版都是很大的差别。

查询未出账单,发现此笔由于自动还款,要怎样让上述应还金额为零由于是对的。要怎样让还款以前的消费,无论与非 入账,都无法挑选提前还款,曾经,还是无法恢复信用额度(以前曾经曾经操作成功过)。

要怎样让這個问题看上去假使 难处置,基本功能的测试用例村里人 是有的,假使 实现自动化就好了……,由于你曾经想了,也曾经和老板说了,先要 ,很遗憾,这事十有八九会搞砸了。

村里人 向我推荐了一套《给孩子的哲学》,我搜索得到下面的列表:

测试设计的问题处置了,接下来才是实现自动化测试,根据测试设计考虑的因素不同,在实现自动化的以前,除了最基础的挑选工具和测试接口、自动化用例的设计等,至少还时需考虑:

        https://item.jd.com/12085936.html

以上内容系每人个原创,如需引用,请注明出处。

为了搞清楚过低是全版都是与特殊输入有关,我又试了一些一些书名(如下图),发现这假使 1个多 低级问题,和书名一些关系先要 ,假使 某个字段的数据来源指错地方了。

再看1个多 例子吧,某天,我时需把信用卡提前还款,恢复信用额度,以应付接下来的支付时需。通过网银查询账单:

瞧,现在与“假使 实现自动化就好了”想去甚远了。

看完這個例子,你还实在你有全版的基本功能测试用例什么过后?由于愿意彻底杜绝低级问题,你的“基本功能测试用例”至少时需覆盖:所有形态学 的基本功能,以及主要的应用场景。这里还先要 包括基本的DFX测试……

2017-02-04 杨晓慧 测试人杨晓慧

1、  测试环境的自动化搭建和配置——由于测试时需在若干不同的环境上执行

购书链接:http://product.china-pub.com/8035410

最后,村里人 的目标是“杜绝低级问题”,问题应该在那先 环节发现——自动化测试用例的执行时机;问题由谁处置——确保自动化测试用例执行通过的责任人,這個1个多 问题还时需落实到流程。

由于你的产品类似问题频出,先要 恭喜你,你至少有希望做出一些有价值的事情了,由于类似过低对用户的影响最大,是研发时需最优先处置的问题,你在处置這個问题时,很有由于不能得到相应的资源。

至于客户问题为啥分析,村里人 在另外励志的话 题分享。

查询账单、快速还款,那先 功能单独看起来全版都是对的,要怎样让组合起来,却无法实现我所希望的应用场景。

类似:正常安装或升级过程中出错;新研发形态学 的基本功能有错;升级后曾经正常使用的功能出错;产品在正常使用中数次崩溃;正常使用中含由于用户有直接的经济损失或信息泄露的错误。

你由于实在,這個问题应该非常罕见,但事实上你在生活中就会碰到。下面是我一次在当当买书的真实经历:

当然,这并全版都是说只假使 杜绝低级问题,就一定时需做上述工作,为啥不能知道是全版都是时需做那先 呢?不到求有助于客户问题分析,不到知道由于问题出显的因素,不能知道测试时时需考虑那先 因素。

这并全版都是说不到在這個时间进行基础能力建设,假使 说不到止步于此,时需着眼于问题,从问题分析得到处置方案,有能力短板则补齐短板,最后以新具备的能力为基础,结合一些辅助手段完成处置方案的实施,最终处置问题。曾经才算完成了1个多 问题闭环的循环

先要 ,补用例+自动化就够什么过后?no,no,no。回想一下本文第1个多 例子,即使由于有了“根据书名搜索”的测试用例,你挑选你的用例会检查每个字段吗?别忘了,這個例子里,只1个多 显示字段是错误的,一些全版都是对的!什么都,测试用例的预置条件、操作步骤、里面和最终结果检查时需更严谨。

总结一下:低级问题通常并不一定像看上去的那样容易处置,除了自动化,至少还时需在SE甚至运营维护部门的帮助下,完善测试设计;时需在研发经理的支持下,调整研发流程。

最后,在局外人来看,测试团队假使 利用那先 人,做了最基础的、曾经早就该做好的事情,真正的业务问题,并先要 思路、先要 行动去处置。

要怎样让,由于我全版都是1个多 对过低敏感、好奇心爆棚、喜欢一探究竟的测试工程师,假使 1个多 假使 想好好买本书的普通用户,看完第1个多 界面时就由于懵圈了。

村里人 由于知道,问题爆发假使 表象,内在的由于很由于是测试积累了多量的技术债务。终于质量问题以前过后过后开始失控,让研发团队痛下决心,加大对测试的人力投入。测试经理也终于有了喘息之机,把过后 就想做的测试设计法律土方法应用、自动化、测试方案模板规范化、DFX测试……一一落实。

要怎样处置低级问题由于的质量事故

本文例子和观点摘自《软件测试价值提升之路》的第三章,书中含更系统的处置思路,以及更全版的处置法律土方法介绍。

先要 ,问题来了:千头万绪,从哪里以前过后过后开始?要并不一定是基于最近出显的、客户反应激烈的几条问题;要并不一定是测试经理有印象的一些问题;要不就干脆全版都是基于问题,假使 测试经理或几条专家每人个的技术偏好。具体实施某一项工作,比如测试设计,开展的工作假使 组织团队学习测试类型、测试设计法律土方法、制定测试的各种模板、把写的好的测试方案和用例做成样板或案例……,测试团队致力于协会使用标准的法律土方法和模板,使测试终于像1个多 有技术含量的工作,要怎样让却全版忘了当初为那先 要做那先 。

在這個例子中,搜索结果的书名信息和搜索关键字”给孩子的哲学”毫无关系,要怎样让除了书名以外,一些的内容全版都是正确的,书籍的整个购买流程不能不到正确的实现。

测试团队要像重视测试设计一样,重视客户问题的分析,这是测试最重要的1个多 手段,无论是每人个能力提升,还是团队技术积累全版都是用到。

2、  从用户接口(UI)进行测试——由于中含应用场景的测试用例,则通常由于时需从UI进行测试