发现缺陷错误，并且尽最大可能找出最多的错误，也是对软件质量进行评估，以提高软件质量。

软件是计算机系统中与硬件相互依存的一部分，它是包括程序、文档的完整集合。

程序（program）是按事先设计的功能和性能要求执行的指令序列。

文档（document）是与开发、维护和使用有关的图文材料。

1、软件没有实现产品说明书要求的功能；

2、出现了产品说明书指明的不应该出现的错误；

3、实现了说明书中未提及的功能；

4、未实现产品说明书虽未明确，但应实现的功能；

5、软件难以理解，不易操作，运行缓慢等问题；

6、缺陷是系统在开发或者维护过程中就存在的错误；

7、缺陷是系统某种功能失效；

2、找到【预期结果】和【实际结果】的差异，保证项目质量；

3、根据需求文档（客户要求）进行测试；

P.s：一般把软件缺陷（defect）称为bug（臭虫）

六、BS架构和CS架构：

1、BS架构——基于浏览器；

优点：分布性强，维护方便，成本低；

缺点：个性化特点明显降低，跨浏览器实现差，响应速度低，容易给服务器造成较大的压力；

2、CS架构——基于客户端；

优点：用户体验佳，速度快，处理能力强；

缺点：需要专门的客户端安装程序，开发、维护成本高，升级一次所有的客户端程序都需要改变。

4、耐心、细心、自信心

6、不管做什么测试，基础一定要牢，才能继续提升

【用户需求】由需求人员（BA）根据客户需求整理一个文档叫需求文档

【需求分析】项目经理—测试经理—开发—测试—BA

1、需求怎么做？——开发

2、需求是否合理？——两个方面：需求、时间

（1）搞清楚这个需求的来源是做什么的；

（2）通过测试思维去考虑它，如何去测试它；

4、需求讨论阶段也是需求确认的一个阶段

【概要设计】开发人员对需求进行梳理；

——开会评审，检查开发人员对需求的理解程度；

【详细设计】开发人员需要通过什么样的技术去实现这个功能，用文档的形式写出来

【单元测试】开发人员对自己编写的程序进行自检

——通过代码的形式进行测试

【集成测试】也叫组装测试，先测试单个模块，再进行组合测试，查看是否能正常运行

——主要是做功能和接口测试

【系统测试】也叫全面测试

——除了功能和接口测试，根据项目要求，进行性能、自动化、兼容性等测试

正式验收：其他的第三方测试团队再测试一次

1、Alpha测试：是由用户、测试人员、开发人员等共同参与的内部测试

2、Beta测试：β测试指的是内测后的公测，即完全交给最终用户的测试

冒烟测试：测试项目的主流程是否通过

1、系统功能比较稳定的情况下才会做交叉测试

2、项目时间比较充裕的情况下做交叉测试

1、长时间测试一个系统会产生视觉和习惯上的疲劳

2、换个人测试，由每个人的测试习惯能够发现新的问题

3、从而保证项目的质量

V模型也叫一个项目的生命周期；

V模型的缺点：没有明确说明早期测试，在测试原则中：测试人员应该尽早的投入测试，与开发同步进行；

提出了优化后的模型：W模型

V模型的优点：明确标注了测试阶段与开发各阶段的对应关系；

1、只关注输入条件和预期结果

2、不关注程序内部结构，主要做功能测试

1、需要关注程序的内部结构，主要是做自动化测试

2、单元测试也属于白盒测试的一种

十一、白盒测试的常用方法

语句覆盖，判断覆盖，条件覆盖，判断/条件覆盖，基本路径覆盖，循环覆盖，模块接口覆盖

十二、黑盒测试的常用方法

等价类划分、边界值分析法、因果图法、状态转换法等

1、界面测试：也叫UI测试，对系统页面进行检查

2、功能测试：测试系统中所有的功能（在公司中，界面属于功能测试的一种）

3、回归测试：重复测试，也叫返测。

（1）开发修复bug后，测试人员重新测试，叫回归测试

