【经验分享】软件测试用例管理

本文涉及到测试用例的编写规范，以及用例管理的分享，因此，无论是对于初级测试工程师，还是质量团队的管理者，都有一定的参考意义。文中涉及到的方法和工具并不是唯一解决方案，希望大家收获到的不仅仅是文字表面，而是文中分享的一些思路。

有人说：测试用例还不知道？不就是描述测试步骤吗？

这么回答确实没什么错，只是如果内心上也仅仅这么认为的话，只能说并未理解测试用例。

测试用例除了作为测试行为的描述，更多的是作为被测目标是否达到需求的验证，主要还是考验了一个测试工程师的组织归纳能力，其输入来源往往是承诺书、用例(Use Case) 以及自身对业务领域知识的经验，一个软件测试工程师的专业度往往体现在他设计的测试用例上。

专业的工程师设计出的测试用例集，不仅能够描述自己的行为，还能指导别人实施，不仅强调深度，还具有优秀的用户思维。

虽然从格式上来说，基本就定型了：

关于这部分，网络上的教程只多不少，就不赘述了。

只不过要强调的重点是， 格式只能保证测试用例明晰，并不能提升测试用例的设计能力 。因此，测试用例该怎么写？还是要从结构化设计开始。这里需要提到一个概念 HLTD [ High Level Test Design ]，可以简单粗暴的理解为测试大纲的设计。

就如同我们写文章一般，提笔正文之前，会先拟个草稿，列出中心思想及段落提纲，然后再攥写润色。

写测试用例也是类似的套路，先列出测试点作为大纲，并且具有结构化布局。通常以大的功能或模块进行分类，再细化二级甚至三级类别，最终列出具体的测试点。该阶段的设计，笔者倾向于利用思维导图（脑图），相较于传统的文档软件工具，思维导图的展现更直观。

由于最终会是一张大图，所以硬伤也随之体现，只适合用于思路梳理，不适合用于文档化管理。

把这些结构化好的测试点文档化，就是我们所说的测试用例了。

所以从这里我们可以看出，每一条测试用例的目的很明确，是验证一个或一类测试点，颗粒度需要根据公司实际情况权衡，太粗不利于对于测试点覆盖的总结，拆太细会消耗更多的精力。

测试用例其实是一个非常详尽的文档，必然会消耗测试工程师相当一部分的精力。在传统软件开发时代，甚至作为 KPI 的一项指标。

但随着敏捷时代的兴起，有一种声音开始冲击这种认知。

早期的敏捷实践者，对敏捷宣言的解读仅仅停留在了文字表面，认为“只需要软件，不需要文档”。这直接导致了这一时期，大量的团队缺失了详尽的文档，甚至连一些基本的文档都没有。

如今，越来越多的敏捷实践者认识到，敏捷宣言所宣扬的并不是“不用详尽的文档”，恰恰相反， 敏捷宣言认同了“详尽的文档很重要”这件事，并且提出了更高的要求 —— “工作的软件更重要”

对于测试用例文档化工具的选择，很多团队仍然停留在传统的办公软件，如 Word、Excel

但如今凡事比快的市场环境下，团队成员高效协作、团队信息实时共享的需求越来越高，测试用例平台化管理必然还是最终归属，除了文档化，还利用平台制定计划，展示进度和结果。

事实上，在传统时代，大一些的软件公司就已经使用平台来管理测试用例了，这再一次证明了敏捷时代并不意味着推翻过去的经验和成果，而是提出了更高的要求。

如今，相对知名的管理平台有基于 Jira 做插件的，如：Zephyr、Xray、synapseRT、TM4J，也有独立的开源平台: 如：TestLink，或收费的独立平台: 如：TestRail

我们主要从其生态、推行成本、可扩展、费用角度去综合考虑。

Zephyr 的名气一直都很大，但实际上并不太符合国人使用的习惯，使用起来诸多不便。用例直接使用 Jira issue，功能比较简单，用例管理主要在计划和循环的关联上。由于其是 Jira 插件，因此能很好的跟 Jira 上其他 issue (需求、任务、缺陷) 进行关联。但其用例管理的可视化不是很好，没有用例集的概念。迁移方面，数据导入支持类型有限。扩展方面，若要使用其 API，还需要另外装一个插件。其费用中等。

