@import url(http://www.blogjava.net/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

　　把握软件的质量 《转载》

　　蔡：如何把握软件产品的质量？

　　郑：不管软件产品规模是大还是小，结构是简单还是复杂，对它们质量的评估都不是一件容易的事情。尽管很难，但是产品质量的评估仍然是必需的，因为它也涉及软件版本是否能够发布。

　　软件发布之前做评估

　　根据我和公司内的实践经验，可以从下面两个方面进行评估。

　　第一，软件产品发布之前的质量评估，具体的度量指标包括：

　　缺陷，包括发现的总的缺陷分布趋势、缺陷在不同功能模块中的分布等。例如，总的缺陷分布趋势图。

　　测试通过率，主要包括计划的测试用例执行进度、通过的测试用例数目、失败的测试用例数目、被阻塞的测试用例数目等。我们项目中定义的测试通过率是95%。

　　测试覆盖率，包括测试对系统需求的覆盖率、对测试类型的覆盖率。例如，我们项目中定义的需求覆盖率必须达到100%，测试类型覆盖率也必须达到100%。

　　信心，负责这个模块的测试人员对质量的主观感受。可能有的人觉得很奇怪，怎么主观感受也可以作为产品质量的评估？因为负责功能模块测试的工程师是最了解他们的测试对象的。

　　旁观者说：可以设计一个信心指数，例如1～10，然后通过各种数据来支持这个指数。

　　软件发布之后做评估

　　第二，软件产品发布之后的质量评估。我们目前采用的度量指标是缺陷检测百分比DDP（Defect Detected Percentage），其计算公式如下：

　　客户现场发现的缺陷数 /（发布前测试团队发现的缺陷数 + 客户现场发现的缺陷数）* 100%

　　我们一般统计产品发布之后6个月内在客户现场发现的缺陷数。不同的公司与项目，采用的统计时间范围会有所不同。

　　旁观者说：统计客户发现的bug是有意义的，一是可以据此对客户做一些分析，例如，经常使用的功能、满意度等；二是可以用于反思之前的测试活动，以求改进。

　　测试团队为软件发布提供质量信息

　　还有一个问题是测试团队非常关心的：谁来决定软件产品的发布？从我的角度而言，我认为由测试团队决定软件产品是否发布是不合适的。

　　软件产品是否可以发布，需要有不同角色的成员参与进来，根据公司定义的判定准则进行评估，同时平衡产品质量、市场机会、产品战略以及成本等多个因素。测试团队在这个过程中主要的作用是尽量多地提供软件产品的质量信息、风险信息等，以帮助管理层做出是否发布的决定。任何一个单方面做决定都可能是不全面的。例如，测试人员觉得质量还不够好，发布有风险；但是市场机会要求我们发布，如果再等一段时间就会减弱市场机会，甚至丧失机会，这个时候就需要考虑哪个因素有更高的优先级。

　　旁观者说：赞同。软件发布与否应当综合各种因素来考虑，而不仅仅是某个角色说了算。

　　新人如何学习软件测试

　　蔡：对于软件测试的新手，包括刚进入这个行业的，也包括正在学习、准备进入的，你有什么建议和经验分享？

　　郑：对于软件测试的新手，假如希望在测试行业有所发展，根据我的经验可以从下面几个方面入手。

　　1、了解你的测试对象。你首先要知道软件产品是干什么的，其实现的主要功能是什么，其工作的基本原理和流程等。比如，我一直从事通信产品，除了产品本身的需求资料外，还花了大量的时间学习和钻研各种通信产品相关的国际标准和行业标准，例如路由协议、IPv6等。

　　2、多向有经验的人学习。在刚刚入门测试行业的时候，我们应该抱着向各位前辈学习的态度，通过各种形式向有经验的人员学习，例如，参加培训、个人交流等。根据测试的特点，学习主要从两个方面入手。

　　（1）我们应该积极参加项目团队中的领域知识培训和交流，也可以直接向系统人员和开发人员询问产品是如何工作的，具体如何实现等问题，以更快地熟悉和掌握产品知识

去管人还是坚持做技术

　　在上海贝尔-阿尔卡特，我当时的目标是去做经理，简单地讲，就是去管人。周围的氛围大抵如此，大家基本都认为管人的经理有地位、有能力，当然也有面子。其间我曾经去UT-斯达康面试过，目标职位是项目经理。所有的面试流程都通过了，但是这个职位因为各种原因最终被取消了，我没有去成。这件事情让我深思，我问自己：自己真的喜欢做项目管理工作吗？自己真的适合做项目经理吗？是自己喜欢还是活在其他人的期望之中？深思和反省了一段时间之后，发觉自己并不是真的喜欢项目经理这样的职位，更多的是由于人家觉得这样是好的。经过这次反思，我给自己重新做了一个定位：发挥自己在测试领域的专长与经验，继续自己的软件测试技术之路。

　　旁观者说：做自己，而不是生活在别人的期望中。

　　上海贝尔-阿尔卡特是一家不错的公司，我在其中的几年最大的收获是：深入了解了软件开发流程、测试流程与项目管理方面的知识。这也是合格测试人员需要具备的技能。除了了解你的测试对象之外，你需要深入了解软件产品是如何开发出来的，开发与测试之间的关系是什么，主要的测试活动与测试任务，等等。

　　由于办公场所在浦东，离家太远，每天往返上下班需要2到3个小时。虽然公司有班车，但是每天在路上花费的时间太多。在2006年的时候，我犹豫、徘徊了很久，最终决定到离家更近的朗讯科技光网络有限公司，继续做我喜欢的软件测试工作。这样，我也可以更好地平衡工作与生活。

　　旁观者说：一个人最珍贵的资源是什么？时间。

　　在朗讯我做了2年多的测试管理职位，带领一个测试团队。在朗讯工作2年多后，也就是2008年年底，我主动向公司申请，转做测试技术岗位。我感觉自己的个人兴趣还是在技术上，我想专注在软件测试过程和测试能力改进等领域上，这样从管理岗位转到技术岗位有利于自己的发展，有更多的时间和精力去做自己想做的事情。

　　旁观者说：能够看清自己的兴趣在哪里，看清自己擅长的在什么地方，真是幸事。

　　研究测试技术和方法

　　在朗讯公司内部，完成测试任务之后，我将其他时间与精力放在了测试技术与方法的研究上面，提出了一些解决方案来不断提高团队内部的测试能力。例如，在测试用例设计与执行中引入了测试类型的概念；根据敏捷开发的特点，在测试团队中提出并引入了Pair Testing（结对测试 ）的概念；在测试用例设计中提出了"精简化的测试用例"的概念；在测试用例设计中提出了放射性思维，使得测试用例编写的工作量与测试人员创造性思维方面得到了很好的平衡。

　　旁观者说：提出新概念是一种创新，当然这不容易做到。

　　同时，我开始在公司内部更广泛地参与测试相关的活动。2011年和2012年分别参加了公司中国区第一届和第二届技术大会，并做了主题演讲。积极参与公司内部的软件测试社区建设，并在公司内部推广测试知识、测试技术与方法、测试管理等方面的培训与分享。现在非常明显地感觉到公司对软件测试的重视程度在不断提高。

　　到现在为止，我在朗讯的工作时间已经有7年了，在软件测试方面给我最大的体会是：不管多好的测试理念、测试技术与方法，我们都需要和实际测试工作结合起来，不断提高测试效率和有效性，不断提升测试质量。这是合格的测试人员需要具备的技能。

　　旁观者说：让理论经过实践的检验，落地，形成适合自己公司和团队的做法和经验。

　　我在测试行业工作已经超过11年了，我感觉是在更深入地了解测试的内涵，更愿意将当前的状态看做是超越自己的一个起点。坚持去做自己喜欢的工作，不断积累、总结和分享，相信每个人都可以成为领域内的专家。

　　旁观者说：11年的积累，仍然看做是一个新的起点，值得学习。

　　跳槽时要考虑自己的兴趣爱好

　　蔡：一个人跳槽的时候要有哪些方面的考虑呢？

　　郑：首先，从大的方向而言，我不鼓励经常跳槽，特别是在没有职业规划的情况下，仅仅因为待遇、人际关系等原因而匆匆下决定的跳槽。从个人的发展机会而言，在一个公司待的时间久了，可以获得更多的机会，俗话说"伟大是熬出来的"。当然行业也很重要，要注意自己知识和技能的持续积累。假如真的决定要跳槽，那么下面几个方面需要仔细考虑。

　　旁观者说：跳槽会有新的机会，同时也会付出代价。在做决定的时候，要看到两面。

　　第一，跳槽要考虑自己的兴趣爱好。做自己喜欢做的事情，尽管钱也很重要，但是为了涨一些钱就跳槽，甚至为此去做自己并不真正喜欢的工作，并不见得是一个明智的选择，同时很难一直坚持下去。我自己就是一个例子，在2005年准备换工作的时候，我心仪的职位是项目经理，感觉特有面子和地位。但在求职失败之后，我重新审视了自己：去做自己喜欢的，还是去做人家喜欢的？最终我选择了前者。从目前的结果看，感觉到自己在公司内部可以做的事情更多了，参与的活动也在增加。不管对公司还是对个人，体现的价值都是在不断增加的。

　　旁观者说：在公司里工作，我们难免会被安排，而不一定都遂人愿，但是在发展的大方向上，还是要自己定。

　　第二，如果兴趣爱好能和自己的优点结合起来，那么跳槽就会更加理性。认识自己的优缺点实际上是挺困难的一件事情，"当局者迷，旁观者清"。还是以我自己为例，我的优点是勤奋、专注于技术能力。因此我更适合有条理地工作，自己计划和控制时间完成每一件事情，而不太适合每天参与各种会议、讨论与协调工作。所以，从这个层面而言，我更适合去做测试技术方面的工作，而不是测试管理工作。假如你认定自己的性格并不适合做管理工作，那就不要强求，否则不仅自己痛苦，整个团队也痛苦。

　　旁观者说：去认识自己的优缺点。一个人要想认清自己其实并不容易。

　　第三，跳槽需要和自己的职业规划相一致，不要乱了方向。假如有了明确的职业规划，清楚实现职业发展需要具备哪些方面的技能，那么在跳槽的时候就会考虑如何更快地掌握这些技能。记得我在中兴通讯上海第一研究所的一位同事，原来是做测试工作的，但是其职业规划是做项目经理。项目经理不仅需要了解测试工作，而且需要了解整个软件开发流程和管理工作。因此，除了平时积极学习项目管理方面的知识外，他在第一次跳槽的时候，找到了一个软件开发的职位，目的就是为了获取软件开发的实际经验，待遇方面考虑得比较少。在软件开发方向工作3年以后，他再次跳槽，如愿以偿地得到了某个公司项目经理的职位。由于他不仅了解开发工作，而且了解测试，同时这一结果又符合自己的职业规划，因此目前他的工作状态是非常有激情，这对公司、对个人都是一个不错的结果。

　　旁观者说：目的非常明确的职业发展路线，值得学习。

　　第四，在考虑跳槽的时候，也需要考虑公司的企业文化、团队氛围、个人在公司内的发展空间等，例如，公司离家是否方便，公司是否经常加班，公司是否等级森严，公司是否鼓励员工个性化发展等

 

（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：测试人员面对的需求经常是不完善的、经常变更的。除了前面提到的完善测试用例设计的参考输入之外，基于经验的测试设计也可以帮助测试人员在这种情况下做得更好。例如，根据以前发现的缺陷和用户现场反馈的缺陷，进行缺陷分类分析和评估。另一个策略是更多地采用探索性测试，更好地发挥测试人员的主观能动性与分析能力

做好评审

　　第四，在测试用例设计过程中，发挥团队的力量分析和评审测试点，其得到的效率和有效性会更好。例如，通过在测试分析与设计过程中应用思维导图 工具，帮助我们拓宽测试思路，增加测试条目。测试团队的放射性思维可以很好地帮助我们提升测试用例设计的效率和有效性。

　　测试用例的颗粒度没有严格的标准，我的观点是只要它们满足测试目的，符合产品特点、开发特点和测试过程等要求，有助于我们更好地发现缺陷和开展测试活动，测试用例的颗粒度就是合适的。

　　如何做好测试用例的评审

　　蔡：测试用例的评审一直是个问题。如何做好评审呢？

　　郑：测试用例是测试人员最重要的输出之一，也是后续开展测试执行与评估的基础。评审应该是开发过程中比较有争议的关键域，现实中存在矛盾：不做评审，这又是一个强制活动；开展评审吧，效果很一般，甚至得不到有用的评审建议，浪费时间。

　　结合我自己在评审方面的经验教训，做好测试用例的评审，下面是我的几个建议。

　　合适的评审团人选

　　第一，选择合适的人参与测试用例评审。例如，我们在做测试用例评审的时候，强制参与的评审人员有该功能的系统人员（他定义具体的需求）、开发人员以及测试架构师等。每个人参与测试用例评审的关注点是不一样的，例如，测试架构师关注测试类型的覆盖率方面，而开发人员和系统人员关注测试用例是否覆盖业务场景与不同功能模块之间的交互等。另外，语法、拼写、排版等方面的问题应该关注，但不应该是评审的重点。

　　管理层的支持

　　第二，管理层的支持。有效的评审是需要时间与资源的。例如，在我们公司的火车开发模型下，针对测试用例的评审是强制的，而且定义了评审的入口准则与出口准则；而且在做项目计划的时候，测试用例评审作为一个重要的活动，也相应地进行了工作量的估算和时间进度安排，这些都需要管理层的支持。

　　做好准备

　　第三，评审人员的准备，这是有效评审的关键所在。例如，我们针对测试用例的评审，定义了评审检查表，包括：测试类型覆盖、系统需求覆盖、测试用例模板符合程度检查等，这有助于有效开展测试用例的评审，也可以集中评审的重点。

　　旁观者说：即使我们要求不了别人，至少可以要求自己，评审前做些准备。

　　宣传评审的价值

　　第四，让更多的人明白测试尽早介入（评审）的意义。很多时候，大家不愿意积极参与评审，除了时间和资源方面的原因，主要是大家对评审的优点没有直观的感觉和定量的数据。例如，提高质量、降低成本、加快进度与过程改进等。只有认可了这些优点，大家参与评审才能更加自觉、有效。

　　我举一个写作的例子。我与马均飞在写作《软件测试管理》与《软件测试设计》过程中，对书稿进行交叉评审。评审过程中的讨论与交流，不仅使得我们对写作内容有更多的理解并达成一致，而且可以使内容更加全面、完善。评审取得成功的主要因素包括：选择合适的评审人员、每个人准备充分、时间与资源有保证，特别是认识到评审对作品（产品）的重要意义！

天猫 软件自动化测试开发