Wordpress支付时效无锡网站优化
缺陷分析
“小李，202504300989这个现场缺陷你负责测试漏测分析，要求用5why方法找到漏测根因，根据找到的根因制定改进措施。你今天下班前完成，完成后立刻通知我，质量部现在每天都在催现场缺陷分析结果。”周二刚上班，就收到萍姐的钉钉消息。
最近两年，现场缺陷每周分析，改进措施随时增加，客户现场缺陷遗漏依旧不断，真不想把时间浪费在现场缺陷分析上面。最近开发递交任务多，已经积压不少任务单，测试工作都完不成，哪有时间搞这个。萍姐昨天通知如果周五下班前完不成测试任务，周六需要加班赶进度。我上周约了朋友这周六去九溪徒步，不能由于分析现场缺陷毁了周六之约，得快速完成分析。
缺陷描述是“做权限等同，选中角色权限时，权限等同后，角色权限被清空了。”做权限等同，怎么会清空角色权限呢？找开发张哥确定引入的任务单，任务单描述是“券商端权限等同时处理太慢，页面卡死，希望优化”。呀！这个任务是我一个月前测的，记得当时根本没提要测试什么角色权限啊。检查一下任务单的修改范围和测试建议，果然没提权限等同对角色权限的影响，看来原因就是开发没识别和告知修改内容。
漏测根因：“开发修改范围评估不全，没将对角色权限的影响告知测试”。
改进措施：“以后开发对自己修改的内容要做准确评估，并在任务单的修改范围和测试建议中写清楚”。
把分析结果告诉萍姐，继续测手上的任务，还好用了不到30分钟，对手上的测试工作影响不大。每天晚上赶赶进度，周五前应该可以把手上的任务完成，不耽误周六的徒步。
“小李，你现场缺陷分析要重做。部门经理张总看了你分析的结果后跟我说：‘我们测试要有自己的判断，不能开发没提我们就不测。如果每次都依赖开发准评估需要测试的内容，那随便找个外包验证就可以了，根本不需要我们这些专业的测试人员。测试人员应该有自己的专业素养，开发的测试建议只是参考，我们需要利用自己的经验和专业能力去发现埋到系统里面的bug。’ 你重新分析一下，必须找出漏测的根因，解决措施要能避免以后出现同类问题。”不到1个小时，一张单子还没测完，就收到萍姐的钉钉消息。周六的徒步大概率要泡汤了。
事件回顾
引入这个问题的需求是修改权限等同处理太慢，并增加进度条。记得那天有10个任务单等着测试，两年前入职的时候平均每天只要测5个单子，现在每天差不多8个，那天要测10个单子，降本增效给的压力有点大。这个需求改动小，就加进度条，并且做权限等同时不要卡死。当时设计了进度条展示、角色等同性能优化两个场景，为了验证原有功能，权限等同后还对比了等同用户与被等同用户的权限。当时测试比较顺利，半个小时就测完了，是10个单子最快的一个。
记得那天把10张单子全部测完都9:45了。回家时抬头看着圆圆的月亮，边走边庆幸自己住得近。公司规定晚上加班到10点后可以报销回家打车的钱，可我虽然只差15分钟也任性地直接往家走，根本不需要等到10点再打车，既节省自己的时间，还为公司省了钱。
原因和措施
回顾当时测试场景，如果做好如下4个方面，有可能发现这个缺陷的。
首先是没有挑选权限等同原有用例做回归测试，确保原有功能的正确性。对于性能优化的场景，应该要找出性能优化涉及模块的原功能测试用例，根据改动影响执行回归测试。在测试管理系统搜了一下人员管理的测试用例，用例库中测试用例三万多条，可人员管理才24条，仅有两条跟权限等同有关还是我自己写的。看来以前的测试用例指望不上，缺的用例也只能发现问题时逐渐补全，现在每天新的任务都测不完，小车不倒只管推，没问题谁有时间去补用例呢。
第二是自己当时没有针对性能优化的改动点设计功能回归测试用例。这个缺陷出现的场景是在权限等同时选中角色权限，等同后查看源角色的权限，就能发现源角色权限被清空了。按照我以往的经验，只会设计权限等同后目标用户权限是否跟原用户一致的测试场景，不会去检查源角色权限，角色权限清空估计只能靠其他使用场景碰巧发现。只靠自己一个人，可能无法完全做好。
第三是开发没有做代码评审。去年萍姐也碰到过性能优化导致原有功能错误的现场缺陷，改进措施包括性能优化的修改必须进行代评评审。这个任务没做代码评审，任务多的时候很多规定的动作都会做不到位。请老大把性能优化需要做代码评审的要求同步给首席架构师，让他们以公告的形式正式发给所有开发。今后性能优化的任务单如果没有代码评审的纪要，我就将任务单打回。
第四是用例没做评审。我们目前对用例评审的规定是：特性需求的测试用例必须线下开会评审，补丁测试用例采用邮件评审，其他日常需求测试用例是否评审没有要求。今后对于性能优化的需求，必须开展测试用例评审。改动点不大的性能优化日常需求，开会评审成本较高，可以像补丁那样采用邮件评审。不过从回复的测试用例评审邮件来看，邮件评审的效果也非常有限。10次评审一两次能回复一两条意见，其他全部是无意见。为了确保邮件评审的效果，可以在邮件中“喊”相关人进行评审，避免评审邮件淹没在邮件列表的海洋中。邮件正文中要明确架构师、设计人员、开发人员、测试经理各自评审的关注点，确保他们认真考虑才能给出答复，提升评审效果。
具体概要如下，首先是标题：【测试用例评审，需要回邮件】xxx测试用例评审。在标题中明确收到邮件的人需要做的动作，引起大家注意。
正文概要：本次性能优化需求和任务单链接如下，测试用例见附件，请各位同事参照以下要求进行评审。
【架构师】 请关注测试用例对架构层面影响进行是否充分覆盖、跨模块交互场景是否覆盖？如果覆盖全面，请回邮件覆盖全面，如果需要补充，请邮件回复需要补充的内容。
【设计】xxx，请关注性能用例是否覆盖设计中性能优化的预期场景、测试用例数据是否覆盖足够的边界值和异常输入等场景？性能优化是否有需要覆盖的可能影响的数据处理逻辑，功能测试是否覆盖可能影响到的功能？如果覆盖全面，请回邮件覆盖全面，如果需要补充，请邮件回复需要补充的内容。
【开发】xxx，检查测试用例是否覆盖性能优化所有代码改动点、异常处理逻辑是否得到有效验证？如果覆盖全面，请回邮件覆盖全面，如果需要补充，请邮件回复需要补充的内容。
【测试经理】xxx，请关注评估测试用例的策略（如性能测试前置、回归测试后置）和覆盖范围是否合理，是否存在测试盲区？检查测试用例的格式、步骤、预期结果是否规范清晰？如果覆盖全面，请回邮件覆盖全面，如果需要补充，请邮件回复需要补充的内容。
总结
任何一个测试任务都不是孤立的，我们测试的对象是整个系统，不是单个的需求，更不只是一个任务单，要在整个系统层面考虑修改点可能的影响范围，然后针对性地开展测试工作。