参加培训后，这个收获应该来说是大的，也给了我思考问题的不同的角度，先说下历史吧：还是从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，能不能适合我们呢？是不是能给我们带来一些新的思考角度呢？