一.測驗與軟體模型
軟體開發生命周期模型指的是軟體開發全程序、活動和任務的結構性框架，軟體專案的開發包括：需求、設計、編碼、測驗、穩定、部署、維護等階段，
常見的軟體開發模型有瀑布模型、迭代開發、螺旋開發和敏捷開發，
1.瀑布模型
瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求分析、設計、編碼、集成、測驗、維護的步驟順序進行，步驟成果作為衡量進度的方法，例如需求規格，設計檔案，測驗計劃和代碼審閱等等，瀑布式的主要有以下問題：
各個階段的劃分完全固定，階段之間產生大量的檔案，極大地增加了作業量；
由于開發模型是線性的，用戶只有等到整個程序的末期才能見到開發成果，從而增加了開發的風險；
早期的錯誤可能要等到開發后期的測驗階段才能發現，進而帶來嚴重的后果，
因此，瀑布式方法在需求不明并且在專案進行程序中可能變化的情況下基本是不可行的，
2.迭代開發模型
迭代式開發是一種與傳統的瀑布式開發相反的軟體開發程序，具有更高的成功率和生產率，在迭代開發中，整個開發作業被組織為一系列的短小的、固定長度（如3周）的小專案，逐步逐步的完成，故為迭代，每一次迭代都包括需求分析、設計、實作與測驗，采用這種方法，開發作業可以在需求被完整地確定之前啟動，并在一次迭代中完成系統的一部分功能或業務邏輯的開發作業，再通過客戶的反饋來細化需求，并開始新一輪的迭代，迭代開發具有以下優點：
降低風險，如果開發人員重復某個迭代，那么損失只是這一個開發有誤的迭代的花費，
適應需求變更，由于用戶的需求并不能在一開始就作出完全的界定，它們通常是在后續階段中不斷細化的，
持續的測驗與集成，降低后期的作業量與風險，
3 .螺旋開發模型
螺旋開發，將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合于大型復雜的系統，“螺旋模型”剛開始規模很小，當專案被定義得更好、更穩定時，逐漸展開， “螺旋模型”的核心就在于不需要在剛開始的時候就把所有事情都定義的清清楚楚，您輕松上陣，定義最重要的功能，實作它，然后聽取客戶的意見，之后再進入到下一個階段，如此不斷輪回重復，直到得到您滿意的最終產品， 螺旋開發分為以下四個階段：
制定計劃：確定軟體目標，選定實施方案，弄清專案開發的限制條件；
風險分析：分析評估所選方案，考慮如何識別和消除風險；
實施工程：實施軟體開發和驗證；
客戶評估：評價開發作業，提出修正建議，制定下一步計劃，
一個階段首先是確定該階段的目標，完成這些目標的選擇方案及其約束條件，然后從風險角度分析方案的開發策略，努力排除各種潛在的風險，有時需要通過建 造原型來完成，如果某些風險不能排除，該方案立即終止，否則啟動下一個開發步驟，最后，評價該階段的結果，并設計下一個階段，
4 .敏捷開發模型
敏捷開發，是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力，相對于“非敏捷”，更強調程式員團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的檔案更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼撰寫和團隊組織方法，也更注重軟體開發中人的作用，
個體和互動重于流程和工具，
可作業的軟體重于求全而完備的檔案，
客戶協作重于合同談判，
應對變化重于遵循計劃，
其中位于右邊的內容雖然也有其價值，但是左邊的內容最為重要，人員彼此信任，人少但是精干，可以面對面的溝通，
敏捷開發小組主要的作業方式可以歸納為：作為一個整體作業；按短迭代周期作業；每次迭代交付一些成果；關注業務優先；檢查與調整，
最重要的因素恐怕是專案的規模，規模增長，面對面的溝通就愈加困難，因此敏捷方法更適用于較小的隊伍，40、30、20、10人或者更少，
5 .四種模型比較
傳統的瀑布式開發，也就是從需求到設計，從設計到編碼，從編碼到測驗，從測驗到提交大概這樣的流程，要求每一個開發階段都要做到最好，特別是前期階段，設計的越完美，提交后的成本損失就越少，
迭代式開發，不要求每一個階段的任務做的都是最完美的，而是明明知道還有很多不足的地方，卻偏偏不去完善它，而是把主要功能先搭建起來為目的，以最短的時間，最少的損失先完成一個“不完美的成果物”直至提交，然后再通過客戶或用戶的反饋資訊，在這個“不完美的成果物”上逐步進行完善，
螺旋開發，很大程度上是一種風險驅動的方法體系，因為在每個階段之前及經常發生的回圈之前，都必須首先進行風險評估，
敏捷開發，相比迭代式開發兩者都強調在較短的開發周期提交軟體，但是，敏捷開發的周期可能更短，并且更加強調隊伍中的高度協作，敏捷方法有時候被誤認為是無計劃性和紀律性的方法，實際上更確切的說法是敏捷方法強調適應性而非預見性，
適應性的方法集中在快速適應現實的變化，當專案的需求起了變化，團隊應該迅速適應，這個團隊可能很難確切描述未來將會如何變化，
6 .軟體開發程序中的測驗
在前面介紹的軟體開發程序中，測驗都是一個重要的組成部分，尤其對于中大型專案，從專案開始指出就要制定測驗計劃、對需求進行測驗、設計測驗和測驗用例、執行測驗，最后對測驗的結果進行總結和分析，軟體缺陷發現得越早，修復軟體缺陷所需的代價越小，
TDD（測驗驅動開發）的思路就是通過測驗推動整個開發的進行，開發代碼之前，先撰寫測驗代碼，在明確要開發某個功能后，首先思考如何對這個功能進行測驗，并完成測驗代碼的撰寫，然后撰寫相關的代碼滿足這些測驗用例，并且，軟體測驗的活動貫穿整個軟體開發生命周期的始終，
7 .軟體測驗的目的與原則
測驗的定義：使用人工或自動手段來運行或測定某個系統的程序，其目的在于檢查它是否滿足規定的需求或是弄清預期結果與實際結果之間的差別，
軟體測驗的目的：發現程式中的錯誤，保證軟體產品的最終質量，
測驗是程式的執行程序，目的在于發現錯誤
一個成功的測驗用例在于發現至今未發現的錯誤
一個成功的測驗是發現了至今未發現的錯誤的測驗
確保產品完成了它所承諾或公布的功能，并且用戶可以訪問到的功能都有明確的書面說明，
確保產品滿足性能和效率的要求
確保產品是健壯的和適應用戶環境的
軟體測驗的原則：
測驗用例中一個必須部分是對預期輸出或介面進行定義
程式員應避免測驗自己撰寫的程式
撰寫軟體的組織不應當測驗自己撰寫的軟體
應當徹底檢查每個測驗的執行結果
測驗用例的撰寫不僅應當根據有效和預料到的輸入情況，而且也應當根據無效和未預料到的輸入情況
檢查程式是否“未做其應該做的”僅是測驗的一半，測驗的另一半是檢查程式是否“做了其不應該做的”
應避免測驗用例用后即棄，除非軟體本身就是個一次性的軟體
計劃測驗作業時不應默許假定不會發現錯誤
程式某部分存在更多錯誤的可能性，與該部分已經發現錯誤的數量成正比
8 .軟體的可測性
軟體的可測性太差會導致測驗的難度相當大，甚至無法測驗，這種情況往往是由于極差的軟體架構設計和極為不規范的軟體開發作業導致的，
緊耦合，不把大半個系統實體化就無法測驗，
弱內聚，這個類實作了太多功能，導致測驗非常復雜，
冗余，同一個方法在多處使用，每一處都得測，
好的軟體架構應該是松耦合、高內聚的，提高軟體的測驗性的同時也提高了軟體的可維護性和可管理性，
二.測驗用例設計
測驗用例是為特定的目的而設計的一組測驗輸入、執行條件和預期的結果，測驗用例是執行的最小物體，簡單地說，測驗用例就是設計一個場景，使軟體程式在這種場景下，必須能夠正常運行并且達到程式所設計的執行結果，
1.是否符合要求，
白盒測驗：已知產品的內部作業程序，可以進行測驗證明每種內部操作是否符合設計規格要求，所有內部成分是否經過檢查，
合理的測驗策略是將這兩種測驗要素組合起來，我們可以通過使用特定的面向黑盒測驗的測驗用例設計方法，而后使用白盒測驗方法對程式的邏輯結構進行檢查以補充這些測驗用例，借此來設計出一個相當嚴格的測驗，
白盒測驗方法有陳述句覆寫、判定覆寫、條件覆寫、判定/條件覆寫、條件組合覆寫、路徑覆寫，黑盒測驗方法有等價類劃分、邊界值分析、因果圖分析、錯誤測驗、狀態圖、場景法等，
2. 白盒測驗用例設計
白盒測驗關注的是測驗用例執行的程度或覆寫程式邏輯結構（源代碼）的程度，完全的白盒測驗是將程式中每條路徑都執行到，然而對一個帶有回圈的程式來說，完全的路徑測驗并不切合實際，白盒測驗的特點：依據軟體設計說明書進行測驗、對程式內部細節的嚴密檢驗、針對特定條件設計測驗用例、對軟體的邏輯路徑進行覆寫測驗，
陳述句覆寫是最起碼的結構覆寫要求，陳述句覆寫要求設計足夠多的測驗用例，使得程式中每條陳述句至少被執行一次，可以很直觀地從源代碼得到測驗用例，無須細分每條判定運算式，由于這種測驗方法僅僅針對程式邏輯中顯式存在的陳述句，但對于隱藏的條件和可能到達的隱式邏輯分支，是無法測驗的，（遺漏隱藏的邏輯分支）
判定覆寫要求必須撰寫足夠的測驗用例，使得每一個判斷都至少有一個為“真”和為“假”的輸出結果，判定覆寫比陳述句覆寫要多幾乎一倍的測驗路徑，當然也就具有比陳述句覆寫更強的測驗能力，同樣判定覆寫也具有和陳述句覆寫一樣的簡單性，無須細分每個判定就可以得到測驗用例，往往大部分的判定陳述句是由多個邏輯條件組合而成（如，判定陳述句中包含AND、OR、CASE），若僅僅判斷其整個最終結果，而忽略每個條件的取值情況，必然會遺漏部分測驗路徑，（遺漏組合判定中的某些條件取值）
條件覆寫要求設計足夠多的測驗用例，使得判定中的每個條件獲得各種可能的結果，即每個條件至少有一次為真值，有一次為假值，要達到條件覆寫，需要足夠多的測驗用例，但條件覆寫并不能保證判定覆寫，條件覆寫只能保證每個條件至少有一次為真，而不考慮所有的判定結果，
判定/條件覆寫要求設計足夠多的測驗用例，使得判定中每個條件的所有可能結果至少出現一次，每個判定本身所有可能結果也至少出現一次，判定/條件覆寫滿足判定覆寫準則和條件覆寫準則，彌補了二者的不足，判定/條件覆寫準則的缺點是未考慮條件的組合情況，
多重條件覆寫要求設計足夠多的測驗用例，使得每個判定中條件結果的所有可能組合至少出現一次，多重條件覆寫準則滿足判定覆寫、條件覆寫和判定/條件覆寫準則，更改的判定/條件覆寫要求設計足夠多的測驗用例，使得判定中每個條件的所有可能結果至少出現一次，每個判定本身的所有可能結果也至少出現一次，并且每個條件都顯示能單獨影響判定結果，缺點是線性地增加了測驗用例的數量，
路徑覆寫要求設計足夠的測驗用例，覆寫程式中所有可能的路徑，由于路徑覆寫需要對所有可能的路徑進行測驗（包括回圈、條件組合、分支選擇等），那么需要設計大量、復雜的測驗用例，使得作業量呈指數級增長，而在有些情況下，一些執行路徑是不可能被執行的，這樣不僅降低了測驗效率，而且大量的測驗結果的累積，也為排錯帶來麻煩，
3 .黑盒測驗用例設計
3.1 等價類劃分
等價類劃分是把所有可能的輸入資料,即程式的輸入域劃分成若干部分（子集）,然后從每一個子集中選取少數具有代表性的資料作為測驗用例，等價類分為有效等價類和無效等價類，其中，有效等價類是指對于程式的規格說明來說是合理的，有意義的輸入資料構成的集合；而無效等價類是指對于程式的規格說明來說是不合理的，沒有意義的輸入資料構成的集合，設計測驗用例時,要同時考慮這兩種等價類，因為軟體不僅要能接收合理的資料,也要能經受意外的考驗，這樣的測驗才能確保軟體具有更高的可靠性，劃分等價類有以下原則：
在輸入條件規定了取值范圍或值的個數的情況下,則可以確立一個有效等價類和兩個無效等價類，如：輸入值是學生成績，范圍是0～100；則小于0和大于100的為無效等價類，0~100之間的為有效等價類，
在輸入條件規定了輸入值的集合或者規定了"必須如何"的條件的情況下，可確立一個有效等價類和一個無效等價類，
在輸入條件是一個布爾量的情況下,可確定一個有效等價類和一個無效等價類，
在規定了輸入資料的一組值（假定n個）,并且程式要對每一個輸入值分別處理的情況下,可確立n個有效等價類和一個無效等價類，例：輸入條件說明學歷可為:專科、本科、碩士、博士四種之一，則分別取這四種這四個值作為四個有效等價類，另外把四種學歷之外的任何學歷作為無效等價類，
在規定了輸入資料必須遵守的規則的情況下,可確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）；
在確知已劃分的等價類中各元素在程式處理中的方式不同的情況下,則應再將該等價類進一步的劃分為更小的等價類，
在確立了等價類后,可建立等價類表,列出所有劃分出的等價類輸入條件：有效等價類、無效等價類，然后從劃分出的等價類中按以下三個原則設計測驗用例：
為每一個等價類規定一個唯一的編號；
設計一個新的測驗用例,使其盡可能多地覆寫尚未被覆寫地有效等價類,重復這一步，直到所有的有效等價類都被覆寫為止；
設計一個新的測驗用例,使其僅覆寫一個尚未被覆寫的無效等價類,重復這一步，直到所有的無效等價類都被覆寫為止，
3.2 邊界值分析
邊界值分析法就是對輸入或輸出的邊界值進行測驗的一種黑盒測驗方法，通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測驗用例來自等價類的邊界，邊界值分析不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測驗條件，邊界值分析不僅考慮輸入條件，還要考慮輸出空間產生的測驗情況，
長期的測驗作業經驗告訴我們，大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是發生在輸入輸出范圍的內部，因此針對各種邊界情況設計測驗用例，可以查出更多的錯誤，使用邊界值分析方法設計測驗用例，首先應確定邊界情況，通常輸入和輸出等價類的邊界，就是應著重測驗的邊界情況，應當選取正好等于，剛剛大于或剛剛小于邊界的值作為測驗資料，而不是選取等價類中的典型值或任意值作為測驗資料，
3.3 因果圖
因果圖是一種利用圖解法分析輸入的各種組合情況，從而設計測驗用例的方法，它適合于檢查程式輸入條件的各種組合情況，
等價類劃分法和邊界值分析方法都是著重考慮輸入條件，但沒有考慮輸入條件的各種組合、輸入條件之間的相互制約關系，這樣雖然各種輸入條件可能出錯的情況已經測驗到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了，如果在測驗時必須考慮輸入條件的各種組合，則可能的組合數目將是天文數字，因此必須考慮采用一種適合于描述多種條件的組合、相應產生多個動作的形式來進行測驗用例的設計，這就需要利用因果圖（邏輯模型），
3.4 錯誤測驗
錯誤測驗是基于經驗和直覺推測程式中所有可能存在的各種錯誤, 從而有針對性的設計測驗用例的方法，
如測驗一個對線性表（比如陣列）進行排序的程式，可推測列出以下幾項需要特別測驗的情況：
輸入的線性表為空表；
表中只含有一個元素；
輸入表中所有元素已排好序；
輸入表已按逆序排好；
輸入表中部分或全部元素相同，
3.5
測驗用例設計綜合策略
Myers提出了使用各種測驗方法的綜合策略：
在任何情況下都必須使用邊界值分析方法，經驗表明用這種方法設計出測驗用例發現程式錯誤的能力最強，
必要時用等價類劃分方法補充一些測驗用例，
用錯誤推測法再追加一些測驗用例，
對照程式邏輯，檢查已設計出的測驗用例的邏輯覆寫程度，如果沒有達到要求的覆寫標準，應當再補充足夠的測驗用例，
如果程式的功能說明中含有輸入條件的組合情況，則一開始就可選用因果圖法，
測驗用例的設計步驟：1)構造根據設計規格得出的基本功能測驗用例；2)邊界值測驗用例；3)狀態轉換測驗用例；4)錯誤猜測測驗用例；5)例外測驗用例；6)性能測驗用例；7)壓力測驗用例，
三.軟體測驗型別
A.單元測驗
單元測驗并不是對整個程式進行測驗，而是對構成程式的較小模塊進行測驗，單元測驗減小了除錯的難度（一旦某個錯誤被發現出來，我們就知道它在哪個具體的模塊中）；單元測驗提供了同時測驗多個模塊的可能，將并行工程引入軟體測驗中，
在為模塊單元測驗設計測驗用例時，需要使用兩種型別的資訊：模塊的規格說明和模塊的源代碼，規格說明一般都規定了模塊的輸入和輸出引數以及模塊的功能，單元測驗總體上是面向白盒測驗的，因此，單元測驗的測驗用例的設計程序如下：使用一種或多種白盒測驗方法分析模塊的邏輯結構，然后使用黑盒測驗方法對照模塊的規格說明以補充測驗用例，
B.集成測驗
自頂向下集成和自底向上集成
C.功能測驗
功能測驗的目的是為了暴露程式的錯誤以及與規格說明不一致之處，而不是為了證明程式符合其外部規格說明，
功能測驗是一種黑盒測驗，功能測驗常用步驟有：根據需求來細分功能點，根據功能點派生測驗需求，根據測驗需求設計功能測驗用例，
D.系統測驗
系統測驗的目的是為了證明程式不能實作其目標，系統測驗的測驗用例設計有以下14種型別：
1.能力測驗：是判斷目標檔案提及的每一項能力（或功能）是否都確實已經實作，
2.容量測驗：使程式經受大容量資料的檢驗，容量測驗的目的是為了證明程式不3.能處理目標檔案中規定的資料容量，
3.強度測驗：使程式承受高負載或強度的檢驗，所謂高強度是指在很短的時間間隔內達到的資料或操作的數量峰值，
4.易用性測驗：試圖發現人為因素或易用性的問題，
5.安全性測驗：設計測驗用例來突破程式安全檢查的程序，舉例來說，我們可以設計測驗用例來規避作業系統的記憶體保護機制，破壞資料庫管理系統的資料安全機制，
6.性能測驗：很多軟體都有特定的性能或效率目標，這終特性描述為在特定負載和配置環境下程式的回應時間和吞吐率，
7.存盤測驗：
8.配置測驗：
9.兼容性測驗，
10…安裝測驗：有些型別的軟體系統安裝程序非常復雜，測驗安裝程序是系統測驗中的一個重要部分，對于包含在軟體包中的自動安裝系統而言，這尤其重要，安裝程式如果出現故障，會影響用戶對軟體的成功體驗，
11.可靠性測驗：所有型別的測驗都是為了提高軟體的可靠性，但是如果軟體的目標中包含了對可靠性的特別描述，就必須設計專門的可靠性測驗，
12.可恢復性測驗：諸如作業系統、資料庫管理系統和遠程處理系統等軟體通常都有可恢復性目標，說明系統如何從程式錯誤、硬體失效和資料錯誤中恢復過來，系統測驗的一個目標是證明這些恢復機制不能夠正確發揮作用，我們可以故意將程式錯誤置入某個系統中，判斷系統是否可以從中恢復，
13.適用性測驗
14.檔案測驗：檢查用戶檔案的正確性，用戶檔案應成為審查的物件，檢查其正確性和清晰性，在檔案中描述的任何范例應編成測驗用例，并提交給程式，
四.自動化測驗
自動化測驗：以程式測驗程式、以代碼代替思維、以腳本運行代替手工測驗，
冒煙測驗:就是在一個新版本出來的時候，將軟體的全部功能過一遍，看有沒有什么大問題，如果功能可以正常運行，不會影響測驗進行，那么這個版本就可以真正開始測驗了，如果功能有重大問題或影響測驗進行，那么這個版本就是不合格的，不用進行進一步的測驗，比如，拿到QQ的app新版本，登陸都登陸不上，那么這個版本肯定無法繼續測下去，或者，游戲中新的模塊出現，但是新的模塊總是崩潰、卡死，測驗進行不下去，那么冒煙的結果就是不合格的，
回歸測驗:就是以前版本中發現的bug在新的版本中驗證是否存在且是否引發新的bug，
1.自動化測驗的優勢
回歸測驗更方便、可靠，由于回歸測驗的業務流程操作和測驗用例是預先設計好的，預期結果也是完全在專案人員掌握之中的，將回歸測驗交給計算機自動運行，可以極大提高測驗效率，縮短回歸測驗時間，
可運行更多更繁瑣的測驗，且快速高效，
可執行一些對于手工測驗來說相當困難或根本做不到的測驗，比如，對大量用戶的并發測驗等，
具有一致性和可重復性的特點，
自動化測驗腳本完全具有復用性，由于自動化測驗通常以腳本的方式實作，這樣在不同的版本之間，就可能只需要做少量的維護甚至不做任何修改，實作在不同的測驗版本中使用相同的測驗腳本執行相同的測驗用例，
2. 自動化測驗的劣勢
永遠不可能完全取代手工測驗，自動化測驗無法做到手工測驗的覆寫率，不是每個測驗用例都適合轉換成自動化測驗用例的，
無法保證測驗的正確性，測驗腳本本身也可能存在缺陷，
手工測驗能發現的缺陷遠比自動化測驗多，自動化測驗幾乎是無法發現新缺陷，
自動化測驗工具是死的，它本身沒有任何想象力，
自動化測驗對測驗工程師來說必須有一定的開發技術背景
3 .引入自動化測驗的時機
專案周期長，系統版本不斷，主要在于回歸測驗，
需求變更不頻繁，
系統中的測驗物件基本可以正常識別，不存在大批量第三方控制元件，
需要反復測驗，如可靠性測驗需要進行上千次的系統測驗，
4 .何時避免展開自動化測驗
專案周期短，需求變更頻繁，專案周期短的情況下引入自動化測驗，不但收不回成本，而且會延長產品的發布時間，需求頻繁改變會使老功能的業務邏輯被修改，從而導致相應的測驗腳本也需相應修改，
軟體版本還沒穩定，
多數物件無法識別以及腳本維護頻繁與艱難，
5 .自動化測驗用例設計
在專案的測驗程序中，測驗工程師都會首先分析測驗需求，產出測驗計劃后，撰寫和設計測驗用例，設計開發測驗腳本，
自動化測驗用例的范圍往往是核心業務流程或者重復執行率較高的，并不需要覆寫所有的手工測驗用例，
自動化測驗用例的選擇一般以“正向”為主，正常情況即為“正向”，例外情況即為“反向”，功能自動化測驗主要還是用于回歸測驗，回歸測驗的目的就是保證新增功能后老功能是否能夠正常運作，
手工測驗用例可以不用回歸原點，而自動化用例往往是必須的，所謂回歸原點就是執行的測驗用例最終需要恢復其在執行前的初始狀態，比如添加用戶功能，由于用戶名是唯一的，第一次執行時沒有問題，第二次執行時程式就會出現用戶名重復而報錯；這種情況下，就需要在自動化測驗用例最后增加洗掉該用戶的步驟，
自動化測驗用例與手工測驗用例不同，不需要每個步驟都寫預期結果，
五.測驗檔案撰寫與缺陷管理
測驗檔案包括：測驗計劃檔案，測驗設計規格檔案，測驗用例，軟體缺陷報告，狀態報告，
測驗用例對一項特定的軟體產品進行測驗任務的描述，體現測驗方案、方法、技術和策略，內容包括測驗目標、測驗環境、輸入資料、測驗步驟、預期結果、測驗腳本等，并形成檔案，測驗用例一般包括驗證測驗用例和證偽測驗用例；驗證測驗用例用于驗證代碼是否按照預期執行，得到預期結果；證偽測驗用例驗證代碼是否對例外和錯誤條件進行了適當處理，
缺陷報告包括：問題/錯誤的簡單描述，重現的環境配置要求，保證多次精確重復的特定輸入，期望結果與實際結果的對比，優先級與嚴重性，對客戶的影響等，
六.常用的測驗工具
1. 功能測驗UFT
UFT自動化測驗的原理
封裝真實被測物件并轉化為UFT物件到物件庫，
對比物件庫里的物件鑒別屬性和運行時的真實被測物件的鑒別屬性，
對比結果一致，則說明物件成功匹配并可以繼續對該真實被測物件進行后續操作；如果不一致則報錯，提示物件無法識別，
2.封裝物件模型
在UFT里的封裝物件共分兩個概念，Test Objects（測驗物件，TO）和Runtime Objects（運行時物件，RO），TO就是被被添加到物件庫中的物件，RO就是被測驗軟體在運行實際所運行的物件，他們都是UFT封裝的物件，TO是為了識別RO而存在的，
UFT識別物件通常先在物件庫中添加測驗物件，然后在被測軟體運行的時候，根據腳本中呼叫的物件名稱，在物件庫中找到相應的測驗物件，并根據這些物件的特征屬性，在被測驗軟體中搜索相匹配的正在運行的物件，最后就可以對這些實際運行的測驗物件進行操作，
GetTOProperty()
基本含義：獲取物件庫中某個物件的某個屬性的值，
公式：ReturnValue = https://www.cnblogs.com/zhaoyingying123456/archive/2021/01/24/物件.GetTOProperty(“封裝屬性名”)
SetTOProperty()
基本含義：設定物件庫中某個物件的某個屬性的值，
公式：物件.SetTOProperty “封裝屬性名” “封裝屬性值”
注：使用代碼形式的修改物件屬性屬于臨時性的，只在腳本運行時有效，一旦腳本運行結束，物件庫里的屬性值就會還原，
GetROProperty()
基本含義：獲取實際運行時的某個物件的某個屬性的值，
公式：ReturnValue = https://www.cnblogs.com/zhaoyingying123456/archive/2021/01/24/物件.GetROProperty(“封裝屬性名”)
注：使用GetROProperty這個方法來動態獲取實際運行時的一些確認資訊，然后和所預期的測驗資料做對比，如注冊功能，在提交一些注冊資訊以后，一般都要到接下來的確認頁面去驗證一些資訊，這就可以使用GetROProperty來動態獲取實際運行時的一些確認資訊，
物件無法識別的解決辦法
設定虛擬物件，不推薦，虛擬物件非常脆弱，難以維護；即使物件沒有發生變化，但只要物件在界面是那個的方位發生變化，虛擬物件就會識別失敗，
使用相對坐標配合WSH去定位物件，
使用DOM組建介面應用技術，只適用于Web專案，
使用UFT自定義擴展SDK Customer來進行二次開發使UFT能夠識別物件，難度大，
開發提供專屬插件，
把無法識別的物件的一些方法封裝到一個dll中并使用UFT呼叫，
資料驅動與場景恢復
資料驅動Data Table的應用：實作測驗資料和腳本業務的分離，
場景恢復：場景恢復可以應對多種型別的錯誤并進行恢復操作，
3.性能測驗LoadRunner
LoadRunner是一種適用于各種體系架構的自動負載測驗工具，它能預測系統行為并優化系統性能，LoadRunner的測驗物件是整個企業的系統，它通過模擬實際用戶的操作行為和實時性能監測，來幫助測驗人員更快地查找和發現問題，
輕松創建虛擬用戶，Virtual User Generator能夠生成虛擬用于，以虛擬用戶的方式模擬真實用戶的業務操作行為，它先記錄下業務流程，然后將其轉化為測驗腳本，并進行引數化操作（Data Wizard直接連接資料服務器獲取資料），利用虛擬用戶可以在不同作業系統上同時產生成千上萬用戶訪問，能極大的減少負載測驗所需要的硬體和人力資源，
創建真實負載，建立虛擬用戶后，需要設定負載方案、業務流程組合和虛擬用戶數量，用Controller能夠很快地組織多用戶測驗方案，
定位性能問題，LoadRunner內含一個實時檢測器，在負載測驗程序的任何時候都能觀察到應用系統的運行性能，
分析結果，一旦測驗完畢，LoadRunner收集匯總所有的測驗資料，并提供高級的分析和報告工具，一遍迅速找到性能問題并做出相應的調整，
七.軟體測驗面試題總結
1.給你一個網站，你如何測驗？
首先，查找需求說明、網站設計等相關檔案，分析測驗需求，
制定測驗計劃，確定測驗范圍和測驗策略，一般包括以下幾個部分：功能性測驗；界面測驗；性能測驗；資料庫測驗；安全性測驗；兼容性測驗
功能性測驗可以包括，但不限于以下幾個方面：
鏈接測驗，鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯資訊回傳，
提交功能的測驗，
多媒體元素是否可以正確加載和顯示，
多語言支持是否能夠正確顯示選擇的語言等，
界面測驗可以包括但不限于一下幾個方面：
頁面是否風格統一，美觀
頁面布局是否合理，重點內容和熱點內容是否突出
控制元件是否正常使用
對于必須但未安裝的控制元件，是否提供自動下載并安裝的功能
文字檢查
性能測驗一般從以下兩個方面考慮：壓力測驗；負載測驗；強度測驗
資料庫測驗要具體決定是否需要開展，資料庫一般需要考慮連結性，對資料的存取操作，資料內容的驗證等方面，
安全性測驗：
基本的登錄功能的檢查
是否存在溢位錯誤，導致系統崩潰或者權限泄露
相關開發語言的常見安全性問題檢查，例如SQL注入等
如果需要高級的安全性測驗，確定獲得專業安全公司的幫助，外包測驗，或者獲取支持
兼容性測驗，根據需求說明的內容，確定支持的平臺組合：
瀏覽器的兼容性；
作業系統的兼容性；
軟體平臺的兼容性；
資料庫的兼容性
開展測驗，并記錄缺陷，合理的安排調整測驗進度，提前獲取測驗所需的資源，建立管理體系（例如，需求變更、風險、配置、測驗檔案、缺陷報告、人力資源等內容），
定期評審，對測驗進行評估和總結，調整測驗的內容，
2.在搜索引擎中輸入漢字就可以決議到對應的域名，請問如何用LoadRunner進行測驗，
建立測驗計劃，確定測驗標準和測驗范圍
設計典型場景的測驗用例，覆寫常用業務流程和不常用的業務流程等
根據測驗用例，開發自動測驗腳本和場景：
錄制測驗腳本：新建一個腳本（Web/HTML協議）；點擊錄制按鈕，在彈出的對話框的URL中輸入”about:blank”；在打開的瀏覽器中進行正常操作流程后，結束錄制；除錯腳本并保存，可能要注意到字符集的關聯，
設定測驗場景：針對性能設定測驗場景，主要判斷在正常情況下，系統的平均事務回應時間是否達標；針對壓力負載設定測驗場景，主要判斷在長時間處于滿負荷或者超出系統承載能力的條件下，系統是否會崩潰；執行測驗，獲取測驗結果，分析測驗結果，
3.一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務器施壓，有什么區別?
300個用戶在一個客戶端上，會占用客戶機更多的資源，而影響測驗的結果，執行緒之間可能發生干擾，而產生一些例外，300個用戶在一個客戶端上，需要更大的帶寬，
IP地址的問題，可能需要使用IP Spoof來繞過服務器對于單一IP地址最大連接數的限制，
所有用戶在一個客戶端上，不必考慮分布式管理的問題；而用戶分布在不同的客戶端上，需要考慮使用控制器來整體調配不同客戶機上的用戶，同時，還需要給予相應的權限配置和防火墻設定，
4.目前主要的測驗用例設計方法是什么？
白盒測驗：邏輯覆寫、回圈覆寫、基本路徑覆寫
黑盒測驗：邊界值分析法、等價類劃分、錯誤猜測法、因果圖法、狀態圖法、測驗大綱法、隨機測驗、場景法
5.軟體的安全性應從哪幾個方面去測驗？
軟體安全性測驗包括程式、資料庫安全性測驗，根據系統安全指標不同測驗策略也不同，
用戶認證安全的測驗要考慮問題： 明確區分系統中不同用戶權限 、系統中會不會出現用戶沖突 、系統會不會因用戶的權限的改變造成混亂 、用戶登陸密碼是否是可見、可 、是否可以通過絕對途徑登陸系統（拷貝用戶登陸后的鏈接直接進入系統）、用戶退出系統后是否洗掉了所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入系統 、系統網路安全的測驗要考慮問題 、測驗采取的防護措施是否正確裝配好，有關系統的補丁是否打上 、模擬非授權攻擊，看防護系統是否堅固 、采用成熟的網路漏洞檢查工具檢查系統相關漏洞（即用最專業的黑客攻擊工具攻擊試一下，現在最常用的是 NBSI 系列和 IPhacker IP ） 、采用各種木馬檢查工具檢查系統木馬情況 、采用各種防外掛工具檢查系統各組程式的外掛漏洞
資料庫安全考慮問題： 系統資料是否機密（比如對銀行系統，這一點就特別重要，一般的網站就沒有太高要求）、系統資料的完整性（我剛剛結束的企業實名核查服務系統中就曾存在資料的不完整，對于這個系統的功能實作有了障礙） 、系統資料可管理性 、系統資料的獨立性 、系統資料可備份和恢復能力（資料備份是否完整，可否恢復，恢復是否可以完整）
6.簡述什么是靜態測驗、動態測驗、黑盒測驗、白盒測驗、α測驗 β測驗
靜態測驗是不運行程式本身而尋找程式代碼中可能存在的錯誤或評估程式代碼的程序，
動態測驗是實際運行被測程式，輸入相應的測驗實體，檢查運行結果與預期結果的差異，判定執行結果是否符合要求，從而檢驗程式的正確性、可靠性和有效性，并分析系統運行效率和健壯性等性能，
黑盒測驗一般用來確認軟體功能的正確性和可操作性,目的是檢測軟體的各個功能是否能得以實作,把被測驗的程式當作一個黑盒,不考慮其內部結構,在知道該程式的輸入和輸出之間的關系或程式功能的情況下,依靠軟體規格說明書來確定測驗用例和推斷測驗結果的正確性，
白盒測驗根據軟體內部的邏輯結構分析來進行測驗,是基于代碼的測驗，測驗人員通過閱讀程式代碼或者通過使用開發工具中的單步除錯來判斷軟體的質量，一般黑盒測驗由專案經理在程式員開發中來實作，
α測驗是由一個用戶在開發環境下進行的測驗，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測驗，Alpha測驗不能由程式員或測驗員完成，
β測驗是軟體的多個用戶在一個或多個用戶的實際使用環境下進行的測驗，開發者通常不在測驗現場，Beta測驗不能由程式員或測驗員完成，
7.軟體測驗分為幾個階段，各階段的測驗策略和要求是什么?
和開發程序相對應，測驗程序會依次經歷單元測驗、集成測驗、系統測驗、驗收測驗四個主要階段：
單元測驗：單元測驗是針對軟體設計的最小單位––程式模塊甚至代碼段進行正確性檢驗的測驗作業，通常由開發人員進行，
集成測驗：集成測驗是將模塊按照設計要求組裝起來進行測驗，主要目的是發現與介面有關的問題，由于在產品提交到測驗部門前，產品開發小組都要進行聯合除錯，因此在大部分企業中集成測驗是由開發人員來完成的，
系統測驗：系統測驗是在集成測驗通過后進行的，目的是充分運行系統，驗證各子系統是否都能正常作業并完成設計的要求，它主要由測驗部門進行，是測驗部門最大最重要的一個測驗，對產品的質量有重大的影響，
驗收測驗：驗收測驗以需求階段的《需求規格說明書》為驗收標準，測驗時要求模擬實際用戶的運行環境，對于實際專案可以和客戶共同進行，對于產品來說就是最后一次的系統測驗，測驗內容為對功能模塊的全面測驗，尤其要進行檔案測驗，
單元測驗測驗策略：
自頂向下的單元測驗策略：比孤立單元測驗的成本高很多，不是單元測驗的一個好的選擇，
自底向上的單元測驗策略：比較合理的單元測驗策略，但測驗周期較長，
集成測驗的測驗策略：
大爆炸集成：適應于一個維護型專案或被測驗系統較小
自頂向下集成：適應于產品控制結構比較清晰和穩定；高層介面變化較小；底層介面未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為，
自底向上集成：適應于底層介面比較穩定；高層介面變化比較頻繁；底層組件較早被完成，
基于進度的集成
優點：具有較高的并行度；能夠有效縮短專案的開發進度，
缺點：樁和驅動作業量較大；有些介面測驗不充分；有些測驗重復和浪費，
系統測驗的測驗策略：資料和資料庫完整性測驗；功能測驗；用戶界面測驗；性能評測；負載測驗；強度測驗；容量測驗；安全性和訪問控制測驗；故障轉移和恢復測驗；配置測驗；安裝測驗；加密測驗；可用性測驗；版本驗證測驗；檔案測驗
8.軟體測驗各個階段通常完成什么作業？各個階段的結果檔案是什么？包括什么內容？
單元測驗階段：各獨立單元模塊在與系統地其他部分相隔離的情況下進行測驗，單元測驗針對每一個程式模塊進行正確性校驗，檢查各個程式模塊是否正確地實作了規定的功能，生成單元測驗報告，提交缺陷報告，
集成測驗階段：集成測驗是在單元測驗的基礎上，測驗在將所有的軟體單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的程序中各部分作業是否達到或實作相應技術指標及要求的活動，該階段生成集成測驗報告，提交缺陷報告，
系統測驗階段：將通過確認測驗的軟體，作為整個給予計算機系統的一個元素，與計算機硬體、外設、某些支持軟體、資料和人員等其他系統元素結合在一起，在實際運行環境下，對計算機系統進行全面的功能覆寫，該階段需要提交測驗總結和缺陷報告，
9.一條軟體缺陷（或者叫Bug）記錄都包含了哪些內容？
一條Bug記錄最基本應包含：
bug編號；
bug嚴重級別，優先級；
bug產生的模塊；
首先要有bug摘要，闡述bug大體的內容；
bug對應的版本；
bug詳細現象描述，包括一些截圖、錄像…等等；
bug出現時的測驗環境，產生的條件即對應操作步驟；
10.黑盒測驗和白盒測驗是軟體測驗的兩種基本方法，請分別說明各自的優點和缺點！
黑盒測驗的優點有：比較簡單，不需要了解程式內部的代碼及實作；與軟體的內部實作無關； 從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；基于軟體開發檔案，所以也能知道軟體實作了檔案中的哪些功能；在做軟體自動化測驗時較為方便，
黑盒測驗的缺點有：不可能覆寫所有的代碼，覆寫率較低，大概只能達到總代碼量的30%；自動化測驗的復用性較低，
白盒測驗的優點有：幫助軟體測驗人員增大代碼的覆寫率，提高代碼的質量，發現代碼中隱 藏的問題，
白盒測驗的缺點有：程式運行會有很多不同的路徑，不可能測驗所有的運行路徑；測驗基于代碼，只能測驗開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；系統龐大時，測驗開銷會非常大，
11.如何測驗一個紙杯？
功能度：用水杯裝水看漏不漏；水能不能被喝到
安全性：杯子有沒有毒或細菌
可靠性：杯子從不同高度落下的損壞程度
可移植性：杯子在不同的地方、溫度等環境下是否都可以正常使用
兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等
易用性：杯子是否燙手、是否有防滑措施、是否方便飲用
用戶檔案：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述
疲勞測驗：將杯子盛上水（案例一）放24小時檢查泄漏時間和情況；盛上汽油（案例二）放24小時檢查泄漏時間和情況等
壓力測驗：用根針并在針上面不斷加重量，看壓強多大時會穿透
12.黑盒測驗的測驗用例常見設計方法都有哪些？請分別以具體的例子來說明這些方法在測驗用例設計作業中的應用，
1.等價類劃分： 等價類是指某個輸入域的子集合.在該子集合中,各個輸入資料對于揭露程式中的錯誤都是等效的.并合理地假定:測驗某等價類的代表值就等于對這一類其它值的測驗.因此,可以把全部輸入資料合理劃分為若干等價類,在每一個等價類中取一個資料作為測驗的輸入條件,就可以用少量代表性的測驗資料.取得較好的測驗結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.
2.邊界值分析法：是對等價類劃分方法的補充，測驗作業經驗告訴我,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測驗用例,可以查出更多的錯誤.
使用邊界值分析方法設計測驗用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測驗的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測驗資料,而不是選取等價類中的典型值或任意值作為測驗資料.
3.錯誤猜測法：基于經驗和直覺推測程式中所有可能存在的各種錯誤, 從而有針對性的設計測驗用例的方法.
錯誤推測方法的基本思想: 列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測驗用例. 例如, 在單元測驗時曾列出的許多在模塊中常見的錯誤. 以前產品測驗中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入資料和輸出資料為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測驗用例.
4因果圖方法：前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 因此必須考慮采用一種適合于描述對于多種條件的組合,相應產生多個動作的形式來考慮設計測驗用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合于檢查程式輸入條件的各種組合情況.
5.正交表分析法：可能因為大量的引數的組合而引起測驗用例數量上的激增，同時，這些測驗用例并沒有明顯的優先級上的差距，而測驗人員又無法完成這么多數量的測驗，就可以通過正交表來進行縮減一些用例，從而達到盡量少的用例覆寫盡量大的范圍的可能性，
6.場景分析方法：指根據用戶場景來模擬用戶的操作步驟，這個比較類似因果圖，但是可能執行的深度和可行性更好，
7.狀態圖法：通過輸入條件和系統需求說明得到被測系統的所有狀態，通過輸入條件和狀態得出輸出條件；通過輸入條件、輸出條件和狀態得出被測系統的測驗用例，
8.大綱法：大綱法是一種著眼于需求的方法，為了列出各種測驗條件，就將需求轉換為大綱的形式，大綱表示為樹狀結構，在根和每個葉子結點之間存在唯一的路徑，大綱中的每條路徑定義了一個特定的輸入條件集合，用于定義測驗用例，樹中葉子的數目或大綱中的路徑給出了測驗所有功能所需測驗用例的大致數量，
9.詳細的描述一個測驗活動完整的程序，（供參考，本答案主要是瀑布模型的做法）
專案經理通過和客戶的交流，完成需求檔案，由開發人員和測驗人員共同完成需求檔案的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實作的功能的地方，專案經理通過綜合開發人員，測驗人員以及客戶的意見，完成專案計劃，然后SQA進入專案，開始進行統計和跟蹤
開發人員根據需求檔案完成需求分析檔案，測驗人員進行評審，評審的主要內容包括是否有遺漏或雙方理解不同的地方，測驗人員完成測驗計劃檔案，測驗計劃包括的內容上面有描述，
測驗人員根據修改好的需求分析檔案開始寫測驗用例，同時開發人員完成概要設計檔案，詳細設計檔案，此兩份檔案成為測驗人員撰寫測驗用例的補充材料，
測驗用例完成后，測驗和開發需要進行評審，
測驗人員搭建環境
開發人員提交第一個版本，可能存在未完成功能，需要說明，測驗人員進行測驗，發現BUG后提交給BugZilla，
開發提交第二個版本，包括Bug Fix以及增加了部分功能，測驗人員進行測驗，
重復上面的作業，一般是3-4個版本后BUG數量減少，達到出貨的要求，
如果有客戶反饋的問題，需要測驗人員協助重現并重新測驗，
13.說說你對集成測驗中自頂向下集成和自底向上集成兩個策略的理解，要談出它們各自的優缺點和主要適應于哪種型別測驗
自頂向下集成
優點：較早地驗證了主要控制和判斷點；按深度優先可以首先實作和驗證一個完整的軟體功能；功能較早證實，帶來信心；只需一個驅動，減少驅動器開發的費用；支持故障隔離，
缺點：柱的開發量大；底層驗證被推遲；底層組件測驗不充分，
適應于產品控制結構比較清晰和穩定；高層介面變化較小；底層介面未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為，
自底向上集成
優點：對底層組件行為較早驗證；作業最初可以并行集成，比自頂向下效率高；減少了樁的作業量；支持故障隔離，
缺點：驅動的開發作業量大；對高層的驗證被推遲，設計上的錯誤不能被及時發現，
適應于底層介面比較穩定；高層介面變化比較頻繁；底層組件較早被完成，
14.設計測驗用例時應該考慮哪些方面，即不同的測驗用例針對那些方面進行測驗？
設計測驗用例時需要注意的是，除了對整體流程及功能注意外，還要注意強度測驗、性能測驗、壓力測驗、邊界值測驗、穩定性測驗、安全性測驗等多方面，（測驗用例需要考慮的四個基本要素是輸入、輸出、操作和測驗環境；另外，測驗用例需要考慮的是測驗型別（功能、性能、安全……），這部分可以參照TP做答，此外，還需要考慮用例的重要性和優先級）
15.在windows下保存一個文本檔案時會彈出保存對話框，如果為檔案名建立測驗用例，等價類應該怎樣劃分？
單位元組，如A；雙位元組， AA、我我；特殊字符 /‘，‘；、=-等；保留字，如com；檔案格式為8.3格式的；檔案名格式為非8.3格式的；/,*等九個特殊字符，
假設有一個文本框要求輸入10個字符的郵政編碼，對于該文本框應該怎樣劃分等價類？
特殊字符，如10個*或￥；英文字母，如ABCDefghik；小于十個字符，如123；大于十個字符，如11；數字和其他混合，如123AAAAAAA；空字符；保留字符
16.單元測驗、集成測驗、系統測驗的側重點是什么？
單元測驗針對的是軟體設計的最小單元–程式模塊（面向程序中是函式、程序；面向物件中是類，）,進行正確性檢驗的測驗作業,在于發現每個程式模塊內部可能存在的差錯.一般有兩個步驟:人工靜態檢查\動態執行跟蹤
集成測驗針對的是通過了單元測驗的各個模塊所集成起來的組件進行檢驗,其主要內容是各個單元模塊之間的介面,以及各個模塊集成后所實作的功能.
系統測驗針對的是集成好的軟體系統，作為整個計算機系統的一個元素,與計算機硬體\外設\某些支持軟體\資料和人員等其他系統元素結合在一起,要在實際的運行環境中,對計算機系統進行一系列的集成測驗和確認測驗.
17.你所了解的的軟體測驗型別都有哪些，簡單介紹一下，
按測驗策略分類：1、靜態與動態測驗2、黑盒與白盒測驗 3、手工和自動測驗 4、冒煙測驗 5、回歸測驗；
按測驗階段分類：單元測驗、集成測驗、系統測驗；
其他常見測驗方法：1、功能測驗 2、性能測驗 3、壓力測驗 4、負載測驗 5、易用性測驗 6、安裝測驗 7、界面測驗 8、配置測驗 9、檔案測驗 10、兼容性測驗 11、安全性測驗 12、恢復測驗
18.您認為做好測驗用例設計作業的關鍵是什么？
白盒測驗用例設計的關鍵是以較少的用例覆寫盡可能多的內部程式邏輯結果
黑盒法用例設計的關鍵同樣也是以較少的用例覆寫模塊輸出和輸入介面，不可能做到完全測驗，以最少的用例在合理的時間內發現最多的問題
19. 一套完整的測驗應該由哪些階段組成？
可行性分析、需求分析、概要設計、詳細設計、編碼、單元測驗、集成測驗、系統測驗、驗收測驗
20. 面向物件的測驗用例設計有幾種方法？如何實作？
給類中的每個建構式設計一組測驗用例
組合類中的類變數、實體變數
組合類中的各種方法
根據前置條件和后置條件設計測驗用例
根據代碼設計測驗用例
在這里推薦一個我自己創建的軟體測驗交流群，qq :642830685，群中會不定期的分享軟體測驗資源，測驗面試題以及測驗行業資訊，大家可以在群中積極交流技術，風里雨里我在群中等你，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/251993.html
標籤：其他
上一篇：別讓假裝努力毀了你，最強的68道軟體測驗基礎問答題你能答的溜嘛？
下一篇：盤點.軟體測驗模型