最近參與兩週測試的工作，和測試的夥伴學習，瞭解測試的流程，看看有什麼可以改進的地方。除了流程方面的東西，我想從開發的角度講講，如何才能做的更好。希望以後在和測試溝通的過程中，能少一些阻礙，多一點順暢。
開發即測試
- 質量不是被測試出來的
- 開發人員對自己的代碼負責
- 比專職的測試人員更適合測試
- You build it, you beak it, your fix it.
- 質量是開發過程的問題，而不是測試問題
- 責任在開發，而不是測試
質量肯定不是被測試出來的，而是開發者對代碼的質量負責。由於開發對自己的代碼非常熟悉，對代碼的業務邏輯熟悉，對代碼可能拋出的異常熟悉，因此還有誰比實際寫代碼的人更適合做測試呢？你自己寫的代碼，你自己找到漏洞，然後修復它。
測試不是獨立隔離的活動，它本身就是開發過程的一部分。在我們日常開發的過程中，就應該時刻測試。如果某個產品出了問題，第一個跳出來的肯定是導致這個問題發生的開發人員，而不是遺漏這個bug的測試人員。如果有質量問題的話，大家一般會說開發寫的真爛，而不是測試測的真爛。代碼質量就是編程人員的聲譽。
提升開發質量的工具
- 基本功能測試
- 代碼評審
- 靜態代碼分析（IDE、SonarLint、FindBugs）
- 單元測試
- 基礎性能測試（頁面響應速度、SQL執行、接口響應時長）
- 持續集成
實際開發中，有很多工具可以幫助我們避免一些問題。
正常情況下，大家都會把基本功能測通，然後提交代碼。不正常的情況下，就不會測試，直接提交了。哪些不正常的情況呢？最常見的應該就是改動很少的情況。有時候只是添加或者修改一個字段，或者只是多了條件判斷之類的修改。非常有信心，肯定不會有問題，再加上測試需要造數據，可能還需要啓動多個服務，就懶得測試了。然後提交，後來一測試，就發現了問題。
代碼評審很重要。通過代碼評審，可以避免一些明顯的邏輯錯誤，可以更加規範代碼，提高代碼質量。我們工作很大一部分就是編程，而代碼評審就是拿代碼溝通，相互學習的絕佳途徑。
代碼評審還可以指導新人，對不熟悉項目代碼結構的新人有很大的幫助，而且也能幫助他們熟悉一些業務邏輯。
哪些代碼最需要評審呢？
第一人寫的新模塊，因爲之後要是有相同的模塊，可能直接就複製這個模塊，然後再修改。因此，需要仔細評審新模塊的代碼結構、規範、功能，甚至是日誌。
剛入職的新人開發的功能，需要評審。因爲他們對業務或者代碼結構還不熟悉，可能在開發過程中忽略一些要注意的點。通過這個評審，也可以增加新人對代碼和業務的熟悉度。
核心的邏輯需要評審。有些業務邏輯比較複雜，或者設計到線程安全的問題。可能自己心裏都沒譜，那就需要拿出來讓大家一起看看啦。
而且很多時候，給大家講自己代碼的過程中，很可能自己就發現可以優化的地方。在開發過程中，需要有優化的地方，但自己懶得修改，比如說剛開始寫了一個很長的方法，懶得拆分。在代碼評審的時候，就不好意思了。
開發這麼多工具，又要自己保證代碼的質量，那是不是就不需要測試了？肯定不是這樣啦，我們就來看看測試的必要性。
測試的必要性
- 開發總會有疏忽和失誤
- 開發和測試的側重點不同
- 開發和測試的範圍不同
- 未經測試也不可能開發出有質量的軟件
首先，開發總會有疏忽和失誤，而這些疏忽和失誤，就需要測試去發現和彌補。另外，我們開發的大部分精力在代碼質量的提升和測試覆蓋率的增加上面。而測試應該花費大量時間在模擬用戶的使用場景和自動化腳本的編寫上。在用戶模擬的場景上面，他們會考慮更多更全面。
而且他們測試的範圍，比開發更廣。可能在開發的過程中，我們只是測試自己的開發的某個模塊，而他們測試是整個軟件的所有模塊，甚至是多個組件，多個系統之間的聯合測試。還有安全測試，防攻擊測試，邊緣測試等。
在他們範圍更廣，深度更深的測試下，才能保證整個系統的穩定運行。所以說，未經測試也不可能開發出有質量的軟件。
既然需要有測試，接下來就來看看測試的構成。
測試構成
- Test Strategy：比如說應該怎麼完成測試任務，需要進行哪些測試，是否需要進行壓測，安全性測試等等，測試着重點等
- Testing Plan：制定測試計劃，包括測試時間，測試需要的人員，測試用例，測試報告需要多久才能完成
- Test Cases：測試用例
- Test Data（數據的有效性，影響測試結果的有效性，如果有關聯，更難造數據）
- Test Environment
上面的每個方面，都有很多相關的軟件幫助完成任務。
對開發的要求
- 充分的自測
最後，談一下開發如何做，才能讓測試流程更加順暢？
再次重申，警惕小的修改。萬一bug進入測試階段，就比較耗時耗力了，因爲要經過測試，然後提交給開發，然後開發再去復現，去 debug，然後去解決，提交後測試再次進行測試。
Leaving obvious bugs in the code isn’t going to do your reputation any good either. “A developer who doesn’t find the obvious defects is never going to shine,” continued Markov. “Developers need to produce working software that’s easy to use. No one wants developers that only do pure coding. What helped me to develop my career was the fact that I always invested more time in designing, reviewing, and testing my code than in actually writing it.”
- 文檔是溝通的基礎
文檔是開發和測試溝通的基礎，好的文檔，可以方便溝通，也方便交給其他人維護。要不然的話，只能是一遍遍地口頭闡述，增加溝通成本。我覺得這一點也是最不容易做好的：
- 因爲站在開發的角度寫文檔，可能有些地方很理所當然，然後就沒有在文檔裏面體現。造成文檔不夠詳細，許多過程需要腦補；
- 文檔更新不及時，或者直接從其他地方複製過來的數據，造成不一致；
- 文檔也可以有一定的深度。比如說需要做什麼步驟，最好順帶解釋一下，更方便測試理解業務。
- 日誌是定位的必要
然後是日誌。日誌既不能打印的很詳細，要不然會泄漏系統或者用戶的一些信息，又不能打印的太簡單，要方便定位排查問題。
平常開發的時候，我們直接代碼 debug 排查錯誤，往往忽略了日誌的重要性。其實，我們可以這樣試試看，就是直接看自己寫的日誌，能不能找到問題。
測試在測的過程中，除了看軟件運行是否正常，數據庫是否正常，然後就是看日誌對不對了。
另外，在現場部署的時候，日誌也是非常重要的排查問題的手段。我之前曾經去過好幾次現場部署軟件，有問題的時候，有時候也不太清楚涉及數據庫的哪些表或者涉及哪些字段，要想定位問題，首先就是看日誌。要是看到日誌只有個異常的棧信息，或者就是簡單提示"業務邏輯運行異常”，那真是相當無語。
- 配置文件簡單明瞭
最後再來說說配置文件。目前我們開發的程序，基本上都有配置文件。有些配置文件可能有幾百個配置項。
首先，配置項的作用有註釋麼？這些配置項可以配置哪些內容有提示麼？我覺得配置項要是太多的話，直接整理一個文檔說明每個配置項也很有必要。
另外，看到有幾百行的配置文件也是非常恐怖的，有些配置甚至很少變動。這個時候就要剋制住什麼都想寫到配置文件的衝動。更多的配置，意味着容易犯更多的錯誤。
或者，如果配置太多的話，是否可以考慮將配置文件分類，這種場景下使用 A 配置，那種場景下使用 B 配置。
試想，如果他們看文檔很費勁，需要和開發溝通多次才弄明白。部署的時候，很費勁，那麼多配置文件，也不知道修改哪一個？不知道設置哪些值？
出現問題了，本來可能是數據源的問題，可是日誌不清晰啊，看不出來什麼問題。然後又丟給開發。然後開發看了下日誌，找不到問題，然後默默地去debug，最終發現數據源有問題。
這整個過程中，不僅是測試耗時耗力，開發也需要配合，中斷當前的開發任務。
我想我們可以達到這樣的境界。
測試有哪點不清晰的地方，我們直接說看啥啥文檔。
測試發現一些明顯的問題時，我們可以對自己的代碼質量有把握，說不可能啊，是不是你數據源有問題。
測試發現一些比較潛在的問題時，我們可以通過日誌快速定位到問題。
總之，我們處於測試的上游，只有我們做的好，他們的工作才能做的更好。