Coplien首先让Uncle Bob定义了一下TDD，Uncle Bob说明了他的三个法则：（敏捷的同学一定不陌生）

　　一个测试驱动的程序员，其不会在写出一个测试失败的Unit Test前，去写一句可用在生产线上的代码。（没有测试之前不要写任何功能代码）

　　在编写用于生产线上代码之前，不写过多的测试失败的Unit Test。（只编写刚好能体现一个失败情况的测试代码）

　　在现有代码通过Unit Test前，不写更多的用于生产线上的代码。（只编写恰好能通过测试的功能代码）

　　Coplien说他有意见的不是这三个法则，而是因为这个三个法则是孤立说出来的。Coplien说他和一些咨询师或是Scrum Master参与过很多的项目，他们发现这些项目都有两个问题：

　　他们使用TDD的时候，软件没有一个架构或是framework。当然，Kent Beck说——TDD可以驱使你去做架构。但是，TDD和Unit Test 是一回事吗？Unit Test是一个伟大的事，尤其是当你去写API和类库的时候。今天XP所说的TDD和UT很不一样。如果你使用TDD来驱动你的软件系统架构，那么，基本上来说，三个迭代以后，你开发的软件就会crash掉，而且无法再往前开发。因为什么？因为连软件团队自己都受不了这三个迭代出来的架构，而且你还会发现，你根本没去重构。

　　第二个问题是，TDD这种方法破坏了GUI（图形界面），就算是Kent也说：“你永远不可以在一个漂亮的界面后面隐藏一个糟糕的架构”，Coplien强烈地相信软件的架构是通过界面来发出其光芒。他觉得如果没有一个好的软件架构，这个会影响用户的操作。

　　Coplien接着说，如果我们使用Uncle Bob的三条法则，我们也许没有什么问题，但Coplien想告诉大家另一个非常重要的事，那就是软件架构。并说：“我根本不接受TDD是软件专业化实践的论点”。

　　Bob大叔说，让我们回到99年，那时的敏捷社区觉得软件架构是无关的，不需要软件架构，只需要做一堆tests，做一堆stories，以及足够快的迭代，这样就可以让那些代码魔幻式地拼装起来，这就是horse shit。对于大多数的敏捷拥护者来说，这的确是愚蠢的。今天你再和Knet说这个事，他也会说那不过是一种说法。

　　Coplien回应到，实际上，Knet在解释XP的时候，在他的书131页的位置说过，“是的，你得做些前期的架构，但也别把自己搞乱了”。

　　Bob大叔把话题转回来，继续聊关于架构方面的事，他说软件的架构很重要，他也写很一些关于架构的书，他说他也是一个架构方面的怪才，但是他认为架构自己并不会形成软件的所有的外表。他觉得好的软件架构和设计能力应该出现在若干次迭代之后。他觉得你在架构软件的时候，你会创造一些东西，也会破坏一些东西，并且会在几次迭代中做一些试验性的工作，来尝试一下不同的架构。在2到3次迭代以后，你可以知道那一种架构是对的，这样，你可以在后面的迭代中进行调整。因此，他认为架构是需要进化和发展的，而不会因为被可执行的代码所形成，也不会因为你所写的测试而形成。

　　Coplien赞同架构进化的观点，而且他相信软件的架构的演变和进化不是因为你写的代码，也不是因为Use Case，也不是告诉你你的软件需求的范围和其中的关系，但是如果你做的方法是以增量式的，以用户驱动式的，而你却在和用户沟通时没有一些前期的业务知识，那么这一定是相当有风险的，并且你一定会把事搞砸的。

