测试过程

概述 敏捷方法论有一个共同的特点，那就是都将矛头指向了“文档”，它们认为传统的软件工程方法文档量太“重”了，称为“重量级”方法，而相应的敏捷方法则是“轻量级”方法。正是因为“轻量级”感觉没有什么力量，不但不能够有效体现灵活性，反而显得是不解决问题的方法论似的。因此，就有了一次划时代的会议，创建了敏捷联盟。 在敏捷方法论领域中，比较知名的、有影响力的，是拥有与 Microsoft 的操作系统相同缩写语——XP的极限编程（eXtreme Programming）。极限编程方法论可以说是敏捷联盟中最鲜艳的一面旗帜，也是被研究、尝试、应用、赞扬、批判最多的一种方法论，也是相对来说最成熟的一种。 这一被誉为“黑客文化”的方法论的雏形最初形成于1996—1999年间，Kent Beck、Ward Cunninggham、Ron Jeffrey 在开发 C3 项目（Chrysler Comprehensive Compensation）的实践中总结出了 XP 的基本元素。在此之后，Kent Beck 和他的一些好朋友们一起在实践中完善提高，终于形成了极限编程方法论。 解析极限编程 那么什么是 XP 呢？XP 是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比，其最大的不同在于： 在更短的周期内，更早地提供具体、持续的反馈信息。 在迭代的进行计划编制

灰盒测试 灰盒测试，是介于 白盒测试 与 黑盒测试 之间的一种测试，灰盒测试多用于 集成测试 阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。 定义 灰盒 测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识和与之交互的环境，能够用于 黑盒测试 以增强测试效率、错误发现和错误分析的效率。 学术含义 灰盒 (Gray Box)是一种程序或系统上的工作过程被局部认知的装置。灰盒 测试，也称作灰盒分析，是基于对程序内部细节有限认知上的 软件调试 方法。测试者可能知道 系统组件 之间是如何互相作用的，但缺乏对内部程序功能和运作的详细了解。对于内部过程，灰盒测试把程序看作一个必须从外面进行分析的 黑盒 。 灰盒 测试通常与web服务应用一起使用，因为尽管应用程序复杂多变，并不断发展进步， 因特网 仍可以提供相对稳定的接口。由于不需要测试者接触 源代码 ，因此灰盒测试不存在侵略性和偏见。开发者和测试者间有明显的区别，人事冲突的风险减到最小。然而，灰盒测试相对 白盒测试 更加难以发现并解决潜在问题，尤其在一个单一的应用中，白盒测试的内部细节可以完全掌握。 灰盒测试结合了白盒测试和 黑盒测试 的要素。它考虑了用户端、特定的系统知识和操作环境。它在

** 第一篇博客 2020年1月15日 **今天是我进入IT行业的第30天，也是我正式对渗透测试，逆向分析感兴趣的第一天。 **从一个什么都不懂的工科女，到对渗透测试有一点了解的小白，这是一个既漫长又短暂的过程。大学四年都没有接触过这些东西，只是自己学了一点网页开发和编程语言。来到公司实习后，开始正式接触安全服务类的项目。本来以为自己只是足够幸运找到了环境和同事都挺好的公司，没想到我还一直被幸运女神眷顾着，也找到了自己喜欢的方向。以后我会在这个行业继续学习更多的知识，努力掌握更多的技术，争取早日成为一个能发表技术文章的人。 **今天的博客是记录自己对这个行业产生兴趣的开始，争取以后发表更多有用的东西。 来源： CSDN 作者： Melancholly 链接： https://blog.csdn.net/Melancholly/article/details/103995142

文章目录 1. 写代码之前要做的事情 2.设置端到端的训练评估框架 1）固定随机种子 2）简单化 3）绘制测试集损失 4）在初始阶段验证损失函数 5）初始化 6）人类基线 7）设置一个独立于输入的基线 8）过拟合一个batch 9）验证减少训练损失 10）在训练模型前进行数据可视化 11）可视化预测动态 12）使用反向传播来获得依赖关系 3.挑选模型 1）挑选模型 2）Adam方法是安全的 3）一次只复杂化一个 4）学习率设置 5）每轮训练数据乱序 6）batch_size选择 7）学习率和batchsize的关系 4.正则化 1）获取更多数据 2）数据扩增 3）有创意的扩增 4）预训练 5）跟监督学习死磕 6）输入低维一点 7）模型小一点 8）减小批尺寸 9）Dropout 10）权重衰减Weight Decay 11）早停法Early Stop 12）附加 5.调参 1）随机网格搜索 2）超参数优化 6.测试阶段 1）模型融合 2）TTA测试时增强 参考博客 1. 写代码之前要做的事情 训练神经网络前，别管代码，先从预处理数据集开始。我们先花几个小时的时间，了解 数据的分布 并找出其中的 规律 。 Andrej有一次在整理数据时发现了重复的样本，还有一次发现了图像和标签中的错误。所以先看一眼数据能避免我们走很多弯路。 由于神经网络实际上是数据集的压缩版本，因此您将能够查看网络

