工行个人消费信贷项目软件测试计划

工行个人消费信贷项目软件测试计划内容摘要：

用的单位是否一致。 传送给另一个被调用模块的变元个数与参数的个数是否相同。 传送给另一个被调用模块的变元属性与参数的属性是否匹配。 传送给另一个被调用模块的变元，其单位是否 与参数的单位一致。 调用内部函数时，变元的个数、属性和次序是否正确。 在模块有多个入口的情况下，是否有引用与当前入口无关的参数。 是否会修改只是作为输入值的变元。 出现全程变量时，这些变量是否在所有引用它们的模块中都有相同的定义。 有没有把常数当作变量来传送。 当模块执行了外部的输入、输出时， Myers 提出还需要考虑： 5 宏源证券项目系统测试计划 文件的属性是否正确。 OPEN 语句是否正确。 格式说明与输入、输出语句给出的信息是否一致。 缓冲区的大小是否与记录的大小匹配。 是否所有的文件在使用前均已打开了。 对文件的结束条件的判断和处 理是否正确。 对输入、输出错误的处理是否正确。 有没有输出信息的正文错误。 对于局部数据结构应该在单元测试中注意发现以下几类错误： 不正确的或者不相容的说明。 不正确的初始化或者缺省值。 错误的变量名，如拼写错或者缩写错。 不相容的数据类型。 6 宏源证券项目系统测试计划 下溢、上溢或是地址错误。 除局部的数据结构之外，在单元测试中还应该弄清楚全程数据对模块的影响。 如何设计测试用例，使得模块测试能够高效率地发现其中的错误，这是非常关键的问题。 无论考虑何种逻辑覆盖都应该注意发现以下一些典型的计算错误： 对运算优先性的错误理解，或者是错误 的处理。 运算方式（ mode）未加区分，发生了混合运算的情况。 初始化错误 计算精确度不够。 表达式中符号表示的错误。 比较和控制流常常是彼此密切相关的，比较的错误势必导致控制流的错误。 需要特别注意发现的错误包括： 不同的数据类型进行比较 逻辑运算或其优先级用错 本应该相等的数据，由于精确度原因不相等。 变量本省或时比较有错。 7 宏源证券项目系统测试计划 循环终止不正确，或循环不已 在遇到发散的循环时不能摆脱出来。 循环控制变量修改有错。 程序运行中出现了异常现象并不奇怪，良好的设计应预先估计到，将来投入运行后可能发生什么出错的情况， 并给出相应的处理措施，使得用户不至于发生了这样的情况束手无策。 检验程序中处理这一问题解决得怎样，可能出现的情况有： 对运行发生的错误描述得难于理解。 指明的错误并非实际遇到的错误。 出错后，尚未进行出错处理便引入系统干预 意外处理不当 提供的错误信息不足，以致无法找到出错的原因。 边界测试通常是单元测试的最后一步，是不容忽视的。 实践表明，软件常常在边界地区发生问题。 例如，处理 N 维数组的第 N 个元素时很容易出错，循环到最后一次执行循环体时可能出错。 这可以利用边值分析方法来设计测试用例，以便发生这类程序错误。 单 元测试的步骤 单元测试常常被当作代码编写的附属步骤，也有人把代码编写和单元测试作为一个开发阶段考虑。 显然在程序编写完毕了、经过 8 宏源证券项目系统测试计划 复查、确认没有语法错误以后，针对每个程序模块单独进行的测试工作。 由于每个模块在整个软件中并不是孤立的，我们在每个模块进行单元测试时，也不能完全忽视它们和周围模块的相互联系。 为模拟这一联系，在进行单元测试时，需要设置若干辅助测试模块。 辅助模块有两种，一种是驱动模块（ Driver） ,用以模拟被测模块的上级模块；另一种桩模块（ Stub），用以模拟被测模块中所调用的模块。 自然驱动模块和桩 模块对测试人员来说是一种额外的负担，就是说，虽在单元测试中必须编写这些辅助模块的程序，但却并不作为最终的软件产品提供给用户。 好在这些模块的结构十分简单，模块间接口的全面检验可在组装测试中进行。 组装测试 在每个模块完成单元测试之后，需要按照设计时作出的结构图，把它们联系起来，进行组装测试 (Integrated Testing)。 经验不多的人可能会提出，既然单元测试时已经对所有模块的工作是否正常进行了检验，为什么还要联起来再次进行测试。