ohmyjava

摘要：在写这个自动化测试框架的时候，我一直在留意各方面的需求。毕竟，我本人并没有做过真正的自动化测试。管理测试方面的领导，提出一个需求，就是在用例运行失败的时候，应该将过程记录下来，并形成报告，Email给相关人员。个人认为这个需求是非常合理的。事实上，任何系统，如果没有输出，那么只能停留在程序员手里。有了报表，才叫真正解决了用户的目标需求。在分析这个需求的过程，我提出了针对每一个操作接口的每一个方法，进行Log。而完成这个工作的第一方法，就想到了AOP，也就是Hook技术的应用。因为Delphi下面并没有对AOP的直接支持，所以考虑这个实现，变成了一个技术研究过程。从技术上讲，本篇博客只适合了解V 阅读全文

摘要：今日将框架完整走通，给测试试用。但从测试表情看，显然没有Surprise的意思，反而有种因为改变使用习惯并要学习新框架的厌烦。尽管事前，我们已经对需求做过自认为相当全面的分析，而且在框架设计上也充分进行了斟酌和权衡。但是，结果就是这样的。当然了，分析这个原因的前提，在于我对自己的要求还是挺高的。期望也是挺高的。那么，原因到底在什么地方了？人如何才会Surprise呢？惊奇，从字面上讲，就是超出其期望。我们在做软件的时候，想到的是如何满足需求。要考虑如何超出其需求，确实比较难。因为这和正常工作是不一样的。联想起Windows XP，其实超强的用户体验，一定是可以让客户有Surprise的感觉的。 阅读全文

摘要：做任何事，要牢记你的用户是谁！设计一个框架，要知道你的用户的使用需求是什么，这样，框架设计才可能容易被接受，离成功也就越进一步了。框架的用户是测试人员。测试人员的特点是： 熟悉或精通业务 了解程序元素，但不了解程序结构 实现细节更是难以洞察 因此，在设计初期，就考虑将控件的访问封装起来。对于测试人员来说，所有的控件都已经封装好了，他们只需要调用就可以了。这一点，应该已经初步解决问题了。但是我们并没有满足这一点。对于测试来讲，他们了解的是业务元素，而我们常规做法，是把控件封装成编程元素。这是不一样的。举个例子：我们在界面编程的时候，命名一个按钮控件，叫btnOk，标题是“确定”。对于程序员来说， 阅读全文

摘要：前面讲到要做一体化自动化测试框架，那么，最重要的是要解决什么呢？相信了解Windows编程的人员，都能发现这个问题所在。在窗体中，写下代码，控制每一个控件的输入是非常简单的事。但是，一旦显示了一个模态窗体，原有的流程代码会不再往下执行，而是停留在新窗体中，等待消息相应。这就是我们代码控制界面的关键问题。这是什么道理呢？我使用的是Delphi系统，所以我可能使用VCL框架来解释这个问题。但是其他语言同样适用。在Windows程序中，WinMain是入口。而WinMain的处理，就是一个典型的死循环，先从消息队列中取出消息，然后再给各窗体派发消息。为了方便理解，我们将这个模型简化，就是一个死循环A 阅读全文

摘要：这段时间一直在为公司内部开发自动化测试框架，简称GTF。这些代码都是公司的财产，不方便共享。当然了，如果公司愿意，我倒愿意开源了。不说这些了，因为这个框架现在还属于开发阶段，很多事都是言之过早。最近几个博文中，我会持续将我在架构过程中的想法写下来。供自己和大家一起分享。这些想法，并不属于我一个人，我工作中的同事们给了我很大的帮助。这一篇主要说明架构方面的考虑。在现有的提供自动化测试解决方案的产品很多，包括：Robot，TestComplete，WinRunner等等。我只接触过这些，公司里也进行过很大的尝试，但是结果往往总是不竟如人意。这中间，排除那些人员方面的原因，也总结这些自动化工具，在使 阅读全文

摘要：自从Martin Fowler先生将Refactoring这个概念带到了中国，许多程序员都如同获得了一个通行金牌似的，随时可能提起"Bad Smell"和"重构"。从我的心里来讲，我并不反对重构。但我反对不考虑项目情况的盲目重构。回想一下，当我们在考虑系统需要重构的时候，我们都考虑了那些因素？特别是大范围的系统级别的重构。由于小型重构涉及面较小，所以下面的很多原因都是针对大型重构进行论述的。"Bad Smell"也许是我们第一个说出的原因。讲起这个，我仿佛就听到有无限个非常有道理的理由，能从重构者嘴里说出。其中最经常的理由就是：现在不 阅读全文

摘要：[原文地址：关于逻辑学的文章zz ]正如充满正义感的人无法容忍犯罪的发生，富于美感的人不能包容丑陋和瑕疵一样，一个逻辑严谨的人是没办法忍受哪怕一点点逻辑漏洞的存在的。几天前的一篇帖子，招来了一堆自以为是的人，也逼得在mop潜水多日的我头一次发贴，来堂堂正正地批驳那道存在严重漏洞的推理题，给所有不了解逻辑的人上一堂浅显的逻辑课。这是我第一次写这种类似科普的文章，如有名词解释、用法上不适当的地方，谨请指正。后面的内容安排如下： 第一章，介绍事件的起因，概述问题和错误的观点。 第二章，用最基本的思维方法和通俗的语言驳斥题目的漏洞。即便你以前对逻辑一无所知，相信看了之后这一章，也会明白漏洞的所在。 第 阅读全文

