1.3　掌控项目背景

无论是做什么项目，要想获得成功，必须清楚项目的背景，包括项目的来源、客户和需求等。软件测试也不例外，要做好软件测试计划和随后的工作，也需要掌控软件项目的背景。如何更好地掌控项目背景？就是要抓住与软件测试相关的项目要素，获取、分析和综合理解与这些要素相关的详细信息。通过了解软件项目的要素信息，就能明确测试需求，掌握项目的不同特点，并针对这些特点采取相适应的测试方法和策略，更好地开展测试活动。

1.3.1　软件测试的项目要素

拿到一个软件项目，首先要了解哪些内容？或者说，项目测试计划前，需要获取哪些项目数据，知道项目有哪些特点？这就要求我们在项目启动时，一定要抓住软件项目的要素，根据这些要素，逐个地去搜集信息、获得数据，并进行分析。

项目的基本要素包括项目范围、质量要求、工期和预算等，如果进一步展开项目要素，它将包括项目的目标、客户和用户、范围、质量要求、工期、预算和成本、人员、材料设备、技术和合同管理等。即使在软件特定领域，软件项目的要素也离不开这些内容，而且这些内容也都是很重要的内容，只不过许多技术人员不关心预算、成本、合同等，甚至不关心客户。在这里，讨论的焦点虽然集中在技术方面，但也绝对不能忽视客户或用户的需求，不能忽视软件开发成本和合同中的有关条款内容。

要点

做产品，不是写程序。 如果技术人员把要做的事情仅仅看做是写代码、编程序和开发系统，而不是看作开发为客户服务的产品，那么问题可能会很严重。技术人员往往过多地从技术方面思考，而很少真正从客户的角度去想，有时也可以开发出比较精妙的、甚至让人惊叹的东西，但在大多数情况下，他们开发出来的产品将不是客户真正需要的、高质量的产品。在这种不正确的意识下开发出来的软件产品，缺陷会很多，很难满足客户的需求，并且开发效率低，会给企业带来很高的开发成本。

要掌控软件测试项目的背景，就要了解下列软件项目的要素及其相关的信息。

（1） 用户： 软件的用户是谁？是为个人服务，还是为中小企业服务，或者为大企业服务？用户是专业的技术人员，还是普通的教师、学生、公务员？如果是面向公务员，可进一步分析，是面向政府机关各层次的工作人员（包括高层领导、中层领导、办事员），还是只面向办事人员？面向不同层次的人员，对软件系统的界面、权限等有什么不同的特殊要求？不同的用户角色，有什么特定的需求？

（2） 目标： 就是软件要真正解决的问题，即要实现的业务功能，如处理个人所得税网上申报的所有流程、网上购物、信用卡认证、英语词汇学习等。

（3） 范围： 软件产品功能的范围和服务对象的范围，也就是要界定系统的边界，哪些功能是该软件系统要实现的，哪些不是。如个人所得税网上申报业务项目，只是完成“申报、查询”工作，还是否包括“税率调整通告、咨询、申诉、个税管理”等功能？是为某个区的居民服务，还是为全市、全国的居民服务的？需要和哪些已有系统集成？

（4） 工期： 项目的阶段划分、各个里程碑的日期等。项目什么时候启动？系统设计和编程又分别在什么时候完成？产品发布和市场宣传等日期是否已确定？

（5） 项目类型： 是长期性产品开发，还是一次性项目？是独立项目，还是多方合作的、综合性集成项目？是本地项目，还是外包项目？是企业应用系统，还是一般软件工具开发？

（6） 软件平台： 是单机，还是网络？是客户端软件，还是服务器端软件？是Windows，还是Mac、Linux、Solaris？是企业内部网络（Intranet），还是互联网（Internet）、无线移动网络？是微软公司的.Net平台，还是JavaEE、Ruby on Rails等？

（7） 开发工具和语言： 是Visual Studio，还是Eclipse、PowerBuilder？是C++、C#、Java/JSP、ASP、PHP、VB等语言中的一种，还是混合编程语言？

在启发式测试策略模型（Heuristic Test Strategy Model，HTSM*，参见：http://www.satisfice.com/rst-appendices.pdf）所要求掌握有关项目的现象包括：用户、与开发者关系、测试团队、设备与工具、进度、测试条目、交付物等，和我们上面讨论的内容比较接近，这里没有涉及与开发者关系、测试团队、测试条目（test item）等内容。但在上一节我们讨论了与开发者关系、测试团队等内容，我们在测试计划中会继续讨论以下这些内容。

