软件测试基本概念

测试

快速了解测试

软件测试职位

功能测试 --> 自动化测试 --> 性能测试 --> 白盒测试 --> 安全测试

软件测试

软件测试概念: 为了发现程序中的错误而执行程序的过程

1. 软件测试是为了发现程序存在的代码或业务逻辑错误
2. 软件测试是为了检验产品是否符合用户需求
3. 软件测试是为了提高用户的体验

测试误区

参考该文章

软件测试的原则

1、 测试应该尽早介入

为什么测试要尽早介入呢，简单的说就是保证软件质量，降低风险和成本。测试人员一般在需求阶段就开始介入，使缺陷在需求或设计阶段就被发现，缺陷发现越早，修复的成本就越小。

2、所有的测试都应该追溯到用户需求

3、程序员应该避免检查自己的程序（单元测试除外）

因为程序员对于自己的作品,思维具有局限性,无法保证测试质量,交给第三方或者专业测试,运用各种测试技术,利用丰富的测试经验对BUG的敏感,去提高软件的质量

4、测试用例

设计测试用例时应考虑到合法的输入和不合法的输入以及各种边界条件,特殊情况下还要执照极端状态和意外状态

• 杀虫剂悖论
  反复使用相同的杀虫剂会导致害虫对杀虫剂产生免疫而无法杀死害虫。软件测试也一样。如果一直使用相同的测试方法或手段，可能无法发现新的bug。为了解决这个问题，测试用例应当定期修订和评审，增加新的或不同的测试用例帮助发现更多的缺陷。测试人员不能一直依赖于现有的测试技术，而要不断的提升测试方法以提高测试效率。

5、二八原则（测试发现的错误中80%很可能起源于20%的模块中）

缺陷集群性表明小部分模块包含大部分的缺陷。软件测试中存在Pareto原则：80%的缺陷发现在20%的模块中。一个功能模块发现的缺陷越高，那存在的未被发现的缺陷也越高，故发现的缺陷与未发现的缺陷成正比。

6、对错误结果要进行一个确认过程

• “没有错误就是好”为谬论
  有可能99%没有bug的软件也是不能使用的。如果对错误的需求进行了彻底的测试，这种情况就发生了。软件测试不仅是找出缺陷，同时也需要确认软件是否满足需求。如果开发出来的产品不满足用户的需求，即便找到和修复了缺陷也作用不大。

7、制定严格的测试计划

• 测试活动依赖于测试内容
  根据业务的不同，软件测试内部也分为不同的行业，比如游戏行业、电商行业、金融行业。不同的行业，测试活动的开展都有所不同，比如测试技术、测试工具的选择，测试流程都不尽相同，所以软件测试的活动开展依赖于所测试的内容。

8、完全测试是不可能的,测试需要终止

• 测试显示软件存在缺陷
  测试只能证明软件中存在缺陷，但并不能证明软件中不存在缺陷。软件测试是为了降低存在缺陷的可能性，即便是没有找到缺陷，也不能证明软件是完美的。
• 穷尽测试是不可能的
  现在软件的规模越来越大，复杂度越来越高，想做到完全性的测试是不可能的。在测试阶段，测试人员可以根据风险和优先级来进行集中和高强度的测试，从而保证软件的质量。

9、妥善保存测试过程中的所有文档

软件测试的分类

1. 按测试阶段划分

• 单元测试
  开发做的(开发的自测行为,开发写完代码自己测试)
• 集成测试
  完成模块和模块的调用,功能和功能之间的对接
  (开发都是各自完成自己被分配到的模块,这些模块需要集成起来进行测试,比如登陆后要跳转到指定的页面,集成测试这部分可以是开发做,也可以是测试做,接口测试这块也属于集成测试的范围)
• 系统测试
  这个是测试人员的工作范围,这里的系统不是指ios,安卓这类系统,而是把所有的功能集合起来,做一个完整的,全面的一个测试
