準(zhǔn)備換工作嗎？作為一個(gè)測(cè)試人員，今天赴面試現(xiàn)場(chǎng)，往往會(huì)被問(wèn)到一系列有關(guān)敏捷測(cè)試的問(wèn)題。即使是一個(gè)開(kāi)發(fā)人員，同樣也免不了。
現(xiàn)在就幫忙大家做一些準(zhǔn)備，這里列出最常見(jiàn)的34個(gè)敏捷測(cè)試面試的Q&A。
1 . 作為測(cè)試人員，面對(duì)需求不斷變更時(shí)應(yīng)該采取什么措施或方法？
當(dāng)需求不斷變化時(shí)，持續(xù)敏捷測(cè)試者應(yīng)該采取以下方法 :
編寫(xiě)通用測(cè)試計(jì)劃和測(cè)試用例，重點(diǎn)在于關(guān)注需求的意圖，而不是其確切的細(xì)節(jié)。
為了了解需求變更的范圍，與Product Owners (PO) 或著是業(yè)務(wù)分析員進(jìn)行密切合作。
確保團(tuán)隊(duì)明白需求變更所涉及到的風(fēng)險(xiǎn)，特別是在迭代后期階段。
如果你要進(jìn)行功能測(cè)試自動(dòng)化，最好等待，直到功能穩(wěn)定而且需求不再發(fā)生變化。
通過(guò)協(xié)商或者實(shí)行下一個(gè)迭代的更改，可以將需求變化控制在一個(gè)很小的幅度。
（對(duì)于測(cè)試者和開(kāi)發(fā)者來(lái)說(shuō)，產(chǎn)品經(jīng)理修改需求是常見(jiàn)的場(chǎng)景，這也就是為什么行業(yè)里面會(huì)有“”P(pán)M立字據(jù)“的傳說(shuō)，有一種更好一點(diǎn)的解決方法可能是 探索式測(cè)試+自動(dòng)化測(cè)試，或者是 本迭代新功能的探索式測(cè)試 和上一迭代穩(wěn)定功能的自動(dòng)化腳本開(kāi)發(fā)。探索式測(cè)試來(lái)發(fā)現(xiàn)新問(wèn)題，自動(dòng)化測(cè)試保證系統(tǒng)的老版本上沒(méi)有因?yàn)樾薷膶?dǎo)致出現(xiàn)新的問(wèn)題）
2 . 列舉出探索式測(cè)試（在敏捷中使用）和基于腳本的測(cè)試的利弊
3 . 解釋極限編程和Scrum的區(qū)別
（探索式測(cè)試并不僅僅使用，只是探索式測(cè)試和敏捷開(kāi)發(fā)模式是天生的一對(duì) ）
4 . 什么是敘事詩(shī)（Epic）、用戶故事和任務(wù)？
敘事詩(shī)：客戶描述的、在Product Backlog中所列舉的軟件功能被稱作為敘事詩(shī)。敘事詩(shī)被分解為許多用戶故事。
用戶故事：用戶故事從用戶的角度來(lái)考慮問(wèn)題，它定義了項(xiàng)目或業(yè)務(wù)功能，并按預(yù)期在特定的迭代被交付。
任務(wù)：進(jìn)一步將用戶故事劃分成不同的任務(wù)。
5 . 解釋什么是重構(gòu)？
為了提高代碼的性能和可讀性，針對(duì)現(xiàn)有的代碼進(jìn)行修改，這就是重構(gòu)。在重構(gòu)時(shí)，代碼的功能不變。
（也就是項(xiàng)目組要還的技術(shù)債。。。）
6 . 解釋如何用不同的團(tuán)隊(duì)能力衡量迭代的速度？
通常，當(dāng)計(jì)劃迭代時(shí)，迭代的速度通過(guò)基于歷史數(shù)據(jù)的專業(yè)判斷來(lái)進(jìn)行度量。然而，用于計(jì)算迭代速度的數(shù)學(xué)公式：
完成故事點(diǎn)x 團(tuán)隊(duì)的能力：如果你用每周40小時(shí)的百分比來(lái)衡量能力
完成故事點(diǎn)/團(tuán)隊(duì)能力：如果你用工時(shí)來(lái)衡量能力
對(duì)于我們的情況，第二種方法是適用的。
7 . 說(shuō)一下sprint backlog和product backlog的關(guān)鍵區(qū)別？
Product backlog包含一張全部需要功能的清單并且由PO編寫(xiě)。
Sprint backlog是開(kāi)發(fā)團(tuán)隊(duì)擁有的Product backlog的一部分，并且將這些承諾放在迭代中。它是在迭代計(jì)劃會(huì)議（SprintPlanning Meeting）中所創(chuàng)建的。
8 . 在敏捷中提到的增量和迭代開(kāi)發(fā)有什么不同？
迭代：迭代方法是一個(gè)連續(xù)軟件開(kāi)發(fā)的過(guò)程，軟件開(kāi)發(fā)周期重復(fù)（迭代&發(fā)布，sprint & releases），直到最終的產(chǎn)品實(shí)現(xiàn)。
版本1：迭代1, 2, …, n
......
版本n：迭代1, 2, …, n
增量：增量開(kāi)發(fā)將系統(tǒng)功能劃分成若干個(gè)開(kāi)發(fā)或部分。在每個(gè)增量開(kāi)發(fā)中，從需求到部署之間的環(huán)節(jié)，由不同部門(mén)負(fù)責(zé)不同部分的功能，能夠合并在一起運(yùn)行。
（其實(shí)，在今天的開(kāi)發(fā)模型中。。。增量和迭代已經(jīng)沒(méi)有那么明顯的分界線，我更愿意理解為一種學(xué)術(shù)上的人為分類(lèi) ）
9 . 解釋敏捷中的spike和第0個(gè)迭代（Zero Sprint）,其目的是什么？
迭代0：在開(kāi)始第一次迭代之前，它被引入來(lái)做一些研究。通常這個(gè)迭代在項(xiàng)目啟動(dòng)時(shí)，用于開(kāi)發(fā)環(huán)境的設(shè)置、準(zhǔn)備Product backlog等。
Spikes：Spikes被用來(lái)表示研究、探索、設(shè)計(jì)甚至原型等活動(dòng)的原型（簡(jiǎn)陋而快速的實(shí)現(xiàn)）。在迭代之間，可以采取spikes來(lái)應(yīng)對(duì)與工作相關(guān)的任何技術(shù)或者設(shè)計(jì)問(wèn)題。Spikes分為技術(shù)Spikes和功能Spikes兩種類(lèi)型。
（迭代0 更多的工作就是需求分析／定義：形成Product backlog，架構(gòu)設(shè)計(jì)、數(shù)據(jù)庫(kù)設(shè)計(jì)等 ）
10 . 什么是TDD？
TDD，測(cè)試驅(qū)動(dòng)開(kāi)發(fā)，也被稱作為測(cè)試驅(qū)動(dòng)設(shè)計(jì)。在“測(cè)試驅(qū)動(dòng)開(kāi)發(fā)”這種實(shí)踐中，開(kāi)發(fā)者首先編寫(xiě)一個(gè)描述新功能或者改進(jìn)的自動(dòng)化測(cè)試用例（測(cè)試腳本／測(cè)試代碼），然后編寫(xiě)一些零碎的代碼來(lái)運(yùn)行該測(cè)試，然后重新確定新代碼以滿足可接受的標(biāo)準(zhǔn)。
（TDD是包含兩部分：ATDD與UTDD。
ATDD（Acceptance Test Driven Development）：驗(yàn)收驅(qū)動(dòng)測(cè)試開(kāi)發(fā)，首先BA或者QA編寫(xiě)驗(yàn)收測(cè)試用例，然后Dev通過(guò)驗(yàn)收測(cè)試來(lái)理解需求和驗(yàn)收條件，并編寫(xiě)實(shí)現(xiàn)代碼直到驗(yàn)收測(cè)試用例通過(guò)。
由于驗(yàn)收方法和類(lèi)型也是多種多樣的，所以根據(jù)驗(yàn)收方法和類(lèi)型的不同，ATDD其實(shí)是包含BDD（Behavior Driven Development）、EDD（Example Driven Development），F(xiàn)DD（Feature Driven Development）、CDCD（Consumer Driven Contract Development）等各種的實(shí)踐方法。
比如以軟件的行為為驗(yàn)收標(biāo)準(zhǔn)，這個(gè)是BDD；如果以特定的實(shí)例數(shù)據(jù)為驗(yàn)收標(biāo)準(zhǔn)，這個(gè)是EDD；如果以Web Service API消費(fèi)者提出API契約來(lái)驅(qū)動(dòng)API提供者開(kāi)發(fā)API，這個(gè)是CDCD等。所以ATDD的具體實(shí)現(xiàn)需要結(jié)合項(xiàng)目的實(shí)際情況來(lái)選用適合的驗(yàn)收測(cè)試方法與類(lèi)型。
UTDD（Unit Test Driven Development）：?jiǎn)卧?qū)動(dòng)測(cè)試開(kāi)發(fā)，首先Dev編寫(xiě)單元測(cè)試用例，然后編寫(xiě)實(shí)現(xiàn)代碼直到單元測(cè)試通過(guò)。這個(gè)就是現(xiàn)在很多人所謂的TDD、實(shí)踐的TDD、喜歡的TDD、抱怨的TDD，但是它卻只是真正意義上TDD的一部分而已。）
11 . 原型和線框圖（wireframes）被廣泛用于什么的一部分？
原型和線框圖都是原型，被廣泛用作經(jīng)驗(yàn)設(shè)計(jì)的一部分。
12 . 解釋什么是應(yīng)用二進(jìn)制接口？
在不同的系統(tǒng)平臺(tái)和環(huán)境中，以二進(jìn)制形式定義應(yīng)用程序可移植性要求的API規(guī)范稱為應(yīng)用程序二進(jìn)制接口。
13 . 解釋敏捷中的燃盡圖，包括burn-up chart 和 burn-down chart？
為了跟蹤項(xiàng)目進(jìn)度的開(kāi)始和結(jié)束，使用這些圖表。
burn-up chart（燃起圖）：它顯示了隨著時(shí)間的推移，故事開(kāi)發(fā)的進(jìn)展?fàn)顟B(tài)。
burn-down chart（燃盡圖）：顯示還有多少工作要做。
14 . 解釋什么是Scrum ban？
Scrum ban是一個(gè)基于Scrum和看板的軟件開(kāi)發(fā)模式。它專門(mén)為需要頻繁維護(hù)的項(xiàng)目而設(shè)計(jì)，經(jīng)常會(huì)遭遇預(yù)料不到的用戶故事和程序錯(cuò)誤。使用這些方法，團(tuán)隊(duì)的工作流程將以每個(gè)用戶故事或編程錯(cuò)誤的最小完成時(shí)間為導(dǎo)向。
15 . 什么是故事點(diǎn)/投入/標(biāo)度（points/efforts/ scales）？
它用來(lái)討論沒(méi)有分配時(shí)間的故事的難度。最常見(jiàn)的標(biāo)度是斐波那契序列（1, 2, 3, 5, 8,13，...，100），不過(guò)有些團(tuán)隊(duì)使用線性標(biāo)度（1, 2, 3, 4 ...），2的次方（1, 2, 4, 8 ......）和衣服尺寸標(biāo)度（XS，S，M，L，XL）
16 . 解釋什么是曳光彈（Tracer Bullet）？
曳光彈是當(dāng)前架構(gòu)的Spikes，是當(dāng)前最好的一套實(shí)踐，是當(dāng)前生產(chǎn)質(zhì)量代碼的技術(shù)集合。它不是一段扔掉的代碼，但可能僅僅是一個(gè)粗糙的功能實(shí)現(xiàn).
17 . 什么是測(cè)試Stub？
測(cè)試Stub是一個(gè)少量代碼的模塊，它可以替代被測(cè)系統(tǒng)中未開(kāi)發(fā)或完全開(kāi)發(fā)的組件。測(cè)試Stub被設(shè)計(jì)成通過(guò)產(chǎn)生特定的已知的輸出并且替代實(shí)際的組件這樣一種方式。
18 .統(tǒng)一過(guò)程(Rational Unified Process)和Scrum方法有什么區(qū)別？
19 . 為什么持續(xù)集成對(duì)敏捷很重要?
持續(xù)集成對(duì)于敏捷來(lái)說(shuō)很重要，因?yàn)橐韵略颍?br>
● 通過(guò)發(fā)現(xiàn)缺陷或集成錯(cuò)誤，可以幫助保持及時(shí)發(fā)布產(chǎn)品。
● 由于頻繁的敏捷代碼交付，通常每個(gè)迭代（sprint）是2-3周，穩(wěn)定的構(gòu)建質(zhì)量是必須的，并且持續(xù)集成確保做到這一點(diǎn)
● 幫助維護(hù)代碼庫(kù)的高質(zhì)量狀態(tài)（bug很少）
● 如果開(kāi)發(fā)工作使用自動(dòng)構(gòu)建和合并功能，則持續(xù)集成有助于檢查工作分支對(duì)主干的影響。
20 . 在敏捷過(guò)程中進(jìn)行了哪些測(cè)試?
在敏捷過(guò)程中，主要的測(cè)試活動(dòng)是自動(dòng)化單元測(cè)試和探索式測(cè)試。
但是，根據(jù)項(xiàng)目的需求，測(cè)試人員可以在被測(cè)應(yīng)用(Application Under Test，AUT)上執(zhí)行功能測(cè)試和非功能性測(cè)試。
21 .解釋敏捷中的速度（Velocity）是什么?
速度是一種度量，是根據(jù)在迭代中所完成的用戶故事相關(guān)的各種努力來(lái)估算出來(lái)的。它計(jì)算出在敏捷的一個(gè)迭代中可以完成多少工作，以及完成一個(gè)項(xiàng)目需要多少時(shí)間。
22 . 優(yōu)秀的敏捷測(cè)試人員應(yīng)該具備哪些素質(zhì)?
優(yōu)秀的敏捷測(cè)試人員應(yīng)該具備以下素質(zhì)：
● 能夠很快地理解需求
● 敏捷測(cè)試人員應(yīng)該了解敏捷原則和概念
● 隨著需求不斷變化，測(cè)試人員應(yīng)該了解其中的風(fēng)險(xiǎn)
● 基于需求，敏捷測(cè)試人員應(yīng)該能夠?qū)ぷ鬟M(jìn)行優(yōu)先級(jí)排序
● 業(yè)務(wù)伙伴、開(kāi)發(fā)人員和測(cè)試人員之間的持續(xù)溝通是必須的
23 . 誰(shuí)都參與了敏捷團(tuán)隊(duì)?
在敏捷中，兩個(gè)主要的領(lǐng)導(dǎo)者是：
● Scrum Master: 協(xié)調(diào)敏捷項(xiàng)目流程所需的絕大部分輸入和輸出
● 開(kāi)發(fā)經(jīng)理: 他們雇傭合適的人，并與團(tuán)隊(duì)一起培養(yǎng)他們。
24 . 詳細(xì)地描述Scrum Master 這個(gè)角色起什么作用?
Scrum Master的主要職責(zé)包括
● 了解需求并將其轉(zhuǎn)換為可工作的軟件
● 監(jiān)控和跟蹤
● 報(bào)告和溝通
● 過(guò)程檢查大師
● 質(zhì)量大師
● 克服障礙
● 解決沖突
● 保護(hù)團(tuán)隊(duì)和績(jī)效反饋
● 領(lǐng)導(dǎo)所有會(huì)議，消除障礙
25 . 提到敏捷的質(zhì)量策略是什么?
敏捷質(zhì)量策略是：
● 重構(gòu)
● 非單一的（Non-solo）開(kāi)發(fā)模式 （團(tuán)隊(duì)共同開(kāi)發(fā)模式）
● 靜態(tài)和動(dòng)態(tài)代碼分析
● 復(fù)審和審查
● 迭代（sprint）演示
● 全員（all hands）演示
● 輕量型的里程碑評(píng)審
● 短的反饋周期
● 標(biāo)準(zhǔn)和指導(dǎo)方針
26 . 在開(kāi)發(fā)敏捷項(xiàng)目時(shí)，屏幕截圖工具，有什么推薦?
在開(kāi)發(fā)敏捷項(xiàng)目時(shí)，您可以使用類(lèi)似工具：
● BugDigger
● ?BugShooting
● ?qTrace
● Snagit
● ?Bonfire
● ?Usersnap
（每次看到這個(gè)，總覺(jué)得是做工具的廠商在做軟廣）
27 . 在整個(gè)項(xiàng)目中保持一致的迭代周期，有什么好處?
好處是：
● 它幫助團(tuán)隊(duì)客觀地衡量進(jìn)展
● 它提供了一種測(cè)量團(tuán)隊(duì)速度的一致方法
● 它有助于建立一致的交付模式
28 . 如果一個(gè)時(shí)間段計(jì)劃的任務(wù)優(yōu)先級(jí)需要再排序，誰(shuí)應(yīng)該做這件事?
如果一個(gè)時(shí)間段（time-box，可以看作一個(gè)迭代）計(jì)劃需要重新排序（優(yōu)先級(jí)排序），應(yīng)該由整個(gè)團(tuán)隊(duì)、PO和開(kāi)發(fā)人員來(lái)考慮。
29 .提到燃盡圖應(yīng)該強(qiáng)調(diào)什么?
燃盡圖顯示了在時(shí)間段(迭代)結(jié)束之前需要完成的剩余工作。
30 .提到Scrum和敏捷之間的區(qū)別是什么?
● Scrum: 在Scrum中，sprint是開(kāi)發(fā)的基本單位。每一個(gè)sprint后面都有一個(gè)計(jì)劃會(huì)議，在這個(gè)會(huì)議中，sprint的任務(wù)被確定和估計(jì)。在每個(gè)sprint中，團(tuán)隊(duì)創(chuàng)建產(chǎn)品的部分功能特性
● 敏捷: 在敏捷中，每次迭代都涉及到一個(gè)團(tuán)隊(duì)，他們致力于完整的軟件開(kāi)發(fā)生命周期，包括計(jì)劃、設(shè)計(jì)、編碼、需求分析、單元測(cè)試，以及當(dāng)向項(xiàng)目干系人演示產(chǎn)品時(shí)所做的的驗(yàn)收測(cè)試。
簡(jiǎn)而言之，敏捷是實(shí)踐，scrum是遵循這一實(shí)踐的過(guò)程。
31 .提到敏捷軟件開(kāi)發(fā)中所涉及的挑戰(zhàn)是什么?
敏捷軟件開(kāi)發(fā)中涉及的挑戰(zhàn)包括：
● 需要更多的測(cè)試和客戶的參與
● 對(duì)管理的影響超過(guò)了開(kāi)發(fā)人員
● 每個(gè)特性都需要在移動(dòng)到下一個(gè)迭代之前完成
● 所有代碼都必須正常工作，以確保應(yīng)用程序處于工作狀態(tài)
● 需要更多的計(jì)劃
32 .什么時(shí)候不使用敏捷?
在使用敏捷方法之前，您必須提出以下問(wèn)題：
● 功能可以拆分嗎？
● 客戶在那里嗎（客戶可以和我們一起工作嗎）？
● 需求很靈活嗎？
● 時(shí)間限制真的很緊嗎？
● 團(tuán)隊(duì)技能足夠強(qiáng)嗎？
33 . 解釋你如何以一種簡(jiǎn)單的方式來(lái)實(shí)施scrum?
這些技巧可以幫助你在項(xiàng)目中實(shí)施scrum。
● 待辦事項(xiàng)（backlog）（按對(duì)客戶的價(jià)值）排好序
● 了解產(chǎn)品待辦事項(xiàng)各項(xiàng)的大小
● 闡明sprint的需求和持續(xù)時(shí)間，以完成迭代backlog
● 估算團(tuán)隊(duì)sprint工作量，然后將需求分解為任務(wù)
● 協(xié)作工作區(qū)：一個(gè)所有團(tuán)隊(duì)討論的中心，包括計(jì)劃、路線圖、關(guān)鍵日期、功能的草圖、問(wèn)題、日志、狀態(tài)報(bào)告等等。
● Sprint：確保在一段時(shí)間內(nèi)完成一部分功能，然后繼續(xù)下一個(gè)。除非沒(méi)有其他選擇，否則sprint不應(yīng)該中止
● 參加每日的站立會(huì)議: 在會(huì)議上值得提一下，上次會(huì)議取得了什么成果？在下次會(huì)議前取得了什么成果？有沒(méi)有阻礙我們前進(jìn)的障礙？
● 使用燃盡圖表來(lái)跟蹤每天的進(jìn)度。從燃盡圖中，可以評(píng)估是在正常跑道上（正常狀態(tài)）、還是在后面跑。
● 在進(jìn)入下一個(gè)迭代之前完成每個(gè)特性；
● 在sprint結(jié)束的時(shí)候，召開(kāi)一個(gè)sprint（迭代）回顧會(huì)議，展示sprint中的實(shí)現(xiàn)或交付。
34 . 解釋產(chǎn)品路線圖是什么意思?
產(chǎn)品路線圖是指創(chuàng)建產(chǎn)品遠(yuǎn)景的產(chǎn)品特性的整體視圖。
