测试总结之交换测试、用做记录的方法整理思路、“这不算BUG”=危险信号

1、交换测试执行内容，熟悉整个系统的功能

在一个多人测试的项目中，如果每个人只负责测试固定的模块，可能会因为各自业务熟悉而很快的找到BUG，但是也可能会着眼于各自模块而忽略模块的关联测试，也可能会因为一人的缺失而影响整个项目的测试。一个人进行测试，往往从自己的惯性思维出发，可能会遗漏一些问题，而其它人参与测试，可以减少这种问题。还有在个别人员的调离情况下，减少对整个项目测试的影响。我希望在测试条件允许的情况下，经常交换测试执行内容。正如，这个版本设计测试与执行测试的内容交换，即相互按照对方的写的用例执行。这个，还有涉及设计与执行分开，目前还有一些项目还是测试人员自己写测试用例，然后自己执行。这样，往往会因为是自己写的用例，在执行中抛开用例执行，最后填写执行日志，测试用例没有起到作用。

2、测试执行中用做记录的方法来整理思路，提高测试执行效率

这个是针对个人而言。比如由于系统业务复杂，测试一个功能点要考虑多种情况，需要准备各种情况的测试数据，而且有的数据是需要一段时间才能生成。如果事先没有一个清晰的准备计划，就会测试完一种情况，才去想还要准备另一种情况的数据，浪费了测试时间，测试执行效率低。拿我这次的测试来说，要造一些结算的单据，而结算要等待几个小时的时间。之前，我没有去测结算，对这个功能不太了解。自己先想到要造一些不同情况的订单让他们等待生成结算单。在等待的过程中，自己再去测试别的功能。几个小时过去，忽然想到结算单，查看一下，已经生成出来。然后回想了自己要造的不同种情况的结算，发现，结算单不够用，还少了一张。于是重复之前的步骤。可能，有的人思路很清晰或对测试的业务很熟悉，知道自己下一步要做什么，怎么做。但是，相信还是有一些跟我有同样体验的人。俗话说，好记性不如烂笔头。在混乱了一段时间后，承认自己的测试效率真的很低。看到周围的人用本子记录，自己也开始做记录，记下要测试的各种情况，对应的测试数据、用途、测试帐号等都记录下来。等数据造好，根据记录来验证，很方便也很清晰。提高测试效率应该有很多方法，希望通过自己总结或从他人借鉴能找到适合自己、最有效的方法。

3、“这不算BUG”，危险信号

以前是在对内的项目组担任测试工作，测试主要就是按照需求验证功能。之前，有提过一些问题，被各种理由拒绝掉了，比如，查询初始界面不统一，答复是由于做了很多版本，以前的版本的内容修改起来比较困难（而在新开发的功能中也没有一个统一的要求）；做了变更内容，相关的导出仍然是旧的模板，答复是客户没有提出要求；其中很多问题都是以“客户没有要求”为理由拒绝。可能是在这种环境下待久了，对于很多问题都自然的掠过了，没有深究。换了一个项目组，查看别人的BUG，才发现自己只基于需求，验证功能，遗漏了很多细微、异常的问题。有一些问题，自己在测试中也发现了，但随即冒出想法，“这个不算是BUG吧，功能已经实现了”，然后掠过。这种想法对于测试来说，太危险了，无形之中放掉了很多BUG，而这些BUG可能导致严重的问题。比如，一个校验账户状态的BUG：前台一个用户登陆提现，在后台对该用户账户进行冻结，前台提现失败；在后台对该用户账户进行解冻，前台点击提现按钮仍然提现失败。当时，我遇到这个情况，把页面刷新一下，提现成功，然后就觉得没什么问题了，认为刷新一下就可以了，这不算BUG。但是，通过这个BUG发现开发人员处理账户校验的方式有问题，而且问题上升到设计层面。如果不是因为这个BUG而发现，可能开发人员还会在类似的校验中采取这种不合理的方式进行处理，从而可能引发更多的、甚至更严重的问题。这给我上了一课，“这不算BUG”这不应该是随便冒出的想法，而是要进行深究，站在用户的角度上看待问题。