Web 手工測試

day 1

學習目標:

• 熟練搭建本地測試環境
• 掌握熟悉項目的步驟和內容
• 掌握項目基本的測試流程

基礎環境介紹:

項目環境的組成部分:

• 操做系統
  • windows
    • win7
    • win10
  • Linux
    • Centos 6.x,7.x
    • Redhat 6.x,7.x
    • Ubuntu 14.z,16.x,18.x
    • Mac
• web 服務器
  • apache: 穩定,文檔齊全 默認監聽端口:80
  • nginx: 負載均衡器 默認監聽端口:80
  • tomcat:默認監聽端口"8080 ->JAVA
• 數據庫
  • Mysql
  • Oracle
  • Sql Server
  • DB2
• 項目
• LNMP: LINUX+Nginx+Mysql+PHP
• WAMP: Windows+Nginx+Mysql+PHP

擴展: Apache 與 Nginx 的區別:

• apache 與 nginx 都可以做爲web服務器使用
• apche 系統穩定性更強文檔豐富
• nginx 消耗更少的系統資源(如CPU,內存等)
• nginx 更加典型的應用場景是做爲負載均衡器使用

搭建測試環境

• 準備工做

  • phpstudy安裝文件
  • 項目部署包
  • 部署說明書

• 安裝集成環境

  • apache 監聽端口: 80
  • mysql 監聽端口: 3306

• 部署項目

  • 將TPshop 項目壓縮包解壓後文件夾裏的所有內容放入phpstudy安裝路徑\www中

• 常見故障

  • mysql 端口被佔用

  • apache 端口被佔用 :httpd-conf

熟悉項目的步驟:

1. 瞭解項目的業務特性:項目用來作什麼的?
2. 瞭解項目的角色與用戶:項目是給誰用的?
3. 瞭解項目的組織架構圖:項目包括哪些功能模塊?
4. 瞭解項目的技術棧:項目是使用哪些技術實現的?

• 業務特性
• 用戶與角色
• 組織架構圖
• 技術棧

熟悉項目的信息來源

• 文檔
  • 需求文檔
  • 設計文檔,數據庫表設計文檔
  • 測試用例
  • 用戶手冊等
• 環境
  • 開發環境->開發
  • 測試環境->測試環境
  • 線上/生產環境->客戶,運維
• 人
  • 產品經理/項目經理
  • 開發工程師
  • 測試工程師
• 項目中已經存在的文檔: 需求說明書,用戶使用手冊測試用例等
• 試用項目的現有環境:開發環境,測試環境,線上環境
• 詢問項目中的其餘成員:測試組員\組長,開發人員,產品經理等

熟悉Tshop步驟:

• 業務特性:Tshop 是一個開源的電商系統.
• 用戶與角色
  • 前臺
    • 遊客
    • 註冊會員
  • 後臺
    • 超級管理員
    • 倉管員
    • 客服
• 組織架構圖
  • 概念:各系統各元素的組織關係,反映的是各個模塊以及各個模塊的組織關係.
  • 做用
    • 幫助總體理解項目
    • 理解相關業務之間的關聯性
  • 工具:xmind
• 技術棧

測試流程(重點)

• 需求分析與評審
• 編寫測試計劃與測試方案
• 設計測試用例與評審(重點)
• 執行測試用例與缺陷跟蹤(重點)
• 編寫測試報告

SVN服務器設置擴展

• 添加用戶
• 添加用戶組
• 建立倉庫及獲取倉庫地址
• 服務啓動,中止,重啓等基本操做

虛擬機(擴展)

裝虛擬機的容器軟件:

• VMware
• VirtualBos

快照:記錄如今的狀況各類參數配置,方便下次再次使用

• 網絡類型
  • 橋接模式
    • 與外部Inter網絡互通
  • NAT模式
    • 經過主機IP去鏈接外部Inter網絡(單向,外部Inter網是找不到此虛擬機)
  • Host-Only 僅主機模式
    • 與外部Inter 網絡互相不能通信
