前言 

最近有很多粉丝问我，有什么方法能够快速提升自己，通过阿里、腾讯、字节跳动、京东等互联网大厂的面试，我觉得短时间提升自己最快的手段就是背面试题，最近总结了软件测试常用的面试题，分享给大家，希望大家都能圆梦大厂，加油，我命由我不由天。

目录

01、您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

02、您认为做好测试用例设计工作的关键是什么？

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

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

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

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

07、测试活动中，如果发现需要文档不完善或者不准确，怎么处理？

08、你认为做好测试计划工作的关键是什么？

09、软件配置管理工作开展的情况和认识？

10、你觉得软件测试通过的标准应该是什么样的？

11、软件测试的文档测试应当贯穿于软件生命周期的全过程，其中用户文档是文档测试的重点。那么软件系统的用户文档包括哪些？

12、简述软件系统中用户文档的测试要点？

13、什么是系统瓶颈？

14、没有产品说明书和需求文档地情况下能够进行黑盒测试吗？

15、为什么尽量不要让时间富裕的员工去做一些测试？

16、完全测试程序是可能的吗？

18、软件测试的风险主要体现在哪里？

19、所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？

20、开发人员老是犯一些低级错误怎么解决？

21、您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？

22、开发人员说不是bug时，你如何应付？

23、软件测试项目从什么时候开始为什么？

24、你能不能说下你的3-5年的职业规划？

25、功能测试用例需要详细到什么程度才是合格的？

26、一个缺陷测试报告的组成？

27、测试用例通常包括哪些内容？

28、你都用什么测试方法？

29、软件的评审一般由哪些人员参加？其目的是什么？

30、什么是软件测试，软件测试的目的？

31、软件测试人员就是QA吗？

32、和用户共同测试（UAT测试）的注意点有哪些？

33、如何编写提交给用户的测试报告？

34、测试工具在测试工作中是什么地位？

35、写出bug报告流转的步骤，每步的责任人及主要完成的工作。

36、写出bug报告当中一些必备的内容。

37、开发人员老是犯一些低级错误怎么解决？

38、画出软件测试的V模型图。

39、为什么要在一个团队中开展软件测试工作？

40、您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？

41、您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）

42、您认为做好测试用例设计工作的关键是什么？

43、测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？

44、您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

45、请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程。

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

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

48、你以前工作时的测试流程是什么？

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

50、结构化程序设计和面向对象程序设计各自的特点及优缺点是什么？

51、描述TCP/IP协议的层次结构，以及每一层中重要协议。

52、简述子网掩码的用途。

53、说出4种以上常用的操作系统及其主要的应用范围（微软的操作系统除外）。

54、在Linux系统中，一个文件的访问权限是755，其含义是什么？

55、Windows操作系统中PATH环境变量的作用是什么？

56、在centos中，从root用户切到userl用户，一般用什么命令？

57、Linux中，一般怎么隐藏文件？

58、DNS是什么,它是如何工作的?

59、简述一下c/s模式或者b/s模式？

60、TCP/UDP有哪些区别？

 61、软件测试的流程是什么？

62、测试用例主要有哪些元素？

63、软件测试有什么策略和阶段？

64、黑盒测试和白盒测试是什么？二者有什么区别？

65、软件测试有什么类型？

66、测试用例是什么？有什么作用？

67、你平时是怎么设计测试用例的？

68、软件缺陷的定义是什么？

71、测试报告里面包含什么内容？

72、如果在测试过程中发现了BUG，可是开发不承认这是Bug，你会怎么办？

73、你们公司的需求评审是怎么进行的？

74、MySQL的常用命令有哪些？

75、Linux下的一些常用命令是什么？

76、你未来的职业规划是什么？

77、还有什么想要问我的吗？

78、为什么想要离职？

79、你的测试职业发展是什么？

80、你认为测试人员需要具备哪些素质

81、你为什么能够做测试这一行

82、测试的目的是什么？

83、测试分为哪几个阶段？

84、单元测试的测试对象、目的、测试依据、测试方法？

85、怎样看待加班问题

86、结合你以前的学习和工作经验，你认为如何做好测试。

87、你为什么选择软件测试行业

88、根据你以前的工作或学习经验描述一下软件开发、测试过程，由哪些角色负责，你做什么

89、根据你的经验说说你对软件测试/质量保证的理解

90、软件测试的流程是什么？

91、你对SQA的职责和工作活动(如软件度量)的理解?

92、说说你对软件配置管理的理解

93、怎样写测试计划和测试用例

94、什么是兼容性测试？兼容性测试侧重哪些方面？

95、我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？

96、测试的策略有哪些？

97、你觉得bugzilla在使用的过程中，有什么问题？

98、描述测试用例设计的完整过程？

99、单元测试的策略有哪些？

100、LoadRunner分哪三部分？

101、LoadRunner进行测试的流程?

102、软件的评审一般由哪些人参加？其目的是什么？

103、Beta测试与Alpha测试有什么区别？

104、你认为做好测试计划工作的关键是什么？

做好测试计划工作的关键 ：目的，管理，规范

105、你认为做好测试用例工作的关键是什么？

106、简述一下缺陷的生命周期？

107、软件的安全性应从哪几个方面去测试？

108、你觉得软件测试通过的标准应该是什么样的？

109、一套完整的测试应该由哪些阶段组成？

110、如何理解压力、负载、性能测试测试？

111、如何编写提交给用户的测试报告？

112、您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

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

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

115、写出bug报告当中一些必备的内容。

116、开发人员老是犯一些低级错误怎么解决？

117、简述一下c/s模式或者b/s模式？

118.给你一个字符串，你怎么判断是不是ip地址？手写这段代码，并写出测试用例

119.请进行测试用例设计：一串数字，闰年的判别

120.请你说一说简单用户界面登陆过程都需要做哪些分析

121.请对这个系统做出测试用例：一个系统，多个摄像头，抓拍车牌，识别车牌，上传网上，网上展示

122.请你对吃鸡游戏进行压力测试

123.请你对朋友圈点赞功能进行测试

124.如果做一个杯子的检测，你如何测试（经典）

125.如何对一个页面进行测试

126.如何对水壶进行测试(同水杯)

127.如何对淘宝搜索框进行测试

128.如何对一瓶矿泉水进行测试

129.请你说一下jmeter

130.为什么使用Jmeter：

131. 请你进行测试：前端下拉框实现，测试下拉框定位方式

132. 请你来聊一聊appium断言

133.请你来说一下购物车的测试用例

134.请你进行一下弱网模拟

135.你写的测试程序是怎么样的，你写过前端、后端程序吗？

136.请问你有没有写过测试脚本，怎么写的？

137.请问你有没有写过web测试，怎么写的？

138.请问测试路由器怎么测，用命令行还是界面？

139.请你回答一下如何测试手机开机键？

140.请问你遇到过哪些印象深刻的bug，接口测试出现bug的原因有哪些？

141.你在做项目中有做过压力测试吗，怎么做

142.请问你在项目中关于功能测试和接口测试是怎么做的

143.请问你有用过什么测试工具吗，用过哪些？

144.请你设计一个微信朋友圈点赞的测试用例

145.请问如果用户点击微博的关注图标但是app上面没有反应，应该怎么排查这个问题

146.在做测试的过程中，假如前端和后端吵起来了都在踢皮球觉得对方该改代码，你怎么办？

147.如果广东用户头条app刷不出东西了，你应该怎么排查问题

148.请你说一下能不能用机器学习去进行自动化测试，如何监控异常流量，如果是脉冲呢，如何和正常流量作区分

149.请你说一说当前工作中涉及的测试问题(测试流程和测试性能)

150. 请你说一说洗牌问题的思路并手写代码，并设计测试用例

151.请你测试一下游戏中英雄的技能

152.请你回答一下性能测试有哪些指标，对一个登录功能做性能测试，有哪些指标，怎么测出可同时处理的最大请求数量

153.请问你有没有做过什么单元测试，怎么进行单元测试，对一个没有参数没有返回值但可能对全局变量有影响的怎么进行单元测试

154.请问你有没有做过压力测试

155. 对于有系统大量并发访问，你会如何做测试，有什么建议

156.分别说出web和app元素定位方法

157. get和post不同点

158. http和https不同点

159.selenium原理

160. appium原理

161.自动化测试用到的模块

162. OSI七层模型

163.cookie、session、token各自区别

164.常用状态码

165. 手写adb命令

166. http请求头和响应头

167.鼠标操作常用函数

168.键盘操作常用函数

169.解决手动造数据问题

170.你写框架多长时间？

171. TestCase使用

172.Selenium 中如何保证操作元素的成功率？也就是说如何保证我点击的元素一 定是可以点击的？

173. 你的自动化用例的执行策略是什么？

174. 常见的 POST 提交数据方式

175. 目前主流的APP自动化测试框架，各个自动化适合的语言

176.Selenium有哪几种定位方式？用的最多的是哪种？

177. UI自动化能发现多少Bug

178.monkey属于自动化吗？

179. 你们一般对什么case会进行自动化，自动化一般在哪个阶段进行

180.app自动化你们一般用什么工具定位元素？

181.您需要一台服务器机器来运行Appium上的测试吗？

182.使用Appium可能遇到的错误是什么？

183. 简述Appium的原理？

184.如何提高selenium脚本的执行速度？

185. 什么是持续集成？

186.什么是page object设计模式？

187. 你觉得自动化测试最大的缺陷是什么？

188.Selenium是否支持桌面应用软件的自动化测试。

189. BDD是什么？你了解多少？TDD是什么？

190. selenium是否可以直接读取Excel表中测试用例，来执行相关测试

191.Selenium有哪些组件？

192. 如果元素定位中遇到iFrame内嵌框架，你是如何定位的？如果没有遇到id属性和name属性为空的情况，又是如何处理的？

193.明明自己定位的元素是对的，执行自动化测试脚本时却报错，这时你有几种方法解决此问题？请写出你的解决方法。

194. 简单说出如何用自动化测试脚本实现遍历复选框点击功能（要求全部勾上）。

195. 写一个自动化脚本，语言不限，要求每执行一次脚本随机生成一个手机号码。

196. 你对单元测试框架了解多少

197.深拷贝和浅拷贝的区别？

198.web/app动态元素如何定位

199、web自动化时，定位元素的方式有哪些？

200、如何去定位属性动态变化的元素？

201、启动浏览器的时候用到的是哪个webdriver协议？

202、XPath中使用单斜杠和双斜杠有什么区别？

203、Selenium中有哪些验证点？

204、如何清除中文本框的内容？

205、如何模拟浏览器的前后移动？

206、find_element()和find_elements()方法有什么区别

207、如何判断case是否通过？

208、等待元素加载的方式有几种？

209.自己开发的自动化框架吗？为啥要开发这么一个框架呢？市面上很多自动化平台为什么不用，却要自己搭建？想过投入产出比吗？

210.说下接口自动化分别用了哪些框架，怎么实现的，你主要负责哪些部分？

211.你们这套框架最难的技术点有哪些？搭建框架过程中遇到哪些问题，怎么解决的？

212.流程场景怎么设计用例的？假如流程比较长，你怎么保障前面流程成功？

213.数据放哪的？数据驱动怎么做的？关键字驱动怎么做的？

214.这套框架覆盖了开发多少业务代码，怎么统计出来的？多少用例，跑一次多长时间？

215.你们公司性能测试怎么做的，说一下流程？

216.TPS 上不去什么原因，怎么排查？响应时间太长怎么分析？

217.线程阻塞和死锁问题怎么去定位分析，有什么现象?

218.内存泄露和内存溢出有什么区别？分别会有什么现象？怎么定位分析？

219.压测线上环境都会遇到什么问题，数据隔离怎么做的？如何减小对生产影响？

220.测试过程中都发现了哪些性能问题，怎么定位分析的?优化方案是什么？

221.项目架构是怎么样的？简单描述或者画图

222.正向代理和反向代理区别？Nginx 了解吗？负载均衡算法

223.mq 是如何测试的？你项目中怎么应用的？mq 的优缺点？为什么使用 mq？怎么保障 mq 消息的有序性、幂等性、可靠性（不丢失）

224.为什么使用 redis，redis 五种数据类型，如何测试 redis 的，项目中如何应用的？

225.都发现过哪些缓存方面的 bug，怎么定位的？

226.假如开发不认可你提出 bug,怎么办？

227.线上有碰到过漏测的 bug 吗？怎么处理的

228.职业规划，离职原因。

关注 公 zhong 号【软件测试小dao】，回复面试题 ，获取《18万字228道软件测试经典面试题总结(附答案)》文档pdf，背题更方便，一文在手，面试我有。

01、您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

答：有黑盒和白盒两种测试种类，黑盒有等价类划分法，边界分析法，因果图法和错误猜测法。白盒有逻辑覆盖法，循环测试路径选择，基本路径测试。

例子：在一次输入多个条件的完整性查询中。利用等价类划分法则和边界分析法则，首先利用等价划分法，可以一个或多个结果是OK的测试用例，然后确认多个NG的测试用例，然后利用边界值分析法，可以对结果分别是OK和NG的测试用例进行扩展和补充。

02、您认为做好测试用例设计工作的关键是什么？

答：测试用例设计工作的关键是对可行的和不可行的都要考虑。

1，输入 2，详细的操作步骤 3，预期输出 4，实际输出。

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

答：有使用过LoadRunner，该工具能够录制测试人员的操作步骤，然后对这个操作步骤模拟出多个用户来播放出来。

1、Visural User Genertor 创建脚本，选择协议，录制操作，编辑操作。

2、中央控制器（Controller）调度虚拟用户，创建场景，选择脚本，建立虚拟用户，设计shedual，设置ip spoofer。

3、运行脚本。分析shedual。

4、分析测试结果。

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

答：性能测试工作的目的是检查系统是否满足在需求说明书中规定的性能，性能测试常常需要和强度测试结合起来，并常常要求同时进行软件和硬件的检测。

性能测试主要的关注对象是响应时间，吞吐量，占用内存大小（辅助存储区），处理精度等。

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

答：检测时间，系统环境，硬件环境，严重程度，程式版本，确认人，功能模板，问题描述，详细操作步骤，是否会重现。

问题描述和详细操作步骤要尽可能详细。Bug应该尽量用书面语，对于严重程度比较高的缺陷要在相同环境下测试一遍。

在C\S模式下，如果条件满足可以使用替换法来确认是client端的问题还是server端的问题。

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

答：最大的兴趣就是具有挑战性。

因为我并不知道哪里会出现bug，在找到一个bug后会很高兴。并且测试需要很强的耐心和细心。我可以很容易的找到一些细节问题。

07、测试活动中，如果发现需要文档不完善或者不准确，怎么处理？

答：要及时的与项目经理进行沟通协调。要在邮件中详细的把不完善不准确的地方描述出来，并提出自己的意见。

08、你认为做好测试计划工作的关键是什么？

答：首先，要有一个明确的目标，详细的阅读需求文档说明。

其次，要对整个测试人员、测试时间、测试进度进行一个预估，并预先进行管理。

最后，要对整个测试流程设定一个规范，所有测试人员都按着规范做事，不能随心所欲的测试。

09、软件配置管理工作开展的情况和认识？

拿到一台裸机过后要安装客户需要的操作系统，并且安装一些所必须的软件。

10、你觉得软件测试通过的标准应该是什么样的？

答：测试用例完全执行，测试用例覆盖到所有的测试点，并且缺陷的密度达到客户的需求。

​现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。

如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受

可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛

分享他们的经验，还会分享很多直播讲座和技术沙龙

可以免费学习！划重点！开源的！！！

qq群号：485187702【暗号：csdn11】

11、软件测试的文档测试应当贯穿于软件生命周期的全过程，其中用户文档是文档测试的重点。那么软件系统的用户文档包括哪些？

答：用户安装文档、用户配置文档、用户使用手册、联机指导等。

12、简述软件系统中用户文档的测试要点？

完整性：用户文档中功能的描述要完整的。不能让用户产生疑问。

一致性：用户文档中的功能描述要与实际软件中的功能一致。不能描述过盛。

易使用性：用户文档描述的内容要方便用户阅读并且能够让用户很清楚的知道如何操作。

图表：有的时候用图表描述会很明了。

13、什么是系统瓶颈？

系统瓶颈就是软件在一定的并发量、访问量下无法达到用户的需求。

比如说用户需要在10s内完成一个访问，但是每一次都要12s才能完成，这个就是性能瓶颈，有可能是程序本身的问题，也有可能和操作系统、软件相关。

14、没有产品说明书和需求文档地情况下能够进行黑盒测试吗？

可以。

这个情况下我们就要进行探索性测试，把软件当成用户需求，一步步进行测试。凭借经验判断功能正确与否，有的时候还可以与项目经理、开发人员一起进行交流沟通，从而进行更好的测试。

15、为什么尽量不要让时间富裕的员工去做一些测试？

首先，专业的测试人员是有一定的技能和耐心对软件一步一步进行测试。如果让时间充裕的员工去测试的话，他可能心思并不在测试上面。会很随意的、没有目标的进行测试。这样子的话测试并不完整，有的时候甚至很重要的bug都没法找出。所以还是需要专业的测试人员来进行测试的。

16、完全测试程序是可能的吗？

不可能

测试人员对程序进行测试，只能找出程序中的bug，但是并不能保证程序是没有bug的。

完全的测试要花费很多的人力财力，并且测试的数据量过大，很浪费时间。测试的结果还很多，有的都是类似的，没有必要进行相同的测试。所以完全测试是不可能的。

18、软件测试的风险主要体现在哪里？

主要体现在没法完全测试。有些问题可能隐藏在没有测到的地方。这样子就被忽略了。客户使用的时候并不熟悉软件是如何操作的。可能有的时候会误点点出问题。这样子的话我们就要承担很大的风险了。

发现的缺陷越多，说明软件缺陷越多吗？

是的，通常如果发现一个缺陷的话，有的时候会发现很多类似的缺陷，因为由于开发人员的习惯，可能一个地方有错误，另外一个地方就会有相同的错误。

19、所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？

从理论上来说所有的缺陷都是可以修复的，但是并不是所有的缺陷都要修复。

一些对于软件没有影响的、不影响使用的缺陷我们可以不用修复。因为修复些细小的缺陷也是需要花费很多时间。项目上面可能会因为时间问题而先忽略这些小缺陷。

20、开发人员老是犯一些低级错误怎么解决？

要在开发的前期就制定好一些编码规范，这样子可以减少很多因为个人习惯引起的错误。同时，测试人员在发现开发人员犯一些低级错误的时候不可以指责他们，要耐心的给他们指出错误所在。然后可以有开发人员自己进行测试，找出一些一眼看得出来是错误的地方。

21、您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？

我一般都是做的Web测试，搭建测试环境，对于一个程序进行集成测试，系统测试，回归测试等。还要编写测试用例以及一些文档，用户使用手册，功能测试文档等等。最擅长的是功能测试。

22、开发人员说不是bug时，你如何应付？

首先把自己的理由告诉开发人员。在同开发人员沟通到底是不是bug，但是如果开发人员还是认为不是bug的话，就把这个问题提到项目经理处，同时附上自己的理由。有项目经理决定是否为bug。

23、软件测试项目从什么时候开始为什么？

一般软件测试越早展开越好，一般是从需要阶段就要进行软件测试。软件测试不仅是测试功能，对于需求文档一类的也要进行测试。越早的找出bug，就会减少后续开发人员修改程序的次数，并且可以降低成本，如果等整个软件开发的差不多了发现一个致命的错误的话，是需要花费很多时间和人力来重新修改的。如果在一开始就发现的话就不会出现这种情况了。

24、你能不能说下你的3-5年的职业规划？

首先，要巩固自己的测试基础知识，在基本知识扎实的情况下提高理解需求文档地能力。

其次，学习自动化测试工具，并将它运用到测试中。

然后，在测试技术达到一定程度后，要学会如何带领一个测试团队。

最后，争取在最快的时间内达到测试经理的水平。

25、功能测试用例需要详细到什么程度才是合格的？

测试用例覆盖到所有的测试点。

26、一个缺陷测试报告的组成？

缺陷编号、缺陷标题、缺陷描述、缺陷的优先级、缺陷的重要程度、缺陷所述的模块、缺陷所属的版本、缺陷所属的开发人员、输入数据、输出结果、缺陷分析等。

27、测试用例通常包括哪些内容？

用例编号、测试环境、用例标题、输入数据、预期结果等

28、你都用什么测试方法？

根据不同的系统和模块有不同的方法。主要是黑盒测试和白盒测试。

29、软件的评审一般由哪些人员参加？其目的是什么？

参加人员：客户、项目经理、开发人员、测试人员

目的：查看软件在未正式投入运行前是否还存在问题。对于不同软硬件平台能否正常运行，是否有与客户理解不一致的地方，同时可以对一些可以改进的地方再多加改进。

30、什么是软件测试，软件测试的目的？

软件测试是通过人工或者自动化的操作进行还没有商业化用途的程序，查看他们的功能是否满足客户需求。

目的：在最短时间内找出尽可能多的软件缺陷。

31、软件测试人员就是QA吗？

软件测试人员的职责是尽可能早的找出软件缺陷，确保得以修复。而质量保证人员（QA）主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。测试人员的主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象。

软件测试和质量是相辅相成的关系，都是为了提高软件质量而工作。

32、和用户共同测试（UAT测试）的注意点有哪些？

软件产品在投产前，通常都会进行用户验收测试。如果用户验收测试没有通过，直接结果就是那不到“Money”，间接影响是损害了公司的形象，而后者的影响往往更严重。根据作者的经验，用户验收测试一定要让用户满意。

实际上用户现场测试更趋于是一种演示。在不欺骗用户的前提下，我们向用户展示我们软件的优点，最后让“上帝”满意并欣然掏出“银子”才是我们的目标。因此用户测试要注意下面的事项：

（1）用户现场测试不可能测试全部功能，因此要测试核心功能。这需要提前做好准备，这些核心功能一定要预先经过测试，证明没有问题才可以和用户共同进行测试。测试核心模块的目的是建立用户对软件的信心。当然如果这些模块如果问题较多，不应该进行演示。

（2）如果某些模块确实有问题，我们可以演示其它重要的业务功能模块，必要时要向用户做成合理的解释。争得时间后，及时修改缺陷来弥补。

（3）永远不能欺骗用户，蒙混过关。道理很简单，因为软件是要给用户用的，问题早晚会暴露出来，除非你可以马上修改。

和用户进行测试还要注意各种交流技巧，争取不但短期利益得到了满足，还要为后面得合作打好基础。

33、如何编写提交给用户的测试报告？

随着测试工作越来越受重视，开发团队向客户提供测试文档是不可避免的事情。很多人会问：“我们可以把工作中的测试报告提供给客户吗？”答案是否定的。因为提供内部测试报告，可能会让客户失去信心，甚至否定项目。

测试报告一般分为内部测试报告和外部测试报告。内部报告是我们在测试工作中的项目文档，反映了测试工作的实施情况，这里不过多讨论，读者可以参考相关教材。这里主要讨论一下外部测试报告的写法，一般外部测试报告要满足下面几个要求：

-根据内部测试报告进行编写，一般可以摘录；

-不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道；

-报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的；

-报告上面的内容尽量要真实可靠；

-整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告。

总之，外部测试报告要小心谨慎的编写。

34、测试工具在测试工作中是什么地位？

国内的很多测试工程师对测试工具相当迷恋，尤其是一些新手，甚至期望测试工具可以取代手工测试。测试工具在测试工作中起的是辅助作用，一般用来提高测试效率。自动化测试弥补了手工测试的不足，减轻一定的工作量。实际上测试工具是无法替代大多数手工测试的，而一些诸如性能测试等自动化测试也是手工所不能完成的。

对于自动测试技术，应当依据软件的不同情况来分别对待，一般自动技术会应用在引起大量重复性工作的地方、系统的压力点、以及任何适合使用程序解决大批量输入数据的地方。然后再寻找合适的自动测试工具，或者自己开发测试程序。一定不要为了使用测试工具而使用。

35、写出bug报告流转的步骤，每步的责任人及主要完成的工作。

（要结合自己实际的工作经验进行回答，不同公司略有区别）

测试人员提交新的Bug入库，错误状态为New。

高级测试员/测试经理验证错误，如果确认是错误，分配给开发组。设置状态为Open。如果不是错误，则拒绝，设置为Declined状态。

开发经理分配bug至对应的模块开发人员。

开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。

对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。

测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决，置Bug的状态为Closed，如没有解决,置bug状态为Reopen。

36、写出bug报告当中一些必备的内容。

硬件平台和操作系统

测试应用的硬件平台（Platform），通常选择“PC”。

测试应用的操作系统平台（OS）。

a) 版本， 提交缺陷报告时通过该字段标识此缺陷存在于被测试软件的哪个版本。b) Bug报告优先级c) Bug状态d) Bug的编号e) 发现人f) 提交人g) 指定处理人h) 概述i) 从属关系j) 详细描述k) 严重程度l) 所属模块m) 附件n) 提交日期

37、开发人员老是犯一些低级错误怎么解决？

这种现象在开发流程不规范的团队里特别常见，尤其是一些“作坊式”的团队里。解决这种问题一般从两个方面入手：

一方面从开发管理入手，也就是从根源来解决问题。可以制定规范的开发流程，甚至可以制定惩罚制度，还有就是软件开发前做好规划设计。

另一方面就是加强测试，具体做法就是加强开发人员的自己测试，把这些问题“消灭”在开发阶段，这是比较好的做法，读者可以参考第13章试案例分析的“13.1.2缺陷反复出现，谁的责任”小节，13.1.2专门讨论了这类问题的方法。

此外，还可以通过规范的缺陷管理来对开发人员进行控制，比如测试部门整理出常见的缺陷，让开发人员自己对照进行检查，以减少这类低级错误的发生。

开发人员犯错误是正常的现象，作为测试人员一定不能抱怨，要认认真真的解决问题才是上策。

38、画出软件测试的V模型图。

39、为什么要在一个团队中开展软件测试工作？

因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。

40、您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？

（根据项目经验不同，灵活回答即可）

我曾经做过web测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。最擅长的是功能测试

41、您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）

测试类型有：功能测试，性能测试，界面测试。 　　功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。 　　性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。 　　界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。 　　区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试

42、您认为做好测试用例设计工作的关键是什么？

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

43、测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？

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

44、您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

1．等价类划分 　　划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 2．边界值分析法 　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 　　使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据. 3．错误推测法 　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例. 4．因果图方法 　　前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

45、请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程。

　首先：得到相关文档（需求文档和设计文档），理解需求和设计设计思想后，想好测试策略（测试计划简单点就OK了），考虑到测试环境，测试用例，测试时间等问题。 　第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的网站的输入数据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处理的，有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。处理过程中，会经历3个步骤，网站才算完成了它的任务。有3个步骤呢，就可以分别对　　这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多50个用例。界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示。 　第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需要web服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了tomcat，所以只要有tomcat即可 　第四步：执行测试

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

（以自己最熟悉的性能测试项目为例）

是的，曾经做过网站方面的性能测试，虽然做的时间并不久（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 ：尝试链接数；　

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

最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了11，12点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1，2点我没有把握，其他点我都很有信心做好它。 　　刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。 　　不到一年半的测试工作中，当时的感动和热情没有减退一点（即使环境问题以及自身经验，技术的不足，做测试的你一定也能理解）。 　　我觉得做测试整个过程中有2点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。 　　第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。还有如何发现bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。如何描述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。

48、你以前工作时的测试流程是什么？

（灵活回答）

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

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

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

50、结构化程序设计和面向对象程序设计各自的特点及优缺点是什么？

（不需要回答如此复杂）

结构化程序设计思想采用了模块分解与功能抽象和自顶向下、分而治之的方法，从而有效地将一个较复杂的程序系统设计任务分解成许多易于控制和处理的子程序，便于开发和维护。它的重点在于把功能进行分解。但是由于在实际开发过程当中需求会经常发生变化，因此，它不能很好的适应需求变化的开发过程。结构化程序设计是面向过程的。

面向对象程序设计以需求当中的数据作为中心，来进行设计，具有良好的代码重用性。

封装性：也叫数据隐藏，用户无需知道内部工作流程，只要知道接口和操作就可以的。

继承性： 一种支持重用的思想，在现有的类型派生出新的子类，例如新型电视机在原有型号的电视机上增加若干中功能而得到，新型电视机是原有电视机的派生，继承了原有电视机的属性，并增加了新的功能。

多态性：指在一般类中定义的属性或行为，被特殊类继承之后，可以具有不同的数据类型或表现出不同的行为。

动态联编：指一个计算机程序自身彼此关联的过程，按照联编所进行的阶段不同，可分为两种不同的联编方法：静态联编和动态联编。

51、描述TCP/IP协议的层次结构，以及每一层中重要协议。

52、简述子网掩码的用途。

子网掩码主要用来判断两个IP地址是否处在同一个局域网当中；子网掩码是由连续的2进制1组成的。子网掩码和IP地址进行按位与运算后，结果一致，表示处于一个局域网当中，如果不一致，表示不再一个局域网当中，需要寻找路由。

53、说出4种以上常用的操作系统及其主要的应用范围（微软的操作系统除外）。

Linux（Red Hat、SUSE、Debian、Trubo Linux）：主要用于搭建各类服务器MAC OS：苹果机的操作系统，用于图像处理Unix（AIX：IBM服务器的专用操作系统；Solaris：Sun操作系统；FreeBSD、NetBSD）

54、在Linux系统中，一个文件的访问权限是755，其含义是什么？

755表示该文件所有者对该文件具有读、写、执行权限，该文件所有者所在组用户及其他用户对该文件具有读和执行权限。

55、Windows操作系统中PATH环境变量的作用是什么？

PATH是Windows操作系统环境变量，PATH作用是用户在命令行窗口执行一个命令，则在PATH变量设置的目录下依次寻找该命令或对应的执行文件，若找到，则执行，若没有找到，则命令行窗口返回无效命令。

56、在centos中，从root用户切到userl用户，一般用什么命令？

susu user1 切换到user1，但切换后的当前目录还是root访问的目录su – user1 切换到user1，并且当前目录切换到user1的根目录下（/home/user1/）

57、Linux中，一般怎么隐藏文件？

文件名以一个.开头

58、DNS是什么,它是如何工作的?

域名解析服务。用于将域名解析为IP，或反和将IP解析为域名。客户机可指定DNS服务器来解析，或用本机hosts文件进行解析。

59、简述一下c/s模式或者b/s模式？

C/S模式：客户端/服务器模式。工作原理：Client向Server提交一个请求；Server则使用一些方法处理这个请求，并将效果返回给Client。B/S结构，即Browser/Server(浏览器/服务器)结构，是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户界面完全通过WWW浏览器实现，一部分事务逻辑在前端实现，但是主要事务逻辑在服务器端实现，形成所谓3-tier结构。B/S结构，主要是利用了不断成熟的WWW浏览器技术，结合浏览器的多种Script语言(VBScript、JavaScript…)和ActiveX技术，用通用浏览器就实现了原来需要复杂专用软件才能实现的强大功能，并节约了开发成本，是一种全新的软件系统构造技术。60、TCP/UDP有哪些区别？TCP-有连接,所以握手过程会消耗资源,过程为可靠连接,不会丢失数据,适合大数据量交换UDP-非可靠连接,会丢包,没有校验,速度快,无须握手过程

60、TCP/UDP有哪些区别？

TCP-有连接,所以握手过程会消耗资源,过程为可靠连接,不会丢失数据,适合大数据量交换UDP-非可靠连接,会丢包,没有校验,速度快,无须握手过程

 61、软件测试的流程是什么？

分析：每当HR问一个问题的时候我们都可以用1~2s的时间去想HR想要从这个问题中获取什么信息，这点搞清楚之后再去回答就很好回答了。如果有工作经验，直接按照公司流程回答即可，如果是刚转行或者刚实习，那按标准回答即可，文中回答仅供参考；   回答： 项目经理或者PD把项目需求文档提前下发给相关的研发人员，研发人员抽出一定的时间记录文档内需求不明确或者遗漏的点为后面的评审做准备；在需求评审会议上，各研发人员提出自己的疑问并解决，需求评审最终通过之后会出一份最终的需求规格说明书；（需求评审阶段）     需求规格说明书评审通过后，开发经理开始编写开发计划，测试经理开始编写测试计划，计划评审通过后开发人员开始进行程序的开发，测试人员开始测试用例的编写，等程序的第一个版本出来后，开发人员进行第二个版本的迭代，这时测试人员对程序进行测试并记录追踪管理缺陷，直到程序迭代完毕。（产品研发阶段）     程序迭代完毕并修复大部分缺陷后，测试人员开始进行工作的总结，并最终输出一份测试报告书，记录此次的测试工作共，程序存在的相关问题。（产品发布阶段）

62、测试用例主要有哪些元素？

分析：每个公司因为使用的模板不一样，所以测试用例的内容也是不尽相同的，所以回答时只需要回答出基本的元素即可；   回答： 测试用例主要元素有：ID、标题、模块、预置条件、操作步骤、预期结果、实际结果、是否通过、BugID等；

63、软件测试有什么策略和阶段？

分析：软件测试的策略就是测试将按照什么样的思路和方式进行如采用什么技术，什么步骤等。   回答 ：软件测试的策略主要有：动态测试和静态测试、白盒测试和黑盒测试。测试阶段按照研发顺序分别是：单元测试、集成测试、系统测试，有些公司还会有验收测试；（单元测试开发在调试代码时就完成，集成测试也是，但是有时测试人员也需要进行集成测试；测试人员平时主要的工作就是系统测试，验收测试是有客户参与进行的测试）；

64、黑盒测试和白盒测试是什么？二者有什么区别？

分析：黑盒测试和白盒测试的概念百度百科上面都有，这里不再做太多介绍。黑盒测试和白盒测试的区别： 回答： 黑盒测试主要是在程序界面进行测试，通过设定某种场景检验程序在这种场景下是否给出了正确的反应，验证程序正确实现了需求规格说明书中的需求，而白盒测试主要是针对程序内部结构，对程序代码进行代码走查等，但是白盒测试的成本会比较大，当程序有多个路径时，可能会产生较多的遗漏；

65、软件测试有什么类型？

回答： 常见的软件测试类型有:功能测试、性能测试、兼容性测试、可靠性测试、安全性测试、压力测试、负载测试等；

66、测试用例是什么？有什么作用？

回答：测试用例就是设计一个特定场景，让软件在这种场景下运行，检验程序是否给出正确的反应，以此验证软件是否正确实现了客户需求。   作用：1、避免盲目测试并提高测试效率；在软件版本更新之后只需修正少部分用例即可开展测试工作，降低工作强度，缩短测试周期；          2、可以分清哪些是测试重点，测试用例是测试工作的见证，能知道测试了哪些功能，没测哪些模块；          3、测试用例是量化测试工作的方法之一；

67、你平时是怎么设计测试用例的？

分析：这个问题的点主要考察是否掌握测试用例设计方法，在回答之后，HR可能会继续追问某种设计方法的概念或者实例，这时举例说明即可；如：等价类划分法就是把程序的输入域划分成等价类，从每个部分中选取少数代表性数据当做测试数据。   回答：设计测试用例一般都会使用到等价类、边界值、场景/流程法、因果图还有错误推测法；

68、软件缺陷的定义是什么？

分析：什么样的问题才是一个缺陷，需要从客户需求出发；   回答：1、软件未实现需求规格说明书中的要求；         2、出现需求规格说明书中指明不应该出现的错误；         3、软件未实现需求文档中虽未明确提及但应该实现的功能；（如：账密加密）         4、软件出现难以理解、不易使用或者运行速度慢等问题都可以认为是软件缺陷；

69、缺陷中应该包含什么元素？严重等级一般有哪些？

分析：这个问题和上面测试用例一样，每个公司的要求可能都会不一样；   回答：主要元素有：标题、BugID、复现步骤、实际结果、预期结果、截图、日志等；软件缺陷等级一般有四种，致命（程序奔溃）、严重（金额计算错误、数据出错）、一般（不影响使用但是会造成一定的麻烦）、优化（字体字号不统一）

70、给你一个杯子，你会怎么测试？

分析：给你一个杯子，给你一个电梯，这种问题在前期的面试中是经常遇到也是非常经典的一道面试题，这里给出一个链接，回答时从外观、功能、性能等各个角度说起，再结合自己的一些话就可以了。

回答：

一个水杯的测试 满有意思，如果你愿意，可以发挥一下你的想象先，然后再看看别人例子，你会更加有收获噢！

测试是一种思想，一种思路，当你脑子里面这个思路思想很清晰的时候 我们测试人员什么东东不会测试？

HOHO！！ 比较有意思的答案如下两种：

一种： 测试项目：杯子

需求测试:查看杯子使用说明书

界面测试:查看杯子外观

功能度：用水杯装水看漏不漏；水能不能被喝到

安全性：杯子有没有毒或细菌

可*性：杯子从不同高度落下的损坏程度

可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用

兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等

易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况

；盛上汽油（案例二）放24小时检查泄漏时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

跌落测试: 杯子加包装(有填充物),在多高的情况摔下不破损

震动测试: 杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路/公路/航空运输

测试数据：测试数据具体编写此处略（最讨厌写测试数据了）。其中应用到：场景法、等价类划分法、因果图法、错误推测法、边界值法等方法 期望输出： 该期望输出需查阅国标、行标以及使用用户的需求

另一种： 总体来说从以下几个方面去考虑 功能性、性能性、易用性、可操作性、稳定性方面进行测试

功能性方面的测试，主要是考虑这个水杯是否能盛水，能盛多少水，能否盛热水，盛热水又能盛多少

性能性方面，盛冷水和热水时分别盛多少水杯能够承受 易用性方面，水杯易用手拿或端着

可操作性，也可以说和易用性相似，当盛冰水时感觉不到很冻，热水时感觉不到很烫，或者也可以归于功能测试 稳定性测试，水杯一直盛着水，是否长时间之后会漏水 测试驱动开发--

- 水杯类：父类（杯子） 属性，如材料、形状、容量等 方法，如盛水等 水杯可以装泥土当花盆用，要提供花盆的接口 水杯的子类：如一次性杯子等等 重写或添加属性、方法 容错：所装物体判断（物体的类别、物体的属性） 执行方法的前提判断（某些属性已经复值，有托盘则执行端的方法，有把手则执行拿的方法；或根据温度） 操作时注意，某个静态字段是否超出数值范围 试杯子 测试项目：杯子 需求测试:查看杯子使用说明书 界面测试:查看杯子外观 功能度：用水杯装水看漏不漏；水能不能被喝到 安全性：杯子有没有毒或细菌 可*性：杯子从不同高度落下的损坏程度 可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用

兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等 易用性：杯子是否烫手、是否有防滑措施、是否方便饮用 用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述 疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等 压力测试：用根针并在针上面不断加重量，看压强多大时会穿透 跌落测试: 杯子加包装(有填充物),在多高的情况摔下不破损 震动测试: 杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路/公路/航空运输 测试数据：测试数据具体编写此处略（最讨厌写测试数据了）。其中应用到：场景法、等价类划分法、因果图法、错误推测法、边界值法等方法 期望输出： 该期望输出需查阅国标、行标以及使用用户的需求 一、GUI测试： 1 看其形状、大小设计是否适合人方便拿起； 2 外观是否吸引人（广告嘛），赏心悦目； 3 带广告的图案沾水后是否掉色、模糊。 二、功能、压力测试： A 考量其装载能力： 在杯子内分别装入少量的、半杯的、满杯的： 1 热水； 2 冷水； 3 冰水； 4 咖啡； 看其装载量和装载时间以及纸杯拿在手中的硬度是否达到设计标准 B 装入热水后，纸杯是否有异味。 三、24*7测试： 装入液体后记录其多久以后漏水。

71、测试报告里面包含什么内容？

分析：测试报告，是测试工作结束后测试部门输出的一份测试结果，但每个公司的测试报告内容都会有些差别。有些公司的测试报告是有测试部门的负责人一人编写，或者是由每个测试工程师输出自己对应模块的测试报告再由测试组长整合成一份完整的测试报告；   回答：测试报告内容一般有：编写目的、系统简介、测试环境、测试方法和工具、测试执行结果与记录、缺陷汇总、遗留缺陷跟踪、测试用例执行情况、测试结论与建议等；

72、如果在测试过程中发现了BUG，可是开发不承认这是Bug，你会怎么办？

分析：HR问这个问题主要还是想知道你平时是如何处理与同事之间的关系。开发和测试是两个即对立又统一的两个岗位，所以开发和测试之间关系的处理也是HR面试过程中需要考虑的一个点。当然，HR问这个问题也表名该公司有氛围不是很好的风险。   回答：首先还是应该回归到客户需求上面，确认这个问题到底属不属于一个缺陷，如果确实是则要和开发同事解释清楚；如果开发还是坚持自己想法的话，则询问同事或者测试组长的意见，讨论这个问题到底属不属于缺陷问题，如果大家都觉得是则需要和开发解释清楚。

73、你们公司的需求评审是怎么进行的？

分析：需求评审，就是对客户需求，软件各个模块之间模糊的点进行审查，排除不理解或者没有考虑到的点。   回答：需求评审，在一些分工比较明确的公司，都是由PD（产品设计师）负责，需求确认好后再下发到开发和测试部门；分工不怎么明确的公司可能就是开发测试产品等大家坐在一起共同探讨；评审形式一般分为线上和线下两种方式，负责人一般会提前把需求文档下发到大家手上供大家整理各自的疑惑点，为后续的评审会议做准备。

74、MySQL的常用命令有哪些？

分析：数据库知识，是测试工程师必备的一个基本技能，在面试过程中也是经常会遇到的一个考点。对于刚入行的测试，对数据库知识的要求不会太高，只要求能掌握基本的增删改查语句即可。关于数据库的知识，在后续的时间里，也会慢慢的整理出来，供大家学习、参考。   回答：这里只给出几个标准的语法结构：         增：insert into 表名（列名） values （数据）;     如：在stu表中插入id为001，姓名为张三的学生，(insert into Stu（stu_id，stu_name） values （001,‘张三’）;）         删：delete from 表名 where 指定数据;     如：在stu表中删除id为001，姓名为张三的学生:(detele from Stu where stu_id=‘001’ and stu_name = ‘张三’;）         改：update 表名 set 改变项 where 指定数据;     如：在stu表中修改id为001的学生姓名为“张三”:(update Stu set stu_name = ‘张三’ where stu_id=‘001’ ;）         查：select （查询项） from 表名 where 指定条件;     如：在stu表中查询id为001，姓名为“张三”的学生信息:(select * from Stu where stu_name = ‘张三’ and stu_id=‘001’ ;）

75、Linux下的一些常用命令是什么？

分析：Linux系统，也是软件测试工程师必须要掌握的一项基本的技能，由于Linux具有运行稳定等很多优点，软件的服务器大多部署在Linux系统上，搭建测试环境也是测试工程师需要掌握的。关于Linux的知识，在后续的时间里，也会慢慢的整理出来，供大家学习、参考。由于Linux下很多命令都是常用的，所以这里不给出答案。

76、你未来的职业规划是什么？

分析：职业规划问题，是所有面试中最常问的问题，问的人可能是HR、部门主管、经理、甚至是董事长。同一个问题，问的人不同，想要获取的信息也肯定是不一样的。HR更多的想看你在公司的稳定性；技术主管可能更想知道你是否真的喜欢测试这个岗位，后期是否会主动学习型新的技能等；而经理更多的是看你的职业规划符不符合公司的发展方向；软件测试工程师的发展方向主要有：测试开发、产品经理、测试转开发、测试大牛、讲师等岗位；   回答：HR：如果是HR问的话，多从稳定性的角度回答，如：家人、朋友都在公司附近，或者喜欢贵公司的文化氛围等；         技术：回答之前可以先简单介绍一下自己为什么选择软件测试这个职业，以及自己对这个职业的看法，最后再回答自己的职业发展方向即可；         经理or董事长：这个回答回答起来的话还是比较难把握的，因为在面试时，面试者往往对公司的发展方向不是非常了解，所以在回答时可以再带一句，“具体的发展方向，还需要公司的发展方向去调整”。这样回答就会保险一些。

77、还有什么想要问我的吗？

分析：这个问题在每个面试的尾声都会被问到，直接说没有，会让HR觉得你不关心这个岗位，问的多了又会显得面试之前没有做好充分的准备。所以问题一般控制在两到三个比较好。   回答：1、公司的研发团队目前是什么规模？开发、测试分别有多少人？         2、公司的业务方向是什么？         3、如果我入职之后，我的工作职责是什么？

78、为什么想要离职？

分析：这个问题主要是想要了解你的近况，以及上一家公司是什么原因导致你离职，。在大部分情况下，HR都会理解你，但是在回答问题时千万不能太过于实诚，有些面试者一上来就在抱怨上一家公司如何压榨公司员工等，没有一家公司愿意接受这样的面试者，HR并不能完全感受你所遭遇到的，所以还是请控制好自己的负面情绪

79、你的测试职业发展是什么？

测试经验越多，测试能力越高。所以我的职业发展是需要时间积累的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年积累测试经验，按如何做好测试工程师的要点去要求自己，不断更新自己改正自己，做好测试任务。 优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但测试需要的基本技能我有信心在工作中得以发挥。

80、你认为测试人员需要具备哪些素质

做测试应该要有一定的协调能力，因为测试人员经常要与开发接触处理一些问题，如果处理不好的话会引起一些冲突，这样的话工作上就会不好做。还有测试人员要有一定的耐心，有的时候做测试很枯燥乏味。除了耐心，测试人员不能放过每一个可能的错误。

81、你为什么能够做测试这一行

虽然我的测试技术还不是很成熟，但是我觉得我还是可以胜任软件测试这个工作的，因为做软件测试不仅是要求技术好，还有有一定的沟通能力，耐心、细心等外在因素。综合起来看我认为我是胜任这个工作的。  

82、测试的目的是什么？

测试的目的是找出软件产品中的错误，是软件尽可能的符合用户的要求。当然软件测试是不可能找出全部错误的。  

83、测试分为哪几个阶段？

一般来说分为5个阶段：单元测试、集成测试、确认测试、系统测试、验收测试  

84、单元测试的测试对象、目的、测试依据、测试方法？

测试对象是模块内部的程序错误，目的是消除局部模块逻辑和功能上的错误和缺陷。测试依据是模块的详细设计，测试方法是采用白盒测试。  

85、怎样看待加班问题

加班的话我没有太多意见，但是我还是觉得如果能够合理安排时间的话，不会有太多时候加班的。  

86、结合你以前的学习和工作经验，你认为如何做好测试。

根据我以前的工作和学习经验，我认为做好工作首先要有一个良好的沟通，只有沟通无障碍了，才会有好的协作，才会有更好的效率，再一个就是技术一定要过关，做测试要有足够的耐心，和一个良好的工作习惯，不懂的就要问，实时与同事沟通这样的话才能做好测试工作。  

87、你为什么选择软件测试行业

因为之前了解软件测试这个行业，觉得他的发展前景很好。  

88、根据你以前的工作或学习经验描述一下软件开发、测试过程，由哪些角色负责，你做什么

要有架构师、开发经理、测试经理、程序员、测试员。我在里面主要是负责所分到的模块执行测试用例。

89、根据你的经验说说你对软件测试/质量保证的理解

软件质量保证与测试是根据软件开发阶段的规格说明和程序的内部结构而精心设计的一批测试用例(即输入数据和预期的输出结果)，并根据这些测试用例去运行程序，以发现错误的过程。它是对应用程序的各个方面进行测试以检查其功能、语言有效性及其外观排布。  

90、软件测试的流程是什么？

需求调查：全面了解系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等。根据系统概况进行项目所需的人员、时间和工作量估计以及项目报价。制定初步的项目计划。 测试准备：组织测试团队、培训、建立测试和管理环境等。 测试设计：按照测试要求进行每个测试项的测试设计，包括测试用例的设计和测试脚本的开发等。 测试实施：按照测试计划实施测试。 测试评估：根据测试的结果，出具测试评估报告。  

91、你对SQA的职责和工作活动(如软件度量)的理解?

SQA就是独立于软件开发的项目组，通过对软件开发过程的监控，来保证软件的开发流程按照指定的CMM规程(如果有相应的CMM规程),对于不符合项及时提出建议和改进方案，必要时可以向高层经理汇报以求问题的解决。通过这样的途径来预防缺陷的引入，从而减少后期软件的维护成本。SQA主要的工作活动包括制定SQA工作计划，参与阶段产物的评审，进行过程质量、功能配置及物理配置的审计等；对项目开发过程中产生的数据进行度量等等。  

92、说说你对软件配置管理的理解

项目在开发过程中要用相应的配置管理工具对配置项(包括各个阶段的产物)进行变更控制，配置管理的使用取决于项目规模和复杂性及风险的水平。软件的规模越大，配置管理就越显得重要。还有在配置管理中，有一个很重要的概念，那就是基线，是在一定阶段各个配置项的组合，一个基线就提供了一个正式的标准，随后的工作便基于此标准，并只有经过授权后才能变更这个标准。配置管理工具主要有CC，VSS,CVS,SVN等。

93、怎样写测试计划和测试用例

简单点，测试计划里应有详细的测试策略和测试方法，合理详尽的资源安排等，至于测试用例，那是依赖于需求(包括功能与非功能需求)是否细化到功能点，是否可测试等。  

94、什么是兼容性测试？兼容性测试侧重哪些方面？

兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。 兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。 兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。 兼容和配置测试的区别在于，做配置测试通常不是Clean OS下做测试，而兼容测试多是在Clean OS的环境下做的。  

95、我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？

①检查系统是否有中毒的特征； ②检查软件/硬件的配置是否符合软件的推荐标准； ③确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务； ④如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的； ⑤在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。  

96、测试的策略有哪些？

黑盒/白盒，静态/动态## 标题，手工/自动，冒烟测试，回归测试，公测（Beta测试的策略）  

97、你觉得bugzilla在使用的过程中，有什么问题？

①界面不稳定； ②根据需要配置它的不同的部分，过程很烦琐。 ③流程控制上，安全性不好界定，很容易对他人的Bug进行误操作； ④没有综合的评分指标，不好确认修复的优先级别。  

98、描述测试用例设计的完整过程？

①需求分析 + 需求变更的维护工作； ②根据需求得出测试需求； ③设计测试方案，评审测试方案； ④方案评审通过后，设计测试用例，再对测试用例进行评审；  

99、单元测试的策略有哪些？

逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析  

100、LoadRunner分哪三部分？

用户动作设计；场景设计； 测试数据分析；  

101、LoadRunner进行测试的流程?

①熟悉业务流程，测试规划 ②创建虚拟用户脚本 ③创建运行场景 ④运行测试脚本 ⑤监视场景 ⑥分析测试的结果 以上，最好是结合一个案例，根据以上流程来介绍。  

102、软件的评审一般由哪些人参加？其目的是什么？

在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷，并采取补救措施，以及找出在性能、安全性和经济方面的可能的改进。 人员：用户、客户或有关部门开发人员，测试人员，需求分析师都可以，就看处于评审那个阶段  

103、Beta测试与Alpha测试有什么区别？

①Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场 ②Alpha testing (α测试),是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试

104、你认为做好测试计划工作的关键是什么？

软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试；  

做好测试计划工作的关键 ：目的，管理，规范

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

105、你认为做好测试用例工作的关键是什么？

需求和设计文档的理解程度，对系统的熟悉程度  

106、简述一下缺陷的生命周期？

提交->确认->分配->修复->验证->关闭  

107、软件的安全性应从哪几个方面去测试？

(1) 用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议 (2) 加密机制 (3) 安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描 (4) 数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理 (5) 防病毒系统  

108、你觉得软件测试通过的标准应该是什么样的？

缺陷密度值达到客户的要求  

109、一套完整的测试应该由哪些阶段组成？

需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）

110、如何理解压力、负载、性能测试测试？

性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。 压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试。增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。而负载测试是压力相对较大的测试，主要是测试系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。 100个用户对系统进行连续半个小时的访问可以看作压力测试，那么连续访问8个小时就可以认为负载测试，1000个用户连续访问系统1个小时也可以看作是负载测试。 实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行测试。  

111、如何编写提交给用户的测试报告？

①根据内部测试报告进行编写，一般可以摘录； ②不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道； ③报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的；-报告上面的内容尽量要真实可靠； ④整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告。

112、您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

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

②边界值分析法 边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误。 使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。 ③错误推测法 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。例如, 在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例。 ④因果图方法 前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等。考虑输入条件之间的相互组合,可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例。 这就需要利用因果图（逻辑模型）。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。  

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

最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。做测试，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的我没有把握，其他点我都很有信心做好它。  

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

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

115、写出bug报告当中一些必备的内容。

硬件平台和操作系统 测试应用的硬件平台（Platform），通常选择“PC”。 测试应用的操作系统平台（OS）。 a) 版本 提交缺陷报告时通过该字段标识此缺陷存在于被测试软件的哪个版本。 b) Bug报告优先级 c) Bug状态 d) Bug的编号 e) 发现人

