先说一些在软件测试过程中的一些现象：用例风格的多样和用例设计人员不同的思维习惯，都导致了用例评审、执行、维护一直处于比较困扰的境地。所以一直想总结出一些规范和方法来起到一定的约束作用以降低用例评审、执行和维护的成本。

古语有云：熟能生巧。什么事情做多了总能产生一些“巧”，这些“巧”往往都是体现在一些方法上，好的方法才能产生好的结果。我们公司使用TD来管理软件的开发。下面总结一下我在TD的管理模式下书写用例的一个方法--层进式的书写方法（先这么叫着吧测试老鸟不要笑我），当然这个方法在其他管理模式下可能也有一定的适用性，写出来供大家参考和借鉴。

一.根据设计文档列出测试点。TD中有专门提取测点的部分，刚开始设计用例的时候我就是先把测试点列出到TD的需求提取模块中。先写一遍测试点再书写用例模块去设计用例。对于新人练手来说这样有助于思维的逐步养成，但是当测试人员有了一些设计用例的经验后这种做法的效率就有些低了。当然，先列测试点再设计用例的思路是没有问题的。为了提高设计效率我现在设计用例的时候都是直接到用例设计模块去写测试点。因为TD的用例设计模块是树形的显示结构，这给我们设计用例带来很大的便利。将测试点直接写到用例的题目中，形如：XX系统_XX功能_XX测试点。也就是设计用例时先设计用例题目，用例的题目就是测试点。这样我们一边对照设计文档一边写测试点，测试点写完了用例的整体结构也就出来了。不过要注意，这样写出的用例容易受设计文档的干扰而导致测试用例的不完整，所以之前对文档进行评审。

二.对测试点进行层层挖掘。按照上述方法写出的用例题目数并不能代表用例的最终题目数。以上只是描绘出了用例的主干，还需要对测试点进行层层挖掘。将测试点进一步细化而形成覆盖率更高的用例集合。如：XX系统_XX功能_XX测试点1;XX系统_XX功能_XX测试点2....,有时这样细化的程度还够那就需要继续细化，如：XX系统_XX功能_XX测试点1.1；XX系统_XX功能_XX测试点1.2...这样以每个测试点和子测试点为节点层层展开就形成了一个逻辑性集中、可读性好、便于维护的用例集合了。还要说一下用例的细化程度，这里只提供一个经验值，每个用例题目下的用例数一般维持在3~5个左右为宜（除特殊情况）。这个主要是出于执行和理解的层面来考虑的，具体的数量大家可在日常工作中根据自己的实际情况来考虑。

从事软件测试快两年了，我逐渐感受到设计文档评审的重要性。经常看到课件里的描述--软件在设计阶段引入的问题是最多的，其严重性很高，修改的成本却很低。我们在平时的日常工作中经常会犯错误，那就是太过重视用例的设计与执行。这个也不难理解，我们总是想快速直接的去发现bug来交给程序处理，bug发现的越多我们的价值就越是得到体现。当然这其中也有很多客观的因素，从业人员对游戏业务的了解不足和对项目的不熟悉都导致了这一现象的产生。接下来的结果就是bug很多测试时间紧张，文档反复修改，用例不断维护等等。这对项目的进度和游戏软件的质量有很大的影响。

对设计文档评审的重要性我想不必多说了。那么游戏的设计文档如何来评审呢？下面来谈一下我个人的感受和一些方法。游戏设计文档有很多种类，书写的格式也是因人而异的。但是从整体上设计文档可分成两个层面：一是功能二是逻辑。比如，大部分描述游戏规则的设计文档都是来阐述逻辑的，大部分系统文档都是用来阐述功能的。当然很多情况下都是功能与逻辑的混合，并且功能也是通过逻辑来实现的。这里先加以区分就是为了便于我们在不同的层面上来评审文档。下面阐述一下我的一些方法：

1.询问。问谁，问什么呢？我们在评审文档的过程中应先询问设计人员的设计目的。有些文档的设计目的比较明确不需要问；有些文档的设计目的就比较隐晦了，这个就需要我们向设计人员了解。了解了设计目的，对我们评审文档是有很大帮助的，如果文档的设计目的我们都不清楚谈何评审呢？呵呵，是吧，下面我们就说问的目的。

2.功能评审。我们先了解了设计目的，那么就可以拿设计目的做为一条准绳来评审设计文档中的功能了。评审功能主要是看功能的合理性。如何来评判一个功能是否合理？这个可是很有难度的事情，不过可以先大概的定一个方向：所有与设计目的相悖的功能一般都是不合理的（注意有些功能看似与单个系统的设计目的相悖，但从整体上来考虑却是有其合理性的一面，这个需要我们与策划沟通来了解）。比如，好友系统是用来增加玩家交互方便玩家间沟通的系统，如果设计文档中存在一些不方便玩家交互的功能甚至是阻碍玩家交互的功能，我们就应该及时的通知设计人员。最好都是以建议的形式，并且应该一直保持谦虚诚恳的态度，要尊重设计人员的决定权。

另外，还有一种逆向的推导合理性的方法。我们先把文档的设计目的放到一边。从玩家的角度去感受这些功能带来的感受。如果我们的感受是较好的且感受与设计目的一致，那么说明这个功能设计的很成功是合理的；如果我们的感受一般或是感受不明显并且没有与设计目的相悖的感受，那么说明这个功能设计的一般，也可以认为该功能可以通过；如果我们的感受不好或是与设计目的相悖，那么就说明这个工能设计的不够合理，应该通知设计人员。

