由运维转软件测试的初体验

严格来说，我也不是真正的运维，是所谓的甲方。但是我的工作有一部分是运维的性质，包括机房、桌面、网站的运维。我理解的运维，不管运维的主体是什么，都是在它们日常工作的过程中对它们进行日常的检查、修理，在遇到故障或者用户有需要变更（如新增业务、删减账户之类）进行处理。

在从甲方转为测试的时候，我也做了一些思考。测试是对产品的质量做一系列的检验，软件测试也是一样，只不过对象变成了软件。软件是由代码构成的虚拟产品，从产生方式要使用场景等可能会区别于其他种类。测试看起来是一个门槛比较低的岗位，并且看起来好像没有开发那么重要，难度也没有那么大。

转测试岗到现在才两个月不到，对产品的功能、定位都还在一个逐步熟悉的阶段，但是我也有了在这个阶段的一些感悟。

首先，针对功能测试。功能测试是对产品对是否达到预期的功能进行检验。一般而言就是对照需求进行测试。功能测试的主要手段就是覆盖技术，数据覆盖，流程覆盖。做覆盖的时候，当然是越细致越好。我经常在使用一些产品（不管软硬件还是其他领域的）的时候有不好的体验，比如最近遇到一件事，在使用出租房里的洗衣机时有几次出现洗衣机不转或者衣服甩不干的情况，本以为是洗衣机坏了，打电话找售后，售后人员也没有来，就说了一下看是不是衣服放少了。回来塞了满满一桶之后果然没出现问题。售后人员可能也是遇到了太多类似的问题，所以不用看就知道原因。推演一下洗衣机的设计和测试思路，8KG的洗衣机，是给洗衣机的洗衣量做了重量上限。测试的时候可能只测8kg的衣物，或者7~8公斤的衣物，结果是正常的，就给通过了。完全没有考虑0.1kg到8kg整个重量区间的功能是否正常。所以，在做功能测试的时候，应该尽可能地考虑可能出现的场景，替开发和设计多考虑一些，考虑更加全面一些。

其次，针对安全测试。按理说安全测试跟功能测试是两个分支。但是对于软件产品来说，在这样一个数据就是资产的时代，忽略安全的产品可以说几乎没有什么存在的意义。安全测试设计相较于功能测试来说，对工具的掌握会变得更加重要，尤其对安全隐患产生的原因也要了解得更多，安全隐患大多是经验积累下来的。比如说密码学，新发明一种密码算法并不容易。比如漏洞管理，都是对现有发现的漏洞进行积累。相较而言，思维的训练可能没有那么重要。

这只是最初接触测试这行的一些粗浅的感悟。因为我现在测试的产品的面向客户是运维人员，所以我的一些运维工作经验以及运维思路对现在的测试是有帮助的。