大话软件测试(txt+pdf+epub+mobi电子书下载)

作者：欧立奇等

出版社：电子工业出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

大话软件测试试读：

前言

本书通篇都是以情景对话的形式，用多个小故事或案例、漫画来组织讲解软件测试。从软件需求设计说起，在对软件测试做了妥善分类后，将本书的内容分为如下几大方面。

在测试需求方面：如何测试需求，如何审核需求，如何设计文档。

在测试分类方面：详解软件质量模型的6大特性27个子特性的各个检查点，并提供经验和案例，从而使读者能够容易地运用到实际项目环境中；让读者能够清楚地得知，软件测试究竟是测什么？

在测试计划方面：如何写用户故事、测试用例、测试计划，如何进行测试建模，如何制定人力资源的分配计划。

在测试管理方面：如何预知风险，如何写日报，如何与DEV（研发）、PM（项目经理）进行交流，如何进行测试项目的管理，如何利用自动化技术来提高测试的效率等。

本书表现形式虽为“大话”，但内容结构实为严谨。在讲解软件测试的过程中，通过问询式结构，把学习门槛降低，让读者可以更加容易地理解测试的目的、策略、方法以及管理，澄清有关软件测试的常见误解，用一种不扭曲、不变形、不晦涩、不忽悠的表达方式表现测试的真谛，以达到不但授之以“鱼”，还授之以“渔”的目的，引导读者体会软件测试过程中蕴藏的大智慧。

本书不同于其他软件测试书籍的主要特点如下。

细

软件测试由于工作的特殊性，软件测试人员更要具有认真、耐心、细致、敏感等个性元素，涉及的方面比较多，且比较基础，也比较细。以软件安装为例，一个完整的软件安装检查点就包括：1．安装环境检查；2．中断安装的情况；3．回溯的检查；4．可定制化安装；5．安装特定参数/端口依赖；6．安装路径；7．安装介质；8．安装语言；9．安装Shell；10．安装组件；11．操作系统兼容性；12．操作系统语言包；13．硬件系统兼容性；14．逻辑安装次序；15．安装安全性；16．安装接口；17．安装结果检查，等等。

所以本书把这些细小的知识点和检查点做了汇总，让读者有章可循，按图索骥就可以轻松测试。本书使用了四级标题，每一条都是一个实际的案例，切切实实地解决读者遇到的实际问题。

深

说到测试，人们首先想到的是：测试是一种技术。然而事实上，测试是一种哲学，一种思想，思想的背后是一个人的眼界和世界观。一个测试也许能从多方面揭示测试者的素质和看待问题、思考问题的能力。市面上流行的测试书籍在此专业性的分类方面做得不够，正因为如此，本书追求的是循循善诱，讲深讲透，侧重于软件测试技术的本质理解，而不仅限于对测试的单纯讲解。

广

市面上流行的软件测试书籍仅对软件功能性测试本身比较侧重，而忽略软件测试外延的东西：比如非功能性测试中的易用性测试、性能测试、文档测试。而随着用户对易用性、可靠性要求的与日俱增，本书对以上诸多方面都给出了详细分析，并结合大量案例制定出测试方案，以满足读者需求。

乐

苦逼的团队做不出有爱的产品，愉悦编程、快乐测试才能使你的职场之路长久。所以，本书语言幽默诙谐，并夹杂了一些漫画来摆事实、讲道理，力求为众多严谨的软件测试书籍添加一抹亮色。

本书不是一本万能书籍，但肯定是您软件测试/开发/管理工作的好助手、好伙伴。

本书主要由欧立奇、何金池编著，其他参与编写的人员有刘洋、秦晓东、李启高、马雪、马煜、胥虎军、李富星、牛永洁等。

最后，感谢本书编写过程中的几位重要人士的支持，衷心感谢明总、峰总、大胖、小四的鼎力协助。

第1部分 软件需求与设计

第1章 软件需求

1.1 从需求的含混性说到软件测试的目的

1.1.1 需求的含混性

小白 大鸟啊，我郁闷得很啊。

大鸟 咋啦？

小白 我们公司参与了一个大项目。当时市场人员把项目签下来的时候，项目组是欢天喜地。项目做了一年多，到了交付的时候，用户却很不满意，当初说好的需求，好多都变了卦。

用户是上帝，最关键的是如果收不到后面的钱，那就算白干了。公司要求项目组加班加点进行修改。我们测试部门也不得不一遍一遍地做着重复劳动，搞得大家是怨声载道。做市场的和做开发的相互指责，然后，大家又一起骂客户刻薄。公司里面弥漫着灰心丧气的气氛。

大鸟 你们是怎么和客户谈需求的？

小白 市场人员先谈单，估计人家需要做什么。然后，我们这边派一个搞技术的人员过去了解需求，拿一些对方的表格和笔记回来。

大鸟 你们去询问需求，然后做了一个文档。你们头脑里的东西，跟客户要的东西，其实是不一样的。但是，大家都认为这样白纸黑字，基本上是一样的。但这里面其实是有差异的。这种差异，有时影响不大，但有时，是致命的。毕竟，文档不是最终的实物。客户永远认为，他是把需求给你讲清楚了的，如果你做不到，不是他的责任。而且，你要记住一点，用户只有在见到或使用过实物的时候，他才知道他其实要的是什么东西。否则，如果研发人员没搞清需求就闷头做事，迟早项目会变成“包工队的故事”。场景漫画：包工队的故事甲：说一个包工队接一好活儿，盖一个70多米高的大烟囱！盖成本家给一千万美金！！乙：还真不错！甲：起早贪黑把活干完了，人家来一验收，死活不给工钱，还叮当五四被打了一顿！乙：为啥啊，质量不行？甲：把图纸拿倒了，人家让挖口井！

小白 “用户只有在见到或使用过实物的时候，他才知道他其实要的是什么东西。”这句话，我严重同意。可是，要按你的说法，那用户和我们之间，就永远不可能存在真正意义上的沟通！那不成了虚无主义了吗？”

大鸟 如果你不了解客户的业务需求，或者不真正熟悉其行业规则的时候，你需要更严谨的方式来询问和确定需求。否则，那些落在纸上的文字和文字之间，埋藏着数也数不完的陷阱。需求阶段过于匆忙，就会出问题。比如说，客户忙，随便给你找一个表格，到最后就是无尽的麻烦。

小白 客户不都是这样吗？有何问题呢？

大鸟 客户没有问题，而是去问的人要格外小心了。他要搞清楚客户的背景、立场——客户关注自己想要的结果，但不同人关注的东西不同。有些客户希望不要给他们增加过多的工作任务，越傻瓜越省事越好；有些用户关心新系统的性能是否可靠，速度够不够快；而系统管理员，关心的技术和安全。总之，每个人都各怀心事。需求是多种多样的，所以对于用户所提出来的需求都要仔细记录，认真掂量。

小白 如何掂量？

大鸟 多问自己几个问题。（1）这是谁的问题？谁是顾客？谁必须被取悦？（Who的问题）（2）他们的问题是什么？来自于哪些方面？基于什么？有什么特殊性？（What和Why的问题）（3）哪些问题是一定要解决的？哪些可以不解决？哪些用户根本不在乎？（Scope的问题）（4）哪些问题是比较简单的？哪些是比较复杂的？简单的要不要合并？复杂的如何分解？（拆分和合并的问题）

很多人去做需求，以为拿着本子记下来就好了。其实，很多时候，都没那么简单。觉得简单，是因为很多人认为从技术上设计这类的软件，简直是小菜一碟。但是，他没有想到的是，很多问题只是冰山一角，有些问题暗流汹涌，有些问题前后矛盾，有些问题不可实现。用户需求暗藏着一个个陷阱和地雷。场景：两个圆的故事甲用铅笔在纸上画了两个圈。问乙：“你说，这是啥？”乙说：“两个圆。”甲摇摇头：“是两个鸡蛋。”乙觉得甲很无聊，不耐烦地说：“好吧，就算两个鸡蛋。”甲摇摇头：“不是，这不是鸡蛋，这是两个乒乓球。”乙不知甲在暗示什么，他在听。甲说：“我看到的东西，和你看到的东西，不一样。但是，在纸上，画的是同样的两个圈。”

1.1.2 软件测试的目的

小白 你上面所说的这些东西，不是市场人员或者需求分析人员应该考虑的问题吗？和测试Team有什么关系呢？

大鸟 那我问你，你现在做软件测试，测试的目的是什么？

小白 让我想想。软件测试的目的是尽可能发现并改正被测试软件中的Bug（缺陷），提高软件的可靠性。

大鸟 这个定义听起来很正确，但用它来指导测试会带来很多问题。比如有的公司，用发现的Bug的数量来衡量测试人员的业绩，其结果如何呢？其一，有一些不够敬业的测试人员会找出一些无关痛痒的Bug来充数，结果许多时间会被浪费在这些无关痛痒的Bug上；其二，测试人员会花很大力气设计一些复杂的测试用力去发现一些迄今尚未发现的缺陷，而不关心这些缺陷在实际用户的使用过程当中是否会发生，从而浪费了大量的宝贵时间。究其根源，就是因为对测试目的的这种错误理解造成的。为什么这么说呢？因为软件里Bug的数量是无法估计的，所以如果测试的目的是为了找Bug，那么测试工作将变成一项无法完成也无法衡量进度而且部分无效的工作（因为有些Bug在实际的运行过程当中根本不会发生）。

小白 唔……那你看这样说对不对：测试的目的就是为了保证软件质量？

大鸟 这个定义也是看似正确，但实际上，混淆了测试和质量保证工作的边界。软件质量要素有很多，包括可理解性（Understandability）、简洁性（Conciseness）、可移植性（Portability）、一致性（Consistency）、可维护性（Maintainability）、可测量性（Testability）、易用性（Usability）、结构（Structure）、效率（Efficiency）、安全性（Security）等，所以，软件质量保证和测试的关注点其实是不同的。假如说，你保证了软件安全性的高质量，但是用户压根就不关心安全性，那你不是白测吗？

小白 那么测试的目的应该是什么呢？

大鸟 IEEE对软件测试的定义是：“使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。”所以，简言之，测试的目的应该是验证需求，Bug（预期结果与实际结果之间的差别，即缺陷）是这个过程中的产品而非目标。测试人员应该像工兵一样，在大部队（客户）预期前进的方向上探雷、扫雷，而不需要去关心那些根本没有人会去碰的地雷。衡量一个测试人员应该去衡量他/她测试了多少需求（测试工作量）。我看到许多测试团队在需求不清晰的情况下，就进行测试，这简直是事倍功半。往往到最后还要返工重来。所以对于我们QA（测试工程师）来说，测试需求是永远放在第一位的。

小白 我一直以为程序完成后了，才开始软件测试。

大鸟 我一直反对软件测试仅存在于程序完成之后。如果只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷，记住“软件缺陷具有生育能力”。软件测试应该跨越整个软件开发流程。需求测试和设计测试也可以算作软件测试的一种。软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期中的每个阶段经得起考验。

1.2 需求的定义与分类

小白 我明白了，正因为测试的目的是为了验证需求，所以测试部门就该和研发、市场、技术等支持部门通力合作，搞清楚需求到底是什么？大鸟，到底需求的定义是什么呢？

大鸟 我认为需求是这样的：需求是指明了必须实现什么的规格说明。它描述了系统的行为、特性或属性，以及在开发过程中对系统的约束。用户（提出）的需求是用户个人认为在对自身目标的解决方案中，自己不能或者不愿完成的部分。

因为不愿且不能，所以用户的目标可能是含混的、模糊的。好多产品只是有一个潜在的客户群，产品做出来后用户才有反馈。

小白 如何减少需求含混性？

大鸟 当我们发现存在比较大的歧义时，自己通过交流的方式来降低这种歧义。开始的时候，我们会有一个初步的文档。但是在合同签下来后，会有一个相对时间较长的需求的再确认过程，我们会和客户一起来走一个流程。然后，我们会把大家商业需求的结果，转换成最终的设计，用PPT把用户故事（包括操作界面和业务流程）都模拟出来，让客户有身临其境的感觉。在正式开工以前，给客户汇报。到此为止，我们并不做任何真正的编码工作。

小白 这样做，还是很花时间，效果如何呢？

大鸟 相对于搞错了需求，重新开发，这是最合算的了。很多人都不愿意这样做，最后人都跑光了。知道项目经理最痛苦的事情是什么吗？项目没完人跑光了（你知道项目经理最最痛苦的事情又是什么吗？人在，项目不让你做了！这种事情，也有不少啊）。

1.2.1 业务需求

小白 那么，如何获得、采集需求？

大鸟 搞清楚用户需求是一个长期不断地获取和澄清的过程。对项目不同阶段所要求的需求粒度（需求分解细化的程度）也各不相同。在项目初始的立项阶段，需求采集的主体是市场人员，市场人员从客户那里得到一些直接的或者潜在的需求，这些需求或为全新的，或为对现有产品的改进期望。市场人员得到此类需求后，及时做初步分析，并书面反馈给PM（项目经理）。这时市场人员是需求的主要来源，但并不是唯一的来源，技术支持人员、中间商、潜在客户群都会给出贡献。我们把立项阶段得到的需求叫业务需求。

小白 业务需求？

大鸟 业务需求反映的是企业/组织对软件系统的高层次目标。业务需求确定后会得到一个叫做业务愿景的东西，其实就是项目成功后会是个什么样子，并在涉众范围内达成一致。而业务需求的确定对之后的用户需求和软件需求起了限定作用，业务需求就是需求过程的宪法，任何需求不得与之相违背。比如说：研发一台电视机，为用户提供看电视的服务。请注意，是服务，是以外部的眼光，全局性地看这一需要实现的东西。

小白 高层次目标？

大鸟 对，就是高层次的。咱们中国有一个成语“纲举目张”，纲是鱼网上的总绳，比喻事物的主干部分；目是指网眼，比喻事物的从属部分。纲举目张是指抓住事物的关键，就可以带动其他环节。在这里面，业务需求就是那个纲，指用户需求的大方向、大框架，它的输出结果就是MRD，即市场需求书（Market Requirement Document），或者有的公司称其为商业需求书。

1.2.2 用户需求

小白 懂了，那然后呢？

大鸟 然后我们要在业务需求的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。用户需求必须能够体现软件系统将给用户带来的业务价值，或用户要求系统必须能完成的任务，即用户能使用系统来做些什么。比如说，为了让用户能够看到电视节目，需要做到：接受电视信号、显示到屏幕、可以换台等。这些内容都是为业务需求服务的，也是为了能够看到电视节目所必不可少的，即用户需求是业务需求的深入和细化。在这个阶段，我们需要将MRD中笼统的“概念化”需求转化为可实现的“专业化”细则，将MRD中的内容进行指标化和技术化。此外我们还要挖掘出其中的隐性需求，以便后续引导用户的兴趣和投资点。

此阶段的输出结果是PRD，即产品需求文档（Product Requirement Document），着重在论述“要做什么”的问题。此文档重点体现产品的功能和各项指标的说明，分别是功能要求、开发要求、兼容性要求、性能要求、扩展要求、产品文档要求、产品外观要求、产品发布要求、产品支持和培训要求、产品其他要求等。其中，在功能要求当中，应该重视主要Feature（特性）的重点描述。

第2章 PRD审核

2.1 PRD分类

小白 PRD对于测试工程师来说一定是非常重要的吧。

大鸟 没错，PRD来自于需求分析阶段的开始，是测试执行的源头，是测试生命的源泉，只有源泉干净清晰，才能保证身体的健康。同样，只有PRD业务描述清晰、完整、正确才能保证整个测试流程的“生命”，否则整个流程都会紊乱。所以在PRD出来后做审核工作是非常有必要的，每个测试人员都应该负责地去审核需求人员编写的每1个字、每1张图，哪怕是每1个标点。但是这种审核不是做文字查错，更多的应该是去关注业务、流程、逻辑和查漏补缺。

小白 我最早还以为PRD仅是PM和市场人员的事呢？

大鸟 的确，现在很多公司或者组织在需求分析和架构阶段，仅有PM和架构师参与，而DEV（研发工程师）和QA在一开始并不被“卷入”。这样操作将会导致两方面的负面结果，一是很容易导致DEV和QA因为不清楚或者误解原始需求和设计背景，而在实现的过程中出现或大或小的功能或者性能的偏差；二是上游的设计没有完全挖掘出一些隐性的风险和漏洞（具体实现层面的细节），而这些隐性的不可实现便会导致研发的不可进行或者延迟交付。因此项目架构应该由架构师牵头，整个开发团队各抒己见，共同完成。

小白 我知道了，那么，PRD包括哪些方面的内容呢？

大鸟 PRD主要包括软件产品定位、软件产品需求以及范围约束这3大项。每一个大项，又分为若干小项，如下表所示。

2.2 软件产品定位

2.2.1 产品背景/定位

小白 产品背景及定位是指什么呢？

大鸟 产品背景及定位描述了软件需求规格说明中所定义的产品的背景和起源。说明了该产品是否是成熟产品所改进的下一代产品、是否是现有应用程序的替代品，或者是否是一个新型的、自主型产品。如果PRD定义了大系统的一个组成部分，那么就要说明这部分软件是怎样与整个系统相关联的，并且要定义出两者之间的接口。

背景分析包括市场状况及该产品的用途、未来增长趋势、市场的竞争能力、需求规模、发展前景。比如说，要开发一款基于HPC（High Performance Compute高性能计算）的系统管理软件，就要先讲一下HPC行业背景分析。案例 HPC2.0产品背景/定位HPC2.0是在HPC1.0基础上的改进版本。传统的HPC应用程序通常内置了MPI（并行计算），它的常见市场用途包括：现代地质、建筑结构、计算流体力学、天气建模、其他科学模型仿真。此外，潜在的市场用途还包括在同一个应用程序中同时运行大量的独立作业，例如电子模拟、蒙特卡罗模拟、基因组测序和业务分析，以及基于使用Hadoop基础设施的大数据分析，如内存分析等。最后，HPC应用程序还包括业务分析及企业级应用。如利用多个服务器应用程序以增加容量和吞吐量，进一步提高了集群性能和可靠性。

2.2.2 目标潜在客户群

