【转载】测试基础培训-测试方法运用、技巧与常见误区

1           常见故障分类

   通过对测试故障的分析，常见程序故障原因如下：

★    越界，包括数组下标越界，内存拷贝越界等等

★    变量定义类型不匹配，变量取值超出定义类型范围，造成上溢/下溢。

★    逻辑判断错误

★    函数调用错误，调用函数未处理返回值失败情况

★    指针、变量没有初始化

★    申请的内存不释放

★    异常处理错误

包括：非法输入不防范

         临界点、边界值处理出错

         过负荷未保护

         对误操作的保护

★ 可维护性错误，不能提供有效的告警、日志等记录供分析定位错误。

★ 界面错误

包括：提示信息错

         窗体标题错

         窗体或对话框显示不完整

         字体不符合要求

         按钮的大小、颜色

         快捷方式不起作用

         按钮功能无效

         下拉菜单或下拉框问题

         操作程序繁杂，不符合用户习惯。

 

2   运用白盒测试技术

白盒测试技术主要运用于单元/集成测试阶段。使用白盒测试技术可发现上面所列的很

多问题。使用白盒测试时，可针对以下问题进行测试。

 

函数调用接口测试清单：

1.  输入的形参数目是否等于实参的数目？

2.  实参和形参的属性是否匹配？

3.  实参和形参的单元系统是否匹配？

4.  传递给被调用模块的实参数目是否等于形参的数目？

5.  传递给被调用模块的实参属性是否等于形参的数目？

6.  传递给被调用模块的实参的单元系统是否等于形参的单元系统？

7.  传递给内置函数的数值属性和参数顺序是否正确？

8.  任何对参数的引用和当前入口点是否有关联？

9.  只输入的参数是否被改变了？

10．跨模块的全局变量定义是否一致？

11.    约束条件是否作为参数传递？

 

文件操作接口测试清单：

1.    文件属性是否正确？

2.    OPEN/CLOSE语句是否正确？

3.    格式规约是否和I/O语句匹配？

4.    缓冲区大小是否和记录大小匹配？

5.    文件是否在打开之前被使用？

6.    是否处理了文件结束条件？

7.    是否处理了I/O错误？

8.    在输出信息里是否有文本错误？

 

局部数据结构测试清单：

1.    是否有不正确或不一致的类型描述？

2.    是否存在错误的初始化或缺省值？

3.    是否有不正确的（包括拼写错误）变量名字？

4.    是否有不一致的数据类型？

5.    检查上溢、下溢和地址错误？

 

边界测试：

    边界测试是单元测试最后也是最重要的一个步骤，使用以下一组值来进行测试：

1.    略大于最小值

2.    略小于最大值

3.    等于边界值（最小值和最大值）

4.    大于最大值（异常测试）

5.    小于最小值（异常测试）

 

推荐技巧：

    用VC编译器，设立最高级别的编译选项来编译前台代码。

    对于C的代码，如果使用VC编译器，设置最高级别的编译选项进行编译，会有很多意外收获。因为我们使用的iRmx或pSos等编译器对于代码中不规范的地方的检查不是非常严格，很多比较危险的用法都检查不出来，对程序进行高级别的编译，编译器会自动列出相应的错误和告警，而这些都是可能导致错误的地方。

强调：

对于协议软件来说，白盒测试不仅仅包括代码的单元测试，也包括对协议要求的业务流程的研究，协议软件的程序控制结构是按照协议流程编写的，因此，详细研读协议，分析流程处理，根据协议要求与流程设置相应的测试点，也是一种白盒测试。

 

3   运用黑盒测试技术

黑盒测试强调程序实现的功能和用户需求的满足，而不注重程序内部实现，因此运用

黑盒测试时，了解系统的所有实现功能和用户需求是前提。

注意：黑盒测试时，了解系统不能实现的功能和了解能够实现的一样重要，因为问题

往往就发生在当功能不能实现时，系统出现异常甚至崩溃。如我们现在做的流量控制和过

负荷控制就是对系统在不能实现更大流量和负荷时的一种保护。

在黑盒测试时，应该考虑以下问题：

1．用户需要的功能是否可以实现？

2．用户使用这些功能的环境和条件？

另外：所有的异常都是可能的，多想想一些“不可能”的异常吧。

 

黑盒测试中的常用方法：逆向思维与边界值分析

所谓逆向思维就是凡事都从反面想一想，如果条件成立，程序是这样处理的，如果条件不成立呢？MSC和BSC之间局间信令要配成“BSC地面电路CCS7-SCCP”，如果不配成这个，选择其它选项呢？前后台链路正常时，处理正常，如果断链呢？正常情况下，消息交互时有应答消息，如果因为某种原因，应答消息丢失呢？程序启动时可能需要读一个文件，假如文件不存在呢？…… 总之，要养成逆向思维的习惯，任何条件都可以假设不成立。（不要去过多考虑现实情况中有没有这种逆向条件的可能）。

