测试基础

软件开发过程与软件测试的关系

1. 什么是软件测试？ 在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否满足设计要求进行评估的过程

敏捷测试

1. 什么是敏捷测试 敏捷测试即不断修正质量指标，正确建立测试策略，确认客户的有效需求能得到圆满实现和确认整个生产的过程是安全的、及时的发布最终产品。

敏捷测试是遵循敏捷宣言的一种测试实践：

• 强调从客户的角度，即从使用系统的用户角度，来测试系统
• 重点关注持续迭代地测试开发的功能，而不是强调传统测试过程中严格的测试阶段
• 建议尽早开始测试，一旦系统某个侧面可测试，比如提供了模块功能就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。

2. 敏捷测试与普通测试的区别？

• 项目相当于开发与测试并行，项目整体时间较快
• 模块提交较快，测试时较有压迫感
• 工作任务划分清晰，工作效率高
• 项目规划合理，不然测试时会出现复测的现象，加大工作量
• 发现问题需紧跟，项目中人员都比较忙，问题很容易被遗忘
• 耗时、或较难解决对项目影响不大的问题一般会遗留到下个阶段
• 发现bug能够很快的解决，对相关的模块的测试影响比较小
• 版本更换比较勤，影响到测试的速度
• 要注意版本的更新情况
• 要多与开发沟通

3. 敏捷测试的方法有哪些？ scrum 并列、极限编程、精益、看板

4. 敏捷开发的特点

• 快速迭代：产品通过短周期的迭代交付，通过不断迭代完善产品
• 快速尝试：避免过长时间的需求分析及调研，快速尝试
• 快速改进：在迭代周期过后根据客户反馈快速改进
• 充分交流：团队成员无缝的交流，如每天短时间的站立会

软件测试方法和策略

软件测试方法包括：白盒测试、黑盒测试、灰盒测试、静态测试、动态测试

白盒测试

白盒测试：是一种测试用例设计方法，在这里盒子指的是被测试的软件，白盒，顾明思义即盒子是可视的，你可以清楚盒子内部的东西以及里面是如何运作的，因此白盒测试需要你对系统内部的结构和工作原理有一个清楚的了解，并且基于这个知识来设计你的用例。

1. 白盒测试有几种方法

• 功能是检查软件的表达和描述是否一致，没有冲突或者没有歧义
• 动态：语句覆盖、判断覆盖、条件覆盖、判断条件覆盖、条件组合覆盖、路径覆盖

2. 白盒测试的优缺点

• 优点：迫使测试人员仔细思考软件的实现；可以检测代码中的每个分支和路径；揭示隐藏在代码中的错误；对代码的测试比较彻底；最优化。
• 缺点：昂贵；无法检测代码中遗漏的路径和数据敏感性错误；不验证规格的正确性。

灰盒测试

最常见的灰盒测试是集成测试。集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成为子系统或者系统。

1. 集成测试策略

• 自顶向下测试
• 自底向上测试
• 核心系统测试
• 高频集成测试

黑盒测试（功能测试）

黑盒测试又叫功能测试，这是因为黑盒测试中主要关注被测软件的功能实现，而不关注内部逻辑。在黑盒测试中，被测对象的内部结构，运行情况对测试人员是不可见的，测试人员对被测产品的验证主要是根据其规格，验证其与规格的一致性。

1. 系统测试策略 功能测试、性能测试、可靠性测试、负载测试、易用性测试、强度测试、安全测试、配置测试、安装测试、卸载测试、文档测试、故障测试、界面测试、容量测试、兼容性测试、分布式测试、可用性测试

单元测试、集成测试、系统测试区别

1. 测试方法不同

• 单元测试属于白盒测试范畴
• 集成测试属于灰盒测试范畴
• 系统测试属于黑盒测试范畴

2. 考察范围不同

• 单元测试主要测试单元内部的数据结果、逻辑控制、异常处理等
• 集成测试主要测试模块间的接口和接口数据传递关系、以及模块组合后的整体功能。
• 系统测试主要测试整个系统相对于需求的符合度。

3. 评估基准不同

• 单元测试的评估基准主要是逻辑覆盖率
• 集成测试的评估基准主要是接口覆盖率
• 系统测试的评估基准主要是测试用例对需求规格的覆盖率

验收测试

验收测试时部署软件之前的最后一个二测试操作。在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。

1. 验收测试类型 正式验收测试、alpha测试、beta测试
2. alpha和beta的区别？

• alpha测试时由一个用户在开发环境下进行测试的。alpha测试不能由程序员或测试完成。alpha测试发现的错误，可以在测试现场立即反馈给开发人员，由开发人员及时分析和处理。alpha测试是可控的。
• beta测试由软件的最终用户们在一个或多个真实环境下进行测试。开发者通常不在测试的现场，Beta测试不可控。

功能测试

功能测试就是对产品的各项功能进行测试，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能

测试用例设计方法

1. 等价类划分 根据程序对数据的要求，把程序的输入域划分成若干个部分，区分出那些数据是有效的，那些数据是无效（有效等价类和无效等价类）。从每个部分选取少数代表性数据作为测试用例
2. 边界值分析发 找到测试数据的边界点，分析出上点、离点、内点，根据上点、离点、内点写出测试用例要点：

• 如果输入条件规定了值的范围，则应取边界点数据，以及边界点两边的数据进行测试
• 如果输入条件规定了值的个数，则用最大个数及其两边的点、最小个数及其两边的点作为测试数据
• 如果程序的规格说明给出了输入域或者输入出域是有序集合，则应选取集合的第一元素和最后一个元素作为测试用例 3.场景法 场景法就是模拟用户操作软时的场景，主要用于测试系统的业务流程

步骤：

• 根据说明、描述出程序的基本流及各项备选流
• 根据基本流和各项备选流生成不同的场景
• 对每个场景生成相应的测试用例

要点：

• 基本流：按照正常义务的流程来实现的一条操作路径
• 备选流：导致程序出错的操作流程

4. 状态转换图法 找出软件所有的状态以及导致这些状态发生变化的所有输入动作，进而用图形的方法把相关联的输入动作和状态联系在一起，真实模拟用户的操作顺序流程
5. 因果图 在一个模块或一个界面中，有多个控件，这些控件的存在约束关系或组合关系，且输出依赖于输入条件，则可以使用因果图法。

步骤：

• 找出所有输入条件
• 找出所有输出条件
• 明确所有输入条件之间的制约关系以及组合关系
• 明确所有输出条件之间的制约关系以及组合关系
• 找出怎么样的输入条件组合会产生哪种输出结果
• 根据因果图表写出判定表
• 根据判定表写出测试用例

要点：

• 恒等、或V()、与(^)、非(~)
• 互斥(E)：a和b中至多有一个可能为1，即a和b不能同时为1
• 包含(I)：a、b和c中至少有一个必须是1，即a、b和c不同是为0
• 唯一(O)：a和b必须有一个，且仅有1个为1
• 要求(R)：a是1时，b必须是1，即不可能a是1是b是0
• 屏蔽(M)：输出条件的约束只有M约束（强制），若结果a是1，则结果b强制为0
• 因果图法主要考虑控件之间条件的组合关系
• 每个控件的条件不宜过多，最好为2个
• 控件较多，或每个控件的条件过多，不宜用因果图法

6. 判定表

测试用例

1. 测试用例包含哪些要素？ 测试用例编号、所属模块、用例标题、重要级别、前置条件、输入数据、操作步骤、预期结果

2. 好的测试用例的特性？ 覆盖率、规范性、可测试性、复用率、稳定性、有效性、准确、指导性、高效性、简洁、一致性、清晰明了

3. 为什么要进行测试用例评审及评审流程？ 测试用例是软件测试的准则，但它并不是编制完成后就直接成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。

用例评审的内容：

