Please enable JavaScript.

Coggle requires JavaScript to display documents.

Guru Testing, Test Document, Agile Testing - Coggle Diagram

- - - - Test Form
        
        當User沒填入必填欄位是否會彈出Error msg
        
        確認Default值是否被顯示
        
        送出資料時是否成功送到DB
        
        是否在閱讀可以更優化
      - Test Cookie
        
        測試Cookie當Cache已清除 or 已過期
        
        登入後當要訪問下個page刪除cookie
      - Test Link
        
        Test Link 測試所有Link是否可運作
      - Test HTML and CSS
        
        Readable Color Schemas
        
        Standard Compliance. Ensure standards such W3C, OASIS,
      - Test Business
        
        測試end to end的情境與workflow
        
        測試負面的情境,例如當user操作非預期的步驟,相對應的error msg or help 應該會被顯示在系統上
  - - - 像menu, 按鈕,或者link 到不同頁面應該在webpage上容易看到
    - - 看內容是否有拼字或文法錯誤
      - 圖片是否應該有包含’’alt’的字樣
  - - - 測試request有成功被送到Database,而且outputu有在client端顯示正確. 如果有error應該要被抓出顯示在administrator而不是在end user
    - - 確保query送到DB有得到對應的結果
    - - 測試Web service應該處理所有request
  - - - Vulnerability Scanning
        
        利用自動化軟體去做scan 一些常見的漏洞
      - Security Scanning
        
        確認檢測出網路或系統上的weaknesses,並提供solution去減少這些風險,此類的scanning有手動和自動
      - Penetration testing(滲透測試)
        
        模擬惡意的hacker去攻擊測試你的系統,並確認是否有淺在地security risk
      - Risk Assessment
        
        security risk進行分析, 並且將這些分類成Low,Medium and high,並可衡量這些risk是否有大的影響
        
        類似像 Thread modeling
        
        驗證是否有儲存客戶敏感的資料
      - Security Auditing
        
        此測試可藉由一行一行檢查code來確認
      - Ethical hacking
        
        由一群不是惡意hacker 來做測試,並回報相關的report
    - - 一開始需求分析就可以先做Risk assessment
      - 到Coding, Unit Testing階段可以進行Static and Dynamic Scanning testing
      - 到System Testing 可加入 Vulnerability Scanning
- - - - 從測試的角度去研讀及判斷requirment的可測試性,
      - 與PM StandHolder討論需求
    - - 決定要做哪些testing type
      - 準備Requirement Traceability Matrix (RTM).
      - 決定要用幾個測試環境
    - - RTM
  - - - 是由QA manger去決定根據現有的成本效益來決定Test Strategy
    - - 準備Test Plan/Strategy 文件
      - Testing Tool選擇
      - Test effort estimation
      - 相關資源規劃與評估
    - - Test plan /strategy document
  - - - 開始新增Test Case, Test Script並做Review驗證
    - - 建立test case測試案例,與自動化script
      - Review 測試案例與script
      - 建立測試資料
    - - Test Case/Script
      - Test Data
  - - - 測試環境建置,可與Test Case Dev階段一起
    - - 準備測試環境與測試資料
      - 提供Smoke Test
    - - 環境Ready
      - Smoke Test Result
  - - - 進行Script測試,維護Script及Bug回報
    - - 根據Test Plan做測試
      - 測試結果文件與相關Defect回報
      - Map Defect to TestCase in RTM
    - - 測試結果報告
      - Defect 報告
  - - - 根據測試結果分析是否有需改善的或者建議
    - - Retrospetive
- - - - 分類過去專案常發生Fail的問題類別
      - 根據這些問題做RootCause分析
      - 找出Risk 及developer想法產生TestCase
    - - what to test
      - How it can be tested
      - What needs to be looked
      - 主要助於確認end user如何使用此系統
    - - 包含一對測試人員相處不能小於90 min
      - 在這90分鐘當中不得中斷
      - Time box可延長或者縮短到45min
    - - 評估defect
      - 從測試中學到東西
      - 分析coverage 的區塊
  - - - 能在requirement doc還沒完成前做
      - 採用investiation procees比一般的測試流程發現更多bug
      - 透過執行越來越多的testcase來擴展測試人員的想像並且改善生產力
      - 深入到系統最小部分並涵蓋到所有需求
      - 涵蓋所有測試類別而且涵蓋各式的測試情境
      - 執行測試時產生新的idea
    - - 此測試完全取決於測試人員的技能
      - 不適合長時間的執行
      - .被測試人員的認知給限制住
