功能测试自动化的投入和产出

测试自动化，对于系统性能测试、负载测试等效果是明显的，而且我们也不得不为之。
我们知道，没有测试工具进行负载模拟，要通过手工测试完成系统测试任务，几乎是不可能的。但在功能测试中，情况就大不一样了。

手工测试在功能测试中的优势还是比较大的，工具本身并没有想象力和灵活性，而人对界面美观性、逻辑合理性，容易作出判断。

所以功能测试自动化主要的应用 在回归测试中，而且产品的界面（UI）和功能变化较大，自动化的脚本（Script）维护成本较大，投入和产出往往变成我们最关心的问题，在功能测试中实 现测试自动化究竟是否合算？

举个例子：假如一个功能测试用例，手工运行需要10分钟，而为此测试用例开发脚本需要4个小时，即240分钟，那么意味着这个测试脚本要被运行24次收回成本，如果在加上测试脚本的维护工作量（10％），需要重复运行40－50次，才收回成本。如果在产品的一个版本中要进行2－3轮测试（一般是需要的），这个产品需要发布15－20个版本才收回成本。所以业界常说，产品发布7个版本才收回成本。

如何降低成本、可以相对增加产出或者说更快地收回成本？关键是提高脚本开发速度、提高脚本运行的稳定性和降低维护脚本的工作量，主要方法有：

－ 选择较好的、更适合的测试工具

－ 选择适宜自动化的模块

－ 尽量将脚本写成数据驱动的脚本，这一点很重要。

－ 多录制脚本，然后结构化脚本。我们知道，不是所有的模块都可以变为数据驱动方式，这时就要抽象出脚本的结构，进行有效的组合，包括分层，形成有效的层次性。

－ 测试和脚本开发合二为一，效率更明显

下表也部分说明了这个问题。也希望得到您更好的想法。

Framework / data-driven (hybrid) structure focusingon views of the application and using data pools

本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/

基于流程管理，提高工作质量和效率 在软件开发领域中，流程协作一直是热门的话题之一，不同的组织架构中，定义不同角色和人员的职责范围，并且通过流程规范来管理不同角色之间的衔接机制，以求不断提高协作效率。
大型项目中的质量策略实践：外卖架构升级项目质量的“取”与“舍” 阿里QA导读： 大中台小前台 的组织和业务体制已经是互联网老生常谈的问题了，外卖场景作为最火热的线上线下场景，日均单量动辄千万量级，想要把交易流量融入到集团统一的中台架构体系中，难度无异于在给高速行驶的汽车换轮胎，对项目组尤其是质量守护同学提出了巨大的挑战，该如何应战？本地生活的雨清同学给大家带来架构升级质量保障的手段和思考，希望对大家有参考价值。
研发过程中的测试工作 年轻的测试工程师又一次累倒在提测阶段，他拖着疲惫的身躯来向师父诉苦，“师父，开发的时候闲的要死，一到提测累的半死”。师父含笑不语，拿出一颗冬枣，一瓶老干妈。年轻人想了半天之后，一拍脑袋说：“师父，我明白了，你一定是说吃枣补气，吃辣活血，更有精神工作。”“不是”师父怒骂到，“早干嘛去了！” —— 其实测试工作是贯穿整个研发过程的，在测试的位置上左移一下，右移一下，才能更好的保障质量。