《軟體測試的藝術》學習記錄

2021-10-17 04:59:09 字數 1770 閱讀 4440

軟體測試的藝術:(測試是發現錯誤而執行程式的過程)

一.端正自己的態度:測試是為了發現錯誤而執行程式。而不是證明軟體不純在錯誤

黑盒測試:(資料驅動測試或輸入/輸出驅動測試)(不太可能實現,1.經濟學2.邏輯上)

窮舉輸入測試:將可能的輸入條件當測試用。

白盒測試:(邏輯驅動測試)(不太可能實現1.邏輯路徑太多2.不經濟)

窮舉路徑測試:測試執行程式的所有控制流路徑。

測試原則:

1.測試用例中乙個必需部分是對預期輸出或結果進行定

2程式設計師應當避免測試自已編寫的程式,編寫軟體的組織不應當測試自己編"的軟體

3.應當徹底檢查每個測試的執行結果

4.測試用例對程式在上述輸入資料下正確結果的精確描述。

5. 測試用例不僅應當根據有效和預期的輸入情況,而且也應當根據無效和未預料到的輸入情況。

6. 避免測試用例用後即棄。

7. 計畫測試工作時不應默許假定不會發現錯誤

人工測試:(可以精確對錯誤的定位)

**檢查和走查主要的人工測試方法。(小組頭腦風暴—目標:找出錯誤)

常用錯誤列表:

1. 資料引用錯誤:

a.引用變數未賦值或者未初始化。

b.陣列的引用是否下標的值都在規定的界限內。

c.陣列的引用是否每乙個下標都是整數值。

d.對於通過指標或引用變數的引用,當前引用是否分配記憶體。(防止虛呼叫)

2.資料宣告錯誤:

a.是否所有的變數都進行了明確的宣告。(不宣告可能會照成麻煩)

b.若沒有宣告,預設的屬性是否真確。

c.變數在宣告語句被初始化,初始化是否真確。

d.每個變數是否都被賦予了正確的長度和資料型別。

e.變數的初始化是否與其儲存空間的型別一致?

f.是否純在相似的名稱的變數,這種情況不一定是錯誤的,但應被視為警告,應為名稱在程式中可能發生混淆。

3.運算錯誤:

a.是否存在不一致的資料型別的變數間的運算。

b.是否有混合模式的運算?(浮點變數與乙個整型變數做加法運算—要謹慎使用)

c.是否有相同資料型別,不同字長變數間的運算?

d.賦值語句的目標變數的資料型別是否下雨右邊表示式的資料型別或結果?

e.在表示式的運算中是否存在表示式向上或向下溢位的情況。(結果有效,但中間結果對於程式語言的資料型別可能過大或者過小)

f.除法運算中的除數是否可能為0?

g.在特定場合,變數的賦值是否超出了有意義的範圍。probability(概率賦值)賦值 始終為正且不大於1.0。

h.賦值和操作符的運算的優先順序是否真確?

i.整數的運算是否有不當的情況。(整形除法 考慮奇數偶數)

4.比較錯誤:

a.是否有不同資料型別的變數之間的比較運算,列如,將字串與位址,日期或數字比較。

b.是否有混合模式的比較運算,或不同長度的變數間的比較運算?如果有,應確保程式能理解轉換規則。

c.比較運算子是否真確? 至多,至少,大於,不小於,小於和等於的區別。

d.布林表示式所敘述的類容是否都正確。 與,或,非表示式的用法。

布林運算子是否是布林型別的?比較運算子和布林運算子是否混淆。

比如:2

除錯的藝術學習筆記 命令記錄

1 單步除錯 n next s step 跟n的區別,s進入到函式內 2 恢復操作 c continue 直到遇到下個斷點 3 臨時斷點 tbreak 有效期,第一次遇到 4 檢查變數 p printf 5 監視點 watch 當監視點的值發生變化時停止 6 檢視棧 bt backtrace 顯示整...

程式設計藝術學習筆記(1)

序言習題 1 通過一系列的替代,將四個變數的值 a,b,c,d 變為 b,c,d,a 用最少的步驟 開門菜,然而還是有很多值得思考的地方。能幫助人理解計算機對於賦值的操作。通過觀察,可以認為這是乙個a i 賦值給a i 1 的操作。最少的步驟,只需要五步即可。需要乙個t來作輔助,t a,a b,b ...

4 3 軟體是多層的 UNIX程式設計藝術學習筆記

自頂向下的設計者可能會首先考慮主事件迴圈,然後在考慮插入具體的事件 自底向上設計者通常會考慮封裝具體的事務,以後再按照某種相關次序把這些東西粘合在一起。單純的使用自底向上和自頂向下都無法達到好的效果。一方面設計程式邏輯 自頂向下 一方面整理底層的域原語 專業術語 然後在中間結合。這樣就導致了膠合層的...