软件测试 决策表测试方法

软件测试 决策表测试方法

在所有的测试方法中，基于决策表的测试方法是最严格的，因为决策表具有逻辑严格性。
决策表有四个部分，如下图所示：
条件桩

条件条目

行动桩

行动条目（条目中的一列就是一个规则）
所有条件都是二叉条件的决策表称为有限条件决策表，如果条件可以有多个值，则对应的决策表叫做扩展条目决策表。
为了使用决策表标识测试用例，把条件解释为输入，把行动解释为输出。有时条件最终引用输入的等价类，行动引用被测软件的主要功能处理部分。这时规则就解释为测试用例。
对于有限条件决策表，如果有n个条件，则必须有2的n次幂条规则。
在决策表中要小心使用不关心条目。
决策表技术适合具有以下特征的应用程序：

if-then-else逻辑很突出

输入变量之间存在逻辑关系

涉及输入变量子集的计算

输入和输出之间存在因果关系

很高的圈复杂度？？

决策表不能很好的伸缩（有n个条件的有限条目决策表有2的n次幂个规则），不过有多个方法可以解决这个问题，如使用扩展条目决策表，代数简化表，将大表分解为小表，查找条件条目的重复模式等。
功能性测试技术的选择：

如果变量引用的是物理量，可采用定义域测试和等价类测试

如果变量是独立的，则可以用定义域测试和等价类测试

如果变量不是独立的，可采用决策表测试

如果可保证是单缺陷假设，则可采用边界值分析和健壮性测试

如果可保证是多缺陷假设，可采用最坏情况测试、健壮最坏情况测试和决策表测试

如果程序包含大量例外处理，可采用健壮性测试和决策表测试

如果变量引用的是逻辑量，可采用等价类测试用力和决策表测试

软件测试报告如何写

测试分析报告：

1、编写目的：说明这份测试分析报告的具体编写目的，指出预期的阅读范围。

2、测试概要：用表格的形式列出每一项测试的标识符及其测试内容，并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别，说明作出这种改变的原因。

3、测试结果及发现：把本项测试中实际得到的动态输出（包括内部生成数据输出）结果同对于动态输出的要求进行比较，陈述其中的各项发现。

4、对软件功能的结论：简述该项功能，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。说明测试数据值的范围（包括动态数据和静态数据），列出就这项功能而言，测试期间在该软件中查出的缺陷、局限性。

测试原则

对计算机软件进行测试前，首先需遵循软件测试原则，即不完全原则的遵守。不完全原则即为若测试不完全、测试过程中涉及免疫性原则的部分较多，可对软件测试起到一定帮助。

因软件测试因此类因素具有一定程度的免疫性，测试人员能够完成的测试内容与其免疫性成正比，若想使软件测试更为流畅、测试效果更为有效，首先需遵循此类原则，将此类原则贯穿整个开发流程，不断进行测试，而并非一次性全程测试。

以上内容参考：百度百科-软件测试

软件测试报告怎么写

