期待される結果は、ソフトウェアということと実際の結果はユーザーの需要のソフトウェア品質保証ツールと並んで、一貫しているかどうかを検証します
ソフトウェアテストの本当の目的は、バグが見つかったのではなく、バグを防ぐためです
方法（ブラックボックステスト、ホワイトボックス、グレーボックステスト）ソフトウェアのテスト
ブラックボックステスト：テストソフトウェアは関数の外見ることができますが、テストしていないの内部を見ることができません。
ホワイトボックステスト：内部関係ソフトウェアの内部構造、ソフトウェアをチェックするため、コードを見に類似
グレーボックステスト：両方の、結合特性の間です。
機能テスト、パフォーマンステスト、セキュリティテスト：ソフトウェアテストの方向。
ブラックボックステスト機能は、機能テストで使用ブラックボックステストのほとんどの試験に等しくありません。
パフォーマンステスト：ダブル11のシステムケイトン、新年のラッシュチケットグラブ、システム性能の欠如
ストレステスト：見積もり、およびシステムのボトルネックを見つけるためにしようとします。ソフトウェアのパフォーマンスのボトルネックが見つかりました。
負荷テスト：長く続くことができる高強度の仕事を維持するために、テスト・ソフトウェアは、時間の持続期間があります。一般的にシステムの80％〜90％のテストの最終値を使用し、長い時間の中で物事を行います。
同時テスト：どのように多くの人々に多くの人々は、物事がうまくいか同じケースをやっているのと同じ時間を防ぐために、瞬間の誰もが同じことをやって、同時実行、同時に最もクリックをテスト・ソフトウェアを耐えることができます。
セキュリティテストは、ハッカーを防ぐためです。
ソフトウェアのテストは、ステージに分割されています。
ユニットテスト：テストポイント機能/開発コード書き込まれたブロック。試験の範囲は：コードブロック機能、方法及びクラス
統合テスト：モジュールに接続されたテスト対象チャネルのインタフェースモジュール。正しいリンク・テスト・モジュールの接続を行うために統合異なるモジュールを行うためのインタフェースを介して。
システムテスト：最初のテスト機能
統合されたシステムのテストのために、この段階では、我々はテストする必要がありますように機能性、安全性、パフォーマンス、互換性、使いやすさ、安定性、UIとを。
ウェブ：互換性が分かれているのと同じサイトには、内部の異なるブラウザで正常に使用できるかどうか
APP：AndroidとiOSに
使いやすさ：ユーザーエクスペリエンスを指し、
安定性：システムを使用するプロセスがクラッシュまたはソフトウェアはありません、テスト・ソフトウェアは7 * 24連続時間を一般的に実行されます。
UI：システムインタフェース良いか悪いか、レイアウト、デザインをチェックし、ボタンが合理的である、一般的な設計は、検査は、設計と一致しています。
状態カテゴリ別ソフトウェアのテスト：静的（稼動していない）に分け：ホワイトボックステスト方法は、コードを見てください。
ダイナミック：テストを実行するためのソフトウェア。
冒烟测试：正式测试之前的测试，主要的目的是检查是否具有可测试性。随便点一点。
回归测试：开发人员修改之后检查是否修改正确的问题。
α测试：内测，内部人员先尝试使用
β测试：公测，一部分用户也参与试用
研发模型：瀑布模型：依次往下
V字形：
W字形：双V模型，开发和测试同步进行。
敏捷模型：特点：高效地工作，及时的沟通，日报，白板，站立会，集中办公。
软件是什么：程序、文档、数据的合集。
测试的流程分为四个：需求分析阶段：
需求分析：
写需求文档，产品原型（前期对产品有一个直观的 感受，画图的形式体现），口述。
学习业务流程
提取功能点：从大到小把功能点写清楚。可以利用树状图，功能点后边记得写清楚该功能的效果和规则做解释。
编写需求分析说明书：如果没有需求：参考市面上已经成熟的同类型的产品的实现。参考其规则。不是抄袭
测试设计阶段：
测试计划：其重点为：时间和人员以及资源的安排与分配。
测试方案：重点：针对每个测试内容如何开展测试
采用什么测试计划，什么测试工具。
测试策略：重点：哪些内容先测，哪些内容后测，开始测试和结束测试的标准是什么。
以上三点可以用5w1h法也称为六合分析法来编写，再实际工作中合并成一个《测试计划说明书》
重中之重：
测试用例：可以给测试人员提供一个工作的依据。交叉测试。
测试用例一般用Excel表格来编写，里边包括
测试的方法：1.等价类：可以分为有效等价类和无效等价类。
通过最少的数据代表最多的数据，找出最具代表的值
2.边界值：可以根据边界值找到等价类。
3.场景法：
4.因果图：
5.判定表：
6.路径覆盖等
例如微信红包：临界值为0.01~200
0.01（输入0.01边界值）
0.02（比边界值稍微打的数）
有效等价类：200（输入最大边界值）
199.99（输入比边界值稍小的数）
150（输入在边界值范围内的的数）
等价类：
0
无效等价类：
200.01
场景法：
发送成功：
用户输入符合要求的金额发送成功 0.01,0.02,200,199.99,110
微信红包为例
（模拟用户发送结果） 用户什么都不输入，导致发送失败
发送失败：用户输入非数字或者数字和其他字符的组合
用户输入错误的金额范围不能发送成功。
预期结果与实际结果是否一致，如果一致则通过，不一致则有问题
测试执行阶段： 提交BUG
回归测试
BUG的管理平台或工具：禅道，BUGFree，ALM/QC
BUG的六要素
BUG的生命周期
BGU的管理：BUG的状态
BUG的等级
编号
bug的名称：言简意赅，看到名称就知道是什么问题
bug的六要素：bug的优先级：高中低
bug的严重级别，等级
bug的复现步骤
附件：用来佐证bug，日志，截图，小视频
bug的等级：
致命的，导致软件挂了，闪退，崩溃；影响产品的和新流程的正常使用；和钱有关。
严重的，导致功能无法使用
一般的，功能的某些场景有问题
轻微的，建议性的东西。
bug的复现步骤：
可以把用例的步骤复制过来
预期步骤
实际结果
测试应用：
web测试
APP测试：安装/卸载
消息推送
更新
弱网测试
场景交互测试：来电话；正在听音乐；调用相机；前后台的切换
权限测试
离线测试
测试总结阶段：对工作的总结
对bug的统计分析
对被测试软件的评估：一级二级的bug全部都关闭了
三级的bug关闭了80%
四级的bug无所谓