軟件工程-2及軟件測試工程師績效評估表

程序編碼習(xí)題【4-1】從下列關(guān)于模塊化程序設(shè)計的敘述中選出5條正確的敘述。①程序設(shè)計比較方便，但比較難以維護。②便于由多個人分工編制大型程序。③軟件的功能便于擴充。④程序易于理解，也便于排錯。⑤在主存儲器能夠容納得下的前提下，應(yīng)使模塊盡可能大，以便減少模塊的個數(shù)。⑥模塊之間的接口叫做數(shù)據(jù)文件。⑦只要模塊之間的接口關(guān)系不變，各模塊內(nèi)部實現(xiàn)細節(jié)的修改將不會影響別的模塊。⑧模塊間的單向調(diào)用關(guān)系叫做模塊的層次結(jié)構(gòu)。⑨模塊越小，模塊化的優(yōu)點越明顯。一般來說，模塊的大小都在10行以下?！?-2】結(jié)構(gòu)化程序設(shè)計有時被錯誤地稱為“無GOTO語句”的程序設(shè)計。請說明為什么會出現(xiàn)這樣的說法，并討論環(huán)繞著這個問題的一些爭論?！?-3】從下面關(guān)于程序編制的敘述中，選出三條正確的敘述。①在編制程序之前，首先必須仔細閱讀給定的程序說明書。然后，必須如實地依照說明書編寫程序。說明書中常會有含糊不清或難以理解的地方。程序員在作業(yè)時應(yīng)該對這些地方作出適當?shù)慕忉尅＂谠谥志幹瞥绦驎r，重要的是采用既能使程序正確地按設(shè)計說明書進行處理，又易于出錯的編寫方法。③在編制程序時，首先應(yīng)該對程序的結(jié)構(gòu)充分考慮，不要急于開始編碼，而要象寫軟件文檔那樣，很好地琢磨程序具有什么樣的功能，這些功能如何安排等等。④考慮到以后的程序變更，為程序編寫完整的說明書是一項很重要的工作。只要有了完整的程序說明書，即使程序的編寫形式難以讓他人看懂也沒有什么關(guān)系。⑤編制程序時不可缺少的條件是，程序的輸入和輸出數(shù)據(jù)的格式都應(yīng)確定。其他各項規(guī)定都是附帶的，無足輕重。⑥作為一個好的程序，不僅處理速度要快，而且易讀易修改等等也都是重要的條件。為了能得到這樣的程序，不僅要熟悉程序設(shè)計語言的語法，還要注意采用適當?shù)囊?guī)程和單純的表現(xiàn)方法，注意使整個程序的結(jié)構(gòu)簡潔。【4-7】下面給出一個求實函數(shù)方程F(x)在自變量區(qū)間[a,b]中的全部實根的算法。首先閱讀此程序，然后 畫出消去全部goto語句的結(jié)構(gòu)化程序流程圖。 在算法中，a與b是區(qū)間[a,b]的兩端點值；eps1與eps2是用戶要求的求解精度。如果區(qū)間中點的函數(shù)值的絕對值小于eps1或新的小區(qū)間的長度小于eps2，就認為這個中點為根。 floatBinRoot(floata,floatb,floateps1,floateps2){ floatlow=a,high=b,mid,fmid;floatflow=Func(low),fhigh:=Func(high); labelL1,L2,L3;//標號說明，給定某些程序地址 if(flow*fhigh>0.0){BinRoot=0;gotoL3;}//無實根L1: mid=(low+high)/2;fmid=Func(mid); if(abs(fmid)<=eps1){L2: BinRoot=mid;gotoL3; } elseif(high-mid<=eps2)gotoL2; elseif(flow*fmid>0.0){low=mid;flow=fmid;gotoL1;} else{high=mid;gotoL1};L3:}習(xí)題解答【4-1】正確的敘述有②、③、④、⑦、⑧。如果程序結(jié)構(gòu)的模塊化滿足評價的標準（高內(nèi)聚，低耦合），這樣的結(jié)構(gòu)是容易編碼，容易測試，容易理解，容易修改，容易維護的。程序的功能也容易擴充。特別適合于大型程序編制時，多人分工合作，協(xié)同完成任務(wù)的情形。因為是采用自頂向下，逐層分解來劃分模塊結(jié)構(gòu)的，所以模塊之間的調(diào)用關(guān)系是分層次的模塊結(jié)構(gòu)，就叫做模塊的層次結(jié)構(gòu)。模塊之間的信息傳遞叫做模塊的接口，模塊之間傳遞信息可以通過參數(shù)表、全局變量或全局數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)文件、專門的通信模塊，不是專指數(shù)據(jù)文件。劃分模塊時，模塊大小要適中。模塊太大，控制路徑數(shù)目多、涉及的范圍廣、變量的數(shù)目多、總體復(fù)雜性高，可理解性、可修改性、可靠性就會變差。模塊太小，模塊個數(shù)增大，調(diào)用的系統(tǒng)開銷就會增大。所以要有一個權(quán)衡。【紛亂如麻的程序流程4-2】早在1963年，針對當時流行的ALGOL語言，PeterNaur指出，在程序中大量地，沒有節(jié)制地使用GOTO語句，會使程序結(jié)構(gòu)變得非?；靵y。但是很多人還不太注意這一問題。以致許多人寫出來的程序仍然是紛亂如麻的。紛亂如麻的程序流程1965年，E.W.Dijkstra在一次會議上提出，應(yīng)當把GOTO語句從高級語言中取消。并指出，程序的質(zhì)量與程序中包含的GOTO語句的數(shù)量成反比。在這種思想的影響下，當時新開發(fā)的幾種高級程序設(shè)計語言，例如LISP、ISWIM、BLISS等，都把GOTO語句取消了。1966年，Bohm與Jacopini證明了任何單入口單出口的沒有“死循環(huán)”的程序都能由三種最基本的控制結(jié)構(gòu)構(gòu)造出來。這三種基本控制結(jié)構(gòu)就是“順序結(jié)構(gòu)”、“選擇IF－THEN－ELSE結(jié)構(gòu)”、“重復(fù)DO－WHILE或DO－UNTIL結(jié)構(gòu)”。1968年，Dijkstra在寫給<ACM>（美國計算機協(xié)會通訊）雜志編輯部的信中再次建議從一切高級語言中取消GOTO語句，只使用三種基本控制結(jié)構(gòu)編寫程序。他的建議引起了激烈的爭論。爭論集中在如何看待GOTO語句的問題上。贊成取消GOTO語句的一方認為，GOTO語句對程序清晰性有很大破壞作用，凡是使用GOTO語句多的程序，其控制流時而GOTO向前，時而GOTO向后，常使程序變得很難理解，從而增加查錯和維護的困難，降低程序的可維護性。但以D.E.Knuth為代表的另一方認為，GOTO語句雖然存在著破壞程序清晰性的問題，但不應(yīng)完全禁止。因為GOTO語句概念簡單，使用方便，在某些情況下，保留GOTO語句反能使寫出的程序更加簡潔，并且GOTO語句可直接得到硬件指令的支持。經(jīng)過爭論，人們認識到，不是簡單地去掉GOTO語句的問題，而是要創(chuàng)立一種新的程序設(shè)計思想、方法和風(fēng)格，以顯著提高軟件生產(chǎn)率和軟件質(zhì)量，降低軟件維護的成本。70年代初N.Wirth在設(shè)計Pascal語言時對GOTO語句的處理可被當做對GOTO語句爭論的結(jié)論。在Pascal語言中設(shè)置了支持上述三種基本控制結(jié)構(gòu)的語句；另一方面，GOTO語句仍然保留在該語言中。不過，N.Wirth解釋說，通常使用所提供的幾種基本控制結(jié)構(gòu)已經(jīng)足夠，習(xí)慣于這樣做的人不會感到GOTO語句的必要。也就是說，在一般情況下，可以完全不使用GOTO語句。如果在特殊情況下，由于特定的要求，偶然使用GOTO語句能解決問題，那也未嘗不可，只是不應(yīng)大量使用罷了。事實上，大量采用GOTO語句實現(xiàn)控制路徑，會使程序路徑變得復(fù)雜而且混亂，從而使程序變得不易閱讀，給程序的測試和維護造成困難，還會增加出錯的機會，降低程序的可靠性。因此要控制GOTO語句的使用。但有時完全不用GOTO語句進行程序編碼，比用GOTO語句編出的程序可讀性差。例如，在查找結(jié)束時，文件訪問結(jié)束時，出現(xiàn)錯誤情況要從循環(huán)中轉(zhuǎn)出時，使用布爾變量和條件結(jié)構(gòu)來實現(xiàn)就不如用GOTO語句來得簡潔易懂。【4-3】①、④、⑥。編制程序的過程實際上是根據(jù)設(shè)計的結(jié)果，用某種機器能夠識別的程序設(shè)計語言，將設(shè)計翻譯成機器代碼的過程。因此，必須如實地按照設(shè)計說明書編寫程序。至于設(shè)計說明書中含糊不清的地方，應(yīng)當在編程時與分析人員或設(shè)計人員協(xié)商，對這些地方做出適當?shù)慕忉?。另外，考慮到將來的程序修改，必須為程序編寫完整的說明書，同時程序必須編寫得容易讓別人看得懂，這樣程序才容易修改，修改時不容易出錯，而且容易驗證修改后得結(jié)果。還有，編寫程序的人不須重新考慮程序要完成什么功能，這些已經(jīng)在軟件分析與設(shè)計過程中充分考慮過了?！?-7】結(jié)構(gòu)化的程序流程圖：low=alow=a;high=b;flow=Func(low);fhigh=Func(high);mid=(low+highmid=(low+high)/2;fmid=Func(mid);end=1;flow*fhigh>0.0?Tretval=0;T|fmid|epsT|fmid|eps1?Fend==1?返回retval;結(jié)束Fend==1?返回retval;結(jié)束Fhigh-mideps2high-mideps2?FTend=0;retval=end=0;retval=mid;TTFflow*fmid>0.0?FTFflow*fmid>0.0?Fhigh=mid;low=mid;flow=high=mid;low=mid;flow=fmid;軟件測試復(fù)習(xí)要求1.了解軟件測試的目的和原則。2.了解軟件錯誤的分類。3.了解軟件測試的過程和策略。4.了解軟件測試用例設(shè)計的方法，掌握邏輯覆蓋、基本路徑測試、因果圖等測試用例設(shè)計方法。5.了解程序靜態(tài)測試的方法。習(xí)題【5-1】從供選擇的答案中選出應(yīng)填入下列()中的字句。軟件測試的目的是（A）。為了提高測試的效率，應(yīng)該（B）。使用白盒測試方法時，確定測試數(shù)據(jù)應(yīng)根據(jù)（C）和指定的覆蓋標準。與設(shè)計測試數(shù)據(jù)無關(guān)的文檔是（D）。軟件的集成測試工作最好由（E）承擔(dān)，以提高集成測試的效果。供選擇的答案：A. ①評價軟件的質(zhì)量 ②發(fā)現(xiàn)軟件的錯誤③找出軟件中的所有錯誤 ④證明軟件是正確的B. ①隨機地選取測試數(shù)據(jù) ②取一切可能的輸入數(shù)據(jù)作為測試數(shù)據(jù)③在完成編碼以后制定軟件的測試計劃④選擇發(fā)現(xiàn)錯誤的可能性大的數(shù)據(jù)作為測試數(shù)據(jù)C. ①程序的內(nèi)部邏輯 ②程序的復(fù)雜程度③使用說明書 ④程序的功能D. ①該軟件的設(shè)計人員 ②程序的復(fù)雜程度③源程序 ④項目開發(fā)計劃E. ①該軟件的設(shè)計人員 ②該軟件開發(fā)組的負責(zé)人③該軟件的編程人員 ④不屬于該軟件開發(fā)組的軟件設(shè)計人員【5-2】請從供選擇的答案中選出應(yīng)填入下列（）中的字句。程序的三種基本控制結(jié)構(gòu)是（A）。它們的共同點是（B）。結(jié)構(gòu)化程序設(shè)計的一種基本方法是（C）。軟件測試的目的是（D）。軟件調(diào)試的目的是（E）。供選擇的答案：A. ①過程，子程序，分程序 ②順序，條件，循環(huán)③遞歸，堆棧，隊列 ④調(diào)用，返回，轉(zhuǎn)移B. ①不能嵌套使用 ②只能用來寫簡單的程序③已經(jīng)用硬件實現(xiàn) ④只有一個入口和一個出口C. ①篩選法 ②遞歸法 ③歸納法 ④逐步求精法D. ①證明程序中沒有錯誤 ②發(fā)現(xiàn)程序中的錯誤③測量程序的動態(tài)特性 ④檢查程序中的語法錯誤E. ①找出錯誤所在并改正之 ②排除存在錯誤的可能性③對錯誤性質(zhì)進行分類 ④統(tǒng)計出錯的次數(shù)【5-3】從下列關(guān)于軟件測試的敘述中，選出5條正確的敘述。(1)用黑盒法測試時，測試用例是根據(jù)程序內(nèi)部邏輯設(shè)計的。(2)盡量用公共過程或子程序去代替重復(fù)的代碼段。(3)測試是為了驗證該軟件已正確地實現(xiàn)了用戶的要求。(4)對于連鎖型分支結(jié)構(gòu)，若有n個判定語句，則有2n條路徑。(5)盡量采用復(fù)合的條件測試，以避免嵌套的分支結(jié)構(gòu)。(6)GOTO語句概念簡單，使用方便，在某些情況下，保留GOTO語句反能使寫出的程序更加簡潔。(7)發(fā)現(xiàn)錯誤多的程序模塊，殘留在模塊中的錯誤也多。(8)黑盒測試方法中最有效的是因果圖法。(9)在做程序的單元測試時，樁（存根）模塊比驅(qū)動模塊容易編寫。(10)程序效率的提高主要應(yīng)通過選擇高效的算法來實現(xiàn)?！?-4】從供選擇的答案中選出同下列關(guān)于軟件測試的各條敘述關(guān)系最密切的字句。(1)對可靠性要求很高的軟件，例如操作系統(tǒng)，由第三者對源代碼進行逐行檢查。(2)已有的軟件被改版時，由于受到變更的影響，改版前正常的功能可能發(fā)生異常，性能也可能下降。因此，對變更的軟件進行測試是必要的。(3)在意識到被測試模塊的內(nèi)部結(jié)構(gòu)或算法的情況下進行測試。(4)為了確認用戶的需求，先做出系統(tǒng)的主要部分，提交給用戶試用。(5)在測試具有層次結(jié)構(gòu)的大型軟件時，有一種方法是從上層模塊開始，由上到下進行測試。此時，有必要用一些模塊替代尚未測試過的下層模塊。供選擇的答案：AE： ①仿真器 ②代碼審查③模擬器 ④樁 ⑤驅(qū)動器⑥域測試 ⑦黑盒測試 ⑧原型 ⑨白盒測試 ⑩退化測試【5-5】對小的程序進行窮舉測試是可能的，用窮舉測試能否保證程序是百分之百正確呢？【5-6】在任何情況下單元測試都是可能的嗎？都是需要的嗎？【5-7】從供選擇的答案中選出應(yīng)填入下面有關(guān)軟件測試的敘述的（）內(nèi)的正確答案。軟件測試方法可分為黑盒測試法和白盒測試法兩種。黑盒測試法是通過分析程序的（A）來設(shè)計測試用例的方法。除了測試程序外，它還適用于對（B）階段的軟件文檔進行測試。白盒測試法是根據(jù)程序的（C）來設(shè)計測試用例的方法。除了測試程序外，它也適用于對（D）階段的軟件文檔進行測試。白盒法測試程序時常按照給定的覆蓋條件選取測試用例。（E）覆蓋比（F）覆蓋嚴格，它使得每一個判定的每一條分支至少經(jīng)歷一次。（G）覆蓋既是判定覆蓋，又是條件覆蓋，但它并不保證使各種條件都能取到所有可能的值。（H）覆蓋比其他條件都要嚴格，但它不能保證覆蓋程序中的每一條路徑。單元測試一般以（I）為主，測試的依據(jù)是（J）。供選擇的答案：A,C：①應(yīng)用范圍 ②內(nèi)部邏輯 ③功能 ④輸入數(shù)據(jù)B,D：①編碼 ②軟件詳細設(shè)計 ③軟件總體設(shè)計④需求分析E,F,G,H：①語句 ②判定 ③條件 ④判定/條件⑤多重條件 ⑥路徑I：①白盒法 ②黑盒法J：①模塊功能規(guī)格說明 ②系統(tǒng)模塊結(jié)構(gòu)圖 ③系統(tǒng)需求規(guī)格說明【5-8】從供選擇的答案中選出應(yīng)該填入下列關(guān)于軟件測試的敘述的()內(nèi)的正確答案。軟件測試中常用的靜態(tài)分析方法是（A）和（B）。（B）用于檢查模塊或子程序間的調(diào)用是否正確。分析方法（白盒方法）中常用的方法是（C）方法。非分析方法（黑盒方法）中常用的方法是（D）方法和（E）方法。（E）方法根據(jù)輸出對輸入的依賴關(guān)系設(shè)計測試用例。供選擇的答案：AB： ①引用分析 ②算法分析 ③可靠性分析 ④效率分析 ⑤接口分析 ⑥操作分析C~E： ①路徑測試②等價類 ③因果圖 ④歸納測試⑤綜合測試⑥追蹤 ⑦深度優(yōu)先 ⑧調(diào)試⑨相對圖習(xí)題解答【5-1】A.②B.④C.①D.④E.④軟件測試的目的是軟件中的錯誤。因為不可能把所有可能的輸入數(shù)據(jù)都拿來測試（時間花費不起），為了提高測試的效率，應(yīng)該選擇發(fā)現(xiàn)錯誤的可能性大的數(shù)據(jù)作為測試數(shù)據(jù)。使用白盒測試方法時，確定測試數(shù)據(jù)應(yīng)根據(jù)程序的內(nèi)部邏輯和指定的覆蓋標準，可以不考慮程序的功能。與設(shè)計測試數(shù)據(jù)無關(guān)的文檔是項目開發(fā)計劃。軟件的集成測試工作最好由不屬于該軟件開發(fā)組的軟件設(shè)計人員承擔(dān)，以提高集成測試的效果?！?-2】A.②B.④C.④D.②E.① 1966年，Bohm與Jacopini提出任何單入口單出口的沒有“死循環(huán)”的程序都能由三種最基本的控制結(jié)構(gòu)構(gòu)造出來。這三種基本控制結(jié)構(gòu)就是“順序結(jié)構(gòu)”、“選擇IF－THEN－ELSE結(jié)構(gòu)”、“重復(fù)DO－WHILE或DO－UNTIL結(jié)構(gòu)”。它們的共同點是只有一個入口和一個出口。E.W.Dijkstra提出了程序要實現(xiàn)結(jié)構(gòu)化的主張，并將這一類程序設(shè)計稱為結(jié)構(gòu)化程序設(shè)計。這種方法的一個重要原則就是采用自頂向下、逐步求精的方法編寫程序。N.Wirth曾做過如下說明：“我們對付一個復(fù)雜問題的最重要的方法就是抽象。因此，對于一個復(fù)雜的問題，不要急于馬上用計算機指令、數(shù)字和邏輯符號來表示它，而應(yīng)當先用較自然的抽象的語句來表示，從而得到抽象的程序。抽象程序?qū)Τ橄蟮臄?shù)據(jù)類型進行某些特定的運算，并用一些合適的記號（可以是自然語言）來表示。下一步對抽象程序再做分解，進入下一個抽象的層次。這樣的細化過程一直進行下去，直到程序能被計算機接受為止。此時的程序已經(jīng)是用某種高級語言或機器指令書寫的了?！避浖{(diào)試則是在進行了成功的測試之后才開始的工作。它與軟件測試不同，軟件測試的目的是盡可能多地發(fā)現(xiàn)軟件中的錯誤，但進一步診斷和改正程序中潛在的錯誤，則是調(diào)試的任務(wù)。調(diào)試活動由兩部分組成：①確定程序中可疑錯誤的確切性質(zhì)和位置。②對程序（設(shè)計，編碼）進行修改，排除這個錯誤?！?-3】正確的敘述有(4)、(5)、(6)、(7)、（10）。黑盒測試主要是根據(jù)程序的有關(guān)功能規(guī)格說明和覆蓋準則來設(shè)計測試用例，進行測試的，不是根據(jù)程序的內(nèi)部邏輯來設(shè)計測試用例，這是白盒測試做的事情。在所有黑盒測試方法中，最有效的不是因果圖法，而是邊界值分析方法。測試的目的是盡可能多地發(fā)現(xiàn)軟件中的錯誤，其附帶的收獲才是驗證該軟件已正確地實現(xiàn)了用戶的要求。測試的一條重要原則是：發(fā)現(xiàn)錯誤多的程序模塊，殘留在模塊中的錯誤也多。軟件可靠性模型（Shooman）就是依據(jù)這個原則建立它的公式的。對于連鎖型分支結(jié)構(gòu)，若有n個判定語句，則有2n條路徑。因此，隨著n的增大，路徑數(shù)增長非?？?。單元測試時，因為樁模塊要模擬子模塊的功能，這不是一件容易的事情，而驅(qū)動模塊只是控制被測模塊的執(zhí)行，所以樁模塊的編寫比驅(qū)動模塊的編寫要難得多。在程序設(shè)計風(fēng)格方面，如果重復(fù)的代碼段沒有明顯的功能，不可以抽取出來形成獨立的公共過程或子程序，只有在這些代碼段表現(xiàn)出獨立的功能時，才可把它們抽取出來形成獨立的公共過程或子程序。另外，程序效率的提高主要應(yīng)通過選擇高效的算法或使用高效的語言編譯器來實現(xiàn)。GOTO語句概念簡單，使用方便，在某些情況下，保留GOTO語句反能使寫出的程序更加簡潔，這句話是正確的?！?-4】(1)②(2)⑩(3)⑨(4)⑧(5)④(1)對可靠性要求很高的軟件，由第三者對源代碼進行逐行檢查，這是代碼審查。(2)軟件變更時可能發(fā)生退化現(xiàn)象：原來正常的功能可能發(fā)生異常，性能也可能下降。因此，對變更的軟件要進行退化測試。(3)基于被測試模塊的內(nèi)部結(jié)構(gòu)或算法設(shè)計測試用例進行測試，這是白盒測試。(4)為了確認用戶的需求，先做出系統(tǒng)的原型，提交給用戶試用。(5)自頂向下對具有層次結(jié)構(gòu)的大型軟件進行集成測試時，需要設(shè)計一些虛擬模塊來替代尚未測試過的下層模塊，這些模塊叫做樁模塊?！?-5】對小程序進行窮舉測試，不見得能保證程序百分之百正確。所謂窮舉測試是拿所有可能的輸入數(shù)據(jù)來作為測試用例（黑盒測試），或覆蓋程序中所有可能的路徑（白盒測試）。對于小程序來說，實際上并不能真正作到窮舉測試。例如前面講過，一個小程序P只有兩個輸入X和Y及輸出Z，在字長為32位的計算機上運行。如果X、Y只取整數(shù)，考慮把所有的X、Y值都做為測試數(shù)據(jù)，按黑盒方法進行窮舉測試，這樣做可能采用的測試數(shù)據(jù)組（Xi，Yi），基數(shù)（radix）i的最大可能數(shù)目為：232×232＝264。如果程序P測試一組X、Y數(shù)據(jù)需要1毫秒，而且假定一天工作24小時，一年工作365天，要完成264組測試，需要5億年。

【5-6】單元測試又稱模塊測試，是針對軟件設(shè)計的最小單位─程序模塊，進行正確性檢驗的測試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯。單元測試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例。多個模塊可以平行地獨立進行單元測試。單元測試是在編碼階段完成的，每編寫出一個程序模塊，就開始做這個模塊的單元測試，所以只要采用模塊化方法開發(fā)軟件，單元測試都是必需的。它可由編寫程序的人來完成。因為它需要根據(jù)程序的內(nèi)部結(jié)構(gòu)設(shè)計測試用例，對于那些不了解程序內(nèi)部細節(jié)的人，這種測試無法進行?！?-7】A.③B.④C.②D.②E.②F.①G.④H.⑤I.①J.①軟件測試方法可分為黑盒測試法和白盒測試法兩種。黑盒測試法是基于程序的功能來設(shè)計測試用例的方法。除了測試程序外，它還適用于對需求分析階段的軟件文檔進行測試。白盒測試法是根據(jù)程序的內(nèi)部邏輯來設(shè)計測試用例的方法。除了測試程序外，它也適用于對軟件詳細設(shè)計階段的軟件文檔進行測試。白盒法測試程序時常按照給定的覆蓋條件選取測試用例。判定覆蓋比語句覆蓋嚴格，它使得每一個判定的每一條分支至少經(jīng)歷一次。判定/條件覆蓋既是判定覆蓋，又是條件覆蓋，但它并不保證使各種條件都能取到所有可能的值。多重條件覆蓋，也叫組合條件覆蓋，比其他條件都要嚴格，但它不能保證覆蓋程序中的每一條路徑。單元測試一般以白盒法為主，測試的依據(jù)是系統(tǒng)的模塊功能規(guī)格說明。【5-8】A.①B.⑤C.①D.②E.③軟件測試中常用的靜態(tài)分析方法是引用分析和接口分析。接口分析用于檢查模塊或子程序間的調(diào)用是否正確。分析方法（白盒方法）中常用的方法是路徑測試方法。非分析方法（黑盒方法）中常用的方法是等價類（劃分）方法和因果圖方法。因果圖方法根據(jù)輸出對輸入的依賴關(guān)系設(shè)計測試用例。面向?qū)ο蠹夹g(shù)復(fù)習(xí)要求1.了解面向?qū)ο蟮母拍?.了解用面向?qū)ο蠓椒?gòu)造軟件的開發(fā)過程3.了解面向?qū)ο蠓治龇椒?.了解面向?qū)ο笤O(shè)計方法習(xí)題【6-1】什么叫面向?qū)ο螅棵嫦驅(qū)ο蠓椒ǖ奶攸c是什么？為什么要用面向?qū)ο蠓椒ㄩ_發(fā)軟件？【6-2】什么是“對象”？識別對象時將潛在對象分成7類，試給出這7類對象的名稱，并舉例說明?！?-3】什么是“類”？“類”與傳統(tǒng)的數(shù)據(jù)類型有什么關(guān)系？有什么區(qū)別？【6-6】面向?qū)ο箝_發(fā)方法與面向數(shù)據(jù)流的結(jié)構(gòu)化開發(fā)方法有什么不同？使用面向?qū)ο箝_發(fā)方法的優(yōu)點在什么地方？【6-12】在類的設(shè)計中需要遵循的方針是什么？三個主要的設(shè)計準則：抽象、信息隱蔽和模塊化如何才能作到？習(xí)題解答【6-1】關(guān)于“面向?qū)ο蟆保性S多不同的看法。Coad和Yourdon給出了一個定義：“面向?qū)ο?對象+類+繼承+消息通信”。如果一個軟件系統(tǒng)是使用這樣4個概念設(shè)計和實現(xiàn)的，則認為這個軟件系統(tǒng)是面向?qū)ο蟮摹Ｃ嫦驅(qū)ο蠓椒ǖ奶攸c是：方法的唯一性，即方法是對軟件開發(fā)過程所有階段進行綜合考慮而得到的。從生存期的一個階段到下一個階段的高度連續(xù)性，即生存期后一階段的成果只是在前一階段成果的補充和修改。把面向?qū)ο蠓治?OOA)、面向?qū)ο笤O(shè)計(OOD)和面向?qū)ο蟪绦蛟O(shè)計(OOP)集成到生存期的相應(yīng)階段。使用面向?qū)ο蠓椒ㄩ_發(fā)軟件的好處是：開發(fā)方法的唯一性，開發(fā)階段的高度連續(xù)性，表示方式的一致性；問題空間實體的自然表示，減輕了設(shè)計者的負擔(dān)，在設(shè)計系統(tǒng)之初不必考慮一個很完整的解決方案。建立穩(wěn)定的系統(tǒng)結(jié)構(gòu)，可促進復(fù)用性，易于維護，易于修改，可合理利用共同性，減少復(fù)雜性。【6-2】對象的定義：對象是面向?qū)ο箝_發(fā)模式的基本成分，是現(xiàn)實世界中個體或事物的抽象表示。每個對象可由一組屬性和它可以執(zhí)行的一組操作來定義?？赡艿臐撛趯ο笥?類：外部實體：它們產(chǎn)生或接受為目標系統(tǒng)所使用的信息。如各種物理設(shè)備、使用人員、其它相關(guān)的子系統(tǒng)。事物：問題的信息域所涉及的概念實體。如各種報告、顯示、文字、信號、規(guī)格說明等。事件：系統(tǒng)運行時發(fā)生的并需要系統(tǒng)記憶的事件。如狀態(tài)轉(zhuǎn)換、物理運動等。角色：與系統(tǒng)有交互的各種人員所扮演的角色。如經(jīng)理、工程師、銷售人員等。場所或位置：建立系統(tǒng)整體環(huán)境或問題上下文的場所、位置。如基于計算機的系統(tǒng)的安裝場所等。組織機構(gòu)：與應(yīng)用有關(guān)的組織機構(gòu)。如組織，部門等。結(jié)構(gòu)：定義由一組成分對象組成的聚合對象，或在極端情況下，定義對象的相關(guān)類。如傳感器、四輪驅(qū)動車、計算機等?！?-3】把具有相同特征和行為的對象歸在一起就形成了類。類成為某些對象的模板，抽象地描述了屬于該類的全部對象的屬性和操作。屬于某個類的對象叫做該類的實例。對象的狀態(tài)則包含在它的實例變量，即實例的屬性中。類定義了各個實例所共有的結(jié)構(gòu)，類的每一個實例都可以使用類中定義的操作。實例的當前狀態(tài)是由實例所執(zhí)行的操作定義的。類，就它是一個數(shù)據(jù)值的聚合的意義上來看，與Pascal中的記錄或C中的結(jié)構(gòu)類似，但又有差別。類擴展了通常的記錄語義，可提供各種級別的可訪問性。也就是說，記錄的某些成份可能是不可訪問的，而這些成份對于本記錄型來說具有可訪問性。類不同于記錄，因為它們包括了操作的定義，這些操作與類中聲明的數(shù)據(jù)值有相同的地位?！?-6】結(jié)構(gòu)化開發(fā)方法是使用最廣泛、歷史最長的過程化開發(fā)方法。結(jié)構(gòu)化開發(fā)方法產(chǎn)生過程的抽象，這些抽象把軟件視為處理流，定義構(gòu)成一系列步驟的算法，每一步驟都是帶有預(yù)定義輸入和特定輸出的一個過程，把這些步驟串聯(lián)在一起可產(chǎn)生合理的穩(wěn)定的貫通于整個程序的控制流。這將最終導(dǎo)致一個很簡單的具有靜態(tài)結(jié)構(gòu)的體系結(jié)構(gòu)。在結(jié)構(gòu)化開發(fā)方法中，數(shù)據(jù)結(jié)構(gòu)是應(yīng)算法步驟的要求而開發(fā)的。數(shù)據(jù)結(jié)構(gòu)貫穿于過程，提供過程需要傳送給它的操作的信息。系統(tǒng)的狀態(tài)是一組全局變量，這組全局變量保持了狀態(tài)的值，把它們從一個過程傳送到另一個過程。結(jié)構(gòu)化開發(fā)方法是一種成熟的應(yīng)用開發(fā)過程。對這種方法已經(jīng)存在許多支持。然而，在大型系統(tǒng)的開發(fā)上和在面向用戶系統(tǒng)的構(gòu)造上存在一些問題。改進大型系統(tǒng)開發(fā)的技術(shù)主要集中在開發(fā)數(shù)據(jù)抽象。日益增多的考慮是使用抽象數(shù)據(jù)類型，把過程化系統(tǒng)開發(fā)過程包括到數(shù)據(jù)驅(qū)動的方法中。隨著大型系統(tǒng)的開發(fā)，接踵而來的問題就是要把過程抽象與數(shù)據(jù)抽象方法組合起來，這種需要導(dǎo)致了面向?qū)ο箝_發(fā)方法的誕生。面向?qū)ο箝_發(fā)方法是我們分解問題所使用方法演化的結(jié)果。在結(jié)構(gòu)化開發(fā)方法中過程抽象是優(yōu)先的，而面向?qū)ο箝_發(fā)方法中優(yōu)先的是實體，即問題論域的對象。在面向?qū)ο箝_發(fā)方法中，把標識和模型化問題論域中的主要實體做為系統(tǒng)開發(fā)的起點，主要考慮對象的行為而不是必須執(zhí)行的一系列動作。面向?qū)ο笙到y(tǒng)中的對象是數(shù)據(jù)抽象與過程抽象的一個混合體。表示這些實體的數(shù)據(jù)抽象是面向?qū)ο笤O(shè)計過程的主要產(chǎn)品，系統(tǒng)的狀態(tài)保存在各個數(shù)據(jù)抽象的核心所定義的數(shù)據(jù)存儲中?？刂屏鞅环殖蓧K，并被包括在各個在數(shù)據(jù)抽象上的各個操作里面。不像在結(jié)構(gòu)化開發(fā)方法里那樣，把數(shù)據(jù)從一個過程傳送到另一個過程，而是控制流從一個數(shù)據(jù)抽象被傳送到另一個數(shù)據(jù)抽象。完成的系統(tǒng)體系結(jié)構(gòu)更復(fù)雜但也更靈活。在塊中分離的控制流允許把復(fù)雜的動作視為局部的相互影響。【6-12】在設(shè)計類時需要遵循的方針是：信息隱蔽：通過信息隱蔽可保護類的存儲表示不被其它類的實例直接存取。消息限制：該類實例的用戶應(yīng)當只能使用界面提供的操作。 狹窄界面：只有對其它類的實例是必要的操作才放到界面上。強內(nèi)聚：模塊內(nèi)部各個部分之間應(yīng)有較強的關(guān)系，它們不能分別標識。弱耦合：一個單獨模塊應(yīng)盡量不依賴于其它模塊。顯式信息傳遞：兩個類之間的交互應(yīng)當僅涉及顯式信息傳遞。派生類當做派生類型：每個派生類應(yīng)該當做基類的特殊化來開發(fā)，而基類所具有的公共界面成為派生類的共有界面的一個子集。抽象類：某些語言提供了一個類，用它做為繼承結(jié)構(gòu)的開始點，所有用戶定義的類都直接或間接以這個類為基類。為了在類的設(shè)計中做到抽象、信息隱蔽和模塊化：以類作為系統(tǒng)的基本模塊單元，通過一般化―特殊化關(guān)系和整體―部分關(guān)系，搭建整個系統(tǒng)的類層次結(jié)構(gòu)，實現(xiàn)數(shù)據(jù)抽象和過程抽象；將數(shù)據(jù)和相關(guān)的操作封裝在類內(nèi)部，建立共有、私有和子類型等存取級別，將數(shù)據(jù)表示定義成為類的私有成員，實現(xiàn)信息隱蔽。通過建立類屬性(類模板)，將某些有可復(fù)用要求的類設(shè)計成在數(shù)據(jù)類型上通用的可復(fù)用的軟件構(gòu)件，這樣有助于實現(xiàn)模塊化。軟件維護在軟件交付使用后修改軟件的過程稱為軟件維護。軟件維護一般不包括重大的體系結(jié)構(gòu)的改變，變更的實現(xiàn)方法一般是修改已有的系統(tǒng)構(gòu)件以及在必要的地方添加新構(gòu)件到系統(tǒng)中。軟件維護的分類?改正性維護：修改軟件缺陷。?適應(yīng)性維護：適應(yīng)變更的操作環(huán)境（硬件、操作系統(tǒng)平臺、其他支持軟件）。?增強性維護：系統(tǒng)需求改變（機構(gòu)因素、業(yè)務(wù)改變）軟件再工程是試圖增加當前系統(tǒng)（或稱遺留系統(tǒng)）的總體質(zhì)量、提高可維護性的工程。軟件再工程過程中的活動主要包括以下幾個方面：?文檔重構(gòu)(redocument)?結(jié)構(gòu)重組(restructuring)?逆向工程(reverseengineering)?再工程(reengineering)【7-6】改錯性維護與“排錯”是否是一回事？為什么？【7-7】從下列敘述中選出5條與提高軟件的可移植性有關(guān)的敘述。①把程序中與計算機硬件特性有關(guān)的部分集成在一起。②選擇時間效率和空間效率高的算法。③使用結(jié)構(gòu)化的程序設(shè)計方法。④盡量用高級語言編寫程序中對效率要求不高的部分。⑤盡可能減少注釋。⑥采用表格控制方式。⑦文檔資料詳盡、正確。⑧在有虛擬存儲器的計算機系統(tǒng)上開發(fā)軟件。⑨減少程序中對文件的讀寫次數(shù)。⑩充分利用宿主計算機的硬件特性?！?-6】改錯性維護與“排錯(調(diào)試)”不是一個概念。調(diào)試是作為測試的后繼工作而出現(xiàn)的，是當測試發(fā)現(xiàn)軟件中的錯誤后，進一步診斷和改正程序中潛在的錯誤的活動。而改正性維護是指在軟件交付使用后，由于開發(fā)時測試的不徹底、不完全，必然會有一部分隱藏的錯誤被帶到運行階段來，這些隱藏下來的錯誤在某些特定的使用環(huán)境下就會暴露出來。為了識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使用所進行的診斷和改正錯誤的過程。調(diào)試在程序編碼階段、測試階段、運行和維護階段都可以發(fā)揮作用，它實際上是一種工具或手段。在軟件交付運行之后，用戶實際充當了測試員的角色，一旦發(fā)現(xiàn)軟件運行中的錯誤或缺陷，就會將問題報告通報軟件銷售商，申請軟件維護。其后軟件維護人員可以利用調(diào)試手段來診斷和改正軟件中存在的錯誤。這時可能涉及的范圍不只包括程序，還有文檔和數(shù)據(jù)，不僅可能修改程序代碼，而且可能需要修改設(shè)計。甚至需求。所以改正性維護是在更大范圍中做工作?！?-7】正確的敘述有①、③、④、⑥、⑦。 為了提高軟件的可移植性，應(yīng)當盡可能用高級語言編寫源程序代碼。對于與硬件或操作系統(tǒng)有關(guān)的部分，或?qū)π室蠛芨叩牟糠?，?yīng)當為它們建立專門的模塊，將用匯編語言寫的程序封裝在這些模塊中，與程序中其它部分以事先約定的標準方式接口。這樣，一旦硬件環(huán)境或操作系統(tǒng)環(huán)境發(fā)生變化，只需修改個別模塊即可。 采用表格控制方式，將所有的外部設(shè)備接口或與其它系統(tǒng)的接口，包括信息傳遞、驅(qū)動程序入口等都用表格控制，即使將來硬件、相關(guān)軟件發(fā)生的變化，只需修改表格中的登記項，原來的程序一律可以不改。 為了將來修改方便，不致于引入新的錯誤，相關(guān)文檔一定要齊全、正確，程序中必須有必要的注釋，并使用如結(jié)構(gòu)化程序設(shè)計方法這樣的良好的程序設(shè)計方法來編寫程序。至于算法選擇，與效率有關(guān)，與可移植性無關(guān)。其它敘述，如⑧、⑨、⑩，都不利于可移植性。軟件測試工程師績效評估表軟件測試工程師職責(zé)：1與軟件產(chǎn)品部配合完成軟件需求分析討論，并根據(jù)需求說明書制定《項目測試（計劃）方案》；編寫《測試用例》；建立測試環(huán)境；2負責(zé)研發(fā)部門各開發(fā)組研發(fā)的軟件產(chǎn)品開發(fā)過程和投入運營之前的新增軟件和修改軟件的模塊測試和系統(tǒng)測試；建立、推廣并維護實施軟件版本管理系統(tǒng)；3負責(zé)推廣實施軟件開發(fā)文檔規(guī)范化工作，管理研發(fā)產(chǎn)品相關(guān)文檔；4負責(zé)配合軟件研發(fā)部門等對于新項目軟件或修改升級項目軟件的測試工作，并提供測試報告；5負責(zé)監(jiān)督軟件開發(fā)流程的執(zhí)行，并負責(zé)提出軟件開發(fā)過程改進建議，提高軟件產(chǎn)品質(zhì)量。6與開發(fā)工程師和研發(fā)部門交流報告任務(wù)進展情況，并提出最近的測試需求；7測試部負責(zé)制訂測試計劃、測試用例和測試實施方案，項目主負責(zé)人安排測試與對應(yīng)的開發(fā)人員交流完成測試執(zhí)行工作；及時提交準確、完整的《項目測試報告》；8項目主負責(zé)人負責(zé)開發(fā)流程管理和人力資源、測試用軟硬件資源調(diào)配，需要與研發(fā)之外的部門定期交流掌握下周或近期可能測試任務(wù)；9外部接口都由測試部主管負責(zé)完成，與其他項目組和產(chǎn)品部門協(xié)調(diào)項目進度；二．軟件測試的不確定性：1軟件測試的目的就是使軟件的錯誤不斷趨進于零，但軟件的錯誤是永遠找不完的；2開始測試時，可能軟件使用1個小時就出現(xiàn)10個錯誤；測試修正后1個小時出現(xiàn)一個錯誤，繼續(xù)修正，繼續(xù)測試，直到約一個月出現(xiàn)一個錯誤。這時這個出錯幾率已經(jīng)通過終結(jié)評審可以接受了。那么測試就結(jié)束了。移植成功之后測試工作由開發(fā)部門來維護。3測試一些成熟的游戲或應(yīng)用，測試過程中很難發(fā)現(xiàn)大量的缺陷；而測試一些不成熟的游戲或應(yīng)用，在測試前期，會出現(xiàn)大量的問題；這樣就導(dǎo)致不同的工程師發(fā)現(xiàn)不同數(shù)量的bug；4軟件測試的進度首先會按照測試計劃逐步進行，但是在測試過程中，測試進度會隨研發(fā)部門的進度而調(diào)整；所以積極的與研發(fā)部門交流、協(xié)調(diào)測試中的問題是相當必要的。三．測試工作最低成功標準及測試工程師考核內(nèi)容：測試工作的最終目標就是發(fā)現(xiàn)客戶可能發(fā)現(xiàn)的所有錯誤。如果移植測試在使用第一天就發(fā)現(xiàn)了你沒測試出來的錯誤，那測試是失敗的。如果使用了很久（如幾個月）才出現(xiàn)錯誤，那說明測試還是成功的。測試工程師考核內(nèi)容：1測試工程師比開發(fā)工程師更了解產(chǎn)品；（產(chǎn)品各模塊總體把握能力）2測試工程師能從客戶的角度來檢測軟件的功能；（用戶身份）3測試工程師獲取資料，使得編制的測試用例更切合測試的重點、難點以及關(guān)注點；（編寫測試用例）4測試工程師比開發(fā)工程師更容易發(fā)現(xiàn)產(chǎn)品的問題；（不同的思維模式）5測試工程師總是不斷的發(fā)現(xiàn)問題，驗證問題；（提交bug數(shù)量、bug質(zhì)量）6測試工程師按照測試計劃完成各自工作；（測試計劃的執(zhí)行能力）7測試工程師以操作員的角度測試產(chǎn)品；（Free測試能力）8測試工程師及時與開發(fā)工程師溝通、交流解決問題；（部門間的工作協(xié)調(diào)能力）9測試工程師及時提交測試報告；（報告的及時性、準確性）10測試工程師之間處理問題；（共同完成任務(wù)）11測試工程師協(xié)助開發(fā)工程師，了解開發(fā)流程等信息；（學(xué)習(xí)能力）四．軟件測試人員工作業(yè)績評估的誤區(qū)：1不能僅從提交的問題數(shù)量、測試執(zhí)行用例數(shù)量來判斷測試人員的好壞；模塊A很不穩(wěn)定，潛在的問題數(shù)可能有100個，由測試人員甲負責(zé)測試，他一個月執(zhí)行300個用例，提交50個問題單，發(fā)現(xiàn)30個有效問題，有10個嚴重問題；

