初级测试总结题！必背！必背！必背！

1）软件的概念？

软件是计算机系统中与硬件相互依存的一部分，包括程序、数据以及与其相关文档的完整集合。

2）软件测试的概念？

使用人工或自动手段来运行或测试某个系统的过程, 其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别

3）测试人员和开发人员区别?

①人员不同

测试：开发人员和测试人员 开发：只有开发人员

②所处阶段不同

测试：贯穿整个软件开发生命周期

调试：在软件开发编码阶段以及测试过程中对BUG进行调试

③对bug处理结果不同

测试：只找出错误，不解决

调试：找出错误并解决

4）什么是需求？

①用户解决问题或达到目标所需的条件或权能，

②系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能

5）测试生命周期模型？

V模型、W模型、瀑布模型、 螺旋模型、敏捷H模型

软件测试流程
1、需求分析，需求评审

2、制定测试计划、计划评审

3、编写测试用例、用例评审

4、测试实施阶段、执行测试用例

按照设计好的用例、准备好的数据和制定的测试策略，实施进行具体的测试过程

5、测试评估阶段

测试总结、缺陷分析、过程评估

7）V模型？

8）W模型？

9）瀑布模型？

10）需求评审内容？

①对需求的描述是否易于理解？

②受否存在有二义性的需求？

③是否定义了术语表，对特定含义的术语给予了定义？

④最终产品的每个特征是用唯一的术语描述的吗？

⑤需求是中的条件和结果是不是合理，有没有遗漏一些异常因果关系？

⑥需求中有没有包含不确定行描述，如：大约、可能、等

⑦每个规格是不是都有明确说明？

⑧环境搭建是否可能或有困难？

11）需求分类？

①业务需求 ②用户需求 ③系统需求

第二部分

12）什么是测试用例？

为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。也就是解决要测什么、怎么测和如何衡量的问题

13）什么是测试计划?

软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试。

14）用例优先级？

② 高：最常执行以保证功能性是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合。

③ 中：这是使给出的功能区域或功能变得更详细，检查功能的多数方面包括边界，错误和配置测试的测试用例。 ④ 低：这是通常最少被执行的测试用例。但这并不意味着这些测试都不重要，只是说他们在项目的生命期间里不是常常被运行，例如GUI，错误信息，可用性

15）用例内容？

主要分为三大部分：基本信息、用例主体、执行记录

基本信息：项目名称、功能模块名、用例设计人、测试执行人、功能特性、测试目的、预置条件、参考信息

用例主体：用例编号、测试对象、检查点、预置条件、用例说明、优先级、预期结果

执行记录：测试结果、缺陷编号、备注

16）用例执行结果？

通过，不通过，未运行，无法运行

17）测试计划内容？

①测试目的 ②测试背景 ③文件受众 ④术语和定义⑤测试参考文档

⑥测试提交文档 ⑦测试范围 ⑧测试策略⑨测试资源⑩测试进度里程碑

⑪系统错误、优先级⑫测试阶段进入退出标准和通过标准

18）测试阶段？

①单元测试（组件测试）

②集成测试 ：自顶向下集成测试 、 自底向上集成测试

③系统测试

④验收测试

19）黑盒测试方法？（写出15种以上）

动态测试

故障转移和恢复测试

配置测试

容量测试

UI测试

数据和数据库完整性测试

易用性测试

功能测试

性能测试

自动化测试

健壮性测试

稳定性测试

场景测试

逻辑测试

随机测试

集成测试

系统测试

验收测试

冒烟测试

兼容性测试

逆向思维测试

本地化测试

接口测试

回归测试

Cookie测试

Alpha测试

Beta测试

安全性和访问控制测试

20）白盒和黑盒区别？

白盒测试：是通过程序的源代码进行测试而不使用用户界面。

黑盒测试：是通过使用整个软件或某种软件功能来严格地测试

①测试特点不同

黑盒测试：测试功能

白盒测试：测试程序接口与结构

②测试依据不同

黑盒测试：需求规格说明书

