qileilove

　　为什么那个清单很糟糕

　　1、他的力气没使对地方

　　我们要遵循的一个准则就是如果你要优化代码时，应该先找出瓶颈在哪。然而Silverton先生的力气没有用对地方。我认为60%的优化是基于清楚理解SQL和数据库基 础的。你需要知道join和子查询的区别，列索引，以及如何将数据规范化等等。另外的35%的优化是需要清楚数据库选择时的性能表现，例如 COUNT（*）可能很快也可能很慢，要看你选用什么数据库引擎。还有一些其他要考虑的因素，例如数据库在什么时候不用缓存，什么时候存在硬盘上而不存在 内存中，什么时候数据库创建临时表等等。剩下的5%就很少会有人碰到了，但Silverton先生恰好在这上面花了大量的时间。我从来就没用过 SQL_SAMLL_RESULT。

　　2、很好的问题，但是很糟糕的解决方法

　　 Silverton先生提出了一些很好的问题。MySQL针对长度可变的列如TEXT或BLOB，将会使用动态行格式（dynamic row format），这意味着排序将在硬盘上进行。我们的方法不是要回避这些数据类型，而是将这些数据类型从原来的表中分离开，放入另外一个表中。下面的 schema可以说明这个想法：

　　3、有点匪夷所思……

　 　他的许多建议都是让人非常吃惊的，譬如“移除不必要的括号”。你这样写SELECT * FROM posts WHERE （author_id = 5 AND published = 1），还是这样写SELECT * FROM posts WHERE author_id = 5 AND published = 1 ，都不重要。任何比较好的DBMS都会自动进行识别做出处理。这种细节就好像C语言中是i++快些还是++i快些。真的，如果你把精力都花在这上面了，那 就不用写代码了。

　　我的列表

　　看看我的列表是不是更好吧。我先从最普遍的开始。

　　1、建立基准，建立基准，建立基准！

　　如果需要做决定的话，我们需要数据说话。什么样的查询是最糟的？瓶颈在哪？我什么情况下会写出糟糕的查询？基准测试可以让你模拟高压情况，然后借助性能测评工具，可以让你发现数据库配置中的错误。这样的工具有supersmack， ab， SysBench。这些工具可以直接测试你的数据库（譬如supersmack），或者模拟网络流量（譬如ab）。

　　2、性能测试，性能测试，性能测试！

　　那么，当你能够建立一些高压情况之后，你需要找出配置中的错误。这就是性能测评工具可以帮你做的了。它可以帮你发现配置中的瓶颈，不论是在内存中，CPU中，网络中，硬盘I/O，或者是以上皆有。

　　你要做的第一件事就是开启慢查询日志（slow query log），装上mtop。这样你就能获取那些恶意的入侵者的信息了。有需要运行10秒的查询语句正在破坏你的应用程序吗？这些家伙会展示给你看他的查询语句是怎么写的。

　 　在你发现那些很慢的查询语句后，你需要用MySQL自带的工具，如EXPLAIN，SHOW STATUS，SHOW PROCESSLIST。它们会告诉你资源都消耗在哪了，查询语句的缺陷在哪，譬如一个有三次join子查询的查询语句是否在内存中进行排序，还是在硬盘 上进行。当然你也应该使用测评工具如top，procinfo，vmstat等等获取更多系统性能信息。

　　在你开始写查询语句之前，你需要设计schema。记住将一个表装入内存所需要的空间大概是行数*一行的大小。除非你觉得世界上的每个人都会在 你的网站注册2兆8000亿次的话，否则你不需要采用BITINT作为你的user_id。同样的，如果一个文本列是固定大小的话（譬如US邮编，通常 是”XXXXX-XXXX”的形式），采用VARCHAR的话会给每行增加多余的字节。

　　有些人对数据库规范化不以为意，他们说这样会形成相当复杂的schema。然而适当的规范化会减少化冗余数据。（适当的规范化）就意味着牺牲少 许性能，换取整体上更少的footprint，这种性能换取内存在计算机科学中是很常见的。最好的方法是IMO，就是开始先规范化，之后如果性能需要的 话，再反规范化。你的数据库将会更逻辑化，你也不用过早的进行优化。（译者注，这一段我不是很理解，可能翻译错了，欢迎纠正。）

　　4、拆分你的表

