1. 概述 

随着 web 应用的增多，新的模式解决方案中以 web 为核心的应用也越来越多， 很多公司各种应用的架构都以 B/S 及 web 应用为主，但是有关 WEB 测试方面的内容并没有相应的总结，所以我在这里对 web 的测试方法和采用的测试技术进行总结，便于内部交流。
测试方法尽量涵盖 web 程序的各个方面，测试技术方面在继承传统测试技术的技术上结合 web 应用的特点。 
l 相关的测试和实现技术也有着很大的关系，由于本公司使用 J2EE 体系，也许例子中只有 JAVA 平台可以使用， .NET 平台测试技术暂时不涉及，如果你有请与我联系。 

2. 测试方法 

说明：测试方法的选择取决你的测试策略。 

一般的 web 测试和以往的应用程序的测试的侧重点不完全相同，基本包括以下几个方面。 

当然圆满的完成测试还要有好的团体和流程等的方方面面的支持，你同样应该对这些方面进行注意。 

有些测试方法设计到了流程，哪些应该在你的测试团队建设中建立。 

2.1 界面测试 

现在一般人都有使用浏览器浏览网页的经历，用户虽然不是专业人员但是对界面效果的印象是很重要的。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常重要了。很多人认为这是测试中最不重要的部分，但是恰恰相反界面对不懂技术的客户来说那相当关键，慢慢体会你会明白的。 

方法上可以根据设计文档，如果够专业的话可以专业美工人员，来确定整体风格页面风格，然后根据这个可以页面人员可以生成静态的 HTML ， CSS 等甚至生成几套不用的方案来讨论，或者交给客户评审，最后形成统一的风格的页面 / 框架。注意不要靠程序员的美术素养形成你的 web 风格，那样可能会很糟糕。 

主要包括以下几个方面的内容： 

1 站点地图和导航条 位置、是否合理、是否可以导航等内容布局 布局是否合理，滚动条等简介说明 说明文字是否合理，位置，是否正确； 

2 背景 / 色调 是否正确、美观，是否符合用户需求； 

3 页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）表单样式 大小，格式，是否对提交数据进行验证（如果在页面部分进行验证的话）等； 

4 连接 连接的形式，位置，是否易于理解等。 

web 测试的主要页面元素 

5 页面元素的容错性列表（如输入框、时间列表或日历）； 

6 页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）； 

7 页面元素的容错性是否存在； 

8 页面元素的容错性是否正确； 

9 页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）； 

10 页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）； 

11 页面元素是否显示正确（主要针对文字、图形、签章）； 

12 元素是否显示（元素是否存在）； 

13 页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）。 

测试技术 

14 通过页面走查，浏览确定使用的页面是否符合需求。可以结合兼容性测试对不用分辨率下页面显示效果，如果有影响应该交给设计人员提出解决方案； 

15 可以结合数据定义文档查看表单项的内容，长度等信息； 

16 对于动态生成的页面最好也能进行浏览查看。如 Servelet 部分可以结合编码规范，进行代码走查。是否支持中文，如果数据用 XML 封装要做的工作会多一点等等。 

2.1.l 界面测试要素 : 

符合标准和规范 , 灵活性 , 正确性 , 直观性 , 舒适性 , 实用性 , 一致性 

2.1.l.1 直观性 : 

a 用户界面是否洁净 , 不唐突 , 不拥挤 . 界面不应该为用户制造障碍 . 所需功能或者期待的响应应该明显 , 并在预期出现的地方； 

b 界面组织和布局合理吗 ? 是否允许用户轻松地从一个功能转到另一个功能 ? 下一步做什么明显吗 ? 任何时刻都可以决定放弃或者退回 , 退出吗 ? 输入得到承认了吗 ? 菜单或者窗口是否深藏不露 ? 

c 有多余功能吗 ? 软件整体抑或局部是否做得太多 ? 是否有太多特性把工作复杂化了 ? 是否感到信息太庞杂 ? 

d 如果其他所有努力失败 , 帮助系统真能帮忙吗 ? 

2.1.l.2 一致性 

a 快速键和菜单选项 . 在 Windows 中按 F1 键总是得到帮助信息； 

b 术语和命令 . 整个软件使用同样的术语吗 ? 特性命名一致吗 ? 例如 ,Find 是否一直叫 Find, 而不是有时叫 Search? 

c 软件是否一直面向同一级别用户 ? 带有花哨用户界面的趣味贺卡程序不应该显示泄露技术机密的错误提示信息； 

d 按钮位置和等价的按键 . 大家是否注意到对话框有 OK 按钮和 Cancle 按钮时 ,OK 按钮总是在上方或者左方 , 而 Cancle 按钮总是在下方或右方 ? 同样原因 ,Cancle 按钮的等价按键通常是 Esc, 而选中按钮的等价按钮通常是 Enter. 保持一致。 

2.1.l.3 灵活性 

a 状态跳转：灵活的软件实现同一任务有多种选择方式； 

b 状态终止和跳过：具有容错处理能力； 

c 数据输入和输出：用户希望有多种方法输入数据和查看结果 . 例如 , 在写字板插入文字可用键盘输入 , 粘贴 , 从 6 种文件格式读入 , 作为对象插入 , 或者用鼠标从其他程序拖动。 

2.1.l.4 舒适性 

a 恰当：软件外观和感觉应该与所做的工作和使用者相符； 

b 错误处理：程序应该在用户执行严重错误的操作之前提出警告 , 并允许用户恢复由于错误操作导致丢失的数据，如大家认为 undo /redo 是当然的； 

c 性能：快不见得是好事，要让用户看得清程序在做什么，它是有反应的。 

2.2 功能测试 

功能测试是测试中的重点，主要包括一下几个方面的内容： 

a 连接：这个连接和界面测试中的连接不同。那里注重的是连接方式和位置，如是图像还是文字放置的位置等，还是其他的方式；这里的连接注重功能，如是否有连接，连接的是否是说明的位置等； 

b 表单提交：应当模拟用户提交，验证是否完成功能，如注册信息，要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。还有数据正确性验证，异常处理等，最好结合易用性要求等。 B/S 结构实现的功能可能主要的就在这里，提交数据，处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量； 

c Cookies 验证：如果系统使用了 cookie ，测试人员需要对它们进行检测。如果在 cookies 中保存了注册信息，请确认该 cookie 能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。关于 cookie 的使用可以参考浏览器的帮助信息。如果使用 B/S 结构 cookies 中存放的信息更多； 

d 功能易用性测试 完成了功能测试可以对应用性进行了解，最好听听客户的反映，在可以的情况下对程序进行改进是很有必要的，和客户保持互动对系统满意度也是很有帮助的。 

2. 2.1 测试技术 

功能测试的测试技术可是很多的，我们可以结合实际环境选择使用。 

a白盒测试技术 (White Box Testing) ： 深入到代码一级的测试，使用这种技术发现问题最早，效果也是最好的。该技术主要的特征是测试对象进入了代码内部，根据开发人员对代码和对程序的熟悉程度，对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，在 JAVA 平台使用 Xunit 系列工具进行测试， Xunit 测试工具是类一级的测试工具对每一个类和该类的方法进行测试。 

b黑盒测试技术（ Black Box Testing ）：黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，根据软件需求，设计文档，模拟客户场景随系统进行实际的测试，这种测试技术是使用最多的测试技术涵盖了测试的方方面面，可以考虑以下方面 

c正确性 (Correctness) ：计算结果，命名等方面。 

d可用性 (Usability) ：是否可以满足软件的需求说明。 

e边界条件 (Boundary Condition) ：输入部分的边界值，就是使用一般书中说的等价类划分，试试最大最小和非法数据等等。 

f性能 (Performance) ： 正常使用的时间内系统完成一个任务需要的时间，多人同时使用的时候响应时间在可以接受范围内。 J2EE 技术实现的系统在性能方面更是需要照顾的，一般原则是 3 秒以下接受， 3-5 秒可以接受， 5 秒以上就影响易用性了。如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，就要考虑到软件的性能问题 

g压力测试 (Stress) ： 多用户情况可以考虑使用压力测试工具，建议将压力和性能测试结合起来进行。如果有负载平衡的话还要在服务器端打开监测工具 , 查看服务器 CPU 使用率，内存占用情况，如果有必要可以模拟大量数据输入，对硬盘的影响等等信息。如果有必要的话必须进行性能优化 ( 软硬件都可以 ) 。这里的压力测试针对的是某几项功能。 

h错误恢复 (Error Recovery) ：错误处理，页面数据验证，包括突然间断电，输入脏数据等。 

