如何写一份靠谱的软件测试计划？(3)

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

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

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

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

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

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

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

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

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

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

　　(四)——地

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

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

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

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

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

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

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

原文转自：http://www.uml.org.cn/Test/200911128.asp