關(guān)于測試用例的設(shè)計(jì)的

關(guān)于測試用例的設(shè)計(jì)的：如何設(shè)計(jì)編制軟件測試用例文章出處：CCW鄧若二發(fā)布時(shí)間：2006-09-29如何設(shè)計(jì)編制軟件測試用例

一、測試用例是軟件測試的核心

二、什么叫測試用例

三、編制測試用例

四、測試用例在軟件測試中的作用

五、相關(guān)問題隨著中國軟件業(yè)的日益壯大和逐步走向成熟，軟件測試也在不斷發(fā)展。從最初的由軟件編程人員兼職測試到軟件公司組建獨(dú)立專職測試部門。測試工作也從簡單測試演變?yōu)榘ǎ壕幹茰y試計(jì)劃、編寫測試用例、準(zhǔn)備測試數(shù)據(jù)、編寫測試腳本、實(shí)施測試、測試評(píng)估等多項(xiàng)內(nèi)容的正規(guī)測試。測試方式則由單純手工測試發(fā)展為手工、自動(dòng)兼之，并有向第三方專業(yè)測試公司發(fā)展的趨勢。一、測試用例是軟件測試的核心

軟件測試的重要性是毋庸置疑的。但如何以最少的人力、資源投入，在最短的時(shí)間內(nèi)完成測試，發(fā)現(xiàn)軟件系統(tǒng)的缺陷，保證軟件的優(yōu)良品質(zhì)，則是軟件公司探索和追求的目標(biāo)。每個(gè)軟件產(chǎn)品或軟件開發(fā)項(xiàng)目都需要有一套優(yōu)秀的測試方案和測試方法。

影響軟件測試的因素很多，例如軟件本身的復(fù)雜程度、開發(fā)人員(包括分析、設(shè)計(jì)、編程和測試的人員)的素質(zhì)、測試方法和技術(shù)的運(yùn)用等等。因?yàn)橛行┮蛩厥强陀^存在的，無法避免。有些因素則是波動(dòng)的、不穩(wěn)定的，例如開發(fā)隊(duì)伍是流動(dòng)的，有經(jīng)驗(yàn)的走了，新人不斷補(bǔ)充進(jìn)來；一個(gè)具體的人工作也受情緒等影響，等等。如何保障軟件測試質(zhì)量的穩(wěn)定？有了測試用例，無論是誰來測試，參照測試用例實(shí)施，都能保障測試的質(zhì)量?？梢园讶藶橐蛩氐挠绊憸p少到最小。即便最初的測試用例考慮不周全，隨著測試的進(jìn)行和軟件版本更新，也將日趨完善。

因此測試用例的設(shè)計(jì)和編制是軟件測試活動(dòng)中最重要的。測試用例是測試工作的指導(dǎo)，是軟件測試的必須遵守的準(zhǔn)則。更是軟件測試質(zhì)量穩(wěn)定的根本保障。二、什么叫測試用例

測試用例(TestCase)目前沒有經(jīng)典的定義。比較通常的說法是：指對(duì)一項(xiàng)特定的軟件產(chǎn)品進(jìn)行測試任務(wù)的描述，體現(xiàn)測試方案、方法、技術(shù)和策略。內(nèi)容包括測試目標(biāo)、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預(yù)期結(jié)果、測試腳本等，并形成文檔。[Kiki]目前有以下一些解釋：

"Asetoftestinputs,executionconditions,andexpectedresultsdevelopedforaparticularobjective,suchastoexerciseaparticularprogrampathortoverifycompliancewithaspecificrequirement."－IEEEStandard610(1990)"Testcasesarewaysofstatinghowwewillverifywhatthesystemactuallydoes,andthereforetheyshouldbetrackedandmaintainedasrequirements.Weintroducethenotionofrequirementstypetoseparatethesedifferentexpressionsofrequirements."-RUP

不同類別的軟件，測試用例是不同的。不同于諸如系統(tǒng)、工具、控制、游戲軟件，管理軟件的用戶需求更加不統(tǒng)一，變化更大、更快。筆者主要從事企業(yè)管理軟件的測試。因此我們的做法是把測試數(shù)據(jù)和測試腳本從測試用例中劃分出來。測試用例更趨于是針對(duì)軟件產(chǎn)品的功能、業(yè)務(wù)規(guī)則和業(yè)務(wù)處理所設(shè)計(jì)的測試方案。對(duì)軟件的每個(gè)特定功能或運(yùn)行操作路徑的測試構(gòu)成了一個(gè)個(gè)測試用例。三、編制測試用例

著重介紹一些編制測試用例的具體做法。

1、測試用例文檔

編寫測試用例文檔應(yīng)有文檔模板，須符合內(nèi)部的規(guī)范要求。測試用例文檔將受制于測試用例管理軟件的約束。

軟件產(chǎn)品或軟件開發(fā)項(xiàng)目的測試用例一般以該產(chǎn)品的軟件模塊或子系統(tǒng)為單位，形成一個(gè)測試用例文檔，但并不是絕對(duì)的。

測試用例文檔由簡介和測試用例兩部分組成。簡介部分編制了測試目的、測試范圍、定義術(shù)語、參考文檔、概述等。測試用例部分逐一列示各測試用例。每個(gè)具體測試用例都將包括下列詳細(xì)信息：用例編號(hào)、用例名稱、測試等級(jí)、入口準(zhǔn)則、驗(yàn)證步驟、期望結(jié)果(含判斷標(biāo)準(zhǔn))、出口準(zhǔn)則、注釋等。以上內(nèi)容涵蓋了測試用例的基本元素：測試索引，測試環(huán)境，測試輸入，測試操作，預(yù)期結(jié)果，評(píng)價(jià)標(biāo)準(zhǔn)。[Kiki]對(duì)測試用例劃分等級(jí)有很多感觸：許多時(shí)候當(dāng)開發(fā)部門應(yīng)客戶需要或發(fā)現(xiàn)嚴(yán)重bug而快速發(fā)布一個(gè)新版本時(shí)，要求在限定的時(shí)間內(nèi)快速測試以確保系統(tǒng)基本功能正常時(shí)，有些測試人員不知如何從現(xiàn)有的測試用例中挑選測試用例，更有甚者還是按順序測試。所以一定需要?jiǎng)澐旨?jí)別，方便BVT或上述的測試。具體參加：《快速劃分測試用例的優(yōu)先級(jí)》2、測試用例的設(shè)置

我們?cè)缙诘臏y試用例是按功能設(shè)置用例。后來引進(jìn)了路徑分析法，按路徑設(shè)置用例。目前演變?yōu)榘垂δ?、路徑混合模式設(shè)置用例。

按功能測試是最簡捷的，按用例規(guī)約遍歷測試每一功能。

對(duì)于復(fù)雜操作的程序模塊，其各功能的實(shí)施是相互影響、緊密相關(guān)、環(huán)環(huán)相扣的，可以演變出數(shù)量繁多的變化。沒有嚴(yán)密的邏輯分析，產(chǎn)生遺漏是在所難免。路徑分析是一個(gè)很好的方法，其最大的優(yōu)點(diǎn)是在于可以避免漏測試。

但路徑分析法也有局限性。在一個(gè)非常簡單字典維護(hù)模塊就存在十余條路徑。一個(gè)復(fù)雜的模塊會(huì)有幾十到上百條路徑是不足為奇的。筆者以為這是路徑分析比較合適的使用規(guī)模。若一個(gè)子系統(tǒng)有十余個(gè)或更多的模塊，這些模塊相互有關(guān)聯(lián)。再采用路徑分析法，其路徑數(shù)量成幾何級(jí)增長，達(dá)5位數(shù)或更多，就無法使用了。那么子系統(tǒng)模塊間的測試路徑或測試用例還是要靠傳統(tǒng)方法來解決。這是按功能、路徑混合模式設(shè)置用例的由來。

3、設(shè)計(jì)測試用例

測試用例可以分為基本事件、備選事件和異常事件。設(shè)計(jì)基本事件的用例，應(yīng)該參照用例規(guī)約(或設(shè)計(jì)規(guī)格說明書)，根據(jù)關(guān)聯(lián)的功能、操作按路徑分析法設(shè)計(jì)測試用例。而對(duì)孤立的功能則直接按功能設(shè)計(jì)測試用例?；臼录臏y試用例應(yīng)包含所有需要實(shí)現(xiàn)的需求功能，覆蓋率達(dá)100%。

設(shè)計(jì)備選事件和異常事件的用例，則要復(fù)雜和困難得多。例如，字典的代碼是唯一的，不允許重復(fù)。測試需要驗(yàn)證：字典新增程序中已存在有關(guān)字典代碼的約束，若出現(xiàn)代碼重復(fù)必須報(bào)錯(cuò)，并且報(bào)錯(cuò)文字正確。往往在設(shè)計(jì)編碼階段形成的文檔對(duì)備選事件和異常事件分析描述不夠詳盡。而測試本身則要求驗(yàn)證全部非基本事件，并同時(shí)盡量發(fā)現(xiàn)其中的軟件缺陷。

可以采用軟件測試常用的基本方法：等價(jià)類劃分法、邊界值分析法、錯(cuò)誤推測法、因果圖法、邏輯覆蓋法等設(shè)計(jì)測試用例。視軟件的不同性質(zhì)采用不同的方法。如何靈活運(yùn)用各種基本方法來設(shè)計(jì)完整的測試用例，并最終實(shí)現(xiàn)暴露隱藏的缺陷，全憑測試設(shè)計(jì)人員的豐富經(jīng)驗(yàn)和精心設(shè)計(jì)。四、測試用例在軟件測試中的作用1、指導(dǎo)測試的實(shí)施

測試用例主要適用于集成測試、系統(tǒng)測試和回歸測試。在實(shí)施測試時(shí)測試用例作為測試的標(biāo)準(zhǔn)，測試人員一定要按照測試用例嚴(yán)格按用例項(xiàng)目和測試步驟逐一實(shí)施測試。并對(duì)測試情況記錄在測試用例管理軟件中，以便自動(dòng)生成測試結(jié)果文檔。

根據(jù)測試用例的測試等級(jí)，集成測試應(yīng)測試那些用例，系統(tǒng)測試和回歸測試又該測試那些用例，在設(shè)計(jì)測試用例時(shí)都已作明確規(guī)定，實(shí)施測試時(shí)測試人員不能隨意作變動(dòng)。2、規(guī)劃測試數(shù)據(jù)的準(zhǔn)備

在我們的實(shí)踐中測試數(shù)據(jù)是與測試用例分離的。按照測試用例配套準(zhǔn)備一組或若干組測試原始數(shù)據(jù)，以及標(biāo)準(zhǔn)測試結(jié)果。尤其象測試報(bào)表之類數(shù)據(jù)集的正確性，按照測試用例規(guī)劃準(zhǔn)備測試數(shù)據(jù)是十分必須的。

除正常數(shù)據(jù)之外，還必須根據(jù)測試用例設(shè)計(jì)大量邊緣數(shù)據(jù)和錯(cuò)誤數(shù)據(jù)。3、編寫測試腳本的"設(shè)計(jì)規(guī)格說明書"

為提高測試效率，軟件測試已大力發(fā)展自動(dòng)測試。自動(dòng)測試的中心任務(wù)是編寫測試腳本。如果說軟件工程中軟件編程必須有設(shè)計(jì)規(guī)格說明書，那么測試腳本的設(shè)計(jì)規(guī)格說明書就是測試用例。4、評(píng)估測試結(jié)果的度量基準(zhǔn)

