1.軟生周(SDLC)六階1問題的定義及規劃此階段是軟件開發方與需求方共同討論，主要確定軟件的開發目標及其可行性。2需求分析在確定軟件開發可行的情況下，對軟件需要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段做得好，將為整個軟件開發項目的成功打下良好的基礎。"一不變的是變化本身。"，同樣需求也是在整個軟件開發過程中不斷變化和深入的，因此我們必須制定需求變更計劃來應付這種變化，以保護整個項目的順利進行。3、軟件設計此階段主要根據需求分析的結果，對整個件系統行設計，如系統框架計數據庫設計等。軟件設計一般分為體設計和詳細設計。好的軟件設計將為軟程序編寫下良好的基礎。4程序編碼此階段是將軟件設計的結果轉換成算機可運行的程序代碼。在程序編碼中必須要制定統一，符合標準的編寫規范。以保證程序的可讀性，易維護性，提高程序的運行效率。5軟件測試在軟件設計完成后要經過嚴密的測試，以發現軟件在整個設計過程中存在的問題并加以糾正。整個測試過程分單元測試組裝測試以及系統測試三個階段進行。測試的方法主要有白盒測試和黑盒測試種。在測試過程中需要建立詳細的測試計劃并嚴格按照測試計劃進行測試，以減少測試的隨意性。6運行維護軟件維護是軟件生命周期中持續時間最長的階段。在軟件開發完成并投入使用后，由于多方面的原因，軟件不能繼續適應用戶的要求。要延續軟件的使用壽命，就必須對軟件進行維護。軟件的維護包括糾錯性維護和改進性維護兩個方面。2、軟生命周期模從概念提出的那一刻開始，軟件產品就進入了軟件生命周期。在經歷需求、分析、設計、實現、部署后，軟件將被使用并進入維護階段，直到最后由于缺少維護費用而逐漸消亡。這樣的一個過程，稱為生命周期模型（LifeCycleModel）。典型的幾種生命周期模型包括瀑布模型、快速原型模型、迭代模型。瀑布模型的特（文檔是主體，很多的問題在最后才會暴露出來。迭代模型比瀑布模型問題暴露的要早；快速原型法比瀑布模型直觀。3.件測試概廣義概念：指軟件生存周期中所有的檢查、評審和確認工作，其中包括了對分析、設計階段，以及完成開發后維護階段的各類文檔、代碼的審查和確認狹義概念：識別軟件缺陷的過程，即實際結果與預期結果的不一致標準定義是指使用人工和自動手段來運行或測試某個系統的過程目的在于檢驗其是否滿足規定的需要或弄清楚預期結果與實際結果之間的差別。4.軟測試目

測試的目的就是發現軟件中的各種缺陷測試只能證明軟件存在缺陷，不能證明軟件不存在缺陷測試可以使軟件中缺陷降低到一定程度，而不是徹底消滅以較少的用例、時間和人力找出軟件中的各種錯誤和缺陷，以確保軟件的質量5．軟測試原則

Good-enough:一種權衡投入產出比的原則保證測試的覆蓋程度，但窮舉測試是不可能的所有的測試都應追溯到用戶需求越早測試越好，測試過程與開發過程應是相結合的測試的規模由小而大，從單元測試到系統測試為了盡可能地發現錯誤，應該由獨立的第三方來測試不能為了便于測試擅自修改程序既應該測試軟件該做什么也應該測試軟件不該做什么6．軟測試的的重測試用例的設計–測試用例的設計是整個軟件測試工作的核心–測試用例反映對被測對象的質量要求，決定對測試對象的質量評估測試工作的管理–尤其是對包含多個子系統的大型軟件系統，其測試工作涉及大量人力和物力，有效的測試工作管理是保證有效測試工作的必要前提測試環境的建立–測試環境應該與實際測試環境一致7．黑測試什么是黑盒測試–又稱功能測試或數據驅動測試，是針對軟件的功能需求實現進行測試，通過測試來檢測每個功能是否符合需求，不考慮程序內部的邏輯結構黑盒測試方法–功能劃分–等價類劃分–邊界值分析–因果圖–錯誤推測等8．什是白盒測試–白盒測試也稱結構測試或邏輯驅動測試，必須知道軟件內部工作過程，通過測試來檢測軟件內部是否按照需求、設計正常運行–白盒測試的主要方法–對應于程序的一些主要結構：語句、分支、邏輯路徑、變量；白盒測試的主要方法是：–語句覆蓋方法–分支覆蓋方法–邏輯覆蓋方法9.什么是態測試動態測試需要在開發/測試環境或實際運行環境中運行軟件，并使用測試用例去查找軟件缺陷；動態測試包括功能確認與接口測試、覆蓋率分析、性能分析、內存分析等10.什么靜態測靜態測試不實際運行軟件，主要是對軟件的編程格式、結構等方面進行評.靜態測試包括代碼檢查、程序結構分析、代碼質量度量等。它可以由人工進行，也可以借助軟件工具自動進行11.手工試和自測試手工測試缺點在于測試工作量大，重復多，回歸測試難以實現自動測試利用軟件測試工具自動實現全部或部分測試工作：管理、設計、執行和報告；節省大量的測試開銷，并能夠完成一些手工測試無法實現的測試手工完成測試的全部過程無法保證測試的科學性與嚴密性–修改的缺陷越多，回歸測試越困難–沒有人能向決策層提供精確的數據以度量當前的工作進度及工作效率–反復測試帶來的倦怠情緒及其他人為因素使得測試標準前后不一–測試花費的時間越長，測試的嚴格性也就越低自動測試將測試人員從反復、煩雜的測試執行中解放出來，用更多的時間進行測試設計和結果分析

