软件测试笔记(上)-CSDN博客

本文链接：https://blog.csdn.net/qq_65501197/article/details/147078157

入门介绍

什么是软件测试

软件测试就是查找软件中的缺陷，日常生活中的各样的软件都会出现不同的缺陷，比如页面打不开、500 错误、白屏、崩溃、闪退等等。

        这些缺陷小到影响用户体验感，比如刷新页面三秒钟后才出现数据，体验感知非常不好；
        中到影响功能不能使用，比如软件某一个功能点击完后没反应或直接报错；
        大到影响财产和生命，像之前某电商出现过薅羊毛事件，一晚上损失几百万，还有波音 737 飞机起飞几秒钟后掉落，最后查明原因是因为软件传感器数据有误，导致机毁人亡的悲剧。

这些 bug 之所以需要一个独立的测试，是因为要实现一个软件，需要以下几个流程：了解用户的需求、产品和架构设计、开发编码实现、交付使用。但交付后可能会出现产品设计和最终实现效果有差距的情况。出现这种差距的主要原因有两点：

开发自测时的思维定势后台写了哪些业务、逻辑判断，就去验证哪些，没写的就不去验证；
关键的数据需要专业的测试技术才能验证出来，技术受限。

如果在交付前加上测试，开发编码之后交由专业测试去验证开发实现的效果和产品的预期效果，发现不一致立即修改，直到合格再交付。最后效果可能会超预期完成。

综上所述，软件就必须要测试，而且是独立的测试岗位去做。

同时软件测试也可以结合现在的人工智能，实现AI 赋能软件测试。AI 在软件测试领域里面，现在已有的成熟方案包括赋能功能测试、自动化测试、性能测试、安全测试以及智能测试管理。从细节上来说，可以针对需求评审、测试计划、缺陷预测、测试用例编写、自动化代码编写等。

使用AI进行测试

AI 即人工智能，能让机器模拟和执行人类的智能活动。AI 在测试领域主要有两个作用：

提高测试的速度和效率，这体现在功能测试、自动化测试、性能测试以及安全测试领域；
预测缺陷以及分析、定位缺陷。

在功能测试领域推荐使用文心一言，它是百度的人工智能大模型。对比其他大模型，百度文心一言在文字领域和自然语言领域里具有一定的优势。
要使用它，需在输入对应的指令和模型进行互动。指令即文字描述，可以是一个问题，也可以是一个任务。指令多样化，提问方式不同，得到的结果也不同，结果可能产生二异性。为了减少这种二异性，需先了解指令集在训练时采用的格式。训练时采用的格式是 prompt 这种语言的组成格式，主要有以下几点：

角色：可以输入一个角色并定义，比如“你是一名测试工程师”，AI 就会明确自身角色。
指示：对任务进行描述，比如“需要对以下需求进行设计测试用例或者是设计测试点”。
上下文：给出与任务相关的其他背景信息。
输入描述：任务的输入信息，比如“SQL 注入，兼容性测试，功能性测试”。
输出描述：输出格式的描述，比如要求以 excel 表格形式进行输出。

其中，角色、任务描述(指示)、输出是我们常用的精准要求。接下来基于一个登录功能的需求来演示一遍。现在要对该需求进行设计测试用例。需求有三点：

支持账号密码登录
1. 系统会验证账号和密码的正确性。
2. 验证通过提示登录成功并进入个人中心；验证失败给出错误提示信息并允许用户重新输入。
支持短信验证码登录
1. 用户输入手机号后点击获取验证码，系统向用户发送验证码。
2. 用户输入验证码登录后，验证验证码正确性。
3. 验证通过进入个人中心，验证失败给出错误提示信息并允许用户重新输入。
支持第三方授权登录
1. 支持微信、QQ 和支付宝。
2. 验证通过进入个人中心，验证失败给出错误提示信息。

        接下来使用文心一言这款工具完成登录需求的测试点设计。在输入框下达任务“针对以下需求设计测试用例”，并将上文的三点需求粘贴发送。
        AI 返回的结果基于账号密码登录、短信验证码登录、第三方授权登录分别进行了测试用例设计。不过，我们现在还没有衡量能力，不知道测试点覆盖全不全，后期学习后会有评审能力。
        假设后期发现返回格式简单，不满足需求，有二异性，可以使用组成格式提高返回的精准性。接下来给 AI 定义一个角色“你是一名测试工程师”，指示“需要针对以下需求设计测试用例”，再次粘贴需求。对输入和输出格式进行圈定，输入考虑功能测试、兼容性测试、SQL 注入；输出使用 excel 表格形式且格式参考用例设计八大要素。

