缺陷杂谈之一：如何理解深层次缺陷
记得有一次，测试刚开始，有一个同事很兴奋跑过来跟我说，对话如下：
他：“傻哥我发现一个很严重的缺陷”
我：“我说什么缺陷”
他：“当一张门诊处方输入200项的时候保存就报错”
我：“需求中门诊处方要求最大项目数是多少，你测试这个错误花了多少时间”
他：“60项，2个小时”
我：“你这个模块用例优先级是’高’都执行完了”
他：“只执行了五分之一”
我：“你见一张处方有200项的吗，还有五分四的测试用例这周能完成吗”（补充说明，当时已经周四下午）
……
我给大家举这个例子的意思是，我们不要为了找深层次的缺陷而去找深层次，我们找缺陷要根做事一事一样要有步骤，要有优先次序地进行。我们必须根据当时项目的情况或根测试用例的优先级高低来执行。
从单个缺陷来看这个缺陷严重非常高，但时从他现在项目和测试情况，这个缺陷优先级非常低
。如果如一个产品的基本功能不能确保的时候，像这样用户可能永远不会发生错误我们却花了大量的成本去发现，我觉得不值。
如果他告诉我“当一张门诊处方输入61项的时候保存，就报错”，那么我会觉得很有价值。
我为什么要说这个，因为我发现很多测试人员觉找一些“简单”缺陷，比如点击某按钮就报错，觉得很没有成就感，项目一开始就花很多时间去找所谓“深层次”的缺陷，而把一些简单缺陷给遗漏了。
我们必须扫清我们所谓简单缺陷以后再去找“深层次”的缺陷。碰到很多简单缺陷时候，我们要分析，要这些大家觉得“很简单”的缺陷以后不再发生，才是我们要做的事。如有些界面问题，可以把一些经常出现的界面问题做成界面规范，让设计人员在界面设计的时候就遵守，那么我测试的时候这些问题就少了。
