欧美成人精品手机在线观看_69视频国产_动漫精品第一页_日韩中文字幕网 - 日本欧美一区二区

LOGO OA教程 ERP教程 模切知識(shí)交流 PMS教程 CRM教程 開(kāi)發(fā)文檔 其他文檔  
 
網(wǎng)站管理員

軟件測(cè)試詳解

admin
2010年12月14日 14:49 本文熱度 3179

什么是軟件測(cè)試


  為了保證軟件的質(zhì)量和可靠性,應(yīng)力求在分析、設(shè)計(jì)等各個(gè)開(kāi)發(fā)階段結(jié)束前,對(duì)軟件進(jìn)行嚴(yán)格技術(shù)評(píng)審。但由于人們能力的局限性,審查不能發(fā)現(xiàn)所有的錯(cuò)誤。而且在編碼階段還會(huì)引進(jìn)大量的錯(cuò)誤。這些錯(cuò)誤和缺陷如果遺留到軟件交付投入運(yùn)行之時(shí),終將會(huì)暴露出來(lái)。但到那時(shí),不僅改正這些錯(cuò)誤的代價(jià)更高,而且往往造成很惡劣的后果。

  軟件測(cè)試就是在軟件投入運(yùn)行前,對(duì)軟件需求分析、設(shè)計(jì)規(guī)格說(shuō)明和編碼的最終復(fù)審,是軟件質(zhì)量保證的關(guān)鍵步驟。如果給軟件測(cè)試下定義,可以這樣講:軟件測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過(guò)程。或者說(shuō),軟件測(cè)試是根據(jù)軟件開(kāi)發(fā)各階段的規(guī)格說(shuō)明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計(jì)的一批測(cè)試用例(即輸入一些數(shù)據(jù)而得到其預(yù)期的結(jié)果),并利用這些測(cè)試用例去運(yùn)行程序,以發(fā)現(xiàn)程序錯(cuò)誤的過(guò)程。

  軟件測(cè)試在軟件生存期中橫跨兩個(gè)階段:通常在編寫(xiě)出每一個(gè)模塊之后就對(duì)它做必要的測(cè)試(稱(chēng)為單元測(cè)試)。編碼與單元測(cè)試屬于軟件生存期中的同一個(gè)階段。在結(jié)束這個(gè)階段之后,對(duì)軟件系統(tǒng)還要進(jìn)行各種終合測(cè)試,這是軟件生存期的另一個(gè)階段,即測(cè)試階段,通常由專(zhuān)門(mén)的測(cè)試人員承擔(dān)這項(xiàng)工作。

  大量統(tǒng)計(jì)資料表明,軟件測(cè)試的工作量往往占軟件開(kāi)發(fā)總工作量的40%以上,在極端情況,測(cè)試那種關(guān)系人的生命安全的軟件所花費(fèi)的成本,可能相當(dāng)于軟件工程其他開(kāi)發(fā)步驟總成本的三倍到五倍。因此,必須高度重視軟件測(cè)試工作,絕不要以為寫(xiě)出程序之后軟件開(kāi)發(fā)工作就接近完成了,實(shí)際上,大約還有同樣多的開(kāi)發(fā)工作量需要完成。僅就測(cè)試而言,它的目標(biāo)是發(fā)現(xiàn)軟件中的錯(cuò)誤,但是,發(fā)現(xiàn)錯(cuò)誤并不是我們的最終目的。軟件工程的根本目標(biāo)是開(kāi)發(fā)出高質(zhì)量的完全符合用戶需要的軟件。

 

 

軟件測(cè)試的目的


  基于不同的立場(chǎng),存在著兩種完全不同的測(cè)試目的。從用戶的角度出發(fā),普遍希望通過(guò)軟件測(cè)試暴露出軟件中陷藏的錯(cuò)誤和缺陷,以考慮是否可以接受該產(chǎn)品。而從軟件開(kāi)發(fā)者的角度出發(fā),則希望測(cè)試成為表明軟件產(chǎn)品中不存在錯(cuò)誤的過(guò)程,驗(yàn)證該軟件已正確地實(shí)現(xiàn)了用戶的要求,確立用戶對(duì)軟件質(zhì)量的信心。

  因?yàn)樵诔绦蛑型嬖谥S多預(yù)料不到的問(wèn)題,可能會(huì)被疏漏,許多隱藏的錯(cuò)誤只有在特定的環(huán)境下才可能暴露出來(lái)。如果不把著眼點(diǎn)放在盡可能查找錯(cuò)誤這樣一個(gè)基礎(chǔ)上,這些隱藏的錯(cuò)誤和缺陷就查不出來(lái),會(huì)遺留到運(yùn)行階段中去。如果站在用戶的角度替他們?cè)O(shè)想,就應(yīng)當(dāng)把測(cè)試活動(dòng)的目標(biāo)對(duì)準(zhǔn)揭露程序中存在的錯(cuò)誤。在選取測(cè)試用例時(shí),考慮那些易于發(fā)現(xiàn)程序錯(cuò)誤的數(shù)據(jù)。

下面這些規(guī)則也可以看作是測(cè)試的目的或定義:


1.    測(cè)試是為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行程序的過(guò)程;


2.    好的測(cè)試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試方案;


