準備換工作嗎？作為一個測試人員，今天赴面試現場，往往會被問到一系列有關敏捷測試的問題。即使是一個開發人員，同樣也免不了。
現在就幫忙大家做一些準備，這里列出最常見的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 . 解釋產品路線圖是什么意思?
產品路線圖是指創建產品遠景的產品特性的整體視圖。
