我两年多的测试生涯到头了。我想再这里总结一下点点滴滴。以及我也会说明我为什么选择离开。在中国有着很多很多的软件测试，很多迫于环境，迫于 leader，迫于很多原因，导致只是一个“执行者”。以下只是我个人的一些经历。大家可以借鉴，也可吐槽，大家随意。

首先在测试的时候需要有一些心理暗示，其实未必是暗示，可能是给自己的一些自信。

第一：产品一定是有 bug 的。

无论你测试什么产品，一定是需要报有这样的心态。为什么？其实就如一句说的“如果自己都不爱自己，那么就不要奢望别人来爱你”。如果连测试潜意识里面都觉得产品是没有 bug 的那么还能有谁认为产品是有 bug 的呢？

测试的历史上有两种验证方法，一种是测试是用来验证产品一定是没有 bug 的，一种是测试是用来验证产品是有 bug 的。无论哪种你都要有一种原则，要有一种信念。就如人生漫漫长路一样，我们必须坚信自己的梦想，坚信自己是能够成功的。那么才有可能，才有希望。当碰见挫折的时候，当迷茫的时候，才不会真的被打败。

一个新的 feature，一个刚刚 fix 的 bug，一个用户反馈，一个不起眼的问题。我们都需要坚信里面有缺陷的。没有任何一个产品，任何一个细节是完美的。

许多公司从上级到下属对于产品的质量根本没有概念，又或者对于质量不重视。在这种情况下，就需要测试产生力量，需要用各种事实依据去告诉公司，告诉大家这样一个产品质量的真想。国外的公司相对好点，国内有很多公司是需要有这种有责任感的测试存在。

第二，任何的 bug 都是能够 repro 的

无论你面对一个很小的功能测试，还是很复杂的场景化的测试，又或者说某个用户很简单明了的描述了一个问题。我们需要坚定不移的告诉自己，只要是一个 bug 就是有重现步骤的。

微软曾经有测试，一个问题的重现步骤长达 50 步。虽然可能不是最佳的步骤，但是依然对于解决问题起到了决定性的作用。

自然，在实际中很多情况下的确会碰见一下子找不到重现步骤的方法。找不到方法意味着什么？意味着你可以开 bug，dev 可以 fix 这个 bug。但是谁都不知道到底有没有真的修复这个问题。还可能因此出现很多 regression 的 bug。所以找到一个 bug 的 repro step 可以说是一个测试基本功也是体现价值的地方。

和第一点一样，只有你自己信念中去相信了，那么你才有可能成功。

第三，只相信自己看到的

在很多情况下，dev 或者同事会告诉测试“这个功能很小，没有 bug 的”“简单测一下就好啦”等等的话。我主张还是不要太相信任何一个人。

面对 bug，我们需要好好的理清问题的根源逻辑，在进行一个完全的测试之后告诉自己“这个功能基本上不会有很大，或者很 block 用户的问题”；面对一个讨论，不要听到别人说什么就是什么，任何的决定都没有完全正确的。我们需要自己亲手去验证很多决定和设计，小到你可以 google，找出各种证据来证明某些事情。大到你可以进行用户数据搜集，很多企业不会去做。但是如果一个有 sense 的测试，我相信必须什么事情都亲手去实践去证明！

以上说了这么多，可能很多人觉得，这个还是测试么？ok，我认为真正的一个测试满足以上三点是远远不够的。以下是我认为一个有 sense 的测试，记住是有 sense 的测试需要做到的。

第一：探知精神乐于学习

为什么我将这两个放在一起呢。两者密不可分。我所在公司是做 android 产品的。目前中国国内很多企业也是一样的问题，就是只是在乎自己的产品怎么样，并不会很关心你的发展。作为测试，必须有探知精神，必须乐于学习。比如你测试A平台的B产品，如果只是一味的测试，只是一味的报 bug。的确你会有进步，做任何一行你都会有进步，行行都能够出状元。但是几年光阴一过去，当别人或者自己问问自己，自己真的知道了多少？可能对于自己公司做的产品很了解之外，一无所知。那么这样对于自身发展又有什么好处呢？

探知，对于任何一个 design，任何一个 bug，任何一个细节都需要去探知。这样无论你做了多久，无论你是否做多少个项目都会依然有进步。时不时的问问自己，对于这个产品 feature 真的了解很透彻么？对于产品功能逻辑很清楚么？对于这个产品所在平台了解么？业内是不是主流的 tools 都清楚了呢？是不是自己已经没有了进步的余地了。这样自己会明了很多。

第二：责任

这点可能很多人会说，测试最基本的不就是责任么？没有责任怎么去做一个测试呢？是的，责任每个人都有，程度是不同的。你作为一个 tester，需要保证产品的质量。勿以 bug 小而不重视，本质上依然是不负责任的表现。

