服装行业管理软件测试基础

软件测试基础
软件系统的复杂是安全的巨大威胁。在秘奥软件系统开发中，服装行业管理软件测试已成为一项不可或缺的内容。软件测试在软件生命周期的地位和意义，软件测试的概念(定义、对象、目的、原则)，软件测试的方法和分类构成了软件测试的基础。

1.1.1软件缺陷导致的事故
1．首个Bug
故事发生在1945年9月9日，一个炎热的下午。当时的机房是一间第一次世界大战时建造的寇建筑，没有空调，所有窗户都敞开着。GraceHopper正领导着一个研究小组夜以纪日地工作，研制一台称为“MARKH”的计算机，它使用了大旦的继电器(电子机械装置，那时还没有使用晶体管)，一台不是纯粹的电子计算机。突然，MARKn死机了……
技术人员尝试了很多办法，最后定位到70号继电器出错。HopPer观察这个出错的继电器，有一只飞蛾躺在中间，已经被继电器打死。他小心地用镊子将蛾子夹出来，用透明胶布粘到“事件记录本”中，并注明“第一个发现虫子的实例。”

2．Tberac案例
Therac系列仪器是一种医用高能电子线性加速器，用来杀死病变组织泅细胞，同时使其对周围健康组织影响尽可能降低。Therac20具有独立的合乎工业标憋的硬件控制系统，配置有PDPIl计算机，但计算机控制屑辅助性质，计算机软件控制仅为在某些情况下方便操作而设置。 在实际应用中，该机器致命地超过剂量设定导致在1985年6月到1987年1月之间，发生6起已知的医疗事故，造成患者死亡或严重辐射灼伤。 经事后的调查发现，在机器的编辑阶段，数据的输入速度是该错误出现的关键因素，也就是说，对于一个熟练的操作人员，在重复同样的操作千百次之后，编辑速度越来越快，最终将使出错时的“MalfMncti。n54”信息出现，即超剂量辐射事故发生。测量这时的辐射剂量已经达到饱和的25000拉德q对人体而言，辐射剂量达到looo拉银就已经是致命的了。

由于软件错误导致系统失效，酿成重大损失的事例不胜枚举。这些惨痛教训增加了软件业界对软件质量在软件工程中的思考。设计人员和使用人员都希望在将软件系统投入运行之前，能得到系统正确性的保证，或能将系统正确性提高到比较高的程度。
软件在其生命周期的各个阶段都有可能发生问题，其情况和形式各不相同，这就是缺陷，通常称为B”g。IEEEslandard729对软件缺陷的定义是：软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，不能满足或不能全部满足用户的需求。从产品的内部看，软件缺陷是软件产品开发或者维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。

一般来说，可以参照以下规则来判别出现的问题是否是缺陷：
(1)软件是否已全部实现需求说明文档要求的功能。
(2)软件是否出现了得求说明文档指明不应该出现的错误。
(3)软件是否多实现了需求说明文档未提到的冗余功能。
(4)软件是否没实现需求说明末提及，但是应该实现的功能和目标
(5)软件是否使用不便，运行速度缓慢，难以理解，导致客户不满意。
在软件的开发阶段，有很多机会引入缺陷，并在开发的其他过程中将这些缺陷传播演变成其他缺陷．新的缺陷也有可能随着旧缺陷的修复而产生。
最有效的缺陷排查应始于项目的最初阶段，远早于程序编码。首先验证需求文档，检查需求在一致性、可测试性、可行性、明确性和可追溯性上存在的错误，往往使得缺陷预防工作在需求阶段的效率最高。其次，编程技术的不足或设计出现逻辑上的错误，比如算法错误、语法错误、计算和精度问题、接口参数传递不匹配等也会为程序带来缺陷。另外的因素包括人为的各种行为、软件本身的因素等。团队中的误解、沟通不畅将导致负责不同阶段的人员对程序涉及的含义有不同的理解。文档错误、时间上不协调或不一致、系统的自我恢复或数据的异地备份、灾难性恢复等问题，都将为后续的工作埋下隐患。

1．1．3软件缺陷分类
一般缺陷可以按照不同的标准进行分类，比如根据相应的缺陷的开发阶段来划分，根据缺陷失效产生的效果，或者以不修复导致的后果来划分。
根据软件缺陷所造成的恶劣程度来分类，每个组织对缺陷严重程度级别的定义不尽相同，具体的等级可以分为5级，如下：
1、crtical：不能执行正常功能或重要功能，或者危及人身安全；
2、major：严重的影咱系统要求或基本功能的实现，且没有办法更正(重新安装或重新启动该软件不属于更正方法);
3、Minor：严重地影响系统要求或基本功能的实现，但存在合理的更正方法(重新安装或重新启动恢软件不同于更正方法);
4、Cosnic：使操作不方便或诅到麻烦．但它不影内执行工作功能或重要功能；
5、Other：其它错误
根据软件缺陷产生的技术原因进行分类缺陷，计算缺陷．接口缺陷，数据缺陷等。

