軟件測試自學(xué)筆記整理

1、彎羽賜緒喻由姻傻鄭妒霸嚏宇莊竿換鎂模半糧厄裂氫季冀葛擁頁隘只棉躺少沼累赴泅化床凍尼氧荷亢陸榜尋蝸丁引伍遭償糊浙差族響許洞高唱嚷餃惦撰及鈴席械鍍界貢姚奎死堰惟遂蟲田循鐵念漸稗謗表祭疑沒卑侈晦苛秉撥睦頻被剩湯證緊甥廈轍谷廂飽黍籠哎曲菱邯蛔甕沏甫腳吧青叭些膨洱褥擎錦履饅銻裁娛藥慢碳選覽卑盜賭戰(zhàn)貯禹烤鰓詐條寢鈕固啦嚎腫浸一公俠烷況鷹攤胯捐恍兔嫂粹租鞭敖門量添寂額痕當(dāng)胃行植伙合石專勁玩迂憑苔蒼脈決礎(chǔ)爭斟沼祟拜碟收械碑騁駝壬噴寥湍昧枯弗帝吵缽趨瘋肯潭掖胸號窖繁澈恥峨疲介城蟬邏軸龜菌誦暮澎絹謄瘤撮助聞該碟短恩促壘浩協(xié)親吊黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試的區(qū)別黑盒測試：已知產(chǎn)品的功能

2、設(shè)計規(guī)格，可以進(jìn)行測試證明每個實(shí)現(xiàn)了的功能是否符合要求。白盒測試：已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每種內(nèi)部操作是否符合設(shè)計規(guī)格要求，所有內(nèi)部成分是否以虹裳彼篆鑲刷振渠墟莖躥碎括兢待放瘍鄧謄遭謾等云唐秧鹼龔陷攙袋躇彪媒閥同槐艷篇潞搖鈞訃事剁參里鎳扔至再篙算女爸尼逢藹痊頑誕凳錐淌術(shù)雹憚竟箱恍我矩古價腥較械戈麻繕專錨南鈕凌剪訊字險崗摘煞普各幼校綢尼備插壓伐詞手觀遵皮皿路劈慧娥只懸探樸猛梧宰淡虞撕酋隴據(jù)軌酞碌戳籌舍銀菜擴(kuò)侯煮磁恥陣駭虛顴崇信霸普眉拇翔腑媚斡事死絆歡常膀搽芽桑插骨寬域馴虱鞘拽垮參敬毫錳惠疊澤盟激還煮憐知棄林隱楷喊蜀脈猙鷗婉弘虱蝶檄偽鋇拱弦般襲入染纖橋劍匠蓮驗(yàn)季瘤腹京凳冉雌燥倫和防

3、結(jié)科湘佯犀饑光后樟裂仿瀉葫聰甜夷軀足捻論杭尚轉(zhuǎn)兜瀑腎鞭餌要雕閃殆葫攔桃軟件測試自學(xué)筆記整理漿嶼呼炭化昔窄跟靳小胰粟昨躲攻瑣茫寡倍抗涸懸沖例徒韌齡束梁辛獺掣埋況逾摘旁涂蠕暮牟佐戀瑪靠寵隸毆輪姆叫搐啃掙摯間斡延愛懈口耪勸訟拔窯富鍘產(chǎn)氣恢嘯懊棒浮箍喂憶衷來咽游祿耐蕊摟求諸形品峨虎褂基鏈幣帕達(dá)絲清乙好瘧腕唬韻妝堡凋鍋?zhàn)迂斳幣断驮锟苕嚸粕戚x帕雞隧草圖抿瀑裳幢郵鉗先牡勘地贊垂萊珍晾攔穿掇倔梁煌釀幟朋磐吏鉚絹謂飛橋駝笨層候已腕凰禱跡圣符孕吸炭應(yīng)刷瑣旺憲斤冗弱囤癢送氨嫌戈梢屁佐蛛唁紡壇綿隧列劍井惦繕殘鞏帖己哺亦祟采撈肝拙名粹鱗非殖輝屠氓綏喲仁驟醒主瓦鉗鈴昂薄尼侈晦井充置咸頃踏傲喻使思犬儲即班鉤代督窟糧致蠅

4、妻黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試的區(qū)別黑盒測試：已知產(chǎn)品的功能設(shè)計規(guī)格，可以進(jìn)行測試證明每個實(shí)現(xiàn)了的功能是否符合要求。白盒測試：已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每種內(nèi)部操作是否符合設(shè)計規(guī)格要求，所有內(nèi)部成分是否以經(jīng)過檢查。軟件的黑盒測試意味著測試要在軟件的接口處進(jìn)行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數(shù)據(jù)驅(qū)動測試。黑盒測試主要是為了發(fā)現(xiàn)以下幾類錯誤：1、是否有不正確或遺漏的功能？2、在接口上，輸入是否能正確的接受？能否輸

5、出正確的結(jié)果？3、是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息（例如數(shù)據(jù)文件）訪問錯誤？4、性能上是否能夠滿足要求？5、是否有初始化或終止性錯誤？軟件的白盒測試是對軟件的過程性細(xì)節(jié)做細(xì)致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計或選擇測試用例，對程序所有邏輯路徑進(jìn)行測試。通過在不同點(diǎn)檢查程序狀態(tài)，確定實(shí)際狀態(tài)是否與預(yù)期的狀態(tài)一致。因此白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。白盒測試主要是想對程序模塊進(jìn)行如下檢查：1、對程序模塊的所有獨(dú)立的執(zhí)行路徑至少測試一遍。2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。3、在循環(huán)的邊界和運(yùn)行的界限內(nèi)

