服装行业软件测试准则

服装行业软件开发的日益复杂和人们对软件可靠性需求的增加，需要对不同的软件做出充分并有效的测试来检验项目的完成度和可靠性。这时测试人员就需要一些合适的建议和有效的测试方法来保证服装行业软件测试的有效性和可靠性。本章从以下7个方面进行介绍：
(1)需求阶段。描述了测试工作在需求阶段需要考虑的问题。在需求阶段，包括测试组代表在内的所有相关人员必须参与需求工作，并且必须收到需求变更通知，这是非常重要的。
(2)测试计划。描述了测试规划活动，其中包括对测试工作目标的了解方法，确定测试策略的方法，以及有关数据、环境和软件本身需要考虑的问题。
(3)测试组成员。主要讨论测试组的人员构成。
(4)系统架构。讨论有关测试系统架构方面的考虑。
(5)测试设计和测试文档。详细描述了如何有效地设计和开发测试过程，其中包括在测试创建和文档化方面需要考虑的问题，还讨论了最有效的测试技术。
(6)与具体测试有关的方面。包括单元测试、自动化测试和非功能性测试方面的注意事项。
(7)管理测试执行。提供了测试执行的管理策略，其中包括追踪测试过程执行和缺陷生命周期的正确方法以及收集用于估计测试进程的度量。

1．1需求阶段
最有效的测试工作开始于项目的开始阶段，远远早于程序代码的编写阶段。首先需要检验的是需求文档，只有如此，在项目的后续阶段测试工作才能专注于保证应用程序代码的质量。在项目生命周期的早期——详细设计和编码工作之前，消除需求工作中的缺陷能够使昂贵的返工工作代价降到最低。
实践证明，在项目生命周期中发现缺陷越早，修正缺陷的代价就越小。表4—1列出了在项目生命周期的不同阶段，修正发现缺陷所需付出的代价。
在需求阶段作为测试人员应该注意下面几点：
1．测试人员应该及早介入
测试人员需要从项目生命周期之初就开始介入，这样才能准确地理解测试的对象并且和其他相关人员一起生成可测试的需求。
测试人员需要彻底地了解产品，只有这样才能设计出更出色和更全面的测试计划、测试设计、测试过程和测试用例。测试组及早介入。就可以了解到应用程序的哪些方面对最终用户来说最关键以及哪些元素的风险最大。这样测试组就可以首先把精力集中在应用程序中最主要的部分．避免对不经常使用的部分过度测试而对重要的部分又测试不充分。
缺陷预防是指在各种错误遗留到后续开发阶段之前，运用各种技术和过程来发现和避免这些错误。缺陷预防在需求阶段的效率最高．此时修正缺陷所需的改动很小：需要改动的仅仅是需求文档，可能还需要相应地修改此阶段制定的测试计划。
对于一条需求，如果可以设计出一个过程来执行所测试的功能，若输出结果是可以预先知道的，并且能够通过编程或者人工方式加以验证，那么就称这条需求是可测试的。
2．应该对需求进行验证
在确定系统需求的工作中，ChristopherAlexander认为应该为每条需求建立一个质量测度标准。为每条需求定义质量测度标准有助于使模糊的需求明确化。
负责验证需求的人员应该从以下几个属性来验证：
(1)正确性：根据用户的需求来进行检验。
(2)完整性：用于保证需求中没有遗漏任何必需的元素。
(3)一致性：验证的是工作产品的内部元素之间或者工作产品之间内部或者外部的矛盾。
(4)可测试性或可验证性：保证了测试一条需求的可能性，同时测试的结果是预先知道的并且能够通过编程或者人工来加以验证。
(5)可行性：保证了需求可以在给定的预算、进度表、技术和其他可用资源的情况下实现。
(6)必要性：验证规格说明书中的每条需求是否都与系统有关。
(7)优先级：让有关人员了解每条需求在需求涉众中的价值。
(8)明确性：保证需求的陈述使用了精确的和可测量的方法。
(9)可追溯性：保证每条需求可以通过寻找到所有引用它的系统部分来确定。
3．需求就绪后立即设计测试过程
和软件工程师根据需求撰写设计文档一样。测试组也需要根据需求来设计测试过程。
为了让测试过程的设计工作有助于需求分析活动，它应该安排在项目过程中更靠近需求阶段的位置。在设计测试过程的过程中．因为测试人员会用测试数据集合作为输入非常仔细地检查系统的每个交互操作，所以会发现需求文档中的某些忽略、遗漏、错误的流程和其他错误。通过这个过程会使需求适应各种变化的场景，也会把在各种情况下的需求描述成一条由交互操作组成的清晰路径。
通过测试过程的定义来确定一条需求中的错误和遗漏的过程就是验证需求的可测试性。如果需求规格说明书中没有足够的信息，或提供的信息过于含糊不清，不能用相关的测试用例为有关的路径创建完整的测试过程，那么就不能认为需求规格说明书是可测试的，可能也是不适合软件开发的。确认是否能够为一条需求设计出测试方案，这种检查总是有价值的，并且认为是检查一个需求是否完备的确认过程的一部分。如果一条需求不能验证，那么它的实现正确性就得不到保证。
为了有效地管理这些不断完善的需求和测试过程，需要定义一个完善的过程，在这个过程中测试设计人员必须参与需求过程。
4．确保需求变化的传达
测试过程已经根据需求定义好后，在需求发生变更时把这种变化通知到测试组成员是非常重要的。
在很多情况下，负责设计测试过程和执行测试过程的测试人员并没有收到需求变化的通知，这种情况会导致错误的缺陷报告，并且失去了必需的研究机会和宝贵的时间。
通常导致这种情况发生的原因有：
(1)变更没有形成文档。
(2)过期的需求文档。
(3)软件缺陷。
如果在一个项目组里希望可以避免这种情况的发生，可以通过设置一个需求变更规程来实现，这个规程有助于把需求的所有变化及时地传达给所有成员。变更规程会概括地记录变更发生的时间、变更的内容、谁做的变更和在哪些地方发生了变更。变更规程可以明确地规定变更请求可以在整个生命周期的任何阶段发起，这些阶段不仅包括需求分析过程中各种类型的评审、走查和检查阶段，而且包括设计、编码、错误跟踪或者测试活动，以及其他的任何阶段。

