软件测试基础知识大全(新手入门必备)
軟件測試基礎知識大全(新手入門必備)
測?試?基?礎
1、?軟件測試的目的：證明（表達軟件能夠工作）→?檢測（發現錯誤）→?預防（管
?理質量）
2、?測試執行：單元測試（UT執行）：一個測試用例的測試執行；
??集成測試（IT執行）：一個測試用例集的測試執行；
??系統測試（ST執行）：不同測試階段的測試執行。這幾句話是什么意思，覺得不是很有針對性？
3、?回歸測試的目的：a.?驗證錯誤是否修復；
b.?檢測對代碼的修改是否引入了新的錯誤。
5、?軟件測試的主要工作：a.?檢視代碼，評審開發文檔；
b.?進行測試設計，寫作測試文檔（測試計劃、測試方案、測試用例等）；
c.?執行測試，發現軟件缺陷，提交缺陷報告，并確認缺陷最終得到了修正；
d.?通過測試度量軟件質量。??????????????????????????????????????????????????????????????????????????????
6、?軟件危機的出現主要表現在：a.?由于缺乏大型軟件開發經驗和軟件開發數據積累，開發工作計劃很難制定；
??????????????????????????????b.?開發早期需求分析不夠明確，造成開發后期矛盾集中暴露；
??????????????????????????????c.?不遵循開發規范，開發文檔不完整，軟件難以維護；
??????????????????????????????d.?缺乏嚴密有效的軟件質量檢測手段，交付給用戶的軟件質量差。
7、?軟件危機的后果：a.?軟件質量不高，很難穩定；
b.?軟件項目延期，進度無法控制；
c.?成本增加，無法控制預算。
8、?軟件危機的根源：a.?根據摩爾定律，硬件發展很快，相應對軟件系統的期望
越來越高；
????????????????????b.?軟件系統復雜性提高，需多人合作；
????????????????????c.?軟件開發是人的智力活動，無法用已有的產業工程方法來組織管理。
9、?軟件生命周期的各個階段：計劃→?需求分析→?設計→?編碼→?測試→?運行→?評價
10、?設計：概要設計（HLD）：在設計階段把各項需求轉換成相應的體系結構，每一部分是功能明確的模塊；
???????????詳細設計（LLD）：對每個模塊要完成的工作進行具體的描述。
11、?軟件研發相關要素：人員、過程、工具。
12、?軟件項目組人員組成：分析人員、設計人員、開發人員、測試人員、配置管理人員、SQA（質量保證人員）；
13、?軟件研發流程類型：瀑布模型、螺旋模型、RVPRUP流程、IPD流程。
14、?軟件研發中幾個重要的過程：需求管理；配置管理；缺陷管理；同行評審。
15、?常見的引入缺陷的原因：a.?開發過程缺乏有效的溝通，或者沒有進行溝通；
???????????????????????????b.?軟件復雜度越來越高；
???????????????????????????c.?編程中產生錯誤；
???????????????????????????d.?需求不斷變更；
???????????????????????????e.?項目進度的壓力；
???????????????????????????f.?不重視開發文檔；
g.?軟件開發工具本身隱藏的問題。等等……?
軟?件?質?量
軟件質量管理體系：
?
?
?
軟件質量管理體系：
??????????????????????????
???????????????????????????
?
?
?
?
?
ISO9000（2000版）???????????CMM??????????????????????六西格瑪
ISO?9000???????????????ISO?9004
???????????????
????????
ISO9000：2000版標準
ISO9000：制定管理理念和原則
ISO9001：標準對組織質量管理體系必須履行的要求做了明確的規定，是對產品要求的進一進補充。（梳心）
ISO9004：是組織進行持續改進的指南標準。
八項質量管理原則：?
一．?以顧客為中心：組織依存于其顧客，因此，組織應理解顧客當前的和未來的需求，??????????????
??????????????滿足顧客要求并爭取趕超顧客期望。
二．?領導作用：?領導者將本組織的宗旨.方向和內部環境編統一起來，并創造使員工能???
???????????????????夠充參與實現組織目標的環境。
三．?全員參與：??各級人員是組織之本，只有他們的充分參與，才能使他們的才干為組?
????????????????????織帶來最大的收益。
四．?過程方法：?將相關的資源和活動作為過程進行管理，可以更高效地得到期望的結
???????????????????果。?
五．????管理系統方法：針對設定的目標，識別.理解并管理一個由相互關聯的過程的過程
???????????????????????所組成的體系，有助于提高組織的有效性和效率。
六．????持續改進：持續改進是組織的一個永恒的目標。
七．?????基于事實的決策方法：對數據和信息的邏輯分析或直覺判斷是有效決策的基礎。
八．?????互利的供方關系：通過互利的關系，增強組織及其供方創造價值的能力。
其中與軟件產品產品優其相關有：（一.三.六.七項）
?
1、?軟件質量的定義：一個實體的所有特性，基于這些特性可以滿足明顯的或隱含的需求。而質量就是實體基于這些特性滿足需求的程度。
2、?軟件質量的三個層次：a.?符合需求規格；b.?符合用戶顯示需求；
????????????????????????c.?符合用戶實際需求。
3、?影響軟件質量的因素：流程、技術、組織。
流程：一組活動（活動是否都是必須的；活動角色之間的關系）
過程：一組將輸入轉化為輸出的相關聯或相互作用的活動。
4、?八項質量管理原則的意義：a.?是質量管理的理論基礎；
????????????????????????????b．用高度概括易于理解的語言所表述的質量管理的最基本，最通用的一般性規律；
????????????????????????????c.?為組織建立質量管理體系提供了理論依據；
????????????????????????????d.?是組織的領導者有效的實施質量管理工作必須遵循的原則。
5、CMM?軟件質量成熟度模型
?CMM(capabillty?Maturity?Moelel)
由于美國軟件工程研究所（SEI）受美國國防部委托立項。
開發人：Watts?Humphrey.
1991年推出CMM1.0版，1993年提出CMM1.1版
現在開發CMMI（CMM?Integration）
軟件能力成熟度模型CMM（提唱過程決定質量）
?
????????????????????????????????????????
????????????????????????????????????????持續改進過程
?
?
?
?????????????????????????可預測的過程????????????????????????????????管理變更
?
?
?
?????????標準.一致的過程?????????????????????????????????????產品過程質量
?
?
?
??紀律的過程????????????????????????????????集成工程過程
?
?
?
???????????????????????????????項目管理
CMM1級
特點：（個人英雄主義）
A項目的成功依賴于一個非常優秀的項目經理的團隊。
B無法重復以往成功的實踐。
C缺乏基本配置管理
可視度：
整個過程不可預測，不可見，不可控。（過程管理非常混亂）
?
CMM2級
特點：（有紀律）
能夠重復以前成功的經驗和實踐。
引入合理需求變更（需求管理）
測試與開發分離，整個過程能力可概為有紀律的。
可視度
原始需求——需求分析——設計——編碼——測試——產品
?
CMM3級
特點：（有過程，經過同行評審）
組織中有一個專門負責組織的標準軟件過程。（SEPG）
可視度
同CMM2但整個過程是標準和一致的。
?
CMM4級特點
特點：（量化管理）
過程能力是可預防的，因為過程是已測量的并在可測的范圍內運行。組織能定量地預測過程和產品質量方面趨勢。軟件產品具有可預測的高質量。
可視度
同CMM3但整個過程是可預測的。
?
CMM5級特點
特點：（改進過程本身）
通過缺陷來發現過程的不足。
新的開發技術觸使改進過程。
可視度
同CMM￥級整個是以改進的。
?
CMM1：初始級，Inltial，不可預測并且缺乏控制；
????CMM2：可重復級：Repeatable，可重復以前的主要經驗；
（關鍵過程區域：需求管理；軟件項目計劃；軟件項目跟蹤和監督；軟件子合同管理；軟件質量保證；軟件配置管理。）
????CMM3：已定義級：Defined，過程被描述，并得到良好理解；
（關鍵過程區域：組織過程定義；組織過程焦點；培訓大綱；集成軟件管理；軟件產品工程；組際協調；同行評審。）
CMM4：已管理級：Managed，過程被測量并受控；
（關鍵過程區域：定量的過程管理；軟件質量管理。）
CMM5：優化級，Optimizing，關注過程改進。
（關鍵過程區域：缺陷預防；技術變更管理；過程變更管理。）
7、?CMM的用途：a.?評估組用來識別組織中的強處和弱處；
????????????????b.?評價組用來識別選擇不同的業務承包商的風險和監督合同；
????????????????c.?管理者用來了解其組織的能力，并了解為了提高其能力成熟度而進行軟件過程改進所需進行的活動；
????????????????d.?技術人員和過程改進組用來作為指南，指導他們在組織中定義和改進軟件過程。
8、?ISO9001和CMM的關系：
????相似點：強調管理、過程、規范化和文檔化；
????不同點：CMM把焦點對準軟件；ISO9001的范圍包括：硬件、軟件、流程性材料和服務；
????兩者關系：CMM2級與ISO9001強相關；CMM的每個關鍵過程域至少按某種解釋與ISO9001弱相關。
六西格瑪管理法（強調組織能力）
本質：全面質量管理，而不僅僅是質量提高手段
?
六西格瑪實施方式：
?????????????????DMAIC過程
?
??????????????????????????????????????????????????????????????????
???????????????????????????????????????????????????????????????推行控制系統
?????????????????
???????????????????????????????????????????????????
???????????????????????????????????????????????????????優化解決方案
?
?
??????????????????????????????????????????????研究資料，確定原因
?
?????????????????????????????????????
??????????????????????????????????????????收集資料，尋找原因
?
?
??????????????????????????????????提出問題，確定目標
?
?
9、?軟件質量模型:
????功能性：當軟件在指定條件下使用時，軟件產品提供滿足明確和隱含需求的功能的能力。包括：適合性；準確性；互操作性；保密安全性；功能性的依從性。
????可靠性：在指定條件下使用時，軟件產品維持規定的性能級別的能力。包括：成熟性；容錯性；易恢復性；可靠性的依從性。
????易用性：在指定條件下使用時，軟件產品被理解、學習、使用和吸引用戶的能力。包括：易理解性；易學性；易操作性；吸引性；易用性的依從性。
????效??率：在規定條件下，相對于所用資源的數量，軟件產品可提供適當性能的能力。包括：時間特性；資源利用性；效率依從性。
????維護性：軟件產品可被修改的能力。修改可能包括修正、改進或軟件對環境、需求和功能規格說明變化的適應。包括：易分析性；易改變性；穩定性；易測試性；維護性的依從性。
????可移植性：軟件產品從一種環境遷移到另外一種環境的能力。包括：適應性；易安裝性；共存性；易替換性；可移植性的依從性。
10、?軟件質量活動：軟件質量保證(SQA)和測試；SQA從流程方面保證軟件的質量、測試從技術方面保證軟件的質量、只進行SQA或者只進行測試活動不一定能產生好的軟件質量。
11、?SQA的主要工作范圍：·?指導并監督項目按照過程實施；
????????????????????????·?對項目進行度量、分析，增加項目的可視性；
????????????????????????·?審核工作產品，評價工作產品和過程質量目標的復合度；
????????????????????????·?進行缺陷分析，缺陷預防活動，發現過程的缺陷，提供決策參考，促進過程改進。
12、?度量：對事物屬性的量化表示；
軟件度量：是指計算機軟件中范圍廣泛的測度，包括對軟件系統、構建或生命周期過程具有的某個給定屬性的度的一個定量測量。
目的：·?提高軟件生產率，縮短產品研發周期，降低研發成本、維護成本；
?????·?提高軟件產品質量，提高用戶滿意度；
?????·?為組織持續改進提供量化的指標和反饋。
13、?軟件度量的作用：理解；預測；評估；改進。
分類：規模；工作量；進度；質量
?????如何將度量的知識應用于實際工作中：建立測試工作的度量數據，目的是作為預測和改進的基礎（a.?熟悉需求：進度、工作量、規模；b.?設計用例：工作效率、覆蓋率；c.?執行用例：工作效率、缺陷密度；）
?
測?試?方?法
1、?什么是白盒測試：
????·?白盒測試是依據被測軟件分析程序內部構造，并根據內部構造設計用例，來對內部控制流程進行測試，可完全不顧程序的整體共能實現情況；
????·?白盒測試是基于程序結構的邏輯驅動測試；
????·?白盒測試又可以被稱為玻璃盒測試、透明盒測試、開放盒測試、結構化測試、邏輯驅動測試。
2、?為什么進行白盒測試：
????·?一般在測試前期進行，通過達到一定的邏輯覆蓋率指標，使得軟件內部邏輯控制結構上的問難題能基本得到消除；
????·?能保證內部邏輯結構達到一定的覆蓋程度，能夠給予軟件代碼質量更大的保證；
????·?發現問題后解決問題的成本較低。
3、?白盒測試的常用技術：
????·?靜態分析：控制流分析、數據流分析、信息流分析等；
????·?動態分析：邏輯覆蓋測試（分支測試、路徑測試等）、程序插裝等。
4、?*控制流相關概念：程序元素、控制流關系、控制流圖、控制流矩陣。（步驟：5）
5、?*控制流分析能發現的問題：轉向并不存在的標號；沒有用的語句標號；從程序
入口進入后無法達到的語句；不能達到停機語句的
語句。
6、?*數據流相關概念：數據的定義；數據的引用。（步驟：3）
7、?*數據流分析的左右：分析代碼中關于數據定義和引用方面的錯誤；進行代碼優
化。（賦值語句運算效率高）
8、?*信息流分析：輸入變量和語句關系；語句和輸出變量關系；輸入和輸出變量管
?理。（步驟：4）
?
9、?覆蓋率工具的作用：
????????·?分析被測試代碼控制結構，決定插裝位置；·?實施插裝；·?將插裝代
碼重新編譯；·?執行被測對象，根據插裝的監控哨信息統計覆蓋率。
10、?白盒測試的特點：
·?測試人員需要了解軟件的實現；·?可以檢測代碼中的每條分支和路
徑；·?解釋隱藏在代碼中的錯誤；·?對代碼的測試比較徹底；·?實現代
碼結構上的優化；·?白盒測試投入較大，成本高；·?白盒測試不驗證規
格的正確性。
11、?什么是黑盒測試：
????????·?黑盒測試把被測對象看成一個黑盒，只考慮其整體特性，不考慮其內部具體實現；
????????·?黑盒測試針對的被測對象可以是一個系統、一個子系統、一個模塊、一個子模塊、一個函數等。
????????·?黑盒測試又可以被稱為基于規格的測試。
12、?常見的黑盒測試類型：功能性測試；容量測試；負載測試；恢復性測試。
13、?*系統測試的時候，如果沒有SRS時，有兩類BUG無法發現：需求遺漏；
需求偏差。
14、?黑盒測試的優點：·對于更大的代碼單元來說（子系統甚至系統級）比白
盒測試效率要高；·?測試人員不需要了解實現的細節，
包括特定的編程語言；·?從用戶的視角進行測試，很容
易被大家理解和接受；·?有助于暴露任何規格不一致或
有歧義的問題。
15、?黑盒測試的缺點：·?沒有清晰的和簡明的規格，測試用例是很難設計
的；·?不能控制內部執行路徑，會有很多內部程序路徑
沒有被測試到；不能直接針對特定的程序段，這些程序
可能非常復雜（因此可能隱藏更多的問題）。
?
16、?動態和靜態測試的分類依據在于：被測對象是否運行起來。
17、?手工靜態分析——同行評審：正規檢視；技術評審；走查。評審對象：計
??劃、需求文檔、設計圖、代碼等。
18、?自動化靜態分析：靜態驗證；語法分析器；符號執行器。
???????自動化測試的限制（板書）：
·?自動化測試不具備想象力，不能夠檢查腳本中給定的觀察點之外的錯誤；
·?自動化測試只能提高測試效率，不能提高測試效果，不能發現比人工測試更多的問題；如被測對象不穩定，存在變動性的話不適合開展自動化測試，否則腳本的編寫和維護所耗費的時間可能遠大于人工測試；
·?只有手工測試積累到一定程度（提供更多的觀察點），才能做好自動化測
試。
V&V模型（測試過程）
1、??驗證與確認V&V：驗證（VERIFICATION）強調過程；確認（VALIDATION）強調
?結果。
2、??V&V告訴我們：·?盡早測試（盡早準備、盡早執行）；
·?全面測試（文檔、代碼）
·?全過程測試（測試參與到開發過程中、對測試過程全稱跟蹤）
·?測試是獨立的、迭代的。
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
3、?單元、集成、系統測試的比較：測試方法不同；考察范圍不同；評估基準不同。
4、?回歸測試策略：完全重復測試；選擇性重復測試（覆蓋修改法；周邊影響法；?指標達成方法；選擇重要級別高的測試用例）
5、?其他測試階段：驗收測試；a(ALPHA)測試；B(BETA)測試。
6、?主要的測試文檔：測試計劃；測試方案；測試用例；測試規程；測試報告；測試日報。
單?元?測?試
1、?單元測試的目的：
在于發現各模塊內部可能存在的各種錯誤主要是基于白盒測試。
·?驗證代碼是與設計相符合的；·?發現設計和需求中存在的錯誤；
·?發現在編碼過程中引入的錯誤。（和設計不相符?/?和設計相符，但是由于
編碼疏漏引起）
2、?孤立的測試策略：
·?方法：不考慮每個模塊與其他模塊之間的關系，為每個模塊設計樁模塊和
驅動模塊。每個模塊進行獨立的單元測試。
??·?優點：該方法是最簡單，最容易操作的。可以達到高的結構覆蓋率。該方法是純粹的單元測試。
???·?缺點：樁函數和驅動函數工作量很大，效率低。
3、?自頂向下的單元測試策略：
·?方法：先對最頂層的單元進行測試，把頂層所調用的單元做成樁模塊。其
次對第二層進行測試，使用上面已測試的單元做驅動模塊。如此類
推直到測試完所有模塊。
·?優點：可以節省驅動函數的開發工作量，測試效率較高。
?·?缺點：隨著被測單元一個一個被加入，測試過程將變得越來越復雜，并且
開發和維護的成本將增加。
4、?自底向上的單元測試策略：
·?方法：先對模塊調用層次圖上最低層的模塊進行單元測試，模擬調用該模
塊的模塊做驅動模塊。然后再對上面一層做單元測試，用下面已被
測試過的模塊做樁模塊。以此類推，直到測試完所有模塊。
·?優點：可以節省樁函數的開發工作量，測試效率較高。
?·?缺點：不是純粹的單元測試，底層函數的測試質量對上層函數的測試將產
生很大的影響。
5、??單元測試的四個階段：·?測試計劃：完成單元測試計劃；
??????????????????????????·?測試設計：完成單元測試方案；
??????????????????????????·?測試實現：完成單元測試用例、單元測試規程、單元測試腳本及數據文件；
??????????????????????????·?測試執行：執行單元測試用例，修改發現的問題并進行回歸測試，提交單元測試報告。
2?單元測試：樁&驅動舉例：
無論是單元測試還是集成測試都涉及到以下三個函數：
主控函數：int?ctrl(int?x,?int?y)
加法函數：int?add(int?x,?int?y)
減法函數：int?sub(int?x,?int?y)
注意：進行單元測試時，設計用例時依據的是LLD；進行集成測試時，設計測試用例依據的是HLD。下面給出來的是需要測試的實際的代碼。
?
int?ctrl(int?x,?int?y)
{
int?temp=0;
if(x>=y)
????temp=add(x,?y);
else
????temp=sub(x,?y);
return?temp;
}
int?add(int?x,?int?y)
{
????return(x+y);
}
?
?
?
?
?
int?sub(int?x,?int?y)
{
????return(x-y);
}
?
?
?
2?自頂向下單元測試策略
不同測試步驟中的驅動可以寫到一起，也可以分開寫，這里是寫到一起了。
?
ü?測試ctrl函數
需要寫一個驅動和兩個樁。
??驅動函數
void?driver()
{
int?ret=0;
ret=ctrl(2,1);??//x>y
if(ret==3)
????printf(“testcase?JISUAN_UT_CTRL_001?pass”);
else
????printf(“testcase?JISUAN_UT_CTRL_001?fail”);
?
ret=ctrl(1,1);??//x=y
if(ret==2)
????printf(“testcase?JISUAN_UT_CTRL_002?pass”);
else
????printf(“testcase?JISUAN_UT_CTRL_002?fail”);
?
ret=ctrl(1,2);??//x<y
if(ret==-1)
????printf(“testcase?JISUAN_UT_CTRL_003?pass”);
else
????printf(“testcase?JISUAN_UT_CTRL_003?fail”);
}
?
??樁函數
int?stub_add(int?x,?int?y)
{
if(x==2?&&?y==1)
????return?3;
if(x==1?&&?y==1)
????return?2;
return?999999;
}
?
int?stub_sub(int?x,?int?y)
{
if(x==1?&&?y==2)
????return?-1;
return?999999;
}
??修改代碼
為了讓樁能體現在測試過程中，需要修改ctrl函數：
int?ctrl(int?x,?int?y)
{
int?temp=0;
if(x>=y)
????temp=stub_add(x,?y);
else
????temp=stub_sub(x,?y);
return?temp;
}
ü?測試add函數
???驅動函數
同測試ctrl函數時的驅動
?
??樁函數
同測試ctrl函數時sub函數對應的樁
?
??修改代碼
int?ctrl(int?x,?int?y)
{???int?temp=0;
if(x>=y)
{
????temp=add(x,?y);
????if(x==2?&&?y==1?&&?temp==3)
????????printf(“testcase?JISUAN_UT_ADD_001?pass”);
????else
????????printf(“testcase?JISUAN_UT_ADD_001?fail”);
????if(x==1?&&?y==1?&&?temp==2)
????????printf(“testcase?JISUAN_UT_ADD_002?pass”);
????else
????????printf(“testcase?JISUAN_UT_ADD_002?fail”);
}
else
????temp=stub_sub(x,?y);
return?temp;
}
ü?測試sub函數
??驅動函數
同測試ctrl函數時的驅動
??樁函數
無
??修改代碼
int?ctrl(int?x,?int?y)
{??
?int?temp=0;
if(x>=y)
????temp=add(x,?y);
else
{????temp=sub(x,?y);
????if(x==1&&y==2?&&?temp==-1)
????????printf(“testcase?JISUAN_UT_SUB_001?pass”);
????else
????????printf(“testcase?JISUAN_UT_SUB_001?fail”);
}
return?temp;???}
?
?
?
?
?
?
?
?
?
?
集?成?測?試
一．?What：什么是集成測試
? 集成測試(Integration?Testing)?集成測試也叫組裝測試、聯合測試、部件測試、子系統測試
? 集成測試測什么
??????1.外部接口：各件吶在一起后表現的功能
??????2.內部接口：各件間的接口是否正確?
? 集成蘇的目的
驗證軟件的組建對概要設計說明書的符合度
? 集成測試的評估基準：
??????接口覆蓋率
???????????A.接口被測試到的百分比
???????????B.接口的等價類、邊界值的覆蓋率
二．?Why：為什么要做集成測試
? 一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常的工作。
? 程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現。
? 雖然已經有了IT和ST，但IT和UT、ST關注點不一樣，它們互為補充
? 反分解性公理：為一個被測模塊獲得的覆蓋并不能覆蓋他所調用的模塊。
? 反組合性公理：對于一個模塊中的對各子模塊分別合適的測試包并不一定對作為一個整體的模塊合適
三．?Who：誰做集成測試
? 開發人員做
???A優勢:一般來說，編程能力稍強
???B劣勢:Protect（就像變形金剛的汽車人），心理上不愿意否定自己的勞動成果，職責是保護程序
? 測試人員做
???A優勢:Destroy（就像變形金剛的霸天虎），心理上追求完美，職責是挑刺、破壞程序
???B劣勢:目前的現狀，大部分tester編程能力不夠
四．?When：什么時候做集成測試
4.1?集成測試所處的測試過程
? 集成測試所處的測試過程
???A.測試準備活動在開發活動時可以并行開展，如開始做HLD設計時就可以開始做ITP了
???B.測試執行活動在單元測試的基礎上進行
五.?Where：對什么部分做集成測試
? 子系統間集成（系統內集成）
? 模塊間集成（子系統內集成）
? 函數間集成（模塊內集成）
六.?How：怎么做集成測試
6.1?測試過程的制定
6.1.1?計劃
根據SVVP制定ITP
6.1.2?設計
根據ITP制定IT方案
6.1.3?實現
根據IT方案制定IT用例
6.1.4?執行
根據IT用例進行集成測試，提交Bug?Report，……，回歸測試
6.2?采用的測試方法
6.2.1?灰盒測試
隨集成層次不同，灰度隨之相應變化
6.3?制定集成測試策略?Test?Strategy
6.3.1?根據被測對象（層次）選擇合適的策略
1>大爆炸集成?Big?Bang
?
優點
方法簡單、效率高
缺點
? "急于求成"，成功率不高
? "大海撈針"，導致即使發現問題也難以定位（無法故障隔離）
? "囫圇吞棗"，許多內部接口的錯誤被漏測
適用范圍
? 小項目、維護型項目
? 軟件結構不清晰的系統
2>自頂向下集成?Top-Down
子策略
? 深度優先（Depth-First）
? 廣度優先（Broadth-First）
優點
A.主控模塊（高層組件）得到較早驗證
B.深度優先策略能夠較早驗證一個完整的功能，增強了開發信心
C.基本不需要開發驅動，減少了這部分的工作量
D.和高層設計順序一致，方便并行開展
E.定位問題容易，支持故障隔離
缺點
A.需要開發大量的樁，工作量、成本太大
B.底層變更可能導致測試推倒重來
C.底層組件的驗證較晚，測試不充分
適用范圍
A.軟件結構清晰的系統
B.高層接口變化小，底層接口變化大
C.主控模塊風險大，需盡早驗證
D.希望盡早看到系統一部分功能
3>自底向上集成?Bottom-Up
優點
A.底層組件得到較早驗證
B.測試初期可以并行集成，效率高
C.由于驅動模塊是額外編寫的，對被測模塊的可測試性要求較低
D.減少了開發樁的工作量
E.定位問題容易，支持故障隔離
缺點
A.需要開發大量的驅動，工作量、成本同樣很高
B.對高層的驗證太晚了，設計上的缺陷不能被及早發現
C.集成到頂層后，對于底層異常將難以覆蓋。而使用樁將簡單得多
適用范圍
A.軟件結構清晰的系統
B.底層接口穩定、或先被開發出來
C.高層接口變化較頻繁
4>?三明治集成（分而治之策略）?又分為傳統型和改進型?Sandwich
優點
融合了自頂向下和自底向上兩種策略的優點
缺點
中間層測試要么不充分，要么測的充分但開發驅動和樁的工作量大
適用范圍
軟件結構清晰的系統基本都適合采用
5>基干集成（內核耦合度高）?Backbone
結構與策略：內核（大爆炸）-應用子系統（自底向上）-控制子系統（自頂向下）
優點
具有三明治集成的優點
缺點
A.對系統結構的分析存在一定難度
B.由于被測系統復雜，驅動和樁的開發工作量較大
C.局部采用了大爆炸策略，存在大爆炸所有的缺點
適用范圍
嵌入式系統
6>分層集成（線性關系）?Layers
集成方式
A.層內集成
策略非常靈活，可以是各種其他策略
優缺點根據策略而變
B.層間集成
策略和優缺點同"層內集成"
使用范圍
有明顯線性層次關系的系統
7>基于功能集成?Function-Based
優點
A.可以盡早驗證關鍵組件的功能
B.可能同時加入多個模塊，與大爆炸類似，效率較高
C.和自頂向下一樣，驅動模塊的開發工作量不多
缺點
A.兼具大爆炸和自頂向下的缺點，比如對有些接口測試不充分，可能導致漏測
B.可能會有較多的冗余測試
適用范圍
對功能的實現沒把握的產品
8>持續集成（高頻集成、每日集成）?Continuous/High-frequency
優點
A.錯誤能被較早發現，且容易定位
B.開發和集成可以并行，效率高
缺點
測試針對性不強，不容易發現有價值的問題
適用范圍
迭代開發、增量開發的產品
9>基于進度集成?Schedule-Based
優點
并行度高，能縮短項目進度
缺點
組件間缺乏整體性，無法有效集成
開發驅動和樁的工作量難以估計
由于進度原因，集成效果不好
適用范圍
進度很緊的項目
10>基于風險集成?Risk-Based
優點
風險大的模塊得到較早驗證，有助于系統的快速穩定
缺點
風險分析偏差導致集成重點的偏離
適用范圍
有些組件有較大的風險，需及早驗證以增強信心
11>基于消息（事件）集成?Message-Based/Event-Based
優缺點與"基于功能集成"類似，適用面向對象系統
12>基于使用集成?Use-Based
優缺點與"自底向上"類似，適用面向對象系統
13>基于C/S、B/S的集成
適用C/S、B/S結構的系統
14>分布式集成?Distributed?Services
適用分布式系統
系?統?測?試
? 定義
System?Testing--是將已經集成好的軟件系統，作為整個計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其他系統元素結合在一起，在實際運行使用的環境下，對計算機系統進行系列的測試活動；
? 對象
1.產品級--軟件+硬件
2.項目級--軟件（也可能包含硬件）
? 完備性
如何保證系統測試的完備性？
1.盡可能所有需求都有對應的Test?Case;
2.依據軟件的質量特性，以不同的角度，測試需求;
3.依據不同的Test?Case、方法，構造不同的測試數據及處理過程;
常用測試方法
1.1?功能測試（功能）
? 定義：
function?Testing--依據SRS和測試需求列表驗證產品的功能是否實現和是否符合產品需求規格
? 目標：
1.是否有不正確或遺漏了的功能？
2.功能是實現是否滿足用戶需求，和系統設計的隱式需求？
3.輸入能否正確接受？能否正確輸出結果？
1.2?性能測試（效率）
? 定義：
Performance?Testing--測試該軟件在集成系統中的運行性能。（大多使用工具測試）
? 目標：
度量系統相對與預定義目標的差距。
? 實施：
1.性能指標定義明確。
2.構造性能測試研究數據。
3.構造不同的性能測試場景。
4.執行性能測試?（一般>90%就通過）。
5.性能分析。
6.性能故障定位。
7.性能優化。
? 依據
1.資源占用性。
2.CPU響應時間。
? 區別：
1.壓力測試--不強調施壓量，只檢查施壓的狀況。
2.容量測試--強調施壓，施了多少壓。
3.性能測試--施壓后檢驗性能指標是否達到規定資源使用和響應時間的要求。
1.2.1?資源方面（資源占用情況）
? CPU使用情況。
? IO使用情況。
? 內存使用情況。
? 信道使用事情。
1.2.2?時間方面（CPU響應時間）
? 每個模塊執行時間百分比。
? 一個模塊等待IO完成的百分比。
? 指令隨時間的跟蹤路徑。
? 每一組指令頁換入和換出的次數。
? 系統反映時間。
? 系統吞吐量，即每個單元的處理數量。
? 所有主要指令的單元執行時間。
1.3?壓力測試/極限測試（可靠性）
? 定義：
Stress?Testing--系統在其資源超符合的情況下表現。
? 目標：
在極限或者惡劣的環境下，系統的自我保護能力。主要驗證系統的可靠性。
? 實施：
1.同一時間，大量的用戶登陸。
2.引入大量的操作。
? 目的：
1.是否存在內存泄露。
2.驗證系統可靠性。
3.測試后給予用戶一個明確的界定。
? 區別：
1.壓力測試--不強調施壓量，只檢查施壓的狀況。
2.容量測試--強調施壓，施了多少壓。
3.性能測試--施壓后檢驗性能指標是否達到規定資源使用和響應時間的要求。
1.4?容量測試
? 定義：
volume?Testing--使系統能夠承受超額的數據容量來發現它是否能夠正確處理。
? 目標：
1.測試系統容量是否滿足需求規定系統容量。
2.若無規定系統容量可以通過此測試給出明確容量界定。
? 實施：
1.構造一批大容量的測試數據輸入到系統。
2.對系統整體構造不同業務場景，反復執行。
? 區別：
1.壓力測試--不強調施壓量，只檢查施壓的狀況。
2.容量測試--強調施壓，施了多少壓。
??????3.性能測試--施壓后檢驗性能指標是否達到規定資源使用和響應時間的要求。
1.5?安全性測試（功能）
? 定義：
Security?Testing--驗證集成在系統內的保護機制能否在實際應用中保護系統不受到非法的侵入。
? 目的：
保證系統安全性，數據的完整性、保密性。
1.5.1?數據
完整性
? 數據存儲的完整性。
? 數據保密的完整性。
保密性
? 數據存儲的保密性。
? 數據訪問的保密性。
1.5.2?權限
? 權限的分配
? 權限的使用
1.5.3?協議
多在手機測試用到。
1.5.4?其他
如LOG..
1.6?GUI測試（易用）
? 定義：
Graphical?User?Interface?Testing--針對軟件系統的界面進行的測試。
? 目標：
1.界面實現與界面設計的吻合情況。(界面設計)
2.確認界面處理的正確性。（針對不同的控件分析）
? 相關自動化測試工具
1.WinRunner
2.SilkTest
3.QaRun?
1.6.1?簡單界面元素
? 定義：
指功能和屬性相對比較單一的界面區域，即通常所指的各種控件。
? 方法：
主要關注他們的外觀、表現行為。
1.6.2?組合類界面元素
? 定義：
一些復雜的界面元素，比如表格、各種文本編輯器等。
? 方法：
先將其分解為簡單的界面元素，然后再進行處理。
1.6.3?完整界面（窗口）
? 定義：
由一系列界面元素通過適當的形式組合而成的界面形式，最為常見的為各種窗口。包括各種對話框、單文檔窗口、多文檔窗口，多文檔子窗口等。
? 方法：
外觀、布局、行為。
1.輸入類界面元素：與要考慮其外觀、輸入時的特性比如回顯、對齊原則、滾動原則等內容。
2.輸出類界面元素：外觀。
?
1.7?可用性測試（易用）
? 定義：
Usability?Testing--為檢測用戶在理解和使用系統方面到底有多好。
? 目標：
1.考慮產品是否符合實際應用情況。
2.是否符合用戶習慣或特殊要求。
3.操作方式是否方便合理、設備和用戶見交互信息是否準確易于理解、是否遵從行業習慣、外觀/界面是否美觀等。
? 一般關注的可用性問題：
1.過分復雜的功能或指令。
2.困難的安裝過程。
3.錯誤信息過于簡單。
4.用戶被迫去記太多信息。
5.語法、格式和定義不一致。
?
1.8?安裝測試
? 定義：
根據軟件測試特性列表、軟件安裝、配置文檔，設計安裝過程的測試用例，發現軟件在安裝過程中的錯誤。
? 被測對象：
1.軟件本身。
2.軟件安裝文檔。
1.8.1?安裝測試前要檢查的工作
1.安裝文檔是否齊全。
2.安裝軟件的程序文件是否齊全。
3.被測軟件的安裝文件是否齊全。
4.軟件的安裝說明文檔是否齊全。
5.檢查軟件的文件格式是否與安裝說明文檔中要求的文件格式相符。
1.8.2?安裝測試過程中的工作
1.所有的預置數據是齊全。
2.軟件環境配置是否合理。
3.硬件環境配置是否合理。
4.用戶選擇的一套任選方案是相容。|
5.安裝過程中：
A.系統提供的缺省參數值進行安裝測試。
B.指定由人工完成安裝過程，列出每一步安裝步驟所需的工作，并仔細檢查每一安裝步驟所完成工作的正確性。
C.安裝測試過程中要設計異常的安裝測試用例，包括配置參數的異常、安裝選項和安裝路徑的異常。
6.安裝文檔的測試。
1.8.3?安裝后要做的檢查工作
1.所有文件是否都已產生并確有所需的內容。
???A.程序文件的目錄是否正確產生。
???B.各目錄及子目錄下的程序文件是否都正確產生。
???C.是否存在無用的目錄、子目錄、程序文件以及無用的子目錄。
???D.目錄、子目錄、以及程序文件本身的權限是否正確。
???E.對于Windows?還要檢查與應用軟件相配套的動態鏈接庫文件齊全。
2.安裝日志的檢查。
3.安裝完成后，要進行程序的運行，聯結驗證。
4.軟件的卸載測試。
1.8.4?安裝測試中軟件的升級測試
1.軟件通過重新安裝來達到升級的目的。
2.通過Patch的方式實現軟件的升級。
3.在線升級。
?
1.9?配置測試
? 定義：
系統在各種軟硬件配置、不同參數配置下系統具有的功能和性能。
? 目標：
驗證全部配置的可操作性，有效性。
?
1.10?異常測試/恢復性測試（可靠）
? 定義：
容錯性測試。通過人工干預手段產生異常，能檢驗系統的容錯、恢復能力，是系統可靠性評價的重要手段。
? 異常處理
1.系統自動處理。
2.人工干預處理。
? 注意
1.系統的異常還與系統的指標測試有關，當系統的服務能力大于系統的設計指標時，也屬于系統的異常情況。
2.系統的可靠性是設計出來的，而不是測試出來的。測試出的數據有助于為我們進一步的系統優化設計積累經驗，設計和測試是一個相互反饋的過程。
?
1.11?備份測試（可靠）
恢復性測試的一個補充，驗證軟件或硬件失敗中備份他數據的能力。
1.12?健壯性測試（可靠）
Robustness?Testing?用于測試系統在故障時，是否能夠自動恢復或者忽略故障繼續運行。
1.13?文檔測試
Documentation?Testing?測試文檔的正確性，保證操作手冊的過程能夠正常工作。
1.14?在線幫助測試
Online?Help?Testing?檢測時實在線幫助的可靠性和正確性。
1.15?網絡測試
網絡環境下和其他設備對接，進行系統功能、性能與指標方面的測試，保證對接的正確性。
1.16?穩定性測試
在一定負荷情況下能持續運行的時間。
?
2?系統測試測試過程
2.1?計劃階段
明確what目標、why測試目的、when可控時間、where測試范圍、how如何開展.主要活動有：參與開發人員軟件需求的分析，SRS評審，通過后寫ST計劃，進行ST計劃評審。
? 入口準則：SRS完成并確定需求規格基線
? 輸入：SRS|SDP|SVVP
? 出口準則：ST計劃評審通過
? 輸出：
2.2?設計階段
主要活動有：組織人員依據測試計劃編寫測試方案，并進行系統方案的評審
? 入口準則：??ST計劃評審通過
? 輸入：?????????ST計劃|SRS
? 出口準則：??ST方案評審通過
? 輸出：?????????ST方案
?
2.3?實現階段
主要活動有：組織人員依據ST方案編寫測試用例、測試規程及預測試項，并對其進行評審
? 入口準則：??ST方案評審通過
? 輸入：?????????ST計劃|SRS|ST方案
? 出口準則：??測試用例、測試規程及預測試項評審通過
? 輸出：?????????測試用例、測試規程及預測試項
?
2.4?執行階段
主要活動有：組織測試執行活動、負責缺陷報告返回給開發部門修改、組織進行測試報告的編寫、組織進行測試報告的評審
? 入口準則：??測試用例、測試規程及預測試項的評審通過
? 輸入：?????????ST計劃|ST方案|ST用例|ST規程|ST預測試項
? 出口準則：??ST報告評審并通過
? 輸出：?????????ST預測試報告|ST測試報告|缺陷報告
?
?
?
?
?
測?試?覆?蓋?率
1、?覆蓋率概念：
·?覆蓋率是用來度量測試完整性的一個手段。覆蓋率是測試技術有效性的一個度量。覆蓋率=（至少被執行一次的item數）/item的總數；
·?覆蓋率大體可以劃分為兩大類：邏輯覆蓋和功能覆蓋；
·?測試用例設計不能一味追求覆蓋率，因為測試成本雖覆蓋率的增加而增加。
2、?邏輯覆蓋主要類型：語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、路徑
覆蓋。
3、?語句覆蓋率：（Statement?Coverage），在測試時運行被測程序后，程序中被執
行到的可執行語句的比率；??????????????????語句覆蓋率?=?
（至少被執行一次的語句數量）/（可執行的語句總數）
4、?分支覆蓋率：（Branch?Coverage）也叫判定覆蓋（Decision?Coverage），它的含
義是：在測試時運行被測程序后，程序中所有判斷語句的取真分
支和取假分支被執行到的比率；
判定覆蓋率=（判定結果被評價的次數）/（判定結果的總數）
5、?條件覆蓋率：（Condition?Coverage）的含義是，在測試時運行被測程序后，所
有判斷語句中每個條件的可能取值（真值和假值）出現過的比率；
條件覆蓋率=（條件操作數值至少被評價一次的數量）/（條件操作數值的總數）
6、?分支-條件覆蓋率：（Branch?Condition?Coverage）也叫判定條件覆蓋（Decision
?Condition?Coverage），它的含義是，在測試時運行被測程序
后，所有判斷語句中每個條件的所有可能值（為真為假）
和每個判斷本身的判定結果（為真為假）出現的比率；
分支條件覆蓋率=（條件操作樹枝或判定結果至少被評價一
次的數量）/（條件操作數值總數+判定結果總數）
7、?路徑覆蓋率：（Path?Coverage）的含義是，在測試時運行被測程序后，程序中
所有可能的路徑被執行過的比率；
路徑覆蓋率=（至少被執行到一次的路徑數）/（總的路徑數）
8、?其他覆蓋率：功能覆蓋率；面向對象的覆蓋率；函數覆蓋；指令塊覆蓋；判定
路徑覆蓋。
測?試?用?例?舉?例
| 測試用例編號 | BOSS_?ST_?MARKETING_NEW_01P |
| 重要級別 | 高（還有“較高、中、較低、低”幾個等級） |
| 測試項目 | 新增營銷記錄 |
| 測試標題 | 新增10元的營銷記錄 |
| 用例類型 | 基本事件（對應還有“備選事件”、“異常事件”） |
| 用例設計者 | songfun |
| 設計日期 | 2005-04-25 |
| 對應需求編號 | REQ_?MARKETING_NEW_01 |
| 對應UI | Marketing.htm |
| 對應UC | UC_?MARKETING_NEW_01 |
| 版本號 | Build?v0.1 |
| 對應開發人員 | Frank |
| 預置條件 | 操作員登錄營銷管理系統 |
| 測試方法 | 等價類劃分（對應還有“錯誤猜測法”、“邊界值分析”等） |
| 輸????入 | 用戶名：51testing?性別：男?金額：10元?描述：aaaaaaa |
| 操作步驟 | ①.?進入【營銷下發】頁面； ②.?點擊『增加』按鈕； ③.?輸入相應數據； ④.?點擊『確定』按鈕； ⑤.?在后臺數據庫(test/test@testDB)輸入查詢語句驗證：select?*?from?MarketingTab?where?ID='1001' |
| 預期輸出 | ㈠.?執行步驟④后，頁面彈出添加成功提示信息框； ㈡.?執行步驟⑤后查詢數據庫，記錄確實添加成功且數據無誤 |
?
同?行?評?審
1、?同行評審：（Peer?Review）是一種通過作者的同行來確認缺陷和需要變更區域的檢查方法。需要進行同行評審的特定產品在定義項目軟件過程的時候被確定并且作為軟件開發計劃的一部分被安排了進度。
??????????????·?需要前期準備、計劃和時間進度表
??????????????·?越早越好
3、?同行評審的作用：·?早期發現缺陷；·?去除缺陷；·?降低成本；·?提高質量。
4、?同行評審的類型：·?正規檢視：（Inspection）最嚴格，要求有規范的流程，參
加者經過正式培訓；
·?技術評審：（Technique?Review）以技術方案的比較、裁決
為目的，嚴格程度介于正規檢視和走讀之間；
·?走????讀：（Walk?Through）最（自由）松散的形式，無流程要求，有評審團隊，評審流程無要求。
5、?通用評審流程步驟（正規檢視流程）：
?
?
?
?
?
?
?
?
?
?
?
?
?
6、?計劃階段：
·?項目負責人指定組織者；·作者自檢工作產品；·?組織者規劃本次評審；
·?檢查入口準則：是否符合文檔標準？是否已用工具檢查？代碼<=500行；
?????????????????文檔<=40頁；……
·?準備評審包：工作產品（HLD）；參考資料（SRS-檢查一致性）；評審表（Review?Form）；查檢表（Checklist）。
·?指定評審專家（3-6人）；
·?組織者將評審包、評審通知單發給相關人員。
7、?介紹會議：
·?被評審對象采用新技術、新方法；·?被評審對象第一次被評審?à（作者介紹被審對象以及相關技術）
·?評審專家第一次參加評審??à?（評審者介紹評審流程）
·?介紹會議的召開距接到評審通知的時間大于5小時；
·?介紹會議的時間不超過1小時，30-60間為宜，關注講解。
8、?準備階段：（最重要、發現缺陷最多）
·?評審專家個人獨立完成工作產品的審視，提出缺陷；
·?準備時間?大于?會議時間，且應于會議前2天開始；
·?評審者：收到組織者發來的評審包；審核工作產品、發現缺陷；填寫評審表單；反饋評審表單給組織者；
???組織者：檢查評審表單；裁決是否需要增加評審評審投入（增加準備時間；增加評審專家人數；更換評審專家）
9、?會議階段（2小時內；只提出問題，不關注解決）：
·?組織者召開評審會議；
·?講解員講解工作產品；（盡量不要由作者兼任）
·?大家共同確認問題（評審表單中記錄的問題；會上發現的問題；當爭執不
下時組織者應做出裁決）
·?對已確認的問題進行分類；
·?作者決定是否召開第三小時會議；
·?記錄員記錄所有的問題及分類，并發給組織者；（記錄員盡量不要由作者和組織者擔任）
·?組織者更新評審表單。
10、?第三小時會議
·?有爭議的問題繼續討論，給出決議；
·?討論解決問題方案；
·?組織者更新評審表單。
11、?返??工：發回作者修改；
12、?跟??蹤：
·?匯總所有需要的數據到評審表單發給相關評審專家；（a2組織者）
·?組織評審專家確認各缺陷得到了修改，并且沒有引入新的缺陷；
·?協助組織者確認相關問題得到了正確修改并且沒有引入新的缺陷；
·?確認評審表單中各相關度量數據正確（發現缺陷數；評審投入時間；評審專家人數等）（評審專家á2）
配?置?&?需?求?管?理
1、?配置管理的目的和意義：
目的：a.?可視性：用戶/買方/賣方詳細知道工作內容；
??b.?管理層能夠知道產品特性；
??????c.?所有的項目參與者在同一平臺下交流；
??????d.?了解現在和計劃的配置；
??????e.?管理層可看到變更的影響；
??????f.?管理層可選擇參與的節點；
目標：????項目：減少返工，減少工作量；
意義：????????????????公司：節約成本，積累項目財富；
????????????可視性提高；
????????????項目可跟蹤性高；
2、??配置、基線、版本各自定義及關系：
配??置：是軟件生命周期個階段產生的程序、數據、文件、環境的集合；
配置項：是軟件生命周期個階段產生的程序、數據、文件、環境
基??線：配置項在其生命周期的不同時間點上通過評審而進入正式受控的一種狀態，而這個過程被稱為“基線化”；
版??本：是表示一個配置項具有一組定義的功能的一種標識；
3、??變更控制的流程（各種角色、職責輸出）：
·?項目成員、客戶代表、市場人員提交CR
·??CMO將CR狀態表示為已提交，并將CR根據條件進行判斷，把不需要CCB進行審核的、決定采納的CR直接進行簽發；把不需要CCB進行審核的、不決定采納的CR直接關閉（4?CMO將CR狀態標識為已拒絕）；將需要CCB評審的CR提交給CCB進行評估；
·?CCB召開會議對CR進行評估??
????·?CMO將CR狀態標識為已接受，將CR于要修改的配置項發給項目組成員并開放CI的配置庫權限
????·?項目組成員執行更改并進行驗證
????·?CCB召開會議對修改進行審核，如果通過將CR狀態表示為已驗證，發給CMO，否則直接關閉，并給出提交人反饋信息
4、?配置管理中測試工程師的職責：
·?測試工程師將自己創建的與測試相關配置項（比如軟件測試計劃、軟件測試方案、軟件測試用例、軟件測試日報、軟件測試報告等）加入配置庫中；
·?測試工程師根據變更請求，對已經基線化的配置項進行Check-Out、修改、Check-In操作。比如，在測試執行之前，需要更新測試用例，此時需要經過CMO的授權，然后由測試人員對相應的配置項（測試用例文件）Check-Out、修改、Check-In
5、?需求跟蹤涉及到的配置項
?
?
?
?
?
?
?
6、?配置項的跟蹤矩陣
Input————————————Task————————————Output
缺?陷?管?理
1、??缺陷管理的目的：·?保證信息的一致性；保證缺陷得到有效跟蹤，解決；
???·?獲取正確的Bug信息，用作缺陷分析和產品度量。
2、?缺陷的相關屬性：·?缺陷發現人（Defect?Reporter）；
·?缺陷發現時間（Defected?on?Date）；
·?缺陷狀態（Status）；
·?缺陷嚴重程度（Sewrity）；
·?缺陷所屬版本（Defected?in?Version）；
·?優先級（Priority）
·?缺陷修改日期（Fixed?on?Date）；
·?再現性（Reproducible）；
·?回歸測試（Regression）；
3、?缺陷管理流程：（參考缺陷管理作業）
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
4、?缺陷跟蹤單寫作準則（5C）
·?Correct（準確），每個組成部分的描述準確，不會引起誤會；
·?Clear（清晰），每個組成部分的描述清晰，易于理解；
·?Concise（簡潔），只包含必不可少的信息，不包括任何多余的內容；
·?Complete（完整），包含復現該缺陷的完整步驟和其他本質信息；
·?Consistent（一致），按照一致的格式書寫全部缺陷報告。
5、?缺陷跟蹤單基本內容：（其他相關屬性）；簡單描述；詳細描述；相關附件。
6、?QC中缺陷管理流程：（實際流程應參考各公司內部流程或者書本）
1.?Qatester提交一個狀態為new的新缺陷后assigned?to?PM?
2.?PM查看該缺陷，并判斷是否為缺陷需要修改?:
nà?在comments中記錄否決意見后closed;
???????????????????????????????yà?在comments中記錄相關意見后將該缺陷指派給相關開發人員，并將status置為open/reopen
3.?Developer打開缺陷模塊，看到指派給自己的缺陷后確定是否修改：
???????????????????nà?在comments中記錄意見后rejected?to?PMà2
???????????????????????????????yà?修改該缺陷，并將status置為fixed指給PM
4.?PM將該缺陷指派給Qatester進行回歸測試
5.?Qatester看到指派給自己的fixed的缺陷后，進行回歸測試，通過？?
???????????????????yà?closed;
??nà?rejected給PMà2
7、缺陷度量—評價軟件技術/流程/組織指標的公式
ü? 分析指標
1．?反映產品質量的指標
缺陷密度=缺陷數量/軟件規模（千行代碼數）
潛在缺陷概數=（100%-發布前缺陷的缺陷去除率）*缺陷密度
2．?反映產品可靠性的指標
平均實效時間=軟件持續運行時間/缺陷數量
3．?反映缺陷發現及修復效率的指標
缺陷檢出率=某階段發現的缺陷/屬于該階段的全部缺陷*100%
發布前缺陷去除率=發布前發現的缺陷/（發布前發現的缺陷+軟件運行前三個月）*100%
缺陷修正率=修復過程中未引發其他問題的缺陷數/被修復缺陷的總數*100%
4．?反映缺陷修復成本的指標
平均修復時間=∑缺陷修復時間/缺陷數量
平均修復成本=開發人員的平均人力成本*平均修復時間
相對返回成本=返工的工作量/項目總工作量*100%
ü?匯總統計
1．缺陷發生的日期統計（缺陷發現趨勢圖）
2．缺陷性質統計（缺陷變更，需求變更）
3．缺陷狀態分布（關閉，修復中，掛起等）
4．缺陷按子系統（模塊）分類統計
5．缺陷引發原因分類統計
6．缺陷來源統計（缺陷提交人或提交方）
?
SQL?SERVER（需搭建SQL?SERVER環境）
??數據定義語言（DDL）
??Create?table?創建數據庫的表
??Create?index?創建數據庫表的索引
??Drop?table?刪除數據庫表
??Drop?index?刪除數據庫表的索引
??Truncate?table?刪除表的所有行
??Alter?table?修改表：增加表列、重定義表列、更改存儲分配等
??Alter?table?add?constraint?在已有的表上增加約束
?
??數據操作語言DML
??Insert?增加數據行
??Delete?從表里刪除行
??Update?更改表中數據
??Select?從表或視圖中檢索數據行
?
??數據控制語言DCL
??Grant?將權限或角色授予用戶或其他角色
??Revoke?從用戶或數據庫角色回收權限
??Set?role?禁止或允許一個角色
?
??數據庫事務控制
??Commit?work?把當前事務所作的更改永久化（寫入磁盤）
??Rollback?作廢上次提交以來的所有更改
?
??Where語句中的通配符：Select?*?from?objects?where?object_namelike?‘sql#_m_il’?????escape?‘#’
??字符類型轉換：?例：convert(varchar(5),@varage)
?
??匯總函數
??平均值avg
??總和sum
??最小值min
??最大值max
??計數count
??Count（*）和count?(distinct?)
?
?
??Insert語句
??Insert?into?表名（列名1，n）value?（值1，n）
??Insert?into?student?values?(20051115,’黃飛鴻’,’男’,21,’cs’)
??Insert?into?student(sname,sno,sdept)?value(‘劉德華’,20055567,’cs’)
??未指明的字段內容為null
??Insert?into?表名（列名1，n）select?語句；如：
??Insert?into?student2(sno,sname,sdept)?select?sno,sname,sdeptfrom?student1
??前提是兩個表的結構相同
?
??Update語句
?Update?表名set?列名1=表達式1，列名2=表達式2..?Where?條件
?Update?student?set?sdept=?‘MA’where?sno=?‘95001’
?所有學生年齡加1
?Update?student?set?sage?=?sage+1
?該語句只對單個表操作，不能同時對多表操作
?該語句僅當事務提交（commit）后才生效；也可通過事務回滾rollback來作廢操作
?
??在SQL?Server?2000中有5種約束：
主鍵約束（primary?key?constraint）
唯一性約束（unique?constraint）
檢查約束（check?constraint）
缺省約束（default?constraint）
外部鍵約束（foreign?key?constraint）
2?課程實例：
---創建表"訂單A"
create?table?訂單A(訂單編號?int?not?null,
??????????????????下單日期?datetime?not?null,
??????????????????客戶編號?int?not?null)
select?*?from?訂單A
?
?
---首先添加訂單名稱,varchar(20),null
alter?table?訂單A
add?訂單名稱?varchar(20)?null
select?*?from?訂單A
?
---之后刪除訂單名稱字段
alter?table?訂單A
drop?column?訂單名稱
select?*?from?訂單A
?
?
---然后同時添加訂單名稱,varchar(20),null和定購數量,int,null
alter?table?訂單A
add?訂單名稱?varchar(20)?null,訂購數量?int?null
select?*?from?訂單A
?
?
---然后嘗試同時修改訂單名稱的字段長度為50,定購數量數據類型為numeric*??不能同時修改*
alter?table?訂單A
alter?column?訂單名稱?varchar(50)?null
select?*?from?訂單A
alter?column?訂單名稱?varchar(50)?null?訂購數量?numeric???
?
?
---最后同時刪除訂單名稱和定購數量
alter?table?訂單A
drop?column?訂單名稱,訂購數量
select?*?from?訂單A
?
?
---向已有表"訂單A"的訂單編號字段添加主鍵約束
alter?table?訂單A
add?constraint?訂單編號_k?primary?key?(訂單編號)
select?*?from?訂單A
?
?
---創建"定購項目"表,并同時添加項目編號字段為主鍵
create?table?訂購項目(訂單編號?int?not?null,
?????????????????????項目編號?int?not?null,
?????????????????????書籍編號?int?not?null,
?????????????????????數量?int?not?null,
?????????????????????primary?key?(項目編號))
select?*?from?訂購項目
---向已有表"定購項目"添加新字段"項目名稱"和"客戶名稱",并設置項目名稱字段為唯一鍵
alter?table?訂購項目
add?項目名稱?varchar(20),客戶名稱?varchar(20)
constraint?項目名稱_u?unique?(項目名稱)
select?*?from?訂購項目
?
?
---在現有表"定購項目"上設置"客戶名稱"為唯一鍵
alter?table?訂購項目
add?constraint?客戶名稱_u?unique?(客戶名稱)
?
?
---設置數量字段必須在10到100之間
alter?table?訂購項目
add?constraint?chk_數量?check?(數量?between?10?and?100)
?
insert?into?訂購項目?values(1,2,3,4,'張三','李四')???
---檢測數量字段的約束條件是否成立
?
create?table?sincky(myid?int?identity(10,1)?not?null,???????????
---通過函數實現自動增量
yourid?varchar(10))
?
?
---添加"定購地點"字段,默認值是"上海"
alter?table?訂購項目
add?訂購地點?varchar(50)?null?default?'上海'????????????---設置缺省約束
?
create?table?書籍(書籍編號?int?not?null?primary?key,
??????????????????書籍名稱?varchar(50)?null,
??????????????????價格?smallmoney?null,
??????????????????出版公司?char(20))
?
alter?table?訂購項目
add?constraint?訂單項目_f?foreign?key?(書籍編號)?references?書籍(書籍編號)
存儲過程：
?
if?exists?(select?*?from?sysobjects?where?name='sinckypro'?and?type='p')
drop?procedure?sinckypro
go
?
create?procedure?sinckypro
@varname?varchar(50),@varage?int?????
as????
declare?@inname?varchar(50)
set?@inname?=?'sincky_'+?@varname
create?table?testtable(myid?int?not?null?primary?key,
myname?varchar(50)?not?null,
mypasswd?varchar(20)?not?null,
myage?int?default?25)
?
insert?into?testtable?values(1,@inname,'zhang',@varage)?
select?*?from?testtable
drop?table?testtable
go
?
exec?sinckypro?'51testing',55??
?
?
測試工具總結
| ?測試工具大全 | |||
| 工具類別 | 工具名稱 | 生產廠商 | 相關網站 |
| 通用功能自動化測試工具 | Winrunner | Mercury |
|
| Quicktest?pro | Mercury |
| |
| Xrunner | Mercury |
| |
| QARun | Compuware |
| |
| TestPartner | Compuware |
| |
| WebKing | Parasoft | http://www.parasoft.com | |
| Robot | IBM?Rational | http://www.ibm.com/cn | |
| Visual?Test | IBM?Rational | http://www.ibm.com/cn | |
| Functional?Tester | IBM?Rational | http://www.ibm.com/cn | |
| SilkTest | Segue |
| |
| SilkTest?International | Segue |
| |
| e-Tester | Empirix |
| |
| WebFT | Radview |
| |
| TestComplete | AutomatedQA |
| |
| QA?Wizard | Seapine |
| |
| Software?EggPlant | RedStone |
| |
| Test?Edition | Microsoft?Visual?Studio |
| |
| PureTest | Minq |
| |
| Autotester | Autotester |
| |
| Testbench400 | Original?Software |
| |
| TestExpert | VEReCOMM |
| |
| TestRunner | Qronus |
| |
| TTCN?suite | Telelogic | http://www.telelogic.com.cn | |
| QC/Replay | Centerline |
| |
| Web | AutoTester |
| |
| eValid | Software?Research |
| |
| WebART | OCLC |
| |
| MaxQ | 開源 |
| |
| WebInject | 開源 |
| |
| Marathon | 開源 |
| |
| 性能測試/監控工具? | LoadRunner | Mercury |
|
| SiteScope | Mercury |
| |
| Topaz | Mercury |
| |
| QaLoad | Compuware |
| |
| PerformaSure/benchmark | Quest |
| |
| Silkperformer | Segue |
| |
| Silkperformer?Lite | Segue |
| |
| SilkCentralTM?Performance?Manager | Segue |
| |
| e-Load | Empirix |
| |
| Robot | IBM?Rational | http://www.ibm.com/cn | |
| Performance?Tester | IBM?Rational | http://www.ibm.com/cn | |
| WebLoad | RadView |
| |
| Web?applicaton?stress?tool? | Microsoft |
| |
| Application?center?test | Microsoft |
| |
| PureLoad | Minq |
| |
| Athene?APR | Metron |
| |
| ForeCast | Facilita |
| |
| Impact/Impact?for?CBT | Cyrano |
| |
| Berkeley?Laboratory?sniffer | Lawrence |
| |
| Jmeter | 開源 |
| |
| openSTA | 開源 |
| |
| Siege | 開源 |
| |
| StressMark | 開源 |
| |
| DBMonster | 開源 |
| |
| 白盒測試/代碼分析工具? | VcTester | ezTester | http://www.eztester.com |
| Jtest | Parasoft | http://www.parasoft.com | |
| C++test | Parasoft | http://www.parasoft.com | |
| SOA?test | Parasoft | http://www.parasoft.com | |
| .test | Parasoft | http://www.parasoft.com | |
| Codewizard | Parasoft | http://www.parasoft.com | |
| Insure++ | Parasoft | http://www.parasoft.com | |
| DataRecon | Parasoft | http://www.parasoft.com | |
| Numega?devpartner?studio | Compuware |
| |
| DevPartnerJavaEdition | Compuware |
| |
| BoundsChecker | Compuware |
| |
| SmartCheck | Compuware |
| |
| DBPartner | Compuware |
| |
| Bean-test | Empirix |
| |
| Aqtime | AutomatedQA |
| |
| QESatJava | AutomatedQA |
| |
| Visual?Unit | Unitware |
| |
| PC-lint | Gimpel?Software |
| |
| Macabe | Macabe |
| |
| Optimizeit?Suite | Borland |
| |
| JProbe?Suite | Quest?Software |
| |
| Application?assurance?suite | Quest?Software |
| |
| Sql?optimizer | Quest?Software |
| |
| Jprofiler | ej-technologies |
| |
| workbench | Cyrano |
| |
| Logiscope | TeleLogic | http://www.telelogic.com.cn | |
| rulecheck | TeleLogic | http://www.telelogic.com.cn | |
| SilkPerformer?Component?Test?Edition | Segue |
| |
| Purifyplus | IBM?rational | http://www.ibm.com/cn | |
| Rational?Test?Realtime | IBM?rational | http://www.ibm.com/cn | |
| junit | 開源 |
| |
| cactus | 開源 |
| |
| Hansel | 開源 |
| |
| TestNG | 開源 |
| |
| StrutsTestCase | 開源 |
| |
| JFCUnit | 開源 |
| |
| Httpunit | 開源 |
| |
| Dunit | 開源 |
| |
| cppunit | 開源 | http://sourceforge.net/projects/cppunit | |
| Nunit | 開源 |
| |
| Xunit | 開源 |
| |
| JTR | 開源 |
| |
| MallocDebug | Linux平臺工具 |
| |
| Valgrind | Linux平臺工具 |
| |
| Kcachegrind | Linux平臺工具 |
| |
| dmalloc | Linux平臺工具 |
| |
| ElectricFence | Linux平臺工具 |
| |
| LeakTracer | Linux平臺工具 |
| |
| memprof | Linux平臺工具 |
| |
| ccmalloc | Linux平臺工具 |
| |
| mprof | Linux平臺工具 |
| |
| yamd | Linux平臺工具 |
| |
| njamd | Linux平臺工具 |
| |
| mpatrol | Linux平臺工具 |
| |
| 嵌入式測試工具 | VcTester | ezTester | http://www.eztester.com |
| codetest | Metrowerks |
| |
| Cantata/cantana++ | IPL |
| |
| IceMaster | Reflex?Technology |
| |
| System?test | Reflex?Technology |
| |
| scorecast | DDC-I |
| |
| Testquest | Testquest |
| |
| UniText | ATTOL |
| |
| vectorcast | Vector?software |
| |
| testrunner | Qronus |
| |
| Logiscope | Telelogic | http://www.telelogic.com.cn | |
| 測試管理工具 | TestDirector(QualityCenter) | Mercury |
|
| QADirector | Compuware |
| |
| certify | Worksoft |
| |
| Product?manager | Aimware |
| |
| SilkCentral?Test?Manager | Segue |
| |
| Doors | Telelogic | http://www.telelogic.com.cn | |
| e-manager | Empirix |
| |
| testmanager | IBM?Rational | http://www.ibm.com/cn | |
| TestView?Manager | RadView |
| |
| Professional | T-Plan |
| |
| 缺陷管理工具 | TestDirector(QualityCenter) | Mercury |
|
| ClearQuest | IBM?Rational | http://www.ibm.com/cn | |
| TrackRecord | Compuware |
| |
| TestTrack?pro | Seapine |
| |
| TrueTrack | McCabe |
| |
| Devtrack | Techexcel |
| |
| Notes | IBM?Lotus |
| |
| SilkCentral?Issue?Manager | Segue |
| |
| PVCS?Tracker | Merant |
| |
| AR?System | Remedy |
| |
| URTrack | LealSoft |
| |
| Butterfly | Hansky |
| |
| Bugzilla | 開源 |
| |
| Mantis | 開源 |
| |
| JIRA | 開源 |
| |
| BugFree | 開源 |
| |
| 配置管理工具 | ClearCase | IBM?Rational | http://www.ibm.com/cn |
| PVCS?Version?Manager | Merant |
| |
| VCS | Diamond |
| |
| StarTeam | Borland |
| |
| Perforce | Perforce |
| |
| TRUEchange | McCabe |
| |
| SYNERGY?CM? | Telelogic | http://www.telelogic.com.cn | |
| VSS | Microsoft |
| |
| Firefly | Hansky |
| |
| CVS | Subversion |
| |
| SCCS | RCS |
| |
| CCC/Harvest | Computer?Associates |
| |
?
測試工具部分詳解
隨著軟件測試的地位逐步提高，測試的重要性逐步顯現，測試工具的應用已經成為了普遍的趨勢。目前用于測試的工具已經比較多了，這些測試工具一般可分為白盒測試工具、黑盒測試工具、性能測試工具，另外還有用于測試管理（測試流程管理、缺陷跟蹤管理、測試用例管理）的工具。
總的來說，測試工具的應用可以提高測試的質量、測試的效率。但是在選擇和使用測試工具的時候，我們也應該看到，在測試過程中，并不是所有的測試工具都適合我們使用，同時，有了測試工具、會使用測試工具并不等于測試工具真正能在測試中發揮作用。
?
u Win?Runner
1. 簡介
WinRunner:強大的企業級自動化測試工具
?
Mercury?Interactive公司的WinRunner是一種企業級的功能測試工具，用于檢測應用程序是否能夠達到預期的功能及正常運行。通過自動錄制、檢測和回放用戶的應用操作，WinRunner能夠有效地幫助測試人員對復雜的企業級應用的不同發布版進行測試，提高測試人員的工作效率和質量，確保跨平臺的、復雜的企業級應用無故障發布及長期穩定運行。?
?
企業級應用可能包括Web應用系統，ERP系統，CRM系統等等。這些系統在發布之前，升級之后都要經過測試，確保所有功能都能正常運行，沒有任何錯誤。如何有效地測試不斷升級更新且不同環境的應用系統，是每個公司都會面臨的問題。?
?
如果時間或資源有限，這個問題會更加棘手。人工測試的工作量太大，還要額外的時間來培訓新的測試人員等等。為了確保那些復雜的企業級應用在不同環境下都能正常可靠地運行，你需要一個能簡單操作的測試工具來自動完成應用程序的功能性測試。
2. 特征：?
?
1) 輕松創建測試
?
用WinRuuner創建一個測試，只需點擊鼠標和鍵盤，完成一個標準的業務操作流程，WinRunner自動記錄你的操作并生成所需的腳本代碼。這樣，即使計算機技術知識有限的業務用戶輕松創建完整的測試。你還可以直接修改測試腳本以滿足各種復雜測試的需求。WinRunner提供這兩種測試創建方式，滿足測試團隊中業務用戶和專業技術人員的不同需求。?
?
2) 插入檢查點?
?
在記錄一個測試的過程中，可以插入檢查點，檢查在某個時刻/狀態下，應用程序是否運行正常。在插入檢查點后，WinRunner會收集一套數據指標，在測試運行時對其一一驗證。WinRunner提供幾種不同類型的檢查點，包括文本的、GUI、位圖和數據庫。例如，用一個位圖檢查點，你可以檢查公司的圖標是否出現于指定位置。?
?
3) 檢驗數據?
?
除了創建并運行測試，WinRunner還能驗證數據庫的數值，從而確保業務交易的準確性。例如，在創建測試時，可以設定哪些數據庫表和記錄需要檢測；在測試運行時，測試程序就會自動核對數據庫內的實際數值和預期的數值。WinRunner自動顯示檢測結果，在有更新/刪除/插入的記錄上突出顯示以引起注意。?
?
4) 增強測試?
?
為了徹底全面地測試一個應用程序，需要使用不同類型的數據來測試。WinRunner的數據驅動向導(?Data?Driver?Wizard)可以讓你簡單地點擊幾下鼠標，就可以把一個業務流程測試轉化為數據驅動測試，從而反映多個用戶各自獨特且真實的行為。
?
以一個訂單輸入的流程為例，你可能希望把訂單號或客戶名稱作為可變欄，用多套數據進行測試。使用Data?Driver?Wizard，你可以選擇訂單號或客戶名稱用數據表格文件中的哪個欄目的數據替換。你可以把訂單號或客戶名稱輸入數據表格文件，或從其它表格和數據庫中導入。數據驅動測試不僅節省了時間和資源，又提高了應用的測試覆蓋率。?
?
WinRunner還可以通過Function?Generator增加測試的功能。使用Function?Generator可以從目錄列表中選擇一個功能增加到你的測試中以提高測試能力。例如，你可以選擇”calendar”，然后從日歷功能的下屬目錄中選擇，如Calendar_select_date(),然后你可以直觀地輸入參數，把這個功能插入到你的測試中。
?
針對相當數量的企業應用里非標準對象，WinRunner提供了Virtual?Object?Wizard來識別以前未知的對象。使用Virtual?Object?Wizard，你可以選擇未知對象的類型，設定標識和命名。在錄制使用該對象的測試時，WinRunner會自動對應它的名字，從而提高測試腳本的可讀性和測試質量。?
?
5) 運行測試?
?
創建好測試腳本，并插入檢查點和必要的添加功能后，你就可以開始運行測試。運行測試時，WinRunner會自動操作應用程序，就象一個真實的用戶根據業務流程執行著每一步的操作。測試運行過程中，如有網絡消息窗口出現或其它意外事件出現，WinRunner也會根據預先的設定排除這些干擾。
?
6) 分析結果
?
測試運行結束后，你需要分析測試結果。WinRunner通過交互式的報告工具來提供詳盡的、易讀的報告。報告中會列出測試中發現的錯誤內容、位置、檢查點和其它重要事件，幫助你對測試結果進行分析。這些測試結果還可以通過Mercury?Interactive的測試管理工具TestDirector來查閱。
?
7) 維護測試?
?
隨著時間的推移，開發人員會對應用程序做進一步的修改，并需要增加另外的測試。使用WinRunner，你不必對程序的每一次改動都重新創建你的測試。WinRunner可以創建在整個應用程序生命周期內都可以重復使用的測試，從而大大地節省時間和資源，充分利用你的測試投資。
?
每次記錄測試時，WinRunner會自動創建一個GUI?Map文件以保存應用對象。這些對象分層次組織，既可以總覽所有的對象，也可以查詢某個對象的詳細信息。一般而言，對應用程序的任何改動都會影響到成百上千個測試。通過修改一個GUI?Map文件而非無數個測試，WinRunner可以方便地實現測試重用。
?
8) 幫助你的應用程序為無線應用作準備?
?
隨著無線設備種類和數量的增加，你的應用程序測試計劃需要同時滿足傳統的基于瀏覽器的用戶和無線瀏覽設備，如移動電話、傳呼機和個人數字助理(PDA)。
?
無線應用協議是一種公開的、全球性的網絡協議，用來支持標準數據格式化和無線設備信號的傳輸。
使用WinRunner，測試人員可以利用微型瀏覽模擬器來記錄業務流程操作，然后回放和檢查這些業務流程功能的正確性。?
?
u LoadRunner?
?
1. 簡介：?
?
LoadRunner?是一種預測系統行為和性能的負載測試工具。通過以模擬上千萬用戶實施并發負載及實時性能監測的方式來確認和查找問題，LoadRunner?能夠對整個企業架構進行測試。通過使用LoadRunner?，企業能最大限度地縮短測試時間，優化性能和加速應用系統的發布周期。
?
目前企業的網絡應用環境都必須支持大量用戶，網絡體系架構中含各類應用環境且由不同供應商提供軟件和硬件產品。難以預知的用戶負載和愈來愈復雜的應用環境使公司時時擔心會發生用戶響應速度過慢，系統崩潰等問題。這些都不可避免地導致公司收益的損失。Mercury?Interactive?的?LoadRunner?能讓企業保護自己的收入來源，無需購置額外硬件而最大限度地利用現有的IT?資源，并確保終端用戶在應用系統的各個環節中對其測試應用的質量，可靠性和可擴展性都有良好的評價。
?
LoadRunner?是一種適用于各種體系架構的自動負載測試工具，它能預測系統行為并優化系統性能。LoadRunner?的測試對象是整個企業的系統，它通過模擬實際用戶的操作行為和實行實時性能監測，來幫助您更快的查找和發現問題。此外，LoadRunner?能支持廣范的協議和技術，為您的特殊環境提供特殊的解決方案。?
?
2. 特征：?
?
1) 輕松創建虛擬用戶
?
使用LoadRunner?的Virtual?User?Generator，您能很簡便地創立起系統負載。該引擎能夠生成虛擬用戶，以虛擬用戶的方式模擬真實用戶的業務操作行為。它先記錄下業務流程(如下訂單或機票預定)，然后將其轉化為測試腳本。利用虛擬用戶，您可以在Windows?，UNIX?或Linux?機器上同時產生成千上萬個用戶訪問。所以LoadRunner能極大的減少負載測試所需的硬件和人力資源。另外，LoadRunner?的TurboLoad?專利技術能。
?
提供很高的適應性。TurboLoad?使您可以產生每天幾十萬名在線用戶和數以百萬計的點擊數的負載。?
?
用Virtual?User?Generator?建立測試腳本后，您可以對其進行參數化操作，這一操作能讓您利用幾套不同的實際發生數據來測試您的應用程序，從而反映出本系統的負載能力。以一個訂單輸入過程為例，參數化操作可將記錄中的固定數據，如訂單號和客戶名稱，由可變值來代替。在這些變量內隨意輸入可能的訂單號和客戶名，來匹配多個實際用戶的操作行為。?
?
LoadRunner?通過它的Data?Wizard?來自動實現其測試數據的參數化。Data?Wizard?直接連于數據庫服務器，從中您可以獲取所需的數據（如定單號和用戶名）并直接將其輸入到測試腳本。這樣避免了人工處理數據的需要，Data?Wizard?為您節省了大量的時間。?
?
為了進一步確定您的Virtual?user?能夠模擬真實用戶，您可利用LoadRunner?控制某些行為特性。例如，只需要點擊一下鼠標，您就能輕易控制交易的數量，交易頻率，用戶的思考時間和連接速度等。?
?
2) 創建真實的負載
?
Virtual?users?建立起后，您需要設定您的負載方案，業務流程組合和虛擬用戶數量。用LoadRunner?的Controller，您能很快組織起多用戶的測試方案。Controller?的Rendezvous?功能提供一個互動的環境，在其中您既能建立起持續且循環的負載，又能管理和驅動負載測試方案。?
?
而且，您可以利用它的日程計劃服務來定義用戶在什么時候訪問系統以產生負載。這樣，您就能將測試過程自動化。同樣您還可以用Controller?來限定您的負載方案，在這個方案中所有的用戶同時執行一個動作---如登陸到一個庫存應用程序----來模擬峰值負載的情況。另外，您還能監測系統架構中各個組件的性能----?包括服務器，數據庫，網絡設備等----來幫助客戶決定系統的配置。?
?
LoadRunner?通過它的AutoLoad?技術，為您提供更多的測試靈活性。使用AutoLoad?，您可以根據目前的用戶人數事先設定測試目標，優化測試流程。例如，您的目標可以是確定您的應用系統承受的每秒點擊數或每秒的交易量。?
?
3) 定位性能問題
?
LoadRunner?內含集成的實時監測器，在負載測試過程的任何時候，您都可以觀察到應用系統的運行性能。這些性能監測器為您實時顯示交易性能數據（如響應時間）和其它系統組件包括application?server,?web?server，網路設備和數據庫等的實時性能。這樣，您就可以在測試過程中從客戶和服務器的雙方面評估這些系統組件的運行性能，從而更快地發現問題。
?
再者，利用LoadRunner?的ContentCheck?TM?，您可以判斷負載下的應用程序功能正常與否。ContentCheck?在Virtual?users?運行時，檢測應用程序的網絡數據包內容，從中確定是否有錯誤內容傳送出去。它的實時瀏覽器幫助您從終端用戶角度觀察程序性能狀況。?
?
4) 分析結果以精確定位問題所在
?
一旦測試完畢后，LoadRunner?收集匯總所有的測試數據，并為您提供高級的分析和報告工具，以便迅速查找到性能問題并追溯原由。使用LoadRunner?的Web?交易細節監測器，您可以了解到將所有的圖象、框架和文本下載到每一網頁上所需的時間。例如，這個交易細節分析機制能
?
夠分析是否因為一個大尺寸的圖形文件或是第三方的數據組件造成應用系統運行速度減慢。另外，Web?交易細節監測器分解用于客戶端、網絡和服務器上端到端的反應時間，便于確認問題，定位查找真正出錯的組件。例如，您可以將網絡延時進行分解，以判斷DNS?解析時間，連接服務器或SSL?認證所花費的時間。通過使用LoadRunner?的分析工具，您能很快地查找到出錯的位置和原因并作出相應的調整。?
?
5) 重復測試保證系統發布的高性能
?
負載測試是一個重復過程。每次處理完一個出錯情況，您都需要對您的應用程序在相同的方案下，再進行一次負載測試。以此檢驗您所做的修正是否改善了運行性能。
?
6) Enterprise?Java?Beans的測試
?
LoadRunner?完全支持EJB?的負載測試。這些基于Java?的組件運行在應用服務器上，提供廣泛的應用服務。通過測試這些組件，您可以在應用程序開發的早期就確認并解決可能產生的問題。?
?
利用LoadRunner,?您可以很方便地了解系統的性能。?它的Controller?允許您重復執行與出錯修改前相同的測試方案。它的基于HTML?的報告為您提供一個比較性能結果所需的基準，以此衡量在一段時間內，有多大程度的改進并確保應用成功。由于這些報告是基于HTML?的文本，您可以將其公布于您公司的內部網上，便于隨時查閱。?
?
7) 最大化投資回報?
?所有Mercury?Interactive?的產品和服務都是集成設計的,?能完全相容地一起運作。由于它們具有相同的核心技術，來自于LoadRunner和ActiveTest?TM?的測試腳本，在Mercury?Interactive?的負載測試服務項目中，可以被重復用于性能監測。借助Mercury?Interactive的監測功能－－Topaz?TM?和ActiveWatch?TM?，測試腳本可重復使用從而平衡投資收益。更重要的是，您能為測試的前期布署和生產系統的監測提供一個完整的應用性能管理解決方案。?
?
8) 支持無線應用協議
?
隨著無線設備數量和種類的增多，您的測試計劃需要同時滿足傳統的基于瀏覽器的用戶和無線互聯網設備，如手機和PDA。LoadRunner?支持2?項最廣泛使用的協議：WAP和I-mode。此外，通過負載測試系統整體架構，LoadRunner?能讓您只需要通過記錄一次腳本，就可完全檢測上述這些無線互聯網系統。
?
9) 支持Media?Stream應用
?
LoadRunner?還能支持Media?Stream應用。為了保證終端用戶得到良好的操作體驗和高質量Media?Stream，您需要檢測您的Media?Stream應用程序。使用LoadRunner?，您可以記錄和重放任何流行的多媒體數據流格式來診斷系統的性能問題，查找原由，分析數據的質量。
?
10) 完整的企業應用環境的支持
?
LoadRunner?支持廣泛的協議，可以測試各種IT?基礎架構。
?
u WAS?
?
1. 簡介：?
?
Microsoft?Web?Application?Stress?Tool?是由微軟的網站測試人員所開發，專門用來進行實際網站壓力測試的一套工具。透過這套功能強大的壓力測試工具，您可以使用少量的Client端計算機仿真大量用戶上線對網站服務所可能造成的影響。
?
2 特征：?
?
1）可以數種不同的方式建立測試指令：包含以手動、錄制瀏覽器操作步驟、或直接錄入IIS的記錄文件、錄入網站的內容及錄入其它測試程序的指令等方式。
?
2）支持多種客戶端接口：標準的網站應用程序C++的客戶端，使用Active?Server?Page?客戶端，或是使用Web?Application?Stress對象模型建立您自定的接口。
?
3）支持多用戶：利用多種不同的認證方式仿真實際的情況，包含了DPA,?NTLM?及?SSL等。
?
u JTEST?
１、簡介：?
jtest是parasoft公司推出的一款針對java語言的自動化白盒測試工具,它通過自動實現java的單元測試和代碼標準校驗,來提高代碼的可靠性。Jtest先分析每個java類，然后自動生成junit測試用例并執行用例，從而實現代碼的最大覆蓋，并將代碼運行時未處理的異常暴露出來；另外，它還可以檢查以DbC（Design?by?Contract）規范開發的代碼的正確性。用戶還可以通過擴展測試用例的自動生成器來添加更多的junit用例。Jtest還能按照現有的超過350個編碼標準來檢查并自動糾正大多數常見的編碼規則上的偏差，用戶可自定義這些標準，通過簡單的幾個點擊，就能預防類似于未處理異常、函數錯誤、內存泄漏、性能問題、安全隱患這樣的代碼問題。
?
２、優勢：?
1）使預防代碼錯誤成為可能，從而大大節約成本，提高軟件質量和開發效率?
2）使單元測試——包括白盒、黑盒以及回歸測試成為可能?
3）使代碼規范檢查和自動糾正成為可能?
4）鼓勵開發團隊橫向協作來預防代碼錯誤?
?
３、特征：??
1）通過簡單的點擊，自動實現代碼基本錯誤的預防，這包括單元測試和代碼規范的檢查
2）生成并執行junit單元測試用例，對代碼進行即時檢查
3）提供了進行黑盒測試、模型測試和系統測試的快速途徑?
4）確認并阻止代碼中不可捕獲的異常、函數錯誤、內存泄漏、性能問題、安全弱點的問題?
5）監視測試的覆蓋范圍?
6）自動執行回歸測試?
7）支持DbC編碼規范?
8）檢驗超過350個來自java專家的開發規范?
9）自動糾正違反超過160個編碼規范的錯誤?
10）允許用戶通過圖形方式或自動創建方式來自定義編碼規范?
11）支持大型團隊開發中測試設置和測試文件的共享?
12）實現和IBM?Websphere?Studio?/Eclipse?IDE?的安全集成
?
４、價格：昂貴
?
?
u JMETER?
?
１、簡介：?
JMeter是Apache組織的開放源代碼項目，它是功能和性能測試的工具，100%的用java實現。使用JMeter進行性能測試?
２、特征：??
JMeter可以用于測試靜態或者動態資源的性能（文件、Servlets、Perl腳本、java對象、數據庫和查詢、ftp服務器或者其他的資源）。JMeter用于模擬在服務器、網絡或者其他對象上附加高負載以測試他們提供服務的受壓能力，或者分析他們提供的服務在不同負載條件下的總性能情況。你可以用JMeter提供的圖形化界面分析性能指標或者在高負載情況下測試服務器/腳本/對象的行為。
?
３、價格：未知?
?
?
u JUNIT?
?
１、簡介：?
?
JUnit是一個開源的java測試框架，它是Xuint測試體系架構的一種實現。在JUnit單元測試框架的設計時，設定了三個總體目標，第一個是簡化測試的編寫，這種簡化包括測試框架的學習和實際測試單元的編寫；第二個是使測試單元保持持久性；第三個則是可以利用既有的測試來編寫相關的測試。
?
２、優勢：?
?
2.1)junit是完全Free的。
?
2.2)使用方便。在你提升程序代碼的品質時JUnit測試仍允許你更快速的撰寫程序?2.3)JUnit非常簡單撰寫測試應該很簡單--這是重點！如果撰寫測試太復雜或太耗時間，便無法要求程序設計師撰寫測試。使用JUnit你可以快速的撰寫測試并檢測你的程序代碼并逐?步隨著程序代碼的成長增加測試。只要你寫了一些測試，你想要快速并頻繁的執行測試而不至于中斷建立設計及開發程序。使用JUnit執行測試就像編譯你的程序代碼那么容易。事實上，你應該執行編譯時也執行測試。編譯是檢測程序代碼的語法而測試是檢查程序代碼的完整性(integrity)。如果你是以人工比對測試的期望與實際結果那么測試是很不好玩的，而且讓你的速度慢下來。JUnit測試可以自動執行并且檢查他們自己的結果。當你執行測試，你獲得簡單且立即的回饋；?比如測試是通過或失敗。而不再需要人工檢查測試結果的報告。JUnit可以把測試組織成測試系列；這個測試系列可以包含其它的測試或測試系列。JUnit測試的合成行為允許你組合多個測試并自動的回歸(regression)從頭到尾測試整個測試系列。你也可以執行測試系列層級架構中任何一層的測試。使用Junit測試框架，你可以很便宜的撰寫測試并享受由測試框架所提供的信心。撰寫一個測試就像寫一個方法一樣簡單；測試是檢驗要測試的程序代碼并定義期望的結果。這個測試框架提供自動執行測試的背景；這個背景并成為其它測試集合的一部份。在測試少量的投資將持續讓你從時間及品質中獲得回收。你寫的測試愈少；你的程序代碼變的愈不穩定。測試使得軟件穩定并逐步累積信心；因為任何變動不會造成漣漪效應而漫及整個軟件。測試可以形成軟件的完整結構的膠結。?2.8)JUnit測試是開發者測試。JUnit測試是高度區域性(localized)測試；用以改善開發者的生產力及程序代碼品質。不像功能測試(function?test)視系統為一個黑箱以確認軟件整體的工作性為主，單元測試是由內而外測試系統基礎的建構區塊。開發者撰寫并擁有JUnit測試。每當一個開發反復(iteration)完成，這個測試便包裹成為交付軟件的一部份提供一種溝通的方式，「這是我交付的軟件并且是通過測試的。使用Java測試Java軟件形成一個介于測試及程序代碼間的無縫(seamless)邊界。在測試的控制下測試變成整個軟件的擴充同時程序代碼可以被重整。Java編譯器的單元測試靜態語法檢查可已幫助測試程序并且確認遵守軟件接口的約定。
一段測試的程序代碼無法單獨的執行，它需要是執行環境的一部份。同時，它需要自動執行的單元測試--譬如在系統中周期性的執行所有的測試以證明沒有任何東西被破壞。由于單元測試需要符合特定的準則：一個成功的測試不應該是人工檢查的（那可要到天荒地老了啊），一個未通過測試的失敗應可以產出文件以供診斷修改。而Junit可以提供給我們這些便利.。這樣所有測試開發者所需撰寫的只是測試碼本身了。跟optimizeit、Jtest那些昂貴而又超級麻煩的tool比較起來，其利昭然可見！
2.9)JUnit測試是以Java寫成的。
2.7)JUnit測試提升軟件的穩定性。
2.6)撰寫JUnit測試所費不多。
2.5)JUnit測試可以合成一個測試系列的層級架構。
2.4)JUnit測試檢驗其結果并提供立即的回饋。?那聽起來似乎不是很直覺，但那是事實。當你使用JUnit撰寫測試，你將花更少的時間除蟲，同時對你程序代碼的改變更?俱有信心。這個信心讓你更積極重整程序代碼并增加新的功能。沒有測試，對于重整及增加新功能你會變得沒有信心；因為你不知道有甚么東西會破壞產出的結果。采用一個綜合的測試系列，你可以在改變程序代碼之后快速的執行多個測試并對于你的變動并未破壞任何東西感到有信心。在執行測試時如果發現臭蟲，原始碼仍然清楚的在你腦中，因此很容易找到臭蟲。在JUnit中撰寫的測試幫助你以一種極?大(extreme)的步伐撰寫程序及快速的找出缺點。
?
３、價格：免費?
?
u WEBLODE?
?
１、簡介：?
?
webload是RadView公司推出的一個性能測試和分析工具,它讓web應用程序開發者自動執行壓力測試;webload通過模擬真實用戶的操作,生成壓力負載來測試web的性能。
?
?２、特征：?
?
１）用戶創建的是基于javas?cript的測試腳本,稱為議程agenda,用它來模擬客戶的行為,通過執行該腳本來衡量web應用程序在真實環境下的性能
?
２）如有需要可以在做負載測試的同時，使用服務器監控工具對服務器端的內容進行記錄那樣使負載測試更加全面。
?
?
第一階段英語單詞總結
一、Abbreviation???縮寫
0、?RTM???requirement?trace?matrix?需求跟蹤距陣
1、 SRS???software?requirement?specification??軟件需求規格說明書
2、 HLD???high?level?design?????????????????概要設計
3、 LLD???low?level?design??????????????????詳細設計
4、 IPO???input?process?output???????????????輸入輸出過程
5、 SQA???software?quality?assurance??????????軟件質量保證
6、 CMO??configuration?management?operator???配置管理員
7、 RUP???rational?unified?process??????????????通用業務流程
8、 IPD????integrated?product?development???????集成產品開發過程
9、 PDCA??plan，?do，?check，?act????????????質量管理PDCA循環
10、 SMART原則???specification具體的,?related相關性,?measurable可度量的,?time-based時限性,?achievable可達到性
11、 DMAC原則??define定義，?measure度量，?analysis分析，?check檢查
12、 SEPG????software?engineer?process?group????軟件工程過程組
13、 SEI??????software?engineer?institute?????????美國軟件工程研究所
14、 CCB???change?control?board????????????????變更控制委員會
15、 MTBF????mean?time?between?failure?????????平均失效時間
16、 MTTR????mean?time?to?repair??????????????平均故障恢復時間
17、 SDP????software?development?plan??????????軟件開發計劃
?
?
二、常用術語
1、 Debug?????????????調試
2、 Test?case???????????測試用例
3、 Siral?model?????????螺旋模型
4、 Software?life?cycle???軟件生命周期
5、 Initial?????????????初始級
6、 Repeatable?????????可重復級
7、 Defined????????????已定義級
8、 Managed??????????已管理級
9、 Optimizing????????優化級
10、 Suitability?????????適合性
11、 Accuracy??????????準確性
12、 Interoperability?????互操作性
13、 Security????????????安全性
14、 Functionality?compliance???功能性依從性
15、 Maturity???????????成熟性
16、 Fault?tolerance??????容錯性
17、 Recoverability?????????易恢復性
18、 Reliability?compliance??可靠性的依從性
19、 Understandability??????易理解性
20、 Learn?ability???????????易學性
21、 Operability????????????易操作性
22、 Attractiveness??????????吸引性
23、 Time?behavior??????????時間特性
24、 Resource?utilization??????資源利用性
25、 Efficiency?compliance?????效率依從性
26、 Analyzability????????????易分析性
27、 Changeability????????????易改變性
28、 Stability????????????????穩定性
29、 Testability???????????????易測試性
30、 Maintainability?compliance?維護行依從性
31、 Adaptability??????????????適應性
32、 installability??????????????安裝性
33、 co-existence???????????????共存行
34、 replaceability?????????????易替換性
35、 portability?compliance?????可移植性的依從性
36、 unit?testing???????????????單元測試
37、 integration?testing?????????集成測試
38、 system?testing?????????????系統測試
39、 regression?testing??????????回歸測試
40、 verification???????????????驗證
41、 validation????????????????確認
42、 alpha?testing??????????????α測試
43、 beta?testing???????????????β測試
44、 top-down?testing???????????自頂向下測試
45、 bottom-up?testing??????????自底向上測試
46、 isolation?testing????????????孤立測試
47、 automates?testing???????????自動測試
48、 artificially?testing???????????人工測試
49、 white?box?testing????????????白盒測試
50、 black?box?testing????????????黑盒測試
51、 entry?criteria???????????????入口準則
52、 exit?criteria?????????????????出口準則
53、 reviews?and?audits???????????評審和審計
54、 work?products?managed?and?controlled??可管理和受控的工作產品
55、 documented?procedures???????書面規程
56、 stub????????????????????????樁單元
57、 performance?testing???????????性能測試
58、 stress?testing?????????????????壓力測試
59、 volume?testing??????????????????????容量測試
60、 security?testing??????????????????????安全性測試
61、 usability?testing?????????????????????可用性測試
62、 backup?testing??????????????????????備份測試
63、 robustness?testing???????????????????健壯性測試
64、 documentation?testing???????????????文檔測試
65、 online?help?testing???????????????????在線幫助測試
66、 statement?coverage??????????????????語句覆蓋
67、 branch?coverage????????????????????分支覆蓋
68、 decision?coverage???????????????????判斷覆蓋
69、 condition?coverage??????????????????條件覆蓋
70、 branch?conditon?coverage????????????分支條件覆蓋
71、 decision?condition?coverage???????????判斷條件覆蓋
72、 path?coverage???????????????????????路徑覆蓋
73、 function?coverage???????????????????功能覆蓋
74、 inheritance?context?coverage??????????繼承上下文覆蓋
75、 state-based?context?coverage??????????基于狀態的上下文覆蓋
76、 User-defined?context?coverage?????????已定義用戶上下文覆蓋
77、 Instruction?blocks?coverage??IB?coverage???指令塊覆蓋
78、 Decision-to-decision?paths?coverage??DDP?coverage??判定路徑覆蓋
79、 Peer?review???????????????????????同行評審
80、 Walkthrough??????????????????????走讀
81、 Defect????????????????????????????缺陷
82、 Error?????????????????????????????錯誤
83、 Syntax?error???????????????????????語法錯誤
84、 Logical?error???????????????????????邏輯錯誤
85、 Fault?????????????????????????????故障
86、 Failure????????????????????????????失效
補充中……
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
復習問題總結
一、測試基礎：
1、?測試目的是什么
證明：證明軟件的可用性
檢測：發現軟件中存在的錯誤
預防：管理軟件的質量，可維護性能
2、?軟件生命周期中的各個模型及其優缺點
瀑布模型：應用的最為廣泛的一種模型，也是最容易理解和掌握的模型，然而它的缺陷也是顯而易見的。
??優點：
–?強調開發的階段性
–?強調早期計劃及需求調查
–?強調產品測試
??缺點：
–?依賴于早期進行的需求調查，不能適應需求變化
–?由于是單一流程，開發中的經驗教訓不能應用于本產品過程
–?測試在后期才參與，前期質量無法保證
螺旋模型：綜合了基本的瀑布式模型和演化/漸增原型方法。
??優點：
–?強調全過程風險管理
–?強調各開發階段的質量
–?提供機會檢討項目是否有價值繼續下去
??缺點：
–?每個階段都要提出多個備選方案，并進行充分的風險分析，研發周期長，效
??????????率低。
–?需要有專門的風險分析人員參與
RUP流程：所有工作流在各個階段都有體現。
??優點：
–?任何功能一經開發就能進入測試以便驗證是否符合產品需求
–?在早期對風險進行識別，采取預防措施
–?盡早得到用戶的驗證
??缺點：
–?如果需求一開始并不完全弄清楚，會給總體設計帶來困難及削弱產品設計的
???????????完整性。
–?如果缺乏嚴格的過程管理，就可能退化為原始的無計劃的“試—錯—改”模
??????????????試。
–?不加控制地讓用戶接觸開發并尚未測試穩定的功能，可能對開發和用戶都會
???????????產生負面的影響
IPD流程：從整個產品角度出發，不僅僅針對研發。
–?流程是由IBM提出來的一套集成產品開發流程，非常適合于復雜的大型開發項目。從整個產品角度出發，流程綜合考慮了從系統工程、研發（硬件、軟件、結構工業設計、測試、資料開發等，制造、財務到市場、采購、技術支援等所有流程。是一個階段性模型，具有瀑布模型的影子。
–? 通過復雜的流程把一個龐大而又復雜的系統進行分解并降低風險。通過流程成本來提高整個產品的質量并獲得市場的占有。此模式不適合經常變動的需求，若用此模式開發小型項目，成本消耗非常大。
?
3、?軟件研發中幾個重要的過程是什么，每個過程中的主要內容是什么？
需求管理：對軟件開發中的需求進行管理，包括需求分配、需求評審、建立需求基線、需求跟蹤、變更控制。
配置管理：配置管理是通過對在軟件生命周期的不同的時間點上的軟件配置進行標識，并對這些被標識的軟件配置項的更改進行系統控制，從而達到保證軟件產品的完整性和可溯性的過程。?
缺陷跟蹤：對軟件開發過程缺陷的發現、確認、定位、修改、評審、關閉等過程進行跟蹤管理的流程。
同行評審：對于軟件工作產品（包括文檔、代碼、用戶手冊等），組織工作產品作者的同行來確認是否存在缺陷、是否需要變更的檢查方法。
4、?引入缺陷的原因都有哪些？
缺陷引入的原因?：?
⑴開發過程缺乏有效的溝通，或者沒有進行溝通
⑵?軟件復雜度越來越高
⑶?編程中產生錯誤
⑷?需求不斷變更
⑸?項目進度的壓力
⑹?不重視開發文檔
⑺?軟件開發工具本身隱藏的問題
?
二、軟件質量：
1、軟件質量分哪幾個層次，分別是什么？
1.?符合需求的規格：符合開發者明確定義的目標，即產品是不是符合需求規格。
2.?符合用戶顯示需求：符合用戶所明確說明的目標。
3.?符合用戶實際需求：符合用戶明確說明的和隱含的目標。
2、影響軟件質量的因素有哪些？為什么？
影響軟件質量因素主要有：
流程：針對不同的需求選用不同的軟件流程模型圖。
技術：包括開發技術、測試技術以及美工工藝的技術。
組織：一組特性及特性之間的關系，它提供規定質量需求和評價質量的基礎。
?
ü?流程：從計劃到策略的實現，流程就是按照這種思維方式指導軟件開發的，并且流程來源于成功的經驗，可以指導項目少走彎路，從而提高軟件質量，不僅如此，流程還對項目的成本和進度控制有很大的幫助
ü?技術：包括了分析技術、設計技術、編碼技術、測試技術，需求是項目的靈魂，良好的需求分析便是項目成功的關鍵所在，若是需求分析做不好不可避免的要出現返工；設計，軟件的質量是設計出來的，良好的設計基本上決定了軟件產品的最終質量；編碼技術產生正確高效的代碼；測試是保證軟件的一道防線。所以各種技術對質量來說都是很重要的
ü?組織：好的組織可以有效的促進流程的實施，同時提供員工的發展通道以吸引更多的人（技術的載體）
總結：質量鐵三角互相促進，缺一不可
3、CMM是什么？CMM各級的特點
CMM(capabillty?Maturity?Moelel)
由于美國軟件工程研究所（SEI）受美國國防部委托立項。
開發人：Watts?Humphrey.
1991年推出CMM1.0版，1993年提出CMM1.1版
現在開發CMMI（CMM?Integration）
軟件能力成熟度模型CMM（提唱過程決定質量）
?
?
?
?
????????????????????????????????????????
????????????????????????????????????????持續改進過程
?
?
?
?????????????????????????可預測的過程????????????????????????????????管理變更
?
?
?
?????????標準.一致的過程?????????????????????????????????????產品過程質量
?
?
?
??紀律的過程????????????????????????????????集成工程過程
?
?
?
???????????????????????????????項目管理
CMM1級
特點：（個人英雄主義）
A項目的成功依賴于一個非常優秀的項目經理的團隊。
B無法重復以往成功的實踐。
C缺乏基本配置管理
可視度：
整個過程不可預測，不可見，不可控。（過程管理非常混亂）
?
CMM2級
特點：（有紀律）
能夠重復以前成功的經驗和實踐。
引入合理需求變更（需求管理）
測試與開發分離，整個過程能力可概為有紀律的。
可視度
原始需求——需求分析——設計——編碼——測試——產品
?
CMM3級
特點：（有過程，經過同行評審）
組織中有一個專門負責組織的標準軟件過程。（SEPG）
可視度
同CMM2但整個過程是標準和一致的。
?
CMM4級特點
特點：（量化管理）
過程能力是可預防的，因為過程是已測量的并在可測的范圍內運行。組織能定量地預測過程和產品質量方面趨勢。軟件產品具有可預測的高質量。
可視度
同CMM3但整個過程是可預測的。
?
CMM5級特點
特點：（改進過程本身）
通過缺陷來發現過程的不足。
新的開發技術觸使改進過程。
可視度
同CMM￥級整個是以改進的。
?
CMM的用途：
1?評估供用商的能力；
2企業的過程改進指南；
3評估組用來識別組織中的強處和弱點；
4管理者用來了解其組織的能力，并了解為了提高其能力成熟度而進行軟件過程改進所需要進行的活動；
5?評價組用來識別選擇不同的業務承包商的風險和監督合同。
?
4、軟件質量模型是什么？
軟件質量模型可分為6大模塊27子模塊
ü?功能性
1.?適合性
2.?準確性
3.?互操作性
4.?保密安全性
5.?功能性的依從性
ü?可靠性
6.?成熟性
7.?容錯性
8.?易恢復性
9.?可靠性的依從性
ü?易用性
1.?易理解性
2.?易學性
3.?易操作性
4.?吸引性
5.?易用性的依從性
ü?效率
1.?時間性
2.?資源利用性
3.?效率依從性
ü?維護性
10.?易分析性
11.?易改變性
12.?穩定性
13.?易測試性
14.?維護性的依從性
ü?可移植性
15.?適應性
16.?易安裝性
17.?共存性
18.?易替換性
19.?可移植性的依從性
5、SQA和測試的關系是什么？
SQA從過程上保證軟件質量?測試從技術上保證軟件質量。
6、SQA的主要工作范圍是什么？
1.?保障制度體系順利執行。
2.?促進過程改進。
3.?指導項目實施。
4.?增強項目的可視度（進度、質量、過程）。
5.?評審工作產品。
6.?審核工作產品。（核心工作）。
7.?協助問題解決。
8.?提供決策支持。
9.?缺陷預防（提高產品質量，降低缺陷發現修復成本）。
10.?實現質量目標
7、質量管理的PDCA循環是什么？
1.?Plan 計劃 （計劃設計）
2.?Do? 執行 （實施執行）
3.?Check? 檢查 （檢查檢測）
4.?Act? 改進 （糾正措施）
8、軟件度量的手段是什么？
1.?規模（size）
2.?工作量(effort)
3.?進度(schedule)
4.?質量-缺陷(quality-defect)
?
三、測試方法：
1、黑盒測試和白盒測試的區別？
黑盒：被測對象當作一個黑盒子，參考與SRS，站在用戶立場上進行測試，方便與功能測試、驗收測試、易用性測試等。
白盒：玻璃盒，基與代碼測試，參考與LLD，HLD在了解程序的內部數據結構和邏輯結構的基礎上展開的更適合于單元測試、集成測試等。
2、常用的黑盒測試技術有哪些？
ü?輸入輸出:等甲類?邊界之?輸入域覆蓋?輸出域覆蓋
ü?條件組合:因果圖?正交試驗?判定法
ü?過程處理:?流程分析?狀態遷移
ü?其他:?錯誤猜測?異常分析
3、常用的白盒測試技術有哪些？
ü?靜態分析：信息流分析、數據流分析、控制流分析。
ü?動態分析：邏輯覆蓋、程序插裝。
4、靜態測試和動態測試的區別
靜態和動態測試的區別是：是否運行被測軟件。
5、靜態測試的方法有哪些？?上題
6、動態測試的方法有哪些？?上題
7、手工測試和自動化測試的區別？
手工測試：測試活動以及執行由人工來完成。
自動化測試：通過工具模擬人的測試執行，由計算機自動執行。
8、手工測試和自動化測試的優缺點是什么？
手工測試：
自動化測試：
四：測試過程：
1、?系統測試、集成測試和單元測試的區別？
用三種不同角度比較如下表：
| 階段 | 考察范圍 | 測試方法 | 評估基準 |
| 系統測試 | 整個系統相對與需求的符合度 | 黑盒 | 測試用例對需求規格的覆蓋率 |
| 集成測試 | 模塊間的接口和接口的數據傳遞關系，以及模塊組合后的整體功能 | 灰盒 | 接口覆蓋率 |
| 單元測試 | 測試單元內部數據結構、邏輯控制、異常處理等 | 白盒 | 邏輯覆蓋率 |
?
2、?為什么測試要分階段進行
雖然在表面看來分階段測試在成本和進度比不分階段測試大，但實際測試分階段進行原因是各個階段都有它不同的關注點，這樣可以盡早發現缺陷，不會導致因為局部缺陷導致全局癱瘓。如果不分階段，那么缺陷的放大效應導致修復成本將變的異常龐大，修復進度將不可預測。除此之外分階段測試因為分工明確也會很大程度上提高產品的質量。
3、?回歸測試的策略如何選擇？
回歸測試的策略主要有：完全重復測試?和選擇性重復測試。
完全重復測試：重新執行所有在前期測試階段建立的測試用例
選擇重復測試：?即有選擇地重新執行部分在前期測試階段建立的測試用例，主要測被修改的程序。
選擇重復測試可分為：覆蓋修改法、周遍影響法、指標達成法。
根據產品進度、缺陷的嚴重性以及缺陷發現的階段性進行選擇。
4、?回歸測試的自動化什么情況下使用？
a)?重復率高。
b)?相對穩定的版本。
c)?手工無法達到的場景模擬。
5、?V&V模型的特點是什么？與瀑布模型和H模型相比有什么優勢
a)?實現了測試設計與執行的分離。
b)?測試與開發同步進行，各階段相對應。
c)?揭示了測試過程分階段分層的本質
瀑布模型沒有實現測試的分階段和分層，而H模型雖然是開發測試同步進行卻沒有標明測試與開發各個階段的對應關系
6、?主要的測試文檔有哪些，分別都是什么內容，作用和讀者都是什么？
| ? | 作者 | 內容 | 讀者 | 作用 |
| 測試計劃 | 測試經理 測試計劃人員 | 測試策略 測試方法 測試項 時間、進度安排 | 項目經理 | 了解測試安排，掌控項目進度 |
| 開發人員 | 評審 | |||
| 測試人員 | 評審、設計測試方案及用例的依據、執行時參考 | |||
| SQA | 度量 | |||
| 測試方案 | 測試經理 測試工程師 測試設計人員 | 測試子項 具體測試方法 | 測試經理 | 評審 |
| 開發人員 | 評審 | |||
| 測試人員 | 評審、設計用例的依據、執行時參考 | |||
| SQA | 度量 | |||
| 測試用例 | 測試工程師 測試實現人員 | 編號、標題、輸入、處理過程、預期輸出等 | 測試經理 | 評審 |
| 開發人員 | 評審 | |||
| 測試人員 | 測試執行的依據 | |||
| SQA | 度量 | |||
| 測試規程 | 測試工程師 測試實現人員 | 測試用例的執行先后順序 | 測試執行人員 | 提高測試執行的效率 |
| 測試報告 | 測試工程師 測試執行人員 | 測試執行情況記錄 | 測試經理 | 了解測試結果 |
| 項目經理 | 掌握軟件的質量水平 | |||
| 缺陷報告 | 測試工程師 測試執行人員 | ? | 開發人員 | 確認缺陷、修改的依據 |
| 測試經理 | 判斷是否重復 | |||
| 項目經理 | 分配缺陷 |
?
7、?系統測試過程各階段的輸入、輸出是什么？
系統測試計劃階段輸入：軟件需求規格說明書、軟件測試計劃、軟件開發計劃
????????????????輸出：系統測試計劃
系統測試設計階段輸入：軟件需求規格說明書、系統測試計劃
????????????????輸出：系統測試方案
系統測試實現階段輸入：軟件需求規格說明書、系統測試計劃、系統測試方案
????????????????輸出：系統測試用例、系統測試規程
系統測試執行階段輸入：系統測試計劃、系統測試方案、系統測試用例、系統測試規程
????????????????輸出：系統測試報告、缺陷報告單
?
8、?集成測試過程各階段的輸入、輸出是什么？
集成測試計劃階段輸入：概要設計說明書、軟件測試計劃
????????????????輸出：集成測試計劃
集成測試設計階段輸入：概要設計說明書、集成測試計劃
????????????????輸出：集成測試方案
集成測試實現階段輸入：概要設計說明書、集成測試計劃、集成測試方案
????????????????輸出：集成測試用例、集成測試規程
集成測試執行階段輸入：集成測試計劃、集成測試方案、集成測試用例、集成測試規程
????????????????輸出：集成測試報告、缺陷報告單
?
9、?單元測試過程各階段的輸入、輸出是什么？
單元測試計劃階段輸入：詳細設計說明書、軟件測試計劃
????????????????輸出：單元測試計劃
單元測試設計階段輸入：詳細設計說明書、單元測試計劃
????????????????輸出：單元測試方案
單元測試實現階段輸入：詳細設計說明書、單元測試計劃、單元測試方案
????????????????輸出：單元測試用例、單元測試規程
單元測試執行階段輸入：單元測試計劃、單元測試方案、單元測試用例、單元測試規程
????????????????輸出：單元測試報告、缺陷報告單
?
10、需求分析階段主要的任務是什么？
把用戶的需求，包括顯式需求和隱式需求轉換為規格化的描述確切的說明文檔，形成SRS
11、概要設計階段主要的任務是什么？
把SRS中的需求轉化為模塊化的體系結構，每個模塊具有明確的功能
12、詳細設計階段主要的任務是什么？
對每個模塊要完成的功能的實現給出具體的描述
13、編碼階段主要的任務是什么？
將設計轉換成程序代碼
14、單元測試執行階段階段主要的任務是什么？
檢驗被測單元與LLD的符合程度
15、集成測試執行階段主要的任務是什么？
檢驗被測單元與HLD的符合程度
16、系統測試執行階段主要的任務是什么？
檢驗被測單元與SRS的符合程度
五、系統測試：
1、系統測試的目的是什么？
2、系統測試的類型有哪些？
1)?功能測試
2)?性能測試
3)?壓力測試
4)?容量測試
5)?安全性測試
6)?可用性測試
7)?GUI測試
8)?安裝測試
9)?配置測試
10)?異常測試
11)?備份測試
12)?健壯性測試
13)?穩定性測試
14)?文檔測試
15)?在線幫助測試
16)?網絡測試
?
3、系統測試的用例設計思路是什么？
4、如何保證系統測試用例的完備性？
a)?附蓋SRS中功能來設計用例
b)?從質量模型的不同特性來設計用例
c)?每個測試項目從不同的角度來設計測試數據
六、通用測試用例
1、測試用例模板的要素分別是什么？
a)?用例編號
b)?測試項目
c)?測試標題
d)?重要級別
e)?預置條件
f)?輸入參數
g)?操作步驟
h)?預期輸出
?
七、同行評審
1、什么叫同行評審？
通過作者的同行來確認產品的缺陷以及變更區域的檢查方法
2、同行評審的目的？
發現和排除產品中的缺陷和不足
3、同行評審的流程？
八、配置管理
1、什么叫配置管理？
對軟件生命周期的各個階段的成果物進行版本控制
2、配置管理的相關術語是什么？
a)?配置
b)?配置項
c)?基線
d)?版本
3、配置管理的目標？
a)?保證各個階段成果物的完整性
b)?保證成果物的可溯性
c)?保證成果物的一致性
d)?使成果物處于受控狀態
4、配置管理的流程？
九、需求管理
1、什么叫需求管理？
在項目的研發過程中對需求的跟蹤和控制等方面的流程
2、進行需求管理的作用是什么？
3、如何控制需求的變更？
4、如何進行需求跟蹤？
八、缺陷管理
1、什么叫缺陷管理？
2、缺陷管理的作用？
3、缺陷管理的流程？
4、如何可以保證缺陷報告的編寫質量？
?
總結
以上是生活随笔為你收集整理的软件测试基础知识大全(新手入门必备)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： InstallShield教程-打包.N
- 下一篇： 易语言获取硬盘特征字序列号加密特征字