测试案例的分析

　　案例：

    某软件公司在开发一个城镇居民保险系统时，在单元测试、集成测试阶段，为了追赶进度，开发人员与测试人员都没有介入测试工作。
　
　　系统测试阶段，测试小组借助缺陷管理工具和开发人员交互进行测试与缺陷修复工作。期间，发现“扭转文档无法归档”的严重错误，开发人员在修改时，认为难度太大，决定暂停修改，得到测试人员认可。在产品发布前，该问题在开发环境下得到解决。
　
　　回归测试结束后，开发人员把开发环境下的产品打包，发送给客户。
　
　　分析：在案例中，有几处显然不合理的地方：

    1.测试介入太晚

    2.回归测试做得不合理：“开发人员把开发环境下的产品打包，发送给客户”，明显还缺少一次测试。所有的缺陷应该经过验证修改后才可以发布产品。
　
　　3.产品发布的出口不对：案例中的产品最后由开发人员直接发布，十分不合理。很多缺陷在开发环境下运行时不会出现，来源于开发环境打包的产品隐藏更多的缺陷。实际最后发布的产品应该从产品库中提取，而且基线库中的产品应该是最后经过测试的。
　
　　4.缺陷流程管理不合理：

    a） 缺陷的权限控制不严：开发工程师无权决定是否延期或者暂时停止修改某一缺陷；测试工程师认可错误的决定也是不合理的。
　
　　b） 没有对每个缺陷进行全程跟踪：测试工程师应该跟踪每一条缺陷，并确定修改后才可以进行关闭操作，而不是发现缺陷就完成了任务。
　
　　c） 缺少缺陷审核步骤：产品发布前，项目经理应该对产品发现的缺陷进行审核，根据修改状况决定是否可以发布。