相反的，很多测试对于产品是负责了，对于自己却是不负责任的。因为他们只是一个傀儡，天天被人操控着。做这个做那个，我觉得这种是更加可悲的。

如果你作为一个 tester leader，那么你的责任不是去指挥别人做事情，不是去拍老板马屁。而是自己不要忘记进一步的学习，不要忘记对于任何的细节去了解。更不要忘记如果出了什么问题，自己勇于承担这个责任。真正的 leader 是什么？需要在流程以及技术上面有自己的 sense，需要不停的去完善项目流程，从而提高测试 team 的效率以及项目的效率。

第三：通过各种渠道找到 bug repro step

bug 会从各个渠道发现。公司内部 bug bash 的时候，用户反馈的问题，自己找到的问题。老板发现的问题等等。这个时候能否找到 repro step 就是体现一个测试的价值所在了。

测试往往碰见的问题是这样的。突然发现一个问题，欣喜若狂！但是然后问问自己“我刚刚做了什么”，基本上很多人都不知道。有的时候是有 log 可以取，但是 log 只是一个告诉开发如何 dev 去解决 bug 的。所以找出重现步骤才是王道。并非要时时刻刻保持警惕，可以有两个做法，一个就是自己在测试的时候留个心眼，养成时不时回忆自己做了哪些操作。一个就是养成一边测试一边记录 log 的方法，这个方法相对很保险，不过前提是自己需要有完全看得懂 log 的能力。

另外一类 bug 是从用户这里报出。用户一般是无知的，根本不会懂你产品的逻辑，可能描述出来的错误和真正的错误根本就是天差地别。这个时候就需要测试去按照经验以及各种方法去判断。判断出用户说的产品的真正的问题在哪里，然后使用各种方法（automation.etc）去模拟 bug 产生的环境。这样一来，bug 在修复的情况下能够在公司内部马上得到 confirm。这样无论是对于产品，用户，还是公司都是一种无限大的利益。

还有一类 bug 是公司同事报出的，或者是老板提出的。一般都是一句话“这里有个很大的 bug”。木有任何细节，木有任何解释。

当然，总结一下来讲，一个测试就如同一个侦探，慢慢的寻找蛛丝马迹，慢慢的看到真相。能够找到这条路的人那么必然是一个有价值的测试。毋庸置疑。

第四：bug 定义 sense

bug 到底是什么？是一种缺陷么？是的。那么测试产品 bug 这个行为是什么？我相信很多书本上面都没有定义过。

测试产品 bug 行为定义：是寻找产生 bug 过程的一种行为，是缩短人们用产品开始到产品发生 bug 的周期的一种行为。

所谓找出 bug，无非是一系列的操作序列造成了程序的缺陷或者崩溃。序列可能是几步，时间周期也可能是一年两年十年。那么测试产品 bug 不就是要在项目周期内尽量多的去寻找问题么？所以，其实本质就是，如果一个用户用一个产品十天才出现的一个 bug，那么测试就需要压缩这种时间，将其在很短的测试周期内发现这个缺陷。

方法有很多，模拟环境，使用各种已经有的 tools，使用各种 automation 进行测试，甚至自己写用户的一个环境等等。缩短用户发现 bug 的周期其实就是一种战斗，一场无止尽的斗争！

第五：UE

UE，用户体验。很多人会说用户体验是 UI team 以及 UE team 的人需要了解的。但是往往这个 sense 对于测试是最最最为重要的。

所谓最高级的 bug，最有价值的 bug 就是贴近用户的使用习惯。但是如果一个测试没有 UE，那么你如何模拟用户操作？你用户是使用 windows 的，是用 mac 的，是用 android 的，是用 dvd 机的等等，而你一个都没有用过，你何以测试？你何以找到用户真正 care 的 bug？根本就是无稽之谈。

UE 的学习对于谁都是有利的，无论你是做什么产品的，你是什么职位上面的。UE 的学习是永无止境的。没有 UE 的测试只是 monkey test 罢了

第六也是最后一点：勇敢的去做

和第一点不同的是，测试这个职业在国内还是一个比较新的职业。很多测试本身都不知道测试到底是干什么的。更加不要说一些互联网产品的测试。很多领域根本就是没有被开发过。你要做的就是勇敢的去尝试。可能有一个 point，开始你的潜意识就觉得 level 太高，根本就是做不到的。但是你要去试试，不试试怎么知道不可能，勇于去做第一人。可能你做的事情就是别人没有做过的呢？要记住！你不去做总有人去做。我相信大家都希望自己成为第一人，而不是跟着别人的脚步再踏步踏。

目前只是想到这些，原本是想写工作回忆录的，却写成了这样一篇东西。真的惭愧。要不要写回忆录呢！纠结！！

来源：豆瓣