软件测试知识点笔记整理

软件开发流程

1 需求分析

确定系统的功能需求、性能需求、可靠性需求，分析数据需求，建立逻辑模型，编写需求说明书。

2 总体设计和详细设计

2.1 总体设计

根据需求分析设计系统的结构，包括组成模块、模块的层次结构、各模块之间的关系和各模块的功能描述。

设计总体数据结构和数据库结构。

2.2 详细设计

在需求分析和总体设计的基础上进行模块的详细设计，确定各模块之间的详细接口信息，确定模块内数据流或控制流。

3 系统实现

根据概要设计说明书和详细设计说明书制定系统实现计划。按照编码规范和详细设计实现系统功能，在代码编写过程中编写软件功能说明、源代码说明。

4 系统测试

设计测试用例，对系统进行单元测试、集成测试，检查是否正确完成规定的功能，把检测出来的错误整理成文档。

编写测试报告和系统使用说明书。

5 系统部署与维护

软件开发模型

1 瀑布模型

​

需求分析——计划——设计——编码——测试

​

瀑布模型是最早出现的软件开发模型，是其他所有软件开发模型的基础框架，与软件生命周期不同的是它没有软件运行维护阶段。

描述：

每个阶段都只执行一次，是一个线性的软件开发模型。

优点：

• 为项目提供了按阶段划分的检查点，强调开发的阶段性。

• 强调早期的计划和需求分析调查。

• 强调产品测试。

缺点：

• 在各个阶段之间的反馈少。

• 只有在项目开发周期的后期才能看到成果，所以风险往往在后期测试阶段才会显露，失去了及早的纠正过程。

适用于需求明确且变更很少的项目。

2 螺旋模型

以原型为基础，沿螺线旋转，每转一圈都经过计划、风险分析、实施、评估等过程得到相应的版本，经过若干次螺旋上升后得到最终版本。

优点：

• 强调严格的风险分析，这种模型往往适用于规模庞大、风险大的项目。

• 强调各个开发阶段的质量。

• 这种开发模式会提供机会探讨项目是否有价值继续下去。

缺点：

由于引入了非常严格的风险识别、风险分析、风险控制，将会大大消耗人力、资源，如果严重影响了项目的利润，风险分析将毫无意义。

软件开发人员应擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。

软件建设周期长，但软件技术发展比较快，所以可能会和当前软件水平有较大的差距，无法满足当前用户需求。

软件生命周期

软件从提出、实现、使用维护倒停止使用的过程

1.需求分析

2.计划制定

3.软件设计

4.软件实现

5.软件测试

6.软件运行和维护

软件测试

1 定义

在规定条件下对程序进行操作，以发现程序的错误，对其是否能满足设计要求进行评估。

2 分类

按测试对象分和开发阶段为：单元测试、集成测试、系统测试、验收测试。

按测试方法分为：白盒测试、黑盒测试。

2.1 单元测试

定义：对软件中最小的可测试单元进行检查和验证。

目的：验证代码是否符合设计；发现需求和设计中存在的错误；发现编码过程中的错误。

方法：分为人工静态测试、自动静态测试、人工动态测试、自动动态测试。

• 人工静态测试：人工查阅代码检查错误。

• 自动静态测试：使用自动工具扫描代码，根据预先设定的错误特征扫描错误。

• 人工动态测试：人工设定程序的输入和预期的正确输出，执行程序，判断是否符合预期。

• 自动动态测试：使用工具自动生成的测试用例测试程序，通过捕捉某些错误特征来发现并报告错误。

2.2 集成测试

定义：以模块或子系统作为单元进行测试，主要测试接口间的关系。

目的：测试各个模块连接后，穿越模块间的接口数据是否丢失；测试各个子功能组合起来后是否实现预期的父功能；测试各模块是否会对其他模块产生负面影响；测试单个模块的误差在累积后是否会放大，达到不可接受的程度。

集成方法：自底向上集成、自顶向下集成、大爆炸集成、三明治集成等。

桩模块：模拟被测单元所调用的模块。

驱动模块：模拟被测单元的上级模块。

• 自底向上集成：从系统层次结构图的底层模块开始进行组装和测试。

• 自顶向下集成：按照系统层次结构图，以主程序模块为核心，自上而下按照深度优先或者广度优先的策略对各个模块一边组装一边进行测试。

