软件测试（基础）入口

一、软件的基本概念

1.1 软件

软件是计算机系统中与硬件相互依存的另一部分，它包括程序，数据及其相关文档的完整集合。

1.2软件的分类

软件主要分为两大类，一种是系统软件，另一种是应用软件，

应用软件中有简单的分为架构类和单机类，在架构类中最长见的是Ｂ/S架构和C/S架构两种。

B/S架构：

B/S架构中，B表示浏览器（browser），S表示服务端（server），使用B/S架构的软件，只需安装一次浏览器即可。

它的优点：版本更新及时

它的缺点：对带宽要求高，

C/S架构：

C/S架构中，C表示客户端（client ），S表示服务端（server），C/S架构的软件需要联网使用，客户端需要单独安装，例如：（QQ,游戏等）。

它的优点：因为需要单独安装在本地，所以大量资源安装在本地，每次使用不需要连接服务器下载资源。

它的缺点：版本更新不及时，BUG修复周期长。

1.3 软件的生命周期

    软件的生命周期，又称为软件生存周期。它是按开发软件的规模和复杂程度,从时间上把软件开发整个（从计划开发开始到软件报废为止的整个历史阶段）进行分解，形成相对独立的几个阶段。
    每个阶段又分解成几个具体的任务，按规定神顺序依次完成各阶段的任务并规定一套标准的文档作为个阶段的开发成果，最后生产出高质量的软件。

1.3.1 软件生命周期概括一下几个阶段

问题定义：确定软件要解决什么问题。
可行性研究：确定问题是否有可以解决的方案。
需求分析：深入具体的需要进行分析。
概要设计：设计出实现软件的几种可能的方案，设计程序的体系架构。
详细设计：从概要设计中选出一条最符合当前条件的设计方案进行详细的模块，算法，数据结构的设计。
编码和单元测试：根据详细设计的文档进行编码实现。
综合测试：根据各类文档，对开发出来的软件进行测试。
软件维护：测试通过后上线使用，在使用中发现的问题进行维护。

1.4 软件开发模型

由于项目、需求的模式不同，为了开发软件的生命过程更加合理，所以要选出合适软件开发模型，生产出更高质量的产品。

1.5 软件开发文档

从测试人员角度看开发过程中产生的文档

需求分析文档

把需求分析作为依据。
概要设计文档

把需求文档中的需求，进行概要设计，要知道设计文档有没有把需求文档中的需求完全覆盖。
详细设计文档

详细设计文档中要包含（方案，策略，架构，体系，接口名称，接口的调用方式，数据库的结合，数据的样式）
测试设计文档

测试的方案（包含哪些方面，需要进行哪些方面的测试，要测试）
测试用例

用例是测试工作的一个依据，一个规范。
测试报告

测试报告中包含（有多少各测试用例，通过多少，失败多少、有多少缺陷，哪些修复，哪些没修复，为什么没修复 ... 等等）

二、软件测试概念

2.1 软件测试定义

软件测试是使用人工或者自动的手段来运行或测定某个软件系统的过程，其目的在与检验它是否满足规定的需求或弄清预期结果和实际结果之间的差别。

2.2 软件测试的分类

这里我按测试的阶段和测试的方法进行分类，如下图。

根据上图，在每个阶段使用到不同的方法进行一个对比，如下表。

	单元测试	集成测试	冒烟测试	系统测试	验收测试
测试阶段	编码后	单元测试完成后	提测	冒烟测试通过后	发布前
测试对象	代码，最小模块	模块间的接口	整个系统系统	整个系统	整个系统
测试人员	白盒测试工程师或开发工程师	白盒测试、开发工程师	黑盒测试	黑盒测试	最终用户或需求方
测试依据	代码、详细文档、注释	单元测试模块、概要设计文档	冒烟测试用例	需求文档，测试方案，测试用例	用户需求、验收标准
测试方法	白盒测试	灰盒测试	黑盒测试（自动或手动）	黑盒测试	黑盒测试
测试内容	模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试	模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响	主要对只要功能进行测试，测试软件是否具有可测试行	功能、界面、可靠性、易用性、性能、兼容性、安全性等	同系统测试(功能...各类文档等)

具体每种测试类型到后面的章节，具体在做具体分析，这里只是先大致了解一下。

2.3 软件测试模型

2.3.1 V模型

V模型是最具有意义的测试模型，在20世纪80年代后期提出，由英国国家计算机中心文献发布，其主旨是为了改进软件开发的效率和效果。V模型本身是软件开发中瀑布模型的变种，它反映了测试活动与分析和设计的关系

在V模型中虽然强调了测试的重要性，但是它还是遵循瀑布模型的线性思路，在项目前期测试并没有能够更早的介入，导致前期存在的缺陷不行及时的发现、修复，导致项目后期在测试中发现缺陷无法修复或修复成本过高的结果。