以前写的东西 省略着写
XX软件测试报告 共 x 页 拟制 年 月 日审核 年 月 日会签 年 月 日批准 年 月 日
1 范围本文档适用于XX软件的单元/集成测试。1.2 系统概述1.3 文档概述本文档用于对XX软件的测试工作阶段成果的描述。包括对软件测试的整体描述，软件测试的分类和级别，软件测试的过程描述，软件测试的结果等内容。2 引用文档《XX软件需求规格说明》《XX软件设计说明》《XX系统接口协议》3 测试概述3.1被测软件的基本概况使用的编程语言：XXX 汇编语言程序行数：1590子程序个数：11单行注释行数：669注释率：约为42%3.1.1. 测试小结本次测试对XX软件进行了静态分析和动态测试。测试工作分为两个阶段。第一阶段进行了软件静态分析，软件测试人员和开发人员分别对软件V1.00版本的代码进行走读。在此基础上软件开发人员对代码走查中发现的问题进行了修改，做了97处代码变更并提交了V1.01版本进行动态测试。在测试过程中针对发现的软件缺陷进行了初步分析，并提交程序设计人员对原软件中可能存在的问题进行考查。在软件测试中首先根据软件测试的规范进行考核，将书写规范，注释等基础问题首先解决，其次考核软件测试中的问题是否存在设计上的逻辑缺陷，如果存在设计缺陷则应分析该缺陷的严重程度以及可能引发的故障。软件开发人员在以上基础上对软件的不足做出相应的修改，同时通过软件回归测试验证软件修改后能够得到的改善结果。软件代码1.00与1.01版变更明细表： 编号 1.00版行号 1.01版行号 更改说明 1 19 22 注释变更 2 26 29 注释变更 3 29 32 注释变更 4 95 98 注释变更 5 108行后 113～116 增加新变量 6 171、172 180、181 命令字大小写变更 7 以下略 从上表可以看出，注释变更一共有15处，主要排除了对原程序的理解错误问题；根据程序的书写规范要求，一行多条语句改为一行一条语句的更改一共有42处；命令字大小写变更一共有7处；在代码走查中对冗余和无用的代码作了更改，将这些代码注释掉，此类更改一共有14处。上述4类更改一共有78处，这些更改对程序本身的功能没有任何影响，但从软件规范的角度来看提高了程序的可读性和规范性。其余19处变更为代码变更，主要是在软件测试中发现原程序的可靠性不足，在不改变原程序功能的基础上相应的增加了新变量、新语句、新程序以提高整个程序的可靠性。在动态测试阶段进行了单元测试和集成测试。此阶段发现的软件问题经软件测试人员修改，提交了V1.02版本，软件测试人员对此版本的软件代码进行了回归测试，确认对前阶段发现的软件问题进行了修改，消除了原有的软件问题并且确认没有引入新的软件问题。认定V1.02版为可以发行的软件版本。3.1.1.1 静态分析小结静态测试采用人工代码走查的方式进行。参加代码走查的软件开发人员有：（略）；参加代码走查的软件测试人员有：（略）。代码走查以代码审查会议的形式进行。静态分析过程中共进行了四次会议审查。静态测试阶段的主要工作内容是：l 根据对软件汇编源代码的分析绘制详细的程序流程图和调用关系图（见附件1）；l 对照软件汇编源代码和流程图进行程序逻辑分析、算法分析、结构分析和接口分析；l 对软件汇编源代码进行编程规范化分析。通过静态测试查找出软件的缺陷18个，其中轻微的缺陷4个，占所有缺陷的22.2％中等的缺陷11个，占所有缺陷的61.1％严重的缺陷：3个，占所有缺陷的16.7％上述软件缺陷见附件《软件问题报告单》3.1.1.2 动态测试小结动态测试使用的测试工具为XXX软件集成开发环境。总共的测试用例数：143个。全部由测试人员人工设计。其中单元测试用例138个，集成测试用例5个。发现的软件缺陷有2个，都是在单元测试过程中发现的。集成测试阶段未发现新的软件缺陷。在发现的软件缺陷中：中等的缺陷1个，占所有缺陷的50％严重的缺陷1个，占所有缺陷的50％上述软件缺陷见附件《软件问题报告单》动态测试中代码覆盖率：代码行覆盖率 100%分支覆盖率 100%程序单元调用覆盖率 100％3.1.1.3 回归测试小结对软件测试过程中发现的缺陷经软件开发人员确认后进行了代码更改，并对更改后的代码进行了回归测试。本报告中的数据是回归测试后的测试数据。3.1.1.4 测试分析下面将对此次软件测试中的所有缺陷以及改进设计进行分析。1． 静态测试中的缺陷分析： 1） 4个轻微缺陷属于代码冗余，由于在程序设计中加入了部分调试程序，在程序设计完成后未将这些调试代码注释或删除掉而造成代码冗余，但对程序本身的功能并无影响。修改后程序的效率得到提高。2） 11个中等缺陷属于注释变更，在原程序代码的注释中存在注释不准确的问题，会影响程序员对程序的理解，修改后的程序提高了程序的可读性。3） 重点分析3个严重缺陷：第一个严重缺陷属于XX号的无效判别和相应的处理问题，程序对XX号进行无效判别时，判别界限并不完全，在本跟踪程序中XX号的有效数为01-10（用4位表示），而判别无效时只判了为00的情况，没有判别大于10的情况。而且在为00时也没有作相应的处理，修改后的程序对设计进行了改进，详见改进设计分析3。第二个严重缺陷属于程序设计中读取地址错误问题，经分析在调试中读取的数据是正确的，但是读取的地址与设计初衷不相符，修改后问题得到了解决，详见改进设计分析1。第三个严重错误是近区/远区子程序判断与进入条件反了，经分析对程序的影响不大，但与设计初衷不一致，修改后问题得到了解决，详见改进设计5。2． 动态测试中的缺陷分析：1） 中等缺陷1个，在程序的注释中出现错误，将近区注释为远区，修改后问题得到了解决，提高了程序的可读性。2） 严重缺陷1个，在XX号无效的判别中，本应判断大于10，但误设计为0，修改后经回归测试问题得到了解决。3． 改进的设计分析：（因和产品相关，略） 3.1.2 测试记录a 测试时间：2005年8月5日至2005年9月17日。b 地点：（略）。c 硬件配置：P4CPU/2.0G，内存256M，硬盘1Gd 软件配置：Wondows98，e 被测软件版本号：V1.0，V1.01，V1.02f 所有测试相关活动的日期和时间、测试操作人员等记录见软件测试记录文档。4 测试结果在两个阶段测试过程中共发现软件缺陷20个，经软件开发人员确认的缺陷为20个，经过改正的代码消除了所有以确认的软件缺陷并通过了回归测试。因测试条件所限，未能进行软件的确认测试和系统测试。5 评估和建议5.1 软件评估 5.1.1 软件编码规范化评估经过回归测试，未残留的软件编码规范性缺陷。软件代码文本注释率约为42%，代码注释充分，有利与代码的理解和维护。5.1.2 软件动态测试评估被测软件单元的总数：11个使用的测试用例个数：143个达到软件测试出口准则的软件单元数为11个，通过率100％通过单元和集成测试得知：软件代码逻辑清晰、结构合理、程序单元间接口关系一致，运行稳定。5.2 改进建议a. 建议在软件开发项目中全面实施软件工程化，加强软件开发的管理工作。b. 建议进一步加强软件需求规格说明、软件设计文档编制以及编写代码的规范化。特别是应该将系统中的硬件研制和软件研制分别管理，软件文档编制的种类和规格按照相关标准执行。c. 尽早开展软件测试工作。在软件研制计划安排上给软件测试留有必要的时间，在资源配置上给软件测试必要的支撑。d. 建议结合系统联试，开展软件的确认和系统测试。附件：软件问题报告单（略）软件更改通知单（略）软件测试记录（略）

