測試的目的是為了保證生產出來的產品滿足甚至超出客戶的需求。測試的角度要從客戶的角度分析客戶的顯性需求和隱性需求。所以，做好測試，你必須要清楚得掌握客戶的需求。要掌握客戶的需求，首先你得清楚你的客戶是誰？

　　傳統的客戶定義主要有三種：Customer、User和Operator。customer是和你簽訂合同的對方；user是使用你的軟件的單位 （點）；operator是操作者。一般：user和討論功能模塊，和operator討論操作場景，和customer簽合同。比如你要做個電信軟件， 跟你簽訂合同的customer就是這個電信公司；使用你的軟件的user就是各個電信營業廳；操作你的軟件的operator就是各營業廳里各個服務 員。

　　CMM里還有一個關于客戶的定義：“負責接收產品并且付給開發組織報酬的個人或組織。”

　　那么我們的客戶是誰呢？

　　答：

　　軟件質量可以從兩個角度看，Producer和Customer. 對應到樓主的定，Producer就是樓主的customer；Customer就是樓主的User和Operator。

　　從producer的角度看質量是：Meet the customer’s requirement the first time and every time.

　　從Customer角度看質量是：Fit for use.

　　測試的職責是縮小和彌合兩者的差距。用圖說明一下：

　　測試部門在SDLC的不同階段對需求的范圍和關注程度是不一樣的，是動態的。

　　SDLC 前期，比如需求分析階段，如果測試介入早，會去和producer和Customer做溝通，關注兩者理解的需求是是否一致。這個階段采用Static testing的方法，比如：Review， walkthrough. 這個階段發現的問題，解決的成本最低。

　　到SDLC中后期，假設Customer的需求都確定了，PRD和其他需求文檔定稿了。測試就會著重關注共同約定的需求，開始測試設計。我們就要確保producer做出來的東西和否和需求吻合。

進入測試已經五個年頭了，感覺這個行業還是比較適合自己的，在這個道路上我還有很長的路要走，在此先和大家分享下我的五年測試歷程。

　　職業道路選擇------認準目標就前進

　　我最開始接觸測試這行是在2005年，還算比較早的，但是那時，我對測試的理解就是要找問題，也不會去深究，對測試沒有一個完整的概念，以為測試就是不會寫代碼的人都可以做的。也沒有意識去思考測試項目流程是什么，項目的架構是怎樣的，要采用哪種數據庫、編程語言，采用什么協議，設計思路是怎樣的？

　　測試了整整一年后，我也只知道按照不是特別規范的測試用例來執行，加上測試進度很緊，當時測了一輪又一輪。那個時期，國內的測試還比較薄弱，公司普遍都還不是很重視測試，我自己也不知道怎樣才算把這個工作做好，在網上查閱了相關的資料，但是關于這方面的資料特別少，自己抽空學習也沒啥效果。

　　后來，我覺得測試前景

不錯的，很想對測試這個行業有一個整體的認識，另外，我也想多了解下自動化測試工具，希望這些能讓我的測試之路走的更遠更好，于是我選擇了自我充電，參加了上海一個測試培訓。

　　在這個過程中，因為學習的欲望很強，很多都是我主動想學的，所以我邊學邊實踐。通過學習，我了解了測試的基本概念、基本流程；測試在整個軟件周期中的作用；測試用例的編寫，方案的編寫；數據庫基本應用等。現在回想起來，這段時間是一個學習的美好的回憶。我最大的收獲就是明確了以后在測試工作中，我應該關注哪些方面、從哪些方面去思考問題、怎樣使我的工作做的更好。

　　心態的作用------一切從工作出發

　　心態好才能工作好，這句話很對，在測試過程中，可能你會做很多重復的活，但是你怎樣才能保證你自己工作積極性一直很高，怎樣才能在工作中獲取自信呢？在工作當中，我是這樣做的：

　　1、對不理解或困難的工作，我自己去查找資料或問同事，尋求幫助。

　　2、對自己會做的工作，我在能夠完成的同時，我會留出一定的時間，來自己做自由測試，這塊很重要，因為很多測試用例覆蓋到的地方，基本都測試過，測試是不能窮盡的，可能有些路徑或者操作，只有在自由測試中才能找出。

　　……………………

　　查看全文請點擊下載：http://www.51testing.com/html/54/n-247254.html

　　對于編程語言的熟悉這一塊，以前我們一個測試經理說，一個測試人員，不懂代碼就像人殘廢一樣，雖然話有點難聽，但是熟悉開發的思路和代碼，會讓你的測試技術之路走的更寬，更長！

