探索式测试实践之路速读感

　　本来打算写了这篇读后感提交参与博客活动的，但是想了下，自己工作经验不足，测试经验更是不行。所以不打算拿出去“卖了”，唉。自己感慨感慨下.

　　这边书基本都是说的探索式测试，什么是探索式测试，我看完之后的理解的就是一边测试一边修改测试方案，有一个雏形到一个完美的测试方案的测试方法。其实就类似“在黑暗中摸索前进”，过程中不断学习和改进，想想猿人，能够如此的“进化”，说不定人真是由此而来。

　　上面都是理论的，而且是空洞的，因此都是“废话”，其实，我们读大学也知道，很多选修课都是一大堆理论，我们学习完了，不知道如何运用，因此我们很”迷茫“。其实理论的东西还是有用的。

　　记得大学的时候，有一门课程就是软件测试，当时写软件测试结课报告，用到了一个.jar的测试工具，能够根据参数绘制出曲线，具体记不太清了。当时根本不知道所谓的软件测试到底有什么用呢?接着写了个等腰三角形的测试用例，就是一个大表格，然后把所有可能的情况，主要是边界值和极限情况全部列举了一遍，然后根据程序输入，最后判断情况。当时用的是c语言，所以在console下输入的。当时的知识太少，不然可以利用脚本或者批处理文件来做，这样省去了很多事情。如果你把程序写的够完美的话，可以定义一大堆出错宏定义，每个值表示不同的情况，利用日志的方式将所有的出错的返回的出错宏去得到你自己定义的bug结果。而上面提到的脚本的方式，我只是知道简单的利用脚本，从输入出发，利用脚本得到输出，也就是所谓的黑盒测试。输入->输出。

　　这些好像和探索式测试读后感没什么关系哈!其实还是有的。我们写好了测试案例，以文档的方式，然后逐个进行测试，把测试结果记录到文档里面，最终提交bug，提交测试文档。很多公司大体上都是这样的，至少我之前呆过的公司是这样的。专门有个文档记录bug，如果没有就不提交。这点我不太看好，我认为测试的所有的结果都应该记录到测试用例文档中。这样便于我们根据情况进行改进和完善测试方案。而探索式测试之路这篇文档，里面提到的这种测试方法的结构图解，我不是很理解，我没做过测试，呵呵呵。不过我觉得书中提到的基本上都是以一种文字方案的方法去执行测试，考虑各种情况。比如对于产品我们处理测试产品是否没有很大问题，然后是否运行顺畅之外，我们还需要考虑产品的用户体验，实用性，美观性等等。如果比较严格的话，我们还可以根据产品的市场价值进行评估测试，这些就需要产品测试经理的丰富经验了。而如果对于给公司部门做小插件的时候，我们考虑的更多的是代码的质量，效率和接口的封装性，其中质量是最重要的，直接影响效率。当然其实质量就包括了效率，封装性，逻辑结构等等。

　　文章中我看的比较多的就是关于淘宝的测试案例：支付宝大家都清楚，完成了开发，很重要的就好似测试了，尤其是这种涉及到bank的交易，任意的bug都可能导致意想不到的不良后果。因此要求具有很高的安全性(操作错误了钱不会无缘丢失，不会轻易被黑客侵入等等)。网页很重的就是用户输入的合法性检查，以及密码的安全性，交易过程中的安全性，不正当操作的容错性等等。诸多情况都要求我们的测试任意要能够想到，制定完善的测试方案，并且不断改进。相信你进入公司后，你参与开发软件或者其他产品，你的测试人员会经常和你打交道，时间久了，你自然就会以测试人员的角度去进行开发，当然你不可能完全考虑到，因为你的经历不再测试上面，所以还是需要靠测试人员，而且越专业越好。

　　好的产品需要经的起任意“玩弄”，书中提到的反复执行同一个操作，目的就是为了看你的产品够不够“硬”，这点我觉得挺好。记得曾经在沈阳参加招聘会的时候，“京东商城”的人员提到了他们的依次活动由于某段时刻突然访问量增大，然后服务器无法“抗压”就崩溃了，不过得到了及时解决。看来这些东西确实要“够硬”才行。你是根据文档也好还是利用脚本或者工具也好都需要认真的实施...当然这其中其实要求我们的开发人员能够提高自身的技能，尽量考虑全面，这才是“王道”，为什么国外的软件很多都很好，从数据上表面：国外的测试投入量远远大于开发，而国内真好相反，不过也没办法，国内讲究的是敏捷开发，I think!

　　我算是也接触过一些测试，主要就是不断的输入各种情况，然后根据数据库进行对比，看是否正确，我基本上花了一个星期去修改和测试，反复的做。说实话，开发其实很早就完了，就光测试和修改就花了两个星期，而且下班后还在思考，唉，都快成“精神病”了，嘻嘻。原因就是我开发的这块功能是网页的，然后本身逻辑比较麻烦，又考虑到要做窗体版的，因此又必须修改代码，让其适应两套方案，当时头都大了。到现在都记忆犹新啊!后来离开了....原因挺多的，但是不是背叛....去的那段时间，锻炼了文档的编写，业务的学习...测试???

　　其实我认为的测试方法：测试文档+性能，测试文档就如探索式测试一书所描述的方法，根据不同具体情况进行测试方案策划，其次我觉得应该考虑性能，软件可能没那么重要，但是软件的反应速度，任何需求模块的性能都要纳入，整体响应时间都需要考虑，并且根据方案提高性能。对于硬件来说就更重要了，专业的测试才可以的。不然你的硬件都不行，其他“甭谈”!

　　我目前听过的测试方法比较“牛”的是一家“芬兰”的公司，名字就不说了，他们公司在芬兰很老牌了，而且公司本身实力不过，给芬兰做了很多高质量的软件。他们公司的氛围是“每天按照安排完成就好了，不要太快”，在北京的分部每天下午都要开会，因此你就知道开发的时间不是很多，但是能够在特定时间内完成，他们不赶进度，可以想象，代码质量不会很低。这只是文化，最牛的在后面...

　　公司有自己的一套自动化测试系统，而且还在完善中，玩Linux的人知道git吧，我们一般开发完后都需要和其他人合并项目。该公司的系统会定时扫描提交的代码，进行检查，然后自动化编译。如果你的变量命名或者函数命名不符合自动化测试系统的话就会在网页上显示本次测试的结果，不同颜色表面不同情况，然后根据具体情况去修改。我觉得太powerfull了，我特别崇拜这种系统。至少代码质量特好，编译器搬强大的功能。羡慕归羡慕，其实我们需要做的是写好代码，技术第一。

原文转自：http://www.ltesting.net