软件测试的测试报告表中 覆盖率 分为 行覆盖率 和分支覆盖率 是指的是什么意思，，是怎么解释呢？急

行覆盖率对应的是你的代码行，有多少行被覆盖，比如，你有100行代码，执行了90行，那么覆盖率就是90%；
分支分概率是你代码中存在分析，有多少分支被覆盖，比如，你有5个分支，那么对应的应该有10条语句（一个分支有两条语句，ture和false），那么你执行了其中的5条，那么覆盖率就是50%；
希望回答对你有帮助！

软件测试用例怎么写，有简单的例子吗？

本回答以ECShop前台应用中用户注册、用户登陆、商品搜索等功能为例介绍测试用例设计活动。

1 用户注册

用户注册功能需求如图1所示。

图1用户注册需求

用户注册需求共涉及4个输入项和1个选择项。针对于输入项，利用等价类及边界值用例设计方法进行设计，选择项则无须设计在步骤中，在测试执行时分别执行勾选与不勾选即可。

01.用户名

用户名共有三个条件：必填、不少于3个字符、不能重复，分别构造有效等价类及无效等价类，具体如表4-1所示。

敏捷测试用例根据实际测试需要，不一定写的非常细致，如“用户名”包含字符类型，此处无须再划分纯字母、纯汉字、特殊符号等，构造数据时可混搭。

02.email

email有两个条件：必填、符合规定格式，分别构造有效等价类及无效等价类，如表4- 2所示。

03.密码

密码有两个条件：必填、不少于6个字符，分别构造有效等价类及无效等价类，如表4- 3所示。

04.确认密码

确认密码有两个条件：必填、与密码一致，分别构造有效等价类及无效等价类，如表4- 4所示。

测试工程师利用禅道设计用例，如图4- 5所示。

图4- 5用户注册功能测试用例

2 .用户登录

用户登陆需求如图4- 6所示。

图4- 6用户登陆需求

用户登陆共有三个字段：用户名、密码、保存登陆信息，其中用户名、密码为输入框，保存登陆信息为选择框。因该需求比较简单，故无须分析过程，直接进行用例设计，如图4- 7所示。

图4- 7用户登陆功能测试用例

3. 商品搜索

商品搜索需求如图4- 8所示。

图4- 8商品搜索需求

通过需求分析，商品搜索功能较为简单，测试用例设计时只需考虑一个搜索条件的测试，测试工程师从搜索功能开发角度考虑。

对于系统而言，如果数据库中存在某个关键字的商品，则应该显示，否则应当提示没有匹配的商品，故搜索用例设计不需要使用复杂的用例设计方法，测试工程师只需根据经验设计用例即可。

对于显示方式，存在显示方式、排序条件、排序方式三种，显示方式又分为小图列表、大图列表、文字，排序条件有按上架时间、按价格、按更新时间，排序方式有升序与降序，如果完全组合则有3*3*2=18种组合，测试工程师可利用正交试验用例设计方法进行设计。