　　Coplien接着说，他在Knet早期提到TDD的时候和Knet时，提到YAGNI（陈皓注：You Aren’t Gonna Need It，XP的一个法则，也就是只做最简单的事）时，Kent说到：“让我们来做一个银行帐户，一个储蓄帐户”，储蓄帐户其实就是对余额进行一些加加减减的事，就像一个计算器一样。Copilen继续解释到，但是如果你要做一个真正的银行系统，你的软件架构根本不可能从一个储蓄帐户的对象（计算器）重构出来。因为储蓄帐户根本就不是一个对象，其是一个流程，后面有一个数据库的查帐索引事务，还有存款保证金和利息，还有一些转帐功能。就算是这样，这也只是用户的功能，你还需要支持税务人员和精算会计师等这些人，这会让银行系统成为一个错综复杂的软件架构，这绝对不是你可以用迭代干出来的事。当然，Bob大叔是可以的，因为他有40年的银行系统的经验。但是Bob大叔你的这40年可真不敏捷啊。

　　Coplien接着说，因为Bob大叔可以在软件前期做很多很重要的决定，这让得后面的事变得相对比较简单。Coplien根本不相信只要你把代码往那一放，在上面披上一层皮，再设置好一些角色，设置好接口，在文档里写上整个业务结构，而你只有在有人花钱的时候你才会在其中填充进真正的代码，反之就违反了你的YAGNI原则。所以，你只是在你需要的时候做你要做的事，但你却还是要提前得到你的软件架构，否则你一定会把你自己逼进死角的。

　　Bob大叔辩解到，我说的可能和你说的这个有点不同。我们应该不会像你所说的往接口中写一些抽象成员函数，而是创建一些有抽象接口的对象。当然，我不会一下子为这个对象装载上一堆方法。那些是我需要使用测试驱动或是需求驱动来做的事，我还会随时随地在看是否哪里软件架构可以让我拆分接口。

　　Coplien说，问题是你得知道你要干什么？他说他非常同意Knet的书”XP Explained”里说的——“你不能去猜”，然后他举了一个例子，一个他曾经在一个电信项目中重新架构软件的例子，这是一个长途交换机的项目，项目组特别喜欢用面向对象，有一个人需要去做一个“Recovery Object”（应该是系统恢复对象），Coplien说这是很扯的一件事，因为系统恢复根本就不是一个对象，因为他对业务不熟，所以想这么做。而当你在细节上分析的时候，你会发现这根本就不是一个有成员方法的对象。我个人认为，Coplien想用这个例子来说Bob大叔的先定义对象的抽象接口并不是一个好的需求分析的方法。Coplien还说，这个事情今天被资本化成了SOA，真是在玩火啊

　Q4阶段，服务线项目特别忙，每个小二身上都承担了两到三个项目的压力，情况的比较坏的是，有些项目是测试执行时间并行的，让人有些腹背受敌的感觉，倍感压力！总结了一些本人在项目测试执行时间并行的情况下的一些小经验，供童鞋们参考：

　　1、每天计划并不断的总结，简单可行

　　两项目并行初期，埋头苦干，发现工作效率很低，疏漏的地方总是防不慎防，在项目中陷入被动的境地。静下心来冷静思考，切身体会到工作效率的低下，照此下去，项目风险不可控！为了改变被动的处境，先简单做了个日工作计划，很简单可行，两个项目都兼顾到，执行中严格按照计划的时间点集中投入时间精力，每个时间点的成果都保存并打印，执行结果反应在纸上一目了然，发的日报和qc上的记录都清晰的显示了白天的工作量和比重！项目的质量、风险完全可以把控！

　　2、持续的跟进需求，和业务方保持良好的沟通

　　在测试执行前和业务方重新过了一遍需求点，对项目的核心功能、重点及TC优先级划分，执行中严格按照需求的优先级执行用例提bug并督促研发人员修改，并对分歧点做记录备份，每天一汇总并体现在测试日报中，如果分歧点比较多的话，可以和业务方、PD、PM、开发人员一起讨论沟通，确定最终实现方法并得到业务方认可.

　　3、在满足业务方需求的基础上完善产品

　　在项目中，完成业务方提出的需求功能点就完事了吗？答案不言自明，业务方提出的只是一些基本的功能点，实现后功能是否可用、是否符合用户的操作习惯也是必须考虑进去的，不同的客户的专业要求不同、习惯也各有特点.做好这个部分就靠测试人员来把握了，需要和需求方多沟通，了解业务方的一些特定功能点和功能实现方式.