3.逻辑推理。人无完人，所有涉及逻辑的地方都有可能出现问题。我在测试过程中就遇到过很多关于防刷和边界的逻辑问题。在这里我要先提及一个概念，就是很多人都把测试思维说成是逆向思维，我总觉得这个说法不太合适，我认为把它描述成正常思维或是发散思维更为合理。废话不多说，那么来说一下我对文档中逻辑推理的一个方法。（其实这些逻辑也可以描述为规则）逻辑是否合理应该从这些逻辑本身出发。首先，所有的逻辑组合起来都是一条条玩家操作的通路，这些通路应该产生正确的结果。所以，当某些玩家操作没有被这些通路所包含时，那就说明有逻辑上的缺失；当玩家的操作没有产生正确的结果时，说明有些逻辑（或是规则）本身不合理（或是错误的）。针对以上情况我们就需要提交bug给设计人员，让他们去补充和完善这些逻辑。

写的差不多了，我也累了。很高兴能拿出一些东西来跟大家分享，欢迎各种鲜花和鸡蛋。最近工作忙，很久没来空间了，自己顶一下！

时间过得真快，这一晃小半年没管理自己的空间了。这段时间说起来比较惭愧，做的总结少了很多。前一段在老大的鼓励下，我把这将近一年的经验整理成了一个ppt在我们测试组的茶话会上给大家做了一次汇报。通过这次总结，我发现自己对测试的理解还是很肤浅的，对一些常用的或者说是应该很熟悉的方法还欠缺全面理解。可能是这段时间积累少了一些的原因吧。测试方法，还是要在下一下功夫，比如白盒测试方法还有一些其他的方法诸如场景法。

我一直都想搞游戏测试的自动化，不过到现在为止还没有深入的了解一款自动化工具。说起这个游戏自动化，实现游戏的自动化操作还是比较容易的，录个脚本就行了。但现在遇到的问题是，既然要自动化操作，还要让脚本有自动识别操作结果的能力，这个实现起来就比较难了。记得以前弄过一个手机自动化测试的脚本，但那个也是没有对操作结果的处理。要是不能识别操作结果还得需要人来观察，这就并不是真正意义上的自动化。前几天测试群里的网友说按键精灵不错，下定决心好好研究一下。

年后公司为了赶项目进度开始加班了，最近感觉个人的时间比较少。我是一个步入测试行业的新人，个人的经验和技术都比较欠缺。尤其是最近我负责的部分开始复杂了，任务难度增加了那么一点，感觉可比之前费力多了。每天头都晕晕的，还有最近老是出问题，比如报错bug、误解文档等等。从前自己总感觉很多问题都是很确定的，但现在却感到有些模糊，有些时候自己很难判定对与错。开始时觉得自己上手很快，但渐渐的感觉自己提升的越来越慢，似乎是进入了瓶颈一样。有些时候感到很无助，我们老大也说过方法不是别人说了你就会用的，只有自己体验过经历过才更深刻。坐等领悟的那一天不符合我的性格，但问题是现在不知道该学些什么，具体的说不知道该从何下手。时间对我来说很有限，是专向发展狠抓测试理论提升的快还是横向发展学开发、学管理提升的快？迷茫中。。。希望我能找到答案。我想起了一个同事的个性签名：a人，现在学什么好呢？；b人，不要问那么多，学就是了。领悟ing。。。

工作忙了就没有时间管自己的空间了。很久没来了，现在每天都在重复一些类似的东西，测试本来就是这样。不过虽然是重复但是在大量的重复中逐渐有了些自己的经验和想法。呵呵，前几天还跟一个同事讨论工作经验的问题，感觉确实是这样，经验这东西是无法传授的，只能靠自己去感悟。不挨一巴掌，记忆就不会深刻。在大量的实践的工作中遇到各种问题，开始的时候像无头苍蝇一样到处乱撞，撞疼了才会懂得哪里是玻璃哪里是门。不多写了，开工。。。

设计了几天的用例，一边做一边修改，现有所领悟，总结如下：

1.将测试需求的详细信息掉出来，找出其中的测试点，将其一一列出；

2.打开将设计好的用例，将用例中已设计的测试点一一列出；

3.将步骤1和2中的测试点相比较，就能明确快速的找出用例中设计测试目标不明确，遗漏测试点，测试目标有偏差的情况。

另外，设计用例的时候最好将测试点也列出来，放在手头，随用随看，减少设计用例时的错误。

找工作的时候以为新进公司的时候只会做一些简单的工做，像执行用例之类的，写用例和测试需求这些处在测试流程前面的部分不会接触到，所以在学习的过程中没有重点看这些知识。但遗憾的是这个天真的想法很快就被证明是错误的。

进公司的第二个星期，组长就给我下达了任务，提取测试需求。我当时就晕了，这是个知识上的漏洞，我看过的教程里只提到过这个步骤，但具体的操作流程没有说明。于是马上打开IE摆渡一下，结果发现大家好象对这个东西都不是很关心，基本上都是提及而已。所以觉得有必要把自己摸索和实践中得到的一些经验和看法记录下来。

