專案管理工具jira的問題，透過圖書和論文來找解法和答案更準確安心。 我們找到下列懶人包和總整理

鯨游藍海：鈦坦科技的敏捷之路

為了解決專案管理工具jira的問題，作者新加坡商鈦坦科技 這樣論述：

企業如何擁抱改變、投入動能？探索鈦坦科技從0到1轉型敏捷的故事！ 　　探索鈦坦科技從0到1轉型敏捷的故事！ 　　│當企業遇到發展危機，如何找到改變契機？ 　　│當夥伴決定導入敏捷，怎麼推動組織轉型？ 　　│當組織建立創新思維，站穩腳步的下一步？ 　　 　　想要成為組織轉型的實踐者嗎？《鯨游藍海－鈦坦科技的敏捷之路》匯集新加坡商鈦坦科技從2005年創立至今，歷經五個階段「英雄時期、分地盤時期、SOP時期、便利貼時期、量子小白兔時期」的組織轉型重要事件，深度剖析鈦坦科技如何在迷霧中逐步前進。 　　英雄時期：草創英雄的風雲相會，挑戰自己，發揮價值！ 　　分地盤時期：摸索出管理能力，一步步建

立企業使命與核心價值。 　　SOP時期：明訂工作流程、撰寫技術文件，卻衍生制度僵化的困境。 　　便利貼時期：導入敏捷開發與管理，全面開展組織轉型。 　　量子小白兔時期：敏捷思維遍地開花，如何維持企業文化濃度？ 　　記錄鈦坦人轉型故事 　　《鯨游藍海－鈦坦科技的敏捷之路》以文字記錄轉型過程中不同人物的思考、該時期的發展願景、使命與價值，並藉由說故事的方式，拆解鈦坦科技在不同階段面臨的問題與解方，引領讀者一步步探索鈦坦轉型敏捷的過程。 　　融合系統圖理性分析，敘畫圖感性情緒 　　輔以「敘畫」、「組織發展歷程系統圖」等可視化圖片巧妙帶出理性分析與感性情緒。本書加入「敘畫」顯化科技裡的人文素養與情

感溫度，同時添加「系統圖」展現組織發展的前後因果與邏輯思維，顛覆你對工作與企業發展的想像。 　　鈦坦科技工具組合技 　　介紹鈦坦身為敏捷企業所使用到工具組合技能，詳盡解說鈦坦實際運用的工具技。本書將各個階段解決問題的商業思維框架，針對不同工作場景，搭配圖像化，說明組織如何靈活使用！ 　　邀請你一起來反思！ 　　邀請你從《鯨游藍海－鈦坦科技的敏捷之路》裡提取靈感，一起透過下列問句，反思如何將靈感應用於自己所屬的組織！ 　　對於鈦坦發展歷程中哪些部分有共鳴？ 　　比對鈦坦的發展歷程及自己所屬的組織現況，有哪些相似與不同的地方？ 　　認識鈦坦的組織發展歷程後，對自己所屬的組織有什麼新發現或理解？

　　為了幫助組織發展，可以採取什麼做法來處理目前的課題？ 各界推薦 　　「Agile is about improving to be more adaptive, and self-management is one of the key concepts to enable that. These concepts were their guiding light in continuously figuring out, trying and improving the way they work, from an individual, to a team and organiz

ational level.（導入敏捷開發所期待的，就是提升員工適應變化的能力。而自我管理正是重點之一。上述的這些概念，對於鈦坦科技就如同一座燈塔，不斷指明公司前進的方向，而鈦坦科技從個人、團隊到組織面向的運作，都持續蛻變中。）」──Odd-e Agile Coach│Stanly Lau 　　「In addition to our work with them, many others were brought in to continue their conscious intention to learn from others, and then make it their own.

（鈦坦科技的員工，在我們的課程告一段落後，仍持續保有從他人身上學習的動機，並將這種行為內化。）」──CPF文化事業學會講師│Lawrence Philbrook 　　「鈦坦的夥伴們總是充滿活力及勇於挑戰！大家雖然不見得對教學熟悉，但總是非常認真的吸收，然後熱情分享。」──《教學的技術》、《上台的技術》、《工作與生活的技術》作者│王永福 　　「本書是一本企業成長故事，透過決策者和員工等多元視角，深入瞭解公司變革時蘊含的細節與挑戰。在顧問亞洲許多企業時，我發現大眾對於大規模導入敏捷組織變革所能找到的多半是國外案例，少有融入亞洲社會文化背景於其中的實例。本書即是亞洲企業在敏捷組織轉型的參考指引，

