发现问题的方法,需要从代码中寻找BUG吗？

这个问题是几位网友发email问我的。在此谈谈我的一家之谈。如有偏差，还望各位同行提出相应的观点和意见。
按我经历和看到的测试，测试通常分为如下几个阶段：
代码走读，白盒测试，灰盒测试，功能测试，系统测试。
代码走读通常是由开发人员互相评审执行。（可以提前发现很多代码中的问题）
白盒测试通常借助一些白盒测试工具来执行，还是由开发人员来执行。（我个人认为ROI并不高）
灰盒测试通常是针对一些关键的底层代码，如driver，或公用度高的代码来进行。通过写一些测试C程序来测试覆盖被测代码。这个工作可以由开发人员完成，也可以由测试人员完成。但同样不需要测试人员看代码，前提是一定要有非常详细的被测模块的功能定义。
功能测试和系统测试都由测试人员完成。自然是黑盒测试，不需要代码。
以我的经验来看，是否发现bug，与读code没有任何关系。反而我认为读代码，会降低测试人员的效率。
为什么？测试人员读代码，我认为有如下几个坏处：
1） 会让测试人员进入黑匣，反而看不到这个匣子的形状和大小。并不利于测试人员设计好的测试方案。
2） 浪费测试人员的有效工作时间。既然读代码的目的是为了更好的设计测试用例，那么就应该多思考如何设计好测试用例。看代码并不是唯一的方法。我的经验是：公司对被测模块的功能定义文档的详细程度将对测试用例开发起到非常好的作用。同时应多向开发人员询问一些问题，如：哪些模块开发人员觉得实现时很复杂，或开发人员自己认为哪些地方更容易出错。
3）测试人员自身并不擅长代码部分，读代码效率也不会高。
这些年工作经验和职业经验告诉我一个道理：无论我们做什么，在公司一定要注意ROI就是投入产出比。你要先考虑公司的投入产出比，再考虑自己的投入产出比。对于中国的企业，普遍处于追赶型企业，项目紧，资源少。
需要在质量和投入上做一个平衡，有时减少一些ROI低的测试流程对公司反而是一件好事。
我个人的观点和建议是：在产品正式交给测试部之前，开发人员一定要先互相进行code review，有资源的情况下，最好能对一些很底层的驱动进行API测试，这样会大大降低傻瓜bug的出现，保护好测试人员的时间，提高测试工程师的效率。
在测试部这端，应把精力多集中在功能测试和系统测试中，多花时间思考好的test stratagem and test case. 在进行测试策略和测试用例设计前，一定要多争取向公司申请详细完整的功能需求文档，设计文档（不需要实现文档）。在进行测试策略和测试用例设计的过程中，一定要多请几位公司技术服务部的系统工程师，听听他们从用户真实使用的角度提供的测试意见，SE的意见会大大提高测试的有效性，提高测试工程师的效率。
对于一个功能，我认为需要有如下类型的测试用例：
1： 功能测试 2：组合测试 3：室外应用测试 4：性能测试 5：压力测试。期间几种测试也可以互相组合。那么对于测试人员如何提高设计测试策略和测试用例的能力呢？
  第一牢记ROI。第二丰富的测试经验。第三时刻考虑以市场导向。
  第四自己对功能需求的真正把握。第五系统实现技术了解的多少。
关于测试用例的设计，我以后会再开一个专题来谈谈我的一家之言。
现在给junior测试者一些建议：
   1：对功能需求要非常熟练，一定不能对功能需求有任何一点误解或是不清晰的地方。其次，必须对功能定义中的数据流也要了然于心。
   2：尽量多了解与所测功能有关的其他功能的应用，可以大大扩展你进行创造性设计时的素材。
   3：多向开发者要一些不涉及代码的设计文档，这样你可以知道哪些地方在实现的时候复杂度高，容易出错。那你就进行重点攻击。
   4：多学习本公司产品实现的主要技术。例如：我在通信厂商，自然一切代码都是依托vxworks来实现的。所以，我在进行了3个月的测试后，自己从公司借了一本vxworks基本技术介绍的书来看。搞清楚了开发人员常常会用到的数据结构：如循环链表，mbuf, 知道了什么情况下读指针会跑到写指针前面导致data access的发生等等。 古人云：知己知彼，百战百胜。也就是这个道理。如果测试者对产品实现的主要技术有一定广度的了解，那么你设计的测试用例就会更有穿透力。
   5:  勤奋。在完成规定的测试后，自己多想想那里还可以再提高，再完善的。对自己潜力的挖掘，一定会大大提供你思维的发散性的，丰富自己的测试方法。