2017-12-23 15:15:42 shouchun_w163 阅读数 403


软件测试思想者 - 软件评测师考试顺利通关


昨晚获悉2017年11月份参加的“软件评测师”考试成绩(上午50分,下午53分),远超历年来的过关分数线45分,正常情况会获得软件评测师中级资格证书。这是继2010年上半年一次性通过“信息系统项目管理师”考试并获得高级资格后, 获得的与本职工作最相关的一个专业证书,也是本人软件测试思想者的一个有力说明。

2018-11-27 16:33:21 qq_42606738 阅读数 952

益相关,这次以一个局外人的身份聊聊软件测试自学,该采取什么样的思路和方法。

很多自学者在冒出这个问题的时候,本职上就是一个感觉:我该从哪里入手?

咱们今天从3个方面着手,来说说如何自学软件测试,文章不长,会说的很透彻,文章底部我会有自学的资料,你们自己拿走就行了。

一、思路篇

二、心态篇

三、技能篇

四。资料篇

好的,咱们先从第一个,学习的思路着手,这就好比写文章先列好提纲一样,第一个方面就是解决思路的问题,确保咱们方向的正确性。

一、思路

在决定自学之前,一定要问自己几个问题,把这几个问题思考明白了,自学的道路会顺利很多,因为见过了太多的“从自学到放弃”

1、自己是否真的想好了进入这个行业?是否真的经过了深思熟虑,还是仅仅因为羡慕这个行业的薪资水平,一时冲动?

这个问题想明白了,就不至于后期 遇到困难的时候出现想放弃的情况,自己选择的路,跪着也要走完!

2、自学的时间是否有严格的计划安排?是否能够固定抽出时间来去学习,这个时间段不受其他事情干扰?

如果这个问题解决不了,那么就是三天打鱼两天晒网,学着前面的,忘着后面的,终究是不成体系。

3、学习的过程中,需要结合实际项目去实操,这个项目去哪里获取?身边是否有稳定的渠道能够接触到项目?

如果这个问题解决不了,那么学的和用的就会脱节,实际进入企业的时候会全盘蒙圈。

4、学习过程中遇到的技术问题,如何自己去解决?百度?请教身边的朋友?去交流群里问?

这个问题我放在最后,尤其的重要,因为技术的东西都是死的,重要的就是自己实际操作,在实操中遇到问题,解决问题,从而提高自己的技术水平。百度问题不全面,没有针对性;身边的朋友看自己的情况,包括去交流群里请教,都是可以的,但是谁都没有义务一直去帮你。

以上4个问题想明白了,那么从哪里着手就是一个小问题了,只不过我是把在自学中会遇到的棘手问题在你自学开始之前就让你去思考,这样不至于中间遇到问题的时候蒙圈。OK,咱们再说说心态。

二、心态

关于自学

1.软件测试入门容易,但是这不是你认为它好学的理由,你怎样轻视它,它就怎样轻视你;

2.门槛低意味着容易入门,但同时也意味着要爬升的道路比较长;

3.看书解决不了问题,只是参考,书籍更新速度慢,信息传达单一,但是经典的终归还是经典;

4.不轻易推荐自学,这个还是要看人,自学非常容易钻进牛角尖,见过太多的“从自学到放弃”。

关于工作态度:

1.认为软件测试就是写写测试用例,执行一下,汇总一下bug的,趁早清醒,否则只能一辈子点点点。你不主宰你自己,那就让别人主宰你;

2.所有身边一开始认为测试容易,钱好混的,再过几年看他,还是老样子;

3.学无止境,你工作别人也在工作,你发呆别人在学习,然后你就被艹爆了;

4.工作中不要只有想象力,没有执行力,咱们还没有成长到公司离不开自己的地步;

5.主观能动性,主动去接触技术性的内容,成年人不要指望别人把东西嚼碎了喂你;

6.2018年靠点点点去混工资已经越来越难了,持续学习+主动探索+分析总结,缺一不可。

三、技能

按照这个路线图去学习,自学就会变得非常轻松,不会有无从下手的感觉了

初级阶段

初级阶段需要掌握四个方面的内容

一、软件测试的基础知识,编写测试用例的方法及测试流程

二、掌握禅道、SVN等必要工具,及缺陷定义和测试计划编写方法

三、web测试与app测试的方式方法与协议

四、接口测试postman工具的操作使用,前端基础知识H5及CSS

中级阶段

中级阶段需要掌握六个方面的内容,从中级开始就是涉及到一些工具的使用

一、QTP自动化工具的环境搭建

二、loadrunner性能工具的环境搭建

三、jmeter性能工具的环境搭建及接口压力测试

四、jmeter脚本增强,app/web性能测试

五、fiddler抓包工具的操作使用、Jenkins自动化部署工具

六、数据库MySQL、SQL语句

高级阶段

高级阶段涉及到四个方面,需要掌握一点开发的知识

一、虚拟机的搭建与使用,Linux环境搭建及命令

二、eclipse框架介绍,学习测试必须掌握的Java基础知识

三、testNG+selenium自动化工具环境搭建

四、APP自动化之monkey
在这里插入图片描述
需要原图可以私我。

按照这个方向去学习,基本上出来技能水平就达到了中级的水平,完全就可以去面试找工作了。但是这个时候与真正的中级水平还差点火候,那就是没有实际的工作经验,那这个时候就需要去研究企业的大项目,去获取一些经验。另外打算面试之前,还需要对掌握一些面试技巧及面试题,最重要的是要包装一下自己的简历。因为能力已经足够,那就需要所有的硬件也都匹配上。

四、资料

在这里会给你们提供一些学习书籍的信息,方便参考。

在这里插入图片描述
(一)书籍

主要是抽时间整理的豆瓣上的软件测试的书目,里面对应的书评对你或许有帮助,仅供参考。

1.《Google软件测试之道 》 2.《持续交付》 3.《软件测试的艺术 》 4.《 代码整洁之道:程序员的职业素养》5.《软件测试 》6.《测试驱动开发 》7.《软件测试经验与教训》8.《探索式软件测试》9.《捉虫日记》10.《发布!软件的设计与部署》11.《移动App测试实战》12.《微软的软件测试之道》13.《颠覆完美软件:软件测试必须知道的几件事》14.《有效的单元测试 》15.《敏捷软件测试测试人员与敏捷团队的实践指南》16.《腾讯Android自动化测试实战》17.《完美软件对软件测试的各种幻想》18.《 Python Web开发:测试驱动方法》19.《测试驱动开发的艺术》20.《软件测试工程师面试指导》21.《自动化测试最佳实践来自全球的经典自动化测试案例解析》22.《Cucumber:行为驱动开发指南》23.《Web安全测试 》24.《大话移动APP测试:Android与 iOS应用测试指南》25.《iOS测试指南》26.《全程软件测试(第2版)》27.《 JUnit实战》28.《 xUnit测试模式 》29.《测试驱动的面向对象软件开发》30.《Java测试新技术TestNG和高级概念》31.《测试之美》32.《测试架构师修炼之道》33.《.NET软件测试自动化之道》34.《 软件测试之魂》35.《模糊测试强制性安全漏洞发掘》36.《 单元测试的艺术(第2版)》37.《 软件测试技术经典教程》38.《有效软件测试》39.《计算机软件测试》40.《 软件测试基础教程》41.《 Junit in Action 中文版》42.《游戏测试精通 》43.《 精通软件性能测试与LoadRunner实战》44.《完美测试 》45.《用例分析技术》46.《软件测试自动化》47.《软件测试面试突击》48.《应用程序性能测试的艺术》49.《 软件测试与持续质量改进》50.《Perl Testing程序高手秘笈 》

综合来说,国外的经典居多,国内的相当一部分是拼凑而来,但是也是有一部分经典的,这个要看作者。建议8.0分以上的都可以读来看看,另外相关书籍没有必要去花那么高的价格去买新书,要么是直接买二手的,要么是直接找电子版的进行看,这其中很多书在大学的图书馆也很容易找到,要是找不到的话,我这里有一部分的电子版,可以给到你们。
在这里插入图片描述
(二)学习平台

