【软件测试】

软件需求是 a.用户解决问题或达到目标所需条件或权能(Capability)。 b. 系统或系统部件要
满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。一种反映上面 a 或 b 所述条件或权能的文档说明（它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制）

（2）类别

①用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。

②软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据就是软件需求。

软件需求是测试人员进行测试工作的基本依据。

用户需求就是一句话；软件需求是一个文档（详细描述用户需求如何实现）

通常使用的是软件需求来进行开发测试。

（3）测试人员角度的需求

需求是测试人员开展软件测试工作的依据。

在具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例。

过程如下，业务需求->软件功能需求点->测试需求点->测试用例

（4）如何深入了解需求

测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。

只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确，从终端用户的使用场景到端到端的覆盖率较高的测试用例集。

①参加需求评审会议

②查阅文档

③沟通

（5）需求重要的原因

从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。

对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计。

3.测试用例

1.定义

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

2.作用

简要而言，测试用例解决了测什么、怎么测的问题。

测试过程中可能存在的问题：不知道是否较全面的测试了所有功能、测试的覆盖率无法衡量、对新版本的重复测试很难实施、存在大量冗余测试影响测试效率。

具体来说，测试用例的作用是：

① 测试用例提高了测试人员工作效率/降低了测试人员工作的重复性问题。

② 测试用例是建立自动化（自动化就是把测试人员双手2解放，让代码代替人员执行测试了）的基础。

4.BUG（软件错误）

当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是软件错误(BUG)。

当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

5.软件测试&开发生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。如果把软件看成是有生命的事物，那么软件的生命周期可以分成6个阶段，即：

需求分析（分析需求是否合理，需求是否完整）【测试人员了解需求、对需求进行分解，得出测试需求】

计划（计划谁来开发，谁来测试，开发多久，测试多久等）【根据需求编写测试计划/测试方案】

设计（根据需求来设计如何开发软件）【测试人员适当的了解设计，对于设计测试用例是很有帮助的，测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例】

编码（开发软件）【测试人员一般是不需要编码的，但已经编码的模块，专业的白盒测试人员可以计划执行单元测试，完善、细化测试用例以及调整测试计划和方案】

测试（测试软件，编写测试报告）【测试阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试，在执行的过程中记录、管理缺陷，测试完成后编写测试报告】

运行维护（如有线上问题，需求测试人员协助开发定位问题+解决问题）【测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人。】

6.开发模型

（1）瀑布模型

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

特点：线性

优点：每个阶段做什么、产出什么很清晰（强调开发的阶段性；强调早期计划及需求调查；强调产品测试）

缺点：风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会（依赖于早期进行的
唯一一次需求调查，不能适应需求的变化； –由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程）

适用项目：小型项目

瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。这会给项目带来很大的风险，尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶段的工作大面积返工。

尽管瀑布模型存在很大的缺陷，例如，在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。但是目前很多软件企业还是沿用了瀑布模型的线性思想，在这个基础上做出自己的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺入迭代的思想。

在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户。

（2）螺旋模型

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。

这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了。

优点：每个阶段都会进行风险分析，避免一些线上问题发生（强调严格的全过程风险管理；强调各开发阶段的质量；提供机会检讨项目是否有价值继续下去）

缺点：风险分析可能会分析错，需要财力人力的投入（引入非常严格的风险识别、风险分析和风险控制；这对风险管理的技能水平提出了很高的要求；这需要人员、资金和时间的投入）

适用项目：大型复杂风险大的项目

（3）增量、迭代

增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。增量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。

增量通常和迭代混为一谈，但是其实两者是有区别的。增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。

（4）敏捷

①敏捷宣言：

个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者

由敏捷宣言可以看出，敏捷其实是有关软件开发的社会工程的。敏捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的领域。

敏捷开发有很多种方式，其中scrum是比较流行的一种。

②scrum

a.三大角色

product owner(产品经理)

