文檔對象模型和動態(tài)html外文翻譯

1、<p><b>　　河北建筑工程學院</b></p><p>　　畢業(yè)設計（論文）外文資料翻譯</p><p>　　系別： 計算機系 </p><p>　　專業(yè)： 計算機科學與技術(shù) </p><p>　　班級： 計092班

2、 </p><p>　　姓名： 孫全華 </p><p>　　學號： 2009309216 </p><p>　　外文出處： 導師提供 </p><p><b>　　英語原文：</b><

3、;/p><p>　　Document Object Model and Dynamic HTML</p><p>　　The term Dynamic HTML,often abbreviated DHTML,refers to the technique of making Web pages dynamic by client-side scripting to manipulate

4、the document content and presentation.Web pages can be made more lively,dynamic,or interactive by DHTML techniques.</p><p>　　With DHTML,you can prescribe actions triggered by browser events to make the page

5、more lively and responsive.Such actions may alter the content and appearance of any parts of the page.The changes are fast and efficient because they are made by the browser without having to network with any servers.Typ

6、ically,the client-side scripting is written in JavaScript and basic techniques for making Web pages dynamic.</p><p>　　Contrary to what the name may suggest,DHTML is not a markup language or a software tool.I

7、t is a technique to make Web pages dynamic through client-side programming.In the past,DHTML relied on browser-and vendor-specific features.Making such pages work for all browsers requires much effort,testing,and unneces

8、sarily long programs.</p><p>　　Standardization efforts at W3C and elsewhere are making it possible to write standard-based DHTML that works for all compliant browsers.Standard-based DHTML involves three aspe

9、cts.</p><p>　　1.JavaScript—for cross-browser scripting(Chapter9)</p><p>　　2.Cascading Style Sheets(CSS)—for style and presentation control (Chapter6)</p><p>　　3.Document Object Mode

10、l(DOM)—for a uniform programming interface to access and manipulate the Web page as a document</p><p>　　When these three aspects are combined,you get the ability to program changes in Web pages in reaction t

11、o user-or browser-generated events.Therefore,you can make HTML pages more dynamic.</p><p>　　Popular with Web developers,supported by all major browsers,and standardized,JavaScript provides the ability to pro

12、gram browser actions in response to events.To have true cross-platform DHTML,we still need a uniform way for JavaScript to access and manipulate Web documents.This brings us to the DOM.</p><p>　　10.1 What is

13、 DOM?</p><p>　　The objective of unit and integration testing was to ensure that the code implemented the design properly;that is,that the programmers wrote code to do what the designers intended.In system te

14、sting,we have a very different objective:to ensure that the system does what the customer wants it to do.To understand how to meet this objective,we first must understand where faults in the system come from.</p>

15、<p>　　Recall that a software fault causes a failure only when accompanied by the right conditions.That is,a fault may exist in the code,but if the code is never executed,or if the code is not executed long enough or

16、 in the appropriate configuration to cause a problem,we may never see the software fail.Because testing cannot exercise every possible condition,we keep as our goal the discovery of faults,hoping that in the process we e

17、liminate all faults that might lead to failures during actual system us</p><p>　　Software faults can be inserted in a requirement,design,or code component,or in the documentation,at any point during developm

18、ent or maintenance.Figure 9.1 illustrates the likely causes of faults in each development activity.Although we would like to find correct faults as early as possible,system testing acknowledges that faults may still be

19、present after integration testing.</p><p>　　Faults can be introduced to the system early in development or late,such as when correcting a newly discovered fault.For example,defective software can result from

20、 faults in the requirements.Whether a requirement was ambiguous because the customer was unsure of a need or because we misinterpreted the customer’s meaning,the result is the same:a system that does not work the way the

21、 customer wants in to work.</p><p>　　The same kind of communication mishaps can occur during system design.We may misinterpret a requirement and write an incorrect design specification.Or we understand the r

22、equirement but may word the specification so poorly that those who subsequently read it and use the design misunderstand it.Similarly,we may make assumptions about characteristics and relationships that are not shared by

23、 the other readers of the design.</p><p>　　Similar events can lead to program design faults.Misinterpretations are common when the system design is translated into lower-level description for program design

