專案測試過程中我們的任務也許僅僅只是找出bug，但是對於bug產生的本身可能並不關心，因為績效考核只關心bug的質量和數量，所以使得我們測試人員的眼光變得很狹隘，甚至可以說是膚淺。最近在接手乙個專案測試任務時，發現我們的工作是如此的單調，而且不愉快，原因在哪兒呢，大家一致總結是因為沒有需求，或者說有需求但是不明確，可能是由於習慣性的軟體開發流程將我們套牢了，測試總是變得很被動，而且必須只能從需求入手才能開展測試，但事實證明，需求也有太多的不合理，因為當需求變得沒有依據時，我們還能指望誰呢？
很久沒有對理論性的東西進行**了，這次專案測試中讓我深有體會，理論不只是理論，我們應該如何正確理解這些個理論和流程，習慣性被接受，還是不斷地去思考，我想可以更理性一些，畢竟工作不只是為了工作，而是為了更好的工作。如何更好的開展工作，就需要我們通過各種辦法來改善我們的工作。測試工作確實很枯燥，可能並是所有的人都這麼認為，至少我也不這麼認為，因為我總是在想辦法讓我的測試工作更簡單，更高效，比如研究自動化，再比較多去了解學習一些測試工具，通過等等這些元素的攝入，我們也會驚嘆原來工作可以這樣來完成，因為這樣更有技術含量，作為乙個技術行業的人員，還有什麼能比技術更吸引你的，除非你確實不是乙個安心搞技術的人。再回到專案測試過程中，我們習慣來按照流程來工作，但是在流程不完善的情況下，我們如何開展呢，對於測試工作來講，比較多見的就是沒有需求，因為開發人員對需求很明白，不過都在他們腦子裡，但最後產品上線了，使用者反饋的卻是這麼功能是幹嘛用的，為什麼少了這個那的的？質問測試人員？我想我回答不了，我只能說我的需求**於開發，因為他們說改就改，說不改就注釋說這個板塊可能不要，或者不重要，使用者不怎麼用，太多理由了，也許大家都很痛苦。但這裡我只想說一點，我們的設計是怎麼來的呢，我們的架構是怎麼來的呢？這些個設計是合理的嗎？記得有一次我問乙個專案組的負責人關於專案架構設計，他反問了我一句什麼架構，搞得我好像比開發還專業一樣，然後我還跟人解釋了半天，後來人就給我發來網路拓撲圖，我也只能接受，因為追問幾次人家都不耐煩了，這就是我們的專案開發負責人，就連他們都沒有設計階段的產物，還能指望下面的開發人員有設計方案嗎？當然很佩服他們，最後產品也如期能提交上來，痛苦就留給測試人員來斟酌吧，畢竟各負其責，因為產品不合格，測試也是要負責任的。當然我們也有接到過一些設計實物，那就是，基本都是ps的，然後隨便貼出在一些文件上加以說明，這就是所謂的設計方案，甚至可以說代替需求文件，我想要開始習慣這些了，因為他們準備繼續這個幹，更可笑的是，開發出來的產品還跟ps的方案不一樣，我簡直不能想象設計可以這樣做。當然這只是描述我們實際工作中經常碰到的一些問題，以次可以想想我們的測試工作是何等被動，又豈能說有成果。
通過幾次這種痛苦的磨練，我開始懷疑我們是否還需要如此被動的開展我們的測試流程，因為都被開發搞的焦頭爛額了，更是被需求忽悠無法容忍了，不過什麼樣的環境我們還是得接受下去，只有通過自個卑微的努力去一點一點地去改變和完善我們的流程，畢竟產品的質量不是一天就可以抓起來的。而對於測試過程我還是吸取了不少經驗，對於今後的專案管理我也有我個人的一些收穫，這些都是痛苦的教訓。以前我很不理解還有測試架構師這個職位，前段時間看過一篇關於軟體設計師與測試架構師的pk，讓我深有體會，測試架構師是什麼角色，這個角色的重要性，正如我今天所碰到的這些問題，如果乙個專案中有這樣的角色，那測試過程將更加完美。測試架構師與軟體設計師的pk就好象測試人員與開發人員的pk，但是從技術含量的角度，軟體設計師和測試架構師可能更容易達成一致，因為產品在設計階段的問題是至關重要的，一般能成為測試架構師，我想水平也肯定不是一般的，所以說如何讓測試人員參與軟體設計，並不只是乙個形式，在沒有測試架構師指導的情況下，測試人員參與軟體設計是絕對有利於軟體設計的，因為很多時候軟體設計本身就沒有依據可言，就需要測試人員扮演使用者的角色來對設計進行測試，提出意見之後達成有效的共識。
如何讓軟體測試人員發揮最大價值
對於軟體測試員 有的公司叫qa或質量控制員 而言，在不同的公司文化或體制下，往往對自己的職責或定位都會存在很大的差異，導致軟體測試員，甚至是公司管理員都存在疑惑 軟體測試員是否真的有存在的必要？如何才能發揮他們的最大價值？什麼是軟體測試的目的？問題不是很簡單嗎？但是，我相信仍然有不少人都不一定能夠答...
自動軟體設計
在1973年，美國人peter freeman在他的文章 自動軟體設計 automating software design 中有這樣的假設 如果有這樣一台機器 當我們告訴它我們需要什麼軟體的時候，它立刻就會滿足我們的要求，自動生成我們需要的程式。這台機器我稱之為萬能機。當我們提出需求的時候，需要關...
軟體設計原則
開閉原則 ocp 軟體設計的最大原則 這個原則說的是 對擴充套件開放，對修改關閉。其實意思是說，給系統新增新的功能，但不修改原有 如果能做到呢，關鍵在於抽象化，也就是封裝變化，抽象層不變，讓具體實現依賴抽象隨需求變化。使得系統具有很強的擴充套件性和可維護性。黎克特制代換原則 任何基類可以出現的地方，...