软件测试面试笔试题


软件测试面试笔试题 2 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 类缺陷允许存在,不超过总缺陷的 10% 8. 测试计划的目的是什么? 答:测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷,通过修正种错误和缺陷提高 软件质量,回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。 9. 软件测试应该划分几个阶段?简述各个阶段应重点测试的点?各个阶段的含义? 大体上来说可分为单元测试,集成测试,系统测试,验收测试,每个阶段又分为以下五个步骤: 测试计划,测试设计,用例设计,执行结果,测试报告 初始测试集中在每个模块上,保证源代码的正确性,,该阶段成为单元测试,主要用白盒测试方法。 接下来是模块集成和集成以便组成完整的软件包。集成测试集中在证实和程序构成问题上。 主要采用黑盒测 试方法,辅之以白盒测试方法。 软件集成后,需要完成确认和系统测试。确认测试提供软件满足所有功能、性能需求的最后保证。确认测试仅仅 应用黑盒测试方法。 单元测试 单元测试是对软件中的基本组成单位进行的测试,如一个模块、一个过程等等。它是软件动态测试的最基本的部 分,也是最重要的部分之一,其目的是检验软件基本组成单位的正确性。 集成测试 集成测试是在软件系统集成过程中所进行的测试,其主要目的是检查软件单位之间的接口是否正确。 系统测试 系统测试是对已经集成好的软件系统进行彻底的测试,以验证软件系统的正确性和性能等满足其规约所指定的要 求,检查软件的行为和输出是否正确并非一项简单的任务,它被称为测试的“先知者问题”。 验收测试 验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子 集. 回归测试 回归测试是在软件维护阶段,对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。 10. 针对缺陷采取怎样的管理措施? 1. 要更好的管理缺陷,必须引入缺陷管理工具,商用的或者开源的都可。 2. 根据缺陷的生命周期,考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。 3. 所有发现的缺陷(不管是测试发现的还是走读代码发现的)都必须全部即时的、准确的提交 到缺陷管理工具 中,这是缺陷提交的管理。 4. 缺陷提交后,需要即时的指派给相应的开发人员,提交缺陷的人需要密切注意缺陷的状态, 帮助缺陷的尽快 解决。缺陷解决后需要即时对缺陷的修复进行验证。这样的目的有两个:一个是让缺陷尽快解决;二是方便后面缺 陷的分析(保证缺陷相关的信息准确,如龄期等),这是缺陷状态的管理。 5. 为了更好的改进开发过程和测试过程,需要对缺陷进行分析,总结如缺陷的类别、缺陷的龄期分布等信息,这 是缺陷分析的管理。 软件测试面试笔试题 3 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、设计用例的方法、依据有那些? 白盒测试用例设计有如下方法:基本路径测试\等价类划分\边界值分析\覆盖测试\循环测试\数据流测试\程序插桩测 试\变异测试.这时候依据就是详细设计说明书及其代码结构 黑盒测试用例设计方法:基于用户需求的测试\功能图分析方法\等价类划分方法\边界值分析方法\错误推测方法\因果 图方法\判定表驱动分析方法\正交实验设计方法.依据是用户需求规格说明书,详细设计说明书。 软件测试面试笔试题 4 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)状态;如果能够重现,就进行修正,修正后关闭,进行回归测试。 软件缺陷生命 软件测试面试笔试题 5 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 item 1 就是一个通过分析软件和需求之前差异,发现 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) 上。 软件测试面试笔试题 6 26.软件测试分哪两种方法?分别适合什么情况? 软件测试方法一般分为两种:白盒测试与黑盒测试。白盒测试又称为结构测试、逻辑驱动测试或基于程序本身 的测试,它着重于程序的内部结构及算法,通常不关心功能与性能指标;黑盒测试又被称为功能测试、数据驱动测 试或基于规格说明的测试,它实际上是站在最终用户的立场,检验输入输出信息及系统性能指标是否符合规格说明 书中有关功能需求及性能需求的规定。 27.一套完整的测试应该由哪些阶段组成?分别阐述一下各个阶段。 计划阶段、设计阶段、白盒单元、白盒集成、黑盒单元、黑盒集成、系统测试、回归测试、验收测试一套完整 的测试应该由五个阶段组成: 1)测试计划首先,根据用户需求报告中关于功能要求和性能指标的规格说明书,定义相应的测试需求报告,即制 订黑盒测试的最高标准。以后所有的测试工作都将围绕着测试需求来进行,符合测试需求的应用程序即是合格的, 反之即是不合格的;同时,还要适当选择测试内容,合理安排测试人员、测试时间及测试资源等。 2)测试设计将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程,并为每个测试过程选择 适当的测试用例(测试用例选择的好坏将直接影响测试结果的有效性)。 3)测试开发建立可重复使用的自动测试过程。 4)测试执行执行测试开发阶段建立的自动测试过程,并对所发现的缺陷进行跟踪管理,测试执行一般由单元 测试、组合测试、集成测试、系统联调及回归测试等步骤组成,测试人员应本着科学负责的态度,一步一个脚印地 进行测试。 5)测试评估结合量化的测试覆盖域及缺陷跟踪报告,对于应用软件的质量和开发团队的工作进度及工作效率 进行综合评价。 28.软件测试的类型有那些?分别比较这些不同的测试类型的区别与联系。 BVT (Build Verification Test),主要目的是验证最新生成的软件版本在功能上是否完整,主要的软件特性是否 正确 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 附件)
还剩7页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享pdf获得金币 ] 0 人已下载

下载pdf

pdf贡献者

tangweibo

贡献于2012-05-25

下载需要 8 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf