上午：
一：测试的分类
1.需求测试
2.界面测试（将UI设计出的高保真图与开发出的界面进行比对）
3.功能测试（检测开发功能的完整性）
4.安全性测试
5.
A:可用性测试 （产品可以使用 电梯-超过两份钟升降）
B:可靠性测试 （在规定的时间内完成规定的时间 2分钟之内完成升降）
可靠性包含可用 （产品可靠则可用）
6.可移植性测试 （不同电脑是否可以运行）
7.兼容性测试（考虑到客户用的多种环境 网站不同的浏览器）
8.易用性测试（功能好不好用 用户体验好不好 同样一个功能微信扫一扫放到辅助功能去 将会带给客户不好的用户体验）
9. 性能测试的一个分类
A：压力测试 （电梯最大承受能力2000kg 不断的加重量 看一下电梯的故障反应 2000kg临界值 压力测试就是突破临界值 ）
B：负载测试 （逼近临界值 电梯加载2000kg 不断的运行 看能运行多久）
A和B是性能测试的一个分类
二：IT常见术语
pc机：personal computer 个人电脑
物理机：用作服务器
便携机：一般基建和工程作业
OS：
操作系统（Operating System）
A：Web端
win10 win7 win xp
Mac OS--苹果电脑的系统 （类Unix系统）
Linux
B：手机端
Android
IOS
Window Phone
黑莓
塞班
Dos命令：
windows系统 运行--》cmd--》出现图形化界面
e: 进入e盘
dir 查看当前盘下所有文件夹
ipconfig 可查看当前ip
u盘--中间件（连接两个物体的中间件）
路径：
相对路径：
绝对路径：
IT行业的两大架构
客户机到服务器
client-server 简称CS架构
安全性相对较高
上传下载网络相对快
缺点：
更新维护更麻烦
需要下载app
浏览器到服务器
browser-server 简称BS架构
优点：
易维护 新功能上线服务器更新就好 方便
缺点：
安全性较低 上传下载相对较慢
单机软件和共享软件
单机：局域网内可用的 魂斗罗
共享软件：有道云
客户和客户需求
项目和项目需求
客户需求转化成专业的项目需求
一个项目组当中的角色：
项目经理 project manager 简称 PM
掌控项目组的进度 （管理测试和项目经理）
下面有个开发经理
开发人员
测试经理： TPM （test manger）
测试组长：TL
测试人员：TE
产品经理：对接客户 对接需求
运维人员：维护公司的开发和测试环境 等等 项目的发布（把app发布到应用市场）和部署等
下午：
为什么要测试
1.软件的非正常运行或其自身的缺陷（bug）会引发很多问题
2.软件是有代码和文档组成的，而这些都是由“人”来编程和设计的，人都可能会犯错
3.环境也会影响软件，已致软件出现失效现象
4.软件测试活动只是关键的质量保证之一
什么是测试：
制造业的定义：以检验产品是否满足需求为目标
软件行业有多种说法：
A：验证软件的正确性
B：发现软件中的缺陷
发现软件中的缺陷的三种观点：
1.测试是为了证明程序有错
2.一个好的测试用例：
在于它能发现以前未发现的错误
3.一个成功的测试：
能发现前所未有的错误的测试
软件的生命周期：
--软件从生产到报废的整个过程，是一种时间的概念
通常软件生命周期包括哪些阶段：
1.客户问题的引入或定义
2.可行性分析（设计经济 商业论证 政治 法律 技术等 ）
3.项目招投标 （项目不一定客户只交给一个团队做 可能需要投标）
4.项目立项（项目进度的规划）
5.需求分析
6.开发阶段（设计 编码 测试）
7.软件维护
接到项目 （30%定金）--》开发完（60%）--》一年维护后（10%）
典型的软件生命周期 的模型：
C:\Users\陈先生\AppData\Local\YNote\data\qq33F4A7B9B5FF2061A2D632C0F0B64137\ab3f374dba324ce78b081fdf5f8863a9\clipboard.png
瀑布开发模型用的比较少
v模型
C:\Users\陈先生\AppData\Local\YNote\data\qq33F4A7B9B5FF2061A2D632C0F0B64137\53c255506a794c8d80fa93bc437b39f3\clipboard.png
根据用户需求进行提炼变为项目需求
召开需求澄清会议：对需求进行分析
需求澄清会议由：产品经理进行讲解
对需求进行分析讨论所有的项目组成员达成一致的意见并且形成一个基线化文档
基线化文档：表示当前状态已经非常的稳定，可以随时进入下一个状态
--》也称为 需求规格说明书（SRS）
概要设计 (HLD)：开发人员编写 根据SRS 搭建一个框架
详细设计（LLD）：开发人员编写 根据 HLD 进行细化开发
单元测试：unit test（开发人员自测）
又被称为白盒测试（透明盒子测试）
对程序的内部数据 内部结构和内部逻辑进行测试
黑盒测试：功能测试等
集成测试：又称为接口测试 又叫做灰盒测试
QQ由五个单元模块组成，给到多个开发小组去是实现
五个模块是通过接口进行集成 单个模块没问题，不能保证集成没问题，需要测试接口
系统测试：
保证自身系统功能正常使用，还要考虑与第三方软件的结合使用/对接
比如别的软件用qq登录，其实也是调接口
系统测试和集成测试放在了一起测试成为系统集成测试（SIT测试），功能和接口测试一起测
验收测试：
α（阿尔法）测试：我们自己去模拟用户的使用行为，（阿尔法测试是有开发人员和测试人员在现场），如果发现了bug，直接让开发人员进行修复。--此时产品还没有交付到客户的手中
β（贝塔）测试：产品已经交付到客户手中，直接由客户去进行验收，如果发现问题（bug），客户会把bug提单（列出清单），发邮件抄送给项目组所有成员。
v模型总结：
用户需求和 需求分析是连贯的很多公司都是合并的
系统测试和集成测试也一般合为系统集成测试
做项目有哪些阶段，每个阶段的输入与输出有哪些：
输入 输出
1.需求分析 对需求进行分析性 SRS（需求规格说明书）
2.概要设计 SRS 概要设计说明书
3.详细设计 概要设计说明书 详细设计说明书
4.编码与实现 编写代码 整个项目的代码包（.war，.jar格式）
5.单元测试 根据代码进行单元测试 单元测试报告
6.系统集成测试 执行测试用例进行测试 系统集成测试报告
7.验收测试 用户参与验收测试 验收测试报告
C:\Users\陈先生\AppData\Local\YNote\data\qq33F4A7B9B5FF2061A2D632C0F0B64137\c38a8840500a4081a7da81b2d5b88fd5\clipboard.png
H模型：
开发流程的模型
以开发电商平台为例
项目和版本之间的区别是什么？
微信项目：运行了8年
版本：3个月一个版本
一个项目有多个版本迭代
需求澄清会议是由产品经理召开，是产品经理进行讲解
6w内 可能会有多次的需求澄清会议
HLD：开发人员根据需求规格说明书编写概要设计说明书
测试人员：
1.Review HLD 评审 HLD
2.继续了解SRS
LLD:开发人员根据概要设计说明书编写详细设计说明书
erview：评审LLD
TPM:测试经理编写测试计划（需求分配 软硬件配置 人力安排 风险评估等）
coding：开发人员进行编写代码
TE（测试人员）输出初稿：测试人员编写完测试用例，进行用例评审
用例评审分为：
1.交叉评审 ：测试组内同事进行评审
2.组内评审 ：项目组内所有的同事进行评审 开发、测试经理 ，开发和测试人员，与项目组相关的同事都会参加
3.会议评审（正式评审） ：有客户参加
TPM将测试用例输出到 testlink==》是一个用例管理工具 并将测试任务分配（一般是谁写的用例谁测）
测试骨干：公司有话语权的测试老大
测试经理或运维人员搭建测试环境，开发人员把项目的代码包给到运维人员或者测试经理 进行部署到Linux当中
当项目部署成功之后进行冒烟测试==》用例执行时间 2-4 天，测2-30条用例 （这2-30条从SIT1测试里抽取的）：
冒烟测试来源：来源于硬件测试 以前测电路板通电 如果电路板冒烟了 就说明电路板坏了 那就没必要再检查电路板的二极管好坏了
冒烟测试：测试主体功能 比如 支付功能就是测试能否正常支付
QQ测试的主体功能：注册成功
登录的主体功能：登录成功
车的主体功能： 能开
冒烟测试不通过： 则把版本打回 让开发人员重新修复bug 重新部署
冒烟测试通过：则执行SIT1 测试
SIT1测试又称为系统集成测试和全量测试
全量测试是指的用例的数量
假设当前版本我写了1000条测试 SIT1测试需要测试1000条
在执行用例过程中找到bug需要让开发人员进行修复，修复后进入SIT2测试
SIT2测试又称之为：回归测试和增量测试
增量测试是指：在执行系统集成测试的时候有场景没有覆盖到，重新添加的用例==》添加了50条
回归测试主要测试哪些问题：==》回归测试执行450条左右
1.根据用例测试上一轮出现的bug
2.新增的用例需要进行测试
3.冒烟测试用例每一轮都要测试
4.需要对上一轮出现bug相关联模块进行测试
SIT3和SIT4都是回归测试，测试的内容和SIT2一致
SIT3执行用例 280条左右
SIT4执行用例100条左右
SIT4:bug为0或者1 bug为0 是上线的硬性条件
这个1是建议性的bug
建议性bug：对功能不会造成太大的影响，可以留在下个版本进行修复
1000条测试用例的bug数量：
50-150个左右 （5%-15%）
项目与产品的区别：
先有项目后有产品
敏捷开发模型：
交付周期非常的短，4-6天一个周期
增量开发模型：
迭代开发模型：
项目被分为大量迭代过程，一次迭代就是一个完整的开发循环，是一个可以发布的可执行的产品，属于软件开发周期中最终产品的一个子集
测试的基本原则：
1.测试的标准是用户的需求
2.测试不仅仅是单纯的软件本身的测试（需求文档也要测试）
3.软件外在没有失效不代表软件系统是可用的
4.软件的完美度没有完全正确的，测试只能帮助软件更加完美，更加正确
5.穷尽测试是不可能的
6.测试应该尽早的介入（早期引入的 问题占到整个问题数目的50%以上）
80%的bug会出现在单元测试阶段
7.二八原则：80%的bug和错误会集中出现在20%的区域内
8.杀虫剂效应（也就是说要不断的...）
安全测试：金融机构，政府系统，和金融挂钩的
测试活动的生命周期：
C:\Users\陈先生\AppData\Local\YNote\data\qq33F4A7B9B5FF2061A2D632C0F0B64137\1463bef72ed8491dbba447a740e3cbeb\clipboard.png
C:\Users\陈先生\AppData\Local\YNote\data\qq33F4A7B9B5FF2061A2D632C0F0B64137\1463bef72ed8491dbba447a740e3cbeb\clipboard.png
|
|
211
0
多测师社区 
