軟件測試知識帖(81-100

軟件測試知識帖(81-100)

第81帖【2004-8-12】:新的可測試性設計思想

隨着科技與經濟的發展,爲提高產品的質量和競爭力,傳統的縱向設計流程必然讓位於“並行工程”設計。在並行工程設計環境下,可測試性技術的內涵與設計策略得到了拓展與豐富。在並行工程設計環境下,測試不僅包括了傳統意義上的製造階段以質量保證爲目的的測試和使用階段以診斷維修爲目的的測試,而且還包含了產品設計實現階段以設計驗證爲目的的測試,以及產品的概念設計和體系結構設計中的可測試性設計過程。並行工程設計環境下可測試性設計策略主要包括:系統可測試性的分級建模與描述策略、可測試性的遞階設計策略以及基於虛擬測試技術的可測試性設計驗證策略。

第82帖【2004-8-13】:新的可測試性機制體系結構

90年代中期推出的遞階集成BIT(HIBIT:hierarchical and integrated BIT)是一種新型的系統級可測試性設計策略,它又被稱爲第四代的測試性設計技術。所謂HIBIT設計是指所設計的可測試性機制具備同系統一樣的遞階層次結構,即具備包括系統級、子系統級(LRU)、電路板級、多芯片模塊級(MCM)和芯片級的層次結構,不同層次的可測試性機制之間通過測試總線相連,實質上,HIBIT技術是邊界掃描技術的一種延伸,在HIBIT中,板級測試利用IEEE 1149.1邊界掃描標準進行,而設備級、系統級的測試則通過IEEE 1149.5 MTM總線進行。

採用分級遞階與集成可測試性機制便於進行“並行工程”的設計與開發,其主要優點是:便於測試性需求指標的分級分配;便於實現測試複用;便於實現並行分佈式的測試進程,提高測試速度。實際上,HIBIT的最大特點就是引入了“並行過程”的設計思想,在HIBIT中採用了並行設計、可複用設計以及虛擬原型設計等並行工程設計方法,這是可測試性設計思想的一次飛躍。

第83帖【2004-8-14】:新的測試信息處理技術與故障診斷方法的應用

可測試性應用的關鍵在於對測試信息進行有效處理,而現有的測試信息處理方法存在故障診斷能力差、虛警率高等問題。爲此,有必要將神經網絡、專家系統等智能理論引入可測試性技術中,研究新型的測試信息處理技術與故障診斷方法,這是可測試性技術的未來研究重點之一。智能測試信息處理方法主要體現在三個方面:在測試信息的獲取階段,應用數據層信息融合的方法,對通過不同測試手段獲取的測試信息進行證實與融合,提高測試信息獲取的質量;在信息處理階段,綜合應用數據壓縮方法、基於狀態模型方法、譜分析以及神經網絡方法等,提取準確表徵被測對象故障狀態的特徵信息;在診斷決策階段,應用馬爾可夫模型、神經網絡、專家系統等方法,並綜合被測對象的環境信息及歷史信息進行智能決策,儘可能地消除測試過程中存在的虛警問題,對故障進行精確定位。

第84帖【2004-8-16】:協議測試

協議測試已經成爲計算機網絡和分佈式系統協議工程學中最活躍的領域之一。近年來,協議一致性測試技術得到了很好的發展和完善,與此同時,互操作測試和性能測試逐漸成爲新的研究熱點。

協議測試包括四種測試:

1)一致性測試(Conformance):檢測所實現的系統與協議規範符合程度;

2)性能測試(Performance):檢測協議實體或系統的性能指標(數據傳輸率、聯接時間,執行速度、吞吐量、併發度等);

3)互操作性測試(Interoperability):檢測同一協議不同實現版本之間、或同一類協議(如電子郵件協議X.400和SMTP)不同實現版本之間互通能力和互連操作能力;

4)堅固性測試(Robustness):檢測協議實體或系統在各種惡劣環境下運行的能力(信道被切斷、通信技術掉電、注入干擾報文等)。

第85帖【2004-8-17】:可接受測試

用戶可接受性測試(User Acceptance Testing)有時也叫驗收測試。在通過了內部系統測試及軟件配置審查之後,就可以開始該項測試了。驗收測試是以用戶爲主的測試。軟件開發人員和QA(質量保證)人員也應參加。由用戶參加設計測試用例,使用用戶界面輸入測試數據,並分析測試的輸出結果,一般使用生產中的實際數據進行測試。在測試過程中,除了考慮軟件的功能和性能外,還應對軟件的可移植性、兼容性、可維護性、錯誤的恢復功能等進行確認。驗收測試實際上是對整個測試計劃進行一種“走讀(Walkthrough)”。

