专业软件测试人员发展的未来
根据Google/微软一些大公司开发和测试融合分工新的趋势，未来的IT世界有可能会发展出一种新的场景和分工：
基本的功能测试设计执行和白盒测试技能应该让所有开发人员都所具备，然后才能解放出专业的测试人员去做复杂的测试工作（非功能测试、beta测试、测试执行平台打造等），有时间去研究如何提高整个研发团队的测试质量与测试效率，更好地辅导开发人员掌握基本测试技能，当然开发人员依然要通过交叉测试来解决测试心理学的问题（不能自己测试自己）。开发将对自己的局部代码质量负责，测试专注整体架构的质量与团队的整体测试体系建设。
这种模式的收益：团队中功能测试人员的数量会减少，研发中的很多低级bug会尽早在开发团队中被发现从而减少bug后期发现的成本和沟通成本，既减少研发成本又能加快研发速度。
这样一种测试分工模式成为现实后，测试人员的工作会更有创造性更有趣，更偏重脑力劳动，而简单的测试工作岗位会更少，市场会需要更多测试专家，简单的测试设计和部分手工执行会由开发人员担当，更多测试执行由自动化来实现，而这也正是敏捷开发模式中的现象。
未来某些公司中tester会出现少而精的状况但是不会消失，当然由于各个公司组织能力建设的程度不同，吸引中高端人员的能力不同，现有的测试模式和新的测试模式会长期共存，而那些能吸引中高端人才的公司则会出现更高效率的研发团队，结果是测试人员的工作更多是技术创新，开发人员测试工作的技术顾问和执行复杂的测试任务。
版权声明：本文出自 架构师Jack 的51Testing软件测试博客：http://www.51testing.com/?293557
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
软件测试工程师的分类从新手到专家
两个重要的概念。
1、经验。不仅仅是我做过什么什么，做了多少多少次，多少多少年，更重要的是在一次次重复的过程中，发生了思维的改变。直白一些说就是在做的过程中不断的思考、学习、改进。否则就只是重复了N次，而并没有对等的经验。——这个问题在一直以来的面试中经常遇到，很多声称有4年经验的 tester，其实只是重复了很多工作，而经验只能相当于2年。
2、情境。区分从新手到专家各个不同等级的重要标志，直白的说，就是一个人对当前所需要解决的问题认识的是否准确。这个不太好量化，牵扯到一个“怎么知道自己认识的是否准确”的问题，所谓的“决策失误”之类的，就是这么个事情。作者的一个观点是“新手通常乐观而无畏，而专家就谨慎的多”。
--------------------------------------------------------------------------------
进入正题了，说说从渺小变强大的过程吧，在讨论的过程中需要反复的引用“经验”和“情境”这两个概念。
NOTE： 新手 和 专家 不是绝对的。你可以在某个领域是专家，而在另外一个领域是新手。
1、新手：对所需要处理的问题毫无经验。
● 作为一个新手，最大的期望是有一个 list 让他照着做就顺利的把事情搞掂，而不是给他一些建议让他自己去尝试——悲观点估计，他会因为无法理解复杂的概念体系以及受挫而变得烦躁易怒、痛苦不堪，并可能随时放弃。所以对待新手的最好方法就是前面那个。
● 当新手手执一份 list 时，表现的会像个专家，因为你可能会发现他的思路很有条理、很靠谱——这个典型的例子就是呼叫中心的座席，典型的 if...else...else...else...then...end 的模式
● 新手的最大特点，就是无法处理任何异常/例外的情况，哪怕是跟 list 上稍有差别——当然，也有些胆子大的敢胡乱折腾。
● 专家可以写出完美的 list 供新手化装成专家，但如果专家自己用这个 list 来工作，则可能表现的还不如那个新手化装成的专家。很绕口，不过的确是这么个意思。
● 在公司里，常见的新手是应届生/实习生。
2、高级新手
● 高级新手与新手的最大不同，在于有了一点经验（注意前面对“经验”的定义），并开始尝试着通过学习来独立解决一些局部的、具体的问题，但通常属于依葫芦画瓢，画得有点费劲，并且可能不太像。
● 高级新手开始有了一些碎片化的知识和经验，但对需要解决的问题缺少系统化、结构化的认识。
● 例如一个 tester 能在文档的帮助下独立完成对环境的搭建和 test case 的执行以及 bug 提交等工作，并且最重要的是他开始能够借助 Google 解决一些技术上的例外情况；或者，一个初级开发人员能通过 Google 或 API 的学习编写一些小段的功能代码。
● 在公司里，通常我们把高级新手称为初级工程师。
3、胜任者：团队中的中坚力量
● 对于自己所从事的工作，胜任者已经掌握了现有的一整套工作思路/方法，并能用来解决相同领域的各种不同问题。例如，一个测试工程师可以理解不同系统的需求，并根据用例设计方法设计出测试用例；同时，他能够与不同的项目团队进行沟通，完成项目的各项测试工作。既是对于不同的业务领域，也能较快的学习上手。
● 胜任者掌握了处理解决类似问题的多种方法，并且有能力区分当前哪个方法更适用。
● 胜任者拥有完全独立工作的能力，而 新手 和 高级新手 通常需要 胜任者 的监督和帮助。
● 在公司里，通常胜任者是 中级工程师。
4、精通者
● 相比 胜任者，精通者做到了“知其然，知其所以然”，不单单能根据当前的情境（参照上面对情境的定义），更有能力思考如何改进原有的解决方法/方式，以更高效的解决问题——这依据的是其对技术、业务、过程的结构化、系统化的理解和思考。
● 精通者 能够理解一些抽象的信息，甚至从中吸收一些新的东西——但未必一定要通过动手实验，进而提出新的抽象模型/模式。
● 对于精通者来说，具体的技术/工具已经不是其完成工作的障碍。
● 对新手和高级新手的容忍度很低。
5、专家
● 已经不再受任何规则/指南的约束，解决自己领域的问题对他们来说似乎不需要思考，如在前文中提到的，专家使用的是“直觉”，这种通过长期大量反复的实践、总结和思考/冥想以后，已经由意识层面进入了潜意识层面的东西。
● 专家可以把自己的解决思路/模式梳理成 list/指南，但是他深知无法将所有的细节和例外都包含其中，而这些细节和例外，就是“情境”中最重要的部分，甚至各种细节变化的累加，足以使一件事情变成了另外一件事情，而专家总是能从容的处理这一切。另外，因为专家深知这一切，在他未表现出来的内心中会对问题保持谨慎的态度，而相对的，新手或高级新手有一种盲目的乐观。
● 如果你要专家使用自己编写的 list/指南去工作，他将无法施展出自己的才能，甚至表现的像个高级新手。所以，对于专家不要要求他像其他人那样工作。
● 如果你见过真正的太极高手，就能体会到什么叫“行云流水”一般，一切显得从容不迫，而这就是专家给人的感觉——可以做到完美，并且感觉不到他是在处理那些胜任者无法想明白的难题。
● 据说人群中能成为专家的，只有1%-5%，所以貌似不用强求自己一定要成为专家，做个精通者也挺好的。
--------------------------------------------------------------------------------
讨论完了从新手到专家的过程，早来说点其他有趣的东西。
1、专家应该尝试编写指南供新手和高级新手操作，并为胜任者和精通者提供培训和指导，但应该避免直接培训新手和高级新手。
2、精通者同样无法忍受新手和高级新手，所以最好去帮助胜任者把事情做得更好。
3、胜任者是培训和指导新手和高级新手的最佳人选。但是，如果缺少了精通者和专家的指引和帮助，胜任者想突破自己将是一个非常痛苦和漫长的过程。
4、新手需要“被驾驭”，别理解错了，他们需要在有明确指引的情况下快速的完成任务，快速收获成就感，否则很容易被挫折打败。
5、高级新手需要更多的激励和实践，以帮助他正确的理解当前所从事的工作，并尽快成长为胜任者。
6、合理的人力结构并非金字塔结构，团队中新手和专家都不要太多。据统计，大概是这样的（书中只有图例，我大概的估算了一下）：高级新手 40%，胜任者 30%，精通者 10%，新手 15%，专家 5%。
7、但如果是一个 agile 团队，新手和高级新手都不要太多，因为 agile 中充满着各种“隐喻（oracle）”和“经验之谈”，这将大量依靠精通者和专家来解读和运作。
8、在推动团队前进方面，精通者与专家有同样的价值。
版权声明：本文出自 aiffir 的51Testing软件测试博客，欢迎转载......
“数据库镜像”是用于提高数据库可用性的主要软件解决方案。Oracle数据库与SQL Server数据库作为两个应用非常广泛的数据库，在数据库镜像上的操作有很多的不同，通过对比，将会深入发现SQL Server与Oracle数据库镜像的不同。
首先，微软SQL Server数据库中的镜像数据库类似于Oracle数据库中的备用数据库。我说的只是类似，确切的说，我们需要考虑不同数据库在自己体系中的差异。SQL Server作为一个实例来操作，一个实例包含几个数据库，你首先要登录一个实例，然后选择哪个数据库作用于该实例。而在Oracle数据库中，简单模式（忽略RAC）就只有一个数据库与一个实例相联系。因此，可以这么说，在Oracle数据库中，备份数据库（standby database）就完全是主数据库的快照。而在SQL Server中，镜像数据库仅仅是选择的那个数据库的备份，但没有包括代理，登录，任务（这些或者更多的数据库项目需要单独在数据库镜像上创建或者复制）这些外部数据项。
在服务器数量上，Oracle的主数据库和备用数据库配置最小需要2台。在SQL Server中，最小数据是2个或3个，根据你所选择的高可用性、高安全性、高性能方式所决定。
高可用性方式：这个操作模式选项允许你在两台服务器上同步事务写入，并支持自动错误恢复。要使用这个选项，你必须还要使用一个证人服务器。
高保护方式：这个选项可以让你在两台服务器上同步事物写入，但是错误恢复是手工的。因为自动的错误恢复不是这个选项的一部分，所以也不会用到证人服务器。
高性能方式：这个选项不关心两台服务器上的写入是否是同步的，因此在性能上有所提高。当使用这个选项的时候，你只能假设镜像服务器上的所有事情都是成功完成。这个选项只允许手工的错误恢复，因此不会用到证人服务器。
为了保证故障自动恢复，就需要有第三台服务器，可以称之为目击者（另外两个就是主数据库和镜像数据库），你可以将这个目击者当作群集中的一个成员。它实现了2比1投票的能力，当我的一个组件不可达，并因此需要进行错误恢复的时候。证人服务器只有在你想实现自动错误恢复的时候才需要用到。
在Oracle数据的一个事务中，日志缓冲器在废数据写入数据文件（忽略write-ahead情况）前被刷新或者写入到redo日志中。这种刷新或者写入到redo日志的行为是有必要的，如像实例失败（使用前滚和回滚恢复过程）这样的事件发生时。SQL Server也承认将日志缓冲器写入到磁盘的重要性。不过这里称之为硬化（hardening）。首先将事务日志缓冲器的信息写入到磁盘或者硬化，接着将日志记录块发送到镜像数据库中。镜像数据库接收到该日志记录块后，将之存入到某个缓冲器中，随后依次硬化该日志记录块。
当数据发生变化时，SQL Server数据库如何保持主数据库和镜像数据库的一致性呢？
Oracle用户非常熟悉SCN，而SQL Server用户通过使用mirroring_failover_lsn机制（粗略来讲就是一个日志序列号）。SQL Server与Oracle不同，SQL Server将事务分离（两个事务在两个机器上），而不是一个分布式事务（在自身提交前需要远程等待提交）。
另外一个相似点，但稍微有些畸变的反射就是redo日志和事务日志。在Oracle中，完成的redo日志将被发送到远程的服务器中，将完成的redo日志应用到备份数据中去。在SQL Server中，事务日志没有被传输，但是就像我以上提到的，日志缓冲器数据发送到网络上。这就导致另外一个镜像反射：备份和恢复模式。
在Oracle中，当你处于归档模式或者非归档模式的时候，这些操作是内定的。如果归档redo日志被传输或者提交到一个远程的服务器，那么主数据库明显就是在归档模式下，那些文件就是这么产生的。运行在这种模式下，允许有少量的数据丢失，因为在发生故障（无论什么样的故障）前，恢复能够在任意一个点上执行。在SQL Server中是类似的，但是有三种状态需要选择。
《SQL Server联机丛书》，像许多其它的在线资源一样，讲述了在使用SQL Server时，3种恢复模式的不同点。快速的比较有：SQL Server完整模式对应于Oracle中的归档模式；简单模式对应于非归档模式；bulk模式与使用直接路径插入，添加提示，或者与nologging模式操作类似。
根据以上三种模式（这三种模式很容易转换，不需要关机或者重启）的描述以及日志缓冲器和归档redo日志的讨论中，很容易断定在SQL Server中进行数据库的镜像需要将数据的回复模式设置成完全模式（full model）。简单模式（Simple model）或许也能行，但是这种模式下维持事务日志中的小部分数据，在备份中，如果在日志被删节了，整个镜像过程也就破环了，因为当你在将事务发送到镜像数据库中的时候，如果日志被删节了，这个过程就不能完成。
说到数据库被破坏该怎么办呢？
这正是镜像（或者说备份）的主要目的：当主数据库断开或者说遇到故障时候我们希望系统能回到镜像前或者备份前的状况去。这如何才能实现呢？我们能自动实现或者手动实现。想实现这些，需要一些已经完成的设置。在SQL Server中，自动故障恢复，回到原来状态需要在HA模式，事务安全是full，数据传输是同步，有目击服务器的情况下。这种模式下运行还需要使用企业版的数据库系统。高安全性和高性能在标准版的情况下也能实现。
SQL Server还有其它版本的选择，但是这些并不如Oracle的反射“干净”，这些版本包括：Developer、Workgroup 和 SQL Express。举个例子，目击服务器能够是任何的版本，但是如果你想给镜像服务器做一个快照，那么你就需要企业或者开发版的了。
在设置伙伴（partner，通常有主数据库和镜像数据库组成）过程中，他们的恢复状态开始起作用。通过使用相同的名字，镜像在远程/镜像服务器上建立（使用配置数据库镜像安全向导是最简单的方法）起来，并且镜像数据库被设置成NORECOVERY，通常它是恢复（recovering）状态的。在SQL Server中，恢复数据库是没有的，因此没有进行上述的设置，是不能被其他用户当作只读数据库来使用的。
为了避免这个中缺陷，你可以给镜像做一个快照，使得该“影像”对用户可见。正如我上述所提到的那样，这需要你的数据库版本是企业（或者开发）版。这就意味着用户需要有快照数据库的知识，知道如何进入存储它，如何告诉应用程序使用哪个数据库。惯例上来说，配置文件使用的.NET环境，你能建立一个主数据库和一个故障回滚的辅数据库。如果在Oracle中配置过备份数据库，你就会觉得这很类似。
结论
这篇文章内容包括按照Oracle的方式，如何更好的理解在另一种主流的RDBMS上执行镜像或者复制，。试着学习和解释你的RDBMS如何工作的，从另外一种模式来得到你的注意有助于你搞清楚你当前数据库系统运行原理。举个例子，我发现非常有实用价值的是Oracle归档模式和SQL Server三种恢复模式之间的关系。使用在SQL Server中的一些术语（伙伴，主数据库，目击，镜像）有助于你构成和识别Oracle中执行数据库镜像的操作。为了更好的评价数据库镜像是如何运作，如何实施的，你可以运行两个单独的SQL Server实例，操作系统是XP或者是2003都没有关系。按照MSDN联机丛书的步骤完成一遍。
下载或者选用AdventureWorks数据库（类似于Oracle的HR/SH数据库等。这些都没有预安装的），将其镜像到主机服务器上。呈现在你面前的不仅仅是另外一个数据的所具有功能特性，你将还会看到SQL Server所具有的操作，得到自己的正确评价。
数据库镜像对于数据库来说，是一个非常重要的应用，而通过不同平台的对比，更能发现各种数据库（比如SQL Server数据库与Oracle数据库镜像对比）在数据库镜像上的不同。
SQL Server中数据库文件的存放方式
在SQL SERVER中，通过文件组这个逻辑对象对存放数据的文件进行管理。
先来看一张图：
我们看到的逻辑数据库由一个或者多个文件组构成
而文件组管理着磁盘上的文件.而文件中存放着SQL SERVER的实际数据。
为什么通过文件组来管理文件
对于用户角度来说，需对创建的对象指定存储的文件组只有三种数据对象：表，索引和大对象（LOB）
使用文件组可以隔离用户和文件，使得用户针对文件组来建立表和索引，而不是实际磁盘中的文件。当文件移动或修改时，由于用户建立的表和索引是建立在文件组上的，并不依赖具体文件，这大大加强了可管理性。
还有一点是，使用文件组来管理文件可以使得同一文件组内的不同文件分布在不同的硬盘中，极大的提高了IO性能。
SQL SERVER会根据每个文件设置的初始大小和增长量会自动分配新加入的空间，假设在同一文件组中的文件A设置的大小为文件B的两倍，新增一个数据占用三页（Page），则按比例将2页分配到文件A中，1页分配到文件B中。
文件的分类
首要文件：这个文件是必须有的，而且只能有一个。这个文件额外存放了其他文件的位置等信息.扩展名为.mdf
次要文件：可以建任意多个，用于不同目的存放.扩展名为.ndf
日志文件：存放日志，扩展名为.ldf
在SQL SERVER 2008之后，还新增了文件流数据文件和全文索引文件。
上述几种文件名扩展名可以随意修改，但是我推荐使用默认的扩展名。
我们可以通过如下语句查看数据库中的文件情况：
还有一点要注意的是，如果一个表是存在物理上的多个文件中时，则表的数据页的组织为N（N为具体的几个文件）个B树，而不是一个对象为一个B树
创建和使用文件组
创建文件或是文件组可以通过在SSMS中或者使用T-SQL语句进行。对于一个数据库来说，既可以在创建时增加文件和文件组，也可以向现有的数据库添加文件和文件组.这几种方式大同小异。下面来看一下通过SSMS向现有数据库添加文件和文件组。
首先创建文件组：
文件组创建好后就可以向现有文件组中添加文件了：
下面我们就可以通过语句将创建的表或者索引加入到新的文件组中了：
使用多个文件的优点与缺点
通常情况下，小型的数据库并不需要创建多个文件来分布数据。但是随着数据的增长，使用单个文件的弊端就开始显现。
首先：使用多个文件分布数据到多个硬盘中可以极大的提高IO性能。
其次：多个文件对于数据略多的数据库来说，备份和恢复都会轻松很多.我碰见过遇到一个150G的数据库，手头却没有这么大的存储设备…
但是，在数据库的世界中，每一项好处往往伴随着一个坏处：
显而易见，使用多文件需要占用更多的磁盘空间。这是因为每个文件中都有自己的一套B树组织方式，和自己的增长空间。当然了，还有一套自己的碎片-.-但是在大多数情况下，多占点磁盘空间带来的弊端要远远小于多文件带来的好处。
总结
本文对SQL SERVER中文件和文件组的概念进行了简单阐述，并在文中讲述了文件和文件组的配置方式。按照业务组织好不同的文件组来分布不同的文件，使得性能的提升，对于你半夜少接几个电话的帮助是灰常大滴:-)
在这些条件下，伪造一个RGHConnection对象最好的方法是对RGHConnection类应用接口提取。如果你手头一个支持重构的工具，那么它很可能也会支持接口提取方法。我们来看一下接口提取后的情况：
<interface>
IRGHConnection
+connect()
+ disconnect()
+RFDIReportFor(id:int):RFDIReport
+ACTIOReportFor(customerID:int) ACTIOReport |
由于retry()和fromPacket()不属于业务相关方法因此只需要在实现类中增加这两个方法，至此我们可以轻松的构建出一个FackeConnection类，并使它能够提供我们所需要的反馈信息，然后将这个伪造的对象用在测试中：
public class FakeConnection implements IRGHConnection
{
public RFDIReport report;
public void connect() {}
public void disconnnect(){}
public RFDIReport RFDReportFor(int id) {return report;}
public ACTIOReport ACTIOReportFor(int customerID) {return null;}
} |
下面我们来写测试
void testNoSuccess()throws Exception{
CreditMaster master = new CreditMaster("crm2.mas",true);
IRGHConnection connection = new FakeConnection();
CreditValidator validator = new CreditValidator(connection,master,"a");
connection.report = new RFDReport(....);
Certificate result = validator.validatorCustomer(new Customer(...));
assertEquals(Certificate.VALID,result.getStatus());
} |
虽然FakeConnection类看起来有点奇怪：它的方法要么是空的要么就简单的返回null。这种情形并不常见。更糟的是，它有一个任何人都可以看到的并随意设置的公共变量。这样一个类似似乎违反了所有的良好准则。但你要看到，实际上并非如此。对于一个用来使得测试可行的类，规则是所不同的。FakeConnection中的代码并非产品代码。它永远也不属于最终投入运行的应用，而只是为了测试工具和测试而诞生。
有了这个fake类我们接下去便可以做更多的相关测试。这就是提高代码可测试性和遇到教难构造的的类的时候所采取的一种方法。若代码设计阶段就将RGHConnection设计为接口，那么在后面的测试中会是测试更加方便，使代码在后期的重构也会更加方便。
本文是在读了《Working Effectively with legacy Code 》第九章，关于在无法将类放入测试用具中时遇到的四种最为常见的问题：
（1）无法轻易创建该类的对象。
（2）当该类位于测试用具中时，测试用具无法轻易通过编译构建。
（3）我们需要用到的构造函数具有副作用。
（4）构造函数中有一些要紧的工作，我们需要感知到它们。
这四个问题在进行单元测试或者接口测试的时候，会对测试工作造成很大的阻碍，这就是一个代码可测性的问题。当遇到这样的问题的时候，有两种方法，第一、强行构建一个类去完成测试，但是这会造成测试的时候大部分工作都耗费在构建这样一个类的过程中；第二、重构代码，使代码具有可测性。本文将通过书中的列子来简单介绍一下如何提高代码的可测性。
如在一个计费系统中，我们有一个未测试的Java类：CreditValidator。
public class CreditValidator
{
public CreditValidator (RGHConnection connection,
CreditMaster master,
String validatorID) {
}
Certificate validateCustomer(Customer customer) throws InvalidaCredit{
}
public class RGHConnection
{
public RGHConnection(int port, String Name, String passwd) throws IOException {
}
}
} |
我们可以看到CreditValidator构造函数含有三个参数RGHConnection，CreditMaster，validatorID。其中RGHConnection对象在构造时会连接到一个服务器，这个链接被用来从服务器上获取必要的信息，以检查客户的余额。
宁一个类CreditMaster，则提供一些我们在检查余额的过程中会用到的策略信息。该类的构造函数会从一个文件中加载相关信息，并把这些信息保存在内存中以备后用。
如果按照我们开头讲的强制构造一个类来完成测试，如下所示：
public void testCreate() throws Exception {
RGHConnection connection = new RGHConnection(DEFAULT_PORT,"admin","rii8ii9s");
CreditMaster master = new CreditMaster ("crm2.mas",true);
CreditValidator validator = new CreditValidator(connection,master,"a");
} |
虽然我们构建一个这个样的类，但是你能忍受这个测试的速度，根据《Working Effectively with legacy Code 》书中提到大于1秒的单元测试，都不叫单元测试。因此在测试中建立到服务器的连接并不是一个好的主意。首先其好事就比较长，况且服务器也并不总是处于服务状态。可想而知RGHConnection是一个令人恼火的参数。我们的设想是：若能创建某种伪造的RGHConnection对象并使CreditValidator相信它是一个真正的RGHConnection的话，就可以避开所有链接的问题了。
首先来看一下RGHConnection所拥有的方法：
RGHConnection
+ RGHConnection(port,name,password)
+ connect()
+ disconnect()
+RFDIReportFor(id:int):RFDIReport
+ACTIOReportFor(customerID:int) ACTIOReport
+retry()
+fromPacket():RFPacket |
看上去RGHConnection中有一些方法是用来处理与连接相关的任务的：如connect、disconnect以及retry。另外还有一些业务方法。因此如果要伪造一个RGHConnection对象的话，那么这个伪造的对象也必须拥有这些方法也能提供一样的信息。
软件测试团队作为软件研发部门的一个组成部分，一度听到的都是软件测试很重要，要重视软件测试。可在当下现实环境中，你有想过软件测试也会拉后腿？！
当研发团队中开发人员资源比较紧缺，而任务比较重，项目比较急的情况下，若全部经过测试组，在软件质量保证的同时，必然出现了软件周期延长，项目上线延迟的问题。倘若测试人员对任务周期安排不恰当，对很早提交的任务进行测试，发现问题让开发人员重新熟悉程序进行解决，又必然占用大量精力和时间。在开发人员原本就很紧张的情况下，加剧了问题的严重性。
这就出现了测试组测与不测的问题。若测试，软件周期太长，影响项目上线和客户使用；若不测，软件质量没保证，影响上线维护和客户使用。这是一个很矛盾的问题。
有一个解决方法，任务开发完直接升级到现场，由开发人员和设计人员进行测试验收。这样测试组干嘛？
为什么会出现这种问题呢？
很显然，开发人员紧缺是个很关键的问题，因为开发人员既要开发代码，也要改代码bug，还要支持现场代码版本等问题。所以开发人员可以不充裕，但是不能紧缺。可能目前还存在开发人员技术水平和业务经验的问题，这也影响了开发速度和开发质量。
另外，说说测试组吧。曾经测试流程出现过问题，测试组在家里测过的程序升级到现场仍会出现不可用。后来改进流程，程序升级至现场测试环境进行测试，增强程序运行环境真实性和程序版本兼容性。现在面临的上述问题，跟测试组本身也有很大关系。
从两方面讲，第一缺乏技术含量。为什么开发人员不能缺，而测试人员可以没有。因为测试人员目前所做的大部分工作可以被开发人员和工程人员所取代，只是不那么全面专业罢了。测试人员没有自己特有的测试技术。有的话可以说是对业务逻辑的测试经验了，但是我仍然认为这不是真正的测试技术。不要怪我讲的这么露骨，我认为这是事实，不用掩饰的。
第二不了解实际需求。尽管工程人员做的测试可能相对没那么全面，但是他们至少比我们更清楚客户的实际需求。他们可以避轻就重的进行测试，这样就可以满足客户使用的主要功能没有问题，其他小问题慢慢解决了。作为测试人员，要尽可能测试全面，不遗漏任何功能点，因为不清楚客户实际会怎么使用。这种方法和思想是正确的，只是在项目中客户群体比较小和使用频度不高的情况下，相对花费了不少时间。
所以这就是一个关于在时间和人员等资源条件限制的情况下，如何做取舍测试的问题。我觉得这都可以开个议题深度讨论了。
众所周知：基本上所有的软件项目到后期必不可少的是fix bug，一个软件在交付客户后或交给测试人员测试时都存在一些程序员意想不到的问题。现在有一些成熟的bug跟踪系统，譬如：bugzero，bugzilla， redmine等等。
解bug是很头痛的问题，一般是以下原因引起的：
（1）设计上的缺陷；
（2）写代码时考虑不周全；
（3）测试人员无中生有；
（4）所依赖的插件，框架本身的缺陷。
第一种情况：最棘手，需要修改程序架构，费时又费力，但是不改又不行总不能要客户该需求，按照你的程序来吧。没办法，改吧。
第二种情况：还好，看看是那里出来问题，改改代码就可以了，但是改完后需要确认一下会不会对其他模块或功能造成影响。一般如果影响很大的话，那就是模块之间的耦合度太高，不是高质量代码，会越改越乱。
第三种情况：
a、撰写需求文档时，对软件需求设计模糊不清，让人产生歧义。譬如在编写需求文档时考虑不周留下让人发挥想象的空间，或前后矛盾。
b、测试人员或者软件开发人员对没有真正理解需求，譬如文化差异导致理解不一致。
c、测试跟你有仇。呵呵。。
第四种情况：
软件越是开发到最后，bug的难度越大。因为这时你对代码一丁点的改动就有可能引发新的bug，这里不管你的设计的如何如何好，模块与模块之间的耦合度如 何如何低，都不可避免。深层次的问题也慢慢暴露出来，那就是你项目依赖的东西，譬如第三方的插件，框架本身的缺陷或者由于对他的不了解造成的误用。这些 bug才是最头疼的。鸡肋鸡肋啊，弃之可惜，用之可悲。
不过，作为一个执着的程序员或软件工作人员，基本的职业道德还是要有的，不能有了难解决的bug就退缩。实际上虽然解决bug学不到新东西，但是还是有好处的：
（1）可以让你更加深入的了解你自己，了解自己一直以来被忽略的“缺陷”。
（2）考验你的耐心和忍耐度，极限。
（3）增加程序员之间的沟通，促进感情交流。
这个要说一下，遇到自己解决不来的bug，可以请能解决的人帮忙看看，有了高人指点也能让自己多学点东西，学的不是这个bug这么解决的，而是人家遇到问题的思考方法为什么比你宽广，找到原因后，你就可以和他一样无所不能了。哈哈。。。
（4）可以在闲暇之余给自己冲冲电。
项目初期和中期都是比较忙的，任务满满的，基本没有闲暇时间。后期就不一样了，bug少的人就可以多一点自己的时间。呵呵，就看你这么利用了。
以上是我对软件项目后期Fix bug的意义的思考，希望对广大软件工作者有所启发。也在此勉励那些不在bug中沉默就在bug中爆发的人，好自为之吧。
2、关于like关键字
对于使用like的查询，需要注意的是只有列的%不在第一个字符索引才可能被使用。以下分别展示了使用like的查询，第一个是索引被使用的，第二个是索引未被使用的。
3、查看索引使用情况
使用以下命令：
如果索引正在工作，那么Handler_read_key 会很高，如果查询中出现Handler_read_rnd_next的值很高，则表明查询低效，索引的应用并不合理。
大批量插入时的SQL语句优化
在大量插入时，尤其是并发插入时，mysql往往要承受更高的负载，使用mysql administortar的健康检查就可以发现，其avg的值相当高，在这种情况下，首先要做的是sql语句的优化，比较下面两个句子，后者的速度比前者要快得多。因为减少大量的连接。
复制内容到剪贴板代码：
在我的一个实际应用中，由于需要经常有数百个并发的插入，我还采用了insert delayed into来取代insert into，前者与后者的区别是在执行插入语句时，数据保存在内存队列中，待数据库空闲时执行，但是会立即返回一个插入成功的信息。使用insert delayed into时需要注意：此时不能使用mysql_insert_id()，因为此时并没有真正插入。对特别重要的数据不宜采用该语句，避免数据以外丢失。
其他杂谈
mysql myisam 表超过4G无法访问的解决
myisam引擎默认是支持4GB，innodb理论上可以到6TB，假设单张表容量超过4GB，可能导致表都无法访问了。可以通过以下命令增加表最大数据量：
MySQL可以说是程序员应用最多的数据库，下面笔者为大家分享MySQL数据库开发当中的一些常识，存储引擎的选择，索引的设计及使用和大批量插入时SQL语句的优化。希望能对大家有帮助。
存储引擎的选择
声明：本文所针对的数据库版本都是MYSQL 5这里我主要针对两种存储引擎进行简单比较分别是MyISAM和InnoDB，首先比较下区别：
1、MyISAM不支持事务，不支持外键，优点是访问速度高，批量插入速度快。假设大量的操作是select、insert，建议采用该存储引擎。但是在我的实际应用中，出现过批量插入过于频繁的时候，当数据量到达一定级别，出现表损坏的情况。
2、InnoDB支持事务处理，但是相对于前者，处理效率低一些，并且其索引及数据也更占用磁盘空间。在存储一些关键数据，并需要对其进行事务操作的时候，我们可以选择innodb，当然，我认为他不应该是访问量太大的。
索引的设计及使用
没有索引的表是恐怖的，除非里头没多少数据，但是怎么设计索引是合理的？恐怕不是所有人都明白，这里简要分析下索引的设计及使用。
1、索引通常是设置where字句中的列，如果你设置select后的列，这是没有任何意义的。当然你需要对某列进行排序，order by后的列也是可以建成索引的。
2、使用唯一索引，主键就是最好的例子，假设你建的索引列，大量都是重复的，例如：性别，那么这样的索引并不会加快搜索速度。至于为什么，请大家自行了解索引的工作原理。
3、只要有可能，就要尽量限定索引的长度，例如索引列为 char（100），在其前10个字符大部分都是唯一的，请设置索引的长度为10，使用短索引可以加快查询速度，并节省硬盘空间。
4、索引的左前缀特性，联合索引实质上也是建立了多个的索引，那么是建立联合索引好还是分别建多个索引好呢？显然前者更好，利用左前缀特性，只要联合索引的最左的列被用到，那么索引都会被使用。
5、当然，最后要说的是，不要过度使用索引，索引越多，插入的速度越慢，尤其到数据量庞大时，同时，大量的索引将耗费很多硬盘空间，造成不必要的浪费。
下面举几个列子来说明索引的使用：
1、联合索引的左前缀
先看索引结构：
user是联合索引的名称，包含3个列，分别是username,order,email。接下来执行以下sql，使用explain命令来分析下运行结果。
在两句sql中，我们可以发现，第一个sql虽然没用上，全部的索引列，但由于使用到了最左端的列，所以，联合索引还是启用了，第二句没有使用到最左的列，所以索引没有使用
安全测试应该是测试中非常重要的一部分，但他常常最容易被忽视掉。
尽管国内经常出现各种安全事件，但没有真正的引起人们的注意。不管是开发还是测试都不太关注产品的安全。当然，这也不能怪我们苦B的“民工兄弟”。因为公司的所给我们的时间与精力只要求我们对产品的功能的实现以及保证功能的正常运行。一方面出于侥幸心理。谁没事会攻击我？
关于安全测试方面的资料也很少，很多人所知道的就是一本书，一个工具。
一本书值《web安全测试》，这应该是安全测试领域维数不多又被大家熟知的安全测试书，我曾看过前面几个章节，唉，鄙视一下自己，做事总喜欢虎头蛇尾。写得非常好，介绍了许多安全方面的工具和知识。我觉得就算你不去做专业的安全开发\测试人员。起码可以开阔你的视野，使你在做开发或测试时能够考虑到产品安全方面的设计。防患于未然总是好的，如果你想成为一个优秀的人。
一个工具，其实本文也只是想介绍一下，这个工具----AappScan，IBM的这个web安全扫描工具被许多人熟知，相关资料也很多，因为我也摸了摸它的皮毛，所以也来人说两句，呵呵！说起sappScan，对它也颇有些感情，因为，上一份工作的时候，我摸过于测试相关的许多工具，AappScan是其它一个，当时就觉得这工具这么强大，而且还这么傻瓜！！^_^! 于是，后面在面试的简历上写了这个工具，应聘现在的这家公司，几轮面试下来都问到过这个工具，因为现在这家公司一直在使用这个工具做安全方面的扫描。我想能来这家公司和我熟悉AappScan应该有一点点的关系吧！呵呵
AappScan下载与安装
IBM官方下载;http://download2.boulder.ibm.com ... 2-AppScan_Setup.exe
本连接为7.8 简体中文版本的
破解补丁；http://www.vdisk.cn/down/index/4760606A4753
破解补丁中有相应的注册机与破解步骤，生成注册码做一下替换就OK了，这里不细说。
AppScan其实是一个产品家族，包括众多的应用安全扫描产品，从开发阶段的源代码扫描的AppScan source edition，到针对WEB应用进行快速扫描的AppScan standard edition.以及进行安全管理和汇总整合的AppScan enterprise Edition等，我们经常说的AppScan就是指的桌面版本的AppScan，即AppScan standard edition.其安装在Windows操作系统上，可以对网站等WEB应用进行自动化的应用安全扫描和测试。
使用AppScan来进行扫描
我们按照PDCA的方法论来进行规划和讨论； 建议的AppScan使用步骤：PDCA： Plan，Do，check， Action and Analysis.
计划阶段：明确目的，进行策略性的选择和任务分解。
1）明确目的：选择合适的扫描策略
2）了解对象：首先进行探索，了解网站结构和规模
3）确定策略：进行对应的配置
a）按照目录进行扫描任务的分解
b）按照扫描策略进行扫描任务的分解
执行阶段：一边扫描一遍观察
4）进行扫描
5）先爬后扫（继续仅测试）
检查阶段（Check）
6）检查和调整配置
结果分析（Analysis）
7）对比结果
8）汇总结果（整合和过滤）
AppScan的工作原理
当我们单击“扫描”下面的小三角，可以出现如下的三个选型“继续完全扫描”，“继续仅探索”，“继续仅测试“，有木有？什么意思？ 理解了这个地方，就理解了AppScan的工作原理，我们慢慢展开：
还没有正式开始，所以先不管“继续“，直接来讨论’完全扫描”，“仅探索”，“仅测试”三个名词：
AppScan是对网站等WEB应用进行安全攻击，通过真刀真枪的攻击，来检查网站是否存在安全漏洞；既然是攻击，肯定要有明确的攻击对象吧，比如北约现在的对象就是卡扎菲上校还有他的军队。对网站来说，一个网站存在的页面，可能成千上万。每个页面也都可能存在多个字段（参数），比如一个登陆界面，至少要输入用户名和密码吧，这就是一个页面存在两个字段，你提交了用户名密码等登陆信息，网站总要有地方接受并且检查是否正确吧，这就可能存在一个新的检查页面。这里的每个页面的每个参数都可能存在安全漏洞，所有都是被攻击对象，都需要来检查。
这就存在一个问题，你领命来检查一个网站的安全性，这个网站有多少个页面，有多少个参数，页面之间如何跳转，你可能很不明确，如何知道这些信息？ 看起来很复杂，盘根错节；那就更需要找到那个线索，提纲挈领； 那就想一想，访问一个网站的时候，我们需要知道的最重要的信息是哪个？网站主页地址吧？ 从网站地址开始，很多其他频道，其他页面都可以链接过去，对不对，那么可不可以有种技术，告诉了它网站的入口地址，然后它“顺藤摸瓜”，找出其他的网页和页面参数？ OK，这就是”爬虫” 技术，具体说，是”网站爬虫“，其利用了网页的请求都是用http协议发送的，发送和返回的内容都是统一的语言HTML，那么对HTML语言进行分析，找到里面的参数和链接，纪录并继续发送之，最终，找到了这个网站的众多的页面和目录。这个能力AppScan就提供了，这里的术语叫“探索”，explorer，就是去发现，去分析，了解未知的，记录。
在使用AppScan的时候，要配置的第一个就是要检查的网站的地址，配置了以后，AppScan就会利用“探索”技术去发现这个网站存在多少个目录，多少个页面，页面中有哪些参数等，简单说，了解了你的网站的结构。
“探索”了解了，测试的目标和范围就大致确定了，然后呢，利用“军火库”，发送导弹，进行安全攻击，这个过程就是“测试”；针对发现的每个页面的每个参数，进行安全检查，检查的弹药就来自AppScan的扫描规则库，其类似杀毒软件的病毒库，具体可以检查的安全攻击类型都在里面做好了，我们去使用即可。
那么什么是“完全测试呢”，完全测试就是把上面的两个步骤整合起来，“探索”+ “测试”；在安全测试过程中，可以先只进行探索，不进行测试，目的是了解被测的网站结构，评估范围； 然后选择“继续仅测试”，只对前面探索过的页面进行测试，不对新发现的页面进行测试。“完全测试”就是把两个步骤结合在一起，一边探索，一边测试。
上图更容易理解：
步骤1：探索（爬行，爬网）
步骤2：真对找到的页面进行测试，生成安全攻击
AppScan扫描大型网站
经常有客户抱怨，说AppScan无法扫描大型的网站，或者是扫描接近完成时候无法保存，甚至保存后的结果文件下次无法打开?；同时大家又都很奇怪，作为一款业界出名的工具，如此的脆弱？是配置使用不当还是自己不太了解呢？我们今天就一起来讨论下AppScan扫描大型网站会遇到的问题以及应对。
什么叫大型网站，顾名思义，网站规模大，具体说是页面很多，内容很全。比如www.sina.com.cn，比如http://music.10086.cn/，都包括上万个页面。而且除了这个，可能还有一个特点---页面参数多，即要填写的地方多，和用户的交互多；比如一个网站如果都是静态页面(.html,.jpg等)，没有让用户输入的地方，那么可以利用，可以作为攻击点的地方也就不多。如果页面到处都是有输入，有查询，要求用户来参与的，你输入的越多，可能泄露的信息也越多，可能被别人利用的攻击点也就越多，所以和页面参数也是有关系的。AppScan声称测试用例的时候，也是根据每个参数来产生的，简单说，如果一个参数，对应了200个安全攻击测试用例，那么一个登陆界面至少就对应400个了，为什么？登陆界面至少有用户名和密码两个字段吧？ 每个字段200个攻击用例。
这个简单吧，还可以更复杂：如果遇到下面的两个地址，那要扫描多少次呢？
http://www.cnblogs.com/fnng/focus/satisfy/file.jsp?id=1
http://www.cnblogs.com/fnng/focus/satisfy/file.jsp?id=2
上面的两个地址有类似的，“？”号以前的URL地址完全一样，”?”号后面带的参数不同，这种可以认为是重复页面，那么对于重复页面，是否要重复测试呢？
这取决于“冗余路径设置”，默认的是最多测试5次；即，这种类型URL出现的前5次，那么就是要测试1000个攻击用例了。
如果再继续修改下：遇到下面的URL呢
http://www.cnblogs.com/fnng/focus/satisfy/file.jsp?id=1&Item=open
http://www.cnblogs.com/fnng/focus/satisfy/file.jsp?id=2&Item=close
每个URL里面都有2个参数，测试的次数就更多了。想象下，如果这个网页里面的参数如果是10个，或者更多的呢？比如很多网站提交注册信息的时候，要填写的内容足够多吧？
要进行的安全测试用例也就随之不断增加…
这是网站规模的影响，还有一个问题，就出在“每个参数，发送200个安全测试用例”这个假设上。这个假设的前提来源于哪里？ 来源于我们选择的扫描规则库。即你关心那些安全威胁，这个需要在测试策略里面选择。同样来参照杀毒软件，你会用杀毒软件来查找一些专用的病毒吗，比如CIH,比如木马；应用安全扫描也是一样的道理，如果有明确的安全指标或者安全规则范围，那么就选择之。这些可能来源于企业的规范，来源于政府的法律法规。就要根据你的理解，在这里选择。
很多时候，我们也很难在最开始的阶段，就把扫描规范制定下来，按照项目经理们的口头禅“渐进明细”，“滚动式规划”，在实践中，更多时候也是摸着石头过河，选择了一个扫描策略，然后根据结果分析，看是否需要调整，不断优化。比如选择默认的“缺省值’扫描策略，对网站进行扫描，发现其”敏感信息“里面会去检查页面上是否含有Email地址，是否含有信用卡号码等，如果我们觉得这些信息，显示在页面上是正常的业务需要， 我们就可以取消掉这些规则，所以扫描规则也很大程度上影响着我们的扫描效率。
单元测试
集成测试
系统测试
程序的常规步骤，但实际的软件生产过程中，这几步骤远远做不到，应视情况而定。
为什么做不到？
这与很多因素有关，如：公司的规模、性质，软件的规模、性质，软件的开发类型（有些只是demo版本），还有一个原因是由以上派生出来的原因，团队的管理制度（有没有强制去做一些友好的步骤，比如单元测试，大家都知道好，为什么都不去做呢？）；
单元测试：
一般研发部门的领导都是要求开发人员编写单元测试代码，因为领导凭着自己的经验能够意识到单元测试的重要性，基本上每个小的功能都要编写单元测试。虽然是测试，也不一定非得在编写完代码之后编写，因为单元测试有其特殊性，在开发某个功能之前，毫无疑问，工程师已经对模块中每个小功能的实现做了详细的思考和规划，一个功能应该怎么实现，心中了如指掌，在这个前提下完全可以预先编写单元测试用例，而且编写单元测试，同时也是全面分析某个功能可能出现的任意bug的过程（这是一次很重要的分析过程，从而会在很大程度上避免一些错误，而在现实中，这种问题出现的太多了，给人的感觉是程序员只是一味地实现功能，而不去考虑功能实现的完整性、健壮性），如此，编写好的程序只要一运行，就能利马知道这段代码的好坏；另外一个好处是，单元测试能“监听”以后开发中的代码改动、模块衔接所出现的大多错误，从而最大程度的避免了新的bug，是这就是磨刀不误砍柴工吧；
集成测试：
以前总是以为书上说的大道理不如实际应用中的经验来的实在，走过一段路后发现，其实不然；我的总结是，当你的成长遇到瓶颈时，理论就开始起作用了，我想说的是“软件工程”里说的内聚与耦合得概念。初学时不理解他的真正含义，如今用到时才感到他的重要性。对于模块的开发者而言，就像要建造一架飞机，程序员的的工作就是生产一个飞机翅膀或者制作一个飞机轮子。假如说你制作的轮子的主要实现还是靠了机身本身的主干结构，而模块本身并没有太多的新东西，只是改改颜色，增加点花纹什么的，可以看出，这个轮不能从飞机身上摘下来，或者摘下来很费劲，并且不能使用，失去了本身的意义；它的核心再机身，而不是轮子本身，又假如你制作的轮子，整个功能的主题都在轮子上，飞机使用时，只需要挂在上去即可，如果飞机不想使用，摘下来换别的即可；这就正好类似程序模块见的内聚、耦合概念，让每个模块在不影响使用的前提下尽量的提高内聚性，降低模块之间的耦合性，这样的好处是，利于模块的重用，方便问题的定位，有利于程序整体结构的工整；（个人认为类的思想也有这样的好处，另外类的一个作用是重用，重用以减少代码量）；在软件测试时，集成测试是耗时最长，重复最多的、最重要的环节；大部分bug再这个阶段被发现，我再测试过程中感受最多的就是，模块之间的耦合性处理的不好，造成了改动一个模块的功能，间接触发其他模块的功能发生错误（没有完整的程序需求和详细设计，是产生这类bug很重要的因素），而且修改时程序员总是很难意识到这类问题的发生，因此也造成了bug定位难的情况。
这个阶段的回归测试，是个比较累人的重复流程，每次程序的改动后，为了避免造成关联模块的bug，改动完后都要进行相关的回归测试，回归的深度基本上设计所有相关模块，因此这种测试，使用自动化测试配合手动测试比较具有实际意义；
系统测试：
程序提交前的最后一轮测试，实际上这轮测试可以想想成工业上的“试车”，就是现场调试。涉及到了程序使用的各个方面，因为是在现场的环境中测试，因此这个阶段测试出来的bug更具有实际意义；一般来说这个环节就是在实际环境中做更复杂的集成测试的步骤，避免出现bug的因素主要是需求的准确性；这个阶段出现较多的bug一般为，网络方面的，一般都会涉及到网络后台、网络的稳定性，而这点在集成测试时往往会忽略。
侃了会老生长谈的东西，大约每个测试人员都不怎么陌生这三个环节，也作了一些规避这些bug产生的研究，避免一些低级bug的产生。然而，现实让人泪奔；
为什么要这样说？（网友）
1、是公司重效益，轻测试
2、程序规模小，不需要系统测试
3、程序员基本没有养成做单元测试的习惯
4、团队管理没有强硬的原则
5、有些程序根本没有需求规格说明书，何谈，需求分析
一般的外包程序，都是简单测试一下，连提交bug的必要都没有，一边测试一边改正（到底这样的程序是否需要做bug管理，我自己也不知道），没有需求规格说明书，没有需求分析；我在想对于开发周期比较小的程序如果做完整的开发测试流程，是否会在时间上得不偿失，因为小程序bug还是相对部较少的。任何流程规则的制定，看来要以现实为依据才是最好的，没必要可以的遵守固有的原则，好用万岁！大型程序，还是需要做完整流程的；
以什么为标准来决定是否需要做bug管理呢？（待答）
成本与质量之间的一个权衡