代码缺陷密度计算

代码缺陷密度

代码缺陷密度是一种度量代码质量的指标，这里采用 按照每个bug的严重程度定义它们的权重，然后加起来得到总缺陷值，最后除以KLOC(千行代码）得到每千行代码的缺陷密度。

禅道bug值

为了获取bug的相关信息，我决定爬取禅道项目的bug提交列表。
其实禅道的api文档写的很简略，单看一篇根本看不懂，我看了好几篇，又问了客服，自己又试了好多次，才获取到目标数据。
URL：http://zentao.talbrain.com/pro
1 登录 /user-login.html
/index.html
Post方法，带着账号和密码。
2 获取sessionID
/api-getsessionid.json
Get方法 ，得到sessionID.
3 带着sessionID访问目标网页
'/pro/bug-browse-(项目编号)-(分支编号)-(查询方法)-(排序方法)–(总查找数)-(每页展示数)-(第几页).json?zentaosid=(sessionID)
Get方法，得到目标网页的api数据（并不是网页看到的数据）。
例如 /bug-browse-88-0-all-opendate_desc–1-2-1.json?zentaosid=1234567
这里设置 总查找数小于每页展示数，就可以把全部数据在一页里显示。
为了保持登录，我使用requests模块里的session方法，在同一个session里进行上述操作。
4. 解析返回的api数据。
对于返回的api数据，需要进行一系列转码解析操作。

遇到类似的编码问题时，先检查响应内容text是什么类型，如果type(text) is bytes，那么
text.decode('unicode_escape')
如果type(text) is str，那么
text.encode('latin-1').decode('unicode_escape')。

例如，这就是解析完成的一条bug的基本信息。

{'id': '45494', 'product': '33', 'branch': '0', 'module': '13551', 'project': '562', 'plan': '0', 'story': '0', 'storyVersion': '1', 'task': '0', 'toTask': '0', 'toStory': '0', 'title': '验证点击‘一级组件’弹窗能否进行收起或者下拉,点击收起二级菜单，显示错误', 'keywords': '', 'severity': '2', 'pri': '2', 'type': 'codeerror', 'os': '', 'browser': '', 'hardware': '', 'found': '', 'steps': '<p>[前置条件]<\\/p>\n显示在音频配置界面，组件名称列表默认为展开状态<p>[步骤]点击二级菜单进行收起，默认跳转到其它一级展示菜单<\\/p>\n<p>[结果]<\\/p>\n<p><img src="{24398.png}" alt="" \\/><\\/p>\n<p>[期望]<\\/p>', 'status': 'active', 'color': '', 'confirmed': '0', 'activatedCount': '0', 'activatedDate': '0000-00-00 00:00:00', 'mailto': '', 'openedBy': 'Tom', 'openedDate': '2018-11-23 14:51:59', 'openedBuild': '主干', 'assignedTo': 'Jerry', 'assignedDate': '2018-11-23 14:51:59', 'deadline': '0000-00-00', 'resolvedBy': '', 'resolution': '', 'resolvedBuild': '', 'resolvedDate': '0000-00-00 00:00:00', 'closedBy': '', 'closedDate': '0000-00-00 00:00:00', 'duplicateBug': '0', 'linkBug': '', 'case': '47910', 'caseVersion': '1', 'result': '7669', 'repo': '0', 'entry': '', 'lines': '', 'v1': '', 'v2': '', 'repoType': '', 'testtask': '153', 'lastEditedBy': '', 'lastEditedDate': '0000-00-00 00:00:00', 'deleted': '0', 'needconfirm': 'false'}

这里我需要project(分支),severity(严重程度),openedDate(提交日期)。
5. 实际上可以看到在api数据里，project分支信息使用数字来编号的，看不出来该bug实际属于哪个分支。我还需要一个编号和分支名的对应关系。
/project-index.json?zentaosid=1234567
Get 方法，获取所有分支和编号的对应关系，解析为字典。
6. 把每条bug数据的project值在分支字典里查到对应的名字，然后归类。由于项目的命名格式差别很大，所以我把带有‘EN’和‘英语’的都算作英语分支。
7. 在api数据里，severity对应的编号是可以后台修改的，在咨询过开发团队后，才得到正确的bug严重度分级，也就是说，还是要自己建个权重对应关系。
8. 最后把每条bug的权重加到对应的分支里。

除了这个，还有一个缺陷分布，计算每个分支下，每种bug的个数。这里需要api数据里的type(类别)。同样，根据需求里的代码，性能，环境等种类，与type值的codeerror,performance,envissue相对应。

gitlab代码行数

使用python的python-gitlab模块

参考文档

api机制简介
需要登录验证的api调用
关于bug的禅道接口