掌握有效测试软件的方法与技术(一)(2)

　　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。

原文转自：http://www.ltesting.net