发布新日志

  • 10多年的测试

    2021-06-07 15:37:59

       回想一下,干测试已经有10多个年头,时间过的真快,当时也没想到自己会干这么久。
       还记得刚开始从开发转测试那会,那还是2017年的事儿。记得当初面试的公司是一家做咨询的公司,开发部总共有6个成员,除了项目经理,其他的都是开发,根本就没有测试人员。我是第一个测试人员,估计也是唯一的一个,当初项目经理的规划还挺好的,不光让我学习软件测试,还需要学习配置管理,还有Python,还用Python配置了Bug 管理系统,现在想想当初还学了不少东西。后来项目经理走了,慢慢的他的规划也搁置了。再后来,因为公司的重点是咨询,所以开发部门就是一个辅助的部门,慢慢的开发租就剩4个成员了。
       再后来我就跳槽到了现在这家公司(外部公司),都说在外包公司干活比较累,但是我个人觉得还行。虽然工资比较高,但是用的知识比较片面,就只有软件测试,有一点比较好,因为接的项目是国外的,所以对英语要求比较高。刚开始是单纯的测试,客户开发完了,发给我们,然后我们帮忙测试,提交bug, 客户修复bug,我们接着验证bug,其实这种的对客户的需求并不是10分理解,当时,这样的项目还挺好的,我记得另外一个项目,项目组成员有10多个人,而且他们的英语都特别好,他们每天都要和客户开视频会议,而且还有外面员工和我们一起工作.在后来,这样的项目没有了,渐渐的,有好多做测试的员工就离职了。 我相对是比较幸运的,被分到了开发团队(就是现在的团队),就是和开发一起来工作。一起分析需求,然后评估,然后写用例,开发提交了,就执行用例。再后来,项目越做越大了,就引入了自动化测试,刚开始用的是Python+robotframework,后来又变成了VSTS。
       一路走来,虽然有很多加班的日子,但是回想起来还是比较开心的,因为我喜欢测试,有时开发提交了,都有感觉说那块肯定有问题。这也许也是经验吧。而且现在这个单位比较人性化,可以在家办公,这样就可以照顾孩子。
  • iPad 上Application 的测试

    2012-05-14 15:48:03

    IPad 上的App 的测试

    1.    安装App

        在IPad 上安装任何App,都需要一个认证文件,意思就是说,要想在IPad 上运行某一程序,IPad 必须认识它才行

            2.   IPad 的屏幕可以旋转,所以要测试在旋转的过程中,App是否能正常运行

            3.   在测试App 的时候,经常会碰到App 用着用着就会崩溃,在这种情况下,就要把IPad 上的log 同步到    PC上,查看到底是因为IPad内存不足还是App本身有严重问题

             4. iPad 上只能通过滑动屏幕来移动页面,所以要测试在滑动的过程中,能否到正确的页面。

              5. 更新App App的新版本能否顺利的安装

              6. App 当要输入数据的时候,键盘是否能及时出现,出现后,键盘上显示是否正确

              7. 退出App,这个AppIPad上的资源是否能释放

  • B/S 和C/S程序测试的区别

    2012-05-14 15:39:21

    1.      

    C/S

    1.           C/S要有安装/卸载测试,包括服务器端的安装/卸载和客户端的安装/卸载,其次是客户端能否顺利的和服务器端连接上。B/S不需要这方面的测试。

    2.       B/S必须要在浏览器上测试,所以浏览器的种类和浏览器相关的Cookies等的设置也属于测试点,在测试的时候都要考虑。而C/S不需要这个。

    3.       B/S 要求有性能测试,就是如果同时有500个人访问,软件会不会反应太慢,软件会不会突然死掉之类的。而C/S对这方面要求一般,因为每人机器上都有客户端,有些工作不用在服务器端完成,不用一直不停的访问服务器端

    4.       B/S 的安全型测试要比C/S的高,因为B/S的程序谁都可以访问,这样就扩大了它的危险性,而C/S只能有客户端才能用,就限制了使用者的范围,同时也降低了它的危险性

    5.       C/S 软件如果有补丁包的话,还要对补丁包的更新进行测试。B/S 没有这方面的测试。

    具体到每一个模块的测试,都是一样的,都要进行功能,界面的测试。

  • 如何书写bug?

    2011-07-19 17:42:24

    对于每一个做测试的人员来说,写bug是天天要干的事,也是测试员的基本技能要求。可是如何写出“漂亮的”bug 那?

    何为“漂亮的bug”呢?个人觉得应该包括以下三方面:

    1.       根据bug 步骤能重现bug

    2.       程序员看到你的bug, 心情没有变糟糕

    3.       程序员看到你的bug 后,基本上95%知道问题出在什么地方了。

    关于第一点,很简单,这也是bug 的最基本要求。就是把我们的操作步骤一步一步列出来就可以了。

    关于第二点,应该也不是很难,就是bug描述要越简单越好,不要写的太长,能用3步说清楚决不要写5步,不仅是程序员不想看,就连自己验证bug的时候也会觉得,这个bug 怎么这么麻烦呀。这和我们说话一样,一个字能表达的,千万不要用一句话,会觉得很啰嗦。

    关于第三点,可能就有点难度,一个是要靠经验,而另一个是要懂一点开发。经验可以告诉我们这个问题通常是由什么引起的;开发基础知识让我们了解这应该和那个模块用的是同一个类,这个模块有问题,另一个模块会不会也有问题那。我们有了这些经验就可以在写bug 的时候,写一些比较关键的步骤,不必要的步骤可以省去。还有就是有时候我们会觉得,应该是同一个类下的内容,为什么在一个模块是好的,在另一个有问题,在这种情况下,bug中不光要描述问题的重现步骤,还要说一下在其他的模块是好的。这样有助于程序员排查问题。
  • 2009年5月21日

    2009-05-21 17:10:07

    2年测试生活的总结
      2007年6月一个偶然的机会我开始做测试工作,公司的开发部很小,只有5个开发工程师,以前没有测试人员,我是第一个。而我以前也没有做过测试,在测试方面相当于零,进公司以后就开始自学,然后把自己所学到的知识都应用到平时的工作中。2年后的今天,我又在测试一个软件,在连续的点击一个控件,结果显示的控件竟然不一样,我就让程序员看,他竟然说:没有这么傻得客户去连续的点同一个控件。当时听了心里很不好受,以前我测软件的时候都是我说了算,一点界面上的问题他们都的改,可现在那?我有时候测出一个问题,程序员竟然说,这个是控件的问题实现不了。回头想想,可能是我的测试技术跟不上他们的要求了吧。以前没有测试人员,所以我来了以后软件的质量提高了,但他们现在觉得,刚靠手工测试达不到他们对质量的要求了,应该再做些性能测试、安全测试等。可说实在的,公司就我一个测试人员,关于测试只有我一个人做,测试流程、测试用例等都没有。这些东西我只能上网学,公司又不给安排测试培训,领导对测试也一点也不重视,而且有时同时两个项目要测试,也没有太多的时间用来学习。心里很困惑,是我自己进步太慢了吗?以前工作也特别开心,现在一点也不开心。

Open Toolbar