m0_74038875的博客

g)其他外部系统响应时间过长，造成本系统的 time-wait。c)中间件（tomcat/nginx/mysql）连接数限制。f)本系统资源的瓶颈（cpu、内存、磁盘、网络等）b)应用程序：内存、线程的阻塞、等待。a)压力机本身性能瓶颈。b)网络 IO 瓶颈。

学生表 student（学生编号 sid、学生姓名 sname、学生年龄 age）成绩表 result（学生编号 sid、课程编号 cid、分数 score）课程表 course（课程编号 cid、课程名称 cname）4、 查询每门课程成绩都在 80 以上的学生姓名。3、 按平均成绩从高到低显示所有学生的平均成绩。1、 查询出年龄最大的 3 位同学信息。2、 查询学生每个年龄都有多少人。

哪些地方容易出 bug：参数校验、边界条件、复杂的逻辑、以及一些异常的场景没考虑。bug 的类型：主要是代码逻辑错误、配置错误。

2. 降低用例之间的耦合性，每个用例尽量都走完整的流程，不要依赖于其他用例，避免其。3. 提升依赖环境的稳定行，通常某些用例会依赖第三方系统的环境，如果第三方环境不稳。定，会造成用例执行的不稳定。可以采用 mock 的形式，屏蔽第三方环境，提升环境稳。4. 脚本的异常处理，在脚本中要多考虑可能出现的异常，尽量对每种异常都有对应的处理。避免使用固定的数据，测试用例中使用老的测试数据，可能会被别人修改或删除。每次跑脚本前，在脚本中构造新的数据，跑完脚本后，把数据清理掉。他用例执行失败，影响了后续的用例。

3、良好的沟通协调能力，在测试过程中需要和产品、开发、运维保持沟通，推动项目进展，2、良好的技术能力，测试基础、用例设计、数据库、Linux、自动化、性能、代码等。单纯从测试这个职位来说的话，我感觉做好测试工作，需要做好以下这些事情。1、良好的业务能力，可以快速熟悉业务系统，并找到对应的测试点。4、保持耐心、细心、责任心。

3、描述问题要简洁、清晰，比如现在在做什么事情，遇到了什么问题，需要开发提供什么。4、测试要有自己的原则和立场，自己认为是正确的事情，要坚定立场和自我判断，不能完。2、不要过渡依赖开发，遇到问题先自己尝试分析下，有一个基本判断后，再去找开发。1、就事论事，跟开发沟通时不要携带任何情绪，客观真实的进行沟通。5、尽量集中式沟通问题，避免碎片化沟通，导致开发工作频频被中断。7、遇到非常难沟通的开发，有必要时，要及时向上反馈，寻求帮助。6、提升自己的技术能力和认知，用更专业的语言和开发沟通。

3、如果自己解决不了问题，要及时向外抛出，暴露风险，寻求帮助。6、及时对 bug 进行追踪，推动开发尽快解决 bug。2、做好测试策略和计划安排，尽量保证每个环节按时完成。1、评估项目的测试范围和测试周期，是否能单独完成。5、对用例设置好优先级，按照优先级去执行。7、把控好上线标准，测试报告中标明上线风险。4、尽量采用一些技术手段，提升测试效率。

基本上我所测试的，没有出现过 P0 和 P1 级别的 BUG。测试时间不充足，导致一些功能点在测试过程中被忽略。开发人员修复其他 bug 时引入的新 BUG。那我主要说一下常见的漏测 bug 的原因。需求规格不明确，导致测试用例编写过于粗略。测试环境或测试数据受限，导致缺陷漏测。需求规格变更，测试用例未及时更新。测试用例覆盖不全面，场景出现遗漏。测试过程中未严格按照测试用例执行。偶有一些很小的问题，主要的原。

最后，线上 bug 解决后，要做问题复盘，将整个过程记录下来并进行相关分析总结，避免后。根据之前的一些经验来看，我首先和开发一起初步评估 bug 的严重程度和产生原因。如果是出现了影响面比较大的功能性问题，且暂时不好定位具体原因，首先考虑是做代码回。如果是性能方面的问题，一般会进行扩容，或者重启尝试解决，然后开发会做进一步问题定。如果能快速定位问题原因，开发会做紧急修复，测试通过后会申请紧急上线。然后在测试环境进行复测，并定位问题原因。如果是不太严重的问题，通常会放在下一个版本解决。

没有访问权限（比如缺乏 token、cookie 之类）- 如果是浏览器访问，是不是绑定了错误的 hosts。- ip 或者端口号或者 url 写错了。- 服务端项目根本没有部署起来。- 服务端程序内部发生了错误。- 客户端和服务端网络不通。- 服务器的防火墙拦截了。- 客户端设置了网络代理。

首先打开charles，点击proxy里面的throttle settings进行设置弱网。点击proxy的breakpoint settings进行设置断点。

