软件测试知识概括

软件测试基础

什么是软件：

• 软件是计算机程序、程序所用的数据以及有关文档资料的集合。
• 软件是计算机的灵魂。软件又可以分为两大类:系统软件和应用软件。
• 系统软件:系统软件是生成、准备和执行其他程序所需要的一组文件和程序。如操作系统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抓包工具详解：

Jmeter(压力测试工具)

压力测试工具：

• 做压力测试的常用工具做压力测试，一般要使用工具， 人工是没办法做的。
• 最常用的工具是LoadRunner, 但是LoadRunner毕竟是收费软件，而且使用上也比较复杂。
• 现在越来越多的人开始使用Jmeter来做压力测试。 免费， 而且使用上非常简单。
• 链接：
  ①JMeter下载及使用
  ②全网最全最细的jmeter接口测试教程以及接口测试流程详解

简介：

• Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试，但后来扩展到其他测试领域。它可以用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器，等等。JMeter可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。
• Apache jmeter 可以用于对静态的和动态的资源（文件，Servlet，Perl脚本，java对象，数据库和查询，FTP服务器等等）的性能进行测试。它可以用于对服务器、网络或对象模拟繁重的负载来测试它们的强度或分析不同压力类型下的整体性能。你可以使用它做性能的图形分析或在大并发负载测试你的服务器/脚本/对象。

jmeter的使用：

• 线程组：代表一定数量的并发用户，它可以用来模拟并发用户发送请求。线程组是为模拟并发负载而设计。
• 取样器（Sampler）：模拟各种请求。所有实际的测试任务都由取样器承担，存在很多种请求。如：HTTP 、ftp请求等等。
• 监听器：负责收集测试结果，同时也被告知了结果显示的方式。功能是对取样器的请求结果显示、统计一些数据（吞吐量、KB/S……）等。
• 断言：用于来判断请求响应的结果是否如用户所期望，是否正确。它可以用来隔离问题域，即在确保功能正确的前提下执行压力测试。这个限制对于有效的测试是非常有用的。
• 定时器：负责定义请求（线程）之间的延迟间隔，模拟对服务器的连续请求。
• 逻辑控制器：允许自定义JMeter发送请求的行为逻辑，它与Sampler结合使用可以模拟复杂的请求序列。
• 配置元件维护Sampler需要的配置信息，并根据实际的需要会修改请求的内容。
• 前置处理器和后置处理器负责在生成请求之前和之后完成工作。前置处理器常常用来修改请求的设置，后置处理器则常常用来处理响应的数据。

性能测试专有名词：

• 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、响应时间、并发量的要求是多少？这样计算

CI/CD工具

CI/CD详解：

• CI(Continuous integration，中文意思是持续集成)是一种软件开发时间。持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。借用网络图片对CI加以理解。
  
• CD(Continuous Delivery， 中文意思持续交付)是在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境(类生产环境)中。比如，我们完成单元测试后，可以把代码部署到连接数据库的Staging环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境。下图反应的是CI/CD 的大概工作模式。

Devops详解：

• 什么是DevOps：
  ①DevOps是一种思想或方法论。它涵盖开发、测试、运维的整个过程!
  ②DevOps强调软件开发人员与软件测试、软件运维、质量保障(QA)部门之间有效的沟通与协作。强调
  ③通过自动化的方法管理软件变更,软件集成。
  ④使软件从构建到测试、发布更加快捷、可靠,最终按时交付软件。
  
• 为什么使用DevOps：
  ①传统上在软件开发中(无论是瀑布模型还是敏捷方式，敏捷也比较传统)，都由开发团队"来构建软件。
  ②开发团队需要与运维团队进行了大规模的交接"。运维团队负责执行一系列部署"活动，将软件代码移至生产环境，并负责维护后续的系统稳定运行。生产环境的基础设施与开发或测试不同。需要有额外检查和平衡，以确保它一切功能正常。部署是由不同的人完成的，运维团队之前从未见过或听说过任何此类软件。
  ③DevOps这种软件开发方法，涉及到软件整个开发生命周期，这些活动只能在DevOps中实现，而不是敏捷或瀑布流
  ④DevOps是在较短的开发周期内开发嬴质量软件的首选方法，同时可以提高客户满意度。
  
• 如何落地实现Devops理念：
  ①Devops 兴起于2009年，近年来由于云计算、互联网的发展，促进了Devops的基础设施及工具链的发展，涌现了一大批优秀的工具，
  ②这些工具包括开发，测试，运维的各个领域，例如:GitHub，Git/svn，Docker、Jenkins，HudSon,Ant/Maven/Gradle,QUnit.JMeter等，看下图:
  
• jenkins：
  ①Jenkins是一个开源的、提供友好操作界面的持续集成(CI)工具，起源于Hudson（Hudson是商用的），主要用于持续、自动的构建/测试软件项目、监控外部任务的运行（这个比较抽象，暂且写上，不做解释）。
  ②Jenkins用Java语言编写，可在Tomcat等流行的servlet容器中运行，也可独立运行。通常与版本管理工具(SCM)、构建工具结合使用。常用的版本控制工具有SVN、GIT，构建工具有Maven、Ant、Gradle。
• 公司开发流程：
  

jenkins详解：

• “持续”是什么意思？
  ①频繁发布：持续实践背后的目标是能够频繁地交付高质量的软件。此处的交付频率是可变的，可由开发团队或公司定义。对于某些产品，一季度、一个月、一周或一天交付一次可能已经足够频繁了。对于另一些来说，一天可能需要多次交付也是可行的。所谓持续也有“偶尔、按需”的方面。最终目标是相同的：在可重复、可靠的过程中为最终用户提供高质量的软件更新。通常，这可以通过很少甚至无需用户的交互或掌握的知识来完成（想想设备更新）。
  ②自动化流程：实现此频率的关键是用自动化流程来处理软件生产中的方方面面。这包括构建、测试、分析、版本控制，以及在某些情况下的部署。
  ③可重复：如果我们使用的自动化流程在给定相同输入的情况下始终具有相同的行为，则这个过程应该是可重复的。也就是说，如果我们把某个历史版本的代码作为输入，我们应该得到对应相同的可交付产出。这也假设我们有相同版本的外部依赖项（即我们不创建该版本代码使用的其它交付物）。理想情况下，这也意味着可以对管道中的流程进行版本控制和重建（请参阅稍后的 DevOps 讨论）。
  ④快速迭代：“快速”在这里是个相对术语，但无论软件更新/发布的频率如何，预期的持续过程都会以高效的方式将源代码转换为交付物。自动化负责大部分工作，但自动化处理的过程可能仍然很慢。例如，对于每天需要多次发布候选版更新的产品来说，一轮集成测试integrated testing下来耗时就要大半天可能就太慢了。
• 持续集成如何监测变更？
  ①轮询：监测程序反复询问代码管理系统，“代码仓库里有什么我感兴趣的新东西吗？”当代码管理系统有新的变更时，监测程序会“唤醒”并完成其工作以获取新代码并构建/测试它。
  ②定期：监测程序配置为定期启动构建，无论源码是否有变更。理想情况下，如果没有变更，则不会构建任何新内容，因此这不会增加额外的成本。
  ③推送：这与用于代码管理系统检查的监测程序相反。在这种情况下，代码管理系统被配置为提交变更到``仓库时将“推送”一个通知到监测程序。最常见的是，这可以以 webhook 的形式完成 —— 在新代码被推送时一个挂勾hook的程序通过互联网向监测程序发送通知。为此，监测程序必须具有可以通过网络接收 webhook 信息的开放端口。
• 链接：jenkins详解

上线、部署、发布、回滚简述：

• 上线：
  ①指你的团队从源码管理库中获取服务代码某个版本的快照，并用它处理线上流量的过程。
  ②我认为整个上线过程由四个不同的专门的小流程组成：构建（build）、测试、部署和发布。
• 部署：
  ①指你的团队在生产环境的基础设置中安装新版本服务代码的过程。当我们说新版软件被 部署 时，我们的意思是它正在生产环境的基础设施的某个地方运行。
  ②基础设置可以是 AWS 上的一个新启动的 EC2 实例，也可以是在数据中心的 Kubernetes 集群中的某个容器中运行的一个 Docker 容器。
  ③你软件已成功启动，通过了健康检查，并且已准备好（像你希望的那样！）来处理线上流量，但实际上可能没有收到任何流量。
• 发布：
  ①我们的意思是它负责服务线上流量。在动词形式中， 发布 是将线上流量转移到新版本的过程。
  ②鉴于这个定义，与上线新的二进制文件有关的所有风险 —— 服务中断、愤怒的用户、 The Register 中的刻薄内容
