第二部分：方法與實(shí)踐

敏捷測試的實(shí)質(zhì)

測試不僅僅是測試軟件本身，還包括軟件測試的過程和模式。產(chǎn)品發(fā)布后才發(fā)現(xiàn)很多問題，很可能是軟件開發(fā)過程出了問題。因此測試除了需要確保軟件的質(zhì)量，即軟件做了正確的事情，以及軟件做了應(yīng)該做的事情以外，敏捷的測試團(tuán)隊(duì)還要保證整個軟件開發(fā)過程是正確的。

敏 捷測試即是不斷修正質(zhì)量指標(biāo)，正確建立測試策略，確認(rèn)客戶的有效需求得以圓滿實(shí)現(xiàn)和確保整個生產(chǎn)的過程安全的、及時的發(fā)布最終產(chǎn)品。敏捷測試人員因而需要 在活動中關(guān)注產(chǎn)品需求，產(chǎn)品設(shè)計(jì)，解讀源代碼；在獨(dú)立完成各項(xiàng)測試計(jì)劃、測試執(zhí)行工作的同時，敏捷測試人員需要參與幾乎所有的團(tuán)隊(duì)討論，團(tuán)隊(duì)決策。作為一 名優(yōu)秀的敏捷測試人員，他（她）需要在有限的時間內(nèi)完成更多的測試的準(zhǔn)備和執(zhí)行，并富有極強(qiáng)的責(zé)任心和領(lǐng)導(dǎo)力。更重要的是，優(yōu)秀的測試人員需要能夠擴(kuò)展開 來做更多的與測試或許無關(guān)，但與團(tuán)隊(duì)共同目標(biāo)直接相關(guān)的工作。他（她）將幫助團(tuán)隊(duì)其他成員解決困難、幫助實(shí)現(xiàn)其預(yù)期目標(biāo)，發(fā)揚(yáng)高度協(xié)作精神以幫助團(tuán)隊(duì)的最 終獲取成功。需要指出的是，團(tuán)隊(duì)的高度協(xié)作既需要團(tuán)隊(duì)成員的勇敢，更需要團(tuán)隊(duì)成員的主動配合和幫助。對于測試人員如此，對于開發(fā)、設(shè)計(jì)人員，其他成員也是 如此。

?

敏捷測試的方法與實(shí)踐

敏捷團(tuán)隊(duì)組織構(gòu)成，敏捷測試團(tuán)隊(duì)的任務(wù)和使命；

敏捷開發(fā)團(tuán)隊(duì)以測試為驅(qū)動的開發(fā)方式——測試驅(qū)動開發(fā)，這是種獨(dú)特的測試？還是開發(fā)？

遞增型的迭代測試，它首先是對敏捷測試過程活動和生命周期模型的介紹，通過學(xué)習(xí)經(jīng)典的敏捷增量測試模型，我們將敏捷測試的各類活動有機(jī)的組合到了一起。在此之上，對定制后的獨(dú)特敏捷增量測試模型的分析和理解，幫助我們理解測試活動的規(guī)劃和管理；

以 及需要特別關(guān)注的遞增型迭代測試的關(guān)鍵活動之一——“靜態(tài)測試”；這也是筆者認(rèn)為的最高難度、最具影響力的敏捷測試活動。它將測試團(tuán)隊(duì)最早的引入產(chǎn)品開發(fā) 環(huán)節(jié)，測試人員以第一用戶的角度判斷設(shè)計(jì)的有效性，此活動較早的暴露了設(shè)計(jì)缺陷、避免了團(tuán)隊(duì)對目標(biāo)的不一致理解等，是測試活動中最有創(chuàng)造性價(jià)值的部分；

最后，筆者將談?wù)劀y試活動中的測試計(jì)劃和管理，即關(guān)于測試任務(wù)估計(jì)，測試活動計(jì)劃，各個重要測試活動時間分配與安排的介紹。

然而，敏捷測試不是一蹴而就的，做到真正的敏捷，無論是從傳統(tǒng)測試模式向敏捷測試的過渡，還是組建全新的團(tuán)隊(duì)都是需要循序漸進(jìn)的，同時也需要團(tuán)隊(duì)成員的通力合作和不斷的實(shí)踐來完善敏捷測試的實(shí)踐原則和方法。

?