我会到测试环境上部署本次开发修改的bug的代码，然后在准备测试数据，到被测软件上执行，测完之后如果bug修复了，我也会将bug改为关闭，如果在验证的时候开发没有修复完成，我也会将日志截图下来让开发去进行修改，等开发修改完成再次复验，直到它验证通过为止，此时还有另外一种情况，当前的版本比较紧急，开发来不及进行修改，领导也同意的情况下，可以暂时挂起，关联到挂起的bug我会关联到下个版本，在测试的时候也会跟踪这个bug直至关闭，如果是拒绝的情况下，只要它的理由是合理的，领导也接受，那我也可以把这个bug写到测试报

公平公正，赏罚分明，工作外大家也能够时常聚会做好。工作内大家分工明确，团队。相互配合，积极协作。每个人的特点特长给大家。nice，懂得如何去。

3.到了对账的时候，对账文件生成了一个对账表，我可以到对账里面根据对应的日期查询下有没有对账文件的生成。1.在进行签约的时候，签约完成，需要到对应的数据库去看一下他的落库情况，是否有对应的签约信息。2.在对已经签约的进行解约，需要到签约信息表，看一下他的状态是否是从已签约变成已解约。5学校方扣款交易流水表，去查询交易金额的正确性。4.清算的时候，查询清算的状态。

测试方面：web端需要测试对不同浏览器的兼容（IE、chrome、Firefox），而h5需要测试浏览器兼容、系统版本兼容、分辨率兼容；（不同的是一个是app嵌入的h5，可以用浏览器打开单独测试，或者是嵌入到APP里面，需要测试的是app不同的版本对于h5的版本的兼容测试，）h5和web，从测试流程来讲，它们的主流程是一样的，都是要经过需求分析、评审、案例编写、测试。：功能测试：刷新、回退、前进、翻页、页面加载、url、界面测试；：功能测试：刷新、回退、前进、翻页、页面加载、url；

less 日志文件名 | grep "ERROR"grep "ERROR" 日志文件名。

Select a.class，b.subject，avg（b.score） from score b join student a on a.id =b.student.id group by a.class，b.subject；

a)首先，将问题提交到缺陷管理库里面进行备案。

2、where子句基于指定的条件对记录行进行筛选；3、group by子句将数据划分为多个分组；1、from子句组装来自不同数据源的数据；8、使用order by对结果集进行排序。5、使用having子句筛选分组；7、select 集合输出；4、使用聚集函数进行计算；6、计算所有的表达式；

token就是令牌，是一个字符串，主要是用于做客户端身份认证，通常登录成功后，服务端会返回token，客户端需要把token值保存下来，后续请求其他接口时，需要在请求中携带这个token值，只有 服务端对token校验通过后，才允许访问。

如果还是不行，那可以给这个问题提出来,跟开发经理和测试经理进行确认。如果最终bug被确定不改， 那么就要在测试报告里面记录一下，以便以后查阅。二是这种情况不可能发生，所以不需要修改，这个时候可以先尽可能的说出是BUG的依据是什么？如果 被用户发现或出了问题，会有什么不良结果？一是需求没有确定，所以这个时候可以找来产品经理进行确认，需不需要改动，商量确定好后再看要不 要改。

首先需要明确的是，该类bug也是需要提bug的，描述清楚当时操作环境、操作步骤、数据、并提供必要 日志，可备注上可能产生原因。然后耐心一点，运用排除法、错误推测找规律，必要时找开发人员一起 定位分析讨论。如果最终仍未解决，那么需要在测试报告中体现，并分析可能造成的影响，大家一起讨论该bug是否可遗留。

4、要从多个维度对软件进行测试，功能、性能、安全等各方面来考虑。1、要根据需求文档来编写用例，确保每条需求都被对应的用例覆盖。2、要充分理解业务，挖掘隐形需求，并编写对应的用例。3、除了正常的业务场景，多考虑一些异常的场景和数据。5、多站在用户的角度去思考问题，模拟用户的使用场景。

可以根据用户的使用习惯和一些行业的规范，来总结一些功能需求。可以找相关人员进行沟通，获取需求，比如产品经理、开发人员。没有需求文档不代表没有需求。

4、对于无法打成一致的问题，可以组织相关人员开会，共同来决定是否为bug。2、看下这个问题是否违反了正常人的行为习惯，或者行业的通用规范。3、可以找产品经理或者开发人员沟通确定是否为bug。1、看需求文档，是否有明确的要求。

在 Python3 中，input()获取用户输入，不论用户输入的是什么，获取到的都是字符串类型的。在 Python 中有 raw_input()和 input(), raw_input()和 Python3 中的 input()作用是一样的， input()输入的是什么数据类型的，获取到的就是什么数据类型的。

设置思考时间，是为了更真实的模拟用户。录制Vuser 脚本时， VuGen 将录制实际思考时间，并插入到Vuser 脚本中响应的Lr_think_time 语句。可以编辑录制的Lr_think_time 语句，并向 Vuser 脚本手动添加更多 Lr_think_time 语句。当录制 Java Vuser 脚本时，不会在 Vuser 脚本中生成 Lr_think_time 语句。可以使用【Run-time Settings】，更改执行 Vuser 脚本时 Lr_think_time 语句的运行方式。