自学整理的软件测试常见的面试题

1，软件的含义

• 程序，数据以及相关文档的全部集合

2，测试与调试的区别是什么

• 测试是由测试人员来进行，主要目标是发现、报告的跟踪缺陷
• 调试是由开发人员进行，主要目标是定位缺陷位置，分析缺陷原因，修复缺陷

3，IEEE是什么意思

• 国际电气电子工程师协会

4，GB

• 国家标准

5，软件测试的含义

• 简单讲，软件测试是发现缺陷的过程；IEEE中的定义是：软件测试是使用人工或者是自动化手段或测定某个系统的过程，目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别

6，软件测试的目的

• 验证软件是否满足各类文档说明书等规定的软件质量要求
• 找出软件缺陷
• 为软件产品的质量和评价提供依据
• 帮助开发改进开发流程

7，什么是功能、性能、兼容性

• 功能是代表一个软件能做什么
• 性能是反映的软件的运行的速度或者效率、占用资源的多少等指标
• 兼容性表示一个软件与在所运行的环境的依赖程度，包括硬件、操作平台、其他软件的依赖

8，测试分为哪几个阶段？每个阶段的测试目的是什么？

• 测试分为单元测试、集成测试、系统测试、验收测试
• 前三个阶段是尽可能多的发现缺陷，而验收测试是要验证软件满足了用户需求，帮助用户建立系统可以正常使用的信心

9，解释QA及其职责

• QA的含义是软件质量的保证
• 主要职责是制定和加强促进软件开发并防止软件缺陷的标准和方法，并监督标准和过程并正确的遵循

10，测试工程师与软件质量保证的区别

• 测试工程师主要的任务是在更短的时间内发现更多的缺陷，并确保这些缺陷可以得到修复
• 软件质量保证的主要职责是指定的加强软件开发并防止软件缺陷的标准和方法并监督标准和过程并正确的遵循

11，测试应该由什么人来进行

• 测试应该由独立的第三方来进行，第三方表示测试人员不参与程序的开发

12，pareto法则。帕累托法则、28原则、82原则

• 一般情况下80%的缺陷聚集在20%的关键核心业务模块中，这个原则至少告诉我们在做测试的时候，应该重点分析和测试20%的核心任务，具体要做好需求分析

13，杀虫剂怪事

• 是描述软件测试越多，其对测试的免疫力越强的现象，这个现象告诉我们测试时候，应该尝试新的方法，不同的测试程序，对程序进行测试，可以找出更多的软件缺陷

14，木桶原理

• 木桶原理在软件方面的主要含义是全面质量管理，另外还告诉我们测试时要关注团队中最弱的人

15，Good-enough原则

• 告诉我们在做测试的时候既不要做过多的测试，也不做不充分的测试，至于多少测试合适，需要我们不断的积累经验，在项目中可以指定最低的测试通过的标准和测试内容，然后具体问题具体分析

16，群集效应

• 含义是发现的缺陷越多，证明软件存在的缺陷越多，群集效应指导我们在找到软件缺陷的地方继续寻找

17，什么是确认测试？回归测试？

• 确认测试也称在测试：缺陷修复后，验证缺陷是否真的修复
• 回归测试：测试修复以后，确保对程序的修改没有给软件其他未改变的地方带来新的缺陷

18，测试人员应该具备哪些素质

• 要有责任心，要有破坏的态度，对事不对人，细心、耐心、缺陷预防的意识、沟通意识、具有一定的开发技能，善于思考

19，如果测试提交的缺陷开发人员不认可怎么办？

• 首先分析或者和开发沟通开发不认可的原因
• 如果拒绝的原因是提交的不是缺陷，而且自己分析后，的确不是缺陷，则应该注意以后做测试的时候要做好复现，认真研读需求，提高自己找缺陷的能力
• 如果拒绝的原因是认可缺陷，但不予修复，如果自己觉得必须修护，则拿出充分的理由和证据和不修护的不利影响和影响的范围，再与开发沟通
• 注意沟通技巧，合理的论述，向开发说明自己判断的理由，注意可以，严谨，不掺杂个人情感

20，如何解决开发和测试的矛盾

• 已沟通和合作的方式开展工作
• 提高开发技能
• 换位思考
• 进行有效沟通

21，测试团队中都有哪些角色？个负责什么任务？各有多少人？

• 测试负责人：制定测试计划。监督安排任务，进行测试总结1人
• 测试工程师：进行测试需求分析，设计用例，搭建环境，执行用例，提交并跟踪缺陷3人
• 技术支持：负责环境维护 1人
• 配置管理员：维护版本架构，维护版本库，文档配置 1人
• 质量保证人员：负责软件质量方面的工作

22，什么 是软件开发生命周期

• 从软件最初的构思到公开发行的过程，以瀑布模型为例：计划、需求、设计、编码、测试、运行、维护循环
• 瀑布模型有严格的开发步骤，每个阶段都是按照顺序进行的，每个阶段都必须出编写完整的文档，每个阶段完成后必须经过审查才能进行下一步
• 瀑布模型不能迭代、不能反复；测试在编码之后，测试太晚；测试的只是程序

