本著共享主義班套，本人將PPT考點(diǎn)梳理出來，并且已經(jīng)翻譯成中文吹菱，供大家參考巍虫，歡迎各位指導(dǎo)！
本次考試題型分為選擇鳍刷、判斷占遥、簡答和大題寫測試用例（Final Exam： 70%（閉卷考試））
所以考點(diǎn)既要把握細(xì)節(jié)，又要掌握大題和理解概念（文章結(jié)合PPT用電腦看合適）
軟件缺陷的概念
從產(chǎn)品內(nèi)部看输瓜，軟件缺陷是產(chǎn)品開發(fā)或維護(hù)過程中所存在的錯誤瓦胎、毛病等各種問題。
從產(chǎn)品外部看尤揣，軟件缺陷是系統(tǒng)所需要實(shí)現(xiàn)的某種功能的失效或者違背搔啊。
軟件測試的一個重要功能
verification(驗(yàn)證）and validation(確認(rèn))
verification：驗(yàn)證我們是不是正確的做了這個產(chǎn)品，也就是產(chǎn)品要符合他的目標(biāo)
validation：確認(rèn)我們是不是做了正確的產(chǎn)品北戏，也就是產(chǎn)品是用戶真正想要的
軟件測試的目的
* 軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程负芋。
* 一個好的測試能過在第一時間發(fā)現(xiàn)程序中存在的錯誤。
* 一個好的測試是發(fā)現(xiàn)了至今尚未發(fā)現(xiàn)的錯誤嗜愈。
* 減小軟件不能正常工作的風(fēng)險
軟件測試的分類
C1:按照測試生成的來源
C2：按照生命周期的階段
C3：按照測試活動的目的
C4：按被測對象的特征
C5：按測試過程的模型
軟件測試V模型
軟件測試用例
輸入以測試系統(tǒng)和預(yù)測這些系統(tǒng)的輸出旧蛾，如果系統(tǒng)根據(jù)其規(guī)范運(yùn)作。
黑盒測試
等價類劃分
分為有效類和無效類蠕嫁，兩者不能有重疊的部分
例如：前亞利桑那州境內(nèi)的一位步槍銷售商銷售密蘇里州制造的步槍機(jī)锨天、槍托和槍管。槍機(jī)（Lock）賣45美元拌阴，槍托（Stock）賣30美元绍绘，槍管（Barrel）賣25美元。銷售商每月至少要銷售一支完整的步槍迟赃，且生產(chǎn)限額是大多數(shù)銷售商在一個月內(nèi)可銷售70個槍機(jī)陪拘、80個槍托和90個槍管。每訪問一個鎮(zhèn)子之后纤壁，銷售商都給密蘇里州步槍制造商發(fā)出電報左刽，說明在那個鎮(zhèn)子中售出的槍機(jī)、槍托和槍管數(shù)量酌媒。到了月末欠痴，銷售商要發(fā)出一封很短的電報迄靠，通知－1個槍機(jī)被售出。這樣步槍制造商就知道當(dāng)月的銷售情況喇辽，并計(jì)算銷售商的傭金如下：銷售額不到（含）1000美元的部分為10％掌挚，1000（不含）～1800（含）美元的部分為15％，超過1800美元的部分為20％菩咨。傭金程序生成月份銷售報告吠式，匯總售出的槍機(jī)、槍托和槍管總數(shù)抽米，銷售商的總銷售額以及傭金特占。
有效等價類：
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}
再例如：有一個報表處理系統(tǒng)，要求用戶輸入處理報表的日期云茸。假如日期限制在2000年1月至2020年12月是目，即系統(tǒng)只能對該段時期內(nèi)的報表進(jìn)行處理。如果用戶輸入的日期不在這個范圍內(nèi)标捺，則顯示“錯誤信息”懊纳。并且此系統(tǒng)規(guī)定日期由年月的6位數(shù)字組成栅盲，前四位代表年芋类，后兩位代表月。
要求：
寫出日期的等價類劃分霍弹。
生成測試用例萍倡。
生成測試用例
邊緣值分析法
基本原理
如下圖取值
注意：邊界值分析法是單一錯誤原則
舉例說明：
三角形問題身弊，輸入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}
測試用例如下
小節(jié)總結(jié)
等價類測試的弱形式不如強(qiáng)形式測試全面备籽。
無效值會引起運(yùn)行錯誤的時候（實(shí)現(xiàn)語言是強(qiáng)類型），則沒有必要做健壯形式的測試分井。
錯誤條件很重要的時候车猬，健壯測試很重要霉猛。
邊界值測試是等價類測試的一種補(bǔ)充，兩者結(jié)合可以加強(qiáng)測試效果珠闰。
決策表技術(shù)可以解決變量之間依賴的問題惜浅。
要進(jìn)行多次嘗試，確認(rèn)最合適的等價類劃分伏嗜。
正交測試
正交測試http://www.reibang.com/writer#/notebooks/11085322/notes/10481239
Decision Tables（決策表）
先來感受一波決策表吧（特別注意赡矢，結(jié)果能合并的一定要合并！Ｔ淖小！）
決策表有四個部分
Stub portion弧械、Entry portion八酒、Condition portion、Action portion
從問題決策到結(jié)果刃唐，Y代表?xiàng)l件滿足羞迷，N代表?xiàng)l件不滿足，--代表忽略這個條件
練習(xí)：
某貨運(yùn)站收費(fèi)標(biāo)準(zhǔn)如下：如果收件地點(diǎn)在本省画饥，則快件每公斤5元衔瓮，慢件每公斤3元；如果收件地點(diǎn)在省外抖甘，則在20公斤以內(nèi)（含20公斤）快件每公斤7元热鞍，慢件每公斤5元，而超過20公斤時衔彻，快件每公斤9元薇宠，慢件每公斤7元。請用決策表方法解決此問題艰额。
第一步：確定規(guī)則的數(shù)目澄港。
條件：
（1）收件地在本省柄沮？
（2）是快件回梧？
（3）重量不超過20公斤？
根據(jù)公式計(jì)算2的3次方＝8
所以應(yīng)有8條規(guī)則祖搓。
第二步：列出所有的條件樁和行動樁狱意。
第三步：填入條件條目
第四步：填入行動條目
第五步：化簡決策表（一定要合并簡化）
Cause-Effect Graphing （因果圖）
因果圖法產(chǎn)生的背景
等價類劃分法和邊界值分析方法都是著重考慮輸入條件，但沒有考慮輸入條件的各種組合棕硫、輸入條件之間的相互制約關(guān)系髓涯。這樣雖然各種輸入條件可能出錯的情況已經(jīng)測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了哈扮。
如果在測試時必須考慮輸入條件的各種組合纬纪，則可能的組合數(shù)目將是天文數(shù)字蚓再，因此必須考慮采用一種適合于描述多種條件的組合、相應(yīng)產(chǎn)生多個動作的形式來進(jìn)行測試用例的設(shè)計(jì)包各，這就需要利用因果圖（邏輯模型）摘仅。
因果圖概念介紹
因果圖（Cause-EffectGraphing）提供了一個把規(guī)格轉(zhuǎn)化為判定表的系統(tǒng)化方法，從該圖中可以產(chǎn)生測試數(shù)據(jù)问畅。其中原因是表示輸入條件娃属，結(jié)果是對輸入執(zhí)行的一系列計(jì)算后得到的輸出。因果圖方法最終生成的就是判定表护姆，它適合于檢查程序輸入條件的各種組合情況矾端。
因果圖中基本符號介紹（這里可以看PPT，不全部列出）
因果圖分析步驟
第一步卵皂，找出Cause（原因）
Cause（原因）
c1— the first character is #
c2 —the first character is *
c3 —the second character is number
第二步秩铆，找出Effect（結(jié)果）
e1— give the information N
e2— modify the document
e3— give the information M
第三步，分析出中間節(jié)點(diǎn)
然后畫出因果圖灯变，如圖
再舉個例子
某公司對客戶有一定的折扣政策殴玛，公司軟件的一個模塊的需求說明書中描述“……當(dāng)交易額小于等于5萬元時折扣為0，當(dāng)交易額大于5萬元時才有折扣添祸，如果交易的客戶在三個月內(nèi)無欠款滚粟，則折扣為15%；如果交易用戶在三個月內(nèi)有欠款刃泌，若該用戶是三年以上的老客戶凡壤，則折扣為10%；若該客戶不是三年以上的老客戶蔬咬，則折扣為5%鲤遥。”
原因（對立的就不要再寫了林艘，比如寫了是小于五萬就不用寫大于等于五萬了）：
C1：交易額大于5萬元
C2：三個月無欠款
C3：三年以上老客戶
結(jié)果（注意對立的就不要再寫了）：
E1：無折扣
E2：折扣=5%
E3：折扣=10%
E4：折扣=15%
因果圖盖奈，從這個圖中你就能找出導(dǎo)出上邊說的四種結(jié)果的邏輯
白盒測試（White-box testing）
白盒測試也叫structural testing, clear box testing, and glass box testing.
白盒測試分為靜態(tài)測試和動態(tài)測試
白盒靜態(tài)測試：Code inspection, Static structure analysis, Static quality metric method
白盒動態(tài)測試：主要基于覆蓋，包括logic coverage, loop coverage, basis path coverage, etc.
白盒測試主要應(yīng)用于單元測試
we can’t use exhaustive（詳盡的） testing
動態(tài)測試之邏輯覆蓋
白盒測試用例設(shè)計(jì)的一個很重要的評估標(biāo)準(zhǔn)就是對代碼的覆蓋度狐援。一說到覆蓋钢坦，大家都感覺非常熟悉，但是常見的覆蓋都有哪些啥酱？各自有什么優(yōu)缺點(diǎn)爹凹？在白盒測試的用例設(shè)計(jì)中我們應(yīng)該如何自如地運(yùn)用呢？為大家總結(jié)了一下幾種常見的覆蓋以及各自的優(yōu)缺點(diǎn)镶殷。
白盒測試中常見的覆蓋有六種：語句覆蓋禾酱、判定覆蓋、條件覆蓋、判定/條件覆蓋颤陶、組合覆蓋和路徑覆蓋颗管。下面我們就分別看看這幾種不同的覆蓋究竟是什么鬼。
一滓走、語句覆蓋（Statement Coverage）
語句覆蓋垦江，顧名思義就是針對代碼語句的嘛。它的含義是我們設(shè)計(jì)出來的測試用例要保證程序中的每一個語句至少被執(zhí)行一次搅方。通常語句覆蓋被認(rèn)為是“最弱的覆蓋”比吭，原因是它僅僅考慮對代碼中的執(zhí)行語句進(jìn)行覆蓋而沒有考慮各種條件和分支，因此在實(shí)際運(yùn)用中語句覆蓋很難發(fā)現(xiàn)代碼中的問題姨涡。舉個非常簡單的例子：
public int foo(int a,int b)
{
return a/b;
}
這是一個求兩數(shù)之商的函數(shù)衩藤。如果我們設(shè)計(jì)如下的測試用例：
TestCase: a = 2, b = 1
這時候我們會發(fā)現(xiàn)，該函數(shù)的代碼覆蓋率達(dá)到了100%涛漂，并且設(shè)計(jì)的case可以順利通過測試慷彤。但是顯然該函數(shù)有一個很明顯的bug：當(dāng) b=0 時，會拋出異常怖喻。
再來看這個例子：
主要特點(diǎn)：語句覆蓋是最起碼的結(jié)構(gòu)覆蓋要求，語句覆蓋要求設(shè)計(jì)足夠多的測試用例岁诉，使得程序中每條語句至少被執(zhí)行一次锚沸。
用例設(shè)計(jì)：（如果此時將A路徑上的語句1—〉T去掉，那么用例如下）
優(yōu)點(diǎn)：可以很直觀地從源代碼得到測試用例涕癣，無須細(xì)分每條判定表達(dá)式哗蜈。
缺點(diǎn)：由于這種測試方法僅僅針對程序邏輯中顯式存在的語句，但對于隱藏的條件和可能到達(dá)的隱式邏輯分支坠韩，是無法測試的距潘。在本例中去掉了語句1—〉T去掉，那么就少了一條測試路徑只搁。在if結(jié)構(gòu)中若源代碼沒有給出else后面的執(zhí)行分支音比，那么語句覆蓋測試就不會考慮這種情況。但是我們不能排除這種以外的分支不會被執(zhí)行氢惋，而往往這種錯誤會經(jīng)常出現(xiàn)洞翩。再如，在Do-While結(jié)構(gòu)中焰望，語句覆蓋執(zhí)行其中某一個條件分支熊赖。那么顯然俱笛，語句覆蓋對于多分支的邏輯運(yùn)算是無法全面反映的零抬，它只在乎運(yùn)行一次，而不考慮其他情況。
二喧务、判定覆蓋（Decision Coverage）
判定覆蓋也被成為分支覆蓋(Branch Coverage)，也就是說設(shè)計(jì)的測試用例要保證讓被測試程序中的每一個分支都至少執(zhí)行一次旭等。舉個例子,有如下流程圖：
針對該圖我們想要做到判定覆蓋，可以設(shè)計(jì)如下case：
TestCase1: a=1, b=1 ?(路徑：ab)
TestCase2: a=-1, b=-1 ?(路徑：acd)
TestCase3: a=2, b=-1 ?(路徑：ace)
判定覆蓋比語句覆蓋強(qiáng)一些箱舞，能發(fā)現(xiàn)一些語句覆蓋無法發(fā)現(xiàn)的問題。但是往往一些判定條件都是由多個邏輯條件組合而成的刽虹，進(jìn)行分支判斷時相當(dāng)于對整個組合的最終結(jié)果進(jìn)行判斷，這樣就會忽略每個條件的取值情況缸剪，導(dǎo)致遺漏部分測試路徑。
同樣上邊流程圖1例子也一樣
用例設(shè)計(jì)
優(yōu)點(diǎn)：判定覆蓋比語句覆蓋要多幾乎一倍的測試路徑，當(dāng)然也就具有比語句覆蓋更強(qiáng)的測試能力。同樣判定覆蓋也具有和語句覆蓋一樣的簡單性捻爷，無須細(xì)分每個判定就可以得到測試用例甜紫。
缺點(diǎn)：往往大部分的判定語句是由多個邏輯條件組合（也就是可能if(a==b&&c==d)這種的邏輯組合）而成（如腰根，判定語句中包含AND、OR拓型、CASE）额嘿，若僅僅判斷其整個最終結(jié)果，而忽略每個條件的取值情況劣挫，必然會遺漏部分測試路徑册养。
三、條件覆蓋（Condition Coverage）
條件覆蓋于分支覆蓋不同压固，條件覆蓋要求所設(shè)計(jì)的測試用例能使每個判定中的每一個條件都獲得可能的取值球拦，即每個條件至少有一次真值、有一次假值帐我。
仍然以上面流程圖2作為例子來說明坎炼。上圖中涉及到的條件一共有4個：
a>0, a<0, b>0, b<0
為了達(dá)到條件覆蓋的目的，我們設(shè)計(jì)的用例需要在 a 點(diǎn)有：
a>0, a≤0, b>0, b≤0拦键，
這些情況出現(xiàn)谣光，并且在 c 點(diǎn)有：
a<0, a≥0, b<0, b≥0
這些情況出現(xiàn)。現(xiàn)在可以設(shè)計(jì)如下用例：
TestCase1: a=1, b=1 ?(路徑：ab)
TestCase1: a=-1, b=-1 ?(路徑：acd)
TestCase1: a=-1, b=0 ?(路徑：ace)
TestCase1: a=1, b=-1 ?(路徑：ace)
通常而言條件覆蓋比判定覆蓋強(qiáng)芬为，因?yàn)闂l件覆蓋使得判定中的每一個條件都取到了不同的結(jié)果抢肛，這一點(diǎn)判定覆蓋則無法保證狼钮。但條件覆蓋也有缺陷，因?yàn)樗荒鼙ＷC每個條件都取到了不同結(jié)果捡絮，但沒有考慮到判定結(jié)果熬芜，因此有時候條件覆蓋并不能保證判定覆蓋。
優(yōu)點(diǎn)：顯然條件覆蓋比判定覆蓋福稳，增加了對符合判定情況的測試涎拉，增加了測試路徑。
缺點(diǎn)：要達(dá)到條件覆蓋的圆，需要足夠多的測試用例鼓拧，但條件覆蓋并不能保證判定覆蓋。條件覆蓋只能保證每個條件至少有一次為真越妈，而不考慮所有的判定結(jié)果季俩。
四、判定條件覆蓋（Decision/Condition Coverage）
以流程圖1為例
主要特點(diǎn)：設(shè)計(jì)足夠多的測試用例梅掠，使得判定中每個條件的所有可能結(jié)果至少出現(xiàn)一次酌住，每個判定本身所有可能結(jié)果也至少出現(xiàn)一次。
優(yōu)點(diǎn)：判定/條件覆蓋滿足判定覆蓋準(zhǔn)則和條件覆蓋準(zhǔn)則阎抒，彌補(bǔ)了二者的不足酪我。
缺點(diǎn)：判定/條件覆蓋準(zhǔn)則的缺點(diǎn)是未考慮條件的組合情況。
五且叁、組合覆蓋（Branch Condition Combination Coverage）
組合覆蓋也叫做條件組合覆蓋都哭。意思是說我們設(shè)計(jì)的測試用例應(yīng)該使得每個判定中的各個條件的各種可能組合都至少出現(xiàn)一次。顯然逞带，滿足條件組合覆蓋的測試用例一定是滿足判定覆蓋欺矫、條件覆蓋和判定條件覆蓋的。
主要特點(diǎn)：要求設(shè)計(jì)足夠多的測試用例展氓，使得每個判定中條件結(jié)果的所有可能組合至少出現(xiàn)一次穆趴。
針對前文提到的流程圖2，做條件組合覆蓋時我們可以設(shè)計(jì)如下用例：
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
優(yōu)點(diǎn)：多重條件覆蓋準(zhǔn)則滿足判定覆蓋带饱、條件覆蓋和判定/條件覆蓋準(zhǔn)則。更改的判定/條件覆蓋要求設(shè)計(jì)足夠多的測試用例阅羹，使得判定中每個條件的所有可能結(jié)果至少出現(xiàn)一次勺疼，每個判定本身的所有可能結(jié)果也至少出現(xiàn)一次。并且每個條件都顯示能單獨(dú)影響判定結(jié)果捏鱼。
缺點(diǎn)：線性地增加了測試用例的數(shù)量执庐。
六、路徑覆蓋
路徑覆蓋导梆，意思是說我們設(shè)計(jì)的測試用例可以覆蓋程序中所有可能的執(zhí)行路徑轨淌。這種覆蓋方法可以對程序進(jìn)行徹底的測試用例覆蓋迂烁，比前面講的五種方法覆蓋度都要高。那么這種方法是不是就一定最好呢递鹉？當(dāng)然不能講得這么絕對盟步，它的缺點(diǎn)也是顯而易見的：由于需要對所有可能的路徑全部進(jìn)行覆蓋，那么我們需要設(shè)計(jì)數(shù)量非常巨大的而且較為復(fù)雜的測試用例躏结，用例數(shù)量將呈現(xiàn)指數(shù)級的增長却盘。所以理論上來講路徑覆蓋是最徹底的測試用例覆蓋，但實(shí)際上很多時候路徑覆蓋的可操作性不強(qiáng)媳拴。
針對流程圖1
優(yōu)點(diǎn)：這種測試方法可以對程序進(jìn)行徹底的測試黄橘，比前面五種的覆蓋面都廣。
缺點(diǎn)：由于路徑覆蓋需要對所有可能的路徑進(jìn)行測試（包括循環(huán)屈溉、條件組合塞关、分支選擇等），那么需要設(shè)計(jì)大量子巾、復(fù)雜的測試用例帆赢，使得工作量呈指數(shù)級增長。而在有些情況下砰左，一些執(zhí)行路徑是不可能被執(zhí)行的
總結(jié)
以上簡單描述了幾種不用的邏輯覆蓋方法的原則和優(yōu)劣匿醒。在實(shí)際的操作中，要正確使用白盒測試的代碼覆蓋方法缠导，就要從代碼分析和代碼調(diào)研入手廉羔，根據(jù)調(diào)研的結(jié)果，可以選擇上述方法中的某一種僻造，或者好幾種方法的結(jié)合憋他，設(shè)計(jì)出高效的測試用例，盡可能全面地覆蓋到代碼中的每一個邏輯路徑髓削。
控制流程圖和圈復(fù)雜度
常見控制流圖
將上訴程序轉(zhuǎn)化成控制流圖
圈復(fù)雜度=判定節(jié)點(diǎn)數(shù)+1
練習(xí)1：
計(jì)算下圖的圈復(fù)雜度
標(biāo)識它的獨(dú)立路徑
獨(dú)立路徑是指程序中至少引進(jìn)一個新的處理語句集合竹挡，采用流圖的術(shù)語，即獨(dú)立路徑必須至少包含一條在定義路徑之前不曾用到的邊立膛。
獨(dú)立路徑數(shù)=判定節(jié)點(diǎn)數(shù)（4）+1= 5
獨(dú)立路徑數(shù)= e – n + 1 = 11 – 7 + 1 = 5
獨(dú)立路徑：
ABCFG
ABDFG
ABEFG
ABCDFG
ABEDFGABDFG
再比如
獨(dú)立路徑
路徑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個判定節(jié)點(diǎn)+1=4（圈復(fù)雜度）
由此為了覆蓋所有程序語句揪罕，必須設(shè)計(jì)至少4個測試用例使程序運(yùn)行于這4條路徑。
循環(huán)測試
路徑覆蓋法是一種將程序中循環(huán)結(jié)構(gòu)簡化成選擇結(jié)構(gòu)的測試方法宝泵。
循環(huán)簡化的目的是限制循環(huán)次數(shù)好啰，無論循環(huán)的形式和循環(huán)體實(shí)際執(zhí)行的次數(shù)，簡化后的循環(huán)測試只考慮循環(huán)一次或者零次兩種情況儿奶。
在這種情況下框往，循環(huán)與判定分支的效果是一樣的，即循環(huán)要么執(zhí)行闯捎，要么跳過椰弊。
采用較復(fù)雜的循環(huán)測試策略測試循環(huán)许溅，可采用下面測試集：
跳過整個循環(huán)；
只循環(huán)一次秉版；
只循環(huán)兩次贤重；
循環(huán)m次，m
數(shù)據(jù)流測試...
突變測試（Mutation Testing）
突變測試(mutation testing) , 或稱作突變分析沐飘、程序突變游桩，它是用于衡量軟件測試的質(zhì)量。突變測試通常對程序的源代碼或者目標(biāo)代碼做小的改動耐朴，并把截然不同的錯誤行為（或者怪異行為）作為預(yù)期借卧。如果測試代碼沒有覺察到這種小改動帶來的錯誤隆判，就說明這個測試是有問題的垫挨。
突變測試目的：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;
條件運(yùn)算符如果用||來替換&&镰吵，就會產(chǎn)生以下變異：
if(a || b) c = 1;
else c = 0;
為了殺死這個突變，需要滿足以下條件：
（1）測試數(shù)據(jù)必須對突變和原始程序引起的不同狀態(tài)覆蓋挂签。如：a=1,b=0可以達(dá)到目的疤祭。
（2）c的值應(yīng)該傳播到程序輸出，并被測試檢查饵婆。
弱突變覆蓋需滿足（1）勺馆，強(qiáng)突變覆蓋需滿足（1）（2）。
1 變異測試?yán)碚?/b>
1.1 兩個基本假設(shè)
變異測試旨在找出有效的測試用例侨核，發(fā)現(xiàn)程序中真正的錯誤草穆。在一個工程中，潛在BUG的數(shù)量是巨大的搓译，通過生成突變體來全面覆蓋所有的錯誤是不可能的悲柱。所以，傳統(tǒng)的變異測試旨在尋找這些錯誤的子集些己，能盡量充分地近似描述這些BUG豌鸡。這個理論基于兩條假設(shè)：Competent
Programmer Hypothesis(CPH) 和 Coupling Effect(CE)。
CPH是指：假設(shè)編程人員是有能力的段标，他們盡力去更好地開發(fā)程序涯冠，達(dá)到正確可行的結(jié)果，而不是搞破壞怀樟。它關(guān)注的是程序員的行為和意圖功偿。而CE(耦合效應(yīng))更加關(guān)注在變異測試中錯誤的類別盆佣。一個簡單的錯誤產(chǎn)生往往是由于一個單一的變異（例如句法錯誤）往堡，而一個龐大復(fù)雜的錯誤往往是由于多出變異所導(dǎo)致械荷。復(fù)雜變異體往往是由諸多簡單變異體組合而成。
變異測試流程
在變異測試中虑灰，對于被測程序p吨瞎，設(shè)定一個測試用例集合T。首先根據(jù)被測程序特征設(shè)定一系列變異算子穆咐；隨后通過在原有程序p上颤诀，執(zhí)行變異算子生成大量變異體；接著從大量變異體中識別出等價變異體对湃；然后在剩余的非等價變異體上執(zhí)行測試用例集T中的測試用例崖叫，若可以檢測出所有非等價變異體，則變異測試分析結(jié)束拍柒，否則對未檢測出的變異體心傀，需要額外設(shè)計(jì)新的測試用例，并添加到測試用例集T中拆讯。
定義 1（變異算子）
在符合語法規(guī)則前提下脂男， 變異算子定義了從原有程序生成差別極小程序（即變異體）
的轉(zhuǎn)換規(guī)則。下表給出了一個典型的變異算子种呐， 該變異算子將“＋” 操作符變異為 “-” 操作符宰翅。選擇被測程序 p 中的條件表達(dá)式 a + b
> c 執(zhí)行該變異算子， 將得到條件表達(dá)式 a - b > c 爽室， 并生成變異體 p′ 汁讼。
定義 2（一階變異體）
在原有程序p上執(zhí)行單一變異算子并形成變異體p′ ，則稱p′為p的一階變異體肮之。
定義3（高階變異體）
在原有程序 p 上依次執(zhí)行多次變異算子并形成變異體 p′ 掉缺，則稱 p′ 為 p 的高階變異體。若在 p 上依次執(zhí)行 k 次變異算子并形成變異體 p′ 戈擒， 則稱 p′ 為 p 的 k 階變異體眶明。
定義 4（可殺除變異體）
若存在測試用例t，在變異體p′ 和原有程序p上的執(zhí)行結(jié)果不一致筐高， 則稱該變異體p′ 相對于測試用例集T是可殺除變異體搜囱。
定義 5（可存活變異體）
若不存在任何測試用例t， 在變異體p′ 和原有程序p上的執(zhí)行結(jié)果不一致柑土， 則稱該變異體p′ 相對于測試用例集T是可存活變異體蜀肘。一部分可存活變異體通過設(shè)計(jì)新的測試用例可以轉(zhuǎn)化成可殺除變異體，
剩余的可存活變異體則可能是等價變異體稽屏。本文對等價變異體定義如下扮宠。
定義 6（等價變異體）
若變異體p′ 與原有程序p在語法上存在差異， 但在語義上與p保持一致狐榔， 則稱p′ 是p的等價變異體坛增。
單元測試（Unit Testing）
單元測試是最小的測試部分获雕，測試模塊是獨(dú)立于其他模塊的，一般情況下收捣，被測單元能夠?qū)崿F(xiàn)一個特定的功能届案，并與其他單元有明確的接口定義，這樣才可以與其他單元隔離開來罢艾。
In Java, a unit is a class or a class method.
In C, a unit is a function or sub processes.
目標(biāo)：確保模塊被正確的編碼
依據(jù)：系統(tǒng)詳細(xì)的規(guī)格說明
過程：經(jīng)過設(shè)計(jì)楣颠、腳本開發(fā)、執(zhí)行咐蚯、調(diào)試和分析結(jié)果一個過程
執(zhí)行者：由程序開發(fā)人員和測試人員共同完成
方法：以白盒測試方法為主童漩，輔以黑盒測試方法
如何進(jìn)行評估：通過所有單元測試用例，代碼沒有嚴(yán)重缺陷
單元測試過程
1春锋、在詳細(xì)設(shè)計(jì)階段完成單元測試計(jì)劃
2睁冬、建立單元測試環(huán)境，完成測試設(shè)計(jì)和開發(fā)
3看疙、執(zhí)行單元測試用例豆拨，并且詳細(xì)記錄測試結(jié)果
4、判定單元測試是否通過
5能庆、提交單元測試報告
單元測試優(yōu)點(diǎn)
1施禾、單獨(dú)進(jìn)行，一起進(jìn)行搁胆，降低軟件質(zhì)量成本弥搞，縮短開發(fā)周期；
2渠旁、便于跟蹤錯誤攀例；
3、集成后錯誤會放大顾腊，集成后復(fù)雜性高粤铭，很難發(fā)現(xiàn)問題；
4杂靶、無需而外的設(shè)備和人員梆惯。
單元測試分為靜態(tài)測試和動態(tài)測試
靜態(tài)測試
代碼評審：代碼走查和正式會議審查。
代碼走查：代碼互查應(yīng)用最多吗垮，代碼走查是相對比較正式的評審過程垛吗，項(xiàng)目組部分成員通過閱讀代碼，向其他成員提出問題并對有關(guān)技術(shù)烁登、風(fēng)格怯屉、可能錯誤是否違背開發(fā)標(biāo)準(zhǔn)和規(guī)范等進(jìn)行評論。
正式會議審查：是一種正式的檢查和評估方法，最早由IBM提出锨络，經(jīng)實(shí)踐證明蝗敢，有一種有效的檢查辦法，從而得到軟件工程界的普遍認(rèn)同足删。它使用逐步檢查源代碼中有無邏輯或語法錯誤的辦法來檢驗(yàn)故障。
集成測試（Integration Testing）（集成測試锁右、組裝測試失受、聯(lián)合測試、子系統(tǒng)測試咏瑟、部件測試）
優(yōu)點(diǎn)：早點(diǎn)發(fā)現(xiàn)錯誤拂到，早點(diǎn)修正錯誤，早點(diǎn)獲得測試反饋码泞，調(diào)度修正錯誤靈活
分為增量式測試和非增量式測試
測試模式
Big bang（大爆炸） integration
優(yōu)點(diǎn)：完成速度快兄旬、能夠并行
缺點(diǎn)：錯誤發(fā)生時很難找出他的位置和改變以及很多問題得在系統(tǒng)測試才能發(fā)現(xiàn)
適用范圍：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（系統(tǒng)測試）
目的:測試可安裝性、可用性余寥、兼容性领铐、可維護(hù)性等等
Performance Testing(性能測試)
性能是量度系統(tǒng)或組件在一定約束條件下，是否達(dá)到功能設(shè)計(jì)的指標(biāo)：如響應(yīng)速度宋舷，計(jì)算的精度绪撵，內(nèi)存利用率。
性能是系統(tǒng)外部的質(zhì)量屬性基于用戶的需求和用戶的系統(tǒng)操作性的看法祝蝠。
同時性能特別應(yīng)用于對實(shí)時系統(tǒng)的評價當(dāng)中,就是它的行為在指定的期限內(nèi)完成正確的操作音诈。
評估指標(biāo)為時間效率，空間效率绎狭，I∕O性能细溅，數(shù)據(jù)庫性能，內(nèi)存性能儡嘶，初始化∕退出時間和資源利用率延時喇聊，事務(wù)處理時間，最大事務(wù)處理時間蹦狂，事務(wù)操作時間承疲，數(shù)據(jù)庫性能，最大消耗的內(nèi)存量鸥咖，高峰內(nèi)存時間燕鸽，資源消耗。
下圖描述了web應(yīng)用的頁面響應(yīng)時間的分解啼辣。
頁面響應(yīng)時間分解為網(wǎng)絡(luò)傳輸時間（N1+N2+N3+N4）和應(yīng)用延遲時間（A1+A2+A3）啊研，
而應(yīng)用延遲時間又可分為數(shù)據(jù)庫延遲時間（A2）和應(yīng)用服務(wù)器延遲時間（A1+A3）。
延遲：一個指令控制器發(fā)出數(shù)據(jù)請求的一瞬間和數(shù)據(jù)傳送的一瞬間之間的時間間隔;是請求和完成操作之間拖延的時間差。
事務(wù)處理時間：是指完成一項(xiàng)事務(wù)所需要的運(yùn)行時間党远，用于評價事務(wù)處理效率削解。通常，事務(wù)處理的時間越短沟娱，則效率越高氛驮。
并發(fā)用戶數(shù)，一般分兩種情況：
嚴(yán)格意義的并發(fā)济似，即所有用戶在同一時間做同一件事情或者操作矫废。
廣義范圍的并發(fā)，多個用戶對系統(tǒng)發(fā)出了請求或進(jìn)行了操作砰蠢，但這些操作可以是相同的蓖扑，也可以是不同的。
吞吐量：是指在一次性能測試過程中網(wǎng)絡(luò)上傳輸數(shù)據(jù)量的總和台舱。
一般來說律杠，吞吐量用請求數(shù)/秒或頁面數(shù)/秒來衡量。
吞吐量指標(biāo)有如下兩個作用：
1竞惋、協(xié)助設(shè)計(jì)性能測試場景柜去，衡量性能測試場景是否達(dá)到了預(yù)期的設(shè)計(jì)目標(biāo)。
在設(shè)計(jì)性能測試場景時拆宛，根據(jù)估算吞吐量數(shù)據(jù)測試場景事物發(fā)生頻率诡蜓。
2、協(xié)助分析性能測試瓶頸胰挑。
性能測試比較關(guān)注業(yè)務(wù)并發(fā)用戶數(shù)蔓罚，從業(yè)務(wù)的角度設(shè)置多少并發(fā)數(shù)合理。
下面給出估算并發(fā)用戶數(shù)的公式：C=nL／T
C —平均的并發(fā)用戶數(shù)
n —登錄會話的數(shù)量
L —登錄會話的平均長度
T —考察的時間段長度
例題：
一個軟件系統(tǒng)每天約有400個用戶訪問瞻颂。用戶在一天之內(nèi)有8小時內(nèi)使用該系統(tǒng)豺谈，從登錄到退出的平均時間為4小時，請計(jì)算該系統(tǒng)的并發(fā)用戶數(shù)和并發(fā)用戶的峰值各是多少贡这？
分析：根據(jù)公式C=400×4／8=200
負(fù)載測試是模擬實(shí)際軟件系統(tǒng)所承受的負(fù)載條件的系統(tǒng)負(fù)荷茬末，通過不斷加載（不斷增加模擬用戶數(shù)量）或其他加載方式來觀察不同負(fù)載下系統(tǒng)響應(yīng)時間和數(shù)據(jù)吞吐量，系統(tǒng)資源占有率（cpu和內(nèi)存）等性能指標(biāo)盖矫，以檢驗(yàn)系統(tǒng)的行為和特性丽惭，發(fā)現(xiàn)系統(tǒng)可能存在的性能瓶頸、內(nèi)存泄露和不能實(shí)現(xiàn)同步等問題辈双。
高低突變加載：某個時間用戶數(shù)量很大责掏，突然降到很低，過一段時間湃望，又突然加到很高换衬，反復(fù)幾次痰驱。借助這種負(fù)載方式的測試，容易發(fā)現(xiàn)資源的釋放和內(nèi)存泄漏的問題瞳浦。
隨機(jī)加載方式：由隨機(jī)算法自動生成某個數(shù)量范圍內(nèi)變化的担映、動態(tài)的負(fù)載，這種方式可能是和實(shí)際情況最為接近的一種負(fù)載方式叫潦。雖然不容易模擬系統(tǒng)運(yùn)行出現(xiàn)的瞬間高峰期蝇完，但可以模擬系統(tǒng)長時間的運(yùn)行過程的狀態(tài)。
壓力測試用于判定應(yīng)用處理大量數(shù)據(jù)的能力矗蕊。
壓力測試可以成功的測試服務(wù)器滿負(fù)載的情況短蜕。
除了在服務(wù)器上增加運(yùn)行的應(yīng)用結(jié)合客戶端測試是一種額外的形式的壓力測試。
性能測試過程：計(jì)劃拔妥，記錄，修改达箍，執(zhí)行没龙，分析
