软件测试自动化学习笔记之二

 

1. 制定测试计划、进行测试设计及执行手工测试的，可以是同一个人。执行自动化测试的，则应该是专写测试脚本的专才。
2. 除了能在手工测试方面找到一两个就业机会外，IT行业当前惟有的就业机会就是编写自动化测试脚本。脚本应在测试计划和设计框架指导下做，不能盲目。
3. 显然，公司如果仍按目前的希望招聘的人上来就做自动化测试，而不招聘一些丰富经验的测试计划和测试设计人员，是很危险的。
4. 改进系统需求文档和软件测试方法最能提升测试工作的效率（找出潜在错误）。
5. 目前没有标准的文件指导软件测试的需求说明（或指导如何对已有的软件需求说明进行转换）。把已有的软件需求说明细化为软件测试需求是很困难的。
6. 在许多情况下，并没有事先写好的软件需求文档，因此，测试工程师需要依靠自己去找出软件测试需求！（想想vdb1.2及csdb-commons等，不能怪白乔）。
7. 从软件需求——>测试需求——>测试条件。两个箭头可以是一对一，多对一，一对多，多对多关系。遇到多对多关系时较复杂，可考虑分析之。
8. Rational Unified Process（RUP）将通用的软件需求分为几个类型：功能性需求、易用性需求（界面，文档和培训资料等）、可靠性需求、性能需求、支持需求（定义测试能力和维护能力）。同时也描述了几个面向软件构造方面的需求：设计需求、实现需求、接口需求、物理需求。
9. 手工测试的需求验证由测试工程师做，而自动化测试的需求验证主要由自动化测试代码判断。
10. 错误猜测与等价类划分和边界分析有着同样重要的作用，它弥补了这些功能的内在不完备性。等划分和边界分析互补，而错误猜测方法有效补充了这两种技巧。
11. 白盒测试基于代码、黑盒测试基于需求（功能）、灰盒测试介于两者之间（基于代码也基于功能）。
12. 冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。在一般软件公司，软件在编写过程中，内部需要编译多个版本(Builds)，但是只有有限的几个版本需要执行正式测试（根据项目开发计划），这些需要执行的中间测试版本，在刚刚编译出来后，软件编译人员需要进行基本性能确认测试，例如是否可以正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等Bug。如果通过了该测试，则可以根据正式测试文档进行正式测试。否则，就需要重新编译版本，再次执行版本可接收确认测试，直到成功。
13. 将测试数据，测试过程中的控制流程，都尽可能地避免硬编码。这样有很多好处：测试设计人员不需要编程便可设计测试用例、添加测试用例可以避免修改脚本等等。
14. 记录式测试脚本通常用处有限，并且需要在正式使用之前，对它们进行修改，最常见的缺点有：

• （1）硬编码
• （2）维护工作量大
• （3）不可靠，有时甚至程序没有任何改变也不能重复执行成功
• （4）记录效率慢。程序输入数据有变化、程序略有修改等都需要进行记录
• （5）软件可能不能正常运行，这个前提不成立，后续记录无法进行