做好了第一部分（通過Fault 列表批量創建Jira Issue功能），發現這個實用的功能可以節省很多自己的工作時間。
但是新的問題又來了，自己很多工作不僅僅為每個工程師創建Jira issue，還有部分工作是給每個Fault在Fault管理系統上添加需要Merge代碼所需的Correction Form，讓工程師在對應的Correction Form上填寫對應的版本信息，保證公司當前開發與維護的分支上不會再出現這個問題。
然而就像我之前說的一樣，使用公司的網絡連接Fault管理系統實在是慢，而且自己需要根據每個月都會變的Correction Policy 來創建至少4個Correction Form。當下自己管理的Fault至少有30個，這樣為每個Fault一一創建Correction Form，基本上自己可以不用干其他事情了。

所以客戶 （也就是我自己）又提出了下面新的需求：

1. 通過命令行創建對應的Correction Form
2. 解析對應的Policy創建對應的Correction Form
3. 支持對多個Fault一次性創建

下面對自己的需求進行分析：

1. 工具支持模擬瀏覽器在Fault管理系統上創建Correction Form
2. 工具可以解析相關的Correction Policy
3. 工具支持提供命令接口來支持對多個Fault的一次性操作

而在技術層面，不像之前第一部分一樣，可以直接使用Jira庫的Reset API，而必須自己找到Fault管理系統的規律，使用工具模擬瀏覽器在Fault管理系統上操作。

所以自己在這次快速迭代中將User Story拆分成以下幾個小Task，這也是Agile中重要的一步，將大的項目拆分小的Task，每個Task都經過測試，具備集成和可運行的特征。

1. 使用瀏覽器對Fault管理系統創建Correction Form進行觀察記錄
2. 采用對應的Python庫對觀察到的數據交互進行模擬
3. 對Correction Policy的網頁進行解析，抽取出有用的信息
4. 添加命令行接口，對需求進行支持。

將任務分解后，自己便開始對每個小Task進行設計分析以及實現

Task 1

自己這個Task主要是想知道瀏覽器在Fault管理系統上操作（創建Correction Form）最后產生的Http交互到底是什么樣子的。一般來說，Web上Http的數據交互最常見的有兩種：Get和Post，而知道瀏覽器和Fault管理系統如何交互后便可以模擬瀏覽器向Fault管理系統交互數據，也就可能達到創建Correction Form的目的。
但是這個交互如何知道呢？
打開Chrome或者Firefox的開發工具，然后點開網絡，在對應的網站上執行操作，這樣相關數據的交互便一目了然。

瀏覽器抓取交互數據

在Fault管理系統上創建Correction Form，然后從瀏覽器上抓取數據交互進行分析，發現是Get方式，而且如何Get也是一目了然。
仔細分析下Get的相關數據，發現瀏覽器向服務器Get對應的Release和Build并且加上Fault的UnID然后服務返回對應的網頁讓瀏覽器顯示。
為了驗證這一發現，自己依葫蘆畫瓢，將其中的Release和Build信息改變，然后在瀏覽器試試。果然，創建了想要的Release和Build的Correction Form，而且在完全沒有實際操作Fault管理系統的情況下完成。
嗯，第一個Task可以commit了。