測試人員進行軟體測試的基本假設是「有罪推斷」，即認為被測程式一定是有bug的，而且每個功能點的實現都存在bug，而且一定存在嚴重的bug。請牢記這個假設，一旦在日後的工作過程中產生了這樣的認識：「這個功能很簡單，肯定不會出現問題，就不再測試了。」或者「這個功能上一輪剛測試過，當時就沒有問題，這一輪應該也不會有問題，就不用測試了。」等等諸如此類的意識，那麼你就有90%的概率導致漏測，造成線上問題。其原因也正是這個測試工作的基本前提假設，一旦被違背就從開端導致了測試工作存在問題，所以真正出現問題的可能性也就很大了。 正因為軟體測試的這個前提假設，在導致了如果我們同開發人員看待程式的角度和出發點完全不同。因為，通常情況下乙個有自信心的開發人員不會認為自己寫的**全部都有問題，他一定是認為自己的**沒有問題了才交付測試的。因此，如果要從事軟體測試工作，那麼就必須牢記並運用該假設。 這個前提假設要求我們在實施測試的過程中不能放過任何乙個細小問題。比如，某個程式執行時在控制台列印了一些錯誤資訊，但是實際上該程式的執行和功能都沒有問題，如果我們摒棄有罪推斷的假設，從合理實現的角度去分析，那麼就可以認為這是開發人員對於日誌列印的輸出控制沒有做好導致的，屬於微不足道的小問題，不需提出即可。於是，這就使你有90%的可能性錯過了發現其編碼上的異常分支判斷錯誤導致的重大問題。此類案例更常見與那些小概率問題，即在測試過程中偶爾出現，但確實很難、甚至無法復現的問題，如果我們同樣摒棄有罪推斷的假設，這些問題也會從我們手邊溜走，跑到線上由使用者發現。相信諸如此類的教訓在每乙個測試人員那裡都不是少數。 所以，請轉變思維，牢記這個假設。無論什麼樣的軟體產品，其設計開發的目的必然是為了滿足一定的需求，這種需求或者是使用者提出的，或者是某個關聯系統提出的。因此，軟體產品最終是為了交付給使用者使用的，也因此可以滿足需求是對於軟體產品質量的基本保證，其它如擴充套件性、維護性等等其實也算是更為廣義的需求。 所以，
我們開展軟體測試工作必須從需求出發
。首先要全面了解需求，包括其
背景、關聯性、使用者特點
等；其次要深入挖掘隱含的需求和關聯，包括某個需求隱含了對於系統現有功能的修改等等。 我們只有在全面、深入了解需求的基礎上，才能設計全面、有效的測試用例來進行測試，以滿足對於軟體產品滿足需求的基本質量保證。我們進行
測試設計
的依據是對於軟體產品需求的全面和深入分析，但是需求決不全是軟體測試的依據。因為我們不僅要驗證需求，而且要驗證設計。比如程式實現的異常（指標越界、字串copy越界等等）判斷，是保證軟體產品可以正常執行的必要實現，但是我們在需求中是無法描述和分析出來的。 那麼進行測試的依據是軟體產品的設計或者是**嗎？當然也不是，因為如果依據開發人員的設計或**來進行測試的話，設計或**正確，但是不符合需求邏輯的錯誤就無法發現。而且，如果依據設計或**進行測試的話，那麼也就違背了我們進行軟體測試的基本假設——有罪推斷。 所以，
我們進行軟體測試的依據應該是我們根據對需求的全面深入分析和對設計實現的了解，兩相綜合產生的測試設計。
正因為如此，測試是否充分和有效的根源也是測試設計。所以，我們的工作重點也是測試用例設計。首先要明確的是測試人員無法保證軟體產品的質量，軟體產品的質量是通過參與軟體過程的各方聯合共同保證的。有兩個原因：一、由於軟體測試人員不是產品設計人員和開發人員，所以無法做到比他們更了解產品需求和產品設計，如果他們都無法保證需求和設計沒有問題，那麼測試人員就更無法保證了；二、軟體測試位於軟體開發生命週期的末端，如果依靠測試人員來發現所有的bug來保證質量的話，那麼風險就會後置，導致問題修復的成本增加，同時也增加了修復問題帶來新問題的風險，因為在專案末端是不可能投入過多的成本來進行那怕接近全面覆蓋的測試的。 也正因為如此，我們是無法決定乙個軟體產品質量的好壞的，只有pm設計出產品需求，rd編碼完成，我們才能夠通過我們的工作，促進pm、rd改進他們的產品、系統，從而達到產品、系統的高質量。 所以，我們才要參與需求評審和設計評審，大家一起努力，各個階段由專業化的人員來保證階段的質量，將問題盡量在前期發現。而測試人員只能根據前期分析的結果，設計出測試用例，來驗證軟體產品在事先設計或後續補充的測試用例上不存在問題。但是「測試人員只是驗證質量」決不是指我們可以不為產品質量負責。因為大家（pm、rd、qa、op等）工作的最終目標是產品質量保證，這個目標是大家共同的目標，所以每個人都必須為這個目標負責。只是由於咱們處於軟體生命週期的最後乙個環節，所以目前看起來產品質量都是由我們來負責和把握的，實際上，如果最終發布的軟體產品出現了問題，那麼無論如何我們肯定是有責任的。既然軟體測試只能驗證質量，那麼所要驗證的內容必然是確定的，或者說是概率確定的。否則也就無從驗證了。 因此，模糊不確定的需求我們無法驗證，輸出結果沒有任何規律的程式設計我們也無法驗證，這就是軟體產品的可測性判斷。也因此，我們進行需求評審和設計評審時是一定要保證這個基本點的。綜上所述，進行軟體測試的目標不是通過測試使得軟體產品不存在bug（這是不可能達成的），而是我們根據確定的需求、確定的設計和確定的測試用例驗證出的結果不存在bug。 同樣的，測試人員的目標也不是在測試執行過程中去找bug，而是
運用測試思維
，使用一定的測試方法，
盡可能早地在需求階段、設計階段將所有的bug找出來
，真正測試執行階段只是驗證不存在用例所描述的那樣的bug，而不是通過用例去發現bug。
通過前文的分析，我麼可以總結出測試人員的工作方法是這樣的：首先對需求進行全面深入地分析，接著去分析評審程式設計，假定每個需求的功能點開發人員的實現都是存在問題的，同時也假定每乙個程式設計的編碼實現（無論是方式還是**寫作）都是存在問題的，然後根據這些假定設計測試用例，最後執行這些測試用例，驗證程式不存在那些問題。從中不難看出，我們同開發人員同時由需求出發，開發人員產生詳細設計和**，我們產生方案和測試用例，然後開發人員提交被測程式，由測試人員同時執行被測程式和測試用例，來動態驗證程式質量。所以，
測試方案和測試用例設計的過程等價於開發人員進行詳細設計和**開發的過程
，兩相對比可以看出，測試人員最重要也是最核心的工作就是測試設計。 因此，測試人員的工作可以重點描述成：是乙個運用測試的思維和各種測試理論及方法，將所測試的軟體產品的每乙個功能都改變成一組特定的輸入和一組特定的輸出一一確定對應的形式，形成測試用例，然後待開發人員提交測試後，在測試環境部署被測程式，根據測試用例進行主動測試的過程。
測試工程師的工作方法
首先，對需求進行全面深入地分析，接著去分析評審程式設計，假定每個需求的功能點開發人員的實現都是存在問題的 同時，也假定每乙個程式設計的編碼實現 無論是方式還是 寫作 都是存在問題的 然後，根據這些假定設計測試用例，最後執行這些測試用例，驗證程式不存在那些問題。測試人員的工作可以重點描述成 是乙個運用...
ftp的工作方法介紹
ftp支援兩種模式，一種方式叫做standard 也就是port方式，主動方式 一種是passive 也就是pasv，被動方式 standard 模式 ftp的客戶端傳送 port 命令到ftp 伺服器。passive模式ftp 的客戶端傳送 pasv命令到 ftp server.port模式ftp...
工作方法決定自己的發展
有人會問，我們同在乙個公司，憑什麼別人可以拿30000，我只能拿3000？拿3000工資與30000工資，究竟有什麼區別？如下截圖告訴你人與人之間的差別！情景一 情景二 這就是差距！一 剛入職時 普通員工 優秀員工 看重工資的高低，在一無所長的前提下，沒有想過學習豐富的工作經驗和職業技能。更看重寶貴...