測試問答總結(jié)

1.、為什么要在一個(gè)團(tuán)隊(duì)中開展軟件測試工作？因?yàn)闆]有經(jīng)過測試的軟件很難在發(fā)布之前知道該軟件的質(zhì)量，就好比ISO質(zhì)量認(rèn)證一樣，測試同樣也需要質(zhì)量的保證，這個(gè)時(shí)候就需要在團(tuán)隊(duì)中開展軟件測試的工作。在測試的過程發(fā)現(xiàn)軟件中存在的問題，及時(shí)讓開發(fā)人員得知并修改問題，在即將發(fā)布時(shí)，從測試報(bào)告中得出軟件的質(zhì)量情況。2.、測試能給你帶來什么樣的快樂？

測試可以給我?guī)砗芏嗫鞓?如果測試出一個(gè)項(xiàng)目缺少東西,我會很高興,因?yàn)槲覍ψ约旱墓ぷ饔辛诵碌恼J(rèn)識,也為公司做了效益;如果測試出一個(gè)項(xiàng)目沒有問題,我也很高興,因?yàn)橥聜兌荚谂?大家都希望為公司做貢獻(xiàn),這就是一個(gè)很強(qiáng)大的團(tuán)隊(duì)，這是一件多么另人振奮的事情啊!27、文檔測試要注意什么？文檔的讀者群、文檔的術(shù)語、文檔的正確性、文檔的完整性、文檔的一致性、文檔的易用性、樣例與示例、文檔的語言3.、軟件測試的目的？

測試的目的是以最少人力、物力和時(shí)間找出軟件中潛在各種錯(cuò)誤和缺陷，通過修正各種錯(cuò)誤和缺陷提高軟件質(zhì)量，回避軟件發(fā)布后由于潛在的軟件缺陷和錯(cuò)誤造成的隱患帶來的商業(yè)風(fēng)險(xiǎn)。4.、Alpha測試與beta測試的區(qū)別Alpha測試在系統(tǒng)開發(fā)接近完成時(shí)對應(yīng)用系統(tǒng)的測試；測試后仍然會有少量的設(shè)計(jì)變更。這種測試一般由程序或測試員完成，不能由最終用戶或其它人員完成。Beta測試當(dāng)開發(fā)和測試根本完成時(shí)所做的測試，最終的錯(cuò)誤和問題需要在最終發(fā)行前找到。這種測試一般由最終用戶或其它人員完成，不能由程序員或測試員完成。5.、簡述集成測試的過程1.構(gòu)建的確認(rèn)過程。2.補(bǔ)丁的確認(rèn)過程。3.系統(tǒng)集成測試測試組提交過程。4.測試用例設(shè)計(jì)過程。5.測試代碼編寫過程。6.Bug的報(bào)告過程。7.每周/每兩周的構(gòu)建過程。8.點(diǎn)對點(diǎn)的測試過程。9.組內(nèi)培訓(xùn)過程。集成測試過程:集成測試計(jì)劃->集成測試設(shè)計(jì)->集成測試實(shí)現(xiàn)->集成測試執(zhí)行。6.、質(zhì)量的八大特性是什么？各種特性的定義？1）功能性：軟件所實(shí)現(xiàn)的功能達(dá)到它的設(shè)計(jì)規(guī)范和滿足用戶需求的程度2）性能：在規(guī)定條件下,實(shí)現(xiàn)軟件功能所需的響應(yīng)時(shí)間和計(jì)算機(jī)資源(CPU、內(nèi)存、磁盤空間和數(shù)據(jù)吞吐量)的使用程度3）可靠性：在滿足一定條件的應(yīng)用環(huán)境中，軟件能夠正常維持其工作的能力，在出現(xiàn)一些錯(cuò)誤操作時(shí)，軟件可以具有容錯(cuò)性，如果軟件意外退出，重新啟動后可以恢復(fù)最近的軟件數(shù)據(jù)4）安全性：為了防止意外或人為的破壞，軟件應(yīng)具備的自身保護(hù)能力5）使用性：用戶在理解、學(xué)習(xí)和操作軟件的過程中的付出的努力的難易程度6）維護(hù)性：軟件在運(yùn)行維護(hù)過程中，如果出現(xiàn)了運(yùn)行故障或者擴(kuò)展新功能和性能，軟件系統(tǒng)是否具有可分析性和良好的擴(kuò)展性，重新設(shè)計(jì)后的軟件的穩(wěn)定性和可測試性7）移植性：軟件從現(xiàn)有運(yùn)行平臺向另一個(gè)運(yùn)行平臺過度的適應(yīng)程度和平臺可替換性8）重用性：整個(gè)軟件或其中一部分能作為軟件包而被再利用的程度7.、系統(tǒng)測試計(jì)劃是否需要同行審批，為什么需要，系統(tǒng)測試計(jì)劃屬于項(xiàng)目階段性關(guān)鍵文檔，因此需要評審。8.、軟件質(zhì)量應(yīng)該從哪些方面來評價(jià)？可靠性、安全性、性能、易用性、外觀、穩(wěn)定性9.、系統(tǒng)測試包含哪些方面？1.恢復(fù)測試、2.安全測試、3.強(qiáng)度測試、4.性能測試10.、區(qū)別階段評審的與同行評審?fù)性u審目的:發(fā)現(xiàn)小規(guī)模工作產(chǎn)品的錯(cuò)誤,主要是找錯(cuò)誤;階段評審目的:評審模塊階段作品的正確性可行性及完整性同行評審人數(shù):3-7人人員必須經(jīng)過同行評審會議的培訓(xùn),由SQA指導(dǎo)階段評審人數(shù):5人左右評審人必須是專家具有系統(tǒng)評審資格同行評審內(nèi)容:內(nèi)容小一般文檔<

