1.測試與軟件模型

軟件開發(fā)生命周期模型指的是軟件開發(fā)全過程萄唇、活動和任務的結構性框架。軟件項目的開發(fā)包括：需求术幔、設計另萤、編碼、測試诅挑、穩(wěn)定四敞、部署、維護等階段拔妥。

常見的軟件開發(fā)模型有瀑布模型忿危、迭代開發(fā)、螺旋開發(fā)和敏捷開發(fā)没龙。

1.1 瀑布模型

瀑布模型式是最典型的預見性的方法癌蚁，嚴格遵循預先計劃的需求分析、設計兜畸、編碼努释、集成、測試咬摇、維護的步驟順序進行伐蒂。步驟成果作為衡量進度的方法，例如需求規(guī)格肛鹏，設計文檔逸邦，測試計劃和代碼審閱等等。瀑布式的主要有以下問題：

• 各個階段的劃分完全固定在扰，階段之間產生大量的文檔缕减，極大地增加了工作量；
• 由于開發(fā)模型是線性的芒珠，用戶只有等到整個過程的末期才能見到開發(fā)成果桥狡，從而增加了開發(fā)的風險；
• 早期的錯誤可能要等到開發(fā)后期的測試階段才能發(fā)現皱卓，進而帶來嚴重的后果裹芝。

因此，瀑布式方法在需求不明并且在項目進行過程中可能變化的情況下基本是不可行的娜汁。

1.2 迭代開發(fā)模型

迭代式開發(fā)是一種與傳統(tǒng)的瀑布式開發(fā)相反的軟件開發(fā)過程嫂易，具有更高的成功率和生產率。在迭代開發(fā)中掐禁，整個開發(fā)工作被組織為一系列的短小的怜械、固定長度（如3周）的小項目颅和，逐步逐步的完成，故為迭代缕允。每一次迭代都包括需求分析融虽、設計、實現與測試灼芭。采用這種方法有额，開發(fā)工作可以在需求被完整地確定之前啟動，并在一次迭代中完成系統(tǒng)的一部分功能或業(yè)務邏輯的開發(fā)工作彼绷。再通過客戶的反饋來細化需求巍佑，并開始新一輪的迭代。迭代開發(fā)具有以下優(yōu)點：

• 降低風險寄悯。如果開發(fā)人員重復某個迭代萤衰，那么損失只是這一個開發(fā)有誤的迭代的花費。
• 適應需求變更猜旬。由于用戶的需求并不能在一開始就作出完全的界定脆栋，它們通常是在后續(xù)階段中不斷細化的。
• 持續(xù)的測試與集成洒擦，降低后期的工作量與風險椿争。

1.3 螺旋開發(fā)模型

螺旋開發(fā)，將瀑布模型和快速原型模型結合起來熟嫩，強調了其他模型所忽視的風險分析秦踪，特別適合于大型復雜的系統(tǒng)〉“螺旋模型”剛開始規(guī)模很小椅邓，當項目被定義得更好、更穩(wěn)定時昧狮，逐漸展開景馁。 “螺旋模型”的核心就在于不需要在剛開始的時候就把所有事情都定義的清清楚楚。您輕松上陣逗鸣，定義最重要的功能合住，實現它，然后聽取客戶的意見慕购，之后再進入到下一個階段聊疲。如此不斷輪回重復茬底，直到得到您滿意的最終產品沪悲。 螺旋開發(fā)分為以下四個階段：

• 制定計劃：確定軟件目標，選定實施方案阱表，弄清項目開發(fā)的限制條件殿如；
• 風險分析：分析評估所選方案贡珊，考慮如何識別和消除風險；
• 實施工程：實施軟件開發(fā)和驗證涉馁；
• 客戶評估：評價開發(fā)工作门岔，提出修正建議，制定下一步計劃烤送。

一個階段首先是確定該階段的目標寒随，完成這些目標的選擇方案及其約束條件，然后從風險角度分析方案的開發(fā)策略帮坚，努力排除各種潛在的風險妻往，有時需要通過建 造原型來完成。如果某些風險不能排除试和，該方案立即終止讯泣，否則啟動下一個開發(fā)步驟。最后阅悍，評價該階段的結果好渠，并設計下一個階段。

1.4 敏捷開發(fā)模型

敏捷開發(fā)节视，是一種從1990年代開始逐漸引起廣泛關注的一些新型軟件開發(fā)方法拳锚，是一種應對快速變化的需求的一種軟件開發(fā)能力。相對于“非敏捷”寻行，更強調程序員團隊與業(yè)務專家之間的緊密協(xié)作晌畅、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟件版本寡痰、緊湊而自我組織型的團隊抗楔、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發(fā)中人的作用拦坠。

• 個體和互動重于流程和工具连躏。
• 可工作的軟件重于求全而完備的文檔。
• 客戶協(xié)作重于合同談判贞滨。
• 應對變化重于遵循計劃入热。

其中位于右邊的內容雖然也有其價值，但是左邊的內容最為重要晓铆。人員彼此信任勺良，人少但是精干，可以面對面的溝通骄噪。

敏捷開發(fā)小組主要的工作方式可以歸納為：作為一個整體工作尚困；按短迭代周期工作；每次迭代交付一些成果链蕊；關注業(yè)務優(yōu)先事甜；檢查與調整谬泌。

最重要的因素恐怕是項目的規(guī)模。規(guī)模增長逻谦，面對面的溝通就愈加困難掌实，因此敏捷方法更適用于較小的隊伍，40邦马、30贱鼻、20、10人或者更少滋将。

1.5 四種模型比較

傳統(tǒng)的瀑布式開發(fā)忱嘹，也就是從需求到設計，從設計到編碼耕渴，從編碼到測試拘悦，從測試到提交大概這樣的流程，要求每一個開發(fā)階段都要做到最好橱脸。特別是前期階段础米，設計的越完美，提交后的成本損失就越少添诉。

迭代式開發(fā)屁桑，不要求每一個階段的任務做的都是最完美的，而是明明知道還有很多不足的地方栏赴，卻偏偏不去完善它蘑斧，而是把主要功能先搭建起來為目的，以最短的時間须眷，最少的損失先完成一個“不完美的成果物”直至提交竖瘾。然后再通過客戶或用戶的反饋信息，在這個“不完美的成果物”上逐步進行完善花颗。

螺旋開發(fā)捕传，很大程度上是一種風險驅動的方法體系，因為在每個階段之前及經常發(fā)生的循環(huán)之前扩劝，都必須首先進行風險評估庸论。

敏捷開發(fā)，相比迭代式開發(fā)兩者都強調在較短的開發(fā)周期提交軟件棒呛，但是聂示，敏捷開發(fā)的周期可能更短，并且更加強調隊伍中的高度協(xié)作簇秒。敏捷方法有時候被誤認為是無計劃性和紀律性的方法鱼喉，實際上更確切的說法是敏捷方法強調適應性而非預見性。

適應性的方法集中在快速適應現實的變化。當項目的需求起了變化蒲凶，團隊應該迅速適應气筋。這個團隊可能很難確切描述未來將會如何變化拆内。

1.6 軟件開發(fā)過程中的測試

在前面介紹的軟件開發(fā)過程中旋圆，測試都是一個重要的組成部分。尤其對于中大型項目麸恍，從項目開始指出就要制定測試計劃灵巧、對需求進行測試、設計測試和測試用例抹沪、執(zhí)行測試刻肄，最后對測試的結果進行總結和分析。軟件缺陷發(fā)現得越早融欧，修復軟件缺陷所需的代價越小敏弃。

