软件测试吧 关注：118,259贴子：702,409
不感兴趣
开通SVIP免广告
二、主要内容
依据优先级分类标准
定义
优先级：指一个BUG相对于其他BUG对于公司的影响，解决的及时性。
分类标准
紧急，例如：
（1）系统无法工作
（2）测试无法继续正常工作
（3）特殊情况：如重要客户（项目重要性）
高，例如：
（1）需求问题
（2）实现与需求不符
（3）出现调试代码
（4）功能性错误
（5）关联性错误
（6）前后模块不一致
（7）链接错误
（8）特殊性的程度性能低下
（9）程序引起的安全问题
注：涉及所有关于数据流的错误
中，例如：
（1）页面格式错误
（2）兼容性问题
（3）校检错误
（4）图片错误
（5）文案错误
（6）程序性能低下
（7）缺少容错性处理
（8）功能易用程度低
（9）配置问题
注：涉及的所有关于文本的错误
低，例如：
（1）遗留问题
（2）暂时无法实现技术问题
（3）合理建议
依据严重程度分类标准
定义
严重程度：指一个BUG对于用户造成的影响，风险和可视性。
分类标准
紧急，例如：
（1）程序无法运行的错误
（2）测试无法执行的错误
非常高，例如：
（1）链接错误
（2）前后模块不一致
（3）需求问题
（4）实现与需求不符
（5）出现调试代码
（6）功能性错误
（7）程序性能低下
（8）程序引起的安全问题
高，例如：
（1）页面格式错误
（2）文案错误
（3）图片错误
（4）兼容性错误
（5）校检错误
中，例如：
（1）关联性错误
（2）配置问题
（3）功能易用程度低
低，例如：
（1）合理建议
（2）遗留问题
（3）暂时无法实现技术问题
注意事项
1) 一些错误可以分在多个级别中，但总的标准以此为准，具体的问题具体分析后再确定其等级数。
2) 为了错误数量的准确性，测试人员提交的每一条BUG报告中只记录一个错误
3) 如果有各个模块中有同类错误的问题，作为多个模块的记录提交，即需要提交多条相同的错误记录，而不是一条记录。
依据优先级分类标准
定义
优先级：指一个BUG相对于其他BUG对于公司的影响，解决的及时性。
分类标准
紧急，例如：
（1）系统无法工作
（2）测试无法继续正常工作
（3）特殊情况：如重要客户（项目重要性）
高，例如：
（1）需求问题
（2）实现与需求不符
（3）出现调试代码
（4）功能性错误
（5）关联性错误
（6）前后模块不一致
（7）链接错误
（8）特殊性的程度性能低下
（9）程序引起的安全问题
注：涉及所有关于数据流的错误
中，例如：
（1）页面格式错误
（2）兼容性问题
（3）校检错误
（4）图片错误
（5）文案错误
（6）程序性能低下
（7）缺少容错性处理
（8）功能易用程度低
（9）配置问题
注：涉及的所有关于文本的错误
低，例如：
（1）遗留问题
（2）暂时无法实现技术问题
（3）合理建议
依据严重程度分类标准
定义
严重程度：指一个BUG对于用户造成的影响，风险和可视性。
分类标准
紧急，例如：
（1）程序无法运行的错误
（2）测试无法执行的错误
非常高，例如：
（1）链接错误
（2）前后模块不一致
（3）需求问题
（4）实现与需求不符
（5）出现调试代码
（6）功能性错误
（7）程序性能低下
（8）程序引起的安全问题
高，例如：
（1）页面格式错误
（2）文案错误
（3）图片错误
（4）兼容性错误
（5）校检错误
中，例如：
（1）关联性错误
（2）配置问题
（3）功能易用程度低
低，例如：
（1）合理建议
（2）遗留问题
（3）暂时无法实现技术问题
注意事项
1) 一些错误可以分在多个级别中，但总的标准以此为准，具体的问题具体分析后再确定其等级数。
2) 为了错误数量的准确性，测试人员提交的每一条BUG报告中只记录一个错误
3) 如果有各个模块中有同类错误的问题，作为多个模块的记录提交，即需要提交多条相同的错误记录，而不是一条记录。
一、什么是缺陷
一切不满足用户需求的都是缺陷。
下面我们对缺陷的概念在详细的介绍一下。
佩腾在《软件测试》一书中说符合下面5个规则的就可以成为软件缺陷：
1、软件未达到产品说明书标明的功能。
2、软件出现了产品说明书中指明不会出现的错误。
3、软件功能超出了产品说明书指明的范围。
4、软件未达到产品说明书中虽未指出但应达到的目标。
5、软件测试员认为软件难以理解、不易使用、运行速度缓慢，或最终用户认为不好。
关于这 5点我们举例来说明一下。第一点，比如说我们开发一个记事本的软件，说明书中明确说了可以输入文字，结果开发的软件不具备输入文本的功能，肯定就是一个 defect了。第二点，说明书中明确说了在记事本软件中输入“联通”可以正确的保存并打开浏览，结果我们的记事本软件打开保存了的输入“联通”的文件出 现了乱码，这也是一个defect了。第三点，比如说我们的说明书中没有定义记事本会自动的对关键字高亮显示（这个主要是针对编程语言），结果我们的记事本程序自动对关键字高亮显示了，这也是defect，尽管这样对用户使用会更好，但是他超出了产品说明书中指明的功能范围，所以还是defect。第四点 不太好说，所以就不用记事本举例了，原谅我，呵呵。比如在我国开发财务管理软件必须要符合财政部的规定，尽管说明书中一般不会指出，但是软件必须要符合这个规定，不然是不能发行使用的啊！第五点就好理解，因为测试员是第一个使用软件的，必须要从客户的角度来对待，尽管这里会有主观感觉，但还是要尽量客观 （就是多参考一些标准，例如定义界面的，检察易用性的标准），比如在Windows下的程序对话框中“是”按钮都是在左边，“否”按钮在右边，如果发现在 我们的记事本程序中，提示是否保存文件的对话框里“是”按钮在右边了，这就是一个defect了，因为它不符合Windows下用户的使用习惯。
知道了什么是缺陷，我们就再来看看怎么去描述一个缺陷吧，看看缺陷都有哪些属性。
一切不满足用户需求的都是缺陷。
下面我们对缺陷的概念在详细的介绍一下。
佩腾在《软件测试》一书中说符合下面5个规则的就可以成为软件缺陷：
1、软件未达到产品说明书标明的功能。
2、软件出现了产品说明书中指明不会出现的错误。
3、软件功能超出了产品说明书指明的范围。
4、软件未达到产品说明书中虽未指出但应达到的目标。
5、软件测试员认为软件难以理解、不易使用、运行速度缓慢，或最终用户认为不好。
关于这 5点我们举例来说明一下。第一点，比如说我们开发一个记事本的软件，说明书中明确说了可以输入文字，结果开发的软件不具备输入文本的功能，肯定就是一个 defect了。第二点，说明书中明确说了在记事本软件中输入“联通”可以正确的保存并打开浏览，结果我们的记事本软件打开保存了的输入“联通”的文件出 现了乱码，这也是一个defect了。第三点，比如说我们的说明书中没有定义记事本会自动的对关键字高亮显示（这个主要是针对编程语言），结果我们的记事本程序自动对关键字高亮显示了，这也是defect，尽管这样对用户使用会更好，但是他超出了产品说明书中指明的功能范围，所以还是defect。第四点 不太好说，所以就不用记事本举例了，原谅我，呵呵。比如在我国开发财务管理软件必须要符合财政部的规定，尽管说明书中一般不会指出，但是软件必须要符合这个规定，不然是不能发行使用的啊！第五点就好理解，因为测试员是第一个使用软件的，必须要从客户的角度来对待，尽管这里会有主观感觉，但还是要尽量客观 （就是多参考一些标准，例如定义界面的，检察易用性的标准），比如在Windows下的程序对话框中“是”按钮都是在左边，“否”按钮在右边，如果发现在 我们的记事本程序中，提示是否保存文件的对话框里“是”按钮在右边了，这就是一个defect了，因为它不符合Windows下用户的使用习惯。
知道了什么是缺陷，我们就再来看看怎么去描述一个缺陷吧，看看缺陷都有哪些属性。
二、缺陷的属性
(1)、缺陷标识：就是缺陷的编号了，每个缺陷有一个唯一的编号。
(2)、缺陷类型：这是一个功能性还是性能的bug，是文档的还是界面的bug，还是本地化的bug。
(3)、缺陷的严重程度：
a、致命Fatal：系统崩溃、数据丢失、数据毁坏。无法进行后续的测试。
b、严重Critical：操作性错误、功能遗漏、影响用户使用。
c、一般Major：UI方面的，一些小的错误，不影响使用。
d、较小Minor：建议性的问题，可以不做修改。
(4)、缺陷的修复优先级：
a、立即修复：影响后续测试的问题。
b、高优先级：在产品发布前必须修复。
c、中优先级：严重程度一般的缺陷。
d、低优先级：有时间就要修复的。
(5)、缺陷的状态
a、open：新提交的bug
b、fixed：已修复等待测试人员验证的bug
c、reopen：测试人员验证发现没有修复的bug
d、closed：测试人员验证已修复的bug
(6)、缺陷的频率---是指缺陷出现的概率
a、总是：可以100%重现
b、通常：出现的概率为80%--90%
c、有时：出现的概率为30%--50%
d、较少：出现频率比较低，2%左右
这里要注意一下缺陷的严重程度和优先级并不是一回事，严重程度说明的是缺陷产生的后果，优先级是修复的优先级。通常严重程度和优先级是一一对应的，但不绝对是。缺陷的严重程度、频率、优先级、状态这些并不是只有这几种情况，每个公司都有自己的定义的。
(1)、缺陷标识：就是缺陷的编号了，每个缺陷有一个唯一的编号。
(2)、缺陷类型：这是一个功能性还是性能的bug，是文档的还是界面的bug，还是本地化的bug。
(3)、缺陷的严重程度：
a、致命Fatal：系统崩溃、数据丢失、数据毁坏。无法进行后续的测试。
b、严重Critical：操作性错误、功能遗漏、影响用户使用。
c、一般Major：UI方面的，一些小的错误，不影响使用。
d、较小Minor：建议性的问题，可以不做修改。
(4)、缺陷的修复优先级：
a、立即修复：影响后续测试的问题。
b、高优先级：在产品发布前必须修复。
c、中优先级：严重程度一般的缺陷。
d、低优先级：有时间就要修复的。
(5)、缺陷的状态
a、open：新提交的bug
b、fixed：已修复等待测试人员验证的bug
c、reopen：测试人员验证发现没有修复的bug
d、closed：测试人员验证已修复的bug
(6)、缺陷的频率---是指缺陷出现的概率
a、总是：可以100%重现
b、通常：出现的概率为80%--90%
c、有时：出现的概率为30%--50%
d、较少：出现频率比较低，2%左右
这里要注意一下缺陷的严重程度和优先级并不是一回事，严重程度说明的是缺陷产生的后果，优先级是修复的优先级。通常严重程度和优先级是一一对应的，但不绝对是。缺陷的严重程度、频率、优先级、状态这些并不是只有这几种情况，每个公司都有自己的定义的。
不感兴趣
开通SVIP免广告
三、bug处理的流程：
这个是最简单的方式了。
下面就是最重要的，我们发现了缺陷就要提交缺陷报告给开发人员，那么如何去写缺陷报告呢？
四、缺陷报告
下面的是一个缺陷报告的基本结构：
A、缺陷编号
B、OS、version、platform、projectname
C、缺陷类型
D、缺陷的严重程度
E、缺陷的频率
F、缺陷的优先级
H、缺陷的状态
I、Summary
J、ReproduceSteps
K、ActualResult
L、ExpectedResult
M、AdditionalInformation
摘要要简明扼要，尽量用执行什么动作发生了什么来描述，比如It pops up an error dialog after clicking the "OK" button on XXX screen.
重现步骤要完整简明，不要包含不必要的信息，每步尽量以动词开头，例如Click XXX button to go to XXX screen.
实际结果要如实的描述发生了什么，不要包含自己的猜想。如：The error dialog pops up about "……"。
期望结果尽量要有依据，比如是根据说明书啊，一般用should，例如：According to the spec page
120, It should ……。
注释可以加上不方便出现在重现步骤中的内容，也可以是图片，log等信息。
写缺陷的一些忠告：
1、要多读优秀的缺陷报告，学习他们是怎么写的。
2、每个缺陷报告尽量的截取图片和log，来帮助开发人员快速定位问题。
3、对重现步骤自己要多执行几遍，确保开发人员可以再现缺陷。
4、缺陷报告要客观得体，不要包含自己的主观情绪
最后和大家分享一下缺陷报告的5C准则：
–Correct（准确）
–Clear（清晰）
–Concise（简洁）
–Complete（完整）
–Consistent（一致）
这个是最简单的方式了。
下面就是最重要的，我们发现了缺陷就要提交缺陷报告给开发人员，那么如何去写缺陷报告呢？
四、缺陷报告
下面的是一个缺陷报告的基本结构：
A、缺陷编号
B、OS、version、platform、projectname
C、缺陷类型
D、缺陷的严重程度
E、缺陷的频率
F、缺陷的优先级
H、缺陷的状态
I、Summary
J、ReproduceSteps
K、ActualResult
L、ExpectedResult
M、AdditionalInformation
摘要要简明扼要，尽量用执行什么动作发生了什么来描述，比如It pops up an error dialog after clicking the "OK" button on XXX screen.
重现步骤要完整简明，不要包含不必要的信息，每步尽量以动词开头，例如Click XXX button to go to XXX screen.
实际结果要如实的描述发生了什么，不要包含自己的猜想。如：The error dialog pops up about "……"。
期望结果尽量要有依据，比如是根据说明书啊，一般用should，例如：According to the spec page
120, It should ……。
注释可以加上不方便出现在重现步骤中的内容，也可以是图片，log等信息。
写缺陷的一些忠告：
1、要多读优秀的缺陷报告，学习他们是怎么写的。
2、每个缺陷报告尽量的截取图片和log，来帮助开发人员快速定位问题。
3、对重现步骤自己要多执行几遍，确保开发人员可以再现缺陷。
4、缺陷报告要客观得体，不要包含自己的主观情绪
最后和大家分享一下缺陷报告的5C准则：
–Correct（准确）
–Clear（清晰）
–Concise（简洁）
–Complete（完整）
–Consistent（一致）
1.2 为什么要做测试需求？
如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。所谓知己知彼，百战不殆。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言。活在自己世界里的人是可悲的，只凭感觉不做详细了解就下定论的项目是失败的。
测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。
如果把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把“软件”两个字全部替换成了“测试”。这样，我们就明白了整个测试活动的依据来源于测试需求。
如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。所谓知己知彼，百战不殆。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言。活在自己世界里的人是可悲的，只凭感觉不做详细了解就下定论的项目是失败的。
测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。
如果把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把“软件”两个字全部替换成了“测试”。这样，我们就明白了整个测试活动的依据来源于测试需求。
不感兴趣
开通SVIP免广告
