歡迎使用CSDN-markdown編輯器

1. 軟件生命週期(SDLC)的六個階段
1、問題的定義及規劃
此階段是軟件開發方與需求方共同討論,主要確定軟件的開發目標及其可行性。
2、需求分析
在確定軟件開發可行的情況下,對軟件需要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段,這一階段做得好,將爲整個軟件開發項目的成功打下良好的基礎。”唯一不變的是變化本身。”,同樣需求也是在整個軟件開發過程中不斷變化和深入的,因此我們必須制定需求變更計劃來應付這種變化,以保護整個項目的順利進行。
3、軟件設計
此階段主要根據需求分析的結果,對整個軟件系統進行設計,如系統框架設計,數據庫設計等等。軟件設計一般分爲總體設計和詳細設計。好的軟件設計將爲軟件程序編寫打下良好的基礎。
4、程序編碼
此階段是將軟件設計的結果轉換成計算機可運行的程序代碼。在程序編碼中必須要制定統一,符合標準的編寫規範。以保證程序的可讀性,易維護性,提高程序的運行效率。
5、軟件測試
在軟件設計完成後要經過嚴密的測試,以發現軟件在整個設計過程中存在的問題並加以糾正。整個測試過程分單元測試、組裝測試以及系統測試三個階段進行。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計劃並嚴格按照測試計劃進行測試,以減少測試的隨意性。
6、運行維護
軟件維護是軟件生命週期中持續時間最長的階段。在軟件開發完成並投入使用後,由於多方面的原因,軟件不能繼續適應用戶的要求。要延續軟件的使用壽命,就必須對軟件進行維護。軟件的維護包括糾錯性維護和改進性維護兩個方面。
2、軟件生命週期模型
從概念提出的那一刻開始,軟件產品就進入了軟件生命週期。在經歷需求、分析、設計、實現、部署後,軟件將被使用並進入維護階段,直到最後由於缺少維護費用而逐漸消亡。這樣的一個過程,稱爲”生命週期模型”(Life Cycle Model)。
典型的幾種生命週期模型包括瀑布模型、快速原型模型、迭代模型。
瀑布模型的特點(文檔是主體),很多的問題在最後纔會暴露出來。迭代模型比瀑布模型問題暴露的要早;快速原型法比瀑布模型直觀。
3.軟件測試概念
廣義概念:指軟件生存週期中所有的檢查、評審和確認工作,其中包括了對分析、設計階段,以及完成開發後維護階段的各類文檔、代碼的審查和確認
狹義概念:識別軟件缺陷的過程,即實際結果與預期結果的不一致
4.軟件測試目的
 測試的目的就是發現軟件中的各種缺陷
 測試只能證明軟件存在缺陷,不能證明軟件不存在缺陷
 測試可以使軟件中缺陷降低到一定程度,而不是徹底消滅
 以較少的用例、時間和人力找出軟件中的各種錯誤和缺陷,以確保軟件的質量
5.軟件測試原則
 Good-enough: 一種權衡投入/產出比的原則
 保證測試的覆蓋程度,但窮舉測試是不可能的
 所有的測試都應追溯到用戶需求
 越早測試越好,測試過程與開發過程應是相結合的
 測試的規模由小而大,從單元測試到系統測試
 爲了儘可能地發現錯誤,應該由獨立的第三方來測試
 不能爲了便於測試擅自修改程序
 既應該測試軟件該做什麼也應該測試軟件不該做什麼
6.軟件測試的的重點
 測試用例的設計
– 測試用例的設計是整個軟件測試工作的核心
– 測試用例反映對被測對象的質量要求,決定對測試對象的質量評估
 測試工作的管理
– 尤其是對包含多個子系統的大型軟件系統,其測試工作涉及大量人力和物力,有效的測試工作管理是保證有效測試工作的必要前提
 測試環境的建立
– 測試環境應該與實際測試環境一致
7.黑盒測試
 什麼是黑盒測試
– 又稱功能測試或數據驅動測試,是針對軟件的功能需求/實現進行測試,通過測試來檢測每個功能是否符合需求,不考慮程序內部的邏輯結構
 黑盒測試方法
– 功能劃分
– 等價類劃分
– 邊界值分析
– 因果圖
– 錯誤推測等
8.什麼是白盒測試
– 白盒測試也稱結構測試或邏輯驅動測試,必須知道軟件內部工作過程,通過測試來檢測軟件內部是否按照需求、設計正常運行
– 白盒測試的主要方法
– 對應於程序的一些主要結構:語句、分支、邏輯路徑、變量;白盒測試的主要方法是:
– 語句覆蓋方法
– 分支覆蓋方法
– 邏輯覆蓋方法
9. 什麼是動態測試
動態測試需要在開發/測試環境或實際運行環境中運行軟件,並使用測試用例去查找軟件缺陷;動態測試包括功能確認與接口測試、覆蓋率分析、性能分析、內存分析等
10.什麼是靜態測試
靜態測試不實際運行軟件,主要是對軟件的編程格式、結構等方面進行評估.靜態測試包括代碼檢查、程序結構分析、代碼質量度量等。它可以由人工進行,也可以藉助軟件工具自動進行
11.手工測試和自動測試
a.手工測試缺點在於測試工作量大,重複多,迴歸測試難以實現
b.自動測試利用軟件測試工具自動實現全部或部分測試工作:管理、設計、執行和報告;節省大量的測試開銷,並能夠完成一些手工測試無法實現的測試
 手工完成測試的全部過程無法保證測試的科學性與嚴密性:
