1、1. 軟件生命周期(SDLC)的六個階段軟件危機的出現主要表現在：a. 由于缺乏大型軟件開發經驗和軟件開發數據積累，開發工作計劃很難制定；b. 開發早期需求分析不夠明確，造成開發后期矛盾集中暴露；c. 不遵循開發規范，開發文檔不完整，軟件難以維護；d. 缺乏嚴密有效的軟件質量檢測手段，交付給用戶的軟件質量差。軟件危機的后果：a. 軟件質量不高，很難穩定；b. 軟件項目延期，進度無法控制； c. 成本增加，無法控制預算。軟件危機的根源：a. 根據摩爾定律，硬件發展很快，相應對軟件系統的期望越來越高； b. 軟件系統復雜性提高，需多人合作；c. 軟件開發是人的智力活動，無法用已有的產業工程方法來組

2、織管理。軟件生命周期(SDLC，軟件生存周期)是軟件的產生直到報廢的生命周期，周期內有問題定義、可行性分析、總體描述、系統設計、編碼、調試和測試、驗收與運行、維護升級到廢棄等階段，這種按時間分程的思想方法是軟件工程中的一種思想原則，即按部就班、逐步推進，每個階段都要有定義、工作、審查、形成文檔以供交流或備查，以提高軟件的質量。但隨著新的面向對象的設計方法和技術的成熟，軟件生命周期設計方法的指導意義正在逐步減少。1、問題的定義及規劃      此階段是軟件開發方與需求方共同討論，主要確定軟件的開發目標及其可行性。2、需求分析  

3、;    在確定軟件開發可行的情況下，對軟件需要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段做得好，將為整個軟件開發項目的成功打下良好的基礎。"唯一不變的是變化本身。"，同樣需求也是在整個軟件開發過程中不斷變化和深入的，因此我們必須制定需求變更計劃來應付這種變化，以保護整個項目的順利進行。3、軟件設計      此階段主要根據需求分析的結果，對整個軟件系統進行設計，如系統框架設計，數據庫設計等等。軟件設計一般分為總體設計和詳細設計。好的軟件設計將為軟件程序編寫打下良好的基

4、礎。4、程序編碼      此階段是將軟件設計的結果轉換成計算機可運行的程序代碼。在程序編碼中必須要制定統一，符合標準的編寫規范。以保證程序的可讀性，易維護性，提高程序的運行效率。5、軟件測試      在軟件設計完成后要經過嚴密的測試，以發現軟件在整個設計過程中存在的問題并加以糾正。整個測試過程分單元測試、集成測試以及系統測試三個階段進行。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計劃并嚴格按照測試計劃進行測試，以減少測試的隨意性。6、運行維護  

5、;    軟件維護是軟件生命周期中持續時間最長的階段。在軟件開發完成并投入使用后，由于多方面的原因，軟件不能繼續適應用戶的要求。要延續軟件的使用壽命，就必須對軟件進行維護。軟件的維護包括糾錯性維護和改進性維護兩個方面。2、軟件生命周期模型 任何軟件都是從最模糊的概念開始的：為某個公司設計辦公的流程處理；設計一種商務信函打印系統并投放市場。這個概念是不清晰的，但卻是最高層的業務需求的原型。這個概念都會伴隨著一個目的，例如在一個"銀行押匯系統" 的目的是提高工作的效率。這個目的將會成為系統的核心思想，系統成敗的評判標準。99年政府部門上了大量的OA

6、系統，學過一點Lotus Notes的人都發了財（IBM更不用說了），但是更普遍的情況是，許多的政府部門原有的處理模式并沒有變化，反而又加上了自動化處理的一套流程。提高工作效率的初衷卻導致了完全不同的結果。這樣的軟件究竟是不是成功的呢？ 從概念提出的那一刻開始，軟件產品就進入了軟件生命周期。在經歷需求、分析、設計、實現、部署后，軟件將被使用并進入維護階段，直到最后由于缺少維護費用而逐漸消亡。這樣的一個過程，稱為"生命周期模型"（Life Cycle Model）。 典型的幾種生命周期模型包括瀑布模型、快速原型模型、迭代模型。瀑布模型（Waterfall Model）首先由R

