本著共享主義，本人將PPT考點梳理出來，并且已經翻譯成中文，供大家參考，歡迎各位指導！
本次考試題型分為選擇、判斷、簡答和大題寫測試用例（Final Exam： 70%（閉卷考試））
所以考點既要把握細節，又要掌握大題和理解概念（文章結合PPT用電腦看合適）
軟件缺陷的概念
從產品內部看，軟件缺陷是產品開發或維護過程中所存在的錯誤、毛病等各種問題。
從產品外部看，軟件缺陷是系統所需要實現的某種功能的失效或者違背。
軟件測試的一個重要功能
verification(驗證）and validation(確認)
verification：驗證我們是不是正確的做了這個產品，也就是產品要符合他的目標
validation：確認我們是不是做了正確的產品，也就是產品是用戶真正想要的
軟件測試的目的
* 軟件測試是為了發現錯誤而執行程序的過程。
* 一個好的測試能過在第一時間發現程序中存在的錯誤。
* 一個好的測試是發現了至今尚未發現的錯誤。
* 減小軟件不能正常工作的風險
軟件測試的分類
C1:按照測試生成的來源
C2：按照生命周期的階段
C3：按照測試活動的目的
C4：按被測對象的特征
C5：按測試過程的模型
軟件測試V模型
軟件測試用例
輸入以測試系統和預測這些系統的輸出，如果系統根據其規范運作。
黑盒測試
等價類劃分
分為有效類和無效類，兩者不能有重疊的部分
例如：前亞利桑那州境內的一位步槍銷售商銷售密蘇里州制造的步槍機、槍托和槍管。槍機（Lock）賣45美元，槍托（Stock）賣30美元，槍管（Barrel）賣25美元。銷售商每月至少要銷售一支完整的步槍，且生產限額是大多數銷售商在一個月內可銷售70個槍機、80個槍托和90個槍管。每訪問一個鎮子之后，銷售商都給密蘇里州步槍制造商發出電報，說明在那個鎮子中售出的槍機、槍托和槍管數量。到了月末，銷售商要發出一封很短的電報，通知－1個槍機被售出。這樣步槍制造商就知道當月的銷售情況，并計算銷售商的傭金如下：銷售額不到（含）1000美元的部分為10％，1000（不含）～1800（含）美元的部分為15％，超過1800美元的部分為20％。傭金程序生成月份銷售報告，匯總售出的槍機、槍托和槍管總數，銷售商的總銷售額以及傭金。
有效等價類：
L1＝{Lock：1≤Lock≤70}
L2＝{Lock＝－1}
S1＝{Stock：1 ≤Stock≤80}
B1＝{Barrel ：1 ≤ Barrel ≤90}
無效等價類：
L3＝{Lock ： Lock ＝0 or Lock ﹤－1}
L4＝{Lock ： Lock ﹥70}
S2＝{Stock ： Stock ﹤1}
S3＝{Stock ： Stock ﹥80}
B2＝{Barrel ： Barrel ﹤1}
B3＝{Barrel：Barrel﹥90}
再例如：有一個報表處理系統，要求用戶輸入處理報表的日期。假如日期限制在2000年1月至2020年12月，即系統只能對該段時期內的報表進行處理。如果用戶輸入的日期不在這個范圍內，則顯示“錯誤信息”。并且此系統規定日期由年月的6位數字組成，前四位代表年，后兩位代表月。
要求：
寫出日期的等價類劃分。
生成測試用例。
生成測試用例
邊緣值分析法
基本原理
如下圖取值
注意：邊界值分析法是單一錯誤原則
舉例說明：
三角形問題，輸入a、b、c
1 ≤ a ≤ 200
1 ≤ b ≤ 200
1 ≤ c ≤ 200
所以a,b,c的取值是
a = {1，2，100，199，200}
b = {1，2，100，199，200}
c = {1，2，100，199，200}
測試用例如下
小節總結
等價類測試的弱形式不如強形式測試全面。
無效值會引起運行錯誤的時候（實現語言是強類型），則沒有必要做健壯形式的測試。
錯誤條件很重要的時候，健壯測試很重要。
邊界值測試是等價類測試的一種補充，兩者結合可以加強測試效果。
決策表技術可以解決變量之間依賴的問題。
要進行多次嘗試，確認最合適的等價類劃分。
正交測試
正交測試http://www.lxweimin.com/writer#/notebooks/11085322/notes/10481239
Decision Tables（決策表）
先來感受一波決策表吧（特別注意，結果能合并的一定要合并！！！）
決策表有四個部分
Stub portion、Entry portion、Condition portion、Action portion
從問題決策到結果，Y代表條件滿足，N代表條件不滿足，--代表忽略這個條件
練習：
某貨運站收費標準如下：如果收件地點在本省，則快件每公斤5元，慢件每公斤3元；如果收件地點在省外，則在20公斤以內（含20公斤）快件每公斤7元，慢件每公斤5元，而超過20公斤時，快件每公斤9元，慢件每公斤7元。請用決策表方法解決此問題。
第一步：確定規則的數目。
條件：
（1）收件地在本省？
（2）是快件？
（3）重量不超過20公斤？
根據公式計算2的3次方＝8
所以應有8條規則。
第二步：列出所有的條件樁和行動樁。
第三步：填入條件條目
第四步：填入行動條目
第五步：化簡決策表（一定要合并簡化）
Cause-Effect Graphing （因果圖）
因果圖法產生的背景
等價類劃分法和邊界值分析方法都是著重考慮輸入條件，但沒有考慮輸入條件的各種組合、輸入條件之間的相互制約關系。這樣雖然各種輸入條件可能出錯的情況已經測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了。
如果在測試時必須考慮輸入條件的各種組合，則可能的組合數目將是天文數字，因此必須考慮采用一種適合于描述多種條件的組合、相應產生多個動作的形式來進行測試用例的設計，這就需要利用因果圖（邏輯模型）。
因果圖概念介紹
因果圖（Cause-EffectGraphing）提供了一個把規格轉化為判定表的系統化方法，從該圖中可以產生測試數據。其中原因是表示輸入條件，結果是對輸入執行的一系列計算后得到的輸出。因果圖方法最終生成的就是判定表，它適合于檢查程序輸入條件的各種組合情況。
因果圖中基本符號介紹（這里可以看PPT，不全部列出）
因果圖分析步驟
第一步，找出Cause（原因）
Cause（原因）
c1— the first character is #
c2 —the first character is *
c3 —the second character is number
第二步，找出Effect（結果）
e1— give the information N
e2— modify the document
e3— give the information M
第三步，分析出中間節點
然后畫出因果圖，如圖
再舉個例子
某公司對客戶有一定的折扣政策，公司軟件的一個模塊的需求說明書中描述“……當交易額小于等于5萬元時折扣為0，當交易額大于5萬元時才有折扣，如果交易的客戶在三個月內無欠款，則折扣為15%；如果交易用戶在三個月內有欠款，若該用戶是三年以上的老客戶，則折扣為10%；若該客戶不是三年以上的老客戶，則折扣為5%。”
原因（對立的就不要再寫了，比如寫了是小于五萬就不用寫大于等于五萬了）：
C1：交易額大于5萬元
C2：三個月無欠款
C3：三年以上老客戶
結果（注意對立的就不要再寫了）：
E1：無折扣
E2：折扣=5%
E3：折扣=10%
E4：折扣=15%
因果圖，從這個圖中你就能找出導出上邊說的四種結果的邏輯
白盒測試（White-box testing）
白盒測試也叫structural testing, clear box testing, and glass box testing.
白盒測試分為靜態測試和動態測試
白盒靜態測試：Code inspection, Static structure analysis, Static quality metric method
白盒動態測試：主要基于覆蓋，包括logic coverage, loop coverage, basis path coverage, etc.
白盒測試主要應用于單元測試
we can’t use exhaustive（詳盡的） testing
動態測試之邏輯覆蓋
白盒測試用例設計的一個很重要的評估標準就是對代碼的覆蓋度。一說到覆蓋，大家都感覺非常熟悉，但是常見的覆蓋都有哪些？各自有什么優缺點？在白盒測試的用例設計中我們應該如何自如地運用呢？為大家總結了一下幾種常見的覆蓋以及各自的優缺點。
白盒測試中常見的覆蓋有六種：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、組合覆蓋和路徑覆蓋。下面我們就分別看看這幾種不同的覆蓋究竟是什么鬼。
一、語句覆蓋（Statement Coverage）
語句覆蓋，顧名思義就是針對代碼語句的嘛。它的含義是我們設計出來的測試用例要保證程序中的每一個語句至少被執行一次。通常語句覆蓋被認為是“最弱的覆蓋”，原因是它僅僅考慮對代碼中的執行語句進行覆蓋而沒有考慮各種條件和分支，因此在實際運用中語句覆蓋很難發現代碼中的問題。舉個非常簡單的例子：
public int foo(int a,int b)
{
return a/b;
}
這是一個求兩數之商的函數。如果我們設計如下的測試用例：
TestCase: a = 2, b = 1
這時候我們會發現，該函數的代碼覆蓋率達到了100%，并且設計的case可以順利通過測試。但是顯然該函數有一個很明顯的bug：當 b=0 時，會拋出異常。
再來看這個例子：
主要特點：語句覆蓋是最起碼的結構覆蓋要求，語句覆蓋要求設計足夠多的測試用例，使得程序中每條語句至少被執行一次。
用例設計：（如果此時將A路徑上的語句1—〉T去掉，那么用例如下）
優點：可以很直觀地從源代碼得到測試用例，無須細分每條判定表達式。
缺點：由于這種測試方法僅僅針對程序邏輯中顯式存在的語句，但對于隱藏的條件和可能到達的隱式邏輯分支，是無法測試的。在本例中去掉了語句1—〉T去掉，那么就少了一條測試路徑。在if結構中若源代碼沒有給出else后面的執行分支，那么語句覆蓋測試就不會考慮這種情況。但是我們不能排除這種以外的分支不會被執行，而往往這種錯誤會經常出現。再如，在Do-While結構中，語句覆蓋執行其中某一個條件分支。那么顯然，語句覆蓋對于多分支的邏輯運算是無法全面反映的，它只在乎運行一次，而不考慮其他情況。
二、判定覆蓋（Decision Coverage）
判定覆蓋也被成為分支覆蓋(Branch Coverage)，也就是說設計的測試用例要保證讓被測試程序中的每一個分支都至少執行一次。舉個例子,有如下流程圖：
針對該圖我們想要做到判定覆蓋，可以設計如下case：
TestCase1: a=1, b=1 ?(路徑：ab)
TestCase2: a=-1, b=-1 ?(路徑：acd)
TestCase3: a=2, b=-1 ?(路徑：ace)
判定覆蓋比語句覆蓋強一些，能發現一些語句覆蓋無法發現的問題。但是往往一些判定條件都是由多個邏輯條件組合而成的，進行分支判斷時相當于對整個組合的最終結果進行判斷，這樣就會忽略每個條件的取值情況，導致遺漏部分測試路徑。
同樣上邊流程圖1例子也一樣
用例設計
優點：判定覆蓋比語句覆蓋要多幾乎一倍的測試路徑，當然也就具有比語句覆蓋更強的測試能力。同樣判定覆蓋也具有和語句覆蓋一樣的簡單性，無須細分每個判定就可以得到測試用例。
缺點：往往大部分的判定語句是由多個邏輯條件組合（也就是可能if(a==b&&c==d)這種的邏輯組合）而成（如，判定語句中包含AND、OR、CASE），若僅僅判斷其整個最終結果，而忽略每個條件的取值情況，必然會遺漏部分測試路徑。
三、條件覆蓋（Condition Coverage）
條件覆蓋于分支覆蓋不同，條件覆蓋要求所設計的測試用例能使每個判定中的每一個條件都獲得可能的取值，即每個條件至少有一次真值、有一次假值。
仍然以上面流程圖2作為例子來說明。上圖中涉及到的條件一共有4個：
a>0, a<0, b>0, b<0
為了達到條件覆蓋的目的，我們設計的用例需要在 a 點有：
a>0, a≤0, b>0, b≤0，
這些情況出現，并且在 c 點有：
a<0, a≥0, b<0, b≥0
這些情況出現。現在可以設計如下用例：
TestCase1: a=1, b=1 ?(路徑：ab)
TestCase1: a=-1, b=-1 ?(路徑：acd)
TestCase1: a=-1, b=0 ?(路徑：ace)
TestCase1: a=1, b=-1 ?(路徑：ace)
通常而言條件覆蓋比判定覆蓋強，因為條件覆蓋使得判定中的每一個條件都取到了不同的結果，這一點判定覆蓋則無法保證。但條件覆蓋也有缺陷，因為它只能保證每個條件都取到了不同結果，但沒有考慮到判定結果，因此有時候條件覆蓋并不能保證判定覆蓋。
優點：顯然條件覆蓋比判定覆蓋，增加了對符合判定情況的測試，增加了測試路徑。
缺點：要達到條件覆蓋，需要足夠多的測試用例，但條件覆蓋并不能保證判定覆蓋。條件覆蓋只能保證每個條件至少有一次為真，而不考慮所有的判定結果。
四、判定條件覆蓋（Decision/Condition Coverage）
以流程圖1為例
主要特點：設計足夠多的測試用例，使得判定中每個條件的所有可能結果至少出現一次，每個判定本身所有可能結果也至少出現一次。
優點：判定/條件覆蓋滿足判定覆蓋準則和條件覆蓋準則，彌補了二者的不足。
缺點：判定/條件覆蓋準則的缺點是未考慮條件的組合情況。
五、組合覆蓋（Branch Condition Combination Coverage）
組合覆蓋也叫做條件組合覆蓋。意思是說我們設計的測試用例應該使得每個判定中的各個條件的各種可能組合都至少出現一次。顯然，滿足條件組合覆蓋的測試用例一定是滿足判定覆蓋、條件覆蓋和判定條件覆蓋的。
主要特點：要求設計足夠多的測試用例，使得每個判定中條件結果的所有可能組合至少出現一次。
針對前文提到的流程圖2，做條件組合覆蓋時我們可以設計如下用例：
TestCase1: a=1, b=1 ?(路徑：ab)
TestCase1: a=-1, b=-1 ?(路徑：acd)
TestCase1: a=-1, b=0 ?(路徑：ace)
TestCase1: a=1, b=-1 ?(路徑：ace)
針對流程圖1
優點：多重條件覆蓋準則滿足判定覆蓋、條件覆蓋和判定/條件覆蓋準則。更改的判定/條件覆蓋要求設計足夠多的測試用例，使得判定中每個條件的所有可能結果至少出現一次，每個判定本身的所有可能結果也至少出現一次。并且每個條件都顯示能單獨影響判定結果。
缺點：線性地增加了測試用例的數量。
六、路徑覆蓋
路徑覆蓋，意思是說我們設計的測試用例可以覆蓋程序中所有可能的執行路徑。這種覆蓋方法可以對程序進行徹底的測試用例覆蓋，比前面講的五種方法覆蓋度都要高。那么這種方法是不是就一定最好呢？當然不能講得這么絕對，它的缺點也是顯而易見的：由于需要對所有可能的路徑全部進行覆蓋，那么我們需要設計數量非常巨大的而且較為復雜的測試用例，用例數量將呈現指數級的增長。所以理論上來講路徑覆蓋是最徹底的測試用例覆蓋，但實際上很多時候路徑覆蓋的可操作性不強。
針對流程圖1
優點：這種測試方法可以對程序進行徹底的測試，比前面五種的覆蓋面都廣。
缺點：由于路徑覆蓋需要對所有可能的路徑進行測試（包括循環、條件組合、分支選擇等），那么需要設計大量、復雜的測試用例，使得工作量呈指數級增長。而在有些情況下，一些執行路徑是不可能被執行的
總結
以上簡單描述了幾種不用的邏輯覆蓋方法的原則和優劣。在實際的操作中，要正確使用白盒測試的代碼覆蓋方法，就要從代碼分析和代碼調研入手，根據調研的結果，可以選擇上述方法中的某一種，或者好幾種方法的結合，設計出高效的測試用例，盡可能全面地覆蓋到代碼中的每一個邏輯路徑。
控制流程圖和圈復雜度
常見控制流圖
將上訴程序轉化成控制流圖
圈復雜度=判定節點數+1
練習1：
計算下圖的圈復雜度
標識它的獨立路徑
獨立路徑是指程序中至少引進一個新的處理語句集合，采用流圖的術語，即獨立路徑必須至少包含一條在定義路徑之前不曾用到的邊。
獨立路徑數=判定節點數（4）+1= 5
獨立路徑數= e – n + 1 = 11 – 7 + 1 = 5
獨立路徑：
ABCFG
ABDFG
ABEFG
ABCDFG
ABEDFGABDFG
再比如
獨立路徑
路徑1：1-11
路徑2：1-2-3-4-5-10-1-11
路徑3：1-2-3-6-8-9-10-11
路徑4：1-2-3-6-7-9-10-1-11
V=3個判定節點+1=4（圈復雜度）
由此為了覆蓋所有程序語句，必須設計至少4個測試用例使程序運行于這4條路徑。
循環測試
路徑覆蓋法是一種將程序中循環結構簡化成選擇結構的測試方法。
循環簡化的目的是限制循環次數，無論循環的形式和循環體實際執行的次數，簡化后的循環測試只考慮循環一次或者零次兩種情況。
在這種情況下，循環與判定分支的效果是一樣的，即循環要么執行，要么跳過。
采用較復雜的循環測試策略測試循環，可采用下面測試集：
跳過整個循環；
只循環一次；
只循環兩次；
循環m次，m
數據流測試...
突變測試（Mutation Testing）
突變測試(mutation testing) , 或稱作突變分析、程序突變，它是用于衡量軟件測試的質量。突變測試通常對程序的源代碼或者目標代碼做小的改動，并把截然不同的錯誤行為（或者怪異行為）作為預期。如果測試代碼沒有覺察到這種小改動帶來的錯誤，就說明這個測試是有問題的。
突變測試目的：Help testers design high quality tests
Evaluate the quality of existing tests
突變測試范圍
unit level、integration level、specification level
下面用一個例子來解釋什么是變異測試，考慮以下代碼片段：
if(a && b) c = 1;
else c = 0;
條件運算符如果用||來替換&&，就會產生以下變異：
if(a || b) c = 1;
else c = 0;
為了殺死這個突變，需要滿足以下條件：
（1）測試數據必須對突變和原始程序引起的不同狀態覆蓋。如：a=1,b=0可以達到目的。
（2）c的值應該傳播到程序輸出，并被測試檢查。
弱突變覆蓋需滿足（1），強突變覆蓋需滿足（1）（2）。
1 變異測試理論
1.1 兩個基本假設
變異測試旨在找出有效的測試用例，發現程序中真正的錯誤。在一個工程中，潛在BUG的數量是巨大的，通過生成突變體來全面覆蓋所有的錯誤是不可能的。所以，傳統的變異測試旨在尋找這些錯誤的子集，能盡量充分地近似描述這些BUG。這個理論基于兩條假設：Competent
Programmer Hypothesis(CPH) 和 Coupling Effect(CE)。
CPH是指：假設編程人員是有能力的，他們盡力去更好地開發程序，達到正確可行的結果，而不是搞破壞。它關注的是程序員的行為和意圖。而CE(耦合效應)更加關注在變異測試中錯誤的類別。一個簡單的錯誤產生往往是由于一個單一的變異（例如句法錯誤），而一個龐大復雜的錯誤往往是由于多出變異所導致。復雜變異體往往是由諸多簡單變異體組合而成。
變異測試流程
在變異測試中，對于被測程序p，設定一個測試用例集合T。首先根據被測程序特征設定一系列變異算子；隨后通過在原有程序p上，執行變異算子生成大量變異體；接著從大量變異體中識別出等價變異體；然后在剩余的非等價變異體上執行測試用例集T中的測試用例，若可以檢測出所有非等價變異體，則變異測試分析結束，否則對未檢測出的變異體，需要額外設計新的測試用例，并添加到測試用例集T中。
定義 1（變異算子）
在符合語法規則前提下， 變異算子定義了從原有程序生成差別極小程序（即變異體）
的轉換規則。下表給出了一個典型的變異算子， 該變異算子將“＋” 操作符變異為 “-” 操作符。選擇被測程序 p 中的條件表達式 a + b
> c 執行該變異算子， 將得到條件表達式 a - b > c ， 并生成變異體 p′ 。
定義 2（一階變異體）
在原有程序p上執行單一變異算子并形成變異體p′ ，則稱p′為p的一階變異體。
定義3（高階變異體）
在原有程序 p 上依次執行多次變異算子并形成變異體 p′ ，則稱 p′ 為 p 的高階變異體。若在 p 上依次執行 k 次變異算子并形成變異體 p′ ， 則稱 p′ 為 p 的 k 階變異體。
定義 4（可殺除變異體）
若存在測試用例t，在變異體p′ 和原有程序p上的執行結果不一致， 則稱該變異體p′ 相對于測試用例集T是可殺除變異體。
定義 5（可存活變異體）
若不存在任何測試用例t， 在變異體p′ 和原有程序p上的執行結果不一致， 則稱該變異體p′ 相對于測試用例集T是可存活變異體。一部分可存活變異體通過設計新的測試用例可以轉化成可殺除變異體，
剩余的可存活變異體則可能是等價變異體。本文對等價變異體定義如下。
定義 6（等價變異體）
若變異體p′ 與原有程序p在語法上存在差異， 但在語義上與p保持一致， 則稱p′ 是p的等價變異體。
單元測試（Unit Testing）
單元測試是最小的測試部分，測試模塊是獨立于其他模塊的，一般情況下，被測單元能夠實現一個特定的功能，并與其他單元有明確的接口定義，這樣才可以與其他單元隔離開來。
In Java, a unit is a class or a class method.
In C, a unit is a function or sub processes.
目標：確保模塊被正確的編碼
依據：系統詳細的規格說明
過程：經過設計、腳本開發、執行、調試和分析結果一個過程
執行者：由程序開發人員和測試人員共同完成
方法：以白盒測試方法為主，輔以黑盒測試方法
如何進行評估：通過所有單元測試用例，代碼沒有嚴重缺陷
單元測試過程
1、在詳細設計階段完成單元測試計劃
2、建立單元測試環境，完成測試設計和開發
3、執行單元測試用例，并且詳細記錄測試結果
4、判定單元測試是否通過
5、提交單元測試報告
單元測試優點
1、單獨進行，一起進行，降低軟件質量成本，縮短開發周期；
2、便于跟蹤錯誤；
3、集成后錯誤會放大，集成后復雜性高，很難發現問題；
4、無需而外的設備和人員。
單元測試分為靜態測試和動態測試
靜態測試
代碼評審：代碼走查和正式會議審查。
代碼走查：代碼互查應用最多，代碼走查是相對比較正式的評審過程，項目組部分成員通過閱讀代碼，向其他成員提出問題并對有關技術、風格、可能錯誤是否違背開發標準和規范等進行評論。
正式會議審查：是一種正式的檢查和評估方法，最早由IBM提出，經實踐證明，有一種有效的檢查辦法，從而得到軟件工程界的普遍認同。它使用逐步檢查源代碼中有無邏輯或語法錯誤的辦法來檢驗故障。
集成測試（Integration Testing）（集成測試、組裝測試、聯合測試、子系統測試、部件測試）
優點：早點發現錯誤，早點修正錯誤，早點獲得測試反饋，調度修正錯誤靈活
分為增量式測試和非增量式測試
測試模式
Big bang（大爆炸） integration
優點：完成速度快、能夠并行
缺點：錯誤發生時很難找出他的位置和改變以及很多問題得在系統測試才能發現
適用范圍：Existing system with only minor modifications
Small systems with adequate unit testing
System made from certified high quality reusable components
Top-down （自頂向下）integration
分為廣度和深度集成測試
Advantage
Early show main points of control and judgments.
Use depth-first assembly, and a complete software function can be firstly implemented and validated.
Only one driver module is needed at most.
Support fault isolation.
Disadvantage
The costs of the development and the maintenance of stubs are both higher.
Bottom level components demand can not be predicted may lead to many amendments to the top level components.
Bottom-up （自底向上）integration
Advantage
Allow conducting early certification for bottom modules, any leaf node is ready for integration testing can be tested.
Reduce workload of stub development
Support fault isolation
Disadvantage
Driver module development huge workload comparison.
Senior validation was deferred until the end, design error can not be found in time.
Bottom abnormal hard cover.
Sandwich（三明治） integration
Advantage
Combine the advantage of top-down strategy and bottom-up strategy.
Disadvantage
The testing of middle level is insufficient before integration testing.
Scope
It is used by the majority of software development projects.
Layers（分層） integration
High-frequency （高頻）integration
Event-based（基于事件） integration
System testing（系統測試）
目的:測試可安裝性、可用性、兼容性、可維護性等等
Performance Testing(性能測試)
性能是量度系統或組件在一定約束條件下，是否達到功能設計的指標：如響應速度，計算的精度，內存利用率。
性能是系統外部的質量屬性基于用戶的需求和用戶的系統操作性的看法。
同時性能特別應用于對實時系統的評價當中,就是它的行為在指定的期限內完成正確的操作。
評估指標為時間效率，空間效率，I∕O性能，數據庫性能，內存性能，初始化∕退出時間和資源利用率延時，事務處理時間，最大事務處理時間，事務操作時間，數據庫性能，最大消耗的內存量，高峰內存時間，資源消耗。
下圖描述了web應用的頁面響應時間的分解。
頁面響應時間分解為網絡傳輸時間（N1+N2+N3+N4）和應用延遲時間（A1+A2+A3），
而應用延遲時間又可分為數據庫延遲時間（A2）和應用服務器延遲時間（A1+A3）。
延遲：一個指令控制器發出數據請求的一瞬間和數據傳送的一瞬間之間的時間間隔;是請求和完成操作之間拖延的時間差。
事務處理時間：是指完成一項事務所需要的運行時間，用于評價事務處理效率。通常，事務處理的時間越短，則效率越高。
并發用戶數，一般分兩種情況：
嚴格意義的并發，即所有用戶在同一時間做同一件事情或者操作。
廣義范圍的并發，多個用戶對系統發出了請求或進行了操作，但這些操作可以是相同的，也可以是不同的。
吞吐量：是指在一次性能測試過程中網絡上傳輸數據量的總和。
一般來說，吞吐量用請求數/秒或頁面數/秒來衡量。
吞吐量指標有如下兩個作用：
1、協助設計性能測試場景，衡量性能測試場景是否達到了預期的設計目標。
在設計性能測試場景時，根據估算吞吐量數據測試場景事物發生頻率。
2、協助分析性能測試瓶頸。
性能測試比較關注業務并發用戶數，從業務的角度設置多少并發數合理。
下面給出估算并發用戶數的公式：C=nL／T
C —平均的并發用戶數
n —登錄會話的數量
L —登錄會話的平均長度
T —考察的時間段長度
例題：
一個軟件系統每天約有400個用戶訪問。用戶在一天之內有8小時內使用該系統，從登錄到退出的平均時間為4小時，請計算該系統的并發用戶數和并發用戶的峰值各是多少？
分析：根據公式C=400×4／8=200
負載測試是模擬實際軟件系統所承受的負載條件的系統負荷，通過不斷加載（不斷增加模擬用戶數量）或其他加載方式來觀察不同負載下系統響應時間和數據吞吐量，系統資源占有率（cpu和內存）等性能指標，以檢驗系統的行為和特性，發現系統可能存在的性能瓶頸、內存泄露和不能實現同步等問題。
高低突變加載：某個時間用戶數量很大，突然降到很低，過一段時間，又突然加到很高，反復幾次。借助這種負載方式的測試，容易發現資源的釋放和內存泄漏的問題。
隨機加載方式：由隨機算法自動生成某個數量范圍內變化的、動態的負載，這種方式可能是和實際情況最為接近的一種負載方式。雖然不容易模擬系統運行出現的瞬間高峰期，但可以模擬系統長時間的運行過程的狀態。
壓力測試用于判定應用處理大量數據的能力。
壓力測試可以成功的測試服務器滿負載的情況。
除了在服務器上增加運行的應用結合客戶端測試是一種額外的形式的壓力測試。
性能測試過程：計劃，記錄，修改，執行，分析
