达内软件测试课程全新升级，课程覆盖数据库、linux、 接口测试、手机测试等技术，并设有辅导课程，主讲编程语言Python，基于Python的接口框架和功能自动化工具Selenium和性能测试工具JMeter，学软件测试就来达内。

　　技术+业务双向赋能  3个月打造π型测试人才

　　手工测试技术

　　测试计划、测试方案、需求分析、用例设计、用例执行、测试报告、缺陷管理、配置管理、用例评审

　　自动化测试技术

　　接口测试、性能测试、WEB测试、APP测试、数据抓包、安全测试、linux、数据库、DevOps

　　1测试开发技术

　　python/java、白盒测试、测试框架、设计模式、持续集成、每日构建、UnitTest、Pytest、大数据测试、人工智能测试、华为云计算

　　主流行业业务掌握能力

　　电商、金融、（银行、保险、理财等）、医疗、视频及直播、即时通信、社交、旅游、人工智能、游戏

　　业务需求分析能力

　　用户需求挖掘分析、业务过程拆解、核心业务流程提取、测试点与测试场景提炼、用户真实场景模拟

　　项目方案设计能力

　　手工测试用例设计、接口测试用例设计、功能自动化脚本编写、性能场景设计、性能测试脚本设计、白盒测试方案设计、安全测试方案设计

　　如何编写测试计划和测试报告

　　一，测试计划

　　在软件测试工作阶段，一共分为五个阶段：计划，设计，执行，评估，验收

　　可以看到在做软件测试工作的时候，较开心，就是做好计划工作，也就是软件测试计划

　　在软件测试设计计划里面应该包含哪些内容？

　　1，测试开始时间&测试结束时间(周期的长短一定是在测试计划里体现了，时间因素影响了后面所有因素)

　　2，测试内容(包含在本轮测试中，哪些功能模块需要测试，哪些需求已经明确实现，业务功能重要度划分)

　　3，测试参与人员以及任务分工

　　4，输出文档的规定以及存放(测试用例编写规则，测试用例的粒度，文档的存储位置和命名规则)

　　5，采用的测试方法以及测试环境或者工具的准备工作

　　二，测试计划的5W原则

　　When：什么时候开始做，什么时候结束测试，要在在这段时间内做好一个规划与进度

　　What:我们要做什么?要明确的罗列出来，好明确我们的测试方向和重点，并方面后期划分责任(人)模块

　　Who谁要参与这次项目的测试?具体负责哪个模块的功能测试?主要负责任务是?都是在这个里面进行明确的责任划分

　　How如何测试，确定我们的测试方法：是白盒测试还是黑盒测试?我们要不要进行安全性测试，都需要在这个里面计划好

　　Where：把文档放在哪里，就明确的包括了我们的传输文档有哪些：比如说测试用例?BUG列表?测试报告等等文档要存放的位置，作用就是规定输出文档以及输出文档的存放位置

　　三，测试报告的编写

　　1，不能用中文写，较好英文，或者其他语言

　　2，报告基本是用Word编写的，记得在页眉上附上公司Iogo和某某测试部

　　3，测试说明部分、说明测试使用技术、工具并说明他们都具有哪些国际性优势

　　4，测试方案部分，说明测试思路，逻辑和用例，请附上逻辑图，测试用例要用代码编写或者用Xml文件编写。如果你写成excel样式的用例，那真的很不professional

　　5，数据分析部分，一定要带上各种表格，纯文字太LOW了，线图，饼图，柱图能上的都上

　　6，缺陷列表部分，请按照缺陷等级有秩序的划分，较严重的等级一定用红色表示，

　　7，风险评估及总结部分，注意字体加粗，颜色依旧用红色。一定要注意某某问题不修改，会严重导致我们用户唾弃我们的产品

　　8，写清楚测试人，次测试日期，第二次测试日期，第N次测试日期，N>=5

　　9，所有原始数据要打个压缩包并附上，因为以科学为依据，以事实为准绳

　　随着测试工作越来越受重视，开发团队向客户提供测试文档是不可避免的事情。但不能把工作中的测试文稿提供给客户，这样可能会让顾客失去信心

　　10，测试报告分为内部测试和外部测试，内部报告是我们在测试工作中的项目文档，反映了测试工作的实施情况，

　　11，外部测试报告的满足需求

　　根据内部测试报告进行编写，一般可以摘录、不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道、报告可以列出一些缺陷，但必须是中极的缺陷，而且这些缺陷必须是修复的、报告上面的内容尽量要真实可靠、整个测试报告要仔细审阅，力争不给项目带来负责作用，尤其是性能测试报告、总之，外部测试报告要小心谨慎的编写

　　四，论测试用模块化的重要性

　　测试用例的模块化是每个企业都在用的，已经成为一种约定俗成的标准。模块化不光美观，更可以使我们能地定位到测试用例位置，同时也是我们对业务逻辑梳理的一种良好体现

　　需严格按照大家商议后的命名规则

　　如何做?

　　1，按照系统的大功能模块进行划分，以百度网盘为例如：

　　注册-登陆-网盘-分享-客户端下载-会员中心

　　2，在系统性的大功能划分好以后，划分其子功能，如;网盘-上传， 网盘-新建文件夹。 网盘-离线下载

　　3，细分子功能的业务场景如：

　　网盘-离线下载-新建BT任务。 网盘-离线下载-新建链接任务

　　4，至少把正常流和异常流区别开来，即写成2条用例，如：

　　网盘-离线下载-新建BT任务-下载成功

　　网盘-离线下载-新建BT任务-中途取消

　　五，融会贯通用例颗粒度

　　1，测试用例同样有颗粒度的概念

　　2，‘粗’粒度的用例的优点是后续维护简单、节省时间从而能尽快对客户进行交付;但有个缺点是不熟悉功能的根本没法执行你所设计的测试用例

　　3，‘细’粒度的用例的优点是即使不熟悉该功能的老阿姨也能轻松运行你的测试用例从而节省了培训成本。另外，粒度细的测试用例其实也可以使测试工程师更安心;缺点非常明显，维护相当麻烦

　　4，所以我们要折中和平衡，可以协调、商量

　　5，总结，测试用例不要太粗也不要太细，根据实际情况自己把握

　　六，测试用例粒度的折中原则

　　1，涉及到金钱的测试用例还是不要太粗，至少把逻辑规则列出来并给较具代表性的参考数据

　　2不太涉及具体测试数据的，可以像写故事一样把流程描绘清楚就可以了

　　3，尽量避免用例太细，在企业里很实际，效率决定一切

　　七，测试用例的执行

　　属性：实际结果

　　(每个步骤的)实际结果的4个较常用属性

　　1，通过

　　2，失败

　　2.1写出实际结果

　　2.2提交缺陷并在实际结果中标注缺陷编号

　　3，无效(N/A，Not Available)(泛指当前步骤失效)

　　3.1如果的确是业务变更了，需求变更了，那么更新测试用例

　　3.2如果是当前版本不用测试或屏蔽等情况，那么保持测试用例不变，但要把具体情况写在实际结果那一栏里

　　4，阻碍

　　4.1由于各种原因导致我们无法执行有效测试用例，那么请查明确具体原因后备注在实际结果里，并时间告知相关人员

　　4.2一般阻碍是外部所影响的，如你收到的第三方所提供的接口有重大问题或者没有如期收到

　　八，缺陷定位分析与审核

　　分析日志是常用的定位软件缺陷的手段，测试工程师不光能找到缺陷，更能够帮助开发定位具体缺陷产生原因

　　安装Notepad++

　　建议定期进行遗留缺陷的审核，如果未来你们公司里没有这个流程，可以提出来。