qileilove

　　作为一位功能测试人员，其主要的职能就是进行测试用例的设计，并根据测试用例执行测试，通过全面的测试来验证产品的质量。因此测试用例也从侧面反映了一个测试人员的测试思路的严密和发散性，要做好功能测试，测试用例的重要性无法忽视。现将本人设计测试用例的流程和思路进行总结，也方便进行交流和探讨：

　　1） 首先要对测试用例的组织结构进行划分

　　如果公司的测试流程还算规范完整的话，在进行需求评审的时候，测试人员就应该根据需求对测试用例的结构进行分类，如果是一个比较大型的管理系统，那么测试用例就可以根据功能模块来进行分类，比如：

　　如果是游戏，就可以根据场景来进行划分，比如：

　　对测试用例的组织结构进行划分的思路，主要根据需求文档的测试切入点来进行参考。

　　2） 根据功能点细致地设计测试用例

　　进行完需求评审后，开发人员会根据需求文档及自己所负责的工作提 交自己的设计文档来进行评审，测试人员可以参考设计文档中的内容提取出各个功能模块中的功能点来设计测试用例，如果是管理模块，首先可以将增删查改功能作 为第一层功能点，然后再根据必填项非空判断、输入格式验证来作为第二层功能点；如果是报表模块，就可以根据各种查询条件来提取功能点。

　　划分好功能点后，就可以利用等价类划分、边界值分析等一些测试方法来编写测试用例，并且可以进行标注，这样对于后期的测试用例整理相当有帮助。

　　3） 执行完一轮测试之后，都要对测试用例进行补充和整理

　 　执行完一轮测试之后，都会对所测试的内容有进一步的了解，并且开发人员在实际开发过程中，会对某些功能的细节部分做出一些修改，测试人员应该根据变更和 熟悉程度对之前编写的测试用例进行完善，主要是对测试步骤的修改和异常情况的补充，提高测试用例对需求的覆盖率，以便能发现更多的BUG。

　　4） 测试结束之后，根据测试用例整理出测试思路进行总结

　　测试结束之后，测试人员在提交测试报告之后一般基本就会有一段短暂的休闲期，在此期间，再看看被自己不断完善的测试用例，根据用例中的标注，可以将之前的测试思路很条理地整理出来，反思有哪些地方考虑不足，这就是经验积累。

　 　做好这些工作之后，在面对领导问你功能测试会测试到哪些功能，会测试哪些情况，执行一轮测试所需的大概时间问题时，测试人员就可以根据自己编写的测试用 例进行流利回答。套用郭德刚的一句词：做科学的人都是很严谨的。大家作为都是有身份证的测试人员，只有工作做得细致严谨，自身的水平才能得到提高。（以上 言论仅代表作者的个人观点，不代表51Testing观点）

　　1.   确认页面的默认排序方式，字段+升降续；

　　2.   含link的列，验证其有效性，即，点击后的跳转是否正确；

　　3.   第一列的选择框，“全选”和“部分 选择”需有效；部分选中时，全选按钮应自动取消。

　　顶部搜索功能：

　　4.   逐个测试每个搜索条件的有效性；

　　5.   做2-3个组合条件的查询，验证结果；合计共有N+3个搜索条件的测试。

　　6.   有时间区间的，验证列表项的开始到结束时间 和 选择区间有交叉，则为有效，且包含所选日期的记录；

　　7.   条件中，开始时间不能大于结束时间；

　　8.   搜索条件，在分页显示时，需始终保持有效；

　　9.   点击名为“显示全部”的按钮，需清除所有条件，并显示所有记录。

　　10.   每一次新的搜索执行，都应该去除分页，显示第一页、并回到进入页面时的默认排序方式。

　　右侧或底部的按钮（按功能分成多个用例）：

　　11.   单选，多选、全选的情况下，点击按钮执行某个功能，如暂停服务、恢复服务的按钮；

　　12.   跨页选择，在一些 选择成员的列表中是应有效的，需进行确认。

　　列表数据的验证：

