软件测试知识概括

Posted 2021-07-22 GeorgeLin98

软件测试知识概括

• 软件测试基础
• 软件测试详解
• 软件测试拓展
• Fiddler抓包工具总结
• Jmeter(压力测试工具)
• PostMan(接口测试工具)
• CI/CD工具()
• 单元测试

软件测试基础

什么是软件：

• 软件是计算机程序、程序所用的数据以及有关文档资料的集合。
• 软件是计算机的灵魂。软件又可以分为两大类:系统软件和应用软件。
• 系统软件:系统软件是生成、准备和执行其他程序所需要的一组文件和程序。如操作系统Windows，数据库SQL-Server,驱动程序(网卡，声卡)，java语言系统编译环境等。
• 应用软件:计算机用户为了解决某些具体问题而购买、开发或研制的各种程序或软件包。如APP. QQ，微信等。

软件的生命周期：

• 软件生命周期(SDLC，Systems Development Life Cycle)是软件开始研制到最终被废弃不用所经历的各个阶段。—软件开发模型

软件开发模型：

• 瀑布型生命周期模型：
  ①在1970年人类整理了第一个软件生命周期，即瀑布型生命周期模型也叫瀑布模型。规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落，具有顺序性和依赖性。每个阶段规定文档并需进行评审。
  <1>测试介入项目特别晚:回溯成本非常高--好
  <2>项目周期很长
  

• V模型：
  ①RAD (Rap Application Development，快速应用开发）模型是软件开发过程中的一个重要模型，由于其模型构图形似字母V，所以又称软件开发的V模型。它通过开发和测试同时进行的方式来缩短开发周期，提高开发效率。
  <1>测试介入早，可以提前对需求进行评审和测试--回溯成本减少
  <2>测试提前在测试文档(用例)----可以直接执行测试===节省准备文档时间--提高项目效率。周期拉短

• 敏捷开发模型：
  ①从1990年代开始逐渐引起广泛关注，是一种以人为核心、快速迭代、循序渐进的开发方法。强调以人为本，专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
  <1>微信:文字聊天，语音聊天，视频聊天，朋友圈，红包，小程序，零钱通，公众号(需求)=== 3年
  <2>第一次迭代版本:文字聊天，语音聊天=== 3个月–上线，用户量，占领
  <3>第二次迭代:视频聊天，朋友圈==2个月 --用户量，吸引新用户
  <4>第三次迭代:红包，小程序，零钱通=3个月
  <5>…
  <6>产品不选的重复–完善，丰富
  ②项目周期多久?迭代周期多久?(1个月，2周，1周)
  ③敏捷开发模型特点：
  <1>弱化文档。
  <2>强调人之间沟通：站会–站着开会：10分钟：今天的任务，昨天问题，协调处理。

软件开发过程：

• 一、问题的定义及规划：
  ①主要确定软件的开发目的及其可行性。制定项目总体开发计划。
• 二、需求分析：
  ①在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析,明确客户的需求(需求评审–产品，开发，测试)，输出需求规格说明书终版(原型图)。
• 三、设计：
  ①把需求分析得到的结果转换为软件结构和数据结构，形成系统架构。
  ②概要设计:主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。
  ③详细设计:对概要设计中表述的各模块进行深入分析等，其中需要包含数据库设计说明。
• 四、编码：
  ①按照详细设计好的模块功能表，编程人员编写出计算机可运行的程序代码
  
• 五、软件测试
  ①软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正，测试的方法主要有白盒测试跟黑盒测试两种。建立详细的测试计划并严格按照计划进行。
  <1>单元测试：主要是测试程序代码，为的是确保各单元模块被正确的编译，比如有具体到模块具体到类，函数、方法的测试等。
  <2>集成测试:单元测试后，将各单元组合成完整的体系，测试软件单位之间的接口是否正确、数据能否正常传递。---接口测试
  <3>系统测试:把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞等。----最重要，常见的(web，APP)
  <4>验收测试:主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到符合效果的。---UAT(用户，产品（领导) )
  <5>α(阿尔法)测试：封闭式内测，由开发公司发放一定数量的激活码或账号给玩家。
  <6>β(贝塔)测试：开放式内测，不限数量，全民参与。
  
• 六、运行维护：
  ①软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的需求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护主要包括纠错性维护和改进性维护两个方面。
  ①纠错性：bug修复，修改代码—新版本
  ②改进性：优化，完善，改良—新版本(需求–立项–需求分析)

一个软件产品从开发到用户使用都涉及哪些环境？

• 1、开发环境：
  ①顾名思义，开发同学开发时使用的环境，每位开发同学在自己的dev分支上干活，提测前或者开发到一定程度，各位同学会合并代码，进行联调。
• 2、测试环境：
  ①也就是我们测试同学干活的环境啦，一般会由测试同学自己来部署，然后在此环境进行测试。bug修复后，需要发版更新测试环境来回归bug。
• 3、回归环境：
  ①回归bug的环境，其实就是我们的测试环境，在测试环境上测试、回归验证bug。
• 4、预发布环境：
  ①测试环境到生产环境的过渡。测试环境可能会受到一些限制，一些流程或者数据没有测试到，就可以在预发布环境进行验证，从而保证产品上线质量。
  ②预发布环境和生产环境区别：
  <1>预发环境中新功能为最新代码，其他功能代码和生产环境一致。
  <2>预发环境和生产环境的访问域名不同。
  ③注意事项：
  <1>预发布环境一般会连接生产环境的数据库，测试时要注意，以免产生脏数据，影响生产环境的使用。
