2.14情人节，你还在纠结送TA什么礼物么？
你还苦于不敢表白么？
在微信里勇敢说出你的爱
51Testing帮你给TA特别的惊喜！
Ps.用这个做借口表个白也不错哦！

本期51官方微信特别选出三种精美的礼品供大家选择。选择同一个礼品的会员中，最有特色/最感人的表白将被小编选中， 你或你心仪的TA，就会收到这个礼物哦！

活动时间：2月10日(中午12:00)-2月12日

活动流程：
1) 微信扫描下方二维码或搜索“51Testing软件测试网”，关注51Testing软件测试网官方微信（微信回复关键词【活动】，即可参与）
2) 在活动期内，将官方微信发布的"情人节活动"分享到朋友圈，并填写：
　　你想要51送出的哪个礼物+对喜欢的人想说的话
3) 截图发送给51Testing软件测试网微信公众号, 信息提交成功，即可有机会获得你心仪的礼物！
 

奖品：
1）苹果造型加湿器（共1个）
2）创意鹿角水杯（共2个）
3）Mokyo珍藏版摇头公仔1对（共2对）
参与奖：参与活动的会员，也有机会获得羊年精美台历一本！（共5本）

　　将统计学_6 sigma应用到测试技术中，需要使用的6 sigma工具如下：QFD，DFMEA ，量测系统检验，Johnson Transformation
　　一、前言：
　　测试女巫又来啦，大家还记的吗？前两次我们主要以"找到bug产生的原因"以及"提高bug产出效率"为例介绍DOE，柏拉图，主效应，交互作用，相关性，鱼骨图，Xbar Chart，One Way ANOVA，Two Way ANOVA这些方法，并着重介绍如何将这些方法应用到我们软件测试中。
　　那这次我们介绍什么呢？大家还记得第三十二期和第三十三期妞妞发表的两篇文章吗？"嵌入式产品自动化测试"和"路由器自动化测试"，对的在我们的测试中引进自动化测试是可以提高工作效率，因为很多机械的工作可以交给自动化工具完成，测试工程师可以做更有价值的工作……听起来非常美好啊~~但是，真的只要引进自动化就可以把大幅度提高工作效率吗？在我们引进自动化测试工具引进我们工作中这两年的时间，我们就发现现实的执行阶段并不是这样美好的~
　　OK，我们来列举几件：
　　1. 你的团队选哪些原本执行手动测试的工程师来开发自动化测试工具，是不是存在有的工程师花了很长时间开发的脚本，却因为开发脚本品质问题，需要重新返工，耗时耗人力，反而最终测试的效率反而不如直接执行手动测试？
　　2. 待测物所有的功能或者所有的测项都适合开发自动化脚本吗?是不是存在因为功能太复杂，开发以及维护所花费的人力以及精力大大超过你的预期？
　　3. 所有的软件版本都适合自动化脚本测试吗？是不是一拿到软件版本我们就可以启动我们的自动化脚本测试了，是不是不同品质的软件，都可以执行自动化测试？
　　我们在实际执行自动化测试时，是遇到很多困难，但是请不要轻易说：自动化测试只是"看上去很美"，我们不是有另一个"尚方宝剑"：6 sigma吗，能不能使用6 sigma的理论以及方法来分析我们自动化测试，找出自动化测试在开发阶段和执行阶段影响工作效率的因子，并找出高效引进自动化测试的方法？
　　好的，既然有想法就要立刻开始着手去做！这次我们主要用到的工具为：QFD，DFMEA，量测系统，Johnson Transformation。在第三十四期的杂志中已经介绍了柏拉图，主效应图，交互作用图的原理和用法，此份文档中也会用到这些工具，因为之前已经介绍过了，这里就不再赘述。
　　二、6 sigma常用工具基础知识介绍
　　1、QFD
　　它的全称是：Quality Function Deployment（质量功能展开）
　　它的作用是把顾客对产品的需求进行多层次的分析，转化为产品的设计要求、零部件特性、生产要求的质量工具，用来指导产品的健壮设计和质量保证。它主要是用在概念设计阶段，但是在优化设计和验证阶段也可以发挥辅助作用。
　　它主要功效如下：
　　1) 从顾客的角度对市场上同类产品进行评估
　　2) 从技术的角度对市场上同类产品进行评估
　　3) 确定顾客需求和技术需求的关系及相关程序
　　4) 分析并确定各技术需求相互之间制约关系
　　5) 确定各技术需求的目标值
　   ... ...
　   查看本期杂志更多精彩内容，请点击下载：http://www.51testing.com/html/98/n-1298298.html

