Day 6 測試報告講義

Day 6 測試報告講義

0 主要內(nèi)容

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

1 T4_測試結(jié)項報告

1.1 什么是結(jié)項報告

結(jié)項卓囚，指的是測試活動的終止框全，close. 結(jié)項報告就是在測試活動終止的時候，輸出的紙質(zhì)文檔阻肿。結(jié)項報告是整個測試過程收尾的一環(huán)康辑，以下是結(jié)項報告建議的內(nèi)容。

1.2 報告內(nèi)容

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

1.3 報告作用

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

2 P2_敏捷項目流程

2.1 敏捷 Scrum 知識

Scrum是一種兼顧計劃性與靈活性的敏捷開發(fā)過程肠套，原詞來自于橄欖球中的“帶球過人”舰涌。在橄欖球比賽的每次沖刺前，都將有一個計劃安排的過程你稚，但沖刺開始后則由隊員在原計劃的基礎(chǔ)上隨機應(yīng)變瓷耙。

Snap1.jpg

不同于瀑布模型將開發(fā)過程劃分為需求、設(shè)計刁赖、編碼搁痛、測試等階段，Scrum將整個開發(fā)過程分為多次迭代（稱為Sprint宇弛，沖刺）鸡典，一般為期2～4周。

在日常工作時枪芒，產(chǎn)品負(fù)責(zé)人會維護一個按優(yōu)先級排序的“產(chǎn)品待開發(fā)項”（Product Backlog）彻况，即從客戶價值理解和描述的產(chǎn)品功能條目。

在每次迭代的第一天舅踪，召開迭代計劃會(Sprint Planning Meeting)纽甘。產(chǎn)品負(fù)責(zé)人會逐一挑選最高優(yōu)先級的部分進行講解。團隊可就需求細(xì)節(jié)抽碌、完成標(biāo)準(zhǔn)等進行詢問悍赢，并逐條估算，放入本次迭代的開發(fā)任務(wù)中，直至任務(wù)量飽和左权。一旦迭代開始皮胡，這些任務(wù)將不會發(fā)生大的變化。

在迭代期內(nèi)赏迟，團隊將決定任務(wù)分配屡贺、所需的技術(shù)等，逐一完成任務(wù)锌杀。每天團隊會進行一個簡短的站立會議即每日立會 Daily Stand-up Meeting烹笔，溝通當(dāng)前進度、下一步任務(wù)和當(dāng)前存在的問題抛丽，以借助團隊的力量解決谤职。團隊還維護一張“燃燒圖”（Burn Down Chart），即所有任務(wù)的累積剩余時間隨開發(fā)進程與日遞減的圖形亿鲜，以觀察和預(yù)測所有任務(wù)是否會按期完成允蜈。

在每個迭代的最后一天，團隊會召集評審會(Review Meeting)蒿柳，邀請產(chǎn)品負(fù)責(zé)人等參加饶套，對已經(jīng)完成的產(chǎn)品功能條目進行評審，后者做出判斷并給出改進反饋垒探。當(dāng)天還會召開反思會(Retrospective Meeting)妓蛮，對本次迭代中的成功與失敗之處做出總結(jié)，并在以后迭代中進行改進圾叼。

• 兩個清單

  • Product Backlog

    產(chǎn)品待開發(fā)項 Product Backlog是從客戶價值角度理解的產(chǎn)品功能列表蛤克。

    • 功能、缺陷夷蚊、增強等都可以是待開發(fā)項构挤。
    • 一般以條目化的方式描述。
    • 客戶和用戶必須能夠理解惕鼓。
    • 描述怎樣使用而非怎樣制造筋现。
    • 整體上從客戶價值優(yōu)先級排序。
    • 總工作量一般需要0.5～10人天箱歧。
    • 高優(yōu)先級的條目應(yīng)有較詳盡的描述矾飞，低優(yōu)先級的條目可只有一個名稱。

  • Sprint Backlog

    沖刺待開發(fā)項 Sprint Backlog是從開發(fā)技術(shù)角度理解的迭代開發(fā)任務(wù)呀邢。

    • 在簡單的純軟件環(huán)境中洒沦，可以直接把產(chǎn)品待開發(fā)項當(dāng)作沖刺待開發(fā)項分配到迭代中。
    • 在復(fù)雜的開發(fā)環(huán)境中驼鹅，可以把一個產(chǎn)品待開發(fā)項分解為Web/后臺……軟件/硬件……程序/美術(shù)……等開發(fā)任務(wù)微谓。

