如何做上线系统的漏测试缺陷分析？(2011-4-11)（获奖名单已公布）
如何做上线系统的漏测试缺陷分析？还有项目的已测试出来的缺陷分析？此话题由会员jimao提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
获奖名单
奖项获奖名单奖励答案链接
一等奖zhyb_200850元移动充值卡21#
新一期的问题，顶起 问题好大，坐板凳学习...:) 可以先解释下你的问题么？“的漏”是什么？ 回复 4# hoppaoy594
如何做上线系统的“漏测试”缺陷分析:) 回复hoppaoy594
如何做上线系统的“漏测试”缺陷分析
hujuanjuan 发表于 2011-4-13 14:55 http://bbs.51testing.com/images/common/back.gif
恩~~ 个人觉得对于“上线系统的漏测试缺陷”分析如下：
首先这种问题的发生，一定不只是测试人员测试的问题，这涉及到上线系统流程以及流程中各个角色的问题。
当出现问题后，测试方面需要先在真实环境下进行问题重现，与开发协助分析此问题发生的原因：
1. bug为主流程或重点功能问题，这属于测试人员的严重错误，出现此错误的原因有几种：
1）一个是测试人员没有严格按照原有测试用例严格执行；
2）一个是开发修复bug后，没有对主流程再次进行验证，导致修复bug过程中引入了新的严重bug；
3）内部测试环境与现场真实环境或配置不同。
2. bug为非重点功能问题，出现此错误的原因有：
1）流程问题，上线系统发版流程中由于没有对发版时间评估错误（没有给测试留出充足的时间）或者没有对测试计划中测试范围进行专业的评审，导致测试内容部分缺失；
2）测试人员人数问题，要由不同人对同一产品进行多轮测试，使测试的更充分。
这是我根据自己工作中遇到的问题想到的，希望对大家有所帮助。 个人觉得对于“上线系统的漏测试缺陷”分析如下：
首先这种问题的发生，一定不只是测试人员测试的问题，这涉及到上线系统流程以及流程中各个角色的问题。
当出现问题后，测试方面需要先在真实环境下进行问题重现，与开发协助分析此问题发生的原因：
1. bug为主流程或重点功能问题，这属于测试人员的严重错误，出现此错误的原因有几种：
1）一个是测试人员没有严格按照原有测试用例严格执行；
2）一个是开发修复bug后，没有对主流程再次进行验证，导致修复bug过程中引入了新的严重bug；
3）内部测试环境与现场真实环境或配置不同。
2. bug为非重点功能问题，出现此错误的原因有：
1）流程问题，上线系统发版流程中由于没有对发版时间评估错误（没有给测试留出充足的时间）或者没有对测试计划中测试范围进行专业的评审，导致测试内容部分缺失；
2）测试人员人数问题，要由不同人对同一产品进行多轮测试，使测试的更充分。
这是我根据自己工作中遇到的问题想到的，希望对大家有所帮助。 个人觉得对于“上线系统的漏测试缺陷”分析如下：
首先这种问题的发生，一定不只是测试人员测试的问题，这涉及到上线系统流程以及流程中各个角色的问题。
当出现问题后，测试方面需要先在真实环境下进行问题重现，与开发协助分析此问题发生的原因：
1. bug为主流程或重点功能问题，这属于测试人员的严重错误，出现此错误的原因有几种：
1）一个是测试人员没有严格按照原有测试用例严格执行；
2）一个是开发修复bug后，没有对主流程再次进行验证，导致修复bug过程中引入了新的严重bug；
3）内部测试环境与现场真实环境或配置不同。
2. bug为非重点功能问题，出现此错误的原因有：
1）流程问题，上线系统发版流程中由于没有对发版时间评估错误（没有给测试留出充足的时间）或者没有对测试计划中测试范围进行专业的评审，导致测试内容部分缺失；
2）测试人员人数问题，要由不同人对同一产品进行多轮测试，使测试的更充分。
这是我根据自己工作中遇到的问题想到的，希望对大家有所帮助。 晕，竟然发了这么多遍:L 还想了解发生这种问题后，测试应该如何避免类似的情况发生？补充用例？完善流程？全员测试？ 个人认为要区别对待：
1.系统上线后，现实环境跟家里的测试环境是有区别的，有很多不明确（所以尽量摸拟真实环境测试很有必要）
2.系统上线后，维护管理得如何（避免人为）
3.如果确实是测试中漏测的，这就是我们测试人员的悲哀，要纳入考核的 老规矩占位先 上线后出现异常，先找到问题原因才能分析是否属于漏测
1.Bug造成，如果TestCase中已有此案例，而没有发现该Bug，则属于漏测，很多漏测都属于执行问题引起；如果TestCase中无次案例，如发生Bug，则不属于漏测范围，属于需求缺陷---建议在测试项目开始前先完成TestCase评审，确保执行Case正常；同时测试负责人需要和研发负责人明确漏测定义
2.上线应用配置造成，造成的原因往往是发布应用的某项配置遗漏配置，上线应用版本以及配置项的正确性由SCM负责---建议在上线前进行上线预演，确保相关配置项的正确性，避免测试正常上线异常的情况发生
3.发布过程异常，造成此类问题的原因有很多，如应用发布顺序错误，第三方Jar包的加载顺序错误，数据库脚本执行顺序异常等，正常发布应由研发以及运维人员来确保---建议在大型项目上线前准备上线CheckList，明确上线应用的发布顺序，数据库脚本执行顺序，各类异常发生时的处理事项等
总之上线的风险是不能避免的，只能降低和转嫁此类风险，不是所有上线问题都应由测试人员来承担 聆听。。 点坐 搬个板凳坐着听 个人理解，上线系统出现问题后，一般比较紧急，优先级应为高，分析流程如下：
首先，定位bug，看看能否复现。 一般是测试协同开发，一起进行分析。根据bug描述，看看能否在测试机上复现。如果可以，则在测试机上分析，尝试查找原因。如果不能复现，则要比较实际生产环境和测试环境有什么不同，是否漏打patch，分析系统运行环境的差别等等。要尽量在测试环境上复现，因为大多数情况是不允许开发在实际生产环境上进行调试的。
然后，Dev进行修复。bug复现之后，Dev进行代码跟踪，查找失败原因。有经验的测试人员，这时也能够进行一些分析，缩小可能出问题的模块，甚至指出那个模块的问题。总之，协助dev尽快修复。
再者，Dev发布patch，QA重新测试。不仅要确保bug已经修复，而且要在有限的时间范围内，尽可能的覆盖受影响的模块。如果有条件的话，要尽可能进行自动化回顾测试。
最后，patch进入生产环境。 如何做上线系统的漏测试缺陷分析？还有项目的已测试出来的缺陷分析？
==>
对于已经上线的系统发现了遗漏的缺陷，
第一：测试人员应该做以下事情：重复操作，是否能够重现缺陷，如果是可重现的问题，那么提交一个缺陷报告（提交一个bug）
第二：项目经理分析这个缺陷，判断是否是一个bug，以及严重程度，判断如何修复这个问题，是否可以等到下一个版本解决或者要发布一个patch来解决这个问题？
第三：项目经理把bug转给负责相应模块的开发人员，进行修改
如果对于是当前项目的bug：
测试人员提交报告，项目经理转给开发人员
对于由于新产生的bug，测试人员应该考虑如何追踪这个bug，如何建立相应的matrix，比如说，有那个测试用例来测试这个bug所涉及的feature。是否要更新TC或者新建TC（test case） 上线之前的缺陷，每个公司都有缺陷分析的参考和相关标准，
常用的一个分析参数应该有"缺陷所属模块（子项）",那我们就从这里开始引申
步骤：
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,缺陷解决情况，把上线后产生的问题，统计一下，看哪些问题是不会再现的，哪些是临时处理的，以及哪些是需要持续的改进的。对于彻底解决的，我们要分析如何彻底解决的，解决的方法是什么，然后，做出补充性的测试过程，进一步测试确定在真的不会再出现；临时解决的，要分析会不会对系统的其他地方造成另外的缺陷，用户是不是可以接收临时解决的方式，我们测试这边在这个问题的后期测试上，需要关注什么？持续改进的，只能测试进一步跟踪，直到问题解决。
以上是个人工作中的一些总结以及和部门内同事讨论后，自己随笔做的一些记录。因为想要换份工作，这一段心态比较放松，心里绷着的弦一下子松了，整个人感觉很累，不想再做一些深入的思考，先给自己放几天假再谋求以后的发展。
欢迎拍砖和补充。
可以把上线后的缺陷的分析提取的一些量化数据，和开发测试阶段的做个比对，做个图表，也能直观的反应一下项目的测试质量。这个大家可以进行一下尝试，附件就不传了。
各位工作愉快，我先放假休息了。
页:
[1]
2
