二、软件测试的目的：

1、以最少的人力、物力、时间找到潜在的各种错误、缺陷

2、利用测试结果、测试信息，避免将来出现错误

3、利用更高效的测试管理手段，提高软件测试的效率和产品质量。

对软件测试的理解：

1、为了尽可能多的发现缺陷，避免线上出现重大问题

2、更深层次的定位bug，协助开发找到解决方案

三、测试和调试的区别：

1、主体不同，一个测试一个开发；目标不同，一个找bug一个改bug；  方法不同，一个正向思维一个反向思维；

2、测试：从已知条件开始，使用预先定义的过程，并没有预知的结果；调试：未知条件开始，结果未知

3、测试：可计划，预先定义用例，调试：计划较困难

4、对象不同：测试文档、数据、代码，调试代码

四、软件生命周期：

软件立项-需求分析-设计（概要设计、详细设计）、编码、测试（单元、集成、系统、验收）-发布维护-淘汰

软件定义：程序+数据+文档

五、软件开发过程模型

1、瀑布模型：

特点：分阶段，当前一个阶段完成，才能进入下一个阶段

优缺点：1、阶段划分过于严格2、线性，前期定需求，到后期才能见到结果，风险较大3、不适应需求的变化

2、快速原型：

特点：迅速建立起一个可维护的原型，便于达成共识确定需求

优缺点：1、克服了瀑布模型---前期需求后期结果----的缺点，减少了风险2、缺点：技术和工具不一定符合主流；快速建立不断更改导致质量低下

快速原型和敏捷开发模型的异同点：

3、增量模型

特点：模块作为一个增量组件，从而分批次的进行设计

优缺点：分批次提交，组件为单位，风险低；开发顺序灵活；但项目管理人员把握全局的水平较高。

4、迭代模型

特点：强调开发的深入、优化；每一次开发迭代都要经历完整的工作流程

优缺点：降低了一个增量的开支风险；降低了产品无法按照既定的进度进入市场的风险，加快了进度，适应需求变化容易

5、螺旋模型

特点：兼顾快速原型的迭代，以及瀑布模型的系统化

优缺点：引入风险分析，重大风险时有机会停止；适合大型昂贵的软件

六、软件测试过程模型（用于定义测试的流程和方法）

1、V模型

特点：1、忽视对需求、设计阶段的测试2、后期需求才能得到验证，风险较大3、没有体现尽早测试、不断测试的理念

2、W模型

特点：1、测试、开发并行2、测试对象：程序+需求+设计3、尽早测试，降低成本4、串行、无法支持迭代（无循环）

3、H模型

特点：1、准备好了就可以测2、尽早准备测试、执行测试3、按照某种次序，也可以反复执行

4、X模型（探索性测试、随机测试）

特点：1、帮助有经验的测试人员，在测试之外发现更多的错误2、针对单独的程序片段进行相互分离的编码和测试

七、软件测试过程理念

理念：尽早测试、全面测试

核心竞争力：尽早发现问题、发现别人无法发现的问题

八、软件测试的分类（重点）

1、按开发阶段划分：

单元测试：检查每一个程序模块能否实现详细设计说明书中的功能、性能、接口设计约束要求；需要从内部结构出发设计测试用例；多个模块可平行独立的进行单元测试

集成测试：单元测试基础之上，将所有的程序模块进行有序的递增测试，检查单元或部件的接口关系，逐步集成为符合要求的程序部件或整个系统。

集成模式：1、增量集成（测一个模块就连一个模块）2、非增量集成（每个模块测完了再连接）3、三明治集成（大爆炸集成，定位缺陷较困难）

集成划分：1、自底向上：从原子模块开始组装，测试到较高层模块时，所需下层模块功能均已具备，缺点是最后一个模块加入时才具备整体形象，需要开发驱动模块2、自顶向下：从主控模块开始测试，需要开发桩模块，能及时发现设计上的错误

确认测试：（较短）验证所有的功能、性能以及其他特性是否和用户预期要求一致

系统测试：（最重要）真实的环境下，检查完整的程序能否和系统正确的配置、连接，并最终满足用户所有的需求。（再进行大规模的系统测试前，先进行冒烟测试）

