第三十七：软件测试八股文(持续更新中)

一.软件测试流程步骤

1.测试需求分析阶段：阅读需求，理解需求
1.1.主要就是对业务的学习，分析需求点，参与需求评审会议

2.测试计划阶段：主要任务就是编写测试计划，参考软件需求规格说明书，编写项目总体计划
2.1.内容包括测试范围，进度安排，人力物力的分配，整体测试策略的制定
2.2.风险评估与规避措施的制定

3.测试设计阶段：主要是编写测试用例
3.1.参考需求文档，概要设计，详细设计等文档，用例编写完成之后会进行评审

4.测试执行阶段：搭建环境，执行冒烟测试-然后进入正式测试，bug管理直到测试结束

5.测试评估阶段：出测试报告，确认是否可以上线

二.软件测试模型

1.V模型

1.1.V模型非常明确地标明测试过程中存在的不同级别
1.1.1.并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系

1.2.局限性：把测试作为编码之后的最后一个活动
1.2.1.需求分析等前期产生的错误直到后期的验收测试才能发现

2.W模型

3.X模型

3.1.X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试
3.2.此后将进行频繁的交接，通过集成最终成为可执行的程序，再对这些可执行程序进行测试

4.H模型

4.1.H模型是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行

4.2.H模型指出测试要尽早准备, 尽早执行.不同的测试活动可以是按照某个次序先后进行的

4.3.但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展

5.总结

V模型非常明确地标注了测试过程中存在的不同类型的测试

W模型非常明确地标注了生产周期中开发与测试之间的对应关系

X模型指出整个测试过程是在探索中进行的

H模型是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行

三.测试人员需要何时参加需求分析

1.如果条件循序原则上来说是越早介入需求分析越好 

2.因为测试人员对需求理解越深刻对测试工作的开展越有利

3.可以尽早的确定测试思路减少与开发人员的交互减少对需求理解上的偏差

四.做好测试计划的关键

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

2.做好测试计划工作的关键 ：目的，管理，规范

明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷
因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷
因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行
测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确

坚持“5W”规则，明确内容与过程“5W”规则指的是“What”、“Why”、“When”、“Where”、“How”

利用“5W”规则创建软件测试计划
可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What）
确定测试的开始和结束日期（When），指出测试的方法和工具（How）
给出测试文档和软件的存放位置（Where）

采用评审和更新机制，保证测试计划满足实际需求测试计划写作完成后
如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容
或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员

分别创建测试计划与测试详细规格、测试用例应把详细的测试技术指标包含到独立创建的测试详细规格文档
把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中

测试计划和测试详细规格、测试用例之间是战略和战术的关系
测试计划主要从宏观上规划测试活动的范围、方法和资源配置
而测试详细规格、测试用例是完成测试任务的具体战术

五.对软件测试/质量保证的理解

1.根据软件开发阶段的规格说明和程序的内部结构而精心设计的一批测试用例

2.并根据这些测试用例去运行程序，以发现错误的过程

3.它是对应用程序的各个方面进行测试以检查其功能、语言有效性及其外观排布

六.软件测试的目的

1.测试的目的是找出软件产品中的错误，使软件尽可能的符合用户的要求

2.当然软件测试是不可能找出全部错误的

七.什么是软件测试

1.在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量
1.1.并对其是否能满足设计要求进行评估的过程

八.软件测试的原则

1.测试应尽早启动、介入（需求分析阶段），所有的测试应追溯到用户需求
1.1.测试软件存在缺陷，不可能执行穷尽测试，完全测试是不可能的，测试需要终止

2.二八原则，测试发现的错误中80%很可能的起源于20%的模块中
3.对错误结果要进行一个确认的过程（测试的详细数据，截图，前置条件等）
4.制定严格的测试计划
5.妥善保管测试过程中的所有文档
6.程序员尽量避免自己的检查程序
7.设计测试用例是应该考虑到合法的输入和不合法的输入

九.软件测试的策略

1.在一定的软件测试标准、测试规范的指导下
1.1.依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合

十.软件的生存周期

