软件测试思维在项目质量保障环节中的应用

前言：随着敏捷、DevOps 等模式的引入以及大数据、人工智能、微服务等技术的发展应用，软件交付周期逐渐缩短，技术复杂度不断提升，对产品质量的保障也提出了越来越高的要求。质量是软件的生命，软件质量保障是一个系统工程，贯穿了软件的全生命周期。打造高质量软件产品，需要软件工程的各个领域和各个环节共同发力。

在公司实际项目工作中，我们能够按照项目既定的进度和质量前进。注重过程质量，注重代码质量，以及注重工作方式、过程方法、过程产物，可以尽早、不间断进行测试。同时，项目组成员也具备一定的执行力、问题反馈、沟通和协调能力。在项目开展过程中，不断地进行总结和完善，寻找适合的方法，更高效完成工作。

01 如何理解软件测试

在日常项目工作中，我们可能遇到过这样的问题。

● 项目提测了，代码刚部署完，发现流程走不通

● 冒烟测试时，某个重点功能走不通，个别模块交互存在问题

● 测试了一半，发现系统某个重要功能尚未实现

当问题被发现后，我们需要第一时间去进行沟通，开发同学不断进行修复，测试同学反复进行验证，浪费很多人力成本和时间成本，影响项目进度和项目质量。

为什么会出现这些问题呢？其实有很多方面的原因。

● 对项目任务优先级理解不同，导致只开发了部分模块就提交测试了；

● 需求触达人员范围覆盖不全，并且不同角色对同一需求存在理解上的偏差；

● 业务场景过于复杂或者突发临时高优先级任务，导致没有充分的进行自测；

● 认为功能很简单，忽略了测试工作；

● 测试工作没有尽早的融入项目过程中，导致暴露问题太晚；

当我们的项目中出现了这些问题，也就说明我们项目的质量可能会存在一定的风险。

面对各种各样质量问题，我们可能会发出疑问：

Q：为什么这个bug没被测出来呢？

业务场景是与时俱进的，所以测试案例设计只能尽量覆盖，但确实是不能穷尽的，测试只能证明已发现的问题是不是缺陷，不能证明软件没有缺陷。我们更需要从设计上开始进行把控，以便能尽早充分发现缺陷。

Q：测试是如何参与到项目工作中的呢？

测试并不是孤立的，受产品需求、开发设计、编码的影响。在前期，测试工作主要是根据产品需求文档、设计文档进行设计，编写测试目标、测试计划、测试用例等。如果产品需求受制于客观条件，有些场景未调研清楚，那我们的案例也会存在偏差，所以整个测试工作都是需要产品、开发、测试紧密结合，共同保障全周期的质量。

Q：为什么测试反馈会不及时呢？

专职测试人员的主要测试工作是在后期，会受项目进度的影响，时间容易被压缩。为了能更充分的进行测试，所以我们的测试设计工作需要尽早的介入项目中，与项目各方进行合作，就能大概率规避部分问题的发生。

在项目实施过程当中，从实践角度来说，测试应该贯穿项目产品整个生命周期，做好缺陷预防和缺陷发现。

我们都知道在不同阶段发现问题和解决问题的成本是不一样的，注意这里说的是项目整体成本，而不是单一个人的工作成本。在coding阶段发现问题并解决问题虽然会造成开发人员的单一工作量提升，但是相较于后期发现问题进行返工，届时涉及项目人员角色更多，从而导致总体成本更高。

（项目实施流程）

所以项目经理确认项目立项时，应根据项目性质，确定测试策略。如果需要经过测试人员介入，应该召集产品、开发、测试、配置管理人员等，尽早介入项目需求中。测试人员和项目干系人进行全流程合作，更充分地理解需求以及设计测试用例，帮助团队在编码前识别一些风险。

这也就是测试工作中常说的测试左移、测试前移。当我们测试前移了，很多问题都可以在前期得到保障，就算提测时间晚，但是提测质量相较于之前的方式是提高的，同时测试也可以花更多的时间和精力对业务场景进行更广泛的覆盖，系统上线后的质量也更有保证。

小结

1.软件质量并不仅仅是软件测试

质量是贯穿产品过程的大质量，软件测试关注的更多是产品质量中的一个小质量。质量更像是一种预防的行为，而测试像是个检测的行为。我们所说的软件测试，主要是为了保证产品质量。

2.测试工作不只是测试人员的工作

项目经理、产品经理在前期对项目需求和产品方案的统筹工作，开发人员在开发阶段的单元测试工作，这些都属于质量工作的一方面。

