菜鸟作——软件测试基础概念

说明：博客作者——a girl , 软件开发新人，小白一个。以下文章为自学总结，如有错误欢迎大家批评指正，第一次法博客，请大家多多指教哦 QAQ

---

**第一章：课程介绍
1-1： 软件测试概要：**
课程目标：
了解软件测试的含义
软件测试遵循的准则
软件测试有哪些分类？分别有哪些概念？
何时开始测试？测试方案如何设计？
测试流程是怎样的？怎么提bug？怎么写报告？
为什么要做自动化？怎么做？

软件测试的历史：

什么是软件测试：
早期定义：软件测试是对程序能够按预期运行建立起一种信心。
经典定义：测试是为了发现错误而执行程序的过程。
IEEE定义（ISO/IEC/IEEE 29119）：使用人工或者自动的手段来运行或测量软件系统的过程，以检验软件系统是否满足规定的要求，并找出与预期结果之间的差异。

软件测试的测试对象：
软件测试≠程序测试

五大要素和两个目标：

五大要素有：质量、人员、资源、流程、技术。
其中最主要的是软件质量，其他四个要素都是为质量服务的。
其次是人员，决定了技术，资源，流程，以及配置和使用。
技术包含了：软件测试技术、软件测试方法、使用的工具。技术是手段。
流程：测试计划，测试用例，测试执行，测试报告。有一些进入进出的标准（规范性，对软件测试做一个规范的要求）。
资源：测试所需要的硬件设备、网络环境、测试设备、测试时间（周期）。

注意：人不是资源。

目标：
①提升测试覆盖率-> 能够有效的保证软件的质量
②提升测试效率->能够使我们更好地完成软件测试

软件测试所遵循的原则
一、测试显示缺陷的存在，但不能证明系统不存在缺陷。
经过软件测试，可以发现软件中的故障；但是经过软件测试，不能保证软件就没有故障了。
二、穷尽测试是不可能的，应设定及时终止的条件。
三、测试应该尽早进行

四、缺陷具备群集特性
越是发现问题多的模块，越是需要重点测试的对象
五、测试的杀虫剂悖论
在测试中，如果采用同样的测试用例，同样的测试方法。多次重复的测试某一个模块，最后就不能再发现新的缺陷。所以说，测试用例和测试方法应该不定期的评审修改，并且增加不同的测试方法和用例来测试不同的部分，从而更多的发现软件的缺陷。
六、测试的二八原则
测试时间和资源往往是有限的，要找出所有的缺陷是不可能的，这时我们需要遵循二八原则。
把80%的时间或者资源用在20%的重点模块上，重点测试模块中20%的重要模块。来达到测试效率和资源配置的最佳的比例。
七、测试活动依赖于测试背景
针对不同的测试背景针对的活动是不同的，比如：电信级的软件对性能、大并发量的访问会有更高的要求。而金融，银行系统相关的软件，对安全性能要求更高。

**第二章：软件测试阶段、手段、模式：
2-1：软件测试流程**
软件测试的分类
按测试阶段来分类：
分为单元测试、集成测试、系统测试、验收测试

单元测试：
什么是单元测试？
对软件中的最小可测试单元进行检查和验证。
比如：在C语言中，单元可以看成C语言中的各个函数；在java面向对象的语言中，单元可以看成是对每一个类进行测试；对于一些有界面的功能软件，单元可以看成具体的功能项。（菜单项、子窗口的具体功能）
单元就是人为规定的，可测试的一个最小的模块。

单元测试的原则：
1：尽可能的保证各个测试用例是相互独立的。
应该避免在一个写的测试脚本中、测试类中，调用其他的依赖的类。

如果有错误，无法判断是login错误还是调用的getPassFromDB（username）方法错误。

2：一般由代码的开发人员实施，用以检验所开发的代码功能符合自己的设计要求。

