1- 需求评审

软件测试工作从需求评审开始

由于软件系统的复杂性，在软件生命周期的需求分析阶段可能存在着开发人员对甲方或者用户业务需求理解不全面、不准确的情况。在这种情况下，如果不进行相关的质量控制，往往会造成开发结果与用户需求不一致的结果。需求评审的目的就在于明确项目情况和核心需求，保证软件设计最大可能地满足有关用户的所有需求，降低额外风险和未预料的成本。

1. 需求评审

需求评审就是以产品或者项目经理组织，项目组所有人员参与，包括项目经理、产品、开发、测试、市场、运维等参加的会议。

其目的就是明确项目情况和核心需求，将需求转化为需求文档，主要明确产品的功能、业务流程、性能、运行环境、用户群体、设计要求和限制、测试准则和质量保证要求等相关信息，产出了《需求规格说明书》，做到尽可能的详细明确，以避免测试遗漏和误解。

需求评审尽可能要有用户或用户代表参与

在项目开始阶段就应当确定不同级别、不同类型的评审必须要有哪些人员的参与，否则可能会遗漏部分人员的意见，增加需求变更风险

对于需求评审要从以下几点进行评价：

1. 完整性:目标软件的所有功能、性能、设计约束以及所有的可能  情况下的预期行为，均完整地体现在需求规格说明书中

2. 正确性：每项需求都必须准确地陈述其要开发的功能

3. 可行性：每项需求都必须是在已知系统和环境的权能和限制范围内可以实施的

4. 唯一性：每项需求只能有一个明确统一的解释

5. 可验证性：每项需求都存在技术经济上可行的手段进行验证和确认

6. 可修改性：需求说明书的格式和组织方式应该保证能够比较容易地 增、删和修改，并使修改后的需求说明书能够较好地保持其他各项属性

7. 可跟踪性：每项需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，使每项需求与用户的原始需求连起来，并为后续开发
   和其他文档引用这些需求项提供便利

2. 需求评审的意义在哪？

直接用一堆正确的话来告诉大家需求评审的意义，可能并不会有太深刻的体会。所以我们不妨另辟蹊径，一起来试想一下：如果开启一个新项目或者迭代没有任何需求评审、研发完全按照产品需求文档进行开发，会有什么样的结果？

看起来貌似节约了大量的沟通时间，也避免了团队内的争论和争吵，但实际开工之后呢？

一方面，在开发过程中，开发人员发现出现了部分需求遗漏、有些看似一句话的需求实现起来成本反而非常高、有些需求未考虑到数据修复、数据查询量过载风险，这时候，经验丰富一些的开发会主动找到产品进行讨论并要求进行需求变更，而另外一些开发新人可能就埋头照做了，到真正上线后才发现实际有一大堆问题，甚至可能造成不可挽回的损失。

另一方面，产品上线之后，销售和售后部门的同事发现需求是满足了，系统的易用性却很差，这时候，客户也接二连三的反馈系统怎么越改越难用了，根本没法解决他们的问题！

这样看来，省去了需求评审之后，产品经理的工作虽然“单纯”了很多，但却很难兼顾全局，也无形中将所有的风险和压力担在了自己一个人身上，浪费了团队的智慧和经验。

因此，一场好的需求评审能够帮助我们很好地管理用户需求，同时也能通过一次次评审和纠偏，帮助整个研发团队明确需求和优先级达成一致，及早进行风险评估及查缺补漏，有效提升团队开发效率和产品可用性。

那么，接下来我们就来看看一次完整的需求评审是怎样的？

3. 需求评审流程

不同公司不同业务不同客户的需求评审流程都有所不同，有些只有1次，有些要开3、4次。但是，无论开几次，其本质都是一样的。

3.1 会前准备

1.争取上层决策者的支持与谅解

2.筹备相关的资源，包括人力、时间计划，评审场地

3.在正式评审之前，将相关的需求以文档或其他形式发布给每个参与评审的人员手中，并确保其有足够的时间可以通阅需求并做好评审前
  的相关质疑与确认记录

4.在正式评审之前，会议组织者应先收集相关评审人员的各项需求评审建议和意见，对存在争议和疑惑的需求说明必须做好讨论的安排

5.发布经确认后的评审计划或时间表

3.2 会中评审

1.一般由产品或者项目经理组织，项目组所有人员参与

2.与会人就某具体的问题进行讨论，讨论的优先级如下所列
    
    2.1 最重要的业务内容，一般是按流程、功能、细节来排定
    2.2 争议或疑问较多的地方
    2.3 部分有争议的地方
    2.4 对于没有提出疑义的地方，可以快速流过

3.最后要注意一定要回顾已提出问题和有结论的地方

4.由会议记录人员整理会议的纲要，记录各与会人员的相关意见，并在会后递交纪要

3.3 会后总结

1.对评审得出结论的问题进行再次确认和修正补充

2.确定下次评审的时间

3.按照第一阶段的流程再次进行组织，并确认结果

4.对大多数组织，两次评审可以解决大部分的问题，对于悬而未决的问题，如影响范围有限，则可以延后讨论解决

3.4 最终确认

1.就以上内容做最后的确认，需求定稿，各方签字确认

2.今后的变更转入需求变更流程，其后产生的评审为小范围内评审

通过开展需求评审，测试人员应能及时发现需求定义中存在的问题，使项目组相关人员在认知上达成一致，采取有效的预防措施，降低变更的成本；更好地理解产品的功能性和非功能性需求，为制定测试计划和用例打下基础。

2-《软件需求规格说明书》

对于一个测试工程师，项目的起点即需求文档，学会看需求文档非常重要。那需求文档是怎么样的，要看哪些内容呢？

产品需求文档一般由产品经理设计出来，让团队人员对产品有清晰的认识，包括产品概述，业务流程，功能详情等。
作为一个测试人员，看需求文档，主要看的是业务流程和功能详情。需求文档有很多，今天我们先来了解测试人员最典型的《软件需求规格说明书》。

《软件需求规格说明书》简称为SRS（Software Requirement Specification）是在需求分析阶段需要完成的文档，是需求评审的最终结果，详细定义了产品的功能、业务流程、性能、运行环境、用户群体、设计要求和限制、测试准则和质量保证要求等相关信息。

1. 为什么编写《软件需求规格说明书》？

• 便于用户、产品和开发、测试进行理解和交流，是软件人员进行设计和编码的基础

• 支持目标软件系统的确认，是测试和验收、判断bug的重要依据

• 控制系统进化过程，如果用户追加需求，那么需求说明书将用于确定是否为新需求

2. 目录简介

• 首页：公司项目名称、文档编号、版本号、责任人、密级、编写日期

• 简介：描述了开发软件系统的目的、意义、背景、适用范围、用户特点、软件功能等

• 需求说明：说明了系统业务功能、性能、准入准出标准、故障处理的要求

• 运行环境：说明软件运行所需的硬件设备和系统工具等，如:列出运行该软件所需要的硬件设备，包括:处理器型号、内存、外存、网络要求等

• 限制：说明软件开发在成本、时间进度、设计等方面的约束

3. 衡量标准

• 完整性：目标软件的所有功能、性能、设计约束以及所有的可能 情况下的预期行为，均完整地体现在需求规格说明书中

• 正确性：每项需求都必须准确地陈述其要开发的功能

• 可行性：每项需求都必须是在已知系统和环境的权能和限制范围内可以实施的

• 唯一性：每项需求只能有一个明确统一的解释

• 可验证性：每项需求都存在技术经济上可行的手段进行验证和确认

• 可修改性：需求说明书的格式和组织方式应该保证能够比较容易地 增、删和修改，并使修改后的需求说明书能够较好地保持其他各项属性

• 可跟踪性：每项需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，使每项需求与用户的原始需求连起来，并为后续开发和其他文档引用这些需求项提供便利

我们在后续的测试工作中我们会经常用到《软件需求规格说明书》，比如测试计划、测试用例的编写；在测试提交的BUG因为某些原因，遭到开发质疑，这时候《软件需求规格说明书》就是我们的重要依据。所以《软件需求规格说明书》对于测试人员来说是必须要掌握的文档。

3-《软件测试计划》

《软件测试计划》是在需求评审阶段完成后由测试经理/测试组长编写，描述了要进行的测试活动的范围、方法、资源和进度以及风险预估。

《软件测试计划》是个偏管理性质的文档

1. 为什么编写《软件测试计划》？

• 使软件测试工作进行更顺利：计划使测试工作能够预先安排，为整个测试工作明确方向

• 能促进测试人员彼此的交流：测试人员能够了解整个项目测试情况，以及测试人员自己所负责的模块任务等

• 使软件测试工作更易于管理：上级能够根据测试计划做宏观调控，进行相应资源配置等；其他人员了解测试人员的工作内容，进行相关配合工作，使得资源与变更成为一个可控的风险

《软件测试计划》作为软件项目计划的子计划，在项目启动初期是必须规划的。在越来越多公司的软件开发中，软件质量日益受到重视，测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中，这样，如何规划整个项目周期的测试工作；如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。测试计划因此也成为测试工作的赖于展开的基础。

《ANSI/IEEE软件测试文档标准829-1983》将测试计划定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。
它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。”软件测试计划是指导测试过程的纲领性文件，包含了
产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参
与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应
对测试过程中的各种变更

详细的《软件测试计划》可以帮助测试工程师之外的人了解为什么和怎样验证产品。它非常有用但是测试项目组之外的人却很少去读它。

2. 目录简介

• 首页：公司项目名称、编号、版本号、责任人、密级、日期

• 简介：描述了该文档的编写目的、背景、参考资料等

• 测试范围：说明本计划所针对的测试类型，简要说明测试对象中接受测试和不接受测试的功能和性能

• 测试资源：说明本次测试所用到的硬件、软件、网速、人员要求等情况

• 测试策略：描述了本次测试的依据、准入准出的标准、测试工具、测试的重点及方法、缺陷严重程度的定义

• 测试过程管理：测试人员的组织架构、测试任务分配、时间进度安排、沟通方式等

• 测试风险：预估测试过程中存在的风险及解决办法

• 附件：输出的测试文档

3. 注意事项

切合实际

测试计划不一定要尽善尽美，但一定要切合实际，要根据项目特点、公司实际情况来编制，不能脱离实际情况

随机应变

测试计划一旦制定下来，并不就是一成不变的，世界万事万物时时刻刻都在变化，软件需求、软件开发、人员流动等都在时刻发生着变化，
测试计划也要根据实际情况的变化而不断进行调整，以满足实际测试要求

宏观调控

测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等

4- 测试用例

测试用例（Test Case）是指对一项特定的软件产品进行测试任务的描述，体现测试计划、方法、技术和策略。其包括编号、模块、标题、前置条件、优先级、输入数据、测试步骤、预期结果等要素，最终形成文档。简单地认为，测试用例就是一组由测试输入、执行条件以及预期结果组成的数据。

通俗一点讲：测试用例是我们测试人员在产品提测之前需要准备的核心工作文档，用它来验证产品的实际结果是否满足用户需求，这就是测试用例。

1. 用例要素

• ID/编号

顾名思义，也就是用例的序号，格式SRS-ydyx-DL-001

SRS：《软件需求规格说明书》简称为SRS（Software Requirement Specification）
ydyx：一般代表项目名称的简写
DL：所属模块的大写首字母
001：用例的序号

有唯一性：每个ID对应一条测试用例
易识别性：看了ID就能明白它所代表的意思，比如我看到这个ID后，就明白这条用例是 云端源想项目下登录模块的第一条测试用例

• 所属模块/测试项

我们对系统所划分的功能模块，或者测试项

• 标题

主要描述测试某项功能，每个标题都是对应一条用例，所以标题原则上不能重复

简单明了、通俗易懂
唯一性

• 前置条件

指用例标题需要满足该条件，执行这条测试用例需要的前提

比如测登录时，预先要有账号和密码、且网络正常

• 优先级

执行用例的先后顺序，一般我们把他分为高中低
   
高：冒烟测试用例，主要都是产品的主要功能、主流业务、都是正向的测试用例，比如验证输入正确的账号密码是否登录成功
中：就是一些非正向用例，或者边缘功能，比如验证输入正确的账号和错误的密码是否登录成功
低：比如一些错误信息的提示、UI页面上的错别字等

• 测试数据

执行用例所需要的数据

比如验证输入正确的账号密码是否登录成功这条用例，
它的测试数据就是 账号：aaaaaa 密码：123456

• 操作步骤

主要描述用例的操作步骤，建议有一个统一的格式  
在什么地方做了什么事

比如验证输入正确的账号密码是否登录成功这条用例，它的操作步骤：
第一步：在登录页面，输入账号aaaaaa
第二步：输入密码123456
第三步：点击“登录”按钮

• 预期结果

需求文档中明确说明的规范，用户想要得到的结果

比如测登录时，输入账号密码点击登录按钮后，他的预期结果就是登录成功，页面正确跳转

很多人都以为测试用例包含实际结果，其实是错误的想法；
测试用例不包含实际结果，测试用例产生于测试之前，只有测试时，才会有实际结果，所以实际结果是不可能与测试用例同步产生；
实际结果存在于BUG报告单，BUG报告单是根据测试用例测试完后生成的报告文档。

2. 测试用例意义

测试用例是将软件测试的行为活动做一个科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式；同时测试用例也是将测试具体量化的方法之一，不同类别的软件，测试用例是不同的。

2.1 测试的标准

测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要严格按照测试用例
和用例步骤逐一执行，并对测试情况记录在测试用例管理系统中，以便自动生成测试结果文档

在已经纳入测试计划且通过评审的测试用例，执行测试时测试人员不能随意更改

2.2 准备测试数据

在实际工作中，测试数据是与测试用例分离的

按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其像测试报表之类数据集的正确性，
按照测试用例规划准备测试数据是十分必须的；
除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据

2.3 评估测试结果的度量基准

执行完测试用例后，需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。
采用测试用例作度量基准更加准确、有效

比如测试用例覆盖率是多少、测试用例合格率是多少等等

2.4 测试用例不断完善

通过BUG分析，对比测试用例和BUG报告单，分析确认是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例

所以测试用例不是一成不变的，而是随着测试工作的进行和软件版本更新一直在补全完善或者变更的

3. 常用的测试用例设计方法

• 等价类划分法

• 边界值分析法

• 正交实验法

• 判定表法

• 流程图法

• 错误推算法

软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入在最短的时间内完成测试工作，发现软件系统的缺陷，保证软件质量，则是每位测试人员探索和追求的目标，每个软件产品或软件开发项目都需要有一套优秀的测试计划和测试方法。

影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等。
因为有些因素是客观存在，无法避免的；有些因素则是波动的、不稳定的。

例如开发队伍是流动的，有经验的开发人员走了，新人不断补充进来；每个开发人员的工作也会受情绪影响，等等。
有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量，从而控制人为因素。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。

因此，测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试必须遵守的准则，更是软件测试质量稳定的根本保障。

5- 等价类划分法

等价类划分法是把所有可能输入的数据划分为若干个区域，然后从每个区域中取少数有代表性的数据进行测试，主要用于输入框合法和非法字符的检查，是测试工作中最常用的一个设计方法。

常用于针对单个输入框，没法穷举的，或数据集过大的数据集

等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的
代表值就等于对这一类其它值的测试；因此可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输
入条件就可以用少量代表性的测试数据取得较好的测试结果。

等价类划分可有两种不同的情况：有效等价类和无效等价类

有效等价类：合法字符，符合需求文档中定义的数据
无效等价类：非法字符，不符合需求文档定义的数据

设计测试用例时，要同时考虑这两种等价类，因为软件不仅要能接收合理的数据，也要能经受意外的考验，这样的测试才能确保软件
具有更高的可靠性

实例

需求描述：提交年龄
         年龄范围输入: 18-99的整数
         当输入数据符合取值范围时提交成功
         当输入数据不符合取值范围时，提示“请输入正确的年龄”

使用等价类划分法分为：
有效等价：18-99的整数
    取值：40
无效等价：空、负数、小于18的整数、大于99的整数、小数、中文汉字、大小写英文字母、特殊字符、空格+合法整数
    取值：空、-40、10、100、50.5、年龄、nl、#￥、空格66

6- 边界值分析法

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

以往的经验告诉我们，程序在处理边界数据的时候容易出错，因此针对各种边界情况设计测试用例，可以查出更多的错误。

常用于针对单个输入框，输入范围有边界。意味着使用场景只能是数字或时间类型

边界值分析法取稍高于或稍低于或者等于边界的一些数据进行测试

使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。

应当选取刚刚小于、正好等于、刚刚大于或边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

1. 常见的边界值

