之前公司一般常用等价类、边界值、流程分析法、场景法、错误推测法这五种方法。

一般情况下有输入框的时候会考虑用到等价类；当出现最大最小、最轻最重字眼的时候会用到边界值来考虑测试点；当出现业务流程的时候会考虑场景法和流程分析法。

还有三种不常用的方法：正交助手、判定表、因果图。当条件和条件组合比较多，组合也会影响到最终的结果，而且结果的取值只有真和假的时候考虑使用判定表；当条件和条件组合比较多，条件与条件之间存在制约关系，条件与结果之间存在因果关系的时候考虑使用因果图；当组合比较多，不能为每一个测试组合设计用例的时候考虑使用正交助手，使用的时候注意添加一些常用的测试组合。

八个要素：用例编号、测试标题、测试模块、测试环境、优先级、测试输入、执行步骤、预期结果（实际结果）

三个主要：测试输入、执行步骤、预期结果

好的测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。

一个好的测试用例，必须具备以下三个特征：

1、整体完备性：好的测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。

2、等价类划分的准确性：指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。

3、等价类集合的完备性：需要保证所有可能的边界值和边界条件都已经正确识别。

做到了以上三点，就可以肯定测试是充分且完备的，即做到了完整的测试需求覆盖。

站在用户的角度，把用户有可能输入到程序中的情况分类全部考虑进来。

我们公司用的V模型最多，个别的项目会用到W模型一部分。

像V模型的话，我们公司也不是完全按照V模型来进行测试，我们在里面渗入了迭代思想，开发一个模块，测试一个模块。然后等整个项目开发完也测试完了，最后进行验收。

像W模型的话，我们有一些项目也会用到W模型的一部分，我们对前面的概要设计测试和详细设计测试可能就省略了。

还有一个模型我们公司不用，是H模型，以我对H模型的了解它适用于比较重要的项目，因为是一个灵活性比较高、测试完全独立的模型，但是他的技术性和管理制度的要求都比较高，所以H模型不太适用于大多数项目。

我对开发模型有一定了解，现在开发模型主要有瀑布模型、快速原型模型、螺旋模型以及近几年比较火的一种叫敏捷开发模型。

像瀑布模型，它是其他模型的一个基础，存在开发阶段明确，但是流程不可逆。如果需求变更会导致代码重写，浪费时间精力和资金。所以我们公司用到的瀑布模型一般都是改良版瀑布模型，这个瀑布模型引入了迭代思想，开发开发一个模块，我们测试测试一个模块，这样在需求有变更的时候或者有 bug产生的时候，开发那边就便于修改或者调整需求。（需求分析–详细设计–编码–开发白盒–实现–软件测试–完成–维护）

像快速原型模型，一般适用于灵活性比较高的小软件，主要是先把原型做出来，实现和用户的交互。然后听取用户的建议，对用户提出的需求进行讨论，明确一下，然后将用户的需求实现。

像螺旋模型，一般用的比较少，主要是考虑在一些重要功能模块，要做到风控。

像敏捷开发模型，为了占据市场，开发人员先把主要功能做出来，经过测试，没有问题之后。然后开始上线，对产品开始快速迭代。

（什么时间什么人通过什么方式干什么事）

测试计划：项目简介、人员配置、测试阶段划分（任务分配）、测试策略（方法、手段、工具）、测试环境、测试资源、框架、风险控制、上线标准、时间

整体大纲：

1、项目概述：项目背景、测试目的、需求文档之类的

2、测试说明：测试模块、测试环境、测试策略、测试资源、分配任务之类的

3、风险控制：风险评估、应急措施之类的（开发更改需求等，保证上线产品没有问题）

4、质量评估标准：测试模块通过标准、验收测试通过标准

5、关键里程碑：什么时间发什么事物

6、附录和其他：测试用例的模板、缺陷报告模板之类的

“5W1H”规则指的是“Who(什么人)”、“When(什么时间)”、“Where(在哪里)”、“What(做什么)”、“Why(为什么做)”、“How(如何做)”。

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

bug的总数、bug的修复率、bug的分布情况、bug的严重等级的统计、未修复bug的原因、总结（本轮测试的情况，为以后测试做铺垫）

整体大纲：

1、测试结论（最重要）

2、遗留问题及风险：

a.重要级别bug修复率不高，未修复的bug需要继续处理

b.由于前期开发严重推迟，导致测试不够充分