誠摯推薦！」──李佳憲│LeadBest Consulting Group執行長 　　「我曾抵達鈦坦的辦公室，目睹簡約黑白色階前台，食物、啤酒、邏輯與創意。人們在其中寬鬆的交流，彼此之間可見創造的談話，夾雜著溫暖彼此的連結，思維得以在空間創造發展，也帶著節制的力量。」──李崇建│長耳兔心靈維度講師 / 作家 / 教育工作者 　　「轉型的過程不見得每一刻都是愉快的，珍貴的是他們建立的引導文化與氛圍讓大家面對困難的時候也『願意冒險』把不同的感受與觀點拋出來，期待成為團隊前進的養分。」──林思玲│文化事業學會講師 　　「經由分享鈦坦的經驗，希望能拋磚引玉，激發出更多的交流與分享，帶給世界更多的

幸運，我猜這也是鈦坦的初衷吧。期待您的交流與分享，帶給自己幸運的同時，也讓這個世界更幸運。」──林裕丞│Aqive氣機科技總經理 　　「藉由《鯨游藍海》鈦坦進行內部對話回顧成長展望未來，同時將其組織發展的獨特歷程分享讀者，邀請讀者反思自己的組織狀況，我想這也是另一種形式的社會對話，發揮影響力！」──吳咨杏│朝邦文教基金會執行長暨核心引導師 　　「如今鈦坦已成為台灣敏捷式管理的標竿企業了。知道鈦坦要出此書甚為興奮，因為在此新世代為主流，加上新創風氣與電商創業盛行的時代，正好是可作為標竿參考與觀摩。願『敏捷』風氣能在台灣廣為展開，形成新氣候。」──陳宗賢│聯聖企管顧問集團董事長 　　「我建議

讀者從這本書中，去了解他們面對失敗與挫折時的歷程，現在所看到各項實踐背後的脈絡與成因，他們對持續改善不斷注入的能量與行動學習，還有學習型組織裡面很重要的一點：『系統全局的關注』」──陳仕傑91│熱血點火師 　　「記得第一次參觀其南港辦公室時，印象深刻的除了冰櫃與吧檯，還意外看到不少蒲團（靜心坐墊）排列在休息區，原來是學習正念後立刻學以致用，熱忱地在公司內推廣，讓我親見了劍及履及的敏捷精神。」──陳德中│台灣正念工坊創辦人暨執行長 　　「相信各位讀完後，會體會到鈦坦科技──這隻遨遊大海的虎鯨，到底經歷了什麼樣的挑戰而自我蛻變。相信你的心情跟我一樣興奮並充滿期待。」──張昀煒│台灣敏捷協會AC

T理事長 　　「我看見鈦坦在理性與感性中來回，於科技與心靈中碰撞。這鯨游藍海不只是一條敏捷之路。更是一場優游於智慧與實踐的文化旅程。」──張譯文│卓越執行企管顧問執行長 　　「在課堂上這群年輕人帶來很高的能量，非常勇於發問與分享，這是我在別的企業很少感受到的，這種『求知若飢，虛心若愚』（Stay Hungry, Stay Foolish）的氛圍，讓我上完課後，仍然震盪不已。」──梅家仁│達真國際教練學校校長 　　「書中不僅是描述Titansoft組織演化的過程，還運用敘畫與讀者連結，透過系統思考圖分析不同時期面臨哪些挑戰，採取哪些應對方法來適應變化、擁抱改變。相信這些寶貴的經驗能提供給讀