40頁,代碼<500行階段評審內(nèi)容:內(nèi)容多,主要看重點(diǎn)同行評審時(shí)間:一小部分工作產(chǎn)品完成階段評審時(shí)間:通常是設(shè)置在關(guān)鍵路徑的時(shí)間點(diǎn)上!11.、測試結(jié)束的標(biāo)準(zhǔn)是什么？1.用例全部執(zhí)行。2.覆蓋率達(dá)到標(biāo)準(zhǔn)。3.缺陷率達(dá)到標(biāo)準(zhǔn)。4.其他指標(biāo)達(dá)到質(zhì)量標(biāo)準(zhǔn)12.、制定測試計(jì)劃之前需要了解什么問題？1.軟件測試計(jì)劃的目的是什么？是否所有人都知道？他們同意這個(gè)測試計(jì)劃過程嗎？2.測試的是什么產(chǎn)品？是新程序還是維護(hù)升級的？是獨(dú)立程序還是由多個(gè)小程序組成的？3.產(chǎn)品的質(zhì)量目標(biāo)是什么？產(chǎn)品的功能需求和性能指標(biāo)必須得到所有人的一致認(rèn)可。13.、請?jiān)斒鲈O(shè)計(jì)測試用例的方法？（只是列出一個(gè)測試用例思考的方向，具體設(shè)計(jì)靠經(jīng)驗(yàn)）①黑盒測試用例根據(jù)業(yè)務(wù)需求說明書來設(shè)計(jì)，分為：等價(jià)劃分法邊界值分析法錯(cuò)誤推測法因果圖法邏輯覆蓋法②白盒測試用例通過研究代碼與程序結(jié)構(gòu)可以分為以下兩種方式：靜態(tài)測試：通過靜態(tài)的檢查程序代碼、界面、文檔中可能存在的錯(cuò)誤的過程。|-測試代碼編寫的規(guī)范性|-測試界面|-測試相關(guān)需求說明和用戶手冊是否符合實(shí)際要求動態(tài)測試：通過路徑和分支測試。測試用例主要根據(jù)以下六種覆蓋測試方法設(shè)計(jì)|-語句覆蓋|-判定覆蓋|-條件覆蓋|-判定/條件覆蓋|-組合覆蓋|-路徑覆蓋14.、比較負(fù)載測試，壓力測試，容量測試和強(qiáng)度測試的區(qū)別負(fù)載測試：在一定的工作負(fù)荷下，系統(tǒng)的負(fù)荷及響應(yīng)時(shí)間。通過逐步增加系統(tǒng)負(fù)載，最終確定在滿足性能指標(biāo)的情況下，系統(tǒng)能承受的最大負(fù)載量的測試。強(qiáng)度測試：又稱疲勞強(qiáng)度測試，在系統(tǒng)穩(wěn)定運(yùn)行的情況下能夠支持的最大并發(fā)用戶數(shù)，持續(xù)執(zhí)行一段時(shí)間業(yè)務(wù)，通過綜合分析，確定系統(tǒng)處理最大工作量強(qiáng)度性能的過程。一定負(fù)荷條件下，在較長時(shí)間跨度內(nèi)的系統(tǒng)連續(xù)運(yùn)行給系統(tǒng)性能所造成的影響。容量測試：容量測試目的是通過測試預(yù)先分析出反映軟件系統(tǒng)應(yīng)用特征的某項(xiàng)指標(biāo)的極限值（如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)等），系統(tǒng)在其極限值狀態(tài)下沒有出現(xiàn)任何軟件故障或還能保持主要功能正常運(yùn)行。容量測試還將確定測試對象在給定時(shí)間內(nèi)能夠持續(xù)處理的最大負(fù)載或工作量。容量測試的目的是使系統(tǒng)承受超額的數(shù)據(jù)容量來發(fā)現(xiàn)它是否能夠正確處理。容量測試是面向數(shù)據(jù)的，并且目的是顯示系統(tǒng)可以處理目標(biāo)內(nèi)確定的數(shù)據(jù)容量。壓力測試：通過逐步增加系統(tǒng)負(fù)載，最終確定在什么負(fù)載條件下系統(tǒng)性能將處于崩潰狀態(tài)，以此獲得系統(tǒng)能提供的最大服務(wù)級別的測試。15.、測試人員需要何時(shí)參加需求分析？如果條件允許，原則上來說是越早介入需求分析越好。因?yàn)闇y試人員對需求理解越深刻，對測試工作的開展越有利，可以盡早的確定測試思路，減少與開發(fā)人員的交互，減少對需求理解上的偏差。16.、軟件的缺陷等級應(yīng)如何劃分？嚴(yán)重：1.由于程序所引起的死機(jī),非法退出2.死循環(huán)3.數(shù)據(jù)庫發(fā)生死鎖4.因錯(cuò)誤操作導(dǎo)致的程序中斷5.功能錯(cuò)誤6.與數(shù)據(jù)庫連接錯(cuò)誤7.數(shù)據(jù)通訊錯(cuò)誤。較嚴(yán)重：1.程序錯(cuò)誤2.程序接口錯(cuò)誤3.數(shù)據(jù)庫的表、業(yè)務(wù)規(guī)則、缺省值未加完整性等約束條件。一般性：1.操作界面錯(cuò)誤（包括數(shù)據(jù)窗口內(nèi)列名定義、含義是否一致）2.打印內(nèi)容、格式錯(cuò)誤3.簡單的輸入限制未放在前臺進(jìn)行控制4.刪除操作未給出提示5.數(shù)據(jù)庫表中有過多的空字段。建議：1.界面不規(guī)范2.輔助說明描述不清楚3.輸入輸出不規(guī)范4.長操作未給用戶提示5.提示窗口文字未采用行業(yè)術(shù)語6.可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標(biāo)志。17.、你自認(rèn)為測試的優(yōu)勢在哪里？優(yōu)勢在于我對測試堅(jiān)定不移的信心和熱情，雖然經(jīng)驗(yàn)還不夠，但測試需要的基本技能我有信心在工作中得以發(fā)揮。18.、你在測試中發(fā)現(xiàn)了一個(gè)bug，但是開發(fā)經(jīng)理認(rèn)為這不是一個(gè)bug，你應(yīng)該怎樣解決。1.如果不是錯(cuò)誤則應(yīng)該主動承認(rèn)不是缺陷。2.如果是需求不明確的則應(yīng)和開發(fā)加強(qiáng)溝通補(bǔ)充需求。3.如果和開發(fā)爭論不休應(yīng)該邀請上級判斷。19.、您認(rèn)為做好測試計(jì)劃工作的關(guān)鍵是什么？

1.明確測試的目標(biāo)，增強(qiáng)測試計(jì)劃的實(shí)用性2．堅(jiān)持“5W”規(guī)則，明確內(nèi)容與過程3．采用評審和更新機(jī)制，保證測試計(jì)劃滿足實(shí)際需求