（2）上期版本的项目已经做好了，这期无大变化，那么我们可以使用上一个版本的测试用例进行回归测试。

P.s.要注意回归测试的时候有无新问题出现

（1）主要测试服务通不通；

（2）含义：查看模块与模块之间、系统与系统之间能不能关联；

（1）模拟我们真实的用户并发——测试系统最大的承受能力；

——简单来说，就是看我们的系统是怎么死的

（1）把以人为驱动的测试行为转化为机器执行的一种过程；

（2）优点：可以模拟人工测试，减少重复机械的测试工作量，大量用于回归测试；

（1）权限测试：主要是各种角色登录系统，查看各角色的权限是否得到控制；

后三个在公司里一般是由专门负责安全测试人员去进行测试，会用到静态代码扫描工具（APPSCAN）进行测试。

BS架构——web项目——浏览器的兼容性；

CS架构——app项目——操作系统和硬件设备版本不同；

（1）文字表达要清晰清楚；

11、随机测试：“猴子”测试，随意向系统输入操作，模拟真实用户操作。

十四、SIT和UAT阶段测试

1、SIT——集成测试——功能、接口  2-3轮

2、UAT——系统测试——全面测试（功能、性能、接口、测试、自动化、兼容性等）

P.s. SIT阶段的功能至少要完成80%，并且提出的bug已经修复才能进入UAT阶段。

3、UT——冒烟测试——系统可以允许没有完成，达到70%的功能已经实现，至少主流程已经实现

1、先从测试种类方面去考虑。（界面、功能、接口、性能、兼容性、易用性、安全等）

2、根据这个产品的特色考虑到他的一些异常情况

1、项目中要尽早投入测试人员；

2、在发现错误多的地方投入更多的精力和时间（二八原则）；

3、发现问题一定要指出；

4、并非所有的bug都能修复；

（1）轻微的问题，不影响项目功能使用可以放在下个版本去修复，但要请示领导，并且得到同意

（2）项目A数据有误，但已上线，我们是B项目，用到了A项目的数据，导致B项目数据有误，那么这种只能等到A项目把数据修正了，我们这边才能展示

5、追溯用户需求规格；

6、测试人员应该比开发人员更熟悉也无需求；

1、QA：监督、跟踪我们项目过程中的每一步，审核我们所有的文档

项目经理（必备）、测试经理、架构师、开发（必备）、测试（必备）、助理、运维、QA、BA（必备）

3、公司开发人员与测试人员的比例：3-4个开发——1个测试

1、需求文档——由BA根据客户需求写出的文档

2、需求分析——开发、测试、BA、项目经理或测试经理

3、测试计划——由测试经理或者测试组长编写的

4、测试方案——由测试经理输出

5、编写测试用例——测试人员

6、评审测试用例——修改测试用例（QC报告——相当于会议纪要）——再次评审

7、合格开始执行测试用例——相当于找bug的过程

8、发现bug——记录缺陷——提交至缺陷管理库

9、开发修复缺陷——回归测试——关闭缺陷

10、输出测试报告——测试经理或测试组长输出

测试计划、测试用例、测试报告、测试日报、测试周报、会议纪要、性能测试报告、用户使用手册

1、对软件中的需求说明书、设计说明书、程序源代码等进行非运行的检查

2、静态测试包括：代码测试、界面测试、文档测试等

简单的理解：检查系统运行，输入数据和预测结果是否符合

1、需求编号——从需求文档上复制下来

2、需求名称——从需求文档中复制（例如淘宝中的男装、女装）

3、模块名称——复制（例如：女装中的连衣裙，短裙，上衣）

4、用例编号——根据需求编号往后+001开始递增（例如：需求编号FN08——用例编号FN08_001）

5、用例名称——唯一性，代表整条测试用例的核心

6、优先级——高、中、低

7、前置条件——特殊情况下使用

8、测试步骤——如何到达系统的页面，详细的记录下来

9、输入数据——使用到测试用例的方法和思维，决定整条测试用例质量

10、预测结果——跟需求文档保持一致