测试需求的提取，字面看起来很抽象，但只要实际动过手就会明白这个名称只不过是个纸老虎。需求，当然是指策划文挡或产品需求说明书（内部的详细说明），里面记载了正在开发项目的各种详细的功能。那么怎么从中提取测试需求呢？这个其实很简单。只要策划说明写的比较规范，提取需求就会变成单纯的拷贝，将策划说明书中的功能说明拷贝出来填到测试需求的相应位置就可以了。当然，这还需要一个前提条件，你必须认真仔细的把需求说明看完，把有疑问的地方记录下来，之后与策划人员进行沟通。一定要把疑问弄清楚，究竟是自己理解错了，还是策划文档说的不明白，还是策划文档写错了。把这些疑问都处理好了，并且与策划人员也达成了一致，这样才能开始提取测试需求。策划文档由于受到编写方式的限制，某些功能的说明会比较分散，在填写测试需求的时候不能只将策划文档中比较集中部分的说明填上，还要将文档中所有涉及这一功能的阐述都要补全，要不然在接下来的编写用例的环节就会落掉许多对功能和操作的测试。一旦在编用例的时候才发现测试需求中提取的测试点不全面，那么修改起来就会很麻烦了。所以，提取测试需求时一定要注意这几个方面：完全理解策划文档，把功能和操作（也就是测试点）填写完全。

1、设计用例之前，你必要非常熟悉产品。用产品的每个功能模块与关联要很清楚。
2、更多的去了解客户的需要，有机会多和客户勾通。如果能和客户面对面最好了，客户对产品的要求往往和开发者会有一定的差距。了解业务流你会设计更实际的用例，发现更有意义的BUG。
3、多和组内同事讨论，“三人行必有我师”。即使你再强，你也会有想不到的地方，一个人的力量是有限的。
4、用例的描述，要简要、清晰。因为你设计的用例可能被别人执行、新员工的参考和学习。
5、每个步骤，尽可能多的想到他的关联，但不要冗余（容易理解不容易做）。
6、一个完整的用例应涉及所有的功能与业务需求（需要很周全的考虑）。

测试环境搭建之后，根据定义的测试用例执行顺序，逐个执行测试用例。在测试执行中需要注意以下几个问题：

　　 全方位的观察测试用例执行结果： 测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某测试用例后，测试用例的实际输出与预期输出完全一致，不过在查询 CPU 占用率地时候，发现 CPU 占用率高达 90 ％，后来经过分析，软件运行的时候启动了若干个 1ms 的定时器，大量的消耗的 CPU 资源，后来通过把定时器调整到 10ms ， CPU 的占用率降为 7 ％。如果观察点单一，这个严重消耗资源的问题就无从发现了。

　　 加强测试过程记录： 测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。

　　 及时确认发现的问题： 测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重新问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。

　　 与开发人员良好的沟通： 测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。此外，测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。

　　 及时更新测试用例

　　 测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。

　　 总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。

　　 提交一份优秀的问题报告单

　　 软件测试提交的问题报告单和测试日报一样，都是软件测试人员的工作输出，是测试人员绩效的集中体现。因此，提交一份优秀的问题报告单是很重要的。软件测试报告单最关键的域就是 “ 问题描述 ” ，这是开发人员重现问题，定位问题的依据。问题描述应该包括以下几部分内容：软件配置、硬件配置、测试用例输入、操作步骤、输出、当时输出设备的相关输出信息和相关的日志等。

　　 软件配置： 包括操作系统类型版本和补丁版本、当前被测试软件的版本和补丁版本、相关支撑软件，比如数据库软件的版本和补丁版本等。

　　 硬件配置： 计算机的配置情况，主要包括 CPU 、内存和硬盘的相关参数，其它硬件参数根据测试用例的实际情况添加。如果测试中使用网络，那么网络的组网情况，网络的容量、流量等情况。硬件配置情况与被测试产品类型密切相关，需要根据当时的情况，准确翔实的记录硬件配置情况。

　　 测试用例输入 \ 操作步骤 \ 输出： 这部分内容可以根据测试用例的描述和测试用例的实际执行情况如实填写。

　　 输出设备的相关输出信息： 输出设备包括计算机显示器、打印机、磁带等等输出设备，如果是显示器可以采用抓屏的方式获取当时的截图，其他的输出设备可以采用其它方法获取相关的输出，在问题报告单中提供描述。

　　 日志信息： 规范的软件产品都会提供软件的运行日志和用户、管理员的操作日志，测试人员应该把测试用例执行后的软件产品运行日志和操作日志作为附件，提交到问题报告单中。

　　 根据被测试软件产品的不同，需要在 “ 问题描述 ” 中增加相应的描述内容，这需要具体问题具体分析。

　　 测试结果分析

　　 软件测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的 “ 测试准备工作 ” 中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；然后，再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中，每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下一轮测试用避免盲区。

以下举一考察交互作用的表头设计例子。
例水稻高产栽培试验，其因子、水平如下表。该试验仅考察A、B、C、D、A×B、A×C、B×C；

因子、水平表   (肥料为硫酸铵)

因    子 \ 水    平	品种A	前期追肥B	中期追肥C	后期追肥D
1 2	灵优 秋二A	8斤 16斤	5斤 10斤	7斤 14斤

选用正交表L₈（2⁷）。因为需考察A×B，所以可先把A放在第1列，B放在第2列由L₈（2⁷）交互作用列附表查出A×B在第3列；将C放在第4列，同法查出A×C在第5列，B×C在第6列，最后D只能放在第7列。这样就得到了如下的表头设计：

         水稻高产试验的表头设计

列	1	2	3	4	5	6	7
因子	A	B	A×B	C	A×C	B×C	D

