软件测试相关问题.doc

1、软件测试的 目的？答：测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。2、需求文档测试：主要测试需求中是否存在逻辑矛盾以及需求在技 术上是否可以实现；设 计文档测试：测试设计是否符合全部需求以及设计是否合理。3、什么是软件测试？答：软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即 输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。4、白盒测试有 哪几种方法？答：白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过 程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作， 而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试5. 软件的缺陷等级应如何划分？ 1致命错误，可能导致本模块以及其 他相关模块异常，死机等问题； 2严重错误，问题局限在本模块，导致模块功能失效或异常退出 3一般错误，模块功能部分失效； 4建议问题，由问题提出人对测 试对象的改进意见；附加: 软件缺陷的分类与管理 在软件缺陷中还有一种分法，跟据缺陷内容来分，主要分为需求Bug与 程序Bug，对于这种分法的好处就是明确了Bug处理的责任人。对于程序Bug我们都 知道是由相关开发人员进行处理。下面主要讨论一下需求Bug,需求Bug从名称上来就知道是要交由需求人员进行处理，可怎么处理，怎样在处理的过程中有效 的让这些创意得到体现。现在我们都有Bug管理系统，这时我们的测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理，不过这 里我想强调的是对需求Bug的定位，如果这个Bug在软件需求说明书中明确提到了，这时就不可能定位它为需求Bug，它是必需让程序员实现的，称为软件功 能缺陷，提交由程序员进行处理。但如果需求说明书没有明确提到的，我们则可以定位为需求Bug.6. 如果能够执行完美的黑盒测试， 还需要进行白盒测试吗？ (白盒与黑盒的区别) 任何工程产品（注意是任何工程产品）都可以使用以下两种方法之一进行测试。 黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。 白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要 求，所有内部成分是否以经过检查。 软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需 求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错 误： 1、是否有不正确或遗漏的功能？ 2、在接口上，输入是否能正确的接受？能否输出正确的结果？ 3、是否有数据结构错误或外部信息（例如数据文件）访问错误？ 4、性能上是否能够满足要求？ 5、是否有初始化或终止性错误？ 软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选 择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白 盒测试主要是想对程序模块进行如下检查：1、对程序模块的所有独立的执行路径至少测试一遍。 2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。 3、在循环的边界和运行的界限内执行循环体。 4、测试内部数据结构的有效性，等等。 以上事实说明，软件测试有一个致命的缺陷，即测试的不完全、不彻底性。由于任 何程序只能进行少量（相对于穷举的巨大数量而言）的有限的测试，在未发现错误时，不能说明程序中没有错误。7. 测试退出标准 测试退出标准为完成测试需求中列出的所有功能及测试过程中发现缺陷的回归测试。 1. 单元测试退 出标准 1)单元测试用例设计已经通过评审 2)核心代码100 经过Code Review 3)单元测试功能覆盖率达到100 4)单元测试代码行覆盖率不低于80 5)所有发现缺陷至少60都纳入缺陷追踪系统且各级缺陷修复率达到标准 6)不存在A、B类缺陷 7)C、D、E类缺陷允许存在 8)按照单元测试用例完成了所有规定单元的测试 9)软件单元功能与设计一致 2. 集成测试退出标准 1)集成测试用例设计已经通过评审 2)所有源代码和可执行代码已经建立受控基线，纳入配置管理受控库，不经过审批不能随意更改 3)按照集成构件计划及增量集成策略完成了整个系统的集成测试 4)达到了测试计划中关于集成测试所规定的覆盖率的要求 5)集成工作版本满足设计定义的各项功能、性能要求 6)在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准 7)A、B类BUG不能存在 8)C、D类BUG允许存在,但不能超过单元测试总BUG的50 9)E类BUG允许存在 3. 系统测试退出标准 1)系统测试用例设计已经通过评审 2)按照系统测试计划完成了系统测试 3)系统测试的功能覆盖率达100 4)系统的功能和性能满足产品需求规格说明书的要求 5)在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准 6)系统测试后不存在A、B、C类缺陷 7)D类缺陷允许存在，不超过总缺陷的5 8)E类缺陷允许存在，不超过总缺陷的108. 测试计划的目的是什么？ 答：测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和 错误造成的隐患带来的商业风险。9. 软件测试应该划分几个阶段?简述各个阶段应重点测试的点?各个阶段的含义？ 大体上来说可分为单元测试,集成测试,系统测试,验收测试,每个阶段又分为以下五个步骤: 测试计划，测试设计，用例设计，执行结果，测试报告 初始测试集中在每个模块上，保证源代码的正确性，该阶段成为单元测试，主要用白盒测试方法。 接下来是模块集成和集成以便组成完整的软件包。集成测试集中在证实和程序构成问题上。 主要采用黑盒测试方法，辅之以白盒测试方法。 软件集成后，需要完成确认和系统测试。确认测试提供软件满足所有功能、性能需求的最后保证。确认测试仅仅应用黑盒测试方法。 单元测试单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等 等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。 集成测试 集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。 系统测试系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确 性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。 验收测试 验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试 数据通常是系统测试的测试数据的子集. 回归测试回 归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。10. 针对缺陷采取怎样的管理措施？ 1. 要更好的管理缺陷，必须引入缺陷管理工 具，商用的或者开源的都可。 2. 根据缺陷的生命周期，考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。 3. 所有发现的缺陷（不管是测试发现的还是走读代码发现的）都必须全部即时的、准确的提交 到缺陷管理工具中，这是缺陷提交的管理。 4. 缺陷提交后，需要即时的指派给相应的开发人员，提交缺陷的人需要密切注意缺陷的状态， 帮助缺 陷的尽快解决。缺陷解决后需要即时对缺陷的修复进行验证。这样的目的有两个：一个是让缺陷尽快解决；二是方便后面缺陷的分析（保证缺陷相关的信息准确，如 龄期等），这是缺陷状态的管理。 5. 为了更好的改进开发过程和测试过程，需要对缺陷进行分析，总结如缺陷的类别、缺陷的龄期分布等信息，这是缺陷分析的管理。11.专业词语解释测试:Alpha测试（测试）是由一个用户 在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由 程序员或测试员完成。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可 靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程 中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应该在Alpha测试前准备好。测试Beta测试（测 试）是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员 完成。因而，Beta测试是 在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合 用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。只有当 Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产品发行的人 员来管理。驱动模块:驱动模块在大多数场合称为主程序，它接收测试数据并将这些数据传递到被测试模块.单元测试一个函数 单元时，被测单元本身是不能独立运行的，需要为其传送数据，为此 写驱动驱动模块主要完成以下事情：1、接受测试输入；2、 对输入进行判断；3、将输入传给被测单元，驱动被测单元执行；4、接受被测单元执行结果，并对结果进行判断；5、将判断结果作为 用例执行结果输出测试报告。桩模块比如对函数A做单元测试时，被测的函数单元下还包括了一个函数B，为了更好的 错误，定位错误，就要为函数B写桩，来模拟函数B的功能，保证其正确。白盒测试白盒测试(White-box Testing，又称逻辑驱动测试,结构测试),它是知道产品 内部工作过程，可通过测试来 检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内 部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。对 开发语言的支持：白盒测试工具是对源代码进行的测试，测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。目前测试工具主要支持的开发语言 包括：标准C、C、Visual C、Java、Visual J+等。静态测试动态通过评审文档、阅读代码等方 式测试软件称为静态测试,通过运行程序测试软件称为测试.在动态测试中,通常使用白盒测试和黑盒测试从不同的角度设计测试用例,查找软件代码中的错误.12、 回归测试回归测试的目的是在程序有修改的情况下，保证原有 功能正常的一种测试策略和方法。说白了就是，我们测试人员在对程序进行测试时发现bug， 然后返还程序员修改，程序员修改后发布新的软件包或新的软件补丁包给我们测试人员，我们就要重新对这个程序测试，已保证程序在修正了以前bug的情况下， 正常运行，且不会带来新的错误的这样一个过程。 一般情况下是不需要全面测试的，而是根据修改的情况进行有效的测试。13、单元测试、集成测试、系统测试的侧重点是什么？单 元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其 他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等。集成测试，也叫组装 测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能 够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接 以及参数的传递等。系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方 法。测试重点是整个系统的运行以及与其他软件的兼容性。14、设计用例的方法、依据有那 些？白盒测试用例设计有如下方法:基本路径测试等价类划分边界值分析覆盖测试循环测试数据 流测试程序插桩测试变异测试.这时候依据就是详细设计说明书及其代码结构黑盒测试用例设计方法:基于用户需求的测试功能图分析方法等价类 划分方法边界值分析方法错误推测方法因果图方法判定表驱动分析方法正交实验设计方法.依据是用户需求规格说明书,详细设计说明书。15、集成测 试通常都有那些策略？1、在把各个模块连接起来的时候，穿越模块接口 的数据是否会丢失；2、各个子功能组合起来，能否达到预期要求的父功能；3、一个模块的功能是否会对另一个模块的功能产生不利的影响；4、 全局数据结构是否有问题；5、单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。16、 一个缺陷测试报告的组成测试软件项目名称,每个要测试软件项目都有唯一的名称，有的公司对项目还有特定的 编号。测试软件版本号,测试周期内，一般需要测试多个软件版本，报告错误时，一定要正确填写产生错误的软件版本号。测试者名 称,便于分清责任，便于管理。测试日期与时间,便于分析和统计错误报告信息。测试软件环境,包括操作系统和其他必要的软件程序。测 试硬件环境,包括测试计算机和其他测试设备的配置信息。错误描述,简明的描述错误的特征，便于查询和快速浏览。错误标识编号 (ID#) ,每个错误都有一个唯一的标识编号，方便查询。错误类型,根据错误类型，分配给适当的人员处理错误。错误级 别,错误的严重程度和处理的优先级，优先处理高级别的错误。错误状态,错误状态表明错误是否已经处理和将怎样处理，根据错误状态，采用适当 的处理方法。错误处理者名称,便于分清责任，便于管理。重现错误的操作步骤,便于重现错误，修复错误和验证错误。期 望的结果,描述满足设计要求的结果。实际测试结果,描述实际测试后得到的结果。必要的附图,便于确认错误的表现形式和错误位 置。测试者的建议等注释,便于错误处理者快速和正确处理错误17、基于 WEB信息管理系统测试时 应考虑的因素有哪些？一、功能测试 1、链接测试 2、表单测试 3、Cookies测试 4、设计语言测试 5、数据库测试二、性能测试 1、连接速度测试 2、负载测试 3、压力测试三、可用性测试 1、导航测试 2、图形测试 3、内容测试 4、整体界面测试四、客 户端兼容性测试 1、平台测试 2、浏览器测试五、安全性测试18、软件本地化测试比功能测试都有哪些方面需要注意？软件本地 化测试的测试策略：1.本地化软件要在各种本地化操作系统上安装并测试。2.源语言软件安装在另一台相同源语言操作系统上， 作为对比测试。3.重点测试因本地化引起的软件的功能和软件界面的错误。4.测试本地化软件的翻译质量。5. 手工测试和自动测试相结合19、软件测试项目从什么时候开始？为什么？ 软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发过程中产生的所有产品都测试,并且软件缺陷存在放大趋势.缺陷发现的 越晚,修复它所花费的成本就越大.20、需求测试注意事项有哪些？一 个良好的需求应当具有一下特点：完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。正 确性：每一项需求都必须准确地陈述其要开发的功能。一致性：一致性是指与其 它软件需求或高层（系统，业务）需求不相矛盾。可行性：每一项需求都必须是在已知系统和环境的权能和限 制范围内可以实施的。无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁 明了的用户性的语言表达出来。健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。必要 性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。可 测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。可修改性：每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。可跟 踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（f i n e - g r a i n e d ）的方式编写并单独标明，而不是大段大段的叙述。21、 简述一下缺陷的生命周期 软件缺陷的生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。简单的软件缺陷生命周期：1、 发现打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员；2、打开修复：开发人员再现、修复缺陷，然后提交测试人员去验证；3、 修复关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。但是这是一种理想的状态，在实际的工作中是很难有这样的顺利的，需要考虑的各种情况都还是非常 多的。复杂的软件缺陷生命周期：1、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，不是代码问题，就是设计需要修 改；2、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，以后修改的，就可以延期；3、新建一个软件缺陷，这个软件 缺陷是（open）状态，进行bug审查，实际没有这个bug，可以将其关闭；4、新建一个软件缺陷，这个软件缺陷是（open）状态，看是否 清楚可重现，如果不能重现，就是缺少信息，需要返回到（open）状态；如果能够重现，就进行修正，修正后关闭，进行回归测试。软件缺陷生命22 什么是“软件测试”？Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features ofthe software item1就是一个通过分析软件和需求之前差异，发现bug,对软件的功能进行评价的过 程。2.软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。3.软件测试是为了发现错误而执行程序的 过程。23 什么是“测试案例”?测试 案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的工 作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设置、输入数据要求、步骤、以及预期的结 果。24 如果时间不够，无法进行充分的测试怎么办?使 用风险分析，确定测试的重点。由于很少有机会对一个应用软件进行所有可能的测试 (包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西)，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经 验。如果有正当理由，也可采用正式的方法。需要考虑下列因素：1) 对于该项目的用途而言，哪种功能最重要?2) 哪种功能对用户最明显?3) 哪种功能对安全影响最大?4) 哪种功能对用户最有用?5)对客户来说，该应用 软件的哪个部分最重要?6)在开发过程中，该应用软件的哪个部分可以最先测试?7)哪一部分代码最复杂，容易导致出现错误?8) 哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?9)哪一部分程序与过去项目中引起问题的部分相类似/有关?10) 哪一部分程序与过去项目中需要大量维护的部分相类似/有关?11)需求和设计的那些部分不清楚或不容易读?12)开发人员认 为在应用软件中哪些部分是高风险的?13)哪些问题能造成最差的发行?14)哪些问题最能引起用户抱怨?15) 哪些测试可以容易地覆盖多种功能?16)哪些测试在覆盖高风险部分的测试时使用时间最少?25 如果需求一直在变化怎么办?1)如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从 而可以尽早地改变测试计划和策略。2)如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做 很多事情了。3)好的代码注释和好的文档有助于开发人员作出相应的改变。4)只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。5)在项目的时间表中应当留出余量，以应付可能出现的变更。6) 尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。7)通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需 求列入该应用软件的以后的版本。8)要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。9) 在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。10)在设计自动测试剧本时，试图使其有一些灵活性。11) 在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。12)对变更进行适当的风险分析，以减少回归测试的要求。13) 在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。14)少注意详细的 测试计划和测试案例，要把重点放在专门的测试 (ad hoc testing) 上。26.软件测试分哪两种方法？分别 适合什么情况？软件测试方法一般分为两种：白盒测试与黑盒测试。 白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试，它着重于程序的内部结构及算法，通常不关心功能与性能指标；黑盒测试又被称为功能测试、 数据驱动测试或基于规格说明的测试，它实际上是站在最终用户的立场，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。27.一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。计划阶段、设计阶段、白盒单元、白盒集成、黑盒单元、黑盒集成、系统测试、回归测试、验收测试一套完整的测试应该由五个阶段组 成： 1）测试计划首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准。以后所有的测试工作都将围绕着测试需求 来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。 2）测试设计将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响测 试结果的有效性）。3）测试开发建立可重复使用的自动测试过程。4）测试执行执行测试开发阶段建立的自动测 试过程，并对所发现的缺陷进行跟踪管理，测试执行一般由单元测试、 组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。5）测试评估结合量 化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。28.软件测试的类型有那些？分别比较这些不同的测试类型的区别与联系。 BVT （Build VerificationTest）， 主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确Scenario Tests（基于用户实际应用场景的测试），Scenario Tests优点是关注了用户的需求，缺点是有时候难以真正模仿用户真实的使用情况Smoke Test，修复Bug后，针对此次修复是否会对其他模 块造成影响而进行的专门测试。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低此外，还有Application Compatibility Test（兼容性测试），主要目的是为了兼容第三方软件，确保第三方软件能正常运行，用户不受影响。Accessibility Test（软件适用性测试），是确保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。其它的 测试还有Functional Test（功能测试）、Security Test（安全性测试）、Stress Test（压力测试）、Performance Test（性能测试）、 Regression Test（回归测试）、Setup/Upgrade Test（安装升级测试）等29.测试用例通常包括那些内容？着 重阐述编制测试用例的具体做法不同结构的用例包括的不一样。（版本、编号、项目、设计人员、设计日期、输入、预期输出） 软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。 用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称测试阶段类型（系统测试阶段）编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。 测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” .重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好 的定义需求的输入，那么测试用例设计中会遇到很大的障碍。 操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。 预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试 通过。30.描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟 踪的管理的流程 1) 测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。 2) 经验证无误后，修改状态为VERIFIED.待整个产品发布后，修改为CLOSED.3) 还有问题，REOPENED，状态重新变为“New，并发邮件通知。 4) 项目组长根据具体情况，重新reassigned分配给bug所属的开发者。 5) 若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明） 6) 开发者收到Email信息后，判断是否为自己的修改范围。 7) 若不是，重新reassigned分配给项目组长或应该分配的开发者。 8) 测试人员查询开发者已修改的bug，进行重新测试。（可创建test case附件）在我们的工 作中，有很多的客户问到关于华为的面 试的问题，希望我们能提供一些关于华为面试的经验，也有很多的客户建议我们能开设这样一个板块，向大家介绍如何面对知 名企业的面试，我们也将相关的面试经验收集整理，供大家参阅，今天要讲的是华为的面试经验！ 面试过程中，面试官会向应聘者发问，而应聘者的回答将成为面试官考虑是否接受他的重要依据。对应聘者而言，了解这些问题背后的“猫腻”至关重要。本文对面 试中经常出现的一些典型问题进行了整理，并给出相应的回答思路和参考答案。读者无需过分关注分析的细节，关键是要从这些分析中“悟”出面试的规律及回答问 题的思维方式，达到“活学活用”。问题一：“请你自我介绍一下” 思路：1、这是面试的必考题目。 2、介绍内容要与个人简历相一致。 3、表述方式上尽量口语化。 4、要切中要害，不谈无关、无用的内容。 5、条理要清晰，层次要分明。 6、事先最好以文字的形式写好背熟。 问题二：“谈谈你的家庭情况” 思路：1、况对于了解应聘者的性格、观念、心态等有一定的作用，这是招聘单位问该问题的主要原因。 2、简单地罗列家庭人口。 3、宜强调温馨和睦的家庭氛围。 4、宜强调父母对自己教育的重视。 5、宜强调各位家庭成员的良好状况。 6、宜强调家庭成员对自己工作的支持。 7、宜强调自己对家庭的责任感。 问题三：“你有什么业余爱好？” 思路：1、业余爱好能在一定程度上反映应聘者的性格、观念、心态，这是招聘单位问该问题的主要原因。 2、最好不要说自己没有业余爱好。 3、不要说自己有那些庸俗的、令人感觉不好的爱好。 4、最好不要说自己仅限于读书、听音乐、上网，否则可能令面试官怀疑应聘者性格孤僻。 5、最好能有一些户外的业余爱好来“点缀”你的形象。 问题四：“你最崇拜谁？” 思路：1、最崇拜的人能在一定程度上反映应聘者的性格、观念、心态，这是面试官问该问题的主要原因。 2、不宜说自己谁都不崇拜。 3、不宜说崇拜自己。 4、不宜说崇拜一个虚幻的、或是不知名的人。 5、不宜说崇拜一个明显具有负面形象的人。 6、所崇拜的人人最好与自己所应聘的工作能“搭”上关系。 7、最好说出自己所崇拜的人的哪些品质、哪些思想感染着自己、鼓舞着自己。问 题五：“你的座右铭是什么？” 思路：1、座右铭能在一定程度上反映应聘者的性格、观念、心态，这是面试官问这个问题的主要原因。 2、不宜说那些医引起不好联想的座右铭。 3、不宜说那些太抽象的座右铭。 4、不宜说太长的座右铭。 5、座右铭最好能反映出自己某种优秀品质。 6、参考答案“只为成功找方法，不为失败找借口”问题六：“谈谈 你的缺点” 思路：1、不宜说自己没缺点。 2、不宜把那些明显的优点说成缺点。 3、不宜说出严重影响所应聘工作的缺点。 4、不宜说出令人不放心、不舒服的缺点。 5、可以说出一些对于所应聘工作“无关紧要”的缺点，甚至是一些表面上看是缺点，从工作的角度看却是优点的缺点。问题七：“谈一谈你的一次失败经历” 思路：1、不宜说自己没有失败的经历。 2、不宜把那些明显的成功说成是失败。 3、不宜说出严重影响所应聘工作的失败经历4、所谈经历的结果应是失败的。 5、宜说明失败之前自己曾信心白倍、尽心尽力。 6、说明仅仅是由于外在客观原因导致失败。 7、失败后自己很快振作起来，以更加饱满的热情面对以后的工作。 问题八：“你为什么选择我们公司？” 思路：1、面试官试图从中了解你求职的动机、愿望以及对此项工作的态度。 2、建议从行业、企业和岗位这三个角度来回答。 3、参考答案“我十分看好贵公司所在的行业，我认为贵公司十分重视人才，而且这项工作很适合我，相信自己一定能做好。” 问题九：“对这项工作，你有哪些可预见的困难？” 思路：1、不宜直接说出具体的困难，否则可能令对方怀疑应聘者不行。 2、可以尝试迂回战术，说出应聘者对困难所持有的态度“工作中出现一些困难是正常的，也是难免的，但是只要有坚忍不拔的毅力、良好的合作精神以及事前 周密而充分的准备，任何困难都是可以克服的。”问题十：“如果我录用 你，你将怎样开展工作” 思路：1、如果应聘者对于应聘的职位缺乏足够的了解，最好不要直接说出自己开展工作的具体办法。 2、可以尝试采用迂回战术来回答，如“首先听取领导的指示和要求，然后就有关情况进行了解和熟悉，接下来制定一份近期的工作计划并报领导批准，最后根据计 划开展工作。” 问题十一：“与上级意见不一是，你将怎么办？”思路：1、一般可以这样回答“我会给上级以必要的解释和提醒，在这种情况下，我会服从上级的意见。” 2、如果面试你的是总经理，而你所应聘的职位另有一位经理，且这位经理当时不在场，可以这样回答：“对于非原则性问题，我会服从上级的意见，对于涉及公司 利益的重大问题，我希望能向更高层领导反映。” 问题十二：“我们为什么要录用你？” 思路：1、应聘者最好站在招聘单位的角度来回答。 2、招聘单位一般会录用这样的应聘者：基本符合条件、对这份共组感兴趣、有足够的信心。 3、如“我符合贵公司的招聘条件，凭我目前掌握的技能、高度的责任感和良好的饿适应能力及学 习能力 ，完全能胜任这份工作。我十分希望能为贵公司服务，如果贵公司给我这个机会，我一定能成为贵公司的栋梁！” 问题十三：“你能为我们做什么？” 思路：1、基本原则上“投其所好”。 2、回答这个问题前应聘者最好能“先发制人”，了解招聘单位期待这个职位所能发挥的作用。 3、应聘者可以根据自己的了解，结合自己在专业领域的优势来回答这个问题。 问题十四：“你是应届毕业生，缺乏经验，如何能胜任这项工作？” 思路：1、 如果招聘单位对应届毕业生的应聘者提出这个问题，说明招聘单位并不真正在乎“经验”，关键看应聘者怎样回答。 2、对这个问题的回答最好要体现出应聘者的诚恳、机智、果敢及敬业。 3、如“作为应届毕业生，在工作经验方面的确会有所欠缺，因此在读书期间我一直利用各种机会在这个行业里做兼职。我也发现，实际工作远比书本知识丰富、复 杂。但我有较强的责任心、适应能力和学习能力，而且比较勤奋，所以在兼职中均能圆满完成各项工作，从中获取的经验也令我受益非浅。请贵公司放心，学校所学 及兼职的工作经验使我一定能胜任这个职位。” 问题十五：“你希望与什么样的上级共事？” 思路：1、通过应聘者对上级的“希望”可以判断出应聘者对自我要求的意识，这既上一个陷阱，又上一次机会。 2、最好回避对上级具体的希望，多谈对自己的要求。 3、如“做为刚步入社会新人，我应该多要求自己尽快熟悉环境、适应环境，而不应该对环境提出什么要求，只要能发挥我的专长就可以了。”问题十六：“您在前一家公司的离职原因是什么？” 思路：1、最重要的是：应聘者要使找招聘单位相信，应聘者在过往的单位的“离职原因”在此家招聘单位里不存在。 2、避免把“离职原因”说得太详细、太具体。 3、不能掺杂主观的负面感受，如“太幸苦”、“人际关系复杂”、“管理太混乱”、“公司不重视人才”、“公司排斥我们某某的员工”等。 4、但也不能躲闪、回避，如“想换换环境”、“个人原因”等。 5、不能涉及自己负面的人格特征，如不诚实、懒惰、缺乏责任感、不随和等。 6、尽量使解释的理由为应聘者个人形象添彩。 7、如“我离职是因为这家公司倒闭。我在公司工作了三年多，有较深的感情。从去年始，由于市场形势突变，公司的局面急转直下。到眼下这一步我觉得很遗憾， 但还要面对显示，重新寻找能发挥我能力的舞台。” 同一个面试问题并非只有一个答案，而同一个答案并不是在任何面试场合都有效，关键在于应聘者掌握了规律后，对面试的具体情况进行把握，有意识地揣摩面试官 提出问题的心理背景，然后投其所好。软件测试管理常见问题及其回答1、测试负责人要进行严格的测试进度跟踪吗？很多时候，由于人力资源的不足，测试项目负责人都是在执行测试，这样就使整个项目缺乏控制，一些问题（例如：有些成员的缺陷质量不够合格；开发人员修改不 及时，系统某些功能发生严重问题导致部分功能无法测试。）得不到解决，耽误了进度。所以测试负责任必须全程监控项目，尽可能多的掌握信息。通常，测试负责 人需要完成下面这些内容的管理工作：测试用例执行情况；每个测试员提交的缺陷情况；测试中是否发生突发问题。2、 测试也有版本控制吗？这里的版本主要是指测试对象的版本控制，也就是指对开发部提交的产品进行版本控制。在开发小组版本管理不规范的情况下，测试小组进行版本控制十分重要，要 保证测试对象是可以控制的。建议开发和测试双方进行明确的约定，可以各自指定专门的测试版本负责人，制定提交原则，对提交情况进行详细的记录，这样基本避 免了版本失控导致的测试失误或无效。3、如何处理测试人员的流动问题？人员流动不仅仅是测试部门，这是IT行业的普遍现象。从管理者角度，主管需要多多和团队内成员进行沟通，建立一个融洽的团队环境，及时掌握情况，可以早些 进行相应的调整。但是只有企业建立好的用人制度，给员工提高广阔的发展空间和好的培训学习机会，才能从根本上解决这一问题。加强项目管理，强化文档管理并保证文档的有效性，可以大大减少由于人员流失带来的损失。同时，测试部门要建立培训机制，使新到员工接受直接或者间接的培 训，快速适应工作。4、为什么开发人员经常抱怨测试工程师提交的缺陷质量太差？我们经常听开发人员说：“这不是缺陷！”，“这个缺陷没有，因为我的系统上运行正常！”。测试工程师本身就是做质量工作的，提交的成果本身就应该质量高 些，为什么还会有这种现象？提交的缺陷引起争议是一种正常的现象，例如测试人员描述不清楚就会引起争议。减少甚至避免这种现象的方法是交叉测试，交叉测试是提高测试质量的一个有效手 段，当然交叉测试会增加一定的测试成本投入。在测试任务完成后，测试工程师之间互相验证彼此提交的缺陷，就会避免了缺陷描述不清、因运行环境而产生的缺陷 等一系列问题，从而大大降低了回归测试以及交流的成本，因而这种投入也是值得的，实际开发人员在单元测试阶段也会进行交叉测试，来提高开发质量。另外，测试人员一定要按照规范描述测试中发现的缺陷，一个缺陷至少描述清楚概要描述、详细描述、重现步骤三方面的内容，缺陷管理参考第八章的内容。5、“让那些新手来做测试，反正他们也不会什么”正确吗？在实际项目开发中，我们常常看到有些单位忽视测试团队存在的意义，当要实施测试时，往往临时找几个程序员充当测试人员。也有些单位尽管认识到了组建测试团 队的重要性，但在具体落实的时候往往安排一些毫无开发经验的行业新手去做测试工作，这常常导致测试效率低下，测试人员对测试工作索然无味。根据笔者的经验，测试团队应首先聘请一名资深的测试领域专家，他应具有极为丰富的同类项目软件测试经验，对软件开发过程中常见的缺陷或错误了然于胸;此 外，他还具有较好的亲和力和人格魅力。其次，项目测试团队还具有很多具备一技之长的成员，如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚 本等。另外，测试团队还应聘请一些兼职成员，如验证测试实施过程中，同行评审是最常使用的一种形式，这些同行专家就属于兼职测试团队成员的范畴。至于测试团队里 里的测试新手，这部分人可以安排去从事交付验证或黑盒测试之类的6、测试同化现象是什么？同化现象是指随着时间的推移，开发人员会逐渐影响测试人员的思维和对缺陷的判断能力，尤其是针对同一产品，同一组开发人员和同一组测试人员共同配合了很长 时间，很多本来是缺陷的问题，由于测试人员对软件“习惯成自然”的使用，会不被当成缺陷，尤其是在开发人员的解释和说服下。同化现象发生可能意味着“恶性 循环”的开始：测试人员会帮着开发人员解释一个个缺陷的合理性，一轮有一轮的测试都不会发现问题。招聘新的人员，不同的测试项目组轮换去测试不同的产品，就可以避免。同时建议产品可以发布测试版，更多的人对其进行测试，就可以发现更多的问题。7、测试工程师如何避免定位效应？社会心理学家曾作过一个试验：在召集会议时先让人们自由选择位子，之后到室外休息片刻再进入室内入座，如此五至六次，发现大多数人都选择他们第一次坐过的 位子。这种现象称为定位效应，说明人们习惯上凡是自己认定的，人们大都不想轻易改变它。定位效应在开发人员和测试人员身上都有体现。例如开发工程师针对某一自己写的功能，经常进行代码移植，这种复制的“功能”，由于上一次经过调试，在新的地 方往往不会认真调试，这些代码往往会带来共享变量冲突等许多种类型的缺陷。定位效应体现在测试人员身上就是测试过的功能不再进行认真测试：在回归测试时，之前由于进行过认真的测试，往往会认为