ss

charlie811

ss

[ 本帖最后由 charlie811 于 2010-8-5 20:18 编辑 ]

dyzyez

我也是新手，不过我觉得第二个问题我会这样回答：根据测试原则，穷尽测试是不可能的。所以在根据产品说明书发现所做的项目符合客户需求，同时在成本上
也要考虑，进一步的测试对系统究竟改进了多少，成本又是多少，如果改进作用不大（即benifit little)，还需要相当大的成本，那么这个时候测试结束了。一般应该是测试经理和开发经理共同决定的吧。

dyzyez

第一题我的理解是根据系统的结构（system architecture)看系统中有多少单元（component），然后项目计划会告诉你什么时候开发人员完成那些单元，根据这个做出测试计划，其实这个最后由test manager定夺的，集成测试如果采用自顶向下的话，那么流程结束了，集成测试也就结束了。我也是新手，回答得不好请大虾们指正

charlie811

谢谢LS的回答，期待更权威的回答阿！！！！！！！！！！！！！！！！

shanshan3346

第二个问题的第二个部分我想会这么回答：软件测试的结束标志首先应该看软件 是否满足了客户的需求，如果满足了，然后对照软件合格国际标准一条条对照看看是不是还有什么不满足的，我是一个刚开始学测试的学生，还处在自学的前期，如果有什么不对，还希望大家能指出来

Giff

呵呵 粗略一看 似乎知道 仔细一想 又不怎么好说了 我也做了有不短时间测试了~不过 个人感觉 这个界定在实际情况中是很模糊的 不好说 不好说；于是马上百度了一下，发现还是有一点理论说法的 呵呵 丢出来了
---------------------------------------------------------------------------------------------------------------

测试退出标准
产品的最终发布日期为2007年**月**日。测试退出标准为完成测试需求中列出的所有功能及测试过程中发现缺陷的回归测试。
    单元测试退出标准
1) 单元测试用例设计已经通过评审
2) 核心代码100％ 经过Code Review
3) 单元测试功能覆盖率达到100％
4) 单元测试代码行覆盖率不低于80％
5) 所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准
6) 不存在A、B类缺陷
7) C、D、E类缺陷允许存在
8) 按照单元测试用例完成了所有规定单元的测试
9) 软件单元功能与设计一致
    集成测试退出标准
1) 集成测试用例设计已经通过评审
2) 所有源代码和可执行代码已经建立受控基线，纳入配置管理受控库，不经过审批不能随意更改
3) 按照集成构件计划及增量集成策略完成了整个系统的集成测试
4) 达到了测试计划中关于集成测试所规定的覆盖率的要求
5) 集成工作版本满足设计定义的各项功能、性能要求
6) 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准
7) A、B类BUG不能存在
8) C、D类BUG允许存在,但不能超过单元测试总BUG的50％。
9) E类BUG允许存在
    系统测试退出标准
1) 系统测试用例设计已经通过评审
2) 按照系统测试计划完成了系统测试
3) 系统测试的功能覆盖率达100％
4) 系统的功能和性能满足产品需求规格说明书的要求
5) 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准
6) 系统测试后不存在A、B、C类缺陷
7) D类缺陷允许存在，不超过总缺陷的5％
8) E类缺陷允许存在，不超过总缺陷的10％

注：这只是一套比较理想化的退出标准，但在实际工作中不可能达到这种程度，尤其是测试覆盖率和缺陷解决率不可能是100%。现在的军方标准是达到99%。对于通用软件来说就要根据公司实际情况了。

------------------------------------------------------------------------------------------------------------

（答案二）

测试结束的标准（Debug版）  
                  -----匆忙编写 待release版
测试结束的标准因各个公司的流程不同而采取的种类十分繁多。举个简单的例子吧，如果一个公司在项目开发的前期就已经制定好了项目结束的时间，这样测试结束的标志就很有可能被定义在项目结束时间这一时间点上，这种定义测试结束的方法即不科学也不准确，没有办法保证软件的质量，但是这中现象是客观存在的，一种情况是时间确实不允许你做更多的测试，这时只能合理的安排测试的进度和时间上的控制，和研发的进度尽量保持一致性；第二种情况是一些对测试没有过多理解或是没有太重视测试的公司在没有详尽的测试计划做知道的前提下将测试的结束点就定在项目结束点上，可想而知这样的定义方式下测试的质量。

     测试永远都不可能发现软件中存在的所有的缺陷，所以人们会将软件中的缺陷分成很多个等级，这也就是我们常常听到的缺陷的严重程度，按照等级和数量的不同一些公司会将测试结束点设置在这些参数的一个合理的范围内，比方说软件在发版之前系统中不允许存在**级别的缺陷，**级别的缺陷不可以超过*个或是总缺陷的百分之几等等，这个也是现在最常用也是最合理的一中确定测试结束标志的方法。

     测试行业兴起没有多长的时间，好多公司为了提高自己软件的质量也纷纷都对自己的产品进行测试，心情是可以理解的，但是会有人把测试当成一种流程，只要走了流程就万事大吉，殊不知软件测试的根本目的是要提高软件的质量，光走流程是没有用的，走流程只能对系统起到最基本的测试，是没有办法发现系统中存在的隐含缺陷的，这也就是为什么说比较有经验的测试工程师能够不必走那烦琐的流程便很容易就能发现软件中隐含的缺陷。所以说走形式的测试是很不可取的。

无论怎样划分确定测试结束标志的方法都只是理论的，要结合实际情况具体分析、充分理解测试的根本目的、融汇各种测试方法才能找到一个适合自己公司的方法，测试要以需求为最低标准，在验证了所有需求的前提下进一步的进行测试，不能验证所有需求都通过的测试是不能够结束的，在一定的范围上可以制定一些相应的标准，从测试方法的选择上来衡量软件的质量，比方说一家公司的软件功能实现上完全没有问题，稳定性也很好，客户可以放心的使用，但是该软件的界面不是很规范，让人用起来不舒服，你可以说这个软件达到了用户规定的功能需求，但外观及其他方面就存在缺陷，所以说缺陷只在测试时是否定义其是否划定在测试范围内，定义好范围就可以制定相应的测试结束标准。

------------------------------------------------------------------------------------------------------------------------

面试的时候感觉可以先这么说一点纯理论的 然后再加上一点个人对实际情况的想法（比如答案二那种），估计面试官应该会很满意了~~~

sbinken

这个问题问得很好，期待高手的回答，最好能结合实际情况

sandy111

标准不一定都能达到，但都是为产品服务，最终要满足客户的需求

fredick

期待中

black_tulip

背一堆答案，有什么用。

charlie811

原帖由 black_tulip 于 2009-3-30 08:54 发表
背一堆答案，有什么用。

关键是现在连答案都不知道呢

black_tulip

建议不要做这一行了。

51testing_zhj

单元测试报告评审并基线化以后就可以做集成测试
集成测试报告评审并基线化以后就可以做系统测试
--------------------------------------------------------------
软件测试结束的标准应该看 测试计划的测试通过标准吧
--------------------------------------------------------------

个人观点