再次发送后，AI 工具返回结果中能看到，限制的内容提高了精准性，表格也体现了八大要素。不过，对于具体内容，等后期学习测试用例基础知识后再评定。

从这里能感受到，AI 工具可以提高测试效率和速度：

AI 赋能软件测试的主要作用有两个，一是提高测试的速度和效率，体现在功能测试、自动化测试、性能测试、安全测试等方面；二是进行缺陷的预测以及分析。
对于文字语言处理模型，推荐百度的文心一言大模型。如果对反馈结果不满意，可以使用指令组成格式提高精准度，指令格式主要有角色、指示（任务）、上下文（参考、例子、输入和输出）等内容。

测试基础

测试分类

对于测试分类，我们可以从不同角度划分，大致分为三类：

按软件生产阶段划分；
按软件源代码可见度划分；
按其他规律角度划分。

接下来我们逐一讲解。

按软件生产阶段划分

按软件生产阶段划分，可分为四种：单元测试、集成测试、系统测试、验收测试。这四种测试是根据软件生产过程，从开始到结束每个阶段都要进行的测试。

        以生活中造车为例，单元测试要从最小部件开始，如螺丝、螺母，主要针对单个零部件测试是否符合规格尺寸，一般由开发自测。
        集成测试是把单个零件组装起来测试，主要测试零部件组装情况，由测试人员完成。
        系统测试是车组装完后整体测试，主要验证整体功能和外观，由测试人员完成。
        验收测试是交付给客户后用户进行体验测试，测试对象是用户。

        从代码角度看，单元测试针对程序源代码进行测试，如程序源代码中登录的最小函数，一般由开发自测。
        集成测试针对模块与模块之间、功能与功能之间进行测试，也叫组装测试，由测试人员完成。
        系统测试对整个系统进行全面测试，包括功能和非功能测试，由测试人员完成。
验收测试是用户代表验收项目，测试对象是用户。

以电商系统为例，开发实现注册功能后，针对自己开发的该功能代码进行测试，属于单元测试；从注册、登录以及下单联动一起测试，属于集成测试；项目相关开发人员完成系统全部业务核心功能后，交付给测试进行全面测试，属于系统测试；整个系统上线后给用户使用，属于验收测试。

按源代码可见度划分

按源代码可见度划分，可分为三种：黑盒测试、灰盒测试、白盒测试。

以微信为例，我们在使用微信发语音、发图片、视频、语音电话等功能时，看不到微信的源代码，只对界面和功能进行验证，这就叫做黑盒测试。黑盒测试主要关注数据的输入和结果的输出。

灰盒测试是部分源代码可见，能看到模块与模块之间调用接口的通道，UI 不可见或部分可见。关注的是输入和输出以及数据访问的通道。

白盒测试相当于透明的盒子，源代码完全可见，测试对象是源代码，UI 功能不可见。更多关注代码本身的语法逻辑，如代码中的条件判断、分支、语句覆盖率等。

如果按阶段划分，黑盒测试属于系统测试；灰盒测试归属于组装测试，也叫集成测试；白盒测试归属于单元测试。

以一个系统为例，按源代码可见度划分，有登录界面后，对登录界面里面的功能进行测试，属于黑盒测试；无界面通过工具和代码实现登录功能的测试，看不到登录的全部代码但能看到部分，属于灰盒测试，也叫组装或接口测试；无界面但可以直接对开发的源代码进行测试，属于白盒测试。

其他测试

其他测试主要有两种：冒烟测试和回归测试。

冒烟测试是对核心功能的验证。主要作用是保障在提测时内容具备可测性。
开发编码完成后先自测，自测通过后通知测试提测，测试先进行冒烟测试，验证程序主功能是否具备可测性，避免投入大量人力后发现好多功能不能实现。冒烟测试通过后进行下一步测试，不通过则返回开发修复，具备可测性后再测，最后进行全面测试。

回归测试是对已经修复好的 bug \迭代更新后对已测内容再次测试。
主要作用：如果是回归 bug，保证 bug 确认并修复；如果是对迭代后的功能进行测试，主要确保新功能对旧功能没有影响。
测试发现缺陷后提交给开发，开发修复后测试进行验证，验证的过程即为回归测试。验证通过后关闭缺陷，不通过则返回开发继续修复。

但要注意，开发在修复原有bug时，可能会引发新bug。

新功能迭代测试也属于回归测试，开发编码完成后交付测试，新增模块需要进行测试，同时还要对之前的旧功能进行回归测试，验证新功能增加时是否影响到旧功能的正确使用。