1.51CTO

2.CSDN

3.博客园

4.简书
在这里插入图片描述
上面这个资料你们可以自己下载

我先放你们入门用的,进阶性能自动化的,私我就行了。

软件测试资料礼包,密码:sad7

软件测试入门提升电子书,密码:exna

软件测试小白入门学习资料,密码:aqvh

2018-10-14 00:08:35 sishuihuahua 阅读数 1153

2018年10月13日23:24:26

自诩:

        因为上一东家工作的原因而接触测试。原本本职是嵌入式软件,因为公司正在风口浪尖的阶段,就是一种小公司要发展成为大公司而经历的那种痛,全公司上下都忙得焦头烂额的这样的背景下,我从软件变成了“测试”小组组长。当时的心情既兴奋又担心。兴奋是因为自己一年的努力与突出表现,老板看在眼里,从而相信我有这个能力去接这个职位。现在想起来,也确实是,老板不会看错人,不会随便将一个人放在一个新建部门小组组长的职位上。但是我却时隔了4个月,离职了4个月后才深深的体会到,是真的是个非常好的机会,回想起来还是非常感谢公司的培养。现在的工作不会像之前那样,几乎是华为苹果公司的强度,至少对我来说,我是18小时在线状态,随时相应苹果客户的测试问题。这也是一个让我不自信的原因,害怕自己做不好让公司利益受损。但是现在想想还真是庆幸,我熬过了半年,压力迫使我现在处事更加从容,再复杂的问题都有始有终,总能找到一个合理的解决方法。也正是因为太忙,让一个刚刚毕业的我遇上了,我想挤点时间让自己充电,让自己沉淀,让自己多一些开发经验,这样我才有底气去领导一个小组,这是我离职的最主要原因。所以我现在才有些时间在这里巴拉巴拉这些话。

        再回到正题,虽然已经离职,但也想为自己的工作,新接触的领域做一个总结,所以才接触到这本书《软件测试的艺术》。我很庆幸我在这本书中,找到我工作时的所使用方法,也让我一下子对这本书产生了好感,也对我上一家公司我的直属领导更加钦佩。本书讲解的方法都很规范,真正完全按照执行,那将是华为、阿里那样的大公司所能驾驭的。当然,很多公司不需要完完全全按照上面的经验去做,我们只需要找到哪怕一点用在我们现在所属的公司里,我觉得就足以提高开发的质量。下面就我将来可能会用到的一些方法进行总结,当然书上还有更加高级的测试理论,因为个人理解有限,不敢曲解书面意思。

        中国的测试工程师是应届毕业生就可以去“胜任”的;而外国的测试是必须是一个资深研发人员才能胜任测试职位。

“测试是为发现错误而执行程序的过程”。

一、软件测试的原则

1. 测试用例中一个必需部分是对预期输出或结果的定义。

        一个测试用例必须包括两个部分:

              a. 对程序的输入数据的描述。

              b. 对程序在上述输入数据下的正确输出结果的精确描述。

2. 程序员应当避免测试自己编写的程序.

        我们大多数程序员都不能有效地测试自己编写的程序,因为我们无法改变思维方式来尽力暴露自己程序中的错误。另外,我们开发者可能会下意识地避免找出错误来,担心受到同事、上司、客户或正在开发的程序或系统的主管的惩罚。这仅次于心理学问题所以说,更重要的是,担心程序开发者理解错了需求,导致程序出现错误。所以说,让其他人来测试程序会更加有效,也会更容易测试成功。当然,解决问题还是得程序开发的作者,那又回到了程序调试、解决bug的层面上。

3. 编写软件的组织不应当测试自己编写的软件

这个和上面一点很相似,但是我想说的是,效果最明显的还是交由第三方专门的测试部门进行测试,而该测试部门应该是客户层面的眼光去测试。

4. 应当彻底检查每个测试的执行结果。

解决任何的测试失败项,避免下次测试时显示的上一次的测试失败项,会误导开发者是新该出的bug。

