软件测试是一项灵活多变的工作。就测试方法而言，可分为若干种，且似乎每一种方法都能找到和他大体相对的另外一种方法。所谓相对，是指各关注的侧重点不同。本文所阐述的感悟是，此相对并非对立，更不是互斥，而是相互的补充。
对于具体的测试方法，有些观点大加赞扬其一，却极力贬低相对的另一种。我对此是持保留意见的。我认为，与其说“测试方法”，不如说它是一种“测试技巧”。工作中，经验技巧当然多多益善，且不存在孰是孰非的问题。我们要做的是，如何取长补短，把他们有效地结合起来。下面举几个典型的例子：
一、正向思维 VS逆向思维
首先抛出一个老生常谈的问题：软件测试的目的是什么？
谈到测试目的，还得引出另一个相关问题。我们都知道，对于一款产品或一个项目的测试，无外乎两件事，一是功能性验证，一是搜寻缺陷。那么，软件测试是以找bug为主还是以功能验证为主呢？哪一方面更重要呢？
我和诸多同行一样，在工作之初很自然地就陷入了误区——测试人员当然是以找bug主了。但是，随着对测试工作的逐步认识，越来越觉得“熟悉业务”和“验证功能”的重要性。并认识到，保证发布版本的功能稳定，满足客户的需求，是测试人员的责任。
也就是说，功能验证和寻找缺陷是同等重要的，缺一不可。在有些时候，功能性验证的优先级会更高一些。虽然意识到了这些，但潜意识里仍觉得，如果测试人员光验证正确的功能，却测不出bug，在工作业绩上会大打折扣。还有一次，一位高层领导讲了一句名言，他说：“好的软件是写出来的，不是测出来的。”从字面感觉，似乎对测试工作有否定的意味。我当时甚至还为此进行过驳斥，但后来经过反复论证，这句话并没有问题。
既然软件测试并不能保证产品的质量，那么测试的目的到底是什么？
我曾一度地因此而迷茫和困惑。直到有一天，业内的一位资深同行提供了一个答案，他说：“测试的目的，是为了验证产品符合设计和需求的程度，衡量产品可发布的状态。测试是为了防止bug而不是单纯地找bug。”查资料，IEEE在软件测试的定义中也指出：“（软件测试是）使用人工或自动的手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。”一语道破天机，我这才豁然开朗。
所以，就测试目的而言，之前的感悟仍然正确。功能验证和发现缺陷同等重要，不能仅强调其一，他们都是实现测试目的的重要手段。“功能验证”是为了“检验是否满足规定的需求”，“发现缺陷”则是对“预期结果与实际结果之间的差别”的预警。
“功能验证VS寻找缺陷”，我想，这其实是“正向思维VS逆向思维”的表现形式之一。在具体的测试方法中，还有很多：比如，测试数据的有效范围与无效范围、常规测试用例与非常规测试用例、正常范围与边界值等等，以及其他具体的正逆向思维方式。正向思维和逆向思维，两者之间是相互补充的关系，不可以偏颇。两手都要抓，两手都要硬。
二、黑盒测试VS白盒测试
打个也许不太恰当的比方：黑盒测试与白盒测试有点儿类似于中医和西医的关系。中医凭借望、闻、切、问来诊断，是建立在大量实验基础上的，可以说是一门经验科学；而西医则是建立在解剖学的基础上的，通过透视每一个器官的细节，了解其工作机理来诊断。
测试也是这样，黑盒测试是一种传统的测试手段。方法简单，可通过基于客户思维的应用来验证功能，也可以通过各种正逆向思维分类归纳出测试用例进行验证。黑盒测试提供可知的信息有限，设计测试用例只能采用猜测和穷举的方法，势必会存在大量地盲点。所以，黑盒测试类似于中医诊断，也是一门经验科学。测试人员的阅历越长，秘籍越多，经验越丰富，眼光就越毒辣。
白盒测试的优点自然很多，好比西医，能透视每一个模块的细节，可跟踪到每一层逻辑。可触及到代码的每一个角落，甚至可以进入if /else、switch/case里永远达不到的条件进行测试。所以可以设计出更多更丰富的测试用例，可以找出更多更重大的缺陷和隐患。对于同样方法存在的错误或隐患进行类比，防止在其他模块中出现等等。但受限于企业理念和测试人员的水平等因素，有能力实现白盒测试的软件企业还屈指可数。
正如中西医结合治疗疑难杂症效果显著一样，黑盒与白盒也应是一种相互补充的关系。白盒测试可以聚焦局部细节，可debug跟踪代码的执行的过程。但黑盒测试更能以客户思维模拟出最终用户的使用场景，体现用户的真实所需所感，更能以客户角度来衡量产品的可用状态。
所以，我觉得，在条件允许的情况下，一直采用传统测试方法的企业应适当地尝试些白盒测试。而有实力做白盒测试的企业，却不应忽视黑盒测试的作用。
三、手动测试 VS自动测试
自动测试可基于黑盒，自动运行设定的或自动生成的测试用例，以及基于白盒的编码规范性检查等等。自动测试对大规模的功能验证占有优势，也正因为有了自动测试，才使“无为而治”的测试最高境界成为可能。
但自动测试受限于投入成本（时间、人力、物力），以及软件的特性等因素，且缺点是难以有效地发现bug。而测试人员查找缺陷的职责，不仅仅是要发现bug现象，更重要的是要总结出bug的发生规律。所以，即便自动测试在运行测试用例过程中出现了错误，但追究其错误原因、捕获线索、总结规律等也需要人工干预，并且在很多时候必须依赖于人的智慧。
手动测试机动灵活，可根据当前的测试用例随机多变地进行组合引申，指哪儿打哪儿，更容易发现问题定位问题和总结规律。此外，手动测试更能以客户思维对软件的可用性和易用性进行评估。由于版本的更迭，功能的增删改等等，自动测试也许永远不能完全代替手动测试。
所以，应积极地辅助于自动测试，却不应过分地迷信它。
宜把自动测试作为手动测试的补充。比如，对于有规律的、大数据量的、重复性强的、压力或性能测试、版本回归测试、可回放的功能性验证等等，尽量采用自动测试。自动测试在这些方面有着手工测试无法比拟的优势。
四、拆分打散 VS交叉组合
当面临一个新的大型系统时，整体了解往往无从下手。于是首先想到的便是化整为零，分模块，分零部件，对每个功能，每个功能中的每一细节进行验证和测试。
好比一部汽车，由成千上万个零部件构成，每个零件都有自己特定的功能，所以保证每个零部件都合格并正常工作是至关重要的。但是，单一零件固然重要，而整体功能和性能才是用户的真正的所需所感。
随着测试的深入以及对业务的理解，分散的模块再逐步被组合起来，并对各项功能进行交叉组合验证，最后对整体（流程）进行测试。所以软件测试中，不忽视每一个细节，更要把握全局。
五、注重技能 VS 熟悉业务
测试方法和经验技能固然重要，但各种方法和技巧的运用，却都应建立在对业务理解的基础上。参见另外一篇感悟文章《不熟悉业务是黑盒测试的悲哀》。链接地址：http://www.51testing.com/index.php?action-viewnews-itemid-220628-php-1
大家知道，“细心、耐心、责任心”是一个测试人员应具备的基本素质。我想还应再加上“虚心”二字，即虚心熟悉业务。我认为，一个优秀的测试工程师，不仅是技术上的专家，更应是业务上的专家。软件测试，熟悉业务是根本，设计测试用例是关键，各种测试方法和经验技巧的运用是达到测试目的的手段。
总之，软件测试不同于其他工作，每种方法都是一把有用的工具。不同方法与技巧之间相互补充相辅相成，不必宣扬一方而贬低另外一方。为了测试的目的，应尽可能地综合运用他们。另外，针对各种方法，不同测试人员会有不同的喜好和擅长，所以，宜发挥各团队成员的优势能力，在测试分工与考核中应特别考虑。
