小结(二)

软件开发阶段综述

• 软件产品会经历从构思,开发,评价,改正,投入正式使用到寻找买家不同阶段.从最初的设想到最终的使用,叫做产品的生命周期(我想大家对个定义很熟悉,稍微温习一下,呵呵 -_-)
• 每一个阶段之间都是交迭进行的.
• 测试与改正活动可以在软件生命周期的任何阶段进行的.
• 缺陷发现并纠正得越早,付出的代价越小(很多人应该同意飧鏊捣ǖ?..)

规划阶段进行的测试

• 在规划阶段,测试人员从以下六个方面评价需求文档
  • 这是"真正的"需求吗?描述的产品是否就是要开发的产品呢?
  • 需求是否完备?第一个发布版本是否需要更多功能?列出的需求是否能减去一部分?
  • 需求是否兼容?需求可能是在逻辑上不兼容的(如,可能是矛盾的)或在心理学上是不兼容的.有些特征源自同一个产品的不同概念,用户解释其中一点,可能无法理解其他的.
  • 需求是否可实现?需求设想的硬件是否比实际运行得更快?它们需要的内存,I/O设备是否太多,要求的输入或输出设备的分辨率是否过高?
  • 需求是否合理?在开发进度,开发费用,产品性能,可靠性和内存使用之间存在平衡关系.这些被都想到了吗?需求是否要求产品运行速度极快,零缺陷,仅占6个字节的存储单元,明天下午就得完成?这些要求单独来说都可以实现,但作为同一个产品,不可能同时实现.是否认识到应该安排一个优先级计划?
  • 需求是否可测?判断设计文档是否满足需求有多难?
• 产品对照评价
  • 最初,对竞争产品进行的分析,会导致需求文档和功能定义的规模膨胀,且费用高,根本无法把竞争产品身上所发现的所有好点子都囊括进去.另外,挤在一起根本无法正常的运行.即使是相互的兼容性很高,随着特征集的增长,产品的复杂度也会相应提高.
  • 从竞争产品中罗列出来的好点子,只能做为参考,但必须进行裁剪,而不能完全变成需求.由重点问题小组提供对此进行裁剪的基本方法.
• 重点问题小组
  • 小组的主要任务是考察当前市场对新主意的反响,而不是说服客户群.
  • 小组能够从多种一般性层面上给出反馈.
• 任务分析
• 这是一种设计手段,对于设计用户界面至关重要.
• 在需求未确定之前不应该进行任务分析,但是任务分析的结论又往往会挑战已成文的产品需求.

设计阶段的测试

• 测试人员应对下列问题进行调查.
• 设计是否良好? 它能否最终导致高效,简洁,可测试,可维护的软件产品?
• 设计是否满足需求? 如果规划文档是非正式的,可变更的和有歧义的,那么设计文档就将是对产品需求的第一份正式说明.
• 设计是否完备?它是否规定了模块间的关系,模块如何传递数据,异常条件下会发生什么,每个模块应赋予什么样的出事状态,以及这些状态如何得到保证?
• 设计是否可行?计算机能运行得这样快吗?有足够的内存吗?有足够的I/O设备吗?数据库中数据的检索速度能达到这样快吗?
• 设计涵盖错误处理的程度如何?在检查设计中对所有似是而非的错误条件进行处理时, 问一下给定错误是否以合适的程度进行处理, 也很重要.
• 评审会议:目的在于识别设计中存在的问题, 并不准备解决它们.有三种通常类型的评审会议:
• 走查:设计人员对程序进行模拟,一步一步地展示程序如何处理由测试人员提供的测试数据.
• 审查:测试人员按照检查表中的每一项逐行检查设计文档.
• 技术评审:测试人员把一系列问题带入会议中.
• 伪代码分析