者更多思考，不僅能產生更多的反思，甚至把這些反思反饋在自己的組織發展歷程中。」──黃國瑜│KKTV總經理 　　「鈦坦在做的是鼓勵全員參與，讓每個人都能取得充分的資訊，獲得充分的信任，讓他們有充足的意願想要參與團隊的討論，並主動去解決所遭遇到的種種問題。」──游舒帆│商業思維學院院長 　　「最讓人敬佩的是他們對公司轉型的堅持，以及不吝分享經驗，積極推動產業敏捷革命的態度；他們不但領略敏捷轉型的甘苦，也實際參與了這場管理典範移轉。本書的出版，正是鈦坦的領導者及同仁們，再一次的無私分享。」──溫金豐│國立陽明交通大學管理學院副院長 　　「留住企業的內隱知識與模式，可以幫助企業在迭代上不用從零開

始，而是在既有基礎上疊加發展，相信本書可為正在思考傳承的企業，提供先行者的學習領悟作為參考！」──蔡梅萍│IAF國際引導者協會認證引導師CPF 　　（依姓氏筆畫排序）

敏捷測試：以持續測試促進持續交付

為了解決專案管理工具jira的問題，作者朱少民 這樣論述：

互聯網產品的快速反覆運算，讓敏捷開發在各個領域都得到了廣泛應用。同時，也加快了敏捷測試在各家企業落地生根的進程。 本書由測試領域老兵聯合10余位測試專家對敏捷測試的實踐經驗匯總、整理而成。本書分為10章和4個附錄。從敏捷開發和敏捷測試基礎、人的因素、敏捷測試基礎設施、分析與計畫、設計與執行、測試右移、收尾與改進、展望等角度入手，幾乎涵蓋實現高效敏捷測試所需的各個方面的知識，以及測試思維、測試流程、測試基礎設施和一系列的優秀實踐，對提高測試效率進而提升產品交付品質具有重大的指導意義。 本書理論知識與實際案例深度結合，輔以思維導圖、延伸閱讀等模組，深入淺出，尤其適合有一定測試實踐經驗的軟體品質

保障和測試人員，想要較為深入瞭解敏捷測試的專業人士閱讀參考。 朱少民 國內知名測試專家、同濟大學特聘教授、軟體綠色聯盟標準評測組組長、《軟體學報》審稿人、QECon大會發起人。 近30年來，一直從事軟體測試、品質管制等工作，先後獲得安徽省、原機械工業部、青島市等多項科技進步獎，出版《全程軟體測試》《軟體測試方法和技術》《軟體品質保證和管理》《軟體專案管理》等10餘部著作。 近5年來，致力於幫助國內近百家企業提升其軟體研發能力水準，並經常在國內外學術會議或技術大會上發表演講，擁有個人公眾號“軟體品質報導”，曾任思科（中國）軟體有限公司QA（品質保證）高級總監，及IEEE IC

ST論壇主席、IEEE QRS和DSA、NASAC程式委員等。 李潔 中科創達軟體股份有限公司測試總監，曾任IBM研發經理，索尼瑞典分公司高級測試經理，諾基亞及Polycom QA總監。擁有20餘年軟體測試技術經驗及管理經驗。在測試專業雜誌發表過多篇文章。 第 1 章　 鋪墊：敏捷開發價值觀、原則與實踐／ 1 導讀／ 1 1．1　敏捷開發模式的由來／ 2 1．1．1　新產品開發方式Scrum ／ 3 1．1．2　羽量級軟體發展方法／ 5 1．1．3　敏捷宣言的誕生／ 6 1．2　敏捷價值觀／ 7 1．3　敏捷開發原則／ 8 1．4　常見的敏捷開發框架／ 9 1．4．1　極

限程式設計／ 9 1．4．2　行為驅動開發／ 13 1．4．3　特性驅動開發／ 15 1．4．4　Scrum 開發框架／ 17 1．5　敏捷與看板、精益的關係／ 20 1．5．1　看板／ 21 1．5．2　精益軟體發展實踐／ 23 1．6　敏捷與DevOps 的關係／ 26 本章小結／ 29 延伸閱讀／ 29 第 2 章　基礎：敏捷測試之道／ 31 導讀／ 31 2．1　什麼是敏捷測試／ 32 2．1．1　從一個真實的案例說起／ 32 2．1．2　敏捷測試的含義／ 35 2．1．3　敏捷測試的其他定義／ 36 2．2　傳統測試與敏捷測試／ 38 2．2．1　 鳳凰項目：一個IT 運維的傳奇故

