資源描述：
《軟件測試轉(zhuǎn)型之路》由會員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在應(yīng)用文檔-天天文庫。
1、軟件測試轉(zhuǎn)型之路選擇測試之路——路上的迷茫2010年12月31日，在網(wǎng)易從事了多年開發(fā)之后，依依不舍地離開，面臨的是一個(gè)完全從零開始的全新職位：SQA，也就是tester。當(dāng)時(shí)對為什么被選擇做軟件質(zhì)量保證，而不是繼續(xù)在研發(fā)上進(jìn)取，持有保留態(tài)度：憑什么要我轉(zhuǎn)，不是別人？這個(gè)時(shí)候，多年的伙伴、領(lǐng)隊(duì)——雷叔就把我的優(yōu)點(diǎn)暴露出來了：認(rèn)真、心細(xì)、負(fù)責(zé)；好吧，基于以上幾點(diǎn)，只有“我行”，只能給力了。從心底里，對質(zhì)量管理、SQA等概念，我并沒有多想，因?yàn)楦鞠氩涣?，腦子里面沒有太全面的認(rèn)知，即使雷叔講過一些，我還是覺得不夠全面，不知道業(yè)界是如何做的？所以心里多多少少有點(diǎn)擔(dān)心！幾
2、個(gè)人成立一個(gè)新團(tuán)隊(duì)，什么都是從零開始，關(guān)鍵還是要有一些流程，這幾年開發(fā)中也積累了些經(jīng)驗(yàn)，總結(jié)了些問題。在12月底，我提交了《軟件質(zhì)量保證第一季度計(jì)劃》，這個(gè)計(jì)劃后來也成為了整個(gè)質(zhì)量保證體系的核心，大概綱要如下：1.搭建項(xiàng)目管理平臺2.搭建持續(xù)集成平臺3.規(guī)范開發(fā)流程4.制定軟件質(zhì)量保證規(guī)范流程5.建立缺陷管理6.建立風(fēng)險(xiǎn)管理庫、經(jīng)驗(yàn)教訓(xùn)庫（長遠(yuǎn)計(jì)劃）2011年1月25日，苦于沒有規(guī)范的流程，做起事來還是不夠順暢，在奮戰(zhàn)多日之后，制定了《產(chǎn)品研發(fā)質(zhì)保流程手冊》，簡單來說，劃分了：需求、開發(fā)、發(fā)布三個(gè)階段，每個(gè)階段定義驗(yàn)收的產(chǎn)物。為什么要制定這個(gè)？必須有章可依，否則步
3、伐不穩(wěn)健，走的再遠(yuǎn)，也會亂。道路上，難免遭遇坎坷，要不斷提升自己，也有三點(diǎn)切身體會：1.如電影《熱血教練》中卡特教練所說，先把基本功練扎實(shí)了，才能有勝算。既然從零開始，就不要被困惑不已的瑣事所糾纏著，下決心突破，可以研讀：質(zhì)量管理、缺陷預(yù)防、軟件測試、持續(xù)集成等書籍，并且通過互聯(lián)網(wǎng)了解一些公司是如何開展測試和質(zhì)量管理的方方面面。2.個(gè)人價(jià)值迎合團(tuán)隊(duì)價(jià)值，果斷取舍，為團(tuán)隊(duì)利益著想。3.堅(jiān)定信念，避免浮躁，把握遠(yuǎn)景，不要急于尋求成就感。同時(shí)，在調(diào)研期間，我意識到持續(xù)集成很重要，并按照當(dāng)前的需求，重點(diǎn)關(guān)注以下幾點(diǎn)：持續(xù)測試、持續(xù)審查、持續(xù)反饋。圖：早期的開發(fā)、測試流程原
4、型圖無悔選擇測試之路——路上的抉擇、進(jìn)取有了流程規(guī)范，接下來是實(shí)施和持續(xù)改進(jìn)。這些規(guī)范運(yùn)用在一個(gè)項(xiàng)目上，先做了三個(gè)月，不停地測試，編寫功能測試用例，也走了2條彎路：1.用例花了大量時(shí)間編寫，就連打開瀏覽器、輸入xx、點(diǎn)擊登錄，這些也記錄了（這種是早期狀況）。我居然還請纓加入開發(fā)，因?yàn)榭吹揭恍┤蝿?wù)完成不了。后來雷叔也指明，測試做測試應(yīng)該去做的，如果我當(dāng)時(shí)幫忙做開發(fā)，那么很多測試都完成不了，一樣保證不了質(zhì)量。1.所以，測試人員除了要了解業(yè)務(wù)，使用簡單、清晰的語言結(jié)構(gòu)來進(jìn)行測試之外，還應(yīng)該準(zhǔn)確定位自己，明白自己在整個(gè)版本迭代中，控制質(zhì)量的位置！事后想想，那段日子鍛煉了什
5、么？那三個(gè)月無法忘記，每天高強(qiáng)度測試，用的最多的就是：功能測試（邊界值、場景法），白盒測試。其實(shí)就是鍛煉了測試的基礎(chǔ)技能和流程管理。后來測試管理流程逐步建立起來，但是在測試過程中，應(yīng)當(dāng)如何提高代碼質(zhì)量？這個(gè)階段我們參考了敏捷開發(fā)中高質(zhì)量Java代碼開發(fā)實(shí)踐，做了一些適合團(tuán)隊(duì)的改進(jìn)，見下圖：圖：質(zhì)量提升的模式這種迭代版本中java代碼質(zhì)量提升的模式，已經(jīng)采用了將近一年，非常有效。同年Q2，我們對測試管理進(jìn)行了改進(jìn)，其中是受到@段念-段文韜《組織敏捷測試》影響，采用類似“一頁紙計(jì)劃”的測試文檔（在此要感謝@段念-段文韜）在redmine進(jìn)行管理。之前每次整理測試計(jì)劃，
6、發(fā)送給開發(fā)人員，實(shí)際上耗費(fèi)了一些時(shí)間，并且成效不大，現(xiàn)在的任務(wù)：需求、開發(fā)、測試，全部交給redmine管理，所有事情一目了然，對任何人都是可見的，有沒有完成，進(jìn)度如何，非常清晰。為了規(guī)范整個(gè)開發(fā)測試流程的管理，包括開發(fā)、測試的交互，我們又制定了輕量級的SQA框架，見下圖：圖：最初制定的SQA框架不過此后這個(gè)框架也發(fā)生了比較大的變化，做得更好、更輕量級。無獨(dú)有偶，我偶然的機(jī)會買了一本@朱少民老師的：《全程軟件測試》，發(fā)覺這個(gè)SQA框架也是滲透到目前的每個(gè)環(huán)節(jié)，更適合目前團(tuán)隊(duì)的scrum模式，在此也要感謝@朱少民老師，真是相見恨晚，不然可以少走很多彎路?。。〈蠹铱赡?/p>
7、會問：Scrum模式、用戶故事，測試人員怎么利用？為什么想到這個(gè)？如果遺漏了測試場景，團(tuán)隊(duì)會很不爽，怎么避免呢？結(jié)合@Aullyxiao的《軟件測試之魂》提到分層測試的想法，想了想，還可以這么整：圖：分層測試圖對于目前的開發(fā)架構(gòu)來說，一個(gè)用戶故事，涉及這四個(gè)點(diǎn)，可以從這四個(gè)點(diǎn)入手來進(jìn)行質(zhì)量保證。如何做呢？單元測試就開發(fā)人員處理了；代碼審查，測試人員可以參與和監(jiān)督，其實(shí)就是要保證：將開發(fā)任務(wù)與提交到SVN的代碼進(jìn)行關(guān)聯(lián)。這樣一來，當(dāng)測試人員檢查開發(fā)任務(wù)的時(shí)候，就可以找到改變過的代碼。我曾經(jīng)試過從這些代碼里面查看邏輯，找到分支場景，補(bǔ)充到測試用例里面。在此期間，我還看
8、過@架構(gòu)師
