现代统计方法在GUI软件测试中的实际应用 篇一

现代统计方法在GUI软件测试中的实际应用 篇一

2026.04.16

我们已经通过大量篇幅和实例对GUI软件测试的思想、理论和方法作了比较系统的阐述。在已经采用过的研究方法中，既有系统归纳的方法也有解构演绎的方法，其中典型的就是具有系统论思想的GUI软件测试“三步骤法”和具有分层思想的GUI软件“层单元”测试方法。本篇将探讨现代统计方法在GUI软件测试中的实际应用，其中将用一些实例作具体分析讨论，但更重要的将首先是系统分析和总结。

值得一提的是，“实验设计方法正交表在GUI软件测试中的实际应用”一文也是现代统计方法的实际应用之一。同时要注意，现代统计方法的理论基础仍然是研究生阶段的数理统计课程。

1 GUI软件测试场景现代统计方法的可用性

GUI软件测试是GUI软件质量控制和保证的主要手段。现代统计方法在传统工业过程中得到了广泛应用，例如在进货检验中抽样检验已得到基本普及，在工序控制中统计方法也得到了不少的采用。但是，在现代新兴的技术产业中能否应用怎样运用是一个值得探讨的课题 - 其中包括软件产业，因为新兴的技术产业中对产品良率要求更严，而质量控制的对象又往往不满足大批量的统计要求。因此，对GUI软件测试而言，我们要先分析GUI软件测试场景现代统计方法的可用性。

1.1 统计学分析

GUI软件编程中，IDE的“Controls/Components”已通过系统提供商的严格测试，可作为“标准件”处理。也就是说，“Controls/Components”的实现技术是成熟的，“Controls/Components”的生产/开发过程是稳定的，又因为“Controls/Components”已大批实际运用于开发过程中，总的数目可以看成是大批量的，因此其本身是可以作抽样检验处理的。但是，程序员在运用IDE进行编程的过程中，要进行接口参数等限制条件的设置和基础缺省数据的设置，因此，又不能照抄抽样统计方法。由此，软件程序员在运用IDE对“Controls/Components”进行编程时，软件测试员可以把它们作为标准件看待，但还必须对程序员编程过程的影响因素进行分析与控制。

从产品过程影响因素分析，程序员用IDE中的“Controls/Components”编程主要的影响因素有：

（1）系统提供商“Controls/Components”的质量

a. “Controls/Components”本身的质量，还包括

b. 和IDE集成的质量

（2）程序员在运用IDE对“Controls/Components”进行编程的质量

a. 接口参数等限制条件设置的质量

b. 基础缺省数据等设置的质量

另外，还可从编程过程进行影响因素分析，其主要影响因素可能有：

（1）程序员原因 a.技术不熟练； b.粗心或没上进心任务了事； c.疲劳造成的过错；d.外界干扰造成的过错。

（2）编程工具原因 a. IDE版本过低； b. IDE选择有问题；c. 染上病毒。

（3）组织管理问题原因 a. 管理者对分工等处理不好，工作交叉； b. 单个编程没有团队合作或者有“Pair-wise”团队等组织类型但出现内耗。

（4）编程环境原因 a. 办公环境不好； b. 技术支持不好；c. 配套软硬件有问题。

在对“Controls/Components”的测试过程中，可遵循“最重要的少数，不重要的多数”原则运用现代统计思想。经过以上分析并经软件测试实践调查后，我们确定将“Controls/Components”的“数据限定” —边界值设置过程作为重点关键工序(Key control point)，进行抽样检验。主要原因是此类缺陷一般都是严重缺陷，安全敏感软件系统（英文名Safety-critical System）则是重大或致命缺陷。但是，因为国内软件产品质量控制起步较晚，早先软件测试主要把控的重点仅仅局限于功能测试；再者，国内软件从业人员不少是从应用、科研和教学方向转岗过来，软件工程的思想和软件产业的思路和意识还普遍缺乏。我本人/个人的建议是 — 将统计抽样检验主要放在独立测试中，尤其是产品发布之前对非常重要单元或重点关键工序的质量把控中。