小白 讲完了产品背景及定位，下面就该讲目标潜在客户群了。所谓的目标客户，就是我们打算把产品卖给谁是吧？

大鸟 对的，所谓目标客户，是指企业的产品或者服务的所针对对象，是产品能满足需求的客户群。一般来说，目标客户具备以下几个特征。（1）购买能力：具备一定数量及支付能力，特别是具备发展的潜力。（2）购买需求：对你所销售的产品的某一个或多个功能有迫切需求，而这一需求是目前市场上其他种类产品所不能完美提供的。

小白 目标客户是潜在客户吗？

大鸟 目标客户包括潜在客户和价值客户。用户产生购买行为后，就从潜在客户变成了价值客户。然后，我们要做的是继续深挖用户的需求，保持产品的先进性，从而使价值客户成为忠实客户。案例 HPC产品目标潜在客户群HPC管理软件针对的一些客户类型如下：（1）使用集群软件管理商业领域向外扩展应用程序的客户，集群是由系统管理员作为单一操作系统进行统一管理的。例如，波音公司、埃克森美孚公司、英国网络公司等。（2）需要工具来部署和管理集群操作系统和软件堆栈应用开发的客户。例如，富士通公司等。（3）进行超级计算和研究并寻找可扩展的集群管理解决方案的客户。例如，红牛公司、德意志银行等。（4）组织并利用超级计算机的能力租赁给内部或外部客户的客户。例如，日本北海道超级计算中心等。

2.2.3 用户问题

小白 下面是关于用户问题的内容。我有一个问题，为什么不直接获得用户需求，而是还要费力搞清楚用户问题、用户的麻烦是什么？

大鸟 用户遇到的麻烦、痛点、顾虑到底是什么？面临的问题是什么？这是我们获取用户需求的基础。如果不知道为什么（Why）就直接问用户要什么（What），那么有可能把事情做偏。下面的例子是高性能计算领域用户常见的问题。案例 组织部署和管理基础设施时经常面临的问题● 昂贵的IT成本（包括硬件管理、不同操作系统的配置、不相容的预警系统等）；● 故障排除时间太久；● 终端用户使用效率太低；● 从采购到生产环节成本高，部署时间长；● 没有简单的方法可以快速部署和有效地管理多个集群；● 技术的可扩展性限制：现有的企业管理解决方案无法向外扩展；企业云解决方案如VMware、OpenStack等目前不支持物理服务器环境中的高性能计算应用程序。

小白 是啊，的确如此。那怎样才是一个好的问题定义呢？

大鸟 “问题定义”只定义了“问题是什么”，而不涉及任何可能的解决方案。它是一个很简单的陈述，并且听起来应该像一个问题。像“机器宕机了，以至于客户不能运行相关的Job了”这样的句子是一个很好的问题定义，而“我们需要HA系统，使得在机器宕机的情况下还能运行用户的Job”这种句子就是糟糕的问题定义，因为它听起来不像是问题，倒像是解决方案。

小白 只搜集问题而先不做猜想？

大鸟 对，先不做猜想。福尔摩斯说过：猜想是很不好的习惯，它有害于做逻辑推理。没有掌握全部问题之前，先做出假设来，这是很大的错误，那样就会使判断产生误差。

小白 如何获得问题的来源？

大鸟 问题的来源是指要考虑“这是谁的问题？”，其目的可能是：（1）确定谁是顾客，就是说，谁必须被取悦？（2）搜集一些有用的线索，以找到合适的解决方案。

小白 举个例子，就说刚才“机器宕机了”这个问题。我们怎么来寻找是谁的问题？

大鸟 如果“机器宕机了”这个问题只是来自于一个小型PC机用户，那么从影响面上考虑，问题不那么大。我们可以采取如下解决方案。（1）远程电话协助。（2）派专业人员上门服务，探查是否存在任何软件问题（如病毒、木马系统崩溃等）或者硬件问题。（3）让用户自己过来报修。

小白 毕竟是小型客户，影响范围小，优先级和严重性也就小。

大鸟 但是大型用户就不一样了。2013年7月，有大量用户反映微信发生全面故障，故障包括微信信息无法发出、无法刷新朋友圈、无法登录公众账号平台、无法连接微信网页版、页面显示为“服务器暂时不可用”。这可就是一个非常严重的问题了。

小白 对，当问题来自于大型客户，解决方案就迥然不同了。

大鸟 如果我们把工商银行或者腾讯公司当作我们服务器的顾客，我们可能会得到一个迥然不同的列表，比如说：（1）服务器是否需要事务级的管理。（2）是否要求电源备机控制系统。（3）是否需要高易用性的远程分布服务系统。（4）技术支持人员是否需要常驻现场。

这两个客户列表，尽管不一定完全排斥，但是我们确实能够看出一些倾向上的差别。为了避免因为这些倾向而做出草率的决定，我们要在提出解决方案之前仔细考虑，并把问题想得尽量全面些：考虑一类问题而不仅是一个问题。

小白 怎么去寻找一个问题的解决方案？

大鸟 四句话：把自己当成别人；把别人当成自己；把别人当成别人；把自己当成自己。（1）在动手去解决问题之前，好好想想问题的来源。（2）站在各个角度来看待面临的问题，以便能够了解其真正所在。（3）不要把解决方法误认为是问题的定义，哪怕是你自己常用的解决方法。

2.2.4 产品特点和特性

小白 产品的特点和特性是指什么呢？

大鸟 简单点说，就是阐述将要开发的这款软件的特性和有必要去开发的理由：创新点是哪些？优越性是哪些？有没有什么独特的价值？研发出来后对相关领域有多大影响？再和市场已经存在的那些软件做个对比，自己产品的优点、改进点是哪些？

小白 是啊，如果没有的话，公司为什么要投资进行研发呢。

大鸟 下面以ETT公司开发的HPC（高性能计算）系列软件产品做为一个例子。案例 ETT公司的HPC产品特性ETT公司的HPC软件是一个商业产品，用于管理大规模硬件和软件。此外，它还是一个可以管理多集群和多租户的计算基础架构的软件产品。ETT公司HPC软件相对市场其他产品的独特价值是：（1）综合管理和监控硬件组件、操作系统和中间件。（2）支持多个操作系统和软件配置。（3）支持多集群、多租户管理。（4）高可扩展性——最多可以扩展到50000个节点。（5）能够提供各种规模的集群环境，如高性能计算、Hadoop和OpenStack的等。（6）ETT的HPC软件不仅能在有OEM（Original Equipment Manufacturer，贴牌代工厂商）合作伙伴的硬件（如Dell、HP等）上运行，而且支持在非OEM合作伙伴的硬件上运行。

2.2.5 产品结构图

小白 产品的结构图指什么呢？

大鸟 产品的结构图指产品的架构和组成方式。这里，以HPC产品为例简单解释一下。（1）在这个图中，最下层是Scope（范围）支持，是指这个产品在哪个硬件范围、操作系统范围以及浏览器范围获得支持。（2）上面一层是产品的架构、内核、数据库。（3）再上面一层是HPC产品的基本功能（安装、部署、管理、监控、扩展性、高易用性）和高级功能（多集群、服务管理、策略管理）。（4）最上面一层是应用层，指应用上支持哪些服务（大数据、GPFS等）。

2.3 软件产品需求

小白 软件产品的需求包括什么呢？

大鸟 包括如下几个方面。（1）功能性需求。（2）非功能性需求。（3）文档需求。（4）项目需求优先级定义。

2.3.1 功能性需求

小白 功能性需求是指什么？

大鸟 功能性需求包括如下几个方面。（1）特性需求。（2）安全性需求。（3）互操作性需求。

特性需求是根据系统特性即产品所提供的主要服务来提交给用户使用的软件功能，使用户可以通过使用产品所提供的特性来执行任务，达到自己的期望。

安全性需求指系统安全性、完整性或与私人问题相关的需求，这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。

互操作性需求包括硬件接口互操作、软件接口互操作，以及通信接口互操作。

硬件接口描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之间交流的数据和控制信息的性质以及所使用的通信协议。软件接口描述该产品与其他外部组件（由名字和版本识别）的连接，包括数据库、操作系统、工具、库和集成的商业组件。通信接口描述与产品所使用的通信功能相关的需求，包括电子邮件、Web浏览器、网络通信标准或协议及电子表格等，定义了相关的消息格式，规定了通信安全或加密问题、数据传输速率和同步通信机制。

以ETT公司的HPC产品为例，我们可以看一下一个大型软件的功能性需求都包括什么。案例 ETT公司的HPC产品功能性需求软件安装/卸载/升级/更新需求：● 交互式安装● 静默安装● 工厂安装● 重新安装（P2）● 卸载（P2）● 安装中断后继续安装（P3）● 升级● 打补丁节点/网络/模块管理包括：● 添加● 删除● 修改● 替换● 重新部署● 导入● 导出● 显示● 锁定● 激活● 查询● 生成报表● 预警● 配置● 同步● 过滤● 状态监控应用层模板管理：● 模板实例化● 发布● 拷贝用户安全管理：● License控制● 用户认证安全● 系统网络安全性● 数据库安全性全球化支持：● 中文支持● 德文支持● 日文支持其他需求：……

2.3.2 非功能性需求

小白 非功能性需求是指什么？

大鸟 非功能性需求是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性，包括系统的性能、易用性、可靠性、可维护性、可支持性、可扩充性、可移植性以及对技术和对业务的适应性等。例如：● 性能（Performance）——响应时间、吞吐量、准确性、有效性、

资源利用率（如要求系统能满足100个人同时使用，页面反应时

间不能超过6秒）；● 易用性（Usability）——人性化因素、帮助、文档；● 可靠性（Reliability）——故障频率（如系统能7×24小时连续运

行，年非计划宕机时间不能高于8小时）、可恢复性（系统出现

故障时，能够快速切换到备用机）、可预测性；● 可支持性（Supportability）——适应性、可维护性、国际化、可

配置性。● 可移植性（Portability）——是否有对原来产品进行软件硬件迁

移的支持？迁移过程中是否有兼容性的要求？

以ETT公司的HPC产品为例，我们可以看一个软件的非功能性需求包括什么。案例 ETT公司的HPC产品非功能性需求● 可靠性测试（P1）我们的目标是支持自动化高可用性计算（High Availability）。● 可扩展性需求（P1）我们的目标是支持集群节点从目前的2000个扩展到5000个。集群的报表、预警系统的图表系统必须能够支持扩展到5000个节点。● 性能需求同时部署500个节点的时间＜4个小时。同时部署2000个节点的时间＜8个小时。同时更新2000个节点的时间＜8个小时。

2.3.3 文档需求

小白 大鸟，文档需求是指什么？

大鸟 文档需求列举出将与软件一同发行的用户文档部分，例如用户手册、在线帮助和教程，并明确所有已知的用户文档的交付格式或标准。案例 ETT公司的HPC产品非功能性需求（1）Online Help（在线帮助）。（2）Man Page（功能帮助以及参数帮助）。

2.3.4 项目优先级的定义

小白 对于一个项目优先级的定义是什么样的呢？

大鸟 一般来说，项目定义为3个优先级，分别是P1、P2、P3。● P1——是强制性的一定要完成的模块，如果出现问题，将会影

响项目发布。● P2——对项目发布非常重要，但是如果出现问题也不会影响项

目发布（具体由项目经理决定）。● P3——重要，但不是强制性的或预期的一定要发布。

2.4 审核软件产品需求

小白 大鸟，上面我们已经介绍了功能性需求和非功能性需求。那么从QA角度来讲，我们怎么来审核PRD，以确保它是个好的需求文档呢？

大鸟 一般来说，用户需求存在如下两个特点。（1）零散：用户会提出不同角度、不同层面、不同粒度的需求，所以是零散的。（2）存在矛盾：由于用户处在企业/组织的不同层面，因此难免会出现盲人摸象的现象，从而导致需求的片面性甚至自相矛盾。

一个合理的需求文档有如下特性：（1）完整性。（2）正确性。（3）一致性。

小白 你总说审核软件需求。先问一个问题，审核到底是什么意思？

大鸟 “审核”在很多人的脑海中就是得出一个通过与否的结论。其实不是那么简单。顾名思义，审核（review）实际意思就是再（re）看（view）一遍的意思，其本质含义是通过再次的审读，尽早地暴露出错误。QA通过审核需求文档，消除歧义、错误、不完整性，以确保沟通没有失真。搞清楚用户想要什么？用户要这干什么？他为什么这么想？他会不会漏了什么？

小白 那你也说了，正是因为需求文档存在歧义、错误、不完整性，所以我们需要不断地审核。

大鸟 是的。

2.4.1 如何保证软件需求的完整性

小白 软件需求的完整性是指什么呢？

大鸟 完整性是指：不应该遗漏要求和必需的信息。不完整性是指：完整性涉及的东西可能根本不存在，或者只说了一部分，没说完整，有遗漏。

小白 别漏了。可是如何保证不漏呢？

大鸟 我们一般用如下这几种方法。（1）演绎法。（2）比较法。（3）分解法。（4）打标签。2.4.1.1 演绎法

小白 演绎法如何解决需求的不完整性？

大鸟 我们知道用户的需求可能是零散的，我们将这些零散、孤立的需求认为是一个个需求孤岛，需要把这些需求孤岛连接起来，最终形成闭环。

小白 需求孤岛？

大鸟 咱们看下面几个例子。例1 业务需求——研发一个飞机，这个飞机可以起飞，可以空中平行飞行。例2 用户需求——HPC软件可以正常地安装。例3 功能需求——普通用户可以对管理节点进行增加、删除的操作。

你觉得上面这些需求缺点什么吗？

小白 第一个例子，貌似没有提降落的事啊。又不是恐怖分子，怎么会研发这种只能起飞和飞行的飞机呢？应该是漏掉了吧。

大鸟 这种遗漏可能是一个大大的缺陷。用户所要求的飞行服务需求应该是一个体系，而不是割裂、孤立的需求。例2也有这样的问题：HPC管理软件里面有安装的需求，但是没有提及卸载、升级、打补丁、重新安装的需求。例3亦然，普通用户对管理节点有增加、删除的需求但是没有提及修改、查看的需求，另外只是普通用户有这个需求吗？管理员、根（root）用户又会怎样呢？进行了增加、删除操作后，成功了如何？失败了又怎样？这些都是需求的不完整性。

小白 如何避免呢？

大鸟 把它放到体系里。还是刚才那个例子，用户有安装的需求：安装的需求放在软件测试里，是属于“可安装性测试”里面的，这里包括安装、卸载、升级、降级、不完全安装等多方面的需求。而“可安装性测试”又属于“可移植性测试”这个体系的一部分。我们把一个孤点需求放在软件需求的整个体系中，通过零散的需求拼图碎片补全整个需求拼图。

小白 有点像达芬奇密码里的拼图。

大鸟 准确点说是用演绎法。

小白 演绎法是什么呢？

大鸟 演绎法是指从普遍性结论或一般性事理推导出个别性结论的论证方法。在演绎论证中，普遍性结论是依据，而个别性结论是论点。演绎推理与归纳推理相反，它反映了论据与论点之间由一般到个别的逻辑关系。

比如说：“天下乌鸦一般黑，西安也有乌鸦，所以西安的乌鸦也是黑的”。这段话中就包含着一个完整的演绎论证。“天下乌鸦一般黑”，是普遍性原理，是论据，是“大前提”；“西安也有乌鸦”，是已知的判断，是“小前提”；而“西安的乌鸦也是黑的”则是结论，也是论点。

同理，大多数软件都有“安装、卸载、升级、降级、不完全安装”需求，大多数用户管理都有“增、删、读、改、导入、导出”等需求。所以，如果开发一个新的软件，那它的需求至少要和体系里面的软件需求保持一致，至少不能丢。

小白 嗯，但是会不会有这样的情况，我们研发了一个产品，就是只有安装，不能卸载。

大鸟 有可能，但是不需要做的东西，你要把它放在Scope外面去，并且从QA的角度来说，至少你要想到这些，否则你怎么审核呢。在本书第2部分的测试分类中，我们会详细讲述测试分类的体系来验证这些需求。2.4.1.2 比较法

小白 除了演绎法之外。你说还有比较法？

大鸟 是的，比较法包括纵向比较、横向比较。

小白 纵向比较是啥？

大鸟 现在的版本和以前的版本相比少不少东西，这是纵向的比较。例 HPC4.2版本的产品，与HPC4.1版本产品相比，管理节点不能修改IP。

HPC4.1版本的产品是可以修改管理节点IP的，但是HPC4.2版本反而不能这样做了。是用户真的没有这样的需求吗？如果用户没有这样的需求，为什么？

如果用户有这样的需求，而仅仅是实现的局限性造成的，那就要问清楚，下一个版本还要实现吗？并把它明确加入到Scope里面去。

此外，上一版本的关键遗留问题（没做的）和上一版本没做好现在要加强（Enhance）的地方，是否已包含在内？这也是检查项之一。

小白 横向比较是啥？

大鸟 新引入一个东西，和类似产品相比少不少东西，这是横向的比较。例 HPC产品中，系统可以监控GPFS，监控包括Alert（预警）。

GPFS是一个新引入的东西，系统以前监控的是NFS，而且监控包括Alert、Report两种。那么GPFS的监控为什么不包括Report呢？既然是一个体系，应该包括完整的监控。2.4.1.3 分解法

小白 分解法是分解什么呢？

大鸟 分解关键字。文字表述中，往往关键字过于庞大，需要分解。像下面这个例子。例 用户不能访问系统管理员级别的数据库里面的数据。

这个就是一个非常模糊的用户需求。它有如下的问题：● 如果关键字是“用户”，用户是普通用户还是root用户，系统管

理员级别的用户可以吗？● 如果关键字是“不能”，那我想知道，验证成功如何？验证失败

又该如何？● 如果关键字是“访问”，访问的方式很多，增、删、读、改、导

入、导出都包括吗？● 如果关键字是“系统管理员级别的”，那么系统管理员级别是指

什么？能否继续分解？情况如何？● 如果关键字是“数据库”，那是什么样的数据库？是Sql

database还是报表？● 如果关键字是“数据”，数据包括什么？是数字、图表？

小白 哇哦，一句话居然扯出来那么多东西。

大鸟 正因为关键字不同，一个含混的需求可以分解成若干个清晰的子需求。

