标签：
百度了一下“测试框架”，搜索结果大部分都是“自动化测试框架”、“单元测试框架”，没有手工测试框架。但是所谓框架不就是把“共性部分形成的体系”提高效率和质量吗？
做测试3年，现在想的更多的是如何提高测试效率和保证测试用例的覆盖率。目前所在的是公司是互联网公司（之前一直在传统软件公司工作），节奏很快，测试周期很短。产品需求文档的完善程度也是参差不齐，然后测试时间又比较紧急，除了个别庞大的项目外，领导不会专门预留编写测试用例的时间。
事件一，2015/12/8，领导安排我和另外一个同事测试一个新增节点，产品没给需求文档，仅在邮件中寥寥的提了一下需要测试的内容，看上去特别简单。领导说本来是打算给 1人*1天 的工时去完成，但是因为这周项目不多，时间、人手都比较充裕，最后给我们的时间是2人*2天 的 工时，然后我和同事一看确实挺简单，估计半天就能搞定（窃喜），然后简单的列了一下testlist就开始搞，然后一直搞到第二天上线才勉强搞完。这是咋回事呢，因为虽然只是增加了一个节点，但是其中有好多隐藏点（涉及到具体业务，我就不举例了），而我们在测试之前并不知道，所以越测越发现需要测试的内容越多，BUG也越多。
事件二，2015/12/8，在产品的上线前1小时被拉入另一个测试组（当时我还在做“事件一”的项目），进行分角色测试（我扮演其中一个角色，帮他们跑下流程，看上去很简单），但也是因为不了解情况，导致最后我这个点耽误整个团队大约1个小时的时间。
以上为背景，因为这两件事在同一天发生，我都没有完成的非常好，非常自责，就想该怎么解决这个问题呢。公司是做金融产品的，产品线主要就是信用贷、抵押贷、赎楼贷、装修贷等，细算的话有10多条，每一条都是大同小异。目前更多的是在做产品线优化，当然公司拓展业务也会增加一些新的产品线。目前公司每次新增产品线或者新添加一个节点，测试人员的工作量还是非常大，但是测试周期又非常短，经常搞的手忙脚乱。
其实很多测试用例都是具有一般性的，具有很强的可复用性；像这种具有一般性的功能测试，比如新增节点、分角色测试甚至是新增一条产品线测试，如果能直接找到一份具有一般性的文档，进行参考，该是多nice啊。大概的测试点有哪些？需要注意什么？都在这个文档里，即使有一些差异，也能提供一个很好的思路和框架；然后在加几条新增功能所独有的测试用例，这样就能很好的完成测试覆盖；每次测试新的功能时拿出相关的文档花10多分钟看下就知道该怎么搞了，遗漏会少很多，也能减少测试用例的设计时间，因为大部分用例都在这个文档里面了。
再然后呢，如果把整个产品线的测试都形成相关的文档，下次在测试新增的产品线时，也会有很强的借鉴意义，毕竟我们公司的产品线差异都不是很大。这样产品线测试就包含了节点测试、分角色测试等等，节点测试又包含页面功能测试等，是不是一个简单的手工测试框架就形成了呢？没次测试任务完成后都对相关文档进行修改补充，相信到最后这会成为一张王牌！
每次测试新增功能的时候，花几分钟看下相关的测试案例，基本上就明白该怎么搞了，需要注意什么也都一目了然，适当增加一些具有特殊性的测试用例即可；心理有谱了，测试的时候用一条测试数据就能覆盖好多测试用例，大大提高测试速度。即使经验很丰富光靠脑子想也不靠谱的，总有遗漏的，更何况是其他不熟悉相关业务的测试人员、或者测试新人呢，形成一个框架后任何人都可以用。
现在开始搞，试试好不好用，好用就在部门推广下！
标签：
原文地址：http://www.cnblogs.com/zhangml/p/5038722.html
