1. 测试的常识与道理
1.1 你真的懂测试吗
u 编程大师说：没有错误的程序世间难求。 （《编程之道》）
u 你在学校里学过测试吗？（读到博士可能也不懂测试）
u 你所在的企业重视测试吗？ （小公司程序员的技能更加全面）
u 临时抱佛脚行吗？你以为有文档模板就会测试了吗？
u 如果不懂得有效地进行测试，你不仅得不到功劳，也没人欣赏你的苦劳，你拥有最多的将只是疲劳。
u 职业软件工程师应当掌握需求开发、系统设计、编程、测试、维护 所有技能。
1.2 测试的目的是什么
u 测试的目的是为了发现尽可能多的缺陷，不是为了说明软件中没有缺陷。
u 推论：成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。
u 千万不要将“测试”与“演示”混为一谈。例如科研鉴定会。
u 如果产品通过了严格的测试，大家不要不吭气，应当好好地宣传一把 。
1.3 一些常识和经验之谈
u 测试能提高软件的质量，但是提高质量不能依赖测试。
u 测试只能证明缺陷存在，不能证明缺陷不存在。“彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止地测试。我们应当祈祷：软件的缺陷在产品被淘汰之前一直没有机会发作。
u 测试的主要困难是不知道如何进行有效地测试，也不知道什么时候可以放心地结束测试。
u 每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据（所以项目需要独立测试人员）。
u 80-20原则：80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错
u 测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”。
2. 测试的分类与比较
u 问题1：有了“黑盒”测试为什么还要“白盒”测试？
– 黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。
– 白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。
u 问题2：由于单元测试要写测试驱动程序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢？
– 如果这样做，在开发过程中，缺陷会越积越多并且分布得更广、隐藏得更深，反而导致测试与改错的代价大大增加。最糟糕的是无法估计测试与改错的工作量，使进度失去控制。因此为图眼前省事而省略单元测试或者“偷工减料”，是“得不偿失”的做法。
u 问题3：如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？
– 要把N个单元集成一起肯定靠接口耦合，这时可能会产生在单元测试中无法发现的问题。例如：数据通过不同的接口时可能出错；几个函数关联在一起时可能达不到 预期的功能；在某个单元里可以接受的误差可能在集成后被扩大到无法接受的程度。所以集成测试是必要的，不是多此一举。
u 问题4：在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试?
– 不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集成测试通常由开发小组执行。根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过测试的依据。
u 问题5：既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？
– 首先是“信任”问题。对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信“别人”呢? 所以当项目进行系统测试之后，客户再进行验收测试是情理之中的事。否则，那是客户失职。
– 不论是合同项目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、使用习惯不同等等）。测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。
u 问题6：能否将系统测试和验收测试“合二为一”？
– 系统测试不是一会儿就能做完的，比较长时间的用户测试很难组织。用户还有自己的事情要做，他们为什么要为别人测试呢？即使用户愿意做系统测试，他们消耗的时间、花费的金钱大多比测试小组的高。
– 系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。如果让用户发现“内幕”，一是丢脸，二是会吓跑买主。所以还是关起门来，先让测试小组做完系统测试的好。
3. 测试人员的组织
3.1 了解开发人员的测试心理
u 测试的目的是找出尽可能多的缺陷。所以测试是“破坏性”的，而开发却是“建设性”的。开发人员总是喜欢欣赏程序的成功之处，而不愿看到失败之处。让开发者去做“蓄意破坏”的测试，就象杀自己的孩子一样难以接受。
u 开发者对自己的程序印象深刻，并总以为是正确的（自信是应该的）。倘若在设计时就存在理解错误，或因不良的编程习惯而流下了隐患，他本人很难发现这类错误.
u 开发者对自己的程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当而引发错误，这与大众用户的情况不太相似，所以测试自己的程序不具备典型性。
u 结论：开发人员应当测试自己的程序，这是他分内的工作。但是开发人员在测试自己的程序时，很难做到客观、公正，所以自我测试不具有说服力。
3.2 如何组织测试人员：应当视企业的人力资源而定
u 条件特别好的公司，可以为每一个开发人员分配一名独立的测试人员。这样的测试人员职业化程度很高，可以完成单元测试、集成测试和系统测试工作，能够实现开发与测试同步进行。
u 条件比较好的公司，可以设置一个独立的测试小组，该测试小组轮流参加各个项目的系统测试。而单元测试、集成测试工作由项目的开发小组承担。
u 条件一般的公司，养不起独立的测试小组。单元测试、集成测试工作由项目开发小组承担。当项目进展到系统测试阶段，可以从项目外抽调一些人员，加上开发人员，临时组织系统测试小组。
u 条件比较差的公司，也许只有一个项目和为数不多的一些开发人员。那么就让开发人员一直兼任测试人员的角色，相互测试对方的程序。如果人员实在太少了，只好让开发者测试自己的程序，有测试总比没有测试好吧！
3.3 避免开发人员与测试人员产生矛盾
u 开发人员的注意事项：
不要敌视测试人员。要理解测试的目的就是发现缺陷，是测试人员的工作职责。不要以为测试人员吃饱了没事干，存心找茬。
不要轻视测试人员，别说人家技术水平差，不配搞开发只好搞测试。
u 测试人员的注意事项：
发现缺陷时不要嘲笑开发人员，别说他的程序真臭、到处是Bug。
在开发人员压力太大时或心情不好时不要火上浇油，发现缺陷时别大声嚷嚷。
u 请留意另一种极端：如果测试人员与开发人员的关系非常好，可能会导致在测试的时候“手下留情”，这对项目也是一种伤害。
4. 企业的测试策略
4.1 理念：
u 企业的主要目的是获取利润，降低测试成本也是盈利的一种方式。
u 用较低的代价实现有效的测试，不应为了追求完美的测试而不失一切代价。
4.2 如何合理地减少测试工作量
u 减少冗余的测试
白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。
在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。
u 减少无价值的测试
无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测试了100次，那么其中99次就是无价值的。
u 如何“偷工减料”
有 一些“短、平、快”的项目，经费本来就少，用户对质量要求也马马虎虎。为了能多挣一点钱，开发方不得不采用“偷工减料”的方式来降低测试代价。偷工减料的 途径无非就是减少测试的内容和频度。但不能砍得太狠，否则软件拿不出手。基本方法是找出软件中需要优先测试的部分（见下表），其它次要部分可以忽略或将来 再测试。
u “偷工减料”方法的测试优先级：
哪些功能是软件的特色？
哪些功能是用户最常用的？
如果系统可以分块卖的话，哪些功能块在销售时最昂贵？
哪些功能出错将导致用户不满或索赔？
哪些程序是最复杂、最容易出错的？
哪些程序是相对独立，应当提前测试的？
哪些程序最容易扩散错误？
哪些程序是全系统的性能瓶颈所在？
哪些程序是开发者最没有信心的？
4.3 测试何时结束
u 基于测试用例的规则
u 基于“测试期缺陷密度”的规则
u 基于“运行期缺陷密度”的规则
4.4 测试奖励机制
u 根据缺陷的危害程度，把奖金分等级。每个新缺陷对应一份奖金，把奖金发给第一个发现该缺陷的人。奖金额要适当，太低了人们不感兴趣，太高了会让项目破产的。
5. 测试规范
5.1 测试流程
u 第一步：制定测试计划。该计划被批准后转向第二步。
u 第二步：设计测试用例。该用例被批准后转向第三步。
u 第三步：如果满足“启动准则” ，那么执行测试。
u 第四步：撰写测试报告。
u 第五步：消除软件缺陷。如果满足“完成准则”，那么正常结束测试。
5.2 测试启动准则
u 同时满足以下条件，允许开始测试：
（1）测试计划已经制定并且通过了审批；
（2）测试用例已经设计并且通过了审批；
（3）被测试对象已经开发完毕并等待测试。
5.3 测试完成准则
u 对于非严格系统可以采用“基于测试用例”的准则。同时满足以下条件允许结束测试：
（1）功能性测试用例通过率达到100％；
（2）非功能性测试用例通过率达到90％时。
u 对于严格系统，应当补充“基于测试期缺陷密度”的规则：
（3）相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m。例如n大于10，m小于等于1。
下一页