小白 那该咋办？

大鸟 限定、分解、细化。所谓限定，是指在范围约束里就把范围都定义清楚了，这里就不至于那么乱了。比如说：我们在范围约束中就指明数据库仅指Oracle 10数据库，那这里的数据库概念就清晰了。

所谓分解就是把主谓宾状都分解：根据什么样的人（Who）在什么样的条件下（Condition）做了什么样的事情（What），结果如何（成功如何？失败如何？）。必要的时候还可以画流程图把它分解成一个细粒度的需求，分解的方法我会在用户故事里面细讲。

小白 需要分解，需要细化。

大鸟 没错，下面的就是一个分解后的软件需求。例 当请求者输入账户号码时，系统将根据在线用户列表来验证所输入的账号。如果在此列表中查不到该账号，则系统将显示一个出错信息并拒绝订货；否则，进入订货流程。2.4.1.4 打标签

小白 还有一个问题哦，假如说QA确实知道某些需求不完整，缺乏一些信息，但这个东西用户、PM暂时也不确定，该咋办呢？

大鸟 没有问题，如果知道缺少某项信息，那么用TBD（To be done，待确定）作为标准标识来标明这项缺漏，这样将有助于你避免不完整性。在开始开发之前，必须解决需求中所有的TBD项。

2.4.2 如何保证软件需求的正确性：明确用户动机

小白 完整性说完了，接着我们说一下正确性。软件需求的正确性是指什么呢？

大鸟 正确性是指：没有歧义，逻辑一致，表达清晰。

小白 可是如何保证软件需求的正确性？

大鸟 有下面两种方法。（1）明确用户动机。（2）正确的表达方式。

小白 既然我们已知道用户要什么，干嘛一定还要追究用户为什么要这么做呢？

大鸟 在福尔摩斯探案集里，每次锁定了犯罪嫌疑人后，除了拿出证据之外，读者更期待知道罪犯的动机是什么。同理，在需求阶段，用户想要什么只是表相。用户的痛点、难点、困难、处境、顾虑、背景等，这才是他们要这样干的原因。许多需求团队在进行需求捕获活动时，经常预期用户能够直接告诉他们要做什么（What），而不太关心用户提出需求的真正动机（Why）。这样就会经常引起下面这样的局面发生：“你要绳子，我给你了；你要木板，我也给你了；你为什么说这不是你想要的呢？”。我想程序员也有类似的问题想问自己的客户：“你要文本框，我提供了；你要一个表单，我也有了；你为什么说这个功能不是你想要的呢？”

小白 所以要透过现象看本质。

大鸟 是的。因为对于一个特定的问题来说，可能的解决方案会有很多，因此用户可能在使用软件的过程中会不断发现其他可选的、更合适的替代方案，从而导致了不必要的需求变更。而缓解这一现象的关键就在于，在需求捕获的过程中要多问“为什么”。还有一种情况是多个原因导致一个结果。

小白 不过虽然很多书籍里都强调需求是讲做什么（What）而不是怎么做（How）。但是实际上我感觉：只写What会导致开发结果不可控，所以某些项目管理人员在需求里面写了好多How。

大鸟 其实，当我们发现How没说清楚的时候，一定要反思Why说清楚了没有，因为需求人员并不是最佳决策者，他们也缺乏解决方案的知识，经验缺乏的结果会造成后期变更。如果程序员不知道Why就去做，很可能做拧了，结果就像欧亨利小说中的老板娘一样。欧亨利小说节选很久很久以前，一个男人天天都到一家小面包店里买两个隔夜的陈面包，新鲜面包是五分钱一个，陈面包五分钱却可以买两个。除了陈面包以外，他从来没有买过别的东西。时间一长，小店女主人开始注意这个男人，从开始的同情、怜悯，到后来对他的坚强和坚持产生好感。后来她得知他是一个艺术家，她想：他眼镜后面的目光是多么温柔和善啊！——但却靠陈面包过活！不过天才在成名之前，往往要经过一番奋斗。又过了很长时间，男人又来买面包，店主鼓起勇气，乘男人不注意，快速地在面包里面塞了一块黄油，然后男人拿走了。女店主开始不安，猜想男人发现后会怎样，会感动？会接受？还是自尊被打击，再也不来了。第二天，男人一早就出现在小店，发疯似地向女店主狂吼：“谁让你在面包里面加黄油的？一年了，我每天都加班到半夜，这幅设计图本来今天就可以完工了，谁让你在面包里面加黄油的！”原来，橡皮能擦掉铅笔字是1770年英国科学家普里斯特首先发现的。在这之前，人们是用陈面包来擦铅笔的。

小白 好心办坏事。

大鸟 女主人知道用户的需求（需要陈面包），但是却搞不知道用户为什么要这样做（擦画）；她以为是用来吃的（没搞清楚用户动机），想要把需求变更一下（夹了块黄油），结果好心做了坏事。同理只有切实知道用户的理由，你才能提供正确的实现方法。

小白 为啥这么做，先给我一个理由。

大鸟 下面是一个我工作中的案例。案例 曾经有一次我们Team做一个节点部署的软件。当时用户提出这样的一个需求：当节点部署完了之后，可以自动跑一个用户自定义的脚本（What）。我们当时部署节点的方式是通过OS模板（Template）方式来作。比如说你想安装一个操作系统为Rhel6.4的节点，那么你就得指定一个Rhel6.4的模板，然后方能部署。所以我们当时的解决方式是把用户自定义的脚本（Script）绑在了模板上，这样用户部署节点的时候，就可以自动执行这个脚本了（How）。从当时来看，这个解决方案确实解决了用户的问题。可是到了项目快结束的时候，用户却并不买账。我们又仔细调查了用户需求：原来用户想跑Script的目标节点是同时给多个组使用，不同的组有不同的模板，有的时候还要随时新建模板，并且期待在不同模板间的频繁切换（Why）。这样，把脚本直接耦合在模板上就不合适了（谁知道那个组用哪个模板呢）。所以，用户实际的需求是要解决在不同模板切换的情况下依旧保持脚本可以顺利运行。因此，目标节点应该和脚本直接耦合。搞清楚了Why才能弄明白用户是怎么玩的，你的How才不会是无的放矢。

小白 怎么才能弄清楚用户动机呢？

大鸟 如果你能够直接问用户或者项目负责人，那是最好的。如果没有这样条件，QA可以做一些推理，大胆假设，小心求证。其实，当你感觉这个地方动机不明、模糊的时候，这些都是QA的机会，别放过它。负责任的警探不会因为动机没搞清楚就匆匆结案，同理，负责任的QA也不会因为没搞清楚用户动机就匆忙测试。

2.4.3 如何保证软件需求的正确性：正确的表达方式

小白 正确性的第二条是正确的表达方式。需要什么表达方式吗？说出来不就完了，写出来不就得了。

大鸟 表达是一种沟通方式的问题。我们做软件一般是通过文档沟通，所有的文档都是书面语言。语言是一种非常无力的东西，心里想的是什么，一张口可能说的是另一个意思。场景：解说员的故事解说员韩某某：“守门员将球回传给门将”；“各位观众，中秋节刚过，我给大家拜个晚年”；“可能有的观众刚刚打开电梯，我们再把比分……”；“球被守门员的后腿挡了一下！！！”；“梅西又习惯性地舔舔自己的舌头”。

韩老师心里明明是这样想的，但表达出来后就是另一种意思了。这是语言描述的局限性。有些东西靠说是讲不清楚的，描述的过程中会造成信息扭曲。

可是文档的表述还不如口语呢，文档没有声音，没有图像，更没有语气。

小白 所以表达方式很重要。

大鸟 是的，所以我们要用正确的表达方式，具体包括如下几条。（1）直接沟通。（2）简洁描述。（3）减少定性描述。（4）词语的准确性。2.4.3.1 直接沟通

小白 您的意思是尽量做一些直接沟通。

大鸟 我们说PRD是很重要的，这没错，但是它再重要也就是一个文档。文档是死的而人是活的，所以不要局限在这个文档上。文档只是我们过河的一条船，我们的目的是过河。如果可以的话，和写文档的人多做一些互动、交互不是更好吗？获取需求的最好办法就是直接和客户面对面沟通，尽量不打电话；如果可以打电话，尽量不要用Skype；如果能用Skype，尽量不要发邮件。越直接，效果越好。找到项目相关的人，最好找到项目的接口人进行面谈，或者直接去用户那里，看看使用环境。2.4.3.2 简洁描述

小白 下一条是简洁描述。

大鸟 软件需求说明书，不是记叙文，而是应用文。应该概括段落大意，给出关键点。尽量用应用文的方式、短句的方式，不要长篇大论。2.4.3.3 减少定性描述

小白 所谓定性描述是什么呢？

大鸟 定性的词语也就意味着不确定。比如“系统对报警提供了有效的支持”、“两个报表间存在有效依赖关系”这两句话，你看其中的两个词“有效”、“依赖”。什么叫有效呢？表现在什么方面呢？依赖是什么呢？是数据依赖？还是流程依赖？这些都是定性的词语，如果审核时候发现了这样词语，QA就要问个为什么了，为什么不能用更加定量的方式来表述。

小白 怎样更加定量呢？

大鸟 用一个指标性或者经验值之类的东西来描述。比如写可靠性时，不写“高可靠性”，而是写“7×24小时不间断的服务”；写易用性时，不写“达到高易用性”，而是写“没有接触过本软件的初级用户能够不在帮忙的情况下30分钟理解所有功能点”。2.4.3.4 词语的准确性场景漫画：开封菜的故事甲：“对对对，我想起来了，这个地方有个挺好吃的，叫什么开封菜还不错。你到那里等我哦。”乙：“开封菜？”甲：“就是一白头发老头做的广告，叫什么KFC（KaiFengCai），再见！”

小白 词语的准确性是指什么？

大鸟 有时候需求文档中同一个词有多种含义，对于含混的表达，文档的作者必须基于这样一个理论：即文档的读者必须有一定的认知水平和认知标准。如果认知标准不同，必须加上清晰的注释。比如IB这个词是个缩写，在软件领域可以理解为IN BOUND CALL也可以认为是Infini Band，这种缩写一定要在需求文档中定义清楚。

2.4.4 一致性

小白 需求的一致性是指什么呢？

大鸟 一致性是指与其他软件需求或高层（系统、业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。只有进行一番调查研究，才能知道某一项需求是否确实一致。案例 系统管理员可以具备访问一切数据内容的权限。PCM用户的数据库仅允许自己访问。如果系统管理员可以访问一切数据库的内容，那也就可以访问PCM用户的数据库，可是PCM数据库仅允许自己访问。这就是不一致。

2.5 范围约束

小白 范围约束是指什么呢？

大鸟 范围约束限制了开发人员设计和构建系统时的选择范围。范围约束一般有如下三种。（1）用户的期盼超出了实现的能力。（2）非技术因素决定的技术选型。（3）预期的使用环境限制。

2.5.1 用户的期盼超出了实现的能力

小白 什么叫用户的期盼超出了实现的能力？

大鸟 这句话的本质就是实现的局限性。

小白 所谓的“属下无能，听凭教主发落”。

大鸟 用户提出了大量的需求，有些是技术上根本无法实现的，比如说一百年前如果有用户提出移动电话的需求，那么当时是实现不了的。

小白 后来技术突破了，就解决了。

大鸟 对，有些是费用预算内无法实现的。就像孩子不知道航天飞机上月球要多少钱一样，用户也不知道自己提出的需求要多大的成本。

小白 用户想掏买馒头的钱吃鲍鱼，显然不可能。

大鸟 还有一种情况是，我能实现，但是在这个时间期限内根本做不完。做不完怎么办？加人或者砍Scope，做不完的就砍掉了，也就是放在范围以外了。或者是这个版本我不支持，下个版本再支持。

2.5.2 非技术因素决定的技术选型

小白 非技术因素决定的技术选型是指什么？

大鸟 对于软件开发而言，有些技术选型并非由技术团队决定，而会受到企业/组织实际情况的影响，例如HPC软件产品原来采用的是Oracle数据库系统，但是现在由于一些实际的原因（法律或者其他非技术因素），采用了PostgreSQL数据库。

2.5.3 预期的使用环境

小白 预期的使用环境是指什么？

大鸟 用户的使用环境（使用场合、软硬件环境等）也会对软件的开发产生很大的影响，如果忽略了这方面的因素会给项目带来一些不必要的麻烦。一般使用环境包括如下几个方面。（1）硬件平台范围：产品支持哪些机器？内存大于多少？硬盘多少。

比如：● 机器类型——ETT/Dell系列/苹果系列等。● 内存——不小于4G。● 硬盘——至少500G。

注意：每类机器有不同的型号，如ETT3750，DellR510。（2）OS（操作系统）范围，支持哪些操作系统？

比如：● DOS。● Windows。● Linux（Rhel/Sles/Ubuntu）。● UNIX（Solaris/AIX/HP-UX）。

注意：OS还有小版本，如Red Hat 5.8，Windows 7等。案例 原来假设用户的环境是Sles11.2，没想到用户实际环境只有Sles10，从而导致很多基于Sles11.2开发的客户端程序不支持。（3）浏览器支持范围，支持哪种浏览器？这里要注意一点，浏览器支持往往与软件或硬件相关。

浏览器包括：Firefox，IE，Chrome，Safari，Opera等。

注意以下几点：● 浏览器往往支持多个操作系统，但其针对不同的操作系统有不同

的版本。比如Firefox，要弄清楚是哪个操作系统上的Firefox。● 有些浏览器的版本变化很快，要搞清是支持哪个版本。● 有些浏览器是支持移动设备的，比如Android上的UC浏览器。（4）预期的使用依赖。

有些软件预期的使用前提是有.NET平台支持，或者有其他第三方软件，忽略这样的情况，会造成实际使用时的尴尬。如果实在没办法解决，那么至少在对软件需求规格的说明中列举出影响需求陈述的假设因素。

2.5.4 审核Scope

小白 对于QA而言，在审核Scope时要做什么呢？

大鸟 要注意以下三点。（1）要搞清楚范围和超出范围的界定。如果确定不做的，就要将其写入范围之外（out-of-scope），不要不了了之。（2）要把超出范围而不去做的原因搞清楚。在此期间，QA可能要做一些调查，而不要完全听从PM和DEV的“忽悠”。搞清楚是Can't（不能）还是Won't（不愿）？（3）搞清楚完成此模块开发的假定事项或者依赖事项是否已表述清楚。

小白 PM和DEV还会“忽悠”QA？

大鸟 多了去了，人都有惰性。明明可以把事情做好，但不愿做的事情也蛮多的。从QA角度，你要搞清楚哪个是不能做的，哪个是不愿做的。

第3章 用户故事

3.1 什么用户故事

小白 大鸟，前两章我们讲了测试的本质是验证软件需求，还讲了如何去审核软件需求，保障软件需求的完整性和正确性。到目前为止，我们的需求含混性解决了吗？

大鸟 我只能告诉你：这样还不够！还不足以“设身处地”地替用户去考虑。我们需要一个画面式的场景来全真模拟用户的行为：我们的产品要为哪些人服务？他们的背景如何？他们有哪些亟待满足的需求？他们需要软件产品的什么功能？他们怎么去玩？想达到一个什么样的目的？想实现什么样的价值？这些都是我们要为用户想到的。

小白 那我们具体该如何“设身处地”地替用户去考虑呢？

大鸟 通过用户故事。

小白 用户故事是什么？

大鸟 你可以理解为：用户故事是一个备忘录似的交互模型，是从用户角度来描述用户渴望得到的功能。它强调的是通过有效、及时的沟通，帮助用户澄清和优化需求，用户故事有一个通用的模板，如下：As a role（作为一个角色）, I want to do something or a piece of functionality（通过某项功能，执行一些操作）, so that achieve some business value or statement of intent.（以便能够实现特定的目标/价值）

在这个模板中，有三个不同的关键点，分别为：● 用户角色（Who）。● 某项功能（功能即用户能亲自执行的操作）。● 实现了某个目标，获得了某种价值（Goal/Value）。

下面是一个例子：例 作为一个皇马的球迷，通过点击皇马官网的最新新闻栏，便能够实时了解最新的皇马动态。●“ 皇马球迷”（用户角色）。●“ 点击皇马官网的最新新闻栏”（功能/用户操作）。●“ 了解皇马的动态”（客户目标/价值）。

3.2 用户故事特点

3.2.1 体现用户价值

小白 用户故事主要是为了通过某个功能来体现用户价值。

大鸟 对产品而言，永远应该把那些最能体现用户价值观的功能置于最高优先级。

我们先看下面两个反例。例1 如果把“保存”按钮统一放在页面上端而非下面，那么对屏幕上侧的控件做些修改时，就无需滚屏即可保存了。例2 所有自定义字段，统一改为1000长度。

第一个故事勉强可以写为：作为一个用户，可以方便地点击上端的“保存”按钮，以便在某些控件修改的时候无需滚屏即可保存。

但是这个故事仅属于易用性优化级别而不是功能级别，颗粒度显得过小。而作为一个用户，这个需求显然和“增删改查”等功能需求，在价值上相差甚远。

第二个故事，找不到“用户”的位置，因为它是我们自己要做的改进，客户完全可以不感知。

所以，上面这两个用户故事都不能很好地体现用户价值。

3.2.2 不要出现技术术语

小白 用户故事由谁来写？是开发人员吗？

大鸟 不对，开发人员容易站在自己的角度去思考和划分故事，这样就背离了用户故事的初衷。一般用户故事是由用户来写的，或者由用户口述，我们的需求人员（有可能就是PM）来整理的。下面，让我们看看“卖香烟”这个例子。用户故事：卖香烟1．用户投入一些钱。2．售货机显示用户已经投了多少钱。3．如果投入的钱足够买某种香烟，这种香烟对应的按钮的灯就会亮。4．用户按了某个亮了的按钮。5．售货机卖出一包香烟给他。6．售货机找零钱给他。

注意到，一个用户故事里面的事件可以这样描述：

1．用户做AA。

2．系统做BB。

3．用户做CC。

4．系统做DD。

5．……