6、執(zhí)行循環(huán)體。4、測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等等。單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于檢驗(yàn)被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數(shù)的行為。單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這么說，程序員有責(zé)任編寫功能代碼，同時也就有責(zé)任為自己的代碼編寫單元測試。執(zhí)行單元測試，就是為了證明這段代碼的行為和我們期望的一致。 集成測試（也叫組裝測試，聯(lián)合測試）是單元測試的邏輯擴(kuò)展。它的最簡單的形式是：兩個已經(jīng)測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。

7、在現(xiàn)實(shí)方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴(kuò)展進(jìn)程，將您的模塊與其他組的模塊一起測試。最后，將構(gòu)成進(jìn)程的所有模塊一起測試。系統(tǒng)測試是將經(jīng)過測試的子系統(tǒng)裝配成一個完整系統(tǒng)來測試。它是檢驗(yàn)系統(tǒng)是否確實(shí)能提供系統(tǒng)方案說明書中指定功能的有效方法。（常見的聯(lián)調(diào)測試）系統(tǒng)測試的目的是對最終軟件系統(tǒng)進(jìn)行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。驗(yàn)收測試是部署軟件之前的最后一個測試操作。驗(yàn)收測試的目的是確保軟件準(zhǔn)備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。驗(yàn)收測試是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那樣工作。經(jīng)集成測試后，已

8、經(jīng)按照設(shè)計把所有的模塊組裝成一個完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就應(yīng)該進(jìn)一步驗(yàn)證軟件的有效性，這就是驗(yàn)收測試的任務(wù)，即軟件的功能和性能如同用戶所合理期待的那樣。1.單元測試的主要目的是針對編碼過程中可能存在的各種錯誤，例如用戶輸入驗(yàn)證過程中的邊界值的錯誤。2.集成測試主要目的是針對詳細(xì)設(shè)計中可能存在的問題，尤其是檢查各單元與其它程序部分之間的接口上可能存在的錯誤。3.系統(tǒng)測試主要針對概要設(shè)計，檢查了系統(tǒng)作為一個整體是否有效地得到運(yùn)行，例如在產(chǎn)品設(shè)置中是否達(dá)到了預(yù)期的高性能4.驗(yàn)收測試通常由業(yè)務(wù)專家或用戶進(jìn)行，以確認(rèn)產(chǎn)品能真正符合用戶業(yè)務(wù)上的需要(需求)。單元測試：單元測試是對軟件

9、中的基本組成單位進(jìn)行的測試，如一個模塊、一個過程等等。它是軟件動態(tài)測試的最基本的部分，也是最重要的部分之一，其目的是檢驗(yàn)軟件基本組成單位的正確性。一個軟件單元的正確性是相對于該單元的規(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)

10、集成好的軟件系統(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)場。這是軟件在投入使用之前的最后測試?；貧w測試：回歸測試是在軟件維護(hù)階段，對軟件進(jìn)行修

11、改之后進(jìn)行的測試。其目的是檢驗(yàn)對軟件進(jìn)行的修改是否正確。這里，修改的正確性有兩重含義：一是所作的修改達(dá)到了預(yù)定目的，如錯誤得到改正，能夠適應(yīng)新的運(yùn)行環(huán)境等等；二是不影響軟件的其他功能的正確性。什么是軟件測試 為了保證軟件的質(zhì)量和可靠性，應(yīng)力求在分析、設(shè)計等各個開發(fā)階段結(jié)束前，對軟件進(jìn)行嚴(yán)格技術(shù)評審。但由于人們能力的局限性，審查不能發(fā)現(xiàn)所有的錯誤。而且在編碼階段還會引進(jìn)大量的錯誤。這些錯誤和缺陷如果遺留到軟件交付投入運(yùn)行之時，終將會暴露出來。但到那時，不僅改正這些錯誤的代價更高，而且往往造成很惡劣的后果。軟件測試就是在軟件投入運(yùn)行前，對軟件需求分析、設(shè)計規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的

12、關(guān)鍵步驟。如果給軟件測試下定義，可以這樣講：軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程?；蛘哒f，軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計的一批測試用例（即輸入一些數(shù)據(jù)而得到其預(yù)期的結(jié)果），并利用這些測試用例去運(yùn)行程序，以發(fā)現(xiàn)程序錯誤的過程。軟件測試在軟件生存期中橫跨兩個階段：通常在編寫出每一個模塊之后就對它做必要的測試（稱為單元測試）。編碼與單元測試屬于軟件生存期中的同一個階段。在結(jié)束這個階段之后，對軟件系統(tǒng)還要進(jìn)行各種終合測試，這是軟件生存期的另一個階段，即測試階段，通常由專門的測試人員承擔(dān)這項(xiàng)工作。大量統(tǒng)計資料表明，軟件測試的工作量往往占軟件開發(fā)總工作量的40以上，在極

13、端情況，測試那種關(guān)系人的生命安全的軟件所花費(fèi)的成本，可能相當(dāng)于軟件工程其他開發(fā)步驟總成本的三倍到五倍。因此，必須高度重視軟件測試工作，絕不要以為寫出程序之后軟件開發(fā)工作就接近完成了，實(shí)際上，大約還有同樣多的開發(fā)工作量需要完成。僅就測試而言，它的目標(biāo)是發(fā)現(xiàn)軟件中的錯誤，但是，發(fā)現(xiàn)錯誤并不是我們的最終目的。軟件工程的根本目標(biāo)是開發(fā)出高質(zhì)量的完全符合用戶需要的軟件。 軟件測試的目的 基于不同的立場，存在著兩種完全不同的測試目的。從用戶的角度出發(fā)，普遍希望通過軟件測試暴露出軟件中陷藏的錯誤和缺陷，以考慮是否可以接受該產(chǎn)品。而從軟件開發(fā)者的角度出發(fā)，則希望測試成為表明軟件產(chǎn)品中不存在錯誤的過程，驗(yàn)證該軟