• 遠程鏈接設置
  • 虛擬機設置容許遠程鏈接
  • 主機輸入mstsc命令啓動本地遠程鏈接
  • 在虛擬機中啓動cmd窗口,而且輸入ipconfig
  • 輸入虛擬機的帳號和密碼

day 2

學習目標

• 需求評審(瞭解)
• 測試計劃與測試方案(瞭解)
• 註冊功能測試用例設計,執行與缺陷跟蹤(重點)
• 輪播圖功能測試用例設計,執行與缺陷跟蹤(重點)
• 購物車功能測試用例設計,執行與缺陷跟蹤(重點)

測試流程

• 需求分析與評審
• 編寫測試計劃與方案
• 設計測試用例與評審
• 執行測試用例與缺陷跟蹤
• 編寫測試報告

軟件需求

爲用戶解決某一問題或達到某一目標所需的軟件功能

爲何須要需求評審

• 保證需求的完整,準確
• 保證團隊對需求理解的一致性

如何作需求評審

• 需求評審會
• 參會人員
  • 項目經理/產品經理
  • 開發工程師,架構師
  • 測試工程師
  • 運維工程師(DEVOPS)
  • UI/UE
  • DBA 數據庫工程師

需求分析->概要設計->詳細設計->編碼->集成->實施->交付

測試V:

單元測試設計->集成測試設計->系統測試設計->驗收測試設計

• 早介入
• 早發現
• 早治療

測試工程師在需求評審中的主要職責是什麼?

• 確認本身對需求要有清晰的理解,沒有疑惑
• 確認需求文檔的完整與正確性,可以知道後期的工做
• 對需求中不合理的地方提出本身的修改意見

在現實工做中很是多的需求邏輯問題都是由測試工程師發現,比提出修正的.

測試方案

概念:從測試的技術角度去分析需求,在方向上明確要怎麼測,分析結果重點在於測試策略於與技術實現

測試方案都包含什麼內容

• 測試策略/測試方法
• 測試環境的規劃
• 測試工具的設計和選擇

TpShop 測試方案 或其餘測試方案獲取

測試計劃與測試方案的區別

• 測試計劃是【管理型】文檔，注重人員、資源，時間的調配；測試方案是【技術型】文檔，注重環境，工具，方法。
• 測試計劃主要解決【作什麼】【誰來作】，測試方案主要解決【怎麼作】
• 主要內容存在差別：
  • 測試計劃主要內容以下
    • 明確的測試目標與測試範圍
    • 執行計劃的角色與職責
    • 任務的進度安排與資源分配
    • 風險估計和應急計劃
    • 測試的各項標準
  • 測試方案主要內容以下：
    • 測試策略/測試方法
    • 測試環境的規劃
    • 測試工具的設計和選擇

註冊功能（重點）

設計測試用例

設計測試用例方法

• 等價類劃分法與邊界值組合

測試用例設計步驟

第一步：需求分析

黑盒測試方法：

• 輸入分析
  • 輸入內容
  • 長度
  • 類型
  • 是否爲空
  • 是否重複
• 處理分析
  • 正常處理
  • 異常處理
• 輸出分析
  • 前臺
  • 後臺

第二部：劃分等價類

執行測試用例與缺陷跟蹤

測試執行

執行步驟:

• 查看用例標題-肯定目標
• 檢查預置前置條件
• 按照步驟執行測試用例
• 實際結果與預期結果進行比對

缺陷跟蹤

• 提交缺陷報告
  • ID
  • 標題
  • 模塊
  • 優先級
  • 嚴重程度
  • 復現步驟
  • 預期結果
  • 實際結果
  • 缺陷狀態
  • 缺陷類型
• 跟蹤缺陷
  • 新建
  • 打開
  • 已修復
  • 關閉
  • 從新打開
  • 拒絕
  • 延期

輪播圖功能(重點)

設計測試用例

設計測試用例方法

