 |
善于提問，勤于回答，你也是專家
|
 |
問題已開啟
(普通問題)
提問者:
• 請問qxdm怎樣測試evdo，如何設(shè)置如何撥號��？ 2009-08-29
• 關(guān)于DT測試數(shù)據(jù)KPI統(tǒng)計，百思不解的問題 2009-08-29
• 請問在做C網(wǎng)、G網(wǎng)路測需要測試那些參數(shù)以及各參數(shù)反映的是什么？謝謝 2009-08-28
• 城區(qū)鎖頻測試難嗎？ 2009-08-27
• W測試遇到的問題 2009-08-27
• 索尼愛立信k790c測試軟件 2009-08-26
• TEMS測試軟件如何統(tǒng)計雙頻網(wǎng)切換 2009-08-26
• 什么是測試中的遠點，中點和近點 2009-08-26
• 關(guān)于DT測試數(shù)據(jù)KPI統(tǒng)計，百思不解的問題 2009-08-29
• 請問在做C網(wǎng)、G網(wǎng)路測需要測試那些參數(shù)以及各參數(shù)反映的是什么？謝謝 2009-08-28
• 城區(qū)鎖頻測試難嗎？ 2009-08-27
• W測試遇到的問題 2009-08-27
• 索尼愛立信k790c測試軟件 2009-08-26
• TEMS測試軟件如何統(tǒng)計雙頻網(wǎng)切換 2009-08-26
• 什么是測試中的遠點，中點和近點 2009-08-26
問題答案
( 5 )
小姐，測試軟件太多了，你是指哪一款呀。
回答者：
cljnn
回答時間：2010-07-06 20:12
10
15
軟件測試：http://www.verycd.com/topics/2823906 《軟件測試資料》(software testing)
軟件性能測試過程詳解與案例剖析.pdf 詳情 28.1MB
qc安裝指南.pdf 詳情 1.1MB
VBScript腳本語言.pdf 詳情 656.2KB
正交設(shè)計助手.zip 詳情 758.6KB
常用正交表.pdf 詳情 135.7KB
[軟件測試資料].WinRunner.7.6.Tutorial_oldsidney_cn.pdf 詳情 1.3MB
自動化測試.pdf 詳情 8.4MB
QTP中的descriptive.programming.pdf 詳情 233.1KB
軟件工程文檔模板.rar 詳情 104.7KB
軟件評測師教程.pdf 詳情 73.2MB
測試藏寶圖.pdf 詳情 2.4MB
軟件測試(原書中文第二版).pdf 詳情 6.4MB
Linux操作系統(tǒng)CPU相關(guān)指標監(jiān)控技術(shù).pdf 詳情 207.1KB
[軟件測試資料].LR9.1Tutorial.pdf 詳情 1.8MB
QTP9.0編程常用方法及實例心得.pdf 詳情 452.9KB
LoadRunner函數(shù)大全之中文解釋.pdf 詳情 480.7KB
LR用戶指南.pdf 詳情 4.2MB
LR安裝指南.pdf 詳情 2.3MB
QTP中常用的VB函數(shù).doc 詳情 126KB
QTP學習與實踐經(jīng)驗總結(jié)1.doc 詳情 6.1MB
QTP技術(shù)集錦.doc 詳情 3.9MB
軟件測試專用術(shù)語.doc 詳情
軟件性能測試過程詳解與案例剖析.pdf 詳情 28.1MB
qc安裝指南.pdf 詳情 1.1MB
VBScript腳本語言.pdf 詳情 656.2KB
正交設(shè)計助手.zip 詳情 758.6KB
常用正交表.pdf 詳情 135.7KB
[軟件測試資料].WinRunner.7.6.Tutorial_oldsidney_cn.pdf 詳情 1.3MB
自動化測試.pdf 詳情 8.4MB
QTP中的descriptive.programming.pdf 詳情 233.1KB
軟件工程文檔模板.rar 詳情 104.7KB
軟件評測師教程.pdf 詳情 73.2MB
測試藏寶圖.pdf 詳情 2.4MB
軟件測試(原書中文第二版).pdf 詳情 6.4MB
Linux操作系統(tǒng)CPU相關(guān)指標監(jiān)控技術(shù).pdf 詳情 207.1KB
[軟件測試資料].LR9.1Tutorial.pdf 詳情 1.8MB
QTP9.0編程常用方法及實例心得.pdf 詳情 452.9KB
LoadRunner函數(shù)大全之中文解釋.pdf 詳情 480.7KB
LR用戶指南.pdf 詳情 4.2MB
LR安裝指南.pdf 詳情 2.3MB
QTP中常用的VB函數(shù).doc 詳情 126KB
QTP學習與實踐經(jīng)驗總結(jié)1.doc 詳情 6.1MB
QTP技術(shù)集錦.doc 詳情 3.9MB
軟件測試專用術(shù)語.doc 詳情
回答者：
tscinter
回答時間：2010-07-06 20:30
12
13
使用人工或者自動手段來運行或測試某個系統(tǒng)的過程,其目的在于檢驗它是否滿足規(guī)定的需求或弄清預期結(jié)果與實際結(jié)果之間的差別.
它是幫助識別開發(fā)完成（中間或最終的版本）的計算機軟件（整體或部分）的正確度(correctness) 、完全度(completeness)和質(zhì)量(quality)的軟件過程；是SQA(software quality assurance)的重要子域。
Grenford J.Myers曾對軟件測試的目的提出過以下觀點:
(1)測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程；
(2)好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案；
(3)成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。
然而,這種觀點指出測試是以查找錯誤為中心,而不是為了演示軟件的正確功能.但是只從字面意思理解,可能會產(chǎn)生誤導,認為發(fā)現(xiàn)錯誤是軟件測試的唯一目的,查找不出錯誤的測試就是沒有價值的測試,實際上并非如此!
(1)測試并不僅僅是為了找出錯誤.通過分析錯誤產(chǎn)生的原因和錯誤的發(fā)生趨勢,可以幫助項目管理者
發(fā)現(xiàn)當前軟件開發(fā)過程中的缺陷,以便及時改進；
(2)這種分析也能幫助測試人員設(shè)計出有針對性的測試方法,改善測試的效率和有效性；
(3)沒有發(fā)現(xiàn)錯誤的測試也是有價值的,完整的測試是評定軟件質(zhì)量的一種方法
軟件測試完整分類，參見：軟件測試的完整分類
1.軟件開發(fā)人員即程序員應當避免測試自己的程序
測
不管是程序員還是開發(fā)小組都應當避免測試自己的程序或者本組開發(fā)的功能模塊。若條件允許，應當由獨立于開發(fā)組和客戶的第三方測試組或測試機構(gòu)來進行軟件測試。但這并不是說程序員不能測試自己的程序，而且更加鼓勵程序員進行調(diào)試，因為測試由別人來進行可能會會更加有效、客觀，并且容易成功，而允許程序員自己調(diào)試也會更加有效和針對性。
2. 應盡早地和不斷地進行軟件測試
應當把軟件測試貫穿到整個軟件開發(fā)的過程中，而不應該把軟件測試看作是其過程中的一個獨立階段。因為在軟件開發(fā)的每一環(huán)節(jié)都有可能產(chǎn)生意想不到的問題，其影響因素有很多，比如軟件本身的抽象性和復雜性、軟件所涉及問題的復雜性、軟件開發(fā)各個階段工作的多樣性，以及各層次工作人員的配合關(guān)系等。所以要堅持軟件開發(fā)各階段的技術(shù)評審，把錯誤克服在早期，從而減少成本，提高軟件質(zhì)量。
3.對測試用例要有正確的態(tài)度：第一，測試用例應當由測試輸入數(shù)據(jù)和預期輸出結(jié)果這兩部分組成；第二，在設(shè)計測試用例時，不僅要考慮合理的輸入條件，更要注意不合理的輸入條件。因為軟件投入實際運行中，往往不遵守正常的使用方法，卻進行了一些甚至大量的意外輸入導致軟件一時半時不能做出適當?shù)姆磻�，就很容易產(chǎn)生一系列的問題，輕則輸出錯誤的結(jié)果，重則癱瘓失效！因此常用一些不合理的輸入條件來發(fā)現(xiàn)更多的鮮為人知的軟件缺陷。
4.人以群分，物以類聚，軟件測試也不例外，一定要充分注意軟件測試中的群集現(xiàn)象，也可以認為是“80-20原則”。不要以為發(fā)現(xiàn)幾個錯誤并且解決這些問題之后，就不需要測試了。反而這里是錯誤群集的地方，對這段程序要重點測試，以提高測試投資的效益。
5.嚴格執(zhí)行測試計劃，排除測試的隨意性，以避免發(fā)生疏漏或者重復無效的工作。
6.應當對每一個測試結(jié)果進行全面檢查。一定要全面地、仔細地檢查測試結(jié)果，但常常被人們忽略，導致許多錯誤被遺漏。
7.妥善保存測試用例、測試計劃、測試報告和最終分析報告，以備回歸測試及維護之用。
在遵守以上原則的基礎(chǔ)上進行軟件測試，可以以最少的時間和人力找出軟件中的各種缺陷，從而達到保證軟件質(zhì)量的目的。
1.程序測試的過程具有破壞性
每當測試一個程序時，人們總希望為程序增加一些價值。利用測試來增加程序的價值，是指通過測試，找出并修改盡可能多的程序缺陷，從而提高程序的可靠性或質(zhì)量。
因此，不要只是為了證明程序能夠正確運行而去測試程序。相反，應該一開始就假設(shè)程序中隱藏著錯誤（這種假設(shè)幾乎對所有的程序都成立），然后測試程序，發(fā)現(xiàn)盡可能多的錯誤。
事實上，如果把測試目標定位于要證明程序中沒有缺陷，那么就會在潛意識中傾向于實現(xiàn)這個目標。也就是說，測試人員會傾向于挑選那些使程序失效的可能性較小的測試數(shù)據(jù)。另一方面，如果把測試目標定位于要證明程序中存在缺陷，那么就會選擇一些容易發(fā)現(xiàn)程序缺陷的測試數(shù)據(jù)。而后一種態(tài)度會比前者給程序增加更多的價值。
因此，大多數(shù)測試專業(yè)人員都贊同Myers對測試的定義：“測試是為發(fā)現(xiàn)錯誤而執(zhí)行程序的錯誤。”這個定義意味著程序測試的過程是具有破壞性的，甚至是一個“施虐”過程。開發(fā)人員可能不愿意這么做，因為人們總是傾向于建設(shè)而不是破壞。這個定義還暗示了對于一個特定的程序，應該如何設(shè)計測試用例（測試數(shù)據(jù)）、哪些人應該而哪些人又不應該執(zhí)行測試。
事實上，如果在測試某個程序段時發(fā)現(xiàn)了可以糾正的缺陷，或者測試最終確定在沒有其他缺陷，則應將這次合理設(shè)計并得到有效執(zhí)行的測試稱作是“成功的”。而所謂“不成功的”測試，僅指未能適當?shù)貙Τ绦蜻M行檢查，未能找出程序中潛藏缺陷的測試。因為軟件中不可能沒有缺陷，沒有找出它們，當然測試是“不成功的”。
“軟件測試就是證明軟件不存在錯誤的過程”。對幾乎所有的程序而言，甚至是非常小的程序，這個目標實際上是無法達到的。因為即使程序完全實現(xiàn)預期要求，仍可能包含有缺陷。也就是說，如果程序不按要求工作，它顯然有缺陷，但如果程序做了不要它做的事，它也有缺陷。
心理學研究告訴我們，當人們在干一件已經(jīng)知道是不合適的或不可能做到的事時，往往他們的表現(xiàn)就相當糟糕。把程序測試定義為在程序中找出錯誤的過程，就使測試成了可以做到的任務，從而克服了心理上存在的問題。雖然這看起來像是個微妙的文字游戲，但對成功地進行軟件測試有很大的影響。
總之，軟件測試更適宜被視為試圖發(fā)現(xiàn)程序中錯誤（假設(shè)其存在）的破壞性的過程。一個成功的測試，通過誘發(fā)程序發(fā)生錯誤，可以在這個方向上促進軟件質(zhì)量的改進。當然最終人們還是要通過軟件測試來建立某種程度的信心：軟件做了其應該做的，而沒有做其不應該做的。
2.程序員應避免測試自己的程序
由開發(fā)人員來測試自己的代碼是一件很不妥當?shù)氖虑椤ｉ_發(fā)和測試生來就是不同的活動。開發(fā)是創(chuàng)造或者建立某種事物的行為，如一個功能模塊或整個系統(tǒng)。而測試的重要目的是證實一個模塊或者一個系統(tǒng)工作不正常。這兩個活動之間有著本質(zhì)的矛盾。一個人不太可能把兩個截然對立的角色都扮演地很好，因此應當限制開發(fā)人員在測試中的參與，給他們比較合適的任務是進行最底層的測試——單元測試。
當一個程序員完成了設(shè)計與編寫程序的建設(shè)性工作后，要一夜之間突然改變他的觀點，設(shè)法對程序形成一個完全否定的態(tài)度，那是非常困難的。所以，大部分程序員都由于不能使自己進入必要的精神狀態(tài)（不是抱著要揭露出自己程序中錯誤的態(tài)度），就不能有效的測試自己的程序。除了這個心理學問題之外，還有一個重要的問題：程序中可能包含由于程序員對問題的敘述或說明的誤解而產(chǎn)生了錯誤。如果是這種情況，當程序員測試自己的程序時，往往還會帶著同樣的誤解致使問題難以發(fā)現(xiàn)。
3.程序設(shè)計組織不應測試自己的程序
在宏觀意義上，一個程序設(shè)計組織或一個工程項目是個有生命的有機體，它同樣有心理學問題。在大多數(shù)情況下，人們都以“在給定日期內(nèi)，以一定代價完成程序編制任務的能力”來衡量程序設(shè)計組織和項目管理人員的。這樣做的理由是時間和成本指標便于衡量，而程序的質(zhì)量很難度量。要程序設(shè)計組織在測試自己的程序時持客觀態(tài)度是很困難的，因為如果用正確的定義看待測試，就不大可能按預定計劃完成測試，也不大可能把耗費的代價限制在要求的范圍以內(nèi)。
軟件生產(chǎn)的三個最重要的因素是：質(zhì)量、進度和費用。由于費用和進度的限制，要開發(fā)一種高質(zhì)量、快速交付和低成本的軟件產(chǎn)品并不容易。也就是說要同時達到三個目標是困難的。因此在軟件產(chǎn)品的開發(fā)中要權(quán)衡它們之間的關(guān)系，是軟件的特性能滿足用戶的要求，這意味著軟件產(chǎn)品的特性的度量和預計是必要的。
軟件測試由獨立測試機構(gòu)承擔有很多好處。獨立測試是指軟件測試工作由在經(jīng)濟上和管理上獨立于開發(fā)機構(gòu)的組織進行。獨立測試可以避免軟件開發(fā)者測試自己開發(fā)的軟件，由于心理學上的問題，軟件開發(fā)者難以客觀、有效的測試自己的軟件，要找出那些因為對問題的誤解而產(chǎn)生的錯誤就更加困難。獨立測試還可以避免軟件開發(fā)機構(gòu)測試自己的軟件，軟件產(chǎn)品的開發(fā)過程受到時間、成本和質(zhì)量三者的制約，在軟件開發(fā)的過程中，當時間、成本和質(zhì)量三者發(fā)生矛盾時，質(zhì)量最容易被忽視，如果測試組織與開發(fā)組織來自相同的機構(gòu)，測試過程就會面臨來自于開發(fā)組織同一來源的管理方面的壓力，使測試過程受到干擾。
采用獨立測試方式，無論在技術(shù)上還是管理上，對提高軟件測試的有效性都具有重要意義。
客觀性——對軟件測試和軟件中的錯誤抱著客觀的態(tài)度，這種客觀的態(tài)度可以解決測試中的心理學問題，既能以揭露軟件中錯誤的態(tài)度工作，也能不受發(fā)現(xiàn)的錯誤的影響。經(jīng)濟上的獨立性使測試有更充分的條件按測試要求去完成。
專業(yè)性——獨立測試作為一種專業(yè)工作，在長期的工作過程中勢必能夠積累大量實踐經(jīng)驗，形成自己的專業(yè)知識。同時軟件測試也是技術(shù)含量很高的工作，需要有專業(yè)隊伍加以研究，并進行工程實踐。專業(yè)化分工是提高測試水平、保證測試質(zhì)量、充分發(fā)揮測試效應的必然途徑。
權(quán)威性——由于專業(yè)優(yōu)勢，獨立測試工作形成的測試結(jié)果更具信服力，而測試結(jié)果常常和對軟件的質(zhì)量評價聯(lián)系在一起，專業(yè)化的獨立測試機構(gòu)的評價，更客觀、公正和具有權(quán)威性。
資源有保證——獨立測試機構(gòu)的主要任務是進行獨立測試工作，這使得測試工作在經(jīng)費、人力和計劃方面更有保證，不會因為開發(fā)的壓力減少對測試的投入，降低測試的有效性可以避免開發(fā)單位側(cè)重軟件開發(fā)而對測試工作產(chǎn)生不利的影響。
[編輯本段]
軟件測試主要工作內(nèi)容是驗證(verification)和確認(validation )，下面分別給出其概念：
驗證(verification)是保證軟件正確地實現(xiàn)了一些特定功能的一系列活動，即保證軟件做了你所期望的事情。(Do the right thing)
1.確定軟件生存周期中的一個給定階段的產(chǎn)品是否達到前階段確立的需求的過程；
2.程序正確性的形式證明，即采用形式理論證明程序符合設(shè)計規(guī)約規(guī)定的過程；
3.評市、審查、測試、檢查、審計等各類活動，或?qū)δ承╉椞幚怼⒎⻊栈蛭募仁欠窈鸵?guī)定的需求相一致進行判斷和提出報告。
確認(validation)是一系列的活動和過程，目的是想證實在一個給定的外部環(huán)境中軟件的邏輯正確性。即保證軟件以正確的方式來做了這個事件(Do it right)
1.靜態(tài)確認，不在計算機上實際執(zhí)行程序，通過人工或程序分析來證明軟件的正確性；
2.動態(tài)確認，通過執(zhí)行程序做分析，測試程序的動態(tài)行為，以證實軟件是否存在問題。
軟件測試的對象不僅僅是程序測試，軟件測試應該包括整個軟件開發(fā)期間各個階段所產(chǎn)生的文檔，如需求規(guī)格說明、概要設(shè)計文檔、詳細設(shè)計文檔，當然軟件測試的主要對象還是源程序。
[編輯本段]
從是否關(guān)心軟件內(nèi)部結(jié)構(gòu)和具體實現(xiàn)的角度劃分
A.白盒測試
B.黑盒測試
C.灰盒測試
B.動態(tài)測試。
B.集成測試
C.確認測試
D.系統(tǒng)測試
E.驗收測試
* 測試過程按4個步驟進行，即單元測試、集成測試、確認測試和系統(tǒng)測試及發(fā)版測試。
* 開始是單元測試，集中對用源代碼實現(xiàn)的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現(xiàn)了規(guī)定的功能。
* 集成測試把已測試過的模塊組裝起來，主要對與設(shè)計相關(guān)的軟件體系結(jié)構(gòu)的構(gòu)造進行測試。
* 確認測試則是要檢查已實現(xiàn)的軟件是否滿足了需求規(guī)格說明中確定了的各種需求，以及軟件配置是否完全、正確。
* 系統(tǒng)測試把已經(jīng)經(jīng)過確認的軟件納入實際運行環(huán)境中，與其它系統(tǒng)成份組合在一起進行測試。
單元測試 (Unit Testing)
* 單元測試又稱模塊測試，是針對軟件設(shè)計的最小單位 ─ 程序模塊，進行正確性檢驗的測試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯。
* 單元測試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例。多個模塊可以平行地獨立進行單元測試。
1. 單元測試的內(nèi)容
* 在單元測試時，測試者需要依據(jù)詳細設(shè)計說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結(jié)構(gòu)，主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應。
(1) 模塊接口測試
* 在單元測試的開始，應對通過被測模塊的數(shù)據(jù)流進行測試。測試項目包括：
– 調(diào)用本模塊的輸入?yún)?shù)是否正確；
– 本模塊調(diào)用子模塊時輸入給子模塊的參數(shù)是否正確；
– 全局量的定義在各模塊中是否一致；
* 在做內(nèi)外存交換時要考慮：
– 文件屬性是否正確；
– OPEN與CLOSE語句是否正確；
– 緩沖區(qū)容量與記錄長度是否匹配；
– 在進行讀寫操作之前是否打開了文件；
– 在結(jié)束文件處理時是否關(guān)閉了文件；
– 正文書寫／輸入錯誤，
– I／O錯誤是否檢查并做了處理。
(2) 局部數(shù)據(jù)結(jié)構(gòu)測試
* 不正確或不一致的數(shù)據(jù)類型說明
* 使用尚未賦值或尚未初始化的變量
* 錯誤的初始值或錯誤的缺省值
* 變量名拼寫錯或書寫錯
* 不一致的數(shù)據(jù)類型
* 全局數(shù)據(jù)對模塊的影響
(3) 路徑測試
* 選擇適當?shù)臏y試用例，對模塊中重要的執(zhí)行路徑進行測試。
* 應當設(shè)計測試用例查找由于錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。
* 對基本執(zhí)行路徑和循環(huán)進行測試可以發(fā)現(xiàn)大量的路徑錯誤。
(4) 錯誤處理測試
* 出錯的描述是否難以理解
* 出錯的描述是否能夠?qū)﹀e誤定位
* 顯示的錯誤與實際的錯誤是否相符
* 對錯誤條件的處理正確與否
* 在對錯誤進行處理之前，錯誤條件是否已經(jīng)引起系統(tǒng)的干預等
(5) 邊界測試
* 注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例，認真加以測試。
* 如果對模塊運行時間有要求的話，還要專門進行關(guān)鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運行時間的因素。
2. 單元測試的步驟
* 模塊并不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯(lián)系，用一些輔助模塊去模擬與被測模塊相聯(lián)系的其它模塊。
– 驅(qū)動模塊 (driver)
– 樁模塊 (stub) ── 存根模塊
* 如果一個模塊要完成多種功能，可以將這個模塊看成由幾個小程序組成。必須對其中的每個小程序先進行單元測試要做的工作，對關(guān)鍵模塊還要做性能測試。
* 對支持某些標準規(guī)程的程序，更要著手進行互聯(lián)測試。有人把這種情況特別稱為模塊測試，以區(qū)別單元測試。
集成測試（Integrated Testing）
* 集成測試 (集成測試、聯(lián)合測試）
* 通常，在單元測試的基礎(chǔ)上，需要將所有模塊按照設(shè)計要求組裝成為系統(tǒng)。這時需要考慮的問題是：
– 在把各個模塊連接起來的時候，穿越模塊接口的數(shù)據(jù)是否會丟失；
– 一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響；
– 各個子功能組合起來，能否達到預期要求的父功能；
– 全局數(shù)據(jù)結(jié)構(gòu)是否有問題；
– 單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。
在單元測試的同時可進行集成測試，
發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)
的問題，最終構(gòu)成要求的軟件系統(tǒng)。
* 子系統(tǒng)的集成測試特別稱為部件測試，它所做的工作是要找出集成后的子系統(tǒng)與系統(tǒng)需求規(guī)格說明之間的不一致。
* 通常，把模塊集成成為系統(tǒng)的方式有兩種
– 一次性集成方式
– 增殖式集成方式
1. 一次性集成方式(big bang)
* 它是一種非增殖式組裝方式。也叫做整體拼裝。
* 使用這種方式，首先對每個模塊分別進行模塊測試，然后再把所有模塊組裝在一起進行測試，最終得到要求的軟件系統(tǒng)。
2. 增殖式集成方式
* 這種集成方式又稱漸增式集成
* 首先對一個個模塊進行模塊測試，然后將這些模塊逐步組裝成較大的系統(tǒng)
* 在集成的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題
* 通過增殖逐步組裝成為要求的軟件系統(tǒng)。
(1) 自頂向下的增殖方式
* 這種集成方式將模塊按系統(tǒng)程序結(jié)構(gòu)，沿控制層次自頂向下進行組裝。
* 自頂向下的增殖方式在測試過程中較早地驗證了主要的控制和判斷點。
* 選用按深度方向組裝的方式，可以首先實現(xiàn)和驗證一個完整的軟件功能。
(2) 自底向上的增殖方式
* 這種集成的方式是從程序模塊結(jié)構(gòu)的最底層的模塊開始集成和測試。
* 因為模塊是自底向上進行組裝，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)組裝并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。
* 自頂向下增殖的方式和自底向上增殖的方式各有優(yōu)缺點。
* 一般來講，一種方式的優(yōu)點是另一種方式的缺點。
(3) 混合增殖式測試
* 衍變的自頂向下的增殖測試
– 首先對輸入／輸出模塊和引入新算法模塊進行測試;
– 再自底向上組裝成為功能相當完整且相對獨立的子系統(tǒng);
– 然后由主模塊開始自頂向下進行增殖測試。
* 自底向上-自頂向下的增殖測試
– 首先對含讀操作的子系統(tǒng)自底向上直至根結(jié)點模塊進行組裝和測試;
– 然后對含寫操作的子系統(tǒng)做自頂向下的組裝與測試。
* 回歸測試
– 這種方式采取自頂向下的方式測試被修改的模塊及其子模塊;
– 然后將這一部分視為子系統(tǒng)，再自底向上測試。
關(guān)鍵模塊問題
* 在組裝測試時，應當確定關(guān)鍵模塊，對這些關(guān)鍵模塊及早進行測試。
* 關(guān)鍵模塊的特征：
�、� 滿足某些軟件需求；
�、� 在程序的模塊結(jié)構(gòu)中位于較高的層次（高層控制模塊）；
③ 較復雜、較易發(fā)生錯誤；
④ 有明確定義的性能要求。
確認測試（Validation Testing）
* 確認測試又稱有效性測試。任務是驗證軟件的功能和性能及其它特性是否與用戶的要求一致。
* 對軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定。它包含的信息就是軟件確認測試的基礎(chǔ)。
1. 進行有效性測試（黑盒測試）
* 有效性測試是在模擬的環(huán)境 (可能就是開發(fā)的環(huán)境) 下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規(guī)格說明書列出的需求。
* 首先制定測試計劃，規(guī)定要做測試的種類。還需要制定一組測試步驟，描述具體的測試用例。
* 通過實施預定的測試計劃和測試步驟，確定
– 軟件的特性是否與需求相符；
– 所有的文檔都是正確且便于使用；
– 同時，對其它軟件需求，例如可移植性、兼容性、出錯自動恢復、可維護性等，也都要進行測試
* 在全部軟件測試的測試用例運行完后，所有的測試結(jié)果可以分為兩類：
– 測試結(jié)果與預期的結(jié)果相符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合，從而這部分程序被接受。
– 測試結(jié)果與預期的結(jié)果不符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致，因此要為它提交一份問題報告。
2. 軟件配置復查
n 軟件配置復查的目的是保證
u 軟件配置的所有成分都齊全；
u 各方面的質(zhì)量都符合要求；
u 具有維護階段所必需的細節(jié)；
u 而且已經(jīng)編排好分類的目錄。
n 應當嚴格遵守用戶手冊和操作手冊中規(guī)定的使用步驟，以便檢查這些文檔資料的完整性和正確性。
驗收測試（Acceptance Testing）
* 在通過了系統(tǒng)的有效性測試及軟件配置審查之后，就應開始系統(tǒng)的驗收測試。
* 驗收測試是以用戶為主的測試。軟件開發(fā)人員和QA（質(zhì)量保證）人員也應參加。
* 由用戶參加設(shè)計測試用例，使用生產(chǎn)中的實際數(shù)據(jù)進行測試。
* 在測試過程中，除了考慮軟件的功能和性能外，還應對軟件的可移植性、兼容性、可維護性、錯誤的恢復功能等進行確認。
* 確認測試應交付的文檔有：
– 確認測試分析報告
– 最終的用戶手冊和操作手冊
– 項目開發(fā)總結(jié)報告。
系統(tǒng)測試（System Testing）
* 系統(tǒng)測試，是將通過確認測試的軟件，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合在一起，在實際運行環(huán)境下，對計算機系統(tǒng)進行一系列的組裝測試和確認測試。
* 系統(tǒng)測試的目的在于通過與系統(tǒng)的需求定義作比較, 發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。
[編輯本段]
集成測試
系統(tǒng)測試
從左到右，描述了基本的開發(fā)過程和測試行為，非常明確地標明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發(fā)過程期間各階段的對應關(guān)系 。
左邊依次下降的是開發(fā)過程各階段，與此相對應的是右邊依次上升的部分，即各測試過程的各個階段。
用戶需求 驗收測試
需求分析和系統(tǒng)設(shè)計 確認測試和系統(tǒng)測試
概要設(shè)計 集成測試
詳細設(shè)計 單元測試
編碼
V模型問題：
1.測試是開發(fā)之后的一個階段。
2.測試的對象就是程序本身。
3.實際應用中容易導致需求階段的錯誤一直到最后系統(tǒng)測試階段才被發(fā)現(xiàn)。
4.整個軟件產(chǎn)品的過程質(zhì)量保證完全依賴于開發(fā)人員的能力和對工作的責任心，而且上一步的結(jié)果必須是充分和正確的，如果任何一個環(huán)節(jié)出了問題，則必將嚴重的影響整個工程的質(zhì)量和預期進度
這個示意圖演示了在整個生產(chǎn)周期中某個層次上的一次測試“微循環(huán)”。圖中標注的其它流程可以是任意的開發(fā)流程,例如設(shè)計流程或者編碼流程。也就是說, 只要測試條件成熟了,測試準備活動完成了,測試執(zhí)行活動就可以進行了。
H模型揭示了一個原理:軟件測試是一個獨立的流程,貫穿產(chǎn)品整個生命周期,與其他流程并發(fā)地進行。H模型指出軟件測試要盡早準備, 盡早執(zhí)行。不同的測試活動可以是按照某個次序先后進行的,但也可能是反復的,只要某個測試達到準備就緒點,測試執(zhí)行活動就可以開展。
軟件測試工程師成長之路：http://www.sz-btesting.com
隨著我國軟件業(yè)的發(fā)展，專業(yè)的軟件測試人員成為了眾多知名公司追逐的對象，軟件測試有著廣闊的發(fā)展前景，具體可以分為：
• 初級測試工程師：初級職位，開發(fā)測試腳本，執(zhí)行測試
•測試工程師 / 程序分析員：編寫自動測試腳本程序
•高級測試工程師 / 程序分析員：確定測試過程并指導初級測試工程師
•測試組負責人：監(jiān)管 1-3 人工作，負責規(guī)模 / 成本估算
•測試 / 編程負責人：監(jiān)管 4-8 人，安排和領(lǐng)導任務完成，提出技術(shù)方法
•測試 / 質(zhì)量保證 / 項目經(jīng)理：負責 8 名以上人員的一個或多個項目，負責全生存期
•業(yè)務 / 產(chǎn)品經(jīng)理：負責多個項目的人員管理，負責項目方向和業(yè)務盈虧
[編輯本段]
• 軟件測試工程師
定義
軟件測試工程師簡單的說是軟件開發(fā)過程中的質(zhì)量檢測者和保障者，負責軟件質(zhì)量的把關(guān)工作。軟件測試工程師（Software Testing Engineer）的主要工作職責是，理解產(chǎn)品的功能要求，并對其進行測試，檢查軟件有沒有錯誤（Bug），決定軟件是否具有穩(wěn)定性（Robustness），寫出相應的測試規(guī)范和測試用例。簡而言之，軟件測試工程師在一家軟件企業(yè)中擔當?shù)氖恰百|(zhì)量管理”角色，及時糾錯及時更正，確保產(chǎn)品的正常運作。[1]
工作內(nèi)容
1、編寫軟件測試計劃，設(shè)計軟件測試腳本和用例，搭建軟件測試環(huán)境；
2、執(zhí)行軟件項目測試，包括功能測試、性能測試、易用性測試等；
3、整理、分析、報告并追蹤軟件缺陷，并確認軟件測試問題得以解決；
4、撰寫軟件測試結(jié)果分析報告，預先評估項目的風險，編寫其它相關(guān)文檔；
5、結(jié)合研發(fā)軟件產(chǎn)品項目情況，制定相應的軟件、項目版本控制制度。
• 至少是一名軟件開發(fā)工程師
• 軟件測試技術(shù)主管
• 軟件測試設(shè)計師
[編輯本段]
• 測試主管
• 測試管理者
• 項目主管
• 產(chǎn)品發(fā)布主管
[編輯本段]
51testing軟件測試論壇：http://www.51testing.com
介紹：軟件測試網(wǎng)包括軟件測試論壇、軟件測試博客和文章資料精選三大模塊，提供學習、交流、教材下載以及求職、招聘信息的發(fā)布、檢索等服務。
中國軟件測試：http://softtest.chinaitlab.com/
介紹：中國軟件測試網(wǎng)是中國IT實驗室核心技術(shù)頻道，致力于打造國內(nèi)最大最全的軟件測試技術(shù)文獻平臺。
北大青鳥軟件測試網(wǎng)站：http://www.sz-btesting.com
介紹：北大青鳥軟件測試網(wǎng)站提供豐富軟件測試技術(shù)資料，開設(shè)軟件測試人才招聘專區(qū)，開展軟件測試主題講座，軟件測試在線咨詢，軟件測試工程師專題，測試資料下載等信息服務。
技術(shù)文獻目錄：
手機測試：http://softtest.chinaitlab.com/sji/Index.html
[編輯本段]
AutoRunner 是國內(nèi)第一款自動化測試工具，可以用來完成功能測試、回歸測試、每日構(gòu)建測試與自動回歸測試等工作。是具有腳本語言的、提供針對腳本完善的跟蹤和調(diào)試功能的、支持IE測試和Windows native測試的自動化測試工具。
TestCenter 是一款功能強大測試管理工具，它可以幫助您：實現(xiàn)測試用例的過程管理，對測試需求過程、測試用例設(shè)計過程、業(yè)務組件設(shè)計實現(xiàn)過程等整個測試過程進行管理。實現(xiàn)測試用例的標準化即每個測試人員都能夠理解并使用標準化后的測試用例，降低了測試用例對個人的依賴；提供測試用例復用，用例和腳本能夠被復用，以保護測試人員的資產(chǎn)；提供可伸縮的測試執(zhí)行框架，提供自動測試支持；提供測試數(shù)據(jù)管理，幫助用戶同意管理測試數(shù)據(jù)，降低測試數(shù)據(jù)和測試腳本之間的耦合度。
TAR(Terminal AutoRunner)適用于VT100、VT220等標準的應用系統(tǒng)，支持命令行模式和窗口模式（使用Cursors編寫的應用程序）,支持自動錄制腳本、所見即所得的資源和腳本編輯，穩(wěn)定的自動同步功能。是目前國內(nèi)最好的銀行業(yè)務測試工具.
LoadRunner 是一種預測系統(tǒng)行為和性能的工業(yè)標準級負載測試工具。通過以模擬上千萬用戶實施并發(fā)負載及實時性能監(jiān)測的方式來確認和查找問題，LoadRunner 能夠?qū)φ麄�企業(yè)架構(gòu)進行測試。通過使用LoadRunner ， 企業(yè)能最大限度地縮短測試時間， 優(yōu)化性能和加速應用系統(tǒng)的發(fā)布周期。目前企業(yè)的網(wǎng)絡應用環(huán)境都必須支持大量用戶，網(wǎng)絡體系架構(gòu)中含各類應用環(huán)境且由不同供應商提供軟件和硬件產(chǎn)品。難以預知的用戶負載和愈來愈復雜的應用環(huán)境使公司時時擔心會發(fā)生用戶響應速度過慢， 系統(tǒng)崩潰等問題。這些都不可避免地導致公司收益的損失。
TestDirector 是全球最大的軟件測試工具提供商Mercury Interactive公司生產(chǎn)的企業(yè)級測試管理工具，也是業(yè)界第一個基于Web的測試管理系統(tǒng),它可以在您公司內(nèi)部或外部進行全球范圍內(nèi)測試的管理。通過在一個整體的應用系統(tǒng)中集成了測試管理的各個部分，包括需求管理，測試計劃，測試執(zhí)行以及錯誤跟蹤等功能，TestDirector極大地加速了測試過程。
[編輯本段]
1 目的：統(tǒng)一測試用例編寫的規(guī)范，以保證使用最有效的測試用例，保證測試質(zhì)量。
2 范圍：適用于公司對產(chǎn)品的業(yè)務流程、功能測試測試用例的編寫。
3 術(shù)語解釋
3.1 測試分析：對重要業(yè)務、重要流程進行測試前的分析。
3.2 業(yè)務流程測試用例：關(guān)于產(chǎn)品業(yè)務、重要流程的測試用例。
4 業(yè)務流程測試用例編寫原則
4.1 系統(tǒng)性
4.1.1 對于系統(tǒng)業(yè)務流程要能夠完整說明整個系統(tǒng)的業(yè)務需求、系統(tǒng)由幾個子系統(tǒng)組成以及它們之間的關(guān)系；
4.1.2 對于模塊業(yè)務流程要能夠說明清楚子系統(tǒng)內(nèi)部功能、重要功能點以及它們之間的關(guān)系；
4.2 連貫性
4.2.1 對于系統(tǒng)業(yè)務流程來說，各個子系統(tǒng)之間是如何連接在一起，如果需要接口，各個子系統(tǒng)之間是否有正確的接口；如果是依靠頁面鏈接，頁面鏈接是否正確；
4.2.2 對于模塊業(yè)務流程來說，同級模塊以及上下級模塊是如何構(gòu)成一個子系統(tǒng)，其內(nèi)部功能接口是否連貫；
5 測試用例設(shè)計的方法
5.1 等價類劃分法
5.1.1 確定等價類的原則
5.1.1.1 如果輸入條件決定了取值范圍，或值的個數(shù)，則可以確立一個有效等價類和兩個無效等價類。
5.1.1.2 如果輸入條件規(guī)定了輸入值的集合，或者規(guī)定了“必須如何”的條件，此時可確立一個有效等價類和一個無效等價類；
5.1.1.3 如果輸入條件是一個布爾量，則可以確定一個有效等價類和一個無效等價類；
5.1.1.4 如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序?qū)γ總�輸入值分別進行處理，此時可為每一個輸入值確立一個有效等價類，此外，針對這組值確立一個無效等價類，它是所有不允許輸入值的集合；
5.1.1.5 如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則，則可以確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同的角度違反規(guī)則）。
5.1.1.6 如果確知，已劃分的等價類中各元素在程序中的處理方式不同，則應將此等價類進一步劃分成更小的等價類。
5.1.2 測試用例的選擇原則
5.1.2.1 為每一個等價類規(guī)定一個唯一的編號；
5.1.2.2 設(shè)計一個新的測試用例，使其盡可能多的覆蓋尚未被覆蓋的有效等價類，重復這一步，直至所有的有效等價類都被覆蓋過；
5.1.2.3 設(shè)計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直至所有的無效等價類都被覆蓋為止。
5.2 邊界值分析法
5.2.1 測試用例的選擇原則
5.2.1.1 如果輸入了條件規(guī)定了值的范圍，則應取剛達到這個范圍的邊界值，以及剛剛超越這個邊界范圍的值作為測試輸入數(shù)據(jù)；
5.2.1.2 如果輸入條件規(guī)定了值的個數(shù)，則用最大個數(shù)、最小個數(shù)、比最大多1、比最小小1的數(shù)作為測試輸入數(shù)據(jù)；
5.2.1.3 根據(jù)規(guī)格說明的每個輸出條件，使用前面的原則；
5.2.1.4 如果程序的規(guī)格說明給出的輸入輸出域是有序集合，則應選取集合的每一個元素和最后一個元素作為測試用列；
5.2.1.5 如果程序中使用了一個內(nèi)部數(shù)據(jù)結(jié)構(gòu)，則應當選擇這個內(nèi)部數(shù)據(jù)結(jié)構(gòu)的邊界上的值作為測試用例；
5.2.1.6 分析規(guī)格說明，找出其他可能的邊界條件。
6 測試用例設(shè)計的原則
6.1 全面性
6.1.1 應盡可能覆蓋程序的各種路徑
6.1.2 應考慮存在跨年、跨月的數(shù)據(jù)
6.1.3 大量數(shù)據(jù)并發(fā)測試的準備
6.2 正確性
6.2.1 輸入界面后的數(shù)據(jù)應與測試文檔所記錄的數(shù)據(jù)一致
6.2.2 預期結(jié)果應與測試數(shù)據(jù)發(fā)生的業(yè)務吻合
6.3 符合正常業(yè)務慣例
6.3.1 測試數(shù)據(jù)應符合用戶實際工作業(yè)務流程
6.3.2 兼顧各種業(yè)務變化的可能
6.4 仿真性
人名、地名、電話號碼等應具有模擬功能，符合一般的命名慣例；不允許出現(xiàn)與知名人士、小說中人物名等雷同情況。
6.5 可操作性
測試用例中應寫清測試的操作步驟，不同的操作步驟相對應的操作結(jié)果。
7 測試用例編寫格式細則
7.1 測試用例內(nèi)容
7.1.1 具體實施可以采用EXCEL和圖形相結(jié)合，可用EXCEL編寫測試用例的同時插入圖形來加以說明。測試用例設(shè)計的內(nèi)容可由：模塊名、功能說明或圖形說明、測試用例輸入、應輸出結(jié)果、實際輸出結(jié)果、結(jié)論、BUG編號、BUG級別8部分組成。
7.1.2 在測試用例設(shè)計模版中有“業(yè)務流程測試用例設(shè)計模版”（包含整體業(yè)務流程）和“功能測試用例設(shè)計模版”兩個模板可按需要選擇。
7.2 測試用例表格格式
7.2.1 表格內(nèi)容的字體為宋體；
7.2.2 表格內(nèi)容的字型為12號；
8 測試用例優(yōu)先級
測試用例優(yōu)先級 描述
A 測試計劃中重要的模塊功能和業(yè)務流程
B 測試計劃中比較重要的模塊功能和業(yè)務流程
C 測試計劃中次重要的模塊功能和業(yè)務流程
D 測試計劃中不重要的模塊功能和業(yè)務流程
E 系統(tǒng)小單元、系統(tǒng)容錯功能
對于A、B 級應重點考慮
9 BUG級別
參考軟件測試停止標準中的錯誤級別.
[編輯本段]
外包軟件測試就是指軟件企業(yè)將軟件項目中的全部或部分測試工作，交給提供軟件外包測試服務的公司，由他們?yōu)檐浖M行專門的測試。這樣做的好處有兩個：一方面軟件企業(yè)可以更好地專注核心競爭力業(yè)務，同時降低軟件項目成本；另一方面，由第三方專業(yè)的測試公司進行測試，無論在技術(shù)上還是管理上，對提高軟件測試的有效性都具有重要意義。
外包軟件測試行業(yè)前景非常看好，發(fā)展空間很大。IDG的數(shù)據(jù)顯示，最近幾年，中國的軟件外包產(chǎn)業(yè)年均增長率為36.5%，正處于快速發(fā)展的階段，2008年預計已達到16.9億美元的市場規(guī)模。目前韓日、歐美國家的軟件企業(yè)紛紛關(guān)注中國市場，而作為軟件外包強國的印度，在其國內(nèi)處于前幾位的軟件外包服務商也準備來“分一杯羹”。從目前市場來看，選擇將部分軟件測試工作進行外包的公司主要是微軟、IBM等國際軟件旗艦企業(yè)，他們利用第三方專業(yè)軟件測試公司，在產(chǎn)品發(fā)布前對軟件進行一系列的集成測試和系統(tǒng)測試，既保證了測試工作的全面性，又節(jié)省了人力、物力的開銷。最重要的是，測試結(jié)果往往好于這些軟件企業(yè)最初的預期，效果非常令人滿意。軟件企業(yè)和提供軟件外包測試服務的公司進行合作，只要達成雙贏，兩方皆大歡喜，這樣的合作就會越來越多，項目也會越做越大。
主要業(yè)務類型
·本地化軟件測試
·國際化軟件測試
主要測試的范圍
·本地化語言質(zhì)量測試
·國際化軟件的功能和性能測試
測試工作主要方式
·公司內(nèi)部（In house）執(zhí)行的測試
·派駐客戶開發(fā)中心的現(xiàn)場測試（On site）。
[編輯本段]
一、 軟件開發(fā)中出現(xiàn)錯誤或缺陷的機會越來越多。
市場對軟件質(zhì)量重要性的認識逐漸增強。所以，軟件測試在軟件項目實施過程中的重要性日益突出。但是，現(xiàn)實情況是，與軟件編程比較，軟件測試的地位和作用，還沒有真正受到重視，對于很多人（甚至是軟件項目組的技術(shù)人員）還存在對軟件測試的認識誤區(qū)，這進一步影響了軟件測試活動開展和真正提高軟件測試質(zhì)量。
�。�1）誤區(qū)之一：軟件開發(fā)完成后進行軟件測試
人們一般認為，軟件項目要經(jīng)過以下幾個階段：需求分析，概要設(shè)計，詳細設(shè)計，軟件編碼，軟件測試，軟件發(fā)布。據(jù)此，認為軟件測試只是軟件編碼后的一個過程。這是不了解軟件測試周期的錯誤認識。軟件測試是一個系列過程活動，包括軟件測試需求分析，測試計劃設(shè)計，測試用例設(shè)計，執(zhí)行測試。因此，軟件測試貫穿于軟件項目的整個生命過程。在軟件項目的每一個階段都要進行不同目的和內(nèi)容的測試活動，以保證各個階段的正確性。軟件測試的對象不僅僅是軟件代碼，還包括軟件需求文檔和設(shè)計文檔。軟件開發(fā)與軟件測試應該是交互進行的，例如，單元編碼需要單元測試，模塊組合階段需要集成測試。如果等到軟件編碼結(jié)束后才進行測試，那么，測試的時間將會很短，測試的覆蓋面將很不全面，測試的效果也將大打折扣。更嚴重的是如果此時發(fā)現(xiàn)了軟件需求階段或概要設(shè)計階段的錯誤，如果要修復該類錯誤，將會耗費大量的時間和人力。
�。�2）誤區(qū)之二：軟件發(fā)布后如果發(fā)現(xiàn)質(zhì)量問題，那是軟件測試人員的錯
這種認識很打擊軟件測試人員的積極性。軟件中的錯誤可能來自軟件項目中的各個過程，軟件測試只能確認軟件存在錯誤，不能保證軟件沒有錯誤，因為從根本上講，軟件測試不可能發(fā)現(xiàn)全部的錯誤。從軟件開發(fā)的角度看，軟件的高質(zhì)量不是軟件測試人員測出來的，是靠軟件生命周期的各個過程中設(shè)計出來的。出現(xiàn)軟件錯誤，不能簡單地歸結(jié)為某一個人的責任，有些錯誤的產(chǎn)生可能不是技術(shù)原因，可能來自于混亂的項目管理。應該分析軟件項目的各個過程，從過程改進方面尋找產(chǎn)生錯誤的原因和改進的措施。
�。�3）誤區(qū)之三：軟件測試要求不高，隨便找個人多都行
很多人都認為軟件測試就是安裝和運行程序，點點鼠標，按按鍵盤的工作。這是由于不了解軟件測試的具體技術(shù)和方法造成的。隨之軟件工程學的發(fā)展和軟件項目管理經(jīng)驗的提高，軟件測試已經(jīng)形成了一個獨立的技術(shù)學科，演變成一個具有巨大市場需求的行業(yè)。軟件測試技術(shù)不斷更新和完善，新工具，新流程，新測試設(shè)計方法都在不斷更新，需要掌握和學習很多測試知識。所以，具有編程經(jīng)驗的程序員不一定是一名優(yōu)秀的測試工程師。軟件測試包括測試技術(shù)和管理兩個方面，完全掌握這兩個方面的內(nèi)容，需要很多測試實踐經(jīng)驗和不斷學習精神。
�。�4）誤區(qū)之四：軟件測試是測試人員的事情，與程序員無關(guān)開發(fā)和測試是相輔相成的過程
需要軟件測試人員、程序員和系統(tǒng)分析師等保持密切的聯(lián)系，需要更多的交流和協(xié)調(diào)，以便提高測試效率。另外，對于單元測試主要應該由程序員完成，必要時測試人員可以幫助設(shè)計測試樣例。對于測試中發(fā)現(xiàn)的軟件錯誤，很多需要程序員通過修改編碼才能修復。程序員可以通過有目的的分析軟件錯誤的類型、數(shù)量，找出產(chǎn)生錯誤的位置和原因，以便在今后的編程中避免同樣的錯誤，積累編程經(jīng)驗，提高編程能力。
（5）誤區(qū)之五：項目進度吃緊時少做些測試，時間富裕時多做測試
這是不重視軟件測試的表現(xiàn)，也是軟件項目過程管理混亂的表現(xiàn)，必然會降低軟件測試的質(zhì)量。一個軟件項目的順利實現(xiàn)需要有合理的項目進度計劃，其中包括合理的測試計劃，對項目實施過程中的任何問題，都要有風險分析和相應的對策，不要因為開發(fā)進度的延期而簡單的縮短測試時間、人力和資源。因為縮短測試時間帶來的測試不完整，對項目質(zhì)量的下降引起的潛在風險，往往造成更大的浪費�？朔@種現(xiàn)象的最好辦法是加強軟件過程的計劃和控制，包括軟件測試計劃、測試設(shè)計、測試執(zhí)行、測試度量和測試控制。
�。�6）誤區(qū)之六：軟件測試是沒有前途的工作，只有程序員才是軟件高手
由于我國軟件整體開發(fā)能力比較低，軟件過程很不規(guī)范，很多軟件項目的開發(fā)都還停留在“作坊式”和“壘雞窩”階段。項目的成功往往靠個別全能程序員決定，他們負責總體設(shè)計和程序詳細設(shè)計，認為軟件開發(fā)就是編寫代碼，給人的印象往往是程序員是真正的牛人，具有很高的地位和待遇。因此，在這種環(huán)境下，軟件測試很不受重視，軟件測試人員的地位和待遇自然就很低了，甚至軟件測試變得可有可無。隨著市場對軟件質(zhì)量的不斷提高，軟件測試將變得越來越重要，相應的軟件測試人員的地位和待遇將會逐漸提高。在微軟等軟件過程比較規(guī)范的大公司，軟件測試人員的數(shù)量和待遇與程序員沒有多大差別，優(yōu)秀測試人員的待遇甚至比程序員還要高。軟件測試將會成為一個具有很大發(fā)展前景的行業(yè)，軟件測試大有前途，市場需要更多具有豐富測試技術(shù)和管理經(jīng)驗的測試人員，他們同樣是軟件專家。這兩年來國內(nèi)軟件測試人員的需求不斷增大,越來越多的IT企業(yè)認識到了軟件測試的重要性,這種可喜的現(xiàn)狀與發(fā)展趨勢讓筆者對我國軟件業(yè)的發(fā)展重新抱有較大的希望。
盡管這是一門嶄新的學科,目前在國內(nèi)的發(fā)展仍處于"嬰兒"階段,但看到越來越多的軟件公司為軟件測試招兵買馬,看到越來越多的技術(shù)人員投入到軟件測試中,我就情不自禁地感嘆:機會來了!這機會不僅僅是某一個人的,而是所有人的,它對每個人都是公平的,學的領(lǐng)域需要新的理論新的工具新的方法,由于國內(nèi)的軟件測試還處在一個比較初級的階段，沒有人確切地知道它需要什么樣的基礎(chǔ),也沒有人確切地知道它應該怎樣發(fā)展,因此這個領(lǐng)域需要大家來共同革命,以促進它的深入發(fā)展。
二、軟件測試的前景
隨著軟件產(chǎn)業(yè)的發(fā)展，軟件產(chǎn)品的質(zhì)量控制與質(zhì)量管理正逐漸成為軟件企業(yè)生存與發(fā)展的核心。幾乎每個大中型IT企業(yè)的軟件產(chǎn)品在發(fā)布前都需要大量的質(zhì)量控制、測試和文檔工作，而這些工作必須依靠擁有嫻熟技術(shù)的專業(yè)軟件人才來完成。軟件測試工程師就是這樣的一個企業(yè)重頭角色。業(yè)內(nèi)人士分析，該類職位的需求主要集中在沿海發(fā)達城市，其中北京和上海的需求量分別占去33%和29%。民企需求量最大，占19%，外商獨資歐美類企業(yè)需求排列第二，占15%。然而，目前的現(xiàn)狀是：一方面企業(yè)對高質(zhì)量的測試工程師需求量越來越大越大，另一方面國內(nèi)原來對測試工程師的職業(yè)重視程度不夠，使許多人不了解測試工程師具體是從事什么工作。這使得許多IT公司只能通過在實際工作中進行淘汰的方式對測試工程師進行篩選，因此國內(nèi)在短期將出現(xiàn)測試工程師嚴重短缺的現(xiàn)象。根據(jù)對近期網(wǎng)絡招聘IT人才情況的了解，許多正在招聘軟件測試工程師的企業(yè)
很少能夠在招聘會上順利招到合適的人才。在具體工作過程中，測試工程師的工作是利用測試工具按照測試方案和流程對產(chǎn)品進行功能和性能測試，甚至根據(jù)需要編寫不同的測試用例，設(shè)計和維護測試系統(tǒng)，對測試方案可能出現(xiàn)的問題進行分析和評估。對軟件測試工程師而言，必須具有高度的工作責任心和自信心。任何嚴格的測試必須是一種實事求是的測試，因為它關(guān)系到一個產(chǎn)品的質(zhì)量問題，而測試工程師則是產(chǎn)品出貨前的把關(guān)人，所以，沒有專業(yè)的技術(shù)水準是無法勝任這項工作的。同時，由于測試工作一般由多個測試工程師共同完成，并且測試部門一般要與其他部門的人員進行較多的溝通，所以要求測試工程師不但要有較強的技術(shù)能力而且要有較強的溝通能力。
它是幫助識別開發(fā)完成（中間或最終的版本）的計算機軟件（整體或部分）的正確度(correctness) 、完全度(completeness)和質(zhì)量(quality)的軟件過程；是SQA(software quality assurance)的重要子域。
Grenford J.Myers曾對軟件測試的目的提出過以下觀點:
(1)測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程；
(2)好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案；
(3)成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。
然而,這種觀點指出測試是以查找錯誤為中心,而不是為了演示軟件的正確功能.但是只從字面意思理解,可能會產(chǎn)生誤導,認為發(fā)現(xiàn)錯誤是軟件測試的唯一目的,查找不出錯誤的測試就是沒有價值的測試,實際上并非如此!
(1)測試并不僅僅是為了找出錯誤.通過分析錯誤產(chǎn)生的原因和錯誤的發(fā)生趨勢,可以幫助項目管理者
發(fā)現(xiàn)當前軟件開發(fā)過程中的缺陷,以便及時改進；
(2)這種分析也能幫助測試人員設(shè)計出有針對性的測試方法,改善測試的效率和有效性；
(3)沒有發(fā)現(xiàn)錯誤的測試也是有價值的,完整的測試是評定軟件質(zhì)量的一種方法
軟件測試完整分類，參見：軟件測試的完整分類
軟件測試的原則
軟件測試的幾大原則：1.軟件開發(fā)人員即程序員應當避免測試自己的程序
測試模型---W模型
不管是程序員還是開發(fā)小組都應當避免測試自己的程序或者本組開發(fā)的功能模塊。若條件允許，應當由獨立于開發(fā)組和客戶的第三方測試組或測試機構(gòu)來進行軟件測試。但這并不是說程序員不能測試自己的程序，而且更加鼓勵程序員進行調(diào)試，因為測試由別人來進行可能會會更加有效、客觀，并且容易成功，而允許程序員自己調(diào)試也會更加有效和針對性。
2. 應盡早地和不斷地進行軟件測試
應當把軟件測試貫穿到整個軟件開發(fā)的過程中，而不應該把軟件測試看作是其過程中的一個獨立階段。因為在軟件開發(fā)的每一環(huán)節(jié)都有可能產(chǎn)生意想不到的問題，其影響因素有很多，比如軟件本身的抽象性和復雜性、軟件所涉及問題的復雜性、軟件開發(fā)各個階段工作的多樣性，以及各層次工作人員的配合關(guān)系等。所以要堅持軟件開發(fā)各階段的技術(shù)評審，把錯誤克服在早期，從而減少成本，提高軟件質(zhì)量。
3.對測試用例要有正確的態(tài)度：第一，測試用例應當由測試輸入數(shù)據(jù)和預期輸出結(jié)果這兩部分組成；第二，在設(shè)計測試用例時，不僅要考慮合理的輸入條件，更要注意不合理的輸入條件。因為軟件投入實際運行中，往往不遵守正常的使用方法，卻進行了一些甚至大量的意外輸入導致軟件一時半時不能做出適當?shù)姆磻�，就很容易產(chǎn)生一系列的問題，輕則輸出錯誤的結(jié)果，重則癱瘓失效！因此常用一些不合理的輸入條件來發(fā)現(xiàn)更多的鮮為人知的軟件缺陷。
4.人以群分，物以類聚，軟件測試也不例外，一定要充分注意軟件測試中的群集現(xiàn)象，也可以認為是“80-20原則”。不要以為發(fā)現(xiàn)幾個錯誤并且解決這些問題之后，就不需要測試了。反而這里是錯誤群集的地方，對這段程序要重點測試，以提高測試投資的效益。
5.嚴格執(zhí)行測試計劃，排除測試的隨意性，以避免發(fā)生疏漏或者重復無效的工作。
6.應當對每一個測試結(jié)果進行全面檢查。一定要全面地、仔細地檢查測試結(jié)果，但常常被人們忽略，導致許多錯誤被遺漏。
7.妥善保存測試用例、測試計劃、測試報告和最終分析報告，以備回歸測試及維護之用。
在遵守以上原則的基礎(chǔ)上進行軟件測試，可以以最少的時間和人力找出軟件中的各種缺陷，從而達到保證軟件質(zhì)量的目的。
軟件測試的心理學
人類行為具有高度目標性，確立一個正確的目標有著重要的心理學影響。軟件測試的心理學問題就是如何擺正測試的兩個目標的關(guān)系，使得測試活動更加富有成效。1.程序測試的過程具有破壞性
每當測試一個程序時，人們總希望為程序增加一些價值。利用測試來增加程序的價值，是指通過測試，找出并修改盡可能多的程序缺陷，從而提高程序的可靠性或質(zhì)量。
因此，不要只是為了證明程序能夠正確運行而去測試程序。相反，應該一開始就假設(shè)程序中隱藏著錯誤（這種假設(shè)幾乎對所有的程序都成立），然后測試程序，發(fā)現(xiàn)盡可能多的錯誤。
事實上，如果把測試目標定位于要證明程序中沒有缺陷，那么就會在潛意識中傾向于實現(xiàn)這個目標。也就是說，測試人員會傾向于挑選那些使程序失效的可能性較小的測試數(shù)據(jù)。另一方面，如果把測試目標定位于要證明程序中存在缺陷，那么就會選擇一些容易發(fā)現(xiàn)程序缺陷的測試數(shù)據(jù)。而后一種態(tài)度會比前者給程序增加更多的價值。
因此，大多數(shù)測試專業(yè)人員都贊同Myers對測試的定義：“測試是為發(fā)現(xiàn)錯誤而執(zhí)行程序的錯誤。”這個定義意味著程序測試的過程是具有破壞性的，甚至是一個“施虐”過程。開發(fā)人員可能不愿意這么做，因為人們總是傾向于建設(shè)而不是破壞。這個定義還暗示了對于一個特定的程序，應該如何設(shè)計測試用例（測試數(shù)據(jù)）、哪些人應該而哪些人又不應該執(zhí)行測試。
事實上，如果在測試某個程序段時發(fā)現(xiàn)了可以糾正的缺陷，或者測試最終確定在沒有其他缺陷，則應將這次合理設(shè)計并得到有效執(zhí)行的測試稱作是“成功的”。而所謂“不成功的”測試，僅指未能適當?shù)貙Τ绦蜻M行檢查，未能找出程序中潛藏缺陷的測試。因為軟件中不可能沒有缺陷，沒有找出它們，當然測試是“不成功的”。
“軟件測試就是證明軟件不存在錯誤的過程”。對幾乎所有的程序而言，甚至是非常小的程序，這個目標實際上是無法達到的。因為即使程序完全實現(xiàn)預期要求，仍可能包含有缺陷。也就是說，如果程序不按要求工作，它顯然有缺陷，但如果程序做了不要它做的事，它也有缺陷。
心理學研究告訴我們，當人們在干一件已經(jīng)知道是不合適的或不可能做到的事時，往往他們的表現(xiàn)就相當糟糕。把程序測試定義為在程序中找出錯誤的過程，就使測試成了可以做到的任務，從而克服了心理上存在的問題。雖然這看起來像是個微妙的文字游戲，但對成功地進行軟件測試有很大的影響。
總之，軟件測試更適宜被視為試圖發(fā)現(xiàn)程序中錯誤（假設(shè)其存在）的破壞性的過程。一個成功的測試，通過誘發(fā)程序發(fā)生錯誤，可以在這個方向上促進軟件質(zhì)量的改進。當然最終人們還是要通過軟件測試來建立某種程度的信心：軟件做了其應該做的，而沒有做其不應該做的。
2.程序員應避免測試自己的程序
由開發(fā)人員來測試自己的代碼是一件很不妥當?shù)氖虑椤ｉ_發(fā)和測試生來就是不同的活動。開發(fā)是創(chuàng)造或者建立某種事物的行為，如一個功能模塊或整個系統(tǒng)。而測試的重要目的是證實一個模塊或者一個系統(tǒng)工作不正常。這兩個活動之間有著本質(zhì)的矛盾。一個人不太可能把兩個截然對立的角色都扮演地很好，因此應當限制開發(fā)人員在測試中的參與，給他們比較合適的任務是進行最底層的測試——單元測試。
當一個程序員完成了設(shè)計與編寫程序的建設(shè)性工作后，要一夜之間突然改變他的觀點，設(shè)法對程序形成一個完全否定的態(tài)度，那是非常困難的。所以，大部分程序員都由于不能使自己進入必要的精神狀態(tài)（不是抱著要揭露出自己程序中錯誤的態(tài)度），就不能有效的測試自己的程序。除了這個心理學問題之外，還有一個重要的問題：程序中可能包含由于程序員對問題的敘述或說明的誤解而產(chǎn)生了錯誤。如果是這種情況，當程序員測試自己的程序時，往往還會帶著同樣的誤解致使問題難以發(fā)現(xiàn)。
3.程序設(shè)計組織不應測試自己的程序
在宏觀意義上，一個程序設(shè)計組織或一個工程項目是個有生命的有機體，它同樣有心理學問題。在大多數(shù)情況下，人們都以“在給定日期內(nèi)，以一定代價完成程序編制任務的能力”來衡量程序設(shè)計組織和項目管理人員的。這樣做的理由是時間和成本指標便于衡量，而程序的質(zhì)量很難度量。要程序設(shè)計組織在測試自己的程序時持客觀態(tài)度是很困難的，因為如果用正確的定義看待測試，就不大可能按預定計劃完成測試，也不大可能把耗費的代價限制在要求的范圍以內(nèi)。
軟件生產(chǎn)的三個最重要的因素是：質(zhì)量、進度和費用。由于費用和進度的限制，要開發(fā)一種高質(zhì)量、快速交付和低成本的軟件產(chǎn)品并不容易。也就是說要同時達到三個目標是困難的。因此在軟件產(chǎn)品的開發(fā)中要權(quán)衡它們之間的關(guān)系，是軟件的特性能滿足用戶的要求，這意味著軟件產(chǎn)品的特性的度量和預計是必要的。
軟件測試由獨立測試機構(gòu)承擔有很多好處。獨立測試是指軟件測試工作由在經(jīng)濟上和管理上獨立于開發(fā)機構(gòu)的組織進行。獨立測試可以避免軟件開發(fā)者測試自己開發(fā)的軟件，由于心理學上的問題，軟件開發(fā)者難以客觀、有效的測試自己的軟件，要找出那些因為對問題的誤解而產(chǎn)生的錯誤就更加困難。獨立測試還可以避免軟件開發(fā)機構(gòu)測試自己的軟件，軟件產(chǎn)品的開發(fā)過程受到時間、成本和質(zhì)量三者的制約，在軟件開發(fā)的過程中，當時間、成本和質(zhì)量三者發(fā)生矛盾時，質(zhì)量最容易被忽視，如果測試組織與開發(fā)組織來自相同的機構(gòu)，測試過程就會面臨來自于開發(fā)組織同一來源的管理方面的壓力，使測試過程受到干擾。
采用獨立測試方式，無論在技術(shù)上還是管理上，對提高軟件測試的有效性都具有重要意義。
客觀性——對軟件測試和軟件中的錯誤抱著客觀的態(tài)度，這種客觀的態(tài)度可以解決測試中的心理學問題，既能以揭露軟件中錯誤的態(tài)度工作，也能不受發(fā)現(xiàn)的錯誤的影響。經(jīng)濟上的獨立性使測試有更充分的條件按測試要求去完成。
專業(yè)性——獨立測試作為一種專業(yè)工作，在長期的工作過程中勢必能夠積累大量實踐經(jīng)驗，形成自己的專業(yè)知識。同時軟件測試也是技術(shù)含量很高的工作，需要有專業(yè)隊伍加以研究，并進行工程實踐。專業(yè)化分工是提高測試水平、保證測試質(zhì)量、充分發(fā)揮測試效應的必然途徑。
權(quán)威性——由于專業(yè)優(yōu)勢，獨立測試工作形成的測試結(jié)果更具信服力，而測試結(jié)果常常和對軟件的質(zhì)量評價聯(lián)系在一起，專業(yè)化的獨立測試機構(gòu)的評價，更客觀、公正和具有權(quán)威性。
資源有保證——獨立測試機構(gòu)的主要任務是進行獨立測試工作，這使得測試工作在經(jīng)費、人力和計劃方面更有保證，不會因為開發(fā)的壓力減少對測試的投入，降低測試的有效性可以避免開發(fā)單位側(cè)重軟件開發(fā)而對測試工作產(chǎn)生不利的影響。
[編輯本段]
軟件測試的內(nèi)容
軟件測試主要工作內(nèi)容是驗證(verification)和確認(validation )，下面分別給出其概念：
驗證(verification)是保證軟件正確地實現(xiàn)了一些特定功能的一系列活動，即保證軟件做了你所期望的事情。(Do the right thing)
1.確定軟件生存周期中的一個給定階段的產(chǎn)品是否達到前階段確立的需求的過程；
2.程序正確性的形式證明，即采用形式理論證明程序符合設(shè)計規(guī)約規(guī)定的過程；
3.評市、審查、測試、檢查、審計等各類活動，或?qū)δ承╉椞幚怼⒎⻊栈蛭募仁欠窈鸵?guī)定的需求相一致進行判斷和提出報告。
確認(validation)是一系列的活動和過程，目的是想證實在一個給定的外部環(huán)境中軟件的邏輯正確性。即保證軟件以正確的方式來做了這個事件(Do it right)
1.靜態(tài)確認，不在計算機上實際執(zhí)行程序，通過人工或程序分析來證明軟件的正確性；
2.動態(tài)確認，通過執(zhí)行程序做分析，測試程序的動態(tài)行為，以證實軟件是否存在問題。
軟件測試的對象不僅僅是程序測試，軟件測試應該包括整個軟件開發(fā)期間各個階段所產(chǎn)生的文檔，如需求規(guī)格說明、概要設(shè)計文檔、詳細設(shè)計文檔，當然軟件測試的主要對象還是源程序。
[編輯本段]
軟件測試的分類
從是否關(guān)心軟件內(nèi)部結(jié)構(gòu)和具體實現(xiàn)的角度劃分
A.白盒測試
B.黑盒測試
C.灰盒測試
從是否執(zhí)行程序的角度
A.靜態(tài)測試B.動態(tài)測試。
從軟件開發(fā)的過程按階段劃分有
A.單元測試B.集成測試
C.確認測試
D.系統(tǒng)測試
E.驗收測試
* 測試過程按4個步驟進行，即單元測試、集成測試、確認測試和系統(tǒng)測試及發(fā)版測試。
* 開始是單元測試，集中對用源代碼實現(xiàn)的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現(xiàn)了規(guī)定的功能。
* 集成測試把已測試過的模塊組裝起來，主要對與設(shè)計相關(guān)的軟件體系結(jié)構(gòu)的構(gòu)造進行測試。
* 確認測試則是要檢查已實現(xiàn)的軟件是否滿足了需求規(guī)格說明中確定了的各種需求，以及軟件配置是否完全、正確。
* 系統(tǒng)測試把已經(jīng)經(jīng)過確認的軟件納入實際運行環(huán)境中，與其它系統(tǒng)成份組合在一起進行測試。
單元測試 (Unit Testing)
* 單元測試又稱模塊測試，是針對軟件設(shè)計的最小單位 ─ 程序模塊，進行正確性檢驗的測試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯。
* 單元測試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例。多個模塊可以平行地獨立進行單元測試。
1. 單元測試的內(nèi)容
* 在單元測試時，測試者需要依據(jù)詳細設(shè)計說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結(jié)構(gòu)，主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應。
(1) 模塊接口測試
* 在單元測試的開始，應對通過被測模塊的數(shù)據(jù)流進行測試。測試項目包括：
– 調(diào)用本模塊的輸入?yún)?shù)是否正確；
– 本模塊調(diào)用子模塊時輸入給子模塊的參數(shù)是否正確；
– 全局量的定義在各模塊中是否一致；
* 在做內(nèi)外存交換時要考慮：
– 文件屬性是否正確；
– OPEN與CLOSE語句是否正確；
– 緩沖區(qū)容量與記錄長度是否匹配；
– 在進行讀寫操作之前是否打開了文件；
– 在結(jié)束文件處理時是否關(guān)閉了文件；
– 正文書寫／輸入錯誤，
– I／O錯誤是否檢查并做了處理。
(2) 局部數(shù)據(jù)結(jié)構(gòu)測試
* 不正確或不一致的數(shù)據(jù)類型說明
* 使用尚未賦值或尚未初始化的變量
* 錯誤的初始值或錯誤的缺省值
* 變量名拼寫錯或書寫錯
* 不一致的數(shù)據(jù)類型
* 全局數(shù)據(jù)對模塊的影響
(3) 路徑測試
* 選擇適當?shù)臏y試用例，對模塊中重要的執(zhí)行路徑進行測試。
* 應當設(shè)計測試用例查找由于錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。
* 對基本執(zhí)行路徑和循環(huán)進行測試可以發(fā)現(xiàn)大量的路徑錯誤。
(4) 錯誤處理測試
* 出錯的描述是否難以理解
* 出錯的描述是否能夠?qū)﹀e誤定位
* 顯示的錯誤與實際的錯誤是否相符
* 對錯誤條件的處理正確與否
* 在對錯誤進行處理之前，錯誤條件是否已經(jīng)引起系統(tǒng)的干預等
(5) 邊界測試
* 注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例，認真加以測試。
* 如果對模塊運行時間有要求的話，還要專門進行關(guān)鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運行時間的因素。
2. 單元測試的步驟
* 模塊并不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯(lián)系，用一些輔助模塊去模擬與被測模塊相聯(lián)系的其它模塊。
– 驅(qū)動模塊 (driver)
– 樁模塊 (stub) ── 存根模塊
* 如果一個模塊要完成多種功能，可以將這個模塊看成由幾個小程序組成。必須對其中的每個小程序先進行單元測試要做的工作，對關(guān)鍵模塊還要做性能測試。
* 對支持某些標準規(guī)程的程序，更要著手進行互聯(lián)測試。有人把這種情況特別稱為模塊測試，以區(qū)別單元測試。
集成測試（Integrated Testing）
* 集成測試 (集成測試、聯(lián)合測試）
* 通常，在單元測試的基礎(chǔ)上，需要將所有模塊按照設(shè)計要求組裝成為系統(tǒng)。這時需要考慮的問題是：
– 在把各個模塊連接起來的時候，穿越模塊接口的數(shù)據(jù)是否會丟失；
– 一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響；
– 各個子功能組合起來，能否達到預期要求的父功能；
– 全局數(shù)據(jù)結(jié)構(gòu)是否有問題；
– 單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。
在單元測試的同時可進行集成測試，
發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)
的問題，最終構(gòu)成要求的軟件系統(tǒng)。
* 子系統(tǒng)的集成測試特別稱為部件測試，它所做的工作是要找出集成后的子系統(tǒng)與系統(tǒng)需求規(guī)格說明之間的不一致。
* 通常，把模塊集成成為系統(tǒng)的方式有兩種
– 一次性集成方式
– 增殖式集成方式
1. 一次性集成方式(big bang)
* 它是一種非增殖式組裝方式。也叫做整體拼裝。
* 使用這種方式，首先對每個模塊分別進行模塊測試，然后再把所有模塊組裝在一起進行測試，最終得到要求的軟件系統(tǒng)。
2. 增殖式集成方式
* 這種集成方式又稱漸增式集成
* 首先對一個個模塊進行模塊測試，然后將這些模塊逐步組裝成較大的系統(tǒng)
* 在集成的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題
* 通過增殖逐步組裝成為要求的軟件系統(tǒng)。
(1) 自頂向下的增殖方式
* 這種集成方式將模塊按系統(tǒng)程序結(jié)構(gòu)，沿控制層次自頂向下進行組裝。
* 自頂向下的增殖方式在測試過程中較早地驗證了主要的控制和判斷點。
* 選用按深度方向組裝的方式，可以首先實現(xiàn)和驗證一個完整的軟件功能。
(2) 自底向上的增殖方式
* 這種集成的方式是從程序模塊結(jié)構(gòu)的最底層的模塊開始集成和測試。
* 因為模塊是自底向上進行組裝，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)組裝并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。
* 自頂向下增殖的方式和自底向上增殖的方式各有優(yōu)缺點。
* 一般來講，一種方式的優(yōu)點是另一種方式的缺點。
(3) 混合增殖式測試
* 衍變的自頂向下的增殖測試
– 首先對輸入／輸出模塊和引入新算法模塊進行測試;
– 再自底向上組裝成為功能相當完整且相對獨立的子系統(tǒng);
– 然后由主模塊開始自頂向下進行增殖測試。
* 自底向上-自頂向下的增殖測試
– 首先對含讀操作的子系統(tǒng)自底向上直至根結(jié)點模塊進行組裝和測試;
– 然后對含寫操作的子系統(tǒng)做自頂向下的組裝與測試。
* 回歸測試
– 這種方式采取自頂向下的方式測試被修改的模塊及其子模塊;
– 然后將這一部分視為子系統(tǒng)，再自底向上測試。
關(guān)鍵模塊問題
* 在組裝測試時，應當確定關(guān)鍵模塊，對這些關(guān)鍵模塊及早進行測試。
* 關(guān)鍵模塊的特征：
�、� 滿足某些軟件需求；
�、� 在程序的模塊結(jié)構(gòu)中位于較高的層次（高層控制模塊）；
③ 較復雜、較易發(fā)生錯誤；
④ 有明確定義的性能要求。
確認測試（Validation Testing）
* 確認測試又稱有效性測試。任務是驗證軟件的功能和性能及其它特性是否與用戶的要求一致。
* 對軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定。它包含的信息就是軟件確認測試的基礎(chǔ)。
1. 進行有效性測試（黑盒測試）
* 有效性測試是在模擬的環(huán)境 (可能就是開發(fā)的環(huán)境) 下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規(guī)格說明書列出的需求。
* 首先制定測試計劃，規(guī)定要做測試的種類。還需要制定一組測試步驟，描述具體的測試用例。
* 通過實施預定的測試計劃和測試步驟，確定
– 軟件的特性是否與需求相符；
– 所有的文檔都是正確且便于使用；
– 同時，對其它軟件需求，例如可移植性、兼容性、出錯自動恢復、可維護性等，也都要進行測試
* 在全部軟件測試的測試用例運行完后，所有的測試結(jié)果可以分為兩類：
– 測試結(jié)果與預期的結(jié)果相符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合，從而這部分程序被接受。
– 測試結(jié)果與預期的結(jié)果不符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致，因此要為它提交一份問題報告。
2. 軟件配置復查
n 軟件配置復查的目的是保證
u 軟件配置的所有成分都齊全；
u 各方面的質(zhì)量都符合要求；
u 具有維護階段所必需的細節(jié)；
u 而且已經(jīng)編排好分類的目錄。
n 應當嚴格遵守用戶手冊和操作手冊中規(guī)定的使用步驟，以便檢查這些文檔資料的完整性和正確性。
驗收測試（Acceptance Testing）
* 在通過了系統(tǒng)的有效性測試及軟件配置審查之后，就應開始系統(tǒng)的驗收測試。
* 驗收測試是以用戶為主的測試。軟件開發(fā)人員和QA（質(zhì)量保證）人員也應參加。
* 由用戶參加設(shè)計測試用例，使用生產(chǎn)中的實際數(shù)據(jù)進行測試。
* 在測試過程中，除了考慮軟件的功能和性能外，還應對軟件的可移植性、兼容性、可維護性、錯誤的恢復功能等進行確認。
* 確認測試應交付的文檔有：
– 確認測試分析報告
– 最終的用戶手冊和操作手冊
– 項目開發(fā)總結(jié)報告。
系統(tǒng)測試（System Testing）
* 系統(tǒng)測試，是將通過確認測試的軟件，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合在一起，在實際運行環(huán)境下，對計算機系統(tǒng)進行一系列的組裝測試和確認測試。
* 系統(tǒng)測試的目的在于通過與系統(tǒng)的需求定義作比較, 發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。
[編輯本段]
軟件測試模型
軟件測試若使用經(jīng)典的V模型階段可以分為
單元測試集成測試
系統(tǒng)測試
V模型是最具有代表意義的測試模型 。
V模型是軟件開發(fā)瀑布模型的變種，它反映了測試活動與分析和設(shè)計的關(guān)系 。從左到右，描述了基本的開發(fā)過程和測試行為，非常明確地標明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發(fā)過程期間各階段的對應關(guān)系 。
左邊依次下降的是開發(fā)過程各階段，與此相對應的是右邊依次上升的部分，即各測試過程的各個階段。
用戶需求 驗收測試
需求分析和系統(tǒng)設(shè)計 確認測試和系統(tǒng)測試
概要設(shè)計 集成測試
詳細設(shè)計 單元測試
編碼
V模型問題：
1.測試是開發(fā)之后的一個階段。
2.測試的對象就是程序本身。
3.實際應用中容易導致需求階段的錯誤一直到最后系統(tǒng)測試階段才被發(fā)現(xiàn)。
4.整個軟件產(chǎn)品的過程質(zhì)量保證完全依賴于開發(fā)人員的能力和對工作的責任心，而且上一步的結(jié)果必須是充分和正確的，如果任何一個環(huán)節(jié)出了問題，則必將嚴重的影響整個工程的質(zhì)量和預期進度
W模型
W模型由Evolutif公司公司提出，相對于V模型，W模型增加了軟件各開發(fā)階段中應同步進行的驗證和確認活動。W模型由兩個V字型模型組成，分別代表測試與開發(fā)過程，圖中明確表示出了測試與開發(fā)的并行關(guān)系。 W模型強調(diào)：測試伴隨著整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、設(shè)計等同樣要測試，也就是說，測試與開發(fā)是同步進行的。W模型有利于盡早地全面的發(fā)現(xiàn)問題。例如，需求分析完成后，測試人員就應該參與到對需求的驗證和確認活動中，以盡早地找出缺陷所在。同時，對需求的測試也有利于及時了解項目難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快項目進度。 但W模型也存在局限性。在W模型中，需求、設(shè)計、編碼等活動被視為串行的，同時，測試和開發(fā)活動也保持著一種線性的前后關(guān)系，上一階段完全結(jié)束，才可正式開始下一個階段工作。這樣就無法支持迭代的開發(fā)模型。對于當前軟件開發(fā)復雜多變的情況，W模型并不能解除測試管理面臨著困惑。H模型
H模型中, 軟件測試過程活動完全獨立,貫穿于整個產(chǎn)品的周期,與其他流程并發(fā)地進行,某個測試點準備就緒時,就可以從測試準備階段進行到測試執(zhí)行階段。軟件測試可以盡早的進行,并且可以根據(jù)被測物的不同而分層次進行。這個示意圖演示了在整個生產(chǎn)周期中某個層次上的一次測試“微循環(huán)”。圖中標注的其它流程可以是任意的開發(fā)流程,例如設(shè)計流程或者編碼流程。也就是說, 只要測試條件成熟了,測試準備活動完成了,測試執(zhí)行活動就可以進行了。
H模型揭示了一個原理:軟件測試是一個獨立的流程,貫穿產(chǎn)品整個生命周期,與其他流程并發(fā)地進行。H模型指出軟件測試要盡早準備, 盡早執(zhí)行。不同的測試活動可以是按照某個次序先后進行的,但也可能是反復的,只要某個測試達到準備就緒點,測試執(zhí)行活動就可以開展。
X模型
X模型也是對V模型的改進,X模型提出針對單獨的程序片段進行相互分離的編碼和測試,此后通過頻繁的交接,通過集成最終合成為可執(zhí)行的程序。X模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此后將進行頻繁的交接，通過集成最終成為可執(zhí)行的程序，然后再對這些可執(zhí)行程序進行測試。己通過集成測試的成品可以進行封裝并提交給用戶，也可以作為更大規(guī)模和范圍內(nèi)集成的一部分。多根并行的曲線表示變更可以在各個部分發(fā)生。由圖中可見，X模型還定位了探索性測試，這是不進行事先計劃的特殊類型的測試，這一方式往往能幫助有經(jīng)驗的測試人員在測試計劃之外發(fā)現(xiàn)更多的軟件錯誤。但這樣可能對測試造成人力、物力和財力的浪費，對測試員的熟練程度要求比較高。前置模型
軟件測試職業(yè)發(fā)展前景軟件測試工程師成長之路：http://www.sz-btesting.com
隨著我國軟件業(yè)的發(fā)展，專業(yè)的軟件測試人員成為了眾多知名公司追逐的對象，軟件測試有著廣闊的發(fā)展前景，具體可以分為：
• 初級測試工程師：初級職位，開發(fā)測試腳本，執(zhí)行測試
•測試工程師 / 程序分析員：編寫自動測試腳本程序
•高級測試工程師 / 程序分析員：確定測試過程并指導初級測試工程師
•測試組負責人：監(jiān)管 1-3 人工作，負責規(guī)模 / 成本估算
•測試 / 編程負責人：監(jiān)管 4-8 人，安排和領(lǐng)導任務完成，提出技術(shù)方法
•測試 / 質(zhì)量保證 / 項目經(jīng)理：負責 8 名以上人員的一個或多個項目，負責全生存期
•業(yè)務 / 產(chǎn)品經(jīng)理：負責多個項目的人員管理，負責項目方向和業(yè)務盈虧
[編輯本段]
技術(shù)之路：
• 軟件測試工程師
定義
軟件測試工程師簡單的說是軟件開發(fā)過程中的質(zhì)量檢測者和保障者，負責軟件質(zhì)量的把關(guān)工作。軟件測試工程師（Software Testing Engineer）的主要工作職責是，理解產(chǎn)品的功能要求，并對其進行測試，檢查軟件有沒有錯誤（Bug），決定軟件是否具有穩(wěn)定性（Robustness），寫出相應的測試規(guī)范和測試用例。簡而言之，軟件測試工程師在一家軟件企業(yè)中擔當?shù)氖恰百|(zhì)量管理”角色，及時糾錯及時更正，確保產(chǎn)品的正常運作。[1]
工作內(nèi)容
1、編寫軟件測試計劃，設(shè)計軟件測試腳本和用例，搭建軟件測試環(huán)境；
2、執(zhí)行軟件項目測試，包括功能測試、性能測試、易用性測試等；
3、整理、分析、報告并追蹤軟件缺陷，并確認軟件測試問題得以解決；
4、撰寫軟件測試結(jié)果分析報告，預先評估項目的風險，編寫其它相關(guān)文檔；
5、結(jié)合研發(fā)軟件產(chǎn)品項目情況，制定相應的軟件、項目版本控制制度。
• 至少是一名軟件開發(fā)工程師
• 軟件測試技術(shù)主管
• 軟件測試設(shè)計師
[編輯本段]
管理之路：
• 測試主管
• 測試管理者
• 項目主管
• 產(chǎn)品發(fā)布主管
[編輯本段]
軟件測試網(wǎng)站推薦
51testing軟件測試論壇：http://www.51testing.com
介紹：軟件測試網(wǎng)包括軟件測試論壇、軟件測試博客和文章資料精選三大模塊，提供學習、交流、教材下載以及求職、招聘信息的發(fā)布、檢索等服務。
中國軟件測試：http://softtest.chinaitlab.com/
介紹：中國軟件測試網(wǎng)是中國IT實驗室核心技術(shù)頻道，致力于打造國內(nèi)最大最全的軟件測試技術(shù)文獻平臺。
北大青鳥軟件測試網(wǎng)站：http://www.sz-btesting.com
介紹：北大青鳥軟件測試網(wǎng)站提供豐富軟件測試技術(shù)資料，開設(shè)軟件測試人才招聘專區(qū)，開展軟件測試主題講座，軟件測試在線咨詢，軟件測試工程師專題，測試資料下載等信息服務。
技術(shù)文獻目錄：
手機測試：http://softtest.chinaitlab.com/sji/Index.html
[編輯本段]
測試工具介紹
AutoRunner 是國內(nèi)第一款自動化測試工具，可以用來完成功能測試、回歸測試、每日構(gòu)建測試與自動回歸測試等工作。是具有腳本語言的、提供針對腳本完善的跟蹤和調(diào)試功能的、支持IE測試和Windows native測試的自動化測試工具。
TestCenter 是一款功能強大測試管理工具，它可以幫助您：實現(xiàn)測試用例的過程管理，對測試需求過程、測試用例設(shè)計過程、業(yè)務組件設(shè)計實現(xiàn)過程等整個測試過程進行管理。實現(xiàn)測試用例的標準化即每個測試人員都能夠理解并使用標準化后的測試用例，降低了測試用例對個人的依賴；提供測試用例復用，用例和腳本能夠被復用，以保護測試人員的資產(chǎn)；提供可伸縮的測試執(zhí)行框架，提供自動測試支持；提供測試數(shù)據(jù)管理，幫助用戶同意管理測試數(shù)據(jù)，降低測試數(shù)據(jù)和測試腳本之間的耦合度。
TAR(Terminal AutoRunner)適用于VT100、VT220等標準的應用系統(tǒng)，支持命令行模式和窗口模式（使用Cursors編寫的應用程序）,支持自動錄制腳本、所見即所得的資源和腳本編輯，穩(wěn)定的自動同步功能。是目前國內(nèi)最好的銀行業(yè)務測試工具.
LoadRunner 是一種預測系統(tǒng)行為和性能的工業(yè)標準級負載測試工具。通過以模擬上千萬用戶實施并發(fā)負載及實時性能監(jiān)測的方式來確認和查找問題，LoadRunner 能夠?qū)φ麄�企業(yè)架構(gòu)進行測試。通過使用LoadRunner ， 企業(yè)能最大限度地縮短測試時間， 優(yōu)化性能和加速應用系統(tǒng)的發(fā)布周期。目前企業(yè)的網(wǎng)絡應用環(huán)境都必須支持大量用戶，網(wǎng)絡體系架構(gòu)中含各類應用環(huán)境且由不同供應商提供軟件和硬件產(chǎn)品。難以預知的用戶負載和愈來愈復雜的應用環(huán)境使公司時時擔心會發(fā)生用戶響應速度過慢， 系統(tǒng)崩潰等問題。這些都不可避免地導致公司收益的損失。
TestDirector 是全球最大的軟件測試工具提供商Mercury Interactive公司生產(chǎn)的企業(yè)級測試管理工具，也是業(yè)界第一個基于Web的測試管理系統(tǒng),它可以在您公司內(nèi)部或外部進行全球范圍內(nèi)測試的管理。通過在一個整體的應用系統(tǒng)中集成了測試管理的各個部分，包括需求管理，測試計劃，測試執(zhí)行以及錯誤跟蹤等功能，TestDirector極大地加速了測試過程。
[編輯本段]
測試用例編寫規(guī)范
1 目的：統(tǒng)一測試用例編寫的規(guī)范，以保證使用最有效的測試用例，保證測試質(zhì)量。
2 范圍：適用于公司對產(chǎn)品的業(yè)務流程、功能測試測試用例的編寫。
3 術(shù)語解釋
3.1 測試分析：對重要業(yè)務、重要流程進行測試前的分析。
3.2 業(yè)務流程測試用例：關(guān)于產(chǎn)品業(yè)務、重要流程的測試用例。
4 業(yè)務流程測試用例編寫原則
4.1 系統(tǒng)性
4.1.1 對于系統(tǒng)業(yè)務流程要能夠完整說明整個系統(tǒng)的業(yè)務需求、系統(tǒng)由幾個子系統(tǒng)組成以及它們之間的關(guān)系；
4.1.2 對于模塊業(yè)務流程要能夠說明清楚子系統(tǒng)內(nèi)部功能、重要功能點以及它們之間的關(guān)系；
4.2 連貫性
4.2.1 對于系統(tǒng)業(yè)務流程來說，各個子系統(tǒng)之間是如何連接在一起，如果需要接口，各個子系統(tǒng)之間是否有正確的接口；如果是依靠頁面鏈接，頁面鏈接是否正確；
4.2.2 對于模塊業(yè)務流程來說，同級模塊以及上下級模塊是如何構(gòu)成一個子系統(tǒng)，其內(nèi)部功能接口是否連貫；
5 測試用例設(shè)計的方法
5.1 等價類劃分法
5.1.1 確定等價類的原則
5.1.1.1 如果輸入條件決定了取值范圍，或值的個數(shù)，則可以確立一個有效等價類和兩個無效等價類。
5.1.1.2 如果輸入條件規(guī)定了輸入值的集合，或者規(guī)定了“必須如何”的條件，此時可確立一個有效等價類和一個無效等價類；
5.1.1.3 如果輸入條件是一個布爾量，則可以確定一個有效等價類和一個無效等價類；
5.1.1.4 如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序?qū)γ總�輸入值分別進行處理，此時可為每一個輸入值確立一個有效等價類，此外，針對這組值確立一個無效等價類，它是所有不允許輸入值的集合；
5.1.1.5 如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則，則可以確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同的角度違反規(guī)則）。
5.1.1.6 如果確知，已劃分的等價類中各元素在程序中的處理方式不同，則應將此等價類進一步劃分成更小的等價類。
5.1.2 測試用例的選擇原則
5.1.2.1 為每一個等價類規(guī)定一個唯一的編號；
5.1.2.2 設(shè)計一個新的測試用例，使其盡可能多的覆蓋尚未被覆蓋的有效等價類，重復這一步，直至所有的有效等價類都被覆蓋過；
5.1.2.3 設(shè)計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直至所有的無效等價類都被覆蓋為止。
5.2 邊界值分析法
5.2.1 測試用例的選擇原則
5.2.1.1 如果輸入了條件規(guī)定了值的范圍，則應取剛達到這個范圍的邊界值，以及剛剛超越這個邊界范圍的值作為測試輸入數(shù)據(jù)；
5.2.1.2 如果輸入條件規(guī)定了值的個數(shù)，則用最大個數(shù)、最小個數(shù)、比最大多1、比最小小1的數(shù)作為測試輸入數(shù)據(jù)；
5.2.1.3 根據(jù)規(guī)格說明的每個輸出條件，使用前面的原則；
5.2.1.4 如果程序的規(guī)格說明給出的輸入輸出域是有序集合，則應選取集合的每一個元素和最后一個元素作為測試用列；
5.2.1.5 如果程序中使用了一個內(nèi)部數(shù)據(jù)結(jié)構(gòu)，則應當選擇這個內(nèi)部數(shù)據(jù)結(jié)構(gòu)的邊界上的值作為測試用例；
5.2.1.6 分析規(guī)格說明，找出其他可能的邊界條件。
6 測試用例設(shè)計的原則
6.1 全面性
6.1.1 應盡可能覆蓋程序的各種路徑
6.1.2 應考慮存在跨年、跨月的數(shù)據(jù)
6.1.3 大量數(shù)據(jù)并發(fā)測試的準備
6.2 正確性
6.2.1 輸入界面后的數(shù)據(jù)應與測試文檔所記錄的數(shù)據(jù)一致
6.2.2 預期結(jié)果應與測試數(shù)據(jù)發(fā)生的業(yè)務吻合
6.3 符合正常業(yè)務慣例
6.3.1 測試數(shù)據(jù)應符合用戶實際工作業(yè)務流程
6.3.2 兼顧各種業(yè)務變化的可能
6.4 仿真性
人名、地名、電話號碼等應具有模擬功能，符合一般的命名慣例；不允許出現(xiàn)與知名人士、小說中人物名等雷同情況。
6.5 可操作性
測試用例中應寫清測試的操作步驟，不同的操作步驟相對應的操作結(jié)果。
7 測試用例編寫格式細則
7.1 測試用例內(nèi)容
7.1.1 具體實施可以采用EXCEL和圖形相結(jié)合，可用EXCEL編寫測試用例的同時插入圖形來加以說明。測試用例設(shè)計的內(nèi)容可由：模塊名、功能說明或圖形說明、測試用例輸入、應輸出結(jié)果、實際輸出結(jié)果、結(jié)論、BUG編號、BUG級別8部分組成。
7.1.2 在測試用例設(shè)計模版中有“業(yè)務流程測試用例設(shè)計模版”（包含整體業(yè)務流程）和“功能測試用例設(shè)計模版”兩個模板可按需要選擇。
7.2 測試用例表格格式
7.2.1 表格內(nèi)容的字體為宋體；
7.2.2 表格內(nèi)容的字型為12號；
8 測試用例優(yōu)先級
測試用例優(yōu)先級 描述
A 測試計劃中重要的模塊功能和業(yè)務流程
B 測試計劃中比較重要的模塊功能和業(yè)務流程
C 測試計劃中次重要的模塊功能和業(yè)務流程
D 測試計劃中不重要的模塊功能和業(yè)務流程
E 系統(tǒng)小單元、系統(tǒng)容錯功能
對于A、B 級應重點考慮
9 BUG級別
參考軟件測試停止標準中的錯誤級別.
[編輯本段]
外包軟件測試
外包軟件測試就是指軟件企業(yè)將軟件項目中的全部或部分測試工作，交給提供軟件外包測試服務的公司，由他們?yōu)檐浖M行專門的測試。這樣做的好處有兩個：一方面軟件企業(yè)可以更好地專注核心競爭力業(yè)務，同時降低軟件項目成本；另一方面，由第三方專業(yè)的測試公司進行測試，無論在技術(shù)上還是管理上，對提高軟件測試的有效性都具有重要意義。
外包軟件測試行業(yè)前景非常看好，發(fā)展空間很大。IDG的數(shù)據(jù)顯示，最近幾年，中國的軟件外包產(chǎn)業(yè)年均增長率為36.5%，正處于快速發(fā)展的階段，2008年預計已達到16.9億美元的市場規(guī)模。目前韓日、歐美國家的軟件企業(yè)紛紛關(guān)注中國市場，而作為軟件外包強國的印度，在其國內(nèi)處于前幾位的軟件外包服務商也準備來“分一杯羹”。從目前市場來看，選擇將部分軟件測試工作進行外包的公司主要是微軟、IBM等國際軟件旗艦企業(yè)，他們利用第三方專業(yè)軟件測試公司，在產(chǎn)品發(fā)布前對軟件進行一系列的集成測試和系統(tǒng)測試，既保證了測試工作的全面性，又節(jié)省了人力、物力的開銷。最重要的是，測試結(jié)果往往好于這些軟件企業(yè)最初的預期，效果非常令人滿意。軟件企業(yè)和提供軟件外包測試服務的公司進行合作，只要達成雙贏，兩方皆大歡喜，這樣的合作就會越來越多，項目也會越做越大。
主要業(yè)務類型
·本地化軟件測試
·國際化軟件測試
主要測試的范圍
·本地化語言質(zhì)量測試
·國際化軟件的功能和性能測試
測試工作主要方式
·公司內(nèi)部（In house）執(zhí)行的測試
·派駐客戶開發(fā)中心的現(xiàn)場測試（On site）。
[編輯本段]
軟件測試的發(fā)展現(xiàn)狀與前景
一、 軟件開發(fā)中出現(xiàn)錯誤或缺陷的機會越來越多。
市場對軟件質(zhì)量重要性的認識逐漸增強。所以，軟件測試在軟件項目實施過程中的重要性日益突出。但是，現(xiàn)實情況是，與軟件編程比較，軟件測試的地位和作用，還沒有真正受到重視，對于很多人（甚至是軟件項目組的技術(shù)人員）還存在對軟件測試的認識誤區(qū)，這進一步影響了軟件測試活動開展和真正提高軟件測試質(zhì)量。
�。�1）誤區(qū)之一：軟件開發(fā)完成后進行軟件測試
人們一般認為，軟件項目要經(jīng)過以下幾個階段：需求分析，概要設(shè)計，詳細設(shè)計，軟件編碼，軟件測試，軟件發(fā)布。據(jù)此，認為軟件測試只是軟件編碼后的一個過程。這是不了解軟件測試周期的錯誤認識。軟件測試是一個系列過程活動，包括軟件測試需求分析，測試計劃設(shè)計，測試用例設(shè)計，執(zhí)行測試。因此，軟件測試貫穿于軟件項目的整個生命過程。在軟件項目的每一個階段都要進行不同目的和內(nèi)容的測試活動，以保證各個階段的正確性。軟件測試的對象不僅僅是軟件代碼，還包括軟件需求文檔和設(shè)計文檔。軟件開發(fā)與軟件測試應該是交互進行的，例如，單元編碼需要單元測試，模塊組合階段需要集成測試。如果等到軟件編碼結(jié)束后才進行測試，那么，測試的時間將會很短，測試的覆蓋面將很不全面，測試的效果也將大打折扣。更嚴重的是如果此時發(fā)現(xiàn)了軟件需求階段或概要設(shè)計階段的錯誤，如果要修復該類錯誤，將會耗費大量的時間和人力。
�。�2）誤區(qū)之二：軟件發(fā)布后如果發(fā)現(xiàn)質(zhì)量問題，那是軟件測試人員的錯
這種認識很打擊軟件測試人員的積極性。軟件中的錯誤可能來自軟件項目中的各個過程，軟件測試只能確認軟件存在錯誤，不能保證軟件沒有錯誤，因為從根本上講，軟件測試不可能發(fā)現(xiàn)全部的錯誤。從軟件開發(fā)的角度看，軟件的高質(zhì)量不是軟件測試人員測出來的，是靠軟件生命周期的各個過程中設(shè)計出來的。出現(xiàn)軟件錯誤，不能簡單地歸結(jié)為某一個人的責任，有些錯誤的產(chǎn)生可能不是技術(shù)原因，可能來自于混亂的項目管理。應該分析軟件項目的各個過程，從過程改進方面尋找產(chǎn)生錯誤的原因和改進的措施。
�。�3）誤區(qū)之三：軟件測試要求不高，隨便找個人多都行
很多人都認為軟件測試就是安裝和運行程序，點點鼠標，按按鍵盤的工作。這是由于不了解軟件測試的具體技術(shù)和方法造成的。隨之軟件工程學的發(fā)展和軟件項目管理經(jīng)驗的提高，軟件測試已經(jīng)形成了一個獨立的技術(shù)學科，演變成一個具有巨大市場需求的行業(yè)。軟件測試技術(shù)不斷更新和完善，新工具，新流程，新測試設(shè)計方法都在不斷更新，需要掌握和學習很多測試知識。所以，具有編程經(jīng)驗的程序員不一定是一名優(yōu)秀的測試工程師。軟件測試包括測試技術(shù)和管理兩個方面，完全掌握這兩個方面的內(nèi)容，需要很多測試實踐經(jīng)驗和不斷學習精神。
�。�4）誤區(qū)之四：軟件測試是測試人員的事情，與程序員無關(guān)開發(fā)和測試是相輔相成的過程
需要軟件測試人員、程序員和系統(tǒng)分析師等保持密切的聯(lián)系，需要更多的交流和協(xié)調(diào)，以便提高測試效率。另外，對于單元測試主要應該由程序員完成，必要時測試人員可以幫助設(shè)計測試樣例。對于測試中發(fā)現(xiàn)的軟件錯誤，很多需要程序員通過修改編碼才能修復。程序員可以通過有目的的分析軟件錯誤的類型、數(shù)量，找出產(chǎn)生錯誤的位置和原因，以便在今后的編程中避免同樣的錯誤，積累編程經(jīng)驗，提高編程能力。
（5）誤區(qū)之五：項目進度吃緊時少做些測試，時間富裕時多做測試
這是不重視軟件測試的表現(xiàn)，也是軟件項目過程管理混亂的表現(xiàn)，必然會降低軟件測試的質(zhì)量。一個軟件項目的順利實現(xiàn)需要有合理的項目進度計劃，其中包括合理的測試計劃，對項目實施過程中的任何問題，都要有風險分析和相應的對策，不要因為開發(fā)進度的延期而簡單的縮短測試時間、人力和資源。因為縮短測試時間帶來的測試不完整，對項目質(zhì)量的下降引起的潛在風險，往往造成更大的浪費�？朔@種現(xiàn)象的最好辦法是加強軟件過程的計劃和控制，包括軟件測試計劃、測試設(shè)計、測試執(zhí)行、測試度量和測試控制。
�。�6）誤區(qū)之六：軟件測試是沒有前途的工作，只有程序員才是軟件高手
由于我國軟件整體開發(fā)能力比較低，軟件過程很不規(guī)范，很多軟件項目的開發(fā)都還停留在“作坊式”和“壘雞窩”階段。項目的成功往往靠個別全能程序員決定，他們負責總體設(shè)計和程序詳細設(shè)計，認為軟件開發(fā)就是編寫代碼，給人的印象往往是程序員是真正的牛人，具有很高的地位和待遇。因此，在這種環(huán)境下，軟件測試很不受重視，軟件測試人員的地位和待遇自然就很低了，甚至軟件測試變得可有可無。隨著市場對軟件質(zhì)量的不斷提高，軟件測試將變得越來越重要，相應的軟件測試人員的地位和待遇將會逐漸提高。在微軟等軟件過程比較規(guī)范的大公司，軟件測試人員的數(shù)量和待遇與程序員沒有多大差別，優(yōu)秀測試人員的待遇甚至比程序員還要高。軟件測試將會成為一個具有很大發(fā)展前景的行業(yè)，軟件測試大有前途，市場需要更多具有豐富測試技術(shù)和管理經(jīng)驗的測試人員，他們同樣是軟件專家。這兩年來國內(nèi)軟件測試人員的需求不斷增大,越來越多的IT企業(yè)認識到了軟件測試的重要性,這種可喜的現(xiàn)狀與發(fā)展趨勢讓筆者對我國軟件業(yè)的發(fā)展重新抱有較大的希望。
盡管這是一門嶄新的學科,目前在國內(nèi)的發(fā)展仍處于"嬰兒"階段,但看到越來越多的軟件公司為軟件測試招兵買馬,看到越來越多的技術(shù)人員投入到軟件測試中,我就情不自禁地感嘆:機會來了!這機會不僅僅是某一個人的,而是所有人的,它對每個人都是公平的,學的領(lǐng)域需要新的理論新的工具新的方法,由于國內(nèi)的軟件測試還處在一個比較初級的階段，沒有人確切地知道它需要什么樣的基礎(chǔ),也沒有人確切地知道它應該怎樣發(fā)展,因此這個領(lǐng)域需要大家來共同革命,以促進它的深入發(fā)展。
二、軟件測試的前景
隨著軟件產(chǎn)業(yè)的發(fā)展，軟件產(chǎn)品的質(zhì)量控制與質(zhì)量管理正逐漸成為軟件企業(yè)生存與發(fā)展的核心。幾乎每個大中型IT企業(yè)的軟件產(chǎn)品在發(fā)布前都需要大量的質(zhì)量控制、測試和文檔工作，而這些工作必須依靠擁有嫻熟技術(shù)的專業(yè)軟件人才來完成。軟件測試工程師就是這樣的一個企業(yè)重頭角色。業(yè)內(nèi)人士分析，該類職位的需求主要集中在沿海發(fā)達城市，其中北京和上海的需求量分別占去33%和29%。民企需求量最大，占19%，外商獨資歐美類企業(yè)需求排列第二，占15%。然而，目前的現(xiàn)狀是：一方面企業(yè)對高質(zhì)量的測試工程師需求量越來越大越大，另一方面國內(nèi)原來對測試工程師的職業(yè)重視程度不夠，使許多人不了解測試工程師具體是從事什么工作。這使得許多IT公司只能通過在實際工作中進行淘汰的方式對測試工程師進行篩選，因此國內(nèi)在短期將出現(xiàn)測試工程師嚴重短缺的現(xiàn)象。根據(jù)對近期網(wǎng)絡招聘IT人才情況的了解，許多正在招聘軟件測試工程師的企業(yè)
很少能夠在招聘會上順利招到合適的人才。在具體工作過程中，測試工程師的工作是利用測試工具按照測試方案和流程對產(chǎn)品進行功能和性能測試，甚至根據(jù)需要編寫不同的測試用例，設(shè)計和維護測試系統(tǒng)，對測試方案可能出現(xiàn)的問題進行分析和評估。對軟件測試工程師而言，必須具有高度的工作責任心和自信心。任何嚴格的測試必須是一種實事求是的測試，因為它關(guān)系到一個產(chǎn)品的質(zhì)量問題，而測試工程師則是產(chǎn)品出貨前的把關(guān)人，所以，沒有專業(yè)的技術(shù)水準是無法勝任這項工作的。同時，由于測試工作一般由多個測試工程師共同完成，并且測試部門一般要與其他部門的人員進行較多的溝通，所以要求測試工程師不但要有較強的技術(shù)能力而且要有較強的溝通能力。
回答者：
mao_mao
回答時間：2010-07-06 21:17
13
14
嘩塞，樓上說得一大堆，不錯，不知LZ想要的有沒有。。。
回答者：
michell11
回答時間：2010-07-06 22:01
18
11
樓上說的不知道是不是樓主所要的資料，樓主能否說的詳細點？
回答者：
chnmyying
回答時間：2010-07-11 21:36
14
11
• 西安長河通訊有限責任公司
聘：網(wǎng)絡優(yōu)化工程師
需求人數(shù)：4 人 地點：渭南市,商洛市,漢中市,安康市
• 浙江明訊網(wǎng)絡技術(shù)有限公司 聘：網(wǎng)優(yōu)工程師（湖南）
需求人數(shù)：0 人 地點：長沙市,湘潭市,邵陽市
• 嘉環(huán)科技股份有限公司 聘：湖南電信原廠優(yōu)化招聘
需求人數(shù)：10 人 地點：長沙市,永州市,郴州市,衡陽市
• 陜西瑞達灃通信技術(shù)有限公司 聘：華為光網(wǎng)絡工程師
需求人數(shù)：8 人 地點：新疆
• 南京欣網(wǎng)通信科技股份有限公司 聘：項目經(jīng)理（昆明）
需求人數(shù)：1 人 地點：昆明市
• 浙江省郵電工程建設(shè)有限公司 聘：寧夏中興5G網(wǎng)優(yōu)中高級工程師
需求人數(shù)：10 人 地點：寧夏
• 北京宜通華瑞科技有限公司 聘：專項優(yōu)化中高級（江西急聘）
需求人數(shù)：5 人 地點：上饒市,景德鎮(zhèn)市,南昌市,鷹潭市
• 南京華蘇科技有限公司 聘：中興數(shù)通工程師
需求人數(shù)：3 人 地點：濟寧市,濟南市
• 河北中創(chuàng)盈和通信科技有限公司 聘：中級前臺/寧夏中衛(wèi)
需求人數(shù)：2 人 地點：寧夏
• 重慶信科通信工程有限公司 聘：江西電信原廠高級后臺
需求人數(shù)：2 人 地點：九江市
需求人數(shù)：4 人 地點：渭南市,商洛市,漢中市,安康市
• 浙江明訊網(wǎng)絡技術(shù)有限公司 聘：網(wǎng)優(yōu)工程師（湖南）
需求人數(shù)：0 人 地點：長沙市,湘潭市,邵陽市
• 嘉環(huán)科技股份有限公司 聘：湖南電信原廠優(yōu)化招聘
需求人數(shù)：10 人 地點：長沙市,永州市,郴州市,衡陽市
• 陜西瑞達灃通信技術(shù)有限公司 聘：華為光網(wǎng)絡工程師
需求人數(shù)：8 人 地點：新疆
• 南京欣網(wǎng)通信科技股份有限公司 聘：項目經(jīng)理（昆明）
需求人數(shù)：1 人 地點：昆明市
• 浙江省郵電工程建設(shè)有限公司 聘：寧夏中興5G網(wǎng)優(yōu)中高級工程師
需求人數(shù)：10 人 地點：寧夏
• 北京宜通華瑞科技有限公司 聘：專項優(yōu)化中高級（江西急聘）
需求人數(shù)：5 人 地點：上饒市,景德鎮(zhèn)市,南昌市,鷹潭市
• 南京華蘇科技有限公司 聘：中興數(shù)通工程師
需求人數(shù)：3 人 地點：濟寧市,濟南市
• 河北中創(chuàng)盈和通信科技有限公司 聘：中級前臺/寧夏中衛(wèi)
需求人數(shù)：2 人 地點：寧夏
• 重慶信科通信工程有限公司 聘：江西電信原廠高級后臺
需求人數(shù)：2 人 地點：九江市
熱點問題
更多精彩
| 聯(lián)系我們 - 問通信專家 | Powered by MSCBSC 移動通信網(wǎng) © 2006 - |