做探索式测试的一些杂项总结

2020-12-31 07:05

  现实上,我正在TW的这几年事务中,简直很少操纵过测试用例去测试,正在手工测试中,大无数工夫都是正在做研究性测试。

  这三年中,也会无意会遭受少许格外丰富的流程必要写一个测试用例做向导,测试经过中固然遵照环节去测试,可是当我看到体系的反应有非常地方后,往往会让我立地联念到新的测试途径去考试,直到考试完了,大概才会返回到方才的用例环节中。

  现实上,IT体系现实上口舌常丰富的体系,有良众细节点必要属意,若是这些点都用文字写成测试用例,那事务量及其伟大,很难一起写完。是以关于丰富的营业场景,咱们能够先构想少许主流程的测试剧本,然后正在每个环节中,按照IT体系给你的反应,去决断和选取下一步该奈何测试,而不是死死凭借测试用例去测试。若是必要全部凭借测试用例去测试,这工夫咱们能够让自愿化剧本去做。而QA更该当阐明人的主观能动性,按照体系的差异去做差异的决断。

  根本上绝大无数的自愿化测试剧本都是开采写的,搜罗UI自愿化测试。有较量高的单位测试笼罩率,和蕴涵紧要营业流程的UI自愿化测试,以及对微办事的集成测试等。若是我正在测试中挖掘了一个Bug,平时会看是否必要开采去添补对应的自愿化测试。有了高笼罩率的各类自愿化测试,我能够参加更无数工夫去做研究性测试,去挖掘那些单位测试、UI自愿化测试和集成测试没有挖掘的Bug。

  有工夫我也会去写UI自愿化测试,比如,当步调员开采少许微办事时,为了远隔微办事并让单位测试运转的更疾,团队操纵了mock手法,但这种手法会有少许坏处,比如测试众个微办事之间的移用时,鸿沟处若是有Bug往往会产生漏测,因而我添补写了少许E2E剧本跨众个办事之间,去测试完美的流程,避免漏测的形势。

  最先我会去领悟开采职员以为个bug不必修复的来因是什么,大概会是以下这几种之一:

  A. 界面和UI计划稿差异,或者大一面地方和计划稿相仿,有些细节地方差异。这种处境下,一助咱们会以为UI的审美认识更好少许,若是开采如故不高兴修复,那最好引入UI计划职员一齐叙论。平时叙论后,UI以为有些藐小bug不影响整个格调的大概就不必要修复了,此外一一面对用户体验会酿成影响,是必要修复的。

  B. Bug只产生正在特定浏览器上,比如bug只产生正在IE10或者手机浏览器chrome28上。这工夫,我会按照统计真正用户活动的软件,比如Adobe 的Omniture领悟结果,去确定现正在必要撑持的浏览器类型。平时,一个产物有豪爽的用户,必要撑持的浏览器类型就较量众,可是因为开采职员有限,往往优先撑持Top10的浏览器类型。若是IE10或者chrome28还正在Top10,那就以此和开采职员疏通说bug必要修复。若是不正在Top10的浏览器列外,那就不必修复。有些特定Bug大概还会引入PM,BA等人一齐确定是否必要正在特定浏览器上修复。

  C.有的Bug是易用性题目。开采职员行为本领事务家,熟识电脑和各类迅速键等,因而大概操纵起来感觉没题目,但产物的真正用户中各品种型人都有,比如有年纪大对IT不熟识的,乃至有色盲、或者其他故障的,那么从这些用户的角度去说服Dev这个bug是否必要修复。

  D. 有些Bug修复的effect过大,开采说不值得去修复。这类平时也要和PM, tech lead,BA一齐叙论一下。大概产生三种处境:

  处境1. 若是这个bug的参加产出比众人都以为不相宜,并且影响较量小,大概就不修了,可是最好有个文档去记载已知的不必要修复的bug。

  处境2. 第二种是众人感觉必要修复,可是由于事务量太大,现正在没有工夫修复,那么修卡,放正在Jira的backlog里,等团队有工夫了,由PM断定什么工夫入手做这个卡。

  处境3. 第三种是众人感觉固然事务量大,可是由于对用户影响较大,现正在就修复。那么必要现正在修卡,并铺排高优先级立地开首修复。

  最终,若是当QA和开采有差异的工夫,能够符合的引入PM,BA,Teach lead,UX等来协同做一个决定。

  没有。咱们产物计划到无论是测试境遇、类产物境遇如故产物境遇,都是全自愿化计划的。是以每当开采提交卸码后,会自愿计划到测试境遇中。这里不必要QA手工插足,减削了良众工夫。

  因为不必要写测试用例,也减削很不少工夫。有些公司要写测试日报或者每周测试呈报,这里都不必要。也不必写机能测试呈报,我把机能测试结果记载正在Jira卡中,和团队分享就能够了。我记得本年就写过几个概要的产物测试计谋文档,以及十众篇测试阅历分享的Blog。别的,其他文档写的很少。

  我概略统计一下,咱们每天做的story card里,有70%~75%旁边会被转移回开采篡改Bug。此中大无数处境下,一张卡有3到8个Bug(咱们这里平时一张卡会是1到3一面天),最众有过一张卡快要20个Bug,但这种处境是极少数才会爆发的。

  如有让你测试一个叫“八星高颗粒子挽回通道”的东西,你会测试吗?根本上没有几一面能测这个东西,由于没有人领会“八星高颗粒子挽回通道”是干什么的。但若是你适值是“八星高颗粒子挽回通道”的本领开采职员,你做出了这个东西,那你对全盘构修经过很熟识,对每个影响最终产物格料的变量都有过亲身的体验,那你就领会哪里容易把产物伤害掉,也领会哪些变量和输入有大概是做这个东西的人有大概脱漏的。因而你就容易挖掘这个产物的缺陷。

  而开采职员做测试的自然上风一,即是他万分会意做这个产物的全盘经过,明了全盘经过中有哪些变量会影响产物格料。他也领会本人正在做开采工夫,往往会疏忽大意遗忘那些点没做,因而也能预判到别人会正在哪里产生脱漏和缺陷。因而开采阅历越众,做测试越容易。

  本年上半年工夫,我紧要事务的中央转到助助开采团队进步测试才智上。咱们有11个开采,一个QA,有工夫测试忙只是来,也会闪开发去从ready for QA列捡卡测试。我之前采用的方法是,写少许blog,分享少许测试阅历,以及和开采一齐结对测试。此中结对测试是通报学问较量有用的方法,开采和我坐正在一齐,协同操纵一个大显示器,做研究式测试,按照体系的反应断定接下来测试的实质。

  只是我现正在又会意到了另一种进步开采测试才智的手法,自此有机缘能够考试一下:这个手法是QA不去测试任何一张卡,一起卡都由开采去测试。QA紧要做两一面事务:

  第一步,正在每张卡上加上解释,阐发这张卡要体贴的测试点,或者和开采面临面疏通一下必要着重测试那些点。

  第二步,当开采交叉测试完后,必需给QA演示他测试的经过。这工夫QA若是以为没有题目,那么这张卡就挪到done了。若是QA挖掘少许题目,那大概会篡改之前写正在卡上写的测试解释,同时,开采会添补测试这些之前没有测到的旅途。

  * 开采若是把Bug漏到产物境遇后,原委几次教训,他本人测试的才智肯定进步很疾。

  * 一个能做好测试的开采,他本人开采出的代码质料也肯定会进步良众。删除Bug的产生能够减削一大笔项目本钱。

  刚来TW,能鲜明感触到众人的本领才智不错,并且公司的本领交换气氛也很好。和一群非凡的本领达人配合,有几个好处:

  * 团队每一面都探索高质料的产物,若是研发施行没做到位,众人都担心适。比如单位测试笼罩率补够,code review不充塞等,众人都邑尽量避免。

  到目前为止,我很爱测试事务。每次研究式测试,就像从迷宫中寻寻得途,或者像是解题经过,从各类蛛丝马迹中寻找大概存正在的产物缺陷,这是测试让我觉得欣喜的第一一面实质。 第二一面实质是,正在大一面处境下,我会从每张卡上寻得少许列的题目给开采,等开采实现后,我能够感触到这一面的产物格料一经不错了。有好的产物格料是让我觉得有结果感的此外一一面来因。

  版上问何如写高效的测试用例的那位老兄该当看看这个贴。写周到的测试用例实正在很过期了。

返回顶部