最常见的34个敏捷测试面试的Q&A（上）
准备换工作吗？作为一个测试人员，今天赴面试现场，往往会被问到一系列有关敏捷测试的问题。即使是一个开发人员，同样也免不了。现在就帮忙大家做一些准备，这里列出最常见的34个敏捷测试面试的Q&A。
1. 作为测试人员，面对需求不断变更时应该采取什么措施或方法？
当需求不断变化时，持续敏捷测试者应该采取以下方法 :
-
编写通用测试计划和测试用例，重点在于关注需求的意图，而不是其确切的细节。
-
为了了解需求变更的范围，与Product Owners (PO) 或着是业务分析员进行密切合作。
-
确保团队明白需求变更所涉及到的风险，特别是在迭代后期阶段。
-
如果你要进行功能测试自动化，最好等待，直到功能稳定而且需求不再发生变化。
-
通过协商或者实行下一个迭代的更改，可以将需求变化控制在一个很小的幅度。
（我解决方案更简单： 探索式测试+自动化测试，见：软件测试的一个新公式引起的思考 ，或者是 本迭代新功能的探索式测试 和上一迭代稳定功能的自动化脚本开发 ）
2. 列举出探索式测试（在敏捷中使用）和基于脚本的测试的利弊
| |
利 |
弊 |
| 探索式测试 |
-需要较少的准备 -当需求变更时易于修改 -当文档稀少时效果好 |
-呈现项目管理进度和覆盖率很困难 |
| 基于脚本的测试 |
-对于按照规范和管理要求测试，它是非常有用的 |
-通常，测试准备是耗时的 -相同的步骤被一次又一次的进行测试 -当需求更改时，很难以修改 |
3. 解释极限编程和Scrum的区别
| Scrum |
XP |
| -团队成员通常必须在被称为冲刺(Sprint)的迭代中工作，迭代一般持续长达两周到一个月。 |
-团队成员的迭代工作持续一到两周。 |
| 团队成员不允许改变迭代。 |
-团队更灵活，可以改变迭代。 |
| -PO对Product Backlog进行优先级排序，但是团队会决定开发Product Backlog项目的顺序。 |
-团队以严格的优先级顺序工作，开发的功能由客户决定。 |
| -没有规定工程实践。 |
-规定工程实践。 |
（探索式测试也可以用在传统开发模式中，只是探索式测试和敏捷开发模式是天生的一对 ）
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
增量：增量开发将系统功能划分成若干个开发或部分。在每个增量开发中，从需求到部署之间的环节，由不同部门负责不同部分的功能，能够合并在一起运行。
（大家觉得这里解释正确吗？解释清楚吗？ 今天看来，迭代开发和增量开发已难以区分，你中有我，我中有你。 每个版本就是一个迭代的交付物，而不是版本1：迭代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）
11. 原型和线框图（wireframes）被广泛用于什么的一部分？
原型和线框图都是原型，被广泛用作经验设计的一部分。
（可参考：http://www.infoq.com/cn/articles/wireframes-start-development-projects）
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，是当前最好的一套实践，是当前生产质量代码的技术集合。它不是一段扔掉的代码，但可能仅仅是一个粗糙的功能实现.
(Tracer Bullet 出自 The Pragmatic Programmer: From Journeyman to Master.程序员修炼之道:从小工到专家 )
17. 什么是测试Stub？
测试Stub是一个少量代码的模块，它可以替代被测系统中未开发或完全开发的组件。测试Stub被设计成通过产生特定的已知的输出并且替代实际的组件这样一种方式。
（待续）
