IBM中國有限公司軟件部高級技術(shù)顧問 靳超

一. 質(zhì)量是產(chǎn)品的生命

　　當(dāng)今隨著軟、硬件技術(shù)的發(fā)展,嵌入式系統(tǒng)廣泛應(yīng)用于航空航天、國防軍事、電子通訊等行業(yè)，其中軟件也越來越復(fù)雜。而這些領(lǐng)域應(yīng)用特點(diǎn)，決定了嵌入式系統(tǒng)往往是高安全、任務(wù)關(guān)鍵的系統(tǒng)，軟件的微小瑕疵，就可能嚴(yán)重威脅到生命和國家的安全、天文數(shù)字的巨額財產(chǎn)損失。就使得保證嵌入式軟件的質(zhì)量和可靠性，變得至關(guān)重要。而在這些領(lǐng)域，對產(chǎn)品質(zhì)量從來就保持著高度的重視，有將“質(zhì)量視為產(chǎn)品的生命”的傳統(tǒng)。這樣，相關(guān)行業(yè)的高層管理人員和開發(fā)人員對于軟件的質(zhì)量也逐漸提高了重視程度。近年來，在組織上，建立了完善的軟件測試體系，從自檢，到專檢，直到甲方的測試中心；在開發(fā)和測試方法上，沿襲了多年在系統(tǒng)工程和硬件設(shè)計中積累的經(jīng)驗(yàn)，在項目管理中將“兩條指揮線四總”的體制推廣到軟件領(lǐng)域，建立了中國的軟件過程成熟度的評價體系GJB5000；在自動化工具方面，投入了大量的經(jīng)費(fèi)和人員在測試設(shè)備的開發(fā)、購置和建設(shè)方面。應(yīng)該說，軟件，作為嵌入式產(chǎn)品主要的組成部分之一，對其質(zhì)量的重視，是目前相關(guān)行業(yè)內(nèi)的一個共識 。
　　然而在現(xiàn)實(shí)生活中，許多軟件產(chǎn)品卻時常陷入質(zhì)量低下的旋渦，總是不盡人意，問題常常表現(xiàn)在：
　.　相關(guān)產(chǎn)品的領(lǐng)導(dǎo)得不到產(chǎn)品質(zhì)量的具體信息，不能對軟件研發(fā)體系交付產(chǎn)品的質(zhì)量建立信心；
　.　項目管理人員無法實(shí)時對項目中軟件部分所處的質(zhì)量狀態(tài)有所了解；
　.　產(chǎn)品在集成階段，常常因?yàn)檐浻布旌系募蓡栴}難以解決，而造成延期，甚至由于進(jìn)度的要求，降低產(chǎn)品的質(zhì)量基線；
　.　開發(fā)團(tuán)隊沒有時間和資源繼續(xù)測試，發(fā)布未經(jīng)過完善測試的產(chǎn)品，然后在維護(hù)產(chǎn)品上花費(fèi)更多的時間、經(jīng)費(fèi)和人員；
　.　于此同時，研發(fā)體系困惑于測試工具的使用，發(fā)現(xiàn)那些購買是良好演示的工具卻無法測試我們開發(fā)出來的系統(tǒng)；
　.　軟件總是由總師設(shè)計出來，由開發(fā)人員編寫出來，最后在項目即將交付時，交給測試人員，由他們承擔(dān)質(zhì)量責(zé)任。
　.　軟件測試更象一場“運(yùn)動”，在項目交付階段臨時組織起來的測試團(tuán)隊，面對交付的壓力，不得不尋求無需學(xué)習(xí)，無需準(zhǔn)備、無需了解被測對象的，無需硬件，無需源碼，最好什么都不需要的“人工智能”的測試工具，只要能出報告，而無暇顧及軟件質(zhì)量的本質(zhì)要求。
　　.　現(xiàn)有的工具往往無法滿足這些測試的需求，我們常常找些看似滿足的，但在實(shí)際使用中，又會發(fā)現(xiàn)由于我們對工具使用預(yù)期不恰當(dāng)?shù)亩ㄎ?，工具原本的功能由于其他的因素?zé)o法發(fā)揮。
　　.　現(xiàn)有的工具常常處于閑置狀態(tài)，而開發(fā)團(tuán)隊又有很多問題得不到解決，需要更多的工具。
　　究其根源，除了軟件本身故有的復(fù)雜性，還和不同的組織對軟件產(chǎn)品質(zhì)量內(nèi)涵有著不同的認(rèn)識，造成不同的工作方式和態(tài)度，養(yǎng)成了不同的工作和思維習(xí)慣，和由此帶來不同的產(chǎn)品質(zhì)量結(jié)果。
　　IBM Rational多年來在軟件工程和質(zhì)量保證方面積累了豐富的方法和經(jīng)驗(yàn)。本文依據(jù)部分嵌入式開發(fā)機(jī)構(gòu)中對軟件質(zhì)量保證工作的一些理解，分析相應(yīng)開發(fā)機(jī)構(gòu)工作中可能的問題，并提出以RUP為核心的全過程的質(zhì)量管理的思想和具體的實(shí)現(xiàn)方式，提出不同單位的過程改進(jìn)方法，以一種漸進(jìn)的方式，從簡單的工作開始，逐漸深入的改進(jìn)組織的軟件質(zhì)量管理水平
　　但我們也需要看到，盡管可能不需要一個繁重的、一蹴而就的過程來達(dá)到高質(zhì)量的要求，但是關(guān)注質(zhì)量的組織思維傾向是必要的條件，并且這必須由最高管理層驅(qū)動。

二. 定義質(zhì)量

　　對于任何一個組織，定義共同的對質(zhì)量的理解，是重要的第一步。軟件開發(fā)組織經(jīng)常按照一種不精確的、概括的質(zhì)量觀念來運(yùn)轉(zhuǎn)。
在IBM Rational統(tǒng)一過程中，質(zhì)量定義如下：
　.　滿足或超出認(rèn)定的一組需求
　.　使用經(jīng)過認(rèn)可的評測方法和標(biāo)準(zhǔn)來評估
　.　使用認(rèn)定的流程來生產(chǎn)。
　　在這個定義中，我們首先看需求，IBM Rational的軟件質(zhì)量在用戶需求方面的定義分為這樣幾個方面：

　
　　講到質(zhì)量保證，歸根結(jié)底就是為客戶提供更高品質(zhì)的產(chǎn)品，更好地滿足客戶的需求。而且客戶的需求是多維的，產(chǎn)品的功能性需求應(yīng)該是客戶首先要考慮的因素，同時還包括其他四個方面。除了這些技術(shù)因素之外，用戶的需求還應(yīng)該包括產(chǎn)品要在指定的時間和預(yù)算范圍內(nèi)完成。

