三天笔记

软件测试是什么？
就是发现软件当中的缺陷bug 验证软件的正确性


需求测试：
需求是谁提出来的？
客户提出来的
需求是谁进行编写的？
需求是由产品经理进行对接客户整理输出来的
它分为那种形式？
第一种：需求规格说明书（文档形式）
第二种：原型图
怎么测试需求？
对需求文档以及原型图进行详细阅读，测试他的这个需求是否又存在矛盾的地方，我们项目组的技术能否实现这个功能需求，他的业务逻辑是否有存在矛盾的地方
需求测试会涉及到需求评审会议：
需求评审会议是由产品经理组织会议的，参与会议评审的人员包括项目组所有组成员


界面测试：
界面是由谁设计的？
是由ui设计工程师设计的 ue ued 输出一份高保真图
界面怎么进行测试？
测试人员根据ui设计师输出的高保真进行测试 参照高保真图对软件的界面（布局排版，字体，字体大小，背景，颜色）做一些检查，是否跟高保真图一致


功能测试：
点点点测试：
功能测试：黑盒测试  理解为一个盒子，我们看不到底层代码设计结构只能针对盒子外部的一个功能进行检查
                  白盒测试  透明盒子测试--单元测试（开发进行的测试），对代码功能检查
测试用例（就是我们编写测试的方法流程）
                  灰盒测试  api（接口）测试


安全测试（专项测试）：
第一种：系统级别的安全性问题  测试方法（xss，sql注入）
第二种：用户信息安全方面考虑；例如用户信息脱敏一系列操作


可靠性测试：我给一个指标，查看软件的运行结果，是否符合要求
可用性测试：程序可以被运行的，可能达不到预期的指标
可靠性包含可用性测试 可靠一定可用 可用不一定可靠


可移植性测试：
        例：华为应用商店 vivo商店 小米应用商店 进行下载软件进行运行，查看运行状态，他是否可以运行 环境也会产生bug 不同的环境运行的结果可能不一样
项目组当中的环境：
开发环境：开发进行编译代码coding的环境，进行单元测试的环境
测试环境：我们测试人员进行测试检查的环境，所有开发完成的项目都会部署在测试环境当中给我们进行测试
预发布环境：产品即将上线，模拟的线上产生环境的一个环境，预发布环境就是生产环境前进行测试的一个环境
线上环境（产生环境）：就是提供给真实用户进行使用一个环境，是用户进行验收的一个环境


兼容性测试：
p c操作系统：win mac linux uinx
手机操作系统：安卓 ios 鸿蒙
手机操作系统的版本：ios5-ios13  
浏览器的兼容性：chrome 火狐浏览器 uc ie
手机不同的品牌：vivo iPhone 华为 小米
兼容性测试，测试软件在不同的操作系统，不同的手机平台下的一个状态。


易用性测试：测试这个软件用来是否贴合用户的使用习惯，是否好用


压力测试：
什么是压力测试？
不断对软件施加压力看软件的性能瓶颈在哪里
例如：淘宝登录接口。不断的施加压力（增加同时访问登录人数）测试它的极限在哪里
负载测试：
什么是负载测试？
负载测试就是承受一定的压力，进行运行。看他能够持续运行多长时间
   压力测试和负载测试都隶属于性能测试  性能测试也是专项测试（专门负责一项业务测试工作）





it的基本术语：
软件与硬件：应用软件；
                      系统软件；
                      硬件：电脑 u盘 cpu
pc机：个人电脑
物理机：可以理解为配置比较高的电脑，一般作为应用的主机
便携机：一般应用于工程类，外形比较坚固，耐用抗摔。
os：操作系统
dos命令与图形化界面
dos命令的打开方式：win+r 输入cmd 菜单开始输入cmd
共享：我把一个东西的知情权使用权分享给你
文件与文件夹
   文件夹：互联网行业统称目录
   文件：文档 视频 代码 图片
目录与路径：
   目录：文件夹的意思
   路径：
              绝对路径：从最开始的地方一层一层走直到目标位置                         \：表示最开始的位置
              相对路径：可以从路径当中的任意一个点进行出发直到目标位置         .\表示相对路径的意思
客户机与服务器：client（客户机）server（服务器） c/s c端产品  
浏览器与服务器：browser（浏览器）server（服务器）b/s b端产品
  c/s架构与b/s架构的区别：
    1.c/s产品需要下载进行安装使用  时常更新
    2.b/s只需要通过ip地址域名进行访问
    3.c/s产品占用本地资源
    4.b/s不用占用本地资源
    5.c/s对服务器的要求对b/s要高
    6.c/s安全性比b/s要高
    7.c/s使用方便
    8.b/s获取的资源要比c/s丰富、多