3.    成功的測(cè)試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。


  從上述規(guī)則可以看出,測(cè)試的正確定義是為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行程序的過(guò)程。這和某些人通常想象的測(cè)試是為了表明程序是正確的成功的測(cè)試是沒(méi)有發(fā)現(xiàn)錯(cuò)誤的測(cè)試等等是完全相反的。正確認(rèn)識(shí)測(cè)試的目標(biāo)是十分重要的,測(cè)試目標(biāo)決定了測(cè)試方案的設(shè)計(jì)。如果為了表明程序是正確的而進(jìn)行測(cè)試,就會(huì)設(shè)計(jì)一些不易暴露錯(cuò)誤的測(cè)試方案;相反,如果測(cè)試是為了發(fā)現(xiàn)程序中的錯(cuò)誤,就會(huì)力求設(shè)計(jì)出最能暴露錯(cuò)誤的測(cè)試方案。

  由于測(cè)試的目標(biāo)是暴露程序中的錯(cuò)誤,從心理學(xué)角度看,由程序的編寫(xiě)者自己進(jìn)行測(cè)試是不恰當(dāng)?shù)摹R虼耍诰C合測(cè)試階段通常由其他人員組成測(cè)試小組來(lái)完成測(cè)試工作。此外,應(yīng)該認(rèn)識(shí)到測(cè)試決不能證明程序是正確的。即使經(jīng)過(guò)了最嚴(yán)格的測(cè)試之后,仍然可能還有沒(méi)被發(fā)現(xiàn)的錯(cuò)誤潛藏在程序中。測(cè)試只能查找出程序中的錯(cuò)誤,不能證明程序中沒(méi)有錯(cuò)誤。

 

 

術(shù)語(yǔ)、名詞定義


1.      黑盒測(cè)試

  黑盒測(cè)試也稱(chēng)為功能測(cè)試,它著眼于程序的外部特征,而不考慮程序的內(nèi)部邏輯結(jié)構(gòu)。測(cè)試者把被測(cè)程序看成一個(gè)黑盒,不用關(guān)心程序的內(nèi)部結(jié)構(gòu)。黑盒測(cè)試是在程序接口處進(jìn)行測(cè)試,它只檢查程序功能是否能正常使用,程序是否能接收輸入數(shù)據(jù)產(chǎn)生正確的輸出信息,并且保持外部信息(如數(shù)據(jù)庫(kù)或文件)的完整性。黑盒測(cè)試是基于用戶角度進(jìn)行的測(cè)試。


2.      白盒測(cè)試

  軟件測(cè)試的主要方法之一,也稱(chēng)結(jié)構(gòu)測(cè)試、邏輯驅(qū)動(dòng)測(cè)試或基于程序本身的測(cè)試。測(cè)試者需要了解待測(cè)試程序代碼的內(nèi)部結(jié)構(gòu)、算法等信息,這是從程序設(shè)計(jì)者的角度對(duì)程序進(jìn)行的測(cè)試。它的優(yōu)點(diǎn)是幫助軟件測(cè)試人員增大代碼的覆蓋率,提高代碼的質(zhì)量,發(fā)現(xiàn)代碼中隱藏的問(wèn)題。


3.      灰盒測(cè)試

  可以理解為靜態(tài)的白盒測(cè)試或動(dòng)態(tài)的黑盒測(cè)試,灰盒就是界于黑白之間, 對(duì)軟件內(nèi)部有所了解, 但不見(jiàn)得到了如指掌的程度, 卻可以結(jié)合這些了解做些比黑盒多點(diǎn)的測(cè)試。


4.      文檔測(cè)試

  文檔測(cè)試涵蓋面很大,在軟件的各個(gè)版本中均有所使用。隨著軟件版本的變化,文檔測(cè)試的測(cè)試內(nèi)容也有所變化。在需求分析以及原型架構(gòu)階段,文檔測(cè)試主要目標(biāo)是: Sitemap、動(dòng)作分解列表、數(shù)據(jù)庫(kù)ER圖、UML用例圖、流程圖、需求文檔等文檔。

  文檔測(cè)試主要檢查文檔的正確性、完整性和可理解性。正確性是指不要把軟件的功能和操作寫(xiě)錯(cuò),也不允許文檔內(nèi)容前后矛盾。完整性是指文檔不可以漏掉關(guān)鍵性內(nèi)容。可理解性是指在文檔中描述的語(yǔ)言要簡(jiǎn)明易懂,不能讓別的開(kāi)發(fā)人員拿到文檔時(shí)看不懂文檔的內(nèi)容。


5.      命名規(guī)范測(cè)試

  命名規(guī)范測(cè)試用于測(cè)試項(xiàng)目中的文件命名、代碼以及版本號(hào)等書(shū)寫(xiě)是否符合規(guī)范。文件命名規(guī)范以及版本號(hào)命名規(guī)范可以參看第四部分里軟件命名規(guī)范的詳細(xì)信息;各種語(yǔ)言的命名規(guī)范可以參考語(yǔ)言自身的規(guī)范,如NoahWeb的可以參考 http://docs.noahweb.net附錄中的《NoahWeb各類(lèi)資源命名規(guī)范》。


6.      需求完整性測(cè)試

  需求完整性測(cè)試主要存在于需求探索階段,在需求尚未完全明確之前對(duì)已收集到的需求做出整理性的、檢查遺漏性的測(cè)試,確認(rèn)需求是否明確。另外,需求完整性測(cè)試也承擔(dān)著一部分澄清需求的任務(wù)。


7.      鏈接完整性測(cè)試

  在原型架構(gòu)階段,鏈接完整性的測(cè)試是非常有必要的。該項(xiàng)測(cè)試任務(wù)主要是檢查假頁(yè)面中各種鏈接是否完整,是否指向目標(biāo)位置,屬于檢查性的測(cè)試。


8.      頁(yè)面完整性測(cè)試

  頁(yè)面完整性測(cè)試主要存在于集成測(cè)試階段以及其后續(xù)其它階段中,測(cè)試頁(yè)面是否完整,頁(yè)面質(zhì)量是否達(dá)標(biāo),屬于檢查性測(cè)試。


9.      UI合理性測(cè)試

  UI合理性測(cè)試也就是人機(jī)交互界面的合理性,UI合理性測(cè)試的內(nèi)容很多,具體測(cè)試內(nèi)容如下:


