第一次软件测试

前期准备

1. 阅读所有与项目有关的文档，包括：需求文档、设计文档、用户手册。
2. 参加各种项目会议，了解项目的背景、人员组成、了解需求和业务
3. 熟悉项目所使用的测试管理工具、配置管理工具，获取对应的地址和登录方式。
4. 阅读已有的测试方案和测试案例。
5. 阅读旧有的 bug 库，了解系统功能，和现有的测试团队保持一致的故障定级原则.
6. 了解公司的规范要求，如用例编写规范、用例执行规范、bug提交规范、测试工具使用规范等。

确认具体的工作内容：

1. 测试的计划是什么？
2. 测试的内容是什么？test case有多少？安排了几天执行？有没有自由测试的时间？
3. 要测试的内容开发人员是谁？需求人员是谁？
4. 我的测试内容是否需要特殊的测试资源？资源是否满足需要？

测试的执行

测试流程

1. 打开待测试的系统
2. 打开测试管理工具用例模块，开始执行用例
3. 发现bug！进行复现并确认bug的复现步骤
4. 记录bug
5. 沟通bug
6. 验证以前提交的bug
7. 确认本次测试完成
8. 编写测试报告

执行测试时还要有临时发挥的能力，根据自己的经验、对测试的感悟以及随机测试可以发现很多根据测试用例无法发现的缺陷。

在测试执行过程中要不断总结测试方法和测试故障模型。真正优秀的测试人员在执行测试时是想着做，做着想，这样的测试效果才好，尤其是在测试过程中，对程序的处理相当了解的情况下，测试的思路会更加清晰和全面。

以注册的需求来进行一次测试

• 功能：所有需求描述的功能
• 功能其他：需求未考虑到的：邮件内容是否正确？连续注册？
• 边界：最大值、最小值等
• 界面：美观，整齐
• 校验：email格式校验，错误校验，已注册校验、输出校验，为空等
• 兼容性：IE,CHROME,360…
• 安全性：验证码能否起效？http请求直接发送？
• 性能：多用户并发
• 其他：48小时真的是48小时么？

bug管理

如何发现更多的bug？

1. 软件测试同样存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度和深度！
2. 开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的bug较多，加强他开发模块的测试广度和深度！
3. 多进行逆向思维和发散性思维
4. 不要局限于用例和需求文档
5. 尽早介入项目, 不要等到开发的差不多了才介入项目

产生分歧时怎么办

清楚、准确，切题、深刻，有意义，有逻辑性，公正、全面

1. 先检查自身，是否bug描述不清楚
   如果能正确地、高质量地录入一个Bug，那么基本上已经成功地与开发人员沟通了一大半关于Bug的信息。但是总有“书难达意”的耐候，这时就需要测试人员主动与开发人员进行沟通了。如果测试人员发现在写完一个缺陷后，好像还有很多关于Bug的信息没有表达出来，或者很难用书面语言表达出来时，就应该在提交Bug后，马上找相关的程序员解释刚才录入的Bug，确保程序员明白Bug描述的意思，而不要等待开发人员找自己了解更多的信息。
2. 站在用户角度考虑问题
   应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。
3. BUG定级要有理有据
   BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往用户的BUG级别和我们的是有区别的，需站在用户的角度定考虑定位级别。
4. 提高自身的技术和业务水平
   提高自身的业务和技术水平，不但要能提出问题，还能够提出解决问题的思路。
5. 发起BUG评审
   可能你已经经过了多轮沟通，但是开发人员仍然拒不接受。此时可以发起Bug评审。