最近CTO組建了一個(gè)敏捷開(kāi)發(fā)團(tuán)隊(duì)，團(tuán)隊(duì)人員包括? PM、設(shè)計(jì)、開(kāi)發(fā)、測(cè)試角色，主要由PM來(lái)主導(dǎo)團(tuán)隊(duì)走向，因?yàn)橐郧安](méi)有參加過(guò)敏捷開(kāi)發(fā)的經(jīng)驗(yàn)，對(duì)敏捷開(kāi)發(fā)做了簡(jiǎn)單理解后，參考了前人的一些意見(jiàn)，總結(jié)出在 敏捷開(kāi)發(fā)模式下如何更好的進(jìn)行測(cè)試 首先：意識(shí)的轉(zhuǎn)變： 意識(shí)需要從發(fā)現(xiàn)Bug轉(zhuǎn)變?yōu)轭A(yù)防Bug出現(xiàn)， 從越多發(fā)現(xiàn)Bug轉(zhuǎn)變?yōu)樵皆绨l(fā)現(xiàn)Bug 測(cè)試人員應(yīng)該及時(shí)跟上開(kāi)發(fā)和需求人員的腳步，及時(shí)地更新測(cè)試用例，并提醒大家需求的變更是不是超過(guò)了限度，該控制控制了 測(cè)試前期：1.全程參與需求討論，最早在需求討論階段，幫助需求和開(kāi)發(fā)對(duì)需求有正確和共同的認(rèn)識(shí)，例如主導(dǎo)更多的用戶場(chǎng)景、異常等討論 　　　　　2.測(cè)試的用例同樣有優(yōu)先級(jí),針對(duì)性編寫用例（重點(diǎn)） 　　　　　3.對(duì)每個(gè)迭代所要達(dá)到的目標(biāo)爛熟于心， 說(shuō)測(cè)試是貫徹開(kāi)發(fā)始終的 　
測(cè)試中: 1.與開(kāi)發(fā)溝通上又直接交流、靈活應(yīng)對(duì)變化，質(zhì)量控制，什么bug是重要的，什么是可以后期去做，分清bug優(yōu)先級(jí) 2.引入能幫助測(cè)試更簡(jiǎn)便的測(cè)試工具和方法，如自動(dòng)化測(cè)試，可以幫助測(cè)試人員有更多的時(shí)間去探索性測(cè)試 測(cè)試產(chǎn)出：測(cè)試用例、測(cè)試報(bào)告 scrum 測(cè)試團(tuán)隊(duì)的主要職責(zé)是盡早給出質(zhì)量反饋，做到風(fēng)險(xiǎn)前移：
1) 最早在需求討論階段，幫助需求和開(kāi)發(fā)對(duì)需求有正確和共同的認(rèn)識(shí)，例如主導(dǎo)更多的用戶場(chǎng)景、異常等討論
2) 用于測(cè)試的用例同樣有優(yōu)先級(jí)，最高的優(yōu)先級(jí)是“用戶使用最多”以及“最容易發(fā)生bug”的場(chǎng)景交集
3) 縮短測(cè)試時(shí)間，更多使用自動(dòng)化，例如Cucumber、Fitness、Selenium等的使用
4) 測(cè)試工作的過(guò)程和結(jié)果可視化(最后有產(chǎn)出結(jié)果)，方便團(tuán)隊(duì)內(nèi)的溝通
另外，測(cè)試團(tuán)隊(duì)需要有一線工作的意識(shí)：測(cè)試人員需要參加計(jì)劃、估算、執(zhí)行、回顧等與產(chǎn)品交付相關(guān)的任何環(huán)節(jié) 下面是百度、知乎下的各前輩的知識(shí)，十分感謝各位大神的經(jīng)驗(yàn)。 敏捷開(kāi)發(fā)、測(cè)試相關(guān)鏈接（全英文。。。。）：http://www.methodsandtools.com/archive/archive.php?id=88、http://www.ambysoft.com/essays/agileTesting.html 知乎相關(guān)鏈接：https://www.zhihu.com/question/19624692 目的一定要清晰： 測(cè)試人員也需要對(duì)每個(gè)迭代所要達(dá)到的目標(biāo)爛熟于心， 說(shuō)測(cè)試是貫徹開(kāi)發(fā)始終的