o      提示、菜單、幫助的格式是否一致;


o      提示、菜單、幫助中的術(shù)語(yǔ)是否一致;


o      各個(gè)控件之間的對(duì)齊方式是否一致;


o      輸入界面和輸出界面在外觀、布局、交互方式上是否一致;


o      功能類(lèi)似的相關(guān)界面在外觀、布局、交互方式上是否一致;


o      同一層次的文字在同一種提示場(chǎng)合(一般情況、特殊字體、警告等)在文字大小、字體、顏色、對(duì)齊方式方面是否一致,字體大小是否與界面的大小比例協(xié)調(diào);


o      多個(gè)連續(xù)界面依次出現(xiàn)的情況下,界面的外觀、操作方式是否一致;


o      系統(tǒng)是否拒絕客戶的錯(cuò)誤輸入并做出提示;


o      系統(tǒng)是否在用戶完成操作時(shí)給出操作成功的提示;


o      用戶界面是否存在空白空間,沒(méi)有空白空間的界面是雜亂無(wú)章的,易用性差;


o      各個(gè)控件的間隔是否一致,垂直和水平方向上是否對(duì)齊;


o      是否允許動(dòng)作的可逆性,返回原有操做;


10.   數(shù)據(jù)和數(shù)據(jù)庫(kù)完整性測(cè)試

  因?yàn)樵陂_(kāi)發(fā)階段開(kāi)發(fā)人員隨時(shí)都有可能根據(jù)需要來(lái)修改數(shù)據(jù)庫(kù),所以對(duì)數(shù)據(jù)和數(shù)據(jù)庫(kù)完整性測(cè)試在軟件項(xiàng)目的任何階段也是非常必要的。該項(xiàng)測(cè)試內(nèi)容主要是以數(shù)據(jù)庫(kù)表為單位,檢查數(shù)據(jù)庫(kù)表以及表中各字段命名是否符合命名規(guī)范,表中字段是否完整,數(shù)據(jù)庫(kù)表中的字段描述是否正確包括字段的類(lèi)型、長(zhǎng)度、是否為空,數(shù)據(jù)庫(kù)表中的關(guān)系、索引、主鍵、約束是否正確。


11.   功能測(cè)試

  功能測(cè)試在軟件項(xiàng)目的任何階段中都是重要的。實(shí)現(xiàn)功能,滿足客戶需求是軟件本身最大的使命。功能測(cè)試在任何階段下基本上都作為測(cè)試工作的第一項(xiàng)出現(xiàn)。該項(xiàng)測(cè)試任務(wù)主要為了測(cè)試已實(shí)現(xiàn)的功能是否滿足需求,是否正確,是否有價(jià)值以及是否完整。在黑盒和白盒測(cè)試狀態(tài)下,該測(cè)試均會(huì)被使用。

  功能測(cè)試中測(cè)試人員往往會(huì)忽略掉一些細(xì)節(jié)問(wèn)題,比如:一個(gè)功能的實(shí)現(xiàn)必須要經(jīng)過(guò)6步操作才能完成,而且需要加入20條信息才能看得出測(cè)試結(jié)果,有的測(cè)試人員為了節(jié)省時(shí)間雖然做完了6步操作,但是沒(méi)有加入足量的信息,,使得測(cè)試不全面,正是因?yàn)檫@樣而導(dǎo)致一些隱藏的BUG沒(méi)有被測(cè)試出來(lái)。所以說(shuō)在功能測(cè)試中要按部就班的把所有要進(jìn)行的測(cè)試功能每一步都執(zhí)行一遍,應(yīng)該添加的數(shù)據(jù)都添加完整,以避免遺漏掉BUG沒(méi)有測(cè)試出來(lái)。


12.   壓力測(cè)試

  壓力測(cè)試是為了發(fā)現(xiàn)在什么條件下您的應(yīng)用程序的性能會(huì)變得不可接受。這通過(guò)改變應(yīng)用程序的輸入以對(duì)應(yīng)用程序施加越來(lái)越大的負(fù)載并測(cè)量在這些不同的輸入時(shí)性能的改變來(lái)實(shí)現(xiàn)的。這種操作也稱(chēng)為負(fù)載測(cè)試,但是負(fù)載測(cè)試通常描述一種特定類(lèi)型的壓力測(cè)試——增加用戶數(shù)量以對(duì)應(yīng)用程序進(jìn)行壓力測(cè)試。

  對(duì)應(yīng)用程序進(jìn)行壓力測(cè)試最簡(jiǎn)單的方法是手工改變輸入(客戶機(jī)數(shù)量、需求大小、請(qǐng)求的頻率、請(qǐng)求的混合程度等等)并描繪性能的變化。但是如果有許多輸入,或者需要在大的范圍內(nèi)改變輸入,那么你可以借助一個(gè)自動(dòng)化的壓力測(cè)試工具來(lái)完成此測(cè)試。


13.   安全性測(cè)試

  安全性測(cè)試主要是測(cè)試系統(tǒng)在沒(méi)有授權(quán)的內(nèi)部或者外部用戶對(duì)系統(tǒng)進(jìn)行攻擊或者惡意破壞時(shí)如何進(jìn)行處理,是否仍能保證數(shù)據(jù)和頁(yè)面的安全。測(cè)試人員可以學(xué)習(xí)一些黑客技術(shù),來(lái)對(duì)系統(tǒng)進(jìn)行攻擊。另外,對(duì)操作權(quán)限的測(cè)試也包含在安全性測(cè)試中。具體測(cè)試內(nèi)容如下:


o      執(zhí)行添加、刪除、修改等動(dòng)作中是否做過(guò)登錄檢測(cè)。


o      退出系統(tǒng)之后的操作是否可以完成。


