手工测试用例是针对手工测试人员，自动化测试用 例是针对自动化测试框架，前者是手工测试用例人员应用手工方式进行用例解析，后者是应用脚本技术进行用例解析，两者最大的各自特点在于，前者具有较好的异 常处理能力，而且能够基于测试用例，制造各种不同的逻辑判断，而且人工测试步步跟踪，能够细致的定位问题。而后者是完全按照测试用例的方式测试，而且异常 处理能力不强，往往一个自动化测试用例运行完毕后，报一堆错误，对于测试人员来定位错误是一个难点，这样往往发现的问题很少。所以，根据其各自的特点，需 要将两者有很好的定位：手工测试是在软件版本前几轮测试的重点，目的是验证功能，发现问题；自动化测试是应用在后几轮版本，保证软件版本模块修改或者添加 新功能后，没有影响开始的功能模块（因为软件中，各模块之间的接口以及类、函数方法等的互相引用，也是容易出问题的地方）。

 

手工测试用例和自动化测试用例功能定位的区别。

　　a）手工测试用例

　　　　i.较好的异常处理能力，能通过人为的逻辑判断校验当前步骤的功能实现正确与否。

　　　　ii.人工执行用例具有一定的步骤跳跃性。

　　　　iii.人工测试步步跟踪，能够细致的定位问题。

　　　　iv.主要用来发现功能缺陷

　　b）自动化测试用例

　　　　i.执行对象是脚本，任何一个判断都需要编码定义。

　　　　ii.用例步骤之间关联性强。

　　　　iii.主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工作中解脱出来。

　　　　iv.目前自动化测试阶段定位在冒烟测试和回归测试。

 

怎么保证我们花了时间和精力去做的自动化测试，其结果是有效的、是能够反映被测代码质量的？

答：

自动化测试或者测试用例的根本目的就是judge（判断）被测系统是否有问题，是以衡量被测产品的“标尺”存在的。所以，它具备一个重要的特征：在测试脚本和被测代码都保持不变的情况下，测试结果应该是稳定的、不变的。

根据这个原则，“坏用例”并不是指测试不通过的用例，更不是测试通过的用例，而是指那些在相同条件下，偶尔通过、偶尔不通过的测试用例。反之，“好用例”则是表现稳定的用例。

为什么说“坏用例”破坏性大？因为如果用例本身不具备稳定的结果输出，就无法准确的衡量被测产品是代码的问题还是用例本身的问题。如果每次测试结果都不能直接说明问题，需要进行反复分析，将直接导致大家对测试用例失去信心。也就是说，测试同学和开发同学会把测试用例的不通过，当成“Warning”而非“Error”,这样的最终效果就是自动化测试慢慢被抛弃。