概述

　　进入软件测试行业已经5年多了，慢慢的也形成了一套自己对测试的理解与观点。并且，发现是与大众不同的。看到周围的人进行的测试工作，包括测试用例的编写，自动化的设计与实现，Bug的寻找与分析，对一个feature整体测试的掌控，等等都有很多的欠缺与不足，因此想把自己的测试理论写下来与大家共享。

　　本来想用Agile Testing这个名称来阐述我所形成的测试理论的，但是发现这个词已经被占用了，而且和我所谈的并不是一个内容，因此就用了Smart Testing这个新词。

　　所谓Smart Testing就是利用一切可能的技术与测试方法，最简单，最快速，最灵活和最高效进行测试以及解决其中发生的各种问题，从而使得在有限的时间里可以test coverage最大化，发现更多更深入的bugs，以及解决更多更难的问题.

　　如何才能使得testing smart是因人而异的，取决于测试人员的水平。而在不同的level，smart的概念也不尽相同。而随着水平的上升以及测试经验的增强，测试人员不应该停滞不前，而应该持续提高，使得测试工作smarter and smarter。

　　而如何才能做到smarter其中一个很重要的因素在与测试人员掌握计算机技术和软件测试方法的多少以及熟练程度。比如，一个人只会一个自动化工具，只会一种脚本语言，他基本没有其他的选择，怎么能保证自己的工作smart呢？

　　我在这几年的测试过程中形成了一些零零散散的经验总结可以使得我在未来的测试中少犯错误，少花不必要的时间，更准确地说是更加合理地利用时间，从而在每天8个小时的工作时间里可以进行更多，更重要的工作。而这些经验是很难用言语来解释清楚的，尤其是对于那些新手们，没有过实际体会是不可能理解的。因此，我的做法就是如果不相信我就让他们自己去体会吧。这些东西是有些微妙的，很难解释清楚，因此我会结合一些实际例子来讲解，希望大家能够明白。比如，这里讲一个例子。我的测试观点之一就是自动化测试的快速开发，我不讲究代码好看，而更看重实际效果。这是由于测试的性质所决定的，我们开发的自动化程序并不是实际产品，没有必要在软件架构，编码技巧，bug-free等等地方花时间，下工夫。因为一旦产品有所变动，你修改测试代码的工程量可能就是巨大的。作为自动化测试工程师，我周围有些人几乎把所以的时间都投入到自动化的开发当中，而我本人自动化的时间也就是10%，剩下的时间我可以去做更重要的工作，比如code review， debugging， 测试相关模块，等等。前不久和一个欧洲小伙子合作一个项目，这个小伙子编码很厉害，C#，VS都很熟，可以说精通，上学期间世界各地参加编程大赛。可是我看他做测试就还不算smart，因为他是用开发人员的观点去写自动化测试。这个项目分两部分，server端，和client端，我让他负责server端，而我负责client端。我估计的时间是两端各一个星期，而我其实只用了两天的时间就完成了client端的自动化程序。而他则是把server端的自动化当成了一个软件产品来开发，考虑了很多诸如软件结构抽象化，软件功能的强大，完善，debug信息，event log，各种异常的处理等等，最后花了两个月才完成。我必须承认他确实是一个很优秀的程序员，但是缺乏必要的测试经验。我在他花费在自动化的这两个月的时间里把我们组所以的feature（一共4个，我们俩负责1个）进行了code review，把所有scenarios手动测试了一遍，发现了大量bug，进行了大量的debugging，并且进行了一定reliability， security， performance test。现在即使不是我own的模块的PM，Dev，Test有事也要来找我，而且这些我都已经做完了，他还在一个模块的自动化中呢。

　　这个例子在一定程度上表达了我的测试观点，也解释了开发与测试工作的不同之处，今后我会用更多的例子讲解如果进行Smart testing。