5. 测试用例的编写不仅应当根据有效和预期的输入情况,而且也应当根据无效和未预料到的输入情况。

6. 检查程序是否“未做其应该做的”仅是测试的一半,测试的另一半是检查程序是否“做了其不应该做的”。

这就涉及到了压力测试及循环测试了,避免因为某个功能的实现导致上一个功能失效。或者是有规律的先运行了某个功能,上一个功能就失效了的问题。

7. 应避免测试用例用后即弃,除非软件本身就是一个一次性的软件。

测试用例应该是被分类好,并且是一个增量的开发。这样的好处是,将来一个新的版本relese后,就可以将之前的测试用例都过一遍,有些因为重大功能改变而导致的失败,那是具体事情具体分析了。这个就是我们常说的“回归测试”。

8. 计划测试工作时不应默许假定不会发现错误。

在实际测试中,不仅仅是测试正常情况下所预期的正常结果,也应该给一些异常的测试项,测试异常的情况下,应触发的异常流程。当测试异常项后,程序表面任然可以运行的情况,也需要去排除,殊不知程序触发了某个异常的bug,在不确定的时间才复现出来。

9. 软件测试是一项极富创造性、极具智力挑战性的工作。

测试一个大型软件所需要的创造性很可能超过了开发该软件所需要的创造

性。我们已经看到,要充分地测试一个软件以确保所有错误都不存在是不可能的。所以上面我说,中国与外国对测试不同的定义,我更倾向与外国的做法。

二、 代码检查、走查与评审

代码检查和代码走查是两种重要的人工测试方法。

代码检查与走查都要求人们组成一个小组来阅读或直观检查特定的程序。无论采用哪种方法,参加者都需要完成一些准备工作。准备工作的高潮是在参加者会议上进行的所谓“头脑风暴会”。“头脑风暴会”的目标是找出错误来,但不必找出改正错误的方法。换句话说,是测试,而不是调试。

1. 代码检查(Code Inspections)

所谓代码检查是以组为单位阅读代码,它是一系列规程和错误检查技术的集合。

一个代码检查小组通常由四人组成,其中一人发挥着协调作用。协调人应该是个称职的程序员,但不是该程序的编码人员,不需要对程序的细节了解得很清楚。

协调人的职责包括以下几点:

  • 为代码检查分发材料、安排进程。
  • 在代码检查中起主导作用。
  • 记录发现的所有错误。
  • 确保所有错误随后得到改正。

明白各自职责后,就可以对代码流程进行检查,任何有疑问的都应该被记录下来,并列好解决方法。以会议的形式开展,既然是开会,时间大概是30分钟到1个小时,视具体项目而定,但是开会是一个耗费脑力的活动,不易过长,不然越到后面效率越低。

2. 代码走查(Walkthroughs)

与代码检查相同,代码走查参与者所持的态度非常关键。提出的建议应针对程序本身,而不应针对程序员。换句话说,软件中存在的错误不应被视为编写程序的人员自身的弱点。相反,这些错误应被看作是伴随着软件开发的艰难性所固有的。很多时候有些直属领导会直接就事论人,这样就会让软件开发作者受到打击,并且树立不好的形象,最终导致整个开发团队氛围的改变。不要在事后说控制不住或者性格这样请见谅的话,一旦不好的风在团队中刮起来,会导致团队中的成员或多或少心里有个带爆发的小宇宙,就不知道什么时候会爆发而已。所以说,态度很重要。

3. 桌面检查(Desk Checking)

人工查找错误的第二种过程是古老的桌面检查方法。桌面检查可视为由单人进行的代码检查或代码走查:由一个人阅读程序,对照错误列表检查程序,对程序推演测试数据。