TDD（測試驅動開發(fā)）的思路就是通過測試推動整個開發(fā)的進行，開發(fā)代碼之前噪馏，先編寫測試代碼麦到。在明確要開發(fā)某個功能后，首先思考如何對這個功能進行測試欠肾，并完成測試代碼的編寫瓶颠，然后編寫相關的代碼滿足這些測試用例。并且刺桃，軟件測試的活動貫穿整個軟件開發(fā)生命周期的始終粹淋。

1.7 軟件測試的目的與原則

測試的定義：使用人工或自動手段來運行或測定某個系統(tǒng)的過程，其目的在于檢查它是否滿足規(guī)定的需求或是弄清預期結果與實際結果之間的差別瑟慈。

軟件測試的目的：發(fā)現程序中的錯誤桃移，保證軟件產品的最終質量。

• 測試是程序的執(zhí)行過程葛碧，目的在于發(fā)現錯誤
• 一個成功的測試用例在于發(fā)現至今未發(fā)現的錯誤
• 一個成功的測試是發(fā)現了至今未發(fā)現的錯誤的測試
• 確保產品完成了它所承諾或公布的功能谴轮，并且用戶可以訪問到的功能都有明確的書面說明。
• 確保產品滿足性能和效率的要求
• 確保產品是健壯的和適應用戶環(huán)境的

軟件測試的原則：

• 測試用例中一個必須部分是對預期輸出或接口進行定義
• 程序員應避免測試自己編寫的程序
• 編寫軟件的組織不應當測試自己編寫的軟件
• 應當徹底檢查每個測試的執(zhí)行結果
• 測試用例的編寫不僅應當根據有效和預料到的輸入情況吹埠，而且也應當根據無效和未預料到的輸入情況
• 檢查程序是否“未做其應該做的”僅是測試的一半第步，測試的另一半是檢查程序是否“做了其不應該做的”
• 應避免測試用例用后即棄，除非軟件本身就是個一次性的軟件
• 計劃測試工作時不應默許假定不會發(fā)現錯誤
• 程序某部分存在更多錯誤的可能性缘琅，與該部分已經發(fā)現錯誤的數量成正比

1.8 軟件的可測性

軟件的可測性太差會導致測試的難度相當大粘都，甚至無法測試。這種情況往往是由于極差的軟件架構設計和極為不規(guī)范的軟件開發(fā)工作導致的刷袍。

• 緊耦合翩隧。不把大半個系統(tǒng)實例化就無法測試。
• 弱內聚呻纹。這個類實現了太多功能堆生，導致測試非常復雜专缠。
• 冗余。同一個方法在多處使用淑仆，每一處都得測涝婉。

好的軟件架構應該是松耦合、高內聚的蔗怠。提高軟件的測試性的同時也提高了軟件的可維護性和可管理性墩弯。

2. 測試用例設計

測試用例是為特定的目的而設計的一組測試輸入、執(zhí)行條件和預期的結果寞射。測試用例是執(zhí)行的最小實體渔工。簡單地說，測試用例就是設計一個場景桥温，使軟件程序在這種場景下引矩，必須能夠正常運行并且達到程序所設計的執(zhí)行結果。

2.1 黑盒測試與白盒測試

黑盒測試：已知產品的功能設計規(guī)格侵浸，可以進行測試證明每個實現了的功能是否符合要求旺韭。白盒測試：已知產品的內部工作過程，可以進行測試證明每種內部操作是否符合設計規(guī)格要求通惫，所有內部成分是否經過檢查茂翔。

合理的測試策略是將這兩種測試要素組合起來蝙场。我們可以通過使用特定的面向黑盒測試的測試用例設計方法勇皇，而后使用白盒測試方法對程序的邏輯結構進行檢查以補充這些測試用例谋旦，借此來設計出一個相當嚴格的測試廉涕。

白盒測試方法有語句覆蓋龙屉、判定覆蓋泳桦、條件覆蓋澈侠、判定/條件覆蓋桥言、條件組合覆蓋延旧、路徑覆蓋谋国。黑盒測試方法有等價類劃分、邊界值分析迁沫、因果圖分析芦瘾、錯誤測試、狀態(tài)圖集畅、場景法等近弟。

2.2 白盒測試用例設計

白盒測試關注的是測試用例執(zhí)行的程度或覆蓋程序邏輯結構（源代碼）的程度。完全的白盒測試是將程序中每條路徑都執(zhí)行到挺智，然而對一個帶有循環(huán)的程序來說祷愉，完全的路徑測試并不切合實際。白盒測試的特點：依據軟件設計說明書進行測試、對程序內部細節(jié)的嚴密檢驗二鳄、針對特定條件設計測試用例赴涵、對軟件的邏輯路徑進行覆蓋測試。

語句覆蓋是最起碼的結構覆蓋要求订讼，語句覆蓋要求設計足夠多的測試用例髓窜，使得程序中每條語句至少被執(zhí)行一次∏担可以很直觀地從源代碼得到測試用例纱烘，無須細分每條判定表達式杨拐。由于這種測試方法僅僅針對程序邏輯中顯式存在的語句祈餐，但對于隱藏的條件和可能到達的隱式邏輯分支，是無法測試的哄陶。（遺漏隱藏的邏輯分支）

判定覆蓋要求必須編寫足夠的測試用例帆阳，使得每一個判斷都至少有一個為“真”和為“假”的輸出結果。判定覆蓋比語句覆蓋要多幾乎一倍的測試路徑屋吨，當然也就具有比語句覆蓋更強的測試能力蜒谤。同樣判定覆蓋也具有和語句覆蓋一樣的簡單性，無須細分每個判定就可以得到測試用例至扰。往往大部分的判定語句是由多個邏輯條件組合而成（如鳍徽，判定語句中包含AND、OR敢课、CASE）阶祭，若僅僅判斷其整個最終結果，而忽略每個條件的取值情況直秆，必然會遺漏部分測試路徑濒募。（遺漏組合判定中的某些條件取值）

條件覆蓋要求設計足夠多的測試用例，使得判定中的每個條件獲得各種可能的結果圾结，即每個條件至少有一次為真值瑰剃，有一次為假值。要達到條件覆蓋筝野，需要足夠多的測試用例晌姚，但條件覆蓋并不能保證判定覆蓋。條件覆蓋只能保證每個條件至少有一次為真歇竟，而不考慮所有的判定結果挥唠。

判定/條件覆蓋要求設計足夠多的測試用例，使得判定中每個條件的所有可能結果至少出現一次途蒋，每個判定本身所有可能結果也至少出現一次猛遍。判定/條件覆蓋滿足判定覆蓋準則和條件覆蓋準則，彌補了二者的不足。判定/條件覆蓋準則的缺點是未考慮條件的組合情況懊烤。

多重條件覆蓋要求設計足夠多的測試用例梯醒，使得每個判定中條件結果的所有可能組合至少出現一次。多重條件覆蓋準則滿足判定覆蓋腌紧、條件覆蓋和判定/條件覆蓋準則茸习。更改的判定/條件覆蓋要求設計足夠多的測試用例，使得判定中每個條件的所有可能結果至少出現一次壁肋，每個判定本身的所有可能結果也至少出現一次号胚。并且每個條件都顯示能單獨影響判定結果。缺點是線性地增加了測試用例的數量浸遗。

