-
第1帖【2004-5-10】:软件测试的理想模式是什么?(转)
2007-07-30 15:40:46
Brian Marick:我不认为存在什么理想模式。我觉得让开发人员承担某些测试也许会更加有效,而其他测试则由独立测试组来进行。因为如果你把所有测试都交给独立测试组,他们不可能有时间把所有测试都做好。所以,最佳的方式是让开发人员承担一定量的测试,独立测试组给予他们支持。独立测试组主要承担整个系统的测试,去寻找开发人员还没有发现的缺陷,如子系统间的交互、运行条件、内存使用等。
如何更有效地开展系统测试呢?让测试人员在项目初期就参与进去,让他们看到第一版的系统需求、用户手册和系统原型,在系统实现前就对需求进行捕获和跟踪。在该过程中,他们从这些文档构造最初的测试设计。这也可以通过检视或评审的形式进行,并且在该过程中会发现一些缺陷。大家都知道,这个阶段,问题发现是非常“便宜”的。
这样,系统测试工程师在项目早期就介入,产生测试设计及基本的需要测试的项目列表。这时不可能产生一个绝对完备的测试设计,因为书写完整测试的条件还不成熟,但这却是构建完整测试的基础。
注:Brian Marick是Reliability Software公司的专职测试技术顾问。 -
第3贴【2004-5-12】:测试的基本原则(转)
2007-07-30 15:36:14
(美)Roger S. Pressman
在设计有效测试用例之前,测试工程师必需理解软件测试的基本原则。这里有一组测试原则:
1、所有的测试都应追溯到用户需求。正如我们所知:软件测试的目标在于揭示错误。而最严重的错误(从用户角度来看)是那些导致程序无法满足需求的错误。
2、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始,详细的测试用例定义可以在设计模型被确定后立即开始。因此,所有测试应该在任何代码被产生前就进行计划和设计。
3、Pareto原则应用于软件测试。简单地讲,Pareto原则暗示着测试发现的错误中的80%很可能起源于程序模块中的20%。当然,问题在于如何孤立这些有疑点的模块并进行彻底的测试。
4、测试应从“小规模”开始,逐步转向“大规模”。最初的测试通常把焦点放在单个程序模块上,进一步测试的焦点则转向在集成的模块簇中寻找错误,最后在整个系统中寻找错误。
5、穷举测试是不可能的。即使是一个大小适度的程序,其路径排列的数量也非常大。因此,在测试中不可能运行路径的每一种组合。然而,充分覆盖程序逻辑,并确保程序设计中使用的所有条件是有可能的。
6、为了达到最佳效果,应该由独立的第三方来构造测试。“最佳效果”指最有可能发现错误的测试(测试的主要目标),所以创建系统的软件工程师并不是构造软件测试的最佳人选。 -
第2帖【2004-5-11】:测试经理角色定位(转)
2007-07-30 15:34:46
为了自己学习方便 转帖于此
Johanna Rothman:
测试经理服务于两种完全不同的客户:测试工程师和高层管理者。对于测试工程师,测试经理帮助他们开发产品测试策略,积累产品测试经验并在测试组内充分共享。对于高层管理者,测试经理搜集尽可能全面的产品信息,供其就产品是否可以发布进行决策。但是有一点是相同的:无论是对于测试工程师还是高层管理者,测试经理将帮助其定义和校验产品发布标准。
产品发布标准的定义和校验:作为一个测试经理,应该找机会与市场、开发人员商讨产品发布标准,并根据客户的反馈对该标准进行修正和校验。开发部门的工作是如何达到公司对产品的期望,要用客户需求为开发人员勾画出客户眼中的产品以及产品应如何工作。一旦产品被清楚地定义,就可以通过测试去验证产品在多大程度上满足了客户需求。
对于测试工程师而言有一点非常重要:将测试任务按优先级划分,使产品发布标准得以满足。由于只有极少数的项目有充足的时间去完成所有事情,所以告诉测试工程师关于“测什么和何时测”测试经理的一个重要职责。
高层管理者需要充分理解产品发布标准,以决定产品是否可以按时发布。我不认为测试组有权利裁决产品是否应该被发布,该权利在组织高层管理者那里。在有了一个通过讨论、达成一致的产品发布标准后,项目组也可以更清楚地了解和认识产品质量。待续..........
-
软件测试分类
2007-07-26 09:35:46
软件测试是一项复杂的系统工程,从不同的角度考虑可以有不同的划分方法,对测试进行分类是为了更好的明确测试的过程,了解测试究竟要完成哪些工作,尽量做到全面测试。
1,按是否需要执行被测软件的角度
按是否需要执行被测软件的角度,可分为静态测试和动态测试,前者不利用计算机运行待测程序而应用其他手段实现测试目的,如代码审核。(我认为主要是让测试人员对编译器发现不了的潜在错误进行分析,如无效的死循环,多余的变量等),而动态测试则通过运行被测试软件来达到目的。
2、按阶段划分:
1 单元测试
单元测试是对软件中的基本组成单位进行的测试,如一个模块、一个过程等等。它是软件动态测试的最基本的部分,也是最重要的部分之一,其目的是检验软件基本组成单位的正确性。因为单元测试需要知道内部程序设计和编码的细节知识,一般应由程序员而非测试员来完成,往往需要开发测试驱动模块和桩模块来辅助完成单元测试。因此应用系统有一个设计很好的体系结构就显得尤为重要。
一个软件单元的正确性是相对于该单元的规约而言的。因此,单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。
2 集成测试
集成测试是在软件系统集成过程中所进行的测试,其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划,一边将模块或其他软件单位组合成越来越大的系统,一边运行该系统,以分析所组成的系统是否正确,各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。
3 系统测试
系统测试是对已经集成好的软件系统进行彻底的测试,以验证软件系统的正确性和性能等满足其规约所指定的要求,检查软件的行为和输出是否正确并非一项简单的任务,它被称为测试的“先知者问题”。因此,系统测试应该按照测试计划进行,其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多,主要有功能测试、性能测试、随机测试等等。
4 验收测试
验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是,验收测试常常有软件系统的购买者代表在现场,甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。
5 回归测试
回归测试是在软件维护阶段,对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里,修改的正确性有两重含义:一是所作的修改达到了预定目的,如错误得到改正,能够适应新的运行环境等等;二是不影响软件的其他功能的正确性。
6 Alpha 测试:在系统开发接近完成时对应用系统的测试;测试后,仍然会有少量的设计变更。这种测试一般由最终用户或其他人员员完成,不能由程序员或测试员完成。
7 Beta 测试:当开发和测试根本完成时所做的测试,而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成,不能由程序员或测试员完成。
3、按测试方法划分:
1 白盒测试
白盒测试也称结构测试或逻辑驱动测试,是指基于一个应用代码的内部逻辑知识,即基于覆盖全部代码、分支、路径、条件的测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。
“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。第二,穷举路径测试不可能查出程序中因遗漏路径而出错。第三,穷举路径测试可能发现不了一些与数据相关的错误。
白盒测试可以借助一些工具来完成如Junit Framework,Jtest等。
2 黑盒测试
黑盒测试是指不基于内部设计和代码的任何知识,而基于需求和功能性的测试,黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等,主要用于软件确认测试。
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。
黑盒测试也可以借助一些工具,如WinRunner,QuickTestPro,Rational Robot等。
3 ALAC(Act-like-a-customer)测试
ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。ALAC测试是基于复杂的软件产品有许多错误的原则。最大的受益者是用户,缺陷查找和改正将针对哪些客户最容易遇到的错误。 -
关于人工测试一点知识
2007-07-19 17:00:33
测试领域里的一个与机器测试相当重要,且在机器测试之前进行,也与之相辅相成的技术,即:人工测试技术。该技术共涉及四种方法:代码检查、代码走查、桌面检查、同行评审;其更着重详细讲述的是第一个方法。同时,作者在开章也提到一种错误认识:人工测试技术由于包含了人为因素在内,导致很多方法的正规性要差于由计算机执行的数学证明,所以人们可能会怀疑某些如此简单和不正规的东西是否有用。反之亦然。就个人经历而言,确实这种认知普遍存在,并且对人工测试技术没有给予足够的重视。文尾,有必要记叙一下,人工测试技术的重要性。它会在两个方面显著地提高软件测试的功效和可靠性。- 错误发现得越早,改正错误的成本越低,正确改正错误的可能性也越大;
- 程序员在开始基于计算机的测试时似乎要经历一个心理上的改变。压力会急剧增长,且要“尽可能快地修正这个缺陷”。由于这些,所以,程序员在改正某个基于计算机测试发现的错误时所犯的失误,可能要比改正早期发现的问题时所犯的失误会更多一些的。
-
自动化测试的优缺点
2007-07-19 16:17:37
自动化测试的优点:
1、对程序的回归测试更方便。这可能是自动化测试最主要的任务,特别是在程序修改比较频繁时,效果是非常明显的。由于回归测试的动作和用例是完全设计好的,测试期望的结果也是完全可以预料的,将回归测试自动运行,可以极大提高测试效率,缩短回归测试时间。
2、可以运行更多更繁琐的测试。自动化的一个明显的好处是可以在较少的时间内运行更多的测试。
3、可以执行一些手工测试困难或不可能进行的测试。比如,对于大量用户的测试,不可能同时让足够多的测试人员同时进行测试,但是却可以通过自动化测试模拟同时有许多用户,从而达到测试的目的。
4、更好地利用资源。将繁琐的任务自动化,可以提高准确性和测试人员的积极性,将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试,仅适合于手工测试,将可自动测试的测试自动化后,可以让测试人员专注于手工测试部分,提高手工测试的效率。
5、测试具有一致性和可重复性。由于测试是自动执行的,每次测试的结果和执行的内容的一致性是可以得到保障的,从而达到测试的可重复的效果。
6、测试的复用性。由于自动测试通常采用脚本技术,这样就有可能只需要做少量的甚至不做修改,实现在不同的测试过程中使用相同的用例。
7、增加软件信任度。由于测试是自动执行的,所以不存在执行过程中的疏忽和错误,完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后,软件的信任度自然会增加。
当然,自动化测试不是万能的,他不能完全替代手工测试。在软件版本还没有稳定的情况下,千万不要开展自动化测试,否则是自讨苦吃。自动化测试的缺点:
1、不能取代手工测试
2、手工测试比自动测试发现的缺陷更多
3、对测试质量的依赖性极大
4、测试自动化不能提高有效性
5、测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱,所以维护会受到限制,从而制约软件的开发。
7、工具本身并无想像力出处:bbs.51testing.com -
自动测试的投入与产出
2007-07-19 16:13:35
自动测试在测试领域里面是个比较热门的话题。同行们见面就问:“你们公司是手动测试还是自动测试啊?”“我们当然用自动化测试工具啊,现在谁还用手动啊?WinRunner和LoadRunner听过没有?嘎强大的!”“哦,不错啊! 我们大部分还是用手动的!只是目前在自学RFT。”“RFT啥玩意啊?没听说过,肯定不好用的!”“RFT没听说过啊?就是IBM公司的Ration Function Tester啊!以前叫XDE,现在简称RFT啦!scrīpt都是用JAVA写的,不是一般的强大啊!还能支持Linux!”心想,你们的xxxRunner行嘛?!“还是你们牛!”说道这,突然想到一个广告词:“...谁用谁知道!”自动化测试的投入和产出真的是应了这局话,谁用谁知道!眼前大伙儿们正一窝蜂的追求自动化测试,但是有多少人会真正想过,我们投入到自动测试的人力、物力、时间会不会得到应有回报?它的存在会给整个测试项目带来多少产出和额外价值?不可否认自动测试在某些测试阶段极大程度得减轻了工作量,同时还节省了时间。但是不是每个测试阶段都适合用自动化测试。而在大的投入之后,如何才能将其价值发挥到极至是不得不认真思考的问题。自动化测试是测试与开发相结合的一个项目。它不仅要求tester有一定的开发经验,最重要的是设计的测试用例有很强的灵活性、可重用性和可移植性。在项目伊始,就要有严格的设计和完备的文档说明。所谓打好基础才能盖出好楼,为了阶段性的产出而忽略基础的设计是不可取的。所以说啦,自动化测试是个比较新的技术、也有很好的发展前景,但是千万得弄清楚它试用在哪些测试阶段,毕竟它不是万金油。也不要只在乎它的阶段性产出,设计非常重要。否则它只是一块遮羞布而已。 -
软件测试术语!摘抄!
2007-07-19 16:07:42
Acceptance Testing--可接受性测试
一般由用户/客户进行的确认是否可以接受一个产品的验证性测试。actual outcome--实际结果
被测对象在特定的条件下实际产生的结果。Ad Hoc Testing--随机测试
测试人员通过随机的尝试系统的功能,试图使系统中断。algorithm--算法
(1)一个定义好的有限规则集,用于在有限步骤内解决一个问题;(2)执行一个特定任务的任何操作序列。algorithm analysis--算法分析
一个软件的验证确认任务,用于保证选择的算法是正确的、合适的和稳定的,并且满足所有精确性、规模和时间方面的要求。Alpha Testing--Alpha测试
由选定的用户进行的产品早期性测试。这个测试一般在可控制的环境下进行的。analysis--分析
(1)分解到一些原子部分或基本原则,以便确定整体的特性;(2)一个推理的过程,显示一个特定的结果是假设前提的结果;(3)一个问题的方法研究,并且问题被分解为一些小的相关单元作进一步详细研究。anomaly--异常
在文档或软件操作中观察到的任何与期望违背的结果。application software--应用软件
满足特定需要的软件。architecture--构架
一个系统或组件的组织结构。ASQ--自动化软件质量(Automated Software Quality)
使用软件工具来提高软件的质量。assertion--断言
指定一个程序必须已经存在的状态的一个逻辑表达式,或者一组程序变量在程序执行期间的某个点上必须满足的条件。assertion checking--断言检查
用户在程序中嵌入的断言的检查。audit--审计
一个或一组工作产品的独立检查以评价与规格、标准、契约或其它准则的符合程度。audit trail--审计跟踪
系统审计活动的一个时间记录。Automated Testing--自动化测试
使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试中用得较多。Backus-Naur Form--BNF范式
一种分析语言,用于形式化描述语言的语法baseline--基线
一个已经被正式评审和批准的规格或产品,它作为进一步开发的一个基础,并且必须通过正式的变更流程来变更。Basic Block--基本块
一个或多个顺序的可执行语句块,不包含任何分支语句。basis test set--基本测试集
根据代码逻辑引出来的一个测试用例集合,它保证能获得100%的分支覆盖。behaviour--行为
对于一个系统的一个函数的输入和预置条件组合以及需要的反应。一个函数的所有规格包含一个或多个行为。benchmark--标杆/指标/基准
一个标准,根据该标准可以进行度量或比较。Beta Testing--Beta测试
在客户场地,由客户进行的对产品预发布版本的测试。这个测试一般是不可控的。big-bang testing--大锤测试/一次性集成测试
非渐增式集成测试的一种策略,测试的时候把所有系统的组件一次性组合成系统进行测试。Black Box Testing--黑盒测试
根据软件的规格对软件进行的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。bottom-up testing--由低向上测试
渐增式集成测试的一种,其策略是先测试底层的组件,然后逐步加入较高层次的组件进行测试,直到系统所有组件都加入到系统。boundary value--边界值
一个输入或输出值,它处在等价类的边界上。boundary value coverage--边界值覆盖
通过测试用例,测试组件等价类的所有边界值。boundary value testing--边界值测试
通过边界值分析方法来生成测试用例的一种测试策略。Boundry Value Analysis--边界值分析
该分析一般与等价类一起使用。经验认为软件的错误经常在输入的边界上产生,因此边界值分析就是分析软件输入边界的一种方法。branch--分支
在组件中,控制从任何语句到其它任何非直接后续语句的一个条件转换,或者是一个无条件转换。branch condition--分支条件
branch condition combination coverage--分支条件组合覆盖
在每个判定中所有分支条件结果组合被测试用例覆盖到的百分比。branch condition combination testing--分支条件组合测试
通过执行分支条件结果组合来设计测试用例的一种方法。branch condition coverage--分支条件覆盖
每个判定中分支条件结果被测试用例覆盖到的百分比。branch condition testing--分支条件测试
通过执行分支条件结果来设计测试用例的一种方法。branch coverage--分支覆盖
通过测试执行到的分支的百分比。branch outcome--分支结果
见判定结果(decision outcome)branch point--分支点
见判定(decision)branch testing--分支测试
通过执行分支结果来设计测试用例的一种方法。Breadth Testing--广度测试
在测试中测试一个产品的所有功能,但是不测试更细节的特性。bug--缺陷
第121贴【2004-10-14】:常见测试术语三
capture/playback tool--捕获/回放工具
参考capture/replay toolCapture/Replay Tool--捕获/回放工具
一种测试工具,能够捕获在测试过程中传递给软件的输入,并且能够在以后的时间中,重复这个执行的过程。这类工具一般在GUI测试中用的较多。CASE--计算机辅助软件工程(computer aided software engineering)
用于支持软件开发的一个自动化系统。CAST--计算机辅助测试
在测试过程中使用计算机软件工具进行辅助的测试。cause-effect graph--因果图
一个图形,用来表示输入(原因)与结果之间的关系,可以被用来设计测试用例。certification --证明
一个过程,用于确定一个系统或组件与特定的需求相一致。change control--变更控制
一个用于计算机系统或系统数据修改的过程,该过程是质量保证程序的一个关键子集,需要被明确的描述。code audit --代码审计
由一个人、组或工具对源代码进行的一个独立的评审,以验证其与设计规格、程序标准的一致性。正确性和有效性也会被评价。Code Coverage--代码覆盖率
一种分析方法,用于确定在一个测试套执行后,软件的哪些部分被执行到了,哪些部分没有被执行到。Code Inspection--代码检视
一个正式的同行评审手段,在该评审中,作者的同行根据检查表对程序的逻辑进行提问,并检查其与编码规范的一致性。Code Walkthrough--代码走读
一个非正式的同行评审手段,在该评审中,代码被使用一些简单的测试用例进行人工执行,程序变量的状态被手工分析,以分析程序的逻辑和假设。code-based testing--基于代码的测试
根据从实现中引出的目标设计测试用例。coding standards--编程规范
一些编程方面需要遵循的标准,包括命名方式、排版格式等内容。Compatibility Testing--兼容性测试
测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。complete path testing --完全路径测试
参考穷尽测试(exhaustive testing)completeness--完整性
实体的所有必须部分必须被包含的属性。complexity --复杂性
系统或组件难于理解或验证的程度。Component--组件
一个最小的软件单元,有着独立的规格Component Testing--组件测试
参考单元测试computation data use--计算数据使用
一个不在条件中的数据使用。computer system security--计算机系统安全性
计算机软件和硬件对偶然的或故意的访问、使用、修改或破坏的一种保护机制。condition--条件
一个不包含布尔操作的布尔表达式,例如:A
condition coverage--条件覆盖
通过测试执行到的条件的百分比。condition outcome--条件结果
条件为真为假的评价。configuration control--配置控制
配置管理的一个方面,包括评价、协调、批准、和实现配置项的变更。configuration management--配置管理
一套技术和管理方面的原则用于确定和文档化一个配置项的功能和物理属性、控制对这些属性的变更、记录和报告变更处理和实现的状态、以及验证与指定需求的一致性。conformance criterion-- 一致性标准
判断组件在一个特定输入值上的行为是否符合规格的一种方法。Conformance Testing-- 一致性测试
测试一个系统的实现是否和其基于的规格相一致的测试。consistency -- 一致性
在系统或组件的各组成部分和文档之间没有矛盾,一致的程度。consistency checker-- 一致性检查器
一个软件工具,用于测试设计规格中需求的一致性和完整性。control flow--控制流
程序执行中所有可能的事件顺序的一个抽象表示。control flow graph--控制流图
通过一个组件的可能替换控制流路径的一个图形表示。conversion testing--转换测试
用于测试已有系统的数据是否能够转换到替代系统上的一种测试。corrective maintenance--故障检修
用于纠正硬件或软件中故障的维护。correctness --正确性
软件遵从其规格的程度。correctness --正确性
软件在其规格、设计和编码中没有故障的程度。软件、文档和其它项满足需求的程度。软件、文档和其它项满足用户明显的和隐含的需求的程度。coverage --覆盖率
用于确定测试所执行到的覆盖项的百分比。coverage item--覆盖项
作为测试基础的一个入口或属性:如语句、分支、条件等。crash--崩溃
计算机系统或组件突然并完全的丧失功能。criticality--关键性
需求、模块、错误、故障、失效或其它项对一个系统的操作或开发影响的程度。criticality analysis--关键性分析
需求的一种分析,它根据需求的风险情况给每个需求项分配一个关键级别。cyclomatic complexity--循环复杂度
一个程序中独立路径的数量。
data corruption--数据污染
违背数据一致性的情况。data definition--数据定义
一个可执行语句,在该语句上一个变量被赋予了一个值。data definition C-use coverage--数据定义C-use覆盖
在组件中被测试执行到的数据定义C-use使用对的百分比。data definition C-use pair--数据定义C-use使用对
一个数据定义和一个计算数据使用,数据使用的值是数据定义的值。data definition P-use coverage--数据定义P-use覆盖
在组件中被测试执行到的数据定义P-use使用对的百分比。data definition P-use pair--数据定义P-use使用对
一个数据定义和一个条件数据使用,数据使用的值是数据定义的值。data definition-use coverage--数据定义使用覆盖
在组件中被测试执行到的数据定义使用对的百分比。data definition-use pair --数据定义使用对
一个数据定义和一个数据使用,数据使用的值是数据定义的值。data definition-use testing--数据定义使用测试
以执行数据定义使用对为目标进行测试用例设计的一种技术。data dictionary--数据字典
(1)一个软件系统中使用的所有数据项名称,以及这些项相关属性的集合。(2)数据流、数据元素、文件、数据基础、和相关处理的一个集合。data flow analysis--数据流分析
一个软件验证和确认过程,用于保证输入和输出数据和它们的格式是被适当定义的,并且数据流是正确的。data flow coverage--数据流覆盖
测试覆盖率的度量是根据变量在代码中的使用情况。data flow diagram--数据流图
把数据源、数据接受、数据存储和数据处理作为节点描述的一个图形,数据之间的逻辑体现为节点之间的边。data flow testing--数据流测试
根据代码中变量的使用情况进行的测试。data integrity--数据完整性
一个数据集合完全、正确和一致的程度。data use--数据使用
一个可执行的语句,在该语句中,变量的值被访问。data validation--数据确认
用于确认数据不正确、不完整和不合理的过程。dead code--死代码
在程序操作过程中永远不可能被执行到的代码。Debugging--调试
发现和去除软件失效根源的过程。decision--判定
一个程序控制点,在该控制点上,控制流有两个或多个可替换路由。Decision condition--判定条件
判定内的一个条件。decision coverage--判定覆盖
在组件中被测试执行到的判定结果的百分比。decision outcome--判定结果
一个判定的结果,决定控制流走哪条路径。decision table--判定表
一个表格,用于显示条件和条件导致动作的集合。Depth Testing--深度测试
执行一个产品的一个特性的所有细节,但不测试所有特性。比较广度测试。design of experiments--实验设计
一种计划实验的方法,这样适合分析的数据可以被收集。design-based testing--基于设计的测试
根据软件的构架或详细设计引出测试用例的一种方法。desk checking--桌面检查
通过手工模拟软件执行的方式进行测试的一种方式。diagnostic--诊断
检测和隔离故障或失效的过程。dirty testing--肮脏测试
参考负面测试(negative testing)disaster recovery--灾难恢复
一个灾难的恢复和重建过程或能力。documentation testing --文档测试
测试关注于文档的正确性。domain--域
值被选择的一个集合。domain testing--域测试
参考等价划分测试(equivalence partition testing)dynamic analysis--动态分析
根据执行的行为评价一个系统或组件的过程。Dynamic Testing--动态测试
通过执行软件的手段来测试软件。
embedded software--嵌入式软件
软件运行在特定硬件设备中,不能独立于硬件存在。这类系统一般要求实时性较高。emulator--仿真
一个模仿另一个系统的系统或设备,它接受相同的输入并产生相同的输出。End-to-End testing--端到端测试
在一个模拟现实使用的场景下测试一个完整的应用环境,例如和数据库交互,使用网络通信等。entity relationship diagram--实体关系图
描述现实世界中实体及它们关系的图形。entry point --入口点
一个组件的第一个可执行语句。Equivalence Class--等价类
组件输入或输出域的一个部分,在该部分中,组件的行为从组件的规格上来看认为是相同的。equivalence partition coverage--等价划分覆盖
在组件中被测试执行到的等价类的百分比。equivalence partition testing--等价划分测试
根据等价类设计测试用例的一种技术。Equivalence Partitioning--等价划分
组件的一个测试用例设计技术,该技术从组件的等价类中选取典型的点进行测试。error--错误
IEEE的定义是:一个人为产生不正确结果的行为。error guessing--错误猜测
根据测试人员以往的经验猜测可能出现问题的地方来进行用例设计的一种技术。error seeding--错误播种/错误插值
故意插入一些已知故障(fault)到一个系统中去的过程,目的是为了根据错误检测和跟踪的效率并估计系统中遗留缺陷的数量。exception--异常/例外
一个引起正常程序执行挂起的事件。executable statement--可执行语句
一个语句在被编译后会转换成目标代码,当程序运行是会被执行,并且可能对程序数据产生动作。Exhaustive Testing--穷尽测试
测试覆盖软件的所有输入和条件组合。exit point--出口点
一个组件的最后一个可执行语句。expected outcome--期望结果
参考预期结果(predicted outcome)。
failure--失效
软件的行为与其期望的服务相背离。fault--故障
在软件中一个错误的表现。feasible path--可达路径
可以通过一组输入值和条件执行到的一条路径。feature testing--特性测试
参考功能测试(Functional Testing)FMEA--失效模型效果分析(Failure Modes and Effects Analysis)
可靠性分析中的一种方法,用于在基本组件级别上确认对系统性能有重大影响的失效。FMECA--失效模型效果关键性分析(Failure Modes and Effects Criticality Analysis)
FMEA的一个扩展,它分析了失效结果的严重性。FTA--故障树分析(Fault Tree Analysis)
引起一个不需要事件产生的条件和因素的确认和分析,通常是严重影响系统性能、经济性、安全性或其它需要特性。functional decomposition--功能分解
参考模块分解(modular decomposition)Functional Specification --功能规格说明书
一个详细描述产品特性的文档。Functional Testing--功能测试
测试一个产品的特性和可操作行为以确定它们满足规格。
glass box testing--玻璃盒测试
参考白盒测试(White Box Testing)IEEE--美国电子与电器工程师学会(Institute of Electrical and Electronic Engineers)
incremental testing--渐增测试
集成测试的一种,组件逐渐被增加到系统中直到整个系统被集成。infeasible path--不可达路径
不能够通过任何可能的输入值集合执行到的路径。input domain--输入域
所有可能输入的集合。inspection--检视
对文档进行的一种评审形式。installability testing--可安装性测试
确定系统的安装程序是否正确的测试。instrumentation--插装
在程序中插入额外的代码以获得程序在执行时行为的信息。instrumenter--插装器
执行插装的工具Integration Testing--集成测试
测试一个应用组合后的部分以确保它们的功能在组合之后正确。该测试一般在单元测试之后进行。interface--接口
两个功能单元的共享边界。interface analysis--接口分析
分析软件与硬件、用户和其它软件之间接口的需求规格。interface testing--接口测试
测试系统组件间接口的一种测试。invalid inputs--无效输入
在程序功能输入域之外的测试数据。isolation testing--孤立测试
组件测试(单元测试)策略中的一种,把被测组件从其上下文组件之中孤立出来,通过设计驱动和桩进行测试的一种方法。Job--工作
一个用户定义的要计算机完成的工作单元。job control language--工作控制语言
用于确定工作顺序,描述它们对操作系统要求并控制它们执行的语言。LCSAJ--线性代码顺序和跳转(Linear Code Sequence And Jump)
包含三个部分:可执行语句线性顺序的起始,线性顺序的结束,在线性顺序结束处控制流跳转的目标语句。LCSAJ coverage--LCSAJ覆盖
在组件中被测试执行到的LCSAJ的百分比。LCSAJ testing--LCSAJ测试
根据LCSAJ设计测试用例的一种技术。Load Testing--负载测试
通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。logic analysis--逻辑分析
(1)评价软件设计的关键安全方程式、算法和控制逻辑的方法。(2)评价程序操作的顺序并且检测可能导致灾难的错误。logic-coverage testing--逻辑覆盖测试
参考结构化测试用例设计(structural test case design)maintainability--可维护性
一个软件系统或组件可以被修改的容易程度,这个修改一般是因为缺陷纠正、性能改进或特性增加引起的。maintainability testing--可维护性测试
测试系统是否满足可维护性目标。modified condition/decision coverage--修改条件/判定覆盖
在组件中被测试执行到的修改条件/判定的百分比。modified condition/decision testing --修改条件/判定测试
根据MC/DC设计测试用例的一种技术。Monkey Testing--跳跃式测试
随机性,跳跃式的测试一个系统,以确定一个系统是否会崩溃。MTBF--平均失效间隔实际(mean time between failures)
两次失效之间的平均操作时间。MTTF--平均失效时间 (mean time to failure)
第一次失效之前的平均时间MTTR--平均修复时间(mean time to repair)
两次修复之间的平均时间multiple condition coverage--多条件覆盖
参考分支条件组合覆盖(branch condition combination coverage)mutation analysis--变体分析
一种确定测试用例套完整性的方法,该方法通过判断测试用例套能够区别程序与其变体之间的程度。
Negative Testing--逆向测试/反向测试/负面测试
测试瞄准于使系统不能工作。non-functional requirements testing--非功能性需求测试
与功能不相关的需求测试,如:性能测试、可用性测试等。N-switch coverage--N切换覆盖
在组件中被测试执行到的N转换顺序的百分比。N-switch testing--N切换测试
根据N转换顺序设计测试用例的一种技术,经常用于状态转换测试中。N-transitions--N转换
N+1转换顺序operational testing--可操作性测试
在系统或组件操作的环境中评价它们的表现。output domain--输出域
所有可能输出的集合。
partition testing--分类测试
参考等价划分测试(equivalence partition testing)path--路径
一个组件从入口到出口的一条可执行语句顺序。path coverage--路径覆盖
在组件中被测试执行到的路径的百分比。path sensitizing--路径敏感性
选择一组输入值强制组件走一个给定的路径。path testing--路径测试
根据路径设计测试用例的一种技术,经常用于状态转换测试中。performance testing--性能测试
评价一个产品或组件与性能需求是否符合的测试。portability testing--可移植性
测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。Positive Testing--正向测试
测试瞄准于显示系统能够正常工作。precondition--预置条件
环境或状态条件,组件执行之前必须被填充一个特定的输入值。predicate--谓词
一个逻辑表达式,结果为‘真’或‘假’。predicate data use--谓词数据使用
在谓词中的一个数据使用。program instrumenter--程序插装
参考插装(instrumenter)progressive testing--递进测试
在先前特性回归测试之后对新特性进行测试的一种策略。pseudo-random--伪随机
看似随机的,实际上是根据预先安排的顺序进行的。
QA--质量保证(quality assurance)
(1)已计划的系统性活动,用于保证一个组件、模块或系统遵从已确立的需求。(2)采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。QC--质量控制(quality control)
用于获得质量需求的操作技术和过程,如测试活动。Race Condition--竞争状态
并行问题的根源。对一个共享资源的多个访问,至少包含了一个写操作,但是没有一个机制来协调同时发生的访问。recovery testing--恢复性测试
验证系统从失效中恢复能力的测试。regression analysis and testing--回归分析和测试
一个软件验证和确认任务以确定在修改后需要重复测试和分析的范围。Regression Testing--回归测试
在发生修改之后重新测试先前的测试以保证修改的正确性。release--发布
一个批准版本的正式通知和分发。reliability--可靠性
一个系统或组件在规定的条件下在指定的时间内执行其需要功能的能力。reliability assessment--可靠性评价
确定一个已有系统或组件的可靠性级别的过程。requirements-based testing--基于需求的测试
根据软件组件的需求导出测试用例的一种设计方法。review--评审
在产品开发过程中,把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。risk--风险
不期望效果的可能性和严重性的一个度量。risk assessment--风险评估
对风险和风险影响的一个完整的评价。
safety--(生命)安全性
不会引起人员伤亡、产生疾病、毁坏或损失设备和财产、或者破坏环境。safety critical--严格的安全性
一个条件、事件、操作、过程或项,它的认识、控制或执行对生命安全性的系统来说是非常关键的。Sanity Testing--理智测试
软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考冒烟测试SDP--软件开发计划(software development plan)
用于一个软件产品开发的项目计划。security testing--安全性测试
验证系统是否符合安全性目标的一种测试。security.--(信息)安全性
参考计算机系统安全性(computer system security)serviceability testing--可服务性测试
参考可维护性测试(maintainability testing)simple subpath--简单子路径
控制流的一个子路径,其中没有不必要的部分被执行。simulation--模拟
使用另一个系统来表示一个物理的或抽象的系统的选定行为特性。simulation--模拟
使用一个可执行模型来表示一个对象的行为。simulator--模拟器
软件验证期间的一个设备、软件程序、或系统,当它给定一个控制的输入时,表现的与一个给定的系统类似。SLA--服务级别协议(service level agreement)
服务提供商与客户之间的一个协议,用于规定服务提供商应当提供什么服务。Smoke Testing--冒烟测试
对软件主要功能进行快餐式测试。最早来自于硬件测试实践,以确定新的硬件在第一次使用的时候不会着火。software development process--软件开发过程
一个把用户需求转换为软件产品的开发过程。software diversity--软件多样性
一种软件开发技术,其中,由不同的程序员或开发组开发的相同规格的不同程序,目的是为了检测错误、增加可靠性。software element--软件元素
软件开发或维护期间产生或获得的一个可交付的或过程内的文档。software engineering--软件工程
一个应用于软件开发、操作和维护的系统性的、有纪律的、可量化的方法。software engineering environment--软件工程环境
执行一个软件工程工作的硬件、软件和固件。software life cycle--软件生命周期
开始于一个软件产品的构思,结束于该产品不再被使用的这段期间。SOP--标准操作过程(standard operating procedures)
书面的步骤,这对保证生产和处理的控制是必须的。source code--源代码
用一种适合于输入到汇编器、编译器或其它转换设备的计算机指令和数据定义。source statement--源语句
参考语句(statement)
specification--规格
组件功能的一个描述,格式是:对指定的输入在指定的条件下的输出。specified input--指定的输入
一个输入,根据规格能预知其输出。spiral model --螺旋模型
软件开发过程的一个模型,其中的组成活动,典型的包括需求分析,概要设计,详细设计,编码,集成和测试等活动被迭代的执行直到软件被完成。SQL--结构化查询语句(structured query language)
在一个关系数据库中查询和处理数据的一种语言。state--状态
一个系统、组件或模拟可能存在其中的一个条件或模式。state diagram--状态图
一个图形,描绘一个系统或组件可能假设的状态,并且显示引起或导致一个状态切换到另一个状态的事件或环境。state transition--状态转换
一个系统或组件的两个允许状态之间的切换。state transition testing --状态转换测试
根据状态转换来设计测试用例的一种方法。statement--语句
程序语言的一个实体,是典型的最小可执行单元。statement coverage--语句覆盖
在一个组件中,通过执行一定的测试用例所能达到的语句覆盖百分比。statement testing--语句测试
根据语句覆盖来设计测试用例的一种方法。Static Analysis--静态分析
分析一个程序的执行,但是并不实际执行这个程序。Static Analyzer--静态分析器
进行静态分析的工具。Static Testing--静态测试
不通过执行来测试一个系统。statistical testing--统计测试
通过使用对输入统计分布进行分析来构造测试用例的一种测试设计方法。stepwise refinement--逐步优化
一个结构化软件设计技术,数据和处理步骤首先被广泛的定义,然后被逐步的进行了细化。storage testing--存储测试
验证系统是否满足指定存储目标的测试。Stress Testing--压力测试
在规定的规格条件或者超过规定的规格条件下,测试一个系统,以评价其行为。类似负载测试,通常是性能测试的一部分。structural coverage--结构化覆盖
根据组件内部的结构度量覆盖率。structural test case design--结构化测试用例设计
根据组件内部结构的分析来设计测试用例的一种方法。structural testing--结构化测试
参考结构化测试用例设计(structural test case design)structured basis testing--结构化的基础测试
根据代码逻辑设计测试用例来获得100%分支覆盖的一种测试用例设计技术。structured design--结构化设计
软件设计的任何遵循一定纪律的方法,它按照特定的规则,例如:模块化,有顶向下设计,数据逐步优化,系统结构和处理步骤。structured programming--结构化编程
在结构化程序开发中的任何包含结构化设计和结果的软件开发技术。structured walkthrough--结构化走读
参考走读(walkthrough)stub--桩
一个软件模块的框架或特殊目标实现,主要用于开发和测试一个组件,该组件调用或依赖这个模块。symbolic evaluation--符号评价
参考符号执行(symbolic execution)symbolic execution--符号执行
通过符号表达式来执行程序路径的一种静态分析设计技术。其中,程序的执行被用符号来模拟,例如,使用变量名而不是实际值,程序的输出被表示成包含这些符号的逻辑或数学表达式。symbolic trace--符号轨迹
一个计算机程序通过符号执行是经过的语句分支结果的一个记录。syntax testing--语法分析
根据输入语法来验证一个系统或组件的测试用例设计技术。system analysis--系统分析
对一个计划的或现实的系统进行的一个系统性调查以确定系统的功能以及系统与其它系统之间的交互。system design--系统设计
一个定义硬件和软件构架、组件、模块、接口和数据的过程以满足指定的规格。system integration--系统集成
一个系统组件的渐增的连接和测试,直到一个完整的系统。System Testing--系统测试
从一个系统的整体而不是个体上来测试一个系统,并且该测试关注的是规格,而不是系统内部的逻辑。technical requirements testing--技术需求测试
参考非功能需求测试(non-functional requirements testing)test automation--测试自动化
使用工具来控制测试的执行、结果的比较、测试预置条件的设置、和其它测试控制和报告功能。test case--测试用例
用于特定目标而开发的一组输入、预置条件和预期结果。test case design technique--测试用例设计技术
选择和导出测试用例的技术。test case suite--测试用例套
对被测软件的一个或多个测试用例的集合。test comparator--测试比较器
一个测试工具用于比较软件实际测试产生的结果与测试用例预期的结果。test completion criterion--测试完成标准
一个标准用于确定被计划的测试何时完成。test coverage--测试覆盖
参考覆盖率(Coverage)test driver--测试驱动
一个程序或测试工具用于根据测试套执行软件。test environment--测试环境
测试运行其上的软件和硬件环境的描述,以及任何其它与被测软件交互的软件,包括驱动和桩。
test execution--测试执行
一个测试用例被被测软件执行,并得到一个结果。test execution technique--测试执行技术
执行测试用例的技术,包括手工、自动化等。test generator--测试生成器
根据特定的测试用例产生测试用例的工具。test harness--测试用具
包含测试驱动和测试比较器的测试工具。test log--测试日志
一个关于测试执行所有相关细节的时间记录。test measurement technique--测试度量技术
度量测试覆盖率的技术。Test Plan--测试计划
一个文档,描述了要进行的测试活动的范围、方法、资源和进度。它确定测试项、被测特性、测试任务、谁执行任务,并且任何风险都要冲突计划。test procedure--测试规程
一个文档,提供详细的测试用例执行指令。test records--测试记录
对每个测试,明确的记录被测组件的标识、版本,测试规格,和实际结果test report--测试报告
一个描述系统或组件执行的测试和结果的文档。Test scrīpt--测试脚本
一般指的是一个特定测试的一系列指令,这些指令可以被自动化测试工具执行。Test Specification--测试规格
一个文档,用于指定一个软件特性、特性组合或所有特性的测试方法、输入、预期结果和执行条件。test strategy--测试策略
一个简单的高层文档,用于描述测试的大致方法,目标和方向。test suite--测试套
测试用例和/或测试脚本的一个集合,与一个应用的特定功能或特性相关。test target--测试目标
一组测试完成标准。testability--可测试性
一个系统或组件有利于测试标准建立和确定这些标准是否被满足的测试执行的程度。Testing--测试
IEEE给出的定义是:1)一个执行软件的过程,以验证其满足指定的需求并检测错误。2)一个软件项的分析过程以检测已有条件之间的不同,并评价软件项的特性。thread testing--线程测试
自顶向下测试的一个变化版本,其中,递增的组件集成遵循需求子集的实现。time sharing--时间共享
一种操作方式,允许两个或多个用户在相同的计算机系统上同时执行计算机程序。其实现可能通过时间片轮转、优先级中断等。top-down design--由顶向下设计
一种设计策略,首先设计最高层的抽象和处理,然后逐步向更低级别进行设计。top-down testing--自顶向下测试
集成测试的一种策略,首先测试最顶层的组件,其它组件使用桩,然后逐步加入较低层的组件进行测试,直到所有组件被集成到系统中。traceability--可跟踪性
开发过程的两个或多个产品之间关系可以被建立起来的程度,尤其是产品彼此之间有一个前后处理关系。traceability analysis--跟踪性分析
(1)跟踪概念文档中的软件需求到系统需求;(2)跟踪软件设计描述到软件需求规格,以及软件需求规格到软件设计描述;(3)跟踪源代码对应到设计规格,以及设计规格对应到源代码。分析确定它们之间正确性、一致性、完整性、精确性的关系。traceability matrix--跟踪矩阵
一个用于记录两个或多个产品之间关系的矩阵。例如,需求跟踪矩阵是跟踪从需求到设计再到编码的实现。 -
测试摸板!转自论坛!
2007-07-19 16:01:18
软 件 测 试 报 告
项目编号: 项目名称:
任务编号/序号: 工作名称:
程序(ID): 程序名称:
编程员: 测试完成日期: 年 月 日
测试工程师: 测试完成日期: 年 月 日
1、
是 否
(1)程序运行环境已经正确设定 □ □
2、程序代码检查:
(1)程序单位首部有程序说明和修改备注 □ □
(2)变量、过程、函数命令符合规则 □ □
(3)程序中有足够的说明信息 □ □
(4)修改注释符合要求 □ □
(5)类库的使用符合要求 □ □
3、画面及报表格式检查:
(1)画面和报表格式符合规定需求 □ □
(2)程序命名符合格式需求 □ □
(3)画面和报表的字段位置和宽度与设计文档一致 □ □
4、功能测试:
(1)多画面之间切换正确 □ □
(2)功能键、触发键、按钮、菜单、选择项功能正确 □ □
(3)数据项关联及限制功能正确 □ □
(4)设计文档规定的其它功能
□ □
□ □
□ □
□ □
□ □
□ □
□ □
5、正确性测试:
(1)读/写/删除操作结果正确
(2)各种组合条件之查询或报表正确
(3)设计文档规定的其它操作
测试内容: □ □
6、可靠性测试:
(1)非法键容错测试
(2)异常字符容错测试
(3)程序负作用检查
(4)残留文件检查
7、效率测试:
单用户(机型) □ □ 多用户(终端数)□ □
(1) 输入画面效率测试:
延迟时间: □ □ □ □
(2) 报表及查询效率测试:
最小报表时间:□ □ □ □
最大报表时间:□ □ □ □
8、多用户测试:
终端数: □ □
(1)随机测试:
测试次数:□ □
(2)共享测试:□ □
(3)同步测试:□ □
9、其它测试:
测试内容: □ □
测试备忘:
-
黑盒测试方法揭密
2007-07-19 11:06:18
作者:陈樵 2002年04月08日 本文选自:中国计算机报
一、黑盒测试在快速应用开发(rad)环境中的重要作用
软件测试方法一般分为两种:白盒测试与黑盒测试。其中,白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试,着重于程序的内部结构及算法,通常不关心功能与性能指标。黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试,实际上是站在最终用户的立场上,检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。
随着rad环境的发展,软件工程面临新的挑战,其中包括:
●应用系统的规模越来越庞大,结构越来越复杂;
●开发团队人员越来越多,分工越来越细;
●项目投资日益提高,导致投资风险增大。
在这样一种背景下,软件质量面临着更大的危机,而解决问题的关键正是黑盒测试,可是由于传统的黑盒测试往往局限于手工测试,凭借工程人员的经验自发地进行,缺乏严格的测试管理机制,因而效果并不明显。
在分发一个应用系统之前,若没有经过科学、周密的黑盒测试,就相当于将大量隐含的缺陷(defect)交付到最终用户手中,这对于开发团队自身、项目投资方及最终用户来说都是不负责任的表现,也将严重损害三方的利益。
今天,软件的质量要求越来越受到重视,在对软件的质量监督中,黑盒测试起着重要的、不可替代的作用;而随着软件开发平台及软件设计思想的进步和发展,特别是rad技术的发展,对黑盒测试提出了更明确的要求,人们发现,必须遵循一定的测试理论,依赖于优秀的测试工具,才能进行科学、完备的测试。
二、黑盒测试的操作步骤
在传统的软件开发生命周期当中,测试工作往往被搁置到整个开发过程的后期进行,也就是说,当应用程序的编码工作已经基本完成,才开始进行测试,这样做的缺点在于:
a)由于应用程序庞大而复杂,测试工作千头万绪,测试人员难以组织科学、全面的测试用例,从而大幅度提高了测试成本,并严重影响测试的全面性和有效性;
b)由于缺陷所涉及的模块从开发到测试之间的时间间隔较长,使得程序员的修改和维护工作要付出更大的代价;
c)由于受到分发日期的限制,测试工作往往是在忙碌中结束的,而将大量的缺陷遗留给最终用户,也就是说,真正的测试工作实际上是由最终用户来完成的。
因此,为了保证测试工作科学、精确、全面、有序地进行,应该采取一边开发一边测试的策略,使得开发工作与测试工作平行进行,这也就是俗话所说的“越早测试越好”的概念。
一套完整的测试应该由五个阶段组成:
1.测试计划
首先,根据用户需求报告中关于功能要求和性能指标的规格说明书,定义相应的测试需求报告,即制订黑盒测试的最高标准,以后所有的测试工作都将围绕着测试需求来进行,符合测试需求的应用程序即是合格的,反之即是不合格的;同时,还要适当选择测试内容,合理安排测试人员、测试时间及测试资源等。
2.测试设计
将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程,并为每个测试过程选择适当的测试用例(测试用例选择的好坏将直接影响到测试结果的有效性)。
3.测试开发
建立可重复使用的自动测试过程。
4.测试执行
执行测试开发阶段建立的自动测试过程,并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成,测试人员应本着科学负责的态度,一步一个脚印地进行测试。
5.测试评估
结合量化的测试覆盖域及缺陷跟踪报告,对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。
显然,黑盒测试只有严格按照步骤进行,才可能对应用程序的质量进行把关。然而,如果没有一种优秀的测试工具的帮助,单纯凭借手工测试,不但将耗费大量的人力、物力和财力,而且有很多测试工作是难以实现甚至是无法实现的。
三、手工测试与自动测试的比较
手工测试无法保证黑盒测试的科学性与严密性,这是因为:
●测试人员要负责大量文档、报表的制订和整理工作,会变得力不从心;
●受软件分发日期、开发成本及人员、资源等诸多方面因素的限制,难以进行全面的测试;
●如果修正缺陷所花费的时间相当长,回归测试将变得异常困难;
●对测试过程中发现的大量缺陷缺乏科学、有效的管理手段,责任变得含混不清,没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率;
●反复测试带来的倦怠情绪及其他人为因素使得测试标准前后不一,测试花费的时间越长,测试的严格性也就越低;
●难以对不可视对象或对象的不可视属性进行测试。
因此,自动测试成为最佳的解决方案。所谓自动测试,实际上是将大量的重复性工作交给计算机去完成,一个优秀的自动测试工具,不但可以满足科学测试的基本要求,而且可以节约大量的时间、成本、人员和资源,并且测试脚本可以被重复利用(包括被不同的项目所利用)。 -
软件测试的常识
2007-07-19 09:52:49
软件测试的常识
软件开发和使用的历史已经留给了我们很多由于软件缺陷而导致的巨大财力、物力损失的经验教训。这些经验教训迫使我们这些测试工程师们必须采取强有力的检测措施来检测未发现的隐藏的软件缺陷。
生产软件的最终目的是为了满足客户需求,我们以客户需求作为评判软件质量的标准,认为软件缺陷( Software Bug )的具体含义包括下面几个因素:
• 软件未达到客户需求的功能和性能;
• 软件超出客户需求的范围;
• 软件出现客户需求不能容忍的错误;
• 软件的使用未能符合客户的习惯和工作环境。
考虑到设计等方面的因素,我们还可以认为软件缺陷还可以包括软件设计不符合规范,未能在特定的条件(资金、范围等)达到最佳等。可惜的是,我们中的很多人更倾向于把软件缺陷看成运行时出现问题上来,认为软件测试仅限于程序提交之后。
在目前的国内环境下,我们几乎看不到完整准确的客户需求说明书,加以客户的需求时时在变,追求完美的测试变得不太可能。因此作为一个优异的测试人员,追求软件质量的完美固然是我们的宗旨,但是明确软件测试现实与理想的差距,在软件测试中学会取舍和让步,对软件测试是有百益而无一弊的。
下面是一些软件测试的常识,对这些常识的理解和运用将有助于我们在进行软件测试时能够更好的把握软件测试的尺度。
• 测试是不完全的(测试不完全)
很显然,由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素,哪怕是一个极其简单的程序,要想穷尽所有逻辑路径,所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子,比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试的话,从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的,即便某一天我们能够穷尽该程序,只怕我们乃至我们的子孙都早已作古了。为此作为软件测试,我们一般采用等价类和边界值分析等措施来进行实际的软件测试,寻找最小用例集合成为我们精简测试复杂性的一条必经之道。
• 测试具有免疫性(软件缺陷免疫性)
软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ,测试人员对其采用的测试越多,其免疫能力就越强,寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的,则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算,软件存在 500 个缺陷时,我们查找一个软件缺陷需要 X 小时,当软件只存在 5 个错误时,我们每查找一个软件缺陷需要 100X 小时。实践证明,实际的测试过程比上面的假设更为苛刻,为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷,因此软件测试应该尽可能的多采用多种途径进行测试。
• 测试是 “ 泛型概念 ” (全程测试)
我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话,需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷,记住 “ 软件缺陷具有生育能力 ” 。软件测试应该跨越整个软件开发流程。需求验证(自检)和设计验证(自检)也可以算作软件测试(建议称为:需求测试和设计测试)的一种。软件测试应该是一个泛型概念,涵盖整个软件生命周期,这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估(信息系统审计和软件工程监理),即测试本身也应当被测试,从而确保测试自身的可靠性和高效性。否则自身不正,难以服人。
另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件,软件测试是提高产品质量最直接、最快捷的手段,但决不是一个根本手段。
• 80-20 原则
80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们,如果你想使软件测试有效地话,记住常常光临其高危多发 “ 地段 ” 。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。
80-20 原则的另外一种情况是,我们在系统分析、系统设计、系统实现阶段的复审,测试工作中能够发现和避免 80% 的软件缺陷,此后的系统测试能够帮助我们找出剩余缺陷中的 80% ,最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷,却无法保证能够发现所有的软件缺陷。
80-20 原则还能反映到软件测试的自动化方面上来,实践证明 80% 的软件缺陷可以借助人工测试而发现, 20% 的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分,因此尚有 5% 左右的软件缺陷需要通过其他方式进行发现和修正。
• 为效益而测试
为什么我们要实施软件测试,是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来,在软件测试中我们应该尽量地保持软件测试简单性,切勿将软件测试过度复杂化,拿物理学家爱因斯坦的话说就是: Keep it simple but not too simple 。
• 缺陷的必然性
软件测试中,由于错误的关联性,并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的软件缺陷。很多软件缺陷之间是相互矛盾的,一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何况在缺陷的修复过程中,我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围,选择一个折中的方案或是从非软件的因素(比如提升硬件性能)考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。
• 软件测试必须有预期结果
没有预期结果的测试是不可理喻的。软件缺陷是经过对比而得出来的。这正如没有标准无法进行度量一样。如果我们事先不知道或是无法肯定预期的结果,我们必然无法了解测试正确性。这很容易让人感觉如盲人摸象一般,不少测试人员常常凭借自身的感觉去评判软件缺陷的发生,其结果往往是把似是而非的东西作为正确的结果来判断,因此常常出现误测的现象。
• 软件测试的意义 - 事后分析
软件测试的目的单单是发现缺陷这么简单吗?如果是 “ 是 ” 的话,我敢保证,类似的软件缺陷在下一次新项目的软件测试中还会发生。古语说得好, “ 不知道历史的人必然会重蹈覆辙 ” 。没有对软件测试结果进行认真的分析,我们就无法了解缺陷发生的原因和应对措施,结果是我们不得不耗费的大量的人力和物力来再次查找软件缺陷。很可惜,目前大多测试团队都没有意识到这一点,测试报告中缺乏测试结果分析这一环节。
结论:
软件测试是一个需要 “ 自觉 ” 的过程,作为一个测试人员,遇事沉着,把持尺度,从根本上应对软件测试有着正确的认识,希望本文对读者对软件测试的认识有所帮助。 -
软件测试 从零开始
2007-07-19 09:28:31
【摘要】本文面向软件测试新手,从测试前的准备工作、测试需求收集、测试用例设计、测试用例执行、测试结果分析几个方面给出建议和方法。鉴于国内的软件开发、测试不规范的现状,本文为软件测试新手提供了若干个软件测试的关注点。
【关键词】软件测试、测试用例、测试需求、测试结果分析
引言
几年前,从学校毕业后,第一份工作就是软件测试。那时候,国内的软件企业大多对软件测试还没有什么概念,书店里除了郑人杰编写的《计算机软件测试技术》之外,几乎没有其它的软件测试相关书籍,软件测试仅仅在软件工程的教材中作为一个章节列出来,因此,我对软件测试一无所知。不过,在正式走上工作岗位之前,公司提供了为期两周的系统的软件测试技术专题培训,对接下来的软件测试工作有很大的指导意义。现在,我继续从事软件测试的培训与咨询服务,在这个过程中,亲眼目睹了很多软件测试新手面对的困惑,他们初涉软件测试行业,没有接受系统的培训,对软件测试一无所知,既不知道该测试什么,也不知道如何开始测试。下面针对上述情况,给出若干解决办法。
• 测试准备工作
在测试工作伊始,软件测试工程师应该搞清楚软件测试工作的目的是什么。如果你把这个问题提给项目经理,他往往会这样回答: “ 发现我们产品里面的所有 BUG ,这就是你的工作目的 ” 。作为一名软件测试新手,如何才能发现所有的 BUG ?如何开始测试工作?即便面对的是一个很小的软件项目,测试需要考虑的问题也是方方面面的,包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用户的并发容量等等。该从何处下手呢?
• 向有经验的测试人员学习
如果你进入的是一家运作规范的软件公司,有独立的软件测试部门、规范的软件测试流程、软件测试技术有一定的积累,那么,恭喜你!你可以请求测试经理委派有经验的测试人员作为你工作上的业务导师,由他列出软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录,在业务导师的指导下逐步熟悉软件测试的相关工作。其实,在很多运作规范的软件公司,已经把上述的师父带徒弟的方式固化到流程中。
如果你进入的是一个软件测试一片空白的软件企业,那么,也恭喜你!你可以在这里开创一片自己的软件测试事业,当然,前提是老板确实认识到软件测试的重要性,实实在在需要提高产品的质量。这时候,可以到国内的软件测试论坛和相关网站上寻找软件测试资源,这种情况下,自学能力和对技术的悟性就至关重要了。
• 阅读软件测试的相关书籍
现在,中文版的软件测试书籍越来越多,有的是国人自己写的,有的是翻译国外经典之作。可以到 www.chinapub.com 或者 www.cnforyou.com 等网络购书的站点查找软件测试相关的书籍。目前,从国外引入的软件测试书籍有很多经典之作,但是,翻译成中文后,翻译质量对阅读效果有很大的影响。
• 走读缺陷跟踪库中的问题报告单
如果您所在的公司已经有软件缺陷跟踪库了,无论采用的是商用工具,如 ClearQuest 、 TestDirecter 等工具,还是采用的 Bugzilla 、 Mantis 等开源工具,这都无关紧要,缺陷跟踪库中的缺陷报告单才是有价值的。缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现,同时也是软件产品问题的集中体现。一般来说,缺陷报告单中最关键的几个部分包括:第一部分是发现缺陷的环境,包括软件环境、硬件环境等;第二部分是缺陷的基本描述;第三部分是开发人员对缺陷的解决方法。通过对上述缺陷报告单的三个部分作仔细分析,不知不觉你已经吸收了其他软件测试人员的工作经验,并掌握了软件产品常见的基本问题。这是迅速提高软件测试经验的好方法。
• 走读相关产品的历史测试用例
如果你所在的公司有测试用例管理系统,那么,走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。走读测试用例也是有技巧的。测试用例写作一般会包括测试用例项和根据测试用例项细化的测试用例,下面举例说明。 “ 测试用户登录的功能 ” 是一个测试项,该测试项的目的是测试用户登录功能是否正确,是否能够完成正常的登录功能,是否能够对非法用户名和密码做异常处理等等。因此,根据该用例项,可以设计出若干个测试用例,大多数情况下,测试用例项和测试用例是一对多的关系。
通过走读测试用例项目,你可以掌握应该从哪些功能点着手未来的测试工作;通过走读软件测试用例,你可以了解如何根据被测试的功能点开展软件测试用例的设计工作,包括如何确定测试用例的输入、测试用例的操作步骤和测试用例的输出结果等。
总之,走读其他软件测试人员设计的优秀软件测试用例,是提高自身用例设计水平的好方法。
• 学习产品相关的业务知识
软件测试人员不仅要掌握软件测试技术相关知识,对产品相关的业务知识也要学习。这很好理解,如果从事财务软件的测试工作,一定要学习财务知识;如果从事通讯产品测试工作,那么相关的通讯理论知识也是必须的;如果从事银行软件的测试,银行的业务流程也是不可或缺的知识点。
因此,在学习软件测试技术的同时,千万不要忽略产品相关业务知识的学习。如果你是一个软件测试技术专家,但是对产品业务知识一无所知,那么也只能测试出来纯粹的软件缺陷,而面对眼前出现的产品业务相关的缺陷,很可能是视而不见,如此这般,软件测试的效果会大打折扣。
• 识别测试需求
识别测试需求是软件测试的第一步。如果开发人员能够提供完整的需求文档和接口文档,那固然好。可以根据需求文档中描述的每个功能项目的输入、处理过程和输出,来设计测试用例。如果开发人员没有提供软件需求文档,那该如何是好?下面给出几个有效的方法:
• 主动获取需求
开发人员通常不会更好地考虑软件测试,如果没有开发流程的强制规定,他们通常是不愿意提供任何开发文档,即便有强制规定,需求文档也未必能够真正指导软件系统测试工作。因此,需要测试人员发挥主观能动性,与相关的软件开发项目经理和软件开发人员保持沟通,了解软件实现的主要功能是什么,并记录得收集到的信息。一般来说,开发人员即便没有提供相关需求文档,也会保存一些简单的过程文档,主动向开发人员索要这些文档,可以作为测试的参考。此外,可以与公司的技术支持人员交流,技术支持人员是最贴近用户的人,因此,通过交流可以获取第一手的用户使用感受,在测试的过程中会更加贴近用户。
当拿到相关的资料后,从哪些方面分析需求?如何与开发人员交流需求?其实,只要把握需求分析的几个关键的点就可以解决问题:输入、处理过程、输出、性能要求、运行环境,下面针对每一个项目逐一分析:
软件输入: 与该需求相关的一切可能输入,可以从这几方面考虑,输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、输入参数的精度和输入参数的有效输入范围。在测试用例设计中,这部分内容作为测试用例输入的依据。
处理过程: 描述对输入数据所执行的所有操作和如何获得输出的过程。测试人员了解处理过程即可,在测试过程中发现 BUG 时候,如果对处理过程了解的深入,对定位问题根源有很大的帮助。
软件输出: 描述每个需求的输出结果,包括输出的位置(如计算机显示器、打印机,文件),输出参数的数量、输出参数的度量单位、输出参数的时序、输出参数精确度、输出参数的有效输出范围、错误消息。在测试用例设计中,这部分内容作为测试用例的预期输出。
性能要求: 与该需求相关的性能要求,比如 “ 插入 ATM 取款卡后, 3 秒钟内弹出提示用户取款的图形界面 ” 。 3 秒钟这一限制,就是对需求的基本性能要求。
运行环境: 软件的运行所需的环境,包括硬件平台的要求、操作系统的要求、数据库的要求,以及其它相关支撑软件的要求。
• 确认需求的优先级
确认需求的优先级是很必要的,如果在产品进度比较紧的情况下,测试人员可以考虑优先测试优先级高的需求项,如果进度允许,那么在测试优先级低的需求项,如果进度不允许,那么就放弃测试优先级低的需求项。如果软件公司有规范的流程支撑,开发人员在提供软件需求文档的时候,应该在文档中确定需求的优先级。但是,如果开发人员连基本的软件需求文档都没有提供,又怎能指望他们确定软件需求的优先级?如果是这样,需求的优先级只能由测试人员完成了。
• 加入开发小组的邮件群组
测试人员需要通晓被测试产品,但是,产品在开发的过程中往往是不断变化的。如果软件开发团队有一套变更控制流程,测试人员会对产品的变更了如指掌。如果没有变更控制,那就要采用其他的土方法了。如果公司里面有自动化办公系统,也许采用的是 Lotus Notes 系统,也许使用的是 E-mail 系统,测试人员应该加入到开发人员的邮件群组中。当开发人员通过邮件讨论问题、通知召开技术会议的时候,测试人员可以及时知晓,如果必要,可以参加开发人员的技术会议。即便公司里面有了软件变更控制流程,加入到开发邮件群组也是一个很好的习惯。
• 与开发人员为邻
建议测试人员与开发人员为邻。我所在的测试组曾经与开发组是在相邻的写字间里,开发人员与测试人员的关系非常融洽,抛去同事关系,大家还是不错的朋友。不管开发人员有什么样的活动,测试人员都能第一时间获得信息。无论从事软件测试工作,还是从事其它的工作,与工作中上下游环节的同事保持良好的个人关系对工作有很大便利。一般的公司内部都存在部门墙,良好的人际关系是打通部门墙的手段之一。向领导建议测试人员与开发人员为邻,这很必要。
• 测试用例设计
测试需求收集完毕后,开始测试设计。测试用例是什么?测试用例就是一个文档,描述输入、动作、或者时间和一个期望的结果,其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题:
• 测试用例的基本格式
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果,下面逐一介绍。
用例编号: 测试用例的编号有一定的规则,比如系统测试用例的编号这样定义规则: PROJECT1-ST-001 ,命名规则是项目名称+测试阶段类型(系统测试阶段)+编号。定义测试用例编号,便于查找测试用例,便于测试用例的跟踪。
测试标题: 对测试用例的描述,测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时,软件的响应情况 ” 。
重要级别: 定义测试用例的优先级别,可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说,如果软件需求的优先级为 “ 高 ” ,那么针对该需求的测试用例优先级也为 “ 高 ” ;反之亦然,
测试输入: 提供测试执行中的各种输入条件。根据需求中的输入条件,确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性,如果软件需求中没有很好的定义需求的输入,那么测试用例设计中会遇到很大的障碍。
操作步骤: 提供测试执行过程的步骤。对于复杂的测试用例,测试用例的输入需要分为几个步骤完成,这部分内容在操作步骤中详细列出。
预期结果: 提供测试执行的预期结果,预期结果应该根据软件需求中的输出得出。如果在实际测试过程中,得到的实际测试结果与预期结果不符,那么测试不通过;反之则测试通过。
软件测试用例的设计主要从上述 6 个域考虑,结合相应的软件需求文档,在掌握一定测试用例设计方法的基础上,可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍,白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍,这里不作赘述。
• 重用同类型项目的测试用例
如果我看得远,那是因为我站在巨人的肩上 --牛顿。
一般来说,每个软件公司的项目可以分为固定的几大类。可以按业务类型划分,比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等;可以按软件结构来划分,比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例,会有很大的借鉴意义。如果,公司中有同类别的软件系统,千万别忘记把相关的测试用例拿来参考。如果,系统非常接近,甚至经过对测试用例简单修改就可以应用到当前被测试的软件。 “ 拿来主义 ” 可以极大的开阔测试用例设计思路,也可以节省大量的测试用例设计时间。
• 利用已有的软件 Checklist
在上面一个小节中,按照不同的规则划分了不同的软件类型。每种类型的软件都有一定的测试规范,比如, WEB 软件系统在系统测试过程中,会有一系列的范式,比如针对 Cookie 就会有很多测试点。在设计测试用例的时候,不妨到网上去搜索相关的 Checklist ,不过国内外的网站很少有这方面的资料,即便有,也不是特别系统。可以先找一份粗糙的 Checklist ,然后,在设计测试用例的时候不断的去完善它,以作为下次测试用例设计的基础。
• 加强测试用例的评审
测试用例设计完毕后,最好能够增加评审过程。同行评审是 CMM3 级的一个 KPA ,如果因为公司没有通过 CMM3 级,就不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审,提交评审意见,然后根据评审意见更新测试用例。 如果认真操作这个环节,测试用例中的很多问题都会暴露出来,比如用例设计错误、用例设计遗漏、用例设计冗余、用例设计不充分等等;如果同行评审不充分,那么,在测试执行的过程中,上述本应在评审阶段发现的测试用例相关问题,会给测试执行带来大麻烦,甚至导致测试执行挂起。
• 定义测试用例的执行顺序
在测试用例执行过程中,你会发现每个测试用例都对测试环境有特殊的要求,或者对测试环境有特殊的影响。因此,定义测试用例的执行顺序,对测试的执行效率影响非常大。比如某些异常测试用例会导致服务器频繁重新启动,服务器的每次重新启动都会消耗大量的时间,导致这部分测试用例执行也消耗很多的时间。那么在编排测试用例执行顺序的时候,应该考虑把这部分测试用例放在最后执行,如果在测试进度很紧张的情况下,如果优先执行这部分消耗时间的异常测试用例,那么在测试执行时间过了大半的时候,测试用例执行的进度依然是缓慢的,这会影响到测试人员的心情,进而导致匆忙地测试后面的测试用例,这样测试用例的漏测、误测就不可避免,严重影响了软件测试效果和进度。因而,合理地定义测试用例的执行顺序是很有必要的。
• 测试用例执行
测试用例设计完毕后,接下来的工作是测试执行,测试执行中应该注意以下几个问题:
• 搭建软件测试环境,执行测试用例
测试用例执行过程中,搭建测试环境是第一步。一般来说,软件产品提交测试后,开发人员应该提交一份产品安装指导书,在指导书中详细指明软件产品运行的软硬件环境,比如要求操作系统系统是 Windows 2000 pack4 版本,数据库是 Sql Server 2000 等等,此外,应该给出被测试软件产品的详细安装指导书,包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品,尤其是软件项目,如果没有安装指导书作为参考,在搭建测试环境过程中会遇到种种问题。
如果开发人员拒绝提供相关的安装指导书,搭建测试中遇到问题的时候,测试人员可以要求开发人员协助,这时候,一定要把开发人员解决问题的方法记录下来,避免同样的问题再次请教开发人员,这样会招致开发人员的反感,也降低了开发人员对测试人员的认可程度。
• 测试执行过程应注意的问题
测试环境搭建之后,根据定义的测试用例执行顺序,逐个执行测试用例。在测试执行中需要注意以下几个问题:
全方位的观察测试用例执行结果: 测试执行过程中,当测试的实际输出结果与测试用例中的预期输出结果一致的时候,是否可以认为测试用例执行成功了?答案是否定的,即便实际测试结果与测试的预期结果一致,也要查看软件产品的操作日志、系统运行日志和系统资源使用情况,来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前,我在测试嵌入式系统软件的时候,执行某测试用例后,测试用例的实际输出与预期输出完全一致,不过在查询 CPU 占用率地时候,发现 CPU 占用率高达 90 %,后来经过分析,软件运行的时候启动了若干个 1ms 的定时器,大量的消耗的 CPU 资源,后来通过把定时器调整到 10ms , CPU 的占用率降为 7 %。如果观察点单一,这个严重消耗资源的问题就无从发现了。
加强测试过程记录: 测试执行过程中,一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异,一定要记录下来,作为日后更新测试用例的依据;如果软件产品提供了日志功能,比如有软件运行日志、用户操作日志,一定在每个测试用例执行后记录相关的日志文件,作为测试过程记录,一旦日后发现问题,开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境,为开发人员重现问题。
及时确认发现的问题: 测试执行过程中,如果确认发现了软件的缺陷,那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题,又无法定位是否为软件缺陷,那么一定要保留现场,然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷,测试人员给予配合;如果开发人员定位问题需要花费很长的时间,测试人员千万不要因此耽误自己宝贵的测试执行时间,可以让开发人员记录重新问题的测试环境配置,然后,回到自己的开发环境上重现问题,继续定位问题。
与开发人员良好的沟通: 测试执行过程中,当你提交了问题报告单,可能被开发人员无情驳回,拒绝修改。这时候,只能对开发人员晓之以理,做到有理、有据,有说服力。首先,要定义软件缺陷的标准原则,这个原则应该是开发人员和测试人员都认可的,如果没有共同认可的原则,那么开发人员与测试人员对问题的争执就不可避免了。此外,测试人员打算说服开发人员之前,考虑是否能够先说服自己,在保证可以说服自己的前提下,再开始与开发人员交流。
• 及时更新测试用例
测试执行过程中,应该注意及时更新测试用例。往往在测试执行过程中,才发现遗漏了一些测试用例,这时候应该及时的补充;往往也会发现有些测试用例在具体的执行过程中根本无法操作,这时候应该删除这部分用例;也会发现若干个冗余的测试用例完全可以由某一个测试用例替代,那么删除冗余的测试用例。
总之,测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后,统一更新测试用例,如果这样,往往会遗漏很多本应该更新的测试用例。
• 提交一份优秀的问题报告单
软件测试提交的问题报告单和测试日报一样,都是软件测试人员的工作输出,是测试人员绩效的集中体现。因此,提交一份优秀的问题报告单是很重要的。软件测试报告单最关键的域就是 “ 问题描述 ” ,这是开发人员重现问题,定位问题的依据。问题描述应该包括以下几部分内容:软件配置、硬件配置、测试用例输入、操作步骤、输出、当时输出设备的相关输出信息和相关的日志等。
软件配置: 包括操作系统类型版本和补丁版本、当前被测试软件的版本和补丁版本、相关支撑软件,比如数据库软件的版本和补丁版本等。
硬件配置: 计算机的配置情况,主要包括 CPU 、内存和硬盘的相关参数,其它硬件参数根据测试用例的实际情况添加。如果测试中使用网络,那么网络的组网情况,网络的容量、流量等情况。硬件配置情况与被测试产品类型密切相关,需要根据当时的情况,准确翔实的记录硬件配置情况。
测试用例输入 \ 操作步骤 \ 输出: 这部分内容可以根据测试用例的描述和测试用例的实际执行情况如实填写。
输出设备的相关输出信息: 输出设备包括计算机显示器、打印机、磁带等等输出设备,如果是显示器可以采用抓屏的方式获取当时的截图,其他的输出设备可以采用其它方法获取相关的输出,在问题报告单中提供描述。
日志信息: 规范的软件产品都会提供软件的运行日志和用户、管理员的操作日志,测试人员应该把测试用例执行后的软件产品运行日志和操作日志作为附件,提交到问题报告单中。
根据被测试软件产品的不同,需要在 “ 问题描述 ” 中增加相应的描述内容,这需要具体问题具体分析。
• 测试结果分析
软件测试执行结束后,测试活动还没有结束。测试结果分析是必不可少的重要环节, “ 编筐编篓,全在收口 ” ,测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的 “ 测试准备工作 ” 中,建议测试人员走读缺陷跟踪库,查阅其他测试人员发现的软件缺陷。测试结束后,也应该分析自己发现的软件缺陷,对发现的缺陷分类,你会发现自己提交的问题只有固定的几个类别;然后,再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来,你会发现,你所提交问题的类别与他们有差异。这很正常,人的思维是有局限性,在测试的过程中,每个测试人员都有自己思考问题的盲区和测试执行的盲区,有效的自我分析和分析其他测试人员,你会发现自己的盲区,有针对性的分析盲区,必定会在下一轮测试用避免盲区。
总结:
限于文章的篇幅,本文不可能给出一个类似于 checklist 的指导性的软件测试新手入门。无论从事软件测试还是从事其它的工作,技术上的和技巧上的问题都可以通过查询相关的软件测试技术书籍获取,掌握一套基本的方法论是最重要的。以上文字,都是作者从事软件测试工作积累的经验之谈,如发现谬误之处请不吝指出。