1.软件生存周期又称为软件生命期，生存期
2.指从形成开发软件概念起，开发的软件使用以后，直到失去使用价值消亡为止的整个过程

3.生存周期包括：问题的定义及规划、需求分析/评审、软件设计、软件编码、测试阶段、运行维护
3.1.六个时期，每个时期又划分为若干个阶段。每个阶段有明确的任务

十一.软件周期模型

1.瀑布模型

2.快速原型模型

2.1.允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型
2.2.该原型向用户展示待开发软件的全部或部分功能和性能
2.3.用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求
2.4.开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护

3.迭代模型

3.1.迭代包括产生产品发布的全部开发活动和要使用该发布必需的所有其他外围元素
3.2.在某种程度上，开发迭代是一次完整地经过所有工作流程的过程
3.3.实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段都可以细分为迭代
3.4.每一次 的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集

十二.软件生命周期阶段

1.软件计划与可行性分析
2.需求分析
3.软件设计
4.编码
5.软件测试
6.运行与维护

十三.软件产品质量特性

1.功能性：适应性、准确性、互操作性、依从性、安全性
2.可靠性：成熟性、容错性、易恢复性
3.可使用性：易理解性、易学习性、易操作性
4.效率：时间特性、资源特性
5.可维护性：易分析性、易变更性、稳定性、易测试性
6.可移植性： 适应性、易安装性、遵循性、易替换性

十四.软件开发周期

1.需求分析：需求规格说明书
2.设计：概要设计说明书，详细设计说明书
3.编码：产出程序

十五.软件测试的方法

1.冒烟测试
2.黑盒测试
3.白盒测试
4.灰盒测试
5.单元测试
6.集成测试
7.系统测试
8.验收测试
9.回归测试
10.α测试(alpha)
11.β测试(beta)
12.静态测试
13.动态测试

黑盒测试：用来确认软件功能的正确性和可操作性，目的是检测软件的各个功能是否能得以实现
把被测试的程序当作黑盒，不考虑其内部结构
在知道程序的输入和输出之间的关系或程序功能的情况下
依靠软件规格说明书来确定测试用例和推断测试结果的正确性

单元测试：各独立单元模块在与系统地其他部分相隔离的情况下进行测试
单元测试针对每一个程序模块进行正确性校验，检查各个程序模块是否正确地实现了规定的功能
生成单元测试报告，提交缺陷报告

集成测试：是在单元测试的基础上，将所有的软件单元按照概要设计规格说明
要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动
该阶段生成集成测试报告，提交缺陷报告

系统测试：将通过确认测试的软件，作为整个给予计算机系统的一个元素
与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起
在实际运行环境下，对计算机系统进行全面的功能覆盖
该阶段需要提交测试总结和缺陷报告

α测试：由用户在开发环境下进行的测试，内部的用户在模拟实际操作环境下进行的受控测试
Alpha测试不能由程序员或测试员完成

β测试：由软件的一个或多个用户在实际使用环境下进行的测试，开发者通常不在测试现场
Beta测试不能由程序员或测试员完成

静态测试：是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程

动态测试：是实际运行被测程序，输入相应的测试实例
检查运行结果与预期结果的差异，判定执行结果是否符合要求
从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能

十六.单元测试的测试对象、目的、测试依据、测试方法

1.单元测试对象是模块内部的程序错误
2.单元测试目的是消除局部模块逻辑和功能上的错误和缺陷
3.单元测试依据是模块的详细设计
4.单元测试方法是采用白盒测试

十七.单元测试的策略

1.逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析

十八.黑盒和白盒的优点和缺点

1.黑盒测试的优点

1.1.不需要了解程序内部的代码及实现，与软件的内部实现无关
1.2.从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题
1.3.基于软件开发文档，所以能知道软件实现文档中的哪些功能
1.4.在做软件自动化测试时较为方便

2.黑盒测试的缺点

2.1.不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%
2.2.自动化测试的复用性较低

3.白盒测试的优点

帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题

4.白盒测试的缺点

4.1.程序运行会有很多不同的路径，不可能测试所有的运行路径

4.2.测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求
4.3.系统庞大时，测试开销会非常大