1．2测试计划的编制
测试纲要成功的基础是有效的测试计划。为了建立和准备测试环境，同时也是为了给安装将要测试的系统、测试工具、数据库和其他组件预留时间，计划的编制工作必须及早考虑。
要编写出合适并行之有效的测试计划，需要注意以下几点：
1．了解手头的任务舜口相关的测试目标
一般来说，测试工作就是用来验证软件是否满足某种特定的标准和最终用户的需求。有效的测试增加了被测的软件在任何环境下正确运行并满足预订的需求的可能性，最终的目的是使应用程序的最终用户满意。虽然测试本身并不能产生高质量的产品，但测试可以看做是软件质量保证的最后一关。
不同的测试工作有不同的测试目标，不同的测试阶段也有不同的测试目标。
编制测试计划的第一步就是了解手头的任务、它的范围和与之相关的测试目标。编制测试计划必须对实现测试目标过程中起作用的每个细节都有清楚的了解。
对于测试目标的了解可以通过以下的途径完成：
(1)理解系统：测试组必须从整个系统的高度来了解正在测试的系统必须满足的功能性需求和非功能性需求。
(2)及早介入：为了深入了解手头的任务，测试组成员应该在系统的开始阶段介入。
(3)理解企业文化和过程：为了适应开发过程或提出对于过程的改进意见，必须了解企业文化和企业软件开发过程。
(4)实现范围：为了确定相应的测试范围，测试组还必须了解实现的范围。
(5)测试期望：管理层对测试的期望是什么，客户期望的测试类型是什么，在测试计划中应该给出明确的回答。
(6)汲取经验：从之前的测试工作中汲取经验是非常重要的。
(7)工作量大小：该系统开发需要的工作量范围和开发人员的数目。
(8)解决方案的类型：确认最终实现的解决方案类型有助于测试计划的制定者了解需要怎样的测试类型。
(9)技术选择：确认系统实现的技术选择有助于确定测试策略和选择测试工具。
(10)预算：给定的预算水平有助于确定可能的测试类型。
(11)时间表：为系统开发和测试分配的时间长短。
(12)分阶段的解决方案：确定实现是分阶段进行还是发行一个大版本，了解这些问题才能使测试工作与当前阶段匹配，并根据当前阶段的情况进行迭代实施。
完成了对系统的全面了解后，测试人员就知道了系统的规模、相应的工作量和潜在的风险。通过这些信息，测试人员就能够了解手头的测试任务并建立测试目标和与测试目标相关的测试框架。
2．根据功能的优先级安排测试工作
软件功能的实现必须划分优先级，分期分批地在功能不断增强的软件版本中实现。但是，测试过程的规划和开发不仅应该依赖于优先级和风险，还要根据软件功能的实现时间表，因为后者决定了可供测试的功能交付顺序。
评定功能的优先级对于分阶段发行来说很重要。在大多数情况下，在开发工作的安排中，应该努力首先交付最主要的功能。相应的，应该首先去测试这些功能。
可以根据下面的标准来划分功能的优先级：
(1)风险高到风险低：将开发和测试的精力首先集中在风险最高的特性上。这是划分优先级的一种方法。
(2)复杂度高到复杂度低：根据复杂度来划分优先级，首先开发和测试最复杂的功能，这种做法可以最大限度地减少进度的延迟程度。
(3)客户的需要：对于大多数的项目，一般都会根据客户的需求来确定功能交付的优先级。
(4)预算、人员和时间的限制：在划分优先级的时候，根据预算的多少、时间限制和人力的可用性来确定也是非常重要的。
3．获得有效的测试数据
测试数据的设计必须使得每个系统级的需求都能经过测试和验证。数据的需求评审应该关注数据的几个关键方面，其中包括：
(1)深度：测试组必须考虑支持测试工作所需要的数据库记录的数量和规模。
(2)宽度：测试工程师必须研究数据数值的变化。
(3)范围：测试数据的范围与数据的精确度、相关程度和完整度是相关的。
(4)测试执行期间的数据完整性：当执行测试时测试组必须保持数据的完整性。测试组在测试过程中．必须能分离数据、修改所选的数据并且能使数据库恢复到它的初始状态。
(5)条件：创建的数据集应该能够反映应用程序所在领域的特性条件，这就是说特定模式的数据并不需要等到一定的时间之后才能通过执行特定的操作来获得。
4．估计测试准备和执行所需要的时间
在实施理想的测试计划和最好的测试策略之前，必须估计测试的准备和执行所需的时间。当制定软件开发时间表时，对测试时间的估计是非常重要的。
理想情况下，测试的估计工作应该从工作分解结构(wBs)开始，或从测试任务的详细列表开始，“测试工作分解结构”是根据测试任务的详细列表而生成的。
为了获得最好的效果，这里列出的方法必须根据组织的要求和规程进行调整：
(1)开发比例法：由于软件工业关注的焦点是估计软件开发的工作量，所以测试工作量的估计一般是基于开发比例方法得到的。这是一种快速简单的测量测试工作所需的工作量等级的方法。其核心是计划投入的软件开发的人员数量。
(2)项目人员比例法：这是另一种快速估计完成测试工作所需的人员数量的方法。该方法根据历史的经验，利用整个项目计划投人的人数(需求，配置，过程，开发和QA等)来计算测试组的规模。
(3)测试过程法：另一种估计测试工作所需人数的方法是采取测试工作的规模估计，其具体是指计划在项目中实施的测试过程的数量。但这种方法由于只关注了需要设计和执行的测试过程的数量，因此在某种程度上是有局限性的。
14)任务规划法：该方法需要回顾相似类型的测试工作在所需人员数和时间方面的历史记录。这种方法和“测试过程法”的不同之处在于它关注的焦点是测试任务。
(5)其他的考虑：无论采用哪种估计方法，有经验的专业人士还是会考虑到任何的特殊情况，这时就需要考虑测试需求范围、测试工程师的技能水平、商业知识、测试组的组织结构等。
5．规划测试环境
测试环境由支持测试工作的所有物质元素组成(测试数据、硬件、软件、网络和设备)。测试环境计划必须确定访问测试环境的人员的数量和类型，并为这些人分配足够数量的计算机，还应该考虑所需环境的安装脚本和试验台脚本的数量和种类。
测试组的成员可以根据下面的信息和资源的准备状况来设计测试环境：
(1)获得客户环境样本的描述。
(2)确定测试环境是否需要一个归档机制来储存测试后产生的大文件。
(3)确定客户环境中的网络特性。
(4)对于基于客户端／N务器或基于web的系统，需要确定服务器的操作系统、数据库和其他组件。
(5)确定测试组需要的自动测试工具的许可证。
(6)确定执行某些测试过程需要的其他软件。
(7)考虑配置测试需要的特殊资源。