　　通常有些表只有一些列你是经常需要更新的。例如对于一个博客，你需要在许多不同地方显示标题（如最近的文章列表），只在某个特定页显示概要或者全文。水平垂直拆分是很有帮助的：

　　artificial key完全是多余的，而且post-tag关系的数量将会受到整形数据的系统最大值的限制。

　　6、学习索引

　　你选择的索引的好坏很重要，不好的话可能破坏数据库。对那些还没有在数据库学习很深入的人来说，索引可以看作是就是hash排序。例如如果我们 用查询语句SELECT * FROM users WHERE last_name = ‘Goldstein’，而last_name没有索引的话，那么DBMS将会查询每一行，看看是否等于“Goldstein”。索引通常是B- tree（还有其他的类型），可以加快比较的速度。

　　你需要给你要select，group，order，join的列加上索引。显然每个索引所需的空间正比于表的行数，所以越多的索引将会占用更 多的内存。而且写数据时，索引也会有影响，因为每次写数据时都会更新对应的索引。你需要取一个平衡点，取决每个系统和实施代码的需要。

　　7、SQL不是C

　　C是经典的过程语言，对于一个程序员来说，C语言也是个陷阱，使你错误的以为SQL也是一种过程语言（当然SQL也不是功能语言也不是面向对象的）。你不要想象对数据进行操作，而是要想象有一组数据，以及它们之间的关系。经常使用子查询时会出现错误的用法。

　　8、理解你的引擎

　　MySQL有两种存储引擎：MyISAM和InnoDB。它们分别有自己的性能特点和考虑因素。总体来讲，MyISAM适合读数据很多的情况，InnoDB适合写数据很多的情况，但也有很多情况下正好相反。最大的区别是它们如何处理COUNT函数。

　　MyISAM缓存有表meta-data，如行数。这就意味着，COUNT(*)对于一个结构很好的查询是不需要消耗多少资源的。然后对于 InnoDB来说，就没有这种缓存。举个例子，我们要对一个查询来分页，假设你有这样一个语句SELECT * FROM users LIMIT 5，10，而运行SELECT COUNT(*) FROM users LIMIT 5，10 时，对于MyISAM很快完成，而对InnoDB就需要和第一个语句相同的时间。MySQL有个SQL_CALC_FOUND_ROWS选项，可以告诉 InnoDB运行查询语句时就计算行数，之后再从SELECT FOUND_ROWS()来获取。这是MySQL特有的。但使用InnoDB有时候是非常必要的，你可以获得一些功能（如行锁定，stord procedure等）。

　　9、MySQL特定的快捷键

　　MySQL提供了许多扩展，方便使用。譬如INSERT … SELECT， INSERT … ON DUPLICATE KEY UPDATE， 以及REPLACE。

　　我能用到它们时是毫不犹豫的，因为它们很方便，能在许多情况下发挥不错的效果。但是MySQL也有一些危险的关键字，应该少用。例如 INSERT DELAYED，它告诉MySQL不需要立即插入数据(例如在写日志的时候)。但问题是如果在很高数据量的情况下，插入可能会被无限期延迟，导致插入队列 爆满。你也可以使用MySQL的索引提示来指出哪些索引是需要使用的。MySQL大部分时间运行是不错的，但如果schema设计不好的话或语句写得不好 的话，MySQL的表现可能很糟糕。

　　10、到这里为止吧

　　最后，如果你关心MySQL性能优化的话，请阅读Peter Zaitsev的关于MySQL性能的博客，他写了许多关于数据库管理和优化的博客。

　 　不过，我们以前熟悉测试中的错误猜测法、Ad hoc测试等方法，不管Cem Kaner承认不承认，ET概念很有可能来源于这些先前的概念，在这些概念的基础上丰富它，试图给ET建立一个比较系统的体系，例如引入基于上下文驱动 （Context-driven）、基于session的测试等。想当初，我们用错误猜测法、Ad hoc测试方法时，一定也会考虑业务或功能的上下文关系，没有上下文还做什么测试？也会考虑某些场景，更多会考虑一些特别的场景，如人们常说的 corner case，right？ 当然，ET和错误猜测法、Ad hoc测试是有区别的。