单元测试的益处
1：能尽早发现缺陷
在测试的前期能够发现更多的缺陷，而且收益是最高的。
TDD：先编写单元测试，在编写功能的代码。并保证这些代码能够使单元测试通过。
不仅保证了代码单元测试成功，而且在编写代码的时候也是对需求设计的一个二次确认和理解的过程，这样可以保证开发人员在开发时对需求设计有一个清晰的理解。

2：有利于重构
软件产品，不变的就是变化，重构总是存在，如果进行了完善的单元测试，就能够最大限度的保证之后的重构，重构后软件的正确性。有了完善的单元测试，在重构时就能快速的识别出重构时出现问题的地方。

3：简化集成
通过单元测试，保证了最小单元模块的稳定性和正确性，为之后的集成测试奠定了基础。
只有正确的进行了单元测试和集成测试，才能更加的聚焦到模块的关系上。而不用再花更多的精力在单元的内部的验证上。

4：文档
代码级文档，如果代码出现修改，文档也需要修改，会使工作量成倍提高。
单元测试包含了对模块功能的基本的理解和特性，如果单元测试比较规范，那么通过对单元测试代码的阅读，就可以基本的理解整个模块的特性。所以很大程度上减少文档的存在。

5：用于设计
通过编写单元测试，可以把我们的设计思路体现在单元测试的组织当中，而且相对于UML基于图形的设计方法，单元测试最大的优点：设计的本身是可以用来验证设计的。

单元测试的限制：
1：不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径的错误。（软件测试不可能发现所有的缺陷，所以单元测试也不可能覆盖所有路径下的错误）。
2：每一行代码，一般需要3-5行测试代码才能完成单元测试，所以存在投入和产出的一个平衡。（不可能进行穷尽测试，所以需要找到投入和产出的一个平衡点，达到最高性价比）。

单元测试框架
XUnit 、JUnit(针对java的)、nUnit（针对.net）、PHPUnit（针对PHP）、CPPUnit（针对C++）

public class Calculator {

    private static int result; // 静态变量，用于存储运行结果

    public void add(int n) {

    result = result + n;

    }

    public void substract(int n) {

    result = result - 1; //Bug: 正确的应该是 result =result-n

    }

    public void multiply(int n) {

    } // 此方法尚未写好

    public void divide(int n) {

    result = result / n;

    }

    public void square(int n) {

    result = n * n;

    }

    public void squareRoot(int n){

    for (; ;) ; //Bug : 死循环

    }

    public void clear() { // 将结果清零

    result = 0;

    }

    public int getResult() {

    return result;

    }

}

import static org.junit.Assert.*;

import org.junit.After;
import org.junit.Before;
import org.junit.Test;

public class CalculatorTest {
     

    private static Calculator calculator = new Calculator();
    @Before
    public void setUp() throws Exception {
        calculator.clear();
    }

    @After
    public void tearDown() throws Exception {
    }

    @Test
    public void testAdd() {
        calculator.add(2);
        calculator.add(4);
        assertEquals(6,calculator.getResult());
    }

    @Test
    public void testSubstract() {
        calculator.add(10);
        calculator.substract(2);
        assertEquals(8,calculator.getResult());
    }

    @Test
    public void testMultiply() {
        calculator.add(10);
        calculator.multiply(2);
        assertEquals(20,calculator.getResult());
    }

    @Test
    public void testDivide() {
        calculator.add(10);
        calculator.divide(2);
        assertEquals(5,calculator.getResult());
    }

    @Test
    public void testSquare() {
        calculator.square(3);
        assertEquals(9,calculator.getResult());
    }


    @Test(timeout=1000)
    public void testSquareRoot() {
        calculator.squareRoot(16);
        assertEquals(4,calculator.getResult());
    }

    @Test(expected = ArithmeticException.class)

    public void divideByZero(){

        calculator.divide(0);

    }
}

慕课网：Junit单元测试必备工具

集成测试：

定义：是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。

