測試人員的思想理念和工作方法

軟件測試的前提假設

　　測試人員進行軟件測試的基本假設是“有罪推斷” ，即認為被測程序一定是有bug的，而且每個功能點的實現都存在bug，而且一定存在嚴重的bug。 請牢記這個假設 ，一旦在日后的工作過程中產生了這樣的認識：“這個功能很簡單，肯定不會出現問題，就不再測試了。”或者“這個功能上一輪剛測試過，當時就沒有問題，這一輪應該也不會有問題，就不用測試了。”等等諸如此類的意識，那么 你就有90%的概率導致漏測 ，造成線上問題。其原因也正是這個測試工作的基本前提假設，一旦被違背就從開端導致了測試工作存在問題，所以真正出現問題的可能性也就很大了。 正因為軟件測試的這個前提假設，在導致了如果我們同開發人員看待程序的角度和出發點完全不同。因為，通常情況下一個有自信心的開發人員不會認為自己寫的代碼全部都有問題，他一定是認為自己的代碼沒有問題了才交付測試的。因此，如果要從事軟件測試工作，那么就必須牢記并運用該假設。 這個前提假設要求我們在實施測試的過程中不能放過任何一個細小問題。比如，某個程序運行時在控制臺打印了一些錯誤信息，但是實際上該程序的運行和功能都沒有問題，如果我們摒棄有罪推斷的假設，從合理實現的角度去分析，那么就可以認為這是開發人員對于日志打印的輸出控制沒有做好導致的，屬于微不足道的小問題，不需提出即可。于是，這就使你有90%的可能性錯過了發現其編碼上的異常分支判斷錯誤導致的重大問題。此類案例更常見與那些小概率問題，即在測試過程中偶爾出現，但確實很難、甚至無法復現的問題，如果我們同樣摒棄有罪推斷的假設，這些問題也會從我們手邊溜走，跑到線上由用戶發現。相信諸如此類的教訓在每一個測試人員那里都不是少數。 所以， 請轉變思維，牢記這個假設 。

　　測試工作的開展思路

　　從需求出發

　　無論什么樣的軟件產品，其設計開發的目的必然是為了滿足一定的需求，這種需求或者是用戶提出的，或者是某個關聯系統提出的。因此，軟件產品最終是為了交付給用戶使用的，也因此可以滿足需求是對于軟件產品質量的基本保證，其它如擴展性、維護性等等其實也算是更為廣義的需求。 所以，我們開展軟件測試工作必須從需求出發。首先要全面了解需求，包括其背景、關聯性、用戶特點等；其次要深入挖掘隱含的需求和關聯，包括某個需求隱含了對于系統現有功能的修改等等。 我們只有在全面、深入了解需求的基礎上，才能設計全面、有效的測試用例來進行測試，以滿足對于軟件產品滿足需求的基本質量保證。

　　測試依據是測試設計

　　我們進行測試設計的依據是對于軟件產品需求的全面和深入分析，但是需求決不全是軟件測試的依據。因為我們不僅要驗證需求，而且要驗證設計。比如程序實現的異常（指針越界、字符串copy越界等等）判斷，是保證軟件產品可以正常運行的必要實現，但是我們在需求中是無法描述和分析出來的。 那么進行測試的依據是軟件產品的設計或者是代碼嗎？當然也不是，因為如果依據開發人員的設計或代碼來進行測試的話，設計或代碼正確，但是不符合需求邏輯的錯誤就無法發現。而且，如果依據設計或代碼進行測試的話，那么也就違背了我們進行軟件測試的基本假設——有罪推斷。 所以，我們進行軟件測試的依據應該是我們根據對需求的全面深入分析和對設計實現的了解，兩相綜合產生的測試設計。 正因為如此，測試是否充分和有效的根源也是測試設計。所以，我們的工作重點也是測試用例設計。

　　測試人員只是驗證質量