{{分頁}}
　　第二方面，這個質(zhì)量定義中明確指出，質(zhì)量更體現(xiàn)在軟件開發(fā)的整個過程和一個標(biāo)準(zhǔn)的評價方式上。在過程質(zhì)量方面，經(jīng)常舉的一個例子就是汽車生產(chǎn)過程。當(dāng)我們面對推銷員推銷兩款汽車，其中一款是由先進(jìn)的生產(chǎn)線生產(chǎn)的產(chǎn)品，而另一款是由技術(shù)精湛的師傅手工精制而成，在汽車的質(zhì)量方面，您會作何感想呢？通過了解市場上同型號車的質(zhì)量狀況，你可以輕松做到對第一輛車心中有數(shù)；但對第二輛呢？由此可見，你對第一輛車的信任，來自于過程質(zhì)量。
　　.　軟件開發(fā)過程質(zhì)量就是指為了生成工件而對可接受流程的實(shí)施和遵守程度，體現(xiàn)在三個層次：
　.　產(chǎn)品本身和用來生產(chǎn)、組裝軟件產(chǎn)品的零部件質(zhì)量，包括用來進(jìn)行軟件開發(fā)或在軟件開發(fā)過程中產(chǎn)生的代碼、文檔、模型和可執(zhí)行系統(tǒng)等工件；
　.　軟件開發(fā)活動本身對標(biāo)準(zhǔn)化軟件開發(fā)過程的遵守和貫徹的程度，主要體現(xiàn)在軟件開發(fā)過程的標(biāo)準(zhǔn)化、流程化、自動化程度和團(tuán)隊基本協(xié)作平臺的效率，各個過程對質(zhì)量的承諾；
　　用來對整個軟件產(chǎn)品進(jìn)行驗(yàn)收的評測手段，它應(yīng)該是被業(yè)界廣泛認(rèn)可和接受的方法，應(yīng)以優(yōu)先考慮經(jīng)典的測試方式的實(shí)現(xiàn)，構(gòu)筑質(zhì)量評價的基礎(chǔ)，然后再針對某些低效環(huán)節(jié)補(bǔ)充其他專門的測試手段。
　　一個軟件生產(chǎn)企業(yè)的過程質(zhì)量一般可以用它的軟件過程成熟度等級來評估，但它依賴我們采取的方法、工具和軟件開發(fā)平臺來決定。
　　我們應(yīng)該如何達(dá)到這一質(zhì)量目標(biāo)呢？盡管要求更好質(zhì)量的下意識反應(yīng)就是擴(kuò)大測試團(tuán)隊，但是這可能不是最好的方法。作為替代，應(yīng)當(dāng)在你的過程中關(guān)注每一個步驟的質(zhì)量。RUP全過程的質(zhì)量保證過程強(qiáng)調(diào)的是在RUP的九個工作流程中都要逐漸形成產(chǎn)品的內(nèi)在質(zhì)量，是由所有團(tuán)隊成員按照要求完成自己的工作并按照RUP中提供的手段檢查自己的工作而締造的。而測試流程是由專門的各個測試角色來負(fù)責(zé)，目的在于評估和改善產(chǎn)品質(zhì)量，監(jiān)控質(zhì)量狀態(tài)的方面。
　　有些開發(fā)人員或許會感覺這樣做不現(xiàn)實(shí)，做不到，或目標(biāo)太遠(yuǎn)大而不實(shí)際，我們在這里想要展示的就是不這樣做，我們僅有的質(zhì)量保證和測試活動在應(yīng)對未來復(fù)雜的系統(tǒng)開發(fā)測試需求時，將耗費(fèi)巨大的經(jīng)費(fèi)和時間，甚至根本無法實(shí)施。而同時，我們將提出一個漸進(jìn)的改進(jìn)方式，最終達(dá)到全過程質(zhì)量保證體系的要求，我們要做的，僅僅是，開始！

三. RUP全過程質(zhì)量保證

　　Rational Unified Process(簡稱RUP)是一個可以通過Web來使用的軟件工程過程。作為軟件工業(yè)事實(shí)上的標(biāo)準(zhǔn)，它回答了我們以下問題：在整個軟件開發(fā)的各個過程中，應(yīng)該由誰（角色）在什么時候（詳細(xì)工作流程）做什么（任務(wù)）和產(chǎn)生什么樣的開發(fā)結(jié)果（工件），以完成整個項目的開發(fā)目標(biāo)。建立有效的工作過程，可以提高團(tuán)隊的生產(chǎn)效率，控制開發(fā)過程中的風(fēng)險，保證軟件開發(fā)進(jìn)度并且提高軟件產(chǎn)品質(zhì)量。同時通過為所有重要的開發(fā)活動提供全面的指南、模板和示例，使整個軟件開發(fā)團(tuán)隊能夠有效共享成功經(jīng)驗(yàn)，提高團(tuán)隊效率，最終保證軟件開發(fā)質(zhì)量。

　　.　全過程質(zhì)量保證思想
　　RUP把整個軟件開發(fā)過程分解成：業(yè)務(wù)建模、需求管理、分析設(shè)計、實(shí)施、測試、部署、配置與變更管理、項目管理和環(huán)境等九個核心工作流程。每個核心工作規(guī)程由多個詳細(xì)工作流程組成。RUP使用角色、任務(wù)和作為輸入輸出的工件來組織每個詳細(xì)工作流程，實(shí)現(xiàn)軟件開發(fā)組織內(nèi)部人、資源和流程的融合。在許多組織中，將測試團(tuán)隊成員視為缺點(diǎn)的清除者，在生命周期后期將他們放在一個應(yīng)用軟件上，讓他們?nèi)ゲ檎移渌鼒F(tuán)隊成員引入的缺陷。為了最有效地測試，測試團(tuán)隊必須更關(guān)注于系統(tǒng)級質(zhì)量問題上。RUP通過建立完整的軟件開發(fā)過程，使得產(chǎn)品的質(zhì)量由項目團(tuán)隊的每個成員所代表的角色共同負(fù)責(zé)，具體體現(xiàn)在：
　
　　　　.　每個工作流程設(shè)定相應(yīng)的工作指南和工作檢查點(diǎn)
      .　每個角色承擔(dān)相應(yīng)的質(zhì)量任務(wù)
 　　    .　角色的每個任務(wù)要產(chǎn)生合格的工件
           .　產(chǎn)品的每個工件建立工件指南、模板和工件檢查點(diǎn)
