【一】为什么要测试？
【1】软件的非正常运行（有些软件在电量低的情况下不能运行）或其自身的缺陷Bug会引发很多问题。
【2】软件是由开发人员编写代码和文档组成的，是人都有可能犯错，测试的工作是需要对开发出来的软件进行测试。
【3】环境也会影响软件，以致出现软件失效的现象。
【4】测试只是保证关键质量的活动之一，并不完全取决于测试，由开发，产品，运维一起决定的。
【二】什么是测试？
【1】制造行业（简称QC）的定义：以检验产品是否满足需求为目的
【2】软件行业的定义：找Bug, 找缺陷
（开发人员通过编程语言把功能实现出来，测试的工作就是不断发现软件中的缺陷，然后让开发人员进行修复）
【3】测试用例：在理解的条件基础上对软件进行测试的步骤。==》只要能发现错误就是一个成功的测试用例
【三】软件生命周期
【1】概念：软件生命周期又称软件生存周期或软件开发生命周期，指的是软件从生产到报废的过程，是一种时间的概念
eg.一部手机的寿命
【2】包括哪些阶段：
（1）客户问题引入或定义：比如电商平台我们团队会派产品经理和客户进行交接，我们能不能接这个项目，这个项目到底赚不赚钱。
（2）可行性分析：涉及经济，商业论证，政治，法律，技术等
（3）项目招投标：通过公开招募或竞争性选择来选择最优的供应商提供相关产品或服务。招一个项目组过来做一个产品需要多长时间。
（4）项目立项：用户的项目需要在半年之后需要交付哪些功能，一年之后完成哪些功能。
（5）需求分析：根据顾客需求输出需求文档。
（6）开发阶段（设计，编码，测试）
（7）维护：一般在项目立项的时候客户不会把钱全部打给团队，可能会打个30%的定金，等项目全部开发完毕后可能会另外支付60%，最后10%客户的要求是团队必须维护这个应用软件一年或者三年。
【3】模型：
（1）瀑布模型（waterfall)：用的非常少，每个程序必须按部就班进行，浪费时间且影响效率。
系统需求》软件需求》分析》程序设计》编码》测试》运行
（2）V模型：项目的阶段（是软件生命周期的5需求分析和6项目的开发阶段）
1.用户需求分析阶段：公司接到一个项目之后分配项目组，项目组的各个成员都对用户的需求进行分析，首先由产品经理根据用户需求提炼成为项目需求然后输出需求文档，与此同时项目组的其他成员比如测试人员和开发人员也根据用户的需求进行初步的分析。》大家各自分析完成后，产品经理召开需求评审会议，项目组成员根据各自的分析对需求文档中有问题的地方或者模棱两可的地方提出意见，然后产品经理根据大家提出的不同意见对需求文档进行修改》最后经过大家一致意见通过修改好的需求文档称之为需求规格说明书（SRS：需求的基线化文档→当前的状态非常的稳定且已经终结，不可以被随意的更改，随时可以进入到下一个状态）。
2.概要设计阶段：开发人员根据需求规格说明书（SRS），编写概要设计说明书（HLD）,设计出应用程序的大体框架结构。
3.详细设计阶段：开发人员根据概要设计说明书（HLD），编写详细设计设计说明书（LLD），设计出具体要开发的哪些功能。
4.编码实现阶段：又称coding编码阶段，开发人员根据详细设计设计说明书（LLD）编写代码，写完代码以后对代码进行打包，打包成一个项目代码包。
5.单元测试阶段（UT）：白盒测试
黑盒测试：又称功能测试，是一种从用户角度出发的测试。把被测程序当作一个黑盒子，测试人员完全不用考虑盒子里面的逻辑结构和具体运作，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。主要的测试方法有等价划分类，错误推测法等。
白盒测试：也称为结构测试。多用于单元测试阶段。它根据程序的控制结构设计测试用例，开发人员针对于自己编写好的代码包进行自测，用代码测试代码，是需要知道软件的内部逻辑，从而对逻辑进行测试，然后输出单元测试报告。
灰盒测试：又称接口测试，多用于集成测试阶段，是介于白盒测试与黑盒测试之间的一种测试，需要知道软件内部的部分逻辑，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑。
三者的区别：
从测试目标和依据来说：黑盒面对的是产品设计，白盒针对的是程序功能的实现，灰盒针对兼而有之，既要考虑产品设计要求，又考虑到功能实现的效果
从实现者而言：黑盒在意的是客户的角度，白盒测试针对的研发人员。
从测试模块颗粒度而言：白盒在意的是代码实现层面，而灰盒更加侧重模块之间，而黑盒更在于用户层面
6.集成测试阶段IT（灰盒测试也叫接口测试）：测试人员对开发代码包实现的功能和页面进行测试，输出系统集成测试报告。
模块A，模块B，模块C，模块D，模块E，==》灰盒测试：对不同的模块之间进行接口测试
7.系统测试阶段ST：除了保证应用程序本身运行和功能正常，还要与第三方应用程序进行衔接。
集成测试阶段IT和系统测试阶段ST合并成为SIT，即系统集成测试。
8.验收测试阶段UAT：由产品经理或者产品项目组对软件的代码包进行验收测试，输出验收测试报告。
α（阿尔法）验收测试：由项目组中的产品成员或者业务人员进行验收，测试人员模拟用户的行为去进行测试，如果在验收过程中发现了问题可以直接让开发人员现场对bug进行解决修复。
β（贝塔）验收测试：产品已经交付到了客户手中，客户自己去操作产品验收，如果发现了问题则由客户把出现的问题进行统一收集，然后以邮件的形式发送给项目组成员，然后再由开发人员去跟进并进行解决。
V模型如下
用户需求 ==》 验收测试（是根据用户的需求来进行验收）
需求分析 ==》 系统测试（是根据需求进行系统测试）
概要设计 ==》 集成测试（是根据概要设计进行集成测试）
详细设计 ==》单元测试（是根据详细设计进行单元测试）
编码和实现
面试题：您之前公司的项目阶段有哪些？并且每个阶段的输入（准入）和输出（准出）是什么？
准入 准出
客户需求分析阶段 ===》对需求进行分析，生成需求文档 ===》需求规格说明书（SRS）
概要设计阶段 ===》需求规格说明书（SRS） ===》概要设计说明书（HLD）
详细设计阶段 ===》概要设计说明书（HLD） ===》详细设计说明书（LLD）
编码实现阶段 ===》根据详细设计说明书（LLD）编写代码 ===》整个项目代码包（.war .jar格式包）
单元测试阶段 ===》开发人员根据代码包进行自测 ===》单元测试报告
系统集成测试阶段 ===》测试人员编写和执行测试用例，对代码包进行测试 ===》系统集成测试报告
验收测试阶段 ===》产品项目组或客户对代码包进行验收 ===》验收测试报告
（3）W模型：是V模型的补充，它贯穿整个软件产品周期。但是还是认为是串行的开发模式。
优点：1.将测试贯穿到整个软件的生命周期中，且除了代码要测试。需求，设计等文档都要测试。2.更早的介入到软件开发中，能尽早的发现缺陷并进行修复。3.测试与开发独立起来，并于开发并行。
缺点：1.对有些项目，开发过程中根本没有文档产生，故W模型无法使用。2.对于需求和设计的测试技术要求很高，实践起来很困难。
（4）H模型（整套课程都是围绕H模型）：项目的流程（在公司里面测试和开发岗位是怎么样去协调工作的，从这个项目的立项到拿到需求以及中间经历了什么样的内容，到产品输出上线）
1.分为两条线，一条开发线，一条测试线。开发人员和需求人员拿到需求规格说明书（SRS）之后进行澄清，为什么要澄清？因为产品经理根据用户的需求提炼为项目需求的过程中可能会有模棱两可的地方，总共24W，有6W的时间对需求文档进行澄清看需求，产品经理在第3W的时候会主持召开需求澄清会议进行需求评审，此时开发和测试人员对需求文档了解的差不多了，开发和测试人员对需要改进的地方提出意见，通过不断地意见交换和修改，最终会形成需求规格说明书（需求规格说明书本质上还是需求文档，只不过得到了大家的一致认可后才叫需求规格说明书）
假设6个月（=180天=24周W）1个版本》先有项目还是先有版本/产品？》先有项目，立项之后通过项目的开发，项目的实施才有产品的上线
& 项目和版本/产品的关系？》微信成立8年 , V1.0, V2.0，》版本会不断迭代开发。
2.需求规格说明书之后，开发人员说我可以开发，测试人员说我可以测试。2W的时间开发人员编写概要设计说明书（HLD）以及详细设计说明书（LLD）。与此同时测试人员继续深入了解SRS,然后评审HLD，LLD，测试经理输出测试计划和测试方案，测试工程师输出testcase（测试用例或者测试案例TC）并进行多次用例评审，最终形成用例基线文档。==》开发人员在写代码的同时测试人员在写测试用例。
3.多次用例评审有三种方式：
交叉评审：在测试组内测试人员相互进行先评审（人员一般就是测试组里面的）
组内评审（又称正式评审)：在项目组内进行评审（项目经理，测试经理，开发经理，开发人员等等与项目组相关的人员）
会议评审：有客户方参与。
需求评审或者说需求澄清会议是由产品经理召开和产品经理主讲
案例评审会议是由测试经理召开，是由测试人员主讲（谁写的用例谁讲）
基线文档：当前的状态非常的稳定且已经终结，不可以被随意的更改，随时可以进入到下一个状态。
测试经理将用例基线文档输出到testlink用例管理工具（又称测试管理工具》禅道：项目管理工具和用例和BUG管理工具），并将TC（test case）测试用例初稿分配给TE（谁写谁测的原则）
开发人员将写好的代码打包然后给到测试经理进行部署项目》测试经理或测试骨干或测试环境运维人员搭建测试环境》基于Linux系统部署项目包
4.常用的环境有哪些：
测试环境（测试服务器）：测试人员在这个环境上进行系统集成测试。
开发环境（开发服务器）：开发人员在这个环境上进行代码的开发，调试。
预发布环境：产品在预发布环境上进行验收测试，如果验收没问题，则将代码包发给运维人员，运维人员将代码包部署到线上环境。
生产环境（正式服务器）：又叫做真实线上环境，例如腾讯课堂可以购买网络课程，给到所有用户使用的环境。
5.部署完项目之后的操作：
测试人员进行冒烟测试》来源于硬件行业》电路板：最主要的功能已经失效》冒烟测试：测试主体功能》测试QQ的登录主体功能，QQ登录成功》支付功能的主体功能》找回密码功能的主体功能》找回密码成功
冒烟测试不通过重新把版本打回》开发人员重新去修改代码
冒烟测试用例是从sit1测试
冒烟测试通过则执行sit1测试
sit1叫做第一轮系统集成测试，又叫做全量测试，例如当前版本写了1000条用例，要把所有写的用例执行一遍（1000条用例能发现大约300-400个bug）。冒烟测试用例是从所有写的1000条测试用例中选取20-30条进行测试
sit2叫做第二轮系统集成测试，又叫做回归测试(从第二轮测试开始到最后一轮都可以称之为回归测试)，又叫做增量测试（在原有的用例上面增加新的用例增加了50条）》回归测试测什么？会选取450条》测试上一轮出现BUG的用例。测试主体功能（冒烟测试）。测试与上一轮出现BUG相关模块的用例。测试新增加的用例。
sit3简称叫做回归测试，选取200条用例
sit4简称叫做回归测试，选取60条用例
发现的bug呈快速收敛状态是哪个阶段？》从系统集成测试到进入回归测试
sit4为什么会存在0个bug或者1个bug?》这个1个bug可能是建议性（应用型）的bug，不对功能使用造成影响，功能性bug必须全部测试完成，直到全部修复》建议性的bug可以和测试经理申请可以放到下个版本进行修复
测试完成之后达到上线的硬性条件是什么？最终实现的 0 bug
6个月一个版本，假设有20个子需求点》开始，语音通话，聊天 现在：红包，小程序，公众号，视频号》先挑最主要的功能进行实现
H模型可以理解为也是一个迭代开发模型，在H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发的进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段，软件测试可以尽早的进行，软件测试可以根据被测物的不同而分层次进行。
（5）敏捷开发模型：这是一种新的模型，前面的几种都是属于传统型，它能适应快速需求变化，交付周期短，轻量级的开发模式。
（6）迭代开发模型：项目被分为大量迭代过程，一次迭代就是一个完整的开发循环，是一个可以发布的可执行的产品，属于软件开发周期中最终产品的一个子集。
（7）增量开发模型：项目被划分为一系列的增量，每一个增量都交付整个项目需求中的一部分功能。需求按优先级进行划分增量的支付。
【四】测试的基本原则
【1】测试的标准是用户需求
【2】测试不仅仅是单纯的软件本身的测试
【3】软件外在没有失效不代表软件系统是可用的
【4】软件的完美度没有完全正确的，测试只能帮助软件更加完美，更加正确
【5】穷尽测试是不可能的（有些条件组合非常多，穷尽测试是不可能的）
==》穷尽测试是指包含了软件输入值和前提条件所有可能组合的测试方法，完成穷尽测试的系统里应该不残留任何未知的软件缺陷，你可以通过做更多的测试来找到他们，也就是说你的测试还没有穷尽。
【6】测试应该尽早介入（早期引入的问题占到整个问题数目的50%以上）
【7】二八原则：80%的缺陷或错误会集中出现在单元测试阶段20%的区域中
【8】杀虫剂效应：也就是说要不断更新用例，因为反复的执行相同的测试用例将会发现新缺陷的能力几乎为零。
【9】测试活动依赖测试对象，测试的关注点不一样，有的更多关注安全和性能的测试
【10】尽量选择第三方测试，避免自己测试自己开发的程序。
【五】测试活动的生命周期（指的是测试流程）
测试计划（测试准入）与控制》测试分析与设计》测试实现与执行》测试报告（测试准出）》测试过程资产归档（测试总结）