对于程序，就像人生！它有生命的起点-经历-稳定-结束
【一】
作为测试人员到底应该做些什么？曾经和团队成员一起讨论这个问题，也在网上搜索过一些，就会有一堆答案出现：
1.应该测试(想像级别)
2.应该做到完全测试(理想级别)
3.应该做到 0 BUG(完美级别)
4.了解测试的应用程序(创新级别)
5.试图破坏测试的应用程序(破坏级别)
……
以上这些都没问题，但让一个测试人员成为”一个好的测试人员“的品质跳跃，那就需要：每双眼睛里都要有这样的疑问，那就是“用什么方法”？“怎么做”?“为什么要这样做”？
保持怀疑一切的心，对待每个程序项目！
【二】
so,当你报告一个程序问题时会发生什么？通常有如下结果:
1.开发人员去解决它(bug已让开发服了)
2.不去管它(项目组无人重视)
3.延迟修复这个问题(不想马上处理)
4.问题被标记为”不可再现“(这是个有故事的bug)
5.设计如此(沟通已经出问题了，测试竟然不知道)
……
那么问题来了，开发人员为什么不解决这个问题，为何需要延迟修复、或是将问题标记为”不可重现“呢？，还有设计如此的情况！ok，以下摘录一些关于比较有意思的测试缺陷内容：
作为一个测试人员，我们的主要职责是测试应用程序或产品并且提BUG。但是我们的责任并没有在这里就结束了，实际上， 真正的任务从这里才开始。你是怎么去理解和应对你的那些被拒绝或者被置为”不可再现“ 的BUG，这一点是非常重要的。
BUG的提问与跟踪是一门艺术，一门通过运用一些要点，来自下而上的改变产品质量并赢得客户信任的艺术。在软件测试领域内，不管你身处什么职位，掌握BUG提问的技能是有必要的。BUG记录不只是一个文档，还是关于：什么错了，怎么错了，哪里错了的总结报告。BUG记录中包含了关于应用程序不足之处的信息，你怎么去呈现它，对于决定这个BUG的未来，是至关重要的。
或许很多人都有阅读了相关一些关于BUG应该包含哪些信息和哪些领域。但整体的缺陷记录呢？即使在包括每个必要的领域之后，你也可能无法创建一个好的缺陷报告。
【三】
so，以个人经验来说，提BUG就是个人的修养，怎么让开发能快速读懂问题，这就是缺陷报告重要一环。如何定位bug，并证明所提的bug，就是bug。在此列举一些关于在报告中提BUG的时候需要注意的点。也是为了让它更容易理解：
例：
以电商平台网站为例，(较为熟悉的项目)，列举出以下几点，怎么突出明确的意思
☞1.阅读自己写在报告的BUG，并问问自己能理解吗？
☞2.为了能节省时间和精力，需要提供更接近的重现步骤
☞3.明确BUG是一个项目的问题，而不是测试人员的个人问题
☞4.一条缺陷记录只描述一个问题
☞5.尽可能多地提供出一些可能造成问题的原因
【END】
学习是主动的，被动就没意思了。过程遇到坑填平了，经验总结下来就是最好的成长！
如果你对测试方面有更好的技术、想法和看法，我们可以一起聊聊。如何改善自己，提升做事效率，个人责任感……
欢迎来撩，但别撩我 ^ _ ^ --by 王子
文章仅供参考，请勿转载。