　　在RUP中，整個軟件開發(fā)過程如上圖所示，它以指定的工件為輸入，通過軟件開發(fā)角色和標(biāo)準(zhǔn)化的軟件開發(fā)活動，生產(chǎn)出滿足質(zhì)量要求的輸出工件。為確保每個工作環(huán)節(jié)的有效執(zhí)行和每個工作環(huán)節(jié)產(chǎn)生的工件質(zhì)量，RUP為主要工作流程提供了對應(yīng)的工作指南和檢查點(diǎn)，為每個工件建立指南、模板和檢查點(diǎn)，從而保證了軟件開發(fā)的過程質(zhì)量。
　　大家可能都曾注意到，RUP的九個核心工作流程并沒有一個質(zhì)量保證的流程。原因就在于我們認(rèn)為質(zhì)量是在產(chǎn)品各個流程中形成的一種產(chǎn)品的屬性，而不是一件流程，質(zhì)量就是質(zhì)量。它意味著，應(yīng)當(dāng)在你的過程中關(guān)注每一個步驟的質(zhì)量。理解這個，是創(chuàng)建一個真正成功的應(yīng)用軟件交付過程的關(guān)鍵。
　　我們都曾經(jīng)誓言視質(zhì)量為產(chǎn)品的生命，在此在回顧一下我們的誓言，將使我們更有信心沿著正確的道路走下去。
　
　　.　過程質(zhì)量
　　努力建立組織級別的，可以針對不同類型項目，指定項目管理的流程，工作分配和檢查點(diǎn)。在項目較多是，可以考慮使用項目組合管理工具來導(dǎo)入在RUP基礎(chǔ)上裁剪的項目管理模板進(jìn)行輔助管理，以保障過程的貫徹實(shí)施和監(jiān)控。
　　當(dāng)我們考慮使用RUP時，大家常常因?yàn)樽约翰皇堑拈_發(fā)方式，認(rèn)為RUP對自己沒有價值。其實(shí)，即便我們暫時不準(zhǔn)備采用迭代化的開發(fā)方式，我們也可以把一個V型的開發(fā)模式當(dāng)作一個迭代，來從RUP中吸取其他值得我們參考的思想，改進(jìn)我們的實(shí)際流程。本身在RUP的迭代方式模型中，就有一個類似于瀑布的稱之為“Grand design” 的開發(fā)方式，來應(yīng)對小型的，或是大型又極端重要的，需求長時間保持清晰穩(wěn)定的項目開發(fā)。
　　實(shí)際上大家實(shí)際工作中都或多或少的采取了一些迭代開發(fā)的方式，首先在很多關(guān)鍵領(lǐng)域的項目開發(fā)中采取的預(yù)言、初樣、正樣的方式，本身就是可以認(rèn)為是某種形式的迭代，我們可以順利的沿用自己習(xí)慣的開發(fā)方式，在RUP的過程和工具中吸取對我們有效的部分，并在其他條件成熟時在細(xì)化現(xiàn)有開發(fā)模式階段的粒度。
　　美國國防部原本提倡瀑布過程和觀點(diǎn)，在發(fā)現(xiàn)那么多采用了該方法的失敗之后，不但不再強(qiáng)調(diào)對它的要求(如1988年的STD-2167A標(biāo)準(zhǔn))，而且從1994年的報告開始，積極地鼓勵采用更加現(xiàn)代化的迭代式生命周期來取代瀑布型做法。

{{分頁}}
　　
　　.　軟件工程成功經(jīng)驗(yàn)共同鑄就軟件質(zhì)量的思想
　　激烈的市場競爭催生高質(zhì)量的軟件。同時，軟件行業(yè)經(jīng)過幾十年的發(fā)展，軟件生產(chǎn)工藝、軟件開發(fā)方法和工具都大大進(jìn)步、日趨成熟，這一切使開發(fā)人員盡可采用更給高效的開發(fā)方式，盡享其帶來的好處，開發(fā)高質(zhì)量的軟件。RUP以迭代式軟件開發(fā)、架構(gòu)為核心的軟件開發(fā)、用例驅(qū)動的軟件開發(fā)和風(fēng)險驅(qū)動的軟件開發(fā)為特色，集中體現(xiàn)了以下六個軟件工程成功經(jīng)驗(yàn)，通過它們共同鑄就了高品質(zhì)軟件：
　　　　.　迭代式軟件開發(fā)：能夠有效控制項目風(fēng)險、增加對項目控制能力、減少需求變更對項目的影響，實(shí)現(xiàn)持續(xù)的質(zhì)量驗(yàn)證，實(shí)現(xiàn)測試技術(shù)的早期驗(yàn)證，提高軟件的可測試性；
 .　有效管理需求：能夠做到質(zhì)量保證從頭作起，在軟件開發(fā)一開始，就把好需求質(zhì)量關(guān)，實(shí)現(xiàn)需求的可追蹤性和需求變更的有效管理；
 .　基于構(gòu)件的軟件架構(gòu)：采用可視化建模技術(shù)來構(gòu)建以構(gòu)件為基礎(chǔ)、面向服務(wù)的系統(tǒng)框架，可以有效地管理系統(tǒng)的復(fù)雜度，增強(qiáng)系統(tǒng)的靈活性和可擴(kuò)展性，并解決了大家在采用迭代設(shè)計方法時構(gòu)件不易識別和劃分的問題；
 .　可視化建模：能夠有效解決團(tuán)隊溝通、管理系統(tǒng)復(fù)雜度、提高軟件重用；
 .　持續(xù)的質(zhì)量驗(yàn)證：借助迭代式軟件開發(fā)方法，可以大大提前軟件集成測試和系統(tǒng)測試在整個開發(fā)生命周期中的時間，實(shí)現(xiàn)持續(xù)地軟件質(zhì)量驗(yàn)證，做到盡早測試、盡早反饋，從而確保產(chǎn)品滿足客戶的需求；
 .　管理變更：能夠?yàn)檎麄€軟件開發(fā)團(tuán)隊提供基本協(xié)作平臺，使企業(yè)管理好自己的軟件資產(chǎn)，通過有效管理所有的變更請求，使開發(fā)團(tuán)隊能夠很好的控制開發(fā)進(jìn)度、及時了解項目狀況，同時為項目的量化管理提供幫助。