i安全性测试 (Security) ：这个领域正在研究中，防火墙、补丁包、杀毒软件等的就不必说了，不过可以考虑。破坏性测试时任意看了一些资料后得知 , 这里面设计到的知识 \ 内容可以写本书了 , 不是一两句可以说清的，特别是一些商务网站，或者跟钱有关，或者和公司秘密有关的 web 更是需要这方面的测试，在外国有一种专门干这一行的人叫安全顾问，可以审核代码，提出安全建议，出现紧急事件时的处理办法等，在国内没有听说哪里有专门搞安全技术测试的内容。 

j 兼容性 (Compatibility) ：不同浏览器，不同应用程序版本在实现功能时的表现不同的上网方式，如果你测试的是一个公共网站的话。 

兼容性测试内容详述： 

a 硬件平台 

b 浏览器软件和版本：浏览器插件，浏览器选项，视频分辨率和色深，文字大小，调制解调器速率 . 

c 软件配置 (Configuration) ：如 IE 浏览器的不用选项 - 安全设定最高，禁用脚本程序等等，你们的程序在各种不用的设置下表现如何。 

2. 2.2 单元测试技术 (Unit Test): 

2. 2.2 .1 下面是对白盒测试和单元测试的区别的论述 : 

单元测试和白盒测试是不同的，虽然单元测试和白盒测试都是关注功能，他们都需要代码支持，但是级别不同。白盒测试关注的是类中一个方法的功能，是更小的单位，但是完成一个单元测试可能需要 N 多类，所以说作单元测试需要写驱动和稳定桩，比如查询单元是一个查询包，包括 N 多的测试类、测试数据，运行他需要提供数据的部分，输入参数和发出命令的驱动等等，是比类大的一个整体进行的。 

另一个明显的区别是白盒测试不会关注类接口，但是单元测试主要的内容就是类接口测试。 

不过很多时候是很少区分的，因为这两种技术实现起来有很多相互关联的部分。不过要看你对质量的关注程度来决定。 

2. 2.2 .2 功能测试边界测试 \ 越界测试技术详述 

a 边界条件 

边界条件是指软件计划的操作界限所在的边缘条件，如果软件测试问题包含确定的边界，那么数据类型可能是：数值、速度、字符、地址、位置、尺寸、数量。同时，考虑这些类型的下述特征：第一个 / 最后一个、最小值 / 最大值、开始 / 完成、超过 / 在内、空 / 满、最短 / 最长、最慢 / 最快、最早 / 最迟、最大 / 最小、最高 / 最低、相邻 / 最远。 

b 越界测试 

通常是简单加 1 或者很小的数 ( 对于最大值 ) 和减少 1 或者很小的数 ( 对于最小值 ) ，例如：第一个减 1/ 最后一个加 1 、开始减 1/ 完成加 1 、空了再减 / 满了再加、慢上加慢 / 快上加快、最大数加 1/ 最小数减 1 、最小值减 1/ 最大值加 1 、刚好超过 / 刚好在内、短了再短 / 长了再长、早了更早 / 晚了更晚、最高加 1/ 最低减 1 。 

另一些该注意的输入：默认，空白，空值，零值和无；非法，错误，不正确和垃圾数据。 

2. 2.2 .3 状态测试技术 

a 软件可能进入的每一种独立状态； 

b从一种状态转入另一种状态所需的输入和条件； 

c 进入或退出某种状态时的设置条件及输入结果。 

具体测试方法可以参考如下： 

d 每种状态至少访问一次； 

e 测试看起来最常见最普遍的状态转换； 

f 测试状态之间最不常用的分支； 

g 测试所有错误状态及其返回值； 

h 测试随机状态转换。 

2. 2.2 .4 竞争条件测试技术 

竞争条件典型情形参考如下 : 

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

b 共享同一台打印机 , 通信端口或者其他外围设备； 

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

d 同时关闭或者启动软件的多个实例； 

e 同时使用不同的程序访问一个共同数据库。 

2. 2.3 负载 \ 压力测试 (StressTest) 

在这里的负载 \ 压力和功能测试中的不同，他是系统测试的内容，是基本功能已经通过后进行的。可以在集成测试阶段，亦可以在系统测试阶段进行。 

使用负载测试工具进行，虚拟一定数量的用户看一看系统的表现，是否满足定义中的指标。 

负载测试一般使用工具完成， loadrunner ， webload ， was ， ewl ， e-test 等，主要的内容都是编写出测试脚本，脚本中一般包括用户常用的功能，然后运行，得出报告。所以负载测试包括的主要内容就不介绍了。 

负载测试技术在各种极限情况下对产品进行测试 ( 如很多人同时使用该软件，或者反复运行该软件 ) ，以检查产品的长期稳定性。例如，使用压力测试工具对 web 服务器进行压力测试。本项测试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩滑。用 J2EE 实现的系统很少但是并不是没有内存问题。 

a 无论什么工具基本的技术都是利用线程技术模仿和虚拟用户，在这里主要的难点在与测试脚本的编写，每种工具使用的脚本都不一样，但是大多数工具都提供录制功能就算是不会编码的测试人员同样可以测试。 

b 对负载工具的延伸使用可以进行系统稳定性测试，系统极限测试，如使用 100 的 Load Size 连续使用 24 小时，微软定义的通过准则是通过 72 小时测试的程序一般不会出现稳定性的问题。 

2. 2.4 回归测试 (Regression Test) 

过一段时间以后，再回过头来对以前修复过的 Bug 重新进行测试，看该 Bug 是否会重新出现。 

a 回归测试技术可以在测试的各个阶段出现，无论是单元测试还是集成测试还是系统测试。是对以前问题进行验证的过程。 

b 回归测试的目的就是保证以前已经修复的 Bug 不会再出现。实际上，许多 Bug 都是在回归测试时发现的，在此阶段，我们首先要检查以前找到的 Bug 是否已经更正了。值得注意的是，已经更正的 Bug 也可能又回来了，有的 Bug 经过修改之后可能又产生了新的 Bug 。所以，回归测试可保证已更正的 Bug 不再重现，不产生新的 Bug 。 

2. 2.5 A lpha 和 Beta 测试 (Alpha and Beta Test): 

在正式发布产品之前往往要先发布一些测试版，让用户能够反馈出相关信息，或者找到存在的 Bug ，以便在正式版中得到解决。 

特别是在有客户参加的情况下，对系统进行测试可能会出现一些我们没有考虑的情况，还可以解决一些客户实际关心的问题。 

不同的测试技术区分 

2.3 覆盖测试技术 

说明 : 测试覆盖率可以看出测试的完成度，在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。 

覆盖测试可以是程序代码的执行路径覆盖，亦可以是功能实现的步骤覆盖（可以理解成流程图的路径覆盖）。 

该技术可以用在任何测试阶段，包括单元测试、集成测试、系统测试。 

使用该技术时可以使用以上的任何测试方法和测试技术。 

2.4 白盒测试和黑盒测试技术 

白盒测试技术 (White Box Testing) ：该技术主要的特征是测试对象进入了代码内部，根据开发人员对代码和对程序的熟悉程度，对有需要的部分进行测试。在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，使用 Xunit 系列工具进行测试，可以包括很多方面如功能性能等。 

黑盒测试 (Black Box Testing) ：测试的主体部分，黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，包括的不同测试类型请参考以上内容。 

2.5 手工测试和自动化测试 

手工测试 （ Manual Testing ）：即依靠人力来查找 Bug 。方法可以参考上边的测试，也可以根据对实现技术及经验等进行不同的测试。 

自动测试 （ Automation Testing ）：使用有针对工具实行。可以作出自动化测试的计划，对可以进行自动化测试的部分编写或者录制相应的脚本，可以加入功能，容错，表单提交等，可以参考 MI,Rational 或者其他类测试工具说明。 

根据权威的软件测试经验，手工测试还是主要的测试方法，自动测试不够灵活，在这里不再详述。微软的测试过程 80 ％还是手工完成。 

自动测试永远也代替不了手工测试，但是手工测试的工作量很大是不争的事实。 

2.6 根据 RUP 标准按阶段区分测试 

单元测试：在上边有详细的叙述，还有针对单元测试和集成测试的论述，请参考。 

集成测试：分为功能集成测试和系统集成测试，相互有调用的功能集成，在系统环境下功能相互调用的影响等，使用方法可以任意选用上面的内容。注重功能方面。 

系统测试：在功能实现的基础上，可以加入兼容性，易用性，性能等等。 

验收测试：可以包括 Alpha 和 Beta 测试，在这里就不再详述。 

3. 存在风险及解决方法 

说明：测试不能找出所有的问题，只是尽量在开发阶段解决大多数的问题而已。 

测试风险如下： 

软硬件的测试环境提供上也对测试结果有很大的影响； 

测试团队的水平，经验，合作效果等； 

整个开发流程对测试的重视程度，测试的进入时间等； 

