移山 - 软件测试讨论

lsekfe

1软件测试和VSTS 测试工具

　本部分介绍各种测试类型，以及它们在VSTS 2005中的应用。

在学习讨论之前，阿彪问大家：我有一个闷在心里好久的问题 – bug到底翻译成什么最好？

　杂曰：臭虫，缺陷，错误，地雷，应用程序异常，

就用bug好了，大家都理解！小强！小强！

大家回头一看，阿毛红着脸说：我们宿舍里有不少小强，每晚自习回去都要打小强。。。
　众大笑。
　阿彪：我倒是不反对用“小强”。
　阿超：好是好，VSTS也支持改工作项的名字。就怕我们以后招进来名字中有“强”的同学。
　阿彪：我觉得我可以为“小强”花一颗银弹，我们以后就把“小强” 当作bug的同义词.
　小飞：那我们怎么翻译“bug fix”?? 翻译成“针对缺陷的修改”也太绕口了。
　阿毛：我们是用拖鞋来打小强，所以不妨称之为“拖鞋”。
　（大笑）
　国栋：我反对把软件工程的术语生活化。。。

阿超：说到测试，大家肯定有不少了解，也保不准有一些误解，我们这个讨论就是要去伪存真，把大家的理解统一到一个水平上。大家知道的“测试方法”有多少？

杂曰：
　Black box Test, White box Test
　Code Coverage, Test Unit Test
　Functional Test, Structural Test
　System Test, Performance Test
　Stress Test, Load Test
　Acceptance Test, Regression Test
　Ad hoc Test, Integration Test
　Alpha/beta Test, Localization/Globalization Test
　Security Test, Accessibility Test, Scenario Test,
　Usability Test,Smoke Test

二柱：这么多！把我都忽悠得有点晕了。看来我国软件测试人才真是大有用武之地了。
　小飞：这么多名词，是得学几年的，写程序的方法怎么没有这么多花头？

阿超：咱们还是一个一个来吧。 这么多名词只不过是从各个方面描述了软件测试，并不是说有这么多独立的测试方法，我们把它们分类处理就不难了。

1.1从测试设计的方法分类

　从测试设计的方法来看，我们知道有两类方法：

Black box (黑箱)
　White box (白箱)

这是每个接触过软件测试的人都会给出的答案。但是这只是整个软件测试的入门。我们可以跳过去，直接讨论下面的内容。。。

问：我在网上看到有人争论黑箱测试和白箱测试哪一个是另一个的基础，还有那一个更难，那一个更有前途，等等。据说李村数码在搞“灰　箱测试”，是不是更高级？能不能简单讲一讲？
　阿超：大家都有这些问题么？
　杂曰：[略去对此问题热烈的争论500 字]
　阿超：听了大家的争论，看来我们的确得花不少时间统一认识.

第一个要注意的问题是，所谓黑箱/白箱，是软件测试设计的方法，不是软件测试的方法！注意“设计”二字。

黑箱：在设计测试的过程中，把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是“Behavioral Test Design”, 从软件的行为，而不是内部结构出发来设计测试。

白箱：在设计测试的过程中，设计者可以“看到”软件系统的的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择。“白箱”并不是一个精确的说法，因为把箱子涂成白色，同样也看不见箱子里的东西。有人建议用“玻璃箱”来表示。

在实际工作中，我们不应画地为牢，严格只用某一种方法来设计测试方法。在实际的测试中，当然是对系统了解的越多越好。所谓“灰箱”的提法，正是这一反映。有些人甚至希望我们全部忘记“箱子”和它们的颜色。

我们并不是要禁止懂得内部构造的人员来进行黑箱测试设计，只不过我们在设计时有意不考虑软件的内部结构。例如：在测试程序内部基本模块的时候（单元测试），我们通常是要求对程序结构非常了解的程序员来设计，这是因为内部模块的“行为”和程序的外部功能并没有直接的关系，而且内部基本模块的“行为”通常没有明确的定义。另一个例子是“可用性测试”，在设计此类测试的时候，我们没必要纠缠于程序的内部结构，而是着重于软件的界面和行为。但是软件可用性测试也需要很多专业知识。这也从一个侧面表明“黑箱”和 “白箱”没有简单的高低之分。

