谈测试人员的几种个人能力

最新推荐文章于 2024-04-05 21:50:36 发布

星河绛橘色的日落

最新推荐文章于 2024-04-05 21:50:36 发布

阅读量242

点赞数 1

分类专栏：自动化测试工具性能测试软件测试文章标签： java 开发语言 python 运维 android

本文链接：https://blog.csdn.net/dj355/article/details/132274599

版权

自动化测试工具同时被 3 个专栏收录

226 篇文章 4 订阅

订阅专栏

软件测试

192 篇文章 1 订阅

订阅专栏

性能测试

148 篇文章 1 订阅

订阅专栏

前言：

测试人员是软件开发过程中非常重要的一环，他们的工作是确保软件的质量和稳定性。

我认为，测试人员应该具备三种基本能力：测试思维、测试技能、测试方法。（这里不谈沟通能力、组织能力等软技能）

一、测试思维

测试思维，是一种特质，就好象小说里写的火属性体质或者水属性体质一样。是测试人员看待一个事物的角度，思考一个问题的角度，解决一个问题的思路。

不管你是做开发还是测试，当你暂时处于” 测试 “这个角色时，你就必须转换你的思维模式，进入测试思维。

比如逆向思维、比如永远怀疑、比如推翻假设、比如用户思维、比如追求完美。。。

这里可以列很多很多，但是重点在于，做测试这个角色时，所需要的思维方式，是和做开发是不一样的。一个好的开发人员，不一定是一个好的测试人员。

遗憾的是，很少有书籍可以告诉我们，如何去训练、培育这种思维模式。很多人都是天生的。

这里我可以举一个比较极端的真实例子，我以前的一位同事，在和开发一起做敏捷的时候，非常努力愉快的和开发一起解决了各种难题，然后成功的让软件运行起来了，各个流程都能跑通了。但是他来给我汇报测试工作已经完成的时候，我给领导说，这个同事不适合做测试，后来让他转了开发（后来成为了一名很成功的开发）。
因为对测试来说，软件可以正常运行，仅仅是一个开始，开发要做的是努力完成它，我们要做的是努力打倒它，直到我们无法打到它为止。如果你根本就没有这种想法，或者光有想法，完全不知道如何去做，那么就必须想办法学习了。

二、测试技能

测试技能主要指对测试工具的掌握、对测试技术的掌握，这里同样也包括编码能力的掌握。我并没有把编程能力单独拿出来说，因为我觉得编程能力只是技能的一种。

一句话来说，为了能更快、更好的完成你的测试目的，你需要使用工具，这些工具包括像 Jmeter、RF、Rest Assured、Jenkins、Appium、TestNG、WebDriver、Nmap、Excel（是的，我确实写了 excel）等等等等，你还必须会编码，比如写 java、写 C#、写 python、写 Go、写 JS。。。

现在很多老一辈的测试人员，会在测试技术上比较落后，因为各种原因，比如编码能力薄弱，比如没有及时跟进新的技术，抱残守缺，比如踏入管理岗位后丢弃了技术，比如学会了混日子再也没有了激情。

如果一直这样下去，被淘汰是必然的。

我个人认为，一名合格的测试人员，最少必须要掌握所在公司开发所使用的主要语言，然后再加一门脚本语言，再加一门前端语言。你不光要能写代码，你还要能写界面，这样才能向项目组展示你的成果。

在我看来，测试最终会有两个分支：业务测试专家和专项测试专家。

前者是在某一行业具备了相当的背景后，特别擅长测试某一类产品，比如金融软件测试专家、比如医疗软件测试专家。
后者是特别擅长测试产品的某一项特征，比如性能测试专家、安全测试专家。

不管如何发展，必然是需要各种测试技能的。当别人都在用导弹、飞机了，还拿着菜刀必然要被时代淘汰。

三、测试方法

测试方法不是测试理论，但是会包括一部分测试理论。

现在你有思维了，也掌握了技术了，如何利用好你掌握的技术去进行测试，这种方法论就是测试方法。

如果说测试技术是绝世宝剑，那么测试方法就是招式，或者说如何去更好的使用宝剑。

同样的一把刀，拿在庖丁的手里，和拿在我的手里，效果是完全不一样的。

有很多业界的前辈，其中特别是我最喜欢的 James Bach、James Whittaker、Martin Fowler 等人，努力的把自己的一些经验，转化为一种模式。我觉得这些测试方法，就应该对应开发的设计模式、软件研发方法。我特别喜欢《软件测试经验与教训》、《Google 软件测试之道》、《软件测试的艺术》等书。
有人说这些很多都是手工测试的书，这里我想声明一下，书里是讲如何去测试，但是没有规定你一定就要手工去做啊，你可以打车去，也可以坐轻轨去，你可以尽量的使用你所会的各种技术，如果没有合适的技术，你还可以学习。

测试方法其实也可以是非常简单、落地的。
举例说接口测试吧，现在接口测试的基本代码已经写好了，你有了一种很犀利的工具，可以去做业务测试无法做的事情，这是一把尖刀，非常锋利。
至少，你要懂得测试用例不光要根据输入字段去设计，还要根据输出（什么样的输入才能覆盖各种可能的输出）、服务器上各种数据的状态变迁图去设计用例。
这就是最简单的方法论，太简单到所有的人都觉得这个不是理所当然的吗。

有人会比较鄙视只会夸夸其谈，说起理论一堆一堆的，但是动起手来就什么都不会的人。我也很鄙视这种人。
不过理论也是必须的，想一想这个问题：
为什么开发同学，除了看《某某语言精通》《深入某某语言》这类的书外，还要看《设计模式》、《重构》、TDD 这类的书呢？
前者是学会一门语言，后者是学会如何用好语言，后者通常是跨语言的，实际上就是一种方法论，如何用好自己学会的语言。

测试在这方面比较薄弱，形成的大家都认同的方法论比较少，但是为什么就不应该有呢？或者说就不重要了呢？
难道不是应该有人站出来，不断的把自己的经验传递下去，最终形成方法论吗？

除非一开始，大家就已经认为测试是一种比较低级的工作，很简单就能做好，难是难在学习一门编程语言上。。。