-
VB实现自动生成统计图表
2018-04-30 20:43:47
方案主要解决如何通过按钮一次完成实现
表格自动生成统计图表。
使用对象
需要统计出各种直方图、饼图、趋势图需要的人员。
功能概述
1.自动选择表格，自动化生成统计图表。
2.自动设置图表式样、格式
3.设置按钮，满足‘一键完成统计图表’
主要功能界面
图1
图2
方案优势
优势1：扩展了TD REQUIREMENT功能，提供具体需求-用例覆盖数值（覆盖率）。
优势2：便于需求管理，实时评估测试用例是否符合标准“100%覆盖产品需求”。
优势3：增加字段，符合项目需求列表特性。
方案配置
1. 原始表格
以TD数据库定期导出的‘History_bug.xls’为例
表2
2.在EXCEL调用VB,实现筛选Reopen记录的功能
效果图：
表3
附：VB编码
Sub MacroName()
'
' MacroName Macro
-
fiddler抓取https的最终说明
2018-04-26 08:39:59
-
JMeter内存溢出解决办法
2018-04-26 08:37:10
使用jmeter进行压力测试时遇到一段时间后报内存溢出outfmenmory错误，导致jmeter卡死了，先尝试在jmeter.bat中增加了JVM_ARGS="-Xmx2048m -Xms2048m -Xmn256m -XX:PermSize=128m -Xss256k"，但结果运行时间增加了，但最终还是报内存溢出，百度后按照网友的建议更改了如下设置后jmeter就没有再卡了：
1、windows环境下，修改jmeter.bat：
set HEAP=-Xms256m -Xmx256mset NEW=-XX:NewSize=128m -XX:MaxNewSize=128m改为：set HEAP=-Xms256m -Xmx1024mset NEW=-XX:NewSize=128m -XX:MaxNewSize=512m根据经验，heap最多设置为物理内存的一半，默认设置为512M.如果heap超过物理内存的一半，可能运行jmeter会慢，甚至出现内存溢出，原因java比较吃内存，占CPU.注意：JDK32位的电脑Xmx不能超过1500m，最大1378m.否则在启动Jmeter时会报错：
2、linux环境下，修改jmeter.sh：java $JVM_ARGS -Xms1G -Xmx5G -XX:MaxPermSize=512m -Dapple.laf.useScreenMenuBar=true -jar `dirname $0`/ApacheJMeter.jar "$@"3、如果查看JDK的位数# java -version java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode) 如果是64位的话,最后一行会显示64-Bit #java -version java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) -
由《战狼2》的角色定位来认识软件测试行业
2018-04-24 08:47:35
-
高性能性能测试开发方法
2018-04-20 08:53:15
1. 背景技术1、 关于软件的性能测试：通常的做法是编写性能测试代码（脚本），性能测试代码实质上就是自动执行的客户端程序，可以简称为性能测试客户端。然后建立起性能测试进程，在进程内并发运行多个性能测试客户端访问应用服务，这样就达到了模拟多个客户端的工作压力进行性能测试的目的。
2、 互联网应用的兴起, 对性能测试提出了越来越大的挑战。 海量用户同时在线使用是互联网应用的显著特征，因此，互联网应用的性能测试要求测试场景中能够保证有大量的性能测试客户端同时运行，这样才能够达到充分真实模拟的目的。
现有方案一及其缺陷： 现有的性能测试方法绝大多数的情况下都是在使用某一种性能测试工具, 以被使用最多、评价最好的loadrunner 为例，其测试方法的过程如下：
· 测试代码的生成： 测试代码由2种方式得来，录制被测试应用客户端的行为，然后做参数化处理；或者直接开发出此类代码供使用
· 测试代码的特点：只模拟一个客户端的行为；所有代码都被设计成在一个线程内顺序执行。
· 测试执行：loadrunner提供测试进程，进程内为每一个性能测试客户端提供一个独占的线程。假如控制多台测试机（m台）、每台测试机启动多个测试进程（n个），每个测试进程包括多个测试线程（t个），这样，同时参与测试的客户端个数是 m*n*t 个。
现有方案示意图：
注：白色区域为测试人员开发的代码
缺陷：
从软件设计性能的角度来考虑， 以上设计不是一个高性能的方案，测试机线程个数、cpu使用率、内存等系统资源随测试压力的增加很快就会成为性能瓶颈。所以这样的方案只能测试一些低压力的场景，如果测试互联网业务，测试进程的性能问题会导致测试无法进行或者时间、资金、人员等成本十分高昂。
在设计过程中没有考虑到测试客户端互相通信的需求，比如性能测试客户**谀掣霾馐允笨桃笮阅懿馐钥突Ф薆完成某个功能或变更某种属性，这是无法办到的，因为某个性能测试客户端在设计上是封闭的，导致测试场景设计上不够灵活。
优点：
测试进程、进程的内线程都由测试工具来控制，测试代码无需关心，测试代码独立、无互相通信的需求，这样都保证了测试代码简单易开发，易上手，低技术级别的人员也可以完成性能测试任务。这样的设计结构也保证了商业的性能测试工具能够容易的控制license，保护其商业利益。
2. 技术方案描述
要解决的技术问题：
极大地提供测试进程承载性能测试客户端数量的能力。提供性能测试客户端互相通信的支持
整体思路：
从纯粹软件的视角来考察测试进程，可以定义为：包括多个测试客户端，每个客户端可以自动运行测试业务。
进一步分析，可以发现测试进程除了测试业务必须自动执行以外，其它方面和一个应用服务程序没有本质差异，也包括大量内存对象，也需要高并发、高吞吐量地处理请求和应答消息。
所以，为了实现高性能的测试进程，必须摒弃测试代码只是完成一个客户端功能的思路，摆脱测试工具对线程的控制，以设计互联网高性能应用服务的思路来解决问题。
在设计高性能服务程序时，线程池几乎是一个必选项，测试进程也需要引入线程池做为提高性能的必要手段。
测试客户端离开了依附的线程如何能够自动的执行下去，也需要一个方法得到保证。
方案一：
1. 测试进程继续由**的测试工具提供或者由开发者自己开发。
2. 必须由性能测试开发人完成的部分包括以下部分：
a. 性能测试客户端代码：不再只是一段顺序执行的代码；而是一个包括必需的客户端属性和业务行为代码合集，在面向对象的语言中，称为“类”。所有客户端对象存储在同一个数据结构中，比如数组、哈西表等。
b. 线程池：提供线程完成性能测试客户端的业务行为；每开始一次业务操作前从池中申请一个空闲线程、业务操作结束后归还。
c. 调度定时器: 周期性地选择多个性能测试客户端和下一步他们需要执行的业务操作、为每个客户端和对应的业务操作从线程池选择空闲线程，执行。
示意图如下：
注：白色区域为测试人员开发的代码
优点：
线程池引入极高地提高了性能。
测试客户端转变了编程方式和存储方式、统一调度定时器的引入，能够更灵活方便地控制测试过程、控制场景、特别是当测试客户端需要协调调度的时候；测试客户端之间的通信需求通过进程内的过程调用就可以完成。
3. 技术方案的关键点和保护点
本技术方案与现有方案不同的部分，为了达到有益效果不可缺少的部分，可以是一个或多个。如果是多个的话，按重要程度从高到低的顺序列出。
重新定义测试进程的结构引入线程池极大提高了性能
重新定义测试进程的结构引入调度定时器配合线程池使用
性能测试客户端由原来的一段顺序执行的代码转变为属性和行为构成的单元（在面向对象的编程中称为“类”），并且存储在一个数据结构中。
-
python开发工具pycharm快速入门
2018-04-16 22:10:19
本教程是关于什么的本教程旨在引导您完成创建，运行和调试一个简单的Python项目，使用PyCharm一步一步 - Python的IDE有一整套完整的生产性的开发工具。
本教程不是关于哪些的
Python编程超出了本教程的范围。要了解更多关于Python语言，请参考官方网站。
在开始之前
请确保：
§ 您正在使用PyCharm 2.7版或更高版本
§ 至少有一个Python解释器，版本从2.4到3.3是正确安装在您的计算机上。
下载和安装PyCharm
如果您还没有PyCharm，从这里下载这个页面。要安装PyCharm，按照说明，根据您的平台。
启动PyCharm
有很多方法来启动IDE，根据您的操作系统。
§ 如果你有一个桌面快捷方式图标 ，只需双击它。
§ 根据您的PyCharm安装的bin目录下，双击pycharm.exe或pycharm.bat（Windows）中，或pycharm.sh（MacOS和Linux）的。
PyCharm启动并显示欢迎屏幕：
创建于PyCharm一个简单的Python项目
要创建一个新的项目，单击该链接Create New Project。你看，Create New Project对话框中，在那里你必须定义所有新项目进行必要的设置。
需要注意的是，你可以创建一个新的项目随时...为了做到这一点，使用File → New Project的主菜单上。
首先，指定项目名称 - 让它成为MySimplePythonApplication。需要注意的是PyCharm默认情况下显示的项目位置。您可以接受默认位置，或单击浏览按钮，找到一些合适的地方你选。
接下来，选择项目类型。PyCharm提出了不同类型的应用程序（Django的，谷歌的AppEngine等）的发展的几个项目模板。当PyCharm建立从项目模板创建一个新的项目，它产生相应的目录结构和具体的文件。
不过，在这里我们的任务是创造Python的一个项目。在这种情况下，我们选择的类型的空项目-它是纯Python编程最合适的。在这种情况下PyCharm不会产生任何特殊的文件或目录。
最后，让我们选择一个Python解释器。正如你看到的，PyCharm通知您的Python解释器尚未选定。因为你至少有一个Python解释器在您的处置，让我们把它定义为项目的解释。
要做到这一点，点击旁边的浏览按钮。在Python Interpreters对话框中，单击，选择本地...，然后选择从文件系统中所需的解释：
当所有必要的设置完成后，OK按钮变为可用-所以点击它，并让你的项目做好准备。
探索和配置项目结构
您可以查看在最初的项目结构Project工具窗口：
如你所见，该项目只包含项目的根，和Python解释器，你在所指定的External Libraries节点。
接下来，让我们来探讨和详细配置项目结构：单击主工具栏上，然后选择Project Structure页面：
根据该项目的根目录，你看.idea目录-它包含MySimplePythonApplication.iml文件，反映了项目结构，和几个XML文件，每一个负责其自己的一套设置，可以通过它们的名字被识别：encodings.xml，VCS的.xml 等。需要注意的是.idea目录是不是在Project工具窗口可见。
接下来，让我们添加源根，所有的工作将被实际执行。在同一个Project Structure页面，用鼠标右键单击项目根目录，然后选择New Folder的右键菜单上：
接下来，输入目录名：
最后，让我们来庆祝这个目录为源根：选择的src目录下，点击你看到的src目录，现在标有
图标。单击确定应用更改并关闭Settings/Preferences项对话框。
请注意，其实这一步是可选的。你可以创建在项目根目录的文件，它会被视为源，因为默认情况下，该项目的根目录是源根。
-
使用 email-ext 替换 Jenkins 的默认邮件通知
2018-04-16 09:15:12
1 简述
众所周知，Jenkins 默认提供了一个邮件通知，能在构建失败、构建不稳定等状态后发送邮件。但是它本身有很多局限性，比如它的邮件通知无法提供详细的邮件内容、无法定义发送邮件的格式、无法定义灵活的邮件接收配置等等。在这样的情况下，我们找到了 Jenkins Email Extension Plugin。该插件能允许你自定义邮件通知的方方面面，比如在发送邮件时你可以自定义发送给谁，发送具体什么内容等等。本文不会告诉你如何安装该插件。
2 配置
它主要包含两个部分：全局配置和项目配置。
2.1全局配置
当然，在一个项目中应用 email-ext 插件之前，您必须做一些全局的配置。现在先跳转到 Jenkins 的“系统设置”页面，如下图：找到标题为“Extended E-mail Notification”的片段，你就能配置一些全局的 email-ext 属性。这些属性必须匹配你 SMTP邮件服务器的设置。这一节不仅能配置成 Jenkins 原有邮件通知的镜像(虽然有很多配置是一样的，但这是个不同的扩展点)，而且还增加了一些额外的功能。输入框中名为 Default Subject 和 Default Content 的项允许你在全局级别配置邮件的内
容。这样做的话，可以使您为所有的项目按您的需求做更好的、更简单的配置。如下图。
-
性能测试的原则和方法
2018-04-12 21:28:02
什么是性能问题
性能问题表现第一种
小规模使用的时候性能表现很好，在大规模使用的时候，性能变得很差，业务响应时间随业务压力变得越来越慢
原因：代码中对资源使用产生的瓶颈，后续的请求在资源(cpu、内存、锁、线程池)上排队
例子： 没有索引的表的查询 随着业务量增加，表的行数快速增加，查询越来越慢
性能测试解决的大部分问题是这种类型
性能问题表现第二种
在一定压力情况下，应用的性能突然变差或者不可使用
原因：应用突然进入了一个异常逻辑，占用了很多资源，并且无法从异常状态下退出
例子：fetion 后台 初期版本中使用同步的socket连接，网络单点异常的时候，全网的服务都不可用。
性能测试很难解决这种类型的性能问题。很难定位异常逻辑是什么。
性能问题表现第三种
在压力大于某个阀值的情况下，总会出现少量业务错误
原因：业务逻辑考虑不严密，导致少量流程不是按照期望发生
例子：取一个值做uniquekey值，锁保护不够导致，取值不唯一。
性能测试能够很好的解决这类问题。
一些基本概念详细解析
响应时间
Response time是性能测试中考察被测试软件性能的一个指标；
Response time包括从客户端请求发出开始，到reponse 应答回来后的时间总和，可能包括：
网络传输
cpu上可执行队列的等待时间
cpu计算
线程执行sleep语句的时间
锁、闩的等待时间
磁盘io等待时间等。
吞吐量tps
吞吐量 tps是考察性能的另一个指标；
单位时间内完成业务量的多少，tps 是一个具体的常用的指标，每秒钟完成的业务个数。
通常的误会是认为response time一定会影响tps，这个不一定成立
并发
并发是指同时被处理的请求个数，同时处理可以有2个含义
同时都在线程堆栈上的请求
指在正在cpu上处理的请求
这里指得是后者。
那么最大的tps = Concurrency*1000 /请求在cpu上的处理时间(ms)
思考时间
Think Time思考时间 Think time是在测试代码中出现的概念，为了在测试代码中模拟时间用户的思考时间而加的sleep时间，2个作用
第一作用是控制测试代码的业务执行速度，完美地执行出预计的场景
模拟实际用户执行的思考时间
有状态的服务 很重要
无状态的服务 不重要
测试压力 business load
测试压力是什么？或者是客户做了什么导致服务器产生压力
对于无状态服务器，客户端的压力来源于客户端的请求数/秒
对于有状态服务器，客户端的压力是客户端的在服务器的留存信息和rps。
数据库是一个有状态的服务器
有状态的服务器更容易有性能问题
性能测试过程
完美的测试过程
完美的性能测试就是软件在现网上实际运行的过程
实验室状态下永远也无法完全模拟
性能测试无法找到所有的问题
性能测试方案
定义了在影响软件运行性能的各个方面采用什么样的方法和策略模拟真实的情况，达到尽量真实模拟的目的。
非常重要， 决定了测试的成败
基础数据 : 测试之前，测试环境中已有的数据总和
关于基础数据的原则
必须调查或者预测出数据库表中每个表应该有多少行的数据。
而且数据取值要实际情况一样丰富。
数据长度和实际情况相同
基础数据决定着数据库server的cpu、内存、io使用或其他多种资源的使用逻辑。
测试数据： 从基础数据中选取的，参与到性能测试中的数据
选择原则
在应用合理范围内随机挑选数据、挑选足够的量。
挑选数据的方式通常影响数据库的内存和io，有状态服务的cpu和内存，线程、锁等。
业务模型
测试完成哪些业务？完成速率？
建立业务模型的原则
最好是实际用户行为的统计，如果没有借助同类软件的用户行为统计，再没有，根据有经验人员的预估。
把用户所有可能使用业务按使用频繁程度排序，频繁程度越高就越应该纳入测试场景。
查看业务消耗计算资源的程度，预计消耗程度越大的越应该纳入测试场景
建立业务模型的原则
多个业务在一起的复杂场景：把所有业务的在周期内的tps放在一起考察，一般情况下所有业务会有一致性的行为，即tps变化一致，取峰值阶段的tps为测试通过标准。
如何有明显不一致，需要取2到多个典型场景分别测试
测试场景
多大测试压力（多少在线用户或者rps是多少）
预估和实际预测的结果
测试多长时间？
无状态的几个小时
有状态的几天
硬件资源选择的原则
大型分布式软件的中每个角色都需要负载均衡的设计才能够平滑扩展。 那么测试环境只需要取得这样一个环境的小的集合就可以了。
单个硬件设备最好使用上线后用的机器，因为不同设备之间的差异很大，无法但从cpu、内存、tpcc等指标来分析硬件之间的差异。
使用差异很大的设备测试只能定性的说明问题，无法定量
如何编写测试代码
能和实际的客户一样完成业务功能。这是最基本的能力，也是性能测试的基础，必选
对每次与服务器的交互做严格的结果正确性检查，保证功能执行的正确性。性能测试的目标不仅仅是提供测试的工作压力，而且要保证测试功能的正确性，必选。
提供出错日志功能，这对于初步分析性能问题，或者测试代码、被测试软件的功能问题都是非常好的手段，可选
测试代码在设计时要意识地保证数据库的数据量的稳定性，可选。
提高测试代码可配置性，保证在多种不同的测试场景下，测试场景可迅速建立，可选。
测试执行人的能力要求
测试人需要按照测试方案的要求，配置测试代码和使用测试工具建立起方案中的测试场景，必选。
按照方案选择合理的测试数据，必选。
测试人必须完全了解测试代码的每个细节，如果在测试中发现测试任何错误，如果这个错误是测试代码或者场景设置的问题，测试人有能力解决，必选。
判断测试的结果分析是否有性能问题，必选。
对于服务方的问题，提供当时的上下文环境供开发和优化人员分析，可选。
能够解决被测试软件方由于配置错误等引起的简单问题，可选。
软件优化的基本步骤
性能问题有哪些？ cpu的瓶颈、内存的瓶颈、磁盘io的瓶颈、网络io的瓶颈、线程之间同步的瓶颈等等
软件优化好以后应该是什么样？特征
Tps 基本上和cpu使用率正相关
响应时间1-50 ms， tps 几百几千几万
参考测试设备 cpu等资源的情况
业务完成过程的复杂度
如果有性能瓶颈
首先排查其它瓶颈，保证tps和cpu正相关。
察看是否有cpu滥用的现象
“所有高cpu的问题都是不必要的循环引起的”---个人体会
没有索引的表的查询
应用本地没有缓存，反复从数据库或者其它应用获取。
线程数太多，导致过多的上下文切换。
-
python中logging会重复写日志的问题分析
2018-04-07 17:47:02
现象
重复写日志的情况，如下
原因
当第二次调用log的时候，根据getLogger(name)里的name获取同一个logger，而这个logger里已经有了第一次你添加的handler，第二次调用又添加了一个handler，也就是说这个logger里有了两个同样的handler，所以就会出现调用几次就会有几个handler
解决方案
在日志记录完之后removeHandler
例如：logger.removeHandler(streamhandler)
除此之外你也可以去判定下，如果logger.handlers列表为空，则添加，否则，直接去写日志，例如
if not logger.handlers: xxxx logger.error
我的栏目
标题搜索
我的存档
数据统计
- 访问量: 88727
- 日志数: 66
- 建立时间: 2008-04-20
- 更新时间: 2019-02-23
