软件测试测试模型与过程解析.ppt

记录运行的结果 测试用例编号 输入值 期望结果 实际结果 是否通过 1 1 打印出“Hello world！” 打印出“Hello world！” 通过 2 2 打印出“Hello guy！” 打印出“Hello guy！” 通过 3 3 打印出“Hello！” 打印出“Hello！” 通过 4 无 不打印 弹出错误对话框 失败 测试总结 4个测试用例中通过了3个，最后一个失败。前3个输入了参数，因此正确，最后一个没带参数，因此出错，说明参数的个数会影响到程序的运行结果，可进一步测试带2个参数、3个参数甚至更多参数的情况。 课后作业 软件测试的生命周期是什么？各个阶段的任务是什么？ 软件测试员的目标是什么？ 有没有质量很高但可靠性很差的产品？请举例说明。 * * * RUP采用Use Case的概念，把要开发的系统根据各功能使用的情况划分多个Use Case，并采用迭代的思想把系统的风险分布在四个阶段，风险越大的迭代越要放在靠前的阶段做，使软件产品的风险不断降低；而不是像传统软件工程那样越往开发的后期问题越多。 * RUP采用Use Case的概念，把要开发的系统根据各功能使用的情况划分多个Use Case，并采用迭代的思想把系统的风险分布在四个阶段，风险越大的迭代越要放在靠前的阶段做，使软件产品的风险不断降低；而不是像传统软件工程那样越往开发的后期问题越多。 * 软件工程中的工作流程分为两部分：核心工作流程与核心支持工作流程 核心工作流程:业务建模 ,需求确定，分析设计, 测试 ，部署 ，发布；核心支持工作流程：环境 ，项目管理 ，配置与变更管理 配置变更管理：用来控制软件工作产品在历经生命周期不同阶段时发生的变化 * * * * * * V模型和W模型均存在一些不妥之处。首先，如前所述，它们都把软件的开发视为需求、设计、编码等一系列串行的活动，而事实上，虽然这些活动之间存在相互牵制的关系，但在大部分时间内，它们是可以交叉进行的。虽然软件开发期望有清晰的需求、设计和编码阶段，但实践告诉我们，严格的阶段划分只是一种理想状况。 H模型中, 软件测试过程活动完全独立,贯穿于整个产品的周期,与其他流程并发地进行,某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。 软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行。图中标注的其它流程可以是任意的开发流程,例如设计流程或者编码流程。也就是说, 只要测试条件成熟了,测试准备活动完成了,测试执行活动就可以进行了。 * * 左边描述的是针对多个单独程序片段所进行的相互分离的编码和测试，通过集成最终合成为可执行的程序，然后再对这些可执行程序进行测试。 右边描述的是己通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。 封版：项目经理认为产品已完成集成测试可以交付用户使用的版本，便于区分和维护 * * * * * * * * * * * * 针对需求分析文档和项目开发计划文档测试完成后，测试组需要编写测试计划文档、制定测试测略及预估测试过程中的风险，并设计出合理的规避风险的策略，为后续的测试工作提供直接的指导。 * * * * * * * * * * * * * 一个简单的软件测试实例 测试以下程序： void static main(int argc, char * argv[]) { printf(“Hello world!”); } 建立测试用例 测试用例编号 说明 操作过程 输入值 期望结果 1 测试程序功能 运行软件 无 在控制台打印出“Hello world！” 执行测试用例 将程序编译、连接形成可执行程序Hello.exe，然后运行它，由于测试不要求输入值，因此运行软件即是执行测试。 记录运行的结果 程序在控制台打印出“Hello world！”字样 测试总结 测试的实际结果与期望的结果一致，程序的打印功能是正确的。 软件测试生命周期 回归测试 制定测试计划 测试设计 测试开发 执行测试 评估测试 缺陷 关键问题 采用的测试策略 设计测试用例 测试的评估 测试策略是制定测试计划的重要参考依据 目的：如何以最少的人力、物力和时间等资源投入来达到最佳测试效果的综合方法，原因在于完全的测试是不可能的，对任何程序的测试必定是不完全的。那么，最显然的测试策略就是努力使测试尽可能完全。 影响因素： 测试完成的标准 成本、人力、时间等资源状况 针对需求定义测试类型、方法及工具等 由于时间和成本的约束，软件测试的最关键问题是： 所有可能的测试用例中，哪个子集最有可能发现最多的错误？ 设计考虑因素及基本原则 代表性、典型性 正确和错误的或者异常的输入 多