事／ 38 2．2．2　3 步工作法／ 39 2．2．3　鳳凰項目改造前後對比／ 40 2．2．4　傳統測試和敏捷測試的區別／ 41 2．3　敏捷測試的思維方式／ 41 2．3．1　固定性思維與敏捷思維／ 42 2．3．2　成長性思維／ 42 2．3．3　以實例來辨析不同思維的測試工程師／ 43 2．3．4　團隊對品質負責的思維／ 44 2．3．5　上下文驅動的思維與用戶思維／ 45 2．4　敏捷測試流程解析／ 45 2．4．1　Scrum 模式下的測試流程／ 45 2．4．2　敏捷測試的通用流程／ 47 2．4．3　敏捷測試流程閉環與持續測試／ 48 2．4．4　 從敏捷專案管理角度來看測試

流程／ 49 2．5　新的敏捷測試四象限／ 50 2．5．1　敏捷測試四象限之歷史／ 50 2．5．2　新的敏捷測試四象限簡介／ 52 本章小結／ 53 延伸閱讀／ 54 第 3 章　人是決定性因素／ 55 導讀／ 55 3．1　敏捷團隊究竟要不要專職的測試人員／ 56 3．1．1　問題的提出及各方的理由／ 56 3．1．2　根據上下文來確定是否需要／ 58 3．1．3　存在即合理／ 59 3．2　配備專職敏捷測試人員時的操作／ 60 3．2．1　Etsy 公司的優秀實踐／ 60 3．2．2　敏捷測試人員的責任和具體任務／ 61 3．2．3　測試人員和開發人員的分工／ 63 3．2．4　測試

敏捷化對團隊意味著什麼／ 64 3．3　沒有專職的測試人員時的操作／ 64 3．3．1　是否借助灰度發佈和一鍵回滾／ 65 3．3．2　消除系統測試不足帶來的影響／ 66 3．3．3　加強敏捷接受度測試和ATDD 的實踐／ 67 3．3．4　應對其他挑戰／ 67 3．4　借助測試負責人角色完成團隊轉型／ 68 3．4．1　冰凍三尺並非一日之寒／ 69 3．4．2　多數團隊不是Google ／ 70 3．4．3　測試負責人角色的責任和具體實踐／ 71 3．4．4　測試主負責人角色／ 72 3．5　 如何創建有強烈品質意識的學習型團隊／ 73 3．5．1　達成品質共識／ 73 3．5．2　營造良好

的品質文化氛圍／ 73 3．5．3　創建學習型團隊／ 74 3．5．4　業務學習與缺陷根因分析／ 76 3．6　如何更好地為測試而學／ 76 3．6．1　系統性思維訓練／ 77 3．6．2　創造性思維訓練／ 79 3．6．3　如何提升測試自動化能力／ 80 3．6．4　如何學習測試建模／ 80 3．6．5　借力提升自己／ 81 3．7　如何與產品、開發等角色協作／ 82 3．7．1　團隊協作的五大障礙／ 82 3．7．2　團隊協作高於一切／ 84 3．7．3　達成對品質及其管理的共識／ 85 3．7．4　溝通的技巧／ 86 本章小結／ 87 延伸閱讀／ 87 第 4 章　構建強大的敏捷測試基

礎設施／ 89 導讀／ 89 4．1　持續集成與持續交付意味著什麼／ 90 4．1．1　敏捷的目標／ 91 4．1．2　持續集成中的測試活動／ 91 4．1．3　持續交付中的測試活動／ 93 4．1．4　持續集成+ 持續測試是關鍵／ 94 4．1．5　持續部署／ 95 4．1．6　持續運維／ 95 4．2　測試如何融入持續集成/ 持續交付環境／ 95 4．2．1　支撐持續集成的測試環境／ 96 4．2．2　支撐持續交付的測試環境／ 96 4．2．3　CI/CD 流水線中的測試過程／ 97 4．3　基於DevOps 的測試基礎設施構成／ 99 4．3．1　DevOps 的測試／ 100 4．3．