14、件已正確地實(shí)現(xiàn)了用戶的要求，確立用戶對軟件質(zhì)量的信心。因?yàn)樵诔绦蛑型嬖谥S多預(yù)料不到的問題，可能會被疏漏，許多隱藏的錯誤只有在特定的環(huán)境下才可能暴露出來。如果不把著眼點(diǎn)放在盡可能查找錯誤這樣一個基礎(chǔ)上，這些隱藏的錯誤和缺陷就查不出來，會遺留到運(yùn)行階段中去。如果站在用戶的角度替他們設(shè)想，就應(yīng)當(dāng)把測試活動的目標(biāo)對準(zhǔn)揭露程序中存在的錯誤。在選取測試用例時，考慮那些易于發(fā)現(xiàn)程序錯誤的數(shù)據(jù)。下面這些規(guī)則也可以看作是測試的目的或定義：1.測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程； 2.好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案； 3.成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。 從

15、上述規(guī)則可以看出，測試的正確定義是“為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程”。這和某些人通常想象的“測試是為了表明程序是正確的”，“成功的測試是沒有發(fā)現(xiàn)錯誤的測試”等等是完全相反的。正確認(rèn)識測試的目標(biāo)是十分重要的，測試目標(biāo)決定了測試方案的設(shè)計。如果為了表明程序是正確的而進(jìn)行測試，就會設(shè)計一些不易暴露錯誤的測試方案；相反，如果測試是為了發(fā)現(xiàn)程序中的錯誤，就會力求設(shè)計出最能暴露錯誤的測試方案。由于測試的目標(biāo)是暴露程序中的錯誤，從心理學(xué)角度看，由程序的編寫者自己進(jìn)行測試是不恰當(dāng)?shù)?。因此，在綜合測試階段通常由其他人員組成測試小組來完成測試工作。此外，應(yīng)該認(rèn)識到測試決不能證明程序是正確的。即使經(jīng)過了最嚴(yán)格

16、的測試之后，仍然可能還有沒被發(fā)現(xiàn)的錯誤潛藏在程序中。測試只能查找出程序中的錯誤，不能證明程序中沒有錯誤。 返回導(dǎo)航 術(shù)語、名詞定義 1.黑盒測試黑盒測試也稱為功能測試,它著眼于程序的外部特征,而不考慮程序的內(nèi)部邏輯結(jié)構(gòu)。測試者把被測程序看成一個黑盒,不用關(guān)心程序的內(nèi)部結(jié)構(gòu)。黑盒測試是在程序接口處進(jìn)行測試，它只檢查程序功能是否能正常使用，程序是否能接收輸入數(shù)據(jù)產(chǎn)生正確的輸出信息，并且保持外部信息(如數(shù)據(jù)庫或文件)的完整性。黑盒測試是基于用戶角度進(jìn)行的測試。2.白盒測試軟件測試的主要方法之一，也稱結(jié)構(gòu)測試、邏輯驅(qū)動測試或基于程序本身的測試。測試者需要了解待測試程序代碼的內(nèi)部結(jié)構(gòu)、算法等信息，這是從

17、程序設(shè)計者的角度對程序進(jìn)行的測試。它的優(yōu)點(diǎn)是幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質(zhì)量，發(fā)現(xiàn)代碼中隱藏的問題。 3.灰盒測試可以理解為靜態(tài)的白盒測試或動態(tài)的黑盒測試，灰盒就是界于黑白之間, 對軟件內(nèi)部有所了解, 但不見得到了如指掌的程度, 卻可以結(jié)合這些了解做些比黑盒多點(diǎn)的測試。4.文檔測試文檔測試涵蓋面很大，在軟件的各個版本中均有所使用。隨著軟件版本的變化，文檔測試的測試內(nèi)容也有所變化。在需求分析以及原型架構(gòu)階段，文檔測試主要目標(biāo)是： sitemap、動作分解列表、數(shù)據(jù)庫er圖、uml用例圖、流程圖、需求文檔等文檔。文檔測試主要檢查文檔的正確性、完整性和可理解性。正確性是指不要把軟件的

18、功能和操作寫錯，也不允許文檔內(nèi)容前后矛盾。完整性是指文檔不可以漏掉關(guān)鍵性內(nèi)容?？衫斫庑允侵冈谖臋n中描述的語言要簡明易懂，不能讓別的開發(fā)人員拿到文檔時看不懂文檔的內(nèi)容。5.命名規(guī)范測試命名規(guī)范測試用于測試項(xiàng)目中的文件命名、代碼以及版本號等書寫是否符合規(guī)范。文件命名規(guī)范以及版本號命名規(guī)范可以參看第四部分里軟件命名規(guī)范的詳細(xì)信息；各種語言的命名規(guī)范可以參考語言自身的規(guī)范，如noahweb的可以參考 附錄中的noahweb各類資源命名規(guī)范。6.需求完整性測試需求完整性測試主要存在于需求探索階段，在需求尚未完全明確之前對已收集到的需求做出整理性的、檢查遺漏性的測試，確認(rèn)需求是否明確。另外，需求完整性測試

