gbt 9585 计算机软件,GBT15532008计算机软件测试规范.PPT

GBT15532008计算机软件测试规范

没有：生命周期模型、测试规格技术、静态测试技术、办公环境、测试功能与培训、评估、底层测试 不同的：介入时间 – Degree of Involvement， 测试自动化 - Test tools, 承诺与动力 – Stakeholder commitment 方法的范围 – Methodology practice 新增：Test Organization, Test case design, Tester professionalism Thank you Q & A MRD: Market Requirement Document Fns: Functional Specification 1) 软件测试如何支撑或协助“持续不断地及早交付有价值的软件”？如何在非常有限的时间内进行充分的测试？ 2) “欣然面对需求变化，即使在开发后期也一样” ，那么测试如何适应这种变化？如何快速地完成回归测试？ 3) 敏捷开发强调开发和测试一起工作，“项目中的每一天都不例外”，在这样的原则下，如何去做敏捷测试？ * “可工作的软件是进度的首要度量标准”，谁做的测试不重要，关键是要有准备好的测试，随时验证已完成的工作。 * “坚持不懈地追求技术卓越和良好设计”，在处理每个测试任务时，都应该找到最有效的办法 * 1) 软件测试如何支撑或协助“持续不断地及早交付有价值的软件”？如何在非常有限的时间内进行充分的测试？ 2) “欣然面对需求变化，即使在开发后期也一样” ，那么测试如何适应这种变化？如何快速地完成回归测试？ 3) 敏捷开发强调开发和测试一起工作，“项目中的每一天都不例外”，在这样的原则下，如何去做敏捷测试？ * 从2003年开始，人们逐渐实践TDD，而ATDD 是在2007年Lasse Koskela写了一本书《测试驱动：Java开发人员的TDD和ATDD》 ，才开始引起大家的更多关注。从那时算起也有7年了，但在国内，则是最近一两年的事。当然，我们可以将TDD和ATDD结合起来使用，形成一种混合的方法模型。 * * 敏捷开发？自动化测试？ 代码质量？持续集成？ * * Customer Benefit: “With WebEx Meeting Center, you can speed up business decision making and at the same time reduce travel cost and time” Interpretation：解释、说明 Mutually：互为、相互地 * 开发人员多、测试人员少，测试更关注效率 整个开发节奏很快，测试要跟上这个节奏 测试时间很少，需要快速完成测试 对产品或业务不够熟悉，需要操作或使用它来熟悉 产品某些部分复杂，需要不断探索，才能很好地完成测试 * * * * 4.3 软件测试流派 各测试流派的特征 * 上下文驱动测试方法 CDT: Context-driven Testing 任何实践活动的价值依赖于它所处的上下文 在某个上下文中只有好的实践，没有最佳实践 一起工作的人，才是项目的最重要组成部分 项目的发展往往难以预料 产品是问题的解决方案，如果问题没得到解决，产品是无用的 好的软件测试时一个富有挑战性的智力过程。 只有通过判断和技能，并在整个项目过程中协同练习它们，我们才能在正确的时间做正确的事，以有效地测试我们的产品 4.4 基于风险的测试策略 基于风险的测试策略是指评估测试的优先级，先做高优先级的测试，如果时间或精力不够，低优先级的测试可以暂时先不做 软件测试总是有风险的，基于风险的测试策略是最常用的策略 在敏捷开发模式中，这种策略更能发挥价值 基于风险的测试策略分析 软件产品的风险度可以通过出错的影响程度和出现的概率来计算 风险测试步骤 列出软件的所有功能和特性； 确定每个功能出错的可能性； 如果某个功能出错或欠缺某个特征，需要评估对用户使用软件产品的影响程度； 根据上面两个步骤，计算风险度； 根据可能出错的迹象，来修改风险度； 决定测试的范围，编写测试方案 4.5 测试过程改进 4.5.1 TMMi (Testing Maturity Model integration) 4.5.2 TPI (Test Process Improvement) 4.5.3 CTP (Critical Test Process) 4.5.4 STEP (Systematic Test & Evaluation Process) 4.5.1 TMMi 过程能力描述了遵循一个软件测试过程可能达到的预期结果的范围。TMMi的建立，得益于以下3点： 充分吸收、CMM/CMMi的精华； 基于历史演化的测试过