软件测试技术的发展方向

　　这个标题有点大，小标题是“测试团队技术能做到的最高境界”或者是“测试技术可以往哪些方向发展”，一家之言。

　　个人感觉可以往两个方向：

　　一个是，一切工具化(Automate Everything)，包括把测试用例自动化，把流程自动化，开发各种各样的工具来提高研发的效率，避免做重复的手动的事情(这些事情比较容易出错)，目的是， 让开发专注做开发，其他事情测试来做;

　　那对人的要求就是，快速开发的能力，洞察力，不断发现问题，分析问题，解决问题的能力(也就是流程改善的能力)，所谓快速开发的能力，就是比如开发人员在开发新功能的时候，测试可以接入然后很快开发出一系列的检查工具帮助开发避免回归的问题;就比如医生在诊断的时候需要的一切工具，体温计，血压计，心电图等等;

　　对研发而言，这些工具包括代码覆盖工具，分析代码改动的工具，代码版本管理，代码风险分析，bug管理，bug数据挖掘，软件模块依赖分析等等。

　　举些例子，关于开发一些工具来提高研发的效率;

　　比如我自己的机器上部署了Nginx还有Php，每次要做一些Php相关的开发或者测试的时候需要把2个程序都打开，以前是手动了一个一个打开，后来想想写个脚本，一键搞定：

　　start "dd" /d "d:\Download\nginx-1.0.11" nginx.exe

　　timeout 20

　　echo "nginx is started"

　　timeout 5

　　start "" "d:\Program Files\PHP\php-cgi.exe" -b localhost:9000

　　echo "php is started"

　　测试某些软件的时候，需要配置环境，比如代理服务，host信息等等，可以把这些动作都自动化，让所有的人“一键点击”即可部署测试环境。

　　其实人是有惰性的，如果想让团队里面的人(开发，项目经理，产品经理，UI/UA工程师)参与测试，一个办法就是让测试变得很容易，一键点击即可完成。

　　再比如周报或者日报，可以开发一些web系统方便团队成员写周报或者日报，然后聚集成团队的周报或者日报

　　还有就是BVT(basic verification Test)把一些API的测试，简单的冒烟测试写成一个bat文件，开发在checkin之前很快的跑一下，没有问题即可checkin。

　　把重复的事情自动化，把需要2步或者3步做的事情一步做完，即可提高研发的效率。

　　另外一个是，软件测试架构师，专业化(变成Expert)，比如你一直测试搜索引擎，那么你很清楚搜索引擎的原理，你发现过各种各样的bug，你甚至可以指导比较junior的开发人员，开发设计新功能的时候需要邀请你，因为你知道各种各样的问题，你可以在设计review的时候提出有价值的意见;在这个层面上，测试软件架构师和开发架构师无异;

　　那对人的要求就是，要有很高的读代码的skill，能够读懂别人的代码，可以做code review，可以了解底层的运作;有很高的debug skill，发现问题的时候可以去root cause，从而从系统的角度上知道如何在将来比去避免这些bug，有很强的bug prevention skill;有很强的coding skill。

　　举个例子，关于如何去做review的：

　　比如我要写个Android上面的记事本，可以把数据传输到云上，也可以下载下来，但是不一定很频繁;不需要实时同步;这样我如果换手机就可以把数据下载下来，避免数据的丢失，或者迁移的麻烦;

　　这些功能一旦确定下来以后，要思考的事情是，放到哪个云上(快盘，微盘还是Dropbox等等)，怎么放(文件传输的方法，用Http，还是Email，还是ftp，或者自己写Socket);有哪些现成的API可以用，比如Java的httpclient的Jar包可以使用，有哪些需要自己写，比如文件上传过程需要把文件读出来编程Java Stream，需要研究哪些技术，文件上传的Http　Post方法等等;由于访问的安全性问题，都使用了OpenID，那我需要研究一下OpenID(oAuth)如何使用等等;

　　测试架构师可以思考这个软件的work flow是怎么样的，data flow是怎么样的，数据要存储在哪里， 有可能有哪些漏洞，比如上面说的产品，需要考虑网络的情况(GPRS，Wifi)和文件大小因为需要和服务器端通讯，还有安全的问题，比如需要考虑如何去获取secret key，会不会过期，过期后怎么办? 文件传输是否支持多线程，性能如何;文件下载到本地的时候，如果程序在运行，那么如何替换掉已经load到内存的数据，还是说先要关闭程序? 等等。

　　这些问题可以在设计的时候就提出，而不是等binary出来，然后去测试，然后再发现问题。测试架构师可以通过自己写一些Demo来了解上面这些技术是如何work的。

　　当架构师去review开发人员的code的时候，可以先大概了解整个软件的架构，哪些模块是负责处理什么的，不需要深入到API的细节; 等了解到哪些是关键的路径，比如如何获取secret key，然后再深入去了解这段API。 之前有些文章提到API的参数处理，其实这里面不需要过多的关注，特别是Java和.Net的程序，因为这里面有的类型判断，所以一个处理String参数的API不可能去接受一个Int型的参数，编译的时候就无法通过。 碰到自己不熟悉的API，最好的方法，一个是Google一下，另外就是自己写个简单的程序用一下这个API就豁然开朗。

　　另外一个是，多从开发的角度其思考问题，最好有空就自己去写一些实用的程序。 思考程序是如何设计的。比如思考一下以下的问题(这些问题摘选自http://coolshell.cn/articles/7048.html)

　　1)网上短网址服务，你有想过这个短网址生成的算法是什么，如何能做到能最短?怎么查询?你也许觉得会用key-value的NoSQL。那么，如果对于同一个URL，如果要重用已生成的短网址，你怎么用key-value的NoSQL来解决?

　　英汉词典的检索和这个很相似，如果通过英文查汉语，又通过汉语查英文?如果是N多种语言的互相翻译呢?你的数据存储和检索如何做呢?

　　2)当我看到Dropbox这样的云同步的软件的时候，我不知道你是否会和我一样会去思考，在多个设备间的文件同步是怎么做的?如果网盘上有几万， 甚至几百万个文件，当要和我的本地数据同步时，他如何比较经济地知道哪些文件更改了?需要向服务端同步或是向客户端同步。更进一步，你有没有想过没有中心 结点的文件同步问题?你有没有想过，文件冲突的问题?

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