自动化测试应用范围，什么样的项目适合自动化测试

1，什么样的项目适合自动化测试

虽然，在你拿到这本书时已经对要测试的项目做了一些分析和考量，但还是有必要在这里啰嗦一下不是所有项目有适合实施自动化测试的，以免对项目实施自动化过程中发现困难重重，浪费了大量的人力和时间而没有得到应有的收益。 1、任务测试明确，不会频繁变动 2、每日构建后的测试验证 3、比较频繁的回归测试 4、软件系统界面稳定，变动少 5、需要在多平台上运行的相同测试案例、组合遍历型的测试、大量的重复任务 6、软件维护周期长 7、项目进度压力不太大 8、被测软件系统开发比较规范，能够保证系统的可测试性 9、具备大量的自动化测试平台 10、测试人员具备较强的编程能力当然，并非以上10 条都具备有情况下才能开展测试工作。这里就需要读者做综合的权衡。在我们普遍的经验中，只要满足三个条件就可以对项目开展自动化测试：软件需求编程不频繁测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。项目周期较长由于自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成。这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。自动化测试脚本可重复使用自动化测试脚本的重复使用要从三个方面来考量，一方面所测试的项目之间是否很大的差异性（如C/S 系统和B/S 系统的差异）；所选择的测试工具是否适应这种差异；最后，测试人员是否有能力开发出适应这种差异的自动化测试框架。

楼主意见很不错，分析很实际。不过你所理解的自动化稍微有点狭隘了，你谈的自动化，仅仅指的是项目提测后的回归测试。其实你看过我之前的自动化分层测试图就知道，其实我们的自动化是有很多个过程的，比如： 1.项目最先开发人员做的单元测试，这个完全是用代码编写的，这个毫无疑问是自动化测试。 2.接下来的接口实现层的接口测试，这个层面属于白盒测试和单元测试十分类似，也是完全需要编写代码的，本来这个层面是测试人员负责测试的，但是目前国内大多是开发人员在做这一块，而且有的也把他叫做单元测试，实际这个是接口测试，当然一些大公司是把这个列入接口测试的。 3.接口封装层的接口测试，就是把接口已经封装成url等形式，但是没有界面，然后提测给测试人员，这个是大家平常做的最多的接口测试类型。这个层面已经是黑盒测试了，看不到代码实现逻辑了。而且从这一层开始就可以进行手工测试了。说到这一层就不能不提到性能测试，因为性能测试大部分是从这一层开始的，性能测试是依赖工具分析且需要编码的测试，如果除开结果分析阶段就是自动化测试，所以性能测试可以说是半自动化测试。 4.再往后就是ui层了，也就是楼主关注的那一层的自动化了。如果在这一层之前的自动化覆盖率很高的话，这一层的bug是会非常少了，因为业务逻辑的bug基本都在接口层检查过了，这一层的bug一般是由于模块集成，界面美观等原因造成的。综上所述：自动化测试其实是能更早介入测试，更高效的测试，更好的保证产品质量的一种测试方法。而不是我们单纯理解的ui自动化。

什么样的项目适合自动化测试

2，自动化测试的意义是什么

实施自动测试的目标和意义1）对于功能已经完整和成熟的软件，每发布一个新的版本，其中大部分功能和界面都和上一个版本相似或完全相同，这部分功能特别适合于自动化测试，从而可以让测试达到测试每个特征的目的。2）每日测试的高效率。DCC版本的发布周期往往比较短，也就是开发周期只有短短的几个月，而在测试期间是每天/每2天都要发布一个版本供测试人员测试，一个系统的功能点有几千个上万个，人工测试是非常的耗时和繁琐，这样必然会使测试效率低下。3）具有一致性和可重复性。由于每次自动化测试运行的脚本是相同的, 所以每次执行的测试具有一致性, 人是很难做到的. 由于自动化测试的一致性，很容易发现被测软件的任何改变。4）更好的利用资源－－周未/晚上。理想的自动化测试能够按计划完全自动的运行, 在开发人员和测试人员不可能实行三班倒的情况下, 自动化测试可以胜任这个任务, 完全可以在周末和晚上执行测试. 这样充分的利用了公司的资源,也避免了开发和测试之间的等待。5）解决测试与开发之间的矛盾。通常在开发的末期,进入集成测试阶段, 由于每发布一个版本的初期,测试系统的错误比较少,这时开发人员有等待测试人员测试出错误的时间. 事实上在叠代周期很短的开发模式中，存在更多的矛盾，但自动化测试可以解决其中的主要矛盾。6）将烦琐的任务转化为自动化测试。大量重复的测试是非常繁琐的，并且需要消耗大量的人力才能够完成。自动测试能够很好的解决这个问题，不需要繁琐的劳动，不需要大量的人员。7）增加软件信任度。只有经过大量测试案例测试过的版本才是可靠的，而只有使用自动测试才能够保证在段时间内完成大量的测试案例。

