测试分类及面试技巧

黑盒测试：

　　把测试的对象看成是一个黑色的盒子的，看不到里面内部的结构，是对软件的一种功能性的测试。

白盒测试：

　　就是把测试的对象看成是一个透明的盒子，能够看见被测软件的内部结构，是单元测试的一种形式，是针对程序的内部代码的一种测试形式。

灰黑测试：

　　它是介于黑盒测试与白盒测试中间，具体的来说就是测试开发工程师（测试工程师）能够看开发的代码，进行代码的走查，和参与开发代码的评审。

测试编写代码的分类：

　　1、手工测试 

　　2、自动化测试（UI自动化测试，接口自动化测试）：通过工具或者是代码的形式来模拟人的操作，来对被测试的产品进行自动化测试的操作。

现在企业要的是什么样的人？

P6

1. 技术方面能够主导公司技术发展。
2. 技术层面能够独立的负责公司层面的项目。
3. 可以和客户以及公司各个不同职能的人来解决问题。

要求：能够独立的负责一个产品的测试，能够很好的做功能测试，以及在自动化测试需要开展的时候又能很好的参与到自动化的测试，以及在性能测试开展的时候又能够很好的参与进去。

 

软件质量的六大特性：

功能性：软件需要满足用户显示或者隐式的功能

易用性：软件易于学习和上手使用。

可靠性：指的就是软件必须实现需求当中指明的具体功能。

效率性：类似于软件的性能。

可维护性：要求软件具有将某个功能修复之后继续使用的功能。

可移植性：当前软件可以从一个平台移植到另一个平台上去使用的能力。

 

什么是算法？

　　在程序里面，指的是做一件事需要的步骤。

什么是程序？

　　程序=数据结构+算法。

数据结构：

　　队列：先进先出

　　栈：先进后出

算法：

　　<：小于

　　==：等于

　　>：大于

　　!=：不等于

　　&&：并且（至少两个条件的关系）

　　||：或者(至少两个条件满足一个就没可以了)

 

软件分类：

B/S（WEB）的产品测试经验。app的测试经验

小程序的产品（依赖于微信&支付宝）

WEB/APP/小程序

 

冒烟测试：

　　开发把编写好的程序转给测试的时候，程序首先需要做的是针对转测的程序进行正常流程的测试，这个过程叫冒烟测试。

针对被测程序的正常流程的测试，目的是验证程序正常流程可以执行通的情况下继续测试被测程序的其他功能

探索性测试：

　　探索性强调测试⼈员的主观能动性，抛弃繁杂的测试计划和测试⽤例设计过程，强调在碰到问题时及时改变测试策略。

 

 

测试用例有哪些部分组成?

测试⽤例组成元素

⽤例ID；

⽤例名称；

测试⽬的；

测试级别；

参考信息；

测试环境；

前提条件；

测试步骤；

预期结果；

设计⼈员。

 

测试⽤例组成元素最核心的部分

⽤例名称；

前提条件；

测试步骤；

预期结果；

 

安全测试：

　　主要是针对被测软件进行安全的考虑，目前主要使用的技术是渗透测试。

回归测试：

　　产品都已经测试完成了，在准备上线的情况下，针对产品进行第N次的测试。回归测试目前主要是大量的自动测试来承担这部分的任务。

 

测试环境：

　　1、系统已有功能的测试（回归）

线上环境：

　　1、系统已有功能的测试

　　2、这对本次上线新功能的回归测试

 

工作第一天内容：

1、熟悉环境，熟悉身边的人，梳理清楚谁是你的负责人。

2、安装电脑的常用软件（java环境,Python环境,postman,jmeter,offer办公软件,思维导图软件,foxmail,git）

3、看需求文档

 

第二天的内容：

　　1、 继续看需求文档

 

看需求文档抓住核心的东西：

　　1、产品是给谁服务的？

　　2、产品的核心流程是什么？ 核心流程最好使用思维导图的模式把流程梳理出来

　　3、如果产品里面有专业术语（咨询产品或者是自己百度搜索）

　　4、梳理出产品哪些逻辑不是很清楚，梳理出来后，专门约产品经理或者是其他测试，让对方协助我们来讲解下这部分

