软件测试基础理论体系学习5-静态测试的理解

Posted 2022-12-16 虫无涯

5-静态测试的理解

• 1 介绍
• 2 静态测试技术
• • 2.1 代码检查
  • • 2.1.1 代码走查
    • 2.1.2 编码风格与规范
    • 2.1.3 审查
    • • 2.1.3.1 代码审查和代码走查
      • 2.1.3.2 代码审查清单
  • 2.2 静态结构分析
  • 2.3 代码质量度量

1 介绍

• 静态测试包括包括代码检查、静态结构分析、代码质量度量等。
• 它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。
• 动态测试在完成静态测试之后进行，这样，就需要设计一系列的测试用例来确保测试的完整性和有效性，而在测试用例的设计中，通常会把白盒测试和黑盒测试结合起来使用。

2 静态测试技术

静态测试是指不运行程序进行的测试–只是检查和审阅。静态测试包括包括代码检查、静态结构分析、代码质量度量等。

2.1 代码检查

• 代码检查包括代码走查、代码审查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面；
• 可以发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。

2.1.1 代码走查

代码走查的一个问题是全部的代码是否都需要走查，在实践中，通常是不可行的，测试者必须找到那些必须要走查的代码，例如，由于在将来的版本中引入缺陷的风险，由于维护阶段的费用很高，将会留下一些代码或者随机检查，或者按照优先权次序。

代码走查过程中的最大的问题是劝说开发者要遵循一定的标准，开发人员对于代码走查可能会有这样的态度：我写的代码为什么要别人批评我写代码的方式。代码走查要采用一个公认的标准以便所有人都能够同意接受它的要求，所有这些都要小心选择并能够全面反映团队的工作环境。

正规的走查是把代码打印出来，邀请别的同行开会检查代码的缺陷。但这种方法太耗时间，所以一般在走查会议上各开发人员自己讲解自己的逻辑、写法，让别人提意见。在编码阶段这种会议有助于大家了解整个项目情况，也有助力于各开发人员及早发现问题。

2.1.2 编码风格与规范

在程序设计中要使程序结构合理、清晰，形成良好的编程习惯，对程序的要求不仅是可以在机器上执行，给出正确的结果，而且要便于程序的调试和维护，这就要求编写的程序不仅自己看得懂，而且也要让别人能看懂。有时候会出现过了一年半载，连编程者自己也读不懂程序的情况。程序如同一篇文章，应该易于被人看懂，读起来流畅，必要时又容易修改，可以从源程序代码中得到提示从哪里修改。好的程序设计风格有助于提高程序的正确性、可读性、可维护性、可用性。

好的风格对于好的程序设计具有关键性作用。写好一个程序，当然需要使它符合语法规则、修正其中的错误和使它运行得足够快，但是实际应该做的远比这多得多。一个写得好的程序比那些写得差的程序更容易读、更容易修改。经过了如何写好程序的训练，生产的代码更可能是正确的。

程序设计风格的原则根源于由实际经验中得到的常识，它不是随意的规则或者处方。代码应该是清楚的和简单的-------具有直截了当的逻辑、自然的表达式、通行的语言使用方式。

2.1.3 审查

2.1.3.1 代码审查和代码走查

代码审查是提高代码质量的良药。但良药苦口，也有很多问题。

没有习惯代码审查的开发员的心理抵触。当指出代码中的问题时，很多程序员会感到难堪。特别是不直接影响程序功能的代码，比如，不良代码风格。另外，现在的软件开发常常是多人维护的，如果不良代码是别人写的，总感觉象代人受过一样。这时，不得不反复说明，代码审查目的是帮助找到问题，而不是针对个人。

如果代码审查没有目标，则很容易使得代码审查变得很无趣，变成了程序逻辑报告会。通常，在代码审查之前，先确定一个审查目标，比如今天主要看代码风格，或安全问题等。这样容易找出问题。如果能事先通报一个检查列表，审查之前表态：今天主要审查这些条目，那会更有效。

2.1.3.2 代码审查清单

这个清单只对结构化编程测试具有意义，不包括特殊应用领域和面向对象软件的测试。

• 数据引用错误

是指使用未经正确初始化用法和引用方式的变量、常量、数组、字符串或记录而导致的软件缺陷。如：变量未初始化、数组和字符串下标越界、对数组的下标操作遗漏[0]、变量与赋值类型不一致、引用的指针未分配内存。

• 数据声明错误

数据声明软件缺陷产生的原因是不正确的声明或使用变量和常量。

• 计算错误

计算或者运算错误是基本的数学逻辑问题。计算无法得到预期结果。如：不同数据类型或数据类型相同但长度不同的变量计算、计算过程中或计算结果溢出、赋值的目的变量上界小于赋值表达式的值、除数/模为0、变量的值超过有意义的范围（如概率的计算结果不在0－1范围内）。

• 比较错误

小于、大于、等于、不等于、真、假。比较和判断错误很可能是边界条件问题。如：混淆小于和小于等于、逻辑表达式中的操作数不是逻辑值。

• 控制流程错误

控制流程错误的原因是编程语言中循环等控制结构未按预期方式工作。通常由计算或者比较错误直接或间接造成。如：模块或循环无法终止、存在从未执行的代码、由于变量赋值错误而意外进入循环。

• 子程序参数错误

子程序参数错误的来源是软件子程序不正确的传递数据。如：实际传送的参数类型或次序与定义不一致、更改了仅作为输入值的参数。

• 输出错误

包括文件读取、接受键盘或者鼠标输入以及向打印机或者屏幕等输出设备写入错误。如：软件没有严格遵守外部设备读写数据的专用格式、文件或外设不存在或者为准备好的错误情况发生时没有相应处理、未以预期的方式处理预计错误、错误提示信息不正确/不准确。

• 其他检查

软件是否使用其他外语？处理字符集的范围（ASCII或Unicode）？是否需要移植？是否考虑兼容性？编译时是否产生警告或提示信息？

2.2 静态结构分析

• 静态结构分析主要是以图形的方式表现程序的内部结构，例如函数调用关系图、函数内部控制流图。
• 函数调用关系图以直观的图形方式描述一个应用程序中各个函数的调用和被调用关系；
• 控制流图显示一个函数的逻辑结构，它由许多节点组成，一个节点代表一条语句或数条语句，连接结点的叫边，边表示节点间的控制流向。

2.3 代码质量度量

ISO/IEC 9126国际标准所定义的软件质量包括六个方面：功能性、可靠性、易用性、效率、可维护性和可移植性。软件的质量是软件属性的各种标准度量的组合。

---

【特别说明】：知识来源于网络、各种资料、书本、网站等，本文仅用于学习使用，不做他用，如果涉及版权问题，请联系博主删除，谢谢