2.3.2W模型

W模型由Evolutif公司提出：开发一个V，测试一个V，组合的W模型；测试伴随着整个软件开发周期，并且测试的对象不仅仅是程序，需求和设计同样要测试

在w模型中测试人员更早的展开测试工作，在项目前期对需求，设计的文档进行测试更早的发现缺陷，但是过于依赖软件开发和软件测试保持一前一后的线性关系，依然无法支持迭代，自发性和需求的变更调整。

2.3.3H模型

人们发现虽然软件开发中需求、设计、编码等活动被分阶段执行、但是实践中，他们并不是完全串行的，它们之间更多时候是交叉进行的，更多的是迭代执行；为了解决上面的问题，有专家专门提出了H模型，它将测试活动完全独立出来，形成一个完全独立的流程，同时将测试准备和测试执行也清晰表现出来。

H模型中将开发和测试分离开，实现一个并行的工作方式，不仅可以使测试尽早的开展工作，不再依赖开发的工作流程，具备更高的灵活性，但是因为并行的工作方式，所以需要开发和测试有较好沟通与配合才才能发挥H模型的优势。

2.4 软件测试的原则

2.4.1 原则一、所有的测试的测试都应该追溯到用户需求

“产品缺陷的80%以上是在产品开发过程中的需求定义阶段引入的，如果需求得到准确的验证，则可以消除80%的返工问题，节省总项目投入费用的45%”。

2.4.2 原则二、尽早启动测试工作

2.4.3 原则三、Pareto法则应用于软件测试

Pareto法则是由意大利经济学家帕累托提出，又称28效率法则。

在测试是哦嗯一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的缺陷,而系统测试又能找到其余缺陷中的80%，最后4%的缺陷可能只有在用户的大范围、长时间使用后才能暴露出来。

2.4.4 原则四、穷尽测试是不可能的

由于很少由机会对一个应用软件进行所有可能的测试，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。

2.4.5 原则五、杀虫剂怪事

软件测试越多，其对测试的免疫力越强的现象。

为了防止杀虫剂怪事，软件测试人员必须不断编写不同的、新的测试程序，对程序的不同部分进行测试，以找出更多软件缺陷。

2.4.6 原则六、前进两步，后退一步

测试用的一个基本问题是----缺陷修复总会以（20-50）%的机率引入新的缺陷。

每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会一隐蔽的方式被破坏。

2.4.7 原则七、三心二意

细心、耐心、信心

团队合作的沟通意识、时刻保持怀疑的态度且由缺陷预防意识

2.5 软件测试覆盖率

我们知道了软件原则中软件测试是不可能做到穷尽测试的，那如何知道在测试工作后是否是有效的，完整的？如何去衡量测试后软件的质量呢？那么我们就可以通过测试覆盖率知道在测试工作中测试了哪些代码、功能，也可以知道哪些代码和功能没有测试，指导之后的测试工作。

2.5.1软件测试覆盖率概念

覆用来度量测试完整性的一个手段，是测试技术有效性的一个度量。

2.5.2软件测试覆盖率计算公式

覆盖率= （被执行一次的item数）/item的总数

2.5.3特点

通过覆盖率数据，可以检测测试工作是否充分
分析出测试的弱点在哪方面
指导测试设计能够增加覆盖率到测试用例，有效提高测试质量，但是测试设计用例不能一味追求覆盖率，测试成本随覆盖率增加而增加

2.5.4 覆盖率的运用

简单的测试覆盖率：本次测试执行的用例数量 / 所有的测试用例总数要求达到100%

测试覆盖率对黑盒测试来说，主要指两方面：需求覆盖和 **用例覆盖 **

需求覆盖：它表示在测试中有哪些需求被测试到了，其测试到的频率有多大，这些需求在系统所有需求中占的比例有多大通过设计一定的测试用例，要求每个测试点都要被测试到。

需求覆盖 = （被验证到的需求数量）/总的需求数量

用例覆盖：主要体现在每轮测试验证通过的用例数在总用例中的占比。

用例覆盖 = （通过验证的用例数）/总的用例数

基于产品的测试覆盖率：以测试需求点数量 / 所有需求中需求数量要求达到100%

基于白盒的测试覆盖率：测试代码覆盖行数 / 总代码行数要求达到80% 基于自动化的测试覆盖率：

自动化测试覆盖的测试场景 / 所有自动化测试用例基于28原则，自动化测试用例选择应该更看重20%的核心功能

三、软件测试流程

posted @ 2020-07-26 22:10 比巴卜b 阅读(384) 评论(0) 收藏举报

刷新页面返回顶部

比巴卜b