文档对象模型和动态HTML外文翻译.doc

河北建筑工程学院毕业设计（论文）外文资料翻译 系别： 计算机系 专业： 计算机科学与技术 班级： 计092班 姓名： 孙全华 学号： 2009309216 外文出处： 导师提供 指导教师评语：签字： 年 月 日英语原文： Document Object Model and Dynamic HTMLThe term Dynamic HTML,often abbreviated DHTML,refers to the technique of making Web pages dynamic by client-side scripting to manipulate the document content and presentation.Web pages can be made more lively,dynamic,or interactive by DHTML techniques.With DHTML,you can prescribe actions triggered by browser events to make the page 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.Typically,the client-side scripting is written in JavaScript and basic techniques for making Web pages dynamic.Contrary to what the name may suggest,DHTML is not a markup language or a software tool.It 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 unnecessarily long programs.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 aspects.1.JavaScriptfor cross-browser scripting(Chapter9) 2.Cascading Style Sheets(CSS)for style and presentation control (Chapter6) 3.Document Object Model(DOM)for a uniform programming interface to access and manipulate the Web page as a document When these three aspects are combined,you get the ability to program changes in Web pages in reaction to user-or browser-generated events.Therefore,you can make HTML pages more dynamic. Popular with Web developers,supported by all major browsers,and standardized,JavaScript provides the ability to program 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.10.1 What is DOM?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 testing,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.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 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 eliminate all faults that might lead to failures during actual system usage. Software faults can be inserted in a requirement,design,or code component,or in the documentation,at any point during development 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 present after integration testing. 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 faults in the requirements.Whether a requirement was ambiguous because the customer was unsure of a need or because we misinterpreted the customers meaning,the result is the same:a system that does not work the way the customer wants in to work. 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 requirement 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 the other readers of the design. Similar events can lead to program design faults.Misinterpretations are common when the system design is translated into lower-level description for program design 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 expected to spot design faults that have been perpetuated through the first steps of the development cycle.For this reason,requirements and design reviews are essential to ensuring the quality of the resulting system. The programmers and designers on our development team may also fail to use the proper 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 the intention of the programmer or designer. Once program component testing begins,faults may be added unintentionally in making changes to correct other problems.These faults are often very difficult 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 noticed until much later,when its source may not be clear.This situation is likely to happen if we are reusing code from other applications,and we modify it to suit our current needs.The nuances of the codes design may not be apparent,and our changes may in fact do more damage than good.For example,suppose you are testing components A,B and C.You test each 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 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.In the same way,maintenance may 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 described,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,including user perception,play a large role in understanding the system an interpreting its messages and required input.User who are not comfortable with the system may not exercise system functions properly or to greatest advantage.Test procedures should be through enough to exercise system function to everyones satisfaction:user,customer,developer.If the tests are complete,faults may remain undetected.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 more early.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 gives us clues about where to look when testing a system.System Testing ProcessThere are several steps in testing a system:1.function testing2.performance testing3.acceptance testing4.installation testingThe steps are illustrated in Figure 9.2.Each step has a different focus,and a steps success depends on its goal or objective.Thus,it is helpful to review the purpose of each step of system testing.Process Objective. Initially,we test the functions performed by the system.We 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 bank account package verifies that the package can correctly credit a deposit,enter a withdrawal,calculate interest,print the balance,and so on.Once the test team is convinced that the functions work 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 system 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 response time to user inquiry.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 with the customers 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 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 objectives.The 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 them.The acceptance test is sometimes run in its actual environment but often is run at a test facility different from the target location.For 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 site.For example,a naval system may be designed,built,and tested at the developers site,configured as a ship might be,but not on an actual ship.Once the development site tests are complete,an additional set of installation tests may be run with the system on board each type of ship that will eventually use the system.Build or lnteration Plan. Ideally,after program testing,you can view the collection 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 when 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 may choose to perform phased system testing.We saw in Chapter 1 that a system can be viewed as a nested set of levels or subsystems.Each level is responsible for performing at least the functions of those subsystems it contains.Similarly,we can divide the system into a nested sequence of subsystems and perform the system test on one subsystem at a time.汉语翻译：文档对象模型和动态HTML 术语中的动态HTML，通常简写为DHTML,通过客户端脚本引用制作动态网页的技术来操作文件内容和文件描述。网页可以通过DHTML技术做得更加生动，动态和拥有更强的交互性。有了DHTML，你可以通过浏览器事件来规定触发动作从而使网页更加生动和具有更强的交互性。这些动作可以改变网页中的任何内容和外观。因为这些改变通过浏览器制作而不需要任何的网络和服务，所以它们是快速而高效的。代表性地，客户端脚本是在JavaScript中写的服务于制作动态网页的基本技术。与名称上可能的启示相反，DHTML不是一种标识语言或者一种软件工具。它是一种通过客户端编程来制作动态网页的技术。在过去，DHTML被浏览器和卖主等特殊群体所信赖。为所有浏览器的需要而制作这些网页需要很多的努力、测试及不必要的时间上的浪费。在W3C和别处的标准化的努力使基于标准的能够在所有支持的浏览器上工作的DHTML成为可能。基于标准的DHTML包括三个方面： 1.Java脚本语言-服务于跨浏览器的脚本语言(第九章) 2.级联风格表单(CSS)-服务于风格和描述的控制(第六章) 3.文档对象模型(DOM)-为了一个统一的编程界面而把网页作为一个文件去访问和操作。 当这三个方面都具备了，你就得到了改变网页在用户或者浏览器生成响应事件的能力。因此，你可以制作更加生动的HTML网页。 随着网络开发的流行，被所有的专业浏览器和标准所支持，JavaScript提供了编写浏览器响应事件行为的能力。为了拥有真正的DHTML交互平台，我们仍然需要一个为JavaScript访问和操作网络文件的统一的途径，这就给我们引入了DOM。 10.1 什么是DOM？ 客观上的单元测试和集成测试是为了确保代码实施了正确的设计；换言之，也就是说程序员们写代码去实现设计者们打算要实现的功能。在系统测试中，有一个非常与众不同的目标，那就是确保系统能够按照顾客的意愿去做事。为了弄清楚如何实现这个目标，首先我们必须知道系统中的故障源自哪里。 回想起一个软件故障，只在伴随着某一个确定的条件时才会引起一个错误。换言之，一个故障可能存在于代码中，但是如果代码没有被执行过，或者代码没有运行足够长的时间，或者代码没有在能够引起问题的配置下运行，我们将有可能永远看不到软件的错误。因为测试不能操作到每一种可能的情况，我们始终保持发现错误的目标，我们希望在过程中消除所有的可能导致系统在实际使用中失败的因素。 软件故障可能产生于一个需求，一个设计，或者代码组件，或者文档中，或者开发或维护的任何一个点中。图9.1说明了在每一项开发过程中出现错误的可能的原因。尽管我们想要尽可能早的发现错误，系统测试显示错误仍然可能出现在集成测试之后。 错误可能在系统早期或发展中或很晚的时候引入，比如当修改一个新出现的错误时。例如，不完美的软件可以在需要的时候输出源自错误的结果。用户是否有要求是模棱两可的，由于顾客需求的不确定性以及我们对客户需求的曲解，系统不会按照顾客想要的方式去运行。 同样种类的交流问题会出现在系统设计中。我们可能曲解顾客的需求并写一个不正确的规格设计说明书。或者说我们清楚顾客的需求，但是可能措辞糟糕而导致在我们之后阅读需求说明书的人发生曲解并进而使用了他们的错误理解。相似地，我们可能作了关于特征和关系的假设，而这些假设却不适用于其他读者。 相似的事件可能导致程序设计的错误。当“系统设计”为了“程序设计说明”被翻译成底层语言和描述的时候，曲解是常见的。程序员们从最初的与客户的关于系统目标和功能的讨论中在不同层面上移除内容。只见树木而不见森林，不能指望程序员通过教条的完成程序开发周期的第一步来使程序没有设计错误。由于以上原因，需求和设计审查是保证系统质量的重要因素。 我们团队中的程序员和设计者们可能也会为了记录他们的工作在运用合适的语法和语义时产生错误。编译器或汇编程序能够在程序运行之前捕捉到一些错误，但是当一个语句的形式是错误的而这种错误和编译器或设计器的关注点不匹配时他们将不能找到错误。 一旦程序组件测试开始，错误可能在修改其他问题的时候被无意中添加进去。这些错误往往很难发现，因为它们可能只出现在某些功能中或者只出现在某种确定的情况下。如果当一个错误无意中添加进去以后这些函数已经被调试过了，这个新的错误可能在它们的源头未被清理之前不会被注意到。如果我们从别的程序中进行代码重用的时候这种情况可能会发生，我们修改代码以适应我们当前的需求。代码设计上的细微差别可能不是很明显，我们的修改可能弊大于利。 例如，假设你正在测试组件A，B和C。你把他们分开测试。当你把它们三个放在一起进行测试时，你发现A通过一个参数到达C是不正确的。在修改A的过程中，你确定现在这个参数是正确的，但是你添加代码时设置了一个错误的指针。因为你可能不会回溯并且再次独立的测试A组件，在很久以后的测试之前你可能不会发现有新错误的迹象，到那时候你已经不清楚A是错误的来源了。 同样