测试复习第一站

面试问题：
1.什么是软件测试？

软件功能是否满足客户的需求。
目的：找BUG，验证是正确的
注意事项：
1.不要背答案
2.结合目前学习,写代码的一些体会
3.结合生活的一些案例
对本人来说：软件测试就是在完成了自己的项目后，进行多方面测试，比如临界值，不同环境下，跳转上然后找到BUG，将项目完成的更好，还有与自己预期结果的做一个对比，验证是不是满足自己的需求。代码实现相当于只是完成了框架，就像盖房子一样一个毛坯房，而软件测试就是装修，最后入住的一定是装修过没有问题的新家。

同时在这里我们可以对软件测试的流程进行了解：

1.需求分析，需求评审
需求分析和评审是对客户的需求进行分析看是否可行，需要怎么进行测试。
2.编写测试计划：
编写测试计划通俗的讲就是什么人在什么时间做什么事，最后产出什么东西。
也就是测试人员要测试那些模块，在什么期限提交什么文档。
3.编写测试用例，用例评审
测试用例就是想好被测试物品，用什么方法测试验证它的功能一系列。
评审：主要审核测试用例不能想当然的测试，作为测试工程师需要有“破坏性”想法测试软件。
4.执行测试，提交BUG，回归测试：
bug是缺陷，发现后需要提交给开发人员修改，然后进行回归测试，验证bug是否被修复。
5.编写测试总结报告
bug都改好了后，要编写测试总结报告，这款软件的质量如何。

千万需要注意不要与软件生命周期混淆

软件的生命周期：

需求分析
软件设计
程序编码
软件测试
运行维护

2.为什么要做软件测试？

本人回答：本人认为软件测试是必不可少的一项，尤其在我们实现了一些功能，后会进行验证，不断的修复bug可以将项目进行优化，给用户提供更好的产品。也是个人性格方面，遇到问题不是很害怕，喜欢追根溯源找到产生问题的源头。

3.作为一个合格的软件测试人员应该具有哪些素质？

本人回答：掌握一门技术语言，熟悉网络数据库，了解Linux的一些基本指令这些
一定要具有很良好的沟通能力，遇到代码bug上的一些问题的时候我们是需要与研发工作人员对接，相比较告诉研发工作人员的有bug，不如直接告诉我们找到bug导致了什么样的问题总结起来，也可以减少研发相对应的工作。同时也需要对自己有收获的东西进行总结归类，一方面是沉淀提升个人能力，也会锻炼解决问题的思维。

3.研发与测试(测开)的区别？

测开区别与测试：
1.掌握自动化
2.具有代码能力
研发与测试的区别：
1.目的：研发完成开发任务（完成），测试验证（研发完成的正确性）。
2.阶段：研发主要参与编码，测试是贯传整个软件的生命周期。
3.开发工具不同
4.方法（研发 if else for等）（测试黑盒白盒包括一些测试用例编写的方法）
5.发展方向（研发：技术：架构师其他：CEO）
6.工作内容：研发：根据需求通过代码来实现。测试：借助工具验证开发人员的代码。

三大概念：

需求：

符合正式文档规定的条件和权能，分为用户需求和软件需求
用户需求：比较粗，只是大概的功能描述。
软件需求：可以指导项目组成员进行下一步工作。研发人员可以设计，编码。测试可以编写测试用例。

BUG：

与需求规格说明书（前提需求正确）或用户期望（合理期望）不匹配的

测试用例：

向被测试的程序输入的一组集合：
要素：测试环境，测试数据，测试步骤，预期结果，备注，测试版本，前提条件等…

软件的生命周期：需求-计划-设计-编码-测试-运行维护。

研发模型：瀑布模型：

特点：串型
适合的项目：需求相对稳定的项目，已有类似的项目。
缺点：
1.发现缺陷的时机比较晚，修改缺陷的成本高
2.过程中积累的经验不能及时的分享给其他项目。
3.测试是最后环节，让人觉得测试不重要。

螺旋模型：

