DevSuite 实践之瀑布篇（二）

在一个需求设计完成并审核通过以后，这个需求就可以被添加到开发项目中进行开发工作（如下图）

 

 

 

在添加到开发项目过程中，DevSuite可以根据功能的模块组成把一个功能点分解成不同小的模块，分配给相应的开发完成，比如这个功能需要在管理员完成一部分，需要在客户端完成一部分，需要在服务器端也完成一部分，这样子就需要分解成三部分，可能会交给不同的三个人来完成。

 

 

 

对于这个开发过程，DevSuite也有一个相应的模块来管理这个过程（如下图）

 

 

 

对于任何的开发任务，DevSuite中可以直接通过需求产生任务的方式来产生任务，当然也可以根据自己的需要自己添加新的任务（比如发现的Bug），这些任务都有自己的属性（比如标题，描述，负责人，状态等等），每个开发人员登录系统以后，就能看到自己名下有没有任务，然后根据任务的描述之类的信息就可以开始开发工作，开发完成以后只要更改一下任务的状态就可以让主管知道这个开发任务完成了。

 

 

 

对于开发的任务，DevSuite提供了多个有效的方式来保证开发的质量与进度：

 

 

 

自动通知与调整：DevSuite能够设置自动提醒功能，让一些需要被重点关注的任务更加重视起来，该任务的负责人会收到自动发送的邮件或者短信来提醒他，甚至当完成一些重要事件的时候，也有相关人员可以被自动发送的邮件及短信通知到。而一旦出现某些任务长时间没有处理等情况，DevSuite还能根据设置来自动调整这些任务给其他人处理。

 

 

 

任务时间跟踪：DevSuite可以设置针对任务级别的时间跟踪，对于每个任务可以设置已花费时间与剩余时间，这样子就能很直观地看到任务的完成度，进而看到整个项目的一个完成程度。

 

 

 

与代码相关联：DevSuite可以与目前基本所有主流的版本控制工具做集成，比如Subversion，Perforce等，这样就能直接把一个功能与相关的代码关联到，万一以后需要修Bug或者更改功能，开发就能直接知道这个功能或者Bug与哪块代码的哪个版本相关，极大地提高了处理效率。

 

。。。。。。

 

 

 

当所有的开发任务完成以后，就相当这个产品已经开发完成了，那就可以进度测试这个环节了，DevSuite中也有专门关于测试这个模块（如下图）

 

 

 

 

在 DevSuite中，产品的测试是按照下面的流程来进行的:

 

首先需要建立测试用例，测试用例主要是针对某个功能点需要覆盖哪些方面，进行怎样测试的一个说明，可以帮忙测试人员实际测试时有个向导。在DevSuite中，对于测试用例还有两个重要的功能，一个叫做环境变量另一个叫做检测点，环境变量的意思就是这个测试用例需要覆盖哪些测试环境，比如哪些操作系统，哪些数据库等等，而检测点的意思就是说对于一个测试用例，我们可以设置它要覆盖哪些检测点，对于这些设置好的测试点，我们可以进一步设置规则，比如说，只要一个检测点不通过，整个测试用例就不通过，或者是所有检测点通过了，这个测试用例才算通过。这个检测点主要是用于对于测试细节特别注意的行业，一般用瀑布模式的行业都是对质量非常重视的，所以这个功能对于它们还是很有意义的。

 

 

 

当测试用例完成设计以后，DevSuite中就会开始用测试用例来生成测试任务，为什么要这么做呢？因为DevSuite认为测试用例是测试的一个基点，并且是可重用的，在真正的进行测试时，首先对于一个测试用例，它必然会用到好几次，首次验证性测试，还有回归测试都能用到，甚至下一个版本测试时，只要这个功能还在，它还是需要用到，所以它是这个功能测试的一个基点，能够可重用的。

 

 

 

当用测试用例产生测试任务以后，真正的大规模测试就开始了，每个测试任务都有与测试用例类似的属性，比如标题，测试过程，期望结果，测试负责人等等这些属性，所以每个测试人员进入系统就可以看到自己被分配到的测试任务，然后一看测试过程就知道自己需要测什么功能了，测试完了以后，发现问题就可以直接提交Bug到集成的缺陷管理系统中，如果测试通过就可以直接把这个测试任务关闭。

 

 

 

当经过几轮测试以后，产生的Bug也得到了不断地修复，最后当我们通过报表看到重要的Bug基本都修好了，几轮测试发现Bug趋势在不断下降中，产品就差不多已经可以发布了，当然如果还需要更严格的发布标准，DevSuite能够分析出哪些功能还存在Bug的几率比较高，可以再继续对一些重点的地方进行一些测试或者再进行几轮测试。

 

 

 

通过这么一个从需求到开发到测试全程的集成处理，DevSuite系统帮助完成了这个产品发布的管理，这个就是瀑布模型在 DevSuite 系统中怎么进行处理的一个简单的过程描述。