qileilove

　　简介

　　SQL Server查询分析器是基于开销的。通常来讲，查询分析器会根据谓词来确定该如何选择高效的查询路线,比如该选择哪个索引。而每次查询分析器寻找路径时，并不会每一次都去统计索引中包含的行数，值的范围等，而是根据一定条件创建和更新这些信息后保存到数据库中，这也就是所谓的统计信息。

　　如何查看统计信息

　　查看SQL Server的统计信息非常简单，使用如下指令：

　　DBCC SHOW_STATISTICS('表名','索引名')

　　所得到的结果如图1所示。

图1.统计信息

　　统计信息如何影响查询

　　下面我们通过一个简单的例子来看统计信息是如何影响查询分析器。我建立一个测试表，有两个INT值的列，其中id为自增，ref上建立非聚集索引，插入100条数据，从1到100，再插入9900条等于100的数据。图1中的统计信息就是示例数据的统计信息。

　　此时，我where后使用ref值作为查询条件，但是给定不同的值，我们可以看出根据统计信息，查询分析器做出了不同的选择，如图2所示。

图2.根据不同的谓词，查询优化器做了不同的选择

　　其实，对于查询分析器来说，柱状图对于直接可以确定的谓词非常管用，这些谓词比如：

　　where date = getdate()
　　where id= 12345
　　where monthly_sales < 10000 / 12
　　where name like “Careyson” + “%”

　　但是对于比如

　　where price = @vari
　　where total_sales > (select sum(qty) from sales)
　　where a.id =b.ref_id
　　where col1 =1 and col2=2

　　这类在运行时才能知道值的查询，采样步长就明显不是那么好用了。另外，上面第四行如果谓词是两个查询条件，使用采样步长也并不好用。因为无论索引有多少列，采样步长仅仅存储索引的第一列。当柱状图不再好用时，SQL Server使用密度来确定最佳的查询路线。

　有这样一个脑筋急转弯的题目，不要试图去网络上寻找答案，思考一下，然后告诉我你的思考过程，不一定要有结果，找到答案不一定是最重要的，我更关心你的思考过程：以下是文章原文出处http://www.taixiaomei.com/archives/94。文章回答的很精辟，不敢独自保留，在此分享出来，供大家欣赏。

　　这一个等式很奇怪，0比2大，2比5大，5比0大，为什么？

　　When you see the following inequality, what will be the reasone, in your opinion? Don’t try to find the answer from the internet. Just tell me your thinking process.

　　0>2,  2>5,  5>0

　　Responses to 说一下你的思考过程 Tell me what you think

　　看到这个等式首先想到的是为什么是反的。然后就想肯定不是代表普通的数学比大小，因为有计算机背景，初步就想到是不是asc编码符的比大小。但是继续验证ASCII编码是不正确的，其本质还是数字的比大小，没有摆脱那个思维，换种思路，上面这个等式的0,2,5其实并不是看做数字来理解而是一种图形，比如0代表圆圈，那2和5又代表什么呢？

　　还是说不通，但是可以肯定的是0,2,5各自代表着某种已定的特殊含义，这种含义又有某种特殊的联系，现在就是要找出这种联。

　　有了新的数据，推翻了上一次的猜测。并且推出新的猜测：“0,2,5其实并不是看做数字来理解，0,2,5各自代表着某种已定的特殊含义，这种含义又有某种特殊的联系”，现在需要用新的数据来证明这种猜测是正确的。

　　这种既定联系的范围太广了，光从这个等式提供的信息量有点少啊。

　　这种状态是否似曾相识？你测试的时候，是否有过这样的时候，感觉毫无头绪，感觉效率很低，感觉没有思路。。。

　　这个时候，不妨试着运用Defocused Thinking，尽量拓宽自己的思路、找更多的数据（data）。或者运用Alternative Thinking，先做些别的事情，过一些时间再回来接着测试，也许就有新的思路了

　　很好，你找到了题目与圆在某一方面的相似性。但是这个就是那个“答案（bug）”了吗？你需要找到更多的数据，证明它就是你要找的

　　“答案”是我们最终要找的东西；我们测试的时候，bug不也是我们要找的东西吗？答案，事先你并不知晓在哪里，你也事先不知道bug藏在哪里，否则就没有必要测试了。都是在解决问题，都是在找寻未知，测试的乐趣也在于此了！

　　可以从软件质量和软件测试的角度来思考这个问题：

　　0、2、5分别表示软件测试中发现的bug数。0>2, 2>5：没有bug的程序固然比有2个bug的程序的代码质量高；类推，2个bug的比5个bug的代码质量高；5>0：0个bug不代表程序没有bug！而只能说由于个人测试方法、测试思维和知识的局限性导致了某些bug无法发现。从这个角度来讲，发现5个bug的测试用例和方法显然比没发现bug的用例和方法对保证软件测试质量的价值和意义重大。从某种角度来说0bug意味着测试方案的失败而非程序质量的成功。事实上，世界上最优秀的程序员，也不敢保证他的代码100%正确无误！

　　这是不是软件测试的博弈？

　　Well, I think I’ve got the key.0：石头；2：剪刀；5：布。

　　非常棒！终于找到了答案。说说我能想到的启发吧：

　　- 做这种题目就是一个寻找未知的过程，测试也是一个寻找未知的过程。这个未知可能是bug、可能是系统真实的表现

　　- 当你知道答案时，你可能觉得这也没有什么高深的，很容易理解，剪刀、石头、布嘛，换句话说，正向思考还是很容易的出这道题的，可是让你找答案时，就不是那么容易了，因为这时你得利用反向思考的方法，这就是测试的思维

　　- 不同的人思维方式区别很大，决定是否能找到这个答案和人的思维方式、知识经验都有很大关系，思维方式可以通过训练提高、知识经验可以通过学习和实践累积。【是的，我是在说，思维方式可以后天训练提升，而不是先天就决定了的】

　　-  所以多做做这种动脑筋的题目、多解解各种谜题、多做做拼图游戏、多玩玩魔法和数独等，都可以训练你的思维，包括边际思考能力、系统思考能力、逆向思考能力等等，这些都是你的学习能力

　　- 学习能力提高了，不管是产品知识还是测试知识，当然都对你来说不是什么难事了，你也能区分出来何时学习产品知识、何时补充测试知识、应该补充什么知识、应该补充多少知识了

　　- 测试中，我们经常可以使用溯因推理法（adbuctive inference），也就是假设性诱导法

　　1、你获得一些数据，希望能够解释这个数据

　　2、你想到数个可能的解释

　　3、你寻求更多的数据帮助你解释或反驳每一个解释

　　4、你选择最能帮助你解释所有其中重要的数据的解释

　　5、或者，你没有找到一个最合理的解释，那么继续寻找更多的数据

　　- 科学家们会经常使用溯因推理法，测试人员也经常使用溯因推理法，实际上有些研究表明科学家们的思考方式与测试人员非常相似，他们经常质疑其他人习以为常的 东西、他们经常做各种可能的假设然后去验证、他们会时而想到其他人想不到的方面，科学家们的发现发明不是因为科学家们都是天才、都有超人的智慧，而是因为 他们的思维方式。所以多读读科学、社会学、人文学、认知学，了解发现问题、解决问题的思考过程，对测试大有裨益。

　什么是Test Load Balancer ？

　　Test Load Balancer 测试分发工具，它能把所有的测试按照某个策略（数量、时间）均衡分布到不同的计算机上运行。

　　问题域？

　　一个典型的问题，当软件开发团队在做CI（持续集成）时，必须让CI的构建时间保持在一个合理的时间，比如10分钟为一个上线，但是由于需求的不断增多测试的数量也随之增加，花费在运行这些测试的时间越来越多，影响到了整个交付团队的进度。为了尽可能的缩短交付周期时间，减少测试的运行时间，一个行之有效的方法就是让测试并行执行。

　　Test Load Balancer 如何工作 ？

　　TLB（Test Load Balancer）有两个比较重要的概念：

　　server：存储，查询测试数据（测试时间、测试结果等）

　　balancer：测试分支，指定测试套件，设置server的url等

　　Balancer与CI或者与某种测试框架一起工作，Server只是一个数据交互中心，Balancer需要测试的数据需要和Server通信。

　　如何使用？

