我对测试的思考

说起来人生第一家互联网公司，教会了我蛮多的东西，虽然比较杂。如运维、测试、实施、开发等。基本上那个时候，哪里有需要，哪里就有我。

之前曾写过这么一篇文章论单元测试之重要性
这篇文章的背景是我处于创业公司的时期，那个时候做的比较杂，由于前后端一起做，功能越来越多，bug也就越来越多。最后发现因为赶着发布周期，不得不快，快的我们连单元测试以及自测都懒得弄。最后发布前，经理测试了一下，发现了一堆bug。于是我们周末加班改bug。

持续了一段时间后，觉得老这样也不行，于是就开始写单元测试。还别说，因为写了单元测试后，bug率果然下降很多，bug率下降很多后，虽然也有一些bug，但并不是很重要，可以慢慢改。总而言之，我们不用周末来加班了，可以有一个美好的双休。

一、第一家公司专做测试的那段日子

之前我的领导是R哥，后来变成了D姐。D姐教我如何写测试用例。
根据测试用例，然后界面上进行操作，这样的测试通常叫功能性测试。
测试有很多种，功能测试是测试人员最基本的，也是最基础的。

测试分类如下:

• 黑盒测试——不是基于内部代码和设计的知识，而是基于需求和功能。

• 白盒测试——基于应用程序的内部逻辑的知识，通过语句，分支，路径和条件的覆盖率。

• 单元测试——测试中的最小单位，测试特殊的功能或代码模块。由于需要对内部代码和设计的详细知识，该测试一般由开发者完成而不是由测试人员完成。该测试的容易程度同代码设计的好坏直接相关。

• 增量型的集成测试——随着新功能的增加，不断的对应用程序进行测试。在程序的所有部分完成之前，需要一个应用程序的各个部分之间能够相对独立的进行工作。这类型测试可以有开发者或测试者完成

• 集成测试——测试应用程序结合的部分来确定它们的功能结合到一起是正确的。在这里‘部分’的概念可能是代码模块，独立的应用程序，在网络上的客户端和服务器断程序等等。这类型测试典型的是于客户/服务器和分布式系统相关。

• 功能测试——是一种黑盒测试，同应用程序的功能需求紧密相关。这类型测试应当有测试人员来完成。这并不意味着开发人员在发布版本之前就不需要检查他们的代码。

• 端到端测试——同系统测试类似，包括模拟现实世界对一个完整的应用环境进行测试。例如同数据库进行交互、使用网络通信，或者其他的软件、硬件和系统进行交互。

• 理智测试——这是一种典型的原始测试，其目的是要确定一个新的软件版本在一些主要的测试努力下表现的足够好并且可以接受。例如：如果一个新软件每五分钟宕机一次，使系统执行速度极其缓慢，或者破坏系统数据，那么该软件就处于不够‘理智’状态，必须保证在当前状态下进行进一步测试。

• 回归测试——在软件或环境被修改后进行的再测试。可能很难确定我们需要进行多少的再测试，尤其接近到开发过程的末期。自动测试工具可能会有很大的帮助。

• 可接受性测试——基于最终用户的规格进行的最后测试。或者基于最终用户在一定的时间范围内的测试。

• 负荷测试——在高负荷条件下进行的测试。

• 压力测试——该术语通常同负荷测试和性能测试是可交换的。也可用于描述这样一些测试如：在不正常的负荷状态下，过分的重复某些动作或输入情况下进行的系统功能测试。

• 性能测试——该术语通常同负荷测试和压力测试是可交换的。理想的性能测试是定义在需求文档或QA测试计划中的。

• 安装和反安装测试——测试完全、部分或升级的安装/反安装过程。

• 恢复测试——测试当出现崩溃，硬件错误或其他灾难性问题时，系统的表现情况。

• 安全性测试——测试系统对于内部和外部非法入侵、故意损坏时的表现情况。可能需要复杂的测试技术。

• 兼容性测试——测试系统在不同的平台/硬件/操作系统/网络上的表现情况。

• ALPHA测试——在开发进行结束的时候进行的测试。针对测试的结果可能还会进行一些小的设计更改。这类测试典型的是由用户进行的，而不是由开发者或测试人员进行的。

