我写这个标题可能被大方之家耻笑了--你才做测试多久，就考虑什么之路了？或许将来看，我现在的想法很幼稚，但是现阶段我还是不断的思考，不断的让自己在将来接近成熟的目标。
刚到一个新环境，之前两个月的测试工作也算告一段落。因为到这边换了业务，尽管还是在一个大系统里，但是和原来的测试内容之间的交集已经很少。需要重新去学习对应的业务只是，重新开始。
没法，虽然已经有工作经验，但是对于目前公司的业务这块，自己还是一张白纸，好画最新最好的画。此篇也是仅仅总结前两个月的一些感想，因为涉及到信息安全，我不会写业务有关的知识，只是想想这两个月的测试生活，让自己沉淀，走更宽更长的路------转载请注明出自测试窝。
这两个月从事的是中间件的测试，需要从底层获取接口，同时向上提供API的测试，具体框架也只能说这么多，全程全部自动化，测试人员负责编写测试脚本，撰写代码（不懂编码不行），自己搭建服务器集群，测试产品的功能--分布式部署、负载均衡、性能问题（既有指标，也要探索）等测试人员需要关注的，因为是全程跟产品，因此也不存在只做功能或者性能，都要懂怎么搞。
测试用例是测试人员的最基本功，入这个行业的基本功底就是编写测试用例，不管是前端页面还是后台接口测试，常用的工程方法都需要的。设计出来的测试用例能够体现一个测试人员的基本能力。但是不是每个熟悉测试方法的人都能够设计好用例，换句话说，仅仅理解了工程方法是远远不够的。
不知道这句结论是否下的有点武断，但是目前我遇到的困境正是这样，因为之前做的是和数据有关方便的测试，对通信方面的业务知识基本上只是了解到大学毕业的水平。知道有那么回事，况且我们从事着一个日新月异的行业，那点知识早就可以进历史博物馆了。业务，是你能否取得长足进步的不容忽视的部分，甚至过分的说，这个比测试方法更让你的价值提高。
这轮测试的时候，我设计的用例在工程方法上面来说基本上是覆盖面最广最全的，也很少被挑毛病，可是这个东西是我的绩效么？你或许会说做的这么好是啊，甚至是好的绩效。不错，这个好只能证明你的测试功底确实不错，你的基础没有问题，可是这个用例真的不是这个产品特别需要的用例。我设计了这些是因为我之前几周了解了这些东西的业务背景，现在刚报道新的产品，我设计用例就举步维艰。
接上面的讨论。一个产品，设计出来是给客户使用的，用户对你支持1000个还是2000个字符、特殊字符、null传递什么的不是特别感冒，他们关注的是你这个东西能够适应我这个使用场景么？这个才是重点，你设计了那么多用例，给你自己，整个产品以及最终用户有多少帮助呢？现在简单的说下我的用例的结果，业务部分，我的用例是远远不足的，也就是说，这个用例还停留在初级阶段，根本没有结合使用场景。可是要现在的我去思考用户的真实使用场景，我承认，我现在还很“嫩”。
接下来我就想这个测试行业了。我和主管的差距、和老员工的差距，技术方面做个几年大家都差不多了，毕竟这个行业的技术也就这么多。那他们比我强的最核心的部分也就是业务。而且这个东西，在这个行业中越久，了解的东西就越多。如果那种不停的跳槽的人，这个积累是不断的被夭折的。也就是他们常说的经常跳槽的人最后就跳不动的原因。
我们选择了职业做测试，但是我们更应该提前选好行业，通信也好，互联网也罢，这个东西和职业一样重要，因为在中国，技术还真的做的很辛苦，而且不懂业务的技术，真的不是什么好现象。我们还是早点清晰点认识为好。祝大家都有个好前程。
