测试过程

从事软件测试行业多年，不管是目前比较流行的业务测试，还是最常见的功能测试，80/20原则（80% 的软件缺陷常常生存在软件20% 的空间里）一直都是适用的。 然而，有时候在总结测试经验的时候发现，这个软件测试行业入门必知的一个知识好像在测试过程中已经被忽略了；看过有人调查的一篇文章，超过60%的人可能都忘记80-20原则是什么了；文章中提到一句很有意思的话是可能你在测试了很久也没有发现很重要的bug，可能一个大佬过来点点点几下就发现几个bug，这说明你根本没有理解被测软件的重点在哪里，导致在测试过程中盲目的测试。我认为可以把80-20原则理解为测试过程中要抓住测试的重点，要把更多的时间很精力投入在那20%重点模块中。 很多时候公司的项目进展都非常紧张，根本没有留下足够的时间给我们测试，我们发现bug之后还要给开发修改，然后再回归测试。此时我们如果无法抓住测试的重点，可能会导致漏测，甚至发布之后出现网上问题。 不同的公司对测试团队的考核可能不一样，有的公司可能考核bug的数量，有的公司考核bug的质量，但总之，我建议大家都可以思考一下是否可以利用80-20原则发现更多更有质量的bug。 来源： oschina 链接： https://my.oschina.net/u/4265622/blog/3220446

从事软件测试行业多年，不管是目前比较流行的业务测试，还是最常见的功能测试，80/20原则（80% 的软件缺陷常常生存在软件20% 的空间里）一直都是适用的。 然而，有时候在总结测试经验的时候发现，这个软件测试行业入门必知的一个知识好像在测试过程中已经被忽略了；看过有人调查的一篇文章，超过60%的人可能都忘记80-20原则是什么了；文章中提到一句很有意思的话是可能你在测试了很久也没有发现很重要的bug，可能一个大佬过来点点点几下就发现几个bug，这说明你根本没有理解被测软件的重点在哪里，导致在测试过程中盲目的测试。我认为可以把80-20原则理解为测试过程中要抓住测试的重点，要把更多的时间很精力投入在那20%重点模块中。 很多时候公司的项目进展都非常紧张，根本没有留下足够的时间给我们测试，我们发现bug之后还要给开发修改，然后再回归测试。此时我们如果无法抓住测试的重点，可能会导致漏测，甚至发布之后出现网上问题。 不同的公司对测试团队的考核可能不一样，有的公司可能考核bug的数量，有的公司考核bug的质量，但总之，我建议大家都可以思考一下是否可以利用80-20原则发现更多更有质量的bug。 来源： oschina 链接： https://my.oschina.net/u/4339497/blog/3220448

5.1 模型融合目标 对于多种调参完成的模型进行模型融合。 完成对于多种模型的融合，提交融合结果并打卡。 5.2 内容介绍 模型融合是比赛后期一个重要的环节，大体来说有如下的类型方式。 简单加权融合: 回归（分类概率）：算术平均融合（Arithmetic mean），几何平均融合（Geometric mean）； 分类：投票（Voting) 综合：排序融合(Rank averaging)，log融合 stacking/blending: 构建多层模型，并利用预测结果再拟合预测。 boosting/bagging（在xgboost，Adaboost,GBDT中已经用到）: 多树的提升方法 5.3 Stacking相关理论介绍 什么是 stacking 简单来说 stacking 就是当用初始训练数据学习出若干个基学习器后，将这几个学习器的预测结果作为新的训练集，来学习一个新的学习器。 将个体学习器结合在一起的时候使用的方法叫做结合策略。对于分类问题，我们可以使用投票法来选择输出最多的类。对于回归问题，我们可以将分类器输出的结果求平均值。 上面说的投票法和平均法都是很有效的结合策略，还有一种结合策略是使用另外一个机器学习算法来将个体机器学习器的结果结合在一起，这个方法就是Stacking。 在stacking方法中，我们把个体学习器叫做初级学习器