• 需求->測試點->測試用例
• 一個測試點就是一條測試用例

測試用例設計步驟

• 第一步：需求分析
• 第二部：劃分等價類
• 第三部：設計測試用例

業務流程測試用例設計（重點）

流程圖基礎知識（複習）

概念：

流程圖：使用形狀和連線來表示業務流程執行順序的一種圖示

流程圖法：它時用流程圖的方式表示用戶的使用場景，經過覆蓋流程的路徑來設計測試用例的一種方法

基本流：用戶的正確操做流程

備選流：用戶的錯誤操做流程

做用：

幫助測試總體理解系統的業務，各個模塊、子模塊在業務上的關聯性

使用階段：

集成測試、系統測試、驗收測試、冒煙測試

經常使用符號：

• 開始或結束：橢圓
• 方向或路徑：箭頭
• 處理或操做：長方形
• 判斷：菱形
• 輸入或輸出：平行四邊形

設計測試用例步驟：

• 需求分析
• 繪製流程圖（分析流程節點、節點的前後順序）
• 設計測試用例（一條流程路徑就是一條測試用例，注意覆蓋流程圖中全部的路徑）

繪製流程圖

繪製步驟：

• 第一步：肯定業務中的操做
• 第二步：分析執行的順序
• 第三步：按照業務方向進行連線

繪製工具：

• Microsoft Visio
• 2003？管理員運行

下單流程

• 登錄
• 選購
• 加入
• 支付
• 等待

Day04

學習目標

• 瞭解測試報告基本內容
• 瞭解非功能測試基礎知識
• 掌握項目與數據庫的關係
• 瞭解項目中數據庫的4種典型應用場景
• 掌握網絡基礎知識（URL、HTML、HTTP、HTTPS）
• Fiddler 經常使用操做，瞭解Fiddler 典型應用場景

編寫測試報告（瞭解）

概念

測試活動的總結性文檔，表只測試活動的結束

主要內容

1. 測試概要
2. 缺陷分析與總結
3. 給出測試結論與建議

非功能性測試

雖未說起，但有不少默認須要實現的具有的

1. 兼容性測試
2. 效率性（性能）
3. 安全性
4. 易用性
5. 可維護性

兼容性測試

概念

在不一樣的軟件環境和硬件環境上都具有很好的可移植性（可以被用戶正常使用）

測試關注點

• Windows
• Linux

瀏覽器

• IE
• 谷歌
• 火狐

注意：實際以客戶需求（客戶現場的真實使用環境）爲準，建議在開發的早期階段（需求分析）就明確相關的需求

分辨率

• 1024*768
• 1920*1024

網絡環境

率性

關注點

訪問項目的時間

測試依據（2-5-10s 法）

• 2s：時間性能很是好
• 2s-5s：用戶還能暫時可以忍受
• 10s：用戶直接中止使用產品

易用性

測試關注點

• 用戶點擊次數：推薦3次達到用戶目的
• Enter 回車事件處理
• 基於特定用戶羣體需求考慮（老人年、兒童等）

可維護性

• 軟件升級過程：停服時間，停服頻率
• 數據庫升級腳本
• 項目代碼的可維護性

安全性

測試關注點

輸入數據的安全性

• 敏感信息的遮擋處理
• 輸入框種敏感信息（密碼）作不能賦值處理

處理數據的安全性（數據傳輸過程當中的安全性）

• 請求方法決定敏感信息不能暴露在地址欄種（推薦用post 請求方式）
• 數據傳輸中須要加密
  • 須要加密
  • 加密算法（複雜度）
    • DES/2DES/AES

輸出數據的安全性

• 數據庫存儲敏感信息須要加密

sql 注入（瞭解）

概念：

主要時利用程序中特殊的 sql 語句漏洞進行非法操做

'or 1=1 #

'or 1=1 --

滲透測試（瞭解）

登錄功能（面試擴展）

功能性測試（功能性需求）

