在繁杂的手工测试中累积测试技术

悠悠小仙仙 · 发表于 2017-6-28 14:55:34

最近稍微得闲，就随便发篇帖吧，，感兴趣的看官就当看小说吧。

正文开始:

一、需求来源：

大部分测试，最开始从纯功能测试入门，做熟练后，容易陷入版本迭代和PK大战的汪洋中，以至于没有时间精力再去额外学习一些基础的测试技术（如某种编程语言、自动化测试工具），即使挤时间强迫自己学习，也不知道从哪里开始入手，很容易陷入人云亦云的尴尬，比如今年的趋势是安全测试，就去百度安全测试，明年是大数据自动化测试，就去百度大数据自动化测试。

“如何在繁琐的手工测试工作中慢慢积累自身技术”是测试同事普遍需要解决的一个问题。

二、前提条件：

1、对自己所在项目的业务流程、功能逻辑相当熟悉；

2、愿意牺牲一部分自己休息的时间；

3、骨子里是个想尽办法都要偷懒的人；

4、内心还是有学习新事物的愿望；

三、大致剧情（最近流行讲故事）：

Step1：

对于项目的业务流程（包括细节）和功能逻辑已经相当熟悉，慢慢发现在每次版本的测试过程中，设计案例/验证/提bug/与开发沟通只占40%~60%的时间。剩下的时间（甚至加班）用来干下列几件事情：

1、构造测试数据，尤其是复杂系统的测试数据既珍贵又难造（比如放贷产品里突然造一笔逾N期未触发代位追偿的数据），在开发BUG频出的情况下，测试造数据的工作量更是翻倍增长；

2、上游的流程因bug受阻，数据从上游过不来，等着开发改bug或手工模拟一个数据出来（大部分情况发现手工是很难模拟的，尤其是量级和复杂度较高的系统），时间一点一滴地在流失，但测试进度在原地踏步；

3、大量看似不相关又不知道真的是否相关的回归案例等着去执行，比如开发就动了一张配置表的某个基本信息，但按照理想测试情况，该信息涵盖到的功能是需要做最基本的冒烟测试的，全套跑下来，回归测试的时间占比高于非回归测试，但功能点就只改了那么一点点。

Step 2：

实在受不了step 1中的事情，开始思考是否有一些偷懒的方法，能把简单而又重复的事情快速完成。于是在休息之余对下面几个方向进行了探索（真正忙于测试和PK时，大部分人没时间想这些）：

1、现在每次造数据的大部分时间是手工操作前端将数据走至测试前的状态，或者手工增删改查+调用一堆存储过程使一条数据变为测试前状态。前端能否按照我的意思自己走流程快速造条数据呢？后台我每次敲一堆sql命令造出来的数据能否按照我的意思自己跑呢？

2、每次出现阻碍bug或开发优先级顺序倒置中前期测试时间浪费时，有没有办法避开这个坑？步骤是12345，每一步的数据能否准确模拟出来？

3、此问题看来貌似暂时无解，不去想了。

Step 3：

为了尝试step 2中的想法，开始做下面的事情：

1、前端是web还是app，如果要自动跑流程就要写点自动化脚本去让它跑起来，如果是web，百度/谷歌之后发现selenium貌似不错，那就用selenium来跑吧。几经折腾写好几个单page脚本，可以自动跑想要的流程了，但发现维护的成本似乎太高，每次改动一下数据自己就要打开这几个单page脚本改好几行代码。

2、开始想能不能进行简单地封装，我只需维护一张excel表格或一个配置文件，就能轻松更改几个脚本的数据源。又折腾了几天后，发现数据源基本不能复用，能否加一些处理脚本使每次自动产生一批可用却又不重复的数据，要做到这点就该去看看开发写的对应代码了。哎，好像不会，那就再抽点时间去网上学会基础编程吧，然后找关系好点的开发同事讲解下，把代码看懂了，拷贝下来，改成适合自己脚本的入参出参方式。啊！又发现语言不一样，能直接用python实现一个java里的功能吗？能，那就自己翻译，不能，那就自己去了解下python如何调用java代码吧。或者，每次跑完后，能自动执行一些写好的sql让这批数据回滚到最初状态，又要折腾两天充分了解这块业务对应了哪些表，这些表的关联关系、因果关系，还要花点时间实现脚本对数据库的无缝调用。

3、要模拟每一步产生的数据，最直接的是去把开发的代码拉下来看，然后把它改成自己最爽的入参出参模式，用了几天，发现这么做是能节约一些时间，可每次要避开一个步骤，就要手工调用一次mock的单脚本，那要不把几个mock脚本封装成一个独立的项目，倒腾几天后自己这边确实做到了一键式产生mock数据。

4、此处省略一万字；

故事到这里Stop:

其实各位看官可能已经明白了，工作中能从无到有，从少到多有效积累测试技术的过程是：
(1)做了一段时间手工测试--->
(2)对项目很熟悉（功能层面上）--->
(3)项目中出现很多浪费时间的鸡肋问题--->
(4)为了解决这些问题开始寻求并实施碎片化的解决方案--->
(5)在不断想偷懒的动力下持续优化第四步的过程中，渐渐学会了编程、数据库、基本网络协议、各类测试框架、自己根据需求设计改写测试框架。

从（1）到（5）后，其实身上的title已经不是那么重要了，就算平时工作只做手工测试也是一名视野开阔，思考有深度的加强版手工测试。这一切最初的驱动都来自于业务项目本身。这条路能不能走通，能走多远，完全取决于自己骨子里有多懒和是否愿意不停学习新事物。