从专业熟悉的软件开发转型为测试人员，或多或少有些许感想。从一个编程员，成功转型到软件测试员总有些许心得。“软件测试员的目标是找到软件缺陷，尽可能早一些，并确保其得以修复。”测试是一个需要细心和耐心的技术活。
当测试人员接手一个新的项目时，首先必须要摸清业务的背景，其次要深入的剖析需求，当没有需求时，往往测试将陷入一个泥潭。需求的不明确或缺失，测试将没有一个很好指标和标准，而出现问题时需要花很多时间去与其他项目成员确认和协商。而项目成员所说所想的，不一定是客户需要的。这样大大的延缓了项目进度和增加了项目成本。很遗憾的是，很多公司都没有重视需求这块。
当需求过了，就应该是测试计划和测试方案设计了，这一块往往在一些公司被忽视掉，不能不说这也是一大弊病，往往公司为了抢进度而忽视了很多真正影响进度的东西。下一个环节就是测试用例的编写和评审了，这一块没有什么说的，如果测试人员具备较好的书写表达能力和清晰的思维逻辑，都能做好。
再后就是执行测试用例，当然其中就涉及到许多测试工具、各种系统指令，以及一定的编程能力和DBS使用操作水平了。提到这里，我不能不说，测试的技术含量不比软件开发低（而这是很多人对测试人员的偏见，认为测试就是点点鼠标，敲敲键盘就搞定的事情），有可能所用到的知识还更多更广(毕竟微软更多的还是测试人员，而不是开发人员)。因为如果你要做好测试，首先你就不得不学会搭建各种系统平台及测试场景；你要清晰准确的定位问题，你不得不花许多时间用于编程的学习，不要多精通，起码不能随便被编程人员忽悠；最后你得主动的多接触新的工具，开头有点头痛，但不得不说这个环节做好了，将大大的提高你的测试效率和任务完成质量（这块有时做的不好，认为反正某个环节只有点东西可能涉及到，就忽视掉，导致以后该环节出问题时，因时间紧急，不得不疲于做重复性的工作）。
其次就是BUG的提交，追踪和管理。这块就需要靠测试人员与开发人员的大量沟通和协作了，毕竟没参与到程序的编写中，一些开发人员自定义的异常和处理信息，你将无从解析和对问题定位。当开发人员解决BUG时，应该及时验证和关闭。
最后就是对版本的整体回归性测试了，这块我不得不有一种深深的无奈。这块应该是项目开发(至少我工作所在是这样)的薄弱环节，往往上面都没有留充分的时间给予测试人员测试，而因为时间的紧张，测试人员也是草草了事，从而没能把好软件质量的最后一道关。最后在项目上线后暴露出这样或那样的问题，导致软件在客户心中的印象和评价大大打个折扣。
说到测试这块，我不得不说测试在项目里面的地位问题。往往测试人员得不到上级的重视和认同，从而造成测试人员对该职业没有成就感和认同感。因此这样的现象就是，往往测试人员做过一两年后将会转型到开发人员。我的理解是，测试应该是相对独立的部门，与开发同属于研发中心。测试人员不是开发人员的附庸，而二者间应该是相辅相成的关系。往往公司的忽视，也造成了开发人员对测试人员的刁难与轻视，不能不说这是我国软件质量提升不上去的原因之一。
最后是测试人员的薪资待遇问题了，好像除了少部分公司，开发人员与测试人员同等待遇外，普遍测试人员的薪资都比开发人员低。测试人员又少，任务又重，风险又大，从而导致高风险而相对较低的回报。即风险与利益不成比例，这也是造成测试从业者大量流失的原因。近年来随着IT行业所软件的质量重视，软件人员的状况有相对的改变，但现在还没看到比较明显的效果。只看到这方面的人才需求是多了，但地位并没挺高多少（从论坛和所属论坛前辈那获悉），一些公司往往都把测试看成是一种面子工程，并没真正发现和重视测试对软件整体质量和长远利益的作用。我热爱测试（虽然我曾一度想搞开发），希望最后测试能与软件开发得到同等或更高的待遇和重视，毕竟只有软件质量上去了，公司或企业才能获得更大的利益和回报。
以上是我从业软件测试师一年的感想，也许有些地方说的不是那么准确，但毕竟人只有在回顾和总结中才能得以升华和提高。希望对打算和即将从业软件测试的朋友有所帮助。