表头设计作好以后，便可列出试验方案，即把安排了因子的列中的数字换成该因子相应的水平，就得到了如下试验表：

水稻高产栽培试验的试验方案表

因子 \ 处理	品种A	前期追肥B	A×B	中期追肥C	A×C	B×C	后期追肥D
1 2 3 4 5 6 7 8	（1）灵优 （1）灵优 （1）灵优 （1）灵优 （2）秋二A （2）秋二A （2）秋二A （2）秋二A	（1）前8斤 （1）前8斤 （2）前16斤 （2）前16斤 （1）前8斤 （1）前8斤 （2）前16斤 （2）前16斤	1 1 2 2 2 2 1 1	（1）中5斤 （2）中10斤 （1）中5斤 （2）中10斤 （1）中5斤 （2）中10斤 （1）中5斤 （2）中10斤	1 2 1 2 1 2 1 2	1 2 2 1 1 2 2 1	（1）后7斤 （2）后14斤 （2）后14斤 （1）后7斤 （2）后14斤 （1）后7斤 （1）后7斤 （2）后14斤

    由以上试验方案表可知，处理1为A₁B₁C₁D₁，即品种用灵优，前期追肥8斤，中期追肥5斤，后期追肥7斤；处理2为A₁B₁C₂D₂，即品种用灵优，前期追肥8斤，中期追肥10斤，后期追肥14斤，其余处理，均可在上表中一一查得。
    作表头设计时，须注意以下几点：
①选择因子的同时，要根据过去的经验和专业知识，初步分析哪些因子之间的交互作用可能较大，需要在试验中加以考察。
②需考察交互作用的试验，要利用两列间的交互列附将各因子及需考察的交互作用分别确定在正交表表头上。
③交互作用所在列，在分析试验结果时要用到它。

特点: 选取有代表性的试验点参与试验，这些试验点均衡分散、整齐可比。因此，有可能从众多的处理组合中选出最优的处理组合。

优点:是一种多、快、好、省的设计方法。通常比全面试验节省人力、物力１／２至３／４以上。

缺点:通常用数学的方法选出的最优处理组合没有出现在参试的处理组合中，给现场示范造成一定的困难，故要进一步做一个参试最优处理组合和用数学的方法选出的最优处理组合作对比试验，作现场示范。

注意事项:正交设计仅是从全面试验中选取有代表性的试验点参与试验的数学方法，而不是田间设计方法。在选取有代表性的试验点（即处理组合）参与试验并写出试验方案之后，要进行田间设计，田间设计可采用随机区组设计或拉丁方设计等。

实例:水稻复因子试验，三个因子（品种、种植密度、用氮量）每个因子两个水平，重复三次,要求考察所有的交互作用，试用正交设计设计该试验。