路徑覆蓋要求設計足夠的測試用例猫胁，覆蓋程序中所有可能的路徑。由于路徑覆蓋需要對所有可能的路徑進行測試（包括循環(huán)跛锌、條件組合弃秆、分支選擇等），那么需要設計大量髓帽、復雜的測試用例菠赚，使得工作量呈指數級增長。而在有些情況下郑藏，一些執(zhí)行路徑是不可能被執(zhí)行的衡查，這樣不僅降低了測試效率，而且大量的測試結果的累積必盖，也為排錯帶來麻煩拌牲。

2.3 黑盒測試用例設計

2.3.1 等價類劃分

等價類劃分是把所有可能的輸入數據,即程序的輸入域劃分成若干部分（子集）,然后從每一個子集中選取少數具有代表性的數據作為測試用例。等價類分為有效等價類和無效等價類筑悴，其中们拙，有效等價類是指對于程序的規(guī)格說明來說是合理的，有意義的輸入數據構成的集合阁吝；而無效等價類是指對于程序的規(guī)格說明來說是不合理的砚婆，沒有意義的輸入數據構成的集合。設計測試用例時,要同時考慮這兩種等價類突勇。因為軟件不僅要能接收合理的數據,也要能經受意外的考驗装盯，這樣的測試才能確保軟件具有更高的可靠性。劃分等價類有以下原則：

• 在輸入條件規(guī)定了取值范圍或值的個數的情況下,則可以確立一個有效等價類和兩個無效等價類甲馋。如：輸入值是學生成績埂奈，范圍是0～100；則小于0和大于100的為無效等價類定躏，0~100之間的為有效等價類账磺。
• 在輸入條件規(guī)定了輸入值的集合或者規(guī)定了"必須如何"的條件的情況下芹敌，可確立一個有效等價類和一個無效等價類。
• 在輸入條件是一個布爾量的情況下,可確定一個有效等價類和一個無效等價類垮抗。
• 在規(guī)定了輸入數據的一組值（假定n個）,并且程序要對每一個輸入值分別處理的情況下,可確立n個有效等價類和一個無效等價類氏捞。例：輸入條件說明學歷可為:專科冒版、本科液茎、碩士、博士四種之一辞嗡，則分別取這四種這四個值作為四個有效等價類捆等，另外把四種學歷之外的任何學歷作為無效等價類。
• 在規(guī)定了輸入數據必須遵守的規(guī)則的情況下,可確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同角度違反規(guī)則）续室；
• 在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下,則應再將該等價類進一步的劃分為更小的等價類栋烤。

在確立了等價類后,可建立等價類表,列出所有劃分出的等價類輸入條件：有效等價類、無效等價類猎贴，然后從劃分出的等價類中按以下三個原則設計測試用例：

1. 為每一個等價類規(guī)定一個唯一的編號班缎；
2. 設計一個新的測試用例,使其盡可能多地覆蓋尚未被覆蓋地有效等價類,重復這一步蝴光，直到所有的有效等價類都被覆蓋為止她渴；
3. 設計一個新的測試用例,使其僅覆蓋一個尚未被覆蓋的無效等價類,重復這一步，直到所有的無效等價類都被覆蓋為止蔑祟。

2.3.2 邊界值分析

邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法趁耗。通常邊界值分析法是作為對等價類劃分法的補充，這種情況下疆虚，其測試用例來自等價類的邊界苛败。邊界值分析不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件径簿。邊界值分析不僅考慮輸入條件罢屈，還要考慮輸出空間產生的測試情況。

長期的測試工作經驗告訴我們篇亭，大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上缠捌，而不是發(fā)生在輸入輸出范圍的內部。因此針對各種邊界情況設計測試用例译蒂，可以查出更多的錯誤曼月。使用邊界值分析方法設計測試用例，首先應確定邊界情況柔昼。通常輸入和輸出等價類的邊界哑芹，就是應著重測試的邊界情況。應當選取正好等于捕透，剛剛大于或剛剛小于邊界的值作為測試數據聪姿，而不是選取等價類中的典型值或任意值作為測試數據碴萧。

2.3.3 因果圖

因果圖是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法末购，它適合于檢查程序輸入條件的各種組合情況勿决。

等價類劃分法和邊界值分析方法都是著重考慮輸入條件，但沒有考慮輸入條件的各種組合招盲、輸入條件之間的相互制約關系低缩。這樣雖然各種輸入條件可能出錯的情況已經測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了曹货。如果在測試時必須考慮輸入條件的各種組合咆繁，則可能的組合數目將是天文數字，因此必須考慮采用一種適合于描述多種條件的組合顶籽、相應產生多個動作的形式來進行測試用例的設計玩般，這就需要利用因果圖（邏輯模型）。

2.3.4 錯誤測試

錯誤測試是基于經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法礼饱。

如測試一個對線性表（比如數組）進行排序的程序坏为，可推測列出以下幾項需要特別測試的情況：

1. 輸入的線性表為空表；
2. 表中只含有一個元素镊绪；
3. 輸入表中所有元素已排好序匀伏；
4. 輸入表已按逆序排好；
5. 輸入表中部分或全部元素相同蝴韭。

2.4 測試用例設計綜合策略

Myers提出了使用各種測試方法的綜合策略：

1. 在任何情況下都必須使用邊界值分析方法够颠，經驗表明用這種方法設計出測試用例發(fā)現程序錯誤的能力最強。
2. 必要時用等價類劃分方法補充一些測試用例榄鉴。
3. 用錯誤推測法再追加一些測試用例履磨。
4. 對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度庆尘，如果沒有達到要求的覆蓋標準剃诅，應當再補充足夠的測試用例。
5. 如果程序的功能說明中含有輸入條件的組合情況驶忌，則一開始就可選用因果圖法矛辕。

測試用例的設計步驟：1)構造根據設計規(guī)格得出的基本功能測試用例；2)邊界值測試用例位岔；3)狀態(tài)轉換測試用例如筛；4)錯誤猜測測試用例；5)異常測試用例抒抬；6)性能測試用例杨刨；7)壓力測試用例。

3. 軟件測試類型

單元測試

單元測試并不是對整個程序進行測試擦剑，而是對構成程序的較小模塊進行測試妖胀。單元測試減小了調試的難度（一旦某個錯誤被發(fā)現出來芥颈，我們就知道它在哪個具體的模塊中）；單元測試提供了同時測試多個模塊的可能赚抡，將并行工程引入軟件測試中爬坑。

在為模塊單元測試設計測試用例時，需要使用兩種類型的信息：模塊的規(guī)格說明和模塊的源代碼涂臣。規(guī)格說明一般都規(guī)定了模塊的輸入和輸出參數以及模塊的功能盾计。單元測試總體上是面向白盒測試的，因此赁遗，單元測試的測試用例的設計過程如下：使用一種或多種白盒測試方法分析模塊的邏輯結構署辉，然后使用黑盒測試方法對照模塊的規(guī)格說明以補充測試用例。

集成測試

自頂向下集成和自底向上集成

功能測試

功能測試的目的是為了暴露程序的錯誤以及與規(guī)格說明不一致之處岩四，而不是為了證明程序符合其外部規(guī)格說明哭尝。

