软件测试基础教程（第2版）.ppt

第2章：软件测试基础,主讲人：贾艳波 职称：讲师,回顾与引言,回顾 软件测试的三个观点 观点1：查找错误的观点 观点2：寻找差异的观点 观点3:发现，改进，完善，强化 软件测试的知识体系和核心内容“方法”和“度量”,由此得到我们下一步的学习目标 了解软件测试活动的本质 软件测试，是集成了整个软件工程过程信息的综合质量检验活动。 本章开始，我们从软件开发过程入手，进入软件测试领域。,为了进入软件测试领域，我们首先需要知道为什么要测试？这关系到软件质量的概念； 进而，需要深入了解软件缺陷（bug）是怎么回事？这关系到软件测试的方法。 本章目的是建立一个完整的软件测试概念，包括基本软件测试过程、测试心理学、测试基本原理等。,丰田：伤了谁的心,汽车质量”召回门“”脚踏门“ 质疑日本制造 ？ /netall/index.shtml?qtext=%u672c%u7530,本章内容,2.1 术语和目的 2.2 基本测试过程 2.3 测试心理学 2.4 测试基本原理,2.1 术语和目的,软件缺陷的严重性,严重性(severity)，就是软件缺陷对软件质量的破坏程度。如何判断软件的严重性？ 从软件最终用户的观点做出判断 判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成的恶劣后果的严重性。 然而，现实中是软件缺陷存在在先，用户蒙受损失在后 评价软件缺陷的，首先是软件开发工程师由此，引出了软件测试活动 缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题进而出现了明确的分工：软件测试师,bug是从哪里来的？,异常处理 每个程序设计人员都知道：设计程序时，安排好异常处理方式当发生预期的异常时产生一个返回值来通知调用方程序有错误发生。 消除那些因异常而导致的bug，是程序设计的基本技能。 但是，并非每个程序员都喜欢这样做。请问，你们当中谁喜欢这样做？ 谁喜欢这样做，谁就有作为测试师的“天赋”。,参考书：编程匠艺:编写卓越的代码,(美)pete goodliffe，韩江等译编程匠艺:编写卓越的代码，电子工业出版社，2008 年9月,软件产品的行为与需求不符合是否就是软件产品不合格？ 只有在了解了一个软件系统正确运行时的期望行为之后，才有可能判定其是否不合格。,几个术语,错误（error） 错误是指某件你做错的事。它是一种特定的人类行为，会造成软件包含缺陷。 和错误有关的行为忘记、疏忽、随意、臆测、误判、错想、误会、含混、轻信、无知。 还有什么和错误相关的词汇？ 缺陷（fault） 缺陷是错误在软件中体现出来的后果，更精确地说，缺陷是错误的表现。当缺陷被执行时会导致失效（failure）的发生。 错误是潜伏在代码中的问题，只有永远不执行那些代码才不会造成问题。但是，如果没有条件引发这个缺陷，我们就以为没有缺陷。,失效（failure） 是指不完全符合给定的需求，是实际结果（action result）或行为（在执行测试时观察到的）与期望结果（expected result）或行为（在规格说明或需求中定义的）之间的偏差。 ieee610.12使用“失效”这一术语来描述用户遇到问题的情形，人们也常用“问题”（problem）或“事件”（incident）来描述同样的情形。在软件测试或者使用过程中，失效会在测试人员（tester）或用户面前“现形”，例如，发生输出错误或者系统崩溃。 我们真正担心的问题是：千万不要出现大的偏差。,因果链 导致软件失效的是软件自身的故障。 软件的每个故障（或缺陷或者bug）都是软件开发或者更改后就存在的。 失效是缺陷的表现形式，只有在软件被执行时这些缺陷才会以失效的方式显露出来。 bug 是一种通俗的说法，通常用作缺陷的同义词。,错误,缺陷,缺陷,缺陷,软硬件环境条件,失效,沿着失效返回的路径，就是查找错误的路径测试,导致失效的因素除缺陷外，还可能有辐射、电磁波、电场等环境因素，另外，环境污染引起的硬件故障也会导致软件运行的失效。 有许多因素会导致软件缺陷，主观原因是人类在从事软件开发过程中容易犯错误，另外由于开发过程管理规范性、开发技术、软件的复杂性、开发的周期长短、个人能力等因素也会导致软件的缺陷产生。,bug是从哪里来的？,示例： 自己赋值的指针变量当然一定是指向自己要访问的地方，但是，所有的指针变量都指向着应该访问的地方吗？下面程序将打印出什么？ int main（void） int ref=一组测试数据集合; int *ptr; int index; for(index=0,ptr=ref;index 4;index+,ptr+) printf(“%d %dn”,refindex,*ptr); return 0;,没有指针检测,bug来自程序员的经验不足（生疏） 编译错误 运行时错误（崩溃） 非预期的行为 bug来自程序员的疏忽大意（不动脑子） 句法错误 构建错误 语义错误 内存错误（溢出、泄漏、耗尽） 数学（计算）错误,或者是不重视一个学籍管理系统和一个航天发射指挥系统是大不一样的。,常见的思想 任何程序员都希望自己的代码是正确的，因此他一般不会专门去查找有问题的地方，甚至，他们可以很容易地写一些测试用例证明自己的代码运行得很完美！ 然而，这种思想就是bug的根本来源。同时也给软件测试指出了一个必要的原则。 请问：什么原则？ 作为程序员，当测试者发现了你的程序有了缺陷的时候，你应该认为，是你自己犯了一个错误。而不是程序有什么缺陷。 一个程序包含了许多缺陷，那就是程序员犯了许多错误。,bug的另一来源：拙劣的项目管理,项目的开始阶段 如：wbs没有划分清楚 中期的测试-修改阶段 如：测试计划的粗糙、测试资源的匮乏、测试后缺陷管理混乱 后期的交付-完善阶段 如：集成测试方案设计不好，测试用例设计华而不实，用户意见不能适时落实 项目之后的维护阶段 代码可维护性差、关键人员缺失，程序文档化效果很差,测试人员要比开发人员更关注管理,明确测试的目标 资源有限，测试的目的必须有所不同，即使是消除软件缺陷，也是一个有限的目标。 你编写的代码越多，你引入的缺陷就越多。 你编写的速度越快，你引入的缺陷也越多。 从未有过“多产，但是几乎无bug”的程序员。 参与测试策略的制定和决策 因此，必须反复思考，回答以下问题： 为什么要测试？ 测试什么？ 谁对测试负责？ 如何正确地进行测试？,一般认为：软件测试是为了发现错误而执行程序的过程。 此观点的不好在于没有理解为什么要测试！ 要站在用户和市场的角度看待测试 程序的效率、可适用性、维护性、可扩充性 安全性、可靠性、系统性能、系统容量 可伸缩性、服务可管理性、兼容性等等因素。,描述软件缺陷的一些词汇,缺点（defect） 偏差（variance） 谬误（fault） 失败（failure） 问题（problem） 矛盾（inconsistency） 错误（error） 毛病（incident） 异常（anomy） 经规整后进入下表：,2.2.1 软件缺陷的定义和种类,bug，即软件缺陷。 bug一词，通常主要表现软件功能上的失败（failure）、功能和实际需求的不一致，即矛盾（inconsistency）。 bug的标准定义： 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题。 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。 ieee 1983 of ieee standard 729。,本教材给出的软件缺陷分类,功能、特性没有实现或部分实现。 设计不合理，存在缺陷。 实际结果和预期结果不一致。 运行出错，包括运行中断、系统崩溃、界面混乱。 数据结果不正确、精度不够。 用户不能接受的其他问题，如存取时间过长、界面不美观。 软件缺陷分类，是软件测试的基础信息，是学习软件测试的入门知识，应给予高度重视。,缺陷分级（4级）,致命的（fatal）：致命的错误，造成系统或应用程序崩溃（crash）、死机、系统悬挂，或造成数据丢失、主要功能组完全丧失等。 严重的（critical）：严重错误，指功能或特性（feature）没有实现，主要功能丧失，导致严重的问题，或致命的错误声明。 一般的（major）：不太严重的错误，这样的软件缺陷虽然不影响系统的基本使用，但没有很好地实现功能，没有达到预期效果。如次要功能丧失，提示信息不太准确，或用户界面差，操作时间长等。 微小的（minor）：一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等。,有资料给出了软件缺陷严重性的分级/phrase/200603111651085.html 1.非常严重的缺陷，例如，软件的意外退出甚至操作系统崩溃，造成数据丢失。 2.较严重的缺陷，例如，软件的某个菜单不起作用或者产生错误的结果； 3.软件一般缺陷，例如，本地化软件的某些字符没有翻译或者翻译不准确； 4.软件界面的细微缺陷，例如，某个控件没有对齐，某个标点符号丢失等。,bug的不同状态,软件缺陷分类，定义了缺陷导致的后果的严重性，这是一种静态的描述。 在软件开发与维护过程中，软件缺陷的严重性是演变而成的。 软件缺陷在某一时刻会处于某种状态，有三种状态： 激活状态（active或open）：问题还没有解决，测试人员新报的bug，或验证后bug仍然存在。 已修正状态（fixed或resolved）：开发人员针对所存在的缺陷，修改程序，认为已解决问题，或通过单元测试。 关闭或非激活状态（close或inactive）：测试人员验证fixed bug后，确认bug不存在之后的状态。,从事故状态演变的过程看bug,下左图是信息系统事故的优先级划分。,紧急程度,影响程度,低,中,高,低,中,高,最严重程度,紧急程度,影响程度,低,中,高,低,中,高,最严重程度,事故的演变路线,事故优先级=影响度紧迫性,参考 软件生态学,2.2.2 软件缺陷的产生,此处，教材的作者试图给出软件缺陷的来源。但实际上并未明确给出（内容上与缺陷分类有很大的重合）。 参考资料，给出一些常规的缺陷查找线索编程匠艺:编写卓越的代码,大范围缺陷-1：编译失败,花好长时间编写的代码编译失败，确实会让你非常烦恼但这是最好的bug。 打字错误（语法错误） 不匹配的参数类型 缺少链接/嵌入的资源 编译失败是很容易引起人们注意的，并且一般都比较容易修正。,大范围缺陷-2：运行时错误,程序出现故障并崩溃（或死机），需要调查程序出错的地方故障必须能够再现 检查崩溃之前的输入序列输入数据错误？ 检查崩溃之前程序的操作在估计/猜测后,需要设置断点跟踪操作过程,大范围缺陷-3：非预期的行为,非预期的行为是真正难以处理的错误 因某行代码有缺陷而出现，出现了界面显示方式、颜色、风格等错误 因几个相互连接但是不太匹配的模块集成在一起而导致意外的现象出现,如：响应奇慢、数据异常等。 非预期行为的根源来自下面的“小范围故障”,小范围缺陷-1:句法错误,检查中漏掉的一些句法错误会造成奇怪的和非预期的行为。 在条件表达式中将“=”错误地写成了“=”，或者将“&”错误地写成了“&” 忘记了句尾的分号，或者在错误的地方添加了分号（典型的位置是在一条for 语句之后） 忘记将一组循环语句用括号括起来 括号不匹配,小范围缺陷-2:构建错误,构建，即make 构建，程序运行前的最后一道手续，你此时你制作的makefile被执行后，直接得到可执行代码。任何错误都被看作是运行时出现的，但问题却发生在构建中。 典型的问题 makefile没有包含足够的依赖关系信息或旧的可执行文件的时间戳己损坏； 程序修改后，无意中运行了旧的存在bug的代码，构建系统出现混乱；,小知识：肮脏测试（dirty tests）,也叫做“负面测试（”negative testing）指保持程序开发的原始环境的测试，意在更加准确地发现程序缺陷的根源所在。 一般，开发者测试自己开发的程序时，喜欢“干净测试”；测试师测试则希望保持一定的“肮脏测试” 在不成熟的测试机构中，肮脏测试同干净测试的数量比例是1：5；成熟的测试机构则保持让肮脏测试的数量是干净测试的5倍。,其他的小范围缺陷,语义错误 内存错误（溢出、泄漏、耗尽） 数学（计算）错误,软件缺陷的构成,这里说的不是构成，而是显而易见的缺陷出现在什么地方？ 规格说明书是软件缺陷出现最多的地方 为什么？规格说明书是最重要的、也是最难写的。 教材中列举的情况，基本上都是对的，但只是一般的现象。,图2-3是很有意义的,软件缺陷在开发周期的不同阶段的分布情况，见下图。,图2-3软件缺陷在不同阶段的分布图,修复软件缺陷的代价,“老生常谈”，但仍未得到应有的重视！ 人们总是因追求进度和实现而忽略了对软件缺陷的及时排除。,图2-4 软件缺陷随着时间的推移带来的成本越来越大,2.1.2 测试术语,测试不是调试,要修正缺陷，必须在软件中找到它的位置。 软件开发人员通过调试（debugging）确定软件缺陷位置并进行修正。 调试是对缺陷的定位和修正，而测试的目标是发现系统的失效，以证明缺陷的存在。 以检测失效为目的而对测试对象进行的每次执行都是测试。必须明确定义测试的条件。测试对象的实际行为和预期行为需要进行对比。,测试的目的,为了寻找失效而执行程序； 为了评估质量而执行程序； 为了增强信心而执行程序； 为了预防缺陷而分析程序或者它的文档。 测试定义： 系统地执行程序以证明正确实现了需求，增强对产品的信心，以及查找系统失效的过程称为“测试”。另外，测试还包含了静态的方法，即使用工具对软件产品进行静态分析，以及对文档进行评审。,除了根据测试数据（test data）对测试对象进行测试以外，测试的规划、设计、实施以及分析（测试管理test management）都是测试过程（test process）的组成部分。 测试运行（test run）或测试套件（test suite）是由一个或多个测试用例（test case）组成的。 测试用例包含对测试条件（多少情况下是执行测试的需求）、输入、测试对象的预期输出或预期行为的定义。 测试用例应该对具有未知错误的较高发现能力。,结论：复杂的软件系统是不可能没有缺陷的。 即使在执行完所有的测试用例后没有发现任何失效，也不能确定系统运行完全可靠（除程序非常小），没有其他故障。,2.1.3 质量的概念,软件质量定义：在rational unified process（rational标准过程理论）中，质量被定义为： 满足或超出认定的一组需求，并使用经过认可的评测方法和标准来评估，还使用认定的流程来生产。 如何理解软件质量定义？ 基本的质量标准，是满足用户的需求 核心的质量要求，是采用的评测方法和评测标准 这涉及到软件质量保证是否可管理、可重复,归纳起来： 软件质量，必须符合或超过用户需求； 这样的质量的评价，必须是权威部门认证的，否则会因有失公正，而不可信、不可用； 在经权威部门评价之前，该质量必须是经过有效的质量管理过程才取得的质量不是评出来的，而是做出来的。 测试是质量管理的关键环节。,软件质量的内涵,软件质量的具体延伸 高品质软件应该是相对的无缺陷（bug free）产品（或只有极少量的缺陷） 该产品能够准时提交给客户（条件是：所花费用都在预算内，并且满足客户需求，是可维护的）。 有关质量好坏的最终评价，依赖于用户的反馈。 软件的质量还必须得到相关项目人员的认可。,软件测试和质量,软件测试能够提高软件质量。 这是通过识别缺陷并对这些缺陷进行相应的调试及修正实现的。 测试同时也是衡量软件质量的手段。 如果测试用例是软使用的合理样本，那么用户所体验到得软件质量应该和测试时所体验到得软件质量不会有太大差异。 所有质量特征（quality characteristic)（或称质量特性quality attribute）都必须在测试时加以考虑，以判断软件产品总体质量。实现必须定义每个质量特征对应的测试对象应该具备什么等级的质量，通过有效地测试对预先定义的质量需求进行验证。,软件质量范畴： 功能性（funcitonality） 安全性 可靠性（reliability） 可用性（usability） 效率（efficiency） 可维护性（maintainability） 可移植性（portability） 为质量特征赋予优先级：这个概念可以为测试时如何针对不同的质量特征决定测试级别强度提供指导。,2.1.4 测试工作量,测试不能证明不存在缺陷。 完全测试（complete test）或穷尽测试（exhaustive test）定义： 测试套件包含了输入值和前置条件所有可能组合的测试方法。 结论：完全测试是不可能的。,所有可能的连接组合数： 520+519+518+51 人工完成测试：10亿年（一个测试用例耗费5分钟） 自动运行测试：19年,测试工作量开销在25%50% 测试工作量常常用测试人员和开发人员的比例来表示。这个通常介于1：10或3：1. 结论： 根据项目的不同，测试工作量或者花费在测试上的预算差别极大。 故障可能引发高成本。“只要寻找和修正缺陷的成本低于失效造成的损失，测试就应该继续下去”。 根据风险确定测试的广度和深度 选择正确的测试规程 只提供需求中要求的功能,测试用例爆炸（test case explosion） 测试用例及其演化出的测试用例可能在短时间内演变成成百上千次测试。这个问题通常称为”组合爆炸“。 每个软件开发项目的资源都是有限的。 测试经理只有运用周详的计划和有效地策略，才能成功地应对这个挑战。,2.2基本测试过程,拓展知识：生命周期模型 2.2.1 测试计划和控制 2.2.2测试分析和设计 2.2.3测试实现和执行 2.2.4测试出口准则的评估和报告 2.2.5测试结束活动,拓展知识：生命周期模型,软件测试与软件工程,软件测试与软件工程息息相关，软件测试是软件工程组成中不可或缺的一部分。 软件工程的目的是提高软件的质量和生产率，最终实现软件的工业生产。 采用软件工程模型的目的是为了确保项目成功，而且是每次都成功。,软件开发模型,软件测试作为质量保证的重要方法和手段，恰当地出现在一个软件工程模型中，是每一个应用软件工程模型的组织或个人都应该仔细考虑的问题。 常见的软件开发模型主要由以下3类： 线性模型； 渐进式模型； 变换模型； 在不同的开发模式中，测试的作用有细微的差别，测试人员应该充分理解软件的开发模式，以便找准自己在其中的位置和角色定位，充分发挥测试人员的价值。,瀑布模型最致命的缺点是：测试被看作是“最终审查”,通用v模型,快速应用开发(rad）模型，即“v”模型 属于线性顺序类的软件开发模型。 rad模型实现的前提是良好的需求分析，且项目范围是明确的。 v模型的特征将“测试”环节引入模型，确立了“提前测试”、“测试驱动开发”的软件开发理念。,通用v模型的主要思想是：开发任务和测试任务是相互对等的活动且同等重要。,v模型左侧代表软件开发过程。在软件开发过程中，系统是逐步设计完善的。 v模型右侧描述了集成和测试过程，通过不断组合程序单元形成更大的子系统，并对它们的功能性进行测试。 根据这个流程开发的整个系统将以验收测试作为集成和测试活动的结束点。 v模型可能给人测试开始相对较晚的印象，在系统实现之后才进行测试。但是情况并不是这样。v模型右边的测试应该理解为对应的测试执行的级别，而不完全是先后顺序。,验证和确认（verificationvalidation）,软件的验证与确认，是最高层面的“测试”搞好了，能够收到事半功倍的效果。 如果没有基本的软件验证与确认，即使实施了规范的软件测试，产品也依然会处于不可预测的境地，甚至导致重大问题上的失败。 误以为软件测试是技术工作，验证与确认是管理工作工科学校很少讲授软件验证与确认方面的知识；这是导致测试人员失去方向、质量人员缺乏有效测试方法的主要原因。 有经验的专业公司都很重视软件的验证与确认 ibm开发者文库中，含有“验证”的文章有2859件，含有“确认”的有1211件 相比较：含有“黑盒”的文章只有63件，含有“白盒”的只有28件。,正确的认识：先“验证”，再“确认”；“测试”在“确认”之中。 验证实施一个对系统或单元评价的过程，以确定一个给定的开发阶段的产品是否满足在此阶段开始时所给定的条件。 确认在软件开发过程期间或结束时实施一个评价系统或单元的过程，以确定它是否满足特定的需求。在确认中，实施测试、测量和改进。可见，测试是确认活动中的测试。而不是孤立的、随意的。见下图。,开发阶段 的开始,验证完成,确认完成,测试1,测试2,测试3,测试4,变更，修改,变更，修改,修改，完善,开发阶段 的结束,测试计划，测试用例设计，测试结果评价,1.验证 也可以翻译为“检验”，即检验软件是否已正确地实现了产品规格说明书所定义的系统功能和特性。 验证过程应提供证据来表明：软件相关产品与所有生命周期活动的要求（如正确性、完整性、一致性和准确性等）相一致。 2.有效性确认 这是“validation”的准确翻译。 有效性确认要求更高，要能保证所生产的软件可追溯到用户需求的一系列活动。 确认过程应提供证据来表明：软件是否满足系统需求（指分配给软件的系统需求），并解决了相应问题。 3两者的区别 验证，是基于设计规格说明书的一致性判定。但设计规格说明书本身就可能存在错误，仅仅进行验证测试还是不充分的，还要进行确认测试但是，只要最大限度地排除了设计规格说明书的错误，就能避免重大的损失。 确认，就是检验产品功能的有效性，即是否满足用户的真正需求。因此，确认必然要求规范的测试给予支持。,出色的观点,对vv最著名又最简单的解释（boehm是）： 验证（verification），即are we building the product right？是否正确地构造了软件？即是否做了正确的事（=验证开发过程是否遵守己定义好的内容）。 确认（validation），即are we building the right product？是否构造了正是用户所需要的软件？即是否正确地做了事。,验证,实现：确认后,设计：验证后,确认,示例：一次接近失败的开发 设想：如果没有验证环节，则实现的是什么就不知道了。,改进的v模型,将“编码”从v字型的顶点移到左侧，和单元测试对应，从而将整个开发过程与测试过程一一对应。,图1-3 改进的rad模型及其解释,pm：项目管理,在改进v模型中的测试工作,需求分析和功能设计阶段，测试人员就应参与其中： 阅读、审查需求分析的结果 了解产品的设计特性和用户的真正需求 准备测试用例（use case）。 系统设计阶段，主要任务是准备系统的测试环境： 了解并跟踪系统的设计与实现方案 了解并跟踪软件开发环境与运行平台 了解并跟踪硬件设备和外购软件情况 在详细设计阶段，测试人员的主要任务是： 为测试最小执行单元而准备测试用例（test case）。 在编程的过程中，同时实施单元测试。,改进的v模型，最大的贡献是什么？,改进的v模型，目的是落实“测试驱动开发”的思想。即： 在开发功能代码之前，先编写测试代码。 在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试程序的代码编写； 进而编写测试用例； 随后参照测试用例的要求逐渐添加功能，直到完成全部功能的开发。 先设计测试，再编写代码，是非常卓越的贡献此思想对测试的自动化具有重要作用。,补充知识,模型驱动的方法,下述内容，主要是介绍了基于uml、建立测试模型的测试方法模型驱动的测试方法 意义： 模型驱动的测试方法是所有测试方法的基础 作用： 推进测试设计和测试用例的生成 作为自动化故障分析与精确定位问题的知识基础。,理解软件测试,测试可以看成是一个搜索问题。 然而，现实要求我们：搜索必须是系统的，集中的和自动的。 系统的确保每一个目标组合都被测试到； 集中的测试必须集中在错误信息所指向的地方 自动的完整的测试必须产生和运行大量的可重复的测试，人工是难以完成的，所以测试必须能自动进行。 为达到上述目的，需要周密地设计测试模型,认识模型的构成要素,主题即模型的名称，以代表一个定义完好的主题。 这是任何模型都必需的。软件测试模型，是描述“被测实现”的模型，也叫做测试实例模型。 论点/理论即模型表达的依据或原理。 描述问题及其信息测试模型表达的是测试行为及测试的焦点，目地是指向软件的缺陷和出错的要素信息。 表示即对于特定模型的表达方法。 如所见的、采用uml的软件模型。 技术指软件的模式、风格 模型中有技术模型中含有复杂的软件技术，如面向对象、面向服务等。,测试模型示例,测试模型示例,软件测试的总体过程：规划与设计,除了整个开发过程中需要有测试之外，测试任务本身需要更加详细的过程。这意味着作为开发任务的组成部分，测试必须拆分成更小的子任务。,这个测试的规划、管理基本过程，在朱少民软件测试方法和技术书中见图2-8详细描述.,测试计划和控制 概念 最主要的任务是确定测试策略（test strategy） 为子系统和单独的功能定义测试强度。 测试优先级划分 工具支持,测试分析和设计,第一任务：对测试依据（test basis）进行评审。 最重要的任务是开发测试用例。,设计测试用例,注意：不同测试阶段，测试计划不同，测试目标不同，测试用例的设计方法也不同。 测试用例：是一定顺序执行的与测试目标相关的测试活动的描述，是确定“怎样”测试。 是最小测试执行单元，相当于测试规格说明书。 测试用例的设计是整个软件测试工作的核心。,设计依据 系统规格说明书、系统设计文档、测试范围、技术特点、程序结构等来设计测试用例。 设计任务 定义执行测试所需要的条件或环境、输入或操作步骧，以及所期望的结果。 测试环境尽量模拟软件系统实际应用的环境。 输入值正常的输入值，但主要是边界值。 期望结果或标准根据系统设计规格说明书的内容拟定输出结果或标准，也可按经验估计和拟定。,逻辑测试用例（logical test case）和具体测试用例（concrete test case）,表2-1 逻辑测试用例表,表2-2 具体测试用例表,测试用例的种类,测试用例的种类可以用下面的两条准则区分 第一种是用来检查特定的行为、输出和反应的测试用例。 另一种测试用例是用例检查测试对象对无效以及意外的输入或者条件的反应。,阅读资料,强化测试用例在测试活动中的作用 改进测试用例执行过程/developerworks/cn/rational/r-test-case/ 从用例到测试用例的追踪/developerworks/cn/rational/04/r-3217/ ibm rational 测试工具包 v2.0/developerworks/cn/rational/kits/tester/ 你的组织为自动化测试做好准备了吗