用戶可接受測試具有下列特點:

1、必須要有用戶參與,且以用戶爲主;

2、可接受測試在不同的組織之間,隨目標的不同及工作量的不同而不同;

3、在軟件開發過程當中,可接受測試是最容易變化的一個測試;

4、用戶可接受測試只有按照既定的目標進行的時候纔能有真正的效果;

5、很少有組織能夠真正理解如何處理測試中人的方面問題,他們同時還缺乏必要的培訓來進行計劃和執行一個有效的可接受性測試

第86帖【2004-8-19】:標杆測試

系統指標能夠描述該產品的基本特性的性能,該指標也可以稱爲性能指標。系統指標在系統設計初期就會提出來,但是最終產品詳細指標如何必須通過嚴格的測試纔可以得到。要根據系統穩定性測試模型,結合系統運行的實際情況對系統進行指標測試或標杆測試(Benchmark Testing)。

系統標杆測試的基本概念可以分爲兩部分:

Ø 在系統基本配置或最優化配置條件下,通過測試工具等模擬系統環境和提供單一或標準負荷模型,從而得到系統各種表徵特性的指標,進一步可以驗證系統需求和設計規格中的指標是否達到;

Ø 在多任務並接近實際網上運行等複雜條件下,由於受CPU ,內存,存儲器,通道,網絡,系統配置等資源的影響而測試出系統性能在各方面潛在的低效和限制,比如系統瓶頸,系統指標上限。

第87帖【2004-8-21】:在線幫助測試

用戶在使用系統時候,如果出現問題,首先求助的就是在線幫助。一個糟糕的在線幫助會很大的打擊用戶對系統的信心。因此一個好的系統,必須要有完備的幫助體系,包括用戶操作手冊,實時在線幫助等。在線幫助的測試(Online Help Testing)主要用於驗證系統的實時在線幫助的可用性和正確性。

在實際操作過程中,在線幫助測試可以和文檔測試(或資料測試)一起進行。在進行在線幫助測試的時候,測試人員需要關注下面這些問題:

Ø 1、幫助文件的索引是否正確?

Ø 2、幫助文件的內容是否正確?

Ø 3、在系統運行過程中幫助能否被正常的激活?

Ø 4、在系統不同的位置激活的幫助內容與當前操作內容是否相關聯?

Ø 5、幫助是否足夠詳細並能解決需要被解決的問題?

第88帖【2004-8-23】:軟件可靠性

軟件可靠性(Software Reliability)可以定義爲:在規定環境,規定時間內(自然單元或時間單元),一個系統或其功能無故障運行的可能性。

其中:

Ø 規定的環境包括硬件環境和軟件環境。軟件環境包括允許的操作系統、應用程序、編譯系統、數據庫系統等;硬件環境包括CPU、內存、I/O等。

Ø 規定的時間一般分爲執行時間、日曆時間和時鐘時間。其中執行時間(Executing Time)是指執行一個程序所用的實際時間和中央處理器時間,或者是程序處於執行過程中的一段時間;日曆時間(Calendar time)指的是編年時間,包括計算機可能未運行的時間;時鐘時間(Clock time)是指從程序執行開始到程序執行完畢所經歷的鐘表時間。

Ø 自然單元除時間外,跟軟件產品處理數目相關的單元如運行、電話呼叫、API調用等都可以看作是一個自然單元。

第89帖【2004-8-24】:軟件可靠性的層次

從用戶角度來看,軟件可靠性可以分四個層次來看:

第一個層面:軟件不出現故障;

第二個層面:軟件即使出現故障,也僅對性能有部分影響,而設備的功能不受損失;

第三個層面:軟件出現故障並造成部分功能受損失,但是能夠很快恢復業務;

第四個層面:軟件出現較大故障,並造成大部分功能受損、業務中斷或癱瘓,但能夠儘快恢復業務(無論是手工恢復還是自動恢復);

對應於不同的可靠性層次,要求系統有相應的層次設計要求和維護要求,例如:

對於第一個層面:要求系統能夠按照充分的規範來進行設計,加強各種異常處理能力和環境適應能力等;

對於第二個層面:要求系統有較高的容錯能力,使用冗餘技術和備份技術等;

對於第三個層面:要求系統有很好的可測試性,能迅速隔離問題和定位問題等;

對於第四個層面:要求系統有較高的可維護性等

第90帖【2004-8-25】:軟件的失效

失效是指功能部件執行其規定功能的能力喪失。

從失效本身的類型來分,又可以分爲:

Ø 1、獨立失效(Independent Failure):指不是由於另一個產品失效而引起的失效;

