公司新职员工作心得感受

来源:职场范文网 时间:2020-09-25 17:42:40

  公司新职员工作心得感受

  公司的产品种类相当丰富,在测试当中接触的产品多种多样。刚开始接触某个产品时,首先先弄懂这个产品是干什么用的,熟悉产品的基本功能。接着应多动手操作,有些产品会有使用说明书,不能一味地看说明书而不进行实际操作。职场范文网小编为大家整理的公司新职员工作心得相关资料。提供参考, 欢迎阅读。
 

公司新职员工作心得感受
 

  本人是新员工,刚好到了转正阶段,趁着这次机会,对这三个月试用期的学习心得做个总结,也可以给后面的新员工学习提供点建议。

  1. 企业文化与规章制度

  进入一个公司,我觉得立即开展工作并不是首要的,首要的任务是要了解这个公司的文化以及规章制度。你只有认可了公司的企业文化,才能更有激情地融入到公司之中,每天上班的心情也比较愉悦。

  很难想象在一个自己并不认可的公司里面工作是一种什么心情,恐怕很快就会丧失工作斗志了,整天浑水摸鱼、得过且过,个人能力没有得到提升,对公司也会产生不利的影响。

  所以进入优特,在三个月的试用期中,第一个月便是学习公司的企业文化与规章制度,我觉得公司制定这样的学习计划是很有必要的。在学习的过程之中,不能一味地接收而没有思考,公司的制度是用来规范员工的行为,同时也是为了公司的有序运行,提高工作效率。所以如果觉得有不合理的地方,也可以向公司的相关部门提出建议。

  2. 测试产品

  公司的产品种类相当丰富,在测试当中接触的产品多种多样。刚开始接触某个产品时,首先先弄懂这个产品是干什么用的,熟悉产品的基本功能。接着应多动手操作,有些产品会有使用说明书,不能一味地看说明书而不进行实际操作。

  “纸上得来终觉浅,绝知此事要躬行”,在实操过程中才能更快地熟悉产品的功能。当碰到不懂的地方时,要及时请教导师或者身边的同事,把每一个疑问弄懂弄透,这样在以后的测试当中能够减少很多不必要的麻烦,测试效率也更高。

  此外,如果时间充裕的话,可以找一些测试产品进行模拟测试,参照测试用例库进行测试,这样一方面可以熟悉产品的功能,另一方面也可以熟悉测试用例的编写规范以及编写格式。通过实操在熟悉测试用例比直接看测试用例而不动手进行测试,效率会高很多。

  3. 编写测试用例

  我认为测试用例是测试环节的重点,测试用例写得详细准确,对于测试会产生事半功倍的效果,同时也能够体现测试人员对于测试的用心程度,因为其他人往往也只能通过你提交的测试用例来了解你对这个产品的测试内容以及测试的广度和深度。

  我觉得编写测试用例对于新员工来说是最困难的一个环节,一方面是对于公司产品不熟悉,对某些功能的操作步骤不清楚;另一方面是之前没有学过编写测试用例,不知从何下手,要怎么组织语言。

  我认为可以从以下几方面来学习编写测试用例,渐渐地做到得心应手:

  1) 参考测试用例库,我们部门有很详细的测试用例库,都是以前测试时编写的测试用例集合起来,并且做了统一的整理,对于我们新员工的学习是很有帮助的。

  2) 多动手实践,熟悉测试产品的功能。当对产品的功能熟悉了之后,写起测试用例就轻松很多,只需把自己实操的步骤以及预期现象写下来就行了。

  3) 要多“反其道而行”,不按照正常的操作步骤去操作产品,测试就是为了发现产品的缺陷,而缺陷往往就存在于异常的操作步骤之中。比如测试电脑钥匙的时候,开锁的过程正常是插入钥匙-验证锁码-开锁,这时如果在验证锁码的过程中拔出钥匙会出现什么结果,这些就是我们需要考虑到的“反其道而行”。

  4. 测试过程

  1) 在测试的过程中,除了按照我们编写的测试用例进行测试,一边还要关注是否还有自己考虑不周全的地方,这时可以再增加到测试用例之中,这样可以使我们的用例更加完整,另外在以后有问题进行追溯时也可以证明自己没有漏测。

  2) 在测试时,如果时间比较充裕的话,有些比较重要的功能可以多测试几遍,有些功能往往在第一次操作时没有问题,当多次操作之后就会出现问题。

  3) 在测试过程中要勤于记录问题,比如遇到问题时可以立即截图,或者用手机进行拍照、录像。因为有些就是随机性问题,这次出现了可能下次又没有出现,复现问题比较困难,我们养成及时记录的习惯,一方面可以证明这个问题确实出现过,另一方面也方便开发人员寻找问题出现的原因。

  5. 关于缺陷

  1) 当测试过程中发现问题时,首先应与开发人员沟通,看是不是自己理解错误或者操作错误而导致的结果异常,如果是的话就不是缺陷,提前与开发人员沟通可以避免提交无效的缺陷。

  2) 对于有些问题,开发人员认为程序设计就是如此,认为不是缺陷,或者此问题可以忽略不计。这时我们就应该有自己的判断,而不是一味地认可开发人员的结论,因为我们是站在用户的角度,是从用户体检出发,而不是从程序本身设计出发。

  3) 当有些问题开发认为不是缺陷而我们经过判断自己认为是缺陷时,还是应该把它判定为缺陷,毕竟最终对产品的使用者是用户而不是开发人员,产品是为用户服务的,而我们测试人员就是用户。至于最后怎么处理就是开发跟项目经理的事情了。

  4) 要做到“举一反三”。一个缺陷在某一个产品中出现时,在同类的产品中也有可能出现,因为同类产品的代码都是比较相似的。当我们测试某个产品时,就要回想之前测试的同类产品中有哪些缺陷是比较严重的,这时就要重点关注一下。比如我在测试1F电脑钥匙时,就发现一个之前在3C电脑钥匙上出现过的缺陷。

  5) 有时间的话可以进入 企业平台-系统测试-缺陷跟踪,看看其他同事之前提过哪些缺陷,哪些地方是我们测试过程中没有关注到的。另一方面可以举一反三,比如我在测试1F电脑钥匙的时候,就去查看3C电脑钥匙提过的一些缺陷,后来发现3C电脑钥匙的一个缺陷在1F钥匙上也有这个缺陷。

  以上就是我在这三个月试用期的学习中的一点学习心得总结。