軟體測試經驗與教訓

1.人工測試的重要性仍是第一位的，儘管現在自動化測試如火如荼的發展著，但很多重大缺陷依然需要通過人工測試的方式才能發現，因為測試策略才是根本，人工測試在這裡充分體現出了其靈活多樣的特性，尤其是有意識的進行探索式測試；

2.乙個經驗豐富，能力較強的只會人工測試的測試工程師的價值肯定大於乙個一般的自動化測試工程師；

1. 如同業務功能測試是測試的基本能力一樣，自動化測試也正在成為測試人員的基本能力；

2.在深刻理解需求的基礎上，自動化測試用例要能體現如同文字測試用例的基本編制要求：「精煉表達、主次分明、漸進可用」；

3.自動化測試的最大用途在於執行回歸測試；

4.對乙個產品/專案能做到80%的自動化測試覆蓋就很不錯了；

test automation pyramid（測試自動化金字塔）

1.ui tests：也稱 gui 測試，穩定度最低，只有長期且比較穩定的產品/專案適合開展自動化ui測試；否則很可能會導致成本大於產出，甚至完全成為花瓶；

2.api tests：介面測試。當下提供的大都是http api，相對穩定，適合自動化測試；

3.unit tests：穩定度最高，開發人員應該採用tdd（test driven development,測試驅動開發），實在不適應也應該有相應的單元測試；

4.在這裡糾正乙個觀點：單元測試是測試人員來寫的。正確的應該是開發人員來編寫，對自己的行為負責！

5. 從上圖中可以看出，單元測試應該占有最大的比例，其次是介面測試，最後才是基於圖形介面的功能測試，可是很多測試團隊都搞反了，所以結果很不理想。

6.個人建議自動化的單元測試也在短期和變化較大的產品/專案中開展；自動化的介面測試在中長期和較穩定的產品/專案中開展。

1.採用tdd或者開發人員編寫單元測試**；

2.採用自動化測試，尤其是自動化的全回歸測試，包括單元測試，介面測試和ui測試；

3.開發提交**到版本伺服器後觸發條件自動取得最新**並自動編譯，編譯通過後自動執行其他指令碼（如資料庫），接下來自動執行單元測試和介面測試，測試通過後最後自動打成安裝部署包。部署到測試環境後再開始自動化的ui回歸測試。

1.有了自動化測試和持續整合這兩個作為前提，經過自動化部署，就可以達到持續交付。

1.堅持實施scrum,雖然會議會占用一定的時間，但這點時間對於團隊成員間的溝通和協調是必不可少的；

2.這世界變化快，編寫敏捷測用例，重點是寫出測試用例的測試點而無需詳細的操作步驟；

3.敏捷測試需要測試人員能夠隨時啟動自動化的回歸測試對馬上發布的迭代**進行快速驗證。

2.web功能以自動化ui測試為主(短期，變化很大的產品/專案除外)，結合探索式測試；

4.web的相容性測試還是人工方式，採用每個迭代內測試不同瀏覽器的方式即可；

6.開展單元測試和介面測試且最好全部實現自動化測試；

7.盡早測試，經常測試，充分測試。