1．1．4软件缺陷生存周期
1．定义缺陷的状态
缺陷的7种状态：
(1)New：指测试人员发现项目经理确认。
(2)oPen：测试人员或测试管理人员确认为Bug后置为Open。
(3)FLxin8：开发人员看到属于自己的B。8后，置为nxin8l表明白己已经看到，正在修改B。8。
(4)Fixed；开发人员修改后置为Fixed，测试人员可以将这种状态的Bug进行回归调试。
(5)Reopen：测试人员或测试管理人员对Fixed的BuB回归测试后，发现问题仍然没有解决．将B。8置为ReoPen。
(6)ReJected：一般出现以下几种情况开发人员可以将B。8置为Rejected，但开发人员必须写明拒绝修改该的原因：哲不修改，开发人员由于某些原因暂不修改，但必须得到项目经理的批准；无法再现，有些问题无法再现，开发人员无法修改；使用诺误，开发人员认为是由于测试人员使用不当造成错误，拒绝修改；系统限制，该功能对系统有特殊要求和限制，本身并无缺陷。
(7)C10sed：Bu8已经解决，测试人员可将其置为ClosedD
上述open，nxing和nxed称为缺陷的活动态，closed和ReIe破ed称为缺陷的终结态。

2．缺陷管理流程
缺陷跟踪管理是测试工作的一个重要部分，测试的目的是为了尽早发现软件系统中的缺陷，因此，对缺陷进行跟踪管理，确保每个被发现的缺陷都能够及时得到处理是测试工作的一项重要内容。缺陷跟踪管理的目标是：确保每个被发现的缺陷都能够被解决．不一定都被修正，也可能以其他方式解决．总之，对每个被发现的Bu8的处理方式必须能够在开发组织中达到一致；收集缺陷数据并根据缺陷趋势曲线识别测试过程阶段，决定测试过程是否结束有很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式；收集缺陷数据并在其上进行数据分析，作为组织的过程财富。
缺陷管理流程如图1．3所示，具体实施必须使用开发小组制定的缺陷管理工具，该工具将记录所有缺陷的状态信息，并可以自动产生缺陷管理报告，一切测试工作都应有计划有步骤地进行，尽早进行管理，并尽可能多地发现Bu8，保证gU试工作的顺利进行。具体遵循以下流程：
(1)测试人员提交新的Bu8入库，错误状态为New。
(2)高级测试人员验证错误，如果确认是错误，分配给相应的开发人员、设置状态为open；如果不是错误，则拒绝，设置为De山ned(拒绝)状态。
(3)开发人员查询状态为oPen的B”g，如果不是错误，则置状态为DecLine山如果是B”8，则修复并置状态为nxed。不能解决的BuB，要留下文字说明及保持B“8为OPen状态。对于不能解决和延期解决的B”g，不能由开发人员自己决定，一般要经某种会议(评审会)通过才能认可。
(4)测试人员查询状态为Ftxed的B‘8，然后验证Bug是否已解决，如解决置Bu8的状态为C10sed，如没有解决置状态为Re。Pen。

1．1．5软件缺陷修复代价
软件在从计划、编制、测试．一直到交付用户公开使用的过程中，都有可能产生和发现错误。随着整个开发过程的时间推移，修复软件的费用呈几何级数增长。图1．4是软件错误在不同阶段发现时修改的费用示意图。

1．2软件测试纳发展历程
早期的软件开发过程中，软件规模小，复杂程度低，软件开发的过程混乱无序，测试的含义比较狭窄，开发人员将测试等同于调试。
1957年，软件到试开始与调试相区别，作为一种发现软件缺陷的活动。但测试活动始终后于开发活动，测试通常被作为软件生命周期中最后一项工作。当时也缺乏有效的测试方法，主要依靠“错误推测(ErrorGuessin8)”来寻找软件中的缺陷。因此，大量软件交付后，仍存在很多问题，软件产品的质量无法保证。

20世纪70年代，人们开始思考软件开发流程的问题，“软件测试”这一词条已频繁出现，一些软件测试的探索者们建议在软件生命周期的开始阶段就根据需求制订测试计划，这时涌现出一批软件测试大师。

1983年IExE提出的软件工程术语中给软件测试下的定义是，“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。这个定义明确指出：软件测试的目的是为了检验软件系统是否满足需求。它不再是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。软件测试己成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。

从20世纪80年代中后期开始，软件生产进入以个体软件过程PSP(PersonalSoftwareProcess)、过程成熟度模型CMM和群组软件过程TSP(TeamSoftwareProcess)为标志，以过程为中心的第二阶段。
1g96年，测试支持度TSM(Testi“8S”pponModel)和测试成熟度TMM(Testin8Matu—小yModel)的概念相继提出。其中TMM被分解为5个级别。
1级(初始级)：测试过程无序，甚至是混乱的，几乎没有妥善定义。测试和调试没有区别，除了支持调试外，测试没有其他目的．测试过程不可重复，且软件发布后没有质量保证。
2级(定义级)：测试被定义为软件生命周期中的一个阶段，在编码阶段之后。
3级(集成级)；测试贯穿于软件开发生命周期。不过，尽管处于该阶段的公司认识到评审在质量控制中的重要性，但并没有建立起有效的质量控制标淮，以在软件开发生命周期中的各阶段实施有效的评审。
4级(管理和度量级)：测试活动除了测试被测程序外．还包括软件生命周期中各个阶段的评审、审查和复查，使测试活动涵盖了软件验证和软件确认活动。
5级(优化级)：具有缺陷预防和质量控制的能力，优化调整和持续改进测试过程。测试过程的管理为持续改进产品质量和过程质量提供指导，并提供必要的基础设施。
软件测试与质量保证体系有机融合，测试方法越来越细化，测试技术不断更新，软件测试正以走向专业化的发展趋势，蓬勃发展。