模塊B比較穩(wěn)定，潛在的問題數(shù)可能有20個，由測試人員乙負責(zé)測試，他一個月執(zhí)行100個用例，提交20個問題單，發(fā)現(xiàn)18個有效問題，有8個嚴重問題；

從上述測試執(zhí)行結(jié)果來看，甲提交的問題單數(shù)量和執(zhí)行用例數(shù)量都要遠遠高于乙，但是從測試的質(zhì)量來看，模塊B的遺留問題顯然少于模塊A，甲執(zhí)行測試的充分性顯然不如乙，從問題單質(zhì)量來看，甲提交的問題單雖然很多，但近半數(shù)是非問題，做了無用功，還影響到開發(fā)人員對問題的定位所消耗的時間。

因此，必須要走出用問題單數(shù)量、用例數(shù)量評價測試人員的誤區(qū)。2對軟件人員發(fā)現(xiàn)的問題的價值沒有進行評估；發(fā)現(xiàn)一個系統(tǒng)架構(gòu)設(shè)計方面的缺陷和隱患遠比發(fā)現(xiàn)幾個普通界面顯示問題的價值大的多；3不重視測試文檔的質(zhì)量；測試文檔的質(zhì)量往往是測試人員測試水平的反映；只有對系統(tǒng)進行了統(tǒng)分的、深入的測試人員才能寫出高質(zhì)量的測試報告；4不重視測試人員的綜合能力；責(zé)任心、積極性、創(chuàng)造性以及溝通和協(xié)調(diào)能力附：軟件測試工程師業(yè)績評估模板：（滿分：100分）軟件測試工程師業(yè)績評估模板：（滿分：100分）類型評定參數(shù)參數(shù)值說明問題（35%）提交有效問題數(shù)量單位（個）最基本的考核指標提交的非問題數(shù)量單位（個）需要測試人員意識到處理非問題影響測試、開發(fā)的工作效率；測試主管必須嚴格審核測試人員提交的bug提交問題的規(guī)范性優(yōu)秀良好普通不合格問題描述是否清晰；相關(guān)trace文件是否齊全；問題等級、版本等信息是否正確；問題跟蹤是否到位；嚴重問題所占比例單位（%）(嚴重問題/問題總數(shù))*100%提交問題的質(zhì)量非常好很好一般良好低綜合評定測試人員提交問題的質(zhì)量；測試人員發(fā)現(xiàn)問題的深入程度；工作效率提交bug驗證bug優(yōu)秀良好普通不合格對自己所提交問題的多版本跟蹤；Check他人bug的程度；不同模塊功能的理解程度；測試用例（20%）執(zhí)行用例覆蓋率開發(fā)用例難度困難普通容易編寫測試用例質(zhì)量….用力的難度直接反映測試人員的測試能力；并影響測試效率；FREETEST….用例外，測試發(fā)現(xiàn)問題的能力新增測試用例價值….新增測試用例質(zhì)量….文檔（15%）測試報告質(zhì)量優(yōu)秀良好普通不合格測試報告的規(guī)范化程度；及時性；準確性；內(nèi)部測試文檔、測試經(jīng)驗的交流及共享經(jīng)常偶爾從不測試工作的協(xié)調(diào)；經(jīng)驗的交流；問題的確定；等等態(tài)度（30%）工作積極性優(yōu)良中差主動解決測試中遇到的問題；溝通能力…根據(jù)實際情況，分析評價；學(xué)習(xí)能力…不斷的提高工作效率；項目了解（主動性）…對項目總體的把握；測試計劃的執(zhí)行…執(zhí)行計劃；部門間團結(jié)協(xié)作…各部門相互配合解決問題；上級主管綜合評定及意見：綜合評定：部門經(jīng)理給出測試人員考核評定及意見附：軟件測試工程師業(yè)績評估模板評估類型績效指標評價標準分值備注評分等級分值激勵方式軟件測試績效工作態(tài)度嚴格遵守各項工作制度和崗位要求。