1、app的性能测试，即专项测试，需要重点关注那些方面？ 内存、cpu占用、耗电量、流量、流畅度等 2、测试过程中遇到app出现crash或者ANR，你会怎么处理？ 可以先把日志过滤出来： adb logcat | findstr xxxxx(过滤日志信息) ，然后再搜索其中的关键字，比如：exception、crash，看看是那些方法或者异常导致了问题的发送，初步定位问题原因后，可以交给开发人员去具体查找深层原因并修复 来源： https://www.cnblogs.com/maoruke/p/12598106.html

一、传统软件开发方法 传统的重量级软件开发方法存在很多局限： 　　(1)传统软件开发过程是基于设计之初正确的设计与估计．并通过开发人员开发出完美的产品。开发方式以“明确需求”为核心．从需求分析、软件设计到系统实现，再进行集成和测试。这样，系统集成进行得比较晚，集成的时间周期比较长，集成时发现的缺陷也比较多。 　　(2)虽然目前有许多项目采用增量迭代的开发周期，但是通常项目在部署前才发布版本，用户只有在部署后才能看到真正的系统．因此，用户会提出很多修改意见，包括流程方面的问题．有此问题可能会影响到系统的架构设计。 　　(3)开发人员由于进度或成本等因素，对单元测试重视程序不足，又缺乏有效的回归测试方法，这样，对于用户提交的Bug，开发人员对Bug的定位时间会比较长，因此，修改的周期也会比较长。 　　(4)传统的开发方法中规定了各种文档，如需求分析、软件设计和各种测试文档等等。在软件开发过程中变更是不可避免的，但是经常需求变了、设计变了，程序变了，而相应的文档却没修改。时间越久，文档就越不符合实际情况。 为克服以上限制，敏捷开发方法应运而生： 二、敏捷开发方法 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备继承和可运行的特征。换言之，就是把一个大项目氛围多个相互关系，但也可独立运行的小项目，并分别完成

1 ． 软件测试 的目的是尽可能多的找出软件的缺陷。（ Y） 2 ．Beta 测试是验收测试的一种。（ Y） Acceptance testing 验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。 3 ．验收测试是由最终用户来实施的。（ N ） 是由测试人员来实施的 4 ．项目立项前测试人员不需要提交任何工件。（ Y ） 工件：加工过程中生产对象 5 ．单元测试能发现约80% 的软件缺陷。（ Y ） 6 ．代码评审是检查源代码是否达到模块设计的要求。（ N ） 代码评审也称代码复查，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。 7 ．自底向上集成需要测试员编写驱动程序。（ Y ） 自顶向下综合测试的具体步骤为： 　　1 以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代； 　　2 依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块； 　　3 每集成一个模块立即测试一遍； 　　4 只有每组测试完成后，才着手替换下一个桩模块； 　　5 为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。 自底向上综合测试的步骤分为： 　　1 把低层模块组织成实现某个子功能的模块群（cluster）; 　　2 开发一个测试驱动模块

那要看你的项目经理是当成什么层面的了，如果是负责面向客户联络沟通，内部监督控制进度的话是能做好内外沟通，两边都能协调好就可以了。如果你要深入项目管理，那么肯定要熟悉整个软件开发项目的过程，什么阶段做什么、怎么做、谁来做，时间、质量、进度三者平衡。没有一个完美的项目，因为总会有瑕疵，不要太追求完美，用户满意、适度质量的项目才好。关于软件开发过程的一些理解分享一下。 1、首先制定项目计划，最初计划是里程碑性质的。 可以先按瀑布模型设置，里程碑点主要为需求评审、设计评审、经过代码开发和单元测试后进行集成测试、部署上线是一个很重要的里程碑，一般用户会期望系统何时能使用进入试运行期（也可以称为用户测试阶段） 2、需求开发阶段： 怎么样写好需求很关键，如何学会进行需求开发可以去看下经典的《需求工程》这个翻译的书，不是很厚，但需要能理解为什么那样做更好，这个需要实践经验锻炼自己。如果有项目成员，可以一起做需求，这个阶段对于业务理解、分析、如何开展调研以及文字表述、业务流程图描述还有文档编辑能力都有不少要求。一般分为《用户需求说明书》和《需求规格说明书》，小项目可以写一个《需求分析报告》，《用户需求说明书》是用用户的语言进行描述，让用户和开发团队对于需求的达成一致的理解，《需求规格说明书》，则是对用户需求的分析，形成系统要具有的功能，这个是真正提供用户可交互操作的文档