1.2 实际编程测试的统计处理

将“Controls/Components”的数据限定测试 — 重点是“上下限边界值”设置作为重点关键工序进行抽样检验要满足基本的统计条件，也就是工序总体具有统计规律性。

（1）概率分布

在GUI软件的实际编程中，软件测试是先单元测试再集成测试，在“三步骤法”中，首先得对软件单元中的“Controls/Components”进行数据限定测试。此时的“Controls/Components”个数往往不很多，而正态分布抽样的样本经常要大于30。为此，不能直接利用正态分布的统计假设。

若把随机事件改成“每次抽检n个样本检验出现软件缺陷的可能”，便只有两种结果“不出现缺陷和出现缺陷”。此时便可构造出二项分布，并以此对数据限定测试作统计抽样处理。二项分布的概率分布是

二项分布的具体查表和计算这里不予赘述，可参考其他文献。

产品发布之前的软件测试和对外包的接收检验，此时的“Controls/Components”个数往往超出30，便可采用正态分布进行统计抽样。正态分布的概率分布是

正态分布的具体查表和计算这里也不予赘述，可参考其他文献。

（2）具体细节处理

这时还要做些具体处理：

• 将某一个程序员的“Controls/Components”作为研究总体；

• “Controls/Components”抽样可以是某一种类型全体，也可以是具有规定条件的某一种类型全体；

• 此程序员是熟练技能的，而不能是初学者；

• 对组织良好的团队，可以转换至编程小团体作为研究总体，譬如“Pair-wise”团队组织；

• 注意内控测试和接收测试要分别处理。内控测试主要针对内部开发，接收测试主要针对外包。

（3）抽样规则和办法

在传统的统计抽样中，一般要求α=0.05进行统计推断，此时的抽检不合格品率是5%。在软件开发中，虽“Controls/Components”可以看成“标准件”，但程序员在编程中要作“再加工”，这就难免失去了原有的统计规律性，因此有从严控制程序员编程过程影响因素的问题。再者，“Controls/Components”的“数据限定” — 边界值设置若出现缺陷，此缺陷一般都是严重缺陷，安全敏感软件系统则是重大或致命缺陷。因此有必要提升抽检不合格品率，一般软件可以提升至3%，安全敏感软件系统或条目一定不能允许有任何超差出现。也就是，一般软件100个输入控件允许3个有缺陷。一般的软件系统中，编辑框控件和组合框控件类的输入控件实际数量有50~100个，允许出现1.5~3个边界值设置缺陷，这并不算太严。

抽样规则：采用随机数发生器或抓阄生成随机数；二项分布每次抽取一件n0=1；正态分布内控测试用α=0.03，每次抽取n1；正态分布接收测试用α=0.05，每次抽取n2。

具体办法：

（a）单元测试或集成测试中的抽样检验

主要以“Pair-wise”模式进行交叉测试 — 全数检验，重点关键控制单元由独立测试员作抽样检验。

a. 一个程序员

抽取某一种相似类型的“Controls/Components”，依二项分布每次抽一个n0=1。若出现1个边界值缺陷，则不予通过。

b. 编程小团体

抽取某一种类型的“Controls/Components”，正态分布用α=0.03，抽样误差δ=0.125，取抽样数n1=27，最好每个程序员能抽一个。若出现1个边界值缺陷，则不予通过。

（b）产品发布之前的抽样检验和控制

由独立测试员作抽样检验。

将整个软件程序作为考察对象，抽取某一种类型的“Controls/Components”，正态分布用α=0.03，抽样误差δ=0.125，取抽样数n1=27，最好每个程序员能抽一个。若出现1个边界值缺陷，则不予通过。

（c）对外包的接收检验

由独立测试员作抽样检验。

可将整个软件程序作为考察对象，正态分布用α=0.05，抽样误差δ=0.125，取抽样数n2=22。既可抽取某一种类型的“Controls/Components”，也可抽取相似的“Controls/Components”，但每种类型须抽一个。若出现1个边界值缺陷，则不予通过。