由于测试环境操作系统，网络环境，带宽等情况可能产生的测试结果可能不同这是就需要经验以及对测试环境的保护等方面下一些功夫。 

4. 软件缺陷的原则 

软件缺陷区别于软件 bug, 它是在测试过程中出现的对系统有影响的，但是在设计中没有的或者对修改后的 bug 测试和开发人员有不同意见等。 

a 软件未达到产品说明书标明的功能； 

b 软件出现了产品说明书指明不会出现的错误； 

c 软件功能超出产品说明书指明范围； 

d 软件未达到产品说明书虽未指出但应达到的目标； 

e 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。 

5. 文档测试 

产品说明书属性检查清单 

a 完整：是否有遗漏和丢失？完全吗？单独使用是否包含全部内容？ 

b 准确：既定解决方案正确吗？目标明确吗？有没有错误？ 

c 精确：不含糊，清晰。描述是否一清二楚？还是自说自话？容易看懂和理解吗？ 

d 一致：产品功能描述是否自相矛盾？与其他功能有没有冲突 ? 

e 贴切：描述功能的陈述是否必要 ? 有没有多余信息 ? 功能是否满足的客户要求 ? 

f 合理：在特定的预算和进度下，以现有人力，物力和资源能否实现 ? 

g 代码无关：是否坚持定义产品，而不是定义其所信赖的软件设计，架构和代码 ? 

h 可测试性：特性能否测试 ? 测试员建立验证操作的测试程序是否提供足够的信息 ? 

产品说明书用语检查清单 

说明：对问题的描述通常表现为粉饰没有仔细考虑的功能 ---- 可归结于前文所述的属性。从产品说明书上找出这样的用语，仔细审视它们在文中是怎样使用的。产品说明书可能会为其掩饰和开脱 , 也可能含糊其词 ---- 无论是哪一种情况都可视为软件缺陷

i 总是，每一种，所有，没有，从不。如果看到此类绝对或肯定的，切实认定的叙述，软件测试员就可以着手设计针锋相对的案例

j 当然，因此，明显，显然，必然。这些话意图诱使接受假定情况，不要中了圈套。 

k 某些，有时，常常，通常，惯常，经常，大多，几乎。这些话太过模糊， " 有时 " 发生作用的功能无法测试。 

l 等等，诸如此类，依此类推。以这样的词结束的功能清单无法测试，功能清单要绝对或者解释明确，以免让人迷惑，不知如何推论。 

m 良好，迅速，廉价，高效，小，稳定。这些是不确定的说法，不可测试。如果在产品说明书中出现，就必须进一步指明含义。 

n 已处理，已拒绝，已忽略，已消除。这些廉洁可能会隐藏大量需要说明的功能。 

o 如果 ... 那么 ...( 没有否则 ) 。找出有 " 如果 ... 那么 ..." 而缺少配套的 " 否则 " 结构的陈述，想一想 " 如果 " 没有发生会怎样。 

6．在LINUX系统中，下列哪一个命令属于目录管理的常用命令？
A．pwd
B．pr  
C．ln  
D．find
答案：（ ）

7．软件测试是软件开发过程的重要阶段，是软件质量保证的重要手段，下列哪个（些）是软件测试的任务？
　　Ⅰ预防软件发生错误　　Ⅱ发现改正程序错误　　Ⅲ提供诊断错误信息
A．只有Ⅰ  
B．只有Ⅱ  
C．只有Ⅲ
D．都是
答案：（ ）

8．软件测试是软件质挝保证的重要手段，下述哪种测试是软件测试的最基础环节？
A．功能测试  
B．单元测试　
C．结构测试  
D．确认测试
答案：（ ）

9．在数据库的如下两个表中，若雇员信息的主键是雇员号，部门信息表的主键是部门号，在下列所给的操作中，哪个操作不能执行？  
雇员信息表：

雇员号 雇员名 部门号 工资
001 张山 02 2000
010 王宏达 01 1200
056 马林生 02 1000
101 赵敏 04 1500
部门信息表

部门号 部门名 主任
01 业务部 李建
02 销售部 应伟东
03 服务部 周垠
04 财务部 陈力胜


A．从雇员信息表中删除行（'010'，'王宏达'，'01'，1200）
B．将行（'102'，'赵敏'，'01'，1500）插入到雇员信息表中
C．将雇员信息表中雇员号='010'的工资改为1600元
D．将雇员信息表中雇员号='101'的部门号改为' 05'
答案：（ ）


10．在数据库的如上图两个表中，若雇员信息表的主键是雇员号，部门信息表的主键是部门号。在部门信息表中，哪一行可以被删除？
A．部门号='01'的行  
B．部门号='02'的行
C．部门号='03'的行  
D．部门号='04'的行
答案：（ ）

11．若用如下的SQL语句创建了一个表S:
CREATE TABLE S（S# CHAR（6）NOT NULL，
SNAME CHAR（8）NOT NULL，SEX CHAR（2），AGE INTEGER）
今向S表插入如下行时，哪一行可以被插入？
A．（'991001'，'李明芳'，女，'23'）
B．（'990746'，"张为'，NULL，NULL）
C．（NULL，'陈道一'，'男'，32）
D．（'992345'，NULL，'女'，25）
答案：（ ）


12．如果互连的局域网高层分别采用TCP/IP协议与SPX/IPX协议，那么我们可以选择的互连设备应该是
A．中继器  
B．网桥  
C．网卡  
D．路由器
答案：（ ）

13．通常可分为白盒测试和黑盒测试。白盒测试是根据程序的（  ）来设计测试用例,黑盒测试是根据软件的规格说明来设计测试用例。
A．功能  
B．性能  
C．内部逻辑  
D．内部数据
答案：（ ）

14．常用的黑盒测试方法有边值分析、等价类划分、错误猜测、因果图等。其中（  ）经常与其它方法结合起来使用。软件测试的步骤主要有单元测试、集成测试和确认测试。
A．边值分析  
B．等价类划分  
C．错误猜测  
D．因果图
答案：（ ）

15．LINUX下，解压缩文件的命令为？
A．        tar zxvf 文件名
B．        COPY 文件名
C．        CAT 文件名
D．        VI 文件名
答案：（ ）

16．从下列关于软件测试的叙述中，选出5条正确的叙述。
(1) 用黑盒法测试时，测试用例是根据程序内部逻辑设计的。
(2) 尽量用公共过程或子程序去代替重复的代码段。
(3) 测试是为了验证该软件已正确地实现了用户的要求。
(4) 对于连锁型分支结构，若有n个判定语句，则有2n条路径。
(5) 尽量采用复合的条件测试，以避免嵌套的分支结构。
(6) GOTO语句概念简单，使用方便，在某些情况下，保留GOTO语句反能使写出的程序更加简洁。
(7) 发现错误多的程序模块，残留在模块中的错误也多。
(8) 黑盒测试方法中最有效的是因果图法。
(9) 在做程序的单元测试时，桩（存根）模块比驱动模块容易编写。
(10) 程序效率的提高主要应通过选择高效的算法来实现。
A．1．3．4．5．9
B．2．4．6．7．10
C．4．5．6．7．10
D．1．2．3．8．9
答案：（ ）

17．（  ）方法根据输出对输入的依赖关系设计测试用例。
Ａ．路径测试      
Ｂ．等价类            
Ｃ．因果图            
Ｄ．归纳测试
答案：（ ）

18．在安装Bugzilla过程中，其中异步需要在BUGZILLA的目录内运行checksetup.pl，请以下那个命令正确？
A．        checksetup.pl
B．        make checksetup.pl
C．        ./ checksetup.pl
D．        cat checksetup.pl
答案：（ ）

19．手动安装PerL模块是，以下哪个操作正确？
A． bash# make
bash# make test
bash# perl Makefile.PL
bash# make install

B． bash# make install  
bash# make
bash# make test
bash# perl Makefile.PL

C． bash# make test  
bash# make
bash# perl Makefile.PL
bash# make install

D． bash# perl Makefile.PL
bash# make
bash# make test
bash# make install

答案：（ ）


20．You want to use the Web to let __(224)__ users or your customers look __(225)__ corporate information. But you want to keep installation at the user end __(226)__ and you don't want just __(227)__ to get __(228)__ your databases.  
  That may be where an application server enters the picture. For more user machine
independent, these software packages, typically written in the __(229)__ programming language for use on Windows __(230)__ -based systems, act as go-betweens __(231)__ browser-equipped end users to the databases that __(232)__ the information they need to __(233)__.  
(224): A. informer B. internal C. inside D. outside  
(225): A. at B. by C. in D. out  
(226): A. simple B. simply C. single D. singly  
(227): A. any B. anyone C. anything D. anywhere  
(228): A. into B. off C. onto D. out  
(229): A. C B. C++ C. SQL D. JAVA  
(230): A. NC B. NT C. PC D. PT  
(231): A. link B. linkage C. linking D. links  
(232): A. held B. helt C. hold D. holt  
(233): A. access B. accessing C. assert D. asserting