　　由此可見，在軟件開發(fā)過程中，高品質(zhì)軟件是由以上軟件工程的成功經(jīng)驗(yàn)共同鑄就的。
　
　　.　盡早測試
　　作為質(zhì)量保證工作的一部分，盡早測試是指在整個軟件開發(fā)生命周期中通過各種軟件工程技術(shù)盡量早的完成各種軟件測試任務(wù)的一種思想。IBM Rational主要在以下三個方面為我們提供的盡早測試的軟件工程技術(shù)：
　　首先，軟件的整個測試生命周期是與軟件的開發(fā)生命周期基本平齊的過程，保證當(dāng)軟件的第一個發(fā)布出來后，測試人員要馬上基于它進(jìn)行測試腳本的實(shí)現(xiàn)，并基于測試計劃中的測試目的執(zhí)行測試用例，對測試結(jié)果進(jìn)行評估報告。這樣，我們可以通過各種測試指標(biāo)實(shí)時監(jiān)控項目質(zhì)量狀況，提高對整個項目的控制和管理能力。
　
　　其次，通過迭代是軟件開發(fā)把原來的整個軟件開發(fā)生命周期分成多個迭代周期，在每個迭代周期都進(jìn)行測試，這樣在很大程度上提前了軟件系統(tǒng)測試發(fā)生的時間，這可以在很大程度上降低項目風(fēng)險和項目開發(fā)成本。
　　最后，IBM Rational的盡早測試成功經(jīng)驗(yàn)還體現(xiàn)在它擴(kuò)展了傳統(tǒng)軟件測試階段從單元測試、集成測試到系統(tǒng)測試、驗(yàn)收測試的劃分，將整個軟件的測試按RUP中的角色和階段，劃分成開發(fā)人員測試和系統(tǒng)測試兩個階段，把軟件的測試責(zé)無旁貸地擴(kuò)展到整個開發(fā)人員的工作過程。通過提前測試發(fā)生的時間來盡早地提高軟件質(zhì)量、降低軟件測試成本。

　　.　持續(xù)測試
　　作為質(zhì)量保證工作的一部分，測試成功經(jīng)驗(yàn)持續(xù)測試是從迭代式軟件開發(fā)模式得來。在迭代的方法中，我們將整個項目的開發(fā)目標(biāo)劃分成為一些更易于完成和達(dá)到的階段性小目標(biāo)，這些小目標(biāo)都有一個定義明確的階段性評估標(biāo)準(zhǔn)。每個迭代中都包括需求、設(shè)計、編碼、集成、測試等一系列的開發(fā)活動，都會增量式集成一些新的系統(tǒng)功能。通過每次迭代，我們都產(chǎn)生一個可運(yùn)行的系統(tǒng)，通過對于這個可運(yùn)行系統(tǒng)的測試來評估該次迭代有沒有達(dá)到預(yù)定的迭代目標(biāo)，并以此為依據(jù)來制定下一次迭代的目標(biāo)。由此可見，在迭代式軟件開發(fā)的每個迭代周期我們都會進(jìn)行軟件測試活動，整個軟件測試的完成是通過每個迭代周期不斷增量測試和回歸測試實(shí)現(xiàn)的。
　　采用連續(xù)測試的軟件成功測試經(jīng)驗(yàn)，不但能夠持續(xù)的提高軟件質(zhì)量、監(jiān)控質(zhì)量狀態(tài)，同時也使系統(tǒng)測試的盡早實(shí)現(xiàn)成為可能。從而有效的控制開發(fā)風(fēng)險、減低測試成本和保證項目進(jìn)度。

　　.　自動化測試
　　作為質(zhì)量保證工作的一部分，在整個軟件的測試過程中要想實(shí)現(xiàn)盡早測試、連續(xù)測試，可以說完善的測試流程是前提，自動化測試工具是保證。方法是質(zhì)量保證活動的基礎(chǔ)，工具的作用多體現(xiàn)在對質(zhì)量保證活動的自動化，以提高工作效率。我們可以體會到，沒有質(zhì)量保證活動的最佳方法，工具的自動化沒有實(shí)現(xiàn)的基礎(chǔ)，工具的作用無法體現(xiàn)；沒有工具輔助的質(zhì)量保證活動，也會因?yàn)樘叩墓ぷ鲝?qiáng)度，或過于文檔化、太繁瑣而無法實(shí)施貫徹。自動化測試的實(shí)現(xiàn)，使軟件測試團(tuán)隊能夠?qū)⒏嗟慕?jīng)歷放在更有創(chuàng)造性的工作上，并且將降低由于規(guī)章制度的遵從性需求給開發(fā)測試人員帶來的額外的工作量。

四. 用正確的過程和平臺實(shí)現(xiàn)質(zhì)量

　　IBM提供一個完整的方案以幫助開發(fā)團(tuán)隊構(gòu)建更高質(zhì)量的軟件。這個開放和標(biāo)準(zhǔn)的平臺包括IBM軟件的許多工具，包括IBM Rational統(tǒng)一過程。在開發(fā)的每個階段和每個流程都強(qiáng)調(diào)關(guān)注質(zhì)量，幫助團(tuán)隊來識別開發(fā)生命周期中的早期問題。以下部分描述了RUP和IBM軟件開發(fā)平臺中的工具如何支持每個工作流程中的質(zhì)量實(shí)踐的。

{{分頁}}
　　為減少重復(fù)描述，先將相關(guān)工具的功能統(tǒng)一簡要描述。下面的所有工具都可以以插件的形式集成到開放的Eclipse平臺上，為開發(fā)者提供前所未有的集成環(huán)境。
　　IBM Rational System Developer 用于系統(tǒng)建模和開發(fā)的集成環(huán)境。
　　IBM Rational TestManager 用于計劃、管理和報告任何測試工作要求。
　　IBM Rational Manual Tester 用以提高手工測試工作的效率。
　　IBM Rational Test RealTime 用于嵌入式系統(tǒng)的靜態(tài)度量、代碼規(guī)則檢查、單元測試、覆蓋率分析、內(nèi)存分析、性能分析、代碼跟蹤、線程分析、基于消息的分布式系統(tǒng)測試的跨平臺解決方案。
　　要推動團(tuán)隊溝通、協(xié)作和合作，IBM Rational還提供額外的解決方案：
　　IBM Rational RequisitePro 用于需求和用例管理 。
　　IBM Rational ClearQuest 用于基于工作流的缺陷和變更管理 。
　　IBM Rational ClearCase 用于配置管理。
　　IBM Rational Method Composer 用于組織開發(fā)方法的構(gòu)造和發(fā)布。
　　IBM Rational ProjectConsole 使管理人員能夠更加形象的了解項目質(zhì)量狀態(tài)。它支持由開發(fā)環(huán)境自動收集的數(shù)據(jù)，動態(tài)產(chǎn)生有網(wǎng)頁形式發(fā)布的一個項目狀況和數(shù)據(jù)矩陣。
　　IBM Rational SoDA自動地產(chǎn)生和維護(hù)全面的項目文檔和報告。
　　順便提一下，在開發(fā)方面，我們還有Apex——針對高安全性嵌入式系統(tǒng)Ada語言開發(fā)工具Rational Ada Developer。
　　
　　.　分析
　　Meta Group報告，引起客戶不滿意問題的百分之八十可以追溯到對需求的糟糕理解上。對于任何嵌入式開發(fā)項目，不論是新的系統(tǒng)開發(fā)，或遺留系統(tǒng)更新集成，質(zhì)量開始于分析業(yè)務(wù)，以確保系統(tǒng)需求清晰且準(zhǔn)確地反映了業(yè)務(wù)和客戶需求。
　　首先，我們可以將被測系統(tǒng)置于其將運(yùn)行的環(huán)境中，采用建模的方式，激發(fā)和整理用戶業(yè)務(wù)和分析人員的思維，捕獲盡可能完整的需求，并在后續(xù)的迭代中完善；通過建模的分析方式，建立松耦合、接口清晰的架構(gòu)，為測試的設(shè)計提供基礎(chǔ)；通過采用相適應(yīng)的架構(gòu)機(jī)制，提高系統(tǒng)的可測試性；通過采用流程管理工具，自動化輔助需求的評估和審計；將最優(yōu)確認(rèn)的需求，用條目化的方式管理需求文檔，實(shí)現(xiàn)從需求，到分析，到設(shè)計，到實(shí)現(xiàn)，到測試的雙向跟蹤，以實(shí)現(xiàn)測試中發(fā)現(xiàn)缺陷到各層次的跟蹤，和影響范圍的分析。
　　此活動的工具包括Rational RequisitePro、Rational System Developer、Rational ClearQuest。