特点：渐进式（每环进行风险分析）
强调：风险
适合的项目：复杂度高，风险大，规模庞大。
优点：项目的风险低。
缺点：风险分析需求时间，增加时间成本，项目进度缓慢。

增量，迭代：

目的：减少项目的风险。
适用：大型项目
增量：第一次发布10个功能，第二次发布10个功能且对第一次发布的功能不会造成影响。不需要修改
迭代：第一次发布，第二次发布，第二次发布会对第一次的有影响：必须修改第一次发布中的一些功能。

敏捷：

宣言：
1.轻文档
2.客户参与
3.拥抱变化
4.人与人的沟通

scrum敏捷模式:
核心角色：
PO （产品负责人）
SM（敏捷教练）
TEAM
特点：人员要求5-10人
站会：时间不超多15分钟
迭代周期：1-4周
敏捷开发的流程：PO整理user story—发布计划会议（项目进行几次迭代）–迭代会议（分配任务，确认时间）–研发中–研发完成–测试中–测试完成（完成一个给待发布里面放一个）–待发布–发布上线

传统的开发模型：只关注结果。敏捷开发：不仅关注结果，更关注过程。

传统的开发模型与敏捷开发模型的区别：
传统的开发模型有什么？
他们的特点是什么？
敏捷的开发模型和特点？
主要区别于传统开发模型：敏捷开发模型轻文档，客户参与，更新迭代快，注重沟通

敏捷测试：

1.不依赖文档–重在沟通，自己的文档–思维导图
2.迭代频繁–调整自己，尽力适应。

软件测试的常用类型：

1、单元测试

这是在开发人员级别使用的最基本的测试，测试人员专注于单元代码的单个部分，而它已经从任何外部交互或依赖于任何模块之前被隔离。这个测试要求开发人员检查他们编写的最小代码单元，并证明单元可以独立工作

2.集成测试：

在开发人员级别上，在单元测试之后，还应该仔细检查这些最小代码的组合(或集成)。集成测试提供了访问网络、数据库和文件系统的测试模块。
它们将指示数据库和网络在合并到整个系统时是否运行良好。最重要的是，在前一阶段测试的小代码单元之间的连接将在这个阶段被证明。

3.功能测试：

毫无疑问，功能测试是更高级别的测试类型，应该在集成测试之后使用。
功能测试检查输出与规范中定义的输入的准确性。对中间值不太重视，但对所创建的最终输出给予了更多的关注。

4.冒烟测试：

冒烟测试的类比来自于电子产品，其中一个问题意味着电路板散发出烟雾。
在功能测试完成之后，在新安装和更新的输入值之后，将在起始点执行一个简单的测试.

5.回归测试

当系统中出现复杂的bug时，通常会影响系统的核心区域，所以使用回归测试来重新测试系统的所有模块

6.UI测试：

除了上面的核心测试类型， UI测试现在也是一个众所周知的，在软件工程行业非常流行。该图形用户界面测试确保了对所有用户友好的特定应用程序或产品。UI测试主要评估设计组件，如布局、颜色、字体、大小等等。另外， UI测试可以手动和自动执行。

当然这不是完整的测试分类列表，因为目前已经有超过150种的测试类型，并且仍在增加中。另外请注意，并非所有测试类型都适用于所有项目，这仍然取决于项目的性质以及测试范围。

测试模型：
V模型：
是串行所以结合瀑布模型一样具有：发现bug时间晚，修复起来成本大，不能及时分享项目经验，测试为最后环节。
在这里插入图片描述
W模型：
强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。

在这里插入图片描述
W模型的优点：

有利于尽早全面地发现问题。从需求分析开始测试工程师就参与到项目的测试中，当需求分析完成后，测试工程师就需要参与到需求的验证和确认活动中，并需要提供可测试性需求分析说明书，这样可以尽早地发现需求阶段的缺陷。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。

缺点：

存在局限性，需求、设计、编码等活动被视为是串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一阶段工作，这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑。

W模型的特征：

(1)测试阶段划分得更全面，不仅仅是单元测试、集成测试和系统测试;

