宝贝打开点我要尿里面h,樱桃视频高清免费观看在线播放,再深点灬舒服灬太大了老师

Day 6 測試報告講義

0 主要內容

1 T4_測試結項報告
2 P2_敏捷項目流程
3 P3_禪道使用建議

1 T4_測試結項報告

1.1 什么是結項報告

結項，指的是測試活動的終止，close. 結項報告就是在測試活動終止的時候，輸出的紙質文檔。結項報告是整個測試過程收尾的一環，以下是結項報告建議的內容。

1.2 報告內容

項目概述
- 被測試的項目（需求）具體內容
- 該需求需要使用自動化測試的原因
- 涉及到的自動化測試邊界
測試方案
- 使用的工具
- 處理第三方代碼
- 測試用例腳本
  - 步驟
  - 斷言
  - 執行
- 組織業務邏輯
- 參數化數據輸入
- 運行與測試報告生成
- 設計結構圖
- 代碼目錄結構
測試結論
- 項目能力描述
- 項目風險評估
- 項目缺陷問題
經驗總結
- 落地實施問題
  - 測試數據
    - 數據準備
    - 數據清理
    - 數據還原
  - 測試腳本
  - 業務抽離
  - 封裝驅動
- 代碼技巧問題
  - 定位元素
  - 實例化驅動
  - 驅動的傳遞
  - 測試前置條件與測試清理操作
  - 斷言的設置
  - 定位元素
    - frame
    - select
    - 動態id
    - 元素自動隱藏
  - 數據庫驗證
- 編程規范問題
  - 命名引發的類級別常亮被重寫
  - 方法命名
  - 方法操作的定義范圍
  - 參數傳遞（傳遞字典）
- 代碼調試問題
  - 常見報錯
  - 如何調試
- 源代碼管理的問題
  - 沖突？
    - 養成習慣，打開電腦，就 update
    - 修改之前，先update
    - 提交之前，同樣 update
    - 修改以后，立刻提交 commit
  - PyCharm 中無法使用 subversion，提示命令行缺失：重新安裝 TortoiseSVN，勾選所有的模塊（命令行工具）
- 測試分工的問題
  - 編寫測試腳本
  - 編寫Page
  - 維護定位符

1.3 報告作用

分析測試活動的優秀實踐
整理測試過程的收獲
描述被測試需求的真實情況
指導公司管理層的決策
提升敏捷團隊的工作能力

2 P2_敏捷項目流程

2.1 敏捷 Scrum 知識

Scrum是一種兼顧計劃性與靈活性的敏捷開發過程，原詞來自于橄欖球中的“帶球過人”。在橄欖球比賽的每次沖刺前，都將有一個計劃安排的過程，但沖刺開始后則由隊員在原計劃的基礎上隨機應變。

Snap1.jpg

不同于瀑布模型將開發過程劃分為需求、設計、編碼、測試等階段，Scrum將整個開發過程分為多次迭代（稱為Sprint，沖刺），一般為期2～4周。

在日常工作時，產品負責人會維護一個按優先級排序的“產品待開發項”（Product Backlog），即從客戶價值理解和描述的產品功能條目。

在每次迭代的第一天，召開迭代計劃會(Sprint Planning Meeting)。產品負責人會逐一挑選最高優先級的部分進行講解。團隊可就需求細節、完成標準等進行詢問，并逐條估算，放入本次迭代的開發任務中，直至任務量飽和。一旦迭代開始，這些任務將不會發生大的變化。

在迭代期內，團隊將決定任務分配、所需的技術等，逐一完成任務。每天團隊會進行一個簡短的站立會議即每日立會 Daily Stand-up Meeting，溝通當前進度、下一步任務和當前存在的問題，以借助團隊的力量解決。團隊還維護一張“燃燒圖”（Burn Down Chart），即所有任務的累積剩余時間隨開發進程與日遞減的圖形，以觀察和預測所有任務是否會按期完成。

在每個迭代的最后一天，團隊會召集評審會(Review Meeting)，邀請產品負責人等參加，對已經完成的產品功能條目進行評審，后者做出判斷并給出改進反饋。當天還會召開反思會(Retrospective Meeting)，對本次迭代中的成功與失敗之處做出總結，并在以后迭代中進行改進。

兩個清單
- Product Backlog
  
  產品待開發項 Product Backlog是從客戶價值角度理解的產品功能列表。
  - 功能、缺陷、增強等都可以是待開發項。
  - 一般以條目化的方式描述。
  - 客戶和用戶必須能夠理解。
  - 描述怎樣使用而非怎樣制造。
  - 整體上從客戶價值優先級排序。
  - 總工作量一般需要0.5～10人天。
  - 高優先級的條目應有較詳盡的描述，低優先級的條目可只有一個名稱。
