軟件測試的修行之道
作者:浪子 ?
一、 需求審查方面
? ? ?首先我們從最開始接觸的文檔開始节仿，那就是測需求文檔;需求審查主要是我們對需求文檔的理解确封，并熟透整個系統(tǒng)的每個功能和流程键袱，對后期所有的測試建立思路，后續(xù)的工作基本依照需求進(jìn)行操作浑厚，所以需求審查是一個很重要的一步股耽。
? ? ? 對于初次進(jìn)行需求審查，我采用我以前文章的方向方法钳幅，看完每一個模塊物蝙，就將這個模塊的功能流程做成流程圖。依次擴大敢艰，就將整個需求流程了解清楚诬乞，每次將流程圖多瀏覽幾次，差不多流程就這樣熟透钠导！
1震嫉、 需求變更
? ? ? 需求變更讓我們測試人員，在其中吃透苦頭牡属，每次需求的變更導(dǎo)致我們前期的工作好多都需要重新開始(流程圖克饶，測試點的提取漩怎，測試用例)炕檩。導(dǎo)致后續(xù)工作難于開展或經(jīng)常出現(xiàn)變更侯谁。
2定硝、 需求不明確
? ? ? 對于青少年足球系統(tǒng)而言肩民，需求全來自教育廳煤傍，里面同樣有很多需求不明確喷舀，全過程盡量與教育廳的需求進(jìn)行延伸担映，然后結(jié)合開發(fā)人員實際開發(fā)的效果废士，進(jìn)行測試過程！
二蝇完、 提取測試需求的過程:
? ? ? ?測試點提取我們依據(jù)每個測試階段的測試輸入的文檔(需求分析)結(jié)合前面的需求分析的審查官硝，覆蓋測試需求和隱藏的業(yè)務(wù)需求矗蕊，我們后期的測試，全是建立在提取的測試點之上進(jìn)行的氢架，可以說測試點提取是后續(xù)工作進(jìn)展必要必經(jīng)路徑傻咖。主要步驟就是，將每個模塊可能存在的問題全部羅列出來岖研，并對其最初可以輸入或者流程路徑的不同卿操，將每個測試點細(xì)分，寫成文檔孙援！
測試點提取的方法:
1害淤、 測試需求分析法
2、 功能點分析法
3拓售、 業(yè)務(wù)流程分析法
4窥摄、 節(jié)點分析法
5、 順序提取法
6础淤、 流程判斷法
? ? ? ?在測試點提取的過程中崭放，測試人員主要存在的問題是，除了輸入框鸽凶，鏈接币砂，按鈕，文字顯示等外吱瘩，流程測試點是最難提取的(提取此處測試點需要了解整個流程)道伟，我們采取的方式是，多閱讀需求書使碾，并且按照我們的思路將流程圖做出來蜜徽，在提取測試點，最終交于指導(dǎo)老師處票摇，一對一的修改拘鞋，另一方面，就是對那些隱藏的測試點提取矢门，對于初次做項目測試的我們盆色，基本沒有擇，只能和指導(dǎo)老師一起尋找和編寫祟剔！
測試點提取不局限于任何一種特定的方法隔躲。
很多時候測試點提取需求用到很多測試點提取方法
測試點提取需要根據(jù)測試階段，測試輸入文檔以及測試對象進(jìn)行合理的方法選擇物延。
測試點提取完畢后不等于已經(jīng)測試點提取完畢宣旱，還需要我們再次進(jìn)行測試點的審查，以防有遺漏或者是泛泛的情況
一份好的測試點提取文檔不但能夠覆蓋所有業(yè)務(wù)分支和功能點叛薯，而且能夠?qū)⑾嚓P(guān)隱藏需求體現(xiàn)出來
三浑吟、 測試用例設(shè)計
? ? 測試用例是為特定的目的而設(shè)計的一組測試輸入笙纤，執(zhí)行條件和預(yù)期結(jié)果，以便測試某個程序路基和核實是否滿足某個特定需求组力！
? ? ?在做功能測試時我們唯一能做的就是保證這個業(yè)務(wù)邏輯的正確性以及各個功能的盡可能的正確省容。業(yè)務(wù)和功能的正確性就要你自己去判斷了，我只是簡單寫下輸入燎字、輸出方面功能的測試腥椒。
? ? ? 作為一位功能測試人員，主要的職能就是進(jìn)行測試用例的設(shè)計上轩触，并根據(jù)測試用例執(zhí)行測試寞酿，通過全面的測試來驗證產(chǎn)品的質(zhì)量。因此測試用例提取脱柱，也從側(cè)面反映了一個測試人員的測試思路的嚴(yán)密和發(fā)散性伐弹，要做好功能測試，測試用例的重要性無法忽視,現(xiàn)就對”四川省青少年校園足球信息化管理系統(tǒng)”設(shè)計測試用例的流程和思路進(jìn)行總結(jié):
1) 首先要對測試用例的組織結(jié)構(gòu)進(jìn)行劃分
? ? ? 在進(jìn)行需求評審的時候榨为，我們就應(yīng)該根據(jù)需求對測試用例的結(jié)構(gòu)進(jìn)行分類惨好，對于我們現(xiàn)在做的青少年足球系統(tǒng)相對較大型的管理系統(tǒng)，那么測試用例就可以根據(jù)功能模塊來進(jìn)行分類
? ? ?對測試用例的組織結(jié)構(gòu)進(jìn)行劃分的思路随闺，主要根據(jù)需求文檔的測試切入點來進(jìn)行參考日川。
2) 根據(jù)功能點細(xì)致地設(shè)計測試用例
? ? ? 進(jìn)行完需求評審后，我們將會根據(jù)需求文檔及自己所負(fù)責(zé)的工作提交自己的設(shè)計文檔來進(jìn)行評審矩乐，可以參考設(shè)計文檔中的內(nèi)容提取出各個功能模塊中的功能點來設(shè)計測試用例龄句，如果是管理模塊，首先可以將增刪查改功能作為第一層功能點散罕，然后再根據(jù)必填項非空判斷分歇、輸入格式驗證來作為第二層功能點；
? ? ?劃分好功能點后欧漱，就可以利用等價類劃分职抡、邊界值分析等一些測試方法來編寫測試用例，并且可以進(jìn)行標(biāo)注误甚，這樣對于后期的測試用例整理相當(dāng)有幫助缚甩。
3) 執(zhí)行完一輪測試之后，都要對測試用例進(jìn)行補充和整理
? ? ? ?執(zhí)行完一輪測試之后窑邦，都會對所測試的內(nèi)容有進(jìn)一步的了解擅威，并且開發(fā)人員在實際開發(fā)過程中，會對某些功能的細(xì)節(jié)部分做出一些修改冈钦，測試人員應(yīng)該根據(jù)變更和熟悉程度對之前編寫的測試用例進(jìn)行完善郊丛，主要是對測試步驟的修改和異常情況的補充，提高測試用例對需求的覆蓋率，以便能發(fā)現(xiàn)更多的BUG宾袜。
4) 測試結(jié)束之后，根據(jù)測試用例整理出測試思路進(jìn)行總結(jié)
? ? ? 測試結(jié)束之后驾窟，測試人員在提交測試報告之后一般基本就會有一段短暫的休閑期庆猫，在此期間，再看看被自己不斷完善的測試用例绅络，根據(jù)用例中的標(biāo)注月培，可以將之前的測試思路很條理地整理出來，反思有哪些地方考慮不足恩急，這就是經(jīng)驗積累杉畜。
? ? ? ?做好這些工作之后，在面對領(lǐng)導(dǎo)問你功能測試會測試到哪些功能衷恭，會測試哪些情況此叠，執(zhí)行一輪測試所需的大概時間問題時，測試人員就可以根據(jù)自己編寫的測試用例進(jìn)行流利回答随珠。套用郭德剛的一句詞：做科學(xué)的人都是很嚴(yán)謹(jǐn)?shù)拿鹪４蠹易鳛槎际怯猩矸葑C的測試人員，只有工作做得細(xì)致嚴(yán)謹(jǐn)窗看，自身的水平才能得到提高茸歧。
A. 測試用例該如何設(shè)計(總)
? ? ? 在軟件測試工作中，測試用例設(shè)計和編寫時最重要的显沈，測試用例是測試工作的指指導(dǎo)软瞎，是軟件測試的必須遵循的原則，更是軟件測試質(zhì)量穩(wěn)定的基本保障拉讯！
1. 測試用例的測試
個人認(rèn)為涤浇，簡單來說，就是方法+經(jīng)驗遂唧，即比較成熟的測試用例設(shè)計方法為指導(dǎo)芙代，再加上設(shè)計人員個人的經(jīng)驗積累！
設(shè)計入手:
菜單樹
需求規(guī)格書盖彭，模塊的詳細(xì)規(guī)格圖
軟件的基本雛形
相關(guān)標(biāo)準(zhǔn)規(guī)格(軟件規(guī)格書)
?設(shè)計步驟
自我認(rèn)為多看需求文檔纹烹，多與需求設(shè)計人員溝通，至少保證覆蓋需求規(guī)格說明書和菜單樹的各項功能召边。
根據(jù)需求規(guī)格和菜單樹得出基本功能測試用例铺呵；
a) 等價類劃分法
將輸入范圍進(jìn)行劃分，測試每個等價類的代表性數(shù)據(jù)等同于測試該類的其他數(shù)據(jù)隧熙。確定有效和無效等價類片挂，一個等價類，如果有充足理由，可以再劃分為多個更小一些的等價類音念。部分更小一些的等價類沪饺，就憑借個人經(jīng)驗和用戶角度去考慮取舍。
b) 功能闷愤，路徑混合分析法:即實現(xiàn)某功能整葡，從進(jìn)入功能實現(xiàn)——退出的各種路徑的操作組合。
進(jìn)入:如果只有一種進(jìn)入方式讥脐，則就沒必要描述了遭居，2種或者2種以上的進(jìn)入方式，則需要分別描述旬渠。常見的進(jìn)入方式:主菜單進(jìn)入俱萍，鏈接進(jìn)入！
功能實現(xiàn):通過主頁導(dǎo)航界面進(jìn)入并實現(xiàn)相關(guān)功能
退出;為實現(xiàn)和已實現(xiàn)的功能退出
邊界值測試用例(所謂邊界條件告丢，是指輸入和輸出等價類中那些恰好處于邊界枪蘑，或超出邊界，或在邊界一下的狀態(tài))
a) 輸入值
b) 輸出值
c) 邊界狀態(tài)
在我們的足球管理系統(tǒng)中芋齿，對照片的縮放腥寇，就用到這一塊！
d) 其他邊界
容錯測試用例(錯誤猜測主要是一項依賴于直覺的非正式的過程觅捆，其基本思想是列舉出可可犯的錯誤或者錯誤易發(fā)生情況的清單)
a) 0或者空值
b) 負(fù)數(shù)
c) 刪除源文件內(nèi)容
? ? ?我們在賽事測試的過程中赦役，設(shè)計上傳參賽表明表，在測試過程中栅炒，我將部分信息刪除掂摔，進(jìn)行測試！
? ? ?并行測試用例(即多個功能同時進(jìn)行赢赊，比如:在青少年足球系統(tǒng)中乙漓，我們需要在發(fā)布賽事以后，同時進(jìn)入公示释移，并且下級報名依然不能給報名)
a) 并行測試與交叉測試的區(qū)別
1. 交叉測試是當(dāng)一個功能運行時叭披，另一功能打斷了原來事件的執(zhí)行，屬于被動玩讳；并行測試不會中斷原有程序涩蜘，是一個主動發(fā)起多功能。
2. 交叉測試發(fā)送在一瞬間熏纯，并行測試營同時運行一段時間同诫。
? ? ?串行測試用例(主要是單個模塊內(nèi)一串深層次路徑的測試，采用自頂而下的方法樟澜，從程序的頂部一直訪問至程序頂部)
? ? ?比如:像我們青少年足球系統(tǒng)误窖，我從首頁進(jìn)入賽事發(fā)布成功進(jìn)入公示頁面叮盘，然后再往上級返回到網(wǎng)頁首頁！
? ? ?交叉測試用例（交叉測試霹俺，即是中斷測試柔吼，當(dāng)一個事件執(zhí)行時，另一事件中斷原有事件的執(zhí)行丙唧。）
a) 兩不寫
1. 操作時間過短嚷堡，如:我們按下首頁的賽事發(fā)布管理按鈕
2. 使用概論低的界面，如:我們青少年足球系統(tǒng)中艇棕，下面的腳碼出的超鏈接，我們很少點擊
b) 兩必寫
1. 操作時間長串塑，如:在我們的青少年足球系統(tǒng)中沼琉，登陸賬號后，30分鐘對網(wǎng)頁沒有做任何處理桩匪，是否有報警觸發(fā)打瘪。
極限測試用例(壓力測試，就是個軟件施加一定的壓力傻昙，從而找出中的錯誤)
這一塊我在整個系統(tǒng)使用的很少闺骚，還處于學(xué)習(xí)階段！
a) 測試用例的檢查
1. 檢查妆档，寫完后自己在重頭到尾的檢查一遍僻爽，然后再拿給我們的小伙伴一起查看
2. 試用，測試用例寫完后應(yīng)該有一個使用期贾惦，在我們使用的過程中發(fā)現(xiàn)漏寫或者不合適的地方胸梆，應(yīng)及時增加或者更改。
b) “期望結(jié)果”與”測試方法”混淆须板，”期望結(jié)果”中出現(xiàn)原本該書寫在”測試方法”的步奏
? ? 測試方法 期望結(jié)果
? ?進(jìn)入到登錄界面碰镜，輸入正確的賬號和密碼進(jìn)行登陸。 能夠正確登陸
c) 但是上面是錯誤的习瑰，應(yīng)該按照下面方法進(jìn)行設(shè)計編寫
測試方法 期望結(jié)果 備注
? ? 進(jìn)入到登錄界面绪颖，輸入正確的賬號和密碼進(jìn)行登陸。 能夠正確登陸 賬號:2151021380(機構(gòu)管理)
? ? ?密碼:123456
B. 再次總結(jié)測試用例設(shè)計的要點甜奄，注意事項
? ? ? ?測試用例設(shè)計是個不斷思考的過程柠横，首先要搞清楚自己所測試的軟件系統(tǒng)的需求和功能，以及所有能變化的因素贺嫂，將這些功能點列成一個設(shè)計框架滓鸠，在分別細(xì)化各個功能點的測試方法和期望結(jié)果，細(xì)化過程中第喳，通過等價類劃分糜俗，正交矩陣等方法來詳細(xì)各個測試點，保證覆蓋的充分性，同時站在用戶的角度悠抹，考慮用戶常用和不常用的操作路徑珠月，依次來取舍測試要點，最后考慮設(shè)計步奏中的七種測試類型是否需要添加相應(yīng)用例楔敌。
? ? ? 測試用例設(shè)計也是個不斷優(yōu)化的過程啤挎，平時發(fā)現(xiàn)的bug，總結(jié)經(jīng)驗卵凑，積累更多的經(jīng)驗庆聘，測試用例也會更全面，軟件品質(zhì)也能得到更好的保障勺卢！
四伙判、 測試報告缺陷的提交和編寫
A. 強調(diào)這一塊的重要性！
下面就是我們在測試過程的滿足的條件:
? ? ?精簡的：缺陷的描述應(yīng)該是清晰而簡要的黑忱。
? ? ?正確的：提交的問題確實是一個缺陷宴抚。
? ? ?中立的：對缺陷及其特征進(jìn)行實事求是的描述，避免夸張甫煞、幽默菇曲、諷刺的態(tài)度，避免在測試缺陷報告中帶有個人感情色彩抚吠，因為這種感情色彩可能會影響團(tuán)隊之間的合作和溝通常潮。
? ? ?準(zhǔn)確的：準(zhǔn)確而明白地描述問題，不僅對做了什么進(jìn)行描述楷力，而應(yīng)該對發(fā)生或者發(fā)現(xiàn)了什么進(jìn)行描述蕊玷。
? ? ?隔離：盡量尋找簡短的步驟復(fù)現(xiàn)缺陷，即將缺陷進(jìn)行隔離弥雹。
? ? ?推廣：確定系統(tǒng)其他部分是否可能也存在同樣的問題垃帅，以及使用不同的數(shù)據(jù)時是否也會出現(xiàn)這種問題等。
? ? ?復(fù)現(xiàn)：確定系統(tǒng)是否可以復(fù)現(xiàn)這個問題剪勿，以及復(fù)現(xiàn)該缺陷的步驟贸诚。對于能夠復(fù)現(xiàn)的問題，應(yīng)該提供簡單的步驟和輸入
? ? ?證據(jù)：如同寫測試用例需要測試條件一樣厕吉，在缺陷報告中酱固，需要提供測試的期望結(jié)果和實際得到的輸出結(jié)果或者行為之間的差距，以及提供測試的依據(jù)头朱。
? ? ?評審：在提交缺陷報告之前运悲，最好有一個有經(jīng)驗的測試人員閱讀一遍。
缺陷報告編寫的過程:
B. 缺陷報告的提交
缺陷報告的提交项钮，在測試過程中班眯，我們采用了兩種方式
? ? 1希停、 提交給我們的指導(dǎo)老師！接下來的工作就是指導(dǎo)老師與相關(guān)開發(fā)人員溝通（這種提交的方式是我們前期的提交方式）
? ? 2署隘、 便是跳過我們的指導(dǎo)老師宠能，直接將問題和呈現(xiàn)過程交于開發(fā)人員，并且讓其快速修復(fù)磁餐！(這種方式比較快捷违崇，能夠快速的解決問題和加快開發(fā)的過程)
C. 如何編寫好的(易讀)的缺陷報告
1、 標(biāo)題(簡單明顯诊霹，不需要含有修飾語)
2羞延、 執(zhí)行動作（步驟）
3、 預(yù)期與實際結(jié)果
D. 缺陷報告的返回脾还，檢驗是否修改肴楷！
? ? ? ? 此環(huán)節(jié)，主要在我們提交缺陷報告后荠呐，開發(fā)人員將缺陷報告再次返回與我們測試人員，測試人員主要是檢查缺陷報告上面的問題是否已經(jīng)修復(fù)砂客，一遍我們能夠提交缺陷報告和了解缺陷的修復(fù)情況泥张！
E. 并描述與開發(fā)人員的交互過程
? ? ? 在我們與開放人員交互的時候：交互過程中存在的問題，當(dāng)部分子功能模塊做出來的時候鞠值，我們測試人員開始測試子功能模塊的時候媚创，測出問題的時候，我們便直接與開發(fā)人員提出此問題彤恶，可能是剛開始合作钞钙，還有他們對自己寫的代碼還有強烈的自信感！對我們的問題采用避讓的方式声离，在我們繼續(xù)的講述和演示功能的過程芒炼，才得以讓他們信服。現(xiàn)在這些問題都不存在术徊，都能夠在規(guī)定的時間完成每個功能的修復(fù)本刽！
F. 過程中的問題如何解決
? ? ? ?輸入框和文字顯示在此不做詳細(xì)說明，我在項目中主要是承擔(dān)邏輯很強的賽事模塊赠涮，這塊設(shè)計的邏輯和流程交互挺多子寓，除此測試這塊的時候很難把握流程問題，整個項目在隨時改變和需求分析存在一定的差異笋除，所以造成這塊測試邏輯流程比較難以實施斜友，為了更好的完成測試，我采用了垃它，進(jìn)行測試之前鲜屏，然相關(guān)模塊開發(fā)的人員演示一下流程烹看，讓我更好的進(jìn)程下一步測試！
G. 最后對測試缺陷報告的綜述(好方法墙歪，注意事項听系，怎樣才能夠做好測試缺陷報告)
測試執(zhí)行過程注意事項：
? ? ? ?注意前提條件和特殊說明
? ? ? ?測試用例要全部執(zhí)行
? ? ? ?不要忽視任何偶然現(xiàn)象
? ? ? ?加強測試過程的記錄
? ? ? ? 詳細(xì)預(yù)期與實際的不一致等
原創(chuàng)文章，轉(zhuǎn)載請說明來路虹菲，謝謝