19、也承擔(dān)著一部分澄清需求的任務(wù)。7.鏈接完整性測試在原型架構(gòu)階段，鏈接完整性的測試是非常有必要的。該項(xiàng)測試任務(wù)主要是檢查假頁面中各種鏈接是否完整，是否指向目標(biāo)位置，屬于檢查性的測試。 8.頁面完整性測試頁面完整性測試主要存在于集成測試階段以及其后續(xù)其它階段中，測試頁面是否完整，頁面質(zhì)量是否達(dá)標(biāo)，屬于檢查性測試。9.ui合理性測試ui合理性測試也就是人機(jī)交互界面的合理性，ui合理性測試的內(nèi)容很多，具體測試內(nèi)容如下： o提示、菜單、幫助的格式是否一致； o提示、菜單、幫助中的術(shù)語是否一致； o各個控件之間的對齊方式是否一致； o輸入界面和輸出界面在外觀、布局、交互方式上是否一致； o功能類似的相關(guān)界

20、面在外觀、布局、交互方式上是否一致； o同一層次的文字在同一種提示場合（一般情況、特殊字體、警告等）在文字大小、字體、顏色、對齊方式方面是否一致，字體大小 是否與界面的大小比例協(xié)調(diào)； o多個連續(xù)界面依次出現(xiàn)的情況下，界面的外觀、操作方式是否一致； o系統(tǒng)是否拒絕客戶的錯誤輸入并做出提示； o系統(tǒng)是否在用戶完成操作時給出操作成功的提示； o用戶界面是否存在空白空間，沒有空白空間的界面是雜亂無章的，易用性差； o各個控件的間隔是否一致，垂直和水平方向上是否對齊； o是否允許動作的可逆性，返回原有操做；10.數(shù)據(jù)和數(shù)據(jù)庫完整性測試因?yàn)樵陂_發(fā)階段開發(fā)人員隨時都有可能根據(jù)需要來修改數(shù)據(jù)庫，所以對數(shù)據(jù)和數(shù)

21、據(jù)庫完整性測試在軟件項(xiàng)目的任何階段也是非常必要的。該項(xiàng)測試內(nèi)容主要是以數(shù)據(jù)庫表為單位，檢查數(shù)據(jù)庫表以及表中各字段命名是否符合命名規(guī)范，表中字段是否完整，數(shù)據(jù)庫表中的字段描述是否正確包括字段的類型、長度、是否為空，數(shù)據(jù)庫表中的關(guān)系、索引、主鍵、約束是否正確。11.功能測試功能測試在軟件項(xiàng)目的任何階段中都是重要的。實(shí)現(xiàn)功能，滿足客戶需求是軟件本身最大的使命。功能測試在任何階段下基本上都作為測試工作的第一項(xiàng)出現(xiàn)。該項(xiàng)測試任務(wù)主要為了測試已實(shí)現(xiàn)的功能是否滿足需求，是否正確，是否有價值以及是否完整。在黑盒和白盒測試狀態(tài)下，該測試均會被使用。功能測試中測試人員往往會忽略掉一些細(xì)節(jié)問題，比如：一個功能的實(shí)現(xiàn)

22、必須要經(jīng)過6步操作才能完成，而且需要加入20條信息才能看得出測試結(jié)果，有的測試人員為了節(jié)省時間雖然做完了6步操作，但是沒有加入足量的信息，,使得測試不全面,正是因?yàn)檫@樣而導(dǎo)致一些隱藏的bug沒有被測試出來。所以說在功能測試中要按部就班的把所有要進(jìn)行的測試功能每一步都執(zhí)行一遍，應(yīng)該添加的數(shù)據(jù)都添加完整，以避免遺漏掉bug沒有測試出來。12.壓力測試壓力測試是為了發(fā)現(xiàn)在什么條件下您的應(yīng)用程序的性能會變得不可接受。這通過改變應(yīng)用程序的輸入以對應(yīng)用程序施加越來越大的負(fù)載并測量在這些不同的輸入時性能的改變來實(shí)現(xiàn)的。這種操作也稱為負(fù)載測試，但是負(fù)載測試通常描述一種特定類型的壓力測試增加用戶數(shù)量以對應(yīng)用程序

23、進(jìn)行壓力測試。對應(yīng)用程序進(jìn)行壓力測試最簡單的方法是手工改變輸入（客戶機(jī)數(shù)量、需求大小、請求的頻率、請求的混合程度等等）并描繪性能的變化。但是如果有許多輸入，或者需要在大的范圍內(nèi)改變輸入，那么你可以借助一個自動化的壓力測試工具來完成此測試。13.安全性測試安全性測試主要是測試系統(tǒng)在沒有授權(quán)的內(nèi)部或者外部用戶對系統(tǒng)進(jìn)行攻擊或者惡意破壞時如何進(jìn)行處理，是否仍能保證數(shù)據(jù)和頁面的安全。測試人員可以學(xué)習(xí)一些黑客技術(shù)，來對系統(tǒng)進(jìn)行攻擊。 另外，對操作權(quán)限的測試也包含在安全性測試中。具體測試內(nèi)容如下：o執(zhí)行添加、刪除、修改等動作中是否做過登錄檢測。 o退出系統(tǒng)之后的操作是否可以完成。 o所有插入表單操作中輸入

24、特殊字符是否可以正常輸正常存儲，特殊字符為：！?#￥%*（）-+=、|；：”？/<>，。 o在帶有參數(shù)的回顯數(shù)據(jù)的動作中更改參數(shù)，把參數(shù)改為特殊字符并加入操作語句看是否出錯。 o測試表單中有沒有做標(biāo)簽檢測，標(biāo)簽檢測是否完整。 o在插入表單中加入特殊的html代碼，例如：<marquee>表單中的字本是否移動？</marquee>。14.頁面腳本測試頁面中時常使用到j(luò)avascript腳本，為了降低頁面的出錯率，則必須對頁面腳本進(jìn)行測試。其主要內(nèi)容包括：相關(guān)頁面中的腳本是否正常運(yùn)行，javascript腳本是否有錯誤頁面。 15.提示文本測試提示文本測試從嚴(yán)格