　　在技術領域里，你知識越淵博，越被人喜歡，因為你就是一個活字典！

　　除了專業知識，對軟件需求也要深入了解。需求是開發編寫軟件的源頭，不管你是作為普通的測試人員，還是資深的測試人員，都需要對你所測的軟件的需求有很好的了解，包括產品需求和測試需求。這個也是一個過程，最開始可以去了解需求的關注項，如：功能，性能，接口，屬性，約束條件等。然后由淺入深，理解顯性需求和挖掘隱性需求。特別要關注開發實現時，是否考慮到異常輸入和輸出。

　　開發與測試關系處理--換位思考

　　在整個項目中，其實開發和測試是一個團隊，團隊的目標是一致的，提高軟件的質量。但是工作當中因為職責的不一樣，往往可能會造成分歧。為了更好的配合開發，測試人員要把握好以下幾點：

　　1、在提交問題時，表達要清楚，重現步驟和預期結果要清楚。

　　2、如果是概率性出現的問題，最好記錄好有用的日志并保持現場，這樣能幫助開發更快解決問題，必要時，要協助開發重現問題。

　　3、在提交問題單時，可以先把嚴重的問題現象，步驟告訴開發，然后再提單。如果問題較多時，先提嚴重的，小問題最后再提，因為開發也有績效考核的，開發修改問題的效率高了，這樣開發會很樂意和你合作。

　　4、有些有爭執的問題或可改可不改的問題，和開發討論沒有結果，但是測試覺得實在是改了更好，可以找上一級或者專家協商確定后，再提單，或者告訴開發兄弟，這個問題可以不用馬上改，優先級很低，要改了這個軟件更好，更能體現開發的能力等。

　　5、把開發當你朋友。每當我測試到一個很嚴重的問題時，我會找開發聊，這個問題是怎樣產生的，你是怎樣解決的？然后會問開發人員，你這樣解決之后會不會產生其他的問題？然后會跟開發人員說，以你的能力你肯定能解決這個問題的，相信你！這樣會增加開發對你信任，也說明你和他是站在一起的。

剛在51testing上看到一個人發帖，說自己寫測試用例沒有很好的思路，對于一些復雜的功能點，有沒有比較好的測試覆蓋方法，比如高級查詢等等，非要列出來那么詳細的測試用例嗎？～～～～看完之后，我就忍不住發言了，作為一個測試人員，設計測試用例那是本職工作，如果我們連寫用例的基本耐心都丟棄了，還談什么測試。那開發總不能說因為寫代碼很麻煩，而不寫吧。很多事情沒有捷徑，必須要做的事情，那是沒有辦法去逃避，不然我們就失去了工作的意義了。

　　其實說來，也是由于最近對于測試用例的設計，讓我產生了一些反思。如何設計測試用例，如何評審測試用例，最后如何管理測試用例，這都是我們測試工作中必須要去改進的問題。在之前的公司，由于團隊工作任務繁忙，我們沒有太多的時間去管理和優化測試用例，也因此對用例方面少了太多的思考，而且雖然有對于用例的評審，但一直以來，我認為是做得不夠好的，畢竟每次評審下來，感覺效果沒有預期的那么好，主要還是沒有足夠的時間去管理，所以無法引起重視。不過，現在我想我需要花大量的時間來管理用例了，而且要保證有序的進行，最后輸出讓團隊中各個成員都認為滿意而且高效的測試用例。對于用例管理的根本問題，我個人認為是分類上，例，就是需如何有效的維護和優化用要前期明確的分類規劃，根據分類的優先級一步一步地來完成就可以了，到最后，我們也可以有效把控的測試覆蓋度。

　　當前，我們大致可以把測試用例分稱三個方面，分別是功能、UI和業務流程，從這三個角度來進行設計。

　　1、從功能的角度，能是每個項目測試的重點，通常在測試人員得到需求文檔的時候，我們就開始設計測試用例，那么這個時候需求文檔上列出都是功能以及部分一些業務邏輯等，所以在測試用例的第一階段就是完成功能的用例設計功。不過這里，肯定會讓很多人疑惑，其實功能、業務還有UI，都是有關聯的，而且很多時候無法分解的。這里后面我會舉個例子說明哈，但絕非都是可以分類，只是談談如何分解的方法，最重要的就是不要遺漏就行。

　　2、從UI的角度，UI通常是指界面測試，這個應該不難理解，但要想與功能點進行分解，也不是那么容易區分的，所以我們來直觀的說明哈。界面測試，注重樣式，外觀、整潔、擺放以及易用性，還包括用戶體驗等。