十九.黑盒测试的测试用例常见设计方法

1.等价类划分

1.1.等价类是指某个输入域的子集合
1.2.在该子集合中，各个输入数据对于揭露程序中的错误都是等效的
1.2.1.测试某等价类的代表值就等于对这一类所有值的测试

1.3.因此，可以把全部输入数据合理划分为若干等价类
1.3.1.在每一个等价类中取一个数据作为测试的输入条件
1.3.2.就可以用少量代表性的测试数据，取得较好的测试结果

1.4.等价类划分可有两种不同的情况：有效等价类和无效等价类

2.边界值分析法

2.1.边界值分析法是对等价类划分方法的补充

2.2.测试工作经验告诉我，大量的错误是发生在输入或输出范围的边界上
2.2.1.而不是发生在输入输出范围的内部

2.3.因此针对各种边界情况设计测试用例，可以查出更多的错误

2.4.使用边界值分析方法设计测试用例，首先应确定边界情况
2.4.1.通常输入和输出等价类的边界，就是应着重测试的边界情况
2.4.2.应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据
2.4.3.而不是选取等价类中的典型值或任意值作为测试数据

3.错误猜测法

3.1.基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法

3.2.列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例
3.2.1.例如，在单元测试时曾列出的许多在模块中常见的错误
3.2.2.以前产品测试中曾经发现的错误等，这些就是经验的总结
3.2.3.还有，输入数据和输出数据为0的情况
3.2.4.输入表格为空格或输入表格只有一行
3.2.5.这些都是容易发生错误的情况，可选择这些情况下的例子作为测试用例

4.因果图方法

4.1.前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件
4.1.1.但未考虑输入条件之间的联系，相互组合等

4.2.考虑输入条件之间的相互组合，可能会产生一些新的情况
4.2.1.但要检查输入条件的组合不是一件容易的事情
4.2.2.即使把所有输入条件划分成等价类，他们之间的组合情况也相当多

4.3.因此必须考虑采用一种适合于描述对于多种条件的组合
4.3.1.相应产生多个动作的形式来考虑设计测试用例

4.4.这就需要利用因果图（逻辑模型）
4.4.1.因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况

5.场景分析方法

5.1.指根据用户场景来模拟用户的操作步骤，类似因果图，但是可能执行的深度和可行性更好

6.正交表分析法

6.1.可能因为大量的参数的组合而引起测试用例数量上的激增，
6.2.同时，这些测试用例并没有明显的优先级上的差距，
6.3.而测试人员又无法完成这么多数量的测试，
6.4.就可以通过正交表来进行缩减些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性
6.5.用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂

6.6.具体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法
6.7.对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来
6.8.但是更深的缺陷，更复杂的缺陷，还是无能为力的

7.状态图法

7.1.通过输入条件和系统需求说明得到被测系统的所有状态，通过输入条件和状态得出输出条件
7.1.1.通过输入条件、输出条件和状态得出被测系统的测试用例

8.大纲法

8.1.大纲法是着眼于需求的方法，为了列出各种测试条件，就将需求转换为大纲的形式

8.2.大纲表示为树状结构，在根和每个叶子结点之间存在唯一的路径

8.3.大纲中的每条路径定义了一个特定的输入条件集合，用于定义测试用例

8.4.树中叶子的数目或大纲中的路径给出了测试所有功能所需测试用例的大致数量

二十.做好测试用例工作的关键

1.需求和设计文档的理解程度，对系统的熟悉程度

二十一.描述软件开发、测试过程，由哪些角色负责，你做什么

1.要有架构师、开发经理、测试经理、程序员、测试员

2.我在里面主要是负责所分到的模块执行测试用例

二十二.在软件测试中具体从事过哪些工作？其中最擅长哪部分工作？

1.测试从事过web测试，后台测试，客户端软件，进行功能测试，性能测试
1.1.编写测试脚本测试，业务地图文档，测试报告，测试计划等的管理

2.比较擅长编写测试用例和进行功能测试

二十三.如何做好软件测试

1.首先要有良好的沟通，只有沟通无障碍，才会有好的协作，才会有更好的效率

2.再就是相应的软件测试技术要过关