• 三個角色

  • Product Owner

    Product Owner（產(chǎn)品負(fù)責(zé)人）負(fù)責(zé)產(chǎn)品需求的提煉、條目化输钩、優(yōu)先級排序豺型。
    現(xiàn)實世界的產(chǎn)品負(fù)責(zé)人

    • 部門經(jīng)理、產(chǎn)品經(jīng)理买乃、策劃人員等都可能做產(chǎn)品負(fù)責(zé)人姻氨。
    • 產(chǎn)品負(fù)責(zé)人是產(chǎn)品的指路人，必須對產(chǎn)品有長遠(yuǎn)的規(guī)劃和深入了解剪验，因此不能簡單地選擇銷售人員甚至客戶作為產(chǎn)品負(fù)責(zé)人肴焊。
    • 大型產(chǎn)品如嵌入式產(chǎn)品和網(wǎng)絡(luò)游戲，常常使用有層級的產(chǎn)品負(fù)責(zé)人團隊功戚，來解決廣度與深度的矛盾娶眷，如產(chǎn)品總監(jiān)-產(chǎn)品經(jīng)理 / 主策劃-策劃團隊。

  • Scrum Master

    Scrum Master（Scrum“大師”）負(fù)責(zé)維護Scrum方法的秩序啸臀，并協(xié)助解決非技術(shù)問題届宠。
    現(xiàn)實世界的Scrum Master

    • Scrum Master的工作方式是靠領(lǐng)導(dǎo)力(leadership)而非權(quán)力工作，因此首先應(yīng)服務(wù)于團隊乘粒。
    • 一種人選是原來的項目經(jīng)理轉(zhuǎn)型豌注，保留原有的管理和技術(shù)職能，但弱化指派任務(wù)灯萍、下達(dá)時間點指令等內(nèi)容轧铁，而增強其組織協(xié)調(diào)能力。
    • 另一種人選是企業(yè)原有的過程改進人員旦棉，協(xié)助不太了解Scrum的項目經(jīng)理按照Scrum的方法工作齿风，可以每人負(fù)責(zé)多個項目，接近全職的Scrum Master绑洛。

  • The Team

    Team（團隊）以“自組織”的相對扁平方式進行管理聂宾，負(fù)責(zé)完成開發(fā)工作。
    現(xiàn)實世界的開發(fā)團隊

    • 實際團隊常常不是“扁平的”诊笤，而是仍有項目經(jīng)理系谐、小組長等職位。
    • 工作中他們以“共同估算”“跨職能工作”“共同跟進”等方式自組織工作讨跟，而不是完全依賴層層指令纪他。
    • 項目經(jīng)理、小組長的領(lǐng)導(dǎo)晾匠、指導(dǎo)茶袒、協(xié)同職能大于其指令職能。