　　随着敏捷开发的迅速推广与普及，敏捷软件开发是否还需要测试工程师的问题被越来越多的人提及，业界对此也持有两种截然不同的观点。
　　本人觉得：随着敏捷开发的进一步推广，从未来趋势的来看，测试人员的作用与地位正在被边缘化，甚至在将来测试人员可能会像恐龙一样从地球上消失。
　　(先别喷，看完下文再说哈^_^)
　　我们先来看测试人员与开发人员比例问题。
　　微软公司的测试人员与开发人员比例一般为1:1，谷歌公司的测试人员与开发人员比例则为1:10。
　　为什么两家公司的差异如此巨大呢。最主要的原因是两家公司对测试人员与开发人员工作范围的定义不同。在微软，单元测试由测试人员做(SDET)，相当于SDET再写一套代码来测试开发人员写的产品代码，其工作量不比开发人员低。而Google的单元测试和功能测试一般都是由开发人员自己来完成，测试人员主要提供自动化测试工具的支持，主要进行性能测试、负载测试、安全性测试等，而这些都是自动化工具来完成的，自然需要较少的测试人员。
　　再来看软件测试的发展历程
　　软件测试的先驱Bill Hetzel博士（代表论著《The Complete Guide to Software Testing》）给软件测试一个这样的定义：“评价一个程序和系统的特性或能力，并确定它是否达到预期的结果。软件测试就是以此为目的的任何行为。”他的核心观点是：测试方法是试图验证软件的功能是按照预先的设计执行的，以正向思维，针对软件系统的所有功能点，逐个验证其正确性。软件测试业界把这种方法看作是的软件测试的第一类方法（测试是验证软件是可以工作的）。
　　后来这一方法受到Glenford J. Myers（代表论著《The Art of Software Testing》）的质疑和挑战。Myers认为测试不应该着眼于验证软件是工作的，相反应该首先认定软件是有错误的，然后用逆向思维去发现尽可能多的错误。他还从人的心理学的角度论证，如果将 “验证软件是工作的”作为测试的目的，非常不利于测试人员发现软件的错误。于是他于1979年提出了他对软件测试的定义：“测试是为发现错误而执行的一个程序或者系统的过程。”的定义。Myers认为，一个成功的测试必须是发现Bug的测试，不然就没有价值，还给出了与测试相关的三个重要观点，那就是：
　　测试是为了证明程序有错，而不是证明程序无错误；
　　一个好的测试用例是在于它能发现至今未发现的错误；
　　一个成功的测试是发现了至今未发现的错误的测试；
　　这就是软件测试的第二类方法（测试是验证软件是有错误的）。
　　Myers提出的“测试的目的是证伪”这一概念，推翻了过去“为表明软件正确而进行测试”的错误认识，为软件测试的发展指出了方向，软件测试的理论、方法在之后得到了长足的发展。
......

转自：http://www.51testing.com/html/61/n-875961.html

