有关测试的思考（2）：开始项目测试以前的准备

 

最近终于有时间写些东西了。这篇博文虽然是此系列的第二篇文章，但是距离上一篇的时间已经快有两年的时间了。有人不禁会问，难道笔者真的忙到连写博文的时间都没有么？其实不是，问题在于写博文的目的。第一篇博文是应微软Test Guru Team（一个微软内部的Virtual Team，主要任务是推进Test Excellence）的要求所写，文章是写给中国区的SDET（Software Development Engineer in Test）看的，为了扩大影响中文版同时也发到了CSDN和51Testing的博客上，同类型的文章还有李和恒的“飞花摘叶还是重剑无锋”（顺便说一下，李和恒是我所敬仰的微软北京圈子里为数不多的测试大牛，此人思想深邃，洞察深刻，大才。其所写文章亦如此，只是略有晦涩，初读难解其中道理，深读后可得其妙）。所有这些文章都是经过十几稿review后方才定稿，着实花了不少心血。两年后的今天，team早已不复存在，team member也已天南地北，其中的两位仁兄已经定居美国…，写第二篇文章的目的其实只是觉得在微软四年半的测试经历确实有些感悟，希望与读者分享。

 

另外，文章中出现了中英文混编的状态，笔者在这里向各位读者表示抱歉。这样做的主要原因有二：一是很多名词真的是很难找到中文解释，比如review，Virtual Team等；二是有些词句即使翻译成中文，也很难表达其中意思或者看上去不舒服，比如Test Guru Team将变成“测试牛人组”，这种翻译估计读者和我都很难接受。由于这样的原因所以保留了英文，而非在这里炫耀英文，也希望读者能够谅解（真的不是周立波所说的那样=-） ）。以下言归正传：

 

作为《思考》系列的第二篇，我将讨论测试前的准备工作，即动手撰写test plan以及test design前的工作，包括：

·         了解Business Vision（BV）

·         理解已有产品。

·         理解产品的已有测试。

·         了解当前team以及process。

 

也许很多人看完这个list就要睡着了，但是事实上它真的很重要，甚至和test plan以及test design一样重要。但是它是测试人员/测试主管的必经心路历程，不可忽视。忽视它的后果是测试工作将失去方向，成为一场赌博，其后的test plan和test design的正确性和有效性将无法保证。

 

了解Business Vision （BV）：

了解BV是所有准备工作中最最重要的。因为它是：

·         测试工作的方向；

·         各项子工作排列优先级时的主要依据；

·         后期评价performance的重要依据。

BV是测试工作存在的根本，也就是老板为什么给你发工资的原因，偏离了BV的任何测试工作都是毫无意义的，相反符合BV的测试工作将是有价值的。另外，在一项测试工作中可能包含多项子工作项目，由于人员、资源和时间的限制，必须针对子工作项目进行优先级设定以便在紧急情况下将不重要的子工作项目延期甚至完全取消，而设定优先级时的依据就是BV。以下是不同优先级的含义：

·         P1：重要级，被设定为P1的子工作项目实现BV的必要部分，也就是说如果没有这部分功能，BV无法实现或者将受到严重影响，等于整个工作都没做。

·         P2：一般级，被设定为P2的子工作项目不是实现BV的必要部分，如果没有这部分功能，BV会在有些情况下受到影响，不属于完美实现BV，但是其结果可以接受。

·         P3：不重要级，被设定为P3的子工作项目和实现BV关系不大，如果没有这部分功能，BV基本不会受到影响或者影响很小。

 

例如，假设一款手机OS其BV是为中老年用户提供良好的用户体验，那么以下子工作项目将会被设定优先级如下：

子工作项目

1.  电话功能。

2.  短信功能。

3.  WAP上网功能。

4.  手机缺省字体比正常值大一倍。

5.  电话缺省音量大30%。

6.  MP3、MP4播放功能。

7.  闹钟功能。

 

设定

·         P1：1，4，5