Ø 2、從屬失效(Dependent Failure):由於另一產品失效而引起的失效。

Ø 3、系統性失效(Systematic Failure):由某一固有因素引起,以特定形式出現的失效。它只能通過修改設計、製造工藝、操作程序或其它關聯因素來消除。注:無改進措施的修復性維修通常不能消除其失效原因。系統性失效可以通過模擬失效原因來誘發。

Ø 4、偶然失效(Random Failure):產品由於偶然因素引起的失效。只能通過概率或統計方法來預測。

Ø 5、單點失效(Single-point Failure):引起產品失效的,且沒有冗餘或替代的工作程序作爲補救的局部失效。

Ø 6、間歇故障(Intermittent Failure):產品發生故障後,不經修理而在有限時間內自行恢復功能的故障。

Ø 7、漸變失效(Gradual Failure):通過事前的檢測或監測可以預測到的失效,它是由於產品的規定性能隨壽命單位數增加而逐漸變化引起的。對電子產品也稱漂移失效(Drift Failure)。

Ø 8、致命性失效(Critical Failure):使產品不能完成規定任務的或可能導致人或物重大損失的失效或失效組合。

Ø 9、災難性失效(Catastrophic Failure):導致人員傷亡或系統毀壞的失效。

Ø 10、非關聯失效(Non-relevant Failure):已經證實是未按規定的條件使用而引起的失效。或已經證實僅屬某項將不採用的設計所引起的失效。

Ø 11、非責任失效(Non-chargeable Failure):非關聯失效或事先已經規定不屬某組織機構責任範圍內的關聯失效。

第91帖【2004-8-26】:可靠性指標分配

可靠性指標分配是指把系統的可靠性指標分配給系統、子系統、模塊、元器件(或函數)。其主要目的是使各級設計人員明確其可靠性設計要求,並研究實現這些要求的可能性及方法。它也是可靠性試驗和評估的依據。

對於電子設備,可靠性可以從整機一直分配到各個元器件。可靠性分配的目的就是使各級設計人員明確其可靠性設計要求,根據要求估計所需的人力、時間和資源,並研究實現這個要求的可能性及方法。然而對於軟件來說,可靠性分配卻有很大的不同,因爲把可靠性分解到每一行源代碼是沒有意義的。對於一個系統,軟件可靠性可以作爲一個整體來進行考慮,它和硬件可靠性一起組成了整個系統的可靠性。它們直接的關係可以用下面公式表示:

1/MTBF(系) = 1/MTBF(硬) + 1/MTBF(軟)

在硬件方面,可靠性分配的時候需要考慮各器件的組合方式(並聯還是串聯),同時還要考慮各種加權因子(例如重要性因子、複雜因子、環境因子、標準化因子、維修性因子和元器件質量因子)。一般來說,重要的單元應分配較高的可靠性,複雜度高的單元應分配較低的可靠性,處於惡劣環境下的單元應分配較低的可靠性,技術上不成熟的單元應分配較低的可靠性。

總之,對可靠性指標的分配必須做到合理協調、技術上可行、經濟上合算。分配的可靠性指標,必須進行可靠性分析,如果分配給分系統的可靠性指標爲當前技術水平和條件所限,而無法實現者,必須修改方案,重新分配,直到滿足要求爲止。

第92帖【2004-8-27】:FMEA

故障模式影響分析(FMEA)就是在產品設計過程中,通過對產品各組成單元潛在的各種故障模式及其對產品功能的影響進行分析,並把每一個潛在故障模式按它的嚴酷程度予以分類,提出可以採取的預防改進措施,以提高產品可靠性的一種設計分析方法【178】。儘管預計每一個失效模式是不現實的,但是開發組應當儘可能廣泛的制定潛在故障模式列表。

通過FMEA可以達到如下目的:

Ø 能幫助設計者和決策者從各種方案中選擇滿足可靠性要求的最佳方案;

Ø 保證所有元器件的各種故障模式及影響都經過周密考慮;

Ø 能找出對系統故障有重大影響的元器件和故障模式,並分析其影響程度;

Ø 有助於在設計審議中對有關措施(如冗餘措施)、檢測設備等作出客觀的評價;

Ø 能爲進一步定量分析提供基礎;

Ø 能爲進一步更改產品設計提供資料;

Ø 在設計階段評價來自客戶或其他參與者的需求,避免引入潛在的故障;

Ø 在設計階段跟蹤和管理潛在的風險;

Ø 保證任何可能產生的失效不會傷害產品或過程的顧客;

Ø 提高客戶滿意度;

Ø 爲測試和開發提供關注點

