如何測試軟體

A. 如何進行軟體功能測試

我是做軟體測試工作的，仁者見仁智者見智，水平有限，就你提出的問題作一個簡單的回答吧，一是期望對你的問題有所幫助，二也是對我自己的提高。
1、我對你的第一個問題表示質疑，你認為測試是保證軟體質量嗎？能保證嗎？
測試只能提高軟體質量，做不到保證，bug是永遠存在的，測試工作可以讓這
量減少、降低嚴重問題的存在；軟體過程才可能保證它的質量，不是軟體測
試，所以這一點我要明確出來。一個軟體的質量好壞不依賴於測試者，測試
再高明，軟體設計本身的水平面要品質不高，巧婦也有無米之炊的無奈。

2、測試的原本目標就是發現缺陷，挑毛病，工作性質和開發人員相反，但目標
是一致的，都是為了使軟體更完美、更穩定。

3、蓋房子的時候，先打地基，地基如果有毛病（如不夠深、不平），那以後房
蓋起來了住個幾年，你會發現樓上的梁會發裂，滲水，然後越來越讓人擔
憂。這時你要修復怎麼辦，再怎麼補都不放心，因為地基有缺陷啊！這個道
和第三個問題是一模一樣的，修復的代價太大太大了！在測試中有一個規
則，問題越早解決代價越小，單元測試發現的問題解決只要1塊錢，等到集成
測試再解決，要10塊錢，你認為比例有多大？需求分析系統設計是源頭，重
中之重，這個比例我認為要在上面我舉例中增加80%，就是說它會導致你在編
碼階段多付出8塊錢。前期可能不覺得，越到後期將發現非常頭痛，這也是我
的經驗之談，沒有太多的科學性哦。

4、對於測試員，首先是效率減低；對於項目而言，成本增加了。瞧病就錯了
診，影響大么？將導致後面的百分之八十的事情白做了，百分之二在長遠
目標中有後期幫助，同時證明另外百分之八十步入歧途。這就要在測試設計
的時候要仔細全面，但是這種事情多少都避免不了，早一點發現並改變，也
是很重要的，另外多布置一些小結會議，有利到測試的工作方向和目標。

usfo，希望我的回答對你稍有幫助哦。

B. 軟體怎麼測試

在測試工作中，需要接觸到各種類型的測試工具。一般來說，有以下一些類型的工具：
測試管理工具：可以幫助完成測試計劃、跟蹤測試運行結果等的工具。這類工具還包括有助於需求、設計、編碼測試及缺陷跟蹤的工具；
靜態分析工具：分析代碼而不執行代碼。這種工具檢測某些缺陷比用其它方法更有效，開銷也更小。這種工具一般可以度量代碼的各種指標，如McCabe測定復雜度，Logiscope度量代碼和規范的復合度等等；
覆蓋率工具：這種工具評估通過一系列測試後，軟體被執行的程度。這種工具大量的被應用於單元測試中，如PureCoverage、TrueCoverage、Logiscope等；
動態分析工具：這種工具評估正在運行的系統。例如，檢查系統運行過程中的內存使用情況，是否有內存越界、內存泄露等等，這類工具有Purify、BoundChecker等；
測試執行工具：這類工具可使測試能夠自動化進行，並且各個層次（單元測試、集成測試、系統測試）的執行工具都有。例如系統測試階段有功能測試自動化工具，如Robot、Winrunner、SilkTest等；還有性能測試工具，如Loadrunner、SilKPerformer等。
白盒測試工具主要有：
內存資源泄漏檢查：Numega中的bouncechecker,Rational的Purify
代碼覆蓋率檢查：Numega中的truecoverage,Rational的Purecoverage，Telelogic公司的logiscope, Macabe公司的Macabe
代碼性能檢查：Numega中的truetime,Rational的Quantify
代碼靜態度量分析質量檢查工具：logiscope和Macabe
黑盒測試工具主要有：
客戶端功能測試：MI公司的winrunner,compuware的qarun,Rational的robot
伺服器端壓力性能測試： MI公司的winload,compuware的qaload,Rational的SQA load等等
Web測試工具：MI公司的Astra系列，rsw公司的e-test suite
測試管理工具：rational的test manager,compuware的qadirector等
缺陷跟蹤工具：trackrecord，Testtrack
單元測試工具：