答案：（     ）

公布答案：
6 A 7 D 8 B 9 D 10 C
11 B 12 D 13 C 14 B 15 A
16 C 17 C 18 C 19 D
2O
B A A B A D B C C A
答案来自某认证考试给出的答案，部分需要商榷。    

LINK：http://bbs.testage.net/viewthread.php?tid=9058&extra=page%3D4%26amp%3Bfilter%3Ddigest

软 件 测 试 考 试

用户注册和密码修改测试点

登陆、添加、删除、查询模块的测试点

构建可“复用”的软件测试环境 [转帖]

软件测试常见模型-V，W，H，X

V模型
在V模型中，测试过程被加在开发过程的后半部分，如下图所示：

 

1.PNG (12.09 KB)

2008-2-20 14:48

    单元测试所检测代码的开发是否符合详细设计的要求。集成测试所检测此前测试过的各组成部分是否能完好地结合到一起。系统测试所检测已集成在一起的产品是否符合系统规格说明书的要求。而验收测试则检测产品是否符合最终用户的需求。

对于测试设计，显而易见的是，V模型的用户往往会把执行测试与测试设计分开对待。在开发文档准备就绪后，就可以开始进行相关的测试设计。如下图所示，相应的测试设计覆盖在了相关的开发过程之上：

2.PNG (12.36 KB)

2008-2-20 14:48

将测试设计覆盖了开发过程后的V模型

 

    V模型有着很吸引人的对称外形，并且把很多人都带入了歧途。本文将集中讨论它在单元测试和集成测试中引起的问题。

为了说明的方便，这里专门制作了以下图片，图中包括一个单独的单元，以及一个单元组，称之为子系统（subsystem）。

3.PNG (7.7 KB)

2008-2-20 14:48

一个假想的子系统

对于一个单元应该多大才最为合适的问题，已经有过很多的讨论，究竟一个单元仅仅是一个函数，一个类，还是相关的类的集合？这些讨论并不影响我在这里所要阐述的观点。我们权且认为一个单元就是一个最小程度的代码块，开发人员可以对进行独立地讨论。

    V模型认为人们首先应该对每一个单元进行测试。当子系统中所有的单元都已经测试完毕，它们将被集中到一起进行测试，以验证它们是否可以构成一个可运行的整体。

那么，如何针对单元进行测试呢？我们会查看在详细设计中对接口的定义，或者查看源代码，或者同时对两者进行查看，找出符合某些测试设计中的有关准则的输入数据来进行输入，然后检查结果，看其是否正确。由于各单元一般来说不能独立地运行，所以我们不得不另外设计桩模块（Stub）和驱动模块（Driver），如下图所示。

4.PNG (4.38 KB)

2008-2-20 14:48

单元及其外部的驱动模块和桩模块

图中的箭头代表了测试的执行轨迹。这就是大多数人所说的“单元测试”。这样的方法有时候是一种不好的方法。

同样的输入也可以有同一子系统中的其它单元来提供，这样，其它的单元既扮演了桩模块，又扮演了驱动模块。如下图所示：

5.PNG (4.99 KB)

2008-2-20 14:48

子系统内部各单元间的测试执行轨迹

到底选择哪一种方法，这需要一种折衷和权衡。设计桩模块和驱动模块要付出多少代价？这些模块如何进行维护？子系统是否会由此而掩盖了一些故障？在整个子系统范围内进行排错的困难程度有多大？如果我们的测试直到集成测试时才真正开始，那么一些bug可能较晚才被发现。由此造成的代价同设计桩模块和驱动模块的代价如何比较？

    V模型没有去考虑这些问题，当单元开发完成后就执行单元测试，而当自系统被集中在一起后就执行集成测试，仅此而已。令我奇怪和沮丧的是，人们从不去做一些权衡，他们已经受制于他们的模型。

因此，一个有用的模型应该允许测试人员考虑节省并推迟测试的可能性。

一个测试，如果要发现一个特定的单元中的bug，最好是在该单元保持独立的情况下执行，并且在其外部辅以特定的桩模块和驱动模块。而另一种方法则是让它作为子系统的一部分来进行测试，该测试的设计主要是为了发现集成的问题。由于一个子系统本身也需要桩模块和驱动模块来模拟该子系统和其它子系统的联系，因此，单元测试和集成测试可能被推迟到至少整个系统已经部分集成的时候。在这种情况下，测试者可能通过产品的外部接口同时进行单元测试、集成测试和系统测试，同样的，其主要目的还是为了减少总体生命周期的成本，对测试成本和延期进行测试及由此造成延期发现bug的代价成本进行权衡。据此而言，"单元测试"、"集成测试"和"系统测试"的区别已经大大削弱了。其结果可参考下图：

6.PNG (14.49 KB)

2008-2-20 14:48

新的方法：在部分阶段延迟进行单元测试和集成测试

在上图右边的方块中，最好要改成为“执行某些适当的测试并得到相应的结果”。

图中的左边会怎样？考虑一下系统测试设计，它的主要根据和信息来源是是规格说明。假设你知道有2个单元处在一个特定的子系统中，它们在运行时相互联系，并且要执行规格说明中的一个特定的声明。为什么不在该子系统被集成时立即对此规格说明中的声明进行测试，就象是在设计完成后立即开始测试的设计一样呢？如果该声明的执行和子系统外的子系统没有任何关系，为什么还要等到整个系统完成以后再测试呢？难道越早发现bug成本越低不对吗？

在上一张图片中，我们用了向上指的箭头（更有效，但在时间上有延迟）。这里还可以把箭头往下指（在时间上提前）：

7.PNG (16.64 KB)

2008-2-20 14:48

新的方法：在不同阶段上提前进行测试设计

在这种情况下，左边的方块中最好被标记为：“在当前信息条件和情况下可以做的任何测试设计”。这样，当测试设计得自于系统中某一个组件的描述时，模型必须允许这样的测试在组件被装配之前被执行。我必须承认我的图片非常难看，这些箭头指得到处都是，对此我有2点说明：

    1. 我们所讨论的事情不是创造美，而是想要发现尽可能多的严重错误，同时尽可能地降低成本。

    2. 难看的部分原因也是因为必须按照某些次序来执行的结果，亦即开发人员先提供系统描述文档，然后测试和这些文档进行关联。这些文档就象是坚实的老橡树，而测试设计则象是细细的枝条缠绕在树上。如果我们采用不同的原理来进行组织，图片可能就会变得好看些。但复杂性仍不可避免，因为我们要讨论的问题本身就很复杂。

    V模型失败的原因是它把系统开发过程划分为具有固定边界的不同阶段，这使得人们很难跨过这些边界来采集测试所需要的信息。有些测试应该执行得更早些，有些测试则需要延后进行。而且，它也阻碍了你从系统描述的不同阶段中取得信息进行综合。例如，某些组织有时执行这样的做法，即对完成的工作进行签署。这样的规定也扩展到系统测试的设计。签署表示已经过评估，该测试设计工作已经完成，除非对应的设计文档改变，否则就不会被修订。如果同这些测试相关的信息后来被重新挖掘和认识，例如，架构设计表明有些测试是多余的，或者，详细设计表明有一个内部的边界可以和已存在的系统测试组合在一起进行测试的话，那么实际上还需要继续调整原来的系统测试设计。

因此，模型必须允许利用不同来源的综合信息进行个别的测试设计。另外，模型还应该允许在新的信息来源出现后重新进行测试的设计。

上次说到V模型的局限性在于没有明确地说明早期的测试,无法体现“尽早地和不断地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试，演化为W模型。在模型中不难看出，开发是“V”，测试是与此并行的“V”。基于“尽早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活动应遵循IEEE1012-1998《软件验证与确认（V&V）》的原则。

V模型

由Evolutif公司提出，相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。

W模型也有局限性。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动，无法支持迭代、自发性以及变更调整。

上次提到两个测试过程模型，都没有很好地体现测试流程的完整性。为了解决以上问题，提出了H模型。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

8.PNG (33.44 KB)

2008-2-20 14:48

     

 

                          

软件测试H模型

示意图演示了在整个生产周期中某个层次上的一次测试“微循环”。图中的其他流程图可以是任意开发流程。例如，设计流程和编码流程。也可以是其他非开发流程，例如，SQA流程，甚至是测试流程本身。只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了。

 

9.PNG (18.55 KB)

2008-2-20 14:48

 

 

H模型揭示了：

·
软件测试不仅仅指测试的执行，还包括很多其他的活动

·
软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行