DevOps面试问题 01 您能告诉我们DevOps和Agile(敏捷)之间的根本区别吗？ 答：尽管DevOps与敏捷方法（这是最流行的SDLC[Software Development Life Cycle]方法之一）有一些相似之处，但两者在软件开发方面都是根本不同的方法。以下是两者之间的各种基本差异： 敏捷方法 敏捷方法适用于敏捷中的开发同时敏捷方法适用于DevOps中的开发和操作。 实践和流程 敏捷涉及敏捷Scrum和敏捷看板等实践，而DevOps涉及CD（持续交付），CI（持续集成）和CT（持续测试）等流程。 优先级 敏捷优先考虑及时性，而DevOps优先考虑及时性和质量。 发布周期 DevOps提供较小的发布周期并提供即时反馈，而敏捷仅提供较小的发布周期而没有立即反馈。 反馈源 敏捷依赖于客户的反馈，而DevOps涉及到自身（监控工具）的反馈。 工作范围 对于敏捷，工作范围仅是敏捷，而对于DevOps，这是敏捷和对自动化的需求。 02 为什么我们需要DevOps？ 答：如今，很多组织或企业正试图通过一系列的发布小的特性传递给客户，而不是发布大的特性集。这样做有几个好处，包括更好的软件质量和快速的客户反馈，所有这些好处导致更高的客户满意度，这是任何产品开发项目的最重要目标。为此，公司需要： 增加部署频率 缩短修复时间 降低新版本的失败率 万一新版本崩溃

定义：软件测试(英语:software testing)，描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出间的审核或者比较过程。软件测试的经典定义是:在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。 测试原则： 一，测试应该尽早进行，最好在需求阶段就开始介入，因为最严重的错误不外乎是系统不能满足用户的需求。 二，程序员应该避免检查自己的程序，软件测试应该由第三方来负责。 三，设计测试用例时应考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下不要制造极端状态和意外状态。 四，应该充分注意测试中的群集现象。 五，对策就错误结果进行地一个确认过程。一般由A测试出来的错误，一定要由B来确认。严重的错误可以召开评审会议进行讨论和分析，对测试结果要进行严格的确认，是否真的存在这个问题以及严重程度等。 六，制定严格的测试计划。一定要制定测试计划，并且要有指导性。测试时间安排尽量宽松，不要希望在极短的时间内完成也有一个高水平的测试。 七，妥善保存测试计划、测试用例、出错统计和最终 分析报告 ，为维护提供方便。 来源： https://www.cnblogs.com/sh183/p/10586270.html

1） 回归第一周目标 对于第一周的目标，在提高代码量，多写多练方面达到了，之前结点编程时还不是很熟悉python，现在写的比较熟练了，同时学习了一门新的语言Julia，在学习的过程中也看了Julia和Flux的一些源码。之前比较不注意个人代码规范，在团队项目中被强行规范了。 2） 快速浏览《构建之法》的问题 在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。这样，程序中的错误就会少很多，程序的初始质量会高很多，这样会省下很多以后修改、测试的时间。 结对编程是个渐进的过程，有效率的结对编程不是一天就能做到的。 在做结对编程的项目中，我体会到了结对编程的优点，虽然刚开始对python代码队友比较熟悉，但是结对编程的时候我也能比较细致的找到bug，比一个人效率高，同时也是相互学习的过程，对于小而精的项目我觉得结对编程挺好的，从长期来看，成员互相提高，也能提高团队的效率。 软件在发展过程中用户需求是变化的，用户的数量和多样性也在增长，这时候我们是否应该重新定义我们的典型用户？ 是的，虽然软件不是为所有人服务的，但是有了新的典型用户之后我们也应该根据新的需求增加对应的功能。 用网站当前的用户做实验，万一引起巨大的反感，用户就真的流失了。 如果用户体验反馈比较准确，那么测试用户的数量要大，来源是我们的真实用户，这样就存在文中的问题