互联网测试计划

测试计划关注很少，变动快，可独立运行差，计划一周左右不要太长远、实时更新，

互联网测试计划：
1、主题-简单介绍-框架、目标、上线时间、
2、风险分析-会遇到的问题-产品工作排期问题情况
3、回归基线-功能基线、性能基线、安全基线；小版本迭代如何算是通过了新功能成功验收、小版本的回归测试成功
4、产品自动、手动是如何分配的，做一个好的折中，达到收益最大，自动化何时介入；
5、发布和回滚，产品发布后出现权限、删除等问题，是否可以成功回滚；
6、质量关注点不同，标注出来是功能、性能、安全关注点等；
7、性能测试基线是什么、可靠性怎样；
8、安全基线是什么、0Day
9、自动化框架怎么运行、可以运行被测目标哪方面、缺陷在哪里
10、产品上下游关系如何、对软件、硬件的依赖如何、出现问题对上游有什么影响、比如数据库等；分布式Doker生产环境；哪些需要Mock、如何Mock；
11、E2E端对端如何设计、测试流程
12、测试可测性分析、哪些部分可测、覆盖情况、预估缺陷有多少；
13 测试计划执行时间、依赖于产品执行时间、测试内容、难点、人力；与开发、测试协商；
14、测试的依赖 测试资源有多少、技术水平如何、开发可否支持、是否可提供自动化支持；
15、文档、附件、

平台测试-环境搭建-生态测试
互联网对隐私强，公开性

1、用户角度验证，互联网测试关注的是用户角度的测试数据，用户角度验收、E2E端对端要加强；
2、技术角度验证，比如崩溃后重启恢复到最初位置；
3、ADhot交叉测试, AD-HOT测试是指随机测试,这种测试的特点是无特定的测试用例,无需记录测试过程及结果。测试过程类似于无思考能力的“猴子”在随意使用被测软件,
4、试用：稳定版对应的开发版本；
5、灰度测试：短时期内预发环境使用者较少，给协议用户或内部人员试用；

敏捷测试：自由、节奏快、变化快、可以参考不要照搬其他人的测试计划

开发开始设计产品是就开始考虑测试，对开发进行一定的约束；

考虑自动化成本，开源、购买功能？ 人力成本 手动、测试开发、开发等
测试框架Selenium +IE、chrome、火狐；对双核、360等自己的不支持，面不够全；
LR、JMeter请求级别的、交互式的性能测试；
流量层的底层等监控、性能测试就不能使用LR、JMeter了

互联网很少能有面上全的测试；
覆盖面的量
自动化测试的收益
接口自动化功能、性能（更适合数据驱动、场景驱动），收益很大比UI（Form+Web）自动化；
自动化离不开手动测试

测试框架是一个解决方案；
系统框架：浏览器IE、Chrome、
应用框架：Selenium、
工具框架：Junit、Nunit、TestNG、包含最基本的调度；

UI自动化：Web页面的自动化、元素操作,操作方式就是场景；Form变化快使得定位OLE、MSA、COM、
WebDriver、Selenium、

接口自动化：标准的数据驱动层的、接口之间相互依赖形成场景，场景驱动；
测试用例：自动生成、开发支持提供、测试自己开发、外包；

持续集成：CI

性能测试：健康态、饱和态
用户状态： RT、QTP、
服务状态：CPU、IO、Memory、NetWork、长链路中那一层是瓶颈、
开发态：数据库[LOck状态、分表、分页、]
业务态：吞吐量、PV

负载性能：饱和态75%下进行；
压力测试：80%下；
稳定性：健康态50%下进行

stepload不断的给系统加压、做一个极限评估，
环境拓扑、每个链路的关系、结构图、
接口图、链路关系、
1、总结分析、问题描述、环境描述、链接、
2、首先用-图表-显示，其次表；

安全测试：
Web安全测试：技术层面的安全、SQL注入、后端代码、文件的生成下载漏洞、
网络层面的安全：网络震动（网络运营商）、设备系统的交互（华为防火墙）
系统安全：
网站公共安全：
业务安全：隐性需求、灰色地带；
安全测试重点：
常见手段：黑白名单、最小权限、尽量后台代码无可预测性字符、开放式设计采用国际上；
使用网上的工具进行渗透、攻击；
扫描、人工审查代码、多层交互、
设计中的安全：

测试管理：
平台流程控制：需求、发布管理、文档管理、
BugFree 找到最适合实际、把握住最主要需求、次要需求可以迁就工具或者自己扩展、
测试方法申请专利、Selenium WebDriver是系统级别的测试，用户级别就是鼠标点击、键盘操作；
Bugzila
克鲁德
测试思维创新：

度量控制：