集成测试的主要实施方案：
1：Big Bang
所有的东西组装好，然后一起进行测试
2：自顶向下
递增的组装软件结构的方法，一般来说从主程序开始->控制层逐层的向下来集成测试，覆盖到所有的模块。
3：自底向上（常用）
从底层的模块开始，逐层的向上组装，并逐层的进行测试。好处：针对我们已经组装过的测试，不需要对上一层进行编写装模块。模拟真实模块。
优点：比较好的锁定软件故障的位置。
4：核心系统集成
将核心的软件部件挑选出来，对这部分进行集中测试。在通过的基础上再扩展到外围的一些部件。直到最后形成稳定的系统。
5：高频集成
同步于我们的软件开发过程，每隔一段时间开发团队就对现有的代码进行一次集成测试。
持续集成就是高频集成

现在常用的：核心系统集成、高频集成
传统的瀑布式的软件测试中常用的：自顶向下、自底向上

集成测试&单元测试
1：测试的对象不同：
单元测试：针对的是软件的基本单元、最小的单元进行测试
集成测试：针对的是以模块和子系统为单元进行测试，主要进行的是模块与模块之间接口的关系

2：测试的依据不同
单元测试：主要针对的是软件的详细设计做测试，测试依据主要是详细的设计文档
集成测试：主要针对软件的概要进行测试，测试依据主要是概要。

3：测试的方法不同
单元测试：单元的类
集成测试：模块之间接口的继承

系统测试
定义：是将经过集成测试软件，作为计算机系统的一个部分，与系统中奇特部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效的测试，以发现软件潜在的问题，保证系统的正常运行。

关注点：
关注系统本身的使用
关注系统与其他相关系统间的连通
关注系统在不同使用压力下的表现（大并发量）
关注系统在真实使用环境下的表现

系统测试&集成测试
测试对象
集成测试：由通过了单元测试的各个模块所集成起来的构件
系统测试：除了软件之外，还包括计算机硬件以及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统。
测试时间
集成测试介于单元测试和系统测试之间测试
系统测试在集成测试之后
测试内容
集成测试：各个单元模块之间的接口
系统测试：整个系统的功能和性能
测试角度：
集成测试：偏于技术角度的验证
系统测试：偏于业务角度的验证

验收测试
定义：也称交付测试。针对用户需求、业务流程的正式的测试，确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统。

细分：
用户验收测试：开发方在交付于用户之前，自己进行的测试。
运行验收测试：是否可以正常运营维护，比如系统上线以后，是否可以备份等
合同和规范验收测试：针对政府法律的测试验收
alpha测试：在开发者所提供的场所及环境中运行，一般由用户测试，场所和环境是开发者提供的。
Beta测试：完全脱离了开发者的场所和环境，在用户提供的场所或者环境下进行测试。

2-2 软件测试手段
软件测试的分类
按测试手段来分类
按测试时对象的可见度，分为：黑盒测试，白盒测试
按状态分为：静态测试、动态测试
按测试执行的方式：手工测试、自动化测试

黑盒测试：

只从外部来看，通过外部的页面、功能进行测试。不考虑其内部的逻辑。
通过用户需求、事件驱动进行测试。

黑盒测试的优缺点：
优点
1：容易实施，不需要关注内部的实现。（操作比较简便）
2：更贴近用户的使用角度

缺点：
1：测试覆盖率较低，一般只能覆盖到代码量的百分之40
2：针对黑盒的自动化测试，复用率较低，维护成本较高。
（因为针对尤其像互联网方面，网站的页面功能、升级是千变万化的，所以成本较高，复用率比较低）

黑盒测试主要测试什么
1：是否有不正确或遗漏的功能？
2：在接口上，输入是否能正确的接受？能否输出正确的结果
3：是否有数据结构错误或外部信息（例如数据文件）访问错误
4：性能上是否能够满足要求

注意：黑盒测试是一种手段，在测试的不同阶段都可以用到，但是常用到系统测试阶段中。

黑盒测试的主要设计方法：