功能測試是一種黑盒測試，功能測試常用步驟有：根據需求來細分功能點剖煌，根據功能點派生測試需求材鹦，根據測試需求設計功能測試用例。

系統(tǒng)測試

系統(tǒng)測試的目的是為了證明程序不能實現其目標耕姊，系統(tǒng)測試的測試用例設計有以下14種類型：

1. 能力測試：是判斷目標文檔提及的每一項能力（或功能）是否都確實已經實現桶唐。
2. 容量測試：使程序經受大容量數據的檢驗。容量測試的目的是為了證明程序不能處理目標文檔中規(guī)定的數據容量箩做。
3. 強度測試：使程序承受高負載或強度的檢驗莽红。所謂高強度是指在很短的時間間隔內達到的數據或操作的數量峰值。
4. 易用性測試：試圖發(fā)現人為因素或易用性的問題邦邦。
5. 安全性測試：設計測試用例來突破程序安全檢查的過程。舉例來說醉蚁，我們可以設計測試用例來規(guī)避操作系統(tǒng)的內存保護機制燃辖，破壞數據庫管理系統(tǒng)的數據安全機制。
6. 性能測試：很多軟件都有特定的性能或效率目標网棍，這終特性描述為在特定負載和配置環(huán)境下程序的響應時間和吞吐率黔龟。
7. 存儲測試：
8. 配置測試：
9. 兼容性測試。
10. 安裝測試：有些類型的軟件系統(tǒng)安裝過程非常復雜滥玷，測試安裝過程是系統(tǒng)測試中的一個重要部分氏身。對于包含在軟件包中的自動安裝系統(tǒng)而言，這尤其重要惑畴。安裝程序如果出現故障蛋欣，會影響用戶對軟件的成功體驗。
11. 可靠性測試：所有類型的測試都是為了提高軟件的可靠性如贷，但是如果軟件的目標中包含了對可靠性的特別描述陷虎，就必須設計專門的可靠性測試到踏。
12. 可恢復性測試：諸如操作系統(tǒng)、數據庫管理系統(tǒng)和遠程處理系統(tǒng)等軟件通常都有可恢復性目標尚猿，說明系統(tǒng)如何從程序錯誤窝稿、硬件失效和數據錯誤中恢復過來。系統(tǒng)測試的一個目標是證明這些恢復機制不能夠正確發(fā)揮作用凿掂。我們可以故意將程序錯誤置入某個系統(tǒng)中伴榔，判斷系統(tǒng)是否可以從中恢復。
13. 適用性測試
14. 文檔測試：檢查用戶文檔的正確性庄萎。用戶文檔應成為審查的對象潮梯，檢查其正確性和清晰性。在文檔中描述的任何范例應編成測試用例惨恭，并提交給程序秉馏。

4. 自動化測試

自動化測試：以程序測試程序、以代碼代替思維脱羡、以腳本運行代替手工測試萝究。

冒煙測試:就是在一個新版本出來的時候，將軟件的全部功能過一遍锉罐，看有沒有什么大問題帆竹。如果功能可以正常運行，不會影響測試進行脓规，那么這個版本就可以真正開始測試了栽连。如果功能有重大問題或影響測試進行，那么這個版本就是不合格的侨舆，不用進行進一步的測試秒紧。比如，拿到QQ的app新版本挨下，登陸都登陸不上熔恢，那么這個版本肯定無法繼續(xù)測下去〕舭剩或者叙淌，游戲中新的模塊出現，但是新的模塊總是崩潰愁铺、卡死鹰霍，測試進行不下去，那么冒煙的結果就是不合格的茵乱。

回歸測試:就是以前版本中發(fā)現的bug在新的版本中驗證是否存在且是否引發(fā)新的bug茂洒。

4.1 自動化測試的優(yōu)勢

• 回歸測試更方便、可靠似将。由于回歸測試的業(yè)務流程操作和測試用例是預先設計好的获黔，預期結果也是完全在項目人員掌握之中的蚀苛，將回歸測試交給計算機自動運行，可以極大提高測試效率玷氏，縮短回歸測試時間堵未。
• 可運行更多更繁瑣的測試，且快速高效盏触。
• 可執(zhí)行一些對于手工測試來說相當困難或根本做不到的測試渗蟹。比如，對大量用戶的并發(fā)測試等赞辩。
• 具有一致性和可重復性的特點雌芽。
• 自動化測試腳本完全具有復用性。由于自動化測試通常以腳本的方式實現辨嗽，這樣在不同的版本之間世落，就可能只需要做少量的維護甚至不做任何修改，實現在不同的測試版本中使用相同的測試腳本執(zhí)行相同的測試用例糟需。

4.2 自動化測試的劣勢

• 永遠不可能完全取代手工測試屉佳。自動化測試無法做到手工測試的覆蓋率，不是每個測試用例都適合轉換成自動化測試用例的洲押。
• 無法保證測試的正確性武花。測試腳本本身也可能存在缺陷。
• 手工測試能發(fā)現的缺陷遠比自動化測試多杈帐。自動化測試幾乎是無法發(fā)現新缺陷体箕。
• 自動化測試工具是死的，它本身沒有任何想象力挑童。
• 自動化測試對測試工程師來說必須有一定的開發(fā)技術背景累铅。

4.3 引入自動化測試的時機

• 項目周期長，系統(tǒng)版本不斷炮沐。主要在于回歸測試争群。
• 需求變更不頻繁。
• 系統(tǒng)中的測試對象基本可以正常識別大年，不存在大批量第三方控件。
• 需要反復測試玉雾，如可靠性測試需要進行上千次的系統(tǒng)測試翔试。

4.4 何時避免展開自動化測試

• 項目周期短，需求變更頻繁复旬。項目周期短的情況下引入自動化測試垦缅，不但收不回成本鹃共，而且會延長產品的發(fā)布時間蹈丸。需求頻繁改變會使老功能的業(yè)務邏輯被修改柳琢，從而導致相應的測試腳本也需相應修改山林。
• 軟件版本還沒穩(wěn)定。
• 多數對象無法識別以及腳本維護頻繁與艱難怔球。

4.5 自動化測試用例設計

在項目的測試過程中嚼酝，測試工程師都會首先分析測試需求，產出測試計劃后竟坛，編寫和設計測試用例闽巩，設計開發(fā)測試腳本。

• 自動化測試用例的范圍往往是核心業(yè)務流程或者重復執(zhí)行率較高的担汤。并不需要覆蓋所有的手工測試用例涎跨。
• 自動化測試用例的選擇一般以“正向”為主。正常情況即為“正向”崭歧，異常情況即為“反向”隅很。功能自動化測試主要還是用于回歸測試，回歸測試的目的就是保證新增功能后老功能是否能夠正常運作率碾。
• 手工測試用例可以不用回歸原點叔营，而自動化用例往往是必須的。所謂回歸原點就是執(zhí)行的測試用例最終需要恢復其在執(zhí)行前的初始狀態(tài)播掷。比如添加用戶功能审编，由于用戶名是唯一的，第一次執(zhí)行時沒有問題歧匈，第二次執(zhí)行時程序就會出現用戶名重復而報錯垒酬；這種情況下，就需要在自動化測試用例最后增加刪除該用戶的步驟件炉。
• 自動化測試用例與手工測試用例不同勘究，不需要每個步驟都寫預期結果。

5. 測試文檔編寫與缺陷管理

