测试理论大全附加-常见面试题
测试理论大全(附加-常见面试题)
目录
一、什么是软件（software）
1.软件
计算机=硬件+软件
软件=程序+文档
注意：软件测试的对象是程序和文档，不能只测程序，文档也需要测试（评审）
2.扩展：软件开发的阶段划分
1.需求分析阶段
由 需求分析人员完成
产出物：《需求规格说明书》
2.设计阶段
由系统架构师/分析师完成
产出物：《概要设计说明书》、《详细设计说明书》
3.编码阶段
由开发人员完成
产出物：程序
面试题：哪个阶段引入的bug最多？哪个阶段最少？对测试工作有怎样的影响？
答案：需求分析阶段引入的bug最多（大概占bug总数的55%），其次是设计阶段（大概占bug总数的25%左右）、引入bug最少的是编码阶段（大概引入15%左右的bug）
–另外还有5%左右的bug是由兼容性问题或配置错误引发的
对于测试工作的影响：
- 需求和设计阶段也是必须要测试的，不仅要测试程序，文档也要测（评审）
- 测试应尽早介入，并且贯穿整个开发周期始终（测试应符合尽早测试原则和不断测试原则
二.什么是软件缺陷
缺陷–defect 、 bug
1.缺陷5条定义（重点）：
说明：满足其中任何一条就是bug，与顺序无关
- 需求要求的功能没有实现
- 实现了需求没有要求的功能（画蛇添足）
- 软件中出现了指明不应出现的错误
- 需求虽未明确指明，但是应该实现的功能没有实现
说明：这条是针对需求可能存在漏洞的情况进行的说明
5.软件不易使用、运行缓慢、难以理解等站在用户的角度，一切不好的地方
2.IEEE（美国电气和电子工程师协会）协会对于缺陷的定义（理解）
3.缺陷的近义词（了解）
错误–error
异常–exception
三.软件测试–test
1.什么是软件测试？
简单来说，软件测试就是从现有软件中，尽可能多的查找bug的过程，软件测试的最终目的是：保证软件质量，希望更好质量的软件被交到用户手中。（QA–质量保证）
说明：
- 软件不是完美的，或多或少都存在bug
- 测试人员的职责不是消灭缺陷，而是尽可能多的查找bug
- 软件测试强调排查bug的过程，只要完成了查找过程就是测试，无论找到还是没有找到bug（企业鼓励测试人员多发现bug）
通常测试人员发现bug的比例在：10%–30%
四、计算机的层次
1、计算机层次
计算机硬件（裸机）
操作系统–os（operating system）
应用软件–Application
2.扩展：相关面试题
Q1：什么是操作系统？操作系统的主要功能组成？–（纯计算机理论）
A: 操作系统简称OS,是用来管理计算机硬件和软件的计算机程序。
操作系统的主要功能组成：
- 进程管理
- 设备管理
- 存储管理
- 文件管理
- 作业管理–用户向系统提出的操作请求就是作业
Q2：列举常用的数据库管理系统?
数据库管理系统–DBMS
说明：DB–database数据库
常用的数据库管理系统：
Oracle数据库–甲骨文oracle公司
Mysql数据库–甲骨文公司收购（免费版本越来越少，但性价比较好，适合小项目）
sql server数据库–微软公司
微软产品的主要数据库，但是与其它公司产品兼容性较差
补充两款高端数据库：
DB2–IBM公司
Sybase–sybase公司
提示：关系型数据库的公共语言是标准sql-结构化查询语言
五.计算机层次
1.层次
扩展：面试题
Q3：软件的两个基本要素：
软件的功能要可以正确实现–功能正确性
软件要有强大的异常处理能力–健壮性
Q4：简介常用的计算机操作系统？（5种）
1.windows系统–微软
特点：简单、易用，可视化所以在pc（personal computer 个人电脑）领域占有率最高；
但安全性、稳定性较差，所以在服务器（server）系统领域占有率较低
2.Unix（贝尔实验室、1969年）
特点：稳定性、安全性较高，可以支持二次开发，unix系统在服务器系统领域拥有大量用户（金融行业等）
3.Linux（自由软件、类unix系统）
特点：稳定性和安全性较高，开源、支持二次开发、免费，在服务器os领域占有最多用户
提示：面试时常会考linux的常用命令
4.Mac系统（苹果公司）
1981年问世，是世界上第一款可视化的操作系统
特点：界面美观、图形图像的设计领域表现优异，在设计领域被广泛使用
5.dos系统（微软第一款OS)
特点：单机版、命令式
测试人员常用Dos命令：
进入dos界面-
Win+r键→打开运行→输入cmd，按确定→进入dos界面
常用命令-
ipconfig–查看ip配置
ping –检查与目标地址之间的网络连接情况
六.软件的分类
1.常规划分
1.系统软件
操作系统（os）、操作系统的补丁程序、驱动程序
选择题：选择以下不是系统软件的选项（ B D）
- u盘驱动–驱动程序（是）
- 卡巴斯基–杀毒软件（不是）
- Unix–OS(是)
- Access–单机数据库（不是系统软件）
2.应用软件(application)
按结构进行分类
单机软件
不需要连接网络就可以应用的软件，例如：记事本、压缩软件等
2.分布式软件
需要连接网络才可以应用的软件，例如：qq、微信、百度网站等
- C/S 结构
C：client 客户端
S：server 服务器
C/S–客户端/服务器
- B/S结构
B：browser 浏览器
S：server 服务器
B/S–浏览器/服务器结构
主要区别：
C/S结构：需要在用户终端安装专门的客户端程序，才能访问服务器，享受服务器提供的服务–胖客户端
B/S结构：不需要在用户终端安装专门的客户端程序，只需要有公共的浏览器，在浏览器地址栏中输入相应的网址，就可以享受相应服务器提供的服务–瘦客户端
注意：在测试B/S结构软件时，需要进行“浏览器兼容性”测试
问题：主流浏览器
- IE、Edge –微软
- Firefox–火狐 （FF）
- Safari–苹果
- Chrome-谷歌
- Opera–欧朋软件
七.什么是缺陷报告
- 测试人员发现bug，将bug记录在缺陷报告中
- 通过缺陷报告将bug的信息告知给开发方
- 对缺陷进行跟踪管理
- 总之：缺陷报告是测试人员和开发人员之间重要的沟通方式
八.企业中常用的bug管理工具
企业中通常使用bug管理工具来科学管理bug，常用的工具有：
禅道（国产、中文、免费）–zentao
Jira（鸡爪）
Mantis（螳螂）
QC（HP公司、英文、付费）
Bugfree、bugzilla等
还有公司使用自制的bug管理工具
注意：不同公司使用不同的bug管理工具，缺陷报告的模板可能会有差别，但是毕竟都是进行bug管理，所以核心内容会大同小异。
九.如何编写缺陷报告
案例：除法功能没有实现
（1）缺陷编号（defect/bug ID
记录发现bug的顺序号
缺陷编号能唯一标识每个bug
（2）缺陷标题（summary）
简明扼要的概括该缺陷
（3）创建者/发现者（detected by）
测试人员填写自己的账号或真实姓名
例如：测试人员
xxx_qa
（4）提交bug的日期（date）
注意：bug应“及时”提交
在项目测试中，发现bug后，通常需要审核后，确认是有效bug，再提交，这样可以尽量避免“假bug”被提交（例如：操作错误、配置错误、需求理解错误等造成的假bug）
同时也不要人为延误bug的提交，尽量审核后就及时提交
（5）指派给谁处理（assigned to）
1)常见指派
测试人员→开发方负责人（开发经理）→开发人员
公司中开发经理的账号通常为：
mayun_dm (开发经理)
Mayun_tm(技术经理)
2）补充：公司中同样常见的指派过程
例1：小公司
测试人员→开发人员
例2：大公司
测试人员→测试主管→开发主管→开发人员
（6）功能模块（subject）
在哪个功能模块中发现该bug
作用：定位bug，并且通常开发主管可以通过功能模块明确，该由谁来负责解决该bug（一般是谁开发的谁负责解决）
（7）所属的版本
说明：对于专业的测试人员来说，版本不仅仅指最终发布的版本，也包括在研发过程中曾经出现过的若干临时版本。
扩展：回归测试（回测）
回归测试：就是在当前版本中，对于上个版本测试过的功能，再重新测试一遍。
回归测试的必要性：如果有新增功能，新功能可能会对原有功能造成影响，引发bug；开发人员修改bug，很可能在解决bug的同时带来新的问题；所以基于以上两点应进行回归测试
回归测试存在重复测试，所以如果条件允许，自动化进行回归测试是比较高效的
表明bug处于怎样的处理情况
(8)缺陷的状态(status)
常见状态：
新的–new
激活的–open
已解决–fixed
已关闭–closed
已拒绝–rejected
重新激活–reopen
面试题1：缺陷报告/缺陷的处理过程（流程、步骤、生命周期）？
参考答案：
步骤1：测试人员提交新的缺陷给开发经理
步骤2：开发经理审核确认该bug：
情况1：审核并确认是有效bug，激活该bug，并指派给相应的开发人员
情况2：审核并确认不是有效bug，将拒绝该bug，由测试团队进行进一步跟踪处理（另见面试题：被拒绝的bug如何处理？）
步骤3：开发人员解决bug后，bug设置为已解决状态（待返测的bug）
步骤4：测试人员对已解决的bug进行返测：
情况1：返测通过，测试方（测试人员、测试主管）将bug关闭
情况2：返测未通过，测试人员将bug重新激活，指派回给开发人员再次解决该bug，直到返测通过，关闭bug为止
面试题2：测试人员提bug，被开发方拒绝该怎么处理？（经验题–思路）
首先：明确bug被拒绝的原因，然后自检自查，确认是否是自己的失误造成“假bug”
接下来：如果确认该bug被拒绝的理由不成立，那么要根据不同的被拒原因找到相应的人员（开发人员、产品经理等）沟通、讨论，最终明确是否是bug
但是：如果在沟通处理的过程中遇到自身不能解决的问题，应向直属上级反馈汇报，由上级领导出面沟通协调解决
最后：经过沟通确认，如果确定是“假bug”，那么测试方负责关闭bug
如果确定是有效bug，那么开发方谁拒绝的谁负责激活bug，将bug纳入回缺陷的常规处理流程中继续处理解决
(9)严重程度（severity）
表示该缺陷有多糟糕，对程序的破坏有多大
常见严重级别：
1级–致命–urgent
2级–严重–high
3级–中等/一般–medium
4级–建议性的小问题–low
说明：（1）bug管理工具不同，严重级别的定义也会存在差别，有的工具的严重级别会多于4级
- 中等级别（3级）的bug占比会相对多一些，建议性的小问题（4级）前期会比较多，后续会相对较少
- 严重级别简单说明比较笼统，容易造成测试人员和开发人员之间的争论，所以企业通常会制定具体的说明，但是应注意：不同公司，甚至同一公司不同项目组，缺陷级别的详细说明都可能不同，工作中应注意区别参考
- 注意：缺陷的严重程度应专业准确的划定，不要为了引起开发方重视就故意夸大严重程度
(10)优先级（priority）
就是希望或建议开发方在什么版本或什么时候解决该bug （决策权在开发方）
优先级的常见级别划分：
1级–立即解决–urgent
2级–下个版本解决–high
3级–在发布之前解决–medium
4级–经讨论，尽量在发布之前解决–low
说明：（1）并不是所有bug管理工具的优先级都是划分为4级，有的会超过4级
- 一般情况下，缺陷越严重，优先级越高（成正比），但是也有特殊情况会成反比，例如：界面的bug，严重程度低（通常4级），但是优先级却很高（1般1级、2级）
- 测试人员建议缺陷的优先级后，开发方可能会根据实际情况修改优先级
- 不同公司、项目组对于bug优先级的具体说明还是可能不一样的，大家工作中应注意区别
扩展：关于严重程度和优先级的面试题
Q1：影响优先级的因素有哪些?
- 严重程度，一般缺陷越严重，优先级越高
- 缺陷影响的范围，影响范围越大，优先级越高
- 开发人员的开发压力越小，优先级越高
- 解决bug的成本（时间），成本越低，优先级越高
Q2：优先级和严重程度一定是正比关系吗？
不一定，一般情况下，缺陷越严重优先级越高，但是例如：界面bug，严重程度低，但优先级高，就是反比关系
Q3：严重程度和优先级确定后，开发方还可以修改吗？
严重程度确定后，开发方不可以修改
优先级确定后，开发方根据实际情况可以酌情修改（一般往后改）
Q4：在发布的软件中，是否可能存在发现但是没有解决的bug？
可能存在这种情况，此类bug数量极少，并且严重程度不高（一般、小问题）
在企业中针对此类bug一般会有“bug讨论”，权衡解决该bug的成本，和不解决bug是否会给用户造成严重损失或给公司引发法律诉讼，权衡讨论后方可确认。
最后该类bug通常会在后期，通过升级版本或打补丁的方式给予解决
(11)缺陷描述/重现步骤（description）
就是将发现bug的过程（步骤、测试数据）记录下来，使开发人员可以重现该bug
注意：缺陷描述/重现步骤的要求
描述应逻辑清晰、易读易懂、专业准确、不要出现二义性（歧义）、不要出现评价性的语言，如实记录bug
提示：很多企业会对缺陷描述有格式要求，常见的格式：
例如：
步骤（step）：
预期（期待）结果（expect result）：
实际（真实）结果（actual result）：
十、缺陷报告总结
（1）缺陷报告可以记录 bug
（2）缺陷报告可以对bug进行跟踪管理
（3）缺陷报告可以实现对bug的分类、统计和总结
1、如何识别bug？
（1）参考需求文档，当与需求不符时就是bug
（2）参考bug的5条定义（总的纲领）
（3）参考测试用例中的预期结果，当实际结果与预期结果不一致就是bug
（4）与测试同事、开发人员、产品经理，用户等沟通、讨论来识别bug
补充：随机bug
也叫偶发bug或不可重现bug（慎重使用该名称），就是执行相同的测试过程，时有时无的bug
问题：
测试人员如果遇到随机bug如何处理？
（1）遇到随机bug也要报告
（2）随机bug要说明该bug为随机bug
（3）随机bug的描述应尽量详细，尽可能多的提供bug信息，方便开发方进行bug调查，如果能够提供证迹尽量提供
（4）如果开发方需要测试人员配合bug调查，测试人员应积极配合（例如：提供bug出现频次、保留测试环境、提供相关测试数据或日志等）
（5）如果可以进行白盒测试，也可以加入白盒测试辅助
十一、软件项目的测试流程（重点）
1、熟悉分析需求
2、制定测试计划
通常由测试主管（组长/经理）制定测试计划，测试人员要阅读计划，并按计划要求执行
3、设计测试
分析需求–>提炼测试点–>编写测试用例–>评审用例
4、执行测试，记录测试结果
测试结果：通过–pass
失败–failed
5、记录bug，并且对bug进行跟踪管理
《缺陷报告》
6、测试的总结
对项目测试中的数据进行统计总结，形成《测试总结报告》、《测试报告》
补充说明：
(1) 在项目测试过程中，主要的测试相关文档有：《测试计划》、《测试用例》、《缺陷报告》、《测试总结报告》
(2) 测试计划主要有哪些部分组成？
1）测试产品简介
产品介绍、测试目的、测试范围
2）测试参考文档和提交的测试文档
3）测试进度安排（排期）
4）测试资源
人力、测试环境、测试工具
5）bug的严重程度和优先级的具体说明（可以独立形成文档）
6）测试风险和风险预案
7）项目的测试策略
（3）你能制定测试计划吗？
可以
（4）软件项目测试结束的标准有哪些？
常见的结束标准有：
测试用例100%测试执行
缺陷的解决/修复率达到95%以上
对于发现的所有bug有相应的处理结果，未解决的bug有明确的后期处理说明
完成测试提交物的提交（计划、总结、用例等）
应覆盖测试需求规格说明书中所有的需求
十二、测试用例/案例（test case /test instance）
1、什么是测试用例？
在测试执行之前，由测试人员编写的，用来指导测试过程的重要文档
测试用例的常见组成有：用例编号、用例标题、测试目的、预置条件、测试步骤、预期结果、参考需求、撰写人、是否评审、功能模块、用例类型等
2、黑盒/功能测试时，常用的设计测试用例的方法有哪些？
场景法、等价类划分法、边界值法、判定表法
补充：经验型测试方法–错误推测法
3、 设计测试用例可以参考什么？
（1）需求和需求相关文档
（2）核心的技术文档（例如：设计文档）
说明：测试方可能会拿不到核心技术文档（例如外包的测试团队）
（3）已经开发出来的被测系统
说明：在实际工作中，只参考需求，大概只能设计50%-70%左右的测试用例，结合着被测系统，测试人员可以补充部分用例，这样，可以使用例的设计更为完善
注意：测试用例是可维护的，在项目测试的过程中可以不断完善，逐步优化的
（4）最后可以与开发人员、产品经理、用户等沟通讨论。
注意：实际工作中这些参考资料可能残缺不齐全，但是测试人员应利用一切能利用的现有资源，尽力去测。也可以辅助的查看一些网上资料或参考市面上的类似软件产品设计测试。
4、测试思想
（1）穷举测试思想：就是将所有可能的数据或情况全部都测试，穷举测试是最全面的测试，测试质量高；但是穷举测试效率太低，要耗费太多时间，在实际工作中无法应用
（2）理想测试思想：就是挑选最少的测试数据，达到最好的测试质量（抽样测试），抽样测试的测试效率高，但是毕竟没有穷举测试，有可能有遗漏bug的风险，如果测试时间允许的情况下，测试人员应进行补充测试，以降低遗漏bug的风险
十三、等价类划分法
1、应用场合 （这个方法适合测试什么情况）
在程序中有数据输入的地方，适合使用等价类划分法测试
2、等价类划分法的测试思想
将大量数据划分成若干个范围（等价类），再从每个范围中挑选少量代表数据进行测试–抽样测试
3、有效等价类和无效等价类？
有效等价类–对程序来说，正确的、合理的输入数据集合–验证功能的正确性–正向测试
无效等价类–对程序来说，错误的、不合理的输入数据集合–验证软件的异常处理能力（健壮性）–反向测试
十四、总结测试用例
1、编写测试用例的注意事项：
（1）编写用例之前应明确用例的模板，格式要求；如果带有附件，应明确附件的命名规范；
（2）要明确用例的提交位置
（3）用例需要评审
1）评审方式
交换评审
内部评审会
外部评审会
2）评审的细节 参考：关于用例的评审.docx
十五、 软件开发的阶段划分（复习）
1、软件开发的阶段划分
需求分析阶段–《需求规格说明书》
概要设计阶段–《概要设计说明书》
详细设计阶段–《详细设计说明书》
编码阶段 – 程序
2、问题：哪个阶段引入的bug最多？哪个阶段最少？对测试有什么影响？
需求分析阶段引入bug最多，其次是设计阶段，引入bug最少的是编码阶段
由此可以得出结论：
1）需求和设计阶段也要测试，不能只测程序，文档也必须要测
2）测试应符合“尽早测试原则”和“不断测试原则”
十六、 软件测试的阶段划分
说明：需求和设计阶段的测试内容没有涵盖在这4个阶段中，涵盖的是从编码之后的阶段
1、单元测试
（1）单元测试是最小的测试单位，例如测试一个窗口、方法、函数、功能模块、类等
（2）单元测试主要依据：详细设计的说明文档
（3）单元测试理论上应采用：白盒测试方法
实际：专业测试人员用白盒测试方法做单元测试成本较高，为了降低成本，公司常用开发人员进行单元测试（白盒），为了保证单元测试的质量，公司常会采用：交叉互测还有开发人员测1轮（白盒），测试人员再测1轮（黑盒）的方式
（4）驱动模块和桩模块（概念）
背景：在单元测试阶段，测试者可能会需要编写驱动模块或桩模块
驱动模块：就是模拟被测模块的上一级模块（调用被测模块的）
桩模块：就是模拟被测模块的下一级模块（被“被测模块”调用的）
总结：驱动模块→被测模块→桩模块
2、集成测试
（1）集成测试也叫组装测试，是在单元测试的基础上，将功能模块逐步、有序的合并起来的测试过程
（2）集成测试阶段，功能模块是逐步合并起来的，不是一蹴而就的，这就会形成若干的临时版本
（3）集成测试阶段主要依据：概要设计说明文档
（4）集成测试阶段的测试方法是黑盒结合白盒测试（核心功能、重点模块会辅助以白盒测试）–灰盒
（5）冒烟测试：
说明：当开发团队提测新版本时，测试方通常会对该版本展开冒烟测试。
冒烟测试：就是组织较少的人（1-3人，业务熟练，经验丰富），花费较少的时间（0.5-2天），对提测版本的主要功能展开快速测试，如果主要业务可以实现，就接受该版本，全测试组展开全面测试；如果主要业务都无法实现，版本不稳定，就拒绝该版本，打回开发组。
（6）在集成测试阶段，如果测试团队接到开发方提测的新版本，通常的工作思路是：
首先–冒烟测试，验证是否接受该版本，展开全面测试
接下来–回归测试
返测
最后–如果有新增功能，要重点对新增功能展开测试（说明：有的版本可能是修复版本，没有新增功能）
3、系统测试
（1）系统测试：是在软件组装完成的基础上，将包含硬件和软件的完整系统，在模拟真实的环境中测试的过程
（2）系统测试的两个重点/要点：
1）就是完整系统在模拟真实的环境中，是否全面满足需求规格说明书的要求
2）就是完整系统中，硬件和软件以及软件之间的兼容性测试
3）系统测试主要依据:需求规格说明书
4）系统测试阶段的测试方法就是黑盒测试
5）补充：确认测试
在系统测试之前，通常会进行确认测试，主要确认两个内容：
1）确认组装完成的软件是否可以进入全面的模拟真实环境的系统测试
2）确认相关的文档，尤其是要交付给用户的文档，是否准备齐全
提示：由于确认测试相对参与人员较少、时间较短，所以没有将其与单元、集成、系统、验收测试阶段并列
4、验收测试（UAT）
UAT–user acceptance test –用户接受度测试
（1）验收测试是以用户为主体，检查软件质量的过程，通常用户会使用自己的真实数据，按照自己使用软件的习惯进行操作（非专业），测试人员如果有需要可以从旁配合、帮助
（2）验收测试分为两个小阶段
1）alpha（α）测试
Alpha测试要在软件公司指定的环境中进行，这样公司对发现的bug控制力更强
Alpha测试理论上应该由最终用户亲自到场进行检查
但是实际情况用户可能无法到场，这种情况，通常由公司的测试人员代替用户进行，或者由用户请第三方测试机构代替自己进行
2）Beta（β）测试
在用户的真实使用环境中，由用户亲自进行beta检查（软件公司很难获取bug的信息）
例：公共类软件（游戏、浏览器、输入法、os等）的beta测试
将beta版软件免费发放给用户，通过收集用户在使用过程中遇到的问题来获取bug信息。
十七、软件测试模型
1、软件测试模型可以表示开发阶段和测试阶段（级别）之间的对应关系，最常用的是V模型，此外还有W模型、X模型、H模型等
2、V模型（常考）
（1）会画V模型
（2）V模型的优点
1）开发阶段和测试阶段（级别）划分清晰明确
2）开发阶段和测试阶段（级别）之间的对应关系也是清晰明确的
3）V模型中既包括了测试最低级别的单元测试（专业级、代码级），又包括了测试最高级别的验收测试（用户级、界面级），涵盖比较全面
（3）V模型的缺点
1）缺少需求和设计阶段的测试内容，容易造成误解：测试只是编码之后的收尾工作
2）V模型不符合尽早测试和不断测试的原则
3、W模型（了解）
（1）W模型其实是双V模型，第一个V是完整的开发活动，第二个V是完整的测试活动
（2）W模型的特点：加入了需求和设计阶段的测试活动，使测试和开发阶段看起来是同步并行的
W模型符合尽早测试原则和不断测试原则
十八、软件测试的分类
1、按测试技术划分
（1）黑盒测试：也叫功能测试，就是把程序看作是黑色盒子，在不考虑程序内部结构和内部特性的情况下，检查程序功能是否按照需求规格说明书的规定正常使用。
（2）白盒测试：也叫结构测试，就是将程序看成是透明盒子，要求全面了解程序内部逻辑结构，对所有逻辑路径进行检测。
补充白盒测试：
1）白盒测试的测试质量较高，但是效率低成本高
2）白盒测试要求测试者至少要能读懂代码（代码能力越强越好），需要掌握白盒测试方法（例：代码检查法、逻辑覆盖法、静态结构分析法等），也需要编写测试用例
（3）灰盒测试：结合黑盒测试和白盒测试的要素，对软件进行测试，常在集成测试阶段采用
2、按是否需要运行程序划分
（1）动态测试：就是需要运行程序才能进行测试，例：功能/黑盒测试
注意：白盒测试有时是静态测试，也有时是动态测试
（2）静态测试：就是不需要运行程序，就可以进行测试，例：文档测试、界面测试、静态代码测试：对代码的格式标准、规范进行检查
问题：白盒测试和静态代码测试的区别？
白盒测试：测试的是程序的内部逻辑实现，要求测试者懂代码，会白盒测试方法， 能够编写用例；
静态代码测试：测试的是代码的规范性和标准性，测试者不需要懂代码，也不需要写用例，只需要按照代码检查单对照检查即可。
3、功能测试和性能测试
功能测试：所有的软件都需要进行功能测试，而且需要先保证功能正确，再考虑其它
功能测试既可以手工实现，也可以自动化实现，自动化功能测试主要依赖工具，常用的功能自动化测试工具有：selenium、appium、qtp等
性能测试：不是所有软件都需要进行性能测试，通常分布式软件(C/S,B/S)需要进行性能测试
性能测试不能手工实现，必须要依赖性能测试工具，常用的性能测试工具有：loadrunner（HP,收费）、Jmeter（常用）等
4、其它
（1）返测：对开发人员已解决的bug进行测试，以验证该bug是否被修复
（2）回归测试：在当前版本中，对上个版本中测过的功能再重新测试一遍。用以验证当前版本中的原有功能是否依然正常，是否出现了新的问题。
（3）随机测试（猴子测试）
就是在常规测试用例执行完成后，可以随意测试的过程，随机测试只能是常规测试之外的补充测试方式
（4）兼容性测试
所测试软件与硬件和其它软件之间的兼容性的测试，兼容性测试主要 分为3类：
1）与硬件兼容
与整机兼容
与外设兼容
2）与软件兼容
与操作系统的兼容（品牌、版本、位数：64位、32位）
浏览器兼容性
与其它应用软件兼容
与数据库的兼容
3）数据兼容
测软件的不同版本之间，数据是否兼容
（5）功能/黑盒测试中常用的设计测试用例的方法有哪些？这些测试方法的应用/选择策略是什么？
常用的测试方法有：场景法、等价类划分法、边界值法、判定表法
选择策略的答题思路：就是说清楚每种方法的应用场合
在测试设计中经常用来补充测试用例的方法：错误推测法（经验型方法）