1、让研发团队的领导重视测试：

　　测试经理作为测试部门的老大，让公司领导重视测试，明白测试给项目带了的价值，那是义不容辞的责任。如何说服公司的领导，让公司的研发总监重视，这一点非常关键。只要这一点做好了，测试才会变得很轻松、愉快。如果公司的领导都不重视测试团队，只看重开发团队，即时测试部门发现了一大堆问题，公司领导也觉的很正常，不在乎，何谈降低测试轮次？如果公司研发领导很重视每轮的测试报告，自然开发部门不敢怠慢，代码的质量肯定要高得多，降低测试的轮次简直就是轻而易举的事情。

　　2、测试团队和开发团队的独立性：

　　国内很多的研发团队都不是很重视测试团队，很多情况下都是开发部门的经理说了算，什么时候测试？什么时候结束？都是如此，这就让测试团队的成员非常郁闷，很无赖，经常是抱怨居多。在这种情况下，多数时候，项目为了赶进度，项目经理和开发经理急了。为了尽快发现问题，只要开发了几个新功能和修复了几个Bug，也就安排大量测试人员立马验证，这样反反复复，版本平凡发布，测试效果极差，软件质量也得不到保证。如果测试部门和开发部门独立以后，发布版本测试都必须通过沟通来解决。你说开发部门的经理“说测试就测试”的想法，说了还能算吗？呵呵！！我们公司很多时候，在测试版本不符合要求时，要送测试部门进行测试，都是开发部门的经理和项目经理给我们测试部门的老大说好话，拍马屁，老大高兴了，我们方才开始测试，否则一切按流程行事，他们也没有办法。保持部门的独立性和平等性，同样重要。

　　3、细化送测标准，建立完善的测试规范：

　　测试经理在编写测试计划的时候，就应该考虑如下的问题：开发部门开发完成到什么时候我们可以开始接受测试？如果这点测试经理不明白，后面重复测试平凡发布版本，不是什么新鲜事。目前，我们公司的做法是：测试经理编写详细的测试规范，在规范中明确规定了软件版本的送测标准（如：某个独立模块的功能点完成了多少百分比，才能够开始测试等等，都要写成一个标准）。测试规范制定完毕后，开会评审让项目经理、开发经理和测试经理达成一个一致的建议，后面测试的时候就按测试规范中的标准执行就可以了。严格把握软件的送测标准，也能够有效的减少测试的次数。

　　4、测试部门建立详尽的预测试标准：

　　如果被测试软件符合送测标准以后，开发部门才能够请求测试部门进行测试。测试部门接受到开发部门的配置表以后，在服务器上取下测试的版本，编译、部署后，安排部分项目核心人员，对部分主要的功能进行预测试，如果预测试通过了，就可以开始测试。如果预测试不通过，就打回开发部门修改好后再预测试，直到预测试通过为止。同时，我们也要制定严格的软件测试结束标准，来把好质量关，避免一味的追求减少测试轮数，而忽视质量，结果自然可想而知。建立详尽的预测试标准，这样也能够减少测试的轮数。

　　5、保持测试和开发独立的测试环境：

　　大部分的项目硬件都非常昂贵，现在很多的公司为了节省成本，开发和测试环境都在同一台机器上。开发人员就在测试机器上开发，这样混乱的测试环境，导致很多测试出来的Bug有可能不能够重现，开发人员对不成功重现的Bug就要求列为无效的Bug，弄得测试的兄弟们递交Bug都胆战心惊的。测试人员为了重新 Bug不得不另取以前的版本，重新编译后，再测试，这样做无意识又增加了测试的轮次。后来测试环境和开发环境分开了，虽然在同一台机器上，数据库都分开了，测试数据再也不会被开发人员修改了，在测试出现的问题，一般在开发那边都能够出现。后来为了保护测试组里成员的利益，我也去掉了绩效考核中“对无效的 Bug”的考核项，大家终于可以放心的提缺陷了。

　　6、重视单元测试，提高被测软件质量：

　　很多时候，测试部门和开发部门单元测试比较马虎或应付客户了事，测试的时间短，留下了很多缺陷。到了后面每轮系统测试的时候，才被发现，加之项目进度的压力，给公司也带来了较大的经济负担。加大单元测试的力度，力争尽早发现并修复缺陷，同样也是减少测试轮次的一种好方法。

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

　　7、重视测试用例的评审，提高测试用例的质量：

　　就目前来说，很多的公司都不是很规范。一种情况：变更了软件需求，相应的测试用例，没有及时增加，测试人员测试时，完全凭个人的理解和经验，想到哪里就测到哪里，随便测试。在这种情况下，不同的人在不同的时间测试时，就会发现并提出不同的缺陷，这样混乱的测试就导致测试轮数较多，效率自然低下。另外一种情况就是测试人员设计测试用例的水平不高，测试用例质量较差，导致测试反复进行，也测试不出Bug。这就要求测试部门主管，加大测试用例评审的力度，力争以最少的测试用例，测试出较多的Bug。

　　8、部门员工进行模块交叉测试，避免漏测提高测试效率：

　　测试主管在安排测试的时候，也要注意“用人之长，避人之短”。测试启动阶段，要对这个系统集中培训，让测试部门的成员对整个系统达成一致意见，最好在第一轮测试时，尽可能发现较多缺陷，开发人员尽早修复。第二轮测试就可以进行模块交叉测试。一方面我们可以避免个人原因造成的漏测试，另外一方面也可以利用每个人不同的思维方式，很容易发现其它模块的缺陷，避免多次重复测试，提高测试人员的积极性。测试效率提高了，发现的问题多了，后面测试的轮次自然要减少。

　　9、加强项目成员的管理，定期报告发现缺陷的情况，增加督促力度：

　　加强项目成员的管理，同样能够减少版本的发布和测试的轮次。测试人员每天都编写测试日志，邮件抄送给项目部成员和公司领导报告每天测试情况，加强不同层次的领导对开发人员的督促力度。这就对应了第一条，如果公司领导不重视测试，也就无所谓。如果公司领导很重视测试结果，马上作出反应，给各个部门的经理施加压力，软件质量被重视了，自然测试版本减少。如果哪个开发人员开发的模块每天都有很多缺陷，开发人员自然很不光彩，毕竟大家都很要面子，开发人员也敢轻而易举，开发的模块功能不测试就直接扔给测试部。这也是一种有效的方法，当然也可以把缺陷的数量、严重程度作为开发人员的绩效考核标准，提高开发人员的“质量意识”，缺陷自然很少。我们公司就是这样做的，一般在2到3个版本时，就很难发现缺陷，测试人员也相互看看其它成员发现的缺陷，一旦有的测试人员发现了较多的Bug，发现缺陷很少的测试人员很急，比较有个比较吗？特别是测试半天都没发现 Bug的测试人员，就经常给我讲自己测试过程中的苦衷，我也很理解他们，多给他们鼓励鼓励。

　　10、严格控制需求变更的流程，减少后期的需求变动：