2　DevOps 測試基礎設施／ 101 4．3．3　基礎設施即代碼／ 103 4．3．4　對基礎設施進行驗證——Testinfra ／ 104 4．4　虛擬機器技術與容器技術的應用／ 105 4．4．1　虛擬化技術——虛擬機器技術和容器技術／ 106 4．4．2　Sidecar 模式——容器的設計模式／ 107 4．4．3　虛擬化技術之NUMA 和DPDK ／ 108 4．4．4　服務虛擬化的利器——Hoverfly ／ 109 4．4．5　Molecule——虛擬化技術的自動化測試工具／ 111 4．4．6　Kubernetes 與測試環境／ 112 4．5　如何完成自動部署／ 113 4

．5．1　配置即代碼——CI 配置管理工具：Ansible、Chef ／ 114 4．5．2　微服務的容器化部署／ 116 4．5．3　微服務在CI 環境中的自動化部署／ 117 4．5．4　 Docker 容器的集群管理之Kubernetes ／ 119 4．5．5　 基礎架構即代碼的工具——Terraform、CloudFormation ／ 122 4．5．6　 管道即代碼的工具——Concourse、Drone ／ 123 4．5．7　 新一代的部署體驗——Serverless 軟體系統架構／ 125 4．5．8　產品發佈之導流模式／ 125 4．6　如何完成全自動的BVT ／ 126

4．6．1　BVT 要驗證哪些點／ 126 4．6．2　不穩定的情況——Flaky ／ 128 4．7　自動的靜態測試和測試報告生成／ 130 4．7．1　代碼分析（靜態測試）／ 130 4．7．2　優秀的靜態測試工具／ 131 4．7．3　靜態測試報告的自動生成／ 131 4．7．4　自動化測試報告的自動生成／ 135 4．8　測試分層策略與金字塔模型／ 139 4．9　搭建敏捷自動化測試框架及其案例分析／ 140 4．9．1　自動化測試框架的構成／ 140 4．9．2　自動化測試框架的分類／ 142 4．9．3　單元測試框架JUnit 5 ／ 143 4．9．4　API 層的TA 測試框

架Karate ／ 144 4．9．5　接受度測試框架Ginkgo ／ 146 本章小結／ 148 延伸閱讀／ 149 第 5 章　測試左移更體現敏捷測試的價值／ 150 導讀／ 150 5．1　沒有ATDD，就沒有用戶故事的可測試性／ 151 5．1．1　可測試性的概念／ 151 5．1．2　需求、設計和代碼等不同層次的可測試性／ 152 5．1．3　用戶故事的可測試性和ATDD ／ 153 5．1．4　ATDD 與TDD（ UTDD）的關係／ 154 5．1．5　如何具體實施ATDD ／ 156 5．2　 產品價值分析：商業畫布、影響地圖與用戶故事地圖／ 156 5．2．1　產品價值是基

礎／ 157 5．2．2　商業畫布／ 158 5．2．3　影響地圖／ 160 5．2．4　用戶故事地圖／ 161 5．3　從Epic 到用戶故事完成需求評審／ 162 5．3．1　通用的評審標準／ 163 5．3．2　Epic 的評審／ 164 5．3．3　用戶故事的評審／ 166 5．4　不可忽視的設計評審／ 169 5．4．1　設計評審的價值和重要性／ 170 5．4．2　如何完成架構評審／ 170 5．4．3　有層次的（元件）評審／ 172 5．4．4　介面定義的評審／ 173 5．4．5　設計的可測試性／ 173 5．5　BDD 及其自動化實踐／ 174 5．5．1　什麼是BDD ／

174 5．5．2　BDD 和測試的關係／ 175 5．5．3　現有的BDD 自動化測試框架／ 177 5．5．4　BDD 實例／ 179 5．5．5　BDD 實踐中的常見問題／ 183 5．6　再進一步，讓產生實體需求落地／ 183 5．6．1　什麼是產生實體需求／ 183 5．6．2　產生實體需求的過程／ 185 5．6．3　RBE 的自動化實現／ 190 5．7　單元測試是否必須TDD ／ 191 5．7．1　為何TDD 是必需的／ 191 5．7．2　如何做好TDD ／ 192 5．7．3　UTDD 測試原則／ 193 5．7．4　UTDD 的具體實踐／ 194 本章小結／ 195 延