C. 如何做軟體測試

軟體測試說白了，就是找出軟體的不足。軟體測試分為黑合和白盒。也有分為黑盒、灰盒、白盒。黑盒主要指功能測試，以手動測試為主，自動化測試做為次要測試。黑盒測試對技術要求相對於白盒來講不是很高。白盒測試以針對源代碼為主，對技術及開發經測試要求高。灰盒測試是黑盒與白盒組成的綜合測試，對工作能力及經驗要求很高。一般用做系統測試。你的提問范圍太大。希望我的回答對你有幫助。建議先從功能測試入手。白盒和灰盒測試一般都要求有開發經驗。

D. 如何測試app軟體測試在手機中的使用情況

手機app測試主要有以下：
1.安全測試
1)軟體許可權
-扣費風險：包括發送簡訊、撥打電話、連接網路等 -隱私泄露風險：包括訪問手機信息、訪問聯系人信息等 -新增風險項
2)開發者官方許可權列表信息比對分析 2.安裝、運行、卸載測試
驗證App是否能正確安裝、運行、卸載，以及操作過程和操作前後對系統資源的使用情況，主要包括：
1)檢測軟體是否能正確安裝、運行、卸載； 2)安裝、卸載、更新錯誤報告； 3)其他輔助信息： -位置和文件夾是否合理； -組件是否正確注冊或刪除；
-評估操作前後，CPU、Memory（內存佔用）、Storage（磁碟佔用）等系統資源的使用情況。 3.UI測試
測試用戶界面(如菜單、對話框、窗口和其它可視控制項)布局、風格是否滿足客戶要求，文字是否正確，頁面是否美觀，文字，圖片組合是否完美，操作是否友好等。
UI測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。確保用戶界面符合公司或行業的標准。包括用戶友好性、人性化、易操作性測試。 4.功能測試
根據軟體說明或用戶需求驗證App的各個功能實現，採用如下方法實現並評估功能測試過程：
1)採用時間、地點、對象、行為和背景五元素或業務分析等方法分析、提煉App的用戶使用場景，對比說明或需求，整理出內在、外在及非功能直接相關的需求，構建測試點，並明確測試標准（若用戶需求中無明確標准遵循，則需要參考行業或相關國際標准或規則）。 2)根據被測功能點的特性列舉出相應類型的測試用例對其進行覆蓋，如：涉及輸入的地方需要考慮等價、邊界、負面、異常或非法、場景回滾、關聯測試等測試類型對其進行覆蓋。 3)在測試實現的各個階段跟蹤測試實現與需求輸入的覆蓋情況，及時修正業務或需求理解錯誤。 5.性能測試

評估App的時間和空間特性
1)極限測試：在各種邊界壓力情況下（如電池、存儲、網速等），驗證App是否能正確響應。
2)響應能力測試：測試App中的各類操作是否滿足用戶響應時間要求 3)壓力測試：反復/長期操作下，系統資源是否佔用異常； 4)性能評估：評估典型用戶應用場景下，系統資源的使用情況。
5)Benchmark測試（基線測試）：與競爭產品的Benchmarking,產品演變對比測試等。 6.中斷測試
針對智能終端應用的服務等級劃分方式及實時特性所提出的測試方法，如：App在前/後台運行狀態時與來電、文件下載、音樂收聽等關鍵運用的交互情況測試等。 7.兼容測試
主要測試內部和外部兼容性，包括：
與本地及主流App是否兼容； 檢驗在各種網路連接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的數據和運用是否正確；
與各種設備是否兼容（若有跨系統支持則需要檢驗是否在各系統下，各種行為是否一致）。
8.安全測試
安全測試顯得尤為重要，粗心、不謹慎的數據存儲或傳輸方式使得非法、惡意目的有可乘之機。
智能終端安全涉及各信息交互、存儲接點，借鑒於網路傳輸和相關安全測試經驗，App安全測試大概劃分為以下幾類：
1)從數據的本地存儲到數據的傳輸、處理以及遠程訪問等各個環節，基於相應的安全標准/行業標准評估App的安全特性；
2)借鑒在Web App和網路安全測試的一些成功經驗在智能終端App測試中進行裁減或適配；
3)檢測App的用戶授權級別，數據泄漏，非法授權訪問等；
4)對App的輸入有效性校驗、認證、授權、敏感數據存儲、數據加密等方面進行檢測,以期發現潛在的安全問題；
5)基於各種通信協議或相應的行業安全標准檢視App是否滿足相應的要求

