軟件測試的修行之道
作者:浪子 ?
一、 需求審查方面
? ? ?首先我們從最開始接觸的文檔開始，那就是測需求文檔;需求審查主要是我們對需求文檔的理解，并熟透整個系統的每個功能和流程，對后期所有的測試建立思路，后續的工作基本依照需求進行操作，所以需求審查是一個很重要的一步。
? ? ? 對于初次進行需求審查，我采用我以前文章的方向方法，看完每一個模塊，就將這個模塊的功能流程做成流程圖。依次擴大，就將整個需求流程了解清楚，每次將流程圖多瀏覽幾次，差不多流程就這樣熟透！
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. 最后對測試缺陷報告的綜述(好方法，注意事項，怎樣才能夠做好測試缺陷報告)
測試執行過程注意事項：
? ? ? ?注意前提條件和特殊說明
? ? ? ?測試用例要全部執行
? ? ? ?不要忽視任何偶然現象
? ? ? ?加強測試過程的記錄
? ? ? ? 詳細預期與實際的不一致等
原創文章，轉載請說明來路，謝謝
