测试流程、用例、管理工具

1、测试流程：
产品先将需求文档给我们看，然后我们会将自己不明白的地方罗列出来；之后我们产品和开发、测试会开一个评审会议，我们会询问不理解的地方，做好记录。会议后，组长会编写测试计划，并且给我们划分测试模块。之后我们会根据这个版本进行测试用例的编写。在这中间，需求也会经常变化，我们也会根据需求的变化，对测试用例进行调整，写用例的时候如果有不明白的地方，也会列一个questionlist，将不太理解的地方给列出来，然后让需求给予解答。直到后面需求基本都定了下来，开发那边基础功能也完成地差不多了，我们开发和测试间会进行一个用例评审，再对测试用例进行部分调整和添加。然后开发提测，我们跑case，如果发现了bug，会提交bug，开发根据我们提交的bug进行修改后，我们会再进行回归测试，查看问题是否fixed，如果修改成功，我们会将bug closed，如果没成功，会将bug改成active的状态。项目发版后，我们的组长会编写缺陷报告，测试报告。
2、bug管理工具如何使用？
内容：标题、指派给谁？（一般由测试经理指派），选择版本号，填入优先级，严重等级。然后写入测试步骤以及期望结果和实际结果，以及复现率和电脑OS号、版本号。有截图也要上传截图。如果后面开发进行修复了，我们要进行验证，无论是否修复成功，我们都要加comments。
commens的内容：

closed：在XXXX版本（可能要加电脑os）上验证，此bug已修复，因此关闭；

Active：在XXXX上验证，该bug复现。

reopen：在新版本上，发现了之前已修复（且closed）的bug再次出现，reopen加comments，在XXXX版本上实现
resolved：如果没有修改，没有add link新版本，则不对状态进行修改。（即开发改完后就是resolved）

more information：比如此bug在其他的电脑型号上也出现。

（回复开发的问题的时候，加上步骤和图片描述清楚。）

3、测试用例包括哪些内容？
UID（用例id），模块，标题，前置条件，步骤，期望结果，优先级，结果 （pass/fail/block/NA，pass绿色，fail红色，block黄色，N/A灰色），comments（备注）
Block：因为某个功能性的bug，阻碍了后面的测试；N/A：无法被测：为什么不能测？需求变更，这个版本不做了&测不了（需要开发配合）

4、测试用例，标题编写？
（1）输入正确的/错误的/空的……，查看结果
（2）点击……链接，查看跳转
（3）在……（情况）下检查……功能

（4）输入……，显示成功/失败
5、一条步骤，一个期望结果，优先级如何判定？
p0：最主要的、最基础的功能。如果执行不通过，就会阻碍后面的测试工作。比如是否可点击跳转，界面是否正确显示。
P1：产品的核心功能。如果执行不通过，会影响产品的正常使用，会给客户带来非常不好的体验。比如是否正确计算出来，输入是否正确……
P2：产品的一般功能。如果执行不通过，会影响某些小功能的使用，但不会阻碍客户的征程使用。如ui、异常情况、复杂性的场景。
p3：没那么重要的，不常常被执行的，以及放到下个版本解决的。

6、bug的严重等级：
p1：crash、功能性缺失；critical；p2：high：ui、文案的问题；p3：major：可修改和可不修改，对功能的影响不大，可以放在下一个版本修复；p4：medium：是我们的建议。其中 ，p1和p2必修
（另一说：致命：系统崩溃，如软件的意外退出，甚至操作系统崩溃，数据丢失。

                  严重：功能无法使用

                  一般：软件的非核心功能失效， 小问题、错别字、UI 布局（颜色，文字没对齐等），罕见故障          

                  提示：不影响使用的瑕疵或更好的实现）