编者按：测试、QA一直是大家关注的话题，只要有软件开发，离不开QA和软件测试。本次特别邀请到一淘网测试架构师 @公直_黄利 ，诺基亚敏捷及精益教练 @徐毅-Kaveri 和百度高级测试工程师杨进，请他们谈下各自对QA和测试的理解，内容涉及如何衡量软件测试的有效性，探索式测试，敏捷测试，开源对测试的影响，测试的开放性以及测试框架推荐等。

　　请先做下自我介绍。

　　徐毅：我叫徐毅，现在在诺基亚北京担任敏捷及精益教练的工作。我是从05年在杭州诺基亚网络的时候开始转做专职测试的，同期也加入公司刚成立的测试自动化小组，这对我的理念有很大的影响，基本上我认为所有的测试都应该自动化。06年初加入当时的第一个Scrum试点项目，体会了一把敏捷测试，当时还根据我们的经验总结出了一套轻量化的测试流程。后来我们在公司内推广使用robotframework这个工具，作为培训师指导大家学会使用这个工具来进行测试自动化。后来还担任了一段时间的测试自动化教练的工作。

　　公直：阿里巴巴一淘网测试架构师。

　　杨进：百度高级测试工程师，06年加入百度，之前有过4年的测试开发工作，加入百度以来，主要从事自动化开发、测试方法改进以及系统测试相关的工作。

　　近主要在从事哪方面的工作？

　　徐毅：近主要是在敏捷及精益教练这个方面做得比较多，辅助组织和个人进行敏捷转型，由于有很强的测试背景，所以同时也做敏捷测试相关的工作。

　　公直：近半年一直在做代码质量的相关工作。在一淘业务线测试团队支持之下，与测试、产品架构师、PE等合作，从系统层面出发，优化目前的测试策略和方法，提升系统的可测试性和可部署性。

　　杨进：近1年主要focus在系统测试和效果监控等系统层面的工作，目前是线下百度和大搜索效果监控的负责人，线下百度是一个基础的系统测试平台，对外提供预上线、故障预演、数据测试等系统层面的服务，而效果监控目标是快速发现产品严重影响用户体验的效果问题，它和线下百度相互相成，共同提升百度对外服务的质量。

　　国内外一直有很多人把测试与质量保证混为一谈，其实测试属于质量控制（QC），而QA还有更多内容，请谈谈您对QA和测试的理解。

　　徐毅：其实不管是保证还是控制，都很难达到名副其实的效果。测试做得再充分、再彻底、再快速，也无法把质量给控制起来，多只能够更频繁地展现出质量的现状。关于QA么，我曾经在微博上发起过一个讨论，还是比较热闹的，大家可以去看看，What is the value of Quality Manager。至于“质量保证”这个词，大家可以想一想，如果我跟你拍胸脯说某件事情包在我身上，我保证办到，但实际情况是，回过头去我得催着一拨人做这个做那个才能保证你的事情办妥，你觉得这是你理解中的“保证”吗？ 更重要的问题在于，“质量是什么”。如今，我们可以说质量的外延发生了变化，已经涵盖了许多方面；也可以说，质量已经不再重要，用户体验才是重要的。温伯格在他的《质量 软件 管理》书中说到“quality is value to some person”，对于不同的人来说，同一件东西的价值可以是不同的。

　　公直：其实一直以来个人不太喜欢把测试工程师称呼为QA，QA一般是指质量保证，范畴更大一些，在一淘，像过程改进工程师、配置管理工程师都在做质量控制的事情。单纯地靠测试工程师本身也是没有办法控制质量的，因为对决定软件质量的还是开发工程师。这个在博客中的《Google如何测试》系列文章中提及，对于质量来说，预防问题比发现问题本身更重要。质量更多是开发人员的问题，而不是测试人员的。通过把测试工作融入到开发过程中，我们能降低那些富产Bug的人的出错机会，不仅可以避免了大量终用户的使用问题，而且还可以极大地降低测试人员报无效Bug的数量。测试的未来在于发现设计和编程人员解决问题方法上的局限、思路中的狭隘和技能方面的不足，这是我对测试的理解，也认为是以后测试发展的一个方向。

　　杨进：我理解测试关注的更多是被测对象上线前的质量，而QA关注的是宏观意义上的质量，包括开发环节的质量控制（如何提高代码本身质量）、测试环节、上线环节以及运维环节（如线上出现问题后如何快速止损），甚至还包括用那种开发模式能更有效的提升项目开发质量和效率，因而是一个更宽泛的领域。

