一， 完全的功能测试人员正在退出舞台

从测试这个行业被大家认可时起，有不少有志之士投入于测试行业。不论是通过自己学习，积极转行，还是通过社会上各种培训机构来转行，最终的结果就是大量的测试人员进入到互联网相关的各个行业。当时的情况确实一片大好，进入这个行业后薪资待遇普通提高了不少。可是经过这几年的发展，社会对测试人员要求越来越高：不管你工作了几年，如果你仅仅只会功能测试，测试工具的使用或是再高级一点儿，在公司现在的平台或框架下写自动化测试用例的话，几乎不能通过一面面试。功能测试目前是校招生，刚刚工作的人的舞台，那些在社会上工作了几年的测试人员，从工资待遇，企业期望等方面来考虑都要求你退出舞台了。

二， 技术要求越来越精深

在测试技术方面，现在要求越来越精深了。先前的测试开发人员，能搭建自动化测试工程，持续化集成框架，使用开源的框架解决工作中遇到的问题等技能就相当不错了，而且能找到比较满意的工作。而目前很多企业面试的时候，如果招的是高级测试开发，资深测试开发的话，要求不仅仅是常用的测试框架的使用，开发相关的框架如Spring，开发技术多线程，分步式，其他如mysql, mongodb, redis也要会使用。越来越接近于开发的要求，有的甚至要求更高，一个岗位多种技能，全栈式解决问题。

三， 注重解决问题的方案而不是细节

在要求测试开发人员技术更加精深的同时，对于高级别的测试开发人员更要求解决问题的方案，考虑问题的眼界。如一个测试流程就需要考虑以下问题：（1）需求测试阶段 （2）开发技术评审 （3）测试用例设计 （4）测试方案选择与测试验收 （5）项目流程控制 （6）项目问题总结与分析。而不是以往的一轮测试，二轮测试，bug验证，上线及回归测试等流程了。在测试一个需求的时候，如测试一个新的App，就需要从这几方面考虑：（1）app的功能与交互 （2）app的性能，兼容性相关（3）app UI自动化 （4）接口或是服务的自动化，安全性与监控等 （5）底层数据mysql,redis等验证与监控。从这些问题出发，我们需要不断培养自己解决问题的方法，开阔眼界，而这又不是一朝一夕就能提高的。

四，工作经验注重切合实际的项目

在我们的求职简历中肯定会写不少项目，在以往的培训机构出来或是在工作中没有真实参与项目的时候，也会虚拟不少项目经验。而现在招聘过程中，大家更加注重真实有效的项目，像物流管理系统，学生管理系统，简单的自动化测试项目都已经过时了。因为他们会让你解释项目流程，代码架构，设计目的和使用效果，如果你的项目经验过时，或是虚构出来的项目，肯定过不了关的。建议还是学习与社会结合度高的技术，踏踏实实地做项目，积累真实有效的项目经验才是王道。

针对上面的这些现状，我们需要做的最重要的事情就是不断地提升自己的能力。但是也不能盲目，要有目的和针对情况，否则会事倍功半。

一， 了解测试行业的技术走向

测试行业如同时尚界，主题元素就那么多，可是每天有不同的流行风格。主题包括功能测试，自动化测试，性能测试，安全测试，持续化集成，测试平台的开发；技术则包括语言类java,python,shell,ruby,go等等，框架类webdriver,appium,testNG以及其他流行度不高，或是二次封装等等。以我个人了解，12-14年比较流行自动化测试,接口自动化测试，Web UI自动化测试以及后来手机app的自动化测试；15-17年比较流程各种测试平台的开发，整合各个流程中的资源形成一个个测试体系；17年下半年到现在，由于docker技术的成熟，持续化集成，持续交付，Devops开始流程了起来，并逐渐出现测试由响应转变成支持的角色，通过提供测试服务，方案，工具等支持开发和产品进行自测的趋势。

二， 以市场需求为导向，针对性地学习

