计算机基础

1、计算机范式：冯诺依曼机

2、存储单元

bit、byte、KB、MB、GB

3、网络

ip、域名、ping 域名、   ipconfig

测试工作的流程

-------------------------------------------------------------------------------------------

一 编写测试大纲

罗列测试点

先读，再分析流程，拆分测试点

## 显性需求 明确的需求

隐性需求 未明确指出 比如：欠费账户支付余额不足、账户类型

拿不准的找业务

二 测试大纲评审

产品、开发、测试 三方 查缺补漏

评审方式

1 定会议室
2 视频会议

---------------------------------------------------------------------------------------

三 写案例 （大纲写完就写案例）

编写测试大纲—分析功能点-----测试要点
测试大纲评审—查漏补缺
案例编写----三方评审
冒烟测试----主流程测试，重要交易----业务、开发、测试-----差缺补漏
第一轮测试

四 冒烟测试 主流程、主业务规则测试 占5% ~ 10%

1 通过 全量测试 第一轮测试   回归测试（第二轮测试）
2 不通过  挂起

五 全量测试

1 第一轮测试

发现缺陷使用缺陷管理工具 jira、禅道

执行案例
发现Bug—提交Bug–跟踪Bug–验证Bug
日报
案例执行数量
Bug发现数量
解决了多少Bug，还剩余多少Bug
风险 验证影响测试进度

bug数量      先多后少    整体10%左右
致命bug      当天或者隔天解决
轻微bug      2~3解决

2 回归测试（第二轮测试、第三轮测试）

在测试过程中可能会有需求新镇、变更、删减 测试用例的补充

回归测试执行用例的情况
时间
如果时间充足，全量用例
时间如果不充足，执行主流程，主业务逻辑，和第一轮测试过程中发现bug的用例，以及和bug相关联的用例

测试质量
如果测试质量很差，30%(占总用例)以上的bug，一定要全量执行用例，如果时间不充足，一定要报风险

六 验收测试 有客户或者产品经理进行验收 一般不是测试进行

七 上线 线上出现bug是危险的事情（生产事件）

-----------------------------------------------------------------------------------------------------------

从冒烟测试到全量、最后回归测试都需要有测试报告

内容
测试的版本、测试的需求版本、测试用例、测试bug信息、风险点、测试结果、如果有未修复的bug一定要备注清楚原因和沟通结果

负责人
一般有主测人或者模块负责人来写

####------------------------------------------------------------------------------------------------------
测试工作的流程
项目立项
需求研读
需求评审
制定测试计划
1 编写测试大纲 主测写、有可能是自己写
2 测试大纲评审
3 写案例 （大纲写完就写案例）
4 冒烟测试 主流程、主业务规则测试 占5% ~ 10%
5 全量测试 第一轮测试 测试报告
6 回归测试（第二轮测试、第三轮测试） 测试报告
验收测试 有客户或者产品经理进行验收 一般不是测试进行
上线 线上出现bug是危险的事情（生产事件）

---------------------------------------------------------------------------------------------------

补充

0-1项目 从头开始的项目，整个测试流程 周期长 半年到一年

迭代项目 项目做好了，但是功能一直在添加的项目测试。美团加影票购买模块 周期短 一周两周 一个月

敏捷测试
敏捷开发的最大特点：高度迭代，有周期性，并且能够及时、持续地响应客户的频繁反馈

敏捷测试主张尽早开始测试，重点关注持续迭代地测试新开发的功能.
敏捷的测试团队还要保证整个软件开发过程是正确的是符合用户需求的
遵循
1、强调从客户的角度，即从使用系统的用户角度，来测试系统
2、重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段
3、建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性