第1章軟件測試的基本概念1、 什么是軟件測試？軟件測試的定義（IEEE1983）:是使用人工和自動手段來運行或測試某個系統(tǒng)的過程，目的在于檢驗其是否滿足規(guī)定的需要或是弄清楚預期結果與實際結果之間的差別。2、 什么是軟件缺陷？軟件缺陷的定義（IEEE1983）:從產品內部看，軟件缺陷是軟件產品開發(fā)或維護過程中所存在的錯誤、毛病等各種問題。從產品外部看，軟件缺陷是系統(tǒng)所需實現(xiàn)的某種功能的失效或違背。3、 什么是測試用例？測試用例的定義（IEEE1990）:是一組測試輸入、執(zhí)行條件和預期結果，目的是要滿足一個特定的目標，比如執(zhí)行一條特定的程序路徑或檢驗是否符合一個特定的需求。TOC\o"1-5"\h\z4?沒有安裝操作系統(tǒng)的裸機中有軟件嗎 ？有軟件。在主板上的CMO芯片中嵌入了BIOS程序，可以看做是一個簡單的嵌入式軟件。5?軟件測試就是通過運行程序來查看錯誤。對嗎 ？錯。軟件測試不僅包括動態(tài)測試，還包括靜態(tài)的檢查。測試的對象不僅針對查程序，還需要針對文檔。6?軟件產品發(fā)布給用戶之后發(fā)現(xiàn)了缺陷，將導致怎樣的后果 ？軟件產品發(fā)布給用戶之后，若由用戶發(fā)現(xiàn)了缺陷，則視缺陷的嚴重程度和影響范圍，導致的后果不同。若導致用戶系統(tǒng)崩潰、嚴重數(shù)據(jù)丟失、巨大的經濟損失，甚至造成人身傷害，則對公司的影響很大。若只是造成用戶使用不便，則其產品可能遭到用戶的拋棄或投訴。7?手機測試是硬件測試，還是軟件測試 ？既是硬件測試，又是軟件測試。針對手機外殼、抗摔、防水等方面的測試是硬件測試，針對手機的通話質量、短信、游戲等方面的測試屬于軟件測試。&為什么說軟件的需求規(guī)格說明書往往是軟件缺陷的最大來源 ？其結論對軟件測試工作有何啟發(fā)？需求規(guī)格說明是通過需求分析得到，需求的變動，需求本身描述的不一致、不正確、不完整將導致設計的變更和設計的缺陷，并進一步影響編碼的正確性。因此，導致軟件與預期結果的偏差越來越大。請仿照NextDate問題，針對PrevDate問題設計測試用例。PrevDate問題的功能簡述如下。當用戶輸入有效日期時（從1800年1月1日到2050年12月31日之間的所有日期），系統(tǒng)將自動計算出前一天的日期，否則，系統(tǒng)不執(zhí)行日期的計算，并給岀消息提示輸入無效。表1-1PrevDate的部分測試用例集合ID輸入數(shù)據(jù)（年月?日〉預期輸出備連00】1950-6-151950^6-14正常數(shù)據(jù)002IK00441799-1241邊界數(shù)據(jù)0032050-12-312050-12-30邊界數(shù)據(jù)00417004)-0提示輸入日期無效無效輸入0053000-15-35提示輸入H期迓效無效輸入006提樂輸入II期無效無效輸入007y-m-d提示輸入日期無效無效輸入00S1550-6-捉示輸入門期無效無效輸入0091950-槌嚇輸入II期無效無效輸入010無輸入提嚇輸入U期無效無效輸入