　　如何衡量软件测试的有效性？

　　徐毅：衡量一个东西的有效性，对我来说看比较有无之间的区别，也是说比较“有软件测试”和“无软件测试”在“效果”上面的差异，那是有效性啦，也即是有效的程度。那么，你所期望的“效果”又是什么呢？

　　公直：从90年代末开始，测试进入所谓的“Prevention oriented period ”（参见wiki）阶段，强调2点，第一个缺陷预防，第二是软件度量。是这个问题本身（如何衡量软件测试的有效性），如何度量你做的测试有什么收益，如何判断你的测试活动的有效性，无论是学术界还是工业界，好像也还没有什么比较好的方法，特别是在国内目前的现状（人治，部门经理或者项目经理决定太多东西），度量系统（例如sonar）计算出的测试ROI本身可能也不一定准确，人的因素变化太多。我简单说下我们这边判断测试有效性做法好了，基本上还是还是从结果来看，上线失败次数、线上故障、线上Bug几个维度来评估测试的有效性。

　　杨进：要想全面评判测试的有效性是比较困难的，目前比较通用的手段是在产品发布以后，利用用户报告bug的数量和趋势来判断测试的有效性，然后这种判断方法需要上线后才能进行因而显得价值有限，上线前也有一些可参考的手段，比如UT完成后的代码覆盖率，测试用例完后的评审，测试报告的评审等。我自己比较喜欢手段是代码覆盖率，因为代码覆盖率是一个利用客观标准进行判定的方法。此外基于测试需求覆盖率也是一个好方法。

　　请谈下您对探索式测试的理解，请分享下这方面的实践经验？

　　徐毅：其实探索式测试是什么，Cem Kaner和James Bach的一些文章、PPT都已经写得非常清楚。

　　首先探索式测试是一种测试的“方式”（Way，或Approach），而不是测试“技术”（Technique），方式也即是指完成整体测试工作所选择的办法，而技术则是指对于局部测试工作进行操作的方法。

　　其次，ET的目的在于“探索”，也即有一个明确的测试目标，但是目标的细节或是达成目标的步骤尚不清晰，所以需要边走边看，同时间地进行学习、设计、执行、解析的结果，与PDCA循环颇有相似之处。

　　第三要区分开ET和手工测试的关系。“手工测试”所强调的是执行的手段，也即“手工”。而ET主要强调目的，也即“探索”，当然还有是，执行只不过是ET中的一部分而已，而这一部分，可以借助自动化。例如，修改某个已有自动化测试脚本中的部分测试数据，借助于脚本快速地执行某些操作，而去掉或暂停分析部分的脚本执行，因为此时测试的结果未知，需要依赖人工来判断、分析测试结果。

　　公直：探索式测试近2年异常火爆，很多人以为是新出的一个测试技术或者方法。Cem Kaner 在1983年（都快30年了）提出了。这是一种强调个人自由与责任的测试方法，让独立测试人员可以借由不断的学习来改善测试的规划与测试的执行，而在测试的过程中也会同时改善测试用例从而达到相辅相成的效果。在一淘这边，其实很早开始使用这种实践方法了，但很多一线的测试人员并不知道自己的做法是探索式测试，在互联网研发模式下，一般都或多或少地使用敏捷模式，或者其他的土方法，但迭代周期都很短，一个月要上线。在这样的环境下，文档少，在测试计划制定设计上都不可能完善，一般在测试过程中是用freemind等脑图工具来记录测试执行过程的同时做测试用例的设计，这种方式可以做常规测试的补充。

　　杨进：我很喜欢探索性测试，它让测试工作变得轻松和富有创造力，它能让你无需复杂的测试准备，直接进入核心的测试工作，并且不拘泥用什么方法、什么工具，也不用考虑能否能被自动化，只需要关注能否快速的找到bug行。当然好的探索性测试实际上对工程师的逻辑分析能力和产品整体理解要求很高，这种依赖于个人能力的测试手段，执行的效果也比较难以控制。

　　探索性测试的实践方面，我们之前尝试过多人组队测试，这种方式适用于多人进行的大型项目，大家一起进行探索性测试，bug系统即时显示你在这个版本发现了多少个bug，并且排名，我们每天乐于寻找更多的bug，并且分享找bug的技巧，在这个过程中我们都得到了很多的成感，并且对产品的理解和测试技巧也大幅提升。现在回想起来也还是一个很有意思的事情。