完成測試實(shí)施后需要對(duì)測試結(jié)果進(jìn)行評(píng)估，并且編制測試報(bào)告。判斷軟件測試是否完成、衡量測試質(zhì)量需要一些量化的結(jié)果。例：測試覆蓋率是多少、測試合格率是多少、重要測試合格率是多少，等等。以前統(tǒng)計(jì)基準(zhǔn)是軟件模塊或功能點(diǎn)，顯得過于粗糙。采用測試用例作度量基準(zhǔn)更加準(zhǔn)確、有效。5、分析缺陷的標(biāo)準(zhǔn)

通過收集缺陷，對(duì)比測試用例和缺陷數(shù)據(jù)庫，分析確證是漏測還是缺陷復(fù)現(xiàn)。漏測反映了測試用例的不完善，應(yīng)立即補(bǔ)充相應(yīng)測試用例，最終達(dá)到逐步完善軟件質(zhì)量。而已有相應(yīng)測試用例，則反映實(shí)施測試或變更處理存在問題。

五、相關(guān)問題1、測試用例的評(píng)審

測試用例是軟件測試的準(zhǔn)則，但它并不是一經(jīng)編制完成就成為準(zhǔn)則。測試用例在設(shè)計(jì)編制過程中要組織同級(jí)互查。完成編制后應(yīng)組織專家評(píng)審，需獲得通過才可以使用。評(píng)審委員會(huì)可由項(xiàng)目負(fù)責(zé)人、測試、編程、分析設(shè)計(jì)等有關(guān)人員組成，也可邀請(qǐng)客戶代表參加。2、測試用例的修改更新

測試用例在形成文檔后也還需要不斷完善。主要來自三方面的緣故：第一、在測試過程中發(fā)現(xiàn)設(shè)計(jì)測試用例時(shí)考慮不周，需要完善；第二、在軟件交付使用后反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成；第三、軟件自身的新增功能以及軟件版本的更新，測試用例也必須配套修改更新。

一般小的修改完善可在原測試用例文檔上修改，但文檔要有更改記錄。軟件的版本升級(jí)更新，測試用例一般也應(yīng)隨之編制升級(jí)更新版本。3、測試用例的管理軟件

運(yùn)用測試用例還需配備測試用例管理軟件。它的主要功能有三個(gè)：第一、能將測試用例文檔的關(guān)鍵內(nèi)容，如編號(hào)、名稱等等自動(dòng)導(dǎo)入管理數(shù)據(jù)庫，形成與測試用例文檔完全對(duì)應(yīng)的記錄；第二、可供測試實(shí)施時(shí)及時(shí)輸入測試情況；第三、最終實(shí)現(xiàn)自動(dòng)生成測試結(jié)果文檔，包含各測試度量值，測試覆蓋表和測試通過或不通過的測試用例清單列表。

有了管理軟件，測試人員無論是編寫每日的測試工作日志、還是出軟件測試報(bào)告，都會(huì)變得輕而易舉。

開發(fā)一個(gè)軟件產(chǎn)品，會(huì)發(fā)布多個(gè)版本，伴隨著測試用例（Testcase）的不斷維護(hù),使測試用例不斷完善并與產(chǎn)品功能、特性(features)的變化保持一致，所以測試用例是和產(chǎn)品版本相關(guān)聯(lián)的。特別是對(duì)提供軟件服務(wù)的軟件產(chǎn)品，多個(gè)版本常常共存，為客戶提供服務(wù)，這時(shí)多個(gè)版本的測試用例也是并存的，所以在新建、修改、刪除測試用例時(shí)要十分小心，并有相應(yīng)的規(guī)則。

根據(jù)產(chǎn)品特性和testcase一致性，分下面幾種情況分別處理：1.產(chǎn)品特性沒變，只是根據(jù)LateDiscoveryBug或RemedyTicket來完善testcase，只有這時(shí)候可以修改Testcase,也就意味著當(dāng)前修改的testcase，對(duì)目前和以前的版本都有效。2.原有產(chǎn)品特性發(fā)生了變化，不是newfeature,而是enhancedfeatures（功能增強(qiáng)）,這時(shí)候原有的testcase只對(duì)先前版本（如version1.0、2.0)有效，而對(duì)新的版本（如version3.0)無效，這時(shí)絕不能修改testcase，只能增加新的testcase，這一點(diǎn)很重要。原有的testcase依然對(duì)原有版本有效（如version1.0、2.0)。3.原有功能取消了，這時(shí)只要在新版本上使之對(duì)應(yīng)的testcase置為inactive（無效）。4.完全新增加的特性，大家比較清楚，增加對(duì)應(yīng)的、新的測試用例。這樣，新舊版本的相同測試用例得到一致的維護(hù)，測試用例數(shù)也不會(huì)成幾、十幾倍的增加，可以真正保證testcase

的完整性、有效性！測試用例設(shè)計(jì)的誤區(qū)文章出處：51testing論壇發(fā)布時(shí)間：2005-10-191、能發(fā)現(xiàn)到目前為止沒有發(fā)現(xiàn)的缺陷的用例是好的用例：

首先要申明，其實(shí)這句話是十分有道理的，但我發(fā)現(xiàn)很多人都曲解了這句話的原意，一心要設(shè)計(jì)出發(fā)現(xiàn)“難于發(fā)現(xiàn)的缺陷”而陷入盲目的片面中去，忘記了測試的目的所在，這是十分可怕的。我傾向于將測試用例當(dāng)作一個(gè)集合來認(rèn)識(shí)，對(duì)它的評(píng)價(jià)也只能對(duì)測試用例的集合來進(jìn)行，測試本身是一種“V&V”的活動(dòng)，測試需要保證以下兩點(diǎn)：

*程序做了它應(yīng)該做的事情

*程序沒有做它不該做的事情

因此，作為測試實(shí)施依據(jù)的測試用例，必須要能完整覆蓋測試需求，而不應(yīng)該針對(duì)單個(gè)的測試用例去評(píng)判好壞。

2、測試用例應(yīng)該詳細(xì)記錄所有的操作信息，使一個(gè)沒有接觸過系統(tǒng)的人員也能進(jìn)行測試；

不知道國內(nèi)有沒有公司真正做到這點(diǎn)，或者說，不知道有國內(nèi)沒有公司能夠?qū)⒚總€(gè)測試用例都寫得如此詳細(xì)。在我的測試經(jīng)歷中，對(duì)測試用例描述的詳細(xì)和復(fù)雜程度也曾有過很多的彷徨。寫得太簡單吧，除了自己沒人能夠執(zhí)行，寫得太詳細(xì)吧，消耗在測試用例維護(hù)（別忘了，測試用例是動(dòng)態(tài)的，一旦測試環(huán)境、需求、設(shè)計(jì)、實(shí)現(xiàn)發(fā)生了變化，測試用例都需要相應(yīng)發(fā)生變化）上的時(shí)間實(shí)在是太驚人，在目前國內(nèi)大部分軟件公司的測試資源都不足的情況下，恐怕很難實(shí)現(xiàn)。但我偏偏就能遇到一些這樣的老總或者是項(xiàng)目負(fù)責(zé)人，甚至是測試工程師本身，全然不顧實(shí)際的資源情況，一定要寫出“沒有接觸過系統(tǒng)的人員也能進(jìn)行測試”的用例。

在討論這個(gè)問題之前，我們可以先考慮一下測試的目的。測試的目的是盡可能發(fā)現(xiàn)程序中存在的缺陷，測試活動(dòng)本身也可以被看作是一個(gè)Project，也需要在給定的資源條件下盡可能達(dá)成目標(biāo)，根據(jù)我個(gè)人的經(jīng)驗(yàn)，大部分的國內(nèi)軟件公司在測試方面配備的資源都是不足夠的，因此我們必須在測試計(jì)劃階段明確測試的目標(biāo)，一切圍繞測試的目標(biāo)進(jìn)行。

除了資源上的約束外，測試用例的詳細(xì)程度也需要根據(jù)需要確定。如果測試用例的執(zhí)行者、測試用例設(shè)計(jì)者、測試活動(dòng)相關(guān)人對(duì)系統(tǒng)了解都很深刻，那測試用例就沒有必要太詳細(xì)了，文檔的作用本來就在于溝通，只要能達(dá)到溝通的目的就OK。

在我擔(dān)任測試經(jīng)理的項(xiàng)目中，在測試計(jì)劃階段，一般給予測試設(shè)計(jì)30%-40%左右的時(shí)間，測試設(shè)計(jì)工程師能夠根據(jù)項(xiàng)目的需要自行確定用例的詳細(xì)程度，在測試用例的評(píng)審階段由參與評(píng)審的相關(guān)人對(duì)其把關(guān)。

3、測試用例設(shè)計(jì)是一勞永逸的事情；

這句話擺在這里，我想沒有一個(gè)人會(huì)認(rèn)可，但在實(shí)際情況中，卻經(jīng)常能發(fā)現(xiàn)這種想法的影子。我曾經(jīng)參與過一個(gè)項(xiàng)目，軟件需求和設(shè)計(jì)已經(jīng)變更了多次，但測試用例卻沒有任何修改。導(dǎo)致的直接結(jié)果是新加入的測試工程師在執(zhí)行測試用例時(shí)不知所措，間接的后果是測試用例成了廢紙一堆，開發(fā)人員在多次被無效的缺陷報(bào)告打擾后，對(duì)測試人員不屑一顧。

這個(gè)例子可能有些極端，但測試用例與需求和設(shè)計(jì)不同步的情況在實(shí)際開發(fā)過程中確是屢見不鮮的，測試用例文檔是“活的”文檔，這一點(diǎn)應(yīng)該被測試工程師牢記。

4、測試用例不應(yīng)該包含實(shí)際的數(shù)據(jù)；

測試用例是“一組輸入、執(zhí)行條件、預(yù)期結(jié)果”、毫無疑問地應(yīng)該包括清晰的輸入數(shù)據(jù)和預(yù)期輸出，沒有測試數(shù)據(jù)的用例最多只具有指導(dǎo)性的意義，不具有可執(zhí)行性。當(dāng)然，測試用例中包含輸入數(shù)據(jù)會(huì)帶來維護(hù)、與測試環(huán)境同步之類的問題，關(guān)于這一點(diǎn)，《EffectiveSoftwareTest》一書中提供了詳細(xì)的測試用例、測試數(shù)據(jù)的維護(hù)方法，可以參考。

5、測試用例中不需要明顯的驗(yàn)證手段；

我見過很多測試工程師編寫的測試用例中，“預(yù)期輸出”僅描述為程序的可見行為，其實(shí)，“預(yù)期結(jié)果”的含義并不只是程序的可見行為。例如，對(duì)一個(gè)訂貨系統(tǒng)，輸入訂貨數(shù)據(jù)，點(diǎn)擊“確定”按鈕后，系統(tǒng)提示“訂貨成功”，這樣是不是一個(gè)完整的用例呢？是不是系統(tǒng)輸出的“訂貨成功”就應(yīng)該作為我們唯一的驗(yàn)證手段呢？顯然不是。訂貨是否成功還需要查看相應(yīng)的數(shù)據(jù)記錄是否更新，因此，在這樣的一個(gè)用例中，還應(yīng)該包含對(duì)測試結(jié)果的顯式的驗(yàn)證手段：在數(shù)據(jù)庫中執(zhí)行查詢語句進(jìn)行查詢，看查詢結(jié)果是否與預(yù)期的一致。細(xì)說軟件測試錯(cuò)誤文章出處：本地化測試網(wǎng)崔啟亮發(fā)布時(shí)間：2005-10-25概述

軟件本地化測試的測試對(duì)象是本地化的軟件，需要在本地化的操作系統(tǒng)上進(jìn)行。雖然本地化的軟件是基于源程序軟件創(chuàng)建的，但二者的測試內(nèi)容和重點(diǎn)具有很大的不同。

