当面临需求规格说明不全、模糊甚至没有需求的时候，要求测试人员确定测试什么，或者确定针对测试对象的测试思路是十分困难的。而基于缺陷分类的测试将可以较好的解决该问题。缺陷分类通常具有较好的结构化和系统化的特点。在讨论测试什么的过程中，可以有效的指导测试人员从哪些方面入手测试软件产品。

　　下面是一个具体的案例，通过询问2名测试人员（该2名测试人员在WEB测试方面有2年左右的工作经验）“网上购书系统的购物车”在哪些地方可能存在缺陷和问题，在没有缺陷分类和有缺陷分类的情况下，分别得到的缺陷分类列表（讨论的时间是15分钟）。

　　（1）进行没有缺陷分类指导的头脑风暴，得到的测试点：

　　■ 往购物车内添加条目失败，例如：增加某本书；

　　■ 移除购物车内的条目失败，例如：移除某本书；

　　■ 无法修改购物车条目相关的定单；

　　■ 购物车应用程序无法和一些浏览器兼容；

　　■ 购物车内选中的条目无法清楚的显示该物品的图片；

　　■ 从客户端可以修改购物车内物品的价格；

　　■ 由于安全问题，客户的信用卡信息可以明文显示；

　　■ 点击“确定”按钮，出现“PAGE NOT FOUND”错误；

　　（2）以缺陷分类作为指导进行头脑风暴，得到的测试点：

　　接下来，通过使用一个结构化的缺陷分类，观察同样的两名测试人员是如何发现更多的测试点的，从而说明缺陷分类是如何拓宽测试人员的测试思路的。此次讨论使用的缺陷分类包括：基本功能问题、易用性问题、计算问题、网络问题和WEB服务器问题。

　　尽管在这个实例中采用的缺陷分类并不多，但是以该缺陷分类为基础得到的测试点比纯粹的头脑风暴法得到的测试点要多的多，并且更加完善和有针对性。具体的测试点如下：

　　■ 功能性问题

　　　　● 往购物车内添加条目失败，例如：增加某本书；

　　　　● 移除购物车内的条目失败，例如：移除某本书；

　　　　● 无法修改购物车条目相关的定单；

　　　　● 从客户端可以修改购物车内物品的价格；

　　■ 易用性问题

　　　　● 用户不能直接从搜索的页面将物品放入购物车；

　　　　● 用户无法直观的得知当前购物车中物品的数量；

　　　　● 用户需要操作很多的步骤才能完成一个定单；

　　　　● 在往购物车内添加物品、删除物品以及更新物品的时候很不方便；

　　　　● 不能直观的得到当前物品的总的价格；

　　　　● 无法找到“帮助”菜单；