o      所有插入表單操作中輸入特殊字符是否可以正常輸正常存儲(chǔ),特殊字符為:!?#%……—*()~——-+=[]{}|;:‘”/《》<>,。


o      在帶有參數(shù)的回顯數(shù)據(jù)的動(dòng)作中更改參數(shù),把參數(shù)改為特殊字符并加入操作語(yǔ)句看是否出錯(cuò)。


o      測(cè)試表單中有沒(méi)有做標(biāo)簽檢測(cè),標(biāo)簽檢測(cè)是否完整。


o      在插入表單中加入特殊的HTML代碼,例如:<marquee>表單中的字本是否移動(dòng)?</marquee>


14.   頁(yè)面腳本測(cè)試

  頁(yè)面中時(shí)常使用到JavaScript腳本,為了降低頁(yè)面的出錯(cuò)率,則必須對(duì)頁(yè)面腳本進(jìn)行測(cè)試。其主要內(nèi)容包括:相關(guān)頁(yè)面中的腳本是否正常運(yùn)行,JavaScript腳本是否有錯(cuò)誤頁(yè)面。


15.   提示文本測(cè)試

  提示文本測(cè)試從嚴(yán)格意義上來(lái)講應(yīng)該屬于UI合理性測(cè)試的一部分,該項(xiàng)測(cè)試主要針對(duì)各個(gè)頁(yè)面中使用到的大量提示文檔進(jìn)行測(cè)試,主要包括:表達(dá)不明確的位置是否有提示文本、提示文本的彈出是否正常、提示信息含義是否明確易懂。


16.   瀏覽器測(cè)試

  由于B/S結(jié)構(gòu)項(xiàng)目是基于瀏覽器運(yùn)行的,所以需要對(duì)瀏覽器進(jìn)行必要的測(cè)試。該測(cè)試任務(wù)主要是軟件對(duì)各種瀏覽器(IE5.5IE6.0 FireFox瀏覽器)的支持是否正常,在IE瀏覽器中可以正常顯示的頁(yè)面在其它瀏覽器中是否可以正常顯示。


17.   安裝測(cè)試

  在軟件項(xiàng)目的后期階段,會(huì)對(duì)做好的軟件進(jìn)行打包把軟件做成安裝程序,以便用戶可以正確的安裝使用,所以需要對(duì)做好的安裝文件進(jìn)行安裝功能方面的測(cè)試。該測(cè)試的主要任務(wù)是:檢查軟件是否能夠正常安裝使用、是否可以完全卸載此軟件的所有功能和頁(yè)面。


自定義測(cè)試

  在常規(guī)測(cè)試時(shí)可能表中的測(cè)試項(xiàng)不能滿足測(cè)試要求,如果有特殊測(cè)試項(xiàng)請(qǐng)測(cè)試人員自己定義修改測(cè)試的類(lèi)型。

 

 

軟件命名規(guī)范


1.      軟件版本階段說(shuō)明


o      Base: 此版本表示該軟件僅僅是一個(gè)假頁(yè)面鏈接,通常包括所有的功能和頁(yè)面布局,但是頁(yè)面中的功能都沒(méi)有做完整的實(shí)現(xiàn),只是做為整體網(wǎng)站的一個(gè)基礎(chǔ)架構(gòu)。


o      Alpha: 此版本表示該軟件在此階段主要是以實(shí)現(xiàn)軟件功能為主,通常只在軟件開(kāi)發(fā)者內(nèi)部交流,一般而言,該版本軟件的Bug較多,需要繼續(xù)修改。


o      Beta: 該版本相對(duì)于α版已有了很大的改進(jìn),消除了嚴(yán)重的錯(cuò)誤,但還是存在著一些缺陷,需要經(jīng)過(guò)多次測(cè)試來(lái)進(jìn)一步消除,此版本主要的修改對(duì)像是軟件的UI


o      RC: 該版本已經(jīng)相當(dāng)成熟了,基本上不存在導(dǎo)致錯(cuò)誤的BUG,與即將發(fā)行的正式版相差無(wú)幾。


o      Release: 該版本意味最終版本,在前面版本的一系列測(cè)試版之后,終歸會(huì)有一個(gè)正式版本,是最終交付用戶使用的一個(gè)版本。該版本有時(shí)也稱(chēng)為標(biāo)準(zhǔn)版。一般情況下,Release不會(huì)以單詞形式出現(xiàn)在軟件封面上,取而代之的是符號(hào)()


 


2.      版本命名規(guī)范

  軟件版本號(hào)由四部分組成,第一個(gè)1為主版本號(hào),第二個(gè)1為子版本號(hào),第三個(gè)1為階段版本號(hào),第四部分為日期版本號(hào)加希臘字母版本號(hào),希臘字母版本號(hào)共有5種,分別為:basealphabetaRCrelease。例如:1.1.1.051021_beta



 


版本號(hào)定修改規(guī)則:


o      主版本號(hào)(1)當(dāng)功能模塊有較大的變動(dòng),比如增加多個(gè)模塊或者整體架構(gòu)發(fā)生變化。此版本號(hào)由項(xiàng)目決定是否修改。


o      子版本號(hào)(1)當(dāng)功能有一定的增加或變化,比如增加了對(duì)權(quán)限控制、增加自定義視圖等功能。此版本號(hào)由項(xiàng)目決定是否修改。


o      階段版本號(hào)(1)一般是 Bug 修復(fù)或是一些小的變動(dòng),要經(jīng)常發(fā)布修訂版,時(shí)間間隔不限,修復(fù)一個(gè)嚴(yán)重的bug即可發(fā)布一個(gè)修訂版。此版本號(hào)由項(xiàng)目經(jīng)理決定是否修改。


