本文共 9739 字，大约阅读时间需要 32 分钟。
软件测试质量过程检测文档
A software product is like an airplane: it must undergo a technical check before launch.
软件产品就像飞机：必须在发射前经过技术检查。
Quality Assurance is a necessary step towards launching a successful software product. It is just a small part of all the project work, but nobody said it would be simple.
质量保证是启动成功软件产品的必要步骤。 这只是所有项目工作的一小部分，但没有人说这会很简单。
There are so many types of software testing – automated and manual, exploratory and functional, compatibility, UI/UX, regression, unit, API, and performance testing. Good luck wrapping your head around all of them!
软件测试的类型很多，包括自动化和手动，探索性和功能性，兼容性，UI / UX，回归，单元，API和性能测试。 祝你好运，把头围住！
What is common for all these types, however, is that each requires you to write thorough QA testing documentation. The quality of test documents defines whether your work will prove useful or go in vain.
但是，所有这些类型的共同点是，每种类型都需要您编写详尽的QA测试文档。 测试文件的质量决定了您的工作将证明有用还是徒劳。
I've written this article to make your life a bit easier. So here it is, your ultimate guide on how to write software QA documentation that will work.
我写这篇文章是为了让您的生活更轻松。 因此，这是您如何编写有效的软件质量检查文档的最终指南。
The test plan is a guiding document which outlines the bigger picture of the QA process, and includes a to-do list, strategy, resources, and schedule.
测试计划是一个指导性文件，概述了质量检查过程的总体情况，并包括待办事项列表，策略，资源和时间表。
Before creating a QA plan document, ask yourself “What is the purpose of the software solution?” and “What features need to be tested?”. Do not rush into testing every single part of your software. You need to decide what methodologies, technologies, and tools you will use.
在创建质量检查计划文档之前，请问自己“软件解决方案的目的是什么？” 和“需要测试哪些功能？”。 不要急于测试软件的每个部分。 您需要确定将使用的方法，技术和工具。
The test plan will help you understand the following:
测试计划将帮助您了解以下内容：
The test progress report is another part of the QA documentation, which is similar to the test plan but with added data on the current progress. This document lets you and your development team monitor project progress and identify organizational issues, if any.
测试进度报告是质量检查文档的另一部分，与测试计划相似，但是增加了有关当前进度的数据。 本文档使您和您的开发团队可以监视项目进度并确定组织问题(如果有)。
Once you've clarified the set of functions that need to be tested in your test plan, you need to create a test case for each part of your software.
在明确了测试计划中需要测试的功能集之后，您需要为软件的每个部分创建一个测试案例。
Test cases are pretty simple – this QA documentation consists of 7 sections: ID, Test Case, Testing Steps, Expected Result, Status, Actual Result, and Comments.
测试用例非常简单–此质量检查文档包含7个部分：ID，测试用例，测试步骤，预期结果，状态，实际结果和注释。
ID is a unique number assigned to your test case.
ID是分配给您的测试用例的唯一编号。
In the Test Case section, you point out the requirement(s) you will be testing and provide a link to it in the specifications document.
在“ 测试用例”部分中，指出要测试的需求，并在规格文档中提供指向该需求的链接。
In the Testing Steps section, you list all the actions needed to complete a test case.
在“ 测试步骤”部分中，列出了完成测试用例所需的所有操作。
In the Expected Result section, you summarize the outcome of a particular test if it is successful.
在“ 预期结果”部分中，您总结特定测试的结果(如果成功)。
In the Status section, you indicate if a particular step passed or failed testing.
在状态部分中，您可以指示特定步骤是否通过测试或失败。
In the Actual Result section, you explain the outcome of a failed test.
在“ 实际结果”部分中，您将解释测试失败的结果。
The Comments section is not obligatory, but you can add it to leave some additional notes.
“ 注释”部分不是强制性的，但您可以添加它以留下一些其他注释。
The defect report is an important element of QA documentation. It registers any unwanted issue with your program. It is a crucial element of the project documentation, which navigates you towards getting a bug-free software solution.
缺陷报告是质量检查文档的重要组成部分。 它会在程序中注册任何不需要的问题。 它是项目文档中的关键元素，可引导您获得无错误的软件解决方案。
Sounds simple, right? Yes, but only until you start documenting. Here, you can see an example of a typical defect report:
听起来很简单，对吧？ 是的，但仅在开始记录之前。 在这里，您可以看到典型缺陷报告的示例：
The defect report consists of the following sections: identifier, summary, description, steps to reproduce, reproducibility, severity, priority, environment, and attachments.
缺陷报告包括以下部分：标识符，摘要，描述，重现步骤，可再现性，严重性，优先级，环境和附件。
Each particular software issue is assigned a unique number – the identifier. It optimizes navigation through QA documents and facilitates communication between developers, testers, and PMs.
每个特定的软件发行都分配有一个唯一的编号- 标识符 。 它优化了质量检查文档的导航，并促进了开发人员，测试人员和PM之间的通信。
In the summary section, you provide a concise answer to three simple questions: what happened, where, and under what circumstances.
在摘要部分中，您将提供对三个简单问题的简要答案：发生了什么，在哪里发生以及在什么情况下发生。
In the description section, you describe the bug in detail. You should tell about the actual results and the expected ones. It's useful to provide a link to your software requirements.
在描述部分中，您将详细描述该错误。 您应该告知实际结果和预期结果。 提供指向您的软件要求的链接很有用。
Then, you write about the steps to reproduce (STR). This shows developers exactly how to reproduce the issue. Don't miss a step or your report may return to you.
然后，编写重现步骤(STR) 。 这向开发人员确切说明了如何重现该问题。 不要错过任何一步，否则您的报告可能会退还给您。
In the reproducibility section, you clarify if the bug appears every time you follow the STR. You should use numbers to show approximate chances, for example 7 times out of 10.
在“可再现性”部分，您确定每次遵循STR时是否都出现错误。 您应该使用数字来显示大概的机会，例如10中的7次。
In the severity section, you explain how much harm the bug may bring to the project. In other words, it shows the technological degree of influence of the defect on the entire system. Even a small issue may badly affect the entire application.
在“ 严重性”部分中，您将解释该错误可能对项目造成的危害。 换句话说，它显示了缺陷对整个系统的技术影响程度。 即使是很小的问题也可能严重影响整个应用程序。
Priority shows how important a particular defect report is. Priority can be denoted with the help of letters – “A” for the most urgent and “Z” for the least urgent, numbers – “1” for the most urgent and “9” for the least urgent, or simply words like “high”, “medium”, or “low”.
优先级显示特定缺陷报告的重要性。 优先级可以通过字母来表示–“ A”表示最紧急，“ Z”表示最紧急，“ 1”表示最紧急，“ 9”表示最紧急，或者简单地表示为“高” ”，“中”或“低”。
In the environment section, you should define which operating systems or browser versions were affected.
在环境部分，您应该定义受影响的操作系统或浏览器版本。
Finally, the attachments include the list of videos, screenshots, or console logs files added to the defect report.
最后， 附件包括添加到缺陷报告中的视频，屏幕截图或控制台日志文件的列表。
Defect reports go through a lifecycle – from the moment you report an issue to the moment the issue is closed.
缺陷报告贯穿整个生命周期-从报告问题到关闭问题。
The first step is to compile and submit the defect report. At this point, the Project Manager or a tech lead decides whether to assign it to a developer or to decline it on the grounds of insufficiency or inadequacy.
第一步是编译并提交缺陷报告。 此时，项目经理或技术负责人将决定是否将其分配给开发人员，还是以供不应求或不充分为由予以拒绝 。
After the assigned developer has fixed the bug, you as a QA have to double-check and verify it has been fixed. If yes, you can close the defect report. The best practice is to close it in a week or two.
在指定的开发人员修复了该错误之后，您作为质量检查人员必须仔细检查并确认它已修复。 如果是，则可以关闭缺陷报告。 最佳做法是在一两个星期内将其关闭。
If the bug is not fixed, you reopen the defect report and send it back to the assigned developer. The bug-fixing process can be a long one, but you have to stay strong until all the defect reports are finally closed.
如果错误未修复，请重新打开缺陷报告，然后将其发送回指定的开发人员。 错误修复过程可能很漫长，但是您必须保持强大，直到最终关闭所有缺陷报告为止。
is a process you simply cannot avoid. Each airplane prior to departure undergoes a technical check. If there is any issue, the aircraft is grounded until the problem is solved.
是您无法避免的过程。 每架飞机在起飞前都要经过技术检查。 如果有任何问题，则将飞机停飞直至问题解决。
Similarly, each software product needs to be checked before launch. You cannot afford to deploy buggy software because users will not give your app a second chance.
同样，每个软件产品都需要在启动之前进行检查。 您无力部署错误的软件，因为用户不会给您的应用第二次机会。
My company KeenEthics provides solid . In case you need an estimate for a similar project, feel free to .
我公司KeenEthics提供扎实的 。 如果您需要对类似项目的估算，请随时与我们 。
If you have enjoyed the article, you should continue with and .
如果您喜欢这篇文章，则应该继续阅读“ 和 。
The original article posted on KeenEthics blog can be found here:
可在以下位置找到发布在KeenEthics博客上的原始文章：
翻译自:
软件测试质量过程检测文档
转载地址：http://ofuzd.baihongyu.com/