23，软件开发有什么模型？软件测试有什么模型？

• 软件开发模型：大爆炸模型、边写边改模型、瀑布模型、螺旋模型、敏捷开发模型

• 软件测试模型：V模型，w模型，H模型，X模型，前置测试模型，敏捷测试模型

• 测

24，简述V模型

• v模型的过程：用户需求—需求分析—概要设计—详细设计—编码—单元测试—集成测试—系统测试—验收测试
• 优点：
  • v的左端表示传统的瀑布开发模型，v的右端明确的将测试分为不同的级别或者阶段，测试的过程更为具体
  • 测试各个阶段和开发的各个阶段相对应
  • v模型的测试策略包括底层测试和高层测试，底层测试是为了源代码的正确性，高层测试是为了整个系统满足用户的需求
• 缺点
  • 测试的对象就是程序的本身，忽视了测试活动虽需求的分析，系统设计等活动的验证和确认的功能，直到后期的验收测试才被发现
  • 测试是开发之后的一个阶段，实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才会被发现

25，简述w模型

• 需求分析、概要设计、详细设计、编码、集成、实施、交付
  系统测试设计、集成调试设计、单元测试设计、单元测试、集成测试、系统测试、验收测试
• 优点：
  • 测试伴随着整个开发周期，需求和测试同样要测试更早的介入测试，可以发现初期的缺陷，修复成本低，分阶段工作，方便项目整体的管理
• 缺点：
  • 开发和测试依然是线性的关系，需求的变更和调整，依然不方便
  • 如果没有文档，跟本无法执行w模型
  • 对于项目组的成员技术要求更高

26，简述H模型

• H模型将测试活动完全独立出来，行程一个完全独立的流程，将测试准备活动和测试执行活动清晰的体现出来，H模型的测试流程是只要是测试准备流程完成，测试就可以执行了
• 优点
  • 软件测试不仅仅指测试的执行，还包括很多其他的活动
  • 软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发的进行，当某个测试时间点就绪的时候，软件测试即从测试准备阶段进入测试执行阶段
  • H模型反映出软件测试要尽早准备，尽早执行
  • 软件测试可以进行迭代，反复进行

27，软件质量要求有哪些？

• 功能要求和非功能要求
• 功能要求：就是代表一个软件能做什么
• 非功能要求：性能测试（压力测试、负载测试、并发测试、可靠性测试）、界面测试、兼容性测试。易用性测试、文档测试、可用性测试、安装测试、安全测试

28，简述测试的基本过程

• 测试人员进行测试需求分析
• 测测试负责人编写测试计划
• 测试人员根据需求分析设计和编写测试用例
• 测试人员搭建测试环境，创建测试数据，执行测试用例，提交缺陷报告并进行跟踪，记录测试事件
• 进行测试评估和总结
• 每一步工作完成后都进行评审

29，拿到一个软件后，应该怎么样开始工作？

• 编写需求分析并评审
• 编写测试计划并评审
• 设计测试用例并评审
• 搭建测试环境、执行测试用例、提交缺陷报告
• 进行评估和总结

29，简述测试流程

• 编写需求分析并评审
• 编写测试计划并评审
• 设计测试用例并评审
• 搭建测试环境、执行测试用例、提交缺陷报告
• 进行评估和总结

29，怎么做测试？

• 编写需求分析并评审
• 编写测试计划并评审
• 设计测试用例并评审
• 搭建测试环境、执行测试用例、提交缺陷报告
• 进行评估和总结

30，怎么进行测试需求分析？

• 收集各类文档，仔细阅读文档，提出问题，分析问题或者沟通解决，整理需求信息
• 编写测试需求分析说明书：功能分解，编写检查点和测试点
• 需求评审

31，拿到项目后，需要分析或者咨询软件的哪些方面的问题？

• 软件的主要功能、流程、开发环境（开发语言（含数据类型）、数据库、中间件）、运行环境（硬件、软件、网络、软件架构）、用户群、测试范围、测试的优先级

32，什么时候提交发现的bug？

• 测试执行发现缺陷时立即提交缺陷

33，什么是入口准则，出口准则？

• 入口准则：是进行测试一项工作前需要准备好的前提条件（文档、软件参考、相关人员）
• 出口准则：是一项测试工作可以结束的前提条件（评审通过、达到测试标准）

34，需求评审都有哪些人参与？

• 项目经理、开发经理、测试经理、测试人员、开发人员、市场经理、客户等

35，怎么做需求评审或者是需求评审需要评审哪些方面？

• 编写或者设计需求评审检查单，比如可以检查有无错别字，病句，标点符号使用是否正确，格式是否一致，是否还有多余需求，是否有错误需求，是否有遗漏需求
• 测

36，测试资源需求有哪些方面？

• 人力资源（参与测试人员、技术、管理）、硬件资源（ CPU、硬盘啊）、软件资源（操作系统、版本、工具）

37，什么是测试策略？什么是测试范围？

