浅谈并发性模型的测试策略

标签：并且   修改   导致   text   取数据   状态   故障   不同的   自用   

目前市面上的不少软件都会用到多方登录或者编辑的并发性问题，针对并发性问题有若干种方法，主要有以下几种：

• 保守方式：这种并发性模型在数据上加了锁。如果一个用户已经打开了一条记录，那么在允许编辑的环境中，系统就会拒绝来自其他用户的读取数据请求。适用于出现一个以上用户同时编辑相同数据的情况。（缺点：当一个用户已经打开某个数据时，其他用户就不能访问它了，这样导致了系统在使用上有些不方便。由于系统需要管理这些记录锁，所以模型在实现上也会有一定的复杂度。）
• 开放方式：总是允许用户读取数据，甚至还可能允许更新数据。但是用户试图保存数据时，系统会检查自从这个用户检索数据以后是否有其他人更新过数据。如果有，那么更新就失败了。适用于不太可能出现多人同时修改同一数据的情况。（缺点：使用不便，用户花费了大量时间来更新一条数据却发现根本不能保存。此时必须要重新检索记录并重新完成修改。）
• 没有并发保护：胜利属于最后一个用户。这种方法并不对多个用户编辑湘潭的数据提供保护。（缺点：第一个用户的修改结果将会丢失，此外，当两个用户试图同时保存数据时，这种方法可能会导致数据损坏。）

对于不同的并发性模型，测试过程中应该关注的要点：

• 保守方式：主要关心的是验证能否正确地取得、释放加在记录上的锁，并且能正确处理应用程序中所有可能更新这条记录的部分。这里主要关心的是以下三个方面：

           1)  锁的获得。关键是系统必须把锁正确地分配给第一个请求的用户。获得锁的操作是可以测试的：让两个用户试图同时进入编辑状态，或者使用脚本来产生比如1000个或者更多的编辑数据请求，这些请求是几乎同时的，以此来验证只有一个请求获得成功。

           2)  锁的效用。如果一个用户获得了锁，那么系统必须保证其他任何用户不能用任何方法修改这个数据，其中包括对数据的更新和删除。具体的验证方法是：让一个用户打开一条记录（进入编辑模式并且保持这个状态），同时其他用户在应用程序的所有地方试图编辑、删除或者以其他方式更新数据。系统应该拒绝所有其他用户更新数据的企图。

           3)  锁的释放。测试人员必须验证：当编辑数据的用户释放了这条记录以后（无论是更新完毕还是取消操作），系统能够成功地让其他用户使用这条记录。释放锁需要注意的一个重要方面是错误处理，也就是持有锁的用户遇到错误（如客户端系统崩溃了）的情况下，系统应该完成什么样的操作。锁是否就失去了控制（处于无法释放的状态）？系统从释放锁的故障中重新恢复的能力需要重点考虑。

• 开放方式。更新是唯一需要关注的要点。测试开放的并发性的最佳方式是综合使用手动和自动测试技术。

          1)  在手动的方法中，两个测试人员编辑数据，然后试图同时保存数据。第一个用户更新操作应该是成功的，但是第二个用户应该得到一条消息，其内容是另一个人已经更新了数据，此时，他需要重新装载数据并且重新完成修改操作。

          2)  除了手动测试以外，还应该使用自动和海量的测试方法。为了保证开放的加锁机制能够使得同一时刻只有一个用户更新了记录，我们可以利用脚本发起成百上千的、几乎同时发生的更新请求进行测试。其余的用户都应该收到错误消息，消息内容类似于：因为另一个用户已经更新了记录，所以记录不能保存。

          3) 与保守并发模型一样，测试人员必须保证对所有可能修改数据的地方，开放的并发性得到验证。其中包括来自用户界面的不同部分的记录操作。

• 没有并发控制。最简单的也是最容易出错的方法是系统不具备任何并发性控制。测试这样的系统和测试开放的并发模型非常相似，区别只是：无论更新请求的顺序如何，所有用户都应该成功完成更新操作。在这里也应该综合使用手动和自动测试技术，但是在没有并发控制的情况下，应该关注的是数据的完整性。测试人员还应该验证是否正确地处理了更新错误，例如：当一个用户试图更新某条记录时，它却被删除了。

浅谈并发性模型的测试策略

标签：并且   修改   导致   text   取数据   状态   故障   不同的   自用   

原文地址：https://www.cnblogs.com/CarolSpace/p/9753635.html