Xray 算中规中矩，也是使用 Jira 的 issue 来创建测试用例。但其新增的 issue 类型多达 5 类，显得极其复杂。关联能力与 Zephyr 相同，数据导入支持类型有限，本身有 API 可供使用。其费用中等。

synapseRT 是国人开发，汉化效果最好，功能强大。有用例集的概念，用例也是用的 Jira issue 来扩展。数据导入支持了 TestLink、Zephyr 这样的其他平台。关联能力同 Zephyr，数据导入支持类型依旧有限，其本身也有 API 可使用。而费用相对较低。

TM4J 使用独立页面管理测试用例，脱离复杂的 Jira issue 页面，上手难度低。数据导入功能强大，覆盖很多类型及一些知名平台。关联能力与上述插件一致，本身也有 API 可使用。但费用相对较高。

TestLink 作为独立的测试管理平台，功能全面，开源免费。可以关联 Jira 这样的知名平台，但由于不是 Atlassian 体系，所以生态体验不高。硬伤是界面丑陋，容易影响工程师的心情。笔者曾经使用其本身的 API 进行 UI 美化。

TestRail 是一个强大的商业平台，笔者接触不多，不乱作评论。

综合考虑，虽然 TestLink 作为免费开源用例管理平台中的 TOP，在用例管理上做得非常科学，一直值得学习，但笔者所在公司已经在使用 Jira，并在落地 DevOps，外加笔者常受 Atlassian 中国社区研究院副院长的支持，TM4J 成为最终选择：

出品方还是挺强的，除了 TM4J，Zephyr 其实也是其下产品，Swagger 也已经是目前认知度很高的产品了。

从官网介绍上可以看出，TM4J 还是比较现代化的：

首先我们看看利用 TM4J 如何来编写测试用例。

层级结构上，我们根据 HLTD 来创建目录以及子目录，以方便所有人理解和阅读，最后的测试点则实例化为一个测试用例，它拥有全局唯一的 Key。

点击 New 按钮创建新测试用例，默认在 Details 标签页，在这里定义用例名称、目的、前提条件，详情中可以设置状态、优先级、所属组件，并可以添加一些便于管理的标签。

切换到 Test Scripts 标签页，默认是 Step-by-Step 类型，按照 STEP - TEST DATA - EXPECTED RESULT 添加每一个测试步骤。

另外值得一提的是，在 Traceability 标签页，可以关联 Jira issue、Confluence page

通常我们针对每次产品发布交付，需要制定范围，因此计划管理是必不可少的。

计划管理推荐按照发布版本来制定顶层目录，然后针对测试类型创建二级目录，如回归、新功能、端到端、接口、性能等等。

测试计划的创建本身 *** 作倒并不复杂，除了定义计划名称、目的、状态、责任人，外加一些标签。

还需要关联一下需求或者 Confluence 页面。测试周期在刚创建测试计划的时候可能并不存在，可以在之后创建测试周期的时候，会双向关联。

测试周期是一个承上启下的关键，往上关联测试计划，往下关联具体的测试用例。

通常一次发布交付会经历 3-5 次冲刺，每轮冲刺的范围不一定完全相同。

在新建完测试周期名称、描述以及详情之后。

进入 Test Cases 标签页，点击 + Add test cases 添加已经编写好的测试用例。

这一步 *** 作使得测试用例具备了项目属性。

最后在测试周期的 Traceability 标签页点击 Test Plans 后面的放大镜。

通过查找来关联已经做好的测试计划。

创建完测试周期，就可以进入该周期浏览到分配到自己名下的测试用例了，这是所有测试执行者都需要用到的界面，还可以通过 Group by 根据不同规则进行归类，比如根据测试周期中制定的不同目录。

对于用例步骤的执行，TM4J 提供了一些快捷按钮，可以直接标记通过、失败、阻塞，并且可以点击齿轮按钮，快速创建、查找 Jira issue 进行关联，当然，除了对于步骤关联 issue，也可以针对该用例标记 issue，点击 Issues 后面的 + ▼ 可进行 *** 作。统一平台的好处便是在此了。

虽然我们在查看测试周期列表的时候可以看到测试的进度，但更多数据展示可以通过测试报告来体现。

TM4J 的 Reports 功能给我们提供了丰富的模板，方便一些经验不足的测试质量管理者。

