[自动化测试] 测试框架探索

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

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

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

Link URL: http://blog.csdn.net/bji129/archive/2009/12/01/4917235.aspx

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23025335/viewspace-624384/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23025335/viewspace-624384/