• 对16-bit 的整数而言 32767 和 -32768 是边界
• 屏幕上光标在最左上、最右下位置
• 报表的第一行和最后一行
• 数组元素的第一个和最后一个
• 循环的第 0 次、第 1 次和倒数第 2 次、最后一次

2. 与等价划分的区别

• 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件
• 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况

3. 实例

需求描述：提交年龄
         年龄范围输入: 18-99的整数
         当输入数据符合取值范围时提交成功
         当输入数据不符合取值范围时，提示“请输入正确的年龄”

使用边界值分析法取值：
0、17、18、19、98、99、100

7- 正交实验法

针对软件页面存在多个输入框互相关联的一种设计方法，又称多因子多状态法。
在各因素互相独立的情况下，设计出一种特殊的表格，找出能以少数替代全面的测试用例。

正交表，是经过统计学的实验，分析得来的一个数学结果，它相当于是在大数据集合当中，按照数学的特性去均匀的选择挑选测试数据，以便大幅缩小测试范围

1. 应用场景

各条件相互独立，每一种有效用例里的组合数过多，而且这些组合都是有效数据。
之前我们在对产品进行测试用例设计的时候，都是针对单个输入框。如果多个输入框的情况下，那么这种情况就比较复杂一点。

2. 用法

• 确定因素（条件）和水平（条件取值，一般空和非空）

• 工具：正交设计助手
  

• 编写用例

3. 实例

有一个注册信息的输入框，有账号、密码、手机号三个输入框，都填写合法注册成功，否则注册失败

3.1 确定因素和水平

• 因素：3因素（账号、密码、手机号）
• 水平：2水平（填写、不填写）

不使用正交实验法
3因素2水平的全面实验次数 >= 2³ = 8次

使用正交分析法的时候，最好的方式是使用一个正交设计助手来使用。我们也可以靠手填写，针对一些输入框比较少的情况下，用手填写和设计哪个框填写，哪个框不填写。如果这个输入框达到几十或者二三十个的时候，手填的话就会变得眼花缭乱，很有可能会导致一些重复的设计用例出现

3.2 使用正交实验法

使用工具：正交设计助手

使用正交设计助手的话，就按照软件的逻辑，来生成需要测试的正交表的测试用例。

打开正交设计助手，首先要去新建工程 —> 新建实验，然后填写设计向导。
所谓的设计向导主要是选择正交表和填写因素与水平

填写设计向导：

• 正交表：L4_2_3
• 因素与水平：填写、不填写

Ln_r_m
L:正交表
n：实验次数
r：水平
m：因素

所以L4_2_3意思就是3因素2水平4次实验

设计向导填完后，点击确定，这时候就会得到4个实验，也即是四条用例

3.3 编写用例

• 账号填写、密码填写、手机号填写，预期结果为注册成功

• 账号填写、密码不填写、手机号不填写，预期结果为注册失败

• 账号不填写、密码填写、手机号不填写，预期结果为注册失败

• 账号不填写、密码不填写、手机号填写，预期结果为注册失败

有些同学说了我不使用正交表分析法也可以列出这些组合，你如果把所有的组合情况都列举出来了，那么是不是浪费了部分人力和时间，而且还会产生很多冗余的用例，我们要知道，在实际工作当中，项目往往给的时间都是不够的，时间很紧张的，所以我们使用正交表分析法就是一种有效减少用例设计个数的设计方法，最终目的就是选择一些典型的组合进行测试。

8- 判定表法

判定表法又称为策略表，基于策略表的测试，是功能测试中最严密的测试方法。该方法适合于逻辑判断复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，会得到一个判断清晰的判定表。

判定表法主要用于页面中各类按钮之间存在组合和制约的关系，即页面除了输入框之外，还存在各类按钮，而且按钮之间存在相互关联和制约的关系，且具有较强的逻辑性。

1. 用法

• 明确需求
• 画出判定表

1.列出条件桩、动作桩
2.对条件项进行全排列组合
3.根据条件组合确定动作项
4.去掉无效组合

• 编写测试用例

2. 实例一

需求描述：
首先输入原密码，如果原密码错误，提示“原密码错误”
然后输入两次新密码，如果新密码不一致，提示“两次新密码输入不一致”
新密码复杂度要求：8-16位，密码可以为：大小写字母+数字，如果复杂度达不到要求，提示“新密码复杂度不够”
如果条件都符合，提示“密码修改成功”

如果不输入原密码，提示请输入原密码
如果不输入新密码，提示请输入新密码

2.1 明确需求

• 条件桩3个：原密码、两次新密码、密码复杂度
• 动作桩6个：原密码错误、两次新密码输入不一致、新密码复杂度不够、密码修改成功

判定表法不考虑空和非空，所以条件桩和动作桩不需要考虑原密码和新密码不输入的场景

空和非空场景需要用到是正交实验法

2.2 画出判定表

2.3 编写用例

• 原密码输入正确，两次新密码输入一致，密码复杂度符合要求，预期结果为密码修改成功

• 原密码输入正确，两次新密码输入一致，密码复杂度不符合要求，预期结果为新密码复杂度不够

• 原密码输入正确，两次新密码输入不一致，密码复杂度符合要求，预期结果为两次新密码输入不一致

• 原密码输入正确，两次新密码输入不一致，密码复杂度不符合要求，预期结果为两次新密码输入不一致

• 原密码输入不正确，两次新密码输入一致，密码复杂度符合要求，预期结果为原密码错误

• 原密码输入不正确，两次新密码输入一致，密码复杂度不符合要求，预期结果为原密码错误

• 原密码输入不正确，两次新密码输入不一致，密码复杂度符合要求，预期结果为原密码错误

• 原密码输入不正确，两次新密码输入不一致，密码复杂度不符合要求，预期结果为原密码错误

3. 实例二

选择充值的金额和投币金额面值相同，充值成功，否则提示充值失败

3.1 明确需求

• 条件桩3个：选择充值的金额20元、选择充值的金额50元、选择充值的金额100元
• 动作桩2个：充值成功、充值失败

3.2 画出判定表

3.3 编写用例

我们在对条件项进行排列时会碰到一些无效组合，比如不选择充值金额这种组合是不存在的，我们需要在最后一步去除掉这类组合，去掉之后用例如下：

• 选择充值的金额20元，投币20元

• 选择充值的金额20元，投币非20元

• 选择充值的金额50元，投币50元

• 选择充值的金额50元，投币非50元

• 选择充值的金额100元，投币100元

• 选择充值的金额100元，投币非100元

实际工作当中因为业务复杂度比较高，我们会采用画图的方式展示条件与条件之间的制约关系，那么通过这个例子我们可以清楚的知道了要使用判定表法，必须先找准条件动作关系和排除不能组合的情况，这也是判定表法的关键，如果分析错了，就会设计出错误的设计用例。

9- 流程图法和错误推算法

流程图法也叫场景设计法，就是专门针对软件业务流程测试的方法。

什么是业务流程？

业务流程是指客户在使用软件的过程中，为了达成自身所想要的目的，按照指定的顺序去操作软件的功能，这样的操作过程叫业务流程。

业务流程是多个功能的组合。比如：把大象放进冰箱就是一个业务流程。

1. 用法

• 根据流程图找出路径

• 编写测试用例

从开始到结束为一条路径，有多少条路径就有多少条用例

2. 实例

2.1 找出流程图路径

我们从图中看出从登录到退出有7条路径，路径数 = 7

2.2 编写用例

• 登录-退出

• 登录-选择商品-退出

• 登录-选择商品-加入购物车-退出

• 登录-选择商品-加入购物车-提交订单-退出

• 登录-选择商品-加入购物车-提交订单-未支付-退出

• 登录-选择商品-提交订单-支付成功-退出

• 登录-选择商品-加入购物车-提交订单-支付成功-退出

流程图法测试不需要深入功能内部详细测试，主要测试流程；未来不管面向什么项目，都是为了实现用户价值去开发的，所以一定会有业务场景测试。也就意味着一定会使用到流程图法。

10- 错误推算法

错误推算法是根据测试人员经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的方法，它没有固定的形式，依靠的是经验和直觉，很多时候，我们都会不知不觉的使用到。

错误推断法是一种基于经验的测试设计方法。使用错误推断法来设计测试用例，测试用例的有效性会比较高，但也容易引发过度测试。

测试用例的有效性：测试用例发现缺陷的能力

过度测试：测试者可能会为了发现缺陷而测试得过于严苛，却忽视对一些基本功能和场景的测试验证，造成测试遗漏