一般是指软件测试的自动化，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常软件自动化测试自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。条件和异常条件。自动化测试与软件开发过程从本质上来讲是一样的，无非是利用自动化测试工具（相当于软件开发工具），经过对测试需求的分析（软件过程中的需求分析），设计出自动化测试用例（软件过程中的需求规格），从而搭建自动化测试的框架（软件过程中的概要设计），设计与编写自动化脚本（详细设计与编码），测试脚本的正确性，从而完成该套测试脚本（即主要功能为测试的应用软件）。　　1) 自动化测试需求分析。　　当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动化测试时，我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据，并形成详细的文档，以便于自动化测试框架的建立。　　2) 自动化测试框架的搭建。　　所谓自动化测试框架便是像软件架构一般，定义了在使用该套脚本时需要调用哪些文件、结构，调用的过程，以及文件结构如何划分。　　而根据自动化测试用例，我们很容易能够定位出自动化测试框架的典型要素：　　a. 公用的对象。　　不同的测试用例会有一些相同的对象被重复使用，比如窗口、按钮、页面等。这些公用的对象可被抽取出来，在编写脚本时随时调用。当这些对象的属性因为需求的变更而改变时，只需要修改该对象属性即可，而无需修改所有相关的测试脚本。　　b. 公用的环境。　　各测试用例也会用到相同的测试环境，将该测试环境独立封装，在各个测试用例中灵活调用，也能增强脚本的可维护性。　　c. 公用的方法。　　当测试工具没有需要的方法时，而该方法又会被经常使用，我们便需要自己编写该方法，以方便脚本的调用。　　d. 测试数据。　　也许一个测试用例需要执行很多个测试数据，我们便可将测试数据放在一个独立的文件中，由测试脚本执行到该用例时读取数据文件，从而达到数据覆盖的目的。　　在该框架中需要将这些典型要素考虑进去，在测试用例中抽取出公用的元素放入已定义的文件，设定好调用的过程。

自动化测试的意义是什么

3，软件自动化测试的意思是什么具体价值体现在什么方面能做些什么

恩，现在很流行的，但是大部分都是跟风而已，工作中有迷茫是好事，说明你在思考，不妨就那么放着，做好眼前的事，随着工作的深入，会找到适合自己的结论。首先，什么适合做自动化测试1. 重复性高的测试用例，比如版本更新很快，基本功能验证的用例，回归测试等2. 人力不可达或者极其费力的，比如10000次注册，点击，等自动化测试的方法论1.测试自动化类似于软件开发的过程录制/回放脚本的开发方式是不可能应付所有自动化测试的需求的，因此，需要测试人员掌握必要的开发知识和编码知识。2.测试自动化是一个长期的过程首先，不能期望自动化测试在短期内找到很多Bug，自动化测试只有在长期的多次运行后磁能体现它的价值。其次，不要认为只要购买了工具，录制一些脚本，然后就可以安枕无忧的看着自动化测试实现想要的效果，需要考虑自动化测试脚本维护成本，随着被测试应用程序功能的增加和修改，测试脚本的维护工具量会急剧的增加。3.确保测试自动化的资源，包括人员和技能最好有专门的自动化测试工程师来保证测试自动化持续，顺利的进行下去，自动化测试工程师需要对项目测试自动化负责，设计测试框架和脚本结构，解决各种测试脚本的开发问题，确保自动化测试得以计划，设计和有序的开发，维护。4.循序渐进的开展自动化测试不要一开始就把自动化设想的很大，这往往是不可实现的，应该从小开始，先熟悉工具和自动化测试的基本技能，然后，整合资源开始实现一些基本的自动化测试用例，例如：冒烟测试类型的自动化测试脚本，先实现那些容易实现的，且相对稳定的功能模块的自动化测试，然后再考虑逐步扩展和补充其他相对难实现，或者是比较不稳定的功能模块。5.确保测试过程的成熟度如果软件企业的测试过程和项目管理过程的能力成熟度比较低，则实现自动化测试的成功率也比较低，在开展自动化测试之前，先考察一下软件企业各方面的管理能力，；例如：测试是否独立进行？有无配置管理？进度控制能力如何？如果各方面的能力成熟度都比较差的话，则不要盲目的引入测试自动化。自动化的目标：自动化测试应该是这样的：自动化应该是一种Service（Automation As A Service)，所有的测试人员和开发人员都应该可以自己很方便的去跑自动化自动化测试的运行结果应该是可以自动分析的，占用很少的时间自动化测试的成功率应该是要很高的（比如95%以上）自动化应该是写一次，运行很多次

