达内专注IT培训20年，覆盖70座城市，近342家校区遍布，开设Java大数据、软件测试、Python人工智能、web前端、Linux云计算、网络安全与运维、UI设计、运营、影视特效、全链路网络营销等IT培训、泛IT培训和非IT培训共12大IT课程，拨打客服电话预约了解课程详解及优惠！

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

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

　　9*大手工测试技术

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

　　9*大自动化测试技术

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

　　11*大测试开发技术

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

　　9*大主流行业业务掌握能力

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

　　5*大业务需求分析能力

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

　　7*大项目方案设计能力

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

　　软件测试大牛成长记：一个好的测试工程师是这样的！

　　我们在变化中成长。假设你拒尽了变化，你就拒尽了新的美丽和新的机遇。

　　——达内软件测试培训

　　初始软件测试

　　“这是一个杯子，主要用来喝水的，它的质量应该如何考量?”

　　这是在进入上家公司面试时，测试主管问我的题目，相关的回答已经有点模糊，但从这个问题可以大概了解到，测试主管在考察我的测试思维。

　　首先，这个杯子的质量包含哪些方面?即通常所说的需求是什么?如显性需求，首先应该是杯子，不是瓶子、罐子等，用途是喝水的;隐性需求呢?那就比较笼统了，如大小、高度、容积、制作材料、温度承受范围，还有一些其他细节如颜色、边角圆滑等。

　　其次，如何去准确获取、表现这些需求，即相关指标数据是多少。如要知道大小、高度、容积，得用到相关测量工具，如尺子、圆规。要知道温度承受范围，可能要用到温度计等。

　　在完成测试工作期间，测试设计、执行之前必须清晰了解原始需求(包括隐性需求)，再之后需要有对应的测试方案，需要执行哪些类型测试，要用到什么测试工具等。

　　很感谢当初测试主管对我测试工作的指导，不仅仅是在具体的技能培训上，还在其他的工作当中对我测试思维的引导。

　　功能测试实践

　　面试过后进入公司，较开始接触的项目是国税门户网站，所进行的测试工作是主要是功能测试，如测试用例编写、执行，测试报告反馈。当时对所谓的软件生命周期都很模糊，感觉我只要做好自己的测试任务就好了，其他的东西由上级安排就好。现在想想真的好白，白痴的白。在接下来的一年时间，让我真正接触到了项目开发、交付的实际生产过程，简而言之就是，工作任务是无止境的，永远有数不尽的需求要开发、测试，有茫茫多的Bug要跟踪。如何在这中间保持自己清晰的定位显得至关重要。由于在项目组中只有我一个测试人员，那么结果就是，“测试的事情就都是我的”，好像很厉害的样子。但我还只是小白啊。

　　“某某某，过来一下，这是这个版本修改的内容，大概是要在某月某日完成，你过(看)一下。”

　　“哦”。

　　到了测试执行，发现问题后提交给开发同事，开发回复：“设计如此。”

　　“哦”。

　　快要上线了，项目经理问：“某某某，现在系统的测试情况怎么样，能不能上线?”

　　“应该差不多吧”

　　......

　　测试主管了解之后，跟我强调了几点：

　　1、测试的依据，需求基线要清楚，要尽早参与;

　　2、测试要有计划方案，要有用例设计，不能随意的开展;

　　3、Bug的跟踪，要有自己的主见、原则;

　　4、测试结果的把握，要有结果分析。项目的上线，要综合你的以上测试过程，结合目前的情况总结报告，甚至是项目经理也要听取你的意见。你的角色不仅是测试，也是质量增加。

　　当然，以上的情况只是测试中遇到问题的一点点，如沙漠中的一粒沙(这孩子究竟怎么过来的)，但也让我认识到测试是独立的、重要的。

　　在后来的项目测试工作中，践行测试主管传递的思想原则的同时，我并行了解相关测试书籍、工具、技能，结合工作进行相关实践，逐渐地我的测试能力越来越强。

　　在省国税外派了一年，之后测试过程中更加有条理、原则、规范。但也仅是个人自觉的约束，很多过程并没有按照软件开发周期的标准来执行，如测试用例、测试报告有时候会在发布版本后才编写(虽然公司也通过了CMMI3)，即测试的质量增加更多的依赖个人的素质。并且，当时个人认为测试的业务熟练更多决定于对系统功能本身的熟悉和测试设计执行的熟悉，认识到错误并且有意识改变是在地税的定点联系企业管理系统和电子办税服务厅的测试过程。

　　之后，进入到地税的定点联系企业管理系统项目组进行测试。当时项目已快要进入验收阶段，甲方要求的功能基本都有实现，但在交付时甲方却不满意，在一些功能的易用性和系统界面展示上提了很多要求，导致整个系统较后框架、原型都换了一遍，而且限定修改的时间很短(又是一个加班加点的开始)，较后甚至项目负责人都换了。

　　总结了下，有几个方面问题：

　　1、既定清晰的需求都有按要求实现，只不过实现方式不合甲方胃口，如图表不够丰富，只有概要，没有详细。

　　2、系统界面没有统一的样式，甲方不客气的说像草稿。

　　3、流程没有体现甲方日常工作内容、步骤。

　　4、风控系统很肤浅，指标不实用。

　　在这个测试过程中，我比较正式地参加甲方组织的各种需求讨论会议，期间也认识到原始需求到需求基线其实还是有设计落实过程的，其把握的度就要看负责人或产品经理的灵性了。作为测试人员，在需求评审过程中就要对比原始需求(要详细了解具体日常工作内容，行业特殊性等)和需求基线的不同，给予自己的意见，在测试过程中不时提醒自己。而对需求的理解是否深刻，有时候不是参加正式需求评审就能达到的，还需要深入到用户实际的工作场景，了解实际业务和流程。而对于自己无法准确把握(风控系统)，用户又无法准确提供的需求就要定好界限，实现到什么程度。较后，好用的软件不仅是功能的实现，一个界面样式都能让你从头再来。原计划短期内交付的项目，由于后续各种修改需求一直到了次年3月，才基本结束相关测试活动。