软件测试面试常见问题（一）
（1）
一、测试
1、你对软件测试的理解。
软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。
2、你觉得你哪些方面适合做软件测试？你的优势和劣势在哪儿？
首先，应对软件测试感兴趣和对自己有自信，善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生。。。。。
。。。。。
3、测试用例的基本元素？例举测试用例设计方法（至少5种）
测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。
测试用例组成元素
1.用例ID；
2.用例名称；
3.测试目的；
4.测试级别；
5.参考信息；
6.测试环境；
7.前提条件；
8.测试步骤；
9.预期结果；
10.设计人员。
每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果(含判断标准)、出口准则、注释等。
测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。
早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。
测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约(或设计规格说明书)，根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。
软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。
测试用例设计方法：
3.1. 等价类划分方法
3.2. 边界值分析方法
3.3. 错误推测方法
3.4. 因果图方法
3.5. 判定表驱动分析方法
3.6. 正交实验设计方法
3.7. 功能图分析方法
3.8. 场景设计方发
附：
测试用例设计原则
1.测试用例的代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
2.测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
3.测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。
4、你使用过哪些测试工具？如果有，说明工具的工作流程。
这个得自由发挥了！
5、你对5年内的职业规划？
1～2年，测试技能：熟悉整个测试过程及产品业务领域，学习和掌握自动化工具，学习测试自动化编程技术；开发和执行测试脚本，承担系统测试实施任务；掌握编程语言、操作系统、网络与数据库方面的技能。
3～4年，测试过程：深入了解测试过程，掌握测试过程设计及改进，参与软件工作产品的同行评审；进一步了解产品业务领域，改进测试自动化编程技术；能指导初级测试工程师；加强编程语言、操作系统、网络与数据库方面的技能。
4～5年，测试组织工作：管理1～3名测试工程师，担任任务估算、管理及进度控制；进一步培养在软件项目管理及支持工具方面的技能。
5～6年，技术管理：管理4～8名测试工程师，提高任务估算、管理及进度控制能力，完成测试规划并制定测试计划；研究测试的技术手段，保持使用项目管理及支持工具的技能；用大量时间为其他测试工程师提供技术及过程方面的指导；开始与客户打交道并做演示推介。
6～12年，测试管理：管理8名以上测试工程师，负责一个或多个项目的测试工作；与客户打交道并做演示推介；保持使用项目管理及支持工具的技能。
6、用你熟悉的语言编写一段程序 ，输入三个数，x,y,z, 使它们从大到小输出。
参考之前博文 "排序"
1、什么是左连接和右连接？（可举例说明)
查看如下语句： SELECT ename , dname FROM Emp, Dept WHERE Emp.Deptno(+) = Dept.Deptno 也可以写成： SELECT ename , dname FROM Emp RIGHT JOIN Dept ON Emp.Deptno = Dept.Deptno 此SQL文使用了右连接，即“(+)”所在位置的另一侧为连接的方向，右连接说明等号右侧的所有记录均会被显示，无论其在左侧是否得到匹配，也就是说上例中无论会不会出现某个部门没有一个员工的情况，这个部门的名字都会在查询结果中出现。 反之： 查看如下语句： SELECT ename , dname FROM Emp, Dept WHERE Emp.Deptno = Dept.Deptno(+) 也可以写成： SELECT ename , dname FROM Emp LEFT JOIN Dept ON Emp.Deptno = Dept.Deptno 则是左连接，无论这个员工有没有一个能在Department表中得到匹配的部门号，这个员工的记录都会被显示
（2）
1. 什么是软件测试？测试的根本目的是什么？
软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。
测试的根本目的就是为了发现尽可能多的缺陷；这里的缺陷是一种泛称，它可以指功能的错误，也可以指性能低下，易用性差等等。因此，测试是一种“破坏性”行为。测试的目的是发现程序中的错误,是为了证明程序有错,而不是证明程序无错。即软件测试是为了“证伪”而非“证真”。把证明程序无错当作测试目的不仅是不正确的, 完全做不到的，而且对做好测试没有任何益处，甚至是十分有害的。软件测试要设法使软件发生故障，暴露软件错误, 能够发现错误的测试是成功的测试，否则是失败的测试。
2．测试用例包含哪两个部分？
测试用例文档由简介和测试用例两部分组成。
3．测试应遵循什么原则？
(1)所有的测试都应追溯到用户需求。 软件测试的目标在于揭示错误。从用户角度来看，最严重的错误是那些导致程序无法满足需求的错误。 (2)应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。 应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。 (3)pareto原则：测试发现的错误中80%很可能起源于20%的模块中。 当某个功能出问题，其对用户的影响有多大?然后根据风险大小确定测试的优先级。优先级高的测试，优先得到执行，一般来讲，针对用户最常用的20%功能(优先级高)的测试会得到完全执行，而低优先级的测试(另外用户不经常用的80%功能)就不是必要的，如果时间或经费不够，就暂时不做或少做。 (4)完全测试是不可能的，测试需要终止。 测试无法显示软件潜在的缺陷，“测试只能证明软件存在错误而不能证明软件没有错误”。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。在测试中不可能运行路径的每一种组合。然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。 (5)应由独立的第三方来构造测试。 第三方测试最大的特点在于它的专业性、独立性、客观性和公正性。对于软件开发商来说，经过第三方测试机构的测试，不仅可以通过专业化的测试手段发现软件错误，帮助开发商提升软件的品质，而且可以对软件有一个客观、科学的评价，有助于开发商认清自己产品的定位。对于行业主管部门以及软件使用者来说，由于第三方测试机构独立公正的地位，可以对被测试的软件有一个客观公正的评价，帮助用户选择合适、优秀的软件产品。 (6)充分注意测试中的群集现象。 测试后程序残存的错误数目与该程序中已发现的错误数目或检错率成正比。不要在某个程序段中找到几个错误就误认为该程序段就没有错误而不再测试，相反应该对错误群集的程序段进行重点测试。 (7)尽量避免测试的随意性。 测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的配置方式，跟踪规则，调试规则，以及回归测试的规定等以及评价标准。 (8)兼顾合理的输入和不合理的输入数据。 (9)程序修改后要回归测试 修改程序后，应该重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 (10)应长期保留测试用例，直至系统废弃。 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护等提供方便。1.应当把“尽早和不断地测试”作为 开发者的座右铭。
2.程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。
3.设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
4.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
5.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
6.制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
7.妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。
8. 回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。4．测试有哪些方法？
软件的测试方法很多，不同的出发点得到不同的测试方法。有：
静态分析时，不执行程序，可对需求分析说明书、软件设计说明书、源程序做结构检查、流图分析、符号执行来分析软件可能导致的异常情况，找出软件错误。从测试过程来分：静态分析法、动态测试法；
结构检查是手工分析技术，对需求说明、程序设计、编码、测试工作进行评议，虚拟地（模拟）执行程序，在评议中发现和检查错误；
流图分析是通过分析流程图、代码结构来检查程序错误，便于进行编码分析和测试结果分析；
符号执行是定义符号化数据，为程序的每条路径给出符号表达式，对特定路径输入符号，经处理输出符号，判断程序的行为是否错误，这种方法复杂，易出错，较少使用。
灰盒法是白盒法和黑盒法相结合使用的方法，仅对重点路径和程序段用白盒法测试，大部分用黑盒法进行测试。
动态测试是直接执行程序进行测试，包括功能测试、接口测试和结构测试，观察程序的行为，记录执行的结果，从执行结果来分析程序可能出现的错误；
有些人设想，不管使用那种测试方法，只要对每一种可能发生的情况都进行测试，能正确通过，就可以得到完全正确的程序。
包含所有可能情况的测试称为穷尽测试，实际上，通常不可能做到穷尽测试。因为各种输入数据的排列组合情况往往多到无法实际测试完成的程度。如用黑盒法测试三个整数型的输入数据，如果每个整数是16位二进制数，则输入数据有
216×216×216=248≈2.8×1014种排列组合。
如果每测试一次需要1毫秒，测试完毕这些排列组合的各种情况需要一万年，另外还需测试不合法的输入情况，实际上不可能穷尽所有组合情况。因此，一般的软件测试是有限测试。
Alpha(α)测试：通用软件产品为了征集用户的意见，在开发者的场所，由用户进行的测试，记录用户发现的错误和问题。
Beta(β)测试：在一个或多个用户自己的场所，由最终用户进行，并记录在测试中遇到的所有问题和想法。
重要的通用软件产品，大多经过α和β测试。
软件测试和软件项目同时开始，从产品的需求分析审查到最后的验收测试，直至软件发布。
软件测试的过程是由一系列的不同测试阶段所组成，这些软件测试的步骤分为：需求分析审查、设计审查、单元测试、集成测试（组装测试）、功能测试、系统测试、验收测试、回归测试（维护）等。详细内容见下表。
|
阶 段
|
输入和要求
|
输出
|
|
需求分析审查
Requirements Review
|
市场/产品需求定义、分析文档和相关技术文档
要求：需求定义要准确、完整和一致,真正理解客户的需求
|
需求定义中问题列表,批准的需求分析文档
测试计划书的起草
|
|
设计审查
Design Review
|
产品规格设计说明、系统架构和技术设计文档、测试计划和测试用例
要求：系统结构的合理性、处理过程的正确性、数据库的规范化、模块的独立性等
清楚定义测试计划的策略、范围、资源和风险，测试用例的有效性和完备性
|
设计问题列表、批准的各类设计文档、系统和功能的测试计划和测试用例
测试环境的准备
|
|
单元测试
Unit Testing
|
源程序、编程规范、产品规格设计说明书和详细的程序设计文档
要求：遵守规范、模块的高内聚性、功能实现的一致性和正确性
|
缺陷报告、跟踪报告；完善的测试用例、测试计划
对系统功能及其实现等了解清楚
|
|
集成测试
Integration Testing
|
通过单元测试的模块或组件、编程规范、集成测试规格说明和程序设计文档、系统设计文档
要求：接口定义清楚且正确、模块或组件一起工作正常、能集成为完整的系统
|
缺陷报告、跟踪报告；完善的测试用例、测试计划；集成测试分析报告；
集成后的系统
|
|
功能验证
Functionality Testing
|
代码软件包（含文档）,功能详细设计说明书; 测试计划和用例
要求：模块集成 功能的正确性、适用性
|
缺陷报告、代码完成状态报告、功能验证测试报告
|
|
系统测试
System Testing
|
修改后的软件包、测试环境、系统测试用例和测试计划
要求：系统能正常地、有效的运行，包括性能、可靠性、安全性、兼容性等。
|
缺陷报告、系统性能分析报告、缺陷状态报告、阶段性测试报告
|
|
验收测试
Acceptance Testing
|
产品规格设计说明、预发布的软件包、确认测试用例
要求：向用户表明系统能够按照预定要求那样工作，使系统最终可以正式发布或向用户提供服务。用户要参与验收测试，包括α测试(内部用户测试)、β测试(外部用户测试)
|
用户验收报告、缺陷报告审查、版本审查
最终测试报告
|
|
版本发布
Release
|
软件发布包、软件发布检查表（清单）
|
当前版本已知问题的清单、版本发布报告
|
|
维护
Maintance
|
变更的需求、修改的软件包、测试用例和计划
要求：新的或增强的功能正常、原有的功能正常，不能出现回归缺陷
|
缺陷报告、更改跟踪报告、测试报告
|
测试部门独立于开发部门。
这种模式可能源于传统制造行业的QC和生产部门的分开。其目的是为了保证测试过程和测试结果的客观性和有效性。这种模式相当于把测试和开发分成两个泾渭分明的活动，并没有过多的考虑两种活动之间的互为补益。在这种模式下，很可能演变成测试和开发之间的对立，或者增加测试和开发之间的沟通成本。
边测试，边开发。
这是XP的轻量级开发过程所倡导的，现在的测试驱动开发理论就是符合了这种模式。采用先设计测试，再进行开发，当开发的软件通过了所有的测试，软件就完成了。这种方式其实并没有规避自己测试自己代码所产生的局限性问题，只是将思维的顺序作了些改变（一般的四位顺序：先开发，后测试），降低了思维定式对软件开发产生缺陷的影响。
测试部门属于研发中心，但独立于项目组。
这种模式保证了测试与项目组之间的最终目标的一致性（高质量的软件产品），能有效的降低沟通成本，又能保证测试人员有一定的独立性，不会过分的受产品经理的控制，避免测试失效现象产生。但在这种情况下，相比两个部门独立，测试的结果有可能不会被项目组所重视，需要频繁的进行协调，才能及时处理缺陷。
6．分别用逻辑覆盖的几种方式设计某一程序片段，写出测试用例。
自由发挥！
7．解释下列术语：单元测试；集成测试；确认测试；系统测试；调试；
单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图〕组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。
确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是确认测试的任务，即软件的功能和性能如同用户所合理期待的那样。
系统测试，英文是System Testing。是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。系统测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。对象不仅仅包括需测试的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。
调试：编好程序后，用各种手段进行查错和排错的过程。作为程序的正确性不仅仅表现在正常功能的完成上，更重要的是对意外情况的正确处理。从心理学的角度考虑，开发人员和调试人员不应该是同一个人。
8．测试与调试有什么区别？测试的策略有哪些？调试有哪几种技术？
软件测试：发现错误（发现自己生病了）
软件调试：诊断并改正错误（去看医生）
->错误定位（医生诊断是胃有病）
->纠正错误（医生说要打针）
->回归测试（医生说还要复诊）
测试的策略：
1.用例的执行策略。
测试用例的执行测试，主要受2个因素影响，1.项目的性质，2.项目资源（时间资源、人员资源）。项目的性质不同，资源投入不同，策略也会有所区别。具体来讲，就是根据项目的性质，时间周期的长短，投入人力资源的多少，以及人员情况（新人、老人、熟悉业务的、不熟悉业务的等）等因素，制定冒烟测试、第一轮、第二轮、第三轮、合并主干测试、预发布测试、正式上线验收测试，由谁执行哪些测试用例。在3轮测试中，每一轮都需要执行测试用例。但是很多项目由于项目时间紧，无法保证3轮测试每一轮都可以完整执行全部的测试用例。需要提前规划好每轮测试的用例执行策略。
比如某项目，主要是页面改动，功能改动不大，而时间又很紧，可以指定这样的用例执行策略：冒烟测试：执行P1级测试用例，保证主流程跑通。第一轮：执行全部测试用例，以免有我们不知道的功能改动点或者影响点。第二轮，执行P1+P2+P3的测试用例，以及第一轮中field的测试用例。该项目为界面改版的项目，对于边界值啊、必填项啊这类细节点影响是不多的，且在第一轮中也已执行一遍，在第二轮中仅跑一遍流程，如果时间过紧，甚至可以只执行P1+P2，一定保证足够的时间可以进行随机发散测试。第三轮测试，主要是回归测试，如果时间充足，最好执行全部测试用例。但如果时间无法保证，可以执行P1+P2+P3，以及前2轮中field用例，用例所在模块的用例。合并主干回归测试，P1+P2的测试用例。我们每一轮都会把流程规则的用例走到，确保不会有严重问题。预发布测试，由于数据为线上真实数据，会对线上有影响，需要规划出是否需要制定出一套独立的适合线上测试的用例。线上验收测试，基本和预发布测试同理，测试的范围可能会更小一些。
2.交叉测试策略。
通常情况，项目会投入至少2名测试人员，测试人员会重点负责一部分功能。为了减小视觉盲点，会进行交叉测试。那么在什么阶段进行交叉测试？如何进行交叉测试？也是测试策略的一部分。比如，我们可以选择，在第二轮开始交叉测试。如何进行交叉测试呢？测试人员会在制定测试计划时变进行了任务分工，之后，测试人员会最关注自己相关功能的业务，对其他人负责的功能，了解的会少一些，在交叉测试时，如何使不了解这个业务的同学，能够很快熟悉业务呢？其实这个问题并不难，刚好可以用上面用例执行测试策略的例子说明。在第二轮测试时，我们还是需要执行流程性测试用例的，在第一轮测试用例执行后，用例均已被梳理一次，哪些用例需要改动，已经清晰。负责这部分测试用例的同学在执行用例时，及时确认是bug还是用例问题，及时修改用例，以及测试用例的补充。这样，第二轮测试时，便可以由其他不熟悉业务的同学来执行用例，熟悉流程和业务规则。
3.兼容性测试策略。
兼容性测试，一般都会有自己的测试规范，哪些操作系统、浏览器、分辨率等是支持的，不同操作系统、浏览器需要支持什么程度。我们需要在制定测试策略时，规定好，对哪些浏览器执行哪些测试用例，以及，什么阶段执行兼容性测试，谁负责哪个浏览器的兼容性测试。例：在第二轮测试阶段，由A执行IE6的P1+P2+P3+页面展现+js相关的测试用例。
此外，为了保证项目高效进行，可以在制定测试策略时考虑，兼容性测试是否可和交叉测试并行进行。这样，一方面便于效率的提高，减少后期冗余测试，一方面又可以保证测试完全，使后期的测试是有计划有条理的进行。
4.bug复验收策略。
上线前，我们需要对bug进行复测。可以将bug复测的工作写入到测试策略中，指点新人。例如：10月29号（第三轮执行完测试用例后）bug提交人对closedbug进行复测，项目测试负责人发送当前later bug致项目组。
5.回归测试策略。
回归测试：第三轮测试及主干回归测试。两者均为回归测试，但是侧重点不同。第三轮测试的回归测试，主要针对程序代码是否还有bug；主干回归测试，验证合并主干后，是否对该应用或相关应用产生了影响。我们这里主要说的是合并主干的测试策略，需要考虑项目的回归任务分配，该应用的回归任务分配，可能影响到的其他应用回归任务分配，以及打分支阶段，该应用其他日常的回归任务分配。
测试策略还会涉及很多其他方面，这些测试工作在实际测试过程中都会涉及到
调试技术： 调试的任务就是根据测试时所发现的错误，找出原因和具体的位置，进行改正。工作主要由程序开发人员来进行，谁开发的程序就由谁来进行调试。 目前常用的调试方法有如下几种： · 试探法。调试人员分析错误的症状，猜测问题的所在位置，利用在程序中输出语句，分析寄存器、存储器的内容等手段来获得错误的线索，一步步地试探分析出错误所在。这种方法效率很低，适合于结构比较简单的程序。 · 回溯法。调试人员从发现错误症状的位置开始，人工沿着程序的控制流程往跟踪代码，直到找出错误根源为止。这种方法适合于小型程序，对于大规模程序于其需要回溯的路径太多而变得不可操作。 · 对分查找法。这种方法主要用来缩小错误的范围，如果已经知道程序中的变量若干位置的正确取值，可以在这些位置上给这些变量以正确值，观察程序运行输出结果，如果没有发现问题，则说明从赋予变量一个正确值开始到输出结果的程序没有出错，问题可能在除此之外的程序中，否则错误就在所考察的这窨程序中，对含有错误的程序段再使用这种方法，直到把故障范围缩小到比较牵诊断为止。 · 归纳法。归纳法就是从测试所暴露的问题出发，收集所有正确或不正确的数分析它们之间的关系，提出假象的错误原因，’用这些数据来证明或反驳，从而翟错误所在。 · 演绎法。根据测试结果，列出所有可能的错误原因。分析已有的数据，排除．能和彼此矛盾韵原因。对余下的原因，选择可能性最大的，利用已有的数据完该假设，使假设更具体。用假设来解释所有的原始测试结果，如果能解释这一，则假设得以证实，也就找出错误；否则，要么是假设不完备或不成立，要么有问题。
9．调试有哪几种策略？
调试的策略有：试探法，回溯法，对分查找法、归纳法、演绎法。可根据个人经验和具体情况灵活应用。
10．软件质量一般从哪几方面进行评价？
11.如何加强软件质量控制？
（3）
软件测试的方法都有哪些？
软件的测试方法很多，不同的出发点得到不同的测试方法。有：
静态分析时，不执行程序，可对需求分析说明书、软件设计说明书、源程序做结构检查、流图分析、符号执行来分析软件可能导致的异常情况，找出软件错误。从测试过程来分：静态分析法、动态测试法；
结构检查是手工分析技术，对需求说明、程序设计、编码、测试工作进行评议，虚拟地（模拟）执行程序，在评议中发现和检查错误；
流图分析是通过分析流程图、代码结构来检查程序错误，便于进行编码分析和测试结果分析；
符号执行是定义符号化数据，为程序的每条路径给出符号表达式，对特定路径输入符号，经处理输出符号，判断程序的行为是否错误，这种方法复杂，易出错，较少使用。
灰盒法是白盒法和黑盒法相结合使用的方法，仅对重点路径和程序段用白盒法测试，大部分用黑盒法进行测试。
动态测试是直接执行程序进行测试，包括功能测试、接口测试和结构测试，观察程序的行为，记录执行的结果，从执行结果来分析程序可能出现的错误；
有些人设想，不管使用那种测试方法，只要对每一种可能发生的情况都进行测试，能正确通过，就可以得到完全正确的程序。
包含所有可能情况的测试称为穷尽测试，实际上，通常不可能做到穷尽测试。因为各种输入数据的排列组合情况往往多到无法实际测试完成的程度。如用黑盒法测试三个整数型的输入数据，如果每个整数是16位二进制数，则输入数据有
216×216×216=248≈2.8×1014种排列组合。
如果每测试一次需要1毫秒，测试完毕这些排列组合的各种情况需要一万年，另外还需测试不合法的输入情况，实际上不可能穷尽所有组合情况。因此，一般的软件测试是有限测试。
Alpha(α)测试：通用软件产品为了征集用户的意见，在开发者的场所，由用户进行的测试，记录用户发现的错误和问题。
Beta(β)测试：在一个或多个用户自己的场所，由最终用户进行，并记录在测试中遇到的所有问题和想法。
重要的通用软件产品，大多经过α和β测试。
你是如何理解软件测试的原则的？
（1）将软件测试贯穿于软件开发的各个阶段中，在开发过程中尽早地发现和预防错误，杜绝隐患，提高软件质量；在一个程序段中，还存在着尚未发现的错误概率与已发现的错误数正相关。
软件测试的一般步骤是什么？
（1）单元测试（也称模块测试）：针对软件设计的基本单元——程序模块，进行正确性检验的测试工作。目的在于发现各个模块内部可能存在的各种差错。单元测试需要从程序内部结构出发设计测试用例，多个模块可以平行、独立地进行测试；
（2）集成测试（也称组装测试，联合测试）：在单元测试的基础上，将所有模块按设计要求集成在一起进行测试，以检验总体设计中各模块间的接口设计问题、模块之间的相互影响、上层模块存在的各种差错及全局数据结构对系统的影响等方面。
（3）确认测试（也称验收测试，有效性测试）：主要检验软件的功能和性能是否与需求说明书中的规定一致。
（4）系统测试：将软件系统作为一个元素，放入整个实际的计算机系统中，与计算机硬件、其他软件、使用人员等系统元素结合在一起，在实际使用环境下进行综合全面的测试。
软件测试的生命周期是什么？
软件测试的模型有哪些？（*）你所做过的项目采用的是哪一种模型？
（*）你参与过哪个项目的测试？请说明你所做项目的主要功能？并阐述你在整个项目中的分工与工作职责？
什么是二八定理？
测试用例的要素有哪些？你认为什么样的测试用例才算是一条标准的测试用例（合理的回答是：表述清楚、没有歧义、简单易懂），请谈谈你的看法。
假如你是测试经理，你如何组织好你所在的测试团队进行有效的工作？
答：
1、加强团队建设：创造和谐团队工作氛围
2、交叉业务培训：利用团队每个员工的技术及业务特长定期组织团队员工进行业务与技术能力交叉学习，规避员工流失导致项目风险。
如果你测出一个BUG，和开发人员意见冲突时候，你该如何协调好自己的工作？
如何避免在项目中出现各种项目风险？（谈谈你是如何规避项目实施中存在的各种潜在风险）
举个例子说明什么样的情况下进行性能测试？
答：可拿百度进行讲述：一般在系统稳定、页面已经美观没有出现页面松动的情况下才会进入从性能测试
是不是每条测试用例都适合自动化测试？为什么？
答：不是，测试用例在实际应用中应用较广泛的、并发用户数目较多的情况下比较适合跑自动化测试
(7)
1、阶段评审与同行评审的区别？
参考答案：
同行评审目的：发现小规模工作产品的错误，只要是找错误；
阶段评审目的：评审模块 阶段作品的正确性 可行性 及完整性
同行评审人数：3-7人 人员必须经过同行评审会议的培训，由SQA指导
阶段评审人数：5人左右 评审人必须是专家 具有系统评审资格
同行评审内容：内容小 一般文档 < 40页， 代码 < 500行
阶段评审内容： 内容多，主要看重点
同行评审时间：一小部分工作产品完成
阶段评审时间： 通常是设置在关键路径的时间点上
2、什么是软件测试及其目的？
参考答案：
软件测试是使用人工或自动化手段来运行或测定某个系统的过程。其目的是：在于检验它是否能满足规定的需求或是弄清楚预期结果与实际结果之间的差别。
3、简述集成测试的过程？
参考答案：
集成测试流程：
在完成软件的概要设计后，即开始制定集成测试计划-》设计集成测试用例和测试过程-》实施集成测试，设计所需驱动和桩-》执行集成测试，记录测试结果-》评估集成测试，根据测试结果评估此次测试，生成评估报告文档。(驱动或桩函数是做单元测试时要用到的。驱动函数是所测4函数的主程序，它接收测试数据，并把数据传送给所测试单元，最后再输出实测结果。当被测单元能完成相关功能时，也可以不要驱动单元。桩，是用来代替所测试单元调用的子单元。)
4、白盒测试有哪几种方法？
参考答案：代码审查，语句覆盖，判定覆盖，条件覆盖，组合覆盖，基本路径，形式化方法，符号执行
5、简述测试目标有哪些类型？
参考答案：
功能测试，负载测试，性能测试，安全性测试，恢复测试，安装测试，兼容性测试，可用性测试，可靠性测试，国际化测试，本地化测试。
6、怎么样做好文档测试？
参考答案：
文档的测试主要采用静态测试即走查的方法，可以依据的是同行评审，列出一个检查表，然后大家一起坐下来对着被测试的文档进行阅读排错。通常文档都很长，而一般的建议是一次同行评审的时间不能超过两个小时，因此可以对被测试文档执行测试时，列个计划，将总的文档分解，按照计划多次对被测试的文档进行走查。
7、测试结束的标准是什么？
参考答案：
从项目周期看：
1、超出了所分配的测试时间；
2、用尽了分配的测试资源；
3、到达了某一个固定的里程碑（如合同规定的交付日期）。
从测试角度看：
1、测试需求覆盖率；
2、测试代码覆盖率；
3、测试用例度量；
4、缺陷检查度量
8、Alpha 测试与Beta测试的区别？
参考答案：
Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应该在Alpha测试前准备好。
Beta测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。因而，Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产品发行的人员来管理。
9、系统测试计划是否需要同行审批，为什么？
参考答案：
需要，系统测试计划属于项目阶段性关键文档，因此需要评审。
10、比较负载测试，容量测试和强度测试的区别？
参考答案：
负载测试：在一定的工作负荷下，系统的负荷及响应时间。
强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。
容量测试：容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。