日历
| |||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | ||||||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
| 12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
| 19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
| 26 | 27 | 28 | 29 | 30 | 31 | ||||
搜索标题
统计信息
- 访问量: 4435
- 日志数: 21
- 图片数: 2
- 文件数: 1
- 建立时间: 2008-04-20
- 更新时间: 2008-05-06
RSS订阅
朋友皆兄弟
我的最新日志
-
软件缺陷管理新法详解
2008-5-06
通常大家发现软件缺陷时会对软件缺陷进行分类，可分类的方式只有一种，就是严重极别,难道没有其它的分法吗。比如我们碰到下面这种情况，测试人员发现有一种功能是必需加入进去的，这时他与程序员说，程序员说没有时间或是不必要，这时这种情况则会形成两者的扯皮，最终的结果也就不了了知了，这样会戳伤了测试人员的积极性，下次他们再也不会尽心的考虑产品的问题，只要可以运行就可以了。其实这种情况是可以解决的,下面我会提到一个新的软件缺陷分类概念，从而有效的解决这个问题。在软件缺陷中不仅仅只是严重极别，更多的则是功能没有做到。说到这里也许大家都理解了，就是需求没有考虑到，可需求不会一次就很完美的，需要大家的共同努力，来不断的完善。那么怎样才能让测试人员提出的好的建议得到有效的执行？这就是我下面想说的。
在软件缺陷中还有一种分法，跟据缺陷内容来分，主要分为需求Bug与程序Bug，对于这种分法的好处就是明确了Bug处理的责任人。对于程序Bug我们都知道是由相关开发人员进行处理。下面主要讨论一下需求 Bug,需求Bug从名称上来就知道是要交由需求人员进行处理，可怎么处理，怎样在处理的过程中有效的让这些创意得到体现。现在我们都有Bug管理系统，这时我们的测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理，不过这里我想强调的是对需求Bug的定位，如果这个Bug在软件需求说明书中明确提到了，这时就不可能定位它为需求Bug，它是必需让程序员实现的，称为软件功能缺陷，提交由程序员进行处理。但如果需求说明书没有明确提到的，我们则可以定位为需求
这样处理有以下好处，首先需求Bug再不象以前，没有人进行确认，需求的处理人员本来就是需求人员，由他们确认与跟踪是最好不过的，因为他们对需求有绝对的权威。同时测试人员其实就是最早的用户，他们的需求就是用户的需求，这种方法加强了需求人员与测试人员的沟通，使需求得到有效的补充，从而让产品更加完善。还有测试人员从本质上来说与程序员还是对立的，这里如果为了这样一个不是软件本身问题的问题形成与开发人员的对立，则会出现赢得战役而丢失整个战争的情况，测试人员协调好与开发人员的关系，让他们更有效的对软件本身的缺陷形成有效的关注是最好的。还有最为关键的一点，测试人员的激情是最重要的，如果他们的想法没有得到体现，这时会渐渐的失去对测试的兴趣，从而软件的质量则会无法得到保证，通过这种方法可以让他们看到自己的建议可以通过对需求人员的反映得到实现，让他们时时觉得自己的想法是可以通过这种方法来有效的推行，这样工作的积极性才会有保障。
不过从实施的角度来说，还是有一定的困难的，首先要让大家改变以前那种凡是Bug就是由开发人员负责的观念，其次需求人员的工作量是要加大的，不过广泛的了解需求是他们的本份工作，想来不会很困难，还有必需要有有效的Bug管理工具，比如BugManage等等，不要出现那种对需求人员说了，可过两天就忘的情况出现，这时需求Bug的生命周期会出现跨越两个软件开发周期，因为有些需求会在下一版实现，这时测试人员需要延长对这些需求Bug的管理，不过我想这些需求是他们提出的，会有兴趣对这些Bug进行管理的。
-
软件测试自动化的具体做法
2008-4-28
因为软件测试的工作量很大（40% 到60% 的总开发时间），而又有很大部分适于自动化，因此，测试的改进会对整个开发工作的质量、成本和周期带来非常显著的效果。
首先，谈谈在测试自动化的情况下，带有图形界面的产品的测试用例的设计问题。因为图形界面的输出显示不是很容易做到测试结果自动化比较，所以一般的做法是把图形界面输出的部分单独建立测试用例，以手工运行。而所有非图形输出则可进行自动测试。
下面举出一些测试自动化的例子：
1.测试个案（test case ，或称为测试用例）的生成
用编程语言或更方便的剧本语言（scrīpt language 例如Perl等）写出短小的程序来产生大量的测试输入（包括输入数据与操作指令）。或同时也按一定的逻辑规律产生标准输出。输入与输出的文件名字按规定进行配对，以便控制自动化测试及结果核对的程序易于操作。
这里提到测试个案的命名问题，如果在项目的文档设计中作统一规划的话，软件产品的需求与功能的命名就应该成为后继开发过程的中间产品的命名分类依据。这样，就会为文档管理和配置管理带来很大的方便，使整个产品的开发过程变得更有条理，更符合逻辑。任何新手半途加入到开发工作中也会更容易进入状态。
2.测试的执行写控制
单元测试或集成测试可能多用单机运行。但对于系统测试或回归测试，就极有可能需要多台机在网络上同时运行。记住一个这样的原则，在开发过程中的任何时候，如果你需要等候测试的运行结果的话，那就是一个缩短开发时间的机会。
对于单个的测试运行，挖潜的机会在测试的设置及开始运行和结果的对比及显示。有时候，需要反复修改程序，重新汇编和重新测试。这样，每一个循环的各种手工键入的设置与指令所花费的时间，加起来就非常可观。如果能利用make或类似的软件工具来帮助，就能节省大量的时间。
对于系统测试或回归测试这类涉及大量测试个案运行的情况，挖潜的的机会除了利用软件工具来实现自动化之外，就是怎样充分利用一切硬件资源。往往，就算是在白天的工作时间内，每台计算机的负荷都没有被充分利用。能够把大量测试个案分配到各台机器上去同时运行，就能节省大量的时间。另外，把大量的系统测试及回归测试安排到夜间及周末运行，更能提高效率。
如果不购买商品化的工具的话，应当遵从正规的软件开发要求来开发出好的软件测试自动化工具。在实践中，许多企业自行开发的自动化工具都是利用一些现成的软件工具再加上自己写的程序而组成的。这些自己开发的工具完全是为本企业量身定做的，因此可用性非常强。同时，也能根据需要随时进行改进，而不必受制于人。当然，这就要求有一定的人力的投入。
在设计软件自动测试工具的时候，路径（path）控制是一个非常重要的功能。理想的使用情况是：这个工具可以在任何一个路径位置上运行，可以到任何路径位置去取得测试用例，同时也可以把测试的结果输出放到任何的路径位置上去。这样的设计，可以使不同的测试运行能够使用同一组测试用例而不至于互相干扰，也可以灵活使用硬盘的空间，并且使备份保存工作易于控制。
同时，软件自动测试工具必须能够有办法方便地选择测试用例库中的全部或部分来运行，也必须能够自由地选择被测试的产品或中间产品采作为测试对象。
3.测试结果与标准输出的对比
在设计测试用例的时候，必须考虑到怎样才能够易于对此测试结果和标准输出。输出数据量的多少及数据格式对比较的速度有直接影响。而另一方面，也必须考虑到输出数据与测试用例的测试目标的逻辑对应性及易读性，这将会大大有利于分析测试所发现的不吻合，也有利于测试用例的维护。
许多时候，要写一些特殊的软件来执行测试结果与标准输出的对比工作，因为可能有部分的输出内容是不能直接对比的（比如，对运行的日期时间的记录，对运行的路径的记录，以及测试对象的版本数据等），就要用程序进行处理。
4.不吻合的测试结果的分析、分类、记录和通报
上一点所谈到的，用于对测试结果与标准输出进行对比的特殊软件，往往也同时担任对不吻合的测试结果进行分析、分类、记录和通报的任务。
“分析”是找出不吻合的地方并指出错误的可能起因。“分类”包括各种统计上的分项，例如，对应的源程序的位置，错误的严重级别（提示、警告、非失效性错误、失效性错误；或别的分类方法），新发现的还是已有记录的错误，等等。“记录”，是按分类存档。“通报”，是主动地对测试的运行者及测试用例的“负责人”通报出错的信息。
这里提到测试用例的“负责人”的概念。是用以指定一个测试用例运行时发现的缺陷，由哪一个开发人员负责分析（有时是另外的开发人员引进的缺陷而导致的错误）及修复。在设立测试用例库时，各用例均应有指定的负责人。
最直接的通报方法是由自动测试软件发出电子邮件给测试运行者及测试用例负责人。邮件内容的详细程度可根据需要灵活决定。
5.总测试状况的统计，报表的产生
这些都是自动测试工具所应有的功能。目的是提高过程管理的质量，同时节省用于产生统计数据的时间。
产生出来的统计报表，最好是存放到一个约定的路径位置，以便任何有关人员都知道怎样查阅。同时，可按需要用电子邮件向适当的对象（如项目经理，测试经理和质量保证经理）寄出统计报表。
6.自动测试与开发中产品每日构建（build ）的配合
自动测试应该是整个开发过程中的一个有机部分。自动测试要依靠配置管理来提供良好的运行的环境，同时它必须要与开发中的软件的构建紧密配合。
在开发中的产品达到一定程度的时候，就应该开始进行每日构建和测试。这种做法能使软件的开发状态得到频繁的更新，以及及早发现设计和集成的缺陷。
为了充分利用时间与设备资源，下班之后进行自动的软件构建，紧接着进行自动测试（这里多数指的是系统测试或回归测试），是一个非常行之有效的方法。如果安排得好，到第二天上班时，测试结果就已经在各人的电子邮箱里面面了，等待着新的一天的开发工作。 -
测试中常见问题分析及对策
2008-4-28
我们一般把发现的错误bug(我们也称为缺陷defect)按严重性分为4类：
死机(系统崩溃或挂起)
致命(使系统不稳定、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的)
严重(系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果，如：显示不正确但输出正确)
一般(界面拼写错误或用户使用不方便)。
我们也把发现的错误按优先级分为三种：高、中、低：一般是越影响用户接受或使用该产品的错误优先级越高。
但下面，将不对所有的问题进行列举和分析，而只是列出一些显而易见的、容易被项目组忽略的错误，这些错误可能是容易修改的、或是容易避免的，但是对于测试组或用户来说可能却是非常头痛和不方便的。
形象类问题：---不专业、用户不信任
1、不符合用户操作习惯。如，快捷键定义不科学、不实用(键位分布不合理、按键太多，甚至没有快捷键)。
2、不够专业，缺乏基本知识，而又没有高手检查。
3、界面中英文混杂，经常弹出莫名其妙的信息，而且还拼错单词
4、SETUP界面：CopyRight 1994-1996；缺省认为用户使用某种分辨率；
5、说明书或帮助的排版格式不专业：中英文搭配不对、标点符号全角半角部分、没有排版准则…
6、程序名/路径名是程序员的名字、或没有安装程序、或安装程序不完善(丢掉一些必要的模块或文件)
7、界面元素参差不齐，文字不能完全显示，TAB时鼠标乱走。
可用性问题：---用户无法使用或不方便使用
"用户比开发或测试人员在接触界面上要花费更多时间。表面上不重要的方面的影响会变得越来越大，最终甚至会掩盖了产品得有用得方面。"
下面是一些用户界面错误的例子：
1、输入无合法性检查和值域检查，允许用户输入错误的数据类型，并导致不可逆料的后果
2、界面中的信息不能及时更新，不能正确反映数据状态，甚至对用户产生错误的误导。如：数据库中剩余记录个数；参数设置对话框中的预设值
下面是一些低效的用户界面的例子：
1、表达不清或过于模糊的信息提示
2、要求用户输入多余的、本来系统可以自己得到的数据。如：服务是否启动，安装后用户要手动修改某些配置文件。
3、为了达到某个设置或对话框，用户必须做许多冗余操作。如，对话框嵌套层次太多。
4、不能记忆用户的设置或操作习惯，用户每次进入都需要重新操作一次初始环境。
5、使用不完善的功能且不给用户以恰当的提示。
6、不经用户确认就对系统或数据进行重大修改
稳定性问题：---影响用户正常工作
1、不可重现的死机，或不断申请但不完全释放资源，系统性能越来越低
2、主系统和子系统使用同样的临界资源而互相不知道。如：使用同样的类名或临时文件名、使用同样的数据库字段名或登录帐号。
3、不能重现的错误，许多与代码中的未初始化变量(在Debug时一般是缺省初始化的)有关，有些与系统不检查异常情况(如内存申请不成功、网络突然中断或长时间没有响应)有关。
其他问题
1、文档匮乏：无标准；无新功能使用方法；无版本改动说明。我们不仅要认为没有说明文档的产品不是是一个完整的产品，也要认为没有说明或没有正确说明的功能是一个没有完全实现的功能，因为用户无法用得起来。
2、运行时不检查内存、数据库或硬盘空间等
3、无根据地假设用户环境：硬件/网络环境；有些动态库；安装程序换台机器不正确；假设网络随时都是连通的
4、提供的版本带病毒，或根本无法安装，或没有加密
5、提供Debug版本给测试组或测试用户，或项目组与测试组使用不同版本
6、用户现场开发和修改，又没有记录和保留
7、错误反复出现，改动得不彻底、或版本管理出现混乱
8、错误越改越多，改动得不彻底、或改动得不小心
9、版本中部分内容和接口倒退
10、有些选项永远是灰的；有些选项、菜单项在该灰时还不灰，并且还能状态显示
11、资源没有和代码分离，不同语言版本间不能平滑转换
12、缺少第三方产品的评估：广告管理系统2000年问题
13、产品配合不利，准备当作一套产品或方案推出，互相之间却各不负责，(没有整个项目负责人，是面向组织的而不是面向产品或方案的)。
期望项目组关注的一些问题
1、修改Bug的人考虑得不够周全，也可能是没有能力考虑周全---不懂全部程序
2、问题留给测试组去发现的心态----不仔细测试、不小心修改、甚至不全面改(不彻底)
3、自己不会用，不了解产品的用法。
4、更多地从用户使用的角度考虑设计、编码与测试 -
LoadRunner中Analysis 会话简介
2008-4-21
Analysis会话的目的是查找系统的性能故障，然后确定这些故障的根源。
1:是否满足了测试的预期目标？在负载下，用户终端的事务响应时间是多少？这些事务的平均事务响应时间是多少？
2:系统的哪些部分导致性能下降？该网络和服务器的响应时间是多少？
3:通过将事务时间和后端监控器矩阵关联起来，您是否能找到可能的原因？
在以下部分中，您将学习如何打开LoadRunner Analysis以及生成和查看图及报告，这将有助于您找出性能问题并确定该问题的根源。 -
LoadRunner Controller 简介
2008-4-21
负载测试指在典型的工作条件下测试应用程序，例如，多个旅行代理同时在相同的航班预订系统中预订航班。
测试用于模拟真实情况。为此，需要能够在应用程序上生成较重负载并计划应用负载的时间（因为用户不会正好在同一时间登录或注销）。还需要模拟各种不同的用户活动和行为。例如，某些用户可能使用Netscape（而不是Internet Explorer）来查看应用程序的性能，并且可能使用了不同的网络连接（例如，调制解调器、DSL或电缆）。您可以在场景中创建并保存这些设置。
Controller可以提供所有您需要的有助于创建并运行测试的工具，以准确地模拟您的工作环境。
场景目标
在本课中，目标是创建一个场景，用来模拟十个旅行代理同时登录系统、搜索航班、购买机票、查看路线和注销系统的行为。
启动 Controller
要开始创建场景，请打开Controller并创建一个新的场景。
1 打开Mercury LoadRunner。
选择“开始”>“程序”>“Mercury LoadRunner”>“LoadRunner”。将打开“Mercury LoadRunner Launcher”窗口。
2 打开Controller。
在“Load Testing”选项卡中，单击“Run Load Tests”。将打开LoadRunner Controller。
默认情况下，Controller打开时将显示“新建场景”对话框。
3 选择场景类型。
选择“手动场景”。
通过手动场景，可以控制正在运行的Vuser数量及其运行的时间，还可以测试应用程序可以同时运行的Vuser数。您可以使用百分比模式根据业务分析员指定的百分比在脚本间分配全部的Vuser。
面向目标的场景用于确定系统是否可以达到特定的目标。由您确定基于的目标，例如，指定的事务响应时间或每秒点击次数/事务数，并且LoadRunner将根据这些目标自动为您创建场景。您将在第9课“面向目标的高级场景”中创建面向目标的场景。 -
laodrunner虚拟用户生成器 (VuGen) 简介
2008-4-21
在测试环境中，LoadRunner会在物理计算机上用虚拟用户（即Vuser）代替实际用户。Vuser通过以可重复、可预测的方式模拟典型用户的操作，在系统上创建负载。
LoadRunner虚拟用户生成器(VuGen)采用录制并播放机制。当您在应用程序中按照业务流程操作时，VuGen将这些操作录制到自动脚本中，以便作为负载测试的基础。
注意：如果已经完成了Mercury LoadRunner快速入门，您将注意录制的脚本步骤与将在以下部分录制的脚本步骤相同。但是，整个录制过程将在此处进行更详细介绍。
-
软件测试种类名词解释(上)
2008-4-20
Client/Server 测试
Roger S. Pressman
通常，客户 / 服务器软件的测试发生在三个不同的层次：
（ 1 ）个体的客户端应用以 “ 分离的 ” 模式被测试 —— 不考虑服务器和底层网络的运行；
（ 2 ）客户端软件和关联的服务器端应用被一起测试，但网络运行不被明显的考虑；
（ 3 ）完整的 C/S 体系结构，包括网络运行和性能，被测试。
下面的测试方法是 C/S 应用中经常用到的：
应用功能测试 —— 客户端应用被独立地执行，以揭示在其运行中的错误。
服务器测试 —— 测试服务器的协调和数据管理功能，也考虑服务器性能（整体反映时间和数据吞吐量）。
数据库测试 —— 测试服务器存储的数据的精确性和完整性，检查客户端应用提交的事务，以保证数据被正确地存储、更新和检索。
事务测试 —— 创建一系列的测试以保证每类事务被按照需求处理。测试着重于处理的正确性，也关注性能问题。
网络通信测试 —— 这些测试验证网络节点间的通信正常地发生，并且消息传递、事务和相关的网络交通无错的发生。
回归测试
Roger S. Pressman
每当一个新的模块被当作集成测试的一部分加进来的时候，软件就发生了改变。新的数据流路径建立起来，新的 I/O 操作可能也会出现，还有可能激活了新的控制逻辑。这些改变可能会使原本工作得很正常的功能产生错误。在集成测试策略的环境中，回归测试是对某些已经进行过的测试的某些子集再重新进行一遍，以保证上述改变不会传播无法预料的副作用。
在更广的环境里，（任何种类的）成功测试结果都是发现错误，而错误是要被修改的，每当软件被修改的时候，软件配置的某些方面（程序、文档、或者数据）也被修改了，回归测试就是用来保证（由于测试或者其他原因的）改动不会带来不可预料的行为或者另外的错误。
回归测试可以通过重新执行所有的测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具来进行。捕获回放工具使得软件工程师能够捕获到测试用例，然后就可以进行回放和比较。
回归测试集（要进行的测试的子集）包括三种不同类型的测试用例：
· 能够测试软件的所有功能的代表性测试用例。
· 专门针对可能会被修改影响的软件功能的附加测试。
· 针对修改过的软件成分的测试。
在集成测试进行的过程中，回归测试可能会变得非常庞大。因此，回归测试应当设计为只对出现错误的模块的主要功能进行测试，每当进行一个修改时，就对每一个程序功能都重新执行所有的测试是不实际的而且效率很低的。
α 测试
α 测试是由一个用户在开发环境下进行的测试，也可以是开发机构枘部的用户在模拟实际操作环境下进行的测试。软件在一个自然设置状态下使用。开发者坐在用户旁边，随时记下错误情况和使用中的问题。这是在受控制的环境下进行的测试，
α 测试的目的是评价软件产品的 FLURPS( 即功能、局域化、可使用性、可靠性、性能和支持 ) 。尤其注重产品的界面和特色。 α 测试人员是除开产品开发人员之外首先见到产品的人，他们提出的功能和修改意见是特别有价值的。
α 测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程序之后再开始。有关的手册（草稿）等应事先准备好。
β 测试
β 测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。这些用户是与公司签定了支持产品预发行合同的外部客户，他们要求使用该产品，并愿意返回有关错位错误信息给开发者。与 α 测试不同的是，开发者通常不在测试现场。因而， β 测试是在开发者无法控制的环境下进行的软件现场应用。在 β 测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告，开发者在综合用户的报告之后，做出修改，最将软件产品交付给全体用户使用。
β 测试主要衡量产品的 FLURPS 。着重于产品的支持性，包括文档、客户培训和支持产品生产能力。只有当 α 测试达到一定的可靠程度时，才能开始 β 测试。由于它处在整个测试的最后阶段，不能指望这时发现主要问题。同时，产品的所有手册文本也应该在此阶段完全定稿。 由于 β 测试的主要目标是测试可支持性，所以 β 测试应尽可能由主持产品发行的人员来管理。 -
软件测试种类名词解释(下)
2008-4-20
单元测试：单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。
集成测试：集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。
集成测试的策略主要有自顶向下和自底向上两种。
系统测试：系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的 “ 先知者问题 ” 。因此，系统测试应该按照测试计划进行，
其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。
验收测试：验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。
回归测试：回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里，修改的正确性有两重含义：
一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。
黑盒测试
黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。
黑盒测试试图发现以下类型的错误：
1 ）功能错误或遗漏；
2 ）界面错误；
3 ）数据结构或外部数据库访问错误；
4 ）性能错误；
5 ）初始化和终止错误。
白盒测试在测试的早期采用，而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构，而是注意信息域。黑盒测试用于回答以下问题：
1 ）如何测试功能的有效性？
2 ）何种类型的输入会产生好的测试用例？
3 ）系统是否对特定的输入值尤其敏感？
4 ）如何分隔数据类的边界？
5 ）系统能够承受何种数据率和数据量？
6 ）特定类型的数据组合会对系统产生何种影响？
运用黑盒测试方法，可以导出满足以下标准的测试用例集：
1 ）所设计的测试用例能够减少达到合理测试所需的附加测试用例数；
2 ）所设计的测试用例能够告知某些类型错误的存在或不存在，而不是仅仅与特定测试相关的错误。
白盒测试
Rex Black
白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够：
1 ）保证一个模块中的所有独立路径至少被使用一次；
2 ）对所有逻辑值均需测试 true 和 false ；
3 ）在上下边界及可操作范围内运行所有循环；
4 ）检查内部数据结构以确保其有效性。
“ 我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节？” 答案在于软件自身的缺陷：
1 、逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、
条件或控制时，错误往往开始出现在我们工作中。日常处理往往被很好地了解，而 “ 特殊情况 ”
的处理则难于发现。
2 、我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流
有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，
只有路径测试才能发现这些错误。
3 、笔误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误，很多将被语法检查机制发现，但是，其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。 正如 Beizer 所说的： “ 错误潜伏在角落里，聚集在边界上 ” ，而白盒测试更可能发现它。
GUI 测试
Roger S. Pressman
图形用户界面（ GUI ）对软件测试提出了有趣的挑战，因为 GUI 开发环境有可复用的构件，开发用户界面更加省时而且更加精确。同时， GUI 的复杂性也增加了，从而加大了设计和执行测试用例的难度。因为现在 GUI 设计和实现有了越来越多的类似，所以也就产生了一系列的测试标准。
下列问题可以作为常见 GUI 测试的指南：
窗口：
· 窗口是否基于相关的输入和菜单命令适当地打开？
· 窗口能否改变大小、移动和滚动？
· 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？
· 当被覆盖并重新调用后，窗口能否正确地再生？
· 需要时能否使用所有窗口相关的功能？
· 所有窗口相关的功能是可操作的吗？
· 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，
并适当地显示？
· 显示多个窗口时，窗口的名称是否被适当地表示？
· 活动窗口是否被适当地加亮？
· 如果使用多任务，是否所有的窗口被实时更新？
· 多次或不正确按鼠标是否会导致无法预料的副作用？
· 窗口的声音和颜色提示和窗口的操作顺序是否符合需求？
· 窗口是否正确地被关闭？
下拉式菜单和鼠标操作：
· 菜单条是否显示在合适的语境中？
· 应用程序的菜单条是否显示系统相关的特性（如时钟显示）？
· 下拉式操作能正确工作吗？
· 菜单、调色板和工具条是否工作正确？
· 是否适当地列出了所有的菜单功能和下拉式子功能？
· 是否可以通过鼠标访问所有的菜单功能？
· 文本字体、大小和格式是否正确？
· 是否能够用其他的文本命令激活每个菜单功能？
· 菜单功能是否随当前的窗口操作加亮或变灰？
· 菜单功能是否正确执行？
· 菜单功能的名字是否具有自解释性？
· 菜单项是否有帮助，是否语境相关？
· 在整个交互式语境中，是否可以识别鼠标操作？
· 如果要求多次点击鼠标，是否能够在语境中正确识别？
· 光标、处理指示器和识别指针是否随操作恰当地改变？
数据项：
· 字母数字数据项是否能够正确回显，并输入到系统中？
· 图形模式的数据项（如滚动条）是否正常工作？
· 是否能够识别非法数据？
· 数据输入消息是否可理解？ -
主流测试工具的测试流程
2008-4-20
========winrunner
1 启动时选择要加载的插件
2 进行一些设置（如录制模式等）
3 识别应用程序的GUI，即创建map(就是学习被测试软件的界面）
4 建立测试脚本（录制及编写）
5 对脚本除错及调试（保证能够运行完）
6 插入各种检查点（图片，文字，控件等）
7 在新版应用程序中执行测试脚本
8 分析结果，回报缺陷
=========quicktestpro========
1 准备录制
打开你要对其进行测试的应用程序，并检查QuickTest中的各项设置是否适合当前的要求。
2 进行录制
打开QuickTest的录制功能，按测试用例中的描述，操作被测试应用程序。
3 编辑测试脚本
通过加入检测点、参数化测试，以及添加分支、循环等控制语句，来增强测试脚本的功能，使将来的回归测试真正能够自动化。
4 调试脚本
调试脚本，检查脚本是否存在错误。
5 在回归测试中运行测试
在对应用程序的回归测试中，通过QuickTest回放对应用程序的操作，检验软件正确性，实现测试的自动化进行。
6 分析结果，报告问题
查看QuickTest记录的运行结果，记录问题，报告测试结果。
＝＝＝＝TestDirect============
安装好后，先进入站点管理
1 创建域及工程
2 添加用户
3 编辑licenses及本服务器
4 编辑数据库
－－TD
1 选择新建的工程进行定制(列表，用户，组，版本等)
2 在require中增加需求
3 把需求转化为plan
4 在testlab中由计划新建测试具体用例与执行
5 发现bug，在defect中提交bug
（每一部分都可以相对独立地使用）
======loadrunner
1 制定负载测试计划
(分析应用程序， 确定测试目标，计划怎样执行LoadRunner）
2 开发测试脚本
（录制基本的用户脚本，完善测试脚本）
3 创建运行场景
（选择场景类型为Manual Scenario，选择场景类型，理解各种类型，场景的类型转化）
4 运行测试
5 监视场景
（MEMORY 相关，PROCESSOR相关，网络吞量以及带宽，磁盘相关，WEB应用程序 ，IIS5.0，SQL SERVER，NETWORK DELAY等)
6 分析测试结果
(分析实时监视图表,分析事务的响应时间,分解页面,确定WEBSERVER的问题,其他有用的功能)
-
如何编写测试用例(三)
2008-4-20
测试用例编写规范
一、测试用例编写准备
从配置管理员处申请软件配置：《需求规格说明书》和《设计说明书》；根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。
二、测试用例制定的原则
测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：
1、 正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
2、 容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
3、 完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
4、 接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
5、 数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。
6、 边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。
7、 压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行。。。进行测试。
8、等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
9、错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
10、效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。
11、可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。
12、可移植性：在不同操作系统及硬件配置情况下的运行性。
13、回归测试：按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员 已经解决，进行下一轮的测试。
14、比较测试：将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较 。
说明：针对不同的测试类型和测试阶段，测试用例编写的侧重点有所不同。
1、 其中第1、2、6、8、9、13项为模块（组件、控件）测试、组合（集成）测试、系统测试都涉及并重点测试的方面。
2、 单元（模块）测试（组件、控件）测试：重点测试第5项。
3、 组合（集成）测试：重点进行接口间数据输入及逻辑的测试，即第4项。
4、 系统测试：重点测试第3、7、10、11、12、14项。
5、 其中压力测试和可移植性测试如果是公司的系列产品，可以选用其中有代表性的产品进行一次代表性测试即可。
6、 GMPS基础测试用例设计完成后，其他的测试项目只编写设计与之不同部分的测试用例。
7、 对于每个测试项目测试的测试用例不是一成不变的，随着测试经验的积累或在测试其他项目发现有测试不充分的测试点时，可以不断的补充完善测试项目的测试用例。
三、测试用例的填写
一个软件系统或项目共用一套完整的测试用例，整个系统测试过程测试完毕，将实际测试结果填写到测试用例中，操作步骤应尽可能的详细，测试结论是指最终的测试结果（结论为：通过或不通过）。