3.做测试要有足够的耐心，和良好的工作习惯，不懂的就要问，实时与同事沟通

二十四.软件测试人员需要具备哪些素质

1.做测试应该要有一定的协调能力，因为测试人员经常要与开发接触处理一些问题
1.1.如果处理不好的话会引起一些冲突，这样的话工作上就会不好做

2.还有测试人员要有一定的耐心，有的时候做测试很枯燥乏味

3.除了耐心，测试人员不能放过每一个可能的错误

二十五.测试在软件开发过程中的任务

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

总的目标是：确保软件的质量

二十六.如何编写测试报告

1.根据内部测试报告进行编写，一般可以摘录
2.不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道
3.报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的
4.报告上面的内容尽量要真实可靠
5.整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告

二十七.执行别人的用例，如果发现用例有错怎么处理

1.首先咨询一下案例作者或者询问测试组长，确认一下，如果确实有误就要修正用例

二十八.提交缺陷的八大要素

1.缺陷编号
2.缺陷状态
3.缺陷标题
4.缺陷类型
5.缺陷严重程度
6.缺陷优先级
7.缺陷的重现步骤
8.缺陷的测试环境

二十九.提交高质量的缺陷记录

1.通用UI要统一、准确

1.1.缺陷报告的UI要与测试的软件UI保持一致，便于查找定位

2.尽量使用业界惯用的表达术语和表达方法

2.1.使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化

3.每条缺陷报告只包括一个缺陷

3.1.每条缺陷报告只包括一个缺陷，可以迅速定位一个缺陷，
3.1.1.集中精力每次只修正一个缺陷
3.1.2.校验者每次只校验一个缺陷是否已经正确修正

4.不可重现的缺陷也要报告

4.1.首先缺陷报告必须展示重现缺陷的能力
4.2.不可重现的缺陷要尽力重现，若尽力之后仍不能重现，仍然要报告此缺陷
4.3.但在报告中要注明无法再现，缺陷出现的频率

5.明确指明缺陷类型

5.1.根据缺陷的现象，总结判断缺陷的类型
5.1.1.例如，即功能缺陷、界面缺陷、数据缺陷，合理化建议
5.2.这是最常见的缺陷或缺陷类型，其他形式的缺陷或缺陷也从属于其中某种形式

6.明确指明缺陷严重等级和优先等级

6.1.明确严重等级和优先等级之间的差别，高严重问题可能

7.描述，简洁，准确，完整，揭示缺陷实质。记录缺陷或缺陷出现的位置描述要准确反映缺陷的本质内容

7.1.为了便于在软件缺陷管理数据库中寻找制定的测试缺陷
7.1.1.包含缺陷发生时的用户界面（UI）是个良好的习惯
7.2.例如记录对话框的标题、菜单、按钮等控件的名称

8.短行之间使用自动数字序号，使用相同的字体、字号、行间距

8.1.短行之间使用自动数字序号，使用相同的字体、字号、行间距
8.1.1.可以保证各条记录格式一致，做到规范专业

9.每一个步骤尽量只记录一个操作保证简洁、条理井然，容易重复操作步骤

10.确认步骤完整，准确，简短

10.1.保证快速准确的重复缺陷，完整即没有缺漏，准确即步骤正确，简短即没有多余的步骤

11.根据缺陷，可选择是否进行图象捕捉

11.1.为了直观的观察缺陷或缺陷现象，通常需要附加缺陷或缺陷出现的界面，
11.1.1.以图片的形式作为附件附着在记录的“附件”部分

11.2.为了节省空间，又能真实反映缺陷或缺陷本质
11.2.1.可以捕捉缺陷或缺陷产生时的全屏幕，活动窗口和局部区域

11.3.为了迅速定位、修正缺陷或缺陷位置，通常要求附加中文对照图

11.4.附加必要的特殊文档和个人建议和注解如果打开某个特殊的文档而产生的缺陷或缺陷
11.4.1.则必须附加该文档，从而可以迅速再现缺陷或缺陷

11.5.为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现，可以附加个人的修改建议或注解

12.检查拼写和语法缺陷

