軟件測試知識帖(41-60)
第41帖【2004－6－27】：測試自動化的限制
測試自動化可以帶來非常明顯的收益，但也有其限制，主要有：
1.不能取代手工測試
2.手工測試比自動測試發現的缺陷更多
3.對測試質量的依賴性極大
4.測試自動化不能提高有效性
5.測試自動化可能會制約軟件開發。由於自動測試比手動測試更脆弱，所以維護會受到限制，從而制約軟件的開發。
6.工具本身並無想像力
另外，人工測試比測試工具更優越的另一個方面是可以處理意外事件。雖然工具也能處理部分異常事件，但是對真正的突發事件和不能由軟件解決的問題就無能爲力。
第42帖【2004－6－28】：什麼是應首先被自動化的測試？
軟件測試的自動化過程是一個漸進的過程，並不需要一開始就對所有的測試進行自動化，這通常也是不現實的。如何選擇首先被自動化的測試成了最先遇到的問題。
有些測試，完全沒有必要進行自動化，因爲自動化它們所需的時間比手工運行它們全部的次數所需的時間總和還長。例如，手工運行一個測試要10分鐘，而且一般每個月運行1次，那麼一年需要120分鐘。但如果自動化這測試需要10小時，那麼這個測試需要連續不斷運行5年才能收回成本。
有些測試，雖然執行的時間不長，但過程繁瑣，需要執行的動作非常多。比如，一個運行10分鐘的測試，可能需要擊鍵150次，打開4～5個窗口，切換操作。如果將其自動化，可以提高可靠性，也是值得的。
對軟件進行的功能性測試，是測試軟件系統在做什麼。這些測試可以明確的知道應該在什麼情況下輸入什麼，會有什麼樣的輸出。這樣的測試是非常容易被自動化的，也能從自動化中獲得較大的收益。
對軟件進行的性能測試，包括在不同的系統負載下進行的測試。這些測試需要採用工具輔助完成，非常適合進行自動化。
如果在測試中，運行10%的測試需要花費90%的時間，那麼將這10%的測試自動化是值得的。
以下列出了選擇首先進行自動化時要考慮的因素：
非常重要的測試
涉及範圍很廣的測試
對主要功能的測試
容易自動化的測試
很快有回報的測試
運行最頻繁的測試
應該注意避免一口氣自動化太多的測試。太多的工作導致參與人員工作積極性下降，可維護性下降，增加工作的風險。尋找可快速制勝的測試，儘快讓大家看到工作成果，有助於獲得更多的工作支持。
第43帖【2004－6－29】：工具的選擇：創建還是購買
在評估了商業市場後，你可能會發現在你的限制之內沒有符合你需求的工具。這時需要考慮是否自行開發自己的工具，還是等待市場上出現滿足要求的新工具。
自行開發新工具有以下特點：
1、它將是最合適你的需求的
2、可以在工具中補償被測軟件缺乏的可測試性
3、工具可以假設很瞭解被測程序，因而減少了實現測試自動化所需的工作
4、在文檔、幫助和培訓方面可以不用提供很好的支持
5、工具可能具有某些典型的問題，如結構、可擴展性等
6、用戶界面不友好
商業工具有以下特點：
1、獲得一個指定功能和性能標準的工具的費用可能比自行開發一個工具的成本要低
2、在文檔、幫助和培訓方面必須提供良好的支持
3、工具通常應該很有吸引力
4、即使使用一個商業工具，可能無法完全避免建立自己的工具
但即使決定自行開發測試工具，也不要試圖生產一個可以廣泛使用的商業工具。
第44帖【2004－6－30】：自動化腳本之線性腳本
線性腳本是錄製手工執行的測試用例得到的腳本。這種腳本包含所有用戶的鍵盤和鼠標輸入。如果僅使用線性腳本技術，每個測試用例可以通過腳本完整地被回放。線性腳本中也可能包括比較，比如檢查某個窗口是否彈出。
手工運行10分鐘的測試用例，可能需要20分鐘到2個小時才能完成測試自動化的工作。因爲錄製的腳本需要維護，尤其是增加部分內容後的維護和測試需要花費很多時間。而且自動化以後的測試執行的時間會大於10分鐘。
線性腳本有以下的優點：
1、不需要深入的工作或計劃
2、可以加快開始自動化
3、對實際執行操作可以審計跟蹤
4、用戶不必是編程人員
5、提供良好的（軟件或工具）的演示
線性腳本適用於以下情況：
1、演示或培訓
2、執行量較少，且環境變化小的測試
3、數據轉換，如將數據從Notes數據庫中轉換到EXCEL表格中
線性腳本有以下缺點：
1、過程繁瑣
2、一切依賴於每次捕獲的內容
3、測試輸入和比較是“捆綁”在腳本中的
4、無共享或重用腳本
5、線性腳本容易受軟件變化的影響
6、線性腳本修改代價大，維護成本高
7、非常容易受意外事件的影響，引起整個測試失敗
第45帖【2004－7－1】：自動化腳本之結構化腳本
結構化腳本類似於結構化程序設計，含有控制腳本執行的指令。這些指令或爲控制結構，或爲調用結構。控制結構中包括“順序”、“循環”和“分支”，和結構化程序設計中的概念相同。調用結構是在一個腳本中調用另外腳本，當子腳本執行完成後再繼續運行父腳本。
結構化腳本的優點是健壯性好。也可以通過循環和調用減少工作量。
結構化腳本的缺點是腳本更復雜，而且測試數據仍然“捆綁”在腳本中。
結構化腳本側重於描述腳本中控制流程的結構化特性。
第46帖【2004－7－3】：自動化腳本之共享腳本
共享腳本是指腳本可以被多個測試用例使用，一個腳本可以被另外一個腳本調用。這樣可以節省生成腳本的時間；當重複任務發生變化時，只需修改一個腳本。
建立共享腳本的時間可能更長，因爲需要建立更多的腳本，且每個腳本需要進行適當的修改，達到腳本共享的目的。
共享腳本可以是在不同主機、不同系統之間共享腳本，也可以是在同一主機、同一系統之間共享腳本。
共享腳本的優點有：
1、以較少的開銷實現類似的測試
2、維護開銷低於線性腳本
3、刪除明顯的重複
4、可以在腳本中增加更智能的功能
共享腳本的缺點有：
1、需要跟蹤更多的腳本，給配置管理帶來一定的困難
2、對於每個測試，仍然需要特定的測試腳本，因此維護費用比較高
3、共享腳本通常是針對被測軟件的某部分，存在部分腳本不能直接運行
要獲得高質量的共享腳本，需要接受一定的訓練。在開始編寫腳本時，多花些時間進行設計是值得的。通過共享腳本技術，還可以建立腳本庫，達到最大程度的共享。由於共享腳本需要被多次使用，所以與腳本相配套的文檔更應該引起注意。
共享腳本側重描述腳本中共享的特性。
第47帖【2004－7－4】：自動化腳本之數據驅動腳本
數據驅動腳本技術將測試輸入存儲在獨立的數據文件中，而不是綁定在腳本中。執行時是從數據文件而不是從腳本中讀入數據。這種方法最大的好處是可以用同一個腳本允許不同的測試。對數據進行修改，也不必修改執行的腳本。
使用數據驅動腳本，可以以較小的開銷實現較多的測試用例，這可以通過爲一個測試腳本指定不同的測試數據文件達到。將數據文件單獨列出，選擇合適的數據格式和形式，可將用戶的注意力集中到數據的維護和測試上。達到簡化數據，減少出錯的概率的目的。
數據驅動腳本的優點有：
1、可以快速增加類似的測試
2、測試者增加新測試不必掌握工具腳本語言的技術
3、對第二個及以後類似的測試無額外的維護開銷
數據驅動腳本的缺點有：
1、初始建立的開銷較大
2、需要專業（編程）支持
3、必須易於管理
第48帖【2004－7－5】：自動化腳本之關鍵字驅動腳本
關鍵字驅動實際上是比較複雜的數據驅動技術的邏輯擴展。將數據文件變成測試用例的描述，用一系列關鍵字指定要執行的任務。在關鍵字驅動技術中，假設測試者具有某些被測系統的知識，所以不必告訴測試者如何進行詳細的動作，只是說明測試用例做什麼，而不是如何做。這樣在腳本中使用的是說明性方法和描述性方法。描述性方法將被測軟件的知識建立在測試自動化環境中，這種知識包含在支持腳本中。
例如，爲完成在網頁瀏覽時輸入網址，一般的腳本需要說明在某某窗口的某某控件中輸入什麼字符；而在關鍵字驅動腳本中，可以直接是在地址欄中輸入網址什麼什麼；甚至更簡單，僅說明輸入網址什麼什麼。
關鍵字驅動腳本的數量不隨測試用例的數量變化，而僅隨軟件規模而增加。這種腳本還可以實現跨平臺的用例共享，只需要更改支持腳本即可。
第49帖【2004－7－6】：腳本預處理
預處理是一種或多種預編譯功能，包括美化器、靜態分析和一般替換。腳本的預處理是指腳本在被工具執行前必須進行編譯。預處理功能通常需要工具支持，在腳本執行前自動處理。
美化器是一種對腳本格式進行檢查的工具，必要時將腳本轉換成符合編程規範的要求。可以讓腳本編寫者更專注於技術性的工作。
靜態分析對腳本或表格執行更重要的檢查功能，檢查腳本中出現的和可能出現的缺陷。測試工具通常可以發現一些如拼寫錯誤或不完整指令等腳本缺陷，這些功能非常有效。靜態分析可以檢查所有的缺陷和不當之處。類似於程序設計中的PC-Lint和LogiScope的功能。
一般替換也就是宏替換。可以讓腳本更明確，易於維護。使用替換時應注意不要執行不必要的替換。在進行調試時，應該注意缺陷可能是存在被替換的部分中，而不是原來的腳本中。
第50帖【2004－7－7】：自動比較技術
測試驗證是檢驗軟件是否產生了正確輸出的過程，是通過在測試的實際輸出與預期輸出（例如，當軟件正確執行時的輸出）之間完成一次或多次比較來實現的。進行測試自動化工作時，自動比較就成爲一個必須的環節。有計劃的進行比較會比隨意的比較有更高的效率和發現問題的能力。
自動比較的內容可以是多方面的，包括基於磁盤輸出的比較，如對數據文件的比較；基於界面輸出的比較，如對顯示位圖的比較；基於多媒體輸出的比較，如對聲音的比較；還包括其它輸出的內容的比較。
比較器可以檢測兩組數據是否相同，功能較齊全的比較器還可以標識有差異的內容。但比較器並不能告訴用戶測試是否通過或失敗，需要用戶自行判斷。
比較可以是簡單的比較，僅匹配實際輸出與預期輸出是否完全相同，這是自動化比較的基礎。智能比較是允許用已知的差異來比較實際輸出和預期輸出。比如，要求比較包含日期信息的輸出報表的內容。如果使用簡單比較，顯然是不行的，因爲每次生成報表的日期信息肯定是不同的。這時就需要智能比較，忽略日期的差別，比較其它內容，甚至還可以忽略日期的具體內容，比較日期的格式，要求日期按特定格式輸出。智能比較需要使用到較爲複雜的比較手段，包括正則表達式的搜索技術、屏蔽的搜索技術等。
第51帖【2004－7－8】：測試的敏感性和健壯性
敏感的測試是指測試過程能發現微小的，甚至是不起眼的錯誤。敏感的測試能發現較多的問題，但任何一點微不足道的改動都將導致測試用例及執行過程的更改。健壯的測試是指測試過程能夠容忍較多的差別，不會影響測試用例的失敗。在自動化測試時，健壯的測試可以較容易通過執行，也就減少了意外情況對測試過程的影響，但會導致發現問題的能力下降，甚至放過應該發現的問題。
應當在測試的敏感性和測試的健壯性之間進行權衡。對大量的自動測試用例而言，過多的敏感性比缺少敏感性更會反面影響失敗分析工作。如果運行一組敏感的測試用例，那麼有可能其中多數的測試用例由於相同的原因而失敗。在這種情況下，每個失敗的測試用例都指示相同的錯誤，但測試人員只是希望獲得不同的錯誤及錯誤的差異，並不需要重複相同的錯誤報告。
敏感性和健壯性的測試應當是：
1、無論軟件何時發生了變化，主要在高層次，即在作爲明智的檢驗運行測試事例的地方，使用敏感比較
2、考慮多組測試用例，其中的一兩組使用敏感比較，而其他組使用健壯比較
3、好的測試自動化策略應該是規劃敏感測試和健壯測試的混合體
第52帖【2004－7－9】：TMM2級目標
TMM Level 2 - 階段定義級目標：
1、區分調試和測試的的各自目標
爲了區分調試和測試，需要成立爲測試和調試負責的組織，該組織需要建立測試目標和策略，另外該組織還要建立調試目標和策略，這些目標和策略要文字化並確保知會到所有的項目經理和開發人員。
2、引進測試計劃過程
完成這個目標，要建立組織範圍內的測試計劃組織、建立測試計劃策略及計劃模板、建立把用戶需求引入測試計劃的正規途徑、測試目標作爲測試計劃基線、對項目管理者進行測試計劃培訓、對軟件工程師進行測試設計和用例設計培訓、計劃工具必須被評估、推薦和申購，使用要得到管理層的支持。
3、基本的測試技術和方法被制度化
必須明確制定何時、如何應用那些測試技術。爲此要成立組織範圍內的測試技術研究組，進行學習、評估、推薦基本的測試技術、方法和相應的工具支持，管理者要在政策上保證推薦的技術和方法在組織範圍內堅持使用。
第53帖【2004－7－11】：TMM3級目標
TMM Level 3 -集成級目標：
1、建立軟件測試的專門組織
建立組織範圍內的測試組織，取得高層支持，並且有資金保證；組織範圍內明確定義了測試部門的角色和職責，將受過良好培訓和激勵的員工分配到測試部，測試部員工協助SQA工作，以提高測試效率和軟件質量；測試部門能與用戶建立溝通渠道，把用戶需求引入測試過程。
2、建立技術培訓流程
管理層必須建立組織範圍內的測試培訓體制，提供支持和資金，必須建立培訓的目標和計劃，建立內部培訓組織，提供必要的工具、設備和資料。
3、測試和軟件週期集成
將測試分成若干階段，以集成到開發過程中；建立並採用 V模型，制定與測試相關的工作標準，爲了使集成容易實現，必須建立測試人員和開發人員的工作機制。
4、監督和控制軟件測試過程
建立相應機構和策略以監控測試過程，建立測試相關活動的度量機制，爲測試計劃執行過程中的突發事件制定應急措施。
第54帖【2004－7－11】：TMM4級目標
TMMLevel 4 -管理和度量級目標
1、建立組織範圍內的評審流程
評審能儘早、有效地識別、分類和消除缺陷，高層管理者必須制定評審的政策，支持評審過程，並把評審集成在組織文化中；測試組和SQA必須制定整個生命週期內的評審目標，計劃和過程，並文檔化，必須指定要評審的項目；參加評審者要接受培訓，包括評審的政策，實踐和程序。
2、建立測試度量流程
建立組織範圍內的測試度量政策和目標，必須建立面向數據收集、分析和應用的測試度量計劃，根據度量分析結果，制定並記錄相應的行動計劃以改進測試過程。
3、進行軟件質量評估
管理者、測試和SQA組織必須定義與軟件質量相關的質量政策，質量目標和質量屬性（例如可以參照ISO9126制訂質量度量模型）；測試過程必須是結構化的，可度量和可評估的，以保證軟件質量目標的可達性。
第55帖【2004－7－12】：TMM5級目標
TMM Level 5 - 優化級目標
1、進行過程的數據進行缺陷預防
對組織內的所有項目採用缺陷預防策略，在管理者的支持下建立缺陷預防的團隊；軟件生命週期每個階段發現的缺陷必須標識和記錄；建立分析的機制，保證能弄清楚導致缺陷的根本原因；建立行動計劃，採取措施，避免管理人員、開發人員和測試人員工作中重現已發現的缺陷。
2、質量控制，測試過程優化
軟件測試和SQA組必須建立軟件產品的目標，如產品單元缺陷率(product unit defectiveness)，自信級別(confidence levels)和可信性 (trustworthiness )，測試經理必須把這些質量目標分解到測試計劃中，必須對測試組進行統計方法培訓。
收集用戶的輸入操作，建立使用模型。
3、測試過程優化
建立測試過程改進組織，監控測試過程，尋找優化點，持續對測試相關的、需要採用的工具和技術進行評估，測試過程效率要持續進行評估，停止測試的決策必須參考質量目標，並以可度量和優化的方式來制定。
第56帖【2004－7－13】：正規檢視需要哪些階段？
檢視過程包括七個階段：
1、計劃
用於確定工作產品是否滿足正規檢視的進入標準，計劃檢視，召集成立檢視小組並分配相應任務、安排正規檢視會議，準備和發放正規檢視的資料。確定是否有必要舉行產品介紹會議。
2、介紹會議
這是可選擇階段。本階段向正規檢視小組介紹產品的背景信息。如果每個檢視小組的成員對被檢視的對象很熟悉，可不用召開產品介紹會議。
3、會議準備
這是關鍵階段。本階段檢視小組的成員單獨準備檢視會議，檢查和發現檢視對象中的錯誤。錯誤將在正規檢視會議期間進行討論。在檢視會議前以問題登記表形式提交給組織者。
4、檢視會議
正規檢視的小組一起審查產品。
(這裏說到正規檢視有七個階段，在網上查了一下，沒找到答案，有知道朋友的可以提醒一下，我把這裏補全。)
第57帖【2004－7－14】：正規檢視介紹會議
正規檢視介紹會議：
介紹會議階段是評審流程可選擇的階段。如果檢視小組成員不熟悉檢視對象以及相關的背景，那麼這個會議就應當安排舉行。在介紹會議上，作者介紹產品的理論基礎，產品同被開發的系統其餘部分的關係，產品的功能和產品的主要應用，以及在產品開發過程中採用的開發方式。所有的檢視者必須參加介紹會議。
召開介紹會議的主要原因如下：
1、正規檢視小組不熟悉檢視對象
2、檢視對象是新開發的或者是首次進行正規檢視
3、正規檢視工作在檢視對象的項目中被首次採用
第58帖【2004－7－15】：軟件配置管理介紹
1、軟件配置管理概念：
軟件配置管理是通過在軟件生命週期的不同時間點上對軟件配置進行標識並對這些標識的軟件配置項的更改進行系統控制，從而達到保證軟件產品的完整性和可溯性的過程。
配置：軟件系統的功能屬性。
配置項：軟件系統的邏輯組成，即與某功能屬性相對應的文檔或代碼等。
2、軟件配置管理的四個基本過程：
配置標識： 標識組成軟件產品的各組成部分並定義其屬性，制定基線計劃。
配置控制： 控制對配置項的修改。
配置狀態發佈： 向受影響的組織和個人報告變更申請的處理過程，通過的變更及他們的實現情況等。
配置評審： 確認受控軟件配置項滿足需求並就緒。
3、配置庫：對各基線內容的存儲和管理的數據庫
開發庫：程序員工作空間，始於某一基線，爲某一目的開發服務，開發完成後，經過評審迴歸到基線庫。
基線庫：包括通過評審的各類基線，各類變更申請的記錄和統計數據。
產品庫：是某一基線的靜態拷貝，基線庫進入發佈階段形成產品庫。
4、檢視對象中應用了最新的技術
第59帖【2004－7－16】：利用PC－LINT進行代碼排錯
PC-LINT是GIMPEL SOFTWARE公司的產品，是一種軟件質量保證工具，用於程序排錯，可對windows、unix平臺下的C、C++代碼進行最仔細的語法檢查，可檢查一些在普通編譯器不易發現的句法、一般邏輯錯誤等，是程序員不可多得的排錯工具。
如果給 PC-LINT工具下一個形象點的定義，那就是：一種更加嚴格的編譯器。它不僅可以象普通編譯器那樣檢查出一般的語法錯誤，還可以檢查出那些雖然完全合乎語法要求，但很可能是潛在的、不易發現的錯誤。
許多國外的大型專業軟件公司，如微軟公司，都把它作爲程序檢查工具，在程序合入正試版本或交付測試之前一定要保證通過了LINT檢查，他們要求軟件工程師在使用LINT時要打開所有的編譯開關，如果一定要關閉某些開關，那麼要給出關閉這些開關的正當理由。
在開發、測試過程中，除了正規檢視、代碼走讀、代碼審查等活動可以有效的幫助獲得正確的代碼，運用PC-LINT、LOGISCOPE等工具也是很好的排錯手段，尤其是PC-LINT，以其方便、準確、嚴格的特點在排除程序一般性錯誤方面有着明顯的優勢，其付出的工作量比正規檢視、代碼走讀的要少很多。
可想而知，如果從編碼後第一次編譯程序時就使用LINT來檢查程序，並且保證消除所有的LINT告警，程序質量的提高是不言而喻的。
第60帖【2004－7－17】：LOGISCOPE介紹
LOGISCOPE是爲軟件的全面質量控制而開發的強大工具，可以用在編程、測試和維護階段。LOGISCOPE五個模塊的功能：
(1) 閱讀器(Viewer)：以文件調用圖(各部件文件之間的關係)及組件調用圖(函數和程序間的調用關係)的形式進行可視化應用軟件設計。可以在各種各樣的抽象級別上分析應用程序，在不同級別上的引導有助於整個應用程序的理解。
(2) 效果檢查器(ImpactChecker)：允許用戶檢查使用的資源(文件、函數、用戶定義類型、全局變量、結構成員常量)。它有助於我們理解函數間的信息流(參數傳遞)，以及數據和其它應用程序資源間的關係。
(3)規則檢查器(RuleChecker)：所有關心無質量風險地開發軟件的公司(比如航天公司)定義了編程規則和質量目標。這樣做的好處是公司編程行爲的一致性、確保易於維護、提高可靠性、易於移植到其它機器上，等等。我們可以用規則檢查器(RuleChecker)確立編程標準，保證質量控制。
(4) 測試檢查器(TestChecker)：實時度量測試覆蓋率、顯示未覆蓋路徑原始數據、生成測試報告、幫助管理測試實例。測試檢查器(TestChecker)和動態分析器 (Dynamic Analyzer)通過閱讀器產生用於應用程序分析的數據。
(5) 代碼檢查器(CodeChecker)：驗證應用程序與質量模型的一致性。代碼檢查器和靜態分析器(Static Analyzer)通過閱讀器(Viewer)產生用於應用程序分析的數據。代碼檢查器(CodeChecker)可以使我們儘早發現和修改質量缺陷。這對質量控制尤爲重要。