软件测试的定义
软件测试是使用人工的或自动的手段来运行或检测某个系统的过程，其目的在于检验它是否满足约定的需求成是比较预期结果与实际结果之间的差别。随着软件业界对软件工程的不断反思和总结，人们对软件测试有了更深入的理解，重新定义了软件铡试：软件测试是在既定的状况条件下，运行一个系统或组件，观察记录结果，并对其某些方面进行评价的过程。
上述是IEEE的定义．一般也称为第一类测试。还存在一种被称为第二类测试的Myers的定义：软件测试是为了发现错误而运行程序的过程。这一定义明确指出软件测试的目的是“发现错误”。
第一类测试可简单地描述为：在设计规定的环境下运行软件，其功能及性能与用户需求或设计相比较，如果相符，则测试通过；否则，视为缺陷。这一过程的目标是将软件的所有功能在设计规定的环境下全部运行并通过*第一类测试方法以需求和设计为本，因此有利于界定测试工作的范畴，更便于部署测试的侧重点，加强针对性。这一点对于大型软件的gU试，尤其是在有限的时间和人力资源情况下显得格外重要。
第二类测试中，测试方法与需求和设计没有必然的联系，更强调测试人员发挥主观能动性，用逆向思维方式不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的骗人以及系统各种弱点，试图破坏系统、摧毁系统，目标就是发现系统中各种各样的问题。这种方法往往能发现系统中存在的更多缺陷。
广义的软件测试是由确认、验证、测试3个方面组成的。
(1)确认(valNation)：评估将要开发的软件产品是否正确无误、可行和有价值。确认意味着确保—个待开发软件是正确无误的，是对软件开发构想的检测，确保产品实现的功能满足了用户所有的需求。
(2)验证(verMc颠ion)：检测软件开发的每个阶段、每个步骤的结果是否正确无误，是否与软件开发各阶段的要求或期望的结果相一致。验证意味着确保软件会正确无误地与规格说明书保持一致性，开发过程是沿着正确的方向进行的。
(3)测试：与狭义的测试概念统一。

1.3．3软件测试的对象
软件测试并不等于程序测试，软件测试应该贯穿整个软件定义与开发期间。因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应该是软件测试的对象，如图1．5所示。
图1．5中，在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中，任何…个环节发生了问题都可能在软件测试中表现出来。
C1enfordJ.Mayers在其经典著作《TheAnofSoftwareTesttng》中，提出了软件测试的十太原则，如下：

1、测试用例中一个必需部分是对预期输出或结果进行定义；
2、程序员应当避免测试自C编写的程序；
3、编写软件的组织不应肖测试自d编写的软件；
4、应当彻底检查每个测试的执行结果；
5、测试用例的编写不仅应当根据有效和遇到的的入情况．而旦也应当根据无效或者未遇到的输入情况；
6、检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”；
7、应该避免测试用例用后即弃，除非软件本身就是一个一次性的软件；
8、计划测试工作时不应默许假定不会发牛错误；
9、程序策部分存在更多错误的可能性，与该部分己发生错误的数量成正比；
10、软件测试是一项极富创造性、权且智力挑战的工作。

下面就其中的几条进行阐述。
测试用例应由测试输入数据和与之对应的预朗输出结果这两部分组成。测试以前应当根据测试的要求选择在测试过程中使用的测试用例(丁e欢case)。测试用例主要用来检验程序员编制的程序，因此不但需要测试的输人数据，而且需要针对这些输入数据的预期输出结果。如果对测试输人数据没有给出预期的程序输出结果，那么就缺少了检验实测结果的基准，就有可能把一个似是而非的错误结果当成正确结果。
程序员应避免检玄自己的程序．编写软件的组织也不应当测试自己编写的软件，与此同时，计划测试工作时不应默许假定不会发生错误。测试工作需要严格的作风、客观的态度和冷静的情绪。人们常由于各种原因具有一种不愿否定自己工作的心理，认为揭露自己程序中的问题总不是一件愉快的事。这一心理状态就成为测试自己程序的障碍。另外．程序员对软件规格说明理解错误而引入的错误则更难发现。如果由别人来测试程序员编写的程序，可能会更客观、更有效，并更容易取得成功。要注意的是，这点不能与程序的调试(debuging)相混淆。
调试内程序员自己来做可能更合效。
应当彻底检查每个测试的执行结果。这是一条最明显的原则．但常常被忽视。有些错误的征兆在输出实测结果时已经明显地出现了，但是如果不仔细、全面地检查测试结果，就会使这些错误被遗漏掉。所以必须对预期的输出结果明确定义，对实测的结果仔细分析检查，抓住征候，暴露错误。
测试用例的编与不仅应当根据有效和遇到的输人情况，而且也应当根据无效或者未遇到的输入情况。合理的输入条件是指能验证程序正确的输入条件，而不合理的输入条件是指异常的、临界的、可能引起问题异变的输入条件。在测试程序时．人们常常倾向于过多地考虑合法的和期望的输入条件，以检查程序是否做了它应该做的事情，而忽视了不合法的和预想不到的输入条件。事实上，软件在投入运行以后，用户的使用往往不遵循事先的约定，使用了一些意外的输入，如用户在模盘上按锗了键或打入门F法的命令。如果开发的软件遇到这种情况时术能做出适当的反应‘给出相应的信息，那么就容易产生故障，轻则给出错误的结果，重则导致软件失效。因此，软件系统处理非法命令的能力也必须在测试时受到检验。用不合理的输入条件测试程序时，往往比用合理的输入条件进行测试能发现更多的错误。
检查程序是西“未做其应该做的”仅是测试的一半，测试的另—半是检查程序是否“做了其不应该做的”。在项目启动时会定义需求规格说明，坚持对需求的验证，使得程序是可预测的。一方面。验证程序的正确性，根据用户的需要来进行检验，同时也应遵从某个标推进行检验；另-方面．验证程序对需求实现的完整性，用于保证需求中没有遗漏任何的功能需求．避免由于没有人提出恰当的问题或者没有人检查相关的原始文档而引起的需求遗漏；另外，还需考虑每个功能件需求附带以F功能性要求，包括性能、安全性、pJ使用性、兼容性和pJ访问性。
应该避免测试用例用后即弃，除非软件本身就是一个一次性的软件。妥善保存测试计划、测试用例、出错统汁和最终分析报告，为维护提供方便。
程序某部分存在更多错误的可能性，与该部分已发生错误的数量成正比。经验表明v测试后程序中残存的错误数的与该程序中已发现的错误数目或检错率成正比，这也被称为群集现象。根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。在所测程序段中，若发现错误数日多，则残存错误数目也比较多。这种错误群集性现象，已为许多程序的测试实践所证实。

