8、你对测试最大的兴趣在哪里？为什么？
　　最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了11，12点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1，2点我没有把握，其他点我都很有信心做好它。
　　刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。
　　不到一年半的测试工作中，当时的感动和热情没有减退一点（即使环境问题以及自身经验，技术的不足，做测试的你一定也能理解）。
　　我觉得做测试整个过程中有2点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。
　　第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。还有如何发现bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。如何描述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。

9、你的测试职业发展是什么？
　　测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经验，按如何做好测试工程师的11，12点要求自己，不断的更新自己改正自己，做好测试任务。

10、你自认为测试的优势在哪里？
　　优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但测试需要的基本技能我有信心在工作中得以发挥。

11、当开发人员说不是BUG时，你如何应付？
　　开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

12、你以前工作时的测试流程是什么？
　　公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。

13、你为什么想离开目前的职务？
　　因为公司运作情况并不理想，公司需要调整部门体系，公司考虑到缩减部门人员，所以大批量的裁员（有6，7个），这是我的第一份工作，对公司也有较深的感情，因为在这里我找到了职业理想（就是测试），所以公司需要精简人员，我自愿退出。虽然很舍不得，但我将会有新的发挥能力的舞台。

14：请谈谈你个人的最大特色。

我的坚持度很高，事情没有做到一个令人满意的结果，绝不罢手。

 

15.你怎样做出自己的职业选择？
　　分析 面试人提出这个问题是为了了解求职者的动机，看看他（她）应聘这份工作是否有什么历史渊源，是否有职业规划，是不是仅仅在漫无目的地申请很多工作。
　　错误回答 我一直都想在企业界工作。自孩提时代起，我就梦想自己至少也要成为大企业的副总裁。
　　评论 除了难以令人相信之外，这种回答还存在一个问题：它表明求职者会对副总裁以下的职位不感兴趣。
　　正确回答 在上大学四年级前的那个夏天，我决定集中精力在某一领域谋求发展。尽管我是学商业的，但是我不知道自己最终会从事哪一行业的工作。我花了一定的时间考虑自己的目标，想清楚了自己擅长做的事情以及想从工作中得到的东西，最后我得出了一个坚定的结论，那就是这个行业是最适合我的。
　　评论 这种回答表明，求职者认真地做过一些计划，缩小了自己的关注点，而且也认准了前进的方向。这种回答还表明，求职者理解个人职业规划的重要性，并且有能力做出认真的个人决策。
1. 你都用什么测试方法
2.怎么编写案例
3.怎么才能够全面的测试到每一个点
1. 你都用什么测试方法
针对不同的产品或者系统或者模块，有不同的测试方法。总体而言有白盒测试和黑盒测试。
2.怎么编写案例
案例的编写与测试阶段的定义有很大的关系。系统测试和unit测试的案例可能不同。总体而言测试案例根据系统的需求而定。
3.怎么才能够全面的测试到每一个点
测试的全面性主要需要在设计测试计划的时候考虑，从测试策略，产品需求等等多个角度考虑从而定义全部的测试点。
1、谈谈软件测试技术，以及如何提高
2、谈谈软件测试职业发展，以及个人的打算
3、谈谈软件测试在企业的地位，也可以结合软件生命周期来谈
有可能清晰的思路比确切的答案更重要

 

在这里，主要说下笔试和面试的问题，希望大家共同参考。
     1，一般公司里实际的软件测试流程是什么样的？你们公司又是怎样的？
     2，软件工程师要具有那些素质？
     3，你会哪些测试工具？怎么操作？
     4，你能不能说下你的3到5年的职业计划（规划）
     5，你觉得你来应聘有那些优势？
其余的还好说，但就第4个问题，我感到不好说哦！希望大家给个意见
第一关：首先要自我介绍，自己的性格怎么样，目前的工作经历积累了一些什么经验取得了些什么值得一说的成果。然后要说说对软件测试怎么看？还有对于软件测试有什么自己的想法。为什么会想到要做这行（因为我的简历上的工作经历没有关于测试方面的）。哦，还有期望薪资。
第二关：认为软件测试人员所要具备的基本素质，如果遇到问题会怎样处理，如果得不到研发人员的配合（就是研发说这个不是问题）你又会怎么处理？然后就是一些基本概念，比如软件测试的流程有哪些？如果我上任了，首先会怎么开始自己的工作计划。
（前两关通过了后面这个就好过多了）
第三关：像我介绍了一下公司的情况，告诉我主要针对什么内容的测试，会不会使用数据库。告诉我大概要做哪些内容，详细的可以上岗以后慢慢熟悉。
大概就这么多了，这对没有经过这一关的不知道有没有帮助，仅供参考吧
我觉得就像李波说的，关键是要给对方留下好印象:)

面试官最后会问你有什么问题要问吗。作为应聘者的你一般不要说没问题问，这会给面试官留下你不太重视这份工作的坏印象。所以如果你想得到这份工作的话应该抓住这最后的表现自己的机会：
你可以问：
1.         贵公司近期和远期的发展目标是什么？
2.         贵公司的主要竞争对手有哪些？
3.         贵公司有多少开发人员有多少测试人员？
4.         贵公司又进一步扩充测试人员的计划吗?
5.         如果我有幸能进入贵公司的话，我有怎么样的发展？
6.         测试人员的沟通能力很重要，贵公司有规范的沟通渠道吗？
7.         请介绍一下贵公司的福利情况。
8.         请问我什么时候能知道结果？

 

 

 

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

 

 

【51软件测试每周一问，整理】没有需求文档的时候如何来设计测试用例？（08-06-20）

这是根据51Testing 软件测试网上“软件测试每周一问”问答整理而成，集大家之智慧！

【引题】测试用例应该是按照需求文档来开发，但是当项目没有需求文档时，该如何设计测试用例呢？

【题外话】大家在求职时参加的面试中会被问到各种各样的问题，有些问题的确是有确定的唯一的答案，而更多的问题是开放性的，面试着主要是你想了解求职人的自己的看法，而回答问题的方式也能看出个人看问题，思考的方式。本身，思考，就是一种方法学。

【正题】hjjlearning的回答是我比较满意的。Case by case的讨论问题，总是比较全面，而且可以引导大家更为全面的去思考，从而提高一个问题的广度。针对“没有需求文档”这样一个现象，我们去想解决问题时，需要花点时间去考虑造成这种现象的原因。针对不同的原因，也就是找对“病因”了，解决问题的方法也就有了。这就如中医看病，总是从表象的症状去寻其根究。就比如头通，表现出来的这一种症状，却有不同的原因，西医总是“头痛医头，脚痛医脚”，而中医主张从其根本去分析，痛其实是身体某处经络不通造成的，把相应的经络打通了，那痛的问题就会解决了，有时头痛可以通过按摩脚底的穴位，或是敲打胃经，胆经，等等。又扯远了，哈！

分析“没有需求文档”，分析其具体原因再针对性的解决：

1.   整个项目的开发人员和项目经理的意识不足，开发流程不规范，或是认识不到需求文档对于测试的举足之重。认为做过了市场可行性分析了，认为项目组的成员对于整个项目都有清楚，而且任务分配下去了，就没有必要写需求文档了。

针对这种情况，测试负责人应该坚持要求项目负责人派专人给出需求文档，否则就拒绝测试。这对于规范的软件开发项目来说应该是理所当然的事情，可是在中国（我不知道别的国家是怎么样子的），做事都讲究官大压死人。bingcha320说的好，上报'没有需求文档将无法进行测试用例设计'的事实给高层管理者(练口才的时候到了),引起他们的重视,让他们尽可能推动开发组或产品组完成需求文档，哈哈

2.   项目进度紧张，后期需求变动会比较大，来不及也不好写详细的需求文档，或是项目是从原有项目上进行升级，开发人员认为不要再进行

当项目经理把自己的难处说给你听，并给你一个“Sorry”的时候，那就要动用各方面的关系自己去搜集功能点啦。

简言之，不能瞎乱糊草的写测试用例。对自己的时间和精力负责，对整个项目负责，自己整一份feature check point list！

Zhuzx给出了比较详尽的条条框框的指导性的回答，（有经验有头脑的人就是厉害哈！我在其精彩回答后加了点自己的“挑刺”）

下面是我的一些看法，恳请各位同行批评指正：
1.根据客户的功能点整理测试需求追朔表：
一般的客户都要把要开发软件的功能点写成一个表格交给市场部，让市场部门转交研发部。所以客户的功能点是编写测试用例一个最最重要的依据。【其实这只是一个依据，客户列出的功能点，要转化为软件实现的功能点并能在开发人员和测试人员之间更好的沟通的话，还是需要一点处理的】

2.根据开发人员的Software Specification List整理我们的功能测试点：
一般来说，开发人员实现一个功能都要把该功能分成几个子模块来实现，所以Software Specification List也是我们参考的另一个比较重要的依据。【只做过黑盒测试，在做黑盒测试时，参考开发人员的design doc时，尽量避免被开发人员误导，因为有些在他们看来是要实现并验证的功能，在用户使用时其实只是一种情况，而有些在他们看来是一个问题时，实际上用户使用时会有不同的体验，测试人员不是为了验证代码的逻辑的正确，而是为了确保交付给用户使用时，软件的质量很高。当然了，这些开发文档在没有需求文档时是比较好的资料啦J】

3.开展项目跨部门讨论会：
可以抽出时间，叫市场部的项目负责人、产品经理、项目经理、软件开发经理和软件开发人员，分别讲讲他们对整个产品的认识和设计模式，对每个功能点的理解和认识，理顺思路，达成共识，测试人员负责记录，测试Leader负责整理汇总，形成测试的部分参考文档。

4.测试人员整理用例需求疑问递交项目组和客户代表回复：
测试人员根据项目讨论会后的理解，测试过程中可能碰到的问题（如：边界值、输入数据类型等等）和需求不明确的问题，整理用例需求疑问，让相关的模块负责人在“用例需求疑问”表格中回复，并给出详细解释和说明。

5.项目内部用例评审：
测试人员根据对项目的理解，编写测试用例要点，测试组内部评审修改后，可以召集项目组的成员，帮助Review一下，然后进行修改。经过多次修改和评审以后，测试用例要点可能会更加全面一些。

6.邮件和客户代表确认部分争议问题：
测试人员与开发人员、项目组成员，在需求问题上讨论有时候观点不一致，各说各有理，这种情况下最好把争议问题写成邮件，发给客户让客户来拍板，确定那种需求合理，到底如何做？抄送项目组的全体成员，方便大家都了解客户的意见。最后编写测试用例的时候，以客户的邮件内容为准。

7.项目Demo和部分已开发系统：
大部分的系统，由于没有需求，为了避免项目风险，开发方一般都要做成Demo，不断让客户确认后签字，不断展现新开发的功能，以达到吸引客户的目的。如果项目中有Demo，Demo也是参考标准。如果什么都没有，那已经开发的部分功能模块，要去随时让用户了解了解，并提出部分修改意见，也可以为我们熟悉系统提供部分依据。

8.参考同行业和竞争对手的类似产品：
假如说是做一个网上书店类似的网站，我们编写测试用例的时候，可以看看“当当网”，“China—pub”等等类似成熟相关的网站。很容易发现本公司产品的问题，无意识给产品添加了竞争力。对于竞争对手的了解一定不能够少。

9.交叉模块的测试，最容易被人忽略：
一般的产品，功能部分的交叉，即是说在A模块中设置了参数，在B模块和C模块中体现该参数的实际运用。比较难的如我们现在测试的“银行系统”中的交叉模块，还可能牵涉到不同的用户，3个以上的模块之间的调用。即是有了需求也很少写，同时也是需求编写的一个薄弱环节。这样的测试用例编写问题，一般初级测试工程师很难考虑全。对于有这种交叉功能的模块，必须要求项目组中的精兵强将，画出相关的调用关系图，表明调用关系，方便后面编写测试用例。

10.可以使用电话、MSN、Skype等网络聊天工具咨询部分需求：
我们做的产品，大多数的客户都在国外，测试经理也可以用这些网络聊天工具和客户确认部分需求疑问。不过要要事先越好时间，并注意异地的“时差”。

其实这些方法远不止是告诉我们在没有需求文档时该如何处理，这些方法同时也帮助写需求文档的人如何多方面的搜集资料，和QA如何更好的在软件开发过程中，获取相关资料从而更好的把握软件质量。

哎呀，论坛里的人才真是太多了，我只获取这么一点点吧

因为毕竟经验有限，有了这些方法上的指导，大家在实际项目中就灵活处理吧！

 

从需求角度考虑：
1、这个水杯的需求是什么？为什么要做这个印有广告的水杯，有什么要求？
测试时，先从对这个水杯的要求点进行测试；这时就出现了针对各个要求点的测试。

参考“我爱手机”中提到的一些测试点，假设，功能上的要求是：
1、这个水杯要印有广告，广告的位置、图片颜色、图片大小；
2、这个水杯要能装水，如：热水、冷水；
3、这个水杯是否要有手提，手提的样式是否有要求；
4、这个水杯的样式是圆的、方的、高的；厚度是否有要求，有什么样的要求；
5、这个水杯是否是透明的，制作材料是否有要求，有什么样的要求。

从用户友好性方面考虑：
1、这个水杯设计的是否方便清洁；
2、这个水杯是否耐摔；
3、这个水杯设计是否美观（从外观、颜色等）；
4、这个水杯在购买时，是否有详细说明它的制作材料和适用情况。

嘿嘿，每个人的思维有限，在测试的过程中，需要大家集体的思考测试点。这样才能想的更全。^_^

 

我觉得还有几点，如：这个虽然是水杯，但是能否装其他的东西，可以当储蓄罐使装钢镚啊呵呵，还有，这个水杯能否在天很冷或很热的情况下正常使用保存？装水会不会泄露？等等，最后还要引到这点：测一个水杯可能不需要那么复杂，但是如果是一个软件的话，我们就要。。。。。^_^

