如何应对不明需求做好测试

在日常需求的测试过程中，因为时间和资源的相对紧张，往往会遇到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之类的输入项，当成功后系统也只是提示操作成功，并返回注册的用户信息页面，而实际上，在注册成功的同时，数据库里不仅仅只是添加了用户所输入的信息，用户ID，用户创建的时间等信息都是系统自动生成但又不展现给用户的，尽管用户并不关心此类数据，但是测试人员必须了解并且跟踪这些数据。确保数据的正确创建。因为当错误的数据被调用时，就会引发一系列未知的问题。所以测试人员必须关心数据。

　　5.对于输入项，还应明确有无初始值、默认值设置。如果有，就应该考虑是不是需要与“重置”操作配合。此外，输入项有无输入控制，如果有，还应该确认对应的异常处理机制，包括提示信息的文案说明。

　　6.对于输出项(返回项)，首先要明确具体有哪些输出，其次需要明确是返回当前页面的操作，还是新窗口。若为前者，就需要考虑输出后是否影响输出前的操作; 若为后者，还需考虑是否能从该页面返回原窗口等等。

　　7.除了关注页面展现，测试人员还应该明确需求实现中涉及的所有表结构，包括表之间的关系。通过表关系，可进一步考虑本次需求可能会影响到的其它需求。并通过比对页面元素，了解页面展现和具体表结构的对应关系，从而确定是否有遗漏和冗余。

　　当然，以上这几点可能还很不完整，仅仅是我在近期的日常需求测试过程中的一点感悟，还需要我在实践的过程中去补充和修正，当然也欢迎大家一起来修正。

　　其实，个人认为带着思考去评审UC或者是编写tc，绝对不止是确认需求和描述自己的操作步骤，通过在跟开发人员的沟通过程中，引导他们一起去思考和去检验自己的代码，其实也是在测试，这样的行为可以说大大的提高了测试的效率，因为很多问题在测试人员开始执行测试之前都已被开发人员所修正，如此一来，在执行测试的时间里，测试人员就可以更好地聚焦于业务逻辑层的实现，使得测试更为充分。从某种角度讲这也是缺陷的预防。当然，缺陷预防的路还有很长，但是我们不用害怕和沮丧，一点点做起来，一步一个脚印的走下去，目标总会近，如果我们每个人再加把劲，多多分享和共享，那么我相信，我们的团队会走的更快、更好。

原文转自：http://www.ltesting.net