12.1.在提交每条缺陷或缺陷之前，检查拼写和语法，确保内容正确，正确的描述缺陷

13.尽量使用短语，避免复杂句型句式软件缺陷管理数据库的目的是便于定位缺陷
13.1.因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性

13.2.以上概括了报告测试缺陷的规范要求，随着软件的测试要求不同，测试者经过长期测试
13.3.积累相应的测试经验，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求

13.4.此外，经常阅读、学习其他测试工程师的测试缺陷报告
13.5.结合自己以前的测试缺陷报告进行对比和思考，可以不断提高技巧

14.缺陷描述内容

14.1.缺陷描述的内容可以包含缺陷操作步骤，实际结果和期望结果

14.2.操作步骤可以方便开发人员再现缺陷进行修正，有些开发的再现缺陷能力很差
14.3.虽然他明白你所指的缺陷，但就是无法再现特别是对系统不熟悉的新加入开发人员
14.4.介绍步骤可以方便他们再现

14.5.实际结果可以让开发明白错误是什么，期望结果可以让开发了解正确的结果应该是如何

三十.缺陷的生命周期

1.提交
2.确认
3.分配
4.修复
5.验证
6.关闭

三十一.发现缺陷后，应该怎么处理

1.首先咨询开发是不是bug，让他初步判断一下
2.如果不是bug，开发给到理由也比较充分，确实自己也搞错，也就算了
3.如果开发也认为是bug，那就直接提了
4.如果怀疑开发的解答，觉得是bug，开发坚持不是bug，就要咨询我们组长或者开发组长，让他们判断一下

三十二.提交缺陷，开发说不是缺陷，怎么处理

1.根据需求设计文档等相关资料进行需求确认和验证
2.提交到缺陷管理平台进行跟踪
3.组织项目相关人员产品，开发，架构和组长进行缺陷的复盘讨论
4.反馈给测试经理判断

三十三.缺陷的级别

L1：致命缺陷，一般不会提
L2：影响主流程
L3和L4：经常提

三十四.在项目中找到的经典缺陷

1.兼容性问题，在ie浏览器，提交订单按钮可以点击，到了谷歌，火狐就不能

2.查询订单页面，根据条件筛选的结果不是想要的结果，还有某些字段的值没有显示出来
2.1.或者显示错误（因为开发从库表取值有误）

3.付款成功后，订单状态一直不翻转为交易成功（因为代码没有正确获取库表中付款成功记录的状态码）
4.修改支付密码，新密码和原密码一致，也通过了，系统没有做新旧密码的校验
5.付款时候的手机验证码，可以一直使用，没有成功做有效期控制
6.手机app断开网络后，再去点击，没有友好的错误页面提示网络已断开，只有undefined返回

三十五.兼容性测试

1.各种系统兼容
2.各种浏览器兼容
3.各种网络环境兼容
4.各种数据库兼容

三十六.软件的安全性应从哪几个方面去测试

1.软件安全性测试包括程序、数据库安全性测试
1.1.根据系统安全指标不同测试策略也不同

2.用户认证安全的测试要考虑问题

2.1.明确区分系统中不同用户权限，系统中会不会出现用户冲突
2.1.1.系统会不会因用户的权限的改变造成混乱

2.2.用户登陆密码是否是可见、可复制 、是否可以通过绝对途径登陆系统
2.2.1.（拷贝用户登陆后的链接直接进入系统）

2.3.用户退出系统后是否删除了所有鉴权标记
2.3.1.是否可以使用后退键而不通过输入口令进入 系统

3.系统网络安全的测试要考虑问题 

测试采取的防护措施是否正确装配好
有关系统的补丁是否打上
模拟非授权
看防护系统是否坚固
采用成熟的网络漏洞检查工具检查系统相关漏洞
采用各种检查工具检查系统情况
采用各种防外挂工具检查系统各组程序的外挂漏洞

4.数据库安全考虑问题

系统数据是否机密（比如对银行系统是特别重要，一般的网站就没有太高要求）
系统数据的完整性（企业实名核查服务系统中就曾存在数据的不完整）
系统数据可管理性 
系统数据的独立性 
系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）