（1）测试的范围直接和测试条目相关，基于测试需求分析，能确定测试条目。

（2）在测试工作量估算时，需要考虑与开发者的关系，如开发人员做了哪些测试工作、单元测试是否充分、代码质量如何等，这些对测试工作量都有较大影响。

（3）测试团队中人员素质如何、有什么技能等情况，会决定我们采用什么样的测试方式、采用什么样的测试策略。

概念

客户和用户 是两个不同的概念。软件产品的使用者或软件服务接受者是用户（User），而客户（Customer）是更为广义的概念，是公司为实现目标所需的产品和过程而影响到的人，不仅包括接受产品或服务的组织或个人，而且包括潜在的客户，例如消费者、委托人、最终使用者、零售商、受益者和采购方等。当一个软件组织直接为用户服务，为特定的用户完成特定的项目时，这时客户和用户是同一个对象。但如果某个用户的产品是通过第3方——软件承包商等委托给软件组织进行开发的，这时客户和用户则是分离的。

里程碑 是软件生命周期各阶段末尾的特定点，在这些特定点上，阶段工作已结束，并且已经取得了正式的阶段性产品。里程碑的设定伴随着阶段性目标、进入/进出标准或指标等的确定，设定里程碑是为了更好地管理项目。如微软软件开发框架（MSF）中有愿景、计划、开发、稳定和发布等主要的里程碑。在开发阶段，还可进一步设定3～4个小里程碑，如设计、编程、集成和代码冻结等。对于软件测试，常见的里程碑有：测试计划签发（Sign-off）、测试用例签发、自动测试脚本完成、功能测试完成、性能测试完成等，可以参考附录A的软件测试全景图。

1.3.2　两个典型项目的介绍

今天，软件应用发生较大变化，其中主要的变化是移动应用、云服务和大数据等，这样对软件测试有更为严峻的挑战。本书在相应的章节（自动化测试、用户体验测试、性能或安全性测试等）会触及这些新的主题。但考虑尽量让读者更好理解软件测试，我们选择的案例会简单些，考虑在实际工作中经常碰到的软件项目类型，主要有如下4种类型。

（1）纯客户端软件，如字处理软件、下载软件、媒体（音频/视频）播放软件等。移动应用有一部分App应用也属于这种，不需要连接网络就可以运行操作的，只是其操作系统不再是Windows，而是Android、iOS等。

（2）纯Web（B/S）应用系统，如门户网站、个人博客网站、网络信息服务等。

（3）客户端/服务器（C/S）应用系统，如邮件系统、群件或工作流系统、即时消息系统等。

（4）大型复杂企业级系统，涉及面广、集成性强，包括B/S、C/S、数据库、目录服务、服务器集群、XML接口等各个子系统。

这里以两个典型项目作为全程测试活动过程的项目背景，旨在帮助大家更好地掌握测试的方法、技术和时间。其中Google Talk是一个客户端/服务器（C/S）软件，如图1-6所示，主要项目因素可简单描述如下。

●　用户：想拥有即时消息（Instance Message，IM）的网络用户，年轻人偏多。

●　目标：操作方便、沟通及时并能和邮件等集成。

●　范围：见后面分析。

●　工期：第一个版本需要6个月左右，发布周期相对长些，适合应用敏捷方法。

●　类型：长期性产品，不断升级。

●　运行在Windows、Mac和Linux等各种操作系统之上。

●　开发语言主要是C++。

而Google日历 （注：有些地方还依旧用第1版的雅虎日历，因为测试数据和所发现的缺陷只在雅虎日历上出现。Google日历和雅虎日历本质上没有差别） 是一个B/S应用系统，包括页面（如图1-7所示）、Web服务器、数据库和邮件服务器等，项目特点如下。

●　用户：网络用户，以商务人员为主。

●　目标：管理日常活动、事件，及时获得提醒等。

●　范围：见后面功能分析和质量需求分析。

●　工期：第一个版本需要3～6个月，发布周期比较独立，以后每1～2个月发布一次更新产品。

●　类型：长期性产品，更新和部署相对容易。

●　客户端主要是通过各类浏览器访问系统，也可以用移动设备访问系统。

●　开发语言主要是JavaScript 和 HTML，采用Ajax技术。