(2)测试与开发是并行的，从需求测试就应该开始介入;

(3)提出尽早测试的概念，这样可以降低缺陷修复成本;

(4)测试对象不仅仅是程序，还包括需求或其他的相关文档。

软件测试能够适应敏捷开发模式：车轮模型

在这里插入图片描述

“车轮”模型是一种以用户需求和用户反馈为驱动，以测试为核心、用于迭代开发模式的测试模型。由于用户需求和用户反馈是增量式的递交，所以产品开发过程是不断重复循环的。测试渗透在产品开发的全过程中，跟踪每一个环节的输入和输出。在“车轮”模型中，测试直接对需求负责，保证产品在各个阶段都是符合需求的，测试对象是产品生命周期全过程。

“车轮”模型中的测试是一个独立的流程，其中包括：测试管理和测试执行。测试管理是指，对测试计划、测试说明、测试资源、源程序、测试用例、测试环境、测试脚本、测试报告、缺陷单等进行管理，同时对测试人员进行合理分工。测试执行是指，测试人员在分配到任务后，对测试对象进行相应的测试，包括：接口测试、功能测试、集成测试、系统测试、回归测试等。

由于测试在“车轮”模型中处于核心位置，跟踪产品生命周期的全过程，所以对测试人员的要求也较高。测试人员除了能熟练执行接口测试、功能测试、集成测试、系统测试、回归测试等基础测试，还需要具备需求分析、文案编辑能力，同时还需要有一定的编码能力，能理解程序的实现算法。

模型详述:

（１）需求分析阶段：①测试需求文档，提出需求缺陷，跟踪缺陷修改情况；②参加需求评审，协助制定验收标准；③根据最终确定的需求文档编写测试计划；④根据需求文档、业务流程，设计测试流程。

（２）产品设计阶段：①对原型进行测试，提出原型缺陷，跟踪缺陷修改情况；②根据需求文档、业务流程和原型，设计功能测试用例。

（３）详细设计阶段：①测试详细设计文档，提出设计缺陷，跟踪缺陷修改情况；②根据详细设计文档编写接口测试计划，设计接口测试用例和测试脚本；③根据详细设计文档、数据字典搭建测试环境，准备测试数据。

（４）编码实现阶段：①对已完成编码的接口进行接口测试；②集成通过接口测试的接口进行模块测试；③根据需要选择进行压力测试、性能测试、稳定性测试、兼容性测试、安全性测试、自动化测试；④跟踪缺陷，不断进行回归测试。

（５）系统集成阶段：①集成全部模块进行系统测试；②完成测试报告；③编写用户手册；④收集β测试中的用户反馈，对用户反馈进行核查筛选确定系统缺陷，跟踪缺陷修改情况；⑤协助实施人员完成系统部署和产品上线。

模型优势:

和常用测试模型相比，“车轮”模型有如下优点：

（１）强调测试对象不是代码而是整个产品生命周期，每一个可交付的中间件都需要通过适当的方式进行测试，真正实现了“全过程”测试，提高了软件测试质量［１２］。

（２）由于测试在项目启动初期就参与其中，保证了测试和开发过程的密切衔接，确保能在第一时间发现错误。

（３）现实中的开发不是一种串行的活动，在大多数情况下是交叉进行的，那么相应的测试也不存在严格的先后关系。“车轮”模型适应了这一现实状况，让各阶段的测试（如：接口测试、集成测试、系统测试、回归测试等）跟随开发进度反复触发、循环迭代。

（４）将测试活动完全独立出来，同时采取敏捷方法，及时响应并全程跟踪，完全实现了测试和开发的同步。

（５）体现了客户、产品经理、开发人员以及测试人员之间的交互，当需求发生变更时能够及时调整方案。并且测试结果实时反馈，也保证了测试质量。

模型应用实施