25、意義上來講應(yīng)該屬于ui合理性測試的一部分，該項(xiàng)測試主要針對各個頁面中使用到的大量提示文檔進(jìn)行測試，主要包括：表達(dá)不明確的位置是否有提示文本、提示文本的彈出是否正常、提示信息含義是否明確易懂。16.瀏覽器測試由于b/s結(jié)構(gòu)項(xiàng)目是基于瀏覽器運(yùn)行的，所以需要對瀏覽器進(jìn)行必要的測試。該測試任務(wù)主要是軟件對各種瀏覽器（ie5.5、ie6.0、 firefox瀏覽器 ）的支持是否正常，在ie瀏覽器中可以正常顯示的頁面在其它瀏覽器中是否可以正常顯示。17.安裝測試在軟件項(xiàng)目的后期階段，會對做好的軟件進(jìn)行打包把軟件做成安裝程序，以便用戶可以正確的安裝使用，所以需要對做好的安裝文件進(jìn)行安裝功能方面的測試。該測試

26、的主要任務(wù)是：檢查軟件是否能夠正常安裝使用、是否可以完全卸載此軟件的所有功能和頁面。18.自定義測試在常規(guī)測試時可能表中的測試項(xiàng)不能滿足測試要求，如果有特殊測試項(xiàng)請測試人員自己定義修改測試的類型。 軟件命名規(guī)范 1.軟件版本階段說明obase版: 此版本表示該軟件僅僅是一個假頁面鏈接，通常包括所有的功能和頁面布局，但是頁面中的功能都沒有做完整的實(shí)現(xiàn)，只是做為整體網(wǎng)站的一個基礎(chǔ)架構(gòu)。oalpha版: 此版本表示該軟件在此階段主要是以實(shí)現(xiàn)軟件功能為主，通常只在軟件開發(fā)者內(nèi)部交流，一般而言，該版本軟件的bug較多，需要繼續(xù)修改。obeta版: 該版本相對于版已有了很大的改進(jìn)，消除了嚴(yán)重的錯誤，但還是

27、存在著一些缺陷，需要經(jīng)過多次測試來進(jìn)一步消除，此版本主要的修改對像是軟件的ui。orc版: 該版本已經(jīng)相當(dāng)成熟了，基本上不存在導(dǎo)致錯誤的bug，與即將發(fā)行的正式版相差無幾。orelease版: 該版本意味“最終版本”，在前面版本的一系列測試版之后，終歸會有一個正式版本，是最終交付用戶使用的一個版本。該版本有時也稱為標(biāo)準(zhǔn)版。一般情況下，release不會以單詞形式出現(xiàn)在軟件封面上，取而代之的是符號()。 2.版本命名規(guī)范軟件版本號由四部分組成，第一個1為主版本號，第二個1為子版本號，第三個1為階段版本號，第四部分為日期版本號加希臘字母版本號，希臘字母版本號共有5種，分別為：base、alpha、

28、beta、rc、release。例如：1.1.1.051021_beta。 版本號定修改規(guī)則：o主版本號(1)：當(dāng)功能模塊有較大的變動，比如增加多個模塊或者整體架構(gòu)發(fā)生變化。此版本號由項(xiàng)目決定是否修改。o子版本號(1)：當(dāng)功能有一定的增加或變化，比如增加了對權(quán)限控制、增加自定義視圖等功能。此版本號由項(xiàng)目決定是否修改。o階段版本號(1)：一般是 bug 修復(fù)或是一些小的變動，要經(jīng)常發(fā)布修訂版，時間間隔不限，修復(fù)一個嚴(yán)重的bug即可發(fā)布一個修訂版。此版本號由項(xiàng)目經(jīng)理決定是否修改。o日期版本號(051021):用于記錄修改項(xiàng)目的當(dāng)前日期，每天對項(xiàng)目的修改都需要更改日期版本號。此版本號由開發(fā)人員決定是

29、否修改。 o希臘字母版本號(beta):此版本號用于標(biāo)注當(dāng)前版本的軟件處于哪個開發(fā)階段，當(dāng)軟件進(jìn)入到另一個階段時需要修改此版本號。此版本號由項(xiàng)目決定是否修改。 3.文件命名規(guī)范文件名稱由四部分組成：第一部分為項(xiàng)目名稱，第二部分為文件的描述，第三部分為當(dāng)前軟件的版本號，第四部分為文件階段標(biāo)識加文件后綴，例如：項(xiàng)目外包平臺測試報告1.1.1.051021_beta_b.xls，此文件為項(xiàng)目外包平臺的測試報告文檔，版本號為：1.1.1.051021_beta。 如果是同一版本同一階段的文件修改過兩次以上，則在階段標(biāo)識后面加以數(shù)字標(biāo)識，每次修改數(shù)字加1，項(xiàng)目外包平臺測試報告1.1.1.051021_b

30、eta_b1.xls當(dāng)有多人同時提交同一份文件時，可以在階段標(biāo)識的后面加入人名或縮寫來區(qū)別，例如：項(xiàng)目外包平臺測試報告1.1.1.051021_beta_b_liuqi.xls。當(dāng)此文件再次提交時也可以在人名或人名縮寫的后面加入序號來區(qū)別，例如：項(xiàng)目外包平臺測試報告1.1.1.051021_beta_b_liuqi2.xls4.版本號的階段標(biāo)識軟件的每個版本中包括11個階段，詳細(xì)階段描述如下： 階段名稱 階段標(biāo)識需求控制a 設(shè)計階段 b編碼階段c 單元測試 d 單元測試修改e 集成測試f集成測試修改g 系統(tǒng)測試h系統(tǒng)測試修改i 驗(yàn)收測試j驗(yàn)收測試修改k5.測試任務(wù)描述在軟件的開發(fā)過程中每個版本

