软件测试与质量保证
本文最后更新于 2024-06-02，文章内容可能已经过时。
1.基本概念：
1.1 质量：
质量是产品或工作的优劣程度，换句话说，质量就是用来衡量产品的或工作的好坏。
1.2 客户：
质量服务于客户，因客户存在而存在，而且质量由客户判定。
客户是质量的接受者，可以直接观察或感觉到质量的存在。
1.3 质量观点：
1.4 质量概念：
第一层次，“符合性质量”：能够满足国家或行业标准、产品规范的要求，最初的质量观念
第二层次，“适用性质量”：让客户满意，不仅满足标准、规范的要求，而且满足客户的其他要求
第三层次，“广义质量”：不仅要让客户满意，还要让客户愉快，也就是，想在客户的前面，超出客户的希望
1.5 质量形成过程：
1.5.1 ISO9000质量环：
1.5.2 朱兰质量螺旋曲线：
1.6 质量管理历史：
质量管理是指在质量方面指挥和控制组织的协调的活动。
1.7 软件特点：
1.8 软件开发的基本过程：
需求分析-设计-编程-测试-维护
1.9 软件缺陷：
从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题。
从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
2.软件质量：
软件质量是软件产品满足规定的和隐含的与需求能力有关的全部特征和特性。
2.1 特性：
2.2 内容：
软件质量是由3部分构成。
软件产品的质量，即满足使用要求的程度
软件开发过程的质量，即能否满足开发所带来的成本、时间和风险等要求
软件在其商业环境中所表现的质量
2.3 工程体系:
将软件质量管理作为一个系统来管理，运用系统科学的方法，通过有关质量的各种信息反馈与调控，对软件质量进行全面、综合的系统性管理，包括软件质量计划、组织、协调、控制，以实现软件质量的目标。
2.4 指标：
正确性：实现的功能达到设计规范，并满足用户需求的程度
可靠性：规定的时间和条件下，仍能维持其性能水准的程度
易用性：用户掌握软件操作所要付出的时间及努力程度
效率：软件执行某项功能所需电脑资源（含时间）的有效程度
可维护性：当环境改变或软件发生错误时，执行修改或恢复所做努力的程度
可移植性：从一个系统/环境移到另一系统/环境的容易程度
2.5 因素：
2.6 模型：
软件质量指标和软件质量因素的分析是为了建立软件模型。软件模型是描述他们之间的关系，分析软件质量因素究竟如何影响质量指标的，从而寻求最优的质量保证解决方案，最终达到软件质量目标。
2.7 工作层次：
2.7.1 质量方针：
在质量方针指导下，质量管理指挥和控制组织的质量活动，协调质量的各项工作，包括质量控制、质量保证和质量改进。
2.7.2 质量控制：
是一个设定标准(根据质量要求)、测量结果，判定是否达到了预期要求，对质量问题采取措施进行补救并防止再发生的过程。
2.7.3 质量保证：
为保护产品和服务充分满足消费者要求的质量而进行的有计划有组织的活动，致力于提供对满足质量要求的信任。
2.7.4 质量改进：
致力于增强满足质量要求的能力，是一个持续过程。
现己形成一套使每个环节不断改进的简单的流程模式：界定、测量、分析、改进、控制。
2.8 质量成本：
质量成本是为确保和保证满意的质量而发生的费用以及没有达到满意的质量所造成损失的总和，即包括保证费用和损失费用。
质量成本＝保证成本＋损失成本
保证成本＝预防成本＋评价成本
2.9 标准体系：
3.质量度量：
3.1 基本概念：
测量是对产品过程的某个属性的范围、数量、维度、容量或大小提供一个定量的指示。
度量是对软件产品进行范围广泛的测度，它给出一个系统、构件或过程的某个给定属性的度的定量测量。
指标是一个度量或一组度量的组合，采用易于理解的形式，对软件过程、项目或产品质量提供更全面、深入的评价和了解，以利于过程和质量的分析。
3.2 分类：
软件质量度量按其研究对像可分为3类：
项目质量度量
产品质量度量
过程质量度量
3.3 项目质量度量：
进度度量：通过任务分解、工作量度量、有效资源分配等做出计划，然后将实际结果和计划值进行对比来度量。
风险度量：一般通过两个参数“风险发生的概率”和“风险发生后所带来的损失”来评估风险。
规模度量：以代码行数、功能点数、对象点或特征点等来衡量。软件规模度量是工作量度量、进度度量的基础，用于估算软件项目工作量、编制成本预算、策划项目进度的基础。
复杂度度量：确定程序控制流或软件系统结构的复杂程度指标。复杂度度量用于估计或预测软件产品的可测试性、可靠性和可维护性，以便选择最优化、最可靠的程序设计方法，来确定测试策略、维护策略等。
缺陷度量：帮助确定产品缺陷分布的情况、缺陷变化的状态等，从而帮助分析修复缺陷所需的工作量、设计和编程中存在哪些弱点、预测产品发布时间、预测产品的遗留缺陷等。
工作量度量：任务分解并结合人力资源水平来度量，合理地分配研发资源和人力，获得最高的效率比。工作量度量是在软件规模度量和生产率度量的基础上进行。
其他的项目度量：顾客满意度、需求稳定性、资源利用效率、文档复审水平、问题解决能力、代码动态增长等。
3.4 产品质量度量：
3.5 过程质量度量：
软件过程质量要素分为共性过程质量要素和个性过程质量要素两大类。
共性过程质量要素：与软件开发过程中多个活动阶段都相关的质量要素，它在每个阶段中所需收集的数据、所用的度量方法、评价准则都是类似的。
个性过程质量要素：指只和当前的过程活动相关的质量要素。
4.质量标准：
4.1 层次：
国际标准一般，由国际机构制定和公布供各国参考的标准为国际标准。比如：ISO―国际标准化组织。
国家标准由政府或国家级的机构制定或批准，适用于本国范围的标准，如：GB、ANSI、BS、JIS等。
行业标准行业标准是由一些行业机构、学术团体或国防机构制定，并适用于某个业务领域的标准。如：IEEE、GJB、DOD-STD、MIL-S 。
4.2 CMMI：
软件过程能力成熟度是指一个特定过程被明确地定义、管理、测量、控制并且是有效的程度。
成熟度意味着能力上的增长能力，并表明一个组织软件过程的丰富性和在项目中运用它时的一致性。
4.2.1 分级：
初始级处于这个最低级的组织，基本上没有健全的软件工程管理制度。
可重复级有些基本的软件项目的管理行为、设计和管理技术是基于相似产品中的经验，故称为“可重复”。
已定义级已为软件生产的过程编制了完整的文档。软件过程的管理方面和技术方面都明确地做了定义，并按需要不断地改进过程，而且采用评审的办法来保证软件的质量。
已管理级对每个项目都设定质量和生产目标。这两个量将被不断地测量，当偏离目标太多时，就采取行动来修正。
优化级组织的目标是连续地改进软件过程。这样的组织使用统计质量和过程控制技术作为指导。从各个方面中获得的知识将被运用在以后的项目中，从而使软件过程融入了正反馈循环，使生产率和质量得到稳步的改进。
除第一级外，CMMI的每一级包含了实现这一级目标的若干关键过程域(KPA)，这些KPA指出了企业需要集中力量改进的软件过程。同时还指明了为了要达到该能力成熟度等级所需要解决的具体问题。
4.2.2 流程改进：
CMMI流程改进基本上可归纳为三大步：
确定流程改进的总体框架
细化框架内的要求
确流程改进的度量方法与标准
5.软件评审：
5.1 原因：
从成本上来衡量：缺陷发现得越晚纠正费用越高。
从技术上来衡量：前一阶段的错误会导致后一阶段的工作结果中有相应的错误，而且错误会逐渐累积，越来越多。
从效率上来衡量：
5.2 内容：
5.2.1 管理评审：
管理评审由最高管理者发起；要求各部门对管理体系目前的状况进行评审；状况包括适宜性、有效性、充分性。
5.2.2 技术评审：
技术评审是对产品以及各个阶段的输出内容进行评估。
目的是确保需求说明、设计说明书与最初的说明书保持一致。并按照计划对软件进行了正确的开发。
5.2.3 文档评审：
正确性
完整性
一致性
有效性
易测性
模块化
清晰性
可行性
可靠性
可追溯性
5.2.4 过程评审：
过程评审是对软件开发过程的评审，主要任务是通过对流程的监控，保证SQA组织定义的软件过程在项目中得到了遵守，同时保证质量方针能得到更快更好地执行。
5.3 评审方法：
对于最可能产生风险的工作成果，要采用最正式的评审方法。
5.4 评审技术：
5.5 评审会议：
制定评审计划和评审时间：
各个阶段的《评审计划》的内容包括：各个阶段的评审时间、评审方式、评审组成人员等。
应根据各个阶段的《评审计划》，制定相应的评审检查点。
组建评审组；
项目组提出评审组长和评审组成员名单的建议，质量组根据项目组的建议，与相关部门或人员进行协商确定。
选定评审组长对评审来说是非常重要的，评审组长需要和作者一起，策划和组织整个评审活动。
准备评审材料：
基础性和早期的文档，如需求说明和原型等
与重大决策有关的文档，如体系结构模型
对如何做没有把握的部分，如一些挑战性模块、不熟悉的或复杂的算法等
将不断被重复使用的部件
发送审查包：
将被审查的可交付产品/文档，其中指明了需要审查的部分
定义了可交付产品的前期文档
相关标准或其他参考文档
参与者需要的所有表格
有助于审查者发现缺陷的工具/文档：如缺陷检查表，相关规则等
用于验证可交付产品的测试文档
制定活动进程表：
评审会议之前，评审组长还需要制定相应的活动进度表，安排会议房间，并将活动、日期、次数和地点通知评审组成员。
6.SQA组织：
6.1 介绍：
SQA，软件质量管理组织。
6.2 组织结构：
SQA组织和SQA体系的创建并不需要完全照搬标准，应该以企业本身目标为前提。软件质量保证和企业实际相结合才是根本。
独立的SQA部门
独立的SQA工程师
非独立SQA小组
独立的SQA工程师
独立的SQA小组
6.3 角色分类：
6.3.1 非全职：
非全职SQA是指在组织结构中有自己的本职工作，在完成本职工作之外，还需要兼职完成SQA的任务的相关人员。
项目经理
开发工程师
测试工程师
6.3.2 全职：
专职的SQA人员承担了大部分的SQA任务，对质量保证目标的实现起着非常重要的作用。
SQA经理
SQA工程师
6.4 SQA计划：
7.软件设计：
软件设计是软件开发的重要阶段之一，是把软件需求转换为软件表示的过程，也是将用户需求准确转化为软件系统的唯一途径。
7.1 目标：
7.2 评价标准：
实体空间标准：--以源系统做为标准来度量系统设计模型，是一个软件设计最终应该附合的标准。关键词：设计的合理性、专家、用户代表
过程空间标准：--可以看作实体空间的间接标准。关键词：分析模型、设计模型、一致性
形式空间标准：--以目标系统的角度(即软件产品质量属性)检验系统设计。产品质量标准就是形式空间的标准。
7.3 设计原则：
设计过程中，始终以质量为目标而展开
设计越简单越好
软件设计的指导思想
降低模块耦合度
提高模块内聚性
8.高质量编程：
8.1 命名规则：
对于一般标示符，适当的使用简写形式，以最短的组合词表达所需要表达的意义。
程序中不要仅靠大小写来区分相似的标识符。
程序中尽量不要出现与标示符完全相同的局部变量和全局变量。
变量的名字应当使用“名词”或者“形容词+名词”。
全局函数的名字应当使用“动词”或者“动词+名词”。
类的成员函数应当只使用“动词”，被省略掉的名词就是对象本。
用正确的反义词组命名具有互斥意义的变量或者相反动作的函数。
8.2 函数处理规则：
8.3 文件结构：
8.4 程序的版式：
9.软件测试：
9.1 概述：
测试是为了发现错误而执行程序的过程
由于软件错误的复杂性，在软件工程范围内要综合应用测试技术，根据定义域中的取值，通过执行和观察，将预期的行为和实际的行为做比较，以确认测试的结果，因此软件测试是一个综合测试的过程。
9.2 测试过程：
9.2.1 单元测试：
对软件中的最小可测试单元进行检查和验证。
接口测试
局部数据结构测试
重要执行路径测试
错误处理测试
边界条件测试
9.2.2 集成测试：
也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统后进行的测试。
所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统。
测试技术：
黑盒测试
功能测试和非功能测试
测试人员：
集成测试应由专门的测试小组来进行
测试小组由有经验的系统设计人员和程序员组成
整个测试活动要在评审人员出席的情况下进行
9.2.3 系统测试：
将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试。
功能测试
性能测试
强度测试
可靠性测试
恢复测试
安装测试
安全性测试
配置测试
可用性测试
兼容性测试
网站测试
压力测试
9.2.4 验收测试：
部署软件之前的最后一个测试操作，也称为交付测试。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
9.2.5 回归测试：
修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
10.白盒测试：
白盒测试也称结构测试或逻辑驱动测试。
它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作；
白盒测试是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。
主要有五种方法：
逻辑覆盖
循环测试
基本路径测试
程序插装
程序变异
10.1 逻辑覆盖法：
逻辑覆盖包括六种覆盖标准：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
10.1.1 语句覆盖：
在测试时首先设计若干个测试用例，然后运行被测程序，使程序中的每个可执行语句至少执行一次。这里所谓“若干个”，自然是越少越好。
10.1.2 判定覆盖：
设计若干测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断的真假值均曾被满足。
10.1.3 条件覆盖：
条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。
10.1.4 判定/条件覆盖：
设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。
10.1.5 条件组合覆盖:
要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。
10.1.6 路径覆盖:
设计足够的测试用例，覆盖程序中所有可能的路径.
即使都覆盖到了，仍然不能保证被测程序的正确性。
10.2 循环测试：
循环语句分为以下4种：简单循环、嵌套循环、连锁循环和非结构循环。
10.2.1 简单循环：
10.2.2 嵌套循环：
除最内层循环外，从最内层循环开始，置所有其他层的循环为最小值；
对最内层循环做简单循环的全部测试。测试时保持所有外层循环的循环变量为最小值。另外，对越界值和非法值做类似的测试。
逐步外推，对其外面一层循环进行测试。测试时保持所有外层循环的循环变量取最小值，所有其它嵌套内层循环的循环变量取“典型”值。
反复进行，直到所有各层循环测试完毕。®完全跳过循环；仅循环一次；
10.2.3 连锁循环：
10.2.4 非结构循环：
使用结构化程序设计方法重新设计测试用例。
10.3 基本路径测试：
把覆盖的路径数压缩到一定限度内，例如，程序中的循环体只执行零次和一次，就成为基本路径测试。
设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次。
10.3.1 画出控制流图：
10.3.2 计算圈复杂度：
一种为程序逻辑复杂性提供定量测度的软件度量。
给定流图G的圈复杂度V(G)，定义为V(G)=E-N+2，E是流图中边的数量，N是流图中结点的数量;
给定流图G的圈复杂度V(G)，定义为V(G)=P+1，P是流图G中判定结点的数量。
10.3.3 导出测试用例：
根据上面的计算方法，可得出四个独立的路径。
一条独立路径是指，和其他的独立路径相比，至少引入一个新处理语句或一个新判断的程序通路。V(G)值正好等于该程序的独立路径的条数。
10.3.4 准备测试用例：
为了确保基本路径集中的每一条路径的执行，根据判断结点给出的条件，选择适当的数据以保证某一条路径可以被测试到。
10.4 程序插装：
基本的测试手段，在软件测试中有着广泛的应用。
保持被测试程序原有逻辑完整性基础上在程序中插入一些探针，通过探针的执行并抛出程序的运行特征数据。基于这些特征数据分析可以获得程序的控制流及数据流信息，进而得到逻辑覆盖等动态信息。
这种方式相当于在运行程序以后，一方面检验测试结果数据，另一方面借助插入语句给出的信息了解程序的动态执行情况。
10.5 程序变异测试：
通过检查测试用例集合是否可以发现特定的错误，来评判测试用例集合完备性的一种软件测试策略。
如果一个测试用例集合可以检测出程序中所有的简单错误，那么这个测试用例集合就可以检测出所有错误（基于单缺陷原则）。
11.黑盒测试：
黑盒测试也称功能测试，通过测试来检测每个功能是否都能正常使用。
测试中把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试。
只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。
黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
11.1 等价类划分：
等价类划分法是一种黒盒测试的技术。
不考虑程序的内部结构，把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。
该方法是一种重要的，常用的黑盒测试用例设计方法。
11.1.1 有效/无效等价类：
有效等价类：
指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合。
利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
无效等价类：
与有效等价类的定义恰巧相反，不符合需求规格说明书。
11.1.2 确定原则：
在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。
在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。
在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。
11.1.3 具体过程：
11.1.3.1 区分等效类：
11.1.3.2 设计测试用例：
从划分出的等价类中按以下三个原则设计测试用例。
每一个等价类规定一个唯一的编号。
设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步。直到所有的有效等价类都被覆盖为止。
设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。
11.1.3.3 进行测试
11.2 边界值分析法：
是对输入或输出的边界值进行测试的一种黑盒测试方法。
边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
11.2.1 设计原则：
如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据。
根据规格说明的每个输出条件，使用前面的原则①。
根据规格说明的每个输出条件，应用前面的原则②。
如果程序的规格说明给出的输入域或输出域是有序集合，应选取集合的第一个元素和最后一个元素作为测试用例。
如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例。n分析规格说明，找出其他可能的边界条件。
11.3 因果图法：
适合于检查程序输入条件的各种组合情况。
等价类划分方法和边界值分析方法，着重考虑输入条件，未考虑输入条件之间的联系。
如果在测试时必须考虑输入条件的各种组合，可能的组合数将是天文数字。因此必须考虑使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例，这就需要利用因果图。
因果图方法最终生成的就是决策表。它适合于检查程序输入条件的各种组合情况。
11.3.1 设计方法：
11.4 功能图法：
功能图方法是一种黑盒、白盒混合用例设计方法
用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例。
功能图模型由状态迁移图和逻辑功能模型构成。
11.4.1 状态迁移图：
11.5 选择策略：
首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法。
在任何情况下都必须使用边界值分析方法。经验表明，用这种方法设计出的测试用例发现程序错误的能力最强。
可以用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验。
对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法。
对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。
功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据。
对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。
12.集成测试：
集成测试是在单元测试的基础上，将多个模块组合在一起进行测试的过程，主要检查各个软件单元之间的相互接口是否正确。
12.1 设计方法：
为系统运行来而设计用例
为正向测试设计用例
为逆向测试设计用例
为满足特殊需求设计用例
为高覆盖率而设计用例
基于模块接口依赖关系来设计用例
12.2 测试过程：
根据集成测试不同阶段的任务，可以把集成测试的过程划分为三个阶段。
计划阶段：
完成集成测试计划，制定集成测试策略。
设计实现阶段：
建立集成测试环境，完成测试设计和开发。
执行评估阶段：
执行集成测试用例，记录和评估测试结果。
13.系统测试：
集成测试通过以后，各模块已经组装成—个完整的软件包，这时就要进行系统测试。
系统测试是指将通过集成测试的软件系统，作为计算机系统的一个重要组成部分，与计算机硬件、外设、某些支撑软件的系统等其他系统元素组合在一起所进行的测试，目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或矛盾的地方。
系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等是否满足需求分析所指定的要求。
13.1 流程：
13.2 主要方法：
性能测试
强度测试
安全性测试
兼容性测试
恢复测试
用户图形界面测试
系统测试工具及其应用
安装测试
可靠性测试
配置测试
可用性测试
文档资料测试
网站测试
系统测试很困难，没有一套通用的方法。因此，系统测试需要真正的创造性。
系统测试由若干个不同的测试类型组成，每一种测试都有一个特定的目标，然而，所有的测试都要充分地运行系统，验证系统各部分能否协调地工作并完成指定的功能。
14.验收测试：
在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动它是技术测试的最后一个阶段,也称为交付测试。
14.1 产品规格说明书：
产品规格说明书是综合客户的需求以及没有提出但必须实现的需求，定义产品的目的、适应范围，有哪些功能，界面表现形式和外观等的文档。通常是用文字和图形来描述产品的Word、PDF或HTML文档，其格式没有特别的要求。
产品规格说明书的审核不是主要任务，但是非常重要，可以去除60%的错误。
14.2 用户界面：
用户界面的7个要素:
符合标准和规范
直观性
一致性
灵活性
舒适性
正确性
实用性易用性测试没有具体量化的指标，主观性较强。
14.3 兼容性：
软件兼容性测试是指验证软件之间是否正确地交互和共享信息。
兼容性包括：
硬件兼容
软件之间兼容
数据之间兼容
14.4 可安装性可恢复性：
