軟體工程估計錯誤總數的方法

1. 軟體測試如何估計程序中的錯誤總數

解：
答案1:
(25+30-15)/(80%)=50
先算出兩組發現的bug總數，再根據測試的2/8定律（即測試只能查到系統中80%的錯誤）
結果當然是50了

答案2:
設錯誤總數為X，那麼甲發現錯誤的概率P(甲)為 25 / X，乙發現錯誤的概率P(乙)為 30 / X ，甲乙同時發現錯誤的概率P(同)為 15 / X 。
因為 P(甲)*P(乙)=P(同) ，所以(25 / X) * (30 / X) = 15 / X
計算而得X=50

2. 在excel表中我只知道一個總數 用什麼方法能知道這個總數是哪幾個的數相加的

這個屬於最簡單的條件規劃求解，去看看這個
http://..com/question/98107620.html

3. 軟體規模估算有哪些方法

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

4. 軟體工程中的數據定義怎麼做

軟體工程
軟體工程一直以來都缺乏一個統一的定義，很多學者、組織機構都分別給出了自己的定義：

Boehm：運用現代科學技術知識來設計並構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。

IEEE：軟體工程是開發、運行、維護和修復軟體的系統方法。

Fritz Bauer：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法。

軟體工程(SoftWare Engineering)的框架可概括為：目標、過程和原則。

(1)軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。

(2)軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓過程等。

(3)軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則。

軟體工程必須遵循什麼原則

圍繞工程設計、工程支持以及工程管理已提出了以下四條基本原則：

(1)選取適宜的開發模型

該原則與系統設計有關。在系統設計中，軟體需求、硬體需求以及其它因素間是相互制約和影響的，經常需要權衡。因此，必需認識需求定義的易變性，採用適當的開發模型，保證軟體產品滿足用戶的要求。

(2)採用合適的設計方法

在軟體設計中，通常需要考慮軟體的模塊化、抽象與信息隱蔽、局部化、一致性以及適應性等特徵。合適的設計方法有助於這些特徵的實現，以達到軟體工程的目標。

(3)提供高質量的工程支撐

工欲善其事，必先利其器。在軟體工程中，軟體工具與環境對軟體過程的支持頗為重要。軟體工程項目的質量與開銷直接取決於對軟體工程所提供的支撐質量和效用。

(4)重視軟體工程的管理

軟體工程的管理直接影響可用資源的有效利用，生產滿足目標的軟體產品以及提高軟體組織的生產能力等問題。因此，僅當軟體過程予以有效管理時，才能實現有效的軟體工程。

軟體工程是指導計算機軟體開發和維護的工程學科。

採用工程的概念、原理、 技術和方法來開發與維護軟體，把經過時間考驗而證明正確的管理技術和當前能夠 得到的最好的技術方法結合起來，這就是軟體工程。

軟體工程強調使用生存周期方法學和各種結構分析及結構設計技術。它們是

在七十年代為了對付應用軟體日益增長的復雜程度、漫長的開發周期以及用戶對

軟體產品經常不滿意的狀況而發展起來的。人類解決復雜問題時普遍採用的一個策

略就是「各個擊破」，也就是對問題進行分解然後再分別解決各個子問題的策略

。軟體工程採用的生存周期方法學就是從時間角度對軟體開發和維護的復雜問題

進行分解，把軟體生存的漫長周期依次劃分為若干個階段，每個階段有相對獨立

的任務，然後逐步完成每個階段的任務。採用軟體工程方法論開發軟體的時候，

從對任務的抽象邏輯分析開始，一個階段一個階段地進行開發。前一個階段任務

的完成是開始進行後一個階段工作的前提和基礎，而後一階段任務的完成通常是

使前一階段提出的解法更進一步具體化，加進了更多的物理細節。每一個階段的開

始和結束都有嚴格標准，對於任何兩個相鄰的階段而言，前一階段的結束標准就

是後一階段的開始標准。在每一個階段結束之前都必須進行正式嚴格的技術審查

和管理復審，從技術和管理兩方面對這個階段的開發成果進行檢查，通過之後這

個階段才算結束；如果檢查通不過，則必須進行必要的返工，並且返工後還要再

經過審查。審查的一條主要標准就是每個階段都應該交出「最新式的」（即和所

開發的軟體完全一致的）高質量的文檔資料，從而保證在軟體開發工程結束時有

一個完整准確的軟體配置交付使用。文檔是通信的工具，它們清楚准確地說明了

到這個時候為止，關於該項工程已經知道了什麼，同時確立了下一步工作的基礎

。此外，文檔也起備忘錄的作用，如果文檔不完整，那麼一定是某些工作忘記做

了，在進入生存周期的下一階段之前，必須補足這些遺漏的細節。在完成生存周

期每個階段的任務時，應該採用適合該階段任務特點的系統化的技術方法——結

構分析或結構設計技術。

把軟體生存周期劃分成若干個階段，每個階段的任務相對獨立，而且比較簡

單，便於不同人員分工協作，從而降低了整個軟體開發工程的困難程度；在軟體

生存周期的每個階段都採用科學的管理技術和良好的技術方法，而且在每個階段

結束之前都從技術和管理兩個角度進行嚴格的審查，合格之後才開始下一階段的

工作，這就使軟體開發工程的全過程以一種有條不紊的方式進行，保證了軟體的

質量，特別是提高了軟體的可維護性。總之，採用軟體工程方法論可以大大提高

軟體開發的成功率，軟體開發的生產率也能明顯提高。

目前劃分軟體生存周期階段的方法有許多種，軟體規模、種類、開發方式、

開發環境以及開發時使用的方法論都影響軟體生存周期階段的劃分。在劃分軟體

生存周期的階段時應該遵循的一條基本原則就是使各階段的任務彼此間盡可能相

對獨立，同一階段各項任務的性質盡可能相同，從而降低每個階段任務的復雜程

度，簡化不同階段之間的聯系，有利於軟體開發工程的組織管理。一般說來，軟

件生存周期由軟體定義、軟體開發和軟體維護三個時期組成，每個時期又進一步

劃分成若干個階段。下面的論述主要針對應用軟體，對系統軟體也基本適用。

軟體定義時期的任務是確定軟體開發工程必須完成的總目標；確定工程的可行

性，導出實現工程目標應該採用的策略及系統必須完成的功能；估計完成該項工程

需要的資源和成本，並且制定工程進度表。這個時期的工作通常又稱為系統分析

，由系統分析員負責完成。軟體定義時期通常進一步劃分成三個階段，即問題定

義、可行性研究和需求分析。

開發時期具體設計和實現在前一個時期定義的軟體，它通常由下述四個階段組

成：總體設計，詳細設計，編碼和單元測試，綜合測試。

維護時期的主要任務是使軟體持久地滿足用戶的需要。具體地說，當軟體在

使用過程中發現錯誤時應該加以改正；當環境改變時應該修改軟體以適應新的環境

；當用戶有新要求時應該及時改進軟體滿足用戶的新需要。通常對維護時期不再

進一步劃分階段，但是每一次維護活動本質上都是一次壓縮和簡化了的定義和開

發過程。

下面扼要介紹軟體生存周期每個階段的基本任務和結束標准。

1問題定義

問題定義階段必須回答的關鍵問題：「要解決的問題是什麼？」如果不知道

問題是什麼就試圖解決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最

終得出的結果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的

，但是在實踐中它卻可能是最容易被忽視的一個步驟。

通過問題定義階段的工作，系統分析員應該提出關於問題性質、工程目標和

規模的書面報告。通過對系統的實際用戶和使用部門負責人的訪問調查，分析員

扼要地寫出他對問題的理解，並在用戶和使用部門負責人的會議上認真討論這份

書面報告，澄清含糊不精的地方，改正理解不正確的地方，最後得出一份雙方都

滿意的文檔。

問題定義階段是軟體生存周期中最簡短的階段，一般只需要一天甚至更少的

