刚踏入测试领域的时候，一些有经验的人告诉我，案例写的太有层次了，所谓的层次就是把用例都拆分成步骤，这样的结果就是每步一个验证的验证结果，这样的话看起来好理解，用他们的话来说我的case不用学测试的人都会写，而且没什么意思，后来接触到按什么流程，按等价类划分，写的case看起来反正自己觉得就有点乱了。

　　一年前，接触一位测试同行，他们的视角很简单，既然测试不是最精通业务的（有业务需求分析人员），那除了更多的放精力在逻辑验证上面，只能依据需求文档和开发设计文档编写用例，当然他们叫做设计场景，然后写各种可能出现的小case，用他们leader的说法，我们的case覆盖率就是100%，所谓100%，那就是每个需求点概要设计点都会有测试case或者场景对应，他们做好之后也会有个映射文档，保证准确性，更为诡异的就是他们，如果有东西开发做不了，测试测试不了的，会在测试的过程中返工从需求或者测试计划中移除该需求点，所以怎么都能保证测试的覆盖率在100%。

　　讲这么多，其实也就是这边自动化测试框架的依据，步骤和叠加，因为接触到的都是web应用所以就拿web brower做对象吧。

　　1. web应用最常看到的就是页面跳转实现业务逻辑，那我们的步骤基元，不妨就定做为页面，这样看起来的，我们的case的结构就是：

　　page[1]->page[2]->page[3]........->page[n]

　　2. 测试步骤有了，那么接下来就是测试期望结果了，那我们的期望结果应该是什么呢？

　　很多人都知道，期望结果一般是在最后一步中验证的，那如果我们的业务足够小，譬如

　　case1： page[1]->page[2]，简单的页面跳转，那也就是说我们的期望结果是看到page loading 完成。

　　这样看来 page[1]的期望结果是page[2],page[2]的期望结果是page[3],以此类推，不难发现其中的奥秘。

　　3. 相信很多人都会忘记测试前提，这里主要涉及数据，如果没有必要的数据准备我们如何做验证性功能测试。

　　就好像刀都没有，如何砍柴？

　　4. 测试用例结果采集：

　　相信很多都有自己的case的组织习惯，而我喜欢用testlink中那种树形的组织目录。

　　project->suite->case，为了简单可以姑且分成三层，当然也可以扩展。

　　所以测试用例执行的单位也分成项目，类别，案例。