现在的很多公司，做起项目来，需求变化速度之快，实在是让人防不胜防。而且基本上对SRS的修改，都是先斩后奏。开发人员一般都是直接和客户交流，直接改代码。更过分的是，他们改完之后，从来就不会第一时间通知需求组，通知测试组。感觉就像整个项目组都应该围着他转一样。

    这里我不想讨论需求为什么变化那么快，为什么会允许这样随意地变更。因为许多公司的现状就是如此，让他们形成配置管理的意识，不是一天两天能解决的事。或者有些企业，虽然知道配置管理的重要性，但是真正到了要落实的时候，就把原本订的配置管理流程束之高阁了。

    在需求变化频繁的情况下，作为测试人员，最重要的就是要搞清楚以下几点：

    1.哪些需求发生了变化

    2.这些需求变化后，对测试工作会产生哪些影响。包括会不会影响测试用例，如果影响，会对哪些用例产生影响。当发生较大改动时，还要明确是不是影响到了测试方案，甚至是测试计划？

    3.明确这些变化，会对自己的工作进度产生多大的影响。当发现自己的大部分用例都受到影响，需要修改时，应该第一时间向上级反映情况。由他定夺解决方案，而不是自作主张，或是一声不响。

    关于如何确定哪些需求发生了变化，最好的工具当然是需求跟踪矩阵了。需求跟踪矩阵是从开发和测试两条线，同时进行跟踪的。但是，要实现需求跟踪矩阵，可不是容易的事情。尤其对于需求变化频繁的公司来说，基本可以断定他们是没有配置管理的。那么需求跟踪矩阵就根本没有实现的可能。但是，公司没有，不代表我们自己没有。

    公司的测试任务分配，一般都是按照子系统或者是模块来分的。比如TesterA测试子系统A，TesterB测试子系统B。那么这时，我们完全可以只针对自己测试的子系统，完成需求跟踪矩阵。我们只需要自己维护测试线的需求跟踪，至于开发线，那可是管不着了。但是这里还是有点问题。我们一般理解的需求跟踪矩阵，是将SRS分成子SRS，然后针对每个子SRS，建立跟踪关系。但是忽略了各个子SRS之间的关联关系。要想把各个子SRS划分得没有一点联系，那是不太可能得。如果有两个子SRS，称为SRS1和SRS2，你测试的是SRS1相关模块，而SRS2相关模块是别人测的。当SRS1相关开发人员告诉你需求已变更后，你分析后得知影响到了SRS2，那么你必须和测试SRS2相关模块的测试人员及时沟通。你能保证做到这点，但是对方未必会在SRS2发生变化时，及时通知你SRS1受影响的部分。这时你需要事先和测试组的其他人员充分沟通，让他们及时通知可能会影响到你的变更。如果他们不及时通知，你就完全有推卸责任的理由了。对于开发人员也是一样，他们擅自改了程序，不通知变更SRS，或者不及时通知变更，你也完全有理由推卸责任了。

    我们的目标肯定是要把测试工作做好，而不是自己没有责任就好了。当建立了自己的需求跟踪矩阵以后，就可以快速定位变更部分，而且目前企业没有配置管理的理念，所以可以及时变更你的用例，方案，甚至是计划。当发现受变更影响的部分非常多时，应该及时通知上级，让他们了解情况，并做出决策。

    总结一下的：需求变化快，测试工作需要重新写用例，方案，甚至计划。这时遇到问题：

    1.得不到及时通知

      解决方案：没有办法，只能事先和开发人员以及测试组内部人员事前声明，不及时通知的部分，一概不付责任

    2.不知道需求变化后，对哪些工作产生了影响

      解决方案：公司没有配置管理，没有需求跟踪，那么就建立自己的小的需求跟踪。只跟踪测试线。把自己的工作做好，并及时通知其他受影响的测试人员。

    3.发现自己大部分用例，方案，甚至计划要重新修改，而没有充足时间

     解决方案：及时通知上级，让他给解决方案，而不是自己苦干。

此文来源于51testing博客，转载请注明出处
原始链接：http://blog.51testing.com/?5246/action_viewspace_itemid_3002.html

测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。

要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。

既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。

确定测试用例之所以很重要，原因有以下几方面。

测试用例构成了设计和制定测试过程的基础。
测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。
判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95 % 的关键测试用例已得以执行和验证”，远比“我们已完成 95 % 的测试”更有意义。
测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。
测试设计和开发的类型以及所需的资源主要都受控于测试用例。
测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例：

·一个测试用例用于证明该需求已经满足，通常称作正面测试用例；
·另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。

一、测试用例是软件测试的核心

软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。

影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。

因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。

二、编制测试用例

着重介绍一些编制测试用例的具体做法。

1、测试用例文档

编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。
软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。

测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释等。以上内容涵盖了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。

2、测试用例的设置

我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。

按功能测试是最简捷的，按用例规约遍历测试每一功能。

对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。

但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。

3、设计测试用例

测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。

设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。

可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。

三、测试用例在软件测试中的作用

1、指导测试的实施

测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。

根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。

2、规划测试数据的准备

在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。
除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

3、编写测试脚本的"设计规格说明书"

为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。

4、评估测试结果的度量基准

完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。

5、分析缺陷的标准

通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

四、相关问题

1、测试用例的评审

测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。

2、测试用例的修改更新

测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。

一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。

3、测试用例的管理软件

运用测试用例还需配备测试用例管理软件。它的主要功能有三个：第一、能将测试用例文档的关键内容，如编号、名称等等自动导入管理数据库，形成与测试用例文档完全对应的记录；第二、可供测试实施时及时输入测试情况；第三、最终实现自动生成测试结果文档，包含各测试度量值，测试覆盖表和测试通过或不通过的测试用例清单列表。

有了管理软件，测试人员无论是编写每日的测试工作日志、还是出软件测试报告，都会变得轻而易举。

五、测试用例的设计

（一）白盒技术

白盒测试是结构测试，所以被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例。
1、逻辑覆盖
程序内部的逻辑覆盖程度，当程序中有循环时，覆盖每条路径是不可能的，要设计使覆盖程度较高的或覆盖最有代表性的路径的测试用例。下面根据图7-1所示的程序，分别讨论几种常用的覆盖技术。
(1)语句覆盖。
为了个提高发现错误的可能性，在测试时应该执行到程序中的每一个语句。语句覆盖是指设计足够的测试用例，使被测试程序中每个语句至少执行一次。
如图7-1是一个被测试程序流程图：

(2)判定覆盖。
判定覆盖指设计足够的测试用例，使得被测程序中每个判定表达式至少获得一次“真”值和“假”值，从而使程序的每一个分支至少都通过一次，因此判定覆盖也称分支覆盖。
(3)条件覆盖。
条件覆盖是指设计足够的测试用例，使得判定表达式中每个条件的各种可能的值至少出现一次。
(4)判定/条件测试。
该覆盖标准指设计足够的测试用例，使得判定表达式的每个条件的所有可能取值至少出现一次，并使每个判定表达式所有可能的结果也至少出现一次。
(5)条件组合覆盖。
条件组合覆盖是比较强的覆盖标准，它是指设计足够的测试用例，使得每个判定表达式中条件的各种可能的值的组合都至少出现一次。
(6)路径覆盖。
路径覆盖是指设计足够的测试用例，覆盖被测程序中所有可能的路径。
在实际的逻辑覆盖测试中，一般以条件组合覆盖为主设计测试用例，然后再补充部分用例，以达到路径覆盖测试标准。
2.循环覆盖
3.基本路径测试

（二）黑盒技术

1.等价类划分
(1)划分等价类。
①如果某个输入条件规定了取值范围或值的个数。则可确定一个合理的等价类(输入值或数在此范围内)和两个不合理等价类(输入值或个数小于这个范围的最小值或大于这个范围的最大值)。
②如果规定了输入数据的一组值，而且程序对不同的输入值做不同的处理，则每个允许输入值是一个合理等价类，此处还有一个不合理等价类(任何一个不允许的输入值)。
③如果规定了输入数据必须遵循的规则，可确定一个合理等价类(符合规则)和若干个不合理等价类(从各种不同角度违反规则)。
④如果已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分为更小的等价类。
(2)确定测试用例。
①为每一个等价类编号。
②设计一个测试用例，使其尽可能多地覆盖尚未被覆盖过的合理等价类。重复这步，直到所有合理等价类被测试用例覆盖。
③设计一个测试用例，使其只覆盖一个不合理等价类。
2.边界值分析
使用边界值分析方法设计测试用例时一般与等价类划分结合起来。但它不是从一个等价类中任选一个例子作为代表，而是将测试边界情况作为重点目标，选取正好等于、刚刚大于或刚刚小于边界值的测试数据。
(1)如果输入条件规定了值的范围，可以选择正好等于边界值的数据作为合理的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。如输入值的范围是[1，100]，可取0，1，100，101等值作为测试数据。
(2)如果输入条件指出了输入数据的个数，则按最大个数、最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。如，一个输入文件可包括1--255个记录，则分别设计有1个记录、255个记录，以及0个记录的输入文件的测试用例。
(3)对每个输出条件分别按照以上原则(1)或(2)确定输出值的边界情况。如，一个学生成绩管理系统规定，只能查询95--98级大学生的各科成绩，可以设计测试用例，使得查询范围内的某一届或四届学生的学生成绩，还需设计查询94级、99级学生成绩的测试用例(不合理输出等价类)。
由于输出值的边界不与输入值的边界相对应，所以要检查输出值的边界不一定可能，要产生超出输出值之外的结果也不一定能做到，但必要时还需试一试。
(4)如果程序的规格说明给出的输入或输出域是个有序集合(如顺序文件、线形表、链表等)，则应选取集合的第一个元素和最后一个元素作为测试用例。
3.错误推测
在测试程序时，人们可能根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例，这就是错误推测法。
4.因果图
等价类划分和边界值方法分析方法都只是孤立地考虑各个输入数据的测试功能，而没有考虑多个输入数据的组合引起的错误。
5.综合策略
每种方法都能设计出一组有用例子，用这组例子容易发现某种类型的错误，但可能不易发现另一类型的错误。因此在实际测试中，联合使用各种测试方法，形成综合策略，通常先用黑盒法设计基本的测试用例，再用白盒法补充一些必要的测试用例。

六、测试用例设计的误区
（来源：关河测试网）

·能发现到目前为止没有发现的缺陷的用例是好的用例；

首先要申明，其实这句话是十分有道理的，但我发现很多人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。我倾向于将测试用例当作一个集合来认识，对它的评价也只能对测试用例的集合来进行，测试本身是一种“V&V”的活动，测试 需要保证以下两点：

程序做了它应该做的事情
程序没有做它不该做的事情
因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。

·测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试；

不知道国内有没有公司真正做到这点，或者说，不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中，对测试用例描述的详细和复杂程度 也曾有过很多的彷徨。写得太简单吧，除了自己没人能够执行，写得太详细吧，消耗在测试用例维护（别忘了，测试用例是动态的，一旦测试环境、需求、设计、实 现发生了变化，测试用例都需要相应发生变化）上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的情况下，恐怕很难实现。但我偏偏就能遇到 一些这样的老总或者是项目负责人，甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。

在讨论这个问题之前，我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个Project，也需要在 给定的资源条件下尽可能达成目标，根据我个人的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，因此我们必须在测试计划阶段明确测试的目 标，一切围绕测试的目标进行。

除了资源上的约束外，测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。在我担任测试经理的项目中，在测试计划阶段，一般给予测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。

·测试用例设计是一劳永逸的事情；

这句话摆在这里，我想没有一个人会认可，但在实际情况中，却经常能发现这种想法的影子。我曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例 却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰 后，对测试人员不屑一顾。

这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。

·测试用例不应该包含实际的数据；

测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行 性。当然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，关于这一点，《Effective Software Test》一书中提供了详细的测试用例、测试数据的维护方法，可以参考。

·测试用例中不需要明显的验证手段；

我见过很多测试工程师编写的测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。例如，对一个订货系统， 输入订货数据，点击“确定”按钮后，系统提示“订货成功”，这样是不是一个完整的用例呢？是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢？ 显然不是。订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。

七、从用例中生成测试用例

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

例如，下图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流 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 进入“安全模式”，在此模式下所有功能都暂停使用，直到采取适当的重启/重新初始化的措施。
在第一次迭代中，根据迭代计划，我们需要核实提款用例已经正确地实施。此时尚未实施整个用例，只实施了下面的事件流： 基本流 - 提取预设金额（10 美元、20 美元、50 美元、100 美元） 备选流 2 - ATM 内没有现金 备选流 3 - ATM 内现金不足 备选流 4 - PIN 有误 备选流 5 - 帐户不存在/帐户类型有误 备选流 6 - 帐面金额不足

可以从这个用例生成下列场景

场景 1 - 成功的提款	基本流
场景 2 - ATM 内没有现金	基本流	备选流 2
场景 3 - ATM 内现金不足	基本流	备选流 3
场景 4 - PIN 有误（还有输入机会）	基本流	备选流 4
场景 5 - PIN 有误（不再有输入机会）	基本流	备选流 4
场景 6 - 帐户不存在/帐户类型有误	基本流	备选流 5
场景 7 - 帐户余额不足	基本流	备选流 6

注：为方便起见，备选流 3 和 6（场景 3 和 7）内的循环以及循环组合未纳入上表。

对于这 7 个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例 ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。

通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。

