做好了第一部分（通过Fault 列表批量创建Jira Issue功能），发现这个实用的功能可以节省很多自己的工作时间。
但是新的问题又来了，自己很多工作不仅仅为每个工程师创建Jira issue，还有部分工作是给每个Fault在Fault管理系统上添加需要Merge代码所需的Correction Form，让工程师在对应的Correction Form上填写对应的版本信息，保证公司当前开发与维护的分支上不会再出现这个问题。
然而就像我之前说的一样，使用公司的网络连接Fault管理系统实在是慢，而且自己需要根据每个月都会变的Correction Policy 来创建至少4个Correction Form。当下自己管理的Fault至少有30个，这样为每个Fault一一创建Correction Form，基本上自己可以不用干其他事情了。
所以客户 （也就是我自己）又提出了下面新的需求：
- 通过命令行创建对应的Correction Form
- 解析对应的Policy创建对应的Correction Form
- 支持对多个Fault一次性创建
下面对自己的需求进行分析：
- 工具支持模拟浏览器在Fault管理系统上创建Correction Form
- 工具可以解析相关的Correction Policy
- 工具支持提供命令接口来支持对多个Fault的一次性操作
而在技术层面，不像之前第一部分一样，可以直接使用Jira库的Reset API，而必须自己找到Fault管理系统的规律，使用工具模拟浏览器在Fault管理系统上操作。
所以自己在这次快速迭代中将User Story拆分成以下几个小Task，这也是Agile中重要的一步，将大的项目拆分小的Task，每个Task都经过测试，具备集成和可运行的特征。
- 使用浏览器对Fault管理系统创建Correction Form进行观察记录
- 采用对应的Python库对观察到的数据交互进行模拟
- 对Correction Policy的网页进行解析，抽取出有用的信息
- 添加命令行接口，对需求进行支持。
将任务分解后，自己便开始对每个小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了。