敏捷團(tuán)隊(duì)

筆者曾共事的整支產(chǎn)品開發(fā)團(tuán)隊(duì)被劃分成 4 個相對獨(dú)立的敏捷開發(fā)隊(duì)伍，而每支隊(duì)伍擁有相同配置的 7 名成員，他們分別具有不同的職能屬性。

每支敏捷隊(duì)伍組成成員角色包括：

1 名 UCD（User Centered Designer），主要負(fù)責(zé)產(chǎn)品的主要設(shè)計(jì)，其工作主要包括界面設(shè)計(jì)、用戶的用例設(shè)計(jì)等等；

1 名 Visual Designer，主要負(fù)責(zé)產(chǎn)品界面的色彩搭配、控件的外觀設(shè)計(jì)和 UCD 界面設(shè)計(jì)方案的初步實(shí)現(xiàn)和美化；

1 名 Information Developer，主要負(fù)責(zé)產(chǎn)品中信息的編輯和重要文檔的撰寫工作；

3 名開發(fā)人員，主要負(fù)責(zé)產(chǎn)品的實(shí)現(xiàn)；

1 名 Tester，主要負(fù)責(zé)產(chǎn)品質(zhì)量的保障。

4 支敏捷的隊(duì)伍擁有相同的 SCRUM MASTER STAKEHOLDER。通常會在同一時間進(jìn)入一個迭代周期，制定各自的敏捷計(jì)劃，并在同一時間退出，發(fā)布各自功能實(shí)現(xiàn)。而 4 支隊(duì)伍的勞動果實(shí)被集成到一起就形成了可發(fā)布的產(chǎn)品了。

因?yàn)槊艚輬F(tuán) 隊(duì)中只有 1 名測試人員，因此需要一臂承擔(dān)測試策略的制定，測試計(jì)劃，測試腳本，測試用例設(shè)計(jì)以及測試的執(zhí)行，幫助團(tuán)隊(duì)發(fā)現(xiàn)潛在問題，并協(xié)助解決問題的工作。敏捷團(tuán)隊(duì) 的敏捷原則也是測試人員敏捷活動的規(guī)范，測試也需要擁有和團(tuán)隊(duì)的良好溝通，高度迭代的活動和不斷的獲得 STAKEHOLDER 的反饋。那團(tuán)隊(duì)的結(jié)構(gòu)與敏捷本身有什么直接關(guān)系呢？與敏捷測試又有多少關(guān)聯(lián)呢？

?

敏捷原則告訴我們敏捷團(tuán)隊(duì)是高度協(xié)同、民主和平等的團(tuán)隊(duì)，為了讓團(tuán)隊(duì)中每個人充分高效的工作。相同職能下的組員至多不好超過 3 名，最佳配置也是不同職能下配置 1 個人頭。因此、在這樣一個小型、平行的組織結(jié)構(gòu)里，溝通更加易于建立，溝通復(fù)雜度也相對較低，相比 17、20 人的團(tuán)隊(duì)組織，溝通的代價(jià)也小很多。相反，很難想象在一個敏捷團(tuán)隊(duì)中會擁有諸多不同風(fēng)格的執(zhí)行者，決策者將是個怎樣的混亂情況。

?

此外，經(jīng)歷過敏捷測試的體驗(yàn)，我們發(fā)現(xiàn)一個單一的敏捷團(tuán)隊(duì)最好保持較小的“尺寸”。這是因?yàn)閾碛泻芏鄿y試人員的敏捷團(tuán)隊(duì)通常不但需要更大的實(shí)際工作量來匹配龐大的機(jī)體而導(dǎo)致團(tuán)隊(duì)任務(wù)量更巨大，更復(fù)雜，失去自我管理的信心，而每個測試人員也將要花費(fèi)大量精力和時間投入到內(nèi)部溝通，和可能因?yàn)閮?nèi)部缺乏一致而導(dǎo)致的更加頻繁的反復(fù)溝通中。

