具有软件开发，测试实施经验

　　软件质量保证牵扯到软件开发的方方面面，包括从启动到需求，到设计，到开发，到测试，到发布，到后期维护的整个过程。在启动阶段，你要理解如何制定项目章程，如何书写项目范围说明书，如何制定项目计划；在需求阶段，你需要理解如何与用户确认需求，如何进行需求分析，如何与用户确认用户需求；在设计方面你要大体理解当前设计前沿技术，了解数据库知识，如何进行概要设计和详细设计；在构造阶段，您需要了解编码规范，编程技巧，集成技术；在测试阶段你需要理解如何进行单元测试，集成测试，系统测试；在验收阶段您需要理解如何进行验收测试，如何培训用户，如何替用户搭建环境；在维护阶段您需要理解如何理解代码，如何进行再工程技术。在这里你好像是一位多面手，但是了解得越多，对你从事质量保证工作越有好处。由于现代分工比较细致，往往一个质量小组需要各个方面的人才组合在一起，才能发挥更大的效能，才能达到1+1>2的结果。

具有一定的数学基础

　　对于从事软件质量保证工作，您需要一定的数学知识，尤其是概率统计知识。无论你是否采用6Sigma，你需要对你的软件质量进行度量活动，需要收集数据，分析数据从而解决问题。你要理解如何使用直方图，散点图，鱼刺图，饼图等工具。这样你才能展示问题的原因，寻找解决问题的原因。

强大的沟通能力

　　对于从事软件质量保证工作，沟通能力非常重要。质量工作做得好坏，关键在于领导的支持和员工的参与。由于目前中国软件的实际工作，公司领导往往忽视软件质量的重要性和优先性，你就需要与领导讲清楚质量管理的优势，如何可以提高公司产品的质量，减少客户的投诉率从而节约公司的成本，提高劳动生产率。有了领导强有力的支持，你的工作就好像添加了一把利剑，可以运行得得心应手。但是仅仅有领导的支持时往往不够的，还需要员工的支持，你需要了解当前问题有什么，阻碍这些问题的要数是是什么，大家需要解决什么样的问题…这些都需要靠你的沟通技巧来解决。

专业的管理和质量知识

　　专业的技术是你软件质量工作成功的有用的武器。在这里我向大家介绍两本书，一本是美国项目管理学会（PMI）颁布的项目管理知识架构体系（PMBOK），它里面的中心思想是项目的五大过程(启动、规划、执行、监控、结项)和九大知识领域（整体、范围、进度、成本、质量、风险、人力资源、沟通、采购）；还有一本是IEEE颁布的软件工程知识架构体系(SWEBOK)，里面主要介绍十大知识领域（软件需求、软件设计、软件构造、软件测试、软件维护、软件配置、软件工程管理、软件工程过程、软件工程工具、软件质量）

1、人机交互性
（1）界面设计简单明了，布局符合用户业务需求，使用户能够很容易找到自己想要使用的功能。页面设计复杂，无疑会对用户操作

效率造成影响。如果我们把所有功能都罗列在一个界面中，用户使用起来只能感觉眼花缭乱，无所适从。
（2）功能名称命名使用用户行业专业术语和常用计算机语言，相同功能命名要统一。名称命名不规范，常常会使用户不知道如何进

行操作，容易造成误操作。
（3）图标、标识符合通俗易懂，特别是打开、保存、关闭这些常用按钮图标，不要追求出新和另类。

2、易用性

（1）菜单设计最好不要超过3层，超过3层菜单，用户使用都会觉得比较复杂。
（2）快捷键设计采用常用快捷键设计，如：F5刷新，Ctrl+C复制。
（3）TAB键的顺序符合业务需要，特别是录入页面，根据用户工作习惯进行顺序设置。
（4）浮动工具条位置、长度、大小，不要遮挡界面主要内容。
（5）减少页面跳转，尽量一个功能在一个页面内完成。
（6）鼠标右键功能和右键菜单的设计。

