hmchzb19<em></em 阅读(58) 评论(0)
1. 测试真的需要吗? 如果需要,测试的成就体现在哪里?
软件测试:就是代码质量高,跟你没关系,代码质量差,你也看不出来。软件测试工作效果体现在哪里是个很大的问题。
所以很多时候软件测试变得更官僚,精致的报告,各种chart 横行,动不动就是测试用例 x 测试平台算笛卡尔积。而忽视了测试本身。
我见过一个ksh 脚本居然写上了read -p ,read -p 是 bash 的用法,而ksh 没有这样的用法,没人愿意管这种小问题,到我这里,我直接改脚本 pass.

2.  软件测试是怎么烂掉的。
a.如果老板说6月1号要release, Ok ,那么下面的人就不会找事,在5月份的时候就不会报太多的defect 了,这样方便developer , 也方便测试能按时完成任务,毕竟老板的意志最大。大家都心知肚明,到了6月1号该release 一定会release, 解不完的defect 会自动进入下个release 或者以fix pack 的形式发布。 

b. 设计测试用例的人都是测试中的领导层,而不是动手跑测试或者需要去实现测试的人,这就给瞎指挥和乱写测试用例埋下了伏笔。
设计测试用例的人让领导层觉得这些设计简直天衣无缝,覆盖面广,涉及了大量的稳定性和高并发测试。例如:我见过一个测试用例,要去deploy 一个virtual server, 以10线程,跑10次。要保证100个全部成功,这个测试用例从来没有100%成功过,但是到了release 的时候,这个测试一定是通过的。作为一个测试人员,如果你的测试用例根本不切实际,那么你的best interest 就是假装测测,然后到了时间直接pass. 这种跟“cloud”相关的测试本身就很难,因为deploy 要设计成一个类似于原子操作或者数据库的transaction 的类型,成功就成功,不成功则意味着要全部回滚。而deploy 一个virtual server 本身是个长流水线。

c. 测试的耦合度:代码总是说松耦合,而测试上我见过不少人却都喜欢用紧耦合的方式来做。例如,A做完一个测试用例的byproduct是刚好能给 B的测试设置好环境,这时候就会变成 B 依赖于A, 如果A 完不成,B 就什么都做不了。写报告的时候这是: A 成了B 的blocking issue , 领导会追问A 为什么你block 了这么长时间,什么时候能继续, 而忽视了其实B 什么都没有做。这种紧耦合其实就是坑前面的A。 

3. 谈谈人的因素
例如要测数据库: 
那么java 就是通过JDBC/ODBC 去调sql, 而建库,建表在linux 上很多时候直接是sql 脚本文件直接用bash -c 去执行。
对于数据库做备份的时候,Oracle 很多时候是调用RMAN , 而mysql的 mysqldump 足够做线上和线下的备份。
我接触到一些软件测试,只会跑集成的命令,就把数据库建好了,备份完成了,从来不考虑这些手动做的话怎么做,只有你知道手动怎么做,你才了解各种脚本里面到底都做了些什么,才可以更好的测试代码。对于底层细节的了解才是关键,就像冰山,只了解水面上的10%那远远不够。

4. 对于搞技术的人来说,blocking issue 一般还是因为你的技术还是不够强。
当然这句话有点装逼了。从操作系统来说,Linux 无非是C 和inline 汇编,Glibc 可以用IDA pro 逆向, strace 可以查看系统调用,Java 是我最不熟的。
而perl/python/php 和 各种shell 大都是明文可以直接看代码。(当然如果只有pyc 的话我也不晓得怎么办),从这个角度看,软件测试要掌握的东西有很多,才能碰到各种问题都能迎刃而解。 其实并不是这样,人的因素其实最不可控,毕竟每个人的知识面不可能横跨这里所有的面,且在每个层次上都达到很高的高度。