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

魂尾ACE

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

略

applepen

内容挺好，要是注意一下排版就更好了

applepen

海海豚

哇~谢谢分享

szc123qq