工作認真負責(zé)，責(zé)任心強。

能夠主動進行工作溝通、交流。

主動發(fā)現(xiàn)問題，并且跟蹤解決。

積極參與測試組各項活動，能夠主動承擔(dān)組內(nèi)工作。16-20分1、工作制度遵循性（公司考勤制度、崗位職責(zé)）

2、工作認真性、責(zé)任心

3、工作積極性

4、溝通、交流

5、主動性、參與性A59~70基本獎勵2倍金額遵守各項工作制度和崗位要求。

工作認真負責(zé)，責(zé)任心強。

能夠主動進行工作溝通、交流。

主動發(fā)現(xiàn)問題，基本能做到跟蹤解決。

參與測試組各項活動，能夠承擔(dān)組內(nèi)工作任務(wù)。11-15分B40~54基本獎勵

遵守各項工作制度和崗位要求。

工作認真負責(zé)，責(zé)任心強。

能夠進行工作中基本溝通、交流。

發(fā)現(xiàn)問題，缺少跟蹤解決。

參與測試組各項活動，能夠承擔(dān)組內(nèi)工作。6-10分C21~35提出改進有督導(dǎo)情況下

基本能遵守各項工作制度和崗位要求。

能基本按要求完成任務(wù)。

進行基本工作溝通、交流。