　　把握住以上三个方面，让我在测试执行时间并行的不利情况下，把控住了项目的风险，希望对以后有类似情况的童鞋们有帮助！

我们知道开发人员与测试人员在某种程度上可以说是冤家对头，因为开发总是认为我做的产品是完美无缺的，没有Bug的，但是测试总是想方设法给你挑刺，因而产生了“矛盾”。很多公司对开发的绩效评估里就有一条是每千行代码产生的Bug量，当然是越少越好了，但是对于测试的绩效评估也有一条平均每天提交的Bug量，所以表明上看起来这种矛盾真的是无法避免的，因为大家都要“混饭”吃的。

　　但是大家其实心里都很清楚，一个产品不可能没有Bug的，或多或少，或大或小，总是会有Bug存在，不然微软也不会这样经常发布补丁了，连微软这种级别的公司都会Bug，所以对于Bug的存在，我们大可以泰然处之。

　　虽然可以泰然处之，但是对于Bug我们还是需要很重视，因为既然产生Bug，总是某一方面没有想到或者是想错了，所以我是建议可以通过对Bug分布进行分析，找出哪些地方特别容易出Bug，然后在开发过程中特别注意。对于我们公司而言，之前说过了我们是用TechExcel DevSuite 系统来管理，所以我们在开发中会加入几个强制检查项，比如说是否兼容不同数据库，是否支持不同语言，是否考虑过不同浏览器，开发在完成代码如果不检查这几项的话，是无法把开发任务直接交给测试来测的，这样就可以从某种程度上避免一些Bug的产生。

　　不过即使避免了总还是会有一些Bug会被找到的，呵呵，没有Bug还要测试干嘛呀？在很多公司里测试人员的数量都大于开发人员的，像微软这种公司，可能是2：1的关系，为什么需要这么多测试呢？

　　第一方面，当然是他们的产品太大了，太复杂了

　　第二方面，一个产品的质量光靠开发是不行的，因为开发虽然能把产品做出来，也可能可以用，但是他们可能没法考虑其他一些方面，比如用户体验上，比如压力测试上，比如不同语言下的应用，甚至是不同操作系统下的应用等等，这些方面光靠开发可能没法想全，甚至即使想全了也做了，你能保证在哪些环境就一定不出问题吗，毕竟开发编程总是在一个环境下的编的，他编完即使自己测了一下也不可能把所有环境下都测过的。

　　第三方面，因为一个产品/一个功能需要在很多外在环境下测试（操作系统，数据库，浏览器，网络），另外一个功能需要测试点又很多（正常输入，非正常输入，临界，压力值等），所以即使是一个功能，需要测试的地方就很多，何况产品大功能多的了。而且，我们知道一个人再强，他能想到的测试点总是有限的，所以我还需要另外的人对一个已经测过的功能点进行再次验证测试 （关于这个方面，由于我们公司是用DevSuite 方案中的 DevTest 工具来管理测试覆盖面的，所以稍微可以减少一些测试人员配置）。另外对于一个开发来讲，由于功能点是他做的，所以别人发现了问题让他修，其实他是可以修起来很快，代码都轻车熟路的，所以如果一个测试配一个开发的话，可能发现的Bug量无法让开发完全忙起来，从领导角度说这个比较浪费成本的。

　　所以考虑到这些原因，一般大公司就会有很多的测试人员了，当然现在的情况又有不少改变了，随着自动化测试的引入，需要人工的地方会相对减少，所以有不少公司开始减少纯手工测试的活，但是做过开发的人也知道，如果一个产品很复杂，光靠自动化测试是远远不够的，所以呢，我相信手工测试还会在很长时间内存在，至少在我能看到的范围呢，好像还没法用自动化测试来代替。

　　不过在国内的话，我接触到的大多数软件公司里，对测试人员的配置都不太多，当然我不认为他们是忽视软件质量，他们可能认为功能做出来了，开发直接测一下就好了，测试人员的话只要最后综合跑一下就Ok了。我相信这个是怎么保证软件质量的一种认知的观念问题，我认为这样就可以保证产品质量，你认为那样才可以保证质量，大家各有说法，但是从我们公司的角度来说，我们还是比较看重质量的，可能也跟我们公司背景有关吧，外企，跟国外比较接轨。所以我们公司现在的开发与测试配置是大于1：1的，不过比微软还是差一点。