　　谈谈探索式测试与基于脚本的测试（Script-base Test 或 Scripted Testing，ST）之关系，不论是在传统测试流程还是在敏捷测试中， 这两者是相辅相成的，谁也不能代替谁，正如James Bach也谈到“Balancing Exploratory Testing with Scripted Testing，... two approaches to testing are fully compatible” 。而且在不同的场景有各自的优势，例如：

　　● 发现问题来看，探索式测试效率会更高些，甚至高得多；

　　● 测试乐趣看，也会优先选择探索式测试；

　　● 敏捷中新功能测试会选择探索式测试；

　　● 探索式测试不易实现自动化，所以自动化测试先需要脚本，然后执行；

　　● 归测试比较确定，需要不断运行，自然会选择基于脚本的测试（ST）；

　　● 产品线来看，开发周期长，复用会大大提高效率，ST也具有很大优势。

　　所以，在一个项目中，经常是同时采用这两种方法——ST和ET，而且不同的组织环境或项目环境，随时间的投入是不一样的，这就是那两条神奇的曲线：

　　当初我没有在线上标ST和ET，就是因为每根线都可能是ET或ST，例如：

　　1、如果自动化测试水平低或没有自动化测试，就需要在前期有更多的ET，在发现产品问题的同时学习产品、更深地理解产品，并通过发现问题来完善测试用例。而为了降低产品质量风险，后期需要进行更系统的测试，特别是要完成大量回归测试、对产品质量有一个完整的评估，需要执行ST。由于自动化水平低，这时人力都投在ST上，就没有经历做ET，而且也不必要。

　　2、如果自动化水平高，前期需要开发脚本，ST的投入自然大。但自动化执行时，虽然会运行大量用例，但解放了生产力，测试人员有更多时间投入ET。

　　实际环境所处的场景会更多，不管怎样，先要清楚自己测试工作中有什么问题，然后采用合适的方法来解决问题。或者说，要清楚自己的目标，是让团队获得激情还是让公司处在稳定的不败之地、还是为了尽快发现Bug还是提高产品的质量，方法何时使用、如何使用、谁使用等都可能不同。即先问Why？What？然后才考虑How、Who、Where？

　　关于探索式测试和脚本测试还有许多东西可以谈，时间关系，今天就谈到这里。

　　出自：http://blog.csdn.net/kerryzhu/article/details/7489319

　　自动化测试的现状

　　自动化测试的发展

　　1、包含的领域

　　2、发展的思路

　　3、观点： 自动化测试是一种软件开发交付过程

　　自动化测试成败在于自动化项目的质量与可维护性

　　自动化测试不只是测试的自动化，应当是流程的自动化

　　自动化的难点：

　　1、极强的定制性使得引入自动化成为难事

　　2、预言性的需求设计使得自动化需求变化极快，同时要求开发周期越短越好

　　3、软件流程往往成为自动化道路中的拌脚石

　　我在自动化测试的计划

　　未来的自动化测试在哪里？

　　引用

　　我在这个领域不长时间，算上入手开始到现在，大概有1年半有余。一直有一种想分享一些想法的冲动，然而总是感觉时机不成熟，毕竟这个领域在中国是新兴的，而我也是一种新入门的感觉，然而，测试领域的混乱状态与最近越来越清晰的思想使得我也借Ruby大会后的时间梳理一下我的想法。

　　自动化测试包含的理念是什么？

　　看了许多51testing上的文章贴子，很多人对此不清楚，我想简单几句表达下我的观点。

　 　为什么出现自动化测试？ 因为手工测试效率低下，回归成本高昂，许多在前期应当控制的代码质量由于手工测试介入过晚导致测试成本过高。 自动化测试的出现要求提高整体测试效率，极大降低回归成本，通过单元自动化，接口自动化，自动化代码检视，编译自动化构建，冒烟构建等立体动态的方案从而 可以尽早从测试手段控制版本开发质量，降低后续测试成本，并快速集成回归。

　　我想提供一个图看下变化过程：

　　这是一个传统的，也是我们一般人使用的软件开发模式，国外有个好听的名字： 瀑布开发模式（你坚着看，很形象吧？）

　　而自动化测试应当提供什么呢？

　　看下图：

　　我们今天不讨论敏捷，这里的自动化模式是基本不改变开发模式的方式下的开展过程。（我想大部分公司很难强推行大规模的开发模式转变：大部分原因被冠名风险与人）

　　这个图是以自动化云层（叫平台也行）依靠，提供全方面的自动化测试过程。