设计方法名称:正交设计 适用范围:仅用于复因子试验 田间排列:田间排列可采用随机区组设计或拉丁方设计等。 一、为什么要用正交试验？     关于复因子试验我门介绍了随机区组设计和裂区设计两种设计方法、但这两种设计方法均属于复因子试验的全面实施，所成的区组叫完全区组，即每一种处理组合在每一区组都必须设置一个小区。然而，对于农林试验，特别小区面积需较大的热带作物试验，作全面实施往往是不可能的。例如，如欲作肥料三要素试验，每因子取三个水平，则共有27个处理组合。若把试验布置成完全区组，则每区组需设置27个小区。这不仅实际执行时常因地形所限而不易找到如此庞大的区组，即使能找到可摆下27个处理组合的区组也难于实行局部控制。此外，作完全区组设计工作量太大，耗费人力物力也多。为解决以上矛盾，人们提出是否可以从全部处理组合中挑选出一部处理组合来做下完全区组试验，而且要求这种部分实施同样能达到主要的试验目的。理论与实施都证明这是可能的，这就是本节所介绍正交试验法。     进一步的问题是：（1）从全部处理合中应该挑几个处理组合来做试验？（2）从全部处理组合中具体挑选哪几个处理组合来做试验？这两个问题都可以从正交表得到回答。 二、正交表 正交试验，是借助于正交表来布置试验的。因此，首先得搞清楚正交表的含意。比如，需作一A、B、C三因子试验，A分为A1、A2二个水平；B分为B1、B2二个水平；C分为C1、C2二个水平。显然，该试验共有8个处理组合，详列如下：     这8个处理组合，可用数字来简单表示，如A1B1C1可简记为“111”，A1B1C2可简记为“112”等等。这样，如若写出“221”，则表示这是处理组合A2B2C1，。即因子A取A2，因子B取B2，因子C取B1所组成的组合。     如果我们希望把试验布置成正交试验，从8个处理 组合中挑选一部分处理组合来做才有代表性呢？这可查正交表得到回答。二水平的最简单一张正交表是L4（23），转录如下： L4（23） 列号 ＼ 处理号 1 2 3 1 2 3 4 1 1 2 2 1 2 1 2 1 2 2 1 上面的正交表是由下面的设计图产生的.三个因子各有两个水平的试验,共有八个处理组合,正如下图的八个顶点,但如果每个平面取两个点,每条线段取一个点,一次可得四个点,这正是下图的 A1B1C1,A1B2C2,A2B1C2,A2B2C1 四个试验点,这就是上面正交表的来历. 这张表告诉我们，这个试验应该选4个处理组合来做试验，这4 个处理组合就是4个横行所示的数字111，122，212，221.由此可知，L4（23）的含意是：L表示它是一张正交表，括号内的底数2表示参试的每个因子都是二水平的；指数3表示它有3列，即最多能安排三个因子的试验；L右下角的数字4表示它有4个横行。用它来安排试验每区组须设置4个小区．井在这4个小区上随机安排111，122，212，221，这4个处理。二水平的正交表还有L8（27），L12（211），L16（215）等等；三水平的正交表有L9（34），L27（313）等等。此外还有一种混合型的正交表， 如L8（4×24），它表示第1列应安徘四水平的因子．另4列只能安排二水平的因子．共做8个处理组合的试验。 三、如何安排试验？ 安排正交试验，可分为以下两个步骤： 第一步，挑因子、选水平     参试因子的确定，主要依据试验工作者的生产实践经验和试验所具备的条件。要注意的是既不能把所有影响生产的因子都安排在试验中，也不能把重要的因子漏掉。一般以不超过四个因子为好。各因子取几个水平，也要按实际情况来确定。水平取得太少可能考察不周，取得太多又增加试验工作量，一般选2~4个水平为宜。 例如针刺采胶正交试验的因子、水平如下表。作因子、水平表时，各因子的水平可按大小顺序排列，也可以不按大小顺序排列，而且最好不要按大小顺序排列。 因子、水平表 因子 \ 水平 A B C 针刺方式 针刺孔数 采胶制度 1 2 3 直刺 横刺 高低线 4 6 8 1/2树围隔日采 1/2树围隔二日 1/2树围隔三日 第二步，作表头设计 1.不考察交互作用的表头设计     不考察交互作用的试验，一般采用未带交互作用列表的正交表进行设计。如上例若不考察交互作用，可采用L9（34）进行设计。将因子A、B、C分别确定在L9（34）的列上，叫做作表头设计。若将A、B、C分别确定在L9（34）的第1、2、3列上，则得表头设计如表: 　 列 号           1         2         3 因 子 ╲ 处理号      1         2         3 针刺方式　针刺孔数　采胶制度 上面的正交表是由下面的设计图产生的.三个因子各有三个水平的试验,共有27个处理组合, 正如下图的27个交点,但如果每个平面取三个点,每条线段取一个点,一次可得九个点,这正 是下图的A1B1C1,A1B2C2,A1B3C3等九个试验点,这就是上面正交表的来历.        　   根据设计的表头，把正交表中各列的数字1、2、3换成该列上因子的水平1、2、3，便得试验方案表如下： 列 号           1         2         3 因 子 ╲ 处理号      1         2         3 针刺方式　 针刺孔数　 采胶制度 1 2 3 4 5 6 7 8 9 直刺（1） 4孔（1） 隔日（1） 直刺（1） 6孔（2） 隔二日（2） 直刺（1） 8孔（3） 隔三日（3） 横刺（2） 4孔（1） 隔二日（2） 横刺（2） 6孔（2） 隔三日（3） 横刺（2） 8孔（3） 隔日（1） 高低线（3） 4孔（1） 隔三日（3) 高低线（3） 6孔（2） 隔日（1) 高低线（3） 8孔（3） 隔二日（2     上表每一横行都是一个处理 组合，如第6号处理表示采用横刺，8孔，隔日采胶。每区组设9个小区，随机安排上面9个处理。 2.考察交互作用的表头设计 试验如需考察因子间的交互作用，就必须选用附有交互作用列如何安排说明的正交表来安排试验。如L8（27）正交表附有“两列间的交互作用列表”：       1 2 3 4 5 6 7 列号   （1） 3 2 5 4 7 6 （2） 1 6 7 4 5 （3） 7 6 5 4 （4） 1 2 3 （5） 3 2 （6） 1 （7） 1 2 3 4 5 6 7     这张附表是用以查出L8（27）任两列间的交互作用列列名的。如L8（27）第1、2列的交互列，可由表中对角线上的（1）向右横看，同时在对角线上的（2）向上竖看，交叉处的数字“3”即为L8（27）第1、2列交互列的列名（即第3列）。同法可查出第2、4列的交互列是第6列第3、7列的交互列是第4列，等等。     如若选用交互作用列附表的三水平正交表做试验，比加选用L8（27），则其任两列的交互作用列为另外的两列。如欲求L27（213）第1、2列的交互列，则可由L27（213）的“两列间的交互列表”查出是第3列和第4列。同法可查出第5、6列的交互列是第1列和第7列等等.     二水平的正交表任两列的交列作用列为1列并非偶然．这是因为两个二水平因于的交互作用的自由度为1，而二水平正交表每列的自由度也恰好等于1（自由度等于该列水平数减1）的缘故。三水平的正交表，其任两列的交互列为另外两列是因为两个三水平因子的交互作用的自由度为4，而三水平正交表的每－列的自由度为2，因此4个自由度应占正交表的两列。

1 基本信息

        好的测试都是基于模型的。

        由于软件输入空间的无限性，使得测试人员不可能遍历软件的所有输入。其实，遍历软件的所有输入一般也是没有必要的。优秀的测试设计，往往能够从繁多的测试用例中挑选出有效的用例，用尽可能少的测试输入，覆盖尽可能多的软件需求，这离不开合适的测试模型的支持。
所谓测试模型（Test Model）,是测试和测试对象的基本特征、基本关系的抽象。它是测试理论家们根据大量的实际测试应用总结出来的，能够代表某一类应用的内在规律，并对应于适合此类应用的一组测试框架性的东西。

