标签：通知 重要 ati off 项目 life dev 经验 体系
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技能，故略~
标签：通知 重要 ati off 项目 life dev 经验 体系
原文地址：https://www.cnblogs.com/xmLaoTan/p/11688926.html