• 5、生产环境：
  ①即线上环境，用户使用的环境。由特定人员来维护，一般人没有权限去修改。
  ②另外，还有个灰度发布，发生在预发布环境之后，生产环境之前。
  <1>生产环境一般会部署在多台机器上，以防某台机器出现故障，这样其他机器可以继续运行，不影响用户使用。灰度发布会发布到其中的几台机器上，验证新功能是否正常。如果失败，只需回滚这几台机器即可。

灰度发布版本和灰度环境：

• 预发布环境过后，就是灰度发布了。由于一个项目，一般会部署到多台机器，所以灰度1台至3台，看看新功能是否ok，如果失败则只需要回滚几台，比较方便。注意，由于是灰度发布几种几台，所以一般会使用跳板机，然后进行域名绑定，这样才可以保证只访问有最新代码的服务器。
• 灰度发布也叫金丝雀发布，起源是，矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度高。
  ①在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。如果没有问题，那么可以将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的A/B测试。
  ②当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。
  ③如果在灰度发布过程中（灰度期）发现了新版本有问题，就应该立即将流量切回老版本上，这样，就会将负面影响控制在最小范围内。
  ④链接：什么是灰度发布?
• 灰度环境：也可称为线上仿真环境或者预发布环境，在上线之前发布到灰度环境，通过后再上线，其实灰度环境的好处挺多的，其中最明显的就是观察用户反馈，即时调整产品的方向，避免因为直接上线导致用户一时半会儿适应不了新系统，导致用户流失。此外还有助于降低上线的成本，如人力成本（一般大版本上线是深更半夜，开发比较疲惫）、降低bug数量等，如果发现灰度环境的问题，可以及时把用户剔除灰度名单，尽可能减少用户的损失
  ①链接：灰度环境搭建笔记

分支解释：

• master 主分支： 对应正式环境的代码。
• develop分支：近期要发布和测试的代码分支，对应 开发分支。
• fixbug分支：要发补丁的代码分支，对应bug分支。
• release分支：本周要发布的代码分支，对应发布分支。

应用软件架构C/S与B/S架构：

• c/S: client-server:这种就是我们一定要安装一个客户端才能够用的软件，就叫C/S
  ①缺点:每次更新，都需要更新服务端与客户端，比如说超市收银系统每次更新每台电脑都必须重装客户端，特别是有分店的情况。人力物力财力都很大。–重启业务中断
• B/S: browser-server:只需要一个浏览器，就可以访问服务的，就是B/S.
  ①优点:只需要更新服务器就OK,不需要去更新浏览器。用户主动性比较高。比如说天猫、淘宝。

软件测试是什么：

• 软件测试的定义: 使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求戎弄清预期结果与实际结果之间的差别。
• 问题:使用QQ的过程,是软件测试么? 答案：不是。
• 我们为什么要做软件测试，它的目的什么?
  ①软件测试为了发现程序(软件)存在的代码或业务逻辑错误
  ②软件测试为了检验产品是否符合用户需求
  ③软件测试为了提高用户的体验

软件测试的分类：

• 按测试技术划分：
  ①黑盒测试：
  <1>产品-黑色盒子–代码实现
  <2>输入输出—数据驱动的测试
  <3>点点点
  ②白盒测试：
  <1>产品—透明盒子—代码逻辑，会代码
  <2>不是测试做的，开发自测----代码审查
  <3>单元测试
  ③灰盒测试：
  <1>大概知道代码逻辑实现,不需要着懂所有的代码
  <2>接口测试
• 被测试对象是否运行划分：
  ①动态测试：程序是运行的
  ②静态测试(文档检查、代码走查)：程序不运行
• 按不同的测试手段划分：
  ①手工测试：(点工)
  ②自动化测试：(代码+工具)
• 按测试包含的内容划分：
  ①功能测试：测试业务逻辑(手工，自动化)—核心重要
  ②界面测试：Ul (user interface)–外观美观，设计合理，友好—主观性强=需求文档
  ③安全测试：高级类型—攻击(工具(扫描–appscan)，代码(脚本–ql注入)）—漏洞，薄弱=账号密码，http协议–https协议
  ④兼容性测试：软件＋硬件(windows, Linux ，MAcOS,android,ios);软件+软件(浏览器兼容)…调用;软件不同版本之间=APP升级(老功能，数据)
  ⑤易用性测试：主观—人性化，舒适，用户使用习惯，用户体验—提bug=站在用户角度考虑，参考成熟产品
  ⑥性能测试：高级类型—双十一(访问人数多)–并发（10000)—资源,CPU，内存–正常处理(压力测试，稳定性、负载测试)
• 按测试阶段划分：
  ①单元测试
  ②集成测试
  ③系统测试
  ④验收测试
  ⑤α测试
  ⑥β测试
• 其他测试：
  ①回归测试：regression test :测试 — bug，开发修复bug(修改代码)=验证bug =其他没被修改的代码模块的测试，影响:上线之前-很多轮(2-4轮)的回归测试(重复)–策略=自动化测试实现
  ②冒烟测试：来源—硬件测试:电路板–通电–冒烟–短路被烧了=打回开发重做…软件测试:软件提测–核心业务功能，主流/程-打回开发
  ③探索性测试/自由测试(测试思维)：发散测试–能力要求非常高:依据，方法=靠经验，积累，直觉----

软件测试详解

软件测试工作流程图：