"授人以鱼，不如授之以渔" 说的是传授给人知识，不如传授给人学习知识的方法。今天我想针对于此从思维层面再做一个升华："授之以渔，则先令人悟之"。
　　做好软件测试，首先具备的修养是需要弄明白三个问题。这就是上面讲到要的"悟"。假如开发人员修改提交了BUG，我们使用"三问"的思想进行测试，对于测试人员了解需求会起到很大的帮助。
　　何以悟"三问"。您一定会问："哪三问？"
　　举个例子，咱们来设计一个场景：想象一下，您走在马路上，迎面走来一个陌生人二话没说扇了你一巴掌。
　　这时出于理性思考您会想到什么。"我无意中得罪他了？"、"这人是不是精神上有问题？"、"他认错人了？"等等。无论您想到什么，终究归结到一个问题，那就是"打我的原因是什么"。
　　第一问："原因是什么"
　　开发人员提交被修复的缺陷，测试人员在展开测试工作之前需要弄明白的第一个问题"此缺陷的原因是什么"。以便于针对问题的原因进行测试分析、测试计划、开展测试工作。事物之间的联系是多样的，在软件测试的思维中引入"先行后续"、"引起与被引起"的关系，加之唯物辩证方法论。可以令我们更为透彻的理解基于此缺陷提出的原因，从而进一步深入的理解业务层面的需求。
　　通过沟通、分析弄明白了：走在街上被扇耳光是因为长得太丑。有人会有疑问："虽说长得太丑，也不能扇耳光吧。为什么要扇耳光呢"。这就是我们要弄明白的第二个问题"缺陷为什么要这样做"
　　第二问：根源--"为何要这样修复"
　　缺陷被修复的方案可以有多个，基于业务、技术实现、设计风险等等角度考虑是开发人员否选择了最优方案。了解"为何要这样修复"有助与我们设计测试案例，并综合衡量测试的风险，便于使问题暴露，增大对相应风险系数较大的测试点进行关注度。
　　亚里士多德说过,一切存在物都由本源构成，一切存在物最初都从其中产生，最后又复归为它。弄明白"为何要这样做"能使我们在进行软件测试工作的时候最大限度的追溯其本源，制定测试计划。使缺陷更大程度的暴露。
　　弄明白"扇耳光原因是丑的无可救药了"。不过话说回来，你可以用语言来感化我，为什么要打我呢，为何不用语言来感化我、为何不去打别人呢。
　　从软件测试的角度，我们要弄明白的第三个问题"为什么不这样做"
　　第三问：启发--"为何不那样做"
　　作为一个专业的软件测试人员，只了解问题的原因、以及根源为何要这样修复是不够的。从思维发散的角度来想，需要我们更进一步的考虑"another way"。这一点很重要。这个缺陷的修复为何用PLAN A，为何不用PLAN B？除了PLAN B外，还有没有PLAN C？弄明白这些问题，便于我们更清楚的熟悉业务、理解系统、提升测试技能、设计测试案例。这些需求背后的需求是诸多软件测试人员成长的瓶颈。
　　鄙人不才，望"三问"作为软件测试的方法论能使大家修测试之心，悟测试之性。工作之余多沟通交流，一起成长进步。
      ……

　　查看本期杂志更多精彩内容，请点击下载：http://www.51testing.com/html/98/n-1298298.html

　　一般而言我们都会使用Excel来统计测试结果，除了Excel之外，还有SAS等软件，也是可以统计测试结果的，本人也是SAS的初学者，现在我就给大家介绍一下SAS的简单使用，随着我不断的学习统计学的知识，我也希望今后能更深入的探究这些统计学软件的功能，并将这些功能和测试相关联。
　　第一部分：SAS软件的基本使用
　　1： 打开SAS 软件。

　　2：在"Program Editor"输入框中输入如下代码( 初始时间是2010年2月1日00:00:00，每一秒钟取一个数据点，有两行统计数据，并以两种不同的形式显示出来，一种是直线，一种是曲线。)

     ......

查看全文请点击下载：http://www.51testing.com/html/98/n-1298298.html