·         P2：2 （这里不考虑没有短信功能手机过不了入网测试的问题：））

·         P3: 3，6，7

 

通常BV已经存在，测试人员\测试主管需要了解已经存在的BV，而不是去创造新的BV或者修改已有的BV，除非是在Brain Storm阶段。BV也是最case-by-case的，没有一定之规，以下所列的是一些常见的BV：

·         满足客户需求：如果一项软件开发任务直接或者间接的来源于客户需求，（换句话说就是有人拿钱等着买这个软件，或者已经付了钱等着拿软件），而且开价又足够大，那么满足客户需求就成为BV。客户又可以分为定制客户和市场客户：定制客户通常是大公司、大客户，需求来自客户本身；市场客户通常是普通用户，数量庞大，不可能直接一一沟通，需求来自针对客户的市场调研。通常这样BV所指明的工作方向是很容易把握的，就是客户要什么就做什么，优先级也很容易设定，那就是——问客户。难点仅存在于有效持续的沟通和DCR（Design Change Requirement）的控制。

·         战略合作需求：某种意义上说来自战略合作伙伴的需求也是一种定制客户需求，不同之处在于战略合作伙伴既是你的客户也是最终用户的生产者。例如，Dell对于Microsoft来说就是战略合作伙伴，如果Dell要求将其使用的几款显卡驱动放入新款Windows的缺省显卡驱动列表中，那么这就是一个战略合作需求，因为帮助Dell就是帮助Microsoft自己，Dell每卖出一台PC都要向Microsoft支付使用费，Dell卖得越好Microsoft就盈利越多。然而对于最终用户而言，Dell和Microsoft又都是生产者。对于这样的BV，确定工作方向将变得复杂，因为事实上有两个方向，一个是最终用户的需求，另一个是战略合作伙伴的需求，而且在双方没有达成战略共识并且沟通不畅的情况下，通常这两个工作方向不同。测试人员\测试主管不能接受的情况是两个方向是矛盾的、不相容的，当然最糟糕的情况是南辕北辙。例如，合作伙伴需要增加某一功能，并且该功能预期会带来性能下降，而最终用户希望提高性能。在这种情况下只能通过沟通消除矛盾，如果其在项目开始前不能解决，那么该项目将面临重大风险。优先级的设定也是一样，需要沟通。

·         复制竞争对手的成功，蚕食市场份额：一般适用于大公司在后发领域中用于与对手竞争蚕食市场份额时使用。这种BV战略的灵魂就是“走别人的路，让别人无路可走”（出自小沈阳语录：） ）。Microsoft大量地使用了这种BV，比如在Xbox、Windows Mobile Phone、搜索引擎等产品上。这种BV有别于以上BV在于其强调产品与竞争对手产品相比：一，有哪些差距；二，哪里能做得比对手产品好。这时来自于客户的需求反而没有那么重要（注意，我不是说客户需求不重要）。对于测试人员必须首先熟悉竞争对手的产品，同时了解自身产品相对于竞争对手产品的差距，或者哪些地方能做得更好，然后根据这两点确定工作方向和设定优先级。

·         辅助相关产品：一般适用于大公司，在一个产品线中某个或某些产品本身并不大赚钱，有时甚至是赔钱的，但是它的存在将有效增大产品线上其他产品的销售，或者保护了其他产品的现有市场份额。这样的BV较难把握，需要对整个产品线的各个产品、相互关系、客户需求和企业商业战略有全盘理解，然后确定工作方向和设定优先级。

·         适应未来的技术趋势：一般适用于大公司，产品是为未来2~5年的市场准备的，在某种程度上是赌博，其前期投资很大而且没有或者很少的客户需求。比如现在的云计算、两年前的iPhone等等。这样的BV是最难把握的，因为基本没有客户需求可以供参考，工作方向很难确定，优先级设定则更加困难。

 

理解已有产品：