1．3测试组成员
测试组成员作为测试工作的主体，测试组能力的高低会极大地影响测试工作的成败。一个高效率的测试组应该同时具备与目前软件问题相关的技术知识和领域专业知识。同时测试组还必须结构合理，每个成员都必须被赋予合适的角色和职责并不断地评测每个成员的有效性以保证测试工作的成功。
为了更好地发挥测试组成员的能力，应该对测试组成员进行如下工作：
1．定义角色和职责
测试工作很复杂，测试组需要具备多种专门技术，能理解测试工作的范围和深度，并为测试工作制定测试策略。为了使测试组的每个成员都了解到什么是必须完成的任务和谁是该任务的负责人，必须定义并文档化测试组成员的角色和职责。
2．测试技巧、行业知识和经验缺一不可
最高效的测试组应该由具备各种专门技术(如行业知识、技术知识、测试技术等)的成员组成，同时也应该由具备各种经验等级的成员组成。了解应用程序功能细节的行业专家(Sub—ject—MatterExpert，SME)在测试组中起着重要作用。
下面详细阐述这些观点：
(1)行业知识：如果软件面向的行业非常复杂。专业的测试人员不可能在短期之内彻底地了解问题域。这时就需要工作中的每个SME与开发人员和整个行业中的其他的SME紧密地协作，才能站在客户的使用和需求角度测试。
(2)技术知识：虽然测试人员完全掌握问题域确实很有价值，但是如果对软件工程(包括测试工作)缺乏一定程度的了解，那么会降低测试人员的效率。最高效的行业专家测试人员是那些对技术感兴趣并有相应的实践经验的人员。
(3)经验等级：测试组完全由专家级的测试人员组成是很少有的，初学者也有其用武之地，但需要为其分配风险较低或测试一些如GUI界面控制之类的外在特性。
虽然专业测试人员和行业专家测试人员侧重于测试工作的不同方面，但是应该鼓励这两种类型的测试人员互相协作。
3．评估测试人员的有效性
要保持测试工作的有效性，就需要对实现测试工作的各个元素不断地进行评估，并且根据实际需要不断地改进这些元素。测试人员作为测试工作的核心力量和重要组成元素，必须被不断地进行评估，来保证测试工作的有效性。
同时对测试人员的评估也是一项十分困难的工作。评价时不仅要考虑典型因素(出勤率、注意力、态度和主动性)，还要有专门用于评估测试人员的有关测试的度量方法。
在没有指定角色、任务、时间表和标准的情况下，无法对测试人员的有效性进行评价，这时测试经理必须表明对测试人员某个时间段的期望是什么．然后根据情况对其进行评估。下面简单罗列一些对测试人员的期望：
(1)遵守测试标准和测试过程：测试工程师必须了解需要遵守的标准和过程，并且必须就过程进行充分的交流。
(2)保持进度：测试人员必须了解测试时间表，其中包括必须交付测试计划、测试设计、测试过程、脚本和其他测试产品的时间。
(3)达到目标和完成指派的任务：为每个测试人员分配的任务必须形成文档并且需要和他们进行充分交流，同时还必须确定截止日期。
(4)控制预算：当测试人员评估必须购买的测试工具和其他测试技术时，他们必须了解可供支配的预算，这样测试人员才不会浪费时间去评估昂贵的产品。
同时由于测试人员的经验和技术类型不同，在进行人员评估时还要注意以下因素：
(1)行业专家和技术专家：行业专家具备的专门技术与应用程序的行业领域有关，而技术型的测试人员对应用程序的技术问题感兴趣。
(2)有经验的测试人员和初学者：测试人员的技能水平必须受到重视。由于初学者可能会忽略一些缺陷或意识不到是缺陷，因此应该分配一些风险低的任务。
(3)功能性测试和非功能性测试：评估功能性和非功能性测试要运用不同的标准。功能性测试还应该建立在对测试过程的评审基础上。
(4)测试阶段：在不同的测试阶段(口测试、|8测试、系统测试、用户验收测试等)，测试人员要完成不同的测试任务。根据测试任务的难度和内容不同，评估的要求也会不同。
(5)开发生命周期的各个阶段：测试人员应该从生命周期的开始就介入项目。对测试人员表现的评估也应该按阶段进行。虽然对测试人员的评估可能是主观的，但是还是应该重视和各个阶段有关的因素，而不是凭第一印象得出表面的结论。
(6)服从命令和关注细节：关注一个测试工程师遵照指示和注意细节的程度是非常重要的。测试经理对测试人员的可依赖程度和贯彻指示的持久性要做到心中有数。
(7)缺陷类型、缺陷率和缺陷文档：在评估的过程中还必须考虑测试工程师发现的缺陷类型，是复杂的、与行业领域相关的还是简单的外观缺陷。