一旦测试用例写出来之后，我们大可以忘了它们是从那种颜色的箱子里出来的，用它就可以了。

1.2功能测试

　以下的测试术语都是主要测试软件的功能。在下表所列的测试中，测试的范围有小到大，测试者也由内到外 – 从程序开发人员（单元测试）到 测试人员，到一般用户（Alpha/Beta 测试）。

测试名称 测试内容

Unit Test 单元测试 – 在最低的功能/参数上验证程序的正确性
　Functional Test 功能测试 – 验证模块的功能
　Integration Test 集成测试 – 验证几个互相有依赖关系的模块的功能
　Scenario Test 场景测试 – 验证几个模块是否能够完成一个用户场景
　System Test 系统测试 – 对于整个系统功能的测试
　Alpha/Beta Test 外部软件测试人员（Alpha/Beta 测试员）在实际用户环境中对软件进行全面的测试。

1.3非功能测试

　一个软件除了基本功能之外，还有很多功能之外的特性，这些叫“non-functional requirement”, 或者“quality of service requirement”- 服务质量需求。没有软件的功能，这些特性都无从表现出来，我们要在软件开发的适当阶段做这些测试。

比如：
　测试名称 测试内容
　Stress/load test 测试软件在负载情况下能否正常工作
　Performance test 测试软件的效能
　Accessibility test 测试软件辅助功能测试 – 测试软件是否向残疾用户提供足够的辅助功能
　Localization/Globalization Test 本地化/全球化测试
　Compatibility Test 兼容性测试
　Configuration Test 配置测试 – 测试软件在各种配置下能否正常工作
　Usability Test 可用性测试 – 测试软件是否好用
　Security Test 软件安全性测试

　1.4Unit Test单元测试

二柱：我们也试过用单元测试来保证质量，要求每人都要写，在签入代码前必须通过单元测试。但是搞了几个星期就不了了之。

大家七嘴八舌的列举了单元测试的问题：
　有时单元测试报了错，再运行一次就好了，后来大家就不想花时间改错，多运行几次，有一次通过就行了。

单元测试中好多错都和环境有关，在别人的机器都运行不成功。
　花在单元测试上的时间要比写代码的时间还多
　单元测试中我们还要测试效能和压力，花了很多时间
　我们都这么费劲地测了，那还要测试人员干什么？

1.4.1用VSTS写 单元测试

　单元测试的基本构成
　Setup//设置好环境，准备测试
　Test// 测试
　Teardown//打扫战场

例子：我们要写一个银行账户的类，那么它的单元测试应该怎么写？
谁自告奋勇上来表演一下写代码？小飞，好请上台。

小飞写了下面的代码：
　定义interface IAccount
　实现public class Account : IAccount
　{
　}

每个函数都使用临时代码

好，现在右键按住Account，就可以看到“Create Unit Tests”的菜单，选中之后，会出来新建Unit Tests的对话框：

每个函数都可以选中是否产生 单元测试。

//解释单元测试的结构

//一个缺省的单元测试
　//修改过的单元测试

//运行单元测试

//单元测试的结果
　//代码覆盖率

1.4.2好的单元测试的标准

　单元测试应该准确，快速地保证程序基本模块的正确性。下面是验证单元测试好坏的一系列标准：

1.4.2.1单元测试应该在最低的功能/参数上验证程序的正确性

　单元测试应该测试程序中最基本的单元 – 如在C++/C#/Java中的类，在此基础上，可以测试一些系统中最基本的功能点（这些功能点由几个基本类组成），从面向对象的设计原理出发，系统中最基本的功能点也应该由一个类及其方法来表现。单元测试要测试API中的每一个方法，及其每一个参数。

