也谈手工测试

   最近在准备Selenium的培训课程，因为有三课时，所以预计授课内容不局限在Selenium工具本身，而是系统的介绍下将近四年的自动化测试相关工作中学习到的技能和自己的愚薄感悟。
   做自动化测试，可能在内心都有一个常识：自动化测试无法取代手工测试。这种见解在网络上随处可见。翻开Ron Patton的《软件测试》这本书，自动化测试相关章节是被放在第四部分：‘测试的补充’。从所隶属的章节也可看出，作者本人也是认为自动化测试，或者说基于工具的自动化测试是作为手工测试的补充，它的意义在于：帮助软件测试员更好的工作。
   可能一些新手因此便误以为自动化测试不过是噱头，没有太多实际意义，从而不重视。之前和自己的领导交流时，忘记从哪里看到一句话：自动化测试的本质就是写软件测软件。而领导也认为：所谓的自动化测试分为两种，全自动化和半自动化。所谓的全自动化就是借助既有工具或者自己实现工具，以框架模式加工待测试数据，在一系列处理流程后，给予完成的测试报告，整个过程中毋须人工干预的测试方式。当然，与之对应的半自动就是指利用一些工具或者脚本（脚本当然也可以认为是简易版的工具），在人工交互下，完成特定测试目的的过程。
   现在网络上随处可见的各种框架论，其实在我们这里也在尝试实现订制化的测试框架。正如我的个人签名：测试员的工作在于管理复杂度。而一些场景下，在复杂度不足以需要引入框架的情况下，盲目的引入框架本身就提高了测试工作的复杂度，是不足取的。
   前面所描述的自动化测试，与之对应的是编码能力，将固化的任务流程转变为可执行代码的能力；而后面的自动化测试框架，则体现设计功力，是对理解设计模式并且具有大量编码经验之后才能有的抽象能力。
   综上所述，我还是非常强调测试人员的代码能力并且个人认为，随着测试行业的发展，所谓的研发和测试这种工作分工间的界线会越来越模糊。关于这点可以参考当前结对编程，测试驱动开发等一些理念。当然，我对此也是一知半解，不过我们可以从中借鉴的是：测试人员一定要培养自己的代码能力。

   今天中午同事一起吃饭，谈及工作，同事说：你们现在就应该不做产品测试，一门心思的去进行自动化测试的相关工作。当然，这和我所在的组工作性质有关，主要是在部门内部介绍一些测试方法，并协助各产品组进行自动化测试的工作展开。我回答他说：其实我一点也不想完全做自动化测试工作，相反，我反而想更多的做一些产品的手工测试工作。他愕然。
   这些不是客套，我的确也和头多次要求多进行一些产品的手工测试工作。这样的想法，首先在我想法中一直坚定的认为：所谓的自动化测试无论是UI功能还是后台的处理，数据交互，或者是借助工具的性能，本身和手工测试没有区别，只是达到测试目的的一种途径，至于选择手工还是编码，无非是最优化问题中的择优而选。不是说会编码，会使用工具进行自动化测试就代表你对测试有多么深入的理解，完全不是。测试应该是一种整体的思想。
   之前和头达成一种共识：测试需要的知识面太广了。以前的时候总是认为做技术要先深再广，意思就是先揪着一门技术深入学习，然后以此为契机学习周边知识，最后形成面。历经了三年多的工作经验，现在觉得真正的所谓技术没有多少，还都是我们在大学中就需要掌握的那些基本的计算机常识：数据结构，计算机组成原理，汇编，编译原理等等，而后的都是工程应用。
   就如同最近在学习《深入理解计算机系统》，可能我们认为的数据来源，以I/O来区别包括鼠标，键盘，网卡等等设备，当这些数据到达计算机中，在总线中传输的都是二进制代码。而我们在socket处理时，也会明白，所谓的socket无非也是进程间通信的一种方式，和利用文本，共享内存都进程通讯方式一样。从这个角度思考，也会明白为什么我们在处理socket流时候非常类似文本操作了。
   伴随着学习的东西越来越多，感觉到自己会的越来越少。然后，更多的感觉还是，测试的途径不重要，重要的是明白如何能够达成测试目的，并且如果在多种选择的情况下，如何选择最有效的一种方式。