游戲測試員攻略：如何提高測試工作的效率?(2)

　　哪些是有針對性的?

　　參照上面一段的例子，比如性能、弱網、數據庫、壓力、接口等等測試都是相當有針對性的。

　　第三個問題：對于測試來說，有哪些基本法?

　　在我看來，就一條： 認真負責、勤學心細 。

　　測試過程：持續優化

　　測試過程的優化問題，也可以看作是提升測試效率的一個零散的點。

　　想到這個問題，還是因為這兩天抽時間優化前段時間用python寫的一個分析統計項目工作量的腳本時想到的。

　　最初的這個python腳本，我只是按照想法直接實現了一版，并沒考慮太多結構上的東西，能跑出結果來就挺滿意，中間還解決了郵件發送圖片的問題，當時覺得還是挺有意思的一件事。

　　But,在實際使用的這段時間，我發現項目每進一個新人，我都要改動代碼中非常多的地方，痛苦不堪。于是被迫重新優化一下原來的腳本，當我回過頭去看我最初寫的那個版本，代碼爛的簡直是一坨屎。

　　于是花了一些時間，重新調整結構，把人員變量抽離出來，這樣項目新加人的時候，只需要增加新的變量就好了，不用調整太多代碼。完成這個版本后，覺得已經很好了。

　　但是，又過了幾天，我回過頭再去看調整后的代碼時，發現，還是一坨屎。。。

　　雖然添加人員方便了很多，但是代碼明顯存在很多冗余的地方，這樣當我們查看具體邏輯時，還是顯得很混亂。于是，我又抽時間優化了一版，把可復用的內容都抽象出來，讓代碼邏輯上更清晰一些。

　　整個過程，腳本代碼從一千多行優化到只有六百多行，可見，最初版本的代碼簡直不忍直視。

　　通過修改這個腳本的過程，帶給我的感觸就是，很多事情，做完了并不意味著是一種良好的狀態。當我們在過程之中遇到問題時，還是要嘗試去優化以前的內容。優化也并不意味著是一次完結的事情，可能要反復很多次，總會有更優的解決方案出現。

　　實例化到我們日常的測試過中，會有很多類似的問題。

　　比如我們測試一個功能時，發現了很多bug，以為測試全面了。但是當我們靜下心來再次回顧這個功能時，往往還是能夠發現很多以前沒有測試到的地方。

　　同樣寫用例也是如此，哪怕功能需求沒變更，等我們寫完之后，再去回顧通篇用例時，還是能夠發現遺漏或冗余的地方。

　　同樣的情況可能會出現在我們日常工作中的很多地方，測試的過程是個持續優化的過程，通過不斷的優化和迭代，可以使得我們的測試工作越來越優秀。

　　最后，補充說明一點，有些事情需要慎重考慮，三思而后行，不適用迭代方式，比如某些決策類行為。有些事情可以通過不斷的迭代來做好，先把事情做完，解決當前面對的問題，再考慮后續的優化，比如日常具體的執行類事務。大家還是要根據實際情況來權衡。

原文轉自： http://www.sykong.com/2016/06/126572