• 四個儀式

  • 計劃會：Sprint Planning Meeting
    • 迭代計劃會在每個迭代第一天召開凉馆，目的是選擇和估算本次迭代的工作項薪寓。
    • 產(chǎn)品負(fù)責(zé)人逐條講解最重要的產(chǎn)品功能亡资。
    • 開發(fā)團隊共同估算故事所需工作量，直到本迭代工作量達(dá)到飽和向叉。
    • 產(chǎn)品負(fù)責(zé)人參與討論并回答與需求相關(guān)的問題锥腻，但不干擾估算結(jié)果。
  • 每日立會：Standup Meeting
    • 隊員認(rèn)領(lǐng)任務(wù)（或由組長協(xié)商分發(fā)）母谎，獨立或與別人一起完成任務(wù)瘦黑。
    • 團隊內(nèi)部利用每日立會來溝通進度。
    • 開發(fā)團隊利用燃盡圖來展示整體進度奇唤。
    • 如無特殊原因幸斥，迭代期內(nèi)無變更。
  • 評審會：Review Meeting
    • 小組向產(chǎn)品負(fù)責(zé)人展示迭代工作結(jié)果咬扇。
    • 產(chǎn)品負(fù)責(zé)人給出評價和反饋甲葬。
    • 以用戶故事是否能成功交付來評價任務(wù)完成情況。
  • 反思會：Retrospective Meeting
    • 在每個迭代后召開簡短的反思會懈贺。
    • 總結(jié)哪些事情做的好演顾，哪些事情做的不好。
    • 制定改進計劃隅居。

Scrum 的使用有一些需要了解的基礎(chǔ)知識背景钠至，主要是角色和構(gòu)件的介紹。

2.2 Scrum 角色

接下來主要介紹3個角色

敏捷三大角色.jpg

1. PO胎源，Product Owner棉钧，產(chǎn)品負(fù)責(zé)人

   產(chǎn)品負(fù)責(zé)人是整個產(chǎn)品的負(fù)責(zé)人，主要做的事情是負(fù)責(zé)產(chǎn)品的進度涕蚤、計劃宪卿、需求和發(fā)布。對應(yīng)禪道的“產(chǎn)品”功能万栅。

2. SM佑钾，Scrum Master，敏捷教練

   這個是敏捷團隊特有的角色烦粒，并不是項目經(jīng)理休溶，而是獨立的個體，任務(wù)和職責(zé)是保證團隊足夠“敏捷”扰她。這一點是禪道與Scrum 不一致的地方兽掰。禪道這里對應(yīng)的是“迭代”或者“項目”。

3. TM徒役，Team Member孽尽，團隊成員

   敏捷團隊中，包括項目經(jīng)理忧勿，開發(fā)與測試杉女。對應(yīng)禪道的是：項目經(jīng)理負(fù)責(zé)“迭代”里面的任務(wù)瞻讽，任務(wù)是分配給開發(fā)和測試。同時禪道又單獨區(qū)分了測試熏挎。提出了測試模塊速勇。

禪道與敏捷的對應(yīng)，主要體現(xiàn)在“產(chǎn)品”和“迭代”這兩塊婆瓜。

• 產(chǎn)品模塊
  • 需求列表：對應(yīng) Product Backlog
  • 需求（用戶故事）：對應(yīng) User Story
  • 發(fā)布計劃：對應(yīng) Product Sprint 優(yōu)先級
• 迭代（項目）模塊
  • 需求列表：對應(yīng) Sprint Backlog
  • 需求細(xì)分任務(wù)：
    • 開發(fā)
    • 測試
    • UI
    • ……
  • 需求分解用例：
    • 測試
  • 版本：Sprint 發(fā)布

2.3 Scrum 流程

1. 迭代開始

• 每個小組：

1. 按照 計劃會的文檔 畫燃盡圖

2. 開站會（每天）

   1. 昨天做了什么
   2. 今天準(zhǔn)備做什么（開始測試哪個需求？）
   3. 對目前的工作有無困難（阻礙）

3. 組長更新燃盡圖

4. 組長在禪道中新建項目（迭代）贡羔，關(guān)聯(lián)產(chǎn)品廉白，關(guān)聯(lián)開計劃會的需求。

   1. 登錄禪道乖寒，組長新建項目（迭代）猴蹂，并且關(guān)聯(lián)產(chǎn)品，設(shè)置團隊成員楣嘁。

      Snap3.jpg

   2. 根據(jù)計劃會的內(nèi)容（計劃會挑選的需求）磅轻，關(guān)聯(lián)需求

      Snap4.jpg

      以接下來的一條需求為例，操作第五步

      Snap5.jpg

