軟體功能點評估常用方法

⑴ 軟體規模估算有哪些方法

現實中常見的軟體成本估算方法包括經驗法（專家法）、類推法，類比法、方程法，交叉驗證法。除估算方法外，還需要估算資料庫的支持才能繼續度量分析，從而得出估算目標。估算數據基礎可以是企業歷史資料庫，也可以是行業基準資料庫。
《軟體研發成本度量規范》中軟體成本估算的思路分三步驟：規模估算、工作量估算、成本估算。

⑵ 軟體測試評估的方法有哪些;分析這些方法有哪些特徵。

1. 黑盒測試
黑盒測試顧名思義就是將被測系統看成一個黑盒，從外界取得輸入，然後再輸出。整個測試基於需求文檔，看是否能滿足需求文檔中的所有要求。黑盒測試要求測試者在測試時不能使用與被測系統內部結構相關的知識或經驗，它適用於對系統的功能進行測試。
黑盒測試的優點有：
1）比較簡單，不需要了解程序內部的代碼及實現；
2）與軟體的內部實現無關；
3）從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；
4）基於軟體開發文檔，所以也能知道軟體實現了文檔中的哪些功能；
5）在做軟體自動化測試時較為方便。
黑盒測試的缺點有：
1）不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的30%；
2）自動化測試的復用性較低。

2. 白盒測試
白盒測試是指在測試時能夠了解被測對象的結構，可以查閱被測代碼內容的測試工作。它需要知道程序內部的設計結構及具體的代碼實現，並以此為基礎來設計測試用例。
白盒測試的直接好處就是知道所設計的測試用例在代碼級上哪些地方被忽略掉，它的優點是幫助軟體測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱藏的問題。

白盒測試的缺點有：

1）程序運行會有很多不同的路徑，不可能測試所有的運行路徑；
2）測試基於代碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可 能會漏掉一些功能需求；
3）系統龐大時，測試開銷會非常大。

3. 基於風險的測試

基於風險的測試是指評估測試的優先順序，先做高優先順序的測試，如果時間或精力不夠，低優先順序的測試可以暫時先不做。有如下一個圖，橫軸代表影響，豎軸代表概率，根據一個軟體的特點來確定：如果一個功能出了問題，它對整個產品的影響有多大，這個功能出問題的概率有多大？如果出問題的概率很大，出了問題對整個產品的影響也很大，那麼在測試時就一定要覆蓋到。對於一個用戶很少用到的功能，出問題的概率很小，就算出了問題的影響也不是很大，那麼如果時間比較緊的話，就可以考慮不測試。
基於風險測試的兩個決定因素就是：該功能出問題對用戶的影響有多大，出問題的概率有多大。其它一些影響因素還有復雜性、可用性、依賴性、可修改性等。測試人員主要根據事情的輕重緩急來決定測試工作的重點。

4. 基於模型的測試

模型實際上就是用語言把一個系統的行為描述出來，定義出它可能的各種狀態，以及它們之間的轉換關系，即狀態轉換圖。模型是系統的抽象。基於模型的測試是利用模型來生成相應的測試用例，然後根據實際結果和原先預想的結果的差異來測試系統。

⑶ 軟體開發工作量如何評估