比较严谨的系统，新增功能后要对所有旧功能进行测试，时间紧任务量大时，最起码要对有关联的功能进行测试。

小结

按阶段划分有四种测试：

单元测试：针对程序源代码进行测试，由开发自测；
集成测试：针对单个模块或单个功能组装时进行测试，由测试人员完成；
系统测试：对整个系统进行全面测试，包括功能和非功能测试，由测试人员完成；
验收测试：以用户身份进行验收测试。

按代码可见度划分有三种：

黑盒测试：不关注程序源代码，主要针对程序的功能和界面进行测试；
灰盒测试：能看到程序的部分源代码，主要针对数据访问通道进行测试；
白盒测试：完全关注源代码，对源代码进行测试，属于单元测试。

其他测试类：

冒烟测试：保证提测内容具备可测性；
回归测试：对已修复bug\迭代后的新功能和新功能关联的旧功能进行再次测试。

质量模型

质量模型就是衡量一个软件质量的维度，这个维度总共有八个，分别是功能性、性能、兼容性、易用性、可靠性、安全、可维护性、可移植性。我们要对每个维度都进行衡量和测试，才能保证软件的优秀程度。接下来，咱们逐一讲解每个维度。

功能性

先看功能性，简单来说，就是看软件是否具备的某方面能力，即该功能是否正常。
以游戏软件的需求为例，假设某款游戏软件要求功能数量有 ABC 3 个，并且每个功能都有具体明细要求。测试这款游戏时，首先要确保功能数量正确，不多也不能少；其次，要检查每个功能是否正确实现。
总的来说，功能性主要关注两点：

功能数量是否满足。
功能正确性是否实现。

功能测试一般基于单用户进行，多用户则需要性能测试。

性能

性能测试主要关注多用户同时使用时是否满足需求、能否处理。
仍以游戏软件需求为例，上线后每日需要支撑每日在线用户 20 W，同时支持 200 人并发操作。基于这个需求进行测试，需要考虑两点：

服务器是否能支持 20 万在线用户，要做模拟用户测试；
能否处理200人并发操作，要支持并发测试。

除了这两点，性能测试更多关注时间和资源，在保证满足需求的前提下，响应时间越快用户体验感越好；资源方面，比如 CPU 内存，不仅要支持 20 万，未来可能还需要支持更多，要有一定的冗余度。
总结一下，性能测试最终关注的是支持能力，同时要考虑响应快、资源占比少。

兼容性

        兼容性简单来说，就是软件在不同设备、不同软件、不同平台上是否能正常使用。
        最常见的情况有浏览器兼容、分辨率兼容、品牌兼容，以及操作系统和网络兼容。
        还是以游戏软件为例，假设要兼容所有 Windows 系统，像常用的 Win11、Win10、Win8 和 Win7 都要支持；还要支持不同分辨率的手机，主流分辨率都要覆盖。验证时，要针对这些需求一一覆盖测试。兼容性测试主要就是保证功能正常使用，显示也正常。

易用性

易用性强调易学易用、用户粘性好，主要从用户角度衡量。大致可以从简洁、流畅和美观三块考虑。这三个方面带有一定主观色彩，所以测试时更多要考虑明确需求才能衡量验证。整体来说，主要作用就是提升用户体验。

安全性

安全性主要考虑数据传输安全和存储安全，简单提炼就是加密传输、加密存储。

可靠性

可靠性是指长时间运行稳定不出现异常，主要从死机、无响应、卡顿等常见异常方面考虑，简单来说就是持久运行无异常。

可移植性

可移植性主要指数据迁移方便，因为任何一款系统经过长期使用后，数据量会不断增大，后续需要对数据进行维护和迁移。

可维护性

可维护性就是机器出现故障后能方便维护，或者系统后期迭代、增加新功能时方便操作。
比如系统设计时没加注释，后期维护时发现好多代码看不懂，原有开发离职后根本无法维护，这是不可行的。所以简单提炼就是出现异常易修复。

小结

以微信为例，基于这八点做一个概括。

功能性要与需求文档数量一致，每个功能都要正确实现；
性能方面要考虑响应快、占用资源少，满足在线用户数；
兼容性要在不同设备平台正常使用；
易用性主要指用户体验好，使用不繁琐；
安全性要对敏感信息进行加密传输和存储，比如登录、支付、聊天相关信息；
可靠性要持久运行无异常，不能玩几分钟就关机；
可移植性要方便后期数据迁移和维护升级；
可维护性要方便升级、更新扩展，出现异常后简单恢复。