3.质量的保障=产品+研发+交付+运维+运营全流程工作的有效配合

在项目实施流程中，一个项目的成功落地，会经历几个阶段，需求调研、项目立项、产品设计、开发设计、测试设计、上线运维保障、后期运营维护等。

每个阶段都必不可少，每一个项目成员都应该是质量管理员，我们除了需要做好自己的工作，也需要与其他项目成员密切配合，共同保证整个项目的质量。我们的目的不仅是为了将测试做好，更是为了将项目做好。

02 如何开展测试工作

进行测试工作的基本假设是“有罪推断”。即：认为被测程序一定是有bug的，而且每个功能点的实现都存在bug，而且一定存在严重的bug。

在项目测试工作中，一定要牢记这个假设，一旦我们在日常工作中产生了这样的认识，“这个功能很简单，肯定不会有问题”、“这个功能上一轮或上一迭代刚测试过，当时就没有问题，这一轮应该也不会有问题”，然后就不再进行测试了，那么我们在之后的工作中极大的概率会造成漏测，容易发现问题不及时或者产生线上问题。

为了保障我们的产品质量，我们每个人，特别是开发工程师，在单元测试阶段以及我们服务的客户在用户测试阶段，就应该具备测试思维方式并掌握相应的测试设计方法。

Part 1  软件测试思维

在日常工作中，软件测试的工作主要是站在系统及业务角度上分析产品需求，设计测试用例，保障产品质量。其实，这并不是毫无逻辑的盲目抓瞎，也是有运用测试思维去完成这项工作，来提升工作效率和保障系统的稳定。

我们常见的软件测试思维有系统性思维、分析性思维、批判性思维、发散性思维、探索性思维、逆向思维等。

1.系统性思维

系统性思维就是站在全局角度思考问题，先定义清楚系统中的核心元素，再思考每个元素之间的关系，如果其中一个因素的变更，那么会给其他因素带来什么影响。

（图为数科惠农云小程序业务办理流程）

①从整体上看，系统的功能主要是申请业务，完成业务并显示。

②我们对这个流程进行分析，考虑这个过程中包含哪几个因素。包括：申请人、业务类型、业务参与人、签署申请书、业务完成。

③最后考虑这些因素之间有什么关系。

我们以申请人已婚有配偶场景为例：

（1）如果申请人已婚，申请线上签约业务时，需要关联人邀请且配偶需要签署申请书；

（2）如果申请人已婚，申请线上产品业务时，则无需关联人邀请且配偶不用签署申请书。

当我们接受到这个功能进行开发或者测试时，如果只考虑到线上签约的场景，有配偶需要签署申请书，就会忽略了线上产品不需要签署申请书的情况。从而导致因系统功能复用，对应的业务场景不同而产生相应的bug。

所以我们考虑问题时，一定要对业务场景中每个因素进行分析，找出他们关联业务及服务。

2.分析性思维

分析性思维帮助我们建立一种循序渐进的思维方法，从收集问题的相关信息、比较不同来源的信息、明确真正的问题，找到问题解决方案，一步一步地去解决。

3.发散性思维

软件测试分析和设计中，我们常常需要借助良好的发散性思维，来发现更多的测试点、列出更多的应用场景。

在我们确定测试范围后，需要对某个功能点进行分析。可以从以下几个方面进行考虑，如“功能、数据、逻辑、操作、界面、需求、异常场景”等。

在数据分析中，主要包含正常数据、错误数据、异常数据。

以担保业务系统为例，从数据以及异常角度，简单来看两个小例子：

案例1---数据相关：

担保业务系统在项目提报流程中，填写贷款申请信息时，限制了贷款利率需>2。

====》我们可以分析出：

（1）显性需求：>2; （2）隐形需求：支持两位小数，仅支持数字。

对需求进行测试分析，可以得到以下测试案例数据：

案例2---相关异常场景

使用担保业务系统app时，可能会因为误操作或外界原因，导致系统出现异常。

我们可以从以下几个方面进行考虑：

Part 2 测试设计方法

在测试过程中，我们拿到一个项目，一般先梳理测试功能点，再根据测试设计方法编写测试用例。

测试点不等于测试用例。测试点在内容上有重复，存在冗余；测试点的测试输入不明确，不知道测试时要测试哪些；测试点描述得太粗，不知道是不是测对了。所以我们一般通过执行测试用例来进行相关测试。

软件质量属性