二十四、什么是测试用例

1、测试用例主要记录了测试的过程、步骤、输入的数据、预期结果等内容

2、它是在执行测试之前由测试人员编写的指导测试的重要文档

——测试用例=用例名称+操作步骤+输入数据+预期结果

二十五、测试用例的用途

1、防止遗漏功能点未测试

二十六、编写测试用例参考文档

3、与BA（需求人员）、开发人员、测试人员等相关人员进行讨论

二十八、测试用例编写思路

二十九、测试用例方法——等价类、边界值

有效等价类：在取值范围内属于有效

无效等价类：在取值范围以外属于无效

优点：可以清晰的梳理被测对象

等价类随意挑选2-3组数据进行测试

内点、离点：±1的区别（边界值核心）

主要用于数值范围的使用

等价类、边界值需配合使用

三十、测试用例方法——因果图

1、通过画图的方式表达输入条件和输出条件之间的约束关系

2、“因”（原因）——输入条件 “果”（结果）——输出结果

3、一般——输入与输入的关系、输入与输出的关系

4、因果图的思想：因为什么原因产生了什么样的结果

5、因果图的基本符号（输入与输出的关系）：

恒等：（1）当输入条件发生时，结果一定会出现；

（2）当输入条件不发生时，结果一定不出现；

非：取反；（1）当输入条件发生时，结果一定不会出现；

（2）当输入条件不发生时，结果一定会出现；

或：（1）当多个输入条件，只要有一个条件满足，结果就出现；

（2）如果输入条件都不满足，则结果不满足；

与：（1）若几个输入条件都满足，结果才出现

6、因果图的约束条件（输入与输入的关系）：

E互斥（异）：如果选，只能选一个，可以不选

I包含（或）：至少选一个，可以多选但不能不选

O唯一：必须选，且只能选一个

R要求：如果a=1，则要求b必须是1

优点：可以快速的梳理业务逻辑关系。条件、组合、限制关系

缺点：每个人的想法有差异，导致用例的条数不一致

三十一、测试用例方法——判定表

1条件桩、条件项、动作桩、动作项

3用例条数：结果状态的（条件数）次方

3、9种测试用例方法，没有哪一种是完胜的，需要配合使用

（1）理解需求，确定条件桩和动作桩

条件桩=输入条件 ，动作桩=输出结果的状态

（2）设计和优化我们的判定表

（3）填写动作项，也就是它的业务逻辑

（4）根据判定表中输出结果的表现，进行判定表的合并（不一定非得做此操作）

——简化判定表（如果输出相同，在其对应的输入中，有且只有一个条件的取值，对动作不产生任何影响的，则可以合并）

判定表给出的只是规则，不像边界值、等价类可以直接给出测试用例

（1）能够将复杂的问题按照各种可能的情况全部列举出来；

（2）简单并避免遗漏；

（3）能够通过公式计算出测试用例总条数；

（1）输入条件之间的限制条件关系不好表达 解决方案：填写备注来描述限制关系；

（2）当输入次数过多，规则以2的N次方剧增时，判定表就会很庞大，这时候判定表会造成逻辑缺失，业务混乱，需要细致分析，尽可能划分多个需求项，再使用判定表；

（3）有重复的测试场景 解决方案：简化判定表

三十二、测试用例方法——场景法

1、基本流：按照正确的业务流程来实现的一条操作路径（模拟正确的操作流程）

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

三十三、测试用例方法——大纲法

1、在一个程序或程序的某个模块中，涉及到多个窗口，每个窗口中能够完成多个动作，这些窗口又互相联系。为了弄清楚窗口和窗口之间的关系，或者说动作与动作之间的关系，可以使用到测试大纲法。

2、大纲法适用于软件的安装程序测试，检查界面测试要点以及窗口之间的变化。

三十四、测试用例方法——正交排列法（正交实验法/优选法）

1、因子：所有参与实验的影响实验结果的条件——条件桩（例如：QQ登录，用户名字段）

2、水平：影响实验因子的取值或输入——条件项（输入框内输入的值）

