软件测试复习整理
Posted 羊羊羊yyy
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件测试复习整理相关的知识，希望对你有一定的参考价值。
软件测试复习整理
！ 仅供参考！有错误的地方请指出，我会及时修改！感谢！！！
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
- 数据驱动测试方法的执行
以上是关于软件测试复习整理的主要内容，如果未能解决你的问题，请参考以下文章