1.4.2.2单元测试必须由最熟悉代码的人（程序的作者）来写

　代码的作者最了解代码的目的，特点，和实现的局限性。所以，没有比作者适合的人选。
问：如果我很忙，能不能让别人代劳单元测试？

答：如果忙到连单元测试都没有时间做，那么你也没有时间写好这个功能。在一些极限编程的方法中，是可以考虑让别人来做单元测试，但是，程序的作者还是要对单元测试负责。

最好是在设计的时候就写好单元测试，这样单元测试就能体现API的语义，如果没有单元测试，语义的准确性就不能得到保障，以后会产生歧义。

　1.4.2.3单元测试过后，机器状态保持不变

　这样就可以不断地运行单元测试，如果单元测试创建了临时的文件或目录，应该在Teardown阶段把这些临时的文件或目录删除。

如果单元测试在数据库中创建或修改了记录，那么也许要删除这些记录，或者每一个单元测试使用一个新的数据库，这样保证单元测试不受以前单元测试实例的干扰。

1.4.2.4单元测试要快 (一个测试运行时间是几秒钟, 而不是几分钟)

　快，才能保证效率。因为一个软件中有几十个基本模块（类），每个模块又有几个方法，基本上我们要求一个类的测试要在几秒钟内完成。如果软件有相互独立的几个层次，那么在测试组中可以分类，如数据库层次，网络通信层次，客户逻辑层次，和用户界面层次，可以分类运行测试，比如我只修改了“用户界面”的代码，我只需运行“用户界面”的单元测试。

1.4.2.5单元测试应该产生可重复，一致的结果

　如果单元测试的结果是错的，那一定是程序出了问题，而且这个错误一定是可以重复的。

问：如果用随机数以增加测试的真实性，好么？
答：一般情况下不好，如果某个随机数导致程序出错，但是下一次运行又不能重复这一错误，于事无补。要注意我们还是要用随机数等办法“增加测试的真实性”，但是不是在单元测试中。单元测试不能解决所有问题，所以也不必期望它会发现所有的缺陷。

1.4.2.6独立性，单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。

　程序中的各个模块都是互相依赖的，否则它们就不会出现在一个程序中。一般情况下，单元测试中的模块可以直接引用其它的模块，并期待其它的模块能返回正确的结果。

如果其它的模块很不稳定，或者其他模块运行比较费时（如进行网络操作），而且对于本模块的正确性并不起关键的作用。这时可以人为地构造数据以保证这个单元测试的独立性。

New Object
　New user
　Get user permission // go thru the server to get the correct permission, you can also mock the permission object.
　Object.Test(user)

1.4.2.7

单元测试应该覆盖所有代码路径，包括错误处理路径，为了保证单元测试的代码覆盖率，
　单元测试必须测试公开的和私有的函数/方法。
　单元测试必须覆盖所测单元的所有代码路径。

问：啊！这样岂不是要写很多啰里啰唆的测试方法？
　答：对，因为程序中很多缺陷都是从这些啰里啰唆的错误处理中产生的。如果你的模块中某个错误处理路径很难到达，那你也许要想想是否可以把这个错误处理拿掉。

[大栓：这对于那些爱写复杂代码的人是一个很好的惩罚，不对，是一个很好的锻炼。]
[阿超：对，把单元测试的责任和代码作者绑定在一起后，代码作者就能更真切地体会到复杂代码的副作用，因为验证复杂代码的正确性要困难得多。要注意的一点是：100% 的代码覆盖率并不等同于100% 的正确性，请看下列例子]

e.g.didn’t check return value.
　e.g. memory leak

1.4.2.8单元测试应该集成到自动测试的框架中

　另一个重要的措施是要把单元测试自动化，这样每个人都能很容易地运行，并且单元测试每天都可以运行。每个人都可以随时在自己机器上运行。团队一般是在每日构建中运行单元测试, 这样每个单元测试的错误就能及时发现并得到修改。

