http://www.csai.cn　　作者：袁琳　　来源：希赛网　　2006年12月1日

  软件行业飞速发展，软件企业面临日趋激烈的市场竞争，常常面临这样的问题：
如何不断推陈出新，保持持续的竞争力。
    如何在短时间内完成软件产品或软件项目的研发，最大化的满足客户需求。
    如何及时跟踪不断变化和升级的开发方法、技术实现方式，来提高研发效率。
    显然，这些问题反映出当前的软件开发模式越来越趋向于由市场驱动，软件企业需要不断适应市场变化、适应不断增长的用户需求、尽快研发并发布新产品、同时需要创造出高质量的软件产品。因此，对于软件开发来说，做好软件项目开发过程中时间、成本、质量的平衡尤为关键。软件开发的时间、成本是有限的，在给定的产品或项目背景下，如何控制软件发布质量、交付用户最满意的产品是一个巨大的挑战！
 
    很多人会说，在激烈的市场竞争面前，产品质量是企业的命脉，是重中之重，必须要保证软件产品的“零缺陷”，于是他们便挖空心思生搬硬套 6sigma、CMM… 结果导致软件开发过程过于形式化、官僚主义，软件创新迟缓、不能快速占领市场，产品交付给用户后，用户说：这不是我想要的！
 
    诚然，产品质量是企业生命的基石。不可否认，6sigma、CMM 是值得研究学习的科学理论，在军事航天、科研探索、大型电信领域都有非常成功的案例。但是，国内的众多中小企业面临巨大的市场竞争压力与内部发展创新的需要，还一味照搬6sigma，就值得反思了，是否有必要耗费大量时间、资源追求每百万个产品的不良品率少于3.4呢？
 
    我们总是期望某种软件开发模式或开发方法能够适用任何类型、特点的软件开发过程，能够开发出高质量的软件产品，可是每当我们实际应用时，却总是会发觉，理想与现实的巨大差距。所以，软件开发方式、质量控制原则的实用性更重要。必须针对不同的软件开发特点，制定不同的质量控制原则。
 
    随着各种敏捷开发方法及其它一些“轻量”开发方法的逐渐兴起，越来越多的软件组织意识到敏捷方法对于软件新产品开发有着良好的指导作用，在市场竞争中能够快速影响需求、缩短研发周期、及时放量发布，这样更有利于降低软件开发过程中的各种风险，通过不断与用户的沟通反馈，不断交付给用户满意的软件产品。越来越多的软件开发团队开始尝试各种敏捷实践，同时也在探索敏捷开发过程中的质量原则。在敏捷开发中，倡导质量Good Enough就OK，那么这个Enough到底是多少呢？在没有明确的原则的情况下，Good Enough  Quality（GEQ）概念滥用，满意质量常被用来为软件中明显存在的缺陷做辩解，甚至有人认为软件供应商在软件产品中保留臭虫（Bug）是一种蓄意行为甚至是聪明的策略，这无疑造成了很大误解。
 
    在2001年“敏捷联盟”建立之后不久，著名的软件测试科学家James Bach根据自己多年的实践经验和理论基础就针对不同软件开发的方法在满意质量的基础上提出了相应的质量原则。
    满意质量的原则进行了系统化定义，满意质量定义如下：
    （1）可带来足够的利益；
    （2）不存在致命性问题；
    （3）所带来的利益超过问题所造成的损失；
    （4）在当前条件下综合考虑所有因素后，进一步的改进所带来的损害大于其带来的帮助。
 
    同时，James Bach提供了一个用于评估GEQ的框架，该框架包括四个GEQ元素和六个GEQ视角，它们构成了一个提示问题集，可用来帮助相互沟通，或者帮助进行产品开发、产品改进、实现更好的实践活动等。GEQ框架的概要描述：
 
GEQ元素（factor）
　　四个元素基于GEQ的定义进行扩展，为评估软件产品质量。 
    1. 评估产品的利益
　　鉴别——对于产品的受益人而 言具有什么已知利益或潜在利益？
　　可能性——假设产品正如所设计的那样工作， 受益人有多大可能性会认识到每个利益？
　　影响——对受益人而 言， 每个利益的期望程度如何？
　　个体重要程度——从个体考虑， 哪些利益是完全不 可替代的？
　　整体利益——作为一个整体且假设没有问题， 是否具有足够的利益以满足受益人？ 
    2. 评估产品的问题
　　鉴别——对于产品的受益人而 言具有什么已知问题或潜在问题？
　　可能性——受益人有多大可能性会发现每个问题？
　　影响——对受益人而 言， 每个问题的破坏程度如何？是否可以继续工作？
　　个体重要程度——从个体考虑， 哪些问题是完全不 可接受的？
　　整体问题——所有问题叠加在一起会怎样？是否有太多的非关键问题？ 
    3. 评估产品质量
　　整体质量——根据GEQ视角， 利益是否看来超值于问题？
　　安全/完美边际值——如果需要或想要使利益超值于问题， 那么至少需要投入多少？ 
    4. 评估改进产品的后勤问题
　　策略——有哪些策略可用于改进产品？
　　能力——具备 实现这些策略的能力吗？知道如何做吗？
　　成本——改进工作需要多少成本或存在什么麻烦？是否充分利用了资源？
　　进度——能否立即开始或稍 后再改进？能否在可接受的时间范围内实现改进工作？
　　利益——改进效果明确吗？有附加利益吗（如更好的士气）？
　　问题——改进工作会有多大可能带来负面影响（例如， 引入错虫、损伤士气、占用其他项目资源）？

GEQ视角（perspective）
　　GEQ元素是评估软件产品质量的必要条件而不是充分条件。为了执行可靠的评估，还必须同时从六个关键视角来检查每个元素：
　　1. 受益人——哪些人关于质量的意见起作用？（例如，项目团队、客户、商会、法院等）
　　2. 关键目的——什么是必须达到的？（例如， 即时生存、利润、市场份额、客户满意度等）
　　3. 时间尺度——质量改进成果的时间敏感性如何？（例如，立即、近期、长期、某个关键事件之后等）
　　4. 替代物——本产品与替代物相比如何？（例如，竞争对手的产品、服9. 务或解决方案）
　　5. 失败结果——如果质量比GEQ稍11. 差一些会怎样？是否需要对突发事件进行规划？
　　6. 评估质量——评估本身的可信度如何？是否令人满意？

    满意质量不等于轻视和放弃软件产品的质量工作，它更强调用理性的思维去分析软件产品或软件项目面临的市场压力、风险状况、种种困境，对软件产品的质量做出理性的决策，而不是循规蹈矩、死板的、刻意执行一些被强制的行为。因此，满意质量被认为是实用主义、功利主义的产物，即倡导使软件开发公司在短期内快速开发出满足用户需求、令用户能够满意的产品，而不是一味的追求完美、追求软件质量的“零缺陷”。对软件公司来说，也应该是最实际的策略，能够有效把握时间、成本、质量等各方面的利益的平衡，满足用户需要的同时，创造最大化的价值。
    满意质量的思想已经开始不断被更多软件开发组织认可，很多软件企业开始尝试基于满意质量思想的各种实践，有些企业甚至鼓励尽早将产品投放市场，发布给用户，让用户参与Beta测试，由用户反馈试用过程中的各种体验和问题，这样企业在同用户在逐步的协作中不断提高质量和用户满意度，最终提供给用户满意的产品，同时也迅速占领市场，达到双赢的目的。

作者：袁琳

　人有过什么经验，遇到过什么恐惧的事，就会形成设法避免这种事情的方法学。研究重型方法学的人可能一直以来的经验就是组织上千人的开发队伍进行开发，比如说大型电信系统的开发、军事航天系统的开发......这种项目严格强调过程执行的规范，注重文档规范、评审及过程度量。而发明XP的人可能一直是在小团队里做项目，项目团队只有3、5个人，项目总是会因为没有满足用户价值而被Cancel，开发公司也蒙受损失，因此注重与用户的交流、反馈，强调快速、灵活。