發(fā)現(xiàn)問題，缺少跟蹤解決。

基本能參與測試組各項活動，不能夠承擔(dān)組內(nèi)工作。0-5分D0~16警告，如果導(dǎo)致影響工作進度、影響上線產(chǎn)品質(zhì)量根據(jù)影響程度給予一定金額處罰。測試用例嚴格按照用例模版編寫用例

根據(jù)需求設(shè)計有效用例，覆蓋所有的需求點。

用例描述準確、簡潔、清晰，評審?fù)ㄟ^率高。

按計劃執(zhí)行用例并且能夠及時補充用例保證用例完整性，對于無法執(zhí)行或不具備環(huán)境不能法執(zhí)行用例及時溝通，并且測試結(jié)果中具體說明。9-10分1、測試用例規(guī)范性

2、設(shè)計有效性（覆蓋率）

3、用例描述的準確性

4、用例評審?fù)ㄟ^率

5、用例執(zhí)行有效性（是否按計劃執(zhí)行）

6、用例及時性、準確性、完整性能夠按照用例模版編寫用例

根據(jù)需求設(shè)計有效用例，基本覆蓋所有的需求點。

用例描述比較準確、簡潔、清晰，評審?fù)ㄟ^率高。

按計劃執(zhí)行用例并且能夠及時補充用例保證用例完整性，對于無法執(zhí)行或不具備環(huán)境不能執(zhí)行用例及時溝通。并且測試結(jié)果中具體說明。6-8分在有人員指導(dǎo)情況下達到以下標準或者個人獨立工作達到以下要求

