为什么把软件测试的目的定义为只是发现错误？这是软件工程的一道课...

一个软件的成型和从业者的角色密不可分，软件测试者最主要的工作是提前发现软件中的种种缺陷，发现的问题提交给开发者来进行问题定位及修正，这样的分工才让这个工作流程更加便捷，毕竟术业有专攻.从这个层面上来说软件测试的目的简单的说是发现软件中的缺陷，专业的说是质量保证，只有通过测试人员的认可这个软件才可以上市或者发布.如果从测试驱动开发的层面来说，测试人员不仅仅只是发现问题就了之了这么简单，测试人员要对发现的缺陷问题进行分类汇总分析及问题的初步定位，帮助开发人员更好的了解开发的软件本身的优势及缺陷，开发人员会根据测试数据分析合适的调整开发适配方案，从整个软件开发进程上说不定会少走很多弯路.发现错误很容易，但是如果发现软件较大部分的错误那就很难了，这其中包括功能性缺陷、性能性缺陷、UI SPEC需求不符方向性错误缺陷、用户体验不够优化等缺陷，所以呢软件测试可以诙谐的认为“目的很单纯，路径很曲折”

软件测试人员遇到发现的bug不能重现怎么办

展开全部 1、在A版本发现的bug应该在A版本进行重现我们知道，有很多原因会导致A版本的bug可能不能在B版本重现：1）开发人员自己偷偷解了bug，以免受到KPI考核；2）环境差异，可能B版本的代码在A版本的环境也会出问题，但是在开发环境可能就不能复现；3）代码变更，也许是其他的代码引起的bug,B版本时其他开发已经修改，此类可以归纳为相关联功能引起的bug;4)AB两版本进行复现的前置条件及步骤已不同。

既然有这么多可能性，那我们就应该排除影响，让问题简单化，保持环境和代码一致的情况下进行复现。

A版本的bug如果在B版本不能复现，时间和条件允许的话，那就回退代码到A版本，有个前提不用回退，那就是已准确定位问题了，并且确定在B版本已经解决它了。

2、项目时间允许的情况下，开发人员应大力协作复现bug对于”疑难杂症“，开发人员应大力配合测试人员进行复现：1）如果对于不好调试的代码就打印更多log;2）可以通过连接测试环境数据库并回滚代码到A版本，根据获悉的已有情况添加断点调试代码；3）做更细致的code review等等方式。

在自己负责的那部分代码确定完没有问题，这时候就需要考虑到接口，是否在接口数据处理上的问题，就需要其他开发人员配合。

而测试人员需要尽最大努力来还原当时的场景：环境，数据，前置条件及测试步骤等。

3、测试人员要再次确认用例设计的覆盖度及周密性有几种情况会导致不可复现：1）环境；2）代码；3）数据。

而数据又可以归纳到代码容错性处理上，环境其实是可以很好还原的，那出现不容易复现的bug就大多数是归于代码和数据上了，对于测试而言，用例设计的覆盖不够，不够严谨就会导致bug不在我们的掌握中。

这个时候，我们有两种情况：一是原本用例就没有好好设计过，未经评审过，大家测试时就很随意，勿容置疑，赶紧把用例好好琢磨琢磨，再叫上项目相关人员进行评审，这么做的目的也是为了保证测试用例得到了项目相关人员的认可，各种情况大家都讨论过，保证在需求上大家的一致性，保证软件覆盖度能满足本次项目需求的要求，做到需求100%覆盖，开发人员若再提出更多建议，那也可以弥补一些黑盒测试时可能遗漏的情况；二是该项目已经经过严格的需求评审及用例评审了。

当然，即便如此也不能避免漏测以及对特殊情况的考虑。

当然，要这么做的前提是这个bug很严重，影响了版本的发布，有必要召集大家协力解决掉它。

4、绞尽脑汁，它仍然不能复现时，保持关注我相信，通过以上步骤的努力，仍然不能复现的bug一定是优先级不高的，那就再评估重要度，若通过项目组决定不影响版本发布，就密切关注此bug，在发布后验证时也重点关注下。

而且该bug不能关闭，依次往以后版本中顺延，并且每轮测试时都要尝试再次复现。

那何时可以关闭呢？也许3,5个版本发布后，没有出问题就可以决定关闭它了。

5、思考测试流程及测试规范，及时更正走过的弯路，制定提交bug的规范，便于开发及我们自己复现有一次，就会有第二次，我们应该及时响应，即便不能亡羊补牢，也要防患未然。

提交bug的规范，这个可能每个公司情况不一样，有些公司木有限制，提交的bug也是千人千面，这对于开发人员理解bug和复现bug无疑增加了难度。

而规范了bug提交，若记录了此bug的前置条件，使用的数据及操作步骤，可能会大有益处。

当然，此处不是说每个bug都这么详细。

希望能帮到你，望采纳！

软件测试是否以发现错误为唯一目的？

测试分QC和QA，不同阶段的测试有不同的目的，软件测试的目的定义为只是发现错误，主要还是由于传统的缘故，比如《软件测试的艺术》书中就给测试下了如上定义，但时隔几十年，不能说错，只能说有点老了，在目前敏捷比较流行的概念中，测试就不再单单是为了发现错误，测试可以是杜绝错误，测试可以是提升用户体验，测试可以是帮助软件提升使用效果，测试可以是帮助开发、测试人员更好地成长，测试可以是帮助项目组更好地了解需求，测试也可以是帮助公司打造精品产品的一种方式，一切皆测试，测试非一切，不要给测试下明确的定义，只要竭尽全力、换位思考、有效沟通、提升质量，何必在乎测试的定义！ 仍然向先辈们致敬，我们是站在巨人的肩膀上成长的！...

转载请注明出处51数据库 » 软件测试只能发现错误而不能保证测试后的软