软件测试__基本知识

（1）测试思维（什么是测试）
       1.需求测试（是一个文档，需求是产品经理负责）
       2.界面测试：（也叫外观测试，或者ui测试，）
       3.功能测试：验证产品是否达到客户的需求
       4.安全测试（脱敏测试）：软件安全测试-木马、病毒、数据泄露、网络
       5.可靠性测试：为了评估一个产品在规定寿命、预期环境下验证产品的寿命
       6.可移植性测试：设计程序与硬件、软件之间的兼容性测试
      7.兼容性测试：ios、andrioid、windows
      8。易用性测试
      9.压力测试
      10。负载测试
-------------------
eg：1.杯子的测试点
2.给你个链接怎么测
3.微信朋友圈测试点
需求/功能：是否能发送朋友圈，删除朋友圈
                   发送朋友圈后，好友是否能正常看到  
                   删除朋友圈后，好友是否能正常看到
                   发送图片时，好友是否能看到
                   是否能指定好友看到
界面：文字字体，大小
           能否选择照片，还是纯文字
可移植性：在手机，电脑上能否发朋友圈
兼容性：在不同的系统中是否能正常发送
可靠性：断网，2.3.4G网络下能否发送成功
安全性：非好友能否看到
易用性：编辑时，闪退后，是否有自动保存
压力测试：反复发送，删除朋友圈是否闪退

服务器退出，服务器中断

4.如何测试购物车
5.微信点赞测试点

需求：是否能点赞
界面：图标，大小，颜色
功能：点赞，取消点赞，取消时效
安全：是否泄露个人信息
可靠性：断网，2.3.4G下是否能点赞
可移植性：不同电脑手机下是否能点赞
兼容性：不同系统中
易用性：点赞标识是否清晰，易找
压力测试：过于频繁闪退，最大点赞数量，闪退

6.二维码怎么测试
需求：文档
界面测试：外观大小，颜色
功能测试：收付款
安全性：安全提示
可靠性：断网，2.3.4G,二维码失效，角度
不同系统是否可扫

7.电梯的测试点
需求：文档
界面测试：外观大小，颜色
功能测试：是否上下楼层
安全性：报警，应急灯
可靠性：下雨，高温是否正常
可移植性：室内，室外是否可以
兼容性：不同区域
易用性：载重量，盲人，扶手
压力测试：最大载人量

8.空调的测试点
9.一支笔如何测试
10.支付的测试点

-----------------------------
常见的基本术语：
硬件：计算机各种设备的总称，CPU、主板、鼠标等
软件：电脑启动时系统软件
硬件软件关系：互相依存、无严格界限、协同发展
pc机：指个人电脑
物理机：相对于虚拟机而言的对是实体的称呼
虚拟机：建立在物理机的基础上
os系统：操作系统

--------------------------------
dos命令
打开输入命令界面 win+r 输入cmd
ipconfig-查看ip地址
ipconfig/all 查看mac地址
盘名：--切换盘符
dir--查看当前目录下所有文件
cd 文件名 ---进入文件
cd..--返回上一层目录
cls--清屏
rd 目录名--删除目录

----------------------------------------
BS架构和CS架构
B：broser
S：server
C：clinent
bs：表示浏览器到服务端（web）---应用在豆瓣、博客园、论坛
cs：客户端到服务端（app）-----应用在抖音、微信、qq

BS架构不需要下载app更新，直接通过浏览器进行网址访问，CS需要下载客户端、定期更新
BS架构对服务器性能要求高，CS架构客户端为服务端分担部分性能
BS架构不占用存储内存，CS会占用存储内存。
CS:优点：手机携带方便，操作简单，上传下载快，安全性高；
     缺点：需要安装升级app，服务器相对比较难维护

BC 优点：直接访问，服务器好维护，信息量比较大，资料多
     缺点：安全性不高，信息容易泄露，容易中病毒。


===================================

人员架构

CEO（首席执行官）
CTO（首席技术官）
PM（项目经理）：从软件开发到上线负责人
产品经理
开发经理-开发人员
测试经理-测试人员（自动化测试、性能测试、安全测试）
cmo运维：搭建环境，部署环境
--------------------------------
题：1、你们公司规模多大？回答项目组有多少人
一个项目组大概20-30人

2，你们公司测试多少人？
3-4，大型公司10几个

3，你们项目组有哪些人？
项目经理，开发，测试，产品，产品经理，测试经理

4，你们公司搭建环境？
运维搭建

5，前端后端开发人员多少？
参考数据
26个 后端15 前端3 测试4 运维1 产品3

===================
为什么要软件测试？
1.软件本身运行就会出错
2.代码是人写的，人就会出错
3.环境影响软件
4.软件测试来保证软件质量的一种方法

软件的生命周期：7
1.客户问题引入、定义
2.可能性分析
3.项目招投标
4.项目立项
5.需求分析
6.开发阶段（设计、编码、测试）
7.维护

什么是测试？
1.验证软甲的正确性
2.发现软件中的缺陷

测试基本原则：1.测试的标准是用户需求
2.测试不仅仅是软件本身（比如环境）
3.软件外在没有失效，不代表可用
4.软件是没有完全正确的，只有更加正确和完美
5.穷尽测试是不可能的
6.测试应该尽早介入
7。二八原则（80%的缺陷或错误会集中在20%的区域）
8.杀虫剂效应（要不断更新用例，因为反复执行相同的测试用例不会发现新的缺陷）
9.测试活动依赖测试对象（功能、性能、安全）
10.尽量第三方测试
=============================
测试分类
一、开发阶段划分
  单元测试、集成的是、系统测试、验收测试
