测试的基本流程以及在流程各部分所负责的工作

1【制定测试计划】-- 制定测试计划（需求会议-评审）需求分析点。
首先要有必备的素质，包括沟通能力、表达能力、逻辑思维能力、团队协作能力、处理日常事务和突发事件的能力、危机感和毅力；同时要具有熟悉产品、明确测试流程中各个阶段的工作、测试案例的设计能力、使用测试工具、测试管理的专业素质。

2【需求文档-项目计划书】 -- 开发产品
项目立项（项目计划、产品需求说明书）——>了解项目需求，并验证需求的可测试性（进行需求评审）；此时指派给相应的测试人员；交互定稿后（有界面，定稿后可编写测试大纲），制定项目测试计划（明确要进行系统测试的项目需求点，以估算系统测试周期），在上述两者确定后开始测试设计阶段。
输出件：项目测试计划、测试计划。

3【测试点】 -- 编辑测试用例测试
根据测试计划、需求概要等相关文档，进行测试大纲（用例）的设计，用例编写必须等到交互定稿后开展，此后进行组内评审和项目组评审。
输出件：测试需求说明书、测试用例、测试计划、用例评审记录。
4【执行测试用例】-- 测试提交给测试经理，经理会根据条件给出详细报告
开发进行自测（使用测试提供的开发自测用例），若开发自测不通过，则需要注明注明情况，如何时才能测试阻塞部分的功能，否则不能提测。
先由产品经理（交互）进行产品验收，保证没有需求bug。如果有产品，产品看功能，若满足需求，指派给测试（测试备注，完成审核）；否则，把单子指回给开发，待到审核通过后再重新提单。
5【发现并提交缺陷】-- 测试
6【开发组修正缺陷】-- 开发
开始测试，包括功能需求测试、专项测试等等。注意在测试过程中每日都要更新测试单，说明测试进度，测试情况。
输出件：测试申请单、测试阶段总结、测试报告、缺陷列表。
7【对已修正缺陷进行复测】-- 测试
8【修正完成的】将状态置为已关闭录入
9【未正确修正】的缺陷重新激活执行复现步骤
整理测试报告发给项目组，让产品评估是否可以发布，哪些bug必须改。
测试工程师提交测试报告后，由测试负责人审查报告，通过后产品提交回归测试，由测试负责人审查bug处理结果，测试工程师再执行回归测试，最后输出测试总结。测试负责人审查测试总结，产品验收确认，通过后即发布。
10 【测试总结】
1、汇总项目初始以来严重buglist并进行项目组评审；
2、汇总已测试的功能点；
3、汇总未测试和无法测试的部分；
4、汇总测试不充分的部分；
5、汇总bug分布图和bug走势图；
6、总结项目风险。

常用的测试工具以及使用场景

1 测试管理工具
禅道（简单好用）
git，同svn，但是多分支管理比svn好
2 接口测试工具
postman
3 性能测试工具

4持续集成工具
jenkins

.谈谈缺陷严重程度的划分

致命、严重、一般、较小

导致系统主干流程进行不下去，系统崩溃，服务无法提供，系统内金额错误，交易失败等严重影响商户体验和公司名誉的缺陷

1、严重(urgent)：
① 用户需求未实现（影响到用户完成业务）；
② 用户需求实现错误（影响到用户完成业务）；
③ 导致被测软件响应明显很慢（假死）、死机、非法退出、崩溃；
④ 用户使用频繁的功能，响应时间超出忍耐限度（不影响其他功能模块）；
⑤ 导致后台数据受损或丢失

2、中等(medium) ：
① 用户需求未实现（不影响用户完成业务、用户使用不频繁) ；
注：用户执行删除操作时系统应弹出确认提示将固定视为用户需求，无删除确认提示的缺陷归属本类
② 用户需求实现错误（不影响用户完成业务、用户使用不频繁) ；
③ 用户操作过程中系统出现异常报错，但不影响系统功能的使用。
④ 用户使用不频繁的功能，响应时间超出忍耐限度；
⑤ UI上存在错误引导用户的信息。
⑥ UI上信息缺失、无法显示完整或出现乱码从而给用户造成疑惑的。
⑦ 用户频繁使用的功能易用性差（操作起来麻烦、复杂、效率低）

3、轻微(low)：
① UI控件不符合界面规范。
② 影响UI友好性。
③ 用户不频繁使用的功能易用性差

缺陷状态一般分为：新建、打开、已分配、已修复、关闭、重新打开
中间会有：延期、重复、拒绝等状态

.测试工作中遇到过哪些棘手的问题

1 由于一个模块产生的缺陷，导致本页面下没有缺陷，但在其他模块下导致的缺陷，
2 复现步骤生缺陷，总会有些不知所措的缺陷，由于数据分流导致数据重载

如何高效的编写测试用例
1、覆盖到所有的业务逻辑（包括正常逻辑和异常逻辑，注意隐性业务会产生的场景）
2、覆盖到所有的典型用户场景（正常和异常场景）
3、覆盖到所有的需求点（当前版本涉及的所有功能）
4、测试目标明确，并且测试步骤能够最快的达到测试目的或者测试时间很短（测试计划起到非常关键的作用）
5、没有冗余的用例（相同的用例可以复用）
6、测试用例能够直接附带测试策略，该模块的策略指定人和用例执行人能够非常清楚（从这点上，写用例要体现的关键点很重要）

1、优先完成业务逻辑图（建议画思维导图，画出测试点），需要在测试的角度上面去画逻辑图，包括数据流完整的输入和输出过程，并且自己能够理解为什么这样处理
2、分析每个逻辑的处理是否完善，是否有没有覆盖到的地方（考虑要周全，重心放在大方向流程上）
3、根据业务逻辑编写测试用例，保证每个逻辑都能够有对应的用例覆盖（有条件性的用例覆盖）