敏捷測(cè)試關(guān)鍵成功要素

1.使用團(tuán)隊(duì)整體參與的方法

2.采用敏捷測(cè)試思維（直接交流、靈活應(yīng)對(duì)變化、鼓勵(lì)嘗試新技術(shù)方法嘗試最簡(jiǎn)單的方法來(lái)滿足測(cè)試需要。）

3.自動(dòng)化回歸測(cè)試（自動(dòng)化冒煙測(cè)試、自動(dòng)化單元測(cè)試）

4.提供并獲取反饋。

5.構(gòu)建核心實(shí)踐的基礎(chǔ)（持續(xù)集成、測(cè)試環(huán)境、管理技術(shù)債務(wù)、增量工作、編碼和測(cè)試同一過(guò)程）

6.與客戶合作

7.保持大局觀

敏捷過(guò)程中，測(cè)試的主要職責(zé)應(yīng)該是對(duì)每次迭代的產(chǎn)出物做驗(yàn)證，確保產(chǎn)出物滿足產(chǎn)品設(shè)計(jì)需求，質(zhì)量合格。 1. .需求的把握。測(cè)試要對(duì)不斷變化的需求都能把握住，以PO（product ower）的標(biāo)準(zhǔn)來(lái)要求自己，敏捷的要旨是小步快跑，保證每一步都是對(duì)的，這樣在團(tuán)隊(duì)中就需要有人來(lái)保證我們做出來(lái)的東西是沒(méi)有偏離需求的，這個(gè)角色只有測(cè)試勝任； 2.團(tuán)隊(duì)節(jié)奏的控制。不知道大家有沒(méi)有做過(guò)敏捷項(xiàng)目，迭代不斷的出現(xiàn)延遲，問(wèn)題單越來(lái)越多，大家疲于根據(jù)計(jì)劃加班。這個(gè)時(shí)候我們可不可以把下個(gè)迭代要做的事情暫時(shí)先停下來(lái)，留一個(gè)迭代或者半個(gè)迭代來(lái)解決問(wèn)題，重新讀下代碼，找出那些異味的代碼（smelly code）重寫一下。找找我們流程中的問(wèn)題并改進(jìn)。這個(gè)事情也是由測(cè)試人員來(lái)提出比較合適；

