軟件測試基礎(chǔ)習(xí)題及答案

軟件測試基礎(chǔ)習(xí)題及答案軟件測試基礎(chǔ)習(xí)題及答案軟件測試基礎(chǔ)習(xí)題及答案V:1.0精細(xì)整理，僅供參考軟件測試基礎(chǔ)習(xí)題及答案日期：20xx年X月軟件測試的定義軟件測試是一個過程或者一系列過程，用來確認(rèn)計算和代碼完成了其應(yīng)該完成的功能，并且不執(zhí)行其不應(yīng)該有的操作。軟件測試的目標(biāo)是什么是想以最少的人力、物力和時間找出軟件中潛在的各種錯誤和缺陷，通過修正各種錯誤和缺陷提高軟件質(zhì)量，降低軟件發(fā)布后由于潛在的軟件錯誤和缺陷造成的隱患所帶來的商業(yè)風(fēng)險。簡單描述一下軟件測試的原則所有的軟件測試都應(yīng)追溯到用戶需求應(yīng)當(dāng)把“盡早地和不斷地進(jìn)行軟件測試”作為測試者的座右銘GoodEnough原則質(zhì)量第一充分注意測試中的群集現(xiàn)象程序員應(yīng)避免檢查自己的程序有據(jù)可依盡量避免軟件測試的隨意性，要有預(yù)期結(jié)果重視回歸測試妥善保存一切測試過程文檔軟件測試中驗(yàn)證和確認(rèn)的區(qū)別Verfication驗(yàn)證：是保證軟件正確實(shí)現(xiàn)特定功能的一系列活動和過程。目的是保證軟件生命周期中的每一個階段的成果滿足上一個階段設(shè)定的目標(biāo)。Validation確認(rèn)：是保證軟件滿足用戶需求的一系列的活動和過程。目的是在軟件開發(fā)后保證與用戶需求符合軟件測試按照測試的基本策略可分為哪兩種并加以詳細(xì)說明白盒測試：白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試，是指基于一個應(yīng)用代碼的內(nèi)部邏輯知識，即基于覆蓋全部代碼、分支、路徑、條件的測試，它是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行，按照程序內(nèi)部的結(jié)構(gòu)測試程序，檢驗(yàn)程序中的每條通路是否都有能按預(yù)定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅(qū)動、基路測試等，主要用于軟件驗(yàn)證。黑盒測試：黑盒測試是指不基于內(nèi)部設(shè)計和代碼的任何知識，而基于需求和功能性的測試，黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動測試，它是在已知產(chǎn)品所應(yīng)具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試者在程序接口進(jìn)行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息（如數(shù)據(jù)庫或文件）的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因—果圖、錯誤推測等，主要用于軟件確認(rèn)測試。6、整個軟件生命周期中，需要進(jìn)行哪幾項(xiàng)測試單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試單元測試單元測試是對軟件中的基本組成單位進(jìn)行的測試，如一個模塊、一個過程等等。它是軟件動態(tài)測試的最基本的部分，也是最重要的部分之一，其目的是檢驗(yàn)軟件基本組成單位的正確性。因?yàn)閱卧獪y試需要知道內(nèi)部程序設(shè)計和編碼的細(xì)節(jié)知識，一般應(yīng)由程序員而非測試員來完成，往往需要開發(fā)測試驅(qū)動模塊和樁模塊來輔助完成單元測試。因此應(yīng)用系統(tǒng)有一個設(shè)計很好的體系結(jié)構(gòu)就顯得尤為重要。一個軟件單元的正確性是相對于該單元的規(guī)約而言的。因此，單元測試以被測試單位的規(guī)約為基準(zhǔn)。單元測試的主要方法有控制流測試、數(shù)據(jù)流測試、排錯測試、分域測試等等。集成測試集成測試是在軟件系統(tǒng)集成過程中所進(jìn)行的測試，其主要目的是檢查軟件單位之間的接口是否正確。它根據(jù)集成測試計劃，一邊將模塊或其他軟件單位組合成越來越大的系統(tǒng)，一邊運(yùn)行該系統(tǒng)，以分析所組成的系統(tǒng)是否正確，各組成部分是否合拍。集成測試的策略主要有自頂向下和自底向上兩種。系統(tǒng)測試系統(tǒng)測試是對已經(jīng)集成好的軟件系統(tǒng)進(jìn)行徹底的測試，以驗(yàn)證軟件系統(tǒng)的正確性和性能等滿足其規(guī)約所指定的要求，檢查軟件的行為和輸出是否正確并非一項(xiàng)簡單的任務(wù)，它被稱為測試的“先知者問題”。因此，系統(tǒng)測試應(yīng)該按照測試計劃進(jìn)行，其輸入、輸出和其他動態(tài)運(yùn)行行為應(yīng)該與軟件規(guī)約進(jìn)行對比。軟件系統(tǒng)測試方法很多，主要有功能測試、性能測試、隨機(jī)測試等等。驗(yàn)收測試驗(yàn)收測試旨在向軟件的購買者展示該軟件系統(tǒng)滿足其用戶的需求。它的測試數(shù)據(jù)通常是系統(tǒng)測試的測試數(shù)據(jù)的子集。所不同的是，驗(yàn)收測試常常有軟件系統(tǒng)的購買者代表在現(xiàn)場，甚至是在軟件安裝使用的現(xiàn)場。這是軟件在投入使用之前的最后測試。簡述集成測試和系統(tǒng)測試的區(qū)別集成測試的主要依據(jù)是概要設(shè)計說明書，系統(tǒng)測試的主要依據(jù)是需求設(shè)計說明書集成測試是系統(tǒng)模塊的測試，系統(tǒng)測試是對整個系統(tǒng)的測試，包括相關(guān)的軟硬件平臺，網(wǎng)絡(luò)及相關(guān)的外設(shè)的測試7、系統(tǒng)測試的策略有哪些功能測試，性能測試，可靠性測試，負(fù)載測試，易用性測試，強(qiáng)度測試，安全測試，配置測試，安裝測試，卸載測試，文擋測試，容錯性測試，界面測試，容量測試，兼容性測試，分布測試，可用性測試等。文檔測試主要包括哪些內(nèi)容聯(lián)機(jī)幫助文檔或用戶手冊指導(dǎo)和向?qū)О惭b、設(shè)置指南示例及模板錯誤提示信息用于演示的圖像和聲音授權(quán)/注冊登記表及用戶許可協(xié)議軟件的包裝、廣告宣傳材料停止測試的條件符合用戶的需求在一段時間內(nèi)測試不出新缺陷注：在企業(yè)實(shí)際開發(fā)過程中，版本發(fā)布時會有遺留問題測試的基本文檔包括哪些測試計劃》：指明測試范圍、方法、資源，以及相應(yīng)測試活動的時間進(jìn)度安排表的文檔?！稖y試方案》：指明為完成軟件或軟件集成特性的測試而進(jìn)行的設(shè)計測試方法的細(xì)節(jié)文檔?！稖y試用例》：指明為完成一個測試項(xiàng)的測試輸入，預(yù)期結(jié)果，測試執(zhí)行條件等因素的文檔。《測試規(guī)程》：指明執(zhí)行測試時測試活動序列的文檔?！稖y試報告》：指明執(zhí)行測試結(jié)果的文檔。簡要的說明一下軟件工程中的V模型項(xiàng)目規(guī)劃項(xiàng)目規(guī)劃項(xiàng)目需求分析項(xiàng)目概要分析項(xiàng)目詳細(xì)分析代碼編寫測試代碼編寫測試需求分析系統(tǒng)測試計劃集成測試計劃單元測試計劃產(chǎn)品發(fā)布測試系統(tǒng)測試集成測試單元測試為什么要開展測試工作因?yàn)闆]有經(jīng)過測試的軟件很難在發(fā)布之前知道該軟件的質(zhì)量，就好比ISO質(zhì)量認(rèn)證一樣，測試同樣也需要質(zhì)量的保證，這個時候就需要在團(tuán)隊(duì)中開展軟件測試的工作。在測試的過程發(fā)現(xiàn)軟件中存在的問題，及時讓開發(fā)人員得知并修改問題，在即將發(fā)布時，從測試報告中得出軟件的質(zhì)量情況測試團(tuán)隊(duì)在項(xiàng)目中的基本責(zé)任是什么發(fā)現(xiàn)軟件程序、系統(tǒng)或產(chǎn)品中所有的問題盡早地發(fā)現(xiàn)問題督促和協(xié)助開發(fā)人員盡快地解決程序中的缺陷。幫助項(xiàng)目管理人員制定合理的開發(fā)計劃對缺陷進(jìn)行跟蹤、分析和分類總結(jié)，以便讓項(xiàng)目的管理人員和相關(guān)的負(fù)責(zé)人能夠及時、清楚地了解產(chǎn)品當(dāng)前的質(zhì)量狀態(tài)。幫助改善開發(fā)流程、提高產(chǎn)品的開發(fā)效率促進(jìn)程序編寫的規(guī)范性、易讀性、可維護(hù)性等。軟件缺陷的定義是什么從產(chǎn)品內(nèi)部看，軟件缺陷是軟件產(chǎn)品開發(fā)或維護(hù)過程中所存在的錯誤、毛病等各種問題；從外部看，軟件缺陷是系統(tǒng)所需要實(shí)現(xiàn)的某種功能的失效或違背。因此軟件缺陷就是軟件產(chǎn)品中所存在的問題，最終表現(xiàn)為用戶所需要的功能沒有完全實(shí)現(xiàn)，沒有滿足用戶的需求。軟件錯誤的分類有哪些軟件需求錯誤功能和性能錯誤軟件結(jié)構(gòu)錯誤數(shù)據(jù)錯誤實(shí)現(xiàn)和編碼錯誤軟件集成錯誤操作系統(tǒng)調(diào)用錯誤測試定義和測試執(zhí)行錯誤一個優(yōu)秀的測試工程師需要具備的素質(zhì)有哪些目標(biāo)：發(fā)現(xiàn)軟件缺陷，并盡可能早些。探索精神，軟件測試員不害怕進(jìn)入陌生環(huán)境。障礙排除高手，善于發(fā)現(xiàn)問題的癥結(jié)。追求完美，他們力求完美，但是知道無法企及時，不去強(qiáng)求。不懈努力，不停嘗試，他們不會心存僥幸，而是盡一切可能去尋找。判斷準(zhǔn)確，要覺得測試內(nèi)容，測試時間以及看到的內(nèi)容是否是真正的軟件缺陷。老練穩(wěn)重，不害怕壞消息，知道怎樣和不夠老練的程序員合作。具有說服力，善于表達(dá)觀點(diǎn)。軟件質(zhì)量的定義是什么軟件質(zhì)量是軟件產(chǎn)品特性的總和，滿足明確或隱含要求的能力。質(zhì)量有哪6個特性1）功能性（functionality）： 制作的功能，達(dá)到設(shè)計規(guī)范和滿足使用者需求的程度。2）可靠性（reliability）： 在規(guī)定期限和條件下，仍能維持其性能水平的程度。3）易使用性（usability）： 使用者學(xué)習(xí)、操作、準(zhǔn)備輸入、理解輸出所作努力的程度。4）效率（efficiency）： 軟件執(zhí)行某項(xiàng)功能所需的計算機(jī)資源（含時間）的有效程度。5）可維護(hù)性（maintainability）： 當(dāng)環(huán)境改變或軟件發(fā)生錯誤時，執(zhí)行修改所做努力的程度。6）可移植性（portability）： 從一個電腦系統(tǒng)或環(huán)境移到另一個電腦或環(huán)境的難易程度。CMMI的中文名稱是什么，共分為幾級軟件能力成熟度模型集成，共分為5級缺陷報告的定義是什么缺陷報告是用來解釋預(yù)期結(jié)果和實(shí)際結(jié)果之間差距的文檔，包含怎么樣再現(xiàn)缺陷的場景缺陷的來源有哪些需求問題設(shè)計缺陷：功能問題系統(tǒng)和軟件架構(gòu)問題實(shí)現(xiàn)缺陷代碼問題相容性問題測試問題缺陷主要有哪些狀態(tài) New：測試人員提交新bug的狀態(tài)標(biāo)識 Open：測試經(jīng)理審核測試人員提交的bug，審核通過后將該bug狀態(tài)改為open并提交給開發(fā)經(jīng)理。開發(fā)經(jīng)理對bug進(jìn)行審核并分配給對應(yīng)的開發(fā)人員。 Fixed：開發(fā)人員已修改bug并自測通過的標(biāo)識，由開發(fā)人員修改為此狀態(tài) Closed：測試驗(yàn)證bug并通過的標(biāo)識，由測試人員修改為此狀態(tài) Rejected：開發(fā)人員認(rèn)為不是Bug、描述不清、重復(fù)、不采納所提意見建議或者測試人員提錯，從而拒絕的問題。由Bug分配人或者開發(fā)人員來設(shè)置。 Later：確認(rèn)是bug，但此bug目前暫時無法解決且對產(chǎn)品影響不大，或無法重現(xiàn)的問題等，通過會議評審可以暫緩或放入下個版本再解決Reopen：測試人員驗(yàn)證bug未通過，修改為此狀態(tài)軟件缺陷報告有哪些屬性軟件缺陷的屬性：缺陷標(biāo)識：缺陷的唯一標(biāo)識，用于識別、跟蹤、查下、排序、存儲管理等，可以使用數(shù)字序號表示標(biāo)題：對缺陷的概括性描述，方便列表、瀏覽、管理等。詳細(xì)描述：包括前提、操作步驟、預(yù)期結(jié)果、實(shí)際結(jié)果等環(huán)境：缺陷發(fā)現(xiàn)時所處的測試環(huán)境，包括操作系統(tǒng)、瀏覽器等所屬項(xiàng)目/模塊：缺陷所屬哪個具體的項(xiàng)目或模塊，要求精確定位至模塊、組件級產(chǎn)品信息：屬于哪個版本等狀態(tài)：缺陷一旦被發(fā)現(xiàn)之后，其被跟蹤過程中所處的狀態(tài)嚴(yán)重程度：因缺陷引起的故障對軟件產(chǎn)品使用或某個質(zhì)量特性的影響程度優(yōu)先級：缺陷被修復(fù)的緊急程度或先后次序，主要取決于缺陷的嚴(yán)重程度、產(chǎn)品對業(yè)務(wù)的實(shí)際影響，需要考慮開發(fā)過程的需求（對測試進(jìn)展的影響）、技術(shù)限制等因素類型：屬于哪方面的缺陷，如：功能、用戶界面、性能、接口等可能性：缺陷產(chǎn)生的頻率缺陷提交人：會和郵件地址聯(lián)系起來缺陷指定解決人：來源：缺陷產(chǎn)生的地方，如：產(chǎn)品需求定義書、設(shè)計規(guī)格說明書、代碼的具體組件或模塊，數(shù)據(jù)庫，在線幫助，用戶手冊等產(chǎn)生原因：產(chǎn)生缺陷的根本原因，包括過程、方法、工具、算法錯誤、溝通問題等，以尋求流程改進(jìn)、完善編程規(guī)范和加強(qiáng)培訓(xùn)等，有助于缺陷預(yù)防。構(gòu)建包跟蹤：用戶每日構(gòu)建軟件包跟蹤，是新發(fā)現(xiàn)的缺陷還是回歸缺陷，基準(zhǔn)是上一個軟件包版本跟蹤：用戶產(chǎn)品版本質(zhì)量特性的跟蹤，是新發(fā)現(xiàn)的缺陷還是回歸缺陷，基準(zhǔn)是上一個版本提交時間：修正時間：驗(yàn)證時間：書寫缺陷報告的基本原則（5C原則）是什么Correct（準(zhǔn)確）：每個組成部分的描述準(zhǔn)確，不會引起誤解Clear（清晰）：每個組成部分的描述清晰，易于理解Concise（簡潔）：只包含必不可少的信息，不包括任何多余的內(nèi)容。Complete（完整）：包含復(fù)現(xiàn)該缺陷的完整步驟和其他本質(zhì)信息。Consistent（一致）：按照一致的格式書寫全部缺陷報告。一般情況下，缺陷報告的組織結(jié)包括哪些內(nèi)容缺陷的標(biāo)題缺陷的基本信息，包括以下幾方面測試的軟件和硬件條件測試的軟件的版本缺陷的類型缺陷的嚴(yán)重程度缺陷的優(yōu)先級復(fù)現(xiàn)缺陷的操作步驟缺陷的實(shí)際結(jié)果描述缺陷的預(yù)期結(jié)果描述注釋文字和截取的缺陷圖像或log缺陷報告需要注意的問題有哪些盡量避免出現(xiàn)錯誤不要把幾個bug錄入到同一個id添加必要的截圖和文件完成一個bug的錄入后應(yīng)進(jìn)行檢查27,、一般缺陷嚴(yán)重等級如何劃分，并描述每個嚴(yán)重等級對應(yīng)的錯誤內(nèi)容致命(可對應(yīng)目前BUG體系中的“非常嚴(yán)重”)：致命性問題主要為：系統(tǒng)無法執(zhí)行、崩潰或嚴(yán)重資源不足、應(yīng)用模塊無法啟動或異常退出、無法測試、造成系統(tǒng)不穩(wěn)定。具體基本上可分為：○嚴(yán)重花屏○內(nèi)存泄漏○用戶數(shù)據(jù)丟失或破壞○系統(tǒng)崩潰/死機(jī)/凍結(jié)○模塊無法啟動或異常退出○嚴(yán)重的數(shù)值計算錯誤○功能設(shè)計與需求嚴(yán)重不符○其它導(dǎo)致無法測試的錯誤●嚴(yán)重（可對應(yīng)目前BUG體系中的“嚴(yán)重”）嚴(yán)重性問題主要為：影響系統(tǒng)功能或操作，主要功能存在嚴(yán)重缺陷，但不會影響到系統(tǒng)穩(wěn)定性。具體基本上可分為：○功能未實(shí)現(xiàn)○功能錯誤○系統(tǒng)刷新錯誤○語音或數(shù)據(jù)通訊錯誤○輕微的數(shù)值計算錯誤○系統(tǒng)所提供的功能或服務(wù)受明顯的影響●一般（可對應(yīng)于目前BUG體系中的“普通”）一般性問題主要為：界面、性能缺陷具體基本上可分為：○操作界面錯誤（包括數(shù)據(jù)窗口內(nèi)列名定義、含義是否一致）○邊界條件下錯誤○提示信息錯誤（包括未給出信息、信息提示錯誤等）○長時間操作無進(jìn)度提示○系統(tǒng)未優(yōu)化（性能問題）○光標(biāo)跳轉(zhuǎn)設(shè)置不好，鼠標(biāo)（光標(biāo)）定位錯誤●提示（可對應(yīng)于目前BUG體系中的“輕微及建議”）提示性問題主要為：易用性及建議性問題具體基本上可分為：○界面格式等不規(guī)范○輔助說明描述不清楚○操作時未給用戶提示○可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標(biāo)志○個別不影響產(chǎn)品理解的錯別字○文字排列不整齊等一些小問題○建議缺陷優(yōu)先級常用的劃分方法是什么P1立即解決：缺陷導(dǎo)致系統(tǒng)幾乎不能運(yùn)行、使用或嚴(yán)重妨礙測試的執(zhí)行，需立即修正、盡快修正；P2高優(yōu)先級：缺陷嚴(yán)重，影響測試，需要優(yōu)先考慮修正，如不超過24小時；P3正常排隊(duì)：缺陷需要修正，但可以正常排隊(duì)等待修正；P4低優(yōu)先級：缺陷可以在開發(fā)人員有時間的時候被修正，如沒有時間，可以不修正列出一些控件的名稱菜單、按鈕、對話框、消息提示框、文本框、單選按鈕、復(fù)選按鈕、工具欄、懸浮框、托盤、下拉列表等。測試用例的定義測試用例是一系列的測試步驟，用以幫助測試人員發(fā)現(xiàn)缺陷描述測試用例設(shè)計的完整過程需求分析+需求變更的維護(hù)工作根據(jù)需求，得出測試需求設(shè)計測試方案，評審測試方案測試方案通過評審后，設(shè)計測試用例，再對測試用例進(jìn)行評審測試用例的元素有哪些用例ID、標(biāo)題、優(yōu)先級、預(yù)置條件、操作步驟、預(yù)期結(jié)果等測試用例設(shè)計的步驟軟件測試用例的設(shè)計遵守下列4部曲：制定測試用例設(shè)計的策略和思想，在測試方案中描述出來設(shè)計測試用例的框架，也就是測試用例的結(jié)構(gòu)細(xì)節(jié)結(jié)構(gòu)，逐步設(shè)計出具體的測試用例通過測試用例的評審，不斷優(yōu)化測試用例測試用例設(shè)計的基本思想是什么設(shè)計測試用例時，要尋求系統(tǒng)設(shè)計、功能設(shè)計的弱點(diǎn)。測試用例需要確切地反映功能設(shè)計中可能存在的各種問題，而不要簡單拷貝產(chǎn)品規(guī)格設(shè)計說明書的內(nèi)容。設(shè)計正面的測試用例，應(yīng)該參照設(shè)計規(guī)格說明書，根據(jù)關(guān)聯(lián)的功能、操作路徑等設(shè)計。而對孤立的功能則直接按功能設(shè)計測試用例。基本事件的測試用例應(yīng)包含所有需要實(shí)現(xiàn)的需求功能，覆蓋率達(dá)100%。設(shè)計負(fù)面的、異常的測試用例，如考慮錯誤的或者異常的輸入，往往可以發(fā)現(xiàn)更多的軟件缺陷，這顯得更為重要。例如，在進(jìn)行電子郵件地址校驗(yàn)的時候，考慮錯誤的、不合法的（如沒有@符號的輸入）或者帶有異常字符（單引號、斜杠、雙引號等）的電子郵件地址輸入，尤其是在做web頁面測試的時候，通常會出現(xiàn)因一些字符轉(zhuǎn)義問題而造成異常情況。測試用例執(zhí)行的步驟有哪些審核測試內(nèi)容ReviewContent.準(zhǔn)備測試環(huán)境PrepareEnvironment.測試用例步驟執(zhí)行Testcasestepexecution.檢查執(zhí)行結(jié)果Conductresultcheck.測試結(jié)果報告Testresultreport.測試用例的更新Testcaseupdate.黑盒測試用例設(shè)計有哪些方法等價類劃分法、邊界值分析法、因果圖法、功能圖法、錯誤推測法、正交實(shí)驗(yàn)設(shè)計法、場景設(shè)計法按照覆蓋度由低到高寫出白盒測試用例設(shè)計的方法語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋。寫出全球化、國際化和本地化的簡稱和它們之間的關(guān)系全球化：G11Nglobalization的簡寫國際化：I18Ninternationalization的簡寫本地化：L10Nlocalization的簡寫全球化=國際化+本地化國際化測試的特殊需求有哪些支持unicode字符集。如建立用于本地字符編碼（ANSI或OEM）和unicode之間變換的字符映射表，既可以處理類似于英文的單字節(jié)語言，又能處理類似于中文、日文等雙字節(jié)或多字節(jié)語言。支持不同時區(qū)的設(shè)定、顯示和切換分離程序代碼和顯示內(nèi)容（文本、圖片、對話框和按鈕等）。如建立資源文件（*.rc）來存儲這些內(nèi)容。消除硬代碼（指程序代碼中所包含的一些特定的數(shù)據(jù)），而盡量使用變量處理，將數(shù)據(jù)存儲在數(shù)據(jù)庫或初始化文件中。使用Headerfiles定義經(jīng)常被調(diào)用的代碼段。彈出的窗口、按鈕、菜單等的尺寸具有自動伸縮性或可靈活地調(diào)整，以適應(yīng)不同語言顯示文本的長度變化。吃吃各個國家的鍵盤設(shè)置，但要統(tǒng)一熱鍵。支持文字排序和大小寫轉(zhuǎn)換。支持各國家的度量衡、時間、貨幣單位等不同格式的顯示方式。支持顏色字體等自定義。擁有國際化用戶界面設(shè)計。軟件國際化的測試就是驗(yàn)證軟件產(chǎn)品是否支持上述特性。本地化測試的基本內(nèi)容是什么功能性測試數(shù)據(jù)格式測試可用性測試翻譯驗(yàn)證測試兼容性測試文檔測試42、一套完整的測試應(yīng)該由哪些階段組成測試計劃、測試設(shè)計與開發(fā)、測試實(shí)施、測試評審與測試結(jié)論43、如何理解壓力、負(fù)載、性能測試性能測試是一個較大的范圍，實(shí)際上性能測試本身包含了性能、強(qiáng)度、壓力、負(fù)載等多方面的測試內(nèi)容。壓力測試是對服務(wù)器的穩(wěn)定性以及負(fù)載能力等方面的測試，是一種很平常的測試，增大訪問系統(tǒng)的用戶數(shù)量、或者幾個用戶進(jìn)行大數(shù)據(jù)量操作都是壓力測試。而負(fù)載測試是壓力相對較大的測試，主要是測試系統(tǒng)在一種或幾種極限條件下的相應(yīng)能力，是性能測試的重要部分。100個用戶對系統(tǒng)進(jìn)行連續(xù)半個小時的訪問可以看做壓力測試，那么連續(xù)訪問8個小時就可以認(rèn)為負(fù)載測試，1000個用戶連續(xù)訪問系統(tǒng)1個小時也可以看做是負(fù)載測試。實(shí)際上壓力測試和負(fù)載測試沒有明顯的區(qū)分。測試人員應(yīng)該站在關(guān)注整體性能的高度上來對系統(tǒng)進(jìn)行測試。44、所有的軟件缺陷都能修復(fù)嗎所有的軟件缺陷都要修復(fù)嗎從技術(shù)上講，所有的軟件缺陷都是能夠修復(fù)的，但是沒有必要修復(fù)所有的軟件缺陷。測試人員要做的是能夠正確判斷什么時候不能追求軟件的完美。對于整個項(xiàng)目團(tuán)隊(duì)，要做的是對每一個軟件缺陷進(jìn)行取舍，根據(jù)風(fēng)險決定哪些缺陷要修復(fù)。發(fā)生這種現(xiàn)象的主要原因如下：沒有足夠的時間資源。在任何一個項(xiàng)目中，通常情況下開發(fā)人員和測試人員都是不夠用的。而且在項(xiàng)目中沒有預(yù)算足夠的回歸測試時間，再加上修改缺陷可能引入的新缺陷，因此在交付期限的強(qiáng)大壓力下，必須放棄某些缺陷的修改。有些缺陷只是特殊情況下出現(xiàn)，這種缺陷處于商業(yè)利益考慮，可以在以后升級中進(jìn)行修復(fù)不是缺陷的缺陷。我們經(jīng)常會碰到某些功能方面的問題被當(dāng)成缺陷來處理，這類問題可以以后有時間考慮