c.轻微和微小级别的bug修复率极低

3、测试执行情况统计

4、缺陷统计和分析

5、未解决的bug列表

6、回归bug统计分析

完成编码之后提交给测试组进行测试时，测试人员先使用正向案例对软件的功能进行测试，如果正向案例可以被接受，就开始全面的测试；否则打回给开发人员，继续对代码进行修改完善。

一般会测试大概三轮左右。

第一轮测试：在冒烟测试通过后进行，覆盖High和Medium优先级的测试用例。目标：所有P1的bug全部修复，绝大多数P2的bug已修复。

第二轮测试：覆盖所有测试用例。目标：所有P1和P2的bug都已修复，绝大部分P3的bug已修复。

第三轮测试：回归测试，验证修复bug时未造成系统其他功能出错。目标：所有P1、P2和P3的bug都已修复，未修复的需要评审是否允许上线。

第一轮：测试所有的模块的所有测试用例；

第二轮：测试主管挑选风险比较大的用例来进行测试（用例级别、兼容性和功能、模块）；

第N轮：交叉测试。AB测试人员互换模块来进行测试，根据经验来发散测试；最后上线前，针对最基本的业务功能进行测试。

提交、打开、拒绝、修复、关闭、推迟

bug的生命周期：我们测试工程师如果找到bug，首先新建bug，提给开发，开发打开bug，然后开发确认bug；如果不是开发的bug就拒绝bug；如果bug延期修复，就先关闭bug收藏bug等后期版本在修复；如果开发确认修复bug，bug修复完成，我们进行复测，验证bug是否修复成功，修复成功就关闭bug，如果没有修复成功就打回开发重新修复，之后就重新复测直到bug修复完成后关闭bug。

首先我在测试工作过程中，没有出现过线上bug；但是我们公司每次上线之前都会有备选方案，把出现严重bug的版本拉下来，候选版本推上去，在bug修复完之后，再把修复完的版本推上去；如果是小型bug，不影响用户使用之类的，就可以直接在线上修改。

（首先强调工作过程中没有出现过线上bug，再说出现bug的备选方案）

可以选择一些钱方面的问题进行回答

1、电商项目：测优惠券模块，满199减50，但是付款的时候没减50或者减100，减少了公司的损失

2、页面跳转空白页，刷新一次又出来了，两三周出现一次

3、闪退（不好定位：app刚刚下载，打开就闪退）

偶性bug，不确定什么时间出现bug（测试什么时候突然出现闪退，后面就是偶尔在某个时间闪退，时间不定）

解决：在Linux下用tail -f查看日志，把日志截给开发，让开发去解决bug

偶性bug的应对措施：

1、抓取log、截图、视频

2、别急着去复现bug，先仔细回忆下自己的操作步骤及前置环境

3、找到能重现的步骤，然后再定位代码，还得考虑数据的因素（检查变量变化是否正确）

对于某些难以定位的一些问题，一般我利用Fiddler的抓包工具，去抓取前后台的数据交互的过程，通过分析请求的数据来判断是前端还是后台的问题。

1、首先看发的请求是否有问题，请求的接口url是否有错误，参数是否有错误，如果url或传参有问题那就是前端bug。

2、如果请求没有问题，看下后台返回的数据是否有问题，状态码5开头的基本都是后台问题，状态码为200，响应数据与预期不一致，那也是后台bug。

3、返回的数据没有问题，请求参数，url也没有问题，那可能是前端代码是否转换有问题，那就是前端bug。

单元测试：软件底层源代码中最小的结构，具体是类、函数、组件等（一般是开发测）

集成测试（接口测试）：将不同的单元组合在一起（将功能点集合起来），验证之间沟通的“接口”是否正常工作

系统测试：对软件当前的整体使用进行测试（从宏观上把控系统运行，不是从细节角度把控）

α测试：内测（在公司内部展开全面性测试)，可随时修改

β测试：公测（在实际环境中进行部分测试)，让特定的用户使用并提建议

γ测试：候选版本的测试

UAT测试：第三方派出专业的业务人员对软件进行使用测试从而验收

重点：逐步扩大市场

灰度测试（特别像β公测）：做出新功能之后，即将发布新版本之前，先小范围尝试（不是一下子让所有用户使用），然后再慢慢放量直到全新的功能覆盖到所有的系统用户（不一定只有公司内部人员，可能会有部分用户）。