一般来说，我们建议把错误推断法和基于模型的测试设计法放在一起使用，在保证测试用例对场景、功能、设计有一定覆盖度的基础上，进一步增加测试用例的有效性。

错误推断法中的“经验”，主要源于对产品缺陷的分析

实例

字符串长度检查

数据库设置字段的类型决定了字符储存长度，比如输入超长混合文本

标点符号检查

空格、各种引号、Enter键、全角半角英文字母

特殊字符

常见的￥%$\单引号：‘   ’、中文、：、0、负数、空格

输入特殊语句

&nbsp、"or"1"="1、\n

非法操作

断电、断网、弱网重连后是否能继续使用且信息未丢失

错误推算法是一个慢慢积累的过程。一般来说，常见的错误推测法都是有一些惯例的，也就是比较容易出错的地方；该方法强调的是对被测软件的需求理解以及设计实现的细节把握，当然还有个人的能力；显而易见地，这个方法的缺点就是太过依赖个人能力，难以系统化。因此，这个方法一般是作为测试用例设计的补充，而不是单独用来设计测试用例。

11- 用例评审

测试用例编写完成后，需要对用例进行评审。

用例评审是由测试人员组织并邀约项目相关人员参与的评审会议，对测试用例的可行性、全面性进行审查评估，同时消除各方对需求文档理解的偏差达到对需求理解的一致，和需求评审类似。

测试人员在用例编写完成之后，不代表用例写的都是正确的或者场景覆盖是全的，因此需要多方人员进行查漏补缺，所以用例评审是产品、开发、测试一起对写好的用例进行一个复验补全的过程。

用例评审在开发提测前完成

1. 参与人员

用例评审分为组内评审和组外评审，为了对测试用例的可行性、全面性进行审查评估，测试用例的评审严格来讲是需要项目组的全体人员都参与的，但在实际工作中，通常一些公司为了节省时间资源，一般都是只有本项目组的测试人员参与评审，甚至绕过评审这步，如果用例都没有评审，直接去执行，可能会存在一些问题。

组内评审：项目组全部测试人员

组外评审：项目组主要是产品、开发、测试

2. 评审作用

• 提高测试覆盖率，扩充测试用例的全面性，提升测试用例质量

• 确保需求的可追溯性，复审需求

• 开发可带入新的测试角度与细节测试方向，是否有自己未考虑到的场景，自己未注意到的需求，或者发现自己对需求理解歧义的地方

• 集思广益，在讨论中预防缺陷，改善产品质量

3. 评审流程

评审用例必须符合软件开发的基本流程，即用例的需求、目的和作用。用户需求和功能需求必须是不变的、稳定的状态

3.1 会前准备

1. 测试人员先把待评审的用例过一遍，看看有没有什么问题

2. 提前准备好用例评审的资料，比如需求文档、UI设计图或者原型图

3. 用例较多时，最好按模块对用例进行评审，这样方便也清楚

4. 在用例评审前，将待评审用例发给相关人员，提前查阅

5. 定好会议室发出会议邀约，一次评审会议的用例不易过多，时间控制在1小时左右

3.2 会中评审

评审过程中，测试人员要做好会议纪要，如果用例有需要补充或修改的地方快速标注清楚，便于会后进行整理补充

3.3 会后优化

1. 用例评审完成后，测试人员根据会中修改和补充的地方重新整理测试用例

2. 优化完成后，将冒烟测试用例发送给开发，供开发人员提测之前进行自测

3. 同时，将测试用例通过用例管理工具分享给项目的相关人员，方便项目其他成员查阅

4. 在后续测试中，如若有需求修改的地方，需及时更新测试用例，做好测试用例的后续管理工作

用例评审是测试流程中必备的环节，用例设计更是整个产品质量的灵魂，想要更好的保障软件产品质量，需要多站在用户场景思考问题，对用户操作、业务逻辑过程进行深度思考，才能从根本上挖掘质量问题，让产品满足需求，为客户的产品质量保驾护航。

12- 执行测试用例

测试人员对已完成评审的用例，严格按照自己的测试用例执行，发现bug后提交至缺陷管理工具并跟踪。

提起测试用例的执行，可以说是一个简单到不能简单的任务，很多刚入行的测试人员，因测试经验有限或对业务不熟悉，往往在刚开始的时候都是做测试用例的执行工作；当然也正是觉得这个工作简单，所以很多人也不觉得在这里面会有什么问题，但是实际情况是果真如此？

在测试用例执行阶段，一般分为两个阶段：冒烟测试阶段和系统测试阶段

1. 冒烟测试

冒烟测试是在软件开发过程中的一种针对一个新编译需要正式测试的软件版本的主要业务功能进行确认验证的手段，主要目的是快速验证软件主要业务功能是否有缺陷，如果冒烟测试没通过，则不必做进一步的测试，即先执行所有正向用例。

我们在正式执行测试用例之前，首先要对系统进行冒烟测试，冒烟测试如果不通过，也就没必要进入系统测试阶段。

2. 系统测试

我们以禅道进行演示

2.1 执行用例

• 点击用例的“执行”按钮

2.2 进入执行界面，选择测试结果

• 填写测试结果，包括“忽略”、“通过”、“失败”、和“阻塞”四种结果。默认结果为“通过”

忽略：表明这条用例本轮不适合执行，暂时跳过

通过：表明这条用例执行结果通过

失败：表明这条用例执行结果失败，不通过

阻塞：表明这条用例受到阻塞，无法执行。例如：需求变更，数据无法造

若全部为“通过”，点击“保存”，禅道自动打开下一个用例。

2.3 添加附件

• 若结果为其他，可以在“实际情况”中填上相关信息，点击“附件”按钮上传图片说明

2.4 用例转BUG

• 附件添加完成后点击保存

• 点击“转Bug”，则跳转至“测试”-“Bug”下的"提Bug"页面

• 也可以在用例例表中，点击“转Bug”按钮

• 在用例例表中，点击“结果”查看用例的执行情况

执行系统测试时，根据测试计划中定义的测试任务执行测试用例，执行过程中对于发现的软件缺陷，要及时填写缺陷报告单，并跟踪问题的解决，做好问题跟踪和解决记录。

如果缺陷较多或较为产重，使得部分系统测试工作无法继续执行，则测试项目组根据问题的严重程度，有权暂停该部分的测试，或将软件版本返回开发项目组，重新组织转系统测试评审活动。

执行测试用例时，可根据实际的测试情况及时补充测试用例，从而增加测试的有效性，提高测试效率。

13- 缺陷

计算机系统或者程序中存在的任何一种破坏正常运转能力的问题都可以叫做缺陷或bug。

在软件测试中，软件产品运行的实际结果与期望结果不一致，不能够满足用户的需求或者不符合《需求规格说明书》的描述，软件在功能、性能、兼容、易用性都不能满足用户需求，我们称之为BUG。

1. 术语

BUG

电脑系统或者程序中存在的任何一种破坏正常运转能力的问题或者缺陷，都可以叫做BUG

有时也被泛指因软件产品内部的缺陷引起的软件产品最终运行时和预期属性的偏离

Debug

调试bug的过程

Defect

指静态存在于软件工作产品（文档、代码）中的错误，也指软件运行时由于这些错误被激发引起的和软件产品预期属性的偏离现象

2. 名词

• 失误（Mistake）：导致软件包含故障的人的行为

• 缺陷（Defect）：软件的异常情况

• 故障（Fault）：引起一个功能组件下不能完成所要要求的功能的一种意外情况

• 失效（Failure）：功能组件执行其规定功能的能力丧失

3. 缺陷类型

错误

软件实现了需求文档指明不应出现的错误

需求是正确，但在实现阶段未将需求正确实现，可能在概要、详细设计时产生了错误，也可能是编码错误。

即有此需求，但需求实现与用户期望不一致。例如排序功能，用户期望的是按价格升序排列，实现时却是降序排列。

额外

软件实现了需求文档未提到的功能，即用户未提及或冗余的需求，在产品中得到了实现。

一般而言，额外功能从用户体验角度来看，如果不影响正常的功能使用，则可以保留，除非存在较大应用风险。

遗漏

软件未实现需求文档要求的功能

规定或预期的需求未体现在产品中，可能在需求调研阶段未能将用户需求全部分析实现，也可能在后续产品实现阶段，未能全面实现。

