在日常需求的测试过程中，因为时间和资源的相对紧张，往往会遇到PRD不够细致，而UC描述也过于简单的情况，这个时候会让经验不够丰富的测试人员有种无从入手的感觉。其实由于思考方式、对需求的理解程度、开发和编写UC的经验、以及文字描述的习惯不同，开发人员首次提交的UC，并不一定能立即指导测试人员编写出一系列相对健壮的TC。
虽然说测试人员有权利退回需求不明的测试任务，但是在遇到“不得已而为之”的时候(比如紧急需求)，想办法解决问题，给出需求方建议总是好过什么都不做的退出测试。
因此需要在TC编写之前进行UC的评审，而UC的评审过程并不仅仅是一个需求再确认的过程，在评审之前测试人员就应该带着思考(类似于checklist)去尽可能的挖掘UC所覆盖到PRD的点以及所有自己的疑问，并且通过沟通尽早的解决疑问。
在这里，我个人想强调一下疑问，因为自己没有疑问并不代表真的没有问题，反而没有疑问才是最大的问题。谁都知道没有什么事物是绝对完美，包括开发人员编写的 UC，测试人员编写的TC，我们做测试不是要追求极致，但是至少要尽可能的降低因为遗漏问题而产生的风险，尽早的发现问题，解决问题。然而没有仔细的推敲和思考很难发现隐藏的问题，所以说没有疑问从某种程度上讲，是我们思考的还不够。举一个最为简单也是最为普遍的例子，我们一定都有过在编写TC过程中才发现有不确定的内容并向开发人员进行确认的经历，从某种角度讲，这就说明了UC的评审过程中，我们有遗漏。所以，只有充分的思考，才有可能捕获疑问，才有可能解决疑问，才有可能降低遗漏。
说完了疑问，在这里就不得不说一说思考，到底在UC评审之前我们应该思考些什么，或者说到底有哪些内容是我们需要去把握的，个人觉得可以从以下几点着手：
1. 如果说功能测试更多的是站在用户的角度进行测试，那么我们首先关注的必然是页面的展现。即页面的元素。一张好图胜似千言万语。这句话确实有其道理，所以界面原型图不仅能帮助开发人员省去很多文字上的描述，也避免了在测试过程中针对页面布局引起测试人员和开发人员争议，更能让测试人员建立一个整体的概念。因此，测试人员可以“提醒”开发人员提供demo截图，但是并不是每一份UC生成时都有充足的资源来获取demo。无论UC中是否有demo提供，我们真正应该关注的包括两点：一是页面包括哪些元素，是否覆盖了需求，有无冗余。再就是各元素的类型，比如列表、文本框，按钮等等。
2.在确定元素之后，就必须考虑元素对用户的开放性。即用户的访问、操作权限。一般而言，权限的控制往往有三种展现方式：一是通过页面元素的直接屏蔽使无权限的用户不可见，一是无操作权限用户使用时提示没有权限，还有就是对于没有权限的用户操作内容显示为不可用状态。测试人员必须确认UC中有该部分的描述，并确认具体属于哪种形式和其控制方式。否则在编写TC过程中就会出现遗漏，从而会导致bug的遗漏。
3.明确入口。由于web自身的特点，一个页面的访问往往会存在多个入口，每一个入口的前置条件都有可能不同，因此测试人员必须确认所有可到达的路径及其条件。
4. 在明确页面布局及元素、权限控制、入口后，我们就应该进一步了解一些具体的操作细节。例如结合demo图(如果有的话)，确定哪些是输入，哪些是输出。而在考虑这些输入和输出的时候我们不光要知道页面展现出来的输入、输出项，一些未展现出来的的输入、输出项，即隐藏的数据也是测试人员需要了解的。如注册用户，可能我们在页面上只需输入类似用户名、id之类的输入项，当成功后系统也只是提示操作成功，并返回注册