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 的话我也不晓得怎么办），从这个角度看，软件测试要掌握的东西有很多，才能碰到各种问题都能迎刃而解。 其实并不是这样，人的因素其实最不可控，毕竟每个人的知识面不可能横跨这里所有的面，且在每个层次上都达到很高的高度。
5. 测试和法律：
在法律上讲究谁主张，谁举证。在软件测试中，我一直在考虑，如果主张这个原则的话，则就对测试提出了更高的要求，也就是说测试必须从功能性的failure 追溯到代码的问题。
而现实中很多时候，测试人员最多看看是哪里抛出来的Exception, 然后全部就交给了开发去解决。所以从这个角度看，测试的工作确实不怎么重要。
开发如果说：请测试来说明下，这个failure 会影响到哪些功能，是不是可以不修复。出个文档请大家规避呢？
测试往往变成了被牵着鼻子走。
阅读(3789) | 评论(0) | 转发(0) |
