软件测试01_软件测试工作流程

测试实施
• 测试方法
在测试过程中,要根据软件产品的质量情 况以及功能提交的情况采用不同角度的 测试方法. 1. 在项目初期,提交的功能比较少,软件 产品的质量还达不到性能测试和极限测 试的要求时. 我们需要按照测试大纲进 行测试,以保证提交的功能达到基本要求, 然后再关注每个功能的细节,这样可以尽 可能保证开发人员完成的功能达到一个 满意的质量目标.
• 测试方法
3. 当软件产品的功能全部提交,并且 当前的错误发现曲线趋于平缓, 这就 说明按照测试大纲进行测试已经很难 提高错误的发现率.这时则需要采取其 他测试方法包括性能,极限测试和脱离 测试大纲的可用性测试. 这里的性能和极限测试系统复杂度小 于与软件提交前的性能和极限测试时 的系统复杂度.
测试实施
市场上所有有关测试的书籍都是在讲测 试的理论,很少发现有讲测试经验的. 因为经验只有从实际的测试工作中得到. 每个项目完成后,我们或多或少都会有 一些好的工作经验,积累这些经验才能 使我们的测试能力逐步提高.
测试工作没有最好,只有更好.
测试总结
2. 多谈不足
测试工作的经验不光是需要积累好的经 验,更重要的是主动发现我们工作的不 足,改进不足才能逐步完善测试工作.
矛与盾是互相对立的.现场调试节省了开发人员时间,但 是也不同程度的浪费了测试人员的时间.(现在比较好的 解决方法是测试人员使用多于一台的机器进行测试)
测试实施
组间协调
经常与开发人员沟通,可以了解开发人员 如何去实现某个功能,这些实现方法可能 就会有漏洞,根据这些漏洞的测试,常常 会有事半功倍的效果.这种方法,在软件 开发的中后期很有效.
需求确认
• 培训的展开
组内的培训
功能测试方法和操作测试方法； 自动测试；
部门的培训
各模块功能培训； 开发技能培训； 专业知识；
测试设计
Test Point Test Case
Function Spec
内部同行评审
开发人员参与 同行评审
测试设计
• 编写测试大纲
1. 形成通用的功能测试集，包含详细的 测试点（以前是日方编写测试点）； 2. 要求追加对测试难点的测试方法或者 测试用例. 3. 对于二期开发的项目,要求包含以前 项目的的全部功能；
寄存器信息
R10 R11 R12 R13 R14 R15 R16 R17 001C6EBC FFFFFFFF 00000000 00005090 00E80234 00000008 069D0736 00E80370 *[001C2AE0] *[00000000] *[00000000] *[00000000] *[00000000] *[FFFFFFFF] *[C542180B] *[00005090] HPR+184 check_find SIT_INT_STACK+488E ___ghsbegin_bss+5ACE4 tsk_count __e_entfnc+AE ___ghsbegin_bss+5AE20
测试实施
• 测试评价
专门的评价组； 评价内容：性能，用户测试，全系统 的内容，不针对于功能； 评价结果：除了填写Buglist，对于产 品的评价内容体现在测试组的周报中；
测试实施
• 组间协调
在工作的过程中，需要和其他组进行协 作或是提供支持的地方。目前的工作中， 测试组面临的组间协调对象主要是各个 开发组； 协调的内容： 系统组例会上各个工作组之间的安排； 测试过程中，对于问题的请教； 测试现场的保留；
调试信息
mapdsp_ClearOrderOfDisplayRequest MapSetNum=0 DisplayNum=1 [MAP_Center_Position] MapsetNo( 0) CenterPos(0x4c9574f1,0x13a0949b) DispNo( 0) CurrentNo( 0) [MAP_Clock_End] (Y/M/D) 1900/ 1/ 1 Week( 1) (H:M:S) 12:44:16 SysTime (0x cd8160) [MAP DRAW_Cancle] CheckClear in MAPDRW_iFirstFail iMapSetNo,iLayer ( 0, 1) [MAP DRAW_Cancle] CheckClear in MAPDRW_iFirstFail iMapSetNo,iLayer ( 0, 3)
软件测试工作流程
软件测试过程
SQA 测试活动 同行评审 里程碑 总结 管理者
需求确认
测试设计
测试执行 测试计划 组间协调
测试总结
需求确认
• 编写测试计划
内容：
时间和人员安排 同行评审及同行评审负责人； 里程碑制定； 进度表； 风险计划的制定； 培训的计划；
测试计划需要进行评审；
需求确认
• 测试工作的介入
• 测试方法
4. 二期开发类型的项目测试执行过程中, 每个阶段都要注意原来项目的功能的实 现情况,特别需要注意的是与新添加以及 变更功能相关功能的测试.即新添加的功 能不能影响原有的功能 注: 对于二期开发项目的性能测试,在没 有具体指标前,对它的要求是性能至少不 低于原来的项目.
测试实施
• 测试报告
测试实施
• 提高错误的再现率
这个问题,很多测试人员不重视,他们认为只要 我测试出错误就可以了.其实不然,本来一些错 误的再现率就很低,在测试人员这里不容易再现 (至少测试人员还知道错误出现的大概步骤),那 么在开发人员那里就更难再现,给开发人员分析 错误带来很大困难.因此我们要求测试人员发现 错误后要尽力寻找再现方法,提高错误的再现率 .1/n的描述是最不好的描述。 不过,这对测试人员来说的确也是一种挑战
1. 测试开始介入的时间和系统组的建立 时间几乎同时进行. 2. 用充足的时间去分析用户需求(在NEUAPN事业部的名称为仕样书)中可以测试内 容, 同时可以发现其中测试比较困难的内 容并及时考虑解决措施 3. 根据不同功能考虑进行不同级别的测 试,采用不同的测试方法.
需求确认
• 需求学习的方法
测试人员自己阅读和分析仕样书, 讲解 自己负责部分的功能,并回答其他测试人 员的提问. 要求不遗漏仕样书中的任何功能,在讲解 中追加自己对仕样书的理解,以及对测试 难点部分考虑的测试方法.
测试实施
• 组间协调
问题的询问
测试时出现仕样中没有明确说明的错误现象时, 需要测试人员及时与开发人员沟通,由开发人员 确认是否是错误.这样不但可以提供错误提交的 质量,另一方面也节省开发人员分析错误后,再 与测试人员讨论的时间
测试实施
• 组间协调
现场的调试
测试时发现严重错误(多为再现率较低的错误) 时,需要测试人员及时找到相关开发人员,根据 现场进行分析和调试.这样可以最大程度减少开 发人员和测试人员再现错误时间以及开发人员 分析错误的时间.
测试工作中的某些经验的获得,就像是足球场 上的守门员一样,他需要经历失败才能走向成 功.
我们面前的挑战
• 开发人员只把测试人员当作测试人 员来看
测试实施
• 重视确认测试
确认测试的时机：
建议在测试功能过程中进行一些简单问题的确认，可以节 约专门的确认时间；
确认方法：
再现率较低的错误, 确认测试要远超过发现错误时的测 试次数,比如一个Bug再现率是3/10,那么确认时至少要做 到20次.再现率更低的错误,确认测试要在多个版本中进 行. 确认测试执行,不能只关注Bug本身,要对Bug相关部分的 功能都进行测试,以确保Bug的修改不会影响其他部分.
版本测试
Component Team
Q&A Component Version Report 协助再现错误 Bugbase
测试实施
• 制定小计划
依据系统组的Release计划； 一般测试的周期比较长，大约4-6个 月，所以针对于每个版本提交的功 能的不同以及每次测试时间长短的 不同,调整和制定测试组小计划. 这样的计划只要在项目例会中传达 或者通过Email通知相关测试人员即 可
Day_Bug_Report：每个测试人员填写； Bugbase：由登录者负责把每个人的测 试结果整理到Bugbase上，进行重复的 过滤; BugbaseStatus :对于Bugbase作的一 些分析图表； 提交给日方的BugList：包括 CheckList和Bugbase的内容;
测试实施
• 错误描述要求
测试设计
• 测试大纲的同行评审
同行评审的内容：测试点的理解错误， 测试用例的遗漏；
同行评审的类型：组内的和开发人员 参与的同行评审； 同行评审的过程：制定负责人，收集 问题表，组织召开同行评审会议，跟 踪关闭已经解决的问题。
测试实施
System Team
ReleaseNote
New Version
• SQA工作 由事业部的SQA人员对于测试的各 项活动和输出进行检查，填写不合 格问题； 测试组内容设立QA人员，协助测试 负责人进行一些工作的检查和监督， 并填写SQA周报；
测试实施
• SCM工作
配置项包括：需求文档，和
CheckList;
注意内容：
1. 使用成为基准的内容，开始 下一步的工作； 2.对于CheckList标识版本，需 要时进行翻译；
毕竟开发人员设计软件时主要考虑如何完成仕 样中说明的功能, 到项目中后期正常的功能基 本不会出错,但是一些功能的细节和容错的处理 是开发人员容易忽略的地方.
测试实施
• 自动测试工作
工具：
SQA,只能进行PC版的自动测试； 操作Log:导航机上进行操作记录的工具；
应用：
静态的，无自车走动的； 重复的，可以大大节省手动测试的内容；
测试实施
• 度量数据的收集 收集形式：测试组个人周报； 收集内容：