• 软件测试基本流程：
  ①测试需求分析阶段：阅读需求，理解需求，主要就是对业务的学习，分析需求点。参与需求评审会议。
  ②测试计划阶段：编写测试计划，参考软件需求规格说明书、项目总体计划，内容包括测试范围(来自需求文档)、进度的安排，人力物力的分配，整体测试策略的制定，和风险的评估与规避措施有一个制定，一般有测试负责人编写，当然我们可能也会参与相关的评审工作。
  ③测试设计阶段：主要任务是编写测试用例，会参考需求文档(原型图)、概要设计、详细设计等文档，有不明确的也会及时和开发、产品经理沟通。用例编写完成后会进行评审。
  ④测试执行阶段：首先搭建测试环境,执行预测(冒烟)，以判定当前版本可测与否，如果预测通过，正式进入系统测试(2-4轮)，遇到问题提交Bug到缺陷管理平台，并对bug进行跟踪，直到被测软件达到测试需求要求，没有重大bug，测试结束。------(完善测试用例)
  ⑤测试评估阶段：出测试报告，对整个测试的过程和版本质量做一个详细的评估(剩余bug数量/严重程度，测试用例的覆盖率)。确认是否可以上线。
  ⑥UAT测试阶段：部署到UAT测试环境，由产品或者领导来验证功能。

测试需求：

• 测试需求是什么?
  ①测试需求主要解决“测什么”的问题，一般来自需求规格说明书中原始需求
  ②测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求–性能，安全、兼容易用、界面–6个方面
• 为什么需要软件测试需求?
  ①简而言之:只有明确了测试需求，才能知道怎么去测试?什么时候开始测试?要多少人测试?在什么环境上测试?----提炼测试点，时间规划，人力规划，测试环境

案例分享：

• 测试点思路步骤如下：正常+异常
  ①正常功能:是否可以正常提交–注册成功–单个功能冒烟测试
  ②单个功能项验证(正常+异常)：规则:按顺序从上至下，对每一个输入项进行验证
  <1>数据长度、数据类型验证、必填项验证、重复
  <2>限制约束验证
  <3>隐形需求:充分熟悉产品业务，挖掘隐性需求
  ③功能交互验证：模块之间传递的信息和数据。对存在功能交互的功能项
  ④非功能性测试：界面，易用性，兼容性，安全性，性能
  
• 拿到项目的基本测试思路:(分析需求)
  ①明确一下这个项目是做什么的? 基本业务逻辑流程:淘宝—注册登录商品浏览购物车―提交订单支付。。。。=流程图(主流分支流程)
  ②细化每一个功能，细化分析提取测试点:注册，登录……
  ③所有的细化模块的分析组合在一起=完成项目的测试点----功能
  ④非功能:界面、易用性、兼容性、安全性、性能压力
  

测试用例：

• 软件测试的核心就是测试用例的编写。
• 等价类划分法的概念：
  ①等价类划分法是把所有程序的输入域划分成若干个子集合(等价类)，然后从每一个子集合(等价类）中选取少数具有代表性的数据作为测试的输入数据。
  ②在该子集合中，所有的输入数据对于揭露软件中的错误都是等效的。–保证质量，减少测试用例数量–提高效率等价类划分有效等价类（正面，不会报错)和无效等价类(负面，抛出错误)。
  ③举例:微信红包，金额区间:0.01~200==需求–设计测试用例
  分析:
  <1>有效等价类:
  1)【0.01，200】
  4)数字
  6)小数点后不超过两位
  <2>无效等价类:
  2)>200
  3)<0.01
  5)非数字(中文、字母、字符)
  7)超过两位小数
  8)空值
  9）负数
• 边界值分析法–等价类划分法一起使用：
  ①定义:边界值分析法是对等价类划分法的一个补充，边界值一般都是从等价类的边缘值去寻找。Ⅰ2．②原则和步骤:确定边界:应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据–范围相关
  <1>有效等价类的边界
  <2>无效等价类的边界
  <3>注意：
  1、次边界值:IP地址(0-255)，时间格式(O-23)，2的幂值(256,1024,65535)-需求没有明说，常识
  2、特殊边界值:0是一个特殊值，负数，空值，空格等。
  ③边界值的作用:人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误!----提出更多bug
  ④边界值的应用场景:如果需求规定了取值范围或规定了取值的个数时，可利用边界值进行测试
  
• 场景法：
  ①什么是场景法?通过场景描述的业务流程(业务逻辑).，也包括代码实现逻辑，设计用例来遍历场景（路径)，验证软件系统唧能的正确性。
  ②如何使用场景法
  <1>画出流程图–产品需求文档–画好了;–需要测试自己画
  1、矩形:表示步骤(操作、输入、输出结果)
  2、菱形:判断条件–是、否
  3、箭头:流向
  ③遍历场景，提取测试用例。
  1、覆盖正常的路径-取到钱的路径----判断的地方–Y
  2、走每一个分支–判断的地方—找菱形–N
  3、出错步骤重新回到主流程，建议多走一步正确的步骤–注意:
  ④注意：
  <1>场景法的重点是测试流程，因此每个流程一个用例验证即可，流程测试没有问题并不能说明系统功能没有问题了，还需要针对单步的功能进行测试，
  <2>只有单个功能点和流程测试，才算是充分的测试＋等价类、边界值----细化测试
  ⑤案例：
  场景一:插入合法银行卡，输入正确的密码，输入正确且充足的金额，ATM足够—取到钱
  场景二:插入不合法的卡，退卡提示错误;
  场景三:插入合法银行卡，输入密码之后取消，–退卡
  场景四:插入合法银行卡，输入错误的密码之后不取消，不超过3次–提示密码错误，重新输入密码
  场景五:插入合法银行卡，输入错误的密码之后不取消，出错3次—吞卡
  场景六:插入合法银行卡，输入正确的密码之后不取消，输入不合法金额–提示错误，重新输入
  场景七:插入合法银行卡，输入正确的密码之后不取消，输入合法金额，账户余额不足–提示错误，重新输入
  场景八:插入合法银行卡，输入正确的密码之后不取消，输入合法金额，账户余额充足，ATM不足余额–提示错误，重新输入
  