三天：产品经理，身边的测试

 

toB:商家

toC:消费者

B2C商对客

 

为什么要需求分析：

　　软件测试需求是设计测试⽤例的依据。

　　有助于保证测试的质量和进度

　　软件测试需求是衡量测试覆盖率的重要指标

 

软件测试需求分析步骤

　　列出需求⽂档中的具有可测性的原始需求

　　对每⼀条需求进⾏细化分解，形成可测试的分层描述的测试点

　　对形成的每⼀个测试点，从软件产品的质量需求来分析，确定测试执⾏时需要实施的测试类型。

　　建⽴测试需求跟踪矩阵，对测试需求进⾏管理

 

测试点分析：

　　通过分析需求描述中的输⼊、输出、处理、限制、约束等，给出对应的验证内容（功能测试）

　　各个模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在给你交互的功能项，给出对应的验证内容（功能业务测试）

考虑到需要的完整性，要充分覆盖软件需求的各种特征，包含隐性需求的验证，⽐如界⾯的验证，异常情况（界⾯、易⽤性、兼容性、安全性、性能）

 

测试⽤例步骤：

　　拿到测试需求 -> 分析需求（画思维导图） -> 编写⽤例 -> 划分⽤例优先级

 

编写测试用例的三种方式：

　　1、思维导图 结构化看起来非常的好，但是不够细

　　2、使用excel，特点是写起来非常浪费时间，但是非常细

　　3、checklist 只考虑被测对象的大概的点

 

你之前测试用例写了多少个？

这个之前还真没有数过，我个人认为数这个没多大意义，更多应该考虑的是把测试的对象的测试点考虑周全

 

你对加班怎么看？假设我们每天需要加班到10点，你会接受吗？

 如果公司需要我加班这边我会服从公司安排

环境：

　　1、测试环境：给测试使用的环境，指的是一个产品还没上线前测试的环境

　　2、预发布环境：介于测试环境与线上环境中间，但是它也是可以给客户使用的环境，一般不开放，只供研发内部人员使用

　　3、线上环境：给真实的用户使用的环境

等价类与边界值结合起来使用

等价类：把输入的数据可以分为有效的数据和无效的数据

被测试的对象输入的数据：

1. 有效的数据
2. 无效的数据

测试一个产品，需要考虑它的正确场景，也要考虑它的异常场景

边界值：边界值测试用例是针对等价类测试用例方法的补充，因为等价类测试用例的方法只考虑到了输入数据的有效数据和无效数据，但是没有考虑到边界情况。

因果图与正交实验分解法结合起来使用

因果图：指的是被测的对象有多少个输入条件，根据不同的输入条件之间的关系（且 或 非）来匹配筛选出不同的结果

排列组合：因果图是根据输入的不同条件来根据排列组合来设计不同条件下的测试用例

正交实验分解法：因果图根据输入的N个不同条件组合下来导致测试用例的个数是呈指数级的增加，这样导致测试的资源（人力，时间资源）上根本无法满足测试的时间要求。那么这个时候只需要测试有代表性的数据就可以了，那么使用的方法就是正交实验分解法。

 

你怎么看因果图和正交实验分解法？

因果图根据输入的N个不同条件组合下来导致测试用例的个数是呈指数级的增加，这样导致测试的资源（人力，时间资源）上根本无法满足测试的时间要求。那么这个时候只需要测试有代表性的数据就可以了，那么使用的方法就是正交实验分解法。

测试用例三种：

1、思维导图

2、excel

3、checklist

checklist（针对测试的对象列出必须测试的场景，只不过它的描述相对而言是比较简单的）：

检查点，使用的场景具体如下：

1、开发转测了，但是时间非常紧张，要求今天上线，那么这个时候测试编写checklist把需要测试的点梳理出来进行测试

2、上线前使用checklist列出上线后必须需要测试的点（必须要进行的测试点往往指的是一个产品的核心流程）

发一个hotfix版本，来修复这个issue。

 

积分流程：

1、当支付成功后就可以发放积分

2、用户发表UGC审核通过后可以发放积分

3、当用户的积分积累到X分并且是在有效期，那么就可以抵扣礼品

 