用户故事只是描述系统的外在行为，以客户能够明白的方式，描述了一个系统的外在行为，它完全忽略了系统的内部动作。如果是下面这样的用户故事：1．用户投入一些钱。2．售货机将塞进来的钱存在钱箱里，然后发送一条命令给屏幕，屏幕显示目前已经投入的金额。3．售货机查询数据库里面所有香烟的价格，判定钱足够买哪些香烟，对于钱足够买的那些香烟，对应的按钮的灯就会亮起来。4．用户按下一个亮起来的按钮。5．售货机卖出一包香烟给用户，然后将数据库里面该香烟的存货数量减1。6．售货机找零钱给用户。

不管是口头描述，还是书面形式，这样的内容是描述用户故事时一个很常见的错误。特别是千万不要提及任何有关数据库、记录、字段之类的、对客户一点意义都没有的东西。

3.2.3 可测试性

小白 可测试性是指什么？

大鸟 通常，不可测试的故事发生在一些非功能性的需求上。所以，可测试性意味着用户故事尽量采用功能性来做描述。

3.3 用户故事分解、细化、合并

小白 用户故事是对用户、对需求的描写，可能非常庞杂，甚至含混。

大鸟 的确如此，用户故事是对需求的细化和切分。既然是细化，就得有一个度，需求的颗粒度需要多少才能称之为用户故事？这就牵扯出和用户故事一起出现的另外一个关键的单词叫Epic（史诗级故事），通俗来说就是大型的故事。Epic有一些自身的特点：它是由许许多多的、较大的、不确定的需求组成，另外Epic本身不能直接通过其完成迭代（逐层分解）和开发，而是首先需要划分成较小的真正的用户故事。除了这两点，Epic因为包含了太多的模糊性需求，所以常常混杂了很多不同的特性，而一个特性就是一组可以归为一类的需求。Epic分为两类：（1）复合故事（compound story）：由多个小的故事组成。（2）复杂故事（complex story）：本身就很大且不容易分解的故事。

对于太小的故事，不值得去写故事和评估，则可以将其合并到需要半天或几天完成的故事中，比如缺陷报表和用户界面变更。

小白 那该如何细化呢？

大鸟 细化可以分成如下几种。（1）按用户角色细化。（2）根据数据边界来细化。（3）根据用户的操作来细化。

3.3.1 按用户角色细化

小白 你是说按用户角色来分，而没有说按用户来分。那用户和角色的区别是什么？

大鸟 这里有三个概念，即用户、角色和权限。

在应用系统中，权限的表现是什么？（1）对功能模块的操作，对上传文件的删改，对菜单的访问，甚至对页面上某个按钮、某个图片的可见性控制，都属于权限的范畴。（2）此外，有些权限设计，会把功能操作作为一类，而把文件、页面元素、机器列表等作为另一类，这样构成“资源”的模型。

角色是什么？可以理解为一定数量的权限的集合、权限的载体。例如一个论坛系统，“超级管理员”、“版主”、“普通用户”都是角色。版主可管理版内的帖子，可管理版内的用户，可以下载某些资源等，这些都是权限。要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个角色赋予该用户。

用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般是多对多的关系。而在做数据表建模时，可把功能操作和资源统一管理，也就是将它们都直接与权限表进行关联，这样可能更具便捷性和易扩展性（如下图所示）。

张三、李四、王五都是用户，但是很有可能他们的权限都一样。他们都是一种角色，所以按照用户来划分，会造成用户故事没有区分度。

小白 明白了，张三、李四、王五属于一种角色。

大鸟 他们属于一个“组”，当用户的数量非常大时，要给系统每个用户逐一授权（授角色），是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在的用户组拥有的权限之和。

当故事只为单一用户角色编写时，故事的可读性是最强的。比如这句话：“作为一个用户，我可以访问资产负债表数据。”可以做如下分解：例 作为一个用户，我可以访问资产负债表数据。——作为系统管理员（实际上是系统管理员组），我可以访问资产负债表数据；——作为普通用户（实际上是普通用户组），我可以访问资产负债表数据；——作为根（root）用户，我可以访问资产负债表数据。

3.3.2 根据用户的操作细化

小白 什么叫根据用户的操作来细化？

大鸟 一般我们用CRUD（Create/Read/Update/Delete，即增删读改）来细化。可以做如下分解：案例 作为一个用户，我可以访问资产负债表数据。——作为一个用户，我可以增加资产负债表数据；——作为一个用户，我可以删除资产负债表数据；——作为一个用户，我可以修改资产负债表数据；——作为一个用户，我可以阅读资产负债表数据。

小白 但是真实情况可能不那么简单。除了增、删、读、改等操作外应该还有激活、冻结等。如果要是安装测试的话，应该还有安装、卸载之类的。

大鸟 你说得没错，具体的内容我会在测试的分类里详细介绍。

3.3.3 按用户角色合并

小白 什么叫做按用户角色合并？

大鸟 对于太小的故事，不值得去写故事和评估，则可以将其合并到需要半天或几天完成的故事中，比如缺陷报表和用户界面变更。

第4章 审核FS

事实上，对于软件开发来说，含混性存在两个方面，一个是对目标需求的含混性，另一方面是实现方式上的含混性。实现方式的含混性主要是解决“给用户什么，怎么给，什么样的呈现方式”的问题。FS（Functional Specification，功能规格书）是更进一步回答“各个模块具体怎么做”的问题。

4.1 实现的含混性

小白 为什么会出现实现的含混性呢？

大鸟 原因有如下两个。（1）一个是科学的方法大多需要量化的度量技术。含混性的量化公式是：

含混性＝实现需求的最大花费/实现需求的最小花费

如果需求过于抽象，那么这个公式给出的含混性就可能非常大，而这种随意性很大的估值是非常忌讳的，很可能会造成亏本。（2）另一个原因，是我们拔高了我们的底层实现。很多时候，歧义来自于我们自身的能力，因为我们有足够的能力做到多样性，而这些多样性都体现出各自的特点，所以我们才会有了如此众多不同的选择。

通过严格的分析后发现，决定含混性的，始终还是应该由实现相应需求的不同方案的数目来确定的。含混性毕竟还是对这种实现的不确定性的度量。按照成本来度量，可能会存在两方面的问题。其一，许多不同的方案花费相差不大，但在具体实现的时候可能会造成一些执行上的偏差，而这种偏差在最开始度量的时候体现不明显；其二，虽然成本一般都对应着相应的解决方案，但是不排除少数解决方案之间存在大的成本跨度。这些情况大多主要影响的是实现，不过确实也需要提前注意。

小白 为了解决实现的含混性，从QA的角度上如何去关注？

大鸟 前面我们说过了，PRD文档重点体现产品的功能需求和各项指标的说明，开发人员拿到最终版的PRD之后，根据各个模块的不同，由不同的开发人员进行并行开发。各个模块开发人员根据该模块的功能需求和技术参数，输出各个子模块的FS。FS更进一步回答了“各个模块具体怎么做”的问题。其实你也可以把它理解为一种需求（开发级需求）：开发人员需要实现什么？开发期间、维护期间有何质量考虑？开发团队的哪些情况会反过来影响架构？

小白 FS是DEV写的？

大鸟 是的，是软件开发工程师写的。

小白 那么FS都包含什么内容？QA又该如何审核呢？有的时候FS非常复杂，QA很难看懂的。

大鸟 FS包括如下几项内容。（1）交付目标。（2）范围约束。（3）功能描述。（4）非功能描述。

至于QA该如何审核，我简单说一下。QA首先要做的就是把规格说明中不清楚的模糊点搞清楚，把项目相关人员之间的重要分歧摆平。把系统内在的复杂性梳理清楚，不要犯遗漏、误解和过于简化的错误。QA对产品、技术和一般测试问题了解得越多，自己的困惑就会成为更准的指南针，指出重要问题所在。

在测试过程中，如果对产品一无所知，那么至少要知道自己的困惑是什么。在这种情况下，困惑可以成为最佳交付内容，即提出也许其他人没有勇气提出的问题。

4.2 交付目标

小白 交付目标是指什么？

大鸟 交付目标是指，到底是要把它做成什么样。我们要交付（Delivery）给用户的到底是什么？是一个模块？一个补丁（Patch）？还是一个ISO（光盘）？是否还包含DOC（文档）？所交付的版本是否清晰？还是兼而有之？

小白 兼而有之是指什么？

大鸟 我们以前有这样的情况：当一个最新产品发布的时候，不但在软件路线图（roadmap）上是一个提升，会交付一个新版本的ISO，此外还要兼顾以前的版本，给出针对以往版本的不足和缺陷的补丁。这样的话，交付目标就有两个。像这种“兼而有之”的情况，我们要特别注意，不要漏了。

此外，对于集成产品（由多个子产品“攒”在一起的产品），还要注意每个子产品的版本号是不是正确的。由于每个子产品都要有自己的版本控制变化，要注意在集成产品中所用到的子产品版本是否是最合适的。

小白 最新的是不是最合适的？

大鸟 不一定，能解决用户问题的才是最合适的。

4.3 范围约束

小白 范围约束是指什么？

大鸟 参考PRD以前的范围约束，简单点说就是要做什么不要做什么。这里是换成具体模块的范围约束，审核方法也与PRD审核类似。

4.4 假设和依赖

小白 假设和依赖是指什么？

大鸟 假设和依赖是指对软件需求规格说明中影响需求陈述的假设因素（与已知因素相对立）。这可能包括你打算要用的商业组件或有关开发或运行环境的问题。你可能认为产品将符合一个特殊的用户界面设计约定，但是另一个研发工程师却可能不这样认为。如果这些假设不正确、不一致或被更改，就会使项目受到影响。

此外，确定项目对外部因素存在的依赖。例如，如果你打算把其他项目开发的组件集成到系统中，那么你就要依赖那个项目按时提供正确的操作组件。如果这些依赖已经记录到其他文档（例如项目计划）中了，那么在此就可以参考其他文档。

以ETT公司的HPC软件交互式安装为例，我们来看一下安装过程中我们都有什么假设和依赖：案例 ETT公司的HPC软件交互式安装假设条件● 管理节点上已经安装了支持的操作系统。● 用户已经阅读了安装文档，并知晓了相关的先决条件和局限性。● 用户已经安装了相关软件包。● 用户已经从ETT公司授权得到了一个合理的License文件。依赖性——集成包依赖● 集成包包括了若干个软件包，包含A，B，C等。所有软件包将以RPM方式安装上。如果这些包出现问题，不能保证软件安装包能正常安装。● 合理的License（许可）文件。

4.5 功能描述

小白 这个功能描述和PRD里面的功能需求相比较来说，有什么区别吗？

大鸟 PRD侧重于把系统要解决的业务逻辑、要实现的功能描述清楚，更宏观；需求规格说明书侧重于把系统的某个功能点的具体约束、输入、输出和处理过程定义讲清楚，更具体。

以软件交互式安装为例，PRD里的功能需求无非就是顺利安装成功。

但是安装中的每一步、每一个过程，比如安装路径、安装端口、设定安装网段、定义域、定义输出结果等，也就是说安装过程中所做的各式各样的每一步操作都要在这里定义好。

4.6 审核功能描述

小白 如何审核这些功能描述呢？

大鸟 主要审核功能描述是否包含如下特质。（1）质量需求或产品特性的描述是否足够准确。（2）实现方式可扩展性。（3）技术合理性。（4）集成和升级风险。（5）理解一致性。（6）设计一致性。

4.6.1 质量需求或产品特性的描述是否足够准确

小白 质量需求或产品的特性描述会不准确吗？

大鸟 质量需求或产品的特性描述不准确，将导致DEV/QA和设计人员对产品特性有歧义，结果使某些地方始终测试不到或验证的标准不对。例 一个iPhone用户来到苹果5S店，他想说“我要越狱”；结果想了半天，也没想出来，最后说了一句“我要出轨”。苹果店的服务人员若有所思地想了一会儿，给这个用户手机上装了微信。

小白 这是什么原因造成的呢？

大鸟 当存在这种问题时，你顺着线索往上，最后就能推算出来，是PRD标准或者用户故事写得太模糊了，到了设计层面，研发工程师就跟着倒霉。因为用户需求的模糊，我们可以给出多种实现方式，所以出现这种问题时，我们要反思用户故事是否足够细化。

举个例子来说，“当机房机器CPU温度超过60度的时候，系统管理员需要被通知到。”我们可以有如下的实现方式。（1）我们可以在GUI实现Alert方法，当温度超过60度的时候在GUI界面上报警提示。（2）我们可实现邮件服务器，当温度超过60度的时候给管理员发邮件提示。（3）当机器CPU温度超过60度的时候，可以亮灯报警，如果看机房的人看到后，可以给管理员打电话。（4）当机器CPU温度超过60度的时候，可以智能给管理员手机发短信。

说不定还有其他实现方式。

小白 感觉第4种方式最智能，第3种方式最土。这么多种实现方式，哪一种才是合适的呢？

大鸟 的确，至于说怎么才算合适，就要看进一步探求用户需求的结果，还要看测试者的经验以及业界的相关标准。

但是越智能的功能，越需要额外的努力，如果时间/人力不允许，或者如果用户可以买账第3种方式，也未尝不可啊。一句话：合适不合适，还是由用户需求决定。

4.6.2 实现方式可扩展性

小白 实现方式可扩展性是指什么呢？

大鸟 开发一个软件，不是一锤子买卖，我们要考虑软件接口是否可以通用，代码的可复用性，软件是否可扩展，设计当中会不会有些是hard code（硬编码）处理的，等等。

小白 别写死了。

大鸟 是啊，比如说这个软件暂时是给Rhel平台使用的，但是谁知道将来会不会给Sles使用呢？如果代码写死了，万一将来扩展起来，岂不是很麻烦。所以我们在审核FS这一层时，就要看看将来解决方式是否可扩展。

4.6.3 技术合理性

小白 如何审核技术合理性呢？

大鸟 这是指审核设计人员对产品技术的选择是否合理，是否选用了成熟合理的技术。

当研发工程师为了实现一个功能的时候，或许手头上有一个从网上复制的示例模块，看上去这个可以使用。假如正好它暂时满足了你的需要，你会对这个模块稍加改动，添加一些代码，然后再加一点。你根本就不知道自己在做什么，只是不断地做一些小的修改，直到这个模块完全满足你的需要。但问题是，这样做就像是用纸牌搭建房子，每增添一张纸牌，就增加了一分纸房子坍塌的危险。你根本就不知道这个模块到底是如何工作的，所以你每做一点儿改动，都有可能导致你的模块完全失败。

小白 不成熟的技术虽然暂时解决了问题，但是会留下隐患。

大鸟 是的，急功近利的做法要不得。

4.6.4 集成和升级风险

小白 集成和升级风险是指什么？

大鸟 举个例子吧：ETT公司的HPC产品由三个集成模块构成，A模块、L模块和P模块，其中一个小模块P需要升级了，例如从原来的P706升级到P901。如果研发工程师没有做调查就直接进行集成，有可能一些旧的环境变量在新的HPC版本上不工作，从而给QA的后续工作造成极大困扰。

小白 那QA该怎么办？

大鸟 辅助DEV一起对变更模块进行调查，搞清楚该模块之前的行为结构和现在的区别，变更点主要是哪些。这些都要吃透。

4.6.5 理解一致性

小白 理解一致性是指什么呢？

大鸟 对于同一个项目的某一个实现点，QA要确保各个部门（相关的责任人和利益方）对数据库、接口、API的理解在同一层面上。

小白 这还能理解不一致吗？

大鸟 挺多的，不同Team站在不同角度，有不同的诉求。下面是HPC管理网络脚本的一个案例。案例 HPC管理网络脚本最早是由后台DEV进行开发的，当时只是一个系统的辅助功能，并没有暴露给用户。但是后来HPC网络管理升级了，新的需求允许在GUI（前台图形界面）上将网络脚本暴露给用户。前台工程师觉得既然之前后台已经做好了，那我直接调用以前的脚本就是了。而后台工程师想反正只是在前台暴露，又不在后台体现，那我就什么都不用做了。这样的话，两方面都理解错了。最后导致，旧有后台工程师的网络脚本的提示信息、容错机制等都无法满足现有用户需求，最终项目失败。

4.6.6 设计一致性

小白 刚才说了理解的一致性，那现在又说设计一致性是指什么呢？

大鸟 设计的一致性是指设计的元素在视觉、体验、操作上具有传承连贯性。主要检查设计是基于公司/业界标准，还是自己另起炉灶——这样的话就增加了用户的理解难度。当然，对技术的改进另当别论。

小白 具体有哪些表现呢？

大鸟 有的表现为工具界面，也可能是操作流程，也有可能是输出结果。工具界面的测试我们会在UI测试中讲，现在说一下操作流程。关于操作流程，比如说我原来是先做A后做B然后做C，现在改成了先做B后做C然后做A。如果不是技术革新，那就值得商榷一下：为什么要做这样的变化。

4.7 非功能描述

小白 这个非功能描述和PRD里面的非功能需求相比较来说，有什么区别吗？

大鸟 FS里面的非功能描述侧重于描述系统某个模块各个非功能点的具体约束。审核方法还是参照审核PRD的方式，在这里不再赘述。

第2部分 软件功能性测试

第5章 功能性测试的准确性和合适性

5.1 功能性测试概念

小白 功能性特性是指什么？

大鸟 功能性特性是指当软件在指定条件下使用时，软件产品提供满足明确和隐含需求的功能的能力。

小白 显性需求我能理解，就是指用户提出来的实际需求，这里的隐含需求是指什么呢？

大鸟 隐含需求是指由一种商品需求/供应引起的对另外一种商品的需求，比如买了红酒的顾客可能会顺带买一个开瓶器。隐含需求的不确定性主要取决于消费者的需求，且商品的复杂度越高，隐含需求不确定性就越高，因为顾客不确定是否需要该商品的新功能。在软件测试中，这些隐含需求包括如下几点。（1）用户的隐式需求。例如：行业规则、业务规则、原来系统已经实现的约定俗成的操作或功能等。对于这些需求，设计人员往往认为研发团队会知道这些规则，所以没有在需求中显式描述。这些地方由于没有明确约定，又缺少沟通，往往成为最容易出现缺陷的地方，不容忽视。（2）计算机领域的规范或习惯。这些方面是很难写到业务需求中的，因为业务需求往往是文字描述，很难准确描述系统的展示界面。例如，如果某个需求是输入有限个元素，则应该用列表框或选择框控件实现，而用编辑框来实现则要在输入中做很多判断，大大增加编程工作量，也增加测试工作量，同时给用户带来不便。（3）客户认为我们应该理解或在需求中遗漏的需求。例如，客户认为我们理解金融行业的会计规则，但是如果不在测试需求中明确说明，则由于测试工程师没有金融行业会计方面的测试经验而忘记测试。（4）业务需求编写人员受自身计算机技术能力限制，不知道性能指标如何描述或描述得不准确。这就需要测试团队协助科技人员和业务人员把正确或隐含的性能指标需求显式地描述清晰，把描述不准确的需求纠正过来。