3.質(zhì)量控制。 這當(dāng)然是測(cè)試的傳統(tǒng)的工作，找出問(wèn)題，讓開(kāi)發(fā)人員來(lái)解決。對(duì)于一個(gè)tester來(lái)說(shuō)，質(zhì)量控制Quality Control比質(zhì)量保證Quality Assurence更重要。在敏捷階段，不是說(shuō)發(fā)現(xiàn)的所有問(wèn)題都需要馬上讓開(kāi)發(fā)人員去改，因?yàn)榛蛟S這個(gè)bug對(duì)應(yīng)的需求還不明確，或許下輪的重構(gòu)就能自動(dòng)解決問(wèn)題，或許當(dāng)前這個(gè)迭代使用的技術(shù)解決這個(gè)問(wèn)題代價(jià)太大... 總之，這里是比較靈活的，也是比較考驗(yàn)測(cè)試人員的經(jīng)驗(yàn)的，什么問(wèn)題應(yīng)該馬上解決，什么問(wèn)題可以討論。 4.測(cè)試盡可能去參與集成測(cè)試的，只是這個(gè)過(guò)程對(duì)測(cè)試來(lái)說(shuō)比較痛苦，需要了解代碼，有一定的編碼能力。 5.測(cè)試產(chǎn)出 文檔，測(cè)試分析，問(wèn)題單，測(cè)試需求分析等等。。。 這個(gè)也是和產(chǎn)品的形態(tài)有關(guān)，如果是輕量級(jí)的產(chǎn)品完全不需要做很多事情，或者很多事情可以合并來(lái)做，產(chǎn)出一份文檔或者結(jié)果就可以。 6.關(guān)于自動(dòng)化測(cè)試 第一，在敏捷里面測(cè)試有一個(gè)很重要的產(chǎn)出就是自動(dòng)化測(cè)試，有了自動(dòng)化測(cè)試之后測(cè)試人員有更多的時(shí)間去做探索性的測(cè)試，并且自動(dòng)化測(cè)試能夠給予團(tuán)隊(duì)一個(gè)很好的反饋，你改動(dòng)了代碼之后是否對(duì)系統(tǒng)有影響都能及時(shí)的反饋出來(lái)。第二，測(cè)試團(tuán)隊(duì)對(duì)需求的影響。測(cè)試人員在設(shè)計(jì)測(cè)試用例時(shí)就會(huì)對(duì)用戶的場(chǎng)景和預(yù)期的行為有一個(gè)描述，就會(huì)出現(xiàn)一些產(chǎn)品人員考慮不到的情況，這樣便可以更加完善需求，提升產(chǎn)品的體驗(yàn)和質(zhì)量。

用例：用例一定要全 1，文檔要全，而且要保證質(zhì)量，不過(guò)測(cè)試用例例外，看情況而來(lái)。 測(cè)試人員應(yīng)該著眼于關(guān)鍵點(diǎn)，一個(gè)全面的測(cè)試用例也常常被證明40%以上的用例是徒勞的。根據(jù)經(jīng)驗(yàn)?zāi)軌蚺袛喑瞿睦锸菨撛赽ug、缺陷和主要數(shù)據(jù)流關(guān)鍵點(diǎn)，針對(duì)這些地方寫測(cè)試用例，方便管理也能夠判斷數(shù)據(jù)流階段性的正確。還有就是TDD在開(kāi)發(fā)過(guò)程中的保證，前期的需求討論，測(cè)試人員參與程度應(yīng)比開(kāi)發(fā)人員更高，而系統(tǒng)架構(gòu)確定、軟件架構(gòu)確定，都是由開(kāi)發(fā)和測(cè)試共同決定，并在開(kāi)發(fā)過(guò)程中出現(xiàn)需求變動(dòng)，也保持軟件架構(gòu)的相對(duì)穩(wěn)定，因?yàn)?strong>軟件架構(gòu)的改動(dòng)對(duì)于測(cè)試人員來(lái)講不單單是改動(dòng)，很可能是重新來(lái)過(guò)。 2，這個(gè)不管是不是敏捷的，前期都盡量挖掘客戶的需求，不留下任何潛在的需求。開(kāi)發(fā)過(guò)程中的需求變動(dòng)，根據(jù)經(jīng)驗(yàn)來(lái)說(shuō)，還沒(méi)有遇上過(guò)需求不變的。這個(gè)其實(shí)是很無(wú)奈的，這是由客戶方不夠?qū)I(yè)引起的，這也確實(shí)沒(méi)有辦法，只能是期望變動(dòng)不是翻天覆地的。 3，開(kāi)發(fā)過(guò)程差不多，或者說(shuō)一樣也可以，但敏捷方法對(duì)人員上的控制有一些建議，來(lái)使人員工作效率更高，交流成本更低。在這方面來(lái)講，敏捷對(duì)于人的性格也有要求，不是每個(gè)人都適合參加敏捷開(kāi)發(fā)，在搞人這方面上，敏捷只是提出了一些建議，最佳實(shí)踐還是得根據(jù)公司人員和公司內(nèi)部結(jié)構(gòu)的實(shí)際情況來(lái)定了。

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

總結(jié)

以上是生活随笔為你收集整理的敏捷开发模式下如何更好的进行测试的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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