最后，笔者想说， 测试工作不能作为一个独立的业务，应该更多的与其他角色协作 ，特别是在现在的敏捷时代，测试用例的执行可以要求开发工程师关注，测试的状况可以要求产品经理随时介入，因此，强烈建议我们软件测试工作者尽量选择一些跨职能协作平台。

使用脚本。
采用自动化关键字数据驱动模式设计，即表格驱动测试或者基于动作的测试，把测试用例、控件元素等放入数据库或页面进行展示 *** 作。
给这个文本框输入数据。即通过ID属性值comtestseller：id/phone_edit1，找到此用户名文本框的控件元素，然后通过sendkeys方法输入用户名数据13798359580到此用户名文本。其他自动化测试步聚的定位方法、控件元素以及 *** 作方法也都与此类似。实际上自动化测试就是通过程序代码来实现模拟手动测试去 *** 作一遍的过程。

黑盒测试，设计用例的方法主要有：等价类划分、边界值设计、经验设计、正向和逆向测试设计等等，按不同的项目，还有不同的设计，比如汽车电子测试中需要场景分析测试，服务器测试中，还有性能和压力测试等。

1输入已注册的用户名和正确的密码,验证是否登录成功
2输入已注册的用户名和不正确的密码,验证是否登录失败,并且提示信息正确
3输入未注册的用户名和任意密码,验证是否登录失败,并且提示信息正确
4用户名和密码两者都为空,验证是否登录失败,并且提示信息正确
5用户名和密码两者之一为空,验证是否登录失败,并且提示信息正确;
6如果登录功能启用了验证码功能,在用户名和密码正确的前提下,输入正确的验证码,验证是否登录成功
7如果登录功能启用了验证码功能,在用户名和密码正确的前提下,输入错误的验证码,验证是否登录失败,并且提示信息正确。

1用户名和密码是否大小写敏感
2页面上的密码框是否加密显示
3后台系统创建的用户第一次登录成功时,是否提示修改密码
4忘记用户名和忘记密码的功能是否可用
5前端页面是否根据设计要求限制用户名和密码长度
6如果登录功能需要验证码,点击验证码是否可以更换验证码,更换后的
7验证码是否可用刷新页面刷新验证码
8如果验证码具有时效性,需要分别验证时效内和时效外验证码的有效性
9用户登录成功但是会话超时后,继续 *** 作是否会重定向到用户登录界
10不向级别的用户,比如管理用户和普通用户,登录系统后的权限是否
11页面默认焦点是否定位在用户名的输入框
12快捷键Tab和 Enter等,是否可以正常使用

1用户密码后台存储是否加密
2用户密码在网络传输过程中是否加密
3密码是否具有有效期,密码有效期到期后,是否提示需要修改密码
4不登录的情况下,在浏览器中直接输入登录后的URL地址,验证是否会重新定向到用户登录界面;
5密码输入框是否不支持复制和粘贴;
6密码输入框内输入的密码是否都可以在页面源码模式下被查看
7用户名和密码的输入框中分别输入典型的"SQL注入攻击”字符串,验证系统的返回页面
8用户名和密码的输入框中分别输入典型的"XSS跨站脚本攻击”字符串,验证系统行为是否被篡改;
9连续多次登录失败况下系统是否会阻止后续的尝试以应对暴力破解
10同一用户在同一终端的多种浏览器上登录,验证登录功能的互斥性是否符合设计预期
11同一用户先后在多台终端的浏览器上登录,验证登录是否具有互斥性。

1单用户登录的响应时间是否小于3s
2单用户登录时,后台请求数量是否过多
3高并发场景下用户登录的响应时间是否小于5S
4高并发场景下服务端的监控指标是否符合预期
5高集合点并发场景下,是否存在资源死锁和不合理的资源等待
6长时间大量用户连续登录和登出,服务器端是否存在内存泄漏

1不同浏览器下,验证登录页面的显示以及功能正确性
2相同浏览器的不同版本下,验证登录页面的显示以及功能正确性
3不同移动设备终端的不同浏览器下,验证登录页面的显示以及功能正确性
4不同分辨率的界面下,验证登录页面的显示以及功能正确性

