软件测试回顾(3)
软件测试回顾(3)
07章：如何高效写缺陷报告?
提BUG是测试和开发沟通问题的路径,怎么写好无歧义的bug,个人认为是非常重要的一件事
缺陷报告是测试工程师与开发工程师交流沟通的重要桥梁，也是测试工程师日常工作的重要输出。作为优秀的测试工程师，最基本的一项技能就是，把发现的缺陷准确无歧义地表达清楚。
缺陷报告本身的质量将直接关系到缺陷被修复的速度以及开发工程师的效率，同时还会影响测试工程师的信用、测试与开发人员协作的有效性。
你必须牢牢记住的是，好的缺陷报告绝对不是大量信息的堆叠，而是以高效的方式提供准确有用的信息
提交bug前
递交缺陷报告前,通常会去缺陷管理系统搜索一下是否已经有人递交过类似的缺陷。
bug标题
缺陷标题通常是别人最先看到的部分，是对缺陷的概括性描述，通常采用“在什么情况下发生了什么问题”的模式。
- 对“什么问题”的描述不仅要做到清晰简洁，最关键是要足够具体，切忌不能采用过于笼统的描述。
- 描述“什么问题”的同时还必须清楚地表述发生问题时的上下文，也就是问题出现的场景。
- 标题应该尽可能描述问题本质，而避免只停留在问题的表面。
- 缺陷标题不易过长，对缺陷更详细的描述应该放在“缺陷概述”里。
不要描述表面问题可太真实了，曾经的领导和我说过，提交bug，直接告诉开发修哪里，这才叫爽。 还有在提交一个bug前，我建议可以思考下，假如一个不知道这个情况的人，能不能读懂你的信息，
bug概述
缺陷概述通常会提供更多概括性的缺陷本质与现象的描述，用清晰简短的语句将问题的本质描述清楚是关键。清晰简洁地描述缺陷，使开发工程师能够聚焦缺陷的本质
bug影响
缺陷影响决定了缺陷的优先级（Priority）和严重程度（Severity）
测试工程师准确描述缺陷影响的前提是，必须对软件的应用场景以及需求有深入的理解，这也是对测试工程师业务基本功的考验。
严重程度是缺陷本身的属性，通常确定后就不再变化，而优先级是缺陷的工程属性，会随着项目进度、解决缺陷的成本等因素而变动。
- 缺陷越严重，优先级就越高；
- 缺陷影响的范围越大，优先级也会越高；
- 有些缺陷虽然从用户影响角度来说不算严重，但是会妨碍测试或者是自动化测试的执行，这类缺陷属于典型的严重程度低，但是优先级高；
- 有些缺陷虽然严重程度比较高，但是考虑到修复成本以及技术难度，也会出现优先级较低的情况。
确实，不深入了解业务的测试，往往就定位错bug的优先级。
环境配置
环境配置用以详细描述测试环境的配置细节，为缺陷的重现提供必要的环境信息。
环境配置的内容通常是按需描述，也就是说通常只描述那些重现缺陷的环境敏感信息。
之前遇到过一个公司，无论什么bug，都需要填写很详细的环境配置，这就导致很简单的ui问题也要提一个很长的bug单
前置条件
前置条件是指测试步骤开始前系统应该处在的状态，其目的是减少缺陷重现步骤的描述。合理地使用前置条件可以在描述缺陷重现步骤时排除不必要的干扰，使其更有针对性
重现步骤
缺陷重现步骤是整个缺陷报告中最核心的内容，其目的在于用简洁的语言向开发工程师展示缺陷重现的具体操作步骤。
操作步骤通常是从用户角度出发来描述的，每个步骤都应该是可操作并且是连贯的，所以往往会采用步骤列表的表现形式。
需要注意的点：
- 确保缺陷的可重现性；
- 找到最短的重现路径，过滤掉那些非必要的步骤
这就意味着不断的重现bug，可能一开始浪费了一定时间，后期熟练可能就不会操作过多的遍数
对于缺陷重现步骤的描述应该尽量避免以下3个常见问题：
- 笼统的描述，缺乏可操作的具体步骤。
- 出现与缺陷重现不相关的步骤。
- 缺乏对测试数据的相关描述。
当你描述期望结果时，需要说明应该发生什么，而不是什么不应该发生；而描述实际结果时，你应该说明发生了什么，而不是什么没有发生。
就按照写测试用例的方式来写重现步骤，要每一步都可以执行
变通方案
临时绕开当前缺陷而不影响产品功能的方式，通常由测试工程师或者开发工程师完成，或者他们一同决定。
根因分析
如果你能在发现缺陷的同时，定位出问题的根本原因，清楚地描述缺陷产生的原因并反馈给开发工程师，那么开发工程师修复缺陷的效率就会大幅提升，而且你的技术影响力也会被开发认可。
但大多数情况下，测试没办法接触到业务代码，或者没有能力去追bug，最多测试能追到的bug，开发一眼就看出来了。
个人觉得根本原因就是：测试不能深入业务代码，别说深入业务代码了，大多数甚至连设计方案，实现逻辑都不知道
附件
对于那些很难用文字描述清楚的GUI界面布局的缺陷，你可以采用截图并高亮显示应该关注的区域的方式去提交缺陷报告。
最难受的莫过于，你辛辛苦苦写完复现步骤，开发不看，直接叫你复现。
08章：制定测试计划
对于很多非产品型的互联网公司，由于采用了敏捷开发模式，的确很少去制定传统意义上的测试计划了，但这并不是说它们就不再制定测试计划了。
只不过是，测试计划的表现形式已经不再是传统意义上庞大的、正式的测试计划文档了，而更多的是体现在每个迭代（sprint）的计划环节，而且这样的短期测试计划可以非常迅速地根据项目情况实时调整。
测试计划依旧存在，只是从原来的一次性集中制定测试计划，变成了以迭代的方式持续制定测试计划
一份好的测试计划要包括：测试范围、测试策略、测试资源、测试进度和测试风险预估，这五大方面，并且每一部分都要给出应对可能出现问题的解决办法。
1.测试范围
测试范围中需要明确“测什么”和“不测什么”。
2.测试策略
测试策略简单来讲就是需要明确“先测什么后测什么”和“如何来测”这两个问题。
测试策略还需要说明，采用什么样的测试类型和测试方法
1.功能测试
对于功能测试，应该根据测试需求分析的思维导图来设计测试用例。
通常应该先实现主干业务流程的测试自动化
通常需要先列出主要的功能测试点，并决定哪些测试点适合采用自动化测试，并且决定具体使用什么样的框架和技术。
对于需要手工测试的测试点，你要决定采用什么类型的测试用例设计方法，以及如何准备相关的测试数据。
测试策略主要是把优先级搞出来，再把自动化和手工挑出来，在对手工测试点进行设计用例(一般会让细化测试点)
2.兼容性测试
兼容性测试的实施，往往是在功能测试的后期，也就是说需要等功能基本都稳定了，才会开始兼容性测试。
兼容性测试用例的选取，往往来自于已经实现的自动化测试用例。道理很简单，因为兼容性测试往往要覆盖最常用的业务场景，而这些最常用的业务场景通常也是首批实现自动化测试的目标。
兼容最后做的结果就是：测试说 不支持某个环境，开发说要更改成本太大了，发布日期又迫在眉睫，项目经理就会说：那就不支持了吧(哈哈哈哈)
所以要在最后做兼容性测试，就一定要把必须支持的功能前期验证出来
3.性能测试
需要在明确了性能需求（并发用户数、响应时间、事务吞吐量等）的前提下，设计性能测试场景并确定性能测试框架。
首先，需要根据你想要解决的问题，确定性能测试的类型；然后，根据具体的性能测试类型开展测试。
3.测试资源
测试资源就是需要明确“谁来测”和“在哪里测”这两个问题。
- 测试人员的资源通常有两个维度：一是，测试工程师的数量；二是，测试工程师的个人经验和能力。
- 测试工程师的经验和能力不足，很难通过测试人员的数量来弥补。
- 把具体的任务清晰地落实到每个人的身上，这将有利于建立清晰的责任机制，避免后续可能发生的扯皮
测试资源我觉得最重要的是对环境和数据的准备，老师在文章说测试环境可以使用docker进行复用，可是有些公司是不允许和生产环境不一致上测试的，否则会视为无效测试，再加上整体的服务器资源少，在搭建一套主备机、集群下来，每个人分到的就又很少了。其次是测试数据，测试数据大家不共享，都在各搞各的，每个人都是信息孤岛，导致效率及其低下，我还没见过标准的共享测试数据的公司(大哭)
4.测试进度
测试进度主要描述各类测试的开始时间，所需工作量，预计完成时间，并以此为依据来建议最终产品的上线发布时间。
版本接受测试（Build Acceptance Test）的工作量，冒烟测试（Smoke Test）的工作量，自动化脚本开发的工作量，缺陷修复的验证工作量，需要几轮回归测试、每一轮回归测试的工作量等等。
还有测试进度受开发和测试经理的脑子影响比较大，开发质量差就会导致延期、加人手。测试经理脑子不好，就会造成“赶工”的情况，为了完成测试经理吹的nb。
5.测试风险评估
在制定测试计划时，你就要预估整个测试过程中可能存在的潜在风险，以及当这些风险发生时的应对策略。
对于需求变更，比如增加需求、删减需求、修改需求等，一定要重新进行测试需求分析，确定变更后的测试范围和资源评估，并与项目经理和产品经理及时沟通因此引起的测试进度变化。测试经理/测试负责人切忌不能有自己咬牙扛过去的想法，否则无论是对测试团队还是对产品本身都不会有任何好处。
随着测试的开展，你可能会发现前期对于测试工作量的预估不够准确，也可能发现需要增加更多的测试类型，也可能发现因为要修改测试架构的严重缺陷而导致很多的测试需要全回归，还有可能出现开发递交测试版本延期，或者人员变动等各种情况。
这块太真实了，出现变动(需求变动、技术方案调整)如果不进行风险评估并且上报，就想着自己扛下来，那就是在作死(变更的风险本来由PM、开发承担，结果由测试隐瞒不报，就变成自己的了)
