軟件測(cè)試的常識(shí)

1、軟件測(cè)試的常識(shí)來(lái)自張華老師的文章,同樣也收錄新手版精華區(qū)。軟件測(cè)試的常識(shí)軟件開(kāi)發(fā)和使用的歷史已經(jīng)留給了我們很多由于軟件缺陷而導(dǎo)致的巨大財(cái)力、物力損失的經(jīng)驗(yàn)教訓(xùn)。這些經(jīng)驗(yàn)教訓(xùn)迫使我們這些測(cè)試工程師們必須采取強(qiáng)有力的檢測(cè)措施來(lái)檢測(cè)未發(fā)現(xiàn)的隱藏的軟件缺陷。生產(chǎn)軟件的最終目的是為了滿足客戶需求,我們以客戶需求作為評(píng)判軟件質(zhì)量的標(biāo)準(zhǔn),認(rèn)為軟件缺陷( Software Bug 的具體含義包括下面幾個(gè)因素:軟件未達(dá)到客戶需求的功能和性能;軟件超出客戶需求的范圍;軟件出現(xiàn)客戶需求不能容忍的錯(cuò)誤;軟件的使用未能符合客戶的習(xí)慣和工作環(huán)境。考慮到設(shè)計(jì)等方面的因素,我們還可以認(rèn)為軟件缺陷還可以包括軟件設(shè)計(jì)不符合規(guī)范,

2、未能在特定的條件(資金、范圍等達(dá)到最佳等。可惜的是,我們中的很多人更傾向于把軟件缺陷看成運(yùn)行時(shí)出現(xiàn)問(wèn)題上來(lái),認(rèn)為軟件測(cè)試僅限于程序提交之后。在目前的國(guó)內(nèi)環(huán)境下,我們幾乎看不到完整準(zhǔn)確的客戶需求說(shuō)明書(shū),加以客戶的需求時(shí)時(shí)在變,追求完美的測(cè)試變得不太可能。因此作為一個(gè)優(yōu)異的測(cè)試人員,追求軟件質(zhì)量的完美固然是我們的宗旨,但是明確軟件測(cè)試現(xiàn)實(shí)與理想的差距,在軟件測(cè)試中學(xué)會(huì)取舍和讓步,對(duì)軟件測(cè)試是有百益而無(wú)一弊的。下面是一些軟件測(cè)試的常識(shí),對(duì)這些常識(shí)的理解和運(yùn)用將有助于我們?cè)谶M(jìn)行軟件測(cè)試時(shí)能夠更好的把握軟件測(cè)試的尺度。測(cè)試是不完全的(測(cè)試不完全很顯然,由于軟件需求的不完整性、軟件邏輯路徑的組合性、輸入數(shù)

3、據(jù)的大量性及結(jié)果多樣性等因素,哪怕是一個(gè)極其簡(jiǎn)單的程序,要想窮盡所有邏輯路徑,所有輸入數(shù)據(jù)和驗(yàn)證所有結(jié)果是非常困難的一件事情。我們舉一個(gè)簡(jiǎn)單的例子,比如說(shuō)求兩個(gè)整數(shù)的最大公約數(shù)。其輸入信息為兩個(gè)正整數(shù)。但是如果我們將整個(gè)正整數(shù)域的數(shù)字進(jìn)行一番測(cè)試的話,從其數(shù)目的無(wú)限性我們便可證明是這樣的測(cè)試在實(shí)際生活中是行不通的,即便某一天我們能夠窮盡該程序,只怕我們乃至我們的子孫都早已作古了。為此作為軟件測(cè)試,我們一般采用等價(jià)類和邊界值分析等措施來(lái)進(jìn)行實(shí)際的軟件測(cè)試,尋找最小用例集合成為我們精簡(jiǎn)測(cè)試復(fù)雜性的一條必經(jīng)之道。測(cè)試具有免疫性(軟件缺陷免疫性軟件缺陷與病毒一樣具有可怕的“免疫性”,測(cè)試人員對(duì)其采用的

4、測(cè)試越多,其免疫能力就越強(qiáng),尋找更多軟件缺陷就更加困難。由數(shù)學(xué)上的概率論我們可以推出這一結(jié)論。假設(shè)一個(gè) 50000 行的程序中有500 個(gè)軟件缺陷并且這些軟件錯(cuò)誤分布時(shí)均勻的,則每 100 行可以找到一個(gè)軟件缺陷。我們假設(shè)測(cè)試人員用某種方法花在查找軟件缺陷的精力為 X 小時(shí) /100 行。照此推算,軟件存在 500 個(gè)缺陷時(shí),我們查找一個(gè)軟件缺陷需要 X 小時(shí),當(dāng)軟件只存在 5 個(gè)錯(cuò)誤時(shí),我們每查找一個(gè)軟件缺陷需要 100X 小時(shí)。實(shí)踐證明,實(shí)際的測(cè)試過(guò)程比上面的假設(shè)更為苛刻,為此我們必須更換不同的測(cè)試方式和測(cè)試數(shù)據(jù)。該例子還說(shuō)明了在軟件測(cè)試中采用單一的方法不能高效和完全的針對(duì)所有軟件缺陷,因

5、此軟件測(cè)試應(yīng)該盡可能的多采用多種途徑進(jìn)行測(cè)試。測(cè)試是“泛型概念”(全程測(cè)試我一直反對(duì)軟件測(cè)試僅存在于程序完成之后。如果單純的只將程序設(shè)計(jì)階段后的階段稱之為軟件測(cè)試的話,需求階段和設(shè)計(jì)階段的缺陷產(chǎn)生的放大效應(yīng)會(huì)加大。這非常不利于保證軟件質(zhì)量。需求缺陷、設(shè)計(jì)缺陷也是軟件缺陷,記住“軟件缺陷具有生育能力”。軟件測(cè)試應(yīng)該跨越整個(gè)軟件開(kāi)發(fā)流程。需求驗(yàn)證(自檢和設(shè)計(jì)驗(yàn)證(自檢也可以算作軟件測(cè)試(建議稱為:需求測(cè)試和設(shè)計(jì)測(cè)試的一種。軟件測(cè)試應(yīng)該是一個(gè)泛型概念,涵蓋整個(gè)軟件生命周期,這樣才能確保周期的每個(gè)階段禁得起考驗(yàn)。同時(shí)測(cè)試本身也需要有第三者進(jìn)行評(píng)估(信息系統(tǒng)審計(jì)和軟件工程監(jiān)理,即測(cè)試本身也應(yīng)當(dāng)被測(cè)試,從

6、而確保測(cè)試自身的可靠性和高效性。否則自身不正,難以服人。另外還需指出的是軟件測(cè)試是提高軟件產(chǎn)品質(zhì)量的必要條件而非充分條件,軟件測(cè)試是提高產(chǎn)品質(zhì)量最直接、最快捷的手段,但決不是一個(gè)根本手段。 80-20 原則80% 的軟件缺陷常常生存在軟件 20% 的空間里。這個(gè)原則告訴我們,如果你想使軟件測(cè)試有效地話,記住常常光臨其高危多發(fā)“地段”。在那里發(fā)現(xiàn)軟件缺陷的可能性會(huì)大的多。這一原則對(duì)于軟件測(cè)試人員提高測(cè)試效率及缺陷發(fā)現(xiàn)率有著重大的意義。聰明的測(cè)試人員會(huì)根據(jù)這個(gè)原則很快找出較多的缺陷而愚蠢的測(cè)試人員卻仍在漫無(wú)目的地到處搜尋。80-20 原則的另外一種情況是,我們?cè)谙到y(tǒng)分析、系統(tǒng)設(shè)計(jì)、系統(tǒng)實(shí)現(xiàn)階段的復(fù)

7、審,測(cè)試工作中能夠發(fā)現(xiàn)和避免 80% 的軟件缺陷,此后的系統(tǒng)測(cè)試能夠幫助我們找出剩余缺陷中的 80% ,最后的 5% 的軟件缺陷可能只有在系統(tǒng)交付使用后用戶經(jīng)過(guò)大范圍、長(zhǎng)時(shí)間使用后才會(huì)曝露出來(lái)。因?yàn)檐浖y(cè)試只能夠保證盡可能多地發(fā)現(xiàn)軟件缺陷,卻無(wú)法保證能夠發(fā)現(xiàn)所有的軟件缺陷。80-20 原則還能反映到軟件測(cè)試的自動(dòng)化方面上來(lái),實(shí)踐證明 80% 的軟件缺陷可以借助人工測(cè)試而發(fā)現(xiàn), 20% 的軟件缺陷可以借助自動(dòng)化測(cè)試能夠得以發(fā)現(xiàn)。由于這二者間具有交叉的部分,因此尚有 5% 左右的軟件缺陷需要通過(guò)其他方式進(jìn)行發(fā)現(xiàn)和修正。為效益而測(cè)試為什么我們要實(shí)施軟件測(cè)試,是為了提高項(xiàng)目的質(zhì)量效益最終以提高項(xiàng)目的總

8、體效益。為此我們不難得出我們?cè)趯?shí)施軟件測(cè)試應(yīng)該掌握的度。軟件測(cè)試應(yīng)該在軟件測(cè)試成本和軟件質(zhì)量效益兩者間找到一個(gè)平衡點(diǎn)。這個(gè)平衡點(diǎn)就是我們?cè)趯?shí)施軟件測(cè)試時(shí)應(yīng)該遵守的度。單方面的追求都必然損害軟件測(cè)試存在的價(jià)值和意義。一般說(shuō)來(lái),在軟件測(cè)試中我們應(yīng)該盡量地保持軟件測(cè)試簡(jiǎn)單性,切勿將軟件測(cè)試過(guò)度復(fù)雜化,拿物理學(xué)家愛(ài)因斯坦的話說(shuō)就是: Keep it simple but not too simple 。缺陷的必然性軟件測(cè)試中,由于錯(cuò)誤的關(guān)聯(lián)性,并不是所有的軟件缺陷都能夠得以修復(fù)。某些軟件缺陷雖然能夠得以修復(fù)但在修復(fù)的過(guò)程中我們會(huì)難免引入新的軟件缺陷。很多軟件缺陷之間是相互矛盾的,一個(gè)矛盾的消失必然會(huì)引

9、發(fā)另外一個(gè)矛盾的產(chǎn)生。比如我們?cè)诮鉀Q通用性的缺陷后往往會(huì)帶來(lái)執(zhí)行效率上的缺陷。更何況在缺陷的修復(fù)過(guò)程中,我們常常還會(huì)受時(shí)間、成本等方面的限制因此無(wú)法有效、完整地修復(fù)所有的軟件缺陷。因此評(píng)估軟件缺陷的重要度、影響范圍,選擇一個(gè)折中的方案或是從非軟件的因素(比如提升硬件性能考慮軟件缺陷成為我們?cè)诿鎸?duì)軟件缺陷時(shí)一個(gè)必須直面的事實(shí)。軟件測(cè)試必須有預(yù)期結(jié)果沒(méi)有預(yù)期結(jié)果的測(cè)試是不可理喻的。軟件缺陷是經(jīng)過(guò)對(duì)比而得出來(lái)的。這正如沒(méi)有標(biāo)準(zhǔn)無(wú)法進(jìn)行度量一樣。如果我們事先不知道或是無(wú)法肯定預(yù)期的結(jié)果,我們必然無(wú)法了解測(cè)試正確性。這很容易然人感覺(jué)如盲人摸象一般,不少測(cè)試人員常常憑借自身的感覺(jué)去評(píng)判軟件缺陷的發(fā)生,其結(jié)