4.分別創(chuàng)建測試計(jì)劃與測試詳細(xì)規(guī)格、測試用例20.、風(fēng)險(xiǎn)和問題◆市場的壓力◆測試時(shí)間不夠◆測試資源的及時(shí)到位◆測試人員的技能需求◆開發(fā)進(jìn)度的變化，需求的變更◆開發(fā)部門的版本控制◆短時(shí)間上線。這個(gè)是已經(jīng)定好的，沒有參考測試人員的意見。時(shí)間短往往不能得到充分的測試，測試策略必須根據(jù)可用的時(shí)間進(jìn)行調(diào)整。盡快指出這樣的問題非常重要，只有這樣才能調(diào)整時(shí)間表，確定快速開發(fā)的風(fēng)險(xiǎn)并制定降低風(fēng)險(xiǎn)的策略?！粜碌脑O(shè)計(jì)過程。引入新的設(shè)計(jì)過程會增加風(fēng)險(xiǎn)，新的設(shè)計(jì)過程包括新的工具和設(shè)計(jì)技術(shù)。如果采用新的技術(shù)，能否像我們預(yù)期的那樣運(yùn)轉(zhuǎn)，都存在很大的風(fēng)險(xiǎn)◆復(fù)雜性。我們應(yīng)該進(jìn)行一些分析工作來確定哪個(gè)功能最復(fù)雜，哪個(gè)功能最容易出錯(cuò)，錯(cuò)誤會對系統(tǒng)的哪些地方造成重大的影響?！羰褂妙l率。軟件最常用功能中隱藏的問題可能給用戶造成嚴(yán)重的損失。◆不可測試的需求。不可測試的需求會對系統(tǒng)的成功造成巨大的威脅。如果測試組在需求階段就驗(yàn)證了需求的可測試性，對需求進(jìn)行了評審，那么此類問題會減少很多。21.、軟件都有多少種分類?固件、支持軟件、系統(tǒng)軟件、應(yīng)用軟件22.、你認(rèn)為軟件測試過程中較常見的困難是什么？如何有效克服這些困難？（根據(jù)自己實(shí)際測試中遇到的情況來寫的）①?Bug的重現(xiàn)問題：有些Bug只是偶爾出現(xiàn)的，根本就不知道具體需要什么條件才能重現(xiàn)Bug.?解決方法：將不能重現(xiàn)的Bug，利用截圖的方式記錄下來。并說明一系列的操作步驟②?Bug的更新：舊的Bug修改好之后，很多時(shí)候會引發(fā)更多Bug的出現(xiàn)。?解決方法：對更新的功能模塊重點(diǎn)的測試之后，再重新測試和更新的功能密切的模塊，會不會產(chǎn)生新的Bug.③?與開發(fā)人員的溝通和對業(yè)務(wù)流程理解的分歧，經(jīng)常缺少需求文檔?解決方法：根據(jù)需求說明書和Bug情況，多多和開發(fā)人員進(jìn)行交流23.、測試計(jì)劃工作的目的是什么？測試計(jì)劃工作的內(nèi)容都包括什么？其中哪些是最重要的？軟件測試計(jì)劃是指導(dǎo)測試過程的綱領(lǐng)性文件，對測試工作的計(jì)劃和安排包含了產(chǎn)品概述、測試策略、測試方法、測試區(qū)域、測試配置、測試周期、測試資源、測試交流、風(fēng)險(xiǎn)分析等內(nèi)容。借助軟件測試計(jì)劃，參與測試的項(xiàng)目成員，尤其是測試管理人員，可以明確測試任務(wù)和測試方法，保持測試實(shí)施過程的順暢溝通，跟蹤和控制測試進(jìn)度，應(yīng)對測試過程中的各種變更。測試計(jì)劃和測試詳細(xì)規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計(jì)劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細(xì)規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)。所以其中最重要的是測試測試策略和測試方法（最好是能先評審）24.、怎樣保證你所負(fù)責(zé)的模塊通過了測試首先是了解用戶的需求，設(shè)計(jì)好的測試用例，嚴(yán)格的進(jìn)行用例的評審，認(rèn)真的執(zhí)行測試用例，對自己提交的Bug進(jìn)行詳細(xì)的描述。反復(fù)測試增強(qiáng)測試的準(zhǔn)確性，通過冒煙回歸隨機(jī)測試挖掘缺陷提高測試工作質(zhì)量，把各個(gè)模塊整體運(yùn)行發(fā)現(xiàn)未曾出現(xiàn)的錯(cuò)誤，完善測試用例25.、您認(rèn)為性能測試工作的目的是什么？做好性能測試工作的關(guān)鍵是什么？性能測試工作的目的是檢查系統(tǒng)是否滿足在需求說明書中規(guī)定的性能，性能測試常常需要和強(qiáng)度測試結(jié)合起來，并常常要求同時(shí)進(jìn)行軟件和硬件的檢測。性能測試主要的關(guān)注對象是響應(yīng)時(shí)間，吞吐量，占用內(nèi)存大?。ㄝo助存儲區(qū)），處理精度等。26.、怎么編寫案例案例的編寫與測試階段的定義有很大的關(guān)系。系統(tǒng)測試和unit測試的案例可能不同?？傮w而言測試案例根據(jù)系統(tǒng)的需求而定。27.、怎么才能夠全面的測試到每一個(gè)點(diǎn)測試的全面性主要需要在設(shè)計(jì)測試計(jì)劃的時(shí)候考慮，從測試策略，產(chǎn)品需求等等多個(gè)角度考慮從而定義全部的測試點(diǎn)。28.、常用的測試工具及分類功能測試工具—QTP；性能測試工具—LoadRunner；測試管理工具—TestDirector；白盒測試工具—Nunit，Junit，C++Test，JTest，BoundsChecker，Logiscope29.、軟件測試與調(diào)試的關(guān)系？1)測試條件已知，規(guī)程可定義，結(jié)果可預(yù)知2)測試可以計(jì)劃，過程可控3)測試是檢驗(yàn)，調(diào)試是推理過程4)測試表明程序失敗，調(diào)試表明正確5)測試可不了解設(shè)計(jì)細(xì)節(jié)6)測試由非設(shè)計(jì)人員完成7)測試有理論依據(jù)8)測試可自動化30.、給你一個(gè)網(wǎng)站，你如何測試？1.查找需求說明、網(wǎng)站設(shè)計(jì)等相關(guān)文檔，分析測試需求。2.制定測試計(jì)劃，確定測試范圍和測試策略，一般包括以下幾個(gè)部分：功能性測試、界面測試、性能測試、數(shù)據(jù)庫測試、安全性測試、兼容性測試。3.設(shè)計(jì)測試用例：功能性測試：1鏈接測試。鏈接是否正確跳轉(zhuǎn)，是否存在空頁面和無效頁面，是否有不正確的出錯(cuò)信息返回等。2提交功能的測試。3多媒體元素是否可以正確加載和顯示。4多語言支持是否能夠正確顯示選擇的語言等。界面測試：1頁面是否風(fēng)格統(tǒng)一，美觀2頁面布局是否合理，重點(diǎn)內(nèi)容和熱點(diǎn)內(nèi)容是否突出3控件是否正常使用4對于必須但未安裝的控件，是否提供自動下載并安裝的功能5文字檢查性能測試：壓力測試、負(fù)載測試、強(qiáng)度測試數(shù)據(jù)庫測試：要具體決定是否需要開展。數(shù)據(jù)庫一般需要考慮連結(jié)性，對數(shù)據(jù)的存取操作，數(shù)據(jù)內(nèi)容的驗(yàn)證等方面。安全性測試：1基本的登錄功能的檢查2是否存在溢出錯(cuò)誤，導(dǎo)致系統(tǒng)崩潰或者權(quán)限泄露3相關(guān)開發(fā)語言的常見安全性問題檢查，例如SQL注入等。4如果需要高級的安全性測試，確定獲得專業(yè)安全公司的幫助，外包測試，或者獲取支持兼容性測試：根據(jù)需求說明的內(nèi)容，確定支持的平臺組合。1瀏覽器的兼容性2操作系統(tǒng)的兼容性3軟件平臺的兼容性4數(shù)據(jù)庫的兼容性4.開展測試，并記錄缺陷。合理的安排調(diào)整測試進(jìn)度，提前獲取測試所需的資源，建立管理體系（例如，需求變更、風(fēng)險(xiǎn)、配置、測試文檔、缺陷報(bào)告、人力資源等內(nèi)容）。5.定期評審，對測試進(jìn)行評估和總結(jié)，調(diào)整測試的內(nèi)容。31.、您在從事性能測試工作時(shí)，是否使用過一些測試工具？如果有，請?jiān)囀鲈摴ぞ叩墓ぷ髟恚⒁砸粋€(gè)具體的工作中的例子描述該工具是如何在實(shí)際工作中應(yīng)用的。有使用過LoadRunner,該工具能夠錄制測試人員的操作步驟，然后對這個(gè)操作步驟模擬出多個(gè)用戶來播放出來。1.VisuralUserGenertor創(chuàng)建腳本，選擇協(xié)議，錄制操作，編輯操作。2.中央控制器（Controller）調(diào)度虛擬用戶。創(chuàng)建場景，選擇腳本，建立虛擬用戶，設(shè)計(jì)shedual，設(shè)置ipspoofer。3.運(yùn)行腳本。分析shedual。4.分析測試結(jié)果。32.、怎樣做好測試計(jì)劃1.理解系統(tǒng)。從整個(gè)系統(tǒng)的高度了解被測系統(tǒng)必須滿足的功能和非功能性需求。利用涉及整個(gè)系統(tǒng)的文檔，形成對系統(tǒng)的整體了解。2.及早介入。為了深入了解項(xiàng)目，測試人員應(yīng)該在系統(tǒng)的開始階段介入，可以增加對客戶需求，客戶問題，潛在風(fēng)險(xiǎn)，以及最重要的功能方面的理解3.測試期望。程序員的期望是什么？客戶的期望是什么？銷售對測試的期望又是什么？測試目標(biāo)必須是絕對的，以免說不清楚是否達(dá)到目標(biāo)。4.吸取教訓(xùn)。把以前工作中學(xué)習(xí)到的經(jīng)驗(yàn)教訓(xùn)運(yùn)用過來，對確定測試策略很有作用。5.工作量大小。完成測試需要多少工作量？需要多少人員？6.技術(shù)選擇。系統(tǒng)會采取什么技術(shù)？系統(tǒng)會采用什么架構(gòu)？這些信息有助于確定測試策略和測試工具。7.時(shí)間表。系統(tǒng)開發(fā)和測試分配的時(shí)間有多長？截止日期是什么時(shí)候？33.、您是否了解以往所工作的企業(yè)的軟件測試過程？如果了解，請?jiān)囀鲈谶@個(gè)過程中都有哪些工作要做？分別由哪些不同的角色來完成這些工作？軟件測試部門配合系統(tǒng)分析人員軟件需求分析討論，并根據(jù)需求說明書制定《項(xiàng)目測試計(jì)劃》，編寫測試用例，建立測試環(huán)境。軟件測試人員負(fù)責(zé)軟件開發(fā)部門的新產(chǎn)品測試及原有產(chǎn)品的升級測試，負(fù)責(zé)軟件問題解決過程跟蹤，負(fù)責(zé)軟件開發(fā)文檔開發(fā)工作的規(guī)范化及管理開發(fā)部門的產(chǎn)品文檔，制作用戶手冊及操作手冊，負(fù)責(zé)產(chǎn)品的上線測試，監(jiān)督軟件開發(fā)過程的執(zhí)行，提高產(chǎn)品質(zhì)量。需求人員連同系統(tǒng)分析人員&測試人員開會討論需求。系統(tǒng)分析人員寫出需求分析說明，并連同系統(tǒng)分析人員&測試人員&需求人員開會討論可行性。系統(tǒng)分析人員寫出詳細(xì)設(shè)計(jì)說明書，程式人員編碼，給出系統(tǒng)流程圖。交與測試人員，測試人員給出Bug統(tǒng)計(jì)表。34.、系統(tǒng)測試階段低級缺陷較多怎么辦？公司有預(yù)測試這個(gè)流程，會在開展測試活動之前對主要功能點(diǎn)的正常流程做一個(gè)測試，以判斷這個(gè)版本是不是可測試版本，如果低級缺陷比較多，嚴(yán)重阻礙測試執(zhí)行的話，我們會打回開發(fā)部，不執(zhí)行測試。35.、缺陷流落到客戶那里怎么辦？我們公司會盡可能的避免這種情況的出現(xiàn)，讓軟件缺陷在內(nèi)部得到解決，萬一版本上線了才發(fā)現(xiàn)有問題，我們也會及時(shí)派技術(shù)人員在最短的時(shí)間內(nèi)做出修改，把客戶的損失降到最低。36.、代碼會審是什么？對代碼的一個(gè)評審的過程，發(fā)現(xiàn)一些最基本的錯(cuò)誤，方式是靜態(tài)的代碼走讀方式，在一些大型軟件的設(shè)計(jì)過程中，還是必不可少的。37.、請問功能測試和性能測試的區(qū)別是什么？(只總結(jié)了兩個(gè)方面，有其他的自己補(bǔ)充)①測試目的：?功能測試：檢查實(shí)際軟件的功能是否符合用戶的需求，測功能是不是全部實(shí)現(xiàn)，某個(gè)實(shí)現(xiàn)是不是有BUG。主要為了發(fā)現(xiàn)以下幾類錯(cuò)誤：A、是否有不正確或遺漏的功能？B、功能實(shí)現(xiàn)是否滿足用戶需求和系統(tǒng)設(shè)計(jì)的隱藏需求？C、能否正確接收輸入？能否正確輸出結(jié)果？?性能測試：驗(yàn)證軟件質(zhì)量的三個(gè)質(zhì)量特性，可靠性，正確性和效率。主要是測試產(chǎn)品的健壯性②測試方式：?功能測試：按照系統(tǒng)需求說明書和測試用例，對產(chǎn)品的功能一步步進(jìn)行測試。找出產(chǎn)品功能是否全部實(shí)現(xiàn)?性能測試：一般都使用性能工具對產(chǎn)品的健壯性進(jìn)行評估。通過創(chuàng)建場景和虛擬用戶來模擬真實(shí)環(huán)境，進(jìn)行壓力測試和負(fù)載測試。38.、狀態(tài)為已修改的缺陷實(shí)際沒有修改怎么辦？加強(qiáng)項(xiàng)目質(zhì)量管理，提高項(xiàng)目執(zhí)行能力。如果測試人員發(fā)現(xiàn)了這樣的問題，首先要弄清楚是什么原因?qū)е逻@種情況，最終還是要督促開發(fā)人員，修改掉這些問題。如果是不能重現(xiàn)的問題或者是老版本中遺留下來的問題不能修改的要做好標(biāo)示。39.、性能測試什么時(shí)候開始最合適一般在功能測試最后階段執(zhí)行因?yàn)楣δ茏咄诵阅懿庞幸饬x總之性能測試要根據(jù)用戶實(shí)際性能指標(biāo)來操作是一個(gè)很重要的測試活動要根據(jù)軟件的屬性以及它的實(shí)際情況來制定策略40.、回歸測試中未解決的缺陷如何處理實(shí)際項(xiàng)目中也會因?yàn)榉N種原因出現(xiàn)最后一輪測試結(jié)束了還有一些缺陷沒有解決那么對于問題的不同我們有不同的解決方式：嚴(yán)重性問題：必須解決，不允許上線；功能性問題：可以考慮在后續(xù)版本中解決；一般性問題：可以不解決或者升級的時(shí)候解決。41.、集成測試通常都有那些策略？1)在把各個(gè)模塊連接起來的時(shí)候，穿越模塊接口的數(shù)據(jù)是否會丟失；2)各個(gè)子功能組合起來，能否達(dá)到預(yù)期要求的父功能；3)一個(gè)模塊的功能是否會對另一個(gè)模塊的功能產(chǎn)生不利的影響；4)全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題；5)單個(gè)模塊的誤差積累起來，是否會放大，從而達(dá)到不可接受的程度。42.軟件測試的對象答：軟件測試并不等于程序測試。軟件測試應(yīng)貫穿于軟件定義與開發(fā)的整個(gè)期間。需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說明、概要設(shè)計(jì)規(guī)格說明、詳細(xì)設(shè)計(jì)規(guī)格說明以及源程序，都應(yīng)成為軟件測試的對象。43.什么是UML？答：UnifiedModelingLanguage它是一種用于描述，構(gòu)造軟件系統(tǒng)以及商業(yè)建模的語言。簡單的理解就是它可以以一種直觀的方式表示出一個(gè)系統(tǒng)的各項(xiàng)內(nèi)容。44.、什么是測試策略測試策略描述測試工程的總體方法和目標(biāo)主要包括以下三個(gè)方面：1確定的測試技術(shù)和工具2制定測試啟動停止完成標(biāo)準(zhǔn)3風(fēng)險(xiǎn)分析和應(yīng)對方案其目的是為我們更好的寫出高質(zhì)量的用例提供支撐45.軟件測試按過程分為三個(gè)步驟單元測試：單元測試又稱模塊測試，是針對軟件設(shè)計(jì)的最小單位─程序模塊，進(jìn)行正確性檢驗(yàn)的測試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯(cuò)。單元測試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測試用例。多個(gè)模塊可以平行地獨(dú)立進(jìn)行單元測試。集成測試：在運(yùn)行（可能是不完整）的應(yīng)用中保證軟件單元被結(jié)合后能正常操作的測試執(zhí)行的階段系統(tǒng)測試：當(dāng)應(yīng)用作為整體運(yùn)行時(shí)的測試執(zhí)行階段軟件測試員和組長的職責(zé)分工普通測試員：創(chuàng)作相關(guān)的測試計(jì)劃和測試案例識別可自動測試的區(qū)域參與組內(nèi)的測試計(jì)劃和測試案例以及測試腳本分析工作手動或自動測試按照需求規(guī)格說明查證并驗(yàn)證各項(xiàng)功能發(fā)現(xiàn)并報(bào)告bug，跟蹤其狀態(tài)初步評估bug對產(chǎn)品其他部分的影響測試組長：確定測試的策略參與對整個(gè)產(chǎn)品的完整測試計(jì)劃的制定參與并管理測試評估bug對用戶的影響跟蹤關(guān)鍵bug狀態(tài)管理測試工作和對象的資源參與面試新人交流狀態(tài)和存在問題，并驅(qū)動問題的解決促進(jìn)組內(nèi)的交流47.什么是bug？軟件的Bug指的是軟件中（包括程序和文檔）不符合用戶需求的問題。常見的軟件Bug分為以下三類：沒有實(shí)現(xiàn)的功能完成了用戶需求的功能，但是運(yùn)行時(shí)會出現(xiàn)一些功能或性能上的問題實(shí)現(xiàn)了用戶不需要的多余的功能48.什么是CMM？CMM：CapabilityMaturityModel，即“能力成熟度模型”。它是一個(gè)分5級的、可以描述結(jié)構(gòu)完善程度的模型，用它來說明所交付的軟件的效能。49.您認(rèn)為在測試人員同開發(fā)人員的溝通過程中，如何提高溝通的效率和改善溝通的效果？維持測試人員同開發(fā)團(tuán)隊(duì)中其他成員良好的人際關(guān)系的關(guān)鍵是什么？