　　每种软件方法产生的背景不同、特点不同、适用的领域亦不相同。那么对于软件项目来说，是否可以使用同一种软件开发方法来对不同类型、规模、复杂度的项目来进行开发呢，显然是不合理的。

　　前不久，恰巧和国内一位资深的软件工程咨询顾问做过一些交流，他本人热衷于RUP的过程改进，倡导针对不同类型项目进行适当的裁剪，实际上这也是一种灵活适应的方式、随需而变的思想。我对此是理解并赞同的，但是我对RUP却一直保持一种相对谨慎的态度。 

　　对于RUP来说，首先，我认为它过于理想化和理论化，RUP 是过程组件、方法以及技术的框架，你可以将其应用于任何特定的软件项目，由用户自己限定 RUP 的使用范围。对于各种类型的软件项目，RUP并未给出具体的自身裁减及实施策略，总有些无依据可循的感觉。你既可以说它能解决任何问题，也可以说它什么都不是；其次，RUP从本质来说还是一个强调设计和规范的软件方法，从这个角度来讲，与传统的瀑布模型没有太大差别，它的灵活性较之敏捷方法还是相对较弱的。在一些小型软件项目、特别是不可预测的软件项目开发中，面临着各种紧急需求、面临着时间压力，沿用RUP是很难应付自如的。但是在另一方面，RUP强调对知识的收集、整理和加工定义，强调在软件开发的时候要有好的体系结构。所以它还是很有利于知识的积累和共享的。

　　相比RUP ，敏捷方法如XP则更为灵活，倡导尽早的、持续的交付有价值的软件满足用户需要。用交流沟通取代详尽的文档，强调团队的主动、自律、自我组织和自发管理。而XP也是以代码为核心的一种方法，这里有很多的东西是未知的，知识只存在于两个地方：开发者的头脑和最后的代码。对于项目管理者来说，他们会认为敏捷开发方法弱化了知识管理的概念，而实际上敏捷开发注重的是最有价值的知识的积累和沉淀。

　　如何灵活应对各种项目风险、如何最大化优先满足用户价值、又如何能够有效的控制项目开发过程、如果做好项目过程中的知识管理，是每一个软件项目管理者都需要深入思考的问题。RUP的倡导者一直强调RUP裁剪，实际上我认为RUP不仅仅是需要自身的裁剪，还需要学会融合。在RUP裁剪的同时，适宜的融合敏捷开发的各种实践。不要认为RUP与XP是矛盾的，其实不然，它们具有不同的原理、具有不同的应用领域。在 RUP 中融合了 XP 技术时，才会得到过程的正确量，既满足了项目所有成员的需要，又解决了所有主要的项目风险问题。对于一个工作于高信任环境中的小型项目团队，其中用户是团队的一部分，那么 XP 完全可以胜任。对于团队越来越分散，代码量越来越大，或者构架没有很好定义的情况，您需要做一些其他工作。在用户交互具有"契约"风格的项目中，仅有 XP 是不够的。RUP 是一个框架，可以从 RUP 出发，在必要时以一组更健壮的技术来扩展 XP。

　　RUP最佳实践包括：

　　1． 迭代开发
　　2． 管理需求
　　3． 使用基于组件的构架
　　4． 可视建模
　　5． 持续的质量验证
　　6． 控制变更

　　12 个 XP 实践包括：