能夠按照用例模版編寫用例

根據(jù)需求設(shè)計有效用例，基本覆蓋主要功能的需求點。

用例描述基本準確、簡潔、清晰，通過評審可以達到要求。

基本按計劃執(zhí)行用例并且基本能及時補充用例保證用例完整性。對于無法執(zhí)行或不具備環(huán)境不能執(zhí)行用例基本做到及時溝通，并且測試結(jié)果中具體說明。3-5分基本能按照用例模版編寫用例

根據(jù)需求設(shè)計有效用例，沒有覆蓋所有的需求點。

用例描述基本準確、簡潔、清晰，通過評審可以達到要求。

不能按計劃執(zhí)行用例并且能夠及時補充用例保證用例完整性。對于無法執(zhí)行或不具備環(huán)境不能執(zhí)行用例基本做到及時溝通0-2分測試BUG能夠按照規(guī)定的流程提交并跟蹤BUG的全過程。

BUG描述語言簡潔、準確。

BUG再現(xiàn)步驟清晰、條理性強，易于再現(xiàn)。

依據(jù)需求提交相應(yīng)BUG，沒提交錯誤BUG。

能夠分析和定位產(chǎn)生的原因，并能根據(jù)BUG的產(chǎn)生趨勢做出有效的質(zhì)量和風(fēng)險風(fēng)析9-10分1、bug規(guī)范（1、描述2、bug和用例相對應(yīng)）

2、bug描述準確性

3、重顯性

4、bug有效性

5、bug總結(jié)