标签：测试经验 量化 测试策略 情况 框架 多少 工具 style 成熟度
如何评估软件产品质量是每个产品测试经理以及每个测试人员都要面对的问题，但是这个问题又没有一个标准的、统一的、可量化的方法。本文根据个人的测试经验说说自己的看法，欢迎探讨。
1、测试过程中，产品相关责任人询问测试能否结束？版本质量如何？能否按计划发布？
2、测试结束，是否允许版本发布？
这里核心的问题软件产品质量如何，我们是怎么评估我们的产品质量的。如果你有自己的评估方法和体系，我想就可以相对比较清晰的回答出产品的质量状况。比如产品测试过程中用了哪些测试方法、发现了什么缺陷，可能存在的风险。如果还有时间，会再做哪些测试去保证测试质量。如果不允许发布，理由是什么。有一套自己的质量评估体系，就不会出现含糊其辞的对于质量的答复或者模棱两可的就发布了版本。
1、版本测试结束，输出测试报告，版本发布。当然，这个过程中会做一些客观的度量数据分析。主要包括需求范围是否100%交付、缺陷加权值是否正常、用例数是否正常等。也包括考虑对异常分布的缺陷值是否做进一步分析或者做了特殊说明、用例数太少是否做了特殊说明等。如果评估没有什么问题，版本就审批通过发布了。这里会有几个明显的问题。我们来分析下：
（1）缺陷值在合理范围内，版本质量就满足发布要求了吗？缺陷严重程度虽然有标准但是不同的测试人员执行起来结果还是会有偏差。
（2）用例数在合理范围内，版本质量就满足发布要求了吗？用例是否有冗余，是否考虑产品特有的典型用例？不同的测试人员用例有效性会有很大的区别。
（3）如果这时评审发现产品某些特性需要补充测试，是否还有时间？已经到版本发布时间了。
2、测试过程中对于答复质量如何或者能不能结束、什么时候能够结束。我比较常见的答复是还有多少用例没有执行、大概需要多少天。也就是以手上的剩余工作去判断测试结束时间。或者答复质量还行，这个版本测试用例是评审过的。
这2种情况是我经常见到的，版本计划安排的测试时间结束版本就发布，至于一些对测试报告中的质疑下面的人总是能找到一个合理的描述去解释，自己有时候确实也没精力去深入分析就把版本发布了。除了几个重要的版本。很少能看到或者听到一个人可以很清晰的去阐述产品的质量如何或者他自己手上的工作如何。
上述发生的问题也描述了，看着好像问题抛的也很合理，是不是就没有办法解决了，个人认为也不是。我理解主要是保证好测试前端工作和把控好测试过程。基于风险的测试策略，主动分析解决，版本发布或者不能发布就不会再最后时间才有定论。
如何评估软件质量，确保软件质量符合发布要求，我理解主要有如下几个关键内容。
这里的需求复杂度主要是指需求实现的难易程度，需要综合考虑开发对需求实现难易的程度、测试对需求可测试性评估程度、是否有成熟的方案、代码是否复用等。通常来说需求实现越复杂，代码量大的版本风险较高。
人力成熟度，需要综合考虑PM、开发、测试人力的成熟度。人力越成熟，开发、测试的风险就会降低。如果是新手开发的模块，就需要特别重视了。当然，在开发、测试分工时，开发经理和测试经理通常是回根据需求复杂度和人力成熟度进行相应的分工。降低版本质量风险。
版本开发测试流程，包括开发团队和测试团队工作的测试流程，从需求进入研发团队到版本发布上线。包括各个阶段的出、入口准则和工作内容、版本发布的准则等。这里重点描述几个环节的出、入口条件和注意事项。
（1）需求准入和传递。需求已签字和所有参与该版本的测试、开发及其他相关人员斗殴参与了需求传递。可以开展开发需求反串讲和测试需求反串讲活动保证开发、测试人员斗殴熟悉理解需求内容。
（2）代码检视。首先确保检视人员，通常是项目组的核心骨干，熟悉业务特性和代码框架。安排检视活动时间，有些项目组会忽略这个活动。同时，输出检视结果，会起到一定的督促效果，也便于回顾。
（3）代码工具扫描。确保项目组规定的代码扫描工具完成，并提供扫描报告，要求扫描结果通过。可以减少代码低级bug、降低圈复杂度，保证代码质量。同时也可以降低后续测试人员用例设计代码覆盖的难度。
（4）测试分层出入口条件。严守各个环节的出入口条件。测试分层包括UT/IT/MST/BBIT/SDV/SIT/SVT等，通常不会分的这么细，根据自己项目情况进行变更。确保各个环节的工作内容、测试对象都已达到出口准则。分析各个环节的执行情况和交付件，调整下一环节的测试策略，确保已知风险尽早解决。
（5）测试用例评审。确保核心人员参与，特别是SE、开发Leader、测试Leader以及核心人员、版本维护人员等。评审形式采用尽量采用会议形式。对于电话会议或者邮件评审，酱油居多，不建议采用，其他特殊情况特殊考虑。评审闭环，确保意见全部修复。
（6）测试策略和测试计划评审。核心人员必须参与评审，包括pm、开发Leader、测试Leader及相关人员等。确保测试任务分工、测试时间合理。不出现明显的时间压缩，因为版本计划通常都是根据发布计划倒排的，所以测试Leader必须有主见，对于测试时间有风险必须及时提出。
（7）测试报告评审。测试报告评审通常都有规定的人员参与。希望到这一步骤时在任何人提出质疑时都可以准确答复质疑。对于版本的质量能有一个相对清晰的描述。虽然很多描述还是依靠主观的。
需求变更在软件开发测试过程都是难以避免，在需求变更管控流程规范下积极面对。做好需求变更管理，分析引入变更对现有交付范围、影响，刷新测试策略和计划。确保风险可控。不能盲目的、一味的接受，避免到最后风险不可控。
软件质量的评估我理解是重在过程。在版本开发测试流程指导下基于风险的测试策略层层递进，降低或者消灭各个环节暴露的风险。确保版本发布上线质量。
标签：测试经验 量化 测试策略 情况 框架 多少 工具 style 成熟度
原文地址：http://www.cnblogs.com/linyfeng/p/7619917.html