　　介绍了一下测试的必要性，再回过头来继续说开发与测试的“矛盾”，其实这个矛盾从本质上来说是由于绩效管理时过分强调了开发人员造成的Bug，而这个“过分强调”又必须是测试人员一定要强调的。所以呢，矛盾就开始产生了，开发说，这个不是Bug，或者说我不能重现，还说，你干嘛老是提Bug，是不是对我有啥不满的。久而久之，“矛盾”产生了，激化了，产品质量下降了......从领导层角度来说，他们当然也希望开发做出来产品是没有Bug的，这样子我连测试人员都不用配了，成本下降很多了。当然，大多数领导也知道这个是不可能的，与其由于产品质量下降造成产品不好卖，还不如配几个测试人员了。配了测试人员，又出现“矛盾”了，我想许多公司的领导已经处理得很好了，不过我还是想简单介绍一下我们公司的处理方案：

序言：上篇文章说的“自动化例行测试有效性策略”，在又一次进行例行测试的时候，安排了一个不懂脚本的测试人员进行了例行测试操作，结果这是最迅速的一次，而且还发现了一些产品问题，效果不错，验证发现，其有效性还是得到了一些提高。所以说，有时候，做自动化测试很害怕的是“完美主义”与“盲目主义”，局限于一些误区，所以一定要以“测试价值”为导向，不时的跳出来看一看其自动化测试的应用价值是不是进入了误区。这次，对一些不同的自动化测试方式的应用进行了策略分析，不同的自动化测试方式应用不同的场景，不管如何应用，提高效率则是最佳应用。

　　一、自动化几种测试方式

　　这次，自动化测试几种方式，我暂时按测试类型分成：

　　1、界面自动化测试

　　C/S架构（或者桌面类型）界面自动化测试：包括桌面界面测试类型，当然有windows方面的软件界面、跑在windows操作系统上的虚拟机方式的界面，例如java swing。前者采取的方式可以调用操作系统本身的API来构建自动化测试、后者可以采用虚拟机内的事件处理机制来完成了。

　　B/S架构（或者web类型）界面自动化测试：其实现原理之一可以依靠JS来进行客户端的操作，然后寻找对象是采用了DOM解析技术，将web方面的节点进行解析定位。

　　手机方面（嵌入式产品）界面自动化测试：其实现原理之一也是可以依靠其相关系统提供的API来完成。例如：安卓的monkey就是安卓提供的一个提供动作操作的一个工具。

　　2、命令行自动化测试

　　CLI自动化测试：即嵌入式的产品很都基于嵌入式操作系统完成，例如：电信产品中的ciso路由器就是最早的代表，而系统测试人员的测试大都应用命令行进行测试，所以，其自动化测试实现可以基于CLI的脚本控制实现。当然，对数据库SQL命令行的操作也可以归为此类。

　　3、API自动化测试

　　API（Application Programming Interface，应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件的以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节，其实就是软件中的封装性的思想。个人认为，API测试是用来验证组成软件的那些单个方法的正确性，其可以包括为单元测试、单个组件测试以及接口测试。一者是对单个模块功能测试、另外一者是对测试系统组件间接口的一种测试。但本质上都是调用其API来验证相应相应功能实现或者交互。

　　二、自动化测试不同方式策略分析

　　以前总在思考如何能够最大化的应用界面自动化测试与CLI自动化测试或者API自动化测试的不同特点去实现各自的自动化测试最大利用率：

　　1、界面自动化测试的特点在于：

　　1）操作方式复杂，需模拟出不同的手工操作。

　　2）其界面元素结构层次变动性较大。

