不同类型数据库的死锁问题

Question

所谓死锁<DeadLock>: 是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程. 由于资源占用是互斥的，当某个进程提出申请资源后，使得有关进程在无外力协助下，永远分配不到必需的资源而无法继续运行，这就产生了一种特殊现象死锁。 一种情形，此时执行程序中两个或多个线程发生永久堵塞（等待），每个线程都在等待被其他线程占用并堵塞了的资源。例如，如果线程A锁住了记录1并等待记录2，而线程B锁住了记录2并等待记录1，这样两个线程就发生了死锁现象。 计算机系统中,如果系统的资源分配策略不当，更常见的可能是程序员写的程序有错误等，则会导致进程因竞争资源不当而产生死锁的现象。 产生死锁的原因主要是： 
（1） 因为系统资源不足。 
（2） 进程运行推进的顺序不合适。 
（3） 资源分配不当等。 
如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则 
就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。 产生死锁的四个必要条件： 
（1） 互斥条件：一个资源每次只能被一个进程使用。 
（2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。 
（3） 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。 
（4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。 
这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之 
一不满足，就不会发生死锁。 死锁的解除与预防： 
理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和 
解除死锁。所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确 
定资源的合理分配算法，避免进程永久占据系统资源。此外，也要防止进程在处于等待状态 
的情况下占用资源,在系统运行过程中，对进程发出的每一个系统能够满足的资源申请进行动态检查，并根据检查结果决定是否分配资源，若分配后系统可能发生死锁，则不予分配，否则予以分配 。因此，对资源的分配要给予合理的规划。

Answer 1

这条用例是后来王建建议加进来的，当时并没有理解的太深入，所以这个用例划分的不够细致，遗漏了部分检查点。单播和组播中继时一类检查点，节目单、点播、直播是一类检查点，而我的用例中时吧单播、组播中继、节目单写在了同一个用例里，在进行测试此用例的过程中，当时只考虑单播和组播RRS拼装是否正确，忽视了节目单的RRS地址的拼装这个检查点，由于自己对单播、组播的认识很少，所以这个用例需要开发人员一起完成，当时是开发人员刘华和我一起完成的这条用例，所以这条用例测完之后心里也是很不踏实，就把当时的日志拷贝下来了，一旦以后出现什么问题比较容易定位，

Answer 2

日志分析过程：
a、 RRS的地址拼装是否有误，由于机顶盒连的时默认分组中的epg，RRS地址的拼装是通过轮偱的方式来完成的，通过观察日志，RRS的地址拼装是正确的。
b、 单播和组播的RRS地址的拼装是否正确，绿色字体的日志时组播RRS地址的拼装结果，根据开发提供的信息判断单播和组播RRS地址的拼装也是正确的。
观察上面数据完成后，我们都误认为这个用例通过了，其实我们都忽视了节目单RRS地址的拼装（因为需求在我们头脑中印象太深刻了，脑子里只有直播和点播），其实，如果当时我们能够足够重视节目单，我们就不会漏测了这个问题，因为在RRS地址正确拼装的下一行就是节目单的RRS地址拼装的地址：
   {PositionY=0, IsHDChannel=2, ChannelLocked=0, Interval=0, ChannelPurchased=1, Lasting=0, ChannelSDP=, UserChannelID=5, TimeShift=1, ChannelName=大自然, PreviewEnable=1, ChannelLogURL=http://10.168.69.142:8181/EPG/jsp/../../images/universal/film/logo/111.jpg, BeginTime=0, ActionType=1, ChannelURL=, ChannelID=73, TimeShiftURL=, TimeShiftLength=0, ChannelType=1, PositionX=0}
 由以上日志我们可知：节目单拼装的RRS地址为空，也就是系统没有给节目单拼装RRS地址。

Answer 3

三、总结分析
这次问题的出现本来完全可以避免的，从这个问题可以看出，测试人员开始测试版本之前一定要对自己负责的模块有非常的了解，在对业务和实现不是完全了解的情况下就草率进行测试，必然会导致问题的漏测。针对该问题，个人觉得测试人员在分析需求分析的时候应该注意以下几点：
1、 story要实现的主要功能。
2、 点引出面。看到需求中的一个点时，能够尽可能的扩展我们的思维，考虑到问题的全全面面（如：这次需求中只提到了点播和直播频道的RRS地址拼装,点播和直播都是播放内容，我们这时就应该想到所有的播放内容的情况，如节目单的播放、书签中的播放、收藏夹的播放等等）。
3、 细化用例。在上面的用例中，单播和组播中继是一个检查点，节目单时一个检查点，一个用例中的检查点太多有可能会遗漏部分检查点，所以，我们需要把该用例的检查点细化开来，这样可以更好的避免漏测的发生。
4、 通过多种途径了解到影响该功能模块所有外界因素。 
5、 及时的与开发沟通，获取更多的信息。
当然，编写测试测试用例时不要仅仅局限在需求中提到的内容，在测试过程中我们需要主动思考和发散思维，慢慢形成点到面的思维模式，在以后的工作和学习中，我会更加努力，尽量避免漏测的发生，这也是作为一个合格的测试人员对自己最基本的要求。