軟件測試不可能完全自動化不能完成所有手工測試任務無創造性且靈活性差，不能改進測試的有效性過程中可能會遇到許多意想不到的問題，特別是當軟件不穩定時測試腳本的維護高12.測試程

單元測試集成測試系統測試用戶驗收測試回歸測試需分確測計（明）系測計（明）概設集測計（明）詳設單測計編

確測報系測報系/認試集測報集測單測報單測確定測試要求制測試計劃有修改雙方確定測試劃通過制定測方案安排項進度培訓測試人員建立測試環境編寫測試用例執行測試計劃未完成檢測并在數據中記錄缺陷

完否

是回歸測試否測報告填寫

向戶提交缺陷列表客

戶

開發人員修正誤13.單元試完成對最小的軟件設計單元模塊的驗證工作

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

根據軟件需求規范的要求進行系統測試，確認系統滿足需求的要求系統測試人員相當于用戶代言人在需求分析階段要確定軟件的可測性，保證有效完成系統測試工作系統測試主要內容所有功能需求得到滿足所有性能需求得到滿足其他需求（例如安全性、容錯性、兼容性等）得到滿足16.用戶收/確認測試測試–是由用戶在開發者的場所來進行的，試是在一個受控的環境中進行的測試–由軟件的最終用戶在一個或多個用戶場所來進行的，開發者通常不在現場，用戶記錄測試中遇到的問題并報告給開發者17．力測試能測試性能測試的目的不是去找bugs,是排除系統的瓶頸，以及為以后的回歸測試建立一個基準。而性能測試的操作，實際上就是一個非常小心受控的測量分析過程。在理想的情況下，被測軟件在這個時候已經是足夠穩定了性能測試是為了檢查系統的反映，運行速度等性能指標，他的前提是要求在一定負載下，如檢查一個網站在100人同時在線的情況下的性能指標，每個用戶是否都還可以正常的完成操作等。概括就是：在不同負載下（負載一定）時，通過一些系統參數（如反應時間等）檢查系統的運行情況；壓力測試是為了發現系統能支持的最大負載，他的前提是要求系統性能處在可以接受的范圍內，比如經常規定的葉面3秒鐘內響應；概括就是：在性能可以接受的前提下，測試系統可以支持的最大負載。舉例說明：針對一個網站進行測試，模擬10到50個用戶就是在進行常規性能測試，用戶增加到1000乃至上萬就變成了壓力/負載測試。如果同時對系統進行大量的數據查詢操作，就包含了強度測試。18.主流測試工的測試流========winrunner啟動時選擇要加載的插件進行一些設置（如錄制模式等）識別應用程序的，即創建map(就是學習被測試軟件的界面）建立測試腳本（錄制及編寫）對腳本除錯及調試（保證能夠運行完）插入各種檢查點（圖片，文字，控件等）在新版應用程序中執行測試腳本分析結果，回報缺陷=========quicktestpro========1準備錄制打開你要對其進行測試的應用程序，并檢查中的各項設置是否適合當前的要求。2進行錄制打開QuickTest的錄制功能，按測試用例中的描述，操作被測試應用程序。3編輯測試腳本通過加入檢測點、參數化測試，以及添加分支、循環等控制語句，來增強測試腳本的功能，使將來的回歸測試真正能夠自動化。4調試腳本調試腳本，檢查腳本是否存在錯誤。5在回歸測試中運行測試在對應用程序的回歸測試中，通過QuickTest放對應用程序的操作，檢驗軟件正確性，實現測試的自動化進行。6分析結果，報告問題查看QuickTest記錄的運行結果，記錄問題，報告測試結果。＝＝＝＝安裝好后，先進入站點管理創建域及工程添加用戶編輯licenses及本服務器編輯數據庫－－TD選擇新建的工程進行定制(列表，用戶，組，版本等)在require中增加需求把需求轉化為plan在testlab中由計劃新建測試具體用例與執行發現bug，在defect中提交bug（每一部分都可以相對獨立地使用）======loadrunner1制定負載測試計劃(分析應用程序，確定測試目標，計劃怎樣執行）2開發測試腳