摘要：今日号召同事们打星际的时候，发现现在年轻人会打星际的已经不多了。而我却被他们嘲笑落伍，因为现在是魔兽的时代。还说某某已经开始转变。我固执地说，我不会轻易改变的！ 而现在，2007年5月19日下午，我再也不要为这个问题困扰了。Blizzard公司已经公布最新的游戏：StarCraftII。详情请访问：http://www.blizzard.com或者http://www.starcraft2.com。 按照Blizzard的介绍，在StarCraftII中，并没有增加新的种族，知识增加了新的单位，另外，最重要的是使用3D引擎渲染游戏。 呵呵，显然，Blizzard没有让我们这些老玩家失望，更没有 阅读全文

摘要：在昨日写《小谈子对象中接口的设计原则》这篇博文的时候，突然想到三个和尚没水喝的故事，想来特有意思。故再次拿出来说明一下。一个和尚挑水喝，两个和尚抬水喝，三个和尚没水喝。这个寓言故事是大家都非常熟悉的。但是，我想问一下，多个和尚真的不好吗？如果真的不能太多，那么多少个和尚最合适了？其实我拿出来的原因之一，大多是因为我自己的缺点所在。我自己是一个绝对的技术人员，因此，我有着技术人员都可能拥有的弊病。解决问题的潜意识中，总是希望隔离系统和周围的联系。我非常擅长处理独立复杂的系统。但是，很显然，我潜意识中总是避免处理联系。所以，三个和尚的故事对我来说是合适的。可是，如果我不再这样了呢？如果是一个擅长管 阅读全文

摘要：不想说，但是事实就是如此，这年头赚钱，绝对不要赚那些老大的钱。否则，即使是拿到了口袋，转眼又会掏出去，可能还得赔钱。目前的PPLive境况也许就是如此。转播CCTV？转播盗版硬碟？要知道这些老大们，就怕没有人来买单。只要你做大了，你就逃不了了。相反，真正最好的方向，也许就是赚我们这些老百姓的钱了（我不愿意，但是必须承认这是真理！）。一人赚个10元钱，1000万个人，就是1个亿。往往市场都不需要开拓，这些渠道早就被垄断行业开通好了。前一段时间的短信行业，聊天、海选、资信等等什么的，就是赚这种钱。这当中，让我们最头疼的就是“包月”，还没明白，人家就扣了你一个月的钱，赶紧退了包月吧，这个月的费用算是 阅读全文

摘要：我原本并不想单独发以下JCL的方法，可是想到很多人可能还是不知道的。另外，从我博客的回复上看，很多人也愿意去了解一下，特此贴出JCL中的代码。//===Interfaceinformation==================================================functionGetImplementorOfInterface(constI:IInterface):TObject;...{TODO-cDOC:OriginalcodebyHallvardVassbotn}...{TODO-cTesting:Checktheimplemetationforanyfur 阅读全文

摘要：这几天一直没什么写博客的动力，今天上来，发现发现访问量终于超过200,000了。听说企业产值的规律是1，2，5，10。相信我的博客也终于突破一个里程碑了。自贺一把！作为祝贺，嗯，还要请那些身边一直支持我的朋友们。当然了，网上的朋友不能请到饭，就邀请大家继续多多支持我了。哈哈，发现这篇博客完全是废话，没什么可说的。哈哈... 阅读全文

摘要：今天和同事在讨论接口的设计原则的时候，总结了一个原则点。虽然简单，也拿出来和大家一起分享。问题对象在实现接口的同时，由于需要提供访问子接口的服务。最正常的设计可能是下面的。但是，如果是另外一个情况呢？看看下面的组合方式吧：小析事情变得有点有趣了。往往就是这样，只有一个的时候，没有人会怀疑。只有出现多个的时候，争吵才开始了。所谓一个和尚挑水喝，两个和尚抬水喝，三个和尚没水喝。要我看来，一个和尚是多么的孤独？三个和尚虽然没水喝，可是有得吵闹，岂不是正得设计的乐趣？初步看起来，这两种设计中，第二种有着明显的不合理。因为这样，层次就变得混乱。而且父对象若是要越过子接口，访问一些实现上的细节，那么就更加 阅读全文

摘要：这几天一直都在思考新项目中，如何促使公司能够最终真正使用上单元测试。前几天发的一篇《单元测试之关键问题解答 》主要写的是我在实践过程中，针对我遇到的一些非技术问题的思考。后来我看到一篇和我博文一样标题的文章《单元测试之关键问题解答》。拜读了之后，发现他对我的思考方向有些误解。虽然这样，因为这些导致他的失望，我还是表示十分的道歉。补充一下，这篇文章不错，推荐大家阅读一下。前几天和我的微软同学聊起微软的自动化测试的时候，他向我提到了几个概念BVT(Build Verification Test)和Smoke Test，这让我注意到一个问题，TDD中并没有解决好复杂系统的全面测试问题。要知道大多数人 阅读全文

摘要：[本文章转自http://www.chinapmclub.com/forums/8172/ShowPost.aspx，作者是微软(Jeff Wang)王志峰。只是网络上的版本大多没有进行排版。这里做了一个简单的排版，并向所有人推荐这篇文章] 这里的“技术”指的是具体的战术问题，比如说如何使用某种工具来解决某一特定测试问题，或者某一类型软件有哪些测试手段等等。而这里的“方法”指的是宏观的战略问题，或者叫方法论，这包括从软件测试的概念或理念，到企业软件质量控制体系；从软件测试的过程，到测试团队的设置及其职责的界定等等。 作为测试人员，热衷于“技术”讨论和交流是一件可喜可贺的事。从中可以感觉到软件测 阅读全文