白盒测试：软件程序

③侧重点不同

黑盒测试：关注功能逻辑实现

白盒测试：关注内部代码结构

21）测试类型？

黑盒

白盒

灰盒

22）回归测试？

更新新版本以后确保老版本的功能依然可以使用

23）alpha测试—内部测试（未公开）

beta测试—用户公测

24）冒烟测试？

确保软件满足系统测试的要求

25）系统测试标准？

不存在致命或严重级别的BUG

不存在优先级为P1的BUG

遗留问题不能大于总BUG数的8%

遗留问题不能明显影响用户使用

26）集成模块？

驱动模块、存根模块

27）验收测试内容？

合同验收测试、法规性验收测试、alpha测试、beta测试、确保实际效果与需求一致

28）确认测试？

缺陷修复后再对其进行测试，确保真正被修复

29）设计用例原则？

100%的覆盖需求

1. 编写测试用例的方法

等价类

边界值

因果图

场景法

正交法

（有经验的老司机还可采用错误推断法）

1. BUG的优先级

P1应立即修复的问题

P2在产品发布之前必须修复的问题

P3如果时间允许应该修复的问题

P4可以在发布版本中存在的问题

P5可改可不改，无伤大雅

32）BUG严重程度

致命

严重

一半

轻微

建议

33）常用的BUG管理工具

禅道、JIRA、Bugfree、QC

34）符合下边5个规则的才能叫做软件缺陷：

①软件未达到产品说明书标明的功能

②软件出现了产品说明书指明不会出现的错误

③软件功能超出产品说明书指明范围

④软件未达到产品说明书虽未指出但应达到的目标

⑤软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好

35）缺陷产生的原因

程序设计错误、文档不完善、需求不断变化、软件的复杂性、沟通交流不够 、工期短，任务大、软硬件支持不完善

36）判断发现的问题是否是缺陷的方法

①通过参考文档来确认缺陷

②通过了解软件产品的行业背景（或参考同类典型软件）来发现缺陷

③通过沟通来确认和识别缺陷

37）缺陷报告原则

①Correct（准确）：每个组成部分的描述准确，不会引起误解； ②Clear（清晰）：每个组成部分的描述清晰，易于理解； ③Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容； ④Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息； ⑤Consistent（一致）：按照一致的格式书写全部缺陷报告。

38）缺陷报告的用途是什么？

①记录缺陷

②缺陷分类

③缺陷跟踪

39）缺陷报告的生命周期（处理流程）

激活、待确认、已解决、待确认、重新激活、已关闭

40）缺陷报告内容

三部分：基本信息、缺陷主体、跟踪记录

①基本信息：编号、版本号、软件名称、编译号、测试人员、日期、指定处理人、硬件平台、操作系统、严重程度、优先级

②缺陷主体：缺陷概述、预置条件、详细描述、预期结果、实际结果

③跟踪记录：处理报告、处理日期、修改记录、返测人、返测版本、返测日期、返测记录

1. OSI网络7层协议
2. 物理层
3. 数据链路层
4. 网络层
5. 传输层
6. 会话层
7. 表示层
8. 应用层
9. APP的兼容性测试包含哪些？
10. 浏览器
11. 系统
12. 分辨率
13. 网络

看完这篇内容后，相信以下两件事，也会对你的个人提升有所帮助：

1、 点赞，让更多人能看到这篇文章，同时你的认可也会鼓励我创作更多优质内容。

2、 让自己变得更强：想一想，如果你想在测试这个行业一直做下去，你的经验和功能测试技术是远远不够的，你需要进阶，你需要不断丰富你的技术栈！还等什么！

老规矩，先看看部分资料截图

这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。

关注我的微信公众号：【伤心的辣条】免费获取~

我的学习交流群：902061117 群里有技术大牛一起交流分享~

如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！

好文推荐：

阿里小黑叹息：越来越多的年轻人从职场撤退了？

Python简单？先来40道基础面试题测试下

App公共测试用例梳理

从一名开发人员转做测试的一些感悟