我们经常会碰到这样的现象，同样的被测对象不同的人去测试发现的缺陷不尽相同？有的人会遗漏测试深度层面的缺陷，有的人会遗漏测试广度上的缺陷？
一.什么是测试的深度和广度？
如下图，如果把测试类比为捉虫。同样的被测对象/特性，如果你分析并执行的测试点越多，相当于你织的网越密，你的测试广度越大。但是有些虫子如果藏在草丛下（隐藏很深的缺陷），仅靠这张网的单一平面可能就无法捕获了。
回到具体测试中，假设你在测试某款通讯设备上IPSec特性，你可以从广度上考虑各种参数配置组合，考虑各种组网场景，从广度上对其进行覆盖。也可以从IPSec SA协商流程，从协议工作细节着手，在测试深度上下功夫，然后再各个击破。
二.关于深度或广度上的遗漏？
对于捕虫这件事情，网是不是要织得无线大，无限密，然后要掘地三尺才能把捕虫这件事情做OK?首先从测试的经济学上来讲，不可能将被测对象的所有测试点全部考虑并测试。另外每个测试人员的knowledge base（知识体系）是有差异的，对被测对象的认知也是有差异的。所以有遗漏在所难免。
那么应该怎么办？
1>尽可能缺点广度和深度上的边界：
还是需要秉承MFQ的一贯理念，多交流学习。多和BA，PO或者更靠近用户的人进行交流。在广度上更多的确定用户使用的场景和功能点；在深度上和DEV和BA上多确定实现细节（还是以通讯协议测试为例），被测对象依赖的协议我们到底是实现了协议的子集还是全集？哪些地方是和标准协议不一致的？哪些是我们在标准协议基础上扩展的？标准协议在我们产品架构上实现的方式等等……确定我们在深度上需要关注的内容。这样我们尽可能在广度和深度上确定好测试的边界。然后还需要通盘考虑交付时间点、人力、测试资源等因素，在广度和深度上都进行一些取舍。
2>灰色地带进行探索:
上面提到了要尽可能的确定广度和深度上的边界。但是往往需求提出者对于需求应用的场景也说不清楚，DEV对于特性实现的能力边界也讲不清楚怎么办？这样会产生大量的“灰色地带”。我觉得可以先集中精力根据对被测产品、行业的了解，对于被测对象/特性最核心的必须要满足的功能点进行验证，然后对于灰色地带进行探索性测试，探索一下产品它的能力到底如何，将疑问/问题通过测试报告的方式记录下来反馈给PO或项目经理，让他们来决策是否要解决疑问测试人员反馈风险的基本工作也就达到了。
3>团队协作和分工：
测试人员在输出TCO之后尽可能的组织一下评审，包括整个测试团队的其他测试人员，DEV和BA尽可能的减少遗漏，减少高风险测试点的遗漏。
有些深度上的测试Idea可能通过ST的方式测试的代价太大或不具备可测试性，可以通过协商通过UT/FT的方式完成。网织的面积大到一定程度之后，可能很多测试是属于功能交互测试，可以考虑和其他团队功能来完成（对于大型的软件项目，测试可能是分不同团队来完成的，分为前后端测试或者通过不同模块来划分测试团队）。