软件工程中有很多新的工具，但我们往往发现叫好不叫座，而原因往往也是使用中国的一句古话就是：具体问题具体分析。但是回过头来分析一下，其实很多具体问题都是可以有办法解决的。将这些总结贡献出来，希望我们中国的软件技术走得更快点。
您目前的位置 >>
首页 >>最新经验
一开始，我们是可能只有一两个人编写测试脚本，而且还可能两人商量着、研究着，因此开始时候，协同的需求并没有那么紧急。但随着脚本工程慢慢扩大，而两个人已经开始分工，各自负责各自的代码。协同一下子变成最最麻烦的事。
对于Ruby，我计划是作为一个测试步骤（TestStep）加入到原有脚本中。这样既不会丢掉原有脚本编辑的优势，又同时拥有了强大扩展能力。如果DSL实现了，那么编程就会变得更加简单。Ruby脚本的易用性，是经过众多网友验证的。
日志是脚本在运行过程中记录下来的信息。对于测试来讲，这些脚本中的错误信息是他们非常需要的。最好的情况是，测试错误能自动发送到相关模块的编码负责人手里，只不过由于这点往往需要和开发管理系统相连接，因此暂时不考虑。
分析日志更是重要，事实上，没有日志的自动化测试没有人愿意去做。目前还是先根据一些简单的需求，做了一些统计，相信以后还会增加的功能是版本日志对比。这样可以看到系统的稳定性变化趋势。
在重构过程中，对新的方法编写测试用例更加有效。因为重构往往是在时间紧急的情况下进行的，所犯错误可能比初期编码阶段更容易。这个阶段，旧的单元测试代码和新的单元测试代码能够很好提升系统的稳定性。
对于自动化测试框架来说，只需要随意作为一个Dll，并注入到原系统中就可以了。如果原系统提供了注入的扩展，那是最好。因为这样调试起来很方便。否则就做成远程注入，不过调试的时候只能Attach了，很麻烦。
判断控件的可见性是非常简单的。但是对于真正不可见的控件的实现，遇到了很多问题，也曾经考虑过绕过去，但是最终我们还是确定，这是一个非常好的原则，必须坚持下去，它将大大改善编写测试代码的简单性和可读性。
最近在考虑自动化测试框架的时候，发现原来的想法，虽然解决了定位及访问控件的困难。但是，用例代码却因此对程序实现细节有了很强的依赖。这些依赖可能对用例代码的开发带来一些困惑。
从技术上讲，本篇博客只适合了解VCL的Delphi程序员阅读。但其间的思想，相信大家都可以借鉴。下面我的描述过程，是以我的探索过程来进行讲述的。中间会带出相关技术点，供大家参考。
我们在做软件的时候，想到的是如何满足需求。要考虑如何超出其需求，确实比较难。因为这和正常工作是不一样的。联想起Windows XP，其实超强的用户体验，一定是可以让客户有Surprise的感觉的。超酷的界面、超酷的动画、超酷的自动化！
做任何事，要牢记你的用户是谁！设计一个框架，要知道你的用户的使用需求是什么，这样，框架设计才可能容易被接受，离成功也就越进一步了。在设计初期，就考虑将控件的访问封装起来。对于测试人员来说，所有的控件都已经封装好了，他们只需要调用就可以了。
消息机制和流程代码的冲突，是根本原因，简单的模型，就是循环嵌套循环问题，使用钩子，在循环开始处，触发任务。
测试框架有多种方式：第一、最典型的就是消息驱动，自动化工具通过脚本录制和编写，保存为测试脚本。第二、嵌入式，TestComplete就是这类工具。第三种方式：一体式，这种方式中，通过给程序在打包的过程中，添加额外的框架代码，是的程序自动提供控件的访问方式
软件工程的目的是为了解决问题。真正解决问题的重点，是找到一条适合自己发展的方法论。在软件设计中，如果我们总是在讲哲学，相信一定不会有《设计模式》这么经典的书面世。敏捷开发方式也不会提出。而我们也正是应该总结我们工作的方式方法并加以提升的时候啊
选择重构的心理，应该和我们程序员的追求完美的个性非常相关。软件不断的进行重构，那么软件的质量就能越好。最关键的是，我们越来越将代码修改得让自己感觉没有遗憾。请允许我这样来分析重构者的心理，但是你不得不承认，往往决定一件事的时候，潜意识很容易战胜理智。
来回扯动会让对方在过程中，暴露出空档。只要你能够抓住机会，就会容易抓住主动权。做软件也是如此，但是这很难讲清楚。简单一点，先做起来，然后在做的过程中发现用户的潜在需求。如先给用户做一些简单的应用。先让用户按照他的业务走起来，然后分析其中有意义之处……
首先你不是CIO，这是现状。但是要做好企业信息化，做不到CIO的高度，就如很多朋友说的那样，必然会遇到很多问题。所以，在接受这个任务的同时，我就对自己说，就当你自己是CIO吧。另外，在认为是CIO的同时，我也应该时刻提醒自己，不再是谁人不怕的技术高手了。
所谓酷的东东往往让人迷失方向，信息化容易失败的真正的问题在于，没有了解清楚公司的现状。我们最初的状态其实是“不知道有”，但却潜意识里认为是“知道没有”。信息化建设还很漫长，但我们一定可以战胜一切困难的。