每名敏捷的 測試人員需要和其他敏捷團(tuán)隊(duì)成員保持頻繁而必要的溝通以保證對目標(biāo)，需求、設(shè)計(jì)的充分正確的理解，對需求變化能夠迅速的做出反應(yīng)。另外，還需要與職能隊(duì)伍 中的其他測試成員保持一致性。如此一來，溝通代價(jià)激增了，它將占到測試人員的工作中的較大比例。而這種內(nèi)部溝通、協(xié)調(diào)，卻不能定義為敏捷的 Backlog 項(xiàng)目來計(jì)入團(tuán)隊(duì)整體的工作輸出。因此，整體的測試效率并不一定隨著人力資源的投入而遞增。非但沒有實(shí)現(xiàn)敏捷原則，而恐怕因?yàn)閳F(tuán)隊(duì)的組織結(jié)構(gòu)變得更加龐雜。 所謂的“自我管理、自我發(fā)展”的團(tuán)隊(duì)只能因而依靠傳統(tǒng)的管理和規(guī)劃了。筆者認(rèn)為，除了因?yàn)樘厥怆A段，特殊時期，敏捷團(tuán)隊(duì)需要“聚合”更多資源來一并解決存 在的高優(yōu)先級的體力型問題外，敏捷的團(tuán)隊(duì)?wèi)?yīng)該盡量保持著較小的“尺寸”。

果真項(xiàng)目投 入了很多的人力資源，無論設(shè)計(jì)還是實(shí)現(xiàn)、測試團(tuán)隊(duì)擁有較大的人數(shù)，那么我們應(yīng)該考慮將這樣的團(tuán)隊(duì)可以分得更小些，工作量也相應(yīng)分得更精細(xì)些，直至接近我們 建議的最佳組合。至少我們認(rèn)為要做好敏捷測試，就要確保敏捷團(tuán)隊(duì)中的每一個職能擁有足夠清晰的職責(zé)范圍和一定程度下自由空間和在這個空間內(nèi)的充分授權(quán)。因 此，但從人數(shù)和職能構(gòu)成上，敏捷團(tuán)隊(duì)的構(gòu)成一定是不可忽略的重點(diǎn)。

正像我們前 面提到的，確認(rèn)軟件開發(fā)過程的正確性也尤為重要，因此作為敏捷的測試人員，更要了解敏捷的過程，比如說，測試人員需要幫助 UCD 和開發(fā)人員確定需求的可行性，測試人員要督促開發(fā)人員及時發(fā)布 build，以保障迭代結(jié)果最終能夠在通過足夠的測試后成功發(fā)布等。在 build 發(fā)布后，測試人員要首先驗(yàn)證當(dāng)前迭代的任務(wù)是否已經(jīng)完成，其次才是驗(yàn)證產(chǎn)品功能的正確性。也為了能夠在日后重復(fù)性和體力型勞動中解放出寶貴的時間去覆蓋測 試更加緊要的內(nèi)容，如可用性，全球化等，測試人員需要自動化一部分測試，創(chuàng)新的、靈活的工作。

敏捷團(tuán)隊(duì)是自我管理的團(tuán)隊(duì)，高度協(xié)作的團(tuán)隊(duì)，質(zhì)量目標(biāo)即是測試團(tuán)隊(duì)也是整個開發(fā)團(tuán)隊(duì)追求的目標(biāo)，因此開發(fā)團(tuán)隊(duì)?wèi)?yīng)將做好單元測試，設(shè)計(jì)團(tuán)隊(duì)將幫助測試團(tuán)隊(duì)設(shè)計(jì)好測試用例作為計(jì)劃內(nèi)的一項(xiàng)工作。這里我們推廣、建議開發(fā)人員采用、普及測試驅(qū)動開發(fā)模式。

測試驅(qū)動開發(fā)

測試驅(qū)動開 發(fā)表現(xiàn)出迭代開發(fā)的最核心的就是開發(fā)人員自己能夠第一時間確認(rèn)其需求得到了正確實(shí)現(xiàn)，而當(dāng)單元測試覆蓋了更多的內(nèi)容，代碼質(zhì)量也將得到提高。測試驅(qū)動開發(fā) 的指導(dǎo)思想就是讓開發(fā)人員在編寫功能代碼之前，先根據(jù)需求編寫測試代碼。先思考如何對將要實(shí)現(xiàn)的功能進(jìn)行驗(yàn)證，并完成單元測試腳本的編寫，然后編寫足夠， 僅僅足夠的功能代碼滿足這些測試用例，直至通過測試。按照這個方法，遞增的在迭代中增加新功能的單元測試和功能代碼編寫，直到完成全部功能的開發(fā)。

