51Testing专访史亮：测试人员在国外

不久前，我接受了51Testing的访问，讨论了软件测试的一些问题。如下是全文。

 

一、史亮老师，做为咱们51Testing的老朋友，能和咱们说说您最近在忙些什么吗？

自2011年起，我加入Microsoft Office部门，参与了Microsoft Office 2013的研发，主要工做是测试Windows版本的Office产品。目前，我正参与研发下一代的Microsoft Office，主要工做是测试产品和开发测试辅助工具。

今年，个人新书《软件测试实战》问世。这本书基于一个很朴素的想法：我在软件测试领域有较多的积累，若是将个人所学所知分享给更多的测试工程师，想必能帮助他们节省学习时间，更快地提升测试水平。 在该想法的驱动下，我研究了测试文献，反思了自身实践，并持续地写做。一方面，我总结了测试专家的看法和方法，将其精华内容综述在本书之中，另外一方面，我努力将本身的经验和反思融入书稿，使它体现出我在实际工做中使用的策略、方法和技巧。总之，这是一本注重实效的书，尝试用理论结合实践的方式来解决现实的问题。

 

二、您在国外工做了一段时间，您认为国外公司和中国公司最大的不一样在哪？让您感觉最深的又是什么？

我认同语境驱动测试（Context Driven Testing）的观点：测试实践的价值来自于它的语境。除了测试人员的态度和能力，产品、项目和团队对测试实践有最大的影响。所以，我在撰写《软件测试实战》一书时，重点讨论了测试人员如何研究产品（第7章）、研究项目（第8章）和融入团队（第9章）。这些内容并不针对特定的企业或项目，而是尝试提供一组方法，帮助测试人员了解当前的项目语境，以设计出高效的测试策略。

在我看来，国内的软件行业蓬勃发展，软件项目呈现出多样化、差别化的特色。有些企业充分利用全球信息，致力于世界级的产品和服务，其企业文化和工做方式与外企并无太大的差异，甚至在许多地方处于领先位置。

从另外一个角度看，不存在“最好的工做方式”，只存在适合当前项目语境（市场环境、产品元素、产品质量、项目团队）的“好的工做方式”。因此，一个好的团队是一个“自学习、自组织”的团队，可以从工做中持续学习经验与教训，并逐渐调整工做方式，经过动态适应变化的环境来优化项目成果。在成功发布的过程当中，团队成员的能力获得发展，团队拥有更强的凝聚力。不管在哪里，技术人员都应该寻找这样的团队，或让本身所在的团队成为这样的团队。

 

三、您在国内和国外都有至关丰富的测试经验，您是如何看待国内外软件测试行业的发展趋势的？

为了更好地讨论这个问题，先介绍一个测试技术分类的参考模型。测试专家Lisa Chrispin和Janet Gregory在《敏捷软件测试》中将测试技术划分到如图1所示的四个象限中。

图1 敏捷测试四象限

• Q1：面向技术的（technology facing）、支持项目团队的（supporting the team）的自动化测试，例如单元测试、组件测试等。
• Q2：面向商业的（business facing）、支持项目团队的自动化和手工测试，包括功能测试、样例、用户故事测试、原型、模拟等。
• Q3：面向商业的、考验产品的（critique product）的手工测试，包括探索式测试，情景测试、可用性测试、用户验收测试、Alpha及Beta测试等。
• Q4：面向技术的、考验产品的、基于工具的测试，例如性能测试、负载测试、安全性测试、属性测试等。

利用敏捷测试四象限，测试人员能够快速理解测试技术在软件开发中的位置，并根据当前任务选择合适的测试技术。不过，我并不一样意Lisa Chrispin和Janet Gregory将探索式测试（exploratory testing）置于Q3象限。探索式测试是一种并行地实施测试学习、测试设计、测试执行和结果评估的测试风格。做为一种测试思惟方法，它能够指导四个象限的任何一种测试技术的使用。