測試文檔包括：測試計劃文檔斟冕，測試設計規(guī)格文檔口糕，測試用例，軟件缺陷報告磕蛇，狀態(tài)報告景描。

測試用例對一項特定的軟件產品進行測試任務的描述，體現測試方案秀撇、方法超棺、技術和策略。內容包括測試目標呵燕、測試環(huán)境棠绘、輸入數據、測試步驟、預期結果氧苍、測試腳本等夜矗，并形成文檔。測試用例一般包括驗證測試用例和證偽測試用例让虐；驗證測試用例用于驗證代碼是否按照預期執(zhí)行紊撕，得到預期結果；證偽測試用例驗證代碼是否對異常和錯誤條件進行了適當處理澄干。

缺陷報告包括：問題/錯誤的簡單描述逛揩，重現的環(huán)境配置要求，保證多次精確重復的特定輸入麸俘，期望結果與實際結果的對比辩稽，優(yōu)先級與嚴重性，對客戶的影響等从媚。

6. 常用的測試工具

6.1 功能測試UFT

UFT自動化測試的原理

1. 封裝真實被測對象并轉化為UFT對象到對象庫逞泄。
2. 對比對象庫里的對象鑒別屬性和運行時的真實被測對象的鑒別屬性。
3. 對比結果一致拜效，則說明對象成功匹配并可以繼續(xù)對該真實被測對象進行后續(xù)操作喷众；如果不一致則報錯，提示對象無法識別紧憾。

封裝對象模型

在UFT里的封裝對象共分兩個概念到千，Test Objects（測試對象，TO）和Runtime Objects（運行時對象赴穗，RO）憔四。TO就是被被添加到對象庫中的對象，RO就是被測試軟件在運行實際所運行的對象般眉。他們都是UFT封裝的對象了赵，TO是為了識別RO而存在的。

UFT識別對象通常先在對象庫中添加測試對象甸赃，然后在被測軟件運行的時候柿汛，根據腳本中調用的對象名稱，在對象庫中找到相應的測試對象埠对，并根據這些對象的特征屬性络断，在被測試軟件中搜索相匹配的正在運行的對象，最后就可以對這些實際運行的測試對象進行操作项玛。

GetTOProperty()
基本含義：獲取對象庫中某個對象的某個屬性的值妓羊。
公式：ReturnValue = 對象.GetTOProperty("封裝屬性名")

SetTOProperty()
基本含義：設置對象庫中某個對象的某個屬性的值。
公式：對象.SetTOProperty "封裝屬性名" "封裝屬性值"
注：使用代碼形式的修改對象屬性屬于臨時性的稍计，只在腳本運行時有效，一旦腳本運行結束裕循，對象庫里的屬性值就會還原臣嚣。

GetROProperty()
基本含義：獲取實際運行時的某個對象的某個屬性的值净刮。
公式：ReturnValue = 對象.GetROProperty("封裝屬性名")
注：使用GetROProperty這個方法來動態(tài)獲取實際運行時的一些確認信息，然后和所預期的測試數據做對比硅则。如注冊功能淹父，在提交一些注冊信息以后，一般都要到接下來的確認頁面去驗證一些信息怎虫，這就可以使用GetROProperty來動態(tài)獲取實際運行時的一些確認信息暑认。

對象無法識別的解決辦法

1. 設置虛擬對象。不推薦大审，虛擬對象非常脆弱蘸际，難以維護；即使對象沒有發(fā)生變化徒扶，但只要對象在界面是那個的方位發(fā)生變化粮彤，虛擬對象就會識別失敗。
2. 使用相對坐標配合WSH去定位對象姜骡。
3. 使用DOM組建接口應用技術导坟。只適用于Web項目。
4. 使用UFT自定義擴展SDK Customer來進行二次開發(fā)使UFT能夠識別對象圈澈。難度大惫周。
5. 開發(fā)提供專屬插件。
6. 把無法識別的對象的一些方法封裝到一個dll中并使用UFT調用康栈。

數據驅動與場景恢復

數據驅動Data Table的應用：實現測試數據和腳本業(yè)務的分離递递。
場景恢復：場景恢復可以應對多種類型的錯誤并進行恢復操作。

6.2 性能測試LoadRunner

LoadRunner是一種適用于各種體系架構的自動負載測試工具谅将，它能預測系統(tǒng)行為并優(yōu)化系統(tǒng)性能漾狼。LoadRunner的測試對象是整個企業(yè)的系統(tǒng)，它通過模擬實際用戶的操作行為和實時性能監(jiān)測饥臂，來幫助測試人員更快地查找和發(fā)現問題逊躁。

1. 輕松創(chuàng)建虛擬用戶。Virtual User Generator能夠生成虛擬用于隅熙，以虛擬用戶的方式模擬真實用戶的業(yè)務操作行為稽煤。它先記錄下業(yè)務流程，然后將其轉化為測試腳本囚戚，并進行參數化操作（Data Wizard直接連接數據服務器獲取數據）酵熙。利用虛擬用戶可以在不同操作系統(tǒng)上同時產生成千上萬用戶訪問，能極大的減少負載測試所需要的硬件和人力資源驰坊。
2. 創(chuàng)建真實負載匾二。建立虛擬用戶后，需要設定負載方案、業(yè)務流程組合和虛擬用戶數量察藐。用Controller能夠很快地組織多用戶測試方案皮璧。
3. 定位性能問題。LoadRunner內含一個實時檢測器分飞，在負載測試過程的任何時候都能觀察到應用系統(tǒng)的運行性能悴务。
4. 分析結果。一旦測試完畢譬猫，LoadRunner收集匯總所有的測試數據讯檐，并提供高級的分析和報告工具，一遍迅速找到性能問題并做出相應的調整染服。

7. 軟件測試面試題總結

1. 給你一個網站别洪，你如何測試？

首先肌索，查找需求說明蕉拢、網站設計等相關文檔，分析測試需求诚亚。

制定測試計劃晕换，確定測試范圍和測試策略，一般包括以下幾個部分：功能性測試站宗；界面測試闸准；性能測試；數據庫測試梢灭；安全性測試夷家；兼容性測試

功能性測試可以包括，但不限于以下幾個方面：

• 鏈接測試敏释。鏈接是否正確跳轉库快，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回钥顽。
• 提交功能的測試义屏。
• 多媒體元素是否可以正確加載和顯示。
• 多語言支持是否能夠正確顯示選擇的語言等蜂大。

界面測試可以包括但不限于一下幾個方面：

• 頁面是否風格統(tǒng)一闽铐，美觀
• 頁面布局是否合理，重點內容和熱點內容是否突出
• 控件是否正常使用
• 對于必須但未安裝的控件奶浦，是否提供自動下載并安裝的功能
• 文字檢查

性能測試一般從以下兩個方面考慮：壓力測試兄墅；負載測試；強度測試

數據庫測試要具體決定是否需要開展澳叉。數據庫一般需要考慮連結性隙咸，對數據的存取操作沐悦，數據內容的驗證等方面。

安全性測試：

• 基本的登錄功能的檢查
• 是否存在溢出錯誤扎瓶，導致系統(tǒng)崩潰或者權限泄露
• 相關開發(fā)語言的常見安全性問題檢查所踊，例如SQL注入等
• 如果需要高級的安全性測試，確定獲得專業(yè)安全公司的幫助概荷，外包測試，或者獲取支持

兼容性測試碌燕，根據需求說明的內容误证，確定支持的平臺組合：

