软件测试，有几种形态，验证、排错、预防、控制。

验证是最初阶的，只要基于需求，验证需求被实现即可。

排错，其实有点像排雷了，除了验证以外，要确保基本范围之外隐藏地雷的排除。这个是有技术含量的，至少也是需要经验积累的。

预防，主旨在于尽早介入，从需求、设计的层面提出问题、屏蔽问题。

控制，其实是综合了验证、排错、预防的。但我今天想说的是一种主动控制意识。有这样一个案例：某项目发布上线了，线上报了一些问题回来，开发同学修复，测试同学回测。几周下周，处理了不少这样的问题。我跟测试同学说，看下这些问题为什么会漏测。看了之后，给我反馈是很多页面的查询功能没好好测，项目后期时间紧，没覆盖全。我说那赶紧补救。于是开展补救行动，做法是先整理查询面板的公用测试用例，然后再Review这些用例，然后再拿着这些用例去跑一下那些页面的查询功能。我问：这个要多久？回答：大概1周时间。我说：直接测要多久？回答：1天。我说：为什么不直接测？回答：本来安排进行补测的这个人不熟业务可能直接测不了。我说：有没有直接能测的人？回答：有。我又说：难道你们不担心这一周过去，不等你开始补测，线上又抛问题来了？如果担心的话，为什么不让能测的那个人直接补测？回答：......   后来是直接找了个熟悉业务的人补测了，1天时间发现了13个查询相关的缺陷，开发立马进行了修复......   这个简单的案例告诉我们什么？主动控制，这里的控制是赶在客户发现问题之前去发现问题，控制质量影响。

对测试来说，其实本质就在于质量控制，开展一系列的控制活动，并且是主动、积极的去控制。

以下这个表格摘自：http://www.sawin.cn/doc/QM/Test/TheEdge422.htm 感谢原创作者。

以上这些度量项，对于测试管理者来说应该都不陌生，全部整理到一起，真的还是蛮齐全的了。测试品质保证的乐趣，其实很多就在这些关键度量元素间。其一，这样的分析显然是颇具科学意义的，统计学嘛；其二，真正能通过管理这些度量项达到提高质量的效果，那是一件很美妙的事情。我个人而言，比较有实用感触的是1，2，3，5，15这几项，上了底色。

1---客户反馈缺陷，即漏测。其实这是一个很直观的质量保证结果，本人非常崇尚用这个指标衡量测试人员的结果绩效。虽然漏测的原因不单单在于测试的疏忽，但终究能在很大程度上体现测试的质量。且通过对这个指标的线性观察，发现一些潜在的可能在未来会反馈回来的问题，我们还能亡羊补牢，出补丁提前堵漏。

2---模块缺陷密度。往往找到缺陷最多的地方也是潜在缺陷最多的地方。这个规律几乎是千真万确。就跟越是担心会出问题的时候一般都是会出问题的，类似。这个在测试过程中或者发布之后拿来分析都很有意义。

3---遗留缺陷。仅仅看一个绝对的数字并无太大意义，它的意义在于与之前拟定的交付标准做比对，假若在标准之内就放行，不在标准之内那就卡住。另外，被允许的遗留缺陷一般也是下一阶段启动任务之时开发任务的首要任务之一。

5---趋势分析。这是一个质量活动如期完成的强力证明工具，当然要真正看到收敛才对。

15--测试用例有效率。这个指标更大意义的是规范测试活动，其次才是提高测试用例的质量。想要统计出有效率，有个前提就是测试集驱动测试，即你开展每一轮测试之前，根据测试需求建立好测试集，并且集里面的测试用例也都已经确定好，之后照着逐一测试。很多测试人员说测试用例只不过是我用来熟悉需求的产物，等我拿到被测对象，我根本就不看测试用例就刷刷的往下测。殊不知，人的记忆往往是有漏洞的，当你脱离测试用例来测试，你就是在走向随机测试，大家想想随机的活动有没有可把握性？

简单评论之后，我再加一个度量项，尤其是在这提倡测试先行的年代。---需求review阶段发现的需求issue数/整个测试过程中发现的需求Issue的总数，这个指标体现测试人员在需求熟悉阶段对需求透析程度，透析度越深往往对促进需求精致化的贡献度越大，对测试用例的有效性的贡献也越大。我们毕竟不希望到了测试执行阶段才来不停的质疑需求这里有问题那里有问题。

上周2007年的SEPG大会在科技园召开，我有收到去免费听演讲的通知。不过也许是懒，也许是担心这样的大会演讲比较空洞浪费时间，反正就是没去。今天翻朱少民老师的blog，他在讲他参加大会的一些心得。呵呵，稍微有点后悔没去感受一下这近在家门口的盛会。