　　.　設(shè)計
　　在設(shè)計中，主要的質(zhì)量集中在構(gòu)架上，這是軟件的“靈魂”。低質(zhì)量的構(gòu)架會引起大范圍的質(zhì)量問題，包括（軟件）脆弱，缺乏升級，以及發(fā)現(xiàn)缺陷也難以修改。這些問題隨著應(yīng)用軟件項目不斷發(fā)展，變得越來越難以解決；并且隨著應(yīng)用軟件從設(shè)計到開發(fā)、測試和部署，糾正缺陷的成本以指數(shù)在增長。如果軟件開發(fā)人員可以有效地發(fā)現(xiàn)、隔離和解決設(shè)計和開發(fā)期間的結(jié)構(gòu)上的不足，這項工作會在整個項目期間獲得受益。開發(fā)人員也應(yīng)該確保，軟件是按照一種保持構(gòu)架完整性和靈活性的方式來實(shí)現(xiàn)的，因此，隨著業(yè)務(wù)需求變化，開發(fā)人員可以快速地進(jìn)行變更。
　　針對此工作流程的工具有Rational System Developer、Rational RequisitePro。

　　.　開發(fā)
　　平均起來，開發(fā)人員在他們寫的每千行代碼中會產(chǎn)生100到150個錯誤。當(dāng)然，這個數(shù)量隨著開發(fā)人員和項目不同而不同。即使只有一小段代碼，產(chǎn)生百分之十的錯誤也是很嚴(yán)重的。
　　RUP倡導(dǎo)開發(fā)人員主導(dǎo)的測試和分析上。盡管單元測試和運(yùn)行時分析已經(jīng)變得更為主流，但是許多管理人員仍然有這樣的誤解，即這些過程向時間表中增加了不必要的時間。事實(shí)上，如果不采用這些措施，開發(fā)時間表通常會一樣或更加延長，這是由于在質(zhì)量保證或客戶發(fā)現(xiàn)問題后，開發(fā)人員在生命周期中調(diào)試代碼后所花費(fèi)的時間。對于那些想要減少風(fēng)險和增加可預(yù)測性的團(tuán)隊來說，開發(fā)團(tuán)隊采用一種良好結(jié)構(gòu)的、主動的質(zhì)量保證方法是一個好的解決方案。
　　針對此工作流程的工具有Rational System Developer、Rational Test RealTime、IBM Rational TestManager、IBM Rational RequisitePro。

　　.　測試
　　管理系統(tǒng)級功能和性能測試是持續(xù)保證質(zhì)量的一個主要部分。一個開發(fā)組織既不應(yīng)當(dāng)過分強(qiáng)調(diào)，也應(yīng)當(dāng)減少系統(tǒng)測試的重要性。如前所述，保證質(zhì)量不只是測試團(tuán)隊的職責(zé)；測試也不只是質(zhì)量保證的唯一領(lǐng)域。某些測試可以并且應(yīng)當(dāng)由開發(fā)人員來運(yùn)行，在某些情況下，可以由構(gòu)架師來運(yùn)行。大量的質(zhì)量保證工作，在RUP的原則下，是由其他開發(fā)角色構(gòu)造的。
針對此工作流程的工具有Rational Test RealTime、IBM Rational TestManager、Rational Manual Tester 、IBM Rational RequisitePro。

　　.　支持保證質(zhì)量的團(tuán)隊職責(zé)
　　質(zhì)量是開發(fā)團(tuán)隊中的每個人的職責(zé)，但是它也是團(tuán)隊作為一個整體的職責(zé)。在一個迭代的過程中，每個迭代確保了每個工件質(zhì)量的持續(xù)的重新評估，這樣，迭代的方式下，經(jīng)?？梢员ＷC提交質(zhì)量更高的產(chǎn)品，也就不奇怪了。團(tuán)隊必須做他們可以做的任何事情，來控制迭代中的活動和工件，建立可追溯性，并簡化溝通。有效的軟件配置管理和變更管理是保證質(zhì)量的一個基本工具；它幫助組織確保軟件在每次構(gòu)建是可重復(fù)的和可靠的，并且保證缺陷和變更請求得到正確的管理。
　　針對此工作流程的工具有IBM Rational Team Unifying Platform，一套完整的基本工具和過程，這個平臺包括 Rational Unified Process、Rational RequisitePro、Rational ClearCase、Rational ClearQuest、Rational ProjectConsole。

五. 質(zhì)量過程改進(jìn)的步驟