1．4系统架构
要正确地测试应用程序，所需要的不仅仅是简单地模拟和重现用户的动作。不了解系统的内部构架和组件。只通过用户界面进行测试的方法就是典型的黑盒测试。但黑盒测试本身并不是最有效的测试方法，要全面地验证应用程序在功能方面的正确性，就需要测试组对系统的内部有一定程度的了解。如果直接把系统的各种模块和层次作为测试目标，那么这种测试方法就叫做灰盒测试。
1．了解系统的架构和基本组件
如果测试工程师对于应用程序的架构和基本组件有所了解的话，这些知识会有助于他们查明产生特定测试结果的应用程序的各个部分。这种了解可以有效地帮助测试人员进行灰盒测试，而灰盒测试又是黑盒测试的有效的补充。
那么有效地了解系统的组件对测试究竟有什么帮助呢?
(1)提高缺陷报告的质量。测试过程通常依赖于需求，因此它会沿着一条相对固定的路径经过系统。当在这条路径上发生错误时，如果测试人员能够在缺陷报告中反映与系统架构有关的信息，那么系统的开发人员势必会得到很大的益处。
(2)提高进行探索性测试的能力。如果某项测试失败，这时会需要测试人员进行集中测试来确定系统的“断裂点”(导致系统崩溃的因素)。在寻找“断裂点”时，如果对被测系统的架构方面有所了解，这会帮助他们进行更有效、更针对的测试。
(3)增加测试的精确度。灰盒测试是为了通过用户界面或者直接面对基本组件检验应用程序而设计的，它通过监视基本组件的行为来确定测试是成功还是失败。
那么测试人员应该如何去很好地了解系统的架构呢?最好的方法莫过于在开发人员提出备选的架构时。测试组参与架构和设计的评审。鼓励
测试人员评审系统架构和设计文档，并向开发人员提出问题。每次版本升级更新后测试人员参与系统架构的变化评审也是十分重要的，这样他们才不会遗留任何影响测试的因素。
2．确认系统的可测性
许多大型的系统都会由很多的子系统组成，而且这些子系统又会由一个或多个层次的代码和其他支持组件组成。用户和系统边界或用户界面进行交互，随后系统再和其他的子系统进行交互来共同完成一项任务。随着系统中子系统、层次和组件的增多，测试该系统的定位问题就越发的困难。
所以在系统架构的最初形成过程中，测试组成员必须时刻跟进并关注架构的所有方面，以及这些方面对应用程序测试工作的有效性和效率可能产生的正负方面的影Ⅱ向。
当应用程序的架构还只是停留在文档上而没付诸实施时，对架构可测试性的研究可极大地减少随后的测试工作中可能出现的意外。
3．使用日志增强系统的可测性
增强应用程序可测试性最常用的方法就是实施日志机制及跟踪机制，这种机制提供的信息有：组件在做什么、应用程序的状态或应用程序运行中遇到的错误。
在应用程序执行过程中，所有的组件写入的日志条目详细描述了它们正在执行的方法和正在操作的主要对象。
一个Ft志条目只是一条具有一定格式的消息，一个好的日志条目应该包含以下基本信息：
(1)类名和方法名。
(2)主机名和进程ID。
(3)条目的时间戳。
(4)消息。
测试人员可以把这些细节信息作为缺陷报告的一部分交给开发人员，所以这些信息大大增强了测试工作的缺陷诊断能力。这样测试人员不但能够报告缺陷的表面“症状”，而且也能够准确地指出导致问题发生的应用程序的内部行为。