质量模型的目的是衡量任何软件质量时，都可以基于这八个维度来衡量，同时也是测试的要点。这八个维度分别是功能性、性能、兼容性、易用性、安全性、可靠性、可移植性和可维护性。
在国内，目前主要常用的是前五个，测试时是必须要进行的。

客户端测试

单功能测试

单功能是指软件程序或应用程序只提供一项核心功能或特性，而不包含其他附加功能。

比如在电商系统中，注册、登录、修改订单等功能都是独立的。以测试登录功能为例，在测试之前需要准备一些材料，最常见的资料有产品原型设计以及需求文档。
测试则分为五步：

分析需求。
设计测试点，覆盖需求，同时考虑质量模型，从多维度测试该单功能。
将测试点转为可执行用例文档。
执行测试
缺陷管理(提交-验证-关闭)

接下来以登录功能为例，依次来上述五个步骤。

分析需求

登录需要账号、密码和验证码。其中账号为必填，是以及注册的手机号或邮箱。密码也是必填，需为上文输入的账号对应的密码。验证码需要正确且未过期。

接下来根据需求分析：

账号：已注册手机号、已注册邮箱、为空、未注册手机号和邮箱是否都要覆盖？
密码：注册密码、为空、错误密码（写纯数字，还是纯字母）？
验证码：正确、过期、错误

但如果有多个同类型数据则需要借助等价类划分法来解决。

等价类划分法

等价类划分法是一种用少量数据获得较好测试效果的工具。该工具可以解决表单输入的问题，包括输入框、下拉框、单选框、复选框等。

具体需要三步：

划分有效等价类：满足需求的数据集合，比如已注册手机号
划分无效等价类：不满足需求的数据集合，比如未注册手机号
每类中选取代表数据

提取测试数据，可以使用xmind或excel工具，根据自身喜好选择。

测试项	等价类类型	描述	示例
账号	有效等价类-手机号	已注册的手机号	13812345678
	有效等价类-邮箱	已注册的邮箱	example@example.com
	无效等价类-空账号	账号为空	（空字符串）
	无效等价类-未注册手机号	未注册的手机号	13987654321
	无效等价类-未注册邮箱	未注册的邮箱	newuser@example.org
密码	有效等价类-注册密码	用户注册时设置的密码	password123
	无效等价类-空密码	密码为空	（空字符串）
	无效等价类-错误密码	错误密码	abc123
验证码	有效等价类-正确验证码	用户输入的正确验证码	1234
	无效等价类-过期验证码	验证码已过期	1234（已过期）
	无效等价类-错误验证码	用户输入的错误验证码	5678（正确验证码为1234）

接下来将分析出来的数据进行组合提取，以便于应用。

有效数据测试原则：在账号里，有效数据包括已注册手机号、已注册的邮箱、有效验证码。当我们执行测试时，这三个一起组合使用，点击登录才能测试登录功能。
无效数据测试原则：对于无效数据，比如测试账号为空的情况，其他两个选项的数据应该正确或者不为空，能正确尽量正确，不能正确的话就不为空，以此来验证单独为空项的判断。

提取数据原则(组合原则)梳理：

多个选项的有效数据建议组合应用；
单个选项的无效数据组合其他选项的有效数据应用。

有效与无效测试点

根据这两个原则，测试点可以分有效测试点和无效测试点，又称为正向和逆向测试点。

有效测试点要求登录成功，有两种情况：

覆盖已注册手机号、对应密码和正确且未过期的图片验证码。
覆盖已注册邮箱、密码和图片验证码的有效数据。

这样就把所有有效的点覆盖完了。

无效测试点对于登录功能来说即为登录失败，登录失败的情况如下：

账号为空：根据原则，单个选项无效数据要组合其他选项有效数据应用。所以第一个选项测试账号为空时，后面要加上有效密码和验证码，验证账号为空时的提示信息。
其余情况直接列出，不再赘述：

账号问题
- 账号为空+有效密码+有效验证码。
- 手机号未注册+有效密码+有效验证码
- 邮箱未注册+有效密码+有效验证码
密码问题
- 注册手机号+空密码+有效验证码
- 注册手机号+密码错误+有效验证码
验证码问题
- 注册手机号+有效密码+空验证码
- 注册手机号+有效密码+错误验证码
- 注册手机号+有效密码+验证码过期

        测试点分析时，关注的是单项的有效与无效，但应用时需组合，因为一个功能需多项协同。组合原则有二：
        一是多项有效数据建议组合应用，避免冗余；
        二是单项无效数据需组合有效数据，精准测试。

