最常见的34个敏捷测试⾯试的Q&A（上）
2017-06-27SQA翻译组
准备换⼯作吗？作为⼀个测试⼈员，今天赴⾯试现场，往往会被问到⼀系列有关敏捷测试的问题。即使是⼀个开发⼈员，同样也免不了。现在就帮忙⼤家做⼀些准备，这⾥列出最常见的34个敏捷测试⾯试的Q&A。 1. 作为测试⼈员，⾯对需求不断变更时应该采取什么措施或⽅法？ 当需求不断变化时，持续敏捷测试者应该采取以下⽅法 :
编写通⽤测试计划和测试⽤例，重点在于关注需求的意图，⽽不是其确切的细节。
为了了解需求变更的范围，与Product Owners (PO) 或着是业务分析员进⾏密切合作。
确保团队明⽩需求变更所涉及到的风险，特别是在迭代后期阶段。 如果你要进⾏功能测试⾃动化，最好等待，直到功能稳定⽽且需求不再发⽣变化。 通过协商或者实⾏下⼀个迭代的更改，可以将需求变化控制在⼀个很⼩的幅度。
（我解决⽅案更简单： 探索式测试+⾃动化测试，见： ，或者是 本迭代新功能的探索式测试 和上⼀迭代稳定功能的⾃动化脚本开
发 ）
2. 列举出探索式测试（在敏捷中使⽤）和基于脚本的测试的利弊
利弊
探索式测试-需要较少的准备
-当需求变更时易于修改
-当⽂档稀少时效果好
-呈现项⽬管理进度和覆
盖率很困难
基于脚本的测试-对于按照规范和管理要
求测试，它是⾮常有⽤
的
-通常，测试准备是耗时
的
-相同的步骤被⼀次⼜⼀
次的进⾏测试
-当需求更改时，很难以
修改
3. 解释极限编程和Scrum的区别Scrum XP
-团队成员通常必须在被称为冲刺(Sprint)的迭代中⼯作，迭代⼀般持续长达两周到⼀个⽉。-团队成员的迭代⼯作持续⼀到两周。
团队成员不允许改变迭代。-团队更灵活，可以改变迭代。
-PO对Product Backlog进⾏优先级排序，但是团队会决定开发Pr oduct Backlog项⽬的顺序。-团队以严格的优先级顺序⼯作，开发的功能由客户决定。
-没有规定⼯程实践。-规定⼯程实践。
（探索式测试也可以⽤在传统开发模式中，只是探索式测试和敏捷开发模式是天⽣的⼀对 ）
4. 什么是叙事诗（Epic）、⽤户故事和任务？
叙事诗：客户描述的、在Product Backlog中所列举的软件功能被称作为叙事诗。叙事诗被分解为许多⽤户故事。
⽤户故事：⽤户故事从⽤户的⾓度来考虑问题，它定义了项⽬或业务功能，并按预期在特定的迭代被交付。
任务：进⼀步将⽤户故事划分成不同的任务。
5. 解释什么是重构？
为了提⾼代码的性能和可读性，针对现有的代码进⾏修改，这就是重构。在重构时，代码的功能不变。
6. 解释如何⽤不同的团队能⼒衡量迭代的速度？
通常，当计划迭代时，迭代的速度通过基于历史数据的专业判断来进⾏度量。然⽽，⽤于计算迭代速度的数学公式：
1. 完成故事点x 团队的能⼒：如果你⽤每周40⼩时的百分⽐来衡量能⼒
2. 完成故事点/团队能⼒：如果你⽤⼯时来衡量能⼒
对于我们的情况，第⼆种⽅法是适⽤的。
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）被⼴泛⽤于什么的⼀部分？
原型和线框图都是原型，被⼴泛⽤作经验设计的⼀部分。
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，是当前最好的⼀套实践，是当前⽣产质量代码的技术集合。它不是⼀段扔掉的代码，但可能仅仅是⼀个粗糙的功能实现.
阅读 16146
(Tracer Bullet 出⾃ The Pragmatic Programmer: From Journeyman to Master.程序员修炼之道：从⼩⼯到专家 )
17. 什么是测试Stub ？
测试Stub 是⼀个少量代码的模块，它可以替代被测系统中未开发或完全开发的组件。测试Stub 被设计成通过产⽣特定的已知的输出并且
替代实际的组件这样⼀种⽅式。（待续）
精选留⾔ socker
第⼀个问题，显然还是把测试脱离在需求讨论之外了。
6⽉27⽇
1 第⼀个问题，侧重测试⼈员如何⾯对“需求变更”的挑战。从实际操作来讲，需求是否变更主要取决于客户／⽤户或业务部门，整个团队都相对被动，测试⼈员也会被动些。但在研发团队的所有需求相关的活动，测试⼈员不会置之度外。
6⽉28⽇
作者回复以上留⾔由筛选后显⽰
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议