24、specifications.Programmers are several levels removed from the initial discussions with customers about system goals and functionality.Having responsibility for one “tree” but not the “forest,” programmers cannot be expe

25、cted to spot design faults that have been perpetuated through the first steps of the development cycle.For this reas</p><p>　　The programmers and designers on our development team may also fail to use the pr

26、oper syntax and semantics for recording their work.A compiler or assembler can catch some fo these faults before a program is run,but they will not find faults when the form of a statement is correct but does not match t

27、he intention of the programmer or designer.</p><p>　　Once program component testing begins,faults may be added unintentionally in making changes to correct other problems.These faults are often very difficul

28、t to detect,because they may appear only when certain functions are exercised,or only under certain conditions.If those functions have already been tested when a new fault is inadvertently added,the new fault may not be

29、noticed until much later,when its source may not be clear.This situation is likely to happen if we are reusing code from other</p><p>　　For example,suppose you are testing components A,B and C.You test each

30、separately.When you test all three together,you find that A passes a parameter to C incorrectly.In repairing A,you make sure that the parameter pass is now correct,but you add code that sets a pointer incorrectly.Because

31、 you may not go back and test A independently again,you may not find evidence of the new fault until much later in testing,when it is not clear that A is the culprit.</p><p>　　In the same way,maintenance may

32、 introduce new faults.System enhancements require changes to the requirements,the system architecture,the program design,and the implementation itself,so many kinds if faults can be inserted as the enhancement is describ

33、ed,designed,and coded.In addition,the system may not function properly because users do not understand how the system was designed to work.If the documentation is unclear or incorrect,a fault may result.Human factors,inc

34、luding user perception,play a</p><p>　　Test procedures should be through enough to exercise system function to everyone’s satisfaction:user,customer,developer.If the tests are complete,faults may remain unde

35、tected.As we have been,the sooner we detect a fault,the better;faults detected early are easier and cheaper to fix.Then,complete and early testing can helo not only to detect faults quickly,but also to isolate the causes

36、 more early.</p><p>　　shows the reasons for faults,not evidence of them.Because testing aims to uncover as many faults as possible,it is concerned with where they may exist.Knowing how faults are created giv

37、es us clues about where to look when testing a system.</p><p>　　System Testing Process</p><p>　　There are several steps in testing a system:</p><p>　　1.function testing</p>&

38、lt;p>　　2.performance testing</p><p>　　3.acceptance testing</p><p>　　4.installation testing</p><p>　　The steps are illustrated in Figure 9.2.Each step has a different focus,and a

39、step’s success depends on its goal or objective.Thus,it is helpful to review the purpose of each step of system testing.</p><p>　　Process Objective. Initially,we test the functions performed by the system.W

40、e begin with a set of components that were tested individually and then together.A function test checks that the integrated system performs its functions as specified in the requirements.For example,a function test of a

41、bank account package verifies that the package can correctly credit a deposit,enter a withdrawal,calculate interest,print the balance,and so on.</p><p>　　Once the test team is convinced that the functions wo

42、rk as specified,the performance test compares the integrated components with the nonfunctional system requirements.These requirements.including security,accuracy,speed,and reliability,constrain the way in which the syste

43、m functions are performed.For instance,a performance test of the bank account package evaluates the speed with which calculations are made,the precision fo the computation,the security precautions required,and the respon

44、se time</p><p>　　At this point,the system operates the way the designers intend.We call this a verified system;it is the designers’ interpretation of the requirements specification.Next,we compare the system

45、 with the customer’s expectations by reviewing the requirements definition document.If we are satisfied that the system we have built meets the requirements,then we have a validated system;that is,we have verified that t

46、he requirements have been met.</p><p>　　So far,all the tests have been run by the developers,based on their understanding of the system and its objectives.The customers also test the system,making sure that

47、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 them.

48、The acceptance test is sometimes run in its actual environment but often is run at a test facility different from</p><p>　　Build or lnteration Plan. Ideally,after program testing,you can view the collection

49、of components as a single entity.Then,during the first steps of system testing,the integrated collection is evaluated from a variety of perspectives,as previously described.However,large systems are sometimes unwieldy wh

50、en tested as one enormous collection of components.In fact,such systems are often candidates for phased development,simply because they are much easier to build and test in smaller pieces.Thus,you</p><p><