　　◆有计划的开发：通过结合使用优先级"故事"和技术估算，确定下一版本的功能
　　◆小版本：以小的增量版本经常向客户发布软件
　　◆隐喻：隐喻是一个简单、共享的"故事"或描述，说明系统如何工作
　　◆简单设计：通过保持代码简单从而保证设计简单。不断的在代码中寻找复杂点并且立刻进行移除
　　◆测试驱动开发：用户编写测试内容以对"故事"进行测试。程序员编写测试内容来发现代码中的任何问题。在编写代码前先编写测试内容
　　◆重构：这是一项简化技术，用来移除代码中的重复内容和复杂之处
　　◆结对编程：团队中的两个成员使用同一台计算机开发所有的代码。一个人编写代码或者驱动，另一个人同时审查代码的正确性和可理解性
　　◆集体代码所有权：任何人都拥有所有的代码。这就意味这每个人都可以在任何时候变更任何代码
　　◆持续集成：每天多次创建和集成系统，只要任何实现任务完成就要进行
　　◆每周 40 个小时：程序员在疲劳时无法保证最高效率。连续两周加班是绝对不允许的
　　◆现场客户：一名真实的客户全时工作于开发环境中，帮助定义系统、编写测试内容并回答问题
　　◆编码标准：程序员采用一致的编码标准证

　　RUP与XP的融合，是各自特点的相互补充，也是软件开发方法的平衡之道。而对软件技术平衡的思考也可以说是技术成熟的开始吧。

　　最后，再阐明我对软件项目开发的理解。在软件项目开发过程中，应该能够识别、分析不同软件项目的特点，采用相对适合的开发实践来适应软件开发过程，保证对软件开发的有效支持，以便能够创造出“足够好的”软件。而这个足够就是对 进度、成本、质量之间的平衡，最大化满足客户需要的实现。

http://www.csai.cn　　作者：袁琳　　来源：CSDN　　2006年10月11日

摘要: 随着国内软件测试行业的逐渐发展，有越来越多的软件企业更加重视软件测试，并已经形成了一套基本的软件测试流程。但是软件测试所起的作用还没有人们期望那样显著，因此，就需要继续加大投入对软件测试的关注程度，对软件测试过程进行持续的改进。软件测试过程中需要注重和改进的几个环节，与大家分享。

1、 计划与风险

　　项目计划对项目过程的实施有着直接的指导作用，它的重要性是不言而喻的。我经历过一些成功的项目，给我感受最深刻的就是计划的充分性，以及根据项目过程中遇到的各种新情况，对计划的及时变更做出反应的能力；我也经历过一些失败项目，由于项目计划的不合理或混乱无序，经常会带来严重的项目风险、以及开发成本，造成项目不断延期、产品质量无法保证。对于软件测试来说，测试计划也是指导后续测试工作的基础，在测试的计划中，不仅需要明确测试的目的、测试的资源、测试的人员等等，更重要的是需要详细明确并估计出在整个测试活动的任务和风险，比如：

测试需要做哪些工作？

整个测试活动估计需要多少工作日？

充分估计测试计划、测试设计、测试执行、测试分析评估这些阶段分别需要多少个工作日？

估计的测试用例规模是多少？

估计的测试进度时间又如何？

在测试过程中，可能会遇到哪些方面的问题？

可能存在的风险又有哪些？等等......

　　只有对过程中各任务的进行更详细的计划，才有利于在测试过程中对项目进度的把握有一个明确的目标；同时，风险策略的制定，也有利于对及早对测试过程中可能遇到的问题做出分析，以便在问题出现时能够尽可能的减少规避风险的成本。

2、 评审

　　在测试过程中的每个阶段结束前，都会输出一些资源，文档、用例 等等…，这些资源往往是下一个测 试阶段或软件开发的下一个环节执行的依据，比如：测试报告，测试人员在完成测试并提交测试报告之后，测试报告里说明已经没有未解决的问题了，那么是不是就应该结束测试呢？我们又如何来保证测试报告的准确性、充分性呢？这就需要组织参与项目的一些重要成员，项目经理、开发负责人、测试经理、QA等等对测试报告进行评审。评和审是结合在一起的，每个角色根据自己对项目的了解，从各自角度来审核测试报告的充分性，对质量风险发表各种见解。最终，对报告的规范性也要进行考察。评审也有会议评审、在线评审等等好几种方式，可以根据实际项目情况，对不同的项目、不同的文档、资源采用不同的方式评审。最后一点需要补充的是，对于测试发现的问题，一般是有争议的问题，需要有评审。对于紧急的问题，一般采用在线方式由专家裁决；另外，也最好根据实际情况组织会议评审来对一定规模的问题统一评审。