灰度测试和β测试的区别：β测试是当一小部分用户使用没有问题之后，软件直接上线，适用于小软件；灰度测试是逐步让一部分用户使用，慢慢的放量直至上线，适用于大软件。

low：错别字

Medium：相对独立的功能bug，对其他模块没有影响

high：需求未实现

veryhigh：大多功能不可用

critical：系统瘫痪

low：时间与资源允许修正

Medium：低优先级，不会延迟发布

high：影响测试活动的进行

veryhigh：错误产生严重影响，优先修复

Urgent：系统瘫痪时，最高优先级

（什么样的问题才是一个缺陷，需要从客户需求出发）

1、软件未实现需求规格说明书中的要求

2、出现需求规格说明书中指明不应该出现的错误

3、软件未实现需求文档中虽未明确提及但应该实现的功能（如账密加密）

4、软件出现难以理解、不易使用或者运行速度慢等问题都可以认为是软件缺陷

（确定需求–环境版本–截图讨论）

首先要知道开发拒绝修改bug的原因；然后确定需求，对一下需求是否有变动；然后在确定环境版本是否有差异；然后再把截图（页面截图、后台log）和重现数据发给开发。当然也可能是无效bug。

1、确定需求，如果测试开发对需求理解一致

2、环境，查看两个人安装的是否一样

3、截图，把测出来的bug截图留证据，有图有真相（页面截图或者后台）

4、实在不行，我们公司每周都有一个会议，来讨论bug

开发人员说不是bug，有2种情况：

1、需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，三方商量确定好后再看要不要改。

2、这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是bug的依据是什么？如果被用户发现或出了问题，会有什么不良结果？开发可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来，跟开发经理和测试经理进行确认，如果要修改就改，如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进bug库中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

（告知领导问题的影响和风险–不能接受就修改–能接受就发布–发布之后需要跟踪）

首先你需要把这个问题说清楚，问题影响范围有多大，然后给PM（项目管理）或者项目经理还有拉上开发一起评审，说明这个问题遗留的风险，如果PM和项目经理接受这个风险，那就可以发布，否则必须修改了才能发布；即使他们接受了，发布之后，也要注意线上的表现，并知会出来；如果线上这个问题表现超过预期，那么就要要求发布补丁修复程序。

（计划–需求–设计–编码–测试–运维–上线）

1、软件计划与可行性分析

2、需求分析

3、软件设计

4、编码

5、软件测试

6、运行与维护

测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。检验是否满足客户需求；度量测试人员的工作量；展现测试用例的思路。

测试用例的定义：为了高效率的发现软件的缺陷而精心设计的少量测试数据。

（尽早介入–找bug，减少bug，保证软件质量，用户的角度的需求）

1、尽可能早的找出系统中的Bug。

2、避免软件开发过程中缺陷的出现。

3、衡量软件的品质，保证系统的质量。

4、关注用户的需求，并保证系统符合用户需求。

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

概括地说，软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”。

具体地说，软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。

影响软件质量的主要因素，这些因素是从管理角度对软件质量的度量。可划分为三组，分别反应用户在使用软件产品时的三种观点。正确性、健壮性、效率、完整性、可用性、风险（产品运行）；可理解性、可维修性、灵活性、可测试性（产品修改）；可移植性、可再用性、互运行性（产品转移）。

（网络，前端代码–定位bug，服务器，问开发）

首先查看主机网络是否有问题；其次查看网页开发者工具，查看前端html代码，定位一下bug；然后查看服务器是否正常运行；最后跟开发进行讨论。

我们可以从几个方面来考虑这个问题：

1、开发代码写错，图片没有显示出来这是最常出错的地方。

2、数据库问题，可能页面提示上传成功了，结果没插进去，可能是个空或者插错了没有上传成功。

3、网络问题，网络不好导致图片没有加载完，而超过它设置的一个设定加载时间。

4、图片格式不对，不是我们常见的图片格式所以代码不支持。

5、兼容性，可能在你访问的这个浏览器能显示，但是在用户的访问的浏览器无法显示，就要考虑你们用的是不是一个浏览器。

6、图片的丢失导致无法显示。

7、接口问题。

（保证新功能对老功能没有影响）

版本回归：在bug解决完了，测试没问题了，在上线之前对最合适的版本号进行最后一轮回归测试。

bug回归：复测（指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误）。

1、按测试策略分类：

静态与动态测试、黑盒与白盒测试、手工和自动测试、冒烟测试、回归测试

