众所周知,在职场,总有各式各样的报告要看,要写,而最常规的莫过于周报(或者日报)了.这类报告通常是关于个人的工作情况或者项目的进展情况等.那么作为一名测试人员,该如何写周报呢(若有日报需要,以此类推).

2009年悄悄地来到了，送走了艰难的、折腾的2008年。人们对2009年会充满更多的期望，9是一个吉祥的数字，天长地久，而且农历是牛年，牛年更牛。

　　到了2009年，该为软件测试写点什么。顺民意，预测一下2009年国内软件测试的十大热点。

　　1. 基于云的测试将是新的课题，包括测试方法、技术和工具。而且，云环境下的测试也是减少测试成本的一个途径。

　　2. 基于Web 2.0/Ajax 的软件测试技术还是热点。Java/Javascript技术变化很快，系统开发框架也是层出不穷。

　　3. 软件测试自动化也还是热点，包括更多的开源测试工具、自动化测试模型和框架、自动化测试的理论研究等。

　　4. 移动测试：移动计算、移动应用用来，包括3G的应用，移动测试（包括无线应用系统的测试）将会受到更多的关注，是测试的一个新的增长点。

　　5. 虚拟技术（如Citrix、微软、VMware的产品）的日益普及，越来越多的测试团队会将虚拟技术应用于测试环境创建、维护和优化，甚至是测试的执行。

　　6. 安全测试：软件系统安全形势更加严峻，对安全测试会提出更高的要求，软件工具厂商会推出更多的安全测试工具。

　　7. 软件外包测试：中国软件外包迎来发展良机和挑战，大型的软件外包企业发展更快，小的软件外包企业困难增大、被兼并的可能性增大，软件测试在外包企业得到更好的发展。

　　8. 测试培训：软件测试培训的竞争将更加激烈，无论宣传还是市场争夺，将会进入白热化的地步。ISTQB将成为2009年国内培训市场的一颗新星。

　　9. 课程与图书：有越来越多的大学，为研究生和本科生开设“软件测试”课程。软件测试的图书在2008年很热，在2009年热度，可能依旧不减。

　　10. 测试会议和沙龙：全国性或国际性的软件测试会议会成为新的热点之一，软件测试的沙龙越来越多。

如果你想创建一个只包含一个源程序文件的简单程序，那么你只需要编译、连接那一个文件就可以了。如果是一个团队项目组，有着许多甚至上千个源程序文件，那么要创建一个可执行程序的过程就变得更复杂、更耗时。你必须用各种各样的组件将程序逐步建立起来。

在微软或其它一些软件公司中惯例是：每日构造并做“冒烟测试”。每天都对已完成的源程序进行编译，然后连接组合成可执行的程序，并做“冒烟测试”，以简单的检查该执行程序在运行时是否会“冒烟”。

带来的好处

虽然这是一个非常简单的过程，但却有非常重要的意义：

1、能最小化集成风险

项目组可能遇到的一个很大的风险是，项目组成员根据不同的系统功能各自开发不同的代码，但是当这些代码集成为一个系统的时候，也许系统完成不了预期的功能。这种风险的发生取决于项目中的这种不兼容性多久才被发现，由于程序界面已经发生了变化，或者系统的主要部分已经被重新设计和重新实现了，相应的排错工作将非常困难和耗时。极端情况下，集成的错误可能回导致项目被取消掉。每日构造和冒烟测试可以使这种集成错误变得非常小，而且便于解决，防止了很多集成问题的产生。

2、能减小产品低质量的风险

这种风险是和集成不成功、集成出错相关联的。每天对集成的代码做一些少量的冒烟测试，即可杜绝项目中那些基本的质量问题。通过这种方式，使系统达到一种周知的良好状态，维护这样的系统可以防止系统逐步恶化到耗费大量时间排查质量问题的地步。

3、能简单化错误诊断

当系统每天都进行build和测试时，系统任何一天发生的错误都能够变得十分精细，便于排查。比如在17日系统还运行正常，18日就出错了，那么只需要检查这两次build之间的代码变化就可以了。

4、能极大鼓舞项目组的士气

看到产品的不断成长，能够极大的鼓舞项目组的士气，有时甚至不管这个产品到底用来做什么。开发人员可能会为系统显示了一个矩形而感到激动。通过每日构造，产品每天进步一点点，保证项目士气的持续高涨。

进行每日构造和冒烟测试

虽然说这是一个简单枯燥的活，每天进行build，每天进行测试，但也有着一些值得注意的细节：

1、每天坚持

每日构造，最重要的就是“每日”。如Jim McCarthy所说，把每日构造看作是项目的“心跳”，没有“心跳”的话，项目也就死了(Dynamics of Software Development, Microsoft Press, 1995)。Michael Cusumano and Richard W. Selby描述了另外一种隐含的比喻，把每日构造比作项目的“同步脉冲”(Microsoft Secrets, The Free Press, 1995)。 不同开发人员写的代码在他们的“脉冲”之间肯定都会存在“同步”的差异，但是必须有这样一个“同步脉冲”，使得这些代码能够组合为一个整体。当项目组坚持每天把这些不同的“脉冲”组合到一起的时候，开发人员脱离整体的情况就会得到极大程度的杜绝。

有些项目组把这一过程简化为“每周build一次”。这样带来的问题是，某一次build失败后，可能要回溯好几周才能找到原因。如果这种情况发生的话，已经得不到经常build带来的好处了。

2、严格检查每一次build

要保证每一次build的成功，就必须保证build后的结果（也可称为build）是可以正常运行的，如果build不可运行，那么本次build被认为是不成功的，同时应该将修复此次build的工作提高到项目组最高级别来处理。

对于如何衡量一个build，每一个项目组都会定义一些自己的标准，这些标准需要设定一个严格的质量级别来处理那些特别严重的缺陷，同时也需要具有一定的伸缩性来忽略掉那些微不足道的缺陷，一些不适当的关心也许会使整个过程举步为艰。

一个好的build起码应该具备以下条件：

●能够成功编译所有的文件、库，以及其它相关组件；

●能够成功链接所有的文件、库，以及其它相关组件；

●不能存在任何使得系统无法运行或者运行出错的高级别故障；

