测试过程

在做并发测试的时候，需要参考tomcat的maxThreads、acceptCount（最大线程数、最大排队数）； tomcat 的Connector配置如下 <</span>Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" maxThreads="800" acceptCount="1000"/> 其中最后两个参数意义如下： maxThreads ：tomcat起动的最大线程数，即同时处理的任务个数，默认值为200 acceptCount ：当tomcat起动的线程数达到最大时，接受排队的请求个数，默认值为100 这两个值如何起作用，请看下面三种情况 情况1：接受一个请求，此时tomcat起动的线程数没有到达maxThreads，tomcat会起动一个线程来处理此请求。 情况2：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，tomcat会把此请求放入等待队列，等待空闲线程。 情况3：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，等待队列中的请求个数也达到了acceptCount，此时tomcat会直接拒绝此次请求，返回connection refused maxThreads如何配置

在本文中，我们讨论如何快速地从更高的层面理解DevOps，介绍准备改变文化的最佳实践。我们将讨论DevOps的目标以及从组织管理层得到支持的方法，为DevOps的概念打下基础。我们将试着从根本上介绍使应用程序生命期管理简单、高效的DevOps实践。 DevOps不是一种框架、工具或者技术，理解这一点非常重要。它更多的是与组织的文化有关。DevOps还是人们在组织中使用预先定义的过程、利用自动化工具，使日常工作更加高效、手工工作更少的一种方法。 为了理解DevOps的重要性，我们在本文中将包含如下主题： DevOps的必要性； 如何发展DevOps文化； PPT（人、过程和技术）的重要性； 为什么DevOps不全和工具有关； DevOps评估问题。 1.1　DevOps的必要性 每个伟大的梦想都源于梦想家。永远铭记，你拥有的力量、耐心和热情，可以令你摘星揽月、改变世界。 改变是生命的法则，也适用于组织机构。如果任何组织或者个人只盯着过去或者现有的模式、文化或实践，他们就肯定会错失未来的最佳实践。在动态的IT世界中，我们必须赶上技术革新的步伐。 我们可以参考乔治•萧伯纳的名言： 不改变就不可能进步，无法改变自己的想法，就不能改变任何东西。 现在，我们关注的是应用程序生命期管理方法的改变。重要的是，我们是否真的需要这种改变？我们是否真的需要经历改变的痛苦？ 答案是肯定的。 人们可能会说

在测试活动结束后，进行测试过程回顾是很好的事情，能帮助我们看看测试过程各个模块投入的精力是否合理，测试状态是否饱满，测试过程是否存在风险及下次活动怎样规避。 从各角度统计缺陷，学会看图说话： 缺陷提交时间bug数量趋势图 如果bug发现越靠后，那风险越高，期望在后期呈现收敛趋势 （在测试执行过程中，除了关注测试进度把控， 还可以关注bug数量趋势，看测试人员的测试状态是否需要调整） 缺陷严重性分布图 （致命问题是迭代模块的主要功能受阻； 严重问题主要为迭代模块的主要功能、数据、展示等问题； 一般性问题主要为迭代模块中的次要功能、展示等问题； 轻微问题主要为提示、建议、优化或影响小等问题。） 缺陷模块分布图 （该迭代版本主要集中在**和**模块，故缺陷较多。 缺陷数量排在前5位的模块分别为：PC后台(12)、……） 缺陷处理状态分布图 （注：遗留*个问题未关闭。 原因：1个无法重现，1个不紧急且有规避措施，1个目前系统业务形态暂是如此、后期分析后探讨解决方案，故团队评审后决定延期处理。） 缺陷激活次数，能反应bug的修复质量 （在测试过程中，回归bug时，注意能激活的就不重新新建bug） ============以上，以后测试工作中哪些方向可以改进？？================== 比如： 1.测试执行阶段，过程的记录可以优化（加入模块的第几轮测试的情况） 2.作计划时

========================================================================================================== 写在前面： 发现整理了很多问题，却没有一个系统学习的过程 ，所以定期维护学习网址，定期更新。 ========================================================================================================== 测试菜菜鸟的蜕变： http://www.51testing.com/html/53/462853-3718359.html 各种教程网址： https://www.yiibai.com/java/io/bytearrayoutputstream_tobytearray.html 来源： https://www.cnblogs.com/conquerorren/p/11857728.html

目录 为什么需要软件测试？回到顶部 为什么选择软件测试行业？回到顶部 为什么不让开发自己做测试？回到顶部 什么是测试？回到顶部 软件测试的作用？回到顶部 软件测试的诞生回到顶部 软件测试出现原因回到顶部 软件测试的发展回到顶部 软件测试的目标回到顶部 缺少软件测试发生的事故回到顶部 软件测试常见的误区回到顶部 软件测试的主要工作回到顶部 测试原则回到顶部 测试对象回到顶部 软件架构回到顶部 常见项目组织架构回到顶部 软件测试用例回到顶部 什么是测试用例回到顶部 为什么需要测试用例回到顶部 测试用例的意义回到顶部 测试用例的生命周期回到顶部 测试环境设计回到顶部 测试力度回到顶部 软件测试计划书回到顶部 测试计划的意义回到顶部 测试目标回到顶部 资源配置回到顶部 风险控制回到顶部 如何制定测试计划回到顶部 5W1H方法回到顶部 工作经验之谈回到顶部 图解软件测试计划回到顶部 软件计划报告回到顶部 软件兼容性回到顶部 what，什么是软件兼容性测试回到顶部 why，为什么要进行软件兼容性测试回到顶部 when，什么时候开始软件兼容性测试回到顶部 where，软件兼容性测试都要测什么回到顶部 who，谁来执行软件兼容性测试回到顶部 how，怎样执行兼容性测试回到顶部 版本控制回到顶部 引入版本控制的原因回到顶部 版本控制的定义回到顶部 版本控制方法回到顶部 版本控制评价标准回到顶部