将“车轮”模型应用到一个社会治理网格化微信公众号的开发项目中，该项目包括公众号前台开发和后台管理平台开发。其中的志愿者模块完全依照“车轮”模型进行全程测试。首先，产品经理与客户沟通需求并完成需求文档后，将需求文档交付给测试人员和开发人员进行评估。在此阶段测试人员会对需求的可行性、合理性及完整性进行测试，并将需求缺陷提交给产品经理。之后产品经理会根据测试提交的缺陷以及开发反馈的意见重新补充并修改需求文档。需求文档定稿后，产品经理、开发人员和测试人员共同参与需求评审会议，制定产品验收标准。

接下来，产品经理根据需求文档完成产品原型的设计后，将原型交付给开发人员和测试人员。在此阶段对原型进行测试，主要包括：界面是否美观；配色是否合理；交互是否友好；操作步骤是否简单；功能是否齐全；使用场景是否全覆盖；逻辑是否合理；操作流程是否顺畅等。测试人员将原型缺陷提交给产品经理后，产品经理会根据测试缺陷以及开发意见对原型进行修改，最终确定原型。

开发人员根据原型进行详细设计阶段，测试人员同时设计编写测试用例。对于需要进行接口测试的部分，测试人员依据开发人员提供的接口说明书设计编写接口测试脚本。在此阶段测试人员还要搭建测试环境，准备测试数据。

由于志愿者模块内还细分了多个小模块，开发人员会将逐个完成的小模块提测给测试人员。测试人员对提测的模块会先进行冒烟测试，确保提测内容的主要功能已通，可以进行后续的全面测试。如在冒烟测试过程中发现阻塞缺陷立即打回给开发人员重新编码。于是整个开发实现过程是一种边开发边测试的状态。当所有小模块全部完成后，开发人员会集中修复测试人员提交的缺陷，而测试人员会不断回归测试已修复的缺陷。

最后测试人员还要再整体进行系统测试、兼容性测试以及并发测试。当已知缺陷全部修复完成后，产品达到验收条件即可上线并交付给客户使用。

配置管理，评审，变更：

配置管理：
工具：Git，SVN
管理什么：软件，文档版本，代码，工具，数据—配置项
评审：
核心文档，测试用例，设计文档，需求，计划类
代码（代码走查，代码审查，CODERIVWER）
变更：
提交申请–评估风险–变更–验证–发布
一旦变更，配置管理也要变更。

缺陷

缺陷描述：
要素：测试环境，测试数据，测试步骤，预期结果，实际结果，附件，级别，优先级…
缺陷级别：
崩溃，严重，一般，次要，建议
A-B-C-D-E与级别相对应。
缺陷状态及转换：
状态：NEW,OPEN,FIXED,DELAY,REJECTED,CLOSE,REOPEN
在这里插入图片描述
如何开展第一次测试：
1.学习项目相关的文档
2.参加项目会议
3.获取项目相关的管理，使用地址，用户名密码等
4.学习相关的规范（编写测试用例，提交缺陷，使用工具）
5.积极主动（与项目成员接触）

如何发现更多的BUG
1.两个28原则：（模块，人员）
80%的缺陷是由20%的模块引起，或者出自20%的研发人员。
2.不要依赖测试用例和需求
3.逆向思维，发散性，扩展性
4.测试要尽早介入（如果需求时就存在bug，可以降低后期的成本）

面试题：提交一个缺陷研发人员不认可怎么办？

先自查，确认缺陷。
不能站在自己角度是认为“缺陷”，需要站在用户的角度上考虑。
缺陷级别定位准确。
提高自身的业务能力与技术水平。
第三方进行评审。

测试用例

测试用例是为了实施测试向被测试系统提供的一组集合，这组集合包含：测试环境，操作步骤，测试数据，预期结果等…

测试用例的设计方法：（都是黑盒测试方法使用在系统测试中）

基于需求的设计方法
等价类
边界值
因果图
正交排列
场景设计法
错误猜测法

基于需求

根据需求来写测试用例：
难点在于：需要读出除需求以外的测试点。
例：（买一款3000元以下的华为智能手机）
我们已知信息：3000以下，智能，品牌但是我们购买过程中是需要做一些基本的测试确保手机可以使用等一些测试。

等价类