●当然，必须通过冒烟测试

3、每天进行冒烟测试

冒烟测试应该是对整个系统流程从输入到输出的完整测试。测试不必是面面俱到的，但是应该能够发现系统中较大的问题。冒烟测试应该是足够充分的，通过了冒烟测试的build就可以认为是经过充分测试、足够稳定的。

不进行冒烟测试的build是没有太大价值的。冒烟测试就像一个哨兵，在阻止着产品质量恶化和集成问题的产生，不进行冒烟测试，每日构造可能会变成浪费时间的练习。

冒烟测试必须随着系统的扩充而扩充。最初，冒烟测试可能是非常简单的，比如验证系统是否会打印“Hello World”，随着系统功能的扩充，冒烟测试需要越来越充分。最初的冒烟测试也许只需要几秒钟来执行，逐渐地，测试可能会花费30分钟，1小时，甚至更长。

4、建立一个专门的build小组

在很多项目组，维护每日构造，并更新冒烟测试用例，会耗费一个人工作的大部分时间。因此在一些大的项目中，这项工作独立成不止一个人来完成的全职工作。比如在 Windows NT 3.0的研发中，就有一个由四个全职人员组成的专门的build小组(Pascal Zachary, Showstopper!, The Free Press, 1994)。

5、为build增加修订，如果这样做有意义的话

一般开发人员不会每天都经常向系统中快速的增加实际的代码，通常是每隔几天，他们在开发好完成某个功能的一套代码以后，然后集成到整个系统中。

6、规定一些导致build失败的惩罚措施

很多执行每日构造的项目组都会规定一些惩罚措施，来惩罚那些导致build失败的行为。从最开始，项目组成员就清楚的知道，build的正常执行是项目组的头等大事。一个失败的build是项目组的意外，无法成为项目组工作的准则。必须坚持：导致build失败的同事，必须停下手中的工作，首先来解决build失败的问题。如果一个项目组的build经常失败的话，久而久之的，再来谈build的正确性就没有意义了。

有种轻松的惩罚措施，能够突出解决问题的优先性。Some groups give out lollipops to each "sucker" who breaks the build. This developer then has to tape the sucker to his office door until he fixes the problem. 有些项目组会惩罚犯错的同事戴上山羊角，或者向一个项目基金捐献5块钱。

有些项目组对此的惩罚就有点残酷了。微软的开发人员，在一些知名度很高、很重要的产品如Windows NT，Windows 95，Excel等产品后期研发中，被要求随时带着寻呼机，如果你的代码导致build失败的话，即使是凌晨3点钟，也会要求你立即来处理这个问题。

7、即使在压力下也需坚持每日构造和冒烟测试

当项目进度的压力越来越大时，维护每日构造的工作看起来有些浪费时间，但是恰恰相反。在压力之下，开发人员丢掉一些平时的规定，会采用一些设计和实现的捷径，这在平时压力较小的环境下一般时不会用的。代码的review和单元测试也可能会比平时粗心一些，这些代码的状态变化也会比平时快很多。

为防止这种情况的出现，每日构造会坚持相关的规定，让压力下的项目保持在正轨上。代码仍然每天在不断变化，但是构造过程使得这种变化每天都可控。

谁能够从每日构造这种过程中得到好处呢？一些开发人员会抗议说，由于他们的项目太大，每天进行build是没有实际意义的。但是为什么现在最复杂的软件项目组却能够成功的执行每日构造的制度呢？本文首发时，Windows NT包括了560万行代码、分布在4万个源程序文件中，项目组仍然可以坚持每日构造。

软件测试的种类何其多也，每种测试都有其要达到的目的和实现手段。本文将介绍两种不太普遍的测试类型-冒烟测试与随机测试。

冒烟测试

冒烟测试（smoke testing）,据说是微软起的名字。在《微软项目求生法则》一书第14章“构建过程”关于冒烟测试，就是开发人员在个人版本的软件上执行目前的冒烟测试项目，确定新的程序代码不出故障。

冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板功基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。

冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

在一般软件公司，软件在编写过程中，内部需要编译多个版本(Builds)，但是只有有限的几个版本需要执行正式测试（根据项目开发计划），这些需要执行的中间测试版本，在刚刚编译出来后，软件编译人员需要进行基本性能确认测试，例如是否可以正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等Bug。如果通过了该测试，则可以根据正式测试文档进行正式测试。否则，就需要重新编译版本，再次执行版本可接收确认测试，直到成功。

新版本的基本功能确认检查的测试，有的公司成为版本健康检查(Build Sanity Check)。对于编译的本地化软件新版本，除了进行上面提到的各种测试检查，还要检查是否在新的本地化版本中正确包含了全部应该本地化的文件。可以通过采用文件和目录结构比较工具，首先比较源语言版本和本地化版本的文件和目录中的文件数目、文件名称和文件日期等，这个过程称为版本镜像检查(Build Image Check)。其次，分别安装源语言版本和本地化版本，比较安装后的文件和目录结构中的文件数目、文件名称和文件日期等，这个过程称为版本安装检查(Build Installing Check)。

随机测试

在软件测试中除了根据测试样例和测试说明书进行测试外，还需要进行随机测试(Ad-hoc testing)，主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行样例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。

随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试(Regressive testing)一起进行。

理论上，每一个被测软件版本都需要执行随机测试，尤其对于最后的将要发布的版本更要重视随机测试。随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试。对于被测试的软件越熟悉，执行随机测试越容易。只有不断的积累测试经验，包括具体的测试执行和对缺陷跟踪记录的分析，不断总结，才能提高。

一、为什么做接口测试

　　目前的BS结构的软件层级体系大致如下，对此的功能测试也主要是针对表现层的内容，下图灰色的部分是未测试的内容（占80%的比例）。

　　

　　对于较小型的网站，通过表现层的测试，路径会大致渗透到下面各个层级。但是一个超大型的网站，其层级会有4层甚至更多，每一个层级又可能包含相互关联的不同业务。如同一个城市的自来水系统，如果只测试水龙头里面是否有水，水质是否优良，这显然远远不够。要想点办法对此进行改进，设想如下图。

　　