一般地，二者的不同在于：第一，測試順序不同。首先要現(xiàn)對(duì)源程序軟件進(jìn)行測試，然后再創(chuàng)建本地化軟件，測試本地化軟件。第二，測試內(nèi)容和重點(diǎn)不同。源程序軟件主要測試功能和性能，結(jié)合軟件界面的測試。本地化軟件的測試，更注重因本地化引起的錯(cuò)誤，例如，翻譯是否正確，本地化的界面是否美觀，本地化后的功能是否與源語言軟件保持一致。第三，測試環(huán)境不同。源程序軟件測試通常在源語言的操作系統(tǒng)上進(jìn)行。本地化軟件在本地化的操作系統(tǒng)上進(jìn)行。

本地化測試過程中，需要同時(shí)運(yùn)行源程序軟件和本地化軟件，依照源程序軟件結(jié)果作為本地化軟件的主要參考。

軟件本地化的錯(cuò)誤類型

軟件本地化的錯(cuò)誤主要分為兩大類：第一、由于源程序軟件編碼錯(cuò)誤引起的；第二，由于軟件本地化引起的。其中由于軟件本地化產(chǎn)生的錯(cuò)誤類型包括語句沒有翻譯、翻譯錯(cuò)誤、控件布局錯(cuò)誤。對(duì)于東亞語系軟件，可能存在雙字節(jié)字符顯示錯(cuò)誤等。

綜合分析本地化軟件的錯(cuò)誤類別，可以歸結(jié)為四種類型：翻譯錯(cuò)誤，功能錯(cuò)誤，界面錯(cuò)誤，雙字節(jié)錯(cuò)誤。

每種類型的錯(cuò)誤的數(shù)量不同，這與源程序軟件和本地化軟件的質(zhì)量有密切關(guān)系。如果源程序軟件沒有經(jīng)過完整的測試，包括功能測試和本地化性能測試，那么本地化軟件中就將存在很多功能錯(cuò)誤、界面錯(cuò)誤、雙字節(jié)錯(cuò)誤。如果本地化軟件沒有經(jīng)過良好的本地化處理，將會(huì)產(chǎn)生很多翻譯錯(cuò)誤和界面錯(cuò)誤。

揭密軟件本地化錯(cuò)誤

下面對(duì)本地化軟件的錯(cuò)誤的四種典型類型進(jìn)行分類討論，探討錯(cuò)誤的表現(xiàn)特征，產(chǎn)生的原因，測試要求，發(fā)現(xiàn)錯(cuò)誤的方法。

翻譯錯(cuò)誤：

(1)產(chǎn)生原因：

1)翻譯人員不熟悉翻譯要求。

2)翻譯人員工作疏漏。

3)用戶界面的翻譯與標(biāo)準(zhǔn)詞匯表不一致。

(2)表現(xiàn)特征：

1)應(yīng)該翻譯而沒有翻譯的英文字符。

2)不應(yīng)該翻譯而翻譯的中文字詞。

3)錯(cuò)誤翻譯的字詞。

4)只在本地化版本中存在該類型錯(cuò)誤。

5)較多隱含在對(duì)話框各控件以及幫助文檔中。

(3)測試要求：

1)明確需要翻譯和不需要翻譯的內(nèi)容。

2)明確正確的翻譯方式。

3)根據(jù)術(shù)語表，確認(rèn)術(shù)語翻譯的正確性與一致性。

(4)測試方法：

1)主要同時(shí)打開中英文版本，執(zhí)行相同的操作。

2)結(jié)合標(biāo)準(zhǔn)界面詞匯翻譯表，參照對(duì)比。

(5)說明：

1)對(duì)于對(duì)話框，如果含有下拉列表框，要打開列表框查看全部項(xiàng)。

2)特別要注意選項(xiàng)中開關(guān)類翻譯錯(cuò)誤。

功能錯(cuò)誤：

(1)產(chǎn)生原因：

1)軟件編碼錯(cuò)誤。

2)錯(cuò)誤本地化，如將程序中的變量進(jìn)行了翻譯等。

(2)表現(xiàn)特征：

1)不能實(shí)現(xiàn)設(shè)計(jì)要求的功能。

2)產(chǎn)生與設(shè)計(jì)要求不符合的結(jié)果。

3)英文和中文都存在同樣的錯(cuò)誤。

4)可能隱含在軟件的任何位置或任何操作步驟中。

(3)測試要求：

1)保證輸入數(shù)據(jù)正確，或者打開了正確的測試用例。

2)明確正確的輸出結(jié)果和中間數(shù)據(jù)數(shù)值及格式。

(4)測試方法：

1)對(duì)于菜單項(xiàng)或工具欄按鈕，通過全面測試各個(gè)選項(xiàng)，認(rèn)真觀察每一步是否正確執(zhí)行，輸出結(jié)果（包括格式和數(shù)值）是否正確。

2)對(duì)于一個(gè)命令中的多個(gè)并列選項(xiàng)，采用路徑跟蹤法，按分支順序測試嵌套的全部子項(xiàng)。

3)對(duì)于對(duì)話框，可以逐個(gè)執(zhí)行各按鈕，各個(gè)列表選項(xiàng)等觀察執(zhí)行結(jié)果。

(5)說明：

1)特別注意不同選項(xiàng)、不同按鈕相互操作的影響。

2)注意檢查快捷鍵是否遺漏，是否多余，是否不同，是否起作用。

布局錯(cuò)誤：

(1)產(chǎn)生原因：

1)軟件本地化后，由于源語言和本地化語言的表達(dá)方式不同，本地化后的字符數(shù)與源語言不同，每個(gè)字符所占空間尺寸不同，使得在英文版本正確顯示的控件字符，可能在本地化版本顯示不正確。

2)本地化人員調(diào)整程序資源不當(dāng)引起，例如，對(duì)話框及其控件高度或?qū)挾鹊牟徽_調(diào)整。

(2)表現(xiàn)特征：

1)控件相互重疊或排列不均勻。

2)控件中字符顯示不完整。

3)主要出現(xiàn)在本地化版本的對(duì)話框中。

(3)測試要求：

1)對(duì)話框中控件布局均勻，字符顯示完整正確。

2)對(duì)話框中控件數(shù)量相等，沒有多余或丟失的控件

(4)測試方法：

1)執(zhí)行將要打開對(duì)話框的菜單或工具欄按鈕，觀察打開對(duì)話框中的控件布局。

2)對(duì)比檢查源語言軟件和本地化軟件對(duì)應(yīng)的對(duì)話框中控件的數(shù)量

(5)說明：

1)可能在執(zhí)行不同的操作后，如選擇了不同單選或復(fù)選按鈕后，編輯框顯示重疊等。

2)執(zhí)行后帶省略號(hào)的菜單或命令按鈕，將會(huì)顯示對(duì)話框。

雙字節(jié)錯(cuò)誤：

(1)產(chǎn)生原因：

1)源程序在設(shè)計(jì)時(shí)沒有考慮雙字節(jié)語言的支持。

2)軟件本地化后，單字節(jié)字符向雙字節(jié)字符轉(zhuǎn)化過程中，由于單字節(jié)和雙字節(jié)之間的差別，可能使得某些本地化后的雙字節(jié)字符的顯示亂碼。

3)軟件本地化后，對(duì)程序中控制符號(hào)如換行鍵“\n”的處理錯(cuò)誤而引起亂碼。

(2)表現(xiàn)特征：

1)控件或?qū)υ捒蛑酗@示不可辯識(shí)的字符。

2)控件或?qū)υ捒蛑酗@示無意義的明顯錯(cuò)誤的字符。

3)不支持雙字節(jié)字符的輸入，包括雙字節(jié)的文件名和路徑名。

4)僅出現(xiàn)在本地化后的版本中。

(3)測試要求：

1)本地化后的軟件字符顯示正確完整，無亂碼或明顯錯(cuò)別字。

(4)測試方法：

1)執(zhí)行菜單或按鈕，檢查對(duì)話框中的字符。

2)打開幫助文檔，檢查所有需要翻譯的字符。

(5)說明：

1)注意檢查對(duì)話框下拉列表中需要拖動(dòng)滾動(dòng)條才能顯示的內(nèi)容。

總結(jié)

以上僅列出了本地化軟件測試經(jīng)常遇到的四種錯(cuò)誤類型，在實(shí)際測試中可能某些錯(cuò)誤的現(xiàn)象（如列表框中有多余項(xiàng)或缺少項(xiàng)），既可以認(rèn)為是布局錯(cuò)誤，也可以屬于功能錯(cuò)誤，應(yīng)該認(rèn)真思考該錯(cuò)誤表現(xiàn)的實(shí)質(zhì)，將其劃分為正確的錯(cuò)誤類型。

實(shí)際測試是一個(gè)動(dòng)態(tài)的過程，不能孤立靜態(tài)地對(duì)待發(fā)現(xiàn)的錯(cuò)誤，因?yàn)橐粋€(gè)錯(cuò)誤可能包含著其他的不同類型的錯(cuò)誤。比如在對(duì)話框中，選擇某個(gè)按鈕，產(chǎn)生一個(gè)錯(cuò)誤提示對(duì)話框，這可能是一個(gè)按鈕功能錯(cuò)誤，如果對(duì)話框中存在需要翻譯而沒有翻譯的英文，則又是一個(gè)翻譯錯(cuò)誤，如果對(duì)話框中存在無法辨識(shí)的字符，則又是一個(gè)雙字節(jié)錯(cuò)誤，如果對(duì)話框中按鈕排列重疊，則還是一個(gè)布局錯(cuò)誤。

總之，本地化軟件的錯(cuò)誤的產(chǎn)生是多方面的，不能僅僅歸結(jié)為軟件本地化過程帶來的錯(cuò)誤，實(shí)際上，良好的國際化設(shè)計(jì)的源程序是減少軟件本地化錯(cuò)誤的根本保證。當(dāng)然，提高軟件本地化過程能力，提高翻譯和檢查，優(yōu)化本地化軟件編譯流程，能夠減少很多因本地化產(chǎn)生的錯(cuò)誤。設(shè)計(jì)功能和界面測試用例一文章出處：個(gè)人博客ruance發(fā)布時(shí)間：2006-11-131.1文本框、按鈕等控件測試1.1.1文本框的測試如何對(duì)文本框進(jìn)行測試

a,輸入正常的字母或數(shù)字。

b,輸入已存在的文件的名稱；

c,輸入超長字符。例如在“名稱”框中輸入超過允許邊界個(gè)數(shù)的字符，假設(shè)最多255個(gè)字符，嘗試輸入

256個(gè)字符，檢查程序能否正確處理；

d,輸入默認(rèn)值，空白，空格；

e,若只允許輸入字母，嘗試輸入數(shù)字；反之；嘗試輸入字母；

f,利用復(fù)制，粘貼等操作強(qiáng)制輸入程序不允許的輸入數(shù)據(jù)；

g,輸入特殊字符集，例如，NUL及\n等；

h,輸入超過文本框長度的字符或文本，檢查所輸入的內(nèi)容是否正常顯示；

i,輸入不符合格式的數(shù)據(jù)，檢查程序是否正常校驗(yàn)，如，程序要求輸入年月日格式為yy/mm/dd，實(shí)際輸入yyyy/mm/dd，程序應(yīng)該給出錯(cuò)誤提示在測試過程中所用到的測試方法：1,輸入非法數(shù)據(jù)；

2,輸入默認(rèn)值；

3,輸入特殊字符集；

4,輸入使緩沖區(qū)溢出的數(shù)據(jù)；