E. 軟體測試的測試流程是怎樣的

• 需求：閱讀需求，理解需求，與客戶、開發、架構多方交流，深入了解需求。--testing team
  2.測試計劃: 根據需求估算測試所需資源（人力、設備等）、所需時間、功能點劃分、如何合理分配安排資源等。---testing leader or testing manager
  3.用例設計：根據測試計劃、任務分配、功能點劃分，設計合理的測試用例。---testing leader, senior tester
  4.執行測試：根據測試用例的詳細步驟，執行測試用例。--every tester(主要是初級測試人員)
  5.執行結果記錄和bug記錄：對每個case記錄測試的結果，有bug的在測試管理工具中編寫bug記錄。--every tester(主要是初級測試人員)
  6.defect tracking：追蹤leader分配給你追蹤的bug.直到 bug fixed。--every tester
  7.測試報告：通過不斷測試、追蹤，直到被測軟體達到測試需求要求，並沒有重大bug.
  8.用戶體驗、軟體發布等……

F. 怎麼搞測試軟體啊從哪弄

你首先得了解軟體測試的基本概念才行，然後在逐步學習一些軟體測試知識，建議你看下《軟體測試的藝術》這本書吧。

G. 怎麼軟體測試啊

軟體測試方法

軟體測試的基本方法
單元測試的基本方法
綜合測試的基本方法
確認測試的基本方法
系統測試的基本方法
軟體測試的基本方法

軟體測試的方法和技術是多種多樣的。
對於軟體測試技術，可以從不同的角度加以分類：

從是否需要執行被測軟體的角度，可分為靜態測試和動態測試。
從測試是否針對系統的內部結構和具體實現演算法的角度來看，可分為白盒測試和黑盒測試；

1、黑盒測試

黑盒測試也稱功能測試或數據驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序介面進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數鋸而產生正確的輸出信息，並且保持外部信息（如資料庫或文件）的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因果圖、錯誤推測等，主要用於軟體確認測試。 「黑盒」法著眼於程序外部結構、不考慮內部邏輯結構、針對軟體界面和軟體功能進行測試。「黑盒」法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。

2、白盒測試

白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於軟體驗證。

「白盒」法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。「白盒」法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，得出測試數據。貫穿程序的獨立路徑數是天文數字。但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序違反了設計規范，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發現不了一些與數據相關的錯誤。

3．ALAC(Act-like-a-customer)測試

ALAC測試是一種基於客戶使用產品的知識開發出來的測試方法。ALAC測試是基於復雜的軟體產品有許多錯誤的原則。最大的受益者是用戶，缺陷查找和改正將針對哪些客戶最容易遇到的錯誤。

單元測試的基本方法

單元測試的對象是軟體設計的最小單位模塊。單元測試的依據是詳細設描述，單元測試應對模塊內所有重要的控制路徑設計測試用例，以便發現模塊內部的錯誤。單元測試多採用白盒測試技術，系統內多個模塊可以並行地進行測試。
單元測試任務

單元測試任務包括：1 模塊介面測試；2 模塊局部數據結構測試；3 模塊邊界條件測試；4 模塊中所有獨立執行通路測試；5 模塊的各條錯誤處理通路測試。

模塊介面測試是單元測試的基礎。只有在數據能正確流入、流出模塊的前提下，其他測試才有意義。測試介面正確與否應該考慮下列因素：
1 輸入的實際參數與形式參數的個數是否相同；
2 輸入的實際參數與形式參數的屬性是否匹配；
3 輸入的實際參數與形式參數的量綱是否一致；
4 調用其他模塊時所給實際參數的個數是否與被調模塊的形參個數相同；
5 調用其他模塊時所給實際參數的屬性是否與被調模塊的形參屬性匹配；
6調用其他模塊時所給實際參數的量綱是否與被調模塊的形參量綱一致；
7 調用預定義函數時所用參數的個數、屬性和次序是否正確；
8 是否存在與當前入口點無關的參數引用；
9 是否修改了只讀型參數；
10 對全程變數的定義各模塊是否一致；
11是否把某些約束作為參數傳遞。