练习

以一个登录功能为例。进行测试点提取前，要先做分析。该登录功能账号为用户名/邮箱/手机号，还需要对应的密码。

这里主要考虑账号和密码。每一项都包含符合条件和不符合条件的情况，等价类划分就是有效和无效，将其分别标注出来。

账号

先看有效情况，要读懂需求，账号是注册用户名、邮箱和手机号，所以有效情况至少有三个，即注册用户名、注册手机号、注册邮箱。
再看无效情况，因为登录时这些是必填项，所以首先要测试为空的情况。接下来，要测试未注册的用户名、未注册的手机号以及未注册的邮箱。因为手机号、用户名和邮箱对于需求来说是并行的，所以都需要单独验证。比如输入一个不存在的手机号，只能覆盖手机号的验证，覆盖不了邮箱和用户名。

密码

对于密码，有效情况是注册时使用的密码，即正确密码。
无效情况就是为空以及错误密码。

这样，练习分析就完成了。我们来数一下，正向（有效）测试点应该有三条，因为账号这一项最多有三条，即注册用户名加正确密码、注册手机号加正确密码、注册邮箱加正确密码。逆向（无效）测试点总共九条。这里给大家扩展一下，在企业里，有效数据专业术语叫正向，无效数据有时叫逆向，意思是一样的。

有效与无效测试点列举

有效测试点是登录成功，数据填写如下：因为账号有三种（有效的用户名、手机号和邮箱），分别列出即可。

有效（正向）
- 登录成功（注册手机号+正确密码）
- 登录成功（注册用户名+正确密码）
- 登录成功（注册邮箱+正确密码）

        无效测试点即登录失败。先测试账号为空&密码不为空（此时写正确或错误密码没区别，因为账号本身不存在，所以只要密码不为空即可）。接下来，账号未注册的情况有未注册手机号、未注册用户名、未注册邮箱，分别加上密码不为空（复制三个，前面分别改为未注册用户名、未注册手机号、未注册邮箱）。
        对于密码，账号必须有效，有效账号有三个，选任意一个即可。密码有两种情况，为空和错误密码。继续登录失败的情况：注册手机号加密码为空；注册手机号加密码错误。
        前面已经覆盖了注册手机号，后面要不要换成注册邮箱或用户名呢？换或不换都行，因为这两个已经单独测过、覆盖到了。

无效（逆向）
- 登录失败（账号为空+密码不为空）
- 登录失败（未注册手机号+密码不为空）
- 登录失败（未注册用户名+密码不为空）
- 登录失败（未注注册邮箱+密码不为空）
- 登录失败（注册手机号+密码为空）
- 登录失败（注册手机号+密码错误）

边界值分析法

接下来通过案例来学习长度范围测试点分析。案例我们采用网易的 163 邮箱注册。

需求总共有三项：

账号：未注册手机号且不能为空
密码：8~16个字符，需要包含大小写字母和数字
条款：需勾选才可以注册

其中账号和条款可以用之前所学的等价类方法来设计覆盖。这里重点看密码。密码的需求是要求 8 - 16 个字符，包含 8 和 16，同时需要包含大小写字母及数字。也就是说，比如八位字符，应该由大写字母、小写字母以及数字这三个进行组合才符合规则。

基于该密码需求，先来用之前所学的等价类划分来分析。
对于有效情况，长度和规则都需有效。长度选八位，规则为必须包含大写字母、小写字母以及数字。

而对于无效情况，有长度无效和规则的无效。
长度无效有两种情况，一是小于八位，二个是大于 16 位。同时在在测长度无效时，注意密码规则一定要符合范围，比如选五位的密码，但必须是由大写字母、小写字母以及数字组成；同样，大于 16 位选 18 位，规则也应该符合。
然后是规则无效。想要对规则单独测试，则长度必须符合 8 - 16 位之间。因为密码是必填的，所以规则可以先覆盖为空。接下来对大写字母、小写字母以及数字进行覆盖，比如长度符合都抽取十位，十位纯大写字母、十位小写字母、十位数字。

经过分析得出的测试数据，假设后台对于密码长度的判断是密码长度8<密码.length<16，（需求是大于等于八位、小于等于 16 位，但开发实现写成大于、小于，少了等号），再对照之前设计的测试数据覆盖，只覆盖了八位、16 位，没有覆盖这种情况，说明设计好的测试输入数据有 bug，有缺陷，测试有遗漏。