• 错误推测法(反推法)—原则步骤：
  ①基于经验和直觉推浏程序中所有可能存在的各种错误从而有针对性的设计测试用例的方法。它的要素共有三点，分别为:经验、知识、直觉。
  ②考虑程序可能触发错误场景–不能正常运行
  ③不单独使用–可以作为其他方法的补充!

bug详解：

• 软件的Bug：
  ①狭义概念是指软件程序的漏洞或缺陷
  ②广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节（增强性，建议性)、或与需求文档存在差异的功能实现等。
• ··bug的类型：··
  ①要确定一个bug的类型，需要对项目(或产品)有比较深的理解。这个划分对于开发定位问题影响很小，但对于问题类型的充计就比较重要了。—测试报告
  ②常见的bug类型划分(禅道系统为例。可自定义):
  <1>代码(功能错误:---最常见---优先级偏高
  <2>界面优化---UI测试:优先绞偏低
  <3>设计缺陷--优化建议:需求上就不合理--优先级偏低
• bug的等级--优先级：
  ①要bug等级，这个划分有分三级或四级，也有分五级的。如果是等级越高（严重)，那么可能被修复的等级也会高一些，然后有些公司还会根据你提的bug数量和bug等级来考察你的绩效。很多情况下，我们提交bug大致的等级差不多即可，没有严格区分。
  ②如何来判断bug的等级（严重程度)，一般可以参照下面的判断条件。
  (1)致命错误: --- blocker
  1、常规操作引起的系统崩溃、死机、死循环、闪退
  2、造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露3、涉及金钱计算—公司巨大损失，业务
  4、阻断性测试，所有测试工作进行不下去（冒烟测试)–登录5、权限问题–爱奇艺资源会员??
  (2)严重错误:-- critical
  1、重要功能不能实现;
  2、错误的波及面广，影响到其它重要功能正常实现; --12306购票系统<–咨询
  3、非常规操作导致的程序崩溃、死机、死循环、闪退
  4、外观(界面)难以接受的缺陷;
  5、控密码明文显示;前端处I理bug后端–服务器（数据库验证)–安全6、偶现的致命性bug
  (3)一般错误:--major：不影响产品的运行、不会成为故陪起因，但对产品外观和下道工序影响较大的缺陷
  1、次要功能不能正常实现;
  2、操作界面错误(包括数据窗口内列名定义、含义不一致);
  3、查询错误。数据错误显示;
  4、简单的输入限制未放在前端进行控制;5、删除操f作未给出提示;—友好型6、偶现的严重性bug
  (4)细微错误:-- minor：程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误–用户休验
  1、界面不规范;
  2、辅助说明描述不清楚;
  3、提示窗口文字未采用行业术语;4、界面存在交字错误;
  (5)改进建议--enhancement: --新需求下一个版本
  1、可以提高产品质量的建议,包括新需求和对需求的改进。
• bug的生命周期（管理流程)：
  ①生命周期中一般缺陷状态:发现--新建（提bug)->指派->已解决->待验->关闭。---正常
  ②如果待验的bug在验证时没有解决好，我们需要重新打开（激活)->指派->已解决->待验，循环这个过程。中间其他状态:拒绝、延期等
  ③我们来看一个bug的处理流程图（生命周期图)，让大家更深刻地理解周期中bug的状态及相应处理。
  
  ④new(新建)—》(提bug者，测试老大)指派(开发，开发老大)︰跟进(3天，push(推进）开发修改)
  <1>重复bug (duplicated)(233)︰要求开发备注一下重复bug 的号(ID: 122)，测试确认–是--加备注，关闭;否–重新激活(reopened)–指派开发;
  <2>不是缺陷(invalid) :by-design(设计如此)，操作失误，需求的理解不一致–争论:1)分析需求，从用户角度出发没找到证据–尝试说服开发;2)产品(项目经理)–拍板–是bug–开发修复;不是–测试不纠结，留好证据(邮件据图，备注bug) ;
  <3>无法复现(un-reproduced) ∶
  1)开发复现:确认一下测试环境再复现出来–可以–帮助开发复现，测试环境调试定位
  2）测试和开发环境都无法复现:尝试眼踪3-5个版本（10次+)—加备注(复现次数，跟踪版本数)–关闭–记录到小本本，研究
  <4>不予解决(wontfix) :bug级别低-- Ul,minor，enhancement bug;
  1)说服开发
  2)产品确认–备注留证据，关闭
  <5>延期(delayed):
  1)建议性(feature/enhancement)–下一个版本需求∶
  2)上线之前，影响比较大(性价比)”–分析，1)分析这个bug用户影响大小，建议他修复;2)严重级别—产品、项目经理最后确认–不修复，备注(留证据)–不关闭，挂起
  <6>已修复(resolved-fixed) ：测试验证―（ bug步骤，结果检查)
  1） verified(已验证)-- closed(关闭)
  2）仍然存在: reopened(重新激活)

bug的跟踪管理-缺陷管理工具：

• 常见的缺陷管理平台:
  ①禅道(entao) ，我们现在做项目用的就是这个
  ②bugzilla、jira:都还不错，也比较强大。但是搭建起来很困难bugfree:
  ③Readmine
  ④easybug:免费开源，在线网站类型的Mantis:这个还可以用
  ⑤Qc(QualityCenter)、TD
