软件测试经验与教训之测试手段与程序错误分析

1.人们可以做的所有测试都可以分为5个方面进行描述：

。测试员：进行测试的人。如用户测试需要站在用户，商家，供应商等不同角色的角度进行测试

。覆盖率：测试了哪些内容。如功能测试中，要测试每个功能，接口测试中测试每个接口

。潜在问题：测试的原因（要测试什么风险）如测试极值问题

。活动：如何测试。例如回归测试，冒烟测试，探索式测试

。评估：怎样判定测试通过还是不通过

所有的测试都是一个要素或者几个要素联合起来就行测试

2.【基于覆盖率的常用测试手段】：

1）功能测试：逐个测试每个功能，彻底测试功能，直到确信该功能没有问题。

2）功能集成测试：多个功能组合在一起执行的情况

3）菜单浏览：遍历产品中所有菜单和对话框，使用每个可选项

4）域测试：域是一个（数学）集合，包含所有可能的函数变量取值。在域测试中，要标识函数和变量。变量可以是输入或输出变量。把每个变量都要把其可能取值集合划分为等价类，从中选取代表值进行测试。 请注意哦，与功能测试形成对比的是，我们重点关注的是变量而不是功能。 进行域测试时必须分析变量，然后再根据分析，以这个变量作为输入或输出，测试设计这个变量的每个功能

5）等价类分析：所谓等价类，是输入条件的一个子集合，该输入集合中的数据对于揭示程序中的错误是等价的。从每一个子集中选取少数具有代表性的数据，从而生成测试用例。等价类又分为有效等价类和无效等价类。有效等价类代表对程序有效的输入，而无效等价类则是其他任何可能的输入（即不正确的输入值）。有效等价类和无效等价类都是使用等价类划分法设计用例时所必须的，因为被测程序若是正确的，就应该既能接受有效的输入，也能接受无效输入的考验。

6）边界测试：边界值是指对于输入等价类和输出等价类而言稍高于其边界值及稍低于其边界值的一些特定情况。效和无效的分界点，往往是程序的判定点，是程序中最容易出错的地方，也是测试人员重点的测试内容

7）最佳代表测试：例如输入框限制输入5到15个字符，一般输入8个字符，就可以判定除了边界外其他的值都是没有问题的

8）用各种方式映射和测试编辑字段：可以用多种方式改变某个字段中的值。直接输入，复制粘贴，通过各种方式改变字段的值。

9）逻辑测试：变量在程序中有关系，逻辑测试就是测试程序中的所有逻辑关系。因果图是一种用于设计大量基于逻辑的测试手段。

10）基于状态测试：程序的状态要发生转换。在给定状态中，有些输入是有效的，其他收入被忽略或拒绝。

11）路径测试：一条路径包含测试员所执行的所有步骤，或程序为了得到正确状态所通过的所有语句。

12）组合测试：相互组合测试两个或很多变量。 

3.【基于潜在问题的测试手段也就是基于风险测试】：

根据程序中，某个功能失效的可能性，以及如果失效确实发生可能造成的损失。 为了发现错误进行风险分析，功能怎么样会失效？什么风险因素导致这个功能失效。

。输入风险：限制程序可以处理的内容的约束。例如，程序只能处理32位数字，则程序应该检测并拒绝超出32位数字限制的输入

。输出风险：输入的合法的但是可能会导致产生程序不能处理的输出值。例如显示图片失败

。计算风险：输入输出没有问题，但是在计算某个值时程序失效。如，将两个很大的数乘在一起，积太大程序不能处理

。存储（或数据）约束：输入输出计算都是合法的，但是操作使程序耗尽内存，或产生的数据文件太大，程序不能处理。

。进行风险测试之前，还必须做相当量的非基于风险的测试，针对时序的测试

4.【基于活动的测试】：

回归测试：

脚本测试：

冒烟测试：

探索式测试：

游击式测试：

场景测试：

安装测试：

负载测试：

长序列测试：
性能测试：

5.【关于测试是否通过的基于评估的测试手段】：