1．5测试设计和测试文档
测试设计和测试文档是测试组的主要工作。在前面已经介绍了，这些工作不应该在软件交付给测试组时才开始，而应该在第一条需求被认可后就启动。因为需求和系统可能会随着时间和系统的开发而不断完善，同时测试过程也需要不断地完善，来覆盖新增和修改的需求和系统的功能。
那么如何进行测试设计和测试文档的编写呢?下面为大家提供一些好的建议：
1．使用测试过程模板和测试设计标准
为了测试过程的可重复性、一致性和完备性，在适当的时候应该运用测试过程模板。下面列出一个可用的测试模板所包含的关键元素。
(1)测试过程ID：符合命名规范的测试过程ID。
(2)测试名称：提供对测试过程的描述。
(3)执行日期：测试过程的执行时间。
(4)测试工程师的名字：执行测试过程的测试工程师的名字。
(5)测试过程的作者：测试过程的开发人员。
(6)测试目标：测试过程的目标。
(7)相关用例和需求编号：测试过程验证的需求的表示编号。
(8)前置条件／假设／依赖：测试过程运行之前必须满足的标准／先决条件。
(9)验证方法：包括标准、自动测试还是手动、审查、示例和分析等。
(10)用户动作：测试过程的目的和期望应该在这明确定义。
(11)预期结果：执行一个特定的测试过程所产生的预期结果。
(12)跟踪日志信息：将后端组件的行为文档化。
(13)实际结果：该项可有默认值，记录了实际的测试结果。
(14)需要的测试数据：支持测试过程的数据集合。
测试设计的标准必须要形成文档，认真传达并付诸实践，这样每个相关人员才能遵守设计方针并且提供所需要的信息。无论是手动还是自动测试过程．都必须遵守测试过程创建标准或原则。
并不是所有的测试场景都要求按照测试模板的要求以相同的细致程度来进行文档化。在复杂的系统中，一些测试过程需要很多的用于计算的输入数据，测试需要采用不同的文档化方法，如数据表。
2．根据需求得到有效的测试用例
对于一个应用程序进行功能性测试的目的是为了发现与最终用户需求不一致的地方。功能性测试活动是大多数软件测试工作的中心。功能性测试阶段最重要的是目标是评估系统的行为是否与需求制定的行为一致。
有效的测试设计所包含的测试过程应该很少出现重叠，相反它会在重复劳动最少的情况下提供最大的测试覆盖率。同时测试执行期间，为了确保测试执行的顺序是正确的，测试工作没有不必要的重复，分析测试流程也是非常重要的。
要设计高效的测试用例，就需要对系统的变化、流程和场景有所了解。为了理解各种联系、流程和相互关系而逐页地通过读需求文档是一件苦差事。在复杂的系统中理解原因与结果之间的联系需要分析思考和关注。只是设计和开发对系统的外在功能进行测试所需要的高层测试用例还不够，在更深入的灰盒层次上设计测试过程也是同样重要的。
3．利用系统设计和系统原型
原型有很多的用途，它可以让用户预先看到某个功能的实现结果，并让用户提前体验应用程序。同时利用原型用户还可以提出对正在开发的软件的反馈意见。
原型有助于检测需求的不一致性。在定义详细需求时，如果由一个以上的人来负责开发和维护，那么矛盾是很难被发现的。原型的创建和设计有助于发现不完整性和不一致性，并且为开发定制工具奠定基础。
为高风险的和高复杂的部分制作原型，就可以在整个过程的早期开发出正确的测试机制，并不断改进。在开发生命周期中及早地准备原型，就可以把原型当做更接近实际的应用程序模型，并据此定义自制测试工具的概要和方法。
系统设计和原型有助于测试过程的完善，同时也是对需求进行添加和修改的基础，因此也是创建更好、更详细的测试过程的基础。
系统原型还有助于利用功能性测试工具的自动测试工作的设计。原型可以帮助测试人员确定哪些自动测试工具会遇到兼容性问题。
4．设计测试用例时采用经过检验的测试技术
在前面已经讨论过预先规划测试数据的重要性。在测试设计阶段会发现测试输入数据是无穷无尽的。因此想要通过穷举法来测试显然是行不通的，这时就需要利用有效的测试技术来减少测试用例和测试场景的数量，用最小的工作量达到最大的测试覆盖率。
在可能采用的多种测试技术中，可以减少测试用例集合的测试方法有：
(1)功能分析法：该方法需要根据功能规格说明书分析系统预期的行为，并且据此为系统的每个功能或者特性设计一个或多个测试过程。
(2)等价类划分：用来确定产生相同结果的输入范围和初始条件。如果期望系统运行所处的情形彼此间是等价的或本质是相似的，那么只测试其中一种情形就够了。
(3)路径分析法：用于测试产品内部的路径、结构和连接。它可在两个层面上运用，一种是基于代码或白盒测试，另一种是功能或黑盒测试方面。
(4)边界值分析法：该方法是路径分析法的补充。边界值测试主要用于输入边界逻辑的测试。负面测试是边界值测试的变种，用来检查对非法数据的过滤处理工作是否正常。
(5)正交排列测试：该方法能够运用最小的测试过程集合获得最大的测试覆盖率。当可能的输入数据或输入数据的组合很大时，由于不可能为每个可能的测试数据都建立测试用例，这种方法这时就特别有效。
选择真正能代表接受值范围的具有代表性的数据样本要靠测试设计人员的判断。使用所有测试参数的所有排列来测试系统一般是不切实际的。因此综合运用边界值分析法和其他测试技术来得出一个适度的测试数据集合是非常重要的。

