开发人员的注意事项：

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

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

　　测试人员的注意事项：

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

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

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

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

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

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

　　企业的测试策略

　　理念：

　　企业的主要目的是获取利润，降低测试成本也是盈利的一种方式。

　　用较低的代价实现有效的测试，不应为了追求完美的测试而不失一切代价。

　　如何合理地减少测试工作量

　　减少冗余的测试

　　白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。

　　在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。

　　减少无价值的测试

　　无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一个典型的输入行了，如果有人在此区间测试了100次，那么其中99次是无价值的。

　　如何“偷工减料”

　　有一些“短、平、快”的项目，经费本来少，用户对质量要求也马马虎虎。为了能多挣一点钱，开发方不得不采用“偷工减料”的方式来降低测试代价。偷工减料的途径无非是减少测试的内容和频度。但不能砍得太狠，否则软件拿不出手。基本方法是找出软件中需要优先测试的部分，其它次要部分可以忽略或将来再测试。

　　“偷工减料”方法的测试优先级：

　　哪些功能是软件的特色？

　　哪些功能是用户常用的？

　　如果系统可以分块卖的话，哪些功能块在销售时昂贵？

　　哪些功能出错将导致用户不满或索赔？

　　哪些程序是复杂、容易出错的？

　　哪些程序是相对独立，应当提前测试的？

　　哪些程序容易扩散错误？

　　哪些程序是全系统的性能瓶颈所在？

　　哪些程序是开发者没有信心的？

　　测试何时结束？

　　一、基于测试用例的规则

　　（1）先构造测试用例（并请有关人员进行评审）。

　　（2）在测试过程中，当测试用例的不通过率达到20％时，则拒绝继续测试，待开发人员修正软件后再进行测试。

　　（3）当功能性测试用例通过率达到100％，非功能性测试用例通过率达到90％时，允许正常结束测试。

　　该规则的优点是适用于所有的测试阶段，缺点是太依赖于测试用例。如果测试用例非常糟糕，那么该规则失效了。

　　二、基于“测试期缺陷密度”的规则

　　把测试一个CPU小时发现的缺陷数称为“测试期缺陷密度”。绘制“测试时间－缺陷数”的关系图，如果在相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m时，则允许正常结束测试。例如n大于10，m小于等于1。该规则比较适用于系统测试阶段。