6.对于输出项(返回项)，首先要明确具体有哪些输出，其次需要明确是返回当前页面的操作，还是新窗口。若为前者，需要考虑输出后是否影响输出前的操作;若为后者，还需考虑是否能从该页面返回原窗口等等。
　　7.除了关注页面展现，测试人员还应该明确需求实现中涉及的所有表结构，包括表之间的关系。通过表关系，可进一步考虑本次需求可能会影响到的其它需求。并通过比对页面元素，了解页面展现和具体表结构的对应关系，从而确定是否有遗漏和冗余。
　　当然，以上这几点可能还很不完整，仅仅是我在近期的日常需求测试过程中的一点感悟，还需要我在实践的过程中去补充和修正，当然也欢迎大家一起来修正。
　　其实，个人认为带着思考去评审UC或者是编写tc，不止是确认需求和描述自己的操作步骤，通过在跟开发人员的沟通过程中，引导他们一起去思考和去检验自己的代码，其实也是在测试，这样的行为可以说大大的提高了测试的效率，因为很多问题在测试人员开始执行测试之前都已被开发人员所修正，如此一来，在执行测试的时间里，测试人员可以更好地聚焦于业务逻辑层的实现，使得测试更为充分。从某种角度讲这也是缺陷的预防。当然，缺陷预防的路还有很长，但是我们不用害怕和沮丧，一点点做起来，一步一个脚印的走下去，目标总会近，如果我们每个人再加把劲，多多分享和共享，那么我相信，我们的团队会走的更快、更好。