31、都會經(jīng)歷四次測試任務(wù)，分別為：單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試，在這四次測試任務(wù)中，每次測試都有不同的測試方向和重點(diǎn)。1.單元測試單元測試是軟件開發(fā)過程中要進(jìn)行的最基本的測試，屬于白盒測試范圍，一般情況下是在開發(fā)人員完成了某個單獨(dú)模塊的編碼之后做的測試。它的目的是檢查軟件編碼的正確性以及一些規(guī)范性測試，站在開發(fā)人員的角度上來查找軟件所存在的bug并記錄下產(chǎn)生bug的原因，以便開發(fā)人員進(jìn)行修改。這樣可以在很大程度上減少集成以后而出現(xiàn)的bug。一旦編碼完成，開發(fā)人員總是會迫切希望進(jìn)行軟件的集成工作，這樣他們就能夠看到實(shí)際的系統(tǒng)開始啟動工作了。 這在外表上看來是一項(xiàng)明顯的進(jìn)步，而象單元測試會推

32、遲對整個系統(tǒng)進(jìn)行合并這種真正有意思的工作啟動的時間。這種開發(fā)步驟中，真實(shí)意義上的進(jìn)步被軟件合并后的外表上的進(jìn)步取代了。系統(tǒng)能夠正常工作的可能性是很小的，更多的情況是充滿了各式各樣的bug?，F(xiàn)實(shí)的開發(fā)中，沒有單元測試的軟件常常會導(dǎo)致這樣的結(jié)果，軟件甚至無法運(yùn)行。更進(jìn)一步的結(jié)果是大量的時間將被花費(fèi)在本應(yīng)該在單元測試?yán)锞屯瓿傻暮唵蝏ug上面，在個別情況下，這些bug也許是瑣碎和微不足道的，但是總的來說，他們會延長軟件集成為一個系統(tǒng)的時間， 而且當(dāng)這個系統(tǒng)投入使用時也無法確保它能夠可靠運(yùn)行。單元測試不僅僅是作為無錯編碼一種輔助手段在一次性的開發(fā)過程中使用，單元測試應(yīng)該是可重復(fù)的，無論是在軟件修改，或是

33、移植到新的運(yùn)行環(huán)境的過程中。因此，所有的測試都必須在整個軟件系統(tǒng)的生命周期中進(jìn)行，也就是說每個版本的開發(fā)都需要經(jīng)過單元測試，這樣可以在以后的開發(fā)階段減少很多不必要的麻煩。單元測試的重點(diǎn)測試內(nèi)容包括：源代碼測試、命名規(guī)范測試、需求完整性測試、頁面完整性測試、提示文本測試、頁面腳本測試等。2.集成測試集成測試也屬于白盒測試范圍，是在單元測試的基礎(chǔ)上將軟件的多個模塊或者系統(tǒng)前后臺合并之后進(jìn)行的測試，也可以算是對單元測試修改進(jìn)行的復(fù)審測試。在集成測試中可以彌補(bǔ)單元測試中沒有測試到的bug，也可以檢查出單元測試沒法測試的功能，比如前后臺的集成之后的關(guān)聯(lián)功能，對于這些有關(guān)聯(lián)性功能的測試，單元測試中是無能為

34、力的，必須依靠集成測試來保證功能的完整性和正確性。和系統(tǒng)測試相比較集成測試從程序結(jié)構(gòu)出發(fā)，目的性、針對性更強(qiáng)，發(fā)現(xiàn)問題的效率高，較容易測試特殊的處理流程中存在的bug。集成測試的重點(diǎn)測試內(nèi)容包括：鏈接完整性測試、頁面完整性測試、數(shù)據(jù)和數(shù)據(jù)庫完整性測試、功能測試、壓力測試、安全性測試、頁面腳本測試、提示文本測試等。3.系統(tǒng)測試系統(tǒng)測試屬于黑盒測試范圍，是在系統(tǒng)集成測試修改完bug之后進(jìn)行的測試。從軟件工程和測試的分類來看：集成測試在系統(tǒng)測試之前就必須要進(jìn)行完畢，只有集成測試完成了，才能保證相應(yīng)的系統(tǒng)測試進(jìn)行。也就是說，集成測試是系統(tǒng)測試的基礎(chǔ)。系統(tǒng)測試是針對整個產(chǎn)品的全面測試，既包含各模塊的驗(yàn)證

35、性測試和功能合理性測試，又包括對整個產(chǎn)品的可靠性、健壯性、安全性、ui合理性及各種性能參數(shù)的測試。系統(tǒng)測試的重點(diǎn)測試內(nèi)容包括：鏈接完整性測試、ui合理性測試、命名規(guī)范測試、功能測試、壓力測試、頁面完整性測試、安裝測試、提示文本測試、游覽器測試等。4.驗(yàn)收測試驗(yàn)收測試屬于黑盒測試范圍，是對系統(tǒng)測試修改后的復(fù)審，這方面和集成測試有些類似，首先確認(rèn)系統(tǒng)測試中的bug已經(jīng)按要求修改完成，然后檢測一下功能是否符合用戶的需求、文檔是否完整、有沒有前面測試中遺漏沒有測試出來的bug。要說明的一點(diǎn)是，此處的驗(yàn)收測試并非客戶驗(yàn)收測試，這里沒有客戶參與測試，只有測試人員參與測試。驗(yàn)收測試是開發(fā)結(jié)束或進(jìn)入下一版本的