1. 根據(jù)計劃會認(rèn)領(lǐng)的需求（需求141逐虚，如上圖）聋溜，對指定的需求，創(chuàng)建測試任務(wù)叭爱，指派給相關(guān)人員

   Snap6.jpg
   Snap7.jpg

2. 根據(jù)計劃會認(rèn)領(lǐng)的測試任務(wù)撮躁，由組長或者測試人員自己添加任務(wù)

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

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

   以上列表中买雾，有編號的是需求把曼，直接按照第五步，對需求漓穿，創(chuàng)建測試任務(wù)嗤军，指派給測試人員。

   無編號的晃危，是針對產(chǎn)品的任務(wù)叙赚，直接在 項目（迭代） | 任務(wù) 中創(chuàng)建任務(wù)。

   Snap8.jpg
   Snap9.jpg

• 個人：

1. 在禪道中僚饭，進入 項目（迭代）| 任務(wù)纠俭，挑選目前需要做的任務(wù)，選定一條浪慌，點擊開始冤荆。

   Snap10.jpg
   Snap11.jpg

2. 針對你要開始做的需求，編寫一頁紙測試計劃权纤，提交SVN钓简。30分鐘以內(nèi)乌妒。并且在禪道的任務(wù)中，做相關(guān)工時記錄外邓。

   記錄工時：

   Snap12.jpg
   Snap13.jpg

3. 在禪道中撤蚊，針對指定的需求，創(chuàng)建用例损话，同時在禪道的任務(wù)中侦啸，做相關(guān)工時記錄。

4. 如果開發(fā)沒有完成需求規(guī)定的任務(wù)丧枪，可以暫定該任務(wù)光涂，同時在禪道的任務(wù)中，做相關(guān)工時記錄拧烦。

   Snap14.jpg
   Snap15.jpg

   ?

5. 等待開發(fā)完成需求規(guī)定的任務(wù)后忘闻，請開發(fā)創(chuàng)建版本，關(guān)聯(lián)需求恋博，并提測齐佳。

6. 測試人員在版本中，找到該版本债沮。對其需求關(guān)聯(lián)用例炼吴，并開始執(zhí)行測試。同時在禪道的任務(wù)中疫衩，做相關(guān)工時記錄缺厉。

   Snap16.jpg
   Snap17.jpg

• Scrum項目流程圖示意

  Scrum項目流程圖.png
  Scrum流程圖.png

3 P3_禪道使用建議

2.2 系統(tǒng)使用流程

敏捷的主要流程如下：

1030887-20161022224425123-1825836340.png

1. 用管理員登錄系統(tǒng)，找到【組織】頁面隧土，維護公司信息提针，創(chuàng)建部門，再創(chuàng)建用戶曹傀。用戶至少需要包括：

   • 產(chǎn)品經(jīng)理
   • 項目經(jīng)理
   • 研發(fā)主管
   • 測試主管
   • 研發(fā)人員（若干）
   • 測試人員（若干）
   Capture.PNG

   角色	主要工作	備注說明
   管理員	維護公司信息和模塊辐脖，管理用戶和權(quán)限
   產(chǎn)品經(jīng)理Product Owner	給產(chǎn)品提需求
   項目經(jīng)理Scrum Master	給當(dāng)前迭代SPRINT挑選需求，并分解需求為任務(wù)
   開發(fā)人員Developer	完成項目經(jīng)理分解的任務(wù)
   測試人員Tester	對當(dāng)前挑選的需求建立用例皆愉，執(zhí)行用例并提交缺陷

2. 禪道由三大模塊組成：產(chǎn)品嗜价、項目和測試。

   img

