手机软件测试基础.pptVIP

* * * * * * * * * * * * * * * * * * * * * ?实际测试是一个动态的过程，不能孤立静态地对待发现的错误，因为一个错误可能包含着其他的不同类型的错误。比如在对话框中，选择某个按钮，产生一个错误提示对话框，这可能是一个按钮功能错误，如果对话框中存在需要翻译而没有翻译的英文，则又是一个翻译错误，如果对话框中存在无法辨识的字符，则又是一个双字节错误，如果对话框中按钮排列重叠，则还是一个布局错误。 * * * * * * * * 文章出处：转载 作者：Kiki翻译 发布时间：2006-01-11 * * 手机测试基本技巧 需求及文档评审技巧(1) IEEE认为好的需求规格说明应该达到以下标准： 正确：每项需求都反映了一种需要。 完整：包含了所有必要的需求。 无歧义：各方在需求的含义上意见一致。 一致：所有部分都相符，如E/R模型与事件清单相符。 确定重要性、稳定性的等级：每项需求的优先级以及预期的修改。 可更改：易于修改且保持一致性。 可验证：能够检查是否满足了需求。 可追踪：由需求至目标/目的，至设计/代码。 其它：可由目标追踪至需求；能为客户、开发人员所理解。 手机测试基本技巧 需求及文档评审技巧(2) 1、兼容性?? 界面需求是否使软硬件系统具有兼容性？ 2、完备性?? 需求定义是否包含了有关文件（指质量手册、质量计划以及其他有关文件）中所规定的需求定义所应该包含的所有内容？?? 需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求？?? 功能性需求是否覆盖了所有非正常情况的处理？?? 是否已对各种操作模式（如正常、非正常、有干扰等）下的环境条件都作规定？?? 是否识别出了所有与时间因素有关的功能？它们的时间准则是否都明了？时间准则的最大、最小执行时间是否都定义了？?? 是否识别定义了在将来可能会变化的需求？?? 是否定义了系统的所有输入？?? 是否标识清楚了系统输入的来源？?? 是否识别了系统的输出？?? 是否说明了系统输入、输出的类型？?? 是否说明了系统输入、输出的值域、单位、格式等？?? 是否说明了如何进行系统输入的合法性检查？?? 是否定义了系统输入、输出的精度？?? 在不同负载情况下，系统的生产率如何？?? 在不同的情况下，系统的响应时间如何？?? 系统对软件、硬件或电源故障必须作什么样的反应？?? 是否充分定义了关于人机界面的需求？ 手机测试基本技巧 需求及文档评审技巧(2) 3、一致性?? 各个需求之间是否一致？是否有冲突和矛盾？?? 所规定的模型、算法和数值方法是否相容？?? 是否使用了标准术语和定义形式？?? 需求是否与其软硬件操作环境相容？?? 是否说明了软件对其系统和环境的影响？?? 是否说明了环境对软件的影响？ 4、正确性?? 需求定义是否满足标准的要求？?? 算法和规则是否有科技文献或其它文献作为基础？?? 有哪些证据说明用户提供的规则或规定是正确的？?? 是否定义了对在错误、危险分析中所识别出的各种故障模式和错误类型所需的反应？?? 是否参照了有关标准？?? 是否对每个需求都给出了理由？理由是否充分？?? 对设计和实现的限制是否都有论证？ 5、可行性?? 需求定义是否使软件的设计、实现、操作和维护都可行？?? 所规定的模式、数值方法和算法是否对待解问题合适？是否能够在相应的限制条件下实现？?? 是否能够达到关于质量的要求？ 手机测试基本技巧 需求及文档评审技巧(3) 6、易修改性?? 对需求定义的描述是否易于修改？例如是否采用良好的结构和交叉引用表等等？?? 是否有冗余的信息？是否一个需求被定义多次？ 7、健壮性?? 是否有容错的需求？ 8、易追溯性?? 是否可以从上一阶段的文档查找到需求定义中的相应内容？需求定义是否明确地表明前阶段中提出的有关需求的设计限制都已被覆盖？ 例如，使用覆盖矩阵或交叉引用表？?? 需求定义是否便于向后继开发阶段查找信息？ 9、易理解性?? 是否每一个需求都只有一种解释？?? 功能性需求是不是以模块方式描述的，是否明确地标识出其功能？?? 是否使用了形式化或半形式化的语言？?? 语言是否有歧义性？?? 需求定义是否只包含了必要的实现细节而不包含不必要的实现细节？是否过分细致了？?? 需求定义是否足够清楚和明确使其已能够作为开发设计规约和功能性测试数据基础？?? 需求定义的描述是否将对程序的需求和所提供的其它信息分离开来? 10、易测试性和可验证性?? 需求是否可以验证？ 是否对每一个需求都指定了验证过程？? 数学函数的定义是否使用了精确定义的语法和语法符号？ 手机测试基本