3、用户的使用习惯
针对不同行业，用户都有不同的使用习惯，界面的操作要符合用户的习惯，特别是产品升级时，界面设计一定要考虑老用户的使用习惯。
4、行业特点
有很多行业具有一定的特殊性，界面操作必须要考虑到这点，比如提供给客户服务热线电话登记的软件，就要考虑让用户尽快少的点击鼠标和使用键盘。一个下拉菜单选择项，需要点击鼠标两次，而一个单选框只需要点击一次，这样的设计虽然很微小，但对用户实际操作会起到很大的帮助。
5、特殊需要
对用户的特殊需要，是否能够很好的实现。例如更换登录用户，大部分软件都是使用者退出，返回登录界面，然后使用另一个用户登录，有的用户就会提出在主界面可以直接登录另一个用户，当前使用的用户自动退出。

Web安全测试知多少
http://www.51testing.com/html/11/n-109111.html

web安全测试－跨站点脚本攻击
http://www.51testing.com/html/21/n-89421.html

WEB安全测试通常要考虑的测试点
http://www.51testing.com/html/71/n-129971.html

Web安全测试概述
http://www.51testing.com/html/16/n-131216.html

WEB安全测试所需的基础知识提纲
http://www.51testing.com/html/38/n-142338.html

Web测试方法
http://www.51testing.com/html/83/n-7583.html

Web测试中容易被忽略的Charset问题
http://www.51testing.com/html/82/n-20482.html

WEB测试经验总结
http://www.51testing.com/html/27/n-64427.html

web测试的几个隐藏点
http://www.51testing.com/html/65/n-76465.html

大家多用搜索功能，网站上有很多相关的资料。

虚拟机中安装的windows 2003系统如何访问本地windows 7系统的操作步骤：
1.先设置虚拟机中安装的wind2003 系统的网卡，也就是设置IP.

2.设置好IP，在虚拟机系统中新建个文件夹，设置该文件夹可共享并赋予操作权限。如图：

3.到本地wind 7系统中访问wind 2003系统，打开wind 2003共享的文件夹，把wind7系统中的文件夹拖放到Wind2003系统中，就OK.

许多bug并不值得去修复。“你这也算是测试人员吗？”，你肯定会冲我大叫，“测试人员是产品质量的捍卫者。”我可以再重复一次（如果需要的话）许多bug并不值得去修复。“让我来告诉你原因。在大多数情况下，修复bug就必须要修改代码。而修改代码需要投入资源（时间）并会引入风险。这真是很糟糕，但这却是事实。有时，如果风险和投入远超过修复bug的价值，因此我们就不会被修复这些bug。

　　我们决定是否修复一个bug并不是，也不应该是靠“感觉”。我喜欢用“用户痛苦”的概念来帮助我做决定。我会用三个关键因素来考虑并确定“用户痛苦”：

　　1、严重性—— 这个bug将产生什么影响 —— 它会让整个程序崩溃吗？它会导致用户的信息丢失吗？或者并不是那么严重？有更简单的解决方法吗？还是它仅仅是个无关紧要的问题？

　　2、频繁性—— 用户碰到这个问题的频率高吗？它是程序主要工作流程中的一部分？还是隐藏在一个并不常用的功能中？在最常用的那部分程序中存在的小问题很可能是需要修复的，而一些不常用到的那部分程序中存在的大问题，也许我们会放在一边。

　　3、对客户的影响——如果你之前准备工作做得好，你应该已经知道你的客户是谁，你的每个客户群中会有多少（或者是你希望有多少）用户。这样你就需要判断，这个问题将会影响到每位用户一，还是仅仅一部分人。如果你能追踪出客户如何使用你的产品，你就能得到更准确的数据。

　　以上3点因素就构成了一个公式。给上面的每一个因素都分配一个数值范围，并且用一些计算 —— 你可以直接使用加法、乘法或是基于你的应用程序以及市场因素加上权值。打个比方，我们只需要执行加法并且对每个bug赋予10分的数值范围。

　　Bug #1：比如它是一个会让程序崩溃的bug（10分），它存在于程序的主要部分（10分），它影响了80%的客户（8分），因此这个bug的”用户痛苦“量值为28分，我们打赌我们肯定会修复它。