• 回滚：
  ①迟早，很可能不久之后，你的团队就会上线一些功能有问题的服务。回滚（和它危险的、不可预测的、压力山大的兄弟 —— 前滚 roll-forward）指将线上服务退回到某个已知状态的过程，通常是重新发布最近的版本。
• 链接：Deploy != Release（第一部分）：部署与发布的区别，以及为什么这很重要

单元测试

单元测试简介：

• 单元测试是编写测试代码，用来检测特定的、明确的、细颗粒的功能。单元测试并不一定保证程序功能是正确的，更不保证整体业务是准备的。
• 单元测试不仅仅用来保证当前代码的正确性，更重要的是用来保证代码修复、改进或重构之后的正确性。
• 一般来说，单元测试任务包括：
  ①接口功能测试：用来保证接口功能的正确性。
  ②局部数据结构测试（不常用）：用来保证接口中的数据结构是正确的
  <1>比如变量有无初始值
  <2>变量是否溢出
  ③边界条件测试：
  <1>变量没有赋值（即为NULL）
  <2>变量是数值（或字符)
  1、主要边界：最小值，最大值，无穷大（对于DOUBLE等）
  2、溢出边界（期望异常或拒绝服务）：最小值-1，最大值+1
  3、临近边界：最小值+1，最大值-1
  <3>变量是字符串
  1、引用“字符变量”的边界
  2、空字符串
  3、对字符串长度应用“数值变量”的边界
  <4>变量是集合
  1、空集合
  2、对集合的大小应用“数值变量”的边界
  3、调整次序：升序、降序
  <4>变量有规律
  1、比如对于Math.sqrt，给出n^2-1，和n2+1的边界
  ④所有独立执行通路测试：保证每一条代码，每个分支都经过测试
  <1>代码覆盖率
  1、语句覆盖：保证每一个语句都执行到了
  2、判定覆盖（分支覆盖）：保证每一个分支都执行到
  3、条件覆盖：保证每一个条件都覆盖到true和false（即if、while中的条件语句）
  4、路径覆盖：保证每一个路径都覆盖到
  <2>相关软件
  1、Cobertura：语句覆盖
  2、Emma: Eclipse插件Eclemma
  ⑤各条错误处理通路测试：保证每一个异常都经过测试

JUNIT：

• JUnit是Java单元测试框架，已经在Eclipse中默认安装。目前主流的有JUnit3和JUnit4。JUnit3中，测试用例需要继承TestCase类。JUnit4中，测试用例无需继承 TestCase 类，只需要使用@Test等注解。
• Assert：
  ①Junit3和Junit4都提供了一个Assert类（虽然package不同，但是大致差不多）。
  ②Assert类中定义了很多静态方法来进行断言。列表如下：

assertTrue(String message, boolean condition) 要求condition == true
assertFalse(String message, boolean condition) 要求condition == false
fail(String message) 必然失败，同样要求代码不可达
assertEquals(String message, XXX expected,XXX actual) 要求expected.equals(actual)
assertArrayEquals(String message, XXX[] expecteds,XXX [] actuals) 要求expected.equalsArray(actual)
assertNotNull(String message, Object object) 要求object!=null
assertNull(String message, Object object) 要求object==null
assertSame(String message, Object expected, Object actual) 要求expected == actual
assertNotSame(String message, Object unexpected,Object actual) 要求expected != actual
assertThat(String reason, T actual, Matcher matcher) 要求matcher.matches(actual) == true

• Mock/Stub：
  ①Mock和Stub是两种测试代码功能的方法。Mock测重于对功能的模拟。Stub测重于对功能的测试重现。比如对于List接口，Mock会直接对List进行模拟，而Stub会新建一个实现了List的TestList，在其中编写测试的代码。
  ②强烈建议优先选择Mock方式，因为Mock方式下，模拟代码与测试代码放在一起，易读性好，而且扩展性、灵活性都比Stub好。