通俗而言，一是根本没记录需求，需求本身就遗漏了用户的原始需求，二是需求是齐备完整的，但在设计开发阶段，遗漏了某些需求。

优化

软件未实现需求文档虽未明确提及，但应该实现的功能

用户难以理解、不易使用、运行缓慢，从用户的角度认为软件质量不好。

比如，针对中老年人的系统在设计开发过程中，采用了时尚前卫的界面、细小隽秀的字体，导致终端用户不适应、看不清，
这样即使所有需求都得到了正确的实现，但不符合用户使用习惯，也是一种缺陷

在测试过程中，测试工程师需要时刻记住，功能再完美、界面再漂亮的系统，如果不是用户期望的，则该系统完全无效，所以测试过程中需处处以用户为基准，从需求角度出发。

4. 产生原因

在软件开发的过程中，软件缺陷的产生是不可避免的，那么造成软件缺陷的主要原因有哪些？从软件本身、团队工作和技术问题等角度分析，就可以了解造成软件缺陷的主要因素。

需求不明确

软件需求不清晰或者开发人员对需求理解不明确，导致软件在设计时偏离客户的需求目标，造成软件功能或特征上的缺陷。

此外，在开发过程中，需求频繁变更也会影响软件最终的质量

软件复杂度高

如果软件系统结构比较复杂，很难设计出一个具有很好层次结构或组件结构的框架，这就会导致软件在开发、扩充、系统维护上的困难。

即使能够设计出一个很好的架构，复杂的系统在实现时也会隐藏着相互作用的难题，而导致隐藏的软件缺陷

开发人员技术水平

在软件开发过程中，程序员水平参差不齐，再加上开发过程中缺乏有效的沟通和监督，问题累积越来越多

如果不能逐一解决这些问题，会导致最终软件中存在很多缺陷

项目周期短

现在大部分软件产品开发周期都很短，开发团队要在有限的时间内完成软件产品的开发，压力非常大，

因此开发人员往往是在疲劳、压力大、受到干扰的状态下开发软件，这样的状态下，就会造成一些缺陷的出现或者主动忽视不严重的bug

开发流程不规范

开发流程不够完善或者不规范，存在太多的随机性和缺乏严谨的内审或评审机制，容易产生问题。

编码没有固定的流程和标准，文档不完善，风险估计不足等

为了最大限度地减少软件缺陷，解决导致软件错误的各种因素至关重要。通过改善沟通、管理软件复杂性、增强设计体验、解决编码错误、处理不断变化的需求、管理时间压力和促进充足的文档，在软件开发过程的每个阶段采取积极主动的措施将带来更高质量的软件并提高整体性能。

14- 缺陷报告单

当测试人员发现一条bug，需要填写一份缺陷报告单来记录这条bug，并通过这个缺陷报告单告知开发人员所发生的问题，即测试工作核心之一提bug

缺陷报告单是测试人员和开发人员交流沟通的重要工具

1. 缺陷报告单属性

缺陷报告单可以把软件存在的缺陷准确的描述出来，当测试人员发现一个缺陷，需要填写一份“缺陷报告”来记录这个缺陷，并通过这个缺陷报告告知开发人员所发生的问题，每个缺陷管理工具的缺陷报告单属性都不尽相同，我们以禅道为例

• 所属模块

我们对系统所划分的功能模块，或者测试项，和测试用例是一样的

• 所属项目

当前被测项目

• 发现版本/发布

发现BUG所属版本/发布，通常都说本次提测的版本/发布

• 指派人/负责人

指派给负责修复的开发人员

• 截止日期

指定修复bug的限期

• BUG类型

描述bug属于哪种类别的问题

通常有代码错误、配置相关、安装部署、安全相关、性能问题、设计缺陷、易用性问题、兼容性问题等

• BUG标题

对BUG的描述

格式：在什么地方做了什么事出现了什么结果
比如在登录页面，输入正确合法的账号和密码，点击登录按钮，页面提示登录失败

要求：简单明了、通俗易懂

• 严重程度

致命：系统产品的崩溃、死机、闪退，或造成数据丢失、主要功能完全丧失

严重：系统产品的功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失

一般：系统产品的次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等

提示：系统产品有个别错别字、文字排版不整齐等，对功能几乎没有影响，系统仍可使用

• 优先级

修复BUG的先后顺序，通常和严重程度一致
   
最高：系统产品的崩溃、死机、闪退，或造成数据丢失、主要功能完全丧失

较高：系统产品的功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失

普通：系统产品的次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等

最低：系统产品有个别错别字、文字排版不整齐等，对功能几乎没有影响，系统仍可使用

• 重现步骤

测试环境及操作步骤、预期结果、实际结果的详细描述，一般和测试用例中的操作步骤相同

• 附件

通常是log日志、截屏、录屏等依据，特别是偶现型BUG，附件尤为重要

2. 提bug准则（5C准则）

• 准确：内容描述准确，不会产生误解

• 清晰：每个组成部分描述清晰，易于理解

• 简洁：只包含必不可少的信息，不包括任何多余的内容

• 完整：复现该bug的操作步骤，和本质信息

• 一致：按照统一的格式书写缺陷报告

3. 作用

• 缺陷报告单是软件测试人员的工作成果之一，体现软件测试的价值

• 缺陷报告单是测试人员和开发人员交流沟通的重要工具

• 缺陷报告单是提供给开发人员或者其他负责人员作为定位缺陷的依据，便于开发人员修改产品缺陷

• 缺陷报告单可以反映项目产品当前的质量状态，便于项目整体进度和质量控制

• 缺陷报告单是软件测试的输出成果之一，可以衡量测试人员的工作能力

• 对bug进行分类，提高时间利用率

• 根据bug状态对bug进行管理跟踪

• 对bug进行分析统计，有利于后期项目的借鉴

15- 缺陷生命周期

缺陷生命周期指的是缺陷从被发现到被解决验证通过的完整过程。

缺陷生命周期通常依赖于软件测试过程，其状态流程一般使用专门的缺陷管理工具进行管理维护；一个缺陷的正常生命周期是 提交–处理中–已修复–关闭，中间还会有拒绝、重新打开、挂起等状态。

1. BUG状态

提交

1. 按照测试用例进行操作，发现和测试用例的预期结果不一致的,都可以被称之为Bug。

2. 测试用例不可能穷尽，总有超出你预料之外的因素,或者是神操作出现的bug。

3. 在提交一个bug，首先尽量描述这个缺陷的属性、Bug重现环境，bug类型，bug等级，bug的优先级及详细的重现步骤，结果与期望等

4. 我们在提交一个bug之前首先应该保证，这个bug是没有被提过的，以免造成重复提交

处理中

开发人员领取bug后，会根据bug单的描述进行复现，定位问题后进行修改，此时开发人员就会修改bug状态为处理中；

测试或者相关负责人就可以通过bug状态了解项目进度

已修复

对于处理完成的bug，开发人员需修改状态为已修复，等待测试人员进行回归测试

拒绝

如果开发不认为这是个bug，就拒绝修改，把bug的状态改为拒绝，并附上拒绝理由

重新打开

测试人员对于已修复的bug进行回归测试，确认这条bug是否修复，如果修复了，就改为关闭，否则改为重新打开

挂起

在处理问题之前，还需要进行一次判断，比如以下场景：

  1. 有些难以复现或无法复现的偶现型bug
  
  2. 修改这条bug的成本较大，比如需要对系统架构进行改动
  
  3. 出于时间成本考虑，对优先级非常低的bug可以放到下个版本修复

上述场景就可以考虑是否需要挂起此类bug

关闭

测试人员对于已修复的bug进行回归测试，确认这条bug是否修复，如果修复了，就改为关闭，这也是一个缺陷的最后一个状态

2. 缺陷管理工具

2.1 禅道

禅道是第一款国产开源项目管理软件。它的核心管理思想基于敏捷方法scrum，内置了产品管理和项目管理，同时又根据国内研发现状补充了测试管理、计划管理、发布管理、文档管理、事务管理等功能。在一个软件中就可以将软件研发中的需求、任务、bug、用例、计划、发布等要素有序的跟踪管理起来，完整地覆盖了项目管理的核心流程。

2.2 Pingcode

PingCode是由国内老牌SaaS1厂商Worktile 打造的智能化研发管理工具，是基于高效协作与敏捷研发理念，为不同规模研发团队提供Scrum、Kanban、知识库、迭代计划&跟踪、产品需求规划、缺陷跟踪、测试管理等，同时满足非研发团队的流程规划、项目管理和在线办公需要。