• 测试策略主要是指如何进行某种测试（功能测试、性能测试、兼容性测试、可用性测试、易用性测试等）。用于说明测试方法以及如何使用测试方法
• 测试范围有时候等价于测试策略，有时候可以表示要进行测试的某个软件的部位

38，什么是BVT? 冒烟测试？版本验证测试？怎么测？

• 也称冒烟测试、版本验证测试、小版本验证测试、版本构建测试，冒烟测试是一组想先运行以确定这个给出的小版本是否可以测试的测试用例。
• 冒烟测试主要测试软件的基本功能，以判断整个原件值不值得进行大规模测试，通常由一个人进行1-2小时的测试，一般不测试次要功能和各种错误

39，测试计划的内容和目的是什么？

• 内容：包含了产品概述、测试区域、测试策略、测试范围、测试目标（测试项、被测特征）、测试配置。测试资源、测试周期、进度安排（测试任务、人员安排）测试方法、测试途径、测试交流和风险分析等内容
• 目的：是指导测试过程，规定测试活动的范围、方法、资源、进度；明确正在测试的项目、要测试的特征、要执行的测试任务。每个任务的责任人以及计划相关的风险

40，怎么判断是不是软件缺陷

• 软件未达到产品说明书标明的功能
• 软件出现了产品说明书指名不会出现的错误
• 软件的功能超出了产品说明书指名范围
• 软件未达到产品说明书虽未指出但应该达到的目标
• 软件测试应该具体问题具体分析，认为软件难以理解、不易使用、运行速度缓慢或者最终用户认为不好

41，缺陷产生的主要原因有哪些？最主要的原因是什么？

• 需求变更频繁、沟通不良、不了解客户的需求、实现新的功能或者一些很酷的功能、追求新技术、项目期限的压力、需求分析或者设计投入的时间和精力不够、产品的复杂度、开发人员疲劳、压力过大或者受到干扰、缺乏足够的知识、技能和经验、缺乏动力等
• 最主要的原因是，需求方面的原因

42，当你发现一个缺陷时，应该怎么样确认的确是一个缺陷？

• 根据缺陷的判断原则来甄别发现的问题是不是一个缺陷，发现缺陷后，应该做好分离和再线（3次），然后才能提交

43，在正式提交缺陷前，你应该做些什么？

• 分离缺陷、再现缺陷（3次），然后才能提交

44，怎么处理无法再现的缺陷？

• 首先，应当对这样的缺陷进行详细的记录，并尽快提交给开发人员
• 其次，对于寻找难以再现的缺陷要合理的安排时间，对一时难以再现的缺陷可以暂时搁置，以保证项目的正常进度
• 最后，在测试过程中对未再现的缺陷予以关注

45，什么是重复缺陷？怎么避免重复缺陷？

• 重复缺陷：提交了一个缺陷库中存在或者开发人员已经知道的缺陷
• 怎么样避免：
  • 如果缺陷是跟同事提交的重复，任务分工解决，也可以在提交之前查询下缺陷库里面是否存在
  • 如果缺陷是与自己提交的缺陷重复，则需要提高发现缺陷的能力，通过提高开发能力来理解两个缺陷的本质上一个缺陷

46，什么是无效缺陷？怎么避免无效缺陷？

• 提交的缺陷不是真正的缺陷
• 充分了解需求，提高自己识别缺陷的能力、提高写作的能力

47，缺陷报告的写作标准是什么？

• correct（准确）：每个组成部分的描述准确，不会引起误解
• clear（清晰）：每个组成部分的描述清晰，易于理解
• concise（简洁）：只包含必不可少的信息，不包含任何多余的内容
• complete（完整）：包含复现该缺陷的完整步骤和其他本质信息
• consistent（一致）：按照一致的格式书写全部缺陷报告

48，缺陷报告的内容有哪些？

• 缺陷标题（或者说缺陷摘要、缺陷概述、缺陷的基本信息）：在什么界面，做了什么操作，出现的什么结果
• 预处理
• 复现步骤（完整简洁1,2,3,）
• 预期结果
• 实际结果
• 严重程度
• 优先级
• 测试环境（硬件环境、操作系统、版本、软件环境、中英文）
• 测试执行人
• 注释

49，缺陷报告的组织结构有哪些？

• 缺陷标题（或者说缺陷摘要、缺陷概述、缺陷的基本信息）：在什么界面，做了什么操作，出现的什么结果
• 预处理
• 复现步骤（完整简洁1,2,3,）
• 预期结果
• 实际结果
• 严重程度
• 优先级
• 测试环境（硬件环境、操作系统、版本、软件环境、中英文）
• 测试执行人
• 注释

50，缺陷报告的写作需要注意什么问题？

• 不要使用你、我、他等字眼，不要使用情绪化的语言和强调符号，不要使用‘似乎’看上去、可能等不确定性内容、不要使用认为比较幽默的内容，不要使用不确定的测试问题（不确定是否是缺陷），不要人身攻击

51，简述缺陷报告的处理流程？

• 软件测试人员提交缺陷报告
• 测试负责人审核以后将缺陷报告分配给相关开发人员修改
• 缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测
• 返测通过的缺陷报告由负责人关闭
• 返测为通过的缺陷报告直接返回开发人员重新修改，然后再由测试人员进行返测，直到测试和开发达成一致的处理意见