　　对于底下几层，采用单元测试，持续集成；对于表现层，采用QTP和类似的工具，编写测试代码，设计测试条件，做到大部分的自动化测试。这样以来，测试的覆盖率会大大提升（灰色部分占20%左右）。如此测试，从技术上来看并没有太大的障碍，从成本上来讲，就是需要大批的能写测试代码的技术人员，这些人员的技能丝毫不逊于开发人员，他们需要完成的测试代码量要高于软件本身的代码量。而一旦自动化的功能测试体系建立起来，在软件的重构和发展的过程中，测试的效率会大大提高。一个成熟的测试体系运转起来就像下图所示了。前图是测试的几个纬度，后图是功能测试的几个组成部分。

　　

　　

　　而整个测试的流程大致如下：（其中安全测试是功能测试的一部分）

　　

二、选用什么样的测试工具

　　基于Java技术的软件代码，有一些比较成熟的测试框架，Junit、Dbunit等等。Junit已经有了很长时间的应用，在JDK1.5之后，其推出了基于annotation的Junit4.4版，使单元测试的代码更加简洁，开发人员可以更加专注于对接口中业务逻辑的校验。Dbunit是一个测试数据的框架，它能够使用excel或xml文件里的数据来对数据库做插入，对比，删除等逻辑，可以完成数据的生成和校验。Junit和Dbunit结合使用就可以完成业务逻辑和数据方面的校验。

　　当一个项目的测试代码编写完毕的时候，我们需要对此进行持续集成，业界总是有一些慷慨无私的人来帮助可爱的开发人员，CruiseControl是一个不错的持续集成工具。每当有代码提交到版本管理工具的时候，它都不知疲倦的执行测试代码，通过邮件和IM软件告诉我们，哪些通过测试了，哪些发现问题了。这个时候你可以相当有自信的说“一切尽在掌握”，这神情会比刘德华都要帅。

　　但对于一个大型的网站来说，其单元测试也非测试“helloWorld”一样如此简单，最大的难题是解决代码之间的依赖性。淘宝网主演主要的架构是基于 Spring的，一般的系统分至少三层，业务层、逻辑层、持久层。spring架构下这三层通过配置文件来装载起来，持久层依赖于自己的配置文件、逻辑层依赖于自己的和持久层的、业务层依赖于三种配置文件。如果有发送邮件，调用外部接口等，还需要相应的配置文件和接口服务器。这种情况下，要做一个单元测试，需要配置很多东西，任何一个配置有误都无法启动spring容器，而且这些配置都在xml文件里面，内容是否正确无法自动检测。要做业务层的测试，不是一个容易的事情。其中持久层的东西相对固定，需要配置的文件也较少，相比较而言，这一层测试很容易完成，逻辑层和业务层的测试难度成指数性增长。

　　三、需要什么样的工作流程

　　我们不要提测试驱动开发，或者TDD之类的名词，适合我们的就是最好的，或许我们可以成为测试开发并驾齐驱。接口测试的工程师我们叫做测试开发工程师，在项目启动的时候就要参与进来，要做需求的分析，系统设计，在开发人员编写功能代码的同时，我们在编写测试代码，无所谓谁快谁慢，写好功能代码就测试，或者写好测试代码就写功能实现。当编码完毕的时候，也是接口测试完毕的时候，然后测试开发工程师写一份测试报告，送给功能测试工程师，告诉他们哪些东西我们测试过，哪些东西需要重点关注。

　　

　　当系统发布运行之后，功能修改的时候我们修改测试代码，平时我们就重点关注CruiseControl，一旦它报错，那一定是有些代码出问题了，Just fix it！

　　四、需要什么样的规范

　　Java编码规范想必都比较清楚，OK，去做好它。另外请在注释里面写清楚测试的场景，输入输出，异常情况。测试代码的可读性一定要高于功能代码。

　　五、到底是单元测试还是接口测试

　　OK，看这么多想必都搞糊涂了，我们测的是接口，写的是单元测试的代码，爱叫什么是什么吧。

对“如何提高测试人员在开发、项目管理层及公司中的地位？”谈谈自己的想法：

　　1、纠正常见测试误区，摆脱测试误导：

　　很多软件测试界的误区都必须让项目组成员学习并达成共识，比如说：“测试人员是所有问题的承担者，一旦出现问题那么测试人员就要承担出现问题的责任”。而实际上很多问题并不是测试人员造成的，这就让测试人员很郁闷，自认倒霉，严重打击了测试人员的自尊心和工作激情，解放测试人员弱势地位，对提高测试团队的地位非常必要。

　　2、对高层领导报忧不报喜：

　　对于高层领导，我们一定要揣摩他在做什么、想什么？哪方面是他们特别重视的，我们不妨采取偶尔发送一些邮件的方式。特别是比较紧急的项目，抄送给高层领导的邮件，多报测试出现的问题，看高层领导能不能顶住压力，视而不见，呵呵！！很多时候邮件一发送，领导就来找老大了，哈哈！！对于测试发现问题较少的项目，可以不把测试结果抄送给高层，这也许能够吸引高层领导的眼球哟。

　　3、让公司管理层看到测试带来的价值：

　　偶在公司的领导，以前不是很重视测试。我去公司的前一年，公司由于发布的版本存在缺陷，一次导致公司赔付客户200多万，公司领导被洗脑，终于醒了，开始重视测试了，呵呵！！！让公司上级对测试有高度的重视，这样开展工作就有了坚实的后盾，提高地位不在话说。

　　4、测试人员的自身自信心问题：

　　作为测试人员，一定要对自己测试的结果，充满自信，很多时候和开发人员讨论时，底气不足，自己都看不起自己，拿不定主意，总觉的低人一等，何谈提高测试人员的地位呢？

　　版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。

　　本文出自51Testing软件测试网，感谢会员爱吃鱼的月亮在每周一问（08-09-15）中的精彩回答。
　　http://bbs.51testing.com/forum-157-1.html

　　5、测试人员如何赢得开发人员的尊重：

　　唉，项目一启动，测试和开发就是天生的一对冤家。个人觉的开发人员大多比较单纯，经常把个人的技术实力作为衡量一个人价值的标准，高水平的测试人员（如测试人员掌握开发人员不掌握的技能，比如说性能测试知识和安全测试工具）很容易赢得开发人员的尊重。相信一句话：“最好的测试人员是能够说服开发人员修改 BUG最多的人”。如果作为一个测试人员真的想提高自己的地位，就不要把、开发和测试对立起来，要把他们融合在一起才对。