我们提升技术除了为单纯的追求新技术的个人兴趣，大部分还是为了涨工资，争取更多的机会。所以就不能盲目，一方面要了解业界技术走向，另一方面要有方法。目前通过参加培训班来提升自己的人比较多，那在选择培训班的时候就要多关注一下他们的课程，有没有与新技术相结合？有没有实用的项目供实训？如果内容过时，项目简单，还是不要花费那个时间和金钱了。还有就是自己主动学习，多关注一下开源社区，我们测试在使用技术的时候一定要注重时效性，投入产出比等，使用开源代码是首要选择。还要了解新技术，可能新技术目前用不到，但是社会发展总是向前的，不及时更新自己的知识体系，会在不知不觉中落伍。

三， 准确定位，步步为营

在了解了外面行业发展，技术走向的前提下，还要好好地审视一下自己。目前我都会哪些与业界需求相关的技术？哪些是我的弱项？以我现在的水平，在各大公司能定个什么级别？如果我要提升，需要补充什么能力？考虑好这些问题才是你行动的方面。就测试行业而言，大概发展路如下，仅供参考：

（1） 功能测试（1到2年）：学习基本的测试流程，掌握相关的测试工具的使用，问题定位方法，项目跟进的策略。

（2） 自动化测试与测试开发（1到2年）：借助于语言来解决遇到的问题，会使用开源的框架搭建接口，UI自动化测试工程，能使用Jenkins做持续化集成。

（3） 高级测试开发（时间不定）：会开发测试平台，能系统地解决问题或是具有自己独特的解决问题的思路。此时有广度和深度两个方向，广度就要系统地考虑和解决问题，全面了解测试相关的技术与方案，能快速地把新的技术落实到实处；深度就是有自己专项的必杀技能，可以帮助开发优化代码，提高效率等等。高级测试开发水比较深，工作年限也不定。

（4） 资深测试开发或是测试架构师（时间不定）：全面解决测试遇到的问题，时刻关注新技术；从团队建设，技术方案设计，整个公司的发展，同行业的发展等方面或是角度来考虑问题。目前好像也没有太清晰的界定，不同的公司定义这个级别的标准也不一样的。

以上是我最近面试过程中遇到的一些问题及总结，现在归纳一下用以指导我的后续工作及技术的学习。不管什么情况下，都不能闭门造车，关注新技术，新方案，不停地给自己加油，提升自己相应的能力，与时代同步，才能在工作中偶尔任性一把！

如果有任何疑问，欢迎添加qq群测试入门到大神 755431660 共同学习~

1、什么是测试用例

一组由前提条件、输入、执行条件、预期结果等组成，以完成对某个特定需求或者目标测试的数据，体现测试方案、方法、技术和策略的文档

　2、为什么要写测试用例

科学有效的对测试步骤进行组织规划，方便管理，记录

3、测试用例主要包含哪些内容

编号、日期、设计和测试人员、优先级、标题、目标、环境、输入数据/动作、预期结果

公众号也有测试用例的模板，大家也是可以回复关键词自行获取的 

　4、编写测试用例需要什么

软件需求设计说明书、软件模板

　5、设计测试用例的注意事项

从高到低，独立性，与功能一一对应，根据需求设计，由有经验的人员设计

6、设计测试用例的原则

有模板，正确性，代表性，可判断性，重现性，详细准确清晰的步骤，符合规范

7、用例的管理工具

市场上的用例缺陷管理工具很多：蛰了列举几个：mantis、redmine、jira、bugzilla、禅道等

bug管理工具我记得之前有写过禅道的，大家可以看一看。

8、用例的管理过程

编写→评审（修改→再次评审）→使用→保存管理→维护/升级

今天这篇文章主要是总结，不然很多不知道用例是干什么的，写用例需要什么，这个文章都有介绍了。

如果有任何疑问，欢迎添加qq群测试入门到大神 755431660 共同学习~

2018年4月27日，柯洁（中国顶级职业围棋手，曾多次获得世界冠军）应邀参加福州举办的第一届“吴清源杯”世界女子围棋赛暨“贝瑞基因杯”2018世界人工智能围棋大赛，再次与围棋AI展开人机大战。

这是柯洁第三次与AI棋手对阵，与前面两次不同的是，这次对决的是我国自己研发的AI棋手“星阵”。在棋局进行到大约两小时的时候，柯洁遗憾落败，AI又赢了。我们不禁要问了，为什么柯洁会屡次败给人工智能呢？

