展望软件测试技术的发展方向(2)

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

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

　　另外一个是，多从开发的角度其思考问题，最好有空就自己去写一些实用的程序。思考程序是如何设计的。

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

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

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

　　3)我们的新员工入职的时候，有一些公司会给新员工的帐号生成一个随机口令，然后新员工可以在登录后修改口令(我一直在想我们的银行应该为用户 生成 一个随机口令，而不是设置一个6个0或是6个8的初始口令)。那么，对生成随机安全口令的算法知道怎么做吗?如果你写出这个算法来了，你怎么证明这个算法 是足够随机，生成的密码强度足够大的?(你会发现，测试口令是否随机是否安全的程序，会比生成器更难写)

原文转自：http://www.uml.org.cn/Test/201206151.asp