• 不管是开源还是商业的缺陷管理工具，它们本质都是一样的，用来管理bug的生命周期。掌握其中一款工具，自然就会用其他的，稍微有一点点区别的，别人加以指点，就可以明白了。
• 禅道缺陷管理平台：
  ①bug标题——标题要清晰简洁，写明bug描述;如果没有选择功能模块，最好在标题中标注功能模块。让查看bug的人员清楚知道你所表达的意思。bug的功能模块+bug的操作+ bug的结果
  ②重现步骤——详细写下发现bug的测试过程。能指导开发重现这个bug。附上测试数据
  ③实际结果——出现bug的结果，粘贴bug截图、日志截图—直观，证据（有图有真相)
  ④预期结果——记得写清楚预期----来自于预期结果
  .⑤bug类型和严重程度——便于后续测试结果分析，bug的统计
  ⑥bug测试环境——例如:什么系统，哪个版本等。兼容性问题、难以重现问题
  ⑦附件——日志文件，文件测试数据。图片、崩溃日志文件等
  

软件测试拓展

目前几个比较主流的测试如下：

• 自动化测试：自动化测试有广义和狭义之分，广义上一切使用工具或代码来代替手工测试都可以认为是自动化测试；不过，在测试圈中，我们一般狭义的来理解自动化测试，基于UI层的自动化测试技术。
• 性能测试：性能测试，相信每个测试人员都或多或少的接触过性能测试。表面上看，它的入门非常简单，主流的LoadRunner和Jmeter都提供了录制脚本的功能，录制–>设置虚拟用户数 -->运行，然后一个性能测试就完成了。笔者的首份测试工作的第二任务也完成一个性能需求；当时磕磕绊绊的花了三四天时间搞定，性能测试报告也做的有模有样。但如果想做好性能测试，我觉得测试人员应该达到一般架构师的水平，至少比一般的开发人员更了解系统的整体架构。
• 安全测试：关于安全测试，我知道很少，只能简单的谈谈。安全测试是主流中的非主流，“主流”指的是它是测试技术的一个主流方向，“非主流”是指在我看来，对这个技术的研究和学习没有什么固定的章法，想要有所成就需要一些天资和悟性。
• 白盒测试：白盒测试主要就是进行研发代码的单元测试了，需要有一定的代码能力哦。测试人员做白盒的优势就是具备测试思维，在设计测试用例时考虑更加全面；但难点也很明显，和开发一样熟悉被测代码，这一点有难度

渗透测试与安全测试的区别：

• 出发点差异：
  ①渗透测试是以成功入侵系统，证明系统存在安全问题为出发点
  ②安全测试则是以发现系统所有可能的安全隐患为出发点
• 视角差异：
  ①渗透测试是以攻击者的角度来看待和思考问题
  ②安全测试则是站在防护者角度思考问题，尽量发现所有可能被攻击者利用的安全隐患，并指导其进行修复
• 覆盖性差异：
  ①渗透测试只选取几个点作为测试的目标
  ②安全测试是在分析系统架构并找出系统所有可能的攻击界面后进行的具有完备性的测试
• 成本差异：
  ①渗透测试需要投入的时间和人力相对较少
  ②安全测试需要对系统的功能、系统所采用的技术以及系统的架构等进行分析，需要投入更多的时间和人力
• 解决方案差异：
  ①渗透测试无法提供有针对性的解决方案
  ②安全测试会站在开发者的角度分析问题的成因，提供更有效的解决方案

常用的软件测试工具有哪些？

• 链接：我们常用的软件测试工具有哪些？
• 测试管理工具：
  ①TestDirector(大而全)
  ②禅道(简单好用)
  ③YApi ：api 管理平台，旨在为开发、产品、测试人员提供更优雅的接口管理服务。
• 接口测试工具：
  ①Jmeter(开源)
  ②postman
  ③SoapUI
• 性能测试工具：
  ①loadrunner，大而全，要学精通还是有点难度，重量级工具
  ②jmeter 基于java平台的性能开源测试工具，其实也很强大，而且比较好用
• 白盒测试工具：
  ①jtest java语言的单元测试框架
  ②JUnit 验证java的工具
• 持续集成工具
  ①jenkins
  ②Hudson
• 抓包工具
  ①fiddler

测试用例：

• 一般测试用例设计包含以下几点内容：
  1、 标识符（用例编号）：一般编号规则：TestCase_项目名称_模块名称_功能名称_0001
  2、 测试项。测试用例的测试目的。一般情况下，用一句话表明目的。例如：使用谷歌浏览器打开百度首页；在QQ登录界面输入正确的用户名密码能登陆上。（表明你的测试模块、测试对象、方式、事件。）（A：人名 B 人名 C 时间 D 地点 E 事件）
  3、 依赖用例：一般功能流程上，下游的功能测试依赖于上游的功能测试的用例。例如：增加了一个数据的测试用例，将会被删除该数据的测试用例依赖。
  4、 测试步骤。用最朴实的语言，写出来软件的操作步骤。要尽量详细。例如，在用户名文本框输入：XXX；在省份下拉列表选择：北京 城市下拉列表选择：北京
  5、 测试数据：单独整合测试数据。必须和测试步骤中的数据保持一致。
  6、 预期结果。准确：对象的准确，内容的准确性。原则上每一个操作，都要有一个结果。在重要的步骤之后，设定预期结果。例如：页面跳转到XXX；程序弹出对话框，提示：用户名或密码错误，请重新输入！一般和测试目的密切相关。测试目的决定了测试步骤和预期结果。
  7、 测试结果。要求在测试执行完成后添加。没有执行保持为空。测试结果只有两个：通过/失败；Pass/Failed。和预期结果一致即为通过；不一致即为失败。
  8、 测试人。测试的执行人。可以和设计者相同，也可以不同。
  9、 备注：为了测试用例正常执行而做的特殊准备。例如：专门制造网络不畅情况下，软件错误提示；
  

UI自动化测试详解：

