91运营网 || 我们为什么要写测试计划 || 如何检查自己写的需求文档是否合格 || 软件测试之测试用例颗粒度问题 || 怎么样评价用例设计的质量 || BVT测试与冒烟测试
软件工程进阶之每日构建[3]：流程 || 软件缺陷分析-软件测试之犯罪心理学 || 软件缺陷度量
1、需求文档检查的具体步骤是什么？检查项主要包括什么，分别对应了那些检查要点？
具体步骤：
用户体验自查、内容自查、账号状态及用户权限自查、硬件环境需求自查、后台交互及管理需求自查
检查项：
1）产品功能点需求：用户需求→后台需求（数据监控等）
2）功能在系统中的位置：前台界面→用户管理后台(个人中心)→官方管理后台；
3）业务流程：步骤1→步骤2→步骤3→步骤3.1→步骤3.2……
4）功能主次关系：主要功能（场景or流程）→次要功能（场景or流程）；
5）功能点在页面布局中的位置：从上→下、从左→右；
6）按照软件状态：基本状态→特殊状态→异常状态；
2、测试计划的内部和外部作用分别是？
内部作用：
作为测试计划的结果，让相关人员和开发人员来评审。
存储计划执行的细节，让测试人员来进行同行评审。
存储计划进度表、测试环境等更多的信息。
外部作用：
给顾客一个信心，关于测试过程、技能、资源、工具等的信息。
3、怎样制定测试计划？
1、确定测试范围
2、制定测试策略
3、确定测试任务
4、确定测试资源和工作量
5、进度安排
6、风险及对策
4、测试用例设计应遵循的原则包括？
1、利用有效的测试技术来减少测试用例和测试场景的数量，用最小的工作量达到最大的测试覆盖率。（功能分析法、等价类划分、路径分析、边界值分析、正交分析等）
2、正确性、全面性、整体连贯性、可维护性、测试结果可判定性和可再现性。
5、怎样确定测试用例的粒度？
1、“重要功能”、“特殊功能”颗粒密集度高，“通用功能”可以试用通用测试粒度，密集度应该可以大致界定。个人认为，假如非要为了一个字体的样式而写了一大长串的测试用例 ，那么这个颗粒度就毫无意义了。
2、颗粒度的大小还取决与客户对“产品”的要求。测试有一个难题是测试的精度，或者说颗粒度的定义，不要说一个程序，就算是一个简单的登录都可以写出几乎无穷尽的测试用例，所以你需要指明功能、性能需求，使用环境等，并说明对缺陷容忍的限度。才好依据最终的需求来定义测试的颗粒度，也才好写测试用例，总之，客户的要
求越详细所得到的测试用例越准确。如果客户跟你说这个地方你必须仔仔细细的测试。那么我们在写测试用例的时候。这个颗粒度一定要小了。
3、一般功能颗粒密集度可能会根据项目或是时间来确定。如果时间充裕颗粒度可以适当小。
4、粒度取决于测试的种类，一般用验收测试,是项目测试中颗粒度比较大。系统测试颗粒度相对较小。
6、确定测试用例质量的方法有哪些？
测试用例内部评审、外部评审、按客户反馈评审
7、BVT测试和冒烟测试的区别是什么？
BVT 所做的测试内容很浅，这一特征似乎符合 Smoke Testing 的定义；但是 BVT 只验证 build 的构建情况，这一点与 Smoke Testing 截然不同，因此二者是完全不同的测试。另外：
- BVT 只在 build 构建完成时进行；Smoke Testing 是各个阶段都有的测试。
- 尽管 BVT 可以加入自动测试脚本并执行少量固定的自动化测试，但 Smoke Testing 与 build 的验证无关。
- BVT 的结果直接决定新构建的 build 是否交付后续测试；Smoke Testing 不影响其他日常测试工作。
8、每日构建的基本流程是什么？
1、提交代码到源代码管理服务器
2、从源代码服务器取出代码到编译服务器
3、在编译服务器生成最终安装包
4、提交安装包到发布服务器
5、从发布服务器获取安装包进行冒烟测试（可选）
6、测试人员从发布服务器上获取安装包并测试
9、常用的软件缺陷的指标是什么？
缺陷数量排行、缺陷发现时间、缺陷清除时间，派生度量元可选择整体缺陷清除率、阶段缺陷清除率、缺陷驻留时间等。
10、缺陷分析的方法是什么？
缺陷分布分析、缺陷趋势分析、注入矩阵分析