①等价类划分法：把相同相似的输入项归为一类，可以形成一些比较独特的输入项。
②边界值分析法：是一种特殊的等价类划分法，通过对边界值、区间进行分析。重要性在于开发人员在开发时边界值是容易失误的，因此边界值是需要重点关注的。
③错误推测法：是根据经验、直觉来判断程序中可能出现错误的地方，从而针对性设计用例（如：界面输入时要考虑特殊字符的处理、处理文件时要考虑文件不存在或文件超大等的处理）
④因果图法：拿到程序的需求规格说明书，根据每一种输入和输出（在因果图中，会把它们看做是原因和结果），对输入和输出赋以特定的标识符，然后将这些情况形成因果图，最终根据我们规格的语义的说明形成一个判定表，根据判定表来编写测试用例。这样的方法叫做因果图法。
⑤正交实验法：通过正交性，从一组数据中筛选出典型的、代表性数据的设计方法。通过筛选输入数据，在进行数据的输入输出。
⑥状态迁移图法：通过梳理软件功能点中的状态迁移关系，来编写测试用例。所谓状态迁移关系，比如：软件审批：提交审批->待审批->审批（分拒绝和通过）->退回提交者->修改->重新提交->审批通过 画出状态图来编写测试用例。
⑦：流程分析法：通过处理程序的逻辑执行的路径来设计测试用例。

白盒测试（又称为结构化测试、透明盒测试）

白盒测试强调逻辑的覆盖率，通过逻辑进行测试。

主要的逻辑单位：
语句、条件、条件组合、分支、路径
不同的逻辑单位。会有不同的覆盖方法，有：语句覆盖、条件覆盖、条件分支覆盖、分支覆盖（判定覆盖）、路径覆盖、判定和条件的组合覆盖

白盒测试主要的逻辑覆盖：
语句覆盖：程序测试用例出来以后，会保证程序的每条语句至少执行一次。
判定覆盖：保证程序的每一个分支至少执行一次。
条件覆盖：覆盖到条件的表达式，所有的表达式至少都计算一次。
条件覆盖：覆盖到条件的不同组合情况
路径覆盖：程序当中，每一条可能的路径都至少执行一次。
分支是路径的一部分。

白盒测试的优缺点
优点
1：迫使测试人员去仔细思考软件的实现，理解原理
2：可以检验代码中每条分支和路径
3：揭示隐藏在代码中的错误
4：对代码的测试比较彻底

缺点：
1：昂贵（较高的覆盖，工作量很大，成本高）
2：无法检测代码中遗漏的路径和数据敏感性错误
3：不能直接验证需求的正确性

白盒测试的主要测试方法：
①代码检测法：包括桌面检查，代码审查和走查，主要代码和设计的一致性，对代码本身进行检查。
②静态结构分析法：测试者通过使用测试工具，来分析源代码的测试结构、数据结构、内部的控制逻辑。通过内部结构的分析来设计测试用例。
③静态质量度量法：根据标准的质量模型（如ISO），然后来构造质量的度量模型，用于评估软件各个方面的要素。
④逻辑覆盖法：（语句覆盖、条件覆盖、条件的组合覆盖、分支覆盖或判定覆盖、路径覆盖、条件和判定的组合覆盖）
⑤基本路径测试法：白盒测试中主要的测试方法，在程序控制流图的基础上，通过分析控制构造的圈复杂度，导出基本可执行路径的集合，进而设计测试用例的方法。程序控制流图：描述程序控制流的图示的方法。

灰盒测试：
介于黑、白盒测试之间的，关注输出对于输入的正确性，同时也关注内部表现。

静态测试：
定义：静态测试是指无需执行被测程序，而是通过评审软件文档或代码，度量程序静态复杂度，检查软件是否符合编程标准，借以发现编写的程序不足之处，减少错误出现的概率。

动态测试：
定义：动态测试是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率，正确性和健壮性等。

注意：黑盒测试主要是动态测试的方法，白盒测试主要是静态测试的方法。

静态测试和动态测试之验车：
1：看看胎压，引擎，油表->静态测试
2：汽车发动起来，听听引擎的声音，开开看行不行->动态测试

