软件测试的初始步骤就是在理解被测试的系统和功能的基础上，用一定的模型结构来描述被测试系统的功能和质量属性，然后根据测试模型获取要覆盖的测试覆盖项。
在获取明确具体的测试覆盖项之后，可设计测试步骤来完成测试用例的设计。在实践中，这样的模型通常被称为测试模型。
对于在项目中引入和应用基于模型的测试，应考虑包括测试策略的选择，考虑基于模型的测试范围，测试工具的选取（或自行开发），建模流程的规定，建模质量的度量，基于模型的测试工具，与自动化测试执行系统集成的方法。
1.测试设计的自动化能改善工作效率和人为的失误
2.尽早建立测试模型能够改善沟通，提前发现需求中的缺陷；
3.使得不了解测试技术的业务人员也能够实施测试设计
4.提高测试覆盖从而有效改进软件产品的质量
5.缩短测试设计的周期，加速测试活动
1.建模需要一定的成本投入
2.从模型生成测试用例可以数量太多，产生测试用例的爆炸
3.模型也可能会描述错误，因为模型是人建立的，包含人为错误也在常理之中。
4.模型的抽象可能带来理解上的困难，所有的模型都有一定程度的抽象，当抽象的逻辑原则未达成共识，可能导致评审者无法理解测试模型。
1.随机遍历用户界面
2.优势信息评估
3.基于进化算法的测试集生成（选择交叉变异）
4.测试执行
先通过随机遍历用户界面生成一组随机的测试用例集
对每个随机测试用例进行优势评估。
在测试用例生成的过程中，遗传或进化算法从一组候选的个体测试用例集开始，然后利用三种不同的搜索操作（一般为选择交叉和变异）生成下一组更优的测试用例集。
选择操作是从每一轮生成的测试用例集中选择更优的个体测试用例进行重组；
交叉操作是将两个独立的个体测试用例产生进行交叉重组，从而共享部分来源于父辈测试用例的优势信息；
变异操作是指对一部分的个体测试用例进行随机修改，并注入额外的信息；
基于探索的我测试当中通过不断的迭代上述三个搜索操作，对给定的一组测试用例集进行优化，在优化的过程中不断的执行测试用例并检测是否有软件缺陷的发生。
优势在于把测试用例生成问题转化为了在特定软件对象的输入域搜索更优的问题，在传统的软件测试过程当中，此类技术已经在软件代码覆盖率和差错能力方面取得了很好的效果，在移动应用领域的测试环境下，基于检索的测试技术主要在于变异操作可能产生大量的输入事件序列无效的测试用例。
基于搜索的测试技术的工具实现：Sapenz。
优点就是语法简单，更适合初学的编程者；
开发效率高，有非常强大的第三方开发库；
具有可移植性；语言扩展性好；
具有可嵌入性；
执行效率不够快，线程不能利用多CPU；
纯面向对象的编程语言
跨平台执行具有很好的移植性
提供了很多内置的类库
提供了对很多Web应用开发的支持
具有良好的安全性和健壮性
解释性语言运行效率极低，
不支持底层操作
主要用于云计算和服务设计
丰富的标准库
简单易学
可以直接编译成机器码，不依赖其他库
支持语言级别的并发性
跨平台编译，编译速度快
缺少框架
错误处理不够好
软件包管理不够完善
基于python，是一个可扩展的基于关键字的自动化测试执行框架，提供了一套特定的语法，并且有非常丰富的测试库；
是一款应用于Web应用程序测试的工具，支持多平台，多浏览器，多语言去实现自动化测试；
是一个CS结构的开源的自动化测试框架，支持iOS平台和安卓平台上的原生应用，Web应用和混合应用
Quick Test Professional的简称，是一种企业级的自动化测试工具，提供了强大易用的测试录制回放功能。
此过程需要明确化测试范围，测试目的，测试内容，测试方法，测试进度要求，并确保测试所需的人力，硬件，数据等资源都准备充分。
将软件的需求转化为测试需求的过程。是建立在测试计划中的测试内容的基础之上，进行细化明确测试点。
自动化测试用例是针对自动化测试框架，应用脚本技术进行用例解析。
一个脚本是一个完整的场景；
一个脚本只用来验证一个功能点；
自动化测试的设计原则
重点测试功能当中的正向逻辑；避免在自动化测试当中涉及大量的异常逻辑的测试，因为自动化测试脚本对异常的逻辑可能引起的系统错误响应的容错性是有限的。
测试用例对应测试脚本应尽可能的互相独立，也就是说测试脚本之间不发生相互的依赖，或者不发生相互的影响。
自动化测试脚本是自动化系统的一个部分，其开发同样应该贯彻软件工程的高内聚和低耦合的结构化设计理念。
在整个脚本中，只对验证点进行验证，不是每一个步骤都需要验证点，不对整个脚本的每一步都做验证。
自动化测试人员在用例设计工作开展的同时即可着手搭建测试环境。
因为自动化测试的脚本编写需要录制页面控件，添加对象，测试环境的搭建包括了被测系统的部署，测试硬件的调用，测试工具的安装与设置，网络环境的布置等。
自动化测试框架的典型要素
公用的对象
公用的环境
公用的方法
测试数据
是具体的测试用例的脚本转化。基本包括了四个部分的内容：准备，执行，断言和清理。
准备：创建实例创建模拟对象等
执行：编写执行测试所需要的方法，传入要测试的参数
断言：就是检查结果对和不对，实际结果与预测结果一致，那么就通过；不一致则用例不通过；
清理：对数据进行清理，关闭进程，清理变量和对象等，这样不影响下一次测试。
三个部分的验证
一个完整的自动化测试通常包含三个部分的验证：验证功能是否正确，验证异常和错误的处理；覆盖边界条件。
脚本调试结束后，便可以在检验模式下测试被测软件。
自动化测试脚本，根据类型不同，有以下几种分类：
他就是简单地录制回放，它的优点是开发成本低，对测试人员的素质要求也低。
缺点：脚本的健壮性不高，脚本不能共享和重用也利于维护。
使用判断循环分支等测试条件，控制测试脚本的执行过程。
优点：可以像函数一样，给其他模块脚本调用或者使用；提高了脚本的可通用性和灵活性，使得代码易于维护；维护成本相比较线性脚本来说要来的低，同时测试也可以更加的灵活。
数据与测试脚本相互分离，单独存在于数据文件，或者数据库当中。
优点：测试脚本只包含测试逻辑，不包含测试数据，修改测试数据无需关联修改测试脚本。
缺点：自动化测试设计工作量会加大，对测试人员的编程要求更高
实际上是较复杂的数据驱动脚本的一个扩展，关键字驱动脚本将数据文件改变为测试事例的描述，用一系列的关键字指定要执行的任务。
优点：数据与脚本分离，脚本维护的成本低，综合了结构化，共享，数据驱动等脚本的优点。
缺点：自动化测试设计工作量会加大，依赖于测试工具，对关键字驱动的支持情况。
将系统中基础的公共的功能的测试脚本给独立出来，以便在其他脚本之间共享使用
优点：可以减少脚本开发的工作量，做到脚本的复用，实现脚本维护成本的低廉。
缺点：需要更多的自动化测试工作量，需要建立额外的框架或者测试支持库；测试人员需要更多的编程技能来维护测试支持库。
每次测试结束的时候，测试工具都会把测试结果显示在测试，结果报告当中；测试结果报告会详细的描述，在测试过程执行当中发生的主要事件，如检查点，主要信息和错误信息，用户信息。
测试出现的缺陷要记录到缺陷管理工具当中，以便定期的跟踪和处理，开发人员修复之后要对问题进行回归测试，就是重复执行一次该问题对应的脚本。
持续集成就是持续的将代码集成到主干上。持续集成强调开发人员在提交了新代码之后，立刻进行构建和单元测试；根据测试结果，可以确定新代码和原有代码能够正确的集成在一起。
好处：它可以快速地发现错误，防止分支大幅偏离主干。
目的：就是可以让产品进行快速的迭代，同时还可以保持高的质量。它的核心措施是代码集成到主干之前，必须通过自动化测试，只要有一个测试用例失败，就不能集成。
一个完整的持续集成必须包括的内容有：一个自动构建过程，包括自动编译，分发，部署和测试等。