　　1.  保证自动化测试成功的三块基石
　　保证软件项目的自动化测试工作成功，如果有三个方面能够做好，那么项目成功即自动化测试成功指日可待。那么，它们是什么呢？它们分别是数据、自动化，以及工具。在此我们分别来讨论一下它们。
　　数据：对于验证日益复杂的软件功能来讲，测试数据的有效性是极其重要的，并且如果测试数据是能够重复的，那么才能够保证自动化测试的效率。所以对于数据来讲，我们要求它是能够被定制的，能够恢复的并且可以重复使用的。如果上述这些内容能够是自动的，那么数据部分就应该准备的比较充分了。通常情况下，我们的手工测试数据与自动化测试数据是混杂在一起的，通常情况下会互相受影响。特别是当你的软件项目有许多个release的时候，你每次为之前的项目跟自动化测试脚本的时候你就会发现数据几乎不能使用了，我们差不多需要为每个脚本重复制作数据，这其中的成本是很大的，而且自动化测试有效率的特性也无法显现。当然对于这种情况有多种不同的解决方案，我的建议是自动化测试部分的数据是能够独立存在的。当然你得保证它的有效性，这里不做具体的讨论，大家可以尝试多思考交流解决。
　　自动化：关于自动化，我们主要是讲自动化测试，也就是说，我们的用户需求，能够被转化为自动化测试脚本，这些自动化测试脚本能够对软件进行测试，从而保证软件功能变便以及重构后，其功能及业务流程未被破坏。对于自动化测试来讲，我们希望是能够有较高的自动化测试覆盖率，从而获得大量时间成本。同时我们也希望较少的脚本的维护。所以针对于自动化测试脚本来讲，我们更应该从软件开发的角度去考虑，构建以及维护它。而不应该简单将手工测试用例转化为自动化测试。如果只是将手工测试用例转为自动化测试用例，我们将会花费大量的时间在维护测试脚本，测试对象库等等方面。当然，我们这里提到自动化，我们也指软件工程的其它方面也被自动化，不只限于自动化测试。如果我们的整个工程大部分或绝大部分是能够自动化的，那么我们的生产力就会得到提升。例如：如果我们能够有自动化测试脚本，那么我们的自动化测试执行也应该是被自动调用的，并且最终的测试结果以及度量结果都应该是可以被自动获取的。简单来说，一切都应该被自动化。
　　......
　　2.   自动化测试生产力
　　最近，被同事问到一个有趣的问题，就是自动化测试生产力。我们的自动化测试生产能力是多少，如何知道我们每年的自动化测试生产力是提升了，还是下降了。针对此总题，我觉得这其实是对要求我们能够有数据指标来衡量一个企业或团队的自动化测试能力。关于这个指标如何定义，我相信各个企业一定有自己的标准。但我想数据的获取应该是类似的，也就是说，那些参与运算的数据应该是差不太多的。在提及这些数据之前我想说一下关于手工测试能力的考察方法，通常大家会把每年写了多少测试用例，执行了多少测试，通过了多少，也有无效的defect有多少等等这些数据考虑进去。对于自动化来讲，我们也会考虑相关数据，如我们的自动化测试覆盖率，我们的脚本被运行的多少次，pass多少次，我们节省了多少时间，我的脚本维护成本是多少等等，有了这些基础数据，我们就可以定制企业自己的自动化测试生产力模型，完成对自己企业或是团队的自动化测试能力的衡量工作。
　　3.   自动化测试框架
　　关于自动化测试框架，这其实是一个非常有意思的现象。为什么这么说呢，因为我们会发现，大多数自动化测试团队都会实现一个自动化测试框架，然后做为标准或规范在团队内推广。而且一但有了自动化测试框架后，我们就会发现，我们的自动化测试脚本开发效率提高了，而且了也规范了许多。这是一件好事，但在这里我想说的事，不要过度框架化，自动化测试的框架还是要尽可能的遵循复用的原则。千万不要搞我之前曾经实现过的类似的关键字框架，我认为目前所有的所谓的关键字测试框架都是效率极其低下的，维护成本是极其高昂的。
　　......
　　查看全文请点击下载：http://www.51testing.com/html/98/n-1298298.html
　　本文收录于《51测试天地》电子杂志第三十六期。
　　版权声明：本文出自51Testing软件测试网电子杂志——《51测试天地》第三十六期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。