手工测试
定义：由专门的测试人员从用户视角来验证软件是否满足设计要求的行为。更适用针对深度的测试和强调主观判断的测试。

众包测试、探索式测试 都是用手工测试来做的

自动化测试
定义：使用单独的测试工具控制测试的自动化执行以及对预期和结果进行自动检查。
单元测试、接口测试、性能测试一般用自动化测试来做。

手工测试VS自动化测试

2-3 软件测试模式

软件测试的分类
按测试模式来分类：
瀑布模式、敏捷测试、基于脚本的测试、基于风险的测试、探索式测试等。

传统的瀑布模型：

瀑布模型的优缺点
优点
1：强调需求、设计的作用
2：前一阶段完成后，只需关注后续阶段
3：为项目提供了按阶段划分的检查点，里程碑清晰
4：文档规范

缺点：
1：难以适应需求的频繁变化
2：项目周期后段才能看到成果
3：强制的里程碑、完成时间点
4：文档工作量大

V模型
是瀑布模型的变种
（没有实现测试尽早进行的要求）

W模型：（又称为双V模型）
是对V模型的一种改进，开发和测试并行，同步进行
W模型弊端：不能很好的执行迭代等。（先串行再并行的结构）

X模型：
（针对V模型的改进，解决交接和频繁集成的周期的问题）

H模型
把软件测试看作是一个独立的流程，贯穿软件的整个生命周期当中。与其他流程并发的进行。

其他流程：软件的其他的开发流程，比方说：设计流程，编码流程，甚至是测试流程。
可以和其他流程交叉着进行。

2-4 软件测试模型-敏捷测试
敏捷测试
Agile Testing–遵循敏捷宣言的一种测试实践

敏捷宣言：
个体与交互 重于 工程和工具
可用的软件 重于 完备和文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划

在每对比较当中，后者并非全无价值，但是我们更看重前者。

敏捷测试
特点：
1：强调从客户角度进行测试
2：重点关注迭代测试新功能，不再强调测试阶段
3：尽早测试，不间断测试，具备条件即测试
4：强调持续反馈
5：预防缺陷重于发现缺陷

敏捷测试VS传统测试
传统测试：
1：测试是质量的最后保护
2：严格的变更管理
3：预先的计划和细节的准备
4：重量级文档
5：各个阶段测试严格的入口和出口标准
6：更多在回归测试时进行重量级的自动化测试
7：严格依赖流程执行
8：测试团队和开发团队是相对独立的

敏捷测试：
1：开发和测试人员是紧密合作的，大家都有责任对软件负责
2：变更是可接受的，拥抱变更
3：计划随着进展时常调整
4：只需要绝对必要的文档。
5：各迭代之间已经没有明显的入口和出口标准
6：所有阶段都需要自动测试，每个人都需要做，是项目集成的一部分
7：流程不在需要严格执行
8：团队合作是无缝隙合作

基于脚本的测试-SBT
Script-based Testing
Scripted Testing(ST)
Exploratory Testing(ET)
先做测试设计，然后再执行测试
首先设计出Script，在手动测试中Script就是测试的用例，在自动化测试中Script就是自动化测试的脚本。
SBT遵照测试计划，属于比较传统的测试。

探索式测试（ET）
完全抛开测试脚本的测试
它是一种测试风格、思维而不是一种测试技术。

ET和ST使用

Pure Script:是完全的ST，完全会参照测试用例来完成，测试用例的编写也会很完善。
Freestyle ET是指完全自由的ET，没有任何文档做支持，也不对测试过程的要点进行记录。
VagueScript:还会写测试用例，但是用例的编写相对比较模糊，比如对预期结果、执行过程的描述相对会简单一些。
Framentary test cases：测试用例不会再写成规程文档，可能只会用一两句话来描述测试的思路。也可以看成是一个测试点的清单。
Charters：更偏向ET，ET会列出一个详细的列表，在列表中会指出测试对象、测试的策略，并指出可能的风险、参考的文档等。
Roles：给测试人员一个独立的角色，测试人员从这个角色出发去测试，测试的质量由测试人员自己决定。

