今天完成的事情：

今天写了一天的测试用例

明天计划的事情：

星期天
遇到的问题：

没有
收获：

场景分析法

测试分析是软件产品生命周期中，测试角色对软件进行的“系统设计”，主要目的是明确测试的覆盖范围和重点。

测试分析的输入一般是产品需求文档，有时候在类瀑布模型下，输入还可能包括系统设计文档；输入为对该产品（系统）的需要测试的点圈定和分析，包括安全性测试，压力测试的必要性等。

测试分析的主要方式包括边界值，等价类划分等方式，这些方法应用较多，不是本文讨论的重点，下面主要说下基于“场景分析”法进行的测分。场景分析法既可以是白盒的，又可以是黑盒的，后面具体举例说明。场景分析法一般可以采取如下步骤：

1.场景原子化

尽量细化场景，争取拆分后的场景不可再拆。这样的目的是保证产品的是全覆盖的。而且基于不同的场景有不同的侧重点，如展示层和数据交互层的测试重点差别就比较大。

2.场景正反向分析

针对单个测试场景做正向/反向或者说是正常/异常流程的场景设计。分析该场景的触发条件是什么，该场景被触发后的下一个场景是什么，如果本场景出现异常，应该进入到哪个场景。

3.场景串联

最后针对重要的场景，做一个串联，两个或者多个场景的串联构成一个功能链路（业务流），加上2中分析的场景，构成一个场景测试集。

具体举例，针对黑盒测试场景，举一个典型的Android app。

先描述下：默认进入主页面，主页面上左上角是返回键，右上角是设定键，下面操作栏分为三个子tab。

1）针对该场景分析，那么该场景的进入条件是点击了桌面上该APP的图标，触发场景运行；该场景上的展示包括6个大部分：

返回/设置/内容展示/下面的三个子tab，这些小的点又可细化为更小的场景。

2）该场景的入口只有一个，即触摸桌面上该app图标（如果是通过其他app唤起，也是一个待测场景。）。

该场景的出口有几个：A.按返回键，退出

B.点击设定，进入到选项页面

C.点击三个子TAB，进入到不同的页面

到此，场景的细化完成。

3）分析场景的异常流程：

进入场景失败，包括可能的原因，数据加载失败/与服务器通讯失败/鉴权失败/app完整性校验失败等。

进入场景正常，需要展示的内容文案等，包括是否支持多语言展示/字体大小颜色等

4）场景串联，包括从该场景进入到下一个场景的触发条件，本场景支持的操作等，分析具体的测试点。

然后根据业务需要进行安全性（数据库安全）/机型适配的测试分析。

针对白盒测试场景，在能够获取到被测产品的源码的情况下，可针对源码级别呈现出的场景，进行测试。

举一个简单的spring mvc系统的例子：

产品分为三层：展示层/业务层/数据持久层

1）对于展示层，大部分是基于网页语言编写，网页上的跳转/链接/展示/渲染需要对场景测试，可以用上个例子中基于黑盒测试的方式；

2）对于更底层的实现，如用户注册时，需要到数据库中先查询是否已经注册，如果已经注册，提示被占用；如果尚未注册，返回校验信息；

3）那么对于该场景的进入，是用户点击“注册”的请求被捕获并经由业务层发给数据持久化层。这个场景上，正常场景是在数据库中查询该用户名是否已经存在，异常场景包括数据库连接异常/数据库超时/数据读取为空/数据读取格式异常等场景；

正常场景就是正常从数据库中读取到注册信息；然后业务层返回处理后的数据给展示层。

4）场景的出口就是“已注册，请找回密码”或者“填写信息注册”。而每个进入子场景的条件中，又可以有3）中所述的异常场景。

5）最后串联成一个“用户注册”的功能点，从展示层到最底层分析出的场景以及对应的正常和异常流程，构成测试集。

场景分析法适用于业务流比较明显，功能清晰，分支较少的情况；如果分支较多或者场景过于复杂，使用等价类划分是个较为合适的方式。

其实场景分析法从本质上来理解，是基于“有限状态机”的分析方式的。