集成测试和系统测试的区别
一般的小系统区分不是很大的。
1、计划和用例编制的先后顺序
从V模型来讲，在需求阶段就要制定系统测试计划和用例，HLD的时候做集成测试计划和用例，有些公司的具体实践不一样，但是顺序肯定是先做系统测试计划用例，再做集成。
2、用例的粒度
系统测试用例相对很接近用户接受测试用例。
集成测试用例比系统测试用例更详细，而且对于接口部分要重点写，毕竟要集成各个模块或者子系统。
3、执行测试的顺序
先执行集成测试，待集成测试出的问题修复之后，（配置管理，基线化），再做系统测试。
4、用例的数量
系统测试的用例数量一般比集成测试的用例数量少，具体的数量要根据各个公司的性能基线来确定，一般写不到这个数量的测试用例还通不过审计。 系统测试这个称呼往往被用于压力测试、容量测试、性能测试、安全测试等方面。
而集成测试这个称呼往往被用于细节化的功能测试的超集——从用户需求来设计和组织较大颗粒度的功能测试。
系统测试最主要的就是功能测试，测试软件《需求规格说明书》中提到的功能是否有遗漏，是否正确的实现。做系统测试要严格按照《需求规格说明书》，以它为标准。测试方法一般都使用黑盒测试 法；
集成测试在系统测试之前，单元测试完成之后系统集成的时候进行测试。集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。集成测试对测试人员的编写脚本能力要求比
较高。测试方法一般选用黑盒测试和白盒测试相结合。
集成测试：是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的借口是否正确。它根据集成测试计划，一边将模块或其他年间单位组
合成越来越大的系统，一边运行该系统，以
分析所组成的系统是否正确，各个组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。也可以理解为在软件设计单元、功能模块组装、集成为系统时，对应用系统的各个部件（软件单元
、功能模块接口、链接等）进行的联合测试，以决定他们能否在一起共同工作，部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。
系统测试：系统测试是基于软件需求说明书的黑盒测试，是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确，
并非一项简单的任务，被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他的动态运行行为应该与软件规约进行对比。软件系统测试的方法很多，主要有功能测试 ，性能测试，随机测试等。
通俗的讲，一个产品从研发到出厂的工程中，测试分为三个阶段：单元测试、集成测试、系统测试； 单元测试：一个模块的功能及常规错误测试； 集成测试：完成单元测试后，各模块联调测试；集 中在各模块的接口是否一致、各模块间的数据流和控制硫是否按照设计实现其功能、以及结果的正确性验证等等；可以使整个产品的集成测试，也可以使大模块的集成测试； 系统测试：针对整个产品的
全面测试，既包含各模块的验证性测试（验证前两个阶段测试的正确性）和功能性（产品提交个用户的功能）测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。

      测试设计是将概括的测试目标转化为具体的测试条件和测试用例的一系列活动。

①评审测试依据（需求，系统架构、设计和接口说明）。

②评估测试依据和测试对象的可靠性。

③通过对测试项、规格说明、测试对象行为和结构的分析，识别测试条件并确定优先级。

④设计测试用例，并确定优先级

⑤确定测试条件和测试用例所需要的必要的测试数据。

①依据在测试策略或测试计划中确定的测试技术。

②通过对测试依据和测试目标的分析，可以确定需要测试的内容，获得测试条件。

       测试用例是通过使用在测试计划中确定的测试技术，对于已确定的测试条件进行逐步推敲，精炼而设计出来的重点说明如何具体 *** 作产生何种结果的文档。（指引我们测试的文档）

      测试用例应该具有可重复性、可验证性和需求可追踪性。

①前提条件，如项目或局部测试环境的需求，及其交付计划。

②测试步骤。

③测试数据。

④预期结果。

①测试两个参数的值相加后的结果是否正确

②期中：输入的数值在-99到99之间，大于99或小于-99的输入应该被拒绝，并显示错误信息。

根据测试需求，我们开始测试：

①分别给第一个参数和第二个参数输入表中的值，得到的测试加过如表所示：

②如果我们对第一个参数的值分别取从-99到99的199个数，第二个参数的值分别取从-99到99的199个数，我们不可能对两位数相加的所有情况进行穷举测试。

