敏捷测试模板.doc

敏捷测试敏捷测试的实践摘要:在敏捷测试流程中,参与单元测试,关注持续迭代的新功能,针对这些新功能进行足够的验收测试,,测试人员尽早开始测试,包括及时对需求、开发设计的评审,更重要的是能够及时、:敏捷测试;敏捷开发;开发周期;单元测试1引言之前跟众人一样对敏捷开发比较熟悉,觉得新鲜而有效率。刚看到老师给的题目时才知道敏捷测试这个概念,自己一直局限于测试方法的学习,并没有系统并从大体框架去学习和了解测试这个行业。在学习敏捷测试过程中了解到这样几个概念:TDD(测试驱动开发TestDrivenDevelopment)、ATDD(eptanceTestDrivenDevelopment)、UTDD(单元驱动测试UnitTestDrivenDevelopment)以及精益方法,并由此开始了解到软件测试和其它知识领域的交叉处。敏捷测试进入国内研究领域还是一个新生力,查找到的国内文献也是极其有限的,在这里也只是发表自己浅陋的理解。通过之前的对软件项目案例的学习,我比较欣赏的是软件生命周期中的螺旋式模型,那敏捷是先于开发,也就跟传统的测试有本质的区别。传统的测试是先写测试计划,此后的测试过程分布在螺旋式模型中的每一次完善的循环中,而敏捷测试则是在开发前写好了用例,根据用例再去开发系统,能够减少很多错误,但这也就意味着开发人员的主导作用更明显。与传统的测试不同,敏捷软件测试并不是一个独立的过程,相反,它与整个敏捷开发中的其它活动交织在一起,处处都能看到它的影子。敏捷测试接纳了敏捷的核心价值观(沟通,简单,反馈,勇气,尊重),在敏捷软件开发过程中开展的测试就能够被称作是敏捷软件测试。因此,敏捷软件测试并不是一个与敏捷软件开发同一层次的划分,而是敏捷软件开发中的一部分。2敏捷测试背景敏捷测试是适应敏捷方法而采用的新的测试流程、方法和实践,对传统的测试流程有所剪裁,有不同的侧重,例如减少测试计划、测试用例设计等工作的比重,增加与产品设计人员、开发人员的交流和协作。在敏捷测试流程中,参与单元测试,关注持续迭代的新功能,针对这些新功能进行足够的验收测试,而对原有功能的回归测试则依赖于自动化测试。由于敏捷方法中迭代周期短,测试人员尽早开始测试,包括及时对需求、开发设计的评审,更重要的是能够及时、持续的对软件产品质量进行反馈。简单地说,敏捷测试就是持续地对软件质量问题进行及时地反馈,如图1所示。图1敏捷测试定义的形象描述首先要从整个项目全局考虑,及早发现需要更改设计的问题。其实这个测试更多的是观察与思考,而是否能发现问题就要看开发人员对需求掌握是否透彻,对整个项目是否有一个全局的把握,是否从最终用户角度去考虑问题,是否以实现客户的商业价值为目标。然后在最短时间内完成所有功能和业务逻辑的测试,最好是每人分配不同的功能和业务逻辑进行测试,这样就能够在最短时间内及时将优先级较高的缺陷及时反馈给开发人员。最后在开发人员忙于修改那些优先级较高,难度较大,比较耗时的缺陷的同时测试人员能够有充分的时间来对这一迭代进行较细致的测试,发现功能和业务逻辑中不易察觉的问题,次要功能问题、验证、界面等。那么,作为一个测试工程师在测试中使用敏捷的思想进行测试,并且需要敏捷测试中需要保证其工作符合相应的准则:①获取和明确用户的质量期望;②建立合适的系统测试、用户验收测试质量标准;③推进单元测试、开发测试;④建立持续构建框架;⑤持续改进自动化测试;⑥保持质量度量结果的可见性。在敏捷方法中,需求变化比较快、产品开发周期很短,我们当前采用四周时间,也就是每个月发布一个新版本。开发周期短,功能不断累加,给软件测试带来很大的挑战,软件测试流程要做相应的调整。例如,我们原有的测试规范明确规定,首先要建立项目的主测试计划书,然后再建立每个功能任务的测试计划书,测试计划书有严格的模板,而且需要和产品经理、开发人员讨论,并和测试团队其它人员(包括测试经理)讨论,最终得到大家的认可和签字才能通过,仅测试计划经过“起草、评审和签发”一个完整的周期就需要一个月。在敏捷方法中,不再要求写几十页的测试计划书,而是在每个迭代周期,写出一页纸的测试计划,将测试要点(包括策略、特定方法、重点范围等)列出来就能够了。在原有测试规范中,要求先用Excel写出测试用例,然后进行讨论、评审,评审通过以后再导入测试用例库(在线管理系统)中。在敏捷测试中,可能不需要测试用例,而是针对UseCase或UserStory直接进行验证,并进行探索性测试。而节约出来的时间,用于开发原有功能的自动化测试脚本,为回归测试服务。自动化测试脚本将代替测试用例,成为软件组织的财富。原有测试规范还要求进行两轮回归测试,在敏捷测试中,只能进行一轮回归测试。综合这些考虑,敏捷测试的流程简单有效,如图2所示。图2敏捷测试