ST VS ET
ST：
1：系统性强
2：容易管理、控制
3：设计在先，执行在后
4：主要是验证自己的思路
5：可预见性

ET：
1：自由灵活
2：和ST是互补的
3：执行和设计（思考）并行
4：不断和系统交互，带着问题测试
5：学习的过程

探索式测试的优点：
1：更能激发测试人员的创造性和工作乐趣。
2：增加了发现新的或较深入Bug的可能性
3：在较短时间内找到更多Bug以及对SUT（被测系统）作一个快速的评估
4：有利于更加有效的实施自动化
5：更加适用于敏捷项目
6：减少了简单、繁复用例的无谓编写时间

探索式测试的缺点：
1：测试管理上有局限性，较难协调和控制
2：对于Bug的重复利用和重视上作用有限
3：对测试人员的测试技能和业务知识深度依赖较大
4：只有在SUT（被测系统）完全可用的前提下才更有作用
5：ET的生产率很难定义
6：ET本身较难进行自动化

局部探索式测试
测试系统的五大要素：
输入、状态、代码、用户数据、执行环境
①输入：包括接受输出，产生输出，存储数据，进行运算
测试时一般是从：输入顺序、输出内容、输出异常几个角度来考虑测试要点。
②状态：临时状态、永久状态
状态有运行时有效、阶段有效为临时的状态；数据保存、文件保存状态相对是永久的状态。
状态的信息可以协助我们更加有效的判断测试输入和测试输出。
③代码路径：更多的指的是对代码的覆盖（白盒测试中对代码的测试方法）。
④用户数据：测试时更多的应该采用真实的用户的数据，尽量的模拟实际运用时的数据。
如果条件不具备，也需要构造合理的测试数据。
⑤执行环境：包括软件运行的操作系统，系统组网的网络的top，与系统交互的一些第三方系统，系统的配置数据，运行我们系统的硬件设备都需要考虑对被测系统产生的相应的影响。

全局探索式测试：

商业区：用户在使用期间主要使用到的一些功能。
旅馆区：软件在休息或者未在实际运行时的一些功能。一般指运行在后台的一些进程或定时任务等功能。
历史区：版本遗留代码中的功能，或者是在原来测试中曾经发现过较多问题的功能。
旅游区：一般指新用户会使用或者比较关注的一些功能。比如：新手指引、新用户注册的功能。
娱乐区：指系统主要功能之外的，一些辅助性的功能。
破旧区：系统已经废弃或者隐藏的，用户看不到的，或者一般不提及的功能。

探索式测试的方法：指南测试法、麻烦测试法、懒汉测试法、恶邻测试法、伸向测试法、破坏测试法等

执行探索式测试流程：

①Know You Mession：了解测试重点、测试环境、测试方向，拥有一个测试的总体的思路
②Learning Session：详细学习、探索被测系统，了解系统的业务逻辑、具体的功能，深入的学习被测系统。
③Coverage Session：主要探索式测试的实施阶段：主要要完成，主要功能点的测试验收，完成测试点的覆盖。
尽可能的把需要测试的东西都覆盖到。
④Deep Session：在覆盖式测试的基础上，做深入的、发散式的、探索的测试，挖掘一些深层次的问题，这个阶段我们会更加深入的把我们的测试做的更深入一点。
⑤Close Session：对前面的测试工作有一个总结，整理探索的过程，记录探索的信息，并且根据这些记录和过程的总结分析测试过程有无遗漏，覆盖率怎么样。
⑥：在close Session之后，进行阶段大扫除，针对close Session总结的信息再针对性的进行大扫除的行动。也有把大扫除阶段包含在Deep Session当中，发动项目相关或不相关的人员共同找bug，来保证系统的完整性。

基于风险的测试-RBT
Risk-based Testing
一种基于对软件失效的风险评估并以此指导测试计划、设计、执行、结果评价的软件测试类型。

