今天完成的事：

*1. 问：你在测试中发现了一个 bug ，但是开发经理认为这不是一个 bug ，你应该怎样解决。
①.根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 
如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 
②.根据用户的一般使用习惯，来确认是否是缺陷； 
③.与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 
合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并由上级做出决定。
*2. 问：给你一个网站，你如何测试？
制定测试计划，确定测试范围和测试策略，一般包括以下几个部分： 
功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试 
② 设计测试用例： 
功能性测试可以包括，但不限于以下几个方面： 
链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回等。 
③ 提交功能的测试。 
多媒体元素是否可以正确加载和显示。 
多语言支持是否能够正确显示选择的语言等。 
④ 界面测试可以包括但不限于以下几个方面： 
页面是否风格统一，美观；页面布局是否合理，重点内容和热点内容是否突出；控件是否正常使用；对于必须但为安装的空间，是否提供自动下载并安装的功能;文字检查 
⑤ 性能测试一般从以下两个方面考虑： 
压力测试；负载测试；强度测试 
数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。 
⑥ 安全性测试： 
1 基本的登录功能的检查 2 是否存在溢出错误，导致系统崩溃或者权限泄露 3 相关开发语言的常见安全性问题检查，例如 SQL 注入等。4 如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持 
⑦ 兼容性测试，根据需求说明的内容，确定支持的平台组合：浏览器的兼容性；操作系统的兼容性；软件平台的兼容性；数据库的兼容性 
开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。定期评审，对测试进行评估和总结，调整测试的内容。 
3. 在搜索引擎中输入汉字就可以解析 到对应的域名，请问如何用 rLoadRunner 进行测试。 
建立测试计划，确定测试标准和测试范围 
设计典型场景的测试用例，覆盖常用业务流程和不常用的业务流程等
录制测试脚本 
新建一个脚本（Web/HTML 协议）,点击录制按钮，在弹出的对话框的 URL 中输入”about:blank”。在打开的浏览器中进行正常操作流程后，结束录制。调试脚本并保存。可能要注意到字符集的关联。 
设置测试场景 
针对性能设置测试场景，主要判断在正常情况下，系统的平均事务响应时间是否达标; 针对压力负载设置测试场景，主要判断在长时间处于满负荷或者超出系统承载能力的条件下，系统是否会崩溃。 
执行测试，获取测试结果，分析测试结果
300 个用户在一个客户端上，会占用客户机更多的资源，而影响测试的结果。 
线程之间可能发生干扰，而产生一些异常。 
300 个用户在一个客户端上，需要更大的带宽。 
IP 地址的问题，可能需要使用 IP Spoof 来绕过服务器对于单一 IP 地址最大连接数的限制。 
所有用户在一个客户端上，不必考虑分布式管理的问题；而用户分布在不同的客户端上，需要考虑使用控制器来整体调配不同客户机上的用户。同时，还需要给予相应的权限配置和防火墙设置。
软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、文档的完整集合。 
软件复用(Software Reuse)是将已有软件的各种有关知识用于建立新的软件,以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码级复用，被复用的知识专指程序，后来扩大到包括领域知识、开发经验、设计决定、 
体系结构、需求、设计、代码和文档等一切有关方面。 
可以被复用的软件成分一般称作可复用构件
软件生存周期是软件开发全部过程、活动和任务的结构框架，是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程。在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为”生命周期模型”（Life Cycle Model）。
1 工作内容：
3 发展前景
成长路径：
4.入门门槛
5.哪些行业适合做运维
6.职业限制

首先，将问题提交到缺陷管理库里面进行备案。然后，要获取判断的依据和标准： 

① 首先，查找需求说明、网站设计 m 等相关文档，分析测试需求。 

4. 根据测试用例，开发自动测试脚本和场景： 

5. 问：一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压，有什么区别? ? 

6. 试述软件的概念和特点？软件复用的含义？构件包括哪些？ 

7. 软件生存周期及其模型是什么？ 

明天计划的 事：

请假

遇到的问题：

无

收获：

看了一波老大写关于QA的文章

“QA最好的出路就是产品经理”。

这是我对QA最好的认知。我知道这里有无数反对的声音，我说的每一句话大概都会有认同和不认同的人，所以如果看到这句话不喜欢，就表再继续看了。

QA的这个职位，大致分成两个流派，一个是功能测试，一个是性能测试。

功能测试就是指的是各种点点点点。然后看看功能和数据有没有问题。什么浏览器，什么版本，什么情况，能否复现。

性能测试就是指：用Jemter，LoadRunner等做压测，测跨后端人员的信心。

基本上就是这两种，很少有专门针对安全的层次去做测试的。那么问题就来了，工程师和QA之间，倒底谁该做功能测试，谁该做性能测试？

我姐告诉我说：

工程师才应该做性能测试，因为只有他们才最应该知道自己开发的系统性能瓶颈在什么地方。

然后也是因为这句话，我举一反三的瞬间懂了什么才是一个工程师，并且在不断的践行者这个理念：

如果你是一个后端工程师，你必须对服务器的线上数据了如指掌：

有多少张表，在哪台机器上，分了几个库，一个表里有多少条数据，数据的分布是什么样的，起了多少台Service，占用多大的内存

高峰期的TPS有多少，CPU的负载怎么样，页面总响应速度有多少，一个请求调用了几个方法，每个方法执行时间是多少

是否加载了缓存，从缓存里加载的数据是多少个，大概多少MS，访问一个数据库需要多久。

你做不到这一点，你就没办法做好性能优化。所以，QA很难做到这些，也完全没有必要做到这些-实际上我们的团队是没有QA的。工程师负责所有的问题。

