软件测试是什么？
软件测试是执行程序以发现错误的过程。另一种说法是，软件测试是精心设计一组基于软件开发各个阶段的规范和程序内部结构的测试案例(即输入数据和预期的输出结果)，并利用它们来运行程序，找出程序中的错误。
软件测试的目的？
软件测试旨在用最少的人力、物力和时间找出软件中可能存在的各种错误和缺陷，通过修正各种错误和缺陷来提高软件质量，避免由于软件潜在的缺陷和错误造成的隐患而导致的商业风险。
要求文档测试：
在技术上，主要测试需求是否存在逻辑矛盾，需求能否在技术上实现；
方案文件测试：
试验设计是否完全符合要求，设计是否合理。
α测试：
Alpha测试(α)是由用户在开发环境中进行的测试，或者是公司内部用户在模拟实际运行环境中进行的受控测试，而 Alpha测试不能由程序员或测试人员来完成。Alpha测试发现的错误，可以在测试现场立即反馈给开发者，由开发人员及时分析和处理。旨在评估软件产品的功能、可用性、可靠性、性能和支持。特别关注产品界面与特色。Alpha测试可以在软件产品编码结束后开始，或者在模块(子系统)测试完成之后开始，或者在确认测试期间产品达到一定的稳定性和可靠性之后开始。在 Alpha测试之前，相关的手册(草案)等应准备就绪。
β测试：
Beta测试(beta test)是由多个软件用户在一个或多个用户实际使用环境中进行的测试。开发人员一般不在测试现场，而测试不能由程序员和测试人员来做。因此， Beta测试就是一种开发人员不能控制的环境下的现场测试。通过 Beta测试，记录用户遇到的所有问题，包括实际问题和主管发现的问题，定期向开发人员报告，开发人员在汇总用户的报告后，进行修改，最终将软件产品交付给所有用户使用。Beta测试的重点是对产品的支持，包括文档、客户培训以及支持产品的生产能力。Beta测试只有在 Alpha达到一定的可靠性之后才能开始测试。因为 Beta测试的主要目的是测试支持性， Beta测试应该尽可能由负责产品发布的人来管理。
驱动模块：
在大多数情况下，驱动模块称为“主程序”，它接收测试数据，并将这些数据传送给测试模块。在对一个功能单元进行测试时，被测单元本身不能独立运行，需要为其传输数据，为此写驱动
驱动器模块主要完成下列工作：
接收测试输入；判断输入；将输入输入到被测单元，驱动被测单元执行；接收被测单元的执行结果，并判断结果；将判断结果作为用例的执行结果输出测试报告。
桩模块
例如，在函数 A做单元测试时，被测单元下也包含了函数 B，为了更好地找错、找错，就要把函数 B写成桩，模拟函数 B的功能，保证它的正确。
白盒测试
白盒测试(White-boxTesting，也叫逻辑驱动测试，结构测试)是了解产品内部的工作过程，通过测试可以检测产品内部动作是否按照规范的规定正常进行，按照程序内部的结构测试程序，检验程序中每一条通路是否都可以按预定要求进行，而主要是软件验证。
支持开发语言：白盒测试工具是对源代码的测试，主要内容包括词法和语法分析、静态错误分析、动态检测等。当前主要支持的测试工具开发语言有：标准 C、 C++、 Visual C++、 Java、 VisualJ++等等。
静态测试
对软件进行动态的测试，如检查文档、阅读代码等等，叫做静态测试，用程序测试软件来测试。在动态测试中，通常采用白盒测试和黑盒测试从不同的角度设计测试用例，并寻找软件代码中的错误。
回归测试
回归测试的目的是在程序有任何改变时，保证原有功能正常的一种测试策略和方法。
可以肯定的是，测试员在测试程序时发现 bug，然后返回给程序员修改，然后由程序员发布新的包或新的软件补丁包给我们测试，我们将重新对程序进行测试，以确保程序在修复了先前的 bug的情况下，仍然可以正常工作，并且不会产生新的错误。一般而言，不需要全面的测试，而是根据修改后的情况进行有效测试。
找工作前先去找工作！快速下载拿 offer！
有哪些方法可以进行白盒测试？
白盒子测试又称结构测试或逻辑驱动测试，是了解产品内部工作过程，通过测试可以检测产品内部动作是否按照规范规范的规定进行，并按照程序内部的结构测试程序，检验程序中的每条路径是否都能按预定要求正确工作，而白盒测试主要方法有逻辑驱动、基路测试等。白盒子的方法能够全面理解程序的内部逻辑结构，测试所有逻辑路径。白盒子的方法是穷尽路径测试。
怎样划分软件缺陷的等级？
1.严重错误，可能导致本模块及其他相关模块出现异常、死机等问题；
2.严重错误，问题局限于此模块，导致模块功能失效或
3.一般异常错误，模块功能部分失效；
3.建议问题，由问题提出人对测试对象的改进意见；
若能完成完美的黑盒测试，是否还需要白盒测试？(白盒子和黑盒子的区别)
(请注意，任何工程产品)可采用下列两种方法之一来测试。
黑盒子测试：已知产品的功能设计规范，可以进行测试，证明每一个功能是否符合要求。
白盒子测试：已知产品的内部工作流程，可通过测试验证每个内部操作是否符合设计规范要求，所有内部成分是否经过检验。
软件黑盒测试意味着测试是在软件界面上进行的。该方法将测试对象视为一个黑盒，测试人员完全忽略了程序内部的逻辑结构和内部特征，而仅仅根据要求规范来检查程序的功能是否符合其功能描述。所以黑盒子测试又称功能测试或数据驱动测试。黑盒子测试通常会发现以下错误类型：
界面上是否有不正确或遗漏的功能，输入能否被正确接受？能得到正确的结果吗？存在数据结构错误或外部信息(如数据文件)存取错误吗？其性能能否达到要求？存在初始化或终止性错误吗？
对软件进行白盒测试就是对软件的过程细节进行仔细的检查。该方法将测试对象视为一个打开的盒子，它允许测试人员利用程序内部的逻辑结构和相关信息，设计或选择测试用例，以测试程序所有逻辑路径。检查不同点上的程序状态，判断实际状态是否与预期状态一致。所以白盒测试也叫结构测试或者逻辑驱动测试。白盒子测试主要对程序模块进行以下检查：
至少测试一次所有程序模块的独立执行路径。在逻辑判断中，能够至少对“真”和“假”两种情况进行测量。按循环边界和运行边界执行循环循环。检查内部数据结构的有效性等。
上述事实表明，软件测试存在着一种致命的缺陷，即不完全、不彻底。因为任何程序都只能进行很少(相对于大量的穷举量)的有限测试，所以在没有发现错误的情况下，就无法说程序中没有错误。
有多少阶段可以划分软件测试？简要说明每一阶段应该着重测试的地方。各阶段的意义？
大体可以分为单元测试、集成测试、系统测试、验收测试，每一阶段又分为以下五个步骤：测试计划，测试设计，用例设计，执行结果，测试报告
对每一个模块进行初始测试，以确保源代码的正确性，即单元测试，以白盒测试法为主。
接着，为了组成一个完整的软件包，集成了模块。整合测试侧重于确认和程序构建问题。以黑盒测试法为主，辅以白盒测试法。
在软件整合之后，完成系统的确认和测试。验证测试提供软件满足所有功能、性能要求的最终保证。验证测试只使用黑盒方法。
单位测试
单元测试是对软件中诸如模块、过程等基本组成部分的测试。作为软件动态测试中最基本的部分，也是最重要的一部分，旨在检验软件基本组成单元的正确性。
综合测试
整合测试是在软件系统集成过程中进行的测试，其主要目的是检查各单元之间的接口是否正确。
制度试验
系统测试就是对已经集成的软件系统进行彻底的测试，以验证软件系统的正确性和性能是否符合法规规定的要求，而要检查软件的运行和输出是否正确，这就是测试的“先知问题”。
接受试验
接受测试是为了向软件的购买者展示软件系统以满足用户的需要。其测试数据通常是系统测试数据的一部分。
回归检验
回归测试是在软件维护阶段对软件进行修改后的测试。这样做的目的是检查对软件的修改是否正确。
如何对瑕疵进行管理？
为了更好地管理缺陷，必须引入缺陷管理工具，无论是商业的还是开源的。考虑到缺陷的管理、缺陷状态的管理和缺陷分析的管理，并根据缺陷的生命周期进行管理。任何缺陷(无论是检测发现的还是读代码发现的)都必须及时、准确地提交到属于缺陷提交管理的缺陷管理工具中。在缺陷提交之后，需要及时指派给相应的开发人员，提交缺陷的人需要密切关注缺陷的状态，以便能够尽快解决缺陷。在缺陷解决后，需要对缺陷及时修复进行确认。这一目标有两个：一是让缺陷尽快解决；二是便于缺陷的分析(保证与缺陷相关的信息的准确性，例如年龄等)，这是对缺陷状态的管理。为改善开发过程和测试过程，必须对缺陷进行分析，如缺陷的类别、缺陷龄期分布等信息，这就是缺陷分析的管理。
什么是单元测试、集成测试、系统测试的重点？
单元测试是在软件开发过程中要进行的最低测试活动，在一个单元测试活动中，软件的独立单元会在与程序其他部分隔离的情况下进行测试，主要测试系统的模块，包括子程序的正确性验证等等。
整合测试又称装配测试或联合测试。根据单元测试，按照设计要求，将各模块组装成子系统或系统，进行集成测试。实际应用表明，有些模块可以独立工作，但不能保证连接在一起也能正常工作。对程序中某些局部不能反映的问题，在全局上就容易暴露，影响功能的实现。主要测试模块之间的衔接、参数传递等。
将被测试的子系统组装成一个完整的系统进行系统测试。这是一种有效的方法，来检测系统是否能够在系统的计划说明书中指定功能。主要测试整个系统的运行和与其它软件的兼容性。
什么是设计用例的方法、依据？
设计白盒测试用例的方法有：基本路径测试\等效分类\边界值分析\覆盖测试\循环测试\数据流测试\程序插入测试\编译测试。此时根据的是详细的设计说明和它的代码结构
黑盒子测试用例设计方法：基于用户需求的测试\函数图分析法\等价类划分法\边界值分析法\错误推断法\因果图法\判断表驱动分析法。根据用户需求规范书，详细设计说明书。
一个测试案例通常包含哪些内容？强调编写测试用例的具体实践方法不同结构，所包括的用例的不同(版本、编号、项目、设计人员、设计日期、输入、预期输出…)
在软件测试用例中，测试用例编号，测试标题，重要性等级，测试输入，操作步骤，期望结果。
使用编号：测试用例的编号有一些规则，例如，系统测试用例的编号定义规则：
PROJECT1-ST-001，命名规则为项目名称+测试阶段类型(系统测试阶段)+编号。通过定义测试用例编号，可以方便地找到测试用例并方便地跟踪测试用例。
考试题目：描述测试用例，测试用例标题应清楚地表达测试用例的用途。例如“在测试用户登录时输入密码错误，软件的响应状态”
重要性级：定义一个测试用例的优先级，通常可分为“高”和“低”。一般而言，如果软件需求的测试用例优先级是“高”，那么该需求的测试用例优先级也是“高”；反之亦然，测试输入：在测试执行中提供各种输入条件。基于输入条件的需求，决定测试用例的输入。在软件需求中，测试用例的输入对输入是非常依赖的，如果在软件需求中没有明确定义需求的输入，那么在测试用例设计中会遇到很大的障碍。
行动步骤：提供测试执行流程的步骤。如果是复杂的测试用例，则需要将测试用例的输入分成几个步骤来完成，并在操作步骤中详细列出。
期望的结果：提供测试执行所期望的结果，并且基于软件需求中的输出。实际测试中，若实际测试结果与预期不符，则测试未通过；相反，则测试通过。
管理过程，描述使用 bugzilla缺陷管理工具来追踪软件缺陷(BUG)
当一个 bug被测试人员或者开发人员发现错误时，判断是哪一个模块出现问题，填写 bug报告之后，系统自动通过E-maill通知项目组长，或者直接通知开发者。确认无误后，修改状态为 VERIFIED.在整个产品发布之后，修改为 CLOSED.这也是个问题， REOPENED，状态恢复为" New"，并发送邮件通知。根据具体情况，项目组长重新指定给 bug所属的开发人员。若要这样做， resolved并给出解决方案。(创建补丁附件和补充说明)开发者收到E-mail信息后，判断修改范围是否属于自己。如果没有，重新 reassigned指派给项目组长或者应该指派的开发人员。测试员查询修改过的 bug，重新进行测试。