哪些是风险？
质量风险：软件的功能，应用性，性能等方面的质量问题。还有软件功能的缺失，数据的转换等等导致的问题都可以说是质量风险。
管理风险：人员的技能不足，项目的人力不足，测试环境不具备，被测系统的需求不清晰。被测系统关联的第三方的系统有问题导致没法进行联调等
风险级别=风险可能性*风险严重度

识别风险
可能性：
1：复杂性
2：时间压力
3：高变更率
4：技能水平
5：地理分散度

严重程度：
1：使用频率
2：失效可视性
3：商业损失
4：组织负面影响和损害
5：社会损失和法律责任

风险要素 分=Sum(单项权重*得分)

RBT优点
优先测试高风险的功能


基于模型的测试-MBT

它是一种软件测试的类型，测试用例是从一个模型当中完整或者部分导出得到的。这个模型描述了我们被测系统的某个方面，通常是功能部分。

注意：这里的模型和之前的W模型、V模型、H模型、瀑布模型是不一样的，它是指对测试功能点建模而不是对我们的测试过程而建立模型。

对基于模型的测试描述 相关链接：https://blogs.msdn.microsoft.com/sechina/2009/11/18.123/

主要的MBT工具
Spec Explorer(Microsoft)
GraphWalker(OpenSource)
http://graphwalker.github.io/
Tcases(OpenSource)
https://github.com/Cornutum/tcases
modelJunit(OpenSource)
http://www.cs.waikato.ac.nz/~marku/mbt/modeljunit/

3-1 软件测试类型
软件测试的分类
按测试类型来分类

功能测试：
定义：根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。简单来说就是给提供给用户的软件功能进行验证。
针对的问题
功能错误或遗漏、界面问题、性能错误、数据及访问错误、初始化及终止错误

功能测试工具

3-2 软件测试类型-性能测试
性能测试
指的是验证软件系统的性能可以满足需求规格给定的指标要求。
性能测试：包括负载测试、压力测试、稳定性测试
①负载测试：在测试过程中来逐步增加负载，并且记录下被测系统相应的性能表现。
最终确定出系统在正常的指标下的一个最大的负载。
②压力测试：测试系统在极限情况下的压力情况。确定系统在什么样的负载压力下会失效、不能正常运行。确定出我们的系统所能承受的最大的极限。
③稳定性测试：一般是稍大于正常业务量的一个负载，对系统进行持续的、长时间的测试，以确定在较长时间下系统的稳定性情况。

性能指标

性能测试工具

静态性能评估
开发Web应用时，基于一系列Web应用页面性能优化的最佳实践对Web应用的页面进行静态分析，并给出评估结果的性能分析方法。（是一种静态的分析方法）

在Crome浏览器->扩展程序中安装两个插件

访问一个页面，如访问www.baidu.com，点击右上角工具，打开YSlow工具。
点击Run Test执行

就会对软件的页面进行一个静态的分析。并对这个网站给出一个评估的分数和级别。

级别一般会分为A、B、C、D、E、F总共六级。
可以看到百度的页面分级为B级，评分是90分。

YSlow进行静态评级时的标准：
1：尽量减少Http的请求
2：使用CDN（内容分发网络）
3：避免空的SRC和Href的编码
4：为文件头指定过期标签
5：有没有使用gzip技术对文件进行压缩
6：把css样式表尽量放在页面的顶部
7：尽量吧js脚本放在页面的底部（便于用户访问时尽早的呈现内容）
8：在使用css样式表的时候，尽量的避免使用css表达式的使用
9：在使用js和css时尽量使用外部文件，方便缓存
10：减少DNS的爬找次数
11：精简js和css样式表
12：避免url的跳转（会消耗性能）
13：删除重复的js和css的脚本
14：配置ETags技术
15：使ajax可以缓存，加快我们的响应
16：使用get来完成ajax的请求
17：减少DOM元素的请求
18：避免404的错误
19：减少Cookie的大小
20：使用没有cookie的域
21：避免滤镜的使用
22：在HTML中不要使用缩放图片
23：小图标尽量是可以缓存的。

