软件测试演义2——技术篇.docVIP

软件测试演义——第二部分 技术篇 ? 作者：朱少民 出处：CSDN ? 技术篇 第10回 在软件开发各个阶段的测试任务 软件测试是软件开发过程中重要内容之一，是软件质量保证的关键。软件测试贯穿软件产品开发的整个生命周期，如第二章V模型图2-1所示，软件测试和软件项目同时开始，从产品的需求分析审查到最后的验收测试，直至软件发布。 从测试实际的前后过程来看，软件测试的过程是由一系列的不同测试阶段所组成，这些软件测试的步骤分为：需求分析审查、设计审查、单元测试、集成测试（组装测试）、功能测试、系统测试、验收测试、回归测试（维护）等。详细内容见下表。 阶? 段 输入和要求 输出 需求分析审查 Requirements Review 市场/产品需求定义、分析文档和相关技术文档 要求：需求定义要准确、完整和一致, 真正理解客户的需求 需求定义中问题列表,批准的需求分析文档 测试计划书的起草 设计审查 Design Review 产品规格设计说明、系统架构和技术设计文档、测试计划和测试用例 要求：系统结构的合理性、处理过程的正确性、数据库的规范化、模块的独立性等 清楚定义测试计划的策略、范围、资源和风险，测试用例的有效性和完备性 设计问题列表、批准的各类设计文档、系统和功能的测试计划和测试用例 测试环境的准备 单元测试 Unit Testing 源程序、编程规范、产品规格设计说明书和详细的程序设计文档 要求：遵守规范、模块的高内聚性、功能实现的一致性和正确性 缺陷报告、跟踪报告；完善的测试用例、测试计划 对系统功能及其实现等了解清楚 集成测试 Integration Testing 通过单元测试的模块或组件、编程规范、集成测试规格说明和程序设计文档、系统设计文档 要求：接口定义清楚且正确、模块或组件一起工作正常、能集成为完整的系统 缺陷报告、跟踪报告；完善的测试用例、测试计划；集成测试分析报告； 集成后的系统 功能验证 Functionality ?Testing 代码软件包（含文档）,功能详细设计说明书; 测试计划和用例 要求：模块集成 功能的正确性、适用性 缺陷报告、代码完成状态报告、功能验证测试报告 系统测试 System ?Testing 修改后的软件包、测试环境、系统测试用例和测试计划 要求：系统能正常地、有效的运行，包括性能、可靠性、安全性、兼容性等。 缺陷报告、系统性能分析报告、缺陷状态报告、阶段性测试报告 验收测试 Acceptance ?Testing 产品规格设计说明、预发布的软件包、确认测试用例 要求：向用户表明系统能够按照预定要求那样工作，使系统最终可以正式发布或向用户提供服务。用户要参与验收测试，包括α测试(内部用户测试)、β测试(外部用户测试) 用户验收报告、缺陷报告审查、版本审查 最终测试报告 版本发布 Release 软件发布包、软件发布检查表（清单） 当前版本已知问题的清单、版本发布报告 维护 Maintance 变更的需求、修改的软件包、测试用例和计划 要求：新的或增强的功能正常、原有的功能正常，不能出现回归缺陷 缺陷报告、更改跟踪报告、测试报告 第11回 集成测试的模式和方法 单元测试主要由开发人员完成，所以从测试人员工作来看，集成测试可能是具体测试实施的第一个阶段，虽然开发人员也比较多地参与集成测试。集成测试相对来说是挺复杂的，而且对于不同的技术、平台和应用，差异也比较大。不过，我们还是不得不面对它，保证系统集成成功，为后来的系统测试打下基础。 集成测试简单的表现形式就是每日构建（Daily Build）, 保证Build构建成功，也就是保证软件的组件或单元能组装成一个系统。每日构建是一个很好的实践，被许多软件公司采用。 集成测试，更多是和开发环境融合在一起，在编程过程中去实现，如MS Visual Studio.NET ，Borland JBuilder IDE， Compuware OptimalJ的集成开发/测试环境。更正确的说法，集成测试发要追溯到设计阶段。当设计数据接口(DB，XML等）、组件接口、应用接口(API)之时，我们就要审查接口的规范性、一致性等，就已经开始了集成测试。 集成测试阶段，测试方法是动态变化的，从白盒测试方法向黑盒测试方法逐渐过渡。在自底向上集成的早期，白盒测试方法占较大的比例，随着集成测试的不断深入，这种比例在测试过程中将越来越少，渐渐地，黑盒测试慢慢占据着主导地位。 集成模式是软件集成测试中的策略体现，其重要性是明显的，直接关系到测试的效率、结果等，一般要根据具体的系统来决定采用哪种模式。集成测试基本可以概括为以下两种： 非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求一次全部组装起来所要的系统，然后进行整体测试。 渐增式测试模式：把下一个要