软件观念革命用户体验设计.ppt

白盒测试把程序看成装在一个透明的白盒子里，测试人员可以完全了解程序的处理过程。这种的方法安装程序内部逻辑测试程序，检验代码中的每条通路是否按预定的要求正确工作。采用穷举路径的测试方式。 白盒测试结构测试或逻辑驱动测试，主要用于软件验证，而不顾程序的功能。 白盒测试的缺点： 不能查出程序违反了设计规范 不可能查出程序中因遗漏路径而出错。 可能发现不了一些与数据相关的错误 如果输入条件规定了取值范围，或是规定了值的个数，应以该范围的边界内及刚刚超出范围的边界外的值，或是分别对最大、最小个数及稍小于最小、稍大于最大个数作为测试用例。 针对需求的每个输出条件使用前面的第①条原则。 如果程序规格说明中提到的输入或输出域是个有序的集合（如顺序文件、表格等），就应注意选取有序集的第一个和最后一个元素作为测试用例。 语句覆盖法 使得程序中的每个条件语句至少被遍历一次 判断覆盖（分支） 使得程序中每一个分支（不管分支是否又语句）至少被遍历一次 条件覆盖 使得每个判断的条件获取各种可能的结果 判断/条件覆盖 条件组合覆盖 路径覆盖 A==1 B==2 R＝X＋Y R－＝Z R＋＝Z 使用语句覆盖法，写出右图的测试用例 Y N Y N 测试人员及测试在项目开发中的角色 测试生命周期及主要的活动 测试用例编写的方法及一般准则 思考和Q＆A 测试过程的保存的文档有什么用？ 有没有想过如果测试一条正则表达式 QA Moore机：次态＝f（现态，输入），输出f（现态） Mealy机：次态＝f（现状，输入），输出f（现态，输入） Moore机与mealy机不同点在于，moore机的输出信号是直接有状态寄存器译码得到，而mealy机则是以现时的输入结合 Moore电路的输出是当前状态的函数。 Mealy电路的输出是当前状态与输入的函数。 ，那么一开始的时候也许你 会觉得这个工具是在浪费时间，因为一个测试人员需要费神把发现Bug 的详细步骤记录下 来，有时还要贴一张示意图，这一切都不如当面说来得直接。 但是使用一段时间，你会发现BugFree 很有用，它忠实的记录着每个问题的处理过程， 不断提醒你存在的问题，永远不会丢失和忘记。 * 三者间关系如下： PM定义需求，书写出包含每个功能特性的设计文档（spec），Dev书写出代码来实现spec，Tester来测试Dev做出来的东西是否符合PM定义的spec 三种角色之间没有必然的上下级关系，只是分工不同而已。 * 需要建立一套测试与开发之间合作的规范。使用市场上已有的测试工具可以是一中选择，当然自己开发适合自己的测试管理工具也是一种不错的选择。在找到bug时，确不确认不能是dev说了算！需要权力！！！！！ * * 将软件测试和软件调试区分开来：debugging的目的是定位和纠正错误 任务是：消除软件故障，保证软件的稳定运行。 * 测试计划、测试计划和测试开发在软件开发完成前进行。 测试执行只能在软件开发完成后执行。 可以测试是伴随整个软件开发的生命周期的。 在下面的时间里我将对测试周期中的每个点进行详细的说明， 在这些阶段需要什么资料，需要出些什么样的文档，我会都详细说明。 现在的软件开发多数采用多次迭代的开发模式，软件测试也是一样，在每次开发迭代完成后，都需要对测试的某个阶段或全部阶段针对新的软件 版本进行一次迭代测试。 * 测试目标、测试范围、测试的资源：这三者是在一个金子塔的三个不同的点，他们之间是互相制衡的一个事物的三个不同的方面，要达到好的测试效果，在相同的人力资源的情况下，需要更多的时间。 * 后置条件:描述程序执行后对返回结果的约束。方法返回值的断言来表示 即它必须返回大于或等于0 的值 * 提问应用软件的主要类型。 1、离散系统的建模，如通讯协议 2、以数据处理为中心的数据库产品， 3、以业务过程处理为中心的工作流产品 * 人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。 由于对输入进行严格意义上的遍历是不可能，测试人员只能测试输入的典型值。 在不知道程序逻辑的情况下如何判断输入的典型值呢? 需求规格说明书！！ 黑盒测试的目的是验收程序的功能是否符合需求规格说明书的要求。 * 错误推测法(error guessing) ?? 基本概念 ?? 猜测被测程序在哪些地方容易出错 ?? 针对可能的薄弱环节来设计测试用例 ?? 例子：对一个排序程序，该检查： ?? 输入表为空 ?? 输入表中只有一行 ?? 输入表中所有的值具有相同的值 ?? 输入表已经是排序的 因果图法（Cause一Effect Graphics） ?? 检查输入条件的各种组合情况 ?? 从功能说明中找出因（输入条件）和果（输 出或程序状态的修改） ?? 通过