　　當(dāng)我們考慮需要什么來構(gòu)建任務(wù)關(guān)鍵和高安全性的系統(tǒng)軟件，并聽說過程質(zhì)量改進(jìn)時，大家往往想到的一個復(fù)雜的過程。其實(shí)，軟件過程質(zhì)量改進(jìn)，如軟件開發(fā)，可以是一個迭代的過程。你不需要一步就完成所有的事情。即使是小的變化，包括調(diào)整你的組織中對質(zhì)量的看法，也會產(chǎn)生一個切實(shí)的改進(jìn)。
　　我們將給大家指出兩條參考的改進(jìn)的線路圖，我們分別稱之為遞進(jìn)式的（或者可以稱之為本質(zhì)的）和演進(jìn)式的（我也稱之為反應(yīng)式的）。遞進(jìn)式的更多考慮工作流程間的依賴性，做到先改善基礎(chǔ)流程，在基于已有的改善基礎(chǔ)，做進(jìn)一步改進(jìn)。而演進(jìn)式的多來自于工作中感知到的問題和瓶頸，依據(jù)問題的表面做反應(yīng)式的改進(jìn)?；诟倪M(jìn)后再發(fā)現(xiàn)新的問題，如此反復(fù)。當(dāng)然，我也在努力發(fā)現(xiàn)一種可以兼顧工作流程間依賴性，有可以快速顯示改進(jìn)效果的改進(jìn)方式。
　　從個人角度看，由于理解有局限，我的建議常常還是反應(yīng)式的。即使在這樣很難考慮到太多前瞻性的工作方式中，我們需要注意：1. 我們是不是了解自己現(xiàn)在的瓶頸，并以此確定方向，并始終堅持自己的方向。2. 我們是不是可以做的更好，我們的改善有更多的預(yù)見性，對問題分析，從表面到本質(zhì)，而不僅僅是反映式的。
　　質(zhì)量保證工作改善我們可以簡單的劃分為以下幾個方面：
　　配置管理和變更管理、靜態(tài)分析和單元測試、集成測試和系統(tǒng)測試、迭代開發(fā)和連續(xù)測試、全過程質(zhì)量、組織級質(zhì)量體系、架構(gòu)分析、需求管理、項目管理。我們將在以后的文章中詳細(xì)描述每種改進(jìn)的內(nèi)容。
遞進(jìn)式的改進(jìn)方式。

{{分頁}}
　
演進(jìn)式的實(shí)施方式。
 
六. 對質(zhì)量保證的幾種理解

　　一下主題，僅是我們所見到和所希望達(dá)到的對軟件質(zhì)量的幾種不同的理解，沒有順序關(guān)系，也不涉及改進(jìn)先后的建議。

6.1. 測試是重要并應(yīng)該智能的

　　在這樣的嵌入式系統(tǒng)開發(fā)團(tuán)隊中，團(tuán)隊成員已經(jīng)認(rèn)識到軟件質(zhì)量的重要性，并努力謀求在軟件質(zhì)量方面的改善，并且積極的尋求適當(dāng)?shù)姆椒?，提高測試的效率和易用性，并且意圖構(gòu)建可以無縫融入原有開發(fā)流程中的測試方法。這些目標(biāo)，也是我們的目標(biāo)。
　　我們也應(yīng)該看到，無論什么樣的方法和工具，目前，都無法改變這樣一個事實(shí)，軟件開發(fā)和測試工作是艱苦的。“易用性”現(xiàn)在常常是個被過度使用的概念?，F(xiàn)在還不存在這樣的工具，他能成為軟件測試的精靈手杖和魔術(shù)子彈。軟件開發(fā)團(tuán)隊不應(yīng)寄希望于只要自己使用了某種軟件測試工具，那么就應(yīng)該可以獲取測試帶來的種種好處。當(dāng)一個工具給大家這樣的印象時，我們只需要回顧軟件質(zhì)量在客戶需求方面的幾個需要考慮的維度上，它滿足的那些？一個按鈕的解決方案是存在的，但我們可以看看這樣的測試工具主要完成了什么類型的測試工作，我們應(yīng)該如何使用他們，應(yīng)該在什么情況下引進(jìn)他們才是最有效果的。采取與所處階段不相符的測試方法，實(shí)際上不但無法達(dá)到提高產(chǎn)品質(zhì)量的目的，而且往往由于實(shí)施的環(huán)境不具備，這些工具本身應(yīng)該具有的功能也無法實(shí)現(xiàn)。這樣的工具，在研發(fā)團(tuán)隊中被束之高閣也就變得在所難免了。
　　在這一過程中，我們建議在于，回顧組織對軟件質(zhì)量的定義；并圍繞這一定義，結(jié)合組織的特點(diǎn)，找到目前工作的著眼點(diǎn)（以文中反應(yīng)式的改進(jìn)路線看，就是發(fā)現(xiàn)工作中的質(zhì)量瓶頸，可參考文中提到的改進(jìn)路線圖）；緊緊圍繞這一著眼點(diǎn)，來指定相關(guān)的流程方法（對流程有疑問，可以致電IBM Rational）；圍繞這一方法，發(fā)現(xiàn)方法實(shí)施中可以通過自動化工具有效提高效率的地方；依此尋求工具支持。而不應(yīng)反而以易用性選工具，以工具定測試需求，以需求來配套方法。

6.2. 系統(tǒng)測試保證產(chǎn)品質(zhì)量

　　在這樣的嵌入式系統(tǒng)開發(fā)團(tuán)隊中，團(tuán)隊成員解決了原來的系統(tǒng)測試可視化程度不高的問題，在原有的測試激勵環(huán)境下，構(gòu)建了相應(yīng)的測試系統(tǒng)，提供可以量化的覆蓋率、性能等指標(biāo)。并且把量化的系統(tǒng)測試當(dāng)成對整個開發(fā)過程健康狀況的評審和反饋，提出以測試促進(jìn)軟件工程的思想，這些是值得我們借鑒的。
　
　　我們也應(yīng)該看到，由于缺乏早期的測試活動，產(chǎn)品的質(zhì)量問題在集成和系統(tǒng)階段被發(fā)現(xiàn)，往往造成修改代價過高，有時對一個早期沒有建立良好架構(gòu)的系統(tǒng),甚至由于害怕的修改引入新的更嚴(yán)重的故障而保留缺陷發(fā)布；由于沒有統(tǒng)一的工具用于單元和系統(tǒng)測試階段，甚至沒有單元測試，使測試工具在系統(tǒng)級需要解決很多和用戶編碼風(fēng)格兼容性問題；同時發(fā)現(xiàn)由于早期未采用迭代化的開發(fā)方式下，而且即便是瀑布式的開發(fā)方式，在早期也沒有注意測試技術(shù)的考慮和驗(yàn)證，知道產(chǎn)品即將交付時，才發(fā)現(xiàn)測試技術(shù)未經(jīng)過實(shí)際的驗(yàn)證，不適應(yīng)系統(tǒng)測試的需求，尋求新的測試方式無疑是為即將到來的發(fā)布雪上加霜；即便有可用的測試方法，由于在系統(tǒng)設(shè)計早期，測試團(tuán)隊沒有介入到系統(tǒng)開發(fā)中去，我們所構(gòu)建的系統(tǒng)不具備可測試的條件；同時，早期設(shè)計時，急于開展編碼，沒有對系統(tǒng)進(jìn)行清晰的需求分析和設(shè)計，只能為測試提供含糊的需求；沒有預(yù)先準(zhǔn)備的測試計劃和測試用例；這樣的系統(tǒng)測試,往往不得已又陷入了只能做“一個按鈕，一本報告”的輕松局面；這種測試，甚至起到的相反的示范效應(yīng)，增強(qiáng)了開發(fā)團(tuán)隊對測試效果的懷疑，同時開發(fā)團(tuán)隊也沒有意識到自己其實(shí)就是質(zhì)量形成的主體。
　　在這一過程中，我們建議在于，加強(qiáng)單元測試，不但可以消除一些可以在單元階段可以消除的問題，而且可以通過在單元和系統(tǒng)階段使用相同的工具，這樣，即使是瀑布式的開發(fā)方式，系統(tǒng)測試技術(shù)也能及早的加以驗(yàn)證，提高可用性；加強(qiáng)系統(tǒng)需求分析和架構(gòu)設(shè)計，是系統(tǒng)架構(gòu)強(qiáng)內(nèi)聚、弱耦合、接口明確，提高系統(tǒng)的可測試性；在系統(tǒng)開發(fā)的早期，測試人員作為系統(tǒng)開發(fā)團(tuán)隊的重要部分，參與系統(tǒng)設(shè)計流程，解決測試相關(guān)問題（有那些問題，RUP中有詳述），為測試對設(shè)計提出要求；加強(qiáng)軟件開發(fā)過程的管理，為測試提供清晰明確的需求和架構(gòu)；