二、是否查看代码
1.黑盒测试：只关注输入输出不关注代码
2.白盒测试：结构测试，关注重点是代码
3.灰盒测试：介于白盒和黑盒之间
三、是否运行划分
1.静态测试
2.动态测试
四、测试对象划分
1.功能测试
2.性能测试
3.安全性测试
4.兼容性测试
5.业务测试
6。文档性
7.界面测试
8.安装测试
五、按照测试实施的组织
a测试（aplha testing）
B测试（beta testing）

六、安装测试是否手工执行划分
手工测试
自动化测试
七、按照测试地域划分
国际化测试和本地测试

====================================
典型软件生命周期模型？
V模型
H模型
敏捷开发模型
瀑布模型：太浪费时间和财力
W模型
迭代开发模型
增量开发模型

---V模型
单元测试（UT）
集成测试（IT）
系统测试（ST）
验收测试（UAT）

集成测试和系统测试合并：系统集成测试（SIT测试）

第一阶段：单元测试
     验证软件单元是否满足文档的规格，能正常执行名主要对代码进行测试。
     单元测试是最小的测试单元
     在工作中单元测试一般是开发自测，如果需要测试进行单元测试，对测试的技术要求非常高

第二阶段：集成测试
--集成测试是指多个
--验证软件是否满足概要设计文档的规格。能正常执行。
--主要测试是模块与模块之间的数据交互

第三阶段 系统测试
--把软件进行正常的运行，对整个系统进行测试，验证系统能正常运行，主要测试一个整体的业务流程

第四阶段 验收测试（UAT测试）
验收测试：站在用户的角度对系统进行测试，验收系统满足客户需求
验收测试分为两种：alpha测试：内部测试
                             和bate测试：第三方测试
区别：
1.测试地点不同  alpha 测试：在公司    bate测试:客户方
2.测试人员不同 alpha测试：内部技术人员测试，开发在场及时发现bug并处理
                        bate测试：客户方的员工测试，发现问题反馈给开发解决
3.测试时间不同： alpha测试：时间短，测试人员集中
                           bate测试：时间长，测试人员不集中

需求分析：软件需求规格说明--简称SRS

概要设计：简称HLD是一个文档
构架设计，说明架构数据库类型，架构的描述，设计，模块和模块名称。

详细设计：简称LLD也是一个文档
内容：针对具体功能实现文档，模块功能实现，具体的设计，具体描述

W模型是V模型的补充
=======================
H模型
SRS需求规格说明书（产品经理）
召开需求会议（产品主持）：澄清需求   参会人员：测试、开发、产品
测试经理：分析需求，编写测试计划

测试计划内容：简介（目的，背景，范围） 测试约束（测试准入，测试准出）环境资源（人力资源配置），测试环境配置
，测试任务进度，测试交付文档
测试准入：sit、uat阶段 开发人员提交

测试人员：我们开始分析需求，编写用例

评审用例：组内评审、交叉评审

用例管理工具管理用例

搭建测试环境：

开发测试：

将代码部署到测试环境
冒烟测试：对新版本的主要功能，基本功能进行测试。

sit1测试（站在用例的角度上：全量测试）执行所有测试用例

回归测试：系统维护阶段，对原有的用例，bug进行再次验证，我们称为回归测试

sit2测试：冒烟测试通过，继续测试

第二次sit测试的用例：（1）冒烟测试用例（2）验证上个版本出现的bug用例（3）测试与bug相关联的模块用例
（4）你认为可疑的测试用例或者测试场景 （5）测试补充的测试用例或场景

sit测试完成-通知uat测试
验收完成
封装版本包
提前准备上线数据
等待上线
上线后，在线上进行测试，测试新的版本没有问题，上线成功

上线后发现bug，怎么处理？
测试有bug，先记录，和开发或领导沟通，评估对项目的影响，如果影响小，备注修改版本，如果影响大必须退回处理

================
总结：
拿到需求=编写测试计划=编写测试用例=用例评审=用例导入项目管理工具=搭建环境
=开发转测试=部署环境=冒烟测试=sit1系统测试=有bug提给开发，开发修改，自己小结
=第二次冒烟测试=sit2系统测试=有bug提给开发并做好小结=第三次冒烟=sit3系统测试
=达到准出要求，输出测试报告=通知uat测试，测试通过=封装版本=准备线上数据=上线=线上测试=上线成功

doc命令
1.ipconfig 查看ip地址
2.ipconfig/all查看mac地址
3.盘名：切换盘符
4.dir查看当前目录下所有文件
5.cd 进入目录
6.md 文件名 创建目录
7.cls清除屏幕
8.rd删除目录

拓展：cd命令只能进入当前盘符中的目录，其中cd / 表示返回到根目录

c/s and b/s架构区别
bs：浏览器到服务端
cs：客户端到服务端

bs架构的应用：博客园、豆瓣、论坛
cs架构的应用：抖音、微信、qq
关系：
1.bs架构不需要下载更新，直接通过浏览器输入网址进行访问，cs需要下载客户端使用，需要定期进行更新
2.bs架构对服务器性能要求高，cs架构客户端为服务器分担性能
3.不是架构不会占用存储内存，cs会占用存储内存

cs优点：手机携带方便，操作简单，上传下载比较快，安全性高
   缺点：需要安装升级app，服务器相对比较难维护
bs优点：直接访问，服务器好维护，信息量比较大，资料多
   缺点：安全性不高，信息容易泄露，容易右病毒