伸閱讀／ 196 第 6 章　敏捷測試的分析與計畫／ 197 導讀／ 197 6．1　基於上下文驅動思維的測試分析／ 198 6．1．1　上下文驅動測試流派／ 198 6．1．2　品質標準／ 201 6．1．3　專案背景／ 202 6．1．4　產品元素／ 204 6．2　如何培養自己的業務與用戶體驗分析技能／ 205 6．2．1　用戶思維／ 205 6．2．2　場景是測試需求的靈魂／ 206 6．2．3　業務分析／ 207 6．2．4　用戶體驗要素／ 208 6．3　敏捷測試的主要風險在哪裡／ 209 6．3．1　需求不清晰／ 210 6．3．2　需求頻繁變更／ 211 6．3．3　時間太緊

張／ 211 6．3．4　自動化測試的有效性／ 212 6．3．5　測試風險專案檢查表／ 212 6．3．6　風險控制／ 213 6．4　啟發式測試策略與測試策略的制定／ 215 6．4．1　什麼是測試策略／ 215 6．4．2　啟發式測試策略模型／ 216 6．4．3　快速、高效地制定測試策略／ 218 6．5　代碼依賴性分析與精准測試／ 220 6．5．1　精准測試／ 221 6．5．2　如何建立測試用例和代碼的映射關係／ 222 6．5．3　代碼依賴性分析／ 223 6．5．4　代碼的變更分析／ 225 6．5．5　測試用例集如何優化／ 225 6．5．6　優秀實踐／ 226 6．6　敏

捷測試要不要計畫／ 227 6．6．1　測試計畫的價值／ 227 6．6．2　一頁紙的測試計畫／ 228 6．6．3　如何編寫一頁紙的測試計畫／ 229 6．7　探索式測試與基於腳本的測試／ 232 6．7．1　什麼是探索式測試／ 232 6．7．2　探索式測試的應用場景／ 233 6．7．3　基於腳本的測試／ 234 6．7．4　 探索式測試與基於腳本的測試的比較／ 235 6．7．5　敏捷擁抱探索式測試／ 236 6．8　SBTM 的由來及使用／ 237 6．8．1　SBTM 的由來／ 237 6．8．2　真正理解會話／ 237 6．8．3　測試計畫分解成多個子目標／ 239 6．8．4　

測試子目標進一步分解為會話／ 240 6．9　一個應用SBTM 的真實案例／ 241 6．9．1　案例背景／ 241 6．9．2　挑戰在哪裡／ 242 6．9．3　測試子目標分解的結果／ 242 6．9．4　幾個典型的會話／ 243 6．9．5　會話表／ 246 6．9．6　口頭彙報／ 247 6．10　敏捷測試分析與計畫的案例／ 248 6．10．1　資訊收集／ 249 6．10．2　測試目標／ 249 6．10．3　通過測試分析得到測試範圍／ 250 6．10．4　根據測試分析進行風險分析和控制／ 251 6．10．5　基於風險的測試策略／ 252 6．10．6　測試計畫／ 253 本章小

結／ 254 延伸閱讀／ 255 第 7 章　敏捷測試的設計與執行／ 256 導讀／ 256 7．1　正確理解DoD 與敏捷中的接受度測試／ 257 7．1．1　什麼是DoD ／ 257 7．1．2　如何創建DoD ／ 258 7．1．3　DoD 和敏捷接受度測試的關係／ 260 7．1．4　如何驗證DoD ／ 261 7．2　如何將用戶故事轉化為測試用例／ 261 7．2．1　轉換為場景／ 262 7．2．2　場景離測試用例還差一步／ 263 7．2．3　使用者故事轉化為測試用例的模型／ 263 7．3　基於場景/ 事件流的測試用例設計／ 265 7．3．1　事件流圖／ 265 7．3．2

　在敏捷測試中的應用／ 266 7．3．3　狀態圖與有限狀態機／ 268 7．4　探索式測試過程與生態／ 270 7．4．1　調查、分析、排序和實驗／ 270 7．4．2　以分析為中心／ 270 7．4．3　自我管理環、學習環／ 271 7．4．4　協作環與測試環／ 272 7．5　探索式測試中的角色扮演與場景挖掘／ 272 7．5．1　批判性思維與探索式測試設計執行／ 272 7．5．2　角色扮演／ 273 7．5．3　場景挖掘／ 274 7．6　探索式測試的具體技巧／ 276 7．6．1　業務路徑測試／ 277 7．6．2　遍歷測試／ 279 7．6．3　極限情況的測試／ 279 7．6．