系统测试和集成测试的区别：1、角度：集成测试偏重于技术角度，系统测试偏重于业务角度2、内容：集成测试偏重于各个模块之间的接口，系统测试偏重于整个系统的功能和性能3、技术：集成测试黑盒+白盒，系统测试黑盒

验收测试：Alpha测试和Beta测试都需要用户的参与，但是Alpha测试是用户在开发环境或公司内部模拟实际操作环境的测试；Beta测试由最终用户来测试

各阶段对应的文档：单元测试-详细设计说明书，集成测试-概要设计说明书，系统测试-需求规格说明书，验收测试-用户需求

2、按测试技术划分

黑盒：

特点：不查看内部逻辑，只查看功能是否能正常使用

缺点：覆盖率较低

优点：易实施，不需要关注内部实现

白盒：

特点：对程序内部结构分析测试，对所有代码路径进行测试，是一种穷举测试。

缺点：耗费较大，不能检测到遗漏的逻辑

优点：可检测到代码的每一条分支路径，揭示隐藏在代码中的错误，对代码的测试比较彻底。

方法：语句覆盖、条件覆盖、判定覆盖、条件组合覆盖、基本路径覆盖

灰盒：基于外部表现也基于内部逻辑

4、按代码运行

静态：不实际运行代码，静态检查代码、界面、文档

动态：实际运行代码，输入相应的测试数据，检查实际输出结果和预期是否相符。

5、按软件特性

功能测试：

性能测试：某一功能在指定时间、空间下是否正常使用。

安全性测试：检查程序内保护机制能否防止非法程序入侵，不受各个因素干扰。

6、其他

回归测试：新版本要重复旧版本的所有测试用例。目的：旧版本缺陷被修复、确认没有新缺陷

冒烟测试：对新版本大规模测试之前，先验证一个软件基本功能是否实现，是否具备可测性

随机测试：经验、直觉

猴子测试：意想不到的错误

九、软件测试的流程

需求分析（需求是否合理）---制定测试计划（人、时间、业务点、工具）---测试用例设计---执行测试（环境搭建、bug提交）---测试报告

详细工作流程：

1、需求分析会议：产品、开发、测试参加，主要探讨一些功能点--->需求文档、原型图、数据库表设计

2、开发员进行开发，测试经理编写测试计划--->测试计划

3、测试员参考需求规格说明书、原型图编写测试用例--->测试用例

4、先预测（主功能业务测试）-->依据测试用例进行系统测试-->提交跟踪bug--->测试完，编写测试报告

5、产品上线，维护性测试

职责划分：

1、测试员：设计测试用例测试脚本

2、测试经理：制定测试计划

3、评估测试--测试经理召集开发、测试来做

十、关于需求

1、需求定义：用户解决问题、达到目标所需的条件；系统或系统部件满足合同、标准、其他正式文档所需条件

用户需求：用户使用产品要完成的任务

业务需求：客户对产品高层次、高目标要求

功能需求：开发人员必须实现的功能

2、80、20原则

Bug分布：将近80%在需求和设计上，20%在程序和其他方面

3、产品需求变更怎么办？

先看改动的范围，如果改动的范围较小，重新测试；

如果改动范围较大，可以放在下一个版本或者争取延长测试时间；

如果不能争取时间，加班加点，且在报告中说明变更情概况。

十一、评审

1、评审的定义：正式的会议上将软件项目的成果提交给用户、客户、相关部门对软件产品进行评价和批准。

2、评审的目标：找问题（找出可能影响软件产品质量、开发过程、维护工作的适应性和环境方面的设计缺陷）、解决问题、改进和优化（性能、安全性、经济方面的改进）

3、分类：

同行评审：产品创建者的同行们，改进不足

单人评审：简单、单独一个评审员

管理评审：软件项目、产品管理者

代码检查：检查编写好的代码规范

十二、两个定义

Software test plan：测试员与开发交流的主要方式，最终目标是交流意图、理解任务，重要的是过程而不是文档

Testcase:设计一种情况，程序在这钟情况下，必须能够正常运行并且达到所设计的预期结果。

用例编写注意：不要穷举，详细与时间的平衡，多关注反向，用例库应该不断的更新，可以复用但要注意有效性，灵活……

十三、黑盒测试用例设计方法

1、等价类划分：