2 GUI软件中输入控件的数据限定测试抽检

2.1 出错的主要原因

程序员在输入控件的实际编程中，数据限定出错的主要原因：

（1）忘记给出；

（2）给出错误。

2.2 一般要求和具体处理

（1）Checkbox控件、单选Button控件等两值选择控件

在微软可视化的IDE中，Checkbox控件、单选Button控件都是两值选择控件，它们的正确性和性能已由编程系统自身保证，其“上下限边界值”为“不选取”和“选取”不需要程序员进行设置。因此，在此类型控件多的场景，可针对这一类型采用抽样检验/测试，或者针对人员组织和编程系统条件好的场景，作免检处理。

（2）编辑框控件

在微软可视化的IDE中，编辑框控件有Edit Box和Rich Edit两种，它们的“上下限边界值”通过可视化方式进行设置，只是要注意区分数据类型。在实际应用软件中，编辑框控件是用得最多的输入控件，可以将编辑框控件独立或者和组合框控件等合并对边界值设置进行统计抽样检验/测试。

（3）组合框控件

相似地，在微软可视化的IDE中，组合框控件有ComBo Box和Extended ComBo Box两种，它们的“上下限边界值”通过可视化方式进行设置，并且它可以给出可供选择的具体基础数据。在实际应用软件中，组合框控件也是用得多的输入控件，可以将组合框控件独立或者和编辑框控件等合并对边界值设置进行统计抽样检验/测试。

2.3 实例— 单元测试或集成测试中的抽样检验

依据以上分析，输入控件的“数据限定” — 边界值设置若出现缺陷，此缺陷一般都是严重缺陷，安全敏感软件系统则是重大或致命缺陷。因此将一般软件中输入控件的“数据限定” — 边界值设置抽检不合格品率提升至3%。

在具体实施GUI软件边界值设置的统计抽样检验中，可首先是在单元测试的关键独立测试中进行，尤其在内控测试中。而此时一个“层单元”中，编辑框控件和组合框控件类的输入控件不会很多，一般不大于10。依据抽检不合格品率3%的要求，一个“层单元”中输入控件缺陷的允差是0.3，也就是不允许有1个出现边界值设置缺陷的。因此，在单元测试中，若对一般“层单元”输入控件的边界值设置由独立测试员进行统计抽样，一次抽样中不允许出现1个缺陷。

实例1质量控制软件PQMS2中的产品数据表单

图1是质量控制软件PQMS2中的产品数据表单/对话框，其中的输入控件包括7个编辑框控件和1个组合框控件，可安排数据限定测试-边界值设置的抽样检验；其他功能触发控件有4个，其功能测试和状态测试不宜运用抽样检验。在具体处理中，可分成两种情况：（1）时间不紧迫或程序员不值得信任只将编辑框控件这种类型作抽样检验，其测试用例设计见表1。（2）时间紧迫或程序员值得信任 — 将编辑框控件和组合框控件归为一个类作抽样检验，其测试用例设计也见表1。

图1 质量控制软件PQMS2中的产品数据表单

表 1 产品数据表单输入控件边界值设置抽样测试的测试用例

结果判定 — 若出现1个边界值缺陷，则不予通过。

实例2质量控制软件PQMS2中的检测工序数据表单

图2是质量控制软件PQMS2中的检测工序数据表单/对话框，其中的输入控件包括6个编辑框控件和3个组合框控件。抽样检验具体处理中，可也分成两种情况：（1）时间不紧迫或程序员不值得信任只将编辑框控件这种类型作抽样检验，其测试用例设计见表2。（2）时间紧迫或程序员值得信任 — 将编辑框控件和组合框控件归为一个类作抽样检验，其测试用例设计也见表2。

图2 质量控制软件PQMS2中的检测工序数据表单

表 2 检测工序数据表单输入控件边界值设置抽样测试的测试用例

结果判定 — 若出现1个边界值缺陷，则不予通过。