5,輸入相同的文件名；命令按鈕控件的測試測試方法：a,點(diǎn)擊按鈕正確響應(yīng)操作。如，單擊確定，正確執(zhí)行操作；單擊取消，退出窗口；

b,對(duì)非法的輸入或操作給出足夠的提示說明，如，輸入月工作天數(shù)為32時(shí)，單擊”確定“后系統(tǒng)應(yīng)提示:天數(shù)不能大于31；

c,對(duì)可能造成數(shù)據(jù)無法恢復(fù)的操作必須給出確認(rèn)信息，給用戶放棄選擇的機(jī)會(huì)；單選按鈕控件的測試測試方法：a,一組單選按鈕不能同時(shí)選中，只能選中一個(gè)。

b,逐一執(zhí)行每個(gè)單選按鈕的功能。分別選擇了“男”“女”后，保存到數(shù)據(jù)庫的數(shù)據(jù)應(yīng)該相應(yīng)的分別為“男”“女”；

c,一組執(zhí)行同一功能的單選按鈕在初始狀態(tài)時(shí)必須有一個(gè)被默認(rèn)選中，不能同時(shí)為空；up－down控件文本框的測試測試方法：a,直接輸入數(shù)字或用上下箭頭控制，如，在“數(shù)目”中直接輸入10，或者單擊向上的箭頭，使數(shù)目變?yōu)?0；

b,利用上下箭頭控制數(shù)字的自動(dòng)循環(huán)，如，當(dāng)最多數(shù)字為253時(shí)，單擊向上箭頭，數(shù)目自動(dòng)變?yōu)?；反之亦適用；

c,直接輸入超邊界值，系統(tǒng)應(yīng)該提示重新輸入；

d,輸入默認(rèn)值，空白。如，“插入”數(shù)目為默認(rèn)值，點(diǎn)擊“確定”；或，刪除默認(rèn)值，使內(nèi)容為空，單擊“確定”進(jìn)行測試；

e,輸入字符。此時(shí)系統(tǒng)應(yīng)提示輸入有誤。組合列表框的測試測試方法：a,條目內(nèi)容正確，其詳細(xì)條目內(nèi)容可以根據(jù)需求說明確定；

b,逐一執(zhí)行列表框中每個(gè)條目的功能；

c,檢查能否向組合列表框輸入數(shù)據(jù)；復(fù)選框的測試測試方法：a,多個(gè)復(fù)選框可以被同時(shí)選中；

b,多個(gè)復(fù)選框可以被部分選中；

c,多個(gè)復(fù)選框可以都不被選中；

d,逐一執(zhí)行每個(gè)復(fù)選框的功能；列表框控件的測試測試方法：a,條目內(nèi)容正確；同組合列表框類似，根據(jù)需求說明書確定列表的各項(xiàng)內(nèi)容正確，沒有丟失或錯(cuò)誤；

b,列表框的內(nèi)容較多時(shí)要使用滾動(dòng)條；

c,列表框允許多選時(shí)，要分別檢查shift選中條目，按ctrl選中條目和直接用鼠標(biāo)選中多項(xiàng)條目的情況；滾動(dòng)條控件的測試要注意一下幾點(diǎn)：a,滾動(dòng)條的長度根據(jù)顯示信息的長度或?qū)挾燃皶r(shí)變換，這樣有利于用戶了解顯示信息的位置和百分比，如，word中瀏覽100頁文檔，瀏覽到50頁時(shí)，滾動(dòng)條位置應(yīng)處于中間；

b,拖動(dòng)滾動(dòng)條，檢查屏幕刷新情況，并查看是否有亂碼；

c,單擊滾動(dòng)條；

d,用滾輪控制滾動(dòng)條；

e,滾動(dòng)條的上下按鈕。各種控件在窗體中混和使用時(shí)的測試a,控件間的相互作用；

b,tab鍵的順序，一般是從上到下，從左到右；

c,熱鍵的使用，逐一測試；

d,enter鍵和esc鍵的使用；在測試中，應(yīng)遵循由簡入繁的原則，先進(jìn)行單個(gè)控件功能的測試，確保實(shí)現(xiàn)無誤后，再進(jìn)行多個(gè)控件的的功能組合的測試。ps:密碼輸入框測試時(shí)要特別注意進(jìn)行字母大寫輸入的測試。查找替換操作

案例演示:打開word中的"替換"對(duì)話框

測試本功能有通過測試和失敗測試兩種情況

通過測試:

1,輸入內(nèi)容直接查找,或查找全部

2,在組合框中尋找已經(jīng)查找過的內(nèi)容,再次查找并確認(rèn)文檔的內(nèi)容正確,如,已經(jīng)查找過"測試用例",再次進(jìn)入不用重新輸入查找內(nèi)容,直接在文檔中搜尋就可以.

失敗測試:

1,輸入過長或過短的查詢字符串.如,假設(shè)查詢的字符串長度為1到255,那么輸入0,1,2,256,255和254進(jìn)行測試;

2,輸入特殊字符集,如,在word中.^g代表圖片,^代表分欄符,可以輸入這類特殊字符測試;

替換測試大體相同.

關(guān)于編輯操作窗口的功能測試的用例:

1,關(guān)閉查找替換窗口.不執(zhí)行任何操作,直接退出;

2,附件和選項(xiàng)測試.假如,設(shè)定"精確搜尋","向后"搜索等附件選項(xiàng)等等來測試;

3,控件間的相互作用.如,搜尋內(nèi)容為空時(shí),按鈕"搜尋全部","搜尋","全部替換","替換"都為灰色.

4,熱鍵,

Tab鍵.回車鍵的使用.

插入操作

1,插入文件

測試的情況

a,插入文件;

b,插入圖像;

c,在文檔中插入文檔本身;

d,移除插入的源文件;

e,更換插入的源文件的內(nèi)容;

2,鏈接文件

測試方法:

a,插入鏈接文件;

b,在文檔中鏈接文檔本身;

c,移除插入的源文件;

d,更換插入的源文件的內(nèi)容.

3,插入對(duì)象

要測試的內(nèi)容

a,插入程序允許的對(duì)象,如,在word中插入excel工作表;

b,修改所插入對(duì)象的內(nèi)容.插入的對(duì)象仍能正確顯示;

c,卸載生成插入對(duì)象的程序,如,在word中插入excel工作表后卸載excel,工作表仍正常使用.

編輯操作

編輯操作包括剪切,復(fù)制,粘貼操作.

測試剪切操作的方法

a,對(duì)文本,文本框,圖文框進(jìn)行剪切;

b,剪切圖像

c,文本圖像混合剪切

復(fù)制操作方法與剪切類似.

測試時(shí),主要是對(duì)粘貼操作的測試,方法是:

a,粘貼剪切的文本,文本框及圖文框;

b,粘貼所剪切的圖像;

c,剪切后,在不同的程序中粘貼

d,多次粘貼同一內(nèi)容,如,剪切后,在程序中連續(xù)粘貼3次;

e,利用粘貼操作強(qiáng)制輸入程序所不允許輸入的數(shù)據(jù).

界面測試用例的設(shè)計(jì)方法

1,窗體

測試窗體的方法:

a,窗體大小,大小要合適,控件布局合理;

b,移動(dòng)窗體.快速或慢速移動(dòng)窗體,背景及窗體本身刷新必須正確;

c,縮放窗體,窗體上的控件應(yīng)隨窗體的大小變化而變化;

d,顯示分辨率.必須在不同的分辨率的情況下測試程序的顯示是否正常;

進(jìn)行測試時(shí)還要注意狀態(tài)欄是否顯示正確;工具欄的圖標(biāo)執(zhí)行操作是否有效,是否與菜單懶中圖標(biāo)顯示一致;錯(cuò)誤信息內(nèi)容是否正確,無錯(cuò)別字,且明確等等;2,控件

測試方法:

a,窗體或控件的字體和大小要一致;

b,注意全角,半角混合

c,無中英文混合.

菜單進(jìn)行測試時(shí)要注意

a,選擇菜單是否可以正常工作,并與實(shí)際執(zhí)行內(nèi)容一致;

b,是否有錯(cuò)別字:

c,快捷鍵是否重復(fù);

d,熱鍵是否重復(fù);

e,快捷鍵與熱鍵操作是否有效

f,是否存在中英文混合

g,菜單要與語境相關(guān),如,不同權(quán)限的用戶登陸一個(gè)應(yīng)用程序,不同級(jí)別的用戶可以看到不同級(jí)別的菜單并使用不同級(jí)別的功能;

h,鼠標(biāo)右鍵快捷菜單

特殊屬性

1,安裝界面應(yīng)有公司介紹或產(chǎn)品介紹,有公司的圖標(biāo)

2,主界面及大多數(shù)界面最好有公司圖標(biāo)

3,選擇"幫助"->"關(guān)于"命令,應(yīng)看見相關(guān)版權(quán)和產(chǎn)品信息測試用例設(shè)計(jì)自動(dòng)化文章出處：51testing論壇天網(wǎng)發(fā)布時(shí)間：2006-11-10

一般來說,用例設(shè)計(jì)屬于重復(fù)次數(shù)少的智能活動(dòng),不太適合自動(dòng)化。但也有一些場合可以進(jìn)行一定程度的自動(dòng)化，提高設(shè)計(jì)效率，但不能指望能完全取代智力的測試活動(dòng)。實(shí)現(xiàn)這種目的的工具有時(shí)稱為測試輸入生成工具。

所有的測試輸入生成工具都存在一個(gè)問題，即工具可能產(chǎn)生大量的測試用例，但它不能區(qū)分哪些測試是最重要的，這些要求創(chuàng)造力的智力活動(dòng)只能由測試人員完成。工具永遠(yuǎn)不能回答如何在合理的時(shí)間里挑選適當(dāng)?shù)挠美齺韴?zhí)行。

工具生成測試用例依賴于規(guī)格描述的形式化，如果不能做到形式化描述，是無法按照一定算法實(shí)現(xiàn)用例設(shè)計(jì)自動(dòng)化的。另外由于用例的生成依賴于所采用的算法，所以工具生成用例比人工設(shè)計(jì)要徹底、精確。但人工在判斷測試需求是否有遺漏方面更有優(yōu)勢。

測試用例的復(fù)審文章出處：blog朱少民發(fā)布時(shí)間：2006-11-09

測試用例的設(shè)計(jì)是整個(gè)軟件測試工作的核心，測試用例反映對(duì)被測對(duì)象的質(zhì)量要求和評(píng)估范圍，決定測試的效率和測試自身的質(zhì)量。

所以對(duì)測試用例的評(píng)審，就顯得非常重要。測試用例設(shè)計(jì)完之后，要經(jīng)過非正式和正式的復(fù)審和評(píng)審。在測試用例審查、評(píng)審過程中，主要檢查下列內(nèi)容：測試用例設(shè)計(jì)的整體思路是否清晰，是否清楚系統(tǒng)的結(jié)構(gòu)和邏輯從而使測試用例的結(jié)構(gòu)或?qū)哟吻逦瑴y試的優(yōu)先級(jí)或先后次序是否合理；測試用例設(shè)計(jì)的有效性，測試的重點(diǎn)是否突出，即是否抓住修改較大的地方、程序或系統(tǒng)的薄弱環(huán)節(jié)等；測試用例的覆蓋面，有沒有考慮到產(chǎn)品使用中一些特別場景（scenario）、考慮到一些邊界和接口的地方；測試用例的描述，前提條件是否存在、步驟是否簡明清楚、期望結(jié)果(Criteria)是否符合產(chǎn)品規(guī)格說明書或客戶需要；測試環(huán)境是否準(zhǔn)確，測試用例有沒有正確定義測試所需要的條件或環(huán)境；測試用例的復(fù)用性和可維護(hù)性，良好的測試用例將會(huì)具有重復(fù)使用的功能,保證測試的穩(wěn)定性；測試用例是否符合其他要求，如可管理性、易于自動(dòng)化測試的轉(zhuǎn)化等。

