关于敏捷测试，之前零零散散的写过好多篇文章，恰好微信公众号推出了“自荐”的功能，就想着完整的梳理一篇合集出来。希望能给大家带来一些帮助。
01 测试的底层逻辑
关于什么是敏捷测试，怎么定义的，其实并不重要，首先回顾下朱少民老师定义的测试底层逻辑：
贯穿整个研发周期，形成闭环，并持续改进测试流程
基于风险的测试策略是必不可少的
以终为始、系统地分析测试需求，在资源和测试目标之间寻求平衡
测试设计是艺术，更要创新、融合
在分析和设计的基础上，尽可能地实现自动化测试
讲好测试故事，和各方一致、协同工作
作为一名测试人员，我个人非常同意上面的说法。
02 需求端到端交付管理
一直以来，作为研发人员，我们关注的都是研发任务的端到端交付（从需求澄清到需求交付），很少有人会去关注需求本身是否给产品或者企业带来多少真正的价值（如激活了多少存量用户、吸引了多少新用户等等）。本文跳出研发人员的视角，从团队的角度梳理如何决策，尝试去做正确的事。详情点击下面链接。
03 从测试看需求
当产品团队确认了做正确的事（需求）后。研发团队如何对齐这件事呢？从我们的实践上来看，通过用户故事来描述需求，通过编写验收标准来达到产、研、测三端的对齐，会是个比较不错的方案，本文会介绍这方面的落地实践。详情点击下面链接。
04 软件测试很简单么
软件测试一直被外行人嘲讽，是个低门槛的职业，公司看门的大爷都可以做软件测试。导致现在还有很多人对测试的认知都停留在这个层面上。实际上，干一行爱一行。许多行业的入门要求都不高，但是要做得好，都不是简单的事。测试人员也不应当把自己局限在测试的职责范围内，不断扩充自己的边界，不好么？测试难不难，取决于你的自我要求。具体需要哪些技能呢，点击下面链接可查看。
05 持续测试持续反馈
关于什么是持续测试，个人的理解是：贯穿整个研发周期，不断验证和反馈的测试活动。至于形式是手动还是自动化，并不是那么重要。重要的是能够得到持续的反馈。那么有哪些业务和工程实践可以做到持续测试呢，本文会进行详细的介绍。详情点击下面链接。
06 测试策略的制定
在敏捷的环境中，我们虽然不再需要一份大而全的测试策略文档，但是在迭代开始前，还是要好好思考一下如何开展更有效的测试方法，我们需要提前为这个迭代的测试活动做些什么，它将指导我们更好的开展测试活动。而不是接到测试任务就开始测试，等遇到问题后，才开始想着如何处理。本文结合具体的案例进行拆解，详情点击下面链接。
07 测试用例写不写
测试用例是自己测试思维的一个载体，它指导着测试活动的进行，是测试执行的最低保障。至于以什么形式来承载，并不重要。处于不同阶段的团队对于测试用例的颗粒度也有不同的要求，可以从不同的目标来确认用例的颗粒度，只要团队形成统一的共识即可。本文从不同层面分析了测试用例需要编写的必要性，详情点击下面链接。
08 分层测试如何开展
基于分层测试思路，我们在做专项测试时，需要有针对性地去做验证。其实每个专项展开来讲，都会有很多的内容，本文篇幅有限，主要思考的还是如何去开展这些专项测试，至于工具的使用，现在有太多的工具可选择了。以终为始，希望测试同行们在提升代码能力的同时，不忘初心，记住我们是为了什么目标而开展专项测试，不要让技术偏离业务，而成为炫耀的存在。详情点击下面链接。
09 测试的最终产物是什么
每一次的迭代交付，对测试人员而言就是一次展示自己的机会，做为测试人员，我们应该做到：培养一个完善的测试思维、编写一份简洁的报告；拥有承担一点责任的勇气，不断努力精进自己的测试能力。详情点击下面链接。
10 团队的交付质量如何评估
如何评估团队的交付质量，初想多数和BUG相关，例如BUG数量、Reopen BUG数、BUG解决时长等等，好像都能体现交付质量啊。仔细想想，我们衡量交付质量，不能只看这些，质量不应该简简单单地缺陷关联上就可以了。还需要结合发布周期，线上监控等一些其它指标，详情点击下面链接。
11 番外两篇
提高自己话语权的三要素：“懂业务、懂技术、有思维”，而不是开发牵着鼻子走。如果你工作3年以上，还不具备这三要素，那需要反思的是自己，而不是去争取所谓的“话语权”。当你做好自己的本职工作，同时又能给团队些许帮助时，你就具备了一定的话语权。单纯行政上的话语权，当你能力不够时，只会沦为被嘲笑的对象。
你把时间花在哪里，就会在那里得到收获。如果你把过多的精力花在学习如何甩锅上，那么你将会有N多个理由去放弃质量。有这时间，还不如去尝试寻找一个可以提升自己能力的团队。尝试通过识别团队的质量观，同时认清自己的质量观，找到一个适合的团队。