与已保存的结果进行比较：通过将当前得到的结果和以前的结果进行对比

一致性是评估程序的主要手段，下面是七种主要的一致性

一致性是评估程序的主要标准

　　1.与历史一致。现在的功能行为与以前的行为一致。

　　2.与我们的想像一致。功能行为与机构的项目预期一致。
　　3．与可比较的产品一致。功能行为与可比较产品的类似功能一致。

　　4.与所声明的内容一致。功能行为与承诺提供的功能一致。

　　5.与用户的预期一致。功能行为与我们认为是用户想要的功能一致。
　　6.产品内部一致。功能行为与产品内部可比较的功能或功能模式的行为一致。

　　7.与用途一致。功能行为与明确的用途一致。

 6.提bug（或者叫错误报告）很重要，程序员通过bug进行程序修复，如果bug写的不行会造成时间的浪费还会造成对测试工程师能力的质疑。

　　上级也会通过bug的质量对测试工程师的技能进行评估

7.不要要弄bug数量来对测试或者开发进行考核。如果以bug数量考核程序员的话，会浪费大量的沟通时间，程序员会争辩是设计问题而不是程序问题，问题重复了，或者复现不了没有办法等等

　　如果以bug数量考核测试的话，会造成都去找显而易见的bug，难的复杂的问题没有人管没有人问。把同一个bug的不同实例全部分别提出来。

8.发现bug一定要及时报告，以免时间长了记不清楚细节

9.当多人合作的时候，即使的非常明显的bug也要看一下是否有人报告过

10.测试还需要找出产品设计不合理的地方。

11.极端的，小缺陷全部都要提出来，无论他改还是不改

12.要给bug明确严重等级和优先等级，这样开发改的时候，知道那些需要先改，那些需要后改。不要夸大问题的等级也不要缩小问题的等级

13.测试提bug，并不是让所有的bug都得到改正，而是准确的报告问题，使项目组能够理解问题的影响，并加以判断修复的代价。

例如：边界经常会测试出问题，可能会忽略用户正常使用方式。有人反馈过问题，会把放在更加重要的位置。

14.对于偶现的，极端场景下出现的bug，也要提当开发不愿意修复的时候，应该说明这个bug可能引发的后果。如果改的代价大于造成的影响那也要做个记录。

15.测试一定要把有争议性，偶现的等等bug都要提出来，因为只有bug才能很好的证明你确实发现了问题并且提出来。

　　对于偶现的bug，也要重视，有可能随着时间的流逝而变得更严重

16.对于其他人【如使用人员】提出来的问题，要反馈

17.如果产品使用者觉得功能不好，或都某些功能没有而感到失望，作为测试可以记录一下，以作参考

18.测试要注意产品使用产品的方式，以及喜欢该产品的什么功能，不喜欢该产品的什么功能。

19.发现一个bug后，可以对这个bug进行后续测试，以及对相关的进行测试，这样可以发现更多的bug

　　我们建议尝试以下单重后续测试

　　1.变化自己的行为：尝试与该任务相关的失效操作，尝试与该失效相关的操作等等

　　2.变化程序选项和设置：

　　3.变化软件和硬件环境：

20.某些bug可能因为成本的问题，最后不会被解决，这也是正常的。

21.对于很早之前的bug，最好可以咨询一下之前的开发或测试人员，因为这些bug有可能是 为了避免 其他更严重的bug而不进行修改的

22.给开发提bug的时候，如果产品文档上面没有写的，不要自己私下定方案要与产品沟通后才可以。

23.项目有bug很正常，要注意和开发沟通交流的语气，态度。

24.提bug时，最好能使用图片这样更清晰，也可以使用动态图片这样更清晰。实在不行可以操作给开发看。

25.开发已解决bug的时候，要及时的验证，如果验证不通过，要及时与开发交流沟通。有的时候可能是 开发代码没有上传等等原因造成没有验证通过的

26.如果bug被不予解决或者设计如此了，要及时与产品和开发进行交流沟通，如果实在不行要让他们写下理由