1. 正確輸入用戶名、密碼登錄成功
2. 錯誤用戶名，正確密碼，登錄失敗
3. 正確用戶名，錯誤密碼，登錄失敗
4. 不輸入用戶名，登錄失敗
5. 不輸入密碼，登錄失敗
6. ...

非功能性測試（非功能性需求）

1. 兼容性測試
   1. 操做系統
   2. 瀏覽器
      1. 客戶的需求
   3. 分辨率
   4. 網絡
2. 效率（性能）
   1. 大量用戶訪問系統響應時間測試
3. 安全性
   1. 密碼要遮擋
   2. 密碼不能被複制
   3. 數據庫種存儲時密碼須要加密
   4. 地址欄中不顯示密碼（post）
   5. 傳輸過程當中數據要加密
   6. sql 注入
4. 易用性
   1. 回車
5. 可維護性
   1. 元素定位難題（自動化測試）

項目與數據庫關係（重點）

• 項目中的數據時存儲在數據庫終得
• 對數據庫修改會影響項目頁面顯示

項目測試使用數據庫場景（掌握）

數據庫肯定數據正確

• 執行用例過程當中，有時須要到數據庫驗證數據的準確性與完整性

藉助數據庫進行缺陷定位

• 進行BUG定位時，有時須要到數據庫查看數據的詳細信息

藉助數據庫構造數據場景(須要特定測試數據)

• 構造某種測試場景時，能夠在數據庫裏直接修改數據，要比使用界面更有效率

藉助數據庫數據備份更新

• 軟件升級過程當中，有時會涉及到歷史數據的處理，這種狀況須要執行升級SQL，並驗證結果
  • 數據庫表中增長字段：alter TABle xxx add COLUMN xxxx int(3) DEFAULT 100;

網絡基礎知識

URL

• 名稱：贊成資源定位符
• 格式：協議://主機地址[端口號]/資源路徑
• 默認監聽在80端口,默認端口號能夠省略
• 示例:http://localhost/
• 客戶端:用戶端,好比B/S架構中的瀏覽器,C/S架構中的手機
• 服務器:對外提供web服務或app服務的服務器,解決資源與數據
• 請求:客戶端向服務器索取數據的一種行爲
• 響應:服務器對客戶端的請求作出的反應,通常指返回數據給客戶端

HTML

• 名稱:超文本標記語言
• 超文本:聲音、視頻、超連接等

HTTP

• 名稱：超文本傳輸協議
• 做用：傳輸超文本

請求（request）

請求內容

• 請求行：請求方式，HTTP協議版本吧
• 請求頭：瀏覽器及操做系統信息，支持的語言
• 請求體：傳輸的參數

請求方式（GET 和 POST）

GET

參數信息會直接暴露在URL 中，典型應用場景就是訪問

POST

不會直接將參數信息暴露在url中，它相對比較安全，典型應用場景：登錄、註冊等向服務器提交數據的狀況

面試題：GET 和 POST區別

• GET數將請求參數包含在URL當中，POST經過request body 傳遞參數
• GET 比POST不安全，不能用來傳遞敏感信息
• GET 在瀏覽器退回無害，POST 會再次提交
• GET直接進行URL 編碼，POST 支持多種編碼方式
• GET 請求參數會被完整保留在瀏覽器歷史記錄裏，而POST中的參數不會被保留
• GET請求在URL 中傳送的參數時有長度限制的，而POST 沒有
• 參數類型看:GET 只接受ASCII 字符，而POST 沒有限制

響應（response）

行

• 協議版本
• 狀態嗎
  • 200:成功
  • 3xx:數據路徑發生改變
  • 4xx,客戶端存在問題
    • 404 ：頁面找不到
    • 403 ：權限不夠
  • 5xx:服務器端問題

頭

• web服務器信息
• 項目信息

體

FIddler 的典型應用場景

• 輔助定位bug
• 構建模擬測試場景
• APP 弱網模擬測試
• 前端性能分析及優化
• 其餘用戶。域名重定向，API 接口測試