软件测试相关概念
-
什么是软件?
从开发的角度：软件=数据结构+算法
从测试的角度：软件=程序+文档
问： 所以软件测试的对象是什么?
答： 程序和文档（都要测试）
拓展内容：
软件开发分为哪几个阶段？
-
需求分析阶段
由需求分析人员完成
产出物：需求规格说明书
-
设计阶段
由系统架构师（系统分析师）完成
产出物：概要设计说明书和详细设计说明书
-
编码阶段
由开发人员完成
产出物：程序
问： 哪个阶段产生的bug最多？哪个阶段产生的bug最少？
答：
- 产生bug最多的阶段是需求分析阶段，大约占总缺陷的55%左右；
- 其次就是设计阶段，大约占总缺陷的25%左右；
- 最少的就是编码阶段，大约占总缺陷的15%；
- 还有约5%的缺陷来自于配置或者是兼容性的问题。
得出的结论：
- 软件测试不能只测程序，还要测文档；
- 测试工作应该尽早介入，并且应该贯穿整个项目的始终；
从上面我们可以得出两个原则：尽早测试原则和不断测试原则。
-
-
如何定义软件缺陷？（什么样的情况才算是软件缺陷）
凡是符合以下条件都属于软件缺陷：
-
需求中要求要实现的功能没有实现；
-
实现了需求中没有要求的功能（画蛇添足）；
-
软件中出现了指明不应该出现的错误；
-
需求虽然没有明确说明，但是应该实现的功能没有实现；
说明： 需求并不是完美，有可能遗漏，所以测试人员不能够因为需求的错误而造成测试的错误。
-
程序运行缓慢，不宜于操作，要站在用户的角度上，一切不好的地方都是缺陷。
根据美国电子和电器协会对软件缺陷的定义：
-
从软件产品的内部看
要求测试人员对专业技能比较高(白盒)；
-
从软件产品的外部看
要求测试人员对专业技能不高，只要懂得操作软件的功能即可(黑盒)；
-
-
什么是软件测试？
简单来说，软件测试就是从现有的软件中尽可能多的查找软件缺陷的过程。
说明：
- 软件不是完美的，测试人员的职责不是消灭缺陷，而是尽可能多的查找缺陷；
- 软件测试是查找缺陷的过程，只要完成查找缺陷的过程就是测试，无论找到还是没有找到bug。
-
软件测试的基本步骤（简单、部分步骤）
-->设计、编写《测试用例》;
-->执行测试;
-->记录测试结果,将预期结果和实际的结果进行对比，如果发现结果不一致，发现bug;
-->编写一个《缺陷报告》：记录缺陷，提交给开发人员进行修复。
缺陷报告
-
软件的测试流程（步骤）
- 对被测项目进行详细需求分析(阅读需求，分析整理：功能组成，业务实现，规则)；
- 制定测试计划 (测试组长、测试经理制定测试计划，测试人员主要阅读测试计划和执行测试);
- 设计测试，比如编写测试用例;
- 执行测试，记录测试结果;
- 记录缺陷，跟踪和管理缺陷(编写缺陷报告);
- 分析结果，记录缺陷(《缺陷报告》);
- 缺陷的跟踪、管理 ;
- 测试总结(《测试总结报告》)。
-
缺陷报告
-
什么是缺陷报告？
缺陷报告是指测试人员在发现缺陷之后，将缺陷记录在缺陷报告中并提交给开发方进行修复，通过缺陷报告可以对缺陷进行跟踪和管理。缺陷报告是测试人员与开发人员之间重要的沟通方式。
-
缺陷报告如何编写?
说明：其实缺陷报告的编写，并不是使用文档或者表格的形式进行记录缺陷：在企业中，有专业的缺陷管理工具，不同的企业，缺陷管理工具也可能是不一样的，但是，基本的内容写的大体都是相同。
比如：目前互联网测试使用的缺陷管理工具有（禅道(中文版)，免费使用； qc(英文版) HP公司；bugzilla）
-
如何编写缺陷报告？
案例：被测项目“计算器”的“除数为0”的时候，点击错误消息提示框的确认按钮，程序退出（bug）
-
缺陷编号(DefectID)
-
说明：缺陷编号是记录缺陷的序号，在管理工具中是自动生成的。缺陷编号 并不是记录你当前所测功能的id，它是整个项目缺陷的ID
-
缺陷标题(Summary):概要说明bug。
-
缺陷发现者 (Detected by)
-
提交缺陷时间(Detected on date)
-
缺陷指派给谁(Assigned To）发现缺陷的功能模块(Subject)
-
缺陷所属的版本(Detected in version /release )
-
缺陷状态(缺陷的生命周期)
- 新的缺陷(new)
- 激活缺陷(open)
- 已修复的缺陷(fixed)
- 关闭的缺陷(closed)
- 被拒绝的缺陷(rejected)
- 重新激活的缺陷(reopen)
-
缺陷的严重程度 (severity)
常用的缺陷严重程度分为：
- 致命的缺陷(urgent）通常这类缺陷不解决，直接影响到后续的开发
- 非常严重(very high)
- 严重的缺陷(high)
- 中等严重(medium)
- 建议性的小问题(low)
-
缺陷的优先级
- 立即解决(bug-urgent)
- 可以在本版本中解决(very high)
- 可以在下一个版本中解决(bug-high)
- 可以在软件在发布之前解决(bug-medium)
- 尽量在产品发布之前解决(bug-low)
-
缺陷的描述（description）
将发现缺陷的过程，数据记录下来，使开发人员可以重现该缺陷(开发人员要能看明白);
要求：逻辑清晰、用语要专业、准确、易于理解、不要有任何评价性的语言出现。
-
-
总结：
问题1： 缺陷报告的跟踪处理过程（步骤、生命周期）？（重要面试题）
步骤1：测试人员将新的缺陷报告提交给开发方负责人（开发经理）
步骤2：开发经理验证缺陷报告，
- 情况1：验证通过，将缺陷报告激活，并指派给相应的开发人员。
- 情况2:验证未通过，将拒绝该缺陷。如果测试方最终确定是假缺陷将关闭该缺陷。如果最终确定是缺陷，那么谁拒绝的，谁负责激活缺陷，将缺陷重新纳入缺陷处理流程中。
步骤3：开发人员修改缺陷，修改完成后，将缺陷报告设置为已修复的状态。
步骤4：测试人员对已修复的缺陷进行返测，
- 情况1：返测通过，测试人员将缺陷关闭（可归档）。
- 情况2：返测未通过，测试人员将缺陷重新激活，由开发人员再次修改缺陷，直到返测通过，缺陷关闭为止。
问题2： 被拒绝的缺陷，测试人员要怎么处理？
- 测试人员应该要自己先确认一下是不是由于操作失误，或配置问题，造成假缺陷。
- 测试人员应该分析bug被拒绝的原因，例如：由于需求理解不同，造成bug被拒，可以通过与开发人员、产品经理沟通，讨论解决；如果由于bug不能重现造成被拒，应该与开发人员沟通，讨论解决等。
- 如果与各部门沟通讨论后依然无法解决问题，可以上报测试组长（经理），由组长出面，沟通解决问题。
- 得到最终结论后，如果是假缺陷，测试方负责将假缺陷关闭。如果最终认定是缺陷，那么谁拒绝谁负责将缺陷激活，重新纳入到缺陷处理流程中。
问题3： 影响缺陷优先级制定的因素有哪些？
- 缺陷的严重程度，一般越严重的缺陷，优先级越高。
- 开发人员的开发压力，开发压力越小，优先级越高。
- 缺陷影响的范围，影响范围越大，优先级越高。
- 解决缺陷所花费的成本（时间），成本越低，优先级越高。
问题4： 缺陷的优先级和缺陷的严重程度一定是成正比的关系吗？
不是严格正比关系，例如:界面中有错别字，虽然严重程度低，但是优先级却较高。
问题5： 缺陷的严重程度和优先级确定后还能修改吗？
-
缺陷的严重程度一般确定后是不能更改的;
-
缺陷的优先级可以修改，开发方根据实际情况经常会做拖延处理。（delay）
问题6： 在发布的软件产品中，是否会有发现但没有解决的bug？
-
有可能会有发现但没解决的bug存在于发布的软件产品中;
-
在实际应用中，对于该类缺陷需要开bug讨论会，权衡解决bug的成本，和不解决bug是否会给用户带来严重影响，以及法律纠纷后，才能最终确定;
-
对于该类bug,软件公司会在后期,通过版本升级或打补丁的方式给予解决。
第三讲 等价类划分和边界值法
-
测试用例
定义: 在测试执行之前,由测试人员编写的用来指导测试过程的重要文档。主要组成有：用例编号，测试目的，测试步骤（用例描述），预期结果（期待结果）等。
说明：不同公司使用的测试管理工具不同，所以用例的模板也有可能不同，但是核心的部分是大同小异的。
- 功能（黑盒）测试的主要测试方法?(核心)
- 等价类划分法
- 边界值法
- 因果图法
- 判定表法
- 正交排列法
- 测试大纲法
- 场景法
- 编写测试用例的参考资料（说明：参考资料在实际工作中常常不齐全，测试人员应利用一切能利用的资源参考来测试。）
- 参考软件的需求相关文档。
- 核心的技术类文档（在实际测试中常常没有，例如：开发和测试不是同一家公司的。）
- 已经开发出来的被测程序。（在实际工作中经常会参考被测程序进行测试，如果只参考需求文档大概只能编写30-40%左右的用例）
- 与产品部门、开发部门、客户进行沟通讨论。（还可以参考相似的软件系统，网络上的相关资源等）
- 功能（黑盒）测试的主要测试方法?(核心)
-
等价类划分法
-
应用场合
在程序中，有数据输入的地方可以使用等价类划分法。就是将大量数据划分若干范围，再从每个范围中挑选少量代表数据进行测试的测试方法。(抽样测试)
-
测试思想
-
“穷举测试”思想：将所有可能的数据全都测试一遍。穷举测试是最全面的测试，但是在实际应用中不能采用，因为穷举测试的测试效率极低，而成本高。
-
理想的测试思想：使用最少的测试数据，达到最好的测试质量。但是毕竟没有测试所有数据，有可能有遗漏缺陷的风险。所以如果测试时间允许时，应该进行“补充测试”，以降低遗漏缺陷的风险。（纠结的，随机挑选的，甚至第六感觉得有风险的都可以补充测试）
-
等价类划分法的测试思想
将大量数据划分若干范围（等价类），再从每个范围中挑选少量代表数据进行测试。每个等价类中的代表数据是可以代表整个等价类的测试结果的。
-
-
等价类划分法的测试步骤:
按照被测程序的需求分析，首先要认识两个概念：
-
有效等价类：对于程序来说，正确的，合理的数据。
-
无效等价类：对于程序来说，输入不正确的，不合理的数据。
根据分析出来的等价类画等价类图
-
-
-
边界值法
说明：在程序开发中，边界是非常容易产生bug的地方，所以应该重点测试，为了保证测试质量，可以使用边界值法测试边界。
-
应用场合
在程序中，有数据输入的地方常常使用边界值法，边界值法通常与等价类划分法一起配合使用，以形成一套较为完善的测试方案。
等价类和边界值法通常一起使用，但是某些特殊情况也有可能不是这样,例如：输入性别 ，有效：男、女 无效：男、女以外的 ，不需要边界值法。
-
如何使用边界值法
-
边界值点（2个）
有效等价类和无效等价类之间的分界点。（最大值、最小值）
-
次边界值点（4个）
-
边界值两边相邻的点是次边界值。
名称
（有效、无效）最小次边
（有效、无效）最大次边界
-
-
问题：
Q1：如果测试时间紧张，优先测试哪个边界值？
最大值和最小值 （边界值点）
Q2：边界值在需求中开始就确定好了吗？
不一定，有些边界值在开始时没有确定，可能逐渐才能明确。
练习：
1)年龄：18-60之间的整数
2)账号：3-20个字符
测试方法之因果图和判定表法
-
应用场合
界面中有许多个控件，控件之间存在组合和相互限制的关系。不同的输入条件的组合会有不同的输出结果。为了理清每个输入条件的组合和输出结果，因此要使用因果图和判定表法。
说明：因果图和判定表比较适合用于测试控件比较少的被测项目中。（一般控件少于20种）
-
对因果图基础认识
-
因果图的因是什么？ 果是什么？
因：输入条件 果：输出结果
-
什么是因果图法？
是用画图的方式，表示因与果之间的关系。
-
因果图的图形符号
因果图的基本图形符号 用来表示因---果之间的关系
-
恒等 (只允许一个输入条件)
如果a=1，那么b=1
如果a=0，那么b=0
-
与 (多个输入条件 至少2个输入条件)
输入条件全为1的时候，结果才是1，有一个为0 则结果就是0。
-
或 (多个输入条件 至少2个输入条件)
-
非 (允许一个输入条件)
如果a=1 那么b=0
如果a=0,那么b=1
-
-
因果图的限制图形符号 用来表示因--因 果--果之间的限制关系
-
互斥 (E—Exclude)
在输入条件中，可以不选，如果选只能选择一个。
-
唯一 (O-Only)
有且只有一个选择（不能不选，必须要选择一个）。
唯一与互斥的区别：
互斥可以不选，要选只能选择一个，唯一必须要选择一个。
-
包含 (I-include)
至少选择一个，可以多选，不能不选。
-
要求(R-required)
如果a=1,那么b=1；
如果a=0,那么b的值没有要求。
-
屏蔽 (M-masked)
如果a=1,那么b必须是0；
如果a=0,那么b可以是0，也可以是1。
-
-