单机软件和共享软件：
    单机软件不需要链接局域网
    共享软件需要网络
项目与项目需求：
    项目可以理解一个工程；
    项目需求：开发人员（先端开发、后端开发、ios开发、安卓开发）
                      具体项目完成周期
                      项目完成的指标（要达到某种程度）
                      项目组人员工作任务安排
客户与客户需求：
    客户是提出需求的人；
    客户需要干什么（要进行具体事务）
项目角色：
    项目经理：pm（project manager）统筹整个项目的工作进度和安排
    产品经理：负责对接客户，输出需求文档以及原型图
    ui设计师：负责软件的页面设计
    开发人员：
                       前端开发（负责项目前端开发设计）
                       后端开发（负责后台逻辑以及接口的开发工作）  
                       ios开发（开发ios应用程序-小程序）   
                       安卓开发（开发安卓应用程序-小程序）              
    开发组长：前端开发组长管理前端开发（工作任务的安排）
    开发经理：统筹整个开发项目组
    测试经理：tpm（test project manager）统筹整个项目组测试人员工作
    测试组长：tl（test leader）一个测试组长管理一个或者多个项目平台，负责安排测试人员，任务的调度
    测试人员：te（test engineer）主要负责软件的测试工作
    运维人员：管理公司的网络安全方面，还有环境搭建和维护
    架构师：负责整个项目的组底层开发架构，开发框架的设计
    数据库管理员：dba（data base administrator）负责公司当中的数据处理情况



为什么要测试？
1.软件的非正常运行或其自身的缺陷（BUG）会 引发很多问题。
2.软件是由代码和文档组成的，而这些都是由 “人” 来设计和编写的，人都有可能犯错。
3.环境也会影响软件，以致出现软件“失效”现 象。
4. 软件测试活动只是关键的质量保证活动之一
    异常测试---->从不同的角度去违反软件的规则

软件是代码和文档组成的？
    一个软件的产生，他是包含很多文档组成，需求规格说明书，概要设计说明书，详细设计说明书，测试用例文档，测试报告，测试计划等
   通过代码实现文档当中标注的功能。

环境也会影响软件，以至出现软件"失效"现象
     在其他环境进行验证的时候没有问题，放在产生环境就出现了问题。一些环境的配置（服务器配置，软件硬件等等）也会引发许多问题，也会导致软件无法使用

软件测试活动只是关键的质量保证活动之一
    还有那些也是保证产品的质量？
    开发编译的代码的规范性吗，也是保证软件的活动
产品经理进行编写需求规格说明书规范，也是保证产品质量活动

通常软件生命周期包括那些阶段？
1.客户问题引入或定义：
    产品经理进行引入客户需求。
2.可行性分析
    涉及经济：1.我生产这个软件是否能够带来具体的经济效益
                      2.我项目组的资金能否支持这个项目的运转
    政治：不能设计政治相关的敏感话题
    法律：不能从事黄赌毒。
    技术：我们这个项目组的技术可不可以实现这个需求
3.项目招投标：
    项目组发布公告吸引有资质的单位来承包项目组的一部分开发工作
4.项目立项：
    开始招聘人员，制定工作计划，制定产品标准，分配工作
5.需求分析：
    通过产品经理整理的需求文档进行分析，需求当中存在的逻辑的问题矛盾的地方产品经理然后进行修改直到所有的项目的成员意见达成一致，形成一个可执行的文档。然后继续分析需求文档。从需求当中提取到我下一步的工作计划。
6.开发阶段
    设计阶段：开发进行设计概要设计文档/详细设计文档，测试人员进行设计测试计划-测试用例文档
    coding编码阶段：开发进行编写代码
    测试阶段：测试执行阶段（执行编写的测试用例）找bug 对应的开发人员进行修复。直到所有的bug关闭，进行上线给用户使用
7.维护阶段
    1.持续根据用户反馈的问题进行优化和解决
    2.开发的代码维护不断的更新
    3.测试用例的脚本也需要维护


一个完整的项目流程包含哪些阶段？
需求搜索：由产品经理进行需求的搜索工作，然后整理成一份可以执行的文档。
需求分析：  
    1.分析这个需求是否又存在矛盾的地方。逻辑错误的地方，以及提炼下一阶段工作开展方向
概要设计：简称hld
    他是由谁进行设计的？    开发人员进行设计编写
    对项目的系统配置以及开发具体的框架进行设计
详细设计：简称lld
    也是由开发人员进行设计的。
   设计项目的具体模块内容和设计编写接口
开发编码：
    开发在快发环境进行程序的开发工作