4　異常情況的測試／ 280 7．7　測試自動化設計模式：一步到位／ 280 7．7．1　基於模型的自動化測試／ 281 7．7．2　狀態圖生成測試用例／ 281 7．7．3　測試資料的自動生成／ 284 7．8　UI 腳本開發與維護的常用技巧／ 287 7．8．1　指令碼語言和測試框架的選擇／ 287 7．8．2　UI 元素定位／ 288 7．8．3　測試代碼的模組化和參數化／ 291 7．8．4　Selenium 集成自動化測試框架／ 293 7．8．5　Page Object 設計模式／ 295 7．8．6　隱式等待／ 296 7．9　 質效合一：自動化測試和手工測試的完美融合／ 296

7．9．1　一個關於測試策略的案例／ 296 7．9．2　新功能手工測試，回歸測試自動化／ 297 7．9．3　探索未知的，自動化已知的／ 299 7．9．4　自動化回歸測試怎麼做／ 300 7．10　優先實現面向介面的測試／ 300 7．10．1　介面（API）測試越來越重要／ 301 7．10．2　介面測試示例／ 301 7．10．3　如何獲取介面資訊／ 304 7．10．4　契約測試和微服務的介面測試／ 306 7．10．5　API 持續測試平臺：API Fortress ／ 308 本章小結／ 308 延伸閱讀／ 309 第 8 章　測試右移：從敏捷到DevOps ／ 310 導讀

／ 310 8．1　線上性能測試／ 311 8．1．1　全鏈路壓測／ 311 8．1．2　線上性能監控／ 313 8．1．3　流量重播技術／ 314 8．2　A/B 測試／ 316 8．2．1　什麼是A/B 測試／ 316 8．2．2　A/B 測試的設計／ 317 8．2．3　A/B 測試平臺與測試執行／ 319 8．2．4　關於用戶體驗的度量／ 320 8．3　監控告警系統／ 321 8．3．1　日誌分析及Elastic Stack 的使用／ 323 8．3．2　調用鏈分析及SkyWalking 的使用／ 324 8．3．3　指標監控及Prometheus 的使用／ 327 8．3．4　監控

系統解決方案／ 329 8．4　安全性監控／ 330 8．5　混沌工程／ 331 8．5．1　混沌工程的由來／ 332 8．5．2　基於故障注入的測試／ 333 8．5．3　混沌工程平臺與工具／ 334 8．5．4　混沌工程的具體實施／ 336 8．5．5　為系統彈性做好設計／ 337 8．6　智能運維與測試／ 340 8．6．1　從自動化運維到智慧運維／ 340 8．6．2　智能運維的典型場景／ 341 本章小結／ 342 延伸閱讀／ 343 第 9 章　敏捷測試的收尾與改進／ 344 導讀／ 344 9．1　如何分析測試結果和評估測試工作的品質／ 345 9．1．1　如何評估敏捷測試過程

／ 345 9．1．2　敏捷測試過程的度量體系／ 346 9．1．3　測試工作品質的分析／ 348 9．1．4　代碼覆蓋率／ 348 9．1．5　功能覆蓋率／ 349 9．1．6　業務覆蓋率／ 349 9．1．7　基於缺陷分析測試品質／ 350 9．2　如何獲得良好的可追溯性、視覺化／ 350 9．2．1　測試管理系統／ 351 9．2．2　需求與測試用例的映射關係，以及測試用例與缺陷的映射關係／ 352 9．2．3　示例：Jira + Zephyr 實現可追溯性／ 353 9．2．4　測試與品質度量的視覺化／ 355 9．2．5　品質雷達圖／ 357 9．3　敏捷測試優秀實踐／ 357 9．

