Smart Testing （2）- 编程语言

cleverman

进入软件测试行业已经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。

http://peking2toronto.spaces.live.com/default.aspx

[ 本帖最后由 cleverman 于 2010-3-5 10:50 编辑 ]

愚人

呵呵，又看到clever兄的文章了，学习了……期待更多……

liangshi

可以考虑让这位优秀的程序员去做开发，要人尽其才么。他考虑了很多可测试性、可调试性的问题，开发出来的软件相信测试者会比较喜欢。

如果他要做一段时间的测试开发者，不妨让他做一些基础的工作，例如开发测试工具、测试基础库或框架。聪明人都很喜欢写程序，喜欢自己造轮子。在某种程度上，也是好事。你比他有经验，自然可以分配一些适合他的工作，让他充分发挥。

Code Review应该拉上他。他对代码很了解，可以提供好的建议，也许可以让其他人学到好的设计或惯用法。

oac

做开发的一定要注重需求，光会写代码很难满足用户的需求，这里的用户也就是项目内的测试人员了，过犹不及。做自动化的一个很重要的目的就是节省人力成本，如果你做自动化的成本比手工要高，我觉得老板肯定不太满意。

[ 本帖最后由 oac 于 2010-3-4 09:58 编辑 ]

smz_198181

战略和战术的问题 呵呵

cleverman

正好有网友说到应该让这位测试人员去做开发或者code review，我就谈谈我对编程语言的理解。还看到一些网友对我的观点有疑议，这也就是我说的要自己亲自体会才能明白的。当然每个人的体验不尽相同，但是很多细微的东西我还是没有解释的，比如老板的心理，visibility, promotion等等。具体怎么做还是应该是灵活的， 总之是要付出同样的时间和精力能够获取更大的好处，更大的好处也并不是仅仅包括测试工作本身，是多方面的。当然我向来都是提倡把这些东西结合在一起的。
现在说说编程语言。可惜的是，这个测试人员据我所知只精通一门编程语言，而我们产品所用的是一门不同的语言，所以他很难转成开发或者进行code review。至少当前的阶段不行。因此在碰到问题的时候，我通常是通过debugging和code review来找到root cause, 就报bug了，而他则不得以要找开发人员来解决，又要repro，又要提供log，等等。尤其是跨team，跨模块的时候就非常辛苦了。因此，我的观点是，对于一个测试人员来说，精通一门语言很重要，但是更重要的是通晓各种语言。这也就是我前边提过的一个问题，你只会一门语言，怎么能smart testing呢？你都没有选择的可能。我刚来公司的时候跟一个C语言高手合作过，发现他竟然在工作中要用到VBScript，Windows Shell这些我不屑使用的脚本语言，而且他还说这些语言很好用，当时就觉得不可思议。现在慢慢的我也明白了，每种语言都自然有它的好处，不可能有一种语言什么都能做，而你懂得更多的语言则可以使你在工作中有更多的选择，从能能够更smart的去工作。
我一直也在考虑过要不要转开发，而最纠结的一点是，开发一般来说只是用一种语言，而我并不喜欢任何一种语言，任何语言都有它的痛苦之处，而紧抱一种语言历史上来看也是危险的。我喜欢在测试中对语言选择的自由性，我可以在不同的情况，面对不同的问题，灵活地选用语言，或者学习新的语言。我大概统计一下我曾经用过的语言或语言工具有，Pascal, C, C++, VB, Foxpro, VC, Powerbuilder, Java, C++ builder, Perl, PHP, C#, C++/CLI, VBScript, JavaScript, Windows Shell, Silverlight, Powershell等等。而我现在自动化所用到的语言就有C,C++, C++/CLI, C#, Windows Shell, Powershell等等，我会根据不同的情况来选用不同的语言去实现。
还有一点很重要的能力就是你用多长时间可以上手一门新语言。我们通常需要学习新的语言去完成某项工作，而完成这项工作未必要精通这门语言，你用多久的学习时间可以完成呢?我学习VC花费了半年的时间，那个时候是在大学里，资料很少，市面上就两本书。VC之后的其他语言的学习没有超过一天的，一般是几个小时，而最近学习的Powershell大概不到半个小时的时间。
因此，作为一个测试人员对编程语言的选择和使用有两点很重要。一是快速掌握一门新语言的能力，二是尽量通晓多门语言。这样才能更好的进行smart testing。

http://peking2toronto.spaces.live.com/default.aspx

[ 本帖最后由 cleverman 于 2010-3-5 10:50 编辑 ]

liangshi

许多开发者已经开始考虑多语言开发。
http://images.china-pub.com/ebook195001-200000/196006/ch05.pdf
http://images.china-pub.com/ebook190001-195000/192175/ch14.pdf
在一些大型团队中，考虑到协作性、可维护性，还是会选取一门主流语言，如Java，C#。即便如此，考虑到Java和.NET平台上的动态语言、函数式语言越来越多，在局部引入新语言的可能性也不低。

测试者多掌握几门语言是有好处的。我推荐学一些动态语言，开发效率高。在Windows平台上PowerShell就很好。

muyang327

看了真受益,谢谢分享你的经验.

park_p

克莱沃曼～～
果然高～～
学好技术固然高，但是能活学活用，才是真的高～～
没有最高，只有更高～～
顶～～

lgr36

不错，支持

dillgates

写得非常好！感谢分享！

key4

前面看了半天，有点晕。。
到了欧洲小伙的例子后主题才明晰了起来。
确实有些东西还需要我们固化沉淀下来，，然后再讲解给自己的团队明白。。。