TC（测试用例）ID 号	场景/条件	PIN	帐号	输入的金额 （或选择的金额）	帐面金额	ATM 内的金额	预期结果
CW1.	场景 1 - 成功的提款	V	V	V	V	V	成功的提款。
CW2.	场景 2 - ATM 内没有现金	V	V	V	V	I	提款选项不可用，用例结束
CW3.	场景 3 - ATM 内现金不足	V	V	V	V	I	警告消息，返回基本流步骤 6 - 输入金额
CW4.	场景 4 - PIN 有误（还有不止一次输入机会）	I	V	n/a	V	V	警告消息，返回基本流步骤 4，输入 PIN
CW5.	场景 4 - PIN 有误（还有一次输入机会）	I	V	n/a	V	V	警告消息，返回基本流步骤 4，输入 PIN
CW6.	场景 4 - PIN 有误（不再有输入机会）	I	V	n/a	V	V	警告消息，卡予保留，用例结束

在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用例 CW1 称为正面测试用例。它一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。这些负面测试用例由 CW2 至 6 表示（阴影单元格表明这种条件下需要执行备选流）。虽然 CW2 至 6 对于基本流而言都是负面测试用例，但它们相对于备选流 2 至 4 而言是正面测试用例。而且对于这些备选流中的每一个而言，至少存在一个负面测试用例（CW1 - 基本流）。   

每个场景只具有一个正面测试用例和负面测试用例是不充分的，场景 4 正是这样的一个示例。要全面地测试场景 4 - PIN 有误，至少需要三个正面测试用例（以激活场景 4）：

• 输入了错误的 PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤 3 - 输入 PIN。
• 输入了错误的 PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。
• 最后一次输入时输入了“正确”的 PIN。备选流在步骤 5 - 输入金额处重新加入基本流。

注：在上面的矩阵中，无需为条件（数据）输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看 V 和 I（或此处采用的阴影单元格），这种方式还易于判断是否已经确定了充足的测试用例。从上表中可发现存在几个条件不具备阴影单元格，这表明测试用例还不完全，如场景 6 - 不存在的帐户/帐户类型有误和场景 7 - 帐户余额不足就缺少测试用例。

一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。

测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据

TC（测试用例）ID 号	场景/条件	PIN	帐号	输入的金额 （或选择的金额）	帐面金额	ATM 内的金额	预期结果
CW1.	场景 1 - 成功的提款	4987	809 - 498	50.00	500.00	2,000	成功的提款。帐户余额被更新为 450.00
CW2.	场景 2 - ATM 内没有现金	4987	809 - 498	100.00	500.00	0.00	提款选项不可用，用例结束
CW3.	场景 3 - ATM 内现金不足	4987	809 - 498	100.00	500.00	70.00	警告消息，返回基本流步骤 6 - 输入金额
CW4.	场景 4 - PIN 有误（还有不止一次输入机会）	4978	809 - 498	n/a	500.00	2,000	警告消息，返回基本流步骤 4，输入 PIN
CW5.	场景 4 - PIN 有误（还有一次输入机会）	4978	809 - 498	n/a	500.00	2,000	警告消息，返回基本流步骤 4，输入 PIN
CW6.	场景 4 - PIN 有误（不再有输入机会）	4978	809 - 498	n/a	500.00	2,000	警告消息，卡予保留，用例结束

以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括：

• 场景 6 - 帐户不存在/帐户类型有误：未找到帐户或帐户不可用
• 场景 6 - 帐户不存在/帐户类型有误：禁止从该帐户中提款
• 场景 7 - 帐户余额不足：请求的金额超出帐面金额

在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：

• 无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）
• 无法读卡（读卡机堵塞、脱机或出现故障）
• 帐户已消户、冻结或由于其他方面原因而无法使用
• ATM 内的现金不足或不能提供所请求的金额（与 CW3 不同，在 CW3 中只是一种币值不足，而不是所有币值都不足）
• 无法联系银行系统以获得认可
• 银行网络离线或交易过程中断电

在确定功能性测试用例时，确保满足下列条件：

• 已经为每个用例场景确定了充足的正面和负面测试用例。 
• 测试用例可以处理用例所实施的所有业务规则，确保对于业务规则，无论是在内部、外部还是在边界条件/值上都存在测试用例。
• 测试用例可以处理所有事件或动作排序（如在设计模型的序列图中确定的内容），还应能处理用户界面对象状态或条件。
• 测试用例可以处理为用例所指定的任何特殊需求，如最佳/最差性能，有时这些特殊需求会与用例执行过程中的最小/最大负载或数据容量组合在一起。

八、从补充规约中生成测试用例

并不是所有的测试目标需求都将在用例中有所反映。非功能性需求（如性能、安全性和访问控制）以及配置要求等将会说明测试目标的其他行为或特征。补充规约是为其他行为生成测试用例的主要来源。

关于如何生成这些其他测试用例的指南说明如下：

• 为性能测试生成测试用例
• 为安全性/访问控制测试生成测试用例
• 为配置测试生成测试用例
• 为安装测试生成测试用例
• 为其他非功能性测试生成测试用例

为性能测试生成测试用例

性能测试用例的主要输入是补充规约，补充规约中包含了非功能性需求（请参见工件：补充规约）。为性能测试生成测试用例时，请使用下列指南：

• 对于补充规约内阐明性能标准的各条说明都应确保至少要确定一个测试用例。性能标准通常表示为时间/事务、事务量/用户或百分数的形式。
• 对每个关键用例，都应确保至少要确定一个测试用例。关键用例是在上述说明中和/或在工作量分析文档中确定的、必须采用性能评测方法来评估的用例（请参见工件：工作量分析文档）。

与功能性测试的测试用例类似，通常对于每个用例/需求都会存在不止一个测试用例。常见的情况是：存在一个低于性能阈值的测试用例、一个处于阈值上的测试用例，还有一个测试用例高于阈值。

除了以上性能标准以外，确保已确定影响响应时间的特定条件，包括：

• 数据库的大小 - 存在多少个记录？
• 工作量 - 同时执行操作的最终用户的数量和类型，以及要同时执行的事务的数量和类型
• 环境特征（硬件、网件以及软件配置）

将用于性能测试的测试用例记录在类似于功能测试所使用的矩阵中。

以下是各种性能测试的一些示例：

对于负载测试：

TC（测试用例）ID 号	工作量	条件	预期结果
PCW1.	1 （单个 ATM）	完成提款交易	全部交易（不依赖于主角的时间）在 20 秒之内完成
PCW2.	2 （1,000 个同时运行的 ATM）	完成提款交易	全部交易（不依赖于主角的时间）在 30 秒之内完成
PCW3.	3 （10.000 个同时运行的 ATM）	完成提款交易	全部交易（不依赖于主角的时间）在 50 秒之内完成

对于强度测试：

TC（测试用例）ID 号	工作量	条件	预期结果
SCW1.	2 （1,000 个同时运行的 ATM）	数据库锁定 - 2 个 ATM 请求同一帐户	ATM 请求排成队列
SCW2.	2 （1,000 个同时运行的 ATM）	无法实现银行系统的通信	交易排成队列或超时
SCW3.	2 （1,000 个同时运行的 ATM）	在交易过程中，银行系统通信被终止	显示警告消息

为安全性/访问控制测试生成测试用例

主角和用例一同说明系统外部用户与系统所执行的动作之间的交互，以便为特定主角生成测试结果。复杂系统包含许多主角，所以我们编制测试用例时必须确保只有指定执行用例的主角可以进行此操作，这一点非常关键。在基于主角类型的用例事件流存在差别时，尤其如此。

例如，在 ATM 用例中，如果主角“银行客户”的卡和帐户有的属于拥有这个 ATM 机的银行，有的是竞争银行的银行卡（和帐户），或是企图使用该 ATM 不支持的银行卡，则将对该主角“银行客户”执行不同的用例事件流。

对于功能性测试用例，请同样遵循上面列举的指南。

关于安全性和访问控制测试用例的示例：

TC（测试用例）ID 号	条件	卡 （V 表明卡有效）	读卡机 （V 表明读卡机工作正常）	银行的网络	预期结果
ACW1.	在银行网络之内	V	V	V	所有用例都可用
ACW2.	银行网络之外	V	V	I	只有提款用例可用
ACW3.	无法读卡	I	V	V	警告消息，卡被退出
ACW4.	因被盗，卡已挂失	I	V	V	警告消息，卡予保留
ACW5.	卡已过期	I	V	V	警告消息，卡予保留

为配置测试生成测试用例

在典型的分布式系统中，允许存在许多种受支持的硬件和软件组合。为了核实测试目标在不同的配置情况下（如不同的操作系统、浏览器或 CPU 的速度）能否正常工作或执行，应该对此进行测试。此外，测试还应涵盖构件的组合，以便检测在不同构件的交互中产生的缺陷。例如，确保由应用程序安装的 DDL 版本不会与另一个应用程序需要的相同 DDL 的版本发生冲突。

采用下列指南来生成用于配置测试的测试用例：

• 确保对每个关键配置，应至少存在一个测试用例可用于对其进行确定。这是通过确定测试目标的环境所要求的硬件和软件配置以及确定这些配置的优先级来完成的。应确保最先测试最常见的配置，包括：
  • 打印机支持
  • 网络连接 - 局域网和广域网
  • 服务器配置 - 服务器驱动程序、服务器硬件
  • 台式机和/或服务器上安装的其他软件
  • 所有已安装软件的软件版本
• 确保对于每个可能有问题的配置至少存在一个测试用例。这些配置可能包括：
  • 具有最低性能的硬件。
  • 历史上存在兼容性问题的共驻内存的软件。
  • 通过最慢的 LAN/WAN 连接访问服务器的客户机。
  • 资源不足（缓慢的 CPU 速度、最小的内存或分辨率，磁盘空间不足等等）

为安装测试生成测试用例

安装测试需要核实测试目标可以在所有可能的安装情况下安装。安装情况可以指首次安装测试目标，或是在装有较早版本的机器上安装测试目标的某个较新的版本或工作版本。安装测试还应确保在遇到异常情况时（如磁盘空间不足），测试目标的执行情况仍可接受。

测试用例应包含以下各种软件的安装情况：

• 分发介质，例如磁盘、CD-ROM 或文件服务器。
• 首次安装。
• 完全安装。
• 自定义安装。
• 升级安装。

客户机服务器软件的安装程序具备一组特定的测试用例。不同于基于主机的系统，服务器和客户机上的安装程序是有所不同的。因而，安装测试应执行构成测试目标的所有构件的安装，包括客户机、中间层以及服务器，这一点至关重要。

为其他非功能性测试生成测试用例

理论上,应找到所有必需的输入来生成测试用例模型、设计模型以及补充规约工件的测试用例。不过，如果此时您需要补充已有的输入，那也不足为奇。

示例如下：

• 操作测试（用以检验在某次故障发生后以及在下一次故障发生前“较长时间”内软件的运行情况）的测试用例。
• 对性能瓶颈、系统容量或测试目标的强度承受能力进行调查的测试用例。

大多数情况下，您可以通过先前所确定的测试用例生成的某些测试用例来构建其变体或聚合关系体，借此来查找测试用例。

 

九、为单元测试生成测试用例

单元测试要求既测试单元的内部结构同时还要测试其行为特征。测试内部结构要求了解实施单元的方式，基于这种了解的测试被称为白盒测试。对单元行为特征的测试侧重于从外部可观察的单元行为，而不需要了解或考虑其实施方式。基于这种方法的测试称为黑盒测试。基于这两种方法所生成的测试用例的说明如下。

白盒测试

理论上，应通过代码测试每一条可能的路径。在所有这些非常简单的单元内实现这样的目标是不切实际或几乎是不可能的。作为最基本的测试，应将每个决定到决定路径（DD 路径）测试至少一次，这样可确保将所有语句至少执行一次。决定通常是指 if 语句，而 DD 路径是两个决定之间的路径。

要达到这种程度的测试覆盖，建议您在选择测试数据时应使每个决定都可以用每种可能的方法来评估。为达到上述目标，测试用例应确保：

每个布尔表达式的求值结果为 true 和 false。例如，表达式 (a<3) OR (b>4) 的求值结果为 true/false 的四种组合
每一个无限循环至少要执行零次、一次和一次以上。
可使用代码覆盖工具来确定白盒测试未测试到的代码。在进行白盒测试的同时应进行可靠性测试。

示例：

假设您对类 Set of Integers 中的 member 函数执行结构测试。该测试在二进制搜索的帮助下，将检查该集合是否包含了某个指定的整数。

成员 (member) 函数以及相应的流程图。虚线箭头指示出如何通过采用两个测试用例将所有语句至少执行一次。

理论上，对于彻底测试的某个操作，测试用例应遍历代码内路径的所有组合情况。在 member 函数的 while-loop 中存在三个可选择的路径。测试用例可以多次遍历该循环，或是根本就不遍历。如果测试用例根本就没有遍历循环，则在代码中只能找到一条路径。如果遍历循环一次，您将发现有三条路径。如果遍历两次，则您将发现存在六条路径，如此类推。因而，路径的总数应该是：1+3+6+12+24+48+...，在实际情况中，这个路径组合总数根本无法无法处理。这就是为什么必须选择所有这些路径的子集的原因。本示例中，可以采用两个测试用例来执行所有的语句。其中一个测试用例中，您可以选择 Set of Integers = {1,5,7,8,11}，而且测试数据 t = 3。在另一个测试用例中，您可以选择 Set of Integers = {1,5,7,8,11}，且 t = 8。

黑盒测试

黑盒测试的目的是为了在不了解单元将如何实施指定行为的情况下，对指定行为进行验证。黑盒测试侧重并依赖于单元的输入和输出。

等价类划分是一种用来减少所需测试数量的技术。对于每一个操作都应确定参数和对象状态的等价类。等价类是一组值的集合，对这组值来说，对象的行为应类似。例如，一个集合可有三个等价类：空、若干元素以及满。

可使用代码覆盖工具来确定白盒测试未测试到的代码。在进行黑盒测试的同时应进行可靠性测试。

接下来的两个小节说明了如何通过选择特定参数的测试数据来确定测试用例。

