みなさん、こんにちは、私はXIです。
この章では、我々のテストに正式に開始されます。さて、今日は作業サイクルのテストエンジニアを見てみましょう。〜私と一緒に来て
この絵にそれを覚えていますか？ではこのチャートのセクションを「ソフトウェアのライフサイクルはconstrues」私たちは、詳細な説明は、ああ、見なかったか、戻ってもう一度見て、ここではそれらを繰り返さないですぐに忘れませんでした。
そのいずれかの場所で、そのテスト？あなたは今までに気づいたことがありますか？プロセス「があり、品質検査員の検査（テスト）」これはああ、実際には、あるテストがあり、テストでは、「ハートの服を試してみて、品質上の問題（テスト）があるかどうかを確認するために開始を取得」、これはそれのテストと考えることができます。対象かどうかを検出するために、製品のテストのためのものです。
写真：Baiduの
一部の人々は、彼女はそれをテストしたのか、うんハートの顧客を求めることができますか？実際には、テストの役割は、顧客は、我々は顧客の要件を満たすために必要なものを買うために、顧客の「模倣」で、顧客は、顧客満足度を向上させるために、我々はそうである内部の顧客に配信する必要がある前に商品が、心かどうかをチェックする必要があります受け取りますクライアントの役割を果たしていると、顧客が心で会うかどうかを事前に確認し、したがってソフトウェアのテストでは、このポストがあります。
要約すると、テストエンジニアは、問題を報告し、テスト用ソフトウェアの顧客の利用と需要地点に立っています。レポートの問題は（問題はバグと呼ばれる理由として、私は記事の最後をマークします）は、いわゆるバグです
テストプロセスの前にいえば、のは、いくつかの概念をクリアしてみましょう：
0 1
ソフトウェアテストエンジニアの目標：
可能な限り早期に、ソフトウェアの不具合を見つけて、それが修復することができることを確認してください。他には、ソフトウェアのライフサイクル全体での情報収集やアーカイブのために準備される（特定のテスト目的のために以下を参照してください）
0 2
試験目的：
システムは有用な情報の項目/グループを収集する必要があるかどうかを確認し、可能な限り早期にソフトウェアの欠陥を探す（例：開発者は、改善するために必要な慣行をコーディング、現在の動作モードは、プロジェクト/チームを満たしています）。
0 3
テスト対象：
プログラム/プロジェクト/製品
ファイル
データ
接下来我们详细说说测试的工作流程（其实在软件生命周期的大图里都有介绍，这里单独拿出来再跟大家絮叨下~目的呢就是希望大家能把这个真真实实理解了，变成自己的东西，加油哦~）。如下图所示，是测试的工作周期（右侧灰色部分是每项工作完成后的输出产物）。
针对上图我们--做说明：
需求分析：
描述：需求细化，前面几篇都有说明，这里不再赘述。最终是要整理归档成《需求说明书》或者《需求规格说明书》。
测试策略：
描述：指测试的方式方法（比如功能测试/性能测试/稳定性测试）以及测试要求（比如测试所有功能点符合《需求说明书》和《任务书》要求）
输出：《测试策略》，现在也有很多公司都把测试策略放在测试方案中来写。一般是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）
-来自百度百科
バグをハング：既存の技術的なアーキテクチャがサポートされていないため、大きな欠陥を解決するためのコストは、プロダクトマネージャーを中断するかどうかを決めることができ、後で解決するために残しました。プロダクトマネージャーによって決定されたものを時間解決するために、特定の。
さて、今日の内容は、以上の私と通信するために歓迎のメッセージです！私たちは〜あなたの次の時間を参照してください