在單元測試 活動中，測試人員也被鼓勵參與到單元測試的設(shè)計(jì)中來，不但可以幫助開發(fā)人員構(gòu)思出更多的單元測試用例來擴(kuò)大單元測試的覆蓋率，還可通過學(xué)習(xí)如何使用單元測 試，如何復(fù)用單元測試用例到回歸測試和功能測試，以達(dá)到最大化利用有效的資源（如下圖）和節(jié)約成本的作用。同時，在回歸測試和用戶接收測試（User Acceptance Test）中如能將單元測試腳本有機(jī)的關(guān)聯(lián)起來，并自動化其執(zhí)行，更能夠進(jìn)一步提高測試的成效并降低測試成本。

單元測試腳本因隨需求、設(shè)計(jì)的變化隨時更新。需要開發(fā)人員站在全局的立場，開發(fā)始終堅(jiān)持先修改測試腳本，再修改產(chǎn)品原代碼。此時，也建議測試人員參與單元測試腳本的改進(jìn)，幫助開發(fā)人員合理的變更單元測試腳本，同時著手修改測試計(jì)劃和測試策略。

靜態(tài)測試

一個好的測 試人員能夠第一時間找到需求分析、設(shè)計(jì)中的模棱兩可，遺漏，錯誤的地方，能夠促進(jìn)團(tuán)隊(duì)前期工作的高效完成，將很大程度降低將來產(chǎn)品的質(zhì)量缺陷的數(shù)量，積極 影響了敏捷開發(fā)的最終輸出。這部分工作是測試團(tuán)隊(duì)，開發(fā)、設(shè)計(jì)團(tuán)隊(duì)最默契合作的階段，交流非常頻繁，正是通過積極的溝通和及時的修正與團(tuán)隊(duì)目標(biāo)“誤差”使 得團(tuán)隊(duì)更加明確其方向，更有凝聚力和也得以發(fā)揮了團(tuán)隊(duì)的最佳戰(zhàn)斗力。在筆者的項(xiàng)目經(jīng)歷中，往往這個階段會需要一個迭代周期 1/4 左右的時間。這同時也說明了靜態(tài)測試在敏捷測試類型中的重要性。

在敏捷開發(fā)過程的靜態(tài)測試即項(xiàng)目迭代開發(fā)前期測試人員的最主要工作。值得再次強(qiáng)調(diào)的是，在這段時期測試人員的工作重心是認(rèn)真了解需求和用例設(shè)計(jì)，并針對設(shè)計(jì)的可行性，可用性進(jìn)行驗(yàn)證，確認(rèn)設(shè)計(jì)是對需求的準(zhǔn)確實(shí)現(xiàn)，最佳實(shí)現(xiàn)。

測試人員應(yīng) 該領(lǐng)導(dǎo)團(tuán)隊(duì)幫助明確出用例更多的細(xì)節(jié)。比如，在一次設(shè)計(jì)用例討論中，設(shè)計(jì)者提出“我需要一個 Overlayer”。那么測試人員應(yīng)該要問：“如何打開這樣一個 Overlayer，如何關(guān)閉？”“這個 Overlayer 需要多大平面尺寸，是否支持調(diào)整，是否支持對屏幕大小的自動適應(yīng)”，“Overlayer 的打開和關(guān)閉是否需要有動態(tài)漸變的效果？”，“Overlayer 的是否需要滾動條？”，等等。

這個過程能夠幫助團(tuán)隊(duì)發(fā)現(xiàn)早期的設(shè)計(jì)缺陷，通過發(fā)現(xiàn)問題，并定制新的設(shè)計(jì)方案，團(tuán)隊(duì)也通過這個過程，更好的了解了測試的重要性，也摒除了可能存在的對需求的種種“假設(shè)”，因而更加明確了團(tuán)隊(duì)的目標(biāo)和方向。這是個非常關(guān)鍵的過程。尤其是對測試人員而言，任何“假設(shè)“都是有害的，所以一定需要把不清楚和模棱兩可的問題從一開始就理清楚。

轉(zhuǎn)載于:https://www.cnblogs.com/zyp1/p/5765472.html

總結(jié)

以上是生活随笔為你收集整理的敏捷的最佳实践-2的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。