一個完整系統的測試過程
首先我們從最開始接觸的文件開始，那就是測需求文件;需求審查主要是我們對需求文件的理解，並熟透整個系統的每個功能和流程，對後期所有的測試建立思路，後續的工作基本依照需
一、 ofollow,noindex"> 需求 審查方面
首先我們從最開始接觸的文件開始，那就是測需求文件;需求審查主要是我們對需求文件的理解，並熟透整個系統的每個功能和流程，對後期所有的 測試 建立思路，後續的工作基本依照需求進行操作，所以需求審查是一個很重要的一步。
對於初次進行需求審查，我採用我以前文章的方向方法，看完每一個模組，就將這個模組的功能流程做成流程圖。依次擴大，就將整個需求流程瞭解清楚，每次將流程圖多瀏覽幾次，差不多流程就這樣熟透！
1、 需求變更
需求變更讓我們 測試人員 ，在其中吃透苦頭，每次需求的變更導致我們前期的工作好多都需要重新開始(流程圖，測試點的提取， 測試 用例 )。導致後續工作難於開展或經常出現變更。
2、 需求不明確
對於青少年足球系統而言，需求全來自教育廳，裡面同樣有很多需求不明確，全過程儘量與教育廳的需求進行延伸，然後結合 開發 人員實際 開發 的效果，進行測試過程！
二、 提取測試需求的過程:
測試點提取我們依據每個測試階段的測試輸入的文件(需求分析)結合前面的需求分析的審查，覆蓋測試需求和隱藏的業務需求，我們後期的測試，全是建立在提取的測試點之上進行的，可以說測試點提取是後續工作進展必要必經路徑。主要步驟就是，將每個模組可能存在的問題全部羅列出來，並對其最初可以輸入或者流程路徑的不同，將每個測試點細分，寫成文件！
測試點提取的方法:
1、 測試需求分析法
2、 功能點分析法
3、 業務流程分析法
4、 節點分析法
5、 順序提取法
6、 流程判斷法
在測試點提取的過程中，測試人員主要存在的問題是，除了輸入框，連結，按鈕，文字顯示等外，流程測試點是最難提取的(提取此處測試點需要了解整個流程)，我們採取的方式是，多閱讀需求書，並且按照我們的思路將流程圖做出來，在提取測試點，最終交於指導老師處，一對一的修改，另一方面，就是對那些隱藏的測試點提取，對於初次做專案測試的我們，基本沒有擇，只能和指導老師一起尋找和編寫！
Ø 測試點提取不侷限於任何一種特定的方法。
Ø 很多時候測試點提取需求用到很多測試點提取方法
Ø 測試點提取需要根據測試階段，測試輸入文件以及測試物件進行合理的方法選擇。
Ø 測試點提取完畢後不等於已經測試點提取完畢，還需要我們再次進行測試點的審查，以防有遺漏或者是泛泛的情況
Ø 一份好的測試點提取文件不但能夠覆蓋所有業務分支和功能點，而且能夠將相關隱藏需求體現出來
三、 測試用例設計
測試用例是為特定的目的而設計的一組測試輸入，執行條件和預期結果，以便測試某個程式路基和核實是否滿足某個特定需求！
在做 功能測試 時我們唯一能做的就是保證這個業務邏輯的正確性以及各個功能的儘可能的正確。業務和功能的正確性就要你自己去判斷了，我只是簡單寫下輸入、輸出方面功能的測試。
作為一位功能測試人員，主要的職能就是進行測試用例的設計上，並根據測試用例執行測試，通過全面的測試來驗證產品的質量。因此測試用例提取，也從側面反映了一個測試人員的測試思路的嚴密和發散性，要做好功能測試，測試用例的重要性無法忽視,現就對”四川省青少年校園足球資訊化管理系統”設計測試用例的流程和思路進行總結:
1) 首先要對測試用例的組織結構進行劃分
在進行需求評審的時候，我們就應該根據需求對測試用例的結構進行分類，對於我們現在做的青少年足球系統相對較大型的管理系統，那麼測試用例就可以根據功能模組來進行分類
對測試用例的組織結構進行劃分的思路，主要根據需求文件的測試切入點來進行參考。
2) 根據功能點細緻地設計測試用例
進行完需求評審後，我們將會根據需求文件及自己所負責的工作提交自己的設計文件來進行評審，可以參考設計文件中的內容提取出各個功能模組中的功能點來設計測試用例，如果是管理模組，首先可以將增刪查改功能作為第一層功能點，然後再根據必填項非空判斷、輸入格式驗證來作為第二層功能點；
劃分好功能點後，就可以利用等價類劃分、邊界值分析等一些 測試方法 來編寫測試用例，並且可以進行標註，這樣對於後期的測試用例整理相當有幫助。
3) 執行完一輪測試之後，都要對測試用例進行補充和整理
執行完一輪測試之後，都會對所測試的內容有進一步的瞭解，並且開發人員在實際開發過程中，會對某些功能的細節部分做出一些修改，測試人員應該根據變更和熟悉程度對之前編寫的測試用例進行完善，主要是對測試步驟的修改和異常情況的補充，提高測試用例對需求的覆蓋率，以便能發現更多的 BUG 。
4) 測試結束之後，根據測試用例整理出測試思路進行總結
測試結束之後，測試人員在提交測試報告之後一般基本就會有一段短暫的休閒期，在此期間，再看看被自己不斷完善的測試用例，根據用例中的標註，可以將之前的測試思路很條理地整理出來，反思有哪些地方考慮不足，這就是經驗積累。
做好這些工作之後，在面對領導問你功能測試會測試到哪些功能，會測試哪些情況，執行一輪測試所需的大概時間問題時，測試人員就可以根據自己編寫的測試用例進行流利回答。套用郭德剛的一句詞：做科學的人都是很嚴謹的。大家作為都是有身份證的測試人員，只有工作做得細緻嚴謹，自身的水平才能得到提高。
A. 測試用例該如何設計(總)
在 軟體測試 工作中，測試用例設計和編寫時最重要的，測試用例是測試工作的指指導，是 軟體測試 的必須遵循的原則，更是軟體測試質量穩定的基本保障！
1. 測試用例的測試
個人認為，簡單來說，就是方法+經驗，即比較成熟的測試用例設計方法為指導，再加上設計人員個人的經驗積累！
Ø 設計入手:
ü 選單樹
ü 需求規格書，模組的詳細規格圖
ü 軟體的基本雛形
ü 相關標準規格(軟體規格書)
Ø 設計步驟
自我認為多看需求文件，多與需求設計人員溝通，至少保證覆蓋需求規格說明書和選單樹的各項功能。
ü 根據需求規格和選單樹得出基本功能測試用例；
a) 等價類劃分法
將輸入範圍進行劃分，測試每個等價類的代表性資料等同於測試該類的其他資料。確定有效和無效等價類，一個等價類，如果有充足理由，可以再劃分為多個更小一些的等價類。部分更小一些的等價類，就憑藉個人經驗和使用者角度去考慮取捨。
b) 功能，路徑混合分析法:即實現某功能，從進入功能實現——退出的各種路徑的操作組合。
進入:如果只有一種進入方式，則就沒必要描述了，2種或者2種以上的進入方式，則需要分別描述。常見的進入方式:主選單進入，連結進入！
功能實現:通過主頁導航介面進入並實現相關功能
退出;為實現和已實現的功能退出
ü 邊界值測試用例(所謂邊界條件，是指輸入和輸出等價類中那些恰好處於邊界，或超出邊界，或在邊界一下的狀態)
a) 輸入值
b) 輸出值
c) 邊界狀態
在我們的足球管理系統中，對照片的縮放，就用到這一塊！
d) 其他邊界
ü 容錯測試用例(錯誤猜測主要是一項依賴於直覺的非正式的過程，其基本思想是列舉出可可犯的錯誤或者錯誤易發生情況的清單)
a) 0或者空值
b) 負數
c) 刪除原始檔內容
我們在賽事測試的過程中，設計上傳參賽表明表，在測試過程中，我將部分資訊刪除，進行測試！
ü 並行測試用例(即多個功能同時進行，比如:在青少年足球系統中，我們需要在釋出賽事以後，同時進入公示，並且下級報名依然不能給報名)
a) 並行測試與交叉測試的區別
1. 交叉測試是當一個功能執行時，另一功能打斷了原來事件的執行，屬於被動；並行測試不會中斷原有程式，是一個主動發起多功能。
2. 交叉測試傳送在一瞬間，並行測試營同時執行一段時間。
ü 序列測試用例(主要是單個模組內一串深層次路徑的測試，採用自頂而下的方法，從程式的頂部一直訪問至程式頂部)
比如:像我們青少年足球系統，我從首頁進入賽事發布成功進入公示頁面，然後再往上級返回到網頁首頁！
ü 交叉測試用例（交叉測試，即是中斷測試，當一個事件執行時，另一事件中斷原有事件的執行。）
a) 兩不寫
1. 操作時間過短，如:我們按下首頁的賽事發布管理按鈕
2. 使用概論低的介面，如:我們青少年足球系統中，下面的腳碼出的超連結，我們很少點選
b) 兩必寫
1. 操作時間長，如:在我們的青少年足球系統中，登陸賬號後，30分鐘對網頁沒有做任何處理，是否有報警觸發。
ü 極限測試用例(壓力測試，就是個軟體施加一定的壓力，從而找出中的錯誤)
這一塊我在整個系統使用的很少，還處於學習階段！
a) 測試用例的檢查
1. 檢查，寫完後自己在重頭到尾的檢查一遍，然後再拿給我們的小夥伴一起檢視
2. 試用，測試用例寫完後應該有一個使用期，在我們使用的過程中發現漏寫或者不合適的地方，應及時增加或者更改。
b) “期望結果”與”測試方法”混淆，”期望結果”中出現原本該書寫在”測試方法”的步奏
|
測試方法 |
期望結果 |
|
進入到登入介面，輸入正確的賬號和密碼進行登陸。 |
能夠正確登陸 |
c) 但是上面是錯誤的，應該按照下面方法進行設計編寫
|
測試方法 |
期望結果 |
備註 |
|
進入到登入介面，輸入正確的賬號和密碼進行登陸。 |
能夠正確登陸 |
賬號:2151021380 (機構管理) 密碼:123456 |
B. 再次總結測試用例設計的要點，注意事項
測試用例設計是個不斷思考的過程，首先要搞清楚自己所測試的軟體系統的需求和功能，以及所有能變化的因素，將這些功能點列成一個設計框架，在分別細化各個功能點的測試方法和期望結果，細化過程中，通過等價類劃分，正交矩陣等方法來詳細各個測試點，保證覆蓋的充分性，同時站在使用者的角度，考慮使用者常用和不常用的操作路徑，依次來取捨測試要點，最後考慮設計步奏中的七種測試型別是否需要新增相應用例。
測試用例設計也是個不斷優化的過程，平時發現的 bug ，總結經驗，積累更多的經驗，測試用例也會更全面，軟體品質也能得到更好的保障！
四、 測試報告 缺陷 的提交和編寫
A. 強調這一塊的重要性！
下面就是我們在測試過程的滿足的條件:
精簡的：缺陷的描述應該是清晰而簡要的。
正確的：提交的問題確實是一個缺陷。
中立的：對缺陷及其特徵進行實事求是的描述，避免誇張、幽默、諷刺的態度，避免在測試缺陷報告中帶有個人感情色彩，因為這種感情色彩可能會影響團隊之間的合作和溝通。
準確的：準確而明白地描述問題，不僅對做了什麼進行描述，而應該對發生或者發現了什麼進行描述。
隔離：儘量尋找簡短的步驟復現缺陷，即將缺陷進行隔離。
推廣：確定系統其他部分是否可能也存在同樣的問題，以及使用不同的資料時是否也會出現這種問題等。
復現：確定系統是否可以復現這個問題，以及復現該缺陷的步驟。對於能夠復現的問題，應該提供簡單的步驟和輸入
證據：如同寫測試用例需要測試條件一樣，在缺陷報告中，需要提供測試的期望結果和實際得到的輸出結果或者行為之間的差距，以及提供測試的依據。
評審：在提交缺陷報告之前，最好有一個有經驗的測試人員閱讀一遍。
缺陷報告編寫的過程:
B. 缺陷報告的提交
缺陷報告的提交，在測試過程中，我們採用了兩種方式
1、 提交給我們的指導老師！接下來的工作就是指導老師與相關開發人員溝通（這種提交的方式是我們前期的提交方式）
2、 便是跳過我們的指導老師，直接將問題和呈現過程交於開發人員，並且讓其快速修復！(這種方式比較快捷，能夠快速的解決問題和加快開發的過程)
C. 如何編寫好的(易讀)的缺陷報告
1、 標題(簡單明顯，不需要含有修飾語)
2、 執行動作（步驟）
3、 預期與實際結果
D. 缺陷報告的返回，檢驗是否修改！
此環節，主要在我們提交缺陷報告後，開發人員將缺陷報告再次返回與我們測試人員，測試人員主要是檢查缺陷報告上面的問題是否已經修復，一遍我們能夠提交缺陷報告和了解缺陷的修復情況！
E. 並描述與開發人員的互動過程
在我們與開放人員互動的時候：互動過程中存在的問題，當部分子功能模組做出來的時候，我們測試人員開始測試子功能模組的時候，測出問題的時候，我們便直接與開發人員提出此問題，可能是剛開始合作，還有他們對自己寫的程式碼還有強烈的自信感！對我們的問題採用避讓的方式，在我們繼續的講述和演示功能的過程，才得以讓他們信服。現在這些問題都不存在，都能夠在規定的時間完成每個功能的修復！
F. 過程中的問題如何解決
輸入框和文字顯示在此不做詳細說明，我在專案中主要是承擔邏輯很強的賽事模組，這塊設計的邏輯和流程互動挺多，除此測試這塊的時候很難把握流程問題，整個專案在隨時改變和需求分析存在一定的差異，所以造成這塊測試邏輯流程比較難以實施，為了更好的完成測試，我採用了，進行測試之前，然相關模組開發的人員演示一下流程，讓我更好的程序下一步測試！
G. 最後對測試缺陷報告的綜述(好方法，注意事項，怎樣才能夠做好測試缺陷報告)
測試執行過程注意事項：
Ø 注意前提條件和特殊說明
Ø 測試用例要全部執行
Ø 不要忽視任何偶然現象
Ø 加強測試過程的記錄
Ø 詳細預期與實際的不一致等
原文轉自：https://blog.csdn.net/Va_Tsai/article/details/51485127