软件测试（1）

1、软件测试的概念

软件测试就是利用技术手段进行对生产的软件进行检查，查看其是否满足用户的实际需求。相当于拿着放大镜对两张看似相同的图片找不同，测试工作类似于从产品的各个角度进行分析寻找出和用户需求的不同之处。

2、软件测试的目的

利用最少的人力、物力、财力，找到软件中得问题并修复，从而降低商业风险。

3、软件测试的分类

• 根据阶段来分：
  • 单元测试：对最小的软件单元模块进行验证，是为了确保软件被正确的编码，通常是白盒测试，对代码风格和规则、业务逻辑等进行测试，以便于尽早发现和解决不易显现的错误。    
  • 集成测试：通过测试发现模块接口有关的问题。
  • 系统测试：对照需求文档，进行黑盒测试，检查系统是否满足了需求的定义。测试的不仅仅是软件，也要对文档、兼容性等进行测试。
  • 验收测试：分为α和β测试。α测试是指用户在开发人员的指导下进行的一个软件测试，是一个可控的环境，发现的bug由开发人员进行登记并修复。β测试是用户在自己的工作环境下进行的测试，开发人员不在场，发现的bug自己记录，然后汇报给开发进行修改。
• 根据可见度来分：
  • 白盒测试：⼜称单元测试（针对程序源代码进⾏测试）
  • 灰盒测试：⼜称接⼝测试（看不⻅部分代码）
  • 黑盒测试：
    ⼜称功能测试（完全看不⻅程序源代码，只能针对功能进⾏验证）

4、软件模型

• 质量模型：功能性、性能特性、安全性、易用性、兼容性、可靠性、可维护性、可移植性

质量模型指明了软件测试的切入方面。

• 瀑布模型

• V模型

• W模型

(1)测试阶段划分得更全面，不仅仅是单元测试、集成测试和系统测试;

(2)测试与开发是并行的，从需求测试就应该开始介入;

(3)提出尽早测试的概念，这样可以降低缺陷修复成本;

(4)测试对象不仅仅是程序，还包括需求或其他的相关文档。

• H模型

        软件测试的过程活动完全独立，形成了一个完全独立的流程，贯穿于整个产品的周期，与其他流程并发进行，某个测试点准备就绪后就可以从测试准备阶段进行到测试执行阶段；软件测试可以根据被测产品的不同分层进行。

(1)测试是一个独立的过程;

(2)测试达到准入条件，才可以执行;

(3)测试对象是整个产品包，而不仅仅是程度、需求或相关说明书。

5、测试流程

①需求分析

-明确产品需求

-各部门站在各自的专业角度来对需求进行查漏补缺

②编写测试计划

-测什么：测试的目标及其范围

-谁来测：测试人员及其进度安排

-怎么测：测试策略和测试工具

③编写测试用例

测试用例的切入点（质量模型）：功能性、性能特性、安全性、易用性、兼容性、可靠性、可维护性、可移植性

④执行测试用例

执行已经编写好的测试用例，查看预期结果和实际结果是否一致

⑤管理缺陷

对缺陷进行管理

⑥编写测试总结报告

 测试目标 、测试过程、缺陷统计、缺陷分析、测试总结

6、测试用例

用例：用户执行的案例。

考虑点：功能性、性能特性、安全性、易用性、兼容性、可靠性、可维护性、可移植性

测试用例里的内容：用例编号、用例标题、所属模块、优先级、前置条件、测试步骤、 测试数据、预期结果、实际结果等。

7、测试用例的设计方法

• 等价类划分法

主要解决有大量数据需要测试，但不能进行穷举测试的问题，把测试的输入域分为有效等价类和无效等价类，然后取里面的一些数据来代表这整个集合。

• 边界值法

和等价类划分法结合使用，主要测试的是输入条件的边界。选择刚好等于、刚好大于、刚好小于的边界值进行测试。应用场景：在等价类划分的基础上针对有边界范围的测试数据进行测试（主要关注边界）。常见修饰词语：最多，最少，至多，至少，大小，尺寸等

边界值覆盖了等价类划分？ （X）   只能覆盖等价类划分中的位数的取值。

• 判定表法 

解决多条件依赖的问题，明确条件桩（输入条件）和动作桩（产生的动作），对条件进行全组合，以此来确定动作项，生成测试用例，假设有n个条件,每个条件的取值是2个，那么共有2的N次方中规则。

• 场景法（流程图法）

用流程图表示用户的使用场景，通过覆盖流程的路径来设计测试用例。是将系统的多个功能进行整合使用，不单单测试一个功能。

• 错误推荐法

在经验的基础上推测系统可能出现的问题。在任务量大时间紧迫的情况下，根据之前的经验找出容易出错的模块进行重点测试。或者在时间充裕的情况下再次测试问题较多的模块。

8、缺陷

定义：软件在使用过程中存在的任何问题都是缺陷，也叫做bug。

判定标准：

多功能：功能不在需求说明书说明的范围内。

少功能：为实现明确提出的功能。

功能错误：实现的功能有问题。

隐形功能错误：未明确指出但是应该实现的功能。

不易使用：运行缓慢，用户体验不好

产生的原因：

需求阶段：需求有歧义，表述理解不清楚。

设计阶段：设计文档存在问题或者缺陷。

编码阶段：代码出现问题。

运行阶段： 软件硬件系统本身故障导致。

生命周期：

注入bug:在需求、设计、编码阶段都有可能产生bug。

发现bug:测试阶段

修复bug:开发人员修复解决。

缺陷提交的要素：

缺陷的编号

缺陷的严重成度：非常严重（引起系统宕机崩溃，重大功能缺少），严重（主功能有错误），一般（次要功能有问题），次要（界面不符合大众审美、错别字）

缺陷的优先级：和用例的优先级相同。

缺陷的类型：功能错误，兼容性，界面错误，易用性…

缺陷的状态 ：new （新建）、open（打开，确定是缺陷，开发人员进行修改）、rejected（拒绝，产品经理不认为是bug）、fixed(修复)、closed(关闭)、reopen(问题没解决、再次打开)、postponed(延期解决)