5.2 功能性测试分类

小白 功能性测试都包括哪些？

大鸟 软件功能性测试主要包括下列几类。（1）适合性（Suitability）测试：系统实现的任务是否与软件属性相适合。如面向任务系统中由子功能构成的功能是否合适、表容量是否合适等。（2）准确性（Accuracy）测试：准确性是指，与能否得到正确或相符的结果或效果有关的软件属性。例如，此属性包括计算值所需的准确程度。（3）互操作性（Interoperability）测试：互操作性是指，与同其他指定系统进行交互的能力有关的软件属性。为避免可能与易替换性的含义相混淆，此处用互操作性（互用性）而不用兼容性。（4）依从性（Compliance）测试：依从性是指，使软件遵循有关的标准、约定、法规及类似规定的软件属性。（5）安全性（Security）测试：安全性是指，与防止对程序和数据进行非授权的故意或意外访问的能力有关的软件属性。

5.3 适合性测试

小白 能不能细讲一下软件的适合性？

大鸟 简单点说吧，测试人员拿到一款软件之后，首先要看这款软件有没有实现客户需要的功能，这就是“适合性”，即所提供的功能是用户所需要的。这里的定义包含两个问题：（1）有还是没有的问题。（2）合适还是不合适的问题。

小白 什么是“有没有”？

大鸟 有没有就是指基本的功能在不在，工作不工作。比如说GUI界面的增删读改按钮。能点击，能工作，那基本功能就有了。

小白 这个很容易理解，那您还说了，这里面还有一个合适不合适的问题。

大鸟 举个例子来说，“当机房机器CPU温度超过60度的时候，系统管理员需要被通知到。”对此我们有多种实现方式，就看实现的合适不合适了。至于说怎么才算合适，就要看测试者的经验，而且还需要进一步探索客户的需求，还要看业界的相关标准。

5.4 准确性测试

小白 明白了，那什么是软件功能准确性测试呢？

大鸟 软件所实现的功能是否正确，是否能够使用，这就是“准确性”；另外，软件产品还要具有所需功能给出正确或相符的结果或效果的能力。即软件除了能实现所要求的功能外，还要求能正确实现所要求的功能。还拿上面的例子来说：“当机房机器CPU温度超过60度的时候，系统管理员需要被通知到。”结果实际情况是，当温度50度的时候，邮件就发出来了。

小白 不准确了。真理要是再向前迈半步就是谬误。

大鸟 你做了我不需要做的事情，就是不准确了。真理往往是刚刚好的状态，再添一点或者再减一点就会不符合实际。另外真理也是会变质的，随着事物的发展，刚才是真理的东西等到下一刻可能就不是真理了。

第6章 软件功能性测试用户故事

6.1 软件功能性测试故事表

小白 适合性和准确性，从软件功能测试的角度来说，应该是一个目的。对吧？

大鸟 从功能性角度来说，这是最基础的目的。

小白 目的只是用户故事的一部分，对吧？有没有比较全面的用户故事表呢？

大鸟 为了让读者能对功能测试有一个比较清晰的认识，我们做了一个比较全面的软件功能测试的用户故事表。这里基于如下的用户故事：As an Actor（作为一个执行者），I would like to do this Action（我实施了这样的行为/诱因）on this Object that is in this State（在这样的情况/状态下），using this Method（使用如下方式）so that achieve some business value or statement of intent（以便能够完成特定的目标/价值）And made the following verification（做了如下的验证/检查）.

对这个故事呢，我们看重六个方面：谁是执行者、行为、情况/状态、方式、目标/价值、验证/检查点。

小白 上次我们讲用户故事的时候，只有三个方面。谁做了什么样的行为，实现了什么样的目标/价值。为什么在这里要另加三个方面？

大鸟 上次讲用户故事主要是从需求的角度来讲，然而从测试的角度来看，必须要加上如下三点：情况、方式、检查点。详见下面这个列表。

6.2 执行者/行为/状态/预期结果/检查点

小白 对于执行者，系统管理员和客户、负责人和部门成员都代表了不同权限，这个我能理解。但是我对生产者和消费者不是看得很懂。这个是指什么呢？

大鸟 我给你举个例子吧，超市和自助餐改变了原来的商店销售和餐厅服务模式，消费者部分的自助服务，换来了更多元、更自如舒适的选择。

种植者原本需要辛苦摘下苹果，运到城市，卖个（每斤）四五块钱的价格，但是采摘活动却让消费者“辛苦”参与劳动，而且使种植者以两倍或者更高的价格销售苹果。像采摘（体验自然和劳动）、陶艺（体验手工并享受艺术创造）、钓鱼（感受安宁并享受休闲）这类活动，都是给消费者提供了独特的体验，收益在生产过程中发生，收获的是愉悦和满足。

在互联网企业，也有类似的情况。比如整个网站都建立在用户贡献内容这个基础上，所以部分消费者转变为生产者，或者绝大多数消费者都参与了生产，对Blog来说是这样，对微博和Facebook也是这样。在互联网时代，生产、消费是交织发生的。

对于生产者和消费者来说，他们各自的权限和执行方式也不一样（但也可能互相转化）。所以，我们在这里做此分类。

小白 对于接下来的行为/状态/检查点。我知道检查点是对结果的检查，行为和结果也比较容易理解，因果关系嘛。但是State（状态）是指什么呢？按我的理解，用户实施了这样的行为，然后就得到了这样的目标/价值。这就足够了啊，为什么还要有一个额外的“状态”或者说条件呢？

大鸟 你说得没错，行为和结果的确是一个因果关系，但是有因不见得有果，中间还有个“缘”字。比如说人接触了甲H1N1型病毒，就一定会高烧，会呕吐腹泻，会肌肉酸痛，然后会死人吗？答案是，不一定。为什么不一定？如果你的身体不给它提供那种发病条件的话，就算是你感染了，也会相安无事。

病毒发病含有两个条件：第一，有一个诱因；第二，有一个生长条件。这个病毒或者细菌呀，它是个因。那么，有了它就会造成我们出现的这些病理症状吗？这个因进到我们身体里了，但是呢，我们没有病毒赖以生存的那种生长条件，病毒就呆不住，就不会发病，对吧。

小白 唔……作为一个皇马的球迷，通过点击皇马官网的最新新闻栏，以便能够实时了解最新的皇马动态。点击这个动作是因，了解皇马动态是结果。这就是直接的因果关系啊。

大鸟 嘿嘿，还是不一定。虽然你是皇马球迷，但是①你权限不够，点击不了；②出于某种原因，皇马官网的最新新闻栏被锁定了，相关的Button变灰，点了没反应。所以说，从功能测试的角度来看，你不一定能获得你期望的结果，甚至得到了别的结果。

小白 所以你说的State实际上就是个“缘”？

大鸟 State的说法可以有很多了，比如缘、内因、条件等等，是吧。Action是因。

小白 Action和State到底有啥区别？

大鸟 原因和结果在时间上是一个先后关系，而状态/条件/情况是已经存在的客观事实。

小白 预期结果和检查点是指什么呢？

大鸟 软件缺陷是经过对比而得出来的。软件测试必须有预期结果，没有预期结果的测试是不可理喻的。这正如没有标准无法进行度量一样，如果我们事先不知道或是无法肯定预期的结果，我们必然无法了解测试的正确性。不少测试人员常常凭借自身的感觉去评判软件缺陷的发生，其结果往往是把似是而非的东西作为正确的结果来判断，因此常常出现误测的现象。

6.2.1 添加数据

小白 好的，我们现在把用户的行为一条条来过一下。首先是添加数据。

大鸟 让我们假设往一个文本输入框里来添加数据，包括如下一些情况。（1）空数据。（2）合法数据。（3）添加中断机制。（4）添加文件/图片。（5）特殊字符字段。（6）带空格字段。（7）带回车键字段。（8）字段长度。（9）数字型边界。（10）数字的约束。（11）字段类型。（12）重复添加。（13）单选按钮。（14）复选框。（15）列表框。（16）上下控件文本框。（17）日期约束。6.2.1.1 空数据

小白 空数据的情况是指用户没有输入任何内容是吧？

大鸟 是的。用户有可能没有任何输入，即输入数据是一个空数据。

小白 那这种情况到底是合理呢还是不合理呢？

大鸟 这个要看具体情况。比如手机中的电话号码簿：只输入用户姓名，没有输入号码。这种情况是合理的。为什么呢？我们允许用户不用一次输入完全部信息，下次可继续输入。

再比如另一种情况：某个网站，注册新用户，用户名是必须输入的，否则没法做验证。

对于这种必需输入的数据条目，在数据框前应该清楚地指出这是必须输入的数据条目字段。

对于强制输入的字段，在屏幕上最好有些标识以说明其为必须输入的字段。一般在字段前或后用红色的“*”号表示。测试时必须要检查有标识的字段是否和功能说明书或其他参考文档所要求的一致，错误信息提示是否正确，强制输入的字段是否真的必须输入。6.2.1.2 合法数据

小白 合法数据是指什么？

大鸟 就是指所有输入字段为合法数据。另外，点击“保存”按钮时，要注意如下一些检查点：（1）系统应该有保存成功提示信息。（2）在数据库中有新保存的数据。（3）通过查询页面，也可以查询到添加的数据。（4）有时程序会把合法数据当作非法数据处理。比如添加IP时，认为223.255.255.255不合理，其实这种IP是合理的，只是系统没有考虑到子网掩码是255.0.0.0的可能性。6.2.1.3 添加中断机制

小白 添加中断机制是指什么啊？

大鸟 有两种情况要考虑。一种情况是还没添加呢，就想退出了。这种情况应该允许用户直接退出。还有一种情况是，添加了一半，突然不想继续了，反悔了，已经添加的不想要了。

小白 还能这么搞？

大鸟 当然可以，事是死的，人是活的；不是人照着事做，是事跟着人变。假如做一件事情，就必须至死不变地照做，那么世界上就没有解约、反悔、道歉、离婚等许多事了。

小白 这种情况要怎么处理？

大鸟 还是给出合理的提示吧。比如一封邮件写好了，然后取消掉。至少要问一下用户是否保留邮件内容，或者取消中断的操作。6.2.1.4 添加文件/图片

小白 添加文件/图片的检查点是什么？

大鸟 上传、下载文件的功能是否能实现；上传的文件能否打开；对上传的文件格式是否有规定；变化选择格式后，显示的内容是否也一并变化；系统验证是否正常；系统是否能正常读取上传和下载的文件。

此外，对于图片预览的功能，对于没有上传的图片，在查看编辑页面时，是否显示默认图片；如果上传了图片，是否显示上传的图片（因为实际工作中很多客户很介意图片显示为红叉）。6.2.1.5 特殊字符字段

小白 特殊字符字段是指什么呢？

大鸟 举个例子来说：单引号。大多数基于SQL的数据库系统在用户存储包含单引号的信息（例如John's car）时会出现问题。对于每一个可以接受文字、数字型数据条目的屏幕，都要试试输入包含一个或多个单引号的文本。

其实不只是单引号，基本上测试人员应该测试所有的特殊字符：单引号、逗号、/、＜、＞。因为这些特殊字符对于Web应用程序来说，都是很容易引发错误的。下面是一个特殊字符测试列表：● 输入半角/全角，大写/小写英文字符● 输入半角/全角数字● 输入简体中文字符（默认全角）● 输入繁体中文字符（默认全角）● 输入全角特殊字符：！＠＃￥％……＆*（）● 输入半角特殊字符：！@#$%^&*()● 输入html字符： （空格的转义字符）；；
；；；< /tr>；；

小白 带空格字段是指什么样的情况呢，是指中间有空格吗？

大鸟 不只是中间，应该包括以下几种情况：（1）中间空格如“aaa aa”，看看保存时是否会过滤掉或过滤成一个空格。（2）输入正常内容的前、后、中间加入多个空格，如“ aaaaa”或“aaaaa ”，看看保存时是否会过滤掉或过滤成一个空格，以及是否算入长度来计算空格。

后者这种情况，如果你单独测试一个平台时没有什么问题，但一旦涉及不同系统间的互操作性可能就有问题了。案例 用户在Linux下安装某个软件并创建文件夹名时多输了一个空格作结尾，结果映射到Windows下生成的文件夹就不可移动/删除，文件不能运行，而且不能在相同目录中建立同名不带空格的文件夹。这种以空格为结尾的文件名、文件夹名会给普通用户带来很多麻烦，没有任何好处。所以，这里要考虑是否允许用户创建以空格结尾的文件名、文件夹名的情况。（3）输入半角/全角空格的情况。（4）只输入空格是否正确，能否正确保存，如不能保存是否有提示。6.2.1.7 带回车键字段

小白 带回车键字段是指什么样的情况呢？

大鸟 回车键包括如下几种方式。● 是否允许输入换行回车。● 保存后显示能否显示输入时的样式。● 只输入换行是否正确并能否正确保存。● 若不能查看是否有提示。6.2.1.8 字段长度

小白 字段长度是指最长能输入多少字符的情况吗？

大鸟 最长最短都要测。应该包括以下几种情况：（1）测试可以输入的最短字符：假设最短限制为N个字符。测试输入1个字符、N－1个字符、N个字符、N＋1个字符等情况。（2）测试可以输入的最长字符：假设长度限制为N个字符。测试N－1个字符、N个字符、N＋1个字符、N＋N＋…（超长）这几个边界值。

功能说明书上应该清楚地指出可以在字段中输入的字符数（例如，first name必须是50个或更少的字符）。一般对于限制长度的字段，现在开发时大多采用限制输入的方法（设置字段的长度）来处理。所以测试时需要测试限制的长度是否合理（和功能说明书或其他参考文档相一致），对于没有限制长度的字段，要测试无穷输入时是否出错。如下图所示。

可以通过写测试用例来保证用户只可以输入特定的字符数，防止用户输入比允许范围更多的字符。因用户已输入过多的字符而给出的错误信息要清晰准确，如下图所示。（3）复制大于长度的值粘贴进去看看是否能输入。6.2.1.9 数字型边界

小白 数字型边界测试主要指什么呢？

大鸟 对于数字型的字段，测试上下边界是非常重要的。例如，如果你正在计算某个账户的利息时，你永远不会输入一个负的利息数给应该赢取利息的账户。因此，你应该尝试用负数测试。同样，如果功能说明书上要求字段在某一个特定的范围（如从10～50），你就应该尝试输入9或51，它应该给出一个得体的信息表示失败。

在边界值测试同时，最好结合等价类以及一些特殊数字进行开展，如这个例子里面的负数，虽然账户利息永远不会出现负数，但是如果系统中一旦输入负数，系统就崩溃，那么这样的系统对于客户来说也是非常危险的。6.2.1.10 数字的约束

小白 数字的约束测试是指什么呢？

大鸟 大多数数据库系统和编程语言允许数字条目被识别为整数或长整数。通常，整数的范围是从－32,767～32,767，长整数的范围从－2,147,483,648～2,147,483,647。对于那些没有特定边界限制的数字数据条目，用这些限制测试以确保不会出现数字的溢出错误。

小数型的数字字段同样也需要额外的测试。一般对于未指出数字类型的字段，尝试输入负整数、负小数、0、正整数、正小数进行测试。6.2.1.11 字段类型

小白 字段类型主要是指什么呢？

大鸟 某些字段类型测试是有特定数据输入要求的。如数字字段，有电话号码、邮编等。测试屏幕上每一个被指出有特定类型的字段，是为了保证你输入基于字段类型的、符合正确格式的数据（数字型字段应该不允许字符或特殊字符，日期型字段应该允许输入一个正确的日期等）。

其实这里还有一个字段格式和字段内容的测试。有些字段对输入的格式有要求，这些字段的格式一般在屏幕上也有相应的提示。所以在测试时需要测试提示的格式是否合理（和功能说明书或其他参考文档相一致）以及系统是否正确识别输入的格式。有些字段对字段的内容有限制，如常见的用户名，不能包含特殊字符，首字不能为数字等要求。所以在测试时需要测试提示的格式是否合理（和功能说明书或其他参考文档相一致），还需要测试在输入不符合内容要求的数据时系统是否正确地处理。下面分别举三个例子来详细介绍。例1 邮箱输入框字段校验测试● 输入合理的英文及数字字符组成的正确格式● 格式正确的前提下输入第一部分中的异常字段校验● 输入无@的格式，如：ab.com● 输入@前无内容的格式，如@b.com● 输入@后无内容的格式，如a@● 输入@前后均没有内容的格式，如@● 输入没有域名的格式，如a@b.，a@b● 输入E-mail中有多个@的格式，如a@@b.com，a@b@c.d● 输入@后面直接跟域名的格式，如a@.com● 输入@后面有多个分隔符的格式，如a@b.c.d，a@b.c.d.e● 输入@前面有分隔符的情况，如a.b@c.d，a.b.c@d.e，a.b@c，a.b.c@d例2 验证码输入框字段校验测试● 不输入，空内容● 空格输入● 输入空格＋正确验证码，空格出现在开头、中间、结尾均需要测试● 输入4位其他非数字内容● 输入第一部分中的异常字段校验● 输入前3位或后3位验证码正确数字● 输入4位正确验证码＋其他数字例3 邮编输入框字段校验测试（假设限制6个字符，只能输入数字）● 不输入，空内容● 空格输入● 输入空格＋数字，空格出现在开头、中间、结尾均需要测试● 输入其他非数字内容● 输入第一部分中的异常字段校验● 输入1个数字● 输入6位数字● 输入超过7位数字● 输入超长全数字测试6.2.1.12 重复添加

小白 添加重复数据会是怎样的情况？