• 在这里，我们可以先学习Web自动化测试，再学习App自动化测试。
• UI自动化测试的成本比接口测试要高，主要原因不是技术实现难度高，而是因为UI是对接用户的终端界面，它是调整最频繁，改动最剧烈的部分，所以维护成本高。
• selenium 是一个 web 的自动化测试工具，不少学习功能自动化的同学开始首选 selenium ，因为它相比 QTP 有诸多有点：
  ①免费，也不用再为破解 QTP 而大伤脑筋
  ②小巧，对于不同的语言它只是一个包而已，而 QTP 需要下载安装1个多 G 的程序。
  ③这也是最重要的一点，不管你以前更熟悉 C、 java、ruby、python、或都是 C# ，你都可以通过 selenium 完成自动化测试，而 QTP 只支持 VBS
  ④支持多平台：windows、linux、MAC ，支持多浏览器：ie、ff、safari、opera、chrome
  ⑤支持分布式测试用例的执行，可以把测试用例分布到不同的测试机器的执行，相当于分发机的功能。
• App自动化测试：
  

Fiddler抓包工具总结

Fiddler抓包工具简介：

• Fiddler是一个蛮好用的抓包工具，可以将网络传输发送与接受的数据包进行截获、重发、编辑、转存等操作。也可以用来检测网络安全。
• 链接：
  ①Fiddler 下载地址
  ②Fiddler抓包工具详解
• Fiddler是通过改写HTTP代理，让数据从它那通过，来监控并且截取到数据。当然Fiddler很屌，在打开它的那一瞬间，它就已经设置好了浏览器的代理了。当你关闭的时候，它又帮你把代理还原了。
• 若打开Fiddler发现不能抓包，则查看浏览器是否被浏览器插件代理了。

Fiddler抓包工具详解：

Jmeter(压力测试工具)

工具与测试：

• 压力测试工具：
  ①做压力测试的常用工具做压力测试，一般要使用工具， 人工是没办法做的。
  ②最常用的工具是LoadRunner, 但是LoadRunner毕竟是收费软件，而且使用上也比较复杂。
  ③现在越来越多的人开始使用Jmeter来做压力测试。 免费， 而且使用上非常简单。
  ④链接：
  <1>JMeter下载及使用
  <2>全网最全最细的jmeter接口测试教程以及接口测试流程详解
• 性能测试与负载测试：
  ①性能测试(Performance testing)：运行性能测试确定系统处理能力,来判断系统是否需要优化
  ②负戟测试(Load testing)：通过系统面临多资源运行或被攻击情况下进行测试

jmeter详解：

• jmeter简介：
  ①Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试，但后来扩展到其他测试领域。它可以用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器等等。
  ②JMeter可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。
  ③Apache jmeter 可以用于对静态的和动态的资源（文件，Servlet，Perl脚本，java对象，数据库和查询，FTP服务器等等）的性能进行测试。
  ④它可以用于对服务器、网络或对象模拟繁重的负载来测试它们的强度或分析不同压力类型下的整体性能。你可以使用它做性能的图形分析或在大并发负载测试你的服务器/脚本/对象。
• jtl文件和jmx文件：
  ① jtl：
  <1>在性能测试过程中，我们往往需要将测试结果保存在一个文件当中，这样既可以保存测试结果，也可以为日后的性能测试报告提供更多的素材
  <2>Jmeter中，结果都存放在.jtl文件。这个.jtl文件可以提供多种格式的编写，而一般我们都是将其以csv文件格式记录
  ②jmx：
  <1>jmeter生成的测试计划文件。
• jmeter的使用：
  ①线程组：代表一定数量的并发用户，它可以用来模拟并发用户发送请求。线程组是为模拟并发负载而设计。
  ②取样器（Sampler）：模拟各种请求。所有实际的测试任务都由取样器承担，存在很多种请求。如：HTTP 、ftp请求等等。
  ③监听器：负责收集测试结果，同时也被告知了结果显示的方式。功能是对取样器的请求结果显示、统计一些数据（吞吐量、KB/S……）等。
  ④断言：用于来判断请求响应的结果是否如用户所期望，是否正确。它可以用来隔离问题域，即在确保功能正确的前提下执行压力测试。这个限制对于有效的测试是非常有用的。
  ⑤定时器：负责定义请求（线程）之间的延迟间隔，模拟对服务器的连续请求。
  ⑥逻辑控制器：允许自定义JMeter发送请求的行为逻辑，它与Sampler结合使用可以模拟复杂的请求序列。
  ⑦配置元件维护Sampler需要的配置信息，并根据实际的需要会修改请求的内容。
  ⑧前置处理器和后置处理器负责在生成请求之前和之后完成工作。前置处理器常常用来修改请求的设置，后置处理器则常常用来处理响应的数据。
• jmeter元件的作用域：
  ①配置元件( config elements )会影响其作用范围内的所有元件。
  ②前置处理程序(Per-processors）在其作用范围内的每一个sampler元件之前执行。
  ③定时器（timers )对其作用范围内的每一个sampler有效。
  ④后置处理程序(Post-processors)在其作用范围内的每一个sampler元件之后执行。
  ⑤断言（Assertions ）对其作用范围内的每一个sampler 元件执行后的结果执行校验。
  ⑥监听器(Listeners )收集其作用范围的每一个sampler元件的信息并呈现。
  ⑦取样器（sampler）元件不和其它元件相互作用，因此不存在作用域的问题。
• jmeter元件执行顺序：
  ①配置元件>>前置处理器>>定时器>>取样器>>后置处理器>>断言>>监听器
  ②如果在同一作用域范围内有多个同一类型的元件，则这些元件按照它们在测象机试计划中的上下顺序一次执行

jmeter参数化、检查点、集合点、关联、结果、连接：