2 组合测试模型

        一种相对简单，并且应用十分广泛的模型是组合模型，具有如下特点：

        1）、输出是由输入变量之间的逻辑关系决定的。
        2）、输出结果不依赖于变量的先后顺序。这一特点是我们理解组合模型的关键。

        对于符合组合模型的输入而言，测试用例设计时要注意：

        1）、考虑输入变量的不同取值以及这些取值之间的不同组合。
        2）、从应用系统中抽象出正确的逻辑表达式，不要遗漏任何一种逻辑组合关系。

        在组合模型中最常用的两种测试技术分别为正交设计技术和组合覆盖测试技术。

2.1 正交设计技术介绍：

        正交实验设计方法:依据Galois理论,从大量的（实验）数据（测试例）中挑选适量的、有代表性的点（例）,从而合理地安排实验（测试）的一种科学实验设计方法。

        采用正交设计法设计测试用例主要包括以下步骤：

        确定影响因素。这里的影响因素指对软件运行结果有影响的软件运行条件，一般情况下是指软件的输入以及其它软件运行的环境。这些因素可以通过对软件需求规格、软件概要设计、软件详细设计等文档分析而获得。
        确定因素的取值范围或集合。因素的取值范围指软件输入的取值范围或集合以及可用的硬件资源。同样，要通过分析软件需求规格等文档获取这些信息。
        确定每个因素的水平。根据因素的取值范围或集合，采用等价类划分、边界值分析等软件测试技术，在每个因素的取值范围或集合里挑选出有效等价类、无效等价类、正好等于、刚刚大于或刚刚小于边界值等有代表性的测试点。例如：对于用下拉框进行输入的字段，下拉框的所有取值都构成了该因素的水平集合。
        选择正交表。根据确定的因素和水平，选择合适的正交表。如果没有合适的正交表可用或需要的测试用例个数太多，则要对因素和水平进行调整。
        设计测试用例。

2.2 组合覆盖测试技术介绍：

        组合覆盖测试技术是一种设计测试用例的方法，它利用组合产生能够覆盖规定组合的测试用例。根据覆盖程度的不同，可以分为单因素覆盖、成对组合覆盖、三三组合覆盖等。这种方法力求用尽可能少的测试用例，覆盖尽可能多的影响因素。

        下面重点讨论成对组合覆盖测试用例的生成方法。

        基本用例选择方法：首先确定出1个基本测试用例，基本用例由每个因素中最重要的水平值组合而成。根据预先定义的标准，如最常用的、最简单的、最小的、最可能使用的等找出最重要的水平值。

        成对组合（Pair-Wise），又称两两组合、对对组合，它是将所有因素的水平按照两两组合的原则而产生的。成对组合覆盖的概念是Mandl于1985年在测试Ada编译程序时提出的。Cohen等人应用成对覆盖测试技术对Unix中的“sort”命令进行了测试，测试结果：模块覆盖率93.5%，判断覆盖率为83%。由此可见，运用成对组合覆盖技术设计出的测试用例具有经济有效的特点。

        假设某功能有3个因素（或者叫输入项），每个因素（输入项）有2个不同的取值，分别为

        【A1，A2】、  【B1，B2】 、 【C1，C2】

        引入成对组合的概念之后，我们可以用成对组合集合来表示通常的测试用例集。对于某个给定的测试用例，它能覆盖一定数量的成对组合元素。例如：

        测试用例（A1，B1，C1）覆盖了（A1，B1），（A1，C1），（B1，C1）3个成对组合元素。
        测试用例（A1，B1，C2）覆盖了（A1，B1），（A1，C2），（B1，C2）3个成对组合元素。

        所谓测试设计，，就是设计出一组测试用例以依之对软件进行测试；显然，不同的测试用例集所覆盖的成对组合元素数量是不同的。在同样大小的测试用例集条件下，覆盖的成对组合元素数量越多，表明该测试用例集的测试效果越好。因此，如何选择测试用例集是一个值得研究的问题。对于上例，有8个成对组合元素需要覆盖，如何从8个候选测试用例中挑选出最少的测试用例，达到100%的成对组合覆盖，选择方案如下：

        【A1，B1，C2】、【A1，B2，C1】、【A2，B1，C1】、【A2，B2，C2】

        通过上面的论述和举例，相信大家已经对这两种模型有了一定的认识，并对每种模型适合什么样的测试需求也有了初步了解。

注：这篇文章中谈到了组合测试的特点，组合测试有它的局限性，我们在实际应用中应该给予重视。不要在方法的使用上出现偏差，带来不必要的麻烦。

用于功能性测试的测试用例来源于测试目标的用例。应该为每个用例场景编制测试用例。用例场景要通过描述流经用例的路径来确定，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。

例如，下图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流 1 和 3），还可能起源于另一个备选流（备选流 2），或者终止用例而不再重新加入某个流（备选流 2 和 4）。




用例的事件流示例

遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：

场景 1 基本流
场景 2 基本流 备选流 1
场景 3 基本流 备选流 1 备选流 2
场景 4 基本流 备选流 3
场景 5 基本流 备选流 3 备选流 1
场景 6 基本流 备选流 3 备选流 1 备选流 2
场景 7 基本流 备选流 4
场景 8 基本流 备选流 3 备选流 4


注：为方便起见，场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。

生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。

例如，假定上图描述的用例对备选流 3 规定如下：

