初级软件测试工程师面试题汇总2020

第一章软件测试理论基础

1.软件测试的概念？

使用人工或者自动手段来运行或者测试某个系统的过程。在规定条件下对程序进行操作从而发现问题，对软件质量进行评估的过程。

简而言之就是：为了发现程序中错误而执行程序的过程。

2.软件测试的目的？

1）软件测试为了发现程序存在的代码或业务逻辑错误；

2）软件测试为了检验产品是否符合用户需求；

3）软件测试为了提高用户的体验

3.软件测试主要测似乎用例设计方法？

1、白盒测试：逻辑覆盖、循环覆盖、基本路径覆盖

2、黑盒测试：等价类划分、边界值、因果图、判定表、场景法、流程分析法、错误推测法、正交表排序法。

4.软件测试的原则？

1）所有测试都应追溯到用户需求。

2）应当把尽早测试和不断测试作为座右铭。

3）2：8原则，测试80%的错误可能来源于20%的新增模块

4）对测试发现的错误结果写一个缺陷报告。

5）完全测试是不可能的，测试需要终止。

6）设计测试用例时应全面考虑各种情况。

7）制定严格的测试计划。

8）注意回归测试，对修改过的代码，重新测试确保没有引入新的错误。

5.  测试计划？

1）测试范围（功能性测试；非功能性测试）

2） 测试通过/失败的标准（通过准则；失败准则）

3）测试挂起恢复条件

4）测试进度人力分布计划

5） 测试交付物

6.  测试方案？

1) 测试环境（软硬件构成；网络构成；环境搭建；测试工具）

2) 测试策略

3) 测试风险评估与预防

4) 测试报告：

测试BUG记录

测试BUG统计分析

测试用例执行情况清单

遗留问题清单

7.  测试流程？

1）需求分析（用户\产品经理）

2) 编写测试计划（测试经理）

2）编写测试用例（测什么\怎么测）

3）评审测试用例

4）搭建测试环境

5）等待开发提交测试包

6）部署测试包

7）冒烟测试（对软件主体基本功能进行测试）

8）执行测试用例

9）Bug跟踪处理

8.  软件产品质量模型？

 软件产品质量模型对产品设计时需要考虑的地方进行高度概括。

1）功能性：在指定情况下，提供满足明确的功能。

2）可靠性：在指定条件下使用时，产品维持规定的性能级别。

第一：系统最好不出故障

第二：出故障不影响主要的功能和业务

第三：如果影响主要功能及业务，系统可以尽快恢复。

3)    易用性：易懂易学易用，漂亮好看（用户体验）

4)    效率性：产品性能

5)    可维护性：产品被纠正改进的能力

6)    可移植性：能从一种环境迁移到另一种环境

9.  单元测试？

单元测试又称模块测试，需要从程序的内部结构出发设计测试用例，多个模块可以平行的进行单元测试。

10.集成测试？

集成测试又称组装测试，通常是在单元测试的基础上，将所有程序进行有序，递增的测试，重点测试不同模块的接口部分。

11.系统测试？

将整个软件系统看作一个整体进行测试，包括对功能、性能、以及对软件所运行的软硬件环境测试。前期主要是测试功能是否满足需求，后期主要测试性能是否满足要求。系统在不同软硬件环境中的兼容性。

13.验收测试？

验收测试是最后一个阶段的测试操作，在软件产品投入正式运行前的所要进行的测试工作。和系统测试相比而言，验收测试与之的区别就只是测试人员不同，验收测试则是由用户来执行这一操作的。

（1）a测试：Alpha测试是在软件开发环境下由用户进行的测试，或者模拟实际操作环境进而进行的测试。Alpha测试主要是对软件产品的功能、局域化、界面、可使用性以及性能等等方面进行评价。

（2）B测试：Beta测试是在实际环境中由多个用户对其进行测试，并将在测试过程中发现的错误有效反馈给软件开发者。所以在测试过程中用户必须定期将所遇到的问题反馈给开发者。

 v模型优缺点？

1、优点：

1.包含了底层测试（单元测试）和高层测试（系统测试）；

2.清楚的标识了开发和测试的各个阶段；

3.自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。

2、缺点：

1.自上而下的顺序导致了，测试工作在编码之后，就导致错误不能及时的进行修改；

2.实际工作中，需求经常变化，导致v模型步骤，反复执行，返工量很大，灵活度较低。

3.改良：每个步骤都可以进行小的迭代工作。

14.w模型优缺点？

定义：开发一个v；测试一个v组合起来的模型（w模型也叫双v模型）

优点：

　　   1.测试伴随着整个开发周期，需求和设计同样要测试；

　　   2.更早的介入测试，可以发现初期的缺陷，修复成本低；

　　   3.分阶段工作，方便项目整体管理。

缺点：

　　   1.开发和测试依然是线性的关系，需求的变更和调整，依然不方便；

　　   2.如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高！

15.H模型优缺点？

H模型的优点：

　　>开发的H模型揭示了软件测试除测试执行外，还有很多工作；

　　>软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；

　　>软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；

　　>软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。

H模型的缺点：

　　>管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制；

　　>技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；

　　>测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难；

　　>对于整个项目组的人员要求非常高：在很好的规范制度下，大家都能高效的工作，否则容易混乱。例如：你分了一个小的迭代，但是因为人员技能不足，使得无法有效完成，那么整个项目就会受到很大的干扰。

总结：

　　v模型适用于中小企业，

　　w模型适用于中大型企业（因为人员要求高），

h模型人员要求非常高，很少有公司使用。

16. 测试用例定义？

测试用例是为特定的目的而设计的一组测试输入，执行条件，和预期的结果。简而言之：测什么，怎么测

17. 等价类划分法？

等价类划分属于黑盒测试，将不能穷举的测试过程进行分类，从而保证完整性和代表性。

（1）分类：

有效等价类：符合需求规格说明书，输入合理的数据集合。

无效等价类：不符合需求规格说明书，输入不合理数据。

（2）细节

考虑输入长度

考虑输入类型

组成规则

是否为空

是否区分大小写

是否重复

是否去除空格

18. 边界值？

边界值是指对于输入等价类和输出等价类而言，稍高于其边界值和稍低于边界值的情况。

19. 因果图法？

因果图法是一种利用图解法分析输入的各种组合情况设计测试用例的方法。

特点：

（1）考虑输入条件的相互制约及组合关系

（2）考虑输出条件对输入条件的依赖关系

因：输入条件

果：输出条件

20.判定表法？

因果图只是一种辅助工具，通过分析最终得到判定表，再通过判定表编写测试用例。

判定表的组成：

（1）条件桩：问题的所有条件

（2）动作桩：问题的所有输出