scrum master(项目经理)

team(研发团队)

product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布
计划，对产品负责。

scrum master 负责召开各种会议，协调项目，为研发团队服务。

team则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

b.迭代开发

与瀑布不同，scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。

c.基本流程

产品负责人负责整理user story，形成左侧的product backlog。

发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。

迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。

每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。

演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。

回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

7.测试模型

（1）V模型

用户需求：PM将用户需求收集形成软件需求

需求分析与系统设计：验证需求是否正确、确定编程语言、确定框架

概要设计：项目结构设计

详细设计：每个接口是什么、涉及哪些库表、设计哪些任务

编码：编写软件

单元测试：测试每一个方法(函数)

集成测试：将多个方法集成到一起测试

系统测试：模块和模块之间需要没有影响

验收测试：验收的人是产品和运营

特点：左边是开发，右边是测试（类似于瀑布模型）

优点：测试被划分成许多类型

缺点：测试人员介入过晚，发现问题时机过晚

V模型提出的目的是改进软件开发的效率和效果。是瀑布模型的变种。

明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系

V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求

局限性:仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试

（2）W模型

特点：开发一个V模型、测试一个V模型（测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的）

优点：测试人员较早介入了需求（有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度）

缺点：测试人员和开发人员一定程度上还是串行的，不能拥抱变化，不能适用于敏捷。

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑

8.BUG

（1）BUG描述方式

1️⃣发现问题的版本

开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。

2️⃣问题出现的环境

环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。

3️⃣错误重现的步骤

描述问题重现的最短步骤。

4️⃣预期行为的描述

要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。要相信：测试人员是最懂需求的。

5️⃣错误行为的描述

描述错误的现象。crash等可以上传log，UI问题可以有截图。

6️⃣其他

某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。

7️⃣不要把多个bug放到一起

在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。

（2）BUG级别

1️⃣Blocker（崩溃）：

阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）

2️⃣Critical（严重）：

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）

3️⃣Major（一般）：

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）

4️⃣Minor（次要）：

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

3.BUG生命周期

测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态.

BUG状态转换图：

● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed

缺陷状态变更流程每个项目团队的实际做法可能不大一样。并且需要结合实际的开发流程和协作流程来使用。

例如，测试人员新发现的Bug，必须由测试组长评审后才决定是否Open并分派给开发人员。测试人员Open的Bug可以直接分派给Bug对应的程序模块的负责人，也可以要求都先统一提交给开发主管，由开发主管审核后再决定是否分派给开发人员进行修改。 Bug的跟踪以及状态变更应该遵循一些基本原则：

测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试，确保相同的问题不再出现，才能关闭缺陷。

对于拒绝修改和延迟修改的Bug，需要经过包含测试人员代表和开发人员代表、用户方面的代表（或代表用户角度的人）的评审。

9.测试

（1）如何开始测试

测试准备：

1、阅读所有项目有关的文档，包括：需求文档、设计文档、用户手册
2、尽可能参加各种项目会议，了解项目的背景、人员组成、尽可能的了解需求和业务。特别针对业务
专业性较强的项目，例如银行业务，需要了解各种业务知识，如高低柜、一二三类账户等、存款、贷款等。
3、熟悉项目所使用的测试管理工具、配置管理工具，获取对应的地址和登录方式

4、阅读已有的测试方案和测试案例
5、阅读旧有的bug库，了解系统功能。尤其重要的是和现有的测试团队保持一致的故障定级原则
6、了解公司的规范要求，特别是用例编写规范、用例执行规范、bug提交规范、测试工具工具使用规范等

简要而言：

1、充分理解需求

2、确定测试计划

3、执行测试

4、项目上线+维护

在进行了以上的准备工作之后，第一次测试工作到来了，我们需要与测试组长确认具体的工作内容：