·
软件测试要尽早准备，尽早执行

·
软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的

在H模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。

X模型的基本思想是由Marick提出的，但首先是Marick不建议要建立一个替代模型。Robin F·Goldsmith引用了一些Marick的想法，并重新经过组织，形成了“X模型”。其实并不是为了和V模型相对应而选择这样的名字，而是由于其它一些原因：X通常代表未知，而Marick也认为他的观点并不足以支撑一个模型的完整描述，但其中已经有一个模型所需要的一些主要内容，其中也包括了象探索性测试（exploratory testing）这样的亮点。

10.PNG (26.92 KB)

2008-2-20 14:48

  

X模型示意图

       Marick对V模型的最主要批评是V模型无法引导项目的全部过程。他认为一个模型必须能处理开发的所有方面，包括交接，频繁重复的集成，以及需求文档的缺乏等等。

       Marick认为一个模型不应该规定那些和当前所公认的实践不一致的行为。X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序。(右上半部分），这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。
由上图中可见，X模型还定位了探索性测试（右下方）。这是不进行事先计划的特殊类型的测试，诸如“我这么测一下结果会怎么样？”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
然而，关注于这样的低级别的行为可能会引起不同的议论。一个模型和一个单独的项目计划有所不同。模型不应该描述每个项目的具体细节，模型应该对项目进行指导和支持。当然，代码的交接也可以简单地认为是一种集成的形式。而V模型也并没有限制各种创建周期的发生次数。

     Marick和Graham都一致认同，应该在执行测试之前进行测试设计。Marick建议：“在你掌握相关知识时进行设计，在你手头有交付内容时进行测试。”X模型包含了测试设计的步骤，就象使用不同的测试工具所要包含的步骤一样，而V模型没有这么做。但是，Marick的例子提示，X模型在这层意义上看也并不是一个真的模型，取而代之的是，应该允许在任何时候选择使用测试设计步骤。

       Marick对V模型提出质疑，也因为V模型基于一套必须按照一定顺序严格排列的开发步骤，而这很可能并没有反映实际的实践过程。
尽管很多项目缺乏足够的需求，V模型还是从需求处理开始。V模型提示我们要对各开发阶段中已经得到的内容进行测试，但它没有规定我们要取得多少内容。如果没有任何的需求资料，开发人员知道他们要做什么吗？我主张在X模型和其它模型中都需要足够的需求并至少进行一次发布。虽然在没有模型的情况下也必须正常工作，但一个有效的模型，可以鼓励很多好的实践方法的采用。因此，V模型的一个强项是它明确的需求角色的确认，而X模型没有这么做，这大概是X模型的一个不足之处。

      Marick也质疑了单元测试和集成测试的区别，因为在某些场合人们可能会跳过单元测试而热衷于直接进行集成测试。Marick担心人们盲目地跟随“学院派的V模型”，按照模型所指导的步骤进行工作，而实际上某些做法并不切合实用。我已经尽自己的努力把Marick的关于需要很多具有可伸缩性的行为的期望结合进了X模型，这样，X模型并不要求在进行作为创建可执行程序（图中右上方）的一个组成部分的集成测试之前，对每一个程序片段都进行单元测试（图中左侧的行为）。但X模型没能提供是否要跳过单元测试的判断准则。

      X模型填补了V模型和W模型的缺陷，并可为测试人员和开发人员带来明显的帮助。

这篇文章详细介绍了测试里面所涉及到的模型，并加入自己对模型的看法，解释了模型的优缺点

                                                            

很多年轻或者刚刚从事测试工作的工程师，经常会问：“测试工程师需要什么技能或者具有什么素质才是合格的？”与开发人员相比，测试人员不但需要一技之长，还需要掌握诸如操作系统、数据库、网络等多方面的知识。
经过这几年的发展，国内IT公司的测试水平有了很大的提高，但是与此同时，很多测试工程师也迎来了个人的发展瓶颈：很多人从测试工程师做到了测试经理的职位，不知道下一步如何发展；或者每天机械地从事着功能测试工作。
根据作者多年的经验，一个有竞争力的测试人员要具有下面三个方面的素质：
1.         计算机专业技能
计算机领域的专业技能是测试工程师应该必备的一项素质，是做好测试工作的前提条件。尽管没有任何IT背景的人也可以从事测试工作，但是一名要想获得更大发展空间或者持久竞争力的测试工程师，则计算机专业技能是必不可少的。计算机专业技能主要包含三个方面：
l         测试专业技能
现在软件测试已经成为一个很有潜力的专业。要想成为一名优秀的测试工程师，首先应该具有扎实的专业基础，这也是本书的编写目的之一。因此，测试工程师应该努力学习测试专业知识，告别简单的“点击”之类的测试工作，让测试工作以自己的专业知识为依托。
测试专业知识很多，本书内容主要以测试人员应该掌握的基础专业技能为主。测试专业技能涉及的范围很广：既包括黑盒测试、白盒测试、测试用例设计等基础测试技术，也包括单元测试、功能测试、集成测试、系统测试、性能测试等测试方法，还包括基础的测试流程管理、缺陷管理、自动化测试技术等知识。
l         软件编程技能
“测试人员是否需要编程？”可以说是测试人员最常提出的问题之一。实际上，由于在我国开发人员待遇普遍高于测试人员，因此能写代码的几乎都去做开发了，而很多人则是因为做不了开发或者不能从事其它工作才“被迫”从事测试工作。最终的结果则是很多测试人员只能从事相对简单的功能测试，能力强一点的则可以借助测试工具进行简单的自动化测试（主要录制、修改、回放测试脚本）。
软件编程技能实际应该是测试人员的必备技能之一，在微软，很多测试人员都拥有多年的开发经验。因此，测试人员要想得到较好的职业发展，必须能够编写程序。只有能给编写程序，才可以胜任诸如单元测试、集成测试、性能测试等难度较大的测试工作。
此外，对软件测试人员的编程技能要求也有别于开发人员：测试人员编写的程序应着眼于运行正确，同时兼顾高效率，尤其体现在与性能测试相关的测试代码编写上。因此测试人员要具备一定的算法设计能力。依据作者的经验，测试工程师至少应该掌握Java、C#、C++之类的一门语言以及相应的开发工具。
l         网络、操作系统、数据库、中间件等知识：
与开发人员相比，测试人员掌握的知识具有“博而不精”的特点，“艺多不压身”是个非常形象的比喻。由于测试中经常需要配置、调试各种测试环境，而且在性能测试中还要对各种系统平台进行分析与调优，因此测试人员需要掌握更多网络、操作系统、数据库等知识。
在网络方面，测试人员应该掌握基本的网络协议以及网络工作原理，尤其要掌握一些网络环境的配置，这些都是测试工作中经常遇到的知识。
操作系统和中间件方面，应该掌握基本的使用以及安装、配置等。例如很多应用系统都是基于Unix、linux来运行的，这就要求测试人员掌握基本的操作命令以及相关的工具软件。而WebLogic、Websphere等中间件的安装、配置很多时候也需要掌握一些。
数据库知识则是更应该掌握技能，现在的应用系统几乎离不开数据库。因此不但要掌握基本的安装、配置，还要掌握SQL。测试人员至少应该掌握Mysql、MS Sqlserver、Oracle等常见数据库的使用。
作为一名测试人员，尽管不能精通所有的知识，但要想做好测试工作，应该尽可能地去学习更多的与测试工作相关的知识。
2.         行业知识
行业主要指测试人员所在企业涉及的行业领域，例如很多IT企业从事石油、电信、银行、电子政务、电子商务等行业领域的产品开发。行业知识即业务知识，是测试人员做好测试工作的又一个前提条件，只有深入地了解了产品的业务流程，才可以判断出开发人员实现的产品功能是否正确。
很多时候，软件运行起来没有异常，但是功能不一定正确。只有掌握了相关的行业知识，才可以判断出用户的业务需求是否得到了实现。
行业知识与工作经验有一定关系，通过时间即可以完成积累。
3.         个人素养[1]
作为一名优秀的测试工程师，首先要对测试工作有兴趣：测试工作很多时候都是显得有些枯燥的，因此热爱测试工作，才更容易做好测试工作。因此，除了具有前面的专业技能和行业知识外，测试人员应该具有一些基本的个人素养，即下面的“五心”。
专心：主要指测试人员在执行测试任务的时候要专心，不可一心二用。经验表明，高度集中精神不但能够提高效率，还能发现更多的软件缺陷，业绩最棒的往往是团队中做事精力最集中的那些成员。
细心：主要指执行测试工作时候要细心，认真执行测试，不可以忽略一些细节。某些缺陷如果不细心很难发现，例如一些界面的样式、文字等。
耐心：很多测试工作有时候显得非常枯燥，需要很大的耐心才可以做好。如果比较浮躁，就不会做到“专心”和“细心”，这将让很多软件缺陷从你眼前逃过。
责任心：责任心是做好工作必备的素质之一，测试工程师更应该将其发扬光大。如果测试中没有尽到责任，甚至敷衍了事，这将会把测试工作交给用户来完成，很可能引起非常严重的后果。
自信心：自信心是现在多数测试工程师都缺少的一项素质，尤其在面对需要编写测试代码等工作的时候，往往认为自己做不到。要想获得更好的职业发展，测试工程师们应该努力学习，建立能“解决一切测试问题”的信心。
“五心”只是做好测试工作的基本要求，测试人员应该具有的素质还很多。例如测试人员不但要具有团队合作精神，而且应该学会宽容待人，学会去理解“开发人员”，同时要尊重开发人员的劳动成果——开发出来的产品。

转自：http://blog.csdn.net/raul_177/archive/2007/03/07/1523199.aspx

测试新手进来看一下！新鲜出炉测试知识索引！

http://bbs.51testing.com/viewthread.php?tid=34811

http://bbs.51testing.com/viewthread.php?tid=22322&highlight=%D0%C2%CA%D6%B1%D8%BF%B4%A1%B6%D7%D4%B6%AF%BB%AF%B2%E2%CA%D4%B9%A4%BE%DF%BD%E9%C9%DCLR%C6%AA%A1%B7

http://bbs.51testing.com/viewthread.php?tid=96652&highlight=%B2%E2%CA%D4%B9%A4%B3%CC%CA%A6%B9%A4%D7%F7%C1%F7%B3%CC%B8%C5%C2%DB

 

http://bbs.51testing.com/viewthread.php?tid=42387&highlight=%D2%BB%B8%F6%C8%ED%BC%FE%B2%E2%CA%D4%B9%A4%B3%CC%CA%A6%B5%C4%D1%A7%CF%B0%CC%E5%D1%E9

软件测试职业规划｛阳光原创｝

    由于编码小知识出到第三帖，特此帖送出API手册一份，想要会自动化，还离不开Win32 API。
    先说下小编对关于Web内存的一些小看法，之前已经有讨论过关于IE内存占用居高不下，导致了QTP对Web页面的操作出现种种问题。今天和大家说下简单的内存释放方法。首先我们使用的将浏览器最小化然后再做最大化的操作来实现这个释放工作。很多人知道，IE最小化后，内存占用不到2M，最大化后，会比之前最小化前占的内存更少。
    先看下下面的代码,因为QTP中对Browser没有提供最小化的方法，因此我们需要借助window的中的方法：
    hwnd=borwser("...").getroproperty("hwnd")
    window("hwnd:="&hwnd).Minimize
    wait(1)
    window("hwnd:="&hwnd).Maximize
   
    看完小编的这4句代码，很高兴，哇，就这么简单？！慢着，你丢进QTP里面运行看看。打开任务管理器，注意，你可以把wait的时间调长点，你可以看到，原来内存居然是有增无减？然后愤怒的拿着砖头丢过来。
    至于为什么使用了Minimize的方法后仍然无效，这个小编猜想是因为QTP本身并没有真正意义上的最小化。好了，说了哪么多，先来个真的可以做到释放内存的，再看看下面代码：
   Public Function QTP_Release_Memory(hwnd)
        Extern.Declare micVoid ,"SendMessageA","user32.dll","SendMessageA",micHwnd,micInteger,micInteger,micInteger
        SC_MINIMIZE = &HF020&
        SC_MAXIMIZE = &HF030&
        WM_SYSCOMMAND = &H112
        Extern.SendMessageA hwnd,WM_SYSCOMMAND,SC_MINIMIZE,0
        wait 1
        Extern.SendMessageA hwnd,WM_SYSCOMMAND,SC_MAXIMIZE,0
   End Function
     大家会问，你怎么要用Function呢，小编这人比较环保，东西能重用就重用，大家只要把窗口的句柄丢给Function就可以用了，以后都可以在同个项目中用到，下次有时间和大家说说如何把脚本写得重用性更高些。
     这个主要是使用的是Win32API的方法，用SendMessage的方法去实现了最大化最小化。在这里小编偷偷告诉大家，SendMessage称得上是Win32 API中最强的一个，它几乎可以模拟所有的你想要的操作，至于真的有多强大，你下载小编给你们的文档看看它的所谓参数就知道。

文章转自http://bbs.51testing.com/viewthread.php?tid=128494

   在实际的性能测试中，经常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户数”，下面用一个实际的例子来说明它们之间的差别。

　　假设有一个OA系统，该系统有2000个使用用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“ 在线统计”功能（系统用一个全局变量记数所有已登录的用户），从在线统计功能中可以得到，最高峰时有500人在线（这个500就是一般所说的“同时在线人数”），那么，系统的并发用户数是多少呢？

　　根据我们对业务并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。当然，500这个数值只是表明在最高峰时刻有500个用户登录了系统，并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如，在这500个“同时使用系统”的用户中，考察某一个时间点，在这个时间上，假设其中40%的用户在较有兴致地看系统公告（注意：“看”这个动作是不会对服务端产生任何负担的），20%的用户在填写复杂的表格（对用户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写过程是不对服务端构成压力的），20%部分用户在发呆（也就是什么也没有做），剩下的 20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。因此，从上面的例子中可以看出，服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。

　　在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。

　　（1） 计算平均的并发用户数： C = nL/T

　　（2） 并发用户数峰值： C’ ≈ C+3根号C

　　公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。

　　公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。

　　实例：

　　假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。

　　则根据公式（1）和公式（2），可以得到：

　　C = 400*4/8 = 200

　　C’≈200+3*根号200 = 242

文章转自http://www.51testing.com/?action_viewnews_itemid_93935.html

1、test strategy与test plan的区别

   test strategy 用来表述如何测试软件系统，如何确定软件系统的测试级别和测试重点。实际项目中，单元测试、集成测试、功能测试、系统测试、验收测试等阶段的测试活动都要有不同的测试策略。拿集成测试阶段来说，可以采用自顶向下和自底向上的混合策略完成测试任务。test plan 要求用系统的方法来保障测试任务的顺利完成。包括测试任务的分配，测试资源的分配，测试策略和测试范围的确定，测试用例的设计方法，通过/失败准则的确定，测试风险的评估，日程安排等方面的内容。

2、backend测试

   可以理解为数据库测试。通过GUI键入的数据会被存储在后台数据库中，或者说数据作为记录存储在数据库的数据表中。因此，backend测试不仅要求通过GUI键入的数据被恰当地，正确地存储在后台数据库中，还要求通过GUI调用的这些数据(记录)能够被正确的显示出来。通过上述分析后，楼主的疑虑不难被消除了。

3、UI测试

   那些用例可以作为我们平时UI测试时的参考，但是不提倡生搬硬套。平时的UI测试要根据UI的特征来进行CASE的设计。这些特征包括符合通用的标准和规范，正确性，一致性，舒适性，直观性等等。

4、冒险测试

   BVT也可以被看作冒烟测试。BVT测试具备下面这些特点：它只是测试人员进行全面测试前的一个测试子集，用来验证软件系统主要的功能是否完好；BVT是一种类型的回归测试，在软件每次有新的build版本时进行；测试时间短，不会超过30分钟；BVT的用例要能覆盖软件基本功能；每天有新的build版本时，都要进行BVT。明白了这些，相信楼主的疑惑也是可以取消的。

5、功能测试和系统测试

   是两码事，功能测试主要是验证软件功能的实现情况，不考虑非功能性问题。而系统测试则是在更广的范围内进行的测试，包括：功能测试、安全测试、容量测试、安装测试、压力测试等等方面。所以即使执行了全部的功能方面的用例，也是无法完成系统测试的。

6、build和release版本

   软件发布前的版本都是build版本，这个阶段的版本是不断发现bug，不断解决bug，不断完善软件的过程。真正向用户发布的版本是release版本，也是软件的最终版本。

7、Use Case\需求文档

  只是描述了软件系统的功能而已，并没有提供功能实现的细节。Use Cases是捕获用户需求的非常有效的机制。通过Use Cases 用户可以看到系统提供的功能，知道自己需要什么样的功能，进而生成用户需求文档。用户接口设计文档应该满足用户需求。补充: Use Case只是描述了系统的功能是怎样的，用户需求里面可能还会关注到系统性能。所以三者的关系不能简单理解为逐步细化。

本文章转自http://bbs.testage.net/thread-48374-1-1.html

   计算机软件是基于计算机系统的一个重要组成部分，软件开发完毕后应与系统中其它成分集成在一起，此时需要进行一系列系统集成和确认测试。对这些测试的详细讨论已超出软件工程的范围，这些测试也不可能仅由软件开发人员完成。在系统测试之前，软件工程师应完成下列工作：
　　（1） 为测试软件系统的输入信息设计出错处理通路；
　　（2） 设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助；
　　（3） 参与系统测试的规划和设计，保证软件测试的合理性。　　系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能政党工作并完成所赋予的任务。下面简单讨论几类系统测试。
１、恢复测试
　　恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。
２、安全测试
　　安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，①想方设法截取或破译口令；②专门定做软件破坏系统的保护机制；③故意导致系统失败，企图趁恢复之机非法进入；④试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。
３、强度测试
　　强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如，①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②定量地增长数据输入率，检查输入子功能的反映能力；③运行需要最大存储空间（或其他资源）的测试用例；④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。
４、 性能测试
　　对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。

软件测试术语表

LCSAJ－－线性代码顺序和跳转（Linear Code Sequence And Jump）
包含三个部分：可执行语句线性顺序的起始，线性顺序的结束，在线性顺序结束处控制流跳转的目标语句。

LCSAJ coverage－－LCSAJ覆盖
在组件中被测试执行到的LCSAJ的百分比。

LCSAJ testing－－LCSAJ测试
根据LCSAJ设计测试用例的一种技术。

Load Testing－－负载测试
通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。

logic analysis－－逻辑分析
（1）评价软件设计的关键安全方程式、算法和控制逻辑的方法；
（2）评价程序操作的顺序并且检测可能导致灾难的错误。

logic-coverage testing－－逻辑覆盖测试
参考结构化测试用例设计（structural test case design）

maintainability－－可维护性
一个软件系统或组件可以被修改的容易程度，这个修改一般是因为缺陷纠正、性能改进或特性增加引起的。

maintainability testing－－可维护性测试
测试系统是否满足可维护性目标。

modified condition/decision coverage－－修改条件/判定覆盖
在组件中被测试执行到的修改条件/判定的百分比。

modified condition/decision testing －－修改条件/判定测试
根据MC/DC设计测试用例的一种技术。

Monkey Testing－－跳跃式测试
随机性，跳跃式的测试一个系统，以确定一个系统是否会崩溃。

MTBF－－平均失效间隔实际（mean time between failures）
两次失效之间的平均操作时间。

MTTF－－平均失效时间 （mean time to failure）
第一次失效之前的平均时间

MTTR－－平均修复时间（mean time to repair）
两次修复之间的平均时间

multiple condition coverage－－多条件覆盖
参考分支条件组合覆盖（branch condition combination coverage）

mutation analysis－－变体分析
一种确定测试用例套完整性的方法，该方法通过判断测试用例套能够区别程序与其变体之间的程度。

Negative Testing－－逆向测试/反向测试/负面测试
测试瞄准于使系统不能工作。

non-functional requirements testing－－非功能性需求测试
与功能不相关的需求测试，如：性能测试、可用性测试等。

N-switch coverage－－N切换覆盖
在组件中被测试执行到的N转换顺序的百分比。

N-switch testing－－N切换测试
根据N转换顺序设计测试用例的一种技术，经常用于状态转换测试中。

N-transitions－－N转换
N＋1转换顺序

operational testing－－可操作性测试
在系统或组件操作的环境中评价它们的表现。

output domain－－输出域
所有可能输出的集合。

partition testing－－分类测试
参考等价划分测试（equivalence partition testing）

path－－路径
一个组件从入口到出口的一条可执行语句顺序。

path coverage－－路径覆盖
在组件中被测试执行到的路径的百分比。

path sensitizing－－路径敏感性
选择一组输入值强制组件走一个给定的路径。

path testing－－路径测试
根据路径设计测试用例的一种技术，经常用于状态转换测试中。

performance testing－－性能测试
评价一个产品或组件与性能需求是否符合的测试。

portability testing－－可移植性
测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。

Positive Testing－－正向测试
测试瞄准于显示系统能够正常工作。

precondition－－预置条件
环境或状态条件，组件执行之前必须被填充一个特定的输入值。

predicate－－谓词
一个逻辑表达式，结果为‘真’或‘假’。

predicate data use－－谓词数据使用
在谓词中的一个数据使用。

program instrumenter－－程序插装
参考插装（instrumenter）

progressive testing－－递进测试
在先前特性回归测试之后对新特性进行测试的一种策略。

pseudo-random－－伪随机
看似随机的，实际上是根据预先安排的顺序进行的。

QA－－质量保证（quality assurance）
（1）已计划的系统性活动，用于保证一个组件、模块或系统遵从已确立的需求；
（2）采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

QC－－质量控制（quality control）
用于获得质量需求的操作技术和过程，如测试活动。

Race Condition－－竞争状态
并行问题的根源。对一个共享资源的多个访问，至少包含了一个写操作，但是没有一个机制来协调同时发生的访问。

recovery testing－－恢复性测试
验证系统从失效中恢复能力的测试。

regression analysis and testing－－回归分析和测试
一个软件验证和确认任务以确定在修改后需要重复测试和分析的范围。

Regression Testing－－回归测试
在发生修改之后重新测试先前的测试以保证修改的正确性。

release－－发布
一个批准版本的正式通知和分发。

reliability－－可靠性
一个系统或组件在规定的条件下在指定的时间内执行其需要功能的能力。

reliability assessment－－可靠性评价
确定一个已有系统或组件的可靠性级别的过程。

requirements-based testing－－基于需求的测试
根据软件组件的需求导出测试用例的一种设计方法。

review－－评审
在产品开发过程中，把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

risk－－风险
不期望效果的可能性和严重性的一个度量。

risk assessment－－风险评估
对风险和风险影响的一个完整的评价。

safety－－（生命）安全性
不会引起人员伤亡、产生疾病、毁坏或损失设备和财产、或者破坏环境。

safety critical－－严格的安全性
一个条件、事件、操作、过程或项，它的认识、控制或执行对生命安全性的系统来说是非常关键的。

Sanity Testing－－理智测试
软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考冒烟测试

SDP－－软件开发计划（software development plan）
用于一个软件产品开发的项目计划。

security testing－－安全性测试
验证系统是否符合安全性目标的一种测试。

security.－－（信息）安全性
参考计算机系统安全性（computer system security）

serviceability testing－－可服务性测试
参考可维护性测试（maintainability testing）

simple subpath－－简单子路径
控制流的一个子路径，其中没有不必要的部分被执行。

simulation－－模拟
使用另一个系统来表示一个物理的或抽象的系统的选定行为特性。

simulation－－模拟
使用一个可执行模型来表示一个对象的行为。

simulator－－模拟器
软件验证期间的一个设备、软件程序、或系统，当它给定一个控制的输入时，表现的与一个给定的系统类似。

SLA－－服务级别协议（service level agreement）
服务提供商与客户之间的一个协议，用于规定服务提供商应当提供什么服务。

Smoke Testing－－冒烟测试
对软件主要功能进行快餐式测试。最早来自于硬件测试实践，以确定新的硬件在第一次使用的时候不会着火。

software development process－－软件开发过程
一个把用户需求转换为软件产品的开发过程。

software diversity－－软件多样性
一种软件开发技术，其中，由不同的程序员或开发组开发的相同规格的不同程序，目的是为了检测错误、增加可靠性。

software element－－软件元素
软件开发或维护期间产生或获得的一个可交付的或过程内的文档。

software engineering－－软件工程
一个应用于软件开发、操作和维护的系统性的、有纪律的、可量化的方法。

software engineering environment－－软件工程环境
执行一个软件工程工作的硬件、软件和固件。

software life cycle－－软件生命周期
开始于一个软件产品的构思，结束于该产品不再被使用的这段期间。

SOP－－标准操作过程（standard operating procedures）
书面的步骤，这对保证生产和处理的控制是必须的。

source code－－源代码
用一种适合于输入到汇编器、编译器或其它转换设备的计算机指令和数据定义。

source statement－－源语句
参考语句（statement）

specification－－规格
组件功能的一个描述，格式是：对指定的输入在指定的条件下的输出。

specified input－－指定的输入
一个输入，根据规格能预知其输出。

spiral model －－螺旋模型
软件开发过程的一个模型，其中的组成活动，典型的包括需求分析，概要设计，详细设计，编码，集成和测试等活动被迭代的执行直到软件被完成。

SQL－－结构化查询语句（structured query language）
在一个关系数据库中查询和处理数据的一种语言。

state－－状态
一个系统、组件或模拟可能存在其中的一个条件或模式。

state diagram－－状态图
一个图形，描绘一个系统或组件可能假设的状态，并且显示引起或导致一个状态切换到另一个状态的事件或环境。

state transition－－状态转换
一个系统或组件的两个允许状态之间的切换。

state transition testing －－状态转换测试
根据状态转换来设计测试用例的一种方法。

statement－－语句
程序语言的一个实体，是典型的最小可执行单元。

statement coverage－－语句覆盖
在一个组件中，通过执行一定的测试用例所能达到的语句覆盖百分比。

statement testing－－语句测试
根据语句覆盖来设计测试用例的一种方法。

Static Analysis－－静态分析
分析一个程序的执行，但是并不实际执行这个程序。

Static Analyzer－－静态分析器
进行静态分析的工具。

Static Testing－－静态测试
不通过执行来测试一个系统。

statistical testing－－统计测试
通过使用对输入统计分布进行分析来构造测试用例的一种测试设计方法。

stepwise refinement－－逐步优化
一个结构化软件设计技术，数据和处理步骤首先被广泛的定义，然后被逐步的进行了细化。

storage testing－－存储测试
验证系统是否满足指定存储目标的测试。

Stress Testing－－压力测试
在规定的规格条件或者超过规定的规格条件下，测试一个系统，以评价其行为。类似负载测试，通常是性能测试
的一部分。

structural coverage－－结构化覆盖
根据组件内部的结构度量覆盖率。

structural test case design－－结构化测试用例设计
根据组件内部结构的分析来设计测试用例的一种方法。

structural testing－－结构化测试
参考结构化测试用例设计（structural test case design）

structured basis testing－－结构化的基础测试
根据代码逻辑设计测试用例来获得100％分支覆盖的一种测试用例设计技术。

structured design－－结构化设计
软件设计的任何遵循一定纪律的方法，它按照特定的规则，例如：模块化，有顶向下设计，数据逐步优化，系统结构和处理步骤。

structured programming－－结构化编程
在结构化程序开发中的任何包含结构化设计和结果的软件开发技术。

structured walkthrough－－结构化走读
参考走读（walkthrough）

stub－－桩
一个软件模块的框架或特殊目标实现，主要用于开发和测试一个组件，该组件调用或依赖这个模块。

symbolic evaluation－－符号评价
参考符号执行（symbolic execution）

symbolic execution－－符号执行
通过符号表达式来执行程序路径的一种静态分析设计技术。其中，程序的执行被用符号来模拟，例如，使用变量名而不是实际值，程序的输出被表示成包含这些符号的逻辑或数学表达式。

symbolic trace－－符号轨迹
一个计算机程序通过符号执行是经过的语句分支结果的一个记录。

syntax testing－－语法分析
根据输入语法来验证一个系统或组件的测试用例设计技术。

system analysis－－系统分析
对一个计划的或现实的系统进行的一个系统性调查以确定系统的功能以及系统与其它系统之间的交互。

system design－－系统设计
一个定义硬件和软件构架、组件、模块、接口和数据的过程以满足指定的规格。

system integration－－系统集成
一个系统组件的渐增的连接和测试，直到一个完整的系统。

System Testing－－系统测试
从一个系统的整体而不是个体上来测试一个系统，并且该测试关注的是规格，而不是系统内部的逻辑。

technical requirements testing－－技术需求测试
参考非功能需求测试（non-functional requirements testing）

test automation－－测试自动化
使用工具来控制测试的执行、结果的比较、测试预置条件的设置、和其它测试控制和报告功能。

test case－－测试用例
用于特定目标而开发的一组输入、预置条件和预期结果。

test case design technique－－测试用例设计技术
选择和导出测试用例的技术。

test case suite－－测试用例套
对被测软件的一个或多个测试用例的集合。

test comparator－－测试比较器
一个测试工具用于比较软件实际测试产生的结果与测试用例预期的结果。

test completion criterion－－测试完成标准
一个标准用于确定被计划的测试何时完成。

test coverage－－测试覆盖
参考覆盖率（Coverage）

test driver－－测试驱动
一个程序或测试工具用于根据测试套执行软件。

test environment－－测试环境
测试运行其上的软件和硬件环境的描述，以及任何其它与被测软件交互的软件，包括驱动和桩。

test execution－－测试执行
一个测试用例被被测软件执行，并得到一个结果。

test execution technique－－测试执行技术
执行测试用例的技术，包括手工、自动化等。

test generator－－测试生成器
根据特定的测试用例产生测试用例的工具。

test harness－－测试用具
包含测试驱动和测试比较器的测试工具。

test log－－测试日志
一个关于测试执行所有相关细节的时间记录。

test measurement technique－－测试度量技术
度量测试覆盖率的技术。

Test Plan－－测试计划
一个文档，描述了要进行的测试活动的范围、方法、资源和进度。它确定测试项、被测特性、测试任务、谁执行任务，并且任何风险都要冲突计划。

test procedure－－测试规程
一个文档，提供详细的测试用例执行指令。

test records－－测试记录
对每个测试，明确的记录被测组件的标识、版本，测试规格，和实际结果

test report－－测试报告
一个描述系统或组件执行的测试和结果的文档。

Test scrīpt－－测试脚本
一般指的是一个特定测试的一系列指令，这些指令可以被自动化测试工具执行。

Test Specification－－测试规格
一个文档，用于指定一个软件特性、特性组合或所有特性的测试方法、输入、预期结果和执行条件。

test strategy－－测试策略
一个简单的高层文档，用于描述测试的大致方法，目标和方向。

test suite－－测试套
测试用例和/或测试脚本的一个集合，与一个应用的特定功能或特性相关。

test target－－测试目标
一组测试完成标准。

testability－－可测试性
一个系统或组件有利于测试标准建立和确定这些标准是否被满足的测试执行的程度。

Testing－－测试
IEEE给出的定义是：1）一个执行软件的过程，以验证其满足指定的需求并检测错误；
                  2）一个软件项的分析过程以检测已有条件之间的不同，并评价软件项的特性。

thread testing－－线程测试
自顶向下测试的一个变化版本，其中，递增的组件集成遵循需求子集的实现。

time sharing－－时间共享
一种操作方式，允许两个或多个用户在相同的计算机系统上同时执行计算机程序。其实现可能通过时间片轮转、优先级中断等。

top-down design－－由顶向下设计
一种设计策略，首先设计最高层的抽象和处理，然后逐步向更低级别进行设计。

top-down testing－－自顶向下测试
集成测试的一种策略，首先测试最顶层的组件，其它组件使用桩，然后逐步加入较低层的组件进行测试，直到所有组件被集成到系统中。

traceability－－可跟踪性
开发过程的两个或多个产品之间关系可以被建立起来的程度，尤其是产品彼此之间有一个前后处理关系。

traceability analysis－－跟踪性分析
（1）跟踪概念文档中的软件需求到系统需求；
（2）跟踪软件设计描述到软件需求规格，以及软件需求规格到软件设计描述；
（3）跟踪源代码对应到设计规格，以及设计规格对应到源代码。分析确定它们之间正确性、一致性、完整性、精确性的关系。

traceability matrix－－跟踪矩阵
一个用于记录两个或多个产品之间关系的矩阵。例如，需求跟踪矩阵是跟踪从需求到设计再到编码的实现。

transaction－－事务/处理
（1）一个命令、消息或输入记录，它明确或隐含的调用了一个处理活动，例如更新一个文件；
（2）用户和系统之间的一次交互；
（3）在一个数据库管理系统中，完成一个特定目的的处理单元，如恢复、更新、修改或删除一个或多个数据元素。

transform analysis－－事务分析
系统的结构是根据分析系统需要处理的事务获得的一种分析技术。

trojan horse－－特洛伊木马
一种攻击计算机系统的方法，典型的方法是提供一个包含具有攻击性隐含代码的有用程序给用户，在用户执行该程序的时候，其隐含的代码对系统进行非法访问，并可能产生破坏。

truth table－－真值表
用于逻辑操作的一个操作表格。

Unit Testing－－单元测试
测试单个的软件组件，属于白盒测试范畴，其测试基础是软件内部的逻辑。

Usability Testing－－可用性测试
测试用户使用和学习产品的容易程度。

validation－－确认
根据用户需要确认软件开发的产品的正确性。

verification－－验证
评价一个组件或系统以确认给定开发阶段的产品是否满足该阶段开始时设定的标准。

version－－版本
一个软件项或软件元素的一个初始发布或一个完整的再发布。

volume testing－－容量测试
使用大容量数据测试系统的一种策略。

Walkthrough－－走读
一个针对需求、设计或代码的非正式的同行评审，一般由作者发起，由作者的同行参与进行的评审过程。

waterfall model－－瀑布模型
软件开发过程模型的一种，包括概念阶段、需求阶段、设计阶段、实现阶段、测试阶段、安装和检查阶段、操作和维护阶段，这些阶段按次序进行，可能有部分重叠，但很少会迭代。

White Box Testing－－白盒测试
根据软件内部的工作原理分析来进行测试。