（3）条件项：针对条件桩的取值

（4）动作项：各种条件区取值情况下输出的结果

20. 场景发？

场景发就是模拟用户操作软件的场景，主要用于测试系统的业务流程。

（1）基本流：按照正确的业务流程实现操作

（2）备选流：导致程序出现错误的操作流程

21. 流程分析法？

流程分析法，又叫场景设计法

三个流程

（1）基本流：通过业务流程输入都为正确的，能够最终达到目标的流程，如atm机取款，插入银行卡-输入正确的密码-输入正确的金额-取钱-取卡

（2）备选流：通过实现业务流程时，因错误操作或异常输入，导致流程存在反复，但最终能够达到预期的操作流程，如atm机取款，插入银行卡-输入错误的密码-重新输入正确的密码-输入金额-取钱-取卡

（3）异常流：通过实现业务流程时，因错误操作或异常输入，导致没有完成业务流程，如atm机取款，插入银行卡，输入三次错误的密码，吞卡

使用方法

（1）根据需求，确定业务流程

（2）绘制流程图，再次明确流程路径

（3）根据业务流程图，抽取测试路径，每个路径包含一个从未走过的路径

（4）细化路径，抽取测试用例

22.错误推测法？

指利用直觉或者经验猜出错误的可能，列举出程序中容易出错或者有可能的错误，常适用于经验丰富的测试人员。

22. 正交表排序法？

使用最少的抽样数据达到最广的，覆盖率最高的统计结果。

在一个界面中有多个控件，每个控件有多个取值，测试要考虑不同控件不同取值之间的组合 ，但是组合数量较大（>20种，20种以下一般用因果图/判定表），没有必要全部测试，如何从所有组合中挑选最少的组合测试，并能得到最优的测试效果—使用正交排列法。

正交排列法和判定表法的主要异同：

1、都是用来测控件的组合问题

2、判定表法适合测组合数量较少的情况

3、正交排列法适合测组合数量较多的情况

4、判定表（因果图）会反映控件之间的限制和组合关系

5、正交排列表只需反映控件之间的组合关系。

三、解析正交表公式

Ln(m^k)

L：line  行

n：表示正交表有几行，需要测试的组合的个数

n值是固定的，一旦正交表确定n值就是固定的，不需要测试人员自己计算。

m：表示正交表中允许出现的最大值

根据每个控件的取值个数来确定m值

k：表示正交表有几列

根据组合的控件个数进行确定

四、使用正交表测试的步骤：

步骤1：分析需求--- 列出需要组合的控件以及每个控件的取值（excel）

步骤2：选择一个合适的正交表 

选择正交表，其实就是确定正交表的m值和k值的过程。

23. 软件缺陷？

软件缺陷是指软件产品中所存在的问题。最终表现为用户所需功能没有完全实现，没有满足用户的需求。

24. 软件缺陷的表现形式？

（1）功能或者特性没有实现或者部分实现。

（2）设计不合理，功能不明确，逻辑不清楚。

（3）产品实际结果与预期结果不一致。

（4）没有达到需求规格说明书指定的性能指标。

（5）运行出错，中断，系统崩溃，界面混乱。

（6）数据不正确，精度不够，格式不统一。

（7）用户不接受的其他问题。

25. 缺陷的状态？

（1）提交：已提交的缺陷。

（2）打开：确认提交的缺陷，等待处理

（3）拒绝：拒绝提交的缺陷，不需要修复或者不是缺陷。

（4）修复：缺陷被修复

（5）关闭：确认修复的缺陷，将其关闭。

（6）推迟：推迟到以后解决。

26. 缺陷的分类？

1、系统缺陷

（1）由程序引起的死机，异常退出。

（2）程序死循环

（3）程序错误，不能执行重要功能。

2、数据缺陷

（1）数据计算错误

（2）数据约束错误

（3）数据输入，输出错误。

3、数据库缺陷

（1）数据库发生死锁

（2）数据库的表未加约束条件

（3）数据库连接错误

（4）数据表中有过多空字段

4、接口缺陷

（1）数据通信错误

（2）程序接口错误

5、功能缺陷

（1）功能无法实现

（2）功能实现错误

6、安全性缺陷

（1）用户权限无法实现

（2）超时

（3）访问控制

（4）加密错误

7、兼容性缺陷

（1）与需求规定兼容性不符

8、性能缺陷

（1）未达到预期的性能指标

（2）性能测试中的错误，导致无法继续

9、界面缺陷

（1）操作界面错误

（2）打印内容，格式错误

（3）删除未给提示

（4）界面不规范

27. 缺陷报告注意的事项？

（1）尽量保证缺陷可以重现

（2）简洁、准确、完整。

（3）一个缺陷报告只写一个缺陷

28. 缺陷书写规范？

（1）标题：保持简洁，准确

（2）步骤：重现测试的步骤，完整，有顺序，明确

（3）实际结果：执行步骤后的结果

（4）预期结果：列出期望的结果

（5）提供附件：图片或者截图

29. 缺陷的跟踪？

（1）新建提交的缺陷为”新建“状态。

（2）再确认有效之后为”打开“状态

（3）开发人员修改后”已修复“状态。

（4）测试人员需要回归测试，如果bug已修复，状态改为”已解决“状态。

30. 你会搭建测试环境？

测试环境=硬件+软件+网络+数据准备+测试工具

（1）硬件

计算机系统：windows系统，Linux系统，macos系统

1）Linux系统的命令和操作必须熟练。

2）Linux系统包括：centos、ubuntu

3）明确软件对硬件的需求：cpu个数、内存大小、硬盘大小

4）了解各种操作系统：Linux命令、安装系统、配置ip

（2）软件

1）当前被测的软件以及相互依赖交互的软件

2）将被测软件部署在linux系统上

3）依赖和交互的软件如：JDK、tomcat、数据库

（3）网络

1）基本网络协议：tcp、udp、http

2）Linux ip和路由配置

3）Linux命令抓包

（4）数据准备

1）准备测试数据

2）测试数据在测试用例阶段设计好

3）少量，正常数据可以手工测试，大量数据通过测试工具。

（5）测试工具

1）接口测试：jmeter/postman

2）压力和性能测试：loadrunner

3）抓包工具：fiddler/wireshark

4）测试管理工具：禅道、bugfree、jira、bugzilla

31. 成为优秀软件测试工程师具备的能力？

1）认真、负责、严谨、耐心地态度

2）有过硬的技术本领：测试理论、测试工具、数据库、开发知识

3）沟通能力十分重要：除了与开发沟通，还要和不同的产品、运营、客服等打交道。如何准确，简洁，严谨的描述bug。

4）逻辑思维能力：重要的是去寻找bug产生的真正原因，准备找到问题的源头。

