-
測試
查看全部 -
3-2 軟件測試類型-性能測試
查看全部 -
2-2 軟件測試手段
查看全部 -
2-1軟件測試階段
需要學習jUnit測試可搜以下課程：
查看全部 -
1-1軟件測試概要
查看全部 -
＊
敏捷測試
查看全部 -
測試遵循原則
- 二八原則 80%時間用在20%的重點模塊上
- 測試活動依賴于測試背景
- 測試顯示缺陷的存在，但不能證明系統不存在缺陷
- 窮盡測試是不可能的，應該盡可能的設定及時終止的條件
- 測試應盡早進行
- 缺陷具備群集特性
- 殺蟲劑悖論 同樣的用例和方法無法再發現新的問題 行不定期修改，評審
查看全部 -
- 測試的二八原則
查看全部 -
Script-based Testing
Script Testing（ST）
查看全部 -
Linux 命令怎么使用?
查看全部 -
單元測試，集成測試查看全部
-
定義：軟件本身的兼容性（對歷史版本的配置或數據兼容）
??????????不同平臺下的兼容性（ubuntu centos redhat等）
????????? ?運行設備的兼容性（32位的 平板電腦 小型機等）????????? ?軟件的互操作性（與一些主流的應用是否兼容）
瀏覽器內核
瀏覽器兼容性測試工具
Browsershots browsersandbox Google瀏覽器兼容性測試插件（頁面代碼層面測試）
查看全部 -
定義：對軟件產品進行測試以確保符合產品安全需求和質量標準
滲透測試：通過模擬對軟件系統的惡意攻擊行為來評估系統安全性的一種測試（取得了用戶的授權）
安全測試vs安全測試
滲透測試：攻 、薄弱點
安全測試：防 、面、難度高
OWASP：Open Web Application Security Project（開放web應用安全項目）
前10名的漏洞問題：
注入：腳本或sql注入 頁面輸入構造
失效的身份漏洞或身份管理
跨站腳本：使用戶瀏覽器能執行動態的內容
不安全的對象的直接引用：在url中修改參數
安全配置錯誤：如框架、服務有默認密碼
敏感信息泄露：沒對關鍵信息加密
功能級別的訪問控制缺失：能夠導航到用戶沒有權限的地方
跨站請求偽造：外部的一個惡意的網站獲取到正常的數據
使用了已知的有漏洞的組件：沒有及時打補丁
未被驗證的重定向或轉發：重定向沒有沒驗證 可以被黑客轉移到釣魚網站
安全測試工具：
Appscan（Web 應用）
Webinspect
Nessus（服務器 主機類）
Nmap
MetaSploit（著名攻擊軟件）
WebScarab
Fortify（源代碼靜態分析）
W3AF（Web應用）
查看全部 -
敏捷測試
Agile Testing
宣言：強調了個體的溝通重于過程，對于軟件看重結果輕文檔，客戶視角與客戶合作創造更多的價值，擁抱變化
特點：
強調從客戶的角度測試
重點關注迭代測試新功能，不在強調測試階段
盡早測試，不間斷測試，具備條件即測試
強調持續反饋
預防缺陷重于發現缺陷（給整個研發提出建設性的意見，質量改進的建議，全方位的參與到軟件研發的各個層面，提升整個團隊的工作效率和保證產品質量）
與傳統測試的區別：
傳統測試是質量的最后保護者；開發和測試人員是緊密合作的，大家都有責任對軟件負責
傳統測試有嚴格的變更管理；變更是可接受的，擁抱變更
預先的計劃和細節的準備（測試計劃、測試方案、測試用例、規程文檔）；敏捷計劃隨著進展時常調整；
重量級文檔；只需要絕對必要的文檔
各個階段測試嚴格的入口與出口標準；各迭代之間已經沒有明顯的入口與出口標準
更多在回歸測試時進行重量級的自動化測試；所有階段都需要自動化測試，每個人都需要做
嚴格依賴流程執行；流程不再需要嚴格執行（注重測試結果，規則就是被打破的）
測試團隊和開發團隊是相互獨立的；團隊合作是無縫隙的合作（整個測試持續不斷的質量反饋的過程，從研發生命周期的開始，就把測試過程中的問題持續不斷的反饋給我們的開發人員、項目經理，及時知曉研發過程中的質量現狀并且及時的進行改正）
基于腳本的測試-SBT
Scripted Testing(ST)
Exploratory Testing（探索式測試）：
完全拋開測試腳本的測試 探索被測系統，帶著問題使用系統，在探索的過程中發現測試要點，找出被測系統的問題，在測試過程中測試設計和測試執行是并行的，更自由；
它是一種測試風格、思維而不是一種測試技術
局部探索式測試：
輸入：接收輸入 產生輸出 存儲數據 進行運算 輸入順序 輸出內容 輸出異常
狀態：臨時狀態（運行時有效 階段性有效） 永久狀態（數據庫保存 文件保存）
代碼路徑：對代碼的覆蓋率
用戶數據：模擬真實用戶數據
執行環境：軟件運行的操作系統 網絡拓撲 三方系統 系統的配置數據 硬件設備
全局探索式測試：
像游客游覽一樣測試系統
商業區：軟件從啟動到關閉用戶可能使用到的一些功能
旅館區：軟件在沒有運行時的功能如定時任務、一些后臺進程
歷史區：歷史遺留的功能
旅游區：新用戶使用或關注的功能（新手指引等）
娛樂區：輔助功能
破舊區：隱藏或遺棄的功能，用戶看不到
執行探索式測試：
Konw You Mession：了解測試任務的重點 主要測試方向 系統的環境
Learnging Session：詳細學習和探索被測系統 業務邏輯 系統功能
Coverage? Session：測試執行階段 完成測試點的覆蓋
Deep Session：更深入的發散式的測試
Close Session：總結 整理 復盤階段
基于風險的測試-RBT
Risk-based Testing
風險：
質量風險（功能 易用性 性能 軟件功能缺失 數據的轉換）
管理風險（人員的技能不足 人力不足 測試環境不具備 被測系統的需求不夠清晰 三方系統有問題等）
風險級別：風險的可能性*風險的嚴重度
識別風險：
可能性：復雜性（越復雜風險越大）時間壓力 高變更率 技能水平 地理分散度（研發團隊太分散 集成上有潛在的問題）
嚴重程度：使用頻率 失效可視性 商業損失（支付功能 計費功能） 組織負面影響和損害 社會損失和法律責任
優點：優先測試的都是高風險的部分 對質量信心的提升非常明顯
基于模型的測試-MBT
查看全部 -
按軟件測試模式來分類
1、瀑布模型
項目計劃：制定研發計劃，確定里程碑節點，輸出項目計劃書
需求分析：明確用戶的需求定義，并對定義進行清晰的描述，充分理解客戶需求明確產品功能，輸出需求規格說明書
軟件設計：根據需求確定產品實現的方案，概要設計、詳細設計的多個文檔
程序開發
軟件測試：獨立的測試的小組，評估產品是否滿足需求，輸出測試報告
集成維護：根據用戶使用情況對產品進行修改
優點：強調需求、設計的作用；前一階段完成后。只需關注后續階段；為項目提供了按階段劃分的檢查點，里程碑清晰；文檔規范
缺點：難以適應需求的頻繁變化；項目周期后段才能看到成果；強制里程碑、完成時間點；文檔工作量大
沒有體現出測試的地位和價值，測試階段只是補救的階段，缺陷發現太晚，修改成本高
2、V模型
使用最廣泛的模型
明確表明了測試過程的不同階段，描述了測試階段與開發階段的對應關系
單元測試、集成測試：檢測程序是否滿足設計上的要求
系統測試：軟件在功能、性能上是否滿足系統要求的指標
驗收測試：是否滿足用戶的要求和合同的標準
在V模型里強調了軟件開發的協作和速度，反應測試活動和分析設計的關系，并且將軟件的實現和驗證有機的結合起來。
局限性：僅僅把測試過程作為在編碼后面的階段，需求和系統設計的驗證只能在驗收測試中發現
3、W模型
V模型的改進模型
測試伴隨整個開發周期，對需求和設計都全面測試，有利于盡早的發現問題
及時了解項目風險
局限性：開發與測試仍然是線性關系
4、X模型
5、H模型
將測試流程看成是一個獨立的模型，與軟件其他流程并發進行
查看全部
舉報