“如果在上述步骤 2‘输入提款金额’中输入的美元量超出当前帐户余额，则出现此事件流。系统将显示一则警告消息，之后重新加入基本流，再次执行上述步骤 2‘输入提款金额’，此时银行客户可以输入新的提款金额。”

据此，可以开始确定需要用来执行备选流 3 的测试用例：

测试用例ID 场景 条件 预期结果
TC x 场景 4 步骤 2 - 提款金额 > 帐户余额 在步骤 2 处重新加入基本流
TC y 场景 4 步骤 2 - 提款金额 < 帐户余额 不执行备选流 3，执行基本流
TC z 场景 4 步骤 2 - 提款金额 = 帐户余额 不执行备选流 3，执行基本流


注：由于没有提供其他信息，以上显示的测试用例都非常简单。测试用例很少如此简单。

下面是一个由用例生成测试用例的更符合实际情况的示例。


示例：



一台 ATM 机器的主角和用例。

下表包含了上图中提款用例的基本流和某些备用流：

本用例的开端是 ATM 处于准备就绪状态。
准备提款 - 客户将银行卡插入 ATM 机的读卡机。

验证银行卡 - ATM 机从银行卡的磁条中读取帐户代码，并检查它是否属于可以接收的银行卡。

输入 PIN - ATM 要求客户输入 PIN 码（4 位）

验证帐户代码和 PIN - 验证帐户代码和 PIN 以确定该帐户是否有效以及所输入的 PIN 对该帐户来说是否正确。对于此事件流，帐户是有效的而且 PIN 对此帐户来说正确无误。

ATM 选项 - ATM 显示在本机上可用的各种选项。在此事件流中，银行客户通常选择“提款”。

输入金额 - 要从 ATM 中提取的金额。对于此事件流，客户需选择预设的金额（10 美元、20 美元、50 美元或 100 美元）。

授权 - ATM 通过将卡 ID、PIN、金额以及帐户信息作为一笔交易发送给银行系统来启动验证过程。对于此事件流，银行系统处于联机状态，而且对授权请求给予答复，批准完成提款过程，并且据此更新帐户余额。

出钞 - 提供现金。

返回银行卡 - 银行卡被返还。

收据 - 打印收据并提供给客户。ATM 还相应地更新内部记录。
用例结束时 ATM 又回到准备就绪状态。


备选流 1 - 银行卡无效 在基本流步骤 2 中 - 验证银行卡，如果卡是无效的，则卡被退回，同时会通知相关消息。
备选流 2 - ATM 内没有现金 在基本流步骤 5 中 - ATM 选项，如果 ATM 内没有现金，则“提款”选项将无法使用。
备选流 3 - ATM 内现金不足 在基本流步骤 6 中- 输入金额，如果 ATM 机内金额少于请求提取的金额，则将显示一则适当的消息，并且在步骤 6 - 输入金额处重新加入基本流。
备选流 4 - PIN 有误 在基本流步骤 4 中- 验证帐户和 PIN，客户有三次机会输入 PIN。

如果 PIN 输入有误，ATM 将显示适当的消息；如果还存在输入机会，则此事件流在步骤 3 - 输入 PIN 处重新加入基本流。

如果最后一次尝试输入的 PIN 码仍然错误，则该卡将被 ATM 机保留，同时 ATM 返回到准备就绪状态，本用例终止。
备选流 5 - 帐户不存在 在基本流步骤 4 中 - 验证帐户和 PIN，如果银行系统返回的代码表明找不到该帐户或禁止从该帐户中提款，则 ATM 显示适当的消息并且在步骤 9 - 返回银行卡处重新加入基本流。
备选流 6 - 帐面金额不足 在基本流步骤 7 - 授权中，银行系统返回代码表明帐户余额少于在基本流步骤 6 - 输入金额内输入的金额，则 ATM 显示适当的消息并且在步骤 6 - 输入金额处重新加入基本流。
备选流 7 - 达到每日最大的提款金额 在基本流步骤 7 - 授权中，银行系统返回的代码表明包括本提款请求在内，客户已经或将超过在 24 小时内允许提取的最多金额，则 ATM 显示适当的消息并在步骤 6 - 输入金额上重新加入基本流。
备选流 x - 记录错误 如果在基本流步骤 10 - 收据中，记录无法更新，则 ATM 进入“安全模式”，在此模式下所有功能都将暂停使用。同时向银行系统发送一条适当的警报信息表明 ATM 已经暂停工作。
备选流 y - 退出 客户可随时决定终止交易（退出）。交易终止，银行卡随之退出。
备选流 z - “翘起” ATM 包含大量的传感器，用以监控各种功能，如电源检测器、不同的门和出入口处的测压器以及动作检测器等。在任一时刻，如果某个传感器被激活，则报警信号发送给警方而其ATM进入安全模式，在此功能下所有功能都暂停使用，知道采取适当的重启、重新初始化的措施。

一 什么是Scrum?

Scrum (英式橄榄球争球队), 软件开发模型是敏捷开发的一种，在最近的一两年内逐渐流行起来。

Scrum的基本假设是：

开发软件就像开发新产品，无法一开始就能定义软件产品最终的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证专案成功。Scrum 将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。

Scrum 开发流程通常以 30 天(或者更短的一段时间)为一个阶段，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部分，开发团队必须尽力于 30 天后交付成果，团队每天用 15 分钟开会检查每个成员的进度与计划，了解所遭遇的困难并设法排除。

二 Scrum较传统开发模型的优点

Scrum模型的一个显著特点就是响应变化，它能够尽快地响应变化。下面的图片使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就迅速降低。


