Web项目测试基本思路
2017-07-19 18:47:08 0 举报AI智能生成
测试小白总结的web项目的测试思路，请大家多多指正，不吝赐教。
作者其他创作
大纲/内容
Web项目测试基本思路
需求分析
新项目上线
需要分析业务并优化，尽量少占用和浪费系统资源达到预期的效果
分析考虑客户体验和开发实现
需要先预估最低并发分析，做好基准测试方案设计
旧项目优化
参考旧项目的历史测试方案
测试环境
测试工具准备
项目管理工具
禅道，tower，伙伴云表格等
功能测试工具
fiddler等
接口测试工具
jmeter，fiddler，httpRequester，postman，loadrunner等
性能测试工具
jmeter，loadrunner等
持续集成工具
ant，Jenkins，maven等
被测项目环境
服务器/中间件
Tomcat
Apache
Nginx
数据库
MySQL，Oracle，SQL server等
Redis
Linux环境
JDK
Python
项目部署
接口测试环境
开发的联调环境可用
功能测试环境
持续集成搭建，满足测试的基本使用
预上线测试环境
模拟线上环境，为基准（性能）测试做准备
数据部署
测试环境数据
支持历史数据兼容
支持开发接口数据
预上线环境数据
线上数据同步
性能工具接口增加
测试计划
接口测试
编写测试用例
请求方法
请求路径
请求参数
必填项
轮流置空
边界值法
非必填项
测试结果
编写测试脚本
单个用例验收测试
集成用例回归测试
用例执行成功保存，预备性能性能测试
功能测试
精简剖析业务
客户体验
黑盒UI
编写用例
分析业务类型
功能点剥离
前置条件
校验规则
性能测试
针对业务量较大的流程设计用例
主要的流程需要注意前置条件
集成接口测试保存的脚本
添加并发用户设置
性能测试分类
并发测试
并发测试可以理解为很多的用户按照预定的场景并发请求某个业务或功能时是否会出现并发问题。几乎所有的性能测试都会涉及并发测试。并发测试的主要目的是找出并发引起的问题。
负载测试
负载测试可以理解为确定所要测试的业务或系统的负载范围，然后对其进行测试。负载测试的主要目的是验证业务或系统在给定的负载条件下的处理性能。负载测试还需要关注响应时间、TPS和其他相关指标。
压力测试
压力测试可以理解为没有预期的性能指标，不断的加压，看系统什么时候崩溃，以此来确定系统的瓶颈或者不能接受的性能拐点，以获得系统的最佳并发数、再打并发数。压力测试可以看做负载测试的一种，即高负载下的负载测试。
稳定性测试
稳定性测试就是长时间运行，在这段时间内观察系统的出错几率、性能变化趋势等。进而大大减少系统上线后的崩溃等现象。一般持续的时间为N*24小时。稳定性测试注意事项1 一般稳定性测试需要在系统成型后进行，并且没有严重的bug存在。2. 场景的设计以模拟真实用户的实际操作为佳。
基准测试
基准测试是一种衡量和评估软件性能指标的活动。你可以在某个时候通过基准测试建立一个已知的性能水平（称为基准线），当系统的软硬件环境发生变化之后再进行一次基准测试以确定哪些变化对性能有影响。
配置测试
配置测试是通过调整系统软/硬件环境，了解在不同环境下系统性能指标的情况，从而找到系统的最优配置。
失效恢复测试
失效恢复测试重在关注系统出现问题后能否根据预先制定的策略恢复，且恢复后能否正常运行。失效恢复测试一般针对有负载均衡的系统进行，主要是为了测试系统局部发生故障时，是否会对全局产生大的影响，产生的影响是否在可以接受的范围内，以及用户是否能继续使用系统。
现网性能测试
现网性能测试，就是在实际网络、实际环境中进行测试，完全和真实用户一样。现网测试注意事项：1. 时间段的选择。2. 垃圾数据处理。3. 网络限制。
测试实施
接口测试执行
收集测试结果，通过邮箱发送测试报告
功能测试执行
收集测试结果，反馈开发
性能测试执行
保存测试结果
调优参考依据
容量规划依据
回归测试
收集接口测试返回结果，针对性的设计用例执行
收集功能测试返回结果，针对性的设计用例执行
性能性能测试返回结果，针对性的调优
UI自动化
在公司投入的许可下，可以使用UI级自动化投入回归测试
测试目标
保证接口的稳定性
保证业务的正确性
保证业务的使用正确性
保证客户体验的易用性等
性能目标
需求预估流量
查找性能瓶颈
做好性能优化
性能结果分析
TPS、响应时间、错误率
磁盘状况，内存状况
perf日志
监控调优
前端
页面请求数量
尽量减少页面不必要的请求
零散的小图合并成大图传输
合并压缩CSS样式表和JS脚本
网络环境
增加带宽，优化DNS寻址，优化网络环境等
减少DNS的查询次数
部署CDN服务节点发布静态资源，减少网络拥堵状况
每个请求的内容大小
尽量减少请求的内容大小
图片尽量保存为png格式，能优化图片尽量优化
使用无cookie域名
在www.*.com上设置cookie，利用static.*.com存放静态资源（或者购买另外域名）
加载渲染机制
利用缓存机制，增大资源失效时间，较少重复资源请求
内容排版
图片延迟加载
尽量使用外部CSS样式和js
CSS样式表引用放在头部标签中，避免使用CSS@import
内部的js尽量放在页面的尾部加载（控制页面内容写入的除外）
大量的计算逻辑后台服务端处理
移除重复脚本
MySQL
索引优化
作为主键的列
经常排序的列
经常使用where子句的列
SQL语句优化（慢查询，explain命令）
减少使索引失效的现象
大SQL分解成一个个小SQL
其他注意子句函数的使用
减少无用字段的查询
注意临时表，游标，存储过程，触发器的使用
避免大事务操作
数据量过大优先使用分页
存储引擎
MyISAM
MyISAM 不支持事务和外键，适用于对事务完整性没有要求或者以 select 、insert 为主的应用
InnoDB
如果应用对事务的完整性有比较高的要求，在并发条件下要求数据的一致性，有大量的增删改查操作，支持外键使用 InnoDB 比较合适
MEMORY
MEMORY 存储引擎使用存在内存中的内容来创建表。每个 MEMORY 表只实际对应一个磁盘文件。MEMORY 类型的表访问非常得快，因为它的数据是放在内存中的，并且默认使用 HASH 索引。但是一旦服务关闭，表中的数据就会丢失掉。
数据类型结构优化
尽量使用数字型字段
尽可能的使用 varchar/nvarchar 代替 char/nchar
注意数据库死锁，备份，还原
数据库架构优化
主从复制
读写分离
分库分表
数据库配置参数优化
Linux
iostat
vmstat
netstat
top
监控
server-status
linux命令
调优
工作模式
Prefork
Worker
参数
Timeout
KeepAlive
过期时间
gzip
HostnameLookups
Nginx_status
网络 I/O 模型
Nginx 采用的是 epoll 网络 I/O 模型
Apache 所采用的select网络I/O模型非常低效
HTTP 模块
Tomcat_status
JVM区
HTTP区
Max threads: 最大可以承载的线程数（重点）
Current thread count: 当前线程池的线程数
Current thread busy: 你访问服务器这个点处于 busy 状态的线程
Max processing time: 单个请求的最大处理时间
Processing time: 请求总的处理时间
Bytes received: 收到的字节数
Bytes sent: 发送的字节数
Request count: 总请求数
Error count: 发生错误的请求数
运行模式
nio
tomcat 在 linux 上，默认使用的是 bio connector
bio
与 nio 相比，bio 性能较低，切换为 nio
关键参数
URIEncoding=\"UTF-8\"
minSpareThreads=\"25\"
enableLookups=\"false\"
useURIValidationHack=\"false\"!--减少它对一些 url 的不必要的检查从而减省开销
connectionTimeout=\"20000\"
最大连接数
JVM
监控工具
Jconsole
Jvisualvm
JProfiler
MAT分析内存快照
内存
JVM参数（重点）
Java线程池
连接池
程序算法
发现问题
内存溢出
热点CPU
TreeNMS for Redis
设置maxmemory（当成数据库使用忽略）
增大物理内存
设置key的过期时间
设置过期策略
maxmemory-policy过期策略
maxClients 设置同一时间最大客户端连接数，参数设置为监控的110%--150%
tcp-keepalive 设置超时时间
rdbchecksum 检查数据的正确性（默认yes，改为no）
auto-aof-rewrite 持久化在线实时数据重写auto-aof-rewrite-percentage（默认100改为0）
appendonly 指定是否在每次更新操作后进行日志记录，默认no改为yes
slowlog-log-slower-than 慢查询 10000微秒 负数的时候是关闭的
slowlog-max-len 128 固定慢查询日志记录最大为128
延迟时间
maxClients 预期连接数的110%--150%
内存给redis大一点
系统内核参数
vm.overcommit_memory=1\t尽可能多的让redis使用内存报错redis is not save snapshots的时候需要加上上面的参数
容量规划
场景
未来做大规模推广，流量上升N倍
按照领导要求
运营数据提供
目前系统状况（峰值）
在线用户
页面刷新
吞吐量
页面数据分析
性能瓶颈
CPU
IO
单台机器能力评估
作为基准
支撑动态请求数量
支撑静态资源流量
预估动态支撑（计算速度）
统计数据作为参考
分析业务模型：未来%或者几倍增长速度
单台机器支撑性能能力
预估机器数量=未来数据/单台基准
预估静态支撑（网络带宽）
预估每个页面的静态文件数量每个文件大小
预估目前带宽页面刷新数/3600S文件个数文件大小
预估峰值的静态流量
预估静态服务器数量
收藏
0 条评论
回复 删除
下一页