　　6、选择威望较高人作测试Leader：

　　测试Leader作为部门的领头羊，在公司中一定要有较高的威望，懦弱的测试经理不但自身难保，何谈说话的份，其它部门的组员不卖你的帐，也不是什么大惊小怪的事。古人曰：上梁不正下梁歪吗？还有一点，对测试漏测或遗留问题进行逐一排查，让事实说话，证明出了问题不单是测试的失职，带领测试人员摆脱受“开发人员”约束的弱势地位。只要能通过这条道路，你将比一般开发人员更具有话语权。

　　7、提升测试团队的集体智慧：

　　很多时候，由于测试人手不够，测试人员介入时间比较短，对需求了解比较少。加之测试部门缺乏快速上手的测试高手，包括测试环境的搭建过多的依赖开发人员，久而久之，开发人员就觉的测试人员一无所知，地位自然不高。最佳的方法是集中测试团队的智慧去解决测试中碰到的问题，保持测试团队的独立性，尽可能在部门内部解决全部的测试问题，开发人员自然不敢小看。

　　8、提高测试的技术含量：

　　往往测试给人的印象是用用软件、点点鼠标这样的重复机械的工作，技术含量较低。要是像自动化测试、性能测试和安全测试这种比较复杂的测试，项目组成员对工具方面懂得比较少，了解比较少，自然不敢怠慢，呵呵！！！还有一个主意，就是介入单元测试，和开发人员一起讨论代码一级的问题，你说他们还敢小看测试吗？

　　9、测试人员的准确定位：

　　测试人员应该是发展成为一个设计测试的技术人才，尽可能的把测试用例写得简单易懂，具备较强的操作性，如：让接受过一些培训的高中生都能做测试， 并把一部分功能用自动化来替代手工测试。那你设计的测试用例就比较牛了。

　　10、测试组常给项目组提有价值的建议：

　　一个公司赋予每个部门的权力是平等的，可是很多时候，测试人员在并不了解测试需求和业务的情况下，在项目会上提了一大堆没有价值的意见，很多都被否决，久而久之，大家都有看法了。个人建议：没有价值的提议最好选择沉默。要是项目会上很多有价值的建议，大多都来至测试部门你说谁还干小看测试部。

 

记录今天学到的几点,如何设计一个好的测试用例:

- 用尽可能少的case发现尽可能多的问题,这样的case才是好case;

- 一个流覆盖尽可能多的检查点,无法覆盖到的支流另写一个新的case;

- 以数据流为检查的核心,及主流;关注数据的insert/update/save;

- 一个步骤对应一个检查点的期望结果,切误将多个期望结果并入一条;

- 期望结果中不应出现操作步骤,同样,步骤中不应出现期望结果;

- 表达语句尽量简单,易懂;

如有好的方法,继续更新.

设计测试案例的时候，需要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。测试用例设计一般包括以下几个步骤：

1、测试需求分析

从软件需求文档中，找出待测试软件/模块的需求，通过自己的分析、理解，整理成为测试需求，清楚被测试对象具有哪些功能。测试需求的特点是：包含软件需求，具有可测试性。

测试需求应该在软件需求基础上进行归纳、分类或细分，方便测试用例设计。测试用例中的测试集与测试需求的关系是多对一的关系，即一个或多个测试用例集对应一个测试需求。

2、业务流程分析

软件测试，不单纯是基于功能的黑盒测试，还需要对软件的内部处理逻辑进行测试。为了不遗漏测试点，需要清楚的了解软件产品的业务流程。建议在做复杂的测试用例设计前，先画出软件的业务流程。如果设计文档中已经有业务流程设计，可以从测试角度对现有流程进行补充。如果无法从设计中得到业务流程，测试工程师应通过阅读设计文档，与开发人员交流，最终画出业务流程图。业务流程图可以帮助理解软件的处理逻辑和数据流向，从而指导测试用例的设计。

从业务流程上，应得到以下信息：

A、                   主流程是什么

B、                   条件备选流程是什么

C、                   数据流向是什么

D、                   关键的判断条件是什么

3、测试用例设计

完成了测试需求分析和软件流程分析后，开始着手设计测试用例。测试用例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等。在用例设计中，除了功能测试用例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。

黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜测，白盒测试的测试用例设计方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里主要讨论黑盒测试。在设计测试用例的时候可以使用软件测试用例设计方法，结合前面的需求分析和软件流程分析进行设计：

功能测试：测试某个功能是否满足需求的定义，功能是否正确，完备。

适合的技术：由业务需求和设计说明导出的功能测试、等价类划分

边界测试：对某个功能的边界情况进行测试。

          适合的技术：边界值划分

异常测试：对某些功能来说，其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生的，类似这样的情况需要书写相关的异常测试。

          适合的技术：由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值分析、内部边界值测试、

性能测试：检查系统是否满足在需求中所规定达到的性能，性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包括响应时间，吞吐量等。

         适合的技术：业务需求和设计说明导出的测试

压力测试：压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力，比如说给一个相当大的负荷或网络流量给应用软件兼容测试：测试软件产品在不同的平台，不同的工具，相同工具的不同版本下功能的兼容性。

         

4、测试用例评审

测试用例设计完成后，为了确认测试过程和方法是否正确，是否有遗漏的测试点，需要进行测试用例的评审。

测试用例评审一般是由测试leader安排，参加的人员包括：测试用例设计者、测试leader、项目经理、开发工程师、其它相关开发测试工程师。测试用例评审完毕，测试工程师根据评审结果，对测试用例进行修改，并记录修改日志。

 

5、测试用例更新完善

测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。测试用例是“活”的，在软件的生命周期中不断更新与完善。

对于一个测试人员来说测试用例的设计编写是一项必须掌握的能力。但有效的设计和熟练的编写却是一个十分复杂的技术，它需要你对整个软件不管从业务还是从功能上都有一个明晰的把握。

一、问题：

