！ 仅供参考！有错误的地方请指出，我会及时修改！感谢！！！

1.什么是软件测试

• 软件测试就是验证软件是否满足客户的需求

2.软件测试和开发的区别

2.1软件测试和开发中调试的区别

2.1.1目的不同：

• 测试：测试是测试人员检测软件是否实现了软件他应该实现的功能
• 开发调试：调试是程序员检查代码是否实现了他想让代码实现的

2.1.2角色

• 测试：测试人员和开发人员
• 调试：开发人员

2.1.3阶段

• 软件测试在软件开发整个生命周期
• 软件调试：在开发阶段

2.2技术角度

• 软件测试对技术要求广，但是深度低，要求会使用各种技术工具（语言或者具体工具）
• 软件开发：对技术要求比较专一，深度会高

3.为什么要选择软件测试（zqsg）

• 兴趣
• 技能
• 抗压力
• 责任感
• 性格特征

4. 需求是什么

• 满足用户的期望或正式规定的文档（合同，标准，规范）所需要的权限和技能。
• 用户需求：最原始的需求，比较广，有可能存在不能实现的需求，所以测试人员需要对需求进行分析和验证。
• 软件需求：经过打磨的用户需求形成的文档

5.BUG

• 当且仅当，软件需求规格说明存在且合理的情况下，如果软件功能和需求规格说明不相符，那说明是软件错误（BUG）；
• 当软件需求规格说明不存在的情况下，用户需求存在且合理，如果软件功能和用户需求不相符，那说明是软件错误（BUG）；

6.测试用例

• 测试用例就是向被测试系统发起的一组集合，包含测试环境，测试步骤，测试数据，预期结果，标题，测试功能模块，优先级，重要性等。

7.开发模型

7.1敏捷模型：

• scrum开发流程：产品发布会议，迭代计划会议，开发期间的每日站会，演讲会议，回顾会议。
• 角色：产品经理（po），项目经理（SM），研发团队（st）
• 敏捷开发模型中测试人员怎么测试？
• 核心人物：找BUG，还需要和开发人员一起找问题产生原因

7.2瀑布模型

• 优点： –强调开发的阶段性； –强调早期计划及需求调查； –强调产品测试。
• 缺点： –依赖于早期进行的唯一一次需求调查，不能适应需求的变化； –由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程； –风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

7.3螺旋模型

• 优点： –强调严格的全过程风险管理。 –强调各开发阶段的质量。 –提供机会检讨项目是否有价值继续下去。
• 缺点： –引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入。

7.4增量，迭代模型

• 增量通常和迭代混为一谈，但是其实两者是有区别的。
• 增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚
• 迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。

8.软件测试模型

8.1V模型

8.2W模型

9.如何描述BUG

• 测试版本
• 测试环境（设备，系统）
• 测试步骤
• 测试数据
• 预期结果
• 实际结果
• 附件（错误截图，错误日志）

9.1 BUG等级

• 1、 Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。
• 2、 Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。
• 3、 Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
• 4、 Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

9.2面试题

• 系统新功能上线，发现用户使用某功能时系统崩溃，并无法修复，这时候测试人员应该怎么处理？
• 1.回退版本（回退到系统的一个稳定版本）
• 2.抓紧时间修复问题

9.3BUG生命周期中的状态

• 新建—确认–重新打开–延迟—-解决—关闭

9.4bug修复后仍存在

• 开发人员修复了一个bug，你测试的时候发现这个bug仍然存在，可能是什么原因？
• 1.让开发检查是否提交新代码
• 2.测试人员没有重新发布测试环境的代码
• 3.确实开发人员没有修改成功

10.软件测试人员和开发人员因为bug产生冲突怎么处理？

• 1.检查自身bug描述是否清楚
• 2.站在用户的角度去说服开发人员
• 3.bug定级是否准确按照公司相关文件
• 4.测试人员要不断提高自身技术和业务水平，要能够发现bug，要定位bug产生原因，以及bug的解决方案
• 5.开三方会议，产品经理，开发人员，测试人员一起讨论BUG的解决方案。

11.测试用例的依据

• 根据需求文档设计
• 分析需求，细化需求，从需求当中提取出功能点/测试点，然后再用设计测试用例的具体方法去设计测试用例

12.黑盒测试设计测试用例的方法

• 等价类
• 边界值
• 因果图
• 场景设计法
• 错误猜测法
• 正交法

1.测试用例

1.1等价类（测试用例无法穷举的情况）

1.1.1 定义

• 把输入（特殊情况下才考虑输出）划分成若干个等价类（有效等价类和无效等价类），从每一个等价类当中选一个测试用例进行测试，如果这个测试用例通过，我们就说这个测试用例代表的等价类通过。

1.1.2实例

• 例如：输入用户名（具有一定规则，8–12），进行测试，不可能全部测试完，选取一部分
• 使用情况：测试用例太多，没有办法穷举
• 分类：
• 有效等价类：符合数据规则，有意义（8-12）
• 无效等价类：不符合数据规则，没意义（<8,>12）
• 测试的时候有效无效都需要测试

1.2边界值（很重要）

• 针对输入边界进行测试的设计，叫做边界值法
• 例如：7，8，12，13位用户名
• 等价类和边界值往往结合在一起进行测试用例的设计

1.3因果图

• 逻辑图：与，或，非，恒等
• 使用情况：当输入有多个，且不同的输入对应着不同的输出，可以用因果图法进行测试用例的设计
• 使用因果图法设计测试用例的步骤
• 1.找出所有的输入和输出
• 2.确定不同输入组合和输出的关系
• 3.根据确定出的关系华因果图
• 4.根据因果图画判定表
• 5.写测试用例