　　3、從業務的角度，這個相對來說，還比較好理解，業務通常是指一連串的動作所連接起來的流程，這個流程必須有行為和目標，或者說方向。業務通常是一個項目或者產品設計的核心，當下，越來越多的應用業務流程都是非常復雜，所以對于業務的用例設計，就是考驗一個測試人員的業務水平如何。

　　下面通過一個證券交易平臺上的買入和撤單業務，進行具體說明：

　　業務說明：買入業務包括股票代碼、當前價格、買入價格，買入股票數量、確定買入按鈕和取消按鈕；

　　撤單業務包括選擇撤單的未成交業務、撤單成功、撤單失敗以及取消撤單按鈕；

　　以上只是大致列舉了一部分。

　　功能點：買入按鈕、取消按鈕、選擇撤單、撤單按鈕和取消撤單按鈕等

　　UI界面測試：股票代碼、當前價格、買入價格、買入股票數量，所有的文本框；買入成功/失敗的提示框；撤單成功/失敗的提示框；撤單成功/失敗的業務狀態等

　　業務測試：買入業務，從輸入買入表單的數據，到提交表單，到最后買入的表單顯示的位置，以及買入提交但未成交，可以撤單，完成撤單的業務，到撤單成功或者失敗等，這一連串的工作組合就是一個業務流程。

　　其實這里就存在一個爭議性的問題，對于買入和撤單，既可以作為功能點，也可以作為一個業務邏輯來設計，但從本質上來講，功能點注重單獨的操作，而業務流重的在是一個流程，還需要具體業務去甄別。功能點的設計更主要對這個買入和撤單的按鈕本身進行用例設計；而業務則是需要從買入和撤單之前的輸入到最后輸出這樣一個過程來設計。

　　以上也只是大概的一個簡單的說明，具體的操作還得根據自己的實際流程來執行，畢竟測試用例的管理是一個長期的積累和沉淀的過程，好的方法都是總結出來的。對于測試來說，用例是基礎，對于回歸測試、自動化、性能等等都是根本，管理好測試用例，也就是提高測試的工作質量。

　　軟件測試基礎——維護型測試的過程，包括：特點，測試目標，方法，測試設計，測試準備，測試執行等。測試周期短，聚焦變更，重視測試可重復性等都是典型維護型項目的特征。

　　軟件測試基礎——測試的質量屬性。包括，功能性，可靠性，高效性，可用性，可維護性。

　　軟件測試基礎——測試等級，包括模塊測試，系統測試，FAT，UAT，PAT，SIT，試點測試等。

　　軟件測試基礎——性能測試，包括：測試關注重點、性能測試分類、性能測試技術、測試工具、故障定位等。

　　軟件測試基礎——測試計劃，包括測試基礎、測試策略、測試組織、移交等

　　軟件測試基礎——測試設計方法，包括邊界值法、因果圖法、等價類法、算法測試等。

　　第一步：評定開發方案和狀態

　　這第一步是創建W＆T計劃的先決條件，W＆T計劃用于評估執行的軟件解決方案。在這一步，測試員可質疑開發方案的完整性和正確性。并且基于項目計劃的完整和延伸定義，測試員要估計出測試這個執行的軟件解決方案所需要的資源數量。

　　第二步：形成測試計劃

　　形成測試計劃應該要符合軟件開發過程的模式，所有計劃的結構應該是一樣的，內容則要基于測試員對開發中的項目的感知程度。

　　第三步：測試軟件的需求說明

　　不完整的，不正確的，或不一致的要求都會導致軟件開發失敗。 在需求收集階段，不正確說明軟件需求，會明顯的增加開發費用。 測試員通過查證，一定要保證需求說明的是正確的，完整的，并且不會有沖突。

　　第四步：測試軟件的設計

　　這一步測試員首先要能過查證技術測試軟件的外部和內部設計，測試設計是否能完成需求說明的目標和這些設計能否在指定的硬件上起作用。

　　第五步：軟件開發過程中的測試

　 　根據內部設計文檔選擇的軟件開發方法將會決定測試員測試需要的類型和范圍。因為軟件構建變得更加自動化，所以這一階段要求相對少的測試，不過，如果軟件 采用瀑布型的開發模式，容易產生錯誤，這些錯誤應該被發現。經驗表明，在構建階段發現問題會比在動態測試過程發現問題節省很多成本

　　第六步：執行和記錄錯誤

