|
|
| 评测中心 > 帮助与支持 > 技术文章 |
（转载）
一、软件质量保证同软件测试的区别
软件质量保证（Software Quality Assurance）:SQA介入于整个软件开发过程——监督和
改进过程，确认达成的标准和过程被正确的遵循，保证问题被发现和解决。它以预防
为主。
软件测试（Software Testing）:软件测试是在一定控制的条件下，围绕一个系统或应用
的操作并且评价其结果（一个最简单的例子：如果用户使用硬件A，在应用接口B上做
了操作C，那么结果D应当出现），控制的条件应当包括正常和异常的条件。测试企图
使事情变得很糟糕，从而来检测出一些应当发生而没有发生，或者不应当发生而发生
的事情。测试以检测为主。
*关于如何安排QA和测试的任务时，不同的组织变化是很大的。有时它们可以有一个
组或个人来负责，共同的是一个项目组混合了测试人员和开发人员，并且他们一起紧
密的工作，而QA过程有项目经理来监督。所有这些是同组织的大小和商业结构有关
的。
二、软件中存在错误的来源
1、缺乏或者没有进行沟通，如对于一些我们应用程序中应当或者不应当实现的细节问
题。
2、软件复杂度——在当今的软件开发中，对于一些没有经验的人来说，软件复杂性
可能是难以理解的。图形化界面，客户/服务器和分布式的应用，数据通信，大规模的
关系数据库，应用程序的规模等指数般的增加了软件的复杂度。面向对象技术也有可
能增加软件复杂度，除非能够被很好的工程化。
3、编程错误——任何一个编程人员都可能产生错误。
4、不断变更的需求——用户可能不知道变更的影响，或者知道影响却还是需要进行
变更，这些会引起重新设计，工程的重新安排，对其它项目的影响，已完成的工作可
能不得不重做或推翻，硬件需求可能也会受到影响。如果存在许多小的变更或者任何
大的改动，由于项目中不同部分间可知和不可知的依赖关系，这样就会产生问题，跟
踪变更的复杂性也可能引入错误。项目开发人员的积极性也会受到打击。在一些快速
变化的商业环境下，不断变更的需求可能是一种残酷的事实。在这种情况下，管理人
员必须了解结果的风险，QA工程师和测试工程师必须适应和计划进行大规模的测试来
防止不可避免的BUG出现无法控制的局面。
5、时间的压力——软件项目的时间安排是最难的，通常是需要很多猜测的工作。当最
后期限来临的时候，错误也就伴随发生了。
6、人员的自大——我们经常会发现人们普遍喜欢说：
“没问题”
“很简单”
“我可以在几小时内解决那个问题”
“修改那些老代码应当是很简单的”
而不是说：
“那会增加很多复杂性，可能会导致很多错误”
“如果我们要做那个的话，我们将无能为力”
“我无法估计可能要多长时间，除非我能进一步进行观察和研究”
“我们无法搞清楚那些混乱的代码到底在做什么事情”
如果存在太多的“没问题”的话，问题也就产生了。
7、缺乏文档的代码——维护和修改很差的代码或缺乏文档的代码是很困难的。最终
结果将导致BUG的出现。
8、软件开发工具——视图工具，类库，编译器，脚本工具等等通常会把它们自身的
BUG 引入到你的项目中。
三、有哪些测试
1、黑盒测试——不是基于内部代码和设计的知识，而是基于需求和功能。
2、白盒测试——基于应用程序的内部逻辑的知识，通过语句，分支，路径和条件的
覆盖率。
3、单元测试——测试中的最小单位，测试特殊的功能或代码模块。由于需要对内部
代码和设计的详细知识，该测试一般由开发者完成而不是由测试人员完成。该测试的
容易程度同代码设计的好坏直接相关。
4、增量型的集成测试——随着新功能的增加，不断的对应用程序进行测试。在程序
的所有部分完成之前，需要一个应用程序的各个部分之间能够相对独立的进行工作。
这类型测试可以有开发者或测试者完成
5、集成测试——测试应用程序结合的部分来确定它们的功能结合到一起是正确的。
在这里‘部分’的概念可能是代码模块，独立的应用程序，在网络上的客户端和服务
器断程序等等。这类型测试典型的是于客户/服务器和分布式系统相关。
6、功能测试——是一种黑盒测试，同应用程序的功能需求紧密相关。这类型测试应
当有测试人员来完成。这并不意味着开发人员在发布版本之前就不需要检查他们的代
码。
7、端到端测试——同系统测试类似，包括模拟现实世界对一个完整的应用环境进行
测试。例如同数据库进行交互、使用网络通信，或者其他的软件、硬件和系统进行交
互。
8、理智测试——这是一种典型的原始测试，其目的是要确定一个新的软件版本在一
些主要的测试努力下表现的足够好并且可以接受。例如：如果一个新软件每五分钟当
机一次，使系统执行速度极其缓慢，或者破坏系统数据，那么该软件就处于不够‘理
智’状态，必须保证在当前状态下进行进一步测试。
9、回归测试——在软件或环境被修改后进行的再测试。可能很难确定我们需要进行
多少的再测试，尤其接近到开发过程的末期。自动测试工具可能会有很大的帮助。
10、可接受性测试——基于最终用户的规格进行的最后测试。或者基于最终用户在一
定的时间范围内的测试。
11、负荷测试——在高负荷条件下进行的测试。
12、压力测试——该术语通常同负荷测试和性能测试是可交换的。也可用于描述这样
一些测试，
如：在不正常的负荷状态下，过分的重复某些动作或输入情况下进行的系统功能测
试。
13、性能测试——该术语通常同负荷测试和压力测试是可交换的。理想的性能测试是
定义在需求文档或QA测试计划中的。
14、安装和反安装测试——测试完全、部分或升级的安装/反安装过程
15、恢复测试——测试当出现崩溃，硬件错误或其他灾难性问题时，系统的表现情况
16、安全性测试——测试系统对于内部和外部非法入侵、故意损坏时的表现情况。可
能需要复杂的测试技术。
17、兼容性测试——测试系统在不同的平台/硬件/操作系统/网络上的表现情况。
18、ALPHA测试——在开发进行结束的时候进行的测试。针对测试的结果可能还会进
行一些小的设计更改。这类测试典型的是由用户进行的，而不是由开发者或测试人员
进行的。
19、BETA测试——在开发和测试已经全部结束后，并且在最终版本发布之前进行的
测试。这类测试典型的是由用户进行的，而不是由开发者或测试人员进行的。
四、开发和执行软件测试需要哪些步骤
1、获取需求、功能设计、详细设计规格和其它必须文档
2、获取预算和时间安排需求
3、确定项目相关人员和他们的责任，汇报需求，必须的标准和过程（如版本过
程、变更过程等）
4、确认应用高风险的部分，设定优先级，确定测试的范围和限制
5、确定测试的方法——单元测试、集成测试、功能测试、负荷测试、可用性测
试等
6、确定环境需求（软件/硬件/通信等）
7、确定测试用具环境（记录/回放工具、覆盖率分析器、测试跟踪、问题跟踪等
等）
8、确定测试输入需求
9、确定任务，任务责任和相应的工作量
10、设定时间安排估计、时间表、里程碑等
11、确定输入的等价类、边界值分析、错误类
12、准备测试计划文档和需要的评审
13、写测试用例
14、对测试用例进行必须的评审
15、准备测试环境和测试用具，获取需要的用户手册/参考文档/配置指导/安装
指导，建立跟踪过程，日志和存档过程，获取测试数据
16、获取和安装软件版本
17、执行测试
18、评价和汇报测试结果
19、跟踪问题和修改
20、如果需要进行再测试
21、在整个生命周期内维护和修改测试计划、测试用例、测试环境和测试用具
五、什么是测试计划
测试计划是描述软件测试努力的目标、范围、方法和焦点的文档。准备测试计
划的过程是完整考虑软件产品可接受评价努力的一个有用的方法。完整的文档
将有助于测试组之外的人理解为什么要进行软件正确性检测，并且如何进行检
测。测试计划应当足够完整但也不应当太详尽，以致在测试组之外没有人会读
它。下面是一些可能会包含在测试计划中的一些内容，依赖于特定的项目：
1、标题
2、确定软件的版本号
3、修订文档历史，包括作者、日期和批示
4、目录表
5、文档的目的和适合的读者群
6、测试的目的
7、软件产品概述
8、相关文档列表，例如：需求、设计文档、其他测试计划等
9、相关的标准或合法需求
10、可跟踪性需求
11、相关的命名规范和标识符规范
12、整个软件项目组织和人员/联系信息/责任
13、测试组织和人员/联系信息/责任
14、假设和依赖关系
15、项目风险信息
16、测试优先级和焦点
17、测试范围和限制
19、测试提纲——对测试过程的一个分解，通过测试类型、特点、功能性、过
程、系统、模块等
20、测试环境设置和配置问题
21、数据库设置需求
22、概述系统日志/错误日志/其他性能，有助于描述和汇报问题的屏幕捕获工具
等
23、有助于测试者跟踪问题根源的具体软硬件工具的论述
24、测试自动化的可能性和概述
25、使用的测试工具，包括版本、补丁等
26、使用的项目测试度量
27、报告需求和测试可传递性
28、软件入口和出口准则
29、初始的理性测试阶段和标准
30、测试终止和重新开始的标准
31、人员安排
32、测试地点
33、用到的测试外的组织，他们的目的、责任、可传递性、联系人和协作问题
34、相关的财产、分类、安全性和许可证问题
35、公开的一些问题
36、附录——词汇表、缩略语等
六、什么是测试用例
1、一个测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目
的是确定应用程序的某个特性是否正常的工作。一个测试用例应当有完整的信息，
如：测试用例ID号，测试用例名字，测试用例的目的，测试条件、输入数据需求、步
骤和期望结果。
2、注意开发测试用例的过程有助于在应用的需求和设计中发现问题。这主要是由于是
需要完整的考虑应用的整个操作。正因为这样，需要在开发的早期准备测试用例。
七、制定测试计划时应考虑哪些因素
应明确的在测试计划中确立好"测试管理机制"的关键事件,如:
1>.汇报机制确定好用周报制度还是日报制度，日报的反馈速度快，定位解决问
题快,但信息处理工作量大;
2>.例会制度,每周举行一次例会，根据实际情况，考虑测试计划的调整或滚动;
3>.实施怎样的实验室管理制度，以做到责任明确;
4>.在日报中的工作汇报：不仅是发现的问题，还应包括在测试时新创造的测试
点，这些测试点应该补充到测试计划中作为一个测试项
5>.人员情绪如何调整，在测试周期过长时，影响测试效率的一个重要因素是测
试人员的情绪，一个人反复测试一个模块，总是会出现厌倦情绪的。具体怎么调整？
是一个有待讨论的问题。
应明确的在测试计划中确立"数据"的管理和分析体系和办法,如:
专人对提交的过程文档,周报报告中的数据予以整理和管理，以便后期在系统测
试评审时作为数据来分析。
现在往往是在系统测试结束后才来收集数据，可能会造成数据的不同程度失真或滞
后。收集的数据可以按不同种类来划分。这可以依赖我们系统CHECKLIST。有一种工
具叫 SRES (软件可靠性专家系统) 还是很有用的，我们可以按照它的输入数据来收
集。
应明确的在测试计划中确立"风险估计"的引入,如:
制定测试计划时,就应该考虑好对系统测试工作量的估计，测试成本的估计,版本
市场定位的估计等等,并且必要时可根据实际情况进行裁剪或补充
七、一些测试方法
1、划分等价类
把所有可能的输入数据划分成若干部分，然后从每一部分中选择少数有代表性的数据
作为测试用例。
（1）有效等价类：对于程序的规格说明来说，是合理、有意义的输入数据构成的集
合。利用这一类测试用例检验程序是否实现了规格说明预先规定的功能和性能。
（2）无效等价类： 对于程序的规格说明来说，是不合理、无意义的输入数据构成的
集合。利用这一类测试用例检验程序的冗错能力。
2、边界值分析
边界值分析方法是对等价类划分方法的补充。根据测试经验，大量的错误发生在输入
或输出范围的边界上，而不是某个范围的内部。
与等价类划分方法的区别：边界值也可能包含在有效等价类中。
3、语句覆盖
设计若干个测试用例，运行所测程序，使得每一可执行语句至少执行一次。语句覆盖
是最弱的逻辑覆盖准则。
IF (( A > 1) AND ( B = 0 ))THEN
X = X / A
IF (( A = 2) OR ( X > 1 ) THEN
X = X + 1
其中“AND”和“OR”是两个逻辑运算符。图6给出了它的流程图。a、b、c、
d和e是控制流上的若干程序点。
语句覆盖的含意是，在测试时，首先设计若干个测试用例，然后运行被测程序，
使程序中的每个可执行语句至少执行一次。这时所谓“若干个”，自然是越少越好。
在上述程序段中，我们如果选用的测试用例是：
A = 2
B = 0 ………………CASE1
X = 3
则程序按路径ace执行。这样该程序段的4个语句均得到执行，从而作到了语句覆
盖。但如果选用的测试用例是：
A = 2
B = 1 ………………CASE2
X = 3
程序按路径abe执行，便未能达到语句覆盖。
从程序中每个语句都得到执行这一点来看，语句覆盖的方法似乎能够比较全面地
检验每一个语句。但它也绝不是完美无缺的。假如这一程序段中两个判断的逻辑运算
有问题，例如，第一个判断的运算符“AND”错成运算符“OR”或是第二个判断中的
运算符“OR”错成了运算符“AND”。这时仍使用上述前一个测试用例CASE1，程序
仍将按路径ace执行。这说明虽然也作到了语句覆盖，却发现不了判断中逻辑运算的错
误。
二、判定覆盖
按判定覆盖准则进行测试是指，设计若干测试用例，运行被侧程序，使得程序中
每个判断的取真分支和取假分支至少经历一次，即判断的真假值均曾被满足。判定覆
盖又称为分支覆盖。
仍以上述程序段为例，若选用的两组测试用例是：
A = 2
B = 0 ………………CASE1
X = 3
A = 1
B = 0 ………………CASE3
X = 1
则可分别执行路径ace和abd，从而使两个判断的4个分支c、e和b、d分别得到覆
盖。
当然，我们也可以选用另外两组测试用例：
A = 3
B = 0 ………………CASE4
X = 3
A = 2
B = 1 ………………CASE5
X = 1
分别路径acd及abe，同样也可覆盖4个分支。
我们注意到，上述两组测试用例不仅满足了判定覆盖，同时还做到语句覆盖。从
这一点看似乎判定覆盖比语句覆盖更强一些，但让我们设想，在此程序段中的第2个判
断条件X>1如果错写成X<1，使用上述测试用例CASE5，照样能按原路径执行（abe
），而不影响结果。这个事实说明，只作到判定覆盖仍无法确定判断内部条件的错
误。因此，需要有更强的逻辑覆盖准则去检验判断内的条件。
以上仅考虑了两出口的判断，我们还应把判定覆盖准则扩充到多出口判断（如
CASE语句）的情况。
三、条件覆盖
条件覆盖是指，设计若干测试用例，执行被测程序以后，要使每个判断中每个条
件的可能取值至少满足一次。
在上述程序段中，第一个判断应考虑到：
A＞1，取真值，记为T1
A ＞1，取假值，即A≤1，记为F1
B = 0，取真值，记为T2
B = 0，取假值，即B≠0，记为F2
第2个判断应考虑到：
A = 2，取真值，记为T3
A = 2，取假值，即A≠2，记为F3
X＞1，取真值，记为T4
X＞1，取假值，即X≤1，记为F4
我们给出3个测试用例：CASE6，CASE7，CASE8，执行该程序段所走路径及覆
盖条件是：
测试用例ABX 所走路径覆盖条件
从这个表中可以看到，3个测试用例把4个条件的8种情况均作了覆盖。
进一步分析上表，覆盖了4个条件的8种情况的同时，把两个判断的4个分支b、c、
d和e似乎也被覆盖。这样我们是否可以说，做到了条件覆盖，也就必然实现了判定覆
盖呢？让我们来分析另一情况，假定选用两组测试用例是CASE 9和CASE 8，执行程序
段的覆盖情况是：
测试用例A B X 所走路径覆盖分支覆盖条件
这一覆盖情况表明，覆盖了条件的测试用例不一定覆盖了分支。事实上，它只覆
盖了4个分支中的两个。为解决这一矛盾，需要对条件和分支兼顾。
四、判定-条件覆盖
判定-条件覆盖要求设计足够的测试用例，使得判断中每个条件的所有可能至少出
现一次，并且每个判断本身的判定结果也至少出现一次。
例中两个判断各包含两个条件，这4个条件在两个判断中可能有8种组合，它们
是：
① A 〉1，B ＝ 0 记为 T1，T2
② A 〉1，B ≠ 0 记为 T1，F2
③ A ≤1，B ＝ 0 记为 F1，T2
④ A ≤1，B ≠ 0 记为 F1，F2
⑤ A ＝2，X 〉 1 记为 T3，T4
⑥ A ＝2，X ≤ 1 记为 T3，F4
⑦ A ≠2，X 〉 1 记为 F3，T4
⑧ A ≠2，X ≤ 1 记为 F3，F4
这里设计了4个测试用例，用以覆盖上述8种条件组合：
测试用例ABX 覆盖组合号所走路径覆盖条件
我们注意到，这一程序段共有四条路径。以上4个测试用例固然覆盖了条件组合，
同时也覆盖了4个分支，但仅覆盖了3条路径，却漏掉了路径acd。前面讨论的多种覆盖
准则，有的虽提到了所走路径问题，但尚未涉及到路径的覆盖，而路径能否全面覆盖
在软件测试中是个重要问题，因为程序要取得正确的结果，就必须消除遇到的各种障
碍，沿着特定的路径顺利执行。如果程序中的每一条路径都得到考验，才能说程序受
到了全面检验。
五、路径覆盖
按路径覆盖要求进行测试是指，设计足够多测试用例，要求覆盖程序中所有可能
的路径。
针对例中的4条可能路径
ace 记为 L1
abd 记为 L2
abe 记为 L3
acd 记为 L4
我们给出4个测试用例：CASE 1，CASE 7，CASE 8和CASE 11，使其分别覆盖这
4条径：
这里所用的程序段非常简短，也只有4条路径。但在实际问题中，一个不太复杂的
程序，其路径数都是一个庞大的数字，要在测试中覆盖这样多的路径是无法实现的。
为解决这一难题只得把覆盖的路径数压缩到一定限度内，例如，程序中的循环体只执
行了一次。
其实，即使对于路径数很有限的程序已经作到了路径覆盖，仍然不能保证被测程
序的正确性。例如，在上述语句覆盖一段最后给出的程序段中出现的错误也不是路径
覆盖可以发现的。
由此看出，各种结构测试方法都不能保证程序的正确性。这一严酷的事实对热心
测试的程序人员似乎是一个严重的打击。但要记住，测试的目的并非要证明程序的正
确性，而是要尽可能找出程序中的错误。确实并不存在一种十全十美的测试方法，能
够发现所有的错误。想要撒下几网把湖中的鱼全都捕上来是作不到的，软件测试是有
局限性的。
|
 |
|
