测试编写规范

转自：http://www.iteye.com/topic/478306

×） 单元/集成测试方法的编写规范：
测试代码编写规范：
×）准备测试数据
×）执行预准备步骤
×）调用测试方法
×）做（输入输出）期望检查
×）每个测试方法避免测试太多逻辑，测试单一点。
×）每个测试代码除去注释，实际代码行数不得多于30行。
注释规范：

×）方法前
×）加以注释此方法的测试目标，
×）方法内：
×）如果需要准备测试数据，以业务语义描述测试数据的“模样”
×) 如果需要模拟某些操作步骤来准备测试数据，则描述这些操作步骤的业务语义
×) 以明确的注释描述期望行为
×) 如果是针对业务功能的测试，注释能够足够清晰到业务人员来看懂并审查。



准备测试数据规范：
×）数据库数据准备使用DBUNIT来准备。
×）保证每个测试之间的测试数据不存在相互影响和依赖
×）准备测试数据的代码应尽可能简单，避免繁琐
×）涉及到workflow级别的测试数据准备，允许以符合业务操作语义的步骤来准备数据。

×） 公用模块/工具类必须保障充足的单元测试，这些测试在功能编码完成时，就应该一起完成。




×）在功能开发期，为了保障功能开发的进度，在充分保障对产品代码的审核，检查，设计指导的前提下不强制要求开发人员针对功能做集成测试，
但是尽可能重构/抽取其中的“易测”代码进行单元测试。

×）单元测试/集成测试的编写步骤严格按照团队制定的规范进行。测试代码与产品代码的重要程度一致，在代码审核，代码检查，编写指导这些方面
    的重要程度均与实际产品代码完全等同。

×）明确开发人员的测试范围：
×）界面的bug，复杂JS动作的bug等等，不作为开发人员的测试范围，而是作为手工测试人员的测试范围。并强调有测试组长重点把控。
×）功能实现上的bug作为开发人员的测试范围。
  

×）功能集成测试的积累：
×）测试人员发现的bug的解决至少有一个相应的集成测试，如果不能提供，在提交的情况说明中，说明这个理由并得到测试人员
   以及小组组长的认可。（界面的bug，复杂js动作的bug等等不要求有集成测试）
×）测试人员参与到对bug的fix 的工作检查中，包括手工测试的审核、bug的测试代码的审核

×）测试人员针对开发人员编写的集成测试代码的审核规范：
×）从业务语义看注释，是否反映了bug的问题重现过程以及修复确认过程。
×）从代码角度来上审核代码的编写是否足够易懂易读。
×）代码审核不通过不能确认这个修复。

×）期望达到的目标：随着项目从功能开发期--》测试完善期--》产品交付期--》产品维护期的过渡，保障这期间所发现的任何一个功能bug
   都有一个对应的测试加以保障得到解决，大大降低产品维护期的代码修改的测试成本以及风险。