測試用例在評(píng)審后，根據(jù)評(píng)審意見做出修改，繼續(xù)評(píng)審，直至通過評(píng)審。在以后的測試中，如果有些被發(fā)現(xiàn)的缺陷，沒有測試用例，應(yīng)及時(shí)添加新的測試用例或修改相應(yīng)的測試用例。和軟件缺陷相關(guān)的測試用例是更有效的測試用例，其執(zhí)行的優(yōu)先級(jí)也高。通過測試用例所發(fā)現(xiàn)的缺陷占所有軟件缺陷的比值，是衡量測試用例質(zhì)量和有效性的方法之一。淺談測試用例－《軟件測試藝術(shù)》讀書筆記(16)文章出處：blogsoliya發(fā)布時(shí)間：2006-10-30本書第四章主要講述了白盒測試和黑盒測試的原理、具體方法，及一些測試策略的思考。就經(jīng)驗(yàn)而言，個(gè)人覺得，測試軟件中最重要的因素還是要：設(shè)計(jì)和生成有效的測試用例。所以，作者在開章之處特別提及測試用例，我認(rèn)為是很必要的。

緣由：因?yàn)闇y試不可能是完全的，所以最顯然的測試策略就是努力使測試盡可能完全。那么，由于考慮到時(shí)間和成本的約束，則一個(gè)最關(guān)鍵的問題就是：在所有可能的測試用例中，哪個(gè)子集最有可能發(fā)現(xiàn)最多的錯(cuò)誤。很顯然，在所有的方法中效率最低的就是隨機(jī)輸入的測試，那么就需要提出一套思考過程，讓其有助于更加睿智地選取測試數(shù)據(jù)。

于是，便有了一種比較合理的測試策略：先使用黑盒測試方法來設(shè)計(jì)測試用例，然后視情況需要使用白盒測試方法來設(shè)計(jì)補(bǔ)充測試用例。先談及、概括一下白盒測試。

白盒測試，所關(guān)注的是：測試用例執(zhí)行的程度或覆蓋程序邏輯結(jié)構(gòu)（源代碼）的程度。因此，也可以認(rèn)為是邏輯覆蓋測試。具體方法有五個(gè)，按其邏輯覆蓋的從弱到強(qiáng)依次列出：

語句覆蓋（面）：將程序中的每條語句至少執(zhí)行一次，但實(shí)現(xiàn)不太可能，該準(zhǔn)則有很大的不足，以至于它通常沒有什么用處判定/分支覆蓋（線）：

必須編寫足夠的測試用例，使得每一個(gè)判斷都至少有一個(gè)為真和為假的輸出結(jié)果。即：每條分支路徑都必須至少遍歷一次。換句話說：所有判斷的每個(gè)可能結(jié)果都至少執(zhí)行一次，以及將程序或子程序的每個(gè)入口點(diǎn)都至少執(zhí)行一次。需要指出的是：該準(zhǔn)則滿足語言覆蓋準(zhǔn)則。條件覆蓋（點(diǎn)）：編寫足夠的測試用例以確保將一個(gè)判斷中的每個(gè)條件的所有可能的結(jié)果至少執(zhí)行一次。判定/條件覆蓋（點(diǎn)線結(jié)合）：設(shè)計(jì)出足夠的測試用例，將一個(gè)判斷中的每個(gè)條件的所有可能結(jié)果至少執(zhí)行一次，將每個(gè)判斷的所有可能結(jié)果至少執(zhí)行一次，將每個(gè)入口點(diǎn)都至少調(diào)用一次。需明確一點(diǎn)，該準(zhǔn)則有一個(gè)極大的缺點(diǎn)：盡管看上去所有條件的所有結(jié)果似乎都執(zhí)行到了，但由于某些特定的條件會(huì)屏蔽掉其他的條件，通常并不能全部都執(zhí)行到。例如：該準(zhǔn)則并不一定會(huì)發(fā)現(xiàn)邏輯表達(dá)式中的錯(cuò)誤（與、或）。

多重條件覆蓋（點(diǎn)線組合）：編寫足夠多的測試用例，將每個(gè)判定中的所有可能的條件結(jié)果的組合，以及所有的入口點(diǎn)都至少執(zhí)行一次。需要說明的是，滿足多重條件覆蓋準(zhǔn)則的測試用例集，同樣滿足判定覆蓋準(zhǔn)則、條件覆蓋準(zhǔn)則以及判定/條件覆蓋準(zhǔn)則。需明確的是：在存在循環(huán)的情況下，多重條件覆蓋準(zhǔn)則所需要的測試用例的數(shù)量通常會(huì)遠(yuǎn)遠(yuǎn)小于其路徑的數(shù)量。文尾，作者小結(jié)了一下。包含每個(gè)判斷只存在一種條件的程序，最簡單的測試準(zhǔn)則就是：設(shè)計(jì)出足夠數(shù)量的測試用例，將每個(gè)判斷的所有結(jié)果都至少執(zhí)行一次；將所有的程序入口都至少調(diào)用一次，以確保全部的語句都至少執(zhí)行一次。包含多重條件判斷的程序，最簡單的測試準(zhǔn)則是：設(shè)計(jì)出足夠數(shù)量的測試用例，將每個(gè)判斷的所有可能的條件結(jié)果的組合，以及所有的入口點(diǎn)都至少執(zhí)行一次。再概述一下黑盒測試。那么首先就是等價(jià)類劃分法。

等價(jià)類劃分，是一個(gè)最優(yōu)子集的挑選過程。該子集必須具備兩個(gè)特性：

嚴(yán)格控制測試用例的增加，減少為達(dá)到“合理測試”的某些既定目標(biāo)而必須設(shè)計(jì)的其他測試用例的數(shù)量；即：每個(gè)測試用例都必須體現(xiàn)盡可能多的不同的輸入情況，以使最大限度地減少測試所需的全部用例的數(shù)量；（經(jīng)驗(yàn)而言，是用于生成有效測試用例的約束。）覆蓋了大部分其他可能的測試用例：使用或不使用這個(gè)特定的輸入集合，哪些錯(cuò)誤會(huì)被發(fā)現(xiàn)，哪些會(huì)被遺漏掉。即：應(yīng)該盡量將程序輸入范圍進(jìn)行劃分，將其劃分為有限數(shù)量的等價(jià)類，這樣就可以合理地假設(shè)測試每個(gè)等價(jià)類的代表性數(shù)據(jù)等于測試該類的其他任何數(shù)據(jù)。（經(jīng)驗(yàn)而言，是用于生成無效測試用例的約束的。）具體步驟為：確定等價(jià)類：確定等價(jià)類是選取每一個(gè)輸入條件，將其劃分為兩個(gè)或更多的組。這里可以借助表格來進(jìn)行劃分，并確定了兩類等價(jià)類：有效等價(jià)類、無效等價(jià)類。生成測試用例。（具體三步就不再敘述了）文尾，順便提一點(diǎn)個(gè)人經(jīng)驗(yàn)：依據(jù)規(guī)格說明確定輸入條件時(shí)，一定要思維緊密和周全，否則會(huì)出現(xiàn)很大的遺漏性；且用單個(gè)測試用例覆蓋無效等價(jià)類，是因?yàn)槟承┨囟ǖ妮斎脲e(cuò)誤可能會(huì)評(píng)比或取代其他輸入錯(cuò)誤檢查。所以應(yīng)：少而全、多而專。邊界值分析法，有較好的測試回報(bào)率。該法較簡單，僅是用于考察正處于等價(jià)劃分邊界或在邊界附近的狀態(tài)。因此，只需明確邊界條件這一定義即可。邊界條件，是指輸入和輸出等價(jià)類中那些恰好處于邊界、或超過邊界、或在邊界以下的狀態(tài)。

錯(cuò)誤猜測法，沒有用到任何特殊的方法，只是利用直覺和經(jīng)驗(yàn)猜測出錯(cuò)的可能類型，然后編寫測試用例來暴露這些錯(cuò)誤?；舅枷胧橇信e出可能犯的錯(cuò)誤或錯(cuò)誤易發(fā)情況的清單，然后依據(jù)清單來編寫測試用例；并且在閱讀規(guī)格說明時(shí)聯(lián)系程序員可能做的假設(shè)來確定測試用例，也就是說規(guī)格說明中的一些內(nèi)容會(huì)被忽略，要么是由于偶然因素，要么是程序員認(rèn)為其顯而易見。

文尾，需提及注意的是：邊界值分析法，考慮到了結(jié)果空間的邊界（因?yàn)檩斎敕秶倪吔绮⒉豢偸悄艽磔敵龇秶倪吔缜闆r。）界面測試文章出處：bbs.51testing51testing會(huì)員發(fā)布時(shí)間：2006-08-29界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對(duì)軟件的第一印象。而且設(shè)計(jì)良好的界面能夠引導(dǎo)用戶自己完成相應(yīng)的操作，起到向?qū)У淖饔?。同時(shí)界面如同人的面孔，具有吸引用戶的直接優(yōu)勢。設(shè)計(jì)合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺，相反由于界面設(shè)計(jì)的失敗，讓用戶有挫敗感，再實(shí)用強(qiáng)大的功能都可能在用戶的畏懼與放棄中付諸東流。目前界面的設(shè)計(jì)引起軟件設(shè)計(jì)人員的重視的程度還遠(yuǎn)遠(yuǎn)不夠，直到最近網(wǎng)頁制作的興起，才受到專家的青睞。而且設(shè)計(jì)良好的界面由于需要具有藝術(shù)美的天賦而遭拒絕。

目前流行的界面風(fēng)格有三種方式：多窗體、單窗體以及資源管理器風(fēng)格，無論那種風(fēng)格，以下規(guī)則是應(yīng)該被重視的。

1：易用性：

按鈕名稱應(yīng)該易懂，用詞準(zhǔn)確，屏棄沒楞兩可的字眼，要與同一界面上的其他按鈕易于區(qū)分，能望文知意最好。理想的情況是用戶不用查閱幫助就能知道該界面的功能并進(jìn)行相關(guān)的正確操作。

易用性細(xì)則：

1):完成相同或相近功能的按鈕用Frame框起來，常用按鈕要支持快捷方式。

2):完成同一功能或任務(wù)的元素放在集中位置，減少鼠標(biāo)移動(dòng)的距離。

3):按功能將界面劃分區(qū)域塊，用Frame框括起來,并要有功能說明或標(biāo)題。

4):界面要支持鍵盤自動(dòng)瀏覽按鈕功能，即按Tab鍵、回車鍵的自動(dòng)切換功能。

5):界面上首先要輸入的和重要信息的控件在Tab順序中應(yīng)當(dāng)靠前,位置也應(yīng)放在窗口上較醒目的位置。

6):同一界面上的控件數(shù)最好不要超過10個(gè)，多于10個(gè)時(shí)可以考慮使用分頁界面顯示。

7):分頁界面要支持在頁面間的快捷切換，常用組合快捷鍵Ctrl+Tab

8):默認(rèn)按鈕要支持Enter及選操作，即按Enter后自動(dòng)執(zhí)行默認(rèn)按鈕對(duì)應(yīng)操作。9):可寫控制項(xiàng)檢測到非法輸入後應(yīng)給出說明並能自動(dòng)獲得焦點(diǎn)。

10):Tab鍵的順序與控件排列順序要一致，目前流行總體從上到下，同時(shí)行間從左到右的方式。