　　在项目开发中，经常碰到这样的情况，客户代表中有产品部、科技部、业务部等等部门的人员，很难通过某个客户代表户讲清需求。客户代表，随着对开发系统的不断深入了解，有可能客户不断的提出新的需求，或者说是不断修改需求，所以对于需求的变更，我们一定要有一个严格的标准流程。通过开发方和客户的评审后，再编写相应需求文档，最后开始开发。很多时候，繁琐的需求变更流程和领导的多级审批签字，并且需求的变更请求，也有相关的记录，很多客户都怕承担需求变更带来风险。也让业务人员觉得变更比较麻烦，不得不放弃需求的变更。严格控制需求的变更流程，做到有效的需求变更，这也许是一种减少测试版本的方法。

度量活动首要考虑的是目的，测试中的度量一般有如下目的：

a)     判断测试的有效性

b)     判断测试的完整性

c)     判断工作产品的质量

d)     分析和改进测试过程

1.2   度量内容

   度量的数据构成一个层次化的体系，就是度量框架。框架的上层是度量指标(Factor)，下层是直接度量(Metrics)。度量指标表示产品或过程的特征，需要从直接度量计算而来。而直接度量是可以直接收集到的数据。下面分别说明系统测试中需要测量的度量内容，注意区分其中的度量指标和直接度量。

1.2.1进度（时间）度量

a)     计划的测试开始、结束时间

b)     实际的测试开始、结束时间

c)     执行测试用例的时间。

1.2.2成本度量

1.     计划投入测试的工作量(人时)

2.     计划投入测试的资金

3.     实际投入测试的工作量(人时)

4.     实际投入测试的资金

6.     缺陷修正成本（提交缺陷、研究缺陷、改正缺陷、验证等所需时间）

7.     累积测试时间。对每一个发布的版本，累积测试时间等于该版本在演变过程中经历的所有测试的测试时间之和。包括完整测试、验证测试和回归测试。 

1.2.3规模度量

1.     被测对象的规模（功能点、代码行（有效代码行，注释行）等）

3.     测试用例数目（总用例数、计划执行数、实际执行数）

1.2.4测试质量（效率）度量

1．  测试覆盖率

    c)测试用例执行率： 测试用例执行率=实际执行的测试用例数/计划执行的测试用例数

2．  缺陷检测率对某一版本，某一个环节（阶段）的缺陷检测率＝(A/（A＋B）)*100％。

其中：

A:测试人员查找出的不包括重复缺陷的数量。

B：用户（包括下一环节的部门）报告的不包括重复缺陷的数量。

3．  测试过程能力

单位缺陷开销＝测试投入的工作量（人时）/缺陷总数

1.2.5产品质量度量

1.     版本发布前缺陷数

2.     版本发布后缺陷数

3.     评审发现的缺陷数

4.     缺陷修正率：缺陷修正率＝发布前已修正的缺陷数/发布前已知的缺陷总数。

5.     缺陷密度：千行代码缺陷率＝测试和评审中发现的缺陷数/被测目标的代码的规模（KL）

软件质量定义：

51Testing软件测试网#cFm6M!Jmd(e

软件测试是为了检验软件存在的缺陷，为了软件提供更好的质量保证。51Testing软件测试网J~+qyO C8N;p|*PY

