自动化测试大概可以分为 单元划分->程序改造->建立测试框架->测试用例执行管理->测试用例自动生成。
其中
单元划分-将给出的测试代码根据函数划分为不同的子单元以方便测试
可以分为 1.自动单元划分
2.人工干预
tip： 自动化单元划分中会把每个函数都划分为一个单元,而人工干预则可以将某几个关联较为密切的函数划分在同一个单元之中,这样可以有效减少打桩的工作量,比自动划分更有效率.
程序改造-为了使测试代码可以跑起来需要对源测试代码在不损害其源代码逻辑基础上进行改造
主要包括 1.重命名main()函数 这个很好理解，如果测试函数中已经有main函数了的话，就需要将其重命名。
2.代码补齐 这个主要是指对于已经声明但是没有定义的变量或者函数的补充，对于前者添加定义，对于后者，打桩啊打桩。
3.插入友元 -----------------目前并不理解。
建立测试框架-获取程序运行实时信息从而方便测试人员掌握测试进度
包括 1.插装 为了捕获程序的实时运行状态以及程序的运行轨迹，可以使用探针函数来捕获
2.打桩模块 主要进行对只声明而未定义的函数和变量的补齐工作.包括 1.仅声明未定义函数(被打桩函数)的查找和编号. 2.被打桩函数的函数名称替换.3.被打桩函数的补完(桩代码生成)
测试用例执行管理-在最后一步测试用例生成时，对各种用例进行管理，排除重复的测试用例，最终得到完善的用例。
包括 1.测试运行监控 检查有无死循环和程序抛出的异常
2.测试用例函数，也可以称为用例文件，将测试用例写成一个函数的形式，将原来的被测试函数封装在里面。
3.驱动文件，调用一个 被测试函数 所产生的所有测试用例函数的文件
4.测试用例库 管理并保存所有有效且不重复的测试用例，通常用xml的形式保存。
测试用例自动生成-测试的核心内容。将自动产生测试用例，通过一定的算法进行筛选，并从中得出最终的测试用例。
包括 1.随即用例生成 思想比较简单，就是先给每个变量在其定义域范围内随机化产生一组随机值，然后每次都随即抽取一些值对程序进行测试，当覆盖率增加的时候就将该组测试用例添加到用例库反之舍弃，结束条件是覆盖率连续N次不增加或者覆盖率达到要求。
2.基于路径的测试用例生成
理解不透彻，现在理解是，将整个程序的流程可以看做(到时候要蛋疼的代码化哟亲)一颗树。根据探针函数可探知用例是否跑到了这棵树的新树杈(- -!意会意会)，用例添加到测试用例库的条件是 这条路径是可达路径且该路径没有走过。(尚不清楚这样做覆盖率会不会增加)
3.基于约束求解的测试用例生成 -没看
最后，对一些之前不知道的术语做一个注释，免得以后忘记了。
MC/DC覆盖测试：MC/DC(修订的条件/判定覆盖)(Modified Condition Decision Coverage)准则是一种实用的软件结构覆盖率测试准则。
定义: 在每个判定中的每个条件都曾独立的影响判定的结果至少一次, (独立影响意思是在其他的条件不变的情况下,改变一个条件);
打桩：打桩也叫存根，举个具体的例子说明：如测试function()函数时，function()中调用了函数test(),但是在测试function()的时候test()函数可能还没有写出来，这时可以写一个test()的存根(stub)函数,来模拟test()函数,让它仅仅返回一个值.这样的话就可以完成对函数function()的测试了
插装：在系统源程序的特定位置中插入探针函数，通过运行插装后的可执行文件以获取动态数据
驱动函数：驱动函数是驱动模块的重要组成部分，它的主要功能是在针对被测函数生成测试用例用后，接受该测试用例作为输入，提取测试用例中全局变量和函数参数，生成驱动函数。