序言：2013年从家回来，就好像没写过日志了，一是忙着部门整体自动化计划，二是忙着JAVA性能，三是忙着公司的持续集成建设，其实最主要的是人懒了，写东西的动力来源于认可，我一直认为，理论太虚，而自己之前写的也确实让人看得虚了点，有点雾里看花的感觉，所以尽量多以实践分析和总结为主，不管如何，再简单，自己能做着自己所认可的事情就算开心了，就算是写给自己看的吧，等到以后有一天，看着自己这些东西，也许自己也会为之小小感动一下。

　　一、并发编程分析思考

　　一般的并发编程问题包括：死锁、并发错误、系统资源不足、线程泄露（工作线程抛出异常而未处理以及线程被阻塞而等待不到数据）、任务过载

　　场景1：

　　需求场景：以前的工具也用过并发编程，其实就是多个线程同时开启，但是最近，开发一个客户级工具的需求让我开始真正认识到并发编程的难度，需求是选择EXCEL表，导入数量能达到1000个的网元，然后同时开始运行过程，每次运行队列为10个，其余的网元处于等待，每完成一个，则将其等待的置为运行（类似于迅雷下载）。每一个网元有各自的结果数据库文件，但是每个网元都会同时访问一个工程数据库文件。

　　设计方法：直接引入线程池进行管理，指定工作队列以及工作队列中保存的队列数量、线程池中维护线程的核心数量以及最大数量，先统一将所有运行线程加入到线程池中，然后开启

　　问题和分析：当1000个队列开始运行后，会发现10个运行线程，一段时间后，会最终只剩下一个线程在运行，其余的9个线程都down掉，后来利用jvisualvm对程序的线程进行跟踪，原来是由于10个线程的同步机制问题，因为会同时访问一个工程数据库文件，虽然中途用了单例模式，只有一个对象，但是几个线程同时调用对象，读写数据库时，会造成Lock异常，然后由于程序中没有对Lock异常进行处理，则会造成线程中断，最后只会自相残杀到最后一个，这就是线程泄露所造成的，所以要注意资源同步和程序异常的处理。

　　场景2：

　　需求场景：之前对公司软件的测试引入SNMP性能测试，开发的工具可以模拟网元，利用大量模拟网元构建背景数据，然后引入小部分的真实网元进行操作，从而达到性能测试的目的。

　　问题和分析：由于大数据下的测试，软件的很多问题暴露了出来，主要是大量数据的同步，即同时收发、然后读写数据库造成。主要的问题类型包括：线程挂起不释放（这是由于死锁、大量阻塞线程造成）、数据库自动关闭（数据库参数读写频率上调后，数据库读写过快造成）、客户端卡死（model反应到view层的数据结构问题）、服务器异常退出（内存泄露造成）、cpu过高等，而这些问题是在之前的功能测试活动中并没有发现的，所以测试并发程序，所面临的挑战是潜在错误具有很大的不确定性和随机性，需要更广泛的覆盖度、更庞大的数据量以及更长的运行时间，这就引申了性能测试和系统监控。

　　二、并发编程的测试总结

　　由于并发测试主要是为了发现隐藏的不确定性，因此，我个人总结的一些前期简单策略，可以分为序列测试、人工干预测试以及随机干预测试（欢迎拍砖讨论）

　　1、序列测试，即基于某些指标，以相同的输入或者步骤重复执行被测程序，并潜在错误会在某次执行中出现；例如，我们对网管的不断同步，即希望能够在合理的大数据背景下，自动反复执行一个并发通信和数据的读写工作，将隐藏的并发问题暴露在监控系统下。并且错误之后，能够保留现场。

　　2、人工干预测试，通过人为干预程序的执行，即在某个序列机制下，同时进行一些人工干预的步骤，例如：在大量网元同步的基础上，进行一些对真实设备的操作，例如：告警查看、配置操作等。

　　3、随机干预测试，即引入自动化手段，在序列测试的操作上，随机从测试案例中，输入一些自动操作，并监控。

　　总结：因为写的突然，也许不够深刻，但突然发现，一直编程下去，总有一天要应用到并发编程这样的技术，一直自动化测试下去，总会走上性能的道路，从上层走向底层，再从底层走向应用分析，所以，刚开始我们不用预料，只要朝一个方向屁颠屁颠走下去，终都会遇到啊。

版权声明：本文出自 散步的SUN 的51Testing软件测试博客：http://www.51testing.com/?382641

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。