【摘抄记录】我们做测试不是要追求极致，但是至少要尽可能的降低因为遗漏问题而产生的风险，尽早的发现问题，解决问题。

测试用例（UC）评审之前我们应该思考些什么?

或者说需求不明,我们应该怎么做?

比如我的项目中只有低保真和高保真,没有明确需求

1.UI检查

高保真、低保真图

页面元素覆盖哪些需求，是否冗余

页面元素类型，比如列表、文本框，按钮等等

解析：

即页面的元素。一张好图胜似千言万语。这句话确实有其道理，所以界面原型图不仅能帮助开发人员省去很多文字上的描述，也避免了在测试过程中针对页面布局引起测试人员和开发人员争议，更能让测试人员建立一个整体的概念。因此，测试人员可以“提醒”开发人员提供demo截图，但是并不是每一份UC生成时都有充足的资源来获取demo。无论 UC中是否有demo提供，我们真正应该关注的包括两点：一是页面包括哪些元素，是否覆盖了需求，有无冗余。再就是各元素的类型，比如列表、文本框，按钮等等。

2.在确定元素之后，就必须考虑元素对用户的开放性

确认权限展现属于哪种形式和其控制方式：

方式：

1）通过页面元素的直接屏蔽使无权限的用户不可见

2）无操作权限用户使用时提示没有权限

3）没有权限的用户操作内容显示为不可用状态（置灰）

解析：

即用户的访问、操作权限。一般而言，权限的控制往往有三种展现方式：一是通过页面元素的直接屏蔽使无权限的用户不可见，一是无操作权限用户使用时提示没有权限，还有就是对于没有权限的用户操作内容显示为不可用状态。测试人员必须确认UC中有该部分的描述，并确认具体属于哪种形式和其控制方式。否则在编写TC过程中就会出现遗漏，从而会导致bug的遗漏。

3.明确各功能点所有入口

确认所有可到达的路径及其条件

解析：

由于web自身的特点，一个页面的访问往往会存在多个入口，每一个入口的前置条件都有可能不同，因此测试人员必须确认所有可到达的路径及其条件。

手机App同样适用

4.在明确页面布局及元素、权限控制、入口后，应该进一步了解一些具体的操作细节。

解析：

例如结合demo图(如果有的话)，确定哪些是输入，哪些是输出。而在考虑这些输入和输出的时候我们不光要知道页面展现出来的输入、输出项，一些未展现出来的的输入、输出项，即隐藏的数据也是测试人员需要了解的。如注册用户，可能我们在页面上只需输入类似用户名、id之类的输入项，当成功后系统也只是提示操作成功，并返回注册的用户信息页面，而实际上，在注册成功的同时，数据库里不仅仅只是添加了用户所输入的信息，用户ID，用户创建的时间等信息都是系统自动生成但又不展现给用户的，尽管用户并不关心此类数据，但是测试人员必须了解并且跟踪这些数据。确保数据的正确创建。因为当错误的数据被调用时，就会引发一系列未知的问题。所以测试人员必须关心数据。

---------------

外包项目一般没有这些细节数据

--------------

5.对于输入项，还应明确有无初始值、默认值设置。如果有，就应该考虑是不是需要与“重置”操作配合。

输入项有无输入控制（浅色字体提示、字符限制、长度限制、错误提示）

初始页面，如通话记录为空

6.对于输出项(返回项)，首先要明确具体有哪些输出，其次需要明确是返回当前页面的操作，还是新窗口。

若为前者，就需要考虑输出后是否影响输出前的操作;

若为后者，还需考虑是否能从该页面返回原窗口等等。

7.除了关注页面展现，测试人员还应该明确需求实现中涉及的所有表结构，包括表之间的关系。

通过表关系，可进一步考虑本次需求可能会影响到的其它需求。并通过比对页面元素，了解页面展现和具体表结构的对应关系，从而确定是否有遗漏和冗余。

--------------------------------------------------------------

注意查看数据库，不过这一般是测试过程中，操作结束后，查看数据库对应数据减少或增加数量是否正确，比如抽奖活动中，奖品剩余数量对应是否正确

--------------------------------------------------------------

需求不明的测试