盡量能有面對面的溝通，如果做不到，那么盡量能直接通過電話溝通，如果只能通過Email等非及時(shí)溝通工具的話，強(qiáng)調(diào)必須對特性的理解深刻以及能表達(dá)清楚。

一是真誠，二是團(tuán)隊(duì)精神，三是在專業(yè)上有共同語言，當(dāng)然也可以通過直接指出一些小問題，而不是進(jìn)入BUGTrackingSystem來增加對方的好感。50.你們以前的測試流程是怎樣的？明確需求——測試計(jì)劃——制定測試策略和測試用例——搭建測試環(huán)境、執(zhí)行測試用例、提交缺陷報(bào)告——對測試過程和版本質(zhì)量評估得出測試總結(jié)報(bào)告——最后驗(yàn)收測試51.請?jiān)囍容^一下黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試的區(qū)別與聯(lián)系。黑盒測試：把測試對象當(dāng)成一個(gè)黑盒子，測試人員完全不考慮邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程式的需求說明書來檢查程式的功能是否滿足它的功能說明。白盒測試：把測試對象當(dāng)成一個(gè)透明的盒子，允許測試人員利用程序內(nèi)部邏輯結(jié)構(gòu)及相關(guān)信息，設(shè)計(jì)或選擇測試用例，對程式所有邏輯路徑進(jìn)行測試。單元測試：白盒測試的一種，對軟件設(shè)計(jì)中的單元模塊進(jìn)行測試。集成測試：在單元測試的基礎(chǔ)上，對單元模塊之間的連接和組裝進(jìn)行測試。系統(tǒng)測試：在所有都考慮的情況下，對系統(tǒng)進(jìn)行測試。驗(yàn)收測試：第三方進(jìn)行的確認(rèn)軟件滿足需求的測試。52.您以往的工作中是否曾開展過測試用例的評審工作？如果有，請描述測試用例評審的過程和評審的內(nèi)容。53.軟件本地化測試和功能測試都有那些方面要注意？54.什么是軟件質(zhì)量？高質(zhì)量的軟件是適當(dāng)?shù)摹o錯(cuò)誤的，能在預(yù)算內(nèi)按時(shí)交貨，滿足需求/或期望，并且是可維護(hù)的。所以，質(zhì)量是一個(gè)主觀的術(shù)語。它取決于誰是客戶以及客戶對項(xiàng)目計(jì)劃的影響。對一個(gè)軟件開發(fā)項(xiàng)目來說，“客戶”的范圍很廣，包括最終用戶、客戶所接受的測試者、與客戶合同有關(guān)的官員、客戶管理、開發(fā)機(jī)構(gòu)的管理者/會計(jì)/測試人員/銷售人員、未來的軟件維護(hù)工程師、股票持有者、雜志專欄記者，等等。每一類客戶對“質(zhì)量”都有自己的傾向性–會計(jì)部門判斷質(zhì)量會從其收益來考慮，而最終用戶則重視友好的用戶界面和沒有錯(cuò)誤。55．為什么軟件會有毛??？1.交流錯(cuò)誤或者沒有進(jìn)行交流，2.軟件的復(fù)雜性編程錯(cuò)誤3.需求變更客戶恐怕不明白改變需求的影響，也許是知道但依然需要變更──會導(dǎo)致重新設(shè)計(jì)、重訂工程進(jìn)度表、對其他項(xiàng)目的影響、已完成的工作需要重做或者放棄、對硬件需求的影響等等。如果在項(xiàng)目中出現(xiàn)許多小的改變或一個(gè)大的改變，在項(xiàng)目各部分中出現(xiàn)已知或未知的相關(guān)的問題，可能會相互影響并導(dǎo)致出現(xiàn)問題。而且，不斷地變更也會增加軟件的復(fù)雜性，可能會導(dǎo)致錯(cuò)誤的出現(xiàn)。這樣就會影響技術(shù)人員的積極性。在一些快速變化的商業(yè)環(huán)境里，持續(xù)變更需求的影響是致命的。在這種情況下，管理者必須知道它的危險(xiǎn)性。質(zhì)量保障和測試工程師必須與此相適應(yīng)，并安排持續(xù)的廣泛的測試，以克服不可避免產(chǎn)生的問題。4.時(shí)間壓力因?yàn)橛性S多猜測成分，軟件開發(fā)項(xiàng)目的進(jìn)度很難安排得理想。當(dāng)最后期限快到的時(shí)候，壓力逐漸增大，錯(cuò)誤隨之產(chǎn)生5.自負(fù)心理、代碼文檔質(zhì)量差、軟件開發(fā)工具56.什么是驗(yàn)證、評價(jià)、預(yù)排、檢查？驗(yàn)證(verification)涉及了回顧和會議，以評估文檔、計(jì)劃、代碼、需求和說明書?？梢酝ㄟ^檢查表、調(diào)查表、排練、和檢查會來進(jìn)行。評價(jià)(validation)則指在檢察完成之后的實(shí)際測試。術(shù)語“IV”和“V”分別代表驗(yàn)證和評價(jià)。“預(yù)排”是一個(gè)非正式的會議，用來進(jìn)行評估和信息交流。通常不需要或者只需很少一點(diǎn)準(zhǔn)備。檢查比預(yù)排更正式一點(diǎn)，通常有3-8個(gè)人參加會議，包括一個(gè)仲裁者(moderator)、讀者(可以是作者或者任何評論者)、一個(gè)記錄員作記錄。典型的檢查對象是一個(gè)文件，例如需求說明或者測試計(jì)劃，目的在于發(fā)現(xiàn)問題和查找遺漏，而不是去對任何東西進(jìn)行實(shí)際的修改。會議的參加者應(yīng)當(dāng)有準(zhǔn)備，應(yīng)當(dāng)通讀文件，大多數(shù)的問題會在準(zhǔn)備的過程中被發(fā)現(xiàn)。檢查會的結(jié)果應(yīng)寫成書面報(bào)告。對檢查會進(jìn)行全面準(zhǔn)備是困難而艱苦的工作，但它是保證質(zhì)量最有用的方法。在檢查過程中，最有經(jīng)驗(yàn)的雇員的作用就向‘大哥哥’一樣，他們的技能也許不大顯眼，但對任何軟件開發(fā)機(jī)構(gòu)是最重要的，這是因?yàn)轭A(yù)防錯(cuò)誤要比發(fā)現(xiàn)錯(cuò)誤在費(fèi)用方面更加有效。介紹一下整體項(xiàng)目流程。我們公司的測試流程是圍繞著測試的五個(gè)階段展開的，測試計(jì)劃、設(shè)計(jì)測試、執(zhí)行測試、評估測試、驗(yàn)收測試。只是在不同的階段有自己的一套做法。在接到項(xiàng)目單后，我們會召開一個(gè)項(xiàng)目開工會，要求各部門的相關(guān)人員都參與，會議我們主要是了解一下項(xiàng)目的背景、目的和資料。確定開始時(shí)間和結(jié)束時(shí)間和項(xiàng)目參與人員，測試部和開發(fā)商量好開發(fā)轉(zhuǎn)系統(tǒng)測試時(shí)間，然后就進(jìn)入計(jì)劃階段，開發(fā)和測試都有自己的計(jì)劃，我們測試計(jì)劃由測試經(jīng)理編寫，測試計(jì)劃中主要是制定可采用的測試策略和范圍，評估項(xiàng)目風(fēng)險(xiǎn)和規(guī)避措施，制定時(shí)間進(jìn)度表，合理的分配人力、物力資源。之后進(jìn)入設(shè)計(jì)階段，設(shè)計(jì)階段我們會參考開發(fā)的需求說明書、詳細(xì)設(shè)計(jì)、概要設(shè)計(jì)去設(shè)計(jì)測試用例。接到開發(fā)的新版本就進(jìn)入了測試執(zhí)行階段，首先是搭建測試環(huán)境，對軟件實(shí)施預(yù)測試主要是驗(yàn)證系統(tǒng)的正常功能是否可用，然后就是系統(tǒng)測試，執(zhí)行用例并提交缺陷報(bào)告，至于系統(tǒng)測試的輪次則要根據(jù)項(xiàng)目的復(fù)雜度和版本質(zhì)量決定的。后期我們進(jìn)入測試評估階段對軟件測試的過程和版本質(zhì)量進(jìn)行評估得出測試總結(jié)報(bào)告，最后我們進(jìn)入測試驗(yàn)收階段，我們會出用戶手冊、操作指引等文檔，我們公司在每個(gè)階段的輸出都有一個(gè)評審階段，保證輸出有效，從而使測試順利進(jìn)行。在實(shí)際項(xiàng)目中你是如何做測試計(jì)劃的做測試計(jì)劃前必須先了解項(xiàng)目的背景、目的等資料，然后合理劃分測試范圍，制定可采用的測試策略，評估項(xiàng)目中可能存在的風(fēng)險(xiǎn)和規(guī)避措施，制定好時(shí)間進(jìn)度表，合理分配項(xiàng)目的人力、物力資源。你是如何制定時(shí)間進(jìn)度表的首先確定三個(gè)大的時(shí)間段項(xiàng)目開始時(shí)間項(xiàng)目結(jié)束時(shí)間開發(fā)轉(zhuǎn)系統(tǒng)測試時(shí)間，在根據(jù)測試各個(gè)階段的工作量和項(xiàng)目資源制定計(jì)劃、設(shè)計(jì)、執(zhí)行、評估、驗(yàn)收階段的時(shí)間。設(shè)計(jì)和執(zhí)行的時(shí)間一般較多。測試計(jì)劃都包括那些項(xiàng)項(xiàng)目基本信息、總體測試策略、項(xiàng)目風(fēng)險(xiǎn)分析和規(guī)避措施、項(xiàng)目資源分配（人力、物力、軟硬件環(huán)境）、項(xiàng)目時(shí)間進(jìn)度表、系統(tǒng)優(yōu)先級測試用例如何設(shè)計(jì)根據(jù)開發(fā)的需求說明書、詳細(xì)設(shè)計(jì)說明、和概要設(shè)計(jì)說明書設(shè)計(jì)測試用例遇見那里不明確的可以直接和開發(fā)人員溝通討論。設(shè)計(jì)的時(shí)候我們會綜合運(yùn)用黑盒測試法，如運(yùn)用等價(jià)類劃分、邊界值分析、錯(cuò)誤推測法等。如何保證用例覆蓋到罕見缺陷1.預(yù)留足夠的時(shí)間理解需求說明在設(shè)計(jì)用例2.采用評審和更新機(jī)制，保證每一步的輸出都是有效的，從而保證測試順利進(jìn)行。3.對覆蓋不全面的或是沒有覆蓋到的，在版本間歇期追加測試用例63.缺陷處理流程！測試員提交新的缺陷入庫設(shè)置狀態(tài)為New由高級測試人員驗(yàn)證缺陷，如果是缺陷則提交給項(xiàng)目經(jīng)理設(shè)置為（Open）分配給開發(fā)部修改，并將修改后的缺陷設(shè)置為（Fixed）,如果不是缺陷則直接拒絕（Decline）對于不能夠立即解決的缺陷一般要開會議討論則設(shè)置狀態(tài)為“延期“（Derlend）最后由測試員從新檢查修改后的缺陷。不是則直接關(guān)閉（Closed）測試用例包括那些項(xiàng)基本信息、用例編號、嚴(yán)重級別、缺陷描述、操作步驟開發(fā)人員修復(fù)缺陷后，如何保證不影響其他功能重新執(zhí)行用例、看是否出現(xiàn)錯(cuò)誤結(jié)果。并對周圍的一些相關(guān)功能點(diǎn)追加新的測試用例。測試總結(jié)報(bào)告包括那些項(xiàng)主要有對測試過程和版本質(zhì)量的評估，并有一些質(zhì)量建議。還有一些數(shù)據(jù)，如用例總數(shù)，執(zhí)行數(shù)量等。針對邏輯性較強(qiáng)的功能點(diǎn)你該如何設(shè)計(jì)測試用例？？？測試工作進(jìn)行到一半是，發(fā)現(xiàn)時(shí)間不夠，你如何處理1.可以加班加點(diǎn)，加派測試人員并征用有經(jīng)驗(yàn)的技術(shù)員2.可以挑選優(yōu)先級別高的用例先執(zhí)行。67.怎樣保證你所負(fù)責(zé)的模塊通過了測試設(shè)計(jì)好的用例、詳細(xì)劃分用例嚴(yán)重級別，先執(zhí)行優(yōu)先級別高的用例，保證規(guī)定的功能都正常工作。保證用例的覆蓋率和用例的質(zhì)量，最后能夠符合用戶需求說明書。并通過了內(nèi)部評審。開發(fā)與測試的關(guān)系？測試是依托于開發(fā)的測試同時(shí)也可以指導(dǎo)開發(fā)。開發(fā)和測試密切聯(lián)系、相互依賴，開發(fā)為測試提供產(chǎn)品，測試負(fù)責(zé)檢查開發(fā)的產(chǎn)品，測試和開發(fā)有共同的目的就是提高和改善軟件質(zhì)量。如果你是測試組長你如何對項(xiàng)目及組員進(jìn)行管理1.強(qiáng)調(diào)合作和討論，一切以圓滿完成項(xiàng)目為出發(fā)點(diǎn)2.合理分配項(xiàng)目資源和技術(shù)人員，明確職責(zé)合理分工。3.表揚(yáng)和懲罰制度4.保護(hù)測試員WEB網(wǎng)站測試總結(jié)1.功能測試