• 瀏覽器的兼容性；
• 操作系統(tǒng)的兼容性修壕；
• 軟件平臺的兼容性愈捅；
• 數據庫的兼容性

開展測試，并記錄缺陷慈鸠。合理的安排調整測試進度蓝谨，提前獲取測試所需的資源，建立管理體系（例如青团，需求變更譬巫、風險、配置督笆、測試文檔芦昔、缺陷報告、人力資源等內容）娃肿。

定期評審咕缎，對測試進行評估和總結，調整測試的內容料扰。

2. 在搜索引擎中輸入漢字就可以解析到對應的域名凭豪，請問如何用LoadRunner進行測試。

• 建立測試計劃晒杈，確定測試標準和測試范圍
• 設計典型場景的測試用例嫂伞，覆蓋常用業(yè)務流程和不常用的業(yè)務流程等
• 根據測試用例，開發(fā)自動測試腳本和場景：

錄制測試腳本：新建一個腳本（Web/HTML協(xié)議）桐智；點擊錄制按鈕末早，在彈出的對話框的URL中輸入”about:blank”；在打開的瀏覽器中進行正常操作流程后说庭，結束錄制然磷；調試腳本并保存，可能要注意到字符集的關聯刊驴。

設置測試場景：針對性能設置測試場景姿搜，主要判斷在正常情況下寡润，系統(tǒng)的平均事務響應時間是否達標；針對壓力負載設置測試場景舅柜，主要判斷在長時間處于滿負荷或者超出系統(tǒng)承載能力的條件下梭纹，系統(tǒng)是否會崩潰；執(zhí)行測試致份，獲取測試結果变抽，分析測試結果。

3. 一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務器施壓氮块，有什么區(qū)別?

300個用戶在一個客戶端上绍载，會占用客戶機更多的資源，而影響測試的結果滔蝉。線程之間可能發(fā)生干擾击儡，而產生一些異常。300個用戶在一個客戶端上蝠引，需要更大的帶寬阳谍。

IP地址的問題，可能需要使用IP Spoof來繞過服務器對于單一IP地址最大連接數的限制螃概。

所有用戶在一個客戶端上矫夯，不必考慮分布式管理的問題；而用戶分布在不同的客戶端上谅年，需要考慮使用控制器來整體調配不同客戶機上的用戶茧痒。同時，還需要給予相應的權限配置和防火墻設置融蹂。

4. 目前主要的測試用例設計方法是什么旺订？

白盒測試：邏輯覆蓋、循環(huán)覆蓋超燃、基本路徑覆蓋

黑盒測試：邊界值分析法区拳、等價類劃分、錯誤猜測法意乓、因果圖法樱调、狀態(tài)圖法、測試大綱法届良、隨機測試笆凌、場景法

5. 軟件的安全性應從哪幾個方面去測試？

軟件安全性測試包括程序士葫、數據庫安全性測試乞而。根據系統(tǒng)安全指標不同測試策略也不同。

用戶認證安全的測試要考慮問題： 明確區(qū)分系統(tǒng)中不同用戶權限 慢显、系統(tǒng)中會不會出現用戶沖突 爪模、系統(tǒng)會不會因用戶的權限的改變造成混亂 欠啤、用戶登陸密碼是否是可見、可 屋灌、是否可以通過絕對途徑登陸系統(tǒng)（拷貝用戶登陸后的鏈接直接進入系統(tǒng)）洁段、用戶退出系統(tǒng)后是否刪除了所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入系統(tǒng) 共郭、系統(tǒng)網絡安全的測試要考慮問題 祠丝、測試采取的防護措施是否正確裝配好，有關系統(tǒng)的補丁是否打上 落塑、模擬非授權攻擊纽疟，看防護系統(tǒng)是否堅固 、采用成熟的網絡漏洞檢查工具檢查系統(tǒng)相關漏洞（即用最專業(yè)的黑客攻擊工具攻擊試一下憾赁，現在最常用的是 NBSI 系列和 IPhacker IP ） 、采用各種木馬檢查工具檢查系統(tǒng)木馬情況 散吵、采用各種防外掛工具檢查系統(tǒng)各組程序的外掛漏洞

數據庫安全考慮問題： 系統(tǒng)數據是否機密（比如對銀行系統(tǒng)龙考，這一點就特別重要，一般的網站就沒有太高要求）矾睦、系統(tǒng)數據的完整性（我剛剛結束的企業(yè)實名核查服務系統(tǒng)中就曾存在數據的不完整晦款，對于這個系統(tǒng)的功能實現有了障礙） 、系統(tǒng)數據可管理性 枚冗、系統(tǒng)數據的獨立性 缓溅、系統(tǒng)數據可備份和恢復能力（數據備份是否完整，可否恢復赁温，恢復是否可以完整）

6. 簡述什么是靜態(tài)測試坛怪、動態(tài)測試、黑盒測試股囊、白盒測試袜匿、α測試 β測試

靜態(tài)測試是不運行程序本身而尋找程序代碼中可能存在的錯誤或評估程序代碼的過程。

動態(tài)測試是實際運行被測程序稚疹，輸入相應的測試實例居灯，檢查運行結果與預期結果的差異，判定執(zhí)行結果是否符合要求内狗，從而檢驗程序的正確性怪嫌、可靠性和有效性，并分析系統(tǒng)運行效率和健壯性等性能柳沙。

黑盒測試一般用來確認軟件功能的正確性和可操作性,目的是檢測軟件的各個功能是否能得以實現,把被測試的程序當作一個黑盒,不考慮其內部結構,在知道該程序的輸入和輸出之間的關系或程序功能的情況下,依靠軟件規(guī)格說明書來確定測試用例和推斷測試結果的正確性岩灭。

白盒測試根據軟件內部的邏輯結構分析來進行測試,是基于代碼的測試，測試人員通過閱讀程序代碼或者通過使用開發(fā)工具中的單步調試來判斷軟件的質量偎行，一般黑盒測試由項目經理在程序員開發(fā)中來實現川背。

α測試是由一個用戶在開發(fā)環(huán)境下進行的測試贰拿，也可以是公司內部的用戶在模擬實際操作環(huán)境下進行的受控測試，Alpha測試不能由程序員或測試員完成熄云。

β測試是軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進行的測試膨更。開發(fā)者通常不在測試現場，Beta測試不能由程序員或測試員完成缴允。

7. 軟件測試分為幾個階段荚守，各階段的測試策略和要求是什么?

和開發(fā)過程相對應，測試過程會依次經歷單元測試练般、集成測試矗漾、系統(tǒng)測試、驗收測試四個主要階段：

• 單元測試：單元測試是針對軟件設計的最小單位––程序模塊甚至代碼段進行正確性檢驗的測試工作薄料，通常由開發(fā)人員進行敞贡。
• 集成測試：集成測試是將模塊按照設計要求組裝起來進行測試，主要目的是發(fā)現與接口有關的問題摄职。由于在產品提交到測試部門前誊役，產品開發(fā)小組都要進行聯合調試，因此在大部分企業(yè)中集成測試是由開發(fā)人員來完成的谷市。
• 系統(tǒng)測試：系統(tǒng)測試是在集成測試通過后進行的蛔垢，目的是充分運行系統(tǒng)，驗證各子系統(tǒng)是否都能正常工作并完成設計的要求迫悠。它主要由測試部門進行鹏漆，是測試部門最大最重要的一個測試，對產品的質量有重大的影響创泄。
• 驗收測試：驗收測試以需求階段的《需求規(guī)格說明書》為驗收標準艺玲，測試時要求模擬實際用戶的運行環(huán)境。對于實際項目可以和客戶共同進行验烧，對于產品來說就是最后一次的系統(tǒng)測試板驳。測試內容為對功能模塊的全面測試，尤其要進行文檔測試碍拆。

