有关工作中弯路或无用功的一些思考

       工作中，有时候往往忙碌了半天或者更久，最后产出的结果却不是最终想要的，甚至南辕北辙，这可称之为弯路或者无用功。我想每个人多多少少在工作中都碰到过，时间白白浪费，进度也可能被延误。

       最近，我就碰到了类似的事情。这个错误在某些人眼中可能是非常低级的,错误是低级的,后果很严重。在这里我记录下来,希望能有些帮助或启发。简单介绍下其中的项目信息：测试某个（web）项目一个后台API的处理能力，此API主要提供搜索和查询功能。要使用这2个功能，需求文档里面提供了以下步骤：1.打开首页面，2.点击客户服链接，3.（重点来了）需要输入客户的ID，才能进入（API所在的）服务页面， 4。搜索或者查看 （比例各占50%）。本次测试中，只有搜索服务和查看服务直接调用了后台API，前面的步骤页面实际上都可以从脚本里面剔除的,只需要保留搜索和查看的脚本，在测试过程中就可以对后台API产生实际的压力。但是实际工作中我自己想当然的做脚本，把前面步骤地页面也包括进了最终脚本。在测试的时候而随着压力的增加前面几个步骤页面消耗了后台服务器（测试环境）的大量资源，影响了对测试目标：后台API的测试，最终导致结果无效,浪费时间一天。

       我在做脚本的时候根本没有想到: 删掉前面的步骤，脚本也可以正常工作或者说可以直接的成功访问后台API。其中的定势或惯性思维是导致本次无效结果的原因之一；或者可以归结为经验或知识的局限（有些系统的某些操作确实需要登录后才能成功操作）？

       而没有及时的去沟通也是原因之一。假如我做好脚本之后，如果及时跟相关同事沟通下脚本相关的问题（如：是否参数化，是否所有步骤都需要等等。最终修改过的脚本很简单：前面的步骤从脚本里移除，另外每次都打开查看固定的一条记录，搜索也是固定的搜索），也可以降低些做无用功的时间成本。

基于上述弯路,我有了下面的一些思考和改进方法:    

1.理解需求

2.理解测试目标

       及时有效的沟通, 结对做脚本(测试),每个阶段增加必要的评审,把隐患扼杀在前期。并持续不断的改善流程。