边界值分析是指对条件的极端情况的分析测试，如条件是一段数值，则对两端的极点的分析。需要指出的是，边界值分析并不仅仅限于一些数值条件，经常还包括一些隐含条件。如话单可以积压在MP上，条件之一是MP硬盘上有空间，如果MP硬盘空间满，无剩余空间呢？这也是一个边界点条件。

 

推荐技巧：

 经常看看别人填写的故障单，对自己会很有帮助。

根据Pareto原理，80％的故障源于20％的原因，所以经常看看别人报告的故障（包

括用服报告的故障），然后举一反三，这些根源导致的故障很可能在自己所测的模块里也存

在。

 

不是技巧的技巧：

    看看你所测的模块，它的开发者是谁？

这个技巧看上去有些势利，但是事实就是，没有经验的新手，出错的可能性就是大，

包括一些很低级的错误。所以对于新手做的东西，一定要采取不放心的心理测，甚至是一

些曾经改过的故障也有可能会重现。（当然，这并不是说有经验的开发人员不会出错，他们

只是错误少一些，往往这些错误也隐藏的深一些，所以基本上不要期望在他们那里发现一

些肤浅的错误。）

 

4               系统测试阶段的白盒技术运用

产品处于商用阶段时，多进行系统测试，而系统测试方法多为黑盒测试，但是，即使

大量使用黑盒技术，系统测试阶段适当运用白盒技术，往往能发掘一些隐藏较深的故障。

从GSM的产品现状来说，已经历经了多个版本的测试，运用黑盒测试技术，已经将系统

的很多功能流程，经由很多测试人员测了很多遍。一个个的测试人员测过，却仍然存在一

些“盲点”从没有人去覆盖，这些盲点就是一些异常情况下的处理，直到在网上运行时出

现问题才能得到改正。为什么？

    举个最近发生的例子：CAMEL业务我们在2000年5月就开始测试了，中间历经了4

拨人的测试，今年8月份在目标网升级后暴露了一个隐藏一年多的问题：主叫在释放时判

断CCF是否存在，而在主叫收到Disconnect消息之后，等待ReleaseComp之前，如果被叫

刚好也释放，就会将CCF清除，此时主叫在判断CCF不存在时，由于程序处理错误，未

将自身资源释放。这虽然是很异常的情况，但如果测试人员在测试时不仅仅是按照规范和

前人的测试规程来测，而是更注重于寻找前人遗漏的地方，采用白盒技术，寻找异常分支，

补充到测试规程中，应该成效更好一些。

所以说，在测成熟产品时，尤其要注意去挖掘一些异常分支，因为随着网上运用环境

的复杂，用户量的增多，出现异常的几率就越来越大。这时就需要回过头来再研究一下协

议流程和程序代码，然后想办法制造条件，让这些异常分支执行一遍。大多数时候，程序

运行的只是部分正常的流程，那些异常流程可能很多年都走不到，但是，如果一旦走到，

后果往往很严重。

经常采用逆向思维来寻找异常分支，比如说，如果if语句后面有一个条件判断，大多

数情况下，执行的条件为true，那么，就一定要让程序在条件为faulse的时候执行一遍。

再举个GPRS的例子：FR收到包后，判断是管理消息，调用HandleFrameRelayMessage函

数处理，该函数先调用GET_UB,然后判断管理消息的合法性，若不合法则返回。大多数情

况下管理消息都是合法的，正常黑盒测试可能很难发出非法的消息，此时，有意从BSC侧

向SGSN连续发错误的STATUS ENQUIRY（UI和协议鉴别语填错），间隔为1MS，长度约为100

字节，结果数秒钟后，就发现打印UB EMPTY。原来是在收到非法包时，程序在返回前未释

放UB，导致收到非法的STATUSENQUIRY后丢内存。

总之，用白盒方法去寻找平时不太容易走到的异常分支，结合黑盒方法去实现，经常

会发现一些比较严重的问题。

 

5   关于定位问题的方法

    有时在实验室发现可疑现象，但无从下手，这里介绍一种非常有效的方法：排除法。

很多问题不能从正面去定位，必须排除掉一切可能排除的原因，缩小问题范围。在排除时，常用的方法是用已知正确的部分替换怀疑部分。举个很小的例子，有时在测试时发

现放音有问题，那么有多种可能，一是硬件故障，音板有问题，二是装载的音不正确，版

本错误，也有可能是数据配置错误，当然最后，有可能是脚本错误或程序处理错误。在这

