请选择行业
请选择职位
请选择省份
请选择城市

我的软件测试之旅:(1)起点——作为软件开发人员

时间: 2012-09-24 15:30   作者: 徐毅   点击次数: 
 

  可能和大多数的IT人一样,我的职业生涯也是从一名软件工程师起步的。虽说头衔是软件工程师,但其实是跟随项目需要什么都干,也许和当时的公司是做外包业务有些关系。不过回头想想这也是好事情,什么都了解一点,什么都做一点,才不会秉持着“我就只做开发”、“我就是做测试”的这种想法。又幸好我后来很快有机会专职做测试,才没有沦为啥也不精专的泛泛之辈。

  我当时并不知道何为测试驱动开发(TDD)、可接受性测试驱动开发(ATDD)、持续集成或者敏捷测试这个概念,但我确实有做一些相似的事情。我们曾经做过一些SAP的开发,根据从日本客户那里拿到的详细设计书,开发一些ABAP程序。出于对自己的不自信,我完全不敢相信自己写出的代码,于是没写出一部分的代码,我都要实际地运行一把,看看运行的结果到底是怎样的。这里得称赞一把SAP的这个开发环境,真不错,帮助很容易查阅,也有一些示例程序,编译运行也很快,很容易就可以得到对自己编写程序的反馈。如果用今天的眼光来看待的话,其实也算是覆盖范围较小的持续集成了,只是我并非有意思的编写测试用例进行功能验证,只是执行程序看看外观和结果而已。由于每几段代码都能看得到实际的效果,再继续写后面的代码时我也有着更强的信心,一方面是对自己编写ABAP代码的信心,另一方面是对开发的方向以及ABAP语言的信心。

  由于是第一次接触ABAP语言,所以我并不敢确信自己使用该语言的方式是否正确,所以基本上在进行开发的同时,我还打开这一个测试项目(Project,IDE工具例如Eclipse中的项目,并非项目管理中的“项目”一词),类似于一个沙盒。沙盒的作用在于,当我需要使用一些函数或者接口,又不肯定它该如何使用时,我可以在沙盒里写一个最简短又能使用到这个函数或接口的小程序,看看它的效果,输入输出参数该如何使用,而后再回到应用程序开发的项目中去使用它。如果我直接在开发中去使用或者尝试,那么带来的风险就太大了。

  在其他一些项目中,我也做过许多类似于调整表格标示符位置,查看对话框位置之类的工作,后来我才了解到,在测试的社区里这些被称作是低等的手工测试工作。当时,我承担的任务被称作是“报表套打程序开发”,依然是被当做开发工作来进行的,虽然程序已经开发完毕,但是我们得细细盘查打印出来的实际效果是否正确,在电脑中看到以及排列整齐的表格,一旦打印出来却是错误百出。做这件事情,需要我们执行报表打印程序,打印到文件,然后观察打印出来的报表,看看表格或者一些字段是否显示在正确的位置。不仅如此,如果位置不对,那我们要立刻调整报表打印程序中的设置,再打印,再检查,再调整,重复此过程直到报表显示正确为止。

  当时公司里除了我所待的开发部,还有一个业务部门,就是本地化(Localization)团队,其实也就是招来一大堆英语、日语等各种语言的专业人士,让她们(绝大部分是女同胞,只有一个男同胞)将界面、菜单、对话框等所有用户看得见的文字都要转化为中文。我也曾经被抓壮丁去帮她们做这些工作,其实是非常的繁琐,也就是要在软件系统中将相应字段定义的地方,把文字替换过来,还要检查在界面上的显示是否正确,是否和原文界面保持一致风格,等等。关于本地化测试的技术和各种方法,我就不多说了,相关的书籍、文章都不少。只是后来回想,我觉得这样的过程其实完全可以做得比较自动化一点,可惜当时的我还没有接触到系统的测试自动化知识,也没有足够的能力可以帮助到她们。当时这个团队还面临着另一个问题,她们的成员多数是语言专业毕业, 计算机方面的知识可谓匮乏,遇到翻译一些专业词汇之时,就容易出错,所以她们也会在项目周期中安排一个阶段,供我们开发部的同事介入进行后期检查。有点像是在做系统测试,但麻烦在于,开发部介入比较晚,而要检查的文字实在太多,仿佛大海捞针,通常也只有凭借经验挑选一些容易出错的地方做重点检查,现在想想,其实颇有一点基于风险测试(Risk-Based Testing)的意味。

打印本页 | 加入收藏

上一篇:写给一名软件测试工程师     下一篇:软件测试的前途与职业发展

关闭  
主要城市: 北京 上海 杭州 广州 南京 武汉 长沙
全部城市: