测试面试题

进程和线程的区别在于：
简而言之,一个程序至少有一个进程,一个进程至少有一个线程.
线程的划分尺度小于进程，使得多线程程序的并发性高。
另外，进程在执行过程中拥有独立的内存单元，而多个线程共享内存，从而极大地提高了程序的运行效率。
线程在执行过程中与进程还是有区别的。每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出口。但是线程不能够独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制。
从逻辑角度来看，多线程的意义在于一个应用程序中，有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用，来实现进程的调度和管理以及资源分配。这就是进程和线程的重要区别。
测试技术面试题
1、根据自己的理解什么是测试用例和测试规程，设计一个测试用例应当从哪几方面考虑？
答：狭义的讲，一个测试用例就是测试人员用以测试被测软件的某个特性或特性组合的一组数据。这组数据可能是从用户处得来的实际的一组数据，也可能是测试人员专门设计出来的测试软件某些功能的一组数据。
测试规程就是详细的对测试用例设计方法、测试方法、测试工具、测试环境和测试数据进行描述的文档，还可以包括能把某个或某一组测试用例应用到被测软件上完成某项测试的一系列的操作步骤。
设计测试用例应当从以下几方面考虑：边界值，等价类划分，有效/无效值等。
2、 什么是软件质量保证？软件质量保证人员与开发人员的关系如何？
答：软件质量保证就是通过确保软件过程的质量，来保证软件产品的质量。
软件质量保证人员和开发人员之间具有管理上的严格的独立性，两个小组的管理员都不能越权管理另一组，但都可以向更高层的管理者汇报软件开发中的问题

3、 您认为做好测试计划工作的关键是什么？
答：1. 明确测试的目标，增强测试计划的实用性
2. 坚持“5W”规则，明确内容与过程，‘what’‘why’‘when’‘where’‘how’
3. 采用评审和更新机制，保证测试计划满足实际需求
4. 分别创建测试计划与测试详细规格、测试用例

4、请画出软件测试过程V模型，并写出采用V模型存在的问题

用户需求

验收测试

需求分析

与系统设计系统测试

概要设计集成测试

详细设计单元测试

编码

2） 采用V模型存在问题：

①.测试是开发之后的一个阶段。

②.测试的对象就是程序本身。

③ 实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。

④ 整个软件产品的过程质量保证完全依赖于开发人员的能力和对工作的责任心，而且上一步的结果必须是充分和正确的，如果任何一个环节出了问题，则必将严重的影响整个工程的质量和预期进度。

5、软件测试的原则，这些原则能更好的理解和指导我们做测试工作，请把你所知道的原则详细列出来

答：1、测试可以显示缺陷的存在，但不能证明系统不存在缺陷。

2、穷尽测试是不可能的

3、测试的尽早介入（越晚发现一个bug,修改bug成本成倍增加）。

4、第三方或独立的测试团队。

5、测试的标准是用户的需求

6、尽早定义产品的质量标准（测试用例应包括明确的输入和输出，做到有的放矢）

7、用例全面（有效数据、无效数据）

8、及时更新测试用例，减少测试人员形成定势思维（杀虫剂悖论：杀虫剂用得多了，害虫就有免疫力，杀虫剂就发挥不了效力）

9、严格执行测试计划，排除测试的随意性。

10、充分注意测试中的群集现象，80%的错误集中在20%的程序模块中。

11、应当对每一个测试结果做全面检查。

12、妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

13、测试贯穿于整个生命周期

6、您认为软件工程师应具备哪些能力和素质

答：能力1、沟通能力2、移情能力3、技术能力4、自信心5、外交能力6、幽默感7、很强的记忆力

素质(1) 首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在开发过程中不管遇到什么样的困难，我相信你一定能克服。

(2) 善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生。别人认为是对的，我却认为不是对的。

(3) 打破砂锅问到底的精神，对于只出现过一次的bug，一定找出原因，不解决誓不罢休。

(4) 保持一个良好的心情，否则可能无法把测试作好。不要把生活中的不愉快的情绪带到工作中来。

(5) 做测试时要细心，不是所有的bug都能很容易的找出，一定要细心才能找出这些bug。

(6) 灵活一些，聪明一点，多制造一些容易产生bug的例子。

(7) 在有条件的情况下，多和客户沟通，他们身上有你所需要的。

(8) 设身处地为客户着想，从他们的角度去测试系统。

(9) 不要让程序员，以“这种情况不可能发生”这句话说服你，相反，你应该去说服他，告诉他在客户心里，并不是这样的。

(10) 考虑问题要全面，结合客户的需求、业务的流程、和系统的构架，等多方面考虑问题。

(11) 提出问题不要复杂化，这一点和前面的有点矛盾，如果你是一新手，暂时不要管这一点，因为最终将有你的小组成员讨论解决。

(12) 追求完美，对于新测试员来说，努力的追求完美，这对你很好，尽管有些事无法做到，但你应该去尝试。

(13) 幽默感，能和开发小组很好的沟通是关键，试着给你的开发小组找一个“BUG杀手”，或对他们说“我简直不敢相信，你写的程序居然到现在没有找到BUG”。

7、举例并说明常见的设计测试用例的方法

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

2.）边界值分析法边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

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

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

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

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

8、详细的描述一个测试活动完整的过程。

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

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

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

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

5. 测试人员搭建环境

6. 开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现bug后提交给bugzilla。 7. 开发提交第二个版本，包括bugfix以及增加了部分功能，测试人员进行测试。

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

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

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

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

9、在您以往的工作中，一条软件缺陷（或者叫bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（bug）记录？ 1. 在传统的bugzilla中，bug描述应该包括以下的信息

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

3. 开发的接口人员

4. bug的优先级

5. bug的严重程度

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

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

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

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

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

1、什么是兼容性测试？兼容性测试侧重哪些方面？
参考答案：
兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。
兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。
兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。
兼容和配置测试的区别在于，做配置测试通常不是Clean OS下做测试，而兼容测试多是在Clean OS的环境下做的。
2、我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？
参考答案：
1、检查系统是否有中毒的特征；
2、检查软件/硬件的配置是否符合软件的推荐标准；
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务；
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。
3、测试的策略有哪些？
参考答案：
黑盒/白盒，静态/动态，手工/自动，冒烟测试，回归测试，公测（Beta测试的策略）
4、正交表测试用例设计方法的特点是什么？
参考答案：
用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；
对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；
具体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。
5、描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程？
参考答案：
就是Bugzilla的状态转换图。
6、你觉得bugzilla在使用的过程中，有什么问题？
参考答案：
界面不稳定；
根据需要配置它的不同的部分，过程很烦琐。
流程控制上，安全性不好界定，很容易对他人的Bug进行误操作；
没有综合的评分指标，不好确认修复的优先级别。
7、描述测试用例设计的完整过程？
参考答案：
需求分析 + 需求变更的维护工作；
根据需求 得出测试需求；
设计测试方案，评审测试方案；
方案评审通过后，设计测试用例，再对测试用例进行评审；
8、单元测试的策略有哪些？
参考答案：
逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析
9、LoadRunner分哪三部分？
参考答案：
用户动作设计；
场景设计；
测试数据分析；
10、LoadRunner进行测试的流程?
参考答案：
1、 测试测试
2、 创建虚拟用户脚本
3、 创建运行场景
4、 运行测试脚本
5、 监视场景
6、 分析测试的结果
以上，最好是结合一个案例，根据以上流程来介绍。
什么是并发？在lordrunner中，如何进行并发的测试？集合点失败了会怎么样？
参考答案：
在同一时间点，支持多个不同的操作。
LoadRunner中提供IP伪装，集合点，配合虚拟用户的设计，以及在多台电脑上设置，可以比较好的模拟真实的并发。
集合点，即是多个用户在某个时刻，某个特定的环境下同时进行虚拟用户的操作的。集合点失败，则集合点的才操作就会取消，测试就不能进行。
12、使用QTP做功能测试，录制脚本的时候，要验证多个用户的登录情况/查询情况，如何操作？
参考答案：
分析用户登录的基本情况，得出一组数据，通过性测试/失败性测试的都有（根据TC来设计这些数据），然后录制登录的脚本，将关键的数据参数化，修改脚本，对代码进行加强，调试脚本。
13、QTP中的Action有什么作用？有几种？
参考答案：
Action的作用
n 用Action可以对步骤集进行分组
n 步骤重组，然后被整体调用
n 拥有自己的sheet
n 组合有相同需求的步骤，整体操作
n 具有独立的对象仓库
Action的种类
n 可复用Action
n 不可复用Action
n 外部Action
14、TestDirector有些什么功能，如何对软件测试过程进行管理？
参考答案：
需求管理
n 定义测试范围
n 定义需求树
n 描述需求树的功能点
测试计划
n 定义测试目标和测试策略。
n 分解应用程序，建立测试计划树。
n 确定每个功能点的测试方法。
n 将每个功能点连接到需求上，使测试计划覆盖全部的测试需求。
n 描述手工测试的测试步骤
n 指明需要进行自动测试的功能点
测试执行
n 定义测试集合。
n 为每个测试人员制定测试任务和测试日程安排。
n 运行自动测试。
缺陷跟踪
n 记录缺陷
n 查看新增缺陷，并确定哪些是需要修正的
n 相关技术人员修改缺陷
n 回归测试
n 分析缺陷统计图表，分析应用程序的开发质量。
15、你所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）？
参考答案：Compatibility Testing（兼容性测试），也称“Configuration testing（配置测试）”，测试软件是否和系统的其它与之交互的元素之间兼容，如：浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

Functional testing (功能测试)，也称为behavioral testing（行为测试），根据产品特征、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。
Performance testing（性能测试），评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。
16、软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
参考答案：
Bug描述（summary）
环境信息：操作系统/数据库/浏览器/软件版本 (OS/Database/Project/Build/Release)
所属Feature：哪个功能模块的问题 (可附带选择操作命令)
测试/开发人员
严重等级(1-5)
客户优先级
开发人员修复的工作量
风险程度
状态
重现步骤
实际结果
语气结果
有没有Workaround
是不是回归问题
分析
5C标准
5C标准Correct（准确）：每个组成部分的描述准确，不会引起误解；
Clear（清晰）：每个组成部分的描述清晰，易于理解；
Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容；
Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息；
Consistent（一致）：按照一致的格式书写全部缺陷报告。
17、Beta测试与Alpha测试有什么区别？
参考答案：Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场
Alpha testing (α测试),是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试
18、软件的评审一般