工作中，有时候往往忙碌了半天或者更久，最后产出的结果却不是最终想要的，甚至南辕北辙，这可称之为弯路或者无用功。我想每个人多多少少在工作中都碰到过，时间白白浪费，进度也可能被延误。
最近，我就碰到了类似的事情。这个错误在某些人眼中可能是非常低级的,错误是低级的,后果很严重。在这里我记录下来,希望能有些帮助或启发。简单介绍下其中的项目信息：测试某个（web）项目一个后台API的处理能力，此API主要提供搜索和查询功能。要使用这2个功能，需求文档里面提供了以下步骤：1.打开首页面，2.点击客户服链接，3.（重点来了）需要输入客户的ID，才能进入（API所在的）服务页面， 4。搜索或者查看 （比例各占50%）。本次测试中，只有搜索服务和查看服务直接调用了后台API，前面的步骤页面实际上都可以从脚本里面剔除的,只需要保留搜索和查看的脚本，在测试过程中就可以对后台API产生实际的压力。但是实际工作中我自己想当然的做脚本，把前面步骤地页面也包括进了最终脚本。在测试的时候而随着压力的增加前面几个步骤页面消耗了后台服务器（测试环境）的大量资源，影响了对测试目标：后台API的测试，最终导致结果无效,浪费时间一天。
我在做脚本的时候根本没有想到: 删掉前面的步骤，脚本也可以正常工作或者说可以直接的成功访问后台API。其中的定势或惯性思维是导致本次无效结果的原因之一；或者可以归结为经验或知识的局限（有些系统的某些操作确实需要登录后才能成功操作）？
而没有及时的去沟通也是原因之一。假如我做好脚本之后，如果及时跟相关同事沟通下脚本相关的问题（如：是否参数化，是否所有步骤都需要等等。最终修改过的脚本很简单：前面的步骤从脚本里移除，另外每次都打开查看固定的一条记录，搜索也是固定的搜索），也可以降低些做无用功的时间成本。
基于上述弯路,我有了下面的一些思考和改进方法:
很好的理解即将入手的工作
1.理解需求
需求是测试的基石, 是测试工作的第一步。为了很好的理解需求,测试团体需尽早介入开发: 在项目起始就参与进去; 分析功能性需求和非功能性的需求; 以及客户预期需要做哪些的测试等等(需求有很多工作要做,这里仅简单分析下)。
2.理解测试目标
只有很好的完全理解了测试目标,制定出来的测试策略才是最合适有效的。结合上面的例子, 分析测试目标的时候,可以有条件的借鉴之前类似地经验而不是完全照搬(可能会碰到完全一样的项目)。
完善有效的流程
及时有效的沟通, 结对做脚本(测试),每个阶段增加必要的评审,把隐患扼杀在前期。并持续不断的改善流程。
风险分析
在实际的测试工作中，有不少风险（因素）能制约你达成你的测试目标。比如做配置测试，其中一个粗心的不正确的配置，可能就会导致你的测试结果无效。排除法一一的排除风险,是个不错的选择。当然风险识别，规避以及风险知识的累积是基础。
第一次就把正确的事情做对
第一次就把正确的事情做对是<质量免费>里面著名的观点。这是一个很大的概念。怎么第一次把事情做对？从经历中学习，包括失败的和成功的。 也包括从别人的经历去学习：其中读经典的技术书籍是最快捷的（如若能找到经验丰富的并愿意做自己老（导）师的测试专家也比较快捷）。经典的书籍要精（研）读，并加入自己的思考，最重要的是要结合实际的项目进行实践，实践再实践。然后尽可能多的 去总结宝贵的失败和成功经验，最后在前人的基础上升华并努力做进一步探索和创新。最终能转化成自己的知识成积累。这本书已经读过,现在看来仅仅是读过,了解了些概念。不过现在还不晚,继续在项目中实践去.
开阔眼界
上面提到了局限的知识或经验大多时候也是导致工作中走弯路的重要原因。 我们需要开阔眼界，思维，积累知识。我认为还有有以下途径可以参考: 参与论坛，通讯群或者加入邮件组进行技术讨论以及帮助别人解决自己力所能及的问题，而不仅仅是旁观者。另外网络上有很多乐于分享，助人的高手和专家。还有多参加一些线下技术交流会。自我检讨下，这方面需要继续努力。
小结：当然上面的一些建议首要是建立在自己有一颗积极上进的心的基础上，外加强烈的兴趣和热情并坚持不懈！最后希望大家都能在工作中不走弯路或做无用功，成长为测试方面的人才甚至专家。
以上是我的一些心路历程以及浅见，欢迎拍砖，谢谢！
版权声明：本文出自 stevenremember 的51Testing软件测试博客：http://www.51testing.com/?100922
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