51，简述缺陷的生命周期？

• 软件测试人员提交缺陷报告
• 测试负责人审核以后将缺陷报告分配给相关开发人员修改
• 缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测
• 返测通过的缺陷报告由负责人关闭
• 返测为通过的缺陷报告直接返回开发人员重新修改，然后再由测试人员进行返测，直到测试和开发达成一致的处理意见

52，简述重复缺陷、正常缺陷、无效缺陷、验证不通过缺陷。描述不清楚缺陷的处理流程

• 正常缺陷的处理流程：提交缺陷—分配缺陷—开发打开缺陷—修改缺陷–返测缺陷–通过关闭缺陷
• 重复缺陷的处理流程：测试提交缺陷—分配缺陷—是重复缺陷—视为无效缺陷
• 验证不通过缺陷：提交缺陷—分配缺陷—开发打开缺陷—修改缺陷–返测缺陷—没有修改好—重新提交缺陷
• 描述不清楚缺陷 处理流程：提交缺陷—开发打开缺陷但是看不懂—视为无效缺陷

53，缺陷按照严重程度可以分为哪些类型？

• 致命缺陷（系统瘫痪、异常退出、死循环、严重的计算错误）
• 严重缺陷（频繁死机、不部分功能不能使用）
• 一般缺陷（功能点没有实现、不符合用户需求、导致数据丢失）
• 较小错误（影响一个相对独立的功能、仅仅发生在特定条件上、与需求定义不一致、断断续续出问题）
• 意见建议（表面性错误，如错别字）

54，缺陷按照优先级可以分类哪些类型

• 缺陷必须立即解决
• 缺陷需要正常排队等待修复或列入软件发布清单
• 缺陷可以在方便时被纠正
• 下一个版本修改
• 不修复

55，缺陷的状态有哪些？

• 提交-----测试人员提交了一个缺陷给程序员
• 打开-----待处理
• 拒绝-----程序员认为不是缺陷或者重复，就可以修改状态为拒绝
• 修改-----程序员修复缺陷后提交的一个状态
• 关闭/已验证-----测试人员经过回归测试后，认为此缺陷已经解决，将其关闭
• 推迟-----可以放在后续的版本解决的问题，但是要详细写出修复的日期或者是版本

56，测试有哪些级别？或者测试有哪些阶段？

• 单元测试
• 集成测试
• 系统测试
• 验收测试

57，什么是单元测试？单元测试由谁来做？

• 针对一个软件单元的测试
• 一般是有开发人员或者懂测试的开发人员（白盒测试）

58，什么是桩模块、驱动模块？

• 桩模块：被 被测模块 调用的模块
• 驱动模块：调用被测模块的模块

59，什么时候可以进行组件测试、单元测试、类测试？

• 完成编译的测试对象，测试环境，开发工具测试对象的规范说明书

60，单元测试使用的技术是什么？测试重点是什么？测试条件是什么

• 技术：黑盒白盒技术，但是白盒居多，黑盒居少，一般先做黑盒在做白盒
• 重点：功能性测试、健壮性（逆向测试、无效性）、性能
• 前提条件：完成编译的测试对象。测试环境 、开发工具、测试对象的规范说明书

61，什么是集成测试？

• 组件间的接口与交互测试

62，集成测试的测试重点是什么？测试条件是什么？使用什么技术？

• 测试重点 ：接口和系统内不同部分的相互作用（交互）
• 测试条件：是完成集成的被测系统，测试台，有关组件间的交互的文档
• 测试技术：包括白盒测试、黑盒测试，白盒居多，黑盒居少，对比单元测试，白盒下线，一般是先做黑盒再做白盒

63，集成测试有哪些策略？

• 自顶向下集成
• 字底向上集成

64，什么是系统测试？

• 对于整个系统能不能满足用户需求的测试

65，系统测试的目的是什么？

• 检查软件是否满足需求

66，测试与调试的区别是什么

• 测

65，系统测试能够发现哪些缺陷？会遗留哪些缺陷？

• 发现：非功能性缺陷，设计整个系统的问题
• 遗漏：对用户的需求的错误理解，没有实现或者没有完全实现用户的隐性需求

66，什么是验收测试？

• 一般由用户/客户进行的确认是否可以接受一个系统的验证性测试，验收测试是根据用户的需求，业务流程进行的正式测试以确保系统符合所有的验收准则

67，验收测试由哪些人进行？

• 客户或者测试，测试人员可以介入

68，验收测试的目的是什么？

• 对系统或者子系统建立信心，对系统非功能性的特性赢得信任

69，什么是alpha、beta测试?有什么区别？

• Alpha测试：潜在的客户/用户在开发场地进行测试，内测版（alpha）内部交流版本：可能存在很多bug，不建议用户安装

• Beta：有潜在客户/用户在自己的环境下测试的软件系统，公测版（beta）面向所有的用户，通过用户的反馈再去修改细节

70，什么是维护测试？

