在该趋势下，专职测试人员的活动将向四象限的右侧和上方移动，更偏向面向商业的、考验产品的测试活动。从业务角度，测试人员的角色应该是领域专家和实际用户，能够以超越代码（beyond code）眼光来考察产品的商业价值和用户价值。从技术角度，测试人员的角色可以是黑客和技术专家，能够在安全性、性能、稳定性等领域实施专业的、高强度的测试。
另一个软件研发的趋势是DevOps，即融合研发团队和运维团队，由一个团队负责整个产品开发、测试、发布、运维和更新。在此类团队中，测试人员需要承担部分开发和运维任务，例如分析服务端的日志、分析客户端提交的遥测（telemetry）数据、分析用户行为、报告服务状态、定位产品问题、修复特定环节的错误、发布产品更新等。这意味着测试人员的工作不仅仅是寻找缺陷，而是通过技术调查（调查对象包括已发布的线上产品）来获得产品信息，以持续提高产品质量。可以说，在一些项目环境中，测试人员的职责发生了变化，需要更多样化的技能。测试人员需要积极面对变化，拓展自己的能力，以适应行业的发展。
51Testing：您已经第二次做客我们51Testing了，上一次专访我们聊得是探索式测试，相信很多朋友都对此印象深刻。作为探索式测试的资深人士，怎样才能进行有效地探索式测试？另外很多优秀的软件测试工程师都能敏锐地嗅到bug，您认为该如何训练这方面能力？
史亮：首先，"态度决定一切"。成为一个优秀的测试人员，我认为最重要的基础是对项目、对自己负责任的态度。对项目负责，测试人员需要提供高质量的测试服务来帮助项目成功；对自己负责，测试人员应该以专业人员（professionals）自居，坚持专业主义（professionalism），追求精湛的技艺和卓越的成果。这需要通过日复一日的努力工作来落实，无捷径可言。
第二，Cem Kaner等测试专家指出"困惑是一种测试工具"。有时，软件的表现出乎测试人员预料，但是他并不能确定这是一个缺陷。这说明测试人员对软件的设计还有不了解的地方。他应该将此疑惑视为一个学习的机会，通过阅读文档、咨询同事等方法来获得答案。推而广之，如果测试人员对软件、技术或项目产生疑问，他应该感到警惕。这可能意味着他不了解业务逻辑，不知晓产品设计，不清楚实现细节。这些知识上的漏洞会导致薄弱的测试设计和严重的缺陷遗漏。
负责人的测试人员不会放过任何一个疑问，在"好奇心"的指引下，他会"打破沙锅问到底"。他会运用多种手段（周密测试、代码分析、软件调试、文档阅读、请教专家等）对问题进行研究。通过积极地测试和学习，测试人员不但可以弥补知识的漏洞，还可以发现隐藏的缺陷。
第三，测试人员需要"刻意练习"。测试专家已经给出了许多好的建议和方法，这些想法皆来自于实践。软件开发专家Ralph E. Johnson 指出"从实践中来的知识在没有实践之前是无法被真正理解的"（practical knowledge has to be experienced to fully understood），测试专家Cem Kaner等也认为"你不能掌握测试，除非你重新发明它"（You can't master testing unless you reinvent it）。因此，测试人员需要将学到的新技术应用于真实的测试，并认真评估其效果。通过练习、评估和反思，测试人员能够掌握方法的原理和细节，并混入自身经验和其他技术，以演化出新的方法。坚持这样的研究和创新将帮助测试人员走上精通之路。
51Testing：许多刚从事测试的新人往往会在工作的过程中发现自己的很多不足，想要提高自己，在您看来，测试人员应如何提高自己的测试思维和测试技术？
史亮：前面两个问题的回答对于本问题有参考价值。在这里，我补充说明一个测试人员容易忽略的要点：提高测试技术的根本目标是为了更有效的测试，在许多情况下，测试效果（测试技术的实施效果）决于测试人员对软件和项目的理解。
我曾经长期测试一个网络应用。当我离开这个项目时，测试经理安排一个测试员工来接替我。他刚刚入职，对被测软件和业务领域都不了解，在工作中遇到了许多困难，我帮助他解决了一系列问题。作为一个测试工程师，我的工作效率更高，主要原因包括：
" 我理解产品，知道它的业务目标，了解它通过什么方法去实现目标。因此，我能够快速地制定测试方案。
" 我理解用户的期望，知道哪些功能绝对不能出错，需要仔细测试。我也知道哪些功能允许一些瑕疵，即便出错，也可以在三个月之后发布的下一个版本中修复。因此，我能够更好地分配测试时间。
" 我理解产品的架构，阅读过大部分模块源代码，知道哪些模块容易出现哪些缺陷。因此，我可以针对不同的模块采用有针对性的测试策略。
" 我曾经尝试自动化测试用户界面，但是发现此类自动化测试很不稳定，需要很高的维护代价，却不能发现错误。于是，我只为Web服务编写自动化测试用例，用手工测试来检查用户界面。因此，我回避了浪费时间却没有收益的任务。
" 我了解产品元素和项目团队。当出现缺陷时，我知道如何阅读系统日志发掘蛛丝马迹；当我遇到困难时，我知道向哪位程序员或测试人员求助。因此，我可以深入挖掘并快速推进。
" 我在原先的团队工作了很长的时间，与同事们保持了良好的关系。当我提出一些可测试性的建议时，比较容易受到程序员的支持。
从以上几点不难看出，我能够更有效地测试，其主要原因不是我掌握更多的测试技术，而是我更了解软件产品、业务领域和项目环境。通过逐点分析，可以得到如下启示。
" 产品是一种解决方案，如果没有解决问题，它就是无用的。测试人员需要了解软件产品和业务领域，才能设计有效的测试。
" 测试是一种信息服务，要了解服务对象（通常最重要的服务对象是用户和项目经理）的需求。如果用户不能容忍某些错误，测试人员就需要仔细测试相关功能；如果用户对一些瑕疵并不在意，测试人员就不必在此花费更多的时间。只有了解服务对象的优先级，才能更好地设定测试工作的优先级。
" 不同的模块采用不同的技术，拥有不同的典型错误。只有了解软件实现，才能设计差异化且有针对性的测试用例。
" 测试设计可能包含错误，测试人员需要从错误中吸取经验和教训。避免一些已知的错误，会提高测试效率。
" 当测试工作遇到困难时，测试人员需要知道在哪里寻找信息。了解产品能够提供的信息、了解哪位同事知道更多内幕，会节省时间。
" "人脉"有时候会极大地提高测试人员的工作效率，测试人员需要和程序员和测试同事保持良好的关系。达成协作关系的关键之一是测试人员能够为同事们提供高质量的信息服务。
" 在职业生涯中，测试人员总是会遇到新的软件、项目和团队。他应该培养一种好的工作风格，以求快速地理解产品和项目。
实施高效的测试需要很多条件。熟练地掌握测试技术是一个很重要的因素，但很少会是决定性的因素。只有充分地掌握软件产品和项目环境，测试技术才能找到大放光彩的舞台。
51Testing：想要提高测试技术，书籍是必不可少的朋友，作为探索式测试的忠实实践者，您能给我们的会员推荐几本相关书籍吗？
史亮：探索式测试是一个内涵丰富的主题，感兴趣的测试人员可以从以下书籍入手。
" Cem Kaner, James Bach, Bret Pettichord, 《软件测试经验与教训》（Lessons Learned in Software Testing：A Context-Driven Approach）。该书是语境驱动测试的经典著作，充满对软件测试的真知灼见，是探索式测试者案头必备。
" 史亮，高翔，《探索式测试实践之路》。该书由我与淘宝资深测试工程师高翔合著，系统地总结了现有的探索式测试实践，并纳入了我们的经验和反思。探索式测试大师James Bach对此书予以了肯定：This is the first book on exploratory testing, in any language, that summarizes the published work in the field。
" 史亮，《软件测试实战》。我本人是探索式测试的忠实实践者，该书可视为"一个探索式测试者的自我总结"。全书虽然没有强调名词"探索式测试"，但是探索式测试的核心精神（将测试学习、测试设计、测试执行、测试结果评估作为相互支持的活动来并行实施）贯穿全书。
" 我和高翔在《探索式测试实践之路》的附录B提供了一批推荐读物，供读者参考。
51Testing：本次访谈即将接近尾声，再问最后一个问题，您以后会选择继续长期留在国外发展还是回国发展呢？
史亮：我目前还在持续评估自己的职业发展，尚未做出长远的规划。
51Testing：由于时间关系，本次访谈正式结束，非常感谢史亮老师抽出宝贵时间参加我们的访谈，祝您在国外工作一切顺利！
史亮：谢谢，也祝51Testing越办越好！
版权声明：51Testing软件测试网原创出品，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。