　　TLB必须结合构建工具使用，我们以TLB自带的例子为例。

　　examples/ant_junit

　　这个例子使用shell写的运行脚本，我在windows上做的，先把它的脚本改改。

　　把run_balancer.sh和上级目录的recipe.sh在powershell脚本里面合并。

　　TLB所有的设置依赖环境变量， TLB_TOTAL_PARTITIONS指定所有的测试分成多少份，TLB_BASE_URL指定TLB Server的地址，TLB_PARTITION_NUMBER当前node执行那一份测试，TLB_BALANCER_PORT指定node的端口。

　　StartServer启动TLB服务器，会开启一个cmd窗口，关闭的时候调用脚本关闭这个窗口就可以关闭TLB 服务器。

　　RunTest 运行测试，在每个node都必须配置TLB_PARTITION_NUMBER和TLB_BALANCER_PORT.

　　StopServer 关闭TLB Server。

　　Runner 脚本入口函数。

　　这里的脚本是把TLB Server 和 Balancer写在一起的，只为show一下TLB如何使用，如果要在不同node运行，必须把它分成server和balancer两部分脚本。server只需要 StartServer 和StopServer函数，而node只需要RunTest函数，去掉for循环，指定具体的TLB_PATTITION_NUMBER和PORT就可以了。

　　TLB不足？

　　TLB虽然可以实现测试分发，但是如果不结合CI工具的话，就必须手动的去运行每个node，而且在server也不能监控和收集每个node的运行结果。

　　配置管理

　　配置管理在软件开发项目中极其重要，它记录了软件开发流程的演进过程。它能够实现软件增量式开发，并随时可以追溯或查看任意时间的软件版本。持续集成一书中对配置管理是这样定义的：

　　配置管理是指一个过程，通过该过程，所有与项目相关的产物，以及它们之间的关系都被唯一的定义、修改、存储和检索。

　　那么我们怎么做配置管理？

　　（一）版本控制

　　（1）首先我们需要一个版本控制系统，Subversion、Mercurial或者Git，对于一个分布式的团队最好优先选择Mercurial或者Git。

　　（2）把软件开发有关的所有内容进行版本控制。包括源代码、数据库脚本、构建脚本、部署脚本、文档、第三方依赖、MindMap等等。保证新加入的成员能够很容易地从零开始工作，保证在新的测试或者生产中能轻松部署应用。

　　（3）频繁提交代码到主干。为了验证修改的正确性，快速的得到反馈，以及能够轻松地回滚到某个无错误的版本，提倡频繁提交。

　　（4）提交注释清晰明了。构建失败时，为了能够通过版本控制器查询是谁破坏了构建，以及他做了哪些修改，提交代码的时候必须使用意义明显的提交注释。建议第一段是简短的总结，第二段是描述更多的修改细节。

　　（二）依赖管理

　　第三方库文件是最常见的依赖，我们可以在本地建一个外部依赖库的副本来统一管理所有依赖，如果你使用Maven，你就可以这样做。

　　（三）环境配置

　　软件最终的运行环境可能不止一个，而且每个软件都会依赖的硬件、软件、基础设施或者外部系统才能工作。我们必须把环境配置自动且可靠化，可以借助Puppet或者CfEngine之类的工具软件。

　　持续集成

　　敏捷宣言首要原则就是尽快的交付可工作的软件到客户手中，为了实现这一原则，控制成本并及早的验证修改的正确性和快速得到反馈，提倡使用持续集成方法。

　　准备工作：

　　（1）版本控制

　　（2）自动化构建

　　（3）持续集成系统（Jenkins，Go，TeamCity等等）

　　（4）七步代码提交法则。如下图：

　　简介

　　SQL Server每个表中各列的数据类型的选择通常显得很简单，但是对于具体数据类型的选择的不同对性能的影响还是略有差别。本篇文章对SQL Server表列数据类型的选择进行一些探索。

　　一些数据存储的基础知识

　　在SQL Server中，数据的存储以页为单位。八个页为一个区。一页为8K，一个区为64K，这个意味着1M的空间可以容纳16个区。如图1所示：

图1.SQL Server中的页和区