我也要有感而发，关于朱老师提到的过程改进在于数据和结果而不是一个认证。之前所在的公司，可能是企业特性而定，一直没有涉及CMM，大抵老板也不屑于此，我们是卖自己的产品，不是卖自己的IT服务。也一直说原先的组织有不好的地方，但我在那里耕耘5年，至少在测试成熟度这块，还算有所积累。因为我们有衡量我们自身成熟度的数据，且我们致力于不断确认这些数据的真实性并不断优化这些数据。测试用例命中率，漏测缺陷率...... 总之，我们在这些数据中成长，尤其是漏测率，直接体现客户对我们的满意度。不管哪个角色，要出绩效，总是出在外部，外部人员受用于你的工作成果，那你就有绩效了。这是《卓有成效管理者》一书中的观点。切入现在的公司，一个多月的时间，是过了CMM3的，有数据，但是数据的真实性尚有改善余地，也就是说目前对于CMM3有序化过程的质量还无法把握，也就无法快速进步。不过我想组织的复杂度决定这个过程会稍稍漫长。没关系，沉下去，慢慢来，总是可以改善的。

        摘要：本文针对需求不明确的情况下如何做测试，列举了3个步骤。这些步骤，都是实际经验的总结。利用这些步骤，可以在需求不明确，或是没有需求的情况下，进行必要的测试工作。但是，这些都是不规范的方法。需求不明确，或是根本没有需求，这本身就是一件不规范的事情，无论是开发人员，还是测试人员都无法在不规范的环境中，做规范的事情。但是工作要继续，不能因为某些障碍而停止。这时，请参考每一个步骤，尽可能地完成测试工作。
        关键字：需求；需求规格；测试需求；文档；猜测；沟通
        软件生命周期中，需求是整个周期的源头。良好的开端，是成功的一半。需求的重要性自然不言而喻。但是，在很多企业中，并没有对需求引起足够的重视。原因并不是PM们不知道需求的重要性，而是商业竞争中不得不裁剪某些看似不能获得很大利益的步骤。
        什么是需求？很多PM和开发人员都未必真正考虑过这个问题。IEEE对需求有以下两种定义的方式。
        1. 解决用户问题或达到用户目标需要具备的条件或能力
        2. 遵守合同、协议、规范或其他要求
        然后用规范的文档描述出来，就成了我们熟悉的SRS。
        我们常说的需求，其实并不是我们认为的SRS。SRS应该叫做需求规格说明书。那需求是什么呢？与需求规格有什么区别？
        需求：对要实现的功能的粗略描述
        需求规格：对需求的精确定义
        我们知道，在软件开发过程中，只有得知了需求的精确定义，才能开展工作。比如功能方面，编辑框能支持多少位字符。性能方面，时间和容量规定等。当然还包含其他非功能，性能方面的定义。
        除了以上所说的需求，对于测试人员，还必须有测试需求。这个环节，很少有企业会重视。测试需求分为2方面：
        需要测试哪些方面
        软件是否可测，需要增加哪些开发需求
        其中第一条，很多企业都列到了测试计划中，这也可以，没有规定一定要放到哪个文档里。但是对于第二条，可以说几乎没有多少企业去做。
        接下来，在没有明确需求，需求规格，测试需求的情况下，我们怎么去做测试呢？现在很多企业，其实就是在这种情况下做项目的。
        当测试人员接手一个项目后，第一件事情一定是想了解这个系统的功能，背景，架构。于是，马上就会想得到需求文档。但结果往往是失望的，根本没有文档，或者文档根本不具备参考价值。此时不必太失望，因为这种情况实在是太常见啦。这时，请试着从以下几个步骤着手。
        查阅文档：文档是最具权威的，也是记忆最长久的。有时，我们的项目可能是在原有产品的基础上，进行版本升级。这时，先去找找，有没有原有版本留下的需求，或者是用户手册等文档。从这些文档中，了解项目的背景，系统的基本功能。这对了解新项目是有很大好处的。并且，在产品升级的项目中，验证老版本的功能在新版本中是否正常，也是一个必要的工作。可以先参考老版本的相关文档，设计新版本中的用例。
        也有时，我们的项目是一个行业项目，比如金融项目。我们可以参考一些行业知识的书籍，文档。这对理解系统也有很大的好处。
        实在没有文档，那只好暂时跳过这一步骤了。
        在进入下一步骤之前，你可能得到了一些相关文档，也可能什么也没得到。无论如何，你可能对系统已经有了一些了解。这时，请记录下来，写成文档。无论是对自己，还是对别人，在以后都可能极有参考价值。试想一下，如果前人已经给你留下了这些文档，你是否可以轻松很多？还要注意及时更新你的文档。因为你对系统的理解，随时都在变化着，一定要保证你的文档和当前你对系统的理解是一致的。
        试着使用系统，根据经验和常识猜测：既然没有需求，那可以推测，该项目的管理一定是很糟糕的，对测试也不会投入很大的成本。因此，测试人员一般都是在编码完成后才进入项目。这时，应该已经可以看到成型的系统了。在没有需求的情况下，试着先“玩”一下系统吧。在这过程中，你应该对系统有可更深入的认识，在上一阶段中，你可能留下很多疑惑或是猜测，这时应该能排除一部分了。
        使用系统的同时，你应该具备行业知识。系统可能是针对某个专业领域设计的。例如一个期货交易系统。你没有基本的期货知识，比如什么是持仓，什么是平仓。那么你如何能真正理解这个系统呢？当你有了业务知识以后，你会进行更深入的思考，来全面测试系统。
        你还需要具备良好的软件知识。比如某些控件的特性。单选框只能单选，不能多选。日历控件是否可以手工输入非法格式等。这些都是应具备的意识。
        最后加上你的主观判断，你对系统的整体感觉怎么样？是否越用越厌烦，为什么厌烦。系统的反应速度是否可以容忍，细节处理是否圆滑，等等。
        在你认识系统的时候，可以使用一些方法，来帮助你更有效率地学习。比如可以画一些流程图。一图胜万语。同时，你也留下宝贵的文档。当然，这个步骤中，你也要随时注意保留和更新文档，以备后用。
        沟通：需求规格不一定非要以文档的形式表现出来。软件既然能做出来，那肯定是有需求的。而最清除需求的，一定是软件的直接制造者，开发人员。开发人员自己知道需求，但一般不会主动和测试人员沟通。因此，测试一定要主动和开发人员沟通。可以安排会议，让开发人员给测试人员介绍系统，并演示系统。让测试人员对系统有一个整体了解。然后测试人员能进行更细致的测试。在进行细致测试的时候，一定会有更多不明确的地方。这时就需要利用自己的行业知识，计算机知识等，猜测一部分。不需要每个细节都去询问开发人员。因为开发人员也有自己的工作，他们不希望花太多时间来给你解释。
        有些项目中，客户会直接参与到项目组来。这时，测试人员在权限允许的情况下，可以和客户进行沟通。客户那得来的需求，是最原始的需求。但是，客户未必有良好的表达能力来描述希望的功能，也未必有计算机知识，因此不能描述出一些隐式的需求。在被允许的情况下，测试人员可以和客户进行交流，不仅可以帮助客户正确描述出真实需求，测试人员也能详细了解需求。但是项目是要考虑成本的，客户的期望是无限制的。在客户提出需求以后，测试人员要先和PM或其他相关负责人协商后，才能将与客户交流得来的需求，作为测试的依据。同事，第一时间告知相关开发人员最新的信息，也记录成文档。这时，你就将非文档形式的需求，转换为文档形式了。至于文档的格式，不一定要按照标准SRS的格式。因为它本身就不是个规范的SRS。以任何容易理解的方式，组织你的文档。
        有时候，会根本找不到可以沟通的人。不要奇怪，确实就是有这种时候。比如：
        1. 测试一个开源软件
        2.  接到一个测试外包，但又没有得到相关文档，为了追求利益，还是接下了
        3.  软件项目组的部分人员已经联系不上等等
        这时候，一方面需要PM协调获取相关资料，联络相关人员。另一方面，测试人员也可组织头脑风暴，利用集体的智慧，共同探讨和猜测软件中的各个环节。也可以安排Bug Bash，让尽可能多的人员参与随机测试。一定会有人提出具有创造性的意见的。
        在进行以上步骤的时候，利用良好的工具，能让你事半功倍。我经常在使用的一个工具，就是Mindjet MindManager。这是一个很好的，帮助扩展思维的工具。它以分支的形式，来表现你的思维层次。你可以先列出个最基本的系统整体结构，然后逐步细化，增加分支。不要急于一次就将真个系统分析透彻，这是不可能的。你在进行以上步骤的时候，随时会细化这个结构。当项目结束后，看看这个结构图，简直可以当作SRS来参考了！