– 修改的缺陷越多,迴歸測試越困難
– 沒有人能向決策層提供精確的數據以度量當前的工作進度及工作效率
– 反覆測試帶來的倦怠情緒及其他人爲因素使得測試標準前後不一
– 測試花費的時間越長,測試的嚴格性也就越低
 自動測試將測試人員從反覆、煩雜的測試執行中解放出來,用更多的時間進行測試設計和結果分析
 軟件測試不可能完全自動化
 不能完成所有手工測試任務
 無創造性且靈活性差,不能改進測試的有效性
 過程中可能會遇到許多意想不到的問題,特別是當軟件不穩定時
 測試腳本的維護高
12. 測試流程
 單元測試
 集成測試
 系統測試
 用戶驗收測試
 迴歸測試
13.單元測試
 完成對最小的軟件設計單元—模塊的驗證工作
 目標是確保模塊被正確地編碼
 使用過程設計描述作爲指南,對重要的控制路徑進行測試以發現模塊內的錯誤
 通常情況下是面向白盒的
 對代碼風格和規則、程序設計和結構、業務邏輯等進行靜態測試,及早地發現和解決不易顯現的錯誤
 單元測試的內容
– 接口測試
– 內部數據結構
– 全局數據結構
– 邊界
– 語句覆蓋,錯誤路徑
14.集成測試
 通過測試發現與模塊接口有關的問題
 目標是把通過了單元測試的模塊拿來,構造一個在設計中所描述的程序結構
 應當避免一次性的集成(除非軟件規模很小),而採用增量集成
集成測試主要內容
 API
 API/參數組合
15.系統測試
 根據軟件需求規範的要求進行系統測試,確認系統滿足需求的要求
 系統測試人員相當於用戶代言人
 在需求分析階段要確定軟件的可測性,保證有效完成系統測試工作
 系統測試主要內容
 所有功能需求得到滿足
 所有性能需求得到滿足
 其他需求(例如安全性、容錯性、兼容性等)得到滿足
16.用戶驗收/確認測試
 Alpha測試
– 是由用戶在開發者的場所來進行的,Alpha測試是在一個受控的環境中進行的
 Beta測試
– 由軟件的最終用戶在一個或多個用戶場所來進行的,開發者通常不在現場,用戶記錄測試中遇到的問題並報告給開發者
17.壓力測試VS性能測試
性能測試的目的不是去找bugs,而是排除系統的瓶頸,以及爲以後的迴歸測試建立一個基準。而性能測試的操作,實際上就是一個非常小心受控的測量分析過程。在理想的情況下,被測軟件在這個時候已經是足夠穩定了
性能測試是爲了檢查系統的反映,運行速度等性能指標,他的前提是要求在一定負載下,如檢查一個網站在100人同時在線的情況下的性能指標,每個用戶是否都還可以正常的完成操作等。
概括就是:在不同負載下(負載一定)時,通過一些系統參數(如反應時間等)檢查系統的運行情況;
壓力測試是爲了發現系統能支持的最大負載,他的前提是要求系統性能處在可以接受的範圍內,比如經常規定的葉面3秒鐘內響應;概括就是:在性能可以接受的前提下,測試系統可以支持的最大負載。
舉例說明:針對一個網站進行測試,模擬10到50個用戶就是在進行常規性能測試,用戶增加到1000乃至上萬就變成了壓力/負載測試。如果同時對系統進行大量的數據查詢操作,就包含了強度測試。
18. 主流測試工具的測試流程
========winrunner
1 啓動時選擇要加載的插件
2 進行一些設置(如錄製模式等)
3 識別應用程序的GUI,即創建map(就是學習被測試軟件的界面)
4 建立測試腳本(錄製及編寫)
5 對腳本除錯及調試(保證能夠運行完)
6 插入各種檢查點(圖片,文字,控件等)
7 在新版應用程序中執行測試腳本
8 分析結果,回報缺陷
 
=========quicktestpro========
1 準備錄製
打開你要對其進行測試的應用程序,並檢查QuickTest中的各項設置是否適合當前的要求。
2 進行錄製
打開QuickTest的錄製功能,按測試用例中的描述,操作被測試應用程序。
3 編輯測試腳本
通過加入檢測點、參數化測試,以及添加分支、循環等控制語句,來增強測試腳本的功能,使將來的迴歸測試真正能夠自動化。
4 調試腳本
調試腳本,檢查腳本是否存在錯誤。
5 在迴歸測試中運行測試
在對應用程序的迴歸測試中,通過QuickTest回放對應用程序的操作,檢驗軟件正確性,實現測試的自動化進行。
6 分析結果,報告問題
查看QuickTest記錄的運行結果,記錄問題,報告測試結果。

====TestDirect============
安裝好後,先進入站點管理
1 創建域及工程
2 添加用戶
3 編輯licenses及本服務器
4 編輯數據庫
--TD
1 選擇新建的工程進行定製(列表,用戶,組,版本等)
2 在require中增加需求
3 把需求轉化爲plan
4 在testlab中由計劃新建測試具體用例與執行

5 發現bug,在defect中提交bug
(每一部分都可以相對獨立地使用)

======loadrunner
1 制定負載測試計劃
(分析應用程序, 確定測試目標,計劃怎樣執行LoadRunner)
2 開發測試腳本
(錄製基本的用戶腳本,完善測試腳本)
3 創建運行場景
(選擇場景類型爲Manual Scenario,選擇場景類型,理解各種類型,場景的類型轉化)
4 運行測試
5 監視場景
(MEMORY 相關,PROCESSOR相關,網絡吞量以及帶寬,磁盤相關,WEB應用程序 ,IIS5.0,SQL SERVER,NETWORK DELAY等)
6 分析測試結果
(分析實時監視圖表,分析事務的響應時間,分解頁面,確定WEBSERVER的問題,其他有用的功能)

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章