常用的一个分析参数应该有"缺陷所属模块（子项）",那我们就从这里开始引申
步骤：
1，上线后缺陷所属模块--》缺陷定位--》快速进行复测试，找到原因--》解决该缺陷，用户满意。OK先解决完了用户使用的问题，然后开始内部分析
2，既然叫成了缺陷，我们就不纠结这东东到底是不是缺陷，一般用户用的很不爽时，反鐀给客服或维护部门的，一般都能当成缺陷，不同的是这个缺陷是在哪个阶段产生的，最后流入了市场。
针对这些上线后的缺陷，这次提取基本可以分析缺陷的所有关键指标：
指标1：上线后缺陷数量，
指标2：缺陷分布模块，
指标3：缺陷产生原因，
指标4：缺陷发生周期（上线后多长时间发现的）
指标5：缺陷解决周期（问题多长时间解决）
指标6：缺陷后果记录
指标7：缺陷解决情况（临时解决？彻底解决？持续改进？）
3，有了第2步一些指标，可以各个指标分别进行分析，然后再进行一个综合分析了，分析的原则是：
实事求是，不扯皮；分析的目的是：改进，后绪各部门工作指导，不再犯
分析过程记录：
A,缺陷遗漏率:通过【上线后缺陷数/（上线后缺陷+过程缺陷）】得出，确定这个是否满足测试中的遗漏标准，如果这个比率超过测试部门接受的区间，该测试过程中，注定有败笔，进一步深入分析；如果遗漏率极低，在标准控制之内，那就不用太过惊慌了，但也要正常的把各指标分析完成。
B,缺陷分步区域：这块儿就细化到开发，测试范围中去了，可以分析缺陷所在的模块的用例的覆盖情况，如果有10个用例执行，发现了5个缺陷，上线后遗漏1个，那这个用例执行的覆盖率应该是【10/(10*(5+1)/5)】*100%=83.3%;这个数值是这样理解的，有17.7%工作，应该是需求开发测试没有执行到位的，或者是用例遗漏的，这两个面进行再分析，如果是用例设计有遗漏，那从部门内部，进一步强化用例设计执行和管理，把用例再审一下，确定遗漏的用例，以后设计时尽量不再犯；如果是工作没有执行到位，把需要补充的工作列出来，协调几个相关部门，把工作给补上，并且可以写入一个意外记录参照表，以希望以后的工作中不再出现类似的工作疏忽或遗漏。
C,缺陷产生原因，这块儿可以和开发过程中出现的同类原因的缺陷放一起，这样，会加重某些原因产生的缺陷的占比，使缺陷产生原因的占比数据更精确，便于把产生原因较集中的缺陷拿出来，共同讨论下一步的工作方式，怎样可以降低这个产生的原因。
D,缺陷发生周期，主要分析缺陷为什么会短期发生，或长时间后才发生，用户使用是否频繁，系统是否有过更新或优化，系统是否进行了重构等，这些，都会造成一个上线后的缺陷的发生周期有长有短，通过对缺陷的周期长短进行分析，得出系统的稳定性方面的一些有价值的结论。
E,缺陷解决周期，要分析这个问题的成本，用了多少人力，多长时间等。
F,缺陷后果记录，这个主要是做为我们的工作的“黑榜”，列到相关的共享版块，提醒着我们曾经发生过什么檅的上线缺陷，造成了多大的错误或损失。
G,缺陷解决情况，把上线后产生的问题，统计一下，看哪些问题是不会再现的，哪些是临时处理的，以及哪些是需要持续的改进的。对于彻底解决的，我们要分析如何彻底解决的，解决的方法是什么，然后，做出补充性的测试过程，进一步测试确定在真的不会再出现；临时解决的，要分析会不会对系统的其他地方造成另外的缺陷，用户是不是可以接收临时解决的方式，我们测试这边在这个问题的后期测试上，需要关注什么？持续改进的，只能测试进一步跟踪，直到问题解决。
以上是个人工作中的一些总结以及和部门内同事讨论后，自己随笔做的一些记录。因为想要换份工作，这一段心态比较放松，心里绷着的弦一下子松了，整个人感觉很累，不想再做一些深入的思考，先给自己放几天假再谋求以后的发展。
欢迎拍砖和补充。
可以把上线后的缺陷的分析提取的一些量化数据，和开发测试阶段的做个比对，做个图表，也能直观的反应一下项目的测试质量。
