我写这个标题可能被大方之家耻笑了--你才做测试多久，考虑什么之路了?或许将来看，我现在的想法很幼稚，但是现阶段我还是不断的思考，不断的让自己在将来接近成熟的目标.

　　刚到一个新环境，之前两个月的测试工作也算告一段落.因为到这边换了业务，尽管还是在一个大系统里，但是和原来的测试内容之间的交集已经很少.需要重新去学习对应的业务只是，重新开始.

　　没法，虽然已经有工作经验，但是对于目前公司的业务这块，自己还是一张白纸，好画新好的画.此篇也是仅仅总结前两个月的一些感想，因为涉及到信息安全，我不会写业务有关的知识，只是想想这两个月的测试生活，让自己沉淀，走更宽更长的路------转载请注明出自测试窝.

　　这两个月从事的是中间件的测试，需要从底层获取接口，同时向上提供API的测试，具体框架也只能说这么多，全程全部自动化，测试人员负责编写测试脚本，撰写代码(不懂编码不行)，自己搭建服务器集群，测试产品的功能--分布式部署、负载均衡、性能问题(既有指标，也要探索)等测试人员需要关注的，因为是全程跟产品，因此也不存在只做功能或者性能，都要懂怎么搞.

　　测试用例是测试人员的基本功，入这个行业的基本功底是编写测试用例，不管是前端页面还是后台接口测试，常用的工程方法都需要的.设计出来的测试用例能够体现一个测试人员的基本能力.但是不是每个熟悉测试方法的人都能够设计好用例，换句话说，仅仅理解了工程方法是远远不够的.

　　不知道这句结论是否下的有点武断，但是目前我遇到的困境正是这样，因为之前做的是和数据有关方便的测试，对通信方面的业务知识基本上只是了解到大学毕业的水平.知道有那么回事，况且我们从事着一个日新月异的行业，那点知识早可以进历史博物馆了.业务，是你能否取得长足进步的不容忽视的部分，甚至过分的说，这个比测试方法更让你的价值提高.

　　这轮测试的时候，我设计的用例在工程方法上面来说基本上是覆盖面广全的，也很少被挑毛病，可是这个东西是我的绩效么?你或许会说做的这么好是啊，甚至是好的绩效.不错，这个好只能证明你的测试功底确实不错，你的基础没有问题，可是这个用例真的不是这个产品特别需要的用例.我设计了这些是因为我之前几周了解了这些东西的业务背景，现在刚报道新的产品，我设计用例举步维艰.

　　接上面的讨论.一个产品，设计出来是给客户使用的，用户对你支持1000个还是2000个字符、特殊字符、null传递什么的不是特别感冒，他们关注的是你这个东西能够适应我这个使用场景么?这个才是重点，你设计了那么多用例，给你自己，整个产品以及终用户有多少帮助呢?现在简单的说下我的用例的结果，业务部分，我的用例是远远不足的，也是说，这个用例还停留在初级阶段，根本没有结合使用场景.可是要现在的我去思考用户的真实使用场景，我承认，我现在还很"嫩".

　　接下来我想这个测试行业了.我和主管的差距、和老员工的差距，技术方面做个几年大家都差不多了，毕竟这个行业的技术也这么多.那他们比我强的核心的部分也是业务.而且这个东西，在这个行业中越久，了解的东西越多.如果那种不停的跳槽的人，这个积累是不断的被夭折的.也是他们常说的经常跳槽的人后跳不动的原因.

　　我们选择了职业做测试，但是我们更应该提前选好行业，通信也好，互联网也罢，这个东西和职业一样重要，因为在中国，技术还真的做的很辛苦，而且不懂业务的技术，真的不是什么好现象.我们还是早点清晰点认识为好.祝大家都有个好前程.