《软件测试规范》
《软件测试规范》(草案)
Computer Software Testing Criterion
⼀、⽬的与适⽤范围
1、⽬的
软件测试是软件⼯程的重要组成部分，测试⼯作的质量直接影响软件产品的⽣命⼒。测试⼯作的标准化是软件质量保证(Quality Assurance)重要⽽且必须的环节。制定本标准的⽬的在于使测试流程更标准，测试过程更规范。从⽽使整个软件⽣产纳⼊更系统化、更专业化的轨道。
2、适⽤范围
本标准适⽤于软件测试流程的管理和测试的具体操作过程。本标准的使⽤者可以是企业内部的测试⼈员和开发⼈员。
⼆、测试⽅法
软件测试的⽅法和技术是多种多样的。以下将介绍⽐较常⽤的⼀些测试⽅法：
1、静态测试
静态⽅法是指不运⾏被测程序本⾝，仅通过分析或检查源程序的⽂法、结构、过程、接⼝等来检查程序的正确性。静态⽅法通过程序静态特性的分析，出⽋缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分⽀嵌套、不允许的递归、未使⽤过的变量、空指针的引⽤和可疑的计算等。静态测试结果可⽤于进⼀步的查错，并为测试⽤例选取提供指导。2、动态测试
动态⽅法是指通过运⾏被测程序，检查运⾏结果与预期结果的差异，并分析运⾏效率和健壮性等性能，这种⽅法由三部分组成：构造测试实例、执⾏程序、分析程序的输出结果。3、⿊盒测试
⿊盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使⽤，在测试时，把程序看作⼀个不能打开的⿊盆⼦，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接⼝进⾏测试，它只检查程序功能是否按照需求规格说明书的规定正常使⽤，程序是否能适当地接收输⼊数锯⽽产⽣正确的输出信息，并且保持外部信息（如数据库或⽂件）的完整性。⿊盒测试⽅法主要有等价类划分、边值分析、因—果图、错误推测等，主要⽤于软件确认测试。
“⿊盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界⾯和软件功能进⾏测试。“⿊盒”法是穷举输⼊测试，只有把所有可能的输⼊都作为测试情况使⽤，才能以这种⽅法查出程序中所有的错误。实际上测试情况有⽆穷多个，⼈们不仅要测试所有合法的输⼊，⽽且还要对那些不合法但是可能的输⼊进⾏测试。
4、⽩盒测试
⽩盒测试也称结构测试或逻辑驱动测试，它是知道产品内部⼯作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进⾏，按照程序内部的结构测试程序，检验
程序中的每条通路是否都有能按预定要求正确⼯作，⽽不顾它的功能，⽩盒测试的主要⽅法有逻辑驱动、基路测试等，主要⽤于软件验证。
“⽩盒”法全⾯了解程序内部逻辑结构、对所有逻辑路径进⾏测试。“⽩盒”法是穷举路径测试。在使⽤这⼀⽅案时，测试者必须检查程序的内部结构，从检查程序的逻辑着⼿，得出测试数据。贯穿程序的独⽴路径数是天⽂数字。但即使每条路径都测试了仍然可能有错误。第⼀，穷举路径测试决不能查出程序违反了设计规范，即程序本⾝是个错误的程序。第⼆，穷举路径测试不可能查出程序中因遗漏路径⽽出错。第三，穷举路径测试可能发现不了⼀些与数据相关的错误。
5、ALAC(Act-like-a-customer)测试
ALAC测试是⼀种基于客户使⽤产品的知识开发出来的测试⽅法。ALAC测试是基于复杂的软件产品有许多错误的原则。最⼤的受益者是⽤户，缺陷查和改正将针对哪些客户最容易遇到的错误。
6、单元测试⽅法
6.1单元测试任务
单元测试任务包括：
u 模块接⼝测试；
u 模块局部数据结构测试；
u 模块边界条件测试；
u 模块中所有独⽴执⾏通路测试；
u 模块的各条错误处理通路测试。
模块接⼝测试是单元测试的基础。只有在数据能正确流⼊、流出模块的前提下，其他测试才有意义。
6.2接⼝测试
测试接⼝正确与否应该考虑下列因素：
u 输⼊的实际参数与形式参数的个数是否相同；
u 输⼊的实际参数与形式参数的属性是否匹配；
u 输⼊的实际参数与形式参数的量纲是否⼀致；
u 调⽤其他模块时所给实际参数的个数是否与被调模块的形参个数相同；
u 调⽤其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；
u 调⽤其他模块时所给实际参数的量纲是否与被调模块的形参量纲⼀致；
u 调⽤预定义函数时所⽤参数的个数、属性和次序是否正确；
u 是否存在与当前⼊⼝点⽆关的参数引⽤；
u 是否修改了只读型参数；
u 对全程变量的定义各模块是否⼀致；
u 是否把某些约束作为参数传递。
如果模块内包括外部输⼊输出，还应该考虑下列因素：
u ⽂件属性是否正确；
u OPEN/CLOSE语句是否正确；
u 格式说明与输⼊输出语句是否匹配；
u 缓冲区⼤⼩与记录长度是否匹配；
u ⽂件使⽤前是否已经打开；
u 是否处理了⽂件尾；
u 是否处理了输⼊/输出错误；
u 输出信息中是否有⽂字性错误；
6.3数据测试
检查局部数据结构是为了保证临时存储在模块内的数据在程序执⾏过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试⽤例，⼒求发现下⾯⼏类错误：
u 不合适或不相容的类型说明；
u 变量⽆初值；
u 变量初始化或省缺值有错；
u 不正确的变量名（拼错或不正确地截断）；
u 出现上溢、下溢和地址异常。
除了局部数据结构外，如果可能，单元测试时还应该查清全局数据（例如FORTRAN 的公⽤区）对模块的影响。
6.4控制流测试
在模块中应对每⼀条独⽴执⾏路径进⾏测试，单元测试的基本任务是保证模块中每条语句⾄少执⾏⼀次。此时设计测试⽤例是为了发现因错误计算、不正确的⽐较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常⽤且最有效的测试技术。计算中常见的错误包括：
u 误解或⽤错了算符优先级；
u 混合类型运算；
u 变量初值错；
u 精度不够；
u 表达式符号错。
⽐较判断与控制流常常紧密相关，测试⽤例还应致⼒于发现下列错误：
u 不同数据类型的对象之间进⾏⽐较；
u 错误地使⽤逻辑运算符或优先级；
u 因计算机表⽰的局限性，期望理论上相等⽽实际上不相等的两个量相等；
u ⽐较运算或变量出错；
u 循环终⽌条件或不可能出现；
u 迭代发散时不能退出；
u 错误地修改了循环变量。
6.5出错处理测试
⼀个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题：
u 输出的出错信息难以理解；
u 记录的错误与实际遇到的错误不相符；
u 在程序⾃定义的出错处理段运⾏之前，系统已介⼊；
u 异常处理不当；
软件测试项目流程
u 错误陈述中未能提供⾜够的定位出错信息。
6.6边界条件测试
边界条件测试是单元测试中最后，也是最重要的⼀项任务。众的周知，软件经常在边界上失效，采⽤边界值分析技术，针对边界值及其左、右设计测试⽤例，很有可能发现新的错误。
7、集成测试的基本⽅法
某设计⼈员习惯于把所有模块按设计要求⼀次全部组装起来，然后进⾏整体测试，这称为⾮增量式集成。这种⽅法容易出现混乱。因为测试时可能发现⼀⼤堆错误，为每个错误定位和纠正⾮常困难，并且在改正⼀个错误的同时⼜可能引⼊新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是增量式集成⽅法，程序⼀段⼀段地扩展，测试的范围⼀步⼀步地增⼤，错误易于定位和纠正，界⾯的测试亦可做到完全彻底。下⾯讨论两种增量式集成⽅法。
7.1 ⾃顶向下集成
⾃顶向下集成是构造程序结构的⼀种增量式⽅式，它从主控模块开始，按照软件的控制层次结构，以深度优先或⼴度优先的策略，逐步把各个模块集成在⼀起。深度优先策略⾸先是把主控制路径上的模块集成在⼀起，⾄于选择哪⼀条路径作为主控制路径，这多少带有随意性，⼀般根据问题的特性确定。
⾃顶向下集成测试的具体步骤为：
u 以主控模块作为测试驱动模块，把对主控模块进⾏单元测试时引⼊的所有桩模块⽤实际模块替代；
u 依据所选的集成策略（深度优先或⼴度优先），每次只替代⼀个桩模块；
u 每集成⼀个模块⽴即测试⼀遍；
u 只有每组测试完成后，才着⼿替换下⼀个桩模块；
u 为避免引⼊新错误，须不断地进⾏回归测试（即全部或部分地重复已做过的测试）；u 从第⼆步开始，循环执⾏上述步骤，直⾄整个程序结构构造完毕。
⾃顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进⾏检验，因此较早地发现错误。缺点是在测试较⾼层模块时，低层处理采⽤桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分。解决这个问题有⼏种办法，第⼀种是把某些测试推迟到⽤真实模块替代桩模块之后进⾏，第⼆种是开发能模拟真实模块的桩模块；第三种是⾃底向上集成模块。第⼀种⽅法⼜回退为⾮增量式的集成⽅法，使错误难于定位和纠正，并且失去了在组装模块时进⾏⼀些特定测试的可能性；第⼆种⽅法⽆疑要⼤⼤增加开销；第三种⽅法⽐较切实可⾏。
7.2⾃底向上集成
⾃底向上测试是从“原⼦”模块（即软件结构最低层的模块）开始组装测试，因测试到较⾼层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。
⾃底向上综合测试的步骤分为：
u 把低层模块组织成实现某个⼦功能的模块（cluster）;
u 开发⼀个测试驱动模块，控制测试数据的输⼊和测试结果的输出；
u 对每个模块进⾏测试；
u 删除测试使⽤的驱动模块，⽤较⾼层模块把模块组织成为完成更⼤功能的新模块；u 从第⼀步开始循环执⾏上述各步骤，直⾄整个程序构造完毕。
⾃底向上集成⽅法不⽤桩模块，测试⽤例的设计亦相对简单，但缺点是程序最后⼀
个模块加⼊时才具有整体形象。它与⾃顶向综合测试⽅法优缺点正好相反。因此，在测试软件系统时，应根据软件的特点和⼯程的进度，选⽤适当的测试策略，有时混和使⽤两种策略更为有效，上层模块⽤⾃顶向下的⽅法，下层模块⽤⾃底向上的⽅法。
此外，在集成测试中尤其要注意关键模块，所谓关键模块⼀般都具有下述⼀或多个特征：①对应⼏条需求；②具有⾼层控制功能；③复杂、易出错；④有特殊的性能要求。关键模块应尽早测试，并反复进⾏回归测试。
8、确认测试的基本⽅法
8.1确认测试标准
实现软件确认要通过⼀系列⿊盒测试。确认测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义⼀些特殊的测试⽤例，旨在说明软件与需求是否⼀致。⽆论是计划还是过程，都应该着重考虑软件是否满⾜合同规定的所有功能和性能，⽂档资料是否完整、准确，⼈机界⾯和其他⽅⾯（例如，可移植性、兼容性、错误恢复能⼒和可维护性等）是否令⽤户满意。
确认测试的结果有两种可能，⼀种是功能和性能指标满⾜软件需求说明的要求，⽤户可以接受；另⼀种是软件不满⾜软件需求说明的要求，⽤户⽆法接受。项⽬进⾏到这个阶段才发现严重错误和偏差⼀般很难在预定的⼯期内改正，因此必须与⽤户协商，寻求⼀个妥善解决问题的⽅法。
8.2 配置复审
确认测试的另⼀个重要环节是配置复审。复审的⽬的在于保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。
8.3α、β测试
事实上，软件开发⼈员不可能完全预见⽤户实际使⽤程序的情况。例如，⽤户可能错误的理解命令，或提供⼀些奇怪的数据组合，亦可能对设计者⾃认明了的输出信息迷惑不解，等等。因此，软件是否真正满⾜最终⽤户的要求，应由⽤户进⾏⼀系
列“验收测试”。验收测试既可以是⾮正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚⾄数⽉，不断暴露错误，导致开发延期。⼀个软件产品，可能拥有众多⽤户，不可能由每个⽤户验收，此时多采⽤称为α、β测试的过程，以期发现那些似乎只有最终⽤户才能发现的问题。
α测试是指软件开发公司组织内部⼈员模拟各类⽤户⾏对即将⾯市软件产品（称为α版本）进⾏测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运⾏环境和⽤户对软件产品的操作并尽最⼤努⼒涵盖所有可能的⽤户操作⽅式。经过
α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各⽅⾯的典型⽤户在⽇常⼯作中实际使⽤β版本，并要求⽤户报告异常情况、提出批评意见。然后软件开发公司再对β版本进⾏改错和完善。
9、系统测试的基本⽅法
9.1恢复测试
恢复测试主要检查系统的容错能⼒。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试⾸先要采⽤各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于⾃动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动(restart)等机制的正确性；对于⼈⼯⼲预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。
9.2安全测试
安全测试检查系统对⾮法侵⼊的防范能⼒。安全测试期间，测试⼈员假扮⾮法⼊侵者，采⽤各种办法试图突破防线。例如，①想⽅设法截取或破译⼝令；②专门定做软件破坏系统的保护机制；③故意导致系统失败，企图趁恢复之机⾮法进⼊；④试图通过浏览⾮保密数据，推导所需信息，等等。理论上讲，只要有⾜够的时间和资源，没有不可进⼊的系统。因此系统安全设计的准则是，使⾮法侵⼊的代价超过被保护信息的价值。此时⾮法侵⼊者已⽆利可图。
9.3强度测试
强度测试检查程序对异常情况的抵抗能⼒。强度测试总是迫使系统在异常的资源配置下运⾏。例如，①当中断的正常频率为每秒⼀⾄两个时，运⾏每秒产⽣⼗个中断的测试⽤例；②定量地增长数据输⼊率，检查输⼊⼦功能的反映能⼒；③运⾏需要最⼤存储空间（或其他资源）的测试⽤例；④运⾏可能导致虚
存操作系统崩溃或磁盘数据剧烈抖动的测试⽤例，等等。
9.4性能测试
对于那些实时和嵌⼊式系统，软件部分即使满⾜功能要求，也未必能够满⾜性能要求，虽然从单元测试起，每⼀测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全⾯、可靠地测试运⾏性能系统性能测试是为了完成这⼀任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套⽀持。
10、回归测试⽅法
回归测试的价值在于它是⼀个能够检测到回归错误的受控实验。当测试组选择缩减的回归测试时，有可能删除了将揭⽰回归错误的测试⽤例，消除了发现回归错误的机会。然⽽，如果采⽤了代码相依性分析等安全的缩减技术，就可以决定哪些测试⽤例可以被删除⽽不会让回归测试的意图遭到破坏。
选择回归测试策略应该兼顾效率和有效性两个⽅⾯。常⽤的选择回归测试的⽅式包括：10.1再测试全部⽤例：
选择基线测试⽤例库中的全部测试⽤例组成回归测试包，这是⼀种⽐较安全的⽅法，再测试全部⽤例具有最低的遗漏回归错误的风险，但测试成本最⾼。全部再测试⼏乎可以应⽤到任何情况下，基本上不需
要进⾏分析和重新开发，但是，随着开发⼯作的进展，测试⽤例不断增多，重复原先所有的测试将带来很⼤的⼯作量，往往超出了我们的预算和进度。
10.2基于风险选择测试：
可以基于⼀定的风险标准来从基线测试⽤例库中选择回归测试包。⾸先运⾏最重要的、关键的和可疑的测试，⽽跳过那些⾮关键的、优先级别低的或者⾼稳定的测试⽤例，这些⽤例即
便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。⼀般⽽⾔，测试从主要特征到次要特征
10.3基于操作剖⾯选择测试：
如果基线测试⽤例库的测试⽤例是基于软件操作剖⾯开发的，测试⽤例的分布情况反映了系统的实际使⽤情况。回归测试所使⽤的测试⽤例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使⽤功能的测试⽤例，释放和缓解最⾼级别的风险，有助于尽早发现那些对可靠性有最⼤影响的故障。这种⽅法可以在⼀个给定的预算下最有效的提⾼系统可靠性，但实施起来有⼀定的难度。
10.4再测试修改的部分：
当测试者对修改的局部化有⾜够的信⼼时，可以通过相依性分析识别软件的修改情况并分析修改的影响，
将回归测试局限于被改变的模块和它的接⼝上。通常，⼀个回归错误⼀定涉及⼀个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。再测试全部⽤例的策略是最安全的策略，但已经运⾏过许多次的回归测试不太可能揭⽰新的错误，⽽且很多时候，由于时间、⼈员、设备和经费的原因，不允许选择再测试全部⽤例的回归测试策略，此时，可以选择适当的策略进⾏缩减的回归测试。
三、测试阶段的划分

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。