• 软件正常使用后，对软件的变更、更新进行测试

71，什么是性能测试？负载测试？压力测试？有什么区别？

• 性能测试：表现处理速度、响应时间、CPU使用、内存使用、硬盘使用等
• 负载测试：通过不断的增加负载来测试一下系统的性能（找到最优的负载量）
• 压力测试：通过增加负载超过系统正常工作能力来考察系统能否在异常的情况下正常工作

72，什么是功能测试？

• 测试一个软件能做什么，是不是做了应该做的，没做不该做的工作

73，什么是结构测试？

• 白盒测试也称结构测试、逻辑驱动测试、基于程序本身的测试，是对程序结构进行的测试

74，什么是与变更相关的测试？有哪些具体的类型？

• 与变更相关的测试是对修改过的程序进行的测试
• 确认测试（再测试）和回归测试

75，什么是静态测试？动态测试？如何区分二者？

• 静态测试：不执行程序的测试，针对文档和不需要执行的代码
• 动态测试：需要执行程序，方法一般采用黑盒测试方法和白盒测试方法

76，圈复杂度怎么计算

• 不重叠的闭合环数+1

77，什么是黑盒测试？白盒测试？

• 黑盒测试：也称功能测试，基于规格说明书的测试，关注输入数据到程序中，输出结果是否正确，侧重于测试软件能做什么
• 白盒测试：也称结构测试，逻辑驱动测试，是对程序内部逻辑结构进行的测试

78，白盒测试有哪些方法？具体解释每种方法？

• 白盒测试主要使用逻辑覆盖方法，包括语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖、路径覆盖等
• 语句覆盖：程序中的每个可执行语句至少被执行一次，能发现语句错误，但不能发现逻辑错误
• 判定覆盖：也称分支覆盖，程序中的每个判定的取真分支和假分支 至少执行一次，能发现逻辑错误，但不能发现组合判断中的条件错误
• 条件覆盖：程序每个判定中每个条件的可能取值至少满足一次，能发现条件错误，但不能发现逻辑错误
• 判定-条件覆盖：每个条件中的所有可能取值至少执行一次，同时，每个判定的可能结果至少被执行一次
• 条件组合覆盖：每个判定中所有的条件取值组合至少执行一次
• 路径覆盖：用例覆盖程序中的所有可能的执行路径，如果路径很多，会变得不切实际

79，什么是配置测试？

• 不同配置环境下进行测试

80，什么是文档测试？

• 不仅包括测试文档校队，还有文档和软件的不一致、安装说明书、使用说明书等等

81，测试用例的内容是什么？

• 用例编号，测试概述或者用例标题、测试步骤、预期结果、输入数据、优先级、前置条件等

82，测试用例有哪些元素？

• 用例编号、测试概述或者用例标题、测试步骤、预期结果、输入数据、优先级、前置条件等
• 测

83，什么是UI/GUI/UI测试什么意思

• 界面
• 图形界面
• 界面测试

84，测试用例的优先级如何

• 冒烟测试
• 高：重要功能，重要错误
• 中：一般功能，一般错误
• 低：较低

85，解释测试目标、测试环境、测试对象、前置条件、测试策略、测试范围的含义

• 测试目标：功能测试、性能测试‘、界面测试、易用性测试、兼容性测试、安全性测试
• 测试策略：某类别的测试的过程、方法、以及方法如何应用，测试的注意事项等
• 测试环境：硬件环境、软件环境、网络环境
• 前置条件：进行某些测试工作需要做好的准备条件
• 测试范围：软件需要测试的某个部位

86，用例评审一般使用什么方式？哪些人参与

• 检查单，一般由测试人员进行

87，测试计划由谁编写？测试需求说明书是由谁编写的？测试用例是由谁编写的？测试总结谁写？

• 测试负责人
• 测试人员（测试需求分析人员）
• 测试人员（测试设计工程师）
• 测试负责人

88，软件投入运行后还需要测试吗？需要哪些测试？

• 需要测试
• 维护测试（升级测试）、数据迁移测试、备份恢复测试、灾难恢复测试等

89，SP2是什么意思？

• 第2个版本的服务包或补丁包

90，给你一个网站，你如何测试？

• 首先，查找需求说明书、或者是这个网站的相关设计文档，来分析测试需求
• 制定测试计划，确定测试范围和测试策略（功能测试、界面测试、性能测试、数据库测试、安全性测试、兼容性测试）
• 设计测试用例
  • 功能性测试
    - 链接测试：检查链接是否能够正常跳转，是否存在空页面和无效页面，跳转的连接是否有不正确的出错信息返回
    - 提交的功能测试（登录或者注册）
    - 图片、视频等是否可以正常加载和显示
    - 多语言支持是否能够正确显示选择的语言等
  • 界面测试
    - 页面的风格是否统一、美观
    - 页面的布局是否合理，重点内容和热点内容是否突出
    - 控件是否能够正常使用
    - 对于必须安装的软件，是否提供自动下载并安装的功能
    - 文字检测
  • 性能测试
    - 负载测试
    - 压力测试
  • 数据库测试
    - 数据库一般需要考虑连接性，对数据的存取操作，数据内容的验证等方面
  • 安全性测试
    - 基本的登录功能的检查
    - 是否存在溢出错误，导致系统崩溃或者权限泄露
    - 相关开发语言的常见安全性问题的检查，例如sql注入等等
  • 兼容性测试，根据需求说明书的内容，确定支持的平台组合
    - 浏览器的兼容性
    - 操作系统的兼容性
    - 软件平台的兼容性（其他软件有冲突）
    - 数据库的兼容性（网站读取的数据库发生了改变，还能不能操作）