这就要从人工智能的“思维方式”谈起了。鉴于这次对弈的“星阵”使用的技术细节还未曾对外透露，并且“星阵”最重要的参考还是AlphaGo，我们这里就以AlphaGo背后的主要机制来给大家做讲解。

事实上，AlphaGo做决策主要依赖于计算机科学家们给它编写的三个函数。它们分别是：策略网络（policy network）、评价网络（value network）和蒙特卡洛树搜索（Monte Carlo tree search）。

策略网络是个13层的卷积神经网络，它可以根据当前的盘面状态来预判对方的可能落子位置。策略网络为什么就可以预判到对方的落子位置呢？这是因为在正式比赛之前，科学家们会对AlphaGo进行“训练”——输入大量的数以千万计的世界职业棋手的棋谱让AlphaGo进行学习，然后通过自我对弈的方式不断增强预测的正确率。

评价网络也是个13层的卷积神经网络，跟策略网络互相独立，它可以根据给定的盘面状态判断出每种落子的最终胜算概率。这个部分的样本通过两台机器对弈的方式产生，这样有效的保证了评价网络经过学习后能够正确的反映出胜算概率。需要指出的是，评价网络的评价机制不是精确的，而是近似值。

蒙特卡洛树搜索的主要作用则在于可以根据当前棋盘状态、策略网络数据和评价网络数据的组合，计算出最佳的落子位置。蒙特卡洛树搜索算法包含四个步骤：

选取：根据目前状态，选取出对方最可能的几种落子位置；

展开：根据选取的对方落子位置，展开至我们最终胜算概率最大的几种落子位置；

评估：评估最佳落子位置。最终选取的落子位置不仅取决于评价网络评估的胜算概率，同时还来自于更深度的蒙特卡洛树搜索；

倒传导：在决定好了我们的最佳落子位置后，再根据这个位置，通过策略网络来评估对手可能的下一步落子位置，通过评价网络来评估落子胜算概率，选取出下一次的最佳落子位置。

由此可见，AlphaGo本质上其实就是通过大量的样本输入和以上这三个函数找到了对弈中的最佳落子位置。隐藏在这个AI超人背后的其实是专门针对于围棋领域的强大的计算机算法。

这个算法汇聚了几千万种棋局的经验，加上计算机做决策完全理性（不会受情绪影响也不会感受到任何压力），不会受任何外界因素干扰，战赢柯洁——一个只有两万多盘棋局经验的年轻人，也算是在情理之中。

而这次人机大战的积极意义则在于它证明了我国人工智能研发进入到了世界先进水平。期望有一天，“星阵”可以有机会跟AlphaGo一较高下。
​如果有任何疑问，欢迎添加qq群测试入门到大神 755431660 共同学习~
​​

早上看到一个测试面试题目：

需求：“世上无难事，庸人自扰之”，如何拆分测试点来设计测试用例（要求列出测试点）

没错，现在测面试官已经不按套路了，大概是以前的杯子啊，椅子啊，都已经用烂了，所以换套路了，不过方法基本不变。

1.对世上测试点做等价类划分

输入世上，期望成功

输入世中，期望失败

输入世下，期望失败

　2.对无测试点做等价类划分

无，期望成功

有，期望失败

　3.难等价类划分

难，期望成功

不难，期望失败

不怎么难，期望失败

4.对庸人测试点做等价类划分

庸人

俗人

僧人

男人

女人

　5.对庸人测试点做边界值测试

刚出生的小孩

快挂掉的老头

　6.对庸人考虑特殊人群

孕妇

狱友

　7.对自扰之做等价类

扰自己

扰别人

　8.对扰的类型测试

噪音干扰

光干扰

性骚扰

自然干扰

　9.对扰动作来源测试

用手扰

用机器扰

10.对扰的程度测试

一级干扰

二级干扰

终极干扰

11.对扰的持久性测试

扰1分钟

扰1天

扰1整年

大概思路是这样，初听到确实有点懵逼，后来发现主要是文字翻译，和我们平时测一个软件是差不多的。

据说，测试的高级境界是：给你一块板砖，你都能写出几百条案例。

只能说，加油吧，路还长着呢

更多关于测试方面的技术，请添加qq群 测试入门到大神 755431660 我们共同进步哦~

一家主要是做一款APP的公司，公司技术部门有三个组：爬虫组、服务端组和APP客户端组。

事实回放：

1）每次运营或产品提出一个BUG给到测试工程师后。

2）测试工程师就会凭感觉和经验（而不是技能判断）判断这个BUG是哪个组，判断之后就会把这个BUG指派给该组的负责同事A。

注意：我们的绩效是按照每个团队每位同事产生的生产BUG去扣分的。

3）接收到这个BUG的开发同事A开始排查问题，花了半小时排查完之后发现这个BUG不是我这边的问题，于是就又丢给测试工程师，同时责备测试不应该把不是他的BUG指派给他，一来浪费他的时间，二来又影响他的绩效。

4）测试根据开发同事A的各种排查描述，得知这个BUG可能（是的，可能）是另一个组的开发同事B的问题，于是测试就把这个BUG指派给开发同事B。

5）接收到这个BUG的开发同事B开始排查问题（每个组的开发排查方式未必相同），顺利的情况下，最后排查得出这个BUG确实是我的。

6）开发同事B开始处理BUG，处理完之后给到测试验收，直到BUG关闭。

流程图如下图1：

图1

在这个过程中，还有隐形的多种问题：

1、验收在接收到测试工程师指派的无法确定是否是需要我处理的这类BUG时，会一直让这个BUG挂机在那不做处理，原因很简单，我花半小时去排查这个BUG，很有可能这个BUG不是我的。

2、开发经常性怼测试工程师，你怎么证明这个BUG就是我的？我就是不处理！还有你为什么总是把不是我的BUG指派给我？而测试工程师的回怼总是无力的“我怎么知道这个BUG是不是你的？”。

3、在互相扯皮的过程中，严重降低了“测试-研发”的合作效率。

　处理方案：

孔子曰“其身正，不令而行；其身不正，虽令不从”，对于测试工程师来说，打铁还需自身硬。提高测试工程师排查BUG的能力势在必行。

当测试工程师拿到一个BUG时，可以通过APP抓包和查找数据库表的方式排查这个问题到底是那个开发工程师的。

举例：在APP上有一张图片无法正常呈现出来，而这个图片是由爬虫工程师采集过来的。

　处理：

1）测试工程师先通过抓包的方式找出这个图片相关的HTTP请求内容，如果这个请求内容里面的图片URL为空，那么这个BUG很可能就是爬虫在采集数据或入库数据时出了问题，找出共性和规则给到爬虫工程师去处理。

2）如果这个图片URL是有值的，并且这个URL可以正常打开，但是这个URL的格式不是OSS的格式（服务端会把外面的图片保存到我们的OSS环境中），那么这个问题就是服务端在保存图片时出了问题，找出共性和规则给到服务端工程师去处理。

3）如果这个图片URL的格式是OSS，并且可以正常打开，但是只是在APP上无法呈现，那么这个问题就是客户端在显示图片时出了问题，找出共性和规则给到客户端工程师去处理。

如果测试工程师可以做到这样的话，BUG提交和处理的流程变成如下图2所示：

图2

当然，在这个过程中，测试工程师一要提高自己排查BUG的准确度，二要提高自己排查BUG过程可以给开发做参考的可用度。

扩展：

“作为一名软件测试工程师，需要具备哪些能力？”需要具备的能力很多，但是我觉得排查BUG能力是最重要，最有效，也是最容易被忽视的一点。

测试工程师的主要职责包括质检和质控，质检的东西大家都说的很多，质控的就比较少啦，我在这里也提一下。

质控一：上游工作质控

在产品刚立项、进行需求确认的时候，测试人员就会参与进去，仔细地Review需求，看需求是不是完整、有没有漏洞，这个时候还没有进入正式开发，修改需求对于项目组来说代价是最少的。在这个环节，测试人员凭借缜密的推演、发散性的思维，往往能发现很多需求的漏洞，提高了项目的整体效率。

另外，测试人员在完成测试计划、测试用例以后，会邀请开发、产品一起评审测试用例，在这个环节，由于测试人员把每个需求如何细化测试都体现在了用例里面，就相当于再次把需求分析了个透，往往还能发现很多需求的漏洞。这也是提早发现需求漏洞的有效环节。

