Hello everyone, I'm XI.
This chapter begins officially into our testing. Well, today we take a look at the work cycle test engineer. Come with me ~
Remember this picture it? In the "software life cycle construes" section of this chart we did a detailed description Oh, did not see or forget quickly go back and look again, not repeat them here.
That test in any place where it? Have you ever noticed? There is a process " quality inspector examination (test) " This is a test Oh, in fact, there is a test that is " Heart get the clothes start to try and see if there are quality problems (test) "; this can be considered a test of it. Are for product testing, to detect whether the target.
Photo: Baidu
Some people may ask Heart customers Yeah, how did she tested it? In fact, the role of the test is the "imitation" of customers, customers to buy things we need to meet customer requirements, the customer receives the goods must be checked whether the mind, before then in order to improve customer satisfaction, we need to be delivered to customers inside there are so to play the role of a client, check in advance whether the customers will meet at the mind, and thus there is a software test this post.
In summary, the test engineer is standing customer use and demand point of test software, report the problem . Report problem is the so-called bug (as to why the problem called bug, I will mark the end of the article)
Speaking before the testing process, let's clear a few concepts:
01
Software Test Engineer goal:
Find software defects as early as possible, and make sure it can be repaired. The other is collected throughout the software life cycle information and prepared for the archives (see below for specific testing purposes)
02
Testing purposes:
Find software defects as early as possible, check whether the system needs to collect the item / The group of useful information (for example: developers coding practices which need to improve, the current mode of operation meets the project / team).
03
testing object:
Program / project / product
File
data
接下来我们详细说说测试的工作流程（其实在软件生命周期的大图里都有介绍，这里单独拿出来再跟大家絮叨下~目的呢就是希望大家能把这个真真实实理解了，变成自己的东西，加油哦~）。如下图所示，是测试的工作周期（右侧灰色部分是每项工作完成后的输出产物）。
针对上图我们--做说明：
需求分析：
描述：需求细化，前面几篇都有说明，这里不再赘述。最终是要整理归档成《需求说明书》或者《需求规格说明书》。
测试策略：
描述：指测试的方式方法（比如功能测试/性能测试/稳定性测试）以及测试要求（比如测试所有功能点符合《需求说明书》和《任务书》要求）
输出：《测试策略》，现在也有很多公司都把测试策略放在测试方案中来写。一般是word编写。
测试计划：
描述：测试组长就要根据《需求说明书》和《任务书》开始编写《测试计划》，测试计划包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。
输出：《测试计划》。测试计划可以是xsl格式（用excel编写），也可以是doc格式（word编写），无论哪种形式，一般是在文档里都以表格方式展现。
测试方案：
描述：一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《需求说明书》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测试方案》编写完成后需要进行组内评审，评审通过则继续系一部的测试用例设计/编写，如果不通过则重新编写，然后再次审核直到审核通过。
输出：《测试方案》。一般是word编写。
测试用例设计：
描述：主要是对测试用例和规程的设计。测试用例是根据《测试方案》和《需求说明书》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要组内评审。
输出：测试用例集。一般在工具上完成（Testlink、excel等等）
测试执行：
描述：执行测试用例，及时提交有质量的Bug和测试日报。及时更新测试用例状态。通过则标注通过，失败则标注失败并且在缺陷管理工具上创建bug，挂起说明原因。
输出：测试用例上的标注。标注通过、未通过、挂起。
回归测试：
描述：对于bug开发修订后会返回给测试，测试需要对bug以及bug相关模块做回归测试。通过后关闭bug，不通过则返回让开发重新修订，直到测试通过为止。
输出：缺陷的状态标注。标注已关闭、已挂起。
测试报告：
描述：是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。最终测试完成要求所有测试用例是通过、已挂起，所有bug是已关闭、已挂起两种状态。
输出：《测试报告》。一般是word编写。
十一的标注：
bug的概念：所谓“（Bug）”，是指程序中隐藏的错误或者缺陷；
bug的由来：1945年9月9日的一个下午，格雷斯·霍波（GraceHopper）中尉正领着他的小组构造一个称为“马克二型”的计算机。
突然，马克二型死机了。技术人员试了很多办法，最后定位到第70号继电器出错。霍波观察这个出错的继电器，发现一只飞蛾躺在中间，已经被继电器打死。她小心地用镊子将蛾子夹出来，用透明胶布帖到“事件记录本”中，并注明“第一个发现虫子的实例。”
从此以后，人们将计算机错误戏称为虫子（bug），而把找寻错误的工作称为（debug）
-来自百度百科
hang bug: For existing technical architecture does not support, the cost of solving large defects can decide whether to suspend the product manager, left to solve later. Specific to solve what time is determined by the product manager.
Well, today's content is over, welcome messages to communicate with me! We see you next time ~