• 大爆炸集成：一旦所有模块分别开发和测试后，全部集成并进行一次测试。

• 三明治集成：将系统分为三层，中间层为主目标层，自上到下的方法用于顶层到中间层的层，自下而上的方法用于底层到中间层的层，大爆炸方法用于中间的模块。

测试方法：非渐增式测试、渐增式测试。

• 非渐增式测试：将没个模块分别进行单元测试，然后再将所有模块按照设计组装起来进行测试。

• 渐增式测试：逐个把未经过测试的模块组装到已经测试过的模块上去进行集成测试，每加入一个模块就进行一次测试，重复此过程直至组装完毕。

2.3 系统测试

定义：将已经集成好的软件看成一个计算机系统的元素，与计算机的硬件、外设、某些支持软件结合在一起，在实际的运行环境下对软件系统进行测试。

目的：通过与系统的需求定义做比较，发现软件是否有与系统不符合或矛盾的地方，以验证软件系统的功能和性能等是否满足设计要求。

类型：功能测试、性能测试、可靠性测试、GUI测试等。

2.3.1 功能测试

定义：在已知软件所具有功能的基础上，以用户的角度对软件各功能进行测试，来验证功能是否能正常使用。

目的：验证是否有不正确或者遗漏的功能；验证实现的功能是否满足客户的需求；验证是否多出不需要的功能；验证输入是否能正确接受，是否能正确输出结果。

2.3.2 性能测试

定义：测试软件在系统中的运行性能。

分支：负载测试、容量测试、压力测试、基准测试等。

• 容量测试：确定系统可处理同时在线的最大用户数。

• 基准测试：

• 压力测试：逐渐增加对系统的压力，来获得系统能提供的最大服务级别或不能接受用户请求的性能点。

  压力测试可分为并发测试和大数据量测试。

  并发测试：测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题，如：线程所、内存泄漏、资源占用等。

  大数据量测试：针对某些系统存储、传输、查询等业务进行大数据量测试，如测试系统存储能力、IO传输速率、读取速率、慢查询等。

• 负载测试：通过逐步增加系统负载，测试系统性能变化，确定在满足系统性能需求的情况下，系统能承受的最大负载量。

  负载测试和压力测试的区别：负载测试用来评估系统的性能指标，压力测试是制造问题，然后分析引起问题的原因。

2.3.3 可靠性测试

定义：为了保证和验证系统可靠性而进行的测试。

目的：通过受控的软件测试预测软件在实际运行中的可靠性。

可靠性分析方法：失效模式影响分析、严酷性分析、故障树分析、事故树分析、潜在线路分析等。

2.4 GUI测试

定义：针对软件系统的GUI界面进行测试。

目的：测试界面实现是否符合界面设计；确认界面处理的正确性。

2.5 黑盒测试

定义：又叫功能测试，主要关注软件的功能实现，而不是内部逻辑，检测程序功能是否与设计需求一致，是否能正常运行。

方法：等价类划分法、边界值分析法、因果图法、错误推测法等。

• 等价类划分法：将程序所有可能的输入数据划分为若干个等价类，然后从每个部分中取有代表性的数据做测试用例，测试用例由有效等价类和无效等价类的代表数据组成。

• 边界值分析法：对输入输出的边界值进行测试，通常作为等价类划分法的补充。

2.6 白盒测试

定义：又叫结构测试，是一种测试用例设计方法，通过检查程序内部逻辑结构，对软件中的逻辑路径进行覆盖测试，在重程序不同地方设置检测点，检测程序状态，以确定实际运行状态与预期状态是否一致。

方法：静态分析、动态分析。

• 静态分析：控制流分析技术、数据流分析技术、信息流分析技术。

• 动态分析：逻辑覆盖率测试（分支测试、路径测试等）、程序插装等。

  • 语句覆盖：使程序中的每个可执行语句都能执行一次

  • 判定覆盖（分支覆盖）：对于判断语句，要设计判断结果为True和False两种情况

  • 条件覆盖：判断语句里面每个条件表达式True和False各取值一次，不判断语句的计算结果

  • 判定条件覆盖（分支条件覆盖）：判断语句中每个条件表达式的所有可能结果至少出现一次，每个判断语句本身所有可能结果也至少出现一次

  • 条件组合覆盖：判断语句中条件结果的所有可能组合至少出现一次

  • 路径覆盖：覆盖程序中所有可能的执行路径

3 流程

3.1 需求分析

确定软件的主要功能、流程、开发环境、运行环境、用户群、测试范围、测试优先级。

3.2 制定测试计划

确定测试范围：即被测项目中的功能模块、子功能模块等需要测试的范围。

确定测试策略：确定对哪些项目进行测试，如：功能测试、性能测试等。

确定测试方法：确定对每个策略使用说明方法，如：边界法、等价类等。

确定测试工具

确定测试资源

确定需要提交的文档

3.3 设计测试用例与编写

3.4 实施测试

3.5 提交缺陷报告

3.6 生成测试总结和报告

4 测试用例设计方法

用例编写核心内容：用例编号、所属模块、用例标题、优先级、前置条件、操作步骤、测试数据、预期结果、实际结果。

4.1 等价类划分法

定义：把所有可能输入的数据划分为若干个区域，在每个区域中取少量有代表性的数据进行测试。

等价类：某个输入域的集合，在这个集合中的每条输入条件都是等效的。

分类：分为有效等价类和无效等价类。

• 有效等价类：输入合理的数据集合

• 无效等价类：输入不合理的数据集合

类型：

• 取值范围型：如成绩0-100

• 恒等值型：只有一个结果是正确的

• 布尔值型：是或否

• 枚举类型：给出选项，选择其中一个

• 规则类型：给定要求，满足要求的均可，如邮箱、密码

4.2 边界值分析法

定义：取稍高于或稍低于边界的数据进行测试。

确定边界值的方法：

• 上点：指边界上的点。

• 离点：指离上点最近的点，如果域为开区间，离点在域内，如果域为闭区间，离点在域外。

• 内点：所有在域内的点都为内点。

4.3 场景法

定义：尽可能全面真实的模拟用户的操作，将用户有可能的操作都列出来，进行测试。

核心概念：

• 基本流：正确流、有效流，模拟用户正确的操作流程

• 备用流：无效流，模拟用户错误的操作流程

5 缺陷管理

基本概念：软件缺陷基本概念分为：缺陷、故障、失效。

缺陷（Defect）：存在于软件之中的偏差，可被激活，存在于软件内部中。相当于bug。

故障（Fault）：软件运行中出现的状态，可引起意外状况，如果不进行处理，可产生失效，是一个动态行为。

失效（Failure）：软件运行时产生的外部异常行为结果，表现与用户需求不一致，功能能力终止，用户无法完成所需要的应用。

软件中的bug不一定被激活，激活后也不一定表现为故障，故障也不一定会导致失效。

软件缺陷报告单：发现软件缺陷失效后，提出书面报告，提供给开发人员作为定位缺陷的依据，也作为日后统计缺陷数量的依据。

软件缺陷报告内容：

缺陷标题/简单描述：对测试过程中出现的问题进行简单概要的描述

重现步骤：

① 描述问题的基本环境，包括操作系统、硬件环境、网络环境、被测试的软件环境等；

② 描述软件出现异常时测试人员的操作步骤和使用数据；

③ 缺陷的原因的分析；

④ 重复操作多少次后bug仍然存在；

⑤ 相关附件；

⑥ 缺陷的属性：

① 缺陷发现人；

② 缺陷发现时间；

③ 缺陷状态：

New：缺陷的初始状态；

Open：开发人员开始修改缺陷；

Fixed：开发人员修改缺陷完毕；

Closed：回归测试通过；

Reopen：回归测试失败；

Postpone：推迟修改；

Rejected：开发人员认为不是程序问题，不需要修改；

Duplicate：与已经提交的Defect重复；

Abandon：被Rejected和Duplicate过的Defect，被测试人员确认后的确不是问题，将Defect置为此状态。

④ 缺陷严重程度（Severity）：

致命的软件缺陷（Fatal）：造成系统或应用崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块或相关模块异常等问题。如：代码错误，死循环、数据库死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等。

严重错误的软件缺陷（Critical）：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如：致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件。

一般错误的软件缺陷（Major）：次要功能没有完全实现但是不影响使用。如：提示信息不太准确，或用户界面差，操作时间长，模块部分功能失效等，打印内容、格式错误，删除操作未给出提示，数据库中有过多的空字段等。

较小错误的软件缺陷（Minor）：使操作者不方便或遇到麻烦，但不影响操作和执行，如：错别字、界面不规范，辅助说明描述不清楚。