• 参数化：
  ①前置处理器里的用户参数。
  ②配置原件里的CSV DATA Set Config。
  ③配置原件里的用户定义的变量。
  ④工具里的函数助手。
• 集合点：
  ①定时器里的Synchronizing Timer。让所有请求在不满足条件的时候处于等待状态。链接：Jmeter 集合点
• 断言：
  ①断言里的响应断言
  ②断言里的断言持续时间
  ③断言里的返回结果大小断言
• 关联：
  ①后置处理器的正则表达式处理器
  ②后置处理器里的json提取器
  ③后置处理器里的BeanShell处理器
• 结果：
  ①监听器里的察看结果树
  ②监听器里的聚合报告
  ③监听器里的断言结果
• 连接：
  ①取样器里的HTTP请求

jmeter图像：

• 扩展插件：
  ①下载插件http://pan.baidu.com/s/1mioVJni
  ②解压下载的安装包，将 jpgc-graphs-basic-2.0.zip 解压缩后只有一个 lib 目录，该目录下有一个 ext 文件夹和一个 jmeter-plugins-cmn-jmeter-0.3.jar 包，ext 文件夹中有 jmeter-plugins-graphs-basic-2.0.jar 和 jmeter-plugins-manager-0.10.jar 包。
  ③将 lib 目录下的 jmeter-plugins-cmn-jmeter-0.3.jar 拷贝到 %JMeter%/lib 目录下；
  ④将 ext 目录下的 jmeter-plugins-graphs-basic-2.0.jar 和 jmeter-plugins-manager-0.10.jar 拷贝到 %JMeter%/lib/ext 目录下。
  ⑤重启 JMeter，发现已经支持 TPS、TRT 等视图了。
• 视图：
  ①Active Threads Over Time
  ②Response Times Over Time
  ③Transactions per Second

jmeter线程：

• 线程(用户) ：一般常用线程组:可以理解成为虚拟用户组
• setup thread group：可用于执行预测试操作。这些线程的行为完全像一个正常的线程组元件。类似Loadrunner中的init
• teardown thread group：可用于执行测试后动作。这些线程的行为完全像一个正常的线程组元件。类似Loadrunner中的end
• 线程组设置：
  ①线程数：虚拟用户数
  ②ramp up period：设置的虚拟用户数需要多长时间全部启动。如果线程数为20，时间为10，也就是每秒钟启动2个线程
  ③循环次数：每个线程发送请求的次数。如果线程数为20，循环次数为100，那么每个线程发送100次请求。总请求数为20*100=2000。如果勾选了“永远”，那么所有线程会一直发送请求，一到选择停止运行脚本。
  ④调度器：可以更灵活的设置运行时间等

脚本语言详解：

• Bean Shell：
  ①BeanShell是一种完全符合Java语法规范的脚本语言,并且又拥有自己的一些语法和方法;
  ②BeanShell是一种松散类型的脚本语言(这点和JS类似);
  ③BeanShell是用Java写成的,一个小型的、免费的、可以下载的、嵌入式的Java源代码解释器,具有对象脚本语言特性,非常精简的解释器jar文件大小为175k。
  ④BeanShell执行标准Java语句和表达式,另外包括一些脚本命令和语法。
• JSONPath：
  ①JSONPath是xpath在json的应用。
  ②xml最大的优点就有大量的工具可以分析，转换，和选择性的提取文档中的数据。XPath是这些最强大的工具之一。

jmeter结果报告：

• 聚合报告各个参数含义如下：
  ①Samples——本次场景中一共完成了多少个请求
  ②Average——平均响应时间
  ③Median——响应时间的中值
  ④90%Line——所有请求中90%的响应时间
  ⑤Min——最小响应时间
  ⑥Max——最大响应时间
  ⑦Error——出错率
  ⑧Troughput——吞吐量
  ⑨Received——响应数据大小
  ⑩KB/sec——以流量做权衡的吞吐量
• TPS报告：
  ①一般来说压测环境的性能一般会比本地环境好2到4倍。

性能测试专有名词：

• TPS：Transactions PerSecond：
  ①意思是每秒事务数，具体事务的定义，都是人为的，可以一个接口、多个接口、一个业务流程等等。一个事务是指事务内第一个请求发送到接收到最后一个请求的响应的过程，以此来计算使用的时间和完成的事务个数。
• QPS：Queries Per Second：
  ①意思是每秒查询率，是一台服务器每秒能够响应的查询次数（数据库中的每秒执行查询sql的次数），显然，这个不够全面，不能描述增删改，所以，不建议用qps来作为系统性能指标。
• QPS和TPS的区别：
  ①如果是对一个查询接口（单场景）压测，且这个接口内部不会再去请求其它接口，那么tps=qps，否则，tps≠qps
  ②如果是容量场景，假设n个接口都是查询接口，且这个接口内部不会再去请求其它接口，qps=n*tps
  ③QPS vs TPS：QPS基本类似于TPS，但是不同的是，对于一个页面的一次访问，形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“QPS”之中。如，访问一个页面会请求服务器2次，一次访问，产生一个“T”，产生2个“Q”。
• RT，响应时间：
  ①RT（Response-time）响应时间：执行一个请求从开始到最后收到响应数据所花费的总体时间，即从客户端发起请求到收到服务器响应结果的时间。该请求可以是任何东西，从内存获取，磁盘IO，复杂的数据库查询或加载完整的网页。
  ②暂时忽略传输时间，响应时间是处理时间和等待时间的总和。处理时间是完成请求要求的工作所需的时间，等待时间是请求在被处理之前必须在队列中等待的时间。
  ③响应时间是一个系统最重要的指标之一，它的数值大小直接反应了系统的快慢。