种情况下，首先是检查配置，有没有配音板？是否正确？然后检查装载的音文件是否正确？

再检查音板有没有问题？换一个音子单元呢？或者换一块音板呢？以上原因都排除，才将

问题的焦点集中到程序上。

总之，排除法非常有效，经常使用排除法是一种很好的定位问题的方式。

   

6   测试中的常见误区

测试中经常会陷于一些误区，这些不正确的心理和做法，往往导致问题从眼前溜过或

测试工作做不到点子上。

 

误区1：以开发人员的设计文档为测试依据。

    这是比较严重的一种现象，我们的新员工在接受培训时，往往从设计文档开始熟悉产

品，久而久之，这些文档就变成了“依据”和“标准”。当然，大多数情况下，这些设计文

档是没有问题的，但是对于测试人员来说，作为独立的第三方测试人员，测试依据应该是

标准协议和用户需求分析。系统部、开发部提供的文档仅仅是作为一种必不可少的熟悉产

品的渠道，而不是测试的依据。如果以设计文档为测试依据，那么当设计人员对协议和用

户需求理解有偏差时，我们的测试也就有偏差了。测试应该做确认工作（是否实现了正确

的产品），而不仅仅是验证工作（是否正确地实现了产品）。

例子：

这里一个典型的例子是短消息超级寻呼业务推出时，由于设计上的疏漏导致超级寻呼

的性能统计未做，而我们的测试人员在测试时仅仅依据设计文档，没有发现这个问题。

 

误区2：测试目标不明确或不符合用户需求，测试的优先级不清晰

有时候我们测试忙的要死，抓了一堆BUG，自我感觉很有成就感，开发人员改起来也是忙的要命，但是版本到投放使用时，却会出现一些不该发生的问题引起了用户的投诉。为什么？（当然测试是无法保证问题不存在的，但是应该保证将关键的问题降至最少）。因为虽然我们在测试时发现了很多错误，但也许相当部分并不是用户关心的问题。

当然，严格来说，不管是什么BUG，是大虫子还是小虫子，都是应该揪出来的。但是

当测试时间不充分时，千万注意：将测试时间留在用户关心的关键业务上。

所以说测试一定要测在点子上，特别是当测试时间紧迫时。也就是说，测试一定要目

标明确，并且符合用户需求！我希望每一位测试人员在开始测试之前，都能够问自己这两

个问题：

1．   我为什么要测这个新版本？为了满足用户哪些要求？

如果新版本仅仅是改错，那么很简单，是因为要修正错误。如果是添加了新功能，要

明确：为什么要加这些功能？什么地方的用户提出的？用户出于何种目的要求实现这些功

能？

2． 这个版本的测试重点是什么？是否真正满足了用户的需求？

无论负责哪一个模块的测试，都应该有一个重点。当测试时间不够充分时，要保证对

这些重点关键的部分进行充分测试。（对于软件来说，测试永远都没有结束的时间，对于测

试人员来说，测试结束时间就是市场需要，时间不够的时候）。另外，还要考虑，实现的功

能是否真正满足了用户的要求。

    测试目标的不明确，往往会导致工作没有重心，工作效率的降低。举几个例子。

例子1：

V2.0版本刚出来时，我们花了很多时间人力去测CUG、ECT业务，而忽视了放音的

测试，结果版本出现一些放音错误，串音、杂音等现象，导致用户投诉。而实际上，CUG、

ECT这些补充业务是很少使用的。

例子2：

短消息测试在这方面也很有体会。短消息版本测试时间一般都比较紧，每次都能发现

很多故障，而这些故障用户不一定关心，用户真正关心的，我们反而没测。

例子3：

302版本刚刚开始测的时候，我们的测试人员仍然按照212的测试规程去测版本，而

没有去了解为什么推出302版本？302版本与212版本的本质区别？结果导致一些很关键

的错误很晚才测出。

 

这些例子再次说明：要从用户的角度出发去明确测试目标，按照测试用户关心的程度

为优先级来安排测试，有利于版本快速稳定，更好地满足用户要求。

 

误区3：盲目相信开发人员的解释

    测试人员在发现故障现象时，听从开发人员的解释而不再仔细分析研究。

    当然，很多时候，开发人员的解释是对的，测试人员报告的故障现象属于误操作、误

配置等人为导致。但是，当听完开发人员的解释后，应该再仔细分析考虑一下，就算是错

误配置导致，是否应该有合理的避免方式，特别是没有协议标准的功能，一定要慎重考虑。

下面举几个例子说明这个问题：

例子1：

    测试部很早之前曾就欠费用户不能拨打免费号码填过一张故障单。但当时相关人

员解释为：欠费限制我们是采用ODBC方式实现的，而协议规定ODBC限制的用户就是

