1 、软件的含义
程序、数据及相关文档的完整集合。
2、测试与调试的区别是什么？
测试是由测试人员来进行，主要目标是发现、报告和跟踪缺陷。
调试是由开发人员进行，主要目标是定位缺陷位置，分析缺陷原因，修复缺陷。
3、 软件测试的含义
简单讲，软件测试是发现缺陷的过程；IEEE 中的定义是，软件测试是使用人工或自动手段来运行或测定某个系统的过程，目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
4、软件测试的目的
（1） 验证软件是否满足各类文档说明书等规定的软件质量要求
（2） 找出软件缺陷
（3） 为软件产品的质量测量和评价提供依据
（4） 帮助开发改进开发流程
5、 什么是功能、性能、兼容性
功能代表一个软件能做什么；性能反映软件运行的速度或效率、占用资源的多少等指标；兼容性表示一个软件与其所在运行环境的依赖程度，包括与硬件、操作平台、其他软件的依赖。
6、 测试分为哪几个阶段？每个阶段的测试目的是什么？
测试分为单元测试、集成测试、系统测试、验收测试四个阶段。前三个阶段的目的是尽可能多的发现缺陷，而验收测试是要验证软件满足了用户需求，帮助用户建立系统可以正常使用的信心，发现缺陷不是此阶段的目标。
7、 如果测试提交的缺陷开发人员不认可，该怎么办？
首先分析或与开发沟通开发不认可的原因。
如果拒绝原因是提交的不是缺陷，而且自己分析后，的确不是缺陷，则应该注意以后再做测试时要做好复现，认真研读需求，提高自己找缺陷的能力。
如果拒绝原因是提交的不是缺陷 但自己分析时认为缺陷应该是存在的，则再次研读需求并做好复现，拿出确实是缺陷的证据，然后与开发沟通。
如果拒绝原因是认可缺陷，但不予修复，如果自己觉得必须修复，则拿出充分理由和证据和不修复的不利影响和影响范围，再与开发沟通。
注意沟通技巧，合理的论述，向开发说明自己的判断的理由，注意客观、严谨，不掺杂个人情绪。
把问题交给测试经理，等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并由上级做出决定。
8、什么是软件开发生命周期
从软件最初构思到公开发行的过程。瀑布模型的过程是计划、需求、设计、编码、测试、运行、维护循环。
瀑布模型有严格的开发步骤，每个阶段是按顺序进行的，每个阶段都必须编写完整的文档，每个阶段完成后必须经过审查才能进入下一步。
瀑布模型不能迭代、不能反复；测试在编码之后，测试太晚；测试的只是程序。
9、 软件开发有什么模型？软件测试主要有哪些模型？
软件开发模型：大爆炸模型、边写边改模型、瀑布模型、螺旋模型、敏捷开发模型软件测试模型：V 模型、W 模型、H 模型、X 模型、前置测试模型、敏捷测试模型
10、简述V 模型。
V 模型的过程：用户需求→需求分析→概要设计→详细设计→编码→单元测试→集成测试→系统测试→验收测试。
优点：
（1）V 的左端表示传统的瀑布开发模型，V 的右端明确地将测试分为不同的级别或阶段，测试过程更为具体；
（2）测试各个阶段和开发的各个阶段相对应；
（3）V 模型的测试策略包括低层测试和高层测试，低层测试是为了源代码的正确性，高层测试是为了整个系统满足用户的需求。
缺点：
（1） 测试的对象就是程序本身。忽视了测试活动对需求分析，系统设计等活动的验证和确认的功能，直到后期的验收测试才被发现。
（2） 测试是开发之后的一个阶段。实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。
11、简述W模型。
W 模型的过程：左边 V 是需求分析→概要设计→详细设计→编码实现→模块集成→系统构建→系统安装；右边 V 是需求测试→概要设计测试→详细设计测试→单元测试→集成测试→系统测试→验收测试。
优点：
（1）W 模型体现了尽早和不断测试的原则，既强调测试方案设计，也强调测试执行。
（2） 左侧 V 是开发，右侧 V 是与开发并行的测试，相对于 V 模型，W 模型增加了软件各开发阶段中应同步进行的验证和确认活动，W 明确表示出了测试与开发的并行关系。测试与开发是同步进行的，有利于尽早地全面的发现问题。
（3） 测试伴随整个软件开发周期，且测试的对象不仅仅是程序，需求、设计等同样要测试。
缺点：
在 W 模型中，需求、设计、编码等活动被视为串行的，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型，不利于当前软件开发复杂多变的情况。
12、简述H模型。
H 模型将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。H 模型的测试流程是只要测试准备工作完成，达到测试就绪点，测试就可以执行了。
优点：
（1） 软件测试不仅仅指测试的执行，还包括很多其他的活动。
（2） 软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
（3）H 模型反映出软件测试要尽早准备，尽早执行。
（4）软件测试可以进行迭代、反复进行。
13、敏捷开发
敏捷开发的核心思想是：以人为本，适应变化。具体讲：
（1） 认为个体和交互重于过程和工具，强调通过过程和工具理解个人和交流的作用；
（2） 认为可用软件重于完备文档，强调通过全面的文档理解运行的软件；
（3） 认为客户协作重于合同谈判，强调通过合同和谈判得到客户的协作；
（4） 认为响应变化重于遵循计划，强调在计划的执行中做出对变更的响应。特点：
（1） 敏捷开发提倡迭代式和增量式的开发模式，并强调测试在其中的重要作用。
（2） 敏捷开发是以用户为中心、以客户需求为导向的开发过程，在此过程中随时做好 “迎接变化”的准备，客户是敏捷的关键环节。
（3） 敏捷开发没有单一固定的开发方法或过程，敏捷开发有三个共同点：依赖客户的参与、测试驱动以及紧凑的迭代开发周期。
14、敏捷测试
（1） 敏捷测试是协同测试的一种形式，程序员结对编程，程序员分饰测试员角色，敏捷测试是连续测试。
（2） 敏捷测试侧重单元测试和验收测试。单元测试的过程是先设计单元测试用例，然后进行编码，之后执行测试。
（3） 敏捷测试强调客户参与，单元测试通过之后代码集成到代码库中，再由客户进行验收测试，验收测试的结论反馈给开发人员，缺陷得以迅速修复。
15、软件质量要求有哪些？
功能要求和非功能要求。
16、软件非功能要求有哪些？
性能要求（负载测试、压力测试、容量测试、可靠性测试）、界面测试、兼容性测试、易用性测试、文档测试、可用性测试、安装测试、安全测试、灾难恢复测试等。
17、简述测试的基本过程
（1） 测试人员进行测试需求分析。
（2） 测试负责人编写测试计划。
（3） 测试人员根据测试需求分析设计和编写测试用例。
（4） 测试人员搭建测试环境、创建测试数据、执行测试用例、提交缺陷报告并进行跟踪、记录测试事件。
（5） 进行测试评估和总结。
每一分步工作完成后都进行评审。
18、拿到一个软件后，应该怎样开始工作？
编写需求分析并评审→编写测试计划并评审→设计测试用例并评审→搭建测试环境、执行测试用例、提交缺陷报告→进行评估和总结
19、怎么做测试？
编写需求分析并评审→编写测试计划并评审→设计测试用例并评审→搭建测试环境、执行测试用例、提交缺陷报告→进行评估和总结
20、简介测试流程
编写需求分析并评审→编写测试计划并评审→设计测试用例并评审→搭建测试环境、执行测试用例、提交缺陷报告→进行评估和总结。
21、怎么进行测试需求分析？
（1） 收集各类文档，仔细阅读文档，提出问题，分析问题或沟通解决，整理需求信息。
（2） 编写测试需求分析说明书：功能分解，编写检查点和测试点。
（3） 需求评审。
22、拿到项目后，需要分析或咨询软件哪些方面的问题？
软件主要的功能、流程、开发环境（开发语言<含数据类型>、数据库、中间件）、运行环境（硬件、软件、网络、软件架构）、用户群、测试范围、测试优先级。
23、什么时候提交发现的缺陷？
测试执行发现缺陷时立即提交缺陷。
24、什么是入口准则、出口准则？
入口准则是进行一项测试工作前需要准备好的前提条件。出口准则是一项测试工作可以结束的前提条件。
25、什么是测试策略？什么是测试范围？
测试策略主要指如何进行某种测试（如功能测试、性能测试、兼容性测试、可用性测试、易用性测试等），用于说明测试方法以及如何使用测试方法。测试范围有时候等价于测试策略，有时候可以表示要进行测试的某个软件部位。
26、什么是BVT冒烟测试？版本验证测试？怎么测？
也称冒烟测试、版本验证测试、小版本验证测试、版本构建测试。冒烟测试用例是一组想先运行以确定这个给出的小版本是否可以测试的测试用例。冒烟测试主要测试软件的基本功能，以判断整个软件值不值得进行大规模测试。通常由一个人进行 1-2 小时的测试，一般不测试次要功能和各种错误。
27、测试计划的内容和目的是什么？
包含了产品概述、测试区域/测试策略/测试范围/测试目标（测试项、被测特征）、测试配置/测试资源、测试周期、进度安排（测试任务、人员安排）、测试方法/途径、测试交流、风险分析等内容。目的是指导测试过程，规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的责任人以及与计划相关的风险。
28、怎么判断是不是软件缺陷？
（1） 软件未达到产品说明书标明的功能；
（2） 软件出现了产品说明书指明不会出现的错误；
（3） 软件功能超出产品说明书指明范围；
（4） 软件未达到产品说明书虽未指出但应达到的目标；
（5） 软件测试员具体问题具体分析，认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
29、缺陷的产生主要有哪些原因？最主要的原因是什么？
需求频繁变更、沟通不良、不了解客户的需求、实现新功能或很酷的功能、追求新技术、项目期限的压力、需求分析或设计投入的时间和精力不够、产品的复杂度、开发人员疲劳、压力过大或受到干扰、缺乏足够的知识、技能和经验、缺乏动力等。
最主要的原因：需求方面的原因
30、当你发现一个缺陷时，应该怎么确认的确是一个缺陷？
根据缺陷的判断原则来甄别发现的问题是不是一个缺陷，发现缺陷后，应该做好分离和再现（3 次），然后才能提交。
31、在正式提交一个缺陷前，你应该做些什么？
分离缺陷、再现缺陷（3 次），然后才能提交。
32、怎么处理无法再现的缺陷？
首先，应当对这样的缺陷进行详细的记录，并尽快提交给开发人员。
其次，对于寻找难以再现的缺陷要合理地安排时间，对一时难以再现的缺陷可以暂时搁置，以保证项目的正常进度。
最后，在测试过程中对未再现缺陷予以关注。
33、什么是重复缺陷？怎么避免重复缺陷？
提交了一个缺陷库中存在或者开发人员已经知道的缺陷。
1、如果缺陷是跟同事提交的重复，任务分工解决，也可以在提交之前查询下库缺陷是否存在。
2、如果缺陷是与自己提交的缺陷重复，则需要提高发现缺陷的能力，通过提高开发能力来理解两个缺陷本质上是一个缺陷。
34、什么是无效缺陷？怎么避免无效缺陷？
提交的缺陷不是真正的缺陷。
充分了解需求、提高自己识别缺陷的能力、提高缺陷写作能力
35、缺陷报告的写作准则是什么？
Correct（准确）：每个组成部分的描述准确，不会引起误解； Clear（清晰）：每个组成部分的描述清晰，易于理解；
Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容； Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息； Consistent（一致）：按照一致的格式书写全部缺陷报告。
36、缺陷报告的内容有哪些？
缺陷标题（或者说缺陷摘要、缺陷概述、缺陷基本信息）预处理
复现步骤预期结果实际结果严重程度优先级 测试环境测试版本
测试执行人注释
37、缺陷报告的组织结构是什么？
缺陷标题（或者说缺陷摘要、缺陷概述、缺陷基本信息）预处理
复现步骤预期结果实际结果严重程度优先级 测试环境测试版本
测试执行人注释
38、缺陷报告的写作需要注意什么问题？
不要使用我、你、他等字眼，不要使用情绪化的语言和强调符号、不要使用“似乎”、看上去可能等不确定性内容、不要使用认为比较幽默的内容、不要使用不确定的测试问题(不确定是否是缺陷)、不要人身攻击。
39、简述缺陷报告的处理流程
软件测试人员提交缺陷报告；
测试负责人审核后将缺陷报告分配给相关的开发人员修改； 缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测返测通过的缺陷报告由负责人关闭；
返测未通过的缺陷报告直接返回开发人员重新修改，然后再由测试人员返测，直到测试和开发达成一致处理意见。
40、简述缺陷的生命周期
软件测试人员提交缺陷报告；
测试负责人审核后将缺陷报告分配给相关的开发人员修改； 缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测返测通过的缺陷报告由负责人关闭；
返测未通过的缺陷报告直接返回开发人员重新修改，然后再由测试人员返测，直到测试和开发达成一致处理意见。
41、简述重复缺陷的处理流程
提交缺陷→分配缺陷→是重复缺陷→置为无效缺陷。
42、缺陷按照严重程度可以分为哪些类型？
致命缺陷、严重缺陷、一般缺陷、较小错误、意见建议等
43、缺陷按照优先级可以分为哪些类型？
缺陷必须立即解决；
缺陷需要正常排队等待修复或列入软件发布清单；缺陷可以在方便时被纠正；
下一个版本修复；不修复。
44、缺陷的状态有哪些？
新建/已提交打开
已拒绝
已解决/已修复已验证
已关闭
45、测试有哪些级别？
单元测试、集成测试、系统测试、验收测试
46、测试有哪些阶段？
单元测试、集成测试、系统测试、验收测试
47、什么是单元测试？单元测试谁来做？
针对一个软件单元的测试。开发人员或懂开发的测试人员
48、什么是桩模块、驱动模块？
桩模块：被被测模块调用的模块。驱动模块：调用被测模块的模块。
49、什么时候可以进行组件测试？
完成编译的测试对象，测试环境，开发工具，测试对象的规范说明书。
50、单元测试使用技术？测试重点是什么？测试条件是什么？
单元测试的技术：黑盒白盒技术，但是白盒居多，黑盒居少，一般先做黑盒再做白盒。单元测试重点：功能性测试，健壮性（逆向测试：无效值），性能。
单元测试前提条件：完成编译的测试对象，测试环境，开发工具，测试对象的规范说明
书。
51、什么是集成测试？
组件间的接口与交互的测试。
52、集成测试的测试重点是什么？测试条件是什么？使用什么技术？
接口和系统内不同部分的相互作用（交互）。
测试条件是完成集成的被测系统，测试台，有关组件间交互的文档。
测试技术包括白盒技术、黑盒技术，白盒居多，黑盒居少，对比单元测试，白盒下降，一般先做黑盒再做白盒。
53、集成测试有哪些策略？
自顶向下集成自底向上集成
54、什么是系统测试？
对整个系统能不能满足用户需求的测试。
55、系统测试的目的是什么？
检查软件是否满足需求。
56、系统测试能够发现哪些缺陷？会遗留哪些缺陷？
发现：非功能性缺陷、涉及整个系统的问题。
遗漏：对用户的需求的错误理解、没有实现或者没有完全实现用户的隐性需求。
57、什么是验收测试？
一般由用户/客户进行的确认是否可以接受一个系统的验证性测试。验收测试根据用户需求，业务流程进行的正式测试以确保系统符合所有验收的准则。
58、验收测试有哪些人进行？
客户或用户，测试人员可以介入。
59、验收测试的目标是什么？
对系统或子系统建立信心、对系统非功能性的特性赢得信任。
60、什么是alpha、beta测试？有何区别？
Alpha 测试：潜在的客户/用户在开发场地进行的测试。
Beta 测试：由潜在客户/用户在自己的环境下测试软件系统。
61、什么是维护测试？
软件正常使用后，对软件的变更、更新进行测试
62、什么是性能测试？负载测试？压力测试？有什么区别？
性能表现处理速度、响应时间、CPU 使用、内存使用、硬盘使用等。负载测试：通过不断增加负载来测试一个系统的性能。
压力测试：通过增加负载超过系统正常工作能力来考察系统能否在异常情况下正常工作
63、什么是功能测试？
测试一个软件能做什么，是不是做了应该做的工作，没做不该做的工作。
64、什么是结构测试？
白盒测试也称结构测试、逻辑驱动测试、基于程序本身的测试，是对程序结构进行的测
试。
65、什么是与变更相关的测试？有哪些具体类型？
与变更相关的测试是对修改过的程序进行的测试。确认测试（再测试）和回归测试。
66、什么是静态测试？动态测试？如何区分二者？
静态测试：不执行程序的测试。针对文档和不需执行的代码。
动态测试需要执行程序，方法一般采用黑盒测试方法和白盒测试方法。
67、圈复杂度怎么计算？
不重叠的闭合环数+1
68、什么是黑盒测试？白盒测试？
黑盒测试也称功能测试，基于规格说明书的测试，关注输入数据到程序中，输出结果是否正确，侧重于测试软件能做什么
白盒测试也称结构测试、逻辑驱动测试，是对程序内部逻辑结构进行的测试
69、白盒测试有哪些方法？具体解释每种方法？
白盒测试主要使用逻辑覆盖测试方法，包括语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖、路径覆盖等。
语句覆盖：程序中的每个可执行语句至少被执行一次。能发现语句错误，但不能发现逻辑错误。
判定覆盖：也称分支覆盖，程序中的每个判定的取真分支和取假分支至少执行一次。能发现逻辑错误，但不能发现组合判断中的条件错误。
条件覆盖：程序每个判定中每个条件的可能取值至少满足一次。能发现条件错误，但不能发现逻辑错误。
判定-条件覆盖：每个条件中的所有可能取值至少执行一次，同时，每个判定的可能结果至少执行一次。
条件组合覆盖：每个判定中的所有的条件取值组合至少执行一次。
路径覆盖：用例覆盖程序中的所有可能的执行路径。如果路径数很多，会变得不切实际。
70、什么是配置测试？
不同配置环境下进行测试。
71、什么是文档测试？
不仅包括测试文档校对，还有文档和软件不一致
72、什么是国际化测试？本地化测试？
国际性的软件
翻译成本国语言的，测试是否符合本国的语言习惯，是否符合本国法律，是否符合本国的国情。
73、测试用例的内容是什么？
用例编号，测试概述或用例标题、测试步骤，预期结果，输入数据，优先级，前置条件
等
74、测试用例有哪些元素？
用例编号，测试概述或用例标题、测试步骤，预期结果，输入数据，优先级，前置条件
等
或者说测试目标 Why、测试对象 What、测试环境要求 Where、测试前提 When，输入
数据
75、什么是UI、GUI？UI测试什么意思？
界面
图形界面
界面测试
76、解释测试目标、测试环境、测试对象、前置条件、测试策略、测试范围的含义？
测试目标：功能测试、性能测试、界面测试、易用性测试、兼容性测试、安全性测试测试策略：某类别测试的过程、方法以及方法如何应用，测试的注意事项等
测试环境：硬件环境、软件环境、网络环境
前置条件：进行某些测试工作需要做好的准备条件测试范围：软件需要测试的某个部位
77、软件投入运行后还需要测试吗？需要哪些测试？
需要测试。维护测试（含升级测试）、数据迁移测试、备份恢复测试、灾难恢复测试等
78、给你一个网站，你如何测试？
-
首先，查找需求说明、网站设计等相关文档，分析测试需求。
-
制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试、界面测试、性能测试、数据库测试、安全性测试、兼容性测试。
-
设计测试用例：
-
功能性测试可以包括，但不限于以下几个方面：
-
链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。
-
提交功能的测试。
-
多媒体元素是否可以正确加载和显示。
-
多语言支持是否能够正确显示选择的语言等。
-
-
界面测试可以包括但不限于一下几个方面：
-
页面是否风格统一，美观
-
页面布局是否合理，重点内容和热点内容是否突出
-
控件是否正常使用
-
对于必须但未安装的控件，是否提供自动下载并安装的功能
-
文字检查
-
-
性能测试一般从以下两个方面考虑：
-
压力测试、负载测试
-
数据库测试要具体决定是否需要开展。
-
数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。
-
-
安全性测试：
-
基本的登录功能的检查
-
是否存在溢出错误，导致系统崩溃或者权限泄露
-
相关开发语言的常见安全性问题检查，例如 SQL 注入等
-
-
兼容性测试，根据需求说明的内容，确定支持的平台组合：
-
浏览器的兼容性；
-
操作系统的兼容性；
-
软件平台的兼容性；
-
数据库的兼容性
-
-
开展测试，并记录缺陷。
-
合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。
-
定期评审，对测试进行评估和总结，调整测试的内容。
-
79、一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压，有什么区别?
-
300 个用户在一个客户端上
-
会占用客户机更多的资源，而影响测试的结果。线程之间可能发生干扰，而产生一些异常。
-
需要更大的带宽。
-
IP 地址的问题，可能需要使用 IP 欺骗来绕过服务器对于单一 IP 地址最大连接数的限制。
-
不必考虑分布式管理的问题。
-
-
用户分布在不同的客户端上
-
需要考虑使用控制器来整体调配不同客户机上的用户。
-
需要给予相应的权限配置和防火墙设置。
-
80、试述软件的概念和特点？软件复用的含义？构件包括哪些？
软件是计算机系统中与硬件相互依存的另一部分，与计算机系统操作有关的计算机程序、规程、规则，以及可能有的文件、文档及数据。
软件复用(SoftWare Reuse)是将已有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码级复用，被复用的知识专指程序，后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。
可以被复用的软件成分一般称作可复用构件。
81、软件配置管理的作用？软件配置包括什么？
软件配置管理（Software Configuration Management，SCM）是一种标识、组织和控制修改的技术。
软件配置管理应用于整个软件工程过程。
在软件建立时变更是不可避免的，而变更加剧了项目中软件开发者之间的混乱。SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。从某种角度讲，SCM 是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高生产效率。
软件配置包括如下内容：配置项识别、工作空间管理、版本控制、变更控制、状态报告、配置审计。
82、什么是软件质量？
概括地说，软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”。
具体地说，软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。
软件质量包括正确性、健壮性、效率、完整性、可用性、风险（产品运行）；可理解性、可维修性、灵活性、可测试性（产品修改）；可移植性、可再用性、互运行性（产品转移）。
83、目前主要的测试用例设计方法是什么？
白盒测试：逻辑覆盖（语句覆盖、判定/分支覆盖、条件覆盖、条件-判定覆盖、多条件组合覆盖）、基本路径覆盖
黑盒测试：测试大纲法、场景法、等价类划分、边界值分析法、错误猜测法、判定表法、随机测试、探索性测试
84、软件的安全性应从哪几个方面去测试？
-
软件安全性测试包括程序、数据库安全性测试。
-
根据系统安全指标不同测试策略也不同。
-
用户认证安全的测试要考虑的问题
- 明确区分系统中不同用户权限、系统中会不会出现用户冲突、系统会不会因用户的权限的改变造成混乱、用户登陆密码是否是可见、可复制、是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）、用户退出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统
-
系统网络安全的测试要考虑的问题
- 测试采取的防护措施是否正确装配好，有关系统的补丁是否打上、模拟非授权攻击，看防护系统是否坚固、采用成熟的网络漏洞检查工具检查系统相关漏洞、采用各种木马检查工具检查系统木马情况、采用各种防外挂工具检查系统各组程序的外挂漏洞
-
数据库安全考虑的问题
- 系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）、系统数据的完整性、系统数据可管理性、系统数据的独立性、系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）
85、什么是测试用例，什么是测试脚本，两者的关系是什么？
测试用例是为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。
测试脚本是为了进行自动化测试而编写的脚本。
测试脚本的编写一般都需要对应相应的测试用例。
86、软件测试各个阶段通常完成什么工作？各个阶段的结果文件是什么？包括什么内容？
单元测试阶段：各独立单元模块在与系统地其他部分相隔离的情况下进行测试，单元测试针对每一个程序模块进行正确性校验，检查各个程序模块是否正确地实现了规定的功能。生成单元测试报告，提交缺陷报告。
集成测试阶段：集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。该阶段生成集成测试报告，提交缺陷报告。
系统测试阶段：将通过确认测试的软件，作为整个给予计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行全面的功能覆盖。该阶段需要提交测试总结和缺陷报告。
验收测试阶段：一般由用户进行测试，或者是用户委托第三方进行测试，主要验证软件是否满足用户的使用需求，提升用户的信心，出具验收测试报告。
87、测试人员在软件开发过程中的任务是什么？
尽可能早的找出系统中的 Bug；
避免软件开发过程中缺陷的出现；
衡量软件的品质，保证系统的质量；
关注用户的需求，并保证系统符合用户需求。
88、如何测试一个纸杯？
功能：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或细菌
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水放 24 小时检查泄漏时间和情况；盛上汽油放 24 小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
89、测试计划工作的目的是什么？测试计划文档的内容应该包括什么？其中哪些是最重要的？
-
软件测试计划是指导测试过程的纲领性文件：
-
领导能够根据测试计划进行宏观调控，进行相应资源配置等。
-
测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等。
-
便于其他人员了解测试人员的工作内容，进行有关配合工作
-
-
测试计划包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
-
测试计划编写 6 要素（5W1H）：
-
why→→为什么要进行这些测试；
-
what→测试哪些方面，不同阶段的工作内容；
-
when→测试不同阶段的起止时间；
-
where→相应文档，缺陷的存放位置，测试环境等；
-
who→项目有关人员组成，安排哪些测试人员进行测试；
-
how→如何去做，使用哪些测试工具以及测试方法进行测试
-
-
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术，其中最重要的是测试测试策略和测试方法（最好是对计划先评审）。
90、什么是测试覆盖率
-
是指完成的测试工作目标量占总目标量的百分比，有很多分类。
-
软件测试覆盖率常用的计算公式：
-
功能覆盖率=至少被执行一次的测试功能点数/测试功能点总数（功能点）
-
需求覆盖率=被验证到的需求数量/总的需求数量（需求）
-
(用例)覆盖率=至少被执行一次的测试用例数/应执行的测试用例总数
-
语句覆盖率=至少被执行一次的语句数量/有效的程序代码行数
-
判定覆盖率=判定结果被评价的次数/判定结果总数
-
条件覆盖率=条件操作数值至少被评价一次的数量/条件操作数值的总数
-
91、一个好的测试用例，有哪些特点
-
用例要完整、简洁、一致
- 至少含有编号、标题、操作步骤和预期结果。
-
用例要表明测试目的
-
用例覆盖程度要高
-
用例能够使工作量最小化
-
用例描述正确、规范
- 含有正确的、规范的测试标题和编号
-
用例的分类以及描述要足够清晰
-
用例要具有可测试性
-
测试用例易于维护
- 如果被测对象有所升级，测试用例的说明或者脚本是不是容易维护呢？
-
可复用
-
可重复性
- 不管谁执行此用例，结果一样。
-
可追踪性
- 用例能追踪到一个具体的需求。
92、测试结束的标准是什么
- 全部测试用例都执行完成。
- 未修改 bug 都被确认或置为应有状态，暂缓修改的问题都有详尽的解释。
- 测试报告编写完成。
- 测试收尾工作结束。
- 测试总结完成。
- 项目处于试运行或上线阶段
- 在测试计划中定义结束标准
- 如计划中规定：系统在一定性能下平稳运行 72 小时，本版本中没有严重的 BUG，普通 BUG 的数量在 3 以下，BUG 修复率 90%以上
- 实际测试达到上述要求，然后由开发经理，测试经理，项目经理共同签字，认同测试结束，版本即可发布。
93、如何全面测试一款产品，请以手机短信功能为例来辅助说明，前提是手机自带的短信功能，并非微信，QQ 这种软件
- 能正常打开或进入短信界面
- 短信可以正常编辑、修改、删除
- 短信可以正常发送和接收
- 短信页面字体、颜色显示正常
- 短信字体可调整
- 给多人同时发短信
- 给特殊号码发送短信
- 如运营商（手机号所属运营商、其他运营商）
- 不存在手机号
- 服务号（收费、不收费）
- 接收验证码
- 短信耗电量测试
- 短信不耗流（联网、不联网）
- 短信干扰测试
- 编辑短信期间（已经编辑好、正在打字），电话进来
- 编辑短信期间（已经编辑好、正在打字），收到短信
- 隐藏到后台（已经编辑好、正在打字），进行其他操作，再返回
94、你手中的这支笔有多少用途，请发挥你的想象力
- 写、画（纸上、墙上、桌子上、地上、其他位置）
- 染色
- 承重
- 当书签
- 当筷子
- 用来扎人
- 用来掏掉进笔记本键盘的小东西
- 用来去除缝隙（比如手机上的缝隙）里的灰尘
- 当作燃料
- 拿在手里转着玩，消遣一下
- 用来碰电门
- 塑料笔管用来当吸管
95、常见的性能测试策略有哪些
负载测试、压力测试、并发测试、内存泄露测试、基准测试、配置测试、数据容量测试、疲劳强度测试
96、说说你对集成测试中自顶向下集成和自底向上集成两个策略的理解，要谈出它们各自的优缺点和主要适应于哪种类型测试
-
自顶向下集成
-
优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。
-
缺点：桩的开发量大；底层验证被推迟；底层组件测试不充分。
-
适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产品控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。
-
-
自底向上集成
-
优点：对底层组件行为较早验证；工作最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。
-
缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。
-
适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。
-
97、系统测试的策略有哪些
有功能测试、性能测试、负载测试、强度/压力测试、易用性测试、安全测试、配置测试、安装测试、文档测试、故障恢复测试、用户界面测试、可用性测试。
98、怎么理解回归测试?
-
回归测试: (regression testing)有两类：用例回归和错误回归；
-
用例回归是过一段时间以后再回头对以前使用过的用例在重新进行测试，看看会不会重新发现问题。
-
错误回归，就是在新版本中，对以前版本中出现并修复的缺陷进行再次验证，并以缺陷为核心，对相关修改的部分进行测试的方法。
-
99、LoadRunner分为哪三个模块？请简述各模块的主要功能。
-
Virtual User Generator
-
虚拟用户发生器
-
用于录制脚本、调试脚本、增强脚本、运行脚本
-
-
Controller
-
控制器
-
用于创建、运行和监控场景
-
-
Analysis
-
分析
-
用于分析测试结果
-
100、性能测试的流程?、
- 测试需求分析
- 测试计划制定与评审
- 测试用例设计与开发，编写测试脚本
- 测试执行与监控，开发场景
- 分析测试结果
- 编写性能测试报告·
- 测试经验总结
101、功能测试中常用的测试方法有哪些？做简要说明
- 场景法
- 主要对业务流程进行测试
- 将业务流区分为基本流和备选流，基本流按照正确的流程设计用例，备选流测试各种错误流程
- 等价类划分
- 将输入区域划分为若干个等价的类别，具体的分为有效等价类、无效等价类
- 有效等价类是依据规格说明书中的要求设计用例
- 无效等价类是违反规格说明书中的要求进行设计用例
- 边界值分析
- 依据输入数据的范围进行用例设计，一般选择边界点上的 4 个或 6 个值进行用例设计
- 通常选择比最小值正好小一点的值、最小值、最大值、比最大值刚刚大一点的数据作为用例
- 决策表
- 分析不同输入的各种组合产生不同的输出
- 错误猜测
- 考虑各种对软件的攻击
102、简单说一下对冒烟测试|集成测试的了解
- 冒烟测试
- 也称为小版本验证测试
- 对软件基本功能的验证
- 通过对软件基本功能的测试，确定能否进行后续大规模的测试，如果冒烟测试通过，则后续可以进行大规模测试，否则将软件打回开发
- 一般，冒烟测试由一个人进行，通常耗时 1-2 小时
- 不同测试类型的冒烟测试可能会有不同，比如性能测试的冒烟测试需要的人力和时间也许会拉长
- 集成测试
- 主要是测试软件多个单元合并到一起时需要的测试
- 通常测试软件各部件之间的接口和交互
- 一般由多个懂开发的测试人员进行
103、如何判断一个系统是否通过冒烟测试？
软件的基本功能或者重要功能已经正确实现
104、简单说一下bug等级是如何确定的？
- 致命
- 一般会引发蓝屏、死机、人身生命安全威胁、非常重要的功能没有实现或未正确实现、数据库死锁、数据库连接失败、因为错误操作导致程序中断
- 严重
- 重要功能没实现或者出现错误、接口出错
- 一般
- 常用功能没实现或者出错，界面错误、出错不提示、输入限制不在前台实现
- 小
- 界面不规范，长时间操作不提示、文字不使用专业术语、必输项与可输入项没有明确区分
- 意见和建议
105、在三角形计算中，要求三角形的三个边长：A，B和C。当三边不可能构可构成三角形时提示错误，可构成三角形时计算三角形周长。若是等腰三角形打印“等腰三角形”，若是等边三角形，则提示“等边三角形”。画出程序流程图、控制流程图、找出基本测试路径，对此设计一个测试用例。
- 程序流程图
- 控制流图
-
测试路径
-
语句覆盖/路径覆盖
- 124578
- 用例：3、3、4
- 123
- 用例：1、2、3
- 12456
- 用例：3、3、3
- 124578
-
判定覆盖
- 用例同上
-
条件覆盖
- 条件 a+b>c、a+c>b、b+c>a、a=b、a=c、b=c
- 都成立的用例：3、4、5
- 都不成立的用例：0、0、0
-
判定-条件覆盖
- 上边判定+条件
-
条件组合
-
条件 a+b>c、a+c>b、b+c>a
- a+b>c 真、a+c>b 真，b+c>a 真
- 用例：3、4、6
- a+b>c 真、a+c>b 真，b+c>a 假
- 用例：2、1、0
- a+b>c 真、a+c>b 假，b+c>a 真
- 用例：0、2、1
- l …
- a+b>c 真、a+c>b 真，b+c>a 真
-
条件 a=b、a=c、b=c
- a=b 真、a=c 真
- 用例：3、3、3
- a=b 真、a=c 假
- 用例：3、3、4
- a=b 假，a=c 真
- 用例：3、4、3
- a=b 假，a=c 假
- 用例：3、4、6
- a=b 真、a=c 真
107、没时间写测试用例怎么办？
- 在日常测试过程中，每天写日志时，记录重要的需求
- 随时记录重要的测试点
- 测试过程中，会发现一些缺陷，把这些缺陷整理成测试点
- 重要数据也可以做记录
- 寻找空闲时间，写出用例
108、有一个在线购物网站，分别适配PC端和微信端，针对选择商品—提交订单—支付这个流程（默认已经成功登录），请列出你能想到的测试点。
- 不选择商品，提交订单
- 选择一件商品
- 选择一件商品的多件
- 选择不同商品各一件
- 选择多种商品各多件
- 选择多件商品，有一件的，有多件的
- 修改商品的件数
- 一件变多件
- 多件变一件
- 一件变 0
- 删除某类商品
- 清空所有商品
- 提交订单后，撤销订单
- 提交订单后，付款
- 提交订单后，不付款
- 分别在 pc 端和微信端作上述测试
- 查看 pc 段和微信端数据是否同步
109、说说你的测试用例设计思路
在测试用例设计中，我会考虑以下几个方面：
功能测试：针对每个功能点设计测试用例，确保其按照预期工作。例如，对于一个登录功能，可以设计一些测试用例来验证不同的用户名和密码组合的登录是否成功，以及登录成功后是否跳转到正确的页面。
边界测试：针对每个功能的边界条件设计测试用例，以测试系统的鲁棒性和容错性。例如，对于一个取值范围为1-100的输入框，可以设计测试用例来验证输入为1、100以及1-100之外的值时系统的反应。
异常测试：设计测试用例来测试系统的异常处理能力。例如，对于一个上传文件的功能，可以设计测试用例来验证系统对于不支持的文件类型、超过限制大小的文件等情况的处理。
性能测试：设计测试用例来评估系统的性能。例如，对于一个搜索功能，可以设计测试用例来测试搜索过程的响应时间、并发用户数以及搜索结果的准确性。
安全测试：设计测试用例来验证系统的安全性。例如，对于一个用户权限管理功能，可以设计测试用例来验证系统是否正确地限制了用户的访问权限。
兼容性测试：设计测试用例来验证系统在不同平台安卓还是苹果，还是windows，苹果系统等、浏览器、设备上的兼容性。例如，对于一个网页应用，可以设计测试用例来测试在不同浏览器（Chrome、Firefox、Safari等）上的兼容性。 在设计测试用例时，还需要考虑测试的可重复性、覆盖率以及测试数据的准备等因素，以保证测试的全面性和可靠性。同时，测试用例的设计思路也可以根据具体的场景和需求进行调整和补充。
110、知道Selenium底层原理吗？
是的，我了解Selenium的底层原理。Selenium是一个用于自动化浏览器操作的工具，底层原理主要涉及三个组件：WebDriver，浏览器驱动和浏览器本身。
WebDriver：
WebDriver是Selenium的核心组件，用于控制浏览器进行页面操作和模拟用户行为。
WebDriver提供了丰富的API来操作浏览器，如页面导航、元素定位和操作、表单填写、截图等功能。
WebDriver支持多种编程语言，如Java、Python、C#等，开发人员可以根据自己的喜好和项目需求选择合适的语言进行自动化测试脚本的编写。
浏览器驱动：
浏览器驱动是连接WebDriver和浏览器的桥梁，它负责与特定浏览器进行通信。
不同浏览器需要使用对应的驱动程序，如Chrome需要使用ChromeDriver，Firefox需要使用GeckoDriver，以及其他浏览器的相应驱动。
浏览器驱动接收来自WebDriver的指令，将其翻译为浏览器可理解的操作，然后将结果返回给WebDriver。
浏览器：
浏览器是实际被自动化的目标，它将WebDriver传递的指令执行，然后将结果返回给WebDriver。
Selenium支持多种主流浏览器，如Chrome、Firefox、IE、Safari等。
通过这三个组件的协作，Selenium能够模拟用户在浏览器中的操作，实现自动化测试和网页数据抓取等任务。它支持跨浏览器、跨平台，并具有广泛的应用领域，如Web应用测试、UI自动化、爬虫等。
111、我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？
1、检查系统是否有中毒的特征；
2、检查软件/硬件的配置是否符合软件的推荐标准；
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务；
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。
112、怎么设计接口测试用例？（非常重要）
通常，设计接口测试用例需要考虑以下几个方面：
①是否满足前提条件
有些接口需要满足前提，才可成功获取数据。常见的，需要登录Token
逆向用例：针对是否满足前置条件（假设为n个条件），设计1~n条用例
②是否携带默认值参数
正向用例：带默认值的参数都不填写、不传参，必填参数都填写正确，设计1条用例
③业务规则、功能需求
结合接口参数说明，可能需要设计N条正向用例和逆向用例
④参数是否必填
逆向用例：针对每个必填参数，都设计1条参数值为空的逆向用例
⑤参数之间是否存在关联
有些参数彼此之间存在相互制约的关系
⑥参数数据类型限制
逆向用例：针对每个参数都设计1条参数值类型不符的逆向用例
⑦参数数据类型自身的数据范围值限制
正向用例：针对所有参数，设计1条每个参数的参数值在数据范围内为最大值的正向用例
113、你做接口测试，测什么？（非常重要）
可用性测试
根据约定的协议、方法、格式内容，传输数据到接口经处理后返回期望的结果：
1、根据响应结果判断接口功能是否正确实现；
2、返回值测试 - 返回值除了内容要正确，类型也要正确，保证调用方和前端能够正确地解析，
3、返回值测试 - 判断返回值中的字段是否有缺少或者多余
4、参数值边界值、等价类测试；
错误和异常处理测试
1、输入异常值（空值、特殊字符等），接口能正确处理，且按预期响应；
2、输入超长数据或者超大或者超小数据，接口能正确处理，且按预期响应；
3、输入错误的参数，接口能正确处理，并按预期响应；
4、多输入、少输入参数，接口能正确处理，且按预期响应；
5、错误传输数据格式（如json格式写成form格式）测试；
安全性测试，主要指传输数据的安全性：
1、敏感数据（如密码、秘钥）等是否加密传输；
2、返回数据是否含有敏感数据，如用户密码、完整的用户银行账号信息等；
3、接口是否对传入的数据做安全校验，如身份ID加token类似校验；
4、接口是否防止恶意请求（如大量伪造请求接口致使服务器崩溃）；
性能测试，如接口的响应时间、并发处理能力、压测处理情况：
1、并发请求相同的接口（特别为POST请求），接口的处理情况（如插入了相同的记录导致数据出错，引发系统故障）；
2、接口响应时长在用户可忍受的范围内；
3、对于请求量大的接口做压测，确定最大的瓶颈点是否满足当前业务需要；
114、没有接口文档，如果做接口测试？（非常重要）
没有接口文档，那就需要先跟开发沟通，然后整理接口文档
没有接口文档，可以抓包看接口请求参数，然后不懂的跟开发沟通
115、你平常做接口测试的过程中发现过哪些bug?（非常重要）
面试官出这个题，主要是想知道你是不是真的做过接口测试，
常规错误，接口没实现，没按约定返回结果，边界值处理出错等。
输入异常值（空值、特殊字符、超过约定长度等），接口抛错，没做封装处理；
输入错误的参数、多输入、少输入参数，接口可能出现的错误；
安全性问题，如明文传输、返回结果含有敏感信息，没对用户身份信息做校验，没做恶意请求拦截等；
性能问题，如接口并发插入多条相同操作，响应时间过长，接口压测出现瓶颈等；
116、你的项目是什么阶段介入接口自动化测试的（非常重要）？
项目前期：编写测试用例、搭建测试框架、调试脚本代码；
项目中期：执行测试，报告bug，维护框架，调整测试用例
项目后期：代码改进，框架优化，结果输出，分析报告，回归测试
项目上线：监控项目，维护框架
117、为什么做接口测试(重要)？
a、可以发现很多在页面上发现不了的bug。
b、检查系统的异常处理能力。
c、检查系统的安全性,稳定性。
d、前端随便变，接口测好了，后端就可以不用变了。
e、接口测试是一个完整的体系，也包括功能刻试、性能则试和安全性测试。
118、登录按钮除了用click方法进行点击以外还有其他方式吗?
还可以使用 submit() 方法，前提是input元素的type为submit
119、怎么验证复选按钮是不是被选中
可以使用元素的 isSelected() 方法，如果返回的是 true 则说明被选中，否则表明未被选中
120、在制定自动化测试计划的时候一般要考虑哪些点？(重要)
1、分析当前的工具是否适合新项目
2、选择合适的自动化测试框架
3、确定要做自动化测试的范围和不做自动化测试的范围
4、测试环境的准备
5、制定一个粗略的脚本开发的时间表
6、制定脚本执行的一些策略，如冒烟测试的频率，回归测试的时间点及频率等
7、定义自动化测试的输出，比如脚本，测试数据，发现的缺陷，测试报告等
121、请描述如何划分缺陷与错误严重性和优先级别？
给软件缺陷与错误划分 严重性和优先级的通用原则：
1.表示软件缺陷所造成的危害和恶劣程度。
2.优先级表示修复缺陷的重要程度和次序。
严重性：
1.严重：系统崩溃、数据丢失、数据毁坏
2.较严重：操作性错误、结果错误、遗漏功能
3.一般：小问题、错别字、UI布局、罕见故障
4.建议：不影响使用的瑕疵或更好的实现。
优先级：
1.最高优先级：立即修复，停止进一步测试。
2.次高优先级：在产品发布之前必须修复。
3.中等优先级：如果时间允许应该修复。
4.最低优先级：可能会修复，但是也可能发布。
122、一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。
一套完整的测试应该由五个阶段组成：
1.测试计划：首先根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。
2.测试设计将测试计划阶段制定的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性）。
3.测试开发建立可重复使用的自动测试过程。
4.测试执行执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。
5.测试评估结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。
123、简述一下缺陷的生命周期
打开：表示问题被提交等待有人处理。重新指派：问题被重新指派给某人处理。处理：问题在处理中，尚未完成。固定：确认此问题存在，但暂时不进行处理。回归：对已经修复的问题进行回归确认。
-reopen: 重新打开关闭：问题的最后一个状态。
124、测试用例设计方法都有哪些？
1.等价类划分法顾名思义，等价类划分，就是将测试的范围划分成几个互不相交的子集，他们的并集是全集，从每个子集选出若干个有代表性的值作为测试用例。
2.边界值分析法长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。选出的测试用例，应选取正好等于、刚刚大于、刚刚小于边界的值，例如，对于在区间min，max的值，测试用例可以记为min，min+，max，max-。
3.错误推测法错误推测法是指：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。
4.判定表法又称为策略表，基于策略表的测试，是功能测试中最严密的测试方法。该方法适合于逻辑判断复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，会得到一个判断清晰的策略表。
5 .正交实验法 用语言描述正交实验法会很抽象难懂，简单说，就是在各因素互相独立的情况下，设计出一种特殊的表格，找出能以少数替代全面的测试用例。其中，上面所说的特殊表格就是正交表，是按照一定规则生成的表。虽然说是特殊的表格，实际表现形式跟一般的表格没有什么区别，正交表的主要特征是，“均匀分布，整齐划一”，正是因为“均匀”的，所以才能以少数代替全部。
125、一个文本框要求输入6位数字密码，且对每个账户每次只允许出现三次输入错误，对此文本框进行测试设计的等价区间有哪些？
1.密码为空 登录
2.正确输入[输入正确的值] 登录
3.错误输入[ 输入错误的值，
输入数据例如：特殊符号、英文字母、汉字及非法字符等一些非正确值；
输入方法例如：不足六位，超出六位，最大输入值） 登录/取消 ]
4.连续错误输入三次以上 [查看连续错误输入后的提示信息及结果]
5.其他[是否支持剪贴板操作，例如：复制/剪切/粘贴]
126、简述什么是静态测试、动态测试、黑盒测试、白盒测试、α测试 β测试
静态测试是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程。
动态测试是实际运行被测程序，输入相应的测试实例，检查运行结果与预期结果的差异，判定执行结果是否符合要求，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能。
黑盒测试一般用来确认软件功能的正确性和可操作性,目的是检测软件的各个功能是否能得以实现,把被测试的程序当作一个黑盒,不考虑其内部结构,在知道该程序的输入和输出之间的关系或程序功能的情况下,依靠软件规格说明书来确定测试用例和推断测试结果的正确性。
白盒测试根据软件内部的逻辑结构分析来进行测试,是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现。
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。
β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。
127、软件产品质量特性是什么?
功能性：适应性、准确性、互操作性、依从性、安全性。
可靠性：成熟性、容错性、易恢复性。
可使用性：易理解性、易学习性、易操作性。
效率：在指定的条件下，用软件实现某种功能所需的计算机资源（包括时间）的有效程度。
可维护性：易分析性、易变更性、稳定性、易测试性。
可移植性： 适应性、易安装性、遵循性、易替换性
128、软件测试分为几个阶段 各阶段的测试策略和要求是什么?
和开发过程相对应，测试过程会依次经历单元测试、集成测试、系统测试、验收测试
四个主要阶段：
单元测试：单元测试是针对软件设计的最小单位––程序模块甚至代码段进行正确性检验的测试工作，通常由开发人员进行。
集成测试：集成测试是将模块按照设计要求组装起来进行测试，主要目的是发现与接口有关的问题。由于在产品提交到测试部门前，产品开发小组都要进行联合调试，因此在大部分企业中集成测试是由开发人员来完成的。
系统测试：系统测试是在集成测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有重大的影响。
验收测试：验收测试以需求阶段的《需求规格说明书》为验收标准，测试时要求模拟实际用户的运行环境。对于实际项目可以和客户共同进行，对于产品来说就是最后一次的系统测试。测试内容为对功能模块的全面测试，尤其要进行文档测试。
单元测试测试策略：
自顶向下的单元测试策略：比孤立单元测试的成本高很多，不是单元测试的一个好的选择。
自底向上的单元测试策略：比较合理的单元测试策略，但测试周期较长。
孤立单元测试策略：最好的单元测试策略。
集成测试的测试策略：
大爆炸集成：适应于一个维护型项目或被测试系统较小
自顶向下集成：适应于产品控制结构比较清晰和稳定;高层接口变化较小;底层接口未定义或经常可能被修改;产口控制组件具有较大的技术风险，需要尽早被验证;希望尽早能看到产品的系统功能行为。
自底向上集成：适应于底层接口比较稳定;高层接口变化比较频繁;底层组件较早被完成。
基于进度的集成
优点：具有较高的并行度;能够有效缩短项目的开发进度。
缺点：桩和驱动工作量较大;有些接口测试不充分;有些测试重复和浪费。
系统测试的测试策略：
数据和数据库完整性测试;
功能测试;
用户界面测试;
性能评测;
负载测试;
强度测试;
容量测试;
安全性和访问控制测试;
故障转移和恢复测试;
配置测试;
安装测试;
加密测试;
可用性测试;
版本验证测试;
文档测试
129、软件生命周期(SDLC)的六个阶段
1、问题的定义及规划
此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
2、需求分析
在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。“唯一不变的是变化本身。”，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。
3、软件设计
此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。
4、程序编码
此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。
5、软件测试
在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
6、运行维护
软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。
130、软件测试原则
Good-enough: 一种权衡投入/产出比的原则
保证测试的覆盖程度，但穷举测试是不可能的
所有的测试都应追溯到用户需求
越早测试越好，测试过程与开发过程应是相结合的
测试的规模由小而大，从单元测试到系统测试
为了尽可能地发现错误，应该由独立的第三方来测试
不能为了便于测试擅自修改程序
既应该测试软件该做什么也应该测试软件不该做什么
131、 软件测试的的重点
- 测试用例的设计
测试用例的设计是整个软件测试工作的核心
测试用例反映对被测对象的质量要求，决定对测试对象的质量评估
- 测试工作的管理
尤其是对包含多个子系统的大型软件系统，其测试工作涉及大量人力和物力，有效的测试工作管理是保证有效测
试工作的必要前提
- 测试环境的建立
测试环境应该与实际测试环境一致
132、什么是黑盒测试?
-
又称
功能测试或数据驱动测试，是针对软件的功能需求/实现进行测试，通过测试来检测每个功能是否符合需求，不考虑程序内部的逻辑结构 -
黑盒测试方法- 功能划分
- 等价类划分
- 边界值分析
- 因果图
- 错误推测等
133、什么是白盒测试
- 白盒测试也称结构测试或逻辑驱动测试，必须知道软件内部工作过程，通过测试来检测软件内部是否按照需求、设计正常运行
白盒测试的主要方法是：- 语句覆盖方法
- 分支覆盖方法
- 逻辑覆盖方法
134、测试流程
- 单元测试
- 集成测试
- 系统测试
- 用户验收测试
- 回归测试
135、单元测试
定义：完成对最小的软件设计单元—模块的验证工作
目标是：确保模块被正确地编码
使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误
通常情况下是面向白盒的
对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早地发现和解决不易显现的错误
单元测试的内容
接口测试
内部数据结构
全局数据结构
边界
语句覆盖，错误路径
136、集成测试
通过测试发现与模块接口有关的问题
目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构
应当避免一次性的集成（除非软件规模很小），而采用增量集成
集成测试主要内容
API
API/参数组合
137、系统测试
根据软件需求规范的要求进行系统测试，确认系统满足需求的要求
系统测试人员相当于用户代言人
在需求分析阶段要确定软件的可测性，保证有效完成系统测试工作
系统测试主要内容
所有功能需求得到满足
所有性能需求得到满足
其他需求（例如安全性、容错性、兼容性等）得到满足
138、用户验收/确认测试
Alpha测试：是由用户在开发者的场所来进行的，Alpha测试是在一个受控的环境中进行的
Beta测试：由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者
139、请说一说黑盒与白盒的测试方法
黑盒测试：
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，因此不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
常用的黑盒测试方法有：等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。
白盒测试：
白盒测试也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但仍然有可能存在错误。因为：穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序；穷举路径测试不可能检查出程序因为遗漏路径而出错；穷举路径测试发现不了一些与数据相关的错误。
白盒测试需要遵循的原则有：
1.保证一个模块中的所有独立路径至少被测试一次；
2.所有逻辑值均需要测试真（true）和假（false）；两种情况；
3 检查程序的内部数据结构，保证其结构的有效性；
4.在上下边界及可操作范围内运行所有循环。
常用白盒测试方法：
静态测试：不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。
动态测试：需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。
白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：
1.语句覆盖每条语句至少执行一次。
2.判定覆盖每个判定的每个分支至少执行一次。
3.条件覆盖每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖同时满足判定覆盖条件覆盖。
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖使程序中每一条可能的路径至少执行一次。
140、 请回答集成测试和系统测试的区别，以及它们的应用场景主要是什么？
区别：
1、计划和用例编制的先后顺序：从V模型来讲，在需求阶段就要制定系统测试计划和用例，HLD的时候做集成测试计划和用例，有些公司的具体实践不一样，但是顺序肯定是先做系统测试计划用例，再做集成。
2、用例的粒度：系统测试用例相对很接近用户接受测试用例，集成测试用例比系统测试用例更详细，而且对于接口部分要重点写，毕竟要集成各个模块或者子系统。
3、执行测试的顺序：先执行集成测试，待集成测试出的问题修复之后，再做系统测试。
应用场景：
集成测试：完成单元测试后，各模块联调测试；集中在各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的正确性验证等等；可以是整个产品的集成测试，也可以是大模块的集成测试；集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。集成测试对测试人员的编写脚本能力要求比较高。测试方法一般选用黑盒测试和白盒测试相结合。
系统测试：针对整个产品的全面测试，既包含各模块的验证性测试（验证前两个阶段测试的正确性）和功能性（产品提交个用户的功能）测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。系统测试测试软件《需求规格说明书》中提到的功能是否有遗漏，是否正确的实现。做系统测试要严格按照《需求规格说明书》，以它为标准。测试方法一般都使用黑盒测试法。
141、请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
1、是否有不正确或遗漏的功能？
2、在接口上，输入是否能正确的接受？能否输出正确的结果？
3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
4、性能上是否能够满足要求？
5、是否有初始化或终止性错误？
白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
1、对程序模块的所有独立的执行路径至少测试一遍。
2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
3、在循环的边界和运行的界限内执行循环体。
4、测试内部数据结构的有效性，等等。
单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。
系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）
系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。
142、请以您以往的实际工作为例,详细的描述一次测试用例设计的完整的过程。
就说最近的这次网站功能测试吧
首先：得到相关文档（需求文档和设计文档），理解需求和设计思想后，想好测试策略（测试计划简单点就OK了），考虑到测试环境，测试用例，测试时间等问题。
第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的网站的输入数据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处理的，有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。处理过程中，会经历3个步骤，网站才算完成了它的任务。有3个步骤呢，就可以分别对 这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多50个用例。界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示。
第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需要web服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了tomcat，所以只要有tomcat即可
第四步：执行测试
143、您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）
测试类型有：功能测试，性能测试，界面测试。
功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
区别：
功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。
性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。
界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否 美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？
做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试
144、您认为做好测试用例设计工作的关键是什么？
- 白盒测试用例设计的关键是
以较少的用例覆盖尽可能多的内部程序逻辑结果 - 黑盒测试用例设计的关键同样也是
以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题
145、配置和兼容性测试的区别是什么?
配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否与不同的软件正确协作。
配置测试的核心内容就是使用各种硬件来测试软件的运行情况，一般包括：
(1)软件在不同的主机上的运行情况，例如Dell和Apple;
(2)软件在不同的组件上的运行情况，例如开发的拨号程序要测试在不同厂商生产的Modem上的运行情况;
(3)不同的外设;
(4)不同的接口;
(5)不同的可选项，例如不同的内存大小;
兼容性测试的核心内容：
(1)测试软件是否能在不同的操作系统平台上兼容;
(2)测试软件是否能在同一操作系统平台的不同版本上兼容;
(3)软件本身能否向前或者向后兼容;
(4)测试软件能否与其它相关的软件兼容;
(5)数据兼容性测试，主要是指数据能否共享;
配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统等。具体进行时仍然按照测试用例来执行。
146、写出bug报告当中一些必备的内容。
硬件平台和操作系统
测试应用的硬件平台（Platform），通常选择“PC”。
测试应用的操作系统平台（OS）。
a)版本
提交缺陷报告时通过该字段标识此缺陷存在于被测试软件的哪个版本。
b)Bug报告优先级
c)Bug状态
d)Bug的编号
e)发现人
f)提交人
g)指定处理人
h)概述
i)从属关系
j)详细描述
k)严重程度
l)所属模块
m)附件
n)提交日期
147、你提交的bug，开发不认可怎么办？
首先我会再看需求文档，是不是我的理解有误，如果是我对需求理解错的话我就去关闭bug；
如果是bug再去让身边的同看看听下他们的意见，然后自己先再三确去复测，并且保存好截图和日志，确定这是一个bug之后我就去跟开发说明白，并且给他看bug重现的截图以及日志。
如果开发还是不认可的话我就跟产品或项目经理说明白情况
148、测试用例是什么？有什么作用？
**回答：**测试用例就是设计一个特定场景，让软件在这种场景下运行，检验程序是否给出正确的反应，以此验证软件是否正确实现了客户需求。
作用：
1、避免盲目测试并提高测试效率；在软件版本更新之后只需修正少部分用例即可开展测试工作，降低工作强度，缩短测试周期；
2、可以分清哪些是测试重点，测试用例是测试工作的见证，能知道测试了哪些功能，没测哪些模块；
3、测试用例是量化测试工作的方法之一；