7、oyce提出。該模型由于酷似瀑布聞名。在該模型中，首先確定需求，并接受客戶和SQA小組的驗證。然后擬定規格說明，同樣通過驗證后，進入計劃階段可以看出，瀑布模型中至關重要的一點是只有當一個階段的文檔已經編制好并獲得SQA小組的認可才可以進入下一個階段。這樣，瀑布模型通過強制性的要求提供規約文檔來確保每個階段都能很好的完成任務。但是實際上往往難以辦到，因為整個的模型幾乎都是以文檔驅動的，這對于非專業的用戶來說是難以閱讀和理解的。想象一下，你去買衣服的時候，售貨員給你出示的是一本厚厚的服裝規格說明，你會有什么樣的感觸。雖然瀑布模型有很多很好的思想可以借鑒，但是在過程能力上有天生的缺陷。 迭代式模型

8、迭代式模型是RUP推薦的周期模型，也是我們在這個系列文章討論的基礎。在RUP中，迭代被定義為：迭代包括產生產品發布（穩定、可執行的產品版本）的全部開發活動和要使用該發布必需的所有其它外圍元素。所以，在某種程度上，開發迭代是一次完整地經過所有工作流程的過程：（至少包括）需求工作流程、分析設計工作流程、實施工作流程和測試工作流程。實質上，它類似小型的瀑布式項目。RUP認為，所有的階段（需求及其它）都可以細分為迭代。每一次的迭代都會產生一個可以發布的產品，這個產品是最終產品的一個子集。迭代的思想如上圖所示。 迭代和瀑布的最大的差別就在于風險的暴露時間上。"任何項目都會涉及到一定的風險。如果

9、能在生命周期中盡早確保避免了風險，那么您的計劃自然會更趨精確。有許多風險直到已準備集成系統時才被發現。不管開發團隊經驗如何，都絕不可能預知所有的風險。"（RUP）二者的區別如下圖所示： 由于瀑布模型的特點（文檔是主體），很多的問題在最后才會暴露出來，為了解決這些問題的風險是巨大的。"在迭代式生命周期中，您需要根據主要風險列表選擇要在迭代中開發的新的增量內容。每次迭代完成時都會生成一個經過測試的可執行文件，這樣就可以核實是否已經降低了目標風險。"（RUP） 快速原型（Rapid Prototype）模型是我喜歡采用的另一種模型?？焖僭湍Ｐ驮诠δ苌系葍r于產品的一個子

10、集。注意，這里說的是功能上。瀑布模型的缺點就在于不夠直觀，快速原型法就解決了這個問題。一般來說，根據客戶的需要在很短的時間內解決用戶最迫切需要，完成一個可以演示的產品。這個產品只是實現部分的功能（最重要的）。它最重要的目的是為了確定用戶的真正需求。在我的經驗中，這種方法非常的有效，原先對計算機沒有絲毫概念的用戶在你的原型面前往往口若懸河，有些觀點讓你都覺得非常的吃驚。在得到用戶的需求之后，原型將被拋棄。因為原型開發的速度很快，設計方面是幾乎沒有考慮的，如果保留原型的話，在隨后的開發中會為此付出極大的代價。至于保留原型方面，也是有一種叫做增量模型是這么做的，但這種模型并不為大家所接受，不在我們的

11、討論之內。 上述的模型中都有自己獨特的思想，其實現在的軟件組織中很少說標準的采用那一種模型的。模型和實用還是有很大的區別的。 軟件生命周期模型的發展實際上是體現了軟件工程理論的發展。在最早的時候，軟件的生命周期處于無序、混亂的情況。一些人為了能夠控制軟件的開發過程，就把軟件開發嚴格的區分為多個不同的階段，并在階段間加上嚴格的審查。這就是瀑布模型產生的起因。瀑布模型體現了人們對軟件過程的一個希望：嚴格控制、確保質量?？上У氖?，現實往往是殘酷的。瀑布模型根本達不到這個過高的要求，因為軟件的過程往往難于預測。反而導致了其它的負面影響，例如大量的文檔、繁瑣的審批。因此人們就開始嘗試著用其它的方法來改進

12、或替代瀑布方法。例如把過程細分來增加過程的可預測性。補充：軟件開發過程中的相關技術3.軟件測試概念廣義概念：指軟件生存周期中所有的檢查、評審和確認工作，其中包括了對分析、設計階段，以及完成開發后維護階段的各類文檔、代碼的審查和確認狹義概念：識別軟件缺陷的過程，即實際結果與預期結果的不一致4.軟件測試目的ü 測試的目的就是發現軟件中的各種缺陷ü 測試只能證明軟件存在缺陷，不能證明軟件不存在缺陷ü 測試可以使軟件中缺陷降低到一定程度，而不是徹底消滅ü 以較少的用例、時間和人力找出軟件中的各種錯誤和缺陷，以確保軟件的質量軟件測試的三層次：1.發現缺陷 2.盡早