1.4.2.9单元测试必须和产品代码一起保存和维护

　单元测试必须和代码一起进行版本维护。如果不是这样，过了一阵，代码和单元测试就会出现不一致，而且所有代码的作者要花时间来确认哪些是程序出现的错误，哪些是由于单元测试更新滞后造成的错误。。。这样就失去了单元测试的意义，同时又给大家增加了负担，折腾多次以后，大家就会觉得维护单元测试是一件很费时费力的事。

1.5BVT 构建验证测试 （Build Verification Test）

　望文生义，构建验证测试是指在一个构建完成之后，团队自动运行的一套验证系统的基本功能的测试。大多数情况下，这一套系统都是在自动构建成功后自动运行的，有些情况下也会手工运行，但是由于构建是自动生成的，我们也要努力让BVT自动运行。

问：一个系统有这么多功能点，什么是基本，什么是不基本的？
　答：第一，必须能安装；第二，必须能够实现一组核心场景（例如：对于字处理软件来说，必须能打开/编辑/保存一个文档文件，但是一些高级功能.
　如: 文本自动纠错, 则不在其中； 又如，网站系统，用户可以注册/上载/下载信息，但是一些高级功能，如删除用户，列出用户参与的所有讨论，则不在其中。

在运行BVT之前，可以运行所有的单元测试, 这样可以保证系统的单元测试和程序员的单元测试版本保持一致。不少情况下，开发人员修改了程序和单元测试，但是忘了把更新的单元测试也同时签入源代码库中。

通过BVT的构建可以称为：可测 （self-test）, 意思是说团队可以用这一版本进行各种测试 – 因为它的基本功能都是可用的。通不过BVT的构建称为“不可测”（self-hosed）

如果构建测试不能通过，那么自动测试框架会自动对每一个失败的测试产生一个bug （小强）。一般的做法这些小强都是有最高优先级，是开发人员要首先修改这些小强。大家知道维持每日构建，并产生一个可测的版本是软件开发过程质量控制的基础。对于导致问题的小强，我们该怎么办？

1． 找到导致失败的原因，如果原因很简单，程序员可以马上修改，然后直接提交。

2． 找到导致失败的原因的修改集，把此修改集剔出此版本（程序员必须修改好后再重新提交到源代码库中）。

3． 程序员必须在下一个构建开始前把此小强修理好。

方法1/2都可以使今天的构建成为“可测”，但是有时各方面的修改互相依赖，不能在短时间内解决所有问题，只能采用第三个办法。

问：有人提到一种“smoke test”，冒烟测试，是什么回事？
答：这事实上是一种基本验证测试，据说是从硬件设计行业流传过来的说法 – 当年设计电路板的时候，很多情况下，新的电路板一插上电源就冒起白烟，烧坏了，如果插上电源后没有冒烟，那就是通过了“冒烟测试”，可以进一步测试电路板的功能了。我们正在讨论的BVT也是一种冒烟测试。

1.6功能测试 （functional test）

　测试团队拿到一个“可测”等级的构建，他们就会按照测试计划，测试各自负责的模块和功能，这个过程可能会产生总共10来个bug，也可能产生100个以上的bug，那么如何保证我们有效地测试了软件，同时我们在这一步怎样衡量构建的质量？

在MSF敏捷模式中，我们建议还是采用场景来规划测试工作
　在“基本场景”的基础上，我们把所有系统目前理论上支持的场景都列出来，然后按功能分类测试，如果测试成功，就在此场景中标明“成功”，否则，就标明“失败”，并且把失败的情况用一个（或几个）“小强”/bug来表示。

当所有的测试人员完成对场景的测试，我们自然地就得出了一个表：

场景ID 场景名 测试结果 Bug/小强id
　3024 用户登录 成功
　3026 用户按价格排序 失败 5032
　3027 用户按名字搜索 失败 5033
　…
　?… … …