- Sprint Backlog
  
  沖刺待開發項 Sprint Backlog是從開發技術角度理解的迭代開發任務。
  - 在簡單的純軟件環境中，可以直接把產品待開發項當作沖刺待開發項分配到迭代中。
  - 在復雜的開發環境中，可以把一個產品待開發項分解為Web/后臺……軟件/硬件……程序/美術……等開發任務。
三個角色
- Product Owner
  
  Product Owner（產品負責人）負責產品需求的提煉、條目化、優先級排序。
  現實世界的產品負責人
  - 部門經理、產品經理、策劃人員等都可能做產品負責人。
  - 產品負責人是產品的指路人，必須對產品有長遠的規劃和深入了解，因此不能簡單地選擇銷售人員甚至客戶作為產品負責人。
  - 大型產品如嵌入式產品和網絡游戲，常常使用有層級的產品負責人團隊，來解決廣度與深度的矛盾，如產品總監-產品經理 / 主策劃-策劃團隊。
- Scrum Master
  
  Scrum Master（Scrum“大師”）負責維護Scrum方法的秩序，并協助解決非技術問題。
  現實世界的Scrum Master
  - Scrum Master的工作方式是靠領導力(leadership)而非權力工作，因此首先應服務于團隊。
  - 一種人選是原來的項目經理轉型，保留原有的管理和技術職能，但弱化指派任務、下達時間點指令等內容，而增強其組織協調能力。
  - 另一種人選是企業原有的過程改進人員，協助不太了解Scrum的項目經理按照Scrum的方法工作，可以每人負責多個項目，接近全職的Scrum Master。
- The Team
  
  Team（團隊）以“自組織”的相對扁平方式進行管理，負責完成開發工作。
  現實世界的開發團隊
  - 實際團隊常常不是“扁平的”，而是仍有項目經理、小組長等職位。
  - 工作中他們以“共同估算”“跨職能工作”“共同跟進”等方式自組織工作，而不是完全依賴層層指令。
  - 項目經理、小組長的領導、指導、協同職能大于其指令職能。
四個儀式
- 計劃會：Sprint Planning Meeting
  - 迭代計劃會在每個迭代第一天召開，目的是選擇和估算本次迭代的工作項。
  - 產品負責人逐條講解最重要的產品功能。
  - 開發團隊共同估算故事所需工作量，直到本迭代工作量達到飽和。
  - 產品負責人參與討論并回答與需求相關的問題，但不干擾估算結果。
- 每日立會：Standup Meeting
  - 隊員認領任務（或由組長協商分發），獨立或與別人一起完成任務。
  - 團隊內部利用每日立會來溝通進度。
  - 開發團隊利用燃盡圖來展示整體進度。
  - 如無特殊原因，迭代期內無變更。
- 評審會：Review Meeting
  - 小組向產品負責人展示迭代工作結果。
  - 產品負責人給出評價和反饋。
  - 以用戶故事是否能成功交付來評價任務完成情況。
- 反思會：Retrospective Meeting
  - 在每個迭代后召開簡短的反思會。
  - 總結哪些事情做的好，哪些事情做的不好。
  - 制定改進計劃。

Scrum 的使用有一些需要了解的基礎知識背景，主要是角色和構件的介紹。

2.2 Scrum 角色

接下來主要介紹3個角色

敏捷三大角色.jpg

PO，Product Owner，產品負責人

產品負責人是整個產品的負責人，主要做的事情是負責產品的進度、計劃、需求和發布。對應禪道的“產品”功能。
SM，Scrum Master，敏捷教練

這個是敏捷團隊特有的角色，并不是項目經理，而是獨立的個體，任務和職責是保證團隊足夠“敏捷”。這一點是禪道與Scrum 不一致的地方。禪道這里對應的是“迭代”或者“項目”。
TM，Team Member，團隊成員

敏捷團隊中，包括項目經理，開發與測試。對應禪道的是：項目經理負責“迭代”里面的任務，任務是分配給開發和測試。同時禪道又單獨區分了測試。提出了測試模塊。

禪道與敏捷的對應，主要體現在“產品”和“迭代”這兩塊。

產品模塊
- 需求列表：對應 Product Backlog
- 需求（用戶故事）：對應 User Story
- 發布計劃：對應 Product Sprint 優先級
迭代（項目）模塊
- 需求列表：對應 Sprint Backlog
- 需求細分任務：
  - 開發
  - 測試
  - UI
  - ……
- 需求分解用例：
  - 測試
