1、软件测试分为黑盒和白盒，分别适合什么情况？
软件测试方法一般分为两种：白盒测试与黑盒测试。
白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试。它着重于程序的内部结构及算法，通常不关心功能与性能指标。
黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试。它实际上是站在最终用户的立场，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。
2、一套完整的测试应该由哪些阶段组成？
可行性分析、需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试、验收测试。
3、测试用例通常包括那些内容？
不同结构的用例包括的不一样。版本、编号、项目、设计人员、设计日期、输入、预期输出……
软件测试用例的基本要素包括：测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。
用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。
重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，一般而言，是5级划分。
对面试经验、软件、接口、自动化测试感兴趣可以175317069，群内会有不定期的免费资料链接发放。如果你有好的学习资料可以私聊发我，我会注明出处之后分享给大家。
测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。
预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。
4、您是否了解以往所工作的企业的软件开发过程？如果了解，请试述一个完整的开发过程需要完成哪些工作？分别由哪些不同角色来完成这些工作？您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？
开发过程：需求调研（需求人员）、需求分析（需求人员）、概要设计（设计人员）、详细设计(设计人员)、编码（开发人员）。
测试过程：需求评审、系统测试设计、概要设计评审、集成测试设计、详细设计评审、单元测试设计、测试执行。
测试工作的整个过程都做过，擅长做测试设计。
过程决定质量，软件的过程改进正是为了提高软件的质量，将过往的种种经验和教训积累起来。
5、在您所经历的测试活动中，参与人员有哪些？您所担任的角色是什么？
有项目管理员、开发管理员、系统分析员、设计员、开发员、质量管理员、测试管理员、测试设计员、测试员
担任过测试管理员、测试设计员、测试员
6、测试用例设计的原则是什么？目前主要的测试用例设计方法有哪些？
代表性：能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等.
可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果.
可再现性：即对同样的测试用例，系统的执行结果应当是相同的。
方法有：等价类、边界值、因果图、状态图、正交法、大纲法
7、面向对象的测试用例设计有几种方法？如何实现？
给类中的每个构造函数设计一组测试用例
组合类中的类变量、实例变量
组合类中的各种方法
根据前置条件和后置条件设计测试用例
根据代码设计测试用例
8、LoadRunner分为哪三个模块？请简述各模块的主要功能。
Virtual User Generator：用于录制脚步
Mercury LoadRunner Controller：用于创建、运行和监控场景
Mercury LoadRunner Analysis：用于分析测试结果
9、你对测试最大的兴趣在哪里？为什么？
最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。
曾经在网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了11，12点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1，2点我没有把握，其他点我都很有信心做好它。
刚开始进入测试行业时，对测试的认识是从网上了解到的一些资料。虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发，但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。
我觉得做测试整个过程中有2点让我觉得很有难度（有难度的东西我就越感兴趣）。
第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写（也就是测试计划或测试策略）？
如果你刚测试一个新任务时，你得花一定时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的）。而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。
第二是发现BUG的时候，这是测试人员最基本的任务，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。
还有如何发现bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。
如何描述bug，bug在什么情况下会产生？如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。
10、你的测试职业发展目标是什么？
测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经验，按如何做好测试工程师的十几点要求自己，不断的更新自己改正自己，做好测试任务。
11、您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）
测试类型有：功能测试，性能测试，界面测试。
功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。
采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
负载测试和压力测试都属于性能测试，两者可以结合进行。
通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。
压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。
而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。
设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
对面试经验、软件、接口、自动化测试感兴趣可以175317069，群内会有不定期的免费资料链接发放。如果你有好的学习资料可以私聊发我，我会注明出处之后分享给大家。
区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范，是否美观，是否安全。
做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试。
12、试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
软件的黑盒测试意味着测试要在软件的接口处进行。
这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。
黑盒测试主要是为了发现以下几类错误：
1、是否有不正确或遗漏的功能？
2、在接口上，输入是否能正确的接受？能否输出正确的结果？
3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
4、性能上是否能够满足要求？
5、是否有初始化或终止性错误？
软件的白盒测试是对软件的过程性细节做细致的检查。
这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。
白盒测试主要是想对程序模块进行如下检查：
1、对程序模块的所有独立的执行路径至少测试一遍。
2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
3、在循环的边界和运行的界限内执行循环体。
4、测试内部数据结构的有效性，等等。
单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
集成测试（也叫组装测试、联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。
系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）
系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，即软件的功能和性能如同用户所合理期待的那样。
13、当开发人员说不是BUG时，你如何应付？
开发人员说不是bug，有2种情况。
一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。
二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来，跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。
有些不是bug，我也只是以建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。
14、为什么要在一个团队中开展软件测试工作？
因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。
在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。
15、如果有机会转成开发人员，你会去做开发工作吗？
如果公司确实需要我可以从事开发，但我还是喜欢做测试，我认为我更适合做测试。
16、软件测试分哪些阶段？各阶段的含义？
分为单元测试、集成测试、确认测试、系统测试、验收测试。
单元测试是最小单位的测试，测试独立模块。
集成测试主要测试模块之间的接口是否正常。
确认测试类似于冒烟测试通常在大规模系统测试之前验证版本主要功能是否实现，版本的稳定性是否可以进入系统测试。
系统测试是全面测试验证系统是否满足用户需求包括功能、性能、兼容性等等。
验收测试是用户参与的测试。
17、一份测试计划应该包括哪些内容？
背景、项目简介、目的、测试范围、测试策略、人员分工、资源要求、进度计划、参考文档、常用术语、提交文档、风险分析。
18、针对于软件的行业背景，你如何理解软件的业务？
阅读用户手册了解软件的功能和操作流程；
看一些业务的专业书籍补充业务知识；
如果有用户实际的数据，可以拿实际的数据进行参考；
参考以前的用例和BUG报告；
在使用软件的过程中多思考，多与产品经理交流。
19、测试用例应包括哪些内容？
编号、模块名称、编写人、日期、操作说明、输入数据、预期结果等。
20、如何定位测试用例的作用？
组织性：编写、组织性、功能覆盖、重复性、跟踪、测试确认
21、什么是兼容性测试？请举例说明如何利用兼容性测试列表进行测试。
主要验证软件产品在不同版本之间的兼容性。包括向下兼容和交错兼容，向下兼容是测试软件新版本保留它早期版本功能的情况，交错兼容是验证共同存在的两个相关但不相同的产品之间的兼容性。
21、对某软件进行测试，发现在WIN98上运行得很慢，怎么判别是该软件存在问题还是其软硬件运行环境存在问题？
看软件的运行环境要求。如果符合要求则是程序存在问题，若不符合要求则是硬件系统存在问题。
22、什么是等价类划分法和边界值分析法？需求测试的注意事项有哪些？
是否使用了公司的模板；
文档内容是否符合规范；
所有的需求是分级是否清析适当；
所有的需求是否具有一致性；
需求是否可行（即，该需求组合有解决方案）；
需求可否用己知的约束来实现；
需求是否足够（即，可以把它送到一个规范的开发组织，并有一个生产出所需要产品的合理的可能性）；
所有的其它需求是交叉引用是否正确；
用户描述是否清楚；
是否用客户的语言来描述需求；
每个需求描述是否清楚没有岐义，可以移交给一个独立的组去实现时也能理解；
是否所有的需求都是可验证的；
是否每条需求都具有独立性，即使发生了变化也不会影响其它需求；
性能指标是否明确；
非功能性需求是否得到充分表现；
是否完整列出适用的标准或协议；
标准和协议之间是否存在冲突。
23、请简述一下缺陷的生命周期。
提交->分配->处理->返测->关闭（返测和处理为循环