发布新日志

  • Oracle数据库中四大应用服务之间的密切关系

    2011-03-14 13:36:41

    本文主要是对Oracle数据库中service_name、tablespace、schema、user四者之间的关系一些分析与实际应用中的举例。
    　　首先简单总结一下：
    　　1. service name 服务名(其实揍是：数据库名)，装 ORACLE 时肯定要指定的一个名字
    　　2. tablespace 表空间，数据库对象的磁盘存储位置
    　　3. schema 方案，数据库对象的逻辑分类
    　　4. user 用户，等同于 schema
    　　5. service name > tablespace > schema(user)
    　　详细说明：
    　　schema 为数据库对象的集合，为了区分各个集合，我们需要给这个集合起个名字，这些名字就是我们在企业管理器的 schema 下看到的许多类似用户名的节点，这些类似用户名的节点其实就是一个schema，schema 里面包含了各种对象如：tables，views，sequences，stored procedures，synonyms，indexes，clusters，and database links。
    　　一个用户(user) 一般对应一个 schema，该用户的 schema 名等于用户名，并作为该用户缺省的 schema。这也就是我们在企业管理器的 schema 下看到 schema 名都为数据库用户名的原因。Oracle 数据库中不能新创建一个 schema，要想创建一个 schema，只能通过创建一个 user 的方法解决(Oracle 中虽然有 create schema 语句，但是它并不是用来创建一个 schema 的)，在创建一个 user 的同时为这个 user 创建一个与用户名同名的 schem 并作为该用户的缺省 shcema。即 schema 的个数同 user 的个数相同，而且 schema 名字同 user 名字一一对应并且相同，所有我们可以称 schema 为 user 的别名，虽然这样说并不准确，但是更容易理解一些。
    　　一个 user 有一个缺省的 schema，其 schema 名就等于用户名，当然一个 user 还可以使用其他的 schema。如果我们访问一个表时，没有指明该表属于哪一个 schema 中的，系统就会自动给我们在表上加上缺省的 sheman 名。比如我们在访问数据库时，访问 scott 用户下的 emp 表，通过select * from emp; 其实，这 sql 语句的完整写法为 select * from scott.emp。在数据库中一个对象的完整名称为 schema.object，而不属 user.object。类似如果我们在创建对象时不指定该对象的 schema，在该对象的 schema 为 user 的缺省 schema。这就像一个 user 有一个缺省的 tablespace，但是该 user 还可以使用其他的 tablespace，如果我们在创建对象时不指定 tablespace，则对象存储在缺省 tablespace 中，要想让对象存储在其他 tablespace 中，我们需要在创建对象时指定该对象的 tablespace。
    　　举例如下：
    Vb代码
    1. SQL> Gruant dba to scott   
    2. SQL> create table test(name char(10));   
    3. Table created.   
    4. SQL> create table system.test(name char(10));   
    5. Table created.   
    6. SQL> insert into test values('scott');   
    7. 1 row created.   
    8. SQL> insert into system.test values('system');   
    9. 1 row created.   
    10. SQL> commit;   
    11. Commit complete.   
    12. SQL> conn system/manager   
    13. Connected.   
    14. SQL> select * from test;   
    15. NAME   
    16. ----------   
    17. system   
    18. SQL> ALTER SESSION SET CURRENT_SCHEMA = scott; --改变用户缺省schema名   
    19. Session altered.   
    20. SQL> select * from test;   
    21. NAME   
    22. ----------   
    23. scott   
    24. SQL> select owner ,table_name from dba_tables where table_name=upper('test');   
    25. OWNER TABLE_NAME   
    26. ------------------------------ ------------------------------   
    27. SCOTT TEST   
    28. SYSTEM TEST  
    29.   ------------------------------ ------------------------------   

    　　--上面这个查询就是将 schema 作为 user 的别名的依据。实际上在使用上，shcema 与 user 完全一样，没有什么区别，在出现 schema 名的地方也可以出现 user 名。

    　　schema 和 user 一般是一致的，建立一个 user 后即可得到一个 schema，如：HR 用户建立后便有 HR 方案，接下来建立表、索引等数据库对象时，要指定其属于哪个 schema，也要指定其存放在哪个 tablespace 里。

    　　也可以这样理解，schema 是数据库对象的逻辑归属和分类，而 tablespace 是数据库对象的物理和实际存放位置。

    原文出处：http：//tech.ccidnet.com/art/1107/20100720/2121277_1.html

    查看(487) 评论(0) 收藏 分享 管理

  • CMMI基础知识扫盲

    2009-05-04 12:06:41

    CMMI基础知识扫盲

    作者：张传波

    摘自：http://www.cmmionline.net

    摘要：

    CMMI全称是Capability Maturity Model Integration，CMMI是个好东西来的，但行内人士对她的认识并不全面，甚至有种种的误解。尽管网上有很多CMMI相关介绍，但一般都是比较苦涩难懂的。本文将用生动通俗的语句，让大家初步看清楚CMMI的真面面孔。

     

    CMMI是什么东西？

    CMMI英文全称是Capability Maturity Model Integration，直接翻译就是能力成熟度模型，直接看这几个中文字，你还是没有办法搞清楚CMMI是什么东西的。

    大家可能在网上见过很多《成功人士的七个习惯》（可能还有很多类似的名字）的文章吧？有人总结了成功人士的成功的原因，总结出他们的习惯，如果我们也能具备这些习惯，那么我们也很可能成为成功人士。类似的，CMMI可以看作是成功企业如何做好软件的一些习惯、做法、准则等的集合，是如何做好软件的最佳实践的集合。如果企业也能按照CMMI的要求做好，那么企业就很可能成为成功的企业。

    CMMI里面所有的要求，都是来自于成功企业的最佳实践的，她的先进性我们不必怀疑，如果我们没有做好，那不是CMMI本身的问题，而是我们自己没有理解好或者是没有执行好的原因。

    说到CMMI，就不可避免会提到另外3个字母SEI，SEI全称是Software Engineering Institute的全称，直译就是软件工程学院，是美国的一所大学，CMMI标准就是他们搞出来的。

    CMMI目前最新版本是V1.2，如果你是现在才开始了解CMMI的，那么你完全没有必要去搞清楚V1.1与V1.2的差别，更加没有必要去比较CMM与CMMI的差别，直接了解CMMI V1.2就可以了，你只需要知道CMM是CMMI的前身，而CMMI V1.1虽然比CMM要新很多，但现在已经不用了。现在在互联网上还有很多比较CMM与CMMI的文章的，除非你很想了解或者你有很多时间，建议不必去看这些内容。

     

    连续式vs阶段式

    CMMI有两种表述方式：连续式与阶段式，两种方式只是从不同的角度来阐述CMMI，其实质上表达的内容是一致的。就好像我们做数据库设计的时候，可能会设计不同的视图来查看相同数据表的数据，只是角度不一样。

    大家可能会问，好好的CMMI，为什么要搞两种表达方式呢？不怕把大家搞糊涂吗？

    确实这两种方式把不少人给搞糊涂了，这是SEI的一个败笔。以前的CMM是只有阶段式的表达方式的，连续式是后来提出来的，SEI内部分成两派，一派支持连续式，一派支持阶段式，互不相让，最后达不成一致，就出来了现在这个样子，连续式与阶段式两者共存。

    连续式其实更加能反应过程改进的本质，并且能更好地引导企业把过程改进做到实处，但连续式比较难以理解。阶段式是直接继承CMM的，大家都比较容易理解，而且阶段式有一个级别，在商业上更好宣传，但很容易导致企业为了过级而过级。

    连续式和阶段式同时也是评估的两个不同角度，用连续式评估，企业会得到很多个PA的Level，用阶段式评估，企业会得到一个整体的Level。

    对CMMI还不是很熟的人士，先了解这么多就可以了，以后再慢慢了解。

     

    CMMI 1至5级简述

    这里我们用比较容易理解的阶段式的角度，来描述一下CMMI的级别。

    在模型中，所有软件组织的软件能力成熟度划分为5个等级——第1到第5级。数字越大，成熟度越高，高成熟度等级代表比较强的综合软件能力。

    5个成熟度等级分别是：

    l 第1级：初始级

    l 第2级：受管理级

    l 第3级：已定义级

    l 第4级：定量管理级

    l 第5级：持续优化级

    第1级是不需要评估的，哪怕你们是手工作坊开发的软件公司，也可以说是CMMI1级。从2级开始到5级，SEI在每个级别都有详细的标准。

    那怎样才算达到某个级别呢？

    要通过高级别的评估，要满足这个级别以下所有级别的标准。

    例如：

    l 一个进行4级评估的企业，评估的时候首先是看是否达到2级要求，然后是3级要求，然后才是4级要求。

    l 评估的时候，如果2级的标准达到，但3级的要求达不到，就算4级的要求达到了，也只能算2级。

    每个级别又代表怎样的意思呢？下表简要地说明了1到5级的差异：

     

     

    2级比较容易做到，要做到3级要做的事情多很多，一般来说建议2、3级一起来做。3级到4级跨度很大，要做到4级非常不容易。如果4级做得比较好，要做到5级难度不算很大。以下是各级难度的示意图：

     

     

    过程域(PA)、目标(Goal)与实践(Practice)

    CMMI2级到5级，每个级别都包含几个到十几个PA(Process Area)，直接翻译就叫做：过程域。

    PA简单地说就是要做好软件开发的某一个方面，如果要达到某个级别的要求，就要达到该级别所有PA的要求。一个PA包含几个Goal（目标），如果要达到某个PA的要求，就意味着要达到该PA每个Goal的要求。

    每个Goal怎样才算达到要求呢？每个Goal又包含几个到十几个Practice（实践），如果这些Practice都做到了，就认为该Goal达到要求了。

    级别、PA、Goal与Practice的关系示意图如下：

    2级有7个PA，3级有11个PA，4级有2个PA，5级有2个PA，一共22个PA，Practice的总数量超过400个。如果要达到5级的要求，意味着必须满足这400多个Practice的要求。

     

    评估办法

    评估一个企业达到多少级别的要求，其实就是看相应的Practice是否达到要求。评估办法根据严谨的程度，分为以下办法：

    l SCAMPI C

    l SCAMPI B

    l SCAMPI A

    SCAMPI A是最严谨的，进行正式评估的时候，必须采用该办法。下面我们简单体会一下SCAMPI A评估方法。

    举一个日常的例子，比方说你今天中午吃了饭，但别人不知道，别人要判断你是不是吃了饭，用SCAMPI A的办法来判断的话，需要提供以下证据：

    1)书面直接证据，能证明你吃了饭的书面的直接的证据。如果你去餐厅吃饭的，你的帐单就可以用来做直接证据，如果你在家做饭，那就麻烦，可能没有能留下直接书面证据了。

    2)书面间接证据：比方说你在家做饭，之前去买菜了，你买菜的账单就可以作为间接书面证据。

    3)访谈证据：如果别人问你，今天中午有没有吃饭，你能准确说出来，并且没有疑点，那就认为证据有效了，或者是如果你和别人吃饭，别人能说出跟你吃了饭，也认为证据有效了。

    以上3方面的证据，第一个证据书面直接证据，是必须要有的，同时第2和第3类证据，至少要有一个。以上证据都具备，才能认为你吃了饭。

    我想大家可能要“吐血”了，为了要证明吃了饭，居然要这样麻烦！当然吃饭只是一个例子，我们进行CMMI评估的时候，每一个Practice都需要提供这样的证据。

    准备评估没有什么捷径，就是老老实实按照CMMI的要求去做，认真做好过程改进的工作，认真准备书面证据，访谈的时候就按照实际的做法老老实实的回答。

     

    企业商业目标与CMMI

    有一种业内普遍的误解，好像CMMI级别越高，项目的成本就越高。那么我们要问，为什么我们还要去追求高级别呢？企业到底为什么要去评估CMMI？

    业内也有另外一种误解，CMMI是用来提高软件质量的。那么CMMI不用来加快软件开发进度，节省成本吗？软件开发从来就是质量、进度、成本的平衡，CMMI只关注一个方面吗？

    公司的商业目标，简单地说两个字可以概括——“赚钱”！为了赚钱，我们有很多办法：

    l 提高质量，我们的质量不需要很高，比竞争对手高就可以了。

    l 加快进度，我们的进度也不需要很快，但至少要比竞争对手快。

    l 减少成本，成本也不必减少很多，关键是能支持公司运作，能带来利润就可以了。

    CMMI是为企业的商业目标服务的！既不是纯粹提高质量，也不是光增加公司的成本而不提高效益。CMMI是为了提高企业的生产力！

    如果贵公司实施了CMMI，而没有提高生产力的话，改进是失败的，违背CMMI的初衷的。CMMI是个好东西，我们没有做好，并不是CMMI的错，是我们没有理解好或者是执行好。

    要让CMMI切实为企业带来价值，难度很高，如何才能做到？这些内容可以写一本书。本文希望能澄清大家的一些思想误区，扫扫CMMI的文盲，为切实发挥CMMI的作用做好准备。

    查看(580) 评论(1) 收藏 分享 管理

  • ASP.NET中常用的26个优化性能方法

    2009-02-13 09:50:27

    . 数据库访问性能优化　
    　
    数据库的连接和关闭

    访问数据库资源需要创建连接、打开连接和关闭连接几个操作。这些过程需要多次与数据库交换信息以通过身份验证，比较耗费服务器资源。ASP.NET中提供了连接池(Connection Pool)改善打开和关闭数据库对性能的影响。系统将用户的数据库连接放在连接池中，需要时取出，关闭时收回连接，等待下一次的连接请求。连接池的大小是有限的，如果在连接池达到最大限度后仍要求创建连接，必然大大影响性能。因此，在建立数据库连接后只有在真正需要操作时才打开连接，使用完毕后马上关闭，从而尽量减少数据库连接打开的时间，避免出现超出连接限制的情况。 　　

    使用存储过程 　
    　
    存储过程是存储在服务器上的一组预编译的    SQL语句，类似于DOS系统中的批处理文件。存储过程具有对数据库立即访问的功能，信息处理极为迅速。使用存储过程可以避免对命令的多次编译，在执行一次后其执行规划就驻留在高速缓存中，以后需要时只需直接调用缓存中的二进制代码即可。另外，存储过程在服务器端运行，独立于ASP.NET程序，便于修改，最重要的是它可以减少数据库操作语句在网络中的传输。

    优化查询语句
    　　
    ASP.NET中ADO连接消耗的资源相当大，SQL语句运行的时间越长，占用系统资源的时间也越长。因此，尽量使用优化过的SQL语句以减少执行时间。比如，不在查询语句中包含子查询语句，充分利用索引等。 　　

    2. 字符串操作性能优化　
    　
    使用值类型的ToString方法
    　　
    在连接字符串时，经常使用"+"号直接将数字添加到字符串中。这种方法虽然简单，也可以得到正确结果，但是由于涉及到不同的数据类型，数字需要通过装箱操作转化为引用类型才可以添加到字符串中。但是装箱操作对性能影响较大，因为在进行这类处理时，将在托管堆中分配一个新的对象，原有的值复制到新创建的对象中。使用值类型的ToString方法可以避免装箱操作，从而提高应用程序性能。 　　

    运用StringBuilder类 　　

    String类对象是不可改变的，对于String对象的重新赋值在本质上是重新创建了一个String对象并将新值赋予该对象，其方法ToString对性能的提高并非很显著。在处理字符串时，最好使用StringBuilder类，其.NET 命名空间是System.Text。该类并非创建新的对象，而是通过Append，Remove，Insert等方法直接对字符串进行操作，通过ToString方法返回操作结果。 　　其定义及操作语句如下所示：


    int num; 　　System.Text.StringBuilder str = new System.Text.StringBuilder(); //创建字符串 　　str.Append(num.ToString()); //添加数值num 　　Response.Write(str.ToString); //显示操作结果3. 优化     Web 服务器计算机和特定应用程序的配置文件以符合您的特定需要

    默认情况下，ASP.NET 配置被设置成启用最广泛的功能并尽量适应最常见的方案。因此，应用程序开发人员可以根据应用程序所使用的功能，优化和更改其中的某些配置，以提高应用程序的性能。下面的列表是您应该考虑的一些选项。

    仅对需要的应用程序启用身份验证。

    默认情况下，身份验证模式为     Windows，或集成 NTLM。大多数情况下，对于需要身份验证的应用程序，最好在 Machine.config 文件中禁用身份验证，并在 Web.config 文件中启用身份验证。根据适当的请求和响应编码设置来配置应用程序。ASP.NET 默认编码格式为 UTF-8。如果您的应用程序为严格的 ASCII，请配置应用程序使用 ASCII 以获得稍许的性能提高。
    　　
    考虑对应用程序禁用 AutoEventWireup。

    在 Machine.config 文件中将 AutoEventWireup 属性设置为 false，意味着页面不将方法名与事件进行匹配和将两者挂钩(例如 Page_Load)。如果页面开发人员要使用这些事件，需要在基类中重写这些方法(例如，需要为页面加载事件重写 Page.OnLoad，而不是使用 Page_Load 方法)。如果禁用 AutoEventWireup，页面将通过将事件连接留给页面作者而不是自动执行它，获得稍许的性能提升。

    从请求处理管线中移除不用的模块。

    默认情况下，服务器计算机的 Machine.config 文件中 节点的所有功能均保留为激活。根据应用程序所使用的功能，您可以从请求管线中移除不用的模块以获得稍许的性能提升。检查每个模块及其功能，并按您的需要自定义它。例如，如果您在应用程序中不使用会话状态和输出缓存，则可以从 列表中移除它们，以便请求在不执行    其他有意义的处理时，不必执行每个模块的进入和离开代码。

    4. 一定要禁用调试模式　　

    在部署生产应用程序或进行任何性能测量之前，始终记住禁用调试模式。如果启用了调试模式，应用程序的性能可能受到非常大的影响。 　　

    5. 对于广泛依赖外部资源的应用程序，请考虑在多处理器计算机上启用网络园艺　　

    ASP.NET 进程模型帮助启用多处理器计算机上的可缩放性，将    工作分发给多个进程(每个CPU一个)，并且每个进程都将处理器关系设置为其 CPU。此技术称为网络园艺。如果应用程序使用较慢的数据库服务器或调用具有外部依赖项的 COM 对象(这里只是提及两种可能性)，则为您的应用程序启用网络园艺是有益的。但是，在决定启用网络园艺之前，您应该测试应用程序在网络园中的执行情况。 　　

    6. 只要可能，就缓存数据和页输出　　

    ASP.NET 提供了一些简单的机制，它们会在不需要为每个页请求动态计算页输出或数据时缓存这些页输出或数据。另外，通过设计要进行缓存的页和数据请求(特别是在站点中预期将有较大通讯量的区域)，可以优化这些页的性能。与 .NET Framework 的任何 Web 窗体功能相比，适当地使用缓存可以更好的提高站点的性能，有时这种提高是超数量级的。使用 ASP.NET 缓存机制有两点需要注意。首先，不要缓存太多项。缓存每个项均有开销，特别是在内存使用方面。不要缓存容易重新计算和很少使用的项。其次，给缓存的项分配的有效期不要太短。很快到期的项会导致缓存中不必要的周转，并且经常导致更多的代码清除和垃圾回收工作。若关心此问题，请监视与 ASP.NET Applications 性能对象关联的 Cache Total Turnover Rate 性能计数器。高周转率可能说明存在问题，特别是当项在到期前被移除时。这也称作内存压力。


    7. 选择适合页面或应用程序的数据查看机制　　

    根据您选择在 Web 窗体页显示数据的方式，在便利和性能之间常常存在着重要的权衡。例如，DataGrid Web 服务器控件可能是一种显示数据的方便快捷的方法，但就性能而言它的开销常常是最大的。在某些简单的情况下，您通过生成适当的 HTML 自己呈现数据可能很有效，但是自定义和浏览器定向会很快抵销所获得的额外功效。Repeater Web 服务器控件是便利和性能的折衷。它高效、可自定义且可编程。 　　

    8. 将 SqlDataReader 类用于快速只进数据游标　　

    SqlDataReader 类提供了一种读取从 SQL     Server 数据库检索的只进数据流的方法。如果当创建 ASP.NET 应用程序时出现允许您使用它的情况，则 SqlDataReader 类提供比 DataSet 类更高的性能。情况之所以这样，是因为 SqlDataReader 使用 SQL Server 的本机网络数据传输格式从数据库连接直接读取数据。另外，SqlDataReader 类实现 IEnumerable 接口，该接口也允许您将数据绑定到服务器控件。有关更多信息，请参见 SqlDataReader 类。有关 ASP.NET 如何访问数据的信息，请参见通过 ASP.NET 访问数据。 　　

    9. 将 SQL Server 存储过程用于数据访问　　

    在 .NET Framework 提供的所有数据访问方法中，基于 SQL Server 的数据访问是生成高性能、可缩放 Web 应用程序的推荐选择。使用托管 SQL Server 提供程序时，可通过使用编译的存储过程而不是特殊查询获得额外的性能提高。 　　

    10. 避免单线程单元 (STA) COM 组件　　

    默认情况下，ASP.NET 不允许任何 STA COM 组件在页面内运行。若要运行它们，必须在 .aspx 文件内将 ASPCompat=true 属性包含在 @ Page 指令中。这样就将执行用的线程池切换到 STA 线程池，而且使 HttpContext 和其他内置对象可用于 COM 对象。前者也是一种性能优化，因为它避免了将多线程单元 (MTA) 封送到 STA 线程的任何调用。使用 STA COM 组件可能大大损害性能，应尽量避免。若必须使用 STA COM 组件，如在任何 interop 方案中，则应在执行期间进行大量调用并在每次调用期间发送尽可能多的信息。另外，小心不要在构造页面期间创建任何 STA COM 组件。例如下面的代码中，在页面构造时将实例化由某个线程创建的 MySTAComponent，而该线程并不是将运行页面的 STA 线程。这可能对性能有不利影响，因为要构造页面就必须完成 MTA 和 STA 线程之间的封送处理。


    <%@ Page Language="VB" ASPCompat="true" %><% Response.Write(myComp.SayHello) %>


    首选机制是推迟对象的创建，直到以后在 STA 线程下执行上述代码，如下面的例子所示。




    <%@ Page Language="VB" ASPCompat="true" %><% Response.Write(myComp.SayHello) %>

    推荐的做法是在需要时或者在 Page_Load 方法中构造任何 COM 组件和外部资源。永远不要将任何 STA COM 组件存储在可以由构造它的线程以外的其他线程访问的共享资源里。这类资源包括像缓存和会话状态这样的资源。即使 STA 线程调用 STA COM 组件，也只有构造此 STA COM 组件的线程能够实际为该调用服务，而这要求封送处理对创建者线程的调用。此封送处理可能产生重大的性能损失和可伸缩性问题。在这种情况下，请研究一下使 COM 组件成为 MTA COM 组件的可能性，或者更好的办法是迁移代码以使对象成为托管对象。 　　

    11. 将调用密集型的 COM 组件迁移到托管代码　　

    .NET Framework 提供了一个简单的方法与传统的 COM 组件进行交互。其优点是可以在保留现有投资的同时利用新的平台。但是在某些情况下，保留旧组件的性能开销使得将组件迁移到托管代码是值得的。每一情况都是不一样的，决定是否需要迁移组件的最好方法是对 Web 站点运行性能测量。建议您研究一下如何将需要大量调用以进行交互的任何COM 组件迁移到托管代码。许多情况下不可能将旧式组件迁移到托管代码，特别是在最初迁移 Web 应用程序时。在这种情况下，最大的性能障碍之一是将数据从非托管环境封送到托管环境。因此，在交互操作中，请在任何一端执行尽可能多的任务，然后进行一个大调用而不是一系列小调用。例如，公共语言运行库中的所有字符串都是 Unicode 的，所以应在调用托管代码之前将组件中的所有字符串转换成 Unicode 格式。另外，一处理完任何 COM 对象或本机资源就释放它们。这样，其他请求就能够使用它们，并且最大限度地减少了因稍后请求垃圾回收器释放它们所引起的性能问题。 　　

    12. 在 Visual Basic .NET 或 Jscrīpt. 代码中使用早期绑定　　

    以往，开发人员喜欢使用 Visual Basic、VBscrīpt. 和 Jscrīpt. 的原因之一就是它们所谓“无类型”的性质。变量不需要显式类型声明，并能够简单地通过使用来创建它们。当从一个类型到另一个类型进行分配时，转换将自动执行。不过，这种便利会大大损害应用程序的性能。Visual Basic 现在通过使用 Option Strict 编译器指令来支持类型安全编程。为了向后兼容，默认情况下，ASP.NET 不启用该选项。但是，为了得到最佳性能，强烈建议在页中启用该选项。若要启用 Option Strict，请将 Strict 属性包括在 @ Page 指令中，或者，对于用户控件，请将该属性包括在 @ Control 指令中。下面的示例演示了如何设置该属性，并进行了四个变量调用以显示使用该属性是如何导致编译器错误的。

    <%@ Page Language="VB" Strict="true" %><% Dim B Dim C As String ' This will cause a compiler error. A = "Hello" ' This will cause a compiler error. B = "World" ' This will not cause a compiler error. C = "!!!!!!" ' But this will cause a compiler error. C = 0 %>Jscrīpt. .NET 也支持无类型编程，但它不提供强制早期绑定的编译器指令。若发生下面任何一种情况，则变量是晚期绑定的：被显式声明为 Object，是无类型声明的类的字段，是无显式类型声明的专用函数或方法成员，并且无法从其使用推断出类型。 　　最后一个差别比较复杂，因为如果 Jscrīpt. .NET 编译器可以根据变量的使用情况推断出类型，它就会进行优化。在下面的示例中，变量 A 是早期绑定的，但变量 B 是晚期绑定的。

    var A; 　　var B; 　　A = "Hello"; 　　B = "World"; 　　B = 0; 为了获得最佳的性能，当声明 Jscrīpt. .NET 变量时，请为其分配一个类型。例如，var A : String。

    13. 使请求管线内的所有模块尽可能高效　　

    请求管线内的所有模块在每次请求中都有机会被运行。因此，当请求进入和离开模块时快速地触发代码至关重要，特别是在不使用模块功能的代码路径里。分别在使用及不使用模块和配置文件时执行吞吐量测试，对确定这些方法的执行速度非常有用。

    14. 使用 HttpServerUtility.Transfer 方法在同一应用程序的页面间重定向　　

    采用 Server.Transfer 语法，在页面中使用该方法可避免不必要的客户端重定向。
    　　
    15. 必要时调整应用程序每个辅助进程的线程数　　

    ASP.NET 的请求结构试图在执行请求的线程数和可用资源之间达到一种平衡。已知一个使用足够 CPU 功率的应用程序，该结构将根据可用于请求的 CPU 功率，来决定允许同时执行的请求数。这项技术称作线程门控。但是在某些条件下，线程门控算法不是很有效。通过使用与 ASP.NET Applications 性能对象关联的 Pipeline Instance Count 性能计数器，可以在 PerfMon 中监视线程门控。当页面调用外部资源，如数据库访问或 XML Web services 请求时，页面请求通常停止并释放 CPU。如果某个请求正在等待被处理，并且线程池中有一个线程是自由的，那么这个正在等待的请求将开始被处理。遗憾的是，有时这可能导致 Web 服务器上存在大量同时处理的请求和许多正在等待的线程，而它们对服务器性能有不利影响。通常，如果门控因子是外部资源的响应时间，则让过多请求等待资源，对 Web 服务器的吞吐量并无帮助。为缓和这种情况，可以通过更改 Machine.config 配置文件节点的 maxWorkerThreads 和 maxIOThreads 属性，手动设置进程中的线程数限制。 　　

    注意：辅助线程是用来处理 ASP.NET 请求的，而 IO 线程则是用于为来自文件、数据库或 XML Web services 的数据提供服务的。分配给这些属性的值是进程中每个 CPU 每类线程的最大数目。对于双处理器计算机，最大数是设置值的两倍。对于四处理器计算机，最大值是设置值的四倍。无论如何，对于有四个或八个 CPU 的计算机，最好更改默认值。对于有一个或两个处理器的计算机，默认值就可以，但对于有更多处理器的计算机的性能，进程中有一百或两百个线程则弊大于利。注意进程中有太多线程往往会降低服务器的速度，因为额外的上下文交换导致    操作系统将 CPU 周期花在维护线程而不是处理请求上。 　　

    16. 适当地使用公共语言运行库的垃圾回收器和自动内存管理　　

    小心不要给每个请求分配过多内存，因为这样垃圾回收器将必须更频繁地进行更多的工作。另外，不要让不必要的指针指向对象，因为它们将使对象保持活动状态，并且应尽量避免含 Finalize 方法的对象，因为它们在后面会导致更多的工作。特别是在 Finalize 调用中永远不要释放资源，因为资源在被垃圾回收器回收之前可能一直消耗着内存。最后这个问题经常会对 Web 服务器环境的性能造成毁灭性的打击，因为在等待 Finalize 运行时，很容易耗尽某个特定的资源。 　　

    17. 如果有大型 Web 应用程序，可考虑执行预批编译　　

    每当发生对目录的第一次请求时都会执行批编译。如果目录中的页面没有被分析并编译，此功能会成批分析并编译目录中的所有页面，以便更好地利用磁盘和内存。如果这需要很长时间，则将快速分析并编译单个页面，以便请求能被处理。此功能带给 ASP.NET 性能上的好处，因为它将许多页面编译为单个程序集。从已加载的程序集访问一页比每页加载新的程序集要快。批编译的缺点在于：如果服务器接收到许多对尚未编译的页面的请求，那么当 Web 服务器分析并编译它们时，性能可能较差。为解决这个问题，可以执行预批编译。为此，只需在应用程序激活之前向它请求一个页面，无论哪页均可。然后，当用户首次访问您的站点时，页面及其程序集将已被编译。没有简单的机制可以知道批编译何时发生。需一直等到 CPU 空闲或者没有更多的编译器进程(例如 csc.exe(C# 编译器)或 vbc.exe(Visual Basic 编译器))启动。还应尽量避免更改应用程序的 \bin 目录中的程序集。更改页面会导致重新分析和编译该页，而替换 \bin 目录中的程序集则会导致完全重新批编译该目录。在包含许多页面的大规模站点上，更好的办法可能是根据计划替换页面或程序集的频繁程度来设计不同的目录结构。不常更改的页面可以存储在同一目录中并在特定的时间进行预批编译。经常更改的页面应在它们自己的目录中(每个目录最多几百页)以便快速编译。Web 应用程序可以包含许多子目录。批编译发生在目录级，而不是应用程序级。

    18. 不要依赖代码中的异常　　

    因为异常大大地降低性能，所以您不应该将它们用作控制正常程序流程的方式。如果有可能检测到代码中可能导致异常的状态，请执行这种操作。不要在处理该状态之前捕获异常本身。常见的方案包括：检查 null，分配给将分析为数字值的 String 一个值，或在应用数学运算前检查特定值。下面的示例演示可能导致异常的代码以及测试是否存在某种状态的代码。两者产生相同的结果。


    　try 　　{ 　　result = 100 / num; 　　} 　　catch (Exception e) 　　{ 　　result = 0; 　　} 　　// ...to this. 　　if (num != 0) 　　result = 100 / num; 　　else 　　result = 0;

    19. 使用 HttpResponse.Write 方法进行字符串串联

    该方法提供非常有效的缓冲和连接服务。但是，如果您正在执行广泛的连接，请使用多个 Response.Write 调用。下面示例中显示的技术比用对 Response.Write 方法的单个调用连接字符串更快。




    Response.Write("a"); 　　Response.Write(myString); 　　Response.Write("b"); 　　Response.Write(myObj.ToString()); 　　Response.Write("c"); 　　Response.Write(myString2); 　　Response.Write("d"); 20. 除非有特殊的原因要关闭缓冲，否则使其保持打开

    禁用 Web 窗体页的缓冲会导致大量的性能开销。 　　

    21. 只在必要时保存服务器控件视图状态　　

    自动视图状态管理是服务器控件的功能，该功能使服务器控件可以在往返过程上重新填充它们的属性值(您不需要编写任何代码)。但是，因为服务器控件的视图状态在隐藏的窗体字段中往返于服务器，所以该功能确实会对性能产生影响。您应该知道在哪些情况下视图状态会有所帮助，在哪些情况下它影响页的性能。例如，如果您将服务器控件绑定到每个往返过程上的数据，则将用从数据绑定操作获得的新值替换保存的视图状态。在这种情况下，禁用视图状态可以节省处理时间。默认情况下，为所有服务器控件启用视图状态。若要禁用视图状态，请将控件的EnableViewState 属性设置为 false，如下面的 DataGrid 服务器控件示例所示。




    您还可以使用 @ Page 指令禁用整个页的视图状态。当您不从页回发到服务器时，这将十分有用：


    <%@ Page EnableViewState="false" %>

    注意:@ Control 指令中也支持 EnableViewState 属性，该指令允许您控制是否为用户控件启用视图状态。若要分析页上服务器控件使用的视图状态的数量，请(通过将 trace="true" 属性包括在 @ Page 指令中)启用该页的跟踪并查看 Control Hierarchy 表的 Viewstate 列。有关跟踪和如何启用它的信息，请参见 ASP.NET 跟踪。

    22. 避免到服务器的不必要的往返过程　　

    虽然您很可能希望尽量多地使用 Web 窗体页框架的那些节省时间和代码的功能，但在某些情况下却不宜使用 ASP.NET 服务器控件和回发事件处理。通常，只有在检索或存储数据时，您才需要启动到服务器的往返过程。多数数据操作可在这些往返过程间的客户端上进行。例如，从 HTML 窗体验证用户输入经常可在数据提交到服务器之前在客户端进行。通常，如果不需要将信息传递到服务器以将其存储在数据库中，那么您不应该编写导致往返过程的代码。如果您开发自定义服务器控件，请考虑让它们为支持 ECMAscrīpt. 的浏览器呈现客户端代码。通过以这种方式使用服务器控件，您可以显著地减少信息被不必要的发送到 Web 服务器的次数。

    使用 Page.IsPostBack 避免对往返过程执行不必要的处理

    如果您编写处理服务器控件回发处理的代码，有时可能需要在首次请求页时执行其他代码，而不是当用户发送包含在该页中的 HTML 窗体时执行的代码。根据该页是否是响应服务器控件事件生成的。

    使用 Page.IsPostBack 属性有条件地执行代码

    例如，下面的代码演示如何创建数据库连接和命令，该命令在首次请求该页时将数据绑定到 DataGrid 服务器控件。


    void Page_Load(Object sender, EventArgs e) 　　{ 　　// Set up a connection and command here. 　　if (!Page.IsPostBack) 　　{ 　　String query = "select * from Authors where FirstName like '%JUSTIN%'"; 　　myCommand.Fill(ds, "Authors"); 　　myDataGrid.DataBind(); 　　} 　　}

    由于每次请求时都执行 Page_Load 事件，上述代码检查 IsPostBack 属性是否设置为 false。如果是，则执行代码。如果该属性设置为 true，则不执行代码。注意 如果不运行这种检查，回发页的行为将不更改。Page_Load 事件的代码在执行服务器控件事件之前执行，但只有服务器控件事件的结果才可能在输出页上呈现。如果不运行该检查，仍将为 Page_Load 事件和该页上的任何服务器控件事件执行处理。 　　

    23. 当不使用会话状态时禁用它　　

    并不是所有的应用程序或页都需要针对于具体用户的会话状态，您应该对任何不需要会话状态的应用程序或页禁用会话状态。 　　若要禁用页的会话状态，请将 @ Page 指令中的 EnableSessionState 属性设置为 false。例如:



    <%@ Page EnableSessi %>注意:如果页需要访问会话变量，但不打算创建或修改它们，则将@ Page 指令中的 EnableSessionState 属性设置为ReadOnly。还可以禁用 XML Web services 方法的会话状态。有关更多信息，请参见使用 ASP.NET 和 XML Web services 客户端创建的 XML Web services。若要禁用应用程序的会话状态，请在应用程序 Web.config 文件的 sessionstate 配置节中将 mode 属性设置为 off。例如:



    24. 仔细选择会话状态提供程序　　

    ASP.NET 为存储应用程序的会话数据提供了三种不同的方法：进程内会话状态、作为 Windows 服务的进程外会话状态和 SQL Server 数据库中的进程外会话状态。每种方法都有自己的优点，但进程内会话状态是迄今为止速度最快的解决方案。如果只在会话状态中存储少量易失数据，则建议您使用进程内提供程序。进程外解决方案主要用于跨多个处理器或多个计算机缩放应用程序，或者用于服务器或进程重新启动时不能丢失数据的情况。有关更多信息，请参见 ASP.NET 状态管理。 　　

    25. 不使用不必要的Server Control

    ASP.net中，大量的服务器端控件方便了程序开发，但也可能带来性能的损失，因为用户每操作一次服务器端控件，就产生一次与服务器端的往返过程。因此，非必要，应当少使用Server Control。 　　

    26. ASP.NET应用程序    性能测试　　

    在对ASP.NET应用程序进行性能测试之前，应确保应用程序没有错误，而且功能正确。具体的性能测试可以采用以下工具进行：Web Application Strees Tool (WAS)是Microsoft发布的一个免费    测试工具，可以从http://webtool.rte.microsoft.com/上下载。它可以模拟成百上千个用户同时对web应用程序进行访问请求，在服务器上形成流量负载，从而达到测试的目的，可以生成平均TTFB、平均TTLB等性能汇总报告。Application Center Test (ACT) 是一个测试工具，附带于Visual Studio.NET的企业版中，是Microsoft正式支持的web应用程序测试工具。它能够直观地生成图表结果，功能比WAS多，但不具备多个客户机同时测试的能力。服务器操作系统"管理工具"中的"性能"计数器，可以对服务器进行监测以了解应用程序性能。 　　

    结论：

    对于网站开发人员来说，在编写ASP.NET应用程序时注意性能问题，养成良好的习惯，提高应用程序性能，至少可以推迟必需的硬件升级，降低网站的成本。

    查看(501) 评论(0) 收藏 分享 管理

  • 测试TCP/IP配置

    2009-02-09 13:40:06

    安装网络硬件和网络协议之后，我们一般要进行TCP/IP协议的测试工作，那么怎样测试才算是比较全面的测试呢?我们认为，全面的测试应包括局域网和互联网两个方面，因此应从局域网和互联网两个方面测试，以下是我们在实际工作中利用命令行测试TCP/IP配置的步骤：
    　　1、 单击“开始”/“运行”，输入CMD按回车，打开命令提示符窗口。

    　　2、 首先检查IP地址、子网掩码、默认网关、DNS服务器地址是否正确，输入命令ipconfig /all,按回车。此时显示了你的网络配置，观查是否正确。

    　　3、 输入ping 127.0.0.1，观查网卡是否能转发数据，如果出现“Request timed out”，表明配置差错或网络有问题。

    　　4、 Ping一个互联网地址，如ping 202.102.128.68,看是否有数据包传回，以验证与互联网的连接性。

    　　5、 Ping 一个局域网地址，观查与它的连通性。

    　　6、 用nslookup测试DNS解析是否正确，输入如nslookup www.163.com，查看是否能解析。

    　　如果你的计算机通过了全部测试，则说明网络正常，否则网络可能有不同程度的问题。在此不展开详述。不过，要注意，在使用 ping命令时，有些公司会在其主机设置丢弃ICMP数据包，造成你的ping命令无法正常返回数据包，不防换个网站试试。

    ping命令详解

    ping [-n count][-l size][-w timeout]

    -n 发送的ICMP数据包数，默认是4个

    -l 发送的ICMP数据包大小，一般是56K+8K=64K

    -w 超时时间

     

    数据格式：
    数据帧：帧头＋IP数据包＋帧尾 (帧头包括源和目标主机MAC地址及类型,帧尾是校验字)
    IP数据包：IP头部＋TCP数据信息 (IP头包括源和目标主机IP地址、类型、生存期等)
    TCP数据信息：TCP头部+实际数据 (TCP头包括源和目标主机端口号、顺序号、确认号、校
    验字等)

    查看(347) 评论(0) 收藏 分享 管理

  • SQL Server数据库优化方案

    2009-01-22 15:12:36

    查询速度慢的原因很多，常见如下几种：
    　　1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)
    　　2、I/O吞吐量小，形成了瓶颈效应。　3、没有创建计算列导致查询不优化。
    　　4、内存不足　　5、网络速度慢
    　　6、查询出的数据量过大(可以采用多次查询，其他的方法降低数据量)
    　　7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)
    　　8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。
    　　9、返回了不必要的行和列
    　　10、查询语句不好，没有优化
    　　可以通过如下方法来优化查询 :
    　　1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2000不在支持。数据量(尺寸)越大，提高I/O越重要.
    　　2、纵向、横向分割表，减少表的尺寸(sp_spaceuse)
    　　3、升级硬件
    　　4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。注意填充因子要适当(最好是使用默认值0)。索引应该尽量小，使用字节数小的列建索引好(参照索引的创建),不要对有限的几个值的字段建单一索引如性别字段
    　　5、提高网速;
    　　6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。配置虚拟内存：虚拟内存大小应基于计算机上并发运行的服务进行配置。运行 Microsoft SQL Server? 2000 时，可考虑将虚拟内存大小设置为计算机中安装的物理内存的 1.5 倍。如果另外安装了全文检索功能，并打算运行 Microsoft 搜索服务以便执行全文索引和查询，可考虑：将虚拟内存大小配置为至少是计算机中安装的物理内存的 3 倍。将 SQL Server max server memory 服务器配置选项配置为物理内存的 1.5 倍(虚拟内存大小设置的一半)。
    　　7、增加服务器 CPU个数;但是必须明白并行处理串行处理更需要资源例如内存。使用并行还是串行程是MsSQL自动评估选择的。单个任务分解成多个任务，就可以在处理器上运行。例如耽搁查询的排序、连接、扫描和GROUP BY字句同时执行，SQL SERVER根据系统的负载情况决定最优的并行等级，复杂的需要消耗大量的CPU的查询最适合并行处理。但是更新操作Update,Insert， Delete还不能并行处理。
    　　8、如果是使用like进行查询的话，简单的使用index是不行的，但是全文索引，耗空间。 like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查询时，查询耗时和字段值总长度成正比,所以不能用CHAR类型，而是VARCHAR。对于字段的值很长的建全文索引。
    　　9、DB Server 和APPLication Server 分离;OLTP和OLAP分离
    　　10、分布式分区视图可用于实现数据库服务器联合体。联合体是一组分开管理的服务器，但它们相互协作分担系统的处理负荷。这种通过分区数据形成数据库服务器联合体的机制能够扩大一组服务器，以支持大型的多层 Web 站点的处理需要。有关更多信息，参见设计联合数据库服务器。(参照SQL帮助文件'分区视图')
    　　a、在实现分区视图之前，必须先水平分区表
    　　b、在创建成员表后，在每个成员服务器上定义一个分布式分区视图，并且每个视图具有相同的名称。这样，引用分布式分区视图名的查询可以在任何一个成员服务器上运行。系统操作如同每个成员服务器上都有一个原始表的复本一样，但其实每个服务器上只有一个成员表和一个分布式分区视图。数据的位置对应用程序是透明的。
    　　11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收缩数据和日志 DBCC SHRINKDB,DBCC SHRINKFILE. 设置自动收缩日志.对于大的数据库不要设置数据库自动增长，它会降低服务器的性能。在T-sql的写法上有很大的讲究，下面列出常见的要点：首先，DBMS处理查询计划的过程是这样的：
    　　1、 查询语句的词法、语法检查
    　　2、 将语句提交给DBMS的查询优化器
    　　3、 优化器做代数优化和存取路径的优化
    　　4、 由预编译模块生成查询规划
    　　5、 然后在合适的时间提交给系统处理执行
    　　6、 最后将执行结果返回给用户其次，看一下SQL SERVER的数据存放的结构：一个页面的大小为8K(8060)字节，8个页面为一个盘区，按照B树存放。
    12、Commit和rollback的区别 Rollback:回滚所有的事物。 Commit:提交当前的事物. 没有必要在动态SQL里写事物，如果要写请写在外面如： begin tran exec(@s) commit trans 或者将动态SQL 写成函数或者存储过程。
    　　13、在查询Select语句中用Where字句限制返回的行数,避免表扫描,如果返回不必要的数据，浪费了服务器的I/O资源，加重了网络的负担降低性能。如果表很大，在表扫描的期间将表锁住，禁止其他的联接访问表,后果严重。
    　　14、SQL的注释申明对执行没有任何影响

    　15、尽可能不使用光标，它占用大量的资源。如果需要row-by-row地执行，尽量采用非光标技术,如：在客户端循环，用临时表，Table变量，用子查询，用Case语句等等。游标可以按照它所支持的提取选项进行分类： 只进 必须按照从第一行到最后一行的顺序提取行。FETCH NEXT 是唯一允许的提取操作,也是默认方式。可滚动性可以在游标中任何地方随机提取任意行。游标的技术在SQL2000下变得功能很强大，他的目的是支持循环。有四个并发选项 READ_ONLY：不允许通过游标定位更新(Update)，且在组成结果集的行中没有锁。 OPTIMISTIC WITH valueS:乐观并发控制是事务控制理论的一个标准部分。乐观并发控制用于这样的情形，即在打开游标及更新行的间隔中，只有很小的机会让第二个用户更新某一行。当某个游标以此选项打开时，没有锁控制其中的行，这将有助于最大化其处理能力。如果用户试图修改某一行，则此行的当前值会与最后一次提取此行时获取的值进行比较。如果任何值发生改变，则服务器就会知道其他人已更新了此行，并会返回一个错误。如果值是一样的，服务器就执行修改。选择这个并发选项OPTIMISTIC WITH ROW VERSIONING:此乐观并发控制选项基于行版本控制。使用行版本控制，其中的表必须具有某种版本标识符，服务器可用它来确定该行在读入游标后是否有所更改。在 SQL Server 中，这个性能由 timestamp 数据类型提供，它是一个二进制数字，表示数据库中更改的相对顺序。每个数据库都有一个全局当前时间戳值：@@DBTS。每次以任何方式更改带有 timestamp 列的行时，SQL Server 先在时间戳列中存储当前的 @@DBTS 值，然后增加 @@DBTS 的值。如果某 个表具有 timestamp 列，则时间戳会被记到行级。服务器就可以比较某行的当前时间戳值和上次提取时所存储的时间戳值，从而确定该行是否已更新。服务器不必比较所有列的值，只需比较 timestamp 列即可。如果应用程序对没有 timestamp 列的表要求基于行版本控制的乐观并发，则游标默认为基于数值的乐观并发控制。 SCROLL LOCKS 这个选项实现悲观并发控制。在悲观并发控制中，在把数据库的行读入游标结果集时，应用程序将试图锁定数据库行。在使用服务器游标时，将行读入游标时会在其上放置一个更新锁。如果在事务内打开游标，则该事务更新锁将一直保持到事务被提交或回滚;当提取下一行时，将除去游标锁。如果在事务外打开游标，则提取下一行时，锁就被丢弃。因此，每当用户需要完全的悲观并发控制时，游标都应在事务内打开。更新锁将阻止任何其它任务获取更新锁或排它锁，从而阻止其它任务更新该行。然而，更新锁并不阻止共享锁，所以它不会阻止其它任务读取行，除非第二个任务也在要求带更新锁的读取。滚动锁根据在游标定义的 Select 语句中指定的锁提示，这些游标并发选项可以生成滚动锁。滚动锁在提取时在每行上获取，并保持到下次提取或者游标关闭，以先发生者为准。下次提取时，服务器为新提取中的行获取滚动锁，并释放上次提取中行的滚动锁。滚动锁独立于事务锁，并可以保持到一个提交或回滚操作之后。如果提交时关闭游标的选项为关，则 COMMIT 语句并不关闭任何打开的游标，而且滚动锁被保留到提交之后，以维护对所提取数据的隔离。所获取滚动锁的类型取决于游标并发选项和游标 Select 语句中的锁提示。锁提示 只读 乐观数值 乐观行版本控制 锁定无提示 未锁定 未锁定 未锁定 更新 NOLOCK 未锁定 未锁定未锁定 未锁定 HOLDLOCK 共享 共享 共享 更新 UPDLOCK 错误 更新 更新 更新 TABLOCKX 错误 未锁定 未锁定更新其它 未锁定 未锁定 未锁定 更新 *指定 NOLOCK 提示将使指定了该提示的表在游标内是只读的。

    　　16、用Profiler来跟踪查询，得到查询所需的时间，找出SQL的问题所在;用索引优化器优化索引

    　　17、注意UNion和UNion all 的区别。UNION all好

    　　18、注意使用DISTINCT，在没有必要时不要用，它同UNION一样会使查询变慢。重复的记录在查询里是没有问题的

    　　19、查询时不要返回不需要的行、列

    　　20、用sp_configure 'query governor cost limit'或者SET QUERY_GOVERNOR_COST_LIMIT来限制查询消耗的资源。当评估查询消耗的资源超出限制时，服务器自动取消查询,在查询之前就扼杀掉。 SET LOCKTIME设置锁的时间

    　　21、用select top 100 / 10 Percent 来限制用户返回的行数或者SET ROWCOUNT来限制操作的行

    　　22、在SQL2000以前，一般不要用如下的字句: "IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'"，因为他们不走索引全是表扫描。也不要在Where字句中的列名加函数，如Convert，substring等,如果必须用函数的时候，创建计算列再创建索引来替代.还可以变通写法：Where SUBSTRING(firstname,1,1) = 'm'改为Where firstname like 'm%'(索引扫描)，一定要将函数和列名分开。并且索引不能建得太多和太大。NOT IN会多次扫描表，使用EXISTS、NOT EXISTS ，IN , LEFT OUTER JOIN 来替代，特别是左连接,而Exists比IN更快，最慢的是NOT操作.如果列的值含有空，以前它的索引不起作用，现在2000的优化器能够处理了。相同的是IS NULL，"NOT", "NOT EXISTS", "NOT IN"能优化她，而"<>"等还是不能优化，用不到索引。

    　　23、使用Query Analyzer，查看SQL语句的查询计划和评估分析是否是优化的SQL。一般的20%的代码占据了80%的资源，我们优化的重点是这些慢的地方。

    　　24、如果使用了IN或者OR等时发现查询没有走索引，使用显示申明指定索引： Select * FROM PersonMember (INDEX = IX_Title) Where processid IN ('男'，'女')

    　　25、将需要查询的结果预先计算好放在表中，查询的时候再Select。这在SQL7.0以前是最重要的手段。例如医院的住院费计算。

    　　26、MIN() 和 MAX()能使用到合适的索引。

    　　27、数据库有一个原则是代码离数据越近越好，所以优先选择Default,依次为Rules,Triggers, Constraint(约束如外健主健CheckUNIQUE……,数据类型的最大长度等等都是约束),Procedure.这样不仅维护工作小，编写程序质量高，并且执行的速度快。

    　　28、如果要插入大的二进制值到Image列，使用存储过程，千万不要用内嵌Insert来插入(不知JAVA是否)。因为这样应用程序首先将二进制值转换成字符串(尺寸是它的两倍)，服务器受到字符后又将他转换成二进制值.存储过程就没有这些动作: 方法：Create procedure p_insert as insert into table(Fimage) values (@image), 在前台调用这个存储过程传入二进制参数，这样处理速度明显改善。

    　　29、Between在某些时候比IN 速度更快,Between能够更快地根据索引找到范围。用查询优化器可见到差别。 select * from chineseresume where title in ('男','女') Select * from chineseresume where between '男' and '女' 是一样的。由于in会在比较多次，所以有时会慢些。

    　　30、在必要是对全局或者局部临时表创建索引，有时能够提高速度，但不是一定会这样，因为索引也耗费大量的资源。他的创建同是实际表一样。
    　31、不要建没有作用的事物例如产生报表时，浪费资源。只有在必要使用事物时使用它。

    　　32、用OR的字句可以分解成多个查询，并且通过UNION 连接多个查询。他们的速度只同是否使用索引有关,如果查询需要用到联合索引，用UNION all执行的效率更高.多个OR的字句没有用到索引，改写成UNION的形式再试图与索引匹配。一个关键的问题是否用到索引。

    　　33、尽量少用视图，它的效率低。对视图操作比直接对表操作慢,可以用stored procedure来代替她。特别的是不要用视图嵌套,嵌套视图增加了寻找原始资料的难度。我们看视图的本质：它是存放在服务器上的被优化好了的已经产生了查询规划的SQL。对单个表检索数据时，不要使用指向多个表的视图，直接从表检索或者仅仅包含这个表的视图上读，否则增加了不必要的开销,查询受到干扰.为了加快视图的查询，MsSQL增加了视图索引的功能。

    　　34、没有必要时不要用DISTINCT和ORDER BY，这些动作可以改在客户端执行。它们增加了额外的开销。这同UNION 和UNION ALL一样的道理。

    　　 　　select top 20 ad.companyname,comid,position,ad.referenceid,worklocation, convert(varchar(10),ad.postDate,120) as postDate1,workyear,degreedescrīption FROM jobcn_query.dbo.COMPANYAD_query ad where referenceID in('JCNAD00329667','JCNAD132168','JCNAD00337748','JCNAD00338345',
    　　'JCNAD00333138','JCNAD00303570','JCNAD00303569',
    　　'JCNAD00303568','JCNAD00306698','JCNAD00231935','JCNAD00231933',
    　　'JCNAD00254567','JCNAD00254585','JCNAD00254608',
    　　'JCNAD00254607','JCNAD00258524','JCNAD00332133','JCNAD00268618',
    　　'JCNAD00279196','JCNAD00268613') order by postdate desc 

    　　35、在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，减少判断的次数。

    　　36、当用Select INTO时，它会锁住系统表(sysobjects，sysindexes等等)，阻塞其他的连接的存取。创建临时表时用显示申明语句，而不是 select INTO. drop table t_lxh begin tran select * into t_lxh from chineseresume where name = 'XYZ' --commit 在另一个连接中Select * from sysobjects可以看到 Select INTO 会锁住系统表，Create table 也会锁系统表(不管是临时表还是系统表)。所以千万不要在事物内使用它!!!这样的话如果是经常要用的临时表请使用实表，或者临时表变量。

    　　37、一般在GROUP BY 个HAVING字句之前就能剔除多余的行，所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优：select 的Where字句选择所有合适的行，Group By用来分组个统计行，Having字句用来剔除多余的分组。这样Group By 个Having的开销小，查询快.对于大的数据行进行分组和Having十分消耗资源。如果Group BY的目的不包括计算，只是分组，那么用Distinct更快

    　　38、一次更新多条记录比分多次更新每次一条快,就是说批处理好

    　　39、少用临时表，尽量用结果集和Table类性的变量来代替它,Table 类型的变量比临时表好

    　　40、在SQL2000下，计算字段是可以索引的，需要满足的条件如下：

    　　a、计算字段的表达是确定的

    　　b、不能用在TEXT,Ntext，Image数据类型

    　　c、必须配制如下选项 ANSI_NULLS = ON, ANSI_PADDINGS = ON, …….

    　　41、尽量将数据的处理工作放在服务器上，减少网络的开销，如使用存储过程。存储过程是编译好、优化过、并且被组织到一个执行规划里、且存储在数据库中的SQL语句，是控制流语言的集合，速度当然快。反复执行的动态SQL,可以使用临时存储过程，该过程(临时表)被放在Tempdb中。以前由于SQL SERVER对复杂的数学计算不支持，所以不得不将这个工作放在其他的层上而增加网络的开销。SQL2000支持UDFs,现在支持复杂的数学计算，函数的返回值不要太大，这样的开销很大。用户自定义函数象光标一样执行的消耗大量的资源，如果返回大的结果采用存储过程

    　　42、不要在一句话里再三的使用相同的函数，浪费资源,将结果放在变量里再调用更快

    　　43、Select COUNT(*)的效率教低，尽量变通他的写法，而EXISTS快.同时请注意区别： select count(Field of null) from Table 和 select count(Field of NOT null) from Table 的返回值是不同的!!!

    　　44、当服务器的内存够多时，配制线程数量 = 最大连接数+5，这样能发挥最大的效率;否则使用 配制线程数量<最大连接数启用SQL SERVER的线程池来解决,如果还是数量 = 最大连接数+5，严重的损害服务器的性能。

    　　45、按照一定的次序来访问你的表。如果你先锁住表A，再锁住表B，那么在所有的存储过程中都要按照这个顺序来锁定它们。如果你(不经意的)某个存储过程中先锁定表B，再锁定表A，这可能就会导致一个死锁。如果锁定顺序没有被预先详细的设计好，死锁很难被发现

    　　46、通过SQL Server Performance Monitor监视相应硬件的负载 Memory: Page Faults / sec计数器如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。

    　　Process:

    　　1、% DPC Time 指在范例间隔期间处理器用在缓延程序调用(DPC)接收和提供服务的百分比。(DPC 正在运行的为比标准间隔优先权低的间隔)。 由于 DPC 是以特权模式执行的，DPC 时间的百分比为特权时间百分比的一部分。这些时间单独计算并且不属于间隔计算总数的一部 分。这个总数显示了作为实例时间百分比的平均忙时。

    　　2、%Processor Time计数器　如果该参数值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。

    　　3、% Privileged Time 指非闲置处理器时间用于特权模式的百分比。(特权模式是为操作系统组件和操纵硬件驱动程序而设计的一种处理模式。它允许直接访问硬件和所有内存。另一种模式为用户模式，它是一种为应用程序、环境分系统和整数分系统设计的一种有限处理模式。操作系统将应用程序线程转换成特权模式以访问操作系统服务)。特权时间的 % 包括为间断和 DPC 提供服务的时间。特权时间比率高可能是由于失败设备产生的大数量的间隔而引起的。这个计数器将平均忙时作为样本时间的一部分显示。

    　　4、% User Time表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。 Physical Disk: Curretn Disk Queue Length计数器该值应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。 SQLServer:Cache Hit Ratio计数器该值越高越好。如果持续低于80%，应考虑增加内存。 注意该参数值是从SQL Server启动后，就一直累加记数，所以运行经过一段时间后，该值将不能反映系统当前值。

    　47、分析select emp_name form employee where salary > 3000 在此语句中若salary是Float类型的，则优化器对其进行优化为Convert(float,3000)，因为3000是个整数，我们应在编程时使用3000.0而不要等运行时让DBMS进行转化。同样字符和整型数据的转换。　48、查询的关联同写的顺序

    　　 　　select a.personMemberID, * from chineseresume a,personmember b where personMemberID = b.referenceid and a.personMemberID = 'JCNPRH39681' （A = B ,B = '号码'） 
    　　
    　　select a.personMemberID, * from chineseresume a,personmember b where a.personMemberID = b.referenceid and a.personMemberID = 'JCNPRH39681' and b.referenceid = 'JCNPRH39681' （A = B ,B = '号码'， A = '号码'） 
    　　
    　　select a.personMemberID, * from chineseresume a,personmember b where b.referenceid = 'JCNPRH39681' and a.personMemberID = 'JCNPRH39681' （B = '号码'， A = '号码'） 

    　　49、

    　　(1)IF 没有输入负责人代码 THEN code1=0 code2=9999 ELSE code1=code2=负责人代码 END IF 执行SQL语句为: Select 负责人名 FROM P2000 Where 负责人代码>=:code1 AND负责人代码 <=:code2

    　　(2)IF 没有输入负责人代码 THEN 　Select 负责人名 FROM P2000 ELSE code= 负责人代码 Select 负责人代码 FROM P2000 Where 负责人代码=:code END IF 第一种方法只用了一条SQL语句,第二种方法用了两条SQL语句。在没有输入负责人代码时,第二种方法显然比第一种方法执行效率高,因为它没有限制条件; 在输入了负责人代码时,第二种方法仍然比第一种方法效率高,不仅是少了一个限制条件,还因相等运算是最快的查询运算。我们写程序不要怕麻烦

    　　50、关于JOBCN现在查询分页的新方法(如下)，用性能优化器分析性能的瓶颈，如果在I/O或者网络的速度上，如下的方法优化切实有效，如果在CPU或者内存上，用现在的方法更好。请区分如下的方法，说明索引越小越好。

    　　 　　begin 
    　　
    　　DECLARE @local_variable table (FID int identity(1,1),ReferenceID varchar(20)) 
    　　
    　　insert into @local_variable (ReferenceID) 
    　　
    　　select top 100000 ReferenceID from chineseresume order by ReferenceID 
    　　
    　　select * from @local_variable where Fid > 40 and fid <= 60 
    　　
    　　end 和 
    　　
    　　begin 
    　　
    　　DECLARE @local_variable table (FID int identity(1,1),ReferenceID varchar(20)) 
    　　
    　　insert into @local_variable (ReferenceID) 
    　　
    　　select top 100000 ReferenceID from chineseresume order by updatedate 
    　　
    　　select * from @local_variable where Fid > 40 and fid <= 60 
    　　
    　　end 的不同 
    　　
    　　begin 
    　　
    　　create table #temp (FID int identity(1,1),ReferenceID varchar(20)) 
    　　
    　　insert into #temp (ReferenceID) 
    　　
    　　select top 100000 ReferenceID from chineseresume order by updatedate 
    　　
    　　select * from #temp where Fid > 40 and fid <= 60 drop table #temp 
    　　
    　　end 

    　另附：存储过程编写经验和优化措施 From：网页教学网
    　　一、适合读者对象：数据库开发程序员，数据库的数据量很多，涉及到对SP(存储过程)的优化的项目开发人员，对数据库有浓厚兴趣的人。
    　　二、介绍：在数据库的开发过程中，经常会遇到复杂的业务逻辑和对数据库的操作，这个时候就会用SP来封装数据库操作。如果项目的SP较多，书写又没有一定的规范，将会影响以后的系统维护困难和大SP逻辑的难以理解，另外如果数据库的数据量大或者项目对SP的性能要求很，就会遇到优化的问题，否则速度有可能很慢，经过亲身经验，一个经过优化过的SP要比一个性能差的SP的效率甚至高几百倍。
    　　三、内容：
    　　1、开发人员如果用到其他库的Table或View，务必在当前库中建立View来实现跨库操作，最好不要直接使用“databse.dbo.table_name”，因为sp_depends不能显示出该SP所使用的跨库table或view，不方便校验。
    　　2、开发人员在提交SP前，必须已经使用set showplan on分析过查询计划，做过自身的查询优化检查。　　3、高程序运行效率，优化应用程序，在SP编写过程中应该注意以下几点：
    　　a)SQL的使用规范：
    　　i.　尽量避免大事务操作，慎用holdlock子句，提高系统并发能力。
    　　ii.　尽量避免反复访问同一张或几张表，尤其是数据量较大的表，可以考虑先根据条件提取数据到临时表中，然后再做连接。
    　　iii.　尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该改写;如果使用了游标，就要尽量避免在游标循环中再进行表连接的操作。
    　　iv.　注意where字句写法，必须考虑语句顺序，应该根据索引顺序、范围大小来确定条件子句的前后顺序，尽可能的让字段顺序与索引顺序相一致，范围从大到小。
    　　v.　不要在where子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
    　　vi.　尽量使用exists代替select count(1)来判断是否存在记录，count函数只有在统计表中所有行数时使用，而且count(1)比count(*)更有效率。
    　　vii.　尽量使用“>=”，不要使用“>”。
    　　viii.　注意一些or子句和union子句之间的替换
    　　ix.　注意表之间连接的数据类型，避免不同类型数据之间的连接。
    　　x.　注意存储过程中参数和数据类型的关系。
    　　xi.　注意insert、update操作的数据量，防止与其他应用冲突。如果数据量超过200个数据页面(400k)，那么系统将会进行锁升级，页级锁会升级成表级锁。

    　　b)索引的使用规范：
    　　i.　索引的创建要与应用结合考虑，建议大的OLTP表不要超过6个索引。
    　　ii.　尽可能的使用索引字段作为查询条件，尤其是聚簇索引，必要时可以通过index index_name来强制指定索引
    　　iii.　避免对大表查询时进行table scan，必要时考虑新建索引。
    　　iv.　在使用索引字段作为条件时，如果该索引是联合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用。
    　　v.　要注意索引的维护，周期性重建索引，重新编译存储过程。
    　　c)tempdb的使用规范：

    　　i.　尽量避免使用distinct、order by、group by、having、join、cumpute，因为这些语句会加重tempdb的负担。
    　　ii.　避免频繁创建和删除临时表，减少系统表资源的消耗。
    　　iii.　在新建临时表时，如果一次性插入数据量很大，那么可以使用select into代替create table，避免log，提高速度;如果数据量不大，为了缓和系统表的资源，建议先create table，然后insert。
    　　iv.　如果临时表的数据量较大，需要建立索引，那么应该将创建临时表和建立索引的过程放在单独一个子存储过程中，这样才能保证系统能够很好的使用到该临时表的索引。

    　　v.　如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先truncate table，然后drop table，这样可以避免系统表的较长时间锁定。
    　　vi.　慎用大的临时表与其他大表的连接查询和修改，减低系统表负担，因为这种操作会在一条语句中多次使用tempdb的系统表。
    　　d)合理的算法使用：
    　　根据上面已提到的SQL优化技术和ASE Tuning手册中的SQL优化内容,结合实际应用,采用多种算法进行比较,以获得消耗资源最少、效率最高的方法。具体可用ASE调优命令：set statistics io on, set statistics time on , set showplan on 等。

    查看(252) 评论(0) 收藏 分享 管理

  • Use Case

    2008-12-09 15:30:07

    　　用例

    　　Use Case（用例）是一个UML中非常重要的概念，在使用UML的整个软件开发过程中，Use Case处于一个中心地位。

    　　那么，到底什么是Use Case呢？在UML的文档中，Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。有点拗口，对吧？其实Use Case就是对系统功能的描述而已，不过一个Use Case描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。（唔？Use Case也没什么特别的嘛！怎么这玩意儿会在开发中处于一个中心地位呢？）在使用UML的开发过程中，需求是用Use Case来表达的，界面是在Use Case的辅助下设计的，很多类是根据Use Case来发现的，测试实例是根据Use Case来生成的，包括整个开发的管理和任务分配，也是依据Use Case来组织的。啊，Use Case，简直太重要了！好了，Use Case就吹到这儿，具体的使用还要在实践中去体会，“运用之妙，存乎一心” 也！

    　　对于每个Actor来说，他都要使用系统的某项功能，所以我们识别和分析Use Case是，要 对于每个Actor来逐个进行。对于ToDo User，我们可以轻易的识别出两个Use Case：Add Task 和 Remove Task。ToDo User主动使用这两个Use Case所描述的系统功能，所以在我们的Use Case图上，ToDo User和这两个Use Case的关系是用从ToDo User发出的箭来表示的。对于FileSystem，我们识别出的也是同样的两个Use Case，不过这次箭头从Use Case指向FileSystem，表示FileSystem是被动的。

    　　Use Case可以用很多方式来描述，我们可以用自然语言（英语，汉语，随您的便），可以用形式化语言（哇！太酷了吧！），也可以用各种图示。在UML中，通常用两种图来描述Use Case，它们就是顺序图（Sequence Diagram）和协作图（Collaboration Diagram）

    　　Use Case 由以下元素组成：

    　　名称

    　　简单描述

    　　事件流

    　　关系

    　　活动图和状态图

    　　Use Case 图

    　　特殊需求

    　　前条件

    　　后条件

    　　一、谈谈对use case有关术语翻译的看法。

    　　笔者认为“用例”是目前较好的译法，这个词可能来源于大家熟知的“测试用例”。有人认为把use case翻译成“用例”是错误的，理由是：“‘例’是被列举出来以说明某种情况的个别事物，use case是对一项系统功能使用情况的普遍适应的描述，而不是对个别actor或者在个别条件下使用这项功能才适应，它也不是通过举例的方式来描述的”，所以不能叫作“用例”。此种说法不尽全面,而且有些牵强（先不管它正确与否），其实use case到底是个别的，还是群体的（普遍适应），取决于我们的视点。虽然对于单个的scenario来说，use case是多个情节的叠加，是一个整体的复合概念，但是我们知道，一个系统的功能必定是可数的、有限的，而每一个功能都可以表示为一个use case，所以在观察系统提供的所有功能需求的集合这个层面上，use case又是一个一个可数的个体（“椭圆”），每一个都代表了不同的用户目标，适用于个别的actor和个别特定的前置条件。同一个事物既是个体的又是整体的，这种现象并不足怪，例如在UML对象-类-类元关系中，通常对象是类的实例，而类又是类元的实例，对类元来说，类、接口、子系统、use case等等就是一个个个体的概念，类既是其对象实例的集合又是其类元集合的个别元素。可见，把use case的“case”译成“例”并没有错。

    　　有的地方把use case翻译成“用况”，即“使用的情况”之意，意思的确不错（use case的另一种说法是“使用的方式”）！可我总感觉这个词比较突兀、拗口，类似的还有“用案”，把scenario叫作“案况”，大概这些词读起来不太符合大家的习惯（类似地，既然可以叫“用况”，为什么不能叫“用情”呢？），所以现在“用例”的叫法还是越来越多了。

    　　其实“用例”这个译法还有个附带的好处，通过它我们很容易把原本就存在紧密联系的use case和test case（test case来自于对scenario的分析，而scenario是用例的一次执行）从中文名称上也方便地统一起来。不过，这里我们需要做一个小小的改进。中文的“测试用例”到底是指test case（带定语的名词词组）呢，还是指对用例进行测试（testing the use cases，动宾词组）呢？显然这两者不易分辨，而且若“用例”和“测试用例”两个词同时出现在一啰个句子或一段话中，常常会让人感觉嗦和便扭。为了消除歧义，干脆以后把test case都叫做“测例”，这样不但比以前的叫法更加简洁明了，而且无论字面上还是语义上都很贴切。当然，用例和测例是不同层面的“例”。

    　　现在市面上Actor也有多种译法，常见的包括“参与者、执行者、主角”等等。“参与者、执行者”的问题主要是不准确。首先，“参与者” 通常让大家马上想到的词是participant，而且请注意，一个用例的真正参与者决不是只有外部的Actor，它们必然还包括系统本身及其内部的各种元素。“执行者”的问题与此类似：一个用例的真正执行者应该是系统本身！因此严格地讲这样译是错误的，兴许叫作“外部参与者”、“外部执行者”才更为恰当。“主角”的译法同样存在着矛盾。如果把Actor叫作“主角”，那么Primary Actor就应该叫作“主主角”了。看来Actor的译法中是不能含有“主”的，那么就剩下“角”了，而UML已经有了一个专门术语role（角色），我们又不能把Actor直接叫作“角色”。

    　　目前看来，把Actor意译成“使用者”是比较妥当的。在大多数情况下Actor的的确确就是用户（确切地说是系统用户所扮演的一种角色），所以我们可以用“使用者”这个词从字面上与“用户”（user）进行区分，但同时又保持两者语义上的联系。我们还可以把为系统服务的Supporting/Secondary Actor（见下文）叫做“被使用者”（为了简化可以省略“被”字）或“辅使用者”。除了指系统的用户之外，“使用者”还有另一层含义，即Actor是use case的使用者（或被使用者），这种关系在UML用例图上应该可视化地表示为它们之间的连线（关联）。这样解释不但说的通，而且更便于不熟悉软件技术的业务人员理解。

    　　当然，我们也不排除将来会找到“use case”、“actor”等术语更好的译法。

    　　二、USE CASE的来历

    　　Ivar Jacobson在1967年定义爱立信AXE系统的够架时开始书写使用场境usage scenarios。

    　　二十世纪八十年代中期Jacobson花了很多精力来思考过去十多年的工作方法。他造了一个术语anvendningsfall，大意是“使用情况”（situation of usage）或用况（usage case）。但当用英文出版的时候，他发现“useage case”在英语里说不通，所以写作用例“use case”

    　　三、创建USE CASE的原则

    　　用例是短文

    　　用例可以是一个场景，包括动作和互交。

    　　用例可以是一组场景，描述不同场景下的行为。这种书写格式可以在任何时候描述有变体的行为，例如黑盒需求，业务流程，系统设计说明。

    　　用例里不要有系统设计

    　　用例里不要有界面设计

    　　用例里不要有特性列表

    　　用例里不要有测试

    　　用例应该描述行为需求

    　　用例的主场景不要超过九步。可以在适当的层次上得到子目标和移除设计说明。

    　　用例的最大价值不在于主场景，而是在于备选行为。主场景可能只占用例长度的四分之一到十分之一。

    　　四、Use Case 事件流

    　　Use Case具有一个基本事件流（可称为"理想路径"）、多个例外流，包括：

    　　基本变化

    　　特殊情况

    　　处理错误情况的异常事件流

    　　五、Use Case 说明书

    　　Use Case 说明书应包括以下内容：

    　　功能描述

    　　可用性

    　　可靠性

    　　性能

    　　可支持性

    　　设计约束

    　　六、Use Cases将做成多大？

    　　试图决定Use Case的大小是一个很有趣的话题，处理这件事的一个方法是将Use Case的大小跟它的意图和范围关联起来，对于一个真正大的范围来说，一个Use Case并不要在一个系统中处理那么多，但这些系统都用于同一商业领域，称为Business Use Case，它把整个公司看作一个黑盒和Actor关于公司目标的说明。这些Business Use Case的场景不允许假定任何公司内部的结构，一个客户将向公司下一个定单而不是客户服务部门。

    　　对于系统发展而言，Use Case的范围限制一个单一的系统，这是Use Cases最通常的形式，我们称之为System Use Case，它把整个系统看作是一个黑盒，它不指定任何内部结构并且仅受限于问题域的语言描述。

    　　Use Cases的另一范围是设计子系统和系统内部组件的，称为Implementation Use Cases，它把组件看作一个黑盒，并且这些Actors是区分它的成员。例如：可能会用Implementation Use Cases去说明应用系统中email组件的需求。

    　　给出了这些分类，关于Use Case的大小话题变得容易了，设计这些项的范围来调整整个大小。帮助系统设计者，每个Use Case只描述没有大的分支的行为的单个线索。违背这个规定，Use Case看起来通常是不准确的或含糊的，作为测试说明的资源和参考，它也是很难使用的。

    　　七、Use Cases的说明

    　　Use Cases的好处是一些情节能用不同程度的正规化的文字说明。每个情节涉及Use Cases中单一的途径，细节是条件组。

    　　不正规的文本描述也能使用，不过当条件较多和可能失败的情况下它们很难跟随下去。开始试图理解需求时，不正规的叙述风格也是非常有用的，然而随着Use Cases的进展，使用更加正规的机制去说明Use Cases才是有用的。

    　　下面是客户对Use Case“下定单”的粗略概略：

    　　“确定客户，找出需要的并且仓库里还有的物品并检查客户信用额是否够用”

    　　结构化叙述的格式已经被证明是非常有效的。这个格式所做的事是描述每一个情节的行为者：目标语句对顺序的叙述。在这个顺序中，每一个行为者：目标的语句对都假设前一个的目标是成功的，右面是一个简单的范例：

    　　Use Cases认为我们正在设计的系统是一个单一的黑盒，根本没有任何内部结构被记录下来，并且它被认为是一个情节产生的目的及对应单一的行为者（Actor）。这些Use Cases没有表示任何关于系统内部的东东，只是表示系统将达到什么样的目标及由什么（人或其它系统）操作和负责。

    　　八、Use Cases使需求有利于回顾

    　　Use Cases已经得到越来越广泛的应用，它与其它需求捕获技术相比，它成功的原因在于：

    　　1 　Use Cases把系统当作一个黑盒

    　　2 　Use Case 使在需求中看到实现的决定变得更加容易

    　　最后一点源于第一点的补充，一个Use Case没有指定任何这些需求相关的系统的内部结构，所以说，如果这个Use Case中陈述了"提交改变到定单数据库"、"显示结果到Web页面"等的话，那么内部结构是显而易见的，并造成对设计的潜在约束。

    　　为什么这些需求不指定内部结构的原因是，说明的内部结构给设计者带来了额外的约束，没有这些约束设计者们能更自由地建立一个正确实现客观可见行为的系统，并存在出现突破方案的可能性。

    　　九、Use Cases的图形符号

    　　这里是Use Cases的图形符号描述，UML中一个单一的"Stick-Man"符号标示角色（Actor），用椭圆标示Use Cases，如

    　　（图一）所示。这些图对于你想看到Use Cases之间如何关联的"大图"和获得系统上下文的大体描述来说是非常重要的。

    　　Use Cases图没有显示不同的场景，它们的意图是显示角色和Use Cases之间的关系。所以Use Cases图需求用结构化叙述文本来补充。UML提供一些可供选择的图来显示不同的场景，这些常规的图形有交互图、活动图、顺序图、状态图等（本文暂不讨论这些图）。使用这些图的主要缺点是它们不象文本一样是紧密的，但它们能用于给出Use Case的整体感觉。

    　　十、Use Case 的评价标准

    　　是否每个Use Case 都包括至少一个actor？

    　　是否每个Use Case 都独立于其他Use Case？

    　　是否每个Use Case 都有一个简单的行为或事件流？

    　　是否每个Use Case 都有一个唯一的、直观的、可扩展的名称，使它不至于在后期被混淆。

    　　用户是否容易理解Use Case 的名称和描述。

    　　十一、Use Case 模型的评价标准

    　　Use Case模型显示系统中的Use Case与Actor 及其相互关系。其评价标准有：

    　　Use Case 模型是可理解的吗？

    　　通过对Use Case 模型的研究是否能对系统功能有一个清晰的概念。

    　　所有的actor都定义了吗？所有的功能需求都满足了吗？

    　　Use Case 模型是否存在多余的行为。

    　　从模型到Use Case包的划分是否是恰当的。

    　　十二、使用Use Case 的误区

    　　由于具有简单的图形符号、易理解的自然语言说明书，Use Case在文档系统和软件需求领域成为一 项越来越受欢迎的技术。Use Case对开发小组极具吸引力，即使小组成员对正式的需求文档没有经验，但这些简单性却具有欺?


    查看(1139) 评论(3) 收藏 分享 管理

  • ODC(Orthogonal Defect Classification)简介

    2008-11-28 13:27:34

    转自：http://www.ibm.com/developerworks/cn/java/j-odc/

    Defect分析是软件开发和测试中一个重要的环节，ODC介绍了一种不同于大家常 用的非常有效的defect分类及分析方法。这篇文章简单的向大家介绍了什么是ODC，以及如何在项目和产品开发中使用ODC来改进开发测试流程从而增强 产品质量。希望读者具有基本的软件开发和测试经验，并且了解defect分析的基本方法。

    Defect 分类帮助改进产品质量

    软件开发中都包含有控制软件开发的流程。我们设计模块、开发代码、对产品进行测试、然后发布产品。但是，我们怎样从以前的错误中学习，怎样做得更好 呢？一般情况下，我们会拿一些输出的数据来进行分析，从而知道我们应该怎么样和进行什么样的改进（如图1）。但是如何确定我们做的努力是真正有用的呢？这 就是defect classification (defect分类) 能够帮助我们的地方，如果我们可以正确的使用defect classification，它会对我们有很多的帮助。


    图1
    图1






    几种常见的defect 分类方法

    在软件开发过程中我们会在不同的阶段发现数量不等的defect，如图2所示，对于所发现的defect我们可以逐一的对它们进行分析，例如使用 root causal analysis方法，可是这种分析方法占用了大量的时间和资源，显然我们非常需要有一种方法可以明确地告诉我们应该在哪里改进。


    图2
    图2

    下面我们来看看几种我们常见的defect 分析方法：

    按照defect 严重程度分类

    我们在测试过程中会根据defect的严重程度对defect 进行分类，在这里我们将严重度称为severity, 我们有如下图所示的一个项目不同测试阶段的defect的分布图：


    图3
    图3

    在这个图中defects跟据它们的severity属性进行了分类， severity为1的defect是最严重的defect, 它使系统根本不能运转，需要立即进行改正。那severity为 2的defect 是一般功能性的错误，这些错误是需求中所要求的，必须改正才能实现系统完整的功能。Severity 为3的defect是一些细小的错误，它们不影响功能的实现，但可能引起用户的误解或者使用不当。Severity为4 的 的defect是测试人员建议改进的地方，如果时间允许开发人员可以选择性的改正，或者等到下个版本中再改进。从图3中我们可以看到第一个图是在一个项目 测试前期的时候，这时候1级的defect很多，整个系统还不能够运转，正需要大量的时间和人力进行测试和改正代码错误。第二个图则显示项目测试已经到了 中期，这时候最严重的defect已经很少了，系统已经基本可以运转，然后测试人员发现了大量的功能性的错误和细节上的错误需要改正。第三个图显示了项目 测试已经到了末期，这时的产品需求的功能已经实现，只有部分细节和建议需要改进，产品已经可以发布了。在用severity分类的图表中，我们可以了解到 以下有关项目的几个方面：

    1) 工作的优先级

    2) 项目的进展状态

    3) 产品的质量

    按照component/module分类

    对于不同的component或者module，我们也可以有类似的defect分布图来说明另外一些问题：


    图4
    图4

    图4中，对于第一个图，我们能看出C模块中发现的defect明显的比其他模块的少，那么原因可能是C模块的开发人员技术非常的好。第二个图中我们 可以看出A和C中发现的defect明显比其他两个模块的多，那么可能这两个模块的难度、大小或者是改动的变化比较大，因此而造成了它们中发现的 defect比较多。对于第三个图，C模块的defect明显比其他的多，那么可能是C模块的开发人员太差了，需要管理者的特别关注了。






    Orthogonal Defect Classification简介

    下面我们来介绍ODC，什么是ODC（Orthogonal Defect Classification）呢？简单的说，它是另外一种defect分类的方法，它使你能够快速得到每一个问题的信息来帮助你后面做出正确的决定来解决问题。

    开发中应用ODC

    作为一个开发人员我发现的问题如果按类型（type）分类可能是由如下几种可能：(括号中的英文为缩写图例)

    1) 没有正确的初始化 （Init）

    2) 代码没有正确的check-in （Chk）

    3) 算法问题 （Alg）

    4) 功能性的错误，可能是模块内的功能没有被正确实现，也可能是模块与模块之间相联系的部分没有被正确实现。（Fnct Cls）

    5) 有可能是有关时间的错误 （Time）

    6) 界面相关的错误 （Intf）

    7) 代码之间相关联的错误，例如错误的继承关系 （Rel'n）

    按照type的分类我们有如下的分布图：


    图5
    图5

    图6
    图6

    从图5、图6中，我们可以了解到开发过程中哪个环节的错误比较多，例如图6中算法错误和功能性错误是最多的那么应该在单元测试或者code review中着重注意这两个部分的代码质量。另外从上图中我们也可以知道在哪以及如何来改正错误代码。

    功能测试中应用ODC

    下面我们来看看测试，在FVT（功能测试）中，一个主要的帮助FVT做得更好的指标是trigger, 在ODC中trigger可以简单的理解为是什么样的测试发现了这个defect。在FVT中我们定义了一下4个trigger：Coverage (这里的coverage不是我一般意义上理解的测试覆盖面的意思，它是指normal function, 是任何用户都会用到的功能，基本的、简单的功能)，Variation （对于有些对产品比较熟悉的用户，有可能会愿意用不常用的有创造性方法或者输入来完成同一种动作或者功能，或者单单就是为了挑错，在这些尝试中往往会发现 很多漏掉的defect，例如'边界限制'），Sequencing (用和以前不同的操作流程来完成一种任务功能)，Interaction （当两个或者多个功能模块互相交互时可能会发生一些错误，例如同时启动一些功能时可能会造成系统死机）。

    下面我们举例来看看FVT中按trigger分类的defect分布图：


    图7
    图7

    在图7中我们可以看到，这个产品中在一般的功能Coverage和改变操作顺序Sequencing的测试中发现了比较多的defect, 这说明了代码还需要作更多的单元测试来减少错误，从而我们可以了解到产品的基本质量水平。


    图8
    图8

    在图8中我们可以看到Coverage的错误很少，产品的基本质量是可以保证的；Variation的错误很多（看来测试组做了大量的这方面的测 试），Sequencing 和 Interaction的错误也不少，那么后面的测试中应该加大这两块儿的测试。这里我们可以清楚地知道我们测了什么还有哪块需要加大测试力度。


    图9
    图9

    在图9中我们可以看到Variation的错误很多，那么加大单元测试的力度可以很好的解决这个问题，例如增加更多的边界检查。

    系统测试中应用ODC

    下面再让我们来看看SVT(系统测试)， 在系统测试中，ODC定义了另外一组trigger, 它们是：Blocked （有哪些defect阻止了SVT的执行， 最常见的是FVT的defect），Stress （压力测试的结果很可能是客户最关心的数据），Recovery (对于数据恢复和出错处理)，Restart (x系统的启动和重启)，Hardware configuration (硬件配置)，Software configuration (软件配置)。 下面我们举例来看看SVT中按trigger分类的defect分布图：


    图10
    图10

    在图10中我们看到了Blocked的defect太多了，显然这个时候进行大量的SVT测试是不明智的，那么应该让产品继续的进行功能测试，直到Blocked的问题减少到可以接受为止。


    图11
    图11

    在图11中，我们同样可以了解到SVT中进行了哪些测试，在这里软件配置测试和压力测试是需要加强的。


    图12
    图12

    在图12中，我们可以了解到硬件配置的defect比较多，那么我们应该要求开发人员更关注这部分的代码。

    从上面的分析中我们看到了ODC中trigger告诉了我们哪里发现了问题，应该去做些什么。

    ODC对于客户影响的应用

    那么下面我们再来看看ODC怎么样的来影响客户。软件产品对于客户的影响有哪些方面呢？在ODC中定义了如下方面：

    1. Installability
    2. Security
    3. Performance
    4. Maintenance
    5. Serviceability
    6. Migration
    7. Documentation
    8. Usability
    9. Standards
    10. Reliability
    11. Requirements
    12. Capability


    图13
    图13

    这里图13是一个产品的defect 影响分布图, 我们可以看到这个产品有非常多的问题出在 "capability性能"、"reliability可靠性"、和"usability可用性"上，那么这样的产品如果卖给客户将是可怕的，那么我们 就应该采取相应的动作来完善这几个方面的问题。

    在ODC中，还定义了其他的元素来组合使用以帮助我们更好的了解问题出在哪里，同时帮助我们做出正确的决定。

    在测试人员发现一个问题并且开一个defect时，需要给defect定义下面的属性：

    1) Activity, 它是指在哪种测试中发现的defect, 例如：UT、FVT、SVT 等等。

    2) Trigger, 问题出现的情况

    3) Impact，影响客户的方面

    当开发人员接到一个defect并且开始修改代码时，他需要定义下面的属性：

    1) Target, 将要在哪里改正错误，例如：design、code 等等

    2) Defect Type, defect的类型，例如：算法、初始化 等等

    3) Qualifier: 只有三个，他们是missing、incorrect 和extraneous

    4) Source: defect 的来源，例如：内部代码、outsource的代码等等

    5) Age: defect是新代码还是重写的代码

    具体可以参考下图：


    图14
    图14



    结束语

    在项目和产品开发中，我们经常会想到这样的问题：我们的测试有多有效？单元测试、功能测试、系统测试都做得正确吗？我们怎样在需求、设计、开发阶段 来减少潜在的defect呢？我们的代码已经完成并且准备好了进入到下一个阶段了吗？我们发现的defect有哪些是属于上一个版本的？客户将会感觉我们 的产品质量怎么样呢？这些都是很关键的问题，需要我们改进开发和测试流程，使它们更加有效，从而进一步增强我们产品的质量。那么怎么样改进呢？通过ODC 我们可以知道我们采用的哪种测试方法正在帮助我们找出更多的defect（是基本功能测试，还是边界条件测试或者压力测试），还有defect是由哪种错 误造成的（是初始化的问题或者界面的问题，还是其他的原因），错误是由于代码缺失还是代码错误造成的，defect是在老代码还是新代码中发现的, defect对于客户的影响有哪些有多大。找出了这些问题的答案，我们就可以改进我们开发和测试的有效性，增强产品模块的稳定性，更早的发现那些高风险的 模块，最后使产品的每个版本都比上一个版本质量更好。


    查看(442) 评论(0) 收藏 分享 管理

  • 重构（Refactoring）——何时重构（转）

    2008-11-26 15:57:22

    何时使用重构

    　　新官上任三把火，开始一个全新的项目时，程序员往往也会燃起三把火：紧锣密鼓、脚不停蹄、加班加点，一支声势浩大的千军万"码"夹裹着程序员激情和扣击键盘的鸣金奋力前行，势如破竹，攻城掠地，直指"黄龙府"。

    　　开发经理是这支浩浩汤汤代码队伍的统帅，他负责这支队伍的命运，当齐恒公站在山顶上看到管仲训练的 队伍整齐划一地前进时，他感叹说"我有这样一支军队哪里还怕没有胜利呢?"。但很遗憾，你手中的这支队伍原本只是散兵游勇，在前进中招兵买马，不断壮大， 所以队伍变形在所难免。当开发经理发觉队伍变形时，也许就是克制住攻克前方山头的诱惑，停下脚步整顿队伍的时候了。

    　　Kent Beck提出了"代码坏味道"的说法，和我们所提出的"队伍变形"是同样的意思，队伍变形的信号是什么呢?以下列述的代码症状就是"队伍变形"的强烈信号：

    　　·代码中存在重复的代码

    　　中国有118 家整车生产企业，数量几乎等于美、日、欧所有汽车厂家数之和，但是全国的年产量却不及一个外国大汽车公司的产量。重复建设只会导致效率的低效和资源的浪费。

    　　程序代码更是不能搞重复建设，如果同一个类中有相同的代码块，请把它提炼成类的一个独立方法，如果不同类中具有相同的代码，请把它提炼成一个新类，永远不要重复代码。

    　　过大的类和过长的方法

    　　过大的类往往是类抽象不合理的结果，类抽象不合理将降低了代码的复用率。方法是类王国中的诸侯国， 诸侯国太大势必动摇中央集权。过长的方法由于包含的逻辑过于复杂，错误机率将直线上升，而可读性则直线下降，类的健壮性很容易被打破。当看到一个过长的方 法时，需要想办法将其划分为多个小方法，以便于分而治之。

    　　牵一毛而需要动全身的修改

    　　当你发现修改一个小功能，或增加一个小功能时，就引发一次代码地震，也许是你的设计抽象度不够理想，功能代码太过分散所引起的。

    　　类之间需要过多的通讯

    　　A类需要调用B类的过多方法访问B的内部数据，在关系上这两个类显得有点狎昵，可能这两个类本应该在一起，而不应该分家。

    过度耦合的信息链

    　　"计算机是这样一门科学，它相信可以通过添加一个中间层解决任何问题"，所以往往中间层会被过多地追加到程序中。如果你在代码中看到需要获取一个信息，需要一个类的方法调用另一个类的方法，层层挂接，就象输油管一样节节相连。这往往是因为衔接层太多造成的，需要查看就否有可移除的中间层，或是否可以提供更直接的调用方法。

    　　各立山头干革命

    　　如果你发现有两个类或两个方法虽然命名不同但却拥有相似或相同的功能，你会发现往往是因为开发团队成员协调不够造成的。笔者曾经写了一个颇好用的字符串处理类，但因为没有及时通告团队其他人员，后来发现项目中居然有三个字符串处理类。革命资源是珍贵的，我们不应各立山头干革命。

    　　不完美的设计

    　　在笔者刚完成的一个比对报警项目中，曾安排阿朱开发报警模块，即通过Socket向指定的短信平台、语音平台及客户端报 警器插件发送报警报文信息，阿朱出色地完成了这项任务。后来用户又提出了实时比对的需求，即要求第三方系统以报文形式向比对报警系统发送请求，比对报警系 统接收并响应这个请求。这又需要用到Socket报文通讯，由于原来的设计没有将报文通讯模块独立出来，所以无法复用阿朱开发的代码。后来我及时调整了这个设计，新增了一个报文收发模块，使系统所有的对外通讯都复用这个模块，系统的整体设计也显得更加合理。

    　　每个系统都或多或少存在不完美的设计，刚开始可能注意不到，到后来才会慢慢凸显出来，此时唯有勇于更改才是最好的出路。

    　　缺少必要的注释虽然许多软件工程的 书籍常提醒程序员需要防止过多注释，但这个担心好象并没有什么必要。往往程序员更感兴趣的是功能实现而非代码注释，因为前者更能带来成就感，所以代码注释 往往不是过多而是过少，过于简单。人的记忆曲线下降的坡度是陡得吓人的，当过了一段时间后再回头补注释时，很容易发生"提笔忘字，愈言且止"的情形。

    　　曾在网上看到过微软的代码注释，其详尽程度让人叹为观止，也从中体悟到了微软成功的一个经验。

    查看(416) 评论(0) 收藏 分享 管理

  • 重构（Refactoring）——什么是重构（转）

    2008-11-26 15:54:53

     什么是重构

    　　重构是在编写代码后在不更改代码的外部行为的前提下通过更改代码的内部结构来改进代码的过程。目的是提高其可理解性,降低其修改成本。

    　　通俗的说法就是,程序的功能和结果没有任何的变化。重构只是对程序内部结构进行调整,让代码更加容易理解,然后更容易维护。

    　　为什么要重构

    　　至于为什么要重构，因本人才疏学浅，故特引用软件工程专家的一段话：

    　　在不改变系统功能的情况下，改变系统的实现方式。为什么要这么做?投入精力不用来满足客户关心的需求，而是仅仅改变了软件的实现方式，这是否是在浪费客户的投资呢?

    　　重构的重要性要从软件的生命周期说起。软件不同与普通的产品，他是一种智力产品，没有具体的物理形态。一个软件不可能发生物理损耗，界面上的按钮永远不会因为按动次数太多而发生接触不良。那么为什么一个软件制造出来以后，却不能永远使用下去呢?

    　　对软件的生命造成威胁的因素只有一个：需求的变更。一个软件总是为解决某种特定的需求而产生，时代在发展，客户的业务也在发生变化。有的需求相对稳定一些，有的需求变化的比较剧烈，还有的需求已经消失了，或者转化成了别的需求。在这种情况下，软件必须相应的改变。

    　　考虑到成本和时间等因素，当然不是所有的需求变化都要在软件系统中实现。但是总的说来，软件要适应需求的变化，以保持自己的生命力。

    　　这就产生了一种糟糕的现象：软件产品最初制造出来，是经过精心的设计，具有良好架构的。但是随着时间的发展、需求的变化，必须不断的修改原有的功能、追加新的功能，还免不了有一些缺陷需要修改。为了实现变更，不可避免的要违反最初的设计构架。经过一段时间以后，软件的架构就千疮百孔了。bug越来越多，越 来越难维护，新的需求越来越难实现，软件的构架对新的需求渐渐的失去支持能力，而是成为一种制约。最后新需求的开发成本会超过开发一个新的软件的成本，这就是这个软件系统的生命走到尽头的时候。

    　　重构就能够最大限度的避免这样一种现象。系统发展到一定阶段后，使用重构的方式，不改变系统的外部功能，只对内部的结构进行重新的整理。通过重构，不断的调整系统的结构，使系统对于需求的变更始终具有较强的适应能力。

    　　通过重构可以达到以下的目标：

    　　·持续偏纠和改进软件设计

    　　重构和设计是相辅相成的，它和设计彼此互补。有了重构，你仍然必须做预先的设计，但是不必是最优的设计，只需要一个合理的解决方案就够了，如果没有重构、程序设计会逐渐腐败变质，愈来愈像断线的风筝，脱缰的野马无法控制。重构其实就是整理代码，让所有带着发散倾向的代码回归本位。

    　　·使代码更易为人所理解

    　　Martin Flower在《重构》中有一句经典的话："任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类容易理解的程序才是优秀的程序员。"对此，笔者感触很深，有些程序员总是能够快速编写出可运行的代码，但代码中晦涩的命名使人晕眩得需要紧握坐椅扶手，试想一个新兵到来接手这样的代码他会不会想当逃兵呢?

    　　软件的生命周期往往需要多批程序员来维护，我们往往忽略了这些后来人。为了使代码容易被他人理解，需要在实现软件功能时做许多额外的事件，如清晰的排版布局，简明扼要的注释，其中命名也是一个重要的方面。一个很好的办法就是采用暗喻命名，即以对象实现的功能的依据，用形象化或拟人化的手法进行命名，一个很好的态度就是将每个代码元素像新生儿一样命名，也许笔者有点命名偏执狂的倾向，如能荣此雅号，将深以此为幸。

    　　对于那些让人充满迷茫感甚至误导性的命名，需要果决地、大刀阔斧地整容，永远不要手下留情!

    帮助发现隐藏的代码缺陷

    　　孔子说过：温故而知新。重构代码时逼迫你加深理解原先所写的代码。笔者常有写下程序后，却发生对自己的程序逻辑不甚理解的情景，曾为此惊悚过，后来发现这种症状居然是许多程序员常患的"感冒"。当你也发生这样的情形时，通过重构代码可以加深对原设计的 理解，发现其中的问题和隐患，构建出更好的代码。

    　　·从长远来看，有助于提高编程效率

    　　当你发现解决一个问题变得异常复杂时，往往不是问题本身造成的，而是你用错了方法，拙劣的设计往往导致臃肿的编码。

    　　改善设计、提高可读性、减少缺陷都是为了稳住阵脚。良好的设计是成功的一半，停下来通过重构改进设计，或许会在当前减缓速度，但它带来的后发优势却是不可低估的。

    查看(471) 评论(0) 收藏 分享 管理

  • 软件测试面试题及解答

    2008-11-10 10:03:52



    　　第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需要web服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了tomcat，所以只要有tomcat即可

    　　第四步：执行测试

    10. 您以往是否曾经从事过性能测试工作？如果有，请尽可能的详细描述您以往的性能测试工作的完整过程。

    　　是的，曾经做过网站方面的性能测试，虽然做的时间并不久（2个月吧），当时呢，是有位网站性能测试经验非常丰富的前辈带着我一起做。

    性能测试类型包括负载测试，强度测试，容量测试等

    　　负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。

    　　强度测试： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况

    　　容量测试：确定系统可处理同时在线的最大用户数  

    　　在网站流量逐渐加大的情况下，开始考虑做性能测试了，首先要写好性能测试计划，根据运营数据得出流量最大的页面（如果是第一次的话，一般是首页，下载页，个人帐户页流量最大，而且以某种百分比），

    　　Web服务器指标指标：

    　　* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；

    　　* Successful Rounds：成功的请求；

    　　* Failed Rounds ：失败的请求；

    　　* Successful Hits ：成功的点击次数；

    　　* Failed Hits ：失败的点击次数；

    　　* Hits Per Second ：每秒点击次数；

    　　* Successful Hits Per Second ：每秒成功的点击次数；

    　　* Failed Hits Per Second ：每秒失败的点击次数；

    　　* Attempted Connections ：尝试链接数；　　

    11. 您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

    12. 您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？

    13. 在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

    14. 您以往所从事的软件测试工作中，是否使用了一些工具来进行软件缺陷（Bug）的管理？如果有，请结合该工具描述软件缺陷（Bug）跟踪管理的流程。

    15. 您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？

    16. 在您以往的测试工作中，最让您感到不满意或者不堪回首的事情是什么？您是如何来对待这些事情的？

    17. 在即将完成这次笔试前，您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会？（可以包括软件测试、过程改进、软件开发或者与此无关的其他方面）

    18.你对测试最大的兴趣在哪里？为什么？

    　　最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了十一二点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1、2点我没有把握，其他点我都很有信心做好它。

    　　刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。

    　　不到一年半的测试工作中，当时的感动和热情没有减退一点（即使环境问题以及自身经验，技术的不足，做测试的你一定也能理解）。

    　　我觉得做测试整个过程中有2点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。

    　　第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。还有如何发现bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。如何描述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。

    19. 你的测试职业发展是什么？

    　　测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经验，按如何做好测试工程师的11，12点要求自己，不断的更新自己改正自己，做好测试任务。

    20. 你自认为测试的优势在哪里？

    　　优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但测试需要的基本技能我有信心在工作中得以发挥。
    软件开发网 www.mscto.com


    21. 你以前工作时的测试流程是什么？

    　　公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。

    22. 当开发人员说不是BUG时，你如何应付？

    　　开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。



    23．你为什么想离开目前的职务？

    　　因为公司运作情况并不理想，公司需要调整部门体系，公司考虑到缩减部门人员，所以大批量的裁员（有6，7个），这是我的第一份工作，对公司也有较深的感情，因为在这里我找到了职业理想（就是测试），所以公司需要精简人员，我自愿退出。虽然很舍不得，但我将会有新的发挥能力的舞台。

    24：你对我们公司了解有多少？

    25：你找工作时，最重要的考虑因素为何？

    　　工作的性质和内容是否能让我发挥所长，并不断成长。

    26：为什么我们应该录取你？

    　　您可以由我过去的工作表现所呈现的客观数据，明显地看出我全力以赴的工作态度。

    27：请谈谈你个人的最大特色。

    　　我的坚持度很高，事情没有做到一个令人满意的结果，绝不罢手。

    28.白箱测试和黑箱测试是什么?什么是回归测试?

    29。单元测试、集成测试、系统测试的侧重点是什么？

    30。设计用例的方法、依据有那些？

    31。一个测试工程师应具备那些素质和技能？

    32.集成测试通常都有那些策略？

    33.你用过的测试工具的主要功能、性能及其他？

    34.一个缺陷测试报告的组成

    35.基于WEB信息管理系统测试时应考虑的因素有哪些？

    36.软件测试项目从什么时候开始，？为什么？

    37.需求测试注意事项有哪些？

    38.简述一下缺陷的生命周期

    39.测试分析测试用例注意（事项）？

    查看(926) 评论(2) 收藏 分享 管理

  • RTM、RC、CTP版本的含义

    2008-11-04 13:23:14

    RTM版是最终压盘版，Release To Manufacturing，也就是交付给光盘制作厂商，这和最终发布版一样。发布RTM后，厂商若要修改就只有通过发布SP来完成了。

    RC版是发布候选版，Release Candidate，一般是RTM版本前的几个预览版，但是这个阶段来说基本功能已经完成，主要是用来捉bug了，所以发布RC后，基本功能不会有大的变化了，只要各种测试能够通过，这也表明最终发布不远了。

    CTP是社群技术预览版，Community Technology Preview，这个版本只是用来在社区内发布，验证市场情况和用户认可度，早于RC版，就像Atlas，在发布了多个CTP后，突然剑峰一转，变为了ASP.NET AJAX，让前期投入大量精力在Atlas上，如dflying chen他们就相当郁闷，所以说CTP版本不一定可靠，可能在功能上都会有大的变化。 

    查看(449) 评论(0) 收藏 分享 管理

Open Toolbar