魂尾ACE 发表于 2020-5-12 22:42:48

给测试同胞们叙述一丢丢敏捷测试理论

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与TE马上完成这个工作,然后小组长分析统计反馈。评估时间尽量在一小时内需要完成,半小时达到敏捷。





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、版本数据监控:

szc123qq 发表于 2020-5-13 09:00:52

:time:

海海豚 发表于 2020-5-13 10:42:48

哇~谢谢分享

applepen 发表于 2020-5-13 12:39:48

:lol

applepen 发表于 2020-5-15 12:41:05

内容挺好,要是注意一下排版就更好了
页: [1]
查看完整版本: 给测试同胞们叙述一丢丢敏捷测试理论