软件测试是对创造力和智力非常有挑战性的任务。测试一个大型软件需要的智能要超过设计这个程序的智能。软件在它发行之前应当通过彻底的测试，以保证它的可靠性和功能性，不幸的是，测试工程师要覆盖一个大型程序的所有情况会感到太麻烦和太费时。确实，软件的每个部分如能被分别测试到，同时一些指定的路径也能被测试，这对总的软件质量的保障是非常有效的。一般的说，没有测试覆盖分析工具，软件在发行前仅有50%的源程序被测试过。在差不多有一半源代码没有被测试的情况下，大量的故障（bug）随软件一道被发行出去。在这种情况下，软件的质量、性能和功能不可能得到保障。此外，什么时候测试结束？或是否要对该程序作进一步的测试？对于测试工程师和测试管理人员来说是不知道的，通过引进测试覆盖的概念，问题就可以得到解决。项目测试管理1。帮助软件管理者准确地测算开发组的效率的，通过提供多层分析,包括系统/文件/类/函数的能力。2。提供管理人员测算工程开发进度与质量分析的能力，允许在被生成的类继承图和函数调用图上，直接反显所有在规定的日期或一个小组/单个员工完成的模块，在这些图上带有覆盖在每个类/函数框上以条形图方式显示的相关质量信息，比如大小、复杂性、数据性能、代码测试覆盖等。3。结合软件系统质量分析能力和系统开发管理能力，提供给管理人员的带有质量数据的有关开发效率和工程开发进度信息总是即时的和精确的，因为它们是直接从源代码得来的第一软件测试是对创造力和智力非常有挑战性的任务。测试一个大型软件需要的智能要超过设计这个程序的智能。软件在它发行之前应当通过彻底的测试，以保证它的可靠性和功能性，不幸的是，测试工程师要覆盖一个大型程序的所有情况会感到太麻烦和太费时。确实，软件的每个部分如能被分别测试到，同时一些指定的路径也能被测试，这对总的软件质量的保障是非常有效的。一般的说，没有测试覆盖分析工具，软件在发行前仅有50%的源程序被测试过。在差不多有一半源代码没有被测试的情况下，大量的故障（bug）随软件一道被发行出去。在这种情况下，软件的质量、性能和功能不可能得到保障。此外，什么时候测试结束？或是否要对该程序作进一步的测试？对于测试工程师和测试管理人员来说是不知道的，通过引进测试覆盖的概念，问题就可以得到解决。项目测试管理1。帮助软件管理者准确地测算开发组的效率的，通过提供多层分析,包括系统/文件/类/函数的能力。2。提供管理人员测算工程开发进度与质量分析的能力，允许在被生成的类继承图和函数调用图上，直接反显所有在规定的日期或一个小组/单个员工完成的模块，在这些图上带有覆盖在每个类/函数框上以条形图方式显示的相关质量信息，比如大小、复杂性、数据性能、代码测试覆盖等。3。结合软件系统质量分析能力和系统开发管理能力，提供给管理人员的带有质量数据的有关开发效率和工程开发进度信息总是即时的和精确的，因为它们是直接从源代码得来的第一手信息。测试计划软件系统不仅变得越来越庞大，但是也变得越来越复杂。复杂的代码是很难阅读、理解和修改的；必须化更多的精力去测试、维护和再测试。测试复杂性分析能帮助软件工程师容易并精确地去计划他们的测试活动。提供系统级复杂性分析和过程级复杂性分析去精确地测量复杂性，帮助工程师更好地计划他们的测试活动。帮助工程师更好估计和使用测试复杂性度量，为满足不同层次的测试覆盖的要求，必需提供：块测试复杂性、分支测试复杂性、段测试复杂性、条件-判定测试复杂性、条件-段测试复杂性。

软件自动化测试的意思是什么具体价值体现在什么方面能做些什么