對于網(wǎng)站的測試而言，每一個(gè)獨(dú)立的功能模塊需要單獨(dú)的測試用例的設(shè)計(jì)導(dǎo)出，主要依據(jù)為《需求規(guī)格說明書》及《詳細(xì)設(shè)計(jì)說明書》，對于應(yīng)用程序模塊需要設(shè)計(jì)者提供基本路徑測試法的測試用例。

鏈接測試

鏈接是Web應(yīng)用系統(tǒng)的一個(gè)主要特征，它是在頁面之間切換和指導(dǎo)用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個(gè)方面：

1）測試所有鏈接是否按指示的那樣確實(shí)鏈接到了該鏈接的頁面；

2）測試所鏈接的頁面是否存在；

3）保證Web應(yīng)用系統(tǒng)上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的URL地址才能訪問。

鏈接測試可以自動進(jìn)行，現(xiàn)在已經(jīng)有許多工具可以采用。鏈接測試必須在集成測試階段完成，也就是說，在整個(gè)Web應(yīng)用系統(tǒng)的所有頁面開發(fā)完成之后進(jìn)行鏈接測試。

Xenu------主要測試鏈接的正確性的工具

可惜的是對于動態(tài)生成的頁面的測試會出現(xiàn)一些錯(cuò)誤。

