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

有关测试的思考（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；