根据中国软件评测中心的测试理念，提出的测试原则就是要从用户和开发者的角度出发，进行软件产品的测试，通过测试，为用户提供高质量的产品，并对优秀产品进行认证。其测试原则有以下8点：
(1)应当尽早和不断地进行软件测试。
(2)程序员应当避免检查自己的程序，测试工作应该交由独立的专业的软件测试机构来完成。
(3)设计测试用例时应该同时考虑合法和不合法的输入以及各种边界条件，特殊情况下可以制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
(4)一定要注意测试中B。g集少发生的现象，这和程序员的编程水平和刁惯有很大的关系。
(5)对测试错误站果一定要有一个确认的过程．一般由A测试出来的错误,一定要由B来确认，严重的错误可以召开评审会进行讨沦和分析。
(6)制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
(7)问归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的带误出现的情况并44少。
(8)妥善保存一切测试过程文档，意义是石言而喻的。
具体来讲．软件测试过程是‘个小断输人数据，观察和记录软件运行行为和输出结果．并判断其行为和输出结果的正确性，直到能够由这些结果有效地分析该软件的性能的过程。抽象地讲，软件测试就是不断进行测试、排错、修改，然后再进行测试(回归测试)、排锗、修改、直到软件达到用户性能要求的一个循环往复过程。

在应用程序开发生命周期的开始阶段，就应该外始测试过程．而不是传统的在编码结束时才开始测试。测试需要与应用程序开发阶段结合起来。一般来说，广州秘奥软件科技有限公司中， 服装行业管理软件测试过程如下：
1．需求分析
在软件开发生命周期的需求阶段，业务需求的定义是比较高级的，并且也是后续阶段及最终实现的基础。因此，在需求阶段对需求近行验证．可以尽早地发现错误。针对密求规格说明文档及其他相关的文档．主要验证需求是否明确无歧义．是否一致，是否易十追溯其来源即可追踪性等。
2．单元测试
单元测试是测试的基本阶段，也是在软件开发过程个要进行的最低级别的测试活动。在这个过程中，软件的独立单元将在与程序的其他部分隔离的情况下进行测试，针对的是单个的函数模块，偌要依据详细设汁说明书和源程序清单，了解该模块的输入／输出和逻辑结构．主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例使之对任何合理的输入和不合理的输入，都能鉴别响应。
3．集成测试
集成测试是在单元测试的基础上。把程序的基本单元按照软件结构设计的要求，组装成软件系统进行测试。文践表明．一些模块能够单独地工作．并不能保证连接起来也能正常工作，所以此阶段的测试非常重要。一般采用照盒测试方法，白盒测试万法作为补充，主要对模块功能、模块间接口等进行测试。一般钉自底向上和自顶向F两种测试策略。
4．确认测试
集成测试完成以后，分散开发的模块被连接起来，构成完整的程序c存在的种种问题都己消除。于是测试工作进入下一阶段——确认测以c
能否按合同要求进行丁作，即是否满足软件需求说明书中的确认标淮。
5．系统测试
其中各模块之间接u
确认测试应检查软件
软件开发完成以后．最终还要与系统中的其他部分配套运行G系统测试实际上是饲对系统中各个组成部分进行的综合性检验。尽管每—个检验有着特定的目标．然而所有的检测丁作都要验证系统中每个部分均己得到正确的集成，并能完成指定的功能。依据需求文档进行各项测试．包括功能测试、可靠件测试、性能测试、强度测试等．这些测试项都应在测试计划小商所计划。
6．验收测试
最后，要进行验收测试。验收测试是以用户为土的测试．用厂参均设汁测试用例，使用用户界面输入测试数据，并分析测试的输出结果。一般使用实际的操作数据进行测试、在测试过程中，除了测试软件基本的功能和性能外，还应该对软件的兼容性、可维护性等进行确认。验收测试实际上是对整个测试计划的一个审查。