　　● 自动化测试的手段： 以自动化测试代码为依托，提高高可用的测试方案与立体的测试体系。

　　● 自动化测试的目的： 让软件测试无事可做！

　　也许较真的兄弟们会说，软件测试覆盖的面可多了，黑盒，模糊，场景，发散等，你怎么取代？ 我说的测试工作是特指我们平时花费最长最无味的系统测试。

　　解释了自动化测试的所在的领域与基本理念后，下一个问题，

　　如何发展？

　　这里就我在工作过程中的一些思路谈一谈，我们知道自动化测试不具备通用性，明白这点很重要。我再解释下，假如你在华为的路由器测试，你会使用cli操作命令进行自动化，你的平台很可能依托在复杂的资源管理平台上。

　　而如果你在人人，你会使用selenium等UI工具进行自动化，你可能直接使用了selenium与hudson作集成自动化。

　　如果你是做企业金融的公司，你会使用flash测试工具，autoit，甚至商业化的RFT等

　　另外，自动化还有一个特点，投入成本高，产出可能很缓慢。 如果你在预算投入不足时，千万不要貌然启动自动化，不要对其报有任何幻想。

　　如果明白这两点，你们公司应该会成立专门的自动化团队了，并且逐步的形成自动化测试的框架与相关的自动化效果产出了。

　　最后我想重点谈谈技术在自动化测试发展中的作用。

　　● 问题一： 选择商业工具还是自主开发？ 商业工具一般很强大，常见的如QTP，RFT，Robot，SilkTest等，并且带有脚本录制与快速回放。那我们直接选好了？

　　No，我的建议是不要去选，至少不要轻易的去选，并不是说你家有钱不让你去花，因为要知道，自动化测试不具备通用性，我们的产品很难说能适应测试工具，而是应该让工具去适应产品。

　　自主开发？ No，我的建议也是No，世界上有一批优秀的程序员（测试员），他们开发了一批优秀的开发的自动化工具供我们使用，我们只需要动动手，整合一个框架出来就 ok了。 你会担心，谁帮我维护？有bug找谁？ 你要记住，如果你的技术不足于达到维护这个自动化测试工具时，你的自动化测试基本也宣告失败了，那么，发现bug提交给相关社区，或者自己去修改并 push请求。达到技术共享的目的。

　　Java代码

　　● 问题二： 先开发框架还是先作自动化项目？ 有些人上来就想做一套框架搞自动化，生怕技术生锈了，实际上我的建议是：

　　先有自动化测试代码，形成简单的结果报告，代码复用规范，将自动化效果展示出来。

　　第二步摸清需求后，进而设计一套合适的框架，这里可充分利用开源的优势，一个技术好的人甚至花不超过1周可搞定一个框架。我们的ATT框架当时 仅花费了20*3人天完成。（一套关键字驱动框架，目前还没有开源） 另外一个单元级框架花费3天完成，具备脚本规范，日志输出，等作用。

　　第三步，设计框架要考虑可扩展性，要有预言性的设计在里面，比如ATT框架对外的接口是一个xmlrpc协议的接口，后来我们花了半年开发了平台管理项目，与ATT框架完美对接。

　　最后，从流程上对自动化云层进行整合，梳理各项流程点，把能够简化的流程步骤全部由云层处理。（就像乔布斯那样把iphone的开关都去掉了，因为实在对用户没有必要）

　　我就简单总结下，

　　1、技术上不要求太精，但一定要广，并且对新技术具备很高的热情，我以后如果去面试，会第一个问题问，是否在业余时间开发过项目，如果用到了rails，erlang，云技术，甚至喜欢研究flex，敏捷，那么是我的首选。

　　2、创新思维，凡事不是第一感觉为否定，而是用研究来验证自己的想法是否可行，能否做到把不可能自动化的东西也自动化掉。

　　3、团队交流与协助，这点不用多说了。

　　4、改进意识，不甘于不断的重复工作，如果没有这点就没有自动化。

　　当然，这样的人有少量就够了。

　　最后就我的里程，作一个回顾，也会以上理论的东西作一个实质的归纳，就当听听故事吧

　　大学玩了一半学了一半，学业成绩称不上优秀，但也算不错。（至少没有挂课~）