　　如图1（PS：发现用windows自带的画图程序画博客中的图片也不错）可以看出，SQL Server中的分配单元分为三种，分别为存储行内数据的In_Row_Data，存储Lob对象的LOB_Data，存储溢出数据的Row_Overflow_data。下面我们通过一个更具体的例子来理解这三种分配单元。

　　我建立如图2所示的表。

图2.测试表

　　图2的测试表不难看出，通过插入数据使得每一行的长度会超过每页所能容纳的最大长度8060字节。使得不仅产生了行溢出（Row_Overflow_Data），还需要存储LOB的页。测试的插入语句和通过DBCC IND看到的分配情况如图3所示。

图3.超过8060字节的行所分配的页

　　除去IAM页，这1行数据所需要三个页来存储。首先是LOB页，这类是用于存储存在数据库的二进制文件所设计，当这个类型的列出现时，在原有的列会存储一个24字节的指针，而将具体的二进制数据存在LOB页中，除去Text之外，VarBinary（max）也是存在LOB页中的。然后是溢出行，在SQL Server 2000中，一行超过8060字节是不被允许的，在SQL Server 2005之后的版本对这个特性进行了改进，使用Varchar，nvarchar等数据类型时，当行的大小不超过8060字节时，全部存在行内In-row data，当varchar中存储的数据过多使得整行超过8060字节时，会将额外的部分存于Row-overflow data页中，如果update这列使得行大小减少到小于8060字节，则这行又会全部回到in-row data页。

　　编写背景：

　　前段时间有不少猎头来电询问是否考虑换工作，我一一回绝；因为在目前公司要完成的目标目前完成了1个，正在进行中1个，剩余1个还没有开始；其中一个猎头问我为什么来这家公司，主要是因为我的老板懂测试这个工种和工作，非常实实在在的支持和重视测试部门。

　　非常感谢今年的绩效考核工作，增加了一项考核指标：生产环境bug修复及时率，让我有机会学习和学会如何用这项指标来驱动开发的工作和检查测试工作成果，感谢我的老板给我的工作指导和好的想法，感谢在工作中时常提醒我做重要事情并给我很多工作建议的mac。

　　今天拿出来和同行分享，希望对大家有帮助。^_^。

　　点子1：生产环境bug的review会议

　　我们有固定的时间每周四上午，花1小时和开发及管理层过生产环境没有处理的P0、P1、P2问题，时间来得及会把P3也过一过；主要让大家知道目前生产环境都有哪些问题，处理进展如何，什么时候能解决，解决这些问题有什么困难。连续开了4周，有一些进步，还需继续引导。

　　点子2：每周过一遍生产环境bug修复及时率数据

　　给大家分享一下上半年的数据，还没有进行更深入的分析。从数据上可以看出测试漏出去不少问题，我在想：为什么会漏出去这些问题？在哪些环节给漏出去的？

　　我们要通过什么方法改善？为什么修复及时率这么低，工作流程中哪个地方有问题？数据因什么原因上升或下降？

　　1、商业区测试法：

　　1.1 指南测试法：4-16字符、英文小写、数字、下划线，不能全是数字或下划线。

　　1.2 可用测试法：帐号由字母、数字组成，点(.)减号(-)下划线(_)不能放在开头或结尾，也不能连续出现。

　　1.3 卖点测试法：当邮箱名已经被注册，不要仅仅只是提示错误信息，最好能给些用户建议或者用户感兴趣的其他处理办法。

　　1.4 质疑测试法：当邮箱名以下划线开头或者以下划线结尾时注册。

　　1.5 地标测试法：1.1与1.3结合，之所以这样测试目标还是考虑基本点和竞争对手。

　　1.6 极限测试法：1.6.1功能方面：长度4、16，组成：全字母、全数字、全下划线、三者组合、非字母、非数字、非下划线。1.6.2性能方面：能同时支持多少用户注册？1.6.3多个用户同时注册某个邮箱名。

　　1.7 快递测试法：测试邮箱地址、登录密码、确认密码、密保问题、密保问题答案、昵称、验证码其中某一个输入错误或者没有填，能否及时提醒。而不是等到最后提交才提醒。而且不能在提交的时候清理掉本身正确的输入。