• BETA测试——在开发和测试已经全部结束后，并且在最终版本发布之前进行的测试。这类测试典型的是由用户进行的，而不是由开发者或测试人员进行的。

那段时期做过最多的还是功能性测试。

那段时期也比较苦恼，觉得功能性测试没有一点技术含量，有过辞职的念头，于是将自己的苦恼跟导师诉说。导师很快给我回复，虽然现在记不得很清楚他的原话，但内容大概是，测试并不是没有技术含量的，高级的测试是需要会写代码的，同时你觉得哪些是重复性、单调的工作你可以学习一些自动化工具来提高你的测试效率。

于是我才坚持下来做了一段时期的测试工作。功夫不负有心人，最终我还是成功转到了开发部门，开始写我喜爱的Code。

二、创业公司的那段测试时期

在创业公司做我们自己的产品，我在这篇文章较为详细的说过创业公司这两年

仔细想想，我们的产品类型分为如下:

• 物联网产品(既面向B端，又面向C端);
• 电商产品(既面向B端，又面向C端);
• 教育产品(既面向B端，又面向C端)。

我们公司组织结构除了研发就是产品，没有测试。所以我们研发人员无论是后端还是安卓端的，基本上都需要兼任测试职责。

就像我在前面说到的那样，前期我们不是很注重测试环节甚至过滤掉，导致我们不必要的加班改bug。后期我们形成了一套流程，周一到周四开发阶段，周五发版测试，如果没有问题，周五下班前直接发给经理，由经理再测试验证，随后再到老板那，如果有问题，问题比较严重，周五改不过来，那么我们就需要周六或周日来加班，

最初我们的测试也就是点点，但后来发现这样不行，因为点点仅仅是确认这个功能是否会报错如500等之类的，但并不能确保业务流程是对的。

于是我们改进了，写了几个业务流程的思维导图，然后测试，这样有针对性的测试，让我们测试就有了方向，不至于东点点西点点浪费不必要的时间。

三、教育SAAS公司的测试时期

教育SAAS有专门的测试人员和完善的测试机制。但是作为开发人员，我们部门明确一点要求，那就是每个人写的Java程序，必须要有对应的测试代码，以确保不必要的错误和代码质量。
每两周发版一次，分为开发周和测试周，开发周写本周产品提出的需求，每周周五开发周将终止，进行内部发版，发到测试环境，周一或者周五下午由测试人员进行冒烟测试。

大家或许对冒烟测试不太了解，其实我之前也不明白。

冒烟测试

1.冒烟测试是什么

针对每个版本或每次需求变更后，在正式测试前，对产品或系统的一次简单的验证性测试。

2.冒烟测试的目的

为正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug。

经过冒烟测试验证Ok没问题后，然后测试人员才会进行下一步测试如功能性测试。

经过这家公司的洗礼，我才发现测试人员还是要有很强的功底如必须对业务非常熟悉和非常细心和严谨，同时还得熟练掌握一些自动化测试工具如LoadRunner或Selenium等。

由于没待过流程体系较为完善的公司，我在这家公司做的第一个功能就出现了近一百多个bug。那个时候我既要写后端，也要写前端。后端bug二十来个，前端bug近一百个。看到禅道上给我指派的bug，我都快哭了。那个时候很想揍那位测试小哥哥。我刚来没多久，就对我这么不友好。想了想，先把bug改完再说。改完后，我逐渐意识到也不能怪那位测试小哥哥，毕竟是人家的职责所在。通过这次我发现自身存在很多问题，如代码写的不严谨、对一些细节不注重、不细心、对于功能差不多就好等缺点，于是后来我努力改进，虽然写的功能或多或少会有bug，但基本上控制在个位数上，改起来也不费劲，自那以后我和测试人员就处的很愉快，bug少，我轻松，他们也轻松。

四、总结

我所待的三家公司里，测试工作的经历告诉我一个很重要的道理:
无论研发、测试、运维或者是其他行业的工作，做到最后都在围绕一个人最重要的素养，那就是责任心，同样这个责任心也是做人最重要的品质之一。