o      日期版本號(hào)(051021):用于記錄修改項(xiàng)目的當(dāng)前日期,每天對(duì)項(xiàng)目的修改都需要更改日期版本號(hào)。此版本號(hào)由開(kāi)發(fā)人員決定是否修改。


o      希臘字母版本號(hào)(beta):此版本號(hào)用于標(biāo)注當(dāng)前版本的軟件處于哪個(gè)開(kāi)發(fā)階段,當(dāng)軟件進(jìn)入到另一個(gè)階段時(shí)需要修改此版本號(hào)。此版本號(hào)由項(xiàng)目決定是否修改。


 


3.      文件命名規(guī)范

  文件名稱(chēng)由四部分組成:第一部分為項(xiàng)目名稱(chēng),第二部分為文件的描述,第三部分為當(dāng)前軟件的版本號(hào),第四部分為文件階段標(biāo)識(shí)加文件后綴,例如:項(xiàng)目外包平臺(tái)測(cè)試報(bào)告1.1.1.051021_beta_b.xls,此文件為項(xiàng)目外包平臺(tái)的測(cè)試報(bào)告文檔,版本號(hào)為:1.1.1.051021_beta





  如果是同一版本同一階段的文件修改過(guò)兩次以上,則在階段標(biāo)識(shí)后面加以數(shù)字標(biāo)識(shí),每次修改數(shù)字加1,項(xiàng)目外包平臺(tái)測(cè)試報(bào)告1.1.1.051021_beta_b1.xls

  當(dāng)有多人同時(shí)提交同一份文件時(shí),可以在階段標(biāo)識(shí)的后面加入人名或縮寫(xiě)來(lái)區(qū)別,例如:項(xiàng)目外包平臺(tái)測(cè)試報(bào)告1.1.1.051021_beta_b_LiuQi.xls。當(dāng)此文件再次提交時(shí)也可以在人名或人名縮寫(xiě)的后面加入序號(hào)來(lái)區(qū)別,例如:項(xiàng)目外包平臺(tái)測(cè)試報(bào)告1.1.1.051021_beta_b_LiuQi2.xls


4.      版本號(hào)的階段標(biāo)識(shí)

軟件的每個(gè)版本中包括11個(gè)階段,詳細(xì)階段描述如下:









































階段名稱(chēng)


階段標(biāo)識(shí)


需求控制


a


設(shè)計(jì)階段


b


編碼階段


c


單元測(cè)試


d


單元測(cè)試修改


e


集成測(cè)試


f


集成測(cè)試修改


g


系統(tǒng)測(cè)試


h


系統(tǒng)測(cè)試修改


i


驗(yàn)收測(cè)試


j


驗(yàn)收測(cè)試修改


k





測(cè)試任務(wù)描述


  在軟件的開(kāi)發(fā)過(guò)程中每個(gè)版本都會(huì)經(jīng)歷四次測(cè)試任務(wù),分別為:?jiǎn)卧獪y(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試,在這四次測(cè)試任務(wù)中,每次測(cè)試都有不同的測(cè)試方向和重點(diǎn)。


1.      單元測(cè)試

  單元測(cè)試是軟件開(kāi)發(fā)過(guò)程中要進(jìn)行的最基本的測(cè)試,屬于白盒測(cè)試范圍,一般情況下是在開(kāi)發(fā)人員完成了某個(gè)單獨(dú)模塊的編碼之后做的測(cè)試。它的目的是檢查軟件編碼的正確性以及一些規(guī)范性測(cè)試,站在開(kāi)發(fā)人員的角度上來(lái)查找軟件所存在的BUG并記錄下產(chǎn)生BUG的原因,以便開(kāi)發(fā)人員進(jìn)行修改。這樣可以在很大程度上減少集成以后而出現(xiàn)的BUG

  一旦編碼完成,開(kāi)發(fā)人員總是會(huì)迫切希望進(jìn)行軟件的集成工作,這樣他們就能夠看到實(shí)際的系統(tǒng)開(kāi)始啟動(dòng)工作了。 這在外表上看來(lái)是一項(xiàng)明顯的進(jìn)步,而象單元測(cè)試會(huì)推遲對(duì)整個(gè)系統(tǒng)進(jìn)行合并這種真正有意思的工作啟動(dòng)的時(shí)間。

  這種開(kāi)發(fā)步驟中,真實(shí)意義上的進(jìn)步被軟件合并后的外表上的進(jìn)步取代了。系統(tǒng)能夠正常工作的可能性是很小的,更多的情況是充滿了各式各樣的Bug。現(xiàn)實(shí)的開(kāi)發(fā)中,沒(méi)有單元測(cè)試的軟件常常會(huì)導(dǎo)致這樣的結(jié)果,軟件甚至無(wú)法運(yùn)行。更進(jìn)一步的結(jié)果是大量的時(shí)間將被花費(fèi)在本應(yīng)該在單元測(cè)試?yán)锞屯瓿傻暮?jiǎn)單Bug上面,在個(gè)別情況下,這些Bug也許是瑣碎和微不足道的,但是總的來(lái)說(shuō),他們會(huì)延長(zhǎng)軟件集成為一個(gè)系統(tǒng)的時(shí)間,而且當(dāng)這個(gè)系統(tǒng)投入使用時(shí)也無(wú)法確保它能夠可靠運(yùn)行。

  單元測(cè)試不僅僅是作為無(wú)錯(cuò)編碼一種輔助手段在一次性的開(kāi)發(fā)過(guò)程中使用,單元測(cè)試應(yīng)該是可重復(fù)的,無(wú)論是在軟件修改,或是移植到新的運(yùn)行環(huán)境的過(guò)程中。因此,所有的測(cè)試都必須在整個(gè)軟件系統(tǒng)的生命周期中進(jìn)行,也就是說(shuō)每個(gè)版本的開(kāi)發(fā)都需要經(jīng)過(guò)單元測(cè)試,這樣可以在以后的開(kāi)發(fā)階段減少很多不必要的麻煩。

  單元測(cè)試的重點(diǎn)測(cè)試內(nèi)容包括:源代碼測(cè)試、命名規(guī)范測(cè)試、需求完整性測(cè)試、頁(yè)面完整性測(cè)試、提示文本測(cè)試、頁(yè)面腳本測(cè)試等。


