Dev(Developer) :开发
TE(Test Engineer) :测试
PM(Product Manager) :产品
敏捷:快速的响应客户(需求),高效的完成开发,不断的追求完善。
TE在敏捷中应该做些什么呢?
流程1-故事分析
角色:
Dev、TE
内容:
需求交接前夕,PM将需求上传到文档管理区并邮件通知,Dev、TE分析需求
初步制定测试策略与测试计划
初步安排测试任务
输出:
测试策略、测试计划
测试工作量初步评估
流程2-故事计划
角色:
整个Team(PM、Dev、TE)
内容:
需求交接(宣讲),了解更多细节
确定测试工作量
更新测试策略各测试计划
考虑环境和并着手准备
输出:
测试策略、测试计划
测试工作量评估
流程3-Story Kickoff
角色:
Dev、TE
内容:
TE与Dev一起理解分析故事
列表疑虑点
Dev拆分task,并思考设计思路
TE列出测试要点
TE各Dev一起就以上各点对PM和Dev进行反串讲(用例与设计评审)
输出:
测试用例
流程4 -故事开发
角色:
TE、Dev
内容:
TE与Dev结对、实现自动化测试
输出:
自动化测试
PS:关于这点,没有自然语言自动化体系支撑,无法达到实行标准
流程5-Desk Check
角色:
TE、Dev、PM
内容:
Dev本地运行系统,准备数据自主UT
TE对此环境做快速测试,检查各流程功能是否开发完成,并反馈问题
PM 全程评价是反馈问题
输出:
Desk Check 问题记录
PS:Desk Check尚处于developing阶段,发现问题或者开发方向错误,Dev能快速修复,这样才能保证功能进入下一个阶段。
流程6-探索性测试、SIT
角色:
TE
内容:
执行测试用例
执行探索性测试
提交缺陷并及时验证修复问题
不能解决问题及时与PM沟通
每日进度反馈,并思考接口安全与性能测试
输出:
测试报告
流程7-UAT和产品验证
角色:
PM、TE
内容:
TE辅助PM验证功能
PM反馈问题
输出:
问题清单
流程8-上线
角色:
整个Team
内容:
TE上线线前回归验证
TE、Dev上线生产环境部署
TE、PM生产功能验证
验证反馈
输出:
上线验证报告
敏捷源于理论、而高于理论:
1、敏捷团队应该是怎么样的呢?
团队拆成小组作战方式,小组共6~10人,其中TE 1~2人,具体人数按实际情况拟定,选出组长。
组长需要分配工作,组织每天的晨会,收集问题,解决问题,总结反馈。
需求按照模块、共性、特性分配给小组,各组负责一部分需求,全组员协作、交接需求、分析需求、拆分任务、评估时间、制定计划、完成开发测试。
晨会(重要),所有人都必需讲真话、讲短话、讲实话。讲话内容应该是昨天的完成进度、问题、阻塞、风险、建议和今天需要做的事情;整个过程应该控制在5~15分钟内完成(更快、更精准、更高效)
版本周期中小组之间可以交叉协作,此点看重组员的综合实力。敏捷很考验综合实力,也是能更快的提升综合实力的。
能力强的Dev与TE可实现结对开发,完成代码UT。
2、分析需求、评估时间:
分析需求:
需求管理是以特性、故事、任务为框架管理。以故事为单位来评估时间汇总到特性。所以PM的需求文档,应尽量以特性为一级标题、故事为二级标题、内容须包含所有需要的UI、数据字段、功能逻辑、权限控制、三方对接等。以便在交接(宣讲)需求时,Dev与TE第一时间响应需求,折分故事。
需求交接(宣讲)完成。小组长带头,将本组负责模块需求拆分故事在便签上写出来,一个故事一个便签,列两个时间:Dev评估时间、Te评估时间。由对应Dev与T马上完成这个工作,然后小组长分析统计反馈。评估时间尽量在一小时内需要完成,半小时达优,达到敏捷。
2、用例与功能:
敏捷的要求在需交接(求宣)后,评估时间前,TE应该在纸上将所有需求测试点都逻辑出来。须简洁明了,即省而优,方便后面用例开展。
1、周期较快、需求较小、功能不重要的,写测试点
2、周期适中、需求适中、功能适中的,写测试点,测试场景
3、测试场景周期较长、需求很大、功能很重要的,写测试点、测试场景、接口性能安全,设计测试数据
测试:
1、Desk Check:敏捷没有三到四轮测试,仅仅一至两轮测试,所以要更早的介入测试,越早发现问题成本越小。
2、探索性测试:精准快速的熟悉陌生的新功能,新软件,方便后续用例测试。
3、习惯使用工具:熟练使用F12、抓包、SQL、postmen等工具与手段快速分解功能与测试用例。
4、良好习惯:缺陷里简单准确的描述出步骤、数据、现象、期望、图片等,方便Dev精准定位问题所在。
5、日清日结:决不遗留缺陷到第二天,Dev改完第一时间验证。
针对第5点举个例子:
上线前一天发现了缺陷,卡了部分流程,Dev需要晚上加班解决,然而TE很早撤退了,Dev解决完提交验证,缺陷只能等到明天来验证。TE第二天缺陷验证不过,吐槽Dev不行。但那部分流程还在卡着,任务无法完成。坚难的上线。
如果TE当晚跟进Dev验证这个问题,发现不通过,Dev及时解决。隔天一来,流程顺畅,测试通过,任务完成。舒服的上线。
4、每日总结:
每日总结:文字记录当天的进度、缺陷、难题、完成了什么、是否正常。明天需要做什么,建议性想法等。当为第二天的晨会准备。
5、冒烟与回归自动化:
好的自动化用例,可以重复利用、减少兼容问题、节约成本、解放人力、提高团队的能力。
自动化测试启动,测试组必须有一个经验丰富的ATE去做下面的事情:
1、首先需要确认项目自动化的可行性,通过历史版本观察,前端变更频繁不适合做UI自动化,后台变更频繁不适合做接口自动化,前端与后台都变更频繁的项目可以放弃自动化。不过并不绝对,分析各模块,稳定的可先实现自动化。
2、设计自动化策略,制定冒烟计划、回归计划:
策略:选择框架、工具、语言
自动化用例具有健壮性、重用性、独立性、维护性等特点,所以需要制定自动化计划。
冒烟计划优先制定,一个系统的冒烟用例不会多,保证主流程的通畅,用例检查点(断言)不用多、一个用例一个即可。
回归计划在冒烟用例完成后可以制定,回归用例与冒烟用例的比率应该在1:50~100。一个用例的检查点(断言)在3~5个,重点:回归用例ATE一个人难做的。需要测试组一起做。
自动化程度越高的项目TE越舒服。
建议:自动化测试的建设一项目稳定的情况下,越早越好,绝不能拖到敏捷开发时候。
6、持续集成:
CI:Continuous integration 持续集成
敏捷不可或缺的一项技术。
自由工具: Jenkins
可持续集成每日按定时任务自动部署,并邮件通知结果。减少了人功的操作,减少了错误率,使流程规范。
1、代码自动检查UT
2、自动编译
3、自动构建
4、自动部署
5、定时执行自动化用例
TE须知道如何搭建,并实战
7、管理工具使用
ALM:application lifecycle management 应用程序生命周期管理
TE须深入了此类工具
不管什么工具,一个TE拿到,在一段时间都应该玩的炉火纯青。故略~
8、版本数据监控:
TL技能,故略~
原文地址:https://www.cnblogs.com/xmLaoTan/p/11688926.html