一些有意義的條目：
1、考慮自動化是否能發現有價值的缺陷，是否經得起時間的考驗，是否值得付出維護費用
2、決定需要測試什么和何時測試
*對于每一個被發現的缺陷，明確的討論它應該在什么時候被發現
3、決定如何測試
*是否有一種特殊的路徑引導人員找到這個缺陷
*這種功能或特許最好用哪種給定的方法來測試
*知道當前已經進行了哪些測試，以及我們目前和將要進行的測試如何才能增加總體測試效果
*發現軟件問題，需要實際用戶在實際的環境中，用實際的數據，去做實際的工作
*簡單重復的工作實現測試自動化
4、測試中最困難的部分是：決定測什么，決定測試的完整性，確認用戶場景等
5、哪些是好的測試，哪些是不好的測試；完成測試后，團隊學會了什么？
測試修行：（很重要）
1、將測試分為兩部分，即“測試今天的項目，準備明天的項目”
*保證當前的測試項目獲得成功
*學習應該做些什么以便下一個測試項目更緊容易
2、警惕重復做一件事情，嘗試能不能自動化
3、思考：
*我們用什么技術找到了那個缺陷？
*我們是否可以創建一種方法來找到更多這類缺陷？
*是否可以記住一些實際的測試經驗并不斷加以應用來提高測試效率？
*軟件的哪些癥狀可以提示我們它有缺陷？
*我們將來能否從那些癥狀中得到更多的警示？
*這個缺陷教會了我們什么？
因而總結一系列的測試技術、建議和工具
4、反思：
*自己的測試流程是否有問題？
*測試流程里有沒有缺陷？
*這里面是否存在妨礙我提高效率的障礙
*例如：
1）收集我們發布給用戶的所有缺陷（特別是安全漏洞或者數據缺陷）：
反思我們是否有流程問題，思路是否有方向性錯誤，或者是否犯了錯誤
2）分析每個缺陷，爭取做到：
停止寫出類似的缺陷；更擅長尋找類似的缺陷；當類似缺陷發生時，該如何識別它們
3）能讓團隊的開發人員、測試人員或者策劃等，知道和明白自己所寫過的每個缺陷
4）將學到的內容整理成文檔，構成已知缺陷的知識體系的基礎部分，也嘗試通過新的方法，或者自動化的方式來預防錯誤
5、當發布每個缺陷時，多問問自己幾個why 和how：
*一開始是什么錯誤導致了這個缺陷？能幫助開發小組建立一套系統知識，來減少錯誤么？
*出現什么樣的失敗癥狀時，能告訴我們現在存在這個缺陷？如何將有缺陷的行為從正確行為中分離出來？
*哪些測試技術可以找到這個缺陷
6、學會使用工具，和掌握信息，了解信息如何影響測試
*來自應用程序的信息，包括：需求、體系結構、代碼結構、源代碼、程序執行時做了哪些事情的運行信息
*確認代碼更新或缺陷修復時，哪些測試會受到影響
對自己的訓練：
1、理解軟件：
*軟件可以做什么？本意是什么？
*它使用哪些外部資源來完成任務？
*它的的主要行為是什么？
*它如何和環境交互？
2、理解軟件故障：
*是否存在某些編程習慣或者程序語言特別傾向于導致這種類型的故障
*這些特定的故障是否可能出現在某些特定類型的軟件行為中
*這些特定的故障是如何使自己顯示為失效的
3、理解軟件失效：
*為什么軟件失效
*軟件如何失效
*是否有軟件失效的癥狀可以揭露我們的應用程序的健康狀況
*某些功能是否有系統問題
*我們如何迫使特定的功能失效
自我總結：
1、記錄測試完整性的部分
*測試用例的執行情況
*測試用例的覆蓋面
*版本更新情況和用例維護情況的對比
*版本復雜度和重要性，與用例的覆蓋的對比
2、考慮哪些可以用圖形來表示：
*測試了哪些，哪些沒測試
*測試的功能模塊的復雜度
*功能模塊內部的依賴關系和外部的依賴關系
*哪些需要重點測試
*測試了的部分的完成度，特別是針對重點模塊的
3、找出軟件缺陷的能力，需要同考慮如何減少軟件中的錯誤結合起來，這樣的能力才是真正的有意義。（回顧起來這也是我以前做的很不好的一點）
*想起以前看到的一個有意思的觀點是：
“軟件測試的真正價值并不體現在代碼中找到多少缺陷，而是發現設計和編程人員解決問題方法上的局限、思路中的狹隘和技能方面的不足。”
PS：我不是自動化測試的fans，也不是人工測試的fans；不相信有包治萬靈的銀彈，但是如果只有一種錘子，那么所有的釘子也會被看成是同一種釘子了！那是悲劇，不是福音！
這些要是都做到了，自己成了專家，同時也可以按照一套體系幫助更多的人一起更好的測試了（hoho）
從新整理了一下思路，發現其實要做的，要改進的東西還很多，需要加油！