1、测试的计划是什么？
2、测试的内容是什么？test case有多少？安排了几天执行？有没有自由测试的时间？
3、我要测试的内容开发人员是谁？需求人员是谁？
4、分配给我的测试内容是否需要特殊的测试资源？资源是否满足需要？
在确认了以上内容之后，就可以开始测试的执行了。

（2）测试的执行

现在我们开始进行测试了：

1. 打开待测试的系统
2. 打开测试管理工具用例模块，开始执行用例
3. 发现bug！进行复现并确认bug的复现步骤
4. 记录bug
5. 沟通bug
6. 验证以前提交的bug
7. 确认本次测试完成
8. 编写测试报告

执行测试时处理要做到测试用例和需求的覆盖外，还要有临时发挥的能力。根据自己的经验、对测试的感悟以及随机测试可以发现很多根据测试用例无法发现的缺陷。

不能拘泥于测试用例或者已经有的测试方法，在测试执行过程中要不断总结测试方法和测试故障模型。真正优秀的测试人员在执行测试时是想着做，做着想，这样的测试效果才好，尤其是在测试过程中，对程序的处理相当了解的情况下，测试的思路会更加清晰和全面。

（3）BUG管理

1、软件测试同样存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度和深度
2、开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的bug较多，加强他开发模块的测试广度和深度
3、多进行逆向思维和发散性的思维
4、不要局限于用例和需求文档
5、尽早介入项目, 不要等到开发的差不多了再介入项目

（4）产生争执怎么办

1、先检查自身，是否bug描述不清楚
2、站在用户角度考虑问题应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。在争执时，可以问一句：如果你是用户，你可以接受么？
3、BUG定级要有理有据
4、提高自身的技术和业务水平. 不光要提出问题, 最好也能提出解决方案
5、开发人员不接受时，不要争吵

二.测试用例

1.测试用例的基本要素

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试

评价测试用例的标准：对比好坏用例的评价标准

用例表达清楚，无二义性。。
用例可操作性强。
用例的输入与输出明确。一条用例只有一个预期结果。
用例的可维护性好。
用例对需求的覆盖率高。

2.测试用例的好处

（1）提高测试效率，节省测试时间

（2）测试用例是自动化测试用例前提

3.测试用例的设计方法

（1）基于需求进行测试用例的设计

基于需求设计测试用例是测试设计和开发测试用例的基础，第一步就要分析测试需求，验证需求是否正确、完整、无二义性，并且逻辑自洽。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者测试项，然后根据每一个测试点进行测试用例的设计。

在分析测试需求时，一般分为功能测试需求和非功能测试需求

①功能需求测试分析

对于功能测试中，可以借助功能框图来帮助我们进行测试的需求分析。概括起来，功能测试需求包括以下，通常包括以下几个方面。

（1）系统各个功能界面的验证
（2）借助业务把功能串起来进行测试
（3）功能的一致性，交互性（多功能互操作）的测试
（4）系统的不同输入，结果输出的业务数据测试。
（5）功能的错误操作，异常操作的测试（属于负面测试）
（6）功能实现用到的算法验证，有时需要用运代码评审
（7）用户操作的易用性，用户体验，往往结合功能测试同时验证

针对具体的需求，可以根据业务分类，用户角色（餐厅的会员系统）或者用户操作区域等将系统的功能分解成若干个功能模块，然后按照功能模块分别进行测试需求分析。按照功能模块划分，业务模块划分是最常见的做法。

②非功能需求测试分析

非功能测试需求主要涉及性能，安全性，可靠性，兼容性，易维护性和可移植性等。从测试需求分析来看，每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响，如安全性越高，就越有可能给易用性，性能带来更大的挑战。

这里要说明的是对于每一个应用软件系统，非功能特性的质量需求都是存在的，但是不同的项目类型对各个非功能特性的要求是不一样的，这个需要根据具体的项目、具体需求和不同产品应用的特点进行分析。

