談談測試用例 測試用例
測試用例分為兩種，一種是功能測試用例，一種是業務流程用例（Business Test Case）。功能測試用例關注的更多的是這個功能是如何實現的，比如添加，刪除這樣的用例，還包括這個功能的UI檢查，關聯檢查等。這種用例不強調業務之間的流轉或者數據的流轉，關注的是這個功能本身的正確性。這種用例一般是最容易寫的，因為步驟不會很多，只需要把你的詳細的check點寫出來就好了。這種用例用到的黑盒測試方法一般有邊界值，等價類等等。業務流程用例關注更多的是模塊之間的交互，入口對應模塊的實現。一般一個業務流程用例就包含了一個完整的操作流程，也是模擬用戶操作最多的一種檢查用例。這里會有很多分支或者數據的流轉，如果分支過多或者入口過多，可以用正交分類法去掉一些。這種用例需要參考的文檔是概要設計和詳細設計。為什么是這兩個文檔呢，因為這里可以看到系統的架構，業務的交互以及數據的流轉，所以對這種用例的設計很有幫助。這種用例用到的黑盒測試方法是場景法。
一、測試用例設計方法
1.1.
白盒測試的測試用例設計（邏輯覆蓋法）
這種方法是從程序內部的邏輯結構出發選取測試用例，因此要求測試用例設計人員對程序的邏輯結構十分清楚，甚至應掌握源程序的所有細節。
1.1.1.
語句覆蓋
設計若干測試用例，運行被測試程序，使得每個可執行語句至少執行一次。
1.1.2.
判斷覆蓋
設計若干測試用例，運行被測試程序，使得程序中每個判斷的真值分支和假值分支至少經歷一次。對象是每個判斷。
1.1.3.
條件覆蓋
設計測試用例，運行被測試程序，使得程序中每個判斷中的每個條件的可能取值情況至少滿足一次。對象是每個條件。
1.1.4.
判斷—條件覆蓋
設計測試用例，運行被測試程序，使得程序的每個判斷中的每個條件的所有可能取值組合至少出現一次，并且使每個判斷本身的判定結果也至少出現一次。
1.1.5.
路徑覆蓋
設計測試用例，覆蓋程序中所有的可能路徑。
1.2.
黑盒測試的測試用例設計
1.2.1.
等價類劃分
是把所有可能的輸入數據,即程序的輸入域劃分成若干部分（子集）,然后從每一個子集中選取少數具有代表性的數據作為測試用例.
該方法是一種重要的,常用的黑盒測試用例設計方法.
該種設計方法分為劃分等價類表和選取測試用例兩步。
劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對于揭露程序中的錯誤都是等效的.并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試.因此,可以把全部輸入數據合理劃分為若干等價類,在每一個等價類中取一個數據作為測試的輸入條件,就可以用少量代表性的測試數據.取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.
有效等價類:是指對于程序的規格說明來說是合理的、有意義的輸入數據構成的集合.利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能.
無效等價類是指對于程序的規格說明書來說不合理的、無意義的輸入數據構成的集合.利用無效等價類可檢查程序中功能和性能的實現是否有不符合規格說明書的地方。.
設計測試用例時,要同時考慮這兩種等價類.因為,軟件不僅要能接收合理的數據,也要能經受意外的考驗.這樣的測試才能確保軟件具有更高的可靠性.
等價類劃分的原則：
（1）
如果輸入條件規定了取值范圍或值得個數，則可以確立一個有效等價類和兩個無效等價類。如：1 < x < 99，則1 < x < 99是有效等價類，而x > = 99 和 x < = 1 就是兩個無效等價類；
（2）
如果輸入條件規定了輸入值的集合，或者是規定了“必須如何”的條件，這是可以確立一個有效等價類和一個無效等價類。如：必須為正整數，則取正整數是有效等價類，而非正整數的是無效等價類；
（3）
如果輸入條件是一個布爾值，則可以確定一個有效等價類和一個無效等價類，則滿足條件的為有效等價類，而不滿足條件的為無效等價類；
（4）
如果規定了輸入數據的一組值(假定n個)，并且程序要對每個輸入值分別進行處理。這樣可以為每一個輸入值確立一個有效等價類，此外可以確立針對這組值確立一個無效等價類，如：{1、5、10、20}，則取1、5、10、20分別建立有效等價類，而非1、5、10、20的值是無效等價類；
（5）
如果規定了輸入數據必須遵守的規則，則可以確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）。如：則滿足規則的為有效等價類，則不滿足規則的分別建立無效等價類；
（6）
如果在確知已劃分的等價類中各元素在程序中的處理方式不同，則應將此等價類進一步分成更小的等價類。
測試用例設計與選擇：
（1）
為每一個等價類規定一個唯一的編號。
（2）
設計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，重復這一步，直到所有的有效等價類都被覆蓋為止。
（3）
設計一個新的測試用例，使其近覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直到所有的無效等價類都被覆蓋為止。
1.2.2.
邊界值分析
是對等價劃分方法的補充。
（1）
邊界值分析方法的考慮:
長期的測試工作經驗告訴我們,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.
使用邊界值分析方法設計測試用例，首先應確定邊界情況。通常輸入等價類與輸出等價類的邊界，就是應著重測試的邊界情況，應當選取正好等于、剛剛大于、或剛剛小于邊界的值作為測試數據。
（2）
邊界值分析方法選擇測試用例的原則在很多方面與等價劃分方法類似。
A.如果輸入條件規定了值的范圍，則應取剛達到這個范圍的邊界值，及剛剛超越這個范圍邊界的值作為測試輸入數據。
B.如果輸入條件規定了值的個數，則用最大個數、最小個數、比最大個數多1，比最小個數少1的數做為測試數據。
C.根據規格說明書的每個輸出條件，使用前面的原則A。
D.根據規格說明書的每個輸出條件，使用前面的原則B。
E.如果程序的規格說明書給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最后一個元素作為測試用例。
F.如果程序中使用了一個內部數據結構，則應當選擇這個內部數據結構的邊界值作為測試用例。
1.2.3.
錯誤推測法
錯誤推測法: 基于經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.
錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入數據和輸出數據為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測試用例.
二、當前國內軟件企業測試流程不規范的原因分析
1） 從事物的發展規律看，軟件測試行業在我國還是新興行業，目前還處于起步和探索期，雖然國外的同行業發展到了一定階段，但事實上他們也在不斷的否定自我并探索著更成熟的方法、尋求著更有效的方案；而國內的測試行業發展期不過10來年，所謂的測試管理流程不規范，也就情有可原了。
2） 從企業個體角度講，測試部門的整頓和加強，按照企業自身發展的優先層次，還沒有被納入優先解決的程度，開拓市場、簽訂定單才是首要問題，也是維系企業生存發展的命脈。當然國內很多優秀的大中型軟件公司的測試部門相對完善，如神州數碼、用友、聯想等，他們和大型跨國軟件公司的合作，也從中汲取了寶貴的管理經驗。
3） 還有一個普遍存在的問題。近幾年國內軟件企業為了加強企業的競爭優勢和名氣提升，通常大搞特搞ISO/CMM認證；筆者也很支持這么做，但更關注的是通過這些認證后的企業有多少真正按照那些規范、設計的標準在后續的測試或軟件開發管理工作中著手開展下去呢？社會上流傳著這樣的話：任何認證到中國，最后都免不了砸牌兒！筆者讀書時很多高校搞的MCSE認證，有培訓機構明目張膽聲稱\"百分百通過率\"！當年也有專門媒體報道此事。聽到這樣的話，我們都會寒心，這里真心希望我們的軟件企業通過ISO/CMM后真正為企業的內部軟件開發流程帶來一點新生的曙光。
4） 最后一個原因，我想是企業內部測試管理人員和技術人員技能的不足，還有自身工作態度的不夠端正。有了再好的規范標準，沒人遵守不行！沒人實施不行！應該說，很多中小軟件企業的高層都或多或少的逐漸意識到軟件測試的重要性和必要性，以及它的標準化、流程化改革的緊迫性，但也有很多的工程師、技術人員并不理會這套，常常在實際工作中投機取巧；也有很多測試管理人員后天的經驗不足、技能不夠，對公司測試管理工作考慮不到位，和開發工程師交流不充分，和上層領導反映不及時等等。
總之，任何問題的出現都不是單方面的原因，從宏觀的社會形勢到微觀的企業個人，都有無可推卸的責任；正因為如此，解決問題也要對癥下藥，如何完善軟件測試流程，就要從小處出發；本文不可能將軟件測試流程優化的話題闡述的面面俱到，因此只從管理角度談談測試用例在測試活動中的重要性，以及測試用例管理流程的一些改進思路。
文章來源于領測軟件測試網 http://www.kjueaiud.com/