当面临需求规格说明不全、模糊甚至没有需求的时候，要求测试人员确定测试什么，或者确定针对测试对象的测试思路是十分困难的。而基于缺陷分类的测试将可以较好的解决该问题。缺陷分类通常具有较好的结构化和系统化的特点。在讨论测试什么的过程中，可以有效的指导测试人员从哪些方面入手测试软件产品。
下面是一个具体的案例，通过询问2名测试人员（该2名测试人员在WEB测试方面有2年左右的工作经验）“网上购书系统的购物车”在哪些地方可能存在缺陷和问题，在没有缺陷分类和有缺陷分类的情况下，分别得到的缺陷分类列表（讨论的时间是15分钟）。
（1）进行没有缺陷分类指导的头脑风暴，得到的测试点：
■ 往购物车内添加条目失败，例如：增加某本书；
■ 移除购物车内的条目失败，例如：移除某本书；
■ 无法修改购物车条目相关的定单；
■ 购物车应用程序无法和一些浏览器兼容；
■ 购物车内选中的条目无法清楚的显示该物品的图片；
■ 从客户端可以修改购物车内物品的价格；
■ 由于安全问题，客户的信用卡信息可以明文显示；
■ 点击“确定”按钮，出现“PAGE NOT FOUND”错误；
（2）以缺陷分类作为指导进行头脑风暴，得到的测试点：
接下来，通过使用一个结构化的缺陷分类，观察同样的两名测试人员是如何发现更多的测试点的，从而说明缺陷分类是如何拓宽测试人员的测试思路的。此次讨论使用的缺陷分类包括：基本功能问题、易用性问题、计算问题、网络问题和WEB服务器问题。
尽管在这个实例中采用的缺陷分类并不多，但是以该缺陷分类为基础得到的测试点比纯粹的头脑风暴法得到的测试点要多的多，并且更加完善和有针对性。具体的测试点如下：
■ 功能性问题
● 往购物车内添加条目失败，例如：增加某本书；
● 移除购物车内的条目失败，例如：移除某本书；
● 无法修改购物车条目相关的定单；
● 从客户端可以修改购物车内物品的价格；
■ 易用性问题
● 用户不能直接从搜索的页面将物品放入购物车；
● 用户无法直观的得知当前购物车中物品的数量；
● 用户需要操作很多的步骤才能完成一个定单；
● 在往购物车内添加物品、删除物品以及更新物品的时候很不方便；
● 不能直观的得到当前物品的总的价格；
● 无法找到“帮助”菜单；
■ 计算问题
● 购物车内增加或者删除一个物品，物品总价并不能实时更新；
● 物品的折扣不能正确的计算；
● 物品的快递费用，不能反映购物车内物品数目不同的时候给予的减免；
■ 网络问题
● 无法连接到物品库存服务器；
● 无法连接到客户数据库服务器；
● 网络拥塞的时候导致服务器重启；
● 路由器失效；
● 物理链路失效；
■ WEB服务器问题
● WEB服务器超过最大的在线人数；
● 登录服务器需要花费很长时间，过于漫长的连接；
● WEB服务器连接超时；
● WEB服务器容量不足；
● WEB服务器资源耗尽，例如：CPU和内存等；
将基于测试人员头脑风暴法得到的测试点，和基于缺陷分类开展的头脑风暴法得到的测试点进行比较，就可以发现后者所具备的一些优点，主要表现在：
■ 在相同的时间和参与人员的情况下，基于缺陷分类的指导可以得到更多的测试点；
■ 通过结构化的缺陷分类作为工具支持，得到的测试点具有更好的测试范围和测试覆盖率，从而可以更好的建立对测试对象的信心；
■ 头脑风暴过程中，测试人员可以更好的将精力集中在缺陷分类罗列的类型上面，因此可以得到更加全面和详细的测试点；
■ 整个头脑风暴过程可以用更少的时间，获得更多的测试点，提高头脑风暴的效率。同时，对于测试团队而言，有缺陷分类指导的头脑风暴比常规的头脑风暴更加有趣和有效；