做好测试工作怎么做？

一：发现缺陷

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’、‘ESC’等导航快捷键）；或删除cookies、密码、表单数据、历史。

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方面发散：

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

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

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

        8.1：测试负责人要对项目整理清楚业务场景

        8.2：系统直接的接口是容易产生缺陷的重灾区

        8.3：测试负责人要清楚辅办测试是否已经对业务场景覆盖全面

二：保留证据

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

1：截图/拍照；

2：录屏/拍视频；

3：记录测试操作路径；

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

5：配置截图；

6：提示：对意思缺陷应先新建缺陷，避免缺陷遗漏；

三：定位缺陷

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

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

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

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

四：提交缺陷

1：测试人员若遇到好说话的开发，立马认缺陷，则直接跳转到第五步（修复缺陷）；

2：测试人员提交缺陷的时候立场要坚定，不可开发不认缺陷就不提交缺陷；

分析一下几种场景的处理方法：

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

b：可优化但开发不愿优化的缺陷，说服业务要改，再跟开发说业务要求要改。

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

d：ST已经发现在UAT环境也发现了，必须提交；

e：因各系统的开发沟通问题导致实现逻辑不一致时，先让开发内部讨论确认由那个系统开发来修复，在提交缺陷给改代码的开发。

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

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

柔

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

B：提交完缺陷在和开发说点好话，安抚其情绪。

刚

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

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

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

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

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

五：修复缺陷

1：测试人员需按缺陷等级、优先级排序跟进缺陷修复进度；

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

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

六：如何提交高质量缺陷

1：唯一性

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

2：可复现

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

3：一致性

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

4：完整性

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

5：简洁性

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

6：跟踪性

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

7：客观性

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

如何保证测试质量？

以下是保证测试质量的重要环节和可量化标准，结合实际做好规范管理。

一：软件测试质量保证工作主要内容和重点

1：指定测试计划。明确测试目标、范围、任务分工等；

2：开发测试用例。覆盖各功能点和场景，考虑边缘值和异常输入；

3：选择测试类型，如 功能测试、回归测试、冲击测试、安全测试等

4：准备测试环境和工具。与开发环境保持一致，支持自动化测试；

5：执行测试。根据计划严格跑通所有用例，记录测试结果；

6：追踪问题。严格分类问题级别，管理解决流程；

7：回归测试。验证问题修复是否可靠，保证质量水平不下降；

8：测试报告。以数据显示测试进度和质量，如bug统计分析；

9：代码审计。选择性diamante审计，发现隐藏问题。

10：自动化测试。自动执行易重复用例，提升覆盖面和效率；

11：客户反馈测试。针对客户需求再测试一次；

12：定期评估测试质量。从用例设计、执行效率等维度评估改进。

13：追踪后期问题。测试中未显示的线上问题需要及时反馈优化。

通过科学的流程和持续优化，实现软件测试质量的可控和提升。

二：测试工作达标 标准

软件测试质量保证一个系统工程，每个步骤的达标标准很重要，这里就各个关键步骤给出一些更详细的标准：

1：测试计划标准：

测试目标明确、可操作。

测试任务清晰分工、时间节点明确。

测试用例设计标准和格式制定。

2：测试用例设计标准：

用例名称签名规范、用例ID管理。

测试目的、条件、步骤、预期结果详细清晰。

测试数据规范、覆盖等值类、边界值、异常值等。

3：测试环境标准：

与开发环境配置及组成相同。

自动化测试工具集成和实现率>80%

环境稳定性得分≥95%

4：测试执行标准

完成度≥95%并记录详细记录

Bug重复提交率<5%

每次测试用时与预期相符

5：Bug管理标准

Bug分类明确完整

Bug处理周期符合要求

Bug解决率、重复率审计达标

6：测试报告标准

测试数据统计全面、准确

Bug统计分析深入浅出

测试质量得分达标线