这样我们就能很快地报告“功能测试56% 通过”等等。如果所有场景都能通过，（有些情况下可以把此标准从100% 降低到90% 左右）则这个构建的质量是“可用”，意味着这一个版本可以给用户使用。 这种情况下，客户，合作伙伴可以得到这样的版本 – 这也是所谓“技术预览版”，或“社区预览版”的由来。

但是，有一个重要的问题要大家注意“可用”，并不是指软件都没有bug，而是指在目前的用户场景中，按照场景的要求进行的操作，都能得到预期的效果。

1． 目前还没有定义的用户场景中，程序质量如何，还未得而知。

a. 场景中没有考虑到多种语言设置

2． 不按照场景的要求进行的操作，结果如何，还未得而知。

a. 如：在某一场景中，场景规定用户可以在最后付款前取消操作，回到上一步，如果一个测试人员发现在反复 提交/取消同一访问多次，然后网页出现问题，这并不能说明用户场景失败，当然这个极端的bug也必须找出原因并在适当的时间改正。

这种测试有时也被称为“acceptance test”, 因为如果构建通过了这样的测试，这一个构建就被测试团队“接受了”。 同时，还有对系统各个方面进行的“接收”测试，如测试系统的全球化，或者针对某一语言环境做的测试。

1.7

Ad hoc Test, Exploratory Test “探索式”的测试

“Ad Hoc” 原意是指 “特定的，一次性的”。

什么叫“特定”测试？或者“探索式”的测试？
就是为了某一个特定目的进行的测试，就这一次，以后一般也不会重复测试。在软件工程的实践中，“ad hoc”大部分是指随机进行的，探索性的测试。

比如：测试人员阿毛拿到了一个新的构建，按计划是进行模块A的功能测试，但是他灵机一动，想看看另一个功能B做得如何，或者想看看模块A在某种边界条件下会出现什么问题，于是他就“ad hoc”一把，居然在这一功能模块中发现了不少小强。

“ad hoc”也意味着测试是尝试性的，“我来试试，在这个对话框中一通乱按，然后随意改变窗口大小，看看会出什么问题…”， 如果没问题，那么以后也不会再这么做了。

一般情况下，测试人员不会花很多时间进行特定测试，但是在一些缺乏管理的团队中，很多时候测试人员不知道自己此时应该做什么，只好做一些看似“ad hoc” 的测试，比如随机测试各个功能的各个方面。这些测试理论上都应该由测试管理人员规划好属于各个功能模块的测试用例中。

在一个团队中，“ad hoc”太多是一个管理不好的标志，因为“ad hoc”是指那些一时想到要做，但是以后也没有计划经常重复的测试计划。

问：我听说有人是“ad hoc”测试的高手，这是什么意思？

答：有很多测试人员会按部就班地进行测试，但是还有一些人头脑比较灵活，喜欢另辟蹊径，测试一些一般人不会想到的场景，这些人往往会发现更多的小强。开发人员对这样的“ad hoc”高手是又爱又恨。

问：同时看问题要分两方面，有些“ad hoc”发现的小强在正常使用软件中几乎不会出现，我们要不要花时间“ad hoc”

答：现在一些成功的通用软件的用户以百万计，按部就班的测试计划很难包括很多实际的场景，这时，“ad hoc”测试能够发现重要的问题；另外一些风险很大的领域，例如安全性，一旦出了问题，威胁就会相当大，这时要多鼓励一些“ad hoc”测试，以弥补普通测试的不足。从这个意义上说，“ad hoc”测试可以用来衡量当前测试用例的完备性，如果你探索了半天，都没有发现什么在现有测试用例之外的问题，那就说明现有的测试用例是比较完备的。

“ad hoc”测试的测试流程是不可重复的，因为它的测试都是“特定”测试，没法重复。由于这一原因，“ad hoc”测试不能自动化，就这一点而言，还达不到CMM的第二级 – 可重复级。