3. 產(chǎn)品經(jīng)理登錄系統(tǒng)幕庐，創(chuàng)建一個新的產(chǎn)品：

   • 產(chǎn)品的負(fù)責(zé)人久锥、測試的負(fù)責(zé)人（測試主管）、發(fā)布的負(fù)責(zé)人（項目經(jīng)理或者研發(fā)主管）

   • 產(chǎn)品的類型：正常异剥、多分支(基礎(chǔ)版瑟由、旗艦版、開源版……)冤寿、多平臺（Windows PC歹苦、Android青伤、iOS(iPhone,iPad)、BlackBerry殴瘦、Mac狠角、Windows Phone、Symbian……）

   • 維護產(chǎn)品的平臺和模塊（注意功能整合和重復(fù)性）

   • 創(chuàng)建產(chǎn)品的計劃蚪腋，按照產(chǎn)品的發(fā)布進度進行劃分

   • 產(chǎn)品經(jīng)理提需求（單獨和批量）丰歌，需求的計劃需要選擇；然后需求的描述“作為XXX屉凯，我希望可以XXX立帖，實現(xiàn)XXX”-- 用戶故事（User Story），需求要寫的籠統(tǒng)一些神得。驗收標(biāo)準(zhǔn)需要量化或者清晰厘惦。驗收標(biāo)準(zhǔn)是測試標(biāo)準(zhǔn)偷仿。

     注意的點：

     • 產(chǎn)品模塊需要產(chǎn)品經(jīng)理登錄
     • 產(chǎn)品有多分支和多平臺之分哩簿。在寫模塊的時候，需要注意區(qū)分
     • 產(chǎn)品的模塊酝静，是拆分產(chǎn)品的功能的重要依據(jù)
     • 產(chǎn)品的需求节榜，就是用戶故事（User Story），也就是一句話需求
       • As a <type of user>, I want <some goal> so that <some reason>.
       • 作為一名<*某種類型的用戶*>别智，我希望<*達(dá)成某些目的*>宗苍，這樣可以<*開發(fā)的價值*>。
     • 產(chǎn)品的需求中薄榛，對驗收標(biāo)準(zhǔn)的描述讳窟，需要確定和詳細(xì)
     • 添加需求的時候，注意需求是否需要評審
     • 添加需求的時候敞恋，注意產(chǎn)品的預(yù)估時間
     • 需求的變更 vs 需求的編輯
       1. 需求變更可以改變需求的描述和驗收標(biāo)準(zhǔn)
       2. 需求編輯只能改變需求的基本信息和備注

4. 項目經(jīng)理登錄系統(tǒng)，創(chuàng)建一個項目，該項目務(wù)必關(guān)聯(lián)剛剛創(chuàng)建的產(chǎn)品货矮，如果這個產(chǎn)品是多分支的或者多平臺的对途，需要關(guān)聯(lián)具體的平臺或者分支。

   • 創(chuàng)建項目啸蜜，關(guān)聯(lián)產(chǎn)品
   • 創(chuàng)建團隊：需要選擇研發(fā)主管(可選)坑雅、測試主管（可選）、研發(fā)人員衬横、測試人員裹粤，并需要統(tǒng)計各位的可用人時。
   • 關(guān)聯(lián)需求蜂林，選中之前產(chǎn)品經(jīng)理創(chuàng)建的需求蛹尝。

5. 項目經(jīng)理開計劃會后豫，準(zhǔn)備Kanban（看板），（未開始的 | 進行中的 | 已完成的 ）突那，全部人參加挫酿，包括產(chǎn)品經(jīng)理

   • 計劃會需要制定的內(nèi)容
     • 迭代周期（sprint），一般是一周或者兩周愕难，定下來以后早龟，所有的迭代都用這個周期
     • 安排每日立會的時間，每日開會時間都固定：
       1. “昨天做了什么”
       2. “今天要做什么”
       3. “有無問題”
     • 挑選本次迭代需要完成的需求猫缭，標(biāo)準(zhǔn)是必要的葱弟，而且可發(fā)布，并且可以構(gòu)成一個可用的版本猜丹。
     • 產(chǎn)品經(jīng)理講解需求
     • 項目經(jīng)理拆分需求為任務(wù)（分解任務(wù)）芝加、需要開發(fā)團隊的支持

6. 測試主管登錄系統(tǒng)，分解用例射窒。把需求分解成用例藏杖。進行用例設(shè)計