大鸟 如果需求规定输入字段不能输入重复数据，那么验证程序对重复数据应该控制。如果输入内容不允许同名，还要检查是否区分大小写的情况。在输入的内容的前后添加空格，看看系统是否对此做出正确的处理。如果输入重复数据，程序不能崩溃，程序对重复数据的错误提示信息清晰准确。

小白 以上我们说的几种情况都是文本框形式，还有没有别的方式？

大鸟 有，其实添加数据我们还有别的形式，比如说单选按钮、复选框、列表框、上下控件文本框以及日期约束等等形式。6.2.1.13 单选按钮

小白 单选按钮是指什么？

大鸟 单选按钮（Radio Button）是必须选且只允许选中一个按钮；一组单选按钮在执行同一功能时，初始状态必须有默认值，不能为空。比如选择男、女单选按钮，在页面初始时，必须有一个被默认选中。6.2.1.14 复选框

小白 复选框控件是指什么？

大鸟 复选框（Check Box）可以同时选中多个选项。验证点如下。（1）查看是否允许选中所有框体。（2）部分选中若干个框体。（3）一个都不选的情况。（4）选中全选框时应该选中当前页所有选项，而去掉当前页某个选项的勾选时，则全选框也取消选中。翻页后，自动去掉已勾选的选项及全选框。（5）在以上几种情况下，查看控件状态，执行选中复选框的功能；如至少有一个必须选中，检查程序是否存在友好提示。6.2.1.15 列表框

小白 列表框控件主要验证什么？

大鸟 列表框控件（List Box）主要验证如下几方面。（1）列表框条目内容是否正确。（2）列表条目比较多时要使用滚动条。（3）挑出部分条目选择，验证功能实现是否正确。（4）列表框如果允许多选时，利用Ctrl键和Shift键查看鼠标多选条目的情况。（5）键盘帮助选择的情况，如上图左边所示，如果用户键入Are，就可以立刻跑到Are开头的条目那里。6.2.1.16 上下控件文本框的测试

小白 上下控件文本框的测试主要测什么？

大鸟 上下控件文本框（up-down）主要验证如下几方面。（1）上下箭头的可控性：直接输入数字或用上下箭头控制。如在“数目”中直接输入10，单击向上的箭头，使数目变为11。（2）边界检测：对于使用上下箭头控制数字的情况，如控件中的数字为最大的限定数字32767时，单击向上箭头，数目应该不变化，反之亦适用；直接输入超边界值，系统应该不允许输入或者提示重新输入。（3）输入默认值、空白内容。比如“插入”的数目为默认值，点击“确定”按钮进行测试；删除默认值，使内容为空，然后点击“确定”按钮进行测试。（4）输入字符。此时，系统应提示输入有误。6.2.1.17 日期约束

小白 日期约束是什么情况？

大鸟 日期约束测试包括5方面。（1）日期校验

对于日期型的字段，测试上下边界是很重要的。日输入的最小天数－1；根据不同的月份输入最大天数＋1。

此外，如果你正在检查一个出生日期的字段，出生日期很大可能不会早于150年前。同样，出生日期应该不是将来的某一天。一般来说，每种数据库系统的日期都有个范围，如SQL Server最小日期是1753年1月1日，所以如果是输入型的日期字段，同样也应该测试早于1753的日期。（2）月份校验

月输入的最小月份－1天以及最大月份＋1天，看看程序是否进行日历验证，是否存在友好提示窗体。（3）年份校验

查看设计文档，非闰年，月输入2、日输入29；闰年，月份输入2、日输入30。看看程序是否进行日历验证，是否存在友好提示窗体。（4）日期格式检查

查看设计文档，检查日期格式的合法性，例如2010-05-28、2010/5/28、20100528、2010.05.28。（5）时间格式验证：包括时间校验和格式检查。

时间校验：查看设计文档，输入24时；输入60分；输入60秒，看看程序是否进行时间验证，是否存在友好提示窗体。

格式检查：不合法格式如“12:30:”、“1:3:0”等。

6.2.2 显示数据

小白 显示数据主要检查哪些内容？

大鸟 主要包括如下几个方面。（1）分页显示。（2）显示数据的一致性。（3）显示信息归类的合理性。（4）滚动条。（5）陈旧数据的及时更新。（6）对数据进行排序。（7）避免遮蔽。6.2.2.1 分页显示

小白 分页显示是指什么呢？

大鸟 当用户查看数据时，如果数据比较多，就需要分页显示数据。

小白 分页显示数据主要验证哪些方面？

大鸟 分页显示数据的检查点如下。（1）首页、上一页、下一页、尾页四个按钮：在存在数据时，控件的显示情况；在无数据时，控件的显示情况（无数据时，上述四个按钮应该隐藏，如果存在数据，且数据能够在一页内显示完全，上述四个按钮亦应该隐藏）。（2）在首页时，首页和上一页是否可单击；在尾页时，下一页和尾页是否可以单击（默认应该为灰，不允许单击）。（3）在非首页和非尾页时，按钮功能是否正确。（4）翻页后，列表中的记录是否按照指定的顺序进行排序（曾经遇见这样的情况，翻页前按照用户名称排序，翻页后居然按照用户ID排序了，因为翻页过程中进行了初始化处理）。（5）总页数是否等于总的记录数/每页指定显示的条数。（6）当前页数显示是否正确。（7）指定跳转页跳转是否成功。（8）输入非法页数时，是否给出提示信息。（9）是否存在默认每页显示条数。（10）是否允许用户自定义显示条数，设定后，显示的条数和页数是否正确。6.2.2.2 显示数据的一致性

小白 显示数据的一致性是指什么？难道数据会不一致吗？

大鸟 会的，有两种情况。

由于数据源不一样，显示的数据就不一样。看下面这个图：数据Summary里有一个Free Memory的数据，NodeList也有一个Free Memory的数据。但是它们来自不同的数据源，所以数据不一致。这是个Bug，要统一数据源。

还有一种情况是，前台数据和后台数据同步时间不一致，从而导致显示数据不一致。如上图所示，两个Free Memory的值各不相同，必然会给用户造成困扰。后台的数据实时来自于数据库，所以是比较真实的。前台的数据却不是实时刷新的。比如三分钟刷新一次的话，前台数据就是后台数据三分钟前的数据。

小白 那就应该实时刷新了呗？

大鸟 这个东西还是要看需求。比如你要看火箭的曲线和数据，这样的情况显然需要实施响应。而有些就是看看节点的内存大小，不需要那么实时，但一定要保证数据源的一致性。6.2.2.3 显示信息归类的合理性

小白 显示信息归类的合理性是指什么呢？

大鸟 你看菜市场卖水果的，苹果和苹果放一起，梨和梨放一堆。他不会胡乱放，他有分类。所以显示信息也应该是这样，CPU的信息放在一起，内存的信息放在一起，Job（作业）的信息放在一起。这叫显示信息归类的合理性。6.2.2.4 滚动条

小白 如何检查滚动条控件呢？

大鸟 当数据比较多的情况下，就会出现滚动条来控制显示。滚动条控件的测试，要注意以下几点。（1）滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如在Word中浏览100页文档，浏览到50页时，滚动条位置应处于中间的位置。（2）拖动滚动条，检查屏幕刷新情况，并查看是否有乱码。（3）单击滚动条，检查是否工作。（4）用滚轮控制滚动条，检查是否工作。（5）单击/常按滚动条的上下按钮，应该可以正常工作。（6）避免使用水平滚动条，因为它会使项目阅读起来比较困难。解决的办法有：尽量使用垂直滚动条、加宽窗口、减小文本的宽度，或者使文本自动换行等。当然，如果确实需要，也可以使用水平滚动条。（7）在字段间的Tab顺序应该是水平移动的。在一些案例中，Tab的顺序可以被设置为垂直移动。6.2.2.5 陈旧数据的及时更新

小白 陈旧数据的及时更新主要检查哪些内容？

大鸟 比如年份变化了，今年是2014年而不是2013年了，但是软件版权日期的数据源还显示2013年。再比如说，某些电话、邮箱发生了变化。QA要注意某些数据的变化，避免DEV一股脑儿地拷贝原来数据的情况。6.2.2.6 分类排序

小白 分类排序是指什么？

大鸟 用过淘宝之类的吧，你想买个商品，比如说买个LV包，一下子搜到很多，你想要按照价钱、产地、口碑、信誉进行一下排序。像这种排序一般有个默认值，有的从高到低，有的从低到高，具体要看需求。此外还要注意一点，如果是英文，那么是否要忽略大小写呢？6.2.2.7 避免遮蔽

小白 避免遮蔽是指什么？

大鸟 在显示多个数据的情况下，要避免自己的数据被别的东西挡住从而显示不全的情况发生。

6.2.3 删除数据

小白 删除数据主要检查哪些内容？

大鸟 主要包括如下几个方面。（1）删除合法数据。（2）不允许删除的数据。（3）删除不存在的数据。（4）删除数据的衍生影响。6.2.3.1 删除合法数据

小白 删除合法数据是怎样的情况呢？

大鸟 删除的合理操作应该验证以下三种情况。（1）删除一条数据记录。（2）删除多条数据记录。（3）删除全部数据记录。

检查点是：（1）数据删了之后，可能就恢复不了了。所以删除时，要让用户认识到删除严重性，并予以确认。（2）删除后，在数据库中是否也删除了。（3）删除后查询数据，数据库应该查不到。（4）删除后，是否可以添加同样的数据记录。（5）删除成功后要有提示信息。6.2.3.2 不允许删除的数据

小白 不允许删除数据的操作应该是怎样的情况？

大鸟 比如说，有些节点正在使用，所以不允许删除。或者有些是默认设计不允许删除的，如管理节点。在这种情况下，要么删除时报错，要么使删除按钮变灰不让用户操作。

小白 有一种情况，就是要删除多个数据，但其中有的允许删除，有的不允许删除。那么在这种情况下，删除按钮是该变灰还是不变灰呢？

大鸟 不变灰，而是提示用户某些数据可以删除，某些不能删除；接着，让用户确认；如果用户确认了，则删除可以删除掉的，不能删除的则保留。6.2.3.3 删除不存在的数据

小白 删除不存在的数据是怎样的情况呢？既然不存在，我咋删除呢？

大鸟 是有这样的情况，比如同时打开两个Web窗口，某些数据在窗口1已经删除掉了，但是在窗口2还有显示，在这种情况下，再删一次，看看会有什么样的情况发生，看看是否有合理的错误提示。6.2.3.4 删除数据的衍生影响

小白 删除数据的衍生影响是指什么呢？

大鸟 测试删除数据的时候，不是删除一个数据那么简单。数据与数据之间有其特定的关联性。从数据层方面来说，查看在明细文件（子表）内是否有相关的细项记录，如果有则不允许删除父表的记录。

小白 对，正所谓“皮之不存，毛将焉附”。

大鸟 是的，还有就是逻辑层方面的问题。即便是在数据库层面都是各自独立的数据表，但是如果彼此之间存在逻辑依赖，那么还是要考虑是否删除相关的数据或者删除后的影响。案例 作者曾经做过一个节点管理软件的测试，其中有些节点是有标签的，比如说节点Compute001标签名为Dell1950，Compute002标签名为ETT3650，这些是硬件标签。如果你在标签管理中，把Dell1950这个标签给删除了，那么节点上所对应的标签名是否也要删除呢？这个就涉及到实现的问题。从逻辑上来说它们是有关系的。此外，还有组合标签的情况。比如说一个标签是“Dell1950 And Windows 2013”，如果删除了标签Dell1950，那么组合标签“Dell1950 And Windows 2013”是否也要删除呢？

6.2.4 查询数据

小白 查询数据主要测什么，怎么测？

大鸟 查询数据的用户场景是这样的：有个查询条件，然后有个查询关键字，点击查询按钮，得到查询结果。6.2.4.1 查询条件输入

小白 查询条件输入是指什么？

大鸟 查询按条件来看，包括两种情况：单条查询、组合查询。单条查询是指仅一条查询语句，返回一个查询结果集；组合查询是指多条查询语句，返回一个查询结果集。

查询条件输入有哪些检查点呢？

检查点有如下几条：（1）查询条件输入方式和需求描述不一致，比如，需求为下拉列表，程序为文本框。（2）对于组合查询，要保证逻辑的正确。输入多个搜索条件，可以同时添加合理和不合理的条件，查看系统是否正确。比如说这种情况就是错误的：查找CPU Usage＞20％而且CPU Usage＜10％的情况。对于逻辑错误的提示要清晰合理。（3）开始时间和结束时间：选择起始时间后，联动显示出结束时间选择，选择结束时间小于起始时间的日期。（4）对于开始时间和结束时间，如果用户不选，则要给一个合理的默认开始时间和结束时间。比如结束时间默认为当前时间，起始时间默认为当前时间前两小时。6.2.4.2 查询关键字

小白 查询关键字是输入值吧。

大鸟 是啊，因为关键字的值是你自己输入，所以对输入框的限定要进行测试。另外，对于特殊字符、带空格字段、超长字符、数字型边界、数字的约束等情况都要考虑，读者可以参照“添加数据”一节，这里不再赘述。6.2.4.3 模糊查询与精确查询

小白 精确查询和模糊查询有什么区别？

大鸟 精确查询就是直接查。例如：

这么查就是查出字段名必须等于“长虹”的字段。那么长虹空调、长虹电视就查不出来。

模糊查询就是换成like：

这么查就是查出字段名中带有“长虹”的字段，%表示任意长度的字符串。那么长虹电视、长虹空调、美丽的长虹都可以查出来。

小白 默认的应该是精确查询还是模糊查询呢？

大鸟 默认的一般都是模糊查询，除非用户指定为精确查询。6.2.4.4 查询结果

小白 查询结果有哪些检查点？

大鸟 有如下几方面：（1）通过查询功能查询到的数据记录个数，要与通过数据库查询的数据记录个数相符。有可能存在不符合的情况：有些记录丢失，有些多出来了。比如说我用长虹电视作为关键字（模糊查询），如果查出长虹空调、长虹洗衣机，那显然就多了。如果“长虹电视机顶盒”没查出来，显然这就是少了。（2）如果根据查询条件确实查不到任何数据，应该给出清晰合理的结果。不能让用户费解。（3）如果用户选择默认条件查询，应该可以查询出全部的数据记录。（4）如果用户选择全空条件查询，应该可以查询出全部的数据记录。

6.2.5 修改数据

小白 修改数据主要检查哪些方面呢？

大鸟 修改数据主要检查如下几个方面：修改合理数据，不能修改/锁的情况，修改多个数据，以及修改后的衍生影响。6.2.5.1 修改合理数据

小白 修改合理数据是指什么？

大鸟 对于修改数据，这里要注意如下几个检查点：（1）点击“修改”按钮，程序跳转到修改页面，验证信息内容和修改时的输入一致。（2）修改后查找数据库，里面有新保存的数据；同时，老数据查不到。（3）通过查询页面，也可以查询到修改的数据；同时，老数据查不到。（4）修改成功后，程序提示保存成功。

对于把数据修改为特殊字符、带空格字段、超长字符、数字型边界、数字约束等情况，读者可以参照“添加数据”一节，这里不再赘述。6.2.5.2 不能修改的情况

小白 不能修改是怎样的情况呢？

大鸟 不能修改是指某些数据正在被使用，因此不能修改。这里面应该有一个锁机制，数据库就是通过锁机制来解决并发问题的。

小白 如何解决这种并发机制呢？

为了确保并发用户在存取同一数据库对象时的正确性（即无丢失修改、可重复读、不读“脏”数据），数据库中引入了锁机制。基本的锁类型有两种：排他锁（Exclusive lock，记为X锁）和共享锁（Share lock，记为S锁）。排他锁与共享锁排他锁：若事务T对数据D加X锁，则其他任何事务都不能再对D加任何类型的锁，直至T释放D上的X锁；一般要求在修改数据前要向该数据加排他锁，所以排他锁又称为写锁。共享锁：若事务T对数据D加S锁，则其他事务只能对D加S锁，而不能加X锁，直至T释放D上的S锁；一般要求在读取数据前要向该数据加共享锁，所以共享锁又称为读锁。在执行select语句的时候需要给操作对象（表或者一些记录）加上共享锁，但加锁之前需要检查是否有排他锁，如果没有，则可以加共享锁（一个对象上可以加n个共享锁），否则不行。共享锁通常在执行完select语句之后被释放，当然也有可能是在事务结束（包括正常结束和异常结束）的时候被释放，主要取决于数据库所设置的事务隔离级别。执行insert、update、delete语句的时候需要给操作的对象加排他锁（笔者感觉在执行insert的时候应该是在表级加排他锁），在加排他锁之前必须确认该对象上没有其他任何锁，一旦加上排他锁之后，就不能再给这个对象加其他任何锁。排他锁的释放通常是在事务结束的时候［当然也有例外，就是在数据库事务隔离级别被设置成Read Uncommitted（读未提交数据）的时候，这种情况下排他锁会在执行完更新操作之后就释放，而不是在事务结束的时候］。数据库是支持在一个事务中进行自动锁升级的，例如，在某个事务中先执行select语句，后执行update语句，这两条语句操作了同一个对象，并且假定共享锁是在事务结束的时候被释放的。如果数据库不支持自动锁升级，那么当update语句请求排他锁的时候将不能成功。因为之前select语句的共享锁没有被释放，那么事务就进入了无限等待，即死锁。有了自动锁升级，在执行update语句的时候就可以将之前加的共享锁升级为排他锁，但有个前提，就是这个共享锁必须是本事务自己加的，而且在操作对象上没有在加其他任何锁，否则共享锁是不能被升级为排他锁的，必须等待其他锁的释放。还有一种叫更新锁。因为通常在执行更新操作的时候要先查询，也就是我们通常会在update语句和delete语句中加where子句。那么，有的数据库系统可能会在执行查询的时候先给操作对象加共享锁，然后在更新的时候加排他锁，但这么做会有问题，也就是如果两个事务同时要更新一个对象，都先给这个对象加了共享锁，当要更新的时候，都请求升级锁，但由于这个对象上存在对方事务加的共享锁，所以无法升级。这样两个事务就在等待对方释放共享锁，进入死锁状态。更新锁就是为了解决这个问题，即在执行查询操作的时候加的不是共享锁而是更新锁（一个对象上只能有一个更新锁和n个共享锁），当要更新的时候，再将更新锁升级为排他锁，升级前提是这个对象上只有本事务加的更新锁，没有其他任何锁了。