作为管理人员来说，如果太多小强是在“ad hoc”出来的，那我们就要看看测试计划是否基于实际的场景，开发人员的代码逻辑是否完善，等等。同时，要善于把看似“ad hoc”的测试用例抽象出来，包括到以后的测试计划中。

　1.8Regression Test回归测试

问：我听说不少关于Regression Test的介绍，但是它到底是怎么“回归”法？回归到哪里去？我还是没搞懂。

答：Regress的英语定义是：return to a worse or less developed state.? 是倒退，退化，退步的意思。

在软件工程中，如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那这个模块就出现了一个“退步”- regression, 从正常工作的稳定状态退化到不正常工作的不稳定状态。

在一个模块的功能逐步完成的同时，和此功能有关的测试用例也同样在完善中。一旦有关的测试用例通过，我们就得到此模块的功能基准（baseline）.?

在某某版本，某某模块的某某测试用例是通过的！

如果测试人员发现了在新的构建版本某个测试用例失败了，这就是一个“倒退”，在新版本上运行所有已通过的测试用例以验证没有“退化”情况发生，这个过程就是一个“regression test”.? 如果这样的“倒退”是由于模块的功能发生了正常变化（由于设计变更的原因），那么测试用例的基准就要修改，以和新的功能保持一致。
?
　针对一个bug fix （拖鞋），我们也要作Regression Test，

a) 验证新的代码的确把缺陷改正了，

b)同时要验证新的代码没有把模块的现有功能破坏，没有regression。
所以我不也知道“回归测试”是如何的“回归”，我们可以理解为“回归到以前不正常的状态”。

回归测试最好要自动化，因为对于每一个构建都要运行所有回归测试，以保证尽早发现问题。

1.9Scenario/integration/System Test? 场景/集成/系统测试

　在软件开发的一定阶段，我们要对一个软件进行全面和系统的测试，以保证软件的各个模块都能共同工作，在各方面都能满足用户的要求。这时的测试叫系统/集成测试。

问：什么时候做系统测试？是不是越快越好？

答：原则上是当一个模块稳定的时候，就可以把它集成到系统中，和整个系统一起进行测试，通常在软件产品需要阶段性发布的时候。

问：有一种叫Scenario Test, 是什么意思?

答：就是以场景为驱动的集成测试，关于“场景”，大家可以看专门的介绍。这一方法的核心思想是：当用户使用一个软件的时候，他/她并不会独立使用各个模块，而是把软件做为一个整体来使用的。我们在做场景测试的时候，就需要考虑在现实环境中用户使用软件的流程是什么样，然后模拟这个流程，看看软件能不能达到用户的需求。这样，能使软件符合用户使用的实际需求。

用一个数字照片编辑软件为例，这个软件的各个模块都是独立开发的，可是用户有一定的典型流程，如果这个流程走得不好，哪怕某个模块的质量再高，用户也不会满意。

1.把照相机的储存卡插入电脑
　2.程序会跳出窗口提示用户导入照片
　3.导入照片
　4.对照片进行快速编辑
　a.调整颜色
　b.调整亮度，对比度
　c.修改红眼
　5.把其中几幅照片用email发送

这里面每一步出了问题，都会影响用户对这一产品的使用，同时这里面各个模块的用户界面如果很不一致（即使是ok/cancel按钮的次序不同），用户使用起来也很不方便。这些问题都是在单独模块的测试中不容易发现的。

1.10Performance Test 效能测试

用户使用软件，不光是希望软件能够提供一定的服务，而且还要求服务的质量要达到一定的水平，软件的效能， 是这些“非功能需求”，或者说“服务质量需求”的一部分。

效能测试要验证的问题是：
　软件在设计负载内能够提供令用户满意的服务质量。
　1．在设计负载内 – 我们要定义什么是正常的设计负载
　2．令用户满意的服务质量 – 我们要定义什么样的质量是令用户满意的