基于输入参数的测试用例
输入参数是由某个操作使用的参数。对于以下每个输入条件，都应通过使用每个操作的输入参数来编制测试用例： 

每个等价类的正常值。
每个等价类的边界值。
等价类之外的值。
非法值。
请记住要将对象状态视作输入参数。例如：如果在对集合这个对象测试添加操作，您必须使用集合内所有等价类的值来测试添加操作。所有等价类的值指的是：充满元素的集合、有若干元素的集合、以及空集合。

基于输出参数的测试用例
输出参数是某个操作所改变的参数。某个参数既可以是输入参数也可以是输出参数。根据以下每个条件选择输入，以便获得输出。

每个等价类的正常值。
每个等价类的边界值。
等价类之外的值。
非法值。
请记住将对象状态视为输出参数。例如，假设您对某个列表测试删除操作，您必须选择输入值以便执行操作之后，列表为充满状态、具有若干元素或为空（采用它的所有等价类的值进行测试）。

如果对象受状态控制（根据对象的状态产生不同的反应），您应利用状态矩阵，如下图所示：

用于测试的状态矩阵。您可以在此矩阵的基础上测试激励和状态的所有组合。

十、为产品验收测试生成测试用例

产品验收测试是部署软件前的最后测试操作。验收测试的目标在于核实软件是否已经准备就绪，而且可以由最终用户按软件设计来执行功能和任务。产品验收测试通常不仅涉及执行软件以确认其是否准备就绪，还涉及交付给客户的所有产品工件，如培训、文档和包装。

为软件工件生成测试用例是按上文中说明的方式实现的。测试用例可与上面确定的测试用例（正式）或某个子集（非正式）相同或类似，这取决于产品验收测试的正式程度。不管测试用例的深度如何，应该在实施和执行产品测试之前对测试用例和产品验收计划达成共识。

对非软件工件的评估将随着被评估工件的不同而相去甚远。请参见每个特定非软件工件的指南以及核对清单，查看这些工件的评估内容和评估方式。

十一、为回归测试编制测试用例

回归测试比较同一测试目标的两个工作版本或版本，并将差异确定为潜在缺陷。据此可假定：新版本应该象早先版本一样操作，并确保并未因为版本的变化而带来缺陷。

理想状态下，您可能希望一次迭代内的所有测试用例都能在后续迭代内使用。应遵照下列指导原则来确定、设计并实施测试用例，这些测试用例可以最大限度地发挥回归测试和复用的价值，同时将维护的成本减至最低：

确保测试用例只确定关键的数据元素（创建/支持被测试的条件所需的数据元素）
确保每个测试用例都说明或代表一个唯一的输入集或事件序列，其结果是独特的测试目标行为
消除多余或等效的测试用例
将具有相同的测试目标初始状态和测试数据状态的测试用例组合到一起

C/S结构与B/S结构的特点分析

为了区别于传统的C/S模式，才特意将其称为B/S模式。认识到这些结构的特征，对于系统的选型而言是很关键的。

  1、系统的性能

  在系统的性能方面，B/S占有优势的是其异地浏览和信息采集的灵活性。任何时间、任何地点、任何系统，只要可以使用浏览器上网，就可以使用B/S系统的终端。

  不过，采用B/S结构，客户端只能完成浏览、查询、数据输入等简单功能，绝大部分工作由服务器承担，这使得服务器的负担很重。采用C/S结构时，客户端和服务器端都能够处理任务，这虽然对客户机的要求较高，但因此可以减轻服务器的压力。而且，由于客户端使用浏览器，使得网上发布的信息必须是以HTML格式为主，其它格式文件多半是以附件的形式存放。而HTML格式文件（也就是Web页面）不便于编辑修改，给文件管理带来了许多不便。

  2、系统的开发

  C/S结构是建立在中间件产品基础之上的，要求应用开发者自己去处理事务管理、消息队列、数据的复制和同步、通信安全等系统级的问题。这对应用开发者提出了较高的要求，而且迫使应用开发者投入很多精力来解决应用程序以外的问题。这使得应用程序的维护、移植和互操作变得复杂。如果客户端是在不同的操作系统上，C/S结构的软件需要开发不同版本的客户端软件。但是，与B/S结构相比，C/S技术发展历史更为“悠久”。从技术成熟度及软件设计、开发人员的掌握水平来看，C/S技术应是更成熟、更可靠的。

  3、系统的升级维护

  C/S系统的各部分模块中有一部分改变，就要关联到其它模块的变动，使系统升级成本比较大。B/S与C/S处理模式相比，则大大简化了客户端，只要客户端机器能上网就可以。对于B/S而言，开发、维护等几乎所有工作也都集中在服务器端，当企业对网络应用进行升级时，只需更新服务器端的软件就可以，这减轻了异地用户系统维护与升级的成本。如果客户端的软件系统升级比较频繁，那么B/S架构的产品优势明显——所有的升级操作只需要针对服务器进行，这对那些点多面广的应用是很有价值的，例如一些招聘网站就需要采用B/S模式，客户端分散，且应用简单，只需要进行简单的浏览和少量信息的录入。

  4、C/S 模式的优点和缺点

  ★ C/S 模式的优点
  ● 由于客户端实现与服务器的直接相连，没有中间环节，因此响应速度快。
  ● 操作界面漂亮、形式多样，可以充分满足客户自身的个性化要求。
  ● C/S结构的管理信息系统具有较强的事务处理能力，能实现复杂的业务流程。

  ★ C/S 模式的缺点
  ● 需要专门的客户端安装程序，分布功能弱，针对点多面广且不具备网络条件的用户群体，不能够实现快速部署安装和配置。
  ● 兼容性差，对于不同的开发工具，具有较大的局限性。若采用不同工具，需要重新改写程序。
  ● 开发成本较高，需要具有一定专业水准的技术人员才能完成。

  5、B/S模式的优点和缺点

  ★ B/S 模式的优点
  ● 具有分布性特点，可以随时随地进行查询、浏览等业务处理。
  ● 业务扩展简单方便，通过增加网页即可增加服务器功能。
  ● 维护简单方便，只需要改变网页，即可实现所有用户的同步更新。
  ● 开发简单，共享性强。

  ★ B/S 模式的缺点
  ● 个性化特点明显降低，无法实现具有个性化的功能要求。
  ● 操作是以鼠标为最基本的操作方式，无法满足快速操作的要求。
  ● 页面动态刷新，响应速度明显降低。
  ● 无法实现分页显示，给数据库访问造成较大的压力。
  ● 功能弱化，难以实现传统模式下的特殊功能要求。
  近年来，随着软硬件技术发展和人们意识的提高，Web应用得到广泛的普及，一方面在互联网浪潮的推动下，基于互联网的信息共享和电子商务不断发展，像新浪、搜狐、8848等大型网站不断涌现出来，另一方面随着Java、CGI等网络技术的成熟，基于B/S结构的大型软件逐渐显示出巨大的优势。同时，也就产生了一个焦点问题，什么样的服务器能够满足不同用户的需求，怎么能够保证Web服务器能够长期稳定地运行，为了满足这样的需求Web测试也就同样变得十分重要。

　　当前Web测试主要通过Web测试工具加上良好的测试案例完成的，我们认为主要有以下两种测试类型：基准测试、非基准测试

　　基准测试：主要指测试工具已经提供了标准的测试案例库，包括静态测试案例（HTM、JPG）、动态测试案例（CGI）和SSL测试案例等。这类测试工具分为测试案例库、控制台程序、客户端程序三个部分。它的原理是，Web服务器开启特定的Web服务程序，并且运行上述测试案例，由控制台程序控制各个客户端按照一定的脚本访问顺序遍历Web服务器的各个测试案例，每个请求完成后，各个客户端向控制台报告访问的结构，当一个测试集完成后由控制台将所有的信息综合统计，测试过程中控制台还需要采用SNMP协议对服务器进行实时监控，综合两个方面的因素可以反映出Web服务器在不同压力情况下的综合性能。

　　在测试过程中，主要影响测试结果的因素有网络环境、客户端性能。目前无论IA架构服务器还是SUN、HP、IBM的UNIX服务器性能都越来越优越，有可能出现在100MB网络下不能够提供足够的网络压力，有可能网络首先出现瓶颈，这样就需要扩展到1000MB网络环境或使用多个网段对服务器提供足够的压力，而稳定的客户端对于测试来说也是十分重要的，因为客户端如果出现性能下降，就会造成系统崩溃或者不能提供稳定的测试压力从而导致测试结果出现偏差；一台客户端到底能够稳定运行多少数量的连接是根据不同的硬件配置和操作系统决定的，因此对客户端的硬件资源进行监控是保证客户端可以稳定运行的必要手段。

　　由于这类测试工具使用的是工具开发商提供的测试案例集，虽然也具有一定的权威性，但是目前再完美的测试案例集也不能涵盖所有的Web应用情况，所以也不能够完全体现出Web服务器完整的性能，因此该类测试工具更加适合IT媒体对Web类服务器软硬件的横向对比测试，在测试对象和环境大体统一的情况下，可以比较出各个测试对象的性能差异。而对于有实际应用背景的Web服务器进行测试，使用这样的测试工具就不适合了，我们在以后的测试漫谈中会继续介绍。

在跟使用Loadrunner工具使用者交流的过程中，经常有人提到这个问题，基于HTML（HyperText Markup Language 超文本置标语言）模式录制与基于URL（Uniform Resource Locator的缩写，统一资源定位符，也被称为网页地址，是因特网上标准的资源的地址。）录制模式到底有什么不同？为什么通常情况下我们都会去选择使用 URL模式去录制我们的业务脚本？所以在这里我把我知道的东西写出来跟同行分享和交流：

HTML是一种高级别的录制模式，这种模式是基于“浏览器”或者说是“内容敏感”的。这种录制选项是让浏览器去决定在回放下载HTML资源，哪些页面资源（比如图片或者Flash内容）是需要被下载。

URL是一种低级别的录制模式，这种录制选项不允许浏览器去确定哪些页面资源（比如图片或者Flash内容）是需要下载的。每项资源在录制回话的过程中都被录制到脚本中。这种级别录制模式同时也会录制其他任何隐藏的对象，比如session ID（也就是会话ID）信息，包括发给服务端和从服务端收到的session ID信息。

脚本方面的不同，HTML级别录制模式将生成的是web_submit_form 语句来提交终端用户可以看见或者修改的信息。当基于HTML模式在提交窗体时遇到错误，你可以选择URL模式去录制任何从服务端发送过来的请求和资源。而URL基本录制模式将生成的是web_submit_data语句，这些语句记录的是所有通过浏览器实际发送给服务端的信息。值得注意的是URL录制模式会录制那些HTML模式没有能录制到隐藏信息。通常情况下，隐藏信息里面会包含session ID信息。

写到这里，熟悉的人可能应该明白为什么在通常的情况下，我们选择URL模式去录制我们基于Web（HTTP/HTML）协议的脚本，概括的说就是现在的应用（或者说将来的应用）为了安全性，都会包含像session ID、token等动态信息。简单的说就是每一访问，服务端都会给客户端发送一个描述会话的session信息，而session ID使用的是动态的生成技术。如果要是脚本能够正常回放，通常需要把这个动态的信息保存下来，这个需要使用到correlation 技术（也就是关联技术）。在以后我会在我的博客里面继续写我对关联的理解（包括自动关联、手工关联、规则等实用技术）。

请根据您以往的学习和工作经历，结合您的个人经验回答以下问题。您可以尽可能详细和完整的表达出自己的思想，如果书写空间不够，您可以将答案写在题目所在页的背面。如果需要稿纸请同接待人员联系。
01. 为什么要在一个团队中开展软件测试工作？

因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。

02. 您是否了解以往所工作的企业的软件测试过程？如果了解，请试述在这个过程中都有哪些工作要做？分别由哪些不同的角色来完成这些工作？
 
03. 您是否了解以往所工作的企业的软件开发过程？如果了解，请试述一个完整的开发过程需要完成哪些工作？分别由哪些不同的角色来完成这些工作？（对于软件测试部分，可以简述）

04. 您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？

我曾经做过web测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。最擅长的是功能测试

 
05. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）

测试类型有：功能测试，性能测试，界面测试。
　　功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
　　性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
　　界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
　　区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试

06. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
　　白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

　　软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
　　1、是否有不正确或遗漏的功能？
　　2、在接口上，输入是否能正确的接受？能否输出正确的结果？
　　3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
　　4、性能上是否能够满足要求？
　　5、是否有初始化或终止性错误？

　　软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
　　1、对程序模块的所有独立的执行路径至少测试一遍。
　　2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
　　3、在循环的边界和运行的界限内执行循环体。
　　4、测试内部数据结构的有效性，等等。

　　单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

　　单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

　　集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。

　　系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）

　　系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

　　验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

07. 测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？

软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）

08. 您认为做好测试计划工作的关键是什么？

1. 明确测试的目标，增强测试计划的实用性
　　编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
　　2．坚持“5W”规则，明确内容与过程
　　“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
　　3．采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
　　4. 分别创建测试计划与测试详细规格、测试用例
　　应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

09. 您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

　1．等价类划分
　　划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

　　2．边界值分析法
　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
　　使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

3．错误推测法
　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

4．因果图方法
　　前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

10. 您认为做好测试用例设计工作的关键是什么？

白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题

11. 请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程。

首先：得到相关文档（需求文档和设计文档），理解需求和设计设计思想后，想好测试策略（测试计划简单点就OK了），考虑到测试环境，测试用例，测试时间等问题。
　　第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的网站的输入数据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处理的，有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。处理过程中，会经历3个步骤，网站才算完成了它的任务。有3个步骤呢，就可以分别对　　这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多50个用例。界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示。
　　第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环
　　第四步：执行测试

12. 您以往的工作中是否曾开展过测试用例的评审工作？如果有，请描述测试用例评审的过程和评审的内容。