　　13.   验证从数据库中得到的列表项中每列数据的正确性，要求覆盖不同情况下的值，比如“开通”、“暂停”的服务状态；已使用空间大小和总空间大小等数字的正确性。可考虑结合其他用例来描述，但必须覆盖到。

　　列表按标题的排序：

　　14.   检查每个列标题，要求点击后能按其进行排序：第一次点击为正序，以后每次点击为升、降续的切换。

　　15.   进入下一页、上一页，以及任意分页显示时，条件需始终保持有效。

　　分页：

　　16.   第2页/共8页  每页 10条/共 79条中的 分页数据必须正确；

　　17.   第一页、 上一页、下一页、最后一页的link在当前上下文有意义时显示，否则隐藏或显示为文本标签；

　　18.   填入某个数字，点击“跳转到”按钮，到正确的页数；

　　题目：

　　环境：B/S结构

　　内容：后台，一个文本框，要求输入5-100个长度的任意格式的字符串；要求输入的字符可以在前台正确的显示。请根据需求设计一组测试数据，根据这组测试数据的测试，可以完整把握功能的正常使用。

　　答案：(这答案都有问题 我实在不知到 出这题的人 到底想考验什么 浪费资源成本太多  测试首先先确保基本的功能实现 细节则要在一次次的测试中慢慢优化)

　　长度分别为4，5，6的中文字符串——长度为4不通过，其他通过

　　长度分别为50的中文字符串——通过

　　长度分别为99，100，101的中文字符串——长度为101不通过，其他通过

　　长度分别为4，5，6的英文字符串——长度为4不通过，其他通过

　　长度分别为50的英文字符串——通过

　　长度分别为99，100，101的英文字符串——长度为101不通过，其他通过

　　字符串：<’”&          &”’> ——显示和编辑的时候正常显示

　　字符串： 99个空格+“中中中中中中”——通过

　　字符串：“中中中中中中”+ 99个空格——通过

　　另外，我觉得作为软件测试人员，应该打开思路，逆向思维，这样才可以发现更多缺陷。

　　大多数你可以灵活支配的全部是你自己的知识。我已经在性能测试领域学习和工作8年了，但我几乎每周还一如既往的学习新的性能测试知识，以软件测试为专项去加深和丰富它。有很多性能测试方面的东西需要写成文字形式去记录下来，这也是一个知识积累的主要部分。

　　如果你梦想成为性能测试人员，那么你需要不断的学习。阅读文章、 博客、书籍和工具文档都是一个好的学习开始。参加会议、培训、专题讨论会和类似的小组会等都是一个可以认识一些有相似爱好者的好方式。如果你没有类似的机 会，那么可以加入一些在线的性能测试论坛，以你自己的学习方式，去参与一些发言或讨论，这也是一种和读书类似的很棒的受教方式。

　　没有任 何学习最终能脱离实践。在此我强烈推荐我写的一篇完整的关于实践的文章(在我的博客中可以找到)。很多你阅读的资料中都包含练习，你可以操作一遍。很多你 参与的会议、培训、专题讨论会，都会有例子，你可以重复一遍。即使你已经知道结果了，也要自己去动手操作，这是一种不同类型的学习。当上手实践过后，才能 成为最好的学习者。

　　对于性能测试，我认为开源社区是一个很好的实践学习的地方。考虑到性能测试的性质，大部分测试工具都是互通的，学习 多种开源工具将会给你不同的解决性能问题的思路。很多时候，现有可用的工具会束缚我们着手解决问题的想法，但如果你实践用过多种工具，则你会有多种不同的 途径和解决方案。

　　一旦你知道如何使用多种性能测试工具，如果你不愿意或因为一些机会不得不离开现在的工作岗位而没有测试项目，那么我建议你自己合理安排你的时间。有很多非盈利性质的在线社区或论坛机构可以帮助技术人才提高其自身的能力。所以对于自身的学习，在非测试工作领域和有正式的测试工作一样很有价值。

　　开始推销你的技能和能力

　 　如果你真希望以性能测试为职业，我建议你开始准备一下齐全的推销资料。一份简历就是绝大部分人聚集他们推销自己技能的场所，也是你推销行动开始的地方。 简历中应该讲述给你潜在雇主什么内容呢？你不是一位性能测试人员吗？你的每一段过去的经历怎样帮助你明确性能测试的发展方向呢？请记住，对于性能测试从业 者来说，一个显著的挑战就是它的多样化，这也一定很容易和一个性能测试者的经验技能联系起来。

　　别忘记在你的简历中包含对培训的描述。我 不得不想起有些人有过像参加专题讨论会、在一些在线社区活跃了几年这样的经历，但未将这些经历写入简历，不管这些是否能帮助你展现你的技能，都要写进简 历，而且还应包含一些能够展示给别人关于你对于性能测试的渴望和你在不断的学习等相关的内容。

　　依据你向往的公司类型或你想从事的项目类型，都要有恰当的证明文件。证明是关于性能测试的而不仅仅证明你会使用测试工具。恰当的证明也许来自程序语言的结构（如Java），网络（如CCNA），应用服务器（如WebSphere），数据库（如Oracle），或者甚至是你想从事的工作内容（如 CPCU，如果你想从事保险行业）。通常我不是一个喜欢关注证明资料的人，但他们可以帮助你畅通无阻的推销自己。

　 　最终我认为写作才是推销你自己的最好方式。开始在一些在线社区活跃起来吧，回答一些专题讨论的问题或用邮件方式研讨一下你的思路等等。就像你听说过的， 在你的博客中列出你学习的目录，这样别人也会对你的努力有所了解。当你确实开始了解了一个性能测试的明确方向，那么去尝试写些文章或关于它的文件吧。在一 些讨论会或专题社区介绍给大家你的思想，你会通过这种写的方式变得更公众化，你也会学到更多。我的体会就是，对于你写的文章，别人提出很多反馈信息时，你 会学到更多。即使你不成为下一个性能方面的资深人士，当你的潜在老板搜索到你的名字，他们会很快因看到你拥有性能测试的广泛知识而喜欢你的。

　　融汇你熟悉的项目到性能测试中

　　即使你在当前的工作中没有性能测试项目，你仍然可以把你的项目联系起来。你的团队在做Web Services的测试吗？那么你可以有XML的经验，不同协议和常用专业工具的经验。你的团队在做数据库的测试吗？那么你可以有SQL和管理大型数据库的经验。你的团队在进行自动化测试吗？那么你可以得到设计和处理分布式测试问题的经验。你的团队在做基于风险的测试吗？那么你将会了解一个应用的风险建模或特征，并且让你懂得进行不同的测试会如何做出不同的选择。我还能继续说出更多类似的例子，所以把握住你当前的机会，将他们联系到不同的性能测试知识中。

　　如果你没有自己的性能测试项目，那么试问一下你能和其他人 一起工作吗。你自己的合理时间是什么？如果你在别人的短暂监管下工作是怎么样的？在与当前的经理共事的过程中去了解是什么要素阻止了给你更好的机会，也许 没有给你机会的原因在他们直接管理的范围之外有好几个，也许他们可以给你机会，但他们没有对你有足够的重视。你想试图和他们明晰这些，在和他们谈话之后， 你应该了解在公司中什么样的机会是有价值的。了解到这点，有时你不得不放弃个别的机会，如果这样做了，确信你就清楚了在以后新的工作中你的期望是什么。

相信在测试过程中，大家都会碰到一个费时又枯燥的工作，即“测试输入项可接受的最大长度是否符合需求。”尤 其是当一个新系统刚开发的时候，有大量的字段需要测试。而当众多的新功能需要测试的时候，这个测试点常常优先级不高，测试人员往往只是挑了其中一些重要的 或者偶然碰到的字段进行了测试，有时甚至忘记这档子事了。不幸的是，根据来自生产环境的缺陷报告，我们几乎每个项目都碰到过由于用户输入了超长的字段而产 生的产品缺陷，有的甚至严重妨碍了用户操作。这个差异告诉我们“应该要测试字段的最大长度，而且要用一种更简单易行的办法使得做这个工作的代价较低。”