设计负载 – 从需求说明出发，得出系统的正常负载。例如，一个购物网站，客户认为正常负载是每分钟20次客户请求。
用户满意的质量 – 同一个购物网站，如果客户定义满意为：每个用户的请求都能在2秒钟内返回结果。

我们可以逐步细化 –
　设计负载的细化，上面我们只提到“20次客户请求”，那这些客户请求到底是什么，我们可以按照请求发生的频率来分类：
　1． 用户登录 （10%）
　2． 用户查看某商品详情（50%）
　3． 用户比较两种商品（10%）
　4． 用户查看关于商品的反馈（20%）
　5． 用户购买商品（5%）
　6． 所有其他请求（5%）

服务质量的细化 – 有些请求，是要对数据作“写”操作，可以要求慢一些，比如“用户购买商品”，这一服务质量请求可以放宽为3秒钟。

除了用户体验到的“2秒钟页面刷新”目标外，效能测试还要测试软件内部各模块的效能，这要求软件的模块能报告自身的各种效能指标，通过perfmon? 或其它测试工具表现出来。

和别的测试不同，效能测试对硬件要有固定的要求，而且最要每次测试在相同的机器和网络环境中进行，这样才能避免外部随机因素的干扰，得到精准的效能数据。

同时，效能测试的结果应该成为“发布指南”的一部份，给客户发布和改进系统提供参考。

在VSTS中如何进行效能测试在以后会详细讲解。

1.11 Stress Test压力测试

　压力测试严格地说不属于效能测试。压力测试要验证的问题是：
　软件在超过设计负载的情况在仍能够返回正常结果，而没有产生严重的副作用或崩溃。

问：为啥不要求软件在这种情况下仍然在2-3秒钟内返回结果？
　答：因为我们做不到。

注意，我们在这一部分要求“正常结果”，啥叫“正常”？我们也要和客户达成一致。比如，同一个购物网站，所有请求都能在网络返回“超时”错误前返回，就可以认为是“正常”。 或者网站返回“系统忙，请稍候”，也是正常结果。但是，如果用户提交的请求一部分执行，另一部分没有执行；或者用户信息丢失，这些都是不正常的结果，应该避免。

那我们怎么增加负载？对于网络服务软件来说，主要有下面两个方面：

1． 沿着用户轴延长
　我们用刚才的购物网站为例，正常的负载是20请求/分钟，如果有更多的用户登录，怎么办？那么负载就会变成30，40， 100请求/分钟，或更高

2． 沿着时间轴延长
　做过网络服务的同事都知道，网络的负载有时间性，负载压力波峰和波谷相差很大，那么如果每时每刻负载都处于峰值，程序会不会垮掉？这就是我们要作的第二点，沿着时间轴延长。

与此同时，我们可以减少系统可用的资源，来增加压力。

注意，压力测试的重点是验证程序不崩溃或产生副作用。在超负载的情况下，我们的程序仍然能够正确地运行，而不会死机。在给程序加压的过程中，程序中的很多“小”问题就会被放大，暴露出来。 最

常见的问题是
　内存/资源泄露，在压力下这会导致程序可用的资源枯竭，最后崩溃。
　一些平时认为“足够大/足够好”的算法实现会出现问题。
　进程/线程的同步死锁问题，在压力下一些小概率事件会发生，看似完备的程序逻辑也出现了问题。

在VSTS中如何进行压力测试在以后章节中会详细讲解。

1.12 Alpha Test, Beta Test

在开发软件的过程中，开发团队希望让用户直接接触到最新版本的软件，以便从用户那里收集反馈，这时开发团队会在开发过程中让特定的用户（alpha/beta用户）使用正处于开发过程中的版本，用户会用特定的反馈渠道（email, BBS）与开发者讨论使用中发现的问题，等等。这种做法成功地让广大用户心甘情愿地替开发团队测试产品并提出反馈。最近有些开发团队增加了反馈的密度，不必再等到Alpha或者Beta发布，而是不断地把一些中间版本发布出去以收集反馈，美其名曰“技术预览版本”或“社区预览版本”。

