Assignment 2
| 姓名 | 学号 | 学院 | 专业 |
|---|---|---|---|
| 米家龙 | 18342075 | 计算机学院 | 软件工程 |
1. 综述软件测试的16条公理
有些人反对软件测试公理的概念，他们认为所有测试规则、原理、技术和方法都是启发式的；启发式方法在可用性和准确性方面受到限制，是有限并且不可靠的。
测试公理分成三部分：
- 利益相关者公理
- 测试设计公理
- 测试执行与交付公理
利益相关者公理
测试是测试者（代表测试利益相关者）执行的信息或者情报收集活动
1. 利益相关者公理：测试需要利益相关者
确定并招募能将要使用我们提供的测试证据并且能从中获益的组织/人员；需要明确如下问题：
- 测试者是谁？
- 测试者代表谁的利益？
- 测试者想要什么证据？
- 测试者需要什么？
- 什么时候需要测试者？
- 测试者以什么样的形式进行测试？
- 测试者多久进行一次测试？
2. 价值公理：测试的价值是为利益相关者提供决策依据
不管来源如何，测试的结果和测试证据的提供方式决定了价值；需要明确如下问题：
- 利益相关者必须做出哪些验收决定
- 利益相关者需要哪些证据才能自信地做出这些决定？
- 什么时候能收集到所需的证据？
- 谁能够提供相关专业知识来组织测试（并使其有价值）？
- 谁有资格执行测试？
- 能否指定可以执行测试的人员组织（他们能否胜任测试）？
- 需要在什么环境和架构下测试要有意义和价值？
3. 范围管理公理：如果我们不约束测试的范围，我们永远无法符合利益相关者的期望
测试者需要明确并同意项目范围内外的项目，并随着时间推移来管理规模；有这些具体问题：
- 利益相关者如何定义系统的范围和哪些需要测试？
- 哪些知识来源可以用来详细定义和理解范围？
- 促成变革的可能因素有哪些？
- 测试者该如何适应测试范围的变化？
- 测试者该如何分析范围变化的影响？
- 测试者是否有权拒绝或者挑战变更？
- 如何保证缺陷的修复（并重新通过测试）？
- 测试者如何测试变更？
- 测试者如何传递测试的状态？
4. 足够好公理：测试和验收的范围始终是妥协的结果
利益相关者和测试者必须共同认识到：测试缺少限制，并且软件的验收决定永远是基于不完整的证据；而实际上，基于利益相关者已知的信息，即使有特定的证据，软件的验收仍可能发生；需要明确下列问题：
- 作出验收决定需要多少测试的证据？
- 谁有权作出验收决定？
- 评估测试过程中收集到的证据的机制是什么？
- 哪种覆盖模型可以用来判断已经收集到了足够的证据？
- 哪种标准用来判断被测试的系统能否验收？
测试设计公理
测试是一个创建环境、系统、人性和测试本身的思维模型的过程。测试设计则是为了寻找对利益相关者最有价值的测试的过程。通过测试基础，我们可以选择测试系统的哪些方面，测试基础是不可靠的；测试模型能够帮助测试者以系统的方式选择测试。
5. 测试设计基于模型
需要选择能够得出对利益相关者有意义的测试的测试模型；同时需要认识到测试模型本身带有的局限性和模型做出的假设；需要明确如下问题：
- 是否可以将设计模型用作测试模型？
- 它们是强制性的么？
- 哪些测试模型能从“测试基础”中导出测试？
- 哪些测试模型可以使用？
- 测试模型是否需要被记录？或者它们纯粹是思维模型？
- 使用这些模型有什么好处？
- 这些模型有哪些简化的假设？
- 模型如何有助于提供对验收决策者有用的证据？
- 模型如何结合来提供足够的证据同时避免重复？
- 如何限制模型派生的测试数量？
6. 测试基础公理：测试者需要知识来源以选择测试内容
需要识别并且同意识别测试内容所需的只是来源。使用多个知识来源，并比较和交叉检查他们。有如下需要明确的问题：
- 使用哪些资源来描述系统并确定测试的内容？
- 这些来源的派生/继承/来源/可靠性是什么？
- 这些来源的权限优先级是什么？测试结果如何与利益相关者的目标和关注点相关？
- 谁能授权使用这些知识来源？
- 谁能仲裁/解决这些知识来源的冲突？
- 谁或什么能提供这些来源弥补空白的知识？
7. 先知公理：测试者需要知识来源以评价被测对象的实际产出或行为
明确并同意能够决定预期结果所需要的知识来源。使用多个知识来源，并比较和交叉检查他们。有如下需要明确的问题：
- 应该使用哪些知识来源来得出预期结果以验证观察到的行为？
- 利益相关者能否同意将这些资源用作测试先知？
- 我们对这些资源有什么信心？
- 在执行这些测试前，是否需要将预期结果记录？
- 这些来源的派生/继承/来源/可靠性是什么？
- 这些来源的权限优先级是什么？
- 谁能仲裁/解决这些相关冲突？
8. 覆盖公理：测试需要一个或多个覆盖模型
测试者需要一种对利益相关者有意义的方式来评估所选测试模型相对于测试的彻底性或完整性
- 如何明确描述测试的彻底性或充分性的覆盖范围？
- 是否可以使用覆盖定义来定义一个量化的衡量覆盖？
- 覆盖措施如何与利益相关者的目标和关注点相关？
- 这些措施可以支持估算、计划和进度报告吗？
- 如何向利益相关者阐明测试的彻底性/充分性？
- 关于系统的可接受性，可以对这些覆盖措施做出什么解释？
9. 优先公理：测试需要一种机制来排序测试优先级
测试人员需要能够按价值顺序对测试进行排名，并确定哪些测试最有价值；需要解决如下问题：
- 谁能定义用于测试对象的优先级？
- 如何阐明优先事项？
- 当前环境下，测试有哪些限制？
- 谁有权施加、更改或消除这些限制？
- 在范围界定过程中，谁将授权包含或排除测试？
- 在测试设计过程中，谁能授权包含或排除测试？
- 在测试执行过程中，谁能授权包含或排除测试？
10. 易失性公理：测试的知识来源是模糊且不完整的
测试基础，模型，先知和优先级划分方法是容易犯错误的，因为定义和使用它们的人员容易出现错误。因此需要明确如下问题：
- 如何确定测试所需的知识来源？
- 谁负责这些来源中的内容？
- 来源的内容能否被一致同意？
- 来源是否稳定？
- 是否已经对来源进行验证？（根据其他参考资料，或者贡献者和利益相关者的经验）
- 如何最大限度地减少错误对知识来源的影响？
- 当来源出现矛盾/错误，谁能仲裁/解决这些相关冲突？
测试执行与交付公理
充足的证据才能支持接受决策的信心；而证据的价值则取决于决策者的判断
11. 信心公理：通过利益相关者做决策时的信心来衡量测试的价值高低
测试者必须了解测试证据与利益相关者的决定之间的关系。测试应着重于给利益相关者能够有信心做出决策的证据。因此需要解决这些问题：
- 利益相关者需要有哪些证据才能自信地做出决策？
- 利益相关者将如何使用该证据？
- 在计划，规格，会议和其他通讯中如何阐明测试的目标？
- 我们如何确保证据尽早送达利益相关者？
- 我们将如何确保所产生证据的准确性和时效性？
- 产生的证据在格式，细节，频率，精度，准确性方面有哪些偏好？
- 利益相关者将如何传递，认可和审查证据？
12. 重复测试公理：一些重复测试是不可避免的
决策者需要制定并同意重新测试和回归测试的政策，并在预算和计划中允许重复测试的存在。
- 什么情况下会重新进行之前失败的测试？
- 什么情况下会重新通过测试？
- 保留测试以备重用的标准是什么？
- 什么情况下保留的测试将被丢弃或修改？
- 为了进行计划，需要估计或定义：
- 测试失败的比例
- 修复和重新测试缺陷所需的时间
- 用于回归目的的测试比例
13. 执行排序公理：先执行最有价值的测试—否则可能没有时间执行它们
如果执行时间有限或测试已停止，则顺序测试可确保运行最有价值的测试。需要考虑如下问题：
- 排序的标准是什么？
- 如何对计划外和临时测试进行排序？
- 顺序测试的限制条件有哪些？
- 如何最小化和管理测试之间的依赖关系？
- 什么情况下测试会失序？
14. 环境公理：测试执行需要明确、可控的测试环境
该公理要求测试者需要确定对环境和用于测试的测试数据的需求和要求，包括及时管理该环境的更改的机制
- 谁负责测试环境的获取、配置和支持？
- 测试模型对测试环境有哪些假设？
- 如何阐明、协商测试环境的要求？
- 如何保证测试环境的有效性和可用性？
- 如何对环境的变化进行管理，使其与需求和被测其他可交付成果的变化保持一致？
- 如何管理环境状态，包括备份和还原的版本？
15. 事件公理：测试永远不会按计划进展，测试所得到的证据按照离散量子化的模式出现
- 测试方法如何适应计划外事件？
- 计划如何阐明测试执行的不确定性和期望？
- 如何管理测试基础，系统或环境的变更？
- 如何沟通，跟踪和管理测试失败？
- 如何记录，跟踪，分析和报告对测试有不利影响的计划外事件？
16. 永无止境的公理：测试永远不会结束，只会停止
测试通常是有时间限制的，可能无法完成
- 利益相关者能否意识到测试可能不会在计划的时间范围内完成？
- 测试者是否理解可能不会运行所有测试，是否可能根据不完整的证据做出接受决定？
- 测试者是否准备告知、建议和协助接受决定？
- 测试者在提供测试证据和状态方面将扮演什么角色？
- 测试者将如何支持利益相关者判断不确定结论的相关性/重要性？
2. 结合你所熟悉的一套软件，针对上述公理表述你的见解
软件选择飞书，飞书以一个主要目标用户为企业的即时通讯系统，集成了大量的效率管理和协作应用。
利益相关者相关
- 公理1、公理2：飞书目标用户企业/组织之间的交流，明确了目标用户和利益相关者，便能够选择出合适的测试人员，从而推进测试的进度和方向
- 公理3：由于该软件本身是在不断更新的，会不断添加有利于企业协作/效率的工具，因此测试者需要不断适应并测试更新的程序，同时将测试者测试的范围约束在企业内部，从而保证决策者能够接收到合理的反馈，并对下一步的开发提供帮助
- 公理4：飞书的功能设计和实际完成效果（即测试效果）并不能完美契合，但是在敏捷开发的过程中，很多功能日程安排并不会给开发有足够长的时间修复和完善，而测试也并不能够有足够完善的能力覆盖所有的功能，即新加功能是否会和前面冗杂的功能有矛盾等；因此决策者和测试者不得不进行妥协
测试设计相关
- 公理6，公理7：如果只从开发者的角度对软件功能进行测试，那么在测试的时候很难得出符合目标用户需求的结论
- 测试者需要企业员工的知识，从企业员工的角度分析测试的内容和结果是否符合预期
- 测试者需要信息安全相关的知识，从信息安全的角度分析通讯和软件能否符合信息安全要求
- 公理9：飞书本质上是一个即时通讯系统，因此通讯相关的功能优先级更高，其他工具的优先级相较而言就低一些
- 公理10：在绝大多数开发项目中，都存在这样的问题：需求质量很差，测试设计所依赖的许多知识：如应用场景，如系统在异常下的行为和结果，都是不明确的，这也是我们一直希望测试能够尽早投入，通过详细的测试设计来提升需求质量，达到预防缺陷的根本原因
测试执行与交付
- 公理12：一些重复测试是不可避免的；由于版本的更新与功能的增加，以及环境和使用技术的变化，需要有重复的测试来保证软件在上面变化的过程中依然能够使用，避免新代码的加入导致整体的缺陷与漏洞；并且由于测试的不完善性，重复的测试有利于发现原本忽略掉的漏洞，从而减少相关损失
- 公理13：先执行最有价值的测试；由于软件开发周期的限制，对于飞书这样一个体量庞大的系统，如果每次更新都对全部功能细节都要进行一次测试的话，将会消耗大量的成本，因此根据公理9，测试的优先级和高优先级优先测试是有必要的
- 公理14：测试执行需要明确、可控的测试环境；为了更加明确的寻找问题，控制变量法是最简单方便的对比方法，有一个稳定、可控的环境能够大大降低测试的随机性，从而提供更加稳定的测试结果
- 公理16： 测试永远不会结束，只会停止。无论何时，只要你进行测试，就一定会发现更多缺陷。因此，测试是被动停止而不是主动完成，停止的原因是因为我们提供了足够的证据，使得决策者认为剩余的产品风险已经可以承担，已经满足客户的应用期望，因此测试不是“盖章放行”，不是质量的“看门人”。