51、;b>　　漢語翻譯：</b></p><p>　　文檔對象模型和動態(tài)HTML</p><p>　　術(shù)語中的動態(tài)HTML，通常簡寫為DHTML,通過客戶端腳本引用制作動態(tài)網(wǎng)頁的技術(shù)來操作文件內(nèi)容和文件描述。網(wǎng)頁可以通過DHTML技術(shù)做得更加生動，動態(tài)和擁有更強的交互性。</p><p>　　有了DHTML，你可以通過瀏覽器事件來規(guī)定觸發(fā)動作從而使網(wǎng)頁

52、更加生動和具有更強的交互性。這些動作可以改變網(wǎng)頁中的任何內(nèi)容和外觀。因為這些改變通過瀏覽器制作而不需要任何的網(wǎng)絡和服務，所以它們是快速而高效的。代表性地，客戶端腳本是在JavaScript中寫的服務于制作動態(tài)網(wǎng)頁的基本技術(shù)。與名稱上可能的啟示相反，DHTML不是一種標識語言或者一種軟件工具。它是一種通過客戶端編程來制作動態(tài)網(wǎng)頁的技術(shù)。在過去，DHTML被瀏覽器和賣主等特殊群體所信賴。為所有瀏覽器的需要而制作這些網(wǎng)頁需要很多的努力、測試及

53、不必要的時間上的浪費。在W3C和別處的標準化的努力使基于標準的能夠在所有支持的瀏覽器上工作的DHTML成為可能。</p><p>　　基于標準的DHTML包括三個方面：</p><p>　　1.Java腳本語言-服務于跨瀏覽器的腳本語言(第九章)</p><p>　　2.級聯(lián)風格表單(CSS)-服務于風格和描述的控制(第六章)</p><p>

54、;　　3.文檔對象模型(DOM)-為了一個統(tǒng)一的編程界面而把網(wǎng)頁作為一個文件去訪問和操作。</p><p>　　當這三個方面都具備了，你就得到了改變網(wǎng)頁在用戶或者瀏覽器生成響應事件的能力。因此，你可以制作更加生動的HTML網(wǎng)頁。</p><p>　　隨著網(wǎng)絡開發(fā)的流行，被所有的專業(yè)瀏覽器和標準所支持，JavaScript提供了編寫瀏覽器響應事件行為的能力。為了擁有真正的DHTML交互平臺，

55、我們?nèi)匀恍枰粋€為JavaScript訪問和操作網(wǎng)絡文件的統(tǒng)一的途徑，這就給我們引入了DOM。</p><p>　　10.1 什么是DOM？</p><p>　　客觀上的單元測試和集成測試是為了確保代碼實施了正確的設計；換言之，也就是說程序員們寫代碼去實現(xiàn)設計者們打算要實現(xiàn)的功能。在系統(tǒng)測試中，有一個非常與眾不同的目標，那就是確保系統(tǒng)能夠按照顧客的意愿去做事。為了弄清楚如何實現(xiàn)這個目標，首

56、先我們必須知道系統(tǒng)中的故障源自哪里。</p><p>　　回想起一個軟件故障，只在伴隨著某一個確定的條件時才會引起一個錯誤。換言之，一個故障可能存在于代碼中，但是如果代碼沒有被執(zhí)行過，或者代碼沒有運行足夠長的時間，或者代碼沒有在能夠引起問題的配置下運行，我們將有可能永遠看不到軟件的錯誤。因為測試不能操作到每一種可能的情況，我們始終保持發(fā)現(xiàn)錯誤的目標，我們希望在過程中消除所有的可能導致系統(tǒng)在實際使用中失敗的因素。&

57、lt;/p><p>　　軟件故障可能產(chǎn)生于一個需求，一個設計，或者代碼組件，或者文檔中，或者開發(fā)或維護的任何一個點中。圖9.1說明了在每一項開發(fā)過程中出現(xiàn)錯誤的可能的原因。盡管我們想要盡可能早的發(fā)現(xiàn)錯誤，系統(tǒng)測試顯示錯誤仍然可能出現(xiàn)在集成測試之后。</p><p>　　錯誤可能在系統(tǒng)早期或發(fā)展中或很晚的時候引入，比如當修改一個新出現(xiàn)的錯誤時。例如，不完美的軟件可以在需要的時候輸出源自錯誤的結(jié)果

