导图社区 测试基础
- 116
- 8
- 1
- 举报
测试基础
测试基础思维导图：包含一、测试相关概念，市场需求调研、可行性研究、项目立项、需求调研开发、设计开发测试、发布运行维护。，项目经理：负责整个项目的成败，大多数时间都在沟通。等等
编辑于2022-05-10 16:14:47- 测试基础
- 相似推荐
- 大纲
测试基础
一、测试相关概念
1、名词解释
1、1软件1.1一系列按照特定顺序组织的计算机数据和指令的集合，程序+数据+文件。
1.2 IT（information technology）：字面上的意思就是信息技术，主要包括：现在计算机、网络通讯等信息领域技术，属于白领。关键词：IT男、IT民工。
1.3产品（product）：能够提供给市场，被人们使用和消费，并能满足人们某种需求的东西，包括有形的物品、无形的服务、组织、观念或它们的组合。关键字：需求，有需要才产生产品。
1.4项目（project）:指一系列独特的、复杂的、并相互关联的活动，这些活动有着一个明确的目的/目标，必须在特定的时间、预算、资源限定内，依据规范完成。
2、软件公司类型
2.1自研公司：公司自己内部的研发团队和测试团队、开发自己的产品，公司还负责运营，比如腾讯、阿里、京东。
2.2外包公司： 项目外包：只负责做项目、也叫半外包，技术团队不需要到客户现场，有自己的办公室，完成产品，然后交付，甲方自己运营。 人力外包：客户提供办公场所、技术团队到客户现场办公，然后完成产品交付给客户，顾名思义，只提供人力，走金融/银行这方面的人力外包比较多。
2.3两者对比：其实有很多的自营公司，也会把自己的部分业务外包出去，为的就是更省钱省力，只要能更高效、性价比更高完成项目，至于什么样的形式是可以挑选的。
3.什么是软件测试？
软件测试：首先我们从字面上的意思来理解，软件：前面我们已经定义了。测试：检查、实验、检验。总的来说，软件测试就是，站在用户的角度，根据用户的需求，验证产品的功能是否和客户的预期一致。
参考文档：需求规格说明说/需求文档/SRS/产品原型/产品原型设计书，指的都是差不多的，参考的标准，没有标准，就无法知道用户想要的结果。
调试：程序确保它能完成的功能 测试：解决程序应该具备的功能
4、软件测试的发展史
1983，IEEE提出的软件工程标准术语，软件测试定义如下：“使 用人工和自动手段来运行或测试某个系统的过程，其目的在于检 验它是否满足规定的需求或是弄清预期结果与实际结果之间的差 别” 。 迄今为止，软件测试的发展一共经历了五个重要时期 • 1957年之前－调试为主(Debugging Oriented) • 1957–1978－证明为主(Demonstration Oriented) • 1979–1982－破坏为主(Destruction Oriented) • 1983–1987－评估为主(Evaluation Oriented) • 1988–至今－预防为主(Prevention Oriented)。
5.为什么要做软件测试
1、为了发现产品的缺陷/bug：就是产品实现的功能和客户预期的需求差异。
2、尽早发现：越早发现问题，维护成本约低。
3、提高产品的满意度，扩大市场占有率，维护公司的形象，提高公司的收益。
4、为我们的决策者提供解决方案，更全面的对整个产品进行评估。
5、总结项目经验，为后续相关产品提供帮助/参考。 总结：当前的软件环境，非常注重使用体验感。比如，一款产品缺陷很多，一款体验很好，那么作为用户来说，我肯定会选择后者。那么好的体验感靠谁来把控呢？测试工程师---质量保障。
6.软件测试工程师需要具备的能力？
耐心和责任心：工作态度，因为只有有耐心和责任心，才能发现更多的缺陷，才能更好的处理问题。
良好的沟通能力：和团队成员之间的沟通能力，特别是和开发工程师的沟通能力，只有和开发之间沟通良好，才能提高团队的效率。
对产品要有怀疑能力：没有完美的产品，我们测试就是为了验证缺陷的存在。
输出测试相关的文档，比如测试数据、测试文件。
对照需求文档进行测试，不要跟着开发的思路走。 加强需求的理解和技术能力的学习，特别，和开发沟通的技术问题，不要反复去问。 测试技术的加持：比如测试基础理论、数据库、linux、性能测试、自动化测试等等。
7.怎么理解测试和开发之间的关系？
开发的工作是建设性和创造性的，我们测试的工作是破坏性的。但是开发和测试的目的都是一样的，为了产品更好的匹配用户的需求。关键词：目的。
测试和开发是相互协调的，没有不可调和的矛盾，测试工程师协助开发定位问题，开发进行修改/解决，就是一种协调的关系。
同理，产品也是具有同样的目的的，产品是软件的设计者，开发是软件的实践者，测试是软件的质量把控者。
二、软件项目周期
市场需求调研、可行性研究、项目立项、需求调研开发、设计开发测试、发布运行维护。
市场需求调研：需求调研人员输出-需求调研报告，市场一部分群体。
可行性研究：研究项目能不能赚钱、实现经济效益；技术上的可行性，产品的可行性研究。
项目立项：项目经理开会立项，项目经理输出项目计划。
项目计划主要包括：项目的时间节点、概要设计、测试设计、第一个版本提交的时间、什么时候去做第一轮测试，直至完成。
需求调研开发：产品经理输出需求文档，进行需求评审，确定相对稳定的需求，然后同步给开发和测试。
设计开发测试： 开发拿到需求文档，进行概要设计和详细设计，进行编码，根据项目计划完成，并及时修改缺陷。
测试拿到需求文档，整理需求，梳理测试内容，提取测试要点，编写测试用例，评审用例，待提测第一个版本，根据测试用例进行测试，提交缺陷，开发修复之后再次验证，输出测试报告。
发布运行维护：产品发布上线或者进行验收测试，交付产品，产品上线以后需要进行线上测试。
针对线上缺陷或者客户提出的优化需求，开发修复或者开发设计优化之后，然后我们测试工程师协助验证后再上线。
三、项目成员的介绍
项目经理：负责整个项目的成败，大多数时间都在沟通。
产品经理：输出需求文档，协调开发和测试需求同步，同时要了解客户的实时需求。 一般的话，现在的公司，两者之间只取其一，通常银行金融项目一般叫项目经理，互联网项目一般叫产品经理，也不是绝对的，根据公司/项目的具体情况而来。
开发经理/总监、开发组长、开发工程师：开发经理分配开发任务，监控整个开发的进度，以及开发的质量；开发组长和开发工程师进行代码编写，保质保量完成工作。
美工/UI：产品的页面设计、以及页面的优化调整，关键：PS。
前端开发工程师：界面的逻辑开发。
后端开发工程师：处理和响应界面传过来的请求，以及后台的自身逻辑。
测试总监/经理、测试组长、测试工程师：测试经理分配测试任务，监督工作进度以及测试工作的质量；测试组长和测试工程师梳理需求，编写测试用例，执行测试，提交缺陷报告，验证缺陷，输出测试相关文档。
运维工程师：负责产品上线，监控测试环境和线上环境，主要是部署和维护环境。
技术支持工程师/客服：主要就是对接线上客户反馈的问题，进行解答，反馈给产品经理。 注意：在有些中小型的公司里面，有些职位的划分没有那么的明确，例如：产品经理和项目经理工作职责合二为一，测试和运维/技术支持常会有工作的交集。
四、测试的基本原则
1.测试对象
软件：开发工程师编写的代码或者我们操作的产品。 数据： a.基础数据：产品上线有具备的基本数据，比如说菜单数据、管理员数据。 b.业务数据：在进行产品业务流程的时候，产生的数据。 c.配置数据：banner图等。 文档：产品生命周期内产生的所有文档，最常见的就是帮助文档、操作手册。
2.测试原则
测试是上下文关联的：测试是根据我们测试的产品变化而变化的，不是一成不变的。 穷尽测试是不可能的：我们要对一个产品进行完美无缺的测试是不可能的，只能在有限的成本/时间/人力/物力下，尽可能多的发现问题。 测试要尽早介入：项目一开始就要介入，这样提前熟悉产品，发现的问题就会越多，后期修复的成本就会越少。需求评审开始就参与，原型定稿之后就开始编写测试计划和测试用例。 杀虫剂悖论：在软件测试里面用来描述这样一种现象，对软件进行越多的测试，那么该软件对当前测试人员的测试就越具有免疫力。如果我们一直使用同一种方法，或者同一个人测试，就会发现比较少的缺陷，所以，我们需要不同的方法测试，以及不同的人员进行交叉测试。 缺陷群集性：二八定律，产品中20%的功能模块，会产生整个项目80%的缺陷，所以安排测试人员我们要合理分配模块，保证时间和人力。第一，开发人员的水平有高又低，不同的功能模块有难有易，因此需要合理分配人员。 测试是证明缺陷的存在：测试是证明产品存在缺陷的，而不是证明产品是没有缺陷的。 无错谬论：不是说没有缺陷的产品就是好产品。首先，完美的产品只存在于理论之中。其次，就算是完美，但前提是满足客户的需求，就算再完美，客户说不好，也没有用。 补充：及时更新自己的用例，加强业务和技术的学习，不断更新、不断学习、不断成长。
五、常见的开发模型
1.边做边改型
缺少整体的规划、越做越乱、导致最后产品无法修改
没有需求，这样的产品风险很大
产品关联文档缺乏，后期维护困难
其实这种模型，相当于没有模型，走一步算一步，比较混乱，常见于一些小型公司，由于内部人员较少，没有办法形成体系，为了节约人力成本呢，为了赶时间，而舍弃了部分质量。
2.瀑布型
阶段比较明确，一个阶段完成以后进入到下一个阶段，没有体现测试尽早介入的情况，有一定的风险。
常见于一些比较大型的项目，公司有成熟的软件团队，有充足的时间情况下，以前有项目/公司使用这种模型。
3.敏捷型
能够快速的迭代，满足用户的迫切需求，测试和开发充分参与到需求讨论中，提高工作效率和降低需求风险，测试也能够尽早介入项目，更早发现问题提高产品成功率。
六、常见测试模型
1.V模型 是开发瀑布模型的变种，非常清楚的描述了测试各个阶段和开发过程各个阶段之间的对应关系，的所有的测试阶段都包含，但是没有体现测试尽早介入产品的过程。
2.W模型 避免了V模型中测试没有尽早介入的问题，只要有需求文档输出，就能介入测试，但是没有办法支持迭代和变更。
3.H模型 总结：时刻进入测试状态，更早的进行测试准备工作，并且测试贯穿到整个产品的生命周期，但是对测试人员的要求较高，不光是对测试工程师是的技能要求高，也对测试管理的要求高，并且迭代的内容不能太多，要求项目的规范比较多。 这个模型是我们以后用到的主要模型。
4.X模型 针对功能模块的模型，开发和测试进行分离，当前这个模型属于探索阶段，需要经验丰富的测试工程师才能进行探索性测试。
5.前置模型 是一个将测试和开发紧密集合的模型，它分别吸取了V模型和X模型的精华，并试图弥补它们的不足，该模型可以使项目加快速度，以后我们的工作中基本不会接触，仅作为了解。
七、软件测试的阶段 名词解释：软件测试的阶段：即是在不同的阶段按照不同的测试级别进行测试。
1.需求测试
测试对象：需求文档---产品经理输出的
检查需求文档上面的错误，检查需求文档是否完整，前后是否有矛盾，需求描述是否有歧义和模糊的地方。
注意：测试工程师，一定要把需求理解透彻，如果需求有问题没有被察觉，后面返工的成本就比较大，我们测试工程师一般不会直接面对客户，不懂得地方要多问！
2.单元测试
单元测试就是测试代码里面的类和函数，一般由开发自己完成，也有测试来进行单元测试的，但是对测试人员的代码能力要求较高，一般的公司不会叫测试去做单元测试。
测试中的最小颗粒度。
参考文档：详细设计说明书
3.集成测试
其实就是模块和模块之间的接口测试，开发或者是测试进行
参考文档：接口文档/概要说明书
4.系统测试
针对整个系统进行测试，不单单包含软件部分，应该包含关联的外部组成部分，主要是测试工程师完成。
主要包括：功能测试、自动化测试、性能测试
参考文档：需求说明书/需求文档/产品原型（蓝湖）
5.确认测试
查看产品是否合格，是否最终满足客户的需求，测试工程师进行
参考文档：需求说明书/需求文档/产品原型。
6.验收测试/UAT（user acceptance test）测试
一般客户会参与，验收测试是验证系统是否符合客户的要求，客户和测试工程师同步进行
参考文档：需求文档/项目合同/验收计划等等
包含α测试（对内）和β测试（对外），也就是内测和公测的意思，游戏里面常常涉及到这两个概念。
7.回归测试
缺陷修复以后，再次进行验证的测试，测试工程师进行。
回归测试是贯穿整个产品的生命周期的，任何一个阶段都会有回归测试。
目的：验证当前的缺陷是否修复，以及查看相关功能是否受到影响（是否有新的缺陷导入），由于模块与模块之间是有关联的，改动一个地方，也许会影响之前已经测试通过的功能。
回归测试的方法
完全重复测试/全量重复测试：不管改到哪里的功能，都把所有的模块/整个系统来重新测试一变，这种方式安全性最高，但是花费的时间/人力太大。
选择性重复测试：
1.哪里修改就验证哪个地方
2.验证被修改的地方，以及相关联的模块/功能，这是工作中的常用方法
3.提前设置一个指标（比如产品功能的百分比、主体功能、主流程）
◆项目做几轮测试
通常会进行2~3轮测试
第一轮：对整个系统进行测试，对自己负责的模块进行的一个测试。
第二轮：针对第一轮发现的缺陷，进行修复后的回归测试，以及和其他同事的交叉测试。
这个是不确定的，但是至少都有两轮测试。如果时间比较充裕，还会进行第三轮测试，在上线之前会进行确认测试，相当于再做一遍自己模块的系统测试。当然，如果时间还很充裕的情况下，可能进行4、5轮测试。
子主题
八、软件测试类型
1. 功能测试
验证软件的功能是否满足客户的需求，我们参照的标准就是需求文档，这是我们最基础的一个测试。
主要关注哪些方面：
1、产品的功能是否实现，并且是否和需求一致。
2、功能有没有遗漏或者没有实现的。
需求文档里面有这个功能，开发没有实现。
需求文档里面没有这个功能，但是客户要求实现
3、客户没有要求的隐性要求
2.界面/UI/GUI测试
针对产品的页面是否满足客户的需求，或者通用的审美要求进行的测试
一般和功能测试同步进行，在进行功能测试的时候也验证了界面
主要验证哪些方面：
1、关注页面的排版是否正确。
2、有没有错别字
3、界面的风格是否统一、按钮的样式是否一致
4、主菜单和子菜单文案是否对应。
界面/UI自动化工具：QTP（收费的）、python+selenium、java+ selenium
界面测试的对象：单一界面元素、组合的界面元素、完整的界面。
3.易用性测试
就是看产品是否好用、是不是简单易学、易于操作、是不是符合大众的使用习惯
一般和功能测试同步进行，验证功能的时候，就把易用性参考进去。
主要关注哪些方面：
1、过分复杂的功能和指令
2、困难的安装过程
3、错误的提示或者提示太简单，甚至没有提示
4、让用户在操作的过程中记录太多的东西
4.安装卸载测试
安装和卸载测试需要注意的事项：
1、验证安装和卸载流程中的错误
2、检查安装或者卸载文档/手册中的错误
移动端安装测试点：
1、首次安装
2、卸载应用，再次安装
3、新的版本覆盖旧的版本（更新）
4、账号登录中的覆盖安装，查看是否需要重新登录
5、安装成功以后，应用是否能成功打开
6、打开应用，拒绝其中一项权限申请，应用是否可用
7、打开应用，拒绝其中所有的权限申请，应用是否可用
8、强制更新时，取消更新后，应用是否成功下载
9、非强制更新时，取消更新后，应用是否可以正常使用
10、非强制更新时，旧版本应用是否可用
移动端卸载测试点：
1、是否能够卸载成功
2、应用的数据缓存是否随着应用卸载而一起清空
5.兼容性测试
主要时看功能和页面是否能在各个浏览器或者平台上正常显示和运行。
浏览器：IE/edge、谷歌、火狐、360、QQ浏览器、UC
IE容易出现兼容性问题
移动端：
不同的手机品牌、不同的操作系统、不同的系统版本、不同的手机屏幕大小（页面自适应）
补充：向上兼容和向下兼容。
6.性能测试 关注产品的一些能够量化的特定指标，达到综合评估和分析当前产品的瓶颈。 主要指标：
外部常见指标
1、吞吐量：每秒系统能够处理的请求数、任务数
2、响应时间：就是处理一个请求或者任务的耗时
3、错误率：处理一批请求/任务中错误所占比例
内部常见指标
1、服务器的CPU
2、服务器的内存
3、整个产品运行的网络
4、服务器的磁盘读写（I/O）
负载测试：
超过正常的业务量或者正常的指定值，不断增加业务量或者指定值，查看当前系统最大的承受业务量和指定值时多少
拐点：
出现异常的指标开始
压力测试：
在业务量或者系统某一资源饱和的状态下，查看系统业务的处理情况
注意：在极限的情况下，处理业务能力变慢，但是不会出错，不会出现崩溃的情况
通常的规则：最大负载能力的120%，持续时间一般30分钟
容量测试：
系统能够承受最大数据容量，但是前提时系统能正常处理，不会出现异常情况
稳定性测试：
在一定负载的情况下，长期运行系统，看是否稳定
一定负责：80%左右
长期：1-3天
性能测试工具：loadrunner（收费的）、jmeter（接口性能比较多）
7.安全性测试 查看产品的内部机制是否能够有效抵挡外界的入侵 安全性不单单只是测试软件测安全性，还会涉及到网络的安全性，数据库的安全性，物理设备的安全性
我们测试工程师需要做的安全测试内容：
1、密码的错误校验
密码的有效性
密码的错误限制
2、密码的脱敏展示
3、验证码发送的次数限制
4、权限的问题
相关岗位：渗透工程师---渗透测试
8.接口测试
接口测试是在网络环境下和其他设备对接，进行系统功能、性能和指标方面的测试，保证设备对接正常。
9.自动化测试
使用一种编程语言，在某个框架下自动去完成检测的一种测试
用工具/代码代替人去执行测试
自动化测试的局限性：
1、自动化测试本身也是功能测试，只是提高效率，不能发现新的缺陷
2、自动化维护成本高，需求变动，改动就比较大
3、对测试人员要求相对较高，必须熟悉一门编程语言
自动化应用：
自动化更多用于回归测试，提高测试下利率
用于第一版冒烟测试
10.文档测试
文档测试：查看用户使用手册或者操作说明书是不是能正确去按照流程进行
11．异常测试
异常测试：通过人工或者系统自动干预进行的一些非正常的测试
比如：多开、同账号同时操作同一业务、断网、拔电、常见于app测试。
九、软件测试方法
1.黑盒测试
黑盒测试就是把产品当成一个黑色的盒子，部门不需要关心它的内部实现，只需要关心它的外在表现，站在用户的角度去看产品需求，验证它的功能是否满足预期
通常情况下，黑盒测试又被称作功能测试
参考文档：需求文、原型图、产品原型、需求说明书
一般是由测试工程师来进行
2.白盒测试
关注被测试对象的内部结构，测试产品的源代码，或者类和函数。
参考文档：详细设计说明书
一般由开发工程师来完成
3.灰盒测试
介于黑盒测试和白盒测试之间
包含一部分功能测试和一部分白盒测试的内容
典型的例子：测试中借助产品的日志定位问题
4.静态测试
产品不需要运行起来的一种测试
通常测试内容：详细设计说明书检查、代码走查、UI走查
5.动态测试
在产品运行中，对产品进行测试
通常的测试内容：内容覆盖情况、判断检查、功能测试
6.人工测试
测试活动是直接通过人工来完成的，这是最基本的测试形式
7.自动化测试
通过工具或者代码进行测试
自动化测试：接口自动化测试、WEB/UI自动化测试
十、软件测试流程
产品经理召开需求评审会--->参与需求评审会--->针对项目情况，提出自己的合理建议
测试组长编写测试计划、分配测试任务--->测试工程师根据分配的内容/任务、阅读和梳理需求，整理测试内容，编写测试用例，组织用例评审
执行测试之前，首先需要进行冒烟测试，冒烟测试通过再进行系统测试，如果没有通过就打回去，叫开发修改，直到冒烟测试通过为止
组长监控组员的执行情况，跟踪测试进度--->测试工程师执行测试，反馈每天执行情况，保证进度
组长查看提交的缺陷情况，分析整个产品的缺陷分布--->测试工程师按照需求文档，针对发现的缺陷进行提交，协助开发定位问题，在缺陷修复完毕以后，再次进行验证
注意：两次以上还没有修改完毕，就当面和开发沟通，详细了解对方对缺陷的理解，不能完全理解的内容找产品经理沟通
组长汇总测试结果，输出测试报告，组织评审测试报告--->测试工程师提交负责模块的测试结果，协助组长完成测试报告，参与测试报告评审/项目总结，总结测试过程中的经验和教训
运维把产品部署上线--->测试工程师线上测试，对比测试环境和线上环境的差异，在客户使用之前最后一次验证
十一、质量特性
1.界面方面
1、查看界面是否对其，排版是否正常
2、如果有链接，能正常访问
2.易用性方面
1、tab键是否支持光标切换
2、输入用户名密码，是否支持enter键登录
3、是否支持多设备登录
3.安全方面
1、密码暗文显示
2、密码错误次数限制、锁定账号、以及是否能正常解锁
4.兼容方面
1、主流浏览器：IE（edge）、火狐、谷歌、360、QQ浏览器
2、手机端：UC、QQ
3、手机端还要考虑品牌、手机型号、操作系统以及版本、屏幕大小
5.性能方面
1、同时支持多少人登录
2、登录花费多少时间
6.特性面试实例
一个水杯如何测试？
功能方面：水杯是否漏水、如果是保温杯是否保温
外观/界面方面：是否满足大众（自己）的审美、是否吸引人
易用性方面：水杯是不是便于携带、是否防烫、是否有利于清洗
安全性方面：材质是否有毒、是否易碎、杯口是否会划伤嘴巴
兼容性方面：出了装水，能否装其他的液体
性能方面：我能够装多少的水，保温能保多久
文档方面：操作手册是否容易理解、保养手册