经典六问答：
问题1：有了“黑盒”测试为什么还要“白盒”测试？
黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。
白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。
问题2：由于单元测试要写测试驱动程序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢？
如果这样做，在开发过程中，缺陷会越积越多并且分布得更广、隐藏得更深，反而导致测试与改错的代价大大增加。最糟糕的是无法估计测试与改错的工作量，使进度失去控制。因此为图眼前省事而省略单元测试或者“偷工减料”，是“得不偿失”的做法。
问题3：如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？
要把N个单元集成一起肯定靠接口耦合，这时可能会产生在单元测试中无法发现的问题。例如：数据通过不同的接口时可能出错；几个函数关联在一起时可能达不到预期的功能；在某个单元里可以接受的误差可能在集成后被扩大到无法接受的程度。所以集成测试是必要的，不是多此一举。
问题4：在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试?
不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集成测试通常由开发小组执行。根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过测试的依据。
问题5：既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？
首先是“信任”问题。对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信“别人”呢? 所以当项目进行系统测试之后，客户再进行验收测试是情理之中的事。否则，那是客户失职。
不论是合同项目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、使用习惯不同等等）。测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。
问题6：能否将系统测试和验收测试“合二为一”？
系统测试不是一会儿就能做完的，比较长时间的用户测试很难组织。用户还有自己的事情要做，他们为什么要为别人测试呢？即使用户愿意做系统测试，他们消耗的时间、花费的金钱大多比测试小组的高。
系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。如果让用户发现“内幕”，一是丢脸，二是会吓跑买主。所以还是关起门来，先让测试小组做完系统测试的好。
回归测试是指对某些已经被测试过的内容进行重新测试。每当软件增加了新的功能，或者软件中的缺陷被修正，这些变更都有可能影响软件原有的功能和结构。为了防止软件的变更产生无法预料的副作用，不仅要对新内容进行测试，还要对某些老内容进行回归测试。
了解开发人员的测试心理：
测试的目的是找出尽可能多的缺陷。所以测试是“破坏性”的，而开发却是“建设性”的。开发人员总是喜欢欣赏程序的成功之处，而不愿看到失败之处。让开发者去做“蓄意破坏”的测试，就象杀自己的孩子一样难以接受。
开发者对自己的程序印象深刻，并总以为是正确的（自信是应该的）。倘若在设计时就存在理解错误，或因不良的编程习惯而流下了隐患，他本人很难发现这类错误.
开发者对自己的程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当而引发错误，这与大众用户的情况不太相似，所以测试自己的程序不具备典型性。
结论：开发人员应当测试自己的程序，这是他分内的工作。但是开发人员在测试自己的程序时，很难做到客观、公正，所以自我测试不具有说服力。
如何合理地减少测试工作量：
1.减少冗余的测试
白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。
在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。
2.减少无价值的测试
无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测试了100次，那么其中99次就是无价值的。
3.如何“偷工减料”
有一些“短、平、快”的项目，经费本来就少，用户对质量要求也马马虎虎。为了能多挣一点钱，开发方不得不采用“偷工减料”的方式来降低测试代价。偷工减料的途径无非就是减少测试的内容和频度。但不能砍得太狠，否则软件拿不出手。基本方法是找出软件中需要优先测试的部分，其它次要部分可以忽略或将来再测试。
软件测试流程：
第一步：制定测试计划。
第二步：设计测试用例。
第三步：那么执行测试。
第四步：撰写测试报告（每一轮测试执行完测试用例就需要写测试总结报告，总结系统的测试情况，BUG数量以及BUG在模块的分布情况等等）。
第五步：消除软件缺陷（由开发人员修改BUG）。
白盒测试工具是对代码的测试；黑盒测试工具是对功能和性能上的测试；测试管理工具是对测试活动进行管理，也就是对测试计划、测试用例、测试实施进行管理，并且，测试管理工具还包括对缺陷的跟踪管理。
80-20原则：80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错。
阅读(794) | 评论(1) | 转发(0) |