32. fiddler抓包工具?

（1）概念？

Fiddler是位于客户端和服务端的http代理，为目前最常用的抓包工具之一。

（3）功能？

1)   检查所有浏览器的所有http/https流量

2)   查看、分析请求内容细节

3)   伪造客户端请求和服务器响应

4)   测试网站的性能

5)   解密https的web会话

6)   全局、局部断点

（4）使用场景？

1）接口调试

2）接口测试

3）线上环境调试

4）Web性能分析

5）判断前后端bug

6）开发环境

7）Host 配置

8）弱网断网测试

 

33. http协议？

超文本传输协议，用于从万维网服务器传输超文本到本地浏览器。http是基于请求和响应模式的无状态应用层协议。

完整的http包括请求和响应两块内容：

（1）http请求报文

主要是由请求行、请求头部、空一行、请求正文四部分组成。

1）请求方法：

Get（请求资源），

Post（提交资源），

head（获取响应头），

put（替换资源），

delete（删除资源），

option（允许客户查看服务器性能），

url（统一资源定位符）

2）请求头部：

Host（主机ip地址/域名）

User-agent（客户机相关信息）

Accept（指定客户端接收数据类型比如：.jpg/html）

Accept-charset(客户端接受的字符集比如：gbk/utf-8)

Accept-language(可接受的语言)

Cookie（携带的cookie信息）

Referer（当前文档url）

Content-type(请求内容类型)

content-length（数据长度）

（2）http响应报文

主要是由状态行、响应头部、空行、响应正文组成。

1）状态行：请求的协议及版本

状态码：服务器响应状态的3位数字代码

1xx：提示信息，请求被成功接收

2xx：成功，请求被成功处理 200

3xx:重定向 304

4xx：客户端错误 404

5xx：服务端错误 500

 

2）响应头部

Server（http服务器软件信息）

Date（响应报文时间）

Exprise(缓存过期时间)

set-cookie（设置cookie）

Last-modified（最后修改时间）

Content-type/content-length

 

 

第二章 Linux环境安装部署及基本命令

Linux目录结构如下：

• bin (binaries)存放二进制可执行文件
• sbin (super user binaries)存放二进制可执行文件，只有root才能访问
• etc (etcetera)存放系统配置文件
• usr (unix shared resources)用于存放共享的系统资源
• home 存放用户文件的根目录
• root 超级用户目录
• dev (devices)用于存放设备文件
• lib (library)存放跟文件系统中的程序运行所需要的共享库及内核模块
• mnt (mount)系统管理员安装临时文件系统的安装点
• boot 存放用于系统引导时使用的各种文件
• tmp (temporary)用于存放各种临时文件
• var (variable)用于存放运行时需要改变数据的文件

linux命令基本格式

cmd [options] [arguments]，options称为选项，arguments称为参数

选项和参数都作为Shell命令执行时的输入，它们之间用空格分隔开。

• Linux是区分大小写的

一般来说，后面跟的选项如果单字符选项前使用一个减号-。单词选项前使用两个减号--

• 这是一般的情况，有些命令还是不归属这种规律的(相对较少)~~~
• 例子：ls -a和ls -all，a 单个字符使用一个-，一个单词all 使用两个--

在Linux中，可执行的文件也进行了分类：

• 内置命令：出于效率的考虑，将一些常用命令的解释程序构造在Shell内部。
• 外置命令：存放在/bin、/sbin目录下的命令
• 实用程序：存放在/usr/bin、/usr/sbin、/usr/share、/usr/local/bin等目录下的实用程序
• 用户程序：用户程序经过编译生成可执行文件后，可作为Shell命令运行
• Shell脚本：由Shell语言编写的批处理文件，可作为Shell命令运行

通配符：

学过一些正则表达式的或者有点基础的同学对通配符应该就不陌生的了，在Linux也有通配符(在搜索的时候挺有用的)

• *：匹配任何字符和任何数目的字符
• ?：匹配单一数目的任何字符
• [ ]：匹配[ ]之内的任意一个字符
• [! ]：匹配除了[! ]之外的任意一个字符，!表示非的意思

常见的文件操作命令：

1）可用 pwd命令查看用户的当前目录

2)   可用 cd 命令来切换目录

　　.表示当前目录

　　.. 表示当前目录的上一级目录（父目录）

　　-表示用 cd 命令切换目录前所在的目录

　　~ 表示用户主目录的绝对路径名

3）ls命令（查看当前目录下的内容）

　　ls-l   显示详细列表相当于ll

　　ls-lh  将数据大小按人性化显示

　　ls-a    显示所有文件，包含隐藏文件

4）mkdir 创建文件夹

　　mkdir  tupian在当前目录下创建文件夹

　　mkdir /home/admin/tupian 以绝对路径创建文件夹

　　mkdir /home/admin/a/tupian -p 如果上级目录不存在，加上-p会自动创建父目录

　　mkdir a b  在当前目录下创建多个文件夹

5）touch 创建空文件

　　touch  a.txt  在当前目录下创建文件

　　gedit a.txt  使用记事本打开文件

6）rm删除文件或者文件夹

　　rm  a.txt   删除文件

　　rm abc -r       删除文件夹

　　rm *   删除所有（不能删除隐藏文件）

7）cp  拷贝文件

　　cp  1.txt   2.txt  将1.txt内容复制到2.txt

　　cp   abc   abcx  -r   拷贝文件夹

8）mv  移动文件（相当于剪切）

　　mv  1.txt  2.txt  剪切文件

　　mv  abc    abx  剪切文件夹

9）cat 查看文件内容或者合并内容

　　cat 1.txt 把文件的内容显示到窗口中

　　cat 1.txt  2.txt  将两个文件合并的内容显示到窗口中

10） grep  查找文件内容

　　grep  hello  a.txt  在文件a.txt中查找“hello”　　

