> 测试技术&建模能力
> 问题敏感性&逻辑分析能力
> 行业知识&快速学习能力
> 技术框架&读、写代码的能力
1. 测试技术、建模能力
开发、产品甚至是技术领导觉得测试只要了解了被测试对象是做什么的，怎么做的，就能做好测试了。甚至很多测试人自己也普遍存在此种想法。这两个能力是测试人的能力核心，也是价值的体现。
建模能力是分析产品的能力，既包括功能、性能、压力等，也包括使用场景、所属行业，测试完整性反馈出来的就是这方面的能力。测试leader如果欠缺这方面的功力，那么产品发布后得到的可能就是不定期和无休止的“惊喜”。不同公司在测试建模方面有不同的实践，目前国内大部分公司基本是延续公司的既有先例，比如将测试用例分为功能、性能、组合、压力、异常等，公司的测试人员也甚少去考虑为什么测试这些，是否还有其他方面需要考虑的，只是简单重复执行而已。不同的产品有不同的用户和市场，测试模型需要单独考虑。 目前比较有代表性测试建模工具，一个是james bach的HTSM(启发式测试策略模型)，另一个是Google在《
How Google Tests Software 》提到的ACC模型。
这两个模型都有几年的时间了，不知道是否有所更新和发展，后续有单独的文章对测试建模进行分析。
Cem Kaner教授从测试的范围、覆盖程度、测试者、风险、活动、质量评估几个角度来对测试技术进行分类，此分类已经建立了有十几年的时间，业界具有权威性。比如基于测试的范围和覆盖度有功能、性能、本地化、配置、边界值等；基于由谁来进行可以分为用户测试、α测试、β测试、本地化测试、专家测试等；基于风险有快速测试、负载测试、性能测试等。不同的测试分类会有相互交叉，我们可以根据公司产品的质量状态、研发流程、产品特点、研发水平选用不同的测试技术，来满足市场对产品质量的需求。
junit、nose、robotframework、jenkins、monkeys、selenium等等只是实践测试技术的工具，技术是核心，建议未了解过的测试同学增强这方面的能力。
2. 问题敏感性、逻辑分析能力
看到同一个现象，不同的人有不同的反应：无反应（我看到什么了？）、正常、有问题。对于反馈正常或有问题的，说明他意识到了这个现象，并且有意识的去分析这个现象是对还是错；而完全无反应的，就属于那种对问题特别不敏感的，需要加强锻炼。比如可以对看到的任何现象都有意识的去分析一下，是对的还是错的、是否符合习惯、是否合理、让你来做你会怎么做等等。
对问题比较敏感的人会将这类思维带入到生活中，比如快递到了得先看看是哪里寄出来的、字有没有写错的、采用这种包装内容物有没有被换掉的风险等等。
每个测试人都希望得到所在团队的尊重和认可。在技术型的公司中，得到尊重唯一的方法是彰显自己的技术实力（当然交流方式也是很重要的）。被尊重是通过自己不断的努力争取来的，这就是平时沟通、交流过程中所体现出来的问题综合分析能力，以及对系统实现、市场应用的深刻理解。
作为一个测试工程师，碰到问题的时候，你能指出这个问题出现在代码的哪个服务、哪个模块、哪个函数吗？是如何调用的？ 甚至是开发同学是如何写错的，怎么改正是对的？如果你觉得这不是测试该干的，那也就只能呵呵了。
3. 行业知识、快速学习能力
所谓行业知识，是指从事这个行业的人，所需要掌握的知识体系、行业规范、实时动向、发展状况等。不同行业比如金融、电信、制造、电商、教育、物流等所需具备的知识是完全不同的。只有具备良好的行业背景才能理解客户需求，并设计满足用户需求的产品，做出合理的测试决策。
你所在的行业有哪些技术规范、行业标准，了解吗？ 国内的，国际的，差异在哪里？
在当前智力大爆发、黑科技频出，不想关的两个行业都可以相互颠覆的时代，测试人作为投身其中的一份子要么随波逐流被动调整，要么主动寻求改变。不管哪种方式，我们都需要具有快速学习的能力才能跟得上这个时代的发展，并站在用户的角度去研究领域知识，成为领域专家，给产品、市场等团队提出合理的产品设计建议，并给出客观的质量评价标准。
你有危机感吗？测试工作会被机器学习、人工智能取代吗？还是开发同事先担心吧，Google已经在研究机器学习写代码了。
4. 技术框架、读写代码的能力
随着竞争的加剧，不管是熊厂、鹅厂还是狼厂比拼的都是产品上市速度。在这种压力下，不可能预留太长的测试时间，持续集成、自动化测试是必然的。这就要求测试人不光要了解测试的技术，还要熟悉网站业务的分割分层、数据库的分库分表、数据的冷备热备；开发所采用hibernate、spring、structs等技术框架，以及java、python、go等层出不穷的语言，以便及时进行单元、集成、API接口、UI层面自动化用例的开发，提高测试的效率。
这是在网上看到的一个例子： 在一个有着广泛市场影响的项目中，新版本发布增加了新的功能，在HTML页面中使用JavaScript来控制控件的显现。而发布时间紧迫，不允许有更多的时间使用正向用例来验证功能的正确性。尽管如此，我们也针对这小小的控件设计了将近百条用例。涉及的方面包括从页面的正反向跳转来验证控件的版本升级，到控件的跨域调用、浏览器的兼容、服务设置及干扰，如此种种，无一不需要了解相关技术，才能设计出有价值的用例。
不管测试分析能力多强，黑盒始终发现的是一部分问题，白盒测试是发现更多问题、提高测试效率的必然手段。但是目前来看，测试工程师对系统的认知能力，是自动化测试比拼不了的，比如易用性、性能测试等。
相关文章：