不能拨打免费号码。此故障作为无效故障返回。

但是今年就有吉林用户提出欠费用户要求可以拨打充值查询号码。

此问题的关键是：虽然协议规定ODBC用户不能拨打免费号码，但协议没有要求欠费

限制一定要以ODBC方式实现。所以当初开发人员的解释是有漏洞的。

例子2：

测试部在早期版本测试时曾经多次发现过机架运行不正常，7号信令链路经常起不来，

有时连DT都起不来，数据重传，MP复位，机框复位都不起作用，恢复的最后一招是整个

机架关电。

开发人员的解释是机房机架太破。

事实是外面开局，新发的机架也出现了这种情况。

例子3：

在测试2.0版本HLR批量鉴权与放号功能时，速度特别慢，好几秒才放一个号，并且

时常中断。当时开发人员的解释是服务器配置太差，在外面开局都是高档配置，不会有这

种情况。并且举例说明已在开局现场放过1万个号，没问题。当时测试人员找来了机房最

好配置的机器，并且将数据库建在磁盘阵列上，但是放号速度仍然没有任何改观。经过测

试人员和开发人员的共同努力，终于发现还是程序的问题，经过对执行脚本和触发器的优

化，批量放号速度提高了好几十倍，即使在低档机器上也能顺利进行。

例子4：

短消息测试中ESME的接入号测试，早期版本中支持以0开头的接入号，但在新版本中

不再支持，测试时也发现此问题，但开发人员解释说接入号不允许以0开头，这种接入号

不规范。结果新版本开局时发现在局方出现许多以0开头的ESME接入号，最后，只得修改

程序，重做版本。

例子5：

 还是一个短消息的例子，早期的版本短消息EMSE接入时，无论大小写均可以，但

随后的版本只支持大写的SME接入码，测试人员发现此问题，向相关人员反映，但均没

有得到回应。直至最近，许多地方不断反映此问题，才引起开发和系统的重视。

 

象这样的例子有很多，所以，正确的做法是，测试人员在听了开发人员的解释后，应

该动动脑筋，有协议依据的查一下协议，没有标准的要同其他测试人员、用服人员、系统

人员讨论一下，看看有没有市场需求。

 

误区4：没有恒心，轻易放弃

    测试一定需要恒心和耐心。机房环境复杂，有时候问题稍纵即逝，或者诸多现象掺杂

在一起，问题越弄越多。特别是有时环境不争气，怎么也折腾不好。这种情况下千万不能

放弃，理清思路，扩大视野，群策群力，一步步检查，往往柳暗花明又一村。

例子1：

在调试PCS测试环境时，出现了控制层和网络层可以正常运行，但DT层怎么也起不

来的现象。检查数据、检查版本、检查硬件连线，种种方法都尝试过了，折腾了好几天，

还是一筹莫展。但是我们的测试人员还是不放弃，最后找来相关项目经理、开发人员、测

试部有经验的老员工，各路专家一起“会诊”，终于发现，原来是一根连接COMM板和DSNI

板的线缆用错了型号，这是怎么也想不到的事情。

例子2：

在测试排队机部分的业务时，因为涉及到的东西很多，而且经常会有一些特殊的要求，

排队机部分又不是我们开发的，涉及到一些深层次的问题经常会难以解决（有时请求IN

产品现场技术支援还会有一定困难），此时，就得考验我们的恒心和解决问题的能力。

在测试上海中英文人工台时，业务加载后无论怎样折腾都没法正常放音，将前台数据

删除后重传，重启前台，重装CTI SERVER，业务卸载再加载，换音板，查数据配置等等方

法，均没有用，经过一天多的时间也没有找到问题之根结。最后考虑到排队机部分除了后

台服务器没有重新安装，其他部分均彻底重新装过，虽然后台服务器部分的程序与业务基

本没有相关性，而且在加载之前均正常，还是决定重新安装后台服务器，结果重新安装后，

配置数据没有任何变化，问题消失了！虽然问题之真正根源没有找到，但至少将测试中遇

到的环境问题解决掉，能够将测试继续下去，不会影响到产品正常的流程。

说明：关于环境的问题，如果问题出在我们的被测系统上，不能采取绕开的方式，一定要

找到根源，如果是对接设备，能找到原因的就找，出于时间原因考虑，可以只找解决方案。

在此希望不要引起误解。

 

 

 

 

 

 

 

 

 

 

参考资料：

GB/T 17544，idt ISO/IEC 12119 信息技术 软件包 质量要求和测试

GB/T 15532 计算机软件单元测试

GB 9386 计算机软件测试文件编制规范

《软件工程 实践者的研究方法》Roger S. Pressman

《编程规范》樊晓斌