第93帖【2004-8-30】:故障樹分析樹

故障樹分析(FTA)在產品設計過程中,通過對可能造成產品故障的各種因素(包括硬件、軟件、環境、人爲因素等)進行分析,畫出邏輯框圖(即故障樹),從而確定產品故障原因的各種可能組合方式的一種可靠性分析技術。是用於分析大型複雜系統可靠性、安全性以及故障診斷的一個有力工具。

該方法存在兩個問題:

Ø 1、不能表示實時問題;

Ø 2、不能表示系統狀態或操作模式;

在使用FTA時,需要注意以下問題:

Ø 1、輸入的可能性很小;

2、被動的組件;

Ø 3、對故障樹進行定量分析(儘管可以對FTA進行量化,但FTA不是一個量化分析方法);

Ø 4、把故障樹代替任何別的分析方法;

Ø 5、小心使用布爾表達式;

Ø 6、獨立的失效模式與非獨立的失效模式對應起來;

Ø 7、確保頂部的事件具有高優先級

第94帖【2004-8-31】:事件分析樹

事件樹分析(ETA)可以在FTA分析之後開始,它通過分析系統中的一個初始事件,然後考慮這個事件所有可能出現的後續事件,尤其是那些可能導致事故的事件。ETA的起始點是那些擾亂正常系統操作的事件,接着它跟蹤事件的傳遞,確定後繼系統組件的失效,計算它們失效的可能性及可能的組合(與/或)。

ETA的缺點是:

Ø1、一個事件的所有可能的後繼考慮起來是有困難的;

Ø2、對於一個複雜的系統,事件樹將變得非常複雜,這是因爲正常和不正常的所有操作都會顯示在事件樹中

第95帖【2004-9-1】:可靠性測試

可靠性測試是從驗證的角度出發,檢驗系統的可靠性是否達到預期的目標,同時給出當前系統可能的可靠性增長情況。可靠性測試需要從用戶角度出發,模擬用戶實際使用系統的情況,設計出系統的可操作視圖,在這個基礎上,根據輸入空間的屬性及依賴關係導出測試用例,然後在仿真的環境或真實的環境下執行測試用例並記錄測試的數據。

對可靠性性測試來說,最關鍵的測試數據包括失效間隔時間,失效修復時間,失效數量,失效級別等。根據獲得的測試數據,應用可靠性模型,可以得到系統的失效率及可靠性增長趨勢。

常用的可靠性模型可以從黑盒(佔主要地位)和白盒兩個角度出發。黑盒方面的可靠性模型包括了Musa基本執行模型,Jelinski-Moranda的分離富化模型,Goel-Okumoto 的NHPP模型,增強的NHPP模型以及Littlewood-Verrall的貝葉斯判定模型。在白盒方面的可靠性模型包括了Krishna-murthy 和 Mathur的基於路徑的模型和 Gokhale et al.的基於狀態的模型。

業界流行的可靠性模型還有很多種,不同的可靠性模型其依賴的假設條件也不同,適用範圍也不同,因此對於一個產品,其所適合使用的可靠性模型需要根據實際出發,儘可能選擇與可靠性模型假設條件相近的模型。

第96帖【2004-9-2】:需求測試

軟件測試V模型要求我們在需求階段就開始制定系統測試的計劃,開始考慮系統測試的方法。但這還不是足夠的。全面的質量管理要求我們在每個階段都要進行驗證和確認的過程。因此在需求階段我們還需要對需求本身進行測試。這個測試是必要的,因爲在許多失敗的項目中,7 0 %~8 5 %的返工是由於需求方面的錯誤所導致的。並且因爲需求的緣故而導致大量的返工,造成進度延遲、缺陷的發散,這是一件及其痛苦的事情。因此我們要求在項目的源頭(需求)就開始測試。這類測試更多的還只是靜態手工方面的測試,當然也有一些自動化的工具,但這些工具會要求我們按照某個固定的格式進行需求的表述(例如形式化的方法),因此在適用性上會受到限制。通過靜態手工方法進行需求測試中最常使用的手段是同行評審。

第97帖【2004-9-4】:通過評審來測試需求

同行評審是業界公認的最有效的排錯手段之一。我們在需求測試過程當中,使用最多的也是同行評審(Peer Review),尤其是正規檢視(Inspection)。正規檢視是由Michael Fagan 在I B M 制定出來的一種非常嚴格的評審過程。

需求評審的參與者當中,必須要有用戶或用戶代表參與,同時還需要包括項目的管理者,系統工程師和相關開發人員、測試人員、市場人員、維護人員等。在項目開始之初就應當確定不同級別、不同類型的評審必須要有哪些人員的參與,否則,評審可能會遺漏掉某些人員的意見,導致今後不同程度的返工。

