结果

　　从稳定性的测试目的中可以得出在对稳定性结果的判断需要从以下几个方面进行：

　　1、判断是否崩溃

　　a）对于能够被崩溃上报进程捕获的的崩溃比较好办，可以通过判断是否有崩溃上报进程来进行判断。

　　b）在测试机上安装任意的debugger工具（例如windbg）就可以检测各种类型的崩溃情况（只要有崩溃就会触发debugger的调用，检测是否出现debugger进程就ok）

　　c）对于那种运行在宿主程序中的插件，单独插件的崩溃有时不会导致宿主程序的整个崩溃，所以对插件崩溃的检测需要记录运行正常时的pid或tid，发现其消失就判断为崩溃，因为插件运行在宿主程序中不是一个进程就是一个线程。

　　2、判断是否假死

　　a）对于单进程程序，只要主窗口发消息即可，找对主窗口是关键，通过枚举某个进程的全部窗口句柄，找parent为null，visible 为true，不是托盘程序的那个窗口句柄。

　　b）强制主窗口重绘（这个重绘方式各产品可能不一样，有的发消息就可以，有的需要移动位置），然后截图，白色的就是假死（判断白色的已有现成的代码）

　　3、判断是否存在性能劣化的趋势

　　a）这点也属于性能测试中资源占用情况的测试，可以再稳定性测试的同时使用性能检测工具进行检测。

　　待改进点

　　1、自动化判断，定位异常信息。目前一些偶现的卡死和崩溃无法捕获到堆栈信息，对定位意义的不大，需要在崩溃或卡死时保留住现场，不能连续的执行后续的case。

　　2、操作步骤及数据选取的随机性。可以考虑引入Fuzzy以及解析用户日志的方式增加操作步骤及测试数据选取的随机性。

　　3、测试case在各个执行环境中循环切换的自动化。目前这种循环还是靠手工保证，后续可以考虑从在每台测试机器上动态调用测试脚本，代替手工的切换及运行。

　　4、测试脚本的稳定性：稳定性的测试不仅是对被测程序稳定性的验证，同时也考验我们自动化测试脚本运行的是否稳定，而且在长时间的运行过程中可能会出现各种阻碍脚本运行的但却是正常的情况，所以需要增加各种判断和轮询的机制，另外为了保证场景的多样性都需要我们的脚本更加通用和周密，一不小心，被测程序还没挂呢，我们自己先停了……对于脚本的稳定性一直在测试的过程中不断完善，积累经验。