在敏捷测试流程中,如前所述,测试是一个持续的质量反馈过程,测试中发现的问题及时反馈给产品经理和开发人员,而且某些关键方面也要得到我们足够的关注,主要有:
● 测试人员不仅要全程参与需求、产品功能设计等讨论,而且要面对面地、充分地讨论(包括带语言、视频的即时通讯),仅仅通过邮件是不够的。
● 参与代码复审(code review),并适当辅助开发人员进行单元测试。
● 在流程中增加一个环节“产品走查(Product work-through)”——测试人员和产品经理、开发人员等在一起,从头到尾将新功能看一遍,可直观、快速地发现问题。
3、新功能的测试和回归测试策略
测试任务简单地可分为新功能测试和回归测试。在敏捷方法中,针对这两部分的测试建立相应的策略,以提高测试的效率,最大限度地降低质量风险。新功能测试的策略主要有:
● 不需要测试用例,直接基于用例、基于对需求的理解来完成新功能的验证。即使要写测试用例,只要保证各个功能点被覆盖,不要过于详细(大颗粒度)。
● 持续地进行验证,一旦某块新代码完成(code drop), 就开始验证,而不是等到所有代码完成后才开始测试。这也包括参与到单元测试和集成测试中。
● 实施端到端(end-to-end)的测试,确保完整的业务流程的实现,同时,也容易发现业务逻辑不够清晰、不够合理等各方面的问题。
● 阅读代码来发现问题,可以和开发人员工作保持同步,消除测试周期的压力。
● 基于经验,可以实施更多的探索性测试、组合交互性(interoperation)测试和用户场景(user scenario)测试,更有效地发现埋藏较深的缺陷。
回归测试是敏捷测试中需要面对的难点。每次迭代都会增加新的功能,一个产品可能会经过十几次、甚至几十次迭代,回归测试范围在不断增大,而每次迭代周期没变,可能还是一个月。这样验收测试的时间非常有限,所以回归测试很大程度上依赖于自动化测试,因为很难将回归测试控制在非常有限的范围内。当然,还是有些办法可以帮助我们减少回归测试的范围,例如:
● 通过执行code diff来了解代码变动的所有地方,再做代码关联分析,就可以明确知道要进行哪些地方的回归测试,回归测试范围会大大缩小。
● 基于风险和操作面分析来减少回归测试的范围,例如回归测试只是保证主要功能点没有问题,而忽视一些细节的问题。
● 持续测试的过程,只要有时间,就进行测试,包括开发人员、产品设计人员都参与到日常的试用和测试中来。
相关链接: