问题一：为什么要在一个团队中开展软件测试工作？
任何软件在开发过程中都会留下缺陷，带有缺陷的软件产品如果提交出去，可能会给公司带来不可估量的损失，我们必须在客户之前发现尽可能多的问题，从而保障客户满意。而发现问题的这个过程称之为测试。

问题二：简述你在以前的工作中做过哪些事情，比较熟悉什么。
      此问题每个人都不一样。我自己的答案如下。
我主要的工作是系统测试和自动化测试，也曾少量涉及性能测试。在系统测试中，主要是对BOSS系统的业务逻辑功能，以及软交换系统的Class 5特性进行测试。性能测试中，主要是进行的压力测试，在各个不同数量请求的情况下，获取系统响应时间以及系统资源消耗情况。自动化测试主要是通过自己写脚本以及一些第三方工具的结合来测试软交换的特性测试。

问题三：你所了解的的软件测试类型都有哪些，简单介绍一下。
1.
基本功能验证。主要是对发布的版本进行一些最主要功能的测试。英文常见叫法是Smoking Test, Basic Verification Test或者Sanity Check。
2.
功能测试。主要是依据需求或者需求分析文档，对所发布的版本进行测试，看看是否满足需求，是否出现了不必要的功能。
3.
单元测试。是开发人员进行的测试之一，一般是开发人员对很小的模块，比如函数进行测试，一般来说，开发人员还需要开发相应的测试桩来进行此类测试。
4.
集成测试。在大型的开发过程中，软件是模块化进行开发的，将不同的模块揉合在一起的话，需要进行的测试就是集成测试。
5.
系统测试。当软件提交给测试组后，是对整个系统的所有功能进行测试，一般来说，功能测试是系统测试的一个部分。
6.
压力测试。主要是在很大性能的情况下，这个性能已经接近了系统的极限，看看系统运转的情况。
7.
负载测试。主要是用各种不同的性能去检测系统，采集各个数据在这些性能情况下的数据。
8.
黑盒测试。指系统对你来说是完全不透明的，只给你留下了输入和最终输出，这个是功能测试的方法之一。
9.
灰盒测试。指在了解部分系统内部工作机制的情况下，对于系统进行的覆盖性测试。
10.
白盒测试。主要是在单元测试和集成测试的情况下，开发人员已知代码，对这一段的代码进行全路径的覆盖测试。
11.
界面测试。主要是看用户界面的友好性和易用性，是否有文字或者排版错误，是否有输入限制等等。
12.
回归测试。一般是系统发现BUG，开发人员修改后，和BUG直接相关以及可能相关的功能进行的测试。
13.
安装和卸载的测试。
14.
恢复测试。主要是一个系统在发生了灾难的情况下，从错误中是否容易恢复。
15.
兼容性测试。一个系统在不同的语言，操作系统下的系统测试。
16.
安全测试。系统在遇到攻击或者类似情况下的表现。
17.
Alpha测试。系统在给最终用户前，测试人员在实验室中模拟最终用户的测试。
18.
Beta测试。由部分最终用户通过使用来进行的测试。
19.
比较测试。和其他具有相同或者类似功能的系统进行对比的测试。
20.
验收测试。一般是最终用户在接受产品前，依据自己所提出的要求进行的测试，很多情况下，验收测试可能委托第三方机构完成。

问题四：测试计划工作的目的是什么？测试计划文档的内容应该包括什么？其中哪些是最重要的？
软件测试计划是指导测试过程的纲领性文件。
包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）。

问题五：你认为做好测试计划工作的关键是什么？
1.
明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
2.
坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
3.
采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
4.
分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

问题六：常见的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

1.         等价类划分

划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

2.         边界值分析法

　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

　　使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

3.         错误推测法

　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

4.         因果图方法

前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

5.         正交表分析法

有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。

6.         场景分析方法

指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。


问题七：您认为做好测试用例设计工作的关键是什么？

白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题


问题八：详细的描述一个测试活动完整的过程。

1.         项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后SQA进入项目，开始进行统计和跟踪

2.         开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。

3.         测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

4.         测试用例完成后，测试和开发需要进行评审。

5.         测试人员搭建环境

6.         开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现BUG后提交给BugZilla。

7.         开发提交第二个版本，包括Bug Fix以及增加了部分功能，测试人员进行测试。

8.         重复上面的工作，一般是3-4个版本后BUG数量减少，达到出货的要求。

9.         如果有客户反馈的问题，需要测试人员协助重现以及回归测试。


问题九：以往是否曾经从事过性能测试工作？请尽可能的详细描述您以往的性能测试工作的完整过程。

       曾经做过一套网管系统的性能测试，主要测试该软件在同时管理大量终端的情况下，在响应时间，CPU/磁盘/内存等参数是否满足要求。

       也曾经做过软交换系统的呼叫性能测试，主要是测试软交换系统在有大量呼叫的情况下，响应时间，呼叫成功率，CPU/磁盘/内存等参数是否满足设计要求。


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

       测试网管系统中，使用的Mimic来模拟终端，能够大量的节省成本。

       测试软交换系统的时候，使用的Prolab来模拟终端并发送呼叫软交换，他完成了同时数百人才能完成的摘机拨号工作，主要工作原理是产生一些符合要求的IP包并发送给软交换系统，同时对软交换系统的回应进行处理，决定下一步动作。


问题十一：您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？

主要是保障在大量用户的情况下，服务能正常使用。


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

1.         在传统的BugZilla中，BUG描述应该包括以下的信息

2.         和BUG产生对应的软件版本

3.         开发的接口人员

4.         BUG的优先级

5.         BUG的严重程度

6.         BUG可能属于的模块，如果不能确认，可以用开发人员来判断

7.         BUG标题，需要清晰的描述现象

8.         BUG描述，需要尽量给出重新Bug的步骤

9.         BUG附件中能给出相关的日志和截图。

       高质量的BUG记录就是指很容易理解的BUG记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。

问题十二：BUG管理工具的跟踪过程

       用BugZilla为例子      

测试人员发现了BUG，提交到Bugzilla中，状态为new，BUG的接受者为开发接口人员

开发接口将BUG分配给相关的模块的开发人员，状态修改为已分配

开发人员和测试确认BUG，如果是本人的BUG，则设置为接收；如果是别的开发人员的问题，则转发出去，由下一个开发人员来进行此行为；如果认为不是问题，则需要大家讨论并确认后，拒绝这个BUG，然后测试人员关闭此问题。

如果开发人员接受了BUG，并修改好以后，将BUG状态修改为已修复，并告知测试在哪个版本中可以测试。

测试人员在新版本中测试，如果发现问题依然存在，则拒绝修改；如果已经修复，则关闭BUG。


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

       尽量能有面对面的沟通，如果做不到，那么尽量能直接通过电话沟通，如果只能通过Email等非及时沟通工具的话，强调必须对特性的理解深刻以及能表达清楚。

       一是真诚，二是团队精神，三是在专业上有共同语言，当然也可以通过直接指出一些小问题，而不是进入BUG Tracking System来增加对方的好感。


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

       某次性能测试覆盖不足，造成系统崩溃。


问题十四：你对测试最大的兴趣在哪里？为什么？

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

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

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

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


问题十五：你的测试职业发展目标是什么？

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


问题十六：你自认为测试的优势在哪里？

有韧性

有能力面对挑战

有信心做好每一件事情

有比较好的教育背景

从以前的经理处都得到了很好的评价表明我做的很好


问题十七：当开发人员说不是BUG时，你如何应付？

如果确实是自己理解错误，则承认错误，没什么大不了

如果是需求不明，请项目经理补充清楚

如果双方理解不一致，且都不能互相说服，则请项目经理判断。


问题十八：你为什么想离开目前的职务？


问题十九：你对我们公司了解有多少？


问题二十：你找工作时，最重要的考虑因素为何？

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


问题二十一：为什么我们应该录取你？

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


问题二十二：请谈谈你个人的最大特色。

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


问题二十三：一个测试工程师应具备那些素质和技能？


问题二十四：集成测试通常都有那些策略？

       自上而下，自下而上，平面集成


问题二十五：测试结束的标准是什么？

       从微观上来说，在测试计划中定义，比如系统在一定性能下平稳运行72小时，目前Bug Tracking System中，本版本中没有一般严重的BUG，普通BUG的数量在3以下，BUG修复率90%以上等等参数，然后由开发经理，测试经理，项目经理共同签字认同版本Release。

       如果说宏观的，则是当这个软件彻底的消失以后，测试就结束了。


问题二十六：软件验收测试除了alpha,beta测试以外,还有哪一种?

第三方验收测试


问题二十七：为什么选择测试这行？

最开始么，公司安排的，然后么，干一行爱一行，发现测试中间还是有很多东西需要学习的，再就是测试中有很多东西值得改进和研究。


问题二十六：为什么值得他们公司雇用？

      用自己的经验和其他同事一起发现更多的问题，同时不同行业的观点可以互相借鉴。


问题二十七：如果我雇用你，你能给部门带来什么贡献？

      分享我的测试经验和测试技能，提高测试部门技术水平

　　启动浏览器，打开Internet选项对话框，切换到高级标签，去掉“启用第三方浏览器扩展(需要重启动)”的勾选，然后再次运行VuGen即可解决问题

　　提示：通常安装Firefox等浏览器后，都会勾选上面得选项，导致不能正常录制。因此建议运行LoadRunner得主机上保持一个干净的测试环境。

　　2.录制Web脚本时，生成的脚本中存在乱码该如何解决?

　　录制脚本前，打开录制选项配置对话框Record-Options，进入到Advanced标签，先勾选“Support charset”，然后选择中支持UTF-8。再次录制，就不会出现中文乱码问题了。

　　3.HTML-based script与URL-based script的脚本有什么区别?

　　使用“HTML-based script”的模式录制脚本，VuGen为用户的每个HTML操作生成单独的步骤，这种脚本看上去比较直观;使用“URL-based script”模式录制脚本时，VuGen可以捕获所有作为用户操作结果而发送到服务器的HTTP请求，然后为用户的每个请求分别生成对应方法。

　　通常，基于浏览器的Web应用会使用“HTML-based script”模式来录制脚本;而没有基于浏览器的Web应用、Web应用中包含了与服务器进行交互的Java Applet、基于浏览器的应用中包含了向服务器进行通信的JavaScript/VBScript代码、基于浏览器的应用中使用了HTTPS安全协议，这时使用“URL-based script”模式进行录制。

　　4.为什么脚本中添加了检查方法Web-find，但是脚本回放时却没有执行?

　　由于检查点功能会耗费一定的资源，因此LoadRunner默认关闭了对文本及图像的检查。要想开启检查功能，必须修改运行时的配置Run-time Setting。

　　进入“Run-time Setting”对话框，依次进入“Internet Protocol→Preferences”，勾选Checks下的“Enable Image and text check”选项即可。

　　检查执行结果时推荐使用web_reg_find方法。

　　5.运行时的Pacing设置主要影响什么?

　　Pacing主要用来设置重复迭代脚本的间隔时间。共有三种方法：上次迭代结束后立刻开始、上次迭代结束后等待固定时间、按固定或随机的时间间隔开始执行新的迭代。

　　根据实际需要设置迭代即可。通常，没有时间间隔会产生更大的压力。

　　6.运行时设置Log标签中，如果没有勾选“Enable logging”，则手工消息可以发送吗?

　　Enable logging选项仅影响自动日志记录和通过lr_log_message发送的消息。即使没有勾选，虚拟用户脚本中如果使用lr_message、lr_output_message、lr_error_message,仍然会记录其发出的消息。

　　7.LoadRunner 8.0版本的VuGen在录制Web Services协议的脚本时一切正常，而回放时报出错误提示“Error：server returned an incorrectly formatted SOAP response”。这时说明原因引起的?

　　造成这种情况的主要原因是LoadRunner 8.0的VuGen在录制Web Service协议的脚本时存在一个缺陷：如果服务器的操作系统是中文的，VuGen会自动将WSDL文件的头改为，因此会有上面的错误提示。

　　解决方法：把“LR80WebservicesFPI_setup.exe”和“lrunner_web_sevices_path_1.exe”两个补丁打上即可解决。
　8.VuGen支持Netscape的客户证书吗?

　　不支持。目前的VuGen 8.0版本中仅支持Internet Explorer的客户端证书。录制脚本时可以先从Netscape中导出所需的证书，然后将其导入到Internet Explorer中，并确保以相同的顺序导出和导入这些证书。而且，在每台将要录制或运行需要证书的Web Vuser脚本的计算机上都要重复执行前面的过程。

　　9.VuGen会修改录制浏览器中的代理服务器设置吗?

　　会修改。在开始录制基于浏览器的Web Vuser脚本时，VuGen首先会启动指定的浏览器。然后，VuGen会指示浏览器访问VuGen代理服务器。为此，VuGen会修改录制浏览器上的代理服务器设置。默认情况下，VuGen会立即将代理服务器设置更改为Localhost:7777。录制之后，VuGen会将原始代理服务器设置还原到该录制浏览器中。因此，在VuGen进行录制的过程中，不可以更改代理服务器设置，否则将无法正常进行。

　　10.在LoadRunner脚本如何输出当前系统时间?

　　LoadRunner提供了char *ctime(const time_t *time)函数，调用参数为一个Long型的整数指针，用于存放返回时间的数值表示。

　　调用语句与返回值如下示例：

　　typedef long time_t;

　　Action()

　　{

　　time_t t;

　　lr_message(“Time in seconds since 1/1/70: %ld ”,time(&t));

　　lr_message(“System time and date: %s”,ctime(&t));

　　}

　　输出结果为：

　　Time in seconds since 1/1/70: 1185329968

　　System time and date:Wed Jul 25 10:19:28 2007

　　11.一些Web虚拟用户脚本录制后立刻回放没有任何问题，但是当设置迭代次数大于1时，如果进行回放则只能成功迭代一次。为什么从第二次迭代开始发生错误?

　　这种现象多是由于在“Run-time Setting”的“Browse Emulation”的设置中，勾选了“Simulate a new user on each iteration”及其下面的选项“Clear cache on each iteration”这两个选项的含义是每次迭代时模拟一个新的用户及每次迭代时清除缓存。

　　由于脚本迭代时，init和end只能执行一次，如果每次迭代都模拟一个新的用户并清除缓存，

则用户登录信息将一并清除，因此迭代时可能会发生错误。

　　12.虚拟客户脚本“Run-time Setting”中的线程和进程运行方式的区别?

　　如果选择“Run Vuser as a process”，则场景运行时会为每一个虚拟用户创建一个进程;选择“Run Vuser as a thread”则将每个虚拟用户作为一个线程来运行，在任务管理器中只看到一个mmdrv.exe，这种方式的运行效率更高，能造成更大的压力，时默认选项。

　　另外，如果启用了IP欺骗功能，则先在Controller中选中Tools菜单下的“Expert Mode”，然后将Tools菜单下的“Options>General”标签页中的IP地址分配方式也设置为与Vuser运行方式一致，同为线程或进程方式。

　　13.在Controller中运行Web相关测试场景时，经常会有很多超时错误提示，如何处理这类问题?

　　这主要有脚本的默认超时设置引起。当回放Web脚本时，有时候由于服务器响应时间较长，会产生超时的错误。这时需要修改脚本的运行时配置。

　　进入“Run-time Setting”对话框后，依次进入“Internet Protocol→Preference”。然后点击“Options…”按钮，进入高级设置对话框，可以修改各类超时设置的默认值。

　　14.为什么Windows系统中的CPU、内存等资源仍然充足，但是模拟的用户数量却上不去?

　　在Windows计算机的标准设置下，操作系统的默认限制只能使用几百个Vuser，这个限制与CPU或内存无关，主要是操作系统本身规定了默认的最大线程数所导致。要想突破Windows这个限制，须修改Windows注册表。以Windows XP Professional为例。

　　(1)打开注册表后，进入注册表项HKEY_LOCAL_MACHINE中的下列关键字：SystemCurrentControlSetControlSession ManagerSubSystems。

　　(2)找到Windows关键字，Windows关键字如下所示：

　　%SystemRoot%system32csrss.exe bjectDirectory=Windows

　　SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1

　　ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2

　　ProfileControl=Off MaxRequestThreads=16

　　SharedSection=1024,3072,512关键字的格式为xxxx,yyyy,zzz。其中，xxxx定义了系统范围堆的最大值(以KB为单位)，yyyy定义每个桌面堆得大小。

　　(3)将yyyy的设置从3072更改为8192(即8MB)，增加SharedSection参数值。

　　通过对注册表的更改，系统将允许运行更多的线程，

因而可以在计算机上运行更多的Vuser。这意味着能够模拟的最大并发用户数量将不受Windows操作系统的限制，而只受硬件和内部可伸缩性限制的约束。

联系：视图（view）是在基本表之上建立的表，它的结构（即所定义的列）和内容（即所有数据行）都来自基本表，它依据基本表存在而存在。一个视图可以对应一个基本表，也可以对应多个基本表。视图是基本表的抽象和在逻辑意义上建立的新关系.

区别：1、视图是已经编译好的sql语句,而表不是.

 
2、视图没有实际的物理记录,而表有。

 
3、表是内容，视图是窗口 .

4、表只用物理空间而视图不占用物理空间，视图只是逻辑概念的存在，表可以及时四对它进行修改，但视图只能有创建的语句来修改.

5、表是内模式，视图是外模式 .

6、视图是查看数据表的一种方法，可以查询数据表中某些字段构成的数据，只是一些SQL语句的集合。从安全的角度说，视图可以不给用户接触数据表，从而不知道表结构。

 
7、表属于全局模式中的表，是实表；视图属于局部模式的表，是虚表。 

8、视图的建立和删除只影响视图本身，不影响对应的基本表。

　　关建字：LoadRunner 性能测试 网络基础编程语言数据库操作系统

　　LoadRuner与性能测试的关系：LoadRunner初学者的误点：把LoadRunner神化了。很多初学LoadRunner的朋友认为掌握了使用LoadRunner这款性能测试工具，就能够做性能测试了。常在网上看到好多人在学习怎么去使用这款优秀的性能测试工具，本来学习怎么去使用LoadRunner这个工具没有错，却把LoadRunner神化了，”天真的”以为它什么都能做，以为学会了LoadRunner的使用就能做性能测试了。尽管用了大量的时间学会了如何使用LoadRunner录制脚本，如何进行关联，如何进行参数化，如何设置集合点等等？可到头来，性能测试还是不会做。为什么？对于产生的性能报告不知道怎么去分析？不知道如何利用得到的分析报告分析出系统存在的瓶颈？不知道如何进行性能调优？像这些事光会使用LoadRunner是做不到的？说白了LoadRunner只是我们做性能测试的一个工具，它并不是万能的，是死的，具体怎么做还得依靠人去操作与分析。会使用LoadRunner的人，并不一定会做性能测试，会做性能测试的人并不一定都会使用 LoadRunner。LoadRunner只是一个性能测试工具而已。我们应该意识到，测试工具只是性能测试中的一部分，仅是为达到性能测试目的而采用的一种手段

　　性能测试与系统性能的关系：高性能，高安全的系统，不是测试出来的，而是构架，设计，编写出来的。当然在这里我并不否认性能测试的重要性，甚至可以说没有经过性能测试的系统，一定不会是优秀的系统，软件是人开发出来的，而人总是会出错的，所谓智者千虑，必有一失……要想做好性能测试，在软件系统需求，设计，编写代码的这些阶段就应该进行性能测试，而不仅仅是系统测试这个阶段才去做性能测试，性能测试应该贯穿于整个软件开发周期中。

　　对初学LoadRunner朋友的建意：常看到网上一些网友发贴子问，怎么对性能测试产生的结果进行分析？测试系统时怎么去选择合适的协议？对于发这些贴子的人我想请问你？你能够详细的说下HTTP协议吗？TCP建立连接和释放连接的过程是怎样进行的？什么是协议？协议是用来做什么的？在OSI参考模型中各层的作用？数据库中产生并发的冲突的原因？不要太依赖于LoadRunner工具本身的学习，而去忽略计算机其它基础知识的学习，我们更应该去掌握一门编程语言，良好的网络基础知识，计算机原理与操作系统知识，数据库知识。这些是我们去学习怎么去使用LoadRunner前提与基础。。

　　1、为什么要掌握一门编程语言

　　其一，大家在使用LoadRunner时常会遇到一些不能录制脚本的情况发生，或者需要录制一些复杂的脚本，这时候我们就必须手动的开发脚本。其二 LoadRunner虽然强大，易于使用，可是它却属于商业软件，价格昂贵，并且代码不开源，我们无法了解LoadRunner具体的实现细节，甚至我们会怀疑LoadRunner收集的性能数据准确吗？它有是如何实现的等等，而这些我们通过LoadRunner的帮助文档无法得知。性能测试工具并不只有 LoadRunner，做性能测试还有许多优秀的性能测试工具可以选择，像JMeter，Curl- Loader等等这些非常优秀的开源工具，在全能上虽然并不上LoadRunner，但在某些方面却比LoadRunner还要强大。例如Curl- Loader这个工具，它虽然支持的协议不多，但是对于http协议它最高能产生10万的并发用户，这是LoadRunner远远所不及的。并且这些工具代码是公开的，我们能够从这些代码中去分析具体实现的细节，并且还可以自已编写代码，增强软件的功能，这也是成为性能测试高手的一条途径。LoadRunner好比我们的Windows操作系统，易于使用，功能强大，代码封闭，论全能比Linux要强大。我们的开源性能测试工具好比Linux操作系统代码开源，不易于使用，但很多方面比我们的Windows要强大。也许这个时候有人会问对于初学者学哪门语言最好最有前途C，C++，VB，JAVA，C#？其实每一种语言能够生存下来，自有其生存的道理，每一种语言都有自已优势和缺点，并且编程语言具有相通信，学好了一门，再去学另外的编程语言，非常快就能上手。对于初学者我建意学习C语言，理由有很多，例如很多优秀的开源性能测试工具就是用C语言开发的…。当然不管选择什么编程语言，或者数据库，或者操作系统，我们不要去想学哪门最好，学哪方面最有前途。我们更应该结合自身的情况，选择最合适的，而不是选择最好的。

　　2、为什么要掌握计算机原理和操作系统知识

　　论坛上常会看到这些问题？LoadRunner中线程与进程的关系？在什么时候用到它们，怎么区别用线程还是进程呢？LoadRunner录制产生了乱码怎么解决？怎么去发现内存泄漏？对那些发贴问这些问题的朋友，我依然想请问你你知道进程和线程的概念吗？知道进程有几种状态吗？知道进程间的通信是怎么进行的吗？死锁，进程与线程的区别这些概念你明白吗？如果你连内存的概念，内存的作用，内存泄露的概念都搞不清楚，你怎么去发现内存泄露？如果这些你都不知道，自然就不知道怎么去做性能测试分析？一些网友录制脚本常常会产生一些莫名奇妙的错误？还震震有词的说这是LoadRunner的原因。其实要说到底要解决这些问题就必需得有良好的计算机原理和操作系统知识。弄清了进程和线程的区别，你自然就明白了使用进程资源使用高，但安全性要强于线程，线程资源利用率少，使用线程能在一个负载生成器上运行更多的Vuser，但可能存在安全问题。LoadRunner录制产生了乱码怎么解决？为什么会产生乱码，你知道什么是字符集吗？什么是编码吗？字符串在我们内存中有是如何存放的？ASCII编码，ANSI编码，UNICODE编码它们的区别是什么？这些都是操作系统的基础基础。掌握好了这些你自然明白LoadRunner中产生乱码的原因。当然计算机原理和操作系统的基础知识还有很多得掌握的知识。像操作系统的体系架构、操作系统的重要基础概念，内存管理、存储/文件系统、驱动/硬件的管理。要做好性能测试计算机原理和操作系统知识必不可少。

　　经常在51testing论坛中看到很多人发贴子。像LoadRuner中为什么要进行关联？LoadRunner测试系统时如何选择协议？LoadRunner中的如何进行IP欺骗？等等。这些问题随便一搜就能发现大量的贴子，其实说到底这些问题和LoadRunner的关系并不是很大，要去解决这些问题并不在于你对LoadRunner这个工具使用是否熟练，而在于我们网络基础知识是否扎实。例如第一个问题LoadRunner中为什么要进行关联？相信很多朋友都知道HTTP协议知道它是超文本传输协议，但是对于一些新手往往不能够详细的说出HTTP具体的内容，像HTTP工作的原理，HTTP协议为什么要使用基于TCP的协议而不使用UDP的协议，HTTP工作在OSI参考模型的哪一层？在HTTP协议上数据是怎么传输的等等。而只有当我们明白了这一切，自然而然就会明白为什么要使用关联，到最后你会发现这些问题其实根LoadRunner关系并不是很大。HTTP协议本质上是无状态的；对页面的每个请求都将被视为新请求，而且默认情况下，来自一个请求的信息对下一个请求不可用。在传统的Web编程中，这通常意味着在每一次往返行程中，与该页及该页上的控件相关联的所有信息都会丢失。例如，如果用户将信息输入到文本框，该信息将在从浏览器或客户端设备到服务器的往返行程中丢失，为了使用浏览网页，页与页是相互联系不去丢失这些信息，于是了就从现了Cookie，Session，查询字符串等等保持状态的技术。什么是Cookie？什么是Session？Cookie 和Session 有是怎么工作的？当我们明白了这些，很多的问题就自然而然的明白了，像这些都是基础的知识和LoadRunner关系大吗？不大。

　　Cookie 是一些少量的数据，这些数据存储在客户端文件系统的文本文件中，或者存储在客户端浏览器会话的内存中。Cookie 包含特定于站点的信息（像用户名密码以及我们在网站一些个性化的设置等等），这些信息是随页输出一起由服务器发送到客户端的。如果浏览器使用的是 cookie，那么所有的数据都保存在浏览器端，比如我们登录以后，服务器设置了cookie用户名，那么当你再次请求服务器的时候，浏览器会将用户名一块发送给服务器，这些变量有一定的特殊标记。服务器会解释为cookie变量，所以只要不关闭浏览器，那么cookie变量一直是有效的，所以能够保证长时间不掉线。。如果设置了的有效时间，那么它会将 cookie保存在客户端的硬盘上，下次再访问该网站的时候浏览器先检查有没有 cookie，如果有的话，就读取该 cookie，然后发送给服务器。这些是Cookie的工作过程，常看到论坛上一些朋友发贴子问使用LoadRunner时录制到了一些Cookie的信息，它是用来做什么的，看起来很烦可不可以把它删除掉？明白了这些细节的知识，你自然能明白那个Cookie的信息能不能删除掉。如果web服务器端使用的是session，那么所有的数据都保存在服务器上，客户端每次请求服务器的时候会发送当前会话的SessionId，服务器根据当前 SessionId唯一地标识在服务器上包含会话数据的浏览器，以确定用户是否登录或具有某种权限。不同的用户发送请求Web服务器会随机发送一个唯一的 SessionID。而我们使用LoadRunner录制时它会把我们SessionID写死，所以导致出错。这时候就得使用关联了，这样不仅明白了 LoadRunner怎样使用关联，而且还明白了为什么要使用关联？对于LoadRunner测试系统时如何选择协议？这个问题也是网络论讨的比较多的问题。要解决这个问题同样得依靠我们的扎实的网络基础，而不是对LoadRunner使用的熟练程度，首先我们得了解LoadRunner录制时的工作原理了，LoadRunner的录制和QTP不一样，它不关心你的对象识别什么的，不关心你的什么界面之类的，不关心你使用什么语言编写的，LoadRunner有一个Agent进程，来专门监控客户端和服务器之间的通信，然后用自己的函数进行录制。LoadRunner录制的时候关心的是通信包，是客户端和服务器之间的数据包。说到这里，大家就比较清楚了，为什么有的时候不能录制呢？因为，协议不认识，导致LoadRunner截获的数据包不能解析，所以录制下来是空的。所以我们得熟悉什么是协议， 熟悉OSI参考模型，OSI参考模型中各层的作用，TCP协议栈各层的作用，熟悉TCP，UDP，ICMP等等协议。当我们明白了这些网络的基础知识后我们自然会明白应该如何去选择协议。另外关于LoadRunner中的如何进行IP欺骗？要解决这个问题同样得有良好的网络基础知识。其实当我们理解了IP 地址的格式，IP地址的分类，子网掩码的概念，以及知道怎么去进行非标准子网的划分方法 ，掌握了这些原理的东西，那么具体怎么在LoadRunner中如何进行IP欺骗，就非常简单了。 当然网络基础知识并不只是上面的而已，还包括路由器，交换机，加密技术等等这些基础的网络知识，这些远远比我们去学习怎么去使用LoadRunner更重要。

　　4、为什么要掌握数据库知识

　　数据库的重要性我想是不言而喻的，性能测试产生的一个非常大的原因是因为数据大集中的趋势，测试从某种意义来讲就是对数据测试，而我们企业的核心数据是放在数据库中的。现在大型的WEB应用程序，都采用多层结构，像典型三层，用户界面层，数据逻辑层，数据层。而数据层，而数据层对我们整个WEB应用程序的性能是非常大的，对数据库的基础知识不懂，我们怎么去进行性能测试分析？怎么知道确定性能产生的瓶颈是否是数据库的原因，如何对系统进行调优？例如数据库模型设计不合理，一条坏的SQL语句就能影响到整个WEB应用程序的性能，所以熟悉SQL语句，建表，索引，存储过程，事务，触发器，并发等这些基础知识是必需得掌握的。

　　路漫漫其修远兮，吾将上下而求索：性能测试难点不在于Loadrunner工具本身，难在对整个系统的全局把握，而对全局的把握你就必需得有丰富的知识面。 并不是学好了LoadRunner的使用就能做性能测试 。目前，国内性能测试领域正处于起步阶段，要做好性能测试还需学习更多的知识，技术性和非技术。性能测试这条路充满着挑战，也充满着机遇。但正如鲁迅先生所说这世上本来没有路，走的人多了，也就成了路。最后祝愿喜爱性能测试的爱好这条道路上能够不鸣则已，一鸣惊人，不飞则已，一飞冲天。

　　集成测试的测试对象是模块间的组装和调用关系以及模块组合后的整体功能；

目的是找出与软件设计相关的程序结构模块调用关系，模块间接口与接口数据传递关系等方面问题；

测试依据是概要设计；

测试方法采用灰盒测试。

　　19.系统测试的测试对象，目的、测试依据、测试方法？

　　系统测试的测试对象是整个系统；

测试的目的是验证软件系统的功能和性能等是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方；

测试的依据是需求规格说明书；

测试方法黑盒测试。

　　20.测试覆盖的类型

　　测试覆盖的类型有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖

　　21.性能测试的分类

　　分为：性能测试、负载测试、压力测试、容量测试、强度测试等

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

强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。（它在系统资源特别低的情况下软件系统运行情况。）

容量测试：确定系统可处理同时在线的最大用户数。容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。

压力测试：通过逐步增加系统负载，测试系统的性能变化，并最终确定在什么负载条件下，性能处于失效状态，并获得系统能提供的最大服务级别。

　　负载测试与压力测试可以结合进行。

　　22.列举您熟悉的主流自动化测试工具

　　我熟悉的自动化测试工具有：基于web应用的开源自动化测试工具selenium、QTP以及性能测试工具LoadRunner

　　24.c/s和b/s结构的软件进行测试时有何不同

　　C/S又称Client/Server或客户/服务器模式。服务器通常采用高性能的PC、工作站或小型机，并采用大型数据库系统。客户端需要安装专用的客户端软件。

　　B/Ｓ是Brower/Server的缩写，客户机上只要安装一个浏览器（Browser）。浏览器通过Web Server 同数据库进行数据交互。

　　26.页面中有一个输入日期的输入框和一个输入身份证号的输入框，如何进行用例设计?

　　输入日期的输入框要考虑边界值、输入有效数据、非法数据、非数字等

　　省份证输入框要考虑18位身份证、16位身份证、非18、16位的数据、汉字、字母、非法数据

　　27.测试和质量保证有什么区别？你的看法

　　质量保证是对软件制作过程的制作质量进行管理，看是否符合公司的规定。

　　软件测试是对软件产品的质量本身进行测试，是从技术方面出发测试软件质量

进行软件测试，是质量保证的前提。

　　28.用过什么缺陷管理工具？ 流程是什么 有什么能改进的

　　我所熟悉的是TD

　　流程是讲测试计划、方案、测试用例录入TD，在TD上执行测试用例记录缺陷，并对bug进行跟踪。

　　29.你有没有用过QTP做项目，QTP的工作原理

　　我有用QTP做过项目。QTP的工作原理是执行重复的手动测试，首先制定测试计划再根据测试计划创建测试脚本，然后对脚本进行优化，增强测试脚本，接下来运行脚本分析测试的结果。

　　30.什么是白盒测试？白盒测试的工具有哪些？

　　白盒测试也称结构测试或逻辑驱动测试，测试人员利用程序内部的逻辑结构及有关信息，设计和选择测试用例，对程序所有的逻辑路径进行测试。工具有：Rational Purify 、Rational Quantify 、Rational Purecoveage

　　31.路由器，集线器，交换机的区别？

　　路由器的作用是用于连接不同网段并且找到网络中数据传输最合适的路径。

　　集线器的作用是将一些pc机连起来组成一个局域网。

　　交换机的作用与集线器的相似，区别在于集线器采用的是共享带宽的方式，交换机是独享带宽。

　　32.我手上这支笔，请你根据这支笔设计测试用例。

参考论坛：http://bbs.51testing.com/thread-47941-1-1.html

功能测试：该笔能否写字、哪些纸上写字、除了书写功能外，是否还有其他功能，例如能不能当手电筒，能不能当计算器等等

性能测试：写字是否流畅、能连续不断地写出多少字、写成的字能保留多长时间、在什么环境下可以正常时使用，比如温度

压力测试：能够承受多大的压力而不会被折断、

安全性测试：写出的字体是否带毒性、笔的材质是否有毒

易用性测试：笔握在手上是不是舒服、是否方便携带和存放

界面测试：设计是否美观，写成字体的颜色、粗细是否符合要求。

　　33.BUG报告包括那些内容

　　Bug出现的位置、可重现的步骤、所使用的数据、bug的截图、发现人及日期。