2.3 Tracup

Tracup 是一款轻量级的团队协同平台，提供简洁、高效的 Bug 追踪，轻量、便捷的项目管理，安全、稳定的数据保障，完美地将 Bug管理与团队协作结合在一起。

无论是修改Bug，还是新增一个功能， Tracup 都可以提供一个理想的工作云平台。便捷团队协作，轻量的项目管理， 完备的问题系统，大容量的文件存储，让用户工作更方便。

16-《软件测试报告》

《软件测试报告》是一份记录软件测试过程、结果和评估的文件，是测试工作的最后阶段，产品达到准出标准后，由测试经理/组长把测试的过程和结果写成文档，是测试阶段最后的文档产出物。

1. 目录简介

• 简介：描述了编写的目的、项目背景、参考资料

• 测试概要：确定本次测试所用到的资源,包括测试方法、范围、设备、工具、人员

• 测试结果：测试执行过程及结果情况分析，包括测试用例覆盖率、执行情况、缺陷分析

• 结论汇总及建议：描述了本次测试的用例和缺陷具体数据

• 附件：其他的一些测试文档

2. 作用

2.1 评估软件质量

软件测试报告通过记录测试执行细节和缺陷情况，为相关用户提供了评估软件质量的依据。通过软件测试报告，项目管理者和开发人员可以了解软件的稳定性和可靠性，及时发现和解决问题，提高软件质量。

2.2 决策支持

软件测试报告为项目管理者和决策者提供了测试进度和测试结果的全面信息。在软件开发过程中，可能需要根据测试报告来确定发布版本、计划下一阶段的开发和测试工作，以及优化项目资源分配。

2.3 沟通与交流

软件测试报告是测试团队与项目其他成员和利益相关者之间的重要沟通工具。通过软件测试报告，测试团队可以向其他人员传达测试进展、测试质量和发现的问题，提高沟通效率和透明度。

2.4 改进测试过程

软件测试报告不仅提供了测试执行的结果，还可以反映测试执行过程中的问题和不足。通过分析测试报告，测试团队可以不断改进测试策略和方法，提高测试效率和准确性。

软件测试报告在软件开发和测试过程中具有重要作用，它是测试团队和其他项目成员之间交流和合作的桥梁。通过详细记录测试结果和缺陷情况，软件测试报告有助于评估软件质量、支持决策、优化测试过程，从而提高软件的可靠性和稳定性；测试报告对发现的问题和bug进行分析，为纠正软件存在的质量问题提供依据，同时为软件验收和交付打下基础。

17- WEB UI测试

UI测试也叫界面测试，是测试用户界面布局是否合理、网站整体风格是否统一、各个控件的放置位置是否符合规范。

此外还要测试界面易用性、页面元素美观性性，包括图片、动画、边框、颜色、字体、背景、按钮等标签。

一般用户趋向于目的驱动，在访问页面的时候，很快地扫描一个页面，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉系统的结构，因此页面要尽可能的准确明了，确保用户能快速了解页面是否还有内容以及内容的位置

WEB页面测试的测试点如下：

1. UI页面

1. 网站风格是否统一

2. 网站风格是否符合区域风俗习惯

3. 页面样式、颜色背景是否协调

4. 页面布局是否合理

5. 各个页面的大小是否一致，比如同样的LOGO图片在各个页面中显示是否大小一致

6. 栏目名称、文章内容等处的文字是否正确，有无错别字或乱码

7. 同一级别的字体、大小、颜色是否统一

8. 窗口标题或图标是否与菜单栏的统一

2. 标题

1. 描述是否有歧义、注意是否有错别字

2. 各个页面的title是否正确

3. 每个页面都有相应的标题，不能为空，或者显示“无标题页面”

3. 提示信息

1. 提示信息是否符合规范（不应该显示英文的cancel、ok，应该显示中文）

2. 提示、警告或错误说明应清楚易懂，用词准确，摒弃模棱两可的字眼

3. 执行风险操作是否有提示（删除、修改敏感数据）

4. 系统应该在用户执行错误的操作之前提出提示信息（必填项“*”）

4. 控件

1. 界面中各个控件是否对齐、

2. 控件的提示语描述是否正确

3. 页面是否有多余按钮或标签

4. 日期控件是否可编辑

5. 日期控件的长度是否合理

6. 日期的正确格式应该是XXXX-XX-XX或XXXX-XX-XX XX:XX:XX

7. 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置

8. 避免空旷的界面上放置很大的按钮

9. 按钮的样式风格要统一

10. 按钮之间的间距要一致

11. 查询结果列表列宽是否合理、标签描述是否合理

12. 查询结果列表太宽没有横向滚动提示

13. 对于信息比较长的文本，文本框有没有提供自动竖直滚动条

14. 数据录入控件是否方便

15. 用滚动条移动页面时，页面的控件是否显示正常

16. 同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示

5. 易用性

1. 操作是否符合用户使用习惯

2. 操作顺序是否合理（有没有把相似的功能的控件放在一起，方便操作）

3. 对于信息比较长的文本，文本框有没有提供自动竖直滚动条，用滚动条移动页面时，页面的控件是否显示正常

4. 快捷键：有没有支持Tab键，回车键、Esc键、Delete键等

5. 页面自适应：窗口的最大化、最小化是否能正确切换

6. 若有滚动信息或图片，将鼠标放置其上，查看滚动信息或图片是否停止

7. 切换窗口大小，将窗口缩小后，页面是否按比例缩小或出现滚动条，各个页面缩小的风格是否一致，文字是否窜行

8. 导航面包屑处是否按相应的栏目级别显示；导航文字是否在同一行显示

9. 文章列表页：左侧的栏目是否与一级、二级栏目的名称、顺序一致

10. 调整分辨率验证页面格式是否错位现象

11. 鼠标移动到Flash焦点上特效是否实现，移出焦点特效是否消失

12. 每个非首页静态页面含图片字节不超过300K，全尺寸banner第一个场景控制在200k以内二个场景在300K，三个场景在400K以此类推

13. 超过一屏的内容，在底部应有快速返回顶部的top按钮

14. 超过三屏的内容，应在头部设提纲，直接链接到文内锚点

15. 首页，各栏目一级页面之间互链，各栏目一级和本栏目二级页面之间互链

16. 报表显示时应考虑数据显示宽度的自适应或自动换行

17. 所有有数据展现的界面（如统计、查询、编辑录入、打印预览、打印等），必须使测试数据的记录数超过一屏/一页

18. 如有多个系统展现同一数据源时，应保证其一致性

19. 对于报表中的所有字段值都应该有明确的定义，对于无意义的字段值，不应该显示空，应显示“/”，表示该字段值无意义

20. 对统计的数据应按用户习惯进行分类、排序

21. 界面内容更新后系统应提供刷新功能

22. 用户在退出系统后重新登陆时应考虑是否需要自动返回到上次退出系统时的界面

23. 在某些数据输入界面，如果要求输入的数据符合某项规则，应在输入界面提供相应的规则描述

24. 在某些对数据进行处理的操作界面，应考虑用户可能对数据进行处理的频繁程度和工作量，考虑是否可以进行批量操作

25. 确保数据精度显示的统一：如单价0元，应显示为0.00元

26. 确保图片按钮链接有效，并且链接的属性正确（比如是新建窗口打开、当前页面打开）

27. 易理解：对于正常的功能，用户可以不必阅读用户手册就能使用

28.合理性检查：做delete, update, add, cancel, back等操作后，查看页面是否正确跳转

18- WEB 表单测试

什么是表单？

HTML表单用于搜集不同类型的用户输入，通长把文本输入框、下拉框、标签、按钮控件放在一个表单中，用于接收用户的输入；网站页面通过提交表单把用户的输入信息提交到服务器。

测试人员就要对表单中的各种输入框、按钮控件进行测试，表单测试的主要测试功能点如下：

1. 输入框

1.1 字符型输入框

1. 汉字、大小写字母、数字、空或非空、特殊字符等组合

2. 长度检查：最小长度、最大长度、最小长度-1、最大长度+1、超长字符（把整个文章copy过去）

3. 空格检查：输入的字符间有空格、字符+空格、空格+字符、空格+字符+空格 

4. 禁止直接输入特殊字符时，尝试“粘贴、拷贝”方式输入

5. 输入特殊字符串、SQL（null、&nbsp、'or'1'='1、javascript、\n)

