持续集成的测试规范

测试前规范

1. [RD] RD的提测限于单个模块，并且尽量依赖其他模块的四位版本、tag。无绝对必要，不能依赖其他模块的trunk/分支。如果确有必要依赖其他模块的trunk/分支，需要尽早和翟耀沟通并且确保zhaiyao这个svn账号有该依赖模块的权限，并且需要对hudson job进行较大的调整（目前cbrank对dn-lib的依赖已经调整完毕）
2. [RD] RD首次提测前的开发，在主干上进行开发，在主干上check in。
3. [QA+RD]每次主干上代码发生变动，都会触发hudson上该模块相关的job的一次构建。如果job构建失败，责任方需跟进。（试点期间，暂由QA先定位问题）
4. [RD+QA] RD首次提测（相对于此前的立项，建三位版本），需要确保自己刚刚check in主干，并在hudson job上触发了一次完整的成功的构建。然后在相应的hudson job上（cbrank对应的是cbrank_quick，bs对应的是bs_quick），进行如下"拉RB"操作[前N次由QA代劳]：(1)修改hudson job中promote插件中需要promote的三位版本号，一般来说是上次的三位版本号的末位加1；(2)对最新一次的构建进行一次Promote操作（hudson上的一个按钮）。进行完上述操作之后，hudson job会做这样三件事情（以cbrank 3.0.4）：(1)给这个模块拉出来一个分支cb-rank_3-0-4_BRANCH，该分支的目前的内容和当前trunk一模一样(2)如果依赖其他模块比如dn-lib的trunk，那么也会拉出对应的分支，分支名为cb-rank_3-0-4_BRANCH；(3)新建一个hudson job：cb-rank3.0.4，这个hudson job跟踪和关注cb-rank模块和dn-lib模块的cb-rank_3-0-4_BRANCH分支。
5. [RD+QA] RD首次提测（拉RB），需要发起Code Review。这个Code Review是拉出来RB之后的第一个revision和“线上最新版本”比较。以后每次在该RB上进行check in，不再需要发起code review,而是交给QA建设的CR monitor来执行
6. [QA] QA建设这个branch上的CR monitor。只要这个分支有代码变动，就会自动发出Code Review。
7. [RD+QA]目前关于立项和提测，建议信件/hi沟通。（建议建假的icafe项目，只用于文档管理和讨论）。

测试中规范

1. [QA] QA收到提测任务之后，确认提测的分支，hudson上的对应新job，并且对该分支保持关注。
2. [QA] QA需要测试的是hudson对应job的产出结果，QA的测试结论仅对该job的编译结果负责。
3. [QA] QA需要发出测试设计，测试设计用信件方式发送。（如果有对应的假icafe项目，那么在项目中进行。）
4. [RD] RD需要认真阅读QA的测试设计。
5. [QA] QA的测试流程一般是：冒烟测试(准入测试)、冒烟性能测试、新功能测试、回归测试、性能测试。除非必要，否则不应该改变顺序。
6. [RD+QA] QA可以提供给相关RD准入测试用例（准入测试用例的执行不应该超过15分钟）。一旦QA提供，RD必须先自测通过准入测试之后方能提测。
7. [RD+QA] QA如果发现bug，仍然需要提交trace。RD修复bug的时候，需要在trunk和branch上同时修复该bug。
8. [QA]项目测试结束后，QA必须把新功能用例移动到E家宝的checklist中，并给出是否自动化的建议。

测试后规范

1. [QA] QA提交测试报告：QA需要在测试完结之后，计划上线的当天上午（或者更早）邮件提交测试报告。
2. [QA] QA清理hudson job。
3. [QA+RD]在QA对某个RB测试完成，认为可以上线的时候，由RD用邮件流程，提供需要上线的bin和conf的下载链接和md5、上线步骤给OP发起“线上操作”，QA需要回复确认并附上测试报告。由于bug均同时fix到主干上，所以不需要进行merge回主干的操作。
4. [RD+QA] QA需要进行线上情况验证。验证之前QA需要列出来需要验证的点，能够直接观察到的现象需要观察。如果不能直接观察到的（比如线上机是否出wf日志等），需要提供check list让RD去验证。
5. [OP] OP根据信件中的bin和conf，并校验md5，完成上线。

bug的规范

注：此处只针对QA报的bug。RD提交的功能性trace不需要满足此规范。关于bug的规范、定义、流程，可以参考附件中的资料详细学习。

1. [QA] QA提交bug的时候，需要描述清晰，字段填写准确。在力所能及的情况下进行初步定位。责任人需要准确填写，关注人需要填写：RD的该模块负责人、RD负责人、QA负责人、测同一项目的其他QA。
2. [QA] QA报的bug一般要遵循附件中的模板。Code Review出的bug可以不遵循模板，但是标题中需要以[CR]开头。
3. [RD+QA] QA只能open和close, active bug，原则上不能resolve bug；RD只能open,resolve,active bug，不能close bug。
4. [RD] RD reslove bug的时候，必须描述清楚：root reason,修复方法需要精确到源文件和具体行，修改的代码）。QA认为写的不完善时候，必须联系对应RD重写或者补充。
5. [QA]每周周会会做Bug分析，Bug分析结果中，视情况会抄送给RD邮件组。(该条暂缓执行)

SVN规范

1. [RD] RD check in代码要保证Check in能够使得Check In之后该模块能够编译成功，并完成基本功能。注：comake文件是QA唯一认可的编译依赖管理文件，comake文件内容遗漏、错误、过期，视同无法编译。
2. [RD] RD每次Check in代码，必须写含义清晰的Comment：Feather开发必须有Feature编号或者描述、Bug修复必须有Bug编号等必要信息。