软件测试常见问题种种.doc

软件测试常见问题种种（一） 关于概率性问题 软件测试中常见的一个问题就是概率性问题，概率性问题无论对软件测试人员还是对开发人员而言都是比较头疼的一个问题。这种概率性问题在测试中该如何处理呢？ ? 首先，概率性问题也是问题，这种我们千万不能一笑而过，在这种情况下测试人员要将这些问题记录下来，多做测试，看能否找出问题产生的规律。 ? 其次，我们要对所出现的问题进行评估，看这种问题的严重性，如果是比较轻微的问题，对用户使用没什么影响，也不会影响到软件其他方面正常工作，那在这种情况下如果开发人员很随手就可修改的话，那就进行修改；如果修该起来耗时耗力的话，则可征得有关人员同意后进行keep. 再者，对于比较严重的概率性问题，如死机、系统崩溃等情况，在记录下问题的同时要及时通知相关开发人员，测试人员和开发人员商量解决如何再现并最终解决问题。对于这样的问题一定不能放过，记得以前在给佳能做传真机测试的时候，遇到一个出现系统自动重起的问题，结果为了抓这个问题，几个测试人员专门盯着这个问题反复的测试，为了这个问题整整测了一个星期，好在问题最后得一解决。 ? 第四，有些问题用语言文字描述可能很难描述清楚，对于这样的问题，测试人员再进行描述的时候，有条件的话可以抓图和提供测试log.当然，如果有再现的话，最好通知开发人员，让开发人员确认问题的现象，毕竟百闻不如一见！ ? 第五，概率性问题产生的原因可能是累积性问题，是一系列复杂操作引起的，而有些可能是时间点的问题，只有在某个瞬间进行操作才能出现，过了那个时间点进行操作时就不会出现问题，这样的问题测试人员在测试时和记录时都要注意采取合适的测试策略。 ? 第六，有些概率性可能和测试人员的操作习惯有关，一个测试人员测试出的问题有时候即使描述的很详细，让另一个测试人员来测，可能都很难发现问题，所以概率性的问题在解决之后最好由相关测试人员进行验证。 ? 第七，对于在一些难以重现的比较严重的概率性问题，有关测试人员还可以大范围的搜集相关信息，如可以群发消息询问其他测试人员或者产品试用人员，看他们在测试过程中有没有出现有关现象，搜集的信息越多越容易分析出问题的规律、原因，这样也便于开发人员解决问题。 ? 第八，对于一些让开发人员也束手无策的难以再现的问题，这种情况下可以使用带trace的版本进行测试，再现时直接分析相应的log记录。当然这些都属于开发人员解决问题方式方法范畴，相信他们都有自己独到之处，在此就不班门弄斧了。 不确定的问题 ? 实际测试中会遇到这样一种情况，有些现象（在确定是问题之前最好用现象来描述）出现了，测试人员很却难确定这种现象是正常的还是一个bug，造成这种情况出现的原因测试人员对软件需求、规格要求等不是很清楚，当然很多情况下根本就没有相应的明确规格定义，尤其是一些比较复杂的大型项目时，其规格、需求往往很难做到那么完善，有很多都是在开发过程中遇到时再进行定义。 ? 针对这种问题，测试人员可以先不要进行匆忙提交，冲动是魔鬼，冲动是会受到惩罚的！建议采用以下方式处理： ? 首先，查看确认软件规格说明和需求文档，当然也可以采用更快捷的方式——直接让相关开发人员确认。这种情况的好处在于快捷，而且可以避免出现需求规格有变更后，而测试人员未有及时得知从而导致判断失误的情况出现。测试人员辛辛苦苦提出的一个“bug”结果被驳回说那不是bug，需求就是那样定义的情况真的就不太好了。 ? 实际工作中出现不是bug的bug时，有些开发人员会相当反感的，所以还是要三思而行。 ? 其次，偶尔有确定不了的问题请相关设计人员确认还可以，如果次数多了，那就不太好了吧，而且有时候就根本不方便向有关设计人员确认，所以当遇到有些确认不了的问题的时候，如果规格也没有明确定义，则可以选择市场上比较成熟的大品牌同类产品进行对比测试，这也是在测试过程中常使用的一种方法。一般在开发一款产品的时候，公司都会购置几款同类产品做参考。 ? 再者，如果出现测试人员确认不了的问题，也可让测试组内部其他人员进行测试确认，俗话说：三个臭皮匠，整死诸葛亮。多一个人确认其结果毕竟更为可靠些。 ? 最后，当一个难以确定的现象被证实是一个bug时，再进行提交，不是一个bug更好，皆大欢喜！ 软件测试常见问题——(三)测试流程常见问题 1、 测试人员要需要何时参加需求分析？ 原则上，测试人员对需求了解得越深入对测试工作越有利，所以最好一开始就应该参加需求分析工作。这样可以带来如下得好处： ????????? 测试人员全程参与需求分析，对需求了解很深刻，减少了很多与开发人员的交互，节省了时间。测试人员参与前期开发讨论，直接掌握了不清晰的需求点； ????????? 早期确定测试用例的编写思路，为测试打好了基础； ????????? 可以获取一些测试数据，为测试用力设计