-
手工与自动化
2008-09-09 16:11:17
1.首先说一下什么时候不该用自动测试:
手工很容易测试的程序。
只需要测试一次的程序。
要马上进行测试的程序。
要使用直觉和经验才能测试的程序。
不可预知结果的程序。
2.什么时候该用自动测试
要经常执行测试的程序。
压力测试。(例如多用户执行、一个程序执行几万遍) -
一道有关榨汁机的面试题的思考(转)
2008-09-03 11:09:06
对于一台榨汁机的需求阶段,需求还没有整理出来,测试人员先行介入,测试人员应该从哪些方面考虑测试用例?
我不知道是哪位仁兄出的这道题目,也不知道这位仁兄的原意如何。但是如果要我来回答,那我的答案是:“无可奉告”。
我 们先来回顾一下软件测试的定义。现在一般分为两派,一派认为软件测试是为了证明软件“可以工作”,另外一派认为软件测试是为了证明软件“不能工作”。好, 不管是那派,他们都需要有一个可以测试的东西作为基础,才能开始下面的证明工作。出题目的仁兄告诉我们,“需求还没整理出来”,测试人员就“先行介入” 了。如果不是题目的陷阱,那只能认为这个项目的团队“有问题”。在需求还不明确的前提下,测试人员可以做的事情有两个:一是学习和项目有关的基础知识,剩 下的就是等待。(需要指出的是,在需求不明确的前提下,开发人员是无法开始做high level design的,更加谈不上让测试人员参与design的讨论)
回到题目上来,我们假设题目有所改变,该榨汁机是一台普通的榨汁机,插电后放入水果或者蔬菜,按动开关,就可以榨汁。(和市面上能买到的差不多)那么需要如何考虑测试用例?虽然没实际用过榨汁机,但是靠想象应该也差不多。
1. 考虑90%以上用户的使用习惯,确保最基本的功能-榨汁能够正常运作。
* 通常的水果:西瓜、番茄、黄瓜、苹果、草莓、香蕉、李子、甘蔗等单独作为输入。
* 非常见:玉米
* 水果的混编作为输入。
* 在输入容器所能容纳的情况下,输出的量杯是否足够大能容纳榨出的液体。
* 在水果较硬的情况下,是否能正常工作。
* 水果较软的情况下,是否能正常工作。
* 如果有按钮或开关调节,测试按钮或开关的可用性和有效性。
2. 易用性测试
* 榨汁机的外观是否美观。这是用户选择的关键。
* 榨汁机的电源线长度是否足够。
* 量杯大小测试
3. Force Error测试
* 在空转情况(无输入)下做榨汁
* 在有异物(如蔬果的枝叶)的情况下做榨汁
* 在榨汁过程中停电,看是否能恢复
* 110v电源输入测试
* 在高温的情况是否能正常工作(40度以上)
* 在周围有磁场的情况下是否能正常工作
* 掉落测试
4. Security 测试
* 是否有儿童手指保护措施?
* 在榨汁有漏出的情况下,是否会有漏电?
5. 耐用性测试
* 刀片耐用度测试
* 平均无故障时间统计
* 按钮或开关耐用度测试
* 榨汁机使用寿命测试
* 榨汁机本体容器压强测试 -
软件测试之常用的功能测试方法解析(转)
2008-09-03 11:08:33
功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。常用的测试方法如下:页面链接检查:每一个链接是否都有对应的页面,并且页面之间切换正确。
1. 页面链接检查:每一个链接是否都有对应的页面,并且页面之间切换正确。2. 相关性检查:删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确。
3. 检查按钮的功能是否正确:如update, cancel, delete, save等功能是否正确。
4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致
9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.
-
测试术语
2008-09-03 11:04:57
AcceptanceTesting--可接受性测试
一般由用户/客户进行的确认是否可以接受一个产品的验证性测试。
actualoutcome--实际结果
被测对象在特定的条件下实际产生的结果。
AdHocTesting--随机测试
测试人员通过随机的尝试系统的功能,试图使系统中断。
algorithm--算法
(1)一个定义好的有限规则集,用于在有限步骤内解决一个问题;(2)执行一个特定任务的任何操作序列。
algorithmanalysis--算法分析
一个软件的验证确认任务,用于保证选择的算法是正确的、合适的和稳定的,并且满足所有精确性、规模和时间方面的要求。
AlphaTesting--Alpha测试
由选定的用户进行的产品早期性测试。这个测试一般在可控制的环境下进行的。
analysis--分析
(1)分解到一些原子部分或基本原则,以便确定整体的特性;(2)一个推理的过程,显示一个特定的结果是假设前提的结果;(3)一个问题的方法研究,并且问题被分解为一些小的相关单元作进一步详细研究。
anomaly--异常
在文档或软件操作中观察到的任何与期望违背的结果。
applicationsoftware--应用软件
满足特定需要的软件。
architecture--构架
一个系统或组件的组织结构。
ASQ--自动化软件质量(AutomatedSoftwareQuality)
使用软件工具来提高软件的质量。
assertion--断言
指定一个程序必须已经存在的状态的一个逻辑表达式,或者一组程序变量在程序执行期间的某个点上必须满足的条件。
assertionchecking--断言检查
用户在程序中嵌入的断言的检查。
audit--审计
一个或一组工作产品的独立检查以评价与规格、标准、契约或其它准则的符合程度。
audittrail--审计跟踪
系统审计活动的一个时间记录。
AutomatedTesting--自动化测试
使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试中用得较多。
Backus-NaurForm--BNF范式
一种分析语言,用于形式化描述语言的语法
baseline--基线
一个已经被正式评审和批准的规格或产品,它作为进一步开发的一个基础,并且必须通过正式的变更流程来变更。
BasicBlock--基本块
一个或多个顺序的可执行语句块,不包含任何分支语句。
basistestset--基本测试集
根据代码逻辑引出来的一个测试用例集合,它保证能获得100%的分支覆盖。
behaviour--行为
对于一个系统的一个函数的输入和预置条件组合以及需要的反应。一个函数的所有规格包含一个或多个行为。
benchmark--标杆/指标/基准
一个标准,根据该标准可以进行度量或比较。
BetaTesting--Beta测试
在客户场地,由客户进行的对产品预发布版本的测试。这个测试一般是不可控的。
big-bangtesting--大锤测试/一次性集成测试
非渐增式集成测试的一种策略,测试的时候把所有系统的组件一次性组合成系统进行测试。
BlackBoxTesting--黑盒测试
根据软件的规格对软件进行的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。
bottom-uptesting--由低向上测试
渐增式集成测试的一种,其策略是先测试底层的组件,然后逐步加入较高层次的组件进行测试,直到系统所有组件都加入到系统。
boundaryvalue--边界值
一个输入或输出值,它处在等价类的边界上。
boundaryvaluecoverage--边界值覆盖
通过测试用例,测试组件等价类的所有边界值。
boundaryvaluetesting--边界值测试
通过边界值分析方法来生成测试用例的一种测试策略。
BoundryValueAnalysis--边界值分析
该分析一般与等价类一起使用。经验认为软件的错误经常在输入的边界上产生,因此边界值分析就是分析软件输入边界的一种方法。
branch--分支
在组件中,控制从任何语句到其它任何非直接后续语句的一个条件转换,或者是一个无条件转换。
branchcondition--分支条件
branchconditioncombinationcoverage--分支条件组合覆盖
在每个判定中所有分支条件结果组合被测试用例覆盖到的百分比。
branchconditioncombinationtesting--分支条件组合测试
通过执行分支条件结果组合来设计测试用例的一种方法。
branchconditioncoverage--分支条件覆盖
每个判定中分支条件结果被测试用例覆盖到的百分比。
branchconditiontesting--分支条件测试
通过执行分支条件结果来设计测试用例的一种方法。
branchcoverage--分支覆盖
通过测试执行到的分支的百分比。
branchoutcome--分支结果
见判定结果(decisionoutcome)
branchpoint--分支点
见判定(decision)
branchtesting--分支测试
通过执行分支结果来设计测试用例的一种方法。
BreadthTesting--广度测试
在测试中测试一个产品的所有功能,但是不测试更细节的特性。
bug--缺陷
capture/playbacktool--捕获/回放工具
参考capture/replaytool
Capture/ReplayTool--捕获/回放工具
一种测试工具,能够捕获在测试过程中传递给软件的输入,并且能够在以后的时间中,重复这个执行的过程。这类工具一般在GUI测试中用的较多。
CASE--计算机辅助软件工程(computeraidedsoftwareengineering)
用于支持软件开发的一个自动化系统。
CAST--计算机辅助测试
在测试过程中使用计算机软件工具进行辅助的测试。
cause-effectgraph--因果图
一个图形,用来表示输入(原因)与结果之间的关系,可以被用来设计测试用例。
certification--证明
一个过程,用于确定一个系统或组件与特定的需求相一致。
changecontrol--变更控制
一个用于计算机系统或系统数据修改的过程,该过程是质量保证程序的一个关键子集,需要被明确的描述。
codeaudit--代码审计
由一个人、组或工具对源代码进行的一个独立的评审,以验证其与设计规格、程序标准的一致性。正确性和有效性也会被评价。
CodeCoverage--代码覆盖率
一种分析方法,用于确定在一个测试套执行后,软件的哪些部分被执行到了,哪些部分没有被执行到。
CodeInspection--代码检视
一个正式的同行评审手段,在该评审中,作者的同行根据检查表对程序的逻辑进行提问,并检查其与编码规范的一致性。
CodeWalkthrough--代码走读
一个非正式的同行评审手段,在该评审中,代码被使用一些简单的测试用例进行人工执行,程序变量的状态被手工分析,以分析程序的逻辑和假设。
code-basedtesting--基于代码的测试
根据从实现中引出的目标设计测试用例。
codingstandards--编程规范
一些编程方面需要遵循的标准,包括命名方式、排版格式等内容。
CompatibilityTesting--兼容性测试
测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。
completepathtesting--完全路径测试
参考穷尽测试(exhaustivetesting)
completeness--完整性
实体的所有必须部分必须被包含的属性。
complexity--复杂性
系统或组件难于理解或验证的程度。
Component--组件
一个最小的软件单元,有着独立的规格
ComponentTesting--组件测试
参考单元测试
computationdatause--计算数据使用
一个不在条件中的数据使用。
computersystemsecurity--计算机系统安全性
计算机软件和硬件对偶然的或故意的访问、使用、修改或破坏的一种保护机制。
condition--条件
一个不包含布尔操作的布尔表达式,例如:A
conditioncoverage--条件覆盖
通过测试执行到的条件的百分比。
conditionoutcome--条件结果
条件为真为假的评价。
configurationcontrol--配置控制
配置管理的一个方面,包括评价、协调、批准、和实现配置项的变更。
configurationmanagement--配置管理
一套技术和管理方面的原则用于确定和文档化一个配置项的功能和物理属性、控制对这些属性的变更、记录和报告变更处理和实现的状态、以及验证与指定需求的一致性。
conformancecriterion--一致性标准
判断组件在一个特定输入值上的行为是否符合规格的一种方法。
ConformanceTesting--一致性测试
测试一个系统的实现是否和其基于的规格相一致的测试。
consistency--一致性
在系统或组件的各组成部分和文档之间没有矛盾,一致的程度。
consistencychecker--一致性检查器
一个软件工具,用于测试设计规格中需求的一致性和完整性。
controlflow--控制流
程序执行中所有可能的事件顺序的一个抽象表示。
controlflowgraph--控制流图
通过一个组件的可能替换控制流路径的一个图形表示。
conversiontesting--转换测试
用于测试已有系统的数据是否能够转换到替代系统上的一种测试。
correctivemaintenance--故障检修
用于纠正硬件或软件中故障的维护。
correctness--正确性
软件遵从其规格的程度。
correctness--正确性
软件在其规格、设计和编码中没有故障的程度。软件、文档和其它项满足需求的程度。软件、文档和其它项满足用户明显的和隐含的需求的程度。
coverage--覆盖率
用于确定测试所执行到的覆盖项的百分比。
coverageitem--覆盖项
作为测试基础的一个入口或属性:如语句、分支、条件等。
crash--崩溃
计算机系统或组件突然并完全的丧失功能。
criticality--关键性
需求、模块、错误、故障、失效或其它项对一个系统的操作或开发影响的程度。
criticalityanalysis--关键性分析
需求的一种分析,它根据需求的风险情况给每个需求项分配一个关键级别。
cyclomaticcomplexity--循环复杂度
一个程序中独立路径的数量。
datacorruption--数据污染
违背数据一致性的情况。
datadefinition--数据定义
一个可执行语句,在该语句上一个变量被赋予了一个值。
datadefinitionC-usecoverage--数据定义C-use覆盖
在组件中被测试执行到的数据定义C-use使用对的百分比。
datadefinitionC-usepair--数据定义C-use使用对
一个数据定义和一个计算数据使用,数据使用的值是数据定义的值。
datadefinitionP-usecoverage--数据定义P-use覆盖
在组件中被测试执行到的数据定义P-use使用对的百分比。
datadefinitionP-usepair--数据定义P-use使用对
一个数据定义和一个条件数据使用,数据使用的值是数据定义的值。
datadefinition-usecoverage--数据定义使用覆盖
在组件中被测试执行到的数据定义使用对的百分比。
datadefinition-usepair--数据定义使用对
一个数据定义和一个数据使用,数据使用的值是数据定义的值。
datadefinition-usetesting--数据定义使用测试
以执行数据定义使用对为目标进行测试用例设计的一种技术。
datadictionary--数据字典
(1)一个软件系统中使用的所有数据项名称,以及这些项相关属性的集合。(2)数据流、数据元素、文件、数据基础、和相关处理的一个集合。
dataflowanalysis--数据流分析
一个软件验证和确认过程,用于保证输入和输出数据和它们的格式是被适当定义的,并且数据流是正确的。
dataflowcoverage--数据流覆盖
测试覆盖率的度量是根据变量在代码中的使用情况。
dataflowdiagram--数据流图
把数据源、数据接受、数据存储和数据处理作为节点描述的一个图形,数据之间的逻辑体现为节点之间的边。
dataflowtesting--数据流测试
根据代码中变量的使用情况进行的测试。
dataintegrity--数据完整性
一个数据集合完全、正确和一致的程度。
datause--数据使用
一个可执行的语句,在该语句中,变量的值被访问。
datavalidation--数据确认
用于确认数据不正确、不完整和不合理的过程。
deadcode--死代码
在程序操作过程中永远不可能被执行到的代码。
Debugging--调试
发现和去除软件失效根源的过程。
decision--判定
一个程序控制点,在该控制点上,控制流有两个或多个可替换路由。
Decisioncondition--判定条件
判定内的一个条件。
decisioncoverage--判定覆盖
在组件中被测试执行到的判定结果的百分比。
decisionoutcome--判定结果
一个判定的结果,决定控制流走哪条路径。
decisiontable--判定表
一个表格,用于显示条件和条件导致动作的集合。
DepthTesting--深度测试
执行一个产品的一个特性的所有细节,但不测试所有特性。比较广度测试。
designofexperiments--实验设计
一种计划实验的方法,这样适合分析的数据可以被收集。
design-basedtesting--基于设计的测试
根据软件的构架或详细设计引出测试用例的一种方法。
deskchecking--桌面检查
通过手工模拟软件执行的方式进行测试的一种方式。
diagnostic--诊断
检测和隔离故障或失效的过程。
dirtytesting--肮脏测试
参考负面测试(negativetesting)
disasterrecovery--灾难恢复
一个灾难的恢复和重建过程或能力。
documentationtesting--文档测试
测试关注于文档的正确性。
domain--域
值被选择的一个集合。
domaintesting--域测试
参考等价划分测试(equivalencepartitiontesting)
dynamicanalysis--动态分析
根据执行的行为评价一个系统或组件的过程。
DynamicTesting--动态测试
通过执行软件的手段来测试软件。
embeddedsoftware--嵌入式软件
软件运行在特定硬件设备中,不能独立于硬件存在。这类系统一般要求实时性较高。
emulator--仿真
一个模仿另一个系统的系统或设备,它接受相同的输入并产生相同的输出。
End-to-Endtesting--端到端测试
在一个模拟现实使用的场景下测试一个完整的应用环境,例如和数据库交互,使用网络通信等。
entityrelationshipdiagram--实体关系图
描述现实世界中实体及它们关系的图形。
entrypoint--入口点
一个组件的第一个可执行语句。
EquivalenceClass--等价类
组件输入或输出域的一个部分,在该部分中,组件的行为从组件的规格上来看认为是相同的。
equivalencepartitioncoverage--等价划分覆盖
在组件中被测试执行到的等价类的百分比。
equivalencepartitiontesting--等价划分测试
根据等价类设计测试用例的一种技术。
EquivalencePartitioning--等价划分
组件的一个测试用例设计技术,该技术从组件的等价类中选取典型的点进行测试。
error--错误
IEEE的定义是:一个人为产生不正确结果的行为。
errorguessing--错误猜测
根据测试人员以往的经验猜测可能出现问题的地方来进行用例设计的一种技术。
errorseeding--错误播种/错误插值
故意插入一些已知故障(fault)到一个系统中去的过程,目的是为了根据错误检测和跟踪的效率并估计系统中遗留缺陷的数量。
exception--异常/例外
一个引起正常程序执行挂起的事件。
executablestatement--可执行语句
一个语句在被编译后会转换成目标代码,当程序运行是会被执行,并且可能对程序数据产生动作。
ExhaustiveTesting--穷尽测试
测试覆盖软件的所有输入和条件组合。
exitpoint--出口点
一个组件的最后一个可执行语句。
expectedoutcome--期望结果
参考预期结果(predictedoutcome)。
failure--失效
软件的行为与其期望的服务相背离。
fault--故障
在软件中一个错误的表现。
feasiblepath--可达路径
可以通过一组输入值和条件执行到的一条路径。
featuretesting--特性测试
参考功能测试(FunctionalTesting)
FMEA--失效模型效果分析(FailureModesandEffectsAnalysis)
可靠性分析中的一种方法,用于在基本组件级别上确认对系统性能有重大影响的失效。
FMECA--失效模型效果关键性分析(FailureModesandEffectsCriticalityAnalysis)
FMEA的一个扩展,它分析了失效结果的严重性。
FTA--故障树分析(FaultTreeAnalysis)
引起一个不需要事件产生的条件和因素的确认和分析,通常是严重影响系统性能、经济性、安全性或其它需要特性。
functionaldecomposition--功能分解
参考模块分解(modulardecomposition)
FunctionalSpecification--功能规格说明书
一个详细描述产品特性的文档。
FunctionalTesting--功能测试
测试一个产品的特性和可操作行为以确定它们满足规格。
glassboxtesting--玻璃盒测试
参考白盒测试(WhiteBoxTesting)
IEEE--美国电子与电器工程师学会(InstituteofElectricalandElectronicEngineers)
incrementaltesting--渐增测试
集成测试的一种,组件逐渐被增加到系统中直到整个系统被集成。
infeasiblepath--不可达路径
不能够通过任何可能的输入值集合执行到的路径。
inputdomain--输入域
所有可能输入的集合。
inspection--检视
对文档进行的一种评审形式。
installabilitytesting--可安装性测试
确定系统的安装程序是否正确的测试。
instrumentation--插装
在程序中插入额外的代码以获得程序在执行时行为的信息。
instrumenter--插装器
执行插装的工具
IntegrationTesting--集成测试
测试一个应用组合后的部分以确保它们的功能在组合之后正确。该测试一般在单元测试之后进行。
interface--接口
两个功能单元的共享边界。
interfaceanalysis--接口分析
分析软件与硬件、用户和其它软件之间接口的需求规格。
interfacetesting--接口测试
测试系统组件间接口的一种测试。
invalidinputs--无效输入
在程序功能输入域之外的测试数据。
isolationtesting--孤立测试
组件测试(单元测试)策略中的一种,把被测组件从其上下文组件之中孤立出来,通过设计驱动和桩进行测试的一种方法。
Job--工作
一个用户定义的要计算机完成的工作单元。
jobcontrollanguage--工作控制语言
用于确定工作顺序,描述它们对操作系统要求并控制它们执行的语言。
LCSAJ--线性代码顺序和跳转(LinearCodeSequenceAndJump)
包含三个部分:可执行语句线性顺序的起始,线性顺序的结束,在线性顺序结束处控制流跳转的目标语句。
LCSAJcoverage--LCSAJ覆盖
在组件中被测试执行到的LCSAJ的百分比。
LCSAJtesting--LCSAJ测试
根据LCSAJ设计测试用例的一种技术。
LoadTesting--负载测试
通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。
logicanalysis--逻辑分析
(1)评价软件设计的关键安全方程式、算法和控制逻辑的方法。(2)评价程序操作的顺序并且检测可能导致灾难的错误。
logic-coveragetesting--逻辑覆盖测试
参考结构化测试用例设计(structuraltestcasedesign)
maintainability--可维护性
一个软件系统或组件可以被修改的容易程度,这个修改一般是因为缺陷纠正、性能改进或特性增加引起的。
maintainabilitytesting--可维护性测试
测试系统是否满足可维护性目标。
modifiedcondition/decisioncoverage--修改条件/判定覆盖
在组件中被测试执行到的修改条件/判定的百分比。
modifiedcondition/decisiontesting--修改条件/判定测试
根据MC/DC设计测试用例的一种技术。
MonkeyTesting--跳跃式测试
随机性,跳跃式的测试一个系统,以确定一个系统是否会崩溃。
MTBF--平均失效间隔实际(meantimebetweenfailures)
两次失效之间的平均操作时间。
MTTF--平均失效时间(meantimetofailure)
第一次失效之前的平均时间
MTTR--平均修复时间(meantimetorepair)
两次修复之间的平均时间
multipleconditioncoverage--多条件覆盖
参考分支条件组合覆盖(branchconditioncombinationcoverage)
mutationanalysis--变体分析
一种确定测试用例套完整性的方法,该方法通过判断测试用例套能够区别程序与其变体之间的程度。
NegativeTesting--逆向测试/反向测试/负面测试
测试瞄准于使系统不能工作。
non-functionalrequirementstesting--非功能性需求测试
与功能不相关的需求测试,如:性能测试、可用性测试等。
N-switchcoverage--N切换覆盖
在组件中被测试执行到的N转换顺序的百分比。
N-switchtesting--N切换测试
根据N转换顺序设计测试用例的一种技术,经常用于状态转换测试中。
N-transitions--N转换
N+1转换顺序
operationaltesting--可操作性测试
在系统或组件操作的环境中评价它们的表现。
outputdomain--输出域
所有可能输出的集合。
partitiontesting--分类测试
参考等价划分测试(equivalencepartitiontesting)
path--路径
一个组件从入口到出口的一条可执行语句顺序。
pathcoverage--路径覆盖
在组件中被测试执行到的路径的百分比。
pathsensitizing--路径敏感性
选择一组输入值强制组件走一个给定的路径。
pathtesting--路径测试
根据路径设计测试用例的一种技术,经常用于状态转换测试中。
performancetesting--性能测试
评价一个产品或组件与性能需求是否符合的测试。
portabilitytesting--可移植性
测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。
PositiveTesting--正向测试
测试瞄准于显示系统能够正常工作。
precondition--预置条件
环境或状态条件,组件执行之前必须被填充一个特定的输入值。
predicate--谓词
一个逻辑表达式,结果为‘真’或‘假’。
predicatedatause--谓词数据使用
在谓词中的一个数据使用。
programinstrumenter--程序插装
参考插装(instrumenter)
progressivetesting--递进测试
在先前特性回归测试之后对新特性进行测试的一种策略。
pseudo-random--伪随机
看似随机的,实际上是根据预先安排的顺序进行的。
QA--质量保证(qualityassurance)
(1)已计划的系统性活动,用于保证一个组件、模块或系统遵从已确立的需求。(2)采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。
QC--质量控制(qualitycontrol)
用于获得质量需求的操作技术和过程,如测试活动。
RaceCondition--竞争状态
并行问题的根源。对一个共享资源的多个访问,至少包含了一个写操作,但是没有一个机制来协调同时发生的访问。
recoverytesting--恢复性测试
验证系统从失效中恢复能力的测试。
regressionanalysisandtesting--回归分析和测试
一个软件验证和确认任务以确定在修改后需要重复测试和分析的范围。
RegressionTesting--回归测试
在发生修改之后重新测试先前的测试以保证修改的正确性。
release--发布
一个批准版本的正式通知和分发。
reliability--可靠性
一个系统或组件在规定的条件下在指定的时间内执行其需要功能的能力。
reliabilityassessment--可靠性评价
确定一个已有系统或组件的可靠性级别的过程。
requirements-basedtesting--基于需求的测试
根据软件组件的需求导出测试用例的一种设计方法。
review--评审
在产品开发过程中,把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。
risk--风险
不期望效果的可能性和严重性的一个度量。
riskassessment--风险评估
对风险和风险影响的一个完整的评价。
safety--(生命)安全性
不会引起人员伤亡、产生疾病、毁坏或损失设备和财产、或者破坏环境。
safetycritical--严格的安全性
一个条件、事件、操作、过程或项,它的认识、控制或执行对生命安全性的系统来说是非常关键的。
SanityTesting--理智测试
软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考冒烟测试
SDP--软件开发计划(softwaredevelopmentplan)
用于一个软件产品开发的项目计划。
securitytesting--安全性测试
验证系统是否符合安全性目标的一种测试。
security.--(信息)安全性
参考计算机系统安全性(computersystemsecurity)
serviceabilitytesting--可服务性测试
参考可维护性测试(maintainabilitytesting)
simplesubpath--简单子路径
控制流的一个子路径,其中没有不必要的部分被执行。
simulation--模拟
使用另一个系统来表示一个物理的或抽象的系统的选定行为特性。
simulation--模拟
使用一个可执行模型来表示一个对象的行为。
simulator--模拟器
软件验证期间的一个设备、软件程序、或系统,当它给定一个控制的输入时,表现的与一个给定的系统类似。
SLA--服务级别协议(servicelevelagreement)
服务提供商与客户之间的一个协议,用于规定服务提供商应当提供什么服务。
SmokeTesting--冒烟测试
对软件主要功能进行快餐式测试。最早来自于硬件测试实践,以确定新的硬件在第一次使用的时候不会着火。
softwaredevelopmentprocess--软件开发过程
一个把用户需求转换为软件产品的开发过程。
softwarediversity--软件多样性
一种软件开发技术,其中,由不同的程序员或开发组开发的相同规格的不同程序,目的是为了检测错误、增加可靠性。
softwareelement--软件元素
软件开发或维护期间产生或获得的一个可交付的或过程内的文档。
softwareengineering--软件工程
一个应用于软件开发、操作和维护的系统性的、有纪律的、可量化的方法。
softwareengineeringenvironment--软件工程环境
执行一个软件工程工作的硬件、软件和固件。
softwarelifecycle--软件生命周期
开始于一个软件产品的构思,结束于该产品不再被使用的这段期间。
SOP--标准操作过程(standardoperatingprocedures)
书面的步骤,这对保证生产和处理的控制是必须的。
sourcecode--源代码
用一种适合于输入到汇编器、编译器或其它转换设备的计算机指令和数据定义。
sourcestatement--源语句
参考语句(statement)
specification--规格
组件功能的一个描述,格式是:对指定的输入在指定的条件下的输出。
specifiedinput--指定的输入
一个输入,根据规格能预知其输出。
spiralmodel--螺旋模型
软件开发过程的一个模型,其中的组成活动,典型的包括需求分析,概要设计,详细设计,编码,集成和测试等活动被迭代的执行直到软件被完成。
SQL--结构化查询语句(structuredquerylanguage)
在一个关系数据库中查询和处理数据的一种语言。
state--状态
一个系统、组件或模拟可能存在其中的一个条件或模式。
statediagram--状态图
一个图形,描绘一个系统或组件可能假设的状态,并且显示引起或导致一个状态切换到另一个状态的事件或环境。
statetransition--状态转换
一个系统或组件的两个允许状态之间的切换。
statetransitiontesting--状态转换测试
根据状态转换来设计测试用例的一种方法。
statement--语句
程序语言的一个实体,是典型的最小可执行单元。
statementcoverage--语句覆盖
在一个组件中,通过执行一定的测试用例所能达到的语句覆盖百分比。
statementtesting--语句测试
根据语句覆盖来设计测试用例的一种方法。
StaticAnalysis--静态分析
分析一个程序的执行,但是并不实际执行这个程序。
StaticAnalyzer--静态分析器
进行静态分析的工具。
StaticTesting--静态测试
不通过执行来测试一个系统。
statisticaltesting--统计测试
通过使用对输入统计分布进行分析来构造测试用例的一种测试设计方法。
stepwiserefinement--逐步优化
一个结构化软件设计技术,数据和处理步骤首先被广泛的定义,然后被逐步的进行了细化。
storagetesting--存储测试
验证系统是否满足指定存储目标的测试。
StressTesting--压力测试
在规定的规格条件或者超过规定的规格条件下,测试一个系统,以评价其行为。类似负载测试,通常是性能测试的一部分。
structuralcoverage--结构化覆盖
根据组件内部的结构度量覆盖率。
structuraltestcasedesign--结构化测试用例设计
根据组件内部结构的分析来设计测试用例的一种方法。
structuraltesting--结构化测试
参考结构化测试用例设计(structuraltestcasedesign)
structuredbasistesting--结构化的基础测试
根据代码逻辑设计测试用例来获得100%分支覆盖的一种测试用例设计技术。
structureddesign--结构化设计
软件设计的任何遵循一定纪律的方法,它按照特定的规则,例如:模块化,有顶向下设计,数据逐步优化,系统结构和处理步骤。
structuredprogramming--结构化编程
在结构化程序开发中的任何包含结构化设计和结果的软件开发技术。
structuredwalkthrough--结构化走读
参考走读(walkthrough)
stub--桩
一个软件模块的框架或特殊目标实现,主要用于开发和测试一个组件,该组件调用或依赖这个模块。
symbolicevaluation--符号评价
参考符号执行(symbolicexecution)
symbolicexecution--符号执行
通过符号表达式来执行程序路径的一种静态分析设计技术。其中,程序的执行被用符号来模拟,例如,使用变量名而不是实际值,程序的输出被表示成包含这些符号的逻辑或数学表达式。
symbolictrace--符号轨迹
一个计算机程序通过符号执行是经过的语句分支结果的一个记录。
syntaxtesting--语法分析
根据输入语法来验证一个系统或组件的测试用例设计技术。
systemanalysis--系统分析
对一个计划的或现实的系统进行的一个系统性调查以确定系统的功能以及系统与其它系统之间的交互。
systemdesign--系统设计
一个定义硬件和软件构架、组件、模块、接口和数据的过程以满足指定的规格。
systemintegration--系统集成
一个系统组件的渐增的连接和测试,直到一个完整的系统。
SystemTesting--系统测试
从一个系统的整体而不是个体上来测试一个系统,并且该测试关注的是规格,而不是系统内部的逻辑。
technicalrequirementstesting--技术需求测试
参考非功能需求测试(non-functionalrequirementstesting)
testautomation--测试自动化
使用工具来控制测试的执行、结果的比较、测试预置条件的设置、和其它测试控制和报告功能。
testcase--测试用例
用于特定目标而开发的一组输入、预置条件和预期结果。
testcasedesigntechnique--测试用例设计技术
选择和导出测试用例的技术。
testcasesuite--测试用例套
对被测软件的一个或多个测试用例的集合。
testcomparator--测试比较器
一个测试工具用于比较软件实际测试产生的结果与测试用例预期的结果。
testcompletioncriterion--测试完成标准
一个标准用于确定被计划的测试何时完成。
testcoverage--测试覆盖
参考覆盖率(Coverage)
testdriver--测试驱动
一个程序或测试工具用于根据测试套执行软件。
testenvironment--测试环境
测试运行其上的软件和硬件环境的描述,以及任何其它与被测软件交互的软件,包括驱动和桩。
testexecution--测试执行
一个测试用例被被测软件执行,并得到一个结果。
testexecutiontechnique--测试执行技术
执行测试用例的技术,包括手工、自动化等。
testgenerator--测试生成器
根据特定的测试用例产生测试用例的工具。
testharness--测试用具
包含测试驱动和测试比较器的测试工具。
testlog--测试日志
一个关于测试执行所有相关细节的时间记录。
testmeasurementtechnique--测试度量技术
度量测试覆盖率的技术。
TestPlan--测试计划
一个文档,描述了要进行的测试活动的范围、方法、资源和进度。它确定测试项、被测特性、测试任务、谁执行任务,并且任何风险都要冲突计划。
testprocedure--测试规程
一个文档,提供详细的测试用例执行指令。
testrecords--测试记录
对每个测试,明确的记录被测组件的标识、版本,测试规格,和实际结果
testreport--测试报告
一个描述系统或组件执行的测试和结果的文档。
Testscrīpt--测试脚本
一般指的是一个特定测试的一系列指令,这些指令可以被自动化测试工具执行。
TestSpecification--测试规格
一个文档,用于指定一个软件特性、特性组合或所有特性的测试方法、输入、预期结果和执行条件。
teststrategy--测试策略
一个简单的高层文档,用于描述测试的大致方法,目标和方向。
testsuite--测试套
测试用例和/或测试脚本的一个集合,与一个应用的特定功能或特性相关。
testtarget--测试目标
一组测试完成标准。
testability--可测试性
一个系统或组件有利于测试标准建立和确定这些标准是否被满足的测试执行的程度。
Testing--测试
IEEE给出的定义是:1)一个执行软件的过程,以验证其满足指定的需求并检测错误。2)一个软件项的分析过程以检测已有条件之间的不同,并评价软件项的特性。
threadtesting--线程测试
自顶向下测试的一个变化版本,其中,递增的组件集成遵循需求子集的实现。
timesharing--时间共享
一种操作方式,允许两个或多个用户在相同的计算机系统上同时执行计算机程序。其实现可能通过时间片轮转、优先级中断等。
top-downdesign--由顶向下设计
一种设计策略,首先设计最高层的抽象和处理,然后逐步向更低级别进行设计。
top-downtesting--自顶向下测试
集成测试的一种策略,首先测试最顶层的组件,其它组件使用桩,然后逐步加入较低层的组件进行测试,直到所有组件被集成到系统中。
traceability--可跟踪性
开发过程的两个或多个产品之间关系可以被建立起来的程度,尤其是产品彼此之间有一个前后处理关系。
traceabilityanalysis--跟踪性分析
(1)跟踪概念文档中的软件需求到系统需求;(2)跟踪软件设计描述到软件需求规格,以及软件需求规格到软件设计描述;(3)跟踪源代码对应到设计规格,以及设计规格对应到源代码。分析确定它们之间正确性、一致性、完整性、精确性的关系。
traceabilitymatrix--跟踪矩阵
一个用于记录两个或多个产品之间关系的矩阵。例如,需求跟踪矩阵是跟踪从需求到设计再到编码的实现。
transaction--事务/处理
(1)一个命令、消息或输入记录,它明确或隐含的调用了一个处理活动,例如更新一个文件。(2)用户和系统之间的一次交互。(3)在一个数据库管理系统中,完成一个特定目的的处理单元,如恢复、更新、修改或删除一个或多个数据元素。
transformanalysis--事务分析
系统的结构是根据分析系统需要处理的事务获得的一种分析技术。
trojanhorse--特洛伊木马
一种攻击计算机系统的方法,典型的方法是提供一个包含具有攻击性隐含代码的有用程序给用户,在用户执行该程序的时候,其隐含的代码对系统进行非法访问,并可能产生破坏。
truthtable--真值表
用于逻辑操作的一个操作表格。
UnitTesting--单元测试
测试单个的软件组件,属于白盒测试范畴,其测试基础是软件内部的逻辑。
UsabilityTesting--可用性测试
测试用户使用和学习产品的容易程度。
validation--确认
根据用户需要确认软件开发的产品的正确性。
verification--验证
评价一个组件或系统以确认给定开发阶段的产品是否满足该阶段开始时设定的标准。
version--版本
一个软件项或软件元素的一个初始发布或一个完整的再发布。
volumetesting--容量测试
使用大容量数据测试系统的一种策略。
Walkthrough--走读
一个针对需求、设计或代码的非正式的同行评审,一般由作者发起,由作者的同行参与进行的评审过程。
waterfallmodel--瀑布模型
软件开发过程模型的一种,包括概念阶段、需求阶段、设计阶段、实现阶段、测试阶段、安装和检查阶段、操作和维护阶段,这些阶段按次序进行,可能有部分重叠,但很少会迭代。
WhiteBoxTesting--白盒测试
根据软件内部的工作原理分析来进行测试。 -
完善的测试依赖全面的测试计划
2008-09-03 11:03:56
在开发项目管理的运作中,究竟如何执行具体的测试呢?答案是:每个软件都有它的功能设计,通过它们为用户解决某些问题或提供某些服务。测试的目的有 两个:第一是要确证这些为用户解决某些问题的功能设计被正确无误地开发出来了,也就是说,如果用户按照所设计的使用方法和过程(我们称为User Scenario,即使用方案),的确能够利用这些功能所提供的服务和解决问题;第二是保证软件在被使用的情况下,如果使用者并不按照所设计的使用方案在 使用软件,它不应该由于任意的使用、或其它外部影响造成任何问题,包括出现差错,比如数据遗失、数据错误、 甚至造成系统崩溃等等。为了达到这两个不同的测试目的,在执行具体的测试时就要采用不同的测试方法。为达到第一个目的、也是最主要的目的,最佳的方法是根据所设计的每个功能和使 用方案,设计一个相对应的测试执行过程,去验证这个功能或使用方案是能够从头到尾完成的。这个测试执行过程的定义和描述我们称它为测试方案或测试案例 (Test Case)。要能够确证所有功能的确是准确地被开发出来了,唯一的办法就是为每一个使用方案都设计出大量的、一套完整的测试案例(在微软的产品开发中往往 都是几百甚至上千的测试案例在测试中被使用),然后通过对这些测试案例的按部就班的执行来证明软件的确可以完成所设计的功能。测试案例的全面性和完整性最 终决定了为达到第一个目的测试的质量。
要能够做到制定完整的测试案例,就需要有一个可以作为依据的纲领性指南,帮助测试人员设计这些案例。这样的纲领性指南是由一份叫做测试计划的文件来总结 的。测试计划在软件的设计规范书的基础上进行总结和撰写,根据具体的软件和使用要求,制定出整个软件产品的总体测试构思和设想、测试总体范围、对测试方法 和测试自动化工具的要求和定义等等。在测试计划的基础之上,测试工程师们根据它再进一步制定详细的具体测试方案。至于测试计划该怎样写,该包括什么内容, 我在《软件开发项目管理》一书的第十一章里有详细的测试计划文件的模版你可以参照使用,这里我就不再重复了。
-
测试用例实例
2008-09-03 11:03:25
1、 一个好的用例的表述要点,即用例中应当包含的信息
一个优秀的测试用例,应该包含以下信息:
1) 软件或项目的名称
2) 软件或项目的版本(内部版本号)
3) 功能模块名
4) 测试用例的简单描述,即该用例执行的目的或方法
5) 测试用例的参考信息(便于跟踪和参考)
6) 本测试用例与其他测试用例间的依赖关系
7) 本用例的前置条件,即执行本用例必须要满足的条件,如对数据库的访问权限
8) 用例的编号(ID),如可以是 软件名称简写-功能块简写-NO.。
9) 步骤号、操作步骤描述、测试数据描述
10) 预期结果(这是最重要的)和实际结果(如果有BUG管理工具,这条可以省略)
11)开发人员(必须有)和测试人员(可有可无)
12)测试执行日期
2、实例
该测试案例是以一个B/S结构的登录功能点位被测对象, 该测试用例为黑盒测试用例。假设用户使用的浏览器为IE6.0 SP4。
功能描述如下:
1. 用户在地址栏输入相应地址,要求显示登录界面;
2. 输入用户名和密码,登录,系统自动校验,并给出相应提示信息;
3. 如果用户名或者密码任一信息未输入,登录后系统给出相应提示信息;
4. 连续3次未通过验证时,自动关闭IE。
表4-1 登录界面测试用例
用例ID
XXXX-XX-XX
用例名称
系统登录
用例描述
系统登录
用户名存在、密码正确的情况下,进入系统
页面信息包含:页面背景显示
用户名和密码录入接口,输入数据后的登入系统接口
用例入口
打开IE,在地址栏输入相应地址
进入该系统登录页面
测试用例ID
场景
测试步骤
预期结果
备注
TC1
初始页面显示
从用例入口处进入
页面元素完整,显示与详细设计一致
TC2
用户名录入-验证
输入已存在的用户:test
输入成功
TC3
用户名-容错性验证
输入:aaaaabbbbbcccccdddddeeeee
输入到蓝色显示的字符时,系统拒绝输入
输入数据超过规定长度范围
TC4
密码-密码录入
输入与用户名相关联的数据:test
输入成功
TC5
系统登录-成功
TC2,TC4,单击登录按钮
登录系统成功
TC6
系统登录-用户名、密码校验
没有输入用户名、密码,单击登录按钮
系统登录失败,并提示:请检查用户名和密码的输入是否正确
TC7
系统登录-密码校验
输入用户名,没有输入密码,单击登录按钮
系统登录失败,并提示:需要输入密码
TC8
系统登录-密码有效性校验
输入用户名,输入密码与用户名不一致,单击登录按钮
系统登录失败,并提示:错误的密码
TC9
系统登录-输入有效性校验
输入不存在的用户名、密码,单击登录按钮
系统登录失败,并提示:用户名不存在
TC10
系统登录—安全校验
连续3次未成功
系统提示:您没有使用该系统的权限,请与管理员联系!
…
…
…
…
-
报表测试注意事项(z)
2008-09-03 11:01:21
进销存系统中的报表测试
报表功能的基本要求,就是通过查询/统计/分析,提供用户所需的准确的数据。如果无法实现这个基本功能,则报表完全失去意义。
对于用户来说,报表可以直接影响到他们的决策,例如可能因为报表对销售和库存情况反映的不准确,导致错误的大量进货;或者因为报表对应收应付金额计算的不准确,而导致企业对资金占用情况做出错误的估计,
从而导致错误的决策,最终造成用户在经营上的损失。诸如此类,相信只要大家留心,还可以找出很多这样的例子。
进 销存系统中的报表多如牛毛,而且各种不同行业的进销存系统中的业务有区别,报表也有些区别,因此不太可能对各种报表逐个讲解,而主要是把一些报表测试的经 验总结成了十几条可以在各种行业的报表测试中应用的“最佳实践”,来跟大家一起分享。希望下面的这十几条像一招招简单实用的“擒拿手”,可以供正在进行报 表测试或者准备开始作报表测试的朋友随手拈来,见招拆招,轻松应对这项工作。
(1) 提高对业务的熟悉程度
其 实对任何一个软件进行测试,都必须要熟悉它的业务,包括业务流程和业务规则。但是报表同一般的业务功能还是有些区别的。例如对于单据的增、删、改,通过对 界面的浏览和探索性的操作,大概都可以弄明白它的业务流程和业务规则,因为这些内容比较直观,而且在不同的行业中也差不了太多。但是在报表中,是很难直观 的看到我们所需要了解的内容的。例如报表中的某个数据项,它的算法或者说数据来源,恐怕是比较难看出来的——即使是很类似的一个数据项,在不同行业的实际 业务中,它的算法和数据来源也可以能完全不同的。
所 以对于报表业务的熟悉,主要是两个方面:数据项的算法和数据来源,也就是说要明白一个数据项同具体的业务有什么关系,单据的增、删、改或者状态的变化,对 报表中各个数据项的计算会产生什么不同的影响。如果不知道到这些,那么就无法验证报表中的数据是否准确,也无法通过报表去检查业务系统的正确与否。
(2) 覆盖所有可能的查询统计方式,而不是以自己的使用习惯为准
对 于报表的使用者来说——一般是企业的中层或高层领导,他们对于报表的要求可能会是多方面的,例如在进销存系统中,可能需要按不同商品进行分类统计,也可能 是按供应商分类统计,这些都是由用户在实际工作中的需要来决定的,所以假如一个报表提供了多种查询统计的方法,那么在测试时,只要时间充分,就应该覆盖这 些所有可能被用到的查询统计方法,而不是以自己的使用习惯为测试的依据。
(3) 使用或构造受控的数据环境
数据对于报表测试来说是一个非常非常重要的问题。因为上面说到,报表的基本功能就是通过各种查询统计分析的方法,为用户提供准确的数据,帮助用户做出决策。那么那些用来进行测试的数据从哪里来呢?
首先,应该保证准备足够多的有效的数据。前面一条也提到了,在实际测试报表时,应当尽可能的覆盖到报表所提供的各种查询统计方法,因此至少应该保证每一种查询统计方法都应该有对应的数据,得到的结果都不会是0,否则等于没有覆盖到这个被测的查询统计算法。当然数据也不是越多越好,能保证全部覆盖,并且刚好够用就可以了,因为数据的准备和生成也是很花时间的。
其 次,要保证数据的可控。数据并不是随意生成的,如果使用通过自动化工具或者通过业务测试时随意的输入的数据来进行报表测试,一般来说是不太可能的。因为如 果无法控制数据来源,那么即使知道报表中每个数据项的算法,也无法最终验证报表的查询统计结果是否正确。例如,系统的会有不同类型的单据,每种单据又会有 不同的状态,某个报表的统计中,可能会涉及到多种类型和状态的单据,那么在准备数据时,就要充分考虑到这一点,准备各种不同的单据来满足测试的要求。又比 如,如果整个系统中只有一个供应商,一个商品,那么测试按供应商分类统计或者按商品分类统计的报表时,意义也就不大了。
所 以如果希望高有效、更高质量的完成报表的测试,那么就要重视并增加对于数据准备工作的关注:用于验证报表功能的数据,一定是专门为报表准备的,并且是经过 精心设计,要分析影响数据项算法的各种因素,以及每个因素可能出现的不同变化,这样才有可能覆盖各种查询统计方法;同时,才能保证无论使用哪个数据项的算 法进行计算,其结果都是可以预知的——因为数据来源已经被我们控制了。
特别是对于算法比较复杂,又提供了多种查询统计方式的报表,如果想完整的测试,就需要准备大量的数据。而如果想高效、高质量的完成这项功能,就一定要理解数据准备工作的重要性。
经过精心设计的数据还有一个好处,就是当在进行业务功能的测试时,不再需要使用一些随意的数据,而是可以通过业务测试的过程,把报表测试所需要的数据输入到系统中。并根据报表对单据类型和状态的需要,进行相应的操作。
如果留心,你也会发现报表测试同其他业务功能测试的 有个区别。业务功能(例如单据的新增、审核等)的测试用例设计,通常需要考虑的是对各种正常的、异常的业务流程和业务规则的组合的遍历或覆盖;而对于报表 功能,虽然没有太复杂的业务流程和规则,但是算法更加复杂,同时报表功能本身就是一种对数据的加工处理,因此会更偏重于对于各种数据来源和算法的遍历或覆 盖,也就是要准备各种正常的、异常的数据,来验证报表是否取到的该取的数据、没有取不该取的数据,并且最后计算出了正确的结果。
(4) 特征性数据的准备
这 又是一个同数据准备有关的问题,也是一个解决实际问题的经验。如果由多人同时对一个系统进行测试,虽然大家各自使用的数据都是经过精心设计的,但是在实际 进行报表测试时,还是很难保证其他人的数据不会对自己的测试结果产生影响,最明显的一个问题就是原来自己对结果是可以预知的——因为数据是经过精心设计 的,是可控的,但是现在掺杂了别人的数据,就需要花时间去区分这种“假”的错误和真的错误。
有一个经验是可以借鉴的,就是在初期,团队内对数据的准备达成一直,使数据中的某一项具有特征性,例如分别使用不同的供应商,或者使用不同的商品。最后测试报表时,通过限定选取的数据来源,来保证相互之间尽可能的没有影响。
(5) 做好数据环境的备份和维护
虽然数据是经过精心准备的,但是难免在操作过程中因为误操作导致环境的变化,例如不小心把一张单据变成了另外一种状态,或者某个类型的单据多做了一张。对于这种情况,一个简单的方法就是去维护你的数据文档——一般我们都可以用EXCEL表 来保存我们事先准备的数据,可以一个文件保存一个类型的单据,例如采购单、入库单、出库单等等,文件中的每张表用来保存不同状态的单据,例如已经审核过的 入库单,没有审核过的入库单,全部入库的入库单和部分入库的入库单,等等。假如你一不小心,把一张本来准备入一半的入库单全入了,那也不要惊慌,去重新调 整一下你的数据文档,在相应的类型相应的状态的单据列表中新增一张就行了。
而如果想减少回归测试的工作量,那么应该考虑在一些关键的“点”上备份测试数据。例如所有的基础单据已经输入完成,但是还都没有开始审核或者出入库,那么可以备份一下,下次再测的时候可以直接在数据库中恢复这部分原始数据。
(6) 在业务功能测试通过之后才开始
这一点相信应该不难理解,如果业务功能本身存在缺陷,导致的数据不准,那么最后进行报表测试也就没有什么意义了。所以,应该在保证各项同报表有关的业务的功能测试通过之后,才开始考虑对报表进行测试。
(7) 寻求开发人员的协助
在报表测试中很常见的一个问题,是需求文档中可能没有定义报表的各个数据项的算法,这时候你需要找开发人员帮忙,向他们了解准确的算法和相应的公式。
(8) 多个报表相互对照
这 是一项“高级”的报表测试技能,需要对整个系统中的各种业务的熟悉程度达到一种炉火纯青的地步。除了可以准确的说出各个业务的处理过程对每张报表的影响之 外,还能够进行横向的联系,知道不同报表之间存在的关系。例如,一个简单的例子,库存报表中,你可以看到商品的出入库情况,而在销售报表中,你可以看到商 品的销售金额和销售成本金额,在应收应付报表中,你又可以看到不同供应商或客商之间的应收应付金额。那么这几张报表之间,是否存在一些关联呢?是否会存在 一些可以相互验证的地方呢?
(9) 着重对那些算法复杂、与业务功能关联较多的报表的测试
如果只是简单的把某个日期范围内的所有入库情况统计出来,可能不会出错;但是如果还要考虑按照供应商或商品汇总,同时要选取特定的类型或状态的单据,再进行一些响应的计算,恐怕就很难保证开发人员永远不会出错了。这就像业务功能的测试一样,越是复杂的业务,越有可能出错。
(10) 留意四舍五入对报表数据的影响
从这一条开始,后面的内容可以说也是一些在实际测试时要注意的事项。
这也是一个常见的问题。在一般的进销存系统中,都会存在这种情况,无论小数点后保留几位,总是难以避免明细和汇总之间的差别。原因可能是因为采购和销售的包装不一致,因为拆零引起的,例如10/30*30≠10;或者由于毛利率、税率等因素导致的不一致。我们曾经试过在保留4位小数的情况下还是无法避免这种情况。
(11) 留意进/存/销时使用不同单位对报表数据的影响
例如采购时是5箱,每箱有100盒,而销售单位是盒,入库之后,可能会要求按照销售单位来统计,这时要注意开发人员是否会选择了错误的单位,把500盒弄成5盒。
(12) 留意业务单据中存在多个日期字段时对报表数据的影响
一 般来说,一张单据上都会有多个日期字段,比如采购单就有采购日期、单据日期、审核日期,而入库单也会有单据日期、入库日期,诸如此类。那么在测试时,一定 要留意,开发人员是否按照要求选择了正确的日期,包括日期选取的一致性——是否存在这边取采购日期,那边取审核日期的情况。
(13) 留意是否存在遗漏的单据类型
例如像出入库的报表,入库方向的,除了最主要的采购入库外,可能还会包括退货入库、盘盈入库、报溢入库;出库方向的,除了最常见的销售出库,还会包括盘亏出库、报损出库。那么在具体测试时,一定要准备充分这些相应类型的单据,并且要留意开发人员是否遗漏了相应的单据类型。
(14) 留意不同状态的单据对报表数据的影响
例如采购单,当采购单发出后,供应商会开始送货,可能第一批之送来了一半的商品,那么这时采购单的收货状态是“未完成” ;当供应商把商品送齐了以后,采购数量=收货数量,则采购单的收货状态变为“已完成”。那这时留意,开发人员在采购报表中,是包含所需要的状态的单据,还是只包含了一部分?
(15) 留意那些被当做默认规则的因素
有些规则——例如单据类型或者单据状态——是作为默认规则写死在SQL语句或者数据库的存储过程里面,这些规则不会体现在界面,也不会由用户选择决定。但是这些规则恰恰是最容易被忽略的部分。所以,一定要同开发人员反复确认,保证自己已经了解了同报表各数据项计算有关的各个因素。
(16) 保证测试人员可以通过UI 找到自己所需的所有原始数据
在进行系统测试时,无论是报表,还是一般的业务功能测试,都不要去直接通过SQL语句查询数据库中的内容,而是通过UI来输入,再通过UI体现处理的结果进行验证——因为这是系统测试,不是集成测试,将来用户是决不会去直接查数据库的。因此,如果需要对报表的结果进行验证,应该通过其他的功能模块,去查询业务单据,或者其他报表,根据UI体现的结果,来进行确认。
(17) 检查大数据量对报表的影响
报表测试也会涉及到性能测试,主要是在大数据量查询统计的测试。大数据量一是说原始数据多,二是被操作、计算的数据多,三是某个数据项被是经过多次计算得出的。特别是对于一些算法比较复杂的报表,10万条数据和100万条数据时的响应时间将表现出巨大的差别。
(18) 不要遗漏权限控制和访问安全性的测试
这 里说的权限控制不是谁可以访问某个模块,谁不可以访问某个模块,而且数据的计算也没有直接的关系,而是侧重于报表设计的测试。我们都知道不同的报表是设计 给不同的人看的,例如出入库报表是给仓库管理人员看的,里面不会包含商品的价格,而只会包含数量;而财务报表中,只会包含采购、销售的金额,而不会包含数 量,这样才能保证可以相互对照,不会出现营私舞弊的行为。那么在测试时,应当考虑报表是否泄漏了不该泄漏的信息。当然,这里对业务的熟悉程度就是更高的要 求了。
又如,不同的业务员只能看到同自己有关的业务,但是领导可以看到所有业务员的业务——例如不同的业务员分管不同的客户或者地域,他们之间的销售情况是互相保密的。
还有一种情况,系统的用户可能会为他的供应商提供一个专门的程序或者Web页 面,供其对其供应的商品的销售、库存情况进行查看。那么对于这种情况,一方面是要保证某个供应商只能看到他所供应的商品的销售、库存情况,如果某个商品由 多个供应商同时提供,那么其中一个供应商应该只能看到他提供的那部分,而看不到其他供应商提供的同一商品的情况。当然,这种功能一般都是通过外网(internet)来访问的,所以也还要考虑相应的访问安全性测试,以免泄漏重要的商业信息。
在追求完美的过程中,享受着快乐与痛苦!
标题搜索
我的存档
数据统计
- 访问量: 37748
- 日志数: 85
- 建立时间: 2008-03-13
- 更新时间: 2011-08-17