f) 提交人 g)指定处理人 h) 概述 i) 从属关系 j) 详细描述 k) 严重程度

l) 所属模块 m) 附件 n) 提交日期

116、开发人员老是犯一些低级错误怎么解决？

从两个方面入手： 一方面从开发管理入手，也就是从根源来解决问题。可以制定规范的开发流程，甚至可以制定惩罚制度，还有就是软件开发前做好规划设计。 另一方面就是加强测试，具体做法就是加强开发人员的自己测试，把这些问题“消灭”在开发阶段，这是比较好的做法。  

117、简述一下c/s模式或者b/s模式？

C/S模式：客户端/服务器模式。工作原理：Client向Server提交一个请求；Server则使用一些方法处理这个请求，并将效果返回给Client。 B/S结构，即Browser/Server(浏览器/服务器)结构，主要是利用了不断成熟的WWW浏览器技术，结合浏览器的多种Script语言(VBScript、JavaScript…)和ActiveX技术，用通用浏览器就实现了原来需要复杂专用软件才能实现的强大功能，并节约了开发成本，是一种全新的软件系统构造技术。

118.给你一个字符串，你怎么判断是不是ip地址？手写这段代码，并写出测试用例

参考回答：

P的格式：(1~ 255).(0~ 255).(0~ 255).(0~255) 方法一：基于对字符串的处理 ```cpp public static void main(String[] args){ Scanner scanner = new Scanner(http://System.in); String ipStr = scanner.next(); boolean isIpLegal = isIpLegal(ipStr); if(isIpLegal) { System.out.println(ipStr + " 合法"); } else{ System.out.println(ipStr + " 非法"); } } public static boolean isIpLegal(String str){ //检查ip是否为空 if(str == null){ return false; } //检查ip长度，最短为：x.x.x.x(7位)，最长为：http://xxx.xxx.xxx.xxx(15位) if(str.length() < 7 || str.length() > 15){ return false; } //对输入字符串的首末字符判断，如果是"."则是非法IP if(str.charAt(0) == '.' || str.charAt(str.length()-1) == '.'){ return false; } //按"."分割字符串，并判断分割出来的个数，如果不是4个，则是非法IP String[] arr = str.split("\\."); if(arr.length != 4){ return false; } //对分割出来的每个字符串进行单独判断 for(int i = 0; i < arr.length; i++){ //如果每个字符串不是一位字符，且以'0'开头，则是非法的IP，如：01.002.03.004 if(arr[i].length() > 1 && arr[i].charAt(0) == '0'){ return false; } //对每个字符串的每个字符进行逐一判断，如果不是数字0-9，则是非法的IP for(int j = 0; j < arr[i].length(); j++){ if (arr[i].charAt(j) < '0' || arr[i].charAt(j) > '9'){ return false; } } } //对拆分的每一个字符串进行转换成数字，并判断是否在0~255 for(int i = 0; i < arr.length; i++){ int temp = Integer.parseInt(arr[i]); if(i == 0){ if (temp < 1 || temp > 255){ return false; } } else{ if(temp < 0 || temp > 255){ return false; } } } return true; }

方法二：正则表达式

public static void main(String[] args) { Scanner scanner = new Scanner(http://System.in); String ipStr = scanner.next(); boolean isIpLegal = isIpLegal(ipStr); if(isIpLegal) { System.out.println(ipStr + " 合法"); } else{ System.out.println(ipStr + " 非法"); } } public static boolean isIpLegal(String ipStr) { String ipRegEx = "^([1-9]|([1-9][0-9])|(1[0-9][0-9])|(2[0-4][0-9])|(25[0-5]))(\\.([0-9]|([1-9][0-9])|(1[0-9][0-9])|(2[0-4][0-9])|(25[0-5]))){3}$"; Pattern pattern = Pattern.compile(ipRegEx); Matcher matcher = pattern.matcher(ipStr); if (matcher.matches()) { return true; } else { return false; } }

等价类划分：

119.请进行测试用例设计：一串数字，闰年的判别

参考回答：

判断闰年的标准是:能整除4且不能整除100，能整除400。

设定合法的年份为1-9999

public class Test2 { public static void main(String[] args) { Scanner in = new Scanner (http://System.in); int year=in.nextInt(); if(year<=0||year>9999) { System.out.println("请输入正确的年份"); } if((year%4==0&&year%100!=0)||year%400==0) { System.out.println("闰年"); }else { System.out.println("不是闰年"); } } }

测试用例：

120.请你说一说简单用户界面登陆过程都需要做哪些分析

参考回答：

功能测试

输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。

输入错误的用户名或者密码,验证登录会失败，并且提示相应的错误信息。

登录成功后能否能否跳转到正确的页面

用户名和密码，如果太短或者太长，应该怎么处理

用户名和密码，中有特殊字符（比如空格），和其他非英文的情况

记住用户名的功能

登陆失败后，不能记录密码的功能

用户名和密码前后有空格的处理

密码是否非明文显示显示，使用星号圆点等符号代替。

牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使 用者），刷新或换一个按钮是否好用

登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确

输入密码的时候，大写键盘开启的时候要有提示信息。

什么都不输入，点击提交按钮，检查提示信息。

界面测试

布局是否合理，testbox和按钮是否整齐。

testbox和按钮的长度，高度是否符合要求。

界面的设计风格是否与UI的设计风格统一。

界面中的文字简洁易懂，没有错别字。

性能测试

打开登录页面，需要的时间是否在需求要求的时间内。

输入正确的用户名和密码后，检查登录成功跳转到新页面的时间是否在需求要求的时间内。

模拟大量用户同时登陆，检查一定压力下能否正常登陆跳转。

安全性测试

登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)。

用户名和密码是否通过加密的方式，发送给Web服务器。

用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript 验证。

用户名和密码的输入框，应该屏蔽SQL注入攻击。

用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）。

防止暴力破解，检测是否有错误登陆的次数限制。

是否支持多用户在同一机器上登录。

同一用户能否在多台机器上登录。

可用性测试

是否可以全用键盘操作，是否有快捷键。

输入用户名，密码后按回车，是否可以登陆。

输入框能否可以以Tab键切换。

兼容性测试

不同浏览器下能否显示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。

同种浏览器不同版本下能否显示正常且功能正常。

不同的平台是否能正常工作，比如Windows, Mac。

移动设备上是否正常工作，比如Iphone, Andriod。

不同的分辨率下显示是否正常。

本地化测试

不同语言环境下，页面的显示是否正确。

121.请对这个系统做出测试用例：一个系统，多个摄像头，抓拍车牌，识别车牌，上传网上，网上展示

参考回答：

1.功能：

每个摄像头都能抓拍车牌；每个摄像头抓拍到的车牌能正常交给系统处理；系统能够正确识别车牌；系统能够将识别出的车牌上传；上传至网络的车牌能够正常展示出来；

一.功能测试

使用正常的车牌，保持车牌静止，检查每个摄像头是否能抓拍车牌；

使用类似非车牌的写有字的纸板，检查每个摄像头是否抓拍；

使用正常的车牌，保持车牌较高速移动，检查每个摄像头是否能抓拍车牌；

在多种情况下检查每个摄像头抓拍到的车牌能否正常交给系统处理，如临时断电、断网后能否正常将数据交给系统；

使用抓拍到的正常的车牌，交由系统处理，检查系统能否识别车牌；

使用非车牌的其他图片，交由系统处理，检查系统能否识别；

在多种情况下检查系统能否将正常识别出的车牌进行上传，如临时断电、断网后未上传数据是否能继续上传；

构造非车牌的其他内容的数据，检查系统能否将异常内容进行上传；

检查上传至网络的车牌能否正常展示出来；

上传非车牌的其他内容的数据，检查能否正常显示出来。

二.性能测试

同时向一个摄像头展示多个静止的车牌，检查摄像头能否抓拍到多个车牌；

同时向一个摄像头展示多个较高速运动的车牌，检查摄像头能否抓拍到多个车牌；

抓拍后，检查系统识别车牌的时间是否在需求要求的时间内；

模拟大量抓拍照片同时交由系统处理，检查一定压力下系统能否正常识别车牌；

模拟大量车牌同时上传，检查一定压力下能否上传成功。

三.安全性测试

检查是否能够通过给车牌加装饰物等方法，使摄像头无法抓拍或抓拍后系统无法正常识别车牌。

122.请你对吃鸡游戏进行压力测试

参考回答：

首先明确需要测试压力的内容:

游戏服务器硬件

a.硬盘I/o

b.内存

c.CPU

网络压力

a.长连接

a1.最大连接数

a2.流量(内网、外网、进、出)

b.长连接短周期(类似Http的TCP应用，这个比较特殊的一个需求，专门针对LoginAgent)

b1.每秒建立的连接数

b2.实际处理能力

数据库

a.每秒事务数

b.每秒锁等待数

c.平均延时(ms)

d.CPU暂用

多线程的最优线程数

a.数据库执行的多线程

b.多连接处理

Windows Server环境测试方式

服务器性能监测

使用Server自带的性能监测器设置各个进程的监测参数。Window的这个自动工具做的相当强大。大家自己摸一摸基本就会用了。每个参数都由详细的说明。

案例设计注意

a.对于数据库的性能测试上，现在由于所有的游戏服务器构架在DB前面都有一个实现DB缓冲功能的进程，以减少数据库频繁的读写操作。所以其实数据库的读是一个轻量级的数量；而数据库的写操作是一个周期性能过程。案例设计一定要能够驱动这种周期性能过程。比如我们游戏的战斗，导致游戏玩家数据的改变，或驱动所有在线玩家数据的周期性存储。

b.选择具有代表性，并且最频繁的游戏操作。用于进行最高用户在线的各种性能指标采集。如，开枪、道具拾取、道具使用、移动、聊天

c.聊天性能测试

广播聊天是最为考验游戏信息发送能力的功能。通过进行全局广播的压力测试。我们可以获取服务器进程发送信息到客户端的最高承载量。进而可以对我们的各种广播功能进行一个预估和频率限制。

d.同屏玩家的移动测试

移动+广播。这两种信息，基本是网络游戏流量的70-80%左右。同屏玩家数量，将会增加各种数据的广播需求，非常影响游戏性能。所以同屏的移动测试也是广播测试的一个必要环节。需要根据实际结果进行适当的优化。

e.大量玩家同时登录测试

玩家登录时，有大量的信息需要进行分配和初始化；同时也有大量的数据需要下传客户端。服务器需要进行大量的TCP连接建立。所以是一个比较关键的过程。这个测试案例是一个比较特殊，但是运营是肯定会碰到的案例。

f.由于线程池处理事务，随着事务的时耗，存在一个最优线程数的问题。过多的线程反而会降低服务器效率

细节问题

a.进行测试需要仔细思考客户端性能影响服务器最后表现的可能性。比如

a1.模拟客户端的性能无法有效处理服务器返回信息,可能就导致服务器发送的信息缓存在服务器系统缓存，从而表现出服务器内存不断增加。表现为服务器发送能力不足，其实可能根本就是客户端的性能问题

a2.客户端性能问题，导致发起的请求数过少，从而导致单位时间内服务器处理的请求过少。表现为服务器性能不足，其实根本就是客户端的请求能力不足。

b.网络带宽导致最后表现不足

b1.确认服务器的各个网卡，以及相互的带宽。不然可能因为相互带宽，导致服务器对于客户端请求的处理延时。表现为服务器卡机

b2.客户端模拟多个玩家，比如1000个玩家。而客户端的网卡或者客户端与服务器之间的中转服务器带宽过小，导致服务器数据发送不出，内存不断增加。表现为服务器发送能力不足，其实是中间带宽问题。

c.debug i/o导致服务器性能下降

c1.进行性能测试，一定要取消debug用的同步的i/o.比如我们服务器的debuginternalLog.同步i/o是非常影响性能的，特别在压力测试下可能导致每秒上千上万甚至几十万次的执行。一处的文件写入操作就可以导致几十万次的处理能力变成几千次的处理能力。

c2.客户端避免进行阻塞操作导致模拟多用户性能下降，导致服务器表现性能下降

d.流量需要区分内网

网内、外网流量在游戏正式运行时是完全分开的。价格也是完全不同的。一个千M的外网是一个无法想象的运营成本，而kmbps/s现在已经是一个可以接受的代价。游戏进程需要进行不同网卡的配置和绑定。确定内外网流量。

123.请你对朋友圈点赞功能进行测试

参考回答：

是否可以正常点赞和取消；点赞的人是否在可见分组里；点赞状态是否能即时更新显示；点赞状态，共同好友是否可见；性能检测，网速快慢对其影响；点赞显示的是否正确，一行几个；点赞是否按时间进行排序，头像对应的是否正确；是否能在消息列表中显示点赞人的昵称、5.不同手机，系统显示界面如何；

备注；

可扩展性测试，点赞后是否能发表评论；是否在未登录时可查看被点赞的信息。

124.如果做一个杯子的检测，你如何测试（经典）

功能

水倒水杯容量的一半

水倒规定的安全线

水杯容量刻度与其他水杯一致

盖子拧紧水倒不出来

烫手验证

性能

使用最大次数或时间

掉地上不易损坏

盖子拧到什么程度水倒不出来

保温时间长

杯子的耐热性

杯子的耐寒性

长时间放置水不会漏

杯子上放置重物达到什么程度杯子会被损坏

界面

外观完整、美观

大小与设计一样（高、宽、容量、直径）

拿着舒服

材质与设计一样

杯子上的图案掉落

图案遇水溶解

安全

杯子使用的材质毒或细菌的验证

高温材质释放毒性

低温材质释放毒性

易用性

倒水方便

喝水方便

携带方便

使用简单，容易操作

防滑措施

兼容性

杯子能够容纳果汁、白水、酒精、汽油等。

震动测试

杯子加包装（有填充物），六面震动，检查产品是否能应对铁路/公路/航空运输。

可移植性

杯子在不同地方、温度环境下都可以正常使用。

125.如何对一个页面进行测试

参考回答：

UI测试：页面布局、页面样式检查、控件长度是否够长；显示时，是否会被截断；支持的快捷键，Tab键切换焦点顺序正确性等。功能测试：页面上各类控件的测试范围，测试点。结合控件的实际作用来补充检查点：比如， 密码框是否*显示， 输入是否做trim处理等。安全测试：输入特殊字符，sql注入，脚本注入测试。后台验证测试，对于较重要的表单 ，绕过js检验后台是否验证；数据传输是否加密处理，比如， 直接请求转发，地址栏直接显示发送字符串？兼容性测试性能测试

126.如何对水壶进行测试(同水杯)

参考回答：

功能

水倒水壶容量的一半

水倒规定的安全线

水壶容量刻度与其他水壶一致

盖子拧紧水倒不出来

烫手验证

性能

使用最大次数或时间

掉地上不易损坏

盖子拧到什么程度水倒不出来

保温时间长

壶的耐热性

壶的耐寒性

长时间放置水不会漏

壶上放置重物达到什么程度壶会被损坏

界面

外观完整、美观

大小与设计一样（高、宽、容量、直径）

拿着舒服

材质与设计一样

壶上的图案掉落

图案遇水溶解

安全

壶使用的材质毒或细菌的验证

高温材质释放毒性

低温材质释放毒性

易用性

倒水方便

喝水方便

携带方便

使用简单，容易操作

防滑措施

兼容性

壶能够容纳果汁、白水、酒精、汽油等。

震动测试

壶加包装（有填充物），六面震动，检查产品是否能应对铁路/公路/航空运输。

可移植性

壶在不同地方、温度环境下都可以正常使用。

127.如何对淘宝搜索框进行测试

参考回答：

1.功能测试

1.输入关键字，查看: 返回结果是否准确，返回的文本长度需限制

1.1输入可查到结果的正常关键字、词、语句，检索到的内容、链接正确性；

1.2输入不可查到结果的关键字、词、语句；

1.3输入一些特殊的内容，如空、特殊符、标点符、极限值等，可引入等价类划分的方法等；

2.结果显示：标题，卖家，销售量，单行/多行，是否有图片

3.结果排序：价格 销量 评价 综合

4.返回结果庞大时，限制第一页的现实量，需支持翻页

5.多选项搜索：关键字 品牌 产地 价格区间 是否天猫 是否全国购

6.是否支持模糊搜索，支持通配符的查询

7, 网速慢的情况下的搜索

8.搜索结果为空的情况

9.未登录情况和登录情况下的搜索（登录情况下 存储用户搜索的关键字/搜索习惯）

性能测试：

1.压力测试：在不同发用户数压力下的表现（评价指标如响应时间等）

2.负载测试：看极限能承载多大的用户量同时正常使用

3.稳定性测试：常规压力下能保持多久持续稳定运行

4.内存测试：有无内存泄漏现象

5.大数据量测试：如模拟从庞大的海量数据中搜索结果、或搜索出海量的结果后列示出来，看表现如何等等。

易用性：交互界面的设计是否便于、易于使用

1.依据不同的查询结果会有相关的人性化提示，查不到时告知？查到时统计条数并告知？有疑似输入条件错误时提示可能正确的输入项等等处理；

2.查询出的结果罗列有序，如按点击率或其他排序规则，确保每次查询出的结果位置按规则列示方便定位，显示字体、字号、色彩便于识别等等；

3.标题查询、全文检索、模糊查询、容错查询、多关键字组织查询（空格间格开）等实用的检索方式是否正常？

4.输入搜索条件的控件风格设计、位置摆放是否醒目便于使用者注意到，有否快照等快捷查看方式等人性化设计？

兼容性

1.WINDOWS/LINUX/UNIX等各类操作系统下及各版本条件下的应用

2.IE/FIREFOX/GOOGLE/360/QQ等各类浏览器下及各版本条件下、各种显示分辨率条件下的应用

3.SQL/ORACLE/DB2/MYSQL等各类数据库存储情况下的兼容性测试

4.简体中文、繁体中文、英文等各类语种软件平台下的兼容性测试

5.IPHONE/IPAD、安卓等各类移动应用平台下的兼容性测试

6.与各相关的监控程序的兼容性测试，如输入法、杀毒、监控、防火墙等工具同时使用

安全性

1.被删除、加密、授权的数据，不允许被SQL注入等攻击方式查出来的，是否有安全控制设计；

2.录入一些数据库查询的保留字符，如单引号、%等等，造成查询SQL拼接出的语句产生漏洞，如可以查出所有数据等等，这方面要有一些黑客攻击的思想并引入一些工具和技术，如爬网等。

3.通过白盒测试技术，检查一下在程序设计上是否存在安全方面的隐患；

4.对涉及国家安全、法律禁止的内容是否进行了相关的过滤和控制；

128.如何对一瓶矿泉水进行测试

参考回答：

界面测试:查看外观是否美

功能度：查看水瓶漏不漏；瓶中水能不能被喝到

安全性：瓶子的材质有没有毒或细菌

可靠性：从不同高度落下的损坏程度

可移植性：再不同的地方、温度等环境下是否都可以正常使用

兼容性：是否能够容纳果汁、白水、酒精、汽油等

易用性：是否烫手、是否有防滑措施、是否方便饮用

用户文档：使用手册是否对的用法、限制、使用条件等有详细描述

疲劳测试：将盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

跌落测试:测试在何种高度跌落会破坏水瓶

129.请你说一下jmeter

参考回答：

Jmeter：Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试，但后来扩展到其他测试领域。它可以用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器， 等等。JMeter 可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。

130.为什么使用Jmeter：

开源免费，基于Java编写，可集成到其他系统可拓展各个功能插件

支持接口测试，压力测试等多种功能，支持录制回放，入门简单

相较于自己编写框架或其他开源工具，有较为完善的UI界面，便于接口调试

多平台支持，可在Linux，Windows，Mac上运行

用例生成与导出：

Jmeter的用例格式为jmx文件，实际为xml格式，感兴趣可以学习下自己定制生成想要的jmx文件。

生成原则：

每个功能模块为一个独立的jmx文件。增加可维护性。（尽量不要将一个jmx文件放入太多功能，后期维护成本会很高。）

模块的私有变量保存在模块中，多模块共有的（例如服务器ip端口等）可以考虑存在单独的文件中读取。

接口测试不要放太多线程，毕竟不是做压力测试，意义也不大。

导出方法：

编写测试用例

文件——保存为——确定：

4. Jmeter运行模式及参数

GUI模式

打开已有的jmx文件（文件——打开）

点击启动按钮运行

命令行模式

依赖：

配置jmeter环境变量（windows下为将${jmeterhome}/bin加入Path变量）

如果未加入环境变量，在执行的时候可以直接给出全路径或在${jmeterhome}/bin下执行

命令：

jmeter -n -t -l

参数：

-h 帮助 -> 打印出有用的信息并退出

-n 非 GUI 模式 -> 在非 GUI 模式下运行 JMeter

-t 测试文件 -> 要运行的 JMeter 测试脚本文件

-l jtl文件 -> 记录结果的文件

-r 远程执行 -> 启动远程服务

-H 代理主机 -> 设置 JMeter 使用的代理主机

-P 代理端口 -> 设置 JMeter 使用的代理主机的端口号

-j 日志文件->设置JMeter日志文件的名称

实例：

JMeter -n -t my_test.jmx -l log.jtl -H my.proxy.server -P 8000

执行步骤：

JMeter 默认去当前目录寻找脚本文件，并把日志记录在当前目录。比如你在 C:\tools\apache-jmeter-2.11\bin 目录下执行以上命令，JMeter 会去该目录下寻找 test.jmx 脚本并把执行结果放在该目录。如果你的脚本在其他目录，而且想要把执行结果放在另外文件夹，可以使用绝对路径告诉 JMeter。

执行结果查看：

GUI界面打开聚合报告

在GUI界面创建一个聚合报告

聚合报告界面点击浏览，选中生成的.jtl文件，打开

8. Jmeter使用

Jmeter创建接口测试计划实例

测试用例应该作为测试的基础内容，而用例的结构可能划分，则是用例的基础（忽然在这里想说一下，用例仅仅是一项测试活动的纲要，有最好，没有的话能保证质量也OK。更不用说用例的格式问题，无论是表格还是导图，其实都无所谓！本文的用例是指jmx文件中的控件结构）。

模块名称（测试计划）：每个模块独立划分为一个jmx文件（例如登陆模块），最好与接口类一一对应。对应的服务器信息，数据库信息等可存在这里。

数据准备：用于测试数据的准备（例如账号信息）。

结果查看：用于放置需要查看结果的控件（例如结果树）。

线程组：所有的接口测试用例放在线程组下，集中定义线程等信息

获取线程对应测试数据：用于获取针对独立线程的测试数据，例如在数据准备里面获得了账号信息，在这里根据账号信息去数据库获取对应的名称，ID等信息。

请求名称：用简单控制器为文件夹，内有不同的请求。简单控制器为一个独立的接口，不同请求对应不同的代码路径（例如成功请求，失败请求等）。建议请求名称最好用英文形式，否则后期持续集成或许会出现问题（no zuo no die！）。

在每条请求内放置正则匹配（用于应对需要返回值作为下次请求的参数的情况）以及断言。

131. 请你进行测试：前端下拉框实现，测试下拉框定位方式

参考回答：

Selenium+Python自动化测试对下拉菜单的定位

通过selenium.webdriver.support.ui的Select进行定位

下拉菜单如下图：

定位代码：

```python from selenium.webdriver.support.ui import Select # 通过index进行选择 Select(driver.find_element_by_id("gender")).select_by_index(1) # 通过value进行选择 Select(driver.find_element_by_id("gender")).select_by_value("2") # 通过选项文字进行选择 Select(driver.find_element_by_id("gender")).select_by_visible_text("Male") # 注：Select only works on 标签的下拉菜单有效）.

定位非标签的下拉菜单

非标签的下拉菜单如下图所示：

定位非标签的下拉菜单中的选项，需要两个步骤，先定位到下拉菜单，再对其中的选项进行定位。

定位代码：

# 先定位到下拉菜单 drop_down = driver.find_element_by_css_selector("div#select2_container > ul") # 再对下拉菜单中的选项进行选择 drop_down.find_element_by_id("li2_input_2").click() # 注：也可以用此方法定位