10、果往往是把似是而非的東西作為正確的結(jié)果來(lái)判斷,因此常常出現(xiàn)誤測(cè)的現(xiàn)象。軟件測(cè)試的意義 - 事后分析軟件測(cè)試的目的單單是發(fā)現(xiàn)缺陷這么簡(jiǎn)單嗎?如果是“是”的話,我敢保證,類似的軟件缺陷在下一次新項(xiàng)目的軟件測(cè)試中還會(huì)發(fā)生。古語(yǔ)說(shuō)得好,“不知道歷史的人必然會(huì)重蹈覆轍”。沒(méi)有對(duì)軟件測(cè)試結(jié)果進(jìn)行認(rèn)真的分析,我們就無(wú)法了解缺陷發(fā)生的原因和應(yīng)對(duì)措施,結(jié)果是我們不得不耗費(fèi)的大量的人力和物力來(lái)再次查找軟件缺陷。很可惜,目前大多測(cè)試團(tuán)隊(duì)都沒(méi)有意識(shí)到這一點(diǎn),測(cè)試報(bào)告中缺乏測(cè)試結(jié)果分析這一環(huán)節(jié)。結(jié)論:軟件測(cè)試是一個(gè)需要“自覺(jué)”的過(guò)程,作為一個(gè)測(cè)試人員,遇事沉著,把持尺度,從根本上應(yīng)對(duì)軟件測(cè)試有著正確的認(rèn)識(shí),希望本文對(duì)讀