13. 您以往是否曾经从事过性能测试工作？如果有，请尽可能的详细描述您以往的性能测试工作的完整过程。

14. 您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

15. 您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？

16. 在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

17. 您以往所从事的软件测试工作中，是否使用了一些工具来进行软件缺陷（Bug）的管理？如果有，请结合该工具描述软件缺陷（Bug）跟踪管理的流程。

18. 您以往是否曾经从事过单元测试和集成测试？如果有，请谈一下这些工作的实际开展情况。

 19. 您如何看待软件过程改进？在您曾经工作过的企业中，是否有一些需要改进的东西呢？您期望的理想的测试人员的工作环境是怎样的？

20. 您以往工作过的企业中，是否开展了软件配置管理工作？您能否描述一下这项工作的开展情况和您对这项工作的认识？

21. 您是否熟悉一些主流的软件工程方法论和思想，如RUP、CMM、CMMI、XP、PSP、TSP。如果熟悉，您是否可以谈一下对这些方法论和思想的认识？

22. 您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？

23. 在您以往的测试工作中，最让您感到不满意或者不堪回首的事情是什么？您是如何来对待这些事情的？

24. 在即将完成这次笔试前，您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会？（可以包括软件测试、过程改进、软件开发或者与此无关的其他方面）

一、概述
   一般而言，软件测试从项目确立时就开始了，前后要经过以下一些主要环节：
   需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM.

   在进行有关问题阐述前，我们先明确下分工，一般而言，需求分析、测试用例编写、测试环境搭建、测试执行等属于测试开发人员工作范畴，而测试执行以及缺陷提交等属于普通测试人员的工作范畴，测试负责人负责整个测试各个环节的跟踪、实施、管理等。

说明：

1．以上流程各环节并未包含软件测试过程的全部，如根据实际情况还可以实施一些测试计划评审、用例评审，测试培训等。在软件正式发行后，当遇到一些严重问题时，还需要进行一些后续维护测试等。

2．以上各环节并不是独立没联系的，实际工作千变万化，各环节一些交织、重叠在所难免，比如编写测试用例的同时就可以进行测试环境的搭建工作，当然也可能由于一些需求不清楚而重新进行需求分析等。这就和我们国家提出建设有中国特色的社会主义国家一样，只所以有中国特色，那是因为国情不一样。所以在实际测试过程中也要做到具体问题具体分析，具体解决。

二、测试流程

   需求分析

   需求分析（Requirment Analyzing）应该说是软件测试的一个重要环节，测试开发人员对这一环节的理解程度如何将直接影响到接下来有关测试工作的开展。可能有些人认为测试需求分析无关紧要，这种想法是很不对的。需求分析不但重要，而且至关重要！

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

   总得说来，做测试需求分析的依据有软件需求文档、软件规格书以及开发人员的设计文档等，相信管理一些规范的公司在软件开发过程中都有这些文档。

   测试计划

   测试计划（Test Plan）一般由测试负责人来编写。测试计划的依据主要是项目开发计划和测试需求分析结果而制定。测试计划一般包括以下一些方面：

1．  测试背景

  a. 软件项目介绍；

  b. 项目涉及人员（如软硬件项目负责人等）介绍以及相应联系方式等。

2．  测试依据

  a.  软件需求文档；

  b.  软件规格书；

  c.  软件设计文档；

  d.  其他，如参考产品等。

3．  测试资源

  a.  测试设备需求；
 
  b.  测试人员需求；

  c.  测试环境需求；

  d.  其他。

4． 测试策略

  a. 采取测试方法；

  b.  搭建哪些测试环境；

  c.  采取哪些测试工具以测试管理工具；

  d.  对测试人员进行培训等。

5． 测试日程

  a.  测试需求分析；

  b.  测试用例编写；

  c.  测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，α、β测试阶段等），每个阶段的工作重点以及投入资源等。

6．  其他。

  测试计划还要包括测试计划编写的日期、作者等信息，计划越详细越好了。计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照原有计划开展。如在软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。所以，这些就要求测试负责人能够从宏观上来调控了。在变化面前能够做到应对自如、处乱不惊那是最好不过了。

   测试设计

   测试设计主要包括测试用例编写和测试场景设计两方面。

  一份好的测试用例对测试有很好的指导作用，能够发现很多软件问题。关于测试用例编写，请参见前面写的《也谈测试用例》一文，里面有详细阐述。

   测试场景设计主要也就是测试环境问题了.不同软件产品对测试环境有着不同的要求。如C/S及B/S架构相关的软件产品，那么对不同操作系统，如Windows系列、unix、linux甚至苹果OS等，这些测试环境都是必须的。而对于一些嵌入式软件，如手机软件，如果我们想测试一下有关功能模块的耗电情况，手机待机时间等，那么我们可能就需要搭建相应的电流测试环境了。当然测试中对于如手机网络等环境都有所要求。

  测试环境很重要，符合要求的测试环境能够帮助我们准确的测出软件问题，并且做出正确的判断。

  为了测试一款软件，我们可能根据不同的需求点要使用很多不同的测试环境。有些测试环境我们是可以搭建的，有些环境我们无法搭建或者搭建成本很高。不管如何，我们的目标是测试软件问题，保证软件质量。测试环境问题，还是根据具体产品以及开发者的实际情况而采取最经济的方式吧。

   测试执行

  测试执行过程又可以分为以下阶段：

  单元测试→集成测试→系统测试→出厂测试，其中每个阶段还有回归测试等。

  从测试的角度而言，测试执行包括一个量和度的问题。也就是测试范围和测试程度的问题。 比如一个版本需要测试哪些方面？每个方面要测试到什么程度？

  从管理的角度而言，在有限的时间内，在人员有限甚至短缺的情况下，要考虑如何分工，如何合理地利用资源来开展测试。当然还要考虑以下问题：

1．当测试人员测试的执行不到位、敷衍了事时该如何解决？

2．测试效率问题，怎样提高测试效率？

3．根据版本的不同特点是只做验证测试还是采取冒烟测试亦或是系统全面测试？

4．当测试过程中遇到一些偶然性随机问题该怎样处理？

5．当版本中出现很多新问题时该怎样对待？测试停止标准？

6．  ……

总之，测试执行过程中会遇到很多复杂的问题，还是那句话，具体问题具体解决！本文不做过多阐述。

   测试记录

  缺陷记录总的说来包括两方面：由谁提交和缺陷描述。

  一般而言，缺陷都是谁测试谁提交，当然有些公司可能为了保证所提交缺陷的质量，还会在提交前进行缺陷评估，以确保所提交的缺陷的准确性。

  在缺陷的描述上，至少要包括以下一些方面内容：

 序号
 标题
 预置条件
 操作步骤
 预期结果
 实际结果
 注释
 严重程度
 概率
 版本
 测试者
 测试日期
 
另外，一个版本软件测试完毕，还要根据测试情况出份测试报告，这也是所要经过的一个环节。

  缺陷管理

 缺陷管理方面，很多公司都采取缺陷管理工具来进行管理，常见缺陷管理工具有Test Director、Bugfree等。

   软件评估

  这里评估指软件经过一轮又一轮测试后，确认软件无重大问题或者问题很少的情况下，对准备发给客户的软件进行评估，以确定是否能够发行给客户或投放市场。

   软件评估小组一般由项目负责人、营销人员、部门经理等组成，也可能是由客户指定的第三方人员组成。

   测试总结

   每个版本有每个版本的测试总结，每个阶段有每个阶段的测试总结，当项目完成RTM后，一般要对整个项目做个回顾总结，看有哪些做的不足的地方，有哪些经验可以对今后的测试工作做借鉴使用，等等。测试总结无严格格式、字数限制。应该说，测试总结还是很总要的。

  测试维护

  由于测试的不完全性，当软件正式release后，客户在使用过程中，难免遇到一些问题，有的甚至是严重性的问题，这就需要修改有关问题，修改后需要再次对软件进行测试、评估、发行。

01.什么是软件测试？

   软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。

   软件测试在软件生存期中横跨两个阶段：通常在编写出每一个模块之后就对它做必要的测试（称为单元测试）。模块的编写者与测试者是同一个人。编码与单元测试属于软件生存期中的同一个阶段。在这个阶段结束之后，对软件系统还要进行各种综合测试，这是软件生存期的另一个独立的阶段，即测试阶段，通常由专门的测试人员承担这项工作。

02.白盒测试有哪几种方法？

   白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。

03.Alpha和Beta测试的区别.

 大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试，目的是从实际终端用户的使用角度，对软件的功能和性能进行测试，以发现可能只有最终用户才能发现的错误。

Alpha测试（α测试）是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应该在Alpha测试前准备好。

Beta测试（β测试）是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。因而，Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产品发行的人员来管理。

由于Alpha和Beta测试的组织难度大，测试费用高，测试的随机性强、测试周期跨度较长，测试质量和测试效率难于保证，所以，很多专业软件可能不再进行Beta测试。随着测试技术的提高，以及专业测试服务机构的大量涌现，很多软件的Beta测试外包给这些专业测试机构进行测试。

 

 

01. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同
　　测试类型有：功能测试，性能测试，界面测试。
　　功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内       部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价、类划分边界值分析、错误推测、因果图和综合策略。
　　性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测     试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能     提供的最大服务级别的测试。
　　界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同     人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的     畏惧与放弃中付诸东流。
　　区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注    于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数     据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试.

02．您认为做好测试用例设计工作的关键是什么？
 白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
 黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题.

03.请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

   黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
　　白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

   软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
　　1、是否有不正确或遗漏的功能？
　　2、在接口上，输入是否能正确的接受？能否输出正确的结果？
　　3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
　　4、性能上是否能够满足要求？
　　5、是否有初始化或终止性错误？

　　软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
　　1、对程序模块的所有独立的执行路径至少测试一遍。
　　2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
　　3、在循环的边界和运行的界限内执行循环体。
　　4、测试内部数据结构的有效性，等等。

　　单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

　　单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

　　集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。

　　系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）
    系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

　　验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

 04. 测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？
　　软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）.

05. 您认为做好测试计划工作的关键是什么？
　　1. 明确测试的目标，增强测试计划的实用性
　　编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
　　2．坚持“5W”规则，明确内容与过程
　　“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
　　3．采用评审和更新机制，保证测试计划满足实际需求
     测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
　　4. 分别创建测试计划与测试详细规格、测试用例
　　应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

06. 您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
　　1．等价类划分
　　划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

　　2．边界值分析法
　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
　　使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚f大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

 3．错误推测法
　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

4．因果图方法
　　前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

 

22 什么是“软件测试”？

  Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features ofthe software item

1就是一个通过分析软件和需求之前差异，发现bug,对软件的功能进行评价的过程。

2.软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。

3.软件测试是为了发现错误而执行程序的过程。

23 什么是“测试案例”?

 测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的工作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设置、输入数据要求、步骤、以及预期的结果。

24 如果时间不够，无法进行充分的测试怎么办?

使用风险分析，确定测试的重点。由于很少有机会对一个应用软件进行所有可能的测试 (包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西)，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。需要考虑下列因素：

1) 对于该项目的用途而言，哪种功能最重要?

2) 哪种功能对用户最明显?

3) 哪种功能对安全影响最大?

4) 哪种功能对用户最有用?

5)对客户来说，该应用软件的哪个部分最重要?

6)在开发过程中，该应用软件的哪个部分可以最先测试?

7)哪一部分代码最复杂，容易导致出现错误?

8)哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?

9)哪一部分程序与过去项目中引起问题的部分相类似/有关?

10)哪一部分程序与过去项目中需要大量维护的部分相类似/有关?

11)需求和设计的那些部分不清楚或不容易读?

12)开发人员认为在应用软件中哪些部分是高风险的?

13)哪些问题能造成最差的发行?

14)哪些问题最能引起用户抱怨?

15)哪些测试可以容易地覆盖多种功能?

16)哪些测试在覆盖高风险部分的测试时使用时间最少?

25 如果需求一直在变化怎么办?

1)如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。

2)如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。

3)好的代码注释和好的文档有助于开发人员作出相应的改变。

4)只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。

5)在项目的时间表中应当留出余量，以应付可能出现的变更。

6)尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。

7)通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。

8)要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。

9)在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。

10)在设计自动测试剧本时，试图使其有一些灵活性。

11)在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。

12)对变更进行适当的风险分析，以减少回归测试的要求。

13)在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。

14)少注意详细的测试计划和测试案例，要把重点放在专门的测试 (ad hoc testing) 上。

26.软件测试分哪两种方法？分别适合什么情况？
　
　　软件测试方法一般分为两种：白盒测试与黑盒测试。白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试，它着重于程序的内部结构及算法，通常不关心功能与性能指标；黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试，它实际上是站在最终用户的立场，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。
　
27.一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。
　
　　计划阶段、设计阶段、白盒单元、白盒集成、黑盒单元、黑盒集成、系统测试、回归测试、验收测试一套完整的测试应该由五个阶段组成：

  1）测试计划首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准。以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。
　
　　2）测试设计将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响测试结果的有效性）。
　
　　3）测试开发建立可重复使用的自动测试过程。
　
　　4）测试执行执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理，测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。
　
　　5）测试评估结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。
　
28.软件测试的类型有那些？分别比较这些不同的测试类型的区别与联系。
　
　　BVT （Build Verification Test），主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确Scenario Tests（基于用户实际应用场景的测试），Scenario Tests优点是关注了用户的需求，缺点是有时候难以真正模仿用户真实的使用情况Smoke Test，修复Bug后，针对此次修复是否会对其他模块造成影响而进行的专门测试。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低此外，还有Application Compatibility Test（兼容性测试），主要目的是为了兼容第三方软件，确保第三方软件能正常运行，用户不受影响。Accessibility Test（软件适用性测试），是确保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。其它的测试还有Functional Test（功能测试）、Security Test（安全性测试）、Stress Test（压力测试）、Performance Test（性能测试）、Regression Test（回归测试）、Setup/Upgrade Test（安装升级测试）等