• 验收测试(正式验收测试,Alpha测试,Beta测试)
  这个一般是客户或者产品经理的范围,就是这个产品是否和最初设计的理念,达到产品的要求
  验收测试，有些也叫UAT测试，项目开发期间，有些公司除了开发环境（开发用），测试环境（测试用），还会有UAT环境（预生产环境），生产环境（项目上线的环境）。
  正式验收测试 : 是指最后真正要上线的一个测试
  Alpha测试 : 一种前期的用户测试,公司内部组织员工及部分用户,模拟实际操作环境下进行验收测试(内测)
  Beta测试 : 一种后期用户测试,此时系统已经通过内部测试,大部分错误已经改正,即将正式发布,在一个或多个真实环境下发布版本,进行测试(公测)
  Alpha测试和Beta测试都是开发和测试不能参与的,不能对数据进行修改,必须由用户进行测试
  Alpha测试是在开发环境下进行测试, Beta测试是在生产环境下进行测试(玩游戏的有个概念,叫内测删档和内测不删档,就是分别指Alpha测试和Beta测试)

2. 按测试技术划分

• 白盒测试
  指了解代码的一个逻辑,对代码功能的进行一个测试,属于代码级别
• 黑盒测试
  指不需了解代码逻辑,只需要根据输入输入的结果判断(在某种程度上等同于功能测试,性能测试也属于黑盒测试)
• 灰盒测试
  介于白盒和黑盒测试之间

3. 被测试对象是否运行划分

• 动态测试
  指定是功能测试,需要进行操作,去测试
• 静态测试(文档检查,代码走查,界面检查)
  不用执行这个程序,直接观察,一行一行对代码,界面进行审查

4. 按不同测试手段划分

• 手工测试
• 自动化测试

5.按测试包含内容划分

• 功能测试
  等同于黑盒测试,相当于"点点点",测试功能模块是否是正常的
• 界面测试
  界面各方面的按钮,文本框,这些风格设计是否正常
• 安全测试
  Dos攻击,SQL注入,网站安全方面,安全测试是为了找到网站的后门,网站的缺陷
• 兼容性测试
  比如一个app在不同的安卓,ios系统,不同的手机上进行一个兼容性测试
• 易用性测试
  站在用户的角度,判断这个程序好不好用,是否容易上手
• 性能测试
  是指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
  详细分析链接
• 压力测试
  验证系统在已经处于极限负载下或者或者某指标处于饱和状态下系统性能的表现
• 负载测试
  验证系统在一定压力下延长系统运行时间，直到系统性能出现“拐点”
• 恢复测试
  也称为灾备测试,系统宕机,数据库死锁,要多长时间恢复

6. 其他测试

• 冒烟测试
  预发布测试,版本马上要上线了,会对主干进行一个测试,如果重要的功能都有问题,那么会将这个版本打回,重新发布版本后,再进行测试
• 交叉测试
  每个人的测试思维都是有限的，交叉测试是指对测试人员与其他测试人员负责的内容进行互换，再进行一次测试，尝试去发现其中没有被发现的bug
• 回归测试
  产品有很多缺陷,提交给开发,开发修改完bug后,再进行测试,查看功能是否正常
• 探索性测试(测试思维)
  没有任何规律性可循,以一种其他的思维对功能进行测试,尝试能否发现隐藏的bug

测试与开发的合作

开发的一句口头禅可能是“我之前跑的好好的，没问题”，或“在我的机器上没问题”，很多情况下这个尴尬的问题可能是环境配置造成的。开发的时候默认环境已经设置好了，当完成开发交付时，遗漏了环境设置。上线服务清单就是一个罗列环境设置的地方。软件工程师在交付他的产品包中不仅仅是需求的实现代码，应该包含使软件能够正常运行的完整说明，像环境搭建方法应该是交付测试的产品内容之一。

测试贯穿整个产品开发过程，包括规范的流程，完备的文档，及时的沟通，是所有团队成员共同参与。

开发与测试的思维差异

软件开发意识中的bug大多是造成程序panic的或输出错误结果的情况，因此自测程序的测试用例是有限的，没有panic或几条用例输出符合预期即通过检验，并且开发人员一般只测试自己负责的模块而不关注整个系统。软件测试要更全面的覆盖整个软件，用例的数量会大大增加，不光要全面考虑可能性，还要有创造性，甚至骚操作。

软件开发更倾向无打扰的创造出一个新生事物，所有流程、规范、管理，凡是和编程没有直接关系的事情都是累赘，破坏思路的坏东西，因此开发会不由自主的抗拒流程规范。测试会更推崇规范的流程，因为测试测的是别人的产品，如果没有一个规范，没有标准，测试工作将会是一团乱麻。

思维方式和工作习惯上差异是开发转测试的一道门槛，随着敏捷开发的推行，作为一个团队，每个成员的工作会有更多的交叉，需要培养devops文化才能更好的进行敏捷开发