請仿照NextDate問題，針對NextMultiDate 問題設計測試用例。NextMultiDate問題的功能簡述如下。若用戶輸入有效日期（從1800年1月1日到2050年12月31日之間的所有日期），并指定延遲的天數(shù)（最多不超過366天），假設為n,則系統(tǒng)將自動計算出從有效日期往后 n天的日期。對于無效日期或無效延遲天數(shù)，系統(tǒng)不執(zhí)行日期的計算，并給岀消息提示輸入無效。表1-2NextWultiDate的部分測試用例集合ID輸入數(shù)據(jù)預期輸出備注年-小口延遲犬數(shù)仙19MM5-151I950-6J6H期：止常饑大融丨天UU21950-6-1531950-^114口期：正常創(chuàng)，尺數(shù)：不足1周(XJ33950-6-1571950^-22H期；止簾仇.天數(shù)；1周0041950-615151950口期：正布值.天數(shù)：不足i打0053950-6-15301950-745日期'正常值.天數(shù)；】月(X161950-6-151K21950^12-14H期土正‘甜價?天數(shù)：不足1年0071950-6-153651951-6-15日期：匸常值?人數(shù)：L年期1lKOO^I-2H期】邊界値大如1天□092050-12-3112O5M-]仃期：邊界值，天熱1天0101700-0-01提不輸入H期尢效尢效輸入OILJ00045361捉示輸入口期無效無效輸入0121提彷輸入H期元效無效輸入01Jy-m-d1捉示輸入H期無效無效輸入0M1950-6-1提示輸入口期無效無效輸入015W50-1振示輸入Ft期無效無效輸入016無輸入1捉示輸入口期無效無效輸入11?若需要對多個測試用例進行管理，除了 ID、輸入和輸岀之外，需針對每個測試用例補充哪些信息 ？測試用例的構成：ID、、項目/軟件、程序版本、編制人/編制時間、功能模塊、測試項、測試目的、預置條件、參考文獻、測試環(huán)境、測試輸入、操作步驟、預期結果、執(zhí)行結果、優(yōu)先級、測試用例之間的關聯(lián)。12.請針對1.4.5節(jié)NextDate問題的第二次測試中所給出的測試用例，補充測試環(huán)境。NextDate的測試環(huán)境應根據(jù)實際的開發(fā)和使用環(huán)境而定， 從軟件使用環(huán)境、 開發(fā)平臺等角度考慮即可。13?請針對第6題的PrevDate問題，補充測試環(huán)境。同上題。第2章軟件測試原理1、對待缺陷我們應遵循哪些基本原則 ？對待缺陷的基本原則：缺陷的群集現(xiàn)象、缺陷有免疫力 （測試要使用不同的測試方法）、缺陷關聯(lián)和依賴（單純依賴、多重依賴、復合依賴）。2、當受到進度壓力的時候，是優(yōu)先進行黑盒測試還是白盒測試 ？應優(yōu)先進行黑盒測試，因為黑盒測試不需要了解程序實現(xiàn)的細節(jié)， 通過黑盒測試至少可以證明：被測軟件系統(tǒng)可以完成哪些功能，哪些功能不能正確的實現(xiàn)，哪些功能甚至完全沒有實現(xiàn)。3、 針對同樣的問題（例如相同的代碼段），采用黑盒測試與白盒測試方法得到的測試用例會有很多是重復的，那么，白盒測試有意義嗎？白盒測試有重要的意義，它主要是覆蓋黑盒測試方法檢查不到或難以發(fā)現(xiàn)的某項缺陷， 白盒測試指標還可以充當對黑盒測試方法效果的檢查，判斷測試是否存在漏洞或冗余。TOC\o"1-5"\h\z4、靜態(tài)測試不需要執(zhí)行程序，那么，是否可以用靜態(tài)測試替代動態(tài)測試呢 ？不可以。靜態(tài)測試與動態(tài)測試之間即具有一定的協(xié)同性， 同時又具有相對的獨立性。 程序靜態(tài)分析的目標不是證明程序完全正確，而是作為動態(tài)測試的補充，在程序運行前盡可能多地發(fā)現(xiàn)代碼中隱含的缺陷。5、良好的單元測試是否可以替代集成測試 ？不能。良好的單元測試只能確保通過測試的單元內部基本可以正常工作， 但不能保證單元集成在一起之后，能夠正常工作，特另U要關注可能存在誤差累積的情況。在單元測試與集成測試的關系中，即使保證每個單個的單元具有優(yōu)秀性能，也不能確保整體的性能。6、自動化測試工具可以讓繁重的手工勞動變得輕松，那么，我們還有必要做手工測試嗎 ？自動化測試目前不可能完全替代手工測試， 一方面是由于自動化測試工具的適用面都相對較窄， 一種測試工具往往僅能處理很小一方面的測試問題，另外，有些測試活動需要重復發(fā)揮人的創(chuàng)造力，采用自動化測試工具不可能收到同樣的效果。7、只要學會某種時下流行的自動化測試工具的使用，就可以輕松搞定測試工作了，是這樣嗎 ？不管是什么測試工具，它實質反映的是其背后的測試思想，因此，拋開測試方法去學習測試工具的使用，是沒有任何意義的。而且，測試工具使用的前提是必須有測試用例為指導，得到的測試腳本才具有復用性，而測試用例的設計涉及多種測試方法。因此，完全不懂測試技術是不能勝任軟件測試崗位的。8什么是冒煙測試？如何實施？冒煙測試是通過簡單測試來判斷系統(tǒng)基本功能 （通常是核心業(yè)務模塊）的覆蓋率如何，而不驗證正確性。例如能否正確安裝/卸載，主要功能是否實現(xiàn)，是否存在嚴重死機或數(shù)據(jù)嚴重丟失等缺陷。冒煙測試工作一般需要實現(xiàn)自動化， 可以借助諸如WinRunner、QTP這樣的工具來錄制自動化測試腳本，腳本由專人維護，且隨著測試的進展對腳本不斷進行增補。9、 隨機測試就是隨便測試，往往會取得意想不到的效果，因此，我們應在軟件開發(fā)過程中廣泛使用隨機測試。是這樣嗎？不能這樣。隨機測試是沒有測試用例的，且往往是不可重復的。這對缺陷的重現(xiàn)十分不利，且廣泛采用隨機測試將不能保證測試的全面性，無法了解測試的整體效果。若在軟考開發(fā)過程中廣泛使用，可以表明測試過程是混亂的，缺乏管理的，則最終提交的軟件產品質量是完全無法保證的。10、在任何情況下，我們執(zhí)行回歸測試時，都應將以前測試過的用例全部執(zhí)行一遍，是這樣嗎 ？不是這樣的。回歸測試是貫穿在整個測試的各個階段的一個測試活動， 主要是對修改過的軟件重新進行測試，目的是為了驗證修改的正確性及其影響?；貧w測試包的選擇應根據(jù)進度、風險、修改情況等全盤考慮。11、 我們該如何應用各種測試過程模型？12、軟件測試的目的是證明程序可以工作。軟件測試的目的是證偽。這兩種說法哪個正確 ？兩種說法都正確，但有存在片面性，應視不同的情況予以應用。13、對比軟件測試工程師的素質要求，你認為自己可以勝任軟件測試工程師的崗位嗎 ？軟件測試工程師的素質要求：兩項意識：服務意識、團隊合作意識。三顆“心”：耐心、細心、信心。四種能力：技術能力、溝通能力、逆向思維能力、移情能力。五個特性：實在幽默、十足記憶、時刻懷疑、十面督促、十分周全。第3章黑盒測試技術?進行邊界值測試時，為何要以邊界點為中心，以一個單位長度作為鄰域，而不是直接選擇“ 1”為鄰域？進行邊界值測試時，當以一個單位長度為鄰域時，鄰域隨著單位長度的變化而改變。若研究的粒度較精細，可選擇更小的鄰域，而若邊界粒度較粗，則應適當增加單位長度，擴大邊界的鄰域范圍。單位長度可方便地調節(jié)邊界值測試的鄰域。若直接選擇“ 1”為鄰域，則有時會造成邊界影響面太小，導致遺漏缺陷。?邊界值測試中所選擇的輸入測試數(shù)據(jù)一定是有效數(shù)據(jù)。是這樣嗎 ？不一定。邊界值測試僅關注邊界，設計測試用例時不區(qū)分系統(tǒng)輸入在邊界點上是否有效。因此，系統(tǒng)輸入在邊界點上可能是有效的，也可能是無效的。?邊界值測試中，若考慮邊界的組合情況，即缺陷岀現(xiàn)在多個輸入條件的邊界或邊界附近，則稱這樣的策略為最壞情況測試。若給出兩個輸入條件 x,y，其中條件x具有3個極值點（x1，x2，x3），條件y具有2個極值點（yl，y2），如圖3-1所示。請采用最壞情況測試方法，導出測試用例的數(shù)目，并設計相應的測試用例。聚壞媲況測試〔兩個輸入條件》最壞情況測試方法相當于在基本邊界值分析的基礎上， 考慮x,y條件同時取得邊界，所以圖1中矩形框的邊界和邊界附近都應取到測試用例。測試用例如圖 3-1所示。測試用例數(shù)目為4X7+4X2+7X1=43。圖3-1最壞情況測試I兩個輸入條件）表3T最壞情況測試的測試用例茨合ID綸入x y備注(X)lxl0*y2)/2“収邊界.y取正簾值002X/+10?/+v2)/2003x2-l0W)/2004x2UW)/2005x2+l0?W)/2006x3A0?W)/2007x3(yl^y2)/2008(xl^x2\/2yt『啦界■ME柚009(xl^x2\T2y/+l010(xl^x2)/2"?1Oil(xl\x2)l2y2012(x2\x3M2yi013(x2+x3\/2f/+1014(x2\x3}!2y2-\015Cv2+x3"2y2016xlyiX取邊界.y取F邊界017X/+Iyi018a-2-1yi019x2yi020x2+lyi021x3Ayi022x3W023xly/+lX取邊界?y取下邊界附近024x/+lW+l025x3AW+l026x2F/+1027x2^\y/+l028aMW+l029x3F/+I030xlW?1X取邊界?『取上邊界附近031x/+ly2A032x3Aw?i033x2034x2^\y2A035x3\），2?l036x3)21037xlx取邊界.丁取上邊界038x/+ly2039x3-\y2040x2y2041y2042x3\v2043x3y2對于3.2.8節(jié)的Commission問題，請采用基本邊界值分析方法，從輸入域設計測試用例。從輸入域采用基本的邊界值分析，得到測試用例集合見表 3-2。表中預期輸岀是指銷售員的總提成。表3-2輸入域的基本邊界值分析測試用例（Commission問題）ID輸入數(shù)據(jù)＜W：〔單位：元）預期輸出（小位：7L）備注紅酬銷咎星岬聲常咎量001501.515150,150940.9505.529,75針對白苕002511.515150,15094LIIK邊界4.999I..5I5150,150L772J829,68651(KM5,0001,515L772.5509,GX7.750052.52530150.1501J7S,55O6.717,75針對紅活0062.52531150,1501.17?/?70旅1畑邊界(M)72.5252,999150.1501,53030K.499J5oos2,525J.OtJO150.1501t5J4.95O(XJS?2.5251,515300607,5003,862.50針對啤灑0102.5251.515301607.5053妣"on2.5251.51529.^99755.9950122.5251.5157血（XX】4,605.00對于3.2.8節(jié)的Commission問題，請分析案例實踐二（見本書光盤部分的圖3.1）中所有邊界點是如何得到的。各種酒的單價為：白酒168元/瓶,紅酒120元/瓶，啤酒5元/瓶。各銷售員每月至少需售出白酒 50瓶,紅酒30瓶，啤酒300瓶。由此得到最低銷售額：1.35萬元，對應最小邊界點。每個銷售員的月供最高為白酒5000瓶，紅酒3000瓶，啤酒30000瓶，由此得到最高銷售額：135萬元，對應最大邊界點。銷售員的提成公式中，發(fā)生提成比例變化的點為： 2萬元和4.5萬元，由此得到中間的兩個邊界點。6?當時間有限時，應優(yōu)先針對輸入域進行邊界值測試，還是針對輸岀域分析邊界 ？為什么？當時間有限時，應優(yōu)先從輸入域考慮邊界值測試。因為系統(tǒng)總是根據(jù)輸入情況來決定如何進行輸岀響應。且輸岀域的邊界值測試用例與輸入域的測試用例有很多重復的情況。因此，一般情況下，先對輸入域展開測試，然后根據(jù)輸岀域的特殊性，補充更多邊界測試用例。7?如何才能方便、快捷地了解劃分岀的等價類是否能夠體現(xiàn)真正的等價呢 ？有兩種途徑：第一種方式是正向判斷法。即從正向觀察系統(tǒng)是輸入和輸岀， 在劃分得到的等價類中隨便選擇幾個數(shù)據(jù)，并從如下方面來觀察：?這些數(shù)據(jù)是否包含相同的輸入條件。?這些數(shù)據(jù)是否導致程序執(zhí)行類似的處理。?這些數(shù)據(jù)是否影響相同的輸出結果。?這些數(shù)據(jù)要么都讓軟件執(zhí)行錯誤處理，要么都不讓。若以上方面中任何一方面不成立，則等價類劃分肯定有問題。第二種方法是結合決策表方法，若從該等價類劃分無法得到精確無誤的決策表， 則說明該等價類劃分是不“等價”的。&為什么對無效等價類設計測試用例時要采取一一對應原則，這對測試有何好處 ？設計測試用例時，采取一一對應原則的含義是每個測試用例唯一覆蓋一個無效等價類， 這樣的處理方式有利于缺陷的定位。一旦某個測試用例失敗，我們可以很方便地了解，系統(tǒng)對于哪個輸入條件的哪個無效等價類無法適當予以處理。9?案例實踐三的NextDate實例中，測試用例ND-EP-001到ND-EP-007（見本書光盤）可以很好地考查系統(tǒng)的容錯能力，但從滿足用戶需求的角度而言，這個測試用例的集合違反了實際工作中的一些基本原則，是哪些原則呢？在實際的測試工作中，我們總是優(yōu)先滿足系統(tǒng)的基本功能， 即優(yōu)先測試系統(tǒng)的基本功能，看是否能夠正確實現(xiàn)，在測試用例上數(shù)目也會更多一些。而在本例中僅有一個測試用例去測試基本功能，卻有 6個測試用例考查系統(tǒng)的容錯能力，這是不合適的。另外，測試應盡量避免漏洞，而不怕冗余，本例中只有一個針對正常數(shù)據(jù)的測試用例，由此導致的測試漏洞是很大的，因此也違反了測試應避免漏洞的基本原則。10、對于NextDate問題，若將2000年從閏年有效等價類中分離出來， 其余兩輸入條件的劃分方式參照 3.3.8節(jié)的第二次等價類劃分嘗試（見本書光盤部分的表3.9）。請采用弱組合和強組合方式分別設計等價類測試的測試用例。此時的等價類劃分如表3-3所示。若采用弱組合形式進行等價類測試， 得到的一組測試用例構成和最終的用例集合分別如表3-4和表3-5所示。^3-3NextDate問題的等價類劃分等怖瓷年份II份Yl:1800W年倚￡2050,且為閏年Ml;.^10.12DI:1疼日期莖27Y2：ISDO-f|：陽2050.口為非國年M2;4,6,9JI()2:Y3;2000年M3:2D3:29W：30D5：31表34NextDate|^1題的導價類測試用例構成（弱組合形式｝測試用例ir>測試用例的等優(yōu)類構成001Y1MlDI(XI2Y2M2U2003Y3M3D3(K)4￥1MLD4(K)5Y2M2[)5表NextDate 的箒價類則試的測試用例〔弱組合形式）[D輸入數(shù)揣t年JMJ）操作歩驟預期輸出0012004-7-13輸入年月日■點擊"計算"?按刼2000-7-14II925-6-2S輸入年月日，點擊"計尊*按粗iy25^6-290032(J00-2-29輪入年月日?點擊按領2000-J-I2004-7-30輸入年月日.點擊“計算片按tn0051925-6-31輸入年月日.點由"計tew握示骨日期不存在”若采用強組合形式的等價類測試，則可得到45（3X3X5）個測試用例，具體的用例設計方法參見表 3.14不再一一列出。11、對于3.2.8節(jié)的Commission問題，請針對輸入域展開等價類測試。針對Commission問題，對輸入條件的上、下限構成的邊界范圍可自然形成一個有效等價類， 所以采用等價類測試，只有一個測試用例。等價類劃分見表3-6，測試用例見表3-7。表中預期輸岀是指銷售商的總提成。表3-6輸入域的等價類劃分（Commission問題）等階次 白衲銷售鼠 紅酒銷秒雖 啤油銷售童冇效普價*：門酒銷優(yōu)暈V5000K：紅灑稍讐址孑工000B：300^呻酒銷甘址乎：30000類表3-7輸入域的等價類測試用例（Commission問題）輸入數(shù)據(jù)（單位：融） 胡杵觀 旳期輸出ID 片灑鈉料Id 卽灑帝省乞 聊灑銷鴨顯 （單悅：元）｛單何土元）001 2525 15）5 150150 ld12、對于如下的槍支銷售問題（簡稱Sales問題），分別從輸入域和輸岀域著手，進行邊界值測試和等價類測試。Sales問題的簡單描述如下。某步槍銷售商負責銷售某軍火制造商生產的步槍，包括槍機 （Lock）、槍托（Stock）和槍管（Barrel）。其中槍機、槍托和槍管的單價分別為 45美元、30美元和25美元。銷售商每月至少應賣岀一支完整的步槍，同時，銷售商每月最多只允許銷售 70個槍機、80個槍托和90個槍管。該銷售商的提成每月結算一次。根據(jù)其銷售業(yè)績，制造商按如下計算方式來計算銷售商的提成。?銷售額不足（含）1000美元的部分，提成比例為10%。?銷售額在1000美元（不含）到1800美元（含）之間的部分，提成比例為 15%。?超過1800美元（不含）的部分，提成比例為20%。最終輸岀為當月銷售報告和銷售商的總提成。三個輸入條件為：槍機、槍托和槍管的銷售量。針對輸入域展開邊界值測試，則槍機的邊界點為 1和70，槍托邊界點為1和80，槍管邊界點為1和90?；具吔缰捣治龅臏y試用例集合見表3-8。針對輸出域展開邊界值測試，以銷售額為輸岀，得到測試用例集合見表 3-9。表中預期輸岀是指銷售商的總提成。表3-8Sales問題的邊界值測試的測試用例（針對輸入域）ID輸入數(shù)據(jù)（W：支）銷售額預期輸岀備注槍機銷優(yōu)彊槍托諸竹a槍甘銷警試tWi返元）￡單檢’美元）00114045237(1334槍機的迪界002240452,415⑷旳4U-+55,4309恥川口7040455,475955()05351452,730406槍托的邊界00635452,7604120073579455.07000S35K0455,imMKO0093540L2.800420槍腎的邊界mo35斗(I2tK2542S01135405.0008600123540905.025U&5表3-9Sales 問題的邊界值測試的補充測試用例（針對輸岀域）

ID輸入數(shù)據(jù)（單位：支）捎鈣觸（單位；美元〉預期輸出（單范1美元）備述槍機刪怙槍托銷理城槍許銷怙審013111KM910.(X1址低銷件屋014L010997597.5C1000R金的015LO10101.0001(K),00提成變化016]0HI111.025103,75017IXIK171.7752\(>.25|晰笑金的018181818220.00捉成變比0191SIK191.H25225.0002070鈾9U7,8001420.IM)最高銷售閾針對輸入域的等價類劃分見表 3-10。針對輸入域的等價類測試用例（強組合形式）見表3-11表3-10輸入域的等價類劃分（Sales問題）槍機銷化站槍售量槍管銷卩;適有效聲冊L:1W桁儒曲花70S:1銷害曲堂80B：鑰竹暈W90表3-11 輸入域的等價類測試用例 （Sales問題）ID-輸入數(shù)據(jù)L「卩妁：丈〕銷售孰預期輸出（小位￡美兀｝槍機銷竹垃槍托豬吿址槍管銷售量0013540453,900640針對輸岀域的等價類劃分見表 3-12，對應等價類測試用例見表 3-13。表3-12 輸岀域的等價類劃分（Sales問題，單位：美元）有效辱價類S1:100荃銷瞥額莖1000 S2：1000＜銷供額忑1特00 S3:1800＜銷低額￡為00備注 雖低tn住額 捉誡變化附點 皿高餡倂飆表3-13 輸岀域的等價類測試用例（Sales問題）ID輸入數(shù)期（甲薊：支）銷捧額C單位：忑元〕預期輸出C單仙芙元）備注槍托常售量槍管銷售量0226555455*1.50銷舊額在SI中023［00銷酋額在算中()24484S4X4SOO820.00銷魯額在常中13、 對3.5.6節(jié)的NextDate問題進行第一次決策表嘗試時，為何所得決策表中會輸出不確定的測試用例？該決策表中打問號的測試用例反映岀系統(tǒng)對輸入的不確定無法處理， 輸入的含義是：對于任意年份，月份是每月有31天的月份，日期是31號，這時存在一個年末日期的問題，對于 12月31日，系統(tǒng)輸出應為次年的1月1日，而對于其他月份（如7月31日），系統(tǒng)輸出應為下月1日（如8月1日），因此，系統(tǒng)無法針對相同的輸入等價類給岀明確的輸岀。這時應將月份的等價類進一步劃分下去。14、 請仿照NextDate問題，針對PrevDate問題使用邊界值、等價類和決策表方法展開測試。PrevDate問題中特殊的日期包括： 年初日（即每年的1月1日）、月初日（即每月1日）和閏年情況（即3月1日）。PrevDate問題包括三個輸入條件：年份、月份、日。邊界點分別為:

?年份：1800年，2050年?月份：1月，12月?日:1號，31號根據(jù)這些邊界點，使用基本邊界值分析方法進行邊界值測試，與 NextDate問題的分析方法完全相同,所以得到的測試用例也非常相似（輸入完全相同，預期輸出不同而已）等價類劃分如表3-14所示，得到決策表見表3-15，米用決策表得到的測試用例見表 3-16表3-14PrevDate問題的等價類劃分等價類 年份等價類 年份有效籌價莢 YliIKOO^年份W2D51LH為閏年 Ml:5,7.IOt12 DI:ID2:2W日期W28Y2:18M年份W205仇且為非闔年D2:2W日期W28M3:2M3:2M4：1MS：31)4:30D5:31MG：S表3-15PrevDate問題的決策表TC001fl()21X)3006007oos010Oil￡)12年笹在YI.Y2Y1.Y2YI,V2mYI.Y2YkY2Y1￥2Y1,Y2￥I,Y2Y1Y2月份袒MlMLM4-M6M1M3.M6M2M2M3M3M3M3M4M5M5Hfr：[)1D2-D3DID2-CM1)5D：D3J)3IM,D5DIDIDI口減| X X X「】為31"30日為29□為2S月黑1月為12年減I提示該口期不存枉表3-16PrevDate 問題的測試用例集合1D-輸入預期輸出年份刀份日0011925712000-6-3000219257162004-7J5tX)31925612004-5-3100419259162004^9-15t)O51925931提示紀該II期不存亦"00619252152004-2-14(M)72004292004-2-28OOS192529捉示“該日期不存護192531提示“該1丨期不存在”01019251119241231Oil2004312004-2-29()121925311925-2-28根據(jù)3.7.5節(jié)的規(guī)則（詳見本書光盤），檢查測試用例表3.24發(fā)現(xiàn)輸入條件“賬面余額”未取到“1”說明測試用例有漏洞，而表3.24中又顯示測試用例覆蓋了所有五個場景，為什么會出現(xiàn)這種相互矛盾的情況？是規(guī)則有錯，還是別的什么原因呢？對于備選流4的含義是：輸入金額校驗失敗， 這里有很多情況可以導致金額校驗失敗， 如輸入金額格式錯誤、賬面余額不足等，表3.24的測試用例ATM-ST-006的觸發(fā)事件是輸入金額格式錯誤的情況，而未測試賬面余額不足的情況，所以輸入條件“賬面余額”未取到“ I”。這里并不矛盾，因為表3.24中的第2列是從較粗的粒度來考查用例覆蓋的，而設計測試用例時若需要覆蓋備選流 4,卻需要從細節(jié)來考慮，所以出現(xiàn)了不一致的情況。第4章白盒測試技術1、 對于節(jié)中的函數(shù)FuncSC隨著三個布爾變量取值的不同，在特殊的取值組合條件下，程序的輸岀與輸入是不相等的。請問在什么條件下，該函數(shù)的輸岀不等于輸入 ？當函數(shù)FuncSC的第1和第2個布爾變量不同時取真值的時候，函數(shù)的輸岀不等于輸入。2、 對于節(jié)中的函數(shù)Func7，其代碼中隱含一個空間分配的缺陷，請找岀該缺陷。函數(shù)Func7中的缺陷在第3-5行代碼處，即當變量bFlag為假的時候，未對pArray分配空間，該指針為空，所以后續(xù)操作將失敗。3、節(jié)中，表4.3中取LC-003到LC-005中的任意一個與LC-002組合起來，都滿足判定覆蓋。請問，LC-003到LC-005這三個測試用例中，哪個測試效果相對更好 ？在同時滿足覆蓋指標的前提下， 應從判定表達式的屏蔽效應以及邊界值測試的角度判斷測試數(shù)據(jù)選擇的好壞。為執(zhí)行路徑L13,兩判定節(jié)點都應取假值，為了避免判斷表達式的屏蔽現(xiàn)象，必須保證 T1為真（即（a>1）為真），測試用例LC-004顯然不滿足該要求。另外，應保證 T4為假（即（x>3）為假），考慮到3是x取值的邊界，因此，應針對邊界值來選擇測試數(shù)據(jù)，所以 LC-005更優(yōu)于LC-003。總體看來LC-005是三個測試用例中最優(yōu)的一個。

