用例千万条，质量第一条。 流程不规范，亲人泪两行！ 昨天衬衫哥接到新的上线需求提交到测试，功能很简单。程序猿童鞋告诉我，不用测了，没问题的。这个时候，刚工作不久的测试童鞋可能本着相信同事，抹不开情面，选择不测或者少测，直接发给运维童鞋准备部署上线了。如果是这样的话，测试童鞋准备被上课了：上线后有问题，都是测试的锅了。测试第一准则就是：不要相信任何人说的话。眼见为实，任何事情都需要验证过，以可交付的文档，原型等文字内容为准。为什么？因为要随时防止背锅啊。上线前，项目经理催你进，产品经理催你，运维催你，销售也催你。上线后，出问题了，他们第一反应就是，测试怎么没测出来？所谓，催进度他们来，背锅测试去。这个时候，需要需要把之前评审过的测试用例甩出来，漏了大家都有责任，有锅大家一起扛。与产品的聊天记录，邮件把需求不清晰，上线前还在变更需求的锅甩回产品。测试计划要把各种风险多描述清楚，特别是测试时间被压缩会导致漏测的风险标注出来。为什么？因为项目开发进度从来都是不够的，测试时间从来都是被压缩的。没错，这就是it行业里的潜规则之一。不要信什么敏捷开发，背靠背开发，都是为了减少程序猿们的文字工作。以前的开发模式，特别是需要CMMI3以上的，开发过程中各种文档，写的项目成员是欲仙欲死。所以现在流行敏捷开发，开发文档少，程序猿童鞋举双手赞成。但这种开发模式对团队人员的技术能力以及沟通能力都有比较高的要求的。国内敏捷开发就是产品经理一通抄，一天搞定一个原型，大概过下主流程没问题就开干。遇到原型不清楚的就靠程序猿童鞋问，或者自己拍脑袋自己发挥。发挥出一个版本，客户不满意，接着第二，第三个版本搞起来。这样赶项目，程序猿童鞋自然是各种偷懒，能省则省。测试测出来就改，没测出来等上线发现bug，测试背锅。测试上线报告这个时候，需要把项目的bug情况介绍下，只说测试用例覆盖的已经完成，发现的bug已经修复，然后把是否能上线权限给产品或者项目经理，同时没bug这种事情绝对不能说满，凡事留一线。