测试驱动开发与CMMI5的精简应用

上一篇 / 下一篇 2006-12-22 17:47:29

51Testing软件测试网b;g7ItJBZ

51Testing软件测试网u(a3@,kz

第一部分实施过程

为了提高产品的质量以及更好地对项目进行控制，在产品开发与测试过程中，由测试驱动开发，并引进了CMMI5流程。考虑到CMMI5在小型项目中的成本过高，在项目实施的过程中精简了CMMI5的实施流程和部分文档，这个精简的流程在项目实施的过程中取得了良好的效果，在此主要就测试方面在项目中的应用进行简述：51Testing软件测试网qd:h'\k

eL eEhC'xj0 1、需求与规范的管理：（1）由测试负责人统一接收相关规范和新需求，测试负责人浏览获知大意将规范和新需求转发给开发经理、项目经理、相关的开发人员和测试人员，同时commit到CVS；（2）测试负责人与项目经理一起对规范和新需求进行研究，并就难点和疑点与项目经理讨论，整理出重点内容，并将重点内容发给开发经理、项目经理、相关的开发人员和测试人员，同时commit到CVS；（3）开发经理、项目经理、测试负责人、相关的开发人员与测试人员开会对规范、需求和重点内容进行讨论，确定最终实现的需求和功能点；（4）项目经理根据规范、需求和开会讨论结果整理新功能列表，测试负责人对新功能列表进行检查并修改，然后commit到CVS；（5）测试负责人确认所有相关文档都已经commit到CVS。51Testing软件测试网!j6k-[)H/ic

rC(k:j2K3jx0 2、项目计划与测试计划：（1）由开发经理组织项目计划讨论会，在讨论会上各开发负责人对自己所负责的模块所需要的工作量进行评估，根据工作量和工程需求初步确定总体开发计划、测试计划和发布时间；（2）测试负责人根据项目计划与发布时间编写测试计划，使用CMMI5总体测试计划模板并对其进行适当的裁剪和补充，编写适合本项目的测试计划；（3）测试计划编写完成后发送给开发经理、项目经理、相关的开发人员和测试人员，开发经理、项目经理、相关的开发人员和测试人员阅读测试计划后将建议和意见以邮件的形式反馈给测试负责人，测试负责人收集大家的邮件中对测试计划进行修改完善，同时回复邮件说明测试计划修改情况，如果存在争议则召开一个小型会议对异议进行讨论，修改后的测试计划commit到CVS。

3、开发设计与评审：（1）项目经理负责编写概要设计文档、数据库设计文档和编码规范，各模块负责人负责编写所负责的模块进行详细设计，发邮件通知开发经理、项目经理、测试负责人、相关开发人员和测试人员；（2）开发经理、项目经理、测试负责人、相关开发人员和测试人员对所提交的详细设计文档进行审查，将建议和意见以邮件的形式反馈给模块负责人；（3）模块负责人收集邮件中的修改建议并对详细设计文档进行修改，同时回复邮件说明详细设计修改情况，如果存在争议则召开一个小型会议对异议进行讨论，修改后的详细设计commit到CVS；（4）测试负责人对开发最终修改的详细设计计划进行检查，并确认所有文档都已经commit到CVS。51Testing软件测试网'z e bKW zQ

4、测试设计与评审：（1）在项目的编码阶段，测试负责人根据规范文档、功能列表和设计文档编写测试方案和测试用例；（2）测试用例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等，在用例设计中，除了功能测试用例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题；（3）在编写测试案例的过程中，对于存在疑问的地方或测试重点，主动与开发负责人或项目经理沟通讨论，一方面有助于设计完善的测试案例，另一方面也有助于开发进一步清晰编码思路；（4）测试方案与测试用例编写完成后，发邮件给开发经理、项目经理、相关开发人员和测试人员；（5）开发经理、项目经理、相关开发人员和测试人员对所提交的测试方案与测试案例进行审查，将建议和意见以邮件的形式反馈给测试负责人；（6）测试负责人收集大家的邮件中对测试方案和测试用例进行修改完善，同时回复邮件说明修改情况，如果存在争议则召开一个小型会议对异议进行讨论，修改后的测试方案与测试用例commit到CVS；（7）测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。

5、测试实施：（1）代码提交前一天准备相关的测试环境（如服务器或数据库等），代码提交后测试人员向Build Master申请打包，并搭建正式测试环境，为了不做到测试以及确保产品可以跨平台，每个测试人员各自搭建一个测试环境，每个平台至少要有一个以上的测试人员负责；（2）测试环境搭建好后进行烟雾测试，如果烟雾测试通过则继续详细的功能测试，否则中断测试并返回给开发；（3）测试人员按照预定的测试计划和测试方案逐项进行测试，在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来，填写测试记录，在必要的时候协助开发追踪与修改所发现的问题；如果在测试的过程中发现重大的bug或因为某些bug导致测试不能继续，测试中断并返回给开发；（4）每个测试阶段测试结束后，由测试负责人总结测试情况，对测试结果进行分析和下一阶段测试可能引进的bug数量进行预测，并提交“测试阶段分析报告”，并发送给开发经理、项目经理、相关测试人员和开发人员；（5）开发经理对测试阶段分析报告中存在的问题采取恰当的措施和调整相关资源，确保下一阶段的开发与测试计划顺利进行；（6）开发对bug进行修改；（7）开发对bug修改后测试人员进行回归测试，经过修改的软件可能仍然包含着错误，甚至引入了新的错误，因此，对于修改以后的程序和文档，按照修改的方法和影响的范围，必须重新进行有关的测试；（8）产品的功能比较完善后，进行产品的性能压力测试，并根据测试结果进行性能调优；（9）当测试产品达到测试计划所制定的产品质量目标和测试质量目标，整理产品发布包和编写相关文档，确认发布包和文档完整后进行产品发布，必要的文档必须包括：A）安装操作手册、B）产品白皮书、C）管理维护手册、D）用户操作手册、E）测试报告51Testing软件测试网To ~oX

51Testing软件测试网qr)?0AIz
6、产品发布：当测试产品达到测试计划所制定的产品质量目标和测试质量目标，整理产品发布包和编写相关文档，确认发布包和文档完整后进行产品发布。对于新产品来说，必要的文档必须包括：51Testing软件测试网|ma)A4v.r
（1）安装操作手册51Testing软件测试网&Y@%by:w&^\j
（2）产品白皮书51Testing软件测试网 X!Q{(Iq
（3）管理维护手册
#u+Ce-I i2K-KLqxLJ"O0（4）用户操作手册
k5D9k Ri0（5）测试报告

7、版本控制：新版本软件发布之后，马上对代码进行质量控制。
XodBO5skQ0（1） Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为IAGW1.0.0，则给该软件源代码也打一个与发布版本相同名字的tag IAGW1.0.0。这样做的一个好处是，在目前的软件的基础上做了修改并发布新的版本后，如果需要check out某个版本的源代码，则可以通过这个版本的tag来check out，代码的修改可以在该版本上进行。51Testing软件测试网g;H?Qy(B
（2） Build Master对新发布的软件源代码进行cvs lock，不允许开发人员在软件发布之后commit源代码，直到有新版本需求修改再给开发人员开放commit权限。这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源版本版本与当前最新的发布版本一致。
8、在需求与规范管理中，由测试负责人与项目经理同时管理、控制与讨论，使需求的管理与变更有了一个严格的控制，经过开发经理、项目经理、测试负责人、相关开发人员和测试人员讨论过的需求实施起来更加准确完备，确保开发出来的产品符合规范和客户需求；测试负责人自需求阶段参与整个项目，有利于对项目的理解，为测试设计和测试实施打下基础，同时在此过程中可以起到保障产品质量的作用。

第二部分应用说明51Testing软件测试网j"W yD$k]
   项目计划、测试计划编写前先开会讨论，由模块负责人估算工作量，能确定的问题和时间安排都在讨论中确定下来，然后根据工作量和工程需求制定项目计划和测试计划；开发在编码前需要进行概要设计和详细设计，确保开发在编码前对自己所负责的模块有一个清晰的设计思路，经评审后确认模块的设计是否合理；计划或设计都是以邮件的形式进行评审；对于存在严整分歧的问题，组织一个小型会议进行讨论有效解决问题，对于规范中不明确的问题集中后由测试负责人直接与移动总规范负责人直接交流，确保不会因为规范的理解不正确导致项目实现与需求不一致。
:B+eT ^r.O[0  测试工作中，在项目编码阶段，测试负责人对项目进行测试设计，指导测试实施有依可循，在编写案例的过程中会遇到很多与流程和细节处理相关的问题，与开发一起讨论也有助于提前发现问题与完善代码；在测试实施阶段，测试人员记录所发现的问题，并协助开发及时解决，在测试过程中所遇到的问题，测试负责人进行记录和分析，在每个阶段完成后提交经分析后的测试阶段报告，在软件测试阶段报告中总结分析了测试过程中所发现的问题并对这些问题提出解决建议，在后续的开发与测试中进行改进与调整，确保项目能够按时保质发布。软件的管理和版本管理则由Build Master负责，确保软件得到良好的控制。
@#AiNt{ V7y0   在这个小型的项目实施中并没有完整实施CMMI5，但是，CMMI5的思想在这个过程中得到了很好的体现，比如在需求与规范管理阶段：（1）需求由测试负责人收集，由项目经理、开发经理和测试负责人讨论，就相当于是一个小型的CCB，节约了资源，也确保了质量；（2）经初步讨论过的需求与规范整理出重点内容（相对于CMMI5的项目愿景与范围的简化版本）后，相关的人员再在一起讨论，这样可以更加有的放矢，需求讨论的效果更加明确；（3）在讨论过程中确定功能列表，明确了开发与测试的功能（相当于CMMI5的需求评审后的项目功能列表）；（4）所有的相关的文档都需要commit到CVS，测试负责人确认所有相关文档都已经commit到CVS，进行了PPQA的检查工作（在其余阶段也是如此）。
   在整个流程中，测试负责人除了负责测试相关任务以外，同时承担了需求管理、流程跟踪、协调沟通等工作（当然，也可由项目经理或开发经理等担任），在其中由测试推动项目开发与实现，在开发成员之间、开发与测试之间搭了一座良好的桥梁，这样的一个协调与推动促进了项目的顺利完成，适合于五至二十的小型团队。测试驱动开发的模式，对测试负责人的要求很高，需要测试负责人具有很高的业务理解能力、沟通协调能力和CMMI5实施经验。