③如果不能进行穷举测试，我们将面临以下的问题：

         在测试了1+1，1+2,1+（-1）和1+（-2）之后，还是否有必要测试1+3,1+4呢？

        如果不对加法计算器程序进行穷举测试，是否放心的认为所有的参数组合都是正确的呢

对于以上两个问题，我们可以采用等价类划分法来进行解决。

①等价类划分的办法就是把程序的输入域划分成若干部分。

②从每个部分中选取少数代表性数据当做测试用例。

③每一类的代表性数据在测试中的作用等价于这一类中的其他值。

④也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误。

⑤繁殖，如果某一类中的例子没有发现错误，则这一等价类中的其他例子也不会发现错误。

①如果输入条件规定了取值范围或值的个数，则可确定一个有效等价类和两个无效等价类。

②如果一个输入条件说明了一个“必须成立”的情况，则可划分一个有效等价类和一个无效等价类。

③如果输入条件规定了输入数据的一组可能的值，而且程序使用不同的方式处理每一种值，则可为每一种值划分一个有效等价类，并划分一个无效等价类。

④如果我们确定，已划分的某等价类中的各元素（例子）在程序中的处理方式是不同的，则应据此将此等价类进一步划分成更小的等价类。

⑤在确定了等价类之后，建立等价类表，列出所有划分出的等价类。

①明确测试对象，非测试对象保证正确。

②为每个等价类规定一个唯一的编号。

③设计一个测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖。

④设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有的无效等价类均被覆盖。

例子是前面的加法计算机

①一个有效数据等价类，两个无效数据等价类。

有效数据等价类就是：由那些对程序的规格说明有意义的、合理的输入数据所构成的集合。

无效数据等价类就是：那些对程序的规格说明不合理的或无意义的输入数据所构成的集合。
       在实际工作中，我们通常在确立了等价类以后，把程序中所有的等价类建立等价类表，一遍在编写测试用例的时候有所依据。

①为等价类表中的每一个等价类分配一个唯一的编号。

②设计一个新的测试用例，使他能够尽量覆盖尚未未覆盖的有效等价类。

③重复这一步骤，从而使所有有效等价类均被测试用例所覆盖。

④与上述类似，设计一个新的测试用例，使它只覆盖一个无效等价类。

⑤重复这一步骤，从而使所有无效等价类均被测试用例所覆盖。

①在测试“-99≤数值99”的这个等价类区间的时候，我们会发现如10+40，-20+30和-30+（-30）这类的正数相加，正数负数相加，负数相加也是不同的等价区间。因此我们可以使用更多的等价类划分。

②根据以上等价类划分的加过，得出下表的等价类表：

根据上面划分的4个等价类，我们至少需要有5个测试用例：

①测试相同的内容。

②如果等价类中的一个测试能够获取一个缺陷，那么选择该等价类中的其他测试也能获取该缺陷。

③如果等价类中的一个测试不能获取缺陷，那么选择该等价类中的其他测试也不能获取缺陷。

④如果正确的花粉都能加了，可以大大降低测试用例的数量，测试会准确有效。

⑤如果错误的将两个不同的等价类当作一个等价类，那就会遗漏一种测试情况。

⑥相反的，把同一个等价类看作了两个不同的等价类，那么测试就会是冗余的。

①不但要考虑有效等价类，也要考虑无效等价类。

②仔细划分，审查划分。

③过于粗略可能会漏掉软件缺陷。

⑤组织评审。

①余额宝体现到yhk增加新规则：快速到账（2小时）日限额1W元。

②超过1W元只能选择普通到账。

③按照等价类划分方法设计测试用例。
①设计用例：

②细致分析需求，日限额1W,所以要区分两个场景：

       边界值分析法是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类便捷的测试用例。

       实践证明，在设计测试用例时，对边界附近的处理必给予足够的重视，为检验便捷附近的处理专门设计测试用例，常常去的良好的测试效果。

      边界值分析法不仅重视输入条件边界，而且也从输出域导出测试用例。

        如果输入条件规定了取值范围，应以该范围的边界内及刚刚超范围的边界外的值作为测试用例。

eg1:以a和b为边界，测试用例应当包含a和b以及略大于a和略小于b的值。

eg2:根据以上计算器的例子，根据边界值分析的方法来看看如何对边界值进行测试：
        由于允许输入的额数值在-99到99之间，所以我们可以把-99和99看做两个边界值。我们测试的时候可以去临近边界值的数值和边界值本身作为输入：