建议问题的软件缺陷（Enhancemental）：由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。

⑤ 缺陷的优先级（Priority）：bug修改的先后顺序

P0：优先级最高，必须当天修改；

P1：1-2天内修改；

P2：2-4天内；

P3：一周内；

P4：发布周期内或不修改。

⑥ 缺陷的类型：

（1）质量特性：功能；性能；安全性；易用性；可靠性。

（2）功能性角度：错误；遗漏；多余的；可优化。

6 web端和app端常见测试点

6.1 web端

6.1.1 输入框

6.1.1.1 字符型输入框

1 字符：英文全角、半角，数字、空、空格、特殊字符，使用粘贴功能输入（包括特殊字符）。

2 长度：最大、最小长度，最大长度+1，最小长度-1。

3 空格：字符，字符后，字符间，字符前后。

4 多行文本框输入：输入回车换行后保存的格式，仅输入回车换行能否正确保存。

5 安全性：特殊字符，如：null、NULL、JavaScript、document.write("hello,world")等。

6.1.1.2 数字型输入框

1 边界值：最大、最小值，最大值+1，最小值-1。

2 位数：最大、最小位，最大位+1，最小位-1，超长值，整数。

3 异常值：特殊字符，如NULL、空格等，禁止输入特殊字符验证是否可以通过粘贴输入。

6.1.1.3 日期型输入框

1 合法性检查：月输入1、5、7、8、10、12，日输入0日、31日、32日；输入非闰年，月输入2，日输入28、29；输入闰年，月输入2，日输入29，30.

2 异常值：特殊字符，如NULL、~!@#$%^&*()等。

6.1.1.4 信息重复

在需要输入唯一性数据的时候重复输入。

6.1.2 搜索框

6.1.2.1 功能实现

输入系统中不存在的数据；如果支持模糊查询是否名称中每一个字都能查到；较长的名称是否能查到。

6.1.2.2 组合查询

多个查询条件时，组合不同条件查询，检测是否出错；不同查询条件来回切换检测是否出错。

6.1.3 添加、修改、删除

6.1.3.1 添加

必填项检查；唯一性字段是否可以重复添加；提交时连续多次点击检测是否会连续增加相同的数据或报错；是否支持Tab和Enter键；不符合要求的地方是否有错误提示。

6.1.3.2 修改

对每个编辑项进行修改保存，检查是否能保存成功；编辑时输入长度是否与添加时一致；修改数据后，查询页面数据是否能及时更新；是否支持Tab和Enter键；不符合要求的地方是否有错误提示。

6.1.3.3 删除

删除时是否有二次确认提示；只有一条数据时是否能删除成功；是否可以连续删除多条数据；删除一条数据后是否可以添加一条相同的数据；删除数据后查询页面数据是否能及时更新。

6.1.4 注册、登录功能

6.1.4.1 注册

注册成功后应以登录状态跳转到首页或指定页面；注册时删除已输入的信息，检查是否能注册成功。

6.1.4.2 登录

输入正确的账号和正确的密码；

输入正确的账号和错误的密码；

输入错误的账号和错误的密码；

输入错误的账号和错误的密码；

输入账号不输入密码；

不输入账号输入密码；

不输入账号和密码；

输入正确的账号和正确的密码，但不区分大小写；

账号和密码包含特殊字符；

账号和密码输入超长值；

页面刷新或重新输入时验证码是否更新。

6.1.5 图片上传功能

文件类型正确，大小合适；

文件类型正确，大小不合适；

文件类型不正确，大小合适；

文件类型不正确，大小不合适；

文件类型和大小都正确，选择上传正在使用中的图片；

输入不存在的图片地址上传；

连续多次选择不同的文件，查看是否上传最后一次选择的文件。

6.1.6 查询功能列表

列表、列宽是否合理；

列表数据太宽有没有提供横向滚动；

列名是否与内容对应；

列名是否描述清晰；

是否将不必要的列显示出来。

6.1.7 返回、回车、刷新键检查

一条已经成功提交的记录，返回后再提交，检查是否做了处理；

多次反复使用返回键，检查是否出错；

输入结果后直接按回车键，看系统如何处理，检查是否会报错；

使用刷新键，看系统如何处理，检查是否会报错。

6.1.8 测试点检查

