1、測試過程介紹第1頁，共28頁，2022年，5月20日，12點4分，星期四本次交流的主要內容本次交流的目的測試的分類測試的階段華為的測試流程一些值得借鑒的地方軟件部對測試的一些建議測試部對軟件部的一些建議的收集第2頁，共28頁，2022年，5月20日，12點4分，星期四本次交流的目的通過對測試方法的簡單回顧和對華為公司測試過程的分析和借鑒, 希望在以后對測試方法或者過程的優化改進中有所幫助.第3頁，共28頁，2022年，5月20日，12點4分，星期四測試的分類兩種常用的測試方法 黑盒測試 白盒測試第4頁，共28頁，2022年，5月20日，12點4分，星期四黑盒測試的測試用例設計 等價類劃分 邊界

2、值分析 錯誤推測法 因果圖第5頁，共28頁，2022年，5月20日，12點4分，星期四等價類劃分等價類劃分是一種典型的黑盒測試方法，使用這一方法時，完全不考慮程序的內部結構，只依據程序的規格說明來設計測試用例。等價類劃分方法把所有可能的輸入數據，即程序的輸入域劃分成若干部分，然后從每一部分中選取少數有代表性的數據做為測試用例。第6頁，共28頁，2022年，5月20日，12點4分，星期四使用這一方法設計測試用例要經歷劃分等價類（列出等價類表）和選取測試用例兩步。劃分等價類等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對于揭露程序中的錯誤都是等效的。測試某等價類的代表值就等價于對這一類其

3、它值的測試。第7頁，共28頁，2022年，5月20日，12點4分，星期四等價類的劃分有兩種不同的情況： 有效等價類：是指對于程序的規格說明來說，是合理的，有意義的輸入數據構成的集合。 無效等價類：是指對于程序的規格說明來說，是不合理的，無意義的輸入數據構成的集合。在設計測試用例時，要同時考慮有效等價類和無效等價類的設計。第8頁，共28頁，2022年，5月20日，12點4分，星期四例如，在程序的規格說明中，對輸入條件有一句話： “ 項數可以從1到999 ” 則有效等價類是“1項數999”兩個無效等價類是“項數1”或“項數999”。在數軸上表示成: 第9頁，共28頁，2022年，5月20日，12點

4、4分，星期四邊界值分析邊界值分析也是一種黑盒測試方法，是對等價類劃分方法的補充。人們從長期的測試工作經驗得知，大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。第10頁，共28頁，2022年，5月20日，12點4分，星期四比如，在做三角形計算時，要輸入三角形的三個邊長：A、B和C。 我們應注意到這三個數值應當滿足 A0、B0、C0、 ABC、ACB、BCA，才能構成三角形。但如果把六個不等式中的任何一個大于號“”錯寫成大于等于號“”，那就不能構成三角形。問題恰出現在容易被疏忽的邊界附近。第11頁，共28頁，2022年，5月2

5、0日，12點4分，星期四這里所說的邊界是指，相當于輸入等價類和輸出等價類而言，稍高于其邊界值及稍低于其邊界值的一些特定情況。使用邊界值分析方法設計測試用例，首先應確定邊界情況。應當選取正好等于，剛剛大于，或剛剛小于邊界的值做為測試數據，而不是選取等價類中的典型值或任意值做為測試數據。 第12頁，共28頁，2022年，5月20日，12點4分，星期四錯誤推測法人們也可以靠經驗和直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的例子。這就是錯誤推測法。錯誤推測法的基本想法是：列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據它們選擇測試用例。第13頁，共28頁，2022年，5

6、月20日，12點4分，星期四因果圖因果圖的適用范圍如果在測試時必須考慮輸入條件的各種組合，可使用一種適合于描述對于多種條件的組合，相應產生多個動作的形式來設計測試用例，這就需要利用因果圖。因果圖方法最終生成的就是判定表。它適合于檢查程序輸入條件的各種組合情況。此方法比較復雜,有興趣的可以研究一下.第14頁，共28頁，2022年，5月20日，12點4分，星期四黑盒測試總結一般不會單獨采用一種方法來設計用例,會綜合幾種方法,多方面,多角度的設計用例, 以達到測試的全面性和系統性.第15頁，共28頁，2022年，5月20日，12點4分，星期四白盒測試的測試用例設計 語句覆蓋語句覆蓋就是設計若干個測試