11、者對(duì)軟件測(cè)試的認(rèn)識(shí)有所幫助Acceptance testing(驗(yàn)收測(cè)試,系統(tǒng)開(kāi)發(fā)生命周期方法論的一個(gè)階段,這時(shí)相關(guān)的用戶和/或獨(dú)立測(cè)試人員根據(jù)測(cè)試計(jì)劃和結(jié)果對(duì)系統(tǒng)進(jìn)行測(cè)試和接收。它讓系統(tǒng)用戶決定是否接收系統(tǒng)。它是一項(xiàng)確定產(chǎn)品是否能夠滿足合同或用戶所規(guī)定需求的測(cè)試。這是管理性和防御性控制。Ad hoc testing (隨機(jī)測(cè)試,沒(méi)有書(shū)面測(cè)試用例、記錄期望結(jié)果、檢查列表、腳本或指令的測(cè)試。主要是根據(jù)測(cè)試者的經(jīng)驗(yàn)對(duì)軟件進(jìn)行功能和性能抽查。隨機(jī)測(cè)試是根據(jù)測(cè)試說(shuō)明書(shū)執(zhí)行用例測(cè)試的重要補(bǔ)充手段,是保證測(cè)試覆蓋完整性的有效方式和過(guò)程。Alpha testing (測(cè)試,是由一個(gè)用戶在開(kāi)發(fā)環(huán)境下進(jìn)行的測(cè)試

12、,也可以是公司內(nèi)部的用戶在模擬實(shí)際操作環(huán)境下進(jìn)行的受控測(cè)試,Alpha測(cè)試不能由程序員或測(cè)試員完成。Automated Testing(自動(dòng)化測(cè)試,使用自動(dòng)化測(cè)試工具來(lái)進(jìn)行測(cè)試,這類測(cè)試一般不需要人干預(yù),通常在GUI、性能等測(cè)試中用得較多。Beta testing(測(cè)試,測(cè)試是軟件的多個(gè)用戶在一個(gè)或多個(gè)用戶的實(shí)際使用環(huán)境下進(jìn)行的測(cè)試。開(kāi)發(fā)者通常不在測(cè)試現(xiàn)場(chǎng),Beta測(cè)試不能由程序員或測(cè)試員完成。Black box testing(黑盒測(cè)試,指測(cè)試人員不關(guān)心程序具體如何實(shí)現(xiàn)的一種測(cè)試方法。根據(jù)軟件的規(guī)格對(duì)軟件進(jìn)行各種輸入和觀察軟件的各種輸出結(jié)果來(lái)發(fā)現(xiàn)軟件的缺陷的測(cè)試,這類測(cè)試不考慮軟件內(nèi)部的運(yùn)作

13、原理,因此軟件對(duì)用戶來(lái)說(shuō)就像一個(gè)黑盒子。Bug (錯(cuò)誤,有時(shí)稱作defect(缺陷或error(錯(cuò)誤,軟件程序中存在的編程錯(cuò)誤,可能會(huì)帶來(lái)不必要的副作用,軟件的功能和特性與設(shè)計(jì)規(guī)格說(shuō)明書(shū)或用戶需求不一致的方面。軟件缺陷表現(xiàn)特征為:軟件未達(dá)到產(chǎn)品說(shuō)明書(shū)標(biāo)明的功能;軟件出現(xiàn)產(chǎn)品說(shuō)明書(shū)指明不會(huì)出現(xiàn)的錯(cuò)誤;軟件功能超出產(chǎn)品說(shuō)明書(shū)指明的范圍;雖然產(chǎn)品說(shuō)明書(shū)未指出但是軟件應(yīng)達(dá)到的目標(biāo);軟件測(cè)試人員或用戶認(rèn)為軟件難以理解,不易使用,運(yùn)行速度緩慢等問(wèn)題。Bug report(錯(cuò)誤報(bào)告,也稱為“Bug record(錯(cuò)誤記錄”,記錄發(fā)現(xiàn)的軟件錯(cuò)誤信息的文檔,通常包括錯(cuò)誤描述、復(fù)現(xiàn)步驟、抓取的錯(cuò)誤圖像和注釋等。B

14、ug tracking system(錯(cuò)誤跟蹤系統(tǒng),BTS,也稱為“Defect tracking system,DTS”,管理軟件測(cè)試缺陷的專用數(shù)據(jù)庫(kù)系統(tǒng),可以高效率地完成軟件缺陷的報(bào)告、驗(yàn)證、修改、查詢、統(tǒng)計(jì)、存儲(chǔ)等任務(wù)。尤其適用于大型多語(yǔ)言軟件的測(cè)試管理。Build(工作版本,軟件開(kāi)發(fā)過(guò)程中用于內(nèi)部測(cè)試的功能和性能等不完善的軟件版本。工作版本既可以是系統(tǒng)的可操作版本,也可以是展示要在最終產(chǎn)品中提供的部分功能的部分系統(tǒng)。Compatibility Testing(兼容性測(cè)試,也稱“Configuration testing(配置測(cè)試”,測(cè)試軟件是否和系統(tǒng)的其它與之交互的元素之間兼容,如:瀏

15、覽器、操作系統(tǒng)、硬件等。驗(yàn)證測(cè)試對(duì)象在不同的軟件和硬件配置中的運(yùn)行情況。Capture/Replay Tool (捕獲/回放工具,一種測(cè)試工具,能夠捕獲在測(cè)試過(guò)程中傳遞給軟件的輸入,并且能夠在以后的時(shí)間中,重復(fù)這個(gè)執(zhí)行的過(guò)程。這類工具一般在GUI測(cè)試中用的較多。Crash(崩潰,計(jì)算機(jī)系統(tǒng)或組件突然并完全的喪失功能,例如軟件或系統(tǒng)突然退出或沒(méi)有任何反應(yīng)(死機(jī)。Debug(調(diào)試,開(kāi)發(fā)人員確定引起錯(cuò)誤的根本原因和確定可能的修復(fù)措施的過(guò)程。一般發(fā)生在子系統(tǒng)或單元模塊編碼完成時(shí),或者根據(jù)測(cè)試錯(cuò)誤報(bào)告指出錯(cuò)誤以后,開(kāi)發(fā)人員需要執(zhí)行調(diào)試過(guò)程來(lái)解決已存在的錯(cuò)誤。Deployment(部署,也稱為shipme

16、nt(發(fā)布,對(duì)內(nèi)部IT系統(tǒng)而言,指它的第一個(gè)版本通過(guò)徹底的測(cè)試、形成產(chǎn)品、交付給付款客戶的階段。Dynamic testing(動(dòng)態(tài)測(cè)試,通過(guò)執(zhí)行軟件的手段來(lái)測(cè)試軟件。Exception(異常/例外,一個(gè)引起正常程序執(zhí)行掛起的事件。Functional testing (功能測(cè)試,也稱為behavioral testing(行為測(cè)試,根據(jù)產(chǎn)品特征、操作描述和用戶方案,測(cè)試一個(gè)產(chǎn)品的特性和可操作行為以確定它們滿足設(shè)計(jì)需求。本地化軟件的功能測(cè)試,用于驗(yàn)證應(yīng)用程序或網(wǎng)站對(duì)目標(biāo)用戶能正確工作。使用適當(dāng)?shù)钠脚_(tái)、瀏覽器和測(cè)試腳本,以保證目標(biāo)用戶的體驗(yàn)將足夠好,就像應(yīng)用程序是專門為該市場(chǎng)開(kāi)發(fā)的一樣。Garb

17、age characters(亂碼字符,程序界面中顯示的無(wú)意義的字符,例如,程序?qū)﹄p字節(jié)字符集的字符不支持時(shí),這些字符不能正確顯示。GB 18030 testing(GB 18030測(cè)試,軟件支持GB 18030字符集標(biāo)準(zhǔn)能力的測(cè)試,包括GB 18030字符的輸入、輸出、顯示、存儲(chǔ)的支持程度。Installing testing(安裝測(cè)試,確保該軟件在正常情況和異常情況的不同條件下,例如,進(jìn)行首次安裝、升級(jí)、完整的或自定義的安裝都能進(jìn)行安裝。異常情況包括磁盤空間不足、缺少目錄創(chuàng)建權(quán)限等。核實(shí)軟件在安裝后可立即正常運(yùn)行。安裝測(cè)試包括測(cè)試安裝代碼以及安裝手冊(cè)。安裝手冊(cè)提供如何進(jìn)行安裝,安裝代碼提供

18、安裝一些程序能夠運(yùn)行的基礎(chǔ)數(shù)據(jù)。Integration testing(集成測(cè)試,被測(cè)試系統(tǒng)的所有組件都集成在一起,找出被測(cè)試系統(tǒng)組件之間關(guān)系和接口中的錯(cuò)誤。該測(cè)試一般在單元測(cè)試之后進(jìn)行。International testing(國(guó)際化測(cè)試,國(guó)際化測(cè)試的目的是測(cè)試軟件的國(guó)際化支持能力,發(fā)現(xiàn)軟件的國(guó)際化的潛在問(wèn)題,保證軟件在世界不同區(qū)域中都能正常運(yùn)行。國(guó)際化測(cè)試使用每種可能的國(guó)際輸入類型,針對(duì)任何區(qū)域性或區(qū)域設(shè)置檢查產(chǎn)品的功能是否正常,軟件國(guó)際化測(cè)試的重點(diǎn)在于執(zhí)行國(guó)際字符串的輸入/輸出功能。國(guó)際化測(cè)試數(shù)據(jù)必須包含東亞語(yǔ)言、德語(yǔ)、復(fù)雜腳本字符和英語(yǔ)(可選的混合字符。Localizability

19、testing(本地化能力測(cè)試,本地化能力是指不需要重新設(shè)計(jì)或修改代碼,將程序的用戶界面翻譯成任何目標(biāo)語(yǔ)言的能力。為了降低本地化能力測(cè)試的成本,提高測(cè)試效率,本地化能力側(cè)是通常在軟件的偽本地化版本上進(jìn)行。本地化能力測(cè)試中發(fā)現(xiàn)的典型錯(cuò)誤包括:字符的硬編碼(即軟件中需要本地化的字符寫在了代碼內(nèi)部,對(duì)需要本地化的字符長(zhǎng)度設(shè)置了國(guó)定值,在軟件運(yùn)行時(shí)以控件位置定位,圖標(biāo)和位圖中包含了需要本地化的文本,軟件的用戶界面與文檔術(shù)語(yǔ)不一致等。Load testing(負(fù)載測(cè)試,通過(guò)測(cè)試系統(tǒng)在資源超負(fù)荷情況下的表現(xiàn),以發(fā)現(xiàn)設(shè)計(jì)上的錯(cuò)誤或驗(yàn)證系統(tǒng)的負(fù)載能力。在這種測(cè)試中,將使測(cè)試對(duì)象承擔(dān)不同的工作量,以評(píng)測(cè)和評(píng)估測(cè)

20、試對(duì)象在不同工作量條件下的性能行為,以及持續(xù)正常運(yùn)行的能力。負(fù)載測(cè)試的目標(biāo)是確定并確保系統(tǒng)在超出最大預(yù)期工作量的情況下仍能正常運(yùn)行。此外,負(fù)載測(cè)試還要評(píng)估性能特征,例如,響應(yīng)時(shí)間、事務(wù)處理速率和其他與時(shí)間相關(guān)的方面。Localization testing(本地化測(cè)試,本地化測(cè)試的對(duì)象是軟件的本地化版本。本地化測(cè)試的目的是測(cè)試特定目標(biāo)區(qū)域設(shè)置的軟件本地化質(zhì)量。本地化測(cè)試的環(huán)境是在本地化的操作系統(tǒng)上安裝本地化的軟件。從測(cè)試方法上可以分為基本功能測(cè)試,安裝/卸載測(cè)試,當(dāng)?shù)貐^(qū)域的軟硬件兼容性測(cè)試。測(cè)試的內(nèi)容主要包括軟件本地化后的界面布局和軟件翻譯的語(yǔ)言質(zhì)量,包含軟件、文檔和聯(lián)機(jī)幫助等部分。Perfo

21、rmance testing(性能測(cè)試,評(píng)價(jià)一個(gè)產(chǎn)品或組件與性能需求是否符合的測(cè)試。包括負(fù)載測(cè)試、強(qiáng)度測(cè)試、數(shù)據(jù)庫(kù)容量測(cè)試、基準(zhǔn)測(cè)試等類型。Pilot testing(引導(dǎo)測(cè)試,軟件開(kāi)發(fā)中,驗(yàn)證系統(tǒng)在真實(shí)硬件和客戶基礎(chǔ)上處理典型操作的能力。在軟件外包測(cè)試中,引導(dǎo)測(cè)試通常是客戶檢查軟件測(cè)試公司測(cè)試能力的一種形式,只有通過(guò)了客戶特定的引導(dǎo)測(cè)試,軟件測(cè)試公司才能接受客戶真實(shí)軟件項(xiàng)目的軟件測(cè)試。Portability testing(可移植性測(cè)試,測(cè)試瞄準(zhǔn)于證明軟件可以被移植到指定的硬件或軟件平臺(tái)上。Priority(優(yōu)先權(quán),從商業(yè)角度出發(fā)是指錯(cuò)誤的重要性,尤其是從客戶和用戶的角度出發(fā),是指錯(cuò)誤對(duì)于系

22、統(tǒng)的可行性和可接受性的影響。與“Severity(嚴(yán)重性”相對(duì)照。Quality assurance(質(zhì)量保證QA,采取的所有活動(dòng)以保證一個(gè)開(kāi)發(fā)組織交付的產(chǎn)品滿足性能需求和已確立的標(biāo)準(zhǔn)和過(guò)程。Regression testing(回歸測(cè)試,在發(fā)生修改之后重新測(cè)試先前的測(cè)試以保證修改的正確性。理論上,對(duì)軟件的任何新版本,都需要進(jìn)行回歸測(cè)試,驗(yàn)證以前發(fā)現(xiàn)和修復(fù)的錯(cuò)誤是否在新軟件版本上再現(xiàn)。Review(評(píng)審,在產(chǎn)品開(kāi)發(fā)過(guò)程中,把產(chǎn)品提交給項(xiàng)目成員、用戶、管理者或其它相關(guān)人員評(píng)價(jià)或批準(zhǔn)的過(guò)程。Sanity testing(健全測(cè)試,軟件主要功能成分的簡(jiǎn)單測(cè)試以保證它是否能進(jìn)行基本的測(cè)試。參考“Smo

23、ke testing(冒煙測(cè)試”。Screen shot(抓屏、截圖,軟件測(cè)試中,將軟件界面中的錯(cuò)誤(窗口、菜單、對(duì)話框等的全部或一部分,使用專用工具存儲(chǔ)成圖像文件,以便于后續(xù)處理。Severity(嚴(yán)重性,錯(cuò)誤對(duì)被測(cè)系統(tǒng)的影響程度,在終端用戶條件下發(fā)生的可能性,軟件錯(cuò)誤妨礙系統(tǒng)使用的程度。與“Priority(優(yōu)先權(quán)”相對(duì)照。Smoke testing(冒煙測(cè)試,冒煙測(cè)試的對(duì)象是每一個(gè)新編譯的需要正式測(cè)試的軟件版本,目的是確認(rèn)軟件基本功能正常,可以進(jìn)行后續(xù)的正式測(cè)試工作。冒煙測(cè)試的執(zhí)行者是版本編譯人員。參考“Sanity testing(健全測(cè)試”。Software life cycle(軟

24、件生命周期,開(kāi)始于一個(gè)軟件產(chǎn)品的構(gòu)思,結(jié)束于該產(chǎn)品不再被使用的這段期間。Static testing(靜態(tài)測(cè)試,不通過(guò)執(zhí)行來(lái)測(cè)試一個(gè)系統(tǒng)。如代碼檢查,文檔檢查和評(píng)審等。Structured query language(結(jié)構(gòu)化查詢語(yǔ)句,SQL,在一個(gè)關(guān)系數(shù)據(jù)庫(kù)中查詢和處理數(shù)據(jù)的一種語(yǔ)言。TBD(To be determined,待定,在測(cè)試文檔中標(biāo)是一項(xiàng)進(jìn)行中的尚未最終確定的工作。Test(測(cè)試,執(zhí)行軟件以驗(yàn)證其滿足指定的需求并檢測(cè)錯(cuò)誤的過(guò)程。檢測(cè)已有條件之間的不同,并評(píng)價(jià)軟件項(xiàng)的特性軟件項(xiàng)的分析過(guò)程。軟件工程過(guò)程的一個(gè)活動(dòng),它將軟件在預(yù)定的條件下運(yùn)行以判斷軟件是否符合預(yù)期結(jié)果。Test case(測(cè)試用例,為特定目標(biāo)而開(kāi)發(fā)的一組測(cè)試輸入、執(zhí)行條件和預(yù)期結(jié)果,其目標(biāo)可以是測(cè)試某個(gè)程序路徑或核實(shí)是否滿足某個(gè)特定的需求。Testing coverage(測(cè)試覆蓋,指測(cè)試系統(tǒng)覆蓋被測(cè)試系統(tǒng)的程度