许多测试类书籍中都有大幅的篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图等。但实际应用中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法有效的提高测试效率。有时我们只有依靠以前项目的用例编写经验（或习惯），希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。

当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地：

l         从此几乎很少被执行

l         已经与程序的实现发生了冲突（界面变动，功能变动）

l         执行用例发现的bug很少

l         根本没有时间为新的功能需求增补用例

l         有时间补充，但用例结构越来越乱，

l         特性的用例与通性用例之间联系不明确（以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化）

l         知道怎样执行这个用例，但它要说明什么呢？（多数用例给我们的感觉是只见树木，不见森林，只对某一功能，无法串起）

通过上面的一系列问题可以看到，似乎测试用例给我们带来的问题远多于益处，也正是因为在实际过程中遇到的问题积累，导致我们有很充分的理由忽视或拒绝用例的应用。

但没有用例或简略用例的编写我们又会舒服很多么？不言自明，谁也不想倒退发展吧。

二、原因：

事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现，究其原因我认为有如下几点：

1、没有适合的规范

“适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题，通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、书本上的定义，但它适合我们当前的项目么？

每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好？

在测试论坛中常能看到介绍用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范？于是我们只得选择从书本或之前的用例中复制，不管是结构还是方式都依赖于以往·的经验，我并不是说这样就是错误的，但不能总结成文的经验无法给予测试更多帮助。

我们有太多经验，但却没有形成适合的规范。

2、功能与业务的分离

我们知道怎样列举一个输入框的用例，但却很少考虑说明这个输入框是用来做什么的，如果仔细分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。

边界值、等价类划分、因果图，这些用例方法是一种高度提纯的方法，本身就很偏向于功能及代码，所以怎样编写业务的用例我们就从理论上失去了参考。

复杂的业务会贯穿于整个软件，涉及众多功能点，里面组合的分支更不可胜数。测试用例务求简洁、明确，这一点也与业务“格格不入”。功能用例依赖程序界面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的bug是最多的，但我们却无法使这个bug对应到一个用例中（点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体）。正因为我们没有很好的积累业务上的用例，才使得我们感到执行用例时发现的bug不多。

用例结构的划分一定程度上也造成了功能和业务的分离，依照界面模块建立文件夹，并在其中新建不同用例，这使得用例从结构上就很难联通起来。

3、测试未能跟上变化

变化！想象一下，当我们越来越多的听到开发人员在那里高呼“拥抱变化”“敏捷开发”的时候，测试又有什么举措呢？当地区特性，软件版本越来越多的时候，测试是否在积极响应呢？变化是我们面临的最大挑战，我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。

对需求和程序的变化测试人员的感受是非常深的，测试总是跟在需求和开发后面跑，使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的工作：尽快投入测试，尽快发现bug，而非从整体把握软件的质量情况，统筹策略。

疲于应对的直接影响就是程序质量无法准确度量，进度无法控制，风险无法预估。用例与程序脱节，新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例，甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要，没有测试数据的保留，测试步骤和重点无法体现，新加功能与原来的程序逐渐“脱离”，可能还会出现相互违背的情况，但这我们却无法很快发现。

永远是变化决定我们的下一步工作，这也是混乱的开始。

三、可能的解决办法：

在这里我希望以探讨的方式提出一些可能的解决办法，因为上面的问题也许在成熟的公司和项目组内很少遇到，而遇到问题的也需根据不同的情况单独考虑。不用拘泥形式，最适合的就是最好的。

1、测试驱动开发，用例指导结果，数据记录变化

“测试驱动开发”（TDD）是一个比较新的概念，在网上可以看到很多介绍文章，它主要讨论如何让开发的代码更奏效（Work）更洁净（Clean），“测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码”。可以看到，TDD是建立在“代码”级别的驱动，但目前我们需要探讨的问题是怎样在黑盒测试中做到“测试驱动开发”。

首先我们需要纠正一个态度，很多人认为黑盒测试的技术含量不高，可思考可拓展的内容不多，主要的工作就是用鼠标在那里瞎点，于是很多“高级”的技术方法都试图与黑盒测试划清界限。但测试人员发现的bug有80％以上都是黑盒测试发现的，手工操作软件仍是目前检验软件质量最有效的一种方法。

如何在黑盒测试中做到测试驱动开发？我认为可以从用例级别做起，以业务用例指导过程和结果。

开发人员通常比较关注技术，对于业务上的理解容易忽视并出现偏差，而需求文档又不会很明确的指出应该实现怎样的结果，这使得从业务到功能出现一个“阅读上的障碍”，如果最后程序错误了还需返工，这样耗费的人力物力就非常大了。使用业务用例驱动开发，就是一个比较好的方法，同样这也需要运用测试中的各种方法，列举出业务流程里数据的等价类和边界值。

业务用例的构造要先于程序实现，与需求和开发人员沟通一致，并以此作为一个基准，保证程序实现不会错，还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面，但一定要有数据的支持。这就是测试主导变化的另一点“数据记录变化”。

我们不仅要应对变化，还要记录变化，使测试用例成为对程序持续性的监控，数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段（业务段与程序中以窗体或页面的划分是不一样的），使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享，最理想的情况就是建立一个“数据库”，每个业务用例都从“数据库”中取得输入数据和预期结果，这个数据只是针对业务入口和出口的，当程序内部设计变更时，保留的数据不会因此而作废。举一个例子，例如我的程序要从某种文件中读取数据并计算结果，一段时间后程序内部字段增加了，如果是以保存的文件附件方式提供数据，则现在程序很可能就打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入，而不关心程序内部结构。

再进一步的话“数据库”就开始涉及到程序内部的接口了，这需要开发人员的配合。

2、为用例标明时间（版本）和优先级

为测试用例标明时间或版本可以起到一种基准的作用，标明项目进度过程中的每一个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流程，也是对变更的一种确认和控制。或者可以为用例增加一个状态，指明这个用例目前是否与程序冲突，当程序变更时改变用例的状态，并更新用例版本。

为测试用例标明优先级可以指出软件的测试重点、用例编写的重点，减少用例回归的时间，增加重点用例执行的次数，帮助项目组新人尽快了解需求，在自动化测试的初期也可以参考这个优先级录制脚本。

3、功能用例与业务用例分开组织

