看这个之前，可以先大致看一下我以前的一篇总结（HTTP请求模型和头信息）：
http://www.51testing.com/index.php?uid-225738-action-viewspace-itemid-216200

做Web测试相关工作，了解一下HTTP协议规定的8中请求方式中最常用的GET和POST是很有必要的，现简单总结一下吧，也当是自己做个笔记。

1.HTTP协议的格式：为了理解两者在传输过程中的不同，我们先看一下HTTP协议的格式：  HTTP请求：

<request line> <headers> <blank line> [<request-body>]

在HTTP请求中，第一行必须是一个请求行（request line），用来说明请求类型、要访问的资源以及使用的HTTP版本。紧接着是一个首部（header）小节，用来说明服务器要使用的附加信息。在首部之 后是一个空行，再此之后可以添加任意的其他数据[称之为主体（body）]。
GET与POST方法实例：

GET /books/?sex=man&name=Professional HTTP/1.1 Host: www.wrox.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Connection: Keep-Alive

POST / HTTP/1.1 Host: www.wrox.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Content-Type: application/x-www-form-urlencoded Content-Length: 40 Connection: Keep-Alive      （----此处空一行----） name=Professional%20Ajax&publisher=Wiley

2.GET与POST的区别：
    HTTP定义了与服务器交互的不同方法，最基本的方法是 GET 和 POST.
    HTTP-GET和 HTTP-POST是使用HTTP的标准协议动词，用于编码和传送变量名/变量值对参数，并且使用相关的请求语义。每个HTTP-GET和HTTP- POST都由一系列HTTP请求头组成，这些请求头定义了客户端从服务器请求了什么，而响应则是由一系列HTTP应答头和应答数据组成，如果请求成功则返回应答。
　　HTTP-GET以使用MIME类型application/x-www-form-urlencoded的urlencoded文本的格式传递参数。Urlencoding是一种字符编码，保证被传送的参数由遵循规范的文本组成，例如一个空格的编码是"%20"。附加参数还能被认为是一个查询字符串。（GET提交，请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，多个参数用&连接；例 如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。）
　　与HTTP-GET类似，HTTP-POST参数也是被URL编码的。然而，变量名/变量值不作为URL的一部分被传送，而是放在实际的HTTP请求消息内部被传送。
（1）get是从服务器上获取数据，post是向服务器传送数据。
（2）在客户端，Get方式在通过URL提交数据，数据在URL中可以看到；POST方式，数据放置在HTML HEADER内提交。
（3）对于get方式，服务器端用Request.QueryString获取变量的值，对于post方式，服务器端用Request.Form获取提交的数据。
（4）GET方式提交的数据长度受浏览器URL长度的限制，而POST则没有此限制。（特定浏览器和服务器对URL长度有限制，例如IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。）
（5）安全性问题。正如在（2）中提到，使用 Get 的时候，参数会显示在地址栏上，而 Post 不会。所以，如果这些数据是中文数据而且是非敏感数据，那么使用 get；如果用户输入的数据不是中文字符而且包含敏感数据，那么还是使用 post为好。

关于浏览器URL长度的限制，这里我再说明一下：见HTTP的RFC2068文档。
HTTP协议本身未指定任何对URL长度要求。它只是建议不要超过255个字符。（Servers should be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations may not properly support these lengths. The spec for URL length does not dictate a minimum or maximum URL length, but implementation varies by browser.）

更多相关知识，请参考：
http://stone-1231.javaeye.com/blog/539191
http://www.cnblogs.com/wxf0701/archive/2008/08/17/1269798.html
http://blog.chinaunix.net/u1/55764/showart_2082293.html

在性能测试中有很多的总结，其中大部分是性能测试工具的使用，对于测试设计总结偏少，且这些总结和具体行业关系较为紧密，导致跨行业测试人员比较难于理解。笔者根据多年测试经验，整理出对性能测试设计、测试执行以及数据分析的3+1原则（3+1原则是指量、全、深+快）。笔者认为只要在测试过程中紧紧把握住3+1原则，就具体了做好性能测试的基础。对于性能测试新手而言把握住这些原可以快速入门，性能测试老手则可以作为参考，对性能测试更深入的理解。

关键词：性能测试 测试分析 测试设计 测试用例 测试报告

　　一、性能测试中“量”原则

　　测试设计是测试工作的重点，在性能测试设计中通常要考虑很多的因素，如果测试设计遗漏往往会导致重测。笔者根据多年测试经验总结出一个核心，就是“量”。性能测试和功能测试的最基本区别也就是性能测试有一定规模的“量”，比如系统有一定数量的用户，有一定的负荷。

　　在测试设计中，对“量”的分析上，可以从系统范围和局部范围两个维度进行思考。系统范围是指将整个产品作为被测对象，主要根据产品实际的使用环境来分析涉及的“量”，然后在测试环境中进行模拟，可以模拟实际环境相同中的“量”，也可以根据测试目的按照一定的算法扩大“量”。局部范围是指以产品中某一个局部模块或者功能等为范围，主要靠测试人员的分析得到，根据系统外部输入的量，分析出被测局部范围有哪些“量”，然后再针对此局部范围有针对性的进行测试，这种方法可以弥补系统范围的不足，但需要对系统有较深入的了解。

　　针对不同的被测对象，涉及到“量”的测试点也不相同，下面根据笔者工作经验和相关文档整理而成，读者可以根据实际情况进一步扩展或细化，这些是性能测试的基础，建议联合有经验的测试人员和开发人员做一次全面的梳理，并形成文档在后续测试工作中使用和检查。

　　业务量：一个系统往往可以处理多种业务类型，这里的量就是指系统支持的业务类型数量。在产品实际使用时这些业务是并发的，所以在测试过程中也要同时进行模拟。相对于其他类型的“量”而言，业务类型量是比较少的，但可以说是最关键的。比如在交换机系统中可以提供语音电话、短消息等业务，这些业务是可以并发的，因此测试时就需要同时模拟这两种业务。

　　负荷量：这里的量是指系统处理的流量，系统能够提供多种业务或者功能，且可以并发，在实际的使用环境中不同业务的用户数不同，因此其对系统产生的负荷也不一样。在测试时，对于系统范围的测试通常是由外部用户的行为决定的，数据来自于现场收集或根据现状进行的趋势分析。比如登陆网站的用户中，同时进行软件下载的用户有500个，同时进行网页浏览的用户有1000个。对于局部范围的测试，通常是将外部的负荷转化为对应的局部负荷，然后通过工具进行模拟得到。比如直接通过测试桩的方式进行测试，而不需要模拟外部用户的行为。

　　……………………

　　查看全文请点击下载：http://www.51testing.com/html/07/n-221707.html

　　三、性能测试中“深”原则

　　这里的“深”包括两个维度，一是对系统的了解要“深”，二是对缺陷的分析要“深”。

　　性能测试通常都是黑盒测试，如果是大的系统，大的公司，分工更细，性能测试人员对系统的理解就更加肤浅。《软件测试经验与教训》中有个观点“黑盒测试并不是基于无知的测试””，笔者在多年测试中深有体会。要想做好性能测试，首先要深入理解系统的架构，系统的机制，其次是根据系统的实际情况，可以有针对性相关产品的知识，因为通常一个系统的组成部分都不会是某个公司自己开发的，都是使用了其他公司的一些产品，这样对这些产品知识的了解也比较重要。

　　通常性能测试中发现的缺陷都是系统中深层次的问题，这些问题对于开发人员来说，定位比较困难，有些缺陷甚至很难重现。因此测试人员要对测试过程进行仔细观察以及对测试结果数据进行初步分析。这里的分析要有一定的深度，当然不是深入到发现缺陷的跟因，但分析结果能够引导开发人员进行问题的定位。笔者多年的经验中感觉到通常开发人员也搞不清楚哪个地方出了问题，在判断大的方向上测试更占优势。

　　……

前些日子看电视时看到一条新闻：上海福利彩票因为更新系统，导致上海福利彩票的销售终端在将近3天的时间内，无法进行销售。作为一名测试，我的第一反应是，这套系统在更新前后是否做过更新前后的数据，系统等等的兼容性测试？也就是在看到这条消息没多久之后，我们部门也在提交版本时发生了意外，幸运的是这个版本在最后部署到生产环境中去的过程中，更新人员发现了问题，及时得到了修正（我要说明的一点是，版本的测试已经在测试环境中通过，问题出在了数据库的更新脚本上）。这件事发生后，我一直在思考问题到底出在什么地方？

我想讨论的是“提升从搭建测试环境开始”，可能很多人很疑惑，这个题目似乎和我开头说的有点搭不上边，而我却不是这么看待的。我问过相关人员，你是怎么看待“搭建测试环境”这个事情的，你觉得你能从中学到什么？你觉得这个对你后面的工作有帮助吗？你觉得测试环境的更新除了替换版本外还应该考虑什么问题？很多人都会这么回答，我觉得能学到很多东西，但具体说不上来，对后面的工作有帮助，但具体有哪些帮助同样说不上来，测试环境的更新，除了保证更新成功外，似乎没有什么需要再考虑的了。

一个负责搭建测试环境的人的意识，如果不得到更进一步的提高，我想，生产环境中发生任何事情就变得不奇怪了（这里不探讨系统设计本身的问题）。

从搭建测试环境，我们到底能提升什么呢？

第一，             是更进一步的了解我们的待测试项目的系统架构。现在对我们测试人来讲的大环境中，测试介入项目的时间往往是项目即将完成开发进入测试环境的阶段。很多测试在拿到项目的后往往关注的是用例，执行，以及最后的结果，似乎没有更多的时间去考虑其他。对于为什么采用这么一个框架，可能很少关注，往往就是按照要求，把环境部署完毕后，联调成功，就算完成了第一步，然后就急急忙忙的开始我们的后面的工作。在我看来，这个是非常错误的，在部署测试环境的过程中，除了能更进一步的了解各个部分采用的技术外，在这个过程中，应该更多的了解一下，为什么会采用这样的方式。说直白一点就是，采用这样的方式的优势是什么？这么说可能还是有很多人不明白，我再举一个简单一点的例子把，我们现在有些项目会做成C/S的模式，有些项目是采用B/S的模式，为什么采用这样的模式？在比如B/S模式的系统中，有些必须考虑性能测试，有些则不需要，为什么？其实，通过部署的过程，你在了解系统设计的原理，你明白了这些，最后我们的用例必然会得到更多的充实。

第二，             更新过程中是否会对原有的数据产生破坏？大家必须注意到一点，测试环境和生产环境的最大区别在于，生产环境是一个延续性的行为过程，而测试环境则没有这么一个延续性行为过程，所以，作为测试环境的部署者，在部署环境的过程中要充分考虑到这个因素，什么样的更新版本才是符合要求的。这点我想可能能解决我开头提到的两个案例。

第三，             在部署中测试环境的复用。这点也非常的关键，资源的合理应用对于任何一个公司来讲都非常的重要，如果这个过程中忽略了这个问题，测试环境可能会变得非常的臃肿，对于维护起来可能会非常的困难。

开发与测试的关系似乎总是那么的微妙。“强势”的开发，“弱势”的测试，这种状态似乎一直没有转变过，也一直成为测试行业内最想扭转的一个目标。如何有效的摆脱开发的控制？

在讨论这个问题之前，我们首先来谈谈一个公司的发展。一个公司的起家模式基本都是先有开发，后有测试这么一个过程，总之一句话，就是测试不可能在开发之前成立（专门的测试公司除外）。公司的发展模式决定了开发的优越感，也因为公司发展的初期依赖的是开发，加之公司发展初期为了自身发展，“效率优先”的原则在很大程度上影响了“一代人”（一代人：指公司创业初期的元老，这代人通常都是设计领域或者开发领域的“强人”，这代人里通常不会有测试领域的“强人”），这一代人在公司初期项目中的习惯影响到了后续的项目，进而形成一个非常牢固的“外壳”，要想打破这个“外壳”，所需要花费的时间和精力是很难评估的。这就像我们从小形成的习惯，明知这个习惯相当不好，可是就是改不过来一样的道理。

公司需求发展，发展需要可靠的质量保证……，这个过程是公司向正规化方向迈进的关键一步，而测试也是在这个过程中诞生的。测试的存在，总是让一些人感觉非常的不舒服，因为开发在观念上会不由的认为测试是在为难开发（这些开发可能不是很成熟），虽然测试也一再强调我们是在协助开发完成项目，而不是为了为难开发。开发与测试是不可分离的，只是在项目中承担各自不同的职责而已。

公司的发展有一个过程，测试部的发展同样需要过程。测试部发展的初期，需要依赖开发的各种支持，但依赖开发的支持不能代表测试就应该丧失自己的原则。这个过程中，妥协的可能往往是测试，但妥协不代表就丧失了测试的原则。我常常对我们的测试人员说，做到心中有数，在适当的情况下，我们需要妥协，妥协的目的是为了把项目继续下去。

测试成立的初期，首先介入的是系统测试。这个阶段的测试主要是属于功能性测试，也就是在外人开来“这里点点，那里点点”的这么一个过程。这个过程往往被外界所轻视，但在我的眼里，这是一个测试部自我能力提升，以及完善最为关键的阶段。这个阶段直接影响到后续的发展。这个阶段测试部需要解决3个问题。第一个问题是学会整理“文档”，这个过程非常重要，文档是依据，这个阶段需要的就是不耻下问，进而形成测试的依据。第二个问题是测试环境必须独立于开发，而且必须是测试自己维护自己的测试环境。第三个问题，整理测试部的工作流程。 这个阶段是测试部最困难的阶段，因为这个过程实际在一定程度上触及到了开发的一些底线，这在任何一个人来看，都是所不能容忍的。这里我最想强调的一个就是测试环境由测试部进行维护的原则。这个是作为测试人的一个底线，如果测试连自己的环境都不能维护的话，这在我看来，测试就不能完全保证测试的质量一样的道理，举一个简单例子，测试的环境由别人在维护，作为测试，你能说我真的完成了某个版本的测试吗？如果测试无法把握自己的在测试版本，测试何以保证质量？随着测试能力的提升，集成测试就会成为测试部的发展趋势。这个过程中，测试部会逐步接触性能测试，接口测试等等这方面的测试，这个过程也是测试真正开始摆脱开发控制的一个关键。记得我们有一个项目，先前开发总认为性能上绝对不会存在任何问题，甚至在测试部提交的测试方案中，开发也是非常强硬的用“时间允许的前提下，可以考虑做一下”。这次项目测试的前期开发是主导，后期测试介入了，测试用非常有力的证据证明了开发先前的错误后，测试顺利的拿下了性能测试的权力。

测试需要逐步摆脱开发的控制，而不是一次成功。测试在自己的翅膀还不是很强硬的时候，需要“伪装”自己，需要低调，在不失原则的过程中逐步壮大自己，在悄无声息中成为基石。这其实何尝不是适合自己的发展呢？

这个问题其实非常不好回答，实际情况往往很复杂……
就我个人经验写一点感受吧~~当然了，诸如要写清楚现象，尽量详细报告等是QA人员应有素质，这里篇幅原因暂且搁置不谈。

首先，开发方必须提供完整详细的式样书和制限事项。式样书是测试人员测试的基础，测试人员如果按照式样书测试得到了不一样的或者奇怪的结果，那么必然是bug无疑，没有任何可以争论的余地；如果测试人员执行了式样书上没有写的动作，得到了一个奇怪的结果，那么首先去制限事项里面找，如果制限事项写了，那么意味着开发者知道这个问题并且还在开发中，那么OK暂时放过（注意是暂时），如果制限事项也没写，那么再看这个动作是不是用户可能做出来的动作，举个例子如果一个软件的某个命令完全封装在内部，调用时一定会以普通用户身份执行，那么测试人员使用root测试出来的问题就是无效的（注意，当然封装的命令可能因为封装错误用root执行了，但那是另一个bug）；如果测试人员的动作虽然式样书没有，但是却是用户可以做出来的，那么抱歉，这个问题必须修改，而且还要围绕这个被式样书遗漏的问题进行拓展。

其次，测试开始前由开发方review测试方的测试计划，并针对测试方对式样书的疑问答疑。这一点有两个好处，一个是开发方可以尽早指出哪里测试不合理，哪里测试薄弱，另外也可以减少以后因为双方理解上的差异带来的时间浪费。虽然这会占用一点开发人员的时间，但是磨刀不误砍柴工。

第三，建立完备的版本管理系统，这个系统如何建立前面的每周一问已经详细讨论过了，目前要补充的就是，版本管理中必须把式样书和制限事项一起加进去，开发者发布了0_0_1版，其中制限事项是文件数目不能超过1M个，0_0_2版开发者取消了这个制限，那么必须在发布作这个版本的同时写明这一点，测试人员才能据此测试。严格的版本管理可以有效减少纠纷，如果测试人员使用0_0_1版测试1M+1个文件失败，那么是无效测试，如果使用的0_0_2版，那么就是bug必须修复，无可争论。

有了上面三条，大部分问题差不多能解决了，但是还是不行，差在哪里？主要还有两个问题，一个是测试方可能指出一些跟个人喜好相关的地方，比如测试方可能指出GUI一个警告信息窗的字体太暗而且不显眼，不容易被注意到，这类问题无法用上面三条来解决，因为是否容易被看到本身就不好界定；另一个问题就是（尤其是到了测试后期），测试人员连续跑了好几天测试忽然程序死了，再来一次又没事了，告诉开发人员这个现象，开发人员也解决不了，因为很难再现，如果是测试环境问题还好，如果真的是软件缺陷那被用户遇上就很严重，但是这种问题无论是让QA无休止的尝试再现还是让开发者没头没脑的调查都很难说得过去。

于是我们加上一条
第四，仲裁机制。QA和开发者并不直接对话去讨论一个问题是否要修改，我们首先对开发者实行残酷的有罪推定，也就是QA报告的问题开发者都必须修改，如果开发者认为无需修改必须给出理由和证据，围绕这个理由是否成立，QA和开发者双方展开讨论，这个讨论必须每一步都使用缺陷管理工具记录下来。最终要改还是不要改由一个仲裁机构来决定，当然了这个仲裁机构其实就是更上层的管理者，他们手里是日程计划，市场需求，对手状况等，他们根据这些更高层信息决定一个问题是否值得去修。

写到这里细心的读者已经发现，题目问的是怎样去说服，我却大谈测试管理方法。其实我个人觉得，建立一个宏观的良好机制比起一个测试者去唇枪舌剑的和开发人员辩论更加有效，我们追求的是什么，不就是效率么。因此我个人以为真正的测试人员职责就是报告缺陷，至于这个缺陷是否应该被修复先用机制套，套不上再来仲裁，仲裁过程QA leader全程参与，测试人员要做的只是在仲裁过程中客观的回答每一个问到自己的问题，至于什么我认为这个bug必须修之类的话不必出自测试人员之口，正如汽车发动机只需要考虑转呀转，具体哪个路口该拐弯也让发动机来考虑就不必了。

==================================================================================

1，和开发人员达成共识：开发人员的开发工作和测试人员的测试工作的出发点是一致的，都是为了给公司创造利益。达成这个共识后，开发人员就不会对测试人员和测试人员的工作有抵触情绪；再在这个认识的基础之上，和开发人员一起讨论如何修改代码他们的Effort比较小（如果你有一定的开发能力）、何时进行修改（由于各种原因，可能需要稍后进行一起修改）等。

2，与开发人员建立良好的关系，包括私人关系。如果你的能力强，开发人员可能会把某些工作交给你，让你帮忙做。这时可以积极接受，尽最大肯能帮助它们。我的一个同事曾发现某个Bug是由于没有写对一个业务逻辑比较复杂的SQL语句，于是他自己写了，就把开发人员一直困扰的这个问题解决了。从此以后，开发人员就非常支持我们的工作了。

3， 系统和软件最终是要交付给客户的。只有他们认可了，同意付款了，开发人员和测试人员的工作才算有意义。因此，我们测试人员一定要站在客户的角度去使用软件，去测试人员。我们要考虑客户会怎么样使用，他们可能会遇到什么问题。这样可以减少许多直到交付给客户后才会发现的问题。从这一点上来说，我们也要让开发人员站在客户的角度去理解为什么这个Bug一定要修改。曾经有许多UI上的错误，开发人员举手之劳就修改了。可是就是不修改，他们认为不需要。我就是让他们先把自己设想为一个客户来使用此系统，然后说服他们去修改的。

4，如果有条件，建议拿出你的数据和证据去说明为什么一定要修改它。如，进行性能测试后的测试报告数据、经客户确认的需求说明书等。

总之，既要让开发人员知道你是站在他的立场上考虑问题的，同时又要站在客户的角度来说明为什么需要修改这个缺陷

=================================================================================

到大家都说出了自己的办法，我也来说说我测试两年中解决此类问题的方法。
下面我就列举一下我的办法：
1.针对开发人员懒惰的心态。
开发人员在项目测试初期对于发现的BUG，往往是非常积极的态度，但是随着项目的测试的结束时间的到来，开发人员就会形成一种懒惰的心理（测试人员也不例外），这种懒惰的心理就会使得开发人员面对那种不是崩溃或者严重性的错误进行公认或者设置为不解决。面对这种情况，测试人员唯一的办法就是将BUG信息传达给项目经理，并讲述不修改这个BUG对项目有可能造成的影响，这是解决这种类型问题的最有效办法，懒惰的项目经理除外。
2.针对开发人员对测试人员的个人感情因素
不知道你们遇到过开发人员对测试人员因为个人感情因素，而故意不对你提的BUG进行修改的问题。有些初级开发人员开发的模块，错误多多，单元测试又做的不足，导致了他所负责的模块的BUG远远超出了其他人的数量。项目经理的指责加上自己能力的限制，面对越来月多的BUG产生厌倦，对提BUG的人员产生厌恶，这种问题其实不好解决。每天必须去开发部10趟以上，而且必须和对你有厌恶感的人侃些工作之外的话，如果他怎么说话，你就和屋内其他人侃，营造幽默气氛，并在开玩笑之余讲述测试的困难，侧面说出你的无奈。如果公司有些什么活动的话，是个很好的机会，记住增加沟通。
3.针对需求不符类型的BUG
满足用户的需求是项目质量的分量很重的评价标准，不满足需求用户需求还提什么软件质量。
开发人员只了解自己负责的部分模块，不懂得整体架构，只知道与其他接口取变量，传变量。
测试出的需求不符的BUG必须将需求中提到的需求点粘贴给他看，概要设计中提到的设计粘贴给他看，可以截图给他或者以附件的形式上传给他，这叫有理可证。
4.试运行前三天遇到的问题
项目测试后期，马上就要拿到线程试运行的时候出现的BUG是最关键的，这个时候遗留的BUG也是项目经理最关注的。如果你想让他们把你提的问题修改，那你就把你的问题设置为严重错误，这个时候即使是一个小小的界面问题，我们都有理由认为它是严重的。
5.针对不容易重现的问题
测试过程中不容易重现的问题也是很多的。自己悄悄测试的时候出现了，开发人员一来看，问题就没了，开发人员看不到的问题，他们当然不会改。所以在测试的过程中尽可能的不要忘记3分钟前你所做的一切操作，并且将问题现象截图保留，因为这你是重现BUG和讲述问题的关键。
6.制定BUG提交规则说明书
强制性的规定测试人员提交的BUG，通过BUG提交规则说明书规范测试人员BUG。提高BUG的有效率。并根据BUG提交个则说明书制定开发人员
BUG修改标准，符合标准的必须由开发人员作出处理。
7.服从领导
如果项目经理说不改，你就不必费脑筋想办法让他们改了！

软件开发过程不规范的项目组中，这种情况是非常常见的。2001年，我接触过的一个公司，它刚刚成立软件测试部，当时的测试部遇到的情况和上面讲的几乎如出一辙，搞得测试员叫苦不迭，开发部的程序员也天天抱怨头疼。

具体到当前这个项目遇到的情况，从上面的问题分析，我认为主要原因是：开发部提供的测试版本太过随意，导致质量太差。要解决它，我认为有以下几个关键点：

×在项目开始时，最好能先开发一个原型出来，原型基本上要确定整体界面的风格、统一的操作习惯等，以后的开发要以原型为基础进行；

×开发部使用版本控制工具，比如CVS、VSS等，并且要保证每天定时Check-in和Check-out，避免积累大量代码，同时要强调在Check-out和Check-in的时候要注明缘由，是为了修改某个bug还是增加新功能等；

×每日构建（Daily Build）：每日构建要形成制度，构建过程最好能自动进行，如果因为是第一次这样做，没有经验，遇到技术问题，在这种情况下，建议由测试部指派一名测试员加入到开发部，协助开发部进行人工构建，每日能集成一个能运行起来的完整的软件系统；

×强化冒烟测试（Smoke testing）：加入开发部的测试员在构建后，集成了一个完整的软件系统，要及时对每一个build进行验证（Build Verification Test ），也可以称之为“冒烟测试”，对软件的基本功能点进行验证；

×强化测试的准入条件：软件测试启动是有条件的，并不是说开发部拿个软件过来，开发部就要测试，比如要启动测试活动，必须要有需求规格说明书、设计书、单元测试报告、冒烟测试报告等，这是前提。满足不了这个前提条件，测试活动不会启动。当然这个制度需要公司管理高层的认可，在项目启动时要和项目经理协调好的；

×强化BUG管理：测试组要使用BUG管理工具，例如bugzilla、JiRA等，要保证 bug、版本、以及人员的对应关系，同时分析在不同的版本、不同的时间段、不同的模块中BUG的走势，确定“危险模块”为重点测试对象，预测未来的BUG走势和工作量等。

×积极的态度：无论是开发部还是测试部，在这个困难的过程中都要有积极的态度，遇到问题要及时沟通，以最高效的方式解决问题。

要从根本上根治这种矛盾，需要一套完整的、规范的开发过程。以上的措施只是一部分，只能在最短的时间内缓解矛盾。

=============================================

这个问题出题很新颖，着重是考察公司的测试Leader应对突发事件的能力？
以前我们公司招测试Leader的面试题目中也有类似的一个题目？我面试了很多人，回答都不是很理想，都只能够回答上几句话，并且都有“需求不明确”等同感，只是工作中太忙缺少总结，给出一个常见的很熟悉的问题，马上作答不知道如何说起。

下面是我的一些看法，恳请各位同行批评指正：
1.根据客户的功能点整理测试需求追朔表：
一般的客户都要把要开发软件的功能点写成一个表格交给市场部，让市场部门转交研发部。所以客户的功能点是编写测试用例一个最最重要的依据。

2.根据开发人员的Software Specification List整理我们的功能测试点：
一般来说，开发人员实现一个功能都要把该功能分成几个子模块来实现，所以Software Specification List也是我们参考的另一个比较重要的依据。

3.开展项目跨部门讨论会：
可以抽出时间，叫市场部的项目负责人、产品经理、项目经理、软件开发经理和软件开发人员，分别讲讲他们对整个产品的认识和设计模式，对每个功能点的理解和认识，理顺思路，达成共识，测试人员负责记录，测试Leader负责整理汇总，形成测试的部分参考文档。

4.测试人员整理用例需求疑问递交项目组和客户代表回复：
测试人员根据项目讨论会后的理解，测试过程中可能碰到的问题（如：边界值、输入数据类型等等）和需求不明确的问题，整理用例需求疑问，让相关的模块负责人在“用例需求疑问”表格中回复，并给出详细解释和说明。

5.项目内部用例评审：
测试人员根据对项目的理解，编写测试用例要点，测试组内部评审修改后，可以召集项目组的成员，帮助Review一下，然后进行修改。经过多次修改和评审以后，测试用例要点可能会更加全面一些。

6.邮件和客户代表确认部分争议问题：
测试人员与开发人员、项目组成员，在需求问题上讨论有时候观点不一致，各说各有理，这种情况下最好把争议问题写成邮件，发给客户让客户来拍板，确定那种需求合理，到底如何做？抄送项目组的全体成员，方便大家都了解客户的意见。最后编写测试用例的时候，以客户的邮件内容为准。

7.项目Demo和部分已开发系统：
大部分的系统，由于没有需求，为了避免项目风险，开发方一般都要做成Demo，不断让客户确认后签字，不断展现新开发的功能，以达到吸引客户的目的。如果项目中有Demo，Demo也是参考标准。如果什么都没有，那已经开发的部分功能模块，要去随时让用户了解了解，并提出部分修改意见，也可以为我们熟悉系统提供部分依据。

8.参考同行业和竞争对手的类似产品：
假如说是做一个网上书店类似的网站，我们编写测试用例的时候，可以看看“当当网”，“China—pub”等等类似成熟相关的网站。很容易发现本公司产品的问题，无意识给产品添加了竞争力。对于竞争对手的了解一定不能够少。

9.交叉模块的测试，最容易被人忽略：
一般的产品，功能部分的交叉，即是说在A模块中设置了参数，在B模块和C模块中体现该参数的实际运用。比较难的如我们现在测试的“银行系统”中的交叉模块，还可能牵涉到不同的用户，3个以上的模块之间的调用。即是有了需求也很少写，同时也是需求编写的一个薄弱环节。这样的测试用例编写问题，一般初级测试工程师很难考虑全。对于有这种交叉功能的模块，必须要求项目组中的精兵强将，画出相关的调用关系图，表明调用关系，方便后面编写测试用例。

10.可以使用电话、MSN、Skype等网络聊天工具咨询部分需求：
我们做的产品，大多数的客户都在国外，测试经理也可以用这些网络聊天工具和客户确认部分需求疑问。不过要要事先越好时间，并注意异地的“时差”。

 

 

测试用例分解
	对被测试点进行分解，把测试用例分解为多个测试场景
	场景编号 场景描述 预期结果 场景一 页面检查 正确 场景二 默认条件搜索 查询结果正确 场景三 修改可选条件搜索 查询结果正确 场景四 修改输入条件搜索 查询结果正确 场景五 修改区间条件搜索 查询结果正确 场景六 组合可选、输入条件搜索 查询结果正确 场景七 操作后检查搜索条件及查询结果 查询结果正确 场景八 错误、空记录搜索 查询结果为空

	测试步骤描述
	按照已经分解的测试场景顺序，逐个描述测试场景的测试步骤
	测试场景一：
	步骤编号 具体描述 1 进入搜索（高级搜索）页面 2 界面共性测试 3 退出
	测试场景二：
	步骤编号 具体描述 1 进入搜索（高级搜索）页面 2 点击“搜索”按钮，显示查询结果列表 3 检查查询结果列表，每页显示记录条数正确、文字折行显示正确、页面布局美观 4 检查查询结果列表，列标题项、列显示内容、排序方式符合需求定义 5 检查查询结果列表，符合默认查询条件结果集 6 点击查询结果列表链接、复选框、全选框响应正确 7 退出
	测试场景三：
	步骤编号 具体描述 1 进入搜索（高级搜索）页面 2 逐一选择各个查询条件可选项，如：“全部”、“类别1”等，点击“搜索”，查询结果正确 3 组合各个查询条件可选项，如：价格＋产品，点击“搜索”，查询结果正确 4 退出
	测试场景四：
	步骤编号 具体描述 1 进入搜索（高级搜索）页面 2 逐一输入文本域条件，模糊查询值，点击“搜索”，查询结果正确 3 逐一输入文本域条件，完全匹配值，点击“搜索”，查询结果正确 4 逐一输入文本域条件，中文值，点击“搜索”，查询结果正确 5 逐一输入文本域条件，字母大、小写值，点击“搜索”，查询结果正确 6 逐一输入文本域条件，数字类型值，点击“搜索”，查询结果正确 7 逐一输入文本域条件，全角、半角值，点击“搜索”，查询结果正确 8 组合各个文本域查询条件，点击“搜索”，查询结果正确 9 退出
	测试场景五：
	步骤编号 具体描述 1 进入搜索（高级搜索）页面 2 修改区间条件左值，右值使用默认值，点击“搜索”，查询结果正确 3 修改区间条件右值，左值使用默认值，点击“搜索”，查询结果正确 4 修改区间条件左、右值，点击“搜索”，查询结果正确 5 修改区间条件左、右值为边界值，点击“搜索”，查询结果正确 6 修改区间条件左、右值，使左值＝右值，查询结果正确 7 修改区间条件左、右值，使左值＞右值，查询结果为空（或提示信息正确） 8 退出
	测试场景六：
	步骤编号 具体描述 1 进入搜索（高级搜索）页面 2 任意组合各个查询条件：如：价格＋产品＋关键字，点击“搜索”，查询结果正确 3 重复步骤2，更换组合内容搜索 4 退出
	测试场景七：
	步骤编号 具体描述 1 进入搜索（高级搜索）页面 2 选择和输入所有查询条件后，点击“搜索”，查询结果正确 3 分别进行翻页、修改、添加、删除等操作后，检查查询条件不变，查询结果正确 4 退出
	测试场景八：
	步骤编号 具体描述 1 进入搜索（高级搜索）页面 2 逐一选择或输入查询条件为：不存在的值（查询结果集为空），查询结果为空 3 逐一选择或输入查询条件为：空格、特殊字符、超长的值，点击“搜索”，查询结果为空 4 组合查询条件，选择或输入不存在、空格、特殊字符、超长的值，点击“搜索”，查询结果为空 5 重复步骤4，更换组合内容搜索 6 退出

测试用例分解
	对被测试点进行分解，把测试用例分解为多个测试场景
	场景编号 场景描述 预期结果 场景一 页面检查 正确 场景二 默认条件搜索 查询结果正确 场景三 修改可选条件搜索 查询结果正确 场景四 修改输入条件搜索 查询结果正确 场景五 修改区间条件搜索 查询结果正确 场景六 组合可选、输入条件搜索 查询结果正确 场景七 操作后检查搜索条件及查询结果 查询结果正确 场景八 错误、空记录搜索 查询结果为空