用於軟體項目工作量估算的方法有以「估」為主的專家法和類推法，以「算」為主的類比法和方程法。在軟體估算的實踐中，類比法和類推法也是普遍使用的估算方法。
1、類比法
類比法是指將本項目的部分屬性與類似的一組基準數據進行比對，進而獲得待估算項目工作量、工期或成本估算值的方法。類比法是基於大量歷史項目樣本數據來確定目標項目的預測值，通常是以50百分位數為參考而非平均值。選擇類比法進行估算，應根據項目的主要屬性，在基準資料庫中選擇主要屬性相同的項目進行比對。
類比法適合評估那些與歷史項目在應用領域、系統規模、環境和復雜度方面相似的項目，通過新項目與歷史項目的比較得到估計數據。類比法估算結果的精確度取決於歷史項目數據的完整性和准確度。因此，用好類比法的前提條件之一是組織建立起較好的項目後評價與分析機制，對歷史項目的相關屬性建立基線數據。
適用范圍：
當需求極其模糊或不確定時，如果此時有與本項目類似屬性（如規模、應用類型、復雜度、開發團隊經驗等）的一組基準數據，則可直接採用類比法，充分利用基準數據來估算工作量。類比法可以在整個項目級上做基準比對，也可以在子系統級上進行。
估算過程：
1） 確定待估算項目所具有的屬性特點，如系統的規模、復雜度、應用類型、業務領域、開發人員的經驗和能力等。
2） 查詢歷史資料庫並篩選「最相似」的項目屬性數據。
3） 如果待估算項目屬性與歷史項目的主要屬性類似，則可依據歷史項目的基線數據直接得出待估算項目的工作量合理范圍。
4） 如果同時滿足待估算項目主要屬性的歷史項目太少，則可針對待估算項目的每個屬性與歷史項目相應屬性的基準數據分別比對，再分別計算得出P25/P50/P75的平均值作為估算值。
5） 一般情況下，取P50的工作量數據作為待估算項目工作量最可能的值。
2、類推法
類推法是指將本項目的部分屬性與高度類似的一個或幾個已完成項目的數據進行比對，適當調整後獲得待估算項目工作量、工期或成本估算值的方罩數法。選擇類推法進行估算，通常只參照1~2個高度類似的項目，同時根據待估算項目與參照項目的差異，進行適當調整。
適用范圍：
1） 當需求極其模糊或不確定時，較難估算工作量，如果此時具有高度類似的歷史項目，則可直接採用類推法，充分利用歷史項目數據進行估算。
2） 適用評估一些與歷史項目在業務領域、應用類型、環境和復雜度等方面的相似項目，通過新項目與歷史項目的比較進行估計。
3） 該方法估算結果的精確度取決於已完成項目滑團數據的完整性、准確度，以及兩個項目之間的相似度。如果沒有類似的項目，該方法就不能應用。
估算過程：
1） 識別出待估算項目的主要屬性。
2） 查找本組織曾經做過的類似的歷史項目。
3） 對比歷史項目，標記差異點，經過調整後計算出待估算項目的工作量。
3、方程法

採用方程法進行工作量估算時，應考慮根據開發組織實際情況進行回歸分析，建立回歸方程。可將所有影響因子都考慮在內建立多元方程，也可以先根據部分影響因子算出初步的結果，再對結果進行調整。
行業級模型示例如下：
行業級模型： AE=（S*PDR）*SWF*RDF
公式中：
AE：調整後工作量，單位為人時
S：規模，單位物讓首為功能點數
PDR：生產率，單位為人時每功能點
SWF：軟體因素調整因子
RDF：開發因素調整因子
能上回答望採納！如有疑問可私信！

⑷ 軟體測試的方法一共有幾種

1、從是否關心內部結構來看

（1）白盒測試：又稱為結構測試或邏輯驅動測試，是一種按照程序內部邏輯結構和編碼結構，設計測試數據並完成測試的一種測試方法。

（2）黑盒測試：又稱為數據驅動測試，把測試對象當做看不見的黑盒，在完全不考慮程序內部結構和處理過程的情況下，測試者僅依據程序功能的需求規范考慮，確定測試用例和推斷測試結果的正確性，它是站在使用軟體或程序的角度，從輸入數據與輸出數據的對應關系出發進行的測試。

（3）灰盒測試：是一種綜合測試法，它將「黑盒」測試與「白盒」測試結合在一起，是基於程序運行時的外部表現又結合內部邏輯結構來設計用例，執行程序並採集路徑執行信息和外部用戶介面結果的測試技術。

2、從是否執行代碼看

（1）靜態測試：指不運行被測程序本身，僅通過分析或檢查源程序的語法、結構、過程、介面等來檢查程序的正確性。

(2)動態測試：是指通過運行被測程序，檢查運行結果與預期結果的差異，並分析運行效率、正確性和健壯性等性能指標。

3、從開發過程級別看

（1）單元測試：又稱模塊測試，是針對軟體設計的最小單位----程序模塊或功能模塊，進行正確性檢驗的測試工作。其目的在於檢驗程序各模塊是否存在各種差錯，是否能正確地實現了其功能，滿足其性能和介面要求。

(2)集成測試：又叫組裝測試或聯合，是單元測試的多級擴展，是在單元測試的基礎上進行的一種有序測試。旨在檢驗軟體單元之間的介面關系，以期望通過測試發現各軟體單元介面之間存在的問題，最終把經過測試的單元組成符合設計要求的軟體。

（3）系統測試：是為判斷系統是否符合要求而對集成的軟、硬體系統進行的測試活動、它是將已經集成好的軟體系統，作為基於整個計算機系統的一個元素，與計算機硬體、外設、某些支持軟體、人員、數據等其他系統元素結合在一起，在實際運行環境下，對計算機系統進行一系列的組裝測試和確認測試。

在系統測試中，對於具體的測試類型有：

（1）功能測試：對軟體需求規格說明書中的功能需求逐項進行的測試，以驗證功能是否滿足要求。

（2）性能測試：對軟體需求規格說明書的功能需求逐項進行的測試，以驗證功能是否滿足要求。

（3）介面測試：對軟體需求規格說明中的介面需求逐項進行的測試。

