适用范围

　　测试活动大概可分为两部分：发现产品的缺陷，验证产品无缺陷，两者缺一不可。探索测试可用于缺陷尽快、尽早的暴露，给我们大概勾画出缺陷分布图，但不能保证产品无瑕疵。故此法必须配合老老实实的规格验收活动，探索测试可作为敏捷开发的一个小活动，产品质量由下自上改进一个添花项。

　　技术积累

　　缺陷分布的宏观分析：各个版本按照一定的模板收集缺陷类型（ST阶段数据为佳）；结合逆向分析、网上问题分析，给出我们产品的薄弱点。

　　具体版本关键路径分析：结合版本设计要素，管理好关键风险；建设好规格的验收活动，必须是自动化的，最好是可重用的；UT、IT、ST用例是完整的，SDV验收活动是可靠的。

　　功能模块的解耦合，软件硬件解耦合便于各个子领域的质量控制；集成风险的分析，有效的控制产品的质量。

　　活动开展模式

　　规格分解阶段，分析规格（此规格是TSEG与SEG共同确认的），建设规格验收的活动。编码阶段，测试人员白天分析代码，编写测试用例，晚上自动化验证。两组人马可以相同，两项活动必须开展，相辅相成。

　　现在资源分析

　　接入产品线的老特性的自动化验收用例是比较完整的，但缺乏具体的覆盖统计。骨干员工基本上接触过脚本语言，但不太熟练，若新特性的研发的自动化规格验证脚本，探索测试发现的用例自动化实现，能否及时交付，可能存在一定的难度。组内做软件的人员基本上没有开发经验，软硬系统架构能力缺乏，能否有效的分析出关键风险，有效的控制好软件硬件解耦以及系统集成，存在很大的问题。

　　接入产品现有的体现结构还相对简单，就目前的人力来看，若能有效结合软硬各自领域的知识，TSEG可以支撑白盒测试的开展。

　　团队测试文化建设

　　落实测试基本理念：发现产品的缺陷，验证产品无缺陷，两者缺一不可。测试人员对负责的特性负责，而不是仅仅是交付件。

　　推进计划

　　第一步，能力准备与数据准备。代码分析能力提升与自动化测试用例设计能力提升：可以从维护版本开始，在缺陷修改阶段，研发测试共同讨论修改方案；测试提供验证用例，必须是自动化的，这样白天设计用例，晚上自动化验证。从转测试后的版本质量评估此项活动是否有效。衡量目标，维护版本只需一个质量验收版本即可发布；缺陷分布因子确定，需要从各个版本中统计出缺陷的分布情况与遗留到网上去的缺陷分布情况。

　　第二步，在新版本上试点，规格分解后，QX接口确定后，同步开发规格自动化验收用例。开发阶段分层覆盖QX接口，新增函数路径覆盖，软硬接口文档。若版本的ST测试质量能达到如上的覆盖要求，而SDV阶段规格自动化验收集合是完备的（是指精确的知道自动化覆盖多少规格以及场景，手工用例覆盖了多少规格以及场景）。则在SDV阶段可以采用探索测试的方法，激发员工的能动性。

　　第三步，在ST阶段采用探索测试方法，快速的找到产品的短木板（关键）。具体实现还没有想清楚，请给位指点迷津。

　　前景展望

　　测试的劣势在重复性的工作太多，同时这也是我们的优势，只要我们能找到重复到重用的道路。今后我们有理由相信，测试的工作是可以达到24*7的，我们只要做好8*5的设计工作，其余的就交给工具来帮我们完成。