　　Bug #2：它仅仅是一个关于排列的bug（2分），它出现在二级窗口中（2分），这个bug所在的那部分程序只会在旧版本中被使用到（2分）。因此这个bug的“用户痛苦” 量值为6分，我们很可能不会去修复它了。

　　遗憾的是，很多情况并不像上面所说的那么简单。Bug #3是一个数据丢失问题（10分），它存在于一个应用程序的某个主要部分中，却只在某些特定的情况下才出错（5分）（顺便提一下，数据是主观编造出的）。客户研究证明它很少会被使用（2分）。因此它的 “用户痛苦”量值为17分，这是一个模棱两可的数据，修与不修都可以。一方面，修复它所需要的投入可能并不值得，只要这个问题能够被理解，并且它没有任何盲点，不再理会这个bug很可能是正确的处理方法。

　　从另一方面来看，你必须把它和系统中的其他bug进行权衡。我们在这里应用“破窗效应（Broken Window）”—— 如果应用程序中有太多此类中等阈值的bug，产品的质量（或者最起码，从质量的感觉上）一定大受影响。你在考虑系统中每一个bug的时候，还应该结合考虑系统中其他（已知的）bug，并且以此来分析、决定哪些bug是需要被修复的而哪些则不值得被修复。

　　正式发布的软件中有bug的确是一件十分糟糕的事 —— 但基于我们现有的开发工具和开发语言，我们还没有找到一个更加合理的解决方法。

　　补充：

　　写出这篇文章的时候，我想我遗漏了公式中的第四个因素：发布日期。临近发布日期时，这个因素在修复/不修复bug的决定中也起了关键作用。然而我并不确定它是否是第四个因素，也无法确定在临近发布时期时，修复一个bug所需要的 “用户痛苦”量值的阈值是多少。

给其他用户赋予数据库操作所有权限：grant all privileges on *.* to linc@192.168.1.46 identified by '123456';

mysql数据库　服务启动时出错：１０６７进程意外终止

解决方法：

1、打开my.ini文件，找到default-storage-engine=InnoDB这一行，把它改成default-storage-engine=MyISAM。

2、删除在MySQL安装目录下的Data目录中的
ib_logfile0
ib_logfile1

3。找到在配置MySQL服务器时指定的InfoDB目录删除掉
ibdata1
4。重新启动MySQL的Service 

  玩家组队，队长在当前地图上显示寻路标记，队员客户端当前地图上也显示该寻路标记，这个任务是我负责测试的，设计用例的时候忘记考虑，队长在寻路过程中，队员执行其他操作，会不会导致队员当前地寻路标记的消失。所以在版本放出后出现以下现象：队长进行寻路操作，队员的当前地图上显示寻路标记但当队员点击地图上的任意其他位置时标记消失.

出现现象：当玩家附近聊天信息超过100条以上时，客户端会很卡，卡至玩家不能移动。
复现步骤：
3个玩家在同一个场景同一个位置下，同时发送信息，让聊天框信息超过100条以上，而且每条信息的内容不同，玩家接受的信息越多，客户端越卡。
用例遗漏点：未考虑多个玩家同时发送信息，客户端可否立即从数据库里面读取数据，读取数据时会不会造成通信传输问题。

--------------------------------------------------

出现现象：玩家返回角色选择不成功后组队切线至曾经crash过的线会导致目标服务器crash                                                         复现步骤：                                                       1.二线崩溃(/s ohmygod)
2.一线玩家A返回选择角色不成功
3.重启二线
4.玩家A与另一玩家组队后切至二线
用例遗漏点：多条件下组合，玩家切线导致客户端crash.

出现现象：
复现步骤：
用例遗漏点：

 

 

代码做静态分析工具：QAC和PC-lint

动态单元测试工具：insure++。

作为一个专业的测试者，要学习很多东西，专业的测试技术和对业务的熟悉。

个人在测试工作2年多的感悟。

1.测试者要不断的总结知识，不然时间长了什么都忘记了。

2.发现了新问题，要去想办法解决这个问题，如果有更多的时间，在想想还有更好的方法吗？

 

哈哈 今天终于开通了 自己的空间

 

 发现里面有很多好玩的东西哦 !