　　1.8 深夜测试法：1.6.2性能方面：能同时支持多少用户注册？最大能支持多少人同时访问，如果超过最大的访问人数，系统又如何处理。

　　1.9 遍历测试法：测试所有字段都填写的时候，只填必填字段时。

　　2、历史区测试法：

　　2.1 恶灵测试法：测试错误常出的地方，在这个例子中主要测试邮箱地址以及密保问题答案。

　　2.2 博物馆测试法：结合开发提的建议，有哪些代码是没有修改过。测试的重点应该是最近被修改（本版本被修改过的部分）。

　　2.3 上一版本测试法：有点类似于回归测试，测试上一个版本的用例。为了更好地对比新老版本在同样功能上的区别。

　　3、娱乐区测试法：

　　3.1 配角测试法：测试一个特定的特性（辅助功能）与一个主要的特性（重要的特性）放在一个测试场景中，目的是验证功能是否存在明显的相互影响。比如注册新浪邮箱和注册新浪会员。比如新浪微博和邮件转发微博内容。

　　3.2 深港测试法：测试密保问题，根据测试不常用的原则，测试靠下的密保问题以及自定义密保问题。从开发人员心理的角度来看，常犯错的地方往往是不经意间的地方。

　　3.3 混合测试法：把正常符合邮箱地址的地址以及密保问题的自定义密保配合来测试，邮箱地址和强的密码（长度6位以上，且组成含有字母（大小写）、数字、特殊字符）

　　3.4 通宵测试法：测试一段时间（10分钟，根据不同行业用户习惯）不对注册邮箱界面做任何操作后，系统是超时退出还是保留原界面。（在安全和易用性之间找到一个平衡点）

　　4、旅馆区测试法：

　　4.1 收藏家法：整理输出，更多是整理输入非法的情况下对应的输出，输出越全面、完整，测试定位问题越精确，软件的容错性就越好。分类处理（更多关注输入隐式的规则，从违反规则角度来对应整理输出，管理员、开发语言的关键字、敏感词汇、特殊字符）。

　　4.2 长路径法：主要应用在配置类测试，具体的例子有移动的资费套餐的配置。

　　4.3 超模测试法：跟GUI测试几乎类似，关注的是风格和样式，包括颜色、字体、控件布局、Tab键的处理等界面相关。

　　4.4 测一送一法：最典型的情况是浏览器的兼容性（某一个BS软件要能支持主流的浏览器），同时使用不同的浏览器来打开注册界面，同时提交数据请求。有时要借助一些工具。如果是测试的是CS的，往往是测试其是否支持多线程。（进程与线程区别）

　　4.5 苏格兰酒吧测试：

　　5、破坏区测试法：

　　5.1 取消测试法：最好给用户回溯功能（取消某一个步骤，甚至是整个操作的功能）这里最典型的是office的undo功能。测试新浪会员能支持清空出错的输入，也能支持回退上一个步骤。

　　5.2 懒汉测试法：对一些有默认值的输入框，我们测试能否正常处理输入框默认值功能，另一个方面是默认值（下拉列表）是否真正默认。

　　影响软件性能的要素有很多，在需求阶段就应该对软件性能进行分析，在设计阶段要充分考虑软件架构设计对性能的影响，在测试阶段要充分验证软件的性能表现是否满足需求。

　　一、需求阶段的性能分析

　　从业务角度分析，如果一个系统上线后使用人数比较多，而且后期数据量比较大（如电信、金融证券等对外开放的系统），就有必要做好性能测试，因为这些系统对于实时性交互要求比较高，对系统的响应时间、并发用户数等要求都比较高，并且从数据角度分析，系统上线几年后存量数据一般都是千万级数据量，因此前期性能设计与验证对业务系统的后期正常运行维护至关重要。

　　在软件开发前期的需求分析阶段，需求分析师与客户业务人员沟通时，要明确提出各项性能指标，包括系统业务交易的使用频度、系统并发用户量、业务数据量评估等各项指标。然后对系统的响应时间、用户数和资源使用进行分析。

　　1、响应时间分析

　　响应时间的需求调研分析，例如查询类的交易需要在多少秒之内响应，对于URL连接或者刷新整个网页的时间，它是一个非常重要的度量值，因为它是直接体现用户体验的一个指数。

　　它同时也是最不容易测量的度量值，因为它比其他的度量值更容易发生变化。我们需要了解响应时间的区域分布。例如：一般月底是发工资的时候，查询当前账户额度是用户这段时间最常用的功能，这段时间的系统响应时间估计比平常响应时间慢些，而对于电信之类的报表查询，省内公司查询当月本省各个分公司、分点的销售额情况，总公司查询全国各省的总销售额情况，这时数量级别相差甚大，查询时响应时间也相对比较慢。这些情况对于指导服务器分布、负载均衡、数据库的设计都非常重要。

　　2、用户数分析

　　用户数分析，主要分析评估系统上线后的总用户数、平均每天在线用户数等情况，具体可分析：哪些交易每天都有用户在执行业务交易，这些用户一般占系统总人数的比例是多少；哪些交易会在月底、季末或者年底高频率并发使用；哪些交易用户使用得比较少，但却是相关重要人物（如上级领导）重点关注的交易。这些用户数分析结果，可为后续的性能测试设计中，针对混合场景的用户数配比设计提供有力的参考依据。

　　3、资源使用分析

　　资源使用分析用于衡量系统资源使用率的情况，反映系统的最底层性能情况，对于容量规划比较有指导作用，同时它也是比较容易理解的性能度量值。

　　二、设计开发阶段的性能分析与验证

　　大部分项目的性能问题是设计出来的，而不是开发和测试出来的。要获得性能良好的软件系统，需要根据需求分析及设计规划，进行系统的规模分析和完整的性能分析，预估性能瓶颈点，提出解决方案，最后通过架构师、程序设计人员等角色进行评审验证并确认，保障性能目标的达成。

　　在代码开发阶段，需要根据设计方案，在开发过程中关注性能瓶颈点，进行相应的白盒测试，通过代码分析和评审等手段，确认性能瓶颈并解决。需要不断地分析和总结性能问题和解决方案，形成性能方面的代码编写规范，从而在研发阶段的早期就能确保把软件系统在性能方面的风险降到最低。

　　系统设计与代码实现的很多细节都会对软件系统性能起到关键的作用。例如，在数据查询界面设计时，需要考虑查询方式是模糊查询还是精确查询、如何设计查询分页展现、对象的创建以及释放问题等。

　　在采用具体实现技术时，也需要注意性能细节，例如 Hibernate 中对大数据量查询时，需慎用 list() 或者 iterator() 遍历返回查询结果。

　　在采用Java等托管语言开发软件系统时，需要注意对象的生成和对象大小问题，否则容易导致产生大量对象实例，系统不仅要花时间生成对象，还可能要花时间对这些对象进行垃圾回收和处理，生成过多的对象将会对程序的性能带来很大的影响。

　　在数据库设计上也有很多细节会对后期系统性能表现有决定性的影响，例如：对历史查询是否分区、如何分区性能更好；如何设计批量数据抽取转换的方式，以保证减少或消除等待；如何设计索引，减少全表扫描、提高SQL查询效率；编写良好的SQL语句以便提高重用率、减少数据库解析。

　　三、统测试阶段的性能验证与优化

　　性能问题越早发现、修改，越能保证系统上线后的稳定性，因此应该在软件生命周期的不同阶段进行软件性能测试。

　　性能测试大致可以分为单元性能测试、集成性能测试、系统性能测试、多套系统互联接口性能测试等。其中，对一套系统进行的系统性能测试，也就是在特定的环境下、一定量的数据情况下，进行的系统级的性能测试，是最常用的，也是最为测试人员所熟悉的一种性能测试。

　　系统性能测试阶段的一般测试过程如下：在系统功能被确认后，模拟真实生产环境进行软件系统的部署（包括硬件设备、操作系统、网络搭建、负载均衡部署、中间件部署、数据库部署等），然后再根据前期的性能测试需求分析结果及测试策略定义的方法，模拟一定量的虚拟并发用户数，进行压力测试，同时监控分析系统是否满足预期的性能指标，识别性能可能出现的瓶颈点（应用代码、网络设备、硬件设备、操作系统、中间件配置、数据库等），并进行性能优化处理，调优后再进行复测，确保软件系统最终达到性能要求。