为解决此问题，我们需要引入边界值分析法，其主要针对边界范围限制来选取测试数据。
比如范围限制是 100 - 300，包含 100 和 300。选点要从三个方面考虑：

上点：边界上的点，100 和 300 是必测(无论包含与否)；
离点：离上点最近的两个点，因为有两个上点，所以离点有四个，选择哪两个主要看是否包含上点。
- 不包含上点选择范围内的点（不包含 100则选 101，不测 99，因为 100 是必测，如果不包含则不通过，99也自然不会通过，只需测101即可)
- 包含上点选择范围外的点（如大于等于 100），上点(100)必测，但不能说明不包含 99，需要测试，同理101可不测。因此如果包含 100 - 300，测试的点应该是 99 和 301；
内点：范围内的点，101 到 279 都是范围内的点，可以选择任意一个点，建议选择中间位的点，因为中间位置可以判断范围的连续性。

边界值分析法在使用过程中要配合等价类进行测试点覆盖。
具体步骤是，先用边界值分析长度范围问题，有关长度范围的全用边界值选取五个点（只要有范围就是五个点，2上点+2离点+1内点）；其次用等价类划分方法负责类型和规则问题，进行覆盖；最后设计测试数据提取。

回到案例，先分析密码，按照整体步骤划分为三步，第一步用边界值分析长度，结果分为有效和无效。
        有效的话选 8 - 16 位，按照边界值分析方法有五个点，其中有效的是三个（两个上点和一个内点）。8位和 16 位是上点必须要测；
        离点因为包含 8 - 16 位，属于无效的，所以选择小于八位的（如五位）和大于 16 位的（如 18 位）；内点选 8 - 16 位之间的一个点，比如 11 位。
        第二步考虑规则，使用等价类，有效规则上面已经覆盖完，接下来考虑无效规则，长度要符合 8 - 16 位之间，取十位，规则不符合，比如十位纯大写字母、十位小写字母、十位数字，还有一个为空。

有效
- 上点
  - 8位大写、小写及数组组成
  - 16位大写、小写及数组组成
- 内点
  - 11位大写、小写及数组组成
- 离点
- 5位大写、小写及数组组成
- 18位大写、小写及数组组成
无效
- 10位大写字母
- 10位小写字母
- 10位数字
- 为空

密码部分处理完成后，来处理账号和条款部分。

账号的有效与无效情况需要仔细分析。有效账号指的是未注册且不能为空的手机号。而无效账号则包括为空和已注册的手机号。在思考账号验证时，我们不仅要考虑有效与无效，还要思考是否需要对账号的位数和类型进行验证。例如，在注册时，如果无意中少输了一位或多输了一个字母，需给出对应的提示。因此，在注册时还需要测试账号的位数和类型。对于位数，非11位数字应视为无效；对于类型，11位非数字也应视为无效。

账号
- 有效
  - 未注册手机号
- 无效
  - 为空
  - 已注册手机号
  - 非11位数字
  - 11位非数字

对于手机号的具体位数和类型（如第一位是几，第二位是几），如果没有特殊要求，我们不建议进行详细测试。因为输错号码将无法获取验证码，且未来还会有新的号码段出现，这种测试的意义也不大。除非有明确要求，如通信验证，否则可以不测。

接下来看条款部分。条款的有效与无效情况相对简单。有效条款就是勾选，无效条款就是为空即不勾选。然后基于有效和无效的原则来提取测试点。我们先回顾一下提取规则：多项有效数据可以组合应用，而无效数据则需要与其他项的有效数据组合使用。

先来看有效用例数量。密码部分最多，有三个有效密码用例；条款部分有一个；账号部分有一个。因此，有效数据用例共有三条：八位合格密码、未注册手机号和勾选协议。注册时，这些有效数据应导致注册成功。

然后是无效数据用例。遵循的原则是：各项的无效数据加上其他项的有效数据组合。例如，当账号为空时，密码和协议都要求是有效的，这会导致注册失败。我们将显著的测试点放在前面，如账号为空加上合格密码和勾选协议。

同样可以为账号的无效情况（如为空、已注册手机号、非11位数字和11位非数字）以及其他无效密码情况（如五位、18位、十位大写字母、十位小写字母、十位数字和空密码）分别创建用例。每个无效情况都需要与其他有效数据组合使用。

最后来看条款为空的情况。当条款为空时，其他项必须是正确的，这会导致注册失败。我们可以为这种情况创建一个用例：有效密码、有效账号和空协议。

