一个软件如何确定测试结束点呢？（08-08-25）（获奖名单已公布）
请各位同行踊跃发表自己的看法和提出自己宝贵的建议。感谢会员wuhandf提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
非常感谢各位会员积极参与，截止至8月31日24：00分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。
获奖名单奖项获奖名单奖励答案链接
一等奖爱吃鱼的月亮当当购物卡50元13#
二等奖goal1860300论坛积分15#
三等奖archonwang100论坛积分 9#
1、首先对每个人测试人员收集测试人员个人的看法，如果都认为是是测试完毕的话，那在看看每代码发现的缺陷和缺陷的走势是否是正常，如果都是正常的话，我认为是可以结束测试的。
2、如果发现不正常的，则找相关的测试人员和开发人员进行讨论，让测试人员对测试的内容进行讲解，如果大家评审结果，测试是全面的，那证明开发确实写的好，那也是可以结束测试的。 以下仅个人看法，不足之处还请补充：
1.在软件开发前期就制定好了项目结束的时间，这种情况下测试的结束可能就是定义为在项目结束这一时间点上，这种方法是不科学的，是没有办法保证软件的质量，但这种情况也是客观存在的。时间控制上或在做测试计划时未做详细深刻的理解导致测试结束点就定在项目结束点上。
2.时间充裕的情况下做测试结束点，这时候就要按照测试规范，制定测试各个阶段的停止标准，结合客户需求，通过各项评审、验收完后就可以作为测试的结束点。
总结：
无论怎样划分确定软件测试结束点的方法都只是理论的，要结合实际情况具体分析、充分理解测试的根本目的、融汇各种测试方法才能找到一个适合自己公司的方法，测试要以需求为最低标准，在验证了所有需求的前提下进一步的进行测试，不能验证所有需求都通过的测试是不能够结束的，在一定的范围上可以制定一些相应的标准，从测试方法的选择上来衡量软件的质量。
如何确定测试结束点
一点个人看法两个方面：
一、如何制定测试计划，确认测试结束时间；
二、执行过程中，如何确认测试是否达到了结束点；
*****一、测试结束点应在计划（项目计划，测试计划）中明确标记，必要的Milestone标志
计划中的测试结束点由以下几个条件决定
1）整个项目的deadline
项目的deadline决定了整个项目的周期，同样会影响到测试计划的制定和执行。
在时间条件允许之下，越充分的测试越好，因为总是可以发现问题。
如果整体时间条件不允许，要针对最终的交付物及最终使用者的使用情况，制定有效的测试策略，从而适应整个项目的交付需要。
毕竟，任何事情都有轻重缓急，最佳的方式是全部拿下，而条件不允许的情况下要根据实际情况相应调整。
注：条件不允许是指整体的开发时间的影响或是受市场方面的时间限制，而不是由于开发时间不足而单一的压缩测试时间。
2）组织级财富库的项目测试数据积累
确定一个项目的测试结束点可以借助以往的项目测试数据的积累，参考与之相当规模的项目的测试时间，从而估算出相应的测试周期和测试结束点。需要考虑，整个项目的规模，人员素质，技术要求，相关的资源分配，彼此的配合等诸多因素。
注：具体的可以参考相关的评估方法
3）测试者经验
测试者的经验也会影响到整个测试计划的执行，要考虑到测试人员的工作能力，工作效率等诸多因素。
注：如果没有项目数据积累，测试者的经验对确认最初的测试执行和结束时间将起到重要作用。
*****二、测试结束标准（相关理论书籍均有介绍）
1.系统功能实现并测试通过
1) 需求所描述功能全部实现并测试通过
2) 潜在需求实现并测试通过
3) 客户提出的个性化需求实现并测试通过
2.测试用例评审通过并执行通过
1) 测试用例经过严格评审并通过
2) 用例覆盖到所有功能点
3) 用例全部执行通过
4）完成了即定的测试计划中的测试内容和轮次
3.所有问题都处于稳定状态：或半闭，或延期，或挂起，或不修改
1) 所有处于延期，挂起和不修改状态的问题都经过第三方的确认，并由相关人员签署修改意见
2) 延期的问题需要明确什么时候修改完毕
3) 挂起的问题需要明确什么状态下会激活并重新评估修改和测试所需时间
4) 不修改的问题需要明确不修改的原因
注：最终确认人的备注十分重要，可以帮助其它项目成员理解BUG的处理情况
4.提交相应的测试报告，得到项目组成员认可
1) 报告当前的测试状态，BUG收敛趋势等
2) 有效反映BUG的分布，有效分析存在的问题
3）存在的问题及风险，帮助PM及后期发布规避相应风险 达到定义好的需求范围就可结束测试 一、测试覆盖率：
1. 经过内部，外部评审后的测试用例要100%执行，力求测试用例80%覆盖需求功能点
二、缺陷跟踪和修复率：
2. 将所有已发现的缺陷(至少80％)都纳入缺陷追踪系统且划分缺陷的级别
3. 如果缺陷的级别由低到高可分为Minor, Major, Critical 和 Blocker的话(以Jira为例)，我们期望产品发布前无Major以上的缺陷存在。Minor级别的存在率不超过5%
4. 产品的缺陷率要随着测试周期的增加而收敛
三、非功能性需求的测试
5. 完成系统的性能和稳定性等其它方面的测试
四、验收测试
6. 制定和评审验收测试执行计划和标准，产品可以通过需求方的验收测试 如何确定测试结束点，个人观点：
1、测试趋势图是否符合常规趋势，如是否已经达到峰值，并逐渐不规则收敛，且当前处于稳定收敛期。
2、符合公司规定的测试通过准则：如一级、二级缺陷全部关闭，三级缺陷95%关闭。
3、总结用例的执行效果，检查是否有用例没有被执行的情况，进行抽样测试。
4、检查测试的执行过程是否满足测试申请中的输入条件，包括多环境的测试是否全部执行。
5、总结近期是否有新的需求或设计变更，对当前系统的影响程度，可以通过测试提交缺陷来分析，判断对系统的影响是否会推迟测试结束。 个人观点,不足之处请指正:
1.在制定测试计划的时候,明确测试范围、测试粒度和通过准则等.
但往往我们在测试过程中会遇到变更,比如加新功能等.这时我们同样需要对上述计划里的内容作变更并评估.
2.就如楼上几位朋友所说的那样,统计分析BUG曲线走向,如果发现的BUG数量与修复的BUG数量都趋于稳定(这两条曲线最终要重叠到一起),可以认为测试结束.同时需要保证所有的用例都至少执行了一遍.
3.如果上述条件都满足,但计划的测试周期还未结束,我们可以继续做一些随机测试,直到时间结束. 关于这个问题，说说自己的一些看法。请大家指正参考。
1. 原则上来讲，我们更希望一种规范化开发的体系来规正这个命题，不需要为此伤脑筋。但在里程碑或计划的截止时间点能结束测试对大多数的软件项目仅仅是一种期望，而不是既定的现实。理想的情况下，我们可以严格执行计划，然后在计划要求的deadline或者里程碑点上提交交付件，以确认该里程碑是否达到要求，是否可以进行下一阶段的工作——但正如前提所言，这个仅仅是理想情况
2. 现在让我们现实一点。我们为什么会有这样的问题（一个软件如何确定测试结束点）？往往就是因为我们不知道何时可以结束一个软件的测试。不管教科书上如何说明一个软件只要还在生命周期内，就无法结束测试，但现实要求我们在某一个时间点上，结束对软件某一阶段的测试。那么，这个问题实际上就已经转化为确定该阶段测试的结束点的方法了。这个方法可能是一种规范，一套流程，一些交付件，一些评审，一些由统计学原理得出的收敛曲线或者仅仅只是一些确认而已。而个人认为，无论这个方法是何种形式的，其基本的要求就是能达成一种协议，确认该协议生效——那么这个阶段的测试就结束了，至于这个点在什么时间，我想就是完成所有要求的这些确认的时间而已。
[ 本帖最后由 archonwang 于 2008-8-27 11:05 编辑 ]
生命周期内软件的测试结束点
很明显，只要在生命周期内，这个软件将持续测试到该软件的生命周期结束，所以无所谓测试的结束点，只有阶段测试工作的结束点。笔者没有参与过这类软件整个生命周期，但从其需求直到产品上市的维护阶段略有所了解。这里仅讲下软件上市前的测试结束点的确认。
1. 确认所有需求、设计、方案、测试、维护及用户培训等文档的完整性
2. 确认所有代码-文档间的对应状况（抽检核心设计编码及文档对应关系）
3. 确认需求覆盖率
4. 确认测试对应的需求覆盖率和测试覆盖率
5. 确认当前软件的所有出现的缺陷修复状况是否已满足了当前测试阶段结束的要求
6. 确认当前软件的缺陷的各项收敛情况
7. 确认当前软件的性能及安全性状况（若有安全性方面的需求的话）
当以上条件满足时，可认为当前阶段的测试结束
以deadline为目标，如何确定测试结束点
这个问题说起来简单也简单，复杂也复杂。判断的最基本标准就是：是以软件的阶段为衡量基准还是以当前阶段的质量达标为衡量基准。如果是以软件的阶段为衡量基准，那么就很简单，只要到了这个时间点，即使软件开发的质量很差，也认为测试即刻结束。在外包领域，尤其是国外的外包项目上，使用这种方法的风险很明显，虽然按时交付，但产出的软件质量很差，有时甚至没法用，所以这种方法往往还要配上另一个附加项：保障基本功能的实现和使用；
如果是以当前阶段的质量达标为衡量基准，那么就需要优先把这个达标要求限定。常见的是：需求覆盖情况，缺陷等级、数量及缺陷收敛状况等。在未满足这些标准前，测试将一直持续直到达成最低标准。这种方式目前用得非常广泛，但是这种方式对质量的追求也不是无止境的。
在某一个阶段达成某个标准的最低值可能是比较好的策略，但也不是绝对的终极策略。只能说是进度与质量的双重平衡，而测试的结束点可能就是其中一个比较重要的标志环。
[ 本帖最后由 archonwang 于 2008-8-27 11:04 编辑 ]
总结
关于这个问题具体的解释和解答，我想最终还是以目标导向为主的。无论如何确定测试的结束点，总归摆脱不了测试的流程、规范及相应的标准，也不可能脱离这些内容在执行结束之后对结果的确认和认可。毕竟，结束不结束，并不是一个测试经理或测试团队说了算的。为了配合目标的实现，测试即使已经达成了具体的标准或已确认的协议，而有可能需要继续进行下去。我想，这个可能才是这个问题的核心。一个软件如何确定测试结束点呢？
在软件消亡之前，如果没有测试的结束点，那么软件测试就永无休止，永远不可能结束。软件测试的结束点，要依据自己公司具体情况来制定，不能一概而论！个人认为测试结束点由以下几个条件决定：：1．基于“测试阶段”的原则：
每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段，我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标准后，再进行后面一个阶段的测试。举个例子来说：单元测试，我们要求测试结束点必须满足“核心代码100％经过Code Review”、“功能覆盖率达到100％”、“代码行覆盖率不低于80％”、“不存在A、B类缺陷”、“所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准”等等标准。集成测试和系统测试的结束点都制定相关的结束标准，当然也是如此。
2．基于“测试用例”的原则：
测试设计人员设计测试用例，并请项目组成员参与评审，测试用例一旦评审通过，后面测试时，就可以作为测试结束的一个参考标准。比如说在测试过程中，如果发现测试用例通过率太低，可以拒绝继续测试，待开发人员修复后再继续。在功能测试用例通过率达到100%，非功能性测试用例达到95%以上，允许正常结束测试。但是使用该原则作为测试结束点时，把握好测试用例的质量，非常关键。
3．基于“缺陷收敛趋势”的原则：
软件测试的生命周期中随着测试时间的推移，测试发现的缺陷图线，首先成逐渐上升趋势，然后测试到一定阶段，缺陷又成下降趋势，直到发现的缺陷几乎为零或者很难发现缺陷为止。我们可以通过缺陷的趋势图线的走向，来定测试是否可以结束，这也是一个判定标准。
4．基于“缺陷修复率”的原则：
软件缺陷在测试生命周期中我们分成几个严重等级，它们分别是：严重错误、主要错误、次要错误、一般错误、较小错误和测试建议6种。那我们在确定测试结束点时，严重错误和主要错误的缺陷修复率必须达到100%，不允许存在功能性的错误；次要错误和一般错误的缺陷修复率必须达到85%以上，允许存在少量功能缺陷，后面版本解决；对于较小错误的缺陷修复率最好达到60%~70%以上。对于测试建议的问题，可以暂时不用修改。
5．基于“验收测试”的原则：
很多公司都是做项目软件，如果这种要确定测试结束点，最好测试到一定阶段，达到或接近测试部门指定的标准后，就递交用户做验收测试。如果通过用户的测试验收，就可以立即终止测试部门的测试；如果客户验收测试时，发现了部分缺陷，就可以针对性的修改缺陷后，验证通过后递交客户，相应测试也可以结束。
6．基于“覆盖率”的原则：
对于测试“覆盖率”的原则，个人觉的只要测试用例的“覆盖率”覆盖了客户提出全部的软件需求，包括行业隐性需求、功能需求和性能需求等等，只要测试用例执行的覆盖率达到100%，基本上测试就可以结束。如“单元测试中语句覆盖率最低不能小于80%”、“测试用例执行覆盖率应达到100%”和“测试需求覆盖率应达到100%”都可以作为结束确定点。如果你不放心，非得要看看测试用例的执行效果，检查是否有用例被漏执行的情况，可以对常用的功能进行“抽样测试”和“随机测试”。对于覆盖率在单元测试、集成测试和系统测试，每个阶段都不能忽略。
7．基于“项目计划”的原则：
大多数情况下，每个项目从开始就要编写开发和测试的Schedule，相应的在测试计划中也会对应每个里程碑，对测试进度和测试结束点做一个限制，一般来说都要和项目组成员（开发，管理，测试，市场，销售人员）达成共识，团队集体同意后制定一个标准结束点。如果项目的某个环节延迟了，测试时间就相应缩短。大多数情况下是所有规定的测试内容和回归测试都已经运行完成，就可以作为一个结束点。很多不规范的软件公司，都是把项目计划作为一个测试结束点，但是如果把它作为一个结束点，测试风险较大，软件质量很难得到保证。
8．基于“缺陷度量”的原则：
这个原则也许大家用的不是很多，了解比较少。我们可以对已经发现的缺陷，运用常用的缺陷分析技术和缺陷分析工具，用图表统计出来，方便查阅，分时间段对缺陷进行度量。我记得以前zhuzx在这个论坛上提出过缺陷分析技术这个问题，我不再重复讲述。我们也可以把 “测试期缺陷密度”和 “运行期缺陷密度”作为一个结束点。当然，最合适的测试结束的准则应该是“缺陷数控制在一个可以接受的范围内”。比如说：一万行代码最多允许存在多少个什么严重等级的错误，这样比较好量化，比较好实施，成为测试缺陷度量的主流。
9．基于“质量成本”的原则：
一个软件往往要从“质量/成本/进度”三方面取得平衡后就停止。至于这三方面哪一项占主要地位,就要看是什么软件了。比如说是：人命关天的航天航空软件,那还是质量重要些,就算多花点钱、推迟一下进度，也要测试能保证较高质量以后才能终止测试，发布版本。如果是一般的常用软件，由于利益和市场的原因，哪怕有bug，也必须得先推出产品，没办法呀。一般来说，最主要的参考依据是：“把找到缺陷耗费的代价和这个缺陷可能导致的损失做一个均衡”。具体操作的时候，可以根据公司实际情况来定义什么样的情况下算是“测试花费的代价最划算、最合理”，同时保证公司利益最大化。如果找到bug的成本比，用户发现bug的成本还高，也可以终止测试。
10．基于“测试行业经验”的原则：
很多情况下，测试行业的一些经验，也可以为我们的测试提供借鉴。比如说测试人员对行业业务的熟悉程度，测试人员的工作能力，测试的工作效率等等都会影响到整个测试计划的执行。如果一个测试团队中，每个人都没有项目行业经验数据积累，拿到一个新的项目，自然是一头雾水，不知道从何处开始，测试质量自然不会很高。因此通过测试者的经验，对确认测试执行和结束点也会起到关键性的作用。
测试结束点
根据需求规格说明书上的内容进行测试，全部都实现了，就OK了！ 这个问题在每一本测试书上都有提到，光拿出来列也没多大意思，就归纳一下吧：1。 组织级的强制退出：
- 项目中止，通常是项目出现了严重的问题或人力不可抗拒因素
- 经费用尽，通常是项目经费没有得到很好的控制，弹尽粮绝，这种情况现在比较少见
- 超过期限，这时最常见的，特别是在传统的瀑布模式下，开发一再延期，导致测试时间不足，只好强行中止，听天由命了
2。达到了功能质量指标。要把所有的质量指标罗列起来太困难了，摆几种常见的退出指标：
- 测试用例覆盖度
- 测试用例的执行率
- 测试平台的覆盖率，像语言阿，操作系统，硬件种类阿等等。这对于一些特殊的测试如配置测试，本地化/国际化测试是至关重要的
- 严重缺陷的修复率
- 未修复缺陷是否被记录了
- *新开缺陷的速度
- *修复缺陷的速度
- 回归测试是否被很好地执行了
- 回归测试的缺陷发现率。（这经常被人忽视，由修复缺陷代码引入新缺陷是测试风险的重要来源）
- *未修复缺陷总数的变化趋势，通常只有快速收敛时才认为是结束测试的好时机
- 文档完备率，决定不修复的问题一定要在发布文档里注明
打星号的三个指标形成的三条曲线通常对于测试来说是最重要的参考依据
3。达到了非功能指标
- 性能指标 （展开来太复杂了）
- 可用性指标（虽说是指标，却很少有硬指标）
- 兼容性指标，特别是对于多组件的应用，对于不同版本的各个组件间的兼容性，有时连开发人员都搞不清楚
- 安全性指标， 及其重要
末了，忍不住又要扯一下敏捷开发。迭代式的开发过程会获得不同的缺陷曲线。似乎找不到哪本书或者文章很好地讨论这个问题。从个人经验来说在客户演示来临前上述的三条关键曲线都会达到一个高峰。而每个迭代的退出时间也通常在演示前不久。还有一个重要的退出条件就是单元测试必须达到很高的覆盖率。因为在敏捷开发中软件的质量很大程度上要依赖于单元测试的质量。而从整个项目生命周期来说缺陷的曲线是呈波浪形的。敏捷开发还有一个特殊的地方。在很多敏捷开发的案例里，并不强求最后所有的需求都要被提交。一些很低优先级但成本很高的功能可能会被取消。所以最后退出的条件可能更灵活更经验化。
13楼的“鱼儿”朋友您真牛，敢于创新的思维，值得我们测试同行学习！！
我可以说是看了不低于10本测试书，基本上都是写了2~3条，作为测试结束的标准，而您能打破常规思维写了10点，并且讲的听清楚，很透彻，谢谢您无私的分享。您那敢于创新的思维，值得我们测试同行学习。
添加一点个人的见解：
个人觉的测试结束了，不见得就测试通过了，能否把测试结束和测试通过做一个折中，那就是最好的结束点了？
有史以来我看到的最权威的测试结束标准
“爱吃鱼的月亮”，你作为测试新手，能写出这样的水平，我个人认为是有史以来我看到的最权威的测试结束标准了，太不简单，真的很了不起，我打心底里佩服您。我同样作为测试新手感觉和您差距太大，相差太远。说说我的观点吧：
我们公司中是以程序中错误的总数量占整个错误的比例，来确定测试的结束点，不知道是否准确？并且要预估开发软件的错误个数。
15楼归纳的比较全面
归纳的比较全面并且一目了然！更远的期待
虽然13楼的测试精英已经回答的不错了，但是我们仍然希望看到更精彩的回答！！！ 个人觉得，测试开始的时候，将测试的各个流程尽量考虑清楚并拟定测试计划，计划中的测试完成应该在项目计划结束时间之前，并且一定要有缓冲时间；测试执行过程中按照各类测试方法完善用例并严格执行测试用例（功能），然后对于用户需要的和核心、常用模块进行性能测试，并解决测试中暴露出来的问题；在测试末期认真完成客户，上司所需要的测试报告，也可以写写测试经验之类的作为自己测试经验教训的总结，还可以帮助测试团队的成长。当然计划一般因为考虑不够周到而导致延误，这个时候就需要利用缓冲时间了。
总之，按照软件流程一步一步来，做到后期就不用到处搬救兵。在这种思路下面，测试组负责人的经验、责任心就起到了很大的作用。
页:
[1]
2
