没有合适的资源?快使用搜索试试~ 我知道了~
首页软件测试知识(测试工程师基础教程)
软件测试知识(测试工程师基础教程)

软件测试基础知识,对以后工作非常有用。如果你觉得你不适合或暂时还没有能力做开发的话,先做测试。这是一些测试的基础知识,希望对大家有用。本人也在学习中。
资源详情
资源评论
资源推荐

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. 为了更好的改进开发过程和测试过程,需要对缺陷进行分析,总结如缺陷的类别、缺
陷的龄期分布等信息,这是缺陷分析的管理。
11.专业词语解释
α 测试:
Alpha 测试(α 测试)是由一个用户在开发环境下进行的测试,也可以是公司内部的用户
在模拟实际操作环境下进行的受控测试,Alpha 测试不能由程序员或测试员完成。Alpha
测试发现的错误,可以在测试现场立刻反馈给开发人员,由开发人员及时分析和处理。目
的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。
Alpha 测试可以从软件产品编码结束之后开始,或在模块(子系统)测试完成后开始,也
可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册(草稿)
等应该在 Alpha 测试前准备好。
β 测试
Beta 测试(β 测试)是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。
开发者通常不在测试现场,Beta 测试不能由程序员或测试员完成。因而,Beta 测试是在
开发者无法控制的环境下进行的软件现场应用。在 Beta 测试中,由用户记下遇到的所有
问题,包括真实的以及主管认定的,定期向开发者报告,开发者在综合用户的报告后,做
出修改,最后将软件产品交付给全体用户使用。Beta 测试着重于产品的支持性,包括文档、
客户培训和支持产品的生产能力。只有当 Alpha 测试达到一定的可靠程度后,才能开始
剩余18页未读,继续阅读
















安全验证
文档复制为VIP权益,开通VIP直接复制

评论2