大鸟 如果QA进行测试的话，要怎么进行呢？

小白 首先要和DEV沟通，看看相关的锁机制是否建立好了。然后要按照上面的分类，构造测试环境。看看相关的锁机制是否工作。6.2.5.3 修改多个数据

小白 修改多个数据是指什么？

大鸟 一般情况下不太可能修改多个数据。当然不排除有种情况，要看需求。比如说用户是给多个数据加标签，加前缀后缀的情况。检查时要保证所有数据都被修改，而不只是第一个/某几个数据被修改。6.2.5.4 修改后的衍生影响

小白 修改后的衍生影响是指什么呢？

大鸟 牵一发而动全身啊，修改这种动作呢，不光对自己进行了改变，可能还对相关数据都进行了改变。

小白 套用黄健翔的话说“他不是一个人在战斗，他不是一个人”。

大鸟 对，所以修改有个边界界定的问题，包括以下两种情况：（1）仅改自己，与别的数据无关的，不要改别的东西；如果自己的数据改后添加了，不影响以前的数据。（2）改自己且与别的数据相关的数据，要把别的数据也改掉。

所以不要做少了也不要做多了。案例1 笔者曾经做过一个节点管理软件的测试：节点管理有一个模板，这个模板下有10个节点。当笔者修改这个模板下的某个脚本时，比如脚本改为“在根目录下建一个test目录”。这个改动实际上是要求对模板下所有节点都要建一个test目录，所以修改后应该提示用户要对节点进行同步操作。案例2 情况如上。笔者还是修改了这个模板，现在的情况是笔者仅仅对管理模板的描述信息做了修改。这个修改不会对它下属的节点造成任何影响，但事实上软件还是提示用户要进行同步，显然这是一个Bug，它做了一些不该做的事情。

6.2.6 激活/冻结

小白 什么叫冻结啊？我记得郭德纲有一句话形容一个大侠：他的剑是冷的，他的刀是冷的，他的心是冷的，他的血也是冷的……这孙子冻上了，哈哈！

大鸟 嗯，有点儿意思。其实冻结的意思在软件中也差不多哦，我们在冻结一个特性、功能或数据后，也要检查相关的功能（删除、修改、拷贝等等）是否也被冻结了。保证该冻上的要被冻上，不该冻上的别被冻上。此外还要检查如下几点：（1）冻结后不允许用户再使用的，要把它变灰。（2）冻结成功后，要有合理的提示信息。（3）能否同时冻结多个。（4）重复冻结的情况。（5）冻结已经被删除数据的情况。（6）冻结的时候，要不要一些描述冻结的理由。

当然具体的行为，还是要看用户需求。

小白 明白了，那么激活呢？

大鸟 所谓激活数据就正好相反，即解冻或者是发布。读者可以参照冻结的检测点加以验证。

6.2.7 导入/导出数据

小白 导入/导出数据的检查点是什么？

大鸟 检查点包括如下几点。（1）导入合理数据。（2）导入数据中存在不合理数据。（3）导出数据。6.2.7.1 导入合理数据

小白 导入合理数据是指什么？

大鸟 导入数据也是一种添加数据，请参考“添加数据”一节。此外你还要考虑，导入的格式是否合理，如果不合适是否有提示等情况。6.2.7.2 导入数据中存在不合理数据

小白 导入数据中存在不合理数据是指什么？

大鸟 这里存在如下几种情况。（1）有的数据是存在的但不合理（格式、数值边界等不合理）。（2）有些数据是合理的但不存在数据（空的路径、不存在的文件夹等）。（3）数据内容不合理，如错误的网卡地址等等。（4）导入的若干条正确记录中混有一条错误记录。（5）对于不合理数据要及时给出提示。6.2.7.3 导出数据

小白 导出数据是指什么？

大鸟 导出数据主要检查如下几点：（1）导出的格式（如xml，doc，pdf）是否满足需求。（2）能否被打开且不出现乱码；数字格式精度是否满足需求。笔者就遇见过这样的情况，在Web报表上展示的是小数点后三位，结果导出xls后就变成小数点后两位了。（3）如果是大规模的导入导出，可能还要测试性能。不过这不属于功能测试，这里就不多说了。

6.2.8 实例化

小白 实例化是指什么？

大鸟 在面向对象的编程中，通常把用类创建对象的过程称为实例化。软件测试中我们通常把根据模板创建出对象的过程叫实例化。这里主要检查创建出来的对象是否能显示正常，实例化过程中是否可定制化，能否实例化多个对象等测试。

6.2.9 拷贝

小白 拷贝和添加数据比较像吧。应该都属于一种添加。

大鸟 对，本质上来说都是添加。下面我们说说区别，区别有以下两条：（1）拷贝数据信息检查。（2）默认拷贝数据名。6.2.9.1 拷贝数据信息检查

小白 什么叫拷贝数据信息检查啊？

大鸟 拷贝数据之后，要进行信息检查。对于拷贝数据和被拷贝数据来说，某些信息是一致的，某些信息是不一致的。一致的比较好理解，下面说一下不一致的地方。举例来说，因为所有拷贝的数据都是用户自定义的，所以如果有Build-in（内嵌）属性，那么对于拷贝数据的话，它一定是“否”。

所以做测试的时候，要把那些不一致的地方搞清楚，别把那些本来应该不一致的地方，最后也变成一致的了。6.2.9.2 默认拷贝数据名

小白 拷贝数据，还要给个默认的名字吗？

大鸟 对于拷贝数据名，默认要给一个合理值。比如rhel6.4这个名字，可以给rhel6.4_copy1这个名字。如果再对rhel6.4拷贝的话，可以累加，比如得到rhel6.4_copy2。像这样的设计才是合理的。

小白 如果我已经有rhel6.4_copy1，rhel6.4_copy3，rhel6.4_copy4了，那我再拷贝一个，默认名字应该是rhel6.4_copy2了吧。

大鸟 是的。

小白 如果拷贝rhel6.4_copy1呢？

大鸟 拷贝出来的名字应该是rhel6.4_copy1_copy1。至于重复添加，拷贝不存在的数据情况，请读者参考“添加数据”一节进行分析。此外，对于拷贝出来的数据，加个时间戳也是合理的。

6.2.10 检查日志

小白 大鸟，我发现表中有一个检查点是检查日志，这是指什么呢？

大鸟 当程序出现错误的时候能准确地定位问题成了保证软件质量的关键，而如何才能准确定位问题呢？这就需要程序出错时尽可能地吐出更多的消息，最好的情况就是把问题定位到具体的文件和语句以及当时的堆栈信息，这样就可以帮助程序员快速地定位问题，这便是软件可测试性的最终目的。

我们平时会使用到一些测试手段，如在代码中使用ASSERT，在屏幕或者控件里打印一些程序的执行过程，还有就是利用Debug去直接跟踪程序的语句等，但是以上这些简单的测试手段对于那些程序中隐藏比较深的Bug就显得有点束手无策了，特别是对一些服务器一级的程序，它们都需要长时间的运行，有时候出了错误并允许马上停下来，这就需要程序必须把错误信息保存下来待以后再去分析它。Windows系统内部就有很多的日志，这些日志不仅可以供开发人员定位问题，也可以帮助用户更好地使用系统。其实所有的程序对可测试性都有着一些相同的要求，于是我们可以把这些需求提取出来抽象成一个单独的系统（类），这样就可以为所有的程序都提供统一的测试接口了。

日志可以提供一种跟踪机制，这种机制提供的信息有：组件正在做什么，包括它们正在操作的数据，应用程序的状态或者应用程序遇到的错误。在执行测试过程期间，测试工程师可以利用这些信息来跟踪处理流程，以及利用这些信息来对系统发生的错误进行定位。

小白 怎么定义一个好的日志呢？

大鸟 比较好的日志一般满足如下条件：（1）能保存成独立的文件，一些程序要执行很久，必须要把程序执行的信息保存下来，同时程序关闭后测试的信息不能随着程序一起消失掉，所以没有比把这些信息保存在磁盘更好的方法了。（2）打印日志的方法必须是可重入的（若一个程序或子程序可以“安全地被并行执行”，则称其为可重入），现在很多软件是多线程的，为了让线程之间打印的信息不互相干扰，我们的打印方法必须支持多线程。（3）对打印要求设定级别，级别的粒度因需要而定，一般都要包括错误信息、报警信息和一般信息三类，这样用户就可以根据需要，通过日志的配置文件来选择需要打印的信息，而不是一股脑地把所有的信息都打印出来，重点不突出反而不利于问题的定位。（4）打印接口要设计得灵活，可以让用户自由地去打印任何信息。有些情况下，打印的同时也要把当时的堆栈信息打印出来，这些信息可能是字符串、整形或浮点型等。（5）打印的内容要采用统一的格式，一个合理的日志条目应该包含如下信息：［时间戳］［等级］［文件/函数/进程ID/主机名］［信息内容］

第7章 软件互操作性测试

7.1 互操作性测试定义

小白 什么是互操作性呢？

大鸟 互操作性（Interoperability）的本质就是关系论。

小白 关系论？这是什么东西啊？

大鸟 你来到这个世界上，就要跟这个你生存的环境，存在天造地化的关系。然后你和别人在社会交往的过程中也要存在关系。 中文里“关系”是一个名词， 前面通常要加上这样的动词：拉、搞、走、跑、套等等。关系是要拉要套的，所以关系是一个动态过程，而不是静态的状态。关系可以这么理解：是一种物质、能量和信息的交换。如果没有这个交换，关系不成立。比如，咱们说拉关系，得拎1条烟、2瓶酒，这叫什么，物质交换；我穷，我没有烟、没有酒，但是我还想拉点关系，怎么办，我上你们家，给你们家扫扫地，换煤气罐，这是奉献我的力气，是能量交换；你看见某个美女，你想获得她的青睐，你对她说：你怎么长这么靓呀，你衣服好合体啊，在哪买的啊？这是信息交换。人和人想发生关系，离开这三个就不成立。

小白 那么软件的互操作性是指什么？

大鸟 所谓互操作性是指一个软件系统与另一个软件系统互相间具有接收、处理并共享所发送信息的能力。当两个产品相互合作、协同地为各自所面向的用户提供某个指定的服务时，所表现出的能力称为互操作性。举例来说：一台UNIX工作站能用TCP/IP通信协议与一台Windows服务器互联并且顺利交换数据。

小白 这是彼此交换信息/数据的能力。那么互操作性测试的标准是什么呢？

大鸟 一致性测试（也称一致性评估）是测试一个实现是否符合一个标准或规范的需求。

确定一个产品是否与标准或规范相一致，这对创建一个健壮的、可互操作的解决方案是必要的。一致性测试为软件开发者和用户提供了一些保证，即保证合格产品按照预期的情况运行，保证合格产品以一种已知的方式执行功能或拥有一个开放的接口或格式。一致性测试并不是互操作性的保证，但是它是获得互操作性的一个必要步骤。

小白 彼此遵循一个统一的开放标准，然后彼此之间可以顺利交换数据。

大鸟 世界经济进入全球一体化和快速增长期，需要有一种具有可操作性的途径来实现计算资源的整合和信息共享，为此呼唤实施开放标准。

而开放标准指的是通过应用编程接口、通信协议以及数据和文件格式，使用公开发布并为公众认可的技术规范来实现异构系统之间的互操作性。开放标准的全部价值在于它对异构系统灵活性的支持，只有采用开放标准才能建立支持异构系统互联互通、互操作、信息共享、资源整合的统一平台。所以，解决软件的互操作性，包括解决开源软件之间、私有商业软件之间以及开源软件与私有商业软件之间的互操作性问题。

7.2 兼容性和互操作性的区别

小白 在读到一些技术文章时，经常发现兼容性和互操作性并列提起，曾看到这样一句话“互操作性测试的主要目标是发现兼容性问题”，很明显在这句话中可以看出兼容性与互操作性在概念上有交叉现象，那么两者究竟是否同属一个概念还是有所区别？

大鸟 所谓兼容性（Compatibility），是指某个系统上运行的应用程序符合另一个系统的接口要求，从而使该应用程序也可在另一个系统上运行，这时对该应用程序符合某个接口的能力称为兼容性。从上面对互操作性和兼容性概念的表述来看，它们间有共性，也有区别。一般来说，互操作性涉及到接口、协议、格式的公开性和一致性，内涵更丰富，具有公平性、主动性、战略性的特点；而兼容性则具有依附性、被动性、短期性的特点，并可能要承担“反兼容”的风险。

小白 虚拟机共存算不算互操作性？

大鸟 在虚拟化技术环境中，通常指物理服务器可虚拟成多个虚拟机的应用，操作系统是在虚拟的硬件上运行（不是在真实的硬件上运行）的，所以在虚拟的环境中可能同时存在几种不同的操作系统，有人也把“共存”理解为“互操作性”，这是扩大互操作性概念的一种看法。服务器虚拟化只是起点，公用计算才是其目的。

小白 两者在测试中有什么区别呢？

大鸟 互操作性与兼容性的共同点在于，两者都包括这样一层内容：即都涉及到验证两个相关产品之间相互操作的测试。如果仅仅考虑这一点，兼容性测试与互操作性测试在测试内容、技术和方法上应该没有太大的区别。

如果从两者的区别上来看，兼容性除了要考虑被测软件与其他软件和硬件相互配合的程度外，还要考虑软件自身不同版本之间的适应性。另外两者的区别还在于对于它们进行测试所考虑的重点不同，兼容性测试关注的重点只有一个，即被测软件，其他的软件或硬件只是为了验证这个软件的兼容性而设置，它们在测试过程中只是起到“配角”的作用，但在互操作性测试中不同，互相操作的两个软件或系统都是“主角”，都属于被测对象。

7.3 不可互操作的原因

小白 我们要测试软件之间的互操作性，是因为有不可互操作性的情况出现。我想问问，不可互操作的原因有哪些呢？

大鸟 对不可互操作的原因进行分析可进一步加深对互操作性的理解，对提高互操作性的可能性也有重大帮助。不可互操作的原因主要如下。（1）服务问题。由于另一个软件/服务的不可用而造成互操作发生问题。（2）协议问题。两个不同系统的协议实现中的选项和参数如果不兼容，则会导致互操作性问题。比如所有的通信都需要确定时间参数，时间问题可分成最大时间、最小时间以及持续时间的不能匹配问题。时间参数不兼容，就会出现互操作问题。特别是像现场总线（指工厂内以测量和控制机器间的数字通信为主的网络）这种对实时性要求比较高的系统，在这方面出现问题的可能性也较大。（3）资源问题。系统之间的互操作都需要资源，但资源是有限的，如果在某些情况下，出现资源不够就可能会导致互操作性问题。这种资源可以是硬件资源，如物理内存、物理缓存、CPU时间等，也可以是软件资源， 如一些应用对象等。（4）应用程序问题或用户配置问题。这实际上并非是互操作范围内的直接问题，但却最终让用户感觉是出现了互操作性问题。因为应用程序没有给用户提供一个统一一致的接口，用户不得不需要额外的精力去面对不同平台的操作步骤。（5）接口问题。根据OSI的基本参考模型和分层原则，对于N层实体来说，它为上层实体提供服务及其接口，同样通过下层实体的接口来使用该层服务。如N层通信对等实体之间出现互操作问题，则可能出现问题的地方有：N层实体本身对N层协议的实现错误；N层实体使用下层实体的接口不当；下层实体的实现正确但提供的接口错误；下层通信对等实体存在互操作问题。（6）协议自身实现问题。这也是最主要的问题，它是由于实现者协议不通用的错误实现而造成的。根据以往的经验，系统出现的互操作性问题在各层上出现的概率有所不同。一般说来，在上几层（包括应用层、会话层等）出现的概率较大，而在下几层（如物理层、数据链路层等）出现的概率要小。因此，为提高系统的互操作性，需要加强对上层协议，特别是应用层协议中有关提高互操作性方面的设计和测试。

7.4 互操作性测试分类

小白 感觉互操作性的概念非常大，有硬件方面的，也有软件方面的。

大鸟 对，互操作性的概念比较广泛，为了达到软件的互操作，需要包括硬件、网络、操作系统、数据库系统、应用软件、数据格式、数据语义等不同层次的互操作，问题涉及运行环境、体系结构、应用流程、安全管理、操作控制、实现技术、语言、数据模型等。所以我们要对这个做一个分类。

小白 具体怎么分呢？

大鸟 可分为如下几类。（1）软件与硬件平台及外设的互操作性，（2）文件系统互操作性。（3）软件互操作性。（4）网络互操作性。（5）操作系统间互操作性。（6）操作系统与数据库之间的互操作性。

7.4.1 软件与硬件平台及外设的互操作性

小白 软件与硬件平台及外设的互操作性主要指什么呢？

大鸟 软件系统与硬件平台及外设的互操作性主要是考虑软件系统在这些硬件平台上是否能够稳定运行，是否能够读写外设及管理外设的运行状况。有一次测试我们Team遇到过这样的事：某一个要测试的系统软件在某个虚拟机或者某一类硬件平台（如Dell R510）上顺利测试过了，好，现在来了新的需求，要支持ETT 3650机器。现在该怎么测？

小白 那就把所有的重新测一遍？

大鸟 不对，既然关注重点是软件系统与硬件平台及外设的互操作性，那就应该集中在硬件相关性（Hardware-depend）上。否则的话，虽然你做了一些测试（比如某些纯软件测试，包括GUI上面的一些测试、软件的Alert/Report、某些Job测试等），但如果是和硬件平台无关的，那相当于你做了无用功。

小白 那什么样的测试才是真正反映在硬件相关性上的测试呢？

大鸟 包括如下几种。（1）安装测试。（2）部署测试。（3）硬件监控。（4）硬件管理。7.4.1.1 安装测试

小白 一个一个说，安装测试主要测什么硬件相关性呢？

大鸟 安装测试是测软件在硬件上的安装，主要测试如下内容。（1）用什么媒介（CD-ROM、U盘或移动硬盘）来安装软件。（2）软件装在哪类硬盘（IDE、SCSI或SATA）上。（3）软件装在哪个盘（Windows系统的C盘、D盘……Linux系统的had、hdb……）上。（4）安装软件时所对应的硬件驱动（主板、CPU、显卡、声卡、光驱、CRT显示器、LCD显示器、有线网卡、无线网卡、无线上网卡、Modem、蓝牙适配器、红外适配器、打印机、扫描仪、数码相机、数码摄像机、手机、U盘、移动硬盘、鼠标、键盘、音箱、耳机、摄像头、投影仪、磁盘阵列、SAN网络、FC交换机、电子书、手持电视、GPS设备等）是否能够正确安装。7.4.1.2 部署测试

小白 明白了，那部署测试主要测什么呢？

大鸟 部署的意思就是网络安装某个机器以及相关的驱动、软件包，并执行一些脚本等等。部署测试主要测试如下内容。（1）部署测试因为主要是通过网络进行的，所以网卡（有线网卡、无线网卡、无线上网卡、Modem、蓝牙适配器、红外适配器）是测试重点。案例 以前笔者曾经遇见一个部署机器的问题：用户尝试用万兆网卡来部署机器，但我们系统软件库里面没有相应的驱动，所以部署就失败了。这是因为在测试的时候，没有相关的硬件来部署，属于硬件测试的盲点。（2）部署机器可以包括两部分：Diskful（有盘工作站）和Diskless（无盘工作站），这些都和机器硬件相关。（3）软件所对应的硬件驱动（网卡、显卡驱动等）、模块有没有安装上。7.4.1.3 硬件监控

小白 懂了，那硬件监控测什么呢？

大鸟 通常硬件包含一些具体的属性、参数和值，由于具体硬件本身不同，里面的内容和值各不相同。

小白 不是都是取值吗？怎么会取不到？

有可能同一套软件系统在某台机器上可以取到相应的值，换到另一台机器上就取不到值。原因是有可能这台机器没有在硬件监控列表里面。

这些值包括CPU、内存、总线、BIOS、端口，以及其他的性能值。7.4.1.4 硬件管理

小白 硬件管理是指什么呢？

大鸟 现在好多高级一点儿的机器都支持BMC（BaseBoard Management Controller，基板管理控制器）管理。BMC是什么东西呢？它是一个远程管理卡，是IPMI（Intelligent Platform Management Interface，智能平台管理接口）的核心控制器，系统管理软件对各个被管理器件的管理都是通过与BMC通信实现的，比如说用户想要实现：机器亮灯、闪烁；远程开机、关机、重启；升级机器微码；远程访问IMM网页；硬件状态的管理等等。但是不同的机器BMC都各不相同，所以要实现通过系统软件进行硬件管理时，这些都是互操作性的测试点。

此外，硬件（网卡、硬盘）或者机器的更换等，也是测试点之一。

7.4.2 操作系统/文件系统的互操作性

小白 操作系统/文件系统的互操作性是指什么？

大鸟 文件系统的互操作性主要从文件系统的格式来考虑，测试软件是否能够读写各种类型的文件系统中的文件。文件系统类型包括：FAT16、FAT32、VFAT、Ext2、Ext3、Ext4、NTFS、Reiserfs、gfs2、ocfs2、isofs、XFS、JFS。

操作系统的“互操作性”，指一个软件在某个系统（如Linux系统）与另一个软件在另一个操作系统（如Windows系统或者苹果操作系统）互相间具有的接收、处理并共享所发送信息的能力。

小白 像Linux版QQ和Windows版的QQ通信算吗？

大鸟 算。Linux是一种开放源代码操作系统，Windows是一种属于私权的商业性操作系统（自然是不开放源代码的），从本质上说，两者是异构的信息系统或环境。

在两个（或多个）异构信息系统的环境中生成的文档、数据，可置于对方环境中被读、写，从而实现两个（或多个）文档系统层次上的互操作性。比如一个软件能在Windows环境中读、写、监控和管理Linux Ext2或Ext3文档系统的软件模块（工具）。

对于实现互操作性来说，还要讲究读、写的速率，以及在测试中文档是否丢失或丢失的数量。一个成熟的“互操作”与大量成功的测试数据有关。彼此间不但能读能写，而且保持在一定效率下的能读能写。所以，构造测试用例的时候还要构造一定的压力测试。

此外，操作系统的互操作性还要注意升级的测试：即系统升级/打补丁后软件操作的功能不受影响（升级前升级后要一个样）。

7.4.3 软件间的互操作性

小白 那什么是软件的互操作性？

大鸟 我给你举个例子：我们都见过某些开源办公套件或某些办公套件（WPS）能与微软.doc格式的文档实现内容兼容、格式兼容和版面兼容。

除此之外，图形图像处理软件、文件管理工具、压缩工具、网络工具（SAMBA、PING、浏览器、即时通信、邮件客户端、下载工具）、多媒体工具（音频播放器、视频播放器）、编辑软件、集成开发环境、文档查看工具、游戏、虚拟化软件、集群配置软件、集群管理软件、负载均衡软件、数据库备份软件等等，相互之间都实现了兼容。

软件间的互操作性还包括：不同版本软件安装在一台电脑上是否能够支持，是否能够稳定运行；多用户同时访问软件时的互操作性；同一个服务器上采用虚拟化技术使多个操作系统同时运行；不同版本软件系统间应用程序和数据文件的移植能力。

7.4.4 网络/数据库的互操作性

小白 什么是网络的互操作性？

大鸟 近年来，通过“Web服务”（Web Service）由低层次到高层次的各项“通信协议”，逐年获得W3C、OASIS等国际标准组织批准，成为公用标准，使得异构应用系统通过这些网络的“通信协议”实现互操作。

历年来逐年获得批准的“Web服务”的公用标准有：● 传输（Transport）标准

如TCP/IP、HTTP、SMTP等。● 语言格式（Format）标准

如XML。● 消息（Message）标准

如SOAP。● 描述（Description）标准

如WSDL、UDDI。● 协同工作（Coordination）标准

如WS-Coordination。● 交易（Transaction）标准

如WS-Transaction。● 安全（Security）标准

如WS-Security。● 服务语言（Service Composition）标准

如BPML、BPEL、BPEL4WS等。

有些高层次标准尚在审议中。

小白 QA测试要注意什么？

大鸟 QA要做一些调查，并检查DEV公用标准的开发，检查公用标准是否来自于网络完整的标准体系，並进行全面贯彻。同时，要研究相应的公用及专用标准，比如SAMBA软件能够让 UNIX与DOS互相分享数据。网络的互操作性主要测试使用不同的网络配置SMB或nfs来访问文件，使用Telnet、FTP、HTTP、HTTPS、SSH互相访问系统，安装和配置远程的LPD队列、SMB共享、网络、远程CUPS服务器、IPP网络、串行传真/调制解调器打印机等。

小白 什么是数据库的互操作性？

大鸟 某个软件在某个操作系统里配置上不同的数据库（Oracle、DB2、MySQL、SQL Server……），那不同数据库之间的数据交换能力、数据库迁移能力，软件同时安装多个数据库是否稳定运行，操作系统中对数据库连接接口的支持能力，软件能否提供与异构数据源相互转换的功能等等，这些都是数据库互操作性测试的范围。

7.4.5 驱动程序的互操作性

小白 驱动程序的互操作性是指什么？

大鸟 驱动程序是涉及U盘、显示器（卡）、硬盘、数字相机、打印机等外部驱动设备的程序软件，操作系统与它们之间存在着互操作性或兼容性的问题。

开源软件作为崛起不久的新的软件体系，在这方面存在更多有待于解决的互操作性或兼容性问题。微软在推出Windows Vista后，也屡屡在“兼容”的门槛上绊跤，例如对诸如尼康、佳能等数款数码相机，就无法在Vista平台上编辑、浏览、处理影像等，甚至可能导致影像的消失、无法恢复。

小白 测试的时候要注意什么呢？

大鸟 QA首先要对外部驱动设备厂商非常了解，最好能懂得一些驱动架构方面的知识。如果能有一个驱动的列表当然更好。给我们所要支持的驱动设备做个分类，然后每类抽出一些主要的品种做测试。

7.4.6 文档的互操作性

小白 文档的互操作性是指什么？

大鸟 文档的互操作性是指不同软件之间彼此阅读对方文档的能力。这里尤其要注意，有一些OEM厂商是否有特殊的需求改变。比如说HPC软件产品，原来的文档是Word文档，这是因为原来的项目用户主要是Windows用户，后来由于需求改变，很多用户被切换成Linux用户，于是Word文档就不那么适用，甚至阅读时出现了很多格式显示的问题。

第8章 安全性测试

8.1 软件安全性测试概念

小白 什么是软件安全？安全测试的目的是什么？

大鸟 软件安全就是软件在受到恶意攻击的情况下依然能够正确运行的工程化软件思想。

安全测试的目的是减少安全漏洞，抵御恶意的黑客和非法用户的攻击，满足用户对软件安全的需求。

一般来说，系统安全指标不同，测试策略也不同。对安全性要求不高的软件，其安全性测试可以混在单元测试、集成测试、系统测试里一起做。但对安全性有较高需求的软件，则必须做专门的安全性测试，以便在破坏之前预防并识别软件的安全问题。

小白 这是一种思想？

大鸟 是的，在做测试过程中，我们的软件产品在安全性方面考虑了多少？应该如何测评一个软件到底有多安全？这里很难得到一个非此及彼的答案。因为安全性从来就不是一个保证。测试人员需要某些停止点，即测试到哪个程度即可。也就是说，当全部组件都似乎在可接受的风险阈值以内时，我们的测试应该停下来。

小白 风险阈值以内？还是不太懂你说的是什么意思？

大鸟 简而言之，还是要看需求。咱们拿一个银行和一家普通的便利店做例子。你觉得哪一个更易遭到抢劫？

小白 当然是便利店。

大鸟 为什么？

小白 因为银行往往有更强大的安全性防范措施；一般来说，银行可能已经将出纳员置于防弹玻璃之后，并安装了摄像机、配备了安全保卫、装备了上锁的保险库以及具有电子密码的门。相比之下，便利店可能只装备了没那么复杂的摄像系统以及很少的其他设备。所以对抢劫犯来说，便利店则是一个容易得多的目标。

大鸟 可是为什么便利店保卫工作不弄得像银行一样？

小白 我想应该是考虑成本吧。假如一家便利店全部的家当才10万块钱，然后花了20万元装备上保险库，显然是不划算的。

大鸟 是啊，同样的道理也适用于软件安全上。首先我们看有没有这样的软件需求：（1）有些产品根本就是用户内部使用，不会暴露给外面，谈不上安全性。（2）软件产品本身价值就是有限的，安全性的成本肯定要小于软件产品本身的价值。

8.2 软件安全性测试策略

小白 如何做好软件安全性测试呢？

大鸟 做好软件安全性测试的必要条件为：（1）充分了解软件安全漏洞；（2）选择好测试方法。

8.2.1 软件安全漏洞

小白 如何充分了解软件安全漏洞？

大鸟 先要搞清楚薄弱环节在哪里？需要什么样的安全级别？安全性包括哪几方面？哪块儿比较差？

大多数人对软件的薄弱环节到底是什么并没有给予足够重视。一般来说，密码术不会是系统最薄弱的部分。的确，密码是可攻破的，攻击者有可能找到较容易的方法攻破密码进入系统，但是攻破它仍然需要大量的计算工作。

如果攻击者想访问通过网络传输的数据，那么他们可能将其中一个端点作为目标，试图找到诸如缓冲区溢出之类的缺陷，然后在数据加密之前或在数据解密之后查看数据。如果存在可利用的缓冲区溢出，那么世界上所有的密码术都帮不了你。

因为以上原因，虽然加密密钥长度的确对系统的安全性有影响，但在大多数系统中它们并不是如此的重要，在这些系统中更重要的事情存在有缺陷。同样地，攻击者通常并不攻击防火墙本身，除非防火墙上有众所周知的弱点。实际上，他们将试图突破通过防火墙可见的应用程序，因为这些应用程序通常是更容易的目标。

所以保证软件安全，你应该首先消除看起来好像是最严重的风险，而不是看起来最容易减轻的风险。一旦一些其他组件很明显是更大的风险时，你就应该将精力集中到那个地方。

此外，有些弱点根本不是程序上的，而是流程上的。比如接线员轻易地透露了用户的信息，以至于黑客利用获得的信息攻击软件。

8.2.2 软件安全测试方法分类

小白 软件安全测试方法分为哪几种情况？

大鸟 分为如下几种情况。（1）反向安全性测试

大部分软件的安全测试都是依据缺陷空间反向设计原则来进行的，即事先检查哪些地方可能存在安全隐患，然后针对这些可能的隐患进行测试。因此，反向测试过程是从缺陷空间出发，建立缺陷威胁模型，通过威胁模型来寻找入侵点，对入侵点进行已知漏洞的扫描测试。这种测试的好处是可以对已知的缺陷进行分析，避免软件里存在已知类型的缺陷，但是对未知的攻击手段和方法通常会无能为力。

①建立缺陷威胁模型。建立缺陷威胁模型主要是从已知的安全漏洞入手，检查软件中是否存在已知的漏洞。建立威胁模型时，需要先确定软件牵涉到哪些专业领域，再根据各个专业领域所遇到的攻击手段来进行建模。

②寻找和扫描入侵点。检查威胁模型里的哪些缺陷可能在本软件中发生，再将可能发生的威胁纳入入侵点矩阵进行管理。如果有成熟的漏洞扫描工具，那么直接使用漏洞扫描工具进行扫描，然后将发现的可疑问题纳入入侵点矩阵进行管理。

③入侵矩阵的验证测试。创建好入侵矩阵后，就可以针对入侵矩阵的具体条目设计对应的测试用例，然后进行测试验证。（2）正向安全性测试

为了规避反向设计原则所带来的测试不完备性，需要一种正向的测试方法来对软件进行比较完备的测试，使测试过的软件能够预防未知的攻击手段和方法。

①先标识测试空间。对测试空间所有的可变数据进行标识，由于进行安全性测试的代价高昂，其中要重点对外部输入层进行标识。例如，需求分析、概要设计、详细设计、编码这几个阶段都要对测试空间进行标识，并建立测试空间跟踪矩阵。

②精确定义设计空间。重点审查需求中对设计空间是否有明确定义，需求牵涉到的数据是否都标识出了其合法取值范围。在这个步骤中，最需要注意的是精确二字，要严格按照安全性原则来对设计空间做精确的定义。

③标识安全隐患。根据找出的测试空间和设计空间以及它们之间的转换规则，标识出哪些测试空间和哪些转换规则可能存在安全隐患。例如，测试空间越复杂，即测试空间划分越复杂或可变数据组合关系越多，也就越不安全。还有，转换规则越复杂，则出问题的可能性也越大，这些都属于安全隐患。

④建立测试用例。安全隐患标识完成后，就可以根据标识出来的安全隐患建立测试用例。列出潜在安全隐患，标识出存在潜在安全隐患的可变数据，标识出安全隐患的等级。其中对于那些安全隐患等级高的可变数据，必须进行详尽的测试用例设计。

小白 正向和反向测试的区别是什么？

大鸟 正向测试过程是以测试空间为依据寻找缺陷和漏洞，反向测试过程则是以已知的缺陷空间为依据去寻找软件中是否会发生同样的缺陷和漏洞，两者各有其优缺点。反向测试过程主要的一个优点是成本较低，只要验证已知的、可能发生的缺陷即可，但缺点是测试不完善，无法将测试空间覆盖完整，无法发现未知的攻击手段。正向测试过程的优点是测试比较充分，但工作量相对来说较大。因此，对安全性要求较低的软件，一般按反向测试过程来测试即可，对于安全性要求较高的软件，应以正向测试过程为主，反向测试过程为辅。

小白 软件测试的测试点包括哪几方面？

大鸟 包括如下几方面。（1）用户认证安全。（2）系统网络安全。（3）数据库安全。

8.3 用户认证安全

小白 用户认证安全主要测试哪几个方面？

大鸟 用户认证安全的测试要考虑如下几个问题。（1）用户权限问题。（2）密码验证机制。（3）密码保护机制。

8.3.1 用户权限问题

小白 用户权限是指什么？

大鸟 一个好的软件系统，其中最基本的功能之一就是：不同职责的人员，对于系统操作的权限应该是不同的。具体来说这里面有如下三个概念。（1）组的特性：对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。（2）可扩展性：权限管理系统应该是可扩展的，它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样，权限管理系统可以被不断地重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。（3）功能权限和资源权限：传统业务系统中，存在着两种权限管理：其一是功能权限的管理，而另外一种则是资源（机器等）权限的管理。在不同系统之间，功能权限是可以重用的，而资源权限则不能。

小白 针对这些概念，我们在测试过程中具体的检查点是什么呢？

大鸟 QA要明确检查如下测试点。（1）区分系统中不同用户权限清晰。（2）保证系统中不会出现用户冲突。（3）系统不会因用户的权限的改变造成混乱。（4）在线超时。（5）操作留痕。8.3.1.1 区分系统中不同用户权限

小白 什么叫区分系统中不同用户权限？

大鸟 对于组来说，我们应该测试其可以添加/删除/授权用户的功能。通过一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法地使用已授权功能，而对那些未经授权的“非法用户”则被“拒之门外”。

小白 会不会有这样的情况，我们授权了某些用户，但是给了他过大的权限，甚至可以威胁系统管理员。

大鸟 如果赋予过大的权限，就可能导致只有普通用户权限的用户利用过大的权限做出危害安全的操作。例如，GUI界面上没有对其不能操作的内容做出限制，就可能导致用户可以访问超出规定范围的其他资源。做了一些不该做的事情。

小白 做了不该做的事，爱了不该爱的人。

大鸟 那伤心总是难免的，所以我们进行安全性测试时必须测试应用程序是否使用了过大的权限，重点要分析在各种情况下应该有的权限，然后检查实际中是否超出了给定的权限。权限过大问题本质上属于设计空间过大问题，所以在设计时要控制好设计空间，避免设计空间过大造成权限过大的问题。8.3.1.2 保证系统中不会出现用户冲突

试读结束[说明：试读内容隐藏了图片]

下载完整电子书