导图社区 《软件测试的艺术》分享1 -第6张
这是一篇关于《软件测试的艺术》分享1 -第6张的思维导图
测试
这是一篇关于《产品思维》的思维导图
这是一篇关于Google软件测试之道的ACC方法的理解。
社区模板帮助中心，点此进入>>
推荐位接入负反馈和找相似
小蜜运营后台
关闭其他及左、右侧文件（即IDE通用关闭tab功能）测试用例
通用检索功能测试用例
通用云文件保存需求测试用例
fms财务软件测试用例
软件测试
软件系统故障模式库
python-selenium自动化测试框架
软件测试面试常问的术语问题汇总
《软件测试的艺术》分享1
一次自评价测试
这个程序从一个输入对话框中读取三个整数值，这三个整数值代表了三角形三条边的长度。程序显示提示信息，指出该三角形是何种三角形：不规则三角形、等腰三角形还是等边三角形。 不规则三角形：三条边不相等 等腰三角形：有两条边相等 等边三角形：三条边都相等
有效等价类
输出为不规则三角形
输出为等腰三角形
输出为等边三角形
无效等价类
不能构成三角形的三条边
任意两边之和小于第三边
任意两边之和等于第三边
三边有为0
三边有负数
需要输入多组数据
输入的边长个数不对
只输入一边
只输入两条边
全为空
软件测试的心理学和经济学
心理学
软件测试的更为合适的定义
测试是为了发现错误而执行程序的过程
错误定义
证明软件不存在错误的过程
证明软件能够正确完成其预定的功能
建立一个“软件做了其应该做的”信心的过程
经济学
建立策略
黑盒测试
数据驱动的测试
输入/输出驱动的测试
测试目标与程序的内部机制和结构完全无关
穷举测试是无法实现的
无法测试一个程序以确保它是无错的
需要考虑软件测试的经济学问题
通过有限的测试用例，最大限度的提高发现的问题的数量，以取得最好的测试效果
白盒测试
逻辑驱动的测试
对程序的逻辑结构进行检查
穷举路径测试
不可能
不切实际
穷举也并不代表程序完全正确
不能保证程序符合其设计规范
不能发现是否缺少必需路径
可能不会暴露数据敏感错误
原则
1. 测试用例中一个必需部分是对预期输出或结果的定义
必须包括的两个部分
对程序输入数据的描述
对程序在上述输入数据下的正确输出结果的精确描述
2. 程序员应当避免测试自己编写的程序
3. 编写软件的组织不应当测试自己编写的软件
更经济的方法是由客观独立的第三方来进行测试
4. 应当彻底检查每个测试的执行结果
5. 测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况
6. 检查程序是否未做其应该做的仅是测试的一半，测试的另一半是检查程序是否做了其不应该做的
7. 应避免测试用例用后即弃，除非软件本身就是一个一次性的软件
8. 计划测试工作时不应该默许假定不会发现错误
9. 程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比
集群效应
10. 软件测试是一项极富创造性，极具智力挑战性的工作
代码检查、走查与评审
观念转变
编写程序仅仅是为了提供给机器执行
阅读代码对于构成完善的软件测试和调试手段的价值
研读代码作为测试工作的一部分
人工测试方法
代码检查
代码走查
具有很多共同之处
优点
更有效
对错误精确定位
降低调试成本
缺点
不能有效的查找出高层次的设计错误
eg：需求分析阶段的错误
可用性测试
桌面检查
同行评审
基于计算机的测试方法
以组为单位阅读代码
一系列规程和错误检查技术的集合
代码检查小组
通常4个人
协调人员：称职的程序员
职责
为代码检查分发材料、安排进程
在代码检查中起主导作用
记录发现的所有错误
确保所有错误随后得到改正
程序作者
程序的设计人员
测试专家
具备较高的测试造诣
熟悉大部分的常见的编码错误
检查议程与注意事项
由程序编码人员逐条语句讲述程序的逻辑结构
参考常见的编码错误列表分析程序
注意力集中在发现错误上，而不是纠正错误
会议理想时间应在90~120min
对事不对人，和人有关的注意事项
检查过程采取积极和建设性的态度
代码检查的目标是发现程序中的错误，从而改进软件的质量
检查代码的衍生功效
程序员通常会得到编成风格、算法选择和编辑技术等方面的反馈信息
其他参与者也可以通过接触程序员的错误和编程风格而同样受益匪浅
用于代码检查的错误列表
数据引用错误
1. 是否有引用的变量未赋值或未初始化？
2. 数组：下标的值是否都在相应维规定的界限之内？
3. 数组：下表是否都是整数？
4. 当前引用的内存单元是否分配？
5. 通过别名引用时，内存区域中的数据值是否具有正确的属性？
6. 变量值的类型或属性是否与编译器所预期的一致？
7. 是否存在间接或直接寻址错误？
内存分配的单元小于内存可寻址的单元大小时
8. 当使用指针或引用变量时，被引用的内存的属性是否与编译器所预期的一致？
9. 假如一个数据结构在多个过程或子程序中被引用，那么每个过程或子程序对该结构的定义是否都相同？
10. 如果字符串有索引，当对数组进行索引操作或下标引用，字符串的边界值是否有“仅差一个”（off-by-one）的错误？
11. 对于面向对象的语言，是否所有的继承需求都在实现类中得到了满足？
数据声明错误
I. 是否所有变量都明确声明了
II. 默认的属性是否被正确理解
III. 变量初始化是否正确
IV. 变量是否被赋予正确的长度和数据类型
V. 变量的初始化是否与其存储空间的类型一致
VI. 是否存在相似名称的变量
容易产生混淆
运算错误
i. 是否存在不一致数据类型的变量间的运算
ii. 是否有混合模式的运算
iii. 是否有相同数据类型，不同字长变量间的运算
iv. 赋值语句的目标变量的数据类型是否小于右边表达式的数据类型或结果
v. 在表达式运算中是否存在表达式向上或向下溢出的情况
vi. 处罚运算中的除数是否可能为0
vii. 基于二进制时，运算结果是否不精确
viii. 特定场合，变量的值是否超出了有意义的范围
ix. 赋值顺序和操作符的优先顺序是否正确
x. 整数的运算是否有使用不当的情况
比较错误
A. 是否有不同数据类型的变量之间的比较运算
B. 是否有混合模式的比较运算
C. 比较运算符是否正确
D. 每个布尔表达式所叙述的内容是否都正确
E. 布尔运算符的操作数是否是布尔类型的
F. 是否有用二进制表示的小数或浮点数的比较运算
G. 对于包含多个布尔运算符的表达式，赋值顺序和运算符的优先级顺序是否正确
H. 编译器计算布尔表达式的方式是否对程序产生影响
控制流程错误
如果程序包含多条分支路径，索引变量的值是否会大于可能的分支数量
是否所有的循环最终都终止了
程序、模块或子程序是否最终都终止了
循环体是否有可能从未被执行过
循环越界了会如何
是否存在仅差一个的错误
是否存在不能穷尽的判断
接口错误
a. 形参数量是否正确实参数量 顺序是否正确
b. 实参属性是否与形参属性相匹配
c. 实参量纲是否与对应形参的量纲相匹配
d. 此模块传递给彼模块的实参数量、属性和量纲是否等于彼模块形参的
e. 调用了内置函数，实参的数量、属性和顺序是否正确
f. 如果某个模块或类有多个入口点，是否引用了与当前入口点无关的形参
g. 是否有子程序改变了某个原本仅为输入值的形参
h. 如果存在全局变量，在所有引用他们的模块中，他们的定义和属性是否一致
i. 常数是否以实参形式传递过
很危险
输入/输出错误
（1） 文件属性是否正确
（2） open语句是否正确
（3） i/o语句是否符合规范
（4） 缓冲大小与记录大小是否匹配
（5） 文件在使用前是否打开
（6） 文件在使用后是否关闭
（7） 文件结束条件是否被正确处理
（8） 是否处理了i/o错误
其他检查
1||| 在交叉引用列表中是否存在未引用过的变量
2||| 属性列表是否与预期一样
3||| 是否存在警告、提示信息
4||| 是否对输入的合法性进行了检查
5||| 是否遗漏了某个功能
与代码检查相似
建议参与者
一位极富经验的程序员
一位程序设计语言专家
一位程序新手
最终维护程序的人员
一位来自其他不同项目的人员
一位来自该软件编程小组的程序员
一位测试人员
一位记录员、协调角色
可视为单人进行的代码检查和走查
由一个人阅读程序，对照错误列表检查程序，对程序推演测试数据
一种依据程序整体质量、可维护性、可扩展性、易用性和清晰性对匿名程序进行评价的技术
对诸如以下问题进行回答
程序是否易于理解
高层次的设计是否可见且合理
低层次的设计是否可见且合理
修改此程序对评审者而言是否容易
评审者是否会以编写出该程序而骄傲
