准备换工作吗？作为一个测试人员，今天赴面试现场，往往会被问到一系列有关敏捷测试的问题。即使是一个开发人员，同样也免不了。
现在就帮忙大家做一些准备，这里列出最常见的34个敏捷测试面试的Q&A。
1 . 作为测试人员，面对需求不断变更时应该采取什么措施或方法？
当需求不断变化时，持续敏捷测试者应该采取以下方法 :
编写通用测试计划和测试用例，重点在于关注需求的意图，而不是其确切的细节。
为了了解需求变更的范围，与Product Owners (PO) 或着是业务分析员进行密切合作。
确保团队明白需求变更所涉及到的风险，特别是在迭代后期阶段。
如果你要进行功能测试自动化，最好等待，直到功能稳定而且需求不再发生变化。
通过协商或者实行下一个迭代的更改，可以将需求变化控制在一个很小的幅度。
（对于测试者和开发者来说，产品经理修改需求是常见的场景，这也就是为什么行业里面会有“”PM立字据“的传说，有一种更好一点的解决方法可能是 探索式测试+自动化测试，或者是 本迭代新功能的探索式测试 和上一迭代稳定功能的自动化脚本开发。探索式测试来发现新问题，自动化测试保证系统的老版本上没有因为修改导致出现新的问题）
2 . 列举出探索式测试（在敏捷中使用）和基于脚本的测试的利弊
3 . 解释极限编程和Scrum的区别
（探索式测试并不仅仅使用，只是探索式测试和敏捷开发模式是天生的一对 ）
4 . 什么是叙事诗（Epic）、用户故事和任务？
叙事诗：客户描述的、在Product Backlog中所列举的软件功能被称作为叙事诗。叙事诗被分解为许多用户故事。
用户故事：用户故事从用户的角度来考虑问题，它定义了项目或业务功能，并按预期在特定的迭代被交付。
任务：进一步将用户故事划分成不同的任务。
5 . 解释什么是重构？
为了提高代码的性能和可读性，针对现有的代码进行修改，这就是重构。在重构时，代码的功能不变。
（也就是项目组要还的技术债。。。）
6 . 解释如何用不同的团队能力衡量迭代的速度？
通常，当计划迭代时，迭代的速度通过基于历史数据的专业判断来进行度量。然而，用于计算迭代速度的数学公式：
完成故事点x 团队的能力：如果你用每周40小时的百分比来衡量能力
完成故事点/团队能力：如果你用工时来衡量能力
对于我们的情况，第二种方法是适用的。
7 . 说一下sprint backlog和product backlog的关键区别？
Product backlog包含一张全部需要功能的清单并且由PO编写。
Sprint backlog是开发团队拥有的Product backlog的一部分，并且将这些承诺放在迭代中。它是在迭代计划会议（SprintPlanning Meeting）中所创建的。
8 . 在敏捷中提到的增量和迭代开发有什么不同？
迭代：迭代方法是一个连续软件开发的过程，软件开发周期重复（迭代&发布，sprint & releases），直到最终的产品实现。
版本1：迭代1, 2, …, n
......
版本n：迭代1, 2, …, n
增量：增量开发将系统功能划分成若干个开发或部分。在每个增量开发中，从需求到部署之间的环节，由不同部门负责不同部分的功能，能够合并在一起运行。
（其实，在今天的开发模型中。。。增量和迭代已经没有那么明显的分界线，我更愿意理解为一种学术上的人为分类 ）
9 . 解释敏捷中的spike和第0个迭代（Zero Sprint）,其目的是什么？
迭代0：在开始第一次迭代之前，它被引入来做一些研究。通常这个迭代在项目启动时，用于开发环境的设置、准备Product backlog等。
Spikes：Spikes被用来表示研究、探索、设计甚至原型等活动的原型（简陋而快速的实现）。在迭代之间，可以采取spikes来应对与工作相关的任何技术或者设计问题。Spikes分为技术Spikes和功能Spikes两种类型。
（迭代0 更多的工作就是需求分析／定义：形成Product backlog，架构设计、数据库设计等 ）
10 . 什么是TDD？
TDD，测试驱动开发，也被称作为测试驱动设计。在“测试驱动开发”这种实践中，开发者首先编写一个描述新功能或者改进的自动化测试用例（测试脚本／测试代码），然后编写一些零碎的代码来运行该测试，然后重新确定新代码以满足可接受的标准。
（TDD是包含两部分：ATDD与UTDD。
ATDD（Acceptance Test Driven Development）：验收驱动测试开发，首先BA或者QA编写验收测试用例，然后Dev通过验收测试来理解需求和验收条件，并编写实现代码直到验收测试用例通过。
由于验收方法和类型也是多种多样的，所以根据验收方法和类型的不同，ATDD其实是包含BDD（Behavior Driven Development）、EDD（Example Driven Development），FDD（Feature Driven Development）、CDCD（Consumer Driven Contract Development）等各种的实践方法。
比如以软件的行为为验收标准，这个是BDD；如果以特定的实例数据为验收标准，这个是EDD；如果以Web Service API消费者提出API契约来驱动API提供者开发API，这个是CDCD等。所以ATDD的具体实现需要结合项目的实际情况来选用适合的验收测试方法与类型。
UTDD（Unit Test Driven Development）：单元驱动测试开发，首先Dev编写单元测试用例，然后编写实现代码直到单元测试通过。这个就是现在很多人所谓的TDD、实践的TDD、喜欢的TDD、抱怨的TDD，但是它却只是真正意义上TDD的一部分而已。）
11 . 原型和线框图（wireframes）被广泛用于什么的一部分？
原型和线框图都是原型，被广泛用作经验设计的一部分。
12 . 解释什么是应用二进制接口？
在不同的系统平台和环境中，以二进制形式定义应用程序可移植性要求的API规范称为应用程序二进制接口。
13 . 解释敏捷中的燃尽图，包括burn-up chart 和 burn-down chart？
为了跟踪项目进度的开始和结束，使用这些图表。
burn-up chart（燃起图）：它显示了随着时间的推移，故事开发的进展状态。
burn-down chart（燃尽图）：显示还有多少工作要做。
14 . 解释什么是Scrum ban？
Scrum ban是一个基于Scrum和看板的软件开发模式。它专门为需要频繁维护的项目而设计，经常会遭遇预料不到的用户故事和程序错误。使用这些方法，团队的工作流程将以每个用户故事或编程错误的最小完成时间为导向。
15 . 什么是故事点/投入/标度（points/efforts/ scales）？
它用来讨论没有分配时间的故事的难度。最常见的标度是斐波那契序列（1, 2, 3, 5, 8,13，...，100），不过有些团队使用线性标度（1, 2, 3, 4 ...），2的次方（1, 2, 4, 8 ......）和衣服尺寸标度（XS，S，M，L，XL）
16 . 解释什么是曳光弹（Tracer Bullet）？
曳光弹是当前架构的Spikes，是当前最好的一套实践，是当前生产质量代码的技术集合。它不是一段扔掉的代码，但可能仅仅是一个粗糙的功能实现.
17 . 什么是测试Stub？
测试Stub是一个少量代码的模块，它可以替代被测系统中未开发或完全开发的组件。测试Stub被设计成通过产生特定的已知的输出并且替代实际的组件这样一种方式。
18 .统一过程(Rational Unified Process)和Scrum方法有什么区别？
19 . 为什么持续集成对敏捷很重要?
持续集成对于敏捷来说很重要，因为以下原因：
● 通过发现缺陷或集成错误，可以帮助保持及时发布产品。
● 由于频繁的敏捷代码交付，通常每个迭代（sprint）是2-3周，稳定的构建质量是必须的，并且持续集成确保做到这一点
● 帮助维护代码库的高质量状态（bug很少）
● 如果开发工作使用自动构建和合并功能，则持续集成有助于检查工作分支对主干的影响。
20 . 在敏捷过程中进行了哪些测试?
在敏捷过程中，主要的测试活动是自动化单元测试和探索式测试。
但是，根据项目的需求，测试人员可以在被测应用(Application Under Test，AUT)上执行功能测试和非功能性测试。
21 .解释敏捷中的速度（Velocity）是什么?
速度是一种度量，是根据在迭代中所完成的用户故事相关的各种努力来估算出来的。它计算出在敏捷的一个迭代中可以完成多少工作，以及完成一个项目需要多少时间。
22 . 优秀的敏捷测试人员应该具备哪些素质?
优秀的敏捷测试人员应该具备以下素质：
● 能够很快地理解需求
● 敏捷测试人员应该了解敏捷原则和概念
● 随着需求不断变化，测试人员应该了解其中的风险
● 基于需求，敏捷测试人员应该能够对工作进行优先级排序
● 业务伙伴、开发人员和测试人员之间的持续沟通是必须的
23 . 谁都参与了敏捷团队?
在敏捷中，两个主要的领导者是：
● Scrum Master: 协调敏捷项目流程所需的绝大部分输入和输出
● 开发经理: 他们雇佣合适的人，并与团队一起培养他们。
24 . 详细地描述Scrum Master 这个角色起什么作用?
Scrum Master的主要职责包括
● 了解需求并将其转换为可工作的软件
● 监控和跟踪
● 报告和沟通
● 过程检查大师
● 质量大师
● 克服障碍
● 解决冲突
● 保护团队和绩效反馈
● 领导所有会议，消除障碍
25 . 提到敏捷的质量策略是什么?
敏捷质量策略是：
● 重构
● 非单一的（Non-solo）开发模式 （团队共同开发模式）
● 静态和动态代码分析
● 复审和审查
● 迭代（sprint）演示
● 全员（all hands）演示
● 轻量型的里程碑评审
● 短的反馈周期
● 标准和指导方针
26 . 在开发敏捷项目时，屏幕截图工具，有什么推荐?
在开发敏捷项目时，您可以使用类似工具：
● BugDigger
● BugShooting
● qTrace
● Snagit
● Bonfire
● Usersnap
（每次看到这个，总觉得是做工具的厂商在做软广）
27 . 在整个项目中保持一致的迭代周期，有什么好处?
好处是：
● 它帮助团队客观地衡量进展
● 它提供了一种测量团队速度的一致方法
● 它有助于建立一致的交付模式
28 . 如果一个时间段计划的任务优先级需要再排序，谁应该做这件事?
如果一个时间段（time-box，可以看作一个迭代）计划需要重新排序（优先级排序），应该由整个团队、PO和开发人员来考虑。
29 .提到燃尽图应该强调什么?
燃尽图显示了在时间段(迭代)结束之前需要完成的剩余工作。
30 .提到Scrum和敏捷之间的区别是什么?
● Scrum: 在Scrum中，sprint是开发的基本单位。每一个sprint后面都有一个计划会议，在这个会议中，sprint的任务被确定和估计。在每个sprint中，团队创建产品的部分功能特性
● 敏捷: 在敏捷中，每次迭代都涉及到一个团队，他们致力于完整的软件开发生命周期，包括计划、设计、编码、需求分析、单元测试，以及当向项目干系人演示产品时所做的的验收测试。
简而言之，敏捷是实践，scrum是遵循这一实践的过程。
31 .提到敏捷软件开发中所涉及的挑战是什么?
敏捷软件开发中涉及的挑战包括：
● 需要更多的测试和客户的参与
● 对管理的影响超过了开发人员
● 每个特性都需要在移动到下一个迭代之前完成
● 所有代码都必须正常工作，以确保应用程序处于工作状态
● 需要更多的计划
32 .什么时候不使用敏捷?
在使用敏捷方法之前，您必须提出以下问题：
● 功能可以拆分吗？
● 客户在那里吗（客户可以和我们一起工作吗）？
● 需求很灵活吗？
● 时间限制真的很紧吗？
● 团队技能足够强吗？
33 . 解释你如何以一种简单的方式来实施scrum?
这些技巧可以帮助你在项目中实施scrum。
● 待办事项（backlog）（按对客户的价值）排好序
● 了解产品待办事项各项的大小
● 阐明sprint的需求和持续时间，以完成迭代backlog
● 估算团队sprint工作量，然后将需求分解为任务
● 协作工作区：一个所有团队讨论的中心，包括计划、路线图、关键日期、功能的草图、问题、日志、状态报告等等。
● Sprint：确保在一段时间内完成一部分功能，然后继续下一个。除非没有其他选择，否则sprint不应该中止
● 参加每日的站立会议: 在会议上值得提一下，上次会议取得了什么成果？在下次会议前取得了什么成果？有没有阻碍我们前进的障碍？
● 使用燃尽图表来跟踪每天的进度。从燃尽图中，可以评估是在正常跑道上（正常状态）、还是在后面跑。
● 在进入下一个迭代之前完成每个特性；
● 在sprint结束的时候，召开一个sprint（迭代）回顾会议，展示sprint中的实现或交付。
34 . 解释产品路线图是什么意思?
产品路线图是指创建产品远景的产品特性的整体视图。