　　Web性能测试的部分概况一般来说，一个Web请求的处理包括以下步骤：
　　（1）客户发送请求
　　（2）web server接受到请求，进行处理；
　　（3）web server向DB获取数据；
　　（4）webserver生成用户的object(页面)，返回给用户。给客户发送请求开始到最后一个字节的时间称为响应时间（第三步不包括在每次请求处理中）。
　　1.事务（Transaction）
　　在web性能测试中，一个事务表示一个“从用户发送请求->web server接受到请求，进行处理-> web server向DB获取数据->生成用户的object(页面)，返回给用户”的过程，一般的响应时间都是针对事务而言的。
　　2.请求响应时间
　　请求响应时间指的是从客户端发起的一个请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间，在某些工具中，响应通常会称为“TTLB”，即"time to last byte"，意思是从发起一个请求开始，到客户端接收到最后一个字节的响应所耗费的时间，响应时间的单位一般为“秒”或者“毫秒”。一个公式可以表示：响应时间＝网络响应时间+应用程序响应时间。标准可参考国外的3/5/10原则：
　　（1）在3秒钟之内，页面给予用户响应并有所显示，可认为是“很不错的”；
　　（2）在3~5秒钟内，页面给予用户响应并有所显示，可认为是“好的”；
　　（3）在5~10秒钟内，页面给予用户响应并有所显示，可认为是“勉强接受的”；
　　（4）超过10秒就让人有点不耐烦了，用户很可能不会继续等待下去；
　　3、事务响应时间
　　事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间是直接衡量系统性能的参数.
　　4.并发用户数
　　并发一般分为2种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即所有用户进行完全一样的操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。
　　另外一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。
　　可以看出，后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况，因此对于大多数的系统，只有数量很少的用户进行“严格意义上的并发”。对于WEB性能测试而言，这2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中，尽管发生的概率不是很大，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来，因为并发功能遇到异常通常都是程序问题，这种测试也是健壮性和稳定性测试的一部分。
　　用户并发数量：关于用户并发的数量，有2种常见的错误观点。 一种错误观点是把并发用户数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把在线用户数量理解为并发用户数量。实际上在线用户也不一定会和其他用户发生并发，例如正在浏览网页的用户，对服务器没有任何影响，但是，在线用户数量是计算并发用户数量的主要依据之一。
　　5.吞吐量
　　指的是在一次性能测试过程中网络上传输的数据量的总和.吞吐量/传输时间,就是吞吐率.
　　6、TPS（transactionper second）
　　每秒钟系统能够处理的交易或者事务的数量.它是衡量系统处理能力的重要指标.
　　7、点击率
　　每秒钟用户向WEB服务器提交的HTTP请求数.这个指标是WEB应用特有的一个指标:WEB应用是"请求-响应"模式,用户发出一次申请,服务器就要处理一次,所以点击是WEB应用能够处理的交易的最小单位.如果把每次点击定义为一个交易,点击率和TPS就是一个概念.容易看出,点击率越大,对服务器的压力越大.点击率只是一个性能参考指标,重要的是分析点击时产生的影响。需要注意的是,这里的点击并非指鼠标的一次单击操作,因为在一次单击操作中,客户端可能向服务器发出多个HTTP请求.
......
本文转自：http://www.51testing.com/html/27/n-1276427.html

　　测试用例的编写是测试流程中不可缺少也极其重要的一环，但我们在编写用例时是根据实际项目还是根据需求文档作为标准呢？

　　在有一定规模的公司里，测试用例设计完成之后和开始实施测试之前必然有一项工作，即测试用例的评审。项目总监、项目的开发人员、产品人员以及视觉交互人员等所有的项目的相关人员坐在一起，由测试人员发起，共同进行测试用例的评审，而评审的最佳时间点就是在项目已经启动，完成了部分的编码工作，这时在测试人员对照需求文档写出的测试用例的基础上，项目组成员进一步针对项目需求细节进行核对，若出现理解不一致的地方，可以当即讨论，达成一致。因为此时项目还在开发中，如果分歧点在还没有开发的功能上自然是最好；即使是已经开发完成的功能上，此时修改的成本也大大低于开发完成之后，因此以需求文档问标准进行测试用例的设计和梳理是对需求的再一次过滤，评审过程中是对需求争议点的一次清理，这样能够大大提高需求的准确性，减少不必要的开发成本。

“我想变成一棵树，一棵只为你存在的圣诞树，顶上最大最亮的那颗星是我的真心，下面挂满
我对你的祝福。你的关注是我的幸福，你的肯定是我的力量，而我将用更多精彩的内容，用
心的分享，给你下一个一整年的精彩！”
                                                                                                      ——51Testing软件测试网

圣诞、元旦双节到，为回报小伙伴一直以来的关注与支持，51Testing邀小伙伴狂欢2星期！！
经过多日的准备，51Testing线上活动隆重登场，找宝箱、答问题、发文章，学习娱乐两不误！
奖品丰富，只等你参与！

双旦狂欢，千万别错过了！赶快参加吧！