中国软件测试专家访谈录（1）
把握软件的质量
蔡：如何把握软件产品的质量？
郑：不管软件产品规模是大还是小，结构是简单还是复杂，对它们质量的评估都不是一件容易的事情。尽管很难，但是产品质量的评估仍然是必需的，因为它也涉及软件版本是否能够发布。
软件发布之前做评估
根据我和公司内的实践经验，可以从下面两个方面进行评估。
第一，软件产品发布之前的质量评估，具体的度量指标包括：
缺陷，包括发现的总的缺陷分布趋势、缺陷在不同功能模块中的分布等。例如，总的缺陷分布趋势图。
测试通过率，主要包括计划的测试用例执行进度、通过的测试用例数目、失败的测试用例数目、被阻塞的测试用例数目等。我们项目中定义的测试通过率是95%。
测试覆盖率，包括测试对系统需求的覆盖率、对测试类型的覆盖率。例如，我们项目中定义的需求覆盖率必须达到100%，测试类型覆盖率也必须达到100%。
信心，负责这个模块的测试人员对质量的主观感受。可能有的人觉得很奇怪，怎么主观感受也可以作为产品质量的评估？因为负责功能模块测试的工程师是最了解他们的测试对象的。
旁观者说：可以设计一个信心指数，例如1～10，然后通过各种数据来支持这个指数。
软件发布之后做评估
第二，软件产品发布之后的质量评估。我们目前采用的度量指标是缺陷检测百分比DDP（Defect Detected Percentage），其计算公式如下：
客户现场发现的缺陷数 /（发布前测试团队发现的缺陷数 + 客户现场发现的缺陷数）* 100%
我们一般统计产品发布之后6个月内在客户现场发现的缺陷数。不同的公司与项目，采用的统计时间范围会有所不同。
旁观者说：统计客户发现的bug是有意义的，一是可以据此对客户做一些分析，例如，经常使用的功能、满意度等；二是可以用于反思之前的测试活动，以求改进。
测试团队为软件发布提供质量信息
还有一个问题是测试团队非常关心的：谁来决定软件产品的发布？从我的角度而言，我认为由测试团队决定软件产品是否发布是不合适的。
软件产品是否可以发布，需要有不同角色的成员参与进来，根据公司定义的判定准则进行评估，同时平衡产品质量、市场机会、产品战略以及成本等多个因素。测试团队在这个过程中主要的作用是尽量多地提供软件产品的质量信息、风险信息等，以帮助管理层做出是否发布的决定。任何一个单方面做决定都可能是不全面的。例如，测试人员觉得质量还不够好，发布有风险；但是市场机会要求我们发布，如果再等一段时间就会减弱市场机会，甚至丧失机会，这个时候就需要考虑哪个因素有更高的优先级。
旁观者说：赞同。软件发布与否应当综合各种因素来考虑，而不仅仅是某个角色说了算。
新人如何学习软件测试
蔡：对于软件测试的新手，包括刚进入这个行业的，也包括正在学习、准备进入的，你有什么建议和经验分享？
郑：对于软件测试的新手，假如希望在测试行业有所发展，根据我的经验可以从下面几个方面入手。
1、了解你的测试对象。你首先要知道软件产品是干什么的，其实现的主要功能是什么，其工作的基本原理和流程等。比如，我一直从事通信产品，除了产品本身的需求资料外，还花了大量的时间学习和钻研各种通信产品相关的国际标准和行业标准，例如路由协议、IPv6等。
2、多向有经验的人学习。在刚刚入门测试行业的时候，我们应该抱着向各位前辈学习的态度，通过各种形式向有经验的人员学习，例如，参加培训、个人交流等。根据测试的特点，学习主要从两个方面入手。
（1）我们应该积极参加项目团队中的领域知识培训和交流，也可以直接向系统人员和开发人员询问产品是如何工作的，具体如何实现等问题，以更快地熟悉和掌握产品知识。
（2）测试人员向测试团队中的前辈学习，包括他们在产品知识、测试过程、测试技术与方法等方面的经验。他们是测试新人学习的最直接的对象，看看他们是如何掌握产品知识的，如何快速有效地找到bug的。
3、多实践，不要怕失败。不管是测试领域的知识，还是测试技能，或者是测试思想和方法，测试新人都需要勇敢地去实践，许多经验、思想和收获来自于失败的经验教训。
旁观者说：如果真是要丢脸的话，越早越好，越晚越被动。
4、勤奋。在我的经验中，勤奋总是占有非常重要的地位。只要你设定的方向是正确的，想要达到目标，勤奋将是不可或缺的基础。特别是觉得自己在某方面基础不好，勤奋可以弥补这方面的不足，我当时入门软件测试就是这么走过来的。你看到有的人很牛，测试经验丰富，各方面都懂，那是表象，其实他（她）在背后花了很多时间，你在玩游戏、看电视的时候，他（她）在看书、总结、写文章。如果我们能够坚持，每天坚持，这样一段时间后你就会发现自己与以前大不相同了。
旁观者说：我很相信一句话：天道酬勤。
如何面对职业发展的迷茫
蔡：你对在软件测试行业工作了三五年的朋友有什么建议吗？有的朋友对我说，他觉得有些迷茫。
问自己三个问题
郑：在软件测试行业工作几年之后，免不了会产生各种不同的迷茫：软件测试有前途吗？软件测试有技术含量吗？将来是做技术还是做管理？我自己在2005年准备换工作的时候，就对是做技术呢，还是去找测试管理的职位有过迷茫。尽管现在已经选择技术方向很多年了，有时候还是会迷茫：测试技术真的能顺利走下去吗？
在面对这些迷茫的时候，我就会问自己：
（1）你喜欢做技术还是做管理？我喜欢做技术。
（2）你的目标是什么？我希望将来成为测试专家。
（3）目前的工作和活动能帮助你达成这个目标吗？是的。
旁观者说：简单直接的三个问题，就像程咬金的三板斧，蛮有威力的，你可以试试。
基于这些问题的内心回答，我会不断给自己加油，并鼓励自己继续往前走。我几乎每天都会反省自己当天的工作，有了哪些收获，有了什么总结，多少时间又被浪费了等。通过这样的形式，不断提升自己的信心，提高学习的效率和有效性。
旁观者说：能够做到每天反省和总结，不简单，值得学习。孔子说，吾三省吾身。或许可以这样说，无论做什么事情，比如锻炼、减肥、写日记、练字、学习等，如果能够坚持每天做，都了不起。
分享周围几个朋友在职业发展方面的例子
我与大家分享一下我对下面几个迷茫问题的建议。
1、到底是做技术还是做管理工作？希望读者可以从我前面的工作经历中得到一些启发：做自己喜欢做的事情，勤奋加坚持，你会发现你可以逐步走向成功，不管是做技术还是做管理。
2、软件测试有前途吗？这个问题应该是每个测试从业人员所关心的话题。假如大家因为这个问题而觉得迷茫，我和大家分享我周围几个朋友的例子，测试同样可以成就你的未来。
（1）以前公司的某个测试部门经理，现在是某公司重庆研究所的所长。测试的职业发展也可以是有高度的，而不是说测试经理就是测试人员的终极目标。
（2）以前公司的某位测试工程师，在2005年换工作的时候，找到的职位是产品经理。测试人员的优势是对软件产品的工作原理、工作环境与客户最关注什么等有充分的了解，因此产品经理是你可以努力的一个方向。
（3）以前公司的某位测试工程师，首先从事测试工作，在换工作的时候应聘了软件开发的工作，在第二次跳槽的时候选择了项目经理的职位。由于有明确的职业规划，在对测试与开发有了深入了解之后，再加上项目管理的知识、技能与经验，测试人员成为项目经理是可以的。
（4）另外，在我们周围有不少独立的测试专家、咨询师等，他们不断出书、写文章，参加各种大会做报告，受邀为公司开展企业咨询工作等，这同样是你可以选择的一条路。
旁观者说：他山之石，可以攻玉。上面几个例子虽然简单，但是仍有可借鉴的地方。
要懂得如何思考和分析
3、软件测试有技术含量吗？很多人都认为软件开发有技术含量，而软件测试就是点点鼠标，按照需求检查工作产品，所以没有什么技术含量。实际情况是这样吗？这让我想起了一个故事：某公司的发电机出现了故障，请了一位经验丰富的工程师进行维修，他在机器上东敲敲、西敲敲，在某个地方画了一个圈，将其中的一个线圈换掉后发电机就正常工作了。收取了1000美元的费用。公司老总觉得费用太贵，不就是换了一个线圈吗？维修工程师回答说：“换个线圈只要1美元，找到哪里的线圈更换需要999美元。”很多人只是看到了表象，测试人员坐在那里点点鼠标，提交了一个缺陷。但是技术含量不是测试人员点点鼠标，而是测试人员为什么点鼠标，鼠标点在哪里，要点几次，即测试人员是如何思考的、如何分析的。这才是人与人之间的最大不同，也是测试人员真正的价值所在。优秀的测试人员与平庸的测试人员之间的最大区别在于前者更懂得如何思考和分析。
旁观者说：努力成为专家型的人才，符合个人利益，也符合公司利益，双赢。
如何做好测试用例的设计
蔡：如何做好测试用例的设计呢？
郑：测试用例设计是每个测试从业人员最主要的测试活动之一。为了做好测试用例的设计，我们必须考虑下面几个因素。
明确参考输入
第一，做好测试用例设计，需要首先明确它有哪些参考输入。以我为例，我是做系统测试的，因此测试对象的需求规格说明是最主要的测试设计参考。但是实际面临的问题是需求常常不完善，因此纯粹依赖于需求规格说明肯定是不全面的。根据我的经验，下面的这些输入也应该经常考虑：用户需求、开发文档、标准与规范、测试经验知识库等。
测试经验知识库是测试人员以前做类似项目的测试经验、收集与分析的缺陷类型分类等，都是开展测试用例设计的基础。例如，我们的测试用例模板中的测试类型定义，除了参考ISO 9126质量模型 ，其中的重要输入就是以前项目的测试经验和缺陷分类分析。
旁观者说：有多少公司收集和存储了项目的历史数据？又是否做了分析和利用？
关注功能之间的交互
第二，做好测试用例设计，除了考虑被测对象功能之外，也需要关注被测功能与其他功能模块之间的交互。由于每个测试人员负责各自的功能模块，往往会导致整个测试对象不同功能模块之间的接口、相互作用和耦合等分析不够充分，而这些是影响测试对象质量的重要因素。例如，在我们当前的项目中，通用的交互测试点有主备倒换、内存使用、内存泄漏、CPU使用、数据备份/恢复、版本升级、系统重启等。
旁观者说：相对于开发人员来说，功能交互是测试人员的优势，我们要在这方面好好发挥。
采用合适的设计技术与方法
第三，有了测试用例设计的输入与交互分析之后，采用合适的测试用例设计技术与方法，有助于做好测试用例的分析。根据《软件测试设计》中提出的“问题驱动的软件测试设计”观点，可以从下面四个方面考虑进行测试设计，以解决测试设计中面临的问题。
1、挑战1：被测对象的逻辑组合和输入数据的组合是非常庞大的，而穷尽测试是不可能的。经典测试设计中的一些技术与方法，在保证测试覆盖率与质量的情况下，对减少测试用例的数目是非常有效的。例如，在项目测试中引入了“组合测试”技术。
2、挑战2：软件产品的不同利益相关者对产品的质量要求是不一样的，如何满足他们各自的质量要求？基于质量特性的测试设计有助于我们选择合适的质量特性。测试设计中要求100%的测试类型覆盖率，可以更好地满足不同利益相关者对质量的不同要求。
3、挑战3：测试时间与资源总是非常有限的，如何平衡测试时间、成本与质量之间的关系是每个测试人员都需要考虑的。基于风险的测试设计可以帮助我们有效地解决这个问题。例如，先给模块确定测试优先级，然后分析每个模块存在的主要风险，并按照不同风险级别开展测试设计活动，以尽快尽早发现严重程度高的缺陷。
4、挑战4：测试人员面对的需求经常是不完善的、经常变更的。除了前面提到的完善测试用例设计的参考输入之外，基于经验的测试设计也可以帮助测试人员在这种情况下做得更好。例如，根据以前发现的缺陷和用户现场反馈的缺陷，进行缺陷分类分析和评估。另一个策略是更多地采用探索性测试，更好地发挥测试人员的主观能动性与分析能力。
做好评审
第四，在测试用例设计过程中，发挥团队的力量分析和评审测试点，其得到的效率和有效性会更好。例如，通过在测试分析与设计过程中应用思维导图 工具，帮助我们拓宽测试思路，增加测试条目。测试团队的放射性思维可以很好地帮助我们提升测试用例设计的效率和有效性。
测试用例的颗粒度没有严格的标准，我的观点是只要它们满足测试目的，符合产品特点、开发特点和测试过程等要求，有助于我们更好地发现缺陷和开展测试活动，测试用例的颗粒度就是合适的。
如何做好测试用例的评审
蔡：测试用例的评审一直是个问题。如何做好评审呢？
郑：测试用例是测试人员最重要的输出之一，也是后续开展测试执行与评估的基础。评审应该是开发过程中比较有争议的关键域，现实中存在矛盾：不做评审，这又是一个强制活动；开展评审吧，效果很一般，甚至得不到有用的评审建议，浪费时间。
结合我自己在评审方面的经验教训，做好测试用例的评审，下面是我的几个建议。
合适的评审团人选
第一，选择合适的人参与测试用例评审。例如，我们在做测试用例评审的时候，强制参与的评审人员有该功能的系统人员（他定义具体的需求）、开发人员以及测试架构师等。每个人参与测试用例评审的关注点是不一样的，例如，测试架构师关注测试类型的覆盖率方面，而开发人员和系统人员关注测试用例是否覆盖业务场景与不同功能模块之间的交互等。另外，语法、拼写、排版等方面的问题应该关注，但不应该是评审的重点。
管理层的支持
第二，管理层的支持。有效的评审是需要时间与资源的。例如，在我们公司的火车开发模型下，针对测试用例的评审是强制的，而且定义了评审的入口准则与出口准则；而且在做项目计划的时候，测试用例评审作为一个重要的活动，也相应地进行了工作量的估算和时间进度安排，这些都需要管理层的支持。
做好准备
第三，评审人员的准备，这是有效评审的关键所在。例如，我们针对测试用例的评审，定义了评审检查表，包括：测试类型覆盖、系统需求覆盖、测试用例模板符合程度检查等，这有助于有效开展测试用例的评审，也可以集中评审的重点。
旁观者说：即使我们要求不了别人，至少可以要求自己，评审前做些准备。
宣传评审的价值
第四，让更多的人明白测试尽早介入（评审）的意义。很多时候，大家不愿意积极参与评审，除了时间和资源方面的原因，主要是大家对评审的优点没有直观的感觉和定量的数据。例如，提高质量、降低成本、加快进度与过程改进等。只有认可了这些优点，大家参与评审才能更加自觉、有效。
我举一个写作的例子。我与马均飞在写作《软件测试管理》与《软件测试设计》过程中，对书稿进行交叉评审。评审过程中的讨论与交流，不仅使得我们对写作内容有更多的理解并达成一致，而且可以使内容更加全面、完善。评审取得成功的主要因素包括：选择合适的评审人员、每个人准备充分、时间与资源有保证，特别是认识到评审对作品（产品）的重要意义！
（未完待续）