　　這個階段包括在動態狀態測試代碼，在測試計劃中指定的步驟，方法，工具會被用于驗證可執行代碼是否符合規定的軟件需求和設計的結構化規范

　　第七步：可接受性測試

　　可接受性測試能讓使用者在操作他們的日常工作所需功能時評估軟件的適用性和可用性。這樣能測試出使用者認為軟件應該實現什么功能，與需求文檔的中說明的軟件應該實現什么功能形成對照

　　第八步：報告測試結果

　　測試報告是一個持續的過程，可口頭表達也可記錄下來。 缺陷和涉及的問題要向相應的小組報告，并且報告要易于理解，這一點很重要。這樣就能以最低的可能成本修正問題

　　第九步：軟件安裝測試

　　一旦測試小組已確認該軟件是供生產使用，在生產環境中，軟件的執行能力將被進行測試。這將測試操作軟件的界面，相關軟件和操作程序。

　　第十步：測試軟件變化

　　當進行到第十步，是軟件被安裝使用后的維護過程。相關概念隨著整個執行過程而改變，任何時候需求改變了，測試計劃也要相應改變，并且這些改變對于整個軟件的影響也要測試和評估。

　　第十一步：評估測試效率

　　測試改進最好通過在測試任務的最后階段評估測試效率完成。這個評估首先應該由測試員完成，同時也要包括開發人員，軟件使用者和專業質量擔保人（如果有這些人員的話）。

web測試20種界測試思路

 1.頁面鏈接檢查：每一個鏈接是否都有對應的頁面，并且頁面之間切換正確。

       2.相關性檢查：刪除/增加一項會不會對其他項產生影響，如果產生影響，這些影響是否都正確。

       3.檢查按鈕的功能是否正確：如update、cancel、delete、save等功能是否正確。

        4.字符串長度檢查：輸入超出需求所說明的字符串長度的內容，看系統是否檢查字符串長度，會不會出錯。

        5.字符類型檢查：在應該輸入指定類型的內容的地方輸入其他類型的內容(如在應該輸入整型的地方輸入其他字符類型)，看系統是否檢查字符類型，會否報錯。

        6.標點符號檢查：輸入內容包括各種標點符號，特別是空格、各種引號、回車鍵。看系統處理是否正確。

        7.中文字符處理：在可以輸入中文的系統輸入中文，看會否出現亂碼或出錯。

        8.檢查帶出信息的完整性：在查看信息和update信息時，查看所填寫的信息是不是全部帶出，帶出信息和添加的是否一致。

        9.信息重復：在一些需要命名，且名字應該唯一的信息輸入重復的名字或ID，看系統有沒有處理，會否報錯，重名包括是否區分大小寫，以及在輸入內容的前后輸入空格，系統是否作出正確處理。

        10.檢查刪除功能：在一些可以一次刪除多個信息的地方，不選擇任何信息，按”delete”，看系統如何處理，會否出錯;然后選擇一個和多個信息，進行刪除，看是否正確處理。

        11.檢查添加和修改是否一致：檢查添加和修改信息的要求是否一致，例如添加要求必填的項，修改也應該必填；添加規定為整型的項，修改也必須為整型。

        12.檢查修改重名：修改時把不能重名的項改為已存在的內容，看會否處理，報錯。同時，也要注意，會不會報和自己重名的錯。

        13.重復提交表單：一條已經成功提交的紀錄，back后再提交，看看系統是否做了處理。

        14.檢查多次使用back鍵的情況：在有back的地方，back，回到原來頁面，再back，重復多次，看會否出錯。

        15. search檢查：在有search功能的地方輸入系統存在和不存在的內容，看search結果是否正確。如果可以輸入多個search條件，可以同時添加合理和不合理的條件，看系統處理是否正確。

        16.輸入信息位置：注意在光標停留的地方輸入信息時，光標和所輸入的信息會否跳到別的地方。

        17.上傳下載文件檢查：上傳下載文件的功能是否實現，上傳文件是否能打開。對上傳文件的格式有何規定，系統是否有解釋信息，并檢查系統是否能夠做到。

        18.必填項檢查：應該填寫的項沒有填寫時系統是否都做了處理，對必填項是否有提示信息，如在必填項前加* 

        19.快捷鍵檢查：是否支持常用快捷鍵，如Ctrl+C Ctrl+V Backspace等，對一些不允許輸入信息的字段，如選人，選日期對快捷方式是否也做了限制。

        20.回車鍵檢查：在輸入結束后直接按回車鍵，看系統處理如何，會否報錯。