【正文】 相似地，我們可以把系統(tǒng)分成一系列的子系統(tǒng)并在一個子系 統(tǒng)里執(zhí)行系統(tǒng)測試。在第一章有一個系統(tǒng)可以被視為一個不同級別的嵌套或者一個子系統(tǒng)。事實上，這樣的系統(tǒng)通常是作為候選分期開發(fā)的，僅僅是因為它們很容易建立并且在一個較小的環(huán)境下測試。然后，在系統(tǒng)測試的第一步中，像先前描述的那樣從各種角度綜合評估。 建造和集成計劃。例如，可能設(shè)計了一個海軍系統(tǒng)，建造和測試都是在開發(fā)者條件下，可能被配置為一艘船，但是并不是在真正的船上。驗收測試有時候在實際環(huán)境中運行的結(jié)果和在測試設(shè)備下運行的目標(biāo)是不同的?？蛻粢矔y試系統(tǒng)，確保系統(tǒng)符合他們對需求的理解，而他們的理解可能與開發(fā)人員的理解不同。如果我們認(rèn)為系統(tǒng)符合需要，然后我們將擁有一個通過驗證的系統(tǒng)；也就是說經(jīng)驗證我們的設(shè)計已經(jīng)達(dá)到了用戶需求。我們稱之為已驗證的系 統(tǒng)；這是設(shè)計師在需求說明書中的闡述。例如，銀行賬戶包性能測試評估包括計算速度、計算精度、必要的安全防護(hù)措施以及用戶查詢的響應(yīng)時間。 一旦測試團(tuán)隊詳細(xì)的確定了功能所規(guī)定的工作，性能測試把系統(tǒng)集成組件和非功能性系統(tǒng)需求作比較。功能測試檢查集成系統(tǒng)的需求所指定的功能。最初，我們測試系統(tǒng)所執(zhí)行的功能。因此，復(fù)查系統(tǒng)測試中每一步的目的是有幫助的。 系統(tǒng)測試流程 在系統(tǒng)測試中有以下幾個步驟： 這些步驟在插圖 中。因為測試的目標(biāo)在于發(fā)現(xiàn)盡可能多的錯誤，這與錯誤存在于哪里有關(guān)。然后，完全的及早的測試不僅能夠快速的解決問題，也能夠更早的隔離錯 誤的來源。測試完成之后錯誤可能仍然未被發(fā)現(xiàn)。讓用戶感覺不習(xí)慣的系統(tǒng)可能無法行使系統(tǒng)的正常功能或者發(fā)揮系統(tǒng)的最大優(yōu)勢。如果文檔是不容易理解的或者不正確的，可能導(dǎo)致一個錯誤。系統(tǒng)擴(kuò)展過程中需要改變系統(tǒng)需求、系統(tǒng)架構(gòu)、程序設(shè)計以及自我實現(xiàn)，許多種類的錯誤可能作為擴(kuò)展描述被引入、設(shè)計和編碼。因為你可能不會回溯并且再次獨立的測試 A 組件，在很久以后的測試之前你可能不會發(fā)現(xiàn)有新錯誤的跡象，到那時候你已經(jīng)不清楚 A 是錯誤的來源了。當(dāng)你把它們?nèi)齻€放在一起進(jìn)行測試時，你發(fā)現(xiàn) A 通過一個參數(shù)到達(dá) C 是不正確的。 例如，假設(shè)你正在測 試組件 A， B 和 C。如果我們從別的程序中進(jìn)行代碼重用的時候這種情況可能會發(fā)生，我們修改代碼以適應(yīng)我們當(dāng)前的需求。這些錯誤往往很難發(fā)現(xiàn)，因為它們可能只出現(xiàn)在某些功能中或者只出現(xiàn)在某種確定的情況下。編譯器或匯編程序能夠在程序運行之前捕捉到一些錯誤，但是當(dāng)一個語句的形式是錯誤的 而這種錯誤和編譯器或設(shè)計器的關(guān)注點不匹配時他們將不能找到錯誤。由于以上原因，需求和設(shè)計審查是保證系統(tǒng)質(zhì)量的重要因素。程序員們從最初的與客戶的關(guān)于系統(tǒng)目標(biāo)和功能的討論中在不同層面上移除內(nèi)容。 相似的事件可能導(dǎo)致程序設(shè)計的錯誤。或者說我們清楚顧客的需求，但是可能措辭糟糕而導(dǎo)致在我們之后閱讀需求說明書的人發(fā)生曲解并進(jìn)而使用了他們的錯誤理解。 同樣種類的交流問題會出現(xiàn)在系統(tǒng)設(shè)計中。例如，不完美的軟件可以在需要的時候輸出源自錯誤的結(jié)果。盡管我們想要盡可能早的發(fā)現(xiàn)錯誤，系統(tǒng)測試顯示錯誤仍然可能出現(xiàn)在集成測試之后。 軟件故障可能產(chǎn)生于一 個需求，一個設(shè)計，或者代碼組件，或者文檔中，或者開發(fā)或維護(hù)的任何一個點中。換言之，一個故障可能存在于代碼中，但是如果代碼沒有被執(zhí)行過，或者代碼沒有運行足夠長的時間，或者代碼沒有在能夠引起問題的配置下運行，我們將有可能永遠(yuǎn)看不到軟件的錯誤。為了弄清楚如何實現(xiàn)這個目標(biāo)，首先我們必須知道系統(tǒng)中的故障源自哪里。 什么是 DOM？ 客觀上的單元測試和集成測試是為了確保代碼實施了正確的設(shè)計；換言之，也就是說程序員們寫代碼去實現(xiàn)設(shè)計者們打算要實現(xiàn)的功能。 隨著網(wǎng)絡(luò)開發(fā)的流行，被所有的專業(yè)瀏覽器和標(biāo)準(zhǔn)所支持， JavaScript 提供了編寫瀏覽器響應(yīng)事件行為的能力。 當(dāng)這三個方面都具備了，你就得到了改變網(wǎng)頁在用 戶或者瀏覽器生成響應(yīng)事件的能力。在 W3C 和別處的標(biāo)準(zhǔn)化的努力使基于標(biāo)準(zhǔn)的能夠在所有支持的瀏覽器上工作的 DHTML 成為可能。在過去， DHTML 被瀏覽 器和賣主等特殊群體所信賴。與名稱上可能的啟示相反， DHTML 不是一種標(biāo)識語言或者一種軟件工具。因為這些改變通過瀏覽器制作而不需要任何的網(wǎng)絡(luò)和服務(wù)，所以它們是快速而高效的。 有了 DHTML，你可以通過瀏覽器事件來規(guī)定觸發(fā)動作從而使網(wǎng)頁更加生動和具有更強(qiáng)的交互性。that is,we have verified that the requirements have been met. So far,all the tests have been run by the developers,based on their understanding of the system and its customers also test the system,making sure that it meets their understanding of the requirements,which may be different from the developers’.This test,called an acceptance test,assures the customers that the system they requested is the system that was built for acceptance test is sometimes run in its actual environment but often is run at a test facility different from the target this reason,we may run a final installation test to allow users to exercise system functions and document additional problems that result from being at the actual example,a naval system may be designed,built,and tested at the developer’s site,configured as a ship might be,but not on an actual the development site tests are plete,an additional set of installation te