2.      集成測(cè)試

  集成測(cè)試也屬于白盒測(cè)試范圍,是在單元測(cè)試的基礎(chǔ)上將軟件的多個(gè)模塊或者系統(tǒng)前后臺(tái)合并之后進(jìn)行的測(cè)試,也可以算是對(duì)單元測(cè)試修改進(jìn)行的復(fù)審測(cè)試。在集成測(cè)試中可以彌補(bǔ)單元測(cè)試中沒(méi)有測(cè)試到的BUG,也可以檢查出單元測(cè)試沒(méi)法測(cè)試的功能,比如前后臺(tái)的集成之后的關(guān)聯(lián)功能,對(duì)于這些有關(guān)聯(lián)性功能的測(cè)試,單元測(cè)試中是無(wú)能為力的,必須依靠集成測(cè)試來(lái)保證功能的完整性和正確性。和系統(tǒng)測(cè)試相比較集成測(cè)試從程序結(jié)構(gòu)出發(fā),目的性、針對(duì)性更強(qiáng),發(fā)現(xiàn)問(wèn)題的效率高,較容易測(cè)試特殊的處理流程中存在的BUG

  集成測(cè)試的重點(diǎn)測(cè)試內(nèi)容包括:鏈接完整性測(cè)試、頁(yè)面完整性測(cè)試、數(shù)據(jù)和數(shù)據(jù)庫(kù)完整性測(cè)試、功能測(cè)試、壓力測(cè)試、安全性測(cè)試、頁(yè)面腳本測(cè)試、提示文本測(cè)試等。


3.      系統(tǒng)測(cè)試

  系統(tǒng)測(cè)試屬于黑盒測(cè)試范圍,是在系統(tǒng)集成測(cè)試修改完BUG之后進(jìn)行的測(cè)試。從軟件工程和測(cè)試的分類(lèi)來(lái)看:集成測(cè)試在系統(tǒng)測(cè)試之前就必須要進(jìn)行完畢,只有集成測(cè)試完成了,才能保證相應(yīng)的系統(tǒng)測(cè)試進(jìn)行。也就是說(shuō),集成測(cè)試是系統(tǒng)測(cè)試的基礎(chǔ)。

  系統(tǒng)測(cè)試是針對(duì)整個(gè)產(chǎn)品的全面測(cè)試,既包含各模塊的驗(yàn)證性測(cè)試和功能合理性測(cè)試,又包括對(duì)整個(gè)產(chǎn)品的可靠性、健壯性、安全性、UI合理性及各種性能參數(shù)的測(cè)試。

  系統(tǒng)測(cè)試的重點(diǎn)測(cè)試內(nèi)容包括:鏈接完整性測(cè)試、UI合理性測(cè)試、命名規(guī)范測(cè)試、功能測(cè)試、壓力測(cè)試、頁(yè)面完整性測(cè)試、安裝測(cè)試、提示文本測(cè)試、游覽器測(cè)試等。


驗(yàn)收測(cè)試

  驗(yàn)收測(cè)試屬于黑盒測(cè)試范圍,是對(duì)系統(tǒng)測(cè)試修改后的復(fù)審,這方面和集成測(cè)試有些類(lèi)似,首先確認(rèn)系統(tǒng)測(cè)試中的BUG已經(jīng)按要求修改完成,然后檢測(cè)一下功能是否符合用戶的需求、文檔是否完整、有沒(méi)有前面測(cè)試中遺漏沒(méi)有測(cè)試出來(lái)的BUG。要說(shuō)明的一點(diǎn)是,此處的驗(yàn)收測(cè)試并非客戶驗(yàn)收測(cè)試,這里沒(méi)有客戶參與測(cè)試,只有測(cè)試人員參與測(cè)試。驗(yàn)收測(cè)試是開(kāi)發(fā)結(jié)束或進(jìn)入下一版本的標(biāo)志性測(cè)試。

  驗(yàn)收測(cè)試的重點(diǎn)測(cè)試內(nèi)容包括:鏈接完整性測(cè)試、UI合理性測(cè)試、功能測(cè)試、壓力測(cè)試、頁(yè)面完整性測(cè)試、提示文本測(cè)試、瀏覽器測(cè)試、安裝測(cè)試。

 

 

測(cè)試工作流程圖


  軟件在開(kāi)發(fā)過(guò)程中共有五個(gè)版本,分別是Base版、Alpha版、Beta版、RC版、Release版,每個(gè)版本的開(kāi)發(fā)中都需要經(jīng)過(guò)上述四次測(cè)試,但是每個(gè)版本中各階段的測(cè)試重點(diǎn)是不一樣的,詳細(xì)的測(cè)試流程和重點(diǎn)請(qǐng)看下面各版本流程圖:


1.      Base版各個(gè)測(cè)試階段流程圖



 


 


 


測(cè)試提交文檔