注册失败（账号为空+有效密码+勾选协议）
注册失败（账号为已注册手机号+有效密码+勾选协议）
注册失败（账号为非11位数字+有效密码+勾选协议）
注册失败（账号为11位非数字+有效密码+勾选协议）
注册失败（5位大小写及数字密码+有效账号+勾选协议）
注册失败（18位大小写及数字密码+有效账号+勾选协议）
注册失败（10位大写字母密码+有效账号+勾选协议)
注册失败（10位小写字母密码+有效账号+勾选协议)
注册失败（10位数字密码+有效账号+勾选协议)
注册失败（空密码+有效账号+勾选协议)
注册失败（有效密码+有效账号+不勾选协议)

非功能测试

无论是功能测试还是非功能测试，各种测试其实都是围绕质量模型来制定的。除了功能测试以外，其他七项都可以理解为非功能测试。因此，非功能测试的定义是比较广泛的。除了公共软件的功能测试以外，其他如文档、安装卸载、升级等都属于非功能测试。

非功能测试有很多方面，其中易用性、性能、安全性和兼容性四项是常测的。而性能测试和安全测试是一些专项测试，有专门的测试部门和测试人员负责。在编写功能测试用例时，我们可以将兼容性考虑进去，并在用例中直接体现。例如，对于外部项目来说，兼容性主要涉及四大浏览器：谷歌浏览器、EDGE预览器、火狐浏览器以及苹果浏览器（Safari）。

易用性主要以主观感受为主，没有统一标准。如果产品有明确的易用性要求，例如菜单不能超过三级、任何地方都应有导航页等，我们就可以进行验证。

兼容性测试属于非功能测试，一般针对整个项目编写测试点，而非针对某一个单功能，因为那样会特别多且重复。在功能测试阶段可以以兼容性为主。对于浏览器，主要测试四大浏览器，并确保所有软件功能、页面和功能显示和操作正常。可以在测试用例中标注浏览器名称，并默认使用最新版本。

测试用例

测试用例就是描述测试点执行时所需要的文档，便于执行。这个文档主要增加了一些信息，比如测试输入的条件、数据，以及预期结果的相关描述，使其更加精准。将一个测试点转成一行描述的测试用例文档，又叫测试执行文档。

在之前的测试点描述登录成功时，只描述了使用注册手机号加正确的密码，但转成文档后，除了登录成功，还有跳转到主页这一步骤，这在写测试点时可能没有详细描述。此外如果业务稍微复杂，需要经过繁琐的步骤，或者在操作步骤之前有准备工作，没有这个文档的话，执行时很容易遗忘，或者很难把测试点执行下来。

        综上所述，将测试点转成用例文档主要有两个作用：
        第一个是能确保测试点能被精准地执行；
        第二个是便于团队协作，因为测试点当下设计完了以后，未必是立马去执行，可能需要经过一个月或两个月后再去执行，毕竟需要项目写完了才能执行。

测试点转为测试用例主要是通过表头，这些表头简称为八大要素，也就是测试用例的八大要素。接下来，我们逐一讲解一下这八大要素。

用例编号：代表这条用例的唯一性，一般格式是由项目的简称加模块简称加数字。例如：Hmtt_login_001
用例标题：该用例执行的期望结果，后面跟上一个小括号，内部写上例执行的测试点。例如：登陆失败(密码为空)
所属模块：模块名称，以该模块名称区分这个用例归属模块
优先级：描述用例的重要程度，最高是P0，然后到P3。
前置条件：执行操作步骤时所需要的前置条件，理论上来说应该和测试步骤无缝对接，作用是简化我们的测试步骤。例如用于测试的账号和密码是正确的。
测试步骤：测试点执行的关键步骤，把关键步骤写上即可。
测试数据：用于测试的数据。
预期结果：该用例执行后的预期结果以及隐性的结果。隐性结果就是我们执行完这条用例以后，还需要关注哪些，比如下单成功后，订单状态为待发货，在个人中心能查到该订单等。

判定表

判定表是一种以表格形式表达多条件之间逻辑判断的工具。在这个表格里，有条件、动作、条件的组合以及采取的不同动作的展示。它的主要作用是对多条件之间有约束规则的需求设计测试点。

判定表由四部分组成：

