软件测试基础丨测试工程师之间要善于发现闪光点——测试理念篇

软件测试基础丨测试工程师之间要善于发现闪光点——测试理念篇

　　古风建筑照片,建材询价网,建筑工程信息价查询测试理念有多种，有一些理念，深藏于我的心中， 而这些理念，您或许偶尔想到，却没有说出，或许您感受到了，却因为工作生活的忙碌，没有将其背后的含义想具体， 在此我非常愿意和大家进行分享这些理念。

　　事实上，测试的过程也是人生的一部分，我们是在一个测试团体中进行测试的，就算只有一个测试工程师，那个测试工程师也可以作为一个测试部门的一份子，他（她）具有一切测试部门所必备的特性。

　　对于软件，我们可以把它当成一个机器，一个冷冰冰的机器，但是对于其他测试工程师，我们需要认清他（她），是一个人，一个地地道道的人，而不是机器。

　　我们绝对不能忽视我们之间的相互扶持，测试人员之间的相互扶持和鼓励是及其重要的。

　　是人就会有情感，他（她）之所以会在测试部门进行测试，那是因为爱测试，这份爱，支持着他（她）对于软件，对于测试部门，对于开发部门的一切活动的关注，那份坚持和执着，是需要每一个人的理解和支持的。

　　爱的付出需要有回报，测试工程师之间发现彼此的闪光点，是每一个测试工程师的首要职责。

　　测试人员之间的话应该是最多的，讨论bug的看法，讨论需求的理解，讨论测试用例的写法，讨论测试的形式，讨论测试的进度任务安排。我们互相之间会形成正确的认识，形成测试的互补。

　　每天的讨论开始于每天早上的早会，早会是将大家准备做的任务陈述一下，时间是十分钟左右。确认任务都分配完整。同时也说明一下昨天测试遇到的困难，看是否有什么方法进行解决。而接下来的讨论，则在于对于在测试过程中的一些讨论。

　　这种讨论的价值是很大的，除了要注重讨论之外，也要注重时刻鼓励对方，比如说：你这次做的真的很不错！，非常感谢，我理解了。

　　犯错是很正常的事情，首先我们要知道每个人都是会犯错的，这种原谅他们所犯的错的心态，是极其珍贵的。如果测试工程师少发现一个bug，是很正常的；如果测试工程师说错一句话也是很正常的，快速理解和纠正，会带来很多的好处，这种好处就在于，这种快速的理解和纠正，就可以以最快的速度改善软件的质量，同时也不会使得其他测试工程师丧失信心，有助于他（她）日后的测试热情保持高涨。

　　其次，这有助于对于犯错的特点一清二楚。一个测试工程师容易犯的错误，往往是，其他测试工程师也很容易犯，避免其他测试工程师犯同类错误，对于测试团体的集体质量提升带来很大的益处，大家能一起共同成长。

　　如果一个测试工程师分享他(她)的测试经验，其他测试工程师应该以一种欣赏的态度去面对，而不是运用一种非常嫉妒的方式去面对，那么就能大大提高测试团队的信心。

　　不仅仅是在其他测试工程师主动分享的时候，值得欣赏，在平时的工作中，互相的交流，测试用例的互相学习，都可以作为欣赏。偶尔的说错一句话，写错一句话，全部忽略不计，只有呈现的最终大家都满意的测试文档，才值得学习和欣赏。

　　测试工程师之间的关系就如同食物链一般，任何一个人的缺失，事实上是缺失了一个食物链的一环，再招聘进来一个测试工程师，必定是不同的，需要很长一段时间的适应期，才可以重新构建一个完整的食物链。

　　并不是说新来的一个测试工程师不熟悉这个软件，而是，每个人的测试风格不同，使得其他测试工程师依赖于某个测试工程师的风格，而早已形成了某种互补的形式，一旦要寻求一个相似的测试工程师，那就是一件比较困难的事情。

　　而这个适应期不会很长，因为只要大家互相理解和包容，就会很快的成为一体。当一个完整的食物链构建好之后，通过测试人员的分工合作，就可以将任务完成到极致和最佳状态。

　　在某些单位，每一个测试工程师负责一个模块，这种做法，其实并不可取，因为这样，这个模块的形式往往会只在某个人的掌握之中，软件的优劣程度，就会产生一个定势，而当这个测试工程师离职之后，再次找一个人替代他（她），就又需要从零开始。

　　这段时间将会是一段非常困难的时期。当这个测试工程师有事请假的时候，其他的测试工程师不能很好的代替他。

　　而当这个专属的测试工程师在工作的时候，他（她）仿佛在说，“我是不可替代的”，这种气势会有压倒一切的感觉，也会给研发部门带来负能量。

　　当这个测试工程师正在测试的时候，他的信息是封闭的，他很难感知到其他测试工程师的气息，他们的动态，他们的思维，而他的想法也无法传达给别人。在封闭的情况之下进行测试，然后还用着“我是不可替代的”气势，仿佛在让别人在惧怕他（她）。

　　而于此相反的测试组仿佛在说，我们是温暖团结，联系紧密的一组测试团队，高矮胖瘦都会有，我们会给软件带来全面准确的分析和测试。

　　假如一个单位有3个项目需要测试，有2个测试工程师，可以采取这个方法，对于每次的新版本，这两个测试工程师轮流负责，项目1的a版本，给测试1，项目1的b版本，给测试2；项目2的a版本，给测试2，项目2的b版本，给测试1；项目3的a版本，给测试2，项目3的b版本，给测试1，以此类推.

　　测试用例采用每个测试工程师各自写各自的测试用例的方式来进行，对于某些必要测试用例，也就是说每次的版本都执行的测试用例，可以放置在同一的地方，方便大家更新和补充。

　　测试的过程中，每个测试人员需要首先，互相沟通，然后在没有结果的情况下，再去问开发，这样不但增进了测试人员之间的友情互动，而且还能尽可能少的麻烦开发，而开发对于测试的询问也应该及时响应。

　　在描写测试用例的时候，尽可能全面而细致，寻找最为恰当的语言来描述测试用例，测试完毕之后，写上测试总结和体会，同样也用最为细腻的语言写出来，让人仿佛能身临其境。同时，也方便进行回顾和分析，这对于日后改善软件的质量是很有帮助的。

　　软件测试是一个长期的工作，对于同一个软件，今天测试的体会和明天测试的体会都会有不同，如果都能写上，那必定是一笔宝贵的财富，也许一年后，翻看以前之前我们写的测试报告，我们会发现自己的进步，会发现自己对于软件的了解更加的深入了，发现自己的测试范围扩大了，眼界更广了。 对于刚开始测试某个软件的测试工程师，需要一点一滴的积累对于软件的理解和认识。将它们写进测试用例，写进测试报告。平时，可以看一些简.奥斯丁的书，因为这位伟大的作家写的书最大的特点就是描写细腻准确，刻画心里活动细致入微。很适合用作测试用例以及测试报告的写作。我认为我写的测试用例和测试报告还并不完美，用词还需更恰当，测试技法还需更丰富。而我的追求，就是能在日后写的越来越接近完美，我认为，测试用例和测试报告，应该力求达到，语句通顺自然，带有文学气息，细致入微，感情丰富细腻，让人能阅读了之后能感知到这个软件给人带来的最真实的体验。

　　这种真实体现在，对于测试用例的执行结果的真实准确，和对于测试分析的真实准确，如果说测试分析的真实准确需要文学的刻画，那么测试测试用例的执行结果的真实准确，是需要拥有耐心和细心的态度，将每个结果标注 pass 或者 fail。不能有随意性，不能有为了完成任务而进行标注的随意性。除了 pass 以及 fail，还可以有其他状态，用于特殊情况的标注，在 pass 和 fail 边上，最好能标注上原因和体会。

　　除此之外，这种真实性还体现在，测试工程师之间彼此沟通的真实性，及时性；和开发之间沟通的真实性，及时性，有任何信号都可以和开发进行沟通，不必拖拉。

　　我比较赞成自己执行自己的测试用例，因为对于自己的测试用例，自己是最为熟悉的。而且，由于自己对于软件有过一定的认识，才写出了测试用例，因此自己的执行效率是最高的。

　　执行别人的测试用例之前我也总是需要花费时间去研究一下软件，事实证明，一个对于软件有更加深入了解的测试工程师，在执行测试用例的时候，体会才是更为深刻的。而这种花时间研究软件的过程，会被某些同行认为你在浪费时间。如果真的是这样的情况出现，我想应该责怪的是他们而不是你，因为他们不了解你，他们也不了解测试。

　　当这个测试组的成员还和我完全不熟悉的时候，又或许当我遇到一个随意编写测试用例的同事，会让我在执行测试用例的时候，有一种屈辱感。

　　但是由于善良的本质，会让我出于善心和责任心，加班再晚，都将测试用例一一执行完毕，并在边上标注上自己的意见和建议。我知道为此我倾注了许多情感！

　　但是当我和别的同事之间产生的深厚的友谊，并且大家彼此之间都非常熟悉这个软件的时候，我想我执行别的同事的测试用例，就是另外一种感觉了。温暖，甜蜜，幸福，思维的碰撞，热情的燃烧都会接踵而来。

　　测试工作会占据我许多的时间和精力，在工作之余如果能再学习一些统计学的知识，一些数学知识，将对于软件测试带来更多益处。您是否认为用以上这种测试方法，就能感受到测试组的同事们对测试的那份执着，是否也感受到一股正能量呢？

　　最后：在我的V ：atstudy-js，可以免费领取一份10G软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。