1．5．2软件测试过程模型
随着测试技术的发展，测试过程的管理显得尤为重要．过程管理已成为测试成功的重要保让。经过多年的努力，测试专家提出厂许多实用的测试模型，其中包括v模型、w模型、H模利、X模刷等。
1．v测试过程模型
v模型枝干内PaMlRook在20世纪80年代盾期提出，旨在改进软件开发的效率。v模型的价值在于它非常明确地提出了测试过秤中存在的不同级别，并民清楚地描述厂这些测试阶段和开发过程期间各阶段的一一对应关系。软件测试过程Y模型如图1．7所示。
公v模型中．单元测试是基于软件源代码的测试，最初时一般出开发人员执行．以验证其可执行程序代码的各个部分是否己达到了文档预期需要的功能要求；而集成测试则验证不同单几之间的集成是否止确．并有针对性地对详细设计中所定义的各单元模块之间的接口进行检金；在所有单元测试和集成测试完成后，系统测试开始以客户环境来模拟系统的运行，以验证系统是否已达到了在概要设计中所定义的功能和性能；最后，当技术部门完成了所有测试工作后，由业务专家或用户进行验收测试，以确保产品能符合用户业务上的需要。
虽然v模型已存在／很长时间，且被广泛应用，但是它也存在一些局限性。比如．它没合明确地说明早期的测试，无法体现“尽早地和不断地进行软件测试”的原则。另外．它忽略了实际测试过程小的一个事实，那就是软件在交接中完成，每次交接都会改变上次交接的行为。还 材v模利过十依赖文档的存在性、推确性、完整性和文时性。