目前，软件行业高速发展，之前所未有的速度向各个产业渗透。在互联网应用、移动应用、物联网应用等重要领域，市场竞争日趋激烈。为了在竞争中脱颖而出，软件项目团队必须具有高度的机动性，可以快速地尝试新想法，并持续发布具备特点的产品。这要求程序员负责更多的测试活动，经过加速“编码—测试—重构”的循环，来快速交付高质量的代码。也就是说，程序员将承担Q1象限（面向技术、支持项目团队）的测试工做，以及部分其余象限的活动——以Q2象限（面向商业、支持项目团队）的活动较为常见。

在该趋势下，专职测试人员的活动将向四象限的右侧和上方移动，更偏向面向商业的、考验产品的测试活动。从业务角度，测试人员的角色应该是领域专家和实际用户，可以以超越代码（beyond code）眼光来考察产品的商业价值和用户价值。从技术角度，测试人员的角色能够是黑客和技术专家，可以在安全性、性能、稳定性等领域实施专业的、高强度的测试。

另外一个软件研发的趋势是DevOps，即融合研发团队和运维团队，由一个团队负责整个产品开发、测试、发布、运维和更新。在此类团队中，测试人员须要承担部分开发和运维任务，例如分析服务端的日志、分析客户端提交的遥测（telemetry）数据、分析用户行为、报告服务状态、定位产品问题、修复特定环节的错误、发布产品更新等。这意味着测试人员的工做不只仅是寻找缺陷，而是经过技术调查（调查对象包括已发布的线上产品）来得到产品信息，以持续提升产品质量。能够说，在一些项目环境中，测试人员的职责发生了变化，须要更多样化的技能。测试人员须要积极面对变化，拓展本身的能力，以适应行业的发展。

 

四、怎么才能进行有效地探索性测试？另外不少优秀的软件测试工程师都能敏锐地嗅到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）。所以，测试人员须要将学到的新技术应用于真实的测试，并认真评估其效果。经过练习、评估和反思，测试人员可以掌握方法的原理和细节，并混入自身经验和其余技术，以演化出新的方法。坚持这样的研究和创新将帮助测试人员走上精通之路。

 

五、您认为如何作一名优秀的软件测试工程师？他至少具有哪些技术能力？

《软件测试实战》的目录（点击连接，在弹出页面中点击“显示目录级别3”，能够查看完整的目录）概述了测试人员须要考虑的专业能力。在此，我作简要的介绍。

• 第2章，缺陷报告：提交高质量的缺陷报告，尽力让缺陷获得修复。
• 第3章，测试文档：在测试的迭代过程当中，发展出实用且多样的测试策略，将测试设计和测试结果的核心信息记录为一组精要的文档。
• 第4章，测试建模：创建产品的模型，以指导测试设计。
• 第5章，测试技术：掌握多种测试技术和测试先知，并结合项目状况多样地选择测试技术。
• 第6章，测试开发：掌握开发技术，以高效地实施自动化测试、计算机辅助测试和超大规模自动化测试。
• 第7章，研究产品：利用静态分析研究产品源代码，利用动态分析研究产品行为，利用业务分析研究理解关系人和领域，从而得到更有针对性的测试设计。
• 第8章，研究项目：熟悉项目团队、研究项目元素、分析项目风险，从而得到更注重实效的测试设计。
• 第9章，团队工做：创建正确的价值观，积极融入团队，并经过有效的测试管理、软件估算、软件度量来为团队服务。
• 第10章，我的管理：积极实施时间管理，经过持续学习和且行且思来逐步成为测试专家。

面对如此多的内容，一条值得参考的指导原则是，肯定项目团队或所在领域最须要的技能，而后努力掌握它们。对于此类知识，经过实际工做来掌握是一种比较好的学习方法。这样作能够加速获取知识与应用知识的循环，并让学习成果当即帮助测试过程。成功的应用可以加强测试人员的信心，鼓舞他更深刻地研究。

 