11):核取方塊和選項(xiàng)框按選擇幾率的高底而先後排列。

12):核取方塊和選項(xiàng)框要有默認(rèn)選項(xiàng)，並支援Tab選擇。

13):選項(xiàng)數(shù)相同時(shí)多用選項(xiàng)框而不用下拉清單框。

14):界面空間較小時(shí)使用下拉框而不用選項(xiàng)框。

15):選項(xiàng)數(shù)較少時(shí)使用選項(xiàng)框，相反使用下拉列表框。

16):專業(yè)性強(qiáng)的軟件要使用相關(guān)的專業(yè)術(shù)語，通用性界面則提倡使用通用性詞語。

2：規(guī)范性：

通常界面設(shè)計(jì)都按Windows界面的規(guī)范來設(shè)計(jì)，可以說：界面遵循規(guī)范化的程度越高，則易用性相應(yīng)的就越好。小型軟件一般不提供工具廂。

規(guī)范性細(xì)則：

1):常用菜單要有命令快捷方式。

2):完成相同或相近功能的菜單用橫線隔開放在同一位置。

3):菜單前的圖標(biāo)能直觀的代表要完成的操作。

4):菜單深度一般要求最多控制在三層以內(nèi)。

5):工具欄要求可以根據(jù)用戶的要求自己選擇定制。

6):相同或相近功能的工具欄放在一起。

7):工具欄中的每一個(gè)按鈕要有及時(shí)提示信息。

8):一條工具欄的長度最長不能超出屏幕寬度。

9):工具欄的圖標(biāo)能直觀的代表要完成的操作。

10):系統(tǒng)常用的工具欄設(shè)置默認(rèn)放置位置。

11):工具欄太多時(shí)可以考慮使用工具箱。

12):工具箱要具有可增減性，由用戶自己根據(jù)需求定制。

13):工具箱的默認(rèn)總寬度不要超過屏幕寬度的1/5。

14):狀態(tài)條要能顯示用戶切實(shí)需要的信息，常用的有：

目前的操作、系統(tǒng)狀態(tài)、用戶位置、用戶信息、提示信息、錯(cuò)誤信息等，如果某一操作需要的時(shí)間較長，還應(yīng)該顯示進(jìn)度條和進(jìn)程提示。

15)：滾動(dòng)條的長度要根據(jù)顯示信息的長度或?qū)挾饶芗皶r(shí)變換，以利于用戶了解顯示信息的位置和百分比。

16)：狀態(tài)條的高度以放置五好字為宜，滾動(dòng)條的寬度比狀態(tài)條的略窄。

17)：菜單和工具條要有清楚的界限;菜單要求凸出顯示，這樣在移走工具條時(shí)仍有立體感。

18)：菜單和狀態(tài)條中通常使用5號(hào)字體。工具條一般比菜單要寬，但不要寬的太多，否則看起來很不協(xié)調(diào)。

19):右鍵快捷菜單采用與菜單相同的準(zhǔn)則。

3：幫助設(shè)施：

系統(tǒng)應(yīng)該提供詳盡而可靠的幫助文檔，在用戶使用產(chǎn)生迷惑時(shí)可以自己尋求解決方法。

幫助設(shè)施細(xì)則：

1)：幫助文檔中的性能介紹與說明要與系統(tǒng)性能配套一致。(我們的系統(tǒng)幫助文檔都是系統(tǒng)的祖先時(shí)期的說明，讓人困惑)。

2)：打包新系統(tǒng)時(shí)，對(duì)作了修改的地方在幫助文檔中要做相應(yīng)的修改。

3)：操作時(shí)要提供及時(shí)調(diào)用系統(tǒng)幫助的功能。常用F1。

4)：在界面上調(diào)用幫助時(shí)應(yīng)該能夠及時(shí)定位到與該操作相對(duì)的幫助位置。也就是說幫助要有即時(shí)針對(duì)性。

5)：最好提供目前流行的聯(lián)機(jī)幫助格式或HTML幫助格式。

6)：用戶可以用關(guān)鍵詞在幫助索引中搜索所要的幫助，當(dāng)然也應(yīng)該提供幫助主題詞。

7)：如果沒有提供書面的幫助文檔的話，最好有打印幫助的功能。

8)：在幫助中應(yīng)該提供我們的技術(shù)支持方式，一旦用戶難以自己解決可以方便的尋求新的幫助方式。4：合理性：

屏幕對(duì)角線相交的位置是用戶直視的地方，正上方四分之一處為易吸引用戶注意力的位置，在放置窗體時(shí)要注意利用這兩個(gè)位置。

合理性細(xì)則：

1)：父窗體或主窗體的中心位置應(yīng)該在對(duì)角線焦點(diǎn)附近。

2)：子窗體位置應(yīng)該在主窗體的左上角或正中。

3)：多個(gè)子窗體彈出時(shí)應(yīng)該依次向右下方偏移，以顯示窗體出標(biāo)題為宜。

4)：重要的命令按鈕與使用較頻繁的按鈕要放在界面上注目的位置。

5)：錯(cuò)誤使用容易引起界面退出或關(guān)閉的按鈕不應(yīng)該放在易點(diǎn)擊的位置。橫排開頭或最后與豎排最后為易點(diǎn)位置。

6)：與正在進(jìn)行的操作無關(guān)的按鈕應(yīng)該加以屏蔽(Windows中用灰色顯示，沒法使用該按鈕)。

7)：對(duì)可能造成數(shù)據(jù)無法恢復(fù)的操作必須提供確認(rèn)信息,給用戶放棄選擇的機(jī)會(huì)。

8)：非法的輸入或操作應(yīng)有足夠的提示說明。

9):對(duì)運(yùn)行過程中出現(xiàn)問題而引起錯(cuò)誤的地方要有提示，讓用戶明白錯(cuò)誤出處，避免形成無限期的等待。

10):提示、警告、或錯(cuò)誤說明應(yīng)該清楚、明了、恰當(dāng)。

5：美觀與協(xié)調(diào)性：

界面應(yīng)該大小適合美學(xué)觀點(diǎn)，感覺協(xié)調(diào)舒適，能在有效的范圍內(nèi)吸引用戶的注意力。

美觀與協(xié)調(diào)性細(xì)則：

1):長寬接近黃金點(diǎn)比例，切忌長寬比例失調(diào)、或?qū)挾瘸^長度。

2):布局要合理,不宜過于密集，也不能過于空曠，合理的利用空間。

3):按鈕大小基本相近，忌用太長的名稱，免得占用過多的界面位置。

4):按鈕的大小要與界面的大小和空間要協(xié)調(diào)。

5):避免空曠的界面上放置很大的按鈕。

6)：放置完控件后界面不應(yīng)有很大的空缺位置。

7):字體的大小要與界面的大小比例協(xié)調(diào),通常使用的字體中宋體9-12較為美觀，很少使用超過12號(hào)的字體。

8):前景與背景色搭配合理協(xié)調(diào)，反差不宜太大，最好少用深色，如大紅、大綠等。常用色考慮使用Windows界面色調(diào)。

9):如果使用其他顏色，主色調(diào)要柔和，具有親和力與磁力，堅(jiān)決杜絕刺目的顏色。

10):大型系統(tǒng)常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。

11):界面風(fēng)格要保持一致，字的大小、顏色、字體要相同，除非是需要藝術(shù)處理或有特殊要求的地方。

12):如果窗體支持最小化和最大化或放大時(shí)，窗體上的控件也要隨著窗體而縮放；切忌只放大窗體而忽略控件的縮放。

13)：對(duì)于含有按鈕的界面一般不應(yīng)該支持縮放，即右上角只有關(guān)閉功能。

14):通常父窗體支持縮放時(shí)，子窗體沒有必要縮放。

15)：如果能給用戶提供自定義界面風(fēng)格則更好，由用戶自己選擇顏色、字體等。

6：菜單位置：

菜單是界面上最重要的元素，菜單位置按照按功能來組織。

菜單測試細(xì)則：

1):菜單通常采用“常用--主要--次要--工具--幫助”的位置排列，符合流行的Windows風(fēng)格。

2):常用的有“文件”、“編輯”，“查看”等，幾乎每個(gè)系統(tǒng)都有這些選項(xiàng)，當(dāng)然要根據(jù)不同的系統(tǒng)有所取捨。

3):下拉菜單要根據(jù)菜單選項(xiàng)的含義進(jìn)行分組，並且按照一定的規(guī)則進(jìn)行排列，用橫線隔開。

4):一組菜單的使用有先后要求或有向?qū)ё饔脮r(shí)，應(yīng)該按先后次序排列。

5):沒有順序要求的菜單項(xiàng)按使用頻率和重要性排列，常用的放在開頭，不常用的靠后放置；重要的放在開頭，次要的放在后邊。

6):如果菜單選項(xiàng)較多，應(yīng)該采用加長菜單的長度而減少深度的原則排列。

7):菜單深度一般要求最多控制在三層以內(nèi)。

8):對(duì)常用的菜單要有快捷命令方式，組合原則見8。

9):對(duì)與進(jìn)行的操作無關(guān)的菜單要用屏蔽的方式加以處理，如果采用動(dòng)態(tài)加載方式——即只有需要的菜單才顯示——最好。

10):菜單前的圖標(biāo)不宜太大，與字高保持一直最好。

11):主菜單的寬度要接近，字?jǐn)?shù)不應(yīng)多于四個(gè)，每個(gè)菜單的字?jǐn)?shù)能相同最好。

12):主菜單數(shù)目不應(yīng)太多，最好為單排布置。13):菜單條是否顯示在合適的語境中？14):應(yīng)用程序的菜單條是否顯示系統(tǒng)相關(guān)的特性（如時(shí)鐘顯示）？15):下拉式操作能正確工作嗎？16):菜單、調(diào)色板和工具條是否工作正確？17):是否適當(dāng)?shù)亓谐隽怂械牟藛喂δ芎拖吕阶庸δ埽?8):是否可能通過鼠標(biāo)訪問所有的菜單功能？19):相同功能按鈕的圖標(biāo)和文字是否一致？20):是否能夠用其他的文本命令激活每個(gè)菜單功能？21):菜單功能是否隨當(dāng)前的窗口操作加亮或變灰？22):菜單功能是否正確執(zhí)行？23):菜單功能的名字是否具有自解釋性？24):菜單項(xiàng)是否有幫助，是否語境相關(guān)？25):在整個(gè)交互式語境中，是否可以識(shí)別鼠標(biāo)操作？26):如果要求多次點(diǎn)擊鼠標(biāo)，是否能夠在語境正確識(shí)別？27):如果鼠標(biāo)有多個(gè)按鈕，是否能夠在語境中正確識(shí)別？28):光標(biāo)、處理指示器和識(shí)別指針是否隨操作恰當(dāng)?shù)馗淖儯?/p>

7:獨(dú)特性：

如果一味的遵循業(yè)界的界面標(biāo)準(zhǔn)，則會(huì)喪失自己的個(gè)性.在框架符合以上規(guī)范的情況下，設(shè)計(jì)具有自己獨(dú)特風(fēng)格的界面尤為重要。尤其在商業(yè)軟件流通中有著很好的遷移默化的廣告效用。

測試細(xì)則：

1):安裝界面上應(yīng)有單位介紹或產(chǎn)品介紹，并有自己的圖標(biāo)。

2):主界面，最好是大多數(shù)界面上要有公司圖標(biāo)。

3):登錄界面上要有本產(chǎn)品的標(biāo)志，同時(shí)包含公司圖標(biāo)。

4):幫助菜單的“關(guān)于”中應(yīng)有版權(quán)和產(chǎn)品信息。