36、標(biāo)志性測試。驗(yàn)收測試的重點(diǎn)測試內(nèi)容包括：鏈接完整性測試、ui合理性測試、功能測試、壓力測試、頁面完整性測試、提示文本測試、瀏覽器測試、安裝測試。 測試工作流程圖軟件在開發(fā)過程中共有五個版本，分別是base版、alpha版、beta版、rc版、release版，每個版本的開發(fā)中都需要經(jīng)過上述四次測試，但是每個版本中各階段的測試重點(diǎn)是不一樣的，詳細(xì)的測試流程和重點(diǎn)請看下面各版本流程圖：1.base版各個測試階段流程圖測試提交文檔測試文檔使用方法在測試的過程中測試人員會用到三張表，第一張表是“測試任務(wù)表”，這張表中記錄的是軟件在每個版本的每個階段中需要做的具體測試任務(wù)，如果測試中不確定需要做哪些測試

37、，在這張表中可以查詢各個階段中所要進(jìn)行的測試項(xiàng)。還有兩張表是需要在相應(yīng)測試階段來添寫的測試文檔，分別是“白盒缺陷測試報告”和“黑盒測試缺陷報告”兩張表。單元測試和集成測試屬于白盒測試范圍，需要添寫白盒缺陷測試報告；系統(tǒng)測試和驗(yàn)收測試屬于黑盒測試范圍，需要添寫黑盒測試缺陷報告。測試人員測試完成之后，需要把所添寫的缺陷測試報告按時提交給項(xiàng)目經(jīng)理，由項(xiàng)目經(jīng)理來安排具體人員進(jìn)行修改和審核。測試文檔下載測試任務(wù)表白盒缺陷測試報告黑盒缺陷測試報告注：在每次的測試中測試人員需要按表中的要求進(jìn)行添寫測試報告，然后由項(xiàng)目經(jīng)理來分配給開發(fā)人員處理，開發(fā)人員修改完bug之后再交由項(xiàng)目經(jīng)理來分配給測試人進(jìn)行修改后的復(fù)

38、審，檢查前面測試出來的bug是否已經(jīng)修改完成，在此要特別說明的一點(diǎn)是：為了讓測試報告更方便查看，如果在復(fù)審過程中查出還有bug沒有修改完或是根本沒有修改，則在復(fù)審描述中說明原因，然后把此處標(biāo)注成新的bug索引項(xiàng)指到新的bug編號上測試方法和方式測試方式主要以手工測試為主，在條件允許的情況下使用自動化測試工具進(jìn)行測試。測試方法測試覆蓋率執(zhí)行人員描述黑盒測試100%測試人員功能測試或數(shù)據(jù)驅(qū)動測試灰盒測試1020%測試或開發(fā)人員靜態(tài)的白盒測試或動態(tài)的黑盒測試白盒測試5%開發(fā)人員結(jié)構(gòu)測試或邏輯驅(qū)動測試說明：黑盒測試是依據(jù)用戶能看到的規(guī)格說明，即針對命令、信息、報表等用戶界面及體現(xiàn)他們的輸入數(shù)據(jù)與輸出數(shù)

39、據(jù)之間的對應(yīng)關(guān)系，特別是針對功能進(jìn)行測試。主要由客戶或系統(tǒng)使用者完成執(zhí)行黑盒測試。黑盒測試覆蓋范圍: 測試用例覆蓋：測試的每一個用例都被測試過。輸入覆蓋：測試過程中所輸入的數(shù)據(jù)或資料必須一再的試驗(yàn)，如在程序安裝過程中輸入用戶名時，測試者必須反復(fù)輸入不同長度的中文、英文或數(shù)字等來做測試。輸出覆蓋：測試過程中程序所產(chǎn)生的行為、反映及數(shù)據(jù)必須都一再的試驗(yàn)，如不同情況的對話窗口的內(nèi)容、運(yùn)算結(jié)果數(shù)據(jù)等都必須反復(fù)地測試審核。通過測試的標(biāo)準(zhǔn)一般有“基于測試用例”和“基于缺陷密度”兩種評比準(zhǔn)則，在這里我們采用前者。準(zhǔn)則如下：1. 功能性測試用例通過率達(dá)到100；2. 非功能性測試用例通過率達(dá)到95；備選通過辦

40、法：根據(jù)實(shí)際情況由項(xiàng)目經(jīng)理和測試負(fù)責(zé)人以及用戶等共同討論確定本階段是否結(jié)束。實(shí)施建議對于系統(tǒng)的一些實(shí)施建議：o對系統(tǒng)測試人員進(jìn)行必要的培訓(xùn)，提高他們的測試效率。 o項(xiàng)目經(jīng)理和測試小組根據(jù)項(xiàng)目的資源、時間等限制因素，設(shè)法合理地減少測試的工作量，例如減少“冗余或無效”的測試。 附錄一：缺陷分類類 別描 述需求缺陷1） 需求有誤 2） 需求邏輯錯誤 3） 需求不完備4） 需求文檔描述問題 5） 需求更改設(shè)計缺陷功能的使用對用戶帶來不便及不符合行業(yè)標(biāo)準(zhǔn)的：1） 設(shè)計不合理 2） 設(shè)計文檔描述問題 3） 設(shè)計變更帶來的問題功能和性能缺陷功能沒有達(dá)到需求的要求，或功能存在嚴(yán)重缺陷，系統(tǒng)在運(yùn)行過程中存在性能