測(cè)試文檔使用方法


  在測(cè)試的過(guò)程中測(cè)試人員會(huì)用到三張表,第一張表是測(cè)試任務(wù)表,這張表中記錄的是軟件在每個(gè)版本的每個(gè)階段中需要做的具體測(cè)試任務(wù),如果測(cè)試中不確定需要做哪些測(cè)試,在這張表中可以查詢各個(gè)階段中所要進(jìn)行的測(cè)試項(xiàng)。

  還有兩張表是需要在相應(yīng)測(cè)試階段來(lái)添寫(xiě)的測(cè)試文檔,分別是白盒缺陷測(cè)試報(bào)告黑盒測(cè)試缺陷報(bào)告兩張表。單元測(cè)試和集成測(cè)試屬于白盒測(cè)試范圍,需要添寫(xiě)白盒缺陷測(cè)試報(bào)告;系統(tǒng)測(cè)試和驗(yàn)收測(cè)試屬于黑盒測(cè)試范圍,需要添寫(xiě)黑盒測(cè)試缺陷報(bào)告。

  測(cè)試人員測(cè)試完成之后,需要把所添寫(xiě)的缺陷測(cè)試報(bào)告按時(shí)提交給項(xiàng)目經(jīng)理,由項(xiàng)目經(jīng)理來(lái)安排具體人員進(jìn)行修改和審核。


測(cè)試文檔下載


·   測(cè)試任務(wù)表


·   白盒缺陷測(cè)試報(bào)告


黑盒缺陷測(cè)試報(bào)告


注:

  在每次的測(cè)試中測(cè)試人員需要按表中的要求進(jìn)行添寫(xiě)測(cè)試報(bào)告,然后由項(xiàng)目經(jīng)理來(lái)分配給開(kāi)發(fā)人員處理,開(kāi)發(fā)人員修改完BUG之后再交由項(xiàng)目經(jīng)理來(lái)分配給測(cè)試人進(jìn)行修改后的復(fù)審,檢查前面測(cè)試出來(lái)的BUG是否已經(jīng)修改完成,在此要特別說(shuō)明的一點(diǎn)是:為了讓測(cè)試報(bào)告更方便查看,如果在復(fù)審過(guò)程中查出還有BUG沒(méi)有修改完或是根本沒(méi)有修改,則在復(fù)審描述中說(shuō)明原因,然后把此處標(biāo)注成新的BUG索引項(xiàng)指到新的BUG編號(hào)上,詳細(xì)情況請(qǐng)看下面截圖:


 

 

測(cè)試方法和方式


  測(cè)試方式主要以手工測(cè)試為主,在條件允許的情況下使用自動(dòng)化測(cè)試工具進(jìn)行測(cè)試。

























測(cè)試方法


測(cè)試覆蓋率


執(zhí)行人員


描述


黑盒測(cè)試


100%


測(cè)試人員


功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試


灰盒測(cè)試


10~20%


測(cè)試或開(kāi)發(fā)人員


靜態(tài)的白盒測(cè)試或動(dòng)態(tài)的黑盒測(cè)試


白盒測(cè)試


5%


開(kāi)發(fā)人員


結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試


  說(shuō)明:黑盒測(cè)試是依據(jù)用戶能看到的規(guī)格說(shuō)明,即針對(duì)命令、信息、報(bào)表等用戶界面及體現(xiàn)他們的輸入數(shù)據(jù)與輸出數(shù)據(jù)之間的對(duì)應(yīng)關(guān)系,特別是針對(duì)功能進(jìn)行測(cè)試。主要由客戶或系統(tǒng)使用者完成執(zhí)行黑盒測(cè)試。



黑盒測(cè)試覆蓋范圍:



 


·   測(cè)試用例覆蓋:測(cè)試的每一個(gè)用例都被測(cè)試過(guò)。


·   輸入覆蓋:測(cè)試過(guò)程中所輸入的數(shù)據(jù)或資料必須一再的試驗(yàn),如在程序安裝過(guò)程中輸入用戶名時(shí),測(cè)試者必須反復(fù)輸入不同長(zhǎng)度的中文、英文或數(shù)字等來(lái)做測(cè)試。


輸出覆蓋:測(cè)試過(guò)程中程序所產(chǎn)生的行為、反映及數(shù)據(jù)必須都一再的試驗(yàn),如不同情況的對(duì)話窗口的內(nèi)容、運(yùn)算結(jié)果數(shù)據(jù)等都必須反復(fù)地測(cè)試審核。

 

 

通過(guò)測(cè)試的標(biāo)準(zhǔn)


  一般有基于測(cè)試用例基于缺陷密度兩種評(píng)比準(zhǔn)則,在這里我們采用前者。
準(zhǔn)則如下:

  1. 功能性測(cè)試用例通過(guò)率達(dá)到100%;
  2. 非功能性測(cè)試用例通過(guò)率達(dá)到95%;

備選通過(guò)辦法:

  根據(jù)實(shí)際情況由項(xiàng)目經(jīng)理和測(cè)試負(fù)責(zé)人以及用戶等共同討論確定本階段是否結(jié)束。


 


 


實(shí)施建議


對(duì)于系統(tǒng)的一些實(shí)施建議:


o        對(duì)系統(tǒng)測(cè)試人員進(jìn)行必要的培訓(xùn),提高他們的測(cè)試效率。


項(xiàng)目經(jīng)理和測(cè)試小組根據(jù)項(xiàng)目的資源、時(shí)間等限制因素,設(shè)法合理地減少測(cè)試的工作量,例如減少冗余或無(wú)效的測(cè)試。


 


 


附錄一:缺陷分類(lèi)












































類(lèi) 別


描 述


需求缺陷


1) 需求有誤
2
) 需求邏輯錯(cuò)誤
3
) 需求不完備
4
) 需求文檔描述問(wèn)題
5
) 需求更改


設(shè)計(jì)缺陷


功能的使用對(duì)用戶帶來(lái)不便及不符合行業(yè)標(biāo)準(zhǔn)的:
1
) 設(shè)計(jì)不合理
2
) 設(shè)計(jì)文檔描述問(wèn)題
3
) 設(shè)計(jì)變更帶來(lái)的問(wèn)題


功能和性能缺陷