29.测试用例通常包括那些内容？着重阐述编制测试用例的具体做法不同结构的用例包括的不一样。（版本、编号、项目、设计人员、设计日期、输入、预期输出……）
　 
   软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。

  用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

  测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” .重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

   操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

   预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

30.描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程

   1) 测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。

   2) 经验证无误后，修改状态为VERIFIED.待整个产品发布后，修改为CLOSED. 

   3) 还有问题，REOPENED，状态重新变为“New"，并发邮件通知。

   4) 项目组长根据具体情况，重新reassigned分配给bug所属的开发者。

   5) 若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明）

   6) 开发者收到Email信息后，判断是否为自己的修改范围。

   7) 若不是，重新reassigned分配给项目组长或应该分配的开发者。

   8) 测试人员查询开发者已修改的bug，进行重新测试。（可创建test case附件）
　
    

11.专业词语解释

α测试:

Alpha测试（α测试）是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应该在Alpha测试前准备好。

β测试

Beta测试（β测试）是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。因而，Beta测试是 在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产品发行的人员来管理。

驱动模块:

驱动模块在大多数场合称为"主程序"，它接收测试数据并将这些数据传递到被测试模块.单元测试一个函数单元时，被测单元本身是不能独立运行的，需要为其传送数据，为此  写驱动

驱动模块主要完成以下事情：
1、接受测试输入；
2、对输入进行判断；
3、将输入传给被测单元，驱动被测单元执行；
4、接受被测单元执行结果，并对结果进行判断；
5、将判断结果作为用例执行结果输出测试报告。

桩模块

比如对函数A做单元测试时，被测的函数单元下还包括了一个函数B，为了更好的错误，定位错误，就要为函数B写桩，来模拟函数B的功能，保证其正确。

白盒测试

白盒测试(White-box Testing，又称逻辑驱动测试,结构测试),它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。

对开发语言的支持：白盒测试工具是对源代码进行的测试，测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。目前测试工具主要支持的开发语言包括：标准C、C＋＋、Visual C＋＋、Java、Visual J＋+等。

静态测试

动态通过评审文档、阅读代码等方式测试软件称为静态测试,通过运行程序测试软件称为测试.在动态测试中,通常使用白盒测试和黑盒测试从不同的角度设计测试用例,查找软件代码中的错误.

12、 回归测试

回归测试的目的是在程序有修改的情况下，保证原有功能正常的一种测试策略和方法。
说白了就是，我们测试人员在对程序进行测试时发现bug，然后返还程序员修改，程序员修改后发布新的软件包或新的软件补丁包给我们测试人员，我们就要重新对这个程序测试，已保证程序在修正了以前bug的情况下，正常运行，且不会带来新的错误的这样一个过程。  一般情况下是不需要全面测试的，而是根据修改的情况进行有效的测试。

13、单元测试、集成测试、系统测试的侧重点是什么？

单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等。

集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接以及参数的传递等。

系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。测试重点是整个系统的运行以及与其他软件的兼容性。

14、设计用例的方法、依据有那些？  

白盒测试用例设计有如下方法:基本路径测试\等价类划分\边界值分析\覆盖测试\循环测试\数据流测试\程序插桩测试\变异测试.这时候依据就是详细设计说明书及其代码结构

黑盒测试用例设计方法:基于用户需求的测试\功能图分析方法\等价类划分方法\边界值分析方法\错误推测方法\因果图方法\判定表驱动分析方法\正交实验设计方法.依据是用户需求规格说明书,详细设计说明书。

15、集成测试通常都有那些策略？

1、在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
2、各个子功能组合起来，能否达到预期要求的父功能；
3、一个模块的功能是否会对另一个模块的功能产生不利的影响；
4、全局数据结构是否有问题；
5、单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。

16、一个缺陷测试报告的组成

测试软件项目名称,每个要测试软件项目都有唯一的名称，有的公司对项目还有特定的编号。

测试软件版本号,测试周期内，一般需要测试多个软件版本，报告错误时，一定要正确填写产生错误的软件版本号。

测试者名称,便于分清责任，便于管理。

测试日期与时间,便于分析和统计错误报告信息。

测试软件环境,包括操作系统和其他必要的软件程序。

测试硬件环境,包括测试计算机和其他测试设备的配置信息。

错误描述,简明的描述错误的特征，便于查询和快速浏览。

错误标识编号 (ID#) ,每个错误都有一个唯一的标识编号，方便查询。

错误类型,根据错误类型，分配给适当的人员处理错误。

错误级别,错误的严重程度和处理的优先级，优先处理高级别的错误。

错误状态,错误状态表明错误是否已经处理和将怎样处理，根据错误状态，采用适当的处理方法。

错误处理者名称,便于分清责任，便于管理。

重现错误的操作步骤,便于重现错误，修复错误和验证错误。

期望的结果,描述满足设计要求的结果。

实际测试结果,描述实际测试后得到的结果。

必要的附图,便于确认错误的表现形式和错误位置。

测试者的建议等注释,便于错误处理者快速和正确处理错误

17、基于WEB信息管理系统测试时应考虑的因素有哪些？

一、功能测试

    1、链接测试 

    2、表单测试

    3、Cookies测试

    4、设计语言测试 

    5、数据库测试

二、性能测试

    1、连接速度测试 

    2、负载测试  

    3、压力测试  

三、可用性测试

    1、导航测试  

    2、图形测试

    3、内容测试

    4、整体界面测试

四、客户端兼容性测试

    1、平台测试   

    2、浏览器测试  

五、安全性测试

18、软件本地化测试比功能测试都有哪些方面需要注意？

 软件本地化测试的测试策略：

1.本地化软件要在各种本地化操作系统上安装并测试。

2.源语言软件安装在另一台相同源语言操作系统上，作为对比测试。

3.重点测试因本地化引起的软件的功能和软件界面的错误。

4.测试本地化软件的翻译质量。

5.手工测试和自动测试相结合

19、软件测试项目从什么时候开始？为什么？

  软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发过程中产生的所有产品都测试,并且软件缺陷存在放大趋势.缺陷发现的越晚,修复它所花费的成本就越大.

20、需求测试注意事项有哪些？

一个良好的需求应当具有一下特点：
完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

正确性：每一项需求都必须准确地陈述其要开发的功能。

一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。

可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。

健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。

必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。

可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。

可修改性：每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。

另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。

可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（f i n e - g r a i n e d ）的方式编写并单独标明，而不是大段大段的叙述。

21、简述一下缺陷的生命周期

    软件缺陷的生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。

简单的软件缺陷生命周期：
1、发现——打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员；
2、打开——修复：开发人员再现、修复缺陷，然后提交测试人员去验证；
3、修复——关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。

但是这是一种理想的状态，在实际的工作中是很难有这样的顺利的，需要考虑的各种情况都还是非常多的。

复杂的软件缺陷生命周期：
1、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，不是代码问题，就是设计需要修改；
2、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，以后修改的，就可以延期；
3、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，实际没有这个bug，可以将其关闭；
4、新建一个软件缺陷，这个软件缺陷是（open）状态，看是否 清楚可重现，如果不能重现，就是缺少信息，需要返回到（open）状态；如果能够重现，就进行修正，修正后关闭，进行回归测试。
 软件缺陷生命

将收集到的软件测试方面的面试笔试题做个汇总,不断累积增加,尽量提供答案;一方面是对测试理论知识的学习,一方面为需要这方面资源的人提供参考.

 

1、软件测试的目的？
    答：测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。

 2、需求文档测试：主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现；
    设计文档测试：测试设计是否符合全部需求以及设计是否合理。

 3、什么是软件测试？  

答：软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。

 4、白盒测试有哪几种方法？

   答：白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。

5. 软件的缺陷等级应如何划分？

   1．致命错误，可能导致本模块以及其他相关模块异常，死机等问题；
   2．严重错误，问题局限在本模块，导致模块功能失效或异常退出
   3．一般错误，模块功能部分失效；
   4．建议问题，由问题提出人对测试对象的改进意见；

 附加: 软件缺陷的分类与管理

　 在软件缺陷中还有一种分法，跟据缺陷内容来分，主要分为需求Bug与程序Bug，对于这种分法的好处就是明确了Bug处理的责任人。对于程序Bug我们都知道是由相关开发人员进行处理。下面主要讨论一下需求Bug,需求Bug从名称上来就知道是要交由需求人员进行处理，可怎么处理，怎样在处理的过程中有效的让这些创意得到体现。现在我们都有Bug管理系统，这时我们的测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理，不过这里我想强调的是对需求Bug的定位，如果这个Bug在软件需求说明书中明确提到了，这时就不可能定位它为需求Bug，它是必需让程序员实现的，称为软件功能缺陷，提交由程序员进行处理。但如果需求说明书没有明确提到的，我们则可以定位为需求Bug.

6. 如果能够执行完美的黑盒测试，还需要进行白盒测试吗？(白盒与黑盒的区别)

   任何工程产品（注意是任何工程产品）都可以使用以下两种方法之一进行测试。 
   黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。 
   白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
   软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：

　  1、是否有不正确或遗漏的功能？

    2、在接口上，输入是否能正确的接受？能否输出正确的结果？

    3、是否有数据结构错误或外部信息（例如数据文件）访问错误？

    4、性能上是否能够满足要求？

    5、是否有初始化或终止性错误？

   软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：

　  1、对程序模块的所有独立的执行路径至少测试一遍。

    2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。

    3、在循环的边界和运行的界限内执行循环体。

    4、测试内部数据结构的有效性，等等。

   以上事实说明，软件测试有一个致命的缺陷，即测试的不完全、不彻底性。由于任何程序只能进行少量（相对于穷举的巨大数量而言）的有限的测试，在未发现错误时，不能说明程序中没有错误。   

7. 测试退出标准

    测试退出标准为完成测试需求中列出的所有功能及测试过程中发现缺陷的回归测试。

    1. 单元测试退出标准

    1) 单元测试用例设计已经通过评审 
    2) 核心代码100％ 经过Code Review 
    3) 单元测试功能覆盖率达到100％ 
    4) 单元测试代码行覆盖率不低于80％ 
    5) 所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准
    6) 不存在A、B类缺陷 
    7) C、D、E类缺陷允许存在 
    8) 按照单元测试用例完成了所有规定单元的测试 
    9) 软件单元功能与设计一致

    2. 集成测试退出标准

    1) 集成测试用例设计已经通过评审 
    2) 所有源代码和可执行代码已经建立受控基线，纳入配置管理受控库，不经过审批不能随意更改 
    3) 按照集成构件计划及增量集成策略完成了整个系统的集成测试 
    4) 达到了测试计划中关于集成测试所规定的覆盖率的要求 
    5) 集成工作版本满足设计定义的各项功能、性能要求 
    6) 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准 
    7) A、B类BUG不能存在 
    8) C、D类BUG允许存在,但不能超过单元测试总BUG的50％ 
    9) E类BUG允许存在

    3. 系统测试退出标准

    1) 系统测试用例设计已经通过评审 
    2) 按照系统测试计划完成了系统测试 
    3) 系统测试的功能覆盖率达100％ 
    4) 系统的功能和性能满足产品需求规格说明书的要求 
    5) 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准 
    6) 系统测试后不存在A、B、C类缺陷 
    7) D类缺陷允许存在，不超过总缺陷的5％ 
    8) E类缺陷允许存在，不超过总缺陷的10％

8. 测试计划的目的是什么？

   答：测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。

9. 软件测试应该划分几个阶段?简述各个阶段应重点测试的点?各个阶段的含义？

   大体上来说可分为单元测试,集成测试,系统测试,验收测试,每个阶段又分为以下五个步骤:

   测试计划，测试设计，用例设计，执行结果，测试报告

   初始测试集中在每个模块上，保证源代码的正确性，，该阶段成为单元测试，主要用白盒测试方法。
   接下来是模块集成和集成以便组成完整的软件包。集成测试集中在证实和程序构成问题上。     主要采用黑盒测试方法，辅之以白盒测试方法。
   软件集成后，需要完成确认和系统测试。确认测试提供软件满足所有功能、性能需求的最后保证。确认测试仅仅应用黑盒测试方法。

   单元测试  
   单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。
   集成测试  
   集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。
   系统测试 
   系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。
   验收测试  
   验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集.
   回归测试  
   回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。

10. 针对缺陷采取怎样的管理措施？

   1. 要更好的管理缺陷，必须引入缺陷管理工具，商用的或者开源的都可。
   2. 根据缺陷的生命周期，考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。
   3. 所有发现的缺陷（不管是测试发现的还是走读代码发现的）都必须全部即时的、准确的提交 到缺陷管理工具中，这是缺陷提交的管理。
   4. 缺陷提交后，需要即时的指派给相应的开发人员，提交缺陷的人需要密切注意缺陷的状态， 帮助缺 陷的尽快解决。缺陷解决后需要即时对缺陷的修复进行验证。这样的目的有两个：一个是让缺陷尽快解决；二是方便后面缺陷的分析（保证缺陷相关的信息准确，如龄期等），这是缺陷状态的管理。
   5. 为了更好的改进开发过程和测试过程，需要对缺陷进行分析，总结如缺陷的类别、缺陷的龄期分布等信息，这是缺陷分析的管理。

 

在软件工程中，测试是一个工程过程，是针对软件这一特殊产品的一道生产工序，是软件质量保证的重要一环。也就是说，软件测试不是项目管理过程的需要，而是软件工程过程的需要。

　　目前在软件开发的项目管理过程中，整体的工程过程主要包括这样几个主要步骤：

　　1、由客户提出业务设想，分析市场可行性后，由与技术部门初步讨论技术可行性。