2．w洲试过程模型
W模型内[vo[11if公司提出，相对十v模型，w模型更为符合软件工程的过程。w模型是v模型的发展．强调的是测试过程伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发需要同步进行，从而有利于尽早地发现程序中的问题。w模型如图1．8所示。
w模型是由两个v字形模则组成的，分别代表测试和开发过程，可以看出w模型绝不是简单对v模型的改进，而是反映)，一种新的测试观念．即测试应该伴随着整个开发周期，测试的对象不仅仅是程序，对需求、规格和设计同样需要测试．以利十尽早地发现和解决错误，降低软件升发风险和代价。但是，同样地、w模型也存在局限性，它无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，w模型并个能解决测试管理面临的难题。

3．H测试过程模型
H模型的提出．有效地解决了各层次(单元测试、集成测试、系统测试等)之间反复触发和迭代的问题。H模型如图1．9所示。
图1．9演示f在整个生产周期中某个层次上的一次测试“微循环”。图巾标注的其他流程可以是任意的开发流程．例如设计流程或者编码流程。H模型将软件测试过程活动完全独立出来，使之贯穿于整个产品的周期，与其他流程并发地进行，一旦某个测试点准备就绪，便从测试堆备阶段进行到测试执行阶段，从而达到让软件测试尽早进行的日的。

4．x测试过程模型
x模型是为了解决V模型的种种问题，由只obinF．(joNSmith在BrianMarick提出的替代模型基础上产生的，他认为v模型和w模型最大的问题体现在以下几个方面：
(1)忽略了这样的事实．即软件开发是由一系列的交接所组成的．每一次交接内容都改变／前一次交接的行为。
(2)依赖于开发文档的存在，及文档的精确性、完整性，并且没苟对时间进行限制。
(3)认为一种测试的设计是依据某一个单独的文档，而不包括根据其前后阶段的文档的倍改而作相应修改。
(4)认定这些依赖十某个单独文档的测试一定要在一起。
X模型如图1．10所示。
x模型的左边描述的是针对单独程序片段所进行的相互分离的编码初测试，右上半部分显示此后将进行频繁的交接．通过集成最终合成为可执行的程序。这些可执行程序还需要进行测试。已通过集成测试的产品可以进行确认并提交给用户．也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。X模型还定位了探索性测试。
这是不进行事先计划的特殊类型的测试，诸如“我这么测试一下结果会怎么样?”这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
总的来说，x模型和H模型有很多相同之处，它们都是为了解决v模型中理想化的一些东西，比如开发阶段有严格的界限、忽视了需求变化往往导致开发过程变化的情况，认为测试可以依据已经写好的精确的文档来进行，没有明确测试执行前应该进行的测试设计等准备阶段等。

1．6．1最普遍的测试策略
1．黑盒测试
黑盒测试被称为功能测试或数据驱动测试。在测试时，把被测程序视为一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下进行。采用黑盒测试的目的如下：
(1)检查程序功能能否按需求规格说明书的规定正常使用．测试各个功能是否有遗漏，检测性能等特性要求是否满足。
(2)检测人机交互是否错误，检测数据结构或外部数据库访问是否错误，程序是否能适当地接收输入数据而产生正确的输出结果，并保持外部信息(如数据库或文件)的完整性。
(3)检测程序初始化和终止方面的错误。
常用的方法包括等价类划分、边界值分析、因果团法、决策表法、错误推测法等。

2．白盒测试
白盒测试又称为结构测试、逻辑驱动测试或基于程序的测试(Frogram—basedTesting)。采用这一测试方法．测试者可以看到被测的源程序，它可用于分析程序的内部构造，并且根据
其内部构造设计测试用例。这时测试者可以完全不顾程序的功能，通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序．检验程序中的每条路径是否都能按预定要求止确运行。具体的白盒测试方法有程序控制流分析、数据流分析、逻辑覆盖、域测试、符号测试、路径分析、程序插桩以及程序变异等。其中多数方法比较成熟，也有较局的使用价值。个别的方法仍有些问题没有得到圆满的解决。例如，路径测试的分析方法是很重要的，仅在程序分支过多及程序路径过多时，已有的方法将会显示出它们的局限性。

3．灰盒测试
灰盒测试．介于白盒测试与黑盒测试之间、可以这样理解，灰盒测试关注输出对十输人的正确性．同时也关注内部表现．但这种关注不如白盒测试那样详细、完整，只是通过…‘些农征性的现象、事件、标志来判断内部的运行状态．有时候输出是正确的．但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低．因此需要采取这样的一种灰盒测试的方法。
如表1—5所示，灰盒测试结合了白盒测试和黑盒测试的要京．它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。灰盒测试内方法和工具组成，这些方法和工具取材于应用程序的内部知识和与之交互的环境v能够用十黑盒测试以增强测试、发现错误和分析错误的效率。
1．基于模型的测试
软件模型是对软件行为和软件结构的抽象描述。软件行为可以用系统输人序列、活动、条件、输出逻辑或者数据流进行描述．软件结构则使用组件图、部署图等进行描述。针对测试任务，通过对软件功能和结构进行抽象并用易于理解的方式进行描述，获得的模型就是对被测试软件系统精确的描述，可以用于软件测试．如图1．11所示。…般对软件不同行为要用不同模型进行描述。
基于模型的软件测试技术可以根据测试模型对被测试程序中所有输入及其状态组合进行系统枚举．因此可以使测试实现系统化、集中化以从自动化。基于模型的软件测试技术属于基于规范的软件测试范畴，其特点是：在产生测试用例和进行测试结果评价时．都是根据被测试应用程序的模型及其派小模型进行的。日前，经典的测试模型包括有限状态机模型、uML模型、马尔可夫链模型等。常见的基于模型的测试工具有specE”P10rer，如图1．12所示。

2．面向对象的测试
面向对象系统与面向过程系统有着许多类似之处，虽然传统测试的理论与方法有不少可用于面向对象的测试中，但毕竟面向对象的开发技术和运行方式与传统的软件有着较大的区别．因此，必须针对面向对象程序的特点开发出新的测试方法。
传统程序执行的路径是在程序开发时定义好的，程序执行的过程是主动的，其流程可以用一个控制流图从头至用地表示；而面向对象程序中方法的执行通常不是主动的．程序的执行路径也是运行过程中动态地确定的，因此描述它的行为往往需要动态的模型。与传统的程序相比较，面向对象程序主要具有封装性、继承性、多态性和动态绑定等几大特性。一般来说，面向对象软件的测试类似于传统软件的测试．但又有所不同，可分为4个层次—一方法测试、类测试、类簇测试和系统测试。

3．web测试
Web应用程序拥有许多传统软件没有的特点。wcb应用程序通常都是由种类繁多的实体组成的，这些实体大部分是使用多语义的标记符或脚伞编写而成的，例如．HTMI‘．Javn—scriPtveol脚本，AsP和Jsl3等。它们人多是没有结构化且难以被抽象，这使得web应用程序变得很难“读懂”扇外，weL应用程序可以被用户以不同类型的客户端浏览器同时访问，且这些客户端可以使用不同类型的操作系统；web应用程序还可以根据用户的交互动态生成不同的web页面，而请求／响应时所使用的HTTP协议所呈现出的新型控制和数据流结构在传统软件中也是没有的。wcb应用程序是在传统c／5模式的应用程序基础之上发展起来的，其与传统c／s模式的应用程序的比较见下表。

4．敏捷测试
敏捷方法是20世纪90年代末，为厂应对传统制造业的“敏捷制造”思想，逐渐形成的新的软件开发模式。敏捷方法通常应用时间定量的迭代和进化式开发．使用自适应计划．提倡增量交付并包含其他提倡敏捷性(快速和灵活的响应变更)的价值和实践，为解决以上问题提供了轻量级的项目管理和开发、维护的思路。
目前比较流行的敏捷测试方法有驱动开发测试和相关环境驱动测试等。

5．模糊测试
模糊测试是‘种通过向日标系统提供非预期的输入并监视异常结果来发现软件漏洞的方法。模糊测试过程中。随机产生人员数据对程序进行驶证，假如么应对这类数据—L：失效．开始出现冲突、死锁、消耗大量内存或者产生不可控制，开发者就知道代码的某处出现了Bug。其中，用于测试的数据包括有效数据和随机数据的联合。
模糊测试的最大优点在于它的成本效率v该项测试通常是自动化的．而且容易配置。模糊测试也是一顶用于验证程序中真文错误的重要丁具．也是所有意识到安全性问题且致力于程序健壮性的程序员们的工具箱中所必备的工具。

服装行业管理软件测试相关术语
Ac。ey?ance?es?inx(验收测试)：它包括A1phM测试和Be内测试，系统开发生命周期方法论的一个阶段。由相关的用户和／或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收该系统。它足一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。
AdhocteMi。g(随机测试)：它主要是根据测试者的经验对软件进行功能和性能抽查．是没合书面测试用例、记录期望结果、检否列表、脚本或指令的测试。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。
A1phatestl。g(A1Pha测试)：既pJ以是一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试。A1ph3测试不能由程序员或测试员完成。
H瓤引esting(13c蛆测试)：软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场、Hcta测试不能内程序员或测试员完成。
八utomatedteMlng(自动化测试)：使用自动化测试工具来进行测试，这类测试一般不需要人厂预，通常在cuI、性能等测试中用得较多。
B1ackboxteMi“g(黑盒测试)：指测试人员不关心程序具体如何实现的一种测试方法。
据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。
wht舵boxqeMing(白盒测试)：根据软件内部的工作原理分析来进行测试．是基于代码的测试*测试人员通过问读程序代码或者通过使用开发工具中的单步调试来判断软件的质量。
白盒测试一般由项目经理在程序开发中进行。
B‘8(错误)：有时称作defctd(缺陷)或crrof(错误)．软件程序中存在的编程错误，可能会带来不必要的副作用，如软件的功能和特性与设计规格说明书或用户需求小一致。软件缺陷表现特征为：软件未达到产品说明书标明的功能；软件出现产品说明书指明个会出现的错误；软件功能超出产品说明书指定的范围；未达到虽然产品说明书未指出但是软件应达到的目标；
软件测试人员或用户认为软件难以理解、不易使用、运行速度缓慢等问题。
B‘8”叩oM(错误报告)：也称为“Bugr?coN＜错误记录)”，记录发现的软件错误信息的文档，通常包括错误描述、复现步骤、抓取的错误图像和注释等。
DefG矾trackin8RystGm(缺陷跟踪系统．DTS)：也称为“B”8trackin85y5tem．BTS”，管理软件测试缺陷的专用数据库系统，可以高效率地完成软件缺陷的报告、验证、修改、查询、统汁、存储等任务，尤其适用于大型多语言软件的测试管理。
Build(工作版本)：软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本，也pJ以是展示要在最终产品中提供的部分功能的部分系统。
CompRtzbilityteuinx(兼容性测试)：也称“Confl8urati。ntesti“g(配量测试)”、测试软件是否和系统的其他与之交互的元素之间兼容．如刷览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。
capture／ReIIIayTo01(捕获／回放工具)：一种测试工具．能够捕获在测试过程中传递给软件的输入，并且能够在以后的时间中，重复这个执行的过程。这类工具一般在GuI测试巾用得较多。
〔：rash(崩溃)：计算机系统或组件突然并完全地丧失功能，例如软件或系统突然退出或没有任何反应(死机)。
Deb”g(调试)：开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时，或者根据测试错误报告指出错误以后，开发人员需要执行调试过程来解决已存在的错误。
Del、1。yment(部署)：也称为Sh5pment(发布)，对内部IT系统而言过彻底的测试、形成产品、交付给客户的阶段。
Dynamictesti，8(动态测试)：通过执行软件的手段来测试软件。
Exceptlon(异常例外)广个引起正常程序执行挂起的事件。
FuncUon9lte4i“g(功能测试)：也称为Blhavioral比姚ing(行为测试)，根据产品特征、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对日标用户能正确工作。使用适当的平台、浏览器和
测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。
Gsrbagecharac?ers(乱码字符)：程序界面中显尔的无意义的字符，例如，程序对双字节字符集的字符不支持时，这些字符不能正确显示。
GBl8030testi“g(〔；B18030测试)；软件支持GBl8030字符集标推能力的测试，包括UB18030字符的输入、输出、显示、存储的支持程度。
Installin8testi“8(安装测试)：确保该软件在正常情况和异常情况的个同条件下都能安装，例如，进行首次安装、升级、完整的或白定义的安装都能实现。异常情况包括磁盘宁间不足、缺少目录创建权限等。核实软件在安装后可立即止常远行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装的说明，安装代码提供安装一些程序能够运行的基础数据。
Integrationte挑ing(集成测试)：被测试系统的所有组件都集成在一起，找出被测试系统组件之间关系和接口中的错误。该测试‘般在单元测试之后进行。
Intern水i。naltesn“g(国际化测试)；白的是测试软件的国际化支持能力，发现软件的同际化的潜在问题．保证软件在世界不同区域中都能止常运行。冈际化测试使用每种可能的国际输入类型，针对任何区域件或区域设置检查产品的功能是否正常。软件国际化测试的重点在
于执行园际字符串的输入／输出功能。冈际化测试数据必须包含东亚语言、德语、复杂脚本宁符和英语(pJ选)的混合字符。
I‘。cali2abil心testi“g(本地化能力测试)：伞地化能人是指不需要重新设计或修改代码，将程序的用户界面翻译成任何目标语言的能力。为丁降低本地化能力测试的成本．提高测试效率，本地化能力测试通常在软件的伪本地化版本上进ff。本地化能力测试中发现的典型错误
包括：字符的硬编码(即软件中需要本地化的宁符写在了代码内部)，对需要本地化的字符长度设置厂固定值，在软件运f?时以控件位置定位，图标和位图巾包含了需要本地化的文本，软件的用户界回与文档术语不一致等。
I。ood次4小8(负载测试)：通过测试系统在资源趟负荷情况下的友现，以发现设计上的错误或验让系统的负载能力。公这种测试巾，将使测试对象承搁小同的工作员，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的日标是确定并确保系统在超出最大预期工作量的情况F仍能正常运行。此外，负载测试还妥评估性能持征，例如，响应时间、事务处理速率和其他与时间相关的方向。
I。ocali2ationtcsh。g(本地化测试)；本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试、安装／卸载测试、当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的话言质量，包含软件、文档和联机帮助等部分。
Performancetesti。g(性能测试)：评价一个产品或组件与性能需求是否符合的测试。包拍负载测试、强度测试、数据作客员测试、基准测试等类型。
躺10ttesti“8(引导测试)：软件开发午，验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中，引导测试通常是客户检查软件测试公司测试能力的一种形式，只有通过了存户特定购引导测试，软件测试公司才能接受客户奥实软件项目的软件测试。
PonaNl心testi“g(可移植性测试＞：该项测试目的在于证明软件可以被移植到指定的硬件或软件平台上。
Prio％ty(优先级)：从商业角度出发是指错误的重要性，尤其是从客户和用户的角度出发，是指错误对于系统的可行什和可接受件的影响。与“severity(严重性)”相对照。
QMal心assurance(质量保证，QA)：采取所打子段以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。
只egressiontest小g(回归测试)：在错误修改之后，重复光前的测试以保证修改的正确性。理论上，对软件的仟何新版本，都需要进行回归测试，验证以前发现和修复的错误不会在新软件版本上冉现。
R。view(评审)：在产品开发过程中．把产品提交给项目成员、用户、管理者或其他相关人员评价成批准的过程。
sanity灾瓤i“g(健全测试)：软件主要功能成分的简单测试以保证它能进行基本的测试。参考“Smoketeui“g(冒烟测试)”。
screenshot(抓屏、截图)：软件测试中，将软件界面中的错误(窗口、菜单、对话框等)的全部或一部分．使用专用工具存储成图像文件．以便于后续处理。
5?ve列y(严重性)：错误对被测系统的影响程度，在终端用户条件下发生的可能性，软件错误妨碍系统使用的程度。与“Prior心(优先级)“相对照。
smoketeMing(冒烟测试)：冒烟测试的对象是每一个新编译的碍要正式测试的软件版本，目的是确认软件基本功能正常、可以进行后续的正式测试工作。旨烟测试的执行考是版本编译人员。参考“sanllytcsting(健全测试)”。
softwarewecycle(软件生命周期)：开始于——个软件产品的构思，结束于该产品不再被使用的这段期间。
st劝tc比挑ing(静态测试)：不通过执行来测试一个系统，如代码检查、文档检查和评审等。
StrMctMredqM。ry[a“gu“ge(结构化杏询语言vsQL)：在一个关系数据库中查询相处理数据的一种语言。
Tobed曰crmined(待定，T耶)：在测试文档中表示一项进行中的尚未最终确定的工作。
Te瓤case(测试用例)：为特定目标而开发的一组测试输入、执行条件和预期结果．其目标可以是测试某个程序路径或核实是否满足某个特定的需求。
Tc5hngcoverage(测试覆盖)：指测试系统覆盖被测试系统的程度，一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。
Testi“8environment(测试环境)：进行测试的环境，包括测试平台、测试基础设施、测试实验室和其他设施。
Testingitem(测试项)：作为四0试对象的工作版本。
丁estingplan(测试计划)：描述了要进行的测试活动的范围、方法确定测试项、被测特性、测试仟务、谁执行任务和各种可能的风险。
Testi。gProccdMre(测试过程)：指设置、执行给定测试用例并对测试结果进行评估的一系
列详细步骤。
Testi“gscriPt(测试脚本)：一般指的是一个特定测试的一系列指令，这些指令可以被自动化测试工具执行。
TestinxsMite(测试包)：—组测试用例的执行框架。一种组织测试用例的方法。在测试包里，测试用例可以组合起来创造出独特的测试条件。
u川teMing(单元测试)：指、S代码的基本测试，其实际大小足未定的．说常是一个函数或子程序，一般由开发者执行“
user加crf5ce(用户界丽，uI)：广义是指使用户可以和计算机进行交互的硬件或软件，狭义是指软件中的可见外观及其底层勺用户交互的部分(菜单、对话框、窗口和其他控件)。软件部分包括用户与计算机信息交换的协议、操作命令等处理软件，硬件部分包括输入装置和输出装置。日前常用的是图形用户界面，它采用多窗口系统，显示直接形象．操作简便，也叫人机界面，简称界面。
UsermterfncGtcding(用户界两测试)：指测试用户界面的风格是否满足客户要求，文字是否正确v贝面是否美观．文字、图片组合是否完美．操作是台友好．等等。测试的日标是确保用户界面为用户提供相应的访问或浏览功能，确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

文章来源：秘奥软件网，中小企业信息化领跑者！全国咨询热线：400-9908-527_www.misall.com