从业软件测试员一年心得体会和感想

从专业熟悉的软件开发转型为测试人员,或多或少有些许感想。从一个编程员,成功转型到软件测试员总有些许心得。“软件测试员的目标是找到软件缺陷,尽可能早一些,并确保其得以修复。”测试是一个需要细心和耐心的技术活。

当测试人员接手一个新的项目时,首先必须要摸清业务的背景,其次要深入的剖析需求,当没有需求时,往往测试将陷入一个泥潭。需求的不明确或缺失,测试将没有一个很好指标和标准,而出现问题时需要花很多时间去与其他项目成员确认和协商。而项目成员所说所想的,不一定是客户需要的。这样大大的延缓了项目进度和增加了项目成本。很遗憾的是,很多公司都没有重视需求这块。

当需求过了,就应该是测试计划和测试方案设计了,这一块往往在一些公司被忽视掉,不能不说这也是一大弊病,往往公司为了抢进度而忽视了很多真正影响进度的东西。下一个环节就是测试用例的编写和评审了,这一块没有什么说的,如果测试人员具备较好的书写表达能力和清晰的思维逻辑,都能做好。

再后就是执行测试用例,当然其中就涉及到许多测试工具、各种系统指令,以及一定的编程能力和DBS使用操作水平了。提到这里,我不能不说,测试的技术含量不比软件开发低(而这是很多人对测试人员的偏见,认为测试就是点点鼠标,敲敲键盘就搞定的事情),有可能所用到的知识还更多更广(毕竟微软更多的还是测试人员,而不是开发人员)。因为如果你要做好测试,首先你就不得不学会搭建各种系统平台及测试场景;你要清晰准确的定位问题,你不得不花许多时间用于编程的学习,不要多精通,起码不能随便被编程人员忽悠;最后你得主动的多接触新的工具,开头有点头痛,但不得不说这个环节做好了,将大大的提高你的测试效率和任务完成质量(这块有时做的不好,认为反正某个环节只有点东西可能涉及到,就忽视掉,导致以后该环节出问题时,因时间紧急,不得不疲于做重复性的工作)。

其次就是BUG的提交,追踪和管理。这块就需要靠测试人员与开发人员的大量沟通和协作了,毕竟没参与到程序的编写中,一些开发人员自定义的异常和处理信息,你将无从解析和对问题定位。当开发人员解决BUG时,应该及时验证和关闭。

最后就是对版本的整体回归性测试了,这块我不得不有一种深深的无奈。这块应该是项目开发(至少我工作所在是这样)的薄弱环节,往往上面都没有留充分的时间给予测试人员测试,而因为时间的紧张,测试人员也是草草了事,从而没能把好软件质量的最后一道关。最后在项目上线后暴露出这样或那样的问题,导致软件在客户心中的印象和评价大大打个折扣。

说到测试这块,我不得不说测试在项目里面的地位问题。往往测试人员得不到上级的重视和认同,从而造成测试人员对该职业没有成就感和认同感。因此这样的现象就是,往往测试人员做过一两年后将会转型到开发人员。我的理解是,测试应该是相对独立的部门,与开发同属于研发中心。测试人员不是开发人员的附庸,而二者间应该是相辅相成的关系。往往公司的忽视,也造成了开发人员对测试人员的刁难与轻视,不能不说这是我国软件质量提升不上去的原因之一。

最后是测试人员的薪资待遇问题了,好像除了少部分公司,开发人员与测试人员同等待遇外,普遍测试人员的薪资都比开发人员低。测试人员又少,任务又重,风险又大,从而导致高风险而相对较低的回报。即风险与利益不成比例,这也是造成测试从业者大量流失的原因。近年来随着IT行业所软件的质量重视,软件人员的状况有相对的改变,但现在还没看到比较明显的效果。只看到这方面的人才需求是多了,但地位并没挺高多少(从论坛和所属论坛前辈那获悉),一些公司往往都把测试看成是一种面子工程,并没真正发现和重视测试对软件整体质量和长远利益的作用。我热爱测试(虽然我曾一度想搞开发),希望最后测试能与软件开发得到同等或更高的待遇和重视,毕竟只有软件质量上去了,公司或企业才能获得更大的利益和回报。

以上是我从业软件测试师一年的感想,也许有些地方说的不是那么准确,但毕竟人只有在回顾和总结中才能得以升华和提高。希望对打算和即将从业软件测试的朋友有所帮助。   



留言