计划测试系列

（三）——人

在本系列文章中的第一篇，笔者就提到了计划的实质是“特定的人在特定的时间在特定的地方做了特定的事情以实现特定的目标”,在上一篇文章的回复中，土豆老粗回复了对于测试计划的看法，也就是5W1H定义：
> WHY：为什么要写测试计划；
> WHAT：测试什么；
> WHEN：测试不同阶段的起止时间；
> WHERE：文档放哪；
> WHO：哪些人去做；
> HOW：怎么测试；

这个定义相对于我的来说，对于测试计划定义得更加详细。不过，正像笔者在博客签名中所宣称的那样：来自草根的实用主义。因此，5w1h定义就不适合三五个人十来杆抢的软件作坊了。对于很多刚刚起步测试活动（近两年才拥有“专门测试人员”，注意是“专门”而不一定是“专业”）的公司来讲——而这种公司，就笔者接触的一些同仁口中所述，在中国还不在少数——或许一些简化版的东西会更适合现在的他们，等到渐渐成长起来，我们才逐渐步入正轨。本文中笔者继续自己的草根实用主义，分享自己的关于计划测试活动中人的一些拙见。

这阵子软件相关论坛上都多多少少有人提到了工具与人的关系，在笔者看来这是一个很扯淡的问题，人的作用是不可能被工具取代的，人之所以为人而不是跟其他动物一样处于原始的生存状态，是因为人会“使用”工具。不过关于人和工具的那点儿事，则是后话了。

中国有句老话“养兵千日，用在一时”。这句话往往是在临战的时候将军（测试负责人）对战士（普通测试人员）说的。中国古代还有一个方法叫做“战时兵闲时农”的策略，即我们广大的劳动人民在没有战争的时候安心种我们的地，一旦战争爆发或者国家需要的时候我们就披上盔甲去作战。这两句话给我们一个提示：我们应该培养我们的测试人员或者说我们的测试队伍。

先拿“养兵千日用在一时”来讲，正如我上面提到的，往往在临战的时候大家才想起这句话，可是我们不妨倒过来想一想，一时的用是需要千日的积累的。这也是在提示我们，一支优秀的测试队伍的每个人都应该是优秀的并且我们需要在“用一时”之前好好“养千日”。这种积累不是一天两天可以形成的，正所谓冰冻三尺非一日之寒。为什么要在谈论计划测试的时候谈论这个问题呢？原因在于“巧妇难为无米之炊”，我们在做计划的时候如果发现没有一个可用之才，那我们的计划怕是做不下去了，或者我们只有准备另外招新人到行伍中间来，亦或者只能外包测试给专业队伍，这无疑又增加了项目的风险，因为新人或者其他队伍使我们不了解的，他们会做成什么样子只有老天知道，当我们把命运交给老天的时候，这相当于在玩火。我们需要把“养千日兵”拉到我们的计划中来，从更加长远的角度来计划一下我们的测试工作，测试方向等等。对于人才的培养，一般使用的是人尽其才的分工制度，即某一个或者一些人熟练掌握某一些测试技能，并对其他技能有所了解，最理想的情况下，我们在测试的方向（或者说是本公司主要的开发方向相关联的各个测试技术方面）都有“专家”，这样才可以保证一个测试队伍可以应付不可预知的测试任务。

对于草根一族来讲，一开始公司很可能就你一个测试人员，有几种情况：

> 公司将“建立一支专业的软件（测试）队伍”的艰巨任务寄托在你身上时，先不要沾沾自喜袭击已经被boss重视了；

> 公司只是拿你来标榜自己拥有了测试，拿你来写测试计划，测试报告等提交给客户看的文档的专业测试——文档——人员

上面两种是比较常见的情况，在笔者看来，这两种情况都很好创造了给你学习的机会，第一种情况你可以打着公司的“建立一支专业的软件（测试）队伍”旗号学习；第二种情况来讲，如果仅仅是写文档的话，那剩余的时间就可以好好利用下来了，而目的在于你想提高自己的技能。而我们的学习方向，笔者大概归纳一下：

> 测试理论（包括测试基本概念，流程，管理等等内容。对于测试来讲，这才是基本）

> 测试文档 （虽然网络上的文档中的内容对于目前的你来说不可能完全有用，但是知道一份专业或者说完整的文档是怎么写的也是必要的）