下图是Scrum模型和传统模型的对比：
      

三 Scrum模型

一)  有关Scrum的几个名词

backlog: 可以预知的所有任务， 包括功能性的和非功能性的所有任务。

sprint:一次跌代开发的时间周期，一般最多以30天为一个周期.在这段时间内，开发团队需要完成一个制定的backlog,并且最终成果是一个增量的，可以交付的产品。

sprint backlog:一个sprint周期内所需要完成的任务。

scrumMaster: 负责监督整个Scrum进程，修订计划的一个团队成员。

time-box: 一个用于开会时间段。比如每个daily scrum meeting的time-box为15分钟。

sprint planning meeting: 在启动每个sprint前召开。一般为一天时间（8小时）。该会议需要制定的任务是：产品Owner和团队成员将backlog分解成小的功能模块,  决定在即将进行的sprint里需要完成多少小功能模块，确定好这个Product Backlog的任务优先级。另外，该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。

Daily Scrum meeting：开发团队成员召开，一般为15分钟。每个开发成员需要向ScrumMaster汇报三个项目：今天完成了什么？　是否遇到了障碍？　即将要做什么？通过该会议，团队成员可以相互了解项目进度。

Sprint review meeting：在每个Sprint结束后，这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为４小时。

Sprint retrospective meeting：对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为３小时。

二）实施Scrum的过程简单介绍

1) 将整个产品的backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力物力条件可以完成的。
2) 召开sprint planning meeting，划分，确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的，并不是按人天计算。
3) 进入sprint开发周期，在这个周期内，每天需要召开Daily Scrum meeting。
4) 整个sprint周期结束，召开Sprint review meeting，将成果演示给Product Owner.
5) 团队成员最后召开Sprint retrospective meeting，总结问题和经验。
6) 这样周而复始，按照同样的步骤进行下一次Sprint.

整个过程如下图所示：

需求分析

 

一般而言，需求分析包括软件功能需求分析、测试环境需求分析、测试资源需求分析等。

 

其中最基本的是软件功能需求分析，首测一款软件先要知道软件能实现哪些功能以及是怎样实现的。比如一款Smartphone包括VoIP、Wi-Fi以及Bluetooth等功能。那我们就应该知道软件是怎样来实现这些功能的，为了实现这些功能需要哪些测试设备以及如何搭建相应测试环境等，否则测试就无从谈起！

 

既然谈了需求分析，那么我们根据什么来分析呢？总不能凭空设想吧。做测试需求分析的依据有软件需求文档、软件规格书以及开发人员的设计文档等，相信管理一些规范的公司在软件开发过程中都有这些文档。

因为测试人员在测试阶段主要是根据《需求分析说明书》、《系统设计说明书》编写《测试用例》，再根据《测试用例》对系统进行测试，如果每步的管理人员对其他步骤意图理解不到位常会出现以下错误：
       1、《需求分析说明书》提及的需求在系统设计和编码中无法实现，也就无法测试；
       2、《需求分析说明书》没有没有覆盖客户的需求，导致后期《系统设计说明书》中没有设计，编码阶段无法编码，测试阶段无法测试；
       3、《需求分析说明书》提及的需求《系统设计说明书》中没有设计，以至于后期编码中无法完成需求分析的要求；
       4、《系统设计说明书》中的设计并不是需求分析中的需求，凭空浪费人力、物力、财力、时间；
       5、编码人员没有完成《系统设计说明书》的设计；
       6、编码人员编写了一些没有用的代码；
       7、《测试用例》不能覆盖《需求分析说明书》提及的需求和《系统设计说明书》提及的设计；
       8、测试人员编写了一些没有用的《测试用例》；

       所以，测试人员在需求分析阶段就应该参与进来主要进行以下工作：
       1、测试《需求分析说明书》是否满足客户的需求；
       2、测试《需求分析说明书》中是否有多余的或者在后期无法实现的需求；
       3、完全理解《需求分析说明书》，以便后期纠正各步骤与需求分析之间的偏差，同时能够帮助自己在测试阶段编写出最简洁，最有效的《测试用例》，并进行测试。

 

不要在定义的理解上出错 

一、软件生命周期(SDLC)的六个阶段

1、问题的定义及规划
      此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。

2、需求分析
      在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。"唯一不变的是变化本身。"，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。

3、软件设计
      此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。

4、程序编码
      此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。

5、软件测试
      在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。

6、运行维护
      软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。

最近接触到了一个新的测试阶段——确认测试。它的定义是：确认测试应检查软件能否按合同要求进行工作，即是否满足需求说明书中的确认标准。

不过感觉它在测试的方法还有其所处的阶段和系统测试区别不大，并且有些书中并没有记载确认测试这个阶段。我看了些资料感觉说的都不是很明白。不知道在实际测试中是否存在确认测试，或者说是否将确认测试和系统测试放到一起。希望路过的高手指点一二！

论坛里确实有很多高人。我最近应该多看看大家发的帖子，把写的好的作者加成好友或记下他们的名字，再看看他们发布的一系列帖子。相信肯定会有很大的帮助。所以近期的打算就是找出高手，跟踪学习！

很快我就要开始软件测试的职业生活了。很荣幸有51testing这样的大网站，给广大的软件测试行业的人员提供了一个更为方便的交流空间。在接下来的职业生涯中，我要把我所经历的一点一滴都记录下来。希望我能很快的成长起来，也希望能和更多的同行一起交流、进步！