最近项目进入了最后的阶段，离产品的发布越来越近了。这个阶段有一个特点：bug的数量相比之前的阶段要少很多，除非是非常严重的bug，否则开发人员不会对代码做改动。在这期间被defer的bug，会经过Dev和QA团队的共同review，有些bug会被推迟到下一个版本修掉，有些bug则会被“打入冷宫”，或许永远也不会被修掉。这个阶段测试人员的最主要的工作就是尽全力使保证产品达到最稳定的状态，针对所有的new feature及legacy feature来说。
挑选出一定数量的测试用例，使其覆盖所有的功能点，执行这样的测试用例，是这一阶段中常见的一种测试方式。在执行这些测试用例的过程中，我最大的感受就是“怀疑精神”。举个例子来说比如一个测试用例要验证5个小功能点，其中4个功能点都通过了验证，只有一个功能点没有通过验证。但是测试人员无法确定这个功能点没通过验证是由于自己对测试用例理解的偏差或者是由于测试用例太过陈旧，不适用于当前的功能点，又或者这真的是一个bug。如果这时候测试人员恰巧发现这个测试用例的历史记录中执行结果都是Pass，那么他很可能也将这个测试用例标为Pass。在这种情况下，如果测试人员能够坚持一下自己的怀疑精神，多做一些假设和验证，或者和其他测试人员讨论一下这个测试用例，或者向Dev进行求证，那么测试人员很可能会揪出一个不错的bug。
测试人员根据自己的经验和测试风格进行探索式测试，是这一阶段另一种测试方式。前几天向组里面一位经验丰富的测试人员求教他是如何发现一个很不错的bug的时候，发现他在一个“不起眼”的场景下提出一个假设，然后进行验证，接着根据结果修正先前的假设，然后再进一步验证，如此循环往复，最终发现了这个不错的bug。其实他的测试方式就是当下很流行的探索式测试（exploratory testing）。探索式测试和Ad-hoc testing有些象，但是探索式测试是一个不断进行反思和优化的过程。Ad-hoc testing则没那么重视测试计划和设计。个人觉得探索式测试只是一种测试方式，具体如何实施取决于测试人员的测试风格、经验、以及对于产品的理解。
最后扯一些题外话，今晚和大学同学一块吃饭，席间聊到了他当初是如何放弃一份优越的工作选择去国外读书的种种。对于他的这段经历，我最大的感受就是“冷暖自知”四个字。一份在外人看来如何光纤如何体面的工作，都有它不为人知的一面，这一点只有身处其中的人才能体会。这也让我联想到了今年春节期间家人询问我工作是否顺心，并一再强调无论钱多钱少，开心最重要。