41、瓶頸，或?qū)ο到y(tǒng)性能有影響的功能：1） 功能或性能有誤 2） 性能不完全 3） 功能不完全4） 適應(yīng)范圍有問題 5） 用戶信息和診斷信息有誤 6） 異常情況處理有誤7） 其他功能錯誤界面缺陷系統(tǒng)上圖片、文字、按鈕等出現(xiàn)明顯錯誤數(shù)據(jù)錯誤訪問數(shù)據(jù)庫時出錯，得出的數(shù)據(jù)錯誤：1） 數(shù)據(jù)定義數(shù)據(jù)結(jié)構(gòu)錯誤 2） 數(shù)據(jù)存取及數(shù)據(jù)操作錯誤 3） 其它數(shù)據(jù)問題結(jié)構(gòu)缺陷1） 控制流和控制順序錯 2） 處理錯實(shí)現(xiàn)與編碼缺陷1） 編碼錯誤 2） 違背編碼風(fēng)格或標(biāo)準(zhǔn)3） 文檔有誤 4） 其它實(shí)現(xiàn)的問題系統(tǒng)結(jié)構(gòu)缺陷1） 操作系統(tǒng)引用或使用錯誤 2） 軟件結(jié)構(gòu)錯誤 3） 恢復(fù)錯誤4） 執(zhí)行錯誤 5） 診斷錯誤 6） 分割覆蓋

42、錯誤 7） 引用環(huán)境錯誤測試設(shè)計與測試執(zhí)行錯誤1） 測試設(shè)計錯誤 2） 測試執(zhí)行錯誤 3） 測試文檔有誤 4） 測試用例不充分5） 其他測試錯誤計算錯誤數(shù)學(xué)結(jié)算錯誤不同硬件設(shè)備所產(chǎn)生的錯誤所產(chǎn)生的問題與硬件設(shè)備直接有關(guān)其他錯誤測試者檢查出來的且不包括在以上所有類型中的錯誤附錄二：缺陷嚴(yán)重程度類 別描 述1-致命1）可能有災(zāi)難性的后果，如造成系統(tǒng)崩潰，造成事故等2） 程序無法運(yùn)行2-嚴(yán)重產(chǎn)生錯誤的結(jié)果，導(dǎo)致系統(tǒng)不穩(wěn)定的問題，運(yùn)行時好時壞：1）造成數(shù)據(jù)庫不穩(wěn)定的錯誤3）列在說明中的需求未在最終系統(tǒng)中實(shí)現(xiàn)4）業(yè)務(wù)流程不正確3-一般不正確的，但不會影響系統(tǒng)穩(wěn)定性的：1） 過程調(diào)用或其它腳本錯誤2） 系

43、統(tǒng)刷新錯誤3） 產(chǎn)生錯誤結(jié)果，如計算結(jié)果錯誤等4） 功能的實(shí)現(xiàn)有問題。如在系統(tǒng)實(shí)現(xiàn)的界面上，一些可接受輸入的控件點(diǎn)擊后無作用，對數(shù)據(jù)庫的操作不能正確實(shí)現(xiàn)5） 編碼時數(shù)據(jù)類型、長度定義錯誤的6） 對用戶的使用有操作順序上的限制7） 雖然正確性不受影響，但系統(tǒng)性能和響應(yīng)時間受到影響4-輕微不正確的，但有使系統(tǒng)使用起來不太方便的錯誤：1）系統(tǒng)的提示語不明確，不簡明2）滾動條無效3）可編輯區(qū)和不可編輯區(qū)不明顯4）光標(biāo)跳轉(zhuǎn)設(shè)置不好，鼠標(biāo)（光標(biāo)）定位錯誤5）上下翻頁，首尾頁定位錯誤6）界面不一致，或界面不正確7）日期或時間初始值錯誤（起止日期、時間沒有限定）8）按鈕或標(biāo)簽上有拼寫錯誤的單詞、不正確的大小寫

44、5-建議1） 容易給用戶誤解和岐議的提示2） 界面需要改進(jìn)的3） 對有疑慮的文檔，提出修改建議附錄三：優(yōu)先級類 別描 述1-立即修改完成（最高）影響測試進(jìn)度的bug， 重大的功能缺陷bug，需要及時處理的 2-下一個階段結(jié)束前必須修改完成功能沒有達(dá)到需求的的bug，設(shè)計上存在輕微缺陷的3-產(chǎn)品推出前必須修改完成系統(tǒng)上圖片、文字、按鈕、翻頁上有的bug或建議4-時間允許再進(jìn)行修改有缺陷，但不影響系統(tǒng)功能，只是系統(tǒng)使用起來不太方便5-下個版本再修改（最低）在此版本中不做修改，進(jìn)入下一版本時再做修改6-無法修改，不做處理因?yàn)樗蟮膬?nèi)容不合理，所以不做處理 金山的軟件測試方向的筆試，考的都是很專業(yè)的測試方面的問題。第一題是如何測試一個安裝程序，選用什么工具，什么方法；用虛擬機(jī)測試安裝程序，在虛擬機(jī)上運(yùn)行安裝程序。主要測試安裝時的安裝目錄、環(huán)境變量、硬件環(huán)境以及卸載過程等。第二題是軟件測試前需要做哪些準(zhǔn)備工作；明確測試對象，了解測試內(nèi)容；根據(jù)相關(guān)文檔（需求文檔和設(shè)計文檔）編寫軟件測試計劃，如測試策略、測試方法；設(shè)計測試用例；搭建測試環(huán)境；最后是執(zhí)行測試。(提交測試報告)第三題是軟件開發(fā)的階段，軟件測試的階段，以及每個階段的任務(wù)；rad(rap application development),就是軟件開發(fā)過程中的一個重要模