1.4场景法

1.1.1定义

• 把系统中一个一个孤立的功能点按照一定的逻辑组合起来，形成一个场景/业务，针对这个场景进行测试。
• 首先确定场景中的每一个功能点，确定功能可能的输入和不同的输出。

1.1.2实例： 测试页面上一个按钮：登录按钮

1.界面

• 按钮是否在合理的位置
• 颜色大小是否按照UI设计稿进行设计的
• 按钮对其他文字或者图片有没有遮挡
• 按钮是否可以点击
• 点击按钮是否调用了对应的接口，是否返回正确的响应
• 调用接口进行接口测试

1.5错误猜测法

1.1.1定义

• 根据测试人员的直觉，经验，知识去判断系统的某一个模块的问题，有针对性的设计测试用例。
• 是一种补充的测试用例的方法

1.6正交法

1.6.1定义

• 研究多因素多水平的一种测试用力的方法，根据郑侥幸，找出最优的输入组合，进行试验，分析实验的结果，用这些结果来衡量整体实验的结果

2.按照开发阶段划分

2.1单元测试

• java单元测试框架
• Junit
• 白盒测试框架
• 很重要！！！
• 依据是：详细设计文档

2.2集成测试

• 按照一定的策略把单元功能模块组装起来，对组装起来的模块进行测试。
  
  测试阶段：单元测试之后
  
  测试依据：概要设计文档
  
  测试对象：接口
  
  测试方法：黑盒和白盒相结合
  
  测试人员：黑盒测试工程师和白盒测试工程师
  
  测试内容：模块和模块之间的借口，全局数据结构的测试，单模块缺陷对系统的影响，模块功能的正确性，冲突

2.3系统测试

测试阶段：集成测试通过之后

测试对象：整个软件系统

测试人员：黑盒测试工程师

测试依据：详细设计文档

测试方法：黑盒测试

测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性，可移植性等

2.4回归测试(Regression Testing)

• 查看新引入的代码对旧的功能是否有影响
• 原因：改BUG，系统进行正常迭代增加的功能

2.5冒烟测试（smoke testing）

• 对系统的主要功能和核心流程进行测试，是判断我们测试人员是否进行系统测试的依据

2.6验收测试

系统文档：产品设计文档，用户功能手册，产品使用说明书等

测试阶段：系统测试之后

测试依据：用户需求

测试方法：黑盒测试

测试人员：用户

测试内容：和系统测试一致，增加了文档测试

3.按照实施组织划分

3.1α测试

3.1β测试

3.1第三方测试

4.是否手工划分

4.1手工测试

4.2自动化测试

5.是否运行代码

5.1静态测试

5.2动态测试

6.按照是否查看代码划分

6.1黑盒测试

• 不关心软件内部代码的逻辑，结构实现，只关心输入和输出
• 等价类划分法，边界值分析法 ，因果图法，正交实验法，场景设计法，错误推测法

6.2白盒测试

• 测试程序的内部的逻辑，结构的实现，是否实现了相应的功能。
• Junit框架
• 语句覆盖
• 逻辑覆盖（判定覆盖，条件覆盖，判定组合，条件组合，判定和条件组合）
• 路径覆盖
• 循环覆盖

7.按照测试对象划分

7.1业务测试

7.2界面测试

• 布局排版，字体大小，粗细，是否斜体，图片是否清晰，页面的控件（按钮，滚动条，checkbox等）

7.3容错性测试

• 指的是当系统由于外界的原因发生异常时，能够自我处理，不把异常直接展示给用户，给用户一个友好提示，给用户很好的使用感受

7.4易用性

用户体验测试，符合常规使用习惯，给用户可以有多重选择

7.5舒适性

7.6实用性

7.7兼容性

7.7.1平台兼容

不同平台下是否能够使用

7.7.2数据兼容

这个平台的数据，另一个平台是否能够使用

7.7.3向前向后兼容

开发了新功能，就功能能否正常使用

7.7.4软件和其他软件兼容性

• 下载了A软件，是否还可以下载B软件
• （国家反垄断）

7.8文档测试

• 术语正确性
• 功能一致性

7.9性能测试

• 响应时间
• tps（HTTP per second）
• 吞吐量
• 系统运行时占用的系统资源的情况

7.10安全性测试

• SQL注入
• xss
• 病毒
• 黑客
• 防爬虫

7.11内存泄漏测试

• 用户分配了内存空间，但是没有回收，导致系统内存占有越来越多，严重情况下系统会崩溃

7.selenium

7.1定位元素的方式

• 1.id
• 2.name
• 3.class-name
• 4.tag-name
• 5.link-text
• 6.partial link text
• 7.xpath
• 8.css selector

7.2等待

• 固定等待：time.sleep
• 智能等待：driver.implicity-wait

7.3层级框架处理

• switch-to.frame()去到一个框架
• switch-to.default（）去到默认框架

7.4弹出框处理 alter

• 1.获得弹出框的操作句柄：switch-to.alter
• 2.关闭弹出框：alter.accept

7.5unittest框架

• 测试固件：前setUp（），后tearDown（）
• 组织测试套件的方式：
• addTest（一个一个加）
• makeSuite（一个类所有的测试方法）
• TestLoaer（一个类所有的测试方法）
• discover（一个文件夹下，某种命名规律的所有文件里面的测试方法）
• 测试方法默认的运行顺序：0-9 > A-Z > a-z
• 忽略测试用例的执行 @unittest.skip（“skipping”）
• 断言：判断预期结果和实际结果一致
• 形成http report
• 数据驱动ddt（Data Driven Testing），安装：pip install ddt，
• @ddt，@data @unpack @file-data
• 数据驱动测试方法的执行