　1.13 Usability Test可用性测试

小燕问：作为测试人员，我们是不是也要作可用性测试?
　答：测试人员，以及其他的团队成员都可以对软件的可用性提出意见，包括用bug的形式放在在TFS中。软件的可用性不神秘，就是让软件更好用，让用户更有效地完成工作。

但是我觉得“可用性测试”似乎更多地用来描述一套测试软件可用性的过程，这个过程一般不是由测试人员来主导的，而是有对软件设计及可用性有很多研究的“可用性设计师”来实行。网络上有许多关于这方面的文章，大家可以参考。

1.14 Bug Bash

问：我们已经讲得太多的测试了，好像微软还有一个叫“bug bash”的活动，是啥意思？
　答：简而言之，就是大家一起来找小强的活动 – 小强大扫除。一般是安排出一段时间（一天），所有测试人员（有时也加入其他角色）放下手里的事情，专心找某种类型的小强。然后结束时，统计并奖励找得最多的，和最厉害的小强的员工。这种活动，如果运用得好，有下面的作用：
　鼓励大家做探索试的测试，开阔思路。
　鼓励测试队伍学习并应用新的测试方法，例如在做完“软件安全性测试”培训后，立马做一个针对“安全性”的小强大扫除.
　找到很多小强，让开发人员忙一阵子

当然，小强大扫除也有一些副作用：
　扰乱正常的测试工作
　如果过分重视奖励，会导致一些数量至上，滥竽充数的做法。

两个细节是：
　1．一定要让“小强大扫除”有明确的目标，明了的技术支持。
　2．一定要让表现突出的人介绍经验，让别人学习。

要记住，最好的测试，是能够防止小强的出现。

　2总结和思考

　2.1十八般兵器

　阿毛：超总, 我的脑袋好像装不下了!? 听了这么多，我感觉像是身上扛着十八般兵器，累得半死，但是不知道什么时候，对哪一种敌人用哪一种兵器，能不能总结一下!
　阿超：好，我们用软件开发的生命周期来说明一下不同的测试在不同阶段的使用：
远景和计划阶段：

测试只是处于计划阶段，同时要收集用户对于软件非功能性的需求，如效能，可用性，国际化等。一些“小强大扫除”的类型也可以在这个时候初步安排。

　开发阶段：

开发人员要写单元测试， 测试人员要写BVT。
对于每一个成功的构建，测试人员要运行功能测试/场景测试，同时建立回归测试基准以便开始回归测试。各类测试人员要进行探索式测试。

随着软件功能的逐步完善，测试人员要进行集成测试。这时，团队可以开展对程序非功能性特性的测试，如效能/压力测试，国际化/本地化测试，安全性测试，可用性，适用性测试等。在这个时候，可以考虑分析各个模块的代码覆盖率，以增加测试的有效性。根据计划，各种类型的“小强大扫除”会以适当的频率发生。

　稳定阶段：

到了一个开发阶段的尾声，这时测试团队就可以依据以前制定的验收标准，对软件逐项进行验收测试。按照测试计划，各个方面的测试都会宣布“测试完成”- 所有想到的测试都做了，所有问题都发现了。在此阶段，团队也可以把软件发布给外部进行alpha/beta测试。
一般情况下，测试队伍要把迄今为止发现的所有小强都从新试一次，确保它们都在最后的版本中被清除了，没有一个“回归”出现。

发布阶段：

测试队伍要把尽可能多的测试用例自动化，并为下一个版本的测试工作做好准备。

2.2构建的质量

　1．编译失败
　2．可测/不可测
　3．可用/不可用

2.3问题

2.3.1 如果连续几天都不能产生“可测”版本，怎么办？

　提示：可以在下一个构建版本中限制签入的数量，只接受那些高等级的修改，在一般的做法中，导致“不可测”的小强的严重性是1，必须在下一个构建开始的时候得到改正。