（4）人機交互界面測試：對所有人機交互界面提供的操作和顯示界面進行的測試，以檢驗是否滿足用戶的需求。

（5）強度測試：強制軟體運行在異常乃至發生故障的情況下（設計的極限狀態到超出極限），驗證軟體可以運行到何種程序的測試。

（6）餘量測試：對軟體是否達到規格說明中要求的餘量的測試。

（7）安全性測試：檢驗軟體中已存在的安全性、安全保密性措施是否有效的測試，

（8）可靠性測試：在真實的或模擬的環境中，為做出軟體可靠性估計而對軟體進行的功能（其輸入覆蓋和環境覆蓋一般大於普通的功能測試）

（9）恢復性測試：對有恢復或重置功能的軟體的每一類導致恢復或重置的情況，逐一進行的測試。

（10）邊界測試：對軟體處在邊界或端點情況下運行狀態的測試。

（11）數據處理測試：對完成專門數據處理功能所進行的測試。

（12）安裝性測試：對安裝過程是否符合安裝規程的測試，以發現安裝過程中的錯誤。

（13）容量測試：檢驗軟體的能力最高能達到什麼程度的測試。

（14）互操作性測試：為驗證不同軟體之間的互操作能力而進行的測試。

（15）敏感性測試：為發現在有效輸入類中可能引起某種不穩定性或不正常處理的某些數據的組合而進行的測試。

（16）標准符合性測試：驗證軟體與相關國家標准或規范（如軍用標准、國家標准、行業標准及國際標准）一致性的測試。

（17）兼容性測試：驗證軟體在規定條件下與若干個實體共同使用或實現數據格式轉換時能滿足有關要求能力的測試。

（18）中文本地化測試：驗證軟體在不降低原有能力的條件下，處理中文能力的測試。

4、從執行過程是否需要人工干預來看

（1）手工測試：就是測試人員按照事先為覆蓋被測軟體需求而編寫的測試用例，根據測試大綱中所描述的測試步驟和方法，手工地一個一個地輸 入執行，包括與被測軟體進行交互（如輸入測試數據、記錄測試結果等），然後觀察測試結果，看被測程序是否存在問題，或在執行過程中是否會有一場發生，屬於比較原始但是必須執行的一個步驟。

（2）自動化測試：實際上是將大量的重復性的測試工作交給計算機去完成，通常是使用自動化測試工具來模擬手動測試步驟，執行用某種程序設計語言編寫的過程（全自動測試就是指在自動測試過程中，不需要人工干預，由程序自動完成測試的全過程；半自動測試就是指在自動測試過程中，需要手動輸入測試用例或選擇測試路徑，再由自動測試程序按照人工指定的要求完成自動測試）

5、從測試實施組織看

（1）開發測試：開發人員進行的測試

（2）用戶測試：用戶方進行的測試

（3）第三方測試：有別於開發人員或用戶進行的測試，由專業的第三方承擔的測試，目的是為了保證測試工作的客觀性

6、從測試所處的環境看

（1）阿爾法測試：是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的測試

（2）貝塔測試：是用戶公司組織各方面的典型終端用戶在日常工作中實際使用貝塔版本，並要求用戶報告

(4)軟體功能點評估常用方法擴展閱讀

軟體測試的內容：

1 得到需求、功能設計、內部設計說書和其他必要的文檔

2 得到預算和進度要求

3 確定與項目有關的人員和他們的責任、對報告的要求、所需的標准和過程 ( 例如發行過程、變更過程、等等 )

4 確定應用軟體的高風險范圍，建立優先順序、確定測試所涉及的范圍和限制

5 確定測試的步驟和方法 ── 部件、集成、功能、系統、負載、可用性等各種測試

6 確定對測試環境的要求 ( 硬體、軟體、通信等 )

7 確定所需的測試用具 (testware) ，包括記錄 / 回放工具、覆蓋分析、測試跟蹤、問題 / 錯誤跟蹤、等等

8 確定對測試的輸入數據的要求

9 分配任務和任務負責人，以及所需的勞動力

10 設立大致的時間表、期限、和里程碑

11 確定輸入環境的類別、邊界值分析、錯誤類別

12 准備測試計劃文件和對計劃進行必要的回顧

13 准備白盒測試案例

14 對測試案例進行必要的回顧 / 調查 / 計劃

15 准備測試環境和測試用具，得到必需的用戶手冊 / 參考文件 / 結構指南 / 安裝指南，建立測試跟蹤過程，建立日誌和檔案、建立或得到測試輸入數據

16 得到並安裝軟體版本

17 進行測試

18 評估和報告結果

19 跟蹤問題 / 錯誤，並解決它

20 如果有必要，重新進行測試

21 在整個生命周期里維護和修改測試計劃、測試案例、測試環境、和測試用具