單元測試測試策略：

• 自頂向下的單元測試策略：比孤立單元測試的成本高很多若治，不是單元測試的一個好的選擇。
• 自底向上的單元測試策略：比較合理的單元測試策略感混，但測試周期較長端幼。

集成測試的測試策略：

• 大爆炸集成：適應于一個維護型項目或被測試系統(tǒng)較小
• 自頂向下集成：適應于產品控制結構比較清晰和穩(wěn)定；高層接口變化較谢÷婆跑；底層接口未定義或經常可能被修改庭呜；產口控制組件具有較大的技術風險滑进，需要盡早被驗證犀忱；希望盡早能看到產品的系統(tǒng)功能行為。
• 自底向上集成：適應于底層接口比較穩(wěn)定扶关；高層接口變化比較頻繁阴汇；底層組件較早被完成。
• 基于進度的集成
• 優(yōu)點：具有較高的并行度节槐；能夠有效縮短項目的開發(fā)進度搀庶。
• 缺點：樁和驅動工作量較大；有些接口測試不充分铜异；有些測試重復和浪費哥倔。

系統(tǒng)測試的測試策略：數據和數據庫完整性測試；功能測試；用戶界面測試；性能評測；負載測試；強度測試绅这；容量測試；安全性和訪問控制測試；故障轉移和恢復測試搓茬；配置測試；安裝測試试浙；加密測試董瞻；可用性測試；版本驗證測試田巴；文檔測試

8. 軟件測試各個階段通常完成什么工作钠糊？各個階段的結果文件是什么？包括什么內容壹哺？

單元測試階段：各獨立單元模塊在與系統(tǒng)地其他部分相隔離的情況下進行測試抄伍，單元測試針對每一個程序模塊進行正確性校驗，檢查各個程序模塊是否正確地實現了規(guī)定的功能管宵。生成單元測試報告截珍，提交缺陷報告。

集成測試階段：集成測試是在單元測試的基礎上箩朴，測試在將所有的軟件單元按照概要設計規(guī)格說明的要求組裝成模塊岗喉、子系統(tǒng)或系統(tǒng)的過程中各部分工作是否達到或實現相應技術指標及要求的活動。該階段生成集成測試報告炸庞，提交缺陷報告钱床。

系統(tǒng)測試階段：將通過確認測試的軟件，作為整個給予計算機系統(tǒng)的一個元素埠居，與計算機硬件查牌、外設事期、某些支持軟件、數據和人員等其他系統(tǒng)元素結合在一起纸颜，在實際運行環(huán)境下兽泣，對計算機系統(tǒng)進行全面的功能覆蓋。該階段需要提交測試總結和缺陷報告懂衩。

9. 一條軟件缺陷（或者叫Bug）記錄都包含了哪些內容撞叨？

一條Bug記錄最基本應包含：

• bug編號；
• bug嚴重級別浊洞，優(yōu)先級牵敷；
• bug產生的模塊；
• 首先要有bug摘要法希，闡述bug大體的內容枷餐；
• bug對應的版本；
• bug詳細現象描述苫亦，包括一些截圖毛肋、錄像....等等；
• bug出現時的測試環(huán)境屋剑，產生的條件即對應操作步驟润匙；

10. 黑盒測試和白盒測試是軟件測試的兩種基本方法，請分別說明各自的優(yōu)點和缺點唉匾！

黑盒測試的優(yōu)點有：比較簡單孕讳，不需要了解程序內部的代碼及實現；與軟件的內部實現無關巍膘； 從用戶角度出發(fā)厂财，能很容易的知道用戶會用到哪些功能，會遇到哪些問題峡懈；基于軟件開發(fā)文檔璃饱，所以也能知道軟件實現了文檔中的哪些功能；在做軟件自動化測試時較為方便肪康。

黑盒測試的缺點有：不可能覆蓋所有的代碼荚恶，覆蓋率較低，大概只能達到總代碼量的30%梅鹦；自動化測試的復用性較低裆甩。

白盒測試的優(yōu)點有：幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量齐唆，發(fā)現代碼中隱 藏的問題嗤栓。

白盒測試的缺點有：程序運行會有很多不同的路徑，不可能測試所有的運行路徑；測試基于代碼茉帅，只能測試開發(fā)人員做的對不對叨叙，而不能知道設計的正確與否，可能會漏掉一些功能需求堪澎；系統(tǒng)龐大時擂错，測試開銷會非常大。

13. 如何測試一個紙杯樱蛤？

功能度：用水杯裝水看漏不漏钮呀；水能不能被喝到
安全性：杯子有沒有毒或細菌
可靠性：杯子從不同高度落下的損壞程度
可移植性：杯子在不同的地方、溫度等環(huán)境下是否都可以正常使用
兼容性：杯子是否能夠容納果汁昨凡、白水爽醋、酒精、汽油等
易用性：杯子是否燙手便脊、是否有防滑措施蚂四、是否方便飲用
用戶文檔：使用手冊是否對杯子的用法、限制哪痰、使用條件等有詳細描述
疲勞測試：將杯子盛上水（案例一）放24小時檢查泄漏時間和情況遂赠；盛上汽油（案例二）放24小時檢查泄漏時間和情況等
壓力測試：用根針并在針上面不斷加重量，看壓強多大時會穿透

11. 黑盒測試的測試用例常見設計方法都有哪些晌杰？請分別以具體的例子來說明這些方法在測試用例設計工作中的應用跷睦。

1）等價類劃分： 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對于揭露程序中的錯誤都是等效的.并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試.因此,可以把全部輸入數據合理劃分為若干等價類,在每一個等價類中取一個數據作為測試的輸入條件,就可以用少量代表性的測試數據.取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.

2）邊界值分析法：是對等價類劃分方法的補充。測試工作經驗告訴我,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.

使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數據,而不是選取等價類中的典型值或任意值作為測試數據.

3）錯誤猜測法：基于經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.

錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產品測試中曾經發(fā)現的錯誤等, 這些就是經驗的總結. 還有, 輸入數據和輸出數據為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發(fā)生錯誤的情況. 可選擇這些情況下的例子作為測試用例.

4）因果圖方法：前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 因此必須考慮采用一種適合于描述對于多種條件的組合,相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況.

5）正交表分析法：可能因為大量的參數的組合而引起測試用例數量上的激增肋演，同時送讲，這些測試用例并沒有明顯的優(yōu)先級上的差距，而測試人員又無法完成這么多數量的測試惋啃，就可以通過正交表來進行縮減一些用例，從而達到盡量少的用例覆蓋盡量大的范圍的可能性监右。

6）場景分析方法：指根據用戶場景來模擬用戶的操作步驟边灭，這個比較類似因果圖，但是可能執(zhí)行的深度和可行性更好健盒。

7）狀態(tài)圖法：通過輸入條件和系統(tǒng)需求說明得到被測系統(tǒng)的所有狀態(tài)绒瘦，通過輸入條件和狀態(tài)得出輸出條件；通過輸入條件扣癣、輸出條件和狀態(tài)得出被測系統(tǒng)的測試用例惰帽。