积分成长流程：

1、 当支付成功后就可以成长值发放

2、 当用户成长值累计到x分可获得到特定的等级特权

3、 当用户获得等级后一年内达到保级条件等级特权可延续一年，

4、 否则先判定是否为金骆驼等级若是及保留本级特权等用户达到消费条件时重新享受该特权如果判定不是金骆驼等级则降级为草骆驼等级

5、 当判断出用户有作弊或其他行为对其成长值扣减无作弊或其他行为则不扣减

 

@产品经理，？@开发，@测试

XX产品的checklist已经写完，麻烦大家帮助我看看，测试场景都考虑到了没

积分流程：

1、当支付成功后就可以发放积分

2、用户发表UGC审核通过后可以发放积分

3、当用户的积分积累到X分并且是在有效期，那么就可以抵扣礼品

 

项目管理工具有三种：

       禅道、TAPD、Jira

项目管理模式；工作安排主要是通过项目管理工具来安排的。

明捷中Task：故事，一个故事有开始也有结束，那么在项目管理里面，会把每个任务按照一个task来看，那么这个task也可以叫story，具体指的就是任务有开始有结束

可以安排很多的task，每个task具体到story

错误推测法：

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

       是针对非功能性的测试，主要是根据现有的经验和直觉，来判断系统中可能存在的问题，然后进行测试来验证存在的问题是否存在。

 

非功能性测试场景：

1、在波浪式的交互过程中，一直往下滑动，可能会出现浏览器卡死

2、加载资源时在列表中翻页可能也会存在浏览器的卡死

3、Java语言编写的应用程序，大概率会存在内存泄漏（Java.lang.OutofMemory，简称：OOM）

以上这些都是需要测试来验证它。

内存泄漏：一个应用程序都会分配内存，比如分配了2G，但是程序在使用的过程中，由于程序受到了太大的压力，导致使用的内存超过了分配给自己的内存，那么就会导致内存溢出，在专业的角度我们叫内存泄漏

4、一码通，对该应用程序进行大量的扫描二位码并且一直在进行扫描，那么很有可能存在扫描二维码后出现不了结果或者时导致结果一直加载中。

 

场景测试方法：指的是针对一个系统从输入流开始一直到输出流的完整性的测试，主要考虑的是被测对象的业务流程，也就是各个不同场景方法的测试。

 

测试开发工程师

 

 

 

 

 

业务流程的测试很敏感设计到钱

沙盒环境|影子库  就是于线上环境一样但是与线上环境是隔离开的。

 

 

一般迭代多久一次：2周

人员结构有哪些：

PM（项目）：1

开发：4-5

前端：1-2

测试：3-4

产品经理：1

共13人

 

 

两周工作内容（一个迭代）：

  第一周：

    周一：熟悉需求文档以及参与需求的评审，和拆分任务

    周二：继续熟悉需求，编写测试用例

    周三：继续编写测试用例，评审测试用例，以及完善测试用例

    周四：编写自动化测试代码（学习/应用）

    周五：继续编写自动化测试代码，开发转测后，进行冒烟测试验证

 

 

  第二周：

    周一：测试被转测试的产品

    第二：继续测试，以及验证回归问题(Issue)

    周三：继续测试，以及进行验收测试

    周四：编写测试报告，做最后的探索性测试，准备上线前的资料，以及晚上上线后的回归测试验证

周五：参加项目迭代复盘会议，以及针对本次迭代进行总结，准备下一个迭代的工作内容

 

验收测试流程：

1、 测试在周三下午测试完成，发送邮件让产品经理进行验收测试，产品经理会在周三下午以及周四早上进行验收测试，验收测试完成后回复邮件，反馈本次验收测试的结果。

2、 测试报告的前提：在产品经理验收测试通过的情况下，测试才能够法测试报告，如果验收测试不通过，开发测试继续修改存在的问题。

 

周五的复盘会议：

1、 总结本次迭代有哪些优点，以及那些缺点。

2、 针对本次迭代的缺点，提出对应的解决方案，在下个迭代中执行。

 

判定表驱动分析⽅法

⽅法简介

