對測試的理解
如果將整個測試流程劃分為四個環節：測試的計畫，測試的設計，測試的執行，測試的評估；那麼需求分
析應該貫徹在前兩個環節，當然有時在測試的執行階段出現一些問題，也需要去重新定位需求，但往往不會
涉及後兩個環節了，測試的執行階段應當完全依賴測試設計的結果，也就是測試用例；而測試的評估當然就
是依賴測試執行的結果：測試用例通過率，缺陷修復率，測試覆蓋率等手段，驗證產品是否可以交付。
測試的設計是整個測試流程的重中之重；而分析需求的能力，決定測試設計的好壞。
測試的設計，第一步應該對未來專案的生產環境有個認知，需求文件中的要求往往不會具體到的每個細
節，有時客戶潛意識中已經預設了一些期待，所以我們除了根據有型的文件，更要進行不斷的溝通，同時也
要考慮資源（財力/人力），來構建我們的測試環境，我認為測試環境的考慮，從功能上說實質是相容性測試
的角度，從效能來說，應當是業務要求的角度（效能方面了解有限）。
http://www.51testing.com/html/90/n-96790.html）文章將測試用例分為三類：step by step, matrix,
automated scrīpts。大多數時候，我們預設的測試用例僅僅是第一種，測試指令碼是基於測試用例的公升級，作
者將指令碼也歸納成測試用例的一種型別，也未嘗不可。
測試人之間經常會討論測試人員需不需要懂開發，如果單純的是作為乙個測試執行者來說，這方面可能
要求不是很高，但作為測試設計者，也就是到了設計測試用例的層面，這問題就不需要回答了。
雖然要求測試人員站在使用者的角度考慮，但不代表僅此而己就夠了，你也應當理解產品的內部是如何工
作的，這有助於你設計出更優秀的測試用例，也就是在測試的執行階段可以最大化的發現缺陷；同時，自己
在設計測試用例時，開發方面的知識可以幫助你去預見一些問題，將他們反饋給開發人員，也許就避免了後
面乙個效能的瓶頸。這裡的價值，可以說彌足珍貴。
除了對於專案的**邏輯要有清晰的思路，同時對於相應的業務領域也要有很好的理解，舉個自身的小
例子最說明問題：網上銀行輸入密碼的鍵盤，其各個鍵的位置是變動的，而我一直不知道，直到開發人員把
這個bug驗證為無效。
在設計測試用例時，首先腦海應該有個架構，應該清楚的知道自己的步驟，注重骨架的劃分，不要急於
去細化到場景。一般來說骨架是以單元功能塊來劃分的，當然需求人員可能已經給你劃分出來，那更好不用
自己操心了。採用功能業務邏輯和**路徑邏輯兩種思路結合去分析，去生成多個的場景；然後對應每個場
景，去制定相應的測試用例；對應每個測試用例，準備不同業務型別的資料，同時再針對每種型別的資料，
靈活的採用黑盒測試方法去劃分出最合理的驗證組合。
好像大部分測試管理工具都很少支援matrix這種型別的測試用例編寫，不過根據功能需求不同，設計的
測試用例也可以採用不同的型別，比如重邏輯輕資料的採用為step by step;輕邏輯重資料的可以採用matrix
。我提到的那篇文章有很好的介紹。
設計測試用例，不是追求其書面結構的好看或者理想狀態下的面面俱到或者盡量來表現編者水平，它的
價值是在接下來的測試執行階段來體現。有時候應該告誡自己，測試用例到了這個粒度已經足夠了。
對 單元測試 UT 的理解
1 單元測試與敏捷開發的衝突點 現在很多公司都推行敏捷開發 與 邏輯不同步的ut沒有意義 而ut 維護是需要成本的 參考 2 從專案的長期角度來看 好的ut對團隊整體開發效率有比較大的提公升，同時可以提高 質量 減少程式缺陷 最大限度地規避線上故障。但過大的ut成本佔比，可能是專案接受不了的。建議 ...
對 委託的執行方法 的測試與理解
今天突然就想知道委託的執行過程是阻塞的還是非阻塞的，於是試了下發現是順序阻塞的 class2 public class class2 console.writeline class2 dowork end class3 public class class3 datetime.now.tolongt...
原創 我對軟體測試這份工作的理解
原創 我對軟體測試這份工作的理解 初入職場也有幾年，到2008年在新公司公升職為測試經理，管理10幾個人的小測試團隊，雖然前幾年工作主要是做為測試工程師，做具體的事 但是後來隨著自己角色轉變，需要帶測試團隊，所以我也經常在思考軟體測試這份工作到底是做什麼？怎麼才能把這份工作做好？怎麼才能獲得更好的職...