初级测试工程师必看的功能测试六点要义

前言

根据一份报告，应用程序崩溃导致71％的卸载。迫使用户卸载应用程序的其他原因是页面响应时间，混乱的UI，电池消耗等。这表明功能测试和非功能测试对于交付用户友好型应用程序的重要性。

一、测试基础的重要性

作为一名测试新人，测试基础非常非常重要。这里说的基础，不仅仅是什么是软件测试、软件测试的目的，而是测试用例的设计能力。

因工作的原因，近来接触不少毕业3、4年，甚至7、8年的测试同学，对用例设计还是停留在理论阶段，这让人不免有些无力吐槽。

问题：软件测试用例的测试方法有哪些？
回答：等价类、边界值、因果图等等。
问题：结合实际的业务场景，来说说常用到的测试用例设计的方法。
回答：不少回复都是以登录来做说明的。

其实日常工作中，常用到的用例设计也就那么几种，如果我们能把理论好好应用到实际工作中，那么涨薪其实也很容易。

那么，怎么样才能设计出好的测试用例呢？业务、业务、业务，重要的事情说三遍。

结合实际的业务场景设计用例非常重要，用例中不仅仅涉及到当前的功能，还需要把上下游关联的业务考虑进去，尽可能覆盖完整。下面就来给大家着重介绍一番~

二、提升数据库处理能力

作为一名合格的测试人员，数据库的增删改查、关联查询是必会科目。但对于测试新手来说，这个难度似乎有点大，很多人做事前往往关注的是表象。

比如：点击保存、提交保存，那是否就判断保存功能是正常的呢？

而正确的做法是，我们必须去数据库中查看数据落库的情况，确认字段值是否存储正确，涉及到有业务关联的功能，也需要到数据库中，对数据的准确性进一步确认。对业务数据流向做到心中有数才行。

三、具备定位问题的能力

在测试过程中，我们经常会遇到接口报错、异常错误信息等情况。作为一名测试新人，你可能第一反应就是直接丢给开发：“喂，兄弟，你这里报错了。”

可是当开发人员问：“是前端还是后端报错啊？”

你可能就只剩下一脸懵了。因为目前大部分软件都是前后端分离的。所以，此时你要做的，就是学会看日志。

通过日志，初步判断是前端还是后端问题，包括：借助抓包工具判断是否是前端传值传错了，还是后端逻辑处理错误等相关问题。并通过初步定位问题，帮助开发人员提升解决问题的效率等。

四、具备总结能力

作为测试新人，我们要多总结。

作者曾问过一名刚毕业的同事，他有一套自己的总结方式比如：通过x-mind梳理总结/梳理业务，遇到的问题会记录处理方法，在测试工作中也形成自己的经验总结，并将自己的方式分享到团队中，这名同学在公司成长非常快，因表现突出，得到晋升。

作为一名技术同学，总结能力非常重要，在日常工作中我们会踩各种各样的坑，将这些遇到的问题总结汇总形成经验并分享给他人，在竞争中也能够更加突出，在之后的工作中可以时不时翻出来看看，每次都会有不一样的收获。

五、适时做好能力提升

技术人员的永恒话题：技术水平的提升。

新人在前期成长非常快，在测试过程中可以多思考，遇到问题想想是否有更好的方法解决。

之前听说不少新人心态比较浮躁，动不动就想用自动化解决问题，但自己的自动化测试水平有限，做起来问题层出不穷。

几乎可以说是，走还没有学会就想跑等问题。以为我们可以先打好基础，做好功能测试，在理解业务的情况下，考虑如何更加高效/高质量的完成测试工作。

作者以为，其实有些同学在处理测试工作时，很多时候是为了自动化而自动化，不少自动化框架既没有运用到工作中，也没有产生实际的价值，还没有自己的思考。建议大家可以先做一个框架，然后引入一定的思考，结合业务来的做自动化测试。

比如，可以从市面上已有的工具入手。

举个例子：接口测试工具jmeter/postman等等，先通过工具了解接口测试流程以及方法，再结合自己的业务，发现当前测试工具解决不了的问题。后期再结合业务开发平台，不断思考和实践。