eg3:余额宝体现到一囊卡增加新规则：快速到账（2小时）日限额1W元：

       等价类划分法和边界值分析方法都是着重考虑输入条件而不考虑输入条件的个各种组合、输入条件之间的相互制约关系。

       如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字；因此必须考虑采用一种适合于描述多种条件的组合、产生多个相应动作的测试方法，这就需要利用因果图（逻辑模型）。

       因果图法基于这样的思想：一些程序的功能可以用决策表的形式来表示，并根据输入条件的组合情况规定相应的 *** 作；因此，可以考虑为决策表中的每一列设计一个测试用例，以便测试程序早输入条件的某种组合下的输出是否正确。

      概括的说，因果图方法就是从程序规格说明书的描述中找出因（输入条件）和果（输出结果或程序状态的改变）。将因果图转换为判定表，为决策表中的每一列设计一个测试用例。这种方法考虑到了输入情况的各种组合以及各个输入情况之间的相互制约关系。

      判定表（Decision Table）是分析和表达多逻辑条件下执行不同 *** 作的工具。是编写程序的辅助工具，可以把复杂的逻辑关系和多种条件组合的情况表达得及具体又明确。

判定表通常由四个部分组成：

①条件桩（Condition  Stub）:列出了问题的所有条件，通常认为列出的条件的次序无关紧要。

②动作桩（Action Stub）：列出了问题规定可能采取的 *** 作，这些 *** 作的排列顺序没有约束。

③条件项（Confition  Entry）:列出针对它左列条件的取值，在所有可能情况下的真假值。

④动作项（Action  Entry ）:列出在条件项的各种取值取值情况下应该采取的动作。

①分析软件规格说明中哪些是原因（即输入条件或输出条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。

②分析软件规格说明中语义的内容，找出原因与结果之间、原因与原因之间的对应关系，根据这些关系画出因果图。

③由于语法或环境的限制，有些原因和原因之间、原因和结果之间的组合情况不可能出现。为表名这些特定的情况，在因果图上使用一些记号表名约束或限制条件。

④把因果图转换为判定表。

⑤根据判定表中的每一列设计测试用例。

eg:使用因果图+判定表设计测试用例测试两位数计算器。

①输入1：                                                                ②输入2：

条件1：0≤X≤99                                                      条件1：0≤X≤99    

条件2：-99≤X<0                                                    条件2：-99≤X<0

条件3：X<-99                                                        条件3：X<-99

条件4：X>99                                                         条件4：X>99
输出：

正确计算

错误提示

输入1：

     1、2、3、4互斥

输入2：

    1、2、3、4互斥

输出：

输出结果正确和错误互斥

得到的测试用例：

       正交实验设计法（Orthogonal experimental design）,是从大量的试验点中挑选出适量的、有代表性的点，应用依据伽罗卡瓦理论导出的“正交表”，合理的安排试验的一种科学的试验设计方法。

1、提取功能说明，构造因子—状态表

2、加权筛选，生成因素分析表

       计算个因子和状态的权值，删去一部分权值较小，即重要性比较小的因子或状态，使最后生成的测试用例集缩减到允许的范围。

3、利用正交表构造测试数据集

  ① 如果每个因子的状态树是不统一的，几乎不可能出现均匀的情况，必须首先用逻辑命令来组织个因子的状态，作出布尔图。

②根据布尔图得到相应结束的正交表。

③依照因果图上根节点到叶子节点的顺序逐步替换正交表上的中间节点，得到最终的正交表。

4、利用正交表每行数据构造测试用例

正交表：

正交表的表示形式：Ln（t^c）其中：L为正交表的代号，n为行数（试验行数），t为水平数，c为列数（因素数）。

eg：L4（2^3），它表示需做四次实验，最多可观察3个因素，每个因素均为2水平：

1：正确

2：错误

eg：一个正交表中也可以割裂的水平数不相等，我们称它为混合型正交表，如L8(2^4 4^1）：

根据正交表的数据结构可以看出吧，正交表是一个n行c列的表，其中第j行由数码1,2，tj组成，这些数码均各出现n/t次。

第二列的数码个数为2，t=2，即由1、组成，各数码均出现2次。

1、Technical Support (supportsaacom)

>