3、 文档

　　文档的编写对于测试人员来说是一个十分重要的任务，深入的、充分的投入测试的测试人员能写出高质量的测试文档。所以，测试文档的质量，往往反映了测试人员执行测试的广度和深度。而在文档的编写方面，首先必须形成统一规范；另外，针对不同项目的测试，可以适当对文档标题、内容进行简化。总之，文档模板一旦形成，必须严格遵守。

　　在编写测试文档过程中需要注意的几个问题：文档中描述的测试数据必须准确；必须详细描述出测试的环境；测试报告中必须详细描述测试的充分性、测试质量评价；等等......这里不再一一列举。

4、 方法与策略

　　测试方法和测试策略，测试的重中之重。这也是我个人非常乐于思考的，方法和策略的意义在于如何用最有效的办法、花最少的成本、在有限的资源情况下尽可能以最高的质量的完成测试项目，并根据项目中遇到的突发情况，不断制定新的策略。

　　测试的策略一般要求从全局方面对测试的阶段、每个阶段的测试类型进行考虑、定义，比如：需要做哪些方面的测试？测试的顺序是怎样的？功能测试如何进行？性能测试何时进行等等。而测试的方法更多是体现在一个具体的测试中，采取怎样的测试思路。另外，在测试过程中，对资源的协调也非常关键，需要能保证测试资源充分利用，每个测试人员都有适度并且相当的工作量。

　　在以往工作中，常常会进行交叉测试，这里予以介绍：测试往往是一个长期的重复性工作，对于测试人员来说，一个测试人员一般长期从事一种产品或一个特性的测试，长期如此，测试人员往往会出现测试反感腻味倦怠。因此，适当的采用交叉测试，让两个或多个测试人员相互学习对方业务领域的知识、并执行测试，既有利于减少测试人员的倦怠心里，使测试人员有一种新鲜感，也可能发现出前测试人员未发现的问题，也起到了互相监督的作用。

5、 总结测试经验

　　在测试的过程中，测试人员应该及时总结发现的错误并归类，标明经常容易出错的地方，将意见提交项目经理，审核后，制定出一份统一标准并提供给开发人员，这样就可以提前避免错误、避免重复错误和重复测试，提高测试效率。不仅如此，项目结束后的各项总结报告将是项目的后期维护或二次开发的宝贵参考资料。

　　另外，测试过程中，也可以将自己所负责特性、产品的体会、心得写出来，做为测试指导书，以便有新员工加入时，使其迅速上手。

6、 缺陷分析、度量

　　对测试活动过程中发现的缺陷进行分析、度量，寻找软件开发过程中存在的问题，并持续改进开发过程，提高质量。缺陷的分析、度量从时间上分为两个方面，首先是在软件开发过程中发现的缺陷进行分析、度量；然后就是，对软件产品发布后，对用户提出缺陷进行统计、分析。

　　对测试过程中的缺陷需要分版本，并按不同模块、问题级别，对缺陷进行各种统计，并比较子版

　　本统计数据之间的差异，CQ在这方面已经提供了比较强大的统计功能，这里不再赘述。进行分析，是因为开发修改后导致该模块不稳定，引发大量新问题；还是因为前期测试出现漏测（设计漏测、执行漏测）；或者是版本合入新增需求的功能导致。然后根据问题原因，提供改进建议。下面对几个参数进行说明：

　　TFVUD 是用户发现缺陷数（ Total Field Valid Unique Defects ）：即由用户发现的经过了确认的、非重复的、非用户错误操作的、非建议类型的所有缺陷；（总数、按模块统计）

　　PDD 是测试发现缺陷数（ Post Development Defects ）：即在开发完成后的测试周期中发现的缺陷数，但它不包括那些向用户发布后发现的缺陷；（分别按模块、级别、时间 统计）

　　DDR是开发缺陷率（Developer Defect Ratio）：一定周期内缺陷总数与代码

