[经济学]第三讲 功能性测试一.ppt

过程3 测试设计 内容 测试用例框架的设计 等价类划分方法设计测试用例 边界值分析方法设计测试用例 错误推测方法设计测试用例 因果图方法设计测试用例 判定表驱动分析方法设计测试用例 功能图分析方法设计测试用例 正交试验设计方法设计测试用例 场景法设计测试用例设计测试用例 系统测试用例的设计 测试用例的审查 3.1 测试用例框架 3.1.1 黑盒测试概述 黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。 3.1.1 黑盒测试概述 在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性，如图所示。 1．黑盒测试主要用于发现以下情况 重点： ①是否有不正确或遗漏了的功能 ②在接口上，能否正确地接受输入数据，能否产生正确地输出信息 ③访问外部信息是否有错 ④性能上是否满足要求 ⑤界面是否错误，是否不美观 ⑥初始化或终止错误 2．“黑盒”的两种基本方法 黑盒测试有两种基本方法，即通过测试和失败测试。 在进行通过测试时，实际上是确认软件能做什么，而不会去考验其能力如何。软件测试员只运用最简单，最直观的测试案例。 在设计和执行测试案例时，总是先要进行通过测试。在进行破坏性试验之前，看一看软件基本功能是否能够实现。这一点很重要，否则在正常使用软件时就会奇怪地发现，为什么会有那么多的软件缺陷出现？ 在确信了软件正确运行之后，就可以采取各种手段通过搞“垮”软件来找出缺陷。纯粹为了破坏软件而设计和执行的测试案例，被称为失败测试或迫使出错测试。 3．黑盒测试的优、缺点 黑盒测试的优点有： 1）比较简单，不需要了解程序内部的代码及实现； 2）与软件的内部实现无关； 3）从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题； 4）基于软件开发文档，所以也能知道软件实现了文档中的哪些功能； 5）在做软件自动化测试时较为方便。 黑盒测试的缺点有： 1）不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%； 2）自动化测试的复用性较低。 3.1.2 测试用例 测试用例就是test case，是为了系统地测试一个功能而由测试工程师写下的文档或脚本他是为某个特定测试目标而设定的，是测试操作过程序列、条件、期望结果及相关数据的一个集合。 1. 为什么需要测试用例（一） 其实，测试用例不是必须的。 如果你是一个特别有想法的人，或者在软件测试方面很有天赋，每天都能找到其他人几天时间才能找到的Bug，那么你可以不用测试用例，如果我是Test Manager的话，就会让你做一个Ad-hoc （随机测试、猴子爬杆）Tester，因为我已经觉得你足够好了，不需要测试用例来指导你了，因为你很有想法，有自己的测试思路。 但是不幸的是，你可能不是这样的人，或者你身上存在着几种情况，就最好使用测试用例。 1. 为什么需要测试用例（二） 1.你工作不主动，你需要测试用例来催着你去工作； 2.你测试时总感觉思维很混乱，或者总感觉有些功能没有测到，而一些功能已经测过好几遍了，这样测试用例能够帮你理清头绪，进行比较系统的测试，不会有太多的重复，也不会让你的测试工作产生遗漏； 3. 在测试时间紧迫的情况下，你不知道要测什么，或者要先测试那些功能，测试用例这个时候就可以帮你分清重点，因为测试用例写完后一定要标重要程度和优先级，以防止在紧急的情况下有重点的工作。 1. 为什么需要测试用例（三） 4.你积极的工作状态不能持续，这个时候测试用例又帮你一个大忙，因为测试用例上面操作步骤和预期结果都已经写好了，你根本不用思考，只需要照着上面做就行了。 5.测试用例是你工作的见证，也是你每次测试以后向上级汇报的依据，有了测试用例，我知道我这次测试了那些功能，还有那些功能没有测到，对上级是一个交代，也做到了自己心中有数。 6.测试用例可以记录你的灵感。如果灵感突发，有一个新颖的测试思路，你可以写成测试用例，或许这个测试用例就是挽救整个软件的重大功臣。 7.测试用例有助于不断的改进工作。因为通过测试用例，可以知道哪些测试用例测出Bug的机率比较大，还有那些测试用例需要改进，对我们以后工作的改进提供了依据。 2.测试用例设计考虑因素 （一） 1.测试用例的基本格式 软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍 ： 用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-S