将功能用例与业务用例分开组织，按照不同关注点列举执行路径。业务用例应在开发前或同期编写，帮助测试人员和开发人员明确业务，了解正确流程和错误流程。功能用例更依赖于程序界面的描述，但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug，也许与业务无关，但用户往往很容易这样操作（例如登录名，你是否考虑到很长的名字，或者用户的键盘有问题，总是敲入n多空格在里面，这与业务无关，但程序将会怎样处理？）。

4、审核用例，结对编写

测试组长或经理对用例进行审核可以做到用例的补充和校对，但一般情况下是很难做到的，我们可以采用另一种方法，就是结对编写测试用例（前提是你有两个以上的测试人员），内部审核。

测试用例不是一个人编写一个人执行，它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”，同时也能拓展思维，加强测试重点的确认，小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理，提高组员的参与积极性。

四、发展

上面的这些解决方法只是一种建议，具体怎样实施到项目中还需根据情况而定。可以看到测试的发展方向是很多很广的，传统的黑盒测试并不是毫无新意，测试工作怎样适合我们而发展，将给予我们更多的思考。

   Test Case ID:

　　用来标记测试用例的编号，这个编号必须是唯一的

　　测试描述:

　　用来描述你将要进行的测试是怎样实施的

　　修订历史:

　　为了明确测试用例由谁创建或者修改，所以每个测试用例都应该有其修订历史

　　功能模块:

　　测试功能模块的名字

　　测试环境:

　　用来描述你的测试环境，当然包括硬件环境和软件环境

　　测试准备:

　　测试之前除了你所测试的程序之外还应该准备的东西，如打印机，网络等等

　　测试执行:

　　用来详细描述你的测试步骤

　　期望结果:

　　The descrīption of what you expect the function to do.描述该功能所要实现怎样的结果

　　实际结果:

　　通过/失败

　　如果成功——纪录实际运行的过程

　　如果失败——描述你观察到的现象，这将有利于发现Bug的起源

　　一个很好的测试所应具有的特征:

　　发现Bug的几率很大

　　没有多余

　　不是太简单也不会太复杂

　　Ps.当你的期望结果有很多的时候，测试用例就会变得很复杂

对于每一个Tester来说都是不可避免的，平时很一部分的工作内容就是编写测试用例，如何写一个好的用例呢？如果你的用例只是用于ISO的审核，那没必要再这里探讨这个问题。好的Case，是Tester的劳动成果，它应该是充满智慧的，具有可复用性，启发性，能充分体现一个Tester的水平。很多人的Case虽然写的很不错，可惜只有他自己才能看懂其中的内容和体会Case的意思，为什么？因为它写的Case描述不清楚，只有他自己看了才明白，一个好的Case必须有良好的书写格式与习惯，能让所有看的人都能理解，也就是说，当你离开这个项目，其他人来接受你的工作时，只要看你的Case就能明白项目的目标与需求。如果做到这一点呢？    

界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。
    目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。
      
        1：易用性
按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。

易用性细则：
1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。
2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
3):按功能将界面划分局域块，用Frame框括起来,并要有功能说明或标题。
4):界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。
5):界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。
9):可写控件检测到非法输入后应给出说明并能自动获得焦点。
10):Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。
11):复选框和选项框按选择几率的高底而先后排列。
12):复选框和选项框要有默认选项，并支持Tab选择。
13):选项数相同时多用选项框而不用下拉列表框。
14):界面空间较小时使用下拉框而不用选项框。
15):选项数叫少时使用选项框，相反使用下拉列表框。
16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。

         2：规范性
通常界面设计都按Windows界面的规范来设计，即包含“菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单”的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢。

规范性细则：
1):常用菜单要有命令快捷方式。
2):完成相同或相近功能的菜单用横线隔开放在同一位置。
3):菜单前的图标能直观的代表要完成的操作。
4):菜单深度一般要求最多控制在三层以内。
5):工具栏要求可以根据用户的要求自己选择定制。
6):相同或相近功能的工具栏放在一起。
7):工具栏中的每一个按钮要有及时提示信息。
8):一条工具栏的长度最长不能超出屏幕宽度。
9): 工具栏的图标能直观的代表要完成的操作。
10):系统常用的工具栏设置默认放置位置。
11):工具栏太多时可以考虑使用工具厢。
12):工具厢要具有可增减性，由用户自己根据需求定制。
13):工具厢的默认总宽度不要超过屏幕宽度的1/5。
14): 状态条要能显示用户切实需要的信息，常用的有：
目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提示。
15):滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。
16):状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
17):菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感。
18):菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。
19):右键快捷菜单采用与菜单相同的准则。

        3：帮助设施
系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。

帮助设施细则：
1):帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明，让人困惑)。
2):打包新系统时，对作了修改的地方在帮助文档中要做相应的修改。
3):操作时要提供及时调用系统帮助的功能。常用F1。
4):在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
5):最好提供目前流行的联机帮助格式或HTML帮助格式。
6):用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
7):如果没有提供书面的帮助文档的话，最好有打印帮助的功能。
8 ):在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。
        4：合理性
屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。

合理性细则：
1):父窗体或主窗体的中心位置应该在对角线焦点附近。
2):子窗体位置应该在主窗体的左上角或正中。
3):多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
4):重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。
5):错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点位置。
6):与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。
7):对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
8):非法的输入或操作应有足够的提示说明。
9): 对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
10):提示、警告、或错误说明应该清楚、明了、恰当。

        5：美观与协调性
界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。

美观与协调性细则：
1): 长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
2): 布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。
3): 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
4): 按钮的大小要与界面的大小和空间要协调。
5): 避免空旷的界面上放置很大的按钮。
6):放置完控件后界面不应有很大的空缺位置。
7): 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
8): 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。
9): 如果使用其他颜色，主色要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
10): 大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
11): 界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
12): 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。
13):对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。
14): 通常父窗体支持缩放时，子窗体没有必要缩放。
15):如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。

        6：菜单位置
菜单是界面上最重要的元素，菜单位置按照按功能来组织。

