失败状态测试

　　状态测试的失败测试的案例，主要是竞争条件、重复、压迫和重负。

　　1. 竞争条件和时序错乱

　　设计多任务操作系统不是很难，设计充分利用多任务能力的软件才是艰巨的任务。在真正的多任务环境中软件设计不能想当然，必须处理随时被中断的情况，能够与其他任何软件在系统中同时运行，并且共享内存、磁盘、通信设备以及其他硬件资源。

　　这样的结果，是导致竞争条件问题；软件未预料到的中断发生，时序会发生错乱。

　　竞争条件测试难以设计，好是首先仔细查看状态转换图中的每一个状态，以找出哪些外部影响会中断该状态。考虑要使用数据如果没有准备好，或者在用到时发生了变化，状态会怎样。数条弧线或者直线同时相连的情形如何。

　　一下是要面临竞争条件的典型情形：

　　－ 两个不同的程序同时保存或打开同一个文档。

　　－ 共享同一台打印机、通信端口或者其他外围设备。

　　－ 当软件处于读取或者修改状态时按键或者单击鼠标。

　　－ 同时关闭或者启动软件的多个实例。

　　－ 同时使用不同的程序方位一个共同数据库。

　　2. 重复、压迫和重负

　　这三个测试的目标是处理那些连程序员都没有想到的恶劣条件下产生的问题的能力。

　　－ 重复测试

　　重复测试是不断执行同样的操作。简单的是不停地启动和关闭程序，或者反复读写数据或者选择同一个操作。这种测试的主要目的是看内存是否不足。如果内存被分配进行某项操作，但操作完成时没有完全释放，会产生一个常见的软件问题。

　　－ 压迫测试

　　压迫测试是使软件在不够理想的条件下运行——内存小、磁盘空间少、CPU速度慢、调制解调器速率低等等。观察软件对外部资源的要求和依赖程度。压迫测试是将支持降到低限度，目的在于尽可能的限制软件的必要条件。

　　－ 重负测试

　　重负测试和压迫测试相反。压迫测试是尽量限制软件，而重负测试是尽量提供条件任其发挥。让软件处理尽可能大的数据文件。大限度的发掘软件的能力，让它不堪重负。比如：软件对打印机或通信端口进行操作，把能连的都连上；服务器可以处理几千个模拟连接，按他说的做。

　　不要忘了，时间也是一种重负测试。

　　重复、压迫和重负测试应联合使用，同时进行。

　　需要注意的是：

　　一，项目管理员和小组程序员可能不完全接受软件测试员这样打破软件的做法。但是软件测试员的任务是确保软件在这样恶劣的条件下正常工作，否则报告软件缺陷。如何以佳方式报告软件缺陷，使其得到严肃对待和修复，也是一门学问。

　　二，无数次重复和上千次的连接对于手工操作是不可能的。因而需要借助自动化测试工具来实现。

　　其他黑盒测试方法

　　1. 像无经验的用户那样做

　　输入意想不到的数据；中途变卦而退回去执行其他操作；单击不应该单击的东西……

　　2. 在已经找到软件缺陷的地方再找找

　　原因有二：一是软件缺陷的集中性。如果发现在不同的特性中找出了大量上边界条件软件缺陷，那么应该对所有特性着重上边界条件。对某个存在的缺陷，应当投入一些案例来保证这个问题不是普遍存在的。二是程序员往往倾向于只修改报告出来的软件缺陷，不多也不少。比如报告启动－终止－再启动255次导致冲突，程序员可能只修复了这个问题。重新测试时，一定要重新执行同样的测试256次以上。

　　3. 凭借经验、直觉和预感

　　记录哪些技术有效，哪些不行。尝试不同的途径。如果认为有可疑之处，要仔细探究。按照预感行事，直至证实这是错误为止。

　　经验是人们对错误行为的称谓。

　　《软件测试》读书笔记（四）

　　静态测试是指测试非运行部分——检查和审查。白盒测试是指访问代码，能够查看和审查。

　　静态白盒测试实在不执行的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程。有时也成为结构分析。

　　静态白盒测试的原因，首先是尽早发现软件缺陷；另外可为接受该软件测试的黑盒测试员提供应用测试案例的思路，他们不必了解代码细节，根据审查备注可以确定可能存在问题的特性范围。

　　正式审查——进行白盒测试的过程

　　正式审查含义广泛，从程序员之间的交谈，到代码的严格检查均属于此过程。主要有4个基本要素：

　　－ 确定问题。

　　审查的目的，不仅是出错的，还包括遗漏的项目。全部的批评应直指代码，而不是其创建者。

　　－ 遵守规则

　　审查要遵守一套固定的规则，可能设定审查的代码量、花费时间、备注内容对象，以帮助合作者确定 自己的目标，了解自己的作用。

　　－ 准备

　　每个合作者需要了解自己的责任和义务，并积极参与审查。

　　－ 编写报告

　　审查小组必须做出总结审查结果的书面报告，并使报告便于开发小组使用。

　　正式审查的类型

　　1. 同事审查

　　召集小组成员进行初次正式审查是简单的方法。大体类似于“各抒己见”类型的讨论。常常仅在编写代码的程序员和充当审查者的其他一两个程序员和测试员之间进行。

　　2. 公开陈述

　　公开陈述是使同事审查正规化的下一步。编写代码的程序员像5人小组或其它类似的程序员或测试员正式表述，逐行或逐个通读代码，解释代码如何工作的以及为什么。审查人员应该在审查之前接到软件拷贝，以便检查并编写备注和问题，在审查过程中提问。参与人数要多于同事审查。因此，做好准备和遵守规则是十分重要的。

　　3. 检验

　　检验是正式的审查类型，具有高度组织化，要求每一个参与者都接受训练。检验与同事审查不同之处在于表述代码的人（表述者或宣读者），不再是原来的程序员。这迫使他学习和了解要表述的材料，从而有可能提出不同的看法和解释。

　　检验员在检验中的职责是从不同的角度（如用户、测试员或产品支持人员）的角度审查代码，指出软件缺陷。检验会议后，检验员可能再次碰头讨论他们发现的不足之处，并与会议主席共同准备一份书面报告，明确解决问题所必须重做的工作。

　　编码标准和规范

　　坚持标准或规范的原因：

　　－ 可靠性。事实证明，代码缺陷将更少

　　－ 可读性、维护性。

　　－ 移植性。如果代码符合设备标准，迁移到另一个平台会轻而易举。

　　标准由4个主要部分组成：

　　－ 标题。描述主题。

　　－ 标准（或规范）。描述内容，解释哪些允许，哪些不允许。

　　－ 解释说明。给出指定该标准的原因。说服程序员。

　　－ 实例。这不是必需的。

　　注意：标准/规范和风格不是一回事。后者不是缺陷。