软件测试人员成长经历分享

  • 格式:docx
  • 大小:56.52 KB
  • 文档页数:5

下载文档原格式

  / 5
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

软件测试人员成长经历分享

初识软件测试

“这是一个杯子,主要用来喝水的,它的质量应该如何考量?”

这是在2010年进入上家公司面试时,测试主管问我的题目,相关的回答已经有点模糊,但从这个问题可以大概了解到,测试主管在考察我的测试思维。

首先,这个杯子的质量包含哪些方面?即通常所说的需求是什么?如显性需求,首先

应该是杯子,不是瓶子、罐子等,用途是喝水的;隐性需求呢?那就比较笼统了,如大小、高度、容积、制作材料、温度承受范围,还有一些其他细节如颜色、边角圆滑等。

其次,如何去准确获取、表现这些需求,即相关指标数据是多少。如要知道大小、高度、容积,得用到相关测量工具,如尺子、圆规。要知道温度承受范围,可能要用到温度

计等。

在完成测试工作期间,测试设计、执行之前必须清晰了解原始需求(包括隐性需求),再之后需要有对应的测试方案,需要执行哪些类型测试,要用到什么测试工具等。

很感谢当初测试主管对我测试工作的指导,不仅仅是在具体的技能培训上,还在其他

的工作当中对我测试思维的引导。

功能测试实践

面试过后进入公司,最开始接触的项目是广东省国税门户网站,所进行的测试工作是

主要是功能测试,如测试用例编写、执行,测试报告反馈。当时对所谓的软件生命周期都

很模糊,感觉我只要做好自己的测试任务就好了,其他的东西由上级安排就好。现在想想

真的好白,白痴的白。在接下来的一年时间,让我真正接触到了项目开发、交付的实际生

产过程,简而言之就是,工作任务是无止境的,永远有数不尽的需求要开发、测试,有茫

茫多的Bug要跟踪。如何在这中间保持自己清晰的定位显得至关重要。由于在项目组中只有我一个测试人员,那么结果就是,“测试的事情就都是我的”,好像很厉害的样子。但

我还只是小白啊。

“某某某,过来一下,这是这个版本修改的内容,大概是要在某月某日完成,你过(看)一下。”

“哦”。

到了测试执行,发现问题后提交给开发同事,开发回复:“设计如此。”

“哦”。

快要上线了,项目经理问:“某某某,现在系统的测试情况怎么样,能不能上线?”

“应该差不多吧”

。。。

测试主管了解之后,跟我强调了几点:

1、测试的依据,需求基线要清楚,要尽早参与;

2、测试要有计划方案,要有用例设计,不能随意的开展;

3、Bug的跟踪,要有自己的主见、原则;

4、测试结果的把握,要有结果分析。项目的上线,要综合你的以上测试过程,结合

目前的情况总结报告,甚至是项目经理也要听取你的意见。你的角色不仅是测试,也是质

量保证。

当然,以上的情况只是测试中遇到问题的一点点,如沙漠中的一粒沙(这孩子究竟怎

么过来的),但也让我认识到测试是独立的、重要的。

在后来的项目测试工作中,践行测试主管传递的思想原则的同时,我并行了解相关测

试书籍、工具、技能,结合工作进行相关实践,逐渐地我的测试能力越来越强。

在省国税外派了一年,之后测试过程中更加有条理、原则、规范。但也仅是个人自觉

的约束,很多过程并没有按照软件开发周期的标准来执行,如测试用例、测试报告有时候

会在发布版本后才编写(虽然公司也通过了CMMI3),即测试的质量保证更多的依赖个

人的素质。并且,当时个人认为测试的业务熟练更多决定于对系统功能本身的熟悉和测试

设计执行的熟悉,认识到错误并且有意识改变是在广东地税的定点联系企业管理系统和电

子办税服务厅的测试过程。

2012年年中,从宁波出差回广州后,进入到广东地税的定点联系企业管理系统项目

组进行测试。当时项目已快要进入验收阶段,甲方要求的功能基本都有实现,但在交付时

甲方却不满意,在一些功能的易用性和系统界面展示上提了很多要求,导致整个系统最后

框架、原型都换了一遍,而且限定修改的时间很短(又是一个加班加点的开始),最后甚

至项目负责人都换了。总结了下,有几个方面问题:

1、既定清晰的需求都有按要求实现,只不过实现方式不合甲方胃口,如图表不够丰富,只有概要,没有详细。

2、系统界面没有统一的样式,甲方不客气的说像草稿。

3、流程没有体现甲方日常工作内容、步骤。

4、风控系统很肤浅,指标不实用。

在这个测试过程中,我比较正式地参加甲方组织的各种需求讨论会议,期间也认识到

原始需求到需求基线其实还是有设计落实过程的,其把握的度就要看负责人或产品经理的

灵性了。作为测试人员,在需求评审过程中就要对比原始需求(要详细了解具体日常工作

内容,行业特殊性等)和需求基线的不同,给予自己的意见,在测试过程中不时提醒自己。而对需求的理解是否深刻,有时候不是参加正式需求评审就能达到的,还需要深入到用户

实际的工作场景,了解实际业务和流程。而对于自己无法准确把握(风控系统),用户又

无法准确提供的需求就要定好界限,实现到什么程度。最后,好用的软件不仅是功能的实现,一个界面样式都能让你从头再来。原计划短期内交付的项目,由于后续各种修改需求

一直到了次年3月,才基本结束相关测试活动。

完成定点联系企业管理系统的测试之后,我进入了电子办税服务厅项目组,在这里个

人的业务掌握程度得到认可。首先,对核心系统(电子办税服务厅接口调用提供方)的相

关业务(文书、申报等)熟悉,并与对应系统的中软项目组人员都可以打成一片(也是吸

取在陕西时沟通不顺的教训,详细后面性能测试提到)。其次,对电子办税厅的需求理解

充分,得益于当时的需求人员耐心引导(为了税务事业,头发都花白了的同事),最后是

自己对相关系统的后台数据表结构都比较熟悉。出现问题之后,能快速的理清思路,定位