51Testing软件测试网7o;A8z5Eg$W(SL&s

	测试步骤描述
	按照已经分解的测试场景顺序，逐个描述测试场景的测试步骤
	测试场景一：
	步骤编号 具体描述 1 进入搜索（高级搜索）页面 2 界面共性测试 3 退出
	测试场景二：
	步骤编号 具体描述 1 进入搜索（高级搜索）页面 2 点击“搜索”按钮，显示查询结果列表 3 检查查询结果列表，每页显示记录条数正确、文字折行显示正确、页面布局美观 4 检查查询结果列表，列标题项、列显示内容、排序方式符合需求定义 5 检查查询结果列表，符合默认查询条件结果集 6 点击查询结果列表链接、复选框、全选框响应正确 7 退出
	测试场景三：
	步骤编号 具体描述 1 进入搜索（高级搜索）页面 2 逐一选择各个查

测试搜索功能时，文本框中可以输入：
1、空格+合法关键字
2、合法关键字+空格
3、数据源中存在的关键字
4、数据源中不存在的关键字，如：任意输入的到达边界的字符串
5、输入单个特殊符号，如：% ？ @ # 空格等
6、输入的关键字两边加双引号
7、文本框：空白，什么也不输

包括关键字搜索.完全匹配.有效字符.无效字符等

1,空内容点击搜索，看其有没有LINK
2,输入过长查询数据，看其有没判断，报错
3,输入各种符号，特别是空格，看其能否正确判断
4,输入各种字符，譬如输入范围是0~9，A~Z的看输入中文是什么效果
5,输入正确数据，看其的查询后数据的完整性
6,注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方
7,在输入结束后直接按回车键,看系统处理如何,会否报错
8,反复输入相同的数据（5次以上）看是否报错
9,各国文字/字符的输入/粘贴能正确显示 退格键等操作显示正常 超过支持的最大长度有相应的提示 混合的多种语言也能正确显示
10,显示&接收；能进行下一步处理
11,其他的 包括能删除  能剪切等（我也不确定要不要包括 有点奇怪 显示语言是字符库支持的问题 而且如果是面向对象程序设计语言做的文本框 删除什么的功能也不用测了吧sdlkfj1 ）
12, 另外注意分析搜索结果.如:搜索结果的正确性,排序等..

<%
Function RegExpTest(patrn, strng)
Dim regEx, Match, Matches '建立变量。
Set regEx = New RegExp '建立正则表达式。
regEx.Pattern = patrn '设置模式。
regEx.IgnoreCase = True '设置是否区分字符大小写。
regEx.Global = True '设置全局可用性。
Set Matches = regEx.Execute(strng) '执行搜索。
For Each Match in Matches '遍历匹配集合。
RetStr = RetStr & "Match found at position "
RetStr = RetStr & Match.FirstIndex & ". Match Value is '"
RetStr = RetStr & Match.Value & "'." & "<BR>"
Next
RegExpTest = RetStr
End Function
response.write RegExpTest("[ij]s.", "IS1 Js2 IS3 is4")
%>
在这个例子中，我们查找字符串中有无is或者js这两个词，忽略大小写。运行的结果如下：
Match found at position 0. Match Value is 'IS1'.
Match found at position 4. Match Value is 'Js2'.
Match found at position 8. Match Value is 'IS3'.
Match found at position 12. Match Value is 'is4'.
下面我们就介绍这三个对象和集合。
1、RegExp对象是最重要的一个对象，它有几个属性，其中：
○Global 属性，设置或返回一个 Boolean 值，该值指明在整个搜索字符串时模式是全部匹配还是只匹配第一个。如果搜索应用于整个字符串，Global 属性的值为 True，否则其值为 False。默认的设置为 False。
○IgnoreCase 属性，设置或返回一个Boolean值，指明模式搜索是否区分大小写。如果搜索是区分大小写的，则 IgnoreCase 属性为 False；否则为 True。缺省值为 False。
○Pattern 属性，设置或返回被搜索的正则表达式模式。必选项。总是一个 RegExp 对象变量。
2、Match 对象
匹配搜索的结果是存放在Match对象中，提供了对正则表达式匹配的只读属性的访问。 Match 对象只能通过 RegExp 对象的 Execute 方法来创建，该方法实际上返回了 Match 对象的集合。所有的 Match 对象属性都是只读的。在执行正则表达式时，可能产生零个或多个 Match 对象。每个 Match 对象提供了被正则表达式搜索找到的字符串的访问、字符串的长度，以及找到匹配的索引位置等。
○FirstIndex 属性，返回在搜索字符串中匹配的位置。FirstIndex 属性使用从零起算的偏移量，该偏移量是相对于搜索字符串的起始位置而言的。换言之，字符串中的第一个字符被标识为字符 0
○Length 属性，返回在字符串搜索中找到的匹配的长度。
○Value 属性，返回在一个搜索字符串中找到的匹配的值或文本。
3、Matches 集合
正则表达式 Match 对象的集合。Matches 集合中包含若干独立的 Match 对象，只能使用 RegExp 对象的 Execute 方法来创建之。与独立的 Match 对象属性相同，Matches `集合的一个属性是只读的。在执行正则表达式时，可能产生零个或多个 Match 对象。每个 Match 对象都提供了与正则表达式匹配的字符串的访问入口、字符串的长度，以及标识匹配位置的索引。
学习了这三个对象和集合，如何应用于字符串的判断和替换呢？regExp对象的三个方法正好解决了这个问题，它们是Replace方法、Test方法和Execute方法。
1、Replace 方法
替换在正则表达式查找中找到的文本。我们还是先看个例子：下面的例子说明了 Replace 方法的用法。
<%
Function ReplaceTest(patrn, replStr)
Dim regEx, str1 ' 建立变量。
str1 = "The quick brown fox jumped over the lazy dog."
Set regEx = New RegExp ' 建立正则表达式。
regEx.Pattern = patrn ' 设置模式。
regEx.IgnoreCase = True ' 设置是否区分大小写。
ReplaceTest = regEx.Replace(str1, replStr) ' 作替换。
End Function
Response.write ReplaceTest("fox", "cat") & "<BR>" ' 将 'fox' 替换为 'cat'。
Response.write ReplaceTest("(\S+)(\s+)(\S+)", "$3$2$1") ' 交换词对.
%>
2、Test 方法
对指定的字符串执行一个正则表达式搜索，并返回一个 Boolean 值指示是否找到匹配的模式。正则表达式搜索的实际模式是通过RegExp对象的Pattern属性来设置的。RegExp.Global属性对Test方法没有影响。
如果找到了匹配的模式，Test方法返回True；否则返回False。下面的代码说明了Test 方法的用法。
<%
Function RegExpTest(patrn, strng)
Dim regEx, retVal ' 建立变量。
Set regEx = New RegExp ' 建立正则表达式。
regEx.Pattern = patrn ' 设置模式。
regEx.IgnoreCase = False ' 设置是否区分大小写。
retVal = regEx.Test(strng) ' 执行搜索测试。
If retVal Then
RegExpTest = "找到一个或多个匹配。"
Else
RegExpTest = "未找到匹配。"
End If
End Function
Response.write RegExpTest("is.", "IS1 is2 IS3 is4")
%>
3、Execute 方法
对指定的字符串执行正则表达式搜索。正则表达式搜索的设计模式是通过 RegExp 对象的 Pattern 来设置的。
Execute 方法返回一个 Matches 集合，其中包含了在 string 中找到的每一个匹配的 Match 对象。如果未找到匹配，Execute 将返回空的 Matches 集合。

衡量搜索引擎系统功能质量方面有2大指标，查询率、查准率。

性能方面从吞吐率、响应时间、系统资源消耗等多方面综合考虑。

搜索引擎应用参与运作的角色划分：分发请求/合并查询结果的merger，以及查询服务的searcher.

 

搜索引擎系统部署可以划分为：

1)      1 个Merger 带N个searcher ，searcher上数据一样  (分布式单个集群多台机器)  ，N>=1且为整数

2)      1个机器 同时充当Merger以及searcher (单机版)

3)      为避免2)单点故障，几台机器同时为merger/searcher，机器的数据一样。

4)      M 个分布式单个集群多台机器组成 1个大型的分布式多集群多机器的复杂环境

 

实践中3)、4)  2种部署模式都是存在的。

 

大数据量、高吞吐率的都采用4），避免单点故障

小型的数据采用3) ，节约成本。

 

单机上搜索引擎的模块划分一般有：

Ø        索引模块：为海量数据（数据库导出的文件数据） 建立索引文件 （依照一定数据结构格式保存为二进制文件）

Ø        查询模块：接收http请求，查询本机硬盘上的索引文件，返回文档ID以及第二次查询时返回具体的内容

Ø        即时更新模块：加入新的数据，可以从0开始重新建索引，也可以在原有基础上增加索引。

Ø        分布式模块：merger/searcher 多台机器的网络通信。

Ø        CACHE模块：这里可以做查询请求的缓存，也可以做查询结果的缓存，但缓存后者的话，将极大消耗系统内存。

Ø        其他管理模块

Ø        外部接口

 

 

基于如上复杂的系统架构，尤其是4)模式，我们在测试当中也碰到相当多棘手的技术问题

1)      海量数据是否都按预期的分词算法建立索引了呢？

2)      机器分词的效果与手工分词相差有多大呢?

3)      海量查询的返回结果是否多查了

4)      海量查询的返回结果是否漏查了

5)      海量查询的返回结果的加亮、标注如期加了？

6)      海量查询的返回结果中相关性分数计算是否正确?

7)      海量查询的返回结果积分计算是否正确了呢

8)      海量查询的返回结果积分相同时，排序的先后依据唯一么？

9)      加入即时更新模块后，每次查询结果都不同，新建的索引内容是否都反馈到查询结果里面了呢 ？

10)  海量数据时CACHE是否预期CACHE该cache的内容？

11)  海量数据时CACHE是否依照一定的过时算法令cache的内容失效呢？

12)  应用程序在32位LINUX 操作系统和64位的LINUX的索引、查询结果是否依然一样？

13)  应用程序在不同的OS 上索引、查询结果是否依然一样？

 

 

我们在实践中，针对查询结果正确性有3类方法处理以上问题

第一类基于人工肉眼对比，极度耗费脑细胞

1)      少量数据单机测试准确性

2)      少量数据1个集群,搭建1merger 1searcher 测试准确性

3)      少量数据1个集群,搭建1merger 多 searcher 测试准确性

4)      少量数据多个集群,搭建1merger 多 searcher 测试准确性

 

第二类，经过人工对比确认基本功能无大问题后，开发linux shell脚本或者loadrunner脚本比较部署方式不同但测试返回结果理当相同的。这个方法也帮我们发现了一些BUG

 

第三类方法，

直接测试大量数据多个集群,搭建1merger 多 searcher 测试准确性。

这个时候采用loadrunner施加高峰压力，抽样检查查询请求的正确性。

 

对于分词结果、相关性的结果，有人可能建立另外按照同样的算法以及输出格式，由2个不同的开发工程师实现，再对比同样的数据分词、相关性是否相同。在项目开发时间从容的情况下，可以考虑这么做的，但现实中有几个项目时间从裕？呵呵，我没有这么好运气遇上。

 

针对搜索引擎测试的困难，欢迎各位各抒己见。