对于大多数人而言,桌面检查的效率是相当低的。其中的一个原因是,它是一个完全没有约束的过程。另一个重要的原因是它违反了上文提出的测试原则,即人们一般不能有效地测试自己编写的程序。因此桌面检查最好由其他人而非该程序的编写人员来完成(例如,两个程序员可以相互交换各自的程序,而不是桌面检查自己的程序)。但是即使这样,其效果仍然逊色于代码走查或代码检查。原因在于代码检查和代码走查小组中存在着互相促进的效应。小组会议培养了良性竞争的气氛,人们喜欢通过发现问题来展示自己的能力。而在桌面检查中,由于没有其他人可供展示,也就缺乏这个显而易见的良好效应。简而言之,桌面检查胜过没有检查,但其效果远远逊色于代码检查和代码走查。

4. 同行评分(Peer Ratings)

这种人工评审方法与程序测试并无关系(其目标不是为了发现错误),却仍在这里谈到,这是因为它与代码阅读的思想有关。同行评分是一种依据程序整体质量,可维护性、可扩展性、易用性和清晰性对匿名程序进行评价的技术。该项技术的目的是为程序员提供自我评价的手段。

三、 模块(单元)测试

模块测试(或单元测试)是对程序中的单个子程序、子程序或过程进行测试的过程,也就是说,一开始并不是对整个程序进行测试,而是首先将注意力集中在对构成程序的较小模块的测试上面。这样做的动机有三个。首先,由于模块测试的注意力一开始集中在程序的较小单元上,因此它是一种管理组合的测试元素的手段。其次,模块测试减轻了调试(准确定位并纠正某个已知错误的过程)的难度,这是因为一旦某个错误被发现出来,我们就知道它在哪个具体的模块中。第三,模块测试通过为我们提供同时测试多个模块的可能,将并行工程引入软件测试中。

这是我所亲身经历的。当时我在开发一个平台代码,python。可以说是一个中性的系统,但是模块分工明确,开发人员分工也明确。所以当我们编写好自己所负责的模块后,自己编写单元测试代码,通过打桩,让每一行、每一个代码分支都被覆盖。而当时我们使用pytest、mock模块,结合Jenkins平台,就可以搭建出一个可视化的测试平台,查看代码覆盖,没有覆盖的代码会标记不同的颜色,很方便查阅。通过对每一行、每一个分支的覆盖测试,这样代码质量就提高了。

当然每种语言都有他相应的单元测试模块,但是思想是一致的,即不需要运行系统,就可以将模块代码中的每一个逻辑都覆盖到。

四、 调试(DEBUGGING)

下面列举了一些常用的调试手段。

1. 暴力法调试(Debugging by Brute Force)

调试程序的最为普遍的模式是所谓的“暴力”方法。这种方法之所以流行,是因为它不需要过多思考,是耗费脑力最少的方法,但同时也效率低下,通常来讲不是很成功。

暴力调试方法可至少被划分为三种类型:

a. 利用内存信息输出来调试。

b. 根据一般的“在程序中插入打印语句”建议来调试。

c. 使用自动化的调试工具进行调试。

 

2. 归纳法调试(Debugging by Induction)

认真的思考能够发现大部分错误,甚至不需要调试人员使用调试工具。归纳是一种特殊的思考过程,可以从细节转到全局,也就是从线索(即错误的症状,可能是一个或多个测试用例的结果)出发,寻找线索之间的联系。参见下图:

3. 演绎法调试(Debugging by Deduction)

演绎的过程是从一些普遍的理论或前提出发,使用排除和精炼的过程,达到一个结论(错误的位置),参见下图:

4. 回溯法调试(Debugging by Backtracking)

在小型程序中定位错误的一种有效方法是沿着程序的逻辑结构回溯不正确的结果,直到找出程序逻辑出错的位置。换句话说,从程序产生不正确结果(如打印了不正确的数据)的地方开始,从该处观察到的结果推断出程序变量应该是些什么值。在头脑中,从这个位置开始逆向执行程序,重复使用“如果程序在此处的状态是这样的,那么程序在上面位置的状态就必然是那样的”过程,就能很快定位出错误。使用这个过程,可以确定程序中从状态符合预期值的位置点,到第一个状态不符合预期值的位置点之间的范围。

5. 测试法调试(Debugging by Testing)

