声明：本文转自一位优秀的测试工程师的文章，仅作为分享，不涉及个人利益问题

一、 发现缺陷

1. 熟悉业务知识：

测试人员要了解业务背景，熟悉业务流程，参考其它生产上已稳定运行的类似业务如何实现，这样便于更好的掌握业务知识。

2. 测试人员要熟悉业务的系统实现方式。

3. 测试人员要具备细心、严谨、耐心的工作态度，绝不放过一个缺陷。

4. 发散性思维：

尤其在案例设计阶段与案例执行阶段，应多进行发散性思维，打破以往的测试思维，可能会发现更多有价值的缺陷。 例如:在案例执行阶段，不按照已规定的流程进行测试，而是可以跳过某个步骤提前去结束，其结果往往就能发现问题。随机测试就是跳出已知的步骤，可以来回反反复复进行操作，这种过程，本身就是另一种用例设计的过程。

5. 破坏性测试：

以下是列举了测试过程中的几大类破坏性测试类型。请参阅。

 A、用户登录类

1.同一账号同一时间内在多个地方进行登录;

2.不同的账号同一时间在同一台机上登录;

 3.输入错误的账户名称或密码进行登录;

 4.在某帐号在线的情况下,删除或修改其权限或信息,且改动的数据正被使用;

 B、 字符输入类

1.添加名称相同的多条数据;

 2.本该输入字符,而故意不输入任何字符,直接确定;

 3.对于有明确长度限制的输入框,输入超出该限制的字符数;

 4.对于未明确长度限制的输入框,输入超量的字符数 (“超量”是指超出常理的100倍以上);

 5.输入超出大小限制的数值;

 6.输入全角或半角的标点符号和特殊字符;

 7.输入网页代码形式的字符;

 8.以上各种字符输入,不仅可以键盘键入,还可以借助复制粘贴的方式;

C、 按键操作类

1.功能执行过程中,切换到其它功能或其它模块;

 2.对于分成多个步骤完成的功能,反复无序地来回跳转;

 3.随意快速地切换界面上的所有功能按键;

 4.重复快速的操作同一个工具或按钮;

 5.功能执行过程中,尝试使用左键单击、右键单击、左键双击、右键双击功能、中键单击、左右键同时按住等鼠标操作方式;

 6.存在弹出式对话框时,尝试操作非活动窗口的工具、按钮、菜单;

 7.对同一个程序,在当前并未退出的情况下,执行重复多次打开;

 8.同时打开多个不同的子系统; 9.重复快速的开关软件10次以上;

 10.快速和慢速移动窗体,界面刷新是否存在异常;

 11.对于基于BS开发的系统(包括CS系统中嵌入了浏览器相关功能的),在操作过程中,尝试使用浏览器快捷键进行操控(如:“ALT+HOME”、“ALT+LEFT”、“CTRL+F5”、“ESC”等导航快捷键);或删除cookies, 密码, 表单数据, 历史, and 临时文件。

12.软件使用过程中,手动关闭、注销(包括切换用户)或重新启动电脑,再打开软件进行使用,检查是否会存在异常;

 13.软件使用过程中,从任务管理器、任务栏中结束软件,检查是否会出现异常;

D、 资料播放类

1.某资料被其它软件占用时,通过我们的程序打开该资料文件进行播放;(反之亦然)

 2.通过我们的程序,打开名称中夹杂着特殊字符、中文、英文、标点符号的资料;(全角与半角都要尝试)

 3.资料文件的后缀名中,夹杂着大写、小写字符;

 4.系统不支持的资料格式;

 5.播放已损坏的资料;

 6.连续反复快速地拖动音视频播放器的播放条滑块;或连续反复的操作播放器的控制按钮(包含语速和音量调节器);

 7.反复快速地在不同的资料间进行切换;

E、 上传下载类

1.上传超过容量限制、个数限制的资料;

 2.同时下载多个大容量的资料(每个资料的容量和个数均是系统允许最大的);

 3.在同一时间或先后短暂的时段内频繁上传/下载资源文件;

 4.在对文件的上传/下载过程中,中止上传/下载过程;

 5.将资料上传/下载到磁盘空间不足的地方;

F、 软件安装类

1.软件使用过程中,重新安装或卸载软件,检查是否会出现异常;

 2.将软件安装到一半的过程中,重启电脑,再进行软件安装,检查是否会出现异常;

 3.将软件安装到磁盘空间不足的目录下,检查是否会出现异常;

G、 软件兼容类

1.不安装必须安装的辅助应用软件的时候对使用软件;

 2.安装比系统所要求的更低(或更高)版本的辅助应用软件的时候使用软件;

 3.在低于标准分辨率下,软件显示的操作流程是否存在异常;

 4.在高于标准分辨率下,软件的显示和操作流程是否存在异常;

 5.不安装杀毒软件、防火墙时对使用软件;

 6.安装了杀毒软件、防火墙时使用软件;

H、 资源占用类

1.在软件操作过程中,执行其它比较占用资源的软件,检查是否会存在异常;

6. 测试人员充分利用业务场景图，资产库案例，产品缺陷库，历史生产事故等方式进行知识沉淀。便于后续测试经验，测试方法等知识的传承。

7. UAT测试人员可参考ST提交缺陷的情况，分析与权衡UAT须关注的部分， 主要从以下2个方面发散。

A. 缺陷密度大的功能点，一定还有遗漏缺陷。

B. 没有缺陷的功能点，查看ST案例是否已经包含了UAT的测试范围。