菜单设测试细则：
1):菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
2):常用的有“文件”、“编辑”，“查看”等，几乎每个系统都有这些选项，当然要根据不同的系统有所取舍。
3):下拉菜单要根据菜单选项的含义进行分组，并切按照一定的规则进行排列，用横线隔开。
4): 一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
5): 没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头， 不常用的靠后放置；重要的放在开头，次要的放在后边。
6): 如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。
7): 菜单深度一般要求最多控制在三层以内。
8): 对常用的菜单要有快捷命令方式，组合原则见8。
9):对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式——即只有需要的菜单才显示——最好。
10):菜单前的图标不宜太大，与字高保持一直最好。
11):主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
12)：主菜单数目不应太多，最好为单排布置。

       7：独特性
如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。

独特性细则：
1):安装界面上应有单位介绍或产品介绍，并有自己的图标。
2):主界面，最好是大多数界面上要有公司图标。
3):登录界面上要有本产品的标志，同时包含公司图标。
4):帮助菜单的“关于”中应有版权和产品信息。
5):公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。

        8：快捷方式的组合
在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些 在西文Windows及其应用软件中快捷键的使用大多是一致的。

细则：
1):面向事务的组合有:
Ctrl-D 删除 ；Ctrl-F 寻找 ；Ctrl –H替换；Ctrl-I 插入 ；Ctrl-N 新记录 ；Ctrl-S 保存 Ctrl-O 打开。
2):列表:
Ctrl-R ，Ctrl-G定位；Ctrl-Tab下一分页窗口或反序浏览同一页面控件；。
3):编辑:
Ctrl-A全选；Ctrl-C 拷贝；Ctrl-V 粘贴；Ctrl-X 剪切；Ctrl-Z撤消操作；Ctrl-Y恢复操作。
4):文件操作:
Ctrl-P 打印；Ctrl-W 关闭。
5):系统菜单
Alt-A文件；Alt-E编辑；Alt-T工具；Alt－W窗口；Alt－H帮助。
6):MS Windows保留键:
Ctrl-Esc 任务列表 ；Ctrl-F4 关闭窗口； Alt-F4 结束应用；Alt-Tab 下一应用 ；Enter 缺省按钮/确认操作 ；Esc 取消按钮/取消操作 ；Shift-F1 上下文相关帮助。
按钮中：
可以根据系统需要而调节，以下只是常用的组合。
Alt-Y确定(是)；Alt-C取消；Alt-N 否；Alt-D删除；Alt-Q退出；Alt-A添加；Alt-E编辑；Alt-B浏览；Alt-R读；Alt-W写。
这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。

        9：安全性考虑
在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。

安全性细则：
1):最重要的是排除可能会使应用非正常中止的错误。
2):应当注意尽可能避免用户无意录入无效的数据。
3):采用相关控件限制用户输入值的种类。
4):当用户作出选择的可能性只有两个时,可以采用单选框。
5):当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
6):当选项特别多时，可以采用列表框，下拉式列表框。
7):在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
8):对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
11):对错误操作最好支持可逆性处理，如取消系列操作。
12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
13):对可能造成等待时间较长的操作应该提供取消功能。
14):特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!~,.。?/还有空格。
15):与系统采用的保留字符冲突的要加以限制。
16):在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
17):有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。

        10：多窗口的应用与系统资源
设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。

细则：
1):在多窗口系统中，有些界面要求必须保持在最顶层，避免用户在打开多个窗口时，不停的切换甚至最小化其他窗口来显示该窗口。
2):在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS系统资源。
3):关闭所有窗体，系统退出后要释放所占的所有系统资源 ，除非是需要后台运行的系统。
4):尽量防止对系统的独占使用。

　　写给初次写用例的朋友：（下面都是自己对用例编写的一点感受或建议，写的不对的地方请多多指教）

　　有很多朋友初次写用例，不知道从何下手，虽然有的公司给出了相关说明文档，但是写起来还是不能得心应手，编写用例方法有很多种：功能导向用例（边界值、等价类等等），用户导向用例（场景法），用户、功能相结合导向用例……那么对于初次编写用例，应该怎样高效率的编写用例？应该注意点什么？

　　一、功能导向用例是按照系统需要达到的每一个功能，进行编写用例，这样的用例着重点在功能实现上，而没有考虑到每个功能之间的关联，因而虽然用例已经达到功能覆盖，却不一定达到逻辑覆盖，因而这种方法通常会和其他方法结合使用。功能导向用例是每个用例编写者前期最常用的方法，网络上可以搜索到很多相关文章，这里因为时间关系就不写了。（还有一个原因就是可能写的很烂，所以就不拿出来丢人现眼了，呵呵）

　　二、用户导向用例是按照用户的习惯，将用户使用系统的每个目的作为一个目标，以每个目标实现为基点设计测试用例，这样的方法在B/S结构中使用比较广泛（我一直从事B/S测试所以适不适用C/S我不清楚，，但因为我喜欢玩网游，所以对C/S软件也不陌生，个人觉得也可以应用，现在的网络游戏（非竞技类）以多任务为主导，比如魔兽世界、梦幻西游、大话西游、完美国际、QQ三国等等，那么可以将完成每个任务作为目标设计测试用例）但是设计这一类用例，初写者，可能会产生很多困惑（下面写一下我第一次写的时候有哪些困惑，并针对这些困惑，后来采取了怎样的解决方案）

　　1、编写用例的第一步我该做什么？

　　理解系统，首先站在测试的角度深入理解系统的每个功能与系统业务逻辑，画出业务逻辑图（即：系统能做什么）。

　　其次站在用户的角度，列出用户使用系统的目的（即：用户使用这个系统，想干什么？）

　　2、怎样确定用户目标？

　　不能确定用户目标，可能由2方面原因造成： a>对系统不够熟悉，b>不了解用户背景。对于第一点原因，那是你自己的原因，只有回过去头看文档了，对于第二点原因，可以从‘系统能做什么 ’推算出‘用户可以做什么’然后再总结出‘用户可能想做什么’，当然这样做的前提是你对系统已非常熟悉。

　　下面以51testing论坛为例，因为刚刚进测试论坛，所以对这类系统不太熟悉，只能简单的阐述一下过程，很多地方没全写（比如：角色、角色能做什么等等），这里只是阐述一种方法，大家可以自己动手写一下：