7. 指定的開發(fā)工程師登錄系統(tǒng)，對指派過的任務(wù)進行開始脉顿、完成蝌麸、關(guān)閉的操作

8. 指定的測試工程師登錄系統(tǒng)，對用例進行編寫艾疟，注意前置條件来吩、步驟（每一步都有期望結(jié)果）、優(yōu)先級

9. 項目經(jīng)理登錄系統(tǒng)蔽莱，創(chuàng)建（構(gòu)建build）版本弟疆，注意SVN等信息

   • 包括版本的具體信息、文件下載信息盗冷、源代碼位置等
   • 關(guān)聯(lián)需求怠苔，關(guān)聯(lián)已經(jīng)完成開發(fā)，并在本版本中包含的需求
   • 到測試頁面 | 版本正塌，提交測試（提測 | 轉(zhuǎn)測）

10. 測試主管登錄系統(tǒng)嘀略，到測試 | 版本 頁面。

• 關(guān)聯(lián)用例
• 指派測試人員
• 開始測試

11. 測試人員登錄乓诽，到指派給我的用例帜羊，進行執(zhí)行。執(zhí)行若出現(xiàn)問題鸠天，就轉(zhuǎn)bug.

12. 測試主管登錄系統(tǒng)讼育，到測試 | 版本 | 概況 頁面，關(guān)閉測試

13. 開發(fā)人員登錄系統(tǒng)，修改bug

14. 項目經(jīng)理登錄系統(tǒng)奶段，重新創(chuàng)建（構(gòu)建build）版本饥瓷，注意SVN等信息

    • 包括版本的具體信息、文件下載信息痹籍、源代碼位置等
    • 關(guān)聯(lián)需求呢铆，關(guān)聯(lián)已經(jīng)完成開發(fā)，并在本版本中包含的需求
    • 關(guān)聯(lián)上一個版本的已經(jīng)修復(fù)的bug
    • 到測試頁面 | 版本蹲缠，提交測試（提測 | 轉(zhuǎn)測）棺克，填寫版本更新的清單

15. 測試主管登錄系統(tǒng)，到測試 | 版本 頁面线定。

    • 關(guān)聯(lián)用例
    • 指派測試人員
    • 開始測試

16. 測試人員登錄系統(tǒng)娜谊，進行測試

17. 測試主管登錄系統(tǒng)，到測試 | 版本 | 概況 頁面斤讥，關(guān)閉測試

18. 產(chǎn)品經(jīng)理登錄系統(tǒng)纱皆，產(chǎn)品 | 發(fā)布 | 創(chuàng)建發(fā)布，注意關(guān)聯(lián)需求芭商。本次版本完成派草。

    整體項目流程圖

    禪道敏捷流程圖.png

3.2 測試與禪道使用

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

• 全流程：產(chǎn)品蓉坎、研發(fā)團隊澳眷、測試團隊全部參與
• 缺陷管理流程：只是測試團隊用來跟蹤和管理缺陷

3.3 部署與升級

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

六天入門軟件測試系列課程總綱

• 相關(guān)學(xué)習(xí)

立師兄Linty：六天入門軟件測試①——測試執(zhí)行講義

立師兄Linty：六天入門軟件測試①——測試執(zhí)行筆記

立師兄Linty：六天入門軟件測試②——測試分析講義

立師兄Linty：六天入門軟件測試②——測試分析筆記

立師兄Linty：六天入門軟件測試③——測試設(shè)計講義

立師兄Linty：六天入門軟件測試③——測試設(shè)計筆記

立師兄Linty：六天入門軟件測試④——測試腳本講義

立師兄Linty：六天入門軟件測試④——測試腳本筆記

立師兄Linty：六天入門軟件測試⑤——測試編程講義

立師兄Linty：六天入門軟件測試⑤——測試編程筆記

立師兄Linty：六天入門軟件測試⑥——測試報告講義

立師兄Linty：六天入門軟件測試⑥——測試報告筆記