6. 输入超长字段，页面是否被撑开

7. 在文本框中输入回车键，显示时是否回车换行

8. 非法的输入或操作应有足够的提示说明

1.2 数值型输入框

1. 边界值：最大值、最小值、最大值+1、最小值-1

2. 位数：最小位数、最大位数、最小位数-1、最大位数+1、输入超长值、输入整数

3. 输入负整数、负小数、分数、输入字母或汉字

4. 小数（小数点前去掉0的情况，多个小数点的情况）

5. 首位为0的数字（01、02）

6. 是否支持科学计数法（10000=1.0E4）

7. 全角数字与半角数字、数字与字母混合

8. 货币型输入（允许小数点后面几位）

9. 特殊字符：NULL、空格可能导致系统错误的字符

10. 禁止直接输入特殊字符时，尝试“粘贴、拷贝”方式输入

11. 对于手机、邮箱、证件号等的输入是否有长度及类型的控制

12. 是否有必填项的控制；不输入必填项，是否有友好提示信息

13. 输入超长字段，页面是否被撑开

14. 在文本框中输入回车键，显示时是否回车换行

15. 非法的输入或操作应有足够的提示说明

1.3 日期型输入框

1. 日期的正确格式应该是XXXX-XX-XX或XXXX-XX-XX XX:XX:XX

2. 年输入非闰年，月输入[2]，日期输入[28、29]

3. 年输入闰年，月输入[2]、日期输入[29、30]

4. 月输入[1、3、5、7、8、10、12]、日输入[31]

5. 月输入[4、6、9、11]、日输入[30、31]

6. 月输入[0、1、12、13]

7. 日输入[0、1、31、32]

8. 时输入[0-24]、分输入[0-60]、秒[0-60]

9. 如果有开始、结束日期，输入开始日期大于结束日期

10. 如果是自动获取日期时间，修改计算机时间，查看系统处理情况

11. 开始时间<=结束时间，测试分、一个小时、跨时、当天、跨天、跨月、跨年的数据

12. 开始时间>/<当前时间，若是针对出生年月搜索，验证大于的情况；若是定时任务时间搜索验证小于的情况

13. 只输入开始时间/结束时间

14. 开始时间、结束时间都不输入

15. 结束时间早于开始时间

2. 下拉框

1. 默认值

2. 数据完整性

3. 数据正确性

4. 第一个/最后一个/中间一个选取、手动输入值模糊匹配、联动选择

5. 业务常见选取的操作

3. 提交按钮

1. 是否支持回车键

2. 单击、快速多次点击是否重复提交表单

3. 网络中断（弱网）提交

4. 提交之后是否有提示

5. 提交后内容是否加密

6. 提交是否做权限校验控制、多人针对表单同时操作的场景测试

4. 提示信息

1. 不符合需求的地方是否有错误提示

2. 无数据时，页面是否有默认提示信息

3. 提示信息是否符合规范（不应该显示英文的cancel、ok，应该显示中文）

4. 提示、警告或错误说明应清楚易懂，用词准确，摒弃模棱两可的字眼

5. 执行风险操作是否有提示（删除、修改敏感数据）

6. 系统应该在用户执行错误的操作之前提出提示信息（必填项“*”）

7. 需求唯一的字段：是否可以重复添加，添加时查看有没有相应的提示信息，比如商品编码、身份证号、银行卡号、手机号等

5. 数据校验

1. 对编辑页的每个字段进行修改，是否可以保存成功，相应字段是否更新

2. 进行必填项检查：为空时是否给出提示，以及提示后是否依然把数据存到数据库中

3. 添加和修改规则是否一致：在编辑的时候，注意编辑项的长度限制，有时在添加的时候有，在编辑的时候却没有

4. 修改数据后，查看相关联的数据是否更新，比如修改分类名称，在其他页面中查看相关分类名称是否更新

6. 文件上传

1. 上传图片：不同格式（jpg、pdf、png、gif、svg）、不同大小、不同数量

2. 上传视频：不同格式（MP4、avi、wvm、rmvb、fiash）、不同大小、不同数量

3. 上传文件：不同格式（TXT、DOC、PPT、XLSX、Markdown）、不同大小、不同数量

7. 搜索

1. 有无默认提示信息、有无错别字

2. 搜索条件为空时

3. 模糊搜索

4. 超长搜索

5. 不存在的与之匹配的搜索条件

6. 查询成功后，查询条件是否自动清除

7. 查看查询结果数据的正确性

8. 不同查询条件之间来回选择，是否出现异常

9. 测试多个查询条件时，要注意查询条件的组合测试（因果判定法）

8. 删除

1. 没选择数据，点击删除，是否有友好提示

2. 选择一条数据，点击删除，是否提示删除确认信息，需二次确认

3. 删除一条数据后，是否可以添加相同的数据

4. 是否支持批量删除，如果系统支持批量删除，注意删除的信息是否正确

5. 如有全选，注意是否把所有的数据删除，有分页时，选择全选，点击删除，是否删除所有数据

6. 是否允许删除一个有关联性的数据，比如删除一个绑定商品的分类

7. 连点击删除按钮，是否有友好提示

8. 所有删除数据操作，要注意相应查询页面及其关联界面的数据是否及时更新

9. 如果结果列表中没有记录或没有选择任何一条记录，系统是否友好提示

9. 返回、刷新

1. 查看返回按钮功能是否正确实现

2. 检查多次使用返回按钮的情况，在有返回按钮的地方，返回到原来的页面多次，查看是否会报异常

3. 查看刷新功能是否正确实现

4. 查看刷新时，是否清空搜索条件

10. 快捷键

1. 比如Tab键、Enter键、Ctrl+C、Ctrl+V、backspace、Delete、ESC等

2. 对不允许做输入的字段，对快捷方式是否也做了限制，比如禁止输入特殊符号的输入框，是否可以通过copy输入

11. 其他注意事项

1. 网络：与网络有关的业务必须考虑到弱网、断网的情况，比如支付业务

2. 滑动条：页面出现滚动条时，滚动条上下滚动时，页面显示是否正常

3. 分页：上下滑动，查看数据会不会重复显示

4. 测试数据尽量接近真实数据，避免单纯输入“123”、“abc“之类的

5. 进行测试时，尽量不要用超级管理员进行测试，用新建的用户进行测试

6. 测试人员尽量不要使用同一个用户进行测试

7. 对于电子商务网站，当用户并发购买数量大于库存的数量时，系统如何处理

8. 账号是否允许多端同时在线

19- WEB 连接测试

什么是web中的链接？

web中的链接指从一个网页指向另一个目标的连接关系，所指向的目标可能是另一个网页、相同网页上的不同位置、图片、电子邮件地址、文件、应用程序等；Web网站中的导航、页面跳转都是通过链接来完成的。

1. 链接测试点

1.1 链接正确

测试链接是否按指示的那样正确链接到了目标页面

1.2 孤立页面

没有链接指向该页面，只有知道正确的URL地址才能访问

1.3 死链接

死链接是链接原来正常，后来失效的链接。向死链接发送请求时，服务器返回404错误

造成死链接原因：
  1. 目标页面文件移动了位置，导致指向它的链接变成死链接，比如 1单元101变为2单元101
  2. 网页内容更新时链接变更，原来的链接变成死链接，比如 1单元101变为102
  3. 数据库不支持、网站服务器设置错误

2. 链接测试工具 - Xenu

由于页面中的链接很多，所以使用手工测试链接的情况比较困难，在链接测试过程中需要借助连接测试工具 - Xenu

Xenu下载：https://xenus-link-sleuth.en.softonic.com

Xenu是一款出色的死链接检测工具，全称为：Xenu Link Sleuth。它是由德国柏林的Tilman Hausherr为网页死链检测专门开发的免费软件。Xenu也许是你所见过的最小但功能最强大的检查网站死链接的软件了。你可以打开一个本地网页文件来检查它的链接，也可以输入任何网址来检查。它可以分别列出网站的活链接以及死链接，连转向链接它都分析得一清二楚；支持多线程，可以把检查结果存储成文本文件或网页文件。

Xenu是被广泛使用的死链接检测工具。可以检测到网页中的普通链接、图片、框架、插件、背景、样式表、脚本和java程序中的链接。

2.1 优点

• 免费

• 体积小巧（软件大小不到1MB），界面简单易学

• 给出死链接所在页面，方便修改或删除死链接

• 检测速度快，最大支持100线程( Parallel threads)