4、425節(jié)中，按照函數(shù)Func6Modified將復雜邏輯表達式拆分為簡單的表達式之后，請設計兩個測試用例來滿足判定覆蓋。設計的測試用例見表4-1。表4-1函數(shù)Func6Modified的測試用例集合（滿足判定覆蓋）[D輸入國期輸出滿足的分支取值AbCXX0013l07TI=T2=T3=T4=Irie0021033T1T2-T3-T4lahe5、給定以下代碼，請利用邏輯覆蓋的各項覆蓋指標分別設計測試用例。boo)TestLogicCoveragefboola.boolb*boolc)boolx-fatse；if((a||b)&&c)x=true;elsex=false;returnx;表4-2表4-2真值表ID輸入條杵預期輸出Xabc001TTTT()02rTFF003TFTT004TFFF(K)5FTTT006FTFF007FFTF008卜F卜F列出真值表如表4-2所示。?對于語句覆蓋和判定覆蓋，選擇測試用例 005和006。?條件覆蓋，選擇測試用例 004和005。?判定/條件覆蓋，選擇測試用例 004和005。?條件組合覆蓋，選擇所有。?修正的判定/條件覆蓋，選擇測試用例003、005、006、007。6、當判定表達式具有三個簡單邏輯判斷條件時，所有可能構成的表達式形式如題表 4.1所示，請針對下表中的四種組合情況，分別采用修正的判定 /條件覆蓋指標設計測試用例。