1．6具体测试相关的方面
1．单元测试
(1)在实际软件开发之前或同时开发单元测试。随着极限开发方式的流行，在实际软件开发之前开发单元测试程序的观念被证明是有效的。这种方法中，因为要用需求来指导单元测试的开发，所以它们必须在单元测试开发之前就定义。
在实现软件组件之前开发单元测试也是有很多优势的。首先，单元测试强迫软件的开发方法能够满足每一条需求。其次。将开发人员的精力集中在解决某一项专门的问题上，而不是开发一个能够满足需求的巨大的解决方案上。最后，通过单元测试也可以推测开发人员的实现目标。
在实际工作中，总是在第一步就创建单元测试是很困难的。在某些情况下，单元测试的开发和软件实现必须同时进行。采用这种方法主要是因为从需求出发不能立即设计出最好的组件接口，或由于突出的问题和其他非需求的因素而没有全部完成需求。这时就应该尽量预先为组件定义完整的接口，并针对接口中正确的部分开发单元测试。
(2)使单元测试的执行成为生成过程的一部分。大多数大型软件系统都由源代码组成，这些代码必须通过生成或编译才能够成为操作系统可使用的可执行模块。但是由于硬件的性能和文件调用关系的复杂，版本的生成可能会持续很长时间。因此很多的开发项目用到了自动生成来定期生成系统的正式版本。把自动执行单元测试加到生成过程中，使得生成过程增加了另一种质量保证机制。它保证了通过自动生成得到的产品是一个真正通过单元测试的系统。
单元测试的一个主要的问题是不一致性。这是由于许多测试人员没有采用统一的和结构化的方法来进行单元测试。一种完成这种标准化工作的方法是创建一个单元测试框架。一般在启动时用一个需要运行的测试列表对这个框架进行配置，随后框架就会依次调用它们。框架的使用会缩短单元测试开发时间，因为只需要编写和维护每个层次中的单个测试，不需要它们都支持错误处理和其他执行逻辑。
2．自动化测试
(1)自动化测试工具选择。
1)了解各类测试工具。虽然在测试工业中宣传最多的是功能性测试工具(记录／回放工具)，但是了解其他的可利用的、用来支持测试工作的工具也十分重要。表4—11中列出了几种在测试中有效的并分别适用于不同测试阶段的测试工具。下面简单介绍一下各个测试工具的特点。
①测试过程生成器：一个需求管理工具，可以和一个基于需求规格说明书的测试过程生成器联成一体。需求管理工具用来捕捉需求信息，生成器通过统计、计算或探索式的方法创建测试过程。
②代码覆盖率分析器和代码测量器：测量结构上的覆盖率，使开发组和测试组认识到测试和测试套件的有效性。
③内存泄漏检测工具：这类工具确定一个应用程序是否释放了它申请的内存，并且还提供了运行时的错误检测。
④测试数据生成器：无论测试数据是用于功能测试、数据驱动的负载测试还是性能测试和强度测试．测试数据生成器都能够根据一组规则快速地填充数据库。
⑤测试管理工具：支持对测试生命周期的所有方面进行计划、管理和分析。
⑥网络测试工具：利用该工具，测试过程可以覆盖服务器、网络的性能、整个系统的性能和贯穿这3个组成部分的功能。
⑦负载、性能和强度测试工具：使测试人员能够检查一个系统或应用程序的响应时间和负载能力。
2)了解测试工具对测试的影响。自动测试工具只是解决方案的一部分，它们并不能解决所有测试工作中的问题。有些人会错误地认为自动测试工具会立即降低测试工作量和缩短测试时间。虽然自动测试被证明是有价值的，并且会对自动测试工具的投资产生回报，但往往不能马上见效。由于存在许多不切实际的期望，进行了错误的实现或者选择了错误的工具，有时自动化测试工作可能会失败。
下面纠正了一些软件业内部普遍存在的对自动化测试的错误认识，并提供了一些指导。
①经常需要多个工具：一般来说，单个测试工具不能满足一个组织所有的自动测试需求。而且在目前的市场上，任何一个产品都不能与所有的操作系统和编程语言兼容。
②测试工作量没有减少：在项目中引进自动化测试的目的是为了减少工作量，但大量的事实证明在首次使用自动化测试工具时，测试工作量增加额可能性很大。这是因为首次使用自动化测试工具会给测试工作带来更高的复杂度，并且工程师需要一个学习的过程。
③测试时间没有缩短：由于首次引进自动化测试会导致测试工作量的增加，自然不能期望测试时间的缩短。
④自动测试遵从软件开发生命周期：自动测试工作可以看做有它自己的微型开发生命周期，也会有其他开发工作中出现的规划和协调问题。
⑤相对稳定的应用程序：为了利用记录／回放工具进行有效的自动化测试，应用程序必须是相对稳定的。
⑥不是所有的测试都应该实现自动测试：自动测试作为手动测试的补充，不可能所有的测试都能够自动运行。如：确认打印输出结果。
⑦一个测试工具不会自动测试所有可能的组合：测试组不可能有足够的时间和资源来100％支持整个应用程序所有可能性的测试工作。这时就需要高效的方法来保证测试的覆盖率了。
⑧测试工具可能是不可预测的：测试工具本身也是复杂的应用程序，所以它们也会有干扰测试工作的缺陷，因此测试工作也存在不可预知
的问题。
3)关注组织的需要。在开始测试前，测试人员都会被问及哪种测试工具是最好的。通常最熟悉某种特殊工具的成员会说该种工具是最好的。但到底选取哪种测试工具，这取决于组织的需要和系统工程环境，它们在一定程度上决定了测试工作如何实现自动化。
在选择一个测试工具时，下面的这些是值得考虑的最优实践：
①确定需要的测试生命周期工具类型：根据不同测试人员测试的不同内容和所处的不同测试阶段，需要的工具类型会有差异。这时测试经理需要考虑系统工程环境和组织的需要．列出一个工具评估标准清单来确定工具类型。
②确定各种系统架构：测试工程师需要了解系统的详细架构设计，因为它们会影响性能需求。根据给定的测试工作，制定特殊的选择标准。这还要依赖于正在测试的应用程序的系统需求。
③确定是否需要一种以上的工具：在一个组织内单个工具通常不会满足所有对测试工具的兴趣和需求。同时在给定的环境下，可能没有哪一个工具能够与所有的操作系统和编程语言都兼容。
④了解正在测试的应用程序管理数据的方式：测试组必须了解到目标应用程序管理数据的方式，并且确定自动测试工具如何支持对数据的验证。
(2)自动化测试过程。
1)不要过分依赖记录／回放工具。功能性测试工具(记录／回放工具)能够增强测试工作的效果，但是如果只通过记录／回放直接创建的脚本还是有一些严重的局限和缺点：
①硬编码的数值：记录／回放工具根据用户的交互动作来生成脚本，其中也包含了从用户界面输入或者接受的任何数据。让数值在脚本中“硬编码”会给以后的维护工作带来问题。如果应用程序的用户界面或者其他地方发生了变化，那么硬编码的数值会导致脚本非法。
②非模块化、不易维护的脚本：测试工具产生的记录／回放脚本通常不是模块化的，维护起来非常困难。
③缺乏可重用性的标准：测试过程开发面临的最重要的课题之一就是可重用性。如果测试创建专门的标准。明确地要求开发可复用的自动测试过程，那么就会极大地提高测试组的工作效率。
因此最高效的自动测试方法还应该包括其他自动测试工具和技术。
2)使用经过检验的测试脚本开发技术。测试脚本的开发本身可以当做一个软件开发项目。为了开发高效、可维护和可重用的测试脚本，应该使用经过检验的技术。
在使用功能性测试工具开发测试脚本时，应该考虑下面的技术：
①数据驱动框架：数据驱动意味着数值是从电子数据表或工具提供的数据池中读取，而不是通过硬编码写进测试脚本中。将输入数据外置还能降低维护的工作量和增加灵活性。
②模块化的脚本开发：一个通用的软件开发技术是把代码分成逻辑上的模块，每个模块完成一项独立的任务，这种技术可以增加源代码的可维护性和可读性。
③模块化的用户界面导航：为了增加测试脚本的可重用性．测试工程师应该在脚本中使用导航的方法，这样可以将来自应用程序的用户界面的影响最小化。
④可重用的函数库：一般对于同一个产品甚至对同一类型的不同产品，测试脚本都有许多的相似之处。可以将这些公共的动作剥离出来，形成一个共享的脚本库。
⑤现成的库：网上提供了许多专用于某些测试工具的现成的函数库，这时就可以直接使用。
⑥版本控制：虽然本质上版本控制并不是一种脚本的开发技术，但是它是任何软件项目的重要组成部分。为了避免不同的测试人员并发修改和维护每个文件的修改历史，所有的测试脚本都应该存储在同一个版本中。
(3)尽量使用回归测试自动化。回归测试的目的是：检查在修改先前的错误或者向应用程序添加新功能时．是否引入了新的错误。
缺乏规划和手动测试的方法会导致回归测试效率低下和测试得不充分，并且对资源的利用也是低效的。
为了得到一个计划周密并高效的回归测试计划，测试人员必须仔细思考下面的几个方面：
1)什么时候执行回归测试?软件的每次改动以及对于以前有缺陷的软件进行了改进都要进行回归测试。
2)回归测试应包含什么内容?回归测试应该集中在高风险的功能和执行最频繁的路径上。测试这些元素后，才能检查更细节的功能。
3)如何优化和改进回归测试套件?测试人员可以通过下面的步骤进行优化：首先，运行回归测试集合；其次，如果回归测试集合成功了，但错误在以后暴露出来，那么把确定这些错误的测试过程和其他相关场景加入到回归测试集合；最后。重复上述的步骤，用质量测量法不断优化回归测试脚本套件。
4)为什么需要自动化回归测试?当面对一个庞大的、复杂的系统时，如果以前版本的功能测试套件也加人到下一个版本回归测试工作中，那么最终将会执行非常多的回归测试。因此有必要自动地执行回归测试套件，并且还必须在一个能够快速地运行所有这些测试的、不占用太多资源的稳定测试环境中执行。
5)如何分析回归测试结果?当发现一个以前运转正常的系统功能出现了错误时，测试组必须确定最可能影响出错功能的其他功能部分是哪些。基于这种分析结果，回归测试可以受影响部分更具针对性。
(4)实现自动生成和烟雾测试。自动生成通常每天执行一次或两次，它们会使用最新的和稳定的代码。开发人员可以每天从负责生成的机器上取得组件，或在迫不及待的情况下本地重新生成。
烟雾测试是回归测试套件的精简版本。它主要是对应用程序关键的高层功能进行自动测试。当拿到一个软件的新版本时，烟雾测试不是手动地反复执行所有测试，而是有针对性地验证软件中的主要功能是否仍然能够正常运行。自动生成的实现，可以很好地连接起开发组和配置管理的工作。除了软件自动生成外，自动进行烟雾测试也能够进一步优化开发和测试环境。因为烟雾测试会自动地验证生成的版本，所以软件在生成之后总是处于可用的状态，这是普遍认可的理想状态。
3．非功能性测试
(1)提前考虑非功能性测试。一般来说，软件项目中的工作人员往往会比较关注系统的功能，而很晚才会去关注系统的非功能性问题。这种方法往往会给系统的实现带来很多问题，甚至增大产品失败的风险。因此有关非功能性的事宜，最好在应用程序的构架和设计阶段就开始研究。如果不能及早地关注这方面的实现，那么以后为满足非功能性方面的要求而添加或修改组件将会非常困难。
在规划软件项目时，应该考虑以下的非功能性风险：
1)糟糕的性能：糟糕的程序性能可能只是使用不便，或者也可能是向用户提交了没有价值的应用程序。
2)不兼容性：在最终用户各种不同的系统配置下，应用程序中各功能都能够正常运转，这是大多数软件开发活动最关心的问题。
3)缺乏安全性：虽然所有的应用程序都应该重视安全性，但基于Web的软件项目要特别关注这个问题。
4)缺乏可使用性：对应用程序的可使用性方面重视不够，会导致它在最终用户中间接受程度不高。
(2)定制可使用性测试。对发布一个令用户满意的应用程序来说，可使用性测试是一个困难但是必不可少的步骤。可使用性测试的目标是验证对应用程序有意向的用户是否能够和应用程序正确地进行交互并感到使用起来明确而方便。
为了正确地开发和测试应用程序的可使用性，需要了解目标受众的需求。从可使用性角度来讲，下面的几种方法可以确定他们的需求：
1)行业专家：在一个复杂的应用程序开发组中，有一个可以不断为需求组、开发组和测试组提供相关领域咨询的行业专家是非常重要的。
2)专题组：通过召开专题组会议，可以获得最终用户的意见。
3)调研：调研工作同时也是获得用户需求的一个有效方法。
4)对同类产品的研究：通过对同类产品的研究，可以知道在相同和不同的问题域中，其他组是如何解决问题的。
5)观察用户的操作：通过观察用户和应用程序界面的交互，能够了解到哪些地方用户难以使用。哪些地方直观易用。
(3)为兼容性测试建立高效环境。对应用程序兼容性测试可能是一项复杂的工作。现有的操作系统，硬件和软件配置如此丰富并且它们的组合数量非常之多，兼容性测试问题是无法回避的，但是一个合适的兼容性测试的环境会使这个过程更加高效。
由于所有可能的配置和潜在的兼容性问题非常多，所以可能无法直接测试每种可能性。这时就需要按照出现频率的高低，由软件测试人员
把目标应用程序可能的配置进行排序。
除了选择最重要的配置外，测试人员还必须为兼容性测试确定恰当的测试用例和测试数据。由于针对每种可能的配置运行所有的测试用例会花费很多的时间，这时就有必要挑选出最具代表性的测试用例的集合。
同时对兼容性测试环境的管理也是一项重要的工作。为了正确地测试应用程序，最好完全重建最终用户环境，但是这样的代价是非常高的。这时就必须采取其他的方法。
一种实用而经济的方法是综合使用活动硬盘驱动器和分区管理工具。另一种方法是使用驱动影响程序为需要的配置建立映像文件。
不要在兼容性测试平台上安装开发工具也是非常关键的，因为这些工具可能“污染”测试环境，并使之不能准确地反映真实的操作条件。