　　2、由技术部门编写解决方案建议书。解决方案通常是为了向客户和投资方说明如何能够解决问题的方案，以获得订单或投资。解决方案建议书的内容包括技术方案、实施方案（初步的项目计划）、项目成本估算，随后提交给客户，由客户进行评审、立项。http://blog.mypm.net

　　从工程过程的角度来说，其中的技术方案所决定的，主要包括两个内容：

　　（1） 根据客户初步的业务需求，定义了业务处理流程中的人机接口，以及所要开发计算机系统的对外数据接口和程序接口，从而确定了计算机系统的边界。此项工作可以视为由技术部门帮助业务部门澄清了软件需求。

　　（2） 不仅是定义应用软件部分的业务需求，其实也同时决定了未来的运行环境要求。运行环境要求是软件设计的一个重要前提。项目管理者联盟文章，深入探讨。

　　3、在开发部门内部，根据批准的解决方案，针对业务需求进行分析和设计：

　　（1） 一方面内部组织项目，制定项目计划，包括项目预算，对项目范围进行跟踪管理，保证最终能够满足客户项目范围的要求。客户立项时的项目范围，包括实现的业务功能、业务的部署范围要求等，在技术部门内部往往需要通过多个内部项目、多个项目阶段、多个维护任务等不同的过程组织形式来完成，项目组织过程比较复杂，项目周期也很长，所以需要对项目范围进行跟踪管理。这方面的内容虽然是属于项目管理的范畴，但也直接影响到工程范围，所以需要在工程过程管理中同时予以考虑。

　　（2） 另一方面开始进行需求分析、业务功能分析和总体设计，根据业务处理流程定义出应用系统的边界，即我们要开发的计算机系统的对外接口（用户界面、数据接口、程序调用接口等），细化针对业务需求的分析和设计，将业务需求映射到软件系统上，最终能够定义出针对软件系统的功能需求。这一环节直接关系到后续的技术活动最终是否能够满足业务需求的要求。

　　4、通过对业务需求的分析和设计，可以得到所涉及的各软件系统的功能需求，据此开始在软件系统一级进行功能分析和设计，根据系统本身的技术结构特点，将软件系统的功能需求分解到软件模块一级，形成软件模块的功能需求。

　　5、将软件模块的功能需求进一步分解，成为程序级的功能要求，由程序员来实现。

　　可以看出，上述过程是一个自顶向下的分解过程，每一个分解的步骤中，分析方法本质上都是相同的。

关键字：软件测试方法

　　6、常用功能键的功能测试

　　（1） 保存---所有编辑页面如果未输入任何信息值而单击“保存”，系统应该给出“XXX字段不允许为空”的提示信息

　　（2） 保存---如果某字段输入值有错误或超出长度范围，那么单击“保存”按钮时，系统应该给出相应的提示信息

　　（3） 保存---输入相关信息单击“保存”后，建议系统给出“保存成功”提示信息

　　（4） 保存---测试新增/修改信息保存后，信息列表是否自动刷新

　　（5） 下一步---单击此按钮，如果有非空字段为空，系统应该给出相应提示信息；如果有字段输入非法值，单击此按钮系统应该给出相应提示信息；正常情况下单击此功能按钮，系统进入到下一个编辑/操作界面

　　（6） 上一步---单击此功能按钮，系统应该正确返回到上一个编辑/操作界面

　　（7） 浏览---测试该功能键功能是否已经正确实现，单击此按钮系统应该弹出文件选择页面，并且可以选择输入相关附件

　　（8） 上传附件---测试上传功能已经正确实现，确认上传的附件在界面相应位置是否显示

　　（9） 下载---测试下载功能已经正确实现（可以将上传到服务器的附件下载的本地相应位置）

　　（10） 重新上传---保存操作后上传功能按钮名称应该自动变为“重新上传”，并且可以重新上传附件

　　（11） 发布---测试该功能键功能已经正确实现，单击些功能按钮系统完成发布操作，相应的信息状态变为“已发布”，发布人、发布时间系统自动生成或已经正确保存（注意：已经发布的信息是不允许再进行修改操作的）（根据系统需求及设计测试，有些系统只有信息修改页面才有此功能）

　　（12） 取消发布---测试该功能键功能是否已经正确实现，单击此功能按钮系统完成取消发布功能，相应信息状态变为“未发布”（根据系统需求及设计测试，有些系统只有信息修改页面才有此功能）

　　（13）  关闭---单击此功能按钮系统将关闭当前页面，建议当单击此功能按钮时系统弹出“确认离开此页面提示信息”

　　（14） 查询---单击查询功能按钮，系统按钮输入查询条件进行模糊查询；查询条件输入非法值进行查询操作，系统应该查询0记录

　　（15） 删除----未勾选待删除记录单击此按钮系统弹出相应提示信息；正常情况下系统删除所选记录

　　（16） 选择---勾选待选记录，单击此按钮系统完成选择操作；单击选择超链接功能按钮系统完成选择操作

　　（17） 取消选择---单击此功能按钮，系统完成取消选择操作（清除所有选择信息）

11、对用户名、密码的有效性测试

　　（1） 密码信息有效性测试：特殊字符、正常字符、空字符（不输入）、空格

　　（2） 登陆名是否区分大小写 

　　（3） 登陆名是否允许重名 

　　（4） 用户名字和密码都为最大长度 （边界值分析，取上点） 

　　（5） 用户名字和密码都为最小长度 （边界值分析，取上点）

　　（6） 用户名字和密码都是非最大和最小长度的数据（边界值分析，取内点） 

　　（7） 用户名长度大于要求1位（边界值分析，取离点） 

　　（8） 用户名长度小于要求1位（边界值分析，取离点）

　　（9）  密码长度大于要求1位（边界值分析，取离点） 

　　（10） 密码长度小于要求1位（边界值分析，取离点） 

　　（11） 是否记住上次登陆名

　　（12） 密码信息有效性测试：字母数字混排、数字、符号数字、字母符号、数字符号、空字符（不输入）、空格 、ASCII字符、字符串在有空格、串在有半角空格

　　（13） 口令锁定：即输入口令次数的限制 

　　（14） 密码显示是否以星号或者别的符号显示

　　（15） 看是否支持tap和enter键等

　　（16） 密码是否可以复制粘贴

　　密码修改测试方法

　　（1） 不输入旧密码，直接改密码

　　（2）  输入错误旧密码 

　　（3） 不输入确认新密码 

　　（4） 不输入新密码

　　（5）  新密码和确认新密码不一致 

　　（6） 新密码中有空格

　　（7） 新密码长度有效性测试方法同上

　　（8） 新密码为非允许字符（如有的密码要求必须是英文和数字组成，那么要试汉字和符号等）

　　（9） 测试密码是否区分大小写，新密码中英文小写，确认密码中英文大写

　　（10）  新密码与旧密码一样能否修改成功

四、权限测试

　　1、业务权限

　　按需求测试用户业务权限分配是否正确，业务权限主要控制功能模块、功能菜单的展示，没有相应业务权限的不展示其功能模块能功能菜单。

　　2、操作权限

　　（1） 权限组：按组用户来分配操作权限。（组内所有人员都具有所分配的操作权限）

　　（2） 测试已分配操作权限的功能按钮是可见的

　　（3） 测试已分配操作权限的功能按钮是否可用；是否可以正确完成相应功能操作

　　（4） 通常不分配调看操作权限是无法进行修改操作

　　五 、算法

　　1、 测试前需要充分了解算法的整个计算过程及结果值的精度

　　2、算法测试之前需要准备充足，而且是准确无误的测试实例

　　3、根据输入值确认系统计算输出结果是否与预期结果完全一致

　　4、如果计算公式中含有引用其它模块的数据，需要先确认数据提取是否对应的正确

　　5、先用等价划分法、边界值测试方法测试输入数据是否在需求范围内

　　6、 严格按照测试用例执行测试，确认计算结果是否正确无误，注意结果的精度。

软件测试方法的总结，是lxm_lxm根据个人所做过的项目整理的，提供给新来的的朋友们。

　　软件测试方法总结

　　一、界面

　　● 界面测试

　　（1） 测试界面设计是否合理、简洁、美观，操作是否方便

　　（2） 功能键、数据项信息是否齐全

　　（3） 确认系统中同一功能抌名称是否统一

　　（4） 设计样式、风格（查询条件样式；输入风格（点选/手输入）；）是否与系统其它模块统一

　　（5） 确认页面内所有字段名称显示风格是否统一（居中、左对齐、右对齐，一般采用居中显示风格）

　　1、新增页面及功能测试

　　● 字段

　　在开始测试时应该保证数据的正确性，然后再从系统中找出各种Bug

　　（1） 各字段输入正确的信息值保存，确认系统是否可以正确完成新增操作。

　　（2） 进入添加界面不输入任何信息值，单击“保存”功能按钮，系统应该给出某个不允许为空字段的提示信息（属于边界测试）

　　（3） 建议不允许为空的字段前面加上‘*’作为标记（统一性，方便性问题）

　　（4） 编码/编号字段不允许输入中文及特殊字符，否则系统应该给出相应的提示信息

　　（5） 测试编码/编号字段不允许重复，否则系统应该给出相应的提示信息

　　（6） 确认字段是否已做长度限制，如果输入值超出长度范围，那么在保存时系统应该给出提示信息

　　（7） 非法测试，如：校验数值型字段输入非数值，保存时系统是否给出相应的提示信息（根据实际需要确定数值型字段是否能够接受负数）

　　（8） 边界测试，如：确认数值型字段的边界值（如：有效值为‘0-100’整数，那么输入-1或101保存时系统应该给出相应的提示信息；输入值为0、100系统应该能正确保存信息值；输入0到100内的整数值系统应该正确保存信息值）

　　（9） 精确值测试，测试小数位数是否在定义的长度内

　　（10） 字段精确值是否正确（四舍五入否）。

　　（11） 根据实际情况测试名称字段是否具有唯一性，（一般情况下名称是不允许重复的，具体问题具体分析），否则系统应该给出相应的提示信息

　　（12） 确认各字段名称书写是否正确（注意：要求编辑界面、住息列表中、错误提示信息、查询条件中的字段名称完全相同）

　　（13） 确认特殊格式的字段是否已做标准格式的限制（如：电子邮件、邮编等）

　　（14） 测试上级信息字段（如：上级XXX名称、上级XXX编号）的信息值是否根据所选择的上级XXX名称系统自动生成（注意：编号生成值一定是维护界面的编号，而不应该是相应表的那个主键编码）

　　（15） 测试如果某字段信息值是从另一个模块中选择输入的，那么需要确认其它相关联字段的信息值是否也相应的正确的自动带入，并且这些字段应该都是只读的

　　（16） 创建人/编辑人、发布人、创建时间、创建人字段应该设为只读的，而且此类字段值应该默认当前操作人的姓名

　　（17） 如果某个字段可以点选输入多个信息值，那么测试该字段是否接受，并保存了点选输入的多个信息值

　　（18） 对于多选字段，测试是否具有记忆上次选择值并已验重

　　（19） 测试字符型字段是否可以接受空格（统一性问题，建议不要接受空格）

　　（20） 引用其它模块的字段信息值的字段长度是否与被引用模块相应字段长度一致

本文出自51Testing论坛，由会员lxm_lxm发布，转载请注明出处。

很多年轻或者刚刚从事测试工作的工程师，经常会问：“测试工程师需要什么技能或者具有什么素质才是合格的？”与开发人员相比，测试人员不但需要一技之长，还需要掌握诸如操作系统、数据库、网络等多方面的知识。
经过这几年的发展，国内IT公司的测试水平有了很大的提高，但是与此同时，很多测试工程师也迎来了个人的发展瓶颈：很多人从测试工程师做到了测试经理的职位，不知道下一步如何发展；或者每天机械地从事着功能测试工作。
根据作者多年的经验，一个有竞争力的测试人员要具有下面三个方面的素质：
1.         计算机专业技能
计算机领域的专业技能是测试工程师应该必备的一项素质，是做好测试工作的前提条件。尽管没有任何IT背景的人也可以从事测试工作，但是一名要想获得更大发展空间或者持久竞争力的测试工程师，则计算机专业技能是必不可少的。计算机专业技能主要包含三个方面：
l         测试专业技能
现在软件测试已经成为一个很有潜力的专业。要想成为一名优秀的测试工程师，首先应该具有扎实的专业基础，这也是本书的编写目的之一。因此，测试工程师应该努力学习测试专业知识，告别简单的“点击”之类的测试工作，让测试工作以自己的专业知识为依托。
测试专业知识很多，本书内容主要以测试人员应该掌握的基础专业技能为主。测试专业技能涉及的范围很广：既包括黑盒测试、白盒测试、测试用例设计等基础测试技术，也包括单元测试、功能测试、集成测试、系统测试、性能测试等测试方法，还包括基础的测试流程管理、缺陷管理、自动化测试技术等知识。
l         软件编程技能
“测试人员是否需要编程？”可以说是测试人员最常提出的问题之一。实际上，由于在我国开发人员待遇普遍高于测试人员，因此能写代码的几乎都去做开发了，而很多人则是因为做不了开发或者不能从事其它工作才“被迫”从事测试工作。最终的结果则是很多测试人员只能从事相对简单的功能测试，能力强一点的则可以借助测试工具进行简单的自动化测试（主要录制、修改、回放测试脚本）。
软件编程技能实际应该是测试人员的必备技能之一，在微软，很多测试人员都拥有多年的开发经验。因此，测试人员要想得到较好的职业发展，必须能够编写程序。只有能给编写程序，才可以胜任诸如单元测试、集成测试、性能测试等难度较大的测试工作。
此外，对软件测试人员的编程技能要求也有别于开发人员：测试人员编写的程序应着眼于运行正确，同时兼顾高效率，尤其体现在与性能测试相关的测试代码编写上。因此测试人员要具备一定的算法设计能力。依据作者的经验，测试工程师至少应该掌握Java、C#、C++之类的一门语言以及相应的开发工具。
l         网络、操作系统、数据库、中间件等知识：
与开发人员相比，测试人员掌握的知识具有“博而不精”的特点，“艺多不压身”是个非常形象的比喻。由于测试中经常需要配置、调试各种测试环境，而且在性能测试中还要对各种系统平台进行分析与调优，因此测试人员需要掌握更多网络、操作系统、数据库等知识。
在网络方面，测试人员应该掌握基本的网络协议以及网络工作原理，尤其要掌握一些网络环境的配置，这些都是测试工作中经常遇到的知识。
操作系统和中间件方面，应该掌握基本的使用以及安装、配置等。例如很多应用系统都是基于Unix、linux来运行的，这就要求测试人员掌握基本的操作命令以及相关的工具软件。而WebLogic、Websphere等中间件的安装、配置很多时候也需要掌握一些。
数据库知识则是更应该掌握技能，现在的应用系统几乎离不开数据库。因此不但要掌握基本的安装、配置，还要掌握SQL。测试人员至少应该掌握Mysql、MS Sqlserver、Oracle等常见数据库的使用。
作为一名测试人员，尽管不能精通所有的知识，但要想做好测试工作，应该尽可能地去学习更多的与测试工作相关的知识。
2.         行业知识
行业主要指测试人员所在企业涉及的行业领域，例如很多IT企业从事石油、电信、银行、电子政务、电子商务等行业领域的产品开发。行业知识即业务知识，是测试人员做好测试工作的又一个前提条件，只有深入地了解了产品的业务流程，才可以判断出开发人员实现的产品功能是否正确。
很多时候，软件运行起来没有异常，但是功能不一定正确。只有掌握了相关的行业知识，才可以判断出用户的业务需求是否得到了实现。
行业知识与工作经验有一定关系，通过时间即可以完成积累。
3.         个人素养[1]
作为一名优秀的测试工程师，首先要对测试工作有兴趣：测试工作很多时候都是显得有些枯燥的，因此热爱测试工作，才更容易做好测试工作。因此，除了具有前面的专业技能和行业知识外，测试人员应该具有一些基本的个人素养，即下面的“五心”。
专心：主要指测试人员在执行测试任务的时候要专心，不可一心二用。经验表明，高度集中精神不但能够提高效率，还能发现更多的软件缺陷，业绩最棒的往往是团队中做事精力最集中的那些成员。
细心：主要指执行测试工作时候要细心，认真执行测试，不可以忽略一些细节。某些缺陷如果不细心很难发现，例如一些界面的样式、文字等。
耐心：很多测试工作有时候显得非常枯燥，需要很大的耐心才可以做好。如果比较浮躁，就不会做到“专心”和“细心”，这将让很多软件缺陷从你眼前逃过。
责任心：责任心是做好工作必备的素质之一，测试工程师更应该将其发扬光大。如果测试中没有尽到责任，甚至敷衍了事，这将会把测试工作交给用户来完成，很可能引起非常严重的后果。
自信心：自信心是现在多数测试工程师都缺少的一项素质，尤其在面对需要编写测试代码等工作的时候，往往认为自己做不到。要想获得更好的职业发展，测试工程师们应该努力学习，建立能“解决一切测试问题”的信心。
“五心”只是做好测试工作的基本要求，测试人员应该具有的素质还很多。例如测试人员不但要具有团队合作精神，而且应该学会宽容待人，学会去理解“开发人员”，同时要尊重开发人员的劳动成果——开发出来的产品。

一. 方法简介

　　1.定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

　　2.因果图法产生的背景：

　　等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。

　　如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

　　3.因果图介绍

　　1) 4种符号分别表示了规格说明中向4种因果关系。

　　2) 因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。

　　3) Ci表示原因，通常置于图的左部；ei表示结果，通常在图的右部。Ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现。

　　4. 因果图概念

　　1) 关系

　　① 恒等：若ci是1，则ei也是1；否则ei为0。

　　② 非：若ci是1，则ei是0；否则ei是1。

　　③ 或：若c1或c2或c3是1，则ei是1；否则ei为0。“或”可有任意个输入。

　　④ 与：若c1和c2都是1，则ei为1；否则ei为0。“与”也可有任意个输入。

　　 2) 约束

　　输入状态相互之间还可能存在某些依赖关系，称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。

　　A.输入条件的约束有以下4类：

　　① E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。

　　② I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。

　　③ O约束（唯一）；a和b必须有一个，且仅有1个为1。

　　④ R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。

　　B.输出条件约束类型

　　输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。

　　5. 采用因果图法设计测试用例的步骤：

　　1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。

　　2) 分析软件规格说明描述中的语义，找出原因与结果之间, 原因与原因之间对应的关系，根据这些关系,画出因果图。

　　3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现，为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。

　　4) 把因果图转换为判定表。

　　5) 把判定表的每一列拿出来作为依据,设计测试用例。

二. 实战演习

　　1. 某软件规格说明书包含这样的要求：第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改，但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息。

　　解答：

　　1) 根据题意，原因和结果如下：

　　原因：

　　1——第一列字符是A；

　　2——第一列字符是B；

　　3——第二列字符是一数字。

　　结果：

　　21——修改文件；

　　22 ——给出信息L；

　　23——给出信息M。

　　2) 其对应的因果图如下：

　　11为中间节点；考虑到原因1和原因2不可能同时为1，因此在因果图上施加E约束。

　　3) 根据因果图建立判定表。

　　表中8种情况的左面两列情况中，原因①和原因②同时为1，这是不可能出现的，故应排除这两种情况。表的最下一栏给出了6种情况的测试用例，这是我们所需要的数据。

　　2. 有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。

　　1) 分析这一段说明，列出原因和结果

　　原因：

　　1.售货机有零钱找

　　2.投入1元硬币

　　3.投入5角硬币

　　4.押下橙汁按钮

　　5.押下啤酒按钮

　　结果：

　　21.售货机〖零钱找完〗灯亮

　　22.退还1元硬币

　　23.退还5角硬币

　　24.送出橙汁饮料

　　25.送出啤酒饮料

　　2) 画出因果图，如图所示。所有原因结点列在左边，所有结果结点列在右边。建立中间结点，表示处理的中间状态。中间结点：

　　11. 投入1元硬币且押下饮料按钮

　　12. 押下〖橙汁〗或〖啤酒〗的按钮

　　13. 应当找5角零钱并且售货机有零钱找

　　14. 钱已付清

　　3) 转换成判定表：

　　4) 在判定表中，阴影部分表示因违反约束条件的不可能出现的情况，删去。第16列与第32列因什么动作也没做，也删去。最后可根据剩下的16列作为确定测试用例的依据。

一. 方法简介

　　1. 定义：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

　　2. 错误推测方法的基本思想：

　　列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

　　1) 例如, 输入数据和输出数据为0的情况；输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

　　2) 例如，前面例子中成绩报告的程序，采用错误推测法还可补充设计一些测试用例：

　　I.程序是否把空格作为回答

　　II. 在回答记录中混有标准答案记录

　　III.除了标题记录外，还有一些的记录最后一个字符即不是2也不是3

　　IV.有两个学生的学号相同

　　V. 试题数是负数。

　　3) 再如，测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况：

　　I.输入的线性表为空表；

　　II. 表中只含有一个元素；

　　III.输入表中所有元素已排好序；

　　IV.输入表已按逆序排好；

　　V. 输入表中部分或全部元素相同。

　　二. 实战演习

　　 暂无

一.方法简介

　　1.定义

　　是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。

　　2.划分等价类：

　　等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。

　　1)有效等价类

　　是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

　　2)无效等价类

　　与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。

　　设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。

　　3.划分等价类的标准：

　　1)完备测试、避免冗余;

　　2)划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合;

　　3)并是整个集合：完备性;

　　4)子集互不相交：保证一种形式的无冗余性;

　　5)同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到"相同的执行路径"。

　　4.划分等价类的方法

　　1)在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如：输入值是学生成绩，范围是0～100；

　　2)在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下,可确立一个有效等价类和一个无效等价类；

　　3)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。

　　4)在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。

　　例：输入条件说明学历可为:专科、本科、硕士、博士四种之一，则分别取这四种这四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类。

　　5)在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；

　　6)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。

　　5.设计测试用例

　　在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件：有效等价类、无效等价类，然后从划分出的等价类中按以下三个原则设计测试用例：

　　1)为每一个等价类规定一个唯一的编号；

　　2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步，直到所有的有效等价类都被覆盖为止；

　　3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止。

二.实战演习

　　1.某程序规定："输入三个整数 a 、 b 、 c 分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型，当此三角形为一般三角形、等腰三角形及等边三角形时，分别作计算 … "。用等价类划分方法为该程序进行测试用例设计。（三角形问题的复杂之处在于输入与输出之间的关系比较复杂。）

　　分析题目中给出和隐含的对输入条件的要求：

　　（1）整数 （2）三个数 （3）非零数 （4）正数

　　（5）两边之和大于第三边 （6）等腰 （7）等边

　　如果 a 、 b 、 c 满足条件（ 1 ） ~ （ 4 ），则输出下列四种情况之一：

　　1)如果不满足条件（5），则程序输出为 " 非三角形 " 。

　　2)如果三条边相等即满足条件（7），则程序输出为 " 等边三角形 " 。

　　3)如果只有两条边相等、即满足条件（6），则程序输出为 " 等腰三角形 " 。

　　4)如果三条边都不相等，则程序输出为 " 一般三角形 " 。

　　列出等价类表并编号

　　 覆盖有效等价类的测试用例：

　　a b c 覆盖等价类号码

　　3 4 5 （1）--（7）

　　4 4 5 （1）--（7），（8）

　　4 5 5 （1）--（7），（9）

　　5 4 5 （1）--（7），（10）

　　4 4 4 （1）--（7），（11）

　　覆盖无效等价类的测试用例：

2.设有一个档案管理系统，要求用户输入以年月表示的日期。假设日期限定在1990年1月~2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的"日期检查功能"。

　　1)划分等价类并编号,下表等价类划分的结果

输入等价类	有效等价类	无效等价类
日期的类型及长度	①6位数字字符	②有非数字字符 ③少于6位数字字符 ④多于6位数字字符
年份范围	⑤在1990~2049之间	⑥小于1990 ⑦大于2049
月份范围	⑧在01~12之间	⑨等于00 ⑩大于12

　　2)设计测试用例，以便覆盖所有的有效等价类在表中列出了3个有效等价类，编号分别为①、⑤、⑧，设计的测试用例如下：

　　测试数据 期望结果 覆盖的有效等价类

200211 输入有效 ①、⑤、⑧

　　3)为每一个无效等价类设计一个测试用例，设计结果如下：

　　测试数据 期望结果 覆盖的无效等价类

95June 无效输入 ② 20036 无效输入③ 2001006无效输入 ④ 198912 无效输入 ⑥ 200401 无效输入 ⑦ 200100 无效输入 ⑨ 200113 无效输入 ⑩

　　3.NextDate 函数包含三个变量：month 、 day 和 year ，函数的输出为输入日期后一天的日期。 例如，输入为 2006年3月 7日，则函数的输出为 2006年3月8日 。要求输入变量 month 、 day 和 year 均为整数值，并且满足下列条件：

①1≤month≤12 ②1≤day≤31 ③1920≤year≤2050

　　1)有效等价类为：

　　

M1＝{月份：1≤月份≤12} D1＝{日期：1≤日期≤31} Y1＝{年：1812≤年≤2012}

　　2)若条件 ① ~ ③中任何一个条件失效，则 NextDate 函数都会产生一个输出，指明相应的变量超出取值范围，比如 "month 的值不在 1-12 范围当中 " 。显然还存在着大量的 year 、 month 、 day 的无效组合， NextDate 函数将这些组合作统一的输出： " 无效输入日期 " 。其无效等价类为：

M2＝{月份：月份<1} M3＝{月份：月份>12} D2＝{日期：日期<1} D3＝{日期：日期>31} Y2＝{年：年<1812} Y3＝{年：年>2012} 弱一般等价类测试用例 月份 日期 年 预期输出 6 15 1912 1912年6月16日

　　强一般等价类测试用例同弱一般等价类测试用例

　　注：弱--有单缺陷假设；健壮--考虑了无效值

　　(一)弱健壮等价类测

　　

用例ID 月份 日期 年 预期输出 WR1 6 15 1912 1912年6月16日 WR2 -1 15 1912 月份不在1～12中 WR3 13 15 1912 月份不在1～12中 WR4 6 -1 1912 日期不在1～31中 WR5 6 32 1912 日期不在1～31中 WR6 6 15 1811 年份不在1812～2012中 WR7 6 15 2013 年份不在1812～2012中

　　(二)强健壮等价类测试

　　

用例ID 月份 日期 年 预期输出 SR1 -1 15 1912 月份不在1～12中 SR2 6 -1 1912 日期不在1～31中 SR3 6 15 1811 年份不在1812～2012中 SR4 -1 -11912 两个无效一个有效 SR5 6 -1 1811 两个无效一个有效 SR6 -1 15 1811 两个无效一个有效 SR7 -1 -11811 三个无效

　　4.佣金问题等价类测试用例，它是根据佣金函数的输出值域定义等价类，来改进测试用例集合。

输出销售额≤1000元 佣金10％ 　　1000<销售额≤1800 佣金=100+(销售额-1000)*15% 　　销售额>1800 佣金=220+(销售额-1800)*20% 　　测试用例 枪机(45) 枪托(30) 枪管(25) 销售额 佣金

　　

1 5 5 5 500 50 2 15 15 15 1500 175 3 25 25 25 2500 360

　　根据输出域选择输入值，使落在输出域等价类内，可以结合弱健壮测试用例结合。