58、。用戶是否有要求是模棱兩可的，由于顧客需求的不確定性以及我們對客戶需求的曲解，系統(tǒng)不會按照顧客想要的方式去運行。</p><p>　　同樣種類的交流問題會出現(xiàn)在系統(tǒng)設計中。我們可能曲解顧客的需求并寫一個不正確的規(guī)格設計說明書?；蛘哒f我們清楚顧客的需求，但是可能措辭糟糕而導致在我們之后閱讀需求說明書的人發(fā)生曲解并進而使用了他們的錯誤理解。相似地，我們可能作了關于特征和關系的假設，而這些假設卻不適用于其他讀者。<

59、;/p><p>　　相似的事件可能導致程序設計的錯誤。當“系統(tǒng)設計”為了“程序設計說明”被翻譯成底層語言和描述的時候，曲解是常見的。程序員們從最初的與客戶的關于系統(tǒng)目標和功能的討論中在不同層面上移除內(nèi)容。只見樹木而不見森林，不能指望程序員通過教條的完成程序開發(fā)周期的第一步來使程序沒有設計錯誤。由于以上原因，需求和設計審查是保證系統(tǒng)質(zhì)量的重要因素。</p><p>　　我們團隊中的程序員和設計者

60、們可能也會為了記錄他們的工作在運用合適的語法和語義時產(chǎn)生錯誤。編譯器或匯編程序能夠在程序運行之前捕捉到一些錯誤，但是當一個語句的形式是錯誤的而這種錯誤和編譯器或設計器的關注點不匹配時他們將不能找到錯誤。</p><p>　　一旦程序組件測試開始，錯誤可能在修改其他問題的時候被無意中添加進去。這些錯誤往往很難發(fā)現(xiàn)，因為它們可能只出現(xiàn)在某些功能中或者只出現(xiàn)在某種確定的情況下。如果當一個錯誤無意中添加進去以后這些函數(shù)已

61、經(jīng)被調(diào)試過了，這個新的錯誤可能在它們的源頭未被清理之前不會被注意到。如果我們從別的程序中進行代碼重用的時候這種情況可能會發(fā)生，我們修改代碼以適應我們當前的需求。代碼設計上的細微差別可能不是很明顯，我們的修改可能弊大于利。</p><p>　　例如，假設你正在測試組件A，B和C。你把他們分開測試。當你把它們?nèi)齻€放在一起進行測試時，你發(fā)現(xiàn)A通過一個參數(shù)到達C是不正確的。在修改A的過程中，你確定現(xiàn)在這個參數(shù)是正確的，但

62、是你添加代碼時設置了一個錯誤的指針。因為你可能不會回溯并且再次獨立的測試A組件，在很久以后的測試之前你可能不會發(fā)現(xiàn)有新錯誤的跡象，到那時候你已經(jīng)不清楚A是錯誤的來源了。</p><p>　　同樣的道理，維護過程中也可能引入新的錯誤。系統(tǒng)擴展過程中需要改變系統(tǒng)需求、系統(tǒng)架構(gòu)、程序設計以及自我實現(xiàn)，許多種類的錯誤可能作為擴展描述被引入、設計和編碼。此外，因為用戶不知道系統(tǒng)是被如何設計來工作的，系統(tǒng)可能不能正常運行。如

63、果文檔是不容易理解的或者不正確的，可能導致一個錯誤。人為因素，包括用戶感知，在了解了系統(tǒng)的一個解釋它的消息所需要的輸入中發(fā)揮了很大的作用。讓用戶感覺不習慣的系統(tǒng)可能無法行使系統(tǒng)的正常功能或者發(fā)揮系統(tǒng)的最大優(yōu)勢。</p><p>　　測試過程應該通過足夠次數(shù)的運行系統(tǒng)功能來使每個人滿意，包括用戶，顧客和開發(fā)者。測試完成之后錯誤可能仍然未被發(fā)現(xiàn)。我們越早發(fā)現(xiàn)錯誤效果越好；故障排除越早也就越容易排除而且價格越便宜。然后