Author：袁琳
MSN：testwin@sohu.com

     随着国内软件测试行业的不断发展，软件测试工作更加深入、规范。其中对测试人员的绩效考核也越来越重要。目前，很多公司对测试人员的考核方面都不相同，有些公司仍然是以单纯的问题单数量来对测试人员进行评价，这样直接对测试人员工作方向产生误导，影响到测试人员工作的积极性和稳定性。因此，为了能够更好对测试过程进行管理，必须对测试人员有一个客观、全面的评价。下面是本人在工作中的一些体会希望能给大家带来一些启发：


一、测试人员工作绩效评价的误区
1、 仅从提交的问题单数量、测试执行用例数量来判断测试人员的好坏
这种做法明显缺乏全面性。问题单的数量只是评估测试质量的一个方面，我们更需要看中实际的测试质量。这就需要考察问题单的质量、测试的难度、问题单的级别。
例如：模块A很不稳定，潜在的问题数可能有100个，由测试人员甲负责测试，他一个月执行300个用例，提交50个问题单，发现30个有效问题，有10个严重问题；
模块B比较稳定，潜在的问题数可能有20个，由测试人员乙负责测试，他一个月执行100个用例，提交20个问题单，发现18个有效问题，有8个严重问题；
从上述测试执行结果来看，甲提交的问题单数量和执行用例数量都要远远高于乙，但是从测试的质量来看，模块B的遗留问题显然少于模块A，甲执行测试的充分性显然不如乙，从问题单质量来看，甲提交的问题单虽然很多，但近半数是非问题，做了无用功，还影响到开发人员对问题的定位所消耗的时间。
因此，必须要走出用问题单数量、用例数量评价测试人员的误区。

2、 对测试人员发现的问题的价值没有进行评估
发现1个系统架构设计方面存在的缺陷和隐患，远比发现几个普通界面的显示问题要有价值的多。因此，在对测试人员进行评价时，必须区分不同问题的重要性和价值。

3、 不重视测试文档的质量
测试文档的质量往往是测试人员的测试水平的反映，只有对系统进行了充分的、深入测试的测试人员才能写出高质量测试报告，说明测试的全面性和测试过程的质量。

4、 不重视测试人员的综合能力
首先，必须考察测试人员的责任心，如果一个测试人员工作不符责任，随意敷衍，即使提交的问题单数量多，也不能证明他测试的质量高。其次，需要关心测试人员的工作积极性，积极工作的态度不仅能带来很高的测试质量，还能提高整个团队的积极向上的风气。还有，测试人员的沟通能力，如果一个测试人员和开发人员对问题沟通交流不畅，甚至经常引发争执，这显然会影响测试工作的效率。


二、建议对测试人员进行综合性的全面评价
评价方法如下：

三、总结
综上所述，必须本着以测试质量为重、对测试负责的角度对测试人员绩效进行客观评价，同时也提高测试人员的质量意识。通过合理的绩效评价，让测试人员以积极的心态投入的测试工作中，保证测试工作的顺利进行。

Author：袁琳
MSN：testwin@sohu.com

   随着国内软件行业的不断发展，国内软件公司也越来越注重于软件的质量，越来越关注软件的可靠性，因此，做为质量保证的重要手段，软件测试过程的实施与管理成为一个热点，其中系统测试是整个测试活动的一个重要的阶段，系统测试的设计也就成为了关注点之一。以下是本人从事系统测试工作中的一些体会。

1、系统测试的定义：
   系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。

2、系统测试的对象：
  系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。

3、系统测试的设计
   系统测试过程包含了测试计划、测试设计、测试实施、测试执行、测试评估这几个阶段，而整个测试过程中的测试依据主要是产品系统的需求规格说明书、各种规范、标准和协议等。在整个测试过程中，首先需要对需求规格进行充分的分析，分解出各种类型的需求（功能性需求、性能要求、其他需求等），在此基础之上才可以开始测试设计工作，而测试设计又是整个测试过程中非常重要的一个环节，测试设计的输出结果是测试执行活动依赖的执行标准，测试设计的充分性决定了整个系统过程的测试质量。因此，为了保证系统测试质量，必须在测试设计阶段就对系统进行严密的测试设计。这就需要我们在测试设计中，从多方面来综合考虑系统规格的实现情况。通常需要从以下几个层次来进行设计：用户层、应用层、功能层、子系统层、协议层