　　grep -niv   hello  a.txt  (n:显示行号，i:不区分大小写，v:反向查找，查找不含hello的内容）

11） find  查找文件　　

　　find  /home  -name 1.txt   查找名为1.txt的文件

　　find /home -name  "*txt"    查找所有以txt结尾的文件

12）tar 打包归档

　　tar  cvf  a.tar   1.txt  2.txt (f必须放在最后，a.tar指打包后的文件）

　　tar  tf   a.tar  列出包里的文件

　　tar   xvf    a.tar     解开文件并放到当前目录

13）less| more  分页显示文件文档内容，可以向前后翻

14）head  显示文档前面的内容，默认显示前十行

常见的系统操作命令

1）top 显示当前系统资源消耗最多的进程

2）date 显示当前系统时间

3）ps -e   显示当前所有进程、环境变量

4）ps -ef  全格式显示

5）ps  -a  显示所有用户所有进程

6 ）kill -9 ss 强制杀死一个进程

7）压缩、解压　

gzip 涉及参数说明：

-k 保留源文件 -d 解开压缩文件 -r 递归处理，将指定目录下的所有文件及子目录一并处理 -v 显示指令执行过程

压缩：

gzip -k ./* #当前目录下所有文件进行压缩，每个文件一个gz包

gzip -rkv ./* 递归压缩

解压：

gzip -dv test.gz 

bzip2:

bzip2 -zk test #压缩test文件

bzip2 -dk test.bz2 #解压

其他命令：

1)、启动mysql服务：systemctl start mysql；service mysqld start

2)、解压文件：tar –zxvf 文件名

3)、创建用户分组：groupadd 分组名

4)、创建新用户：useradd 用户名

5)、下载安装文件：yum install -y文件名

6)、编辑文件：vi 文件名

7)、保存： :wq

8)、强制退出：:q!

9)、创建文件：mkdir 文件名

10)、本机复制文件：cp file /remote_file/file

11)、移动文件：mv file /remote_file/file

12)、多台主机传输文件：scp local_file remote_username@remote_ip:remote_folder（需要注意的是需要知道目标主机的密码密码以及网络通畅）

13)、删除文件：rm –rf file

14)、查看主机信息：top

15)、查看进程：ps –ef | grep mysql

16)、查看端口：netstat -tunlp | grep 3306

17)、杀死进程：kill -9 进程号

18)、切换目录：cd

19)、显示磁盘信息：df –h

20)、Docker

 

 

 

 

第三章  测试相关面试题

1、你的测试职业发展是什么?

1）测试经验越丰富，测试能力越高。所以我觉得的职业发展是需要时间积累的，一步步向着高级测试工程师奔去。

2）而且我也有初步的职业规划，前3年积累测试经验，按如何做好测试工程师的要点去要求自己，不断更新自己改正自己，做好测试任务。

1、巩固基础测试知识，提高理解需求能力。

2、学习自动化测试，并且运用。技术到尾后学习带领测试团队。

3、最后争取达到测试经理水平。

2、你认为测试人员需要具备哪些素质？

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

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

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

3、软件测试工程师需要具备的能力？

1）业务分析能力：分析整体业务流程、分析被测业务数据、分析被测系统架构、分析被测业务模块、分析测试所需资源、分析测试完成目标；

2）缺陷洞察能力：一般缺陷的发现能力、隐性问题的发现能力、发现连带问题的能力、发现问题隐患的能力、尽早发现问题的能力、发现问题根源的能力；

3）团队协作能力：合理进行人员分工、协助组员解决问题、配合完成测试任务、配合开发重现缺陷、督促项目整体进度、出现问题勇于承担；

4）专业技术能力：掌握测试基础知识、掌握计算机知识、熟练运用测试工具；

5）逻辑思考能力：判断逻辑的正确性、对可行性逻辑分析、站在客观角度思考；

6）问题解决能力：技术上的问题、工作中的问题、沟通问题；

7）沟通表达能力：和技术人员、产品人员、上下级的沟通；

8）宏观把控能力：有效控制测试时间、有效控制测试成本、有效制定测试计划、有效进行风险评估、有效控制测试方向。

4、结合你以前的学习和工作经验，你认为如何做好测试？

　根据我以前的工作和学习经验，我认为做好工作首先要有一个良好的沟通，只有沟通无障碍了，才会有好的协作，才会有更好的效率，再一个就是技术一定要过关，做测试要有足够的耐心，和一个良好的工作习惯，不懂的就要问，实时与同事沟通这样的话才能做好测试工作。

5、说说你对软件配置管理的理解？

　项目在开发过程中要用相应的配置管理工具对配置项(包括各个阶段的产物)进行变更控制，配置管理的使用取决于项目规模和复杂性及风险的水平。软件的规模越大，配置管理就越显得重要。还有在配置管理中，有一个很重要的概念，那就是基线，是在一定阶段各个配置项的组合，一个基线就提供了一个正式的标准，随后的工作便基于此标准，并只有经过授权后才能变更这个标准。配置管理工具主要有CC，VSS,CVS,SVN等，我只用过SVN，对其他的工具不是很熟悉。

6、怎样写测试计划和测试用例？

　简单点，测试计划里应有详细的测试策略和测试方法，合理详尽的资源安排等，至于测试用例，那是依赖于需求(包括功能与非功能需求)是否细化到功能点，是否可测试等。

7、做好软件测试的一些关键点？

　1-测试人员必须经过测试基础知识和理论的相关培训

　2-测试人员必须熟悉系统功能和业务

　3-测试要有计划，而且测试方案要和整个项目计划协调好

　4-必须实现编写测试用例，测试执行阶段必须根据测试用例进行

　5-易用性，功能，分支，边界，性能等功能行和非功能性需求都要进行测试

　6-对于复杂的流程一定要进行流程分支，组合条件分析，再进行等价类划分准备相关测试数据

　7-测试设计的一个重要内容是要准备好具体的测试数据，清楚这个测试数据是测试那个场景或分支的。

　8-个人任务平均每三个测试用例至少应该发现一个BUG，否则只能说明测试用例质量不好。

 

8、软件测试员自身素质培养？

　1-首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在开发过程中不管遇到什么样的困难，相信一定能克服

　2-善于怀疑，实际上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事情，我却认为可能发生，别人认为是对的，我却认为不是对的。

　3-打破沙锅问到底的精神，对于只出现过一次的BUG一定要找出原因，不解决誓不罢休。

　4-保持一个良好的心情，否则可能无法把测试做好。不要把生活中的不愉快的情绪带到工作中来。

　5-做测试时要细心，不是所有的BUG都能很容易找出，一定要细心才能找到这些BUG。

　6-灵活一些，聪明一点，多造一些容易产生BUG的例子。

　7-在有条件的情况下，多和客户沟通，他们身上有你所需要的。

　8-设身处地为客户着想，从他们的角度去测试系统。

　9-不要让程序员，以“这种情况不可能发生”这句话说服你，相反，你应该去说服他，告诉他在客户心理，并不是这样的

　10-考虑问题要全面，结合客户的需求，业务流程和系统的架构等多方面考虑问题。

　11-提出问题不要复杂化，这点和前面矛盾，如果你是一个新手，暂时不要管这点，因为最终将有你的小组成员讨论解决。

　12-追求完美，对于新测试员来说，努力追求完美，这对你很好，尽管有些事情无法做到，但你应该尝试。

　13-幽默感，能和开发小组很好的沟通是关键，试着给你的开发小组找一个BUG杀手，或对他们说“我简直不敢相信，你写的程序居然到现在没有找到BUG”。

9、你所熟悉的软件测试类型有哪些?

　测试类型有：功能测试、性能测试、界面测试

　1）功能测试在测试工作中占有比例最大，功能测试也叫黑盒测试。

　2）性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。

　3）界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。

　4）区别在于，功能测试关注产品的所有功能，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注产品整体的多用户并发下的稳定性和健壮性。界面测试则关注与用户体验相关内容，用户使用该产品的时候是否已用，是否易懂，是否规范(用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告)。做某个性能测试的时候，首先它可能是个功能点，首先要保证她的功能是没有问题的，然后再考虑性能的问题。

10、您认为做好测试计划工作的关键是什么?

　1）明确测试的目标，增强测试计划的实用性

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

　2）坚持“5W”规则，明确内容与过程

　“5W”规则指的是“WHAT(做什么)”、“WHY(为什么做)”、"WHEN(何时做)"、"WHERE(在哪里)"、"HOW(如何做)"。利用“5W"规则创建软件测试计划，可以帮助测试团队理解测试的目的(WHY)，明确测试的范围和内容(WHAT)，确定测试的开始和结束日期(WHEN)，指出测试的方法和工具(HOW)，给出测试文档和软件存放的位置(WHERE)。

　3）采用评审和更新机制，保证测试计划满足实际需求

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

　4）分别创建测试计划与测试详细规格、测试用例

　应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

11、当开发人员说不是BUG时，你如何应付?

　开发人员说不是BUG，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动。3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的一句是什么?如果被用户发现或出了问题，会有什么不良结果?程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来，跟开发经理和测试经理进行确认，如果要修改就改，如果不要修改就不改。其实有些真的不是BUG，我也只是建议的方式写进测试文档中，如果开发人员不修改也没有大问题。如果不是BUG的话，一定要坚持自己的立场，让问题得到最后的确认。

12、文档测试主要包含什么内容?

　在国内软件开发管理中，文档管理几乎是最弱的一项，因而在测试工作中特别容易忽略文档测试也就不足为奇了。要想给用户提供完整的产品，文档测试是必不可少的。文档测试一般注重下面几个方面：

　1）文档的完整性：主要是测试文档内容的全面性与完整性，从总体上把握文档的质量。例如用户手册应该包括软件的所有功能模块。

　2）描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度。例如用户手册基本完整后，我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度。

　3）易理解性：主要是检查文档对关键、重要的操作有无图文说明，文字、图表是否易于理解。对于关键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明了。

　4）文档中提供操作的实例：这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是否丰富，提供的实例描述是否详细。只有简单的图文说明，而无实例的用户手册看起来就像是软件界面的简单拷贝，对于用户来说，实际上没有什么帮助。

　5）印刷与包装质量：主要是检查软件文档的商品化程度。有些用户手册是简单打印、装订而成，过于粗糙，不易于用户保存。优秀的文档例如用户手册和技术白皮书，应提供商品化包装，并且印刷精美。

13、配置和兼容性测试的区别是什么?

　配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否与不同的软件正确协作。

　配置测试的核心内容就是使用各种硬件来测试软件的运行情况，一般包括：

　(1)软件在不同的主机上的运行情况，例如Dell和Apple;

　(2)软件在不同的组件上的运行情况，例如开发的拨号程序要测试在不同厂商生产的Modem上的运行情况;

　(3)不同的外设;

　(4)不同的接口;

　(5)不同的可选项，例如不同的内存大小;

　兼容性测试的核心内容：

　(1)测试软件是否能在不同的操作系统平台上兼容;

　(2)测试软件是否能在同一操作系统平台的不同版本上兼容;

　(3)软件本身能否向前或者向后兼容;

　(4)测试软件能否与其它相关的软件兼容;

　(5)数据兼容性测试，主要是指数据能否共享;

　配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统等。具体进行时仍然按照测试用例来执行。

14、完全测试程序是可能的吗?

　软件测试初学者可能认为拿到软件后需要进行完全测试，找到全部的软件缺陷，使软件“零缺陷”发布。实际上完全测试是不可能的。主要有以下一个原因：

　1）完全测试比较耗时，时间上不允许;

　2）完全测试通常意味着较多资源投入，这在现实中往往是行不通的;

　3）输入量太大，不能一一进行测试;

　4）输出结果太多，只能分类进行验证;

　5）软件实现途径太多;

　6）软件产品说明书没有客观标准，从不同的角度看，软件缺陷的标准不同;

　因此测试的程度要根据实际情况确定。

15、所有的软件缺陷都能修复吗?

　从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试人员要做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队，要做的是对每一个软件缺陷进行取舍，根据风险决定那些缺陷要修复。发生这种现象的主要原因如下：

　1）没有足够的时间资源。在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且在项目中没有预算足够的回归测试时间，再加上修改缺陷可能引入新的缺陷，因此在交付期限的强大压力下，必须放弃某些缺陷的修改。

　2）有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进行修复。

　3）不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有时间时考虑再处理。

　最后要说的是，缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复，不同角色的人员从不同的角度来思考，以做出正确的决定。

16、软件测试人员就是QA吗?

　软件测试人员的职责是尽可能早的找出软件缺陷，确保得以修复。而质量保证人员(QA)主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。测试人员的主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象。

　软件测试和质量是相辅相成的关系，都是为了提高软件质量而工作。

17、测试产品与测试项目的区别是什么?

　习惯上把开发完成后进行商业化、几乎不进行代码修改就可以售给用户使用的软件成为软件产品，也就是可以买“卖拷贝”的软件，例如Windows2000。而通常把针对一个或者几个特定的用户而开发的软件成为软件项目，软件项目是一种个性化的产品，可以是按照用户要求全部重新开发，也可以修改已有的软件产品来满足特定的用户需求。项目和产品的不同特点，决定我们测试产品和测试项目仍然会有很多不同的地方：

　1）质量要求不同。通常产品的质量要高一些，修复发布后产品的缺陷成本较高，甚至会带来很多负面的影响。而做项目通常面向某一用户，虽然质量越高越好，但是一般只要满足用户要求就可以了。

　2）测试资源投入多少不同。做软件产品通常是研发中心来开发，进度压力要小些。同时由于质量要求高，因此会投入较多的人力、物力资源。

　3）项目最后要和用户共同验收测试，这是产品测试不具有的特点。

　此外，测试产品与测试项目在缺陷管理方面、测试策略制定都会有很大不同，测试管理者应该结合具体的环境，恰如其分的完成工作。

18、如何编写提交给用户的测试报告?

　随着测试工作越来越受重视，开发团队向客户提供测试文档是不可避免的事情。很多人会问：“我们可以把工作中的测试报告提供给客户吗?”答案是否定的。因为提供内部测试报告，可能会让客户失去信心，甚至否定项目。

　测试报告一般分为内部测试报告和外部测试报告。内部报告是我们在测试工作中的项目文档，反映了测试工作的实施情况，这里不过多讨论，读者可以参考相关教材。这里主要讨论一下外部测试报告的写法，一般外部测试报告要满足下面几个要求：

　-根据内部测试报告进行编写，一般可以摘录;

　-不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道;

　-报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的;

　-报告上面的内容尽量要真实可靠;

　-整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告。

　总之，外部测试报告要小心谨慎的编写。

19、测试工具在测试工作中是什么地位?

国内的很多测试工程师对测试工具相当迷恋，尤其是一些新手，甚至期望测试工具可以取代手工测试。测试工具在测试工作中起的是辅助作用，一般用来提高测试效率。自动化测试弥补了手工测试的不足，减轻一定的工作量。实际上测试工具是无法替代大多数手工测试的，而一些诸如性能测试等自动化测试也是手工所不能完成的。

对于自动测试技术，应当依据软件的不同情况来分别对待，一般自动技术会应用在引起大量重复性工作的地方、系统的压力点、以及任何适合使用程序解决大批量输入数据的地方。然后再寻找合适的自动测试工具，或者自己开发测试程序。一定不要为了使用测试工具而使用。

　20、详细的描述一个测试活动完整的过程？

1）项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后sqa进入项目，开始进行统计和跟踪

2）开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。

3）测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

4）测试用例完成后，测试和开发需要进行评审。

5）测试人员搭建环境

6）开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现bug后提交给bugzilla。

　 7）开发提交第二个版本，包括bug fix以及增加了部分功能，测试人员进行测试。

　 8）重复上面的工作，一般是3-4个版本后bug数量减少，达到出货的要求。

　 9）如果有客户反馈的问题，需要测试人员协助重现以及回归测试。

　21、在您以往的工作中，一条软件缺陷(或者叫bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(bug)记录?

　1）在传统的bugzilla中，bug描述应该包括以下的信息

　2）和bug产生对应的软件版本

　3）开发的接口人员

　4）bug的优先级

　5）bug的严重程度

　6）bug可能属于的模块，如果不能确认，可以用开发人员来判断

　7）bug标题，需要清晰的描述现象

　8）bug描述，需要尽量给出重新bug的步骤

　9）bug附件中能给出相关的日志和截图。

　高质量的bug记录就是指很容易理解的bug记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。

22.软件的生命周期（prdctrm）？

计划阶段（planning）-〉需求分析（requirement）-〉设计阶段（design）-〉编码（coding）->测试（testing）->运行与维护（running maintrnacne）

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

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

制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试

设计测试用例：

①功能性测试可以包括，但不限于以下几个方面：

链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。

提交功能的测试。

多媒体元素是否可以正确加载和显示。

多语言支持是否能够正确显示选择的语言等。

②界面测试可以包括但不限于一下几个方面：

页面是否风格统一，美观

页面布局是否合理，重点内容和热点内容是否突出

控件是否正常使用

对于必须但未安装的控件，是否提供自动下载并安装的功能

文字检查

③性能测试一般从以下两个方面考虑：

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

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

⑤安全性测试：

基本的登录功能的检查

是否存在溢出错误，导致系统崩溃或者权限泄露

相关开发语言的常见安全性问题检查，例如SQL注入等

如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持

⑥兼容性测试，根据需求说明的内容，确定支持的平台组合：

浏览器的兼容性；

操作系统的兼容性；

软件平台的兼容性；

数据库的兼容性

开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。

定期评审，对测试进行评估和总结，调整测试的内容.

24.软件产品质量特性是什么?

功能性：适应性、准确性、互操作性、依从性、安全性。

可靠性：成熟性、容错性、易恢复性。

可使用性：易理解性、易学习性、易操作性。

效率：时间特性、资源特性。

可维护性：易分析性、易变更性、稳定性、易测试性。

25.测试计划编写6要素（5W1H）？

why——为什么要进行这些测试；

what—测试哪些方面，不同阶段的工作内容；

when—测试不同阶段的起止时间；

where—相应文档，缺陷的存放位置，测试环境等；

who—项目有关人员组成，安排哪些测试人员进行测试；

how—如何去做，使用哪些测试工具以及测试方法进行测试

26.BUG管理工具的跟踪过程（用BugZilla为例子）

1.测试人员发现了BUG，提交到Bugzilla中，状态为new，BUG的接受者为开发接口人员。

2.开发接口将BUG分配给相关的模块的开发人员，状态修改为已分配，开发人员和测试确认BUG，如果是本人的BUG，则设置为接收；如果是别的开发人员的问题，则转发出去，由下一个开发人员来进行此行为；如果认为不是问题，则需要大家讨论并确认后，拒绝这个BUG，然后测试人员关闭此问题。

3.如果开发人员接受了BUG，并修改好以后，将BUG状态修改为已修复，并告知测试在哪个版本中可以测试。

4.测试人员在新版本中测试，如果发现问题依然存在，则拒绝验证；如果已经修复，则关闭BUG。

27.LoadRunner分为哪三个模块？请简述各模块的主要功能。

Virtual User Generator：用于录制脚步

Mercury LoadRunner Controller：用于创建、运行和监控场景

Mercury LoadRunner Analysis：用于分析测试结果

28：你所了解的的软件测试类型都有哪些？

（1）按测试策略分类：1、静态与动态测试2、黑盒与白盒测试 3、手工和自动测试 4、冒烟测试 5、回归测试；

（2）按测试阶段分类：单元测试、集成测试、系统测试、验收测试；

（3）其他常见测试方法：1、功能测试 2、性能测试 3、压力测试 4、负载测试 5、易用性测试 6、安装测试 7、界面测试 8、配置测试 9、文档测试 10、兼容性测试 11、安全性测试 12、恢复测试

29、您是否了解以往所工作的企业的软件开发过程？如果了解，请试述一个完整的开发过程需要完成哪些工作？分别由哪些不同的角色来完成这些工作？您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？

开发过程---需求调研（需求人员）、需求分析（需求人员）、概要设计（设计人员）、详细设计(设计人员)、编码（开发人员）

测试过程---需求评审、系统测试设计、概要设计评审、集成测试设计、详细设计评审、单元测试设计、测试执行

测试工作的整个过程都做过，擅长做测试设计

过程决定质量，软件的过程改进正是为了提高软件的质量，将过往的种种经验教训积累起来。

30、如何理解压力、负载、性能测试测试?

性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。

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

（2）负载测试是压力相对较大的测试，主要是测试系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。100个用户对系统进行连续半个小时的访问可以看作压力测试，那么连续访问8个小时就可以认为负载测试，1000个用户连续访问系统1个小时也可以看作是负载测试。

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

31、在搜索引擎中输入汉字就可以解析到对应的域名，请问如何用LoadRunner进行测试？

1、建立测试计划，确定测试标准和测试范围

2、设计典型场景的测试用例，覆盖常用业务流程和不常用的业务流程等

3、根据测试用例，开发自动测试脚本和场景：

4、录制测试脚本：新建一个脚本（Web/HTML协议）；点击录制按钮，在弹出的对话框的URL中输入”about:blank”；在打开的浏览器中进行正常操作流程后，结束录制；调试脚本并保存，可能要注意到字符集的关联。

5设置测试场景：针对性能设置测试场景，主要判断在正常情况下，系统的平均事务响应时间是否达标；针对压力负载设置测试场景，主要判断在长时间处于满负荷或者超出系统承载能力的条件下，系统是否会崩溃；执行测试，获取测试结果，分析测试结果

32、STAR法则？

S（situation）：项目属于什么类型，周期多长

T（task）：团队分工，你的角色

A（action）：具体实施，自己做了什么

R（result）：最后成果，你的收获

33、问：我现在有个程序，发现在Windows上运行的很慢，怎么判别是程序存在问题还是软硬件系统存在问题？

1、检查系统是否有中毒的特征

2、检查软件/硬件的配置是否符合软件的推荐标准

3、确认当前的系统是否独立，即没有对外提供什么消耗CPU资源的服务

4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成

5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况

 

34、针对添加购物车这个测试点说一下你要怎么测试“添加购物车”？

参考答案（从增删改查角度思考）

1、购物车的初始状态（即GUI）。

2、能否加入购物车，同一件商品能否再次添加到购物车。

3、购物车商品件数的上限限制。

4、购物车是否可以正常移除商品，移除商品后，能否再添加回来。

5、添加的每种商品是否可以正常增减数量，数量大于0。

6、退出购物车，再去查询购物车，商品是否正常。

7、购物车的商品可以全选，取消全选，可以复选，选中的商品和数量可以正常下单。

8、商品添加到购物车以后，已下架，购物车是否会提示此宝贝已失效。

9、商品添加到购物车以后，库存不足了，是否会有提示。

 

35互联网第三方基金销售公司，你们要做哪些测试？

　　答：这个好像内容较多，具体我们做了哪些类型测试，我可以说这个系统什么样的测试都做了，比如：

          1. 业务规则测试

          2.功能测试

          3.用户界面测试

          4. 接口测试

          5. 性能测试

          6.迁移测试

          7.兼容性测试和安全测试等，

其中我认为做的比较好的是性能测试、迁移测试和接口测试，因为中间碰到过非常多的坑，而且也成功挑战；其中也踩过很多坑，也有太多的酸甜苦辣，当然对我和团队来讲，能力的成长也是几何式的增长；就像我的技术大领导说的，如果你能成功挑战这么复杂的业务系统，和这么庞大的系统架构，其它公司系统测试你在看，你会发现都是非常轻松的，想想也是这个道理；有句话说的话，要想做一件事非常容易，哪你应是非常努力去做，才能看起来很容易，好像这话很绕，道理就是这样的。

36.测试类型分类？

1 用户界面测试，用户界面测试是对所有人机交互界面提供的操作和显示界面进行的测试，一般我们都是对照需求文档及设计稿进行检查；

2 功能测试，针对软件需求规格说明书中的功能进行逐项进行的测试验证，检查是否满足要求；

3 性能测试，通过用采用工具模拟系统，并发一定虚拟用户，对系统造成一定负载，来检查系统的各项性能指标进行测试，这里的性能测试我们更侧重讲的是整个系统性能测试来谈，当然性能测试常见的分类一般会分为基准测试，负载测试，压力测试，容量测试和稳定性测试；

3.1 基准测试，简单理解就是检查系统在并发1个用户时，各系统性能指标是否正常，以次做为一个基线，来检查后续修改是否造成系统倒退；

3.2 负载测试，更侧重要系统所处于某个固定负载，各系统性能指标是否正常；

3.3 压力测试，系统处于一定并发用户时，性能的拐点，系统所能承受到的最大压力是多少？

3.4 容量性测试，通常是检查系统在承受具体业务量时，是否可以支持，如：最常见的短信容量，存储空量容量，数据增长容量达到多少时处理效率降低；

3.5 稳定性测试，通常是和可靠性测试联系在一起，一般我们会检查系统在一定并发值范围内，挂续72小时来检查系统是否可以正常，当然内部测试一般采用8小时制；

4 接口测试，接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点；数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等；

备注：有些公司接口测试是属于开发人员工作，测试人员不用需接触，但从个人发展来看，接触越多，测试人员才有更多的发展机会 

5 兼容性测试，是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能够很友好的运行的测试；

6 安全测试，是有关验证应用程序的安全服务和识别潜在安全性缺陷的过程；

7 边界测试或极限测试，就是用来探测和验证代码在处理极端的或偏门的情况时会发生什么，通常针对输入域/输出域的边界，当然还有（1、数据结构的边界；2、状态转换的边界；3、功能界限的边界或端点。）

备注：边界测试其实更应是一种测试方法或是思维，严格来讲不应算是一种测试类型，所以我增加叫“极限测试”

8 可安装性测试和反安装性测试，在目标环境安装软件的安装程序所进行的测试，比如安装QQ，需要在各操作系统环境下检查，这个很好理解；

9 可靠性测试，也称软件的可靠性评估，指根据软件系统可靠性结构(单元与系统间可靠性关系)、寿命类型和各单元的可靠性试验信息，利用概率统计方法，评估出系统的可靠性特征量；

备注：这个一般做的比较少，通常一般在偏像通讯行业比较多，我平时所接触到朋友中；

10 可恢复性测试，检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统，也有人叫自愈测试，其实就是当我们系统出现问题时，系统是否可以恢复到正常。 

11  配置测试，检查系统在某种配置下是否可以正常运行，这个很好理解，如大家经常谈买什么样的电脑？什么样的配置才是最好的，性价比最高的？我这里更强调的系统的配置，比如我接触过有的系统当我们在上线前，通常对线程开几个，在某个特定系统下进行检查验证，会有一个合理值，好像和兼容性测试很类似，其实并不是一回事；

12  敏感性测试，发现在有效输入类中可能引起某种不稳定性或不正常处理的某些数据的组合而进行的测试。例：输入敏感词汇

13 标准符合性测试，验证软件与相关国家标准或规范（如军用标准、国家标准、行业标准及国际标准）一致性的测试，如：通讯行业或是航天等都有各自标准，这个也很好理解，就像我们日常生活用品一样，你不会买没达到标准的产品吧，万一有毒呢？

14 中文本地化测试，就是将软件版本语言进行更改，检查是否符合当地语言，在特定环境下是否正常，如微信的操作系统，这个估计很好理解，大家都接触过；

15  文档测试，检查系统交付给用户时，所附属的文档测试，通常是照着文档进行验证，如：系统帮助、用户使用手册、用户安装手册，这个很好理解；

16 易用性测试，系统是否用学习，易用使用，易于理解，通常由专有的用户体验师团队负责；

17 数据完整性测试，检查针对系统对数据进行操作，重点是检查数据一致性，完整性，正确性测试，如果你做过支付测试，估计对这块是非常敏感，我目前做支付测试，数据库测试可以说是我们工作的重中之中；

18  迁移测试，检查系统从某个环境迁移到另一个环境，重点是检查新旧系统之间数据是否兼容，各业务是否可以正常，如：将oracle数据库切换成mysql，或是将历史会员数据迁移升级成新系统架构中

 

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　第四章  数据库相关知识

数据库（视图、事务、存储过程、函数） && 数据库备份

1. 视图：

 视图就是通过查询得到一张虚拟表，然后保存下来，下次直接使用即可 （视图就是查询得到的虚拟表）

视图的特点：

　　1.视图的列可以来自不同的表，是表的抽象和逻辑意义上建立的新关系；

　　2.视图是由基本表（实表）产生的表（虚表）；

　　3.视图的建立和删除不影响基本表；

　　4.对视图内容的更新（添加、删除和修改）直接影响基本表；

　　5.当视图来自多个基本表时，不允许添加和删除数据。

  注意：1、在硬盘中，视图只有表结构文件，没有表数据文件，数据来源于原始表  

       2、视图一般只用于查询，一般不修改表中的数据，在公司一般不使用视图

-- 创建视图

　　create view 视图名 as sql语句;

　　create view v1 as select id,name from userinfo;

-- 使用视图

　　select * from 视图名;

　　select * from v1;

-- 更新视图

　　alter view 视图名 as sql语句;

　　alter view v1 as select id,name from userinfo where id<10;

-- 删除视图

    drop view 视图名;

    drop view v1;

2. 事务

事务：开启一个事务可以包含一些sql语句，这些sql语句要么同时成功  要么一个都别想成功，称之为事务的原子性

（1）原子性（atomicity）。一个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。

（2）一致性（consistency）。事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。

（3）隔离性（isolation）。一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。

（4）持久性（durability）。持久性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。

create table user(

id int primary key auto_increment,

name char(32),

balance int

);

 

insert into user(name,balance)

values

('wsb',1000),

('egon',1000),

('ysb',1000);

start transaction;

 

# 修改操作

update user set balance=900 where name='wsb'; #买支付100元

update user set balance=1010 where name='egon'; #中介拿走10元

update user set balance=1090 where name='ysb'; #卖家拿到90元

# 回滚到上一个状态

rollback;

# 开启事务之后，只要没有执行commit操作，数据其实都没有真正刷新到硬盘

commit;

"""开启事务检测操作是否完整，不完整主动回滚到上一个状态，如果完整就应该执行commit操作"""

3. 触发器

触发器：监视某种情况，并触发某种操作；对某个表进行【增/删/改】操作的前后如果希望触发某个特定的行为时，可以使用触发器，触发器用于定制用户对表的行进行【增/删/改】前后的行为。

触发器创建语法四要素：

　　1.监视地点(table)

　　2.监视事件(insert/update/delete)

　　3.触发时间(after/before)

　　4.触发事件(insert/update/delete)

创建触发器语法        

create trigger 触发器名 after/before insert/update/delete

　　on 表名 for each row  -- 这句是固定的

begin

　　-- begin和end中间放置需要执行的sql语句

end

 

after/before：只能选一个 , after(后置触发), before(前置触发)

insert/update/delete：只能选一个

 

使用触发器

-- 商品表

create table goods_tb(

  id int primary key auto_increment,

  name varchar(20),

  num int

); 

-- 订单表

create table order_tb(

    oid int primary key auto_increment,

    gid int,

    gnum int

); 

-- 添加3条商品数据

insert into goods_tb(name,num) values('商品1',10),('商品2',10),('商品3',10);

4. 存储过程

存储过程：存储过程是为了完成某个数据库中的特定功能而编写的语句集合；该语句集包括SQL语句（对数据的增删改查）、条件语句和循环语句等......当主动去调用存储过程时，其中内部的SQL语句会按照逻辑执行。

无参数存储过程

-- 看现有的存储过程

    show procedure status; 

-- 创建存储过程（无参数示例）

    create procedure p1()

    begin

    select * from t1;

    end

-- 调用存储过程

    call 存储过程名称(参数类型 参数名 数据类型);

-- 删除存储过程

    drop procedure 存储过程名称;

有参数存储过程

create procedure p2(in i int,inout io varchar(50))

begin

update goods_tb set name=io where id=i;

end

set @io="商品100";   # 设置初始值

call p2(3,@io);     # 执行存储调用

select @io;         # 拿到结果

create procedure p3(in i int,out o varchar(50))

begin

select name into o from teacher where id = i;

end

set @name=null;

call p3(1,@name);

select @name;

对于存储过程，可以接收参数，其参数有三类：
in           仅用于传入参数用
out         仅用于返回值用
inout      既可以传入又可以当作返回值

# 存储过程优点：

    1.存储过程增强了SQL语言灵活性

        存储过程可以使用控制语句编写，可以完成复杂的判断和较复杂的运算，有很强的灵活性

    2.减少网络流量，降低了网络负载

        存储过程在服务器端创建成功后，只需要调用该存储过程即可，而传统的做法是每次都将大量的SQL语句通过网络发送至数据库服务器端然后再执行

    3.存储过程只在创造时进行编译，以后每次执行存储过程都不需再重新编译

        一般SQL语句每执行一次就编译一次，所以使用存储过程可提高数据库执行速度

# 存储过程缺点：    

    1.扩展功能不方便

2.不便于系统后期维护

 

5. 函数

MySQL中提供了许多内置函数

-- 创建自定义函数

create function func1(

    i1 int,

    i2 int)

returns int  -- 设置返回类型

begin

    declare num int;  -- 声明num类型

    set num=i1+i2;

    return(num);

end

 

-- 调用自定义函数

select func1(1,5);

在sql语句中使用自定义函数

select func1(参数1,参数2),字段名 from 表名;

删除自定义函数

drop function 自定义函数名;

函数与存储过程的区别：