单元测试：白盒测试---透明盒子测试---开发人员进行自测
                  白盒测试具体方法：
                      六种方式：
                          语句覆盖：所有可以执行的语句都需要运行一次
                          判定覆盖：所有需要进行取值的判定节点都需要运行一次
                          条件覆盖：所有运行出现的结果都需要运行一次
                          判定条件覆盖：所有取值可能出现的结果都需要运行一次
                          条件组合覆盖：所有条件进行组合运行一次                          
                          路径覆盖：所有含概的路径方法都要运行一次
冒烟测试：
    冒烟测试是测试人员执行的第一轮测试。
    这个项目的主题功能是否能运行。
    冒烟测试如果测试不通过，直接打回开发进行修复然后进行自测。自测完成之后再一次执行冒烟测试，直至冒烟测试通过

系统测试：it测试
    系统测试，针对系统的配置以及性能等，功方面进行测试。

集成测试：st测试
   也叫组装测试--->模块与模块之间的交互问题
   也针对api进行测试。

系统集成测试（sit）
   全量测试（全方位的测试包含it--st阶段内容）

回归测试（sit1）
    针对上一轮产生的bug做验证测试，这个bug是否修复，这个bug相关联的一些模块也需要进行测试，看有没有产生新的bug
    回归测试关闭条件，所有用例都已经执行通过 所有的bug修复率达到了百分之百九十八就可以关闭回归测试，遗留的bug必须是建议bug 不会对这个产品产生奉献项，才可以关闭回归，进入验收阶段
    回归测试通过，编写sit系统集成阶段的测试报告
        1.包含你的所有测试用例
        2.包含测试过程中所有出现的bug
        3.包含所有遗留的问题以及对于风险
        4.此次测试的总结

验收阶段：
    α alphc 验收：
       他是在非正式环境进行验收----在模拟的预发布环境进行验收。项目的所有组成员在场，出现问题及时进行修复。验收通过发布线上给用户进行使用。
    β beta 验收：
        在正式环境进行验收----会挑选一个时间进行验收
        验收人员包含产品，测试开发。发布正式环境之后由测试人员进行新一轮测试，测试没有问题的话就直接交由用户进行验收使用
假如你发布的时候碰到bug怎么办？
    1.首先分析这个bug修改时间需要多长时间，及这个bug的等级如果说这个bug修复时间可控，那么就在当天晚上进行修复，再次进行发布
    2.bug太严重了，开发人员不确定修复时间，及时进行回滚（恢复到上个版本），取消上线发布，然后在进行修复，修复完成之后测试进行测试。测试通过在选择一个时间进行发布

静态测试：不需要运行程序，对程序的代码以及文档进行静态走查
动态测试：通过运行程序来发现程序当中的一系列问题
    分为白盒测试和黑盒测试，都需要通过运行来检查
手工测试：以用户的角度来检验产品是否符合它对应的需求，点点点，属于黑盒测试的一种
自动化测试包含哪些内容：