　　毕业的时候，我直接投了深圳这边公司的简历，当时当然是一心投的开发职位，然而，对开发倒是一种不舒服的感觉，因为毕业设计的时候设计的那个邮件服务器始终存在一个bug，让我决定可以试试测试职位，最终通过了现在的公司的面试。（ 主要是动手能力强， 嘿嘿）

　　随便说一下，当时腾讯来过，我去面准备不足（第一次面），直接被一面bs，我就暗下决心，你bs我，我就以后bs你，所以现在听有人进了腾讯，我就不由分说bs一番。（现在只是说说了，虽然心里知道它现在的霸主地位） 等我以后再真正bs你吧。

　　那时候，华为还没有过来，但早就听说华为的速度（无论面试还是offer）最慢，我是那种不喜欢条条框框的人，直接不等它了。

　　进了公司后，开始做测试，我的性格里只有两种事情划分，要么做好做么不做，开始的测试工作还是蛮有意思的，学习也真的很快，期间也收获了同事们 的认可，然而时间一长，测试的重复工作和无力的成就感使得我不得不重新考虑以后的计划，以后的几天，我向我导师反映了我的心态与计划，转岗or离开。 然而，在那时候我坚持了下来，半年后我们的测试主管确定成立自动化测试部，在10年4月的某一天，我全职投入自动化，从基本上是零一直到现在。

　　因为公司的自动化发展特殊性，我们的自动化投入基本上是：

　　投入自动化项目 -> review效果 -> 剥离框架 -> 投入自动化项目

　　目前效果产出比较明显，好几个版本ROI超过了2，直逼3。 在这里我建议投入的项目是：

　　基本功能bvt -> 易于实现的自动化功能 -> 提高部分模块自动化率， 期间不断优化框架与平台，整合出我们的自动化云端。

　　目前我们有5个人全职自动化，马上会有新人继续加入。

　　写在这里，这篇已经很长了，接下来就自动化实施的难点加以分析与说明。为自己留下些成长中途的记忆。

　在前述的文章中对独立测试无用论做了“激烈”的回击，支持者有之，反对者有之，总之能引起大家的思考就好。这篇我打算写温和一点的内容，那就是，反向思考，为什么有些独立测试不招人待见？如果从独立测试工程师自身出发，我们应该如何避免做“庸俗”的测试工程师？以下是观点：

　　1、做发动机，不做拖油瓶。

　　当码农那年，刚开始进一项目，对面的核心开发就开始被一个测试大哥“骚扰”，此测试大哥言谈高调，目光如炬，最善发现类似页面俩空格只有一个，俩输入框不该在一行这类问题。

　　发现UI错误本身没错，确实现在好多页面的界面也够呛。但是，哥，咱们是在项目的前期啊，开发脑子里都是核心业务如何实现，三个表四百个字段怎么高效操作，你确定他们该停下来改UI吗？

　　UI是重要，UAT（客户验收测试）之前抽个几天就可以做出很大改进，不是吗？

　　团队利益的核心是什么？按时交付。而测试人员的价值是：项目高质量交付。那么团队利益和测试利益在根本上就可能冲突。这还怎么一块过？......其实也能过。男人的价值观和女人还不一样呢，那么多两口子不也一过一辈子。

　　所以，后来做测试经理和团队负责人时，在项目前期，都要求测试人员提高对这类UI、易用性缺陷的容忍度，这么做有两个好处：

　　第一， 开发和测试在前期不会因为这些问题争执不下，前提是，开发人员必须耐心的给核心测试讲清楚，现在重要的是什么。小问题不一定不重要，什么时候你准备把这些东西拾起来？

　　第二， 测试人员避免心理收到打击：为什么我辛苦测试出来的bug没人重视。在这种时候，耐心的把项目的情况解释清楚，测试人员一般都会接收团队价值。

　　不做拖油瓶测试，核心的要求就是：你得知道项目处于什么阶段，最大的风险是什么，该做什么不该做什么，不该做的什么时候捡起来做。

　　在最极端情况下，测试组的结论是“产品质量是狗屎，不能发布”，但是项目经理的要求是“一定要发布，除非从老子尸体上踩过去”，那怎么办？

　　三国中关羽失荆州被杀，刘备大怒准备伐吴，诸葛亮劝谏不可，刘备不听，最后果然刘备大败。