1. 定义：判定表是分析和表达多逻辑条件下执⾏不同操作的情况的⼯具。

2.判定表的优点

1. 在⼀些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执⾏不同的操作。判定表很适合于处理这类问题。

能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利⽤判定表能够设计出完整的测试⽤例集合。

 

1)条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序⽆关紧要。

2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

3)条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。

4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

 

判定表驱动分析⽅法:列表被测试对象可能存在的各个不同条件，再依据因果图排列组合的方式（逻辑关系并且和或者关系），来设计出被测产品的测试点，如果排列组合下来的测试用例个数比较多，在资源紧张的情况下，那么就可以使用正则分解法来优化测试用例。

 

功能图分析⽅法

⼀个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输⼊数据的次序或转移的次序.静态说明描述了输⼊条件与输出条件之间的对应关系.对于较复杂的程序,由于存在⼤量的组合情况,因此,仅⽤静态说明组成的规格说明对于测试来说往往是不够的.必须⽤动态说明来补充功能说明.功能图⽅法是⽤功能图FD形式化地表示程序的功能说明,

并机械地⽣成功能图的测试⽤例. 功能图模型由状态迁移图和逻辑功能模型构成.状态迁移图⽤于表示输⼊数据序列以及相应的输出数据.在状态迁移图中,由输⼊数据和当前状态决定输出数据和后续状态.逻辑功能模型⽤于表示在状态中输⼊条件和输出条件之间的对应关系.逻辑功能模型只适合于描述静态说明,输出数据仅由输⼊数据决定.测试⽤例则是由测试中经过的⼀系列状态和在每个状态中必须依靠输⼊/输出数据满⾜的⼀对条件组成.功能图⽅法其实是是⼀种⿊盒

⽩盒混合⽤例设计⽅法。

（功能图⽅法中,要⽤到逻辑覆盖和路径测试的概念和⽅法,其属⽩盒测试⽅法中 的内容.逻辑覆盖是以程序内部的逻辑结构为基础的测试⽤例设计⽅法.该⽅法要求测试⼈员对程序的逻辑结构有清楚的了解.由于覆盖测试的⽬标不同,逻辑覆盖可分为:语句覆盖,判定覆盖,判定-条件覆盖,条件组合覆盖及路径覆盖.下⾯我们指的逻辑覆盖和路径是功能或系统⽔平上的,以区别与⽩盒测试中的程序内部的.）

功能图分析⽅法：它是非功能性的测试用例设计方法，是针对被测程序内部的一种测试方法，主要测试的对象是被测程序的内部代码，使用代码的逻辑来验证被测对象的程序逻辑是否存在问题，是白盒的一种方法。（说白了就是针对代码测试）

 

诚意的测试用例方法有哪些？举例说明？（面试的必考题）

等价类：

  针对被测对象的输入数据分为有效数据和无效数据，是功能测试的一种测试用例设计方法。如电话号码，那么有效数据就是符合运营商电话号码的规则，无效就是不符合，如连续的11个同样的数字以及非11的数字。

边界值：

  边界值是针对等价类测试用例方法的补充，如电话号码，需要考虑到11位，以及12位，和0位，也就是边界的情况

判定表驱动分析方法

  列出被测对象可能存在的不同条件，如招聘类网站筛选出的结果排序，可能会存在多个条件来筛选出结果，如年限，薪资，地区等等，需要先列出来

因果图

  在判定表的基础上，根据被测对象列出的条件，来使用排列组合的方式来验证各个不同条件下（并且以及或者关系）程序的结果情况

正交实验分解法

  在因果图的基础上，使用排列组合下来的测试用例个数是非常多，导致测试用例的个数是非常多的，那么使用正交实验分解法可以优化

  测试用例的个数，选择有代表性的数据来进行测试

场景设计方法

  主要考虑的是一个产品的完整的业务流程，从输入流开始一直到输出流，比如淘宝，从一个商品上架一直到商品的出售

错误推试法

  针对被测产品的非功能性的测试用例，主要使用探索性测试的方法，来验证被测产品可能存在问题

功能图分析⽅法

  针对程序非功能性的测试，主要考虑的是被测程序的内部结构代码的测试