2、按测试阶段分类：

单元测试、集成测试、系统测试、验收测试

3、其他常见测试方法：

功能测试、性能测试、压力测试、负载测试、易用性测试、安装测试、界面测试、配置测试、文档测试、兼容性测试、安全性测试、恢复测试

4、系统测试分类：

功能测试、性能测试、兼容性测试、安全测试

1、功能测试层面上，Web和App测试在流程上没什么区别，但两者的载体不同，主要区别从系统方面，Web项目是b/s架构，基于浏览器，只需要更新服务端，客户端同步更新；App项目是c/s架构，服务器更新以后，客户端手动进行更新。

2、性能测试方面，Web测试需要响应时间、内存、cpu、吞吐量、并发数；App测试需要测试响应时间、内存、cpu、消耗电量、流量。

3、兼容性方面：Web主要考虑多种浏览器，浏览器的版本；App主要考虑手机品牌、型号、尺寸、分辨率、版本。

4、测试工具方面：自动化测试，Web一般用Selenium，手机用Appnium。性能测试，Web一般用Loadrunner，手机用jmeter。相对于 Web端测试App测试还需要关注：a.干扰测试（来电、短信、通话、关机、重启）；b.不同网络下的测试，网络切换的测试，无网的测试；c.安装、卸载、更新；d.权限测试。

（自动化解决了大部分人力，但是有些地方是自动化测试不到的地方，这就需要有专业技能的测试人员来协助自动化一起测试；但是测试人员也面临着挑战，需要学习新的技术，跟随潮流，比如现在的迭代开发，敏捷开发之类的）

软件测试是正在快速发展，充满挑战的领域。尽管现在许多自动化测试软件的出现使得传统手工测试的方式被代替，但自动化测试工具的开发、安全测试、测试建模、精准测试、性能测试、可靠性测试等专项测试中仍然需要大量具有专业技能与专业素养的测试人员，并且随着云计算、物联网、大数据的发展，传统的测试技术可能不再适用，测试人员也因此面临着挑战，需要深入了解新场景并针对不同场景尝试新的测试方法，同时敏捷测试、Devops的出现也显示了软件测试的潜力。

（早发现问题–发现别人无法发现的问题–补充技术能力）

测试人员的核心竞争力在于提早发现问题，并能够发现别人无法发现的问题。

1、早发现问题：问题发现的越早，解决的成本越低。如果一个需求在还未实现的时候就能发现需求的漏洞，那么这种问题的价值是最高的。

2、发现别人无法发现的问题：所有人都能发现的问题，你发现了，那就证明你是可以被替代的。别人发现不了，而你可以发现，那么你就是无法被替代。

钱，减少了公司损失，优惠券之类的

小数点保留：本来是保留两位，但是显示只有一位。

正常Web应用、服务端的很多操作最后都会进行数据库落库，所以需要通过查询数据库来确认落库数据是否正确（比如一个注册接口，如果注册成功，那么用户表就应该有记录这个用户的账号密码这方面的信息，没记录那就是严重bug了）。同时也会需要通过改一些数据库信息，进行一些场景的模拟。不过用的大部分还是基础的增删改查，存储过程啥的基本也不大会涉及。

除了查数据进行测试，搭建测试环境也会涉及一些数据库操作，每个版本提测的脚本，跑sql脚本也得测一下，有的测试数据也得进行备份，做自动化的一些预置条件也可以通过sql来插入数据等等。

手工测试缺点：

1、重复的手工回归测试，代价昂贵、容易出错。

2、依赖于软件测试人员的能力。

手工测试优点：

1、测试人员具有经验和对错误的猜测能力。

2、测试人员具有审美能力和心理体验。

3、测试人员具有是非判断和逻辑推理能力。

自动化测试的优点：

1、对程序的回归测试更方便。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。

2、可以运行更多更繁琐的测试。自动化的一个明显的好处是可以在较少的时间内运行更多的测试。

3、可以执行一些手工测试困难或不可能进行的测试。比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。

4、更好地利用资源。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。

5、测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。

6、测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。

7、增加软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。

自动化测试的缺点：

1、不能取代手工测试。

2、手工测试比自动测试发现的缺陷更多。

3、对测试质量的依赖性极大。

4、测试自动化不能提高有效性。

5、测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受到限制，从而制约软件的开发。

6、工具本身并无想像力。

  总结：

感谢每一个认真阅读我文章的人！！！

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

          视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。