软件测试之我见
软件测试之我见经历过正规的培训,也独立完成了一些简单或是比较复杂的项目,大部分是基于B/S架够的开发.
在这段时间做的几个C2C项目给我的感受泊深,虽然在以前的公司也参与过,但没有象现在这样系统的负责过一个大型项目从头到尾的测试.根据对几个公司(以前和现在的公司几乎是B2C和C2C领域的老大)实战项目的经验,发现51的课本知识还是有很多弊端的,虽然里面的老师都有很丰富的经验.
最严重的问题是教学重点不明确,过于强调黑盒测试,可能我的思路和别人不大一样,有人认为黑盒测试也能出高手,其实不然,黑盒测试的关键在于你多熟悉这个业务流程,有多熟悉模块的功能点,这和测试技巧无关,关键是你的理解能力,对模块理解更多的则可以针对这些功能点更好的去编写CASE覆盖,这没有什么精不精的,做个3,5年等你把公司的产品全吃透了,自然黑盒做起来得心应手.51的学习过于强调这快,个人认为黑盒没什么前途,只要你是个人,接触1,2个实际的项目能从头到底测一遍,我赶说,你黑盒这快没问题了,有的只是细节和流程上的问题,但公司的流程每个都不一样,怎么能和书上相比呢?书上那套我估计CMM5的公司也没做的那么详细.
我们学测试花力气应该花在哪?
首先要学好DB,要精通T-SQL,在DB中有时候能更清楚的反映问题,也可以看清很多前台不会反映的问题,当然DB开发的能力也会影响你的操作.但个人认为DB的能力一定要强, SELECT语句要用到出神入化.
要逐步的去学习白盒,白盒的学习非一朝一夕,因为他要有个编码的积累,现在的主流开发是C#和JAVA,因此学好这2个的UT测试还是很有必要的,一是提高自己,二是不管以后去哪,会UT测试都是很吃香的,但没做过开发是很难高效的完成UT测试的,建议可以先编写测试框架,测试用例由开发完成,毕竟开发肯定要比你熟悉自己写的代码.然后你在去看他的CASE总结经验提高自己的编码水平,如果你能发现他代码级的错误,那么你到哪都是个"牛人",至少开发不会觉得你一无是处,老是找些小毛病去刁难他,发现代码级的BUG或是逻辑上的BUG才是王道.
然后要说下性能测试,性能测试运用的其实不多,也只有大公司用下,一般的情况都是为了防止流量过大导致系统奔亏,为系统奔亏后该怎么做去做准备,小公司基本不用,一般情况下从后台看下实际的性能情况就够了,可能大家会觉得公司不负责任,但现实就是如此,
性能测试发现的错误不外呼3种,1.代码级的问题,当项目成形后一般不会去动,做过测试的都知道,可能一修改会导致大范围的问题出现.2是硬件问题,一般的公司不会因为你性能差一点点就去更换或添加服务器,毕竟公司也是要核算成本的,好的服务器价格可不便宜,3是网络拓扑的问题,这个修改起来就相当麻烦了,一般没人去动它.所以性能测试不大能改变什么现实最多达到个预防的作用,比如在本亏的时候有什么补救措施,个人认为性能测试应该多针对DB测试,如果是应用程序的服务器,那没什么好说的,流量大了最原始的方法就是加服务器搞分流,况且还有负载均衡器,但DB就不一样了,访问量大只能拆表,但拆表是有限的,不能无限制的拆下去,所以用性能测试测下DB是有必要的,现在大多数的服务器本亏都是DB服务器的OVER.
深夜感冒无法入睡,写点东西和大家分享,本人也是菜鸟,欢迎大家指正批评. 没上过课的路过！ 没经过正规的培训，属于开发转测试。看你这篇帖子写的很早，不知道你现在还在做测试吗？
页:
[1]
