说到测试，就要先讲一下测试的流程。下面我按照测试的流程，去分析和演示一下测试的方法和过程：
1、需求分析
现在要测试一个登录界面，验证页面上所有功能的可用性，要测试的界面如下：
需求分析：
- 这是一个登录界面，首先，需要有账号、密码输入框，和登录按钮；
- 需要有两种登录方式，账号密码登录和扫码登录；
- 既可以使用QQ号登录，也可以用微信登录，可以手动切换；
- 需要记住密码功能，第二次登录时只需选择已登录过的账号，即可自动补全密码；
- 需要自动登录功能，双击快捷方式后，软件自动完成登录进入主程序界面；
- 需要找回密码功能，可以找回忘记的密码；
- 需要注册账号功能，可以注册新的QQ账号；
- 需要设置功能，里面可以设置网络，可以设置服务器；
- 需要关闭按钮，可以关掉登录窗口。
2、编写用例
测试用例是执行测试时的依据，用例是根据需求去编写的，每个需求可以生成一条或多条用例（因为一个需求可能包含多个操作，每个操作都可能需要进行功能的验证）。现在我以【账号、密码登录】为例，演示一下账号密码登录功能测试的用例。
分析账号、密码登录功能，要写用例，主要分为以下几种情况：
1. 正确账号、正确密码
2. 正确账号、错误密码
3. 错误账号、正确密码
4. 错误账号、错误密码
5. 正确账号、空密码
6. 空账号、正确密码
用例编写如下：
| 序号 | 功能名称 | 操作步骤 | 预期结果 | 实际结果 | 是否通过 |
|---|---|---|---|---|---|
| dl-01 | 正常登录 | 输入“正确账号、正确密码”，点击【登录】按钮 | “登录成功” | ||
| dl-02 | 密码错误 | 输入“正确账号、错误密码”，点击【登录】按钮 | “登录失败，提示：密码错误” | ||
| dl-03 | 账号错误 | 输入“错误账号、正确密码”，点击【登录】按钮 | “登录失败，提示：账号或密码错误” | ||
| dl-04 | 账号密码都错误 | 输入“错误账号、错误密码”，点击【登录】按钮 | “登录失败，提示：账号或密码错误” | ||
| dl-05 | 密码为空 | 输入“正确账号”，密码不填，点击【登录】按钮 | “提示：请输入密码后再登录” | ||
| dl-06 | 账号为空 | 输入“正确密码”，账号不填，点击【登录】按钮 | “提示：请输入账号后再登录” |
3、执行测试
根据上面用例的描述，执行测试操作，并记录实际结果到用例表格里，对比实际结果和预期结果是否一致，如果不一致，则说明有bug。
| 序号 | 功能名称 | 操作步骤 | 预期结果 | 实际结果 | 是否通过 |
|---|---|---|---|---|---|
| dl-01 | 正常登录 | 输入“正确账号、正确密码”，点击【登录】按钮 | “登录成功” | 登录成功 | 是 |
| dl-02 | 密码错误 | 输入“正确账号、错误密码”，点击【登录】按钮 | “登录失败，提示：密码错误” | 登录成功 | 否 |
| dl-03 | 账号错误 | 输入“错误账号、正确密码”，点击【登录】按钮 | “登录失败，提示：账号或密码错误” | 登录失败，无提示 | 否 |
| dl-04 | 账号密码都错误 | 输入“错误账号、错误密码”，点击【登录】按钮 | “登录失败，提示：账号或密码错误” | 登录失败，无提示 | 否 |
| dl-05 | 密码为空 | 输入“正确账号”，密码不填，点击【登录】按钮 | “提示：请输入密码后再登录” | 登录成功 | 否 |
| dl-06 | 账号为空 | 输入“正确密码”，账号不填，点击【登录】按钮 | “提示：请输入账号后再登录” | 提示：请输入账号后再登录 | 是 |
如上面的用例执行结果所示，大部分用例执行的结果都是不通过的，只有第一条和最后一条是通过的，而且综合分析后发现，登录功能只对账号进行了验证，对密码根本没有校验，且提示语也有缺失。
这种情况，说明功能开发的不够完善，并不符合测试的基本条件，因为用例里面的每条都是最基本功能的验证，最基本功能都不能通过验证，是不能进行系统测试的。
我们把验证最基本功能（主要功能）的测试，叫做冒烟测试。如果冒烟测试不通过，则需要直接打回到开发那里，由开发人员进行自测。当开发人员自测基本功能无误后，重新提交到测试人员手里进行系统测试，对功能的更多细节问题进行验证。
事实上，当我们测试到第二条时，发现不能验证密码准确性的bug，就已经说明未通过冒烟测试了，账号密码登录的测试，最重要的就是验证账号和密码：1、准确性，2、必填性。如果准确性都不能校验，说明功能开发未完成（或者开发不完善），必须重新开发（或者开发者进行自测和完善）。
4、跟踪bug
说通俗点就是时不时查看bug修复的进度，及时督促和跟进开发人员修复bug，不要拖延修复bug的时间，避免项目延期。好的测试工程师，提交的bug，可以简单便捷、通俗易懂的将问题描述清楚，同时更好的方便开发人员定位bug。（下面我所讲的都是一般的功能测试，不涉及性能、安全、自动化等更高级的测试）
通常情况下，当我们发现了bug之后，我们都会通过图文或者视频等描述，将bug复现的方式展现给开发的同事，或者将日志文件也发给同事，便于开发快速定位bug。我们以普通功能测试为例：就是将操作步骤、预期结果和实际结果详细描述一下，告诉开发，说明问题所在即可。
当我们进行系统测试的时候，由于功能模块很多，bug的数量也会比较多，如果用QQ/微信聊天的方式说明bug，或者使用文档记录bug的方式，并不方便测试人员跟进bug的修复进度，很可能时间久了还会导致一些提交过的bug会忘记修复和复测。因此，为了解决这个问题，市面上大多数IT公司都在使用bug管理系统进行bug提交和跟进。比较常见的bug管理工具有禅道、jira、tapd等等，我比较推荐的还是【禅道】！
禅道首页
禅道提交bug的界面
使用禅道的方法，属于另外的内容了，本文就此略过。总之，使用bug管理工具，可以随时查看bug的修复进度，方便开发修复bug，同时也方便测试复测已修复的bug，可以使工作效率大大提升。
5、交叉测试
当各个模块都进行了测试以后，就需要进行交叉测试来更好的覆盖所有功能点，避免漏测等问题的出现。
所谓交叉测试，也就是交换功能测试，原本“A测试甲模块，B测试乙模块”，现在改为“A测乙，B测甲”。
我们都知道，一个人的思考，难免存在着疏漏之处，所以才有“三个臭裨将，顶个诸葛亮”之说，进行交叉测试就是为了避免漏测的，多个人测试，就能更好的覆盖功能测试点。交叉测试其实也可以放在编写测试用例的阶段，也就是【测试用例评审】，这样的评审，可以提前将测试用例完善，这样在测试的阶段就可以不用交叉测试了。（当然了，很多公司在实际操作时，都没有按照标准测试流程进行操作，很多时候根本就没有编写测试用例和用例评审的过程，这种情况就只能靠开发工程师自己的能力来保证测试质量了）
通过在多家公司的实际测试经验，我总结一下当前软件测试的实际情况和面临的问题：
1、有些公司的测试流程不完善，有些根本就没有流程，就是胡乱安排测试的；
2、有些公司的测试是有流程的，但是也不够重视测试，总是把未经培训的测试放在软件测试岗位上；
3、有些公司在招聘测试工程师时，随波逐流，还没把功能测试搞好，就急着想招聘自动化测试，舍本逐末；
4、有些公司在招聘测试工程师时，往往忽视工作经验和能力，更多的是强调学历和毕业院校等无关信息；
5、实际工作中，测试工程师常被当做杂工，什么零碎的活都让测试去做，浪费了测试人员的很多精力；
6、测试过程中，已经测试无误的功能，过段时间就反复出现相同的问题，会被说成是测试的问题（背锅）...
我们知道，没有完美的公司，没有完美的领导，但是我们有更多的公司和领导，把测试重视起来，开发生成功能，而测试保证体验。想让公司的产品质量更加有保证，就要让测试和开发一样，用更好的状态和饱满的精神去完成测试工作。专业的人做专业的事，才能让结果更加如人所愿！
我是John，一个小小的软件测试工程师，希望我的文字能帮助更多的人~
网友评论