7、用例，運行被測程序，使得每一可執行語句至少執行一次。 判定覆蓋判定覆蓋就是設計若干個測試用例，運行被測程序，使得程序中每個判斷的取真分支和取假分支至少經歷一次 條件覆蓋條件覆蓋就是設計若干個測試用例，運行被測程序，使得程序中每個判斷的每個條件的可能取值至少執行一次 路徑覆蓋路徑測試就是設計足夠的測試用例，覆蓋程序中所有可能的路徑第16頁，共28頁，2022年，5月20日，12點4分，星期四測試的階段V模型介紹第17頁，共28頁，2022年，5月20日，12點4分，星期四華為的測試流程第18頁，共28頁，2022年，5月20日，12點4分，星期四測試部的前期工作需求階段:測試部會在開發人員寫需求

8、分析的時候就派人跟蹤此項目,在這個階段完成系統測試用例的設計,通過此工作來驗證需求的可測試性和合理性.概要設計階段:此階段測試部會完成集成測試用例的設計和用例的寫作第19頁，共28頁，2022年，5月20日，12點4分，星期四系統測試介紹測試策略定義測試那些用例.定義重點測試的模塊.定義預測試通過的條件.測試風險,以及規避措施等.測試計劃定義測試時間測試人員,測試環境,測試儀表,測試版本等測試報告對整個系統做出一個評價.分模塊進行評價.給出下一輪測試的測試建議和測試重點.第20頁，共28頁，2022年，5月20日，12點4分，星期四值得借鑒的地方(1)測試用例庫測試簡單,方便,提高測試效率.方

9、便制定測試策略.完成測試經驗的積累和共享.自動測試能夠完成大部分機械性的操作, 節省人力,提高開發效率.測試人員可以設計出更加優秀的測試用例.第21頁，共28頁，2022年，5月20日，12點4分，星期四值得借鑒的地方(2)測試策略和計劃在測試之前根據實際情況,制定測試內容,測試計劃,對測試有著很強的指導意義.為以后測試的改進做好準備.帶分析的測試報告第22頁，共28頁，2022年，5月20日，12點4分，星期四值得借鑒的地方(3)測試方法:為了保證測試的質量和投入,測試部一般會對版本進行預測試,預測試通過之后會按測試計劃來進行測試,如果預測試不通過會打回到開發,此種情況會影響開發團隊的考核.

10、一旦通過預測試,則需要完成整個測試計劃,這樣可以減少測試版本,縮短開發周期.系統測試過程一般測試三輪,第一輪為全局測試, 第二輪為重點模塊測試, 第三輪為回歸測試, 主要針對第二輪的問題單進行測試和開局的模擬驗證,如果不能達到發布條件則需要進行下一輪測試.第23頁，共28頁，2022年，5月20日，12點4分，星期四系統測試的依據任何事情都要有個評判的依據,對于目前我們的手機項目來說,測試的依據就是開發人員提供的“規格書”,凡是和規格書不一致的地方都可以認為是問題. 當然也不排除規格書有誤的地方,這些也需要提出來要求開發人員改正,以保證資料的正確性和權威性.第24頁，共28頁，2022年，5月20日，12點4分，星期四對測試人員的要求需要了解代碼.需要經常和開發人員進行交流, 提升自己對系統的理解能力。能夠大致評估開發人員修改帶來的影響.能夠清晰的描述問題,并進行初步定位,給出參考意見.多從用戶的實際使用角度來設計用例.能夠考慮各種異常情況.第25頁，共28頁，2022年，5月20日，12點4分，星期四軟件部對測試部的一些建議問題單描述不清楚，不規范，不容易看懂.重