对大多数人来说，若要建一幢数百万元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根” (Leffingwell 1997) 。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟 ( 期望差异 ) —开发者开发的与用户所想得到的软件存在着巨大期望差异。 在软件工程中，所有的风险承担者 (stakeholder)( 这个词很有意思，原义是赌金保管者。我看过很多的翻译，有翻译成涉众的，也有的翻译成参与者的，但是我想他的主要意思就是和这个项目有密切相关利益的人 ) 都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员 ( 负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人 ) 、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用有效的需求分析过程。软件需求的定义 IEEE 软件工程标准词汇表 (1997 年 )

1、bug的定义 需求文档存在差异的功能实现 与用户需求不符 2、bug的类型 代码（功能错误）：功能没有实现 界面优化：UI、用户界面 设计缺陷：开发、需求文档中的功能没有实现 3、bug的等级 1.致命缺陷： 系统崩溃、死机　　 安全性问题　　 涉及金钱计算　　 阻断性测试　　 2.严重错误　　 重要功能　　 功能交互　　 非常规操作导致的程序崩溃、闪退　　 界面难以接受　　 密码明文　　 偶尔出现的致命bug　　 3.一般错误 不影响产品的运行　　 次要功能不能正常实现　　 操作界面错误　　 查询错误，数据错误显示 限制未被控制 删除后为给出提示是（没有二次确认） 偶尔的严重性bug 4.细微错误 界面不规范 辅助说明描述不清楚 提示窗口文字 4、bug的生命周期 新建bug---指派---已解决---待验证---关闭 5、bug的跟踪管理流程图 　　 6、bug的跟踪管理--状态处理 已经指派的bug ----已经指派给开发的，请大家注意自己bug的走向，随时关注并进行跟踪!如果直未修复，提醒开发修改,以免开发忘记;如果已经修复等待测试环境更新后进行验证。催着改bug 已解决的bug ----等待测试环境更新后进行验证，验证通过则关闭;验证不通过则重新打开指派给开发 重复bug ------先去查看下是否跟开发指定的bug重复?如果确定是重复则关闭;如果不重复,说明原因

在App开发中，内嵌WebView始终占有着一席之地。它能以较低的成本实现Android、iOS和Web的复用，也可以冠冕堂皇的突破苹果对热更新的封锁。 然而便利性的同时，WebView的性能体验却备受质疑，导致很多客户端中需要动态更新等页面时不得不采用其他方案。 以发展的眼光来看，功能的动态加载以及三端的融合将会是大趋势。那么如何克服WebView固有的问题呢？我们将从性能、内存消耗、体验、安全几个维度，来系统的分析客户端默认WebView的问题，以及对应的优化方案。 性能 对于WebView的性能，给人最直观的莫过于：打开速度比native慢。 是的，当我们打开一个WebView页面，页面往往会慢吞吞的loading很久，若干秒后才出现你所需要看到的页面。 这是为什么呢？ 对于一个普通用户来讲，打开一个WebView通常会经历以下几个阶段： 交互无反馈 到达新的页面，页面白屏 页面基本框架出现，但是没有数据；页面处于loading状态 出现所需的数据 如果从程序上观察，WebView启动过程大概分为以下几个阶段： 如何缩短这些过程的时间，就成了优化WebView性能的关键。 接下来我们逐一分析各个阶段的耗时情况，以及需要注意的优化点。 WebView初始化 当App首次打开时，默认是并不初始化浏览器内核的；只有当创建WebView实例的时候，才会创建WebView的基础框架。

