現在再給你個測試任務，你會怎麼測試？
撇開自動化測試、效能測試，從功能測試的角度，來闡述下自己的測試過程。
一、測試思路構建：新的任務分配到手中，可能只是乙個簡單的bug，也可能是乙個完整新構建專案。首先要讀懂需求所需、業務想要。相關的需求文件當然要仔仔細細的看一遍甚至多遍、把涉及的點麵理解到位。我覺得在這裡要做到以下幾點：
<1>，分塊包括狀態和頁面。把乙個系統中的主要功能所有頁面分塊管理，比如如果是購物系統，需要明白設計點對前後流程的影響，從加入收藏、加入購物車、提交待結算、提交待結算刪除訂單、結算完成、結算完成刪除訂單等各個狀態值。理清楚各個狀態值非常的重要，通常看到乙個內容框的值及其狀態在製作頁面、提交頁面、檢視頁面等都不同，防止遺漏，各個場景都需進行建立相應的測試用例及驗證思路。
<2>，找線（有始有終）。從開始到完成，我們需要有始有終。什麼意思呢，比如oa系統管理中的請假管理，如果請假人提出請假管理，那麼其領導再審批得過程中，可以同意其審批申請，也可以不同意其請假申請，但是，不管同意不同意，我們需要把流程節點回歸到請假人初，讓請假人知悉這個結果。該任務從請假人處新建到請假人收到通知辦結，就是乙個有是有終的線。當然負責的業務有流程中不會只有一條線，所以在這裡我們就需要把所有的線分離出來，將來做乙個單獨的業務流程測試。
<3>，估量測試時間，有經驗的測試在這裡就能夠根據業務流程和業務功能等不同的複雜度大概估計測試時間，其實這個非常重要，比如乙個專案有三十天的時間測試，那麼你就不能三十天都在測試，你最多有二十天的測試時間來保證能覆蓋到整個專案的70%-80%的bug，還有十天的冷靜期。這十天時間，你可以轉換思路，從不同的角度來測試專案，比如再次翻看相關詳細設計需求文件，檢視資料庫、跟蹤日誌，或者可以再次從整體思維能力看一遍資料庫。這些會幫助你把專案覆蓋度提高到90%以上。
整體思路構建的好處可以很好的解決我們的測試時間，從整體到區域性，再從區域性到整體，將分析到的內容羅列其中，包括其中。就能很好地完成測試工作。
二、測試方法分析：根據不同的專案，分解不同的測試方法，專案中常用的測試方法分析：
<1>，順序測試：顧名思義就是按照順序，乙個頁面從上往下、乙個流程從開始到結束。這個方法是在功能測試中非常常用的方法，也是對於小的功能塊查詢bug最多的方法。
<2>，關聯測試：所謂關聯測試，我理解的是：乙個功能點的測試你要考慮到所有與之關聯的內容。比如我們常見請假管理中，公司的年假每年每人都有不同的天數設定。如果再請假申請頁面提出請假2天的申請，那麼與之關聯的分別有：a，請假總天數是否大於等於2天；b，請假審批頁面改天數是否是兩天；c，請假檢視頁面該天數是否是兩天；d，請假申請完結後，請假總天數是否發生相應改變。
<3>，合併測試：在測試中，我們常常會遇到一些功能模組，代用同乙個介面或者同一頁面，那麼在測試的時候，我們可以將其歸為一類中的不同，然後進行合併測試，挑其中乙個進行詳細測試，其他進行驗證性測試即可。
<4>，反規則測試：在測試中，一般需求會給一些規範，比如會有關於數字的範圍或者小數的保留位數等規則，在驗證時，就需要進行反規則測試，按照相反的思路進行測試。其實反規則測試也是我們寫測試用例時常用的用例，比較常見。
<5>，拓展測試：拓展我覺得就是想多一點，比如一些文字資訊只有字數要求，那麼對於就要多想一些，比如對特殊字元的相容、對空字元的校驗等，多想一些，就能讓服務更完美一些。
不同的人可能常用的測試方法不同，但是不管什麼方法，就是在有限的時間內容盡可能的覆蓋專案，減少生產上bug發生率，只要自己用的開發，用的順手，不一定是這麼些的。
<1>，測試過程中參考，《需求設計文件》、《詳細設計文件》（可能設計**邏輯，盡量看懂）、專案demo（如果有的話）、資料庫、日誌資訊、測試用例。
<2>，測試編寫，《測試用例》（前期工作，後續跟蹤專案需求，補充完善）、《測試日誌》（跟蹤自己每天的工作，對整個測試任務把控）、《使用者使用手冊》（如果需要編寫的話，盡可能詳細）、《測試總結》（對整個測試過程進行總結，體現工作思路、bug管理、專案總結等）。
四，細心執行，及時反饋。
做好了準備工作，接下來進行測試的過程中，就需要我們根據測試用例進行測試，測試過程一點要細心，並且及時將測試進度與遇到的問題與專案經理進行反饋，做好溝通，更好的完成測試工作。。。
JUnit單元測試感悟
以前用dotnet的時候，曾經用過nunit，後來改用testdriven。但是由於專案不大，而且都是看得見摸的著的東西，直接就能看到執行介面，所以感覺用處並不是太大，也就是當作專案要求的規範來寫寫。現在，公司要求開發過程中必須用junit寫單元測試用例，即使以前的沒有寫測試用例的 也要補寫出來。寫...
JUnit單元測試感悟
以前用dotnet的時候，曾經用過nunit，後來改用testdriven。但是由於專案不大，而且都是看得見摸的著的東西，直接就能看到執行介面，所以感覺用處並不是太大，也就是當作專案要求的規範來寫寫。現在，公司要求開發過程中必須用junit寫單元測試用例，即使以前的沒有寫測試用例的 也要補寫出來。寫...
我對測試的感悟 2009 10 18
今天下午去復旦大學參加了 5etesting 組織的乙個測試人員的交流活動，該活動主要是介紹了 e測中國團隊和他們現階段的乙個專案和產品。其中重點介紹了 qtp專案，活動之前我對 qtp是完全不了解，通過期間的介紹我才知道它是 quicktest professional 的縮寫，是個自動化測試的框...