1.3 实战演习

为了让大家对VSTS有更清晰的认识，阿超举了如下的例子。

假设通过几次会议，大牛把“实现用户注册”的用户需求搞清楚了，阿超和果冻写了初步的功能说明，也通过了审核，看起来都不错。

阿超建立了一个任务：实现用户注册功能，阿超把它分派给果冻。

阿超建立了一个任务：测试用户注册功能，阿超把它分派给荔荔。

阿超：果冻，你觉得几天可做完？

果冻：一天就够了，事实上一个上午就能写好。

于是果冻稀里哗啦就把它做好了，于是把代码签入，并且把任务状态改为完成。

构建服务器发布了一个新的版本。荔荔得到新的版本，开始测试果冻新写好的功能，结果发现不少问题，于是新建几个“缺陷”：23、24、25，并且把这些缺陷都链接到最初的“实现用户注册”任务及“测试用户注册功能”任务。

大牛用Excel管理项目，一看新增加了3个缺陷，这还得了，立马把这些缺陷都分派给果冻，并根据缺陷的严重程度赋予不同的优先级。大牛修改后，用“发布”功能把修改上传到数据库中。

果冻浏览了一遍分派给自己的缺陷，改了缺陷23，这是明显属于自己的错误，修改代码后，签入，并且把缺陷的状态改成“解决”，送给荔荔。果冻把另一个缺陷24给了大牛，因为需求说明书没写清楚在这种情况下怎么做，需要说明；第三个缺陷25，果冻送给了荔荔，因为在自己的环境中没法再现问题。

大牛拿到了缺陷24，觉得的确有问题，和阿超及其他同事讨论如何解决。讨论的结果是目前也不清楚，双方同意到下个里程碑再讨论。于是大牛在征得阿超的同意后，就“推迟”缺陷24到里程碑2。

荔荔得到了缺陷25，验证在自己的机器上是有这样的问题，就把果冻揪到自己的机器前，果冻捣鼓了半天，发现是安装程序出的错，于是他们把缺陷25交给小飞，因为是小飞负责的安装程序。

小飞：我招谁惹谁了，干吗把我拉上？

一星期之后，阿超和大牛，测试组长阿亨一起复查报告。上面列出哪些任务还没有完成，哪些任务产生的缺陷最多，等等。

例如，图1-27说明了在一段时间内缺陷的走势。

图1-27 缺陷形势（Bug Rates）报表