开发者工具->打开插件（执行分析）

应用性能管理（APM）
Application performance Managment提供对系统的实时监控以实现性能管理、故障管理的解决方案。
www.tingyun.com
听云官网

针对于Web应用的APM产品的功能

CPU资源的情况，占用的内存，都可视化。业务响应比较慢的情况等。

3-3 软件测试类型-安全测试
安全测试
定义：对软件产品进行测试以确保其符合产品安全需求和质量标准。

渗透测试
通过模拟对软件测试的恶意攻击行为来评估系统安全性的一种测试

渗透测试VS安全测试：

因为安全测试涉及的方面更广一些，所以安全测试相对于渗透测试要难一些。

OWASP：
Open Web Application Security Project（开放的Web应用安全项目）
OWASP官方网站 www.owasp.org

每年OWSP会发布最有威胁的安全漏洞（前十），并且对其进行详细的分析。

1：注入漏洞
2：失效的身份认证和会话管理
3：跨站脚本
4：不安全的对象的直接引用
5：安全配置错误
6：敏感信息泄漏（未对关键信息进行加密）
7：工人级别的访问控制确实（访问一个网站，能够在内部导航到用户没有权限到达的地方）
8：跨站请求伪造（CSRF）
9：使用了已知的具有漏洞的组件
10：未被验证的转发和重定向

测试指南：
指引安全测试人员如何进行测试的网站

安全测试工具

3-4 软件测试类型-兼容性测试
兼容性测试

浏览器内核

浏览器兼容性测试工具

browsershots.org
在其中输入想要检测的网址，就会返回该网页在不同浏览器上的界面截图
通过不同浏览器上界面的比对，可以看浏览器兼容的差异。

3-5 软件测试类型-文档测试
文档测试
定义：针对软件产品的交付品，配套的文档类部件的测试。如用户手册、使用说明、用户帮助文档等。
文档测试的关注要点：
完整性、正确性、一致性、易理解性、易浏览性

可靠性测试

易用性测试：
定义：易用性测试是指测试用户使用软件时是否感觉方便，是否能保证用户使用体验的测试类型。
注意：易用性和可用性是两个不同的概念，易用性：是否容易方便使用；可用性：软件是否可以使用。
一般易用性测试针对UI界面的交互、页面是否过于复杂、有没有误导用户的指引、网站的布局，样式。

本地化测试
定义：针对软件的本地化版本实施的针对性测试。

部署测试：
定义：也称为安装测试，主要验证系统部署过程，并确保软件经过安装测试后可以正常使用。

无障碍测试：
Accessibility Test：也称可访问性测试。是指软件需要提供便于特殊人群使用的功能，包括视障、听障、老年人、身体残疾用户等，无障碍测试则是针对这部分功能的测试。

4-1 其他测试的分类
其他的一些测试类型概念：

回归测试
定义：软件功能修改后，对软件进行重新测试以确认修改没有引入新的错误或导致其他部分产生错误。
回归测试的中心在关键模块和重点功能组件。
软件研发周期中会进行多次回归测试，且尽量实现自动化。

Monkey测试：
定义：Monkey测试，也称为搞怪测试。就是用一些随机、稀奇古怪的方式来操作软件，以测试系统的健壮性和稳定性。

冒烟测试
定义：来自于硬件板卡验证术语。软件上则用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。
（冒烟测试更多的针对全流程上的测试，而回归测试等更多的是针对模块测试）

A/B测试
定义：多用于互联网行业，通过为页面提供2个版本给用户使用并记录相关的用户行为数据，来确定更优化设计的一种测试方案。

A/B测试实施要点：
1：多个方案并行
2：每次测试仅改动一个变量
3：按照某种规则进行优胜劣汰

A/B测试工具

总结：

教程来源自慕课网-软件测试基础概念篇（https://www.imooc.com/learn/700）
如有侵权，请联系作者删除，谢谢！