工作中接口测试常见的bug

一、接口参数数据类型：

1. 数值型慎厅迟

2. 字符串类型

3. 数组或者 链表类型

4. 结构体

二、接口测试常见bug：

1. 特殊值处理不当导致程序异常退出或者崩溃

2. 类型边界溢出，导致数据读出和写入不一致

3. 取值边界外值未返回正确的错误信息

4. 参数 为null或空字符串“”等

5. 权限未处理，可以访问其他用户的信息

例如:无权限可以访问，或者 一般用户可以访问管理员权限）

6. 逻辑校宽李验不完善，可利用漏洞获取非正当利益

例如：某网站兑换1块钱需要100币，当小于100币时调用后台 接口是否可以兑换

例如：购物结算时为100元，调用 后台接口设为0元，哈哈

7. 状态处理不当，导致逻辑出现错误（可能程序员123都搞懵了）

8. 数组类型item个数为0或者item重复时程序异常退出伏好

9. 超时问题，超时后处理

10. 潜在性能问题（后台提交处理或者把性能风险提前提出）

软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中发现的错误,将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。在实际软件测试过程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。

错误跟踪管理系统

为了正确跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条条记录输入制定的错误跟踪管理系统。

目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件（商业软件）.Mozilla公冲高竖司的Buzilla软件（免费软件），以及国内的微创公司的BMS软件，这些软件在功能上各有特点，可以根据实际情况选用。当然，也可以自己开发缺陷跟踪软件，例如基于Notes或是ClearQuese开发缺陷跟踪管理软件。

作为一个缺陷跟踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的处理信息的全部内容。字段内容可能包括测试软件名称，测试版本号，测试人名称，测试事件，测试软件和硬件配置环境，发现软件错误的类型，错误的严重等级，详细步骤，必要的附图，测试注释。处理信息包括处理者姓名，处理时间，处理步骤，错误记录的当前状态。

正确的数据库权限管理是错误跟踪管理系统的重要考虑要素，一般要保证对于添加的错误不能从数据库中删除。软件错误的状态

新信息(New)：测试中新报告的软件缺陷；

打开 (Open)：被确认并分配给相关开发人员处理；

修正(Fixed)：开发人员已完成修正，等待测试人员验证；

拒绝(Declined):拒绝修改缺陷；

延期(Deferred): 不在当前版本修复的错误，下一版修复

关闭(Closed)：错误已被修复；

Bug管理的一般流程

测试人员提交新的Bug入库，错误状态为New。高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为Declined状态。

开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。对于不能解决散大和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。

测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。

软件错误流程管理要点

为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测念举试步骤是否准确，可以重复。

每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug状态。

拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。

错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。

加强测试人员与程序员的交流，对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。

作为一个程序员，你发现同事写的代码有Bug，你会告诉他吗？讲真的，这个事情对我来讲，很难，因为我在这个事情上吃过苦头！

看待这个问题首先得看对方脾气咋样，如果对方脾气不好，或者很难搞，还是想想其他办法。直接跟他讲可能会遭到对方的白眼！

别看我们程序员一个个傻傻呆呆的，其实自尊心特别强！除非你是他的领导，否则即使你发现衡察虚了他代码里的Bug，他也不会服你！虽然还是会改，但内心一定在想：“就你能？自己管好你自己就成，看我代码干啥？”

其实我也是这样的心理，好像程序员除非自己愿意，否则都不怎么喜欢别人去研究自己的代码，好像对方故意找自己茬的意思。

但是不管咋样，不管是有意无意，我们既然发现了同事写的代码有问题，就不能坐视不管！

我最近在调一个小伙伴的接口时，因为涉及到数据回滚，所以就想知道他的代码有没有做回滚 *** 作。如果没有，可能我这边数据已经回滚了，他那边没回滚就会导致数据前后不一致。所以我也不是有意要审查他的代码。

然后我就发现他不光没有做回滚 *** 作，也没有做批处理。几个涉及到修改数据的代码就这样一行一行走下来，看着直让人挠后脑勺。

于是我就把这个事情告诉了他，让他要么做事物（如果 *** 作有问题，可以自动回滚），要么做主动回滚。否则我在调他接口时，如果我这边撤销了数据修改，他那边却提交了修改，就会导致数据丢失或前后不一致。

当我告诉他这个情况和解决方案以后，我能很明显地感受到他有点不愉快。但事实摆在眼咐燃前，也只能修改。可修改归修改，他还是有点脾气的。于是他写了一个事物，将大部分涉及到增删改的语句全部包在了里面，唯一把一个删日志的语句留在了外面。

我看到这个情况，就委婉地跟他说：“”好像这个删日志的语句也要包在事物里面哦！”

但是他却说，这个无关紧要，他特意放在外面的。

我跟他说，既然这里有数据存在，就不是无关紧要的。不管咋样，也不能无缘无故就把数据给删了。但是他很倔强，执意不改，还说如果我觉得这个数据有用，那就让我自己“顺手”把这里的代码改一下。

此时我能明显地感受到他已经有点烦我了！无奈之下，我把这段代码给移动到了事物里面。

而我为什么说我因为发现同事代码有Bug告诉同事而吃过亏呢？

原因在于我之前待过的一家公司，有一个工作了几年的程序员同事，而我当时是个萌新。因为我专门培训过，所以代码能力还行。可这个同事虽然工作了几年，但写出来的程序代码却Bug一堆，常规测试手段还测不出来。

我是在偶然之间发现他写的一个程序是有Bug，但是又不确定，所以就想看看他代码是咋写的。不看不知道，一看吓一跳，他写的好大一部分代码都有问题！

我当时初生牛犊不怕虎，发现一个跟他说一个，结果最后把他给惹毛了，当场就要跟我动手，说我专门针对他。我哪有针对他的心呀！我当时想的是把这些Bug找出来，让他改掉，否则对公司也不好。

但是他想的估计是被我这个萌新发现了一堆Bug很丢人。我总是针对他的代码找Bug，他就是脾气再好也绷不住啊！

后来我们的部门经理为了不让他难堪，也为了给他个台阶下，找了我写的程序里的一个缺点，猛批了下，然后跟大家说：“我刚才看了看，大家写的代码有好多问题。这样，大家都各自检查一下自己的代码，看看有没有问题，有问题尽快改过来，然后我们统一测试！”

直到现在，我也没毕没学会当发现同事代码有Bug以后，在不让同事产生不愉快的心理的情况下，委婉地告诉同事他代码写的有问题的方法。

---