• 开展测试，并记录缺陷
  • 合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如：需求的变更、风险、配置、测试文档、缺陷报告、人力资源等内容）
• 定期评审，对测试进行评估和总结，调整测试的内容

91，一台客户端有300个客户和三百个客户端有300客户对服务器施压，有什么区别？

• 300个客户在一个客户端上
  - 会占用客户机更多的资源，而影响测试的结果，线程之间可能会发生干扰，而产生的一些异常
  - 需要更大的带宽
  - IP地址的问题，可能需要IP期骗来绕过服务器对单一的IP地址最大连接数的限制
  - 不必考虑分布式管理的问题
• 用户分布在不同的客户端上
  - 需要考虑使用控制器来整体调配不同客户机上的用户
  - 需要给予相应的权限配置和防火墙设置

92，目前的主要的测试用例设计方法是什么？

• 白盒测试：可以分为逻辑覆盖（语句覆盖、条件覆盖、分支覆盖、条件判定覆盖、多条件组合覆盖）和基本路径覆盖
  • 逻辑覆盖： 是指对于我们程序当中比如说顺序语句、分支语句、循环语句进行测试
  • 基本路径覆盖： 是指对于我们程序当中的通道、通路走的每一条道进行用例覆盖
  • 语句覆盖：对程序当中的所有顺序语句都要执行一遍，如果写了100行代码，都要保证这100行代码执行成功
  • 条件覆盖：是指程序当中写了if语句也好，where 循环 for循环都是有条件 ，比如说大于小于不等于等等，条件是指我们的这个小条件（大于、小于、不等于）让它真一次或者假一次，来去执行
  • 判定覆盖：在程序中有好几个小条件and /or合成一个大条件的时候，让这个大条件真一次或者假一次，如果只有一个条件的话判定覆盖和条件覆盖就是一样的了，也叫分支覆盖
  • 条件-判定覆盖： 是指这个大条件真一次，假一次，每个小条件也要真一次，假一次
  • 多条件组合覆盖：相对应的一起用的小条件，条件1 and 条件2，当条件1真的时候相对应的条件2要真一次或者假一次，当条件1假的时候相对应的条件2要真一次或者假一次
• 黑盒测试
  • 测试大纲法：把软件当中所有的功能按照从大到小罗列出来，一般是来做功能拆分的。这样会有利于我们把握整个软件的组成部分
  • 场景法：主要用来测试业务流程，分为基本流（正确流程）和备选流（错误流程）
  • 等价类划分：确定有效等价类和无效等价类，有效等价类划分（题目的条件，还要注意边界值（极值）中间在随意找个值），有效等价类划分（题目的条件，还要注意边界值（极值）中间在随意找个值），两个框一个要正确，一个要错误，这样才能准确判断
    • 一定要根据需求来判断预期结果
      等价类划细节----总结问题：
      1，考虑输入长度
      2，考虑输入的类型
      3，组成规则
      4，是否为空
      5，是否区分大小写
      6，是否重复
      7，是否去除空格
• 边界值方法：我们在测试的过程中，一定要小心边界值（极值），因为在程序中这些边界值最容易出问题
  具体的测试用例书写思路：
  找到边界值和两端的值，分别进行测试
  例如：0-100之间的整数 就测 -1 0 1 99 100 101
  总结：
  • 边界值思想应该是选到边界和刚刚超过的值，来进行测试，要根据实际情况来选择
  • 边界值和等价类是相辅相成的关系，是配合来是使用的
• 因果图：
  • 因：输入条件
  • 果：输出条件
    适用于输入条件之间有相互制约，相互依赖的的情况
    因果中的符号：
    1，恒等--------有因就有果，没有因就没有果
    2，非-----------有因没有果，没有因有果
    3，或-----------条件有一个是真，结果就是真；条件都是假，结果才是假
    4，且（与）----条件都为真，结果才是真，一个条件为假，结果就是假
• 判定表
  • 根据因果图来制作判定表（因果图可以不画）
    组成部分：
    1，条件桩：所有条件
    2，动作桩：所有结果
    3，条件项：针对条件桩的取值
    4，动作项：针对动作桩的取值
    书写步骤：
    1，列出所有条件和动作桩
    2，填写条件和动作桩的所有项目
    3，简化判定表
    注意：如果出现“-”代表此选项不影响最终结果
• 流程法
  • 适用于有先后顺序的测试，常用于业务流程、安装流程等等，每个流程都是一条测试用例，它只是在测试整体流程是否正确，细节还需要使用等价类、边界值等方法进行完善