13、的發現缺陷3.幫助開發軟件盡早的發現缺陷。（體現了測試人員的價值）5軟件測試原則ü Good-enough: 一種權衡投入/產出比的原則ü 保證測試的覆蓋程度，但窮舉測試是不可能的ü 所有的測試都應追溯到用戶需求ü 越早測試越好，測試過程與開發過程應是相結合的ü 測試的規模由小而大，從單元測試到系統測試ü 為了盡可能地發現錯誤，應該由獨立的第三方來測試ü 不能為了便于測試擅自修改程序ü 既應該測試軟件該做什么也應該測試軟件不該做什么6軟件測試的的重點ü 測試用例的設計 測試用例的設計是整個軟件測試工作的核

14、心 測試用例反映對被測對象的質量要求，決定對測試對象的質量評估ü 測試工作的管理 尤其是對包含多個子系統的大型軟件系統，其測試工作涉及大量人力和物力，有效的測試工作管理是保證有效測試工作的必要前提ü 測試環境的建立 測試環境應該與實際測試環境一致7軟件測試的幾種常用模型W模型由Evolutif公司提出，相對于V模型，W模型增加了軟件各開發階段中應同步進行的驗證和確認活動。W模型由兩個V字型模型組成，分別代表測試與開發過程，圖中明確表示出了測試與開發的并行關系。W模型強調：測試伴隨著整個軟件開發周期，而且測試的對象不僅僅是程序，需求、設計等同樣要測試，也就是說，測試與開發是同

15、步進行的。W模型有利于盡早地全面的發現問題。例如，需求分析完成后，測試人員就應該參與到對需求的驗證和確認活動中，以盡早地找出缺陷所在。同時，對需求的測試也有利于及時了解項目難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快項目進度。但W模型也存在局限性。在W模型中，需求、設計、編碼等活動被視為串行的，同時，測試和開發活動也保持著一種線性的前后關系，上一階段完全結束，才可正式開始下一個階段工作。這樣就無法支持迭代的開發模型。對于當前軟件開發復雜多變的情況，W模型并不能解除測試管理面臨著困惑。X模型是由Marick提出的，他的目標是彌補V模型的一些缺陷，例如：交接、經常性的集成等問題

16、。     X模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此后將進行頻繁的交接，通過集成最終合成為可執行的程序。右上半部分，這些可執行程序還需要進行測試。已通過集成測試的成品可以進行封版并提交給用戶，也可以作為更大規模和范圍內集成的一部分。多根并行的曲線表示變更可以在各個部分發生。      X模型還定位了探索性測試（右下方）。這是不進行事先計劃的特殊類型的測試，諸如“我這么測一下結果會怎么樣？”，這一方式往往能幫助有經驗的測試人員在測試計劃之外發現更多的軟件錯誤。  

17、60;   但V模型的一個強項是它明確的需求角色的確認，而X模型沒有這么做，這大概是X模型的一個不足之處。 而且由于X模型從沒有被文檔化，其內容一開始需要從V模型的相關內容中進行推斷，因為它還沒有完全從文字上成為V模型的全面擴展。V 模型 ：“V”的左端表示傳統的瀑布開發模型，而“V”右端表明相應的測試階段。在V模型中，每一個開發階段和一個相應的測試階段相連。當工作進行到某個特定的開發階段時，就要執行相應測試階段的計劃和一些基本的設計工作。用戶需求單元測試編碼集成測試概要設計詳細設計需求說明系統測試驗收測試8黑盒測試ü 什么是黑盒測試 又稱功能測試或數據驅動測試，

18、是針對軟件的功能需求/實現進行測試，通過測試來檢測每個功能是否符合需求，不考慮程序內部的邏輯結構ü 黑盒測試方法 功能劃分 等價類劃分 邊界值分析 因果圖 錯誤推測等9什么是白盒測試 白盒測試也稱結構測試或邏輯驅動測試，必須知道軟件內部工作過程，通過測試來檢測軟件內部是否按照需求、設計正常運行 白盒測試的主要方法 對應于程序的一些主要結構：語句、分支、邏輯路徑、變量；白盒測試的主要方法是： 語句覆蓋方法 分支覆蓋方法 邏輯覆蓋方法10.什么是動態測試動態測試需要在開發/測試環境或實際運行環境中運行軟件，并使用測試用例去查找軟件缺陷；動態測試包括功能確認與接口測試、覆蓋率分析、性能分析

