关键字：软件测试知识帖
第85贴【2004－8－17】：可接受测试 用户可接受性测试（User Acceptance Testing）有时也叫验收测试。在通过了内部系统测试及软件配置审查之后，就可以开始该项测试了。验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。由用户参加设计测试用例，使用用户界面输入测试数据，并分析测试的输出结果，一般使用生产中的实际数据进行测试。在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。验收测试实际上是对整个测试计划进行一种“走读（Walkthrough）”。
用户可接受测试具有下列特点：
Ø1、必须要有用户参与，且以用户为主；
2、可接受测试在不同的组织之间，随目标的不同及工作量的不同而不同；
Ø3、在软件开发过程当中，可接受测试是最容易变化的一个测试；
Ø4、用户可接受测试只有按照既定的目标进行的时候才能有真正的效果；
Ø5、很少有组织能够真正理解如何处理测试中人的方面问题，他们同时还缺乏必要的培训来进行计划和执行一个有效的可接受性测试
第86贴【2004－8－19】：标杆测试
系统指标能够描述该产品的基本特性的性能，该指标也可以称为性能指标。系统指标在系统设计初期就会提出来，但是最终产品详细指标如何必须通过严格的测试才可以得到。要根据系统稳定性测试模型，结合系统运行的实际情况对系统进行指标测试或标杆测试（Benchmark Testing）。
系统标杆测试的基本概念可以分为两部分：
Ø 在系统基本配置或最优化配置条件下，通过测试工具等模拟系统环境和提供单一或标准负荷模型，从而得到系统各种表征特性的指标，进一步可以验证系统需求和设计规格中的指标是否达到；
Ø 在多任务并接近实际网上运行等复杂条件下，由于受CPU ，内存，存储器，通道，网络，系统配置等资源的影响而测试出系统性能在各方面潜在的低效和限制，比如系统瓶颈，系统指标上限。
第86贴【2004－8－21】：在线帮助测试
用户在使用系统时候，如果出现问题，首先求助的就是在线帮助。一个糟糕的在线帮助会很大的打击用户对系统的信心。因此一个好的系统，必须要有完备的帮助体系，包括用户操作手册，实时在线帮助等。在线帮助的测试（Online Help Testing）主要用于验证系统的实时在线帮助的可用性和正确性。
在实际操作过程中，在线帮助测试可以和文档测试（或资料测试）一起进行。在进行在线帮助测试的时候，测试人员需要关注下面这些问题：
Ø 1、帮助文件的索引是否正确？
Ø 2、帮助文件的内容是否正确？
Ø 3、在系统运行过程中帮助能否被正常的激活？
Ø 4、在系统不同的位置激活的帮助内容与当前操作内容是否相关联？
Ø 5、帮助是否足够详细并能解决需要被解决的问题？
第87贴【2004－8－23】：软件可靠性
软件可靠性（Software Reliability）可以定义为：在规定环境，规定时间内（自然单元或时间单元），一个系统或其功能无故障运行的可能性。
其中：
Ø 规定的环境包括硬件环境和软件环境。软件环境包括允许的操作系统、应用程序、编译系统、数据库系统等；硬件环境包括CPU、内存、I/O等。
Ø 规定的时间一般分为执行时间、日历时间和时钟时间。其中执行时间（Executing Time）是指执行一个程序所用的实际时间和中央处理器时间，或者是程序处于执行过程中的一段时间；日历时间（Calendar time）指的是编年时间，包括计算机可能未运行的时间；时钟时间（Clock time）是指从程序执行开始到程序执行完毕所经历的钟表时间。
Ø 自然单元除时间外，跟软件产品处理数目相关的单元如运行、电话呼叫、API调用等都可以看作是一个自然单元。
第88贴【2004－8－24】：软件可靠性的层次
从用户角度来看，软件可靠性可以分四个层次来看：
第一个层面：软件不出现故障；
第二个层面：软件即使出现故障，也仅对性能有部分影响，而设备的功能不受损失；
第三个层面：软件出现故障并造成部分功能受损失，但是能够很快恢复业务；
第四个层面：软件出现较大故障，并造成大部分功能受损、业务中断或瘫痪，但能够尽快恢复业务（无论是手工恢复还是自动恢复）；
对应于不同的可靠性层次，要求系统有相应的层次设计要求和维护要求，例如：
对于第一个层面：要求系统能够按照充分的规范来进行设计，加强各种异常处理能力和环境适应能力等；
对于第二个层面：要求系统有较高的容错能力，使用冗余技术和备份技术等；
对于第三个层面：要求系统有很好的可测试性，能迅速隔离问题和定位问题等；
对于第四个层面：要求系统有较高的可维护性等
第89贴【2004－8－25】：软件的失效
失效是指功能部件执行其规定功能的能力丧失。
从失效本身的类型来分，又可以分为：
Ø 1、独立失效（Independent Failure）：指不是由于另一个产品失效而引起的失效；
Ø 2、从属失效（Dependent Failure）：由于另一产品失效而引起的失效。
Ø 3、系统性失效（Systematic Failure）：由某一固有因素引起，以特定形式出现的失效。它只能通过修改设计、制造工艺、操作程序或其它关联因素来消除。注：无改进措施的修复性维修通常不能消除其失效原因。系统性失效可以通过模拟失效原因来诱发。
Ø 4、偶然失效（Random Failure）：产品由于偶然因素引起的失效。只能通过概率或统计方法来预测。
Ø 5、单点失效（Single-point Failure）：引起产品失效的，且没有冗余或替代的工作程序作为补救的局部失效。
Ø 6、间歇故障（Intermittent Failure）：产品发生故障后，不经修理而在有限时间内自行恢复功能的故障。
Ø 7、渐变失效（Gradual Failure）：通过事前的检测或监测可以预测到的失效，它是由于产品的规定性能随寿命单位数增加而逐渐变化引起的。对电子产品也称漂移失效(Drift Failure)。
Ø 8、致命性失效（Critical Failure）：使产品不能完成规定任务的或可能导致人或物重大损失的失效或失效组合。
Ø 9、灾难性失效（Catastrophic Failure）：导致人员伤亡或系统毁坏的失效。
Ø 10、非关联失效（Non-relevant Failure）：已经证实是未按规定的条件使用而引起的失效。或已经证实仅属某项将不采用的设计所引起的失效。
Ø 11、非责任失效（Non-chargeable Failure）：非关联失效或事先已经规定不属某组织机构责任范围内的关联失效。
第90贴【2004－8－26】：可靠性指标分配
可靠性指标分配是指把系统的可靠性指标分配给系统、子系统、模块、元器件（或函数）。其主要目的是使各级设计人员明确其可靠性设计要求，并研究实现这些要求的可能性及方法。它也是可靠性试验和评估的依据。
对于电子设备，可靠性可以从整机一直分配到各个元器件。可靠性分配的目的就是使各级设计人员明确其可靠性设计要求，根据要求估计所需的人力、时间和资源，并研究实现这个要求的可能性及方法。然而对于软件来说，可靠性分配却有很大的不同，因为把可靠性分解到每一行源代码是没有意义的。对于一个系统，软件可靠性可以作为一个整体来进行考虑，它和硬件可靠性一起组成了整个系统的可靠性。它们直接的关系可以用下面公式表示：
1/MTBF（系） = 1/MTBF（硬） + 1/MTBF（软）
在硬件方面，可靠性分配的时候需要考虑各器件的组合方式（并联还是串联），同时还要考虑各种加权因子（例如重要性因子、复杂因子、环境因子、标准化因子、维修性因子和元器件质量因子）。一般来说，重要的单元应分配较高的可靠性，复杂度高的单元应分配较低的可靠性，处于恶劣环境下的单元应分配较低的可靠性，技术上不成熟的单元应分配较低的可靠性。
总之，对可靠性指标的分配必须做到合理协调、技术上可行、经济上合算。分配的可靠性指标，必须进行可靠性分析，如果分配给分系统的可靠性指标为当前技术水平和条件所限，而无法实现者，必须修改方案，重新分配，直到满足要求为止。
第91贴【2004－8－27】：FMEA
故障模式影响分析（FMEA）就是在产品设计过程中，通过对产品各组成单元潜在的各种故障模式及其对产品功能的影响进行分析，并把每一个潜在故障模式按它的严酷程度予以分类，提出可以采取的预防改进措施，以提高产品可靠性的一种设计分析方法【178】。尽管预计每一个失效模式是不现实的，但是开发组应当尽可能广泛的制定潜在故障模式列表。
通过FMEA可以达到如下目的：
Ø 能帮助设计者和决策者从各种方案中选择满足可靠性要求的最佳方案；
Ø 保证所有元器件的各种故障模式及影响都经过周密考虑；
Ø 能找出对系统故障有重大影响的元器件和故障模式，并分析其影响程度；
Ø 有助于在设计审议中对有关措施（如冗余措施）、检测设备等作出客观的评价；
Ø 能为进一步定量分析提供基础；
Ø 能为进一步更改产品设计提供资料；
Ø 在设计阶段评价来自客户或其他参与者的需求，避免引入潜在的故障；
Ø 在设计阶段跟踪和管理潜在的风险；
Ø 保证任何可能产生的失效不会伤害产品或过程的顾客；
Ø 提高客户满意度；
Ø 为测试和开发提供关注点
第92贴【2004－8－30】：故障树分析树
故障树分析（FTA）在产品设计过程中，通过对可能造成产品故障的各种因素（包括硬件、软件、环境、人为因素等）进行分析，画出逻辑框图（即故障树），从而确定产品故障原因的各种可能组合方式的一种可靠性分析技术。是用于分析大型复杂系统可靠性、安全性以及故障诊断的一个有力工具。
该方法存在两个问题：
Ø 1、不能表示实时问题；
Ø 2、不能表示系统状态或操作模式；
在使用FTA时，需要注意以下问题：
Ø 1、输入的可能性很小；
2、被动的组件；
Ø 3、对故障树进行定量分析（尽管可以对FTA进行量化，但FTA不是一个量化分析方法）；
Ø 4、把故障树代替任何别的分析方法；
Ø 5、小心使用布尔表达式；
Ø 6、独立的失效模式与非独立的失效模式对应起来；
Ø 7、确保顶部的事件具有高优先级
第93贴【2004－8－31】：事件分析树
事件树分析（ETA）可以在FTA分析之后开始，它通过分析系统中的一个初始事件，然后考虑这个事件所有可能出现的后续事件，尤其是那些可能导致事故的事件。ETA的起始点是那些扰乱正常系统操作的事件，接着它跟踪事件的传递，确定后继系统组件的失效，计算它们失效的可能性及可能的组合（与/或）。
ETA的缺点是：Ø
1、一个事件的所有可能的后继考虑起来是有困难的；
Ø2、对于一个复杂的系统，事件树将变得非常复杂，这是因为正常和不正常的所有操作都会显示在事件树中
第94贴【2004－9－1】：可靠性测试
可靠性测试是从验证的角度出发，检验系统的可靠性是否达到预期的目标，同时给出当前系统可能的可靠性增长情况。可靠性测试需要从用户角度出发，模拟用户实际使用系统的情况，设计出系统的可操作视图，在这个基础上，根据输入空间的属性及依赖关系导出测试用例，然后在仿真的环境或真实的环境下执行测试用例并记录测试的数据。对可靠性性测试来说，最关键的测试数据包括失效间隔时间，失效修复时间，失效数量，失效级别等。根据获得的测试数据，应用可靠性模型，可以得到系统的失效率及可靠性增长趋势。常用的可靠性模型可以从黑盒（占主要地位）和白盒两个角度出发。黑盒方面的可靠性模型包括了Musa基本执行模型，Jelinski-Moranda的分离富化模型，Goel-Okumoto 的NHPP模型，增强的NHPP模型以及Littlewood-Verrall的贝叶斯判定模型。在白盒方面的可靠性模型包括了Krishna-murthy 和 Mathur的基于路径的模型和 Gokhale et al.的基于状态的模型。业界流行的可靠性模型还有很多种，不同的可靠性模型其依赖的假设条件也不同，适用范围也不同，因此对于一个产品，其所适合使用的可靠性模型需要根据实际出发，尽可能选择与可靠性模型假设条件相近的模型。
第95贴【2004－9－2】：需求测试
软件测试V模型要求我们在需求阶段就开始制定系统测试的计划，开始考虑系统测试的方法。但这还不是足够的。全面的质量管理要求我们在每个阶段都要进行验证和确认的过程。因此在需求阶段我们还需要对需求本身进行测试。这个测试是必要的，因为在许多失败的项目中，7 0 %～8 5 %的返工是由于需求方面的错误所导致的。并且因为需求的缘故而导致大量的返工，造成进度延迟、缺陷的发散，这是一件及其痛苦的事情。因此我们要求在项目的源头（需求）就开始测试。这类测试更多的还只是静态手工方面的测试，当然也有一些自动化的工具，但这些工具会要求我们按照某个固定的格式进行需求的表述（例如形式化的方法），因此在适用性上会受到限制。通过静态手工方法进行需求测试中最常使用的手段是同行评审。
第95贴【2004－9－4】：通过评审来测试需求
同行评审是业界公认的最有效的排错手段之一。我们在需求测试过程当中，使用最多的也是同行评审（Peer Review），尤其是正规检视（Inspection）。正规检视是由Michael Fagan 在I B M 制定出来的一种非常严格的评审过程。
需求评审的参与者当中，必须要有用户或用户代表参与，同时还需要包括项目的管理者，系统工程师和相关开发人员、测试人员、市场人员、维护人员等。在项目开始之初就应当确定不同级别、不同类型的评审必须要有哪些人员的参与，否则，评审可能会遗漏掉某些人员的意见，导致今后不同程度的返工。
第96贴【2004－9－6】：好的需求应当具有的特点
一个良好的需求应当具有一下特点：
Ø 完整性。每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
Ø 正确性。每一项需求都必须准确地陈述其要开发的功能。
Ø 一致性。一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。
Ø 可行性。每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
Ø 无二义性。对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。
Ø 健壮性。需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
Ø 必要性。“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。
Ø 可测试性。每项需求都能通过设计测试用例或其它的验证方法来进行测试。
Ø 可修改性。每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。
Ø 可跟踪性。应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（f i n e - g r a i n e d ）的方式编写并单独标明，而不是大段大段的叙述。
另外应当对所有的需求分配优先级。如果把所有的需求都看作同样的重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度
第97贴【2004－9－8】：通过用例设计来测试需求
我们从V模型上可以知道，验收测试是以系统需求为基础的，系统测试是以功能测试为基础。每个开发阶段的活动都与相应的测试活动是并行进行的。在需求阶段进行系统（验收）测试计划和设计，除了能指导最终的系统测试和验收测试执行外，其本身也是对需求的一个验证过程。
通过阅读软件需求规格说明书，通常很难想象在特定环境下的系统行为。以功能需求为基础或者从使用实例派生出来的测试用例可以使项目参与者看清系统的行为。虽然没有在运行系统上执行测试用例，但是设计测试用例的简单动作可以解释需求的许多问题。如果你在部分需求稳定时就开始开发测试用例，那么就可以及早发现问题并以较少的费用解决这些问题。
设计概念性测试用例可以发现需求的错误、二义性、不可测性、遗漏等方面问题，为了获得最大的效果，要求测试人员能够独立的去对需求进行思维，从一个不同于开发的角度上进行分析，这可能会是一个逆向的思维过程，在这个过程中，测试人员可能会设计出不同于需求的测试用例，而这最终可能会有两个解释：
Ø1、需求不完整或者需求有错；
Ø2、遗漏了测试用例或者测试用例本身有错误；
不管是哪种解释，最终肯定会提高整个系统的质量。但这个质量的获得是通过冗余的人员来完成的，即：开发人员在对系统需求进行进一步分析的时候，有一组独立的测试人员也在对系统需求进行独立的思维，并从中获取测试用例。尽管这两种思维可能会出现重复，但由于思维的方式不同，最终肯定会使得需求变得更清晰和更完善。
第98贴【2004－9－9】：需求建模测试
需求的建模包括把需求转换成图形模型或形式化语言模型。需求的图形化分析模型包括数据流图（Data Flow Diagram，DFD）、实体关系图（Entity-Relationship Diagram，ERD）、状态转化图（State-Transition Diagram，STD）、对话图（Dialog Map）和类图（Class Diagram）。这些图形化模型一般都需要借助一定的CASE（Computer-Aided Software Engineering）工具。这样就可以借助于自动化分析工具本身提供的检测手段来对需求进行测试，而这类检测主要可以提供描述上的完整性检查，需求项之间的不一致性检查等方面的功能。同时，使用这类自动分析工具有助于获得需求的质量特性，包括：有效性、一致性、可靠性、可存活性、可用性、正确性、可维护性、可测试性、可扩展性、可交互性、可重用性、可携带性等。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