• 用例设计的结构安排是否清晰、合理、是否利于高效对需求进行覆盖
• 优先级安排是够合理
• 是否覆盖测试需求上的所有功能点
• 用例是否具有好的可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法
• 是否已经删除了冗余的用例
• 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&&8法则，那就是4倍与正面用例的数据，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。
• 是否从用户层面来设计用户使用场景和使用流程的测试用例
• 是否简洁、复用性强

用例评审过程：

• 提前发出用例初稿，并确定参与用例评审人员，目前我们是只包含测试工程师和测试经理参与
• 先做简单的业务流程介绍，这个是在评审开始尤为重要的一个过程，刚开始评审，参与人员会比较蒙圈，其他测试工程师可能都不知道测试的思路。
• 按模块进行，有些模块，业务性不是特别强，可以简单说下。每个模块评审的时候，按测试项分类，UI、核心功能、基础功能、边界测试、兼容测试和异常测试等，预期结果类似的，主要讲清楚用例主题，让参与人员知道每条用例是做什么的
• 按业务流程进行，业务流程性较强的需要求，需要有业务场景和逻辑，按一定的顺序来；
• 按测试数据进行，涉及到计算逻辑、收益、报表等需求的，用例编写时会先规划好测试数据，尽管测试数据页是按不同的业务场景来设计的，但直接用测试数据来评审你的测试点，会更清晰。

用例评审需要避免：

• 测试点含糊用语，每个用例评审都应该确定最终版，稍有矛盾或疑惑的需求，都应该确认下来，不能含糊不清
• 测试用例本身的描述是否清晰，是否存在二义性
• 是否考虑到测试用例的执行效率，往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率低下
• 是否针对需要变更进行跟进，覆盖了所有的测试需求
• 是否尽可能的覆盖了异常流程和异常测试点

4. 设计一下登录的测试用例

界面UI上：

• 从上往下，检查界面，是否完整显示
• 界面是否美观，风格是否和其他界面统一

功能上：

• 支持登录的方式（手机登录、第三方登录）
• 登录输入框的验证（不输入、输入空格、最大输入限制、特殊符号、特殊字符null）
• 密码输入框是否支持隐藏/显示密码
• 密码输入框是否限制了条件
• 正确的用户名和密码登录是否成功
• 登录失败是否有准确的提示(已被删除的用户、用户账户或密码错误)
• 升级版本后，是否可以正常登录
• 是否存在忘记密码登录的功能

性能上：

• 同时支持多少人同时登录的请求
• 用户登录的响应时间是否小于3秒

安全上：

• 登录共鞥使用的时http还是https，数据传输是否安全
• 登录密码是明文传输还是密文传输
• 是否存在安全漏洞，如XSS、SQL注入等
• 登录成功的标识是使用cookie保存在客户端还是生成了session保存在服务器端
• 登录后cookie的时效性，是否有超时需重新登录的机制
• 是否有登录失败次数限制
• 是否存在越权问题。如使用a账号登录，换成b账号，还能看到a账号的信息
• 是否支持多设备登录，不支持是否有踢退机制

兼容性上：

• 登录功能是否支持web断，app端甚至小程序端的数据连通
• 对于移动设备、不同分辨率、不同系统UI显示的兼容

网路：

• 2G/3G/4G/5G网络是否正常登录
• 网络切换，wifi与移动输入的切换
• 弱网登录，是否有友好的交互

1. web测试基于实际测试的功能测试点总结

• 页面链接检查：每个链接是否都有对应的页面，并且页面之间切换正确
• 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否正确
• 检查按钮的功能是否正确：如update、cancel、delete、save等功能是否正确
• 字符串长度检查：输入超出需求所说明的字符串长度的内容，看系统是否检查字符串长度，会不会出错
• 字符类型检查
• 标点符号检查
• 中文字符处理
• 检查带出信息的完整性：在查看信息和update信息时，查看所填写的信息是够全部带出，带出信息和添加的是够一致
• 信息重复
• 检查删除功能：在一些可以一次删除对个信息的地方，不选择选择任何信息，按delete，看系统如何处理，是否会出错；然后选择一个和多个信息，进行删除，看是否正确处理
• 检查添加和修改是否一致
• 检查修该重名
• 重复提交表单
• 检查多次使用back键的情况
• search检查：在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确，如果可以输入多个search条件，可以同时添加合理和不合理的条件，看系统处理是否正确
• 输入信息位置：注意在光标停留的地方输入信息是，光标和输入的信息会否跳到别的地方
• 上传下载文件检查：长传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息。并检查系统是够能够做到
• 必填项检查
• 快捷键检查