（1）纯客户端软件，比如字处理软件（Word，PPT)，媒体（音频/视频）播放软件（电脑自带的）等。这类软件对系统的功能测试要求是最低的，但是对兼容性和稳定性，可移植性有一定的要求。
（2）企业内部的客户端/服务端（C/S)应用系统。比如电子邮件，即时通信系统（飞Q，企业QQ）等，在系统功能测试需求上比纯客户端复杂，要求功能正确，稳定性能好。但是整体上看，对性能，安全性，兼容性要求不高。
（3）外部大型复杂网络应用系统，比如电子商务，网上银行，视频网站（腾讯，优酷）等，除了有复杂的系统的功能测试需求外，在系统的性能，安全性，兼容性，容错性，可靠性等都有很高的要求。

（2）具体的设计方法

①等价类

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能

无效等价类：根据需求说明书，不满足需求的集合。

等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。

②边界值

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

边界点：

上点：边界上的点

内点：边界内的点

离点：边界值附近的一个点（闭区间为区间外距离上点最近的点，开区间为区间内距离上点最近的点）

边界值设计测试用例方法：

1.充分理解需求

2.找边界点

3.针对边界点设计测试用例

③因果图（判定表）

判定表是另一种表达逻辑判断的工具。

关系：

与、或、非、恒等（条件为真，结果一定为真）

设计测试用例方法：

1.分析所有可能的输入和可能的输出

2.找出输入与输出之间的对应关系

3.设计判定表

4.把判定表对应到每一个测试用例

④正交排列（正交表）

最简单的正交表是L4(23)，含意如下：“L”代表正交表；L 下角的数字“4”表示有 4 横行，简称行，即要做四次试验；括号内的指数“3”表示有3 纵列，简称列，即最多允许安排的因素是3 个；括号内的数“2”表示表的主要部分只有2 种数字，即因素有两种水平1与2。正交表的特点是其安排的试验方法具有均衡搭配特性。

⑤错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。

这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。

错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应运于测试。

这个方法的缺点是难以系统化，并且过度依赖个人能力

⑥场景设计法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。

典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。

4.实际测试用例

（1）水杯设计测试用例

（2）微信发送朋友圈设计测试用例

（3）总结

测试用例设计的万能公式：

三.测试分类

1.按测试对象划分

（1）界面测试

软件只是一种工具，软件与人的信息交流是通过界面来进行的，界面是软件与用户交流的最直接的一层，界面的设计决定了用户对我们设计的软件的第一印象；界面如同人的面孔，具有吸引用户的直接优势，设计合理的界面能给用户带来轻松愉悦的感受。

界面测试（简称UI测试)，指按照界面的需求（一般是UI设计稿）和界面的设计规则，对我们软件界面所展示的全部内容进行测试和检查，一般包括如下内容：

        验证界面内容显示的完整性，一致性，准确性，友好性。比如界面内容对屏幕大小的自适应，换行，内容是否全部清晰展示；

        验证整个界面布局和排版是否合理，不同板块字体的设计，图片的展示是否符合需求；
        对界面不同控件的测试，比如，对话框，文本框，滚动条，选项按钮等是否可以正常使用，有效和无效的状态是否设计合理；

        界面的布局和色调符合当下时事的发展。

测试点：布局、兼容、字体、按钮大小、图片大小、色差等。

（2）可靠性测试

可靠性（Availability）即可用性，是指系统正常运行的能力或者程度，一般用正常向用户提供软件服务的时间占总时间的百分比表示。

可靠性 = 正常运行时间/（正常运行时间+非正常运行时间）*100%

系统非正常运行的时间可能是由于硬件，软件，网络故障或任何其他因素（如断电）造成的，这些因素能让系统停止工作，或者连接中断不能被访问，或者性能急剧降低导致不能使用软件现有的服务等。

可用性指标一般要求达到4个或5个“9”，即99.99%或者99.999%

如果可用性达到99.99%，对于一个全年不间断（7*24的方式）运行的系统，意味着全年（252600min)不能正常工作的时间只有52min，不到一个小时。