如果模塊內包括外部輸入輸出，還應該考慮下列因素：
1 文件屬性是否正確；
2 OPEN/CLOSE語句是否正確；
3 格式說明與輸入輸出語句是否匹配；
4緩沖區大小與記錄長度是否匹配；
5文件使用前是否已經打開；
6是否處理了文件尾；
7是否處理了輸入/輸出錯誤；
8輸出信息中是否有文字性錯誤；

檢查局部數據結構是為了保證臨時存儲在模塊內的數據在程序執行過程中完整、正確。局部數據結構往往是錯誤的根源，應仔細設計測試用例，力求發現下面幾類錯誤：
1 不合適或不相容的類型說明；
2變數無初值；
3變數初始化或省缺值有錯；
4不正確的變數名（拼錯或不正確地截斷）；
5出現上溢、下溢和地址異常。

除了局部數據結構外，如果可能，單元測試時還應該查清全局數據（例如FORTRAN的公用區）對模塊的影響。

在模塊中應對每一條獨立執行路徑進行測試，單元測試的基本任務是保證模塊中每條語句至少執行一次。此時設計測試用例是為了發現因錯誤計算、不正確的比較和不適當的控制流造成的錯誤。此時基本路徑測試和循環測試是最常用且最有效的測試技術。計算中常見的錯誤包括：
1 誤解或用錯了算符優先順序；
2混合類型運算；
3變數初值錯；
4精度不夠；
5表達式符號錯。

比較判斷與控制流常常緊密相關，測試用例還應致力於發現下列錯誤：
1不同數據類型的對象之間進行比較；
2錯誤地使用邏輯運算符或優先順序；
3因計算機表示的局限性，期望理論上相等而實際上不相等的兩個量相等；
4比較運算或變數出錯；
5循環終止條件或不可能出現；
6迭代發散時不能退出；
7錯誤地修改了循環變數。

一個好的設計應能預見各種出錯條件，並預設各種出錯處理通路，出錯處理通路同樣需要認真測試，測試應著重檢查下列問題：
1輸出的出錯信息難以理解；
2記錄的錯誤與實際遇到的錯誤不相符；
3在程序自定義的出錯處理段運行之前，系統已介入；
4異常處理不當；
5錯誤陳述中未能提供足夠的定位出錯信息。

邊界條件測試是單元測試中最後，也是最重要的一項任務。眾的周知，軟體經常在邊界上失效，採用邊界值分析技術，針對邊界值及其左、右設計測試用例，很有可能發現新的錯誤。

單元測試過程

一般認為單元測試應緊接在編碼之後，當源程序編制完成並通過復審和編譯檢查，便可開始單元測試。測試用例的設計應與復審工作相結合，根據設計信息選取測試數據，將增大發現上述各類錯誤的可能性。在確定測試用例的同時，應給出期望結果。

應為測試模塊開發一個驅動模塊（driver）和（或）若干個樁模塊（stub）,下圖顯示了一般單元測試的環境。驅動模塊在大多數場合稱為「主程序」，它接收測試數據並將這些數據傳遞到被測試模塊，被測試模塊被調用後，「主程序」列印「進入-退出」消息。

驅動模塊和樁模塊是測試使用的軟體，而不是軟體產品的組成部分，但它需要一定的開發費用。若驅動和樁模塊比較簡單，實際開銷相對低些。遺憾的是，僅用簡單的驅動模塊和樁模塊不能完成某些模塊的測試任務，這些模塊的單元測試只能採用下面討論的綜合測試方法。

提高模塊的內聚度可簡化單元測試，如果每個模塊只能完成一個，所需測試用例數目將顯著減少，模塊中的錯誤也更容易發現。

H. 如何進行軟體測試