3．1　微軟的優秀實踐／ 358 9．3．2　谷歌的優秀實踐／ 359 9．3．3　亞馬遜的優秀實踐／ 360 9．3．4　ThoughtWorks 的優秀實踐／ 361 9．3．5　騰訊的優秀實踐／ 364 9．3．6　阿裡巴巴的優秀實踐／ 365 9．4　敏捷過程的反思與持續改進／ 366 9．4．1　敏捷過程的反思／ 367 9．4．2　敏捷測試過程的改進分析／ 368 9．4．3　資料驅動改進／ 369 9．4．4　PDCA 迴圈／ 369 9．4．5　根因分析／ 371 本章小結／ 372 延伸閱讀／ 372 第 10 章　敏捷測試的展望／ 374 導讀／ 374 10．1　大資料

的測試／ 375 10．1．1　大數據的特性與挑戰／ 376 10．1．2　大資料的測試方法／ 378 10．1．3　大資料的測試實踐／ 380 10．1．4　大資料的測試工具／ 381 10．2　人工智慧系統的測試／ 382 10．2．1　人工智慧系統的不確定性和不可解釋性／ 383 10．2．2　人工智慧系統的白盒測試／ 384 10．2．3　人工智慧系統的演算法驗證／ 386 10．2．4　示例：針對智慧語音的設計與執行／ 388 10．3　人工智慧助力敏捷測試／ 392 10．3．1　基於圖像識別技術的UI測試／ 392 10．3．2　基於人工智慧的、全自動化的API 測試／ 397

10．3．3　人工智慧助力代碼深度分析／ 399 10．3．4　人工智慧驅動測試／ 401 10．3．5　人工智慧測試工具／ 403 10．4　敏捷測試工具的未來／ 406 10．4．1　敏捷測試工具的發展趨勢／ 406 10．4．2　MBT 的前景如何／ 408 10．4．3　無代碼化的測試自動化／ 409 10．5　徹底實現持續測試／ 413 10．5．1　重新理解持續測試／ 414 10．5．2　持續測試的實現框架／ 415 10．5．3　持續測試成熟度模型／ 424 10．5．4　徹底的持續測試／ 425 本章小結／ 426 延伸閱讀／ 427 附錄A　基於Kubernetes 和D

ocker搭建Jenkins 可伸縮持續集成系統／ 428 導讀／ 428 A．1　工作流程圖／ 429 A．2　系統組態／ 429 A．3　安裝Kubernetes 集群／ 430 A．3．1　安裝前的準備／ 430 A．3．2　安裝配置／ 430 A．4　Harbor 的安裝部署／ 434 A．4．1　下載Harbor 離線安裝包／ 434 A．4．2　安裝Docker ／ 435 A．4．3　安裝Docker Compose ／ 435 A．4．4　Harbor 的安裝與配置／ 435 A．4．5　用戶端訪問Harbor 倉庫／ 436 A．5　 採用Jenkins Pipeline 實

現自動構建並部署至k8s ／ 438 A．5．1　部署Jenkins ／ 438 A．5．2　新建Spring Boot Java工程／440 A．5．3　配置Jenkins Pipeline任務／ 444 A．5．4　測試Pipeline 任務／ 446 A．5．5　遇到的問題及解決方法／ 449 附錄B　敏捷實踐發展史／ 451 附錄C　後敏捷時代暨DevOps發展史／ 461 附錄D　中國敏捷測試大事記／ 463 參考文獻／ 465

問題單處理與專案派工系統之整合與實作

為了解決專案管理工具jira的問題，作者湯佳天 這樣論述：

目前大部分問題單處理的工具，通常都需要以人工的方式填入實際工時等資訊，不但容易錯誤，有些比較複雜或需要多人處理的問題，不僅不容易追蹤控管，每位成員的實際工時也很難精確地計算出來。同時在資源分配方面，也常必頇使用不同的工具，因此管理階層對於問題單處理，派工及資源分配三方面，也很難有一個通盤的考量。在本篇論文中，我們整合了問題單處理軟體 Jira及可用於派工的軟體 XPlanner。當使用者將問題單填入 Jira 之後，能將必要的欄位匯出到 XPlanner中，此時可以透過 XPlanner 進行分工計畫，派工及進度追蹤。然後在問題解決並確認結案之後，將實際工時匯回 Jira，並將每一個處理問題

的成員的實際工作時數，加總後匯到一個工時匯報系統中。