• Concurrency，并发数：
  ①并发数是指系统同时能处理的请求数量，这个也反应了系统的负载能力。
  ②并发意味着可以同时进行多个处理。并发在现代编程中无处不在，网络中有多台计算机同时存在，一台计算机上同时运行着多个应用程序。
• 吞吐量：
  ①系统的吞吐量（承压能力）和处理对CPU的消耗、外部接口、IO等因素紧密关联。单个处理请求对CPU消耗越高，外部系统接口、IO速度越慢，系统吞吐能力越低，反之越高。
  ②系统吞吐量有几个重要指标参数：QPS（TPS）、并发数、响应时间。
• 总结：
  ①QPS（TPS）：（Queries Per Second）每秒钟请求/事务数量。
  ②并发数： 系统同时处理的请求/事务数。
  ③响应时间： 一般取平均响应时间。
  ④理解了上面三个指标的意义之后，就能推算出它们之间的关系：
  <1>QPS（TPS）= 并发数/平均响应时间
  <2>并发数 = QPS*平均响应时间
• 链接：
  ①系统吞吐量（TPS）、用户并发量、性能测试概念和公式
  ②一文搞懂高并发性能指标：QPS、TPS、RT、并发数、吞吐量
  ③性能测试问产品 压力测试指标给多少？TPS、响应时间、并发量的要求是多少？这样计算

PostMan(接口测试工具)

Postman简介：

• Postman的功能非常强大，但是面对以下这些状况时，我觉得调试一个接口太麻烦了（这里不讨论工具的好坏，工具是帮助我们提高效率的，每个人的需求也不一样，我只说明我个人遇到的一些情况，不喜请勿喷）：
  ①查找配置多数要通过鼠标点来点去, 与习惯文本和快捷键操作的便捷方式违背
  ②调试别人接口要导入他们的一些数据，比较麻烦
  ③多个产品线环境变量查看不直观
  ④写完接口要来回切换应用进行测试，比如（IDEA <——> Postman）
  ⑤快速定位接口比较麻烦
• 使用教程：Postman使用详解

Postman基础功能：

身份验证Authentication：

• Inherit auth from parent：
  ①向集合或文件夹添加授权。
  ②假设您在集合中添加了一个文件夹。在授权选项卡下，默认的授权类型将被设置为“从父类继承auth”。
• Basic Auth：
  ①是基础的验证，所以会比较简单
  ②用户名和密码用:合并，将合并后的字符串使用BASE64加密为密文，每次请求时，将密文附于请求头中，服务器接收此密文，进行解析，判断是否认证。
• No Auth：
  ①默认情况下，“No Auth”出现在下拉菜单列表中。当您不需要授权参数发送请求时，使用“No Auth”。
• Digest Auth：
  ①在“Digest Auth”流程中，客户端向服务器发送请求，服务器返回客户端的nonce和realm值；客户端对用户名、密码、nonce值、HTTP请求方法、被请求资源URI等组合后进行MD5运算，把计算得到的摘要信息发送给服务端。服务器然后发回客户端请求的数据。
  ②通过哈希算法对通信双方身份的认证十分常见，它的好处就是不必把具备密码的信息对外传输，只需将这些密码信息加入一个对方给定的随机值计算哈希值，最后将哈希值传给对方，对方就可以认证你的身份。
  ③Digest思想同样采如此，用了一种nonce随机数字符串，双方约好对哪些信息进行哈希运算即可完成双方身份的验证。Digest模式避免了密码在网络上明文传输，提高了安全性，但它仍然存在缺点，例如认证报文被攻击者拦截到攻击者可以获取到资源。
• OAuth 1.0：
  ①OAuth 1.0是一种可以让我们在不公开密码的情况下授权使用其他应用程序的授权模式。
  ②在Postman中按照以下步骤使用OAuth 1.0授权：
  ③在Authorization下来授权标签中选择“OAuth 1.0”授权模式；在“Add authorization data to” 下拉选择框中，选择对应的请求模式。
  ④当选择“Request Body/Request URL”时，Postman将检查请求方法是POST还是PUT，以及请求主体类型是否是x-www-form-urlencoded；如果是这样，Postman将增加授权参数到请求主体。对于所有其他情况，它会向URL添加授权参数。
• OAuth 2.0：
  ①OAuth 2.0作为OAuth 1.0的升级版本。在Postman中按照以下步骤进行使用：
  <1>在Authorization下来授权标签中选择“OAuth 2.0”授权模式在“Add authorization data to”下拉选择框中，选择对应的请求模式；
  <2>设置请求的授权参数，有以下三个选择：
  1、点击“Get New Access Token”按钮，在弹出的对话框中输入对应的参数；单击“Request Token”按钮获取对应的Token。接下来有了对应的Token后，就可以点击“Send”按钮发送请求了；
2、在“Access Token”输入框中输入一个Token，或者Token对应的环境变量，然后就可以点击“Send”按钮发送请求了；
3、在“Available Tokens”下拉框中选择已经存在的Token，然后发送请求。
• Bearer Token：
  ①Bearer Token是安全令牌。任何带有Bearer Token的用户都可以使用它来访问数据资源，而无需使用加密密钥。
  ②使用Bearer Token:
  1、从下拉菜单中选择“Bearer Token”。
2、要设置请求的授权参数，请输入令牌的值。
3、点击发送按钮。

CI/CD工具()

CI/CD详解：

• CI(Continuous integration，中文意思是持续集成)是一种软件开发时间。持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。借用网络图片对CI加以理解。
  

以上是关于软件测试知识概括的主要内容，如果未能解决你的问题，请参考以下文章

Vue高级知识概括

软件测试知识概括

软件开发流程知识概括

软件开发角色知识概括

软件开发角色知识概括

嵌入式数据库知识概括