之前在B公司，有很多的presention机会，新人自我介绍，试用期满答辩，职位晋升，工作产出评审，知识分享，专业培训等等。所以经过B公司正规历练的人，都有着一定的presention技能，哪怕一个很普通的技术人员。B公司为什么有这样的一个传统，我不深究了，只是我发现这个方法很好，被我应用到了测试管理工作中，尤其是需求理解度确认 以及 测试用例评审。

这里我想重点说的是需求理解度确认。

被要求上台做需求理解度presention的QA，pass的标志就是“讲的请，问不倒”。并不是赤手空拳上去接受霹雳啪啦的发问，而是会遵循一个基本流程。

• 先跟大家说明需求的业务背景概要--从业务应用上去理解需求；
• 然后用面向对象的方式描述业务主体流程，场景；
• 接着选择重点业务详细讲述，可以辅助UML图形，活动图，状态图，序列图，自由组合；
• 再后来讲述测试需求（含非功能测试需求）验收标准，测试策略，测试重点、难点。
• 最后就是接受集体轰炸。当然前面也可以适时轰炸。

Presention过程中可能会用到需求文档中的一些原始资料，但是我们还是极力鼓励原创，即消化吸收需求后，要用自己的语言文字表达出来。记得曾经有我们的小QA被底下的人轰炸到语塞甚至委屈到掉眼泪。比如说你问的这个需求上也没写清楚嘛，可是你不搞清楚，怎么测试呢？比如说“大概，也许是这样的吧”，可是这样的标准如何具备可测试性呢？......