　　35.W和H模型的区别

　　W模型强调的是测试伴随整个软件开发周期，而且测试的对象不仅是程序，需求也需要进行测试，测试与开发是同步进行的。

　　H模型是讲测试活动玩却的独立出来，形成了完全独立的流程，可以实现迭代而W模型不支持迭代这是两者最打的区别。

　　36.没有任何说明书，如何进行测试？

　　首先是通过对软件册使用来熟悉整个软件，接着是与开发沟通掌握软件的特性并一一记录下来，作为测试的依据。

问题一，谈谈你对缺陷的认识？

参考的思路：首先，这个问题是个非常发散的问题，为什么这么说呢？因为大家都知道BUG在软件的整个生命周期内一直是一条主线，从程序员的“错误”的行为导致“缺陷”，而“缺陷”被激发导致软件“故障”，“故障”没有人修复会导致软件某一功能“失效”。另外一点的是众所周知的缺陷放大模型，根据缺陷放大模型的要求提出了“尽早测试”的观点，同时也带出了静态测试的重要性。从目前很多企业通过“BUG”数来衡量测试执行人员甚至是测试人员的工作绩效，到IBM所提倡而且做得非常成功的对“缺陷”从100多个纬度来进行ODC分析。再到微软强调的“以BUG为中心”的工作模式，无不体现“缺陷”在整个软件测试甚至在整个软件开发活动中的重要性。那么对于缺陷而言，到底有哪些东西是需要我们测试人员能联想到和需要掌握的呢？以下是鄙人的一点点看法：

第一，一谈到缺陷，我们首先能够想到的肯定是缺陷怎么样管理，也就是缺陷跟踪怎么样去做？用什么样的缺陷跟踪工具？缺陷的一生到底是什么（也就是BUG有哪些状态）？为什么要进行缺陷跟踪？参考的答案：首先缺陷跟踪对于整个项目具有十分重要的意义，是后期进行缺陷的分析和统计的基础，是对整个软件质量进行度量的基础。而想到缺陷的分析，我们可以联系到Gompertz模型和ODC分析，通过对缺陷的Gompertz分析我们可以得出测试该如何结束？测试应该停止于理智而非情感，那就是我们对于测试该如何结束的决策需要基于事实数据，这里可以联想到ISO的八项质量管理原则的其中一点“基于事实的决策”。通过的缺陷的ODC分析，我们可以从多个纬度来分析导致缺陷发生的技术和非技术原因，从而可以改进我们的开发和测试技术以及我们的测试过程，举个例子，如果通过分析发现很多问题跟初始化相关，那可以说明单元测试的静态检查没有做好，那可以选择对单元比较熟悉的人，经验跟丰富的人来做代码检查。因为工作好象就是这样的，如果你不行就让别人来。好，不能太发散了，回到我们缺陷跟踪，常见的具备缺陷跟踪能力的工具有以下：1，最简单的电子表格和WORD文档管理，2，专业的测试管理工具如QC、CLEARQUEST、免费的BUGZILLA和JIRA等。然后再描述下，比如在QC中BUG有哪些状态？

第二，BUG单的内容？什么样的BUG单是比较好的BUG单？参考的答案：1，测试项目的名称，这一点好的BUG跟踪工具都已经把它给模板化了，在填写BUG单的时候只需要选择就可以了。2，软件的版本号，包括主版本和从版本号。这一点同测试项目名称一样，都已经模板化了。3，BUG问题发现人，这个目的很简单，为了方便问题的统计，了解某一测试执行工程师的工作成绩。4，BUG发现的日期和时间，同上面一样方便统计。5，问题发现的测试环境（软硬件软件，包括客户端和服务端的环境），目的是为了清晰地了解问题发现的条件。6，缺陷的编号，每个缺陷都有唯一规范的编号，目的是为了方便检索和统计。7，缺陷的标题，对缺陷的简明扼要的描述。8，缺陷的类型，缺陷是功能性问题还是性能性问题，还是安全性问题，这样可以联想到软件质量模型。9，缺陷发现的用例编号，目的很明确，为了方便回归测试，然后又可以联想到回归测试的策略等。10，缺陷的严重级别，是致命、严重、一般还是提示问题，方便问题的统计和对版本质量的总体评估。11，缺陷的优先级别，这个定义了开发处理问题的优先级别，一般情况下，一般优先处理紧急且重要的问题。12，缺陷重现的操作步骤，这点的重要性就不必多少了，这个也最能体现提问人的智慧和水平。13，缺陷描述需要的附件，一个贴图有时可以顶上你洋洋洒洒几百字的描述。14，缺陷的状态，缺陷当前的状态。15，缺陷建议的处理人。那么什么样的BUG单是好的BUG单？这里大家可以想到的应该有“5C”原则：Correct,Clear,Concise,Complete,Consistent。具体的东西大家可以去发挥，另外敬请参考编写优秀缺陷报告的艺术一文：

51Testing软件测试网://www.51testing.com/？94273/action_viewspace_itemid_9903.html