　　1、首先确定系统使用角色：

　　a、管理员用户：

　　b、普通用户：

　　A)版主：见习版主、**版主……

　　B)水手：菜鸟、大虾……

　　……

　　2、确定这些角色能做什么：

　　……

　　菜鸟：看帖、发帖、回帖、修改自己发的帖……

　　……

　　版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。

　　本文为51Testing论坛会员feiyunkai原创，http://bbs.51testing.com

　　3、将自己放在用户角度设计用例：

　　场景1：我不是51testing会员，我想发帖子

　　对问题进行扩展：我不是会员（怎样成为会员），我想发帖子（在哪里发帖子、发什么样的帖子、发完后怎样查看帖子、怎样修改帖子、怎样查看别人的跟帖、怎样回帖（并送鲜花、砸鸡蛋）、怎样退出论坛）

　　分析一下步骤：用户注册、登录、进入相关主题、发帖、查看帖、编辑帖、查看跟帖、回帖、退出论坛

　　下面可以设计用例了：

　　1、将用户场景作为用例概述

　　2、将用户目标转化为用例所要达到的目标：a注册为会员，可发帖子。 b非会员不可发帖子（根据具体情况而定）。

　　3、以问题扩展为步骤设计测试用例：

　　1.1 我不是51testing会员，我想发帖子

　　目标：a注册为会员，可发帖子。 b非会员不可发帖子

　　Step 1 注册成为会员

　　详细步骤：1）在IE浏览器输入：www.51testing.com

　　2）点击【**】→点击【**】→点击【**】……点击【注册】，进入测试论坛注册页面（因为没打开51论坛，不记得步骤，所以用**代替，实际写用例过程应按照实际步骤写）

　　3）填写注册信息，点击【提交】

　　预期结果：

　　1）成功打开51testing主页

　　2）成功进入论坛注册页面

　　3）A）填写的信息符合规则，注册成功，点击进入论坛链接直接进入论坛，未点击进入论坛链接5秒后自动进入论坛

　　B）填写的信息不符合规则，注册失败，有相关提示（具体提示应和输入错误类型对应，这里不详细写了）

　　Step 2 登录论坛,进入相关主题（根据实际，进入相应主题）

　　步骤：

　　1）……

　　2）……

　　预期结果：

　　1）……

　　2）……

　　Step 3 发表帖

　　……

　　Step 4 查看帖

　　……

　　Step 5 编辑帖

　　……

　　Step 6 查看跟帖

　　……

　　Step 7 回帖

　　……

　　Step 8 退出论坛

　　1.2 我是会员，我想有自己的BLOG

　　目标：会员可以成功开通自己的BLOG

　　前提：该用户已经注册为52testing会员（前提，应按照实际情况写，没有前提就不写）

　　Step1:……

　　步骤：……

　　期望结果：……

　　Step 2：……

　　……

　　……

　　1.3 我是会员，我想改变我的页面风格

　　1.4 我是会员，我想给好友发消息

　　……

　　（列出用户登录论坛的各种可能的目的，然后按照1.1的形式编写对应用例）

　　时间关系，先写这些了，写的不好的地方，请提出来，多多指教，谢谢。

　　1、必须说清楚测试报告的操作系统环境：

　　比如说XX软件运行的操作系统是什么？是Windows 98、Windows2000、WindowsXP, 还是Linux操作系统等等。很多时候，大多数的软件只能够在某个系统上存在缺陷，而在其它版本的系统上可能不存在缺陷。

　　2、测试报告结果只对发布的版本和配置库的SVN号负责：

　　也许同行们都有这种尴尬，很多测试的时候，发现了Bug，并将Bug记录到Bug跟踪系统上，结果开发人员说，自己的机器上不存在这个Bug。要求测试人员重新验证Bug是否存在。一种可能是开发人员发现测试人员递交缺陷后，修改了该缺陷，还有一种情况是版本的发布不规范，开发人员忘了递交代码到配置库，结果就发布了。所以，测试报告只对特定的版本和环境负责。

　　3、指出测试的浏览器：

　　特别是Web类似的软件，不同的浏览器，测试出来的问题不一样。同样的一种浏览器，不同的版本，测试结果报告也有时候不一样，我们部门以前碰到过IE6.0和IE7.0同样的一个功能，页面显示不太一样的现象。故，Web类似软件的测试报告，最好是说明出现问题的浏览器。

　　4、测试结论和测试建议，对于一个有效的测试报告非常关键：

　　测试结论和测试建议要求简短和准确，甚至有时候决定该版本是否可以发布，特别是测试的负责人，对被测试软件的报告一定要仔细斟酌，小心为佳。

　　5、测试用例的执行情况：

　　针对软件测试报告的几种类型，如：单元测试、集成测试、功能测试、性能测试和压力测试分别编写测试报告。编写报告时，已经执行或未执行的的用例数目。用例通过的百分比，未执行的测试用例，必须说明不能执行的原因。对于测试阻塞的测试用例，必须加以说明，最好用粗体字表明，让人一看就比较清楚。

　　6、一般都要附上缺陷列表（Buglist）：

　　某个软件的测试版本，测试中共发现了多少问题，缺陷的严重等级和优先级如何，已经关闭和Fix掉的Bug有哪些？哪些问题是该版本遗留的问题？哪些是下一个版本解决的问题？哪些是重复打开的缺陷？有了Buglist，一看就一目了然，简单并且很清晰。

　　7、测试结果的图形和数据分析情况：

　　测试报告递交一定要分清递交对象，不同类型的人，递交不同版本的测试报告。如果是递交给研发部的人员，最好要附上缺陷隔离等相关方面的解释，方便开发人员迅速定位缺陷，解决问题。如果递交对象是客户，你就详细说明客户关心的功能和常用模块是否已经实现，是否存在问题即可。如果递交的对象是公司领导和客户领导，他们根本就没有很多时间来看你的文字，主要看看测试图表，最好用缺陷管理工具，如：TestDerector和QAcenter自动生成不同的图表，并且附带上各个功能模块的缺陷情况，就可以应付了，呵呵！！

　　8、测试报告也可以附带缺陷度量的相关分析：

　　如缺陷密度呀等等之类的，增加缺陷报告的技术含量.