如果可用性达到99.999%，意味着全年不能正常工作的时间只有5min

不同的应用系统，可用性的要求是不一样的，非实时性的信息系统或一般网站要求都很低，99%和99.5%就可以了，但是军事系统，要求则很高。

（3）容错性测试

容错性测试是指系统能够处理异常，用户的错误操作而不至于系统崩溃，从而能够提高系统的可用性。

容错性测试包含以下方面：

①输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。

比如数据级测试，校验测试，环境容错性测试，界面容错性测试

②灾难恢复性测试。

通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。

（4）文档测试

国家有关计算机软件产品开发文件编制指南中共有14 种文件，可分为3大类。

开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。

用户文件:用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。

管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
在实际的测试中，最常见的是用户文件的测试，例如：手册说明书等。也会有一些公司对需求文档进行测试，来保证需求文档的质量。

文档测试的关注点：

文档的术语
文档的正确性
文档的完整性
文档的一致性
文档的易用性

（5）兼容性测试

兼容性测试需求是指明确要测试的兼容环境，考虑软，硬件的兼容，就软件兼容来说，主要考虑以下几个方面：

        系统自身版本的兼容，用户已有数据的兼容，数据兼容是重中之重，对用户来说，数据是最有价值的。

        测试与应用环境的兼容性，比如操作系统，应用平台，浏览器的兼容

        测试与第三方系统以及第三方数据的兼容性

对于环境（操作系统，应用平台）兼容性的测试不仅仅局限在操作系统，浏览器这两个因素，还包括以下，32位，64位CPU；手机平台Android ，iOS，Windows Phone；支持不同的Internet连接速度。对于iOS和Android两个平台，还要区分手机和平板电脑，考虑不同的型号（屏幕尺寸，分辨率等）。

（6）易用性测试

许多产品都应用人体工程学的研究成果，是产品在使用起来更加灵活和，舒适。软件产品也始终关注用户体验，让用户获得舒适，易用的体验，针对软件这方面的测试称之为易用性测试。

易用性在ISO25020标准中指容易发现，容易学习和容易使用。易用性包含七个要素：符合标准和规范，直观性，一致性，灵活性，舒适性，正确性和实用性。我们主要讨论以下几个方面:

1. 标准性和规范性

        对于现有的软件运行平台，通常其UI标准已经不知不觉地被确立了，成为大家的共识。多数用户已经习惯并且接受了这些标准和规范，或者说已经认同了这些信息所代表的的含义。比如安装软件的界面的外观，在什么场合使用恰当的对话框等。

        所以用户界面上的各中信息应该符合规范和习惯，否则用户使用起来会不舒适，并得不到用户的认可。

        测试人员需要把与标准规范，习惯不一致的问题报告为缺陷。

2. 直观性

        用户界面的直观性，要求软件功能特性易懂，清晰。用户界面布局合理，对操作的响应在用户的预期之中。比如数据统计结果用报表的形式（条形图，扇形图等）展示清晰直观；现在主流的很多搜索引擎和日历的设计也有直观性的特点。

3. 灵活性

        软件可以有不同的选项以满足不同使用习惯的用户来完成相同的功能。但是灵活性的设计要把握好度，不然可能由于太多的用户状态和方式的选择，增加了软件设计的复杂性，和程序实现的难度。

        例如手机键盘有九宫格和全键盘，还支持手写，满足了不同用户的需求。

4. 舒适性

        舒适性主要强调界面友好，美观，操作过程顺畅，色彩用运恰当，按钮的立体感等。例如左手鼠标的设置给习惯用左手的人带来了便利，也为右手十分劳累时提供了另一种途径。

（7）安装卸载测试