前端也是一样的，做了一个App，耗电量，带宽，内存，兼容性，都是前端应该关心的问题。

所以我在这里给出的一个明确答案就是：性能测试，开发人员做，功能测试，QA做。

但是这里的功能测试，并不是指的是普通的功能测试。

实际上，开发人员应该自测一百遍再提交到测试环境（我在讲到敏捷开发的话，会再次提到整个开发流程是怎么样的，以我在几家公司实施的经验来看，这套敏捷开发流程，对于很多公司梳理内部结构都会有帮助。）

QA做的应该是自动化的回归测试，边界条件测试，极限条件测试等种种很难测试得到的问题。对了，再解释一下为什么要有QA，以及为什么Bug总是测不完。

因为在我根本记不清的一篇文章里说到，哪怕是最简单的几个功能组合，想无穷穷举测完都很困难--马丹，原话我记不住了。

所以这就是给无数擅长性能测试的QA判了死刑，你之所以能做性能测试，是因为你们的开发模式和流程不对--别看我，我就是喜欢这么说，一点都不委婉。爱听听，不听拉倒。

但是QA真的不是一个很简单的活儿，可以这么说吧。QA几乎是所有职业中，最熟悉系统的人-甚至包括设计它出来，开发它出来的产品经理和各种工程师！

很多时候QA做的事情都是非常单调的，但是又必须有责任心的，拿我之前的话说，QA就是最后一道关口。

所以，如果你想成为一个PM，你可以考虑先做QA，当然，前提是你必须遇到一个愿意给你机会做产品的好老大-比如说我。

So，接下来就开始来闲扯一下QA了。

QA需要了解需求，很多公司会要求QA写测试用例，我觉得是扯淡。完全是在浪费时间。通常开发三周，QA测试的时间只有一周到一周半。还有关于提前写测试用例的，都不靠谱。

但是总之，了解需求，就算是不写也要自己知道自己测，这是QA的必备职责。

跟着就是等开发人员开发，这个时候也会有一些奇葩公司，要求QA提前界入的，理由是加快上线周期。

之前还有说过完成一个Story就要测试完整的，我也不想吐槽了。总之，如果你真的遇到了这样的公司，你的工作就是测试，然后跟开发人员说不对。

然后开发人员说改好了，然后再测。然后你大喊一声，好毛线啊。然后开发人员说，稍等，我先梳个头。然后再告诉你好了。

然后你再说，好毛线啊。然后开发人说。。。这次真的好了，于是你测了一下，真的好了，开发人员很Nice的说：完美！

你也很开心，但是没过几秒钟，你就会喊：什么鬼，之前的功能是好的，为什么又改回去了？

如果你呢。遇到好点的流程。会在上QA之前，打版本（我始终无法理解不打版本是什么流程），会Demo，那么你可以有一个安心的测试环境了。

这个时候稍微正常点的工作，就是测试，然后把Bug录入到Jira，禅道，或者Bugzilla等各种专用的Bug管理工具。

跟着就是追踪bug(如果你们公司有Bug处理流程的话)，如果有晨会就在晨会上说明，如果有周会，就在周会上统计。

大部分的QA都比较羞涩，并不太敢提Bug，并不太敢说哪个程序员的代码写的有问题。

毕竟，这是唯一一个必须要当面揭短的职业，哈哈哈哈。

基本上到这里QA的任务就没了。等着发布上线就好了。实际情况上发布上线的时候QA要等着程序员改代码，验证。。。

2 需要技能：

流程【Bug修复流程，版本发布流程】

工具【禅道，BugZilla，Jira,Excel表格来统计Bug数，自动化测试】

性格【严谨，耐心】

QA里经常会嘲笑自己是技术Team里最没技术的一个。

如果说你是一个标准的QA的话，真的不用去特地研究一些压测工具的。

不过也确实可以了解一下，Jmeter怎么用，TPS是什么概念，90%线是什么意思，PostGet什么的。

自动化测试工具是我一直都强烈推荐的，无论是神马办法，只要你能做到哪怕只有一部分自动化的测试，你做回归测试就很容易了。相信我，回归测试在每一个版本发布都是需要的。只不过有的时候，只是需要跑一下脚本就好了。有问题再详细测一下。

严谨和耐性是非常非常难得的，也是QA最重要的能力。当然也包括需求的理解能力啦。

QA的发展前景。。真的不算好，跟网管一样，如果说并不能转产品的话，20K基本上就封顶了，就算是有公司，愿意出30K让你们做性能测试，也是到天花板了。

1年~2年：4K~15K

2年以上：12K~20K

测试工程师-测试组Leader-PM

如果能转到PM，真的就很赞了，我推荐的时间应该是在半年到一年左右就开始转。

QA并没有什么门槛，一般来说，是妹子比较多。

汉子比较少，是汉子的，也多数是做点性能测试相关的。但是请相信我，这绝对不是一个好的天赋加点方式，就算是性能测试做的再6又怎么样？

所以稍微懂一点Bug修复流程就好啦。勇敢的去做QA吧。。。

IT界：all其他界：all

虽然是IT界的All都可以转QA，但是说实话，我没有看到过一个从其他职业转到QA的。。也许除了运维。。

职业限制也说过啦。总有重复的使用技能的厌倦感，毕竟这些技术水平都不需要太多。理解能力好一些，严谨一些就能做。

说的直接点，从事五年的QA和从事一年的QA，本质上并没有什么差别啊。但是好处就是，如果你有心，你会对系统特别特别的了解，这对于你转行做PM，是一个非常非常大的优势。再强调一遍，并不推荐QA转走技术路线。