　　大概，项目经理有更高的诉求，测试所为，只能是把情况列出，含泪再拉一把：主公，我们还是准备准备在Release吧…Orz

　　现实就是这样，决策就有风险，测试就是提供决策支持，至于听不听，结局如何，只能让历史去评说了。

　　PS： 文中那位测试大哥，真心不适合做测试，适合去当公务员，当那个圈儿的人，最后他还真去事业单位了。

　　2、做谢耳朵，不做软耳朵。

　　以前面试测试工程师的时候，很喜欢问一个问题，如果你提的bug，开发人员激烈反对，你怎么办？

　　注意！这个问题没有标准答案。只是想通过测试人员的回答检验他们对于反对意见的处理方式。

　　软耳朵测试要不得：开发说这不是bug，这是特性，好吧那就是特性；开发说这是你用的方式不对，好吧那就是方式不对；开发说这是你点鼠标的姿势不对，好吧那就是姿势不对；开发说测试没技术含量，好吧那就是没技术含量；开发说不需要测试，好吧那就不需要测试！

　　拜托，拿着这样的测试人员写出来的报告，你晚上能放心的睡觉？

　　个人喜欢有点小强迫症的测试工程师：不能复现的一定想办法复现；开发不接受的一定要据理力争，真理是越辩越明。

　　看生活大爆炸吗？里面的谢耳朵最多人喜欢，他有时候够讨厌，但是他的观点很多时候也最有价值，不是吗。

　　在本篇文章中，我们将集中介绍一些方法，来帮助你在你的环境中使用并确保IIS7服务器和其应用程序的安全。

　　1、第一步，确保你的Web服务器是强化的OS操作系统。如果你使用的是Windows Server 2008 R2的操作系统，那么服务器核心安装版本会给你需要的——所有功能，但不能降低被攻击的风险。如果你正在使用常规版本的Windows Server，可以试着安装IIS，它只是作用于你目前所需要的装置。根据你的需要，也可以恢复或者安装更多你所需要的功能。注意，当你添加了，你不使用的装置时，这会使你受到的攻击范围扩大。

　　2、使用防火墙可以真正帮助你保护WEB服务器，尤其是面向互联网的服务器。防火墙能确保服务器只接收有效的有服务的封包。当外部袭击者试图对你的服务器进行恶意攻击时，防火墙就是你的第一道防线。使用入侵预防系统（IPS），可以进一步保障你的系统，尤其是IIS服务器。 如果你的系统不是很大，不需要装特定的硬件防火墙装置时，你也可以利用Windows Server 2008的综合防火墙同样可以获得较好的安全性。

　　3、用IIS7控制ip和域限制访问你WEB服务器的内容。 例如，你可以只授权组织内部域的访问。或者添加除合作伙伴以外，管理员家里的IP地址，老板或其他任何你希望可以访问的组织或者个人。

　　4、IIS7可让你更好的过滤需要处理的，需要过滤的信息。利用这一特点你可以对特定规则要求过滤，例如处理带有特定扩展名的文件，或者处理在URL中的特定短语。

　　5、当一个有效的包进入IIS处理时，同时也应该会有一个授权的人。IIS7允许你使用一个过程调用 URL授权。 特定的页面和/或Web服务器的网站，可以授权给不同的用户。默认情况下，用户应首先验证自己，并根据其验证身份，然后允许或不允许进入他们所要求的网页/网站。这与之前ISS版本不同，管理员可设置文件系统级别上的权限。使用URL授权IIS7的方式来支持更详细的授权用户。

　　6、确保你的IIS服务器的最佳方法之一是通过使用有证书的SSL通信在用户和Web服务器之间。如果服务器是公开使用的，你应该要从GoDaddy或Verisign这样的受信任的证书颁发机构颁发的证书。这个证书在任何浏览器上，在任何一台电脑上，都是可信任的，也是最容易的，但是使用SSL的缺点就是价格较高。如果IIS服务器只在你的组织内部使用，你可以使用自己的PKI证书发出的Web服务器，在你所处的环境。但是，内部用户访问时可能存在，在不同的电脑上没有安装证书的计算机访问会出现问题。如果你的IIS服务器只在测试环境中使用，那么你可以在ISS管理工具中，使用自签名的证书。在以前的ISS版本中没有集成这一功能，你必须从微软下载一个工具来创造自己的签名证书，而在IIS7中，这个过程就容易多了。

