國家別/組織別 標 準
英國標準
(British Standard,BS) BS
7925-1:軟體測試字彙(Vocabulary)。
BS 7925-2:軟體元件(Component)測試標準。
Def Stan 00-55:國防裝備安全性相關的軟體之要求標準。
DO-178B:在空運系統與裝備(Equipment)保證(Certification)之軟體考量標準。
國際電子技術委員會標準
(The International Electrotechnical Commission,IEC) IEC
60300-3-9:技術系統風險(Risk)分析標準。
IEC
61508:用電(Electrical)、電子(Electronic)、可程式化(Programmable)的功能性安全相關系統標準。
IEC 880:核能電廠安全系統電腦軟體標準。
IEEE 610:電腦字典(Dictionary)標準。
IEEE 610.12:軟體工程(Software
Engineering)專門用語(Terminology)。
IEEE 730:軟體品質保證(Software Quality
Assurance)計畫標準。
IEEE 829:軟體測試文件(Documentation)標準。
IEEE 1008:軟體單元(Unit)測試標準。
IEEE 1012:軟體驗證與確認(Software Verification and
Validation)之標準。
IEEE 1028:軟體審查(Reviews)標準。
IEEE
1044:軟體異常(Anomalies)分類(Classification)標準。
IEEE
1044.1:軟體異常(Anomalies)分類(Classification)指引(Guide)。
國際標準組織
(The International Organization For Standardization,ISO) ISO
9000:品質管理與品質保證(Assurance)標準。
ISO
9001:設計(Design)、開發(Development)、生產(Production)、安裝(Installation)和服務(Servicing)之品質保證模式。
ISO 9000-3:應用ISO
9001標準去開發、提供、安裝與維護之電腦軟體指導綱要(Guidelines)。
ISO/IEC 12207:軟體生命週期作業。
ISO 15026:系統與軟體整合性層次(Integrity Levels)。
ISO 15288:系統生命週期過程。
國際標準技術學會
(The National Institute Of Standards And Technology,NIST) NIST
500-234:軟體驗證與確認(Verification and
Validation)流程之參照資訊。
SE CMM(System Engineering Capability Maturity
Model):系統工程性能完整模式。
SW CMM(Capability Maturity Model for
Software):軟體功能性完整模式。
TMM (Testing Maturity Model):測試完整模式。
歐洲太空署
(European Space Agency,ESA) PSS:程序、規格和標準。
PSS-05-0:歐洲太空署(ESA)軟體工程標準。
汽車工業軟體信賴學會
(Motor Industry Software Reliability Association)
MISRA:以車輛為主之軟體開發指導綱要(Guidelines)。
軟體測試標準面面觀
本節從流程(Process)的角度、品質(Quality)的角度和專用語(Terminology)角度來探討軟體測試標準,如圖一所示:
圖一:從流程、品質、專用語三個角度看軟體測試
圖二:流程(Process)角度的軟體測試
(一)從流程(Process)的角度來看:
依據IEEE
610對流程(Process)的定義為「達到特定目標所執行的一連串步驟」。從流程的角色來看軟體測試(Software
Testing),亦有各種定義,BS
7925-1提出主要的定義:應用軟體去驗證符合特定需求,並能找出錯誤的流程。此外,軟體測試也應包括執行軟體驗證與確認(Software
Verification and
Validation)中的靜態技術,例如審查(Reviews)與檢視(Inspection)。很顯然地,驗證與確認不能被當成單獨的流程來執行,而是軟體工程(Software
Engineering)流程中的一部份。因此,從流程角度來看,軟體測試是驗證與確認的一部份,被視為包含在軟體工程中,亦是系統工程(System
Engineering)的一部份。其關係如圖二。
事實上,系統工程、軟體工程和驗證與確認,都有其相對的標準(例如:ISO
15288,ISO/IEC 12207和IEEE
1012)。這些標準都有自己相對應的軟體測試作業規範。而ISO
15288和ISO/IEC
12207兩標準,更包含驗證與確認的作業。ISO/IEC
12207標準,它是定義軟體生命週期作業標準;不同於ISO
9001國際標準,其被美國的IEEE機構認為是整合性軟體工程標準,因而有IEEE/EIA
12207序列資訊系統標準供軟體業者參考引用。IEEE
1012標準,則專門定義驗證與確認流程、活動、執行的作業規範。
(二)從品質(Quality)的角度來看:
依據ISO
8402品質詞彙中,對品質的定義為「一個實體的特性總合,此種特性具有滿足明訂與潛在的需求之能力」。從品質(Quality)的角度來看,測試乃驗證與確認的一部份(如圖三),被視為軟體品質保證(Software
Quality
Assurance)完整的部份。其關係如同:假如軟體是較大系統的一部份,那麼,軟體測試可被視為品質管理與保證(Quality
Management and
Assurance)的一部份。依據此流程模式,在說明較高層次,是由相對的標準所涵蓋(例如:ISO
9000,IEEE 730與IEEE 1012)。IEEE
730為軟體工業標準,目的為軟體品質保證計畫提供一個一致的、可接受的需求準則,偏重於開發軟體的基本計畫,並指出軟體品質保證所需的共同項目。大部份的軟體發展者都不會忽略ISO
9000標準,但是一般認為此層次之測試程式基本上都沒有相對的測試文件。
圖三:品質(Quality)角度的軟體測試
圖四:專用語(Terminology)角度的軟體測試
(三)從專用語(Terminology)的角度來看:
採用統一的標準專用語(Terminology),將有助於溝通與瞭解。應採自然語言,如同我們日常生活語法一樣,此標準在最高層次,從計算用語與軟體工程用語,最後導用到軟體測試用語。此標準可用於此模式(如圖四)的每一層。例如:開始用在牛津英語字典,又被導用於IEEE
610、IEEE 610.12,最後又用到BS 7925-1等軟體測試字彙上。
三、軟體測試模式與對映標準
儘管許多測試者認為軟體測試標準是屬於高層次的,但是從上節三個角度來看,與軟體測試有關的大部份標準已經被律定。然而,從相容性和市場觀點來看,ISO
9001國際標準僅提供給實際測試者少部份的軟體測試能力,而ISO/IEC
12207生命週期標準被認為在相容性上也會有問題。因此,本節提供一個軟體測試模式從企業組織由上而下分級來探討所對映的標準為何。
此軟體測試模式:包含從組織層到每一專案階段。包括:流程測試、流程改善(Improvement)、專用語(Terminology)、文件和意外(Incident)管理。(如圖五)每一模式的元件均依據其相關之支援標準。
圖五:一般性軟體測試模式
1.測試專用語(Test Terminology):
IEEE 610.12:提供軟體工程專用詞語(Glossary)。
BS
7925-1:提供軟體測試的專門字彙。其缺點是偏向於元件測試;它是源自於BS
7925-2的定義而來,原本完全偏向於元件測試,但是現在已普遍延用於一般軟體測試。
2.測試政策(Policy):
將企業組織對軟體測試的考量詳細地描述出來,並保證這些標準(例如ISO
9001、ISO/IEC 12207、IEEE 730等)的相容性問題。
ISO
9001:只提供一個非常高層次的需求規格,作為執行測試時驗證與文件的參考。
ISO/IEC
12207:定義驗證與確認流程之規格,以支援軟體開發、維護等主要的作業流程。
IEEE
730:要求軟體驗證與確認計畫(Plan)與任何測試文件(Documentation)之產品標準。
從測試者的觀點來看,不需要同時使用ISO 9001與ISO/IEC
12207。
3.測試策略(Strategy):
定義測試階段所必須完成之高層次(High
Level)的文件。
ISO
9000-3:提出有關單元、整合、系統和驗證的測試,提供給IS0
9001應用之導引。
IEEE 1012:定義驗證與確認流程、活動和任務。
ISO
15026:基於風險分析的角度來定義整合性層次流程。
4.專案測試計畫(Project Test Plan):
此文件定義測試階段種類及相關階段內特定專案的測試作業。其標準除了測試策略所談的IEEE
1012、ISO 15026之外,尚有IEEE
9000-3提出測試計畫檢索。IEEE
829則強調是一套全面性測試計畫需求文件。
5.階段(Phase)測試計畫:
提供階段內執行測試詳細需求。包括元件(Component)測試計畫、整合(Integration)測試計畫。IEEE
829提供整體的一套測試計畫需求。還有更多與單元、元件測試階段有關的標準,BS-7925-2:定義詳細整體元件測試計畫內容與提供一套案例文件說明。
6.流程測試(Test Process):
BS 7925-2定義一般性的元件測試流程(如圖六)。IEEE
1008則提供類似於BS
7925-2詳細的測試流程,但屬於單元測試。
圖六 一般性軟體測試流程
階段性的測試計畫,應該考量測試案例(Test
Case)設計的技術及所應採用的標準二件事,此二件事與軟體的整合層次有關。而整合層次流程被定義於ISO
15026中。風險分析流程被定義在IEC
60300-3-9。測試計畫和測試規格書將被IEEE
1028標準來審查(Review)。在測試規格活動中的測試例子(Test
Case)設計技術以及使用在完成檢驗(Check
Completion)活動中所涵蓋的測試方法與案例,均在BS
7925-2中定義。
7.意外管理(Incident Management):
意外管理是屬於檢驗與報告(Check and
Report)活動的主要部份,是測試流程的重要部份,經常被稱為問題報告(Problem
Reporting)或異常分類(Anomaly Classification)。ISO/IEC
12207包括問題解作業、IEEE 829包含意外報告(Incident
Reporting)文件。更多詳細範圍被定義在IEEE
1044中,它定義異常分類流程與分類方案。IEEE 1044是IEEE
1044.1的全面性指導綱要(Guidelines)。
8.測試文件(Test Documentation):
IEEE
829提供一套全面性的測試計畫、測試規格(Specification)與測試報告文件。
9.測試流程改善(Test Process Improvement):
測試流程改進應是組織測試政策(Policy)的一部份,流程改善(Process
Improvement)被規範於ISO 9000標準中並需與ISO/IEC
12207標準相互遵循引用,如此,此改善流程(Improvement
Process)方能與測試政策相配合。
在系統工程與軟體工程層次方面,軟體工程學會(Software
Engineering
Institute,SEI)已有功能完整模式產品(分別為:系統工程性能完整模式(System
Engineering Capability Maturity Model,SE
CMM)、軟體功能性完整模式(Capability Maturity Model for
Software,SW CMM),均涵蓋些許測試規範。ISO
15504是國際性軟體流程改善標準,其中也包括一些軟體測試規範。或許沒有任何流程改進標準是針對特定的軟體測試流程,但還是有專業的計畫,如測試完整模式(Test
Maturity
Model,TMM),可以應用到軟體測試流程改善上。(如圖七)
圖七:測試改善流程
四、整合層次與風險為基測試標準
在與安全相關的實務應用中,整合層次已經應用多時。整合層次的觀念允許某單一標準去定義不同的需求,常與整合層次產品所採用的標準有關。產品可能是完整系統,但通常是系統的一部份;這意謂著標準要求不同的系統,符合不同之需求。分割(Partitioning)系統是明智合理的,否則整個系統中最高整合層次(Highest
Integrity)將須符合更嚴苛之需求,而最高整合層次也許只是全部系統的一小部份而已。整合層次通常取決於風險評估,當應用在安全性相關的應用程式時,風險評估是建立在安全問題上。一旦整合層次被確定,那麼符合它的要求(如:方法、技術、涵蓋的層次等等)就可被整合層次予以選定。
整合層次的使用最初被限制在特定應用(Application-Specific)標準上面,如:DO-178B(航電控制系統)、Def
Stan
00-55(防禦系統)和MISRA(汽車產業系統);但這發展是漸進的,譬如最近所發表的IEC
61508,它將應用在電機(Electrical)/電子(Electronic)/可程式(Programmable)的安全性相關系統上;大致可用來取代先前提到的標準。IEC
61508在美國拓展的速度比較慢,就如同它被歐洲接受成為標準一樣。IEC
61508有四個整合層次,大部份標準都使用此觀念,是相當全面性的,並包含硬體和軟體。
IEC 61508為常見的安全性相關的特定應用標準。IEEE
1012也使用整合層次概念,其既不是安全性相關標準也不是專業應用標準;此標準定義驗證與確認的執行時,是以四個軟體整合層次為基礎,這些整合層次不需要安全相關性(Safety-Related),但卻植基於(Based
on)其他的風險型態上(如:經濟、安全等)。ISO
15026則定義一個植基於風險分析之整合層次流程;這標準也定義整合層次必須將軟體的風險值(Values)限制在一定範圍(Range)內。這些標準(包括風險分析標準IEC
60300-3-9)支持近來出現與流行的風險基礎測試和提供最初的標準架構。
五、特定應用標準
有許多應用在軟體開發與測試上的特定應用標準(Application-Specific
Standard),而這些標準多與軟體安全性有關;類似的標準有DO-178B(航電控制系統),MISRA(汽車產業系統),Def
Stan
00-55(防禦系統),及IEC880(核能系統),前三項標準是使用整合層次之觀念所訂定,而IEC880(核能系統)則否。
一項疑問經常被提出:「為何特定應用(Application-Specific)標準,不能成為一般通用軟體開發、測試的標準」,沒有說適用於航電控制系統測試標準不能用於汽車、製藥、醫療、財務等應用系統。其實只要是軟體開發失敗的風險性(Risk)是在同樣的層次,那麼其在軟體開發與測試所努力的結果,將會適當的被使用是應屬合理的。例如,同為影響一企業未來營收之汽車製造系統軟體元件(Component)與財務系統軟體元件(Component),其兩個系統均分別需經嚴格測試,就測試標準來講,兩種系統很難比較誰的測試技術比較好。換句話說,如果兩個系統都具有相同之失敗風險,則其應享有同等之測試標準。
已知,不應有其特定應用的軟體開發與測試標準,但為何又存在這種現象?試想,在某特殊產業中,他們認為需要一套專門的軟體開發與測試標準,經由產業中的專家們發展出來,其實此標準可被視為一通用性(Generic)標準,但由於此等專家對其他系統並不了解,同時也想滿足委請他們發展標準的業界,所以他們就把其發展的標準當成在此專業中軟體開發測試的特殊標準。PSS-05-0(歐洲太空署軟體工程標準)發展小組就遇到這個問題。這個小組將其標準視為一般軟體開發通用標準,他對如何開發出高品質的軟體提供了精確的定義。因此,PSS-05-0標準的發展較所謂的特定應用標準更勝一籌。此標準在軟體檢視上參考IEEE
1028標準,在有效性檢測上參考IEEE
1012,在軟體文件檢測方面則參考IEEE
829,它唯一不足的是,未使用整合層次概念。IEC
61508可滿足整合層次之一般標準,但其強調該標準較適用於與安全相關之應用,至於為何IEC
61508不適用於非安全相關之軟體,此點並未被清楚的指出來。
雖然有些特定應用標準只考慮軟體測試,但例如NIST
500-234是定義軟體驗證與確認流程之參照資訊。這些少數特定應用標準提供不錯的通用軟體測試標準,同時亦具備特定應用測試再利用軟體及智慧型系統之能力。其相關文件可在網站上取得。
一般來說,特定應用的軟體開發與測試標準並不值得發展,因此,把用在開發專業應用標準的人力,用在開發一般型的標準上,如此,更能節省重覆人力的投資,例如,將專家在他們所使用的應用領域裡所提供的整合性層次標準開發理念,應用在整合層次的一般性軟體測試標準開發上,實是最佳的利用。
六、軟體測試標準架構
由前面所述來看,依照某些型態之風險評估,整合層次(Integrity
Levels)是最適合定義不同層次的測試標準與測試軟體。雖然對某些特定應用言,某些特別的標準是存在的,而一旦某軟體的整合層次標準確立了(ISO
15026即適用於此),它們亦可被當成驗證與確認之標準,以決定在何測試階段,做何測試。IEEE
1012標準即適於應用於此項作為。因此,整合層次測試可使用於各個測試階段,以決定測試技術及測試標準,所有經長使用的測試標準,定義在專用語字彙中。在BS7925-1擴充版標準中均對測試標準做規範。其軟體測試標準架構如圖八所示:
圖八:軟體測試標準架構
有關階段測試,現行標準僅支援元件(Component)、單元(Unit)測試階段(BS
7925-2和IEEE
1008規範這階段之測試),至於整合測試、系統功能及非功能、及可接受度測試等,尚需建立相關標準。
BS7925-2之內容包含測試技術與衡量標準之定義與流程,此技術與衡量標準並不只適用於單元測試,且亦適用於其他測試階段。例如,臨界值(Boundary
Value)測試,其即可適用於所有測試階段。然而由於BS7925-2主要用於單元測試,其測試技術及衡量方法僅涵蓋單元測試部份,如此造成在制定其他測試標準時參考的不易,如要重新定義新標準,又易產生各標準間不一致的情形,更糟的是,它將造成制定標準之人力重覆投資的浪費。解決上述問題的方法就是制定一可通用於各測試階段的標準,此標準將告訴我們各測試階段所應使用之方法及衡量標準。此項做法唯一不好的是新定之測試技術與衡量標準將去除大部份BS7925-2原有之規範與相關定義,只留下單元測試流程部份。然而,修訂BS7925-2原有之規範與相關定義,卻是新標準產生的最佳起點。
七、結論
本文以上提出了不少高層次的軟體測試標準與規範,其中最重要的兩項是:強調一致性與市場性的ISO
9000國際標準,及定義生命週期作業流程架構的ISO/IEC
12207標準。其次,針對通用性測試模式的建立,以訂定更詳細之測試標準規範。這種測試模式不適用於個別測試階段,而適用於單元測試,而此種測試方式的標準又以BS
7925-2最好。此種模式的另一缺失是,改善測試流程的資訊太具專屬性,並不通用,故此種模式尚待標準化。至於通用性測試模式的其他方面,一般標準均支援,尤其在意外管理(Incident
Management)及整合層次(Integrity
Level)分類方面,有不少標準均支援。
總之,軟體測試工作是一門專業技術,沒有絕對的標準可以確保其測試品質與效率。但為提高軟體生產力與優良品質,軟體測試工作是相當重要的、必要的。但確不能只靠軟體測試,還必須配合流程的改善。因此,相關的標準規範都要有所引用參考,方能確保軟體品質。