64、，完全的及早的測試不僅能夠快速的解決問題，也能夠更早的隔離錯誤的來源。</p><p>　　列出錯誤出現(xiàn)的原因而不是證據(jù)。因為測試的目標在于發(fā)現(xiàn)盡可能多的錯誤，這與錯誤存在于哪里有關。知道了故障如何出現(xiàn)就給了我們在測試系統(tǒng)時關于去哪里查找錯誤的線索。</p><p><b>　　系統(tǒng)測試流程</b></p><p>　　在系統(tǒng)測試中有以下幾個步

65、驟：</p><p><b>　　1.功能測試</b></p><p><b>　　2.性能測試</b></p><p><b>　　3.驗收測試</b></p><p><b>　　4.安裝測試</b></p><p>　　這些步

66、驟在插圖9.2中。每一個步驟的側(cè)重點不同，一個步驟的成功取決于它的目標。因此，復查系統(tǒng)測試中每一步的目的是有幫助的。</p><p>　　過程目標。最初，我們測試系統(tǒng)所執(zhí)行的功能。我們先把一組組件分開測試之后再集合在一起測試。功能測試檢查集成系統(tǒng)的需求所指定的功能。例如，一個銀行賬戶包的功能測試證實這個包能夠正確的信貸存款、輸入提款、計算利息、打印結(jié)余等等。</p><p>　　一旦測試團

67、隊詳細的確定了功能所規(guī)定的工作，性能測試把系統(tǒng)集成組件和非功能性系統(tǒng)需求作比較。這些需求包括安全性、準確性、速度和可靠性，系統(tǒng)功能被執(zhí)行在約束好的路徑下。例如，銀行賬戶包性能測試評估包括計算速度、計算精度、必要的安全防護措施以及用戶查詢的響應時間。</p><p>　　此時此刻，設計師想要的系統(tǒng)操作方式。我們稱之為已驗證的系統(tǒng)；這是設計師在需求說明書中的闡述。接下來，我們通過復查需求定義文檔來把系統(tǒng)和客戶的期望作

68、比較。如果我們認為系統(tǒng)符合需要，然后我們將擁有一個通過驗證的系統(tǒng)；也就是說經(jīng)驗證我們的設計已經(jīng)達到了用戶需求。</p><p>　　迄今為止，開發(fā)者已經(jīng)做了所有的基于他們對系統(tǒng)的認識和系統(tǒng)目標的測試?？蛻粢矔y試系統(tǒng)，確保系統(tǒng)符合他們對需求的理解，而他們的理解可能與開發(fā)人員的理解不同。這個（由客戶完成的）測試稱為驗收測試，保證我們建造的系統(tǒng)是符合客戶要求的。驗收測試有時候在實際環(huán)境中運行的結(jié)果和在測試設備下運行的

69、目標是不同的。由于這個原因，我們可能做一次安裝測試，在這次測試中允許用戶檢測系統(tǒng)功能和附加文檔問題以便于知道在實際過程中遇到的結(jié)果。例如，可能設計了一個海軍系統(tǒng)，建造和測試都是在開發(fā)者條件下，可能被配置為一艘船，但是并不是在真正的船上。一旦開發(fā)環(huán)境下的測試完成了，可能在不同型號的船只上進行一個附加的安裝環(huán)境測試，然后最終使用這個系統(tǒng)。</p><p>　　建造和集成計劃。理念上，經(jīng)過程序測試，你可以作為一個單獨的

70、實體瀏覽組件的集合。然后，在系統(tǒng)測試的第一步中，像先前描述的那樣從各種角度綜合評估。然而，巨型系統(tǒng)在作為一個大的組件的集合的時候是很難處理的。事實上，這樣的系統(tǒng)通常是作為候選分期開發(fā)的，僅僅是因為它們很容易建立并且在一個較小的環(huán)境下測試。因此，你可以選擇完成分期系統(tǒng)測試。在第一章有一個系統(tǒng)可以被視為一個不同級別的嵌套或者一個子系統(tǒng)。每一級至少負責測試它們所包含的子系統(tǒng)的功能。相似地，我們可以把系統(tǒng)分成一系列的子系統(tǒng)并在一個子系</