大多数情况下测试人员\测试主管所面对的产品不是Version One的产品，即项目将在已有产品上展开，那么对已有产品的理解就十分重要。测试是要保证N+1的所有功能（N个是已有产品的功能，1是新加功能）都正常工作，而不仅仅是保证新加功能正常。通常，测试人员\测试主管需要了解：

·         产品的功能以及各个产品的历史；

·         使用产品的典型客户和典型应用场景；

·         产品的特殊要求；

·         法律对于某些产品的特殊要求；

·         当前产品的Pain Points；

·         主要竞争对手产品、其优势和劣势。

 

理解产品的已有测试：

在对已有产品有所理解后，还应当理解已有产品的已有测试。针对已有测试的理解将有助于为新项目建立完善的测试体系，形成回归测试，是保证N部分功能在新版本中正常工作的重要手段；另外，已有测试中的Test Infrastructure是测试中可以重用的部分（Test Infrastructure就是除了Test Case以外的测试代码，包括Test Harness，Test Management System等等）。其包括：

·         功能测试；

·         稳定性测试；

·         性能测试；

·         场景测试；

·         Test Infrastructure。

 

熟悉当前Team以及Process：

最后要准备的就是熟悉Team和Process。核心就是要了解Team中的Key Person和Key Process，以帮助日后开展工作。

·         项目的实际决策层；

·         项目开发人员；

·         项目组中的Expertise；

·         相关的其他开发组；

·         Development Process；

·         Test Process；

·         Bug Process；

 

 

 

 

我在微软亚洲工程院从事测试工作已经有两年了。两年间走了很多弯路，但也学习了很多无法从书本上知道的知识，有了一些关于测试的思考和心得，于是打算写出来与大家一起分享。这次我想谈论的话题是：是什么在决定着软件测试的设计与决策？

测试新手的困惑

读研的时候，我曾经读过一些有关测试的书籍（也许有些人会觉得我奇怪，因为大多数CS和EE身的人都更喜欢做开发，而通常会把测试当作“第二志愿”或者根本不予考虑）。但是到了微软以后，我却发现真正的测试工作与那些书上所写的内容总是有些差别。这种差别总是让人感到很茫然，甚至泄气，因为它会影响我们做决策时的信心。特别是被老板或者老资格的员工challenge时，这种缺乏信心的表现就会更加明显。下面举两个典型的有关实际与书本的差别的例子：

·         很多测试理论都指出，编写详细而完整的测试文档是测试设计与实现的第一步，也是最重要的一步。通常要求每个测试用例都要有详细的测试用例文档。而实际工作中的测试文档则相对简单了许多，有时只是包括测试用例名称的列表，没有详细的针对测试用例的描述。而与此同时，所有的测试都要求实现自动化，所有的测试用例都包含在测试程序中，而在很多测试理论中，自动化测试只是一种辅助的测试手段，并不是必须的。如果按照一般的测试理论，新手在工作计划中规划很长时间用于编写测试文档，而同时又忽略了测试自动化，那么这个工作计划将很难被认可并通过。

·         大多数测试理论都很少对压力测试有太多的论述，从我的理解看来似乎压力测试并不是一种非常重要的测试。而实际工作中，压力测试是仅次于功能测试的一种测试，通常说来程序在经过基本的功能测试并达到一定的测试通过率以后，压力测试便会开始（在此之前压力测试程序必须准备就绪），并且持续不断一直到程序被发布。如果按照一般的测试理论，新手没有给予压力测试足够的重视，或者在时间的安排上过于靠后，那么这个工作计划也将很难被认可并通过。

不仅如此，不同的测试小组之间对同一种测试的设计和实现通常也会有些许的出入，比如：

·         在有些测试小组内，性能测试被当作一项非常重要的测试；而在其他的测试小组内，性能测试只在每个milestone的结尾才会手动的运行一次。

这些现象都令人非常困惑。我时常会问自己这样一个问题：