> 测试工具（对于刚起步的测试人员，如果你不是开发大牛，建议你还是先使用别人已经写好的工具）

> 开发知识 （有则加之，无则添之，总是是要学，因为这一点是为将来打算，这些知识有助于我们更好地测试）

笔者在文章开头提到了人与工具的问题。现在各种各样的测试工具很多，有关于性能的测试工具，有关于功能自动化的测试工具等等。不过昨天看到一篇博文，博文作者深感当前几乎所有人讨论的问题都是测试工具怎么用，而关于测试工具开发相关的帖子却很少，笔者也认为这是一个不正常的现象。的确，对于大多数软件项目组来讲，自己开发一个性能测试工具并不是一个现实的想法，又鉴于性能测试的重要性，在测试组中拥有掌握主流性能测试工具的专家是很迫切的需求。如果可以的话，我们拥有自动化测试工具的专家，我们拥有自动化测试工具自主开发的专家等等这些都是很有用的。不过这些专家的培养的顺序也要顺势而行，不仅急不得而且也急不了。

当一个优秀的测试团队成立起来之后，“米”的问题就解决了，这个时候再来针对某一个具体的项目考虑怎样“炊”的问题就简单很多了。简单，并不代表可以不费吹灰之力就可以把事情摆平了。要知道，人是一个复杂的动物，人的心情会有阴晴圆缺，人会有喜怒哀乐，关于这些跟技术不搭调的问题笔者就不扯了，毕竟笔者的人生阅历还没有精彩到可以教读者怎么做人的地步~关于计划测试中人有关的话题，在本系列的后续文章中会结合“特定的事”“特定的时间”等等继续探讨。

（四）——地

正所谓，天时地利人和，前面的一片里面笔者花费了大堆口水在“用兵一时，养兵千日”的怎么“养兵”和“兵”自己怎么实现自我修行。 人有了，该是考虑“地利”的问题了。所谓地利，即指软件的测试环境，这与开发环境有着很大的不同，同时也保持了一定的联系（废话）。

测试不会凭空出现，正是因为之前有过太多的教训，人们开始对质量重视起来。从这个意义上来讲，相关组织是为了避免损失而测试，而减少支出其实是赚了钱，所以他们进行测试是为了获取利润的。从另外一个方面来看，测试也要投资，而测试环境则在这些支出中免不了分一杯“羹”。

先看一个笔者赶制的一个草图

对于上面的图，简单说明一下，或者“按图索骥”吧。 在我们计划测试的过程中，我们使用由顶向下的分析策略。

所谓测试环境（我们这里指的是物理意义上的环境），对于软件测试来讲“咔嚓”一声分成两半：硬件环境和软件环境。

把硬件环境拿出来讲，包括了测试项目依赖的硬件环境，测试工作本身依赖的硬件环境。

所谓测试项目依赖的硬件环境，举例来讲我们测试一个手机操作系统，总得要拿出个手机来试一试吧；如果拖拉机也需要软件配备，那么一台拖拉机也是需要的，另外还需要弄一个库房或者至少一个空地来放这个拖拉机；所谓测试工作本身依赖的硬件环境，至少得一台测试用的机器吧，对于特殊要求，比如开发一个嵌入式程序用来监控室内二氧化碳的浓度，这个时候一个特殊的工作室可能也是必要的，至少有一个工具可以改变二氧化碳浓度，有个地方可以困住这些二氧化碳吧。关于机器，我们还需要考虑到机器的配置等等问题。

接着就是软件环境了，跟硬件环境一样，包括了测试项目依赖的软件和测试工作本身依赖的软件，当然最重要的是要有个操作系统，还要搭上待测的应用程序。

关于待测应用程序就不讲了，想想如果没有待测程序那我们还测什么啊，是不？测试项目依赖的软件，这里面的弯弯绕就显得多了一点了。首先，待测程序引用或者操作的一些应用程序得准备齐整，比如说某应用程序用于监测某个人每天打开了多少次Outlook并收发了多少邮件，如果机器上没有装上outlook的那我们就只能测试没有outlook下该应用程序的的表现这一种情况了，虽然这也是一个很重要的用例，但是更多的有用的用例还是需要我们配备上outlook来测测的。其次待测程序运行的平台，.NET开发的你总得安装上相应的.NET Framework吧，web应用程序没个浏览器也是不行的。

测试工作本身依赖的软件，说明白点主要就是测试工具了，这里面的弯弯绕太多，笔者就不绕进去了。

