测试的基本理论与方法（2）

 测试的基本理论与方法（2）

　七、测试的分类与比较

　　测试方式

　　白盒测试：关心软件内部设计和程序实现，主要测试依据是设计文档

　　黑盒测试：不关心软件内部，只关心输入输出，主要测试依据是需求文档

　　测试阶段

　　单元测试、集成测试、系统测试、验收测试。是“从小到大”、“由内至外”、“循序渐进”的测试过程，体现了“分而治之”的思想。

　　单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。

　　集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既要验证“设计”又要验证“需求”。

　　系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。

　　验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。

　　开发与测试的 V 型关系

　　如果软件开发过程采用严格的瀑布模型，那么开发与测试有“V”型的对应关系 。

　　测试内容

　　接口与路径测试。

　　功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试…

测试阶段 

主要依据 

测试人员、测试方式 

主要测试内容 

单元测试 

系统设计文档 

由开发小组执行白盒测试 

接口测试、路径测试 

集成测试 

系统设计文档

需求文档 

由开发小组执行白盒测试和黑盒测试 

接口测试、路径测试、功能测试、性能测试 

系统测试 

需求文档 

由独立测试小组执行黑盒测试 

功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试 

验收测试 

需求文档 

由用户执行黑盒测试 

 

测试人员的组织

　　了解开发人员的测试心理

　　测试的目的是找出尽可能多的缺陷。所以测试是“破坏性”的，而开发却是“建设性”的。开发人员总是喜欢欣赏程序的成功之处，而不愿看到失败之处。让开发者去做“蓄意破坏”的测试，就象杀自己的孩子一样难以接受。

　　开发者对自己的程序印象深刻，并总以为是正确的（自信是应该的）。倘若在设计时就存在理解错误，或因不良的编程习惯而流下了隐患，他本人很难发现这类错误.

　　开发者对自己的程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当而引发错误，这与大众用户的情况不太相似，所以测试自己的程序不具备典型性。

　　结论：开发人员应当测试自己的程序，这是他分内的工作。但是开发人员在测试自己的程序时，很难做到客观、公正，所以自我测试不具有说服力。

　　如何组织测试人员：应当视企业的人力资源而定

　　条件特别好的公司，可以为每一个开发人员分配一名独立的测试人员。这样的测试人员职业化程度很高，可以完成单元测试、集成测试和系统测试工作，能够实现开发与测试同步进行。

　　条件比较好的公司，可以设置一个独立的测试小组，该测试小组轮流参加各个项目的系统测试。而单元测试、集成测试工作由项目的开发小组承担。

　　条件一般的公司，养不起独立的测试小组。单元测试、集成测试工作由项目开发小组承担。当项目进展到系统测试阶段，可以从项目外抽调一些人员，加上开发人员，临时组织系统测试小组。

　　条件比较差的公司，也许只有一个项目和为数不多的一些开发人员。那么就让开发人员一直兼任测试人员的角色，相互测试对方的程序。如果人员实在太少了，只好让开发者测试自己的程序，有测试总比没有测试好吧！

　　避免开发人员与测试人员产生矛盾

　　开发人员不能很好地测试自己的程序是因为做不到“无情”。但如果测试人员真的做到了“无情”却会引起开发人员的愤怒，遭人白眼。由于开发与测试存在“对立”关系，开发人员与测试人员很容易产生矛盾，这对项目而言是一种伤害。

　　开发人员的注意事项：

　　（1）不要敌视测试人员。要理解测试的目的就是发现缺陷，是测试人员的工作职责。不要以为测试人员吃饱了没事干，存心找茬。

　　（2）不要轻视测试人员，别说人家技术水平差，不配搞开发只好搞测试。

　　测试人员的注意事项：

　　（1）发现缺陷时不要嘲笑开发人员，别说他的程序真臭、到处是Bug。

　　（2）在开发人员压力太大时或心情不好时不要火上浇油，发现缺陷时别大声嚷嚷。

　　尽量不要相互讽刺对方，例如：

　　A对B说：你唯一的特点就是无能。

　　B对A说：你唯一的特点就是粗鲁。

　　还要注意的是，如果测试人员与开发人员的关系非常好，可能会导致在测试的时候“手下留情”，这对项目也是一种伤害。

黑盒测试与白盒测试的比较

测试方式 

特征 

依据 

测试人员 

测试驱动程序 

黑盒测试 

只关心软件的外部表现，不关心内部设计与实现。 

软件需求 

任何人（包括开发人员、独立测试人员和用户）  

一般无需编写额外的测试驱动程序 

白盒测试 

关注软件的内部设计与实现，要跟踪源代码的运行。  

设计文档 

由开发人员兼任测试人员的角色 

需要编写额外的测试驱动程序 

　　问题1：有了“黑盒”测试为什么还要“白盒”测试？

　　黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。

　　白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。

　　问题2：由于单元测试要写测试驱动程序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢？

　　如果这样做，在开发过程中，缺陷会越积越多并且分布得更广、隐藏得更深，反而导致测试与改错的代价大大增加。最糟糕的是无法估计测试与改错的工作量，使进度失去控制。因此为图眼前省事而省略单元测试或者“偷工减料”，是“得不偿失”的做法。

　　问题3：如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？

　　要把N个单元集成一起肯定靠接口耦合，这时可能会产生在单元测试中无法发现的问题。例如：数据通过不同的接口时可能出错；几个函数关联在一起时可能达不到预期的功能；在某个单元里可以接受的误差可能在集成后被扩大到无法接受的程度。所以集成测试是必要的，不是多此一举。

　　问题4：在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试?

　　不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集成测试通常由开发小组执行。根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过测试的依据。

　　问题5：既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？

　　首先是“信任”问题。对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信“别人”呢? 所以当项目进行系统测试之后，客户再进行验收测试是情理之中的事。否则，那是客户失职。

　　不论是合同项目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、使用习惯不同等等）。测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。

　　问题6：能否将系统测试和验收测试“合二为一”？

　　系统测试不是一会儿就能做完的，比较长时间的用户测试很难组织。用户还有自己的事情要做，他们为什么要为别人测试呢？即使用户愿意做系统测试，他们消耗的时间、花费的金钱大多比测试小组的高。

　　系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。如果让用户发现“内幕”，一是丢脸，二是会吓跑买主。所以还是关起门来，先让测试小组做完系统测试的好。

　　回归测试

　　回归测试是指对某些已经被测试过的内容进行重新测试。每当软件增加了新的功能，或者软件中的缺陷被修正，这些变更都有可能影响软件原有的功能和结构。为了防止软件的变更产生无法预料的副作用，不仅要对新内容进行测试，还要对某些老内容进行回归测试。