本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。
　　随着Internet和Intranet/Extranet的快速增长，Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和数据库系统正在被移植到互联网上，电子商务迅速增长，早已超过了国界。范围广泛的、复杂的分布式应用正在Web环境中出现。Web的流行和无所不在，是因为它能提供支持所有类型内容连接的信息发布，容易为最终用户存取。
　　Yogesh Deshpande和Steve Hansen在1998年就提出了Web工程的概念。Web工程作为一门新兴的学科，提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。它"使用合理的、科学的工程和管理原则，用严密的和系统的方法来开发、发布和维护基于Web的系统"。目前，对于web工程的研究主要是在国外开展的，国内还刚刚起步。
　 在基于Web的系统开发中，如果缺乏严格的过程，我们在开发、发布、实施和维护Web的过程中，可能就会碰到一些严重的问题，失败的可能性很大。而且，随着基于Web的系统变得越来越复杂，一个项目的失败将可能导致很多问题。当这种情况发生时，我们对Web和Internet的信心可能会无法挽救地动摇，从而引起Web危机。并且，Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。
　　在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。
　　一般软件的发布周期以月或以年计算，而Web应用的发布周期以天计算甚至以小时计算。Web测试人员必须处理更短的发布周期，测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。
　　一、功能测试
　　1、链接测试
　　链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
　　链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
　　2、表单测试
　　当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
　　3、Cookies测试
　　Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
　　如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
　　4、设计语言测试
　　Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、javascript、 ActiveX、VBScript或Perl等也要进行验证。
　　5、数据库测试
　　在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
　　二、性能测试
　　1、连接速度测试
　　用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
　　另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
　　2、负载测试
　　负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？
　　3、压力测试
　　负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
　　进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
　　压力测试的区域包括表单、登陆和其他信息传输页面等。
　　三、可用性测试
　　1、导航测试
　　导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
　　在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。
　　导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
　　Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
　　2、图形测试
　　在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
　　（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
　　（2）验证所有页面字体的风格是否一致。
　　（3）背景颜色应该与字体颜色和前景颜色相搭配。
　　（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。
　　3、内容测试
　　内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
　　信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。
　　4、整体界面测试
　　整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。
　　对所有的可用性测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
　　四、客户端兼容性测试
　　1、平台测试
　　市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。
　　因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
　　2、浏览器测试
　　浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、javascript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，javascript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
　　测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
　　五、安全性测试
　　Web应用系统的安全性测试区域主要有：
　　（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
　　（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
　　（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
　　（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
　　（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
　　六、总结
　　本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。
基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。 

快速提升MySQL可扩展性的五大绝招

我对抽象类和接口的理解

今天公司组织培训。讲解到抽象类和接口这里的时候。好像有同事不太明白。（请允许我自作多情一下！）

　　鉴于我自己对这部分也不是掌握的很透彻。所以发个博文上来，一是记录一下。二是希望还不明白的朋友在阅读完本文之后能有个了解。

　　新手，如有不当之处，请多多包涵！

　　MSDN：抽象类是从子类发现了公共的东西，泛化（也可以说把公共的东西单独提取出来）出父类，然后子类继承父类，而接口是根本不知道子类的存在，方法如何实现还不确定，预先定义的

　　有一个人，他叫王麻子，那年，他生了个儿子，起名叫 王三。这个时候用程序来描述就是他和他老婆创建了一个对象 ，代码如下：

public class WangSan     {         string FirstName;         string Sex;         void CanDo()         {             Console.WriteLine("我是王三,我会画画");         }     }

　　王三有 姓、性别、和一个能力，他会画画。

　　又过了一年，王麻子和他老婆又生了个孩子，起名叫 王四，用程序来说，他们俩又创建了一个对象

public class WangSi     {         string FirstName;         string Sex;         void CanDo()         {             Console.WriteLine("我是王四,我会唱歌");         }     }

　　王四也有 姓、性别和一个能力，他会唱歌

　　假如一下。假如他们是印度人，对计划生育没什么限制，他们每隔几年都会再生个孩子出来。这样的话。如果要用程序来描述起来岂不是很麻烦，所以这个时候我们应该考虑对代码进行重构，提取共同的部分，也就是姓名、性别和一个能力

　　如下：

public abstract class Son     {         protected string FirstName;         protected string Sex;     }