• 代码覆盖率：
  ①比较流行的工具是Emma和Jacoco,Ecliplse插件有eclemma。eclemma2.0之前采用的是Emma，之后采用的是Jacoco。
  ②这里主要介绍一下Jacoco。Eclmama由于是Eclipse插件，所以非常易用，就不多做介绍了。
  <1>Jacoco：
  1、Jacoco可以嵌入到Ant、Maven中，也可以使用Java Agent技术监控任意Java程序，也可以使用Java Api来定制功能。
  2、Jacoco会监控JVM中的调用，生成监控结果（默认保存在jacoco.exec文件中），然后分析此结果，配合源代码生成覆盖率报告。需要注意的是：监控和分析这两步，必须使用相同的Class文件，否则由于Class不同，而无法定位到具体的方法，导致覆盖率均为0%。

单元测试规范：

• 提交Git前必须单元测试：
  ①在开发中，自己开发的新模块，只有在通过单元测试之后才能提交Git 库，防止未经测试的代码更改流入到生产环节中（代码审核）。
  ②Git提交前的代码已经做了单元测试，未做单元测试的需求和补丁单打回。
• 单元测试必须遵循AIR原则。
  ①A：Automatic（自动化）：单元测试应该是全自动化，而非交互式的。输出结果不需要人肉验证。
  ②I：Independent（独立型）：为了保证单元测试稳定可靠且易于维护，单元测试用例之间不能互相调用，不需要规定执行的先后顺序。
  ③R：Repeatable（可重复）：单元测试是可重复执行的，外界环境的变化不会影响测试结果。
• 项目启动或者maven编译时必须处理测试断言中未通过用例
• 对于增量迭代的代码必须同步修改单元测试
• 单元测试单测粒度至多是类级别，一般是方法级别
• 单元测试代码必须写在如下工程目录：src/java/test，不允许写在业务代码目录下
• 覆盖率指标：
  
• 遵守BCDE原则，以保证被测试模块的交付质量：
  ①B：Border，边界值测试，包括循环、 特殊取、特殊取特殊时间点、数据顺序、初始值是否存在null、 变量是否溢出（期望异常，拒绝服务，最小值-1，最大值+1）、参数边界（最小值，最大值，无穷大）、字符串（字符串长度等）、集合（大小边界）、查询接口返回列表（查询返回结果集长度判定100%，不超过单次阈值）、其他（系统业务侧边界和规则校验）。
  ②C：Correct，正确的输入，并得到预期结果。
  ③D：Design，设计文档相结合，来编写单元测试。
  ④E：强制错误信息输入（如：非法数据、异常流程业务允许等），强制错误信息输入（如：非法数据、异常流程业务允许等），并得到预期结果。
• 提交测试报告：
  ①测试报告只能导出需要测试的文件并打包上传到需求单补丁单中（不允许打全量）。
  ②压缩包名：实际需求单标题。
  ③推荐：数据库相关的查询，更新，删除等操作，不能假设数据库里的数据是存在的，或者直接操作数据库把数据插入进去，请使用程序插入或者导入数据的方式来准备数据。
  ④推荐：对于不可测的代码建议做必要的重构，使代码变得可测，避免为了达到测试要求而书写不规范测试代码。
  ⑤推荐：在解决方案评审阶段，开发人员需要和测试人员一起确定单元测试范围，单元测试最好覆盖所有测试用例。
  ⑥推荐：多层条件语句建议使用卫语句、策略模式、状态模式重构。

private方法如何进行单元测试？

• 不测试：
  ①这是最消极的一种办法，毕竟大家都不会闲的没事，非要对一个private方法进行测试，一般来说都是有某种不可抗拒原因导致我们必须想办法进行测试（譬如说要求测试覆盖率达到一定标准，包含了复杂业务逻辑实现），否则的活没必要测试private方法。
• 改权限：
  ①将private方法变成protected或者package
  ②这也是一种办法吧，但问题随之而来——当初我为啥要将方法的权限修饰为private访问权限?这种方法在我看来根本不可取。
• 进行内部测试：
  ①在被测类中编写仅对测试有用的代码。
  ②至于这种就更扯淡了，逻辑测试写在一起，大概只有初学者会这么搞吧，当你在某个项目组里这么做的时候你最好祈祷别被负责人打死。
• 使用反射：
  ①此处我推荐使用反射来完成，这种才是真正解决问题的方式。

Intellij IDEA run coverage之覆盖率测试：

• 查看单元测试覆盖度
  
• 查看具体覆盖：绿色部分表示已经覆盖的地方，红色部分表示单元测试还没有覆盖的行。
• 导出测试报告：