在很多測試**的論壇上，這個問題都是津津樂道的熱門話題。而究其根源，主要是因為很多測試人員做不了開發才來做測試，於是其中的很多人便懷著一些「膽怯」心理，與同行反覆**這個問題，期望其他人能夠肯定 「即使不會開發也能做好測試」的觀點，以便在心理上得到一些安慰。
是否需要開發技能與測試人員從事的測試工作種類有極大關係，相信很多人都聽過微軟曾經聘用一名家庭主婦來測試windows作業系統的故事。實際上，如果從事單元測試、整合測試等較接近程式**的工作，無疑需要開發技能，這類工作對測試人員開發技能的要求甚至會超過程式設計師；而從事基本的介面測試、使用者功能測試，不會開發不會有大的影響。
但是，原則上還是建議測試人員最好具備一定的開發能力，而且是開發能力越強越好，開發技能對測試工作可以說是「百利而無一害」，例如可以更容易避免報告重複的缺陷、對缺陷原因進行更準確的定位等等。同時，由於國內多數公司對測試人員沒有分類，要想得到更多的發展機會，也應該學會開發，便於從事各種型別的測試工作，除非只從事那些遠離**的測試工作。
此外，掌握一門開發語言後，進行測試的時候可以站在程式開發的角度進行思考，而且知道程式如何編寫，就更容易發現問題。
測試只能證明缺陷存在，不能證明缺陷不存在。而徹底的、全面的測試又難以成為現實，現實中要考慮時間、費用等限制，不允許無休止地測試。通常的測試結束，只是滿足一定條件下的測試結束，最後的「測試」還是交給了使用者。
因此，即使測試結束了，質量也不一定好。例如測試小組在時間緊迫的情況下，只測試了核心模組，這樣的軟體系統質量一般不會好。
通常對於相對複雜的產品或系統來說，zero-bug是一種理想，good-enough是我們的原則。
good-enough原則就是一種權衡投入/產出比的原則：不充分的測試是不負責任的；過分的測試是一種資源的浪費，同樣也是一種不負責任的表現。
執行測試工作的關鍵在於：如何界定什麼樣的測試是不充分的，什麼樣的測試是過分的。解決這一問題的通常方法是制定最低測試通過標準和測試內容，然後具體問題具體分析。
（1）確保產品完成了它所承諾或公布的功能。這一目標就是軟體要符合需求，開發出的軟體應該達到所有功能都有明確的書面說明，測試的首要目的就是保證所有預定功能是存在並且經過規範的測試。
（2）確保產品滿足效能和效率的要求。現在的使用者對軟體的效能方面的要求越來越高，使用起來系統執行效率低(效能低)、或使用者介面不友好、使用者操作不方便(效率低)的產品市場空間肯定會越來越小。因此通過測試改善效能也是測試工作乙個目標。
實際上使用者最關心的不是軟體的技術有多先進、功能有多強大，而是能從這些技術、這些功能中得到多少好處。也就是說，使用者關心的是他能從中取出多少，而不是你已經放進去多少。
（3）確保產品是健壯的、適應使用者環境的。健壯性即穩定性，是產品質量的基本要求，尤其對於乙個用於事務關鍵或時間關鍵的工作環境中的應用系統。軟體只有穩定的執行，才會不致於中斷使用者的工作，因此通過健壯性測試是軟體測試工作的又乙個目標。
測試中的80-20原則是說一般情況下，在分析、設計、實現階段的複審和測試工作能夠發現和避免80%的bug，而系統測試又能找出其餘bug中的80%，最後的5%的bug可能只有在使用者的大範圍、長時間使用後才會暴露出來。因為測試只能夠保證盡可能多地發現錯誤，無法保證能夠發現所有的錯誤。還有就是一般情況下80％的缺陷聚集在20％的關鍵核心業務模組中。
在研發小組將所開發的程式經驗證後，提交測試組後，測試實施工作基本開始了。這個時候，測試人員要仔細閱讀有關資料，包括規格說明、設計文件、使用說明書及在設計過程中形成的測試大綱、測試內容及測試的通過準則，全面熟悉系統，編寫測試計畫，設計測試用例，作好測試前的準備工作。為了保證測試的質量，我們一般測試過程分成幾個階段，即：**審查、單元測試、整合測試和驗收測試。
**會審是由一組人通過閱讀、討論和爭議對程式進行靜態分析的過程。會審小組由組長，2～3名程式設計和測試人員及程式設計師組成。會審小組在充分閱讀待審程式文字、控制流程圖及有關要求、規範等檔案基礎上，召開**會審會，程式設計師逐句講解程式的邏輯，並展開熱烈的討論甚至爭議，以揭示錯誤的關鍵所在。實踐表明，程式設計師在講解過程中能發現許多自己原來沒有發現的錯誤，而討論和爭議則進一步促使了問題的暴露。例如，對某個區域性性小問題修改方法的討論，可能發現與之有牽連的甚至能涉及到模組的功說明、模組間介面和系統總結構的大問題，導致對需求定義的重定義、重設計驗證，大大改善了軟體的質量。
**會審儘管需要一定的成本，但是在大型軟體中，是必不可少的。
很多時候產品經過最後一次測試後由開發人員來發布，或者由質量管理部來發布，這樣做都是不合適的。
開發人員發布產品常常會導致缺陷解決不徹底。一種較常見的現象是最後一次回歸測試後，開發人員修改完成最後幾個缺陷直接從開發環境發布產品，13.1.3節中的案例就是這樣的一種情況，這種條件下實際是缺陷一次測試，因為修改缺陷通常會引入新的缺陷，甚至是嚴重的缺陷。
測試人員發布缺陷也是不和流程的，測試人員的職責是報告軟體質量情況。而且測試人員發布缺陷容易帶來版本管理混亂。
正確的做法是產品經過最後一次測試後，把產品和缺陷修改情況存入產品基線庫，形成乙個可以發布的版本。這樣發布產品的乙個前提是每次產品提交測試前都要有乙個預備發布版本，測試或者回歸測試後如果有問題需要修改解決，開發人員對該預備版本進行修改。如此反覆多次後，直到最後一次測試，所有缺陷都得到修改或者審核，同時開發人員此次測試後沒有對產品經過任何修改，我們就可以把這個最後乙個預備發布版本存入基線庫。
進行了上面正確的版本控制後，我們可以通過配置管理庫進行產品發布管理。對外部發布產品時，直接從配置管理庫中提取就可以了。詳細的內容，讀者可以參考配置管理方面的書籍。
軟體測試的疑惑（三）
目前it行業人員流動較大已經成為一種不爭的事實，員工的辭職大多數都會給組織帶來一定的影響，而這種影響基本是不可能避免的。在測試領域，員工忽然辭職也會帶來很大的負面影響，尤其測試隊伍規模較小時。面對這種情況，我們所能做的，就是如何最大限度的降低這種影響。根據作者的經驗，主要有兩種方法 第一種是在測試人...
軟體測試理論（四）
測試執行過程 整體過程 測試執行階段的主要任務 測試准入准出 開發編碼結束，並在開發環境已完成單元測試 需求上規定的功能均已實現，如沒有實現，開發給出提測的測試範圍 已完成整合測試，被測系統的基本流程可以走通，介面上的功能均已實現，經過 評審並符合軟體編碼規範 開發提交最新版本 以此為稷仙，提交並通...
軟體測試基礎 四
ui測試 1 測試目標 2 導航測試 測試 內容測試 相容性測試 3 導航型別 4 導航測試點 6 內容測試 7 相容性測試 windows unix macintosh linux 同乙個應用在某些作業系統中可以正常執行，在另外的系統下可能會執行失敗 在web系統發布之前，需要在各種作業系統下對w...