測試裡面的知識學習可以分為以下三個階段來進行（這個階段只是自己的一種個人見解）：第一個階段我們必須要讓做測試的人明白測試在整個軟體工程裡面的重要性，了解測試的相關基礎知識，並且在了解這些知識的過程中逐漸挖掘出他對測試的興趣。興趣愛好是很好的從事一項工作的一個重要條件。讓一個對測試絲毫不懂而且不感興趣的人去直接去做測試，你不覺得是在耽誤別人的青春嗎？ 第二個階段我們必須對測試的流程的管理工作通過實際的軟體測試有個非常明確的認識。因為很多時候工作都是在團隊相互協調的情況下進行的，所以對於整個軟體開發流程以及開發流程當中的測試流程都需要很熟悉，這樣才可以更好的配合工作。當我們這些都很熟悉並且在工作當中應用很流暢的時候，我們就可以對測試工具進行相對應的學習。誠然，現在很多公司在招聘測試人員的時候總是要求了解自動化測試工具，實際上據了解，很多公司並不能真正用自動化測試。所以不要一進門就想著學習自動化測試工具，很多知識在你了解了其他知識之後學習效果跟用途可能會更好。在了解測試相關流程的同時我們必須擴充我們的其他相關知識，包括對我們的產品的客戶的需求的了解要比開發人員了解更全面，更深入。這樣才能保證我們的流程，我們的測試按照客觀的正確的方向前進，而不至於被開發人員的思想所牽引。呵呵。我喜歡做事主動而不是被動的去執行。 到第三個階段我們可以跟區分專業一樣走自己喜歡的途徑：一方面可以繼續深入提高自己的測試的專業技能並且能夠真正從事自動化測試，成為技術領域裡面的專家。另一方面我們可以慢慢趨於測試管理方面。從一個初級測試工程師晉升到一個高級測試工程師比較快，但是從一個初級測試工程師發展到一個Team Leader所需要的時間相對比較長。而從一個高級測試工程師發展到一個資深測試工程師花費時間更長一點，到達資深測試工程師之後就可以很容易做到測試主管了，以後可以發展到PM。當然從初級測試人員到高級、資深測試人員並不是表述為「曲線發展過程」的，很多時候行業經驗、行業知識的累積等都很重要。而這點只有深入發展的人才會發現其重要性的。很多隨著時間的推移和經驗的增長，一些沉澱下來的東西不是表現在字面上，別人就可以理解並領悟的。所以要有信心的同時我們做事還必須有耐心，羅馬非一日建成。相信明天就要緊緊把握今天。

I. 如何去測試一個B/S軟體

由於你們只做功能測試，作為過來人，有兩點建議：
1、需要業務上的各個流程搞通，要非常精通業務，能夠想到各個細枝末節，包括轉牛角尖的地方（就是特殊環節）。
2、程序設計流程，需要你們與開發人員溝通，也需要很精通，這個可以參考設計人員的程序設計資料。
先精通業務，後搞通程序設計流程

J. 新完成的軟體該怎麼測試

不一定需要工具。

簡單來說，
1、根據時間安排和你們這個軟體的具體需求制定一個合適的測試計劃，測試計劃要做以下事情：
a) 制定測試策略。要進行哪些測試（功能、性能、安全等等）， 這個你需要多查查資料；
b) 確定測試進度安排，分配好測試資源（人員、機器的安排等等）；
c) 定義輸入輸出標准（軟體達到什麼程度可以交付測試，測試進行到什麼程度可以結束測試）；
2、測試計劃在完成後要進行評審，包括項目組所有成員，最好叫上你們老師一起，修改不合適的地方，最後把計劃確定下來。確定後就好辦了，後期照著執行就行。
3、寫好測試用例，用例的設計方法網上都有，主要是用例要能覆蓋所有的功能點，步驟和結果要清晰、明確。
4、測試用例完成後也要進行評審。
5、執行測試用例，找到的BUG看來是你們自己修改。BUG修復後還要進行回歸測試，確認bug已經修復。
6、最後BUG修改的差不多，達到通過標准（在測試計劃中定義的）後，就算是OK了。

對於你們來說其他的可以先不考慮，最主要的是寫好測試用例，用例能覆蓋所有的功能點。最後有個規范、完整的測試用例文檔，和軟體一起交付就還算過得去了。