搜索
3.1代码检查3.2用于代码检查的错误列表3.3代码走查3.4桌面检查第3章代码检查、走查与评审静态测试（人工测试）不运行程序进行测试，即检查和审阅静态黑盒测试——检查产品说明书静态白盒测试——检查代码，在不执行的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，有时称为结构分析。动态测试（基于计算机的测试）运行和使用软件以发现错误，即通常意义上的测试第3章代码检查、走查与评审—静态测试和动态测试人工测试方法的正规性、精确性不如基于计算机测试，但并不妨碍测试取得成功，相反可以提高测试的功效和可靠性错误发现得越早，改正错误成本越低，正确改正错误可能性越大程序员在开始基于计算机的测试时要经历一个心理上的转变，改正早期发现的错误比改正后期计算机执行发现的错误时失误更少更容易定位以及发现由该错误引发的其他缺陷（如连锁错误或类似错误）降低调试成本通常会有效地查找出30％－70％的逻辑设计和编码错误第3章代码检查、走查与评审—人工测试人工测试的主要方法代码检查代码走查可用性测试第3章代码检查、走查与评审—人工测试负责静态测试的人员不是固定的。在某些小组中，程序员就是组织和审查的人员，软件测试员被要求作为独立的观察者。还有一些小组，软件测试员是该任务的执行人，要求编写代码的程序员和其他同时帮助审查。采用何种方式取决于开发小组的自身状况。3.1代码检查静态白盒测试一般面临的情况是不能善始善终，因为小组会认为太好使，费用太高，没有产出。原因是人们认为程序员的任务就是编写代码，而任何破坏代码编写效率的事情都会减缓开发过程。3.1代码检查四个基本要素确定问题遵守规则准备编写报告3.1代码检查实施过程协调人在代码检查前几天分发程序清单和设计规范编码人员讲述程序的逻辑结构，其他人员提问题并判断是否存在错误(对照历来常见的编码错误列表)注意力集中在发现错误而非纠正错误上（非调试）会议结束后，程序员会得到一份已发现错误的清单3.1代码检查人员组成（4人）一人负责协调：分发材料、安排进程、确保错误随后得到改正被测试程序的编码人员程序的设计人员和一名测试专家代码检查的其他作用程序员会得到编程风格、算法选择及编程技术等方面的反馈信息其他参与者也可以同样受益3.1代码检查1.数据引用错误变量使用前是否赋值或初始化？容易引起变量使用错误，特别是对于指针或引用变量。在java中要求变量在使用前必须初始化。数组下标的范围和类型是否存在下标越界错误，下表类型是否为整型。通过指针引用的内存单元是否存在（虚调用）？如在函数返回局部变量的指针或引用时会产生虚调用错误。被引用的变量或内存的属性是否与编译器预期的一致？如A类型的指针或引用是否指向的是非A类型对象。3.2用于代码检查的错误列表2.数据声明错误是否所有变量都已声明？绝大多数编程语言要求变量先定义后使用，可保证变量使用的安全性。默认的属性（默认值）是否正确？变量的初始化是否正确？变量的初始化是否与其存储空间的类型一致？是否每个变量都有正确的长度、类型和存储类别？是否存在相似名称的变量？3.2用于代码检查的错误列表3.运算错误是否存在非算术变量之间的运算？是否存在混合模式的运算？（int与float类型）是否存在不同字长变量之间的运算？（int与long类型）目标变量大小是否小于所赋值的大小？（精度损失或越界错误）中间结果是否上溢或下溢？是否存在除0错误？操作符的优先顺序是否正确？整数除法是否正确？（精度问题，如2*(i/2)==i）3.2用于代码检查的错误列表intx=1;inty=2;floatz=0;z=x/y;System.out.println(z=z);OUTPUT:z=03.2用于代码检查的错误列表4.比较错误是否有不同类型数据的比较运算？（如日期与数字）是否有混合模式或不同长度数据的比较运算？比较运算符是否正确？（如至多、至少，不小于）布尔表达式（与、或、非）是否正确？比较运算符是否与布尔表达式相混合？（如2i10对吗？）是否存在浮点数的比较？优先顺序是否正确？（例如if((a==2)&&(b==2)||(c==3)）布尔表达式的计算方式（例如if((x==0&&(y/x)z)）3.2用于代码检查的错误列表5.控制流程错误是否所有循环都能终止？（循环结束条件是否能满足以及递归的终止条件是否能满足。）是否存在由于入口条件不满足而跳过循环体？（do…while循环）是否存在仅差一个的循环错误？（如for(inti=0;i=10;i++){}）程序结构中括号是否匹配、if…else是否匹配、do…while是否匹配、try…catch是否匹配等。3.2用于代码检查的错误列表for(i==x;i=z;i++){...}while(NOTFOUND){...}3.2用于代码检查的错误列表6.接口错误形参和实参的数量是否相等？形参的属性是否与实参的属性相匹配？形参的属性是否与实参的顺序相匹配？形参的单位是否和实参匹配？（属逻辑错误）是否改变了某个仅作为输入值的形参？（C++中的const关键字）全局变量的定义是否一致？3.2用于代码检查的错误列表7.输入输出错误文件属性是否正确？打开文件的语句是否正确？缓冲区、内存大小是否足够来保留程序将读取的文件？文件在使用前是否打开？文件在使用后是否关闭了？文件结束条件是否本正确处理？是否处理了IO错误？打印或输出的文本信息中是否存在拼写或语法错误？即输出结果正确性。3.2用于代码检查的错误列表8.其他检查是否存在未引用过的变量？每个变量的属性和赋予的默认值是否一致？编译通过的程序是否存在“警告”或“提示”信息？程序或模块是否对输入的合法性进行了检查？（如第一章中三角形例）程序是否遗漏了某个功能？3.2用于代码检查的错误列表代码走查和代码检查类似，都是以小组为单位进行代码阅读，是一系列规程和错误检查技术的集合。二者的过程大致相同，不同之处在于规程稍微不同走查会议期间，每个测试用例都在人们脑中推演，即把测试的数据沿着程序的逻辑结构走一遍，记录程序的状态供监视，很多错误是在向程序员提问的过程中发现的。其他与代码检查相同的地方参与者所持的态度同样非常关键代码走查也会带来同样的附带作用3.3代码走查桌面检查是人工查找错误的一种古老的方法桌面检查可视为由单人进行的代码检查或代码走查由一个人阅读程序，对照错误列表检查程序，对程序推演的过程。桌面检查的缺点桌面检查的效率低是一个完全没有约束的过程违反了测试原则：人们一般不能有效测试自己编写的程序，因此桌面检查最好由其他人而非该程序的编写人员来完成桌面检查的效果逊色于代码走查或代码检查缺少了代码检查和走查小组中存在的互相促进的效应3.4桌面检查人工测试的必要性和有效性人工测试方法利用错误列表进行代码检查小组代码走查桌面检查小结