James Bach在他的网站(http://www.satisfice.com/tools.shtml)上发布了他写的一个小程序Perlclip，可以用来生成一定规律的指定长度的字串，放在windows的剪贴板中，然后你可以粘贴到任何你想要输入的字段中。这是一个适用范围比较广的小工具，如果你还在自己手工输入长串数据，并且用word去计算这个字串的长度。那么建议你至少可以向前走一步，试试James的工具。

有时，我们还需要贪心一点。想想，James工具只能一个一个地准备数据，而把这些数据粘贴到对应的输入框里还是需要手工来做。看数据字典、生成字串、粘贴、提交、验证；看数据字典、生成字串、粘贴、提交、验证。。。如此五步需要大量重复，是否也可以自动化呢？让我们以一个基于ExtJS的web应用为例，借助Sahi这个开源的轻量级web自动化工具，来尝试测试字段最大长度的更省力的办法。

思路1： 从页面元素得到它的长度限制，然后生成一个最大长度的字串和一个最大长度加1（此处用边界值法简化）的字串，进行测试。但困难在于页面元素的长度限制在UI层得不到，只好放弃。

思路2：在整个页面的字段中找到那个允许长度最长的字段，然后以这个最长的长度加1的随机串去填充各个某种特定输入类型（如textbox或者textarea）的所有字段，保存，看是否每个字段都报错。报错时页面应该提示数据非法（所有有长度校验的字段都失败)，且此时失败的字段个数及相应的提示（最大长度是多少）应与数据字典一致。（需要人工检查）如果DB出了异常，我们应该可以从服务器返回的信息或者异常的日志中知道哪个字段出错。

这个思路没有大的问题，但是在我们具体的程序实现技术下碰到了两个问题。一、我们程序的页面上有些list因为也是textbox类型，所以被赋了值非法的长值。这并不是我们想要的，因为它把非法值的校验的和长度的校验揉杂在一起了。所以，我通过数据字典那边只抽出需要校验自由输入的长度的字段来屏蔽这个问题。二、我发现一些系统生成的只读的textbox字段，如某对象的ID，不应该通过我们的Sahi程序将它的值修改掉。还有一些UI不可见的元素，如开发人员设计中特意用到的一些oid，因为也是textbox类型，如果用我们的长字串代替了就会出错。所以我仅仅对UI可见的且非只读的textbox来做。经过上述修正，最后我的方法如下：

准备工作：

1. 准备一个包含两列的excel，第一列是需要验证字段长度的字段名，第二列是该字段允许的最大长度。当然，你也可以准备一个三列的excel，其中多一列字段的类型，以便你既可以生成字串又可以生成数字。

步骤：

1.   打开一个待测试的页面

2.   跑验证字段长度的脚本

a.   将excel中每个页面label对应的textbox都填上excel中指定长度的字符串，然后一起保存。预期结果应该是保存成功（不因为字段长度的校验而失败）。以此方法还可以顺便就把label拼写错误（UI label与数据字典label匹配不上）的情况轻松地暴露出来。

b.   将excel中每个页面label对应的textbox都填上excel中指定长度再加1的字符串，观察系统行为。如果在前台已经做了校验，则观察前台的提示。如果前台不会禁止掉用户的超长输入，则通过保存来提交后台，预期结果应该是保存失败。

1. 需求之内，关注

(1)  需求本身是否正确、完整、无二义性（虽然这一步主要在需求学习阶段进行，但design review发现需求本身问题仍然不算太晚。而且一般此阶段暴露的需求问题也比需求学习时更深入和细致。）（如果是CR，需要从代码角度再次确认是否所有的影响都被分析到了。）

(2)  已经明确的需求是否被正确理解、完整覆盖

(3)  需求上的等价类是否由于设计而不等价了

2. 需求之外，关注

(4)设计时添加的控制字段、mock出来的对象等的具体含义和用法

(5)  是否考虑了非功能性需求，如性能、可用性、兼容性、可扩展性等

(6)  是否考虑了特定技术下的异常情况的处理，如多线程的调度先后顺序、cache的同步等

