軟件測試的內(nèi)容整理

軟件測試】軟件測試的內(nèi)容什么是軟件測試為了保證軟件的質(zhì)量和可靠性，應(yīng)力求在分析、設(shè)計等各個開發(fā)階段結(jié)束前，對軟件進(jìn)行嚴(yán)格技術(shù)評審。但由于人們能力的局限性，審查不能發(fā)現(xiàn)所有的錯誤。而且在編碼階段還會引進(jìn)大量的錯誤。這些錯誤和缺陷如果遺留到軟件交付投入運行之時，終將會暴露出來。但到那時，不僅改正這些錯誤的代價更高，而且往往造成很惡劣的后果。軟件測試就是在軟件投入運行前，對軟件需求分析、設(shè)計規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。如果給軟件測試下定義，可以這樣講：軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程?；蛘哒f，軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計的一批測試用例（即輸入一些數(shù)據(jù)而得到其預(yù)期的結(jié)果），并利用這些測試用例去運行程序，以發(fā)現(xiàn)程序錯誤的過程。軟件測試在軟件生存期中橫跨兩個階段：通常在編寫出每一個模塊之后就對它做必要的測試（稱為單元測試）。編碼與單元測試屬于軟件生存期中的同一個階段。在結(jié)束這個階段之后，對軟件系統(tǒng)還要進(jìn)行各種終合測試，這是軟件生存期的另一個階段，即測試階段，通常由專門的測試人員承擔(dān)這項工作。大量統(tǒng)計資料表明，軟件測試的工作量往往占軟件開發(fā)總工作量的40％以上，在極端情況，測試那種關(guān)系人的生命安全的軟件所花費的成本，可能相當(dāng)于軟件工程其他開發(fā)步驟總成本的三倍到五倍。因此，必須高度重視軟件測試工作，絕不要以為寫出程序之后軟件開發(fā)工作就接近完成了，實際上，大約還有同樣多的開發(fā)工作量需要完成。僅就測試而言，它的目標(biāo)是發(fā)現(xiàn)軟件中的錯誤，但是，發(fā)現(xiàn)錯誤并不是我們的最終目的。軟件工程的根本目標(biāo)是開發(fā)出高質(zhì)量的完全符合用戶需要的軟件。返回導(dǎo)航軟件測試的目的基于不同的立場，存在著兩種完全不同的測試目的。從用戶的角度出發(fā)，普遍希望通過軟件測試暴露出軟件中陷藏的錯誤和缺陷，以考慮是否可以接受該產(chǎn)品。而從軟件開發(fā)者的角度出發(fā)，則希望測試成為表明軟件產(chǎn)品中不存在錯誤的過程，驗證該軟件已正確地實現(xiàn)了用戶的要求，確立用戶對軟件質(zhì)量的信心。因為在程序中往往存在著許多預(yù)料不到的問題，可能會被疏漏，許多隱藏的錯誤只有在特定的環(huán)境下才可能暴露出來。如果不把著眼點放在盡可能查找錯誤這樣一個基礎(chǔ)上，這些隱藏的錯誤和缺陷就查不出來，會遺留到運行階段中去。如果站在用戶的角度替他們設(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)的錯誤的測試。從上述規(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)格的測試之后，仍然可能還有沒被發(fā)現(xiàn)的錯誤潛藏在程序中。測試只能查找出程序中的錯誤，不能證明程序中沒有錯誤。術(shù)語、名詞定義黑盒測試黑盒測試也稱為功能測試,它著眼于程序的外部特征,而不考慮程序的內(nèi)部邏輯結(jié)構(gòu)。測試者把被測程序看成一個黑盒,不用關(guān)心程序的內(nèi)部結(jié)構(gòu)。黑盒測試是在程序接口處進(jìn)行測試，它只檢查程序功能是否能正常使用，程序是否能接收輸入數(shù)據(jù)產(chǎn)生正確的輸出信息，并且保持外部信息（如數(shù)據(jù)庫或文件）的完整性。黑盒測試是基于用戶角度進(jìn)行的測試。白盒測試軟件測試的主要方法之一，也稱結(jié)構(gòu)測試、邏輯驅(qū)動測試或基于程序本身的測試。測試者需要了解待測試程序代碼的內(nèi)部結(jié)構(gòu)、算法等信息，這是從程序設(shè)計者的角度對程序進(jìn)行的測試。它的優(yōu)點是幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質(zhì)量，發(fā)現(xiàn)代碼中隱藏的問題?；液袦y試可以理解為靜態(tài)的白盒測試或動態(tài)的黑盒測試，灰盒就是界于黑白之間,對軟件內(nèi)部有所了解,但不見得到了如指掌的程度,卻可以結(jié)合這些了解做些比黑盒多點的測試。文檔測試文檔測試涵蓋面很大，在軟件的各個版本中均有所使用。隨著軟件版本的變化，文檔測試的測試內(nèi)容也有所變化。在需求分析以及原型架構(gòu)階段，文檔測試主要目標(biāo)是：Sitemap、動作分解列表、數(shù)據(jù)庫ER圖、UML用例圖、流程圖、需求文檔等文檔。文檔測試主要檢查文檔的正確性、完整性和可理解性。正確性是指不要把軟件的功能和操作寫錯，也不允許文檔內(nèi)容前后矛盾。完整性是指文檔不可以漏掉關(guān)鍵性內(nèi)容?？衫斫庑允侵冈谖臋n中描述的語言要簡明易懂，不能讓別的開發(fā)人員拿到文檔時看不懂文檔的內(nèi)容。命名規(guī)范測試命名規(guī)范測試用于測試項目中的文件命名、代碼以及版本號等書寫是否符合規(guī)范。文件命名規(guī)范以及版本號命名規(guī)范需求完整性測試需求完整性測試主要存在于需求探索階段，在需求尚未完全明確之前對已收集到的需求做出整理性的、檢查遺漏性的測試，確認(rèn)需求是否明確。另外，需求完整性測試也承擔(dān)著一部分澄清需求的任務(wù)。鏈接完整性測試在原型架構(gòu)階段，鏈接完整性的測試是非常有必要的。該項測試任務(wù)主要是檢查假頁面中各種鏈接是否完整，是否指向目標(biāo)位置，屬于檢查性的測試。頁面完整性測試頁面完整性測試主要存在于集成測試階段以及其后續(xù)其它階段中，測試頁面是否完整，頁面質(zhì)量是否達(dá)標(biāo)，屬于檢查性測試。UI合理性測試UI合理性測試也就是人機(jī)交互界面的合理性，UI合理性測試的內(nèi)容很多，具體測試內(nèi)容如下：＞提示、菜單、幫助的格式是否一致；＞提示、菜單、幫助中的術(shù)語是否一致；＞各個控件之間的對齊方式是否一致；＞輸入界面和輸出界面在外觀、布局、交互方式上是否一致；＞功能類似的相關(guān)界面在外觀、布局、交互方式上是否一致；＞同一層次的文字在同一種提示場合（一般情況、特殊字體、警告等）在文字大小、字體、顏色、對齊方式方面是否一致，字體大小是否與界面的大小比例協(xié)調(diào)；＞多個連續(xù)界面依次出現(xiàn)的情況下，界面的外觀、操作方式是否一致；＞系統(tǒng)是否拒絕客戶的錯誤輸入并做出提示；＞系統(tǒng)是否在用戶完成操作時給出操作成功的提示；＞用戶界面是否存在空白空間，沒有空白空間的界面是雜亂無章的，易用性差;＞各個控件的間隔是否一致，垂直和水平方向上是否對齊；＞是否允許動作的可逆性，返回原有操做；數(shù)據(jù)和數(shù)據(jù)庫完整性測試因為在開發(fā)階段開發(fā)人員隨時都有可能根據(jù)需要來修改數(shù)據(jù)庫，所以對數(shù)據(jù)和數(shù)據(jù)庫完整性測試在軟件項目的任何階段也是非常必要的。該項測試內(nèi)容主要是以數(shù)據(jù)庫表為單位，檢查數(shù)據(jù)庫表以及表中各字段命名是否符合命名規(guī)范，表中字段是否完整，數(shù)據(jù)庫表中的字段描述是否正確包括字段的類型、長度、是否為空，數(shù)據(jù)庫表中的關(guān)系、索引、主鍵、約束是否正確。功能測試功能測試在軟件項目的任何階段中都是重要的。實現(xiàn)功能，滿足客戶需求是軟件本身最大的使命。功能測試在任何階段下基本上都作為測試工作的第一項出現(xiàn)。該項測試任務(wù)主要為了測試已實現(xiàn)的功能是否滿足需求，是否正確，是否有價值以及是否完整。在黑盒和白盒測試狀態(tài)下，該測試均會被使用。功能測試中測試人員往往會忽略掉一些細(xì)節(jié)問題，比如：一個功能的實現(xiàn)必須要經(jīng)過6步操作才能完成，而且需要加入20條信息才能看得出測試結(jié)果，有的測試人員為了節(jié)省時間雖然做完了6步操作，但是沒有加入足量的信息，,使得測試不全面,正是因為這樣而導(dǎo)致一些隱藏的BUG沒有被測試出來。所以說在功能測試中要按部就班的把所有要進(jìn)行的測試功能每一步都執(zhí)行一遍，應(yīng)該添加的數(shù)據(jù)都添加完整，以避免遺漏掉BUG沒有測試出來。壓力測試壓力測試是為了發(fā)現(xiàn)在什么條件下您的應(yīng)用程序的性能會變得不可接受。這通過改變應(yīng)用程序的輸入以對應(yīng)用程序施加越來越大的負(fù)載并測量在這些不同的輸入時性能的改變來實現(xiàn)的。這種操作也稱為負(fù)載測試，但是負(fù)載測試通常描述一種特定類型的壓力測試——增加用戶數(shù)量以對應(yīng)用程序進(jìn)行壓力測試。對應(yīng)用程序進(jìn)行壓力測試最簡單的方法是手工改變輸入（客戶機(jī)數(shù)量、需求大小、請求的頻率、請求的混合程度等等）并描繪性能的變化。但是如果有許多輸入，或者需要在大的范圍內(nèi)改變輸入，那么你可以借助一個自動化的壓力測試工具來完成此測試。安全性測試安全性測試主要是測試系統(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)容如下：頁面腳本測試頁面中時常使用到JavaScript腳本，為了降低頁面的出錯率，則必須對頁面腳本進(jìn)行測試。其主要內(nèi)容包括:相關(guān)頁面中的腳本是否正常運行JavaScript腳本是否有錯誤頁面。提示文本測試提示文本測試從嚴(yán)格意義上來講應(yīng)該屬于UI合理性測試的一部分，該項測試主要針對各個頁面中使用到的大量提示文檔進(jìn)行測試，主要包括：表達(dá)不明確的位置是否有提示文本、提示文本的彈出是否正常、提示信息含義是否明確易懂。瀏覽器測試由于B/S結(jié)構(gòu)項目是基于瀏覽器運行的，所以需要對瀏覽器進(jìn)行必要的測試。該測試任務(wù)主要是軟件對各種瀏覽器（IE5.5、IE6.0、FireFox瀏覽器）的支持是否正常，在IE瀏覽器中可以正常顯示的頁面在其它瀏覽器中是否可以正常顯示。安裝測試在軟件項目的后期階段，會對做好的軟件進(jìn)行打包把軟件做成安裝程序，以便用戶可以正確的安裝使用，所以需要對做好的安裝文件進(jìn)行安裝功能方面的測試。該測試的主要任務(wù)是：檢查軟件是否能夠正常安裝使用、是否可以完全卸載此軟件的所有功能和頁面。自定義測試在常規(guī)測試時可能表中的測試項不能滿足測試要求，如果有特殊測試項請測試人員自己定義修改測試的類型。軟件命名規(guī)范軟件版本階段說明oBase版：此版本表示該軟件僅僅是一個假頁面鏈接，通常包括所有的功能和頁面布局，但是頁面中的功能都沒有做完整的實現(xiàn)，只是做為整體網(wǎng)站的一個基礎(chǔ)架構(gòu)。oAlpha版:此版本表示該軟件在此階段主要是以實現(xiàn)軟件功能為主，通常只在軟件開發(fā)者內(nèi)部交流，一般而言，該版本軟件的Bug較多，需要繼續(xù)修改。oBeta版：該版本相對于a版已有了很大的改進(jìn)，消除了嚴(yán)重的錯誤，但還是存在著一些缺陷，需要經(jīng)過多次測試來進(jìn)一步消除，此版本主要的修改對像是軟件的UI。oRC版：該版本已經(jīng)相當(dāng)成熟了，基本上不存在導(dǎo)致錯誤的BUG,與即將發(fā)行的正式版相差無幾。oRelease版：該版本意味“最終版本”，在前面版本的一系列測試版之后，終歸會有一個正式版本，是最終交付用戶使用的一個版本。該版本有時也稱為標(biāo)準(zhǔn)版。一般情況下，Release不會以單詞形式出現(xiàn)在軟件封面上，取而代之的是符號(R)。測試任務(wù)描述在軟件的開發(fā)過程中每個版本都會經(jīng)歷四次測試任務(wù)，分別為：單元測試、集成測試、系統(tǒng)測試、驗收測試，在這四次測試任務(wù)中，每次測試都有不同的測試方向和重點。4.2.1.單元測試單元測試是軟件開發(fā)過程中要進(jìn)行的最基本的測試，屬于白盒測試范圍，一般情況下是在開發(fā)人員完成了某個單獨模塊的編碼之后做的測試。它的目的是檢查軟件編碼的正確性以及一些規(guī)范性測試，站在開發(fā)人員的角度上來查找軟件所存在的BUG并記錄下產(chǎn)生BUG的原因，以便開發(fā)人員進(jìn)行修改。這樣可以在很大程度上減少集成以后而出現(xiàn)的BUG。一旦編碼完成，開發(fā)人員總是會迫切希望進(jìn)行軟件的集成工作，這樣他們就能夠看到實際的系統(tǒng)開始啟動工作了。這在外表上看來是一項明顯的進(jìn)步，而象單元測試會推遲對整個系統(tǒng)進(jìn)行合并這種真正有意思的工作啟動的時間。這種開發(fā)步驟中，真實意義上的進(jìn)步被軟件合并后的外表上的進(jìn)步取代了。系統(tǒng)能夠正常工作的可能性是很小的，更多的情況是充滿了各式各樣的Bug?，F(xiàn)實的開發(fā)中，沒有單元測試的軟件常常會導(dǎo)致這樣的結(jié)果，軟件甚至無法運行。更進(jìn)一步的結(jié)果是大量的時間將被花費在本應(yīng)該在單元測試?yán)锞屯瓿傻暮唵蜝ug上面，在個別情況下，這些Bug也許是瑣碎和微不足道的，但是總的來說，他們會延長軟件集成為一個系統(tǒng)的時間，而且當(dāng)這個系統(tǒng)投入使用時也無法確保它能夠可靠運行。單元測試不僅僅是作為無錯編碼一種輔助手段在一次性的開發(fā)過程中使用，單元測試應(yīng)該是可重復(fù)的，無論是在軟件修改，或是移植到新的運行環(huán)境的過程中。因此，所有的測試都必須在整個軟件系統(tǒng)的生命周期中進(jìn)行，也就是說每個版本的開發(fā)都需要經(jīng)過單元測試，這樣可以在以后的開發(fā)階段減少很多不必要的麻煩。單元測試的重點測試內(nèi)容包括：源代碼測試、命名規(guī)范測試、需求完整性測試、頁面完整性測試、提示文本測試、頁面腳本測試等。集成測試集成測試也屬于白盒測試范圍，是在單元測試的基礎(chǔ)上將軟件的多個模塊或者系統(tǒng)前后臺合并之后進(jìn)行的測試，也可以算是對單元測試修改進(jìn)行的復(fù)審測試。在集成測試中可以彌補(bǔ)單元測試中沒有測試到的BUG,也可以檢查出單元測試沒法測試的功能，比如前后臺的集成之后的關(guān)聯(lián)功能，對于這些有關(guān)聯(lián)性功能的測試，單元測試中是無能為力的，必須依靠集成測試來保證功能的完整性和正確性。和系統(tǒng)測試相比較集成測試從程序結(jié)構(gòu)出發(fā)，目的性、針對性更強(qiáng)，發(fā)現(xiàn)問題的效率高，較容易測試特殊的處理流程中存在的BUG。集成測試的重點測試內(nèi)容包括：鏈接完整性測試、頁面完整性測試、數(shù)據(jù)和數(shù)據(jù)庫完整性測試、功能測試、壓力測試、安全性測試、頁面腳本測試、提示文本測試等。系統(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)品的全面測試，既包含各模塊的驗證性測試和功能合理性測試，又包括對整個產(chǎn)品的可靠性、健壯性、安全性、UI合理性及各種性能參數(shù)的測試。系統(tǒng)測試的重點測試內(nèi)容包括：鏈接完整性測試、UI合理性測試、命名規(guī)范測試、功能測試、壓力測試、頁面完整性測試、安裝測試、提示文本測試、游覽器測試等。4.2.4驗收測試驗收測試屬于黑盒測試范圍，是對系統(tǒng)測試修改后的復(fù)審，這方面和集成測試有些類似，首先確認(rèn)系統(tǒng)測試中的BUG已經(jīng)按要求修改完成，然后檢測一下功能是否符合用戶的需求、文檔是否完整、有沒有前面測試中遺漏沒有測試出來的BUG。要說明的一點是，此處的驗收測試并非客戶驗收測試，這里沒有客戶參與測試，只有測試人員參與測試。驗收測試是開發(fā)結(jié)束或進(jìn)入下一版本的標(biāo)志性測試。驗收測試的重點測試內(nèi)容包括：鏈接完整性測試、UI合理性測試、功能測試、壓力測試、頁面完整性測試、提示文本測試、瀏覽器測試、安裝測試。測試提交文檔測試文檔使用方法在測試的過程中測試人員會用到三張表，第一張表是“測試任務(wù)表”，這張表中記錄的是軟件在每個版本的每個階段中需要做的具體測試任務(wù)，如果測試中不確定需要做哪些測試，在這張表中可以查詢各個階段中所要進(jìn)行的測試項。還有兩張表是需要在相應(yīng)測試階段來添寫的測試文檔，分別是“白盒缺陷測試報告”和“黑盒測試缺陷報告”兩張表。單元測試和集成測試屬于白盒測試范圍，需要添寫白盒缺陷測試報告；系統(tǒng)測試和驗收測試屬于黑盒測試范圍，需要添寫黑盒測試缺陷報告。測試人員測試完成之后，需要把所添寫的缺陷測試報告按時提交給項目經(jīng)理,由項目經(jīng)理來安排具體人員進(jìn)行修改和審核。注：在每次的測試中測試人員需要按表中的要求進(jìn)行添寫測試報告，然后由項目經(jīng)理來分配給開發(fā)人員處理，開發(fā)人員修改完BUG之后再交由項目經(jīng)理來分配給測試人進(jìn)行修改后的復(fù)審，檢查前面測試出來的BUG是否已經(jīng)修改完成，在此要特別說明的一點是：為了讓測試報告更方便查看，如果在復(fù)審過程中查出還有BUG沒有修改完或是根本沒有修改，則在復(fù)審描述中說明原因，然后把此處標(biāo)注成新的BUG索引項指到新的BUG編號上，詳細(xì)情況請看下面截圖：4.4測試方法和方式測試方式主要以手工測試為主，在條件允許的情況下使用自動化測試工具進(jìn)行測試。測試方法測試覆蓋率執(zhí)行人員描述黑盒測試100%測試人員功能測試或數(shù)據(jù)驅(qū)動測試灰盒測試10~20%測試或開發(fā)人員 靜態(tài)的白盒測試或動態(tài)的黑盒測試白盒測試5%開發(fā)人員結(jié)構(gòu)測試或邏輯驅(qū)動測試說明：黑盒測試是依據(jù)用戶能看到的規(guī)格說明，即針對命令、信息、報表等用戶界面及體現(xiàn)他們的輸入數(shù)據(jù)與輸出數(shù)據(jù)之間的對應(yīng)關(guān)系，特別是針對功能進(jìn)行測試。主要由客戶或系統(tǒng)使用者完成執(zhí)行黑盒測試。4.5黑盒測試覆蓋范圍測試用例覆蓋：測試的每一個用例都被測試過。輸入覆蓋：測試過程中所輸入的數(shù)據(jù)或資料必須一再的試驗，如在程序安裝過程中輸入用戶名時，測試者必須反復(fù)輸入不同長度的中文、英文或數(shù)字等來做測試。輸出覆蓋：測試過程中程序所產(chǎn)生的行為、反映及數(shù)據(jù)必須都一再的試驗，如不同情況的對話窗口的內(nèi)容、運算結(jié)果數(shù)據(jù)等都必須反復(fù)地測試審核。4.6通過測試的標(biāo)準(zhǔn)＞一般有“基于測試用例”和“基于缺陷密度”兩種評比準(zhǔn)則，在這里我們采用前者。＞準(zhǔn)則如下：＞ 1.功能性測試用例通過率達(dá)到100%；＞2.非功能性測試用例通過率達(dá)到95%；＞備選通過辦法：＞根據(jù)實際情況由項目經(jīng)理和測試負(fù)責(zé)人以及用戶等共同討論確定本階段是否結(jié)束。4.7對于系統(tǒng)的一些實施建議＞對系統(tǒng)測試人員進(jìn)行必要的培訓(xùn)，提高他們的測試效率。＞項目經(jīng)理和測試小組根據(jù)項目的資源、時間等限制因素，設(shè)法合理地減少測試的工作量，例如減少“冗余或無效”的測試。附錄一：缺陷分類類別描述需求缺陷1） 需求有誤2） 需求邏輯錯誤3） 需求不完備4） 需求文檔描述問題5） 需求更改設(shè)計缺陷功能的使用對用戶帶來不便及不符合行業(yè)標(biāo)準(zhǔn)的：1） 設(shè)計不合理2） 設(shè)計文檔描述問題3） 設(shè)計變更帶來的問題功能和性能缺陷功能沒有達(dá)到需求的要求，或功能存在嚴(yán)重缺陷，系統(tǒng)在運行過程中存在性能瓶頸，或?qū)ο到y(tǒng)性能有影響的功能：1） 功能或性能有誤2） 性能不完全3） 功能不完全4） 適應(yīng)范圍有問題5） 用戶信息和診斷信息有誤6） 異常情況處理有誤7） 其他功能錯誤界面缺陷系統(tǒng)上