【IT168 评论】刚踏入测试领域的时候，一些有经验的人告诉我，案例写的太有层次了，所谓的层次就是把用例都拆分成步骤，这样的结果就是每步一个验证的验证结果，这样的话看起来好理解，用他们的话来说我的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，为了简单可以姑且分成三层，当然也可以扩展。

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

　　5. 调用关系和主要函数

　　1)浏览器对象：ie.new

　　2)事件激发对象：click.new

　　3)登陆系统：login

　　4)执行project/suite/case

　　● project/suite/case

　　三者的关系用两层数组可以搞定，一般来说项目只会有一个，case的执行可以逆向搜索获得suite名

　　最后调用的即是logstartsuite->excute('case')->logcase->logendsuite;

　　log的作用主要是记录执行结果写入到html文件，一般来说是根据日期时间信息创建目录结构，

　　在目录中组织html文件，可以自由发挥。

　　● case/pages

　　刚在以上的思想已经提到，case是有页面的基元构造而成的，所以可以使用页面对象调用相应的方法就可以获得想要的东西。

　　譬如：搜索中国客户并且验证，就可以按照以下办法执行

　　$ChineseCustomer = $search_customer_page->getChineseCustomer($custID);

　　$customer_detail_page->getCustomerID() eq $custID ? return "Pass" : return "Fail";

　　● page对象

　　页面对象控制的有：元素，逻辑，小页面(弹出层等)。

　　譬如以上的getChineseCustomer方法就调用了很多search页面的元素进行排列组合而形成的。

　　● excute的对象传承

　　excute(project/suite/case)->excute(testcase[1])->更小的case执行集合->page 方法组合->更小页面组合。

　　5)登出系统：logout

　　可能是因为树形目录结构的可扩展性，在实践的过程中，不断发现，把下一级的结构细化就可以然后任意的组合返回给上一级都能更好的实现扩展。