在代码层次，在编码之前写测试脚本，可以称为单元测试驱动开发（Unit Test Driven Development，UTDD） 在业务层次，在需求分析时就确定需求（如用户故事）的验收标准，即验收测试驱动开发（Acceptance Test Driven Development，ATDD）。 来源： https://www.cnblogs.com/sea-stream/p/11844802.html

PSP表格 PSP2.1 Personal Software Process Stages 预估耗时（分钟） 实际耗时（分钟） Planning 计划 5 5 · Estimate · 估计这个任务需要多少时间 10 10 Development 开发 120 120 · Analysis · 需求分析 (包括学习新技术) 60 60 · Design Spec · 生成设计文档 10 10 · Design Review · 设计复审 10 10 · Coding Standard · 代码规范 (为目前的开发制定合适的规范) 5 5 · Design · 具体设计 10 10 · Coding · 具体编码 10 10 · Code Review · 代码复审 5 5 · Test · 测试（自我测试，修改代码，提交修改） 10 10 Reporting 报告 20 30 · Test Repor · 测试报告 10 20 · Size Measurement · 计算工作量 10 10 · Postmortem & Process Improvement Plan · 事后总结, 并提出过程改进计划 10 20 总计 295 325 学习进度条 第N周 新增代码（行） 本周学习耗时(小时) 累计学习耗时（小时） 重要成长 1 50+ 4 4 更加熟悉分析过程 来源：

2.5 LEFT JOIN查询 该测试主要用于测试LEFT JOIN与JOIN的处理逻辑上的差异，具体查询处理逻辑如下所示： JOIN:prepare阶段 setup_tables()：同2.1测试。 setup_fields()：同2.1测试。 setup_conds()：同2.4测试。 JOIN:optimize阶段 simplify_joins()：类似2.4测试。不同之处在于由于LEFT JOIN 使用的数据表不能为 NULL表，这是由是否有where条件过滤决定的。所以该过程会将LEFT JOIN外链接查询转化为多表联合查询操作，从而忽略LEFT JOIN的链接操作。 optimize_cond()：同2.1测试。 make_join_statistics()：同2.4测试。 choose_plan()：同2.1测试。 greedy_search()：同2.1测试。 best_extension_by_limited_search()：同2.4测试。 get_best_combination()：同2.4测试。 JOIN:exec阶段 以下同2.4测试。 Left join 嵌套（ join ）查询 ， 执行SQL： SELECT student.std_id, std_name, std_spec, std_***, std_age, cur_name, cur

2、复合查询 在进行复合查询时，为了体现外连接（left join、right join）和一般联合查询的区别，对student表增加了几条记录，而这几条记录在std_cur和course中都没有对应的记录。 2.1 多表联合查询 多表联合查询的逻辑处理过程如下所示： JOIN:prepare阶段 setup_tables()：对查询涉及的表，逐个查看是否存在，设置变量相应的值，为查询准备。 setup_fields()：对查询的字段进行检查，不同于之前1.1的检查，该过程中如果不指定具体数据表的字段的话，将会对所有查询的数据表进行检查。 setup_conds()：检查查询的where条件中字段是否存在，同样如果不指定具体数据表的字段，将会对所有查询的数据表进行检查。(sql_base.cc:8379) JOIN:optimize阶段 simplify_joins()：如果可以将外连接简化为内连接处理，那么简化为内连接处理。此外，如果查询为内连接或者外连接查询使用的表拒绝 NULL值，那么将ON条件添加到where条件中，将表的连接操作转化为联合查询处理。在该测试中，由于没有显示的JOIN ON操作，因此不做以上处理。 optimize_cond()：优化查询的where条件，对等值条件调用build_equal_items()（sql\sql_select.cc:8273

2. show databases; 显示可以数据库 update novel_reg_info_new53 set create_time=1525752469 where id = 868971573； 3.使用chalers抓取请求的url，一般从url中可以看出来请求的接口，字段应该是type = content 这里面包含了领取七天免费特权的接口is_7days_free，这个接口是后端的接口。如果有的接口被前端包裹，可以使用查看日志的方式查看，以本次环境为例，查看方式是tail -f log/access_log | grep content --color 4. 线下测试环境和前端联调的时候，开发的代码里面肯定是线上的环境，所以需要一步替换操作 sed -i "s/https:\/\/boxnovel.baidu.com/http:\/\/cp01-boxnovel.epc.baidu.com:8085/g" `grep https:\/\/boxnovel.baidu.com -rl .` 文章来源: 测试过程操作数据库等操作