文档介绍：一个成功软件测试项目的经验一个成功软件测试项目的经验诺亚发表于 2009 年 09月 29日 15:10 阅读(2) 评论(0) 分类: 技术文档举报测试如何尽早介入基于以前的测试经验, 我们也越来越认识到测试人员应该尽早介入项目的重要性。简单地沿用测试 V 模型往往出现很多问题,特别是在项目进度拖延的情况下更是如此。如果测试人员一味固执地被要求严格案照 V 模型定义的标准来开展测试工作的话, 则结果往往是在项目初期测试人员工作量极度不饱和( 很多测试人员无所事事),而到了项目后期, 一旦项目经理决定压缩测试时间, 测试人员就不得不加班加点工作。但是,不少朋友实践“测试人员尽早介入”的效果并不理想,例如: 1. 测试人员参加项目前期的各种会议, 会被当作“专职的”会议记录员。 2. 测试人员参加代码评审, 又不甚了解程序开发语言, 浪费了时间其丢失了自信。实际上,在项目开发初期,测试人员可以开展很多有价值的工作,例如: 1. 评审需求文档的正确性和可测试性; 根据需求文档整理和分析测试需求,清晰明确的测试需求事测试设计的基础。 2. 在开发设计过程中, 根据需求文档和设计文档进行测试设计, 测试设计方案事测试用例的保证。 3. 和项目团队中的集成组和开发组协商软件版本的编译方式和编译进度以及测试人员提取版本的方式和进度。 4. 开发人员每天下午 4: 30 前提交所有可编译的代码, 每天晚上进行日编译; 5. 开发经理根据版本稳定情况,每周提交测试申请单。 6. 测试人员根据测试进度需要,提取测试版本。 7. 提前准备测试环境, 包括数据库环境, 操作系统和 Web 一用服务器, 以及复杂集群环境。 8. 如果项目需要, 还可以在此阶段研究一下自动测试工具, 包括一些准备外包测试的工作。根据产品的成熟度调整测试策略开发测试一盘棋。测试经理应该有大局观,保持测试策略总与开发的进展相一致, 保证最终的软件成果最佳( 而不是测试部发现 Bug 最多)。合理制定不同阶段的测试策略,会收到不错的效果。产品开发期同情的测试要忍!要在这个能够发现大批 Bug 的黄金时段学会做减法。就现实而言, 这个阶段的产品, 大多难以满足系统测试的条件。如果进行追杀式的测试, 无疑会加重开发人员的焦虑心情, 甚至对测试产生逆反心理。另一方面,测试工作部应停滞,特别式不少测试人员对产品的了解还流于皮毛, 抓紧时间进行“测试练兵”非常有必要。因此,, “产品开发期”的测试切忌生硬。其实, 此时程序人员也知道产品还不成熟,所以要测试经理要告诉测试执行人员: 1. 这个阶段不要提交界面简单错误和易用性方面的 Bug ( 可以先记录下来到项目末期提交), 否则会使开发人员质疑测试人员发现简单的 Bug 。 2. 换位思考, 了解此时开发人员最关心的功能是否能正确运行, 多对基本功能进行测试。产品成熟期积极的测试随着产品的不断成熟, 主要功能的实现已经趋于完善, 关键路径的测试已经不成问题。此时的程序员们,压力已经大大减轻,他们的工作重点也从“构建”转移到了“修复 Bug ”,这个阶段程序员对于 Bug 的接受程度是最高的,对 Bug 的修复和反馈也非常积极。于是,此时的测试工作应对整个产品的细节和所有路径进行覆盖测试,保证测试的全面性,层层深入地测试产品值得测试的各个部分, 尽可能多的发