- 版本：Sprint 發布

2.3 Scrum 流程

1. 迭代開始

每個小組：

按照計劃會的文檔畫燃盡圖
開站會（每天）
1. 昨天做了什么
2. 今天準備做什么（開始測試哪個需求？）
3. 對目前的工作有無困難（阻礙）
組長更新燃盡圖
組長在禪道中新建項目（迭代），關聯產品，關聯開計劃會的需求。
1. 登錄禪道，組長新建項目（迭代），并且關聯產品，設置團隊成員。
  
  Snap3.jpg
2. 根據計劃會的內容（計劃會挑選的需求），關聯需求
  
  Snap4.jpg
  
  以接下來的一條需求為例，操作第五步
  
  Snap5.jpg

根據計劃會認領的需求（需求141，如上圖），對指定的需求，創建測試任務，指派給相關人員

Snap6.jpg

Snap7.jpg

根據計劃會認領的測試任務，由組長或者測試人員自己添加任務

以下圖的 APP壓力測試和WEB UI自動化驗收測試為例，講解此步驟

編號	需求名稱	所屬模塊	測試人員	測試時間
105	普通用戶注冊	注冊	XXX	1
106	普通用戶密碼登錄	登錄		2
120	新建項目	項目列表		1
134	任務編輯
109	邀請新成員	團隊		1
111	成員列表
-	APP壓力測試（monkey）
-	WebUI自動化測試（驗收）
匯總	14個			14

以上列表中，有編號的是需求，直接按照第五步，對需求，創建測試任務，指派給測試人員。

無編號的，是針對產品的任務，直接在項目（迭代） | 任務中創建任務。

Snap8.jpg

Snap9.jpg

個人：

在禪道中，進入項目（迭代）| 任務，挑選目前需要做的任務，選定一條，點擊開始。

Snap10.jpg

Snap11.jpg
針對你要開始做的需求，編寫一頁紙測試計劃，提交SVN。30分鐘以內。并且在禪道的任務中，做相關工時記錄。

記錄工時：

Snap12.jpg

Snap13.jpg
在禪道中，針對指定的需求，創建用例，同時在禪道的任務中，做相關工時記錄。
如果開發沒有完成需求規定的任務，可以暫定該任務，同時在禪道的任務中，做相關工時記錄。

Snap14.jpg

Snap15.jpg

?
等待開發完成需求規定的任務后，請開發創建版本，關聯需求，并提測。
測試人員在版本中，找到該版本。對其需求關聯用例，并開始執行測試。同時在禪道的任務中，做相關工時記錄。

Snap16.jpg

Snap17.jpg

Scrum項目流程圖示意

Scrum項目流程圖.png

Scrum流程圖.png

3 P3_禪道使用建議

2.2 系統使用流程

敏捷的主要流程如下：

1030887-20161022224425123-1825836340.png

用管理員登錄系統，找到【組織】頁面，維護公司信息，創建部門，再創建用戶。用戶至少需要包括：

產品經理
項目經理
研發主管
測試主管
研發人員（若干）
測試人員（若干）

Capture.PNG

角色	主要工作	備注說明
管理員	維護公司信息和模塊，管理用戶和權限
產品經理`Product Owner`	給產品提需求
項目經理`Scrum Master`	給當前迭代`SPRINT`挑選需求，并分解需求為任務
開發人員`Developer`	完成項目經理分解的任務
測試人員`Tester`	對當前挑選的需求建立用例，執行用例并提交缺陷

禪道由三大模塊組成：產品、項目和測試。

img
產品經理登錄系統，創建一個新的產品：
- 產品的負責人、測試的負責人（測試主管）、發布的負責人（項目經理或者研發主管）
- 產品的類型：正常、多分支(基礎版、旗艦版、開源版……)、多平臺（Windows PC、Android、iOS(iPhone,iPad)、BlackBerry、Mac、Windows Phone、Symbian……）
- 維護產品的平臺和模塊（注意功能整合和重復性）
- 創建產品的計劃，按照產品的發布進度進行劃分
- 產品經理提需求（單獨和批量），需求的計劃需要選擇；然后需求的描述“作為XXX，我希望可以XXX，實現XXX”-- 用戶故事（User Story），需求要寫的籠統一些。驗收標準需要量化或者清晰。驗收標準是測試標準。
  
  注意的點：
  - 產品模塊需要產品經理登錄
  - 產品有多分支和多平臺之分。在寫模塊的時候，需要注意區分
  - 產品的模塊，是拆分產品的功能的重要依據
  - 產品的需求，就是用戶故事（User Story），也就是一句話需求
    - As a <type of user>, I want <some goal> so that <some reason>.
    - 作為一名<*某種類型的用戶*>，我希望<*達成某些目的*>，這樣可以<*開發的價值*>。
  - 產品的需求中，對驗收標準的描述，需要確定和詳細
  - 添加需求的時候，注意需求是否需要評審
  - 添加需求的時候，注意產品的預估時間
  - 需求的變更 vs 需求的編輯
    1. 需求變更可以改變需求的描述和驗收標準
    2. 需求編輯只能改變需求的基本信息和備注