第98帖【2004-9-6】:好的需求應當具有的特點

一個良好的需求應當具有一下特點:

Ø 完整性。每一項需求都必須將所要實現的功能描述清楚,以使開發人員獲得設計和實現這些功能所需的所有必要信息。

Ø 正確性。每一項需求都必須準確地陳述其要開發的功能。

Ø 一致性。一致性是指與其它軟件需求或高層(系統,業務)需求不相矛盾。

Ø 可行性。每一項需求都必須是在已知系統和環境的權能和限制範圍內可以實施的。

Ø 無二義性。對所有需求說明的讀者都只能有一個明確統一的解釋,由於自然語言極易導致二義性,所以儘量把每項需求用簡潔明瞭的用戶性的語言表達出來。

Ø 健壯性。需求的說明中是否對可能出現的異常進行了分析,並且對這些異常進行了容錯處理。

Ø 必要性。“必要性”可以理解爲每項需求都是用來授權你編寫文檔的“根源”。要使每項需求都能回溯至某項客戶的輸入,如Use Case或別的來源。

Ø 可測試性。每項需求都能通過設計測試用例或其它的驗證方法來進行測試。

Ø 可修改性。每項需求只應在S R S 中出現一次。這樣更改時易於保持一致性。另外,使用目錄表、索引和相互參照列表方法將使軟件需求規格說明書更容易修改。

Ø 可跟蹤性。應能在每項軟件需求與它的根源和設計元素、源代碼、測試用例之間建立起鏈接鏈,這種可跟蹤性要求每項需求以一種結構化的,粒度好(fine-grained)的方式編寫並單獨標明,而不是大段大段的敘述。

另外應當對所有的需求分配優先級。如果把所有的需求都看作同樣的重要,那麼項目管理者在開發或節省預算或調度中就喪失控制自由度

第99帖【2004-9-8】:通過用例設計來測試需求

我們從V模型上可以知道,驗收測試是以系統需求爲基礎的,系統測試是以功能測試爲基礎。每個開發階段的活動都與相應的測試活動是並行進行的。在需求階段進行系統(驗收)測試計劃和設計,除了能指導最終的系統測試和驗收測試執行外,其本身也是對需求的一個驗證過程。

通過閱讀軟件需求規格說明書,通常很難想象在特定環境下的系統行爲。以功能需求爲基礎或者從使用實例派生出來的測試用例可以使項目參與者看清系統的行爲。雖然沒有在運行系統上執行測試用例,但是設計測試用例的簡單動作可以解釋需求的許多問題。如果你在部分需求穩定時就開始開發測試用例,那麼就可以及早發現問題並以較少的費用解決這些問題。

設計概念性測試用例可以發現需求的錯誤、二義性、不可測性、遺漏等方面問題,爲了獲得最大的效果,要求測試人員能夠獨立的去對需求進行思維,從一個不同於開發的角度上進行分析,這可能會是一個逆向的思維過程,在這個過程中,測試人員可能會設計出不同於需求的測試用例,而這最終可能會有兩個解釋:

Ø1、需求不完整或者需求有錯;

Ø2、遺漏了測試用例或者測試用例本身有錯誤;

不管是哪種解釋,最終肯定會提高整個系統的質量。但這個質量的獲得是通過冗餘的人員來完成的,即:開發人員在對系統需求進行進一步分析的時候,有一組獨立的測試人員也在對系統需求進行獨立的思維,並從中獲取測試用例。儘管這兩種思維可能會出現重複,但由於思維的方式不同,最終肯定會使得需求變得更清晰和更完善。

第100帖【2004-9-9】:需求建模測試

需求的建模包括把需求轉換成圖形模型或形式化語言模型。需求的圖形化分析模型包括數據流圖(Data Flow Diagram,DFD)、實體關係圖(Entity-Relationship Diagram,ERD)、狀態轉化圖(State-Transition Diagram,STD)、對話圖(Dialog Map)和類圖(Class Diagram)。這些圖形化模型一般都需要藉助一定的CASE(Computer-Aided Software Engineering)工具。這樣就可以藉助於自動化分析工具本身提供的檢測手段來對需求進行測試,而這類檢測主要可以提供描述上的完整性檢查,需求項之間的不一致性檢查等方面的功能。同時,使用這類自動分析工具有助於獲得需求的質量特性,包括:有效性、一致性、可靠性、可存活性、可用性、正確性、可維護性、可測試性、可擴展性、可交互性、可重用性、可攜帶性等。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章