6.3. 分階段測試提高測試效率

　　在這樣的嵌入式系統(tǒng)開發(fā)團(tuán)隊中，建立了在經(jīng)典測試?yán)碚擉w系中包含的靜態(tài)分析，單元測試，集成測試，系統(tǒng)測試的測試工作和相應(yīng)的配套的自動化工具，對各種測試的責(zé)任人有認(rèn)識上的理解和劃分，有一些測試過程中需要的和產(chǎn)生相關(guān)文檔，對測試流程有一些零散的制度和自發(fā)的實(shí)施行為。
　　我們也應(yīng)該看到，在這樣的組織中，常常存在由于不恰當(dāng)?shù)膶卧獪y試的理解，導(dǎo)致為覆蓋率而編寫測試用例的傾向，促使開發(fā)人員認(rèn)為單元測試流于形式，沒有實(shí)際作用；對單元測試的不理解，根據(jù)代碼編寫用例的工作方式，從態(tài)度上滋生的抵觸情緒，認(rèn)為單元測試和單元測試工具是增加工作負(fù)擔(dān)的形式主義；由于在設(shè)計時沒有考慮測試的需要，測試人員也從未介入過設(shè)計工作，軟件的可測試性需求得不到體現(xiàn)，甚至測試人員也認(rèn)為良好的測試就應(yīng)該是對開發(fā)毫無影響的測試；被測試的軟件本身并不具備可測試性，使用多么昂貴的測試工具也很難發(fā)揮作用；對設(shè)計文檔的需求，包括需求文檔到詳細(xì)的軟件規(guī)格說明的需求得不到滿足，開發(fā)人員也往往是更具模糊的、口頭達(dá)成的設(shè)計開始編碼；沒有組織級別的測試體系和度量標(biāo)準(zhǔn)；測試行為和對工具的使用多出自于人為的自覺；工具散落在組織各處，項目間測試經(jīng)驗(yàn)、甚至測試工具使用經(jīng)驗(yàn)都得不到整理和傳承；在組織內(nèi)，沒有人負(fù)責(zé)測試流程和測試工具支持的工作。

{{分頁}}
　　在這一過程中，我們建議在于，建立基于組織的開發(fā)測試體系和輔助工具管理方式，制度化并通過使用工具幫助在組織中貫徹實(shí)施；大家可以參考rational的RUP統(tǒng)一過程的最佳實(shí)踐，和Rational Method Composer定制和部署適合自己的工具；使用各類管理工具，對軟件開發(fā)過程的基礎(chǔ)管理實(shí)現(xiàn)盡可能高的自動化，使用IBM Rational ProjectConsole，將基礎(chǔ)項目數(shù)據(jù)形象的展現(xiàn)管理者；重視軟件測試團(tuán)隊的作用，在系統(tǒng)設(shè)計時，要理解和鼓勵測試人員參與到早期設(shè)計的需要；測試人員積極介入系統(tǒng)的設(shè)計，提高對系統(tǒng)的把握能力，在系統(tǒng)設(shè)計時期，加入系統(tǒng)可測試性的屬性，驗(yàn)證系統(tǒng)測試方法。

6.4. 完善的質(zhì)量保證的活動

　　在這樣的嵌入式系統(tǒng)開發(fā)團(tuán)隊中，作為一個單獨(dú)的活動，建立的獨(dú)立的V&V（驗(yàn)證和確認(rèn)）的流程，通過驗(yàn)證評估各個開發(fā)階段產(chǎn)出的工件的質(zhì)量，包括各種形式的設(shè)計文檔和工件，通過確認(rèn)，評價各個開發(fā)階段于對本階段需求的符合程度，建立的對開發(fā)各個階段完善的評估和反饋體制。
　
　　在這一過程中，我們建議在于，我們鼓勵組織成員，將軟件質(zhì)量不要僅僅限于測試團(tuán)隊或僅僅某些過程，我們要力求引到組織邁向全過程質(zhì)量管理之路；，檢測僅僅是項目質(zhì)量狀態(tài)的審查和反饋的過程；我們可以將視野放在RUP的整個九個工作流程，從中提取我們可以采納的提高質(zhì)量的工作方法，和基于每個角色和每個任務(wù)的檢查方式；加強(qiáng)系統(tǒng)的架構(gòu)設(shè)計，建立高質(zhì)量、易于維護(hù)、易于改進(jìn)的體系架構(gòu)；考慮采用迭代的設(shè)計方法，將強(qiáng)調(diào)早期文檔的驗(yàn)證工作，轉(zhuǎn)向到更強(qiáng)調(diào)對每個迭代結(jié)束以后的可執(zhí)行系統(tǒng)的驗(yàn)證。

6.5. 基于組織的高質(zhì)量的過程

