在软件应用当中，处理并发性问题主要有3种方法：
（1）保守方式
这种并发性模型中数据上加了锁（如此一来会有很多的锁）。如果一个用户已经打开了一个数据，那么这允许编辑的环境中，系统会拒绝来自其他用户的读取数据的请求。此方法很安全，但不方便，导致后来的用户不能对数据
进行访问。由于系统必须管理这些
记录锁，所以这种模型中实现上有一定复杂度。
（2）开放方式
在这种模型中，总是允许用户读取数据，甚至还允许更新数据。但是，当其他用户试图保存数据时，系统会检查自从这个用户检索数据以后是否有其他人‘更新’过数据。如果其他数据发生了变化，那么更新就失败了。这种模
型适用于不大可能出现多人同时修改同一数据的情况；但是，如果用户花费了大量时间来修改数据，最后却发现根本不能保存修改（会很郁闷^_^），那么他们会感到不方便。此时必须重新检索（刷新）并重新完成修改。
（3）没有并发保护
“胜利属于最后一个用户”。这是所有模型中最简单的一种模型。这种方法并不对多个用户编辑相同的数据提供保护，即系统只承认最后一个用户的保存行为。之前用户的保存会丢失。此外，根据系统的具体实现方式，当两个
用户试图同时保存数据时，这种方法可能会导致数据损坏。
软件采用何种并发处理方式，会影响到程序的性能、可用性和数据完整性。因此，为了验证应用程序在并发处理方面是否正确和有效（合理），根据为项目选择的并发性模型设计相应当并发性测试是非常重要的。
测试并发性很困难，时机是一个问题。无论系统处理并发采用了何种模型，为了确定系统是否『恰当』地保护理数据，测试人员必须模拟2个用户同时读取或写入数据。
在并发性测试中，可以综合考虑手动和
自动化测试技术。要设计并执行正确的测试，其关键时要对系统实现有所了解。
当相同的数据可以通过不同界面或者功能更新时，并发性测试会变得更加复杂。例如，当一个用户在编辑记录，而另外一个用户却删除了此记录，此时系统必须加强对并发性的控制。事实上，为了保证正在编辑的记录不被其他
功能所修改，应该测试『所有』可能访问这条记录的功能。
系统级的非功能性需求规格说明书，通常应该详细说明系统处理并发性问题的方式。如果某西特殊的系统功能与此有冲突，那么应该在描述这些特殊功能的需求文档中对之详细说明。
可见，测试人员要做到对系统实现方式了解，是多么重要和困难。
对不同的并发性模型，测试过程应该关注的要点：
● 保守方式
测试应主要关心的是验证能否正确定取得、释放（尤其是释放）锁，并且能正确处理应用程序中所有可能更新这条记录（或数据）的部分。这里主要关心的是一下3个方面：
■ 锁的获得。关键是系统必须把锁正确地分配给第一个请求的用户。如果获得锁到代码实现有错误，就会导致多个用户都认为他们自己拿到了锁，但是当他们试图保存数据时，可能会遇到错误或者其他不可预料的系统行为。
获得锁的操作是可以测试的，具体方法是：让2个用户同时进入编辑状态（或者也可以有大量的请求）。
■ 锁的效用。如果一个用户获得了锁，那么系统必须确保其他用户不能以『任何』方法和途径来修改这个数据，其中包括对数据的更新和删除。具体实现方法是：让一个用户打开一条记录（进入编辑状态并保持这个状态），
同时其他用户在应用程序的所有地方试图编辑、删除或者以其他方式来更新数据。系统应该【拒绝】所有其他用户更新数据的企图。
■ 锁的释放。测试人员必须验证：当编辑数据的用户释放了这条记录后（无论是更新完毕还是取消操作），系统能够成功地让其他用户使用这条记录。释放锁需要注意的一个重要方面是错误处理，也就是持有锁的用户遇到错
误（例如系统崩溃了）的情况下，系统应该完成什么样的操作。锁是否失去控制（如释放不了）？系统重释放锁定故障中重新恢复的能力需要重点考虑。
● 开放方式
在某种程度上，该并发模型的实现复杂度稍低。因为允许所有用户检索并编辑数据，所以『更新』是唯一要关注的要点。在手工的方法中，2个测试人员编辑数据，然后试图同时保存数据。第一个用户更新操作应该是成功的，
但第二个用户应该得到适当的提示信息。
与保守的并发模型一样，在开放的模型中，测试人员必须保证对『所有』可能修改数据的地方，开放的并发性都得到了验证，其中包括来自用户界面的不同部分的记录操作。
● 没有并发控制。这是最容易出错的并发模型。测试方法与测试开放的并发模型非常相似，区别是：无论更新请求的顺序如何，所有用户都应该成功完成更新操作。注意，应该关注数据的完整性。测试人员还应该验证是否正确
的处理了更新错误。
测试组对系统实现计划的研究有助于他们正确地确定采用何种策略来测试并发。
