2017年从学校毕业到参加工作一年时间，一直在从事着软件测试的工作，先后通过两位测试同事的合作与学习，再加上这一年来大大小小的软件测试经验，总结了一些心得。
首先是测试流程，流程相对于工作不光是规范，同时也是在告诉我们每个阶段需要做什么。
然后是测试用例，主要是说明测试用例的必要性和编写的方法。
第三是缺陷管理，包括了缺陷的生命周期以及录入一个缺陷生命周期需要哪些要素。
第四是测试报告，简要说明测试报告应该包含的内容。
第五是其他测试。
一、测试流程
1）项目启动时，项目经理根据项目的需求，向测试部门提出测试人员需求，应该包括以下内容：项目周期、项目目标以及完成标准；
2）测试部门在接到项目组的测试需求后，进行需求评审，需要给出相应的团队信息，团队人员、分工；
3）测试主管需要写测试计划，对整个项目的开展进行排期，同时也包括了测试人员的分工和工作排期；
4）测试人员在接到工作任务安排的时，
4-1）首先要详细阅读需求文档和原型，分析需求时，可能会遇到需求文档描述的不清晰或者功能逻辑遗漏的情况，所以在写测试用例之前，最好要有一份测试分析文档，测试分析针对系统功能拆分进行粗略的书写，在测试分析时就要找产品部门进行需求核对，把不符合逻辑的地方讨论清楚；
4-2）测试分析完成后，参照已有的测试分析，就可以进行测试用例的书写，测试用例和开发写程序的时间是并行的，可能提早；
4-3）完成测试用例编写后，测试部门内部需要对测试用例进行评审并修改；
5）在开发将war包提交给测试部门后，测试部门可以将已经准备好的测试环境搭建发版，首先收到开发人员的邮件说明（需@项目组），哪些页面哪些功能可以进行测试，然后测试人员有正对性地对相应的功能进行一轮冒烟测试，查看是否达到测试准入的规范，
5-1）不通过测试准入，鉴于没有引入相应的奖惩措施，可以回复开发的转测邮件，说明问题影响测试工作；
6）执行测试用例过程中，进行日程bug管理、回归测试；
7）测试通过，输出测试报告；
8）项目上线，正式环境测试；
二、测试用例
1）简述：用文字描述出系统测试时的操作步骤
2）好处：
2-1）清晰思路、避免遗漏
当系统功能多且复杂时，根据系统每个模块，拆分功能点，花点时间思考并整理成文档，尽可能结合功能与业务，模拟不同场景，从根本上避免了直接测试系统的“手忙脚乱”。
2-2）明确测试进展
参考测试用例，可以清晰看到哪些用例执行了，哪些用例没有执行，从中看到测试进行到哪一步，以及结合问题管理平台，直观地从测试角度，分析项目进展。
2-3）系统模块缺陷率
根据测试用例发现的问题，可以看到哪个功能模块出现的bug较多。
3）方法：
3-1）等价类划分：输入的子集中选择，假如输入要求输入数字1到10，那么输入4和7去验证；
3-2）边界值：输入支持的最大值，假如一个文本输入框最大值为100，输入的内容超过101；
3-3）因果图：判定表，通过因果关系判定；
3-4）错误推测法：基于测试经验推测系统在什么样的操作可能会出现错误；
4）元素：
4-1）目录
根据拆分的系统功能点，每个功能点可以用目录的方式区分，如一个系统的系统管理-用户管理-用户添加，那么系统管理就是一级目录，用户管理就是二级目录，用户添加就是三级目录；
4-2）测试项
同上，根据三级目录，一般用户添加包括的元素有用户名、密码输入框、保存按钮、取消，那么每个元素都可以分成一个测试项；
4-3）操作步骤
每一个测试项，都对应相应的操作步骤，可以分成操作步骤1、操作步骤2，操作步骤可以细化到，点击添加用户的按钮、输入框输入某某用户名密码点击保存按钮；
4-4）预期结果
操作步骤，在完成一系列动作之前，都要有对应预期结果作为参考，这个参考就是最初业务部门提供的需求分析文档，根据需求分析文档来告诉我们每一个功能要有什么样的结果；
4-5）实际结果
操作步骤，完成之后，需要记录实际的情况，如果与预期结果不符，就可以归于bug；
考虑是否可以将实际结果改成注释，避免与预期结果一一对应关系，解耦合。
4-6）优先级
5）探索性测试
在设计测试用例时，并不能完全保证每个功能每个场景都设计到位，而且单纯执行测试的时候非常枯燥，那么加入一点发散性思维，进行一些非常规性操作，以用户的心态去使用系统，或是尽情地“破坏”系统，发现系统的问题。
真正的探索性测试需要对产品的深入了解，以及软件开发技术有一定的深度和宽度。
6）用例评审
测试用例编写完成后，需要在测试内部进行一次评审，评审的内容包括：功能是否完整、需求是否符合，使每一个测试人员在系统测试过程中，不存在主体思维的偏差。
同时用例评审也是一个很好的学习过程，每一位测试人在介绍系统时，能够意识到各自设计用例时的不足，包括自动化、性能都可以进行技术的探讨。
7）不需要用例情况：
7-1）功能过于简单
7-2）急于交付，弊端就是不能保证测试的覆盖率。
三、缺陷管理
1）缺陷生命周期：
1-1）提交bug、指派解决人员、确认问题、处理问题、回归测试、关闭问题
1-2）确认问题时，如果开发未发现问题情况，需要测试进一步验证，验证完后再次提交；
1-3）回归测试时，如果测试未通过，需要打回处理，相关措施可以参照准入流程邮件发送；
2）缺陷要素
2-1）重现环境，需要注明操作系统、什么浏览器及版本、还有在测试环境下哪个数据库；
2-2）问题类型，redmine有系统异常、操作指导、新需求；
2-3）缺陷等级，等级可以由低——>中——>高——>紧急来划分，高优先级的任务必须要求开发人员优先处理；
2-4）缺陷状态，有新建、处理中、已解决等；
2-5）操作步骤，描述发现问题时的操作场景；
2-6）预期结果，描述发现问题时的操作步骤，应该是什么样的结果；
2-7）测试结论，简要说明问题情况以及结论；
2-8）截图，tomcat的log日志；
四、测试报告（第四点copy百度百科）
1）测试结论（测试是否通过/是否满足发布要求/是否能够发布）
2）罗列发现的主要问题（或者说该版本存在的主要风险）
3）测试版本（客户端，服务器）（如果允许发布，附件发布包或其链接，包大小，以及md5校验码）
4）测试内容（测试范围）
5）测试用例执行情况（一共多少，执行了多少，未执行多少，通过多少，失败多少）
6）发现的严重缺陷有哪些（仅仅罗列最严重级别的bug）
7）邮件的附件是测试计划执行结果文件
五、用户容忍度与易用性测试
很多时候，项目组对待软件的质量会与用户容忍度有一定的关系，像是交付性的软件，只需要做完之后然后交付给用户，甚至UAT不需要测试部门内部进行，那么这样的情况下，我们更关心的应该是功能的实现。
举个不恰当的栗子，当你很口渴的时候有个水壶，你需要一个杯子，那么你关心的只是这个杯子能不能装水能不能喝，此时杯子需要的特性就是：能用、干净。
但是如果这个杯子被放在商城的展柜上时，那么需要的特性就非常的多了，如下拆分：
1）功能测试。杯子是否能装水，还能否装下其他液体，杯子的容量如何，是否有刻度，能支持最大的热量和最低的温度是多少；
2）界面测试。杯子的外观如何，颜色和形状怎么样，重量如何，是否有异味；
3）性能测试。能否装100°以上的水，泡茶泡面，能否放在冷藏柜里冰冻，杯子盛水后长时间是否会漏水，是否会被压碎；
4）安全性测试。杯子是否有毒，是否易碎，碎后时候会割手，易生细菌，会不会爆炸或融化；
5）易用性测试。杯子形状在手上好不好拿，导热如何会不会烫手，是否防滑，形状设计是否容易被喝到；
有时候不要为了测试去测试，为了体现自己的价值，非揪着某个问题不放，对项目进展没有帮助性的工作。对此，我并不是说测试人员可以放弃自己的测试原则，只是说当前的环境并不支持或适合你去开展测试工作。
为贡献产品的发展测试远比为了测试了测试所带来的价值大得多；所以站在产品的发展上去看待测试工作更能体现自己的价值。