什么是敏捷开发？
敏捷开发（Agile Development）是一种以人为核心、迭代、循序渐进的开发方法【迭代式的开发】
如何理解
它不是一种技术（不属于测试或开发），它是一种开发方法，一种软件开发的流程（是一种思想），指导我们按规定的环节去一步步完成项目开发，而这个开发方式的主要驱动核心是人，它采用的是迭代式开发。
敏捷测试常见术语
scrum：敏捷研发的框架【敏捷思想框架】 sprint：原意为冲刺，Scrum中的Sprint无对应中文翻译，指一个迭代 scrum master：敏捷专家，敏捷研发总负责人【不需要懂开发，测试，项目管理。只需要懂敏捷思想，一种处理事务的方式风格】 product owner：产品负责人，简称PO scrum team：敏捷研发团队 product backlog：产品待办列表，指需求清单【基于产品考虑的，测试需要做的事】 sprint backlog：sprint待办列表，指sprint任务清单【在product backlog里拿出来，这个迭代要做的事】 daily scrum meeting：每日站会 sprint review meeting：sprint评审会议 user story：用户故事，指一条需求
主要角色及职责
PO（Product Owner）产品负责人
产品负责人复制最大化产品以及开发团队工作的价值，实现这一点的方式会随着组织、Scrum团队以及单个团队成员的不同而不同。
SM（Scrum Master）敏捷教练/专家
Scrum Master以各种方式服务于产品负责人和Scrum团队【只关心敏捷的流程是否按照预定的敏捷流程走】
ST（Scrum Team）Scrum团队
包含了专业人员，负责在每个sprint的结尾交付潜在可发布的“完成”产品增量。只有开发团队的成员才能创造增量。 开发团队由组织构建并授权，来组织和管理他们的工作、所产生的协同工作能最大化开发团队的整体效率和效力。【根据需求，确定迭代内容，按照预定规则增量交付】
Scrum详细解释
Scrum是一个用于开发和维持复杂产品的框架【产品如果可以在较短时间做完上架的话，就可以不采用敏捷，主要是需要确定项目抢占市场的一个价值】，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个端的迭代周期称为sprint，每个print的建议长度是2-4周【国内的话1周到2个月都有】。使用product backlog来管理产品需求，product backlog是一个按照商业价值排序的需求列表，列表条目的表现形式通常为user story【需求】。scrum team总是先开发对客户具有较高价值的需求【先后顺序的确定】。在sprint中，scrum team从product backlog中挑选最高优先的需求进行开发，挑选的需求在sprint计划会议上经过讨论，分析和估算得到相应的任务列表，我们称它为sprint backlog【召开迭代拆分会议，梳理迭代安排、先做哪些，并输出确定级别的sprint backlog】，在每个迭代结束时，scrum team将递交潜在可交付的产品增量。scrum起源于软件开发项目，但它适用于任何复制或是才能更新性的项目。
敏捷软件开发宣言
Manifesto for Agile Software Development 个体和互动高于流程和工具【相比流程，以人为核心，尊重个人想法，多互动，灵活性】 工作的软件高于详尽的文档【软件的目标就是尽可能傻瓜式的操作，把自己当成客户】 客户合作高于合同谈判：关心客户的痛点【了解客户的核心需求】 响应变化高于遵循计划：【快速迭代，每做完一个迭代就叫客户来看或者请一些人来内测；沟通频次要提高，每次做完一个小模块，小页面就去和客户确认是否是想要的，如果不是，提出来下个迭代立马改掉；敏捷开发最大的好处就是可以快速响应客户的需求，每两周就有一个东西可以给到客户让他去确认，当有变化的时候两周后立马就给改了，能够快速响应沟通】
敏捷软件研发的十二条原则
最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意 欣然面对需求变化，及时在开发后期也一样，为了客户的竞争优势，敏捷过程掌控变化。 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 业务人员和开发人员必须相互合作，项目中的每一天都不例外。 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。 不论团队内外，传递信息效果最好效率也最高的方式是面对面交谈。【100个人的公司可能有12个会议室，小型会议室】 可工作的软件是进度的首要度量标准 敏捷过程倡导持续开发，责任人、开发人员和用户要能够共同维持其不掉稳定延续 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强 以简洁为本，它是极力减少不必要工作量的艺术 最好的架构、需求和设计处置组织团队 团队定期地反思如何能提高成效，并依次调整自身的举止表现
客户【如委托方对软件的要求】/市场【调研市场对已软件的情况（如何做应该完爆其他软件的爆品）】/高层【领导的需求和意愿】→软件新的创意/存在缺陷/新的功能→product owner（产品负责人）【负责收集创意/缺陷/功能】→产品功能列表（produce backlog）【产品代办列表：收集信息整合出的清单】→由PO组织的计划会（sprint backlog）【迭代拆分会：sprint待办列表】[参与人员：开发（开发经理）、测试（测试经理）、产品（产品经理）、开发测试的骨干人员；其他人员如运维、支持等选择性参加，一般是测试完了需要给技术支持培训一下：毕竟技术支持要给测试客户，需要懂迭代做了什么]→迭代任务【一般只输出最近的三个迭代任务即可】→敏捷开发【敏捷开发模型】→可工作软件【迭代不一定上线，可以给用户查看，修改】→每日立会【站立的立，简洁精神面对面交流】→评审会【用例评审】→反思会
星期一星期二星期三星期四星期五第一周上午：需求评审写手工测试用例写手工测试用例数据库准备数据， 写自动化脚本等等待开发提测（把冒烟测试用例给开发）下午：讨论分工，写测试用例，评估工作量第二周环境搭建，开始测试，执行用例（手工测试）测试提bug 开发改bug测试题bug 开发改bug回归测试（手工）测试报告，产品验收，上线
Scrum的常见活动
产品待办事项列表梳理【迭代拆分】
产品待办事项通常会很大，而且也很宽泛，还会变来变去、优先级也会变化，所有产品待办事项梳理是一个贯穿整个scrum项目始终的活动。该活动包含但不限于以下内容：
保持产品待办事项列表有序 把看起来不再重要的事项移除或者降级 增加或提升涌现出来的或变得更重要的事项 将事项分解成更小的事项 将事项合并为更大的事项 对事项进行估算【需要几周去做完，多个模块是否需要放在一个迭代去做】
产品待办事项列表梳理的一个大好处是为即将到来的几个sprint做准备，维持，梳理时会特别关注那些即将被实现的事情
迭代计划会议
Scrum看板
标记大家工作进度的进展
待办：最开始都是待办 处理中：项目开始处理事项逐渐增加 完成：全部完成是项目的目标之一
Scrum每日站会
每日站立会议是敏捷流程scrum中很重要的一个制度之一【迭代的开发、测试、产品人员，每次会议控制在10个人，10min左右，每个人大概1分钟发言时间，内容：昨天做了什么，今天做什么，昨天遇到什么问题】 功能
快速同步进展，让项目组内部的员工互相了解彼此的进展，从而了解本项目的整体进展【如产品经理等着测试进度】 给每个人一种精神压力，新手成立，这是一种面对面的精神压力，直面项目进展【承诺计划做的事情，第二天汇报昨天的事情是否做完，如果没做完，是因为什么原因导致的，出了什么问题，大家一起来解决】 培养团队的文化，让每个人意识到：我不是一个人在战斗，我们是一个团队
站立会的目的
让所有人了解其他人在做什么，当前项目计划进展如何 帮助大家解决那些阻碍做事情的问题，以及共享承诺这些都非常有利于提高团队合作精神的
Scrum迭代回顾会议
在每个sprint结束后，scrum团队会聚在一起开sprint回顾会议【比如每周五下午4-6点，每周轮流一个人去给大家买吃的喝的零食，将大家叫道会议室里，桌上摆的全是吃的，大家就边吃边开会（开会内容：这个迭代里你认为谁做得好或者不好），提前准备小纸条来写，专人收集，把共同的问题整理出来，边吃边去过这些问题（以轻松的方式来相互吐槽，说一下问题）】
目的是回顾一下团队在流程人机关系以及工具方面做得如何 团队识别出那些做得好，哪些做得不好，并找出潜在的改进事项，为将来的改进指定计划 所有的scrum会议都是限定时长的，sprint回顾会议的，推荐时长是sprint中的每一周对应一个小数（比如一个sprint包含两个星期，则sprint回顾会议时长为2小时）
Scrum架构模式
迭代不一定上线，初期基础功能不全，是半成品，还用不了。只能说迭代完了，可以去验收【比如crm：梳理了20个迭代，需要做1年半，增量式交付，迭代式开发】
探索性测试
什么是探索式测试？
探索式测试（ET Exploratory Testing）是一种软件测试风格，而不是一种具体的软件测试技术（如等价类划分、边界值分析、组合测试等。） 探索式测试强调依据当前待测项目实际情况，选择合适的测试技术，而不局限于特点的测试技术【根据特殊的情况，采用特殊的方式，达到测试的目的，已目的为导向的测试】
探索式测试的核心思想
探索式测试强调独立测试人员的自由和责任。测试人员应该为个人和团队负责，调动所有能量，发挥人的灵活性，在整体上持续优化个人和团队的产出 自由：任意发挥，采用各种测试技术；责任：有义务/必须将软件测好
什么样的项目适合做探索式测试？(一定要写简历上)
SRS（Software Requirements Specifiction）不完善，时间紧迫，没有测试用例的情况下，以ET快速完成版本新功能的测试。作用：更快设计，更快执行，更低成本 系统测试之后，时间允许的情况下，以ET作为补充，尝试系统测试覆盖不到的场景。作用：减少漏测，提高覆盖【一般不会有这种情况发生，发生就是工作量不饱和，对产品测试的估算时间出现严重失误，导致产品上线时间有延迟，无法今早抢占市场。问题严重！】
前提：
团队对产品功能比较熟悉 已经可以运行的待测软件
探索式测试在项目中如何落地
快速学习需求：基于对软件你是版本的熟悉，对新版本功能快速学习，提出问题并进行澄清【没有需求文档的时候：产品经理、开发、测试在一个会议室里，如果前期没bug，开发可以先走，产品经理不能走，就坐测试旁边办公，集中办公，测试有问题直接找产品确认，减少沟通成本。提出需求问题，产品快速提出相应和澄清】 做出计划：时间，范围，团队分工（模块）、负责人等
论坛项目探索式测试模块时间负责人注册登录6.23-6.24测试A技术文章6.23-6.25测试B问答贴6.23-6.25测试C
利用脑图形式，列出有哪些模块，覆盖哪些场景，每个场景的注意事项，然后进行评审。【整理测试点，确保大方向没有遗漏，比如输入框、编辑按钮、删除按钮等。不是一个新软件，而很可能是一次迭代，正常需要7、8天，压缩到2、3天】 探索：按照脑图，执行探索过程中，根据情况，逐步深挖（也是边执行边学习的过程）每条path，更新并记录执行过程中走过的path（带着反思去执行测试）【脑图是我们探索性测试的探索地图，先有地图后有探索，探索测试过程需要有简单，记录比如对输入的长度验证，格式验证。需要把所以的记录痕迹通过脑图保留下来，做为探索性测试的文档记录】Bug需要直接写出来（要求和提bug的要求一致：什么bug，什么情况下出现的），注意关联值的传递【比如下拉框里的值，可能是需要去另外一个模块添加，因此需要去另一个模块添加校验等】核心：1.脑图整理出来（测试点）；2.直接上手测，测的时候反复跳转，记录测试过程；3.通过打勾，不通过标记出来，把bug的一些描述写上；4.以上过程循环往复，来回跳转 提交缺陷：把探索性测试过程中发现的缺陷提交到缺陷管理系统中，修复后回归 报告总结：以简单的表格，对bug的分布，数量，级别，进行统计和报告【时间太紧迫可以直接将思维导图扔给开发，按照提交的bug进行修改。但是不管怎样，还是需要找个时间，把bug整理回去，作为存档jira】
论坛项目探索式测试报告总耗时发现buu总数A类bug总数B类bug总数C类bug总数D类bug总数26小时681236155bug类型数据展示异常表单校验错误页面展示错误提示信息错误基本功能异常数量201614108已解决数量18151388本项目采用探索性测试，共发现69bug，bug详细分类如上表所示，目前已解决的bug为62，bug修复率为62/68=，符合/不符合上线标准，可以/不可以上线
上线标准：95%的bug已修复，剩下5%的bug不含重要级别的bug【功能性bug】，轻微和一般的bug可以留着，后面出优化版本
总结【三个交付】
测试计划：谁负责什么模块，什么时候测完 探索脑图：谁负责哪个知识点，探索了哪些功能点，测试内容通过还是不通过，不通过写原因【写bug描述】 测试报告：脑图补充好之后，出一个简洁版的测试报告
面试题
你们企业的工作流程是什么，你上个月做的这个迭代有哪些内容，是怎么去做的，都包括哪些环节，你参与了什么环节？ 离职前的迭代你负责的是什么？ 你测这个项目这么久了，上线了没有？你们上线是怎么个方式上的，多久上的？双周一定上线吗？迭代完了一定上吗？
你们公司当时是什么情况导致你们采用探索性测试？具体怎么做的？
我的当时有一个项目比较紧，开发已经做完了但测试还没有人投入，项目急着上线，留给我们的时间不到3天，三天后必须上线，所以我们选择了探索性测试
如有侵权，邮箱联系，实属抱歉。 此只为学习个人笔记整理，同时如有转载请注明出处。 联系邮箱：wengyao1234@outlook.com 一同学习测开技企鹅群（闲聊，水群，广告勿扰）：826471103
推荐链接
您阅读本篇文章共花了：
发表评论