• 检测范围广，一次检测可以涵盖100万以上的URL总量

• 报告采用HTML格式输出、可以按照网页标题自动生成网站地图

• 支持检测重定向和SSL网站（“https”）

2.2 缺点

• 只检查链接是否有效，不检查是否正确

• 不能检测由JS生成的链接

• 只支持 Windows 操作系统

• 网速慢可能会超时错误（Timeout）

• 极少存在检测不准确问题，可以通过点击死链接进行复验

2.3 Xenu 使用方法

2.3.1 打开Xenu

双击Xenu.exe，打开软件程序

2.3.2 打开检查配置界面

打开 Xenu 后，选择文件 —> 检查网站

2.3.3 输入网址、参数配置

输入需要检查的网站地址（必须要加http://或者https://），如果网站有指向外部的链接，需要检测外连接，则勾选“检查外部连接”

2.3.4 参数配置

点击检查配置页面的更多设置，根据自己业务需求进行修改相关参数，一般都可以选择默认

2.3.5 开始检查

全部设置完成后，点击：开始检查

2.3.6 检查完成

检查完成后，进度条显示100%，弹窗提示是否生成报告

2.3.7 生成报告

自动生成的报告总体来说不太利于浏览，一则报告是全英文，二则统计分类项过多，需要逐一浏览，比较耗费时间。可以通过导出制表符分割文件，导出的txt文件再直接拷贝到Excel表格中查看分析，具体操作步骤如下：

• 检查完成后，弹出提示框，点击“确定”按钮，弹出FTP参数框，不用管直接关

• 为方便查看，点击 文件—>文件导出为制表符分隔的文件，保存txt文件
  

• 将保存的txt文件 【Ctrl+A(全选)、Ctrl+C(复制)，Ctrl+V(粘贴)】粘贴到Excel中保存，对“状态码”列进行“筛选”排序，就可快速定位网站链接 或者修改文本文档打开方式
  

2.3.8 常见的报告状态

20- APP 专项测试

很多小伙伴不知道APP的功能应该怎么测试，其实APP与WEB一样，功能测试主要也是测试软件的功能特性。但APP又与WEB不一样，因为一个是C/S架构，一个是B/S架构。一句话来概括就是APP的功能测试与WEB的功能测试基本上是一致的，相比较web测试，app更是多了一些专项测试。

APP大部分的功能测试都与WEB相同，相同的地方呢，这篇文章就不再介绍了。我们重点可以看看APP测试与WEB测试不相同的地方。

1. 安装

安装、卸载和升级是任何一款APP中都属于最基本功能。一旦出错，就属于优先级为紧要的BUG

1. 软件是否可以正常安装（命令行安装；手机助手等第三方软件安装；apk安装包安装/纯净安装）

2. 安装过程中是否能暂停，再次点击，是否能继续安装

3. 安装空间不足时如何表现，是否有相应提示，提示是否友好

4. 安装过程中断网或网络不稳定的情况下，是否有相应提示，以及网络恢复后是否能继续安装

2. 卸载

1. 是否可以正常卸载应用（桌面卸载、第三方软件卸载、命令行卸载）

2. 应用卸载后所有的安装文件夹是否全部删除

3. 卸载过程中出现异常情况（死机、断电、重启），等待环境恢复后是否可以继续正常卸载

4. 卸载是否支持取消功能

5. 取消卸载后软件能否正常运行

3. 更新

3.1 不卸载更新

1. APP开启后是否跳出更新提示信息

2. 更新提示信息能否关闭

3. 提示的更新信息是否正确（版本号、安装包大小、提示更新内容）

4. 更新弹窗只提示一次，还是每次打开app都提示更新信息

5. 多次关闭和打开APP后是否正常跳出更新提示信息

6. 点击更新是否正确跳转至后台配置的更新页面

7. 更新成功后，软件能否正常使用

8. 点击更新是否正确跳转至后台配置的更新页面

9.  更新成功后，软件能否正常使用

10. 更新后，版本号是否更新

11. 取消版本更新时，老版本可以正常使用

12. 使用第三方软件能否更新

13. 跨版本升级

14. 手机设置自动更新，查看WiFi状态下是否自动更新

15. 内存不足时更新

3.2 卸载更新

- 卸载APP后再更新，能否正常使用

- 更新后的版本号是否正确

4. 交叉事件

主要是指多个应用之间是否有冲突

1. 使用app时拔打电话

2. 收发短信

3. 连接耳机或蓝牙设备

4. 旋转屏幕

5. 第三方应用对软件的影响

6. 低电量告警、插拔充电器等

7. 没有内存空间时，APP能否正确响应

8. 横竖屏切换展示

9. 反复操作某个功能，不断点击和刷新，是否会出现闪退

5. 网络

1. 不同网速（3G、4G、5G、wifi） 下应用的各功能可正常运行

2. 弱网、断网时，数据交换失败是否会有提醒

3. 网络异常时（有网->无网->有网），数据是否可以自动恢复，正常加载

4. 只允许内网访问的APP，在连接到外网时是否有友好提示

6. 权限

1. 首次启动APP询问是否同意启用权限

2. 消息权限开启/关闭时，消息推送是否正常接收

3. 位置权限开启/关闭时，APP能否定位到当前位置，是否有提示引导用户开启权限

4. 网络权限关闭时，APP是否有提示（“服务器或网络错误，请稍后重试”），是否有提示引导用户开启权限

21- 兼容性测试

兼容性测试是指在不同软件、硬件、操作系统、网络环境等多个平台上测试产品的兼容性质量，以确保软件、硬件或产品在各种环境下的正常运行。

兼容性测试主要涉及软件应用程序、网站、操作系统、数据库、浏览器等系统环境的兼容性测试。其中，兼容性测试的重点是测试软件或网站在多个设备、系统或浏览器上的兼容性水平，以保证软件产品能够在不同的环境中达到稳定和一致的用户体验和功能表现。兼容性测试涵盖多种测试方法和技术，如黑盒测试、白盒测试、自动化测试、手动测试等。通过兼容性测试，能够发现和解决软件或网站的兼容性问题，提高软件品质和用户体验，增强软件的稳定性和可靠性。

1. 浏览器兼容

浏览器兼容性测试是在指定的浏览器上检查Web页面显示以及交互是否正常。要测试的浏览器包括主流浏览器Chrome、Firefox、QQ浏览器、Safari、360浏览器等。

在进行浏览器兼容性测试时需要注意：

• 此类测试常见于B/S结构的产品中

• 正式测试前，应由用户明确待测试的浏览器和版本，或者根据软件性质选择几款市场主流浏览器

• 浏览器兼容性测试跟具体的业务逻辑无关

• 留意浏览器版本的升级，阅读更新的版本说明，以了解是否影响已有的测试计划

2. 操作系统兼容

操作系统兼容性测试是在指定的操作系统上检查软件功能是否正常。要测试的操作系统包括: Windows系列、Mac OS X系列、UNIX/Linux 系列、Android 系列、iOs 系列

在进行操作系统兼容性测试时需要注意：

• 此类测试常见于C/S结构的产品中

• 应由用户明确待测试的操作系统和版本

• 注意操作系统升级对原有测试计划的影响

• 注意是否有对同一操作系统多个版本的兼容性要求

3. 数据兼容

数据兼容性测试是指软件升级改造之后数据结构发生改变，因此确认数据在新、老版本之间都能正常运行的测试过程。

在进行数据兼容性测试时需要注意:

• 必须进行向前兼容测试，即新版本的软件要能正常且正确地读取和加载老版本生成的数据

• 同时做向后兼容分析，即分析当前版本的软件能否在后续高版本的平台上正常运行

• 测试数据处理或显示需要调用的 Office 类软件、多媒体制作或播放类软件版本升级对数据的影响

分辨率兼容：页面在不同分辨率下，显示的样式可能会不一样，设置系统的分辨率，缩放浏览器比例查看系统页面显示情况

4. 分辨率兼容

分辨率兼容性测试也被称作适配性测试，是指验证被测软件界面或网页在各种分辨率下的显示器或各种分辨率、尺寸屏幕的移动设备上都能正常显示的测试过程。

在进行分辨率兼容性测试时需要注意：

• 测试应当包括普通分辨率的屏幕和高清分辨率的屏幕

• 关注各功能界面在不同分辨率下是否存在UI展示问题（如果代码没有对不同分辨率做适配处理，就可能会出现错位、遮挡、留白、拉伸和模糊等问题）