5):公司的系列產(chǎn)品要保持一直的界面風(fēng)格，如背景色、字體、菜單排列方式、圖標(biāo)、安裝過程、按鈕用語等應(yīng)該大體一致。8：快捷方式的組合

在菜單及按鈕中使用快捷鍵可以讓喜歡使用鍵盤的用戶操作得更快一些在西文Windows及其應(yīng)用軟件中快捷鍵的使用大多是一致的。

菜單中：

1):面向事務(wù)的組合有:

Ctrl-D刪除；Ctrl-F尋找；Ctrl–H替換；Ctrl-I插入；Ctrl-N新記錄；Ctrl-S保存Ctrl-O打開。

2)：列表:

Ctrl-R，Ctrl-G定位；Ctrl-Tab下一分頁窗口或反序?yàn)g覽同一頁面控件；。

3):編輯:

Ctrl-A全選；Ctrl-C拷貝；Ctrl-V粘貼；Ctrl-X剪切；Ctrl-Z撤消操作；Ctrl-Y恢復(fù)操作。

4)文件操作:

Ctrl-P打印；Ctrl-W關(guān)閉。

5):系統(tǒng)菜單

Alt-A文件；Alt-E編輯；Alt-T工具；Alt－W窗口；Alt－H幫助。

6):MSWindows保留鍵:

Ctrl-Esc任務(wù)列表；Ctrl-F4關(guān)閉窗口；Alt-F4結(jié)束應(yīng)用；Alt-Tab下一應(yīng)用；Enter缺省按鈕/確認(rèn)操作；Esc取消按鈕/取消操作；Shift-F1上下文相關(guān)幫助。

按鈕中：

可以根據(jù)系統(tǒng)需要而調(diào)節(jié)，以下只是常用的組合。

Alt-Y確定(是)；Alt-C取消；Alt-N否；Alt-D刪除；Alt-Q退出；Alt-A添加；Alt-E編輯；Alt-B瀏覽；Alt-R讀；Alt-W寫。

這些快捷鍵也可以作為開發(fā)中文應(yīng)用軟件的標(biāo)準(zhǔn),但亦可使用漢語拼音的開頭字母。

9:安全性考慮：

在界面上通過下列方式來控制出錯(cuò)幾率，會(huì)大大減少系統(tǒng)因用戶人為的錯(cuò)誤引起的破壞。開發(fā)者應(yīng)當(dāng)盡量周全地考慮到各種可能發(fā)生的問題,使出錯(cuò)的可能降至最小。如應(yīng)用出現(xiàn)保護(hù)性錯(cuò)誤而退出系統(tǒng),這種錯(cuò)誤最容易使用戶對(duì)軟件失去信心。因?yàn)檫@意味著用戶要中斷思路,并費(fèi)時(shí)費(fèi)力地重新登錄,而且已進(jìn)行的操作也會(huì)因沒有存盤而全部丟失。

安全性細(xì)則：

1)：最重要的是排除可能會(huì)使應(yīng)用非正常中止的錯(cuò)誤。

2)：應(yīng)當(dāng)注意盡可能避免用戶無意錄入無效的數(shù)據(jù)。

3)：采用相關(guān)控件限制用戶輸入值的種類。

4)：當(dāng)用戶作出選擇的可能性只有兩個(gè)時(shí),可以采用單選框。

5)：當(dāng)選擇的可能再多一些時(shí),可以采用復(fù)選框,每一種選擇都是有效的,用戶不可能輸入任何一種無效的選擇。

6)：當(dāng)選項(xiàng)特別多時(shí)，可以采用列表框，下拉式列表框。

7)：在一個(gè)應(yīng)用系統(tǒng)中,開發(fā)者應(yīng)當(dāng)避免用戶作出未經(jīng)授權(quán)或沒有意義的操作。

8)：對(duì)可能引起致命錯(cuò)誤或系統(tǒng)出錯(cuò)的輸入字符或動(dòng)作要加限制或屏蔽。

9):對(duì)可能發(fā)生嚴(yán)重后果的操作要有補(bǔ)救措施。通過補(bǔ)救措施用戶可以回到原來的正確狀態(tài)。

10):對(duì)一些特殊符號(hào)的輸入、與系統(tǒng)使用的符號(hào)相沖突的字符等進(jìn)行判斷并阻止用戶輸入該字符。

11)：對(duì)錯(cuò)誤操作最好支持可逆性處理，如取消系列操作。

12):在輸入有效性字符之前應(yīng)該阻止用戶進(jìn)行只有輸入之后才可進(jìn)行的操作。

13):對(duì)可能造成等待時(shí)間較長的操作應(yīng)該提供取消功能。

14)：特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!

,.。?/還有空格。

15)：與系統(tǒng)采用的保留字符沖突的要加以限制。

16)：在讀入用戶所輸入的信息時(shí)，根據(jù)需要選擇是否去掉前后空格。

17)：有些讀入數(shù)據(jù)庫的字段不支持中間有空格，但用戶切實(shí)需要輸入中間空格，這時(shí)要在程序中加以處理。

10:多窗口的應(yīng)用與系統(tǒng)資源：

設(shè)計(jì)良好的軟件不僅要有完備的功能，而且要盡可能的占用最底限度的資源。

1)：在多窗口系統(tǒng)中，有些界面要求必須保持在最頂層，避免用戶在打開多個(gè)窗口時(shí)，不停的切換甚至最小化其他窗口來顯示該窗口。

2)：在主界面載入完畢后自動(dòng)卸出內(nèi)存，讓出所占用的WINDOWS系統(tǒng)資源。

3)：關(guān)閉所有窗體，系統(tǒng)退出后要釋放所占的所有系統(tǒng)資源，除非是需要后臺(tái)運(yùn)行的系統(tǒng)。

4)：盡量防止對(duì)系統(tǒng)的獨(dú)占使用。5)：窗口能否基于相關(guān)的輸入或菜單命令適當(dāng)?shù)卮蜷_？6)：窗口能否改變大小、移動(dòng)和滾動(dòng)？7)：窗口中的數(shù)據(jù)內(nèi)容能否使用鼠標(biāo)、功能鍵、方向箭頭和鍵盤訪問？8)：當(dāng)被覆蓋并重調(diào)用后，窗口能否正確地再生？9)：需要時(shí)能否使用所有窗口相關(guān)的功能？10)：所有窗口相關(guān)的功能是可操作的嗎？11)：是否有相關(guān)的下拉式菜單、工具條、滾動(dòng)條、對(duì)話框、按鈕、圖標(biāo)和其他控制可為窗口可用，并適當(dāng)?shù)仫@示？12)：顯示多個(gè)窗口時(shí)，窗口的名稱是否被適當(dāng)?shù)乇硎荆?3)：活動(dòng)窗口是否被適當(dāng)?shù)丶恿粒?4)：如果使用多任務(wù)，是否所有的窗口被實(shí)時(shí)更新？15)：多次或不正確按鼠標(biāo)是否會(huì)導(dǎo)致無法預(yù)料的副作用？16)：窗口的聲音和顏色提示和窗口的操作順序是否符合需求？17)：窗口是否正確地關(guān)閉？測試驅(qū)動(dòng)開發(fā)全攻略文章出處：網(wǎng)絡(luò)未知發(fā)布時(shí)間：2006-09-22{關(guān)鍵字}測試驅(qū)動(dòng)開發(fā)/TestDrivenDevelopment/TDD

測試用例/TestCase/TC

設(shè)計(jì)/Design

重構(gòu)/Refactoring{TDD的目標(biāo)}CleanCodeThatWorks這句話的含義是，事實(shí)上我們只做兩件事情：讓代碼奏效（Work）和讓代碼潔凈（Clean），前者是把事情做對(duì)，后者是把事情做好。想想看，其實(shí)我們平時(shí)所做的所有工作，除去無用的工作和錯(cuò)誤的工作以外，真正正確的工作，并且是真正有意義的工作，其實(shí)也就只有兩大類：增加功能和提升設(shè)計(jì)，而TDD正是在這個(gè)原則上產(chǎn)生的。如果您的工作并非我們想象的這樣，（這意味著您還存在第三類正確有意義的工作，或者您所要做的根本和我們?cè)谡f的是兩回事），那么這告訴我們您并不需要TDD，或者不適用TDD。而如果我們偶然猜對(duì)（這對(duì)于我來說是偶然，而對(duì)于KentBeck和MartinFowler這樣的大師來說則是辛勤工作的成果），那么恭喜您，TDD有可能成為您顯著提升工作效率的一件法寶。請(qǐng)不要將信將疑，若即若離，因?yàn)槿魏我豁?xiàng)新的技術(shù)——只要是從根本上改變?nèi)说男袨榉绞降募夹g(shù)——就必然使得相信它的人越來越相信，不信的人越來越不信。這就好比學(xué)游泳，唯一能學(xué)會(huì)游泳的途徑就是親自下去游，除此之外別無他法。這也好比成功學(xué)，即使把卡耐基或希爾博士的書倒背如流也不能擁有積極的心態(tài)，可當(dāng)你以積極的心態(tài)去成就了一番事業(yè)之后，你就再也離不開它了。相信我，TDD也是這樣！想試用TDD的人們，請(qǐng)遵循下面的步驟：編寫TestCase–>實(shí)現(xiàn)TestCase–>重構(gòu)

（確定范圍和目標(biāo)）（增加功能）（提升設(shè)計(jì)）[友情提示：敏捷建模中的一個(gè)相當(dāng)重要的實(shí)踐被稱為：ProveitWithCode，這種想法和TDD不謀而合。]{TDD的優(yōu)點(diǎn)}『充滿吸引力的優(yōu)點(diǎn)』完工時(shí)完工。表明我可以很清楚的看到自己的這段工作已經(jīng)結(jié)束了，而傳統(tǒng)的方式很難知道什么時(shí)候編碼工作結(jié)束了。

全面正確的認(rèn)識(shí)代碼和利用代碼，而傳統(tǒng)的方式?jīng)]有這個(gè)機(jī)會(huì)。

為利用你成果的人提供Sample，無論它是要利用你的源代碼，還是直接重用你提供的組件。

開發(fā)小組間降低了交流成本，提高了相互信賴程度。

避免了過渡設(shè)計(jì)。

系統(tǒng)可以與詳盡的測試集一起發(fā)布，從而對(duì)程序的將來版本的修改和擴(kuò)展提供方便。

TDD給了我們自信，讓我們今天的問題今天解決，明天的問題明天解決，今天不能解決明天的問題，因?yàn)槊魈斓膯栴}還沒有出現(xiàn)(沒有TestCase)，除非有TestCase否則我決不寫任何代碼；明天也不必?fù)?dān)心今天的問題，只要我亮了綠燈?！翰伙@而易見的優(yōu)點(diǎn)』逃避了設(shè)計(jì)角色。對(duì)于一個(gè)敏捷的開發(fā)小組，每個(gè)人都在做設(shè)計(jì)。

大部分時(shí)間代碼處在高質(zhì)量狀態(tài)，100％的時(shí)間里成果是可見的。

由于可以保證編寫測試和編寫代碼的是相同的程序員，降低了理解代碼所花費(fèi)的成本。

為減少文檔和代碼之間存在的細(xì)微的差別和由這種差別所引入的Bug作出杰出貢獻(xiàn)。

在預(yù)先設(shè)計(jì)和緊急設(shè)計(jì)之間建立一種平衡點(diǎn)，為你區(qū)分哪些設(shè)計(jì)該事先做、哪些設(shè)計(jì)該迭代時(shí)做提供了一個(gè)可靠的判斷依據(jù)。