8. 测试人员要关心辅办的测试范围：

A. 测试负责人要对项目整理清楚业务场景。

B. 系统直接的接口是容易产生缺陷的重灾区。

C. 测试负责人要清楚辅办测试是否已经对业务场景图覆盖全面。

二、 保留证据

测试人员发现相关缺陷后，应养成及时保留缺陷证据的好习惯，以下是常见的几种方式。

1. 截图/拍照；

2. 录屏/拍视频；

3. 记录测试操作路径；

4. 保存测试数据：如：收付方卡号、报文标识号等软数据；手机客户端版本、手机系统版本、手机型号；执行时间点等数据关键字段信息。

5. 配置截图；

6. 提醒：对疑似缺陷应先新建缺陷，避免缺陷遗漏；

三、 定位缺陷

1. 如果测试人员能清楚定位是哪个开发的缺陷，则直接找对应开发阐述问题，然后到第四步（提交缺陷）。

2. 测试人员分析是对应哪个系统哪块程序的管控，找到对应的开发负责人进行沟通。

3. 测试人员与开发清晰描述缺陷复现路径、复现场景，包括但不限于以下方式：视频；文字；图片；电话；测试数据；配置截图。

4. 测试人员协助开发一起定位、思考是否是缺陷、以及缺陷出现的原因。

四、 提交缺陷

1. 测试人员若遇到好说话的开发，立马认缺陷，则就直接跳到第五步(修复缺陷)。

2. 测试人员提交缺陷的时候立场要坚定，不可开发不认缺陷就不提交缺陷。 分析了以下几种场景的处理方法：

（1）.根因为环境问题、配置问题、需求问题时要坚定立场提交缺陷给开发或业务。

（2）.可优化但开发并不愿优化的缺陷，说服业务要改，再跟开发说业务要求要改。

（3）.参考其他生产上已稳定运行的类似业务有这样实现，但是我们做的功能并没有 实现，以此来说服业务和开发改

（4）.ST已发现在UAT环境也发现了，必须也提交上去。

（5）.因各系统的开发的沟通问题导致实现逻辑不一致时，先让开发内部讨论确认由哪个系统的开发来修改，再提交缺陷给改代码的开发。

（6）.测试开发都无法定位缺陷归属时，提交给业务，让业务担责。

 3. 与开发人员周旋是否该提交缺陷时，应采用刚柔并用的方法。

（1）.柔

A.先和开发友好的描述这个“异常的现象”，让开发帮忙看一下，切记直接说开 发代码有问题，一般直接说开发的代码有问题都会被揍的。

B.提交完缺陷再和开发说点好话，适当安抚其情绪。

（2）.刚

开发和测试可能都知道是缺陷，然而开发不想认，这时候测试人员的态度要强硬。 以下几种话术可参考,来表达测试方的态度。

 话术一：我们不提缺陷的话，是不会验证缺陷是否修复以及验证缺陷所关联的功 能，万一泄漏到生产……我们都担不起这个责任.

话术二：本来缺陷就被ST都找的差不多了，我们UAT好不容易发现缺陷了，还不 让我们UAT提……

话术三：还有XXX优化的问题我们都没提，你这个问题确实是缺陷都不让我们提 是不是太不近人情了……

话术四：你不让我们提缺陷，我们是不会出报告的，到时候领导知道了，我们都不 好过……

4. 关于提交缺陷，与开发人员周旋时，根据开发人员的态度，因人而异采用不同的方法。

五、 修复缺陷

1. 测试人员须按缺陷等级、优先级排序跟进缺陷修复进度。

2. 项目中所有不处理的缺陷，测试人员都需要问下业务是否接受。

3. 要和开发沟通是否需要关联验证其他功能或者测试场景，以免因缺陷修复的系统改动引发其他系统问题。

六、 与开发人员友好相处

1. 测试人员与开发人员互帮互助，当开发人员在项目外寻求测试的帮助时，我们应适当配合，下次我们再提缺陷的时候就不会有那么大的阻力。

2. 一起吐槽项目或者需求变动太大之类的话，引起共鸣。

3. 测试人员适当赞美对应的开发。例如：你是我合作过解决缺陷最快的！！！

4. 适当和你的开发开玩笑。

5. 和ST的关系也是很重要的，在需求评审前期发现问题及时知会到ST（你把问题留着后面再提bug，只会影响整个项目的进度），后面需求变更ST一定会记得通知我们。记得我们和ST是一个战壕的兄弟，测试与开发的目标也是为了项目高质量的如期上线。

七、 如何提交高质量缺陷

1、 唯一性。

一个缺陷说明一个问题，如果有能力的话，一个缺陷说明一类问题，这一类问题一定要能判断出是一条代码错误引起。

2、 可重现。

提供这个缺陷的精确步骤，使开发人员容易看懂。

3、 一致性。

缺陷描述及所有信息要前后一致，不可有歧义。

4、 完整性。

最好能抓图，一目了然；测试环境和特定条件一定要描述清楚，许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节但又必要的特定条件。

5、 简洁性。

通过使用关键词，可以使软件缺陷的标题描述短小简练，又能准确解释产生缺陷的现象。

6、 跟踪性。

也许随着版本的变化，或者测试的深入，对缺陷有了新的认识或者新的判断，及时补充相关信息，能够提供给开发更有用的信息。

7、 客观性。

软件缺陷描述不要带有个人观点，不要对开发人员进行评价，软件缺陷报告是针对产品的。

来源：富小翠