最后一个“思维型”的调试方法是使用测试用例。这可能听起来有些奇怪,因为从本章一开始就将调试和测试区分了开来。然而,考虑下面两种类型的测试用例。供测试的测试用例,其目的是暴露出以前尚未发现的错误.供调试的测试用例,其目的是提供有用的信息,供定位某个被怀疑的错误之用。两者之间的区别是,供测试的测试用例会“胖”一些,因为我们尽量使用较少数量的测试用例来涵盖较多的条件,而供调试的测试用例则“瘦”一些,因为每个测试用例仅需要覆盖一个或几个条件。换句话说,当发现了某个被怀疑的错误的症状之后,我们需要编写与原先有所变化的测试用例,尽量确定错误的位置。实际上,这种方法不是一个完全独立的方法;它常常结合归纳法一起使用,以获得进行假设和/或证明假设所需的信息。它也可以和演绎法一起使用,以排除有嫌疑的原因,提炼剩下的假设,并/或证明假设。

 

五、 调试的原则

1. 定位错误的原则

  • 动脑筋
  • 如果遇到了僵局,就留到稍后解决
  • 如果遇到了困境,就把问题描述给其他人听
  • 仅将测试工具作为第二种手段
  • 避免使用试验法——仅将其作为最后的手段

2. 修改错误的技术

  • 存在一个缺陷的地方,很有可能还存在其他缺陷
  • 应纠正错误本身,而不仅是其症状
  • 正确纠正错误的可能性并非 100%
  • 正确修改错误的可能性随着程序规模的增加而降低
  • 应意识改正错误会引入新错误的可能性
  • 修改错误的过程也是临时回到设计阶段的过程
  • 应修改源代码,而不是目标代码

3. 错误分析

  • 错误出现在什么地方?这个问题是最难回答的问题之一,它需要通过对程序文档和项目历史进行回溯研究,但同时它也是最有价值的问题。它要求我们指出该错误的源头和发生时间。举例来说,错误的源头可能是规格说明中的一个模棱两可的语句,对先前错误的一次修改,或对最终用户需求的一个错误理解,
  • 谁制造了这个错误?如果发现有 60 %的设计错误都是由 10 名软件分析师中的某个人犯下的,或某程序员犯的错是其他程序员的 3 倍,难道这不是相当有用么?(不是为了处罚某人,而是为了进行培训。)
  • 哪些做得不正确?仅仅判断错误的发生时间和出现人员还不够,其中丢失的环节是准确地判断出错误发生的原因。错误是由于某人写得不清楚?是由干某人缺乏对该编程语言的培训?是打字错误?假设做得不对?还是因为没有考虑有效输入?
  • 如何避免该错误的出现?在下一个项目中可以进行哪些调整以避免该问题的出现?此向题的答案就是我们所寻找的最为宝贵的反馈信息或知识。
  • 为什么错误没有早些发现?如果错误是在测试引入段发现的,我们就应该研究为什么在更早些的测试阶段、代码审查和设计评审中没有发现该错误。
  • 该如何更早地发现错误?这个问题的答案是另一个宝贵的反馈信息。该如何改进评审和测试过程以便在将来的项目中更早地发现同类型的错误?假设分析的问题不是由最终用户发现的(也就是说,是由测试用例发现的),我们就应意识发生了一些有价值的事情:我们编写了一个成功的测试用例。这个测试用例为什么会成功?我们是否能从中学习些什么,无论是针对该程序还是将来的程序,设计出更多的成功用例?

再一次申明,分析的过程是很艰难的,但是找到的答案为改进后续的编程实践提供极其宝贵的价值。值得警惕的是,绝大多数的程序员和编程机构都尚未使用这种方法。

2006-01-04 18:43:00 cyz1980 阅读数 1956

                                     一个软件测试工程师05年工作总结

       2005年即将过去,虽然我2005年在Longtop的工作时间不长,只有不到3个月的时间,但是这将近三个月的时间里,本人认真的做好了本职工作,认真、积极、按质按量的完成领导安排的工作。

一、工作总结


总体来说,2005年我主要完成了以下几方面的工作:

l         项目测试工作

