軟件測試工作的三個(gè)階段(3)

　　- 有一套自動(dòng)化驗收的用例，可以?huà)旖拥阶詣?dòng)部署之后或者daily build。前提是我們的自動(dòng)化要足夠的問(wèn)題，效果才會(huì )好。

　　這個(gè)階段除了業(yè)務(wù)測試的努力，也體現出了QA的價(jià)值。這里的QA是指質(zhì)量管理，有的地方叫SQA，專(zhuān)注在質(zhì)量度量和研發(fā)流程的管理上。

　　到這個(gè)階段，發(fā)現事情順了很多，質(zhì)量也有更大程度的提升，并有改善額趨勢。

　　第三個(gè)階段：推動(dòng)全面的質(zhì)量提升

　　到上面第二個(gè)階段，我們發(fā)現質(zhì)量有了一定的提升，但是還是有不少的問(wèn)題，而且有些問(wèn)題需要我們把思路和眼界拓寬來(lái)看。這里討論的一些東西可能更適合互聯(lián)網(wǎng)的產(chǎn)品。

　　這里列一些我們可以去做的事情，受限于個(gè)人的經(jīng)驗，可能還很片面。

　　1. 研發(fā)流程的梳理

　　其實(shí)在階段2的時(shí)候也可能有些團隊已經(jīng)開(kāi)始做這樣的事情，因為在分析質(zhì)量和效率問(wèn)題的時(shí)候，我們發(fā)現很多問(wèn)題不單純是代碼的問(wèn)題，可能還涉及研發(fā)流程的很多方面，比如：

　　- 需求不清楚

　　- 跨團隊的配合問(wèn)題

　　- 代碼版本管理

　　- 技術(shù)方面的評審和大家的理解

　　所以整個(gè)研發(fā)流程的規范和梳理，以及配合對應的需求和版本管理的系統也是非常的必要，實(shí)際中發(fā)現效果也是比較的明顯。而且還有一點(diǎn)體會(huì )，在接手一個(gè)很混亂的狀況時(shí)，這樣角度的數量和調整比技術(shù)方案的引入更重要和切中要點(diǎn)，能從40分到60分，技術(shù)是往80分走的過(guò)程效果更明顯。

　　2. 提交測試前后做的一些事情

　　- 代碼的靜態(tài)掃描

　　這個(gè)方法很多的團隊都在做，但是實(shí)際的效果似乎差別很多，而且ROI也很難說(shuō)，不過(guò)從方法本身來(lái)說(shuō)還是值得去做的，對測試人員也提出來(lái)更高的要求。

　　- code review

　　這個(gè)開(kāi)發(fā)應該要做，特別是開(kāi)發(fā)間的交叉review，非常的有幫助。不過(guò)這個(gè)也和自測一樣，取決于開(kāi)發(fā)負責人的態(tài)度。另外，測試也應該去做，特別是對于 diff 代碼的review，我們檢查做了大概兩個(gè)月的時(shí)間，發(fā)現還是非常的有收獲。發(fā)現了一些黑盒難以發(fā)現的問(wèn)題，以及開(kāi)發(fā)的代碼夾帶，并且對于這個(gè)版本影響范圍的評估也更準確。但問(wèn)題是短期會(huì )花費測試更多時(shí)間，以及需要測試人員有一定的技術(shù)能力。

　　3. 測試能力的提升

　　測試階段有很多的事情可以去做，覺(jué)得最主要的還是兩個(gè)方面

　　- 自動(dòng)化。 越來(lái)越覺(jué)得這個(gè)是繞不開(kāi)的話(huà)題，要想盡辦法去做，做得更高效更全面。前面有篇blog也提到了一些輕量級的做法，業(yè)務(wù)測試的團隊可以參考 http://blog.csdn.net/superqa/article/details/20644285

　　- 輔助手段，比如代碼覆蓋率，特別是差異的覆蓋率。這個(gè)大家都比較容易理解就不展開(kāi)了。

　　- 拓展測試的類(lèi)型

　　這個(gè)方面說(shuō)起來(lái)有些泛，需要結合團隊和業(yè)務(wù)的情況，比如安全測試，性能測試，兼容性測試等，去發(fā)現一些對于產(chǎn)品來(lái)說(shuō)很重要的風(fēng)險。

　　這方面有兩個(gè)前提，一是我們的基本功能質(zhì)量到了一個(gè)階段，可以讓大家騰出手去拓展測試的面，另一方面我們測試人員的能力要跟得上。

　　4. 發(fā)布環(huán)節的質(zhì)量把控

　　這個(gè)方面和傳統的測試不太一樣，而且了解到不同的組織做法不同，執行發(fā)布的人員可能不同，有開(kāi)發(fā)，運維，專(zhuān)職的版本管理或者測試來(lái)做。

　　在我們的實(shí)踐中，發(fā)布后來(lái)都逐步收到測試這邊，回頭來(lái)看覺(jué)得還是有不少有幫助的地方。當然也不絕對的必須測試來(lái)做。

　　- DO分離，避免了隨意的發(fā)布，特別是在開(kāi)發(fā)手上的時(shí)候。所有的bugfix都經(jīng)過(guò)測試發(fā)布，可以更準確的度量質(zhì)量(除非這個(gè)問(wèn)題可以不修復，否則肯定要過(guò)發(fā)布環(huán)節)

　　- 知道最近發(fā)了什么，可能的影響是什么，需要線(xiàn)上關(guān)注什么。

　　- 灰度。 互聯(lián)網(wǎng)產(chǎn)品常用的一個(gè)控制風(fēng)險和節奏的手段。

　　- 擴容的快速自動(dòng)化檢查，這方面也依賴(lài)于自動(dòng)化的建設。

　　- 發(fā)布過(guò)程支持灰度的控制，備份和快速的回滾。對發(fā)布系統有一定的要求，而且有可追溯性。

原文轉自：http://blog.csdn.net/superqa/article/details/21485737

• 共5頁(yè):
• 上一頁(yè)
• 1
• 2
• 3
• 4
• 5
• 下一頁(yè)