缺点defect 偏差variance 谬误fault 失败failure 问题problt 矛盾incosistency 错误error 特殊feature 毛病incident 缺陷bug 异常anomaly
导致软件缺陷最大的原因是产品说明书.
说不出来就做不出来.
软件测试员的目标是找出软件缺陷,尽可能早一些,并确保其得以修复.
软件测试员应具备的素质:
探索精神,故障排除能手,不懈努力,创造性,追求完美,判断准确,老练稳重,说服力.
软件测试员的一个基本素质是打破砂锅问到底.
软件测试员要学会的一个主要原则是如何把无边无际的可能减少到可控制的范围,以及如何针对风险制订作出明智抉择,去粗存精.
软件测试员用于描述测试方法的两个术语是墨盒子测试和白盒子测试.
黑盒子测试中,软件测试员只需要知道软件要做什么即可---而无法看到盒子中是如何运作的.
白盒子测试(开盒测试)中,软件测试员可以访问程序员的代码,并通过检查代码来协助测试---可以看到盒子里面.
描述软件测试的另外两个术语是静态测试和动态测试.
静态测试是指测试不运行的部分---只是检查和审阅.
动态测试是指通常意义上的测试---运行和使用软件.
测试产品说明书属于静态黑盒子测试.
了解软件最终结果的最佳方法是研究同类软件.
产品说明书属性检查清单:
完整,准备,精确,不含糊,清晰,一致,贴切,合理,代码无关,可测试.
软件缺陷情况:
总是,每一种,所有, 没有,从不.如果看到此类绝对或肯定的,切实认定的叙述,软件测试员就可着手设计针锋相对的安例.
当然,因此,明显,显然,必然,这些话意图诱使接受假定情况,不要中了圈套.
某些,有时,常常,通常,惯常,经常,大多,几乎,这些话太过模糊,有时发生作用的功能无法测试.
等等,诸如此类,依此类推,以这样的词结束的功能清单无法测试.功能清单要绝对或者解释明确,以免让人迷惑,不知如何推论.
良好,迅速,廉价,高效,小,稳定,这些是不确定的说法,不可测试.如果在产品说明书中出现,就必须进一步指明含义.
已处理,已拒绝,已忽略,已消除.这些说法可能会隐藏大量需要说明的功能.
如果...那么...(没有否则),找出有如果...那么...而缺少配套的否则结构的陈述.想一想如果没有发生会怎样.
不深入代码细节的软件测试方法称为动态墨盒测试.它是动态的.因为程序正在运行---闭上眼睛.
动态墨盒测试常常被称为行为测试.
选择测试案例是软件测试员最重要的一项任务.
软件测试有两个基本方法:通过测试和失败测试.
软件测试员不把软件当回事,只运用最简单最直观的测试案例.
在设计和执行测试案例时,总是首先进行通过测试.
纯粹为了破坏软件而设计和执行的测试案例称为失败测试或迫使出错测试.
选择测试案例的方法是等价分配,也称等价划分.等价分配是指分步骤地把过多(无限)的测试案例减小到同样有效的小范围的过程.
等价类别或者等价区间是指测试相同目标或者暴露相同软件缺陷的一组测试案例.
等价区间有合法字符,非法字符,合法长度的名称,过长名称和过短名称.
等价分配的目标是把可能的测试案例组合缩减到仍然足以测试软件的控制范围.
数据测试:就是在检查用户输入的信息,返回结果以及中间计算结果是否正确.
根据下列主要原则进行等价分配,以合理减少测试案例:边界条件,次边界条件,空值和无效数据.
三个失败状态测试是重复,压迫和重负,测试目标是处理连程序员都没想到恶劣条件下产生的问题的能力.
重复测试是不断执行同样的操作.
压迫测试是使软件在不够理想的条件下运行---内存小,磁盘空间少,CPU速度慢,调制解调器速率低等,观察软件对外部资源的要求和依赖的程度.
重负测试与压迫测试相反,压迫测试是尽量限制软件,而重负测试是尽量提供条件任期发挥,让软件处理尽可能大的数据文件.
静态白盒子测试是在不执行的条件下有条理地仔细审查软件设计,体系结构和代码,从而找出软件缺陷的过程,有时称为结构分析.
正式审查就是进行静态白盒子测试的过程,四个基本要素:确定问题,遵守规则,准备,编写报告.
静态白盒技术－通用代码审查清单:
一、数据引用错误。
定义：是指使用未经正确初始化用法和引用方式的变量、常量、数组、字符串或记录而导致的软件缺陷。
是否引用了未初始化的变量？查找遗漏之处与查找错误同等重要。
数组和字符串的下标是整数值吗？下标总是在数组和字符串大小范围之内吗？
在检索操作或者应用数组下标时是否包含“丢掉一个”这样的潜在错误？
是否在应该使用常量的地方使用了变量－例如在检查数组范围时？
变量是否被赋予不同类型的值？例如，无意中使代码为整形变量赋予一个浮点数值？
为引用的指针分配内存了吗？
一个数据结构是否在多个函数或者子程序中引用，在每一个引用中明确定义结构了吗？
二、数据声明错误。
产生的原因：不正确地声明或使用变量和常量
所有变量都赋予正确的长度、类型和存储类了吗？例如，本应声明为字符串的变量声明为字符数组了吗？
变量是否在声明的同时进行了初始化？是否正确初始化并与其类型一致？
变量有类似的名称吗？这基本上不算软件缺陷，但有可能是程序中其他地方出现名称混淆的信息。
存在声明过、但从未引用或者只引用过一次的变量吗？
在特定模块中所有变量都显式声明了吗？如果没有，是否可以理解为该变量与更高级别的模块共享？
三、计算错误。
是基本的数据逻辑问题，计算无法得到预期结果。
计算中是否使用了不同数据类型的变量，例如将整数与浮点数相加？
计算中是否使用了不同数据类型相同但不同长度的变量－例如，将字节与字相加?
计算时是否了解和考虑到编译器对类型或长度不一致的变量的转换规则？
赋值的目的变量是否小于赋值表达式的值？
在数值计算过程中是否可能出现溢出？
除数/模是否可能为零？
对于整型算术运算，某些计算，特别是除法的代码处理是否会丢失精度？
变量的值是否超过有意义的范围？例如，可能性的计算结果是否小于0%或者大于100%？
对于包含多个操作数的表达式，求值的次序是否混乱，运算优先级对吗？需要加括号使其清晰吗？
四、比较错误。
小于、大于、等于、不等于、真、假。比较和判断错误很可能是边界条件问题。
比较得正确吗？虽然听起来简单，但是比较应该是小于还是小于或等于常常发生混淆。
存在分数或者浮点值之间的比较吗？如果有，精度问题会影响比较吗？1.00000001和1.00000002极其接近，它们相等吗？
每一个逻辑表达式都正确表达了吗？逻辑计算如期进行了吗？求值次序有疑问吗？
逻辑表达式的操作数是逻辑值吗？例如，是否包含整数值的整型变量用于逻辑计算中？
五、控制流程错误。
原因：编程语言中循环等控制结构未按预期方式工作。它们通常由计算或者比较错误直接或间接造成。
如果程序包含begin..end和do...while等语句组，end是否对应？
程序、模块、子程序和循环能否终止？如果不能，可以接受吗？
可能存在永远不停的循环吗？
循环可能从不执行吗？如果是这样，可以接受吗？
如果程序包含像switch...case语句这样的多个分支，索引变量能超出可能的分支数目吗？如果超出，该情况能正确处理吗？
是否存在“丢掉一个”错误，导致意外进入循环？
六、子程序参数错误。
来源于软件子程序不正确地传递数据。
子程序接收的参数类型和大小与调用代码发送的匹配吗？次序正确吗？
如果子程序有多个入口点，引用的参数是否与当前入口点没有关联？
常量是否当作形参传递，意外在子程序中改动？
子程序是更改了仅作为输入值的参数？
每一个参数的单位是否与相应的形参匹配。
如果存在全局变量，在所有引用子程序中是否有相似的定义和属性？
七、输入/输出错误。
包括文件读取、接受键盘或者鼠标输入以及向打印机或者屏幕等输出设备写入错误。
软件是否严格遵守外部设备读写数据的专用格式？
文件或者外设不存在或者未准备好的错误情况有处理吗？
软件是否处理外部设备未连接、不可用，或者读写过程中存储空间占满等情况？
软件以预期方式处理预计的错误吗？
检查错误提示信息的准确性、正确性、语法或拼写了吗？
八、其他检查。
软件是否使用其他外语？是否处理扩展ASCII字符？是否需要用统一编码取代ASCII？
软件是否要移植到其他编译器和CPU，具有这样做的许可吗？如果没有计划或者测试，那么，移植性可能成为一个大难题。
是否考虑了兼容性，以使软件能够运行于不同数量的可用内存，不同的内部硬件，例如图形卡和显卡，不同的外设，例如打印机和调制解调器？
程序编译是否产生“警告”或者“提示”信息？这些信息通常指示进行了有疑问的处理。纯粹主义者可能认为警告信息是不可接受的。
动态白盒子测试(结构测试)是指利用查看代码功能和实现方式得到的信息来确定哪些要测试,哪些不要测试,如果开展测试.
动态白盒子测试不仅仅查看代码,还包括直接测试和控制软件,包括以下四个部分:
直接测试底层功能,过程,子程序和库.
以完整程序的方式从顶层测试软件,但是根据对软件运行的了解调整测试案例.
从软件获得读取变量和状态信息的访问权.
估算执行测试时命中的代码量和具体代码,然后调整测试,去掉多余的,补充遗漏的.
动态白盒子测试的目标是寻找软件缺陷,调试的目标是修复它们.
在底层进行的测试称为单元测试或者模块测试.递增测试有两条途径:自底向上和自顶向下.
在进行白盒子测试之前,一定要根据说明书建立黑盒子测试案例.
分段测试,数据范围(数据流,次边界,公式和等式,错误强制),代码范围(程序语句和代码行范围,分支范围,条件范围)
使用错误强制的好方法是迫使软件中的所有错误提示信息显示出来.
软件兼容性测试是指检查软件之间是否正确地交互和共享信息.
兼容性测试的两个常用术语是向前兼容和向后兼容.
向后兼容是指可以使用软件的以前版本.
向前兼容是指可以使用软件的未来版本.
使用文本文件是演示向前兼容和向后兼容最简单的办法.
本地化软件,甚至非本地化软件中存在的一个常见问题是扩展字符的处理.
重复执行测试的过程称为回复测试.
非侵入式:用于监视和检查软件不对其进行修改.
侵入式:以任何方式修改程序代码或者操纵操作环境.
beta测试可以成为寻找配置和兼容性软件缺陷的好方法.
频度和统计是跟踪项目进展,成效和测试的手段.
测试案例计划的四个目标:组织性,重复性,跟踪和测试证实.
软件测试三个任务:测试计划,实际测试,报告发现的问题.
报告软件缺陷的基本原则:尽快报告软件缺陷,有效描述软件缺陷,在报告软件缺陷时不做评价,补充完善软件缺陷报告.
软件质量评判人没的主要职责是检查和评价当前软件开发过程,并设法达到防止软件缺陷出现的目标.
