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