文檔對象模型和動態(tài)html外文翻譯-預(yù)覽頁
【正文】 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 ponent testing begins,faults may be added unintentionally in making changes to correct other faults are often very difficult to detect,because they may appear only when certain functions are exercised,or only under certain 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 situation is likely to happen if we are reusing code from other applications,and we modify it to suit our current nuances of the code’s design may not be apparent,and our changes may in fact do more damage than good. For example,suppose you are testing ponents A,B and test each you test all three together,you find that A passes a parameter to C repairing A,you make sure that the parameter pass is now correct,but you add code that sets a pointer 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 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 addition,the system may not function properly because users do not understand how the system was designed to the documentation is unclear or incorrect,a fault may factors,including user perception,play a large role in understanding the system an interpreting its messages and required who are not fortable with the system may not exercise system functions properly or to greatest advantage. Test procedures should be through enough to exercise system function to everyone’s satisfaction:user,customer, the tests are plete,faults may remain we have been,the sooner we detect a fault,the better。網(wǎng)頁可以通過 DHTML 技術(shù)做得更加生動，動態(tài)和擁有更強(qiáng)的交互性。代表性地，客戶端腳本是在 JavaScript 中寫的服務(wù)于制作動態(tài)網(wǎng)頁的基本技術(shù)。為所有瀏覽器的需要而制作這些網(wǎng)頁需要很多的努力、測試及 不必要的時(shí)間上的浪費(fèi)。因此，你可以制作更加生動的 HTML 網(wǎng)頁。在系統(tǒng)測試中，有一個(gè)非常與眾不 同的目標(biāo)，那就是確保系統(tǒng)能夠按照顧客的意愿去做事。因?yàn)闇y試不能操作到每一種可能的情況，我們始終保持發(fā)現(xiàn)錯誤的目標(biāo)，我們希望在過程中消除所有的可能導(dǎo)致系統(tǒng)在實(shí)際使用中失敗的因素。 錯誤可能在系統(tǒng)早期或發(fā)展中或很晚的時(shí)候引入，比如當(dāng)修改一個(gè)新出現(xiàn)的錯誤時(shí)。我們可能曲解 顧客的需求并寫一個(gè)不正確的規(guī)格設(shè)計(jì)說明書。當(dāng)“系統(tǒng)設(shè)計(jì)”為了“程序設(shè)計(jì)說明”被翻譯成底層語言和描述的時(shí)候，曲解是常見的。 我們團(tuán)隊(duì)中的程序員和設(shè)計(jì)者們可能也會為了記錄他們的工作在運(yùn)用合適的語法和語義時(shí)產(chǎn)生錯誤。如果當(dāng)一個(gè)錯誤無意中添加進(jìn)去以后這些函數(shù)已經(jīng)被調(diào)試過了，這個(gè)新的錯誤可能在它們的源頭未被清理之前不會被注意到。你把他們分開測試。 同樣的道理，維護(hù)過程中也可能引入新的錯誤。人為因素，包括用戶感知，在了解了系統(tǒng)的一個(gè)解釋它的消息所需要的輸入中發(fā)揮了很大的作用。我們越早發(fā)現(xiàn)錯誤效果越好；故障排除越早也就越容易排除而且價(jià)格越便宜。知道了故障如何出現(xiàn)就給了我們在測試系統(tǒng)時(shí)關(guān)于去哪里查找錯誤的線索。 過程目標(biāo)。例如，一個(gè)銀行賬戶包的功能測試證實(shí)這個(gè)包能夠正確的信貸存款、輸入提款、計(jì)算利息、打印結(jié)余等等。 此時(shí)此刻，設(shè)計(jì)師想要的系統(tǒng)操作方式。 迄今為止，開發(fā)者已經(jīng)做了所有的基于他們對系統(tǒng)的認(rèn)識和系統(tǒng)目標(biāo)的測試。由于 這個(gè)原因，我們可能做一次安裝測試，在這次測試中允許用戶檢測系統(tǒng)功能和附加文檔問題以便于知道在實(shí)際過程中遇到的結(jié)果。理念上，經(jīng)過程序測試，你可以作為一個(gè)單獨(dú)的實(shí)體瀏覽組件的集合。因此，你可以選擇完成分期系統(tǒng)測試。
畢業(yè)設(shè)計(jì)相關(guān)推薦
鄂ICP備17016276號-1