題表4.1三個簡單邏輯判斷條件構成的所有可能的判定表達式ADCAAND(BANDC)AAND(BORC)AOR<BANDC)AOR(BORC)TTTTTTTTTFFTTTTFTFTTTTFFFFITFTTFFTTFTFFrFTFFTFFFTFFFKFFF根據(jù)題目中給岀的真值表，采用唯一原因法得到各條件的獨立影響對如表 4-3所示。因此得到滿足不同表達式的修正判定/條件覆蓋的測試用例集合分別見表 4-3。表4-3不同復合表達式的條件獨立影響對輸入家件ABc測試用例集合AAND(BANDC](1.5}(1,3)：lt2j1,2.3,5AANDfBURC)(2,6)(2.4)3,4)2r3*4.6AOR(BANDO(3.7)(玉了)5,6)3,5,氐7AOR(BORC^(<K)7.K)4t6.7,87、請針對擴展的TrgI問題展開基路徑測試。Trgl問題描述為：給定三角形的三條邊長，分別為ab和c,且邊長均為整數(shù)，要求根據(jù)三條邊長的關系輸岀：不構成三角形、不等邊三角形、等腰但不等邊三角形或等邊三角形，具體的程序代碼如下。voidExtcndcdTtiang1e(inta,intb,intc)boolblsTr^l*fklse；//若兩邊之和大于第三邊，則可以構成三角形’否則無法構成三角形遛(a+t3)>c&& &&(b+c)>a)blsTrgl=true；elseblsTfgl=false;if{blsTrgJ){//若構成三角形.則進一步判斷三角形的類型i^a!^b&&br=c)printf(勺=%也b-%dlc=^d：不等邊三角形\n舄a,b,cEeke邁pnb&&.a=c)Bprintf(怙=%山c=%d：零邊三弟形血雷42els?Hprintff“id,2>迢c-%d：等腰但不等邊三角形也二臥b5寺}els?//否則直接輸出’不枸成三角形print算**a=^%d,b=%(Lc=%d:不構成三角形a,b5c);考慮到不可行路徑，最終測試 4條路徑：Pathl：1,3,4,7,8,9,EndPath2:1,3,4,7,8,10,11,EndPath3:1,3,4,7,8,12,13,EndPath4:1,3,5,6,7,15,16,End得到測試用例見表4-4。且應考慮到輸入的各種組合，所以給岀了更多的測試用例。表4-4三角形問題測試用例集合[D輸入條件撤期輸出abC0013斗5不尊訕匕信形002354不等訕三餡形003453不零邊三舟時004333等邊三九彫005135等鰹隕不等邊二仰形006353等腰但不等邊三角圧007533等腰但不等邊三角形OOS123不構成三洞形009113不構成三角形&請針對以下的Commission代碼進行基路徑測試[蚊花Cdnnni9SHKiModify(intglcohol,uttrtdWinc,intbeer)(UalwhoLredWine和beer分別記最白種’紅藕和啤酒的月銷會■(單位舌瓶》intalcoEio1Price=16^；//白簷的單折intwdWiiiePrke=120;//紅酒的單的mtbcrrPrice-5;V啤酒的單價doublecommissioTi=QP0;/7記錄毎月提成intmcnthSales=alcoholPrice*alcohol+redWinePrice*redWine+beerPrice*beer;//記錄每月銷售額果銷售額低于20000元的部如按4%提成commission=monthSalcs+0,04;else訊monthSales<-^5000|//銷售額低于4丸00元的部分.按1%提成commission科(monthSaks-20000)*0,01+20000*0.04;else//銷售額高于知)00元的部分，按仍％提碰commission=(manthSales-45000)* +(45000-20000)*0,01+20000*004;priatfl；^alcoholredWine=%d,beer=%d,monthSalts=%dTcommission■W \nw,alcohol,TtdWmc,beer,monthSittBsionKBrewmcommission,}該CommissionModify函數(shù)只有3條路徑。若用A表示1,2,3,4,5號語句，則有Path1:A,6,7,12,13Path2:A,6,8,9,12,13Path3:A,6,10,11,12,13這其實已經等同于等價類測試+邊界值測試了。測試用例不再列岀。第5章面向對象軟件測試1、 所有類都需要進行單元測試嗎？并非所有類都需要進行單元測試，類的優(yōu)先級可從三方面來衡量：類在系統(tǒng)中所起的作用類自身的復雜度和與其他類之間的交互復雜度開發(fā)該類的測試程序所需的成本2、 私有方法可以測試嗎？私有方法可以測試，測試方法有：直接修改被測代碼的訪問權限在被測類中加入公有方法利用內類機制3、對于一個類而言，測試用例設計的一般策略是怎樣的 ？面向對象的單元測試一般策略：首先根據(jù)方法特性劃分：構造函數(shù)、功能函數(shù)和接口函數(shù)。針對構造函數(shù)，根據(jù)前置和后置條件設計用例。針對功能函數(shù)公有方法：基于前置條件和后置條件設計測試用例。受保護的方法：嚴格區(qū)分有訪問權限和無訪問權限的前置條件和后置條件，設計測試用例。私有方法：根據(jù)實際情況選用適當?shù)牟呗赃M行測試。針對接口函數(shù)，根據(jù)狀態(tài)轉換設計測試用例。對于以上每種情況，都應結合邊界值、等價類等測試方法來選擇測試數(shù)據(jù)。4、 將測試代碼直接寫在被測類的代碼中即可，對嗎 ？可以將測試代碼直接寫在被測類的代碼中，但這不利于開發(fā)代碼與測試代碼的分開，不 利于后續(xù)測試代碼的維護和開發(fā)產品的交付。5、抽象類無法實例化，所以不能測試，對嗎 ？抽象類雖然無法實例化，但可以通過以測試類的內類繼承方式來測試，是可以的。6、順序圖和協(xié)作圖可用作面向對象的單元測試，對嗎 ？順序圖和協(xié)作圖適用于面向對象的集成測試。第6章單元測試1、 良好的單元測試是否能夠代替集成測試？若每個模塊都經過了嚴格的單元測試，還需要集成測試。我們在測試過程中經常遇到的情況是：單元測試中每個模塊都能單獨工作，但將這些模塊集成在一起之后，某些模塊就不能正常工作了。例如，接口數(shù)據(jù)丟失，模塊之間的不良影響，誤差的不斷累積等。因此，單元測試無法代替集成測試，每個模塊的性能最優(yōu)并不能保證集成之后的指標達到最優(yōu)。2、 什么是驅動模塊？什么是樁模塊？為什么需要驅動模塊和樁模塊？驅動模塊是模擬被測單元的上級模塊，用于接收測試數(shù)據(jù)、啟動被測模塊和輸出結果。樁模塊是模擬被測單元所調用的模塊。測試時需要通過驅動模塊和樁模塊搭建單元測試環(huán)境。3、 單元測試的過程是怎樣的？單元測試的過程可劃分三個階段：計劃階段：完成單元測試計劃，制定單元測試策略。設計實現(xiàn)階段：建立單元測試環(huán)境，完成測試設計和開發(fā)。執(zhí)行評估階段：執(zhí)行單元測試用例，記錄和評估測試結果。4、 為第4章白盒測試中的Commission問題進行單元測試。5、 針對第3章的思考題14（PrevDate問題），寫出程序代碼，并進行單元測試。第7章集成測試1、 什么是集成測試？集成測試是在單元測試的基礎上，將所有已通過單元測試的模塊按照概要設計的要求組裝為子系統(tǒng)或系統(tǒng)，進行集成測試，目的是確保各單元模塊組合在一起后能夠按既定意圖協(xié)作運行，并確保增量的行為正確。2、 集成測試與單元測試的區(qū)別在哪里 ？與單元測試的區(qū)別：單元測試關注模塊內部，集成測試關注模塊接口；單元測試也關注模塊接口，但它從內部查看接口，從個數(shù)、屬性、量綱和順序等方面查看輸入的實參與形參的匹配情況。集成測試查看接口時主要關注穿越接口的數(shù)據(jù)、信息是否正確，是否會丟失。單元測試主要依據(jù)是詳細設計說明書，集成測試的主要依據(jù)是概要說明書。3、 集成測試與系統(tǒng)測試的區(qū)別在哪里 ？與系統(tǒng)測試的區(qū)別：集成測試僅針對軟件系統(tǒng)展開測試，系統(tǒng)測試中所涉及的系統(tǒng)則不僅包括被測試的軟件本身，還包括硬件及相關外圍設備。集成測試的主要依據(jù)是概要說明書，系統(tǒng)測試的主要依據(jù)是需求規(guī)格說明書及行業(yè)標準。4、 如何評價某種集成測試方法？集成測試策略的評價標準：測試用例的規(guī)模驅動模塊的設計樁模塊的設計缺陷定位的難易程度5、 成對集成與鄰居集成各自的思想是怎樣的 ？有何特點？成對集成基本思想：將每個集成測試用例限定在一對調用單元上。特點是仍需要開發(fā)樁模塊和驅動模塊。鄰居集成基本思想：將每個集成測試用例限定在某個節(jié)點的鄰居（直接調用或被調用的模塊）上。特點是：可以減少樁模塊和驅動模塊的開發(fā)工作量，但缺陷定位困難。6、 請比較大爆炸集成、自頂向下、自底向上和三明治集成策略。大爆炸集成基本思想：將所有經過單元測試的模塊一次性組裝到被測系統(tǒng)中進行測試，完全不考慮模塊之間的依賴性和可能的風險。自頂向下集成的基本思想：從主控模塊（主程序，即根節(jié)點）開始，按照系統(tǒng)程序結構，沿著控制層次從上而下，逐漸將各模塊組裝起來。自底向上集成的基本思想：從最底層模塊（即葉子節(jié)點）開始，按照調用圖的結構，從下而上，逐層將各模塊組裝起來。三明治集成的基本思想：策略1:將系統(tǒng)劃分為三層，中間層為目標層，測試時對目標層上面的層使用自頂向下的集成策略，對目標層下面的層使用自底向上的集成策略。策略2:在第1種集成策略的基礎上，對目標層采用獨立測試的策略，以確保目標層模塊在集成測試之前得到充分的測試。策略3:對包含讀操作（系統(tǒng)輸入）的子系統(tǒng)自底向上集成測試直至根節(jié)點，然后對包含寫操作（系統(tǒng)輸出）的子系統(tǒng)自頂向下集成測試直至葉子節(jié)點。7、集成測試的一般過程是怎樣的，與單元測試的過程有何區(qū)別 ？集成測試的過程可劃分三個階段：計劃階段：完成集成測試計劃，制定集成測試策略。設計實現(xiàn)階段：建立集成測試環(huán)境，完成測試設計和開發(fā)。執(zhí)行評估階段：執(zhí)行集成測試用例，記錄和評估測試結果。單元測試的過程可劃分三個階段：計劃階段：完成單元測試計劃，制定單元測試策略。設計實現(xiàn)階段：建立單元測試環(huán)境，完成測試設計和開發(fā)。執(zhí)行評估階段：執(zhí)行單元測試用例，記錄和評估測試結果。第8章系統(tǒng)測試1、 系統(tǒng)測試與單元測試和集成測試的區(qū)別是什么 ？系統(tǒng)測試的最終目的是保證開發(fā)方交付給用戶的軟件產品能夠滿足用戶的需求，因此，測試的測試用例應在實際的用戶使用環(huán)境下來執(zhí)行，系統(tǒng)測試是涉及軟件、硬件、網(wǎng)絡方面因素的過程。這是系統(tǒng)測試與集成測試、單元測試最大的不同之處。2、 功能測試與界面測試有何區(qū)別？界面測試應與功能測試區(qū)分開來，界面測試中不應涉及具體的邏輯功能實現(xiàn)，只是關于布局、字體、風格等有關界面上的一些問題。且在界面測試過程中，我們可以通過創(chuàng)建界面測試檢查單的方式來簡化測試用例，簡化測試過程。3、 請為某圖書館信息管理系統(tǒng)設計功能測試策略。功能測試的策略因不同類型系統(tǒng)差異較大。圖書館信息管理系統(tǒng)是一個以數(shù)據(jù)為中心的系統(tǒng)，可以從兩個方面考慮展開功能測試，即從實體關系模型來考慮和從對數(shù)據(jù)的操作來考慮。從實體關系模型來考慮，檢查實體之間的對應關系和邏輯關系，包括1對1、1對多、多對1、多對多；從對數(shù)據(jù)的操作來考慮，檢查各種操作是否能正常實現(xiàn)，包括增加、刪除、查找、修改。4、 請為從ATM機系統(tǒng)設計功能測試策略。以活動序列為中心的系統(tǒng)可基于以下策略進行功能測試： 基于系統(tǒng)輸入的測試用例設計、基于系統(tǒng)輸出的測試用例設計、基于系統(tǒng)狀態(tài)的測試用例設計、基于系統(tǒng)事件的測試用例設計。5、 壓力測試和負載測試有何區(qū)別？壓力測試指持續(xù)不斷地給被測系統(tǒng)增加壓力， 直到被測系統(tǒng)被壓垮，從而確定系統(tǒng)能承受的最大壓力。（強調施加壓力的大?。┴撦d測試指讓被測系統(tǒng)在其能忍受的壓力極限范圍內（或臨界狀態(tài)下）連續(xù)運行，來測試系統(tǒng)的穩(wěn)定性。（側重壓力持續(xù)的時間）6、 兼容性測試需要考慮哪幾方面的內容 ？兼容性測試的內容包括與硬件兼容、與其他軟件平臺和應用程序兼容、數(shù)據(jù)共享。7、 安裝軟件的一般流程是怎樣的？執(zhí)行啟動程序結束安裝第9章測試用例的組織和管理1、 測試用例為什么需要管理？因為測試用例是軟件測試的核心和本質，它需要具有組織性、重復性、跟蹤性、客觀性，良好的測試用例管理和跟蹤是良好測試質量的保障。2、 測試用例有幾種形式的模板？各有什么特點？嚴格來講，有無數(shù)多種形式的模板，任何公司都將根據(jù)自己的實際情況來確定測試用例模板。 如WordExcel、IEEE829標準和BugFree工具模板。3、 如何劃分測試用例的優(yōu)先級？在大部分情況下，可能發(fā)現(xiàn)的缺陷的嚴重性越高，對應的測試用例就越重要，其優(yōu)先級也越高。根據(jù)這一假設，我們可將測試用例分為四個基本等級。冒煙測試：在正式測試之前進行的測試工作， 冒煙測試中選擇的測試用例能測試到被測軟件的核心功能或新增功能。高：最常執(zhí)行的測試用例集合，這些測試用例可以保證功能穩(wěn)定，系統(tǒng)可以正常工作，并包含對重要邊界的測試。中：一般需要執(zhí)行的測試用例集合，這些測試用例可使得功能區(qū)域或功能更加詳細。低：通常最少執(zhí)行的測試用例。低優(yōu)先級并非意味著這些測試不重要，只是這些用例在項目生存周期內并非反復地運行而已，例如用戶界面、錯誤提示信息、性能測試等。這四個等級可以作為測試用例的初始優(yōu)先級， 之后基于質量目標和項目需求再對初始優(yōu)先級進行提升或降級。4、測試用例組織和管理的一般步驟是怎樣的 ？基本步驟：整理模塊需求撰寫測試計劃設計測試思路編寫測試用例評審測試用例（內部和外部評審）修改更新測試用例（給出變更記錄或版本升級）執(zhí)行測試用例分析評估測試用例質量，包括測試用例的設計質量、測試用例的執(zhí)行情況。5、測試用例的評審有幾種形式有效的測試用例評審一般分為兩種形式：測試部門內部的評審、測試部門外部的評審。6、測試用例應寫得越詳細越好，是這樣嗎 ？測試用例設計并非越詳細越好。測試用例的執(zhí)行人員是測試用例的設計者， 或對被測軟件非常熟悉，則測試用例不必描述太詳細；測試用例的執(zhí)行人員是剛入公司的新人，或將測試外包給第三方，則測試用例的描述應盡量詳細；設計測試用例時，應關注核心功能、高風險功能，且應滿足合理的覆蓋指標。