2011年已经过去了,一直在想去年我的测试水平到底有没有提升,主要在哪些方面,而哪些方面提升不多,哪些事情做得不到位,这些都是需要思考的。
其实自己个人感觉做得比较多,但是很多事情也没用升华下去,接下来就说说自己做的几块大的事情吧,也说下自己的思考。
预计会写如下几篇(争取一天一篇):
2011回顾之接口性能测试
2011回顾之持续集成初步实践
2011回顾之持续测试设计最优化
2011回顾之探索式测试实践
2011回顾之公共组件的抽象
2011回顾之前端测试
持续测试设计最优化
测试设计在项目测试过程中是个重要的一环,个人认为测试设计的质量很大程度上决定着项目测试的质量和效率。测试设计这个话题非常的大,本来不想说些基础的知识,但是考虑到我个人的一些想法和做法,还是决定说的清楚点较好。
测试设计的定义:
输入:测试计划;需求规格说明书;UC;详细设计。
输出:测试设计。
行动:对于评审后的需求使用各种测试设计方法进行更进一步的用例设计。
原则: 通常应该避免依赖先前测试用例的输出。
为什么要做测试设计:
1.对前面评审后的需求进行进一步的评审。
2.对于大的需求做一些分解和加深理解。
3.产出所有具体需求的所有测试思路和异常分支。
4.对后续的用例编写根本性的指导。
5.对整个被测系统进行测试模型的建立。
6.为了对被测接口进行接口功能的评审和检查(接口)。
测试设计的关键目的就是为了让测试更丰富
测试设计的产出形式:
测试设计的产出不是一份文档
内容:
1.功能需求分解MM图:Free Mind; Xmind
2.系统交互图:Rose
3.数据流程图:Rose
4.分析完成的用例思路集合
5.接口设计的具体测试用例(接口)
我这边提出的测试设计,就是本产品测试所需要的所有测试思路的集合,按照类型和功能的结合来进行分类,让其他测试人员都能快速了解测试覆盖率和需求覆盖率。同样的是,我个人认为测试设计分两种:一种是项目的测试设计,该测试设计文档的生命周期是是随着需求评审的开始到项目监控期的结束。另一种是产品的测试设计,只要该产品还存在于线上,该产品的测试设计文档无论在何时必须处于最新状态,最完整状态,最正确状态。
可能受到探索式测试的一些影响,我负责的产品的测试的测试设计都是必须要达到这三个状态,所以我对测试用例的编写非常不感冒,这些都要求和train我在做测试设计的时候的高规格。对测试思路和关键字的把控一定要到位,同时对分类和组合有一定经验。关于测试设计的案例,我的很多blog都贴着图了,这里就不再重复了。
很多人对于我这个想法都会提出异议,认为我的产品的测试用例写的不行,确实,我的cover点不是非常详细的tc,而是丰富且全面的测试思路集合,也就是我必须要维护的测试设计。很多team的测试人员都做不到这一点,把精力分散出去,靠很多零星的记录点来维持,缺乏系统性和持久性。
为啥说我的测试设计是最优化,那就是该产品的任何一个需求的开始和结束,不管是大的项目需求,还是小的日常需求,我都在我的产品测试里面增、删、该。保持最新业务状态,反馈最新业务发展,给开发和需求人员的指导和提醒,帮助开发做自测等等都启动一定的好处。
另外还需要说到的是,如何将我们的测试设计的覆盖达到最高呢,如何来最优化它呢,我这边提出了一些基本的测试设计流程,那就是基于测试模型的测试设计。
测试模型:在一定的测试范围内建立一个模型图,以便让测试人员快速地了解和掌握该测试范围内的关键测试点,将这些关键测试点在一定测试范围内进行简单的建模,从而得到测试模型。
下面是详细的说明:
测试设计:通过三个阶段得到的设计文档,第一个是在PRD(需求规格说明书)评审阶段,使用基于需求的测试方法编写的测试设计思维图(功能点划分,P1级、P2级的用例场景);第二个是在User Case评审阶段,使用基于需求的测试方法评审User Case并完善测试设计思维图(补充P1 级、 P2级的用例场景,P3级、P4级的用例场景);第三个是在系统设计评审阶段,通过评审接口说明文档,详细设计文档,数据库设计文档(补充每个功能点容易遗漏的异常场景和详细校验点)。
测试设计一 :应用功能测试模型阶段,通过熟悉功能测试模型和分析系统的功能需求,补充公共功能容易遗漏的异常场景和详细校验点。
测试设计二 :应用线下故障测试模型阶段,通过熟悉线下故障测试模型和分析系统的功能需求类型,补充复杂特殊功能容易遗漏的异常场景和详细校验点。
测试设计三 :应用线上故障测试模型阶段,通过熟悉线上故障测试模型和分析系统的功能需求类型,补充特殊环境下容易遗漏的异常场景和详细校验点。
使用基于测试模型的测试设计,可以得到完整和覆盖率较高的测试设计思路,从而保证测试的质量和减少线上故障。