不久前，我接受了51Testing的访问，讨论了软件测试的一些问题。以下是全文。
1、史亮老师，作为我们51Testing的老朋友，能和我们说说您最近在忙些什么吗？
自2011年起，我加入Microsoft Office部门，参与了Microsoft Office 2013的研发，主要工作是测试Windows版本的Office产品。目前，我正参与研发下一代的Microsoft Office，主要工作是测试产品和开发测试辅助工具。
今年，我的新书《软件测试实战》问世。这本书基于一个很朴素的想法：我在软件测试领域有较多的积累，如果将我的所学所知分享给更多的测试工程师，想必能帮助他们节省学习时间，更快地提高测试水平。 在该想法的驱动下，我研究了测试文献，反思了自身实践，并持续地写作。一方面，我总结了测试专家的见解和方法，将其精华内容综述在本书之中，另一方面，我努力将自己的经验和反思融入书稿，使它体现出我在实际工作中使用的策略、方法和技巧。总之，这是一本注重实效的书，尝试用理论结合实践的方式来解决现实的问题。
2、您在国外工作了一段时间，您认为国外公司和中国公司最大的不同在哪？让您感受最深的又是什么？
我认同语境驱动测试（Context Driven Testing）的观点：测试实践的价值来自于它的语境。除了测试人员的态度和能力，产品、项目和团队对测试实践有最大的影响。因此，我在撰写《软件测试实战》一书时，重点讨论了测试人员如何研究产品（第7章）、研究项目（第8章）和融入团队（第9章）。这些内容并不针对特定的企业或项目，而是尝试提供一组方法，帮助测试人员了解当前的项目语境，以设计出高效的测试策略。
在我看来，国内的软件行业蓬勃发展，软件项目呈现出多样化、差异化的特点。有些企业充分利用全球信息，致力于世界级的产品和服务，其企业文化和工作方式与外企并没有太大的差别，甚至在许多地方处于领先位置。
从另一个角度看，不存在“最好的工作方式”，只存在适合当前项目语境（市场环境、产品元素、产品质量、项目团队）的“好的工作方式”。所以，一个好的团队是一个“自学习、自组织”的团队，能够从工作中持续学习经验与教训，并逐渐调整工作方式，通过动态适应变化的环境来优化项目成果。在成功发布的过程中，团队成员的能力得到发展，团队拥有更强的凝聚力。无论在哪里，技术人员都应该寻找这样的团队，或让自己所在的团队成为这样的团队。
3、您在国内和国外都有相当丰富的测试经验，您是如何看待国内外软件测试行业的发展趋势的？
为了更好地讨论这个问题，先介绍一个测试技术分类的参考模型。测试专家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）数据、分析用户行为、报告服务状态、定位产品问题、修复特定环节的错误、发布产品更新等。这意味着测试人员的工作不仅仅是寻找缺陷，而是通过技术调查（调查对象包括已发布的线上产品）来获得产品信息，以持续提高产品质量。可以说，在一些项目环境中，测试人员的职责发生了变化，需要更多样化的技能。测试人员需要积极面对变化，拓展自己的能力，以适应行业的发展。
4、怎么才能进行有效地探索性测试？另外很多优秀的软件测试工程师都能敏锐地嗅到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）。因此，测试人员需要将学到的新技术应用于真实的测试，并认真评估其效果。通过练习、评估和反思，测试人员能够掌握方法的原理和细节，并混入自身经验和其他技术，以演化出新的方法。坚持这样的研究和创新将帮助测试人员走上精通之路。
5、您认为如何做一名优秀的软件测试工程师？他至少具备哪些技术能力？
《软件测试实战》的目录（点击链接，在弹出页面中点击“显示目录级别3”，可以查看完整的目录）概述了测试人员需要考虑的专业能力。在此，我做简要的介绍。
- 第2章，缺陷报告：提交高质量的缺陷报告，尽力让缺陷得到修复。
- 第3章，测试文档：在测试的迭代过程中，发展出实用且多样的测试策略，将测试设计和测试结果的核心信息记录为一组精要的文档。
- 第4章，测试建模：建立产品的模型，以指导测试设计。
- 第5章，测试技术：掌握多种测试技术和测试先知，并结合项目情况多样地选择测试技术。
- 第6章，测试开发：掌握开发技术，以高效地实施自动化测试、计算机辅助测试和超大规模自动化测试。
- 第7章，研究产品：利用静态分析研究产品源代码，利用动态分析研究产品行为，利用业务分析研究理解关系人和领域，从而获得更有针对性的测试设计。
- 第8章，研究项目：熟悉项目团队、研究项目元素、分析项目风险，从而获得更注重实效的测试设计。
- 第9章，团队工作：建立正确的价值观，积极融入团队，并通过有效的测试管理、软件估算、软件度量来为团队服务。
- 第10章，个人管理：积极实施时间管理，通过持续学习和且行且思来逐步成为测试专家。
面对如此多的内容，一条值得参考的指导原则是，确定项目团队或所在领域最需要的技能，然后努力掌握它们。对于此类知识，通过实际工作来掌握是一种比较好的学习方法。这样做可以加速获取知识与应用知识的循环，并让学习成果立即帮助测试过程。成功的应用能够增强测试人员的信心，鼓舞他更深入地研究。
6、您认为在测试中如何提高自己的测试思维和测试技术？
问题4和问题5的回答对于本问题有参考价值。在这里，我补充说明一个测试人员容易忽略的要点：提高测试技术的根本目标是为了更有效的测试，在许多情况下，测试效果（测试技术的实施效果）决于测试人员对软件和项目的理解。
我曾经长期测试一个网络应用。当我离开这个项目时，测试经理安排一个测试员工来接替我。他刚刚入职，对被测软件和业务领域都不了解，在工作中遇到了许多困难，我帮助他解决了一系列问题。作为一个测试工程师，我的工作效率更高，主要原因包括：
- 我理解产品，知道它的业务目标，了解它通过什么方法去实现目标。因此，我能够快速地制定测试方案。
- 我理解用户的期望，知道哪些功能绝对不能出错，需要仔细测试。我也知道哪些功能允许一些瑕疵，即便出错，也可以在三个月之后发布的下一个版本中修复。因此，我能够更好地分配测试时间。
- 我理解产品的架构，阅读过大部分模块源代码，知道哪些模块容易出现哪些缺陷。因此，我可以针对不同的模块采用有针对性的测试策略。
- 我曾经尝试自动化测试用户界面，但是发现此类自动化测试很不稳定，需要很高的维护代价，却不能发现错误。于是，我只为Web服务编写自动化测试用例，用手工测试来检查用户界面。因此，我回避了浪费时间却没有收益的任务。
- 我了解产品元素和项目团队。当出现缺陷时，我知道如何阅读系统日志发掘蛛丝马迹；当我遇到困难时，我知道向哪位程序员或测试人员求助。因此，我可以深入挖掘并快速推进。
- 我在原先的团队工作了很长的时间，与同事们保持了良好的关系。当我提出一些可测试性的建议时，比较容易受到程序员的支持。
从以上几点不难看出，我能够更有效地测试，其主要原因不是我掌握更多的测试技术，而是我更了解软件产品、业务领域和项目环境。通过逐点分析，可以得到如下启示。
- 产品是一种解决方案，如果没有解决问题，它就是无用的。测试人员需要了解软件产品和业务领域，才能设计有效的测试。
- 测试是一种信息服务，要了解服务对象（通常最重要的服务对象是用户和项目经理）的需求。如果用户不能容忍某些错误，测试人员就需要仔细测试相关功能；如果用户对一些瑕疵并不在意，测试人员就不必在此花费更多的时间。只有了解服务对象的优先级，才能更好地设定测试工作的优先级。
- 不同的模块采用不同的技术，拥有不同的典型错误。只有了解软件实现，才能设计差异化且有针对性的测试用例。
- 测试设计可能包含错误，测试人员需要从错误中吸取经验和教训。避免一些已知的错误，会提高测试效率。
- 当测试工作遇到困难时，测试人员需要知道在哪里寻找信息。了解产品能够提供的信息、了解哪位同事知道更多内幕，会节省时间。
- “人脉”有时候会极大地提高测试人员的工作效率，测试人员需要和程序员和测试同事保持良好的关系。达成协作关系的关键之一是测试人员能够为同事们提供高质量的信息服务。
- 在职业生涯中，测试人员总是会遇到新的软件、项目和团队。他应该培养一种好的工作风格，以求快速地理解产品和项目。
实施高效的测试需要很多条件。熟练地掌握测试技术是一个很重要的因素，但很少会是决定性的因素。只有充分地掌握软件产品和项目环境，测试技术才能找到大放光彩的舞台。
7、您能给想学习探索式测试的新人，给推荐几本书？
探索式测试是一个内涵丰富的主题，感兴趣的测试人员可以从以下书籍入手。
- 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提供了一批推荐读物，供读者参考。