51Testing软件测试网 J k&G,|WA]0[

那么质量是怎么定义的呢？怎么样的才算好的质量呢？51Testing软件测试网"q\:?q#l

---

s Xw({7A6{3z:~#S0

b@ Ue}0

AN7zs$B4Q)T(C2B0H0——最好的产品是用户不用说明书就能使用的产品；51Testing软件测试网}1T([h9L~
L

51Testing软件测试网1^ i"G QTl?&`2o3Z

——好员工是能站在企业角度考虑问题的员工；51Testing软件测试网E|p C*iAl

51Testing软件测试网4S @mCQ3WD(p&[v w

——最好的服务是能让顾客有宾至如归感觉的服务；

3?Nn3|C051Testing软件测试网 HLW8X!vl0A[

---

ISO是这样定义的：质量是实体基于实体特性满足需求的程度。

x I B-Q8B0

 软件质量的三个层次（由低到高）：

`H@J(rW0

• 符合需求规格：满足了开发者明确定义的目标；
• 符合用户显示需求：符合用户明确说明的目标；
• 符合用户实际需求：满足用户明确的和隐含的需求。

 影响软件质量的因素：51Testing软件测试网-l,S\W!Mps

软件质量的提高是一个综合的因素。51Testing软件测试网w+_6rjv

• 流程：是软件产品开发过程的规范。好技术不如好流程
• 技术：什么是真正的技术？编码？架构？设计？
• 组织：是员工职位、工作的安排等。它是流程执行的保障
• 进度及成本

软件质量管理体系：

流行的软件质量管理体系有：ISO9000、CMMI/CMM、六西格玛51Testing软件测试网y4{n Ftg E3i.\

 ISO9000：2000的管理八项原则：

1. 以顾客为中心：满足顾客的需求、期望才能保证组织的存在；
2. 领导作用：好的组织离不开好的领导；
3. 全员参与：真正创造效益的是员工；
4. 过程方法：一个好的流程规范是产品质量的最重要保证
5. 管理的系统方法：采用好的方法提高效率、有效性
6. 持续改进：可持续发展战略
7. 基于事实的决策方法：能达到量化每一个过程
8. 互利的供方关系：双赢

 八项质量管理原则的意义：

• 质量管理的理论基础；
• 概括了一般性的规律；
• 提供理论依据；
• 遵循的原则；

 CMMI（Capability Maturity Model Integration）/CMM（Capability Maturity Model）：

CMMI/CMM除了能评估软件承包商开发软件的能力，还能协助软件组织改进过程、提高过程能力。51Testing软件测试网'V9q#XJ8g1A g R"T

CMMI是CMM的集成和综合，集成了CMM-SW、CMM-SE、CMM-IPT、CMM-SA51Testing软件测试网~p,Wf$c6w4Rd

实施CMMI/CMM有什么必要呢？

0lH$i;E6r~0

• 业界的实施标准
• 业界的一种交流语言
• 国内企业获取国际订单的门槛
• 向下采购的保障：如软件外包公司的承包评价
• 降低软件风险的有力手段

CMMI/CMM五个级别51Testing软件测试网\/|G!y(|&ub\V"J:p

1. 初始级：不可预测的，有能工作的团队；
2. 可重复级：有大概的流程，不过过程可重复，有组织；
3. 已定义级：软件过程标准已文档化，有组织（SEPG）来管理标准并实施此标准，定义标准过程，保证过程的标准型和一致性；
4. 已管理级：能预定量化的目标，保证效率和质量，量化过程并采集过程数据来控制过程，是可预测的过程；
5. 优化级：改进过程，预防弱点，改进新技术。

t},p;K5{8S0

 

关键过程区域：KPA(key process area)

过程域：指的是事情的某一方面，也是其中一方面。下面列举了CMM各等级里面的关键过程域。51Testing软件测试网 [0I6}!j W5jR

　　CMM2:可重复阶段：51Testing软件测试网PV*V [1|2sNoV1r

　　需求管理：requrement management51Testing软件测试网 yO0`'nB8w`2{)ct

　　软件项目计划：software project planning

C}#iU1z-M$ro0

　　软件项目跟踪和监督：software project tracking oversight51Testing软件测试网4^ ZzsQCH)F\;s

　　软件子合同管理：software subcontract management51Testing软件测试网#WP,N&g w0}

　　软件质量保证：software quanlity assurance

#p#oA9EA@O0

　　软件配置管理：software configuratione management

*c.~1o`s!m*b,Jj0

　　CMM3:已定义阶段：

;S6v0DK\O/n2o*S0

　　组织过程焦点：organization process focus51Testing软件测试网0Y ?]W$C

　　组织过程定义：organization process definition51Testing软件测试网9A0f@b ri+w

　　培训大纲：training program

K }-|,^ c$i/M Y,_0

　　集成软件管理：intergrated software management51Testing软件测试网J0` `lo r4\

　　软件产品工程：software product engineering51Testing软件测试网Q D)f'x f3M

　　组间协调：intergroup coordination

X,XQTj/\ i0

　　同行评审：peer review51Testing软件测试网)R:b}m}"K

　　CMM4:已管理阶段：51Testing软件测试网1@{6NuTStd.\

　　定量管理过程：quantitative process management51Testing软件测试网'n?H-CUohw

　　软件质量管理：software quality management51Testing软件测试网6Bo,_1J _9I$n4g;u

　　CMM5:优化阶段：

Fb$]"[fh,Y0

　　缺陷预防：defect prevention51Testing软件测试网6e8b,j,~D

　　技术改革管理：technology change management51Testing软件测试网;}gx1{DVZ

　　过程更改管理：process change management51Testing软件测试网JpS:JB0`b6W

CMMI/CMM的用途：

• 评估组用来识别组织的强处和弱点；
• 评估组用来识别选择不同的业务承包商的风险和监督合同；
• 管理者用来了解组织的能力并提高能力成熟度所进行的活动；
• 技术人员和过程改进组的指南

ISO9001与CMM的关系

• 相似点：强调管理、过程、规范化和文档化
• 不同点：CMM只针对软件；而ISO9001还包括硬件、流程材料和服务
• 联系：CMM 2级与ISO9001强相关；CMM的每个关键过程域至少与ISO9001弱相关

（更多CMM资料请点击：http://baike.baidu.com/view/8110.htm）51Testing软件测试网^
A1fu3Dh(U.H

六西格玛(6σ)管理法

特点：51Testing软件测试网 ^;XsX _#]Gf

• 以质量为主线，以客户需求为中心，利用事实和数据的分析，改进组织的业务流程能力，灵活的、综合性的管理方法体系
• 要求企业从外部客户角度来看待企业内部的各种流程
• 利用客户的要求来建立标准，设立产品与服务的标准和规格。并以此来评价企业流程的有效性和合理性
• 通过提高企业流程的绩效来提高产品质量服务的质量和企业整体竞争力
• 塑造一流的企业文化

六西格玛(6σ)水平利用事件概率积分来衡量产品的绩效和企业的水平。

@e6Z0_Y5F%UN0

• 6个西格玛＝3.4失误/百万机会―意味着卓越的管理，强大的竞争力和忠诚的客户
• 5个西格玛＝230失误/百万机会－优秀的管理、很强的竞争力和比较忠诚的客户
• 4个西格玛＝6,210失误/百万机会－意味着较好的管理和运营能力，满意的客户
• 3个西格玛＝66,800失误/百万机会－意味着平平常常的管理，缺乏竞争力
• 2个西格玛＝308,000失误/百万机会－意味着企业资源每天都有三分之一的浪费
• 1个西格玛＝690,000失误/百万机会－每天有三分之二的事情做错的企业无法生存

六西格玛(6σ)管理原则

+A5~/^)K4Vzq4C0

• 注重客户
• 注重流程
• 全员参与
• 以防为主
• 事实依据的决定
• 持续和突破性改进

六西格玛(6σ)改进区域51Testing软件测试网(o t.js
?faq%NQ

• 周期时间（流程个速度，回应能力）
• 输出物的变差（产品和服务的直通率，缺陷成本降低，客户满意度提升）
• 营运效率（更低成本）

六西格玛(6σ)的实施方法:DMAIC过程

• D（Define ）—— 定义/界定：提出问题，确定目标
• M（Measure）—— 量测：收集资料，查找原因
• A（Analyze）—— 分析：研究资料，确定原因
• I（Improve）—— 改进：优化解决
• C（Control）—— 控制：推进控制

六西格玛(6σ)管理组织结构：是成功实施6σ的重要保证。

领导51Testing软件测试网i GXQ4X/}kO	推动 !jmaf/x0	管理 ,q e9N_tl$Bg0	执行51Testing软件测试网WQeS^ J	配合 "gk4NHO eV0
委员会 cp+FU|1nN@e7@0	倡导者51Testing软件测试网~6XmA ]	全职工作者51Testing软件测试网I:jN/i A]_y:c0b4Z	基层领导者 +W*ze{&`y,D0	兼职和员工 S$rGK5S;h v u0
1N4a(Qq;@(e X;Z2w+io0	CY E}9f B0	主黑带 Kze+y?0wC)F P!}:~0	黑带51Testing软件测试网k(s K t0K?D	绿带 lP,iJ!q$tX)EJ0

51Testing软件测试网qEC+qx(I,D

软件质量模型

质量模型:一组特性及特性之间的关系，提供规定质量需求和评价质量的基础。51Testing软件测试网jOJ6^XrXx

外部和内部质量

• 功能性:软件提供满足明确和隐含需求的功能的能力

  • uH \8V8GIb0适合性：为指定的任务和用户目标提供一组合适的功能的能力。（手机的通话功能）51Testing软件测试网~2d(|k)b ~C'm

  • 51Testing软件测试网}'KhZ
    GGn{

    准确性：提供所需精度的正确或相符的结果或效果的能力。（计算结果一致）

    
    DYO1M&^D4x9xZs?0

  • _X6o'p F q0互操作性：与一个或更多规定系统进行交互的能力。（word打印功能可以跟多种打印机搭配）51Testing软件测试网 ]Q\7n g"U

  • a&B&e/p r2fy0保密安全性：保护信息和数据的能力。（帐号密码的安全）

    ^%N Jq)_E.Y0

  • t YOLw3xX9bUx L0功能性的依从性：软件产品遵循与功能性相关的标准约定或法规以及类似规定的能力。（行业标准等）

    w~/TCyo-q2p0

• 可靠性：软件产品维持规定的性能级别的能力

  • 2EF s4}1ifT0成熟性：为避免由软件中错误而导致失效的能力。（小错误不会影响软件正常工作）51Testing软件测试网](WA mQ0s"R-k+w

  • 51Testing软件测试网2[$@|2y'} B3Q5s$_%V+S

    容错性：软件出现故障或者违反指定接口的情况，软件维护规定的性能的性能级别的能力。（输入框输入错误的提示）

    {8g"l,@v
    MV0

  • *y+mkzsnfWk0易恢复性：在失效的情况下，重建规定的性能级别并恢复受影响数据的能力。（计算机死机重启）

    en}o1rI e0

  • l6Q-eq9Eq j1{;JE`0可靠性的依从性：软件产品遵循与功能性相关的标准约定或法规以及类似规定的能力。（行业标准等）51Testing软件测试网i s'Uwl6hR'H

• 易用性：软件产品被理解、学习、使用和吸引用户的能力

  • 51Testing软件测试网#c*i8oGY8B9D!S v

    易理解性：用户理解软件是否合适的，以及用于特定任务和环境的能力。（用户知道软件是做什么的）51Testing软件测试网9GK+{ a9SE T

  • 51Testing软件测试网&c!J Xh'G(r~(kb;|:[

    易学性：用户学习和应用的能力。（用户不依赖于产品说明）

    Is-M'J;v'j0W'V&|0

  • 0FHN4Q*x-PA0易操作性：用户能操作和控制软件的能力。（操作简单、快捷）51Testing软件测试网.c F3J7?6dL

  • wb(i1t4n4_h0吸引性：吸引用户的能力。（游戏吸引玩家的能力）51Testing软件测试网F3O4E ?#f0gt

  • 51Testing软件测试网 Rs,?u f7J+j6|

    易用性的依从性：软件产品遵循与功能性相关的标准约定或法规以及类似规定的能力。（行业标准等）51Testing软件测试网/?:OJ%f*_r+v4O:l1K

• 效率：相对使用资源的数量，提供适当性能的能力

  • 3Fi'}I9{8W*?8?,[0GYA0时间特性：软件执行过程中，适当的响应和处理时间以及吞吐率的能力。（系统响应时间）

    '|6H&u7AWG C8Y0

  • D7zc.P `HA8tX0资源利用性：使用合适的资源和类别的能力。（消耗内存量）

    ,e
    L:}
    Y7i bp0

  • \D%f nj3b0效率的依从性：软件产品遵循与功能性相关的标准约定或法规以及类似规定的能力。（行业标准等）

    q!g&Te%]S0

• 维护性：软件产品可被修改的能力。包括修正、改进、功能变化的适应

  • $TG4[&T7\A0易分析性：诊断软件出现缺陷原因或识别修改部分的能力。（简单知道为什么出错）

    9]%P,Q0j&I&Q"}0
  • 51Testing软件测试网2B5QC5M]@ b8U:D&~

    易改变性：指定的修改可以被实现的能力。（升级简单）51Testing软件测试网U+^;} W0f3H*x K

  • 7j5[3i jN\ k0易测试性：被修改的软件能被确认的能力。（能简单识别软件被修改）

    ,C5}2W:Oyy0

  • (}6R:CI-H4Zt0维护性的依从性：软件产品遵循与功能性相关的标准约定或法规以及类似规定的能力。（行业标准等）51Testing软件测试网,Y2z}}f
    |,r8Q

• 可移植性

  • 51Testing软件测试网$\_5SR OHe3bw

    适应性：软件适应不同的制定环境的能力。（软件适应多操作系统）51Testing软件测试网2`Z"e#|s y![,ZG#~

  • h2`e F:w:~:k*ij:X }0易安装性：软件被安装的能力。（用户安装向导）

    _,jp
    h(O0

  • 
    z R A3Z?a5H0g~)B0共存性：在公共环境中同与其分享公共资源的其他独立软件共存的能力。（与其他软件同时可运行）51Testing软件测试网I*W_vp\ R

  • 51Testing软件测试网{W'_ q'G d+?7GR

    易替换性：替换相同用途的指定软件产品的能力。

    &G `z.Q1L/f&@5T#^0

  • 7Jp.@'Z%D2Gb4VE0可移植性的依从性：软件产品遵循与功能性相关的标准约定或法规以及类似规定的能力。（行业标准等）51Testing软件测试网hT,Ix x.|

软件质量活动：

主要的软件质量活动

• 软件质量保证（SQA software quality assurance）
• 测试

SQA和测试的关系

• SQA从流程方面保证软件的质量
• 测试从技术方面保证软件的质量
• 两者缺一不可

SQA的主要工作范围

• 指导并监督项目按照过程实施
• 对项目进行度量、分析，增加项目的可视性
• 审核工作产品，评价工作产品和过程质量目标的符合度
• 进行缺陷分析，缺陷预防活动，发现过程的缺陷，提供决策参与，促进过程改进

质量管理PDCA循环

• P（plan）计划：计划设计
• D（do）执行：实施执行
• C（check）检查：检查检测
• A（act）改进：纠正措施

51Testing软件测试网(UW.jz~?'W(Z2u

软件度量

概念：

度量：对事物属性的量化表示。51Testing软件测试网iUP2~l4p

软件度量：对软件范围的测度，包括软件系统、构件或生命周期过程具有的某个给定属性的度的一个定量测量。51Testing软件测试网psH ^C#L yI8h#N

目的：

• 提高软件生产率，缩短产品研发周期，降低研发成本、维护成本
• 提高软件产品质量，提高用户满意度
• 为组织持续改进提供量化的指标和反馈

作用：

• 理解：通过度量，获得对过程、产品、资源的理解，确定以后预测的基线和模型。是其他作用的基础。
• 预测：根据理解确定的模型，根据已知要素推算、估计其他要素，以便合理分配资源、合理定制计划。
• 评估：分析活动与计划的符合度，确定偏差，以便控制执行。
  • 开发活动和计划的符合程度
  • 产品质量
  • 新技术的影响
• 改进：根据量化的信息，帮助识别要因、查找问题的根源，以及提高产品质量和过程效率的方法；与以前的量化信息比较，验证方法的有效性。

过程（五步法）：

这是以个循环的过程，不断改进的过程。是PDCA发展。51Testing软件测试网"[;T;I2X }L

1. 识别目标（identify goal）
2. 定义过程（define process）
3. 收集数据（collect data）
4. 分析数据（analyze data）
5. 改进过程（improve process）

分类：

四个基本度量项

J3C*G&XC8kj0

• 规模（size）：工作产品的大小
• 工作量（effort）：完成各软件工作产品和活动所用人时/人天
• 进度（schedule）：各软件工作产品和活动开始和结束的时间
• 质量（quality）-缺陷（defect）：各软件工作产品和活动中产生的缺陷数

规模度量：

——SRS文档页数51Testing软件测试网'^3k] _A2B4a XQ x

——HLD文档页数51Testing软件测试网 Sn7W ^%V)x

——LLD文档页数

k UL@
I(Mm ~I0

——代码量（KLOG）51Testing软件测试网"`m(UN$]2P

——UT用例数51Testing软件测试网8ASYd} e

——IT用例数

}&eP3t-];A2f0

——ST用例数

t,]tTV$j0

……51Testing软件测试网Q b-\ FEML

工作量度量：

——SRS所用人时数51Testing软件测试网(~ W-L+|-Xq/{:T

——HLD所用人时数51Testing软件测试网9oOM0[4t

——LLD所用人时数

9~%OF&L0q~/p0

——编码所用人时数

5Rth$a\#T.s*n/s0

——测试（UT、IT、ST）计划所用人时数51Testing软件测试网`T7[f9P;o

——测试（UT、IT、ST）方案所用人时数51Testing软件测试网4\)hD1L9L7d&q Q0]*l h

——测试（UT、IT、ST）用例所用人时数51Testing软件测试网
x#o&Z TB

——测试（UT、IT、ST）执行所用人时数51Testing软件测试网g:{"l`B0Ks%[ R

……

Y-M8F${;DtMg0

进度度量：

——SRS阶段开始时间、结束时间

V!g:uQ:Z H%T0

——HLD阶段开始时间、结束时间

u H W;e3A$A0

——LLD阶段开始时间、结束时间51Testing软件测试网/k|Qn0r

——编码阶段开始时间、结束时间

rc"f@ DX.{![0

——测试（UT、IT、ST）计划阶段开始时间、结束时间

:u |T W:c0{0

——测试（UT、IT、ST）方案阶段开始时间、结束时间51Testing软件测试网LVV
C2h]7s

——测试（UT、IT、ST）用例阶段开始时间、结束时间

:o _o$b)pn0

——测试（UT、IT、ST）执行阶段开始时间、结束时间51Testing软件测试网8_fa@$Q{ v

……

|9K w6u^6w1cE0

缺陷度量

——SRS评审发现缺陷数51Testing软件测试网 aN
[Ns)L_I

——HLD评审发现缺陷数

F&t c:[Q _e2L0

——LLD评审发现缺陷数

Q!hlXB0

——编码评审发现缺陷数

/]S'Gz'A{0

——UT发现缺陷数

${B L+d!A0

——IT发现缺陷数51Testing软件测试网C.m8u+[Tq
lcGcZ

——ST发现缺陷数51Testing软件测试网ct Zg#^K&?

……

(?UW*vLw+e0

其他度量指标：

缺陷密度：

D%wM5j SLX4O0

研发活动发现的缺陷密度51Testing软件测试网^P:|i@J ]-XJ6R

研发活动引入的缺陷密度

-hd\ j!L0

工作产品的缺陷密度

#AU1O
Ytggk0

生产率：

]v2z%G}(v_0

阶段文档生产率：页/人天、页/人时51Testing软件测试网hjXJ |

编码生产率:KLOG/人天

u$]:E%|NH)F0

用例生产率：用例/人天

;[r"eAl+U5e0

测试用例执行效率：执行用例数/人天51Testing软件测试网 f&t%oac V9znX

用例密度：用例数/KLOG

?g$? Q6U/yK:g/~0r0

……51Testing软件测试网f4P^?Z6H%@n

实际和计划的对照比较、总结分析、查找原因、改进完善，达到一个持续发展的过程。

　　一、质量体系的策划与设计

　　该阶段主要是做好各种准备工作，包括教育培训，统一认识，组织落实，拟定计划；确定质量方针，制订质量目标；现状调查和分析；调整组织结构，配备资源等方面。

　　（一）教育培训，统一认识

　　质量体系建立和完善的过程，是始于教育，终于教育的过程，也是提高认识和统一认识的过程，教育培训要分层次，循序渐进地进行。

　　第一层次为决策层，包括党、政、技（术）领导。主要培训：

　　1.通过介绍质量管理和质量保证的发展和本单位的经验教训，说明建立、完善质量体系的迫切性和重要性；

　　2.通过ISO9000族标准的总体介绍，提高按国家（国际）标准建立质量体系的认识。

　　3.通过质量体系要素讲解（重点应讲解“管理职责”等总体要素），明确决策层领导在质量体系建设中的关键地位和主导作用。

　　第二层次为管理层，重点是管理、技术和生产部门的负责人，以及与建立质量体系有关的工作人员。

　　这二层次的人员是建设、完善质量体系的骨干力量，起着承上启下的作用，要使他们全面接受ISO9000族标准有关内容的培训，在方法上可采取讲解与研讨结合，理论与实际结合。

　　第三层次为执行层，即与产品质量形成全过程有关的作业人员。对这一层次人员主要培训与本岗位质量活动有关的内容，包括在质量活动中应承担的任务，完成任务应赋予的权限，以及造成质量过失应承担的责任等。

　　（二）组织落实，拟定计划

　　尽管质量体系建设涉及到一个组织的所有部门和全体职工，但对多数单位来说，成立一个精干的工作班子可能是需要的，根据一些单位的做法，这个班子也可分三个层次。

　　第一层次：成立以最高管理者（厂长、总经理等）为组长，质量主管领导为副组长的质量本系建设领导小组（或委员会）。其主要任务包括：

　　1.体系建设的总体规划；

　　2.制订质量方针和目标；

　　3.按职能部门进行质量职能的分解。

　　第二层次，成立由各职能部门领导（或代表）参加的工作班子。这个工作班子一般由质量部门和计划部门的领导共同牵头，其主要任务是按照体系建设的总体规划具体组织实施。

　　第三层次：成立要素工作小组。根据各职能部门的分工明确质量体系要素的责任单位，例如，“设计控制”一般应由设计部门负责，“采购”要素由物资采购部门负责。

　　组织和责任落实后，按不同层次分别制定工作计划，在制定工作计划时应注意：

　　1.目标要明确。要完成什么任务，要解决哪些主要问题，要达到什么目的？

　　2.要控制进程。建立质量体系的主要阶段要规定完成任务的时间表、主要负责人和参与人员、以及他们的职责分工及相互协作关系。

　　3.要突出重点。重点主要是体系中的薄弱环节及关键的少数。这少数可能是某个或某几个要素，也可能是要素中的一些活动。

[NextPage]

　　（三）确定质量方针，制定质量目标

　　质量方针体现了一个组织对质量的追求，对顾客的承诺，是职工质量行为的准则和质量工作的方向。

　　制定质量方针的要求是：

　　1.与总方针相协调；

　　2.应包含质量目标；

　　3.结合组织的特点；

　　4.确保各级人员都能理解和坚持执行。

　　（四）现状调查和分析

　　现状调查和分析的目的是为了合理地选择体系要素，内容包括：

　　1.体系情况分析。即分析本组织的质量体系情况，以便根据所处的质量体系情况选择质量体系要素的要求。

　　2.产品特点分析。即分析产品的技术密集程度、使用对象、产品安全特性等，以确定要素的采用程度。

　　3.组织结构分析。组织的管理机构设置是否适应质量体系的需要。应建立与质量体系相适应的组织结构并确立各机构间隶属关系、联系方法。

　　4.生产设备和检测设备能否适应质量体系的有关要求。

　　5.技术、管理和操作人员的组成、结构及水平状况的分析。

　　6.管理基础工作情况分析。即标准化、计量、质量责任制、质量教育和质量信息等工作的分析。

　　对以上内容可采取与标准中规定的质量体系要素要求进行对比性分析。

　　（五）调整组织结构，配备资源

　　因为在一个组织中除质量管理外，还有其他各种管理。组织机构设置由于历史沿革多数并不是按质量形成客观规律来设置相应的职能部门的，所以在完成落实质量体系要素并展开成对应的质量活动以后，必须将活动中相应的工作职责和权限分配到各职能部门。一方面是客观展开的质量活动，一方面是人为的现有的职能部门，两者之间的关系处理，一般地讲，一个质量职能部门可以负责或参与多个质量活动，但不要让一项质量活动由多个职能部门来负责。目前我国企业现有职能部门对质量管理活动所承担的职责、所起的作用普遍不够理想总的来说应该加强。

　　在活动展开的过程中，必须涉及相应的硬件、软件和人员配备，根据需要应进行适当的调配和充实。

　　二、质量体系文件的编制

　　质量体系文件的编制内容和要求，从质量体系的建设角度讲，应强调几个问题：

　　1.体系文件一般应在第一阶段工作完成后才正式制订，必要时也可交叉进行。如果前期工作不做，直接编制体系文件就容易产生系统性、整体性不强，以及脱离实际等弊病。

　　2.除质量手册需统一组织制订外，其它体系文件应按分工由归口职能部门分别制订，失提出草案，再组织审核，这样做有利于今后文件的执行。

　　3.质量体系文件的编制应结合本单位的质量职能分配进行。按所选择的质量体系要，素，逐个展开为各项质量活动（包括直接质量活动和间接质量活动），将质量职能分配落实到各职能部门。质量活动项目和分配可采用矩阵图的形式表述，质量职能矩阵图也可作为附件附于质量手册之后。

　　4.为了使所编制的质量体系文件做到协调、统一，在编制前应制订“质量体系文件明细表”，将现行的质量手册（如果已编制）、企业标准、规章制度、管理办法以及记录表式收集在一起，与质量体系要素进行比较，从而确定新编、增编或修订质量体系文件项目。

[NextPage]

　　5.为了提高质量体系文件的编制效率，减少返工，在文件编制过程中要加强文件的层次间、文件与文件间的协调。尽管如此，一套质量好的质量体系文件也要经过自上而下和自下而上的多次反复。

　　6.编制质量体系文件的关键是讲求实效，不走形式。既要从总体上和原则上满足 ISO9000族标准，又要在方法上和具体做法上符合本单位的实际。三、质量体系的试运行

　　质量体系文件编制完成后，质量体系将进入试运行阶段。其目的，是通过试运行，考验质量体系文件的有效性和协调性，并对暴露出的问题，采取改进措施和纠正措施，以达到进一步完善质量体系文件的目的。

　　在质量体系试运行过程中，要重点抓好以下工作：

　　1.有针对性地宣贯质量体系文件。使全体职工认识到新建立或完善的质量体系是对过去质量体系的变革，是为了向国际标准接轨，要适应这种变革就必须认真学习、贯彻质量体系文件。

　　2.实践是检验真理的唯一标准。体系文件通过试运行必然会出现一些问题，全体职工立将从实践中出现的问题和改进意见如实反映给有关部门，以便采取纠正措施。

　　3.将体系试运行中暴露出的问题，如体系设计不周、项目不全等进行协调、改进。

　　4.强信息管理，不仅是体系试运行本身的需要，也是保证试运行成功的关键。所有与质量活动有关的人员都应按体系文件要求，做好质量信息的收集、分析、传递、反馈、处理和归档等工作。

　　四、质量体系的审核与评审

　　质量体系审核在体系建立的初始阶段往往更加重要。在这一阶段，质量体系审核的重点，主要是验证和确认体系文件的适用性和有效性。

　　1.审核与评审的主要内容一般包括：

　　（1）规定的质量方针和质量目标是否可行；

　　（2）体系文件是否覆盖了所有主要质量活动，各文件之间的接口是否清楚；

　　（3）组织结构能否满足质量体系运行的需要，各部门、各岗位的质量职责是否明确；

　　（4）质量体系要素的选择是否合理；

　　（5）规定的质量记录是否能起到见证作用

　　（6）所有职工是否养成了按体系文件操作或工作的习惯，执行情况如何。

　　2.该阶段体系审核的特点是：

　　（1）体系正常运行时的体系审核，重点在符合性，在试运行阶段，通常是将符合性与适用性结合起来进行；

　　（2）为使问题尽可能地在试运行阶段暴露无遗，除组织审核组进行正式审核外，还应有广大职工的参与，鼓励他们通过试运行的实践，发现和提出问题；（3）在试运行的每一阶段结束后，一般应正式安排一次审核，以便及时对发现的问题进行纠正，对一些重大问题也可根据需要，适时地组织审核；

　　（4）在试运行中要对所有要素审核覆盖一遍；

　　（5）充分考虑对产品的保证作用；

　　（6）在内部审核的基础上，由最高管理者组织一次体系评审。

　　应当强调，质量体系是在不断改进中行以完善的，质量体系进入正常运行后，仍然要采取内部审核，管理评审等各种手段以使质量体系能够保持和不断完善。

质量保证工程师（QA）岗位职责

　　测试计划 → 测试设计 → 测试开发 → 测试执行 → 测试评估

　　测试计划就是定义一个测试项目的过程，以便能够正确的度量和控制测试。

　　第一部分：测试计划

　　测试计划的问题：

　　1、测试计划经常是等到开发周期后期才开始实行，使得没有时间有效的执行计划；

　　2、测试计划的组织者可能缺乏Client/Server测试经验；

　　3、测试的量度和复杂性可能太大，没有自动化工具，很难计划和控制。

　　测试策略：

　　测试策略描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（单元测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能测试、压力测试等）。

　　测试策略包括

　　1、要使用的测试技术和工具；

　　2、测试完成标准；

　　3、影响资源分配的特殊考虑例如测试与外部接口或者模拟物理损坏、安全性威胁。

　　测试计划最关键的一步就是将软件分解成单元，写成测试需求。

　　测试需求有很多分类方法，最普通的一种就是按照商业功能分类。把软件分解成单元元件有几个好处：

　　1、测试需求是测试设计和开发测试用例的基础，分成单元可以更好地进行设计；

　　2、详细的测试需求是用来衡量测试覆盖率的重要指标；

　　3、测试需求包括各种测试实际和开发以及所需资源。

　　怎样估计测试工作量：

　　1、效率假设：即测试队伍的工作效率。对于功能测试，这主要依赖于应用的复杂度，窗口的个数，每个窗口中的动作数目。对容量测试，主要依赖于建立测试所需数据的工作量大小。

　　2、测试假设：为了验证一个测试需求所需测试动作数目。

　　3、应用的维数：应用的复杂度指标。例如要加入一个记录，测试需求的维数就是这个记录中域的数目。

　　4、所处测试周期的阶段：有些阶段主要工作都在设计，有些阶段主要是测试执行。

　　测试资源：

　　1、人力资源

　　测试经理

　　为测试项目提供总体方向。开发测试计划、征集并监督测试人员、申请系统资源、监视并汇报工作进程、测试评估、测试需求的分解。

　　测试工程师 ---- 设计和开发

　　设计：对被测软件的详细了解、分解测试需求的技能、选择在C/S环境下用来验证测试需求的技术。

　　开发：熟悉SQA、VB、和脚本语言。

　　测试工程师 ---- 执行

　　负责测试执行和记录结果。需要能够安装系统，网络知识，初始化数据库和其他初始条件。重要的是诊断能力。

　　测试系统管理者

　　每个测试项目必须指定一个专人负责管理SQA Suite。包括在服务器上安装存储库，安装打印机连接，执行备份，以及其他维护工作。管理者必须高度熟悉SQA，网络工作经验。

　　2、系统资源

　　安装SQA Suite的硬件和软件环境

　　数据库服务器

　　该服务器必须专用于 测试工作，能够重置某些初始值，包括系统日期和时间等。

写测试计划的步骤：

　　1、确定工程

　　收集下列信息

　　文档 已创建（是/否） 版本/日期

　　需求详述

　　功能详述

　　项目计划

　　设计详述

　　原型

　　用户手册

　　定义新的工程，Adminà New Project。

　　确定软件的结构，用Assetsà Software Structure选项定义软件结构。

　　2、定义测试策略

　　测试策略项 例子

　　测试阶段 系统测试

　　测试类型 功能测试

　　测试技术 75%用SQA Suite自动测试，25%手工测试

　　完成标准 95%测试用例通过并且最高级缺陷全部解决

　　特殊考虑 测试必须在上午进行

　　3、分解软件，写测试需求

　　分析各种信息

　　反复检查并理解各种信息，和用户交流，理解他们的要求。可以按照以下步骤执行：

　　1）确定软件提供的主要商业任务

　　2）对每个商业任务，确定完成该任务所要进行的交易。

　　3）确定从数据库信息引出的计算结果。

　　4）对于对时间有要求的交易，确定所要的时间和条件。这些条件包括数据库大小、机器配置、交易量、以及网络拥挤情况。

　　5）确定会产生重大意外的压力测试，包括：内存、硬盘空间、高的交易率

　　6）确定应用需要处理的数据量。

　　7）确定需要的软件和硬件配置。通常情况下，不可能对所有可能的配置都测试到，因此要选择最有可能产生问题的情况进行测试，包括：最低性能的硬件、几个有兼容性问题的软件并存、客户端机器通过最慢的LAN/WANF连接访问服务器。

　　8）确定其他与应用软件没有直接关系的商业交易。包括：

　　管理功能，如启动和推出程序

　　配置功能，如设置打印机

　　操作员的爱好，如字体、颜色

　　应用功能，如访问email或者显示时间和日期。

　　9）确定安装过程，包括定置从哪安装、定制安装、升级安装。

　　10）确定没有隐含在功能测试中的户界面要求。大多界面都在功能测试时被测试到。还有写没有测到，如：操作与显示的一致性，如使用快捷键等；界面遵从合理标准，如按钮大小，标签等。

　　把需求组织成层次图

　　4、估计测试工作量

　　∑(每个测试的时间*每个需求的测试的数目*测试需求的的数目)

　　（测试设计、开发、…）

5、确定资源

　　人力资源

　　职位                    姓名         特殊责任/说明

　　测试经理

　　测试工程师

　　设计/开发（可以多人）

　　测试工程师

　　测试执行（可以多人）

　　测试系统管理员

　　系统资源

　　系统                     名称/类型

　　数据库服务器

　　网络/子网

　　服务器名称

　　数据库名称

　　SQA 测试存储库

　　网络/子网

　　服务器名称

　　客户测试机

　　包括专门的配置需求列表

　　测试开发的PC机列表

　　6、创建工程调度表

　　任务         相关工作量（天）

　　整个SQA过程          38

　　测试计划             12

　　确定项目             1

　　定义测试策略

　　决定测试需求

　　估计工作量

　　确定资源

　　调度测试活动

　　生成测试计划文档

　　测试设计              7

　　分析测试需求

　　指定测试过程

　　指定测试用例

　　查看测试需求的覆盖率

　　测试开发              12

　　建立测试开发环境

　　录制和回放原型过程

　　开发测试过程

　　测试和调试测试过程

　　修改测试过程

　　建立外部数据集合

　　重新测试并调试测试过程

　　测试执行               6

　　设置测试系统

　　执行测试

　　验证测试结果

　　调查突发结果（unexpected result）

　　生成缺陷日记

　　测试评估               1

　　回顾测试日记

　　评估测试需求的覆盖率

　　评估缺陷

　　决定是否达到测试完成的标准

7、书写测试计划

　　1）介绍

　　目的

　　背景

　　测试范围

　　项目文件列表

　　2）测试需求

　　3）测试策略

　　◇ 测试类型

　　　　● 功能测试

　　　　● 用户界面测试

　　　　● 性能测试

　　　　● 压力测试

　　　　● 容量测试

　　　　● 配置测试

　　　　● 安装测试

　　◇ 工具

　　4）资源

　　人力资源

　　系统资源

　　5）调度

　　6）文档

　　软件元件

　　测试特性（Assets）

　　测试日记

　　缺陷报告

　　第二部分：测试设计

　　测试设计的问题

　　1、不做测试设计，测试过程也是胡乱建立的。

　　2、测试设计不详细，不是基于可量度的测试策略，例如测试计划覆盖一个集合或者测试需求的一个子集。

　　3、测试过程没有采用最好的技术来检验Windows C/S结构的测试需求

　　测试用例的选择规则

　　1、选择与测试需求的实质部分最相关的测试用例。

　　2、选择的测试用例应该不容易应用程序的改变的影响。

　　下面是选择测试用例的几点具体规则：

　　1、商业函数

　　商业函数一般与数据库有关，要测试数据库的变化，有几种方法：

　　1）如果数据库的的改变会反映在一个列表框中，那么就要选择验证列表框内容的测试用例。

　　2）还可以检查交易完成后的确认对话框。可以检查对话框的标题。图象比较也可以检查确认对话框，但图象比较容易受其他因素影响。

　　3）修改脚本，SQA Basic提供了强大的数据库支持。

　　2、域的验证

　　各种不同的域选择相应的测试用例。

　　3、用户界面测试

　　对象状态测试用例

　　4、性能标准

　　等待状态测试用例

　　5、压力下的操作

　　6、访问控制

　　Object state test case

　　7、配置测试

　　不能选择图象测试用例（也分辨率有关）和文件测试用例（与驱动器有关）

　　8、安装选项和验证

　　对象状态用例和窗口存在用例，文件存在用例。

　　书写测试设计的步骤

　　生成测试需求报告
　　　　　↓
　　指定测试过程
　　　　　↓
　　指定测试用例（可选）
　　　　　↓
　　回顾测试覆盖率

第三部分：测试开发

　　输入：被测软件、基于测试需求的测试设计

　　输出：测试过程和测试用例

　　目标：

　　1、创建可以重用的测试过程和测试用例

　　2、维护测试过程、测试用例与相关测试需求的一一对应。

　　测试开发的问题：

　　1、测试开发很乱，与测试需求或测试策略没有对应性

　　2、测试过程不可重复或不可重用

　　3、测试过程被作为一个编程任务来执行，导致脚本太长，不能满足软件移植性的要求。

　　错误处理——当测试过程发生错误时，有几种解决办法：

　　1、跳转到别的测试过程

　　2、调用一个能够清除错误的过程

　　3、退出过程，启动另一个

　　4、退出过程和应用程序，重新启动启动Windows，在失败的地方重新开始测试

　　测试开发的步骤

　　1、设立开发环境

　　SQA Suite

　　连接到SQA存储库

　　启动SQA Baisc或VB

　　被测软件

　　等等

　　2、录制和回放原型过程

　　原型过程指出所有未知窗口控制，使得他们都能象标准窗口那样动作或者没有特别的动作，把他们都划归为Generic类型。通过这个过程，SQA Robot就知道该怎样处理应用中的特殊控制。

　　1、把recording option 中的Define Unknown Object as Type Generic选项设置为off

　　2、使用的过程标识符要可以被覆盖，或者能被删掉。因为这只是个原型，用来教SQA Robot 录制的过程

　　3、录制测试过程和测试用例

　　1、录制模块测试过程和与测试需求最低层对应的测试用例；

　　2、录制初始化过程；

　　3、录制导航过程，把前面的过程串起来；

　　4、测试和调试测试过程

　　5、修改测试过程（可选）

　　6、建立外部数据集合

　　如果测试过程是用来循环一套输入和输出数据，就需要建立数据集合。

　　7、重复测试和调试测试过程，回到4

第四部分：测试执行

　　测试执行的问题

　　1、自动化测试没有有效的利用，使得手工测试太多。

　　2、测试结果的捕获没有系统性，而且没有查看或调查

　　3、缺陷报告必须用手工加入缺陷跟踪系统

　　错误分类

　　1、测试用例失败

　　正常错误

　　2、脚本命令失败

　　当测试过程不能不能执行录制过程中的某个功能时，回产生这种错误，如鼠标单击按钮或选择菜单项等。它也能指示是缺陷还是测试过程的设计问题。

　　3、致命错误

　　导致测试停止，这种情况最好重起Windows。

　　具体步骤：

　　1）建立测试系统

　　2）准备测试过程

　　3）运行初始化过程

　　4）执行测试

　　5）从终止的测试恢复

　　6）验证预期结果

　　7）调查突发结果

　　8）记录缺陷日记

　　第五部分：测试评估

　　测试评估的目标

　　1、量化测试进程

　　2、生成缺陷和测试覆盖率的总结报告

　　测试评估的问题

　　1、没有把测试覆盖率作为报告测试进程的根据，使得不知测试是否结束；

　　2、没有做缺陷评估，缺陷评估是量度软件可行性的重要指标；

　　3、不使用专门的软件工具进行数据输入任务和相应的评估活动，使得这些任务变得繁重累人。

　　测试覆盖率

　　评估测试完成多少的标准

　　缺陷评估

　　评估软件质量的重要指标，通常评估模型假设缺陷的发现是呈泊松分布的；严格的缺陷评估要考察在测试过程中发现缺陷的间隔时间长短。评估要估计软件当前的可靠性并预测随着测试的继续进行，软件可靠性会怎样提高。

　　SQA Suite 提供四种形式进行缺陷评估：

　　1、缺陷分布报告可以生成缺陷数量与缺陷属性的函数。如测试需求和状态。

　　2、缺陷趋势报告可以看出缺陷增长和减少的趋势；

　　3、缺陷年龄报告展示一个缺陷处于某种状态的时间长短

　　4、测试结果进度报告展示测试过程在被测应用的几个版本中的执行结果以及测试周期。

　　具体步骤

　　1、回顾测试日记

　　2、评估测试需求的覆盖率

　　3、分析缺陷

　　4、决定是否达到完成测试的标准，没有满足标准时

　　1）再测试

　　2）降低标准

　　3）确定软件的一个满足标准的子集，看是否可以发布。

　　1、 正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。

　　2、 容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。

　　3、 完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。

　　4、 接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。

　　5、 数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。

　　6、 边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。

　　7、 压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行。。。进行测试。

　　8、等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。

　　9、错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。

　　10、效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。

　　11、可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。

　　12、可移植性：在不同操作系统及硬件配置情况下的运行性。

　　13、回归测试：按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员 已经解决，进行下一轮的测试。

　　14、比较测试：将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较 。

　　说明：针对不同的测试类型和测试阶段，测试用例编写的侧重点有所不同。

　　1、 其中第1、2、6、8、9、13项为模块（组件、控件）测试、组合（集成）测试、系统测试都涉及并重点测试的方面。

　　2、 单元（模块）测试（组件、控件）测试：重点测试第5项。

　　3、 组合（集成）测试：重点进行接口间数据输入及逻辑的测试，即第4项。

　　4、 系统测试：重点测试第3、7、10、11、12、14项。

　　5、 其中压力测试和可移植性测试如果是公司的系列产品，可以选用其中有代表性的产品进行一次代表性测试即可。

　　6、 GMPS基础测试用例设计完成后，其他的测试项目只编写设计与之不同部分的测试用例。

　　7、 对于每个测试项目测试的测试用例不是一成不变的，随着测试经验的积累或在测试其他项目发现有测试不充分的测试点时，可以不断的补充完善测试项目的测试用例。

　　测试执行的时候，大家面对是一堆用例，这些用例起到的作用也是不同的，那么如何保证我们在有限的时间执行的用例是最有效的，最有价值的。

　　尤其是无法全部执行用例的时候，势必有裁剪的时候，我们需要有很好的用例执行的优选原则。

　　我们要应用抢钱原则，选择好最有价值的用例优先执行。那么，如果搞清楚什么样的用例最有价值，就OK。

　　用例价值大的用例主要有三个方面的因素：1 容易发现的故障的用例；2 用户最常用的场景；3 如果泄露，用户的生气程度大的。

　　1、容易发现故障的用例

　　1） 性能相关的用例—上游的环境受限，所以这个部分比如容易发现故障

　　2） 边界值相关用例—边界引发的故障比例最高

　　3） 开发部在集成测试最不容易做到的用例，比如场景复杂度高的

　　2、用户最常用的场景

　　1） 比如局内呼叫，做主叫，做被叫，短消息，预付费，彩铃等多是最常用的业务，这些业务如果出现问题，只有回退版本了。

　　2） 配置管理的号码分析，动态管理的查看链路状态，告警查看

　　3、如果泄露，用户生气程度大的

　　1） 比如无法拨打电话 > 可拨打，单通 > 可以正常通话，无回铃音 > 可以正常通话，回铃音有杂音

　　2） 无法出话单 > 话单内参数错误

　　如上的仅仅是一些实例，没有复杂的算法模型来排序用户行为。

　　总之：拿到用例，一定要先分析出最有价值的用例，再开始执行。如果拿到用例，平铺直叙的执行。 那咱不就成了抢钱时候先抢毛票的傻子了？

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

本文出自gracehjd的51Testing软件测试博客：http://www.51testing.com/?92844