质控二：下游工作质控

在产品完成了测试以后，就是发布的环节了，测试人员在发布的环节也能发挥作用。首先，测试人员为了部署测试环境，研究自动化部署的技术，可以把上线部署的环节也自动化，以前需要2个小时的部署环节压缩到半个小时甚至更少，而且更加准确可靠。

如果有些版本修改比较多，上线的质量风险大，测试人员会跟产品一起制定灰度发布的方案并在技术上进行实现，让版本先面向一小部分用户开放，如果发现Bug了，影响的用户也比较小，Bug改掉以后，再逐渐扩大用户范围。

另外，优秀的测试人员还会发动项目组的其他人一起来保证项目质量，比如推动开发进行代码Review；引入冒烟自测流程，让开发先自测以后再提交给测试做冒烟测试；通过在项目组分析Bug，让开发提高自测，降低Bug数量等；引入策划、交互、视觉在测试阶段进行走查等等各种措施。

请点击此处输入图片描述

可以利用Linux的crontab定时任务来实现这样的需求，具体命令如下：

* 6 * * * find /root/home/zhang/* ctime 1 -exec rm -rf {} \;

表示每天早上六点删除/root/home/zhang目录下一天前创建的所有文件，不删除文件夹zhang，如果这个文件夹也要删除的话用

* 6 * * * find /root/home/zhang ctime 1 -exec rm -rf {} \;

* 6 * * *释义：

第一个*号表示时间中的 分钟 取值范围：0-59

第二个*号表示时间中的 小时 取值范围：0-23

第三个*号表示一个月中的第几天，取值范围：1-31

第四个*号表示一年中的第几个月，取值范围：1-12

第五个*号表示一个星期中的第几天，以星期天开始依次的取值为0～7，0、7都表示星期天

ctime 表示创建时间，1 表示一天前，其实Linux中不存在文件创建时间，只有访问时间（atime）、修改时间（mtime）、状态改动时间（ctime） 。

可以通过命令 stat + 文件路径 查看时间

也可通过命令 touch -t 201212212359 aa （建立文件aa,时间是2012年12月21日23时59分）修改时间

若是删除目录下的指定文件可以用：

find 对应目录 -mtime +天数 -name "文件名" -exec rm -rf {} \;

写好了命令，下面就是启动定时任务了。

首先要创建一个crontab,输入命令crontab -e 进入编辑界面，编写你的定时任务，即上面的命令。

也可以不使用crontab -e命令创建crontab配置文件，其他任何文本编辑器编写命令序列，比如文件名为abc.cron，然后使用命令：crontab abc.cron将命令序列添加到crontab中。

创建好crontab之后，就可以把上面的命令写道 /etc/crontab这个文件中

通过 crontab /etc/crontab 命令启动这个定时任务，可以通过 crontab -l 命令查看当下的定时任务

为保险起见，最好再重启服务，之后查看下crontab的服务状态

命令如下：

查看crontab服务状态：service crond status

/sbin/service crond start //启动服务

/sbin/service crond stop //关闭服务

/sbin/service crond restart //重启服务

/sbin/service crond reload //重新载入配置

基本流程就是这样。

不得不叹服，Linux命令行的强大呀！ Windows 下的回收站功能在Linux下就是这容易就实现了！还多了个智能定时清理“回收站”的功能！嘿嘿，比 Windows 的回收站好用多了！

需求跟踪是一个高阶的管理活动，目标是为了更好地管理需求的状态，更好地分析需求变更产生的影响。虽然执行需求跟踪会带来不错的效益，但其所需付出的工作量也是巨大的。因此在需求定义，需求开发和需求管理还没有非常顺畅时，不太建议引入需求跟踪活动。

1.1 需求跟踪的基本概念

需求跟踪是将单个需求和其他系统元素之间的依赖关系和逻辑联系建立跟踪。这些元素包括：各种类型的需求，业务规则，系统架构，设计组件，源码，测试用例，以及帮助文档等。具体来说需求跟踪涉及5中类型的跟踪链：

通常需求跟踪的收益体现在以下几个方面，都属于比较高阶的管理收益：

》审核：跟踪信息可以帮助审核确保所有需求都被应用。

》变更影响分析：跟踪信息在增删改需求时，可以确保不忽略每个受到影响的系统元素。

》维护：可靠的跟踪信息使得维护时能正确，完整地实施变更，从而提高生产率。

》项目跟踪：认真记录跟踪数据，可以使得计划当前的实现状态。

》再设计：可以列出传统系统中将要替换的功能，记录他们在新系统的需求和软件组件中的位置。

需求跟踪是比较高阶的管理活动，所需的工作量非常大，特别是软件需求到设计元素的跟踪，因此一定要考虑投入与收益是否成正比。

1.1.1 用户需求到软件需求的跟踪

跟踪链第一类是用户需求到软件需求的跟踪，工作量中等，对与项目管理好处很明显，建议有时间尽量实现此类跟踪。

1.1.1.1 目的：保证所有的用户原始需求都得到满足。

1.1.1.2 好处：

》开发人员在实现时能精确地定位到相关的原始需求。

》可以为软件需求是否必要提供第一手证据。

》容易找到需求之间的矛盾和歧义。

1.1.1.2 具体手段：在第六章 需求分析与建模最佳实践中介绍到一种方法，就是将一句话标识的用户原始需求直接归并到软件需求的用例中。

1.1.2 软件需求到软件需求的跟踪

跟踪链中的第二类是软件需求到软件需求的跟踪，这类跟踪工作量规模较小，对于需求管理的好处十分明显，此类跟踪最应该建立。

1.1.2.1 主要内容：

》项目目标，stakeholder关注点到软件需求的跟踪。

》相关软件需求之间的跟踪。

1.1.2.2 目的：确保项目目标，stakeholder关注点被实现。

1.1.2.3 好处：

》更好地理解软件需求的实现意义。

》更好地处理软件需求之间的逻辑相关性。

1.1.2.4 具体手段：为项目目标，stakeholder关注点，创建唯一编号，通过表格或链接法实现跟踪。

1.1.3 软件需求到下游工作产品的跟踪

跟踪链中第三类是软件需求到下游工作产品(系统架构，设计组件，源码，测试用例，帮助文件等)的跟踪。这类跟踪对于变更管理的好处十分明显，但工作量巨大，因此此类跟踪应该谨慎使用。

1.1.3.1 目的：维护软件需求与设计元素，测试元素之间的关联关系。

1.1.3.2 好处：

》在针对变更的技术影响分析时，能够得到更加精确的评估结果。

》可以更好地隔离变更影响。

1.1.3.3 具体手段：手动更新或通过配置管理软件来实现更新。

1.2 需求跟踪的操作方法

要对需求进行跟踪，就必须对每个需求定义唯一标识。在实际操作过程中，主要有表格法和链表法两种跟踪策略。

1.2.1 表格法

在使用需求跟踪矩阵时，只是制定了计划而没做具体工作时还不能填写这些信息，必须完成了工作并且通过验证后才能填入这些信息。

1.2.2 链表法

链表法主要是用于特定软件上，比如需求管理工具Telelogic DOORS。

1.3 小结

每当谈起需求跟踪活动，总是有一句话作为核心：需求开发活动都是必须的，需求管理活动都是可选的。因为任何管理活动都是有成本的，因此我们必须做好成本效益分析，而不是将所有管理活动都做到位了就是最好的。

我们可以根据项目，人员，团队的特点，选择部分意义重大，价值较高的项目做需求跟踪，甚至可以在一个项目内，选择部分需求进行跟踪；另外还应该选择合适的需求管理工具，以降低需求跟踪的工作量。

区块链技术因为比特币的火爆而广受关注，我们这里用 python 代码来聊一下区块链技术：

区块链实现原理的简易描述

区块链技术做为一种数字记账技术，其核心是将保存了交易数据的区块，以加密的方式，按时间的顺序链式记录。区块链本身就是一个公共的数据库，系统将新诞生的业务数据存储在被称为区块的容器之中，并将该区块添加到已有区块组成的链条之中。有点像贪吃蛇，吃的区块越多，蛇的身体越长；在比特币的应用场景下，这些数据是一组转账交易记录。在共享单车的应用场景下，这些数据就可以是借车还车的交易记录。

区块链的简易实现代码

在上述的代码中，区块链核心存储的数据结构是列表，通过 new_block()产生的新区块，被不断的增添到区块链的尾部，每个区块的 Hash 值中包含该区块所有的数据信息，在计算该 Hash 值的过程中需引用前一区块的 Hash 值，故而实现了防篡改。而区块链数据库的最大价值就是这种高度防篡改的可信计算。在我们的简易区块链实现中成功体现了这一点。在商用级的区块链应用中，新建区块的过程被称为智能合约，区块链就是通过智能合约不断的壮大。
以下是代码的运行结果，在不同的时间下，运行结果不同。

运行结果

如想学习更多关于IT技术方面的文章，请前往51Testing软件测试网-中国软件测试人的精神家园(http://www.51testing.com)。

更多内容请关注51testing软件测试网

　　那么对于Web应用来说，该测试哪些方面，该如何测试呢？来看看作者 Abhimanyu Ghoshal给出的这些建议。
　　一、首先应该测试什么？
　　当测试Web应用的时候，首先要明确你的应用要用来做什么，比如帮助用户编辑照片、发送票据、联系朋友或跟踪社交媒介等。你通常需要着眼于这四大领域：
　　1.  功能性测试
　　几乎所有的用户都期望自己所使用的Web应用功能准确、迅速、一致。这就意味着开发者必须精益求精，帮助用户实现某种形式上的结果。下面是一些需要全面测试的常见的功能元素：
　　表单：无论是反馈调查、创建任务计划，还是订阅新闻，都需要用到表单。你需要检查提交操作是否正常，是否能够提交连接并提交到你的数据中，所有字段是否能够接收输入的内容。
　　文件操作和计算：这其中涉及图像和文档的上传、编辑、计算功能和正确的输出值。首先，要确保你能想象得到会有多少用户会使用你的应用，并尽可能地针对他们进行调节。另外，要考虑一下如何使你的App更有效地计算并显示出结果，给用户提供一个更加流畅的用户体验。
　　搜索：如果你的应用允许用户搜索内容、文档或文件，那么就要保证你的搜索引擎能够索引这些信息，并定期更新，以便能够让用户实现快速查找，并根据查找条件快速显示相关结果。
　　媒体播放组件：测试音频、视频、动画和互动媒体播放组件（如游戏和图形工具）的时候，这些组件应该像预期的功能效果一样，在加载和运行的时候不能影响（暂停或减缓）其他应用的运行。
　　脚本和类库：确保你的脚本（比如图像显示或Ajax页面加载）在各种浏览器之间是相互兼容的，因为不同的用户可能会使用不同的浏览器访问你的应用，同时你可以测量不同浏览器的加载时间来进行性能优化。如果你的脚本只能和某些浏览器相互兼容，那么就要确保应用中的其他组件有更好的性能，这样所有的用户就能得到最好的应用体验。
　　最后，就是要全面检查其他组件的功能，包括提示系统、用户配置文件和管理仪表板等。

更多内容请关注51testing软件测试网...

官方标准应该是：
　　在产品的需求探索阶段，测试就需要进入，提出测试对产品的一些可测试性需求，比如在产品中增加调试命令，增加模拟告警信息等。同时，对产品的需求，从测试本职业务的角度进行分析、设计。
　　实际上，不同的产品、项目，团队的成熟度，可能测试进入的时间并不一定。
　　比如测试团队是新成立的团队，本身没有足够的能力去对产品进行出谋划策，那么还不如老老实实的等产品设计完成后，请开发人员或项目经理培训一下，然后先从功能黑盒测试开始入手。
　　比如产品是老产品，是V4.0升级到V4.1，产品线经年累月就是不停的迭代开发一个主产品，那么在少量的增量开发的前提下，在需求阶段过多的介入，反而是投入产出不成正比，还不如少量的投入，抽出精力把测试用例进行优化、开发测试工具、提炼场景式测试方法等等。
　　国内的测试还不太正规，所以结合实际情况，做到比较适合、符合本公司的实际业务情况和成熟度即可。

ipadmini、惠普平板电脑、京东购物卡...一大波好礼正在接近！参与51Testing圣诞节新年活动 ~2014马上有礼！

活动一：【“购房通”圣诞新年找茬活动】找茬，找房，找BUG，找出你的ipadmini~  bbs.51testing.com/thread-999309-1-1.html
活动二：【圣诞&新年猜猜猜】猜中有礼，百元京东购物卡，圣诞只为等你猜！bbs.51testing.com/thread-999324-1-1.html

　　因为存取频繁，所以这几个表的数据存在内存中，更新数据后使用，语句来进行内存更新
　　当然执行这个命令需要reload权限
FLUSH PRIVILEGES

　　用户登录时需检查，mysql.user中的user host pass 三个字段，如果允许任何主机外部链接可以吧host设置成%
　　用户登录通过后，mysql会自上而下的检查用户权限，首先在mysql.user中读取对应用户的权限。

51Testing软件测试论坛圣诞活动火热进行中 ipad 大奖等你拿  详情请上51testing软件测试网论坛

开发或者测试互联网产品的过程中，同学们一定遇到过connection timed out和socket read timed out两种和网络相关的异常。今天我们并不分析引起这些异常的原因，也不谈发生异常以后的解决办法，我们来说说如何制造这类异常，从而模拟对应的异常场景。
　　了解tcp协议就知道connection即建立连接的过程，其实和socket read即传输数据的过程并没有太大的差别，两者都是请求应答模式，而只是前者的请求数据量很小而已。要使两者超时，我们可以采用相同的方法即限制网络传输的带宽来达到目的。
　　Tc即traffic control就是这样一款能够限制网络流量的工具。Tc中主要的概念包括类class和过滤器filter。
　　我们可以用class把网络设备的带宽划分成不同的区间
　　tc class add dev $DEV parent 1: classid 1:11 htb rate 90mbps ceil 100mbps
　　tc class add dev $DEV parent 1: classid 1:12 htb rate 90bps ceil 100bps
　　如上，11这个class对应的带宽为90到100mbps，12这个class对应的带宽只有90到100bps。划分好了class，我们就可以用filter把符合特定条件的数据包归入不同的class中
　　tc filter add dev $DEV protocol ip parent 1:0 prio 1 u32 match ip sport $PORT 0xffff match ip dst $IP flowid 1:12
　　如上就把源端口是$PORT，目的地址是$IP的数据包归入12这个class中了，这样就把符合该条件的数据流量限制到了90到100bps。在正在运行的系统中开启上述tc限制，即把特定数据流限制到一个极小值，我们就能模拟出connection timed out异常了。关于tc更详细的教程可以参考1、2。
　　那么socket read timed out异常又该如何模拟呢，我们怎么才能区分建立连接和数据传输这两个过程，tc工具还能满足我们的需求吗？在寻找问题答案的过程中，另一个linux内核组件iptables进入了我们的视野。
　　Iptables是linux系统中常用的防火墙组件，功能十分强大，网上有十分丰富的资料。由于其能够识别数据包中的syn、ack等标志位，故能把建立连接和后续的数据传输过程区分开来。
　　iptables -A INPUT -p tcp --src $IP --dport $PORT ! --syn -j DROP
　　如上，在目的机器上加入该条iptables规则，可以实现将未设置syn标志位的数据包丢弃的功能，这样连接能够建立完成但后续的数据传输将无响应。
　　另外，Iptables具有一种连接跟踪机制，即能够记录连接的状态。这些状态分别是NEW、ESTABLISHED、RELATED和INVALID。我们可以利用该特性实现相同的效果。
　　iptables -A INPUT -p tcp -m state --state ESTABLISHED -s $IP --dport $PORT -j DROP
　　如上，在目的机器上加入该条iptables规则，当匹配了ip和端口，并且数据包所对应的连接状态是ESTABLISHED时将其丢弃。
　　至此read timed out异常也能轻松模拟了。Tc和Iptables是linux网络模块中强有力的工具，除了能够利用它们开发功能，也能够在网络异常测试中发挥关键的作用。

51Testing软件测试论坛圣诞活动期待您的参与~ipadmini 惠普平板 京东购物卡等你来抢！