内部测试流程一些意见

新特性，特别是涉及到第三方部件时，测试总能有一堆接口问题，甚至漏到一线，

经常是流程不通，才会去关注接口，导致一些字段在与第三方部件交互的时候由于定义不一致才导致暴露出来，漏测就产生了，这影响也很大，关系到版本的交付时间。

但经常是测试时间不断被压缩，没能在测试时进行详细检查，再加上接口参数方面由单部件保障，然而每个单部件就按照自己的接口文档测试，当然没发现问题。

由于整套内部系统，存在十余个部件，修改起来还需要配合，相当麻烦，因此需要提前发现此问题。

这时候假若将时间点提前到联调拉通时，时间似乎也是相当紧张，毕竟每次拉通阶段都会延期，因此需要再次提前。

在版本未开发或者正在开发时，由测试人员进行静态测试，将各部件接口文档进行对比，看接口名扣重字段含义，进行逐一对比，保证一致性。

二、加强需求分析设计

在需求分析阶段加大投入，好的测试人员在需求分析阶段就能发现问题，这才是最难得最值得称赞的，鼓励在需求分析阶段发现方案性问题，但这却往往不能作为一项数据具体呈现出来，这就像华佗的三兄弟，却只有华佗最出名，如能统计给表扬，立标杆也许会带来一定激励。

三、方案互评

由于个人的局限性或者盲点，在进行方案设计时，会存在漏掉功能点的情况，时间充裕时，需要其他测试人员的帮助补充审查，这样更多的人熟悉其他特性。方案互评时，可以是组内，也可以是单部件测试人员。

四、方案评审

对于方案评审时是一个互动的过程，不仅仅是分析该方案的测试人员讲解，其他测试人员也需要提出自己的疑问，当然讲解设计方案的同学不仅仅关注到时候该怎么去测试，而是一个不断的反思过程，这样就足够了么,是否存在遗漏现像。最好能boss坐镇，防止其余人员纯走过场现象。

五、用例评审

用例一块，分析该功能的同学看自己写的当然没问题，当分给其他同事，假若描述过于简单，或者场景重复冗余，其他同学估计心情就不太顺了，这样的用例还关系到今后的验证，为了避免埋下隐患，因此对于用例一块最好也能加大评审力度，防止质量差冗余高的用例出现。