如果真的能经受住这5轮考验的测试人员，那么他写的测试用例，他在测试过程中对问题轻重缓急的拿捏，我们都可以给予一定的信赖。且具备良好表达说服能力的人，在与开发人员沟通的时候我们也不必担忧了。真是一举N得！

Test Case Quality=Defect Number/Case Number.以这样的方式衡量测试用例质量的指标，大家可能也见过。大致的意思是看平均一个测试用例能发现几个缺陷。

我对此持反对态度，我认为这样的指标没有实际意义。原因如下：

1. 未过滤出由测试用例范围之外随机、意外发现的缺陷。

   测试过程中难免会出现一系列测试用例验证范围之外的随机的意外的缺陷。一旦发生，做的比较好的测试组织会去修正测试用例，做的不好的可能就视而不见了。这两种情况不管哪种，最终的统计结果都不是我们需要的。前者，修正过的测试用例已经不代表我们真实的测试用例设计水平，只是防范后期同类漏测的一个补救措施；后者，其粗糙、虚假程度不值得在这里分析了。

2. 关于追求尽量多的缺陷 与 尽量少的测试用例 的误区。

   按照这个公式，表面理解是用尽量少的测试用例发现尽量多的缺陷。要使结果趋于良好，要么缺陷足够多，要么用例尽量少。缺陷足够多，很容易使我们陷入一个追求缺陷数量的误区；用例尽量少，其实就很难确保测试的完备性，顶多是把一些同类的做抽象合并处理，而事实上我们还是希望测试用例写的尽量细致的，这与尽量少是矛盾的，可操作性较低。

所以，关于衡量测试用例质量好坏，我的观点是去统计 由测试用例发现的缺陷/缺陷总数，即测试用例缺陷命中率。这才代表测试用例的一个水准。只要在合理的人力、时间条件下，这个指数越高，说明测试用例的质量越高，测试有序性也越高。同时对于测试用例范围之外的缺陷，我们要持续的做分析，针对性地改善。

这里再提供一下我们的经验值，发展了3年多的一个软件测试组织，测试对象是中小型企业应用软件，命中率大概能达到60%左右，这是一个比较诚实的数据。

近日看到一篇文章，关于软件质量特性因子。http://blog.csdn.net/giltworld/archive/2007/02/25/1513897.aspx

忽然发现这里面的特性因子，其实与我们正在做的产品验收标准其实是异曲同工的。

记得一年前每次老板问到产品的质量怎么样？我头头是道的讲测试用例的覆盖率，测试用例的命中率，缺陷的走势等等，但结果还是鸡同鸭讲，他最后还是会问我：为什么我认识的一个做软件测试的人告诉我经过他们测试的软件都能达到90分以上？你告诉我们的软件得多少分？我就无语了。

后来终于明白过来，有一日晚上忽然想起来，就发短信给老板说：之所以我给不出分数是因为我们开始的时候就没有定下质量验收的标准。老人家马上回复明白。次日，即召来产品经理/研发经理/实施经理等，一起商定产品质量验收标准事宜。自打那以后我就很轻松了，每次报告就按照标准给分值，再也不会无语。

这里总结如下几点：

1。所谓的验收标准，其实与质量因子是一样的。你要根据实际情况分几个纬度。比如业务功能满足度/业务流程满足度/性能满足度/稳定性满足度/易用性满足度/实施标准工作量满足度等等。

2。每个因子，得有一定的比例，即占整体质量的权重，这样最后才好给分数。

3。每个因子要定好验收方，当然不是每个因子全部由测试来验收，比如说实施标准工作量，这得由负责交付的部门来验收。比如业务功能/性能/易用性这些其实都是可以通过测试用例来衡量的，pass了就算满足了。

所以，一旦你学会按照这样的思路去给你的老板做报告，基本上你就很轻松了。当然，同时你的报告也不要单单是这些内容，还要注意测试本身的一些数据积累，比如缺陷走势/测试用例的命中率等等这些对于测试专业度的提升还是很有参考价值的。