今天下午去復旦大學參加了
5etesting
組織的乙個測試人員的交流活動，該活動主要是介紹了
e測中國團隊和他們現階段的乙個專案和產品。其中重點介紹了
qtp專案，活動之前我對
qtp是完全不了解，通過期間的介紹我才知道它是
quicktest professional
的縮寫，是個自動化測試的框架。其實參加這個活動並不是想去了解某個具體的框架，是難得有個這樣乙個測試的人員的聚會，想藉此結識一下更多從事測試工作的朋友，了解他們對測試的看法、體會和經驗。
也是難得能從自己所從事的測試工作中閒暇下來，跳出自己的測試圈子，聽聽別人對實際工程中測試工作的感悟，所以我也利用聽講座的機會反思了一下自己這些年來的測試經驗，簡單總結如下：
1.
在專案開始階段，測試用例不宜太多、太細、太具體，應該隨著專案的不斷深入，逐漸地增加測試用例的數量、覆蓋的廣度和具體程度。
解釋：之所以這樣，是因為專案的初始階段，產品或者專案有太多內容和因素無法確定下來，過多的測試用例只會增加後面維護和修改用例的成本。但往往專案的初期，大家群情激昂躍躍欲試，容易把本可以簡單的工作做的很複雜和過於「精緻」。等到專案做完的時候，再回首專案初期時所做的「精緻」的東東，多半早已被刪減的所剩無幾或者是改動的面目全非。那麼專案的初期的，測試人員應該做些啥呢？多了解專案的背景、使用者的需求，熟悉和改進已有測試框架和流程。
2.對於自動化測試用例而言，其每乙個執行和驗證步驟都應該有詳細的結果輸出到日誌檔案中。
解釋：自動化測試用例在提高測試執行效率的同時，也引入了很多需要人工輔助的地方。自動化測試用例在執行完畢後，需要人工去分析執行的結果，失敗的結果有可能會有比手工測試更多因素造成，包括：產品缺陷、測試框架缺陷、測試用例缺陷、測試執行環境設定問題。沒有詳細的輸出日誌檔案，你很難快速的分析和定位出測試用例失敗的原因。如果每次都需要很費勁的才能分析出測試失敗的原因的話，那引入自動化測試用例的優點何在呢？
3.尋找適合自己專案的手工測試用例和自動測試用例的合理比例關係。
解釋：2:8還是
8:2，或者其它的比例關係。沒有去給自己的專案設定乙個別人的經驗值，多花點是時間研究一下自動化測試在自己專案中的可行性、實現的難度和成本、執行的必要性和可靠性，逐步去摸索得到。理論上自動化測試用例比例越高越好，但如果你的自動化測試框架不穩定、難於開發和維護，那還是越少越好。
4.測試用例更需要注釋，而且是需要更為詳細的注釋，詳細到何種程度呢？應該讓你的手動測試用例描述、自動化測試用例的指令碼或者**足以取代專案經理的產品功能說明。
解釋：認真觀察一下軟體開發從始至終整個過程中產生的各種「副產品」
: 專案需求說明、郵件、詳細設計、開發人員的產品**、測試用例、缺陷描述等等，這其中那些是在隨著產品的開發過程在不斷地更新、始終準確描述了產品的最新功能呢？
應該只有兩個：產品**和測試用例。其它的呢？它們實際上都是匆匆的「過客」，服務於開發過程的某個特定的時間片段，服務於對產品**和測試用例的更新。試想一下你在產品初期編寫的需求，和產品實現完成之後功能還一樣嗎？絕對是不一樣的。而產品**實現了產品功能，但是它的結構複雜，很難從它直接描述出產品的功能。測試用例則不同，其結構工整，組織有序，是天生的用來描述產品的材料。
5.測試工作不只是要測試**，更可以提前到去測試一下專案早期的文件。
解釋：測試人員應該在早期就去測試一下專案早期的各種文件，去讀去想這些文件，發現其中不完善的邏輯、不清晰的描述、混亂的定義、哪怕是錯別字和拼寫錯誤。這樣做是為了能夠更早期發現專案的問題，集思廣益，同時也是讓測試人員更早更深的了解專案。
6.測試人員不應該被手工測試用例或者自動化測試用例限制手腳和廣闊的思路。
解釋：已經寫好的測試用例只能夠幫你覆蓋住已明確的功能和缺陷，無法幫你發現新的產品問題。測試的目的是去發現更多的問題，不要把自己限制在測試用編寫的常規工作中，應該多留些時間去想客戶還會怎樣使用你產品，多些「天馬行空」想象力。
7. 調動測試人員的熱情提高它們在團隊中話語權。
解釋：很多人來做測試並不是真正喜歡，而是因為門檻低，在別無其他可選擇的情況只好做測試了
。在實際的工作中，很多更是只想把測試作為進入這個行業的「驛站」或者「敲門磚」，時刻等待著機會去轉為開發人員或者管理人員。造成這樣的結果也是必然，國內這個行業從對測試人員的認識和待遇就是這樣乙個現狀，多半是道理上把你說的很重要，實際工作中測試人員總是在從屬地位難有真正的話語權，很少能有自發的熱情。所以自然而然的，測試人員也就時刻「居安思危」。
對於乙個公司而言如何來改善這種狀況呢？高層領導的認知很重要；測試過程不要死氣沉沉，多謝
bug bash
和這樣的活動；產品經理
/專案經理
/開發組長等應該注意聆聽測試人員的意見，團隊例會時請給你的
qa優先發言權；加強軟體生命週期工具（如
visual studio team system, ibm rational
等）在測試中的應用，這樣可以增強測試過程的規範性、增加測試成果的可度良性和透明性，避免開發和測試人員之間「用嘴喊」的原始合作方式，用文件
/郵件來記錄發現的產品缺陷、記錄測試用例、測試工作項，只會讓人覺得測試是乙個沒規範、隨機的過程；發現的任何測試本身的問題，如：測試用例缺陷、測試框架缺陷等，也要以同產品
bug一樣對待並記錄下來，由測試人員來修復。
8.減少ui介面測試用例的數量，多一些單元測試和模型測試。
解釋：ui介面測試的框架都還不是很穩定，執行時間長測試結果分析困難。
9.任何測試框架等應該考慮它所依賴的軟體生命週期（alm）管理工具。
解釋：現在的軟體開發更為複雜，更強調協作，單獨的任何工具已經不再適應這樣的需求了，測試工具和框架也是如此，需要喝
alm工具相結合，以促進開發過程不同角色的溝通和協作。
10.單個測試用例的測試步驟不要太多，6/7步足以。
解釋：過多的步驟只會帶來執行、實現和分析的難度。可建立多個小的測試用例，考慮用它們的組合來實現更複雜的測試。
11.軟體產能品的複雜性和多樣性，決定了不可能有一種簡單萬能測試方法和自動化測試框架能聰明到把它們都覆蓋住。
隨便總結了一下，沒想到寫了這麼多。有些還僅是些初步的專案，有待進一步的完善和補充。希望這些個人的測試工作實際體驗能夠給大家以幫助！不早了，
11:00pm
，要休息了！身體是繼續更好測試的本錢！
我的測試生活感悟1
有些天沒有更新部落格了，有的時候想到一些東西，打算把它寫下來時發現時間不夠，有時寫著寫著發現自己開始長篇大論，原本一兩句話可以說清楚的事情，非要用幾個段落來描述。當我看完一本幾百頁的書時，真正記住的原文內容不會很多，通過自己總結，大約可以用10句話來描述。因此，我打算用一種簡潔的 無廢話的方式記錄一...
我對大學的一點感悟
有人說 大學，大學，大致學習一下！也有不少人宣傳 大學是學不到什麼，學的東西在工作中根本沒用，重要的在於能力的培養 等認識。於是不少同學對知識和能力有了錯誤的認識，甚至將它們視為對立的兩個方面而完全放棄了求知，一味追求提高自己的 能力 的確，我們需要通過進學生會，參加各種活動，校外兼職等來提高我們的...
MBTI對我的性格測試
mbti myers briggs type indicator 一種迫選型 自我報告式的性格評估測試，用以衡量和描述人們在獲取資訊 作出決策 對待生活等方面的心理活動規律和性格型別。由美國的心理學家katherine cook briggs 1875 1968 和她的心理學家女兒isabel br...