• 错误推断法
  • 凭直觉和经验来设计测试用例，它是根据之前的项目相关的bug数据总结出来的
• 正交表
  • 从全面试验中挑选出有代表性的点进行测试（均匀分散，整齐可比）
    高效率、快速、经济
    使用方法：
    1，根据控件和取值数选择一个合适正交表
    2，列举取值并编号，生成取值表
    3，按取值表与选择的正交表进行映射
    正交表的生成工具：
    1，制作取值表（只列出数据即可，不用编号）
    2，复制取值表的数据，放到文本文档中保存（注意不要更改任何格式，例如文件叫text2.txt）、
    3，把文本文档放在allpairs文件夹中
    4，win+r 输入cmd 进入控制台
    5，使用控制台代码进入allpairs文件夹中（cd 路径）
    6，在控制台中输入allpairs.exe text2.txt>chenggong.txt（chenggong.txt是自己起的名字）

93，测试用例方法的选择？

• 如果测试功能和流程的话，要使用场景法
• 需要输入数据的地方，我们要使用等价类划分法，要注意配合边界值方法来做详细的测试
• 如果有条件组合的情况，我们要使用因果图制作出判定表
• 配置类软件，组合比较多，我们要使用正交表来科学的选择测试用例
• 如果没有达到覆盖标准，就要增加一些测试用例
• 依靠经验追加一些测试用例(错误推断法)
• 每个需求都是一个测试点，一个测试点一天测试用例（工作总结出来的）
• 测

94，测试人员在软件开发过程中的任务是什么？

• 尽可能早的找出系统中BUG
• 避免软件开发过程中缺陷的出现
• 衡量软件的品质，保证系统的质量
• 关注用户的需求，并保证系统符合用户需求

95，如何测试一个纸杯？

• 功能：用纸杯装水看漏不漏，水能不能被喝到
• 安全性：被子有没有毒或者细菌
• 可靠性：杯子从不同的高度落下的损坏程度
• 可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
• 兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
• 易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
• 用户文档：使用手册是否有对杯子的用法、限制、使用条件等有详细的描述
• 疲劳测试：将杯子盛水放24小时检查泄露时间和情况，盛汽油放上24小时看看
• 压力测试：用跟针在上面不断的加重量，看压强多大时候会穿透

96，测试计划编写的六要素？

• why——为什么要进行这些测试
• what—测试哪些方面，不同阶段的工作内容
• when—测试不同阶段的起止时间
• where—相应文档，缺陷的存放位置，测试环境等
• who—项目有关人员组成，安排哪些测试人员进行测试
• how—如何去做，使用哪些测试工具以及测试方法进行测试。

97，编写测试计划的目的是是什么？

• 使测试工作顺利进行；使项目参与人员沟通更舒畅；使测试工作更加系统化

98，您认为在测试人员开发人员在沟通的过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？

• 尽量的面对面沟通，其次是能直接通过电话沟通，必须要对沟通的主题理解深刻以及表达清楚
• 运用一些测试管理工具进行管理也是有效的办法，同时要注意在工具中对BUG有准确的描述
• 真诚、团队精神、在专业上要有共同的语言，对事不对人，工作至上

99，你为什么要做测试？

• 我觉得这是一个很有挑战的工作，而且测试是一个经验行业，工作越久越可以感觉到做好测试的难度和乐趣，可以通过自己的工作，能够使软件产品越来越完善，并且能够从中体会到乐趣
• 测

100，一个好的测试用例，有哪些特点？

• 用例要完整（至少含有编号、标题、操作步骤和预期结果）
• 用例要表名测试目的
• 用例覆盖程度要高
• 用例能够使工作量最小化
• 用例描述正确、规范（含有正确的、规范的测试标题和编号）
• 用例的分类以及描述要足够的清晰
• 用例要具有可测试性
• 测试用例易于维护
• 可复用性
• 可重复性（不管是谁执行此用例，结果谁都一样）
• 可追踪性（用例能够追踪到一个具体的需求）

101，测试的结束标准是什么？

• 全部测试用例都执行完成
• 为修改的bug都被确认或置为应有的状态，暂缓修改的问题都有详尽的解释
• 测试报告编写完成
• 测试收尾工作结束
• 测试总结完成
• 项目处于试运行或上线阶段
• 在测试计划中定义结束的标准
  • 如计划中规定，系统在一定的性能下平稳运行72小时，本版本中没有严重bug，普通的bug的数量在3个一下，bug的修复率在90%以上
  • 实际测试达到上述要求，然后有开发经理，测试经理，项目经理共同签字，认同测试结束，版本即可发布

102，一个身份证号码输入框，怎么设计用例？

• 校验身份证号规则的有效性（包括地址码、生日期码、顺序码和校验码
  校验 15 位身份证号和 18 位身份正好都是可用的
  校验末位是 X 的情况
  校验不足 15 位、16-17 位和大于 18 位的情况
  如果是必输项，校验不输入的时候会不会有正确的提示
  如果不是必输项，则要校验不输入的时候流程能否正常进行
  校验输入非数字的情况，是否会有正确提示信息（包括大小写字母、汉字、特殊字符和标点符号）
  校验输入全角的数字的时候，系统是否会识别（这个得根据需求确定是否可以使用全角的数字）

