软件测试

一. 软件测试的七项基本原则

1. 测试尽早介入

软件测试的目的是保证质量，预防风险，降低成本，其中成本包括缺陷的修复成本，缺陷有一个特点就是越早发现的缺陷，修复成本越低。测试尽早介入，就是为了能够在需求阶段就能找出需求与设计方面的缺陷，降低后期的修复成本。

2. 测试活动依赖于测试内容

在面试过程中有时总会遇到面试官部“做软件测试什么最重要”，想来做过测试的都知道“需求”最重要，对测试人员来说是需求，对公司来说就是业务。

根据业务的不同，软件测试内部也分不同的行业，比如游戏行业，金融行业，电商行业等等。

不同的行业，测试活动的开展都有所有不同，比如工具的选择，测试流程都不尽相同，所以软件测试活动的开展依赖于所测试的内容。

3. 穷尽测试是不可能

现在的软件规模越来越大，复杂度越来越高，想做到完全性的测试就完全不可能的。就是软件的规模和复杂度有所减少，但要做完全也测试也是不能做到。那在测试阶段，软件测试人员可以根据风险和优先级来进行集中测试和高强度测试，从而保证软件的质量。

4. 测试显示软件存在缺陷

测试人员只能证明软件中存在缺陷，但并不能证明软件中没有缺陷，软件完美。软件测试人员可以通过软件测试活动，找出软件中大部分缺陷，避免软件在上线后给用户带损失，给公司带来风险。

5. 缺陷集群性（2/8原则)

世界上万事万物都符合二八原则，比如著名的财富理论：世界20%的人掌握了世界上80%的财富。

还有成长理论：判断一个人是否成功，主要看他20%的业余时间做什么事情。

软件测试也符合二八原则:

功能：一个软件20%为主要功能，会花费软件测试人员80%的时间。

缺陷：一个功能模块发现的缺陷越高，那存在的未被发现的缺陷也越高，故，发现的缺陷与未发现的缺陷成正比。

6. 杀虫剂悖论

开发刚转测当天，测试人员是一个bug接一个bug的提，但随着测试进度的推进，每天发现在的缺陷会越来越少，到最后简直就是不能够发现缺陷了。

这并不能说明自己测试的软件中没有bug了！！！

这是因为测试人员对缺陷产生了免疫能力，就算是一个bug放在测试人员面前，测试人员也不一定能发现。这就像害虫对杀虫剂产生了免疫，杀不死一样的。

解决方案有：

a.内部测试人员交叉测试。

b.测试用例常用常更新，在测试过程中根据软件的特性修改测试用例。

c.不变地变化测试方法，不要使用单一的测试方法去测试软件，根据软件内容使用不同的测试手段、测试方法。

7. 无错就是好是谬论

假设一个软件完全没有bug，完美无缺，但是不符合用户的需求，那能说这个软件是OK的么？

判断一个软件的好与不好，主要依据的还是用户需求，是否实现用户所期盼的结果，并不是仅仅依赖于软件中是否存在缺陷

有些伙伴会说测试理论没什么用，但理论看似没用，却能培养我们的测试思维，让我们对软件测试有更多的认识和了解，测试人员不要只去追求技术上的超越，而思维上的建立也是至关重要。

二. 软件测试流程，阶段，方法，类型

1. 测试流程

首先拿到测试的SRS（需求规格说明书），提取SRS中的测试点后编写Test Plan（测试计划），之后小组分配测试任务，根据自己负责模块编写Test Case（测试用例），然后执行Test Case，提交发现bug到相应缺陷管理工具，跟踪定位配合开发解决缺陷，最后回归测试后编写测试报告以及个人总结。

2. 测试类型

（1）功能测试（黑盒测试）

测试软件产品的功能，要考虑每个细节功能，每个功能可能存在的问题，不需要测试软件产品的内部结构和处理过程。

利用黑盒技术设计测试用例的方法有：等价类划分法，边界值分析法，错误推测发，因果图方法，正交表分析法，场景分析法。

 （2）性能测试

一般是通过自动化的测试工具模拟多种正常，峰值，以及异常负载条件来对系统的各项性能指标进行测试。主要关注产品整体的多用户并发下的稳定性和健壮性。

有负载测试和压力测试。

负载测试：确定在各种负载下系统性能的指标，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。

压力测试：通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

（3）界面（UI）测试

关注用户体验，该产品是否易用，易懂，规范，美观，安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）

（4）兼容性测试

硬件兼容，软件兼容，网络兼容

（5） 安全测试

 （6）接口测试

3. 测试方法

（1）按照测试技术分为：

 a. 黑盒测试：黑盒测试又叫功能测试或数据驱动测试，在完全不考虑程序内部结构和内部特性的情况下，通过软件的外部表现 来发现其缺陷和错误。

 b. 白盒测试：白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构进行测试程序，通过测试来检测产品内部逻辑是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。

 c. 灰盒测试：

（2）按照测试手段分为：手工测试，自动化测试

（3）按照是否执行被测试软件来分：

 a. 静态测试：是指不运行软件，测试包括代码检查、静态结构分析、代码质量度量等，主要对软件需求说明书、设计说明书、 软件源代码进行检查与分析。

  b. 动态测试：指通过运行被测程序，检查运行结果与预期结果的差异，分析差异原因，并分析软件运行效率、健壮性等性能。 动态测试是目前公司主要的测试方式。

（4）按照过程阶段来分：

 a. 单元测试：通过模块(类/方法/函数)测试，使代码达到设计要求 主要目的是针对编码过程中可能存在的各种错误，例如用户输入验证过程中的边界值的错误。

 b. 集成测试：将经过单元测试的模块逐步组装成完整的程序。 主要目的是检查各单元与其它程序部分之间的接口是否存在问题，各模块功能之间是否有影响。

 c. 系统测试：是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起进行测试。 系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方 ，进行改正。

 d. 验收测试：验收测试是在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的最后一次软件测试活动，也称为交付测试。 通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要。

三. 测试分层

现在的开发模式大多是前后端分离MVC/MVP/MVVM，每一层都有对应的测试

             （图片引用自网上，特表示感谢(#^.^#)）

相应的测试

个人延伸：

前后端分离的项目，看懂接口文档在接口测试中非常重要（后续会在http和postman文章中进行详述）

{
    code：0,
    message: "success",
    data: { 
        "id": 1,
		"title": "校园生活纪实",
        "content": "某某中学，被外地人占领的高考工厂"
    }

}

1. code: 一般用于返回状态码，1表示成功，非1表示各种不同的错误,10000可以用来表示客户端传参错误
2. message: 描述信息，成功时为”success”，错误时则是错误信息
3. data: 成功时返回的数据，类型为对象或数组

 

四. 软件开发模型

1. 瀑布模型：适用于需求很明确的项目，分阶段向下进行，无法回溯

2. 迭代模型：需求不明确，迭代版本系统

3. 敏捷开发模型：敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中，软件项目被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

4. 测试驱动开发模型：先编写测试代码，再写开发代码

五. 软件测试模型

1. V模型：反映了测试与开发阶段之间一一对应的特点，测试在开发之后，出错后回归测试量大

 

 

2. W模型：测试伴随整个开发周期，测试与开发同步进行，有利于尽早发现问题

 

 

3. H模型：软件测试活动完全独立，与其他流程并行

 

 

会持续更新补充(#^.^#)！！！