(7)  设计是否具有良好的可测试性

(8)  设计是否符合通用的设计原则和应用了正确的设计模式

在去之前，我的想法是：

通常来说，有技术含量体现在：1需要有人需要此技术，即此工作有价值；2掌握此技术需要长时间的积累，但单纯长时间也难以掌握此技术；3不是有很多人能做好这个工作  

测试技术含量体现在：

1 测试策略方法需要根据实际情况灵活运用 

2测试工具需要一定专业技能才能掌握，并发挥最大功效

3测试内容包括功能测试、性能测试、安全性测试、兼容性测试、可靠性测试等等，不同的测试要求不同的专业技能和工具 

4对测试软件相关的领域知识的掌握 

5测试对于开发和需求分析的促进和推动

在活动中，主持人对于“知识、技能、技术”的解析让人印象深刻，帮助我更好地理解了技能的内涵。辩论中，认为测试没有多少技术含量的一方虽然看似处在弱势，但实际正方要举例说明有技术含量也颇费脑力。不管大家观点如何，积极探寻测试的价值、方法、技能成为共同的心声。

活动后，大家总结了一下与其他角色对比而言，测试的核心竞争力体现在哪三个方面：

1. 相比其他角色，测试人员需要具备更广的视角,更了解被测系统

2. 作为测试人员的本职工作和核心竞争力，我们需要在测试方面成为专家。比如，在基于风险的测试(以尽可能低的成本在尽可能短的时间内挖掘尽可能多的有价值的缺陷 )方面拥有自主权和高置信度

3. 作为个人，测试人员特别需要的软技能体现在：良好的沟通能力，怀疑精神，强烈的好奇心。。。

单个脚本的数据问题可以这样处理，那么多个脚本之间的数据共享和传递呢？比如，一个系统有两个模块：上游模块A，下游模块B，B的输入是A的输出。这里有一个问题：B的数据怎么创建？有人会马上想到数据传递啊，把A模块的输出写到一个公共变量或者数据表中，B模块从这里拿数据开始自己的执行。是的，这是自动化测试工具提供的功能。可是，如果某次运行，模块A有新的缺陷，造不出B预期的输入数据，会导致B的自动化脚本失败。当我们看到失败后，是否费力排查下来才发现A才是B失败的罪魁祸首？而如果A是成功的（A是否失败要看是否有关于这个缺陷的相关验证），则更具有蒙蔽性，很难快速想到问题可能出在A。这里举的例子还相对简单，若系统中模块间的交互更多、更复杂，数据的问题、脚本的问题、程序本身的缺陷就象几个毛线团缠绕在一起，排查问题的根本原因将耗费大量的人力，并让人沮丧。更有甚者，上游一失效，下游所有相关功能测试全部失败，即使他们本来是没有缺陷的。这样的自动化也太脆弱了，简直和天气预报一样经常误报啊！

如 此看来，测试数据的依赖确实给我们添了不少乱子。那我们是否可以这样做？即使本来两个功能之间有数据的传递，也为每个单独的功能预埋其输入数据（而非依赖 上游在执行过程中产生这样的数据）。这样当一个功能失效后我们能够迅速定位到它。当然，这样做的一个风险就是可能隐藏某模块不能正确产生其它模块希望的正确输出，而这种问题对于用户的端到端的操作是严重的问题。

因此，我建议在多个脚本的测试数据上综合使用以上两种方法。“数据独立”适用于测试不稳定的功能（如新功能），或者容易出错的功能（如老功能中复杂的逻辑），方便查找原因。“数据依赖”适用于测试稳定的功能/接 口或者基本业务流程，有了它的保障，我们对端到端的正确性更有信心。当“数据独立”和“数据依赖”在一次运行中都有时，如果“数据独立”的脚本失败，我们 从“数据独立”的单个脚本开始排查问题；如果“数据依赖”的脚本失败，同时“数据独立”的脚本也在相关处失败，则从“数据独立”的单个脚本开始排查问题， 否则从“数据依赖”的脚本处排查问题。