在我们的测试工作中，除了需要不断的学习新知识外，还有一个可能常常被我们忽视的工作，那就是反思。
反思的重要性不言而喻，可以帮助我们总结过往的经验教训，可以帮助我们重新复盘过去工作中的得失，可以让我们通过曾经犯下的错误找到未来需要规避的问题，可以通过积累的经验获取后续工作中更高效的方法。
那么问题来了，做测试的我们，该反思什么呢？
在我们团队的日常工作中，每隔一段时间我们就会组织召开一次学习总结会。在这个会上，我们会去回顾过去一段时间工作中大家遇到的问题、学到的新知识、沉淀的经验和方法。在这个过程中，大家互相交流，互相碰撞，互相提问，互相弥补。通过这样的讨论学习，每个人都能感受到这些碰撞出的火花带来的提升。
所以在这里，我以经典BUG和重点需求两个方面，简单梳理下我们在交流碰撞中的一些思路和方法，供大家参考，特别是给进入测试不久的同学们一些思路，帮助大家在以后的工作中找到自我提升的方法。
经典BUG
作为测试，提bug是我们做的最多的工作。那么，我们是否每隔一段时间就会去总结沉淀下自己过往提的bug带给我们的知识呢？
在我们的测试过程中，我们每次提交bug时，都可以去思考下这个bug带给我们的东西，比如，这是个什么类型的bug？是文案错误，还是交互问题？是逻辑设计问题，还是兼容性问题……这个bug产生的原因是什么呢？是开发工程师粗心大意了，还是对某一个逻辑分支没考虑充分？发现这个bug的用例是否足够完整，有没有遗漏？对类似用例是否有考虑到这些情况？是否对其他分支覆盖完整了？如此，等等。这是我们提交每一个bug时都需要考虑的。
然而，这就足够了吗？我觉得还不够。对一般性问题，这样的思考也许是够的，但总有一些可以带给我们更多思考和启发的，就需要我们不定期的进行回溯总结，复盘这些问题带给我们更深层次的东西。这也是我们团队在每次学习总结会上交流的内容。
在交流过程中，对于每个拿出来分享的bug，我们都会向大家介绍下面几个问题：
这是个什么需求？和这个bug有关的需求点是什么？
bug的描述是怎样的？是否描述清楚了其中产生的原因和过程？是否能让开发看到后立刻明白如何重现这个bug？
这个需求点的技术实现是怎样的？背后的逻辑是怎样的？
这个bug产生的原因是什么？
这个需求点背后还有哪些异常？我们的用例都考虑到了吗？
同类型的需求点是否有类似问题？我们是怎样设计这些需求点的用例的？
这个bug带给了我们哪些测试方法？带给了我们哪些更深层次的方法论？
只有把这些问题都说清楚，才是一个经典bug带给我们的完整思考，这样的分享才有意义，也才能给我们的需求测试能力带来更多进步和提升。
重点需求
测试需求的过程中，还有一个内容是值得我们去反思和沉淀的，那就是有代表性的需求。这些需求，或者是技术实现上有代表性，或者是业务逻辑上有值得沉淀的内容，或者是在测试过程中使用的测试方法有需要总结的地方。对于这类需求，我们称之为「重点需求」。
对于重点需求，也是需要我们在测试结束后需要去进行一番总结的，总结这个需求带给我们的思考。
关于需求总结，我们也有一套可以分享的问题：
这是个怎样的需求？
这个需求的实现原理是怎样的？背后的技术架构是怎样的？它与其他模块之间的调用关系是怎样的？
我们的用例设计思路是怎样的？有什么以往需求不同的地方？
对这个需求的测试，需要用到什么辅助工具？这个工具的实现原理是怎样的？
过往的需求中，是否有类似的需求？这些需求相似和不同点是什么？
这个需求有哪些异常场景或特殊情况需要考虑？为什么会有这样的特殊点？
这个需求的测试能给我们沉淀哪些知识点？能给我们带来哪些新的方法论？
需求在经过这样不断深挖后，我们对这个需求的理解就会上一个台阶，也会在测试用例设计和回顾中有更好的补充和完善。
小结
这里仅是从经典BUG和重点需求两个点上去举例说明我们对自己日常工作中反思的方法和思路。
其实，在日常工作和学习中，还有很多方面需要我们去不断的思考、积累和总结，只有不断的向下深挖一尺，多思考三五步，我们才能更好的掌握自己所经手的每一个东西——需求、工具、方法……
只有对自己使用过的东西都有足够且充分的了解，我们才可以在工作中更进一步，才能在自己的能力提升上更快、更有效。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
