软件测试
2025-03-26 22:53:57 0 举报AI智能生成
软件测试
作者其他创作
大纲/内容
测试用例的写作与规范
企业现状
具备测试用例编写能力
公司研发流程不规范
没有用例，直接测试
需要用例，但是没有相关文档，不方便编写用例
后期接入项目团队，需要在短时间内上线
上线之后，遇到的紧急的用户问题，需要短时间修复
解决方案
不推荐不写测试用例，因为有弊端，而且测试用例就是拿来指导测试执行的
checklist表，做校验，相当于简易的测试用例（针对测试点的校验）；
可对checklist做改善，测试输入、预期结果、操作步奏加在checklist里面，时间不够一般用checklist
以软件测文档
操作软件+用户手册
28原则（80%的用户只会用到20%功能模块），（不能一上来就测，要分析checklist，做分解，看由哪些模块组成，
然后对模块进行分级，分为核心模块，基本模块，辅助模块，然后再依据28原则来操作软件，用户手册）
测试点，记录下来，边测试边补充完善测试用例
以文档测软件
上线
上线时间：午夜
3*24小时，项目组（如果遇到问题都会在短时间内解决，用于遇到问题，
就会在自己的环境中确认问题，然后修改问题，再进行测试，再发布上线）
依据经验+相关模块用例的分析+开发，测试完成后，补充用例
非用例发现的bug（维护、更新用例）
没有用例或记录来与之对应，用例一般都涵盖不全；
非用例发现的bug，这个是很正常的现象，但是要控制比例
在项目后期（间歇期），在空闲时间就要去维护更新测试用例
用例发现bug
有用例来与之对应的bug
测试用例架构(组成)，按照架构编写测试用例
不规范
规范
用例标题
用例编号
输入数据
操作步奏
前置条件
预期结果
执行结果
作者
执行人
测试时间
测试思路
测试点
平台
环境
版本
优先级
测试项
测试子项
用例元素
基本元素
标题
一般建议不超过20个字
不能重复
可以适当的在标题里面加上一些预期结果，可避免重复
可以适当加入结果和操作步奏
让执行人通过标题，知道用例是干嘛的
预期结果
UI的结果
数据库的结果
模块与模块之间有交互，还要写出相关交互的结果
涉及到日期差看的结果，还要查看日志log
预置条件
在做某一个操作步奏之前，需要达到什么要求
优先级
进度、时间紧、任务重
是不是所有的用例都需要执行？
先执行哪些？后执行哪些？
标识符：非常高、高、中、低，1,2,3,4
扩展元素
用例编号
编写规则
编号的作用
通过编号和测试项可以分配工作、分配模块，方便管理
用例可以覆盖需求，根据编号也可以建立和用户需求的追踪表，编号可以和需求建立追踪；
根据编号可以发现用例缺陷，在缺陷单中写出用例编号，
通过编号找到测试用例方便做回归测试。编号可以和缺陷建立追踪；
测试完成后，测试报告可以依据编号统计，找到相应的数据。
编写规则
借鉴测试阶段，UI,IT,ST
借鉴产品或者项目的名称
不同的测试项给不同的编号
如果是几百条从001开始，几十条从01开始
操作步骤
操作：怎么操作
在每一步中都体现出是如何操作的
不清晰？
测试项（测试项目）
测试项就是模块
一级测试自相
二级测试子项
三级测试子项
输入数据
需求+数据设计
这个元素可有可无
用例评审
测试计划与分析
计划
表格：更多的：模块级的任务量的划分、进度的管理、人员的安排，资源的配置（不怎么关心）
粗粒度
细粒度
测试规范：用邮件方式（文档方式）告诉整个团队，涉及到不同团队的：规范，需要和不同团队达成一致，大家都遵守（如：转测试规范，缺陷管理规范），形成管理约束方
如：测试范围、进度规划、完成标志，不建议放在表格当中
测试范围，进度规划，不建议放在表格当中
邮件让团队知道
文档，存档
备注：相当于文档中：异常或风险事项
如：人力不够，需求不明确，进度延迟
及时在工作日报中，列出备注，发送邮件
分析&设计
分析：需求分析
需求分类
用户需求
产品需求
硬件
软件+硬件结合
软件或者平台，医疗行业设备等
软件需求
功能需求
性能需求
其他：安全需求
数据库需求
复用
竞争对手、类似产品
基线库（配置库）：相似经验
需求变更
紧急：口头、电话会议、远程邮件记录
自己整理形成：记录存档；（需求优先级）
没有需求怎么测试？
从执行层面：增删改查来测，业务流程
需求来源
需求规格说明书
UI界面原型
概设、祥设、系统产品设计，数据库设计（领域模型）
业务流程
可测性分析
可视、可见性
UI层
数据层
数据库
中间的处理程序
日志记录
被测软件：状态，当前输入当前输出：验证被测软件是符合要求的
可操作性
简单性
测试成本可控
挖掘隐式需求
隐含：理解一致
需要对用户数据定期进行备份
需求模块与测试需求模块，大部分都是一致的
提取测试需求，分析测试需求，提出被测对象
测试设计
过程
过程的体现：用草稿纸的方式，如A4纸
电子工具
脑海
测试方案
被测对象
解决：怎么测试，测试思路是怎样的
顶层设计（测试类型）
ST测试类型
交互性
各个模块之间是否有交互，相互影响
相互影响到的点或者说模块，要明确
测试任务的划分，测试数据的构造，测试流程的先后
继承性
工作量分配
可测性分析
分解分配
大化小，分解之后的并集，一定要和原始需求一致
模块级、子系统级，产品级，系统级
测试点
测试项~测试点~测试用例
测试用例设计
测试点
测试用例
用1条或者多条测试用例，覆盖测试点
测试数据设计
测试用例的不同就是测试数据的不同
实现&执行
用例实现
用例执行
测试方法
判定表
定义
最严格 、最具逻辑性：
把复杂的逻辑关系和多条件组合情况 ，
表达的比较明确
实质： 把输入中所有可能的情况进行组合，
并汇总所对应的操作结果。
各种组合类型的全值组合。
需求
手机是否通讯
是否欠费
是否停机
是否通讯
酒店住宿系统
支持：提前预订 和 会员卡办理 ；
如果房间提前预订，并且已支付定金；
或 持有酒店会员卡；
可以优先办理酒店房间入住
下一天函数：要求输入年月日，
系统显示当前输入的下一天
解答
列出：所有的条件桩 和 动作桩（条件项，动作项）
计算规则的个数
填充 条件项 和 动作项 到判定表
合并\化简规则（业务处理来的）
合并规则
两条或两条以上规则有相同的操作，
且条件项之间存在较为类似的关系，
需要进行规则的合并，用—代替
不推荐合并：在数据逻辑上是可以的，
在业务逻辑上不确定。
优缺点
优点：
充分考虑输入条件间的组合，
对组合情况，覆盖充分；
把复杂的问题按各种可能的情况一一列举出来，
进行全部罗列
简明易于理解
每个用例覆盖多种输入情况，
有利于提高测试效率
对输入条件间的约束关系做了考虑，
避免了无效用例
缺点
输入较多时，判定表规模非常大
合并有可能存在着漏测的风险
是一个全值组合；会产生冗余用例
不能表达重复执行的动作
适用范围
输入输出比较多，
输入之间和输出之间相互制约的条件比较多的情况 。
测试流程
用例设计
随机测试、任意测试
发散测试
无方法、无规则、随意
覆盖不充分，完全
穷举测试
完备的测试是不可能的
时间成本
不可能做到全部
目的：
输出：测试用例，指导执行（在第一轮的时候，有多少用例就要执行多少条，就需要经过评审，确定有效的）
人：进度、成本、质量===工作量
尽可能设计少的测试用例，达到对需求的充分覆盖
目标
用例生成过程中，没用到任何方法
套方法，理解有限
用例生成过程中，灵活运用，任何方法都可以，达到（红色）目的
方法
状态转换
N-switch
多用于电商
修改
流程分析（场景法）
主要是来测流程的
基于个人经验
错误推测
新增、删除、修改、查询
输入输出
等价类
等价是什么意思？
输入
不同的子集（类）；任意值（代表值）；
输出
达到同样的效果输出
证实（达到需求规格里的功能要求）
证伪（发现更多的错误）
等价类有哪些类组成
等价类=有效等价类+无效等价类
有效类：针对需求，满足需求规格，合法
无效类：针对需求：不满足需求规格，不合法
测试用例：数据包含：有效数据，无效数据
软件：针对有效数据，做相应的处理；
针对无效的数据，做相应的处理
无效值钱：用例当中更多地是针对无效类的用例
如何划分等价类？与集合的关系？
有效类
无效类：尽可能的无交集
所有类并集：满足符合最开始的需求
冗余
如何做
找：输入条件（输出条件）
针对输入条件，划分等价类，给等价类不同的编号（独立）
逻辑测试用例
物理测试用例
1：N，针对有效等价类设计测试用例，尽可能的覆盖多个有效类，
直到所有的有效类覆盖完成
1:1，针对无效类，设计一条设计用例，只覆盖一个无效类，
知道所有的无效类覆盖完成
测试数据构造
测试
主力
开发
协助
DBA
测试环境
开发环境
测试环境
用户环境（生产环境）
特性
干净
必须
无毒
软件&工具
独立
一般指的是数据库
开发用自己的
测试用自己的
冲突
稳定性
边界值
测试数据
特殊值
如：6-18位字符，可以使字母，数字下划线，必须以字母开头
优先测上点和离点，如果说时间允许可以测内点，时间不允许，可以不用测内点
需要关心三个点
上点
离点
内点
上点和离点不可能同时有效
分支主题
分类法
多条件（数据）组合
判定表
因果图
解决输入输出的关系，
输入与输入，输出与输出之间的约束
正交实验
全单值
基本组合
两两组合（pair-wise）
全对偶
组合技术
认识
多条件
每1个条件都会有多种输入
输出：每一个条件的每一种输入，尽可能的全部组合，就是全覆盖；在逻辑处理上达到全覆盖，
不同的输入组合系统可能会产生不同的处理结果
全单值（单一组合）
多条件：每个条件有多种或1种取值
只需要满足：每个条件的取值，只要取到1次即可，（直到所有的取值完成）
优点：简单明了
缺点：可能会遗漏某些特定的组合
解决方案：补充相关的业务，相关的组合用例
基本组合（一般组合）
相当于以你选择的一条用例为基础，保持一个条件不变，去取另一个条件的值
以选择的1条用例为基本，修改任意的取值，直到所有的取值完成（做加法）
特点：与选择的基本组合有关
判定表
定义
最严格 、最具逻辑性：
把复杂的逻辑关系和多条件组合情况 ，
表达的比较明确
实质： 把输入中所有可能的情况进行组合，
并汇总所对应的操作结果。
各种组合类型的全值组合。
需求
手机是否通讯
是否欠费
是否停机
是否通讯
酒店住宿系统
支持：提前预订 和 会员卡办理 ；
如果房间提前预订，并且已支付定金；
或 持有酒店会员卡；
可以优先办理酒店房间入住
下一天函数：要求输入年月日，
系统显示当前输入的下一天
解答
列出：所有的条件桩 和 动作桩（条件项，动作项）
计算规则的个数
填充 条件项 和 动作项 到判定表
合并\化简规则（业务处理来的）
合并规则
两条或两条以上规则有相同的操作，
且条件项之间存在较为类似的关系，
需要进行规则的合并，用—代替
不推荐合并：在数据逻辑上是可以的，
在业务逻辑上不确定。
优缺点
优点：
充分考虑输入条件间的组合，
对组合情况，覆盖充分；
把复杂的问题按各种可能的情况一一列举出来，
进行全部罗列
简明易于理解
每个用例覆盖多种输入情况，
有利于提高测试效率
对输入条件间的约束关系做了考虑，
避免了无效用例
缺点
输入较多时，判定表规模非常大
合并有可能存在着漏测的风险
是一个全值组合；会产生冗余用例
不能表达重复执行的动作
适用范围
输入输出比较多，
输入之间和输出之间相互制约的条件比较多的情况 。
正交试验
在大量的试验数据中，挑选部分的，有代表性的点来组合覆盖 ，以达到试验目的
用例集数量不太多，达到效果是一样的
缺点：如果系统找不到相应的正交表，可能没办法借用这个方法
正交表
行数：表示用例个数
列数：表头的列表示条件数（因子）
每列的数据：每个条件的取值（水平）
L9（3^4）四个条件，三个取值；表示9=4*（3-1）+1，表示三水平四因子
所有条件的取值分布是均匀的，对于很多重要的没有覆盖到的，还是应该补充
任意两个条件的配对组合分布也是均匀的
写出了全真的测试用例，不要忘了去补充全假的测试用例，
写出了全假的测试用例，不要忘了去补充全真的测试用例
pair-wise
全对偶
状态转换（迁移）
N-switch覆盖：
N从0开始取值
0-switch
1-switch
去覆盖被测对象的各种状态的N+1次 连续状态转换序列
用这个方法，需要明确：1被测对象有哪些状态（状态有一个起止节点（状态））；
有限的状态之内，避免陷入循环
2：任意的起始状态，它所需要转换的事件，以事件驱动
3：状态间通过事件触发转换后的下一个状态（输出）
怎么做（HOW）
根据需求，列出状态以及事件，起止点；（确定被测对象以及其所有的事件）
划出：状态转换图
以图转表（列出测试条件）
确定N-switch覆盖度
根据测试条件，设计用例
（不同的人可能会设计不同条数的用例，根据实际情况选取）
流程分析（场景分析）
用户场景的三个要素
用户场景一定是真是存在的
场景涉及到不同的人，角色相关
涉及到先后顺序，与结果的不同
测试重点
业务流程
至于：流程中间单个功能是否正确，不太关心（先测功能，再测流程）
怎么做（how）
确定用户场景
主要场景（成功的场景）
（基本流）
所有的输入都是正确的，完成相应的业务，输出正确的结果
扩展场景（失败的或者是特殊的场景）
备选流
输入的错误操作或是其他情况，能够完成相应的业务，输入正确
异常流
输入的错误操作，不能完成相应的业务
流程图
建议：图文分开、以备注的方式
根据流程图设计测试用例，覆盖流程、路径
所有的基本流，构成1条测试用例
1个基本流+1个备选流，构成1条测试用例
直到所有的场景覆盖完
识别测试路径
因果图
因果图
定义
由图转表
从需求中找出因（输入条件）和
果（输出或程序状态的变化），
通过分析输入条件之间的关系（组合、约束），
以及输入和输出之间的关系，绘制出因果图，
通过因果图转化成判定表的方法
需求
如果输入的第一个字符必须是#或*，
第二个字符必须是1个数字，则进行文件修改；
如果输入的第一个字符不是#或*，则提示为N；
如果第二个字符不是数字，则提示为M；
有一个处理单价为：1.5元的饮料的自动售货机软件；
若投入1.5元，按下可乐，雪碧，红牛按钮，
相应的饮料会出来；
若投入2元，则送出饮料的时候，退还5角钱；
若投入不足1.5元，提示：金额不足，请继续投币；
若饮料不够，退还金额；
若没有零钱，退还金额，不送出相应的饮料；
步骤
找出原因和结果，并给出标识符
找出原因与原因之间的关系，
原因与结果之间的关系，生成因果图
由图转换成表
生在用例
符号和关系
E： <=1; 最多1个1，可以全为0；
或：I：>=1; 至少有1 个1；
O：有且只能为1；
R：要求：ａ要求ｂ；如果ａ为１，则ｂ必须为１；
即：ｂ为ａ的前导条件； ａ要成功，ｂ必须成功；
Ｍ： 两个结果不能同时发生；
ａ要为１，则ｂ必须为０；
输入 和 输出
CI 和 EI
输入 和输入
组合
约束
和判定表关系
无本质差别
复杂
简单
适用范围
输入条件过多，存在着一定关系（因果）
需求文档与评审
what
需求文档==初稿‘；更新：版本编号可能产生变化
一般以：文档方式呈现
需求文档编写规范：
what
针对异常情况：粗略的列出错误或者异常的情况（最基本）；具体的错误提示信息，如果不确定，可以放在后期的测试（执行的时候）阶段，提出bug单，建议要怎么修改
专业术语：自定义，参考一些专业文档或者书籍；过往的项目经验；
UI界面原型：当有的地方不好描述的时候，可以截图或者加上一句：参见高保真原型介面
依赖性
背景：why：解决什么问题
当前现状
异常处理
概设
祥设
测试用例
分解：每个人写小部分
作用
1：用户需求是源头，用来指导后续的开发和测试的工作展开2：需求的质量怎么样，确定软件的质量如何，后续工作
2：通过该文档，与用户建立连接，让用户理解需要做什么，与需求文档中的描述是不是一致的
3：可以作为用户使用手册的参考文献
需求评审，测试
who
需求分析人员
测试工程师
开发工程师
用户代表
需求分析人员会出一个需求文档的初稿或者概要，然后用户确定没问题后，需求分析人员会和研发团队（需求分析人员，测试工程师，开发工程师）对这个初稿进行评审
怎么做how
评审机制
自省
内省
外省
流程
需求人员进行宣讲（也叫串讲，告诉本次要做什么，用户的背景以及用户的要求）
开发人员，测试人员一起理解需求
对需求产生问题进行统一的记录（方式多样，刚开始打批注，空余时间集中整理为需求问题记录表）
要对需求中的问题进行答复或修改，并告知所有的团队成员
进行第二次宣讲（也叫反串讲），达成三方理解一致，形成需求基线（需求规格说明书的基线）
检查点
被测对象
需求文档
测试方法
黑盒方法：静态
检查点
一致性：前后依赖或者有关联的模块中间有共同的东西是一致的
需求遗漏：需求中包含的东西不全面，和用户需求有出入
二义性：也叫歧义性：造成不同的人有不同的理解
需求错误（正确性）：不清晰的，不明确到底是做什么的
统一性：与UI相关的要考虑统一性
完整性
：需求上的东西：一定是软件要实现的
需求文档里面应该有明确的输入与输出规格
标识（对于不同的分类，需要有不同的标识）
易理解性：让开发和测试容易理解
后续阶段的需求测试
测试需求与分析阶段：有遗漏、不完善、不清晰
回头补充你的需求规格说明书（找需求分析人员，找他确认）
管理者的角度
组织架构
人，根据公司规模制定相应的组织架构
以开发为中心
老大是开发
向开发汇报
绩效考核，软件质量指标，刑侦与技术管理，开发话语权是比较大的
延伸：测试团队规模扩大，可能负责多个项目：与项目挂钩（这里会出现项目接口人：是以开发为负责）
以项目经理为中心
相对以开发为中心，测试的地位有提高，基本上和开发平级
项目经理是老大：汇报对象是项目经理
项目软件
外包
资源，固定的
外包，成本控制：更多的是让公司考虑（由公司的决策或者行政部门），（人员培养，技术积累）
技术提升：培训，培养：交叉能力（会强调能力的多方面的发展）：也是在项目间歇。
一旦进入项目组，离开或者结束点，都是项目经理说了算
资源池释放
甲乙，甲乙丙
产品软件
产品经理是老大
汇报对象是产品经理
独立测试团队
项目经理、测试经理、开发经理是平级独立
独立的资源。调配；预算（人员培训绩效考核等都是产品经理说了算）
汇报对象：测试经理
第三方评测机构（外包服务）
可以通过组织架构，评估测试团队在研发团队中的地位以及影响力，也可以看出公司是否重视测试或者是公司对质量的认识
评审流程
评审更多的是以会议形式展开，会形成：会议纪要
角色定义
作者：主讲人
评审团：
记录员：
子主题 4
测试执行
执行活动
需求评审（静态测试范畴）
转测试、转验收、测试接收版本
版本发布（发包）
开发：取源码，构建
可发布的版本
通知相关的测试人员取版本
部署在测试环境
发包常见形式
1：开发负责人，构建，可能通过QQ、邮件直接发给测试人员
2：CMO配置管理员构建发布：SVN（配置管理工具）：开发人员把代码上传到SVN，CMO取代码，编译，构建，然后通知相关测试人员到SVN的某个路径下取版本
3：测试负责人来构建
4：工具构建：持续集成、每日构建，开发把代码传到CI工具，工具会自动取代码，编译，检错，会形成版本。以发送消息给开发与测试团队
转验收活动
当开发把版本转给测试之后，
意味着测试以此版本为基础，进行测试
直接执行
开发给的版本：配置文件丢失，
导致有些功能，前台页面不能用
导致一些最基本的功能无法使用，
如：页面无响应，报错，版本只能打回，开发修改，测试玩
为了避免以上情况，引入了：转验收活动
（内部）转验收
who
开发
测试
需求
环境：测试环境上执行
用例：1级用例（当前模块你认为最基本的用例）执行
执行结果：
通过之后测试接收版本，进行测试
通过但是会出现bug，测试接收版本，进行测试
不通过，bug级别高，很严重，按本打回，提交缺陷，验收不通过
灵活处理
买电脑、开机配置
冒烟测试（预测试）
冒烟测试，来自于硬件测试（办卡和电源）
目的:暴露最基本，验证，正确性的问题
测试人员与开发人员都可以做冒烟测试
开发人员在转版本转验收之前做
找测试人员提供用例，如果没有用例，可以用简易的checklist测
环境：开发环境，真实环境
执行结果：如果出现缺陷，开发提交缺陷单
没有问题，自验通过，转验收
测试人员在转版本转验收之后做
单个模块，转验收
单个模块：也可以在全面测试之前测试
子系统，系统级，产品级？
测试人员做
用例：1+2级正向
环境：测试环境
问题：提单，或者版本打回
建议：每一轮开始测试前，都应该做冒烟测试
版本信息内容（内部版本）（明确
开发给的源码包是你想要的）
现状：1：很多时候会产生需求变更，变更记录一般是滞后，开发给你的包/版本，有可能和原计划不一致（这样很可能出现偏差）
现状：2：开发把bug修改后，没有及时的更新bug的状态，可能就不会针对这个bug进行测试
现状：3：延期，模块复杂度比较高，不能够按计划如期完成
开发把报构建好，不告诉测试相关的情况，有可能会
子主题 5
全面测试
回归测试
软件代码会变更
需求变更
功能新增、减少、变化
修改bug
代码优化、移植平台
目的
bug本身有没有被修改完成
修改bug过程中有没有引入新的bug
有没有改变原有功能（老功能）
回归策略
优先级
优先做预测试（老功能+新功能的1级）
针对bug，进行测试
how
执行用例
执行全部
执行部分
优先级1级
用例发现bug
非用例发现bug
补用例
补充（修改影响法）
测试人员：提交的bug，需要自己分析，有没有相互影响的地方
查看：相互影响的部分，是否有用例与之对应，如果没有，重新设计编写用例
执行bug单本身对应的用例，还需要执行新加的相互影响的用例
引入新bug
老功能有影响
回归记录说明
1：回归不通过，引入新的问题，将新问题列清楚，把缺陷单的状态改为reopen，重新给开发
开发不愿意看到bug单很多
开发也不愿意看到bug单少单严重度高
开发不希望看到一个bug单的不通过次数多
2：开发要求你们，关闭本身的bug单，重新提价一个新的相互影响的bug单。
避免：1：本身项目组bug严重度高的单数量超高，可以不提交，但是在回归的时候一定要做完整2：需要重新补：避免新的bug单和操作步奏与老的bug单一模一样
交叉测试
发散测试
测试活动
story测试
指的是单个模块在这个测试中，没有轮次
迭代测试
第一轮（528-529）
第二轮（531-61）
SIT第一轮（518-520）
SIT第二轮（22-23）
SIT第三轮（26-30）
SDV,UAT（验收测试）
上线
测试延伸
网站发布检查
搭建检查用例
编写测试框架思维导图
实现对应的用例
新增功能的后续添加
出现问题的用例维护
时间点
4月1日
4月15日
无时间
定点添加
建立评审制度
目标
用例评审
测试报告完善
网上问题分析
定期分享
方式
互相评审，会议制
持续测试3日以上任务必出报告
记录每一笔网上问题，半月分析
会议制，分享近期心得
测试方向优化
方向
自动化
回归测试固化
子主题4
子主题3
做法
使用selenium,appnium实现
发布流程以及版本测试
子主题3
子主题4
工作总结
测试报告
项目软件
外包
外部（会美好一些）
内部（会真是一些）
产品软件
公司自己制定
日报/总结
执行阶段
当天的任务执行情况
当天任务风险控制
明天的计划安排
每一轮结束的时候
自己负责的测试模块
质量评估
发现缺陷的统计
组长会汇总成测试团队本轮的测试报告
测试报告
特点：严谨
依靠数据说话（测试团队的测试记录）
用例总数：用例与需求的覆盖度
用例的执行情况
缺陷的总数
缺陷的解决率
缺陷的遗留率
结论
达到要求（符合要求）
不通过，达不到要求
内容
测试对象
项目名称，产品名称，版本号
测试范围
测试项，测试需求
测试结论
领导会看
测试的组织
人，任务，工作量
测试环境、测试工具
测试的数据
发现的bug数
用例情况
需求覆盖情况
风险
备注
用户使用手册
按照需求功能写
用户使用场景
测试策略
什么是软件
程序
数据
文档
测试对象
测试软件，不仅仅是测程序
不同的阶段，
会需要不同的测试对象，进行测试
测试级别
单元测试（junit单元测试的工具，主要是java编写的）
集成测试
系统测试
验收测试
测试方法
单元测试就是白盒测试？
系统测试就是黑盒测试？
白盒、黑盒、灰盒
静态、动态
用户、开发方、第三方（）第三方评测机构
不信任
手工、自动化
单元、集成、系统、验收
测试策略
分支主题 6
一、iOS App漏洞检测系统
1.1 核心检测模块
静态检测引擎
Logical Data转化
代码描述分析
证书初始化验证
动态分析引擎
设备操作监控
网络监控程序
视频文件行为追踪
1.2 专项检测能力
第三方库检测
安全版本比对
漏洞模式匹配
系统层检测
Manifest分析
签名系统验证
权限异常检测
二、Android App漏洞检测系统
2.1 多维检测体系
APK深度解析
通用脱壳技术
动态硬盘分析
文件结构检测
运行时监控
内存数据捕获
网络请求审计
系统API调用追踪
2.2 安全增强功能
漏洞感知系统
实时风险预警
漏洞模式库匹配
自动化修复
代码热更新
配置文件替换
三、任务管理系统
3.1 任务控制中枢
任务流引擎
批量任务创建
优先级分配
异常中断处理
执行监控
实时进度仪表盘
资源占用统计
日志记录分析
3.2 协同工作平台
团队协作模块
任务分派系统
权限分级控制
数据管理
检测报告归档
历史记录检索
四、漏洞感知系统
4.1 智能分析体系
多维度感知
静态特征扫描
动态行为分析
数据流追踪
风险评级
CVSS评分适配
危害场景模拟
4.2 响应处置机制
自动化报告
漏洞详情生成
修复建议输出
预警推送
多通道通知
应急响应预案
附录：系统对接说明
开放接口
RESTful API
Webhook配置
数据导出格式(JSON/XML)
硬件集成
移动设备集群管理
云真机调度系统
测试回顾
测试环境
C端的搭建
ie，chrome，ff
S端的搭建
web服务器的搭建
Apache tomcat 8.0.33
windows平台的web服务器IIS
启动服务
通过浏览器IE来访问web服务器的地址
本地访问：localhost：端口号；===www.baodu.com：URL地址，域名
本地访问：127.0.0.1：端口号；===IP地址；回环地址
多人：客户端访问：域名和IP地址访问
访问的时候有负载均衡或者多台服务器，不会造成
访问出现问题
外网：一般的：通过域名访问服务：
局域网：一般有两方式都可以：IP和域名访问
DNS：域名解析服务器
本地hosts文件配置：在C盘中找windows文件夹找system32，
然后找drivers然后找ETC，里面有个hosts文件，
可以再最后加入IP地址与对应的域名，就可以通过域名访问了
发布你们的网站，系统，要让外网的人访问，要做DNS域名的备案；
把被测对象放入相关文件夹：webapps
通过浏览器：项目名（文件夹名称）
数据库服务器的搭建
表
涉及到软件，硬件，网络
服务器的IP地址：静态，固定化；一般不会DHCP
测试类型思维导图总结
一、测试类型
（一）文档测试
目标
方法
完成标准
需考虑的特殊事项
（二）标准符合性测试
目标
方法
完成标准
需考虑的特殊事项
（三）数据及数据库完整性测试
目标
方法
完成标准
需考虑的特殊事项
（四）用户界面测试
目标
方法
完成标准
需考虑的特殊事项
（五）功能测试
目标
方法
完成标准
需考虑的特殊事项
（六）业务逻辑测试
目标
方法
完成标准
需考虑的特殊事项
（七）性能测试
目标
方法
完成标准
需考虑的特殊事项
（八）安全性测试
目标
方法
完成标准
需考虑的特殊事项
（九）兼容性测试
目标
方法
完成标准
需考虑的特殊事项
（十）配置测试
目标
方法
完成标准
需考虑的特殊事项
（十一）故障转移及恢复测试
目标
方法
完成标准
需考虑的特殊事项
（十二）易用性测试
目标
方法
完成标准
需考虑的特殊事项
（十三）可靠性测试
目标
方法
完成标准
需考虑的特殊事项
（十四）本地化及国际化测试
目标
方法
完成标准
需考虑的特殊事项
（十五）其他类型测试
目标
方法
完成标准
需考虑的特殊事项
缺陷管理
术语
Bug：错误，在设计上编码上需求上的错误
defect：缺陷，更多是在设计上的不足或遗漏
错误，故障，影响，失效
Bug单
办公软件
缺陷管理工具
自研dts
商业
QC,JIRA
开源
禅道，bugfree，bugzilla，redmine
缺陷组成
用例编号
bug编号
统计bug数量
操作步奏
预期结果
缺陷标题（缺陷主题、概述）
一般可以借鉴用例标题，转成缺陷标题
让开发能够通过缺陷的标题，看得出是个什么缺陷、表象
祥述
环境信息
测试访问地址：BS架构
测试数据库地址
客户端：测试机、用户端：兼容性
操作步奏
预期结果
实际结果
通过操作步骤，操作软件，软件的实际表现
备注
一般写特殊情况或实际结果不好描述的，一般会加粗，或者是在实际结果描述不清的时候，在实际结果中添加详见备注
附件
截图
截最后结果的图
视频：录制视频
提交人
提交时间
bug状态
new
open
reject
duplicate重复
fixed修复完成
reopen（意味着回归测试没有通过）
close
项目名
模块
版本
严重度
致命
系统死机、崩溃、核心功能和核心业务流程错了
严重
当前的功能，影响了别的功能的使用，
一般
当前的功能问题，不会对别的模块造成影响
无关紧要
UI布局，颜色统一性，提示信息不方便
对用户的影响（关注质量模型），
上面四个更多指的是功能上面的影响
优先级
开发修改缺陷，决定先改税后改谁
非常高
高
中
低
解决办法
开发，通常有三个需要开发填
问题分析
解决说明
测试建议
解决人（也叫下一步处理人）
开发
测试管理
开发管理
回归说明
回归的策略
回归版本
回归的结论
回归填写（测试填）
谁回归？
提交人？谁提交？谁回归？
bug管理流程
提交
重现
确认
分析
定位
修改
自验
转交
跟踪
bug（缺陷）生命周期
生、死
流程
简单、直接
测试
开发
标准
测试
开发
测试管理
审核
是否有重复
是否符合规范
缺陷内容正确性（需求变更）
开发管理
分发
分发给不同的开发人员
白盒测试技术
单元测试的目的
发现各模块内部可能存在的各种错误，主要是基于白盒测试
验证代码与设计的符合性
跟踪需求和设计的实现
发现设计和需求中的错误
发现在编码中引入的错误
在C++中，测试基本单元是类或类的方法
单元测试的内容
模块接口
局部的数据结构
独立路径
出错处理
边界处理
单元测试环境
测试用例
驱动模块：接收测试数据，传送给被测试模块，比较输出和期望值，打印结果
被测试单元
桩：模拟替代隶属于本单元的模块，返回不同期望值，模拟不同功能
单元测试的开展
1. 确定被测试对象、模块主要功能及与其他模块的关系
2. 确定应测试的特性及各被测试模块的具体测试对象
3. 分析被测试单元间关系，画关系图，确定测试策略
4. 根据结构图和测试策略，定义操作流程，包括驱动、桩、测试代码的添加
5. 测试需求：环境需求、被测试对象的特殊要求、测试工具要求、测试代码要求、测试数据要求
示例：确定模块间测试流程
RankConfig：解析配置项
GeneralRankFrame：实现逻辑控制
GeneralRankObject：实现排序算法
BoostObjects：实现数据结构
测试顺序：RankConfig → BoostObjects → GeneralRankObject → GeneralRankFrame
确定被测单元内部测试流程
测试策略
自顶向下策略：先测试顶层单元，调用的单元做桩模块；依次向下测试，已测试单元作为驱动模块
自底向上策略：先测试最底层模块，模拟调用模块作驱动；依次向上测试，已测试模块作桩模块
独立测试策略：不考虑模块间关系，为每个模块设计桩和驱动，独立进行单元测试
逻辑覆盖
语句覆盖法
分支覆盖法
条件覆盖法
分支条件覆盖法
路径覆盖法
基本路径覆盖法
1. 根据程序流图得到控制流图
2. 计算环路复杂度
3. 导出基本可执行路径集合
4. 设计测试用例确保基本路径中每条路径执行
其他测试方法
循环路径测试：包括简单循环、连锁循环、嵌套循环
等价类划分
边界值分析
单元测试原则
代码行小于30的函数可不做单元测试，通过代码走读保证质量
代码行大于200的函数建议重构
提高测试效率，建议以黑盒测试用例设计为主，白盒为辅
对全新和修改过的代码进行单元测试
按测试方案进行，避免随意性
建议使用自动化测试框架
单元测试应融入代码每日构建中
软件危机
低成本（高成本）：预付：20%，60%-70%
高质量（低质量）
高成本VS低质量 根本矛盾冲突
软件工程学引入：指导软件软件生产与管理，希望低成本（时间、经济）去研发满足用户的需求（高质量）的软件
怎样把测试工作做好？做质量
质量模型
质量管理体系
SQA与QC的关系
质量
消费者
终端用户
验收：外部质量
验收测试：去测试被测对象是否满足用户需求
使用质量
在用户使用过程中检验被测系统是否满足用户的显示
与隐式需求。显示需求：SRS与用户需求；
隐式需求：潜规则，用户习惯，默契等
用户对软件关心哪几个方便
是否能用：适用性（能不能提供我想要的功能）
提供功能服务怎么样？==性能
时间响应快不快？
效率怎么样？
稳定性？
易用性：操作方不方便用户操作
安全性
兼容性：平台移植能力
测试工程师：一定要站在用户的角度进行测试
你们是软件的第一批用户（用户体验不好的都可以认为是一个缺陷）。
生产中
关心质量
研发团队（需求人员，系统架构设计，编码，测试人员，运维）
生产商
内部质量
测试活动：去测试被测对象满足需求规格说明书（SRS）。
测试过程中哪一个阶段发现的缺陷最多？
测试初期发现的缺陷最多，随着时间的增多，缺陷收敛
管理者
过程质量
SAQ（软件质量保证），一般中小公司该角色由测试人员做
监督流程的实施、过程的制定、进度、质量
质量即符合需求（质量即需求的符合度，
符合度越高，质量越好）
软件质量模型
拿到任意软件，被测对象都可以参考软件质量模型进行测试
ISO：国际标准化组织
ISO：9126版本
6个质量特性
功能性：互操作性差不多相当于兼容性
可靠性：在规定时间内完场规定工作的能力
易用性：易操作性：方不方便操作；
易理解性：容不容易知道是做什么的；
效率
维护性
可维护性可移植性对于用户（测试工程师）来说，可测性不高。
更多是站在软件研发内部，关注的是代码逻辑
结构、数据处理、是否方便维护和移植（开发关心）。
可移植性：从一种环境移植到另一种环境的能力
27个质量子特性
分支主题
ISO：25010版本
8个质量特性
功能性
安全性
互用性
可靠性
可用性
效率
可维护性
可移植性
36个质量子特性
软件测试模型
软件测试流程是什么
V模型
分支主题
W模型
分支主题
分支主题
H模型
分支主题
说出：V、W模型的区别？V模型是串行工作方式，W模型是并行工作方式
说出：你所知道的测试模型
移动无线测试
基础能力体系
操作系统
**Android**（SDK/ADB调试）
**iOS**（XCTest/XCUITest）
**跨平台开发**（React Native/Flutter）
开发工具
**IDE**
Android Studio
Xcode
**版本控制**
Git（Gerrit代码评审）
SVN
测试工具矩阵
通用工具链
**抓包工具**
Charles（HTTPS解密）
Wireshark
**调试工具**
ADB（Android Debug Bridge）
Instruments（iOS性能分析）
自动化测试框架
跨平台框架
**Appium**（支持Android/iOS）
**Calabash**（Ruby驱动）
**Robotium**（Android精准定位）
平台专用框架
**Android**
Espresso（Google官方）
UI Automator
**iOS**
KIF（Keep It Functional）
EarlGrey
单元测试体系
Android单元测试
JUnit4
Mockito（模拟对象）
Robolectric（阴影对象）
iOS单元测试
**OCUnit**（SenTestingKit）
**GHUnit**（可视化报告）
**XCTest**（苹果官方）
性能优化工具
内存分析
**MAT**（Memory Analyzer Tool）
**Android Profiler**
**Instruments Allocations**
网络性能
**Network Link Conditioner**（iOS网络模拟）
**ARO**（App Resource Optimizer）
安全测试维度
漏洞扫描
**drozer**（Android组件安全）
**MobSF**（移动端渗透框架）
数据安全
**SQLCipher**（数据库加密）
**Keychain**（iOS密钥管理）
AB测试平台
**Firebase A/B Testing**
**Apptimize**（实时配置更新）
**Optimizely**（多变量测试）
专项测试能力
多设备管理
**STF**（设备农场管理）
**Sauce Labs**（云端真机）
持续集成
**Jenkins Pipeline**
**CircleCI**（自动化构建）
**Fastlane**（一键发布）
兼容性测试
**AWS Device Farm**
**Xamarin Test Cloud**
系统测试类型
不同类型的被测对象
针对被测对象，有不同的测试类型，
有不同的角度来进行测试
为什么做了ut，it还要做st？
需要去找差异和区别
UT，IT做的是功能测试，接口测试
子主题 2
常用测试类型
功能
功能测试是不是系统测试？
测试环境和用户环境中间是有差异的
去测试软件的功能是否满足用户的需求；
看功能达没达到；
人工或自动化
测试工程师
用户代表
类用户
开发人员
单个模块的功能，相关功能模块的集合：业务；（业务流程）
输入输出、数据组合、状态转换、个人经验、
错误推测：场景分析或者流程分析
性能
一般性能测试
负载测试
压力测试
容量测试
基准测试
稳定测试
兼容
1：需求分析阶段、需求评审、需求测试：提出自己的建议：有没有兼容性的需求？哪些地方需要考虑兼容性？在系统中，怎么体现出兼容性?让用户知道理解（建议或者提示）？
兼容类型
相同软件的不同版本间兼容
向前
向后，习惯性会向后兼容
BS：ietester工具：模拟ie6-ie10
类似软件间的兼容
ie，Google，ff（浏览器的内核）
windows与Linux兼容；医疗设备，嵌入式设备
数据的兼容
针对不同类型的数据，用不同的软件使用，数据不失真
另存为，导入导出，可以理解为数据兼容，数据库可能产生乱码
硬件兼容
与整机兼容
与外设兼容
APP测试
移动设备、手持终端
分辨率兼容
软件兼容
操作系统/平台
应用软件之间的兼容
不同浏览器器的兼容
数据库的兼容
软硬件配合兼容
数据兼容
不同版本间的数据兼容
不同软件间的数据兼容
配置测试
在不同的相关硬件的配置下，看软件的表现能力怎么样
S端：（web服务器、DB服务器等等的硬件配置不同）
放在：性能测试类型里；
安全
1：安全测试是保障软件或者被测对象的安全机制能够防止非法入侵；同时还要保障合法的正常使用
2：一般是从功能上面做安全，企业更多地招聘职位偏重于攻击（黑客）
3：最常见的防范：密码的设定（密码的复杂度，更新频率，密文的显示方式，加密的方式（由安全公司做），不提供复制粘贴密码，用户时效性（通常在BS端），）登录方式：（本地异地，不同设备上的验证）
4：权限的控制：默认账号、管理员、普通用户；不同的权限只能做自己范围内的事情；
5：数据的安全（数据存储、用户信息安全、），安全日志文件（配置、日志文件，涉及到敏感信息，一般不会明文显示）
6：攻击手段：（appscan可以扫描所做产品或者系统的显而易见的漏洞）；
7：软件本身的安全（白盒）
UI
1：如果时间充足，团队需求，需要单独做UI测试，单独写用例；
2：如果团队没有单独要求，不需要单独为某个模块设计UI测试
设计，往往和相关功能测试用例在一起
3、不会单独让人做UI设计用例，可以在UI界面原型设计
和评审环节，可以介入
4、和UI界面原型对比，界面原型在需求分析之后，后期执行测试的时候，当发现UI界有需要改动的时候可以提出来
5：UI的主题很重要，怎么体现软件，和软件结合起来；内容（导航、图片、连接、色彩搭配，整体框架、文字、交互等等）
6：图片：交给设计人员和开发人员保证；文字：word格式校验；连接：xenu工具
易用性
1：站在用户角度觉得方便，易使用，易学习，易理解，易吸引；尽可能少花成本
2：实际的处理方式：灰度处理
3：用户使用习惯；简单、易懂（图标）；对比（纵向、横向）；创新；
4：易理解：tips；用户提示信息；（让用户知道当前的系统处于什么样的状态，同时下一步系统要怎么处理）
本地/国际化
质量模型：依从性
软件为谁开发，遵循它的规范、使用习惯、人文风俗
汉化、翻译
安装
1:APP应用会用到测试===上架、下架(应用商店)
安装测试
安装手册：文档；在线方式
安装使用文档：一般都是测试人员编制
流程（场景分析、流程分析方法）
安装过程中，产生的数据；===compare文本、文件夹对比测试
考虑配置文件or支撑程序，配置程序
先后顺序：
希望提前预判；自动安装（LR）
已经存在了，使用了，再来安装
安装过程中，任意一个环节取消
同时安装多个程序，处理方式
所有过程，正向，下一步
更新测试（升级测试）
CS端：例如QQ，要清楚升级的是C端还是S端
低到高：如果不好用，能不能高低到
升级过程中文件的生成方式：覆盖or其他
软件的发布方式：只发布补丁or全部
新旧版本的并存
卸载测试（反安装）
文件、数据的处理
干净，注册表
卸载方式：
控制面板：windows平台
第三方管理工具
兼容测试
软件本身是否有卸载程序
直接删除文件
卸载之后，再一次安装
怎么做测试？
综合练习：A4纸的测试
要求：全面按照国家的标准做
被测对象：A4纸
功能
1：对比大小厚度颜色，合格产品
2材质是否合格，把这个环节提前由其他部门保障质量
ph，静电
3和用户使用结合场景
安全性：易用性：
办公
写字，绘画
不浸墨
不掉色
反复写
打印
子主题 1
复印
非办公
折纸
其他
4：逆向、发散测试场景
反复折叠
反复擦写
揉成团再展开
0 条评论
下一页