(1) 用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议
(2) 加密机制
(3) 安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描
(4) 数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理
(5) 防病毒系统

三十七.如何理解压力、负载、性能测试测试

1.性能测试是个较大的范围，实际包含性能、强度、压力、负载等多方面的测试内容

2.压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试
2.1.增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试

3.负载测试是压力相对较大的测试，主测试系统在一种或者集中极限条件下的相应能力
3.1.如100个用户对系统进行连续半个小时的访问可以看作压力测试
3.1.1.那么连续访问8个小时就可以认为负载测试
3.1.2.1000个用户连续访问系统1个小时也可以看作是负载测试

4.实际上压力测试和负载测试没有明显的区分
5.测试人员应该站在关注整体性能的高度上来对系统进行测试

三十八.测试非常紧急过程中，遇到阻塞性问题，对应的开发没有时间解决，如何推动问题解决

1.首先判断问题的严重性，向对应的开发了解问题的原因
2.然后再汇报给自己的测试组长和开发组长，让组长知情，咨询他们的意见
3.再把问题汇报给开发分组经理，让他们统一协调处理
4.安排经验丰富的高级开发人员来协助此开发解决问题，然后通过加班来完成问题解决和测试

三十九.什么是关系型数据库，主键，外键，索引分别是什么

1.关系型数据库是由多张能互相联接的二维行列表格组成的数据库

2.主关键字是表中的一个或多个字段，它的值用于唯一地标识表中的某一条记录

3.外键表示两个关系之间的相关联系
3.1.以另一个关系的外键作主关键字的表被称为主表，具有此外键的表被称为主表的从表
3.1.1.外键又称作外关键字

4.关系数据库中，索引是单独的、物理的
4.1.是对数据库表中一列或多列的值进行排序的一种存储结构
4.1.是表中一列或若干列值的集合和相应的指向表中物理标识值的数据页的逻辑指针清单

四十.什么是自动化测试框架

1.测试自动化框架是设置特定产品的自动化规则的集成系统
1.1.该系统集成了功能库，测试数据源，对象详细信息和各种可重复使用的模块
1.2.这些组件用作需要组装以代表业务流程的小型构建块
1.3.该框架为测试自动化提供了基础，并简化自动化工作

2.也是为自动化软件测试提供支持的假设框架，概念和工具的主要优点是维护成本低。
2.1.如果测试用例发生变化，只需要更新测试用例文件，驱动程序和启动脚本将保持不变
2.2.理想情况下，如果应用程序发生更改，则无需更新脚本

3.选择正确的框架/脚本技术有助于降低成本
3.1.与测试脚本相关的成本是由于开发和维护工作
3.2.测试自动化期间使用的脚本的方法对成本有影响

四十一.程序在Win上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题

1.检查系统是否有中毒的特征
2.检查软件/硬件的配置是否符合软件的推荐标准；
3.确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务；
4.如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的
5.在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。

四十二.给个网站，如何测试

1.首先，查找需求说明、网站设计等相关文档，分析测试需求

2.制定测试计划，确定测试范围和测试策略
2.1.包括：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试

3.设计测试用例

3.1.功能性测试

链接测试，链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回
多媒体元素是否可以正确加载和显示
提交功能的测试
多语言支持是否能够正确显示选择的语言等

3.2.界面测试

页面是否风格统一，美观
页面布局是否合理，重点内容和热点内容是否突出
控件是否正常使用
对于必须但未安装的控件，是否提供自动下载并安装的功能
文字检查

3.3.性能测试

压力测试
负载测试
强度测试

3.4.数据库测试

要具体决定是否需要开展
数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面

3.5.安全性测试

基本的登录功能的检查
相关开发语言的常见安全性问题检查，例如SQL注入等
是否存在溢出错误，导致系统崩溃或者权限泄露
如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持兼容性测试

3.6.兼容性测试

浏览器的兼容性
操作系统的兼容性
软件平台的兼容性
数据库的兼容性

4.开展测试，并记录缺陷
5.合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系
5.1.（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）
6.定期评审，对测试进行评估和总结，调整测试的内容