如果有一天我领导一个测试小组接手一个新的产品项目，或者在已有的产品上增加新的功能，我应该如何设计实现针对这个产品的测试？在有争议的问题上我又应该依据什么做出决策？显然，这个时候照搬书本上的或者其他测试小组的best practice是有一定危险的。

其实，这个问题的实质就是要回答“是什么在决定着软件测试的设计与决策”。

软件测试背后的那只无形的手 – 商业利益与商业效率

针对这个问题，我一直在思索，都没有得到满意的答案。直到有一次我去美国总部出差，在那里我通过和美国总部的同事交谈，得到了答案：

决定测试的设计与决策的是其背后的商业利益和商业效率的考量。

简单的说，就是测试工作的投入和产出决定了测试的设计与决策。

·         测试的商业利益 = 测试的产出 – 测试的投入

·         测试的商业效率 = 测试的商业利益 ÷ 测试的投入 × 100%

为了形象的解释这个观点，首先把我们自己想象成一个软件公司的CEO，在俯视公司全景的同时，思考这样两个问题：

·         公司为什么要雇佣大量的软件测试工程师，并且人数逐年递增？

·         公司为什么每年要为测试部门提供大笔的预算，并且还逐年追加投入？

原因只有一个，那就是与对测试部门的投入相比，测试部门能够减少费用支出或者避免损失。当然，从另一个角度想这其实就是在创造价值，就是测试的产出，而且这个产出一定要高于对测试部门的投入，并且其商业效率应该不低于软件投资的平均资产增值率。否则，我们将有理由直接将测试部门从公司的部门列表中删掉，并省下这笔投入。

所以，说测试能够保证软件的质量也好，说测试能够提高客户满意度也好，其实这些都是测试在整个软件商业链条中的一种价值的体现，但并不是软件测试存在的根本原因。如果测试的商业利益是负的，或者测试的商业效率低于平均的软件投资的平均资产增值率，那么这样质量应该没有哪个软件企业愿意去保证，这样的客户满意度也没有哪个企业愿意去提高。

真实的测试案例

以下是几个真实的测试设计与决策的案例。一年前，我到美国总部的测试实验室去了解那里是如何在Windows Mobile和CE上测试射频驱动程序（此驱动程序用于驱动手机或嵌入式设备上的射频电话模块）的。在那里我得到了对这些案例的正确解读。

自动化测试VS完备文档。

在实验室中，我见到了我所见过的最大的自动化测试系统。所有的功能测试都是通过这种自动化系统完成的。系统由数量巨大的测试设备和中心测试驱动服务器组成，测试人员只要通过远程的客户端安排自动化测试任务并将之提交到中心测试驱动服务器上即可，其余的工作将由中心测试驱动服务器完成。这个过程包括搜索处于空闲状态的测试设备，启动并控制测试设备，并在测试完成后收集日志数据信息和计算测试通过率。

这时，我突然想到了我先前的疑惑——为什么与编写完备的测试文档相比，我们在实际工作中更看重测试的自动化？我的美国同事给我的回答是：运行成本的原因。编写完备的测试文档自然是能够帮助测试小组完整的记录所有的测试用例，但是对于一个在操作系统上起着重要作用的驱动程序而言，每周两次的回归测试是才是保证驱动程序质量的根本手段。可以想象，如果没有自动化测试，而是依据文档中的测试用例，这种频繁的回归测试将会消耗多少人力物力。而与此同时，自动化的测试程序和用例使用统一的测试框架，并且辅助以相当的注释，这样测试程序和用例的代码本身已经能够很好的说明测试用例的详细信息，所以在文档中便不再需要重复的详细信息了。

庞大到不可思议的压力测试系统。