　　在這樣的嵌入式系統(tǒng)開發(fā)團(tuán)隊中，開發(fā)機(jī)構(gòu)建立了完善的開發(fā)流程和各個階段的管理手段。建立了基于軟件開發(fā)全過程檢測，力爭在開發(fā)過程本階段修正錯誤能力。組織對于質(zhì)量的理解，已經(jīng)從減少軟件運(yùn)行錯誤、加強(qiáng)軟件測試、避免軟件缺陷的一般性層面，發(fā)展到對整個軟件開發(fā)生命周期的全過程質(zhì)量管理；這樣組織中的質(zhì)量管理部門，主要負(fù)責(zé)開發(fā)流程的執(zhí)行，并專門負(fù)責(zé)制定產(chǎn)品開發(fā)流程，他針對整個軟件開發(fā)流程，關(guān)心的是怎樣在軟件開發(fā)生命周期中來保證好軟件的質(zhì)量。
　
　　在這一過程中，我們可以相互學(xué)習(xí)，來追逐軟件開發(fā)過程管理的更高目標(biāo)，從在開發(fā)過程中盡早發(fā)現(xiàn)與修正錯誤，進(jìn)展到盡量預(yù)防錯誤的出現(xiàn)。通過對錯誤的分析，完善各階段的檢測手段，做到在本開發(fā)階段發(fā)現(xiàn)及修正錯誤。這是軟件過程改進(jìn)的一項重要內(nèi)容，是開發(fā)機(jī)構(gòu)可以預(yù)期有一個高質(zhì)量的產(chǎn)品及一個低成本、高效率的軟件過程的重要標(biāo)志。

6.6. 迭代開發(fā)持續(xù)測試保證軟件質(zhì)量

　　迭代式軟件開發(fā)，能夠有效控制項目風(fēng)險、增加對項目控制能力、減少需求變更對項目的影響，實(shí)現(xiàn)持續(xù)的質(zhì)量驗(yàn)證，實(shí)現(xiàn)測試技術(shù)的早期驗(yàn)證，提高軟件的可測試性；保證持續(xù)地質(zhì)量保證的實(shí)現(xiàn)。主要說明，所有的開發(fā)活動和工件都需要通過持續(xù)的測試和復(fù)審來檢查質(zhì)量。這意味著測試不僅僅是軟件構(gòu)建之后的一個階段。測試是在整個迭代開發(fā)周期中執(zhí)行的，每次都有一個不同的目標(biāo)，依照RUP這是大家都知道的一個任務(wù)。例如，測試在精化階段，可以集中在確認(rèn)構(gòu)架上，而在構(gòu)建階段中，測試可以集中在查找最重要的軟件缺陷上。

6.7. 質(zhì)量是一種文化

　　在這樣的組織中，我們專注于我們的客戶和客戶的客戶的價值，并以此為產(chǎn)品質(zhì)量的最終衡量標(biāo)準(zhǔn)，了解軟件交付的質(zhì)量，不僅僅是軟件會出多少個故障，這很重要，但不只是這些，更多的要幫助我們的用戶了解最終客戶業(yè)務(wù)的價值。
質(zhì)量改進(jìn)本質(zhì)上是一種思維習(xí)慣問題。

七. 從上至下驅(qū)動質(zhì)量

　　續(xù)保證質(zhì)量要求管理和工作的付出，這些需要從領(lǐng)導(dǎo)高層至下驅(qū)動的，它要求領(lǐng)導(dǎo)和組織復(fù)雜事務(wù)的管理能力。質(zhì)量改進(jìn)本質(zhì)上是一種思維習(xí)慣問題；當(dāng)來自上層的管理人員在整個組織慢慢灌輸質(zhì)量文化時，質(zhì)量就會滲透到每個項目中。
　　在這樣一種文化中，工作會給管理人員提供極大的好處。他們不再必須考慮帶有已知或未知缺陷而發(fā)貨的產(chǎn)品運(yùn)行可能的后果，。并且促使產(chǎn)生質(zhì)量的嚴(yán)格過程、團(tuán)隊責(zé)任心和目標(biāo)矩陣也創(chuàng)建了項目進(jìn)度和質(zhì)量的可預(yù)言性。與那些不斷地重新確定項目范圍，并且仍然錯過期限的團(tuán)隊不同，高質(zhì)量的團(tuán)隊可以精確地確定范圍、估算和確定時間，并且順利地在計劃的經(jīng)費(fèi)和工期內(nèi)交付。這樣的開發(fā)體系，可以有助于你的產(chǎn)品的質(zhì)量水平和產(chǎn)品功能有別于你的競爭對手。

八. 獲得軟件高質(zhì)量的高收益

　　最重要的是，全過程的質(zhì)量保證體系總是會比忽略考慮質(zhì)量成本要低。事實(shí)上，提高產(chǎn)品質(zhì)量基本上沒有成本，如果你正確地做的話。
在國際上，隨著軟件質(zhì)量保證理論及應(yīng)用研究工作的不斷深入，針對軟件質(zhì)量保證工作的工作重點(diǎn)也經(jīng)歷了如下發(fā)展歷程：
　　1. 70年代以前，Ad-hoc testing，與調(diào)試沒有區(qū)分；
　　2. 70年代末到80年代中期，測試基礎(chǔ)理論和實(shí)用技術(shù)形成，軟件測試作為軟件質(zhì)量保證（SQA）的主要手段和職能；
　　3. 80年代末到90年代中期，測試工具在質(zhì)量和數(shù)量上不斷增長，測試與SQA（注重于過程和質(zhì)量監(jiān)督）分離。注重于工具對測試效率的影響；SQA為另一專業(yè)領(lǐng)域。
　　4. 90年后期到目前，重新關(guān)注有效的過程管理對于軟件測試的重要性，將軟件工程視為軟件測試的基礎(chǔ)，或形成各種獨(dú)立的測試模型、測試能力成熟度模型。
　　我們現(xiàn)在哪里呢？
　　高品質(zhì)軟件，需要完整的軟件開發(fā)過程和整合的軟件開發(fā)平臺來共同鑄就。IBM Rational軟件開發(fā)平臺，就是以各種國際標(biāo)準(zhǔn)和開放平臺為基礎(chǔ)，為嵌入式系統(tǒng)軟件產(chǎn)品的開發(fā)和生產(chǎn)過程提供了前所未有的開發(fā)速度和質(zhì)量保證。
　　本文的很多思想都來源于IBM developerWorks Web上的文章，對細(xì)節(jié)有興趣的開發(fā)人員可以在此網(wǎng)站上瀏覽更多相關(guān)文章。IBM也提供了許多服務(wù)，幫助開發(fā)團(tuán)隊交付高質(zhì)量軟件。開發(fā)人員可以參加面對面和基于Web的培訓(xùn)課程，這些課程都通過IBM developerWorks Web門戶，集中在工具使用和技巧改進(jìn)上，并且專業(yè)服務(wù)咨詢可以與開發(fā)團(tuán)隊一起創(chuàng)建定制質(zhì)量實(shí)施計劃，生成初始的項目評估、安裝、指導(dǎo)、培訓(xùn)和維護(hù)。