和各位亲交流一下我对的想法，欢迎各位专家拍砖。我认为，成功的自动化测试工程的成功公式为：

　　成功（100%）=高效的自动化测试框架平台（30%）+合理科学的自动化测试策略及实现（35%）+持续运营维护（25%）+其他（10%）

　　高效的自动化测试框架平台（30%）：

　 　咱们测试部门现在的自动化测试框架的水平，在全国绝对处于非常领先的地位。全国的IT企业里面，拥有和我们类似框架的没有几家。我们现在已经越过了河 流，游到了对岸，而大多数还在摸着石头尝试过河。我们的改变也是最近几个月的事情，之前虽对自动化工具有所研究，但纯粹靠编程来实现自动化测试，不适合我 们公司（稍有修改，就需要重新编译打包，没人喜欢；我们的业务测试人员的编码水平也不足以完成大量用例的编写）。

　 　虽对取得的成绩自豪，但是咱们的工具还没到冰封代码的时刻，我们还有很多想法需要花时间和精力去实现，也需要更多的人力……新的正能量的加入，是个很好 的开始。我也写好了半年开发计划，期待半年后，一个更完整，遵循简单、高效理念的框架为大家所喜爱。这个30%，测试工具开发部门可以拿到满分的 120%！

　　合理科学的自动化测试用例设计策略及实现（35%）：

　　自动化测试用例设计策略是个很大的话题，需要我们在实践中不断总结：

　　需要自动化的比例？

　　–》自动化测试属于的一部分，自动化测试带来效率改变的同时，也需要花费很多精力去创建及维护测试脚本，需在投入和产出之间找到平衡。把Testlink上面所有的功能用例都自动化—即使这是未来的规划方向—这也是不现实的。那些最稳定、功能最重要的功能模块才需要自动化。

　　自动化什么样的用例？

　　–》用 例的设计有横向与纵向之分，工程学上以较长为纵、较短为横，纵向指的完整的业务流程用例设计，横向设计即切面设计，把功能模块从大向小细分。 Testlink上面的用例大都属于后者，事无巨细都考虑的很清楚。对于自动化测试，因投入成本问题，选取纵向设计的用例比较科学合理。建议：重新设计合 理的自动化测试用例，而不是简单盲目选用testlink上面已有用例。你，如何认为呢？

　　相信自动化测试用例数目吗？

　　–》打开testlink，咱们的“NGB系统端”和“SmartTV系统”的用例数在8000左右啊！！！8000个用例全都自动化实在没有必要，也没可能。大部分用例也是只有标题，没有内容。还不如80个覆盖重要功能的完整业务流程的纵向测试用例实在啊！

　　……

　　持续运营维护（25%）：

　　自动化测试不是一次性筷子工程，而是需要我们不断的运营维护，我们运营维护的时间越长，从中受益也越大。运行后及时分析结果，反馈bug给开发或者完善测试脚本。产品升级之后，也需要更新测试脚本的。

　　其他（10%）：

　　其他影响因素，如果其他90%都做得很好，自动化项目还是失败了，都可以归于此。当项目组想告别刀耕火种的方式时，建议以实施自动化测试作为绩效考核之一。审核机制，建议同时关注自动化测试的产量和质量，不要只相信数字，不要相信国内的免检产品。

　　其他的其他……

====================================分割线================================

最新内容请见作者的GitHub页：http://qaseven.github.io/