敏捷测试流程.pptx

敏捷测试
我们将要讨论以下几个问题:
1. 什么是敏捷测试?
2. 敏捷测试有哪些流程改进?
3. 敏捷测试策略
4. 测试人员在敏捷方法中的价值
5. 如何合理把敏捷测试应用于我们的项目?
第1页/共13页
什么是敏捷测试
敏捷测试应该是适应敏捷方法而采用的新的测试流程、方法和实践,对传统的测试流程有所剪裁,有不同的侧重,例如减少测试计划、测试用例设计等工作的比重,增加与产品设计人员、开发人员的交流和协作。在敏捷测试流程中,参与单元测试,关注持续迭代的新功能,针对这些新功能进行足够的验收测试,简单地说,敏捷测试就是持续地对软件质量问题进行及时地反馈
第2页/共13页
敏捷测试流程图
第3页/共13页
敏捷流程
在敏捷方法中,需求变化比较快、产品开发周期很短。开发周期短,功能不断累加,给软件测试带来很大的挑战,软件测试流程要做相应的调整。
对于传统测试流程:
1. 我们原有的测试规范明确规定,首先要建立项目的主测试计划书;
2. 然后再建立每个功能任务的测试计划书,测试计划书有严格的模板;
3. 需要和产品经理、开发人员讨论,并和测试团队其他人员(包括测试经理)讨论,最终得到大家的认可和签字才能通过
4. 仅测试计划经过“起草、评审和签发”一个完整的周期就需要一个月。
而在敏捷方法中,不再要求写几十页的测试计划书,而是在每个迭代周期,写出一页纸的测试计划,将测试要点(包括策略、特定方法、重点范围等)列出来就可以了。
第4页/共13页
敏捷流程
在传统测试规范中,要求先用Excel写出测试用例,然后进行讨论、评审,评审通过以后再导入测试用例库(在线管理系统)中。在敏捷测试中,可能不需要测试用例,而是针对Use Case或User Story直接进行验证,并进行探索性测试。而节约出来的时间,用于开发已有功能的自动化测试脚本,为回归测试服务。传统测试规范还要求进行两轮回归测试,在敏捷测试中,只需要进行一轮回归测试。
第5页/共13页
敏捷流程
在敏捷测试流程中,测试是一个持续的质量反馈过程,测试中发现的问题要及时反馈给产品经理和开发人员,而且某些关键方面也要得到我们足够的关注,主要有:
测试人员不仅要全程参与需求、产品功能设计等讨论,而且要面对面地、充分地讨论(包括带语言、视频的即时通讯),仅仅通过邮件是不够的。
参与代码复审(Code Review),并适当辅助开发人员进行单元测试。
在流程中增加一个环节“产品走查(Product Walk-through)”——测试人员和产品经理、开发人员等在一起,从头到尾将新功能看一遍,可直观、快速地发现问题。
第6页/共13页
敏捷测试策略
不需要特别细节的测试用例,测试用例只要保证各个功能点被覆盖,不要过于详细(大颗粒度)。
持续地进行验证,一旦某块新代码完成(Code Drop),就开始验证,而不是等到所有代码完成后才开始测试。这也包括参与到单元测试和集成测试中。
实施端到端(End-to-End)的测试,确保完整的业务流程的实现,同时,也容易发现业务逻辑不够清晰、不够合理等各方面的问题。
阅读代码来发现问题,可以和开发人员工作保持同步,消除测试周期的压力。
基于经验,可以实施更多的探索性测试、组合交互性(Interoperation)测试和用户场景(User Scenario)测试,更有效地发现埋藏较深的缺陷。
第7页/共13页
测试人员在敏捷方法中的价值
1. 在需求和功能设计讨论上,测试人员可以站在客户角度来阐述自己的观点,扮演“用户代表”角色,强调用户体验,真正体现测试人员和开发人员的互补作用。
2. 测试人员不仅扮演“用户代表”角色,而且通过需求讨论、代码复审等各种活动及时地提供质量反馈,包括代码质量、接口一致性等,保证在产品构造的整个过程中质量受到足够的关注,以提高质量改进的持续性和可视性。
3. 测试人员应积极参与单元测试,即使不参加单元测试,也应督促开发人员进行单元测试,确保单元测试达到80% 以上覆盖率,确保开发出具有良好可测试性的代码。
4. 在敏捷方法中,往往将一个大的系统开发分解成多个小的子系统(模块或组件),集成测试和端到端(End-to-End)测试显得更为重要,测试人员在这些测试上能发挥更大的作用。
5. 产品发布前,验收测试和回归测试依然不可缺少,这更是测试人员的用武之地。
6. 一个迭代周期结束后,对缺陷根本原因进行分析、总结规律,帮助开发人员建立良好的习惯,预防缺陷,从根本上提高产品质量。
第8页/共13页
如何合理使用敏捷测试方法
思奇互动项目,是典型的符合敏捷测试的项目,我认为因为以下几点:
1. 项目周期比较短;
2. 我们开发的东西有前瞻性,试探性,不允许冗余的流程;
3. 我们是做自己的产品,要