克莱's profile克莱沃曼PhotosBlogListsMore  |  Tools Help |
|
August 21 2006 世界软件50强（看看你的公司排第几）Rank Company Software / Services Revenue ($Million) Software / Services Revenue Growth Corporate Revenue ($Million) Corporate Revenue Growth Services as % R&D as % of Corporate Revenue Employees Software Business Sector August 14 用一个小例子来说明手工测试，自动化测试，系统命令，编程语言，API的关系很多人理解的自动化就是把手工测试case用脚本和工具转变成自动化测试。也就是说把手工测试的每一个步骤用脚本来模拟，从而执行test case。那么自动化的所有问题就归结于，如何用工具和脚本来转化手工操作步骤了。还有很多非常senior的，但是不会coding的手工测试工程师强调case的design能力是如何如何重要，自动化相对来说不是那么重要。我这里可以肯定的说，没有好的编程功底，你也不可能涉及出非常好的test case, 自动化的开发也不应该是仅仅把手工操作用脚本来模拟，而是应该大幅度的改变test case，使得能够用最好的方式来进行自动化。那些手工测试人员所谓的设计case的重要性，和他们设计case的高水平，实际上只是在他们的知识范围之内产生的观点。下边我用一个小例子来说明，编程能力在自动化过程中起的作用到底有多大。基本上来讲，有多强的开发水平，就有多强的自动化设计，实现水平。自动化开发和产品的开发实际上都是一样的，都是有需求，你来实现。当然，不同水平的人，实现起来的效果是千差万别的。这也就是为什么开发有高手，有低手，自动化测试的开发也同样有低手，有高手。自动化测试水平没有上限，你要学会发挥自己的无穷潜力。 不多说了，现在说一下我们要自动化什么问题。我们有两个计算机帐号，A和B。我们需要用B帐号进行系统的设置，也就是测试的准备工作，然后用A帐号来进行测试。下边来说一下不同水平的人是如何进行自动化的。 1. 手工测试人员
2. 初级自动化人员（直接把手工case转成自动化）
3. 有一定经验的自动化人员（改变手工测试case以利于自动化的更简单，可靠的实现）
4. 中级自动化人员（具有更丰富的开发经验，可以用程序代替UI和系统命令）
5. 高级自动化人员（精通高级语言，精通操作系统内核）
从以上的例子可以看到，针对同一个test case，不同的测试人员，从手工到高级自动化，由于自己知识面的原因，会设计出非常不同的case出来。越高级的自动化越灵活，稳定，可靠，也更需要掌握更多的开发和内核的知识。因此，我们看到很多人在强烈的否定自动化，你先看看他到底在哪个层次中。越下边层次的自动化人员，由于技术的原因，碰到的问题会越多，能解决的问题却越少，因此对自动化的抱怨也就越大了。这些都是可以理解的，不过以此来否定自动化，我觉得还是不太应该，毕竟自己技术还不过关。 August 12 一个ＵＩ自动化的小例子随便用一个小例子来解释一下ＵＩ自动化的开发吧． 我先现在有一个Ｂｕｔｔｏｎ是ｄｉｓａｂｌｅ的状态，一旦Ｂｕｔｔｏｎ ｅｎａｂｌｅ，我们就Ｃｌｉｃｋ弹出一个窗口． 我们使用的测试工具就有同步的功能．
1．自动化工具生成的程序（发现和操作控件，不能真正运行） button=FindButton(); ClickButton(button);
2．傻瓜的自动化程序（通过加入ｓｌｅｅｐ变成可以运行的程序） button=FindButton(); Sleep(10); ClickButton(button); Sleep(10); window=FindWindow();
3．简单的自动化程序（加入同步，使得更可靠和有效率） button=FindButton(); WaitButtonEnable(button); ClickButton(button); window=WaitWindowOpen();
4．完整的自动化程序（保证１００％可靠,没有测试程序ｂｕｇ,简单写了一下，没有包含exception的控制，时间急，可能也会有错误，不过就是这个意思） Button button=null; if(button==null) if(！WaitButtonEnable(button)) Window window=null; for(i=0;window==null&i<3;i++)//ClickButton不稳定，或者没有得到open event，或者产品问题 if(window==null) 再谈UI自动化测试最近还是发现有一些文章，个人对于自动化测试报有很大的怀疑态度，本人也对相关的文章给与了驳斥。我个人和公司对自动化测试都是报有很积极的态度的。这里我想再次的写一篇文章来阐述到底UI自动化测试可以做什么，作为一个优秀的UI自动化测试工程师应该具备有什么方面的技能，以及本人对UI自动化的一些经验和体会。 首先还是要强调一点，API和command line程序都是非常适合用自动化来进行测试的。我想这个观点，即使那些反对自动化测试的人也不应该否认吧？至少我觉得他们应该有这个意识。因此，对于他们反对自动化就集中在了UI自动化方面，我这里也完全站在UI自动化测试的角度来写这篇文章，后边就不再强调了。 再次套用朋友的一句话，＂自动化测试听起来很神秘，学起来很简单，用起来很麻烦＂。我想有过自动化测试经验的人，可能大多都有这个体会吧？前边的过程我就不提了，以后主要探讨为什么用起来会麻烦和怎样简单化自动化测试。总而言之，想搞好自动化测试，还是需要测试人员比较高的技术水平，尤其是编程能力和解决问题，分析问题的能力。
首先，我要谈谈自动化测试工具和编程语言的关系。作为一个优秀的自动化测试人员，他的最基本的能力就是编程水平了。所谓编程就是至少要精通一门高级语言，比如Ｊａｖａ，Ｃ＃等等，脚本语言不计算在内。请记住，不是熟悉，是精通。高级编程语言给我们提供很强的能力来实现一些东西。你所精通的语言能力越强，你在自动化测试可以做的事情就越多，越好。简单来讲，论程序的能力来排序是这样的，测试工具－〉脚本语言－〉高级语言（Ｊａｖａ，Ｃ＃）－〉Ｃ／Ｃ＋＋－〉Ｃ＋＋／ＣＬＩ。根据这个语言能力的排序，结合你自己的语言能力，你可以想想你到底具备多少自动化测试能力。我所强调的是，如果你想优秀，你至少要精通一门高级语言，这是必不可少的。如果很多人还只是用测试工具，脚本语言工作而抱怨自动化，我要强烈的建议他们好好去学习一下编程能力先了。他们的问题在于，由于编程能力的不足，使得自动化测试的很多问题没有能力和办法去解决。再谈一下自动化测试工具，无论哪种测试工具，无论他们设计的多么强大，从编程语言来讲，他们最多能够达到脚本语言的能力。也就是说，如果你完全用测试工具来进行自动化的开发，很多问题你还是无法解决的。因此，我推荐的自动化开发方法是高级语言结合测试工具。我的自动化测试逻辑是，用测试工具只是完成ＵＩ操作，其他部分完全用高级语言来实现。我们不能否认高级语言所具有的能力，他们创造出了世界上这么多丰富多彩，这么多优秀的软件，难道开发测试程序会有问题吗？因此，我们的焦点就落在了测试工具的ＵＩ操作部分。
第二，关于测试工具。开发语言重要，选择一个合适的测试工具也同样的重要。一个灵活，强大的测试工具可以使你的自动化开发起到事半功倍的作用。结合不同的项目，不同的语言，你可能会有不同的选择。不过，这里我想解释的是，具有了高级语言的开发能力之后，我们期望测试工具来为我们做什么。我前边也说过了，我们所要求自动化测试工具所做的就是ＵＩ的操作。这里边比较重要的是三个方面，一是找到ＵＩ对象，二是操作ＵＩ对象，三是同步。如果一个工具能够让你找到所有的ＵＩ对象，并且能成功操作这些对象，就完全满足我们的自动化开发需要了。如果，工具能够提供同步的功能，就使你能够如虎添翼，不然的话要自己去实现，会麻烦不少。到了这里，你已经具有了所有ＵＩ的操作能力（测试工具提供），并且具有了高级语言的实现能力（高级语言提供），你才有了基本的能力去做一个优秀的自动化开发。没有这些能力的人，我严重怀疑能否做出好的自动化测试。
第三，怎样自动化。我的自动化的原则是，尽量少的进行ＵＩ的操作，除非是你本身要测试的ＵＩ。道理很简单，ＵＩ操作由于可能受各种问题的干扰，很容易失败。通过非ＵＩ的方法去实现是更加可靠和快速的。这也是我为什么要强调对于高级语言的精通，具有高级语言的开发能力，你就能过把大量的任务从ＵＩ操作转向了程序操作，使得你的自动化程序的可靠性大大的增强。这里还需要强调的一点能力就是系统应用的能力，比如Ｗｉｎｄｏｗｓ使用的能力。Ｗｉｎｄｏｗｓ的很多的操作是有相关的命令来实现的，不一定非得通过大家熟悉的ＵＩ。记住这个原则：除非是你要测试的ＵＩ，否则尽可能的通过高级语言来实现。我想大家对于高级语言来实现的工作应该还是有信心吧？因此，下边我要谈的内容就完全的与你要测试的界面相关了。
第四，怎样进行ＵＩ测试。首先要尽量的减少ＵＩ操作，除非是你必须要测试的操作。比如简洁快速的启动你要测试的界面，用快捷键代替鼠标操作等等。总而言之，理想状态下我们进行的每一次ＵＩ操作，都是我们需要测试的，其他操作尽量避免，不能避免用最可靠的方式去实现。那么我们现在的焦点就变成了，怎样来处理我们真正要测试的ＵＩ了。ＵＩ测试的开发基本上就三个问题：发现对象，操作对象和同步。简单解释一下同步，同步就是有一个机制告诉你何时可以执行一个ＵＩ操作。很多人是用ｓｌｅｅｐ的方式，等待一定的时间去执行下一个操作，这是我非常反对的。我的原则是，尽量少用ｓｌｅｅｐ，就算要用每次最多不要超过一秒。滥用ｓｌｅｅｐ会严重影响测试程序的性能（具体的ＵＩ自动化过程，大家可以参考我的其他文章）。
第五，ＵＩ测试错误／异常的解决和Ｄｅｂｕｇ。通过以上的解释，我们只是在自己需要测试的ＵＩ操作才进行ＵＩ操作，否则通过高级语言或者系统命令来实现。是不是我们的ＵＩ自动化就完美了呢？绝对不是，这只是一个基础，还远远没有达到完美。我们在自动化开发和应用的过程中，大部分的时间其实是花费在了异常／错误处理和Ｄｅｂｕｇ上面。这跟真正的程序开发非常的类似，你如果去看代码的话，大量的是在进行返回值得检验和异常的处理。如果我们的程序在运行过程中出了问题怎么办，或者如果没有出现我们期望的结果怎么办？一般来说有三种问题，第一是产品的问题，我们可以报ｂｕｇ了，第二是你测试程序的ｂｕｇ，你需要ｆｉｘ。第三是其他的问题，比如测试工具，甚至高级语言本身的问题，你需要ｗｏｒｋａｒｏｕｎｄ。总而言之，优秀的测试程序最终的目的是，一旦程序的运行发现了问题，就是产品的问题，就是可以报ｂｕｇ的。能够达到这种境界才能算自动化测试的完美，才能算是一个真正优秀的测试人员。（当然了，正如软件产品不可能没有ｂｕｇ，你的测试程序也不可能完全没有ｂｕｇ。但是，由于软件产品是有大量的用户来使用，而你的测试程序只是很小范围内来使用，使得你消除影响测试过程的ｂｕｇ成为完全可能）
综上所述，一个优秀的自动化测试工程师必须要具备高级语言的开发能力，自动化工具的灵活应用能力，系统命令和使用的熟练能力等这些基本功，还更要具备优秀的Ｄｅｂｕｇ，Ｆｉｘｂｕｇ的能力，和保持程序稳定性能力。换句话讲，一个优秀的自动化测试工程师必定也是一个优秀的软件开发工程师。 最后谈一下我为什么要转向Ｃ＋＋／ＣＬＩ？从上边的排序大家可以看到，Ｃ＋＋／ＣＬＩ是目前Ｗｉｎｄｏｗｓ平台最强大的编程语言。在我的自动化开发的过程中，我需要高级语言和系统命令都不能完成的功能。如果没有Ｃ＋＋／ＣＬＩ我就必须要通过ＵＩ来实现，从而降低我程序的可靠性。而有了Ｃ＋＋／ＣＬＩ的功能，我就可以绕过ＵＩ操作了。总之，能够绕过ＵＩ操作的能力也体现出一个自动化测试人员的能力。从这个角度讲，测试人员有很多东西要学的。最后说一下，我自动化工作的要求是１００％可靠，我还不能完全满足，因为使用我程序的人是那些手工测试的人，他们的使用环境的变化有可能引起一些问题的产生，基本上还不是我程序的问题，而是测试工具，或者其他模块的问题，我需要想办法去ｗｏｒｋａｒｏｕｎｄ。不过，随着一定时间问题的积累和解决，如果环境不变，应该可以达到１００％可靠。（可是环境的变化是不会停止的，因此实际上很难达到永久的可靠，不过一段时间的可靠还是应该可以达到的，或者说我们的测试开发必须有这样一个目标，就如同软件开发的目标一样） August 08 驳斥《C++/CLI 的十宗罪》由于公司有大批程序员死在 C/C++ 的内存管理上(泄露，越界)，作为有先见之明的，伪程序员的老板征集了各方意见后，决定将现有的所有框架代码移植到 C++/CLI 下面来。由于本人在 C/C++ 上多花了几年功夫，自然，这个“简单”的问题就落在了我的肩膀上。用了一端时间 C++/CLI 后，发觉 C++/CLI 不是鼓吹中的那么好，特别是对于 C++ 程序员来说，简直是噩梦。依据 MS 的历史,我认为 MS 在 VC9.0 以后的版本中才能将 C++/CLI 实现的比较完美。(MS 的历史：要在第三个版本才会比较好用，例如：VC4、VC5 都不是很好，VC6 我用了 7 年；.NET 2002、2003 也一堆问题，.NET 2005 终于好用了)。 特在此总结了 C++/CLI 的十宗罪，罪状如下： 第一、没有全局变量 好吧，我承认“现代”的高级语言都没有全局变量，不过，实现这些高级语言的运行库都有无数的全局变量（反汇编跟踪下就知道了）——哦，只许州官放火，不许百姓点灯。好吧，我承认没有全局变量，我还能生存，大不了晚上我不点灯不做事了。
[Comments] 既然你知道现代的高级语言都没有全局变量，怎么能把它作为Ｃ＋＋／ＣＬＩ的罪过呢？为什么现代的高级语言都没有全局变量呢？为什么面向对象的一大特点就是封装性呢？既然你研究了几年了Ｃ／Ｃ＋＋，应该清楚和明白吧？简单的来说，在Ｃ语言时代是没有封装性的概念的，因此全局变量满天飞，使得大型程序维护起来十分的不方便。这也是为什么面向对象概念兴起的一个很重要的原因。作为一个程序员如果从整体的设计来考虑的话，是应该尽量少用或者不用全局变量的。这也是为什么现代的高级语言都取消了全局变量了，而且如果面向对象的设计能力比较强的话，是可以完全的抛弃全局变量的使用的。当然了，对于很多Ｃ程序员来说，不能使用全局变量有点要命的感觉。不过这不能怨语言，应该看看自己是否真正理解了面向对象的概念。 还有就是，为什么他们的运行库有无数全局变量？因为他们是用Ｃ来实现的，在Ｃ语言里是必须要用全局变量的。
第二、类的静态成员变量的初始化时机问题 没有全局变量是吧，那么我用静态成员变量来模拟总可以了吧。很好，顺利编译通过！但是，但是，这个静态成员变量是什么时候初始化的呢？哦，用到这个类的任何变量/函数/实例的时候初始化的！这个到是很好，解决了全局变量的初始化顺序问题。问题是，我只不过希望静态成员变量将本类注册到类工厂去。我从来不会直接访问这个类的任何变量/函数/实例——我只访问他的基类。这样一来，我的类工厂里空空如野，我的系统再也工作不起来了。
[Comments]这个问题跟第一个问题是类似的。还是你要想方设法的去用全局变量，而没有想过为什么不让你用全局变量。静态成员变量本来就不是做这个用途的，它是类的实例的一个全局变量，注意只是这个类的实例，而不是整个应用程序。这只能说明你错用了静态成员，而不能归于Ｃ＋＋／ＣＬＩ的罪过。 还有就是静态成员完全可以初始化，只是你自己不会罢了。建议你好好的去学习一下．ＮＥＴ。
第三、弱智的、缺乏实际应用经验的人设计的的静态成员变量初始化地方的问题 你能判断下面这句话是变量声明还是函数申明吗？
[Comments]没看出这个有什么问题呀？你难道读程序是一句一句的读吗？我们怎么能够把程序分割理解呢？如果上下文一起来看，能有什么歧义呢？
第三、静态局部变量的问题 你知道，仅仅一个“单件”，就多么的需要这个玩意！
[Comments]这个不太明白想表达什么。
第四、功能弱到极点的 array 其实已经很强大了，比 C++ 的数组多了一个 Resize() 功能了。但是，跟 std::vector 比较起来，一个天上，一个地狱！好吧，我承认我对 CLI 不熟悉，那么，谁告诉我，C++/CLI 提供了什么样的东西，具备 std::vector 的功能？不要告诉我基于 CLI 的模板库，我严重怀疑其可工作否。
[Comments]看来你真的没好好学过Ｃ＋＋／ＣＬＩ，你不知道Ｃ＋＋／ＣＬＩ最大的优点在于通吃一切吗？你现在抱怨的是ＣＬＩ，就算ＣＬＩ没有你想要的功能。可是Ｃ＋＋／ＣＬＩ是Ｃ＋＋和ＣＬＩ的混合体，你没有必要一定用ＣＬＩ，你当然还可以用回你所有的Ｃ＋＋功能。ｓｔｄ：：ｖｅｃｔｏｒ算个什么呢？
第五、value struct 和 cpp struct 在模板函数上，对“引用”的符号匹配问题 对于 cpp struct 应该匹配那个符号？'&' 还是 '%'？答案是 '%'。哦，我的天哪，居然还可以使用 pin_ptr<cpp struct> 来取地址！实在是太伟大了！那么，我的 cpp struct 变量究竟位于哪里？堆上？栈上？还是托管堆上？我迷糊了，编译器跟我一起迷糊了。
[Comments] 看来你还没分清楚ｃｐｐ ｓｔｒｕｃｔ和ＣＬＩ ｓｔｒｕｃｔ的区别呀。建议你还是好好学习一下再来讨论吧。
第六、模板函数的特例化问题 对于下面这样的函数： myclass c; 你认为“式一”会调用那个函数？我知道你的答案，不过你的答案是错误的，因为你是一个资深的 C++ 程序员。当我意识到我的系统不能正常工作是源于此的时候，我很想联系恐怖份子，购置一枚或者更多的原子弹，然后在 google 上找到 MS 总部甚至分部的坐标，然后把原子弹的目标设置好……
[Comments] 建议你先学学ｔｅｍｐｌａｔｅ和ｇｅｎｅｒｉｃ的区别吧。
第七、C++ 和 C++/CLI 的代沟问题 ref class,value class 里不能放置 cpp class 的实例，这个我还能接受。但是，cpp class 里不能放置 ref class,value class 的任何玩意——实例、引用、指针、interior_ptr,pin_ptr。我怎么实现回调式的功能？不是我非要设计出回调式的功能，而是，有那么多，那么多的Win32 API 是回调式的！好在我在知识的海洋中找到了 System::Runtime::InteropServices::GCHandle，不然，我定制的原子弹就会上升成为氢弹！
[Comments] 这不是Ｃ＋＋和Ｃ＋＋／ＣＬＩ的代沟问题，是Ｃ＋＋和ＣＬＩ的代沟问题，Ｃ＋＋／ＣＬＩ提供了你一个桥梁把他们联系在一起，你应该感激才对。没有Ｃ＋＋／ＣＬＩ你更没法搞。这是Ｃ＋＋／ＣＬＩ一大优点，而不是罪过。
第八、.NET提供的类库太过于臃肿 大家知道，C/C++ 的 CRT 也就几百K，C/C++ 仍然实现了你所能看到的软件的绝大部分——但是，你看到的，用 .NET 实现的软件有几个？好吧，我承认我偷梁换柱，不过，由于.NET库的臃肿，以致于稍微一个好听，合义的单词都被.NET用掉了。这让我不能放心用 Object,String,IStream...等等作为我自己的类型的命名，我只好绞尽脑汁想别的名字——正如您所猜测的一样，我的英文很差，必须要借助翻译工具才能看懂 C++/CLI 的白皮书。这让我想出新鲜的，上口的，其他跟我英文一样差的人能看明白的单词，其难度真不啻于用随机数拼出一个Windows啊！ 随机数拼出一个Windows：这个是我一个哥们的研究课题，把 N 台电脑关在一个小黑屋里，让他们随机生成二进制数据，并当作程序来运行。当速度足够快或者运气足够好的时候，生成的二进制数据刚好跟你从 DB 商手里买到的 Window XP 一样。（UMU：U墨的手法，说明几率极小极小！）
[Comments]首先．ＮＥｔ是否臃肿，是否应该臃肿本身就是一个问题。就算．ＮＥＴ是臃肿的，也不是Ｃ＋＋／ＣＬＩ的罪过。那是．ＮＥＴ的问题。
第九、四饼！ 这个问题是由第八个问题引起的，因为有这么多，这么深的名字空间，各个名字空间下有这么多相同名字的类型名，让我不得不整天::...::...::...::...::...::...::...::...::...::...::...::...::......
[Comments]如果你用了using spacename, 是不用那么多：：的，这个是．ＮＥＴ的常识问题，也是．ＮＥＴ的一大预言特点。优于Ｃ＋＋的。
第十、GC不能解决内存泄露问题 首先，我们要承认 GC 的一个伟大壮举：GC 能够在程序退出去的时候，释放所有的内存。但是，在 8 年前，我用 C 在 DOS 也能够办到这个功能。问题是，运行十天后，我 C/C++ 占用的不会释放的内存，GC 也不能释放，甚至 GC 占用的内存还更多。因为 GC 分不清楚没有置空的句柄是否还有机会被再次使用。
[Comments] 看来你一点都不懂ＧＣ呀。建议你先去好好学学。 综上所述，作者是一个对．ＮＥＴ没有太多概念的Ｃ／Ｃ＋＋的程序员。因此，对Ｃ＋＋／ＣＬＩ的理解，就显得非常肤浅了。不知道作者搞了几年的Ｃ／Ｃ＋＋为什么就这么轻率的发表这样不负责任，有很大误导作用的文章出来。从作者这样热衷全局变量的使用来看，好像面向对象的设计水平也很普通。希望大家不要被误导，看到作者的文章，使我对Ｃ＋＋／ＣＬＩ更加有信心了。 August 07 发现C++/CLI是发现新大陆了吗？最近事情不多，想学点什么新东西了。最近几个月Facebook的F8炒得很火，吸引我看了看他们的Application是什么样子的，应该怎么开发。看完之后，自己不太感兴趣，因为自己要建Server，比较麻烦。然后，随便找找发现了C++/CLI。原来微软在2005年就推出了这门算是新的语言吧，以前只是知道有managed C++，评价不高，C++/CLI是它的改进版本。随便了解了一下，感觉这门语言还是很吸引我的。原因很简单，就是它的强大混合编程的能力。它可以调用.NET, MFC, Windows API。目前的测试开发语言主要是C#。一直以来自己都认为C#是最适合自己的测试开发工具了，因为用C++开发测试程序不太现实，至少不能作为主要的开发语言。VB，Java什么的是我一直都讨厌的，其他script的什么的，功能都太弱了。唯有C#是除了C++以外最强大的快速开发工具。可是，用C#开发里边就存在了一个不可逃避的问题，就是调API的艰难。很多时候，我们都会碰到.NET不能完成的功能，尤其是偏系统一类的测试。那么我们就需要用Windows API来实现，可是C#调API的方式使我选择了逃避，或者说放弃。心里想，必要的时候就用C++吧，可是还真没用过。（这也就是测试人员的灵活性了，呵呵） 大概一天的时间都是看别人对C++/CLI的评论，使用心得什么的。感觉大部分人都是批评的态度，少数人喜欢和支持。说真的，自己也能理解C++程序员对它的看法。首先，它新增加的关键字确实让人不习惯，看起来，用起来都觉得怪怪的。其次，大部分C++程序员开发的项目都不需要用到.NET吧？至少目前应该是这样，很多人还在VC6下边编程。既然用不到它，就不会体会它的好处，那么就真的只有不好了。少数人喜欢它就是因为它强大的能力。目前来看，还真的没有其他语言从功能上说能与它相提并论。另外一点就是，从资料上来看，目前使用这门语言的人很少。因此我也很犹豫到底应不应该学习和使用它。 在疑惑中对它进行了学习，感想如下。 1。想真正的掌握好这门语言既需要C++的知识，又需要.NET的知识。正如一些人所说，学习它的难度要高于C++和C#。当然我是说真正的掌握，你可以用它只做C++程序，或者只做.NET程序，那就跟单独学C++或者C#的难度一样了。因为，大部分C++程序员侧重于底层，C#程序员侧重于上层，使得纯C++/C#程序员转向C++/CLI都需要一定的时间，不会轻易上手。当然对C++程序员来说会更简单一些，毕竟.NET还是比较容易掌握的（前提是他们能有心，耐心学习）。另外，如果同时具备了C++和C#的知识和经验，上手C++/CLI还是会很快的。比如我学了一天就可以上手了。 2。功能的确强大，.NET, MFC, API通吃。我装的VS2008 express 版本不支持MFC, 不过.NET+API真的就足够对付任何工作了。 3。语法没有想象中的那么不可接受。首先，它增加的关键字其实并不多，大概10几个吧，很容易学习和掌握。其次，很多关键字你也可以完全不用的，比如ref struct, value struct可以完全不用。value class 我觉得也没什么太大用。ref class就足够了。这样的话，虽然是4个关键字，可是对你来说就只是一个。再次，这里边真的有一个习惯问题, */^, using/using spacename, ./->, new/gcnew 这些东西你很快就应该能够适应。 4。和C#的比较。C#的语法还是简洁许多，也更自然。如果纯做.NET程序，目前来看没有必要非用C++/CLI。可是如果需要调用API的话，C++/CLI给你带来的方便性还是要大于语法的繁琐。因为语法可以去适应，习惯。功能的强大可是可遇而不可求的东西呀。所以，个人认为做测试程序，C++/CLI还是一个不错的选择，能够更广阔的设计我们的test case。 5。关于C++/CLI的未来。未来真的很难说，一看市场的需求，二要看微软的支持。目前来看，C++多用于系统，驱动方面。C#用于应用方面。相信未来的一段时间都会维持在这种状态中。C++/CLI给我们带来的是C++,C#混合编程。可是市场上有多少产品的开发需要这种混合编程呢？目前来看很少，就算有，有些公司就单独用C++,C#来做，再集成起来也是解决的一种方法。另一方面，C++程序员和C#程序员分的很开，没有适合用这种语言的中间状态的程序员。如果没有产品，没有程序员的支持，很难说能有什么太好的前途。不过我想C#加上C++/CLI的解决方案还是要比C#加上纯C++的解决方案更合适，合理一些。如果不嫌弃C++/CLI的语法，单独用它也可以完全的解决。现在来看，C++/CLI的阻力最大来自于它的语法了，如果语法简洁了，在.NET领域会有不少人用，从而引起它的流行，而在系统领域也得到一定的应用。个人认为，using space可以就改为using, *,^合并为*，由编译器智能判断是传统指针还是引用指针，new和gcnew也合并，编译器智能判断是应该在普通堆还是在托管堆上建立。如果这样的话，我想就没什么人会拒绝接受它了。 个人来说, C++/CLI还是极大的提高了我写测试程序的能力，我还是抱着积极的态度去采用它。这也避免我长期用C#而疏远了C++。用好C++/CLI就等于用好了三门语言。 August 02 如何debug lsass.exe这两天需要调试lsass.exe, 昨天baidu竟然都查不到什么信息。lsass有它的一些特点。首先它是运行在user mode, 因此一般来讲应该用user mode的调试工具来调试。可是，如果用debuuger直接跟它相连，计算机就会自动重启，使得调试无法进行下去。其次，如果我们想在机器启动的时候调试lsass也比较麻烦，因为user mode debugger那个时候还不能工作。再次，调试lsass的时候，网络的访问不能进行，因此从网络上访问symbols and source code 也成为了不可能。经过认真研究，发现有三种方法可以用来调试lsass,并且各有优缺点。下面就一一讲解一下。 1. ntsd piped through KD a. 修改注册表 HKLM\Software\Microsoft\Windows NT\CurrenVersion\Image File Execution Options\lsass.exe debugger = REG_SZ c:\debuggers\ntsd.exe -d -g -G b. 用另一台机器通过kernal debugger和测试机相连 c.重起测试机 这样的话，在启动阶段，当系统调起lsass的时候，测试机的ntsd就开始工作，并且将输入，输出传送到kernal debugger上。这个属于在kernal debugger里进行user mode的调试。 优点：可以在启动的时候调试lsass。 缺点：symbols and source files 必须要copy在测试机上。（不太方便）
2.Debugging LSA via dbgsrv.exe a.Find the PID for LSA via tlist.exe b. C:\Program Files\Debugging Tools for Windows>dbgsrv.exe -t tcp:port=1234,password=spat c.Run this command to attach to LSA on the remote machine. I:\debugger>windbg.exe -premote tcp:server=192.168.1.102,port=1234,password=spat -p 596 -- where 596 = PID of LSASS 优点：symbols and source files 可以在调试机上 缺点：不能在启动的时候进行调试
3.Debugging LSA from Kernel a. Get the process address for LSASS 0: kd> !process 0 0 lsass.exe PROCESS 815196c0 SessionId: 0 Cid: 010c Peb: 7ffdf000 ParentCid: 00e4 DirBase: 042d2000 ObjectTable: 81519aa8 TableSize: 859. Image: LSASS.EXE b. Switch to the process context: Either .process /p /r 815196c0 Or .process –i 815196c0 ;g;.reload /user 优点：symbols and source files 可以在调试机上，可以进行log out/ log on 过程的调试 缺点：不能在启动的时候进行调试 因此，如果想在启动的时候调试，就必然要选方法1。如果想在log on的时候调试，选择方法3。其他情况，可以选择方法2，或者方法3。 |
|
|