3.1、用户层：
     主要是面向产品最终的使用操作者的测试。这里重点突出的是在操作者角度上，测试系统对用户支持的情况，用户界面的规范性、友好性、可操作性，以及数据的安全性。主要包括：
3.1.1、用户支持测试
     用户手册、使用帮助、支持客户的其他产品技术手册是否正确、是否易于理解、是否人性化。
3.1.2、用户界面测试
     在确保用户界面能够通过测试对象控件或入口得到相应访问的情况下，测试用户界面的风格是否满足用户要求，例如：界面是否美观、界面是否直观、操作是否友好、是否人性化、易操作性是否较好。
3.1.3、可维护性测试
    可维护性是系统软、硬件实施和维护功能的方便性。目的是降低维护功能对系统正常运行带来的影响。例如：对支持远程维护系统的功能或工具的测试。
3.1.4、安全性测试
    这里的安全性主要包括了两部分：数据的安全性和操作的安全性。核实只有规格规定的数据才可以访问系统，其他不符合规格的数据不能够访问系统；核实只有规格规定的操作权限才可以访问系统，其他不符合规格的操作权限不能够访问系统；

3.2、应用层：
     针对产品工程应用或行业应用的测试。重点站在系统应用的角度，模拟实际应用环境，对系统的兼容性、可靠性、性能等进行的测试。
3.2.1、系统性能测试
     针对整个系统的测试，包含并发性能测试、负载测试、压力测试、强度测试、破坏性测试。并发性能测试是评估系统交易或业务在渐增式并发情况下处理瓶颈以及能够接收业务的性能过程；强度测试是在资源情况低的情况下，找出因资源不足或资源争用而导致的错误；破坏性测试重点关注超出系统正常负荷N倍情况下，错误出现状态和出现比率以及错误的恢复能力。
3.2.2、系统可靠性、稳定性测试
     一定负荷的长期使用环境下，系统可靠性、稳定性。
3.2.3、系统兼容性测试
     系统中软件与各种硬件设备兼容性，与操作系统兼容性、与支撑软件的兼容性。
3.2.4、系统组网测试
     组网环境下，系统软件对接入设备的支持情况。包括功能实现及群集性能。
3.2.5、系统安装升级测试
     安装测试的目的是确保该软件在正常和异常的不同情况下进行安装时都能按预期目标来处理。例如，正常情况下，第一次安装或升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。还有一个目的是核实软件在安装后可立即正常运行。另外对安装手册、安装脚本等也需要关注。

3.3、功能层
     针对产品具体功能实现的测试。
3.3.1、业务功能的覆盖
     关注需求规格定义的功能系统是否都已实现。
3.3.2、业务功能的分解
     通过对系统进行黑盒分析，分解测试项及每个测试项关注的测试类型。
3.3.3、业务功能的组合
     主要关注相关联的功能项的组合功能的实现情况。
3.3.4、业务功能的冲突
     业务功能间存在的功能冲突情况。比如：共享资源访问等。

3.4、子系统层
     针对产品内部结构性能的测试。关注子系统内部的性能，模块间接口的瓶颈。
3.4.1、单个子系统的性能
     应用层关注的是整个系统各种软、硬件、接口配合情况下的整体性能，这里关注单个系统。 3.4.2、子系统间的接口瓶颈
     例如：子系统间通讯请求包的并发瓶颈。
3.4.3、子系统间的相互影响
     子系统的工作状态变化对其他子系统的影响。

3.5、协议/指标层
     针对系统支持的协议、指标的测试。
3.5.1、协议一致性测试
3.5.2、协议互通测试

哈哈 51testing的个人空间还真不错！