操作系统，对于基于windows操作系统的软件，我们就需要考虑到微软这些年来给我们贡献的这么多版本，如果考虑到其他操作系统，我们就不得不考虑到苹果等等的贡献了。

总结一下，对于测试人员来讲，在项目里面不需要考虑到所有的部分（图的叶子部分），但非叶子节点部分还是得好好琢磨琢磨。对于开发人员来讲，比较常出现的一个情况是软件工作的环境问题：应用Team Foundation管理团队项目的时候，项目开发人员A引用了外部DLL（假设为C.DLL），当签入源代码的时候这个DLL是不被签入到TFS上的，这就会导致服务器上的版本编译不通过，提示无法找到DLL之类的错误信息。这是一个常见的环境错误。另外，如果项目组成员使用的开发环境不一致，也可能导致应用程序集成失败或者BVT运行不通过；如果开发团队开发环境一致，那么在对应用程序有兼容性要求的时候，相关的系统兼容性测试是必需的。

（五）——时

到了“时”了，这是计划测试过程中最让人纠结的地方了。计划本来就是一件很麻烦的事情，关键点就在于计划的时候很难拿捏准时间的长度。在一本称之为《软件工程中的事实与谬误》的书籍中，作者提到一条软件项目走向失败的两大因素中的一条就是估算不准，由此可见计划之难了。Aaron现在对于时间计划搞得也是没模没样。

初一的时候计划在十五月圆之夜一起赏月对饮，可是天有不测风云，到了十五那天天气转阴了，月亮连个影子都没有更不要提月圆了。在项目中也会经常遇到这种情况，我们预计某年某月某日我们实现某项功能，可是等真的到了那一天，才发现原来我们想象中的那项功能依然只能存在与想象之中了。

那我们怎么做时间计划呢？ 在Aaron看来，因项目性质而异，要知道我们从事的项目大致可以分为两种：产品性质的和外包性质的。这两种性质的项目对于时间的要求，对于测试强度的要求是大不一样的。

对于一般外包项目来讲，对于测试要求相对较低，而时间是固定的。当前大多数标榜使用螺旋开发的团队其实只是变相的甚至是变质的瀑布模型，对于测试的现状更是如此。测试先行，测试与项目同时启动在大多数项目中都只是一句口号而已，因为大家心里都明白，口号是不要钱的，所以空喊口号这种最廉价的朝脸上贴金的方式广受软件作坊主们的欢迎甚至推崇。废话不扯了，对于这种项目的测试工作来讲，一般是标准的段段式的，即计划测试，测试用例设计，测试用例执行及bug管理，测试报告提交等等阶段。这就好弄多了，根据经验（如果一点经验都没有，那还有直觉）我们把这几个阶段换算成比例，然后把测试总时间瓜分了，需要提醒大家的就是记得在瓜分之后留点“缓冲时间”来，否则到时候出了点意外就麻烦了，记住是在每段时间之后加上一个缓冲期，而不是最后加上一次。

对于产品来讲，测试要求会比较高，时间当然也是需要考虑的，套用IT界最常被引用的一句话，“在这个瞬息万变的时代”，把握时机对于一个产品来讲无疑是很重要的。不过，由于众公司都不愿意自己的产品一出生生了满身毒疮——bug。轻则产品销量受损，重则产夭折，甚至严重影响公司形象乃至导致公司运转等严重问题。这个时候我们还是先将测试分段，对于这种项目，我们首先站在测试质量的角度，实事求是按照功能点数目、难度，测试经验等来估计测试时间，然后将总时间加起来，如果时间充裕，我们考虑加入更多测试面，如果时间紧迫，我们考虑是否删除部分非核心功能，以降低开发和测试的时间成本，从而为测试质量保驾护航。

回到上面的“月圆之夜”的故事片段上来，这个片段提醒了我们在时间计划的时候还有一些问题需要注意。上面提到计划失败是因为“月圆”这个外界因素没有达到要求，这就提醒我们在计划的过程中，应当尽量减少对于外界的依赖，如果依赖是必需的，那么对于依赖可能导致的意外我们要多出几套应急方案。另外，在项目执行过程中，及时检查项目进度也是必要的，这可以避免我们跑在错误的道路上，那样只会越错越远，这部分不属于计划测试的范畴，因此不做考虑了，如果有兴趣可以看一下持续集成相关的资料。