　　7、日志 是一个让你最有保障的方法。它可帮助你搜索攻击源或者一个服务器损坏的原因。从一开始就确保你的设置，并在危机关头协助你的监测工作。

　　8、如果你感觉你的IIS基础设施和所有的安全解决方案已经没有问题的话，那么就要进行测试了。使用测试工具微软会提供给你大师级的策略来确保你的测试是最好的方法。 做测试最常用的工具是SCW和SCM。下面就来介绍一下：安全配置向导（SCW）——这是根据你的服务器除IIS服务器之外，是否或者还扮演一些其他的角色，而有所不同。 测试结束后SCW会告诉你如何提高服务器安全性的报告和建议。安全合规管理器（SCM）-是微软给你的服务器做安全测试的工具。在与配置服务器的预定义模板进行对比后，通过改变使用策略来配置服务器。SCM使用更新过的数据库工具，要比SCW所使用的工具更复杂。从而确保你定期进行初始化安装服务器后能运行这些工具。

　　9、上面提到了有关IIS日志记录功能的作用，但日志最重要的作用是为你监视特定事件可能导致服务器或托管的应用程序中存在的问题。同样重要的是为你监控服务器本身的运行时间，可用性和性能问题。 也可以监控IIS服务器的一个SLA协议的对象，无论是内部（公司）或外部（客户端）的SLA要求。 理论上，这种监测可以由一个服务器管理员手动完成，但要更高效、更可靠的话可把这种工作，交给像Monitis的监测公司解决。

　说到存储过程和触发器，其实在以前做机房收费系统的时候就接触到了。但是当时总感觉存储过程和触发器是比较高级的东西，这个系统不用这些东西也可以。于是就一直没有好好研究这块知识。现在看牛腩新闻发布系统，再一次涉及到了这个东东，这才发现，存储过程和触发器并没有想象的那么高深莫测。也许有人会说：那是你没有深入研究。是，我承认，但个人觉得目前我们还没有必要那么深入研究。我们要做的就是：用20%的努力，获得80%的知识。这样就基本上可以满足我们日常的需求了。下面就宏观上说一下存储过程和触发器。

　　什么是存储过程呢？官方是这样定义的，存储过程（Stored Procedure）是在大型数据库系统中，一组为了完成特定功能的SQL语句集，经编译后存储在数据库中，用户通过指定存储过程的名字并给出参数（如果该存储过程带有参数）来执行它。

　　1、创建存储过程语句如下：

　　2、调用存储过程

　　exec sp_name [参数名]

　　3、删除存储过程

　　drop proceduresp_name

　　其实，说白了，存储过程就是一类特殊的函数，只要我们给它合适的参数就可以直接调用，跟调用API函数差不多，唯一不同的就是API函数大部分是别人写的，而存储过程我们一般都是自己写。

　　注意：不能在一个存储过程中删除另一个存储过程，只能调用另一个存储过程。

　　那么什么是触发器呢？严格意思上说，触发器就是存储过程，只不过它的执行不是由程序调用，也不是手工启动，而是由事件来触发。

　　创建语句如下：

　　这时有人不解了，什么叫由事件来触发呢？其实这和botton按钮的点击事件一样，只不过触发器是由Insert、Update、Delete这些动作触发，而botton的点击事件是通过点击的动作来触发的。

　　那么存储过程有哪些优点呢？

　　1、速度快。

　　在运行存储过程前，数据库已对其进行了语法和句法分析，并给出了优化执行方案。也就是说，存储过程在调用前就已经编译好了，所以存储过程能以极快的速度执行。

　　2、存储过程可以重复使用，可减少数据库开发人员的工作量 。

　　3、保证数据的安全性。

　　通过存储过程可以使没有权限的用户在控制之下间接地存取数据库，从而保证数据的安全。

　　4、保证数据的完整性。

　　通过存储过程可以使相关的动作在一起发生，从而可以维护数据库的完整性。

　　既然存储过程有如此多的好处，那么我们做项目的时候是不是用的越多越好呢？答案肯定是NO。万事都有个度，存储过程也一样。如果在一个程序系统中大量的使用存储过程，那么必然会导致它的数据结构相当复杂，这样维护该系统将会是相当困难的一件事。

　　让我们合理使用触发器和存储过程，尽情享受他们带给我们的方便。