• 确定了取值范围，一个有效、两个无效
• 确定了输入值集合或规定了必须如何，一个有效一个无效
• 布尔一个有效一个无效
• 输入一组值n个，n个有效，一个无效
• 规定必须遵守规则，一个有效，n个无效
• 规定划分的等价类，要划分更小的等价类

2、边界值分析

• 规定了范围，取刚到达范围的边界值以及刚超越这个范围的边界值
• 规定了个数，取最大个数、最小个数、最大个数加一、最小个数加一
• 找其他可能的边界
• 若给出的输入域输出域是有效集合，选第一个和最后一个
• 若使用了一个内部数据结构，则选取这个内部数据结构边界上的值

3、因果图

• 适合多种输入条件的组合（案例：饮料机）

4、判定表驱动

• 条件排列顺序、规则排列顺序不影响操作，某个规则满足并确定执行操作，不比检验别的规则；（案例：累不累）

5、正交试验法

• 用最少的实验覆盖最多的操作，用例少，效率高
• 确定因素，确定每个因素的水平，选择正交表

十四、web测试方法

1、web功能测试

• 链接测试：检查链接是否正确；跳转页面是否存在；是否有孤立的页面
• 表单测试：表单控件是否正确；提交信息是否正确完整；是否有错误处理
• Cookie测试：（cookie通常标识用户信息、记录用户状态，使用web时会创建一个cookie文件，写入部分信息，若下次再访问，就能够正确的标识）检查cookie能否正常工作

2、web性能测试

• 速度测试：多长时间才能显示出来所需界面-----影响时间的因素有服务器（要从大量的数据中检索），硬件（cpu,内存），访问页面文件大小，网络
• 负载测试：一定负载下，web能否正常工作
• 压力测试：系统崩溃的临界点

3、web安全性测试

• 日志文件记录主要操作，加密技术要完整、正确，web是否有超时

4、web兼容性测试：服务端，客户端

5、web易用性测试：能否完成一个任务，完成一个任务多长时间，完成一个任务访问页面数，是否有明确的导航功能，帮助功能是否可靠、易用

十五、web测试、app测试区别

1、架构：web基于b/s,app基于c/s，web中只要更新了服务器，客户端会自动更新，app更新需要用户手动完成，app修改了服务器，意味着客户端使用的所有版本都要进行回归测试

2、性能：web关注响应速度，app关注电量、流量、cpu、内存

3、兼容性：web依赖浏览器、电脑硬件系统；app依赖手机、平板、安卓、ios；分辨率，尺寸，

4、app比web多一项---安装、卸载、更新、界面操作、触屏手势

十六、app测试关注哪些：

性能：cpu,内存，耗电量/流量（满格时候，省电模式），安装，卸载，更新，吞吐量（每秒系统能够处理的请求数），响应时间（处理一个请求的耗时），错误率（一批请求中出错的占比）

兼容性：不同系统上win,linux,unix，不同手机上android,ios

中断：电话、短信、断网

网络：三大运营商，数据wifi切换，4g2g切换，弱网，无网

十七、手动、自动化缺点，自动化意义

手动：

• 缺点：重复的手工回归测试代价昂贵容易出错；也依赖测试员的经验和能力
• 优点：手工测试员有经验和对错误的猜测能力；有审美能力、心理体验；有是非判断、逻辑推理能力

自动：

• 优点：回归测试更方便，缩短时间；可以运行更繁琐的测试；可以执行一些手工困难的、不可能的性能测试；更好的利用资源
• 缺点：不可以取代手工；手工比自动化发现的缺陷更多；对测试质量依赖很大；工具本身并没有想象力；制约软件的开发

自动化测试的意义：1、回归测试2、执行困难的压力、并发等性能测试3、更好的利用资源，节省时间、人

使用测试工具的意义：帮助测试找问题、协助问题诊断、节省测试时间

十八、bug周期、类别

New:测试员发现一个bug

Assigned:开发确认是一个bug

Open:开发处理bug

Fixed:开发自认为已修复

Pending Reset:（待测）

Reset:再测

Closed:确认解决

Reopen:再次打开

Pending Reject:开发拒绝

Rejected:被拒绝

Postponed:延期

new----assigned----open---fixed--pending reset---reset----closed---reopen---pending reject----rejected---postpoend

bug类型：代码错误，界面优化、设计错误、性能问题、测试脚本