表單測試

當(dāng)用戶給Web應(yīng)用系統(tǒng)管理員提交信息時(shí)，就需要使用表單操作，例如用戶注冊、登陸、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗(yàn)提交給服務(wù)器的信息的正確性。例如：用戶填寫的出生日期與職業(yè)是否恰當(dāng)，填寫的所屬省份與所在城市是否匹配等。如果使用了默認(rèn)值，還要檢驗(yàn)?zāi)J(rèn)值的正確性。如果表單只能接受指定的某些值，則也要進(jìn)行測試。例如：只能接受某些字符，測試時(shí)可以跳過這些字符，看系統(tǒng)是否會報(bào)錯(cuò)。

要測試這些程序，需要驗(yàn)證服務(wù)器能正確保存這些數(shù)據(jù)，而且后臺運(yùn)行的程序能正確解釋和使用這些信息。

B/S結(jié)構(gòu)實(shí)現(xiàn)的功能可能主要的就在這里，提交數(shù)據(jù)，處理數(shù)據(jù)等如果有固定的操作流程可以考慮自動化測試工具的錄制功能，編寫可重復(fù)使用的腳本代碼，可以在測試、回歸測試時(shí)運(yùn)行以便減輕測試人員工作量。

我們對UM子系統(tǒng)中各個(gè)功能模塊中的各項(xiàng)功能進(jìn)行逐一的測試，主要測試方法為：邊界值測試、等價(jià)類測試，以及異常類測試。測試中要保證每種類型都有2個(gè)以上的典型數(shù)值的輸入，以確保測試輸入的全面性。

