QA评审底层测试的价值体现在这几个方面：

　　最重要的是利用QA的测试技能，可以发现Dev所写底层测试可能存在的问题，让测试更有效。

　　QA通过review底层测试，能够更好的了解测试覆盖情况，更清楚整体的测试状态。

　　QA看Dev写的测试，可以起到督促他们编写测试的作用。

　　但是，如果没做好，就会变成一种形式，Dev把测试给QA看一遍，QA就是稀里糊涂的过一遍，没有输入也没有反馈……这样的话，当然就没有价值了，而且还会浪费大家的时间。

　　虽然说的QA评审测试，其实是Dev和QA合作完成的事情，要想做好，对Dev和QA都有不同的要求。

　　首先，对Dev的要求：

　　自己要能清晰理解所有的测试，比如换人结对后，可能对原来同学写的测试没有搞清楚，当然没办法给QA讲清楚；

　　能清晰的介绍所写测试，包括对应的测试点、哪些点在单元测试覆盖、哪些在集成测试覆盖等；

　　要能系统的给QA去演示，不是直接打开IDE让QA自己去看，也不是东一个西一个想起哪个给演示哪个，把QA搞晕了。

　　据我的经历来看，不同经验的Dev演示的效果是截然不同的。

　　当然，对于经验特别丰富的QA来讲，对Dev的要求不一定有这么高，因为QA自己可以系统的去理解。

　　其次，从QA的角度，要想把测试搞清楚，有下面几个要求：

　　对测试分层等测试策略的理解，需要能够判断出哪些应该写单元测试、哪些写集成测试；

　　对于底层代码结构的理解，了解单元测试和API集成测试的实现形式，倒不一定要自己去实现，只是要做到能看懂能理解。

　　对于测试点的把握，比如对所验收用户故事的测试点要做到心中有数，能够清楚的知道需要有哪些测试来覆盖，帮助发现是否有遗漏的测试。

　　还有就是一些基本测试编写技巧的掌握，比如说测试命名、测试验证点是否正确、测试是否有冗余等。

　　如果QA对于技术实现不是很了解，可以加强与Dev的沟通，让Dev帮忙介绍更多的上下文以帮助更好的理解。因此，对主动性和沟通能力都有要求。

　　另外，既然是一个合作完成的事情，对于不太理想的评审过程，团队可以一起回顾一下，看看有哪些可以改进的地方。

　　相信QA评审测试是有价值的，团队一起来想办法找到适合的方式，让这个实践发挥应有的价值。

　　没有做好评审过程，怀疑存在的价值，一定是双方都有责任。

作者：by林子    

来源：http://www.51testing.com/html/22/n-4473922.html