項目經理登錄系統，創建一個項目，該項目務必關聯剛剛創建的產品，如果這個產品是多分支的或者多平臺的，需要關聯具體的平臺或者分支。
- 創建項目，關聯產品
- 創建團隊：需要選擇研發主管(可選)、測試主管（可選）、研發人員、測試人員，并需要統計各位的可用人時。
- 關聯需求，選中之前產品經理創建的需求。
項目經理開計劃會，準備Kanban（看板），（未開始的 | 進行中的 | 已完成的），全部人參加，包括產品經理
- 計劃會需要制定的內容
  - 迭代周期（sprint），一般是一周或者兩周，定下來以后，所有的迭代都用這個周期
  - 安排每日立會的時間，每日開會時間都固定：
    1. “昨天做了什么”
    2. “今天要做什么”
    3. “有無問題”
  - 挑選本次迭代需要完成的需求，標準是必要的，而且可發布，并且可以構成一個可用的版本。
  - 產品經理講解需求
  - 項目經理拆分需求為任務（分解任務）、需要開發團隊的支持
測試主管登錄系統，分解用例。把需求分解成用例。進行用例設計
指定的開發工程師登錄系統，對指派過的任務進行開始、完成、關閉的操作
指定的測試工程師登錄系統，對用例進行編寫，注意前置條件、步驟（每一步都有期望結果）、優先級
項目經理登錄系統，創建（構建build）版本，注意SVN等信息
- 包括版本的具體信息、文件下載信息、源代碼位置等
- 關聯需求，關聯已經完成開發，并在本版本中包含的需求
- 到測試頁面 | 版本，提交測試（提測 | 轉測）
測試主管登錄系統，到測試 | 版本頁面。

關聯用例
指派測試人員
開始測試

測試人員登錄，到指派給我的用例，進行執行。執行若出現問題，就轉bug.
測試主管登錄系統，到測試 | 版本 | 概況頁面，關閉測試
開發人員登錄系統，修改bug
項目經理登錄系統，重新創建（構建build）版本，注意SVN等信息
- 包括版本的具體信息、文件下載信息、源代碼位置等
- 關聯需求，關聯已經完成開發，并在本版本中包含的需求
- 關聯上一個版本的已經修復的bug
- 到測試頁面 | 版本，提交測試（提測 | 轉測），填寫版本更新的清單
測試主管登錄系統，到測試 | 版本頁面。
- 關聯用例
- 指派測試人員
- 開始測試
測試人員登錄系統，進行測試
測試主管登錄系統，到測試 | 版本 | 概況頁面，關閉測試
產品經理登錄系統，產品 | 發布 | 創建發布，注意關聯需求。本次版本完成。

整體項目流程圖

禪道敏捷流程圖.png

3.2 測試與禪道使用

禪道參與測試與兩種使用方式：全流程與缺陷管理流程。

全流程：產品、研發團隊、測試團隊全部參與
缺陷管理流程：只是測試團隊用來跟蹤和管理缺陷

3.3 部署與升級

升級安裝
1. 備份舊的版本，cp -r zentaopms zentaopms_bak
2. 覆蓋舊的版本
3. 在 zentaopms/www 創建 ok.txt (注意是否顯示已知文件的擴展名)
4. 備份數據庫 mysqldump -u root -p zentao > c:\zentao_20161111.bak
5. 確認升級的版本
6. 升級完成
故障處理
- 白屏
  MySQL 數據庫沒有啟動，啟動失敗
  MySQL 數據庫端口不匹配（3306）
  MySQL 用戶密碼不匹配
- 404
  object not found 活該你單身
  檢查端口和路徑
重置密碼
1. 點擊忘記密碼
2. 按照指引，在 zentaopms/www 創建一個 xxxx.txt 的文件
3. 點擊指引的刷新按鈕
4. 轉到重置用戶密碼的頁面，輸入用戶名，如果用戶名忘記了，需要打開數據庫管理工具，選擇 zentao 數據庫的 zt_user 表，查看用戶名
5. 重置之后，在瀏覽器重新輸入 http://[host][:port]/zentaopms/www