103，.登录功能怎么设计测试用例？

• 功能测试(Function Test)
  1、输入正确的账号和密码，点击提交按钮，验证是否能正确登录。（正常输入）
  2、输入错误的账号或者密码, 验证登录会失败，并且提示相应的错误信息。（错误校验）
  3、登录成功后能否跳转到正确的页面（低）
  4、账号和密码，如果太短或者太长，应该怎么处理（安全性，密码太短时是否有提示）
  5、账号和密码，中有特殊字符（比如空格），和其他非英文的情况（是否做了过滤）
  6、记住账号的功能
  7、登录失败后，不能记录密码的功能
  8、账号和密码前后有空格的处理
  9、密码是否加密显示（星号圆点等）
  10、牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按
  钮是否好用
  11、登录页面中的注册、忘记密码，登出用另一帐号登录等链接是否正确
  12、输入密码的时候，大写键盘开启的时候要有提示信息。
  13、什么都不输入，点击提交按钮，看提示信息。（非空检查）
• 界面测试(UI Test)
  1、布局是否合理，2 个 Testbox 和一个按钮是否对齐
  2、Testbox 和按钮的长度，高度是否符合要求
  3、界面的设计风格是否与 UI 的设计风格统一
  4、界面中的文字简洁易懂，没有错别字。
• 性能测试(Performance Test)
  1、打开登录页面，需要几秒
  2 、输入正确的账号和密码后，登录成功跳转到新页面，不超过 5 秒
  安全性测试(Security Test)
  1、登录成功后生成的 Cookie 是否有 HttpOnly(降低脚本盗取风险) 2、账号和密码是否通过加密的方式，发送给 Web 服务器
  3、账号和密码的验证，应该是用服务器端验证，而不能单单是在客户端用 javaScript 验证
  4、账号和密码的输入框，应该屏蔽 SQL 注入攻击
  5、账号和密码的输入框，应该禁止输入脚本（防止 XSS 攻击）
  6、错误登录的次数限制（防止暴力破解）
  7、考虑是否支持多用户在同一机器上登录；
  8、考虑一用户在多台机器上登录
• 可用性测试(Usability Test)
  1、是否可以全用键盘操作，是否有快捷键
  2、输入账号，密码后按回车，是否可以登录
  3、输入框是否可以以 Tab 键切换
• 兼容性测试（Compatibility Test） 1、主流的浏览器下能否显示正常已经功能正常（IE6~11, FireFox, Chrome, Safari 等 ） 2、不同的平台是否能正常工作，比如 Windows, Mac
• 3、移动设备上是否正常工作，比如 iPhone, Android
  4、不同的分辨率
  本地化测试 （Localization Test） 1、不同语言环境下，页面的显示是否正确。
  软件辅助性测试 （Accessibility Test）
  软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能
  1、高对比度下能否显示正常（视力不好的人使用）

104，请查询出$_dept表中区域（region_id）为1,3的部门信息？

• select * from $_dept where region_id in(‘1’,‘3’)

105，请查询出s_emp 表中工资(salary)在1500到2000之间的员工？

• select * from s_emp where salary between 1500 and 2000

106，请查询出s_emp 表中姓名（name）中含有字母a的员工信息？

• select * from s_emp where name like ‘%a%’

107，请从contastr保单表和poliy_prem费用表中查询出满足一下的条件的保单：费用表的fee_type=24,fee_status=0,且due_time日期小于2012年10月29日，保单表中的organ_id以111开头的supend=‘N’,两张表用policy_id关联

• select * from contastr as c inner join poliy_prem as p on c.policy_id=p.policy_id where fee_type=24 and fee_status=0 and due_time<‘2012/10/29’ and organ_id like ‘111%’ supend=‘N’

108，软件测试项目从什么时候开始，为什么？

• 软件测试应该在需求分析阶段就介入，因为测试的对象不仅仅是程序编码，应该对软件开发过程中产生的所有产品都进行测试，并且软件缺陷存在方法趋势，缺陷发现的越晚，修复所花费的成本就越大

109，怎么理解回归测试？

• 回归测试有两类：用例回归和错误回归
• 用例回归：是指一段时间以后再回头对以前使用过的用例在重新进行测试，看看会不会重新发现问题
• 错误回归：就是在新版本中，对以前版本中出现并修复的缺陷进行再次验证，以缺陷为核心，想相关修改的方法进行测试方法

110，什么是BS架构，什么是CS架构？

• BS 是浏览器/服务器架构，需要通用客户端，主要压力在服务器
• CS 是客户端/服务器结构，需要专用客户端，客户端需要承担一部分工作和压力

111，什么是面向对象思想？

• 以数据为核心
• 将问题分解为不同的事物或类和对象，考虑类和对象的特征和行为
• 编程时，创建类，类包含属性和方法，属性反映所有对象的共同特征，方法反映所有对象的公共行为
• 创建对象，调用方法