软件可能进入的每一种独立状态;
从一种状态转入另一种状态所需的输入和条件;
进入或退出某种状态时的设置条件及输入结果.
l 具体测试方法可以参考如下:
每种状态至少访问一次;
测试看起来最常见最普遍的状态转换;
测试状态之间最不常用的分支
测试所有错误状态及其返回值
测试随机状态转换
2.2.4 竞争条件测试技术
l 竞争条件典型情形参考如下:
两个不同的程序同时保存或打开同一个文档
共享同一台打印机,通信端口或者其他外围设备
当软件处于读取或者修改状态时按键或者单击鼠标
同时关闭或者启动软件的多个实例
同时使用不同的程序访问一个共同数据库
2.3 负载\压力测试(StressTest)
l 在这里的负载\压力和功能测试中的不同,他是系统测试的内容,是基本功能已经通过后进行的.可以在集成测试阶段,亦可以在系统测试阶段进行.
l 使用负载测试工具进行,虚拟一定数量的用户看一看系统的表现,是否满足定义中的指标.
l 负载测试一般使用工具完成，loadrunner，webload，was，ewl，e-test等，主要的内容都是编写出测试脚本，脚本中一般包括用户一般常用的功能，然后运行，得出报告。所以负载测试包括的主要内容就不介绍了。
l 负载测试技术在各种极限情况下对产品进行测试 (如很多人同时使用该软件，或者反复运行该软件)，以检查产品的长期稳定性。例如，使用压力测试工具对web服务器进行压力测试. 本项测试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩滑。用J2EE实现的系统很少但是并不是没有内存问题.
无论什么工具基本的技术都是利用线程技术模仿和虚拟用户，在这里主要的难点在与测试脚本的编写，每种工具使用的脚本都不一样，但是大多数工具都提供录制功能就算是不会编码的测试人员同样可以测试。
对负载工具的延伸使用可以进行系统稳定性测试，系统极限测试，如使用100的Load Size连续使用24小时，微软定义的通过准则是通过72小时测试的程序一般不会出现稳定性的问题。
2.4 回归测试 (Regression Test)
l 过一段时间以后，再回过头来对以前修复过的Bug重新进行测试，看该Bug 是否会重新出现。
回归测试技术可以在测试的各个阶段出现，无论是单元测试还是集成测试还是系统测试。是对以前问题进行验证的过程。
回归测试的目的就是保证以前已经修复的Bug不会再出现。实际上，许多Bug都是在回归测试时发现的，在此阶段，我们首先要检查以前找到的Bug 是否已经更正了。值得注意的是，已经更正的Bug 也可能又回来了，有的Bug 经过修改之后可能又产生了新的Bug。所以，回归测试可保证已更正的Bug不再重现，不产生新的Bug。
2.5 Alpha 和Beta 测试 (Alpha and Beta Test):
l 在正式发布产品之前往往要先发布一些测试版，让用户能够反馈出相关信息，或者找到存在的Bug，以便在正式版中得到解决。
l 特别是在有客户参加的情况下，对系统进行测试可能会出现一些我们没有考虑的情况，还可以解决一些客户实际关心的问题
不同的测试技术区分
文章来源于领测软件测试网 https://www.ltesting.net/