应用的安装和卸载在任何一款APP中都属于最基本功能。一旦出错，就属于优先级为紧要Critical的缺陷。主要需要考虑以下方面：

        软件不同的安装和卸载方式；
        应用是否可以在不同的环系统，版本下安装（安装兼容性）
        安装或者卸载过程中是否可以手动暂停，或者取消
        安装空不足的时候系统是否有提示
        是否可以正常的卸载，以及应用软件的各种卸载方式
        卸载和安装过程中出现环境问题，软件是否可以正常并且合理的应对，比如死机，断电，断网等

（8）安全测试

安全性是指信息安全，是指计算机系统或网络保护用户数据隐私，完整，保护数据正常传输和抵御黑客，病毒攻击的能力。安全性测试属于非功能性测试很重要的一个方面，系统常见的安全漏洞和威胁如下：

输入域，如输入恶性或者带有病毒的脚本或长字符串；
代码中的安全性问题，如SQL/XML注入
不安全的数据存储或者传递
数据文件，邮件文件，系统配置文件等里面有危害系统的信息或者数据；
有问题的访问控制，权限分配等
假冒ID：身份欺骗
篡改，对数据的恶意修改，破坏数据的完整性

安全性测试的方法有代码评审，渗透测试，安全运维等，常用的静态安全测试工具有，Coverity，IBMAppscan Source，HPFortify，常用的动态安全测试有OWASP的ZAP，HP WebInspect等。其中静态安全测试是常用的安全性测试的方法。

（9）性能测试

我们在使用软件的时候有时会碰到软件网页打开时越来越慢，查询数据时很长时间才显示列表，软件运行越来越慢等问题，这些问题都是系统的性能问题引起的。

要进行软件产品的性能问题，要对产品的性能需求进行分析，然后基于系统的性能需求和系统架构，完成性能测试的设计和执行，最后要进行持续的性能调优。常见的性能问题如下：

资源泄露
资源瓶颈
线程死锁，线程阻塞
查询速度慢或效率低
受外部系统影响越来越大

衡量一个系统性能好坏的关键性指标有，用户响时间，事务平均响应时间（TPS），吞吐率，每秒点击次数，内存和CPU使用率等。

（10）内存泄漏测试

很多软件系统都存在内存泄露的问题，尤其是缺乏自动垃圾回收机制的“非托管”语言编写的程序，例如C、CH、Delphi等。从用户使用的角度来看，内存泄露本身不会造成什么危害，一般用户可能根本不会感觉到内存泄露的存在。但是内存泄露是会累积的，只要执行的次数足够多，最终会耗尽所有可用内存，使软件的执行越来越慢，最后停止响应。可以把这种软件的问题比喻成软件的“慢性病”。

造成内存泄露的原因有很多，最常见的有以下几种：

分配完内存之后忘了回收。
程序写法有问题，造成没办法回收（如死循环造成无法执行到回收步骤）。
某些API函数的使用不正确，造成内存泄露

内存泄漏的检测方法：

人工静态法：代码走读，人工查找未被回收的内存。
自动工具法：借助相应测试内存泄漏的工具，如Visual Leak Detector，记录每次内存分配，清楚告诉用户内存是如何泄漏的。

2.按是否查看代码划分

（1）黑盒测试

黑盒测试就是在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使用、是否能适当的接收输入数据而输出正确的结果，满足规范需求。（测试人员不关注代码内部实现，通过一些科学的手段，想测试系统发起测试数据，关注测试执行结果是否和预期结果一致）

所以，黑盒测试又称之为数据驱动测试，只注重软件的功能

黑盒测试的优点：

        不需要了解程序内部的代码以及实现，不关注软件内部的实现。
        从用户角度出发设计测试用例，很容易的知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人员的产品思维
        测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能。

黑盒测试的缺点：不可能覆盖所有代码

黑盒测试用到的测试方法有，等价类，边界值，因果图，场景法，错误猜测法等。

（2）白盒测试

白盒测试又称为结构测试或逻辑测试，它一般用来分析程序的内部结构，针对程序的逻辑结构来设计测试用例进行测试。（关注代码内部实现）