1．7管理测试的执行
测试的执行阶段在前面所介绍的各个阶段的后面。这时已经有了测试策略、测试计划、设计并开发完成的测试过程以及可以操作的测试环境。但只有这些还不够，如果在测试执行的过程中没有好的管理体制，测试工作仍然会很难展开和有效完成。下面为大家提供一些在管理测试方面的建议：
1．明确定义测试执行周期的开始和结束时间
不管是哪个测试阶段，为软件测试执行周期定义入口标准和出口标准都是非常重要的。
入口标准描述了何时一个测试组可以开始测试一个特定的版本。在系统测试期间。为了接受一个服装行业软件版本，必须满足以下标准：
(1)所有的单元测试和集成测试已经成功完成。
(2)软件的生成过程没有任何错误。
(3)软件版本通过了之前描述的烟雾测试。
(4)配套文档已经完成。
(5)缺陷已经修正并且准备重新测试。
(6)源代码已经储存在版本控制系统中。
只有在满足入口标准后，测试组才能准备接受软件版本并开始测试周期。
同入口标准一样，出口标准也依赖于当前的测试阶段。它描述了软件完成了充分测试的时间。以下列出了几个可以作为出口标准的准则：
(1)已经执行了用来确定系统满足制定的功能性和非功能性需求的测试过程。
(2)在测试结果中记录的所有的l级、2级和3级(导致运行中断的、紧急的和高优先级的)软件问题都已经解决。
(3)软件发货时可能尚存在已知的低优先级缺陷。
(4)在回归测试中，从前运转正常的功能中发现缺陷的比例。
(5)缺陷修正失败的频率。
(6)随着测试阶段的继续，新缺陷的发现率的走势。
虽然应用程序中可能还有未发现的缺陷，但当它处于发货状态或满足出口标准时，就认为测试完成了。
2．隔离测试环境和开发环境
在测试组准备实施测试策略时，测试环境的建立是非常重要的。
测试环境必须要和开发环境分开，这是为了避免测试期间的严重疏忽和无法追踪软件的变化。
但是如果没有规划独立的测试环境，那么在测试工作的进行当中会产生很多的问题：
(1)环境的变化：由于开发人员可能在没有通知测试组的情况下，把缺陷修正的结果或者其他变化应用到开发配置中，或向开发配置添加了新的数据。
(2)版本管理：如果开发人员和测试人员共享同一个环境，那么版本的管理就比较困难。开发人员可能需要为软件增加新的功能，同时测试人员却需要一个稳定的版本来完成测试工作。
(3)操作环境的变化：为了在各种不同的条件下测试应用程序，可能需要对测试环境进行重新配置。这会造成环境的严重混乱，这种混乱会严重影响到开发人员的活动。如果由于预算有限，可以采取以下的措施来保证测试环境的相对独立：
(1)降低性能和容量。
(2)使用活动硬盘。
(3)建立一个共享的测试实验室。
3．实现缺陷追踪生命周期
缺陷追踪生命周期是测试工作的一个关键部分。
每个测试组必须用一个详细的过程完成缺陷报告工作，其中主要包括以下几个步骤：
(1)建立缺陷文档。缺陷文档中应该包含的各种属性如下：
1)主标题：主标题的前缀应该是发现缺陷的系统部分的名字。
2)正在测试的工作版本：正在测试的工作版本。
3)操作系统和配置：列出发现缺陷的测试工作所用的操作系统和其他配置元素。
4)附件：例如有关错误的截屏和打印的日志等。
5)再现性：如果错误可以重现，这里应该包含开发人员能够重现缺陷的所有必要信息。
6)重现错误的步骤：指明缺陷是总可以重现，随机出现或不能重现。
7)返测失败：如果在返测中缺陷仍然存在，这里将给出详细描述。
8)分类：需要报告的行为类别包括缺陷、增强请求或变更请求。
9)解决方案：开发人员指出修正一个缺陷应该采取的正确措施。
(2)划分优先级。以下是一些通用的缺陷优先级分类方法：
1)导致运行中断：由于缺陷导致应用程序崩溃，预期功能没实现。
2)紧急：事件非常重要。并且需要马上给予关注。
3)高级：事件是重要的。并且应该在紧急事件处理之后尽快解决。
4)中级：事件是重要的，由于解决问题需要一定时间，可以用较长时间来解决。
5)低级：时间不重要，可以在时间和资源允许的情况下再解决。
6)N／A：没有适用的优先级。
(3)重复出现：过程中应该定义如何处理重复出现的问题。
(4)关闭：如果某个缺陷已经修正、确定是重复缺陷，或者发现其实不是缺陷．那么报告就应该立即终止。
4．追踪测试工作的执行
服装行业软件项目的涉众都希望知道测试工作何时结束，为了能够回答这个问题，必须对测试进行有效的追踪。为了完成这项工作，需要收集数据或度量测试工作执行来显示测试的进度，将其与计划进行比较，可以及时得到测试行为滞后的信息，从而尽早采取必要的措施。
在测试的执行周期中，测试进度的度量需要反复收集。有关测试进度的度量包括：
(1)测试过程执行状况一已经执行的测试过程数量／测试过程总数。
(2)缺陷持续时间一从发现缺陷到改正缺陷的时间跨度。
(3)从缺陷纠正到返测的时间一从缺陷被修正并且在新版本中发布的时间到缺陷被返测的时间跨度。
(4)缺陷趋势分析一在测试生命周期内，随着测试工作的进行，发现缺陷的数量的变化趋势。
(5)修改的质量一修改后剩余的缺陷数量。这个度量数据也称为重现率。
(6)缺陷密度一一个需求中发现的缺陷总数／为这个需求执行的测试过程数量。
为了测试工作的执行进行度量，我们需要收集的度量数据很多。为了确定缺陷修正活动的所有需要，突出高风险的部分和最终使测试工作成功执行，这里描述的度量是需要追踪的核心度量集合。