测试资料收集.docVIP

自动化测试能否最终取代手工测试 手工测试和自动化测试都是软件质量保障的重要途径，也是很多测试人员争相讨论的两种测试方法。如何正确的看待这两种测试方式，更好的使两者相互结合是我们现在所要讨论的话题。本文总结了自动化测试和手工测试的优点和缺点，列举了各自的适用范围，并分析了自动化测试无法最终取代手工测试的原因。 1. 自动化测试是灵丹妙药吗？ 前提 需手工执行的工作 快速 脚本执行比人工执行快 实际上，测试人员还需要做编写脚本，设置脚本如何运行，解释测试结果，讨论是否需要修复等工作。所有这些工作使得测试执行实际上只是整个测试工作量中的一个小部分。 第一次的自动化测试项目将花比纯粹手工测试更多的时间。我们应该将自动化看成是改进测试人员效率的一个工具，而不是一个测试人员的完全替代物。利用测试脚本程序可以很快地将测试人员带到测试应用程序的同一水平线上。 全面 你可以构建一个覆盖应用程序每一个功能的测试包 自动化测试覆盖的功能点越多，测试程序就会变得越复杂。自动化测试战胜了消耗时间和测试深度之间的平衡。 在做自动化测试之前，详细地说明所有的功能点及其运行条件。利用手工测试的检查表可以发现许多人为的错误。测试人员要集中在测试深度上。警惕将要使用新技术的地方及其预算。 可靠 每次测试脚本在运行时执行相同的操作，因此减少了人为的错误 现在的技术只能识别那些已经被编程的部分并进行检查。需要人为地检查并且留意异常的事情 利用自动化做些沉闷的工作，如扫描应用程序中期望的菜单标题等。 并且为测试人员给出可能发生的问题的指示。 可编程 你可以编写复杂的测试脚本来找出应用程序中隐藏的信息 花在编写复杂测试脚本的时间会像手工测试中“真实工作”的时间一样被检查吗？测试人员乐意成为像遵守纪律的编程人员一样维护复杂的程序代码吗？ 预算明确的用于自动化研究及开发（及传播）的时间。培训编程人员并核查他们构思逻辑及从API中提取信息的熟练程度。 可以重复使用 你可以测试软件将如何回应重复执行相同操作 当软件发生更改时，脚本和图像可能都需要重现编写，甚至要重新设计 采用数据驱动的方法：利用spreadsheets或测试说明书数据库来有计划地驱动测试 可重用 你可以重复使用测试脚本来测试应用程序的不同版本，即使用户界面发生了变更 为了彼此可以更好的工作，需要在一个公共的架构上创建程序代码 强制使用命名规范及函数的公用库。设计模块中的测试脚本从一个共同的起点开始，例如主页。并且追踪使用的测试数据。 ????由此可见，自动测试生来就是用脚本写成的，而不是探索性的，它需要我们设定上下文后才能在一定的范围内为特定的目的而执行。即便我们使用的是一个引入了所有可能情况的自动测试组合，我们的测试也只能在它们覆盖的地方游刃有余，但对于其它没有涵盖到的地方，它们就鞭长莫及了。如果出现了哪些没有预料到的情况，那么它们很可能就失效了，而且即使它们能够从这些情况中恢复过来，它们还是无法停止正在处理的任务并检查没有预料到的情况。很显而易见将所有测试都自动化是不切实际的。 2. 手工测试会被自动化测试替代吗？ 3. 什么时候该用自动化测试？ ????????回归测试。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。????????可以运行更多更繁琐的测试。自动化的一个明显的好处是可以在较少的时间内运行更多的测试。????????可以执行一些手工测试困难或不可能进行的测试。比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。?????????更好地利用资源。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。????????测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。????????测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。????????增加软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。 4. 什么时候该用手工测试？ ????????界面测试????????用户体验测试????????