白盒测试的测试目的是，通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。

主要包含六种测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

（3）灰盒测试

灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。（代码关注，业务上的预期结果和实际结果是否相匹配也关注）

3.按开发阶段划分

测试金字塔：

（1）单元测试

单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。又称为模块测试

测试阶段：编码后或者编码前（TDD）
测试对象：最小模块
测试人员：白盒测试工程师或开发工程师
测试依据：代码和注释+详细设计文档
测试方法：白盒测试
测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

（2）集成测试

集成测试也称联合测试（联调）、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。

测试阶段：一般单元测试之后进行
测试对象：模块间的接口
测试人员：白盒测试工程师或开发工程师
测试依据：单元测试的模块+概要设计文档
测试方法：黑盒测试与白盒测试相结合
测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响

（3）系统测试

将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。

测试阶段：集成测试通过之后
测试对象：整个系统（软、硬件）

测试人员：黑盒测试工程师
测试依据：需求规格说明文档
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

（4）回归测试

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。随着系统的庞大，回归测试的成本越来越大，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

（5）冒烟测试

冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件主要功能和核心流程正常，在正式进行系统测试之前执行。冒烟测试一般在开发人员开发完毕后提交给测试人员来进行测试时，先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。

如果冒烟测试通过，则测试人员开始进行正式的系统测试，如果不通过，则测试人员可以让开发人员重新修复代码直到冒烟测试通过，再开始进行系统测试。

回归测试和冒烟测试都属于系统测试。

（6）验收测试

验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。

测试阶段：系统测试通过之后
测试对象：整个系统（包括软硬件）。
测试人员：主要是最终用户或者需求方。
测试依据：用户需求、验收标准
测试方法：黑盒测试
测试内容：同系统测试(功能...各类文档等)

4.按测试实施组织划分

（1）α测试(Alpha Testing)

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。

大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试。α测试不能由程序员或测试员完成。

【所有员工进行测试，测试周期短】

（2）β测试(Beta Testing)

Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个场所进行。

α测试与Beta测试的区别：

测试的场所不同：Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。

Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。beta测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。

alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。

【每天有一部分进行测试，测试周期长】

（3）第三方测试

介于开发方和用户方间的组织的测试

5.按是否运行划分

（1）静态测试

所谓静态测试（static testing）就是不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。不以测试数据的执行而是对测试对象的分析过程，仅通过分析或检查源程序的设计、内部结构、逻辑、代码风格和规格等来检查程序的正确性。

（2）动态测试

动态测试（dynamic testing），指的是实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以判断一个测试属于动态测试还是静态的，唯一的标准就是看是否运行程序。

大多数软件测试工作都属于动态测试。

6.按是否手工划分

（1）手工测试

手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。总结优缺点：

优点：自动化无法替代探索性测试、发散思维结果的测试。

缺点：执行效率慢，量大易错。

（2）自动化测试

就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。简单说自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。

自动化测试比如功能测试自动化、性能测试自动化、安全测试自动化。

自动化测试按照测试对象来分，还可以分为接口测试、UI测试等。接口测试的ROI（产出投入比）要比UI测试高。

7.按测试地域划分

（1）国际化测试

软件的国际化和软件的本地化是开发面向全球不同地区用户使用的软件系统的两个过程。而本地化测试和国际化测试则是针对这类软件产品进行的测试。由于软件的全球化普及，还有软件外包行业的兴起，软件的本地化和国际化测试俨然成为了一个独特的测试专门领域。

（2）本地化测试

之前的都是本地化测试。

冰果滴

关注

21
点赞
踩
23

收藏

觉得还不错? 一键收藏
打赏
0
评论
【软件测试】

软件需求是 a.用户解决问题或达到目标所需条件或权能(Capability)。b. 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。一种反映上面 a 或 b 所述条件或权能的文档说明（它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制）测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
复制链接

扫一扫