Cookies測試

Cookies通常用來存儲用戶信息和用戶在某應(yīng)用系統(tǒng)的操作，當(dāng)一個(gè)用戶使用Cookies訪問了某一個(gè)應(yīng)用系統(tǒng)時(shí)，Web服務(wù)器將發(fā)送關(guān)于用戶的信息，把該信息以Cookies的形式存儲在客戶端計(jì)算機(jī)上，這可用來創(chuàng)建動態(tài)和自定義頁面或者存儲登陸等信息。

如果Web應(yīng)用系統(tǒng)使用了Cookies，就必須檢查Cookies是否能正常工作而且對這些信息已經(jīng)加密。測試的內(nèi)容可包括Cookies是否起作用，是否按預(yù)定的時(shí)間進(jìn)行保存，刷新對Cookies有什么影響等。

設(shè)計(jì)語言測試

Web設(shè)計(jì)語言版本的差異可以引起客戶端或服務(wù)器端嚴(yán)重的問題，例如使用哪種版本的HTML等。當(dāng)在分布式環(huán)境中開發(fā)時(shí)，開發(fā)人員都不在一起，這個(gè)問題就顯得尤為重要。除了HTML的版本問題外，不同的腳本語言，例如Java、JavaScript、ActiveX、VBScript或Perl等也要進(jìn)行驗(yàn)證。

數(shù)據(jù)庫測試

在Web應(yīng)用技術(shù)中，數(shù)據(jù)庫起著重要的作用，數(shù)據(jù)庫為Web應(yīng)用系統(tǒng)的管理、運(yùn)行、查詢和實(shí)現(xiàn)用戶對數(shù)據(jù)存儲的請求等提供空間。在Web應(yīng)用中，最常用的數(shù)據(jù)庫類型是關(guān)系型數(shù)據(jù)庫，可以使用SQL對信息進(jìn)行處理。

在使用了數(shù)據(jù)庫的Web應(yīng)用系統(tǒng)中，一般情況下，可能發(fā)生兩種錯(cuò)誤，分別是數(shù)據(jù)一致性錯(cuò)誤和輸出錯(cuò)誤。數(shù)據(jù)一致性錯(cuò)誤主要是由于用戶提交的表單信息不正確而造成的，而輸出錯(cuò)誤主要是由于網(wǎng)絡(luò)速度或程序設(shè)計(jì)問題等引起的，針對這