19、、內存分析等 11.什么是靜態測試靜態測試不實際運行軟件，主要是對軟件的編程格式、結構等方面進行評估.靜態測試包括代碼檢查、程序結構分析、代碼質量度量等。它可以由人工進行，也可以借助軟件工具自動進行 12.手工測試和自動測試a.手工測試缺點在于測試工作量大，重復多，回歸測試難以實現b.自動測試利用軟件測試工具自動實現全部或部分測試工作：管理、設計、執行和報告；節省大量的測試開銷，并能夠完成一些手工測試無法實現的測試ü 手工完成測試的全部過程無法保證測試的科學性與嚴密性: 修改的缺陷越多，回歸測試越困難 沒有人能向決策層提供精確的數據以度量當前的工作進度及工作效率 反復測試帶來的倦怠情

20、緒及其它人為因素使得測試標準前后不一 測試花費的時間越長，測試的嚴格性也就越低ü 自動測試將測試人員從反復、煩雜的測試執行中解放出來，用更多的時間進行測試設計和結果分析ü 軟件測試不可能完全自動化ü 不能完成所有手工測試任務ü 無創造性且靈活性差，不能改進測試的有效性ü 過程中可能會遇到許多意想不到的問題，特別是當軟件不穩定時ü 測試腳本的維護高13. 測試流程ü 單元測試ü 集成測試ü 系統測試ü 用戶驗收測試ü 回歸測試14.單元測試ü 完成對最小的軟件設計單元模塊的驗證

21、工作ü 目標是確保模塊被正確地編碼ü 使用過程設計描述作為指南，對重要的控制路徑進行測試以發現模塊內的錯誤ü 通常情況下是面向白盒的ü 對代碼風格和規則、程序設計和結構、業務邏輯等進行靜態測試，及早地發現和解決不易顯現的錯誤ü 單元測試的內容 接口測試 內部數據結構 全局數據結構 邊界 語句覆蓋，錯誤路徑15.集成測試ü 通過測試發現與模塊接口有關的問題ü 目標是把通過了單元測試的模塊拿來，構造一個在設計中所描述的程序結構 ü 應當避免一次性的集成（除非軟件規模很小），而采用增量集成集成測試主要內容ü A

22、PIü API/參數組合16系統測試ü 根據軟件需求規范的要求進行系統測試，確認系統滿足需求的要求ü 系統測試人員相當于用戶代言人ü 在需求分析階段要確定軟件的可測性，保證有效完成系統測試工作ü 系統測試主要內容ü 所有功能需求得到滿足ü 所有性能需求得到滿足ü 其它需求（例如安全性、容錯性、兼容性等）得到滿足17.用戶驗收/確認測試ü Alpha測試 是由用戶在開發者的場所來進行的，Alpha測試是在一個受控的環境中進行的ü Beta測試 由軟件的最終用戶在一個或多個用戶場所來進行的，開發者通

23、常不在現場，用戶記錄測試中遇到的問題并報告給開發者18壓力測試VS性能測試  性能測試的目的不是去找bugs,而是排除系統的瓶頸，以及為以后的回歸測試建立一個基準。而性能測試的操作，實際上就是一個非常小心受控的測量分析過程。在理想的情況下，被測軟件在這個時候已經是足夠穩定了性能測試是為了檢查系統的反映，運行速度等性能指標，他的前提是要求在一定負載下，如檢查一個網站在100人同時在線的情況下的性能指標，每個用戶是否都還可以正常的完成操作等。概括就是：在不同負載下（負載一定）時，通過一些系統參數（如反應時間等）檢查系統的運行情況；壓力測試是為了發現系統能支持的最大負載，他的前提是要求系統

24、性能處在可以接受的范圍內，比如經常規定的葉面3秒鐘內響應；概括就是：在性能可以接受的前提下，測試系統可以支持的最大負載。舉例說明：針對一個網站進行測試，模擬10到50個用戶就是在進行常規性能測試，用戶增加到1000乃至上萬就變成了壓力/負載測試。如果同時對系統進行大量的數據查詢操作，就包含了強度測試。19. 主流測試工具的測試流程1.自動化測試工具=loadrunner=1制定負載測試計劃(分析應用程序， 確定測試目標，計劃怎樣執行LoadRunner）2開發測試腳本（錄制基本的用戶腳本，完善測試腳本）3創建運行場景（選擇場景類型為Manual Scenario，選擇場景類型，理解各種類型，場景的類型轉化）4運行測試5監視場景（MEMORY 相關，PROCESSOR相關，網絡吞量以及帶寬，磁盤相關，WEB應用程序