-
对于测试，更为合适的定义应该是“测试是为发现错误而执行程序的过程”
人类行为总是倾向于具有高度的目标性，如果我们的目标就倾向于程序中存在错误，我们设计的测试数据就有可能更多的发现问题。 -
程序员应当避免测试自己编写的程序
当程序员“建设性”地设计和编写完程序之后，很难让他突然改变视角以一种“破坏性”的眼光来审查程序。 -
应避免测试用例用后即弃
复用省时省力，回归标准一致 -
程序某部分存在更多错误的可能性，与该部分已发现的错误的数量成正比
来源于经验，错误总是倾向于聚集存在，对容易产生错误的程序需要更多的额外测试 -
目前人们已普遍认识到错误发现的越早，改正错误的成本越低，正确改正错误的可能性也越大。
代码走查（CR），单元测试，AC...
其中代码走查可以发现30%~70%的逻辑设计和编码错误 -
黑盒测试 - 等价划分
a. 确定等价类：根据条件定义有效等价类和无效等价类
b. 生成测试用例 -
黑盒测试 - 边界值分析
考虑边界条件的测试用例具有更高的测试回报率 -
黑盒测试 - 因果图
需剖析原型（产品需求），明确相关的输入输出规则 -
黑盒测试 - 错误猜测
列举可能犯的错误或错误易发情况的清单，依赖于直觉 -
模块（单元）测试
模块测试的目的是将模块的功能与定义模块的需求或接口需求进行比较 -
高级测试
1.png
-
对错误发现时期的推测
image.png
-
可用性测试（用户体验）
a. 需多少人员进行测试
E=100*（1-（1-L）^n）
E = 找到错误的比例
n = 测试人数
L = 单测试人员发现可用性问题的比例
实验结论：L=31%时，6个测试人员可以发现90%的可用性问题，20个人员能够趋近100%，与28法则不谋而合。
image.png
b. 数据采集非常有价值
c. 用户体验调查问卷
d. 对于测试人员，最好足够能代表目标市场潜在用户群。心得：对于公司内部，可以适当找运营帮忙
网友评论