软件测试与质量管理2(不完整,逐步补充)

上一篇 / 下一篇  2009-01-05 16:27:54 / 个人分类:系统化测试

1.        软件测试

1)       软件测试具有组织性、步骤性和计划性的特点

软件测试仪测试形态分类,可以分为建构性测试、系统测试以及专项测试

a)        建构性测试又称为开发测试,一般包括,单一步骤测试、尝试性测试、单元测试、组建测试、集成测试

b)       系统测试通常称为QA Testing,测试人员通常为专业的系统测试工程师,系统测试是针对系统急性测试,这包括所应支持的软件、硬件、操作系统以及所应集成的第三方软件;包括集成测试、前哨测试(冒烟测试)、功能测试、设置测试、发行测试、验收测试

c)       专项测试,就是需要额外的人力及资源来进行的测试活动,有时也需要根据产品的本质特征来安排或略去专项测试,如所开发的产品属于pda软件的话,进行压力测试就显得多此一举了。专项测试一般包括回归测试、压力测试、兼容性测试、性能测试AlphaBeta测试

2)       测试技术

a)        准备工作:一般包括测试计划、测试用例等

b)       执行方式:人工执行、自动化执行

c)       测试方法:黑盒测试白盒测试,黑盒测试以测试广度为主,白盒测试以测试深度为主

                        i.             白盒测试也成为结构性测试,有时候涉及到内部机密的问题这种测试一般都在公司内部进行,很少委托给其他公司或个人。严格来说,白盒测试有两大方面:数据流面和控制流程面,数据流面就是数据进出系统的程序所经过的流程,控制流程面就是测试程序在执行过程中每个阶段的流程

1.        语句覆盖:每一个程序语句都被执行到

2.        分支覆盖:每一个程序的进出点都至少被执行过一次

3.        条件覆盖:分支覆盖再加上所有的判断情况都至少被执行过一次

4.        条件组合覆盖:不同的组合的判断情况都至少被执行一次

                      ii.             黑盒测试着重于软件的功能面,也成为功能测试;可以委托其他机构去执行

1.        测试用例覆盖:test cases的每一个用例都被测试过

2.        输入覆盖:所有输入都必须考虑到

3.        输出覆盖:所有输出都必须考虑到


2.        软件缺陷的种类

1)       Bug的历史:bugdebug

2)       造成软件缺陷的原因:

a)        程序编写错误

b)       编写程序未按照规定

c)       软件越来越复杂

d)       开发人员的态度

e)        测试人员的经验与技巧不足

f)        沟通上的问题

g)       需求变更太过频繁

h)       进度上的压力

i)         管理上的缺失

3)       缺陷的种类

a)        功能不正常

b)       难以使用的软件

c)       未作良好规划的软件

d)       所提供的功能不足

e)        与使用者的互动

f)        使用性能太差

g)       未作好错误处理

h)       边界错误

i)         计算错误

j)         使用一段时间所产生的错误

k)       控制流程的错误

l)         在压力下所产生的错误

m)     不同硬件设备所产生的错误

n)       版本控制不良所产生的错误

o)       文件的错误


3.        问题跟踪系统:缺陷跟踪系统

1)       实施目的

a)        质量无法控制

b)       问题无法量化

c)       重复问题接连发生

d)       解决问题的知识无法保留

2)       问题的生命周期

a)        测试人员找到问题

b)       制定问题的拥有者

c)       开发人员检查问题

d)       如果是问题,修改;如果不是问题,关闭

e)        将修改的问题送回到测试人员

f)        测试人员确认问题,如果问题修改完成,关闭问题;如果发现新问题,重新进入流程

3)       设置问题的等级:

a)        Bug严重等级分类

                        i.             高:缺少主要功能,或主要功能毫无作用;所产生的问题会导致系统停摆、工作不正常;所产生的问题导致无法进行下一步的测试

                      ii.             中:主要功能运行不完全;所产生的问题会导致系统部分功能不正常;所产生的问题虽然严重但是不影响下一步的测试

                     iii.             低:功能运行正常,但是会有一些不一致的情形产生;所产生的问题不会导致系统任何问题;所产生的问题不影响下一步的测试

                    iv.             微:功能运行正常,可是有改进的空间;所产生的问题不会导致系统任何问题;所产生的问题不影响下一步的测试

b)       Bug处理紧急程度

                        i.             1:立即修改完成

                      ii.             2:下一阶段结束前必须修改完成

                     iii.             3:产品推出前必须修改完成

                    iv.             4:如果时间允许的话再来修改

                      v.             5:在下一版本再修改

c)       两种分类方法的讨论

                        i.             严重等级分类法是从质量管理的角度来考虑,主动权在QA人员手中;处理优先级分类法是从项目管理的角度来考虑,主动权在项目经理或产品经理手中;两者往往会出现矛盾

                      ii.             让缺陷跟踪系统运作流畅必须配合适当的游戏规则,建议常常召开问题审核会议;并利用REDCReviewEvaluateDiscussionConclusion)来减少测试人员与开发人员不必要的冲突和对立


TAG: 系统化测试

 

评分:0

我来说两句

Open Toolbar