思想：解决输入无穷的问题
目的：减少测试用例
使用场景：只针对于输入
概念：无穷的输入进行N个归类，从每一类中提取一个数据进行测试，如果这个数据测试通过就表示，这一个类测试通过。
有效等价类：符合要求，满足客户需求。
无效等价类：有效等价类以外。

边界值

使用场景：输入和输出
概念：输入和输出的“边界值”
等价类的一种补充方法，和等价类成对出现。
取值：
【1，50】（0,1,50,51）
（1,50】（1,2,50,51）

因果图（根据因果图可以清楚知道输入输出的关系，从而根据依赖编写测试用例）

使用场景：强调的是输入（原因）和输出（结果）的关系。
概念：强调的输入（原因）和输出（结果）关系，适用于有多个输入，并且输出依赖于输入。
恒等与或非
步骤：
1.梳理出所有的输入。
2.梳理出所有的输出。
3.梳理出输入和输出的关系。
4.画因果图
5.画判定表--------列数（通过计算得出）
输出：幂数 ------------输入：底数

恒等：
在这里插入图片描述
与：

或

案例：
假设业务单据的处理规则为：“淘宝618活动，提单已提交，订单合计金额大于300元或有红包，则进优惠”。

对于这条业务规则，首先通过分析所有可能的输入和可能的输出，可以得到如下结果：
● 输入：订单已提交、金额大于300、有红包。
● 输出：优惠、不优惠。
然后，进行第二步，找出输入与输出之间的对应关系。通过分析，可以看出有以下的对应关系。
(1)订单已提交，订单金额大于300元，则优惠。
(2)订单已提交，订单金额小于等于300元，无红包，不优惠
(3)订单已提交，有红包，则优惠。
(4)订单已提交，订单金额大于300元，有红包，则优惠。
(5)订单未提交，不优惠。
为了方便画出因果图和判定表，需要对所有输入和输出编号，现在编号如下。
1：订单已提交。
2：订单金额大于300元。
3：有红包
21：优惠
22：不优惠
画因果图

在这里插入图片描述
判定表：我们输入的条件是3个，结果是两个所以：222=8个

正交排列法（采用抽样，减少测试用例区别于等价类不解决输入无穷问题）

思想：正交表------正交实验（抽样）
两条性质：（画图重点遵守这个性质来画图）
1.任何列中出现的数字的个数一样。
2.任何两列中有序对数出现的次数一样。
目的：减少测试用例
看起来与等价类的目的一样。但是这里是有区别的正交排列是需要满足性质通过抽样来满足减少测试用例的，等价类主要是解决输入无穷的问题的。
公式：L=N（TC）
L 正交表
N 实验次数------ 通过水平和因素计算：公式是 N=(T-1)*C+1
T 水平== 变量的取值
C 因素== 变量
.
步骤：
1.理出所有的因素
2.理出所有的水平
3.选一个合适正交表
4.画出正交表，水平带进去。
5.第一行就是一条测试用例
6.最后将（特殊的）需要测试的数据加进去，补充测试用例

例：
1、因素：姓名、邮箱、密码、确认密码、验证码
2、水平：填写、不填写
我们算出N=6
水平是偶数个，所以们的测试用例可以是8,10 都行但是最少不低于6
在这里插入图片描述
这里我们可以添加特殊的一些测试用例：

场景法：(不同事件流，可能会有不同的结果，根据不同场景编写测试用例)

理解为业务流程：把各个孤立的功能点串起来，但是一个业务流程不一定是一个场景（一条分支代表一个场景）
.
事件，事件流。
什么是事件，什么又是事件流呢？
我们举例说明：
一个登陆界面，点击登陆按钮做为案例。
事件：
1,判断用户名是否存在
2.判断用户名和密码是否正确
3.判断用户状态是否正确
4.判断用户是否激活
5.click或者submit
以上每一个单独的都是一个事件
事件流：
我们点击登录按钮后：事件是如何在后台如何执行，是以一个什么样的逻辑？
1-2-3-4-5 ？
4-3-1-2-5 ？
这样的将事件串起来的执行，称为事件流。