n是测试组合的次数（测试用例条数）；

k是表的列数（因子个数）；

（1）水平相同正交表——公式：n=k*(m-1)+1（常用）

5、正交表的优点：经过严格的数学推理而来，可以提高效率，正交排列法计算的测试用例是最优的，因此也叫优选法。

6、正交表的缺点：会漏掉一些测试场景 解决方案：根据错误推断法增加测试用例。

（2）找出因子和水平个数

（3）通过公式计算出测试用例条数

（4）找到对应的试验号

（5）把控件及其取值映射到正交排列表中

（7）如果缺少测试场景，需要补充

在工作中经常使用到的方法有：

等价类+边界值+因果图+场景法+错误推断法

【你是不是项目中的骨干？】

1.测试的模块是项目的核心内容

2.我们项目组的测试计划报告都是我来出的，包括周报、日报的汇总

3.我会用Jmeter做性能测试，我们项目组的性能测试基本上都是我主导的

4.我自学了Python，然后会给项目组的其他成员进行技术分享

5.对接开发和其他系统的沟通基本也是我做的

【Web项目实战——美萍酒店管理系统】

三十五、测试流程与阶段

4.编写测试用例、评审

5.执行测试用例、提bug单

6.回归测试输出测试报告

1先看需求文档，了解整个项目的架构，找到自己所负责的模块

2将自己负责的模块，整体的流程弄清楚，然后再去了解细节内容

3再找到跟自己负责的模块有关联的模块，搞清楚他们之间的关系

4找到自己测试模块对应的开发，然后进行需求确认，需求串讲

1.需求文档的目的是将需求的功能点梳理并且细化

2.是BA进行编写，但是要通俗易懂

3.为开发和测试人员提供依据

————在公司当中，不是所有的公司都有现成的项目给你进行参考的

确认、整理自己的模块功能，确保需求一致

2.分别将以上需求点与需求人员和开发人员进行确认，保证需求的一致性和清晰性

测试计划是描述了要进行的测试活动的范围、方法、资源和进度的文档

是对整个信息系统应用软件组装测试和确认测试

它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险

2.测试参考文档和测试提交文档

5.问题严重性及优先级描述

5.1 缺陷严重级别定义

5.2 缺陷优先级定义

5.3 缺陷跟踪及测试版本

本次测试计划保证了项目地正常进行，但具体还需根据项目的进度操作。

测试计划可以有效预防计划的风险，保障计划的顺利实施

目的：在方向上明确要怎么测，以及达到什么样的质量标准

（测试工程师需要基于产品功能和测试方案来设计和执行测试用例，同时也要参考产品设计说明文档）

软件测试方案有助于软件项目成员理解和执行测试过程中的各项活动，同时测试方案也有助于测试活动的管理

测试计划和测试方案的区别：

组织架构、工作任务分配、工作量评估、人力物力资源分配、进度的安排、风险把控和规避、以及各任务通过的准则等。

测试需求的细化、测试组流程设计、自动化测试框架设计、测试数据和测试脚本设计、测试用例设计的方法等。

总而言之，测试方案需要在测试计划的指导下进行，测试计划提出“做什么”，而测试方案明确“怎么做”

此方案明确了测试方向，细化了需求与业务流程，并在技术方面写出了具体测试方法和应有的验收质量标准，也为后续编写测试用例提供参考。

3.标题要设置背景颜色并且加粗

4.折叠栏以模块的形式划分

5.不能有错别字，错的标点符号

6.字体统一，最好为11

7.从需求编号——预期结果为电脑屏幕正常显示，不需要拖动查看

【你一天能写多少测试用例？】

大颗粒度——40-50条

项目名+版本号+测试用例

机密等级：绝密（只能高层领导查看）、机密（本项目组的人查看）、秘密、公开

测试用例评审之后，我们将有问题的地方进行修改

【测试用例需要随时更新？】

需求变更、代码改动，测试用例随时改变

四十一、缺陷报告的处理流程