在实验室中，我见到了我所见过的最大的压力测试系统。这个系统整整摆满了三排铁架子，几乎占了整个实验室的四分之一的位置。架子上除了几台用于日志数据分析的服务器以外，剩下的全都是各种各样的手机或者嵌入式系统。架子上没有测试驱动服务器，因为测试驱动服务是通过网络由中心测试驱动服务器提供的，这种服务是所有测试系统共享的。这些设备自动化的从中心测试驱动服务器得到压力测试用例集，并自动运行13小时左右的压力测试，与此同步的是产生的日志数据将通过中心测试驱动服务器传输给日志分析服务器用于错误分析。当测试结束或者有不可恢复的程序错误或者系统错误出现时，测试设备将停止测试，并由中心测试驱动服务器扑捉这种事件，在经过适当的记录和处理后测试设备将被重置，并且准备进行下一次压力测试。这样庞大的压力测试系统令我产生了疑问——为什么我们需要如此大力度的压力测试？花费如此多的人力物力是否值得？

我从美国同事那里得到的答案是这样的。其实开始的时候并没有这样庞大的压力测试系统。和许多其他项目的压力测试类似，针对射频驱动程序的压力测试也只是在一两种嵌入式系统上进行，而且根本没有手机参与其中。但是，从后来的用户反馈中发现，在很多手机和嵌入式系统上都存在着长时间反复使用电话功能后电话短信功能失灵的现象，而在已有的压力测试过程中并没有发现类似的问题。来自OEM的压力越来越大，OEM的反馈表明这个问题增加了他们通过入网测试时的难度，使得研发成本增加了很多，与此同时，客户服务部门也在抱怨此类问题加重了他们的日常工作。问题已经变得很严重了，于是这个测试小组做了一个决定，扩大压力测试的范围、频度和力度。从此，很多手机和嵌入式系统就逐步的加入了这个压力测试系统。另外，原先的系统中是没有日志数据分析服务器的，但是随着测试设备的日益增多，在海量的日志数据中捕捉出错信息的工作也变得越来越繁重，测试小组无法再提供更多的人力用于分析这些日志数据。于是又有人提议架设一台能够用于分析日志数据的服务器，程序由测试开发工程师设计和编写，并负责日常维护。后来，随着测试设备的继续增加，一台服务器不能满足其要求了，于是又增加了几台，直到今天的规模。在这个系统投入测试后的一段时间内，很多非常难于发现的bug浮出了水面，在修正了这些bug后先前提到的问题就基本绝迹了。

很明显，建立如此庞大的压力测试系统的真正原因是OEM和客户服务部门由于驱动程序稳定性差而产生的巨大费用造成的。从测试原理本身或者测试小组对于产品质量的理解出发并不能支持建立这样大的压力测试系统，所以说这个测试系统是商业利益驱动的。

 

非常简单的性能测试。

在实验室中另一个让我感到惊奇的是实验室中没有用于测试射频驱动程序性能的任何设备，而就在这个实验室的另外两个架子上却摆满了用于测试另一个模块的性能测试系统。这在驱动程序的测试实践中实在是不多见的。很难想象，一个驱动程序没有自动化的性能测试系统对其进行测试。

对于这个问题，美国同事的解释是：的确没有自动化的性能测试系统，但是性能测试在每个milestone结束时会由测试小组中的一名测试开发工程师手动完成。如此处理的主要原因是，从以往的测试数据看来，驱动程序不是其所在的功能调用栈中的性能瓶颈，并且射频驱动程序的性能明显比瓶颈的性能高很多。所以在没有很大的结构变动的情况下，性能通常不会成为严重影响程序质量的因素，所以性能测试就如此简单了。当然，如果射频驱动程序是整个功能调用栈的性能瓶颈的话，结果就会大不相同了。

很明显，简化性能测试的真正原因是对非瓶颈模块的性能测试和优化不会对功能调用栈整体的性能产生贡献，当然这样的投入也几乎不会有大的商业价值的产出，所以，简化性能测试并维持一个最基本的性能测试便是最佳的选择。

其实，从更高的角度观察，整个软件产业都是商业性的，所以作为其重要组成部分的软件测试也必然带有商业性，但这恰恰是不容易发现的。