　　首先要明確的是測試人員無法保證軟件產品的質量，軟件產品的質量是通過參與軟件過程的各方聯合共同保證的。 有兩個原因：一、由于軟件測試人員不是產品設計人員和開發人員，所以無法做到比他們更了解產品需求和產品設計，如果他們都無法保證需求和設計沒有問題，那么測試人員就更無法保證了；二、軟件測試位于軟件開發生命周期的末端，如果依靠測試人員來發現所有的bug來保證質量的話，那么風險就會后置，導致問題修復的成本增加，同時也增加了修復問題帶來新問題的風險，因為在項目末端是不可能投入過多的成本來進行那怕接近全面覆蓋的測試的。 也正因為如此，我們是無法決定一個軟件產品質量的好壞的，只有PM設計出產品需求，RD編碼完成，我們才能夠通過我們的工作，促進PM、RD改進他們的產品、系統，從而達到產品、系統的高質量。 所以，我們才要參與需求評審和設計評審，大家一起努力，各個階段由專業化的人員來保證階段的質量，將問題盡量在前期發現。而測試人員只能根據前期分析的結果，設計出測試用例，來驗證軟件產品在事先設計或后續補充的測試用例上不存在問題。 但是“測試人員只是驗證質量”決不是指我們可以不為產品質量負責。 因為大家（PM、RD、QA、OP等）工作的最終目標是產品質量保證，這個目標是大家共同的目標，所以每個人都必須為這個目標負責。只是由于咱們處于軟件生命周期的最后一個環節，所以目前看起來產品質量都是由我們來負責和把握的，實際上，如果最終發布的軟件產品出現了問題，那么無論如何我們肯定是有責任的。

　　測試的內容一定是確定的

　　既然軟件測試只能驗證質量，那么所要驗證的內容必然是確定的，或者說是概率確定的。否則也就無從驗證了。 因此，模糊不確定的需求我們無法驗證，輸出結果沒有任何規律的程序設計我們也無法驗證，這就是軟件產品的可測性判斷。也因此，我們進行需求評審和設計評審時是一定要保證這個基本點的。

　　測試的目標不是沒有bug

　　綜上所述，進行軟件測試的目標不是通過測試使得軟件產品不存在bug（這是不可能達成的），而是我們根據確定的需求、確定的設計和確定的測試用例驗證出的結果不存在bug。 同樣的，測試人員的目標也不是在測試執行過程中去找bug，而是運用測試思維，使用一定的測試方法，盡可能早地在需求階段、設計階段將所有的bug找出來，真正測試執行階段只是驗證不存在用例所描述的那樣的bug，而不是通過用例去發現bug。

　　測試人員的工作方法

　　通過前文的分析，我么可以總結出測試人員的工作方法是這樣的： 首先對需求進行全面深入地分析，接著去分析評審程序設計，假定每個需求的功能點開發人員的實現都是存在問題的，同時也假定每一個程序設計的編碼實現（無論是方式還是代碼寫作）都是存在問題的，然后根據這些假定設計測試用例，最后執行這些測試用例，驗證程序不存在那些問題。 從中不難看出，我們同開發人員同時由需求出發，開發人員產生詳細設計和代碼，我們產生方案和測試用例，然后開發人員提交被測程序，由測試人員同時運行被測程序和測試用例，來動態驗證程序質量。所以，測試方案和測試用例設計的過程等價于開發人員進行詳細設計和代碼開發的過程，兩相對比可以看出，測試人員最重要也是最核心的工作就是測試設計。 因此，測試人員的工作可以重點描述成：是一個運用測試的思維和各種測試理論及方法，將所測試的軟件產品的每一個功能都改變成一組特定的輸入和一組特定的輸出一一確定對應的形式，形成測試用例，然后待開發人員提交測試后，在測試環境部署被測程序，根據測試用例進行主動測試的過程。

原文地址：http://www.51testing.com/html/40/n-807640.html

轉載于:https://www.cnblogs.com/xinyuxin912/p/3511420.html

總結

以上是生活随笔為你收集整理的【转】测试人员的思想理念和工作方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。