功能沒(méi)有達(dá)到需求的要求,或功能存在嚴(yán)重缺陷,系統(tǒng)在運(yùn)行過(guò)程中存在性能瓶頸,或?qū)ο到y(tǒng)性能有影響的功能:
1
) 功能或性能有誤
2
) 性能不完全
3
) 功能不完全
4
) 適應(yīng)范圍有問(wèn)題
5
) 用戶信息和診斷信息有誤
6
) 異常情況處理有誤
7
) 其他功能錯(cuò)誤


界面缺陷


系統(tǒng)上圖片、文字、按鈕等出現(xiàn)明顯錯(cuò)誤


數(shù)據(jù)錯(cuò)誤


訪問(wèn)數(shù)據(jù)庫(kù)時(shí)出錯(cuò),得出的數(shù)據(jù)錯(cuò)誤:
1
) 數(shù)據(jù)定義數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤
2
) 數(shù)據(jù)存取及數(shù)據(jù)操作錯(cuò)誤
3
) 其它數(shù)據(jù)問(wèn)題


結(jié)構(gòu)缺陷


1) 控制流和控制順序錯(cuò)
2
) 處理錯(cuò)


實(shí)現(xiàn)與編碼缺陷


1) 編碼錯(cuò)誤
2
) 違背編碼風(fēng)格或標(biāo)準(zhǔn)
3
) 文檔有誤
4
) 其它實(shí)現(xiàn)的問(wèn)題


系統(tǒng)結(jié)構(gòu)缺陷


1) 操作系統(tǒng)引用或使用錯(cuò)誤
2
) 軟件結(jié)構(gòu)錯(cuò)誤
3
) 恢復(fù)錯(cuò)誤
4
) 執(zhí)行錯(cuò)誤
5
) 診斷錯(cuò)誤
6
) 分割覆蓋錯(cuò)誤
7
) 引用環(huán)境錯(cuò)誤


測(cè)試設(shè)計(jì)與測(cè)試執(zhí)行錯(cuò)誤


1) 測(cè)試設(shè)計(jì)錯(cuò)誤
2
) 測(cè)試執(zhí)行錯(cuò)誤
3
) 測(cè)試文檔有誤
4
) 測(cè)試用例不充分
5
) 其他測(cè)試錯(cuò)誤


計(jì)算錯(cuò)誤


數(shù)學(xué)結(jié)算錯(cuò)誤


不同硬件設(shè)備所產(chǎn)生的錯(cuò)誤


所產(chǎn)生的問(wèn)題與硬件設(shè)備直接有關(guān)


其他錯(cuò)誤


測(cè)試者檢查出來(lái)的且不包括在以上所有類(lèi)型中的錯(cuò)誤


 

 


附錄三:優(yōu)先級(jí)


























類(lèi) 別


描 述


1-立即修改完成(最高)


影響測(cè)試進(jìn)度的BUG, 重大的功能缺陷BUG,需要及時(shí)處理的


2-下一個(gè)階段結(jié)束前必須修改完成


功能沒(méi)有達(dá)到需求的的BUG,設(shè)計(jì)上存在輕微缺陷的


3-產(chǎn)品推出前必須修改完成


系統(tǒng)上圖片、文字、按鈕、翻頁(yè)上有的BUG或建議


4-時(shí)間允許再進(jìn)行修改


有缺陷,但不影響系統(tǒng)功能,只是系統(tǒng)使用起來(lái)不太方便


5-下個(gè)版本再修改(最低)


在此版本中不做修改,進(jìn)入下一版本時(shí)再做修改


6-無(wú)法修改,不做處理


因?yàn)樗蟮膬?nèi)容不合理,所以不做處理


 

 

 


附錄四:測(cè)試計(jì)劃審批意見(jiàn)








項(xiàng)目經(jīng)理審批意見(jiàn):


 


 


 


 


 


                    項(xiàng)目經(jīng)理簽字:
                        日期:


該文章在 2010/12/14 14:49:26 編輯過(guò)
關(guān)鍵字查詢
相關(guān)文章
正在查詢...
點(diǎn)晴ERP是一款針對(duì)中小制造業(yè)的專(zhuān)業(yè)生產(chǎn)管理軟件系統(tǒng),系統(tǒng)成熟度和易用性得到了國(guó)內(nèi)大量中小企業(yè)的青睞。
點(diǎn)晴PMS碼頭管理系統(tǒng)主要針對(duì)港口碼頭集裝箱與散貨日常運(yùn)作、調(diào)度、堆場(chǎng)、車(chē)隊(duì)、財(cái)務(wù)費(fèi)用、相關(guān)報(bào)表等業(yè)務(wù)管理,結(jié)合碼頭的業(yè)務(wù)特點(diǎn),圍繞調(diào)度、堆場(chǎng)作業(yè)而開(kāi)發(fā)的。集技術(shù)的先進(jìn)性、管理的有效性于一體,是物流碼頭及其他港口類(lèi)企業(yè)的高效ERP管理信息系統(tǒng)。
點(diǎn)晴WMS倉(cāng)儲(chǔ)管理系統(tǒng)提供了貨物產(chǎn)品管理,銷(xiāo)售管理,采購(gòu)管理,倉(cāng)儲(chǔ)管理,倉(cāng)庫(kù)管理,保質(zhì)期管理,貨位管理,庫(kù)位管理,生產(chǎn)管理,WMS管理系統(tǒng),標(biāo)簽打印,條形碼,二維碼管理,批號(hào)管理軟件。
點(diǎn)晴免費(fèi)OA是一款軟件和通用服務(wù)都免費(fèi),不限功能、不限時(shí)間、不限用戶的免費(fèi)OA協(xié)同辦公管理系統(tǒng)。
Copyright 2010-2025 ClickSun All Rights Reserved