软件测试的一个目标是验证产品质量是否满足用户需求。在软件产品质量模型中，将一个产品的质量划分为六大属性（功能性、易用性、可移植性、可维护性、可靠性、效率），这每个大属性又会细分成多个子属性。一般情况下，一个高质量的产品在质量六大属性中都很出色，如果产品在六大属性中有所缺失，那么产品可能就存在一定的质量风险。在软件测试过程中，我们判断一个产品是否符合质量，一般可以从以上几个方面进行设计。

四步设计方法

在确定了测试点之后，我们需要观察测试点类型，对测试点进行设计。一般来说，我们目前接触到的项目根据业务特点基本可以划分为流程类、参数类、数据类、组合类四个类型。而对于每一类我们都有相应的设计方法。

03 举个例子

下面我们通过两个例子，来了解软件质量六大属性和四步设计方法的应用。

例1：比如有一个杯子，如果我们要对这个杯子进行测试，从软件质量属性方面上考虑，我们该怎么设计呢？

从软件质量六大属性上，对杯子进行分析。

例2: 刚才我们是从软件质量属性方面思考一个产品是否满足质量，我们现在再从软件设计上考虑产品是否满足质量。

在做功能测试时，我们唯一能做的就是保证这个业务逻辑的正确性以及各个功能尽可能地正确。我们来看这个例子。

（上下文案例中涉及数据均为非真实数据）

这是名单制项目需求变更前的一个名单准入场景，选取了其中一条白名单准入策略规则，经过对数据及方案的加工处理，得到的一个测试场景。 首先明确我们要做的测试任务，需要验证申请人是否有资格申请业务，其中会有很多判断条件。我们将判断条件分析整理后，可以得到这个流程图。

软件设计方法又是如何得到应用的呢？

路径分析法

所谓路径分析法，就是指对能够覆盖流程的各种路径进行分析，得到一个路径的集合。

从图中，可以看到，业务一共有7条路径，一个正向流程，六个逆向流程。我们将业务流程梳理后，进行分析，就可以得到7条路径的集合，这7条路径就是7条测试用例。这也就是我们的流程类设计方法。一般来说，流程类分析主要用于开发自测阶段流程验证以及系统测试阶段主流程验证。

（流程类测试设计-路径分析表）

输入-输出表

所谓“输入-输出表”，即充分考虑各个参数之间的关系和约束条件，并进行逐一分析，进行100%覆盖。

整个流程涉及到六个判断条件，我们在测试设计过程中，需要对每个条件都进行分析，一个输入对应一个输出，不同的输入条件也会有不同的输出结果，也就是我们可以根据不同的输入条件得到不同的测试用例。

（参数类测试设计-输入输出表）

数据分析法

所谓数据分析法，就是我们首先对“输入”进行等价类划分，再将每个等价类的边界值作为测试的样本点。前面有说过，数据设计分为正常数据、异常数据和错误数据。

如果对输入条件进行等价类划分，正常数据可看作我们的有效等价类，错误数据可看作我们的无效等价类。在测试过程中，除了对等价类进行划分，也要考虑边界值场景。

（数据类测试设计-等价类分析表）

组合类测试设计

所谓组合类测试设计，算是对前面几种方法的综合考虑。使用等价类和边界值的方法来确定每一个因子取值，因子比较多时，可以两两进行组合，按照唯一变量原则，进行相关用例设计。

（组合类测试设计-因子表）

我们学习软件测试思维和设计方法并不能保证在日后的工作中不会有新问题产生，而是要尽量避免产生更多的问题。

04 小结

1.那我们如何保障产品质量呢？总的来说六个字：流程、制度、方法。用流程保证项目相关环节是可控的、有序运转的；用制度约束和激励项目相关人，保证项目的正常进度；用软件工程方法提升项目测试人员的测试效率、测试深度和测试广度。

2.思想是内核，技巧只是辅助，学习再多的思想和技巧，我们都需要有大量的实践。希望我们在今后的工作中，对业务的设计可以更完善，先思后行。在实际项目工作中，能够按照项目既定的进度和质量前进；注重过程质量、代码质量、以及工作方式、过程方法、过程产物，尽早、不间断进行测试。提高自己的执行力、问题反馈、沟通和协调能力，不断地进行总结和完善，寻找适合的方法更高效的完成工作。

3.工作不能教条，我们这些从事软件工程和数据工程的各类工程师，都应对突发性事件以及必要的需求变更有兼容性和适应能力。毕竟这类事件不是常态化的工作主旋律，所以一旦出现，我们所有的角色都要怀着极大的责任心，甚至需要牺牲个人的业余时间来以测试思维保障工作成果的质量。

最后：下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

整套资料获取