【模块名称】进入xxx页面，类型与身份证号码不匹配也能查询成功

提bug单的原则：有图有真相（截图）

严重程度：致命、严重、一般、轻微

【如果出现问题一定会提单吗？】

1.先看一下是属于什么样的问题。界面的问题，我们可以先记录下来，进行跟踪。

2.其他的问题，一定要提单

赋予权限——赋予测试人员的权限

——可以提bug单，也可以查询我们项目组甚至我们公司内部所有项目的bug单

——不能删除自己的bug单，也不能删除别人的bug单

——不能提重复和无效的bug单（再三检查和确认）

——可以到处查看测试用例

【到公司的第一步】打开电脑

【第二步】打开邮箱和沟通工具

测试这边测试的第一个模块出现的问题跟第二个模块出现的问题一致，是要归类为一个问题还是分开写两个问题？

1.两个模块出现同样的问题，两个模块是由同一个开发人员做的，只需要提一个bug单

2.两个模块出现同样的问题，两个模块是由不同的开发人员做的，可以提2个bug单，方便跟踪

3.比如说，第一个模块和第二个模块出现同一个问题，你可以提一个单，然后马上在工作群把这个问题暴露出来

注意：如果一个问题在多个模块出现，那么就要注意这个问题，并且在工作群知会其他人

在工作中你发现了一个bug，但是开发不承认，你如何跟他沟通，处理这个事情？

1、截图，找出问题，重现给开发人员看

2、如果这个时候开发还是不承认，就找自己的直接领导测试经理去说明这个问题的重要性，让他进行沟通

3、测试经理这时候一般会找项目经理沟通

测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件存在的质量问题提供依据，同时为软件验收和交付打下基础。

常见缺陷：功能实现错误，功能未实现或只实现了部分，APP崩溃（最常见问题，影响比较严重）

四十三、安装，卸载测试要点

四十四、软件更新测试要点

四十八、交叉事件（交叉测试、冲突测试）

测试要点（APP的优先级不能高于手机的主要功能电话，短信，闹钟等）

四十九、用户体验测试要点

软件测试的工作职责是：1、制定、编写软件测试方案与计划；2、按时完成软件测试工作任务，执行测试，跟踪缺陷状态，提交测试执行报告；3、编写测试文档、测试报告，提交测试结果；4、测试环境的设计、设置，完善测试规范流程、创建和维护测试用例；5、改进软件测试流程、工具和质量；6、参与测试结果评审。软件测试描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程，其经典定义为：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

为了发现尽可能多的缺陷。这里的缺陷是一种泛称，它可以指功能的错误，也可以指性能低 下，易用性差等等。因此，测试是一种“破坏性”行为。

测试的目的是发现程序中的错误,是为了证明程序有错,而不是证明程序无错。即软件测试是为了“证伪” 而非“证真”。把证明程序无错当作测试目的不仅是不正确的, 完全做不到的，而且对做好测试没有任何益处，甚至是十分有害的。软件测试要设法使软件发生故障，暴露软件错误, 能够发现错误的测试是成功的测试，否则是失败的测试。

根据软件开发各阶段的文档资料和程序的内部结构，精心设计一组“高产”的测试用例（一组输入数据和与之对应的预期的输出结果，在设计测试用例时，应包括合理的输入数据和不合理的输入数据），利用这些用例执行程序，找出软件潜在的缺陷一个好的测试用例很可能找到至今为止尚未发现的缺陷的用例；一个成功的测试则是指揭示了至今为止尚未发现的缺陷的测试。

主观上由于开发人员思维的局限性，客观上由于目前开发的软件系统都由相当的复杂性，决定了在开发过程中出现软件错误是不可避免的。若能及早排除 开发中的错误，就可以排除给后期工作带来的麻烦，也就避免了付出高昂的代价，从而大大地提高了系统开发过程的效率，因此，软件测试在整个软件开发生命周期 各个环节中都是不可缺少的。

软件测试总的目标是：确保软件的质量，所以测试并不仅是个技术问题，更是个职业道德问题。