参加培训后,这个收获应该来说是大的,也给了我思考问题的不同的角度,先说下历史吧:还是从bug说起吧,我们都知道bug是我们测试人员永远都要讨论的话题,之前也说了,把bug分为2类:一个是新功能的bug,一个是旧功能的bug。其实还有一种bug是客户发现的bug。那么对于这三种bug,会想出不同的方法和team来对付这些bug,

  我们的目标是发现更多的新功能的bug,减少旧功能和客户发现的bug。目标确定后,要组织team和系统去测试这些,培训老师给的方案也是思科公司目前的做法:一个功能测试部专注于测试新的项目,新的功能,发现新功能的bug;一个回归测试部专门负责所有旧功能的回归工作,并发现旧功能的bug;后一个是解决方案测试部,专注于研究用户使用环境,模拟线上真实环境,尽大可能发现用户发现的bug。

  上面我们可以看到的是有3个team在整个产品周期中所起到的作用,第一个功能测试部的运作方式大家都很熟了,这里不详细说了。下面说下回归测试部的运作方式:这里有2个前提,那是产品的基线库的建立,一定要完备,二个是以前功能测试用例的自动化程度要高,才能启动回归测试部的工作。首先说下回归测试任务的参与阶段,同样是在系统质量稳定后,

  大概是第三轮测试的时候,这里可是24X7 auto regression所有功能。不停的跑以前功能的测试脚本,像火车一样,定时开始运行,哪个项目上线,赶上哪趟火车上,其测试人员负责运行所有脚本,分析产生的bug(是脚本问题,还是旧功能的bug,测试环境问题),以及report所有的bug。这里回归测试部的人员不负责维护脚本。

  怎样使回归测试部的管理更好呢:首先采用标准的拓扑结构的测试床(测试环境);并行的运行所有的脚本;对测试床的有效性和回归周期进行有效的关联;对脚本的要求是如果一旦硬件环境等问题可自动重启服务,继续运行后面的脚本。

  这里还有个小问题是我们发现的问题怎么判断是是bug呢? 这里说到基线的作用了,我们会与基线相比较来确定是否bug和分析。有4种情况:

  第一: 基线是 Pass的,加入新功能后回归 是Pass的。  不用分析的,直接跳过。

  第二: 基线是 Fail的,加入新功能后回归 是Pass的。  不用分析的,直接跳过。

  第三: 基线是 Fail的,加入新功能后回归 是Fail的。  绝大部分情况不用分析的。

  第四: 基线是 Pass的,加入新功能后回归 是Fail的。  肯定是bug,直接分析。

  有人肯定怀疑第二种情况,其实好的基线是不允许这个情况的,也是说好的继续其Pass率是很高的。我们主要关心的是第四种情况。一旦发现了,那产出显而易见了。

  这里大概讲下解决方案测试部的运作方式,之前在第一家公司的时候,确实有这个部门去做:有几个特点吧:直接面向客户;专注不同测试类型;与第三方公司合作;负责的用户环境;模拟真实线上环境。有点类似我们的预发布测试。这个team做的好的是当我们项目用到其他产品的接口时能发现很多相关的bug。

  上面说的是思科公司的做法,人家也许是好的,但我们更多的是了解别人为啥这么做,主要是要了解context,能不能适合我们呢?是不是能给我们带来一些新的思考角度呢?