缺陷

软件缺陷等级划分

1. A类,致命错误，包括：

• 由于程序所以其的死机，非法退出
• 死循环
• 数据库发生死锁
• 因错误操作导致的程序中断
• 数据流错误
• 程序通讯错误
• 严重的数值计算错误

2. B类,较严重错误，包括以下各种错误

• 程序错误
• 程序接口错误
• 数据库的表、业务规则、缺省值未加完整性等约束条件
• 轻微的数据计算错误

3. C类，一般错误，包括：

• 操作界面错误（包括数据窗口内列名定义、含义是否一致）
• 打印内容、格式错误
• 简单的输入限制为放在前端进行控制
• 删除操作未给出提示
• 数据库表中有过多的空字段 4.D类，较小错误，包括以下各种错误：
• 界面不规范
• 辅助说明描述不清楚
• 输入输出不规范
• 长操作未给用户提示
• 提示窗口文字未采用行业术语
• 可输入区域和只读区域没有明确的区分标志
• E类：测试建议

缺陷的分类

1. 功能遗漏
2. 功能实现错误
3. 实现了产品规格说明中没有提到的功能
4. 没有实现产品规格说明中没有明确提及但应该实现的功能（如用户登录时，密码应该加密显示）
5. 错误性差、界面不友好、兼容性差

缺陷的生命周期

1. new 新建：缺陷第一次递交的时候，状态即为“新建”。就是说缺陷未被确认其是否是真正是一个缺陷
2. open 打开：在测试者提交一个缺陷后，测试组长确认其确实为一个缺陷的时候，会把缺陷状态置为“打开”并分配给相应的开发人员
3. test 测试（已修复）：开发人员修复缺陷后，会将bug状态提交给测试组进行新一轮的测试
4. verified 确认：开发人员被分配缺陷后，如果认为这个缺陷时真是存在的，会将缺陷状态改为“确认”
5. deferred 延期：意味者缺陷将会在下个版本中修复
6. reopende 重新打开：如果缺陷被开发人员修复后仍然存在，测试人员会把缺陷状态置为“再次打开”
7. duplicate 重复：同一个缺陷被重复提交或者两个bug表明的意思相同
8. rejected 拒绝：开发人员不认为其是个缺陷，他不会接受
9. closed 关闭：一旦缺陷被修复，测试人员会对其进行验证，如果测试人员认为缺陷不存在了会将状态改为“关闭”

性能测试

性能测试是通过自动化的测试工具模拟多种正常，峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。

负载测试

1. 什么是负载测试？ 确定在不同负载下系统的性能，目标是测试当负载逐渐增加时，系统各项指标的变化情况
2. 什么是压力测试？ 通过确定系统系统的瓶颈或不能接受的性能点，来获得系统提供的最大服务级别的测试。
3. 什么是恢复测试？ 主要关注导致软件运行失败的各种条件，并验证其恢复过程能够正确执行，在特定情况下系统需要具备容错能力。
4. 什么是健壮性测试？ 即测试软件系统在异常情况下能否正常运行的能力。健壮性有两层含义：一是容错；二是恢复能力

测试结束的标准

1. 系统测试退出标准：

• 系统测试用例设计已经通过评审
• 按照系统测试计划完成了系统测试 系统测试的功能覆盖率达100%
• 系统的功能和性能满足产品需求规格说明书的要求
• 在系统测试中发现的错误已得到修改并且各级缺陷修复率达到标椎
• 系统测试后不存在A、B、C类的缺陷 D类缺陷允许存在，不超过总缺陷的5% E类缺陷允许存在、不超过总缺陷的10%