　　因为他们都是王麻子的孩子，咱们假设一下，假设由于他们都是王麻子的孩子，所以他们必须 姓王、有性别，所以这个 基类 Son 就必须声明为  abstract 的（创建就为被继承）。就是说凡是 王麻子的孩子，都必须继承自 Son 这个基类，因为他们都有王麻子的一些特性和自己的特性，

　　比如：

public class WangSan:Son     {     }

　　我们不必在 WangSan 这个类中写任何代码，因为他是王麻子的孩子，所以他有 姓 和 性别。。在New WangSan 这个对象的时候。他就自动的有了 FirstName 和 Sex。这些属性。

又假如，由于王麻子是个全能人才。所以他的孩子必须会一项技术，比如游泳或者 唱歌。这个时候 基类就可以修改一下：

public abstract class Son     {        protected string Name;        protected string Sex;         /// <summary>         /// 抽象类中的抽象方法，在子类中必须自行实现         /// </summary>         public abstract void CanDO();     }

　　添加了 CanDo 的抽象方法。 这样 当 王三 这个对象一被创建，他就必须继承 Son 这个类（他必须是王麻子的儿子，莫非两口子生的孩子是别人的？？）...而又由于Son 中有个抽象的方法 CanDo. 所以。王三 他必须 得有一项技术。如果不实现 CanDo .编译不通过（你不实现，就不能说明你是我孩子，以后我对你不好！）

public class WangSan:Son     {         public override void CanDO()         {             Console.WriteLine("我是王三，王麻子的孩子，我必须有一个擅长，那我选择唱歌");         }     }

　　这样。王三也必须会一项长处了！！

　　王四也是一样。只要他是 王麻子的儿子。他就必须实现 CanDo 方法，并且有FirstName 和 Sex属性

　　又假如有一天，王麻子偷师学艺，学会水上漂。但是他不知道谁愿意学，又不想强迫孩子们。所以他让孩子们自己决定。他定义了一个接口（发布了一个规范） IShuiShangPiao。

interface IShuiShangPiao {         void CanFly();     }

　　谁想学。就来我这里报道。结果王武想学。所以王武来报道了（程序解释就是王武实现这个接口）

public class WangWU : Son, IShuiShangPiao     {         public override void CanDO()         {             throw new NotImplementedException();         }         /// <summary>         /// 实现接口（报道），老爸就教我水上漂         /// </summary>         public void CanFly()         {             throw new NotImplementedException();         }     }

　　回到我们软件开发当中，假设以上类是我们程序中实现的一项功能，假如某一天，我们发现（或者客户要求）：凡是王麻子的孩子都必须会英语，这个时候，我们就仅仅只需要在 Son 这个类中 增加一个会说英语的方法。他的孩子们就都会说英语了。如果不采用继承的话。假设王麻子有1万个孩子，那就得修改一万个类，很累。。。。

　　以上就是我个人针对 抽象类和 接口的理解，如有不当之处，敬请提出！

　　程序需要慢慢重构，这个我当时理解起来也非常不容易。多练习，多思考就会豁然开朗！

　　但是切记，千万不要为了设计而设计。造成过度设计会很糟糕的。。。就好像我们设计数据库，虽然有3大范式，但是有时候业务迫使我们不得不违背。。。。

　　以上！

　　希望对这部分不明白的朋友通过本文能对这部分知识有个进一步的了解。同时希望各位的技术一天牛比一天！！

　如果您很容易使 shell 提示行变得色彩绚烂且带有更多信息，为什么还要坚持用烦人的标准提示行呢？在这篇技巧中，Daniel Robbins 将说明如何获得符合您的意愿的 shell 提示行，并会说明如何动态更新 xterm 的标题栏。

　　作为 Linux/UNIX 人，我们有很长的时间是在 shell 中工作，并且在许多情况下，下面这一行就是始终盯着我们的那个提示行：

　　bash-2.04$

　　如果您恰巧是超级用户 (root)，您就有权使用下面这个美丽的标示“身份”的提示行版本：

　　bash-2.04#

　　这些提示行并不是十分漂亮。这也就难怪几种 Linux 版本对默认提示行进行了升级，在其中增加了颜色和更多的信息。但是，即便您恰好有一个本身带有很好的彩色提示行的新式版本，它也不可能是完美无缺的。您或许希望在提示行中增加或更改几种颜色，或者增加(或删除)一些信息。从头开始设计属于您自己的彩色的、经过装饰的提示行并不难。

　　提示行基础

　　在 bash 下，可以通过更改 PS1 环境变量的值来设置提示行，如下所示：

　　$ export PS1="> " >

　　更改会立即生效，通过将 "export" 定义放在您的 ~/.bashrc 文件中可将这种更改固定下来。只要您愿意，PS1 可以包含任意数量的纯文本：

　　$ export PS1="This is my super prompt > " This is my super prompt >

　　尽管这很有趣，但在提示行中包含大量静态文本并不是特别有用。大多数定制的提示行包含诸如用户名、工作目录或主机名之类的信息。这些花絮信息可以帮助您在 shell 世界中遨游。例如，下面的提示行将显示您的用户名和主机名：

　　$ export PS1="\u@\H > "drobbins@freebox>

　　这个提示行对于那些以多个不同名称的帐户登录多台机器的人尤为有用，因为它可以提醒您：您目前在哪台机器上操作，拥有什么权限。

　　在上面的示例中，我们使用了专用的用反斜杠转义的字符序列，藉此通知 bash 将用户名和主机名插入提示行中，当这些转义字符序列出现在 PS1 变量中时，bash 就会用特定的值替换它们。我们使用了序列 "\u"（表示用户名）和 "\H"（表示主机名的第一部分）。下面是 bash 可识别的全部专用序列的完整列表（您可以在 bash man page 的 "PROMPTING" 部分找到这个列表）：

　　序列说明

　　\aASCII 响铃字符(也可以键入 \007)

　　\d"Wed Sep 06" 格式的日期

　　\eASCII 转义字符(也可以键入 \033)

　　\h主机名的第一部分(如 "mybox")

　　\H主机的全称(如 "mybox.mydomain.com")

　　\j在此 shell 中通过按 ^Z 挂起的进程数

　　\l此 shell 的终端设备名(如 "ttyp4")

　　\n换行符

　　\r回车符

　　\sshell 的名称(如 "bash")

　　\t24 小时制时间(如 "23:01:01")

　　\T12 小时制时间(如 "11:01:01")

当测试和开发在一起的时候事情好像是向着两个极端发展！

　　一是开发人员很厌恶测试人员给他们提BUG（当然存在这种想法的开发人员也很少），另一个则是开发人员很想让测试人员帮自己纠错！

　　这次我们几个测试人员要和开发人员急了！BUG太多，每个工作流都走得举步维艰！

　　平时在公司很自由，开发在二楼，测试在三楼，上个月看需求，写测试需求和测试用例，过得挺安逸！搞不明白的地方就直接打电话给项目经理及其他两位带头人！很少正面和开发人员接触！我们测试团队的老大说任何需求上有疑问处和那三位负责需求的人商量，不要问开发人员！

　　现在项目进行到封闭阶段，集成测试，和开发人员坐一起面对面办公，改变了以往的平静！

　　我们测试团队到后，项目经理就让我们尽快展开工作，发挥我们的找BUG的作用！呵呵！

　　幸福的是这次给我配置了一台新的电脑（台式），配置较高，速度挺快！不幸的是我的机器同时作为服务器，多的时候会有十几个人连我的机器！

　　项目紧，清明节前要先交给客户一个版本看看！但是现在我们用测试版，流程都走不通！每进行一步都会发现BUG！模块之间的嵌套有些复杂！想把整个流程走通还是很难！

　　和他们开发人员讲赶紧把某某BUG改了，他们也是不断地到我的机器上查看数据库！找到源头，发现问题，然后去改！但有时大家会都比较忙，有点混乱，和他们说了当是没说！昨天项目经理对开发人的机器实行了物理隔离！我们和开发人员之间虽然面对面坐着，但是想传个什么文件都还要用U盘来拷贝！估计下一步要给我们测试机也断网了！这样大家交流又会困难些！

　　一个同事气急之下和旁边的开发人员说“我不测了，你先改吧，等改好了我再测！”我们几个异口同声“支持”！呵呵！他们开发人员也报以很无奈的表情！只好和她说好话，大家好好商量！

　　中午大家在一块匆匆吃过饭，项目经理招呼大家去休息会，几个开发人员说哪能睡得着！又回去工作！中午搭载我那台服务器，也和他们一块劳作！

　　有时候会很急的是和他们说的问题改不了，想测试下一个流程无法进行，或者是他们修改的效率很低，耽误我们测试的进展！但是他们说我们测试团队的人很细心，也表示很感谢！既然开发人员都这么说了，我们测试团队成员也得稍微大度一些，得控制一下情绪了！时间赶得紧，有些环节没安排太好，也要大家共同相互理解一下了！一位项目指导人和我聊天时说现在他们的编程能力已经有很大的提高了，问问题的质量也高了很多！

　　测试团队和开发毕竟还是一个团队，还是和谐相处吧，有时偶尔虽然会有些哭笑不得！呵呵！

程序员应知——关注细节

　曾经有一句话，叫做“细节决定成败”，充分说明了细节对于成功的作用。如果我们注意一下，就会发现很多因为注重细节而获得成功的案例。

　　产品的细节

　　苹果的系列产品我们都已经非常熟悉了，各种各样i打头的产品，对于细节已经给予了非常大的关注。尤其体现明显的就是在对用户使用的友好度和便利性方面的细节。iPad、iPhone和iTouch等产品都是大大的屏幕，而在正面就只有一个按钮，用户不必考虑到底需要按什么按钮。而系列产品的做工更是让人赞不绝口，这也是另外一个细节。

　　另外对于国内的电子书产品，bambook我感觉细节做得也很不错，首先所使用的硬件质量都很好，我已经用了快一年的时间了，每个按钮还和刚拥有的时候一样灵活；电池也一直非常耐用，充一次电基本上可以至少用大半个月，这还是因为我几乎每天上下班的路上都会使用它来看书。曾经在使用的时候遇到一位用汉王产品的人，和我抱怨那款电子书的问题，首先就是按钮，没用两个月就坏掉了；还有电池，刚开始的时候能撑一个多月，但不长时间之后，就只能撑几天了。按钮、电池，看起来都是很细节的东西，但确实直接影响到了用户的体验，从而影响了用户对于产品乃至于企业的印象。

　　服务的细节

　　以上说的是产品，对于服务也是一样，同样需要关注细节。最近一段时间最火的饭店应该就是“海底捞”了，有无数的故事让人来传说，其实他们的服务充分体现了关注细节这一特点，不仅仅是产品的质量，更包括了服务的质量，他们能够关注于客户的各种反应，从而做出让人最满意的服务，那样才获得了巨大的成功。尽管说“海底捞你学不会”，但我们至少可以学习他们关注细节这一点，呵呵。

　　程序员要关注细节

　　作为程序员，我们的工作有很多，一方面需要创造出各种系统，编写各种程序，制造各种产出物；另一方面要和客户沟通，为最终的业务用户服务。无论哪个方面，我们都需要关注细节，那样才能够把工作做得更好。

　　在创建产品方面，我想我们可以做的有：

　　● 所有程序外观、使用方式统一，从而让用户更容易地学习和使用

　　● 程序代码遵守规范，便于维护和修改

　　● 各种功能使用简单，程序帮助用户做尽可能多的事儿

　　● 协助用户改进不合理的工作方式，帮助用户提高工作效率

　　● ……

　　其实这还比较笼统，更细节的问题可能会是：

　　● 界面上的文字是否有错别字？

　　● 文字的大小、颜色是否符合规范？

　　● 各种提示信息是否规范，是否真正有助于用户发现并解决问题？

　　● 代码中的注释是否必要，是否能够正确地为代码提供补充说明？

　　● ……

　　如果能够做到关注细节，那么不管是对于用户，还是团队中的其他开发人员来说，我们所体现出来的就是一种专业的精神和专业的态度。