6.1.8.1 直接URL链接检查

在地址栏直接输入各功能的URL地址，检测是否能链接查看（匿名查看），是否有权限控制，是否直接执行，并返回相应结果页。

6.1.8.2 相关性检查

功能相关性：删除或增加一项会不会对其他项产生影响，如果产生影响，这些影响是否正确。

数据相关性：下拉列表默认值检查，下拉列表值检查。

6.1.8.3 按钮功能正确性检查

新增、编辑、删除、关闭、返回、保存、导出、导入、下一页、上一页、页面跳转、重置等功能是否正确。

6.1.9 页面和易用性检查

风格、样式、颜色是否协调；

页面布局是否整齐、协调；

界面操作、标题描述是否恰当；

操作是否符合常规习惯；

提示界面是否符合规范；

界面中各个控件是否对齐；

日期控件是否可编辑；

日期控件长度是否合理，是否可以在修改时显示出全部时间；

查询出来的列表列宽是否合理，标签描述是否合理；

信息较长的文本，文本框是否有滚动条；

数据录入控件是否方便；

控件的描述提示是否准确；

使用滚动条移动页面时，页面控件显示是否正常；

日期格式是否正确；

页面是否有多余控件或标签；

窗口的标题或图标是否与菜单栏的统一；

窗口的最大化和最小化是否能够正常切换；

对于正常的功能，用户不需阅读用户手册就可使用；

执行风险操作时是否有二次确认；

操作顺序是否合理；

系统应该在用户做出错误的操作之前提出警告、提示信息；

页面分辨率检查，在各种分辨率浏览系统检查系统界面的友好性；

检查本地化是否通过，英文翻译是否准确，英文版是否出现中文等。

6.1.10 兼容性检查

不同操作系统和浏览器下的兼容；

不同硬件下的兼容等。

6.1.11 连接测试

保证链接的可用性和正确性。

6.1.11.1 导航测试

web应用系统是否易于导航：导航是否直观，web系统的主要部分是否可以通过主页存取，是否需要站点地图、搜索引擎或其他导航的帮助；

页面结构、导航、菜单、连接的风格是否一致等。

6.1.11.2 图形测试

确保图形有明确的用途，图片尺寸尽量要小，并且要能清楚的说明某件事情，一般都能链接到某个具体的页面；

验证所有页面字体的风格是否一致；

背景颜色应该与字体颜色和前景颜色相搭配；

文字回绕是否正确；

图片大小和质量，一般采用JGP或GIF压缩，最好使大小降到30k一下。

6.1.12业务流程测试（主要功能测试）

在保证单个模块功能正确的前提下，对各个模块间传递的数据进行测试。

6.1.13 安全性测试

SQL注入；

XSS跨网站脚本攻击；

验证码更新问题；

页面是否有超时限制；

检测是否可以在不登录的情况下访问必须登录才能访问的页面。

6.1.14 性能测试

6.1.14.1 连接速度测试

web响应时间

6.1.14.2 负载测试

检测web系统可承载多少用户同时在线，超出后系统会怎样；能否处理大量用户对同一个页面的访问。

3.1.14.3 压力测试

在系统发布以后，在实际的网络中进行测试，检测系统限制和故障恢复能力，即测试系统会不会崩溃，在什么情况下崩溃。

6.2 app端

6.2.1 安装、卸载测试

6.2.2 启动app测试

6.2.3 升级测试

6.2.4 功能测试

功能点、业务逻辑、服务端接口测试等。

6.2.5 性能测试

启动时间、响应时间等。

6.2.6 安全测试

敏感信息传输是否加密、单点登录、长时间不处理自动注销、应用切换到后台是否模糊处理等。

6.2.7 Android特性测试

横竖屏、home键、返回键、功能键等。

6.2.8 各种网络状态下测试

网络切换、弱网络状态数据加载处理方式。

6.2.9 中断性测试

突然来电、短信弹出、低电量时能否正常使用、蓝牙数据传输、连接电脑等。

6.2.10 兼容性测试

Android各个版本、各种分辨率下能否正常使用，与第三方app的兼容。

6.2.11 app对资源的的占用

6.2.12 app权限

通讯录、摄像头、相册、麦克风、位置等，在程序安装启动时是否提示用户涉及到的内容。

6.2.13 分享功能

6.2.14 清空数据或强制退出后能否正常使用