一. 摘要 这篇文章详细介绍了一个“多路信号采集系统”的开发过程。“多路信号采集系统”是一个可伸缩的信号采集系统，通道可以选择从0~100路不同的信号源。单个采集板都能够采集10路数据，用户可以根据自己的需求方便地扩展或者收缩信号通道数。本系统可以用于常见的民用或者工业现场监控、仪器仪表等数据采集场合。该系统基于Arm Context M3内核处理器实现，有基板和采集板两大部分组成，基板主要负责整个采集时序的控制，而采集板则完成真是的数据采集并将采集到的数据发送到数据总线，进而传输到主机端。数据传输采用了串口通信的方式（RS485），并采用Modbus协议实现，从而方便地实现了采集板地址的检索、数据量控制、以及CRC校验值确定等功能。软件系统则采用了固件库编程的方式，全程开发均使用C语言完成，从而为以后升级做好准备。开发使用了今日标企业工作平台以及Github代码托管平台相结合完成开发的方式，使用今日标企业工作平台管理项目开发流程，而使用Github则方便地实现了不同地区开发者协作开发的目的。而系统调试则选择了传统的调试方式，先进行单个功能模块测试，再测试系统功能，进而Burning实验。 二. 本文提纲 1. 摘要 2. 本文提纲 3. 项目起始 4. 开发方式选择 5. 系统构架 6. 硬件设计 7. 软件设计 8. 系统调试 9. 总结 三. 项目起始

软件工程知识技能水平高低的主要体现方面 1. 开发语言：至少熟练掌握一门编程语言 2. 数据结构与算法：算法是软件工程师的重点知识结构，算法的掌握情况往往能够决定软件工程师的成长高度 3. 开发环境：熟练掌握Windows、Linux等大型主流操作系统的操作，熟练掌握编程环境配置与软件环境部署 4. 软件开发流程： 熟悉掌握瀑布模型、敏捷开发等软件工程开发的流程。了解软件开发各周期或阶段的目标以及作用。了解软件开发的一些原则技术及方法 5. 团队协作能力：队员间在各个开发环节需要沟通协作 软件工程知识技能水平测评试题 一.选择题（共40分，一题4分） 1. 软件生命周期一般包括三个时期：软件定义期、软件开发期和软件运行期。下述（ ）不是软件开发期所应包含的活动。 A. 可行性分析 B. 需求获取和需求建模 C. 软件体系结构设计和数据设计 D. 软件集成与系统测试 答案：D 软件开发期所应包含的活动有：可行性分析、需求获取和需求建模和软件体系结构设计和数据设计。 2. “软件危机”是指（ ） A. 大众不适应软件的使用 B. 软件开发相关人才过少 C. 软件开发和维护中出现的一系列问题 D. 大量黑客出现 解析：C 软件危机指的是随着软件规模不断扩大而产生的一系列开发与维护的难题 3. 下列哪个不是瀑布模型的优点（ ） A. 项目提供了按阶段划分的检查点 B. 当前一阶段完成后

小组成员：郭立同，柳洋，孙晨旺，孙世鑫，刘玲玲，陈忠林 团队应该如何做好软件质量保证（QA） 软件质量是贯穿软件生存期的一个极为重要的问题,是软件开发过程中所使用的各种开发技术和验证方法的最终体现。因此在软件生存期中要特别重视质量的保证，以生产出高质量的软件产品。 软件质量保证的目标是开发出可接受的软件产品。这里所谓的“可接受”应是用户理解意义上的可接受,或者说应达到用户提出的质量要求。所以软件质量保证的任务自然就是保证软件质量。 软件质量保证是提高预防、检查与改进来保证软件质量,是软件生存周期的管理以及验证软件是否满足规定的质量和用户的需求。 软件质量保证是由各项任务构成,这些任务的参与者有两种人。软件开发人员和软件质量保证人员。前者负责技术工作,后者负责质量保证的计划、监督、记录、分析及报告工作。 软件开发人员通过采用可靠的技术方法和措施，进行正式的技术评审，执行计划周密的软件测试来保证软件产品的质量。软件质量保证人员则辅助软件开发组得到质量的最终产品。所以软件开发人员和软件质量保证人员都是保证软件质量的重要组成部分。 如果将一个软件生产类比于一个工厂的生产。那么生产线就是过程,产品按照生产线的规定过程进行生产。软件质量保证体系(SOA)的职责就是保证过程的执行,也就是保证生产线的正常执行。 所以我们可以总结出软件质量保证体系(SQA)的主要职责有以下三点: (1