時間。

2可行性研究

這個階段要回答的關鍵問題：「對於上一個階段所確定的問題有行得通的解

決辦法嗎？」為了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了的

系統分析和設計的過程，也就是在較抽象的高層次上進行的分析和設計的過程。

可行性研究應該比較簡短，這個階段的任務不是具體解決問題，而是研究問題的范

圍，探索這個問題是否值得去解，是否有可行的解決辦法。

在問題定義階段提出的對工程目標和規模的報告通常比較含糊。可行性研究

階段應該導出系統的高層邏輯模型（通常用數據流圖表示），並且在此基礎上更

准確、更具體地確定工程規模和目標。然後分析員更准確地估計系統的成本和效

益，對建議的系統進行仔細的成本／效益分析是這個階段的主要任務之一。

可行性研究的結果是使用部門負責人做出是否繼續進行這項工程的決定的

重要依據，一般說來，只有投資可能取得較大效益的那些工程項目才值得繼續進

行下去。可行性研究以後的那些階段將需要投入要多的人力物力。及時中止不值

得投資的工程項目，可以避免更大的浪費。

3需求分析

這個階段的任務仍然不是具體地解決問題，而是准確地確定「為了解決這個問題，

目標系統必須做什麼」，主要是確定目標系統必須具備哪些功能。

用戶了解他們所面對的問題，知道必須做什麼，但是通常不能完整准確地表

達出他們的要求，更不知道怎樣利用計算機解決他們的問題；軟體開發人員知道

怎樣使用軟體實現人們的要求，但是對特定用戶的具體要求並不完全清楚。因此系統

分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經過用戶確

認的系統邏輯模型。通常用數據流圖、數據字典和簡要的演算法描述表示系統的邏

輯模型。

在需求分析階段確定的系統邏輯模型是以後設計和實現目標系統的基礎，因

此必須准確完整地體現用戶的要求。系統分析員通常都是計算機軟體專家，技術

專家一般都喜歡很快著手進行具體設計，然而，一旦分析員開始談論程序設計的

細節，就會脫離用戶，使他們不能繼續提出他們的要求和建議。較件工程使用的結

構分析設計的方法為每個階段都規定了特定的結束標准，需求分析階段必須提供完

整准確的系統邏輯模型，經過用戶確認之後才能進入下一個階段，這就可以有

效地防止和克服急於著手進行具體設計的傾向。

4總體設計

這個階段必須回答的關鍵問題是：「概括地說，應該如何解決這個問題？」

首先，應該考慮幾種可能的解決方案。列如，目標系統的一些主要功能是用

計算機自動完成還是用人工完成；如果使用計算機，那麼是使用批處理方式還是

人機交互方式；信息存儲使用傳統的文件系統還是資料庫……。通常至少應該考慮

下述幾類可能的方案：

低成本的解決方案。系統只能完成最必要的工作，不能多做一點額處的工

作。

中等成本的解決方案。這樣的系統不僅能夠很好地完成預定的任務，使用

起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點。雖然用戶沒

有提出這些具體要求，但是系統分析員根據自己的知識和經驗斷定，這些附加的

能力在實踐中將證明是很有價值的。

高成本的「十全十美」的系統。這樣的系統具有用戶可能希望有的所有功

能和特點。

系統分析員應該使用系統流程圖或其他工具描述每種可能的系統，估計每種

方案的成本和效益，還應該在充分權衡各種方案的利弊的

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

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）貝塔測試：是用戶公司組織各方面的典型終端用戶在日常工作中實際使用貝塔版本，並要求用戶報告

(5)軟體工程估計錯誤總數的方法擴展閱讀

軟體測試的內容：

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

2 得到預算和進度要求

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

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

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

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

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

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

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

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

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

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

13 准備白盒測試案例

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

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

16 得到並安裝軟體版本

17 進行測試

18 評估和報告結果

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

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

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

6. 軟體工程的題請幫忙坐下

CCCDC DBADB第4題不太確定