- - - - 白箱測試
      - Advantage
        
        提早找到Bug並修復,測試向左移
        
        確保每個Function的本質就算有變動,有Unit test做Regress testing做驗證,遇到問題就可以快速找到
        
        沒有依賴性,不像Integration testing需要等其他因素
      - TDD
        
        在開發前寫測試,以確保程式碼品質符合需求
      - BDD
        
        比較偏向系統功能與Business Logic的自動化測試
        
        GIven, When, Then
      - Disadvantage
        
        花蠻多時間成本
        
        難找到System integrate上的問題
      - 測試軟體單一unit or componet,每一Unit可能為function, module, method....
      - Test Individual Component
    - - 主要是module and module 之間的測試,單一module測試可能沒問題,但整合起來就有
        
        例如手電筒有包含很多unit module,燈泡,開關,手把,電池等等, 有個case測試打開開關有沒有亮,這就是Integrate testing
      - Best Practice
        
        確定測試策略
        
        了解服務架構,並瞭解哪些是重要的module,哪些需要先被測試
      - Test Integrated Component
    - - 黑箱測試Black Testing
      - Test the Entire System
    - - beta testing of the product done by the actual end users
    - - 可用於剛開始初期Builf較不穩定時
      - 驗證軟體較重要的功能是否能正常work,
      - 常用於Regress Testing來確認主要功能是否有被影響或覆蓋
      - 通過之後才會過Functional Testing
      - 每次出Build都要先跑過Smoke Testing 再來Sanity Testing
    - - 用於相關Build已經穩定
      - 當有new Build or 功能,確認那些Bug or issue已經fix,不希望修這個Bug產生另外個Bug
    - - 在上Prod release前做的End user測試
      - 目的是要驗證end to end的商業邏輯流程
      - Why
        
        有可能RD按照自己邏輯去開發
        
        需求改變時沒有有效率跟RD溝通產生誤會
      - Test Final System
  - - - 保證不會影響服務及Requirment不會變動
      - vs. ReTesting
        
        目的再一次測試功能或者bug,並確保程式是被修復的
      - 挑戰
        
        成功的Regress Testing 會有大量的Test suite,
        
        用最小量的Test suite覆蓋大量的Coverage
      - 目的是確認每次Code變動不會有 Side effect
  - - - Security
        
        如何handle從內部或外部進行攻擊
        
        Security Testing
      - Reliability
        
        :Reliability Testing
        
        確保在長時間下滿足目標及不會有bug
      - Availability
        
        Stability Testing.
      - Usability
        
        Usability Testing
      - Scalability
        
        驗證當有需求時系統能夠自動擴增
        
        Scalability Testing
      - Performance Testing
- - - - 沒有任何書面Spec資料,測試案例,預期期望值等等,單純靠著經驗及知識來對軟體功能及效能做測試
    - - 隨便輸入數值來確認服務行為是否有異常或Crash
    - - Test Case為全新且至今尚未跑過首度蹭社
      - 需求一直頻繁在改變
      - 對某些臨時或暫時的需求做測試
  - - - High Risk- Business Critical test cases
      - Test cases that are repeatedly executed
      - Test Case難以用手動測試做
      - Test Cases which are time-consuming
    - - 測試工具選擇
      - 定義測試範圍與Scope
      - 準備設計與開發
      - 執行測試
      - 維護
    - - Data Driven
        
        Data is not Hard-coded in the test scrip
      - Keywork Driven
        
        包含像 Login, Logout..
      - Modular Automation
        
        找出就常用的Flow,例如Login to Logout,把Flow變成function存在file讓test script去做呼叫
      - Hybrid
        
        可根據需求去組合以上的framework feature
    - - 建立一致的Script comment
      - 有足夠的Expecption Handling
      - 相關的Log訊息要明白清楚,包含Info Log, Error Log..
- - - - 黑箱測試不知道系統或服務內部架構邏輯
      - 可被應用於軟體測試的各個level:unit, integration, system, and acceptance Testing
      - 不知內部任合code的情況下
      - 主要由End User Developer or 測試人員執行
      - 俗稱 Behavioral Testing
      - 舉個例子：你測試一個website, google好了,你不需要知道內部的程式邏輯,你只要input資料,並且看output是不是符合你預期的
  - - - 確認系統內部的功能性
      - low-level 測試
      - 測試是基於code coverage(包含code statements, branches, paths or conditions.)
      - 包含 Unit Testing, Integration Testing,主要是由測試人員或developer來執行
      - 目標是要驗證服務的working flow, 會先提前define input 及output 來做測試
    - - Statement Coverage
      - Branch Coverage
      - Decision Coverage
    - - 優點
        
        發現隱藏的error使code更佳化
        
        白箱測試case可以較自動化
        
        通常涵蓋所有code路徑,所以測試會更加徹底
        
        當GUI還沒ready時,測試可以跟SDLC一樣早開始
      - 缺點
        
        非常複雜及花成本(包含時間)
        
        需要很詳細知道程式的執行與邏輯
- - - - tester 藉由business requirement doc 來做測試確認
    - - 藉由自動化工具可以完成此部分
    - - model 是一個用圖形來敘述系統的behavior,可方便讓我們可以更快瞭解系統的行為,並且能有效率的產生testcase,
- - - - Minimum
      - Just above the minimum
      - A nominal value
      - Maximum
      - Just below the maximum
    - - Input condition is valid between 1 to 10
        Boundary values 0,1,2 and 9,10,11
  - - - 可歸類四種測試情境
        
        數入數量>10 (e.g11) 應該會顯示訂購失敗的訊息
        
        輸入數量<1 (e.g. 0) 應該會顯示訂購失敗的訊息
        
        輸入數量（1-10）應該會顯示訂購成功的訊息
        
        輸入三位數的數量(e.g 100) 應該會顯示訂購失敗的訊息
- - - - Test Case 1: Check results on entering valid User Id & Password
      - Test Case 2: Check results on entering Invalid User ID & Password
      - Test Case 3: Check response when a User ID is Empty & Login Button is pressed, and many more
  - - - test case建立完後應被team member review
    - - 不管誰執行此test case,應該都要產生一樣的結果
    - - Boundary Value Analysis (BVA)->值的變化
- - - - Critical
        
        The defect that need to be fixed immediately because it may cause great damage to the product
      - High
        
        The defect impact the product's main features
      - Medium
        
        The defect causes minimal deviation from product requirement
      - Low
        
        The defect has very minor affect product operation
  - - - ( defect rejected/ total defect raised) *100
      - e.g 例如回報84個defect但實際64個才是defect,所以DRR is 20/84 = 0.238 (23.8 %).
    - - (number defect missed//total defect of software) *100
      - DRR and DLR越小表示 test execution 品質越好