六、功能测试的测试工作流程

1、测试计划：这个计划，我个人觉得应该在详细设计确定后，代码开始编写的时候进行制定，因为我是“提早开始测试工作”思路的忠实fans.

a) 测试计划，主要是给后面的测试工作一些指南，不能写成领导看的计划，而是要写成由做事的人看的计划

b) 包含的内容可能有：

测试团队人员及分工(要确定当测试时出现缺陷界定、测试环境准备等问题时能找到指定的人员)
测试开始结束时间(理想情况下，不要安排的太紧，赶工肯定会造成延期或测试不完整，可惜理想和现实的差距被规定为很大)
测试环境配置(什么样的硬件条件，是否网络、设备等，系统在什么地址访问，访问权限、使用的测试数据等方面的预计和准备)
测试哪些东西要说清楚，这里我建议把简单的测试大纲纳入测试计划中，一方面领导可以看到你的计划写的多详细，另一方面大纲可以很好的成为编写用例的依据
怎么测试要说明白，如只做系统测试，那就要写清楚不做集成测试，如果需要集成测试，就需要写明白集成顺序。另外如果需要进行性能、文档、等其他的测试也要在这个计划中写明，虽然一般这个计划都是针对功能测试，但是如果有其他测试，也要写出来并安排时间，相应测试的相关计划等也需要指明
测试结束标志(要说明测试达到什么程度可以结束测试，不能等到把所有缺陷都找出来以后才结束，因为那将是一万年)，允许缺陷存留在系统里，我们只需要找到留多少这个度就够了

2、测试用例：这个文档，主要描述具体的测试步骤

但实际应用中，至少目前我的项目里，由于时间的原因，很少有写的，就算写了的，也基本没有用到测试里，在这边的很多项目大都是直接来测，全凭我个人的经验来检查。

但是我想说其实他很重要，也许你不需要写的很详细，但是绝对需要通过这样的步骤来理顺思路，这个文档的好坏和实用程度，直接可以决定你是否能“用最少的工作(量和时间)，尽早的发现尽可能多的缺陷”，写这个文档需要用到一些测试方法理论，如等价类划分、边界值、这个表那个表(汗。。。忘记了)

3、缺陷记录：是功能测试过程中使用频率最高的文档，用于在测试过程中记录发现的缺陷，并由开发人员作为修改缺陷的依据，以及修改后测试人员进行回测的主要依据

a) 该文当也有助于分析开发人员存在的“错误集群”现象，总结易出错的地方，对缺陷多的部分做更深入的测试，并提醒开发人员避免缺陷

b) 缺陷记录填写指南：

缺陷级别(即严重程度)，一般由公司统一定义，为发现的缺陷进行分类，以便决定修改的缓急
bug分类：区分发生的位置，是功能的，还是性能的，是有效性问题还是其他问题等，与bug级别一起，用于决定bug的修改要求度
bug状态：是标志bug的当前情况，标识是否被处置(关闭状态)
上述这些指标一般由公司统一定义(一般标准都大同小异)，也会用于项目的度量

c) 缺陷记录使用时的注意点：

描述bug要有三要素：在哪里，什么情况(前提)下，发生了什么样的问题
可以借助截图、引用位置、模块等方式来描述bug，目的是让开发人员能够通过您的描述立刻马上能够重现bug，即使不能重现，也能让开发人员了解到错误的所在
缺陷报告要由开发人员和测试人员共同完成，测试人员要督促开发人员填写该表以便测试后续的回测工作
如果是在执行用例的同时填写bug报告，用例的最后一列一般可以填写用例的执行结果，如果用例发生了非期望的结果，那么就要把问题记录在缺陷记录中，此时可以在缺陷记录中引用该用例的编号

4、测试总结报告：用于报告和总结项目测试工作的执行结果，列举和统计相关测试数据，对比分析数据即工作中存在的问题为后续工作做出提示，并记录遗留的问题等

总结报告的还有一个功能就是告诉项目组成员该系统已经按照测试计划的要求进行了测试，并已经达到测试计划中说明的“测试结束条件”，可以证明系统已经达到测试计划所期望的质量

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：