8）大綱法：大綱法是一種著眼于需求的方法，為了列出各種測試條件父虑，就將需求轉換為大綱的形式该酗。大綱表示為樹狀結構，在根和每個葉子結點之間存在唯一的路徑。大綱中的每條路徑定義了一個特定的輸入條件集合呜魄，用于定義測試用例悔叽。樹中葉子的數目或大綱中的路徑給出了測試所有功能所需測試用例的大致數量。

12. 詳細的描述一個測試活動完整的過程爵嗅。（供參考娇澎，本答案主要是瀑布模型的做法）

項目經理通過和客戶的交流，完成需求文檔睹晒，由開發(fā)人員和測試人員共同完成需求文檔的評審趟庄，評審的內容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實現的功能的地方。項目經理通過綜合開發(fā)人員伪很，測試人員以及客戶的意見戚啥，完成項目計劃。然后SQA進入項目是掰，開始進行統(tǒng)計和跟蹤

開發(fā)人員根據需求文檔完成需求分析文檔虑鼎，測試人員進行評審，評審的主要內容包括是否有遺漏或雙方理解不同的地方键痛。測試人員完成測試計劃文檔炫彩，測試計劃包括的內容上面有描述。

測試人員根據修改好的需求分析文檔開始寫測試用例絮短，同時開發(fā)人員完成概要設計文檔江兢，詳細設計文檔。此兩份文檔成為測試人員撰寫測試用例的補充材料丁频。

測試用例完成后杉允，測試和開發(fā)需要進行評審。

測試人員搭建環(huán)境

開發(fā)人員提交第一個版本席里，可能存在未完成功能叔磷，需要說明。測試人員進行測試奖磁，發(fā)現BUG后提交給BugZilla改基。

開發(fā)提交第二個版本，包括Bug Fix以及增加了部分功能咖为，測試人員進行測試秕狰。

重復上面的工作，一般是3-4個版本后BUG數量減少躁染，達到出貨的要求鸣哀。

如果有客戶反饋的問題，需要測試人員協(xié)助重現并重新測試吞彤。

13. 說說你對集成測試中自頂向下集成和自底向上集成兩個策略的理解我衬，要談出它們各自的優(yōu)缺點和主要適應于哪種類型測試

自頂向下集成

• 優(yōu)點：較早地驗證了主要控制和判斷點；按深度優(yōu)先可以首先實現和驗證一個完整的軟件功能；功能較早證實低飒，帶來信心许昨；只需一個驅動，減少驅動器開發(fā)的費用褥赊；支持故障隔離糕档。
• 缺點：柱的開發(fā)量大；底層驗證被推遲拌喉；底層組件測試不充分速那。
• 適應于產品控制結構比較清晰和穩(wěn)定；高層接口變化較心虮场端仰；底層接口未定義或經常可能被修改田藐；產口控制組件具有較大的技術風險荔烧，需要盡早被驗證；希望盡早能看到產品的系統(tǒng)功能行為汽久。

自底向上集成

• 優(yōu)點：對底層組件行為較早驗證鹤竭；工作最初可以并行集成，比自頂向下效率高景醇；減少了樁的工作量臀稚；支持故障隔離。
• 缺點：驅動的開發(fā)工作量大三痰；對高層的驗證被推遲吧寺，設計上的錯誤不能被及時發(fā)現。
• 適應于底層接口比較穩(wěn)定散劫；高層接口變化比較頻繁稚机；底層組件較早被完成。

14. 設計測試用例時應該考慮哪些方面获搏，即不同的測試用例針對那些方面進行測試抒钱？

設計測試用例時需要注意的是，除了對整體流程及功能注意外颜凯，還要注意強度測試、性能測試仗扬、壓力測試症概、邊界值測試、穩(wěn)定性測試早芭、安全性測試等多方面彼城。（測試用例需要考慮的四個基本要素是輸入、輸出、操作和測試環(huán)境募壕；另外调炬，測試用例需要考慮的是測試類型（功能、性能舱馅、安全……）缰泡，這部分可以參照TP做答。此外代嗤，還需要考慮用例的重要性和優(yōu)先級）

15. 在windows下保存一個文本文件時會彈出保存對話框棘钞，如果為文件名建立測試用例，等價類應該怎樣劃分干毅？

單字節(jié)宜猜，如A；雙字節(jié)硝逢， AA姨拥、我我；特殊字符 /‘渠鸽〗形冢‘；拱绑、=-等综芥；保留字，如com猎拨；文件格式為8.3格式的膀藐；文件名格式為非8.3格式的；/,,*等九個特殊字符红省。

假設有一個文本框要求輸入10個字符的郵政編碼额各，對于該文本框應該怎樣劃分等價類？

特殊字符吧恃，如10個*或￥虾啦；英文字母，如ABCDefghik痕寓；小于十個字符傲醉，如123；大于十個字符呻率，如11硬毕；數字和其他混合，如123AAAAAAA礼仗；空字符吐咳；保留字符

16. 單元測試逻悠、集成測試、系統(tǒng)測試的側重點是什么韭脊？

• 單元測試針對的是軟件設計的最小單元--程序模塊（面向過程中是函數童谒、過程；面向對象中是類沪羔。）,進行正確性檢驗的測試工作,在于發(fā)現每個程序模塊內部可能存在的差錯.一般有兩個步驟:人工靜態(tài)檢查\動態(tài)執(zhí)行跟蹤
• 集成測試針對的是通過了單元測試的各個模塊所集成起來的組件進行檢驗,其主要內容是各個單元模塊之間的接口,以及各個模塊集成后所實現的功能.
• 系統(tǒng)測試針對的是集成好的軟件系統(tǒng)饥伊，作為整個計算機系統(tǒng)的一個元素,與計算機硬件\外設\某些支持軟件\數據和人員等其他系統(tǒng)元素結合在一起,要在實際的運行環(huán)境中,對計算機系統(tǒng)進行一系列的集成測試和確認測試.

17. 你所了解的的軟件測試類型都有哪些，簡單介紹一下任内。

按測試策略分類：1撵渡、靜態(tài)與動態(tài)測試2、黑盒與白盒測試 3死嗦、手工和自動測試 4趋距、冒煙測試 5、回歸測試越除；

按測試階段分類：單元測試节腐、集成測試、系統(tǒng)測試摘盆；

其他常見測試方法：1翼雀、功能測試 2、性能測試 3孩擂、壓力測試 4狼渊、負載測試 5、易用性測試 6类垦、安裝測試 7狈邑、界面測試 8、配置測試 9蚤认、文檔測試 10米苹、兼容性測試 11、安全性測試 12砰琢、恢復測試

18. 您認為做好測試用例設計工作的關鍵是什么蘸嘶？

白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果

黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試陪汽，以最少的用例在合理的時間內發(fā)現最多的問題

19. 一套完整的測試應該由哪些階段組成训唱？

可行性分析、需求分析挚冤、概要設計况增、詳細設計、編碼你辣、單元測試巡通、集成測試、系統(tǒng)測試舍哄、驗收測試

20. 面向對象的測試用例設計有幾種方法宴凉？如何實現？

給類中的每個構造函數設計一組測試用例

組合類中的類變量表悬、實例變量

組合類中的各種方法

根據前置條件和后置條件設計測試用例

根據代碼設計測試用例