【正文】 只出現(xiàn)在某種確定的情況下。因?yàn)槟憧赡懿粫?huì)回溯并且再次獨(dú)立的測(cè)試 A 組件，在很久以后的測(cè)試之前你可能不會(huì)發(fā)現(xiàn)有新錯(cuò)誤的跡象，到那時(shí)候你已經(jīng)不清楚 A 是錯(cuò)誤的來(lái)源了。測(cè)試完成之后錯(cuò)誤可能仍然未被發(fā)現(xiàn)。因此，復(fù)查系統(tǒng)測(cè)試中每一步的目的是有幫助的。例如，銀行賬戶包性能測(cè)試評(píng)估包括計(jì)算速度、計(jì)算精度、必要的安全防護(hù)措施以及用戶查詢的響應(yīng)時(shí)間。驗(yàn)收測(cè)試有時(shí)候在實(shí)際環(huán)境中運(yùn)行的結(jié)果和在測(cè)試設(shè)備下運(yùn)行的目標(biāo)是不同的。事實(shí)上，這樣的系統(tǒng)通常是作為候選分期開發(fā)的，僅僅是因?yàn)樗鼈兒苋菀捉⒉⑶以谝粋€(gè)較小的環(huán)境下測(cè)試。在第一章有一個(gè)系統(tǒng)可以被視為一個(gè)不同級(jí)別的嵌套或者一個(gè)子系統(tǒng)。例如，可能設(shè)計(jì)了一個(gè)海軍系統(tǒng)，建造和測(cè)試都是在開發(fā)者條件下，可能被配置為一艘船，但是并不是在真正的船上。我們稱之為已驗(yàn)證的系 統(tǒng)；這是設(shè)計(jì)師在需求說明書中的闡述。最初，我們測(cè)試系統(tǒng)所執(zhí)行的功能。然后，完全的及早的測(cè)試不僅能夠快速的解決問題，也能夠更早的隔離錯(cuò) 誤的來(lái)源。系統(tǒng)擴(kuò)展過程中需要改變系統(tǒng)需求、系統(tǒng)架構(gòu)、程序設(shè)計(jì)以及自我實(shí)現(xiàn)，許多種類的錯(cuò)誤可能作為擴(kuò)展描述被引入、設(shè)計(jì)和編碼。如果我們從別的程序中進(jìn)行代碼重用的時(shí)候這種情況可能會(huì)發(fā)生，我們修改代碼以適應(yīng)我們當(dāng)前的需求。程序員們從最初的與客戶的關(guān)于系統(tǒng)目標(biāo)和功能的討論中在不同層面上移除內(nèi)容。例如，不完美的軟件可以在需要的時(shí)候輸出源自錯(cuò)誤的結(jié)果。為了弄清楚如何實(shí)現(xiàn)這個(gè)目標(biāo)，首先我們必須知道系統(tǒng)中的故障源自哪里。在 W3C 和別處的標(biāo)準(zhǔn)化的努力使基于標(biāo)準(zhǔn)的能夠在所有支持的瀏覽器上工作的 DHTML 成為可能。 有了 DHTML，你可以通過瀏覽器事件來(lái)規(guī)定觸發(fā)動(dòng)作從而使網(wǎng)頁(yè)更加生動(dòng)和具有更強(qiáng)的交互性。that is,that the programmers wrote code to do what the designers system testing,we have a very different objective:to ensure that the system does what the customer wants it to understand how to meet this objective,we first must understand where faults in the system e from. Recall that a software fault causes a failure only when acpanied by the right 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 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 ponent,or in the documentation,at any point during development or illustrates the likely causes of faults in each development 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 example,defective software can result from faults in the 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 customer wants in to work. The same kind of munication mishaps can occur during system may misinterpret a requirement and write an incorrect design we understand the requirement but may word the specification so poorly that those who subsequently read it and use the design misunderstand ,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 are mon when the system design is translated into lowerlevel description for program design are several levels removed from the initial discussions with customers about system goals and responsibility for one “tree” but not the