软件测试的工具 ：
程序(最紧张测试的工具)数据(库)文档3.2 软件开拓模型常见的软件开拓模型包括 ： 瀑布模型 、V模型 、迭代模型 、敏捷模型 。
条件 ：假定要开拓一款软件 ，共包含了20个需求 。
开拓模型
开拓过程
适用公司
开拓周期
对测试哀求
瀑布模型
将所有需求完成才进入到下一个阶段，依次类推。
做项目性的小公司
2月+
功能测试或以功能测试为主。
V模型
将所有需求完成才进入到下一个阶段，依次类推。
给大型公司开拓软件的大公司
4月+
白盒测试、集成测试、功能测试、自动化测试。
迭代模型
将20个需求拆分成若个次迭代，每次只做部分功能，依次进行迭代 。
做产品的互联网企业
2周~6六周
功能测试、自动化测试、其它测试
敏捷模型
以用户故事为单位进行拆分，依次迭代
大厂
一周以内
功能测试、自动化测试、测试开拓、其它测试 。
产品 ：面向大众项目 ：面向个体3.3 软件质量模型软件测试职员的代价 ：
担保/提升/度量软件质量提升测试效率(自动化)软件质量本身是一个抽象的观点 ，须要用具体的指标去量化 。 利用了国际质量模型ISO9126去量化 。通过验证质量模型中6大特性，从而去担保软件质量 。
质量特性
测试类型
功能性
功能测试、安全测试
可靠性
可靠性测试、性能测试
易用性
易用性测试
效率
性能测试
掩护性
/
可移植性
兼容性测试、安装测试
常见的测试类型 ：
功能测试安全测试可靠性测试性能测试易用性测试兼容性测试3.4 测试观点3.4.1 按阶段划分阶段
描述
对应角色
单元测试
此阶段对软件的最小单元-模块进行精确性验证，测试工具便是代码 ，测试职员必须懂代码。
开拓职员 白盒测试职员
集成测试
将模块组装起来进行测试 ，更看重模块之间的接口 。
开拓职员 白盒测试职员 功能测试职员
系统测试
对系统的整体功能进行测试，包括功能测试、性能测试、兼容性测试、易用性测试等。
功能测试/专项测试职员
验收测试
α测试 ： 公司内部职员来完成测试 ，比如产品经理 β测试 ： 是由用户来完成的测试 。
公司内部职员/用户
3.4.2 按照是否查看源代码是否查看源代码
描述
分别阶段
黑盒测试
将测试软件算作一个玄色的盒子，测试职员不须要关注盒子的内部构造(代码的逻辑) ,只须要站在用户角度进行测试即可，通过输入不同的数据，进行比较输出结果是否精确 ，比如打算器。
系统测试
白盒测试
将测试工具算作一个透明的盒子 ，测试职员须要查见地式内部的代码逻辑 ，然后对代码进行测试
单元测试
灰盒测试
将测试工具算作一个灰色的盒子，更多的是测试程序的接口 。
集成测试。
3.4.3 按照是否运行源代码静态测试 ：对代码的语法、逻辑、规范进行的测试 ，一样平常情形下是不运行的代码，紧张场景便是代码评审(review) 。对文档进行测试 ，必须需求文档 ，用户手册等。动态测试：指运行代码的测试 ，包括黑盒测试、灰盒测试 、白盒测试等。3.4.4 按照是否自动化手工测试 ： 由人工来完成的测试 ，通过实行测试用例 ，操作软件 ，比对结果的全体过程 。自动化测试 ：是由代码去完成测试 ，通过代码驱动软件自动实行测试用例 、自动操作 、自动比较结果从而完成测试 （app自动化、web自动化 、接口自动化）3.4.5 其它测试冒烟测试 ：为了验证开拓提交给测试的软件质量是否合格 ，从已经编写好的测试用例中选取一部分具有代表性的测试用例作为冒烟测试用例 ，以验证软件是否合格 。若该部分用例实行通过 ，代表冒烟测试通过 ，反之冒烟测试不通过 。随机测试(发散测试) ：在测试时不受功能限定、测试方法限定 、测试思维的限定 ，其紧张目的是为了创造bug ，在实行测试时非常有效的测试方法 。探索式测试 ：有目的性和正对性的测试 ，强调的是一边探索、一边学习、一边验证的过程 。回归测试 ：紧张是对软件功能或已经修复的bug进行复测 ，紧张确认功能/bug被真正的修复，同时还不能引入新的问题 。3.4.6 测试观点总结4.软件测试流程紧张包含事变
所处阶段
主导角色
紧张事情
1.需求评审
需求剖析阶段的尾声
产品经理主导，其它角色参与
理解需求。
2.编写测试操持
在设计阶段的早期
测试经理主导，测试职员参与
输出测试操持并同步给团队
3.编写测试用例以及评审
全体开拓阶段
测试职员
编写测试用例，参与测试用例的评审。
4.搭建测试环境
测试阶段的早期
测试职员
支配测试须要的环境
5.实行测试
测试阶段
测试职员
对系统进行不同类型的测试 。
6.提交bug并跟踪管理
测试阶段
测试职员
提交bug并跟踪管理
7.编写测试报告
测试阶段的尾声
测试职员
输出测试报告并同步团队。
8.上线测试
上线阶段
运维角色、测试职员、开拓职员
上线事情。
解释 ：
以上的任务项中，占用最多韶光的便是设计测试用例、实行测试和创造bug。设计测试用例和创造bug还是属于比较难的 。5.环境先容5.1 环境分类开拓环境 ：开拓职员进行调试而利用的环境 。测试环境 ：测试职员进行测试利用的环境 。准生产环境(预发布环境) ：为了仿照天生环境而搭建的环境，紧张给测试职员利用 。减少由于测试环境和天生环境差异太大导致的问题。天生环境（线上***：用户利用的环境5.2 软件的构成客户端 ：app ：测试环境便是手机小程序 ： 测试环境便是微信浏览器 ：测试环境便是浏览器做事端 ：供应做事的哪一端 ，包括了依赖软件 + 被测软件 。5.3 做事端软件支配所谓的做事端软件支配，实在便是将以下的软件支配到对应的操作系统上 。由于软件的浸染不同，它的支配频度也不一样 。
被测试软件 ，会不断的支配 ，一次版本迭代可能支配多次 ；依赖软件支配只支配一次即可。
操作系统 ：紧张支配在Linux系统，
依赖软件 ：包括开拓措辞、中间件、数据库、其它软件开拓措辞 ： Java ，c, C++ ,.net ,php ,python .中间件 ：tomcat , apache数据库 ：mysql ，Oracle ，db2 .被测软件 ：便是你所在公司的产品或项目 。6.测试用例6.1 观点测试活动 ：针对软件的某个功能进行的一系列操作，包括输入、输出的一个过程，比如登录。包含要素 ：测试用例模板形成文档 ：xls , xmind , 工具(禅道)、testlink ,自研的测试用例工具 。紧张目的 ： 通过测试用例去验证软件是否符合需求 。6.2 包含要素基本项 ： 用例编号 、项目名称、模块 、用例标题、用例级别、前置条件、数据、操作步骤、预期结果扩展项 ：备注，实际结果 、优先级 。6.3 设计测试用例的流程需求剖析-提取测试点 -设计测试用例-用例评审 -修正和完善测试用例 。
6.4 测试用例的浸染验证软件功能是否知足产品需求确保需求的覆盖率 ，只管即便提高测试覆盖率 ，从而减少问题漏测 。可以衡量测试的事情量。7.测试方法常见的测试方法有 ： 等价类划分，边界值 、缺点推测法 、场景法 。
7.1 等价类划分问题 ：在测试过程中，输入是无穷尽的 ，不可能对所有的情形进行遍历到 ，以是须要将无穷的输入转化为有限的输入 。
观点 ：将所有输入划分为多少平分，从每一个平分中选取中一条或者几条具有代表性的数据作为测试用例的数据 。
利用等价类划分的关键步骤 ：
分类 ，要划分几个平分 ？ 该如何划分 ？取数 ，如何在个中一个平分中选数 。等价类干系观点 ：
有效等价类 ：操作的功能能正常完成，有效等价类设计出来的用例叫正向用例 ，简称正例。无效等价类 ：在操作功能的过程中输入的数据不符合哀求或者非常的数据 ，导致无法完成功能。紧张在于验证程序在非常数据时的表现 。无效等价类设计出来的用例叫反向用例 。简称反例。如何进行合理的分类 ？
先将功能的输入划分成有效等价类和无效等价类 。对有效等价类进行细分 ，先剖析功能的构成条件 ，从构成条件中详细的属性再一步的细分 。直到划分成原子层级。末了做用例组合 ，去掉冗余的用例和逻辑不成立的用例，终极形成了正向用例 。无效等价类 ，须要每个条件取反，终极形成了反向用例 。7.2 边界值观点 ：根据实际的履历，输入数据在边界上涌现问题的几率要远远高于边界内 。
取数原则 ：[min,max]
有效等价类 ：最小下边界 、最大上边界 、边界内取一个数 。无效等价类 ： 最小下边界-1 ，最大上边界+1 。条件条件 ： 有范围，有长度的功能 。
其它情形 ：
(min,max][min,max)(min,max)7.3 缺点推测法观点 ：紧张是基于自己的履历、直觉和自己的判断 ，来推测某个功能存在问题，从而设计出一些测试用例 。
设计测试用例的紧张思考点 ：
履历 ：输入数据 ：默认值不输入(为空)输入较长的值 。（探索测试）输入较短的值输入分外的值。输入和业务干系的数自己的判断 ：判断业务的逻辑(必须熟习业务)基于实际情形去判断7.4 场景法观点 ：站在用户角度 ，将几个功能组合起来构成用户的利用场景 ，总结为 ：功能组合 + 操作顺序 。比如购物流程。
基本流 ：考虑用户正常的操作流程，每每选取的基本流都是用户高频操作的功能 ，也便是为了达成用户的目的 。
备选流：在操作基本流的路径上涌现了缺点或者非常 ，导致结果要么直接结束流程 ，要么便是重新回到基本流 、要么便是走向其它基本流 。
对付一个别系来说，会存在很多的基本流 ，选择基本流紧张是站在用户角度去考虑。一旦确定了某条基本流，就可以考虑它的备选流了 。
案例 ：ATM取款机
1.根据需求确定出基本流和备选流
用户目的 ：取款基本流 ：插卡-输入密码-查询余额-输入金额-输入密码-取款成功。备选流 ：插入无效的卡插卡的方向是反的输入缺点的密码输入的密码次数太多，账号被锁定永劫光未输入密码，自动退卡输入的取款金额 > 账户余额输入的取款金额 > 当日限额输入的金额不符合哀求。2.将基本流和备选流进行组合 ，去掉无意义的用例 。
测试用例
覆盖流
备注
插卡-输入密码-查询余额-输入金额-输入密码-取款成功。
基本流
插入无效的卡
放在单功能中测试
插入无效的卡-重新插入精确的卡-输入密码-查询余额-输入金额-输入密码-取款成功。
基本流+备选流1
插卡的方向是反的
放在单功能中测试
插卡的方向是反的-重新插入精确的卡-输入密码-查询余额-输入金额-输入密码-取款成功。
基本流+备选流2
插卡-输入缺点的密码-输入精确的密码-查询余额-输入金额-输入密码-取款成功。
基本流+备选流3
插卡-输入缺点的密码次数太多
放在单功能测试。
插卡-永劫光未输入密码
放在单功能测试
插卡-永劫光未输入密码-插卡-输入密码-查询余额-输入金额-输入密码-取款成功。
基本流+备选流5
插卡-输入密码-查询余额-输入的取款金额 > 账户余额-重新输入金额-输入密码-取款成功
基本流+备选流6
插卡-输入密码-查询余额-输入的取款金额 > 当日限额-重新输入金额-输入密码-取款成功
基本流+备选流7
插卡-输入密码-查询余额-输入的取款不符合哀求-重新输入金额-输入密码-取款成功
基本流+备选流8
插卡-输入密码-查询余额-输入金额-输入缺点的密码-输入精确的密码-取款成功。
7.5 流程图法
它也是一种专门设计功能组合的一种测试方法，紧张依据需求中流程去设计测试用例 ，紧张为了覆盖流程图中的每一条分支。
流程的来源 ：
来至于需求来至于自己去画流程图 。7.6 测试方法总结测试方法
利用场景
特点
利用关键
等价类划分
针对单功能设计的一种方法
特殊适宜于颗粒度更细的覆盖。
1.合理的划分 2.合理的取数
边界值
针对单功能设计的一种方法
非常高效的方法 ，创造bug的几率非常高。
确定边界，确定范围
缺点推测法
针对单功能设计的一种方法
更发散、更快、更多的创造问题。
判断、履历、直觉
场景法
对用户场景设计的一种方法
设计出的测试用例，表示在实行次数比较多
用户操作目的(代价)
流程图
对用户场景设计的一种方法
设计出的测试用例，表示在实行次数比较多
须要能自己画出流程图。
8.实行测试&创造bug8.1 bug先容8.1.1 观点
所谓的软件毛病 ，成为bug ，它是指程序在运行过程中涌现的缺点或非常、导致功能不能知足用户需求/产品需求 。
8.1.2 毛病分类功能毛病页面数据显示缺点业务逻辑缺点功能未实现或实现缺点。性能毛病相应韶光太长页面崩溃/系统崩溃易用性毛病页面体验不太好利用起来太繁芜安全毛病数据被暴露权限设置兼容性毛病手机不兼容屏幕不兼容版本不兼容可靠性毛病运行韶光长报错弱网环境下报错和其它运用争用资源报错 。8.1.3 毛病包含的字段毛病包含的字段
字段描述
毛病id
系统自动创建，代表唯一性。
毛病的标题
用来描述毛病 ，紧张给开拓职员开。
毛病的状态
在测试职员操作bug过程产生的状态包括 ：新建/激活 ，打开/重新打开 ，已修复 ，已关闭
毛病的严重程度
产生毛病后，它对系统/用户/公司的影响
毛病的优先级
产生毛病后，它被修复的前后顺序
毛病的版本
此毛病发生在那个版本下
附件
供应毛病的截图、日志、视频
毛病的严重程度
一级bug ：程序崩溃、流程壅塞、核心功能不可用二级bug ： 紧张功能不可用、数据显示缺点、性能指标不达标、安全问题 。兼容性问题。三级bug ： 次要功能不可用 ，界面显示问题四级bug ： 建议优化的bug毛病的优先级
越严重的bug越被优先修正 ，它的优先级是最高的。在毛病严重程度相同的情形下，优先级越高越被优先修正 。毛病的版本：指创造的bug是在那个版本下提交的 。
毛病的状态：
1.测试职员新建bug->开拓职员/测试经理确认bug->开拓职员修正bug->4.测试职员回归bug->closed 。
状态包括 ：新建/激活 ，打开/重新打开 ，已修复 ，已关闭
如何编写毛病标题？
遵照的原则 ：完全 + 准确 +简洁提bug的公式 ：所在模块 + 操作动作 + 产生结果上传附件
至少上传一张截图 ，截图直接粘贴到文本框 ，不要以附件的形式上传 。上传截图时，只管即便将关键位置标注出来，提高识别度 。如果有日志的话，可以上传日志文件 。将操作步骤录制小视频 ，以附件的形式上传 。8.2 禅道利用8.2.1 管理员角色用户管理权限掩护创建项目流程
8.2.2 测试角色提交bug/回归bug用例管理，包括添加用例，实行用例以及转bug 。编写套件
测试单(开拓利用)编写测试报告。8.3 如何找bug方法1 ： 实行测试用例 ，通过实行测试用例验证软件的实际结果和预期结果是否同等，若同等实行通过，若不一致，则为bug。方法2 ： 随机测试(发散测试) ，通过你对功能的理解熟习 ，进行发散测试该功能，从而创造bug。9.需求评审9.1 什么是需求评审
产品经理将已经设计好的需求文档(PRD)在需求评审会上同步给团队成员 ，使团队成员能理解需求 ，以便后续更好的开展事情 。
9.2 参与角色开拓职员前端开拓后端开拓UI职员测试职员项目经理9.3 需求评审的目的确保参会职员对需求都理解同等 ，对需求的准确性和完全性进行确认 。哀求干系团队给出排期 ，包括开拓周期、测试周期、UI周期。10.测试操持10.1 测试操持的目的高指定性 ，减少由于短缺考虑或考虑不清楚而导致的漏测 。合理的安排测试资源(人力资源、韶光资源、环境资源) ，从而减少测试摧残浪费蹂躏 。10.2 测试操持包含要素测试目标 ：要达成若何的质量目标 ，会将质量目标进行量化 。测试范围(what) : 我们要测试什么 ？ 本次迭代新增了那些功能 ？ 影响了那些功能 ？ 要进行若何的测试类型 ？测试策略(How) : 我们要如何进行测试 ？在本次迭代的韶光内 ，如何安排测试资源 ？须要进行几轮测试 ？利用什么样的方法 ？测试资源(who) : 是由谁来测试 ？ 花费多永劫光 ，以及利用到的测试环境 、测试数据 、测试工具等 。测试标准 ：在测试过程中，须要统一测试标准 ，比如准入准出标准 、设计测试用例的标准 。测试类型的标准 。测试风险和应对方法 ： 在测试过程中可能碰着的风险 ？ 比如需求变更 、开拓提测不通过 。10.2.1 测试目标确定每次迭代测试的质量目标，通过详细的指标进行量化 ，从而确定测试的完成指标 。
bug关闭率 ： >=97% , bug关闭率 = bug回归后关闭的数量/总bug数量测试用例通过率 >=98% , 测试用例通过率 = 测试用例终极实行通过的数量/总用例数在回归测试期间不要涌现严重bug : >=2级bug 。备注 ： 每家公司指标是不同的 ，指标值也不相同 。
10.2.2 测试范围每次小的迭代要进行测试的范围 ，须要明确出测试什么 ？ 不测试什么 ？
功能测试当前迭代新增或修正的功能，须要重点考虑 。新增或修正对原有功能的影响 。核心的功能和流程进行回归测试非功能测试根据详细的实际情形去剖析 。10.2.3 测试策略浸染 ：在明确该怎么测试 ？
阶段
紧张事变
韶光
职员
方法
目标
1.需求剖析及业务熟习
测试职员
准备阶段
2.编写测试操持
1天
测试经理/测试组长
3.设计测试用例
7天
测试职员
4.用例评审/用例修正
1天
测试职员
实行阶段
5.搭建测试环境
0.5天
张三
第一轮测试
4天
全员
1.冒烟测试 2.实行测试用例
目标1：所有用例实行完毕 目标2：bug回归率>=60%
第二轮测试
3天
全员
发散测试/探索式测试/交叉测试/数据测试/测试类型
目标1：用例通过率超过90% 目标2：bug回归率：>=90%
第三轮测试
1天
全员
回归测试 编写测试报告
bug关闭率 ： >=97% 测试用例通过率 >=98% 在回归测试期间不要涌现严重bug
10.2.4 测试标准准入准出标准 ：准入标准 ： 通过冒烟测试用例去衡量 ，若冒烟测试全部通过 ，代表准入通过 ；反之，准入失落败 。针对失落败的情形 ： 要么选择打回 ，要么选择连续测试，但是发告警邮件 。准出标准 ： 便是对应的测试指标测试用例标准 ：确定测试用例的工具 ，比如统一利用禅道确定测试用例的编写形式 ：测试用例标题 、步骤 、级别 。测试用例的覆盖点 ：覆盖流程 + 覆盖功能 + 覆盖其它类型 。确定bug的标准 ：bug标题 、bug级别 、bug类型 。确定测试类型的标准 ：兼容性测试 ：浏览器兼容性 ：可以选择市情上top3的浏览器进行测试 。app兼容性测试 ：小版本测试可以利用公司内部测试机 ；大版本测试可以利用云测做事 。易用性测试 ：页面元素布局 、元素之间的间距 、字体大小、颜色等。10.2.5 测试风险及应对方法可能涌现的风险
应对方法
需求变更
1.在测试后期进行需求冻结 2.在评估测试周期时，只管即便预留一些冗余韶光 3.加班 4.调度测试策略/降落测试标准
开拓提测不符合准入标准
1.条件把冒烟测试用例发给开拓，并解释不通过后会承担的后果 2.记录不通过的次数和缘故原由，可以把数据反馈给开拓老大
韶光不足
1.加班 2.加人 3.调策略
11.测试报告11.1观点紧张是供应测试结论、测试过程以及测试剖析的一份文档，为后续产品质量供应参考依据 。一旦输出测试报告，就意味着测试阶段的结束 。
11.2 对团队的意义报告 ： 将测试结果和测试质量 、测试剖析等数据以文档的形式奉告团队把关 ： 将测试目标和实际进行比对 ，以确保测试目标是完成的。改进 ：对全体研发过程中涌现的问题 ，进行剖析后提出改进建议，以推动团队能进行实行 。预防 ： 利用对应的办理方案 ，同时办理方案能看到效果，起到了后续预防浸染 。11.3 测试报告的编写编写测试报告肯定是测试职员，一个版本只写一份 ，由某一位测试职员去编写 。测试报告一样平常都会有模板 ，你只须要按照模板去填写数据就可以了。11.4 测试报告包含要素测试结论 ：一样平常情形下便是测试通过或测试终止 。测试依据 ：给出测试通过的准出标准测试过程的回顾 ：测试准备阶段的回顾 、测试实行阶段的回顾bug统计剖析 ： 按照不同维度去剖析 ，bug关闭率 ，bug激活率、bug有效率、bug按照类型分布 、bug级别 。问题和建议 ： 在剖析测试过程中创造的问题 ，去找对应的办理方案并形成建议 。12.设计测试用例的框架场景 ： 在事情中碰着所测试的模块功能非常多或者直接测试一个别系 。
办理思路 ：设计测试用例框架
详细步骤 ：
先去考虑功能测试 ，从两个维度去考虑 ，分别是用户场景和覆盖功能 。针对用户场景 ，多数会在需求中表示 ，将这些用户流程转化为测试用例(流程图) 。有的主要的场景你可以利用场景法设计测试 。针对功能覆盖 ，确保每个功能都能被覆盖到 ，针对每个功能进行设计测试用例 。详细到每个功能然后再利用等价类、边界值、缺点推测法末了在去考虑其他测试类型 ，紧张包括性能测试、易用性测试、兼容性测试。