通过分析，共有3个参数，每个参数分别有3、3、2个取值，因此需选择因子数、水平数都3，且试验次数最少的正交表。查询正交表，4因子3水平正交表符合条件，如表4- 5所示。

替换参数，得到表4- 6。

多余因子4舍弃不用，排序方式中的3，可使用升序或降序任意填充，由于4因子3水平表中没有全部取2与3的情况，因此根据经验再补充两条，最终得到表4- 7所示的正交表。

表4- 7优化后的商品显示测试组合

结合搜索条件，利用禅道设计用例如图4- 9所示。

图4- 9商品搜索功能测试用例

通过上述过程，测试工程师完成测试用例的设计工作，评审通过后等待测试版本发布，然后进行测试用例执行、跟踪处理缺陷等活动。

软件测试的用决策表法为QQ登录界面设计测试用例（只考虑用户名和口令）

用户名： Y Y Y N N
密码： Y Y N Y N
匹配： Y N
成功登录： X
重新输入用户名： X X
重新输入密码： X X
Y表示正确，N表示错误。X表示动作
测试用例：用户名 密码 结果
123234123 3338838f 正确登录（密码用户句匹配）
123234123 4656566 重输密码
34536473 393939 重输密码
123a eettet344 重输用户名
345 空 重输密码
注：有效QQ号：5-10位数字
有效密码：1-16数字，字符

阿里软件测试工程师推荐｜测试用例设计方法——判定表法

判定表(Decision table)是另一种表达逻辑判断的工具。与结构化语言和判断树相比，判断表的优点是能把所有条件组合充分地表达出来；其缺点是判定表的建立过程较繁杂，且表达方式不如前两种简便。判定表在用于知识表达中，有许多其他方式所达不到的作用

判定表法定义

判定表是分析和表达逻辑条件下执行不同操作的情况的工具。

判定表的4个组成部分

判定表通常有以下四个部分组成：

1)条件桩（Condition Stub）：在左上部，列出了问题的所有条件。通常认为列出的条件的次序无关紧要。

2)动作桩（Action Stub）：在左下部，列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

3)条件项（Condition Entry）：在右上部，列出针对它左列条件的取值。在所有可能情况下的真假值。

4)动作项（Action Entry）：在右下部，列出在条件项的各种取值情况下应该采取的动作。

判定表法设计测试用例步骤以及案例讲解

判定表的建立步骤：

1)确定规则的个数.假如有n个条件。每个条件有两个取值（0,1）,故有2的n次方种规则。

2)列出所有的条件桩和动作桩。

3)填入条件项。

4)填入动作项。得到初始判定表。

5)简化、合并相似规则（相同动作）。

案例：

判定表也称我决策表，能表示输入条件的组合，以及与每一输入组合对应的动作组合。与因果图法相似判定表法主要侧重输入条件之间的逻辑关系。

1.判定表主要包含以下五部分：

条件桩：列出所有可能的条件

条件项：列出所有的条件取值组合

动作桩：列出所有可能的操作

条件项：列出在每一种条件取值组合的情况下，执行动作桩中的哪些动作。

规则：一种条件取值组合与其对应的动作组合（即判定表中贯穿条件项和动作项的一列）构成判定表的一个规则。条件组合的数目就是规则的数目。

2.建立判定表可遵循的步骤

1）列出条件桩和动作桩

2）确定规则的个数，用来为规则编号。

若有n个原因，且每个原因的可取值为0或者1，那么将会有2n个规则。

3）完成所有条件项的填写。

4）完成所有的动作项的填写。（得到初始判定表）

5）合并相似规则，用以对初始判断表进行简化。

有两个或者多条规则具有相同的动作，并且条件项之间存在极为相似的关系就可以进行合并。

3.实例

问题描述： “……对于功率大于50马力的机器，并且维修记录不全或已运行10年以上的机器，应给予优先的维修处理……”

条件桩：

C1：功率大于50马力吗？

C2：维修记录不全吗？

C3：运行超过10年吗？

动作桩：

A1：进行优先处理

A2：作其他处理

生成判断表：

简化判定表：

1，2合并，5，7合并，6，8合并

软件测试题目求解判定表

合并相似规则，用以对初始判断表进行简化。有两个或者多条规则具有相同的动作，并且条件项之间存在极为相似的关系就可以进行合并。

如果把简化的判定表画成这样就很容易明白了。

会发现 3 和5、7 不是一种情况，当条件C1符合的时候你不得不去查看C2，看完C2 还要确定C3 不能作为条件项与取值无关。

关于软件测试 决策表测试方法的介绍就到这里，以上就是小编整理的软件测试 决策表测试方法全部内容了，欢迎大家留言讨论。访问学分高考了解更多相关内容