典型的生命周期开发模型有哪些？    1.瀑布模型（waterfall）        19070年提出  瀑布模型的特点：            1.瀑布模型是阶段性的展开的，一个阶段的完成才进行下一个阶段直到项目结束            2.能够清晰开发周期的全部过程。明确标注了每个阶段的任务。            瀑布模型： 优点 适合大型的项目                               缺点 1.不够灵活，需求如果发生变动，返工的代价比较大。                                        2.项目的前期很难看到实际效果                              适用的项目：大型项目；需求稳定的项目    2.v模型        v模型是一个串行结构的模型，它包含了测试的所有行为也包含单元测试。测试的行为有了参考的依据。        输入：用户需求       输出：需求分析        输入：需求分析       输出：概要设计（系统的配置大概功能，系统开发框架设计）        输入：概要设计       输出：详细设计（各个模块之间的api设计，以及）              输入：详细设计       输出：编码coding              输入：编码              输出：单元测试（白盒测试。开发进行自测）              输入：单元测试       输出：集成测试 （模块模块之间的）        输入：集成测试       输出：系统测试 （安全、性能、功能等方面测试）         输入：系统测试       输出：验收测试（α、β验收两种方式）        v模型的优点：           1.它涵盖了所有的测试行为           2.测试有了参考的依据        缺点：           1.测试行为依旧在开发行为之后，前面放生的一些问题测试并不清楚    3.w模型        w模型是v模型的延申，但是依旧是个串行结构测试的接入的项目时间提到需求分析阶段        w模型的优点：            1.贯穿了整个项目的开发周期模型            2.测试行为提升到需求分析阶段能够尽早的发现项目当中的问题            3.开发与测试进行并行开始，可以加强开发与测试的合作关系        缺点：            1.实际的工作场景当种并不会产生实际性的文档            2.编写文档对开发来收要求比较高            读懂实际文档对测试来说要求比较高    4.敏捷开发模型：        1990提出的开发模式：        敏捷开发模型他的交付周期（星期）        强调人与人之间的沟通        能够快速适应需求的变化。        测试时间不足，会导致测试不是很全面。    5.迭代开发模型        项目被分为大量的迭代过程，一个迭代过程就是一个开发的生命周期，迭代的子集可以单独    6.增量开发模型    7.h模型        srs需求规格说明书---澄清会议        所有项目组的组成员对需求规格说明书进行评审        1.开发分析整个需求可行性，以及设计方法        2.测试分析整个需求可行性，这个需求有疑问的地方进行指出，需求存在矛盾进行提出        3.分析这个需求的时候开发需要得知自己的开发大致周期，测试人员得出自己测试这个产品的大致周期开发线：        概要设计：系统方面的设计，包括系统开发框架的设计，这个项目的大致的主体功能，以及数据库结构的设计
详细设计：模块与模块之间的接口设计，主体功能子模块的详细设计实现的方法与思路
coding编码工作：制定完成交付周期。
        单元测试：白盒测试（开发自己在他自己的开发环境进行代码的走查）测试线：继续了解需求文档，罗列出需求当中的测试点        然后根据罗列出现的测试点，转换为测试用例tpm设计制定测试计划：分配测试工作，相关项目模块划分                1.测试人员根据所划分的模块，书写相关模块的测试用例输出测试用例初稿：        用例评审：用例评审得到目的：评审你所书写的测试用例，是否又存在遗漏的地方，有的话进行补充，再次评审。用例没有问题，那么就形成最终执行文档。组内评审：测试组所有测试人员进行评审交叉评审：负责同一个项目的测试人员之间进行交互评审会议评审：包含测试经理，产品经理，开发等等所有项目组成员对写的用例进行评审。用例评审是由测试人员进行发起的                        2.tmp将用例的极限文档导入到用例bug管理工具，并将用例进行分配用例bug管理工具：它是用来管理测试用例和所有的bug，管理项目产品。testlink：QC：禅道：jira：TAPD：3.搭建测试环境：1.如果说公司由运维人员就由运维进行搭建测试环境。2.开发进行搭建测试环境。3.测试人员进行搭建测试环境。测试环境一般是部署在linux系统或者windows开发把开发好的代码包进行打包，然后转给对应的相关人员（运维、测试，要么开发自己部署）代码包的打包格式war.jar包测试人员进行冒烟测试：对项目的大致主体功能进行测试测试通过。执行下一阶段工作，不通过打回开发进行修复，自测，进行新一轮的冒烟测试冒烟测试通过，测试人员执行sit系统集成测试（全量测试，批量注入我们所写的测试用例。进行测试，如果发现bug，提交给对应的开发进行修复。直到第一轮测试完成，等开发修复好bug之后进行第二轮sit2测试（回归测试）回归上一轮所产生的bug。（这个bug相关联的模块是否出现了新的问题）如果说一直由bug产生就一直进行回归）直到这个项目bug修复率达到98%左右，且没有重大或者一般的bug，百分之二是建议性bug（不影响线上用户使用bug，这些建议bug跟领导进行确认）那就可以关闭回归测试。输出这个项目的测试报告进行验收测试：αβ验收一个项目可以划分多个版本v0.1 v0.2


测试的基本原则？

SVN是一款版本控制工具：
        它可以进行管理：测试用例，测试报告,代码,产品规格说明书,可以实现资源共享。

        SVN为什么创建了文件进行上传,删除不了，客户端删除不了服务端的资源


        SVN工作原理：
        每天早上开发进入到公司第一件事情，就是打开SVN获取最新的代码（update）进行一天编程工作，到下班的时候进行传最新代码（commit），（有可能碰到代码冲突的问题，由最后一个进行上传的开发进行解决问题）





        SVN update 进行更新资源
        SVN commit 进行上传资源

        出现红色感叹号其他符号怎么解决问题，
        右键点击tortoiseSVN 选择clean up
        清空缓存 delete 下面三个都进行勾选清除

在项目组当种测试人员使用svn较多；
开发使用git较多

git也是一款版本控制工具：
他比svn多了暂存区以及远程仓库

git status                查看git状态
git diff                 查看提交内容有哪些修改的地方
git add                 从电脑本地提交到暂存区
git commit         从暂存区提交到本地仓库
git pull                从远程仓库拉取到本地仓库
git push                从本地仓库提交到远程仓库