条件桩：列出问题中的所有条件。
- 例如，某促销活动优惠，在指定时间段内消费且消费金额满1000元时享受九折。从该需求来看，条件应该有两个，一个是指定时间范围内，一个是满1000元，九折是结果。所以列出条件后，指定时间段和满1000元是两个条件。
动作桩：列出问题中可能采取的操作。
- 如果满足条件，有九折优惠；如果不满足条件，没有优惠。所以操作应该是两个，一个是九折，一个是无折扣。
条件项：列出条件所对应的取值。
- 任意一个条件的值都有两个，即真（成立）和假（不成立），这里用“是”和“否”表示。指定时间段有“是”和“否”，满足1000元也有“是”和“否”。
动作：根据不同的条件采取不同的动作。
- 如果指定时间段和消费1000元都满足，可能采取的动作是打九折；如果有任何一个不满足，可能就是无折扣。采取的动作就是要么打九折，要么无折扣。

判定表中贯穿条件项和动作项的一列就是一个规则，每一列就是一个规则。
假设有N个条件，每个条件取值都有0和1（这里对应“是”和“否”），那么全部组合应该有2的N次方条用例。比如两个条件，就是2的二次方，四个用例（规则）；三个条件，就是2的三次方，八条用例（规则）；四个条件，就是2的四次方，十六条用例（规则）。

执行用例

        在项目开始测试之前，我们还有两个前置准备。
        首先，要确保项目要执行用例对应的功能开发已经完成，并且交付给测试了。
        其次，交付给测试的内容已经部署在项目里，可以运行、可以访问，也就是项目环境已经准备好了。

在整个测试过程中，我们需要关注主要有三点。

用例的执行结果，比如登录成功或者登录失败，要和预期结果一致。如果不一致，就一定是缺陷。
隐性结果。隐性结果和实际结果正常执行完后，应该有相似之处，不能出现模棱两可的东西。
如果实际结果与预期结果有争议处，需参考用户角度衡量。

缺陷管理

软件中存在的任何问题，也叫缺陷（bug）。
软件缺陷是指系统中存在的任何不符合需求或影响使用体验的问题。这些问题不仅包含代码错误，更涵盖功能缺失、设计不合理等范畴。例如登录功能缺少"忘记密码"选项，或电商系统强制收集身份证号等敏感信息，都属于缺陷范畴。

缺陷的五个核心判定维度：

功能缺失：需求要求两个功能，实际仅交付一个（如登录缺少密码找回）
多余功能：超出需求范围的功能（如电商系统支持身份证号登录引发隐私风险）
功能错误：核心流程未正确实现（如正确输入后仍登录失败）
隐性缺陷：包含流程缺失（登录成功未跳转页面）和违规设计（强制展示违法广告）
体验缺陷：操作复杂、响应缓慢或界面不友好（需测试人员从用户视角判断）

当发现缺陷时，需通过专业工具（如禅道）规范提交，关键要素包括：

当前指派：明确指定修复责任人（如前端张三/后端王五）
缺陷类型：区分代码错误、设计缺陷等类别
标题描述：精准概括问题（技巧：测试点+预期结果+实际结果）
严重程度：评估影响范围（低/中/高/严重）
优先级：定义修复紧急程度（24小时/48小时/下个版本）
复现步骤：清晰描述前置条件、操作步骤和测试数据
附件补充：上传截图、日志等辅助定位材料

四、实战案例演示
以"登录失败提示信息不准确"为例：

标题：登录模块-账号为空时提示信息不准确
描述：测试点（账号为空+密码非空）、预期结果（提示"账号不可为空"）、实际结果（提示"账号或密码不可为空"）
严重程度：低（提示信息问题）
优先级：3（下个版本修复）
复现步骤：打开登录页→输入空账号+有效密码→点击登录→观察提示信息
附件：上传实际提示截图

缺陷跟踪流程

        当测试人员发现缺陷后，需规范提交缺陷报告。开发团队接收到缺陷后，若当前负责人无法立即处理，可协调分配给其他同事，但需确保沟通到位。
        接收缺陷的负责人需优先判断该缺陷是否重复：通过检索同类问题库，若已有相同问题被提出且正在修复，则可直接标记为重复缺陷并关闭，同步告知测试人员修复进展。
        若确认为新缺陷，开发需基于报告中的复现步骤进行验证。确认无误后，需评估修复优先级：对于需立即处理的问题，开发应着手定位代码根源并修复；若需延期处理，则需标注对应版本号。完成修复后，开发需将缺陷状态更新为"已解决"，并注明修复版本（如1.4版本），触发测试验证流程。
        测试团队在收到"已解决"通知后，需在新版本环境执行回归测试。若验证通过，则关闭缺陷并归档；若问题仍存在，需重新打开缺陷并附加复现证据，重启处理流程。此阶段需特别注意版本同步，确保测试环境与修复代码版本严格对应。