『有爭議的優(yōu)點(diǎn)』事實(shí)上提高了開發(fā)效率。每一個(gè)正在使用TDD并相信TDD的人都會(huì)相信這一點(diǎn)，但觀望者則不同，不相信TDD的人甚至堅(jiān)決反對(duì)這一點(diǎn)，這很正常，世界總是這樣。

發(fā)現(xiàn)比傳統(tǒng)測試方式更多的Bug。

使IDE的調(diào)試功能失去意義，或者應(yīng)該說，避免了令人頭痛的調(diào)試和節(jié)約了調(diào)試的時(shí)間。

總是處在要么編程要么重構(gòu)的狀態(tài)下，不會(huì)使人抓狂。（兩頂帽子）

單元測試非常有趣。{TDD的步驟}

編寫TestCase–>實(shí)現(xiàn)TestCase–>重構(gòu)

（不可運(yùn)行）（可運(yùn)行）（重構(gòu)）步驟制品

（1）快速新增一個(gè)測試用例新的TestCase

（2）編譯所有代碼，剛剛寫的那個(gè)測試很可能編譯不通過原始的TODOList

（3）做盡可能少的改動(dòng)，讓編譯通過Interface

（4）運(yùn)行所有的測試，發(fā)現(xiàn)最新的測試不能編譯通過－(RedBar)

（5）做盡可能少的改動(dòng)，讓測試通過Implementation

（6）運(yùn)行所有的測試，保證每個(gè)都能通過－(GreenBar)

（7）重構(gòu)代碼，以消除重復(fù)設(shè)計(jì)CleanCodeThatWorks{FAQ}[什么時(shí)候重構(gòu)？]

如果您在軟件公司工作，就意味著您成天都會(huì)和想通過重構(gòu)改善代碼質(zhì)量的想法打交道，不僅您如此，您的大部分同事也都如此?？墒牵烤故裁磿r(shí)候該重構(gòu)，什么情況下應(yīng)該重構(gòu)呢？我相信您和您的同事可能有很多不同的看法，最常見的答案是“該重構(gòu)時(shí)重構(gòu)”，“寫不下去的時(shí)候重構(gòu)”，和“下一次迭代開始之前重構(gòu)”，或者干脆就是“最近沒時(shí)間，就不重構(gòu)了，下次有時(shí)間的時(shí)候重構(gòu)吧”。正如您已經(jīng)預(yù)見到我想說的——這些想法都是對(duì)重構(gòu)的誤解。重構(gòu)不是一種構(gòu)建軟件的工具，不是一種設(shè)計(jì)軟件的模式，也不是一個(gè)軟件開發(fā)過程中的環(huán)節(jié)，正確理解重構(gòu)的人應(yīng)該把重構(gòu)看成一種書寫代碼的方式，或習(xí)慣，重構(gòu)時(shí)時(shí)刻刻有可能發(fā)生。在TDD中，除去編寫測試用例和實(shí)現(xiàn)測試用例之外的所有工作都是重構(gòu)，所以，沒有重構(gòu)任何設(shè)計(jì)都不能實(shí)現(xiàn)。至于什么時(shí)候重構(gòu)嘛，還要分開看，有三句話是我的經(jīng)驗(yàn)：實(shí)現(xiàn)測試用例時(shí)重構(gòu)代碼，完成某個(gè)特性時(shí)重構(gòu)設(shè)計(jì)，產(chǎn)品的重構(gòu)完成后還要記得重構(gòu)一下測試用例哦。[什么時(shí)候設(shè)計(jì)？]

這個(gè)問題比前面一個(gè)要難回答的多，實(shí)話實(shí)說，本人在依照TDD開發(fā)軟件的時(shí)候也常常被這個(gè)問題困擾，總是覺得有些問題應(yīng)該在寫測試用例之前定下來，而有些問題應(yīng)該在新增一個(gè)一個(gè)測試用例的過程中自然出現(xiàn)，水到渠成。所以，我的建議是，設(shè)計(jì)的時(shí)機(jī)應(yīng)該由開發(fā)者自己把握，不要受到TDD方式的限制，但是，不需要事先確定的事一定不能事先確定，免得捆住了自己的手腳。[什么時(shí)候增加新的TestCase？]

沒事做的時(shí)候。通常我們認(rèn)為，如果你要增加一個(gè)新的功能，那么先寫一個(gè)不能通過的TestCase；如果你發(fā)現(xiàn)了一個(gè)bug，那么先寫一個(gè)不能通過的TestCase；如果你現(xiàn)在什么都沒有，從0開始，請(qǐng)先寫一個(gè)不能通過的TestCase。所有的工作都是從一個(gè)TestCase開始。此外，還要注意的是，一些大師要求我們每次只允許有一個(gè)TestCase亮紅燈，在這個(gè)TestCase沒有Green之前不可以寫別的TestCase，這種要求可以適當(dāng)考慮，但即使有多個(gè)TestCase亮紅燈也不要緊，并未違反TDD的主要精神。[TestCase該怎么寫？]

測試用例的編寫實(shí)際上就是兩個(gè)過程：使用尚不存在的代碼和定義這些代碼的執(zhí)行結(jié)果。所以一個(gè)TestCase也就應(yīng)該包括兩個(gè)部分——場景和斷言。第一次寫TestCase的人會(huì)有很大的不適應(yīng)的感覺，因?yàn)槟阒八鶎懙乃袞|西都是在解決問題，現(xiàn)在要你提出問題確實(shí)不大習(xí)慣，不過不用擔(dān)心，你正在做正確的事情，而這個(gè)世界上最難的事情也不在于如何解決問題，而在于asktherightquestion！[TDD能幫助我消除Bug嗎？]

答：不能！千萬不要把“測試”和“除蟲”混為一談！“除蟲”是指程序員通過自己的努力來減少bug的數(shù)量（消除bug這樣的字眼我們還是不要講為好^_^），而“測試”是指程序員書寫產(chǎn)品以外的一段代碼來確保產(chǎn)品能有效工作。雖然TDD所編寫的測試用例在一定程度上為尋找bug提供了依據(jù)，但事實(shí)上，按照TDD的方式進(jìn)行的軟件開發(fā)是不可能通過TDD再找到bug的（想想我們前面說的“完工時(shí)完工”），你想啊，當(dāng)我們的代碼完成的時(shí)候，所有的測試用例都亮了綠燈，這時(shí)隱藏在代碼中的bug一個(gè)都不會(huì)露出馬腳來。但是，如果要問“測試”和“除蟲”之間有什么聯(lián)系，我相信還是有很多話可以講的，比如TDD事實(shí)上減少了bug的數(shù)量，把查找bug戰(zhàn)役的關(guān)注點(diǎn)從全線戰(zhàn)場提升到代碼戰(zhàn)場以上。還有，bug的最可怕之處不在于隱藏之深，而在于滿天遍野。如果你發(fā)現(xiàn)了一個(gè)用戶很不容易才能發(fā)現(xiàn)的bug，那么不一定對(duì)工作做出了什么杰出貢獻(xiàn)，但是如果你發(fā)現(xiàn)一段代碼中，bug的密度或離散程度過高，那么恭喜你，你應(yīng)該拋棄并重寫這段代碼了。TDD避免了這種情況，所以將尋找bug的工作降低到了一個(gè)新的低度。[我該為一個(gè)Feature編寫TestCase還是為一個(gè)類編寫TestCase？]

初學(xué)者常問的問題。雖然我們從TDD的說明書上看到應(yīng)該為一個(gè)特性編寫相應(yīng)的TestCase，但為什么著名的TDD大師所寫的TestCase都是和類/方法一一對(duì)應(yīng)的呢？為了解釋這個(gè)問題，我和我的同事們都做了很多試驗(yàn)，最后我們得到了一個(gè)結(jié)論，雖然我不知道是否正確，但是如果您沒有答案，可以姑且相信我們。我們的研究結(jié)果表明，通常在一個(gè)特性的開發(fā)開始時(shí)，我們針對(duì)特性編寫測試用例，如果您發(fā)現(xiàn)這個(gè)特性無法用TestCase表達(dá)，那么請(qǐng)將這個(gè)特性細(xì)分，直至您可以為手上的特性寫出TestCase為止。從這里開始是最安全的，它不會(huì)導(dǎo)致任何設(shè)計(jì)上重大的失誤。但是，隨著您不斷的重構(gòu)代碼，不斷的重構(gòu)TestCase，不斷的依據(jù)TDD的思想做下去，最后當(dāng)產(chǎn)品伴隨測試用例集一起發(fā)布的時(shí)候，您就會(huì)不經(jīng)意的發(fā)現(xiàn)經(jīng)過重構(gòu)以后的測試用例很可能是和產(chǎn)品中的類/方法一一對(duì)應(yīng)的。[什么時(shí)候應(yīng)該將全部測試都運(yùn)行一遍？]

GoodQuestion！大師們要求我們每次重構(gòu)之后都要完整的運(yùn)行一遍測試用例。這個(gè)要求可以理解，因?yàn)橹貥?gòu)很可能會(huì)改變整個(gè)代碼的結(jié)構(gòu)或設(shè)計(jì)，從而導(dǎo)致不可預(yù)見的后果，但是如果我正在開發(fā)的是一個(gè)ERP怎么辦？運(yùn)行一遍完整的測試用例可能將花費(fèi)數(shù)個(gè)小時(shí)，況且現(xiàn)在很多重構(gòu)都是由工具做到的，這個(gè)要求的可行性和前提條件都有所動(dòng)搖。所以我認(rèn)為原則上你可以挑幾個(gè)你覺得可能受到本次重構(gòu)影響的TestCase去run，但是如果運(yùn)行整個(gè)測試包只要花費(fèi)數(shù)秒的時(shí)間，那么不介意你按大師的要求去做。[什么時(shí)候改進(jìn)一個(gè)TestCase？]

增加的測試用例或重構(gòu)以后的代碼導(dǎo)致了原來的TestCase的失去了效果，變得無意義，甚至可能導(dǎo)致錯(cuò)誤的結(jié)果，這時(shí)是改進(jìn)TestCase的最好時(shí)機(jī)。但是有時(shí)你會(huì)發(fā)現(xiàn)，這樣做僅僅導(dǎo)致了原來的TestCase在設(shè)計(jì)上是臃腫的，或者是冗余的，這都不要緊，只要它沒有失效，你仍然不用去改進(jìn)它。記住，TestCase不是你的產(chǎn)品，它不要好看，也不要怎么太科學(xué)，甚至沒有性能要求，它只要能完成它的使命就可以了——這也證明了我們后面所說的“用Ctrl-C/Ctrl-V編寫測試用例”的可行性。但是，美國人的想法其實(shí)跟我們還是不太一樣，拿托尼巴贊的MindMap來說吧，其實(shí)畫MindMap只是為了表現(xiàn)自己的思路，或記憶某些重要的事情，但托尼卻建議大家把MindMap畫成一件藝術(shù)品，甚至還有很多藝術(shù)家把自己畫的抽象派MindMap拿出來幫助托尼做宣傳。同樣，大師們也要求我們把TestCase寫的跟代碼一樣質(zhì)量精良，可我想說的是，現(xiàn)在國內(nèi)有幾個(gè)公司能把產(chǎn)品的代碼寫的精良？？還是一步一步慢慢來吧。[為什么原來通過的測試用例現(xiàn)在不能通過了？]

這是一個(gè)警報(bào)，RedAlert！它可能表達(dá)了兩層意思——都不是什么好意思——1）你剛剛進(jìn)行的重構(gòu)可能失敗了，或存在一些錯(cuò)誤未被發(fā)現(xiàn)，至少重構(gòu)的結(jié)果和原來的代碼不等價(jià)了。2）你剛剛增加的TestCase所表達(dá)的意思跟前面已經(jīng)有的TestCase相沖突，也就是說，