这几天我一直在琢磨这里面我的观点以及这里面我没有深刻理解的东西，甚至于我还深究我导致我的观点的外在以及内在因素。

　　我体会到： 其实你是可以做得更好的。

　　反思我自己带过的项目，其实在测试方面确实可以做得更好，而做得更好的途径的就是“ 明确在项目里该如何积累、保证充足的测试，并使得这些测试是易维护的”，测试在以前的项目，确实还不够，但是为什么存在“测试不够”的情况下，项目仍然朝着很好的方向走呢？ 其中很多原因在“简单就是检验设计的唯一标准”哪里陆续都有提到，因为对这些因素的掌控力以及较强的执行力，所以使得项目能够按照正确的方向发展，而恰恰就因为这些“强势”因素让我忽略了作为开发人员应该承担的测试角色。

　　是否让开发人员写功能测试，这个问题本身讨论起来似乎很可笑，但是实际运作起来，它会有多种后果，我觉得最危险的就是因为没有足够的标准以及规范来指导开发人员如何编写有效、简洁、易读的测试，导致测试本身成为“垃圾产出”而增加项目的成本，说实在话，直到前几天我都没有构思一个足够有效的代码编写测试规范，我们团队的核心成员可以写出简洁、优美的测试代码，但是并没有把这个东西抽取出来作为团队的灵魂之一，加以贯彻、指导、规范及实施。从这个角度来看，在之前的项目采取的策略其实是为了避免这种担心的后果而作出的决定，而现在我已经构思出一个明确的可以执行的测试指导原则，那么这之前的策略确实应该发生改变，这样也会使得项目的质量完成得更好，维护成本更低，反馈变化速度更快。

　　那么该如何有效开展测试呢？

　　我先抛砖引玉的提出我的观点，这些观点或许作为接下来的我们公司项目的测试指导规范，这可能需要一个反复实践的过程：

　　单元/集成测试方法的编写规范：

　　测试代码编写规范：

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

　　注释规范：

　　方法前

• 加以注释此方法的测试目标

　　方法内：

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

　　准备测试数据规范：

• 数据库数据准备使用DBUNIT来准备。
• 保证每个测试之间的测试数据不存在相互影响和依赖
• 准备测试数据的代码应尽可能简单，避免繁琐
• 涉及到workflow级别的测试数据准备，允许以符合业务操作语义的步骤来准备数据。
• 公用模块/工具类必须保障充足的单元测试，这些测试在功能编码完成时，就应该一起完成。
• 在功能开发期，为了保障功能开发的进度，在充分保障对产品代码的审核，检查，设计指导的前提下不强制要求开发人员针对功能做集成测试，但是尽可能重构/抽取其中的“易测”代码进行单元测试。
• 单元测试/集成测试的编写步骤严格按照团队制定的规范进行。测试代码与产品代码的重要程度一致，在代码审核，代码检查，编写指导这些方面的重要程度均与实际产品代码完全等同。

　　明确开发人员的测试范围：

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

　　功能集成测试的积累：

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

　　测试人员针对开发人员编写的集成测试代码的审核规范：

• 从业务语义看注释，是否反映了bug的问题重现过程以及修复确认过程。
• 从代码角度来上审核代码的编写是否足够易懂易读。
• 代码审核不通过不能确认这个修复。

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