1. 软件测试的原则
应当把“尽早和不断的测试”作为开发者的座右铭
程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成
设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况
一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。测试中存在群集现象，错误喜欢发现在相同的模块以及相关的开发人员编写的程序
对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B 来确认，严重的错误可以召开评审会进行讨论和分析
制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试
回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见
妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档
2.软件测试经验
测试的Good Enough
Good-enough原则：不要做不充分的测试，也不要做过多的测试；找到测试费用和测试量之间的平衡点，是最佳选择
制定测试内容和最低测试通过标准加以衡量（必要时具体问题具体分析）。
测试的规律木桶原理和80－20原则
测试人员永远不要保证什么
测试人员的编写的文档是代表自己
测试人员要学会逆向思维
编写缺陷一定要保证重现
测试一定要根据需求
《规格需求说明书》
关注对用户不利的缺陷
站在用户的角度
适当的引入测试工具提高测试效率
测试人员是服务人员
3.有效制定软件测试计划？
3.1.概念
一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险
3.2.制定好处
项目经理、高层经理等相关领导能够根据测试计划做宏观调控，进行相应资源配置等；
测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等；
便于开发人员、市场人员、质量人员等了解测试人员的工作内容，进行有关配合工作；
3.3.谁来负责制定
具有丰富经验的项目测试负责人制定测试计划，需要对整个测试过程负责
3.4. 编写时间
软件测试计划越早编写越好，以便对整个项目有总体的测试规划
3.5.要素
why——为什么要进行这些测试，测试目的是什么；
what—测试哪些方面，确定测试的内容；
when—测试不同阶段的起止时间，确定各测试活动的时间；
where—相应文档，缺陷的存放位置，测试环境等；
who—谁来负责相应的工作；
how—如何去做，使用哪些测试工具以及测试方法、测试策略进行测试
3.6.模版
测试目的
测试项目简介
测试参考文档
测试提交文档
术语和定义
测试策略
确定测试内容
资源
测试进度
测试人员的任务分配
风险和问题
3.7.维护与评审
随着项目计划、软件需求、软件开发以及人员等的变更，软件测试计划也是不断更新和维护的
4.软件测试用例基本概念？
4.1.概念
测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
测试用例一般可以简单划分为：场景测试用例（简称“测试用例”）和基本测试用例（或称为“公用测试用例”）
4.2. 优缺点
好处
有效性
完整性
组织性
缺点
测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多
4.3.模版
Word
Excel
使用工具
根据公司具体情况制定模版
4.4.素质
测试用例的方法
考虑问题的全面性
业务知识的深刻性
逆向思维能力
丰富的测试经验
4.5.更新与维护
原因
需求变更，功能变化，测试用例也需要更新
测试用例需要细化和不断完善，是个循序渐进的过程
通过测试实践检验测试用例并添加、修改、删除测试用例
测试用例要经过正式、有效的评审
利用测试工具来管理测试用例
声明：本文部分内容可能来源或整理自网络，如有侵权，请联系删除