六、您认为在测试中如何提升本身的测试思惟和测试技术？

问题4和问题5的回答对于本问题有参考价值。在这里，我补充说明一个测试人员容易忽略的要点：提升测试技术的根本目标是为了更有效的测试，在许多状况下，测试效果（测试技术的实施效果）决于测试人员对软件和项目的理解。

我曾经长期测试一个网络应用。当我离开这个项目时，测试经理安排一个测试员工来接替我。他刚刚入职，对被测软件和业务领域都不了解，在工做中遇到了许多困难，我帮助他解决了一系列问题。做为一个测试工程师，个人工做效率更高，主要缘由包括：

• 我理解产品，知道它的业务目标，了解它经过什么方法去实现目标。所以，我可以快速地制定测试方案。
• 我理解用户的指望，知道哪些功能绝对不能出错，须要仔细测试。我也知道哪些功能容许一些瑕疵，即使出错，也能够在三个月以后发布的下一个版本中修复。所以，我可以更好地分配测试时间。
• 我理解产品的架构，阅读过大部分模块源代码，知道哪些模块容易出现哪些缺陷。所以，我能够针对不一样的模块采用有针对性的测试策略。
• 我曾经尝试自动化测试用户界面，可是发现此类自动化测试很不稳定，须要很高的维护代价，却不能发现错误。因而，我只为Web服务编写自动化测试用例，用手工测试来检查用户界面。所以，我回避了浪费时间却没有收益的任务。
• 我了解产品元素和项目团队。当出现缺陷时，我知道如何阅读系统日志发掘蛛丝马迹；当我遇到困难时，我知道向哪位程序员或测试人员求助。所以，我能够深刻挖掘并快速推动。
• 我在原先的团队工做了很长的时间，与同事们保持了良好的关系。当我提出一些可测试性的建议时，比较容易受到程序员的支持。

从以上几点不难看出，我可以更有效地测试，其主要缘由不是我掌握更多的测试技术，而是我更了解软件产品、业务领域和项目环境。经过逐点分析，能够获得以下启示。

• 产品是一种解决方案，若是没有解决问题，它就是无用的。测试人员须要了解软件产品和业务领域，才能设计有效的测试。
• 测试是一种信息服务，要了解服务对象（一般最重要的服务对象是用户和项目经理）的需求。若是用户不能容忍某些错误，测试人员就须要仔细测试相关功能；若是用户对一些瑕疵并不在乎，测试人员就没必要在此花费更多的时间。只有了解服务对象的优先级，才能更好地设定测试工做的优先级。
• 不一样的模块采用不一样的技术，拥有不一样的典型错误。只有了解软件实现，才能设计差别化且有针对性的测试用例。
• 测试设计可能包含错误，测试人员须要从错误中吸收经验和教训。避免一些已知的错误，会提升测试效率。
• 当测试工做遇到困难时，测试人员须要知道在哪里寻找信息。了解产品可以提供的信息、了解哪位同事知道更多内幕，会节省时间。
• “人脉”有时候会极大地提升测试人员的工做效率，测试人员须要和程序员和测试同事保持良好的关系。达成协做关系的关键之一是测试人员可以为同事们提供高质量的信息服务。
• 在职业生涯中，测试人员老是会遇到新的软件、项目和团队。他应该培养一种好的工做风格，以求快速地理解产品和项目。

实施高效的测试须要不少条件。熟练地掌握测试技术是一个很重要的因素，但不多会是决定性的因素。只有充分地掌握软件产品和项目环境，测试技术才能找到大放光彩的舞台。

 

七、您能给想学习探索式测试的新人，给推荐几本书？

探索式测试是一个内涵丰富的主题，感兴趣的测试人员能够从如下书籍入手。

• 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提供了一批推荐读物，供读者参考。