l         知识与经验分享

l         完成所需知识的积累

l         工具学习及研究

具体来说,如下:

1.  项目测试工作

这段时间,我主要是协助C.Y.X进行CMBP项目测试,主要工作内容有:

l         对测试用例的编写提供反馈意见;

l         对测试过程及测试情况进行分析,并提供意见;

l         设计业务测试数据的例子;

l         绘制系统关键业务流程;

l         进行主要功能的界面测试、功能测试;

l         按照测试用例执行测试,并提交测试汇报;

l        进行需求验证工作。

2.  知识与经验分享

这部分工作,主要表现在四方面:

l         完成项目测试经验总结

l         完成“测试经验交流与知识分享”简报,包括简报材料的制作。该简报内容包括:项目测试经验介绍、测试度量、性能测试知识介绍、LoadRunner使用经验交流。

l         对现有测试规范提供改进反馈意见;

l         根据以往经验,在CMBP项目中提供帮助。

3.  完成所需知识的积累

这部分工作,主要是为了更好的完成工作,学习所需的知识、工具及技能。我主要是根据《新员工入职指引表》的要求进行的。主要工作内容有:

l         学习金融行业业务知识

l         学习公司研发规范

l         学习研发部产品知识(保理项目、IntelliWorkflow、农行CRM系统、工作流知识)

l         参加公司或业务部门组织的培训(新员工入职培训、基于UML的面向对象分析和设计、金融衍生工具介绍)

l         学习缺陷管理工具TTP

4.  工具学习及研究

根据《新员工入职指引表》的要求,我了解Rational 测试解决方案和工具,并进行Rational Performance Tester的研究。完成对Rational Performance Tester的研究后,我提交了研究成果,包括:《Rational Performance Tester 6 介绍.doc》、使用Rational Performance Tester进行性能测试的例子及学习参考资料。



  二、2006年计划


2006年,我希望能通过参与具体项目的实践,达到以下目标:

1.  能将测试过程在项目中真正的运用起来,并让项目的开发人员了解我们的测试过程

2.  在项目中沉淀出一些部门成果

除了保质保量的完成项目测试工作外,我还将积极、主动的参与部门建设工作,和部门所有成员一起努力,在领导的指导下,将我们部门做成受到公司认可,有一定地位的部门。


三、对部门建设的建议


在部门建设上,我想可以从以下几方面逐步开展部门建设工作:

1.  对人员进行分工,或者说是团队成员的侧重方向进行明确

例如,同一测试技术或测试工具,可以不需要多个人同时研究,这样可能造成资源的浪费。

2.  强化制度建设

3.  加大对测试过程的实施力度

现有测试过程,过程文件上存在不易操作的地方。所以在实施上也相应的存在一些问题。另外,争取能让开发人员了解测试过程。如果能让开发人员了解测试过程,可以让测试工作更好开展,以及获得更好的配合。

4.  加强部门测试成果的积累与沉淀。

现在的测试成果保存在服务器上,很容易发生测试成果丢失的情况。加上还有一些测试成果未提交服务器,只是保留在个人机器上,很容易发生人走成果也不在的情况。另外,保存在个人机器上,也不利于知识的传播与分享,不利于部门成员技能的提升。

除了将已有测试成果进行有效管理外,还需要将已有的测试知识沉淀下来。例如,对项目的测试经验,性能测试的经验,测试用例设计经验等等。

2011-03-31 21:48:00 jackyy313 阅读数 441

做新的工作整整三个月,接手三个功能模块的质量保证;三个月来,经历缺东少西、茫然失措,到慢慢熟悉、独立处理,然而仍未达到完全掌控、游刃有余。其中主要一条是没有认清楚自己的主要职责,带领外包人员没有好好地引导其做事情;角色转变进入的比较慢。欲做好本职工作,许多东西要加强。

 

可喜可贺的是,对自己的认识加深了些,尤其是更多地考虑如何共同完成工作、共同提高和进步。“专注”这一优势主题,也充分得到体现。

把本职工作做好

阅读数 323

没有更多推荐了,返回首页