Testing,debug and turning

測試的種類

1. 白箱測試或單元測試：

將一個軟体系統分成不同的單元(或模組)逐一測試，有時需要利用debug工具一步步的運行來進行調試，需要了解每一個模組的內部程式碼的構造、演算法資訊。這是從程式設計者的角度對程式進行測試。

在嵌入式系統中，要透過ICE或其它裝置來trace機器上的程式總是比較不方便，可以的話，除了驅動程式或少數系統模組外，其它模組的單元測試能夠在模擬器上進行。因在模擬器上總比實体上快，故在模擬器上完成測試後，還要在實体機器上做一次"確認測試)，驗証所有在模擬器上所做過測試在模擬器及機器上OK。(在實体機器上進行確認測試，可以找出一些實体機器和模擬器上所未預料的不同點)

2.黑箱測試：

指測試者不需要了解程式的內部情況，比較系統的預期輸出及實際輸出，來測試系統功能是否正常。這種測試不需了解內部構造，是從使用者角度來對程式測試。只需程式的輸入、輸出及系統功能即可。

3.基本功能測試：

按照測試軟体的各個功能劃分，進行有條理、有範圍的測試，必須保証測試範圍能覆蓋所有功能和各種功能條件的組合。

4.整合測試：

相對基本功能測試而言，主要確認在多個基本功能整合在一起後並交互操作後有沒有問題；此外整合測試也必須檢查出一些環境上旳問題(記憶体配置錯誤)。"小範圍的測試可以在模擬器環境上完成，來加速測試。最後還是在實体機器上測試"

5.系統測試及確認測試：

必須在實体機上測試，測試所有預期功能是否可正確工作。旨在檢查整個系統的功能是否完全符合產品規格的需求。

在發行重要版本之前，都必須在機器上作"確認測試"，檢查這個版本各部的功能是否都能依照規格正確運行；規格除了功能的正確性外，系統效能也是檢查的項目。

 

6.壓力測試或極限值測試：

使用者/系統。對鍵盤頻繁且無規格的操作，同時執行多個應用程式，或儀器設備造出無用的封包。

而系統架構，則是由工程師寫程式來測試系統模組，例如不斷記寫記憶体來測試穩定度、模擬驅動程式持續不斷的送出中斷，以測試上層模組可應附此種狀況、反覆的rellocate/mallocate/free。

 

7.極限測試：

和壓力測試差不多，基本上是：系統設計上會明定許多限制，如電梯的最大載重、LCD的解析度、電池的低電壓等級。

"以通過極限值測試可以證明就算遇到了超過極限值旳將況，系統會略過或發出警訊，至少不會執行錯誤操作"

8.自動測試：

主要是針對基本功能，開發一個自動測試的程式，可在人工不介入下，測試所有的基本功能並產生報表。

 

9.硬体測試：

ESD防護：靜電防護。因靜電可能由任何路徑打入機器，只多做一些判斷，"盡量"誀免誤動作。

EMC(electro magnetic compatibility)，電磁相容性。電磁干援，指除了所需信號外而出現在電路內的任何電氣訊號。基本所有電子都有送出EMI,也都受到EMI干擾。因此電子裝置的設計，應不受外在EMI干擾外、也不應成為EMI。grounding、shielding and filtering。

極端環境測試：了解市場為何?

強度測試：

  和機構設計有關，例如從一公尺摔下。

在測試出bug後的處理原則：

• 每一個bug都應有屬於某一個分類,而每一個分類的bug有預設的處厓者，為了避免bug送錯人而延遲處理時間，測試人員如果無法區分bug的類別，在issuse這個bug前，最好找主管或相關工程師討論。
• 盡量找出最簡單就可以把bug重現的步驟。
• 辨別那些現象是屬於同一個bug；類似的bug寫同一張即可。
• 當發現bug時，測試工程師有義務依規格，去check其它可能同樣問題的地方，提醒工程師一次處理所有類似的問題。
• 測試人員不應憑個人來判斷某個現象是否合理，一切均依規格書。
• 某功能不待合產品規格當然是bug,但測試人員最好能寫好參考規則書的章節。
• 效能不佳也可列為bug，但有時效能好不好是主觀的，最好找客戶,訂定規格人員討論。
• 並不是所有bug處理者,都是工程師；例如工程師依規格中的定義實現了某個功能，但測試人員或end user以使用者角度覺得不易使用；此時測試人員可將這個問題加入bug list，並指定給客戶或訂規格的人。

bug的生命週期

http://upload.wikimedia.org/wikipedia/commons/thumb/3/31/Bugzilla_Lifecycle_color-aqua.svg/542px-Bugzilla_Lifecycle_color-aqua.svg.png

• new:bug創建後的初始狀態，尚未確認是否為"合法"的bug。已寄發給該類別的bug預設處理者及相關人員，但還沒正式指定處理者。
• assigned：，accepted，表示bug已確認是合法bug，已分配給適當的開發人員處理。
• 已修正，待驗證(resolved)：開發部門對bug進行處理或修改後的狀態
  • fixed:已找出問題，並已修改
  • invalid:開發人員認為不應該是bug
  • wonfix:這個不用修改
  • later:開發人員認為bug在當前版本可以暫時不修改，考慮在後續版本中做修改
  • remind:基本上開發人員不會去修改這個bug，只有當有空時也會去修改
  • duplicate：表示這個問題和其它已被找到的bug是同一個
  • worksforme: work for me，在我的機器上OK?表示開發人員無法重複這個bug,故無法修改
• reopened: 當assigner稱某個bug已解，若經由測試人員驗證卻仍然存在，則將其狀態改為reopened。
• verified：測試人員經驗證，若確認結果OK則將其設為verified。
• unconfirmed:由開發人員自己提交bug，是一種初始狀態，待測試人員確定後變為new
• closed:bug的結束。對verified的bug.

Tuning:

效能。

case by case。

• 在進行最佳化前，先要有一個穩定、可靠的版本，而且在確定最佳化未完成前，不要將程式匯入正式版本之內。
• 調整編譯器的最佳化等級；但務必記得其compiler無法幫程式師完成所有最佳化的任務，尤其是程式風格不好。
• 優先使用改良演算法來做調整。
• 以空間換取時闁。
• 不要把程式最佳化與"用組語改寫"混為一談，首先應找出程式的熱區(hot sport)，也就是效能瓶頸。再來修改。
  • 乘/除及餘數，用左/右移及其它操作代替。
  • 最大限度地滅少分支(if..else if..else 或switch)的數量及複雜度。
  • 以循序處理資料。
    • for(i=0;i<100;i++)
      • for(j=0;j<100;j++)
        • a[i][j]=xx;
        • //a[j][i]=xx;
  • 檢查並少用for 及while內的迭代次數。
  • 在迭代次數的for迴圈或while中，精簡迴圈內的程式。
    • for(i=0;i<9999;i++)
      • //計算字串長度
      • length=strlen(string);
      • do_something(length);
    • 不同記憶体有不同的存取速度.盡量把熱區放在RAM上
  • 以一次處理偶數或四個倍數